MTK SoC平台开发实战：启动链路、编译环境与刷机避坑指南

简介：这是一份源自2024年国际固态电路会议（ISSCC）的官方论文，聚焦联发科技基于4纳米工艺打造的3.4GHz Tri-Gear全乱序ARMv9.2 CPU子系统，并说明其在5G移动SoC中的集成方案。内容适合芯片设计、移动处理器架构方向的工程师与研究人员研读。文档详细解析了高性能核心与效率核心的搭配逻辑，以及逻辑SRAM、标准单元改进、高带宽电压控制、双轨均衡器、硬件DVFS与PMIC被动放电等关键电路技术。性能数据方面，高性能核心较前代实现单线程IPC提升15%、功耗降低38%、峰值性能提升16%；效率核心则实现峰值性能提升172%、功耗节省68%。资源共1个PDF文件，压缩包约29.94MB，已有157人学习。通过这篇论文，读者能系统掌握旗舰手机SoC从处理器架构到电路全链路优化的方法，对学术研究或工业实践均有参考价值。

1. MTK SoC Platform 是什么：先别急着编译，看这条启动链路

很多工程师第一次接手 MTK SoC Platform（源码里有时写成 mtk soc paltform）项目，都会照着快速指南敲编译命令。而我看到的是，MTK SoC 平台真正难的从来不是编译，而是从上电到 Android 起来的这条启动链路。它决定开机速度、稳定性，也决定你改一行设备树能不能生效。这篇文章把平台开发的基本盘拆开：代码结构、编译环境、分区布局、启动时序，以及五条刷机变砖级别的踩坑记录。适合刚开始做 BSP、驱动移植或系统集成的工程师，新手可以按步骤跑通，熟手可以跳过基础概念直接看避坑和调试技巧。

2. 平台技术栈与源码结构：先认清你在哪一层，再决定改哪里

2.1 从硬件到应用的五个层级

MTK SoC 平台不是一颗独立 CPU，而是把 CPU、GPU、Modem、ISP、NPU 全部集成在同一片 SoC 里的完整硬件系统。拿到平台之后，最常见的问题不是“不会编译”，而是搞不清改动应该落在哪一层。一个用户态功能异常，有人会去改内核驱动；一个无法开机的故障，有人一整夜都在看系统服务日志。两个方向都容易跑偏。

为了避免这种情况，我习惯把整个平台切成五层来看：硬件层、引导层、内核层、供应商适配层、用户空间。硬件层包括参考板原理图、GPIO、电源树和时钟树；引导层包括 BootROM、Preloader、ATF 和 LK；内核层是 Linux 内核本身，加上厂商对各类外设控制器的扩展驱动；供应商适配层是 camera、audio、RIL 等硬件能力对 Android HAL 的封装；用户空间则是 Android Framework 和你的应用程序。

这五层的边界很重要。比如你要改一个 GPIO 口，可能只是改设备树里的 pinctrl；但如果你要改的是开机时某个外设的上电时序，那可能要改引导层，而不是内核。MTK SoC 平台和纯开源 SoC 平台最大的不同，就是引导层有大量闭源二进制。Preloader 里做了 DDR、PMIC、存储、安全启动相关的初始化，很多地方只开放配置参数，不开放源码。这导致一个问题：你无法像追踪代码调用那样追踪它，只能靠日志、配置项和现象来反推。

所以在接触一个平台之初，第一件事就是确认你手里的代码范围：哪些是完整源码，哪些是预编译库，哪些目录属于平台厂商私有模块。这个判断准确了，后面定位问题才会快。

判断分层有一个很实用的经验：看现象出现的时机。上电到亮 logo 之间出问题，基本都在引导层；亮 logo 后卡住，通常是内核或 HAL;进入系统后功能异常，才轮到用户空间和 Framework 的排查。很多人混淆前后，导致在不对的层里反复看代码，却一直找不到根因。

2.2 拿到平台源码后先摸清楚目录结构

当我们说“一个 MTK SoC 平台工程”，通常是指 Android BSP 代码树。这个树里既有公共代码，也有板级定制代码，还有平台厂商的私有驱动。常见做法是先按目录看归属，不急着编译。

cd <source-root> ls -F device/*/ 2>/dev/null | head -30 ls -F vendor/*/ 2>/dev/null | head -30 du -sh vendor/* 2>/dev/null | sort -h | tail -5

第一行列出板级产品目录，里面是某块板卡的硬件配置、产品专属内核配置、BoardConfig 之类的文件；第二行列出版商私有目录，MTK 平台在这方面通常体积巨大，里面放着大量编译好的动态库和配置文件；第三行快速看出哪些目录最占空间，通常就是你最需要关注，但也是最不敢乱动的区域。

只看出身还不够，还需要找到产品到底选了哪些模块。很多平台通过配置文件来开关芯片外设，比如某个功能开启后才会把对应的 vendor 库打进镜像。这个文件一般在device/或vendor/下的 mk 文件里，字段命名通常类似MTK_CAMERA_SUPPORT、MTK_AUDIO_TUNING。不要通过删文件的方式裁剪功能，正确做法是改这些配置开关。

如果你拿到的代码树里out目录已经存在，还存在一个风险：旧的编译缓存会干扰新改动。我习惯在切换大版本或更换分支之后，先清掉一次out，避免后面被各种“没改却有变化”的问题带偏。清的时候不要只删一个子目录，最好把整个out移走，因为里面的模块依赖链很复杂，只删一半反而容易留下更隐蔽的问题。

2.3 平台关键配置：BoardConfig、设备树与编译开关

平台定制的核心在三个地方：BoardConfig、设备树（dts 和 dtsi）、以及配套的编译开关。BoardConfig 里定义了分区大小、系统类型、内核 cmdline 的一部分、AVB 策略等。设备树则负责描述板级硬件和驱动需要的资源。

看板级配置的一个典型命令：

grep -E "BOARD_.*(SIZE|IMAGE|BUILD)|TARGET_.*(KERNEL|BOOT)" device/*/BoardConfig.mk 2>/dev/null | head -50

这里能看到你当前产品对 system、vendor、boot 分区的大小定义，以及是make bootimage还是走 vendor_boot。这些值一旦和刷机工具里的 scatter 不一致，后面就会出现刷机失败。

设备树方面，一个常见场景是调 GPIO 或串口。打开 dtsi 看 pinctrl 节点，确认 pin 的 mux、pull 和 drive strength。这里要注意，该平台的 pinctrl 驱动很多细节和主线 Linux 不完全一致，比如同一组引脚既做 GPIO 又做 UART，必须先查平台提供的 pin 复用表，不能靠猜。

很多初学者喜欢直接修改arch/arm64/boot/dts/下的文件，改完发现内核起不来。我的习惯是改之前先确认这个 dts 会被哪个配置加载，同一系列芯片下可能存在多份相近的 dts，改错了编译也不报错。验证设备树是否生效，可以在内核起来后执行：

adb shell ls -l /proc/device-tree/ adb shell cat /proc/device-tree/model 2>/dev/null

第一行能看到挂载在 /proc 下的设备树节点，第二行读一下模型名。如果和你的板卡不匹配，说明你改的 dts 根本没被编译进内核镜像。这种“改了没反应”的坑，比编译报错难查得多。

3. 搭建编译环境并跑通最小镜像构建

3.1 前置环境：别拿最新系统当主力编译机

MTK SoC 平台的构建脚本通常依赖一套固定的系统环境。平台厂商发布时一般会注明支持某个长期支持的 Ubuntu 版本，配套的交叉编译链、Python、GLibc 都针对这套环境验证过。不要总想着用最新版系统，很多构建脚本在新系统上会出现各种奇怪报错，而且报错信息往往和真实原因距离很远。

一个可靠的检查流程：

uname -m cat /proc/cpuinfo | grep -c processor free -g df -h /home lsb_release -a

uname -m确认是 64 位系统；grep -c processor看核心数；free -g看可用内存；df -h看磁盘剩余。BSP 工程编译对内存和磁盘都比较敏感，平台官方文档通常会在 README 里写建议值，但实际经验是 8 核 CPU、16G 内存起步，全量编译时 32G 内存更稳。磁盘最好给out目录留出 100G 以上，因为中间产物比最终镜像大得多。

平台自带的 prebuilts 工具链会管理交叉编译器，所以你不需要自己装 GCC。最怕的是你自己修改系统默认 GCC，导致部分编译目标报stdin错误或链接失败。遇到这类问题，第一选择是在干净环境重跑，而不是去找补丁。

还有一点容易忽略：不要在一个已经有旧out的代码树里直接切新分支。不同分支对 GCC 版本、Python 版本、模块列表的依赖不同，旧缓存轻则让你多编译几分钟，重则把错误的产物带进镜像。我一般会先执行环境检查，再看 git 状态，确认工作区干净后再开始。

3.2 初始化编译环境和最小构建命令

拿到代码树，常见做法是基于 AOSP 的构建体系操作。第一步加载环境：

source build/envsetup.sh lunch <product>-userdebug make -j$(nproc) 2>&1 | tee build.log

source导入构建环境，lunch选择产品与构建类型。userdebug适合调试，因为它保留部分调试能力但接近 user 版行为。make -j$(nproc)用所有核心并行，但如果你的机器在编译中触发 OOM，先降为-j4或-j8，不要硬扛。tee build.log保证日志不会因为终端滚动而丢失，出问题时可以从build.log翻最后一次成功的输出。

全量编译一次很耗时间。如果只是在调试内核和驱动，可以只编译单个镜像。编译 boot 的常见做法：

source build/envsetup.sh lunch <product>-userdebug make bootimage -j8

这条命令一般几分钟到十几分钟完成，改动内核后用它验证最省事。刷机时只要把新的 boot.img 刷进 boot 分区，不影响 data 和 system。调试早期想让系统起来，第二步可以编译：

make vendorimage systemimage -j8

但建议先把 boot 和内核相关的板级基础跑通，再上完整系统。完整系统编译时间最长，而且一旦出问题，错误日志里可能一半是编译缓存相关的信息，排查成本高。

增量编译也有技巧。如果你只改了 vendor 下的一个模块，可以不重新打包整个 vendor.img，而是先编译出模块再手动 push：

make <module_name> -j8 adb remount adb push out/target/product/<product>/system/lib64/<module_name>.so /system/lib64/

注意不是所有平台都允许直接 remount，尤其是开启 AVB 后，system 分区只读。遇到这种情况，最稳妥的方式是重新生成并刷入systemimage。我个人的习惯是：改动少时用 push 验证，改动多时直接编译整个镜像，避免 push 一半时模块依赖断裂。

3.3 编译产物、常见失败信号

编译完成后，主要镜像在out/target/product/<product>/下。你要关注的通常是这几个：

编译失败常见有三种信号。一是链接阶段出现多个 .o 文件冲突，多半是你同时改动了公共代码和平台私有代码，导致符号重复；二是 make 报告缺某个 mk 文件或变量未定义，多半是lunch选择的产品配置不完整；三是磁盘满导致的No space left on device，此时 out 目录残留大量半成品。

遇到这类失败不要反复试同一命令，先看最后 50 行日志：

tail -n 50 build.log grep -iE "error:|failed|no space" build.log | tail -20

第二次执行建议先make clean或删掉对应的局部 out 目录，再重新初始化。很多平台还有出包目标，比如 dist 包，但调试期不需要。只要镜像能刷进板子、能开机，就说明最小构建链路已经通了。

4. 启动链路与分区布局：看懂每一步打印，才能定位变砖点

4.1 启动链路的五个阶段

MTK SoC 平台的启动流程可以用五个阶段概括。BootROM 烧在芯片内部，上电后先从存储介质找到 preloader 并加载到 SRAM；然后 Preloader 负责 DDR、PMIC、时钟初始化，并根据分区表加载 LK；LK 负责显示开机画面、检测按键、提供下载入口，再把 kernel 镜像加载到内存；内核起来之后挂载 ramdisk，按设备树初始化驱动；最后 Android init 挂载分区，启动 Zygote 和系统服务。

每个阶段都有对应的日志输出位置。BootROM 阶段基本无输出，Preloader 阶段通过串口输出少量初始化日志；LK 阶段会打出带[0.000]时间戳的行；内核之后可以用dmesg查看。定位问题第一步就是判断系统停在哪一阶段，而不是直接看 crash log。比如停在 Preloader，你刷再多的 debuggable boot.img 都没用。

我常用一张简表来快速判断阶段归属：

这张表不绝对，但能帮你把问题先切到正确的一层。很多白板机，就是因为只关注内核打印，却不知道 preloader 早就死了。

4.2 分区表与镜像对应关系

平台刷机依赖 scatter 文件描述的分区布局。常见分区如下：

分区表出现不一致是刷机失败的常见原因。改产品分区大小时，要保证 BoardConfig 与刷机工具的 scatter 同步。否则 fastboot 或下载工具会在不同阶段报出错误。有些平台还允许动态分区，system、vendor 等逻辑分区来自 super 分区；此时你还得关注 super 的大小。

一个常见误操作是把 persist 分区随手格式化，原本的传感器校准数据、NVRAM 数据全部丢失，之后开机速度变慢，个别传感器失效。这种问题不会让板子变砖，但很难恢复，需要回到产线重新校准。所以量产阶段我基本不碰这些分区。

4.3 在已开机的板子上核对分区

不刷机也能检查当前实际生效的分区。用 adb 连接目标机：

adb shell cat /proc/partitions adb shell ls -l /dev/block/by-name/ | head -40

第一行看系统实际挂载的分区和大小；第二行看别名指向的 block 设备。如果你刚改过 BoardConfig，并且只刷了 system，用这个命令能立刻看到新旧分区大小是否错位。平台厂商有些分区没有在 by-name 里公开，这时用/dev/block/mmcblk0pX结合设备树或串口日志判断。

如果板子处于 fastboot 模式，也可以用：

fastboot getvar all

在输出里找到 partition 相关的变量。注意 fastboot 下看到的分区命名可能与 Android 侧不同，但分区顺序通常一致。只要当前系统能开机，优先用/proc/partitions验证，它最接近真实内容。

调试阶段还有一个实用动作：把当前分区表完整导出，备份一份在本地。因为平台代码更新频繁，新版代码可能默默改了分区大小，有了备份对照，你能第一时间知道是哪次改动破坏了兼容性。

4.4 抓取串口启动日志的通用步骤

启动早期还没到内核时，只能靠串口。串口参数通常是 115200 8N1。接线时确认用的是方案指定的调试口，不同板卡的 UART 编号不一样。抓日志命令：

sudo screen /dev/ttyUSB0 115200

screen直接连串口，方便、副作用小。开机时能看到从 Preloader 到 LK 再到 kernel 的连续输出。也可以先把日志落盘：

script -c "screen /dev/ttyUSB0 115200" uart_$(date +%F_%H%M).log

如果屏幕无输出但系统能开，优先怀疑接线和波特率，而不是引导程序没有日志。另外，串口日志中常常混有厂商协议帧，不要看到乱码就认为串口坏。真正的问题排查应该以关键字为准，比如 DDR、PARTITION、LK、kernel 等。

我习惯在抓日志前用一根短接线把 TX、RX 交叉，并确认没有接错 GND。很多串口无输出的问题，最后发现只是 RX 和 TX 接反。

5. 平台开发避坑：5个我把板子刷黑之后才明白的问题

5.1 改了内核配置，make bootimage 后刷进去不生效

现象：在 kernel 目录改了 defconfig，打开一个驱动，编译出的 boot.img 也变了，刷机后 dmesg 显示驱动没加载。

原因：平台的内核配置可能被多层 mk 文件覆盖。你改的 kernel 配置并不一定是最终参与编译的配置文件，真正的配置可能在 product 级或 vendor 级文件中被单独指定。

解决：先执行一次完整编译并保留环境，在 out 目录里找到实际生成的内核.config，确认你的改动有没有进入最终内核。如果没有，就在产品 mk 和 board 配置里找TARGET_KERNEL_CONFIG或等价的变量，看看它最终指向哪个文件。改完之后，建议直接查镜像内容：

grep -a "CONFIG_YOUR_DRIVER" out/target/product/<product>/obj/KERNEL_OBJ/.config

不要只对比源码里的 defconfig。只要KERNEL_OBJ/.config里没有你的配置，刷进去肯定不生效，这一步能省下一整轮刷机时间。

5.2 刷了新 preloader，整机黑屏不开机

现象：为了调整 DDR 频率或电源参数，重编了 preloader 并刷入，之后机器不充电、不亮屏，连接电脑也可能没有任何反应。

原因：Preloader 里做的 DDR 校准失败，BootROM 无法把 Preloader 完整拉起。板子退化成白板，普通 fastboot 根本进不去。

解决：使用平台下载工具强制进入下载模式，通常需要按住特定按键组合或短接测试点，重刷回原厂 preloader。核心教训是：改 preloader 前必须先把当前可用的原厂 scatter 和原厂 preloader 备份好，并且第一次验证时要单独刷 preloader，不要把它和 system 一起刷。因为如果 preloader 不对，之后刷什么都白搭。

5.3 刷机工具报 partition not found

现象：同一套刷机包在 A 板上正常，在 B 板上报找不到某个分区，或者提示分区大小不匹配。

原因：两块板子用的分区表不一致。量产后的工程板可能更新过 partition 配置，而你手里的镜像和 scatter 还是旧版本。

解决：先从能开机的板子上导出实际分区表，和当前 scatter 做对比。如果代码树里的 BoardConfig 已经改了分区大小，刷机工具里也要同步更新。对比命令：

adb shell cat /proc/partitions

把每个分区的大小与 scatter 中的linear_start_addr、partition_size对齐。不一致的项要同步，否则刷机工具会先报错，有些工具还会要求手动忽略错误，这时候很容易刷出半成品镜像。

5.4 串口没有任何输出，但板子能正常开机

现象：系统启动正常，接上 USB 转串口后屏幕什么都没有，甚至怀疑是开发板没有输出。

原因：调试口选错。很多板卡有多路 UART，默认 console 输出在某个特定 UART 上，你接到的可能是第二路或第三路，当然没日志。

解决：查原理图确认 UART 编号，或者从设备树里搜 stdout-path、console= 相关的配置，确认调试口具体是哪个。另外检查 USB 转串口模块的 RX 是否接板子的 TX，板子的 TX 必须接模块的 RX。交叉接错是最常见的低级坑。

5.5 vendor 分区刷入后部分 HAL 服务崩溃，logcat 只有 could not load

现象：手动把新 vendor.img 刷到旧 system 上，开机后蓝牙、Wi-Fi 或相机服务崩溃，logcat 提示某个 .so 无法加载。

原因：平台闭源库通常同时依赖 vendor 内其他库和内核接口。单独替换 vendor 分区容易造成库版本对不上，尤其当 system 和 vendor 来自不同构建期时，依赖关系很容易断裂。

解决：调试时不要混合刷写。尽量刷同一套完整镜像，至少保证 boot、vendor、system 来自同一次构建。如果必须混合，先用依赖检查工具看 .so 的引用是否齐全，再看内核接口版本是否匹配。最保险的方式是重新构建整套镜像，而不是单独 patch 一个 vendor。

6. 进阶技巧：用一条串口日志快速定位启动卡死点

所有平台启动卡死，本质都是卡在某一段初始化。与其一遍遍看全量日志，不如先确认在哪一段停住。这里有一个非常实用的方法：抓串口日志时，不仅看内容，还要看最后一条完整打印。它往往直接告诉你卡在哪一行。

如果是能进内核的卡死，我会连 adb 后快速看内核的启动时间分布：

adb shell cat /proc/boottime 2>/dev/null

这个节点在部分平台上会给出各个初始化阶段消耗的时间。如果该节点不存在，就靠串口打印分段。Preloader 卡住通常停在 DDR 校准相关行附近，LK 卡住会停在加载 boot.img 相关行附近，内核卡住则停在某个驱动 probe 的打印附近。

我习惯抓日志永远保留两份，一份用 screen 看实时，一份用 script 落盘。等到板子死掉后再回头看，落盘文件是唯一的线索。另一个习惯是把 console 波特率、RX/TX 线序、保存路径写在一个固定笔记里，每次拿板子先对一遍，避免低级错误反复发生。

如果你的平台支持独立运行 LK 和 kernel，调试前期我会建议只验证 preloader 和 boot 两个分区，能开机再看完整系统。这样缩小变砖范围，也让你对启动链路越来越有数。我做平台升级时，第一个版本永远只刷 preloader 和 boot，确认引导链路没问题后才上 system 和 vendor。这个习惯帮我挡掉了不少“刷了整套镜像后不知道该怪谁”的局面。

希望帮到你。

本文还有配套的精品资源，点击获取