[REGRESSION] imx8mm_evk: FSPI build broken by 37e50627e

[Fabio Estevam]

Fixing the U-Boot list address.

On Tue, Mar 31, 2026 at 8:47 AM Fabio Estevam <festevam at gmail.com> wrote:
>
> Adding Peng and Ye Li in case they could take a look.
>
> On Tue, Mar 31, 2026 at 6:24 AM Alexander Koch <akoch at initse.com> 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 at 30280000 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 at 30280000 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