Re: [REGRESSION] imx8mm_evk: FSPI build broken by 37e50627e
On 4/3/26 9:23 PM, Alexander Koch wrote: I think I have narrowed down the cause for the broken SPL blob but I don't fully understand it. Comparing hexdumps of the last working SPL+DDR blob and the first broken one we can see three chunks of difference: 1) two bytes near the IVT 2) U-Boot version string and compile timestamp 3) four bytes around offset 0x18b50 (striped at 16 bytes) Let's ignore number 2) as that is expected and focus on 1) and 3). For the first difference we have at offset 0x20 in spl.bin (0x1020 in flash.bin): good: 0020: C0 0F 7E 00 00 DC 02 00 bad: 0020: C0 1B 7E 00 00 D0 02 00 I first thought it could be the boot data pointer not reflecting the FSPI config blob offset but if I read `struct ivt` correctly this is actually _after_ the IVT itself. So I patched these two bytes in the broken 'flash.bin' and that made the SPL run (while console output still stopped before ATF). board/nxp/imx8mm_evk/imximage-8mm-lpddr4.cfg:LOADER u-boot-spl-ddr.bin 0x7E1000 configs/imx8mm_evk_defconfig:CONFIG_SPL_TEXT_BASE=0x7E1000 It seems the SPL entry point address somehow changed ... from 0x7e0fc0 to 0x7e1bc0 .. the delta is 0xc00 , does that fit into some offset in the imx8mm-u-boot.dtsi binman node ? The second chunk of interest is at offset 0x18b50 in spl.bin (0x19b50 in flash.bin): good: 0001 8B50: B8 C4 80 00 00 00 00 00 0001 8B60: F8 69 80 00 00 00 00 00 0001 8B70: 74 63 80 00 00 00 00 00 0001 8B80: 80 E5 7F 00 00 00 00 00 bad: 0001 8B50: B8 D4 80 00 00 00 00 00 0001 8B60: F8 79 80 00 00 00 00 00 0001 8B70: 74 73 80 00 00 00 00 00 0001 8B80: 80 F5 7F 00 00 00 00 00 After patching those 4 bytes I got ATF and U-Boot proper running so I'd consider that flash.bin fixed. Can anybody tell me what we have in those two locations? These locations are offsets of the lpddr4_pmu_train_* DRAM init blobs , see arch/arm/dts/imx8mm-u-boot.dtsi . When binman bundles those blobs together with SPL, it patches the locations of those blobs into the SPL binary. It seems it patches in the wrong offsets ... offset by 0x1000 Bytes , isn't that the size of the FSPI page ? Thank you for investigating this problem, it is much appreciated ! +CC Simon, maybe he can help with binman ?
Re: [REGRESSION] imx8mm_evk: FSPI build broken by 37e50627e
I think I have narrowed down the cause for the broken SPL blob but I don't fully understand it. Comparing hexdumps of the last working SPL+DDR blob and the first broken one we can see three chunks of difference: 1) two bytes near the IVT 2) U-Boot version string and compile timestamp 3) four bytes around offset 0x18b50 (striped at 16 bytes) Let's ignore number 2) as that is expected and focus on 1) and 3). For the first difference we have at offset 0x20 in spl.bin (0x1020 in flash.bin): good: 0020: C0 0F 7E 00 00 DC 02 00 bad: 0020: C0 1B 7E 00 00 D0 02 00 I first thought it could be the boot data pointer not reflecting the FSPI config blob offset but if I read `struct ivt` correctly this is actually _after_ the IVT itself. So I patched these two bytes in the broken 'flash.bin' and that made the SPL run (while console output still stopped before ATF). The second chunk of interest is at offset 0x18b50 in spl.bin (0x19b50 in flash.bin): good: 0001 8B50: B8 C4 80 00 00 00 00 00 0001 8B60: F8 69 80 00 00 00 00 00 0001 8B70: 74 63 80 00 00 00 00 00 0001 8B80: 80 E5 7F 00 00 00 00 00 bad: 0001 8B50: B8 D4 80 00 00 00 00 00 0001 8B60: F8 79 80 00 00 00 00 00 0001 8B70: 74 73 80 00 00 00 00 00 0001 8B80: 80 F5 7F 00 00 00 00 00 After patching those 4 bytes I got ATF and U-Boot proper running so I'd consider that flash.bin fixed. Can anybody tell me what we have in those two locations? Best regards Alex
Re: [REGRESSION] imx8mm_evk: FSPI build broken by 37e50627e
Fixing the U-Boot list address. On Tue, Mar 31, 2026 at 8:47 AM Fabio Estevam wrote: > > Adding Peng and Ye Li in case they could take a look. > > On Tue, Mar 31, 2026 at 6:24 AM Alexander Koch wrote: > > > > > > > > Is it possible that binman patched some blob offset (maybe for the DRAM > > > blobs) at the wrong offset due to the extra header ? > > > > I'm afraid it's not that easy. After a good amount of juggling around with > > hex > > editors here are my findings: > > > > First of all, we can ignore the error message regarding 'fspi_header.bin' > > for > > now, that's definitely a different bug (the first `make` will generate a > > 'flash.bin' without the header and the second one will add it in without > > breaking anything else). > > > > Now I have compared the layout of 'flash.bin' from the last good commit > > (6509e007) to the one from the first bad commit (37e50627) and unfortunately > > they both look structurally identical: > > > > Good: > > - FSPI header at offset 0x00 > >(from 'fspi_header.bin', 448 Bytes) > > - SPL blob = SPL+DDR-FW at offset 0x1000 > >(from 'spl.bin', 188288 Bytes) > > - FIT blob = U-Boot+ATF+DTB at offset 0x58c00 > >(from 'u-boot.itb', 729528 Bytes) > > > > Bad: > > - FSPI header at offset 0x00 > >(from 'fspi_header.bin', 448 Bytes) > > - SPL blob = SPL+DDR-FW at offset 0x1000 > >(from 'u-boot-spl-mkimage.bin', 185216 Bytes) > > - FIT blob = U-Boot+ATF+DTB at offset 0x58c00 > >(from 'section.fit.fit', 729320 Bytes) > > > > So it seems binman is still right regarding the top-level structure of the > > image. > > > > As I am not even seeing output from the SPL with the bad build I then had a > > deeper look at the SPL blobs. > > > > Both do have the DDR firmware at identical offsets: > > > > - 0x1c5c0: lpddr4_pmu_train_1d_imem.bin > > - 0x243b4: lpddr4_pmu_train_1d_dmem.bin > > - 0x24a38: lpddr4_pmu_train_2d_imem.bin > > - 0x2a4f8: lpddr4_pmu_train_2d_dmem.bin > > > > Scrolling through the binary diff I'd say it's mostly build timestamps and > > version strings that make up the difference. The 3072 Bytes that the > > working SPL > > blob is larger are all 0x00 again. > > > > My last idea was trying to inject the SPL blob from the working build into > > 'flash.bin' from the broken build, to confirm it really is the SPL blob > > itself > > that is causing troubles. > > > > Lo and behold, that patched 'flash.bin' actually did boot and it did not > > only > > run the injected SPL part but also proper U-Boot as well as the ATF: > > > > > > > > U-Boot SPL 2024.07-rc1-00155-gef8cc500d15 (Mar 30 2026 - 19:18:36 +0200) > > No pmic > > SEC0: RNG instantiated > > WDT: Started watchdog@3028 with servicing every 1000ms (60s timeout) > > Trying to boot from NOR > > NOTICE: BL31: v2.6(release):lf-6.1.1-1.0.0-1-g874e9578a > > NOTICE: BL31: Built : 14:40:27, Jul 15 2024 > > > > > > U-Boot 2024.07-rc1-00156-gb550ac40df5 (Mar 30 2026 - 19:32:55 +0200) > > > > CPU: Freescale i.MX8MMD rev1.0 at 1200 MHz > > Reset cause: POR > > Model: FSL i.MX8MM EVK board > > DRAM: 2 GiB > > Core: 78 devices, 22 uclasses, devicetree: separate > > WDT: Started watchdog@3028 with servicing every 1000ms (60s timeout) > > MMC: FSL_SDHC: 1, FSL_SDHC: 2 > > Loading Environment from MMC... MMC: no card present > > *** Warning - No block device, using default environment > > > > > > (please ignore the commit hashes, I had to cherry-pick a pylibfdt fix to > > make > > the build run on my host system) > > > > > > So, any idea what might break the SPL blob itself in 37e50627e? > > > > > > Best regards, > > > > Alex
