MTK源码包开发实战：从拆包、source到编译调试全攻略

简介面向 MediaTek 芯片平台开发者的源码资源包适合需要基于 MTK 硬件进行系统软件、应用层开发、调试与优化并希望理解底层驱动与编译流程的工程师使用。包内聚焦底层驱动、固件、库文件及示例代码同时包含 pl/pm 脚本、sh 脚本、C/C 头文件与源码、构建配置说明等共 857 个文件整体约 2.7MB以 rar 格式压缩打包。考虑到带宽限制包内未附带 MinGW 与 MSYS 等编译环境开发者可在 Windows 下自行准备 GNU 工具再依据包内构建脚本和编译说明完成源码的编译与链接。解压后可以看到 AP638 相关目录该目录对应 MediaTek 某一具体芯片型号围绕它可以快速定位驱动、固件和示例代码便于开展驱动调试、功能裁剪和系统定制。目前已有 731 人学习下载对于刚接触 MTK 平台的开发者来说这份源码包能够帮助理解芯片架构、驱动调用方式和构建脚本结构缩短环境搭建与代码阅读的探索周期也为后续二次开发和性能调优提供了可参考的基线。 第一次拿到MTK开发源码包很多人的反应是一样的怎么这么大我印象里一个MTK Android BSP工程解压完轻松三十、五十个G起步如果还带着完整的prebuild和vendor闭源代码占掉一整块固态硬盘都不稀奇。更让人无从下手的是源码包装好了、README也翻完了对着命令行却不知道先敲哪一句。这篇内容就是围绕“MTK开发源码包 source”这条主线把这几年在MTK平台上做驱动和系统开发时从拆包、source环境、编译到调试和读码的完整链路整理一遍给第一次接触MTK源码包的同学一份能直接照着操作的路线图。1. MTK源码包的真实形态从release note到目录树1.1 判断你拿到的是不是“对的包”MTK的源码包跟普通开源项目的发布方式很不一样。普通开源项目一个git clone就结束MTK这边往往是一整个Android工程或者BSPBoard Support Package工程用压缩分卷、repo仓库群、甚至内部FTP目录的形式发放。很多老工程师习惯把MTK的Android工程叫ALPS包这个称呼沿用了很多年实际上是Android Linux Platform Software的缩写它的命名里通常带平台名和版本号比如MT6785、MT8788之类。拿到源码包之后首先要干的事不是解压而是找release note。这个文本文件往往被放在包的根目录或者一个叫doc、release的文件夹里。release note里会写清楚这份源码包对应的芯片平台、Android版本、内核版本、modem版本以及所有驱动二进制文件对应的代码commit号。我见过太多人跳过这一步直接把包解压了然后编译最后编出来的系统跑起来各种奇怪问题回头一查才发现源码包和modem版本根本不匹配。版本匹配这件事用一句话概括MTK源码包是一个“组合包”内核、第三方驱动、modem固件、preloader、TEE等都是分开管理的。release note相当于这些组件之间的“锁”告诉你哪几个版本放在一起才是厂商验证过的组合。只要组合变了哪怕只是modem版本差一个小版本号都可能出现搜网异常、射频指标不达标这类看起来跟代码毫无关系的故障。1.2 目录树里最重要的一批目录解压完源码包你会面对一棵非常庞大的目录树。第一次进来很容易迷路但真正需要频繁进出其实就那几个kernel-x.y内核源码MTK一般会以kernel-4.14、kernel-4.19、kernel-5.10这样的目录名给出。驱动开发的大部分时间都泡在这里。device/mediatek硬件相关的Android设备配置包含mk文件、权限配置、fstab、init.*.rc等重要文件。vendor/mediatekMTK的平台私有代码包含proprietary目录里面是闭源二进制库和预编译ko还有大量的定制脚本。hardware/mediatekMTK贡献给Android HAL层的代码包括gralloc、camera、sensor等HAL实现。out编译输出目录编译出来的image、obj文件都在这。这个目录通常不随源码包分发是你自己编出来的。如果做的是老一些的MTK平台还会看到alps/这个传统目录名它是整个工程的根。新版平台可能改叫mtk_project之类的但整体逻辑是一样的。对新手来说我的建议是不要一开始就想着看懂整棵树。先把vendor/mediatek/proprietary/scripts和device/mediatek/build这两个脚本目录看明白因为你会反复用到它们。剩下的目录按需进用到哪个查哪个比漫无目地浏览效率高得多。1.3 拆包之后的首次体检解压完成之后我习惯做三件事。第一检查编译工具链是否随包携带。MTK有些源码包会把prebuilt编译器一起放在prebuilts/目录里有些则依赖你宿主机自己装的交叉编译链。用cat /etc/issue看一眼宿主机系统版本再对照release note里写的推荐系统避免一上来就在环境上浪费两天。第二确认文件权限。用ls -l检查一下build/envsetup.sh这类关键脚本是否有执行权限。从压缩包解压出来的文件权限有时会不对遇到Permission denied别急着改代码先看权限。第三做一次轻量编译可行性检查也就是跑一遍后面要讲的source和lunch流程只出配置、不实际编译。这样能尽早暴露环境和源码包本身的匹配问题比闷头跑两小时编译再报错要省时间得多。2. 让源码包“活”起来的source流程环境脚本才是入场券2.1 为什么不能直接敲make很多从标准AOSPAndroid Open Source Project玩过来的朋友习惯性地解压完源码就敲source build/envsetup.sh lunch make。这条组合拳在AOSP里没问题但到了MTK这边十有八九会在半路卡住。原因在于MTK的编译系统不是纯粹的标准AOSP。它在AOSP的基础上加了一层自己的构建框架用来处理modem镜像打包、分区表生成、preloader编译、GED和GPU等模块的版本合并等一系列私有逻辑。这些逻辑依赖大量以MTK_开头、以MTK_*_SUPPORT之类命名的环境变量而它们不会自动加载必须通过source脚本进入环境。所以source在MTK开发里不只是“载入环境变量”这么简单它实际上是一整套构建系统的入口。理解这一点你就知道为什么release note里总是强调要先source某一个脚本。不source你用的其实是残缺的编译环境source了MTK的构建框架才会把几百个编译开关注进来。2.2 从source build/envsetup.sh到./mk的标准流程MTK不同版本的标准流程有一点点差异但主干基本一致。以常见的MTK Android工程为例我一般这样操作cd 源码包根目录 source build/envsetup.sh lunchlunch之后会出现一个菜单列出当前工程支持的target列表比如full_mt6785-userdebug之类。输入对应序号回车即可。接下来就是MTK特有的那一步。很多新平台直接走make -j$(nproc)也可以编但如果你想编出带MTK私有逻辑的完整刷机包更稳妥的是用MTK的mk脚本./mk -oTARGET_BUILD_VARIANTuserdebug -t r new这条命令做了几件事-o指定编译变体-t r表示清理中间产物后重新编译new是编译目标会产出完整的image集合。如果只想做增量编译把new换成模块名或者用./mk mm 模块路径指定某个模块即可。增量编译对于日常调试能省下大量时间比如只改了内核跑一下./mk -t k或者默认的bootimage目标就够。有些新版本平台会推荐用source build/envsetup.sh lunch之后直接make pl lk kernel这样的分段编译策略原理是一样的先编preloader和lk再编内核最后汇编整个系统。分段编译的好处是报错定位快不会一整个流程全挂掉之后不知道该查哪块。2.3 source阶段的高频报错与正确处理我在多台机器上跑过这个流程遇到最多的报错其实不在代码而在环境。第一个是lunch列不出菜单或者只列出一两项。这种情况下先检查是否有vendor/mediatek/proprietary/scripts/build/下的脚本没被加载。某些版本要求在source build/envsetup.sh之后手动source一个平台特定脚本具体看release note。不要觉得多敲一条source很麻烦这是那个版本设计的一部分。第二个是磁盘空间不足。MTK编译过程非常吃空间out目录加产物20G起步很正常。用df -h提前看一眼别等编译到一半报No space left on device那是真的想砸键盘。第三个是JDK版本不匹配。老版本MTK工程要求JDK 8新版本要求JDK 11或17。如果你系统里同时装了多套JDKsource脚本可能选错。遇到Unsupported major.minor version这类报错基本可以断定是JDK版本问题。用update-alternatives --config java切到正确版本即可。还有一类报错跟源码本身无关但会让人误判成环境问题比如Windows下做开发时常见的freetype fatal error[PE1696]: cannot open source file sys/types.h这种报错在Windows上看MTK源码、用IDE或脚本做交叉解析时非常常见。原因是Windows环境里没有Linux的sys/types.h头文件解析器找不到内核头文件路径。这不是源码坏了而是你在Windows侧缺少对应的include路径配置。处理方式后面讲source insight时再细说这里先记住一个原则MTK源码包的主战场是LinuxWindows侧只能做代码阅读和轻量分析别指望在Windows下完整编译。3. 拿到源码后最容易踩的四个深水区sensor、手势唤醒、WIFI MAC、内存泄漏与dump3.1 sensor移植以GC5025为例源码包拿到手最常干的活儿之一就是移植新sensor。热词里提到gc5025这是格科微的一颗500万像素CMOS图像传感器我在MTK平台上接过类似的案子流程非常有代表性。第一步不是改代码而是确认sensor驱动在源码包里是否已经存在。老一些的MTK平台sensor驱动会放在vendor/mediatek/proprietary/custom/project/hal/imgsensor/下每个sensor一个文件夹。新平台则倾向于把sensor配置放到内核dts/dtsi里配合统一的imgsensor框架。GC5025这类sensor如果已经有现成的驱动目录那主要工作就是把它加到平台的编译列表里并在kd_camera_hw.c或对应的sensor列表文件里注册。第二步是上电时序和MCLK配置。这是新手最容易翻车的地方。sensor不上电、I2C不通、CLK没输出都会导致效果表现是黑屏或者图像花掉。用示波器量dvdd、avdd、dovdd、mclk四路信号和datasheet里的时序图逐个对齐。我遇到过sensor datasheet里上电时序要求reset脚拉低后等5ms再拉高而驱动里只等了1ms结果图像每隔几帧就抖一下排查了很久才抓到。第三步是效果调试。MTK平台有一套图像效果调校工具链通常包含在厂商提供的NVRAM和3A tuning参数里。这一步依赖厂商支持但作为系统驱动工程师至少要会确认tuning参数是否通过源码包里的camera_3a、isp相关配置正确加载了。3.2 双击唤醒驱动层到底发生了什么“mtk 手势双击唤醒”是我见过搜索量很高的需求。这个功能在MTK平台上通常依赖TP触摸屏固件的手势识别能力具体由TP方案商汇顶、新思、敦泰等的驱动和固件实现。从源码开发的角度你在内核驱动里要做的事是把手势事件从TP中断处理函数一路送到应用层。常见做法是在TP驱动中定义自定义事件类型比如#define GESTURE_DOUBLE_TAP KEY_WAKEUP input_report_key(ts-input_dev, GESTURE_DOUBLE_TAP, 1); input_sync(ts-input_dev); input_report_key(ts-input_dev, GESTURE_DOUBLE_TAP, 0); input_sync(ts-input_dev);然后上层在PhoneWindowManager或InputReader里监听这个键值点亮屏幕。整个链路里最隐蔽的问题有两个一个是TP固件没有使能手势功能导致内核根本收不到手势中断另一个是suspended状态下手势唤醒的电源域没保持。调试这个功能时先确认TP的gesture寄存器是否配置成功再查系统suspend流程是否把TP的电源给断了。3.3 WIFI MAC地址丢失NV与persist分区MTK平台丢WIFI MAC地址是几乎每个做产线的兄弟都遇到过的问题。这个问题的根子在于WIFI MAC地址一般存放在NVNon-Volatile分区或者persist分区而产线刷机、恢复出厂、系统升级都有可能动到这些分区。排查思路分两步。先确认MAC是真正的“丢了”还是驱动没读到。用ip link show wlan0看MAC是不是全零或者全是FF如果是基本可以确定NV读取路径出了问题。再查日志搜wifi、nvram相关的关键字找到驱动加载NV的路径。常见原因和解决办法也很集中NV分区数据被格式化需要重新写入包含WIFI MAC的NV数据或者用厂商的SN writer工具重新写入。MAC地址没有被正确写进NV只是驱动里读到了默认值重新刷写带正确MAC的NV bin文件。系统升级后NV分区格式不兼容确认升级包是否带了正确的NV升级逻辑。如果只是开发阶段临时测试也可以在驱动里通过模块参数直接指定MAC地址但这个方法只适合调试不能作为产线方案。3.4 内存泄漏与dump解析MTK平台的排查链路内存泄漏和解析dump是MTK平台调试里的硬仗。先讲内存泄漏。内核态内存泄漏我用的最多的是kmemleak这个工具在MTK内核里一般默认编译为模块或者是config选项。打开方式echo scan /sys/kernel/debug/kmemleak cat /sys/kernel/debug/kmemleak另外cat /proc/meminfo、cat /proc/buddyinfo、cat /proc/slabinfo这三连是基础快捷键能快速判断是page泄漏、slab泄漏还是ion/CMA的问题。MTK平台经常出现显存类泄漏可以重点关注cat /d/ion/heap和cat /proc/mtk_meminfo这类节点。用户态内存泄漏MTK工程里可以用malloc_debug给目标进程设置libc.debug.malloc.options再复现问题最后用showmap、pss之类的工具抓进程内存情况。定位到大概率泄漏的代码路径后用ASanAddressSanitizer做定向编译往往是最后一击。再讲dump解析。MTK平台最常见的两类dump一类是内核panic一类是用户态tombstone。内核panic之后先抓/sys/fs/pstore/console-ramoops-0这类节点里面是内核最后一次完整打印日志。log里找到Kernel panic - not syncing那一行再往前翻几行就是panic现场。有了PC指针之后用交叉工具链反汇编或者addr2line转成代码行aarch64-linux-gnu-addr2line -e out/target/product/platform/obj/kernel/linux-4.19/vmlinux panic地址用户态的tombstone一般落在/data/tombstones/文件名带序号里面已经有完整的backtrace。配合ndk-stack或者直接看#00 pc行再对照带符号的so文件能定位到具体函数。MTK有些平台会额外生成coredump用厂商的T32脚本或者gdb分析都行但日常tombstoneaddr2line已经能覆盖大部分问题。4. 用source insight啃MTK源码的正确姿势工程配置与避坑4.1 为什么大工程一定要建好索引MTK源码包的代码量巨大光内核一个目录就有几万个文件。用grep虽然也能搜但看调用关系、查结构体定义、跳转函数实现source insight这类索引工具远比纯命令行高效。source insight在MTK开发圈里地位很稳尤其4.0版本之后对Linux内核这种大C工程的支持比早期版本好太多。热词里还有source insight4.0 使用教程、source insight4.0 安装破解这些高频搜索说明很多新手卡在了工具本身。我不主张去碰破解这些东西公司能买就买正版个人学习先用官方试用版即可重点是会用、配置对。4.2 source insight新建工程与目录过滤新建工程有一个关键技巧不要把整个源码包都塞进一个工程。正确做法是按模块建工程比如建一个内核工程只包含kernel-4.19/和必要的dts目录再建一个系统工程包含device/mediatek、vendor/mediatek、frameworks你关心的那几块。新建工程时用Project New Project然后在添加文件时用Add from Source Tree并只选中目标目录。对于内核工程建议把kernel-4.19/arch/你的架构里其他不相关的架构目录排除掉比如你做arm64就把arch/x86、arch/arm从工程里去掉。这样同步速度快非常多跳转也不会迷路。老版本source insight默认同步较慢4.0版本我已经习惯开启后台解析它会在你编辑代码的同时异步建立索引。如果发现跳转不准多半是同步没跑完按CtrlShiftS手动触发全量同步即可。4.3 头文件路径与常见编译报错处理source insight默认解析C/C代码时需要知道include路径。MTK内核代码里有大量#include linux/xxx.h、#include mtk_xxx.h这类头文件如果工程里没正确配置include路径函数声明和宏定义会解析不到表现就是符号跳转失效。在Options Preferences Languages C/C里把内核的这些路径加进去kernel-4.19/include kernel-4.19/include/uapi kernel-4.19/arch/arm64/include kernel-4.19/drivers/misc/mediatek/include这就是前面提到Windows下报cannot open source file sys/types.h时最直接的解决思路把Linux内核的include路径手动指给IDE或解析器。如果你在Windows侧还缺Linux头文件可以从源码包里抽出kernel-x.y/include和对应的架构头文件目录放到一个公共目录下再配置给source insight。另有一个小坑MTK的.dtsi文件后缀比较特殊source insight默认不把它当C文件处理。需要在Options File Type Options里把.dtsi和.dts关联到C/C文件类型否则设备树节点没法跳转。5. 个人实操经验让MTK源码包编译又快又稳的几条建议最后聊几条这几年实际跑MTK平台总结出的经验不算什么高深理论但每一条都实打实帮我省过时间。第一ccache一定要开。MTK编译很多C代码开启ccache之后二次编译能有肉眼可见的提升。方法是在source环境脚本之前先exportexport USE_CCACHE1 export CCACHE_MAXSIZE50G ccache -M 50G注意要在source之前设置否则编到一半才想起开ccache前面编译全白费。第二别在机械硬盘上编MTK源码。整包解压后五十多个G机械硬盘解压就要半小时编译时随机读写更是折磨。有条件就上NVMe固态编译时间和IO等待时间能差出一大截。第三用repo管理自己的改动。MTK源码包虽然给你的是完整工程但你不能保证改了内核或者vendor之后还能方便地追踪改了什么。在源码根目录先git init或者针对你要动的kernel目录单独建一个git仓库。每次改代码之前清清爽爽提交一版后面出了问题能快速git diff、git bisect这习惯能救你很多次。第四遇到奇怪的编译问题先怀疑out目录和增量缓存。MTK编译系统偶尔会出现增量编译状态不一致的情况表现为“我没改代码但重新编译报错了”。这种时候别死磕直接清理out目录或者跑一遍带-t r的全量编译。代价是时间但能排除一大类无效排查。第五改vendor/mediatek下的私有代码前一定要先搞明白这个目录是开放权限还是只读发布。很多MTK源码包里vendor/mediatek/proprietary是厂商预编译产物加少量脚本不是让你随便改的地方。你真正的修改重点应该放在kernel、device、hardware这几个开放目录。真需要改proprietary里的东西务必先在release note里确认对应代码是否提供了源码分支。MTK源码包的开发跟做普通应用开发完全是两种节奏。它不是一个“拉下来就能跑”的工程而是一整套由release note、环境脚本、私有构建框架和大量历史经验共同撑起来的系统。第一次接触别心急按照拆包、source环境、分段编译、按需调试的顺序一步一个脚印慢慢就会建立起自己的套路。上面的内容至少能帮你把最开头那段路走稳后面遇到具体模块的问题再针对性地去查vendor目录里的文档和脚本会比对着全网搜零散帖子高效得多。本文还有配套的精品资源点击获取