📚 课程目录第2章 VxWorks产品化部署环境搭建

2. VxWorks产品化部署环境搭建

VxWorks 产品化部署的第一步不是写代码，而是把“开发主机—交叉工具链—目标机—调试通道”这条链路搭稳。很多后续问题，例如镜像下载失败、符号表不匹配、串口无输出、网络引导超时，根源往往在环境搭建阶段就埋下了。本节围绕硬件选型、Workbench/VxWorks SDK 安装与授权、交叉编译工具链验证、网络与串口调试通道建立四个环节展开，目标是形成一套可复现、可验证的部署环境。

一、开发主机与目标机硬件选型

开发主机承担编译、链接、镜像生成、调试服务与文件服务等任务。VxWorks 7 的 Workbench 基于 Eclipse 框架，对内存和磁盘 I/O 较敏感。建议开发主机至少 16 GB 内存、512 GB SSD，CPU 主频 2.5 GHz 以上；若同时运行多个目标机调试会话或大型 BSP 编译，32 GB 内存更稳妥。操作系统优先选择 VxWorks 官方支持的 Linux 发行版（如 Ubuntu 20.04/22.04 LTS）或 Windows 10/11 专业版，避免使用滚动更新的发行版，以减少工具链兼容性风险。

目标机选型取决于产品形态。常见三类：一是评估板（如 NXP i.MX8、Xilinx Zynq、Intel x86 工控板），适合早期验证；二是自研单板，需确认 CPU 架构、内存布局、启动介质（NOR/NAND/eMMC/SD）、网络 PHY 与串口电平；三是虚拟目标机（VxWorks Simulator），适合无硬件时验证应用逻辑。选型时要重点核对：CPU 架构是否被 VxWorks 7 支持、BSP 是否可获得、启动方式是否与引导流程匹配、调试串口是否引出。若目标机使用 U-Boot 引导，还需确认 U-Boot 版本与 VxWorks 镜像格式（如 uImage、ELF）的兼容性。

二、Workbench/VxWorks SDK 安装与授权配置

VxWorks 7 的安装通常通过官方安装器完成，需要有效的许可证文件（license）。安装前先确认已获取对应版本的安装包与 license，并记录 license 中的主机 ID、到期时间与授权功能项。安装路径建议不含中文和空格，例如 /opt/windriver 或 D:\WindRiver。

安装过程大致分为：选择安装目录、导入 license、选择需要安装的组件（Workbench、VxWorks SDK、BSP、工具链）、等待解压与注册。安装完成后，Workbench 首次启动会要求指定 workspace，建议为每个项目单独建立 workspace，避免索引冲突。授权配置的关键是让 license 服务或本地 license 文件被正确识别。Linux 下常见做法是设置环境变量并启动 license 守护进程：

export LM_LICENSE_FILE=/opt/windriver/license/WRSLicense.lic
# 若使用 FlexLM，可启动 lmgrd
/opt/windriver/license/lmgrd -c /opt/windriver/license/WRSLicense.lic -l /tmp/lmgrd.log

验证授权是否生效，可在 Workbench 中打开 Help > About Workbench > Installation Details，查看已授权组件；或在命令行执行 vxworks -version 类命令，确认无 license 报错。若提示 “License not found”，优先检查环境变量、license 文件路径、主机 ID 是否与申请时一致。

三、交叉编译工具链验证

VxWorks 7 的工具链随 SDK 安装，通常位于 installDir/vxworks-7/host/<host>/bin 下，命名如 arm-linux-gnueabihf-gcc 或 wr-cc。验证分三步：确认工具链可执行、确认目标架构正确、确认能编译出目标格式的可执行文件。

# 查看工具链版本
arm-wrs-vxworks-gcc --version

# 编译一个最小测试程序
arm-wrs-vxworks-gcc -c hello.c -o hello.o
arm-wrs-vxworks-objdump -f hello.o

若 objdump 输出中 architecture 与目标 CPU 一致（如 arm、aarch64、i386），说明工具链基本可用。进一步可在 Workbench 中新建 VxWorks Kernel Image 工程，选择对应 BSP，执行 Build。若编译通过并生成 vxWorks 镜像，说明工具链、BSP 与 SDK 已正确联动。常见失败原因包括：BSP 未安装、工具链路径未加入 PATH、目标架构与 BSP 不匹配。

四、网络与串口调试通道建立

调试通道是目标机与开发主机之间的“生命线”。串口用于查看启动日志、进入 U-Boot、设置启动参数；网络用于下载镜像、挂载文件系统、运行调试服务。两者建议同时建立，互为备份。

串口连接：确认目标机调试串口电平（TTL 3.3V 或 RS-232），使用 USB 转串口模块连接开发主机。Linux 下设备通常为 /dev/ttyUSB0，Windows 下为 COMx。串口参数常见为 115200-8-N-1，无流控。可使用 minicom、picocom 或 PuTTY 打开：

picocom -b 115200 /dev/ttyUSB0

网络连接：开发主机与目标机应处于同一网段，或通过交换机直连。典型配置为开发主机 192.168.1.100/24，目标机 192.168.1.200/24。在 U-Boot 中设置目标机 IP、服务器 IP、网关与启动文件：

setenv ipaddr 192.168.1.200
setenv serverip 192.168.1.100
setenv gatewayip 192.168.1.1
setenv bootfile vxWorks
saveenv

开发主机侧需启动 TFTP 服务，将 vxWorks 镜像放入 TFTP 根目录。验证方法：在 U-Boot 中执行 ping 192.168.1.100，若返回 host 192.168.1.100 is alive，说明网络链路通；再执行 tftpboot 0x80000000 vxWorks，观察是否成功下载。若 ping 不通，检查网线、PHY 自协商、防火墙与 IP 冲突。

建议在环境搭建完成后，立即做一次“冷启动全链路验证”：目标机上电 → 串口输出 U-Boot 日志 → 网络下载 vxWorks → 内核启动 → 串口出现 VxWorks 登录提示。该过程能一次性暴露串口、网络、镜像格式与授权问题。

环境搭建完成后，建议形成一份简短的检查记录：开发主机 IP、目标机 IP、串口设备节点、工具链版本、SDK 版本、license 到期时间、TFTP 根目录、最近一次成功启动时间。这份记录在后续排障和产品化交付时能显著缩短定位时间。环境不是一次搭好就永久有效，系统升级、license 到期、网段变更都可能让链路失效，因此每次正式部署前做一次最小验证是必要的工程习惯。