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

[Marek Vasut]

On 11/10/24 6:21 PM, Adam Ford wrote:
> 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.
I am hoping Simon could offer some input here ...

Can you try the attached diff on MX8MM (use "git show -w" to view the 
diff better) ? It will generate two files, flash.bin and flash-fspi.bin 
, the later should have the fspi header and maybe even correct offsets?

Applies on top of 56accc56b9aa ("bios_emulator: fix first argument of 
pci_{read,write}_config_* function calls") .

I noticed that there is some dependency issue where fspi_header.bin may 
not be generated yet when binman is triggered -- that needs to be fixed. 
You can detect the failure by running 'hexdump -C flash-fspi.bin | head' 
, if there is no FCFB header then this failure occurred. The easiest way 
to work around this is to run 'rm flash.bin ; make flash.bin'. The real 
fix is likely a matter of some Makefile tweak.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: fspi.diff
Type: text/x-patch
Size: 7317 bytes
Desc: not available
URL: <https://lists.denx.de/pipermail/u-boot/attachments/20241111/f45243a2/attachment.bin>