内核启动早期打印：从原理到实战的完整实现指南

1. 从一行乱码说起：内核启动早期打印到底在解决什么问题

如果你曾经在调试一块新板子，或者给一个嵌入式系统做底层适配，大概率遇到过这样的场景：串口工具打开，上电，屏幕上刷出来几行字，然后卡死。你想知道卡在哪了，但系统连控制台都还没初始化完，printk打不出来，调试器又接不上，整个人就僵在那里。

这就是内核启动早期打印要解决的核心问题。它指的是从内核解压、进入保护模式或长模式，到正式的控制台驱动注册完成之前，这段时间里如何把信息输出到某个可见的地方。这个窗口期非常短，通常只有几百毫秒到几秒，但恰恰是问题最集中的阶段——内存还没完全初始化、页表刚建好、中断控制器还没配、串口驱动还没注册。任何一步出错，系统就静默死机，你连个报错都看不到。

我见过太多人在这上面吃亏。有个做工业控制的朋友，板子跑起来偶尔卡死，概率大概百分之几。他花了整整两周，用示波器量电源、换晶振、改时序，最后发现是内核在早期初始化某个时钟节点时超时了，但因为没有早期打印，这个超时被完全吞掉了。后来加上早期控制台输出，一眼就看到卡在哪一行。

所以这篇文章想聊的，就是内核启动早期打印的完整实现思路和实操细节。我会从为什么需要它、有哪些常见方案、每种方案的适用边界、具体怎么配置、踩过哪些坑这几个角度展开。不管你是做嵌入式Linux、RTOS，还是自己写一个小型内核玩，这套思路都能直接参考。

注意：本文讨论的是通用技术方案，不涉及任何特定厂商的私有实现，所有示例均为原理性说明。

2. 早期打印为什么不能直接用printk

2.1 printk的依赖链比你想的长

很多人第一反应是：我直接调printk不就行了？问题在于，printk看起来简单，背后却依赖一长串基础设施。

首先，printk需要一个缓冲区来暂存日志。这个缓冲区通常是静态分配的，看起来没问题。但日志最终要输出到某个地方，这就需要console。而console的注册依赖于驱动模型、设备树解析、甚至时钟和GPIO子系统。在启动早期，这些统统不存在。

其次，printk内部会用到锁。多核系统上，锁的实现依赖于原子操作和内存屏障，这些在早期可能还没配好。单核系统上，如果中断还没关，一个中断进来再打日志，就可能死锁。

再者，printk的时间戳功能依赖于定时器。定时器又依赖于时钟源驱动和中断控制器。这一层套一层，等到所有依赖都就绪，早期阶段早就过去了。

所以结论很明确：在启动早期，printk要么不可用，要么用了会出问题。你需要一个更底层、依赖更少的输出通道。

2.2 早期阶段的时间窗口到底有多窄

我实测过几个典型的ARM64平台，从内核入口到console_init被调用，时间大概在200毫秒到1.5秒之间，取决于CPU主频和初始化内容的多少。这段时间里，内核做了很多事情：解压自身、建立临时页表、初始化内存管理、解析设备树、初始化中断控制器、初始化定时器、初始化调度器、然后才轮到控制台。

如果把这比作装修房子，printk和console就像是装修完成后的对讲机系统，而早期打印就是施工期间用的临时对讲机——它不需要装修完成，拉两根线就能用。

2.3 一个真实的排查案例

之前有个项目，系统在启动到某个阶段时随机重启。看门狗喂狗线程还没起来，硬件看门狗超时导致复位。但为什么会超时？因为某个初始化步骤卡住了。卡在哪？没有任何输出。

后来我们在早期打印里加了一个简单的标记机制：每进入一个初始化函数，就往一个固定的内存地址写一个数字。系统重启后，通过调试器读这个地址，就知道最后执行到哪。这个方法很土，但极其有效。它本质上就是一种最原始的早期打印——不依赖任何驱动，只依赖内存写入。

这个案例说明，早期打印不一定要输出到串口，任何能被外部观测到的信号都可以。关键是找到那个阶段可用的、最简的输出通道。

3. 几种主流早期打印方案的取舍与对比

3.1 基于UART直接寄存器的输出

这是最常见也最实用的方案。核心思路是：绕过所有驱动框架，直接操作UART控制器的寄存器，把字符一个一个发出去。

为什么可行？因为UART控制器通常在上电后就有默认配置，或者可以通过极少的寄存器操作完成配置。你只需要知道UART的物理基地址、数据寄存器偏移、状态寄存器偏移，以及波特率分频值。

以常见的16550兼容UART为例，初始化只需要几步：关中断、设波特率、设数据位和停止位、使能FIFO。之后往数据寄存器写一个字节，轮询状态寄存器的发送完成位，就完成了一个字符的输出。

这个方案的优点是依赖极少，几乎在任何阶段都能用。缺点是需要硬编码UART地址和配置参数，换一块板子就要改。而且如果UART时钟还没使能，写寄存器也没用。

3.2 基于半主机模式的输出

半主机模式是一种调试机制，通过调试器把目标机的输出转发到主机。它的原理是触发一个特定的异常或指令，调试器捕获后读取寄存器里的字符，显示在主机终端上。

这个方案的好处是完全不依赖目标机的任何外设，连UART都不需要。只要调试器连着，就能输出。缺点是必须有调试器，量产环境用不了。而且不同架构的半主机指令不一样，ARM上是SVC或HLT，RISC-V上是EBREAK。

我一般把这个方案作为备用。当UART还没配好，或者UART引脚被复用成其他功能时，半主机就是救命的。

3.3 基于内存缓冲区的延迟输出

这个方案的思路是：早期阶段先把日志写到一个预留的内存缓冲区里，等控制台初始化完成后，再把缓冲区里的内容刷出来。

它的优点是对早期阶段几乎没有要求，只要内存能写就行。缺点也很明显：如果系统在刷出之前就死了，日志就丢了。所以它适合那些“能启动到控制台，但早期信息想保留”的场景，不适合排查早期死机。

我通常会把内存缓冲区和UART方案结合使用：早期用UART实时输出关键标记，同时把详细日志写进内存缓冲区，等控制台起来后再补看详细内容。

3.4 方案对比与选型建议

选型的时候，我一般这样判断：如果板子有可用的UART且时钟已经使能，优先用UART方案。如果没有UART或者UART还没配好，用半主机。如果两者都不行，用内存缓冲区加GPIO标记做兜底。

提示：不要只选一种方案。实际项目中，我通常同时启用UART和内存缓冲区，UART输出关键节点，内存缓冲区记录详细流程，互为补充。

4. 手把手实现一个极简早期UART打印

4.1 确定UART的物理地址和时钟

第一步是查芯片手册，找到UART控制器的物理基地址。这个地址在芯片的存储映射表里，通常是固定的。比如某款芯片的UART0基地址是0x09000000，UART1是0x09010000。

然后确认UART时钟是否已经在早期使能。有些芯片的UART时钟默认开启，有些需要先配置时钟控制器。如果时钟没开，写UART寄存器不会报错，但也不会有输出，这个坑很隐蔽。

我一般会先用调试器读一下UART的某个只读寄存器，比如状态寄存器。如果读出来是全0或全F，说明时钟可能没开或者地址不对。如果读出来有合理的值，说明UART是活的。

4.2 初始化UART的最小寄存器序列

以16550兼容UART为例，最小初始化序列如下：

#define UART_BASE 0x09000000 #define UART_THR (UART_BASE + 0x00) // 发送保持寄存器 #define UART_LSR (UART_BASE + 0x14) // 线路状态寄存器 #define UART_LCR (UART_BASE + 0x0C) // 线路控制寄存器 #define UART_DLL (UART_BASE + 0x00) // 除数低字节 #define UART_DLM (UART_BASE + 0x04) // 除数高字节 #define UART_FCR (UART_BASE + 0x08) // FIFO控制寄存器 void early_uart_init(void) { // 关闭FIFO，简单模式 write32(UART_FCR, 0x00); // 设置波特率，假设输入时钟48MHz，目标115200 // 分频值 = 48000000 / (16 * 115200) = 26 write32(UART_LCR, 0x80); // 使能除数锁存 write32(UART_DLL, 26); write32(UART_DLM, 0); write32(UART_LCR, 0x03); // 8位数据，1位停止，无校验 } void early_putc(char c) { // 等待发送保持寄存器空 while ((read32(UART_LSR) & 0x20) == 0); write32(UART_THR, c); } void early_puts(const char *s) { while (*s) { if (*s == '\n') early_putc('\r'); early_putc(*s++); } }

这段代码的关键点：UART_LSR的bit5是发送保持寄存器空标志，轮询这个位就能知道能不能发下一个字符。UART_LCR的bit7是除数锁存使能，设波特率前要先置1，设完再清0。

4.3 处理换行和格式化输出

串口终端通常需要\r\n才能正确换行，只发\n的话光标会下移但不会回到行首。所以early_puts里遇到\n要先补一个\r。

格式化输出可以自己实现一个极简的early_printf，支持%s、%d、%x就够了。不需要支持浮点，也不需要支持宽度和对齐。实现思路是遍历格式字符串，遇到%就解析下一个字符，根据类型取可变参数并转换。

void early_printf(const char *fmt, ...) { va_list args; va_start(args, fmt); char buf[32]; while (*fmt) { if (*fmt == '%') { fmt++; switch (*fmt) { case 's': { const char *s = va_arg(args, const char *); early_puts(s); break; } case 'd': { int v = va_arg(args, int); itoa(v, buf, 10); early_puts(buf); break; } case 'x': { unsigned int v = va_arg(args, unsigned int); itoa(v, buf, 16); early_puts(buf); break; } default: early_putc('%'); early_putc(*fmt); break; } } else { early_putc(*fmt); } fmt++; } va_end(args); }

这个early_printf大概只有几十行，但足够覆盖早期调试的绝大多数需求。

4.4 在启动流程中插入打印点

有了输出函数，接下来就是在关键节点插入打印。我的习惯是在这些位置加标记：

• 内核入口第一条指令之后
• 页表建立完成之后
• 内存管理初始化完成之后
• 设备树解析完成之后
• 中断控制器初始化完成之后
• 定时器初始化完成之后
• 调度器初始化完成之后
• 控制台初始化完成之后

每个标记输出一个简短的字符串，比如[early] mm init done。这样一旦卡死，最后一条输出就是线索。

注意：打印点不要太多，否则会影响启动速度，也可能因为输出太多导致看不过来。一般十个以内的关键节点就够了。

5. 那些年我在早期打印上踩过的坑

5.1 时钟没使能导致输出全无

这是最常见的坑。UART控制器有独立的时钟门控，如果时钟没开，寄存器读写可能不报错，但UART就是不工作。我遇到过好几次，代码看起来没问题，但串口就是没输出，查了半天发现是时钟控制器里UART的时钟位没置1。

解决办法：在初始化UART之前，先确认时钟控制器的相关寄存器。如果芯片支持，可以在早期打印里加一句读时钟状态寄存器的输出，确认时钟是否开启。

5.2 引脚复用没配置

另一个常见问题是UART的引脚被复用成了GPIO或其他功能。芯片上电后，引脚通常有一个默认功能，但不一定是UART。如果引脚复用没配好，UART控制器工作正常，但信号出不来。

这个坑的特点是：用调试器看UART寄存器，状态位都正常，发送完成位也会置起，但物理引脚上没有波形。解决办法是查引脚控制器的寄存器，把UART的TX和RX引脚配成正确功能。

5.3 FIFO和波特率的隐蔽问题

有些UART的FIFO默认是开启的，而且触发阈值设得很高。这会导致你写进去的字符被FIFO缓存，但没有立即发出去。如果系统在FIFO刷新之前死机，最后的字符就丢了。

我一般会在早期初始化时把FIFO关掉，或者把触发阈值设成最低。这样每个字符写进去就立即发送，不会丢。

波特率的问题更隐蔽。如果分频值算错了，输出会是乱码。但乱码至少说明UART是工作的，比完全没输出好排查。我习惯先用一个固定的、已知正确的分频值测试，确认通路后再调整。

5.4 多核环境下的输出交错

多核系统上，如果多个核同时往UART写，输出会交错在一起，变成乱码。早期阶段可能还没有核间锁，这个问题更严重。

解决办法有两个：一是只让主核输出，其他核在早期阶段不打印；二是用一个简单的自旋锁保护UART写操作。我通常选第一种，因为早期阶段其他核本来就不应该做太多事情。

5.5 打印本身导致的时序变化

这是一个很微妙的问题：加了打印之后，系统行为变了。比如某个硬件需要在上电后一段时间内完成初始化，打印消耗的时间导致错过了窗口，系统反而不启动了。

这种情况虽然少见，但确实存在。我的应对方法是：先用最少的打印点定位大致范围，然后逐步增加打印密度，同时观察系统行为是否变化。如果加打印后问题消失，说明是时序问题，需要调整初始化顺序或加延时。

6. 从早期打印到完整日志系统的平滑过渡

6.1 早期打印和控制台的分工

早期打印和控制台不是替代关系，而是接力关系。我的做法是：早期打印负责从内核入口到控制台初始化完成这段时间的输出，控制台初始化完成后，自动切换到正常的printk。

切换的时机很关键。太早切换，控制台还没准备好，日志会丢；太晚切换，早期打印的代码一直占着UART，影响正常驱动。我一般在console_init调用之后，用一个全局标志位标记“控制台已就绪”，然后早期打印函数检查这个标志，如果就绪就转发给printk。

6.2 日志缓冲区的衔接

如果早期阶段用了内存缓冲区，控制台就绪后需要把缓冲区里的内容刷出来。刷的时候要注意顺序，先刷最早的日志，再刷最新的，保持时间顺序。

刷出的方式可以是在console_init之后直接调用一个flush_early_log函数，把缓冲区内容逐条printk出来。也可以注册一个late_initcall，在更晚的阶段刷出，避免影响启动速度。

6.3 保留早期打印作为应急通道

即使控制台已经就绪，我建议保留早期打印函数作为应急通道。当系统出现严重错误，比如控制台驱动崩溃、中断风暴导致printk不可用时，可以切回早期打印，直接操作UART输出紧急信息。

这个应急通道的触发方式可以是一个特殊的魔术键组合，或者一个调试器可写的内存地址。触发后，系统切换到轮询模式的UART输出，绕过所有驱动和中断。

6.4 一个实用的日志分级策略

早期阶段的日志也需要分级。我的做法是分三级：

• 紧急：系统即将死机或已经死机，必须输出。比如页表建立失败、内存检测失败。
• 关键：重要初始化步骤完成，用于定位卡死位置。比如中断控制器初始化完成。
• 详细：每个函数的进入和退出，用于深度调试。默认关闭，需要时通过编译宏开启。

分级的好处是：正常启动时只输出紧急和关键日志，启动速度快；排查问题时开启详细日志，信息全。

7. 不同架构下的早期打印差异

7.1 ARM64的早期打印特点

ARM64在内核入口时，MMU还没开，用的是物理地址。所以早期打印的UART地址必须是物理地址，不能是虚拟地址。等MMU开启并建立映射后，可以切换到虚拟地址，但通常没必要，一直用物理地址更简单。

另外，ARM64的earlycon机制支持通过设备树或命令行参数指定UART，这比硬编码地址灵活。但earlycon本身也依赖于设备树解析，在设备树解析之前还是得用硬编码方案。

7.2 RISC-V的早期打印特点

RISC-V的UART通常是16550兼容的，寄存器操作和ARM64类似。但RISC-V的启动流程中，设备树可能由BootROM提供，解析时机不同。另外，RISC-V的SBI接口可以提供控制台输出，但需要SBI实现支持。

我一般在RISC-V上先用硬编码UART地址做极早期输出，等SBI控制台可用后切换过去。

7.3 x86的早期打印特点

x86的早期打印更复杂，因为涉及到实模式、保护模式、长模式的切换。在实模式下，可以用BIOS的int 10h输出字符；在保护模式和长模式下，需要直接操作UART或VGA文本缓冲区。

VGA文本缓冲区是一个不错的选择，因为它在实模式和保护模式下都可以访问，地址固定为0xB8000。往这个地址写字符和属性字节，就能在屏幕上显示。缺点是只能显示80x25个字符，信息量有限。

8. 早期打印的进阶技巧与性能考量

8.1 用压缩编码减少输出量

早期打印的输出速度受限于UART波特率。115200波特率下，每秒大概能发11520个字符。如果打印点很多，输出会成为启动时间的瓶颈。

一个技巧是用压缩编码。比如每个初始化步骤用一个字节的编码表示，输出时只发这个字节，主机端再查表还原。这样能把输出量减少一个数量级。

另一个技巧是只输出差异。比如循环初始化十个设备，不需要每个都打印，只在失败时打印错误码。

8.2 时间戳的获取

早期阶段没有定时器，但有些架构提供了周期计数器，比如ARM的CNTPCT_EL0，RISC-V的timeCSR。这些计数器在上电后就开始计数，可以直接读取。

有了周期计数器，就可以在每条早期打印前输出时间戳，精确到微秒。这对分析启动各阶段的耗时非常有用。我一般会输出相对于内核入口的时间差，单位是毫秒。

8.3 输出缓冲与批量发送

如果UART有FIFO，可以先把多个字符写入FIFO，再等待FIFO发送完成。这样比逐字符轮询效率高。但要注意FIFO深度，写满了会丢字符。

我的做法是：实现一个小的环形缓冲区，早期打印先写入缓冲区，然后在合适的时机批量刷到UART。这样既能减少轮询等待，又能保证字符不丢。

8.4 在中断上下文中使用早期打印

早期阶段如果发生了异常或中断，需要在异常处理程序中输出信息。这时候要特别小心，因为异常处理程序的上下文可能很受限。

我的原则是：异常处理程序中的早期打印只输出最必要的信息，比如异常类型和故障地址，不输出格式化字符串。而且输出前要关中断，防止嵌套异常导致输出交错。

9. 实际项目中的配置示例与验证方法

9.1 一个完整的早期打印配置

以某ARM64平台为例，配置步骤如下：

1. 在启动汇编中，第一条指令后调用early_uart_init，传入UART基地址和时钟频率。
2. 在C入口函数中，调用early_puts输出内核版本和编译时间。
3. 在页表建立、内存初始化、设备树解析、中断初始化、定时器初始化等关键节点插入early_printf。
4. 在console_init之后，设置全局标志，早期打印转发给printk。
5. 保留早期打印函数，作为应急通道。

9.2 验证早期打印是否工作

验证方法很简单：上电后观察串口输出。如果没有任何输出，按以下顺序排查：

• 确认串口工具配置正确：波特率、数据位、停止位、校验位。
• 确认UART时钟已使能。
• 确认引脚复用配置正确。
• 确认UART基地址正确。
• 用调试器读UART寄存器，确认读写正常。
• 用示波器或逻辑分析仪看TX引脚是否有波形。

9.3 性能影响的量化评估

我实测过，在115200波特率下，输出100个字符大约需要8.7毫秒。如果启动过程中输出500个字符，总耗时约43毫秒。对于大多数系统来说，这个开销可以接受。

但如果输出量达到几千个字符，耗时就会超过200毫秒，对启动时间敏感的场景就需要优化。优化方法包括：提高波特率、减少输出量、使用压缩编码、异步输出等。

10. 一些个人体会和后续扩展思路

早期打印这件事，看起来简单，但真正做好需要对这些东西有感觉：芯片的启动流程、UART的工作原理、时钟和引脚控制、多核同步、异常处理。每一个环节出问题，都会导致“没输出”这个最终现象，而排查起来往往要花不少时间。

我的经验是：在新板子 bring-up 阶段，第一件事就是把早期打印调通。不要等到出问题了再临时加，那时候可能连调试器都接不上。早期打印调通之后，后面所有调试都会轻松很多。

后续如果想进一步扩展，可以考虑这几个方向：一是把早期打印和内核的pstore机制结合，死机后重启还能看到上次的日志；二是实现一个基于早期打印的交互式调试控制台，在启动早期就能读写内存和寄存器；三是把早期打印的输出通过DMA发送，进一步降低CPU占用。

这些扩展我自己也只做过一部分，但思路是通的。核心还是那句话：在系统最脆弱的时候，给它一个最简单的输出通道，你就能看到它在做什么。