企业官网建设流程全解析

干了十几年的嵌入式开发，提到VxWorks这套东西，很多新入行的朋友可能一脸懵，但只要是搞过航天、军工、电力、轨交这些领域的老工程师，一听WorkBench 3.2加VxWorks 6.8的组合，基本都会心一笑——这正是当年用得最顺手、也是最后一代经典IDE与RTOS搭配之一。虽然Wind River后来推出了更新版本，但大量存量项目、老设备的维护和二次开发，依然牢牢钉在WorkBench 3.2和VxWorks 6.8这套环境上。我这几年帮同事搭环境、自己也重装了好几台机器，总结了不少安装细节和踩坑记录，今天干脆一次性写出来，给准备接手老项目、或者实验室里要搭VxWorks教学环境的同学做个完整参考。

这篇文章覆盖从环境准备、软件安装、许可证配置、目标机服务器配置，到第一个工程的创建、编译、烧写验证的全流程。无论你是在Windows真机、还是在VMware虚拟机里装，照着走基本都能跑通。文章里还会把安装过程中最常见的报错、坑点、排查方法整理成速查表，方便以后出问题时随手翻。

1. 安装前的准备工作

1.1 硬件、操作系统与虚拟机环境要求

先说硬件。WorkBench 3.2和VxWorks 6.8是2008年前后发布的工具链，对硬件的要求放在今天看其实很低，但也正因为老，反过来对“新”硬件有莫名其妙的挑剔。我建议至少满足这几个条件：

• CPU：双核以上即可，不需要高性能，安装过程比较吃单核主频，主频2.0GHz以上体验好一些。
• 内存：至少2GB，推荐4GB。编译大型工程时内存占用会明显上升，4GB才够从容。
• 磁盘空间：WorkBench 3.2安装完大约需要6GB左右，VxWorks 6.8组件安装完又要占4~6GB，再加上后续BSP、工程文件、补丁包，建议预留20GB以上空间。
• 网络：必须有一块物理网卡，或者虚拟机里配置好桥接网络。目标机调试是网络通信，网卡不稳定后面会非常头疼。

操作系统这块是最大的坑。这套工具链最完美的运行环境是Windows XP或Windows Server 2003，其次是32位Windows 7。如果你手头只有64位Win7、Win10甚至Win11，就别硬刚真机了，直接用VMware装一个Windows XP或Win7 32位的虚拟机，这是最省心的方案。我先后在Win7 64位和Win10上试过直接安装，结果不是注册表服务起不来，就是WorkBench启动时提示找不到Java虚拟机，折腾半天最后还是回到虚拟机。

用VMware时有个要点：虚拟机的网络模式必须选桥接，千万不要用NAT。原因很简单，目标机服务器需要在网络上广播和发现目标机，NAT相当于躲在路由器后面，目标板根本找不到主机，后面调试的时候会出现“目标机不可达”这种莫名其妙的错误。装完系统之后，建议先固定一个静态IP，然后关闭Windows防火墙和Windows Defender实时防护，这套老工具的服务端口都是自管理的，防火墙拦一下，服务就瘫了。

1.2 安装包识别与目录结构

WorkBench 3.2和VxWorks 6.8的安装包一般以光盘镜像（ISO）形式提供，有的项目组还会刻成实体光盘。拿到镜像后，先挂载或解压，确认里面几类关键内容都在：

• WorkBench 3.2安装程序，通常叫setup.exe或install_windows.exe；
• VxWorks 6.8安装程序，一般独立于WorkBench，在另一个镜像里；
• Patcher补丁工具及相关补丁包；
• 文档目录，包含Release Notes、Installation Guide、BSP说明书等；
• 许可证相关文件或License Server安装包。

我的习惯是先把镜像所有内容全部解压到一个纯英文路径下，比如D:\Workbench_Install，不要直接在虚拟光驱里双击安装，也不要放在带空格或者中文的目录里。这个工具链的安装程序对路径解析比较脆弱，路径稍微复杂一点，中间某个组件就会报错，而且是那种看不出原因的通用错误码。解压完以后，记得看一下镜像的总大小和文件完整性，如果文件缺失或者解压报错，后面安装到一半换盘是非常痛苦的。

另外建议在安装前先记下主机的MAC地址和CPU信息。WorkBench的许可证通常和主机绑定，生成license文件时需要用到hostid，不同的授权方式可能要求MAC地址或CPU序列号。先把这个记好，后面配置许可证能少走很多弯路。

2. WorkBench 3.2正式安装过程

2.1 安装步骤与关键选项解析

WorkBench 3.2的安装过程整体是向导式的，但有几个界面需要特别留意，选错了后续很麻烦。

第一步，找到解压目录里的setup.exe，右键以管理员身份运行。安装程序会先解压临时文件，然后进入欢迎界面。这里注意，有的镜像会带一个InstallAnywhere的引导程序，会先让你选择安装语言，选English即可，中文系统下选中文虽然界面友好，但偶尔会出现字体乱码和路径编码问题。

进入组件选择界面后，核心是勾选WorkBench主程序，以及配套的Host Tools、Simulator和文档组件。我的建议是：除了纯BSP相关的组件可以后面再补，其他能装的全部装上。尤其是Simulator，就算你现在不用，后面调试协议栈、验证工程时非常有用，可以在没有目标板的情况下先跑一个虚拟目标机。这个组件很多人安装时不勾，等到想用的时候又要重装一遍，非常浪费时间。

安装路径默认是C:\WindRiver，我建议就保持默认。这个路径会被写进很多环境变量和配置文件里，如果你改成D盘，必须保证路径纯英文且没有空格，比如D:\WindRiver，否则后续编译器调用、BSP编译脚本都会出问题。另外，安装的目标版本选择界面里，WorkBench 3.2的安装程序会同时提供VxWorks 6.8的安装入口，但我的经验是最好分开安装，先装WorkBench，再单独装VxWorks，两个一起装看起来省事，实际上安装日志混在一起，出问题了不好排查。

安装过程中，程序会注册几个Windows服务，主要是Wind River Registry和Wind River FTP Server。这时候Windows会弹出防火墙提示，一定要勾选“允许访问”，并选择“专用网络”和“公用网络”都允许。很多人在这一步点了取消，结果后面目标机服务器起不来，或者FTP下载镜像一直超时，排查了半天才发现是防火墙把服务端口全拦了。

安装结束后，先别急着启动WorkBench，到开始菜单里找到Wind River目录，确认WorkBench 3.2的快捷方式已经生成。接着打开命令提示符，输入wtxregd并回车，检查Wind River Target Server服务的注册状态，如果提示服务未注册，需要手动执行一次服务注册。这一步容易被忽略，但非常关键，目标机服务器能不能正常用就看这个服务了。

2.2 License服务器与许可配置细节

WorkBench 3.2的许可证机制是基于FlexLM的，安装好之后第一步就是要让它能找到合法的许可证。不少人在安装完软件后，兴冲冲启动WorkBench，结果界面一闪而过，或者提示“License not found”，多半就是许可证配置没做。

首先确认安装包里是否附带许可证文件，一般是一个license.lic文本文件，里面含一行SERVER和若干行FEATURE。如果没有现成的license文件，就需要通过主机hostid向Wind River申请，这个流程得提前走，因为邮件审批可能要几天。

然后是配置License方式，有两种常用方案。一种是本地文件方式，把license.lic放到一个固定目录，比如C:\WindRiver\license\license.lic，然后添加系统环境变量WIND_LICENSE_FILE，值填这个文件的完整路径。另一种是服务器方式，如果项目组有统一的License服务器，就把WIND_LICENSE_FILE设置为port@server_ip的格式，例如27001@192.168.1.10，这样所有开发机可以共用一套License。

我自己的经验是：单机开发用本地文件方式最省心。服务器方式虽然能共享授权，但一旦服务器宕机或者网络抖动，WorkBench启动会变得非常慢，甚至直接卡死。在目标板调试的关键时刻碰到这种事，真的会崩溃。

配置完环境变量后，需要重启系统让环境变量生效，或者至少重启WorkBench。启动后可以在Help菜单下找到License相关页面，查看实际的授权信息和到期时间。还有一个常见坑，就是同一台机器上装了多个Wind River产品，它们的环境变量会互相覆盖。比如之前装过其他版本的工具链，WIND_LICENSE_FILE被指向了旧版License，启动WorkBench 3.2时就会报版本不匹配。遇到这种情况，把环境变量统一指向新版License文件即可。

3. VxWorks 6.8安装与BSP集成

3.1 VxWorks组件安装及目录结构说明

WorkBench装好之后，接下来装VxWorks 6.8。VxWorks的安装程序一般会识别到已经安装的WorkBench版本，并自动把组件解压到C:\WindRiver\vxworks-6.8目录下。

安装时同样要注意组件选择。VxWorks 6.8的安装组件包括编译器工具链（GNU和Diab）、所有官方BSP包、目标机组件库、主机端工具等。我建议全选，因为这些组件加起来也就几个GB大小，后面做板级移植时说不定哪个BSP就能派上用场。尤其是GNU编译器，VxWorks 6.8所有的内核和BSP默认都是用GNU工具链编译的，不装的话连个空工程都编译不过。

安装完成之后，建议先熟悉一下C:\WindRiver\vxworks-6.8的目录结构。target\config\all目录存放的是架构无关的公共配置文件，target\config\<bspname>目录是各个具体BSP的源码和配置文件，target\lib目录是预编译的内核库和组件库。搞清楚这几个目录，后面改BSP、排查编译错误会轻松很多。

还有一个细节，VxWorks 6.8安装镜像里往往附带一个support或bsp文件夹，里面是额外的BSP包，这些包不会自动解压，需要手动拷贝到target\config目录下。很多人在官网下载了对应板卡的BSP，不知道该放哪，其实就是放在这个目录里。

3.2 如何正确选择BSP

BSP（Board Support Package）说白了就是一块目标板的“硬件抽象层”，它负责把VxWorks内核和具体的CPU、内存、串口、网卡等硬件隔离开。选BSP是整个安装过程中最关键的一步，选错了后续编译、启动都会出问题。

选择BSP首先要确定目标板的处理器型号和架构。VxWorks 6.8支持的BSP覆盖了x86、PowerPC、ARM、MIPS等主流架构，常见的有PENTIUM4（x86通用）、MV5100（PowerPC）、P2020RDB（PowerPC）、AT91SAM9260（ARM）等。如果你用的是开发板，包装盒或者手册上一般会写明推荐的BSP名称；如果是自己设计的板子，就需要根据CPU型号找到最接近的参考BSP，再通过修改config.h适配。

其次是确认目标板上的外设型号，尤其是网卡芯片。VxWorks的网络驱动是绑定在BSP里的，如果网卡型号与BSP自带的驱动不匹配，内核启动后网络接口就是死的，根本无法通过网络下载镜像。常见的Intel 82559、82574等网卡，在PENTIUM4 BSP里都有支持；如果是其他型号的网卡，就得找到对应BSP或者自己移植驱动。

看到一个BSP目录时，怎么判断它是否完整？我的检查方法是看三个文件：Makefile、config.h和bspname.h。Makefile定义了编译规则和依赖，config.h是整个BSP的配置中心，里面会涉及内存布局、启动参数、默认IP等，bspname.h则定义了板卡型号、时钟频率、外设基址等硬件参数。这三个文件都在，基本可以认定BSP是完整的。

如果你用的是VMware虚拟机加Simulator来学习，那就可以跳过BSP选择这一步，直接用SIMLINNT或SIMPC这类模拟器BSP。Simulator相当于在主机上跑一个虚拟VxWorks，不需要真实目标板，非常适合前期熟悉WorkBench环境和调试流程。

3.3 Patcher补丁工具的使用

装完VxWorks 6.8之后，强烈建议接着把官方补丁打上。很多人的VxWorks跑着跑着出现网络栈崩溃、文件系统异常，或者编译器生成代码有莫名其妙的问题，其实都是因为没打补丁。VxWorks 6.8从发布到生命周期结束，官方陆陆续续出了十几个补丁包，修复了大量已知问题。

Patcher工具一般在WorkBench的安装目录下，可以通过开始菜单的Wind River Patcher启动。它的使用逻辑很简单：选择需要打补丁的产品（比如VxWorks 6.8），然后加载从官网下载的补丁包文件（一般是.zip格式），最后把补丁安装到对应安装目录。

打补丁时要注意几个细节。第一，补丁必须在所有开发任务暂停的时候打，因为补丁会替换编译器、内核库和BSP文件，如果此时有工程正在使用这些文件，打补丁会失败。第二，打完补丁后，以前编译过的工程必须全部重新编译，不能复用旧的.o文件，否则链接时会出现符号版本不匹配的错误。第三，Patcher本身也有版本要求，老版本的Patcher可能不识别新补丁包，必要时需要先升级Patcher工具。

如果项目组里有多台开发机，补丁包最好统一管理和分发。我见过有的项目因为某台机器没打补丁，编译出来的内核在目标板上跑起来行为不一致，排查了一周最终发现是补丁版本差异导致的。这种问题特别隐蔽，值得从一开始就规范起来。

4. 目标机服务器配置与第一个工程的完整验证

4.1 目标机服务器的作用与配置方法

WorkBench和目标机之间的通信，全靠目标机服务器（Target Server）这个中间人。可以把它理解成一个翻译官：WorkBench里的调试指令通过它翻译成目标机能够理解的协议包，目标机上报的状态信息也通过它回传给WorkBench。它集成了FTP服务、Telnet服务、调试代理和符号表管理等功能，配置不正确的话，后面所有调试都没法进行。

打开WorkBench，在菜单栏找到Target -> Target Server Configurations，新建一个配置。连接方式通常选Network，这两项比较容易困惑：Backplane是VxBus背板方式，只在特定硬件上使用；Network则适用于所有带网卡的板卡，包括Simulator。

网络连接的关键参数包括：目标机IP地址、主机IP地址、FTP用户名和密码。VxWorks的默认FTP账号通常是target，密码也是target。如果在BSP的config.h里修改过默认密码，这里需要保持一致。端口方面，目标机服务器默认监听1534端口，主机端使用FTP的21端口，确保这些端口没有被其他程序占用。

如果是用Simulator，目标机服务器配置更简单，直接选择对应的模拟器BSP，WorkBench会自动创建一个虚拟网络接口。不用设置IP地址，Simulator内部会自动分配，适合初学者快速上手。

4.2 创建并编译第一个VxWorks工程

环境就绪后，我们来创建一个工程，把全流程验证一遍。

打开WorkBench，File -> New -> VxWorks Image Project，输入工程名，选择对应的BSP。如果这里找不到你的BSP，说明BSP没有正确安装到target\config目录，或者WorkBench没有刷新BSP列表，重启一次WorkBench一般就能解决。

创建工程后，WorkBench会显示VxWorks组件配置界面。这里默认配置已经可以编译出一个最小内核，但为了后面调试方便，建议在组件面板里手动勾选几个常用组件：telnet server、ftp server、Shell（命令行）组件。这些组件不勾选也能跑，但少了它们，你就只能通过WorkBench的图形调试界面看状态，想直接在目标机上敲命令就不行了。

编译前还要确认一下构建目标。VxWorks工程默认会生成vxWorks这个内核镜像，如果需要生成bootrom引导程序，可以在Build Target里选择bootrom或bootrom_uncmp。bootrom的作用是把内核从主机或Flash加载到内存，网络启动方式下必须先用bootrom引导，再下载vxWorks镜像。

点击Build按钮，编译开始。第一次编译会比较慢，尤其是Simulator工程，可能要好几分钟。编译过程中注意观察Console窗口的输出，看到Creating vxWorks ... done或者类似信息，说明编译成功。如果报错，优先检查BSP路径、编译器路径和磁盘剩余空间。WorkBench的编译器路径是在安装时自动写入的，如果之前修改过WindRiver安装目录，这里很容易出问题。

我个人建议工程目录不要放在C:\WindRiver里面。默认工程路径在C:\WindRiver\workspace下，但老工具链对工作空间里的中文路径支持不好。我一般单独建一个workspace目录，比如D:\VxWorks_Workspace，这样工程文件、生成的镜像都不跟工具链混在一起，备份和迁移也方便。

4.3 目标板启动与调试连接验证

工程编译通过后，开始板级联调。先把目标板的串口线、网线都接好，目标板通过串口输出启动日志。设置目标板从网络启动，上电后bootrom引导程序会在串口终端打印启动信息，此时迅速按键盘上的空格键或其他指定按键，进入启动行配置界面。

启动行（boot line）是VxWorks引导时最关键的一串参数，大致长这样：

motetsec(0,0)host:vxWorks h=192.168.1.10 e=192.168.1.11 u=target pw=target tn=target

解释一下这串参数的含义：motetsec(0,0)表示使用第0个网卡的第0个接口；host:vxWorks表示从主机下载名为vxWorks的镜像文件；h=指定主机的IP地址；e=指定目标机自己的IP地址；u=和pw=是FTP登录的用户名和密码；tn=是目标机名称。在启动行界面里，把这些参数改成你的实际环境，保存并重启，bootrom就会通过FTP从主机下载vxWorks镜像并跳转到内核入口执行。

此时回到WorkBench，在Target Server配置中启动之前配置好的目标机服务器，等目标机屏幕上出现VxWorks的shell提示符->，说明内核已经跑起来了。在WorkBench里，你可以尝试连接这个目标机，建立调试会话。连接成功后，左侧的Target Explorer里能看到任务列表、内存信息，在命令行窗口里敲i可以查看当前运行的任务列表。

我第一次搭这个环境时，卡在目标板下载镜像这一步整整一天，后来发现是FTP服务没启动。WorkBench自带的FTP服务器需要在服务列表里启动，而且启动前要确保防火墙放行。这个环节出的问题最多，后面的排查章节我会展开讲。

5. 常见问题与排查技巧实录

5.1 典型报错速查表

装了这么多年环境，我把最常见的报错和解决办法整理成了速查表，遇到问题可以先对照排查：

这个表只是一份入门速查，实际项目中的问题往往更隐蔽，需要结合日志和硬件环境具体分析。

5.2 几个必须牢记的经验心得

根据我反复装环境踩过的坑，有几个经验可以免费分享给后来人。

第一个心得：不要在64位系统上浪费时间。网上有各种WorkBench 3.2在64位Win7下的“破解”安装方法，说实话，绝大多数都是碰运气，即使装上了，后续调试过程中也可能出现各种诡异问题。用虚拟机装一个32位Windows XP或Win7，运行效率足够高，稳定性和兼容性却是真机没法比的。做嵌入式开发，稳定压倒一切。

第二个心得：每次修改BSP的config.h或者config.bat前，一定要先备份。VxWorks的BSP配置文件里一个标点错误就可能导致整个内核编译失败，而且错误信息常常晦涩难懂。备份一个原始版本，改了出问题还能快速回退，不然只能重新解压安装包，费时费力。

第三个心得：如果条件允许，给项目组配置一台统一的License服务器，并且做好License文件的版本管理。很多项目组用我前面说的本地License方式，每台机器一个文件，时间一长就乱了。谁改了文件、什么时候到期的，完全没有记录。统一管理之后，新同事入职配环境，只需要把环境变量指到License服务器，十分钟就能搞定。

第四个心得：网络环境一定要固定。我见过不少项目组开发机的IP是DHCP动态获取的，今天能连目标机，明天路由器一重启，IP变了，目标板的启动行参数也得跟着改。更麻烦的是，目标板往往没有键盘，只能通过串口进入启动行修改，操作繁琐还容易出错。建议把开发机IP固定下来，目标板IP也固定下来，能省掉无数额外的工作量。

6. 老环境的新心得

最后再分享一点个人体会。像WorkBench 3.2和VxWorks 6.8这套组合，技术上虽然已经不算前沿了，但在存量项目维护和特定行业应用中仍然是主力工具。每当我需要在一台新机器上把整套环境搭起来时，我都会先静下心确认操作系统版本、网络模式、许可证这些前置条件，而不是急着双击安装程序往前冲。前置条件确认好了，后面的安装通常一气呵成。

做嵌入式开发这么多年，我越发觉得，环境搭建这件事，慢就是快。今天图省事跳过了一个检测，后面可能要花几倍的时间去排查。希望这篇教程能帮你一次就把WorkBench 3.2和VxWorks 6.8的环境跑起来，少走一点弯路。如果你在安装过程中碰到什么这里没提到的奇怪问题，欢迎在评论区留言，我看到后会尽量给出排查建议。