[PATCH 1/4] arm64: dts: imx8mn: Fix FSPI booting

[Adam Ford]

On Sun, Nov 10, 2024 at 10:42 AM Marek Vasut <marex at denx.de> wrote:
>
> On 11/10/24 2:15 PM, Adam Ford wrote:
> > On Sat, Nov 9, 2024 at 7:34 PM Marek Vasut <marex at denx.de> wrote:
> >>
> >> On 11/9/24 9:06 PM, Adam Ford wrote:
> >>> When FSPI_CONF_HEADER is set, the binary needs to be built such
> >>> that there is a configuration file located at 0x400 and the start
> >>> of the file that would normally be flash.bin starts at 0x1000.
> >>> This used to be done properly until the device tree was converted to
> >>> nxp_imx8mimage.
> >>>
> >>> Building these with the offsets built into the binman device tree
> >>> changes impacts how the actual image is built and the locations
> >>> of the various blobs aren't fetched properly and booting fails.
> >>>
> >>> Fix this by building a standard image as if it were to boot from
> >>> eMMC or SD, then use that image as the input for a second image
> >>
> >> This seems like a workaround for some broken offset calculation in binman ?
> >
> > This used to work until it was migrated to nxp_imx8mimage.
> > The blobs appear to be at the proper offsets, but the contents of
> > what's stored at those offsets are not the same.
>
> I know, this is what Lukasz reported too.
>
> > If you're going to claim there is a bug somewhere, I would argue that
> > it's somewhere i nxp_imx8mimage
>
> I agree with that claim. Well, by extension, the problem might also be
> in binman itself.
>
> >.  However, if you look at this series,
> > the added benefit is the ability for Nano to be able to build both a
> > SD/eMMC image and FSPI images with one config which allows for the
> > elimination of extra defconfig files.  I am guessing Plus would have a
> > similar benefit since they have similar bootloaders.
> This I do not agree with. If the intent is to generate two images, then
> there should be two full binman descriptors, one for each image (one for
> flash-plain.bin and one for flash-fspi.bin or some such naming).
>
> Can you try and fix the FSPI generation first, so an FSPI compatible

I am not a python programmer, and I couldn't determine what was going on.

> flash.bin can be generated using binman only, without the dependency on
> processing non-FSPI compatible flash.bin ? I think the intention of
> binman was to replace all that ad-hoc pre/postprocessing of blobs.