On Sun, Nov 10, 2024 at 10:42 AM Marek Vasut <[email protected]> wrote: > > On 11/10/24 2:15 PM, Adam Ford wrote: > > On Sat, Nov 9, 2024 at 7:34 PM Marek Vasut <[email protected]> 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.
