3. Sitara平台开发环境搭建与启动流程

在开始为 TI Sitara（以 AM335x 系列为例）编写工业数据采集程序之前，必须先建立一套完整的开发环境，并理解从上电到根文件系统挂载的整条启动链路。本节围绕“工具安装—源码配置—镜像烧写—串口验证”这条主线展开，重点讲清楚 SPL、U-Boot、Kernel、Rootfs 四段加载过程各自负责什么、由谁加载、失败时如何判断。

一、开发环境需要哪些工具

TI 的 Sitara 开发通常依赖四类工具，它们分工明确，缺一不可：

  • CCS（Code Composer Studio）：集成开发与调试环境，用于编写、编译、下载和单步调试裸机程序或 RTOS 程序，也用于连接 XDS 系列仿真器。
  • SDK（Processor SDK Linux）：包含交叉编译工具链、U-Boot 源码、Linux 内核源码、设备树、根文件系统以及 Yocto 构建脚本，是 Linux 侧开发的核心。
  • PinMux Tool：图形化引脚复用配置工具，用于确定每个引脚的功能（如 MII、I2C、UART、GPIO），并生成可供 U-Boot/内核使用的配置片段。
  • Clock Tree Tool：时钟树配置工具，用于查看和计算各模块时钟源、分频系数与输出频率，帮助排查外设时钟未使能或频率不符的问题。

安装顺序建议为：先装 CCS 与仿真器驱动，再安装 Processor SDK，最后安装 PinMux 与 Clock Tree 工具。SDK 安装完成后，需要执行环境变量脚本，使交叉编译器进入 PATH：

export PATH=$HOME/ti/processor-sdk-linux/bin:$PATH
arm-linux-gnueabihf-gcc -v

若能看到 gcc 版本信息，说明工具链可用。注意 SDK 版本要与芯片型号匹配，例如 AM335x 应选择对应 am335x-evm 的 SDK。

二、U-Boot、内核与根文件系统的配置

U-Boot 是第二阶段引导程序，负责初始化 DDR、串口、MMC 等关键外设，并加载内核。配置时通常先选定板级 defconfig，再按需裁剪：

make ARCH=arm CROSS_COMPILE=arm-linux-gnueabihf- am335x_evm_defconfig
make ARCH=arm CROSS_COMPILE=arm-linux-gnueabihf- menuconfig
make ARCH=arm CROSS_COMPILE=arm-linux-gnueabihf- -j4

内核配置同样先取默认配置，再打开采集相关驱动，例如 ADC、I2C、SPI、网络与文件系统支持：

make ARCH=arm CROSS_COMPILE=arm-linux-gnueabihf- omap2plus_defconfig
make ARCH=arm CROSS_COMPILE=arm-linux-gnueabihf- menuconfig
make ARCH=arm CROSS_COMPILE=arm-linux-gnueabihf- dtbs zImage -j4

根文件系统可以使用 SDK 提供的预编译镜像，也可以用 BusyBox 自行构建。工业采集场景通常需要保留 /dev、/sys、/proc 以及采集程序运行目录。设备树文件（.dtb）必须与硬件引脚配置一致，PinMux 生成的配置应体现在设备树或 U-Boot 的 pinmux 数据中。

三、SD 卡分区与镜像烧写

首次启动推荐使用 SD 卡，因为它不破坏板载存储，便于反复验证。SD 卡一般分为两个分区：

分区格式内容
第 1 分区FAT32MLO（SPL）、u-boot.img、zImage、am335x-evm.dtb
第 2 分区ext4根文件系统 rootfs

烧写时先确认设备名，避免误写系统盘：

lsblk
sudo dd if=MLO of=/dev/sdX bs=512 seek=1 conv=fsync
sudo dd if=u-boot.img of=/dev/sdX bs=512 seek=1 conv=fsync

MLO 必须写在 FAT 分区起始位置附近，Sitara 的 ROM 代码会按固定顺序在 SD 卡中查找有效引导头。若 MLO 位置错误，串口将没有任何输出。

四、串口连接与启动链路观察

使用 USB 转 TTL 串口线连接板子的 UART0，参数为 115200-8-N-1。上电后应依次看到 ROM → SPL → U-Boot → Kernel → Rootfs 的输出。下图给出这条加载链路的对象与传递关系：

Sitara 首次启动加载链路（SD 卡启动） ROM Code 芯片内部固化 SPL / MLO 初始化 DDR U-Boot 加载内核与 DTB Kernel 驱动与设备树 Rootfs 挂载 /init SD 卡分区内容 FAT32：MLO + u-boot.img + zImage + am335x-evm.dtb ext4：rootfs（/bin /etc /dev /proc） 串口关键输出（115200-8-N-1） U-Boot SPL 2021.01 → U-Boot 2021.01 → Loading Kernel from mmc0:1 → Starting kernel ... [ 0.000000] Booting Linux on physical CPU 0x0 → VFS: Mounted root (ext4) ...

判断启动是否成功，可以按以下顺序检查：

  1. 串口是否有 ROM 输出。无输出说明串口线、波特率或 SD 卡引导头有问题。
  2. 是否打印 U-Boot SPL。若停在 SPL，多为 DDR 配置或 MLO 不匹配。
  3. 是否进入 U-Boot 命令行。若提示 mmc init failed，检查分区与文件系统格式。
  4. 是否出现 Starting kernel ...。若卡在此处，通常是 DTB 与硬件不匹配或内核镜像损坏。
  5. 是否出现 VFS: Mounted root。若提示 Kernel panic - not syncing: VFS，说明根文件系统分区或 root= 参数错误。
在 U-Boot 中可用 printenv 查看 bootargs，确认 root=/dev/mmcblk0p2 与 console=ttyO0,115200n8 是否与实际分区和串口一致。修改后可用 saveenv 保存。

五、常见问题与排查思路

首次启动失败大多集中在三类原因：一是 MLO 未写入或写入位置错误，导致 ROM 找不到引导程序；二是设备树与 PinMux 配置不一致，表现为串口无输出或外设不工作；三是根文件系统分区未格式化或 bootargs 指向错误分区。排查时建议先只保留最小系统（MLO + U-Boot + 内核 + 最小 rootfs），确认链路通畅后再逐步加入采集驱动与应用程序。

完成首次启动后，应记录下串口完整日志、U-Boot 环境变量和分区布局，作为后续调试的基线。只有这条加载链路稳定可复现，后续的工业数据采集程序才有可靠的运行基础。

← 上一章 📖 返回目录 下一章 →