1. 项目概述从Pre-loader到Lk的启动探秘最近在折腾一块基于MTK平台的开发板想给它移植个新系统结果第一步就卡在了bootloader上。系统死活起不来串口日志停在某个神秘阶段就没了下文。这让我不得不静下心来重新梳理一遍MTK这套独特的启动链尤其是从Pre-loader到Little KernelLk这段“黑盒”过程。很多开发者包括曾经的我对这段流程要么一知半解要么直接依赖原厂提供的二进制文件出了问题根本无从下手。这次我决定把踩过的坑、读过的代码和逻辑梳理清楚形成这份分析笔记。如果你也在和MTK的bootloader较劲或者单纯对嵌入式系统启动的底层细节感兴趣希望这篇从实践出发的梳理能给你带来一些清晰的思路和实用的调试方法。MTK平台的启动流程因其高度集成和商业闭源的特点相比其他开源平台如高通、Rockchip显得更为“神秘”。其中Pre-loader和Lk是两个承上启下的关键阶段。Pre-loader是芯片上电后最早运行的代码肩负着最基础的硬件初始化和加载后续镜像的重任而Lk则是一个轻量级的引导加载器负责初始化更复杂的硬件、加载内核或进入fastboot等模式。理解它们如何协作是解决启动失败、进行深度定制比如解锁、刷机乃至安全研究的基础。接下来我将结合代码逻辑、串口日志和实际操作带你一步步拆解这个过程。2. MTK Bootloader整体架构与设计思路在深入细节之前我们得先站在高处看看MTK设计的这套启动链条的全貌。这不像在PC上BIOS之后就直接是GRUB。在资源受限、强调安全与效率的嵌入式设备上启动被精细地分成了多个阶段每个阶段各司其职有点像火箭的多级推进。2.1 多阶段启动的必然性为什么MTK要设计Pre-loader和Lk两个阶段而不是一个完整的bootloader这背后有几个核心考量安全隔离与最小化信任根Pre-loader是芯片ROM Code固化在芯片内部的初始代码加载的第一段外部可执行代码。它的代码量极小功能极简只做最必要的事。这种设计符合安全启动的理念将信任链的起点尽可能缩小。即使Pre-loader被篡改由于其功能有限造成的破坏也相对可控。Lk则在Pre-loader验证通过后被加载承担更复杂的任务。硬件初始化的阶段性启动初期的硬件环境非常“脆弱”。DRAM尚未初始化CPU可能运行在低速模式。Pre-loader负责用最保守、最稳定的配置初始化关键硬件如时钟、内存控制器为Lk准备好一个可以“宽敞”运行的环境比如将自身从SRAM搬移到DRAM。Lk则可以利用DRAM进行更全面、更复杂的硬件初始化如显示、USB、存储设备等。代码体积与存储限制Pre-loader通常存储在Boot ROM或芯片内部SRAM可寻址的特定存储区域如eMMC的boot分区。这些区域空间有限。一个极简的Pre-loader可以确保被可靠加载。完整的引导功能则由体积更大的Lk在DRAM中实现。灵活性与可扩展性分离设计使得两部分可以独立更新尽管Pre-loader更新风险极高。同时这种架构也便于支持多种启动模式正常启动、Recovery模式、Fastboot模式、Meta模式等这些模式判断和路由逻辑通常在Lk中实现。MTK的典型启动流程可以简化为芯片ROM Code - Pre-loader - Lk - Linux Kernel。我们今天聚焦的就是中间那两个箭头。2.2 Pre-loader与Lk的职责划分理解它们各自干什么是分析一切问题的基础。我画了一个简单的职责分工表这比纯文字描述更直观阶段主要载体运行环境核心职责关键输出Pre-loader通常为preloader.bin芯片内部SRAM1. 初始化最基础时钟、串口用于早期调试。2. 初始化DRAM控制器。3. 从存储设备eMMC/UFS加载Lk镜像到DRAM。4. 验证Lk镜像的完整性如果使能安全启动。5. 跳转到Lk入口地址。一个已初始化的DRAM环境以及位于DRAM中的Lk镜像。Little Kernel (Lk)通常为lk.bin或bootloader.imgDRAM1. 完成复杂的硬件初始化显示、USB、按键、PMIC等。2. 解析分区表定位内核、设备树等镜像。3. 实现Fastboot协议支持刷机。4. 显示启动界面Logo。5. 加载并验证内核最后跳转到内核。初始化完成的硬件平台以及传递给内核的启动参数。注意不同MTK芯片平台如MT6572, MT6735, MT6765, MT6785等的具体实现会有差异但这份职责划分的基本逻辑是相通的。在查找资料和代码时务必确认你的芯片平台。3. Pre-loader深度解析上电后的第一个脚印Pre-loader是启动过程中我们能够分析和定制的第一个环节。它的代码通常部分开源例如在MTK发布的Android源代码包中位于vendor/mediatek/proprietary/bootable/bootloader/preloader目录下这给了我们一窥究竟的机会。3.1 Pre-loader的入口与初始化芯片上电后固化在ROM中的代码会从预先定好的存储介质地址比如eMMC的boot0分区加载一小段代码到内部SRAM中执行这就是Pre-loader。它的入口函数通常是main()位于platform/xxx/src/core/main.cxxx为平台名。它做的第一件事往往是关闭看门狗、配置最基本的主时钟和串口时钟。这里有个关键点此时DRAM还不能用所以代码里不能有全局变量初始化因为.bss段在DRAM里函数调用栈也必须在SRAM内。因此你会看到很多用宏定义的“静态”配置和小心翼翼的内存操作。串口初始化是调试的生命线。Pre-loader会初始化UART0或UART1输出最早的调试信息。如果你在串口工具上看到类似[PL]或[PRELOADER]开头的日志恭喜你Pre-loader已经跑起来了。如果什么都没看到那问题可能出在更早的ROM阶段或硬件本身如电源、晶振。// 示例性的伪代码逻辑非实际代码 void main(void) { // 1. 关闭看门狗防止复位 watchdog_disable(); // 2. 初始化基础时钟和串口0波特率通常是115200或921600 clock_init_early(); uart_init(CONFIG_DEBUG_UART_PORT, 115200); // 3. 打印第一个标志性日志 uart_puts([PL] Pre-loader start\n); // 4. 初始化DRAM控制器 dram_init(); // 5. 从存储设备加载Lk load_lk_image(); // 6. 验证Lk如果使能了安全启动 if (secure_boot_enabled()) { if (!verify_lk_signature()) { uart_puts([PL] Lk verification FAILED!\n); while(1); // 验证失败死循环 } } // 7. 跳转到Lk jump_to_lk(); }3.2 DRAM初始化为Lk铺平道路这是Pre-loader最核心也最容易出错的任务之一。dram_init()函数会读取预先烧录在设备中的DRAM校准参数。这些参数是在工厂生产时通过专用工具如MTK的ATE工具对每一片PCBA进行测试后写入到设备特定存储区如eMMC的RPMB分区或芯片efuse的。它们包含了针对这块特定板子的DRAM时序、阻抗等最优参数。实操心得如果你是自己画的核心板或开发板在第一次启动前必须先使用ATE工具进行DRAM校准并将生成的参数烧录进去。否则Pre-loader无法正确初始化DRAM后续所有步骤都无从谈起。这也是很多DIY玩家移植MTK平台的第一道难关。日志里如果看到[PL] DRAM init failed或类似的错误几乎可以确定是校准参数问题。初始化成功后Pre-loader会将自己的一部分关键数据如果需要或者直接准备将Lk加载到DRAM的指定地址。这个地址是链接脚本里定义好的必须和Lk镜像的加载地址LOAD_ADDRESS完全一致。3.3 加载与验证Lk镜像Pre-loader需要知道去哪里找Lk镜像。这个信息通常硬编码在Pre-loader的代码中或者通过某个头结构定义。在MTK的方案中Lk镜像通常位于eMMC的MBR之后、第一个分区之前的某个固定偏移处或者在一个名为bootloader的分区里。load_lk_image()函数会调用底层存储驱动如eMMC/SD卡驱动去读取这个区域的二进制数据。这里涉及到存储设备的初始化对于eMMC可能需要配置为HS200/HS400高速模式以提高加载速度。如果项目启用了安全启动Secure Boot在跳转之前Pre-loader会使用芯片内置的密码学引擎如SHA256, RSA对Lk镜像的签名进行验证。验证失败则会挂起防止恶意代码执行。这也是为什么未经官方签名的第三方Recovery或Bootloader无法在锁BL的设备上启动的原因。3.4 跳转权力的交接最后jump_to_lk()函数执行一个简单的指针跳转。它会将Lk的入口地址通常是镜像加载地址一个小的偏移如0x40用于跳过镜像头强制转换为一个函数指针然后调用它。同时它可能会通过寄存器如ARM的r0, r1向Lk传递一些参数比如DRAM的大小、校准数据地址等。typedef void (*lk_entry_t)(int, int, void*); void jump_to_lk(void) { lk_entry_t lk_entry; uint32_t lk_load_addr get_lk_load_addr(); // 例如 0x40000000 uint32_t lk_entry_addr lk_load_addr LK_IMAGE_HEADER_SIZE; // 跳过头部 lk_entry (lk_entry_t)lk_entry_addr; // 清理Cache设置栈指针如果需要然后跳转 arch_disable_cache(); uart_puts([PL] Jump to Lk\n); lk_entry(0, 0, NULL); // 传递参数 // 正常情况下不会返回 }至此Pre-loader的任务完成CPU的控制权交给了Lk。4. LkLittle Kernel启动流程详解Lk是一个功能相对完整的引导加载器MTK对其进行了大量定制。它的源码在vendor/mediatek/proprietary/bootable/bootloader/lk目录下。相比Pre-loaderLk运行在宽敞的DRAM中可以链接标准C库实现复杂得多的功能。4.1 Lk的初始化建立完整运行时环境Lk的入口通常是kmain()或lk_main()。它首先要做的是建立完整的C运行时环境因为Pre-loader只提供了一个“裸”的硬件环境。架构相关初始化在arch/arm/start.S之类的汇编文件中设置异常向量表、初始化各模式下的栈指针、使能MMU内存管理单元和Cache。使能Cache对性能提升巨大因为后续加载内核等大文件会快很多。平台早期初始化调用platform_early_init()初始化中断控制器、定时器、更复杂的时钟树让CPU跑在最高频、以及GPIO等。这里会重新初始化串口可能切换到更高的波特率。内存管理系统初始化Lk有自己的内存分配器如heap。mem_init()会探测DRAM的实际大小和布局初始化堆为后续动态内存分配做准备。线程与定时器系统启动Lk是一个微内核支持多线程。thread_init()和timer_init()为异步任务如按键检测、USB枚举、显示刷新提供基础。在这个过程中串口日志前缀会从[PL]变为[LK]或没有前缀。通过日志可以清晰看到启动进度。4.2 关键子系统初始化环境准备好后Lk开始初始化各个关键的硬件子系统这些子系统决定了设备的功能和用户体验。显示Display与背光Backlight初始化MIPI-DSI接口点亮屏幕显示启动Logo通常是logo.bin。如果这里失败屏幕会是黑屏但串口日志可能正常。需要检查屏时序参数dtsi或lk/.../disp_drv.c中的配置和供电。存储设备Storage重新初始化eMMC/UFS并挂载文件系统如读取logo.bin可能需要FAT。Lk会读取分区表通常是GPT或MTK自定义的MBREBR建立起分区名到偏移量的映射。这是后续加载boot.img、recovery.img的基础。USB控制器初始化USB使其能够进入设备模式。这是Fastboot刷机功能的核心。当检测到USB连接和特定按键如音量减时Lk会进入Fastboot模式等待主机命令。电源管理PMIC与按键初始化PMIC芯片配置各路电源。扫描按键GPIO用于检测组合键如音量电源进入Recovery模式。安全相关如果之前Pre-loader做了安全验证Lk可能会继续验证内核。它也会初始化TrustZone相关环境为跳转到安全世界如TEE做准备。这些初始化工作通常是并行的由不同的线程驱动或按依赖顺序进行。在串口日志中你会看到一堆[DRV]或[INIT]开头的成功或失败信息。4.3 启动模式判断与路由所有硬件就绪后Lk需要决定下一步做什么。这就是启动模式判断逻辑通常在app/mt_boot/mt_boot.c之类的文件中。// 简化的模式判断逻辑 boot_mode_t boot_mode get_boot_mode(); switch (boot_mode) { case NORMAL_BOOT: load_and_boot_kernel(); // 正常启动内核 break; case RECOVERY_BOOT: load_and_boot_recovery(); // 启动Recovery分区 break; case FASTBOOT_BOOT: enter_fastboot_mode(); // 进入Fastboot等待USB命令 break; case META_BOOT: enter_meta_mode(); // 进入工厂测试模式 break; case ALARM_BOOT: // 关机闹钟启动 break; default: // 未知模式可能尝试正常启动或进入充电画面 break; }get_boot_mode()的判断依据包括按键状态长按音量和电源进入Recovery长按音量-和电源或连接USB进入Fastboot。特定寄存器或存储区域的值系统异常重启后可能会在RGU复位发生单元的寄存器或PMIC的某个寄存器中留下标志指示进入特殊模式。命令参数通过Fastboot命令fastboot oem append-cmdline ...设置的参数可能会影响下次启动模式。充电器插入状态如果只有充电器插入没有电池可能会直接进入充电画面不启动系统。4.4 加载与启动内核在正常启动模式下load_and_boot_kernel()函数开始工作定位内核镜像根据分区表找到boot分区或boot_a/boot_b在A/B设备中。读取镜像将boot.img读到DRAM的指定地址。boot.img是一个Android特有的格式它包含了一个kernel、一个ramdisk和一个可选的second stage如设备树DTB。解压与验证内核可能是压缩过的如Image.gz。Lk需要将其解压到最终的执行地址。如果使能了dm-verity或AVB这里会进行哈希验证。准备启动参数准备ATAGS或更现代的Flattened Device Tree (FDT)传递给内核。这些参数包含了内存布局、命令行参数 (cmdline)、硬件配置信息等。cmdline非常重要它定义了控制台、根文件系统位置、初始化进程等关键信息。跳转到内核关闭中断清理Cache然后通过一条汇编指令如bx r0跳转到内核的入口点。Lk的历史使命至此结束。5. 关键问题排查与调试技巧实录理论梳理得再清楚最终都要落到解决问题上。下面是我在调试Pre-loader和Lk启动问题时总结的一些常见故障点和排查手段。5.1 串口日志你的第一双眼睛没有串口日志调试启动问题就是盲人摸象。确保硬件连接正确TX/RX交叉GND共地波特率设置正确早期Pre-loader可能是115200Lk可能切换到921600。如果完全没日志检查板子供电是否正常核心电压是否到位。检查芯片的启动引脚BOOTMODE配置是否正确是否进入了下载模式而非正常启动模式。尝试更换波特率或使用示波器/逻辑分析仪抓取UART引脚波形看是否有数据发出。5.2 Pre-loader阶段常见问题问题串口有[PL]开头日志但很快停止没有[LK]日志。排查这通常是DRAM初始化失败或Lk加载失败。步骤仔细查看Pre-loader的最后几条日志是否有DRAM init passed或Load LK success等信息。如果没有DRAM成功日志重点怀疑DRAM校准参数。确认参数是否已烧录是否与板子使用的DRAM颗粒型号匹配。如果有DRAM成功日志但无LK加载成功日志检查存储设备。确认Lk镜像是否烧录到了正确的位置eMMC的boot分区或用户分区的特定偏移。可以使用读取命令如mmc read在Pre-loader代码中增加调试直接读取目标地址看数据是否正确。检查跳转地址。确认Pre-loader中定义的Lk加载地址是否与Lk镜像链接脚本中的地址一致。使用readelf -h lk.bin或objdump -f lk.bin查看Lk的入口地址。问题日志卡在[PL] Jump to Lk后没有任何输出。排查跳转成功但Lk一开始就崩溃了。最常见的原因是运行环境不匹配。步骤栈指针Pre-loader跳转前是否为Lk设置了正确的栈指针Lk的汇编入口代码是否正确地重新设置了栈Cache状态跳转前是否正确地无效化和清理了CacheCache状态不一致会导致取指错误。MMU如果Pre-loader使能了MMU跳转到Lk时MMU状态是怎样的Lk的代码是否期望一个特定的虚拟地址通常Pre-loader不会开启MMU或者使用恒等映射。使用JTAG调试器如果条件允许用JTAG在Lk入口点设断点单步执行查看第一条指令是否成功执行以及在哪条指令跑飞。5.3 Lk阶段常见问题问题串口有大量[LK]日志但卡在某个驱动初始化例如[DISPLAY] init error或[EMMC] init failed。排查特定硬件子系统初始化失败。步骤对照硬件原理图检查该硬件所需的电源、时钟、复位信号是否在Lk的初始化代码中正确配置。MTK平台的GPIO复用和供电控制非常复杂一个引脚配置错误就可能导致初始化失败。检查代码配置Lk的板级配置文件通常在platform/xxx/rules.mk和project/xxx.mk中是否打开了对应宏如MTK_XXX_SUPPORTyes。驱动代码中的时序参数、设备地址是否与硬件一致。分步调试在驱动初始化函数中增加更多日志缩小问题范围。例如在显示驱动中分别打印初始化MIPI控制器、发送初始化序列、点亮背光等步骤的结果。问题Lk启动后直接进入了Fastboot模式或Recovery模式而不是正常启动。排查启动模式判断逻辑出错。步骤检查按键首先确认是否有按键被意外按下或卡住测量按键GPIO的电平。检查重启原因查看PMIC或RGU寄存器确认上次重启是否是看门狗复位、内核恐慌panic等这些可能导致Lk选择进入Recovery。检查命令参数通过Fastboot设置的临时启动参数是否还残留可以尝试在Fastboot中执行fastboot oem append-cmdline 清空。检查存储标志有些设备会在misc分区或frp分区存放启动标志。用命令fastboot getvar all查看相关信息。问题Lk显示Logo后卡住无法加载内核。排查内核加载或验证失败。步骤查看最后日志Lk在跳转前通常会打印Jump to kernel以及内核地址等信息。确认这些信息是否打印。检查boot.img确认boot.img是否已正确烧录到boot分区。可以使用fastboot flash boot boot.img重新刷写。使用file命令或abootimg工具检查boot.img格式是否正确。检查启动参数特别是cmdline中的root和init参数是否正确。根文件系统设备是否正确指定如果使用ramdisk确认其是否被正确加载和解压。内核解压失败如果内核是压缩的解压失败会导致跳转后立即崩溃。检查Lk中解压算法的代码或者尝试使用未压缩的Image格式内核进行测试。5.4 实用调试技巧与工具修改代码增加调试日志这是最直接的方法。在关键函数入口、出口和错误分支添加dprintf(INFO, ...)或printf()。注意Pre-loader阶段可能只能用uart_puts。使用JTAG/SWD调试器对于Pre-loader和Lk的早期问题JTAG是无敌的。可以设置断点、查看内存、单步执行精准定位崩溃点。OpenOCD配合J-Link或DAPLink是性价比很高的选择。内存查看如果串口还能工作可以在代码中插入内存dump函数将关键数据结构或一片内存区域的内容通过串口打印出来分析其是否正确。利用LED或GPIO在代码不同阶段翻转一个GPIO用示波器测量其波形可以直观地看到代码执行到哪个阶段卡住。这被称为“GPIO点灯法”在早期没有串口时非常有用。对比法找一个能正常启动的同型号设备抓取其完整的串口日志与你的问题日志逐行对比往往能快速发现异常点。6. 进阶定制与开发中的核心考量当你不再满足于仅仅让系统跑起来而是想进行深度定制比如移植到新硬件、修改启动流程、开发自己的刷机工具时以下几个核心环节需要格外关注。6.1 链接地址与内存映射这是所有嵌入式启动代码的基石绝对不能错。Pre-loader它的链接地址VMA和加载地址LMA通常是一样的且必须在芯片内部SRAM的地址范围内例如0x200000。你需要仔细查看芯片数据手册的Memory Map章节。Lk它的加载地址由Pre-loader决定必须和链接脚本lk.ld中定义的起始地址一致。这个地址通常在DRAM的起始位置往上偏移一段如0x40000000要避开预留区域如ATF、TEE的加载地址。内核Lk加载内核的地址也必须符合内核的要求。对于ARM64 Linux这个地址通常是0x40080000即DRAM起始 512KB。这个地址需要在Lk的代码和内核的配置arch/arm64/configs/xxx_defconfig中的TEXT_OFFSET中保持一致。修改任何一方的地址都必须同步检查其他相关方。一个地址错误就会导致程序跑飞。6.2 分区表与存储布局MTK设备通常使用MBREBR的分区方案或者GPT。分区表定义了preloader、boot、recovery、system等镜像在存储设备上的精确位置。修改分区表如果你需要调整分区大小比如扩大system分区必须同时修改Lk代码中的分区表定义如platform/xxx/partition/partition.c。烧录工具如SP Flash Tool使用的分散加载文件scatter.txt。系统编译时生成的MTxxx_Android_scatter.txt。 三者必须完全一致否则会导致刷机失败或启动后找不到分区。实操心得在修改分区表后第一次烧录最好使用“Format All Download”选项确保整个存储布局被重新构建。如果只做Firmware Upgrade旧的分区信息可能残留导致冲突。6.3 安全启动与签名在消费级设备上安全启动是默认开启的。这意味着Pre-loader会验证Lk的签名Lk会验证内核的签名。开发阶段为了便于调试你可以在编译配置中关闭安全启动验证如设置MTK_SECURITY_BOOT_SUPPORTno。但务必注意这仅用于开发调试最终产品必须重新开启。生产与发布你需要MTK提供的签名工具和公司的私钥为你的Lk和内核镜像生成签名。没有正确签名的镜像在安全启动开启的设备上无法加载。这也是第三方ROM制作的最大法律和技术壁垒之一。6.4 性能优化点启动速度是用户体验的关键。在Lk阶段可以优化的点包括DRAM频率在Lk中尽早将DRAM频率提升到最高档位。存储接口速度正确配置eMMC的HS400模式或UFS的Gear。内核压缩使用压缩率与解压速度平衡的算法如lz4比gzip解压快很多。并行初始化利用Lk的多线程特性让显示初始化、USB枚举、存储设备读取等任务并行进行。Logo显示时机尽早显示Logo可以给用户“很快”的心理感受。可以在显示驱动初始化完成后立即显示一个静态Logo而不是等所有初始化完成。调试Pre-loader到Lk的启动过程就像在黑暗的迷宫中一步步点亮蜡烛。每一次成功的启动背后都是对硬件特性、软件逻辑和调试方法的深刻理解。这份笔记记录了我点亮其中几根蜡烛的过程希望能为你的探索之路提供一点微光。记住耐心和细致的观察串口日志永远是你最好的伙伴。当系统终于从串口吐出那期待已久的内核启动日志时所有的折腾都值了。