1. 项目概述与核心价值最近在折腾一块基于全志T113-i芯片的开发板项目目标是把它打造成一个快速响应的嵌入式终端设备。在调试过程中我发现了一个非常影响用户体验的问题从按下电源键到系统完全就绪整个过程耗时接近30秒。对于追求“秒开”体验的工业HMI、智能零售终端或者广告机来说这个速度显然是不及格的。于是我花了大概两周时间深入系统启动流程的每一个环节把启动时间优化到了10秒以内。这个过程就像给一辆老爷车做全面性能调校涉及从硬件初始化到应用加载的方方面面不仅仅是改几个参数那么简单。T113这颗芯片性价比很高双核Cortex-A7加上内置的128MB DDR3在不少低成本嵌入式场景里很受欢迎。但正因为成本控制其启动链路上的各个环节都可能存在优化空间。这次优化不仅仅是追求一个数字更是对嵌入式Linux系统启动机制的深度梳理。无论你用的是T113还是其他类似的ARM平台比如RK3566、i.MX6ULL这套分析和优化思路都是相通的。如果你也在为你的设备启动慢而烦恼或者单纯想了解Linux系统到底是如何“醒来”的那么接下来的内容应该能给你不少直接的参考和启发。2. 启动流程深度拆解与耗时瓶颈定位优化启动速度第一步不是盲目动手而是先搞清楚时间都花在哪里了。我们需要一个清晰的“计时地图”。对于基于T113和类似平台的嵌入式Linux系统其启动流程可以划分为几个相对独立的阶段每个阶段都有其主导的耗时因素。2.1 启动阶段划分与测量方法一个典型的从Flash启动的流程如下ROM Code (BootROM)芯片上电后首先运行固化在芯片内部ROM中的一小段代码。它的任务是初始化最基本的外设如SRAM、时钟然后从指定的外部存储介质如SPI NAND Flash的固定位置加载下一阶段的引导程序。这个过程通常非常快在毫秒级一般不是优化重点。SPL (Secondary Program Loader) / U-Boot SPL由于内部SRAM容量有限BootROM加载的通常是一个精简的U-Boot称为SPL。SPL会初始化更复杂的外设最主要的是DDR内存控制器。初始化DDR的耗时与DRAM颗粒的型号、配置参数密切相关是前期的一个潜在瓶颈。SPL接着从Flash中加载完整版的U-Boot到DDR中并跳转执行。U-Boot (Full)完整的U-Boot会进行更全面的硬件初始化如网卡、USB、显示等如果配置了然后解析环境变量根据bootcmd的指示去加载内核镜像Image和设备树.dtb最后将控制权交给内核。U-Boot自身执行、等待启动指令如串口输入、加载大体积内核镜像的时间都需要关注。Linux Kernel内核启动阶段包括解压如果使用了压缩内核、汇编级初始化、C语言环境建立、设备树解析、驱动探测与初始化等。驱动初始化尤其是存储、显示等复杂外设的驱动可能耗时较长。内核最后会尝试挂载根文件系统rootfs。Root Filesystem Init Process根文件系统挂载成功后内核启动第一个用户空间进程通常是/sbin/init可能是busybox init、systemd或sysvinit。随后init进程会执行一系列启动脚本如/etc/inittab,/etc/rcS.d/*启动必要的系统服务如网络、日志、图形界面如Qt应用等。这个阶段往往是耗时最长的“重灾区”因为涉及大量磁盘I/O、进程fork和串行执行的脚本。要定位瓶颈我们需要在每个阶段结束时打上时间戳。最简单有效的方法是利用串口输出。在U-Boot中可以启用CONFIG_BOOTSTAGE和CONFIG_BOOTSTAGE_REPORT配置编译后U-Boot会在启动末尾打印出一份详细的耗时报告。另外也可以在U-Boot源码的关键位置如board_init_f,board_init_r以及bootm命令相关函数手动添加printf打印当前计时器值。在Linux内核中可以启用内核配置CONFIG_PRINTK_TIME这样所有内核打印信息都会附带时间戳从内核启动开始计算。通过观察不同驱动初始化之间的时间差就能定位内核阶段的瓶颈。更强大的工具是initcall_debug在内核命令行添加initcall_debug参数内核会打印出每一个初始化函数*_initcall的执行耗时信息非常详细。在用户空间可以在/etc/inittab或/etc/rcS脚本的最开头和关键服务启动前后使用date命令或/proc/uptime来记录时间。对于使用systemd的系统直接使用systemd-analyze blame命令就能列出所有服务的启动耗时是分析用户空间启动慢的神器。注意测量一定要在release模式关闭调试串口大量输出、关闭内核调试符号下进行。调试信息本身会通过串口打印而串口速率如115200bps是瓶颈会严重拖慢启动速度导致测量失真。优化前后的对比测量必须在同一配置下进行。2.2 T113平台特有的瓶颈点分析基于对T113开发板的实际测量我发现了几个值得特别关注的耗时点DDR初始化延迟T113-i通常搭配128MB或256MB的DDR3内存。U-Boot SPL中DDR初始化的代码dram_init会执行一系列DRAM颗粒的培训training流程以确保内存稳定工作。这个流程的耗时与DRAM厂商、速率以及SPL中的配置参数有关。有时为了兼容性SPL会使用比较保守的延时参数导致初始化变慢。从SPI NAND Flash加载镜像慢出于成本考虑很多T113板卡使用SPI NAND Flash作为存储。其读写速度远低于eMMC尤其是随机读取性能差。U-Boot加载几MB到十几MB的内核镜像以及内核读取文件系统数据时SPI NAND的慢速I/O会成为显著瓶颈。测量发现从Flash读取10MB的内核镜像在24MHz SPI时钟下可能需要近1秒。内核驱动探测与初始化Linux内核会探测并初始化所有在设备树中启用的设备驱动。对于显示驱动如T113的DE/TCON其初始化可能涉及显存分配、时钟配置、显示模式读取从屏的EDID等耗时可能达到几百毫秒。如果还启用了USB、以太网等复杂外设它们的探测时间也会累加。根文件系统挂载与初始化脚本这是最大的变量。如果使用只读的squashfs挂载很快。但如果使用可读写的ext4 over SPI NAND挂载时的文件系统检查特别是非正常关机后的fsck会带来不可预测的延迟。此外/etc/init.d/或systemd启动的服务数量是决定用户空间启动时间的核心因素。一个完整的系统可能会启动dbus、NetworkManager、bluetooth、avahi等一堆服务每个都可能消耗数百毫秒。3. 核心优化策略与实操步骤定位了瓶颈接下来就是“对症下药”。优化是一个系统工程需要从底层到上层逐级推进。3.1 U-Boot阶段优化精简与加速U-Boot的优化目标很明确只保留启动内核所必需的功能并加快加载速度。1. 裁剪U-Boot功能进入U-Boot源码目录执行make menuconfig或修改对应的defconfig文件。禁用网络相关除非你需要网络引导tftp boot否则关闭CONFIG_CMD_NET,CONFIG_NET,CONFIG_CMD_PING,CONFIG_CMD_TFTPBOOT等。禁用非必要命令关闭CONFIG_CMD_USB,CONFIG_CMD_FPGA,CONFIG_CMD_IMI内存信息、CONFIG_CMD_IMLS列出所有镜像等调试或扩展命令。禁用文件系统支持如果你只用ext4或fat加载内核可以关闭CONFIG_FS_CRAMFS,CONFIG_FS_JFFS2,CONFIG_FS_UBIFS等。减少控制台输出可以适当提高CONFIG_BOOTDELAY为-1不等待直接启动并减少CONFIG_SYS_MALLOC_LEN等内存分配以加快初始化。实操心得裁剪后务必测试bootcmd是否能正常执行。一个极简的bootcmd可能类似sf probe 0; sf read ${loadaddr} 0x100000 0x800000; bootm ${loadaddr}。这表示从SPI Flash 0号设备偏移0x100000处读取8MB数据到内存然后启动。2. 优化SPI Flash读取速度T113的SPI控制器时钟可以提升。检查U-Boot中SPI控制器的初始化代码通常在board/sunxi/board.c或驱动文件中找到时钟配置部分。在保证Flash芯片支持的前提下可以将时钟从24MHz提升到50MHz甚至更高。这能直接减少内核和设备树的加载时间。修改示例需根据具体代码调整查找类似spi_setup_slave()或spi_set_max_speed()的调用将速度参数提高。风险提示过高的时钟可能导致读写不稳定。务必进行多次重启和读写测试确保可靠性。3. 启用内核压缩与跳过解压时间U-Boot的bootm命令在引导uImage旧格式时会自动解压。但对于更新的Image非压缩的ELF格式或fitImage内核本身可能是压缩的如Image.gz。解压需要时间。一个技巧是在U-Boot中先解压再引导未压缩的内核。方法将压缩的内核镜像如Image.gz烧写到Flash。在bootcmd中先将其加载到内存地址A然后使用gunzip ${loadaddr} ${unzip_addr} ${filesize}解压到另一个内存地址B最后使用booti ${unzip_addr} - ${fdt_addr}对于ARM64或bootm ${unzip_addr} - ${fdt_addr}对于ARM32启动。这样解压耗时被算在U-Boot阶段而内核启动时直接运行二进制代码跳过了自解压过程。虽然总时间可能变化不大但阶段划分更清晰。3.2 Linux内核优化移除冗余与延迟初始化内核是承上启下的关键优化原则是“非必要不初始化”。1. 精简内核配置这是最有效的方法之一。使用make menuconfig进行深度裁剪。移除不需要的驱动你的板子没有USB摄像头关掉CONFIG_USB_VIDEO_CLASS。没有PCIE关掉所有CONFIG_PCI*。没有音频关掉CONFIG_SND*。仔细审查设备树只启用实际存在的硬件对应的驱动。禁用调试与日志生产环境关闭CONFIG_DEBUG_INFO大幅减小内核大小、CONFIG_DEBUG_KERNEL、CONFIG_PRINTK可以保留但降低级别等。注意关闭CONFIG_PRINTK会影响早期启动日志建议先保留但设置loglevel0在内核命令行。优化内核模块如果使用模块将必须的驱动如SPI NAND、显示编译进内核y而不是模块m避免模块加载的耗时。不用的模块直接不编译。2. 调整内核启动参数cmdline通过U-Boot的bootargs环境变量传递给内核的参数能显著影响启动行为。rootdelay如果根文件系统在USB或MMC上可能需要等待设备就绪。如果根文件系统在SPI NAND上可以尝试设置为rootdelay0或移除。rootflags对于只读根文件系统如squashfs添加rootflagsro。quiet和loglevel0quiet参数减少内核控制台输出loglevel0最高级别只打印紧急信息。这能减少串口输出耗时对速度提升明显。initcall_debug仅用于调试。添加此参数会打印所有初始化调用的耗时用于定位慢的驱动。生产环境务必移除。init可以指定第一个进程例如init/bin/sh直接进入shell跳过所有初始化脚本用于测试内核启动到底有多快。示例优化后的bootargsconsolettyS0,115200 earlyprintk root/dev/mtdblock2 rootfstypesquashfs ro quiet loglevel03. 利用设备树进行电源与时钟管理检查设备树.dts文件中是否有外设默认被使能但实际上并未使用。例如未使用的i2c控制器、uart端口可以在设备树中将其状态设置为status disabled;防止内核去初始化它们。 对于显示设备如果内核启动早期不需要显示比如应用才启动GUI可以考虑在设备树中暂时禁用显示相关节点或者在内核中配置CONFIG_DRM_PANEL_BRIDGE等延迟初始化的选项让显示驱动在内核启动完成后再初始化。3.3 根文件系统与用户空间优化化繁为简用户空间是启动时间的“主战场”优化潜力最大。1. 选择与优化根文件系统首选只读文件系统如squashfs。它压缩率高挂载速度快且完全只读避免了挂载时的检查。将系统核心部分/bin,/sbin,/lib,/usr做成squashfs镜像。/etc目录中需要写的部分如配置文件和/var、/tmp可以使用tmpfs内存文件系统或overlayfs叠加文件系统来实现可写。避免使用ext4 on SPI NAND如果必须用确保正常关机避免fsck。可以在内核参数中添加rootflagsro先以只读方式挂载等系统启动后再由一个初始化脚本重新以读写方式挂载需要更复杂的脚本。使用initramfs对于非常简单的系统可以考虑将根文件系统直接编译进内核initramfs。这样内核启动后立即进入用户空间跳过了从慢速存储挂载根文件系统的等待。但这会增加内核体积且修改文件系统内容需要重新编译内核灵活性差。2. 简化Init流程以Busybox init为例精简/etc/inittab只保留最必要的行。例如确保只有一条::sysinit:/etc/init.d/rcS用于启动系统脚本一条::respawn:/sbin/getty用于登录控制台。移除所有tty2::askfirst等额外的登录提示。优化/etc/init.d/rcS脚本并行启动检查脚本中的服务哪些是真正必须在应用启动前完成的将没有依赖关系的服务启动命令放到后台在命令末尾加上。例如/etc/init.d/S50network start 。移除无用服务彻底删除或重命名将S开头改为K开头或不以S开头那些不需要的服务脚本如bluetooth、avahi-daemon、cron等。延迟启动对于非关键服务如日志轮转logrotate可以将其从rcS中移除改为在系统完全启动后由主应用或一个定时器触发。脚本效率避免在脚本中使用大量echo打印避免调用执行慢的命令如查找文件。3. 使用更快的Init系统如systemd虽然systemd本身有一定开销但它强大的并行启动能力对于依赖关系复杂的系统可能比串行的sysvinit脚本更快。关键是正确配置服务间的依赖。使用systemd-analyze工具这是分析启动时间的利器。systemd-analyze time看整体时间systemd-analyze critical-chain看关键路径systemd-analyze blame看每个服务的耗时。针对耗时长的服务进行优化。精简服务systemctl disable掉所有不需要的服务如bluetooth.service,ModemManager.service。调整服务超时有些服务启动慢可能因为等待某个资源超时。可以适当减少TimeoutStartSec的值在服务单元文件中让失败的服务不影响整体启动。但要小心这可能导致服务无法正常启动。4. 应用启动优化如果你的最终目标是一个图形应用如Qt程序那么应用本身的加载和初始化也是耗时大户。静态编译将应用和所需的Qt库静态链接避免动态链接器ld-linux在运行时加载和解析大量.so文件的时间。这会增大可执行文件体积但显著加快启动速度。预加载库如果必须动态链接可以考虑使用LD_PRELOAD环境变量或者在/etc/ld.so.preload中预加载常用库但效果有限。延迟初始化在应用代码中将非必要的初始化如网络连接、复杂资源加载放到主界面显示之后进行给用户一个“快速启动”的感知。4. 高级技巧与综合调优实战在完成上述基础优化后如果对启动时间还有极致要求可以尝试以下更深入的手段。4.1 利用休眠唤醒Suspend-to-RAM实现“瞬时启动”这不是传统意义上的启动而是深度睡眠。系统在第一次完全启动后将整个系统的状态CPU寄存器、内存内容保存下来然后进入极低功耗的休眠状态。当再次“开机”时实际上是恢复休眠前的状态耗时通常在1-3秒内实现“瞬间亮屏”。实现条件需要内核完美支持Suspend-to-RAMCONFIG_SUSPEND并且所有关键驱动显示、输入、存储都支持休眠/恢复回调。T113平台需要验证其电源管理芯片PMIC和DDR的自我刷新Self-Refresh功能是否支持。操作流程用户按下“关机”键实际触发休眠脚本echo mem /sys/power/state。下次上电时BootROM和U-Boot仍会正常执行但在U-Boot中需要配置好恢复内存内容的环境并跳转到内核的恢复入口点。这需要对U-Boot和内核有较深的定制。优缺点优点是“启动”极快。缺点是功耗不为零需要维持内存供电且“冷启动”后第一次休眠的保存过程较慢。适合需要频繁开关机但对功耗不极度敏感的场景如手持设备、POS机。4.2 优化内核与根文件系统加载位置如果板载有少量但速度更快的存储如片内SRAM、PSRAM或者通过SPI接口的NOR Flash可以利用它们来加速最关键的启动路径。XIP (eXecute In Place)将内核的代码段.text烧写到支持XIP的NOR Flash中U-Boot直接跳转到Flash地址执行省去加载到内存的时间。但T113通常搭配NAND Flash不支持XIP。二级加载将U-Boot、内核等镜像存储在慢速的SPI NAND中但上电后由U-Boot或一个初级加载器将这些镜像先拷贝到速度更快的介质如DDR中预留的一块“安全”区域或者外接的PSRAM中再从那里执行。这需要额外的存储介质和定制代码。Initramfs如前所述将最小的根文件系统集成到内核里完全避免早期挂载大容量慢速存储。适合系统小、定制度高的场景。4.3 综合优化案例从28秒到9.5秒以下是我在T113开发板上的一个真实优化案例记录基线测量原始系统使用buildroot构建包含Qt5应用。串口测量从U-Boot SPL开始到Qt应用主窗口显示总时间约28秒。U-Boot阶段含SPL~4.5秒Linux内核启动~3.5秒挂载根文件系统ext4 on SPI NAND并执行初始化脚本~12秒Qt应用加载与启动~8秒第一阶段优化U-Boot 内核裁剪U-Boot移除网络、USB等命令bootdelay设为0。时间降至~3秒。提升SPI Flash时钟至50MHz。内核加载时间减少约0.5秒。精简内核配置移除未使用的驱动摄像头、声卡、多个USB Host关闭DEBUG_INFO。内核启动时间降至~2.8秒。第二阶段优化文件系统与Init将根文件系统改为squashfs只读/var和/tmp挂载为tmpfs。挂载时间从~2秒降至~0.5秒。彻底重写/etc/init.d/rcS脚本将网络服务、LED灯控制等移至后台并行启动并移除syslogd、klogd由内核printk直接输出到控制台。用户空间脚本执行时间从~10秒降至~4秒。在/etc/inittab中移除所有多余的getty。第三阶段优化应用层将Qt应用改为静态编译。应用启动时间从~8秒降至~3.5秒。在应用代码中将“读取大型配置文件”和“初始化网络连接”的操作延迟到主界面显示后的一个定时器中执行。最终结果U-Boot阶段~2.8秒Linux内核~2.5秒挂载rootfs init~4.5秒Qt应用显示主窗口~1.5秒总计~9.5秒后续后台任务继续加载踩坑记录在尝试并行启动服务时遇到了网络服务还没起来应用就开始连接网络导致失败的问题。解决方法是在应用启动脚本中增加一个简单的循环检测直到网络接口eth0获得IP地址后再启动应用的核心逻辑或者使用sleep 2等简单延迟但这会牺牲一点时间。更好的方式是让应用具备网络重连机制。5. 常见问题排查与调试技巧优化过程中肯定会遇到各种问题。这里记录几个典型问题和排查思路。问题1优化后系统无法启动卡在U-Boot或内核早期。排查思路回退法确认最后修改了哪个部分内核配置、设备树、U-Boot环境变量先回退到能启动的状态。串口日志这是最重要的信息源。确保串口接线正确波特率匹配通常是115200。观察卡在哪一行打印信息之后。U-Boot阶段卡住常见于SPL初始化DDR失败内存参数不对、加载镜像失败Flash地址或大小错误、bootcmd命令错误。检查U-Boot编译时使用的dram参数以及sf read命令的偏移和长度是否与Flash布局匹配。内核早期卡住常见于设备树.dtb不匹配或损坏。确认U-Boot加载的fdt_addr是否正确以及设备树二进制文件是否与当前内核匹配。可以尝试使用旧版能启动的设备树。内核解压或运行卡住可能是内核镜像Image在加载过程中损坏或者内核配置如内存地址CONFIG_PAGE_OFFSET与U-Boot传递的参数不匹配。问题2启动速度优化不明显某个阶段耗时依然很长。排查思路精确计时使用前面介绍的bootstage、initcall_debug、date命令精确锁定耗时最长的阶段甚至函数。检查存储I/O如果内核启动或文件系统挂载慢很可能是SPI NAND的读写瓶颈。使用内核的ftrace功能跟踪块设备请求或者用time dd if/dev/mtdblockX of/dev/null测试原始读取速度。检查服务依赖使用systemd-analyze critical-chain查看哪些服务是启动关键路径上的瓶颈。对于sysvinit手动分析/etc/rcS和/etc/rcN.d/中的脚本用time命令包装每个重要命令找出慢的元凶。应用剖析如果应用启动慢可以使用strace -T跟踪应用启动过程看时间花在了哪些系统调用上如频繁的open、read库文件或者使用gprof、perf工具进行性能剖析。问题3系统能启动但某些功能如网络、显示失效。排查思路驱动被裁剪这是最可能的原因。检查内核配置确认相关驱动如CONFIG_SUNXI_EMACfor Ethernet,CONFIG_DRM_SUNXIfor Display是否被启用并编译进内核y。设备树节点被禁用检查设备树中对应硬件节点如ethernet,hdmi的status属性是否为okay。内核模块未加载如果驱动编译为模块m检查对应的.ko文件是否存在于根文件系统以及初始化脚本中是否执行了modprobe。优化时建议将关键驱动静态编译进内核。服务未启动网络失效可能是network.service或systemd-networkd服务被禁用。使用systemctl status network.service或检查/etc/init.d/下的网络脚本是否存在且可执行。调试工具箱速查表工具/方法作用阶段使用方式/命令关键输出信息U-BootbootstageU-Boot配置CONFIG_BOOTSTAGE并启用报告各初始化函数耗时列表内核initcall_debug内核启动内核参数添加initcall_debug每个*_initcall函数的耗时内核printk.time内核启动配置CONFIG_PRINTK_TIME或加time参数每条打印信息前的时间戳systemd-analyze用户空间(systemd)systemd-analyze time,blame,critical-chain整体时间、服务耗时、关键链strace应用启动strace -T -o trace.log /your/app应用执行的所有系统调用及耗时date命令任何阶段在脚本关键点插入date %s.%N绝对时间戳计算差值串口控制台全程连接串口设置正确波特率最原始、最重要的启动日志流启动速度优化是一个需要耐心和细致分析的工作没有一劳永逸的银弹。最好的策略是测量 - 假设 - 修改 - 验证的循环。每次只修改一个变量观察效果积累对系统启动流程的深刻理解。对于T113这类资源受限的平台往往最简单的裁剪和配置调整就能带来最显著的提升。当你看到设备从按下开关到呈现界面时间缩短了三分之二的那一刻那种成就感就是嵌入式开发的乐趣所在。
全志T113-i嵌入式Linux启动优化：从30秒到10秒的实战指南
1. 项目概述与核心价值最近在折腾一块基于全志T113-i芯片的开发板项目目标是把它打造成一个快速响应的嵌入式终端设备。在调试过程中我发现了一个非常影响用户体验的问题从按下电源键到系统完全就绪整个过程耗时接近30秒。对于追求“秒开”体验的工业HMI、智能零售终端或者广告机来说这个速度显然是不及格的。于是我花了大概两周时间深入系统启动流程的每一个环节把启动时间优化到了10秒以内。这个过程就像给一辆老爷车做全面性能调校涉及从硬件初始化到应用加载的方方面面不仅仅是改几个参数那么简单。T113这颗芯片性价比很高双核Cortex-A7加上内置的128MB DDR3在不少低成本嵌入式场景里很受欢迎。但正因为成本控制其启动链路上的各个环节都可能存在优化空间。这次优化不仅仅是追求一个数字更是对嵌入式Linux系统启动机制的深度梳理。无论你用的是T113还是其他类似的ARM平台比如RK3566、i.MX6ULL这套分析和优化思路都是相通的。如果你也在为你的设备启动慢而烦恼或者单纯想了解Linux系统到底是如何“醒来”的那么接下来的内容应该能给你不少直接的参考和启发。2. 启动流程深度拆解与耗时瓶颈定位优化启动速度第一步不是盲目动手而是先搞清楚时间都花在哪里了。我们需要一个清晰的“计时地图”。对于基于T113和类似平台的嵌入式Linux系统其启动流程可以划分为几个相对独立的阶段每个阶段都有其主导的耗时因素。2.1 启动阶段划分与测量方法一个典型的从Flash启动的流程如下ROM Code (BootROM)芯片上电后首先运行固化在芯片内部ROM中的一小段代码。它的任务是初始化最基本的外设如SRAM、时钟然后从指定的外部存储介质如SPI NAND Flash的固定位置加载下一阶段的引导程序。这个过程通常非常快在毫秒级一般不是优化重点。SPL (Secondary Program Loader) / U-Boot SPL由于内部SRAM容量有限BootROM加载的通常是一个精简的U-Boot称为SPL。SPL会初始化更复杂的外设最主要的是DDR内存控制器。初始化DDR的耗时与DRAM颗粒的型号、配置参数密切相关是前期的一个潜在瓶颈。SPL接着从Flash中加载完整版的U-Boot到DDR中并跳转执行。U-Boot (Full)完整的U-Boot会进行更全面的硬件初始化如网卡、USB、显示等如果配置了然后解析环境变量根据bootcmd的指示去加载内核镜像Image和设备树.dtb最后将控制权交给内核。U-Boot自身执行、等待启动指令如串口输入、加载大体积内核镜像的时间都需要关注。Linux Kernel内核启动阶段包括解压如果使用了压缩内核、汇编级初始化、C语言环境建立、设备树解析、驱动探测与初始化等。驱动初始化尤其是存储、显示等复杂外设的驱动可能耗时较长。内核最后会尝试挂载根文件系统rootfs。Root Filesystem Init Process根文件系统挂载成功后内核启动第一个用户空间进程通常是/sbin/init可能是busybox init、systemd或sysvinit。随后init进程会执行一系列启动脚本如/etc/inittab,/etc/rcS.d/*启动必要的系统服务如网络、日志、图形界面如Qt应用等。这个阶段往往是耗时最长的“重灾区”因为涉及大量磁盘I/O、进程fork和串行执行的脚本。要定位瓶颈我们需要在每个阶段结束时打上时间戳。最简单有效的方法是利用串口输出。在U-Boot中可以启用CONFIG_BOOTSTAGE和CONFIG_BOOTSTAGE_REPORT配置编译后U-Boot会在启动末尾打印出一份详细的耗时报告。另外也可以在U-Boot源码的关键位置如board_init_f,board_init_r以及bootm命令相关函数手动添加printf打印当前计时器值。在Linux内核中可以启用内核配置CONFIG_PRINTK_TIME这样所有内核打印信息都会附带时间戳从内核启动开始计算。通过观察不同驱动初始化之间的时间差就能定位内核阶段的瓶颈。更强大的工具是initcall_debug在内核命令行添加initcall_debug参数内核会打印出每一个初始化函数*_initcall的执行耗时信息非常详细。在用户空间可以在/etc/inittab或/etc/rcS脚本的最开头和关键服务启动前后使用date命令或/proc/uptime来记录时间。对于使用systemd的系统直接使用systemd-analyze blame命令就能列出所有服务的启动耗时是分析用户空间启动慢的神器。注意测量一定要在release模式关闭调试串口大量输出、关闭内核调试符号下进行。调试信息本身会通过串口打印而串口速率如115200bps是瓶颈会严重拖慢启动速度导致测量失真。优化前后的对比测量必须在同一配置下进行。2.2 T113平台特有的瓶颈点分析基于对T113开发板的实际测量我发现了几个值得特别关注的耗时点DDR初始化延迟T113-i通常搭配128MB或256MB的DDR3内存。U-Boot SPL中DDR初始化的代码dram_init会执行一系列DRAM颗粒的培训training流程以确保内存稳定工作。这个流程的耗时与DRAM厂商、速率以及SPL中的配置参数有关。有时为了兼容性SPL会使用比较保守的延时参数导致初始化变慢。从SPI NAND Flash加载镜像慢出于成本考虑很多T113板卡使用SPI NAND Flash作为存储。其读写速度远低于eMMC尤其是随机读取性能差。U-Boot加载几MB到十几MB的内核镜像以及内核读取文件系统数据时SPI NAND的慢速I/O会成为显著瓶颈。测量发现从Flash读取10MB的内核镜像在24MHz SPI时钟下可能需要近1秒。内核驱动探测与初始化Linux内核会探测并初始化所有在设备树中启用的设备驱动。对于显示驱动如T113的DE/TCON其初始化可能涉及显存分配、时钟配置、显示模式读取从屏的EDID等耗时可能达到几百毫秒。如果还启用了USB、以太网等复杂外设它们的探测时间也会累加。根文件系统挂载与初始化脚本这是最大的变量。如果使用只读的squashfs挂载很快。但如果使用可读写的ext4 over SPI NAND挂载时的文件系统检查特别是非正常关机后的fsck会带来不可预测的延迟。此外/etc/init.d/或systemd启动的服务数量是决定用户空间启动时间的核心因素。一个完整的系统可能会启动dbus、NetworkManager、bluetooth、avahi等一堆服务每个都可能消耗数百毫秒。3. 核心优化策略与实操步骤定位了瓶颈接下来就是“对症下药”。优化是一个系统工程需要从底层到上层逐级推进。3.1 U-Boot阶段优化精简与加速U-Boot的优化目标很明确只保留启动内核所必需的功能并加快加载速度。1. 裁剪U-Boot功能进入U-Boot源码目录执行make menuconfig或修改对应的defconfig文件。禁用网络相关除非你需要网络引导tftp boot否则关闭CONFIG_CMD_NET,CONFIG_NET,CONFIG_CMD_PING,CONFIG_CMD_TFTPBOOT等。禁用非必要命令关闭CONFIG_CMD_USB,CONFIG_CMD_FPGA,CONFIG_CMD_IMI内存信息、CONFIG_CMD_IMLS列出所有镜像等调试或扩展命令。禁用文件系统支持如果你只用ext4或fat加载内核可以关闭CONFIG_FS_CRAMFS,CONFIG_FS_JFFS2,CONFIG_FS_UBIFS等。减少控制台输出可以适当提高CONFIG_BOOTDELAY为-1不等待直接启动并减少CONFIG_SYS_MALLOC_LEN等内存分配以加快初始化。实操心得裁剪后务必测试bootcmd是否能正常执行。一个极简的bootcmd可能类似sf probe 0; sf read ${loadaddr} 0x100000 0x800000; bootm ${loadaddr}。这表示从SPI Flash 0号设备偏移0x100000处读取8MB数据到内存然后启动。2. 优化SPI Flash读取速度T113的SPI控制器时钟可以提升。检查U-Boot中SPI控制器的初始化代码通常在board/sunxi/board.c或驱动文件中找到时钟配置部分。在保证Flash芯片支持的前提下可以将时钟从24MHz提升到50MHz甚至更高。这能直接减少内核和设备树的加载时间。修改示例需根据具体代码调整查找类似spi_setup_slave()或spi_set_max_speed()的调用将速度参数提高。风险提示过高的时钟可能导致读写不稳定。务必进行多次重启和读写测试确保可靠性。3. 启用内核压缩与跳过解压时间U-Boot的bootm命令在引导uImage旧格式时会自动解压。但对于更新的Image非压缩的ELF格式或fitImage内核本身可能是压缩的如Image.gz。解压需要时间。一个技巧是在U-Boot中先解压再引导未压缩的内核。方法将压缩的内核镜像如Image.gz烧写到Flash。在bootcmd中先将其加载到内存地址A然后使用gunzip ${loadaddr} ${unzip_addr} ${filesize}解压到另一个内存地址B最后使用booti ${unzip_addr} - ${fdt_addr}对于ARM64或bootm ${unzip_addr} - ${fdt_addr}对于ARM32启动。这样解压耗时被算在U-Boot阶段而内核启动时直接运行二进制代码跳过了自解压过程。虽然总时间可能变化不大但阶段划分更清晰。3.2 Linux内核优化移除冗余与延迟初始化内核是承上启下的关键优化原则是“非必要不初始化”。1. 精简内核配置这是最有效的方法之一。使用make menuconfig进行深度裁剪。移除不需要的驱动你的板子没有USB摄像头关掉CONFIG_USB_VIDEO_CLASS。没有PCIE关掉所有CONFIG_PCI*。没有音频关掉CONFIG_SND*。仔细审查设备树只启用实际存在的硬件对应的驱动。禁用调试与日志生产环境关闭CONFIG_DEBUG_INFO大幅减小内核大小、CONFIG_DEBUG_KERNEL、CONFIG_PRINTK可以保留但降低级别等。注意关闭CONFIG_PRINTK会影响早期启动日志建议先保留但设置loglevel0在内核命令行。优化内核模块如果使用模块将必须的驱动如SPI NAND、显示编译进内核y而不是模块m避免模块加载的耗时。不用的模块直接不编译。2. 调整内核启动参数cmdline通过U-Boot的bootargs环境变量传递给内核的参数能显著影响启动行为。rootdelay如果根文件系统在USB或MMC上可能需要等待设备就绪。如果根文件系统在SPI NAND上可以尝试设置为rootdelay0或移除。rootflags对于只读根文件系统如squashfs添加rootflagsro。quiet和loglevel0quiet参数减少内核控制台输出loglevel0最高级别只打印紧急信息。这能减少串口输出耗时对速度提升明显。initcall_debug仅用于调试。添加此参数会打印所有初始化调用的耗时用于定位慢的驱动。生产环境务必移除。init可以指定第一个进程例如init/bin/sh直接进入shell跳过所有初始化脚本用于测试内核启动到底有多快。示例优化后的bootargsconsolettyS0,115200 earlyprintk root/dev/mtdblock2 rootfstypesquashfs ro quiet loglevel03. 利用设备树进行电源与时钟管理检查设备树.dts文件中是否有外设默认被使能但实际上并未使用。例如未使用的i2c控制器、uart端口可以在设备树中将其状态设置为status disabled;防止内核去初始化它们。 对于显示设备如果内核启动早期不需要显示比如应用才启动GUI可以考虑在设备树中暂时禁用显示相关节点或者在内核中配置CONFIG_DRM_PANEL_BRIDGE等延迟初始化的选项让显示驱动在内核启动完成后再初始化。3.3 根文件系统与用户空间优化化繁为简用户空间是启动时间的“主战场”优化潜力最大。1. 选择与优化根文件系统首选只读文件系统如squashfs。它压缩率高挂载速度快且完全只读避免了挂载时的检查。将系统核心部分/bin,/sbin,/lib,/usr做成squashfs镜像。/etc目录中需要写的部分如配置文件和/var、/tmp可以使用tmpfs内存文件系统或overlayfs叠加文件系统来实现可写。避免使用ext4 on SPI NAND如果必须用确保正常关机避免fsck。可以在内核参数中添加rootflagsro先以只读方式挂载等系统启动后再由一个初始化脚本重新以读写方式挂载需要更复杂的脚本。使用initramfs对于非常简单的系统可以考虑将根文件系统直接编译进内核initramfs。这样内核启动后立即进入用户空间跳过了从慢速存储挂载根文件系统的等待。但这会增加内核体积且修改文件系统内容需要重新编译内核灵活性差。2. 简化Init流程以Busybox init为例精简/etc/inittab只保留最必要的行。例如确保只有一条::sysinit:/etc/init.d/rcS用于启动系统脚本一条::respawn:/sbin/getty用于登录控制台。移除所有tty2::askfirst等额外的登录提示。优化/etc/init.d/rcS脚本并行启动检查脚本中的服务哪些是真正必须在应用启动前完成的将没有依赖关系的服务启动命令放到后台在命令末尾加上。例如/etc/init.d/S50network start 。移除无用服务彻底删除或重命名将S开头改为K开头或不以S开头那些不需要的服务脚本如bluetooth、avahi-daemon、cron等。延迟启动对于非关键服务如日志轮转logrotate可以将其从rcS中移除改为在系统完全启动后由主应用或一个定时器触发。脚本效率避免在脚本中使用大量echo打印避免调用执行慢的命令如查找文件。3. 使用更快的Init系统如systemd虽然systemd本身有一定开销但它强大的并行启动能力对于依赖关系复杂的系统可能比串行的sysvinit脚本更快。关键是正确配置服务间的依赖。使用systemd-analyze工具这是分析启动时间的利器。systemd-analyze time看整体时间systemd-analyze critical-chain看关键路径systemd-analyze blame看每个服务的耗时。针对耗时长的服务进行优化。精简服务systemctl disable掉所有不需要的服务如bluetooth.service,ModemManager.service。调整服务超时有些服务启动慢可能因为等待某个资源超时。可以适当减少TimeoutStartSec的值在服务单元文件中让失败的服务不影响整体启动。但要小心这可能导致服务无法正常启动。4. 应用启动优化如果你的最终目标是一个图形应用如Qt程序那么应用本身的加载和初始化也是耗时大户。静态编译将应用和所需的Qt库静态链接避免动态链接器ld-linux在运行时加载和解析大量.so文件的时间。这会增大可执行文件体积但显著加快启动速度。预加载库如果必须动态链接可以考虑使用LD_PRELOAD环境变量或者在/etc/ld.so.preload中预加载常用库但效果有限。延迟初始化在应用代码中将非必要的初始化如网络连接、复杂资源加载放到主界面显示之后进行给用户一个“快速启动”的感知。4. 高级技巧与综合调优实战在完成上述基础优化后如果对启动时间还有极致要求可以尝试以下更深入的手段。4.1 利用休眠唤醒Suspend-to-RAM实现“瞬时启动”这不是传统意义上的启动而是深度睡眠。系统在第一次完全启动后将整个系统的状态CPU寄存器、内存内容保存下来然后进入极低功耗的休眠状态。当再次“开机”时实际上是恢复休眠前的状态耗时通常在1-3秒内实现“瞬间亮屏”。实现条件需要内核完美支持Suspend-to-RAMCONFIG_SUSPEND并且所有关键驱动显示、输入、存储都支持休眠/恢复回调。T113平台需要验证其电源管理芯片PMIC和DDR的自我刷新Self-Refresh功能是否支持。操作流程用户按下“关机”键实际触发休眠脚本echo mem /sys/power/state。下次上电时BootROM和U-Boot仍会正常执行但在U-Boot中需要配置好恢复内存内容的环境并跳转到内核的恢复入口点。这需要对U-Boot和内核有较深的定制。优缺点优点是“启动”极快。缺点是功耗不为零需要维持内存供电且“冷启动”后第一次休眠的保存过程较慢。适合需要频繁开关机但对功耗不极度敏感的场景如手持设备、POS机。4.2 优化内核与根文件系统加载位置如果板载有少量但速度更快的存储如片内SRAM、PSRAM或者通过SPI接口的NOR Flash可以利用它们来加速最关键的启动路径。XIP (eXecute In Place)将内核的代码段.text烧写到支持XIP的NOR Flash中U-Boot直接跳转到Flash地址执行省去加载到内存的时间。但T113通常搭配NAND Flash不支持XIP。二级加载将U-Boot、内核等镜像存储在慢速的SPI NAND中但上电后由U-Boot或一个初级加载器将这些镜像先拷贝到速度更快的介质如DDR中预留的一块“安全”区域或者外接的PSRAM中再从那里执行。这需要额外的存储介质和定制代码。Initramfs如前所述将最小的根文件系统集成到内核里完全避免早期挂载大容量慢速存储。适合系统小、定制度高的场景。4.3 综合优化案例从28秒到9.5秒以下是我在T113开发板上的一个真实优化案例记录基线测量原始系统使用buildroot构建包含Qt5应用。串口测量从U-Boot SPL开始到Qt应用主窗口显示总时间约28秒。U-Boot阶段含SPL~4.5秒Linux内核启动~3.5秒挂载根文件系统ext4 on SPI NAND并执行初始化脚本~12秒Qt应用加载与启动~8秒第一阶段优化U-Boot 内核裁剪U-Boot移除网络、USB等命令bootdelay设为0。时间降至~3秒。提升SPI Flash时钟至50MHz。内核加载时间减少约0.5秒。精简内核配置移除未使用的驱动摄像头、声卡、多个USB Host关闭DEBUG_INFO。内核启动时间降至~2.8秒。第二阶段优化文件系统与Init将根文件系统改为squashfs只读/var和/tmp挂载为tmpfs。挂载时间从~2秒降至~0.5秒。彻底重写/etc/init.d/rcS脚本将网络服务、LED灯控制等移至后台并行启动并移除syslogd、klogd由内核printk直接输出到控制台。用户空间脚本执行时间从~10秒降至~4秒。在/etc/inittab中移除所有多余的getty。第三阶段优化应用层将Qt应用改为静态编译。应用启动时间从~8秒降至~3.5秒。在应用代码中将“读取大型配置文件”和“初始化网络连接”的操作延迟到主界面显示后的一个定时器中执行。最终结果U-Boot阶段~2.8秒Linux内核~2.5秒挂载rootfs init~4.5秒Qt应用显示主窗口~1.5秒总计~9.5秒后续后台任务继续加载踩坑记录在尝试并行启动服务时遇到了网络服务还没起来应用就开始连接网络导致失败的问题。解决方法是在应用启动脚本中增加一个简单的循环检测直到网络接口eth0获得IP地址后再启动应用的核心逻辑或者使用sleep 2等简单延迟但这会牺牲一点时间。更好的方式是让应用具备网络重连机制。5. 常见问题排查与调试技巧优化过程中肯定会遇到各种问题。这里记录几个典型问题和排查思路。问题1优化后系统无法启动卡在U-Boot或内核早期。排查思路回退法确认最后修改了哪个部分内核配置、设备树、U-Boot环境变量先回退到能启动的状态。串口日志这是最重要的信息源。确保串口接线正确波特率匹配通常是115200。观察卡在哪一行打印信息之后。U-Boot阶段卡住常见于SPL初始化DDR失败内存参数不对、加载镜像失败Flash地址或大小错误、bootcmd命令错误。检查U-Boot编译时使用的dram参数以及sf read命令的偏移和长度是否与Flash布局匹配。内核早期卡住常见于设备树.dtb不匹配或损坏。确认U-Boot加载的fdt_addr是否正确以及设备树二进制文件是否与当前内核匹配。可以尝试使用旧版能启动的设备树。内核解压或运行卡住可能是内核镜像Image在加载过程中损坏或者内核配置如内存地址CONFIG_PAGE_OFFSET与U-Boot传递的参数不匹配。问题2启动速度优化不明显某个阶段耗时依然很长。排查思路精确计时使用前面介绍的bootstage、initcall_debug、date命令精确锁定耗时最长的阶段甚至函数。检查存储I/O如果内核启动或文件系统挂载慢很可能是SPI NAND的读写瓶颈。使用内核的ftrace功能跟踪块设备请求或者用time dd if/dev/mtdblockX of/dev/null测试原始读取速度。检查服务依赖使用systemd-analyze critical-chain查看哪些服务是启动关键路径上的瓶颈。对于sysvinit手动分析/etc/rcS和/etc/rcN.d/中的脚本用time命令包装每个重要命令找出慢的元凶。应用剖析如果应用启动慢可以使用strace -T跟踪应用启动过程看时间花在了哪些系统调用上如频繁的open、read库文件或者使用gprof、perf工具进行性能剖析。问题3系统能启动但某些功能如网络、显示失效。排查思路驱动被裁剪这是最可能的原因。检查内核配置确认相关驱动如CONFIG_SUNXI_EMACfor Ethernet,CONFIG_DRM_SUNXIfor Display是否被启用并编译进内核y。设备树节点被禁用检查设备树中对应硬件节点如ethernet,hdmi的status属性是否为okay。内核模块未加载如果驱动编译为模块m检查对应的.ko文件是否存在于根文件系统以及初始化脚本中是否执行了modprobe。优化时建议将关键驱动静态编译进内核。服务未启动网络失效可能是network.service或systemd-networkd服务被禁用。使用systemctl status network.service或检查/etc/init.d/下的网络脚本是否存在且可执行。调试工具箱速查表工具/方法作用阶段使用方式/命令关键输出信息U-BootbootstageU-Boot配置CONFIG_BOOTSTAGE并启用报告各初始化函数耗时列表内核initcall_debug内核启动内核参数添加initcall_debug每个*_initcall函数的耗时内核printk.time内核启动配置CONFIG_PRINTK_TIME或加time参数每条打印信息前的时间戳systemd-analyze用户空间(systemd)systemd-analyze time,blame,critical-chain整体时间、服务耗时、关键链strace应用启动strace -T -o trace.log /your/app应用执行的所有系统调用及耗时date命令任何阶段在脚本关键点插入date %s.%N绝对时间戳计算差值串口控制台全程连接串口设置正确波特率最原始、最重要的启动日志流启动速度优化是一个需要耐心和细致分析的工作没有一劳永逸的银弹。最好的策略是测量 - 假设 - 修改 - 验证的循环。每次只修改一个变量观察效果积累对系统启动流程的深刻理解。对于T113这类资源受限的平台往往最简单的裁剪和配置调整就能带来最显著的提升。当你看到设备从按下开关到呈现界面时间缩短了三分之二的那一刻那种成就感就是嵌入式开发的乐趣所在。
