1. 项目概述与优化价值作为一名在嵌入式领域摸爬滚打了十多年的老工程师我深知产品启动速度对于用户体验和系统性能的“第一印象”有多重要。尤其是在像全志T113这类面向工控、物联网、智能终端的应用处理器平台上从按下电源键到应用界面就绪这短短几秒的等待时间往往直接关系到产品的市场竞争力。今天我就以手头这块基于T113核心板的开发套件为例和大家深入聊聊如何从Bootloader、内核到文件系统进行一场彻头彻尾的启动速度“瘦身”手术。这次优化的目标非常明确在保证系统功能稳定、满足产品需求的前提下尽可能压缩从硬件上电到主应用程序比如一个Qt界面完全启动并响应的时间。原始未优化的启动流程可能需要十几秒甚至更长这对于许多实时性要求较高的场景是无法接受的。通过下文将详细拆解的一系列方法我们完全有机会将总启动时间压缩到5秒以内甚至更快。无论你是刚接触嵌入式的新手还是正在为产品启动慢而头疼的资深工程师这篇文章里提到的思路和具体操作都值得你仔细琢磨和实践。2. 启动流程分析与优化切入点在动手优化之前我们必须像医生诊断一样先搞清楚系统启动的“生命周期”。对于基于Linux的嵌入式系统其冷启动过程通常遵循一个清晰的链条ROM Code - Boot0 - Boot1/U-Boot - Linux Kernel - Root Filesystem - Application。T113平台也基本遵循这个流程。ROM Code芯片内部固化的代码不可修改。它负责最基础的硬件初始化并从指定的存储介质如SPI NOR Flash eMMC SD卡中加载下一阶段的引导程序。Boot0这是全志平台特有的一个初级引导加载程序通常由芯片厂商提供。它的主要职责是初始化DRAM等关键外设然后从存储介质中加载更大的U-Boot。U-Boot通用的引导加载程序。它完成更全面的硬件初始化加载设备树DTS最终将Linux内核镜像从存储介质加载到内存中并跳转执行。Linux Kernel内核启动过程包括解压如果使用了压缩内核、设置虚拟内存、初始化驱动子系统、挂载根文件系统等。Root Filesystem内核挂载根文件系统后会寻找并执行初始化进程如/sbin/init或/etc/inittab指定的程序进而执行一系列启动脚本如/etc/init.d/rcS启动各种系统服务和用户应用程序。优化的核心思路就是“减负”和“提速”减负移除启动链路上非必要的步骤、代码、驱动和功能。比如你的产品根本用不到Wi-Fi和蓝牙那么在编译时就应该把它们从内核中剔除。提速优化那些必须存在的环节减少等待、查询和冗余操作。例如关闭串口调试输出能节省大量数据搬运和格式化的时间精确设置内核分区大小可以避免U-Boot读取多余的数据。接下来我们将按照U-Boot、内核、文件系统这三个主要阶段逐一拆解具体的优化手段。我会结合T113开发板以天嵌的T113核心板及底板为例的实际代码和配置路径给出可操作的修改步骤并解释每个修改背后的原理和潜在风险。3. U-Boot阶段优化详解U-Boot作为承上启下的关键一环其优化效果立竿见影。我们的目标是在确保系统能正常引导的前提下砍掉所有不必要的等待和输出。3.1 禁用烧录检测流程修改文件u-boot-2018/cmd/sunxi_burn.c操作与原理 全志平台的U-Boot通常集成了一个用于工厂烧录或升级的检测机制。它会在启动时检查某个特定的GPIO状态或串口命令判断是否进入烧录模式。这个检测过程通常包含一个循环查询或短延时。对于最终产品这个功能是完全多余的。 找到这个文件中的关键函数可能是sunxi_burn_detect或类似名称你可以直接将其改成一个空函数或者更彻底地在U-Boot的编译配置如make menuconfig中找到相关选项可能叫CMD_SUNXI_BURN或SUNXI_BURN_DETECT并禁用它。我的实操心得直接修改源代码虽然快但不利于后续维护和版本升级。更规范的做法是通过U-Boot的配置文件如include/configs/sunxi-common.h或板级特定的头文件中的宏定义来控制。你可以搜索CONFIG_SUNXI_BURN之类的宏确保其未被定义。如果找不到明确的配置项再采用修改源文件的方式。实测下来这个优化能节省大约0.7秒因为跳过了几次GPIO读取和逻辑判断的循环。3.2 消除启动延时修改文件device/config/chips/t113/configs/evb1_auto/longan/env.cfg操作与原理 U-Boot启动后默认会等待一个名为bootdelay的时间通常为1-3秒在此期间如果用户在串口输入任意键则会进入U-Boot命令行交互模式。在产品化场景中我们不需要这个交互等待。 在env.cfg配置文件中找到bootdelay这个环境变量将其值设置为0。bootdelay0注意事项将bootdelay设为0意味着用户完全无法通过串口中断启动过程进入U-Boot。这会给后期调试和故障恢复带来极大困难。因此强烈建议在开发调试阶段保留此延时比如设为1仅在最终发布版本中将其设为0。或者可以采用一个折中方案通过检测某个硬件开关如测试点短路的状态来决定bootdelay的值实现调试模式和产品模式的切换。3.3 关闭串口调试输出操作与原理 U-Boot运行过程中向串口输出日志信息如版本号、驱动初始化状态、内存检测结果等需要消耗CPU周期进行字符串格式化和传输。关闭这些输出可以显著加快执行速度。 根据原文提示有两个地方需要修改关闭U-Boot自身输出修改uboot-board.dts或sys_config.fex文件。找到[platform]段落将其中的debug_mode参数设置为0。这个参数通常控制着Boot0和U-Boot早期阶段的调试信息输出。关闭Boot0输出同样在sys_config.fex文件的[platform]段落下确保debug_mode0。Boot0是更早阶段的引导程序关闭其输出也能节省一点时间。深入解析sys_config.fex是全志平台特有的一种硬件配置文件在编译过程中会被工具转换成二进制的sys_config.bin供Boot0和U-Boot使用。debug_mode是一个标志位设置为0后底层驱动会跳过大量格式化的打印函数调用。这个优化节省的时间取决于原始输出的信息量通常在0.5秒到数秒不等。关闭后你将完全失去通过串口观察U-Boot启动过程的能力因此务必在系统稳定后再进行此操作。4. Linux内核阶段深度优化内核是启动过程中的“重量级选手”优化空间巨大。这里的核心思想是按需裁剪静默启动。4.1 解决随机数生成器初始化阻塞修改文件kernel/drivers/char/random.c问题与原理 Linux内核的随机数生成器RNG在初始化时需要收集足够的“熵”系统噪声来确保随机数的质量。在嵌入式系统启动初期熵源如中断时间、磁盘活动非常少内核可能会在crng_init完成之前阻塞等待。这会导致依赖随机数的服务或应用程序包括一些加密库、甚至部分文件系统操作启动缓慢。 找到random.c中与crng_init状态判断相关的代码。一个常见的“暴力”优化方法是在内核启动早期强制将随机数生成器状态标记为已初始化。但这会降低系统随机数的安全性仅适用于对密码学安全要求不高的场景。更安全的做法启用内核配置中的CONFIG_RANDOM_TRUST_CPU或CONFIG_RANDOM_TRUST_BOOTLOADER如果你的CPU支持硬件随机数生成器如ARM的RNDR指令或者你信任U-Boot传递的随机种子可以启用这些选项让内核信任这些早期熵源从而快速完成初始化。在U-Boot中预置熵高版本的U-Boot支持将收集到的随机数通过设备树传递给内核。你需要确保U-Boot配置了CONFIG_RANDOM_UUID和CONFIG_CMD_RANDOM并在启动脚本中生成并设置chosen节点的rng-seed属性。使用haveged等用户空间熵守护进程这不是内核优化但思路值得借鉴。如果应用可以容忍启动后一小段时间内随机数质量不高可以让内核快速通过然后在用户空间运行haveged来快速填充熵池。但这需要文件系统启动后才能进行。原文提到的修改random.c是最直接但最不推荐的方式因为它破坏了安全模型。建议优先尝试上述两种配置方法。4.2 内核驱动与功能裁剪操作与原理 这是优化中“减负”最有效的一环。通过内核的图形化配置工具make menuconfig移除产品根本用不到的驱动和子系统。Wi-Fi/蓝牙如果你的设备不需要无线连接找到Network support - Wireless以及Bluetooth subsystem support全部禁用。音频如果不需要播放声音或录音在Device Drivers - Sound card support下禁用对应的声卡驱动如全志的sunxi声卡驱动。4G模块如果不需要蜂窝网络在Device Drivers - Network device support下禁用PPP、USB串口GSM/CDMA驱动等。裁剪技巧与风险使用make menuconfig时不要盲目禁用。对于不认识的选项先按/键搜索查看它的依赖关系和被谁使用。最安全的方法是基于一个已知可工作的最小配置defconfig然后只添加你需要的功能。切记裁剪后一定要进行全面的功能测试包括所有要用的外设接口USB、以太网、SD卡、显示屏等。一次激进的裁剪可能导致某个关键驱动比如作为控制台的串口驱动被误删造成系统无法启动。建议采用迭代方式每次裁剪一部分编译测试通过后再继续。4.3 降低内核日志输出级别修改文件device/config/chips/t113/configs/evb1_auto/longan/env.cfg操作与原理 与U-Boot类似内核启动时也会向控制台通常是串口输出大量信息驱动探测、文件系统挂载等。这些打印操作本身耗时且格式化和传输需要CPU参与。 在env.cfg中找到传递给内核的启动参数通常是bootargs变量在其中添加或修改loglevel参数。数字越小输出的日志越少。bootargs... loglevel3 ...loglevel0仅输出紧急信息。loglevel3输出错误、警告和一般性信息跳过调试信息。这是一个比较平衡的设置。loglevel7输出所有信息默认。注意事项将日志级别设得太低如0或1会给后续的问题排查带来巨大困难因为系统几乎“失声”。建议在开发阶段保持loglevel7在优化启动速度时先尝试loglevel4或3在最终产品中可以考虑设为1或0。同时内核日志还会输出到/proc/kmsg和dmesg即使控制台输出关闭了启动后仍然可以通过dmesg命令查看部分日志但这只记录在内存缓冲区中如果内核崩溃过早这些信息可能丢失。4.4 关闭内核校验与精确分区操作一关闭内核校验修改文件同上文的env.cfg。 在bootargs启动参数中添加verifyno。这个参数告诉内核跳过启动时的某些完整性校验在某些配置下可以节省少量时间。bootargs... verifyno ...操作二精确设置内核分区大小原理在Flash分区表中我们通常会为内核boot分区分配一个固定大小的空间例如4MB。但实际编译出的内核镜像zImage或uImage可能只有2MB。U-Boot在加载内核时如果采用简单的方式可能会读取整个分区的数据4MB到内存尽管后半部分是空的。这浪费了读取时间和内存带宽。修改方法这需要调整U-Boot中加载内核的命令。通常U-Boot使用ext4load或fatload等命令从文件系统加载内核或者直接用nand read/mmc read从原始分区读取。你需要修改启动脚本bootcmd将读取的字节数改为内核镜像的实际大小。 例如原始的可能是nand read 0x40080000 0x100000 0x400000 // 从偏移0x100000读取4MB数据到内存0x40080000如果你知道内核镜像zImage大小是0x2000002MB则应改为nand read 0x40080000 0x100000 0x200000更优做法让U-Boot自动检测内核大小。这可以通过在Flash上使用文件系统如FAT、EXT4存放内核并使用load命令来实现load命令会自动读取文件大小。或者在内核镜像前添加一个包含大小的头信息如uImage格式U-Boot的bootm命令可以识别。5. 文件系统与用户空间启动优化当内核启动完毕挂载根文件系统后启动的“接力棒”就交给了用户空间的初始化脚本。这里的优化核心是精简服务并行启动避免阻塞。5.1 优化启动脚本执行顺序操作与原理 在典型的BusyBoxinit系统中/etc/init.d/rcS是主启动脚本。它会按顺序执行/etc/init.d/目录下所有以S开头的脚本。关键脚本前置将你的核心应用或最关键的服务的启动脚本例如S50myapp放在rcS中靠前的位置执行。你可以通过修改脚本文件名来实现因为rcS通常是按文件名顺序执行的例如S01比S99先执行。确保核心应用能尽早启动响应用户。延迟非关键服务对于那些不急于启动的服务如日志轮转、定时任务检查可以将其脚本重命名放在后面执行甚至可以考虑在核心应用启动并进入主循环后再在后台异步启动这些服务。我的实操心得不要简单地把所有脚本都塞到最前面。要分析依赖关系。例如网络服务可能依赖于网络接口配置脚本图形界面可能依赖于输入设备驱动初始化。一个有效的方法是绘制一个简单的服务依赖图确保前置服务所需的资源已就绪。对于rcS本身可以用#!/bin/sh -x让它输出详细执行日志然后用grep或重定向到文件分析每个步骤的耗时。5.2 消除脚本中的无效延时与输出操作文件例如/etc/init.d/embedsky_conf或其他厂商提供的脚本。 仔细审查这些脚本常见的拖慢启动的因素有sleep命令脚本中可能包含sleep 1、usleep 500000等等待命令用于等待设备就绪。你需要判断这些等待是否必要。有时可以通过查询设备状态文件如/sys/class下的节点来替代盲等。大量的echo输出每个echo到控制台特别是串口的操作都有开销。将调试信息的输出重定向到/dev/null或者仅在调试版本中开启。冗余检查一些脚本可能会反复检查同一个条件。优化逻辑减少检查次数。5.3 应用启动策略优化操作与原理 原文提到“优先执行qt程序并且延时一段时间在执行其他功能”。这是一个非常实用的策略。并行启动在rcS脚本中使用将你的主Qt应用程序放到后台启动/usr/bin/myqtapp 。这样脚本不会等待应用完全启动完毕就会继续执行后面的任务。延时启动非核心功能在启动主应用后再使用sleep延时几秒再启动其他占用资源或可能干扰主应用的服务例如一些可能弹出对话框或占用输入焦点的服务。这能确保用户第一时间看到主界面并可以交互。依赖管理如果其他服务依赖于主应用创建的某些资源如套接字、共享内存那么这种“主应用先行其他延时”的策略就是必须的。你需要设计好应用间的通信和同步机制。6. 进阶优化与系统级调优思路除了上述针对特定组件的修改还有一些系统级的思路可以进一步提升启动速度。6.1 内核压缩与解压方式选择内核镜像通常经过压缩如gzip, lz4, lzo。不同的压缩算法在压缩率和解压速度上各有权衡。LZ4以解压速度极快而著称虽然压缩率略低于gzip但对于追求启动速度的场景往往是首选。在内核配置中General setup - Kernel compression mode可以选择。XZ压缩率高但解压慢不适合快速启动。未压缩如果存储空间充足直接使用未压缩的镜像Image可以完全省去解压时间但镜像体积会大很多。选择建议在T113这类存储空间不紧张通常有几十MB甚至上百MB的Flash且CPU性能尚可的平台推荐使用LZ4压缩能在镜像体积和启动时间上取得很好的平衡。可以通过对比测试测量内核解压到执行start_kernel的时间来做出最终决定。6.2 初始化进程init替换传统的sysvinitBusyBoxinit是串行执行脚本的。可以考虑替换为更快的初始化系统systemd虽然功能强大但在嵌入式系统中可能显得臃肿启动本身有一定开销。BusyBox runit一个轻量级的方案支持简单的并行服务管理。自定义init程序对于极度简单的应用完全可以自己写一个小的init程序直接fork/exec你的主应用这是最快的方案。评估替换init系统改动较大涉及根文件系统的构建和诸多脚本的迁移。除非启动时间瓶颈确实卡在用户空间服务初始化串行等待上否则不建议轻易改动。先优化现有init脚本的效率收益更明显。6.3 根文件系统类型与挂载优化文件系统类型initramfs内存文件系统的挂载速度远快于从Flash读取的ext4或squashfs。你可以将关键的启动程序和配置文件打包进initramfs让内核在内存中直接访问加速早期启动。主根文件系统可以后续再挂载。异步挂载在/etc/fstab中对非关键的文件系统如/tmp,/var/log使用async挂载选项让内核在后台进行挂载操作不阻塞启动流程。禁用文件系统日志对于只读文件系统如squashfs或对数据完整性要求不高的可写分区可以在挂载时使用datawriteback或noload针对ext4等选项来禁用日志提高挂载速度。但这会显著增加断电导致数据损坏的风险请谨慎评估。7. 效果测量、验证与常见问题排查优化不是一蹴而就的需要科学的测量和严谨的验证。7.1 如何精确测量启动时间串口时间戳在U-Boot和内核的启动参数中启用更精细的时间戳。对于U-Boot可以设置环境变量timestamp支持。对于内核在bootargs中添加initcall_debug和printk.time1这样每个初始化函数调用都会打印时间。通过分析串口日志可以定位耗时最长的阶段。GPIO点灯法这是最直观、硬件成本最低的方法。在启动流程的关键节点如U-Boot开始、内核开始、文件系统挂载完成、应用启动完成通过代码控制一个GPIO引脚输出高/低电平。用示波器或逻辑分析仪测量这些电平跳变之间的时间间隔即可得到各阶段精确耗时。内核initcall_debug如上所述在内核参数添加initcall_debug会在dmesg中输出每个级别initcall的执行时间帮助你发现内核初始化过程中耗时的驱动或子系统。7.2 优化后系统验证清单任何优化都不能以牺牲系统稳定性为代价。修改后必须进行以下测试冷启动/热启动多次断电重启确认系统每次都能正常引导至应用界面。外设功能逐一测试所有需要使用的硬件接口以太网、USB、SD卡、显示屏、触摸屏、音频输入输出、GPIO控制等。网络与存储进行大文件传输、持续读写存储测试系统在负载下的稳定性。压力测试长时间运行主应用程序监控内存泄漏和系统负载。掉电测试在系统运行中突然断电再上电检查文件系统是否损坏特别是如果你优化了文件系统挂载选项。7.3 常见问题与回退方案系统无法启动黑屏/串口无输出可能原因U-Boot或内核关键驱动被裁剪bootargs参数错误导致内核崩溃文件系统损坏或挂载失败。排查首先恢复串口输出将debug_mode和loglevel改回原始值。如果仍无输出可能是U-Boot损坏需通过SD卡或USB OTG方式重新烧录U-Boot。如果有内核恐慌panic信息根据错误信息定位问题。回退始终保留一份已知良好的完整镜像包含U-Boot、内核、文件系统并确保有可靠的烧录恢复手段如全志的PhoenixSuit工具。应用启动后功能异常可能原因依赖的服务如网络、数据库尚未启动完成内核驱动缺失文件系统挂载顺序问题。排查检查dmesg和应用程序日志。使用ps命令查看相关进程是否已运行。检查/sys和/proc下相关设备节点是否存在。解决调整启动脚本中的服务顺序和依赖关系。确保内核配置包含了所有必需的驱动模块。启动速度优化不明显可能原因瓶颈不在已优化的部分。例如可能卡在Flash读取速度、某个硬件初始化如PMIC、或等待某个外部设备如模组上电就绪。定位使用GPIO点灯法或精细时间戳精确测量每个阶段的耗时找到新的瓶颈点。可能是硬件设计或芯片本身固有限制。优化嵌入式Linux启动速度是一个系统工程需要耐心和细致的测试。从最耗时的部分入手每次只做一两项修改验证效果和稳定性再继续推进。记住可维护性和稳定性永远是第一位的不能为了追求极致的秒数而引入不可控的风险。希望这篇基于T113开发板的实战总结能为你下一个产品的“闪电启动”提供清晰的路径。