这周在折腾 STM32MP257F-EV1 开发板跑 OpenSTDroid遇到了一个很典型的启动问题从 DFU 模式把镜像写进 eMMC然后切到 eMMC 启动板子直接进入无限重启循环串口日志里反复刷IAC exception 128更难受的是死活进不了 fastboot 模式。前后折腾了两三天把整个排障过程、根因定位和最终恢复方法完整记录下来。这篇文章适合正在搭 OpenSTDroid 开发环境、或者手上正好有 STM32MP25 系列板卡的朋友参考遇到类似“刷完 eMMC 起不来”的情况基本可以照着这个思路排查一遍。1. 先把这个报错讲明白OpenSTDroid、DFU 和 eMMC 启动到底发生了什么1.1 这套启动链是怎么回事STM32MP257F-EV1 是 ST 基于 STM32MP257F 处理器做的评估板这颗芯片是双核 Cortex-A35 加 Cortex-M33 的架构定位在工业控制和边缘计算场景。OpenSTDroid 则是 ST 专门为这颗 SoC 维护的 Android 发行版跟我们平时用的手机 ROM 思路类似底层有 TF-A、OP-TEE、U-Boot上层有 Linux 内核和 Android 系统。启动流程大致是这样的芯片上电后片内 ROM 代码先跑负责根据启动引脚或 OTP 配置选择从哪个介质加载下一级引导程序。在 STM32MP2 系列上可选启动源包括 USB DFU、SD 卡、eMMC、NAND 等。接下来依次加载 FSBL也就是 TF-A BL2、FIP 包里面包含 BL31、BL32/OP-TEE、U-Boot、然后 U-Boot 再拉起 Linux 内核和 Android 用户空间。这里要注意一点OpenSTDroid 对引导链的完整性要求非常严格。因为 Android 有一套 AVBAndroid Verified Boot校验机制bootloader 之间的每个环节都会检查签名。任何分区内容不匹配、校验失败都有可能在启动过程中直接中断表现出来就是反复重启或者卡死。1.2 DFU 和 eMMC 是两个完全不同的“世界”DFUDevice Firmware Upgrade模式下芯片的 ROM 代码会主动枚举出一个 USB 设备让主机通过 USB 直接访问芯片的存储介质比如 eMMC、SD 卡或内存。在 STM32MP 平台上DFU 是“半砖”状态下最常用也是最好用的救砖通道只要 ROM 还没被烧坏基本都能靠 DFU 刷回来。但 DFU 和从 eMMC 正常启动是完全两条路径。DFU 是 ROM 代码直接接管 USB然后由 STM32CubeProgrammer 这类工具往目标介质写数据它不经过 TF-A不经过 U-Boot也不需要验证镜像合法性本质上是一个原始写入通道。而从 eMMC 启动的时候ROM 会去读 eMMC 里特定偏移处的 FSBL读完以后把控制权交给 TF-A。后面再加载什么TF-A、OP-TEE、U-Boot 都是逐级校验的。很多人在 DFU 刷完镜像后习惯性地切到 eMMC 启动结果发现起不来。原因往往就藏在“DFU 能写不代表写进去的东西能正常被启动链读出来并且通过校验”这句话里。1.3 IAC exception 128 到底代表什么先解释一下 IAC 三个字母ST 在 STM32MP2 系列中引入了一个比较关键的总线防火墙机制叫 Initiator Access Control直译过来就是“发起者访问控制”。它负责管理系统里的各种总线主设备比如 Cortex-A35、Cortex-M33、DMA 等对内存区域和外设寄存器的访问权限。可以把它理解成大楼的安保系统每个进入房间的人都有工牌IAC 就是那道闸机权限不够就拦住。报错里的exception 128从串口日志语境来看通常是 TF-A 或者 OP-TEE 在初始化阶段访问某个内存区域或外设寄存器时被 IAC 单元拦下并触发异常数值 128 对应具体的异常/访问错误分类。不同版本的固件里这个编号含义可能略有差异但核心问题是一致的某段代码去碰了它没权限碰的地址。当这个异常发生在引导阶段比如 TF-A 初始化 DDR、配置外设时钟时系统整体还处于非常早期的状态没有可靠的异常处理机制所以芯片会直接复位重启。复位后再次执行同样的代码再次触发同一个异常于是就成了无限重启循环。这也解释了为什么 fastboot 进不去fastboot 在 U-Boot 阶段才提供eMMC 启动链在 TF-A 阶段就崩了U-Boot 压根没机会跑起来。2. 现场复现从“能烧”到“无限重启”的过程记录2.1 复现前的环境清单这次复现的硬件环境如下STM32MP257F-EV1 评估板一块一个 USB-C 数据线用于连接主机和板子的 DFU/OTG 口一根 USB-C 转 USB-A 数据线连接串口调试器板载 ST-Link 也可以一台 Linux 主机Ubuntu 22.04安装 STM32CubeProgrammer 和 Android platform-tools一个稳定的 12V 电源适配器确保供电充足主机侧需要装好两个工具STM32CubeProgrammer用于 DFU 刷写fastboot用于后续的 fastboot 操作。Linux 下一般还需要配置好 udev 规则否则设备节点权限不够工具会提示找不到设备。板卡上的串口调试信息建议直接接到板载 ST-Link 的虚拟串口上波特率一般是 1152008N1。这一步非常关键后面所有分析都依赖串口日志没有日志就是盲人摸象。2.2 完整复现步骤避坑版我的操作顺序是这样的先把 boot 拨码开关切到 USB/DFU 启动档位。用 USB-C 线把板子连接到主机。确认 STM32CubeProgrammer 能识别到设备执行STM32_Programmer_CLI -l dfu正常会列出一个 USB DFU 设备。使用 STM32CubeProgrammer 的图形界面或命令行加载 OpenSTDroid 生成的 flashlayout 文件把镜像写到 eMMC。烧录完成后按正常流程断开连接、断电。将 boot 拨码开关切到 eMMC 启动档位重新上电。打开串口终端观察启动日志发现无限重启。烧录时我用的 flashlayout 文件是 OpenSTDroid 构建产物里的flashlayout_stm32mp257f-ev1系列里面定义了全部分区起始位置和大小包括fsbl1、fsbl2、fip、bootfs、vbmeta、super等。这里要特别强调一句烧录的时候千万别手动改分区表也不用只挑几个分区刷。OpenSTDroid 的分区布局是写死的手动改偏移或者漏刷分区后面基本都会出问题。2.3 串口日志怎么看才不慌复现后串口日志大概是这个样子NOTICE: BL2: v2.8-stm32mp25-r1(debug):df7c2b3 NOTICE: BL2: Booting BL32 ERROR: IAC exception 128 from current context ERROR: Initiator access control fault ERROR: panic!注意完整日志里会有很多其他信息比如 DDR 初始化、时钟配置、FIP 加载进度等。一旦看到IAC exception 128出现就要立刻倒回去看它是在哪一行之后出现的。这个位置决定了问题出在哪一层。如果日志停在了 TF-A 的某个初始化步骤之后比如 DDR 初始化完成、但还没进入 BL32那大概率是 TF-A 在访问某个外设地址时被 IAC 拦截。如果日志已经显示出 OP-TEE 的 banner那问题可能出在 OP-TEE 的安全配置上。如果日志已经出现 U-Boot 版本号只是在进 fastboot 时卡住或崩掉那问题就完全不一样属于接入层问题而非启动链问题。我这次的情况是日志里能看到BL2: v2.8...和Booting BL32随后立刻撞出 IAC 异常然后复位。基本可以确定在 TF-A 加载 BL32 阶段就凉了根本没碰到 U-Boot。3. 根因定位思路为什么刷完就崩3.1 第一嫌疑镜像没刷全遇到启动崩溃第一反应应该是检查烧录内容是否完整。不要因为 DFU 刷写过程顺利就默认所有分区都写对了。DFU 模式下STM32CubeProgrammer 是按 flashlayout 文件逐个分区刷的。每一步都会有进度条和状态回显但人很容易忽略中间某一步的报错比如“Fail to write partition xxx”然后又因为 GUI 交互太顺手直接点了 OK导致实际漏刷了某个分区。我的排查习惯是刷完后用STM32_Programmer_CLI的读取命令把 eMMC 里关键分区的校验值拉出来和本地镜像对比。STM32MP 的 FIP 分区带有标准头可以直接从 eMMC 里读取 FIP 头部并解析出镜像列表如果读不到合法 header说明 FIP 没刷进去或者偏移不对。另外还有一个非常容易被忽视的点FIP 里面打包了多个镜像包括 BL31、BL32、U-Boot以及各自的设备树。如果构建 OpenSTDroid 的时候改了 TF-A 或 OP-TEE 的配置必须重新生成 FIP 并烧录对应分区。只更新了 U-Boot 或内核而没刷新 FIP往往会出现版本不一致轻则启动参数异常重则直接触发防火墙访问异常。3.2 第二嫌疑防火墙/总线权限配置没跟上这次的问题最后定位在 IAC 配置上这也是我认为的最终根因。OpenSTDroid 默认的安全启动策略里IAC 的静态防火墙配置是通过 TF-A 和 OP-TEE 侧的安全机制写进系统寄存器里的。这个配置的源头并不在 U-Boot 或内核而在 TF-A 的启动早期初始化里。正常情况下构建系统会生成一份和设备匹配的安全配置并在 TF-A 启动时自动应用。但如果构建时用了与板卡不匹配的设备树、或者手动修改过启动参数导致 TF-A 走了一个错误的初始化路径就有可能在访问某个片上外设的寄存器时被 IAC 单元拦下。这里有个非常重要的前提STM32MP257F 和同系列的 STM32MP251/253 外设资源其实有差异。如果我用的是通用构建产物、不是针对 EV1 板卡的精简配置或者换过其他板卡的 FIP 镜像IAC 规则就会对不上异常就是这么来的。解决办法是重新确认构建版本确保烧进 eMMC 的fip分区和fsbl1/fsbl2分区来自同一次构建。如果确认之后问题消失那说明之前 100% 是镜像错配。3.3 第三嫌疑eMMC 启动配置被写坏eMMC 本身除了用户数据分区还有 boot partition 1 和 boot partition 2 两个特殊区域以及一个扩展 CSD 寄存器用来控制 boot 模式、访问时序和总线宽度。STM32MP 平台从 eMMC 启动时ROM 会按照 eMMC 的 boot 配置去读取 FSBL。如果在 DFU 烧录的时候偶尔出现掉电、烧录中断或者你在工具里执行了一些 eMMC 高级配置操作比如修改 boot bus width、切换 boot partition就有可能把 eMMC 的启动配置写坏。之后 ROM 读不到完整合法的 FSBL自然无法进入后续启动流程。另一个常见问题是 eMMC 上已经写入了旧版本或者不同项目的 FSBL。ROM 不会去分辨镜像版本它只会去固定偏移找数据。只要那个位置上有内容ROM 就尝试加载。如果内容恰好是另一块板卡的旧 TF-A启动到某个外设初始化阶段被 IAC 拦下来也是完全可能的。所以遇到 IAC 异常除了看 FIP还要回头确认 eMMC 的 boot 配置以及 fsbl1/fsbl2 区域内容是不是预期的。3.4 关于 fastboot 进不去的三点误区很多人一看到“无法进入 fastboot”就怀疑主机驱动、USB 线材这其实是被手机刷机经验带偏了。在嵌入式开发板上fastboot 进入不了有更前置的问题。第一U-Boot 本身没起来。这个场景下fastboot 作为 U-Boot 的一个命令自然不存在。你敲任何键、按住任何按键都没有意义。解决办法是让启动链先健康起来。第二U-Boot 起来了但没开 fastboot。OpenSTDroid 的 U-Boot 配置里通常默认打开 fastboot 支持但如果你用的不是 OpenSTDroid 官方产物而是自己裁剪的 U-Boot可能压根没编译CONFIG_FASTBOOT。这时候 U-Boot 控制台里敲fastboot 0会提示 unknown command。第三U-Boot 起来了fastboot 命令也支持但 USB 设备枚举不出来。这种情况主机端会显示waiting for device。排查方向包括是否接的是 OTG 口而非 device 口、线材是否为数据线、主机端 udev 规则是否正确、U-Boot 中 USB gadget 驱动是否初始化成功。我会在下一节详细说。4. 恢复方法与实操细节从救砖到二次验证4.1 第一步把 DFU 找回来无限重启不可怕只要还能进 DFU 就能救。STM32MP257F-EV1 的 ROM 优先级很高只要 boot 引脚配置成 USB 启动芯片上电后就不会去碰 eMMC而是直接枚举 DFU 设备。操作步骤断电。把 boot 拨码开关切回 USB/DFU 启动档位。如果板子没有拨码开关通常是按住 BOOT 键再上电具体看板子丝印和用户手册。连接 USB 线到主机。上电。执行STM32_Programmer_CLI -l dfu确认设备枚举成功。如果这一步设备都识别不到优先检查两点一是 USB 线是不是数据线很多 Type-C 线只能充电二是主机有没有给 DFU 设备权限Linux 下需要 udev 规则Windows 下需要安装 DFU 驱动。4.2 第二步重新烧写镜像的正确顺序确认能识别 DFU 设备后我建议不要直接用图形界面一键烧录而是用STM32_Programmer_CLI一个一个分区写这样出错了能立刻知道是哪个分区的问题。烧录顺序遵循从底层到上层的原则# 先擦除 eMMC 的 boot 区域再写 FSBL STM32_Programmer_CLI -c portUSB1 -w fsbl1.stm32 0x00000000 STM32_Programmer_CLI -c portUSB1 -w fsbl2.stm32 0x00020000 # 写 FIP 分区 STM32_Programmer_CLI -c portUSB1 -w fip.bin 0x00040000 # 写 bootfs 和超级分区 STM32_Programmer_CLI -c portUSB1 -w bootfs.ext4 0x00080000 STM32_Programmer_CLI -c portUSB1 -w super.bin 0x000C0000注意不同构建版本的 flashlayout 分区偏移可能不完全相同上面的偏移值只是示例以你手上 flashlayout 文件为准。一定要在烧录前打开 flashlayout 核对每个分区起始地址。擦除 eMMC 的做法建议直接通过 STM32CubeProgrammer 对整个 eMMC 做 raw 擦除然后重新写所有分区。只覆盖个别分区而保留其他旧分区容易造成版本混乱。我这次就是先完整擦除再重新写入整套镜像来自同一次构建问题才稳定解决。4.3 第三步验证和二次启动烧录完成后不要急着切启动源。先做一次快速验证保持 DFU 启动模式重新枚举设备抽查几个关键分区的读取结果确认 FIP header 合法、文件大小和本地一致。然后断电切换到 eMMC 启动上电观察串口日志。这次应该能正常看到 TF-A 完整启动、BL32 进入、U-Boot banner 出现最后停在 Android 内核启动阶段或直接进入系统。如果 U-Boot 正常起来但没自动进 fastboot可以在 U-Boot 控制台里手动执行fastboot 0如果看到Fastboot: Normal或者USB device相关提示说明 fastboot 已经准备就绪。此时主机端执行fastboot devices应该能看到对应的设备 ID。4.4 如果还不行还有哪些可以试如果重新烧写全套镜像后依然无限重启可以从这几个方向继续排查换一个 USB 口和电源适配器。部分评估板对供电质量敏感电源波动会导致 TF-A 初始化 DDR 时不稳定这种不稳定也可能表现为异常或复位。检查是否有其他外部外设板卡连接部分扩展板会占用 IAC 规则里定义的资源导致冲突。检查 TF-A 和 OP-TEE 的日志级别把日志调成 verbose 模式能看到更详细的 IAC 触发源地址。如果手上还有一块正常的 STM32MP257F-EV1 板卡可以做交叉对比把正常板卡的 eMMC 完整导出一个镜像用 DFU 刷到问题板卡上如果恢复说明问题板卡的硬件大概率没问题纯粹是软件配置问题。5. 常见问题速查与避坑清单5.1 日志关键错误速查表这里整理一份排查速查表方便大家对照日志快速定位日志现象可能原因优先处理IAC exception 128在 BL2 加载后出现TF-A/FIP 镜像配置与该板卡不匹配重新用同一次构建生成 fsbl/fip 并重烧IAC exception 128在 OP-TEE 启动后出现OP-TEE 安全配置或设备树资源冲突核对 DTB 与板卡型号是否对应DFU 设备识别不到USB 线材/供电/驱动问题换数据线、检查 udev 规则、安装驱动eMMC 启动后无任何日志eMMC boot 配置损坏或 FSBL 缺失用 DFU 重新烧 fsbl1/fsbl2 并检查 eMMC boot 配置U-Boot 起来了但 fastboot 命令无效内核/构建未打开 fastboot 支持检查 CONFIG_FASTBOOT换官方 OpenSTDroid 产物主机waiting for device线材/USB gadget 未初始化查看 U-Boot 日志确认 USB 枚举是否成功刷入后启动正常但进不去 Androidsuper 分区不完整或 AVB 校验失败重刷 super 分区确认 vbmeta 分区正确5.2 我踩过的坑可以直接抄的注意事项这次排障过程中有几个细节值得单独拎出来说。第一刷机前一定把串口日志备份好。我一开始只顾着看 GUI 烧录进度没有全程保存串口输出导致第一次复现时缺少关键日志只能从头再跑一遍。建议用script或tee命令把串口输出完整存下来。第二不要轻易在全擦除前拔电。DFU 烧录中如果中途断电eMMC 的分区表区域可能处于半写状态运气好还能重新刷运气不好会把 eMMC boot 分区头写坏后面排查成本直接翻倍。烧录期间一定保证电源稳定。第三STM32CubeProgrammer 的“刷完自动复位”选项不一定是好的。默认烧完以后工具可能会自动让芯片跳到 eMMC 启动如果 boot 引脚切在 USB 启动档这个跳转会失败看起来像是烧录失败实际并没有。建议烧完后手动断电、手动切换启动源。第四fastboot 进去以后不要急着刷镜像先执行fastboot getvar all看一下当前分区、槽位和版本信息。这个命令能帮你确认 U-Boot 和 Android 侧是否匹配也能验证 USB 链路是否稳定。第五如果需要在多台主机之间切换操作建议把 STM32CubeProgrammer 和 Android platform-tools 的版本固定一下。不同版本的 fastboot 协议实现有差异在开发板上偶尔会出现命令超时不一定是板子问题。第六关于 udev 规则Linux 下一定要给 DFU 和 fastboot 设备加权限。可以新建/etc/udev/rules.d/99-stm32.rules把 ST 官方提供的规则文件复制进去然后sudo udevadm control --reload。没配这个规则的话很可能在lsusb里能看到设备但工具读不到。对我个人来说这次排障最大的体会是OpenSTDroid 这类系统对构建产物的一致性要求远比普通 Linux 嵌入式系统高不能在“能烧写完”和“能启动”之间划等号。真正让我绕过弯路的不是某一个巧妙的调试技巧而是把启动链上的每一层都当成一个独立的可信验证环节逐级确认到位。尤其是 IAC 这种安全防火墙一旦权限配置出错行为不会表现为某个功能失效而是整个系统在启动早期直接崩溃排障时必须跳出“看代码找 bug”的惯性回到镜像一致性这个最基础的点上。希望这篇记录能帮遇到同样问题的朋友省下两三天折腾时间。