3. Linux BSP源码树与版本管理
拿到一个 TI Sitara 处理器的 Linux SDK 安装包后，第一件容易让人困惑的事，是它看起来不像一个普通的“内核源码目录”。TI 的 Processor SDK Linux 采用 Yocto Project 构建体系，源码并不是集中放在一棵树里，而是由 ARAGO 发行层、meta-ti BSP 层、OpenEmbedded Core 以及若干第三方层共同组成。理解这套分层结构，是后续做工业平台适配、裁剪内核、替换 U-Boot 或锁定版本的前提。
一、SDK 顶层目录与 Yocto/ARAGO 的组织关系
以 Processor SDK Linux 08.xx / 09.xx 为例，安装后的顶层目录通常包含 board-support/、bin/、filesystem/、linux-devkit/、Makefile 等。其中真正与源码树相关的是 board-support/：它下面既有预打包的 linux-*.tar.gz、u-boot-*.tar.gz，也有 ti-processor-sdk-linux-*-evm-*/board-support/ti-linux-kernel/ 这类已解压的 Git 仓库。而 Yocto 的构建入口则在 board-support/yocto-build/ 或独立的 tisdk/ 目录中，通过 oe-layersetup 脚本拉取各层。
ARAGO 是 TI 在 OpenEmbedded 之上维护的发行配置层，它定义了 arago.conf、distro 特性、工具链版本和默认镜像配方。meta-ti 则提供芯片相关的 BSP 配方：机器配置（conf/machine/*.conf）、U-Boot 与内核的 .bbappend、设备树、固件和引导脚本。两者关系可以概括为：ARAGO 决定“用什么发行版策略构建”，meta-ti 决定“为哪颗芯片构建什么”。
二、u-boot / linux / recipes 的分层与覆盖机制
在 Yocto 中，U-Boot 和内核都不是“直接改源码”，而是通过 recipe 与 bbappend 控制。以 AM335x 为例，meta-ti 中会有 recipes-bsp/u-boot/u-boot-ti.bb 和 recipes-kernel/linux/linux-ti-staging_*.bb，它们指定了源码 Git 地址、分支、SRCREV、配置文件（defconfig）和设备树列表。TI 的 SDK 层再通过 .bbappend 追加补丁、修改 PV 或覆盖 SRCREV。
这种“基础 recipe + 追加 bbappend”的机制，意味着版本管理的核心不是文件拷贝，而是 SRCREV 与分支的锁定。例如：
# meta-ti/recipes-kernel/linux/linux-ti-staging_6.1.bb
SRC_URI = "git://git.ti.com/ti-linux-kernel/ti-linux-kernel.git;protocol=https;branch=ti-linux-6.1.y"
SRCREV = "a1b2c3d4e5f6..."
# 产品层追加
# meta-myproduct/recipes-kernel/linux/linux-ti-staging_%.bbappend
SRCREV = "9f8e7d6c5b4a..."
SRC_URI += "file://0001-my-industrial-patch.patch"当执行 bitbake -e linux-ti-staging | grep ^SRCREV 时，可以看到最终生效的 SRCREV 是产品层覆盖后的值。这就是分层覆盖的实际效果：越靠后的层优先级越高，越能覆盖前面的定义。
三、Git 仓库与分支策略
TI 的源码托管在 git.ti.com 上，主要仓库包括 ti-linux-kernel/ti-linux-kernel、ti-u-boot/ti-u-boot、ti-linux-firmware 等。分支命名遵循 ti-linux-6.1.y、ti-u-boot-2023.04 这类规则，其中 ti- 前缀表示 TI 的集成分支，.y 表示稳定维护线。TI 会定期把上游 stable 分支合并进来，并叠加 Sitara 平台补丁。
实际项目中推荐的做法是：不要直接在 TI 分支上开发，而是基于某个 tag 或 SRCREV 创建自己的产品分支，例如 myproduct-6.1.y，把工业定制补丁以 commit 形式叠加。这样既能跟随 TI 更新，又能保持产品差异清晰可追溯。分支策略可以概括为三层：上游主线 → TI 集成分支 → 产品分支，每一层只做自己该做的事。
四、BSP 版本与芯片匹配
TI 的 SDK 版本与芯片、内核版本、U-Boot 版本之间存在明确的对应关系。下表列出常见 Sitara 器件的匹配示例（具体以 TI 官方发布说明为准）：
| 芯片系列 | 典型 SDK 版本 | 内核分支 | U-Boot 分支 | machine 配置 |
|---|---|---|---|---|
| AM335x | Processor SDK 08.02 | ti-linux-5.10.y | ti-u-boot-2021.01 | am335x-evm.conf |
| AM437x | Processor SDK 08.02 | ti-linux-5.10.y | ti-u-boot-2021.01 | am437x-evm.conf |
| AM57xx | Processor SDK 08.02 | ti-linux-5.10.y | ti-u-boot-2021.01 | am57xx-evm.conf |
| AM64x | Processor SDK 09.00 | ti-linux-6.1.y | ti-u-boot-2023.04 | am64xx-evm.conf |
| AM62x | Processor SDK 09.00 | ti-linux-6.1.y | ti-u-boot-2023.04 | am62xx-evm.conf |
匹配时最容易出错的地方是：设备树、U-Boot 配置和内核配置必须来自同一 SDK 版本。如果混用 08.02 的 dtb 和 09.00 的内核，可能出现引脚复用冲突、时钟树不匹配或驱动 probe 失败。判断方法是在目标板上执行 cat /proc/device-tree/model 和 uname -a，确认设备树模型与内核版本是否与 SDK 发布说明一致。
- 确认
conf/local.conf中MACHINE与目标芯片一致； - 确认
bblayers.conf中 meta-ti 层路径正确且顺序合理； - 用
bitbake -e检查最终 SRCREV、PV、MACHINE 是否被意外覆盖； - 记录产品分支的 commit hash，作为 BSP 版本基线；
- 升级 SDK 时，先对比 TI 发布说明中的“迁移注意事项”，再合并产品补丁。
把源码树、层关系、recipe 覆盖和 Git 分支策略串起来看，TI Sitara Linux BSP 的版本管理本质上是一套“层优先级 + SRCREV 锁定 + 产品分支”的组合机制。掌握这套机制后，无论是做工业协议栈集成、实时内核改造，还是长期维护多个硬件版本，都能做到有据可查、可回退、可复现。