2. Linux 内核源码获取与版本管理
在全志 T113 平台进行外设驱动移植时，内核源码的获取与版本管理是基础性工作。不同内核版本（如 Linux 4.9、5.4、5.10、6.1 LTS）在 API、设备树绑定、驱动框架上存在差异，因此需要一套规范的版本管理策略。本章将围绕 Git 仓库克隆、版本标签选择、分支管理策略以及补丁文件管理四个核心环节展开。
实践建议：全志 T113 官方 SDK 通常基于 Linux 4.9 或 5.4 内核。若需移植到更新的 LTS 版本（如 5.10 或 6.1），建议先通过 Git 标签（tag）定位目标版本，再基于该标签创建本地开发分支。
2.1 Git 仓库克隆与远程源配置
Linux 内核官方源码托管在 git.kernel.org 及 GitHub 镜像上。对于全志 T113 开发，通常需要同时拉取官方主线仓库和全志（或第三方 SoC 厂商）的维护仓库。
2.1.1 克隆官方主线仓库
# 克隆完整内核仓库（含全部历史，体积较大）
git clone https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
cd linux
# 查看所有远程源
git remote -v
# 添加全志 T113 相关仓库作为第二个远程源（示例）
git remote add allwinner https://github.com/allwinner-zh/linux.git
git fetch allwinner2.1.2 浅克隆与稀疏检出（节省空间）
若仅需特定版本或特定架构代码，可使用浅克隆（--depth）与稀疏检出（sparse-checkout）加速下载。
# 浅克隆：只获取最近 1 次提交
git clone --depth 1 --branch v5.10 https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git
# 稀疏检出：只拉取 arch/arm 和 drivers 目录
git sparse-checkout init --cone
git sparse-checkout set arch/arm drivers
关键点：全志 T113 使用 ARM Cortex-A7 架构，因此
arch/arm 目录下的 mach-sunxi 和 plat-sunxi 是平台相关代码的核心区域。
2.2 内核版本标签选择策略
Linux 内核版本号遵循 主版本.次版本.修订版 格式，LTS（长期支持）版本通常维护 2~6 年。全志 T113 驱动移植应优先选择 LTS 版本，以获得长期安全更新和社区支持。
| 版本标签示例 | 类型 | 全志 T113 适配建议 |
|---|---|---|
v4.9 |
LTS（已 EOL） | 官方 SDK 默认版本，驱动成熟但 API 较旧 |
v5.4 |
LTS（维护中） | 推荐迁移目标，设备树与驱动框架稳定 |
v5.10 |
LTS（维护中） | 支持较新外设驱动，需注意 GPIO/时钟 API 变更 |
v6.1 |
LTS（最新） | 社区活跃，但部分全志私有驱动需重写 |
2.2.1 标签查看与切换
# 列出所有可用标签（按版本排序）
git tag -l "v5.4.*" --sort=-version:refname
# 切换到指定标签（分离头指针状态）
git checkout v5.4.280
# 基于标签创建本地开发分支（推荐做法）
git checkout -b t113-v5.4-dev v5.4.280
注意：直接
git checkout 标签会进入“分离头指针”状态，在此状态下提交的修改在切换分支后可能丢失。务必先基于标签创建分支再进行开发。
2.3 分支管理策略
在驱动移植项目中，建议采用“上游跟踪 + 本地特性分支 + 补丁队列”的分支模型，避免直接修改主线分支。
2.3.1 推荐分支结构
# 创建上游跟踪分支（只读，用于同步主线更新）
git branch upstream-v5.4 v5.4.280
# 创建本地开发分支（基于上游标签）
git branch t113-spi-v5.4 v5.4.280
git branch t113-i2c-v5.4 v5.4.280
# 创建集成测试分支（合并多个驱动分支）
git branch t113-integration-v5.4 v5.4.2802.3.2 分支管理流程
- 上游同步：定期从
v5.4.x标签拉取安全更新，合并到upstream-v5.4分支。 - 驱动开发：每个外设驱动（SPI、I2C、PWM 等）在独立特性分支上开发，保持提交粒度清晰。
- 集成测试：将多个特性分支合并到
t113-integration分支，解决冲突后进行全量测试。 - 补丁导出：从集成分支生成补丁文件，用于版本管理或提交上游。
分支命名规范：
平台-驱动名-内核版本，例如 t113-spi-v5.4、t113-mmc-v6.1。避免使用无意义名称如 dev1、test。
2.4 补丁文件管理
在全志 T113 驱动移植中，补丁文件（patch）是跨版本迁移的核心载体。通过 git format-patch 生成补丁，使用 git am 或 patch 命令应用补丁。
2.4.1 生成补丁
# 基于当前分支与基准标签的差异生成补丁
git format-patch v5.4.280 --stdout > t113-spi-v5.4.patch
# 按提交粒度生成多个补丁文件
git format-patch v5.4.280 -o patches/spi/2.4.2 应用补丁
# 使用 git am 应用补丁（保留提交信息）
git checkout v5.10.200
git am < t113-spi-v5.4.patch
# 使用 patch 命令直接应用（不保留提交信息）
patch -p1 < t113-spi-v5.4.patch2.4.3 补丁冲突处理
当补丁在新内核版本上应用失败时，需手动解决冲突。常见冲突原因包括：
- API 变更：如
gpio_request改为gpiod_get，需重写驱动调用逻辑。 - 设备树绑定变化：如
compatible字符串格式调整，需同步修改 DTS 文件。 - 头文件路径迁移：如
#include <linux/gpio.h>改为#include <linux/gpio/consumer.h>。
冲突解决技巧：使用
git mergetool 可视化解决冲突；或手动编辑冲突文件后执行 git add + git am --continue。
2.5 内核版本管理流程总览
2.6 补丁文件组织规范
为便于跨版本管理和团队协作，建议按以下目录结构组织补丁文件：
patches/
├── t113-spi/
│ ├── 0001-add-spi-dts-binding.patch
│ ├── 0002-fix-spi-clock-divider.patch
│ └── README.md
├── t113-i2c/
│ ├── 0001-add-i2c-controller.patch
│ └── README.md
├── t113-pwm/
│ └── 0001-add-pwm-fan-support.patch
└── series.conf # 补丁应用顺序配置文件
补丁命名规范：使用
序号-简短描述.patch 格式，序号保证应用顺序。在 series.conf 中按行列出补丁文件名，便于自动化工具（如 quilt）批量应用。
2.7 常见问题与避坑指南
| 问题场景 | 原因 | 解决方案 |
|---|---|---|
| 补丁应用后编译报错 | 内核 API 在新版本中已删除或重命名 | 查阅内核 Documentation/process/deprecated.rst，替换为新 API |
| 设备树节点不匹配 | 新内核修改了 compatible 字符串或属性名 |
对比 Documentation/devicetree/bindings/ 中的绑定文档 |
| Git 冲突标记残留 | 手动解决冲突后未清理 <<<<<<< 标记 |
使用 grep -r "<<<<<<<" . 全局搜索并修复 |
| 补丁顺序错误 | 依赖补丁未先应用 | 在 series.conf 中按拓扑排序，先基础后特性 |
重要提醒：在全志 T113 平台，部分外设驱动依赖全志私有头文件（如
include/linux/sunxi/）。在迁移到主线内核时，这些头文件可能不存在，需要将私有定义迁移到驱动自身或使用主线通用接口替代。
2.8 本章小结
本章系统介绍了全志 T113 驱动移植中的内核源码获取与版本管理方法：
- Git 仓库克隆：掌握浅克隆、稀疏检出、多远程源配置，提升源码管理效率。
- 版本标签选择：优先选择 LTS 版本（5.4/5.10/6.1），基于标签创建开发分支。
- 分支管理策略：采用“上游跟踪 + 特性分支 + 集成分支”模型，保持提交历史清晰。
- 补丁文件管理：使用
format-patch生成补丁，通过series.conf组织应用顺序，解决跨版本冲突。