在这里记录自己的嵌入式学习方向和成果，只做大方向的规划，目前学习规划如下：

• √ linux基础学习

• √ arm裸机开发（使用正点原子IMX6ULL的板子）

• √ linux的系统移植

• √ Linux核心驱动开发

• √ qt

• √ linuxc应用编程

• 【doing】linux内核源码分析（主要通过以下两本书并结合linux源码进行学习）：

  • linux内核设计与实现（在看）
  • 深入理解linux内核

引言

在现代多核处理器系统中，处理器核心的组织方式和任务分配策略直接影响系统的软件设计与通信方式。按照核心间的共享程度，多核系统通常可以分为 对称多处理（SMP, Symmetric Multi-Processing） 和 非对称多处理（AMP, Asymmetric Multi-Processing） 两类。

SMP 架构

SMP 系统中的所有核心平等地共享同一份内存和 I/O 资源。每个核心运行相同的操作系统实例，一个核通过_start初始化以后，唤醒其他的核做secondary_start_kernel，可以执行任意任务，并通过统一的调度器协调任务执行。

AMP 架构

AMP 系统中，各个核心独立运行自己的操作系统实例或裸机程序，它们之间可能不共享内存，甚至运行不同类型的操作系统。典型应用包括 异构多核 SoC，如 Cortex-A 与 Cortex-M 核组合，或者 CPU 与 DSP 的混合系统。

SMP 与 AMP 的主要区别

SMP多对称处理器间的通讯

应用场景

1. 调度应用

   • 场景：当一个 CPU 修改了任务优先级 / 唤醒了一个任务，但该任务更适合在另一个 CPU 上执行时。

   • 做法：当前 CPU 向目标 CPU 发送 IPI，目标 CPU 立即触发调度器，切换到这个任务

2. 跨核函数调用（smp_call_function）

   • 场景：某个内核子系统需要在所有 CPU 上执行一段代码，比如linux下的fiq-debugger机制：当某个核卡死的时候依然可以通过smp_call_function让该卡死的核执行传入的回调函数，在调试的时候非常好用，比如我的代码导致了某一个核卡死了，可以通过smp_call_function的机制让卡死的核dump一些信息

   • 做法：一个 CPU 发 IPI 给其他 CPU，让它们都执行一个回调函数。

3. 核间通知 / 快速消息传递

   • 场景：一个 CPU 发现了全局事件（如中断、数据更新），需要立即通知其他 CPU。
   • 做法：通过 IPI 发送“消息”或触发事件处理函数。

在linux下多个a核间的通讯相对来说比较简单，主要是通过向需要通讯的核发一个ipi中断来实现，ipi中断以及中断处理函数在初始化的时候进行注册

IPI 的全称是 Inter-Processor Interrupt，中文一般叫 处理器间中断 或 核间中断。

它的作用就是在 **多核处理器 ** 系统里，让一个 CPU 主动“打断”另一个 CPU，从而实现 跨核通信与协作。

初始化前瞻

先看一些定义： linux内核支持的ipi调用

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21

enum ipi_msg_type {
	IPI_WAKEUP,
	IPI_TIMER,
	IPI_RESCHEDULE,
	IPI_CALL_FUNC,
	IPI_CPU_STOP,
	IPI_IRQ_WORK,
	IPI_COMPLETION,
	NR_IPI,
	/*
	 * CPU_BACKTRACE is special and not included in NR_IPI
	 * or tracable with trace_ipi_*
	 */
	IPI_CPU_BACKTRACE = NR_IPI,
	/*
	 * SGI8-15 can be reserved by secure firmware, and thus may
	 * not be usable by the kernel. Please keep the above limited
	 * to at most 8 entries.
	 */
	MAX_IPI
};

1. 为每个核注册ipi中断（也就是gic控制器的SGI中断–注册为软件中断）：

   1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28

   void __init set_smp_ipi_range(int ipi_base, int n) { int i; WARN_ON(n < MAX_IPI); nr_ipi = min(n, MAX_IPI); //遍历所有支持的sgi中断号 for (i = 0; i < nr_ipi; i++) { int err; //为每个cpu注册相同的中断处理函数 err = request_percpu_irq(ipi_base + i, ipi_handler, "IPI", &irq_stat); WARN_ON(err); //把中断描述符存在本地静态变量中 ipi_desc[i] = irq_to_desc(ipi_base + i); irq_set_status_flags(ipi_base + i, IRQ_HIDDEN); /* The recheduling IPI is special... */ if (i == IPI_RESCHEDULE) __irq_modify_status(ipi_base + i, 0, IRQ_RAW, ~0); } ipi_irq_base = ipi_base; /* Setup the boot CPU immediately */ ipi_setup(smp_processor_id()); }

2. 看一下ipi的处理函数

   1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69

   //看一下都支持哪些中断处理 static void do_handle_IPI(int ipinr) { unsigned int cpu = smp_processor_id(); if ((unsigned)ipinr < NR_IPI) trace_ipi_entry_rcuidle(ipi_types[ipinr]); switch (ipinr) { case IPI_WAKEUP: break; #ifdef CONFIG_GENERIC_CLOCKEVENTS_BROADCAST case IPI_TIMER: //看起来是时钟相关的 tick_receive_broadcast(); break; #endif case IPI_RESCHEDULE: //执行调度 scheduler_ipi(); break; case IPI_CALL_FUNC: //执行某个函数回调 generic_smp_call_function_interrupt(); break; case IPI_CPU_STOP: //暂停cpu ipi_cpu_stop(cpu); break; #ifdef CONFIG_IRQ_WORK case IPI_IRQ_WORK: //执行延迟的 irq_work 任务 irq_work_run(); break; #endif case IPI_COMPLETION: //通知ipi发起者某个操作完成了 ipi_complete(cpu); break; case IPI_CPU_BACKTRACE: //打印backtrace printk_nmi_enter(); nmi_cpu_backtrace(get_irq_regs()); printk_nmi_exit(); break; default: pr_crit("CPU%u: Unknown IPI message 0x%x\n", cpu, ipinr); break; } if ((unsigned)ipinr < NR_IPI) trace_ipi_exit_rcuidle(ipi_types[ipinr]); } static irqreturn_t ipi_handler(int irq, void *data) { //通过传入相对的中断号码 do_handle_IPI(irq - ipi_irq_base); return IRQ_HANDLED; }

案例分析

这里拿IPI_CALL_FUNC来举例，场景是我们需要唤醒某个cpu执行一个函数（比如dump当前的reg）：ps – 为了方便理解整体的链路，代码部分我进行了一定的删减，因此与实际上的linux的代码有差异，感兴趣可移步至源码kernel/smp.c与arch/arm/kernel/smp.c中阅读

处理部分主要分为两个链路，一个是发ipi的链路，一个是处理ipi的链路，先看发ipi中断的链路：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102

//这里其实就是处理所有发送ipi中断请求的接口，属于芯片架构层（这里会调用不同中断处理器的架构注册的回调函数）
int __ipi_send_mask(struct irq_desc *desc, const struct cpumask *dest)
{
    struct irq_data *data = irq_desc_get_irq_data(desc);
    struct irq_chip *chip = irq_data_get_irq_chip(data);
    unsigned int cpu;
	
    //如果该中断处理器已经注册了直接处理对应掩码的函数直接调用
    if (chip->ipi_send_mask) {
    	chip->ipi_send_mask(data, dest);
    	return 0;
    }

    //开始发送
    for_each_cpu(cpu, dest)
		chip->ipi_send_single(data, cpu);
    return 0;
}

static void smp_cross_call(const struct cpumask *target, unsigned int ipinr)
{
    trace_ipi_raise_rcuidle(target, ipi_types[ipinr]);
    __ipi_send_mask(ipi_desc[ipinr], target);
}

void arch_send_call_function_single_ipi(int cpu)
{
  	smp_cross_call(cpumask_of(cpu), IPI_CALL_FUNC);
}

void send_call_function_single_ipi(int cpu)
{
    //这里就进入到架构层了，会去对应的架构找相应的发ipi的函数
    arch_send_call_function_single_ipi(cpu);
}

void __smp_call_single_queue(int cpu, struct llist_node *node)
{
    //把回调的结构体加入对应cpu的链表中 -- 该例子中传入的是0 也就是代表将该事件加入到cpu0的执行list中
    if (llist_add(node, &per_cpu(call_single_queue, cpu)))
    	send_call_function_single_ipi(cpu);
}

static int generic_exec_single(int cpu, struct __call_single_data *csd)
{
    //如果是本cpu就直接执行传入的函数
    if (cpu == smp_processor_id()) {
        smp_call_func_t func = csd->func;
        void *info = csd->info;
        unsigned long flags;

        csd_lock_record(csd);
        csd_unlock(csd);
        local_irq_save(flags);
        func(info);
        csd_lock_record(NULL);
        local_irq_restore(flags);
        return 0;
    }
    
    //发ipi到其他cpu
    __smp_call_single_queue(cpu, &csd->llist);

    return 0;
}

//参数： cpu：要执行回调的cpuid func：回调函数指针 info：私有指针，供回调函数使用 wait：是否等待其他cpu执行完再退出
int smp_call_function_single(int cpu, smp_call_func_t func, void *info,
                             int wait)
{
    call_single_data_t *csd;
    call_single_data_t csd_stack = {
    	.flags = CSD_FLAG_LOCK | CSD_TYPE_SYNC,
    };
    int this_cpu;
    int err;

	//防止当前线程被调度到其他 CPU
    this_cpu = get_cpu();

    //确保这里不是在中断的上下文中调用的
    WARN_ON_ONCE(!in_task());

    csd = &csd_stack;
    //如果这里不等其他cpu执行完再退出的话就需要用全局变量作为参数防止该函数退出后导致访问空指针
    if (!wait) {
        csd = this_cpu_ptr(&csd_data);
        csd_lock(csd);
    }
	//设置函数指针和信息
    csd->func = func;
    csd->info = info;
	//发送ipi
    err = generic_exec_single(cpu, csd);

    if (wait)
    	csd_lock_wait(csd);

    put_cpu();

    return err;
}

既然中断已经发送过去了就需要看一下对应的中断处理函数，也就是generic_smp_call_function_interrupt：代码依旧只保留了关键逻辑

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48

static void flush_smp_call_function_queue(bool warn_cpu_offline)
{
    call_single_data_t *csd, *csd_next;
    struct llist_node *entry, *prev;
    struct llist_head *head;
    static bool warned;

    lockdep_assert_irqs_disabled();

    // 获取当前CPU的回调队列
    head = this_cpu_ptr(&call_single_queue);
    entry = llist_del_all(head);
    entry = llist_reverse_order(entry);

    prev = NULL;
    llist_for_each_entry_safe(csd, csd_next, entry, llist) {
		// 处理 SYNC 类型回调（同步等待的回调）
        if (CSD_TYPE(csd) == CSD_TYPE_SYNC) {
            smp_call_func_t func = csd->func;
            void *info = csd->info;
			
            if (prev) {
                prev->next = &csd_next->llist;
            } else {
                entry = &csd_next->llist;
            }

            csd_lock_record(csd);
          	//关键就是从链表中取出该该任务执行对应的回调
            func(info);
            csd_unlock(csd);
            csd_lock_record(NULL);
        } else {
            prev = &csd->llist;
        }
    }

    if (!entry)
        return;
    if (entry)
        sched_ttwu_pending(entry);
}


void generic_smp_call_function_single_interrupt(void)
{
	flush_smp_call_function_queue(true);
}

for test

我们可以写一段测试程序来验证一下我们上面所说的框架：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38

#include <linux/module.h>
#include <linux/kernel.h>
#include <linux/init.h>
#include <linux/smp.h>

static void smp_test_func(void *info)
{
    int cpu = smp_processor_id();
    printk("CPU%d executed callback, info=%s\n",
            cpu, (char *)info);
}

static int __init smp_test_init(void)
{
    int cpu;
    printk("SMP Call Function Any Test Module Loaded\n");

    for_each_online_cpu(cpu) {
        printk("Sending task to CPU%d...\n", cpu);
        smp_call_function_any(cpumask_of(cpu),
                              smp_test_func,
                              "Hello SMP",
                              1 );
    }

    printk("All CPUs have executed the callback.\n");
    return 0;
}

static void __exit smp_test_exit(void)
{
    printk("SMP Call Function Any Test Module Unloaded.\n");
}

module_init(smp_test_init);
module_exit(smp_test_exit);

MODULE_LICENSE("GPL");

这里只是做了一行打印，但是我们在回调函数中的自由度是非常高的，所以可以做一些非常有意思的事情，例如dump当前cpu的一些信息

总结

所以总的来说，linux下的smp间的通信就是基于下发ipi中断来实现的，整体的流程也非常的简单：

1. 初始化阶段

   • 内核启动时，会调用 set_smp_ipi_range()

   • 为 每个 CPU 注册好所有支持的 IPI 中断号（SGI → 对应 ipi_handler）

   • 所有 IPI 的入口统一落到 ipi_handler() → do_handle_IPI(ipinr)

2. 通信阶段

   • 某个 CPU 需要和别的 CPU 通讯时 → 调用 smp_cross_call(cpumask, ipi_nr)

   • 本质就是往目标 CPU 发一个 IPI 中断（SGI）

3. 处理阶段

   • 目标 CPU 收到 IPI → 进入统一的 ipi_handler()

   • 根据 IPI 类型 分发到不同的处理逻辑：

     • IPI_CALL_FUNC → 执行 generic_smp_call_function_interrupt()，在目标 CPU 上调用函数
       • IPI_RESCHEDULE → 执行 scheduler_ipi() → 触发一次 schedule() 调度
       • IPI_CPU_STOP → 停止 CPU
       • IPI_IRQ_WORK → 执行 irq_work
       • IPI_CPU_BACKTRACE → 打印 backtrace

4. 举一反三（线程切换例子）
   如果我们想让某个 CPU 立刻执行一次线程切换：

1
2

// 发一个 IPI_RESCHEDULE 到目标 CPU -- 可能会封装好api，但是最终都会走到这里
smp_cross_call(cpumask_of(cpu), IPI_RESCHEDULE);

​ 在目标 CPU 上最终执行的就是：

1
2
3

case IPI_RESCHEDULE:
    scheduler_ipi();   // -> 最终进入 schedule()
    break;

​ 所以完全可以推断：**IPI_RESCHEDULE 的处理函数就是触发 schedule()**。

图示如下：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44

graph TD

    subgraph CPUn["CPUn (发起方)"]
        FUNCREQ["smp_call_function*() 发起请求"]
        RESECHEDULE["smp_send_reschedule"]
        .....["....."]
        SENDIPI["调用 send_call_function_single_ipi()"]
    end

    subgraph ABST["架构抽象层 (ARCH 层)"]
        ARCHSEND["arch_send_call_function_single_ipi() 发送 IPI"]
        ARCHRECV["handle_IPI() (ARCH 层实现)"]
    end

    subgraph HW["硬件 (GIC / APIC)"]
        HWIPI["触发 IPI 硬件中断"]
    end

    subgraph CPUm["CPUm (接收方)"]
        IRQ["CPUm 收到 IPI 中断"]
        HANDLEIPI["进入 handle_IPI()"]
        
    end
    
    subgraph ipi_hand["handle_IPI"]
    	DISPATCH["根据 IPI 类型分发"]
        CALLFUNC["IPI_CALL_FUNC → generic_smp_call_function_interrupt()"]
        RESCHED["IPI_RESCHEDULE → scheduler_ipi() 调度器"]
        ...["..."]
    end

    FUNCREQ --> SENDIPI
    RESECHEDULE --> SENDIPI
    ..... --> SENDIPI
    SENDIPI --> ARCHSEND
    ARCHSEND --> HWIPI
    HWIPI --> IRQ
    IRQ --> HANDLEIPI
    HANDLEIPI --> ARCHRECV
    ARCHRECV --> DISPATCH
    DISPATCH --> CALLFUNC
    DISPATCH --> RESCHED
    DISPATCH --> ...

AMP非对称多核的通讯

由于a核和m核心之间通信方式有很多，大部分要看soc内部的硬件实现，比如mailbox，共享内存等等的机制，对于机制的具体实现本节我们不过多关注，但是linux提供了一个rpmsg的框架，用于向用户屏蔽底层差异。源码位于 driver/rpmsg下

rpmsg在linux中作为一个单独的总线实际上和其他类似platform，iic，pcie总线类似，总线的主体都是由probe，remove，match组成的。

先看一下这个结构：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88

/**
 * struct rpmsg_device_ops - indirection table for the rpmsg_device operations
 * @create_ept:		create backend-specific endpoint, required
 * @announce_create:	announce presence of new channel, optional
 * @announce_destroy:	announce destruction of channel, optional
 *
 * Indirection table for the operations that a rpmsg backend should implement.
 * @announce_create and @announce_destroy are optional as the backend might
 * advertise new channels implicitly by creating the endpoints.
 */
struct rpmsg_device_ops {
	struct rpmsg_endpoint *(*create_ept)(struct rpmsg_device *rpdev,
					    rpmsg_rx_cb_t cb, void *priv,
					    struct rpmsg_channel_info chinfo);

	int (*announce_create)(struct rpmsg_device *ept);
	int (*announce_destroy)(struct rpmsg_device *ept);
};
/**
 * rpmsg_device - device that belong to the rpmsg bus
 * @dev: the device struct
 * @id: device id (used to match between rpmsg drivers and devices)
 * @driver_override: driver name to force a match
 * @src: local address
 * @dst: destination address
 * @ept: the rpmsg endpoint of this channel
 * @announce: if set, rpmsg will announce the creation/removal of this channel
 */
struct rpmsg_device {
	struct device dev;
	struct rpmsg_device_id id;
	char *driver_override;
	u32 src;
	u32 dst;
	struct rpmsg_endpoint *ept;
	bool announce;

	const struct rpmsg_device_ops *ops;
};

typedef int (*rpmsg_rx_cb_t)(struct rpmsg_device *, void *, int, void *, u32);
typedef int (*rpmsg_rx_sig_t)(struct rpmsg_device *, void *, u32, u32);

/**
 * struct rpmsg_endpoint - binds a local rpmsg address to its user
 * @rpdev: rpmsg channel device
 * @refcount: when this drops to zero, the ept is deallocated
 * @cb: rx callback handler
 * @cb_lock: must be taken before accessing/changing @cb
 * @sig_cb: rx serial signal handler
 * @addr: local rpmsg address
 * @priv: private data for the driver's use
 *
 * In essence, an rpmsg endpoint represents a listener on the rpmsg bus, as
 * it binds an rpmsg address with an rx callback handler.
 *
 * Simple rpmsg drivers shouldn't use this struct directly, because
 * things just work: every rpmsg driver provides an rx callback upon
 * registering to the bus, and that callback is then bound to its rpmsg
 * address when the driver is probed. When relevant inbound messages arrive
 * (i.e. messages which their dst address equals to the src address of
 * the rpmsg channel), the driver's handler is invoked to process it.
 *
 * More complicated drivers though, that do need to allocate additional rpmsg
 * addresses, and bind them to different rx callbacks, must explicitly
 * create additional endpoints by themselves (see rpmsg_create_ept()).
 */
struct rpmsg_endpoint {
	struct rpmsg_device *rpdev;
	struct kref refcount;
	rpmsg_rx_cb_t cb;
	struct mutex cb_lock;
	rpmsg_rx_sig_t sig_cb;
	u32 addr;
	void *priv;

	const struct rpmsg_endpoint_ops *ops;
};

struct rpmsg_driver {
	struct device_driver drv;
	const struct rpmsg_device_id *id_table;
	int (*probe)(struct rpmsg_device *dev);
	void (*remove)(struct rpmsg_device *dev);
	int (*callback)(struct rpmsg_device *, void *, int, void *, u32);
	int (*signals)(struct rpmsg_device *rpdev,
		       void *priv, u32 old, u32 new);
};

使用方法

我们以rockchip的核间通讯的驱动为例：
首先会注册一个platform总线的驱动框架用于管理自己的设备资源：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16

static const struct of_device_id rockchip_rpmsg_match[] = {
	{ .compatible = "rockchip,rk3562-rpmsg", .data = (void *)RK3562, },
	{ .compatible = "rockchip,rk3568-rpmsg", .data = (void *)RK3568, },
	{ /* sentinel */ },
};

MODULE_DEVICE_TABLE(of, rockchip_rpmsg_match);

static struct platform_driver rockchip_rpmsg_driver = {
	.probe = rockchip_rpmsg_probe,
	.remove = rockchip_rpmsg_remove,
	.driver = {
		.name = "rockchip-rpmsg",
		.of_match_table = rockchip_rpmsg_match,
	},
};

在probe中会注册一个virtio设备，同时注册mailbox通道，将virtio的rx tx 接口设置为mailbox，我们可以理解mailbox是在virtio的下一层，是实际和硬件交互的层级：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18

//这是我从probe中提取出来的一部分
for (i = 0; i < rpdev->vdev_nums; i++) {
		dev_info(dev, "rpdev vdev%d: vring0 0x%x, vring1 0x%x\n",
			 i, rpdev->rpvdev[i]->vring[0], rpdev->rpvdev[i]->vring[1]);
		rpdev->rpvdev[i]->vdev.id.device = VIRTIO_ID_RPMSG;
		rpdev->rpvdev[i]->vdev.config = &rk_rpmsg_config_ops;
		rpdev->rpvdev[i]->vdev.dev.parent = dev;
		rpdev->rpvdev[i]->vdev.dev.release = rk_rpmsg_vdev_release;
		rpdev->rpvdev[i]->base_queue_id = i * 2;
		rpdev->rpvdev[i]->rpdev = rpdev;

		ret = register_virtio_device(&rpdev->rpvdev[i]->vdev);
		if (ret) {
			dev_err(dev, "fail to register rpvdev: %d\n", ret);
			goto free_reserved_mem;
		}
	}

在a核上我们可以将m核作为一个虚拟设备，使用virtio去管理，所以rgmsg基于virtio注册了一个通用的驱动，位于drivers/rpmsg/virtio_rpmsg_bus.c下：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31

//只要virtio id device ==  VIRTIO_ID_RPMSG 的所有设备都可以进probe中
static struct virtio_device_id id_table[] = {
	{ VIRTIO_ID_RPMSG, VIRTIO_DEV_ANY_ID },
	{ 0 },
};

static unsigned int features[] = {
	VIRTIO_RPMSG_F_NS,
};

static struct virtio_driver virtio_ipc_driver = {
	.feature_table	= features,
	.feature_table_size = ARRAY_SIZE(features),
	.driver.name	= KBUILD_MODNAME,
	.driver.owner	= THIS_MODULE,
	.id_table	= id_table,
	.probe		= rpmsg_probe,
	.remove		= rpmsg_remove,
};

static int __init rpmsg_init(void)
{
	int ret;

	ret = register_virtio_driver(&virtio_ipc_driver);
	if (ret)
		pr_err("failed to register virtio driver: %d\n", ret);

	return ret;
}

当我们的soc中需要做m核和a核的通讯的时候，我们需要注册一个rpmsg driver以及一个device，而在上面的rpmsg_probe就会执行device的注册，此时我们再需要注册一个rpmsg的driver就可以让这一套机制运行起来了，由于virtio框架内容比较多，这里不纠结底层的实现了，大致流程可以从如下框图看出：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25

sequenceDiagram
    participant APP as 用户态应用
    participant RPDRV as RPMsg 驱动
    participant VQ as Virtio/vring
    participant MBOX_CL as Mailbox Client
    participant HW as Mailbox 硬件
    participant MBOX_SRV as Mailbox Server
    participant RPKERN as 远端 RPMsg 核心
    participant FW as 远端固件/RTOS 应用

    APP->>RPDRV: 写消息
    RPDRV->>VQ: enqueue 到 tx virtqueue
    VQ->>MBOX_CL: virtqueue_kick()
    MBOX_CL->>HW: mbox_send_message()
    HW->>MBOX_SRV: 触发中断 / 写寄存器
    MBOX_SRV->>RPKERN: 收到消息，放入 vring buffer
    RPKERN->>FW: 调用远端应用回调
    FW-->>RPKERN: 响应数据
    RPKERN->>MBOX_SRV: enqueue 响应到 vring
    MBOX_SRV->>HW: 触发中断通知 A 核
    HW->>MBOX_CL: 收到中断
    MBOX_CL->>VQ: virtqueue callback
    VQ->>RPDRV: rpmsg_receive()
    RPDRV->>APP: 调用用户回调 / 返回消息

从0分析RTT内核aarch64启动流程

分析前先看下面这个函数：

1
2
3
4

.macro get_phy, reg, symbol
    adrp    \reg, \symbol
    add     \reg, \reg, #:lo12:\symbol
.endm

• adrp \reg, \symbol 计算symbol相较于pc寄存器的页基地址，可以看成：

  1	reg = (symbol & ~(0xFFF)) - (pc & ~(0xFFF)) + (pc & ~(0xFFF))

• 再通过add \reg, \reg, #:lo12:\symbol将symbol的低12位与reg相加存放回reg中

这么使用是为了解除直接使用ldr reg,=symbol的限制

step1

首先从内核的入口_start进行分析：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43

/* Variable registers: x21~x28 */
dtb_paddr .req x21
boot_arg0 .req x22
boot_arg1 .req x23
boot_arg2 .req x24
stack_top .req x25


_start:
/*
 * Boot CPU general-purpose register settings:
 *   x0 = physical address of device tree blob (dtb) in system RAM.
 *   x1 = 0 (reserved for future use)
 *   x2 = 0 (reserved for future use)
 *   x3 = 0 (reserved for future use)
 */
    mov     dtb_paddr, x0
    mov     boot_arg0, x1
    mov     boot_arg1, x2
    mov     boot_arg2, x3

    /* Save cpu stack */
    get_phy stack_top, .boot_cpu_stack_top
    /* Save cpu id temp */
#ifdef ARCH_USING_HW_THREAD_SELF
    msr     tpidrro_el0, xzr
    /* Save thread self */
#endif /* ARCH_USING_HW_THREAD_SELF */
    msr     tpidr_el1, xzr

    bl      init_cpu_el
    bl      init_kernel_bss
    bl      init_cpu_stack_early

#ifdef RT_USING_OFW
    /* Save devicetree info */
    mov     x0, dtb_paddr
    bl      rt_hw_fdt_install_early
#endif

    /* Now we are in the end of boot cpu process */
    ldr     x8, =rtthread_startup
    b       init_mmu_early

• 首先通过mov dtb_paddr, x0将设备树的物理地址从x0中取出（由uboot放入x0中）放入dtb_paddr中，由dtb_paddr .req x21可知dtb_paddr 是寄存器x21的别名，同理，x1-x3中的值会被放入x23-x24中。
• 再通过get_phy stack_top, .boot_cpu_stack_top将CPU得栈顶地址保存在X25中
• 再将tpidr_el1&&tpidrro_el0清0
• 执行cpu的一些初始化，如init_cpu_el是对el3的一下初始化，init_kernel_bss将bss段清0，init_cpu_stack_early初始化CPU栈
• 通过mov x0, dtb_paddr将设备树的物理地址放入x0寄存器
• 在rt_hw_fdt_install_early将设备树的地址，size信息存放在全局变量中
• 将rtthread_startup的地址存入x8寄存器中后跳转到init_mmu_early

step2

我们进入init_mmu_early中查看：

1
2
3
4
5
6
7
8
9
10
11
12
13

init_mmu_early:
    get_phy x0, .early_page_array
    bl      set_free_page

    get_phy x0, .early_tbl0_page
    get_phy x1, .early_tbl1_page

    get_pvoff x2 x3
    ldr     x2, =ARCH_EARLY_MAP_SIZE    /* Map 1G memory for kernel space */
    bl      rt_hw_mem_setup_early

    b       enable_mmu_early

1. 首先获得了early_page_array的物理地址，通过源码可知，early_page_array是预留出来的一片24*4096的地址空间：

   1 2	.early_page_array: .space 24 * ARCH_PAGE_SIZE

   再通过 bl set_free_page将这个地址存入全局变量__init_page_array中：

   1 2 3 4

   void set_free_page(void *page_array) { __init_page_array = page_array; }

2. 将early_tbl0_page early_tbl1_page存入x0,x1寄存器中。early_tbl0_page early_tbl1_page描述如下：

   1 2 3 4 5

   .early_tbl0_page: .space ARCH_PAGE_SIZE .early_tbl1_page: /* Map 4G -> 2M * 512 entries */ .space 4 * ARCH_PAGE_SIZE

3. 再通过get_pvoff x2 x3计算物理地址与虚拟地址的差值并存入x3寄存器：

   1 2 3 4 5

   .macro get_pvoff, tmp, out ldr \tmp, =.boot_cpu_stack_top get_phy \out, .boot_cpu_stack_top sub \out, \out, \tmp .endm

   该函数先将符号boot_cpu_stack_top的地址（在链接阶段已经确定是虚拟地址）存入tmp寄存器，再将boot_cpu_stack_top的物理地址存入out寄存器，最后相减存回out寄存器

4. 将ARCH_EARLY_MAP_SIZE的值存入x2寄存器

5. 跳转到rt_hw_mem_setup_early函数,此时x0-3寄存去的值分别为：

   • early_tbl0_page
   • early_tbl1_page
   • ARCH_EARLY_MAP_SIZE
   • pvoff

   将early_tbl0_page和early_tbl1_page映射为2M的页表,分别用于内核态和用户态，而early_tbl0_page和early_tbl0_page分别为内核态和用户态l0页表的首地址

6. 再跳转到enable_mmu_early函数中

step3

enable_mmu_early:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40

enable_mmu_early:
    get_phy x0, .early_tbl0_page
    get_phy x1, .early_tbl1_page

    msr     ttbr0_el1, x0
    msr     ttbr1_el1, x1
    dsb     sy

    bl      mmu_tcr_init

    /*
     * OK, now, we don't use sp before jump to kernel, set sp to current cpu's
     * stack top to visual address
     */
    get_pvoff x1 x0
    mov     x1, stack_top
    sub     x1, x1, x0
    mov     sp, x1

    ldr     x30, =kernel_start      /* Set LR to kernel_start function, it's virtual addresses */

    /* Enable page table translation */
    mrs     x1, sctlr_el1
    orr     x1, x1, #(1 << 12)      /* Stage 1 instruction access Cacheability control */
    orr     x1, x1, #(1 << 2)       /* Cacheable Normal memory in stage1 */
    orr     x1, x1, #(1 << 0)       /* MMU Enable */
    msr     sctlr_el1, x1

    dsb     ish
    isb

    ic      ialluis     /* Invalidate all instruction caches in Inner Shareable domain to Point of Unification */
    dsb     ish
    isb

    tlbi    vmalle1     /* Invalidate all stage 1 translations used at EL1 with the current VMID */
    dsb     ish
    isb

    ret

1. 再获得刚刚分配的页表的首地址给x0与x1并将地址存放在ttbr0_el1和ttbr1_el1中
2. 设置内存屏障
3. 跳转到mmu_tcr_init函数
4. 获取pv_off到x0中并将sp设置为cpu栈顶指针的虚拟地址
5. 将x30寄存器设置为kernel_start的地址
6. 设置sctlr_el1寄存器，启动mmu和缓存，并失效前面的所有缓存
7. 返回

返回后由于x30寄存器中存放的是kernel_start地址所以会跳转到kernel_start中执行

step4

1
2
3
4
5
6

kernel_start:
    /* jump to the PE's system entry */
    mov     x29, xzr
    mov     x30, x8
    br      x8

1. 将x29寄存器清0，再跳转到x8中执行。x8寄存器在step1中ldr x8, =rtthread_startup被存放了rtthread_startup的地址，所以会跳转到rtthread_startup中执行,接下来就是c的代码的阅读啦~

lwip

lwip协议栈内存管理

pbuf 结构体：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33

struct pbuf {
  /** next pbuf in singly linked pbuf chain */
  struct pbuf *next;

  /** pointer to the actual data in the buffer */
  void *payload;

  /**
   * total length of this buffer and all next buffers in chain
   * belonging to the same packet.
   *
   * For non-queue packet chains this is the invariant:
   * p->tot_len == p->len + (p->next? p->next->tot_len: 0)
   */
  u16_t tot_len;

  /** length of this buffer */
  u16_t len;

  /** pbuf_type as u8_t instead of enum to save space */
  u8_t /*pbuf_type*/ type;

  /** misc flags */
  u8_t flags;

  /**
   * the reference count always equals the number of pointers
   * that refer to this pbuf. This can be pointers from an application,
   * the stack itself, or pbuf->next pointers from a chain.
   */
  u16_t ref;
};

• next:链表
• payload： 存放网络数据包的
• len：可变空间大小
• tot_len：整个链表下一个节点之后的总长度大小
• type：4种pbuf类型
• ref：引用标志

AARCH64学习

参考

armv8基础知识

armv8中，执行发生在4个异常级别之一，在aarch64中，异常级别决定了特权级别，类似于armv7中定义的特权级别，异常级别决定特权级别，因此在Eln执行对于特权Pln。类似地，具有比另一个更大的n值的异常级别处于更高的异常级别，一个数字比另一个小的异常级别被描述为处于较低的异常级别。

• EL0 ：normal user app
• EL1：Operation system kernel typically described as privileged
• EL2：Hypervisor
• EL3：Low-level firmware，including the Secure Monitor

arm架构学习

工作模式

• User ：用户模式，一般在执行上层应用程序的时候处于该模式（和linux用户态和内核态无关）

• Fiq 快速中断模式

• IRQ：中断模式

• SVC：当复位或执行软中断指令后arm进入这种模式（例如刚上电或者软中断执行的时候处于该模式）

• Abort： 当产生存取异常时进入这种模式

• Undef： 当执行未定义的指令时ARM将进入这种模式

• System： 使用和User模式相同的寄存器集的特权模式

• Monitor：为了安全而拓展出的用于执行安全监控代码的模式

Linux驱动开发和裸机开发的区别**

1. 裸机开发：
   1. 底层，和寄存器打交道，有些MCU提供库
2. 驱动开发思维：
   1. 直接操纵寄存器不太现实
   2. 根据Linux下的各种驱动框架进行开发，一定要满足框架，也就是Linux各种驱动框架的掌握
   3. 驱动最终表现就是/dev/xxx文件。打开，关闭，读写。。。
   4. 现在新的内核支持设备树，这是一个.dts文件，此文件描述了板子的设备信息
3. Linux驱动开发分类：
   1. 字符设备驱动：最多的
   2. 块设备驱动：存储
   3. 网络设备驱动
      ==一个设备不一定只属于摸某一个类型==

系统移植

• Windows下使用OTG烧写系统
  1. 在Windows使用NXP提供的mfgtool来向开发板烧写系统，需要用先将开发板的USB_OTG链接到电脑上
  2. mfgtool工具是向板子先下载一个linux系统，然后通过系统完成烧写工作
• Ubuntu下通过脚本烧写系统
  1. 首先向SD卡烧写一个系统，然后使用SD卡启动，启动以后在Linux中执行烧写到EMMC或NAND中

Uboot

Uboot是一个裸机程序，比较复杂，就是一个bootloader。作用就是用于启动Linux或其他系统，Uboot最主要的工作就是初始化DDR（Linux的运行是运行在DDR里面的），一般linux镜像zimage（uimage）+设备树（.dtb）存放在SD，EMMC,NAND,SPI FLASH等等外置存储区域。

显示驱动

像素点

Rgb 三原色组成每个像素点，而分辨率就是像素点的个数，而argb则是增加了透明通道，

时间参数和时序

1. vsync：垂直同步信号，该信号的产生表示一帧新的信号产生
   1. 会产生一个开始信号，持续时间vspw
   2. vsync完成后需要持续一段时间，vbp
   3. vbp信号结束以后就是要显示的行数，显示完所有的行
   4. 显示完所有的行以后会有一段vfp延时
2. hsync：水平同步信号，该信号的产生表示一行新的数据开始显示
   1. 会产生一个开始信号，维持时间被叫做hspw
   2. hsync信号完成后需要一段时间延时，这段时间叫hbp
   3. 接着就是一行像素显示
   4. 一行像素显示完成以后到hsync下一行信号的产生之间的延时叫做hfp
   5. 真正显示一行所需的时间就是hspw+hbp+width+hfp

所以视频视频显示的逻辑是先发vspw开始信号->一段vbp延时（稳定需要？)-> n*（hspw行开始信号->hb屏信号->行像素显示信号->hfp作为到下一行开始信号的延时）->vfp作为到下一帧的信号延时。然后这些信号发送给ser 再通过des解码给屏幕

lp display

1
2
3
4
5
6
7
8
9
10
11
12

"vidoeTiming":{
                "visWidth":2560,  //一行2560个像素点 
                "hsyncFrontPorch":88, //水平同步信号的前肩时间 hfp
                "hsyncWidth":60, //水平同步脉冲宽度，触发行扫描的起始信号（要注意上拉还是下拉？） hspw
                "hsyncBackPorch":60, //水平同步信号后肩时间，完成行切换后的稳定时间 hbp
                "visHeight":1440, //一列1440个像素点
                "vsyncFrontPorch":32, //垂直同步前肩时间，帧缓冲切换前的空白时间 vfp
                "vsyncWidth":2, //垂直同步脉冲宽度，触发帧扫描的起始信号 vspw
                "vsyncBackPorch":20, //垂直同步信号后肩时间，完成帧切换后的稳定时间 vbp
                "pixelFreqInHz":248123520 //像素时钟频率，决定每秒传输的像素总数
            },

TODO:显存学习

serdes

串行器连接在外设中，将并行信号转换为串行信号，解串器将串行信号再解析为并行信号

个人理解

串行解串器的控制是同一个芯片控制还是串行器一个芯片，解串一个芯片，两个分别作为iic的子设备进行控制，主要有几个场景，比如：

1. cpu需要将画面显示到屏幕，就把数据发到串行器上，通过解串器输出到屏幕上（我们json中的应该是cpu-serdes-scr链路？？
2. 摄像头等画面直接通过serdes把画面输出到屏幕上，所以json里面有很多des？？

并行数据到串行数据的转换

1. 时钟数据恢复：将并行的像素数据流与时钟信号合并，并用一种叫做 时钟-数据恢复（CDR） 的机制生成同步的时钟信号，用于后续的串行数据传输。

2. 编码：将并行的数据进行编码转换。通常，为了提高信号的传输效率和抗干扰能力，会使用像 8b/10b 编码 或 10b/12b 编码 等方法。

   • 8b/10b 编码：这是一种常见的编码方案，能够将每 8 位数据转换为 10 位符号，增加冗余位以减少误码率。
   • 10b/12b 编码：这是一种用于高带宽数据传输的编码技术，将 10 位数据映射为 12 位编码，进一步提高信号的可靠性。

3. 串行化：将并行的数据进行串行化，TI 935 会把多个并行数据通道（例如 8 位、10 位或 12 位并行数据）按特定的时序顺序串联成一个单一的 串行数据流。这个串行数据流会通过 高速差分信号对（如 FPD-Link 3 协议中的差分对） 进行传输。具体地，TI 935 使用 FPD-Link 3 协议 中的高速串行链路来将这些并行数据转化为串行数据。FPD-Link 3 协议支持非常高的传输速率，能够有效传输 4.5 Gbps 或更高的速率。

4. 数据打包与封装：将编码后的串行数据通过一对或多对 差分信号对 传输到接收端（通常是解串器 TI 960）。FPD-Link 3 使用的差分信号对（如 LVDS 信号对）能够提供高速、低功耗的长距离传输，支持最大 15 米的传输距离（具体距离取决于数据速率和电缆质量）。

5. 时钟恢复与同步：不仅要将数据串行化，还需要通过 时钟数据恢复（CDR） 技术来保持数据和时钟的同步。这是因为，在串行化数据时，时钟信号被嵌入到数据流中，并通过差分信号传输。在接收端（解串器 TI 960）会从串行信号中恢复出时钟信号，并重新同步数据流。

传输协议

DSI

mipi dsi controller

The APB-to-Generic block bridges the APB operations into FIFOs holding the Generic commands. The block interfaces with the following FIFO: Command FIFO, Write payload FIFO, Read payload FIFO.

上面的架构无非就是体现两件事：

1. dsi命令通过apb interface发出
2. 视频数据通过dpi interface发出

Generic interface packets are always transported using one of the DSI transmission modes; Video mode or Command mode. If neither of these mode are selected, the packets are not transmitted through the link and the released FIFOs eventually get overflowed.

通用接口数据包总是使用DSI传输模式之一进行传输；视频模式或命令模式。如果不选择这两种模式，则数据包不会通过链路传输，并且释放的fifo最终会溢出。

dpi interface

The DPI interface follows the MIPI DPI specification with pixel data bus width up to 24 bits. It is used to transmit the information in Video mode in which the transfers from the host processor to the peripheral take the form of a real-time pixel stream. This interface allows sending ShutDown (SD) and ColorMode (CM) commands, which are triggered directly by writing to the register of VO_CON[9:8] in the GRF Module. To transfer additional commands(for example, to initialize the display), use another interface such as APB Slave Generic Interface to complement the DPI interface.

The DPI interface can be configured to increase flexibility and promote correct usage of this interface for several systems. These configuration options are as follows:Polarity control: All the control signals are programmable to change the polarity depending on system requirements.

==After the MIPI DSI HOST Controller reset, DPI waits for the first VSYNC active transition to start signal sampling, including pixel data, and preventing image transmission in the middle of a frame.==

If interface pixel color coding is 18 bits and the 18-bit loosely packed stream is disabled, the number of lines programmed in the pixels per lines configuration is a multiple of four. This means that in this mode, the two LSBs in the configuration are always inferred as zero. The specification states that in this mode, the pixel line size should be a multiple of four.

DPl接口遵循MIPI DPI规范，像素数据总线宽度高达24位。它用于以视频方式传输信息，其中从主机处理器到外设的传输采用实时像素流的形式。该接口允许发送ShutDown （SD）和ColorMode （CM）命令，这些命令通过写入GRF模块中的VO_CON[9:8]寄存器直接触发。要传输额外的命令（例如，初始化显示），可以使用其他接口（如APB Slave Generic interface）来补充DPI接口。可以配置DPI接口以增加灵活性，并促进多个系统正确使用该接口。极性控制：所有的控制信号都是可编程的，可以根据系统设备改变极性。在MIPI DSI主机控制器复位后，DPI等待第一个VSYNC主动转换到一个帧。

==如果接口像素颜色编码为18位，并且禁用了18位松散打包流，则在每行像素配置中编程的行数是4的倍数。这意味着在这种模式下，配置中的两个lsb总是被推断为零。规格规定，在此模式下，像素线尺寸应为4的倍数。==

DPI 功能说明

“The DPI interface follows the MIPI DPI specification with pixel data bus width up to 24 bits.
It is used to transmit the information in Video mode in which the transfers from the host processor to the peripheral take the form of a real-time pixel stream. This interface allows sending ShutDown (SD) and ColorMode (CM) commands, which are triggered directly by writing to the register of VO_CON[9:8] in the GRF Module. To transfer additional commands(for example, to initialize the display), use another interface such as APB Slave Generic Interface to complement the DPI interface.”

总结：

• DPI 遵循 MIPI DPI 规范，总线宽度可达 24bit。
• 主要用于 Video Mode 下的实时像素流传输。
• 支持少量命令（SD/CM），通过 GRF VO_CON[9:8] 触发。
• 初始化或更多命令需通过 APB Slave Generic Interface。

原文引用 2：DPI 信号与像素编码

“The DPI interface captures the data and control signals and conveys them to the FIFO interfaces that transmit them to the DSI link. Two different streams of data are presented at the interface; video control signals and pixel data. Depending on the interface color coding, the pixel data is disposed differently throughout the dpipixdata bus. The following table shows the Interface pixel color coding.”

总结：

• DPI 捕获两类信号：视频控制信号 和 像素数据。
• 像素数据在总线上的排列取决于 Interface Pixel Color Coding 配置。
• 文档提供了 16/18/24bit 不同配置下的 R/G/B 位映射表。

原文引用 3：18-bit loosely packed 限制

“If interface pixel color coding is 18 bits and the 18-bit loosely packed stream is disabled, the number of lines programmed in the pixels per lines configuration is a multiple of four. This means that in this mode, the two LSBs in the configuration are always inferred as zero.”

总结：

• 当 18-bit loosely packed 禁用时：
  1. “pixels per line” 必须是 4 的倍数。
  2. 配置中的 两位最低有效位被自动置为 0。
• 目的是保证像素数据对齐，避免总线或 PHY 传输错误。

原文引用 4：DPI 配置选项

“These configuration options are as follows: Polarity control: All the control signals are programmable to change the polarity depending on system requirements. After the MIPI DSI HOST Controller reset, DPI waits for the first VSYNC active transition to start signal sampling, including pixel data, and preventing image transmission in the middle of a frame.”

总结：

• Polarity control：控制信号极性可编程。
• VSYNC 对齐：DPI 等待第一个 VSYNC 激活信号再开始采样像素，避免中途传输导致画面错位。

💡 整体理解：

1. DPI 接口主要处理 Video Mode 的像素传输 + 少量 SD/CM 命令。
2. 初始化或其他控制命令需要 通过 APB Generic Interface。
3. 像素数据编码和行数必须遵循规范，保证数据总线和 PHY 传输正确。
4. 控制信号极性可调，VSYNC 保证帧同步。

APB Slave Generic Interface

The MIPI DSI HOST Controller supports the transmission or write and read command mode packets as described in the DSI specification. These packets are built using the APB register access. The GEN_PLD_DATA register has two distinct functions based on the operation. Writing to this register sends the data as payload when sending a Command mode packet. Reading this register returns the payload of a read back operation. The GEN_HDR register contains the Command mode packet header type and header data. Writing to this register triggers the transmission of the packet implying that for a long Command mode packet, the packet’s payload needs to be written in advance in the GEN_PLD_DATA register.

APB Slave Interface 与 Command Mode

The APB Slave interface allows the transmission of generic information in Command mode, and follows the proprietary register interface. Commands sent through this interface are not constrained to comply with the DCS specification, and can include generic commands described in the DSI specification as manufacturer-specific.

• APB Slave 接口：用于通过寄存器访问发送 Generic packet（通用命令）或 DCS 命令。
• Command Mode：通过这个接口发送的数据是按需发送，不是持续的视频流。
• Generic Packet：不必符合 DCS 标准，可以是厂商自定义的命令。
• 用途：用来发送控制屏幕的命令，比如初始化、参数设置或者写内存。

2️⃣ GEN_HDR 与 GEN_PLD_DATA

The GEN_PLD_DATA register has two distinct functions based on the operation. Writing to this register sends the data as payload when sending a Command mode packet. Reading this register returns the payload of a read back operation. The GEN_HDR register contains the Command mode packet header type and header data. Writing to this register triggers the transmission of the packet implying that for a long Command mode packet, the packet’s payload needs to be written in advance in the GEN_PLD_DATA register.

• GEN_PLD_DATA（Payload Data）
  • 写入：作为 Command Mode 包的 payload
  • 读取：返回读回操作的 payload
• GEN_HDR（Header）
  • 写入 header 会触发命令包发送
  • 对于 长命令包（Long Packet）：payload 必须先写入 GEN_PLD_DATA，然后再写 header 发出包

总结：

1. 写 payload → 写 header → 控制器开始发送
2. FIFO 机制：payload FIFO + command FIFO

3️⃣ 支持的包类型

文档列出了很多可通过 Generic Interface 发送的包，包括：

• Generic Write Short / Long Packet（0-2 参数）
• DCS Write Short / Long Packet
• Read Packet 配置

理解：

• Short Packet 用于简单命令（如设置寄存器）
• Long Packet 用于数据量大的命令（如写显存、Write Memory Start / Continue）

4️⃣ Transmission Mode 的关系

Generic interface packets are always transported using one of the DSI transmission modes; Video mode or Command mode. If neither of these mode are selected, the packets are not transmitted through the link and the released FIFOs eventually get overflowed.

• 任何 Generic 包都必须通过 DSI 传输模式发送
• Video Mode / Command Mode 都可以发送 Generic 包
• 如果都没选：FIFO 写入的数据不会被发送 → FIFO 最终溢出

结论：MODE_CFG 决定控制器整体传输方式，但命令包本身不需要每条切换模式。

5️⃣ APB 接口速率限制

The transfer of packets through the APB bus is based on the following conditions:
The APB protocol defines that the write and read procedure takes two clock cycles each to be executed. This means that the maximum input data rate through the APB interfaces is always half the speed of the APB clock.

• APB 写/读需要 2 个时钟周期 → 最大输入速率 = APB 时钟的一半
• 总线宽度：32 bit → payload 数据以 32bit 总线写入

The DSI link bit rate when using solely APB is equal to (APB clock frequency) *16 Mbps.

• 如果只通过 APB 发送命令包，DSI link 速率 = APB 时钟 * 16 Mbps
• 带宽与 APB 时钟频率成正比

6️⃣ 高带宽命令模式

To drive the APB interface to achieve high bandwidth Command mode traffic transported by the DSI link, the MIPI DSI HOST Controller should operate in the Command mode only and the APB interface should be the only data source that is currently in use.

• 如果要让 Command Mode 最大化带宽：
  1. 控制器保持 Command Mode（不输出视频）
  2. APB 接口是唯一数据源
• 这样 APB 拥有整个 DSI link 带宽，不与 Video Mode 或其他输入共享

7️⃣ 写内存命令（Memory Write Commands）

The memory write commands require maximum throughput from the APB interface, because they contain the most amount of data conveyed by the DSI link. While writing the packet information, first write the payload of a given packet into the payload FIFO using the GEN_PLD_DATA register. When the payload data is for the command parameters, place the first byte to be transmitted in the least significant byte position of the APB data bus. After writing the payload, write the packet header into the command FIFO.

• Memory Write Commands（长数据命令）：payload 很大，需要 APB 最大带宽
• 写包顺序：
  1. 先写 payload 到 GEN_PLD_DATA FIFO
  2. 再写 header 到 GEN_HDR → 触发发送
• 字节顺序：第一个要发的字节写在 APB 总线 LSB

The DCS long packets are encapsulated in a DSI packet. The DSI included in the diagrams.In the follow figures, the Write Memory Command can be replaced by the DCS command Write Memory Start and Write Memory Continue.

• DCS 长包会被封装成 DSI 包
• Write Memory Start / Continue 是典型长包命令，用于写显存 / Framebuffer

✅ 总结核心要点

1. APB Interface
   • 用于 Command Mode / Generic Packet
   • 写 GEN_PLD_DATA → 写 GEN_HDR → 发送
   • 支持短包 / 长包 / DCS / Generic
2. 模式选择（MODE_CFG）
   • Video Mode：连续像素流 + 少量包
   • Command Mode：仅发送命令包，带宽最大
3. 高带宽 Command Mode
   • 控制器保持 Command Mode
   • APB 接口独占 → 最大化发送速率
4. 内存写 / 长包命令
   • payload FIFO 先写数据
   • header 写入触发发送
   • 注意字节顺序（LSB → 总线）

Transmission of Commands in Video Mode

1. 垂直方向（帧级）

   在一帧里，垂直方向的时序顺序是：

1
2
3
4
5
6
7
8
9
10
11

VSS（Vertical Sync Start / VSA开始）  
   ↓
VSA（Vertical Sync Active / VSYNC脉冲持续时间）
   ↓
VBP（Vertical Back Porch / 垂直后沿）  
   ↓
Active Lines（有效显示行，即每行有 HSS/HSE + Pixel Data）  
   ↓
VFP（Vertical Front Porch / 垂直前沿）  
   ↓
下一帧 VSS

• VSS：帧开始标记，协议短包
• VSA：VSYNC脉冲持续的行数。 – vspw
• VBP：VSYNC结束到有效显示区域开始的空闲行数
• Active Lines：真正显示内容的行
• VFP：有效显示行结束到下一帧 VSS 的空闲行数

2. 水平方向（行级）

   每一行的水平时序是：

1
2
3
4
5
6
7
8
9
10

  HSS（Horizontal Sync Start / HSA开始）  
   ↓
HSA（水平同步脉冲宽度，对应HSPW）  
   ↓
HBP（水平后沿 / 后沿空闲周期）  
   ↓
Active Pixels（有效像素数据）  
   ↓
HFP（水平前沿 / 前沿空闲周期）  
下一行 HSS

• HSS：行开始短包
• HSA：水平同步脉冲对应的时间段 – hspw
• HBP：脉冲结束到有效像素开始的延时
• Active Pixels：真正显示的像素
• HFP：有效像素结束到下一行 HSS 的间隔

dsi屏端配置

ARM裸机

汇编LED驱动实验

汇编LED原理分析

1. ALPHA开发板LED灯硬件原理分析
   stm32初始化流程：
   1. 使能GPIO时钟
   2. 设置IO复用，将其复用为GPIO
   3. 配置GPIO 的电器属性
   4. 使用GPIO输出高低电频

I.MAX6ULL IO初始化流程

1. 使能时钟 CCGR0-CCGRU这7个寄存器控制着6ULL所有时钟的使能，为了简单，设置CCGR0-CCGR6这7个寄存器全部设置为0XFFFFFFF,相当于使能所有外设时钟
2. IO复用，将寄存器IOMUXC_SW_MUX_CTL_PAD_GPIO1_IO03的比特设置为0101=5，这样GPIO1_IO03就复用为GPIO 。
3. 寄存器IOMUXC_SW_PAD_CTL_PAD_GPIO1_IO03 是设置GPIO1_IO03的电气属性，包括压摆率。速度，驱动能力，开漏，上下拉
4. 配置GPIO功能，设置输入输出，设置GPIO1_GDIR寄存器bit3为1，也就是设置为输出模式，设置GPIO1_DR寄存器的bits3，为1表示输出高电平，为0表示输出低电平