内核启动早期打印机制：earlycon与earlyprintk调试实战指南

1. 内核启动早期的打印到底在解决什么问题

做过嵌入式或者操作系统底层开发的人都有一个共同的痛点：板子上电之后，屏幕黑的，串口也没输出，你完全不知道内核跑到哪一步就挂掉了。这种“哑巴死机”是最让人抓狂的，因为没有任何线索，只能靠猜。而内核启动早期的打印，就是用来解决这个问题的——它让你在系统还没有完全初始化、连正经的驱动都还没加载的时候，就能看到内核在干什么。

这个主题涉及的核心领域是操作系统内核开发与调试，具体聚焦在内核启动阶段的信息输出机制。它要解决的核心问题是：在内核的完整打印系统（比如printk的完整缓冲区和输出通道）还没准备好的时候，如何尽早地、可靠地把调试信息吐出来。适合阅读这篇文章的人包括：做嵌入式Linux驱动开发的工程师、搞操作系统课程设计的学生、以及任何需要调试内核启动流程的开发者。

我见过太多人在这个环节翻车。有人改了半年代码，结果发现是启动参数里一个地址写错了，但因为早期没有任何输出，硬是排查了两周。也有人明明配置了earlyprintk，但就是不出东西，最后发现是串口引脚复用没配对。这些坑，说到底都是对“内核启动早期打印”这套机制理解不够深导致的。

这篇文章会从整体设计思路讲到具体的实操配置，再到常见问题的排查，把我在实际项目中积累的经验都倒出来。不管你是刚接触内核的新手，还是已经调过几个板子的老手，应该都能从中找到有用的东西。

2. 内核启动早期打印的整体设计与思路拆解

2.1 为什么不能用普通的 printk 来搞定一切

很多人第一反应是：内核不是有printk吗？直接用它打印不就行了？问题在于，printk虽然名字听起来很简单，但它背后依赖的东西一点都不简单。

printk要把信息输出到串口，至少需要以下几个条件就绪：串口驱动已经注册并初始化完成、控制台设备已经注册、printk的日志缓冲区已经分配好、内核的调度和中断系统能正常配合。而在内核启动的最早期，这些条件一个都不满足。你想想，内核刚解压完，连内存管理都还没初始化，怎么可能有完整的串口驱动？

所以，内核启动早期的打印必须走一条“特殊通道”，绕开那些还没准备好的基础设施，直接用最原始的方式把字符怼到串口硬件寄存器上。这就是earlyprintk、earlycon这类机制存在的根本原因。

2.2 从 earlyprintk 到 earlycon 的演进逻辑

早期内核用的是earlyprintk，它的思路非常直接：在编译时就把串口的物理地址写死，启动时直接往那个地址写字符。这种方式简单粗暴，但问题也很明显——它和具体的硬件平台强绑定，换个板子就得改代码重新编译。

后来内核引入了earlycon机制，思路就优雅多了。earlycon支持通过设备树或者启动参数来传递串口信息，不需要重新编译内核就能适配不同的硬件。它内部使用了一套通用的早期控制台框架，把“往哪写”和“怎么写”解耦了。

这个演进背后的逻辑其实很朴素：调试手段本身不应该成为调试的障碍。如果为了打开早期打印还得改代码重编译，那调试效率就太低了。earlycon的设计目标就是让你通过一个启动参数就能打开早期输出，改参数重启就行，不用动内核镜像。

2.3 内核启动各阶段的打印能力对照

要理解早期打印，必须搞清楚内核启动的各个阶段分别能提供什么级别的打印能力。下面这张表是我根据实际调试经验整理的：

这张表的关键信息是：从“完全没输出”到“完整日志”之间，有一个很长的过渡地带。早期打印机制就是用来填补这个过渡地带的空白。你在调试的时候，首先要判断问题出在哪个阶段，然后选择对应的打印手段。

2.4 方案选型：什么场景用什么机制

在实际项目中，选择哪种早期打印方案，取决于你的具体需求和硬件条件。我一般按以下逻辑来判断：

• 如果是开发阶段，硬件平台固定，追求最快出结果，直接用earlyprintk写死地址，简单可靠。
• 如果是产品化阶段，需要适配多个硬件版本，用earlycon配合设备树，灵活性强。
• 如果是极端早期，连设备树都还没解析，那就只能用earlyprintk或者 Bootloader 传递的earlycon参数。
• 如果是ARM64 平台，基本只用earlycon，因为earlyprintk在新架构上支持很有限。

这里有一个很多人忽略的点：早期打印和正常 printk 是可以并存的。你完全可以在启动参数里同时配置earlycon和console，这样从早期到正常阶段的输出是连续的，不会出现中间断档。这个技巧在调试启动卡死问题时特别有用。

3. 核心细节解析与实操要点

3.1 串口硬件层面的关键参数

早期打印能不能成功，最底层的决定因素是串口硬件配置是否正确。这里涉及几个关键参数，任何一个搞错都会导致输出乱码或者完全没输出。

波特率是最基础的。早期打印阶段，内核还没有能力去协商波特率，它只能按照你给定的值去配置串口。常见的值是 115200，但有些平台默认用 921600 甚至更高。如果你在 Bootloader 里用的是 115200，但早期打印配置的是 921600，那看到的就是一堆乱码。

数据位、停止位、校验位这三个参数通常默认是 8N1（8 数据位、无校验、1 停止位），绝大多数平台都支持。但如果你用的是某些特殊串口芯片，可能需要调整。

寄存器偏移是很多人踩坑的地方。不同厂商的串口 IP 核，寄存器偏移可能不一样。比如同样是 8250 兼容串口，有的平台寄存器间距是 1 字节，有的是 4 字节。这个参数在earlycon的配置里需要明确指定，否则写过去的字符会跑到错误的寄存器里。

提示：在配置早期串口之前，务必从硬件手册或者 Bootloader 的串口配置中确认上述所有参数。不要凭经验猜，猜错了排查起来非常痛苦。

3.2 设备树中 earlycon 的配置方法

在设备树中配置earlycon是目前最推荐的做法，因为它不需要重新编译内核，改设备树重新打包就行。具体操作是在 chosen 节点中添加stdout-path属性：

/ { chosen { stdout-path = "serial0:115200n8"; }; };

这里的serial0是串口设备的别名，115200n8表示波特率 115200、无校验、8 数据位。内核在启动时会解析这个属性，自动配置对应的早期控制台。

如果需要更精细的控制，比如指定寄存器偏移，可以这样写：

/ { chosen { stdout-path = "serial0:115200n8r"; }; };

末尾的r表示使用寄存器偏移模式。具体支持哪些后缀，取决于内核版本和串口驱动，建议查阅对应版本的内核文档。

3.3 启动参数中 earlycon 的写法

除了设备树，还可以通过启动参数（bootargs）来配置earlycon。这种方式更灵活，适合在调试阶段快速切换配置。

常见的写法有以下几种：

• earlycon：让内核自动从设备树的 stdout-path 中获取配置。
• earlycon=uart8250,mmio,0x10000000,115200n8：手动指定串口类型、地址和参数。
• earlycon=pl011,mmio32,0x9000000,115200n8：针对 ARM PL011 串口的写法。

这里的关键是串口类型和地址必须匹配你的硬件。uart8250是最常见的兼容类型，但很多 ARM 平台用的是pl011或者厂商自定义的类型。如果你写错了类型，内核会找不到对应的早期控制台驱动，输出自然就没有了。

注意：启动参数中的earlycon配置优先级高于设备树中的stdout-path。如果你两个都配了，以启动参数为准。调试的时候可以利用这一点，不改设备树就能覆盖配置。

3.4 内核配置选项的取舍

要让早期打印工作，内核配置里必须打开对应的选项。这些选项在不同的内核版本里名字可能略有差异，但核心的几个是：

• CONFIG_SERIAL_EARLYCON：早期控制台框架的总开关，必须打开。
• CONFIG_SERIAL_8250：8250 串口驱动，如果你的串口是 8250 兼容的，需要打开。
• CONFIG_SERIAL_8250_CONSOLE：8250 控制台支持，影响正常阶段的串口输出。
• CONFIG_SERIAL_AMBA_PL011：ARM PL011 串口驱动，ARM 平台常用。
• CONFIG_DEBUG_LL：底层调试输出支持，某些平台需要。

这里有一个常见的误区：有人以为只要打开了CONFIG_SERIAL_EARLYCON就够了，结果发现串口类型对应的驱动没编译进去，早期打印还是不出东西。早期控制台框架和具体的串口驱动是两回事，框架提供接口，驱动提供实现，两者缺一不可。

3.5 输出格式与日志级别的控制

早期打印的输出格式和正常printk不太一样。早期阶段，内核还没有能力做完整的日志格式化，所以输出通常比较简陋，可能只有裸的字符串，没有时间戳、没有日志级别前缀。

如果你需要更结构化的早期输出，可以考虑使用CONFIG_DEBUG_LL配合printascii等底层函数。这些函数可以输出格式化的信息，但需要你自己处理字符串拼接。

另外，早期打印的日志级别控制也很有限。正常printk可以通过loglevel参数控制输出级别，但早期阶段这个机制还没生效。所以你会看到早期输出往往比较“啰嗦”，什么都往外打。这在调试时是好事，但在产品化阶段可能需要通过配置来精简。

4. 实操过程与核心环节实现

4.1 从零搭建一个可调试的早期打印环境

假设你手头有一块 ARM 开发板，串口是 8250 兼容的，物理地址是0x10000000，波特率 115200。下面是我实际搭建环境的完整步骤。

第一步：确认硬件连接。用 USB 转串口线把开发板的调试串口连到电脑上，打开串口终端工具（比如 minicom 或者 picocom），配置为 115200 8N1。这一步看起来简单，但我见过不少人因为串口线没插紧或者终端工具配置错了，白白浪费半天时间。

第二步：配置内核。进入内核源码目录，执行make menuconfig，确保以下选项被打开：

CONFIG_SERIAL_EARLYCON=y CONFIG_SERIAL_8250=y CONFIG_SERIAL_8250_CONSOLE=y CONFIG_DEBUG_KERNEL=y

如果你的平台需要CONFIG_DEBUG_LL，也一并打开。配置完成后编译内核，生成新的内核镜像。

第三步：配置启动参数。在 Bootloader 的启动参数中添加：

earlycon=uart8250,mmio,0x10000000,115200n8

如果你用的是设备树，也可以在 chosen 节点中添加stdout-path属性。两种方式选一种即可，我一般推荐先用启动参数快速验证，验证通过后再固化到设备树里。

第四步：启动并观察输出。重新启动开发板，你应该能在串口终端里看到内核早期的输出信息。如果看到了，恭喜你，环境搭建成功。如果没看到，别急，下一节会讲排查方法。

4.2 参数计算与地址确认的实操方法

串口物理地址的确认是早期打印配置中最容易出错的环节。我一般用以下几种方法交叉验证：

方法一：查芯片手册。这是最权威的方式。在芯片的存储映射章节里找到 UART 控制器的基地址。注意要区分物理地址和虚拟地址，早期打印用的是物理地址。

方法二：看 Bootloader 源码。Bootloader 里通常有串口初始化的代码，里面会写死串口地址。直接参考它的配置，一般不会错。

方法三：从设备树反推。如果设备树里已经描述了串口节点，可以直接读取它的reg属性。但要注意，设备树里的地址可能是经过转换的，需要确认是否是物理地址。

方法四：用 devmem 工具验证。如果系统已经能启动到用户空间，可以用devmem工具读取串口寄存器，确认地址是否正确。这个方法适合事后验证。

寄存器偏移的计算稍微复杂一些。以 8250 为例，发送寄存器（THR）的偏移通常是 0，但有些平台是 4 的倍数。你可以通过读取线路控制寄存器（LCR，偏移通常是 0x0C 或 0x0C 的倍数）来验证。如果读出来的值符合预期（比如 0x03 表示 8N1），说明偏移是对的。

4.3 完整启动日志的解读示例

下面是一段典型的带早期打印的内核启动日志，我来逐段解读：

[ 0.000000] Booting Linux on physical CPU 0x0 [ 0.000000] Linux version 5.10.0 (user@host) (gcc version 10.2.0) [ 0.000000] earlycon: uart8250 at MMIO 0x10000000 (options '115200n8') [ 0.000000] printk: bootconsole [uart8250] enabled [ 0.000000] Memory: 2048000K/2097152K available ... [ 1.234567] printk: console [ttyS0] enabled [ 1.234568] printk: bootconsole [uart8250] disabled

关键信息在第三行和最后两行。第三行的earlycon: uart8250 at MMIO 0x10000000说明早期控制台已经成功注册，地址和类型都正确。最后两行的console [ttyS0] enabled和bootconsole [uart8250] disabled说明正常控制台已经接管，早期控制台功成身退。

如果你在日志里看到earlycon: uart8250 at MMIO 0x10000000这行，但后面没有任何输出了，那说明早期控制台注册成功了，但内核在后续初始化中卡住了。这时候你需要根据最后一条输出信息来判断卡在哪个环节。

4.4 从早期打印到正常控制台的平滑过渡

很多人会遇到一个问题：早期打印有输出，但到了某个阶段突然就没了，然后过一会儿又出现正常输出。中间那段“沉默期”让人很不安。

这个现象的原因是：早期控制台在某个时间点被禁用了，而正常控制台还没准备好。要解决这个问题，关键是让两者的切换尽可能平滑。

内核的设计是：当正常控制台注册时，会接管输出，同时禁用早期控制台。这个切换点通常在console_init()调用之后。如果你在切换点附近看到输出断档，可能是因为正常控制台的初始化耗时较长。

一个实用的技巧是：在启动参数中同时指定earlycon和console，并且确保两者指向同一个串口。这样即使切换过程中有短暂断档，也不会丢失关键信息。另外，可以通过keep_bootcon参数让早期控制台在正常控制台注册后继续保留一段时间，避免切换时的信息丢失。

5. 常见问题与排查技巧实录

5.1 早期打印完全没输出的排查思路

这是最常见的问题，也是最让人头疼的。我一般按照以下顺序排查：

第一，确认串口硬件连接和终端配置。换一根线、换一个终端工具、换一台电脑试试。听起来很蠢，但确实有很多人栽在这上面。

第二，确认启动参数是否正确传递。在 Bootloader 里打印一下启动参数，看看earlycon那一段是不是完整传给了内核。有时候 Bootloader 会截断或者覆盖参数。

第三，确认内核配置是否生效。解压内核镜像，检查config文件里相关选项是否真的被打开了。有时候make menuconfig改了但没保存，或者被其他配置覆盖了。

第四，确认串口地址和类型是否匹配。这是最容易出错的地方。用前面说的交叉验证方法，确认地址、类型、寄存器偏移都正确。

第五，确认串口时钟是否使能。有些平台需要显式使能串口时钟，否则寄存器写了也没反应。检查时钟控制寄存器或者设备树里的 clocks 属性。

5.2 输出乱码的原因分析与解决

乱码通常比完全没输出好排查，因为至少说明数据通路是通的。乱码的原因主要有以下几种：

波特率不匹配是最常见的原因。我遇到过一种情况：Bootloader 把串口时钟配置成了某个值，但内核早期打印假设的是另一个值，导致波特率偏差很大。解决方法是让内核早期打印使用和 Bootloader 相同的时钟配置，或者在启动参数中明确指定正确的时钟频率。

5.3 早期打印导致启动变慢或卡死

早期打印本身不应该导致启动变慢或卡死，但如果配置不当，确实可能引发问题。

一种情况是串口硬件流控没配对。如果串口配置了硬件流控（RTS/CTS），但另一端没有正确响应，写操作可能会阻塞。早期打印阶段没有超时机制，一旦阻塞就是死等。解决方法是在早期打印配置中禁用硬件流控。

另一种情况是串口寄存器访问方式不对。有些平台的串口寄存器需要特殊的访问方式（比如先写某个解锁寄存器），如果早期打印直接访问，可能会导致总线错误或者死锁。这种情况下需要检查平台手册，确认是否有特殊要求。

还有一种情况是早期打印输出量太大。如果内核在早期阶段疯狂输出，而串口波特率又比较低，输出缓冲区可能会满，导致内核在某些点等待。虽然这种情况比较少见，但在调试级别开到最高时有可能发生。解决方法是在产品化阶段适当降低早期打印的日志级别。

5.4 不同平台的适配经验速查

不同架构和平台的早期打印配置差异很大，下面是我整理的一份速查表：

这份表只是参考，具体配置还是要以硬件手册和内核文档为准。我在实际项目中遇到过厂商自定义的串口类型，内核主线不支持，需要打补丁才能用。这种情况下，要么等厂商提供补丁，要么自己照着 8250 的驱动改一个。

5.5 独家避坑技巧汇总

最后分享几个我在实际调试中总结的技巧，都是踩过坑之后才明白的：

技巧一：先用 Bootloader 验证串口通路。在配置内核早期打印之前，先确认 Bootloader 的串口输出是正常的。如果 Bootloader 都出不来，那问题在硬件层面，跟内核配置无关。

技巧二：保留一份能工作的配置作为基准。每次修改早期打印配置时，保留一份已知能工作的配置。一旦新配置出问题，可以快速回退，避免在多个变量之间迷失。

技巧三：用示波器或者逻辑分析仪抓串口波形。如果软件层面排查了一圈都没找到问题，用示波器看一下串口 TX 引脚上有没有波形。有波形但乱码，说明配置参数不对；完全没波形，说明数据根本没写出去。

技巧四：注意内核版本差异。不同内核版本的早期打印机制可能有变化，特别是earlycon的配置语法。在升级内核版本时，务必重新确认早期打印配置是否仍然有效。

技巧五：产品化阶段记得关闭或精简早期打印。早期打印在开发阶段是利器，但在产品化阶段可能暴露敏感信息或者影响启动速度。建议在产品固件中关闭早期打印，或者只保留最低级别的输出。

我在最近一个项目中遇到过一个很隐蔽的问题：早期打印在开发板上工作正常，但到了定制板上就完全没输出。排查了很久才发现，定制板把串口引脚复用到了另一个控制器上，地址变了。这个教训告诉我，硬件变更后第一件事就是重新确认串口地址和引脚配置，不要假设和开发板一样。

另外一个值得注意的点是，有些平台的 Bootloader 会在启动内核之前重新配置串口，导致内核早期打印的配置被覆盖。这种情况下，要么修改 Bootloader 让它不要动串口，要么在内核早期打印配置中使用和 Bootloader 相同的参数。我一般倾向于后者，因为改 Bootloader 的风险更大。

关于日志级别的控制，早期打印阶段其实可以通过loglevel参数来间接影响。虽然早期控制台本身不解析日志级别，但内核在早期阶段输出的信息量是可以通过quiet或者debug参数来调节的。如果你觉得早期输出太多，加一个quiet参数能精简不少。反过来，如果需要更详细的输出，加debug参数会让内核在早期阶段打印更多调试信息。

还有一点关于earlycon和设备树的关系需要澄清：当你在启动参数中写了earlycon但没有指定具体参数时，内核会尝试从设备树的stdout-path中获取配置。这意味着如果你在设备树里配好了stdout-path，启动参数里只需要写一个裸的earlycon就能工作。这个技巧在需要频繁切换调试串口的场景下特别有用，改设备树比改启动参数更方便。

最后说一个关于输出缓冲的问题。早期打印通常是直接写硬件寄存器，没有缓冲。这意味着每个字符的写出都是同步的，速度受限于波特率。如果你在早期阶段打印大量信息，启动时间会明显变长。我实测过，在 115200 波特率下，打印 1000 个字符大约需要 87 毫秒。如果早期打印输出上万字符，启动时间会增加将近一秒。这在调试时无所谓，但在产品化阶段需要考虑。