Re: [PATCH v2] binman: nxp_imx8mcst: Handle FCFB header during SPI NOR boot

Hi Marek,

On 2026-07-21T02:09:14, Marek Vasut <[email protected]> wrote:
> binman: nxp_imx8mcst: Handle FCFB header during SPI NOR boot
>
> In case the image that is wrapped in the nxp_imx8mcst already contains
> an FCFB header which is mandatory for SPI NOR boot, then the IVT is at
> offset 0x1000 instead of offset 0x0, but the whole image including the
> FCFB header must be signed to prevent attacker from tampering with any
> of the headers. Add the FCFB handling.
>
> Signed-off-by: Marek Vasut <[email protected]>
>
> tools/binman/etype/nxp_imx8mcst.py | 15 +++++++++++++--
>  1 file changed, 13 insertions(+), 2 deletions(-)

> diff --git a/tools/binman/etype/nxp_imx8mcst.py b/tools/binman/etype/nxp_imx8mcst.py
> @@ -101,6 +102,9 @@ class Entry_nxp_imx8mcst(Entry_mkimage):
>          # - If it is mkimage'd imx8mimage, then extract to be signed data size
>          #   from imx8mimage header, and calculate CSF blob offset right past
>          #   the SPL from this information.
> +        # - If it is mkimage'd imx8mimage wrapped in FCFB, then extract to be
> +        #   signed data size from imx8mimage header past the FCFB header, and
> +        #   calculate CSF blob offset right past the SPL from this information.

Thanks for updating the block comment.

> diff --git a/tools/binman/etype/nxp_imx8mcst.py b/tools/binman/etype/nxp_imx8mcst.py
> @@ -114,6 +118,13 @@ class Entry_nxp_imx8mcst(Entry_mkimage):
> +        elif signtype == MAGIC_NXP_IMX_FCFB: # SPL/imx8mimage with FCFB
> +            # Sign the payload including FCFB and imx8mimage headers
> +            # (extra 0x1000 and 0x40 bytes before the payload)
> +            signbase -= 0x1040
> +            signsize = struct.unpack('<I', data[4120:4124])[0] - signbase
> +            # Remove mkimage generated padding from the end of data
> +            data = data[:signsize]

This part is not tested:

tools/binman/etype/nxp_imx8mcst.py                         94      3    97%

Also 4120 is still an unexplained decimal literal rather than the FCFB
offset plus the IVT csf-pointer offset. If you don't want to change
that, perhaps add a comment as to where 4120 comes from?

Regards,
Simon