4. 建立交叉编译与调试环境

VxWorks BSP 的移植工作，本质上是在宿主机上生成能在目标板上运行的引导代码与内核镜像，再通过板级通道把镜像送进目标板并观察其启动行为。因此，在动 BSP 源码之前，必须先把“编译—下载—运行—观察—调试”这条链路打通。本节围绕 Toolchain 安装、Workbench 工程配置、串口终端、TFTP/网络加载、JTAG 调试器连接与验证五个环节展开，目标是形成一条可复现的最小可用环境。

一、Toolchain 安装与版本对齐

VxWorks 7 的编译工具链由 Wind River 随 Workbench 一起提供，常见形态是 wr-cc 系列交叉编译器，例如面向 ARM 架构的 arm-wrs-vxworks7eabi-gcc。安装时需要注意三点：第一，工具链版本必须与目标 VxWorks 源码版本匹配，VxWorks 7 的 SR 版本（如 SR0620、SR0640）对应不同的 GCC 与 binutils 版本，混用会导致内核编译期出现头文件或 ABI 不兼容；第二，安装路径不要包含空格与中文，否则 Makefile 中的路径展开容易失败；第三，安装完成后应把工具链的 bin 目录加入 PATH，并用 wr-cc --version 或 arm-wrs-vxworks7eabi-gcc -v 验证。

# 示例：验证工具链可用性（路径按实际安装调整）
export WIND_HOME=/opt/windriver
export PATH=$WIND_HOME/wr7/arm/bin:$PATH
arm-wrs-vxworks7eabi-gcc -v
# 期望输出中包含 gcc version 与 target: arm-wrs-vxworks7eabi

若输出中 target 与目标板 CPU 架构一致，说明工具链本身可用。此时还不代表能编译 BSP，因为 BSP 编译还依赖 WIND_HOME、WIND_BASE 等环境变量指向正确的 VxWorks 源码树。

二、Workbench 工程配置

Workbench 是基于 Eclipse 的集成环境，BSP 工程通常以“VxWorks Image Project（VIP）”或“VxWorks Source Build（VSB）”形式存在。配置时先创建 VSB 工程，选择与目标板一致的 CPU 架构、工具链和内核配置（如 VIP_ARM_V7），再创建 VIP 工程并关联该 VSB。关键配置项包括：

• BSP 选择：在 VIP 的 Kernel Configuration 中指定目标 BSP 目录，例如 bsp/vxworks7/arm/xxx。
• 组件裁剪：至少保留 INCLUDE_NETWORK、INCLUDE_TFTP、INCLUDE_SHELL、INCLUDE_DEBUG，否则后续无法通过网络加载或进入调试。
• 启动参数：设置 bootline，典型形式为 motetsec(0,0)host:vxWorks h=192.168.1.100 e=192.168.1.10 u=target pw=vxworks，其中 h 为宿主机 IP，e 为目标板 IP。

配置完成后执行 Build，若能在 default/ 目录下生成 vxWorks 与 vxWorks.bin，说明工程配置与工具链已正确衔接。

三、串口终端与 TFTP/网络加载

串口是目标板最基础的观察通道。宿主机侧使用 minicom、PuTTY 或 screen 连接 USB 转串口设备，参数通常为 115200-8-N-1，无流控。连接后应能看到目标板上电时的 BootROM 输出，例如：

# 示例：串口终端连接
sudo screen /dev/ttyUSB0 115200
# 目标板上电后期望看到类似输出
VxWorks BootROM 1.0
Press any key to stop auto-boot...

网络加载依赖 TFTP。宿主机需启动 TFTP 服务并把 vxWorks 镜像放入根目录，目标板 BootROM 通过 bootline 中的 h= 指向宿主机。验证顺序建议为：先 ping 通宿主机与目标板，再在 BootROM 命令行执行 @ 或 boot，观察是否出现 Loading... 0x... 与 Starting at 0x...。若卡在 TFTP 阶段，优先检查防火墙、TFTP 根目录权限与文件名大小写。

四、JTAG 调试器连接与验证

当串口与网络加载都正常后，JTAG 用于更底层的调试，例如在 BootROM 阶段设置断点、查看寄存器、单步执行。以常见的 ARM 目标板为例，JTAG 调试器（如 Wind River Probe 或兼容的 FTDI 方案）需先安装驱动，再在 Workbench 的 Debug Configuration 中新建“VxWorks Kernel Task”或“Wind River Debug”连接，指定 CPU 类型、JTAG 时钟频率（示例：10 MHz）与复位方式（SYSRESET 或 CPU_RESET）。

验证时先执行“Connect”，若能在 Debug 视图中看到 CPU 寄存器窗口并读取到 PC 值，说明 JTAG 链路已通。随后可加载 vxWorks 符号文件，在 usrInit 或 sysInit 处设置断点，复位目标板，观察是否命中。若连接失败，按“驱动—线序—时钟—复位方式—目标板供电”的顺序排查，其中线序与供电是最常见的两个原因。

五、最小验证闭环与常见问题

把上述五个环节串起来，就形成一条最小验证闭环：工具链能编译出 vxWorks，Workbench 工程能生成镜像，串口能看到 BootROM 输出，TFTP 能把镜像加载到目标板，JTAG 能在 usrInit 处命中。任何一环失败，都会表现为“目标板无反应”或“启动卡住”，因此建议按以下顺序定位：

需要强调的是，本节的环境搭建不是一次性的准备工作，而是后续所有 BSP 调试的前提。只有串口、网络与 JTAG 三条通道都验证通过，才能在修改 sysClkRateSet、sysSerialHwInit 或中断控制器初始化代码后，快速判断问题出在 BSP 逻辑还是环境链路。因此，建议在正式移植前，先用一个已知可用的参考 BSP 走通整条链路，再替换为目标板 BSP，这样可以把“环境问题”和“BSP 问题”有效分离。