1. 厂商内核与驱动定制到底在解决什么问题第一次接触“厂商内核与驱动定制”这个概念很多人会以为这是芯片原厂或者大厂系统团队才需要碰的东西跟普通开发者没多大关系。但实际情况恰恰相反——只要你手里的设备跑的是某个厂商提供的系统镜像或者你在做嵌入式产品、定制化终端、专用设备你迟早会撞上这个问题官方给的内核太“通用”了通用到很多你需要的硬件特性、功耗策略、外设支持都被裁剪掉了或者默认配置根本跑不出你想要的性能。所谓厂商内核简单说就是芯片厂商或设备厂商基于某个主线内核版本加入自家硬件适配补丁、驱动模块、电源管理策略、调试接口之后发布的一套内核源码树。它跟上游主线内核最大的区别在于厂商内核往往包含大量尚未合并进主线的私有驱动、针对特定硬件平台的调优参数、以及一些为了快速量产而做的临时方案。驱动定制则是在这个基础上根据具体产品需求对驱动模块进行裁剪、参数调整、功能增强甚至重写。这件事能解决的核心问题有三个层面。第一层是硬件兼容性很多外设芯片、传感器、显示模组只有厂商提供的驱动才能正常工作主线内核里根本没有对应支持。第二层是性能与功耗的平衡厂商内核通常带有针对特定工艺和封装调优的DVFS表、温控策略、休眠唤醒流程这些直接决定了设备的续航和发热表现。第三层是产品差异化同样一颗主控不同产品对音频延迟、摄像头响应、网络吞吐的要求完全不同驱动层的参数定制就是实现差异化的关键手段之一。适合看这部分内容的人我大致分成三类。一类是做嵌入式Linux产品开发的工程师需要基于厂商BSP做二次开发一类是做系统集成或设备定制的技术负责人需要评估厂商内核的可用性和改造空间还有一类是喜欢折腾开发板、单板计算机的爱好者想搞清楚为什么官方镜像跑分高但实际用起来卡顿以及怎么通过驱动层调整来改善体验。不管哪一类核心诉求都是一样的把厂商给的那套“半成品”内核变成真正贴合自己产品需求的东西。2. 厂商内核源码树的结构与关键目录拆解拿到一份厂商内核源码第一件事不是急着编译而是先搞清楚它的目录结构和跟主线内核的差异。我见过太多人直接make menuconfig然后编译结果出来的镜像缺驱动、缺固件、启动就挂回头排查半天发现是厂商把关键配置放在了非标准路径下。2.1 厂商内核与主线内核的目录差异主线内核的标准目录结构大家都熟悉arch/、drivers/、fs/、kernel/、mm/这些。厂商内核通常会在几个地方做手脚。最常见的是在drivers/下新增一个以厂商名或平台名命名的子目录比如drivers/mstar/、drivers/amlogic/这种里面塞满了私有驱动。另一个高频改动点是arch/arm64/boot/dts/或arch/arm/boot/dts/厂商会在这里放大量板级设备树文件命名往往跟内部项目代号对应跟公开资料对不上号。还有一个容易被忽略的地方是firmware/目录。很多厂商会把闭源固件二进制直接放在这里编译时打包进镜像。如果你只拷贝了内核源码却漏了firmware目录编译能过但运行时报固件加载失败。我建议拿到源码后先执行一次diff -rq跟同版本主线内核做对比把新增和修改的文件列出来心里有个底。# 假设主线内核源码在 ~/linux-mainline厂商内核在 ~/linux-vendor diff -rq ~/linux-mainline ~/linux-vendor | grep -E Only in|differ | head -50这个命令能快速列出厂商新增的目录和修改过的文件。实测下来一个中等复杂度的厂商内核差异文件通常在两千到五千个之间其中大部分是设备树和驱动。2.2 配置文件与设备树的定位技巧厂商内核的默认配置文件通常放在arch/arm64/configs/下文件名可能是defconfig、xxx_defconfig或者带项目代号的projectA_defconfig。如果你不确定用哪个可以看厂商提供的编译脚本通常叫build.sh、mk.sh或者make_kernel.sh里面会明确指定ARCH、CROSS_COMPILE和defconfig名称。设备树文件的位置更隐蔽一些。有些厂商会把设备树放在arch/arm64/boot/dts/vendor/下有些则直接放在arch/arm64/boot/dts/根目录文件名可能是board-v1.dts、board-v2.dts这种。我的经验是直接搜compatible字符串找到跟你的板子型号匹配的那个dts然后顺着#include关系把整个设备树链条理清楚。注意厂商内核的设备树经常有多层include顶层dts可能只包含一个#include board-common.dtsi真正的硬件配置在dtsi文件里。改设备树之前一定要把include链全部展开看一遍否则你改了半天发现被后面的include覆盖了。2.3 驱动模块的编译方式与加载机制厂商内核的驱动编译方式分两种内置built-in和模块module。内置驱动直接编进内核镜像启动时自动加载模块驱动编成.ko文件需要手动insmod或者通过modprobe加载。厂商通常会把核心驱动做成内置把可选功能做成模块。判断一个驱动是内置还是模块看Makefile里的obj-y和obj-m就行。obj-y是内置obj-m是模块。但厂商有时候会玩花活用obj-$(CONFIG_XXX)这种条件编译这时候就得结合defconfig里的配置项来判断了。# 典型厂商驱动Makefile片段 obj-$(CONFIG_VENDOR_GPU) vendor_gpu.o obj-$(CONFIG_VENDOR_VPU) vendor_vpu.o vendor_gpu-objs : gpu_core.o gpu_pm.o gpu_debugfs.o上面这个例子里vendor_gpu驱动由三个目标文件链接而成是否编译取决于CONFIG_VENDOR_GPU这个配置项。你可以在defconfig里搜这个配置项看它是y还是m分别对应内置和模块。3. 驱动定制的核心手段与实操要点驱动定制不是让你从零写一个驱动绝大多数情况下是在厂商驱动基础上做参数调整、功能裁剪和行为修改。我把它归纳成四种手段按改动量从小到大排列配置项调整、模块参数修改、设备树覆盖、源码级修改。3.1 配置项调整与模块参数修改配置项调整是最安全的定制方式只改defconfig里的CONFIG_XXX值不碰源码。比如你不需要蓝牙功能就把CONFIG_BT关掉需要开启某个调试接口就把对应的CONFIG_DEBUG_XXX打开。这种改动的风险最低但能实现的效果也有限。模块参数修改稍微进了一步。很多驱动在加载时接受参数比如insmod vendor_gpu.ko debug_level3。这些参数通常在驱动源码里用module_param()宏定义你可以在/sys/module/驱动名/parameters/下看到当前值也可以直接echo修改。# 查看某个驱动模块的可调参数 ls /sys/module/vendor_gpu/parameters/ # 运行时修改参数 echo 1 /sys/module/vendor_gpu/parameters/debug_level这种方式的优点是即时生效、不用重新编译缺点是重启后失效需要写进启动脚本或者modprobe.d配置里才能持久化。3.2 设备树覆盖与硬件描述修正设备树是驱动定制的重头戏。厂商给的设备树往往只保证“能跑”很多硬件参数用的是保守值或者通用值。比如I2C总线的时钟频率、SPI的传输模式、GPIO的上下拉配置、电源域的电压档位这些都可以通过修改设备树来优化。我举个实际例子。某块开发板的SD卡接口在厂商设备树里配置的max-frequency是50MHz但实际硬件走线质量很好可以跑到100MHz。改设备树把频率提上去之后SD卡读写速度直接翻倍。这种改动不需要碰驱动源码只改dts就行。sdhci { max-frequency 100000000; bus-width 4; cap-sd-highspeed; sd-uhs-sdr50; status okay; };但设备树修改有个大坑厂商的驱动可能对某些属性有硬编码依赖。比如驱动里写死了if (freq 50000000) return -EINVAL;那你设备树里写100MHz也没用驱动直接拒绝。所以改设备树之前最好把对应驱动的probe函数扫一遍看它读了哪些属性、有没有做范围检查。3.3 源码级修改的边界与风险控制源码级修改是最后的手段也是最容易出问题的。我个人的原则是能改配置就不改设备树能改设备树就不改源码。但有些需求确实绕不开源码修改比如驱动有bug、需要增加新的ioctl接口、要对接自研的硬件模块。改源码之前第一件事是建一个git分支把厂商原始代码提交一次所有修改都在分支上进行。这样你随时能git diff看自己改了什么也能随时回退。第二件事是尽量用#ifdef包裹自己的修改方便后续跟厂商新版本合并。/* 厂商原始代码 */ static int vendor_gpu_probe(struct platform_device *pdev) { int ret; ret clk_prepare_enable(gpu-clk); if (ret) return ret; /* ... */ } /* 定制修改增加时钟频率检查 */ static int vendor_gpu_probe(struct platform_device *pdev) { int ret; #ifdef CONFIG_VENDOR_GPU_CUSTOM_CLK if (gpu-clk_rate MAX_SUPPORTED_RATE) { dev_warn(pdev-dev, clk rate too high, fallback\n); gpu-clk_rate MAX_SUPPORTED_RATE; } #endif ret clk_prepare_enable(gpu-clk); if (ret) return ret; /* ... */ }注意源码修改后一定要做回归测试至少覆盖启动、休眠唤醒、外设基本功能这三项。我踩过的坑是改了一个电源管理相关的驱动结果设备休眠后唤不醒排查了两天才发现是某个寄存器写入顺序被自己改乱了。3.4 驱动定制中的性能与功耗权衡驱动定制永远是在性能和功耗之间找平衡点。把GPU频率拉满游戏帧率上去了但发热和耗电也上去了把WiFi省电模式打开续航长了但网络延迟可能变得不稳定。这个平衡点没有标准答案取决于你的产品定位。我的做法是建一个简单的测试矩阵把关键场景列出来每个场景下测不同参数组合的表现。比如视频播放场景测CPU调频策略从performance到schedutil的功耗差异游戏场景测GPU调频档位对帧率稳定性的影响。数据攒够了再决定默认参数怎么设。场景可调参数性能影响功耗影响推荐策略视频播放CPU governor低高schedutil游戏GPU freq高高动态调频待机休眠深度无极高最深休眠网络传输WiFi省电中中关闭省电这张表是我做定制时的参考框架具体数值需要根据实际硬件实测填充。关键是养成“改参数必测功耗”的习惯否则很容易做出一个跑分好看但实际没法用的配置。4. 从零构建定制内核的完整实操流程前面讲了原理和手段这一部分我把整个流程串起来从环境准备到最终烧录每一步都给出可复现的操作。这套流程我在多个项目上跑过适配大多数厂商内核的定制场景。4.1 交叉编译环境搭建与依赖检查交叉编译工具链是第一个坎。厂商通常会指定用哪个版本的GCC或者Clang版本不对可能编译报错或者生成的内核跑不起来。我建议严格按照厂商文档里的版本要求来不要自作主张用最新版。# 以aarch64为例安装交叉编译工具链 sudo apt install gcc-aarch64-linux-gnu # 验证版本 aarch64-linux-gnu-gcc --version除了工具链还需要装一些编译依赖flex、bison、libssl-dev、bc、rsync、cpio。这些在编译过程中会用到缺一个就报错。我习惯一次性装齐sudo apt install build-essential flex bison libssl-dev bc rsync cpio \ libncurses-dev device-tree-compiler环境变量也要设好ARCH和CROSS_COMPILE这两个必须正确否则编译出来的架构不对。export ARCHarm64 export CROSS_COMPILEaarch64-linux-gnu-4.2 内核配置裁剪与驱动模块选择配置裁剪是定制内核的核心步骤。我一般分三步走先加载厂商defconfig再用menuconfig做交互式调整最后用diff对比配置变化。# 加载厂商默认配置 make vendor_defconfig # 交互式配置 make menuconfig # 保存后对比差异 make savedefconfig diff .config defconfigmenuconfig里重点关注的几个区域Device Drivers下的厂商私有驱动、Kernel Features下的调度器和电源管理、Networking support下的协议栈选项。每关掉一个驱动都要确认没有其他驱动依赖它否则编译会报undefined reference。提示裁剪配置时遵循“最小可用”原则只保留产品实际用到的功能。我见过一个项目为了省事保留了所有驱动结果内核镜像比实际需要的大了40%启动时间多了两秒。对于量产产品来说这两秒可能就是用户体验的分水岭。4.3 编译、打包与镜像生成配置搞定后就是编译。make -j$(nproc)并行编译能快不少但内存小于8G的机器建议把并行数降到一半否则容易OOM。# 并行编译根据CPU核心数调整 make -j$(nproc) Image dtbs modules # 安装模块到指定目录 make modules_install INSTALL_MOD_PATH./output编译产物通常在arch/arm64/boot/下Image是内核镜像dts/下是设备树dtb文件。模块在drivers/各子目录下.ko文件需要跟内核版本严格匹配否则加载会报version magic错误。打包成可烧录镜像这一步不同平台差异很大。有的用mkbootimg有的用厂商自己的打包脚本有的直接生成img文件。我建议直接用厂商提供的打包脚本不要自己造轮子因为里面可能包含签名、校验、分区表等隐藏步骤。4.4 烧录验证与启动日志分析烧录方式取决于设备SD卡启动的直接ddeMMC的用fastboot或者厂商工具。烧录完成后接串口看启动日志这是排查问题的第一手资料。# 串口日志抓取波特率通常是115200 sudo minicom -D /dev/ttyUSB0 -b 115200 # 或者用picocom sudo picocom -b 115200 /dev/ttyUSB0启动日志里重点看几个地方Uncompressing Linux...之后的内核解压信息、Booting Linux on physical CPU确认CPU识别正常、Memory:确认内存大小正确、各驱动probe的成败信息。如果卡在某个驱动probe上大概率是设备树配置或者驱动依赖有问题。我习惯把启动日志重定向到文件方便后续搜索关键字sudo picocom -b 115200 /dev/ttyUSB0 | tee boot.log # 另开终端搜索错误 grep -iE error|fail|timeout|denied boot.log5. 常见问题排查与避坑经验实录驱动定制这件事踩坑是常态。我把这些年遇到的高频问题整理成速查表附上排查思路和解决方法希望能帮你少走弯路。5.1 驱动加载失败与版本不匹配最常见的问题就是insmod报invalid module format或者version magic mismatch。原因通常是模块编译时用的内核源码跟当前运行的内核不是同一份或者编译时的配置跟运行内核的配置不一致。排查步骤很简单先看uname -r确认运行内核版本再看模块的modinfo里的vermagic字段两者必须完全一致。uname -r modinfo vendor_gpu.ko | grep vermagic如果版本号对得上但还是报错检查CONFIG_MODVERSIONS是否开启。开启了这个选项的话模块和内核之间的符号CRC校验必须匹配任何一方重新编译都会导致不匹配。解决方法是模块跟内核一起重新编译不要分开编。错误信息可能原因解决方法invalid module format内核版本不匹配重新编译模块version magic mismatch配置不一致用同一份.config编译unknown symbol依赖模块未加载先insmod依赖模块permission denied内核锁定或签名关闭模块签名校验5.2 设备树配置错误导致的硬件异常设备树写错的表现五花八门I2C设备读不到、GPIO电平不对、时钟频率异常、电源域起不来。排查设备树问题/proc/device-tree/是你的好朋友里面能看到内核实际解析出来的设备树内容。# 查看某个节点的属性 ls /proc/device-tree/soc/i2cff110000/ cat /proc/device-tree/soc/i2cff110000/clock-frequency如果发现设备树里的值跟预期不符先确认dts编译成dtb时有没有报warning。dtc编译器对某些语法错误只是警告不报错但生成的dtb可能缺节点。# 单独编译设备树看警告信息 dtc -I dts -O dtb -o test.dtb board.dts注意设备树里的status属性必须是okay写成ok或者enable都不会生效。这个坑我踩过不止一次明明节点写对了但驱动就是不probe最后发现是status拼错了。5.3 功耗异常与休眠唤醒问题功耗问题最难排查因为它涉及CPU、GPU、内存、外设、电源管理芯片多个环节。我的排查顺序是先看待机电流再看各电源域状态最后查唤醒源。待机电流偏高第一步用cat /sys/kernel/debug/pm_genpd/*/state看各电源域是否正常关闭。如果有域一直是on状态说明有驱动持有引用计数没释放。第二步用cat /sys/kernel/debug/clk/clk_summary看时钟是否都关了没关的时钟对应哪个驱动。休眠唤不醒的问题通常是唤醒源配置错误。检查设备树里的wakeup-source属性以及驱动里enable_irq_wake()有没有正确调用。我遇到过一次RTC唤醒失效查了半天发现是RTC驱动在suspend时把中断关了但没配置成唤醒源。5.4 性能调优中的常见误区性能调优最大的误区是只看跑分不看实际体验。把CPU governor设成performance跑分确实高但待机功耗翻倍温度升高导致降频实际游戏体验反而更差。我的建议是建立场景化的测试标准比如视频播放看帧率稳定性网页浏览看响应延迟游戏看帧率波动。另一个误区是忽略散热约束。驱动层把频率拉高散热跟不上温度一上来硬件自动降频性能反而比默认配置还低。调频之前先确认散热方案能压住否则就是白忙活。# 查看当前温度和频率 cat /sys/class/thermal/thermal_zone*/temp cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_cur_freq我一般会在调频参数确定后跑一个持续30分钟的压力测试观察温度曲线和频率曲线。如果温度稳定在阈值以下且频率不波动说明配置可用如果温度撞到阈值导致频繁降频就得往回退一档。6. 定制内核的维护与版本升级策略定制内核不是一锤子买卖厂商会不定期发布新版本上游主线也在持续演进。怎么在保持自己定制内容的同时跟进新版本是个需要提前规划的问题。6.1 定制补丁的整理与版本管理我的做法是把所有定制内容整理成patch文件按功能分类存放。比如0001-gpu-clk-override.patch、0002-wifi-power-save-disable.patch。每个patch只做一件事方便单独回退和重新应用。# 生成patch git format-patch -o patches/ HEAD~3 # 应用patch git am patches/*.patchpatch的命名要有规律前缀数字表示应用顺序后面跟简短描述。这样升级厂商内核时按顺序重新apply一遍就行。如果某个patch冲突了git am会停下来让你手动解决解决完git am --continue继续。6.2 跟进厂商新版本的合并流程厂商发布新内核版本后不要直接把自己的patch往上一贴就完事。先看厂商的release note确认有没有跟你定制内容重叠的改动。比如你之前自己改了一个bug厂商新版本里已经修了那你的patch就不用再应用了。合并流程我一般这样走先建一个新分支基于厂商新版本然后把旧分支的patch逐个cherry-pick过去每pick一个就编译测试一次。全部pick完再做一轮完整回归测试。这个过程比较耗时但比一次性全贴上去然后出问题再排查要高效得多。6.3 长期维护中的技术债务控制定制内核最大的技术债务就是“改了但不知道为什么改”。我见过太多项目前人改了一堆驱动参数没写注释没留文档后人接手时完全不敢动生怕一改就崩。控制技术债务的方法很简单每一条定制修改都要有记录记录里写清楚改了什么、为什么改、影响范围是什么。我习惯在源码里用统一的注释格式标记定制点/* CUSTOM-BEGIN: gpu clk override for thermal limit * Reason: default 800MHz causes thermal throttle in 10min * Impact: max gpu freq limited to 600MHz * Author: xxx, Date: 2024-xx-xx */ #define GPU_MAX_FREQ 600000000 /* CUSTOM-END */这样后续任何人看到这段代码都知道来龙去脉升级内核时也能快速判断这个修改是否还需要保留。技术债务不可怕可怕的是债务没有账本。6.4 从定制走向上游的思考如果你做的定制修改具有通用性比如修复了一个驱动bug、增加了一个标准接口可以考虑把patch提交到上游主线。这样做的好处是后续升级内核时这部分改动会自动包含不用再自己维护。但提交上游有门槛代码风格、commit message、review流程都有严格要求需要投入额外精力。我的建议是分两步走先在项目内部把patch打磨稳定经过充分测试验证然后再花时间按上游规范整理提交。不要一开始就奔着上游去那样容易在review环节反复修改影响项目进度。等patch在内部跑稳了提交上游就是水到渠成的事。7. 实操心得与几个容易忽略的细节最后分享几个我在实际项目中总结的小经验都是文档里不会写但确实能省时间的东西。第一个是关于编译缓存的。厂商内核全量编译一次可能要二三十分钟改一行代码重新编译如果还全量跑就太浪费时间了。用ccache能大幅加速重复编译尤其是你频繁切换分支测试的时候。sudo apt install ccache export CROSS_COMPILEccache aarch64-linux-gnu-第二个是关于内核日志级别的。调试驱动时把loglevel调到8能看到所有debug信息但量产固件里一定要调回4或者更低否则串口输出会拖慢启动速度而且暴露太多内部信息也不合适。第三个是关于设备树overlay的。如果你的平台支持overlay尽量用overlay做定制不要直接改基础dtb。overlay的好处是基础dtb可以跟着厂商更新你的定制内容单独维护互不干扰。很多厂商的uboot都支持加载多个overlay按顺序叠加。第四个是关于驱动调试的。debugfs是驱动调试的利器厂商驱动通常会在/sys/kernel/debug/下暴露一堆调试节点。没事多翻翻这些节点能看到寄存器值、状态机状态、统计计数比盲猜高效得多。# 挂载debugfs mount -t debugfs none /sys/kernel/debug # 查看厂商驱动调试节点 ls /sys/kernel/debug/vendor_gpu/第五个是关于备份的。改内核之前一定要备份能正常工作的镜像和模块最好连启动日志一起存着。我习惯在设备上留一个已知可用的内核分区定制内核出问题时能快速切回去不至于设备变砖。这个习惯救过我很多次尤其是赶项目进度的时候没时间慢慢排查先切回可用版本保证业务不中断再找时间分析问题。驱动定制这件事说到底就是跟硬件和厂商代码不断磨合的过程。没有一劳永逸的配置只有持续迭代的平衡。每次改动前想清楚影响范围改动后做好验证记录时间长了自然就有一套自己的方法论了。