diff options
| author | Marek Vasut <[email protected]> | 2026-05-30 19:08:24 +0200 |
|---|---|---|
| committer | Fabio Estevam <[email protected]> | 2026-06-04 17:26:40 -0300 |
| commit | 822a98588d16e5542b4e4d9d23c19a8ee7e93040 (patch) | |
| tree | 6c9a7df086c6a69842d223aa0d7fbdeb63e9d06b /include/dm | |
| parent | cdb9e79056dcc94440202845a75a31e4e40cc3a2 (diff) | |
binman: imx8mimage: Handle nxp,boot-from = "fspi"
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 <[email protected]>
Diffstat (limited to 'include/dm')
0 files changed, 0 insertions, 0 deletions
