
简介面向嵌入式开发者的VxWorks 6.8 VMware版板级支持包BSP用于在VMware虚拟机中快速搭建可编译、可调试的VxWorks实时系统开发环境尤其适合航空航天、工业自动化等领域需要边学习边验证的工程师。压缩包共70个文件约3.68MB以C语言源文件.c、头文件.h、汇编启动文件.s、目标文件.o、配置文件.cdf及构建脚本为主涵盖网络驱动、串口、SCSI、TFFS等常用模块。目前已有729人学习下载。该包免去了物理硬件环境配置可直接在VMware Workstation/Player中加载引导映像配合Workbench IDE进行驱动适配和应用程序开发对于想了解VxWorks虚拟化部署、BSP移植或快速搭建实验平台的开发者来说是一份减少重复踩坑的实用材料。 说实话第一次看到vmware-vxworks6.8.rar这个文件名的时候我第一反应是“这包是不是哪家培训机构流传出来的” 毕竟 VxWorks 平时更多地出现在军工、航天、工业控制这些场景里普通开发者接触的机会并不多。但拿到手解压之后我发现这里面其实是一套可以直接在 VMware Workstation 里运行的 VxWorks 6.8 环境。也就是说没有风河的硬件开发板没有昂贵的仿真器只要一台普通 PC 加一个 VMware 虚拟机就能把 VxWorks 6.8 拉起来跑还能连上 Wind River Workbench 做调试。这篇文章整理的就是我折腾这套环境的完整过程包括虚拟机的硬件选型、镜像引导、网络调试和几个让我卡了最久的坑希望能给正在搞嵌入式或者想研究 RTOS 的朋友省点时间。1. 压缩包里有什么VxWorks 在虚拟机里的价值1.1 为什么要在 VMware 里跑 VxWorks很多人会觉得 VxWorks 这种硬实时系统就应该待在板子上和 VMware 这种通用虚拟化平台八竿子打不着。但实际上在项目早期或者验证阶段能把 VxWorks 跑在虚拟机上价值很大不用等硬件拿到 BSP 和镜像就能开始跑驱动逻辑和应用层代码。方便多人共用一套环境测试机不用和开发板绑定。出了问题可以直接拍快照回滚调试效率比反复烧写开发板高不少。VxWorks 6.8 这个版本比较特殊它仍然保留了 5.x 时代的老式 bootrom 引导链路同时又加入了 Workbench 3.0 的工程体系和 VxBus 驱动框架。虚机环境里跑它踩的坑往往就在新老框架交替的边界上。1.2 解包后的环境构成我拿到这个 rar 之后看到里面并不是单一的一个镜像文件而是一整套虚拟机运行环境。解压之后通常会包含这几类文件vxWorks主镜像就是 VxWorks 内核编译出来的可执行文件启动后由 bootrom 负责加载到内存里执行。bootrom或bootrom_uncmp引导镜像负责初始化硬件、解压内核镜像。.vmx虚拟机配置文件这个很关键它直接决定了 VMware 把虚拟机识别成什么硬件形态。可能还有README.txt一般会写清楚这款镜像对应的 BSP、内存地址、默认的 WDB 连接方式等信息。需要特别提醒的是这类的 rar 包来源五花八门解压之后先别急着双击.vmx启动。先看 README确认一下这个镜像是用哪个 BSP 编译的最典型的区别在于网络驱动是amd芯片的还是intel e1000的这会直接影响后面虚拟机的网卡选型。我最开始就是没注意这一点默认选了vmxnet3网卡结果系统起起来之后网口识别不到白白折腾了一个多小时。2. VMware 虚拟机硬件配置虚拟硬件选型直接决定能不能启动2.1 关键硬件参数对照VxWorks 6.8 毕竟是针对嵌入式场景设计的系统对虚拟硬件的支持是有限度的VMware 默认的很多硬件配置对它来说并不是最优解。我最终稳定运行的配置如下硬件项推荐配置说明客户机操作系统Other (32-bit)VxWorks 是 32 位内核选 Other 即可不需要选任何 Linux/Windows 模板内存256 MB - 512 MB对 VxWorks 来说 256MB 已经绰绰有余给的太大反而可能触发某些 BSP 内存探测适配问题处理器单核即可6.8 的 SMP 支持需要特定组件默认镜像一般用单核跑硬盘SCSI 或 IDE8GB 以内如果你只是想把系统拉起来甚至可以不挂硬盘直接软驱或网络引导网络适配器E1000对应 Intel PRO/1000 芯片VxWorks 6.8 的 x86 BSP 自带驱动实测最稳软盘驱动器可挂载 bootrom 镜像这是启动的关键步骤之一详细见下一节2.2 串口与会话通道的配置VxWorks 的调试离不开串口。你可能会想虚拟机哪来的串口VMware Workstation 提供了“命名管道Named Pipe”支持可以把串口重定向到宿主机上的一个管道文件然后 Wind River Workbench 或者任意串口工具去连接这个管道就可以看到 VxWorks 的启动输出和 shell。创建虚拟机的时候添加一个“串行端口”选择“输出到命名管道”管道名按照 Windows 平台习惯写\\.\pipe\vxworks_com1另一端选择“另一端是应用程序”这样可以保证 Workbench 能连上这个管道。然后 VxWorks 启动过程中的串口调试信息就会输出到这里。这一步非常重要。VxWorks 不像 Linux 那样有 dmesg 可以事后查它启动早期阶段的输出只有串口这一条路。如果你没有配置好命名管道后面启动卡死了你都无从观察只能对着黑屏干瞪眼。我后续排查启动卡死问题靠的就是从串口管道里抓到的完整输出日志。提示命名管道和串口工具只能同时占用一端。如果 Workbench 连不上检查一下是不是已经有别的串口工具占用了这个管道。3. 镜像引导链路从 bootrom 到 vxWorks 是怎么“接力”的3.1 两阶段启动的原理VxWorks 的传统启动过程和 Linux 差别不小它是典型的两阶段引导第一阶段是bootrom初始化 CPU、芯片组、串口、网卡等硬件然后根据 bootline 引导参数从软驱、IDE 硬盘或者 FTP/TFTP 服务器上加载真正的内核镜像。第二阶段是vxWorks镜像在内存里解压、重定位然后执行usrInit初始化内核子系统最后创建第一个任务启动 shell。在 VMware 里操作的时候如果你拿到的是一个单独且完整的vxWorks镜像可以直接把软驱指向它来引导如果拿到的是bootrom vxWorks的组合那就需要先配置软盘镜像为bootrom再通过网络或磁盘加载镜像。我这次 rar 包里的镜像相对完整所以直接把软驱指向了引导镜像。虚拟机的启动顺序建议设置为“先尝试软驱再尝试硬盘”避免出现 VMware 直接试图从空白硬盘引导时报错。3.2 启动参数调优VxWorks 的 bootline 参数在 bootrom 里就定好了也可以在启动时按提示修改。常见的关键参数包括boot device: 引导设备类型网络引导就是feiIntel e1000 驱动或者elPciAMD PCNet软盘引导是fd。file: 要加载的 vxWorks 镜像文件名。host inet addr和target inet addr: 宿主机和目标机的 IP 地址。target name: 目标机名字方便 Workbench 识别。o: 启动标志位o1表示加载后不自动执行应用程序适合调试。我这次的 bootline 大概配置成这样boot device: fei processor number: 0 host name: host file name: vxWorks inet on ethernet (e): 192.168.137.10:0xffffff00 host inet address (h): 192.168.137.1 target name (tn): vxvm other (o): 0注意 IP 网段要和 VMnet 的网络一致。VMware 默认的 NAT 网段是192.168.137.x如果你的环境用了别的网段需要同步调整。3.3 启动卡死的判断方法VxWorks 启动过程中如果卡住了最常见的表现就是串口输出停在某一行。根据我的实际经验可以这样判断卡点卡在Loading...之后的Starting at 0x...前面说明 bootrom 没能完整加载 vxWorks 镜像优先检查网络连接、FTP 服务或者软驱镜像是够完整。卡在UsrRoot之后但 shell 没出现多半是内核某组件初始化时挂了可以串口输入i命令看已有任务列表或输入lkup查找符号表确认内核符号有没有正常加载。如果输出直接就没有几行大概率是串口参数不对VxWorks 默认串口波特率多为 9600 或 115200注意 RealTerm 等串口工具的参数要匹配。4. 打通调试链路用 Workbench 连接 VMware 里的目标机4.1 Wind River Workbench 与 Target ServerVxWorks 跑起来只是第一步真正开发调试还得靠 Wind River Workbench。它的调试原理是通过 Target Server 组件用 WDBWind Debug协议和目标机通信。最新版 Workbench 3.0 本身基于 Eclipse所以有过 Eclipse 经验的开发者上手会很容易。创建 Target Server 时需要配置后端连接方式网络或串口。目标机 IP 地址和 bootline 里配置的 target IP 一致。WDB 通信方式VxWorks 6.8 支持在config.h里配置 WDB 使用串口还是网络。我个人更推荐网络方式连接稳定性和速度都比串口好。不过如果网络起不来串口依然是兜底方案。4.2 宿主机与虚拟机的网络桥接要让 Workbench 从宿主机连上虚机里的 VxWorks前提是两者网络能通。VMware 有三种网络模式可以用NAT 模式虚机访问外网方便但宿主机到虚机的连接默认是被 NAT 隔离的需要配置端口转发才比较稳妥适合网络调试初期。桥接模式虚机直接和宿主机同一局域网Workbench 连接最自然也是我推荐的方式。Host-only 模式宿主机和虚机组成一个私密隔离网络外网不可达如果你只做本地开发调试这是最干净的方式。我最后用的是 Host-only 模式手动把宿主机虚拟网卡和虚机配置到了同一个静态网段保证两边 IP 固定不变。调试时最烦的就是 DHCP 动态变 IP容易把 Workbench 的 Target Server 连接弄挂。Target Server 连上之后Workbench 里会显示目标机的系统信息、任务列表、内存使用情况。这时你可以做的事情就很丰富了挂起任务、单步调 C 代码、查看内核数据结构、动态下载模块。整个调试手感和调试 Linux 内核模块差不多但实时性反馈更直接。4.3 一个容易忽略的防火墙问题宿主机上的 Windows 防火墙经常会默认拦截 Workbench 发起的网络通信尤其是它要往目标机监听端口主动建立连接时。如果你发现 Target Server 一直在“Connecting...”但网络 ping 是通的那就要重点关注宿主机防火墙是否放行了 Workbench 相关进程。我当时的处理方式是直接在防火墙高级设置里为 Workbench 的可执行文件添加“允许所有网络通信”的入站规则。开发调试用的宿主机这样配置问题不大。5. 排障实录我在这里卡了最久的三个问题5.1 虚拟网卡选型E1000 还是 VMXNET3这个坑我开头已经提过值得再展开细说。VMware Workstation 默认给新虚机里的虚拟网卡类型一般是 VMXNET3它属于 VMware 半虚拟化设备性能好但 VxWorks 6.8 的 x86 BSP 里根本没有对应的 open source 驱动。如果你选了这个启动后系统里ifconfig是看不到任何网口的。改成 E1000也就是 Intel PRO/1000之后VxWorks 6.8 自带的fei驱动可以直接识别。改法很简单编辑虚机.vmx文件找到ethernet0.virtualDev属性改成e1000重启虚拟机即可。注意修改 .vmx 前先把虚拟机完全关机否则 VMware 可能不认你手动改的配置。5.2 VxWorks 启动后没有串口输出这是我折腾最久的一个问题。VxWorks 在虚拟机里启动后Workbench 一直连不上 Target Server而在命名管道的另一端我也看不到任何输出。排查过程是这样走的先确认虚拟机的“串行端口”确实连接到了命名管道再确认波特率参数。结果都没问题。后来我在 VMware Workstation 的日志文件vmware.log里发现一条警告提示串口设备被挂起因为管道端的应用没有正常打开。实际上窗口开了不代表管道已经建立成功了。最终我发现问题出在打开顺序上。正确流程是启动串口监听工具确认管道一侧已经处于监听状态之后再开机启动虚拟里的 VxWorks。如果先开机再开监听VxWorks 已经完成了早期串口初始化但后续输出就没有往管道里送很容易被误判为系统卡死。5.3 VMware 报错无法连接到虚拟机请确保您有权运行该程序这个报错不是 VxWorks 特有的很多用 VMware Workstation 的朋友都遇到过。它通常发生在双击.vmx启动虚拟机时常见原因有两个当前 Windows 用户对虚拟机文件所在目录没有完全控制权限尤其是从下载工具或 rar 解压工具里拿到的文件经常被标记为“来自其他计算机”。VMware Authorization Service 服务没有启动或者被安全软件禁用了。处理很简单右键.vmx文件打开“属性”在“解除锁定”处打勾同时确保VMware Authorization Service在服务管理器里处于运行状态。我顺手把存放虚拟机的整个目录加到了文件和打印机共享例外里避免其他安全软件误拦截。5.4 一张排障速查表现象可能原因处理建议启动后没有打印任何输出串口管道未监听 / 串口参数不对确认管道端监听先于虚拟机启动核对 9600/115200 波特率卡在Starting at 0x...bootrom 无法加载 vxWorks检查软驱/网络引导配置确认 FTP 路径大小写ifconfig无网口虚拟网卡型号不兼容使用 E1000避免 VMXNET3Target Server 连不上网络不通 / 防火墙拦截使用 Host-only 模式固定 IP放行 WorkbenchWorkbench 连上但无法 attachbootline 中 WDB 参数未启用确认启动参数里有wdb...且与 Workbench 设置一致6. 把镜像固化进 vxWorks Image Project从“能跑”到“能开发”6.1 Workbench 里重建工程很多情况下你拿到的 rar 只是别人编译好的镜像想在这个环境里改内核组件、加驱动、调试自己的代码还得在 Workbench 里建立一个属于自己的 VxWorks Image ProjectVIP关联好 BSP 和源码包。在 Workbench 3.0 中新建 VIP 时选择你镜像对应的 BSP。如果 rar 包里的 README 没有标注 BSP可以通过镜像启动时的sysBspRev()或者 bootrom 输出来判断常见的是x86或pentium系列 BSP。把工程建好之后编译生成的vxWorks镜像就可以替换掉 rar 包里的同名文件重新放回软驱或者通过 FTP 加载相当于你把整个开发闭环打通了。6.2 内核组件裁剪的思路VxWorks 6.8 的内核很灵活很多功能是通过内核组件component来配置的比如 C 支持、网络协议栈、VxBus 驱动。在 Workbench 的vxWorks Image Project里你可以很方便地启用或禁用组件。一个实用经验在虚拟机环境里能关掉的组件尽量关掉。比如不用的文件系统、不用的网络协议模块关掉之后镜像体积更小启动速度更快也减少了不必要的符号表加载时间。最开始的镜像往往是“全家桶”跑起来没问题但调试一些严格时序相关的代码时会有额外干扰。6.3 符号表和调试信息VxWorks 的调试体验非常依赖符号表。如果 Workbench 连上之后看到的内存地址都是裸的十六进制那多半是符号表没加载。解决方法是在 Target Server 配置时指定 vxWorks 镜像对应的vxWorks.out或者.sym文件让 Host 端知道每个地址对应的符号名。这里也提醒一下从网上下载的镜像如果被人用strip处理过符号信息可能已经丢了那时候 Workbench 就只能做粗糙的内存调试没法直接单步到 C 代码。所以最好还是自己在工程里重新编译一个镜像出来开发体验会完全不一样。7. 一些操作层面的心得体会整个环境跑通之后我最大的体会是VxWorks 在虚拟机上跑性能和真实硬件上是有差别的尤其是涉及中断响应时间、缓存一致性这些环节不要用虚拟机测出的数据去论证实时性指标。但反过来跑应用逻辑、验证任务调度行为、调试驱动框架这些层面虚机环境的便利性真的无可替代。实际操作中我给虚拟机拍了一个“内核启动成功且网络正常”的快照。后面每次调试环境被我折腾坏了直接回滚快照一分钟就能恢复到一个干净的 VxWorks 系统这个开发效率提升是很直观的。最后再分享一个小技巧VMware 的快照恢复并不总是完美的有时候网络连接恢复后要等几秒。如果你刚好是用 Workbench 开机自动连接 Target Server建议把 Target Server 的“自动重连”间隔调大一点避免它在这个间隙报错然后一直显示连接失败。调好之后整个流程就顺畅多了。本文还有配套的精品资源点击获取