Hi Marek, Adam > On 11/7/24 2:55 AM, Adam Ford wrote: > > On Tue, Apr 23, 2024 at 1:33 PM Marek Vasut <[email protected]> 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 <[email protected]> > >> --- > > > > 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-mc...@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: [email protected]
pgpbEpPqU9ERl.pgp
Description: OpenPGP digital signature
