简介：这是一份面向嵌入式底层开发者的VxWorks基于ARM9（S3C2410X）的BSP资源包，适用于需要完成BSP移植、驱动调试或学习板级支持包构建的工程师与学生，也可作为嵌入式系统课程设计和毕业设计的参考资料。包内共37个文件，主要包括C源码、H头文件、汇编启动文件、目标文件、配置文件、Makefile及README说明，整体约1000KB，结构上覆盖了串口、中断控制器、定时器、CS8900A网卡驱动等关键模块。已有188人学习下载，说明该包在同类资源中具备一定参考价值。通过阅读源码和配置，可以梳理从ROM启动、系统时钟初始化到设备驱动注册的完整流程，理解S3C2410X内存布局与中断映射，以及驱动编写和调试方法；包内包含编译链接所需的Makefile与目标文件，便于直接进行交叉编译和烧写测试，为二次开发和问题排查提供可对照的实例。 干这行的都清楚，VxWorks的BSP（Board Support Package，板级支持包）开发看着不复杂，但真上手弄过基于ARM9的BSP，才算把嵌入式底层这块骨头啃明白。很多刚接触VxWorks的朋友，手里拿一块ARM9开发板，比如经典的S3C2440，装个Tornado或者Workbench，第一反应是“我直接从网上找个BSP下来改改不就行了？”——实际做完你就会发现，BSP不只是“启动代码+驱动”那么简单，它决定了一个实时操作系统能不能在你的硬件平台上稳定跑起来。
这篇文章我就拿ARM9平台为主线，带大家把VxWorks的BSP开发完整走一遍，从整体架构、启动流程、核心文件，到实操中的下载调试和避坑经验，一次讲透。无论你是学校课程项目要做BSP实验，还是工作中接手了一块新板子需要移植VxWorks，这篇内容都能给你一个可参考的完整思路。
1. BSP整体设计与思路拆解
1.1 BSP到底是什么，为什么不能随便改改就用
BSP的全称是Board Support Package，它的作用是在VxWorks内核和具体硬件之间搭一座桥。说得直白点，VxWorks内核并不知道你用的CPU是ARM9还是PowerPC，它只管任务调度、消息队列、信号量这些东西。而BSP负责把“抽象的VxWorks”变成“你板子上能跑的VxWorks”。
很多人有个误解，觉得BSP就是把启动代码加驱动文件，配置一下就行。但实际BSP要完成的事情很多：CPU初始化（关中断、设置异常向量表）、内存映射（MMU/TLB配置）、时钟和定时器初始化、串口驱动（用于调试输出）、中断控制器初始化、总线设备枚举，以及把VxWorks镜像从Flash加载到内存并跳转执行。任何一个环节出问题，系统都起不来，而且调试难度很大，因为这时候还没有操作系统帮你打日志。
ARM9和X86平台最大的区别在于，ARM9的存储结构是统一编址的，外设寄存器通过地址访问，没有独立的I/O空间。所以BSP里大量工作就是对着芯片手册查寄存器地址，然后正确配置它们。以S3C2440为例，它内部有GPIO、UART、DMA、中断控制器、定时器等模块，每个模块都有各自的基地址和寄存器偏移，BSP要做的事情就是把这些寄存器配置成VxWorks期望的状态。
1.2 为什么选择ARM9作为BSP开发的学习平台
虽然现在Cortex-A系列处理器已经很普及，但ARM9依然是学习BSP开发非常好的平台。原因有三点：第一，ARM9架构没有像Cortex-A那么复杂的GIC（通用中断控制器），中断管理相对简单，适合理解中断处理的本质；第二，ARM9的MMU和Cache机制比Cortex-A简单，配置起来容易调通；第三，大量的ARM9开发板（如S3C2440、AT91RM9200）都有公开的BSP源码和参考资料，遇到问题好排查。
ARM9中的典型代表S3C2440，主频400MHz，有独立的16KB指令Cache和16KB数据Cache，支持MMU，跑VxWorks完全够用。而且S3C2440的启动方式支持NOR Flash启动和NAND Flash启动两种方式，这对理解BSP中镜像加载逻辑非常有帮助。
2. 核心文件解析与配置要点
2.1 VxWorks BSP的目录结构和关键文件
拿到一个VxWorks BSP，你会看到一整套文件，看上去很杂，但实际上可以分成几类：
第一类是启动代码，典型文件是romInit.s和romStart.c。romInit.s是汇编写的，它是CPU复位后执行的第一段代码，负责最基本的初始化：设置CPU模式、关闭中断、初始化堆栈指针。romStart.c是C语言入口，负责把镜像从Flash拷贝到RAM，并跳转到usrInit。这一段是整个BSP中最关键的部分，因为它涉及代码重定位和内存初始化。
第二类是系统初始化文件，典型是sysLib.c、sysHwInit.c、sysHwInit2.c。sysLib.c主要是提供sysPhysMemDesc[]这样的内存映射描述表，告诉VxWorks内核你的板子物理内存如何映射到虚拟地址空间。sysHwInit.c负责初始化各个硬件设备的中断、寄存器状态，它是VxWorks启动早期调用的，这个时候中断还是关闭的。
第三类是配置文件，最重要的是config.h。这个文件里有大量宏定义，比如DEFAULT_BOOT_LINE（默认启动参数）、RAM_HIGH_ADRS和RAM_LOW_ADRS（内存地址布局）、INCLUDE_MMU（是否使能MMU）等。改BSP有七成的时间是在改这个文件。
还有一类是Makefile，它控制整个BSP的编译链接过程。VxWorks的Makefile继承了Wind River提供的一套规则框架，一般不需要从头写，但需要根据你的板子修改一些变量。
2.2 config.h中那些绕不开的关键配置项
config.h是整个BSP配置的核心，它同时作用于bootrom和vxWorks镜像。我第一次做ARM9的BSP配置时，最容易搞混的就是几个内存地址相关的宏：
RAM_LOW_ADRS表示VxWorks内核镜像在RAM中的加载地址，RAM_HIGH_ADRS表示系统内存堆的最高地址，这两个值直接决定了VxWorks能不能正确在RAM中解压缩和运行。对于S3C2440这种通常有64MB SDRAM的板子，常见设置是RAM_LOW_ADRS = 0x30000000 + 0x1000，RAM_HIGH_ADRS = 0x30000000 + 0x04000000。
另外一个容易出错的地方是DEFAULT_BOOT_LINE。这一行字符串指定了启动设备、启动文件、主机IP、目标机IP等信息。比如：
"tffs0(0,0)host:/vxWorks h=192.168.1.10 e=192.168.1.11 u=target pw=target o=ae"如果在没有网络环境的情况下调试，可以用串口下载或者直接从Flash启动，配置方式就完全不同。建议刚开始调试时先把启动参数配成从Flash加载，避免网络问题干扰判断。
2.3 中断控制器和定时器：ARM9 BSP最容易翻车的地方
ARM9平台的BSP中，中断控制器和定时器的初始化是排查问题周期最长的部分，没有之一。
S3C2440的中断控制器支持60多个中断源，分成了两个子中断组。BSP的sysHwInit2中，你需要先关掉所有中断，然后逐个注册ISR，再在sysHwIntEnable中使能对应的中断源。VxWorks对中断处理的方式是：所有的中断都会先进入一个统一的入口——intEnt，然后由VxWorks内核分发到注册的handler。所以BSP需要提供intEnt的地址给内核，这个是通过INCLUDE_INT_CONTROL和相关的宏配置的。
定时器也容易踩坑。VxWorks的系统时钟（system clock）和辅助时钟（auxiliary clock）在ARM9平台通常使用不同的硬件定时器。系统时钟用的是PWM定时器0，辅助时钟用的是定时器3或4。如果系统时钟没有配置好，VxWorks的tick不会跳动，表现出来就是taskDelay永远不返回，任务调度看起来像卡死了一样。
3. 实操过程：从零配置ARM9的VxWorks BSP
3.1 环境准备与工具链选择
做VxWorks BSP开发，第一个决策是选择开发环境。老牌的选择是Tornado 2.2，它支持VxWorks 5.5，对ARM9的支持比较成熟，缺点是运行在Windows XP这种老系统上。新一代的是Workbench 3.0，支持VxWorks 6.x，界面更现代，但配置复杂度也更高。
我的经验是，如果只是学习BSP原理，用Tornado 2.2 + VxWorks 5.5 + ARM9的经典组合是最省心的，因为这个组合的资料非常多，踩坑之后容易搜到解决方案。工具链方面，Tornado自带了ARM交叉编译器（arm-elf-gcc等），不需要额外安装。
除此之外，你还需要一个调试终端工具。串口调试用SecureCRT或者Putty都可以，关键是波特率要和BSP中配置的一致，S3C2440平台常见的是115200bps。
3.2 建立BSP工程与编译流程
在Tornado中新建BSP工程，一般选择“Create a bootable VxWorks image”类型的工程，然后选择从已有的BSP模板复制一份出来。如果你用的开发板没有现成的BSP，就找一个最接近的模板复制，然后逐步修改。
我常用的方法是：先把工程建好，用默认配置编译一遍，确保最小系统能跑起来；再逐个添加组件，每加一个就编译、下载、测试一次。千万别一次性把所有驱动和组件都勾选上，出了问题你根本不知道是哪个环节导致的。
编译之前，要重点检查Makefile中的CPU类型和工具链前缀。对于ARM9，CPU应该设为ARMARCH5或者ARMARCH4，取决于具体内核。S3C2440是ARM920T，对应ARMARCH5。如果CPU类型配错，编译出来的镜像在启动早期就会崩溃，而且往往没有任何输出。
3.3 启动流程的逐步验证
新板子BSP调试，最核心的事情是验证启动流程的每一步。我习惯按照以下顺序来验证：
第一步，验证romInit.s能跑通。下载bootrom到Flash，上电后看串口有没有输出。哪怕是最简单的“Uncompressing...”也算成功一半了。如果完全没有输出，先查串口寄存器配置，再看时钟初始化是否正确。
第二步，验证romStart.c的拷镜像流程。这里往往会遇到两个问题：一个是源地址和目的地址配置不对，导致拷贝后程序跑飞；另一个是解压缩算法不匹配，导致跳转后崩溃。
第三步，验证usrInit和usrRoot。在VxWorks的启动流程中，usrInit会调用sysHwInit来初始化硬件，然后创建usrRoot根任务。这个阶段如果出现问题，可以通过在usrInit中添加printf来定位到具体卡在哪个函数。虽然这种方法比较土，但在系统还没有完整起来之前，printf是最可靠的工具。
第四步，验证定时器tick是否正常。启动完成后，在shell里执行“i”命令查看任务列表，同时观察系统时钟是否在跳动。如果时钟不跳动，重点检查定时器0的寄存器配置和中断是否已经使能。
3.4 内存映射与MMU配置实战
ARM9平台开启MMU之后，VxWorks访问外设就需要依赖sysPhysMemDesc[]中的映射关系。S3C2440的内存布局中，SDRAM位于0x30000000开始的地址区间，各种外设寄存器起始地址各不相同：GPIO在0x56000000，UART在0x50000000，中断控制器在0x4A000000。
sysPhysMemDesc[]的典型写法是把整个物理地址空间映射到相同的虚拟地址空间，也就是恒等映射。对于S3C2440，可以这样配置：
PHYS_MEM_DESC sysPhysMemDesc[] = { {0x00000000, 0x00000000, 0x10000000, VM_STATE_MASK_VALID | VM_STATE_MASK_WRITABLE | VM_STATE_MASK_CACHEABLE}, {0x30000000, 0x30000000, 0x04000000, VM_STATE_MASK_VALID | VM_STATE_MASK_WRITABLE | VM_STATE_MASK_CACHEABLE}, {0x48000000, 0x48000000, 0x28000000, VM_STATE_MASK_VALID | VM_STATE_MASK_WRITABLE}, {0x56000000, 0x56000000, 0x01000000, VM_STATE_MASK_VALID | VM_STATE_MASK_WRITABLE}, };这里面有一个很重要的细节：SDRAM映射为Cacheable可以提升性能，但外设寄存器所在的内存区域一定不能设置为Cacheable。如果把外设寄存器映射成Cacheable，你会遇到一个很诡异的问题：往串口发送寄存器写数据，第一次写不出去，要写第二次才能发出来。原因是第一次写入的数据停留在Cache里，没有被立刻写回外设。
3.5 串口驱动的实现细节
串口是BSP调试的生命线，几乎所有早期调试都靠串口输出。S3C2440的UART控制器有三个通道，BSP中至少要实现uart16750或者类似的串口驱动接口，并且要支持VxWorks标准的sysSerialTtyConnect。
串口初始化需要配置波特率、数据位、停止位、校验位。S3C2440的波特率设置比较特殊，它需要通过一个除法器寄存器UART_BRDIV来计算，计算公式是：
UBRDIV = (PCLK / (波特率 * 16)) - 1如果主时钟PCLK是50MHz，波特率116200（实际是115200笔误，正确的是115200），那UBRDIV大概是26。算错这个值，串口会输出乱码。我之前就遇到过，串口输出全是一堆“@#￥%&”这样的乱码，排查半天发现是PCLK频率算错了——实际PCLK是66MHz而不是50MHz，重新计算之后乱码就消失了。
4. 常见问题与排查技巧实录
4.1 系统启动无任何输出的排查思路
这是BSP调试中最常见的问题，也是让人最头疼的问题。我总结了一个排查顺序：先看电源和复位，用示波器量一下复位引脚有没有正常拉高；再看时钟，ARM9通常需要外部晶振提供时钟源，检查晶振是否起振，PLL锁相环配置是否正确；然后看串口接线，S3C2440的TXD/RXD是否交叉连接正确；最后才是看代码。
代码层面的排查重点是romInit.s。因为bootrom是烧在NOR Flash里面的，CPU复位后从0x00000000地址取指令。你需要确认这条路径上有没有被MMU干预。虽然在romInit阶段MMU通常还没有开启，但如果代码里错误地提前使能了MMU，就会导致PC跑飞，无任何输出。
一个非常实用的技巧是：在romInit.s的关键步骤之间添加板载LED的翻转代码，用示波器看LED引脚的电平变化来定位卡死位置。这比猜代码快得多。
4.2 vxWorks镜像加载后崩溃的定位方法
有时候bootrom已经正常跑起来了，引导信息也打印出来了，但解压完vxWorks镜像跳转执行之后就崩溃。这种问题往往涉及内存地址的匹配问题。
首先检查config.h中RAM_LOW_ADRS的配置是否和链接脚本一致。如果在Tornado的工程设置中，vxWorks镜像的链接地址是0x30100000，而实际镜像被加载到了0x30000000，跳转之后第一条指令就会访问错误地址导致异常。
其次检查镜像是否完整。可以通过对比Flash中镜像的大小和config.h中配置的RAM大小来判断，如果镜像超过了实际RAM大小，那么加载过程中末尾的数据会丢失，运行到后期必然崩溃。
还有一个容易被忽视的问题是：栈溢出。VxWorks的启动阶段，从romInit到usrInit，使用的是临时栈，栈的大小在romInit.s中定义。如果栈设置太小，函数调用层级一旦加深就会溢出，表现为启动到某一步突然死机。解决方法是在usrInit之前把栈加大，或者先跳到一个简单的C函数中测试栈是否够用。
4.3 任务创建不起来或任务调度异常的排查
系统能起来，但用户任务创建后就崩溃，或者任务调度异常，这类问题通常和定时器、中断优先级配置有关。
先检查系统时钟中断号是否注册正确。S3C2440的PWM定时器0中断号是INT_TIMER0（通常为10），如果注册成了INT_TIMER1，中断永远不会触发，系统tick就不会跳动。
再检查中断优先级配置。S3C2440的中断控制器支持优先级仲裁，如果系统时钟中断和串口中断的优先级配置不当，可能出现在高负载情况下定时器中断一直被串口中断打断，造成系统时间漂移。
最后检查任务栈大小。VxWorks中每个任务都有独立的栈，如果自定义任务的栈设置太小，任务运行到深层函数调用时会栈溢出。ARM9平台可以开启栈溢出检测功能，在config.h中定义INCLUDE_STACK_CHECK，这样栈溢出时会打印警告信息，便于定位问题。
4.4 网络不通时的配置检查清单
网络是VxWorks调试中另一个高频问题来源。如果目标机连不上主机，从以下三个方面排查：
第一，确认网络接口驱动已加载。在shell中执行ifconfig命令查看网络接口是否存在。如果没有网络接口，检查config.h中是否包含了INCLUDE_END，以及END驱动是否正确绑定了网络控制器芯片，比如DM9000或CS8900。
第二，确认IP地址配置正确。通过DEFAULT_BOOT_LINE或nvRam中的参数来设置目标机IP。注意目标机和主机的IP必须在同一网段，而且不能有地址冲突。
第三，确认物理层连接正常。ARM9平台常用的网络接口芯片有些需要EEPROM来存储MAC地址，如果EEPROM中的数据有问题，网络接口虽然能初始化但收不到数据包。调试时可以先用tftp命令测试目标机向主机发起传输，看看能否双向通信。
5. 实操心得与经验总结
5.1 一个完整的BSP开发流程复盘
把ARM9平台的VxWorks BSP从头做一遍，整个流程可以归纳为六个阶段：环境准备、模板复制、最小系统调试、硬件设备驱动、网络功能验证、系统集成测试。最忌讳的就是跳步——还没验证串口输出就急着调网络，出了问题永远不知道是底层问题还是上层问题。
我在实际项目中通常按70%的工作量花在调试上，30%花在编码上来规划。其中调试的70%里面，又有超过一半的时间是在做“起点验证”——确认某个功能从最基础的寄存器配置开始就是正确的。
做BSP开发，学会“反向推理”很重要：如果串口没输出，不一定是串口驱动的问题，可能是系统时钟没起来导致CPU根本没有执行到串口初始化代码；如果网络不通，不一定是网卡驱动的问题，可能是内存映射导致DMA缓冲区地址出错。从一个现象推理到可能的多个原因，再逐一验证排除，这种思路是BSP调试的核心能力。
5.2 常见工程管理经验
版本管理要尽早做。BSP代码涉及大量配置改动，一个config.h的改动可能导致行为完全变化。每完成一个阶段的调试，就提交一次代码，写清楚改动内容和验证结果。这样后续如果改出问题，可以快速回退。
对于团队协作的场景，必须统一工具的版本。Tornado 2.2和Workbench生成的BSP工程结构不同，交叉编译器版本也不同，混用会导致代码风格和编译选项不一致。建议整个团队使用相同的开发环境，包括补丁版本也要统一。
日志规范要从第一天就建立起来。BSP的调试信息应该分级管理：基本的启动日志、详细的初始化日志、调试用的寄存器读写日志。在sysHwInit阶段用串口直接输出，在系统运行后用logMsg输出到shell。合理的日志设计能让问题排查效率提升一倍以上。
5.3 最后再分享一个调BSP的实用技巧
提一个很多文档不会细说的小技巧：在调试ARM9的BSP时，善用看门狗。S3C2440内置了看门狗定时器，它不仅可以防止系统卡死，还能在调试阶段作为定位工具使用。比如你怀疑某段代码执行时间过长，可以在代码块前开启看门狗，设置一个较短的超时时间，如果这段代码卡住了，看门狗就会复位系统，通过复位原因寄存器来判断是不是这里导致的。
这个方法尤其适合定位那种“系统跑着跑着突然重启”的隐蔽问题。当然，正常发布的时候记得把看门狗关掉，不然后续维护的人会以为系统不稳定，实际上是你留了个定时炸弹在那里。
本文还有配套的精品资源，点击获取
