i.MX8M Plus — Secondary image boot (IMG_CNTN_SET1_OFFSET) on ECSPI/SPI NOR: does ROM fall back in OP i.MX8M Plus -- Secondary image boot (IMG_CNTN_SET1_OFFSET) on ECSPI/SPI NOR: does ROM fall back in OPEN config? ==== Setup ==== - SoC: i.MX8M Plus (custom SMARC module) - Boot device: serial NOR on ECSPI2 / CS1 (Winbond W25Q128, 16 MiB). This is the legacy eCSPI controller, NOT FlexSPI. - Security: OPEN configuration (device is not HAB-closed). - Fuse IMG_CNTN_SET1_OFFSET (fuse read 2 1) = 0x00000000. - Flash map: primary bootloader at 0x000000, secondary copy at 0x400000 (4 MiB). Per the documented SPI mapping: "For SPI: secondary boot disabled if fuse > 10; n == 0 -> Offset = 4 MB; n == 2 -> 1 MB; others & n <= 10 -> 1 MB * 2^n." With fuse n = 0 (factory default, no burn needed) the secondary offset should be exactly 0x400000. ==== The problem ==== We placed a byte-identical, cmp.b-verified copy of the primary image at 0x400000, then invalidated the primary boot header (sf erase 0 0x1000) and reset. The ROM does NOT fall back to the secondary image -- the board is bricked (recoverable only via USB SDP). We also tried erasing a hole inside the primary body (sf erase 0x100000 0x40000) with the same result. ==== Questions ==== 1. On SPI/ECSPI NOR, what exactly triggers the ROM to switch to the secondary image at the IMG_CNTN_SET1_OFFSET? Is it any invalid primary boot header / failed image parse, or specifically a HAB authentication failure? 2. Does secondary-image boot work in OPEN (non-secured) configuration, or only when the device is HAB-closed? 3. Does it fall back on the same reset, or does it require a power cycle / second reset (persistent-boot style)? 4. Must the secondary image at 0x400000 be a separately-built bootable image (its own IVT/boot data for that offset), or is a byte-identical copy of the primary sufficient? ==== Logic-analyzer evidence (SPI bus captured during reset) ==== We probed the ECSPI2 bus (CLK, MOSI, MISO, CS) with a Saleae Logic Pro 16 at 500 MS/s and decoded every SPI transaction during reset. For comparison we did the same on an i.MX8QM module which boots from FlexSPI NOR and does fall back to secondary successfully. ---- i.MX8M Plus (ECSPI NOR), primary corrupted ---- The ROM issues only 0x03 READ commands, reading strictly sequentially from offset 0: 0x03 00 00 FC -> READ 0x0000FC 0x03 00 04 EC -> READ 0x0004EC 0x03 00 08 DC -> READ 0x0008DC ... (~50 reads per 64 KiB block, strictly increasing) ... 0x03 00 13 xx -> read count drops here (erased hole 0x100000-0x140000, MISO=0xFF) 0x03 00 18 xx -> continues LINEARLY past the hole ... up to ~0x1A69E8 ... The ROM reads linearly through the entire primary region, straight through the erased/invalid area (getting 0xFF back), and NEVER issues a read to 0x400000 or 0x800000 (the secondary region). There is no "0x03 40 xx xx" anywhere in the full capture (25 million samples, 654 decoded transactions). On a fully-erased-header case the ROM loads 0xFF, executes it, and crashes with a Synchronous Abort -- no fallback of any kind. ---- i.MX8QM (FlexSPI NOR), for contrast -- secondary fallback DOES work ---- When only the primary container header is invalidated (FCB left intact at 0x000400), the QM ROM does: 0x0B 00 04 00 -> Fast-Read FCB @0x000400, MISO: 46 43 46 42 ("FCFB" magic, FlexSPI config valid) ... reads FCB configuration data ... 0x0B 00 10 00 -> Fast-Read primary container @0x001000, MISO: FF FF FF FF (invalid!) 0x0B 40 10 00 -> Fast-Read SECONDARY container @0x401000, MISO: valid <-- ROM switched, SAME reset 0x0B 40 30 00, 0x0B 40 40 00, ... -> loads whole secondary image (~90 reads at 0x40xxxx) The QM ROM reads FCB, configures FlexSPI, checks the primary container at 0x001000, sees 0xFF, and immediately (same reset) switches to the secondary container at 0x401000. This works. If we instead erase the whole first 4 MB (including the FCB), the QM ROM makes only 2 reads at 0x000400, gets 0xFF, and does NOT fall back -- so a valid FCB is required for the fallback to engage. ---- Comparison ---- i.MX8M Plus (this board): Controller : eCSPI (legacy SPI) Read opcode: 0x03 READ FCB present: No (eCSPI has no FCB concept) Reads secondary on corrupt primary: NO -- bus never shows "0x03 40 xx xx" Result: bricks (loads 0xFF -> crash) i.MX8QM (reference): Controller : FlexSPI Read opcode: 0x0B Fast Read FCB present: Yes (0x400, magic "FCFB") Reads secondary on corrupt primary: YES -- "0x0B 40 10 00", same reset Result: boots secondary successfully ==== Summary ==== From the bus captures, the IMG_CNTN_SET1_OFFSET secondary-image boot on i.MX8M Plus appears to be either FlexSPI-only, or gated by HAB-closed config, and does not engage for eCSPI NOR in OPEN config. Could NXP please confirm: - Whether eCSPI (as opposed to FlexSPI) NOR is supported for secondary-image boot at all on i.MX8M Plus; - Whether the trigger is HAB-auth-failure (closed config only) vs. any invalid header (open config too); - Whether fallback is same-reset or requires a power cycle; - Whether the secondary must be separately built for that offset, or a byte-identical copy is OK. Thank you.
記事全体を表示
