第四章 Linux系统移植：基于征程芯片的内核配置、设备树编写、根文件系统构建与启动流程
征程系列芯片（如J3、J5、J6）作为面向智能驾驶与高阶辅助驾驶的高算力SoC，其Linux系统移植的复杂度远高于通用应用处理器。系统移植不仅仅是编译一个内核镜像，而是需要围绕芯片特有的异构计算单元（CPU簇、BPU、ISP、GPU）、多路MIPI-CSI输入、功能安全岛（Safety Island）以及复杂的电源/时钟域进行深度定制。本章将基于地平线开源SDK（如地平线OpenExplorer或XJ3 BSP），系统拆解Linux内核配置、设备树（DTS）编写、根文件系统（RootFS）构建以及从Bootloader到用户空间的完整启动链路。
征程芯片的Linux移植本质上是一个“硬件抽象收敛”的过程。开发者需要将芯片手册中描述的寄存器级细节，通过设备树和内核配置，转化为操作系统可管理的资源。本章节将按照“配置→描述→构建→启动”的逻辑主线，结合地平线J3芯片的实战经验，帮助学员建立完整的系统移植知识框架。
4.1 内核配置：从defconfig到精细化裁剪
征程芯片的Linux内核配置不能直接使用ARM64通用的defconfig，因为其包含大量与智能驾驶无关的驱动（如消费级GPU、桌面音频等），且缺少BPU、ISP等核心加速器驱动。地平线官方BSP提供了基于内核5.10/5.15的arch/arm64/configs/horizon_j3_defconfig，但实际项目必须基于此进行二次裁剪与优化。
核心原理：三层次配置模型
征程芯片的内核配置需要关注三个层次：芯片基础层（CPU频率、GIC中断控制器、ARM架构特性）、外设接口层（MIPI-CSI、I2C、SPI、UART、Ethernet AVB）、计算加速层（BPU、ISP、GPU、VPU）。其中计算加速层是征程芯片区别于普通ARM平台的关键，通常以内核模块（.ko）形式存在，便于独立升级。
| 配置项 | 推荐值 | 说明 |
|---|---|---|
| CONFIG_ARCH_HORIZON | y | 启用征程芯片架构支持 |
| CONFIG_CMA_SIZE_MBYTES | 512 | 为ISP/VPU预留连续内存 |
| CONFIG_ION | y | BPU推理所需内存分配器 |
| CONFIG_VIDEO_HORIZON_MIPI | m | MIPI-CSI驱动模块化 |
| CONFIG_PREEMPT | y | 降低ISP中断延迟 |
| CONFIG_HZ_1000 | y | 高时钟频率提升调度精度 |
操作流程：基于menuconfig的增量配置
- 加载地平线基础配置：
make horizon_j3_defconfig - 执行
make menuconfig，按项目需求勾选/取消驱动。 - 重点检查
Device Drivers → Staging drivers中的BPU/ISP驱动路径。 - 保存配置并生成
.config，使用make savedefconfig生成精简defconfig。 - 编译内核：
make Image dtbs modules -j$(nproc)
实战场景：自动驾驶域控制器的内核裁剪
在某L2+级ADAS项目中，我们基于J3芯片需要同时运行感知算法和车辆控制。初始内核镜像大小为18MB，启动时间2.3秒。通过裁剪掉蓝牙、WiFi、HDMI等非必要驱动，并将BPU/ISP驱动改为模块化加载，最终内核镜像缩减至11MB，启动时间降至1.6秒。关键操作包括：CONFIG_BT=n、CONFIG_DRM_DW_HDMI=n，同时将CONFIG_VIDEO_HORIZON_MIPI设为m。
常见误区
- 盲目追求最小内核：过度裁剪可能导致ISP的MIPI-CSI2协议栈缺失，造成摄像头图像采集异常。
- 忽略CMA配置：BPU推理需要大块连续物理内存，CMA设置过小会导致内存分配失败。
- 模块与内建混用不当：BPU驱动若内建，则无法在运行时动态调整内存策略。
4.2 设备树编写：描述征程芯片的硬件拓扑
设备树（DTS）是连接内核与征程芯片硬件细节的桥梁。与通用ARM平台不同，征程芯片的设备树需要特别关注多级时钟域、电源域以及异构核间通信的描述。一个典型的J3设备树包含约2000行代码，其中约40%用于描述BPU/ISP相关的复杂外设。
核心原理：设备树中的“域”概念
征程芯片将硬件划分为多个电源域（如PD_CPU、PD_BPU、PD_ISP）和时钟域（如CLK_BPU_CORE、CLK_ISP_AXI）。设备树中必须通过power-domains和clocks属性明确每个外设的归属，否则内核无法正确执行动态电源管理（DVFS）。
/* 征程J3 BPU节点示例 */
&bpu {
compatible = "horizon,bpu-v3";
reg = <0x0 0xA5100000 0x0 0x10000>;
interrupts = <GIC_SPI 96 IRQ_TYPE_LEVEL_HIGH>;
clocks = <&clk CLK_BPU_CORE>, <&clk CLK_BPU_AXI>;
clock-names = "core", "axi";
power-domains = <&pd PD_BPU>;
operating-points-v2 = <&bpu_opp_table>;
memory-region = <&bpu_reserved>;
};
判断方法：设备树编译与运行时验证
编写完成后，使用make dtbs编译生成.dtb文件。在U-Boot中通过fdt addr和fdt ls命令检查节点是否完整。更关键的是内核启动日志中的OF: fdt: Machine model: Horizon J3以及后续的驱动probe信息。若BPU驱动未成功probe，通常会在dmesg中看到failed to get clock或no power domain等错误。
status = "okay"，并配合earlycon启动参数，以便在串口终端实时观察设备树解析过程。案例拆解：MIPI-CSI摄像头设备树调试
在某项目中，J3连接了6路摄像头，但系统启动后只有4路能被内核识别。通过对比原理图与设备树，发现port节点下的endpoint连接关系错误。具体表现为：csi2_rx节点的remote-endpoint指向了错误的sensor_out端口。修正后，6路摄像头全部正常枚举。此案例说明，征程芯片的MIPI-CSI设备树必须严格遵循“Sensor→MIPI D-PHY→CSI-2 Controller→ISP”的链路顺序。
常见误区
- 忽略reserved-memory：BPU和ISP需要独占物理内存，必须在设备树中预留，否则内核会将其分配给普通进程。
- 时钟频率描述错误：征程芯片的时钟树非常复杂，错误描述会导致外设工作频率异常，表现为摄像头帧率不稳或BPU算力下降。
- pinctrl配置遗漏：I2C、UART等引脚复用必须在设备树中明确，否则外设无法工作。
4.3 根文件系统构建：Buildroot与Yocto的实战选择
征程芯片的根文件系统需要平衡体积、启动速度和开发便利性。地平线官方推荐使用Buildroot构建最小系统，但量产项目往往需要集成自研算法库和中间件，此时Yocto的定制化能力更强。
核心原理：RootFS的层次化设计
一个完整的征程芯片RootFS通常分为四层：基础层（BusyBox、glibc）、驱动层（内核模块、固件文件）、算法层（BPU运行时库、OpenCV）、应用层（感知、规划、控制进程）。分层设计便于独立更新，避免因算法升级而重刷整个文件系统。
| 构建工具 | 优点 | 缺点 | 适用场景 |
|---|---|---|---|
| Buildroot | 简单、快速、体积小 | 定制复杂软件包困难 | 原型验证、小批量 |
| Yocto | 高度可定制、版本管理完善 | 学习曲线陡峭、构建时间长 | 量产项目、长期维护 |
| Debian/Ubuntu | 软件包丰富、调试方便 | 体积大、启动慢 | 开发调试阶段 |
操作流程：基于Buildroot的最小系统构建
- 下载地平线提供的Buildroot外部树（
br2-external）。 - 配置目标架构：
make horizon_j3_defconfig - 添加必要的用户包：如
iproute2、ethtool、gdb（调试用）。 - 执行
make，生成rootfs.ext4镜像。 - 将内核模块安装到
target/lib/modules/目录。
bpu_fw.bin）放置在/lib/firmware/horizon/目录下，并在内核模块加载时通过request_firmware机制动态加载，避免固件烧录在Bootloader分区中导致升级困难。实战场景：Yocto定制带安全启动的RootFS
在功能安全项目中，我们使用Yocto构建了一个只读的RootFS，并通过dm-verity进行完整性校验。关键步骤包括：在local.conf中设置IMAGE_FSTYPES = "ext4"，启用dm-verity内核模块，并使用veritysetup生成哈希树。最终RootFS大小为256MB，启动时校验时间仅增加0.3秒，但有效防止了RootFS被篡改的风险。
常见误区
- 使用NFS作为量产RootFS：NFS依赖网络，且无掉电保护，仅适合开发调试。
- 忽略initramfs：在需要提前加载BPU驱动的场景，应使用initramfs作为过渡，再切换到真正的RootFS。
- 文件系统权限混乱：征程芯片的某些设备节点（如
/dev/bpu）需要特定用户组权限，否则算法进程无法访问。
4.4 启动流程：从ROM Code到用户空间的完整链路
征程芯片的启动流程遵循ARM64标准，但加入了安全启动和异构核启动的复杂性。理解整个链路对于排查启动失败问题至关重要。
核心原理：五阶段启动模型
征程J3的启动分为五个阶段：ROM Code（固化在芯片内部，负责初始化DDR和加载SPL）、SPL（初始化时钟和DDR控制器，加载U-Boot）、U-Boot（加载内核和设备树，传递启动参数）、Kernel（解压并初始化硬件）、init进程（挂载RootFS并启动系统服务）。其中，SPL阶段会进行安全启动校验，确保Bootloader未被篡改。
/* U-Boot环境变量示例 */
setenv bootargs 'console=ttyS0,1500000n8 root=/dev/mmcblk0p5 rw rootwait mem=6G cma=512M'
setenv bootcmd 'ext4load mmc 0:1 0x80200000 Image; ext4load mmc 0:1 0x83000000 horizon-j3.dtb; booti 0x80200000 - 0x83000000'
判断方法：启动日志分析
当系统无法启动时，通过串口日志定位阶段。若日志停留在U-Boot 2020.04之前，问题在SPL或DDR初始化；若出现Starting kernel ...后无输出，则可能是设备树中chosen节点的bootargs配置错误或内核早期串口未初始化。
mailbox机制启动。在设备树中必须描述mailbox节点，否则BPU固件无法加载，导致算法进程崩溃。案例拆解：启动卡在“Starting kernel”的排障
在某次移植中，内核启动日志在Starting kernel ...后完全停止。通过排查，发现U-Boot传递的bootargs中console=ttyS0与设备树中stdout-path不一致。U-Boot使用ttyS0，而设备树中定义为serial0。修正设备树中的aliases节点后，内核日志正常输出。此案例说明，征程芯片的串口别名映射必须与U-Boot环境变量严格对应。
常见误区
- 忽略FIT镜像格式：征程芯片支持FIT（Flattened Image Tree）格式，可将内核、设备树、ramdisk打包为一个镜像，便于签名校验。但部分开发者仍使用传统镜像格式，导致安全启动功能无法启用。
- 内存布局冲突：U-Boot加载内核的地址（如
0x80200000）必须与设备树中reserved-memory区域不重叠，否则内核启动时会覆盖BPU固件。 - 盲目使用quiet参数：在调试阶段应移除
quiet，保留loglevel=8以获取完整日志。