📚 课程目录第4章 BSP移植基础

4. BSP移植基础：从QNX BSP到Linux BSP的映射

好，咱们进入正题。这一章聊的是BSP移植，说白了就是怎么把QNX那套板级支持包，搬到Linux上来。很多从QNX转过来的兄弟，一开始都会被设备树（DTS）搞懵——QNX里哪有这东西？别急，我慢慢拆开讲。

核心认知：QNX的BSP是“代码驱动”的，Linux的BSP是“数据驱动”的。前者靠写C代码描述硬件，后者靠设备树描述硬件。这个思维转变，是移植的第一步。

4.1 从QNX BSP到Linux BSP的映射关系

我在做第一个座舱项目移植时，花了整整两周才理清这个映射。你想想看，QNX的BSP结构通常是这样的：

Startup —— 相当于Linux的bootloader + 早期初始化
Syspage —— 系统页，描述硬件资源，对应Linux的DTB
Drivers —— 驱动代码，对应Linux的kernel drivers
Buildfile —— 构建配置，对应Linux的defconfig + DTS

我习惯把映射关系画成一张表，这样团队里新人一看就懂：

QNX组件	Linux对应物	移植要点
Startup代码	Bootloader + 内核早期启动	时钟、DDR、串口初始化逻辑复用
Syspage	设备树(DTB)	内存映射、中断号、时钟频率
io-pkt / dev-*	内核驱动模块	寄存器操作逻辑可移植
Buildfile	Kconfig + DTS	外设使能、引脚复用配置

嗯，这里要注意：QNX的Startup里那些时钟初始化、PLL配置、DDR时序，这些代码逻辑是可以直接参考的。我当年移植i.MX8平台时，就是把QNX Startup里的时钟树配置抄过来，翻译成Linux的clock driver注册方式——省了一半的工作量。

4.2 设备树(DTS)编写入门

设备树，是Linux世界里描述硬件的“通用语言”。我第一次接触时也觉得别扭，但用顺手了就会发现，它比QNX的Syspage灵活得多。

一个最基本的DTS文件，长这样：

/dts-v1/;

#include "soc.dtsi"

/ {
    model = "QNX-to-Linux Migration Board";
    compatible = "vendor,board-rev1";

    chosen {
        stdout-path = &uart0;
    };

    memory@80000000 {
        device_type = "memory";
        reg = <0x0 0x80000000 0x0 0x80000000>;
    };

    soc {
        uart0: serial@1c090000 {
            compatible = "vendor,uart-ip";
            reg = <0x1c090000 0x1000>;
            interrupts = <0 72 4>;
            clocks = <&clk 42>;
            status = "okay";
        };
    };
};

我建议你记住三个核心概念：

compatible —— 驱动匹配的关键字，QNX里叫“匹配ID”
reg —— 寄存器地址和范围，对应QNX的Syspage中的内存映射
interrupts —— 中断号，注意Linux和QNX的中断号偏移可能不同

我的经验：移植时先把QNX的Syspage dump出来，对照着写DTS。把每个外设的基地址、中断号、时钟ID一一对应填进去，基本不会出错。我曾经踩过一个坑——QNX的中断号是物理中断号，Linux需要加上GIC的偏移量（通常是32），这个不处理好，中断全不干活。

4.3 时钟与复位控制器配置

时钟和复位，是BSP移植里最容易出问题的地方。为什么？因为QNX和Linux对时钟的管理方式完全不同。

QNX里，时钟配置通常在Startup里一次性搞定，驱动只管用。Linux则把时钟抽象成CCF（Common Clock Framework），驱动通过clk_get()、clk_enable()来操作。

我画了一张图，帮你理解这个映射关系：

时钟配置的DTS写法，我举个例子：

&clk {
    compatible = "vendor,clock-controller";
    #clock-cells = <1>;
    reg = <0x1c100000 0x1000>;
    clocks = <&osc 0>, <&rtc 0>;
    clock-names = "osc", "rtc";

    assigned-clocks = <&clk 42>, <&clk 55>;
    assigned-clock-rates = <500000000>, <200000000>;
};

&uart0 {
    clocks = <&clk 42>;
    resets = <&rst 17>;
};

我曾经踩过的坑：复位控制器和时钟控制器的初始化顺序。有一次我移植一个显示控制器，时钟已经配好了，但复位信号没释放，结果屏幕死活不亮。查了两天，才发现是DTS里reset-names写错了，驱动没找到对应的复位控制句柄。记住：复位控制器的probe顺序一定要早于依赖它的设备。

4.4 移植实战：时钟树调试技巧

时钟树配好了，怎么验证？我一般用这几个方法：

看内核启动日志 —— 搜索"clk:"开头的行，确认时钟频率对不对
用clk_summary节点 —— cat /sys/kernel/debug/clk/clk_summary，一目了然
对比QNX的时钟寄存器dump —— 在QNX下用io-read把时钟寄存器读出来，跟Linux下对比

嗯，这里要特别说一句：座舱系统里，显示控制器和GPU的时钟频率是性能瓶颈。我建议你在DTS里把这两个时钟的assigned-clock-rates写死，别依赖驱动动态调频——万一调错了，画面撕裂或者闪屏，用户可不会给你好脸色。