3、系统启动与初始化：IPL/FSL启动流程、系统启动脚本分析、资源管理器与驱动加载
好，咱们今天聊聊QNX系统启动这块。说实话，很多做嵌入式开发的朋友，对应用层代码写得飞起，但一碰到系统启动阶段就有点发怵。我当年刚接触QNX时也是这样，总觉得启动流程是个黑盒子。其实你把它拆开看，就那么几步。
3.1 IPL/FSL启动流程：从硬件复位到内核跑起来
系统上电后，CPU首先执行的是固化在ROM里的启动代码。QNX的启动分两个阶段：IPL（Initial Program Loader）和FSL（Flash Startup Loader）。
IPL阶段，说白了就是第一级引导。它通常放在NOR Flash或者ROM里，代码量极小。我见过很多新手以为IPL能干很多事，其实它的任务就三个：
- 初始化最基本的硬件（时钟、内存控制器、串口）
- 把FSL从存储介质加载到RAM里
- 跳转到FSL入口
嗯，这里要注意，IPL本身不加载内核。它只负责把FSL请进来。
FSL阶段才是重头戏。FSL会做更完整的硬件初始化，然后加载IFS（Image Filesystem）映像到内存。IFS里包含了QNX微内核、proc、资源管理器、以及你的应用程序。
关键点：FSL启动时，会解析IFS映像头部的启动脚本。这个脚本决定了哪些模块先加载、哪些后加载。我在项目中遇到过，有人把驱动加载顺序写反了，结果系统反复重启，查了两天才找到原因。
FSL加载完成后，会跳转到内核入口。这时候，QNX微内核开始接管系统。
3.2 系统启动脚本分析：.build文件与启动顺序
QNX的启动脚本，其实就是一个.build文件。你想想看，整个系统的启动顺序、内存布局、驱动加载，全写在这个文件里。我建议你把它当成系统的“宪法”来对待。
一个典型的.build文件长这样：
# 这是注释
[virtual=x86, bsp +compress] .bootstrap = {
startup-something
path = /proc/boot
}
[+script] .script = {
# 启动脚本开始
procnto -s
waitfor /dev/ser1
devc-ser8250 -e -F -b115200 0x3f8,0x28
waitfor /dev/ser1
pipe
devb-umass
io-blk.so
fs-qnx6.so
mount -t qnx6 /dev/hd0t177 /fs/hd0
# 启动脚本结束
}
这里有几个关键点：
- procnto -s：启动微内核和进程管理器。这是系统的第一个进程。
- waitfor：等待某个资源就绪。我习惯在每个驱动加载后都加一个waitfor，防止后续模块依赖还没准备好的设备。
- devc-*：字符设备驱动，比如串口、键盘。
- devb-*：块设备驱动，比如硬盘、SD卡。
- fs-*：文件系统驱动。
个人经验：调试启动问题时，我经常在.build文件里加一些临时性的waitfor和打印语句。比如在关键步骤后加个echo "step X done" > /dev/ser1，这样就能通过串口看到启动进度。这招比看log文件直观多了。
3.3 资源管理器与驱动加载：系统如何“认识”硬件
QNX里有个很特别的概念——资源管理器（Resource Manager）。它本质上是一个遵循POSIX路径命名空间的进程。你想想看，为什么你在QNX里可以用open("/dev/ser1", ...)来操作串口？就是因为有资源管理器在背后注册了这个路径。
驱动加载的过程，其实就是资源管理器注册路径的过程。具体来说：
- 驱动进程启动（比如devc-ser8250）
- 驱动调用
resmgr_attach()函数，向进程管理器注册一个路径（比如/dev/ser1） - 进程管理器把这个路径加入到全局命名空间
- 其他应用程序就可以通过标准文件操作来访问这个设备了
我曾经在调试一个工控项目时，发现某个设备节点死活创建不出来。查了半天，原来是驱动进程启动时依赖的共享库路径不对。资源管理器启动成功了，但注册路径时崩溃了。嗯，这种问题用pidin命令一看进程状态就明白了。
避坑指南：我曾经遇到过一个很隐蔽的问题——两个驱动注册了相同的路径。后启动的驱动会覆盖前一个，但前一个驱动还在运行。结果就是，有些请求路由到了新驱动，有些还留在旧驱动里，行为完全不可预测。所以，驱动路径一定要唯一，最好在.build文件里用注释标明每个驱动注册的路径。
驱动加载的顺序也很讲究。一般来说：
| 加载顺序 | 驱动类型 | 典型示例 | 说明 |
|---|---|---|---|
| 1 | 系统基础驱动 | devc-ser8250 | 串口、时钟等，用于调试输出 |
| 2 | 总线驱动 | pci-server, io-pci | PCI、USB等总线枚举 |
| 3 | 存储驱动 | devb-umass | 硬盘、SD卡等块设备 |
| 4 | 文件系统驱动 | fs-qnx6.so | 挂载根文件系统 |
| 5 | 网络驱动 | io-sock, devn-* | 网卡、协议栈 |
| 6 | 应用层驱动 | io-display, io-audio | 显示、音频等 |
这个顺序不是绝对的，但基本遵循“先基础后应用”的原则。我建议你在设计启动脚本时，把依赖关系画个图。比如串口驱动要在网络驱动之前加载，因为网络驱动初始化时可能需要串口输出日志。
最后说一句，QNX的启动调试，最常用的工具就是pidin和sloginfo。pidin看进程状态，sloginfo看系统日志。如果系统起不来，先用串口看启动输出，再用这两个工具定位问题。我个人的习惯是，在.build文件里把sloginfo的级别调到最高，这样任何错误都不会漏掉。
好，系统启动这块就聊到这儿。下一节咱们会深入讲进程管理和内存调试，到时候再细聊。