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

[Adam Ford]

On Sun, Nov 10, 2024 at 6:49 PM Marek Vasut <marex at denx.de> wrote:
>
> 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?

I reset my branch to to U-Boot master from wedneday a7a96a37cbd8
"Merge https://source.denx.de/u-boot/custodians/u-boot-riscv")

I verified the FCFB header is present.  Unfortunately, when I burn the
FSPI on my 8MM and attempt to boot, nothing happens.

However, I changed the "nxp,boot-from" parameter to "fspi" and it booted!

U-Boot SPL 2025.01-rc1-00168-ga7a96a37cbd8-dirty (Nov 10 2024 - 19:27:21 -0600)
WDT:   Started watchdog at 30280000 with servicing every 1000ms (60s timeout)
SEC0:  RNG instantiated
Trying to boot from NOR
<snip>

I looked at your patch, and noticed your FIXME. Once we get the code
working, we'll likely need a way to pass the header offset, because
it's different between Mini (0x0) and Nano / Plus (0x400).

I'd like to suggest we #iifndef the section filename where "flash.bin"
currently sits, and remove it if we are building for flexspi.  This
way we get what you originally requested, which is a single binary.
I have attached my diff file, so you can see my proposal. I am happy
to test either Mini or Nano, but I am traveling this week starting
Wednesday afternoon (US Central time) until Sunday night, so I won't
be able to test in that window.

Let me know how/if you want to proceed.

Thanks for looking into this.

adam
>
> 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: aford.diff
Type: text/x-patch
Size: 7407 bytes
Desc: not available
URL: <https://lists.denx.de/pipermail/u-boot/attachments/20241110/daa9b798/attachment.bin>