企业官网建设流程全解析

简介：面向嵌入式开发者的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 默认的很多硬件配置对它来说并不是最优解。我最终稳定运行的配置如下：

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: 引导设备类型，网络引导就是fei（Intel e1000 驱动）或者elPci（AMD PCNet），软盘引导是fd。
• file: 要加载的 vxWorks 镜像文件名。
• host inet addr和target inet addr: 宿主机和目标机的 IP 地址。
• target name: 目标机名字，方便 Workbench 识别。
• o=: 启动标志位，o=1表示加载后不自动执行应用程序，适合调试。

我这次的 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 Server

VxWorks 跑起来只是第一步，真正开发调试还得靠 Wind River Workbench。它的调试原理是通过 Target Server 组件，用 WDB（Wind 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 一张排障速查表

6. 把镜像固化进 vxWorks Image Project：从“能跑”到“能开发”

6.1 Workbench 里重建工程

很多情况下你拿到的 rar 只是别人编译好的镜像，想在这个环境里改内核组件、加驱动、调试自己的代码，还得在 Workbench 里建立一个属于自己的 VxWorks Image Project（VIP），关联好 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 的“自动重连”间隔调大一点，避免它在这个间隙报错，然后一直显示连接失败。调好之后，整个流程就顺畅多了。

本文还有配套的精品资源，点击获取