U-Boot 启动参数：内核起不来，先看 bootargs

U-Boot 启动参数内核起不来先看 bootargs一、启动失败不一定是内核坏了嵌入式 Linux 启动失败时很多人第一反应是改内核配置或怀疑驱动。实际现场里bootargs 写错更常见。rootfs 路径、console、分区 UUID、init 参数、内存保留区只要一项不对内核就可能卡住或 panic。U-Boot 启动参数是 bootloader 和内核之间的合同。内核按它去找根文件系统、输出串口日志、解析设备树和保留内存。合同写错后面再怎么改驱动都没用。二、启动链路要把环境变量展开看U-Boot 里常见bootcmd调用多个变量变量又引用其他变量。排查时不能只看最后一行要把完整展开后的命令看清楚。flowchart TD A[U-Boot 环境变量] -- B[bootcmd] B -- C[加载 kernel] B -- D[加载 dtb] B -- E[设置 bootargs] C -- F[booti 或 bootm] D -- F E -- F F -- G[Linux Kernel]很多问题就藏在变量拼接里。比如root/dev/mmcblk0p2写死后量产分区顺序一变就挂。三、保留一套最小可启动参数排障时可以先用最小 bootargs 启动确认内核和 rootfs 基本可用。setenv bootargs consolettyS0,115200 root/dev/mmcblk0p2 rw rootwait init/sbin/init fatload mmc 0:1 ${kernel_addr_r} Image fatload mmc 0:1 ${fdt_addr_r} board.dtb booti ${kernel_addr_r} - ${fdt_addr_r}rootwait很关键。存储设备初始化慢时没有它会导致内核过早挂载 rootfs 失败。串口参数也要和设备树里的 UART 对上。四、bootargs 修改要可回滚现场设备不要直接覆盖唯一环境变量。可以保留bootargs_default和bootargs_test测试失败后自动回退。U-Boot 环境区损坏也要考虑最好有默认环境编译进镜像。还要注意安全。生产设备的启动参数不应随意开放修改。某些参数能绕过安全策略或进入调试模式量产前要锁定写保护和升级流程。最后启动日志要保存。串口日志是排查 bootargs 的第一证据。没有日志只能猜内核卡在哪一步。量产设备至少要能在失败时保留最近一次启动原因。还要确认设备树地址。booti或bootm传入的 dtb 地址如果被内核镜像、initrd 或保留内存覆盖启动现象会很诡异。U-Boot 环境里应统一管理kernel_addr_r、fdt_addr_r和ramdisk_addr_r并留出足够间隔。rootfs 参数也要适配存储类型。eMMC、NAND、NFS、initramfs 的写法不同。NAND 上还要考虑 UBI volume 名称网络启动要确认 ip、serverip 和 nfsroot。bootargs 不是一份通用模板必须跟板级启动方案绑定。生产环境建议把启动参数打印到早期日志。这样现场拿到一段串口输出就能知道设备到底用哪套参数启动而不是猜环境变量是否保存成功。五、总结U-Boot bootargs 是内核启动的关键输入。内核起不来时先展开 bootcmd 和环境变量确认 console、rootfs、dtb 和 init 参数。排障要保留最小启动参数生产要提供回滚和写保护。启动链路越底层越不能靠猜。