[PATCH 3/3] ARM: dts: imx: Convert i.MX8M flash.bin image generation to binman

[Lukasz Majewski]

Hi Marek, Adam

> On 11/7/24 2:55 AM, Adam Ford wrote:
> > On Tue, Apr 23, 2024 at 1:33 PM Marek Vasut <marex at denx.de> wrote:  
> >>
> >> Rework the flash.bin image generation such that it uses the new
> >> binman nxp_imx8mimage etype. This way, the flash.bin is assembled
> >> in correct order using plain binman, without any workarounds or
> >> sections assembled in special DT node order.
> >>
> >> Signed-off-by: Marek Vasut <marex at denx.de>
> >> ---  
> > 
> > This introduced a regression on the 8M Nano with
> > CONFIG_FSPI_CONF_HEADER set.  As is, the board doesn't appear to do
> > anything.
> > 
> > Looking at the binary blob that is generated, the offset for the SPL
> > phase is missing, so SPL starts at 0x5c0 instead of 0x1000, but
> > adding offset = <0x1000> isn't sufficient.
> > 
> > Adding the offset = <0x1000>  starts the SPL phase, but it hangs
> > right away and doesn't past the version message:
> > U-Boot SPL 2024.07-rc1-00155-g37e50627ef-dirty (Nov 06 2024 -
> > 19:16:52 -0600)
> > 
> > <hangs here>
> > 
> > I have only tested this on a Nano, but I think the issue would
> > likely affect Plus since their boot ROM is similar.  I currently
> > don't have a Mini in my possession right now, so I cannot verify
> > the behavior on it.  
> 
> I think Lukasz was able to reproduce it on Mini. I have a few Mini
> here, but none of them use FSPI.
> 
> iMX8MP never supported FSPI ?
> 
> >  From what I can tell, reverting this patch appears to restore boot
> > operation.   I don't know enough about the mkimage tool, but I have
> > tried changing  nxp,boot-from and that doesn't seem to fix it
> > either.
> > 
> > When I diff the binaries, it looks like a fairly significant about
> > of the values have changed, but the various magic numbers and offets
> > appear correct.  This makes me wonder if setting the offsets being
> > passed to mkimage are getting in the way.
> > 
> > If remove the references to  CONFIG_FSPI_CONF_HEADER in the device
> > tree, a regular image is built.  I then use dd to create a new file
> > which has the FSPI header at 0x400, and moves the beginning of the
> > rest of the image to 0x1000.  This process boots the board just
> > fine. This leads me to believe that something in the imx8 mkimage
> > tool is doing something different when fspi is enabled.  
> 
> [...]
> 
> > I'd like to rework the binman to build a standard flash.bin without
> > the Flexspi stuff, then create a second file like fspi.bin (or
> > something similar) which inserts the FSPI header at 0x400 and then
> > just places the entirely of flash.bin contents placed at 0x1000 in a
> > way that doesn't pass these offsets to imx8 mkimage tool.  
> 
> That looks like a workaround . It would be much better if binman
> would generate suitable flash.bin blob with FSPI header. Maybe the
> FSPI header needs to be generated by binman using yet another etype,
> and the SPL/U-Boot have to be positioned properly according to the
> binman node content in imx8mm-u-boot.dtsi ?
> 
> (I also have hard time with binman tool)

I've managed to nail down which offsets are shifted by 0x1000. The
"only" only problem is to add this "fix" to binman... :)

Please refer to below discussion/link:
https://lore.kernel.org/all/CAFLszTh65OkyXnG3L7XTJFK69EYdj4DZwYGxizu4877n-mCw-w@mail.gmail.com/T/


Best regards,

Lukasz Majewski

--

DENX Software Engineering GmbH,      Managing Director: Erika Unter
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-59 Fax: (+49)-8142-66989-80 Email: lukma at denx.de
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 488 bytes
Desc: OpenPGP digital signature
URL: <https://lists.denx.de/pipermail/u-boot/attachments/20241108/e9bc5bd3/attachment.sig>