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

[Marek Vasut]

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)