Re: [PATCH v2 1/3] binman: imx8mimage: Handle nxp,boot-from = "fspi"

[Marek Vasut <marex@nabladev.com>]

On 5/28/26 2:43 PM, Fabio Estevam wrote:
> Hi Marek,
> 
> On Mon, May 25, 2026 at 8:52 PM Marek Vasut <marex@nabladev.com> wrote:
>>
>> Boot from FSPI requires additional 448 Byte long header, with U-Boot SPL
>> starting at offset 0x1000. Currently, both i.MX8MM and i.MX8MN attempt
>> to generate this header using fspi_conf_block with filename pointing at
>> CONFIG_FSPI_CONF_FILE file. This does not work, for two reasons.
>>
>> First, the CONFIG_FSPI_CONF_FILE is generated by mkimage -T imx8mimage
>> and may not be available yet when the fspi_conf_block is evaluated. That
>> leads to a race condition where highly parallel builds fail to find the
>> CONFIG_FSPI_CONF_FILE, which is usually called fspi_header.bin, on first
>> build attempt.
>>
>> Second, binman gets confused and patches incorrect offset of DDR PHY
>> firmware blobs into U-Boot SPL, the offset is incremented by exactly
>> 0x1000 which is the size of fspi_conf_block.
>>
>> Fix both problems at once, make imx8mimage handle the generated FSPI
>> header and prepend it in front of the imx8mimage processed data. This
>> way, the race condition is solved, because the data generated by the
>> imx8mimage are surely combined only after mkimage -T imx8mimage ran.
>> The binman offset calculation is also solved, because there is no
>> fspi_conf_block node in the DT anymore.
>>
>> Signed-off-by: Marek Vasut <marex@nabladev.com>
> 
> Is this series 2026.07 material, or can it wait until 2026.10?
> 
> Alexander, if possible, please test this series and reply with your
> Tested-by tag.
This should have been 2024.07 material, but I had no hardware to debug 
this on, so 2026.07 will do.