4. BSP与L4T版本管理

在Jetson量产测试与烧录验证工程中，版本管理不是“记录一下用了哪个JetPack”这么简单。真正决定一块模组能否被稳定烧录、能否通过产测、能否在客户现场复现问题的，是四个彼此耦合的版本维度：JetPack版本、L4T源码版本、Board Spec（板级规格）以及配置文件集合。它们共同构成一个BSP（Board Support Package）的完整身份。任何一项发生漂移，都可能让同一批模组出现“有的能烧、有的报错”的诡异现象。

四个版本维度分别管什么

JetPack是NVIDIA面向Jetson的SDK发行包，它把L4T、CUDA、cuDNN、TensorRT、多媒体API等打包成一个可安装的整体。JetPack版本号（如5.1.2、6.0）决定了上层软件栈的基线，但它不直接等于你实际烧进模组的固件版本。真正落到模组eMMC或NVMe上的，是L4T（Linux for Tegra）的BSP。

L4T源码版本通常以“R”开头，例如R35.4.1对应JetPack 5.1.2，R36.3.0对应JetPack 6.0。L4T源码包含U-Boot、Linux内核、设备树（DTS/DTB）、根文件系统、闪存配置（flash.xml、分区表）以及NVIDIA提供的驱动。量产固件版本控制的核心，就是锁定一个确定的L4T源码tag，并在此基础上叠加自己的板级改动。

Board Spec描述的是硬件本身的电气与机械规格：模组型号（如Orin NX 16GB）、载板设计、电源时序、PCIe/USB/MIPI通道分配、GPIO映射、EEPROM内容等。Board Spec一旦变更（例如载板改版、更换PHY芯片），设备树和引脚配置必须同步更新，否则会出现“系统能启动但外设不工作”的问题。

配置文件则是把上述三者“粘合”起来的具体参数：p3448-0000-p3449-0000-a02.conf这类板级配置、flash.xml分区布局、odmdata、bpmp配置、pinmux表、device tree覆盖文件等。它们决定了烧录时写入哪些镜像、写到哪个偏移、以什么参数启动。

版本对应关系与常见陷阱

JetPack与L4T的对应关系必须查表确认，不能凭记忆。例如JetPack 5.1.2对应L4T R35.4.1，JetPack 6.0对应L4T R36.3.0。如果团队里有人用JetPack 5.1.2的SDK Manager刷机，另一个人用R35.4.1源码手动编译，理论上一致，但若其中一人拉了R35.4.1的某个中间commit，设备树就可能与官方发布包不同，导致烧录后HDMI无输出或PCIe枚举失败。

更隐蔽的陷阱在Board Spec与配置文件的匹配上。以Orin NX为例，p3767-0000与p3767-0001对应不同内存容量和SKU，其odmdata、bpmp配置、pinmux都可能不同。如果产线误用了p3767-0000的conf去烧p3767-0001的模组，可能出现“烧录成功但启动卡在U-Boot”的现象。因此，量产固件包必须把“适用模组型号”作为强制校验项。

量产固件版本控制策略

建议采用“三层锁定”策略。第一层是源码层：用Git管理L4T源码，打上自己的板级patch，并打tag，例如l4t-r35.4.1-customer-v1.0。第二层是构建层：用脚本固定编译环境（Docker镜像或指定Ubuntu版本），记录apply_binaries.sh的输入参数、flash.sh的板级conf、odmdata值，输出构建日志。第三层是发布层：生成量产烧录包时，附带一个version.json，内容至少包含JetPack版本、L4T版本、Board Spec标识、配置文件哈希、构建时间、SHA256校验值。

{
  "jetpack": "5.1.2",
  "l4t": "R35.4.1",
  "board_spec": "p3767-0000 + p3768-0000-a02",
  "config_files": {
    "conf": "p3767-0000-p3768-0000-a02.conf",
    "flash_xml": "flash.xml",
    "pinmux": "tegra234-mb1-bct-pinmux-p3767-dp-a03.dtsi"
  },
  "build_time": "2025-03-18T10:22:00+08:00",
  "sha256": "a3f1c9e2b7d4..."
}

产线烧录工具在开始烧录前，应先读取模组EEPROM中的Board Spec信息，与version.json中的board_spec比对。不匹配则拒绝烧录并报警，而不是“先烧了再说”。这一步能把大量批次性错误拦截在烧录之前。

变更管理与冻结

量产固件一旦进入量产阶段，应执行版本冻结。任何变更——无论是NVIDIA发布安全补丁、载板改版，还是客户要求升级CUDA——都必须走变更评审，生成新的版本号，并重新执行完整的烧录验证与产测。不能在同一版本号下“悄悄替换”烧录包，否则现场出现问题时无法追溯到底烧的是哪一版。

对于多客户、多SKU的场景，建议维护一张版本矩阵表，行是模组型号与载板组合，列是固件版本，单元格记录验证状态（已验证/待验证/不适用）。每次发布新固件，只更新受影响的行，避免全量重测。这样既保证可追溯性，又控制验证成本。

总结来说，BSP与L4T版本管理的本质，是把JetPack、L4T源码、Board Spec、配置文件四者绑定成一个不可分割的“固件身份”，并通过版本号、校验值和变更记录，让这个身份在量产、测试、返修、升级的全生命周期中始终可追溯、可复现。做到这一点，产线才不会因为“版本对不上”而停线，客户现场也不会因为“烧错包”而返工。