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

[Marek Vasut]

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 
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.