[PATCH v2 1/3] binman: imx8mimage: Generate FSPI header in binman instead of mkimage

Simon Glass sjg at chromium.org
Thu Jul 2 13:13:58 CEST 2026


Hi Marek,

On 2026-06-30T08:40:46, Marek Vasut <marex at nabladev.com> wrote:
> binman: imx8mimage: Generate FSPI header in binman instead of mkimage
>
> Stop depending on the current mkimage method of generating the FSPI
> header, instead generate the FSPI header within binman itself. This
> is more flexible, as the FSPI header properties can be configured
> from within the board-specific DT instead of being hard-coded in
> mkimage at build time.
>
> Signed-off-by: Marek Vasut <marex at nabladev.com>
> Acked-by: Peng Fan <peng.fan at nxp.com>
>
> tools/binman/etype/nxp_imx8mimage.py               | 97 ++++++++++++++++++++--
>  tools/binman/ftest.py                              | 23 ++---
>  tools/binman/test/vendor/nxp_imx8m_fspi.dts        |  1 -
>  .../nxp_imx8m_fspi_fail_columnadresswidth.dts      | 19 +++++
>  ...fail.dts => nxp_imx8m_fspi_fail_devicetype.dts} |  3 +-
>  .../vendor/nxp_imx8m_fspi_fail_flashpadtype.dts    | 19 +++++
>  .../nxp_imx8m_fspi_fail_readsampleclksrc.dts       | 19 +++++
>  .../vendor/nxp_imx8m_fspi_fail_serialclkfreq.dts   | 19 +++++
>  tools/binman/test/vendor/nxp_imx8m_fspi_pass.dts   |  1 -
>  9 files changed, 179 insertions(+), 22 deletions(-)

> diff --git a/tools/binman/etype/nxp_imx8mimage.py b/tools/binman/etype/nxp_imx8mimage.py
> @@ -25,8 +25,26 @@ class Entry_nxp_imx8mimage(Entry_mkimage):
> +        - nxp,fspi-columnadresswidth - FSPI column address width

This misspells 'address'. It becomes part of the binman DT binding and
will be hard to change later, so please can you rename it to
nxp,fspi-columnaddresswidth (and the matching variable)?

> diff --git a/tools/binman/etype/nxp_imx8mimage.py b/tools/binman/etype/nxp_imx8mimage.py
> @@ -37,9 +55,30 @@ class Entry_nxp_imx8mimage(Entry_mkimage):
> +        if not self.fspi_columnadresswidth in [ 0, 3, 12, 13 ]:
> +            raise ValueError('nxp,fspi-columnadresswidth can be 0, 3, 12, 13 only.')

Please use self.Raise() rather than raise ValueError, as with other
etypes - it adds the node path so the user can see which image is at
fault. Also 'not in' reads better than 'not x in':

    if self.fspi_columnadresswidth not in [0, 3, 12, 13]:
        self.Raise('nxp,fspi-columnadresswidth can be 0, 3, 12, 13 only')

Same for the other four checks.

> diff --git a/tools/binman/etype/nxp_imx8mimage.py b/tools/binman/etype/nxp_imx8mimage.py
> @@ -59,10 +98,52 @@ class Entry_nxp_imx8mimage(Entry_mkimage):
> +                # 0x80 ... lookupTable
> +                spidata += struct.pack('<I', 0x0818040b)
> +                spidata += struct.pack('<I', 0x24043008)

Just to check, this LUT is a single-pad fast-read sequence, so should
we mention the fixed read command? E.g. if a board uses quad pads,
what will happen.

> diff --git a/tools/binman/etype/nxp_imx8mimage.py b/tools/binman/etype/nxp_imx8mimage.py
> @@ -59,10 +98,52 @@ class Entry_nxp_imx8mimage(Entry_mkimage):
> +                # 0x88..0xfff ... Padding (end of FSPI block is 0x1bf, align to 4k)
> +                spidata += tools.get_bytes(0, 0x1000 - 0xa8)

At this point len(spidata) is 0x88, not 0xa8, so the header comes out
as 0xfe0 bytes and the mkimage output starts at 0xfe0 instead of 0x1000
- 0x20 bytes short. Please use the actual length so this cannot go
stale:

    spidata += tools.get_bytes(0, 0x1000 - len(spidata))

> diff --git a/tools/binman/ftest.py b/tools/binman/ftest.py
> @@ -8101,17 +8101,18 @@ fdt         fdtmap                Extract the devicetree blob from the fdtmap
> +        self._DoTestFile('vendor/nxp_imx8m_fspi.dts')
> +        self._DoTestFile('vendor/nxp_imx8m_fspi_pass.dts')

Since binman now generates the header itself, please can you check the
output data in the test, e.g. verify the tag at offset 0 and that the
mkimage data starts at 0x1000? That would have caught the padding
problem above. Also please use assertIn() on str(e.exception) for each
failure case, so the test confirms the expected error rather than any
ValueError.

Regards,
Simon


More information about the U-Boot mailing list