MTK Fastboot底层揭秘：从LK启动到USB命令处理的完整代码解析

MTK Fastboot底层揭秘：从LK启动到USB命令处理的完整代码解析

如果你曾经尝试过为MTK平台的设备定制Bootloader，或者只是单纯好奇手机在按下电源键到系统启动之间，那块小小的引导程序究竟做了什么，那么这篇文章就是为你准备的。我们不会停留在“Fastboot是个刷机工具”的层面，而是要拿起“手术刀”，深入到联发科平台Little Kernel（LK）的源代码中，去亲眼看看Fastboot模式是如何从芯片上电的一刻开始被构建，又是如何通过USB线与你的电脑对话，执行一个个看似简单的flash或boot命令的。这个过程充满了精妙的架构设计和底层交互细节，理解它不仅能让你在设备变砖时多一份从容，更能让你对嵌入式系统的启动链有一个透彻的认知。

1. 旅程的起点：LK引导程序与kmain的召唤

当MTK设备的电源键被按下，CPU从固定的复位向量地址开始执行，经过一系列极其底层的硬件初始化（通常由汇编代码完成，如crt0.S），最终的控制权会交到C语言的入口——kmain()函数手中。这个函数位于LK的main.c中，它是整个引导程序世界的主宰。

kmain()做的第一件事是为操作系统（此时就是LK自身）的运行准备一个基本环境：设置栈、初始化内存管理、配置中断控制器等。但这只是搭建舞台，真正的“演员”——各种功能模块——还没有登场。于是，它创建了第一个内核线程：

thread_t *thread_bs2 = thread_create("bootstrap2", &bootstrap2, NULL, DEFAULT_PRIORITY, DEFAULT_STACK_SIZE);

这个名为bootstrap2的线程，肩负着第二阶段初始化的重任。在线程调度器启动后，bootstrap2()函数被调用，其核心任务之一是调用apps_init()。这里就是理解LK模块化架构的关键。LK并非一个铁板一块的单体程序，而是由许多独立的“应用”（app）组成的。每个app负责一个特定的功能，比如显示驱动、按键扫描、电池管理，以及我们最关心的——Android引导（aboot）和Fastboot。

apps_init()函数的工作流程清晰而有力：

1. 初始化所有app：遍历一个特殊的内存区域（由链接脚本定义），调用每个app描述符中的init函数。这相当于给所有演员化妆、熟悉剧本。
2. 启动标记为“开机启动”的app：再次遍历，对于那些设置了entry函数且没有APP_FLAG_DONT_START_ON_BOOT标志的app，调用start_app将其放入调度队列。这相当于导演喊“Action！”，让该上场的演员开始表演。

那么，这些app是如何被收集到一起的呢？奥秘在于链接器脚本（.ld文件）和宏定义。在MTK LK的链接脚本中，你会找到类似这样的段落：

__apps_start = .;
KEEP (*(.apps))
__apps_end = .;

这指示链接器将所有输入目标文件中，被标记在名为.apps的节（section）里的数据，连续地存放在最终镜像的某个地址段，并用__apps_start和__apps_end这两个符号记录其起止地址。而一个app如何将自己放入这个节呢？通过app.h中定义的宏：

#define APP_START(appname) const struct app_descriptor _app_##appname __SECTION(".apps") __USED = { .name = #appname,
#define APP_END(appname) };

开发者用APP_START和APP_END包裹一个app_descriptor结构体变量，这个变量就会被自动放置到.apps节中。