On 11/7/24 2:55 AM, Adam Ford wrote:
On Tue, Apr 23, 2024 at 1:33 PM Marek Vasut <ma...@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 <ma...@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)
