启动失败最怕“哪里都怀疑一点”。专业的排查方式是先把启动链拆开：BootROM、SPL、U-Boot、内核、设备树、rootfs，每一段都有明确的输入、输出和可观察证据。
面试先抓这几个点：
先判断串口是否有任何输出：完全无输出和进入U-Boot后卡住，是两类问题。
看U-Boot环境变量、bootcmd、bootargs、加载地址、镜像格式和存储介质读取是否正确。
能启动Kernel但挂在早期日志，要看设备树、时钟、中断、内存和earlycon。
Kernel起来后找不到rootfs，则重点看root=参数、驱动内建或模块化、文件系统和挂载设备。
面试官真正想听什么
这类问题通常不是考一句标准答案，而是看你能不能把原理、工程约束、验证方法和风险连成一条完整链路。回答时建议先讲判断条件，再讲设计动作，最后补上如何验证。
回答时可以按这几个方面组织
一个更像工程师的参考回答
遇到U-Boot启动卡住，我先根据串口最后一行日志确认停在哪个阶段。完全没有输出时会先看BootROM/SPL相关的启动介质、启动脚和DDR初始化；如果已经进入U-Boot，我会检查环境变量、bootcmd、bootargs、kernel和dtb加载地址以及镜像是否真的从存储读出来。能跳到Kernel但早期挂死时，我会开启earlycon并核对设备树和内存信息。若最后是VFS挂载失败，则重点看root=参数、对应存储驱动是否内建以及文件系统类型。每一步都用日志或内存内容确认，而不是直接重刷系统。
面试官可能继续追问
SPL和完整U-Boot分别主要做什么？
为什么Kernel驱动做成模块可能导致rootfs挂不上？
bootargs里console和earlycon有什么区别？
设备树地址加载错会有哪些表现？
容易失分的回答
一遇到启动失败就重烧镜像。
不区分U-Boot问题、Kernel问题和rootfs问题。
只看最后一句报错，不看启动链上一阶段的输入是否正确。
面试前可以这样准备
把自己平台的一次完整启动日志按阶段标注。
熟悉bootcmd、bootargs、kernel_addr_r、fdt_addr_r等常见变量。
准备一个“串口最后一行日志→下一步检查”的排查树。
核心关键词：U-Boot、BootROM、SPL、Kernel启动、rootfs、嵌入式Linux面试
