📚 课程目录第1章课程导论与背景

1. 课程导论与背景：为什么需要从3.x移植到5.x？内核版本演进的关键差异概述

1.1 移植的驱动力：为什么必须升级？

嵌入式Linux内核从3.x时代演进到5.x，不仅仅是版本号的跳跃，更是内核架构、驱动模型和开发范式的根本性变革。对于嵌入式产品而言，长期停留在3.x内核意味着技术债务的持续累积和产品竞争力的下降。以下是驱动移植的核心驱动力：

安全漏洞与长期支持（LTS）终止： 3.x系列内核（如3.10、3.18）的LTS周期早已结束，不再接收关键安全补丁。5.x内核（如5.4、5.10、5.15）作为新的LTS版本，提供长达6年以上的安全维护。
硬件生态支持： 新的SoC、外设（如MIPI CSI/DSI、USB 3.2 Gen2、PCIe Gen4）和无线协议（WiFi 6/6E、Bluetooth 5.2）的驱动框架仅在4.x/5.x中完整支持。3.x内核缺乏对这些新硬件的原生驱动支持。
实时性与性能优化： 5.x内核引入了可抢占内核（PREEMPT_RT）的深度整合、BPF（Berkeley Packet Filter）性能追踪、以及I/O调度器（BFQ/MQ-Deadline）的改进，显著提升了嵌入式系统的实时响应和吞吐量。
维护成本与社区资源： 社区和芯片厂商（如NXP、TI、Rockchip）的BSP（板级支持包）已全面转向5.x主线。继续使用3.x意味着需要自行向后移植大量补丁，维护成本呈指数级增长。

行业现状： 截至2025年，主流嵌入式Linux发行版（如Yocto Project的Kirkstone、Dunfell）均基于5.x内核。新项目建议直接基于5.10或5.15 LTS版本启动，避免从3.x起步。

1.2 内核版本演进的关键差异：从3.x到5.x的架构变迁

从3.x到5.x，内核在设备模型、硬件描述和驱动API三个维度发生了根本性变化。理解这些差异是成功移植的前提。

1.2.1 设备模型：从“平台设备硬编码”到“设备树（DT）驱动”

3.x时代，许多嵌入式驱动依赖板级文件（board-*.c）硬编码平台设备和资源。5.x内核强制要求使用设备树（Device Tree, DT）描述硬件，驱动通过匹配表（of_match_table）与设备树节点绑定。

1.2.2 关键API与框架差异

驱动开发者需要重点关注以下API层面的变化，这些是移植过程中最常见的“断点”。

模块/框架	3.x 内核（旧API）	5.x 内核（新API）	移植要点
时钟框架	`clk_get()` + `clk_enable()`	`clk_get()` + `clk_prepare_enable()`	新增prepare/unprepare语义，需拆分或使用组合函数
GPIO子系统	`gpio_request()` + `gpio_direction_output()`	`gpiod_get()` + `gpiod_direction_output()`	基于描述符（descriptor）的API，不再使用整数GPIO号
中断子系统	`request_irq()` + `set_irq_type()`	`devm_request_irq()` + `irq_set_irq_type()`	推荐使用devm_系列资源管理API，简化错误处理
DMA引擎	`dma_request_channel()`	`dma_request_chan()`	新API支持设备树DMA绑定，通道匹配更灵活
PWM框架	`pwm_request()` + `pwm_config()`	`pwm_get()` + `pwm_apply_state()`	引入pwm_state结构体，配置参数统一管理
Regulator框架	`regulator_get()` + `regulator_enable()`	`devm_regulator_get()` + `regulator_enable()`	推荐使用devm版本，增加电压约束检查

  核心原则： 5.x内核全面推行 Managed Device Resources (devm_*) 机制。驱动开发者应优先使用 devm_ 系列API，内核会自动处理资源释放，显著减少内存泄漏和悬挂指针风险。

1.2.3 内核配置与构建系统变化

从3.x到5.x，Kconfig和Makefile的语法基本保持向后兼容，但引入了新的配置选项和构建机制：

编译目标： 3.x常用 make uImage，5.x推荐使用 make zImage 或 make Image.gz（ARM64）。
设备树编译： 3.x需手动调用 dtc 编译，5.x通过 make dtbs 自动编译所有设备树。
模块签名： 5.x引入了 模块签名（MODULE_SIG） 和 锁定（Lockdown） 功能，驱动模块需要签名才能加载到启用安全启动的内核中。
GCC版本要求： 5.x内核要求GCC 5.1+，推荐使用GCC 9.x或Clang 12+。3.x内核通常使用GCC 4.9。

1.3 移植工作的范围与挑战

一个典型的从3.x到5.x的驱动移植项目，通常涉及以下四个层面的工作：

设备树化（DT-ification）： 将板级文件中的硬件资源描述（寄存器地址、中断号、时钟、GPIO）转换为设备树节点。
API适配（API Adaptation）： 替换废弃的API调用，适配新的框架接口（如GPIO描述符、时钟prepare/enable）。
内核机制适配： 处理内核调度、内存管理、并发锁机制的变化（如 spin_lock 变更为 raw_spin_lock 在RT场景下）。
功能验证与回归测试： 确保移植后的驱动在5.x内核上功能正确，性能不下降。

常见陷阱： 不要直接复制3.x驱动的 platform_data 结构体到5.x驱动中。5.x驱动应通过 device_property_read_u32() 等通用属性API从设备树读取参数，而不是依赖自定义的 platform_data 结构体。这会导致驱动无法与设备树解耦。

1.4 课程路线图：从理论到实战

本课程将按照以下路径，带领学员完成从3.x到5.x的完整驱动移植：

通过本课程的学习，你将掌握一套系统化的移植方法论，能够独立将3.x时代的遗留驱动平滑迁移到5.x内核主线，并充分利用新内核带来的性能提升和安全特性。