On Sun, Nov 10, 2024 at 10:42 AM Marek Vasut marex@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@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.