StudyWinter的博客

"U-Boot" 是 "Universal Bootloader" 的简称，是一个广泛使用的开源引导程序，主要用于嵌入式系统。U-Boot 的主要功能是在设备启动时初始化硬件、加载操作系统内核并将控制权移交给内核。它支持多种处理器架构和硬件平台，因此在嵌入式设备、单板计算机、路由器等多种设备中得到了广泛应用。U-Boot 允许用户通过命令行界面执行各种任务，如修改引导参数、调试硬件问题、从网络或存储设备加载操作系统镜像等。这种灵活性使得 U-Boot 成为嵌入式开发中的一个重要工具。

ARM 架构支持一级页表映射，也就是说 MMU 根据 CPU 发来的虚拟地址可以找到第 1 个页表，从第 1 个页表里就可以知道这个虚拟地址对应的物理地址。一级页表里地址映射的最小单位是 1M。ARM 架构还支持二级页表映射，也就是说 MMU 根据 CPU 发来的虚拟地址先找到第 1 个页表，从第 1 个页表里就可以知道第 2 级页表在哪里；再取出第 2级页表，从第 2 个页表里才能确定这个虚拟地址对应的物理地址。二级页表地址映射的最小单位有 4K、 1K， Linux 使用 4K。

值得注意的是，上面 2个红线部分都属于 APP1 的“上下文”，或者这样说：红线所涉及的代码，都是 APP1调用的。但是按键的中断服务程序，不属于 APP1的“上下文”，这是突如其来的，当中断发生时， APP1正在休眠呢。当 APP1 再次运行时，就会继续执行 drv_read 中剩下的代码，把数据复制回用户空间，返回用户空间。在中断的处理过程中，也就是 gpio_key_irq 的执行过程中，它不能休眠：“中断”怎么能休眠？在 APP1的“上下文”，也就是在 APP1的执行过程中，它是可以休眠的。

以前用 work 来线程化地处理中断，一个 worker 线程只能由一个 CPU 执行，多个中断的 work 都由同一个 worker 线程来处理，在单 CPU 系统中也只能忍着了。而这些线程，之间是互相独立的，“同时运行”，也就是说：每一个线程，都有自己的栈。在中断的处理过程中，该 CPU 是不能进行进程调度的，所以中断的处理要越快越好，尽早让其他中断能被处理──进程调度靠定时器中断来实现。可以，但是开销太大：读按键的程序，要把按键通知播放音乐的程序，进程间通信的效率没那么高。

中断：在主程序运行过程中，出现了特定的中断触发条件（中断源），使得CPU暂停当前正在运行的程序，转而去处理中断程序，处理完成后又返回原来被暂停的位置继续运行。中断嵌套：当一个中断程序正在运行时，又有新的更高优先级的中断源申请中断，CPU再次暂停当前中断程序，转而去处理新的中断程序，处理完成后依次进行返回。中断优先级：当有多个中断源同时申请中断时，CPU会根据中断源的轻重缓急进行裁决，优先响应更加紧急的中断源。后面的 3 种方式，都需要“小孩来中断妈妈”：中断她的睡眠、中断她的工作。

前面的学习，我们使用直接操作寄存器的方法编写驱动。这只是为了让大家掌握驱动程序的本质，在实际开发过程中我们可不这样做，太低效了！如果驱动开发都是这样去查找寄存器，那我们就变成“寄存器工程师”了，即使是做单片机的都不执着于裸写寄存器了。Linux 下针对引脚有 2 个重要的子系统： GPIO、 Pinctrl。

button_operations 结 构 体 中 有 init 函 数 指 针 ， 它 指 向board_stm32mp157_button_init 函数，在里面将会初始化 LED 引脚：使能、设置为 GPIO 模式、设置为输出引脚。该寄存器共32位，涉及16个GPIO，每个GPIO对应 2 位。button_operations 结 构 体 中 还 有 有 read 函 数 指 针 ， 它 指 向board_stm32mp157_button_read 函数，在里面将会读取并返回按键引脚的电平。

合并 LED 、 BUTTON 框 架 驱 动 程 序 ：01_led_drv_template 、01_button_drv_template，合并为：gpio_drv_template

这样的结构易于扩展，对于不同的单板，只需要替换 board_xxx.c 提供自己的 button_operations 结构体即可。register_button_operations 函 数代码如下，它还根据底层提供button_operations 调用 device_create，这是创建设备节点。上层是 button_drv.c，它的核心是 file_operations 结构体，首先看看入口函数，代码如下。按键被按下后，上图中左边的 GPIO 电平为低，右边的 GPIO 电平为高。

在做单片机开发时，要读取GPIO按键，通常是执行一个循环，不断地检测GPIO引脚电平有没有发生变化。。这 4 种方法并不仅仅用于 GPIO 按键，在所有的APP 调用驱动程序过程中，都是使用这些方法。通过这 4 种方式的学习，可以掌握如下知识：① 驱动的基本技能：中断、休眠、唤醒、 poll 等机制。这些基本技能是驱动开发的基础，其他大型驱动复杂的地方是它的框架及设计思想，但是基本技术就这些。② APP 开发的基本技能：阻塞 、非阻塞、休眠、 poll、异步通知。

一步步由简单到框架。

韦东山嵌入式linux系列-LED 模板驱动程序的改造：设备树-具体单板stm32mp157的驱动程序

① dts 在PC机上被编译为 dtb 文件；② u-boot 把dtb文件传给内核；③ 内核解析dtb文件，把每一个节点都转换为 device_node 结构体；④ 对于某些 device_node 结构体，会被转换为 platform_device 结构体。

在内核中，使用同一个芯片的板子，它们所用的外设资源不一样，比如A板用 GPIO A， B 板用 GPIO B。而 GPIO 的驱动程序既支持 GPIO A 也支持GPIO B，你需要指定使用哪一个引脚，怎么指定？比如 LED 驱动，在内核的驱动程序里去操作寄存器，但是操作哪一个引脚？请想想，要操作硬件就需要去操作复杂的寄存器，如果设备树可以操作寄存器，那么它就是“驱动”，它就一样很复杂。设备树并不是重新发明出来的，在 Linux 内核中其他平台如 PowerPC，早就使用设备树来描述硬件了。

p_led_opr这个指针是由底层芯片相关的(chip_demo_gpio.c)代码提供的，其中chip_demo_gpio.c这里面有led_operations结构体，结构体中有init/ctl函数。应用程序调用open/write等函数最简单的方法时驱动层也提供对应的drv_open/drv_write，应用程序调用read/write，驱动层也提供对应的drv_open/drv_write等等，需要写出驱动层的函数。platform_driver有name，和platform_device匹配；

③ 进入 platform_device_register/platform_driver_register 内部，分析 dev 和 drv 的匹配过程。有一个platform device，里面有resource，resource指向一个数组，里面定义了设备的资源，平台设备指定资源。（1）搜索 platform_device_register，随便找一个文件，找有全局变量的。（4）继续搜索它的platform_driver，按名称搜索（orion_nand）（2）点进去，在这个文件中可以看到注册。

应用程序调用open等函数最简单的方法是驱动层也提供对应的drv_open，应用程序调用read，驱动层也提供对应的drv_read等等。需要写出驱动层的函数，为了便于管理，将这些函数放到file_operations结构体中，即第一步定义对应的file_operations结构体，并实现对应的open等程序（第一步）；实现完成之后，将file_operations结构体通过register_chrdev注册到内核（第二步）；然后通过入口函数调用注册函数（chrdev），安装驱动程序的时候，内核会调用入口函

比如 board_A.c 使用芯片 chipY，那就可以写出： chipY_gpio.c，它实现芯片 Y 的 GPIO 操作，适用于芯片 Y 的所有 GPIO 引脚。以面向对象的思想，在 board_A_led.c 中实现 led_resouce 结构体，它定义“资源”──要用哪一个引脚。在 chipY_gpio.c 中仍是实现 led_operations 结构体，它要写得更完善，支持所有 GPIO。a) 有方向寄存器 DIR、数据寄存器DR等，基础地址是addr_base_addr_gpio1。

1怎么写 LED 驱动程序？详细步骤如下：① 看原理图确定引脚，确定引脚输出什么电平才能点亮/熄灭 LED② 看主芯片手册，确定寄存器操作方法：哪些寄存器？哪些位？地址是？③ 编写驱动：先写框架，再写硬件操作的代码注意：在芯片手册中确定的寄存器地址被称为物理地址，在 Linux 内核中无法直接使用。

这是第五篇第5章的课后作业，尝试实现实现读 LED 状态的功能：涉及 APP 和驱动。