📚 课程目录第3章获取Linux内核源码

3. 获取Linux内核源码：从kernel.org下载主线内核、从芯片厂商（如NXP/ST）获取BSP内核、Git仓库管理

在ARM平台移植实战中，获取正确的内核源码是决定项目成败的第一步。不同来源的内核各有其适用场景与维护策略，开发者需要根据项目阶段、硬件平台与长期维护需求做出选择。本章系统梳理三种主流获取路径及其管理方法。

核心原则： 主线内核（Mainline）适合通用开发与社区协作；芯片厂商BSP内核适合快速原型验证与硬件驱动依赖；自维护Git仓库适合产品化阶段的版本管理与定制。

3.1 内核源码的三大来源对比

来源	典型URL/仓库	适用阶段	驱动完整性	长期维护成本
主线内核（kernel.org）	`https://www.kernel.org`	社区开发、通用平台	仅包含已合入驱动	低（社区持续维护）
芯片厂商BSP	NXP: `github.com/nxp-imx` ST: `github.com/STMicroelectronics`	硬件验证、快速原型	完整（含闭源/未合入驱动）	高（依赖厂商发布节奏）
自维护Git仓库	企业内部GitLab/GitHub	产品化、量产维护	按需定制	中（需团队持续同步上游）

3.2 从kernel.org获取主线内核

主线内核是Linux社区官方发布的内核源码，适用于所有通用ARM平台。下载方式包括HTTP、FTP与Git克隆。

3.2.1 通过HTTP下载稳定版本

# 下载Linux 6.6 LTS稳定版（推荐用于新项目）
wget https://cdn.kernel.org/pub/linux/kernel/v6.x/linux-6.6.tar.xz

# 解压
tar -xf linux-6.6.tar.xz
cd linux-6.6

3.2.2 通过Git克隆主线仓库

# 克隆完整主线仓库（包含所有历史标签）
git clone https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
cd linux

# 查看所有可用标签（含LTS版本）
git tag -l 'v6.*' | head -20

# 切换到指定LTS版本
git checkout v6.6

注意： 主线内核不包含未合入的厂商驱动。对于NXP i.MX、ST STM32MP等平台，直接使用主线内核可能导致外设（如GPU、VPU、特定以太网PHY）无法驱动。建议先通过make ARCH=arm defconfig验证基础启动能力。

3.3 从芯片厂商获取BSP内核

芯片厂商提供的BSP（Board Support Package）内核基于主线内核，额外包含未合入的硬件驱动、设备树补丁与配置脚本。以NXP i.MX与ST STM32MP系列为例。

3.3.1 NXP i.MX BSP内核获取

# NXP官方i.MX Linux内核仓库（基于LTS + 厂商补丁）
git clone https://github.com/nxp-imx/linux-imx.git
cd linux-imx

# 查看NXP发布分支（如lf-6.6.y对应Linux 6.6 LTS）
git branch -a | grep 'lf-'

# 切换到i.MX 8M Plus推荐分支
git checkout lf-6.6.y_2.0.0

3.3.2 ST STM32MP BSP内核获取

# ST官方STM32MP Linux内核仓库
git clone https://github.com/STMicroelectronics/linux-stm32.git
cd linux-stm32

# 查看ST维护分支
git branch -a | grep 'stm32'

# 切换到STM32MP25系列支持分支
git checkout stm32mp-v6.6

厂商	仓库地址	典型分支命名	包含内容
NXP	`github.com/nxp-imx/linux-imx`	`lf-6.6.y_2.0.0`	i.MX全系列驱动、VPU/GPU补丁、DDR训练固件
ST	`github.com/STMicroelectronics/linux-stm32`	`stm32mp-v6.6`	STM32MP系列驱动、M4协处理器支持、Trusted Firmware补丁
TI	`git.ti.com/ti-linux-kernel`	`ti-linux-6.6.y`	AM62x/AM64x系列驱动、PRU-ICSS、工业协议栈

  实战建议： 首次接触某款ARM SoC时，优先使用厂商BSP内核进行硬件验证。待所有外设驱动验证通过后，再评估将必要补丁移植到主线内核的可行性。

3.4 Git仓库管理与分支策略

在产品开发中，内核源码的版本管理直接影响团队协作效率与长期维护成本。推荐采用“上游跟踪 + 产品分支”的双分支策略。

3.4.1 推荐的分支模型

# 1. 克隆厂商BSP内核作为上游
git clone https://github.com/nxp-imx/linux-imx.git linux-imx-product
cd linux-imx-product

# 2. 创建产品分支（基于厂商LTS标签）
git checkout -b product-v1.0 lf-6.6.y_2.0.0

# 3. 添加产品定制补丁
git am /path/to/patches/0001-*.patch

# 4. 标记产品发布版本
git tag -a v1.0.0 -m "Product v1.0 initial release"

# 5. 当厂商发布新BSP时，合并上游更新
git checkout product-v1.0
git merge lf-6.6.y_2.1.0

3.4.2 分支管理策略对比

策略	适用场景	优点	缺点
直接基于厂商分支	快速原型、评估阶段	简单直接，无需额外管理	无法隔离产品定制，升级困难
产品分支 + 定期合并	产品开发、量产维护	隔离定制，可跟踪上游安全更新	合并冲突需人工处理
补丁队列（quilt/stgit）	需要精细控制补丁顺序	每个补丁可独立管理、回退	学习曲线陡峭，团队协作复杂

3.5 内核源码获取与分支管理流程

3.6 验证源码完整性与版本一致性

获取源码后，必须验证其完整性与版本一致性，避免因下载损坏或分支错误导致编译失败。

# 1. 验证Git仓库完整性
git fsck --full

# 2. 确认当前分支与标签
git log --oneline -3
git describe --tags

# 3. 检查内核版本字符串
head -5 Makefile | grep VERSION

# 4. 验证厂商补丁是否完整（以NXP为例）
git log --oneline --grep="MLK-" | wc -l

  关键检查点：
  Makefile中的VERSION、PATCHLEVEL、SUBLEVEL是否与预期LTS版本一致
厂商分支是否包含目标SoC的设备树文件（如arch/arm/boot/dts/imx8mp.dtsi）
Git日志中是否有厂商特有的提交前缀（如NXP的MLK-、ST的stm32mp:）

3.7 本章小结

获取Linux内核源码是ARM平台移植的起点，选择正确的来源与版本管理策略直接影响开发效率与产品质量。主线内核适合通用开发与社区协作，厂商BSP内核提供最完整的硬件支持，自维护Git仓库则是产品化维护的基石。建议开发团队建立“上游跟踪 + 产品分支”的双分支模型，定期同步安全更新与关键修复，同时保持产品定制的独立性。