深入解析u-boot中多UART外设通信的DTS配置与设备探测

1. 为什么我们需要在U-Boot中配置多个UART？

大家好，我是老李，一个在嵌入式领域摸爬滚打了十多年的老码农。今天想和大家聊聊一个在项目里经常遇到，但又容易让人头疼的问题：在U-Boot里，怎么让第二个、第三个串口（UART）动起来，好跟你的外设通信。

你可能觉得这很简单，不就是改改设备树（DTS），然后调用几个API吗？我一开始也是这么想的，结果一脚踩进坑里，折腾了好几天。就拿我最近做的一个基于全志H3芯片的项目来说，板子上UART0默认是调试串口（Console），用来打印启动信息和交互。但我的外设模块（比如一个4G模组或者一个GPS模块）需要接到UART1上，并且我需要在U-Boot的命令行里，就能直接读写这个UART1，去初始化或者配置外设。

这时候问题就来了。U-Boot启动后，你会发现只有serial0（也就是UART0）能正常工作，输入输出都没问题。但你用serial list命令，可能根本看不到serial1的影子；或者你费劲找到了设备，一操作就data abort（数据访问异常）了。这背后的核心原因在于，U-Boot的设备驱动模型（Driver Model）虽然借鉴了Linux，但它的初始化流程更“精简”，很多硬件初始化的活儿，它默认只给“必要”的设备做。对于非控制台的串口，它可能只是“知道”有这个设备节点，但并没有真正去初始化它的时钟、引脚复用（Mux）和控制器寄存器。

所以，这个过程不仅仅是改个DTS那么简单。它涉及到三个关键环节：第一，在DTS里正确地声明和启用这个UART节点；第二，在代码里正确地“找到”并“探测”（probe）这个设备，把它从静态的设备树节点变成一个可以操作的驱动实例；第三，也是最容易忽略的，手动补上U-Boot可能“偷懒”没做的硬件初始化，比如时钟和GPIO复用。这就像你买了个新家电（外设），说明书（DTS）告诉了你插哪个插座（UART1），你也找到了插座（找到了设备），但你没给插座通电（初始化时钟），也没把插头插上去（配置引脚复用），那家电肯定没法工作。

接下来，我就结合我踩过的那些坑，带你一步步走通这个流程。我会先讲清楚DTS该怎么配，然后深入代码看看设备探测的“黑盒子”里发生了什么，最后把那些必须手动补上的硬件初始化细节掰开揉碎了讲明白。目标是让你看完后，不仅能搞定UART1，以后遇到I2C、SPI等其他外设的类似问题，也能举一反三。

2. 设备树（DTS）配置：给U-Boot一张正确的“地图”

要让U-Boot认识并使用你的第二个串口，第一步就是修改设备树源文件（.dts或.dtsi）。你可以把DTS理解为一张给内核或Bootloader的“硬件地图”，它描述了板子上有哪些芯片、它们怎么连接的、以及初始状态是什么。U-Boot在启动时会解析这份“地图”。

2.1 基础修改：添加节点与别名

以全志H3平台为例，通常串口节点已经在SoC级别的.dtsi文件（如sun8i-h3.dtsi）中定义好了。我们需要在板级.dts文件（如sun8i-h3-nanopi.dtsi）中启用它。原始文章里给出的diff是一个很标准的做法：

/ {
    aliases {
        serial0 = &uart0;
+       serial1 = &uart1;
    };
    chosen {
        ...
    };
};

...

+&uart1 {
+   pinctrl-names = "default";
+   pinctrl-0 = <&uart1_pins_a>;
+   status = "okay";
+};

我来解释一下这几处修改的含义：

1. 添加别名（Alias）：在根节点下的aliases子节点里，添加serial1 = &uart1;。这行代码给uart1节点起了一个别名serial1。在U-Boot中，serial开头的别名有特殊意义，它被串口驱动框架用来索引设备。当你调用uclass_get_device(UCLASS_SERIAL, 1, &dev)时，第二个参数index为1，U-Boot就会去查找别名serial1对应的设备。如果不加这个别名，你可能需要通过其他更复杂的方式（比如用设备树路径）来查找设备。
2. 启用节点：通过&uart1这个引用，我们定位到<