3. VxWorks目标机启动与调试基础

VxWorks 的自动化测试与持续集成，最终都要落到目标机上：镜像能不能稳定加载、串口和网络通道是否可用、Shell 能否执行命令、调试代理能否连上、启动流程是否可复现。这一节围绕“目标机从加电到可调试”的完整链路展开，重点讲清 BootROM 与 VxWorks 映像的关系、串口与网络两种启动方式、WindSh 与 Target Shell 的使用差异、GDB 调试代理的连接方式，以及如何分析系统启动流程。

BootROM 与 VxWorks 映像的分工

VxWorks 目标机启动涉及两类镜像。第一类是 BootROM，它通常烧写在 Flash 或作为引导程序加载，负责最基础的硬件初始化（CPU、内存控制器、串口、网口）、提供引导参数和加载能力。第二类是 VxWorks 映像，它包含内核、驱动和应用组件，是真正运行测试代码的系统。BootROM 的任务是把 VxWorks 映像从网络、本地存储或 TFTP 服务器搬到内存并跳转执行。

常见映像形态包括：vxWorks（可加载的压缩或未压缩内核）、vxWorks.st（带符号，便于调试）、bootrom.bin / bootrom_uncmp.bin（引导 ROM）。在自动化测试环境中，建议保留带符号的 vxWorks.st，否则 GDB 调试时无法解析函数与变量。

串口启动与网络启动

串口启动是最基础的通道。目标机通过串口输出 BootROM 的启动日志，操作者可以在串口终端中查看内存检测、网口初始化、boot line 解析等过程。串口启动通常用于首次烧写、网络参数未知或网络启动失败时的兜底。串口参数一般为 115200-8-N-1，无流控。在自动化测试中，串口常被用作日志采集和异常恢复通道。

网络启动是持续集成中最常用的方式。BootROM 通过 TFTP 或 FTP 从主机拉取 VxWorks 映像，加载到内存后跳转。网络启动的关键是主机侧要运行 TFTP/FTP 服务，且目标机与主机在同一网段、IP 配置正确。网络启动速度快、便于替换镜像，适合 CI 中频繁刷机与回归测试。

# 主机侧启动 TFTP 服务（示例）
sudo systemctl start tftpd-hpa
# 将 vxWorks.st 放入 TFTP 根目录
cp vxWorks.st /srv/tftp/
# 目标机 BootROM 中设置 boot line
boot line: motetsec(0,0)host:vxWorks h=192.168.1.100 e=192.168.1.10 u=target pw=vxworks f=0x0

判断网络启动是否成功，主要看串口日志中是否出现 Loading...、Starting at 0x... 以及内核启动后的版本信息。如果卡在 Loading...，优先检查 TFTP 服务、防火墙、IP 与文件名；如果加载后无输出，检查映像是否与目标机 CPU 架构匹配。

WindSh 与 Target Shell

WindSh 是运行在主机侧的交互式 Shell，通过串口或网络与目标机上的 Target Shell 通信。Target Shell 运行在目标机内部，负责解析并执行 C 语言风格的命令。两者关系是：WindSh 是前端，Target Shell 是后端。WindSh 可以执行 i（查看任务）、sp（查看任务栈）、lkup（查找符号）、d（查看内存）、taskSpawn（创建任务）等命令。

在自动化测试中，WindSh 常被脚本化调用，通过重定向输入输出实现命令批处理。例如，将一组命令写入文件，再通过串口或 Telnet 发送到目标机。Target Shell 的返回值、打印信息是判断测试是否通过的重要依据。

# WindSh 常用命令示例
-> i                    # 列出所有任务
-> sp                   # 查看任务栈使用
-> lkup "testFunc"      # 查找符号地址
-> d 0x100000, 16       # 查看内存
-> taskSpawn "t1", 100, 0, 0x2000, testFunc, 0,0,0,0,0,0,0,0,0,0

GDB 调试代理

VxWorks 支持通过 GDB 进行源码级调试。目标机上需要运行调试代理（如 gdbserver 或 WDB 代理），主机侧 GDB 通过串口或网络连接代理，实现断点、单步、变量查看。典型连接方式为 target remote 192.168.1.10:1234 或 target remote /dev/ttyS0。调试代理需要与带符号的 vxWorks.st 配合，否则无法解析符号。

在 CI 中，GDB 调试代理更多用于失败用例的现场保留：当测试异常时，自动触发 GDB 连接，抓取任务栈、寄存器、内存快照，供后续分析。这比单纯看日志更有效，尤其适合定位死锁、越界、任务挂起等问题。

系统启动流程分析

VxWorks 启动流程可以概括为：上电 → BootROM 初始化硬件 → 解析 boot line → 加载 VxWorks 映像 → 跳转内核入口 → 内核初始化 → 创建任务 → 启动应用。每一步都有对应的日志或可观察点。分析启动流程时，重点关注：BootROM 是否完成内存与网口初始化、映像是否成功加载、内核是否打印版本信息、应用任务是否创建成功。

下面用一张信号链与状态关系图，把“BootROM → 映像加载 → 内核启动 → Shell/调试代理可用”的关键路径和判断点串起来，便于在排障时快速定位卡点。

结合上图，排障时可以按“先看 BootROM、再看加载、再看内核、最后看 Shell 与调试代理”的顺序逐段确认。若 BootROM 阶段就失败，优先检查硬件与串口参数；若加载阶段失败，检查网络与文件路径；若内核启动后无 Shell，检查 Target Shell 组件是否被裁剪；若 GDB 连不上，检查代理是否启动、端口是否被占用、符号文件是否匹配。

启动流程中的常见问题与处理

第一类问题是 boot line 配置错误，表现为目标机反复重启或停在 BootROM 提示符。处理方式是进入 BootROM 命令行，用 c 修改 boot line，确认 h、e、f 字段与主机环境一致。第二类问题是 TFTP 加载超时，常见原因是主机防火墙拦截、TFTP 根目录权限不足、文件名大小写不匹配。第三类问题是 映像与硬件不匹配，例如为 ARM 编译的映像加载到 x86 目标机，表现为跳转后无任何输出。

第四类问题是 Target Shell 不可用，通常是因为内核配置中未包含 INCLUDE_SHELL 或串口驱动未正确初始化。第五类问题是 GDB 连接失败，需要确认调试代理是否随内核启动、端口是否与 GDB 配置一致、主机与目标机网络是否互通。对于 CI 环境，建议把上述检查点固化为启动自检脚本，在每次刷机后自动执行，减少人工判断。

掌握本节内容后，读者应能独立完成目标机的启动配置、串口与网络加载、WindSh/Target Shell 操作、GDB 调试代理连接，并能根据启动日志定位常见卡点。这些能力是后续自动化测试脚本编写与 CI 流水线搭建的基础。