Re: [PATCH 4/5] doc: imx: ahab: add i.MX93 secure boot guide

Hi Jérémie,

On 2026-08-14T17:07:09, Jérémie Dautheribes
<[email protected]> wrote:
> doc: imx: ahab: add i.MX93 secure boot guide
>
> Add a step-by-step guide describing how to securely boot an i.MX93
> image using AHAB.
>
> This guide is largely based on the following documents:
>   - doc/imx/ahab/guides/mx8ulp_9x_secure_boot.txt, from uboot-imx
>   (lf_v2026.04), originally written by Utkarsh Gupta
>   - doc/imx/habv4/guides/mx8m_spl_secure_boot.txt, from this tree,
>   originally written by Marek Vasut
>
> Signed-off-by: Jérémie Dautheribes (Schneider Electric) <[email protected]>
>
> doc/imx/ahab/guides/mx93_secure_boot.txt | 269 +++++++++++++++++++++++++++++++
>  1 file changed, 269 insertions(+)

> +Warning: Please ensure your sample is in OEM Open state, OEM SRK hash
> +has been fused, and you are able to boot a signed image successfully
> +without any SECO events reported. If not, your sample will be

SECO does not exist on i.MX93 - the security subsystem is ELE. This is
a leftover from the mx8ulp_9x guide; please change to 'AHAB events'
(or 'ELE events') to match the earlier ahab_status step.

> +i.MX93 boot image. It is assumed that the reader is familiar with basic
> +AHAB concepts and with the PKI tree generation. Details about AHAB can be
> +found in the introduction_ahab.txt document and in processors Security
> +Reference Manual Document (SRM). The i.MX93 signing procedure is

Minor: 'processors Security Reference Manual Document' reads awkwardly
- please make it 'the processor Security Reference Manual (SRM)' and
drop the redundant 'Document'.

> +all the commands that the AHAB executes during the secure boot. These
> +commands instruct the AHAB code on which memory areas of the image to
> +authenticate, which keys to install, use and etc. The CSF is generated

'install, use and etc.' is not quite English - please rephrase, e.g.
'which keys to install and use, and so on'.

> +| DT property        | Variable    | Description                                                  |
> ++====================+=============+==============================================================+
> +| nxp,srk-table      | SRK_TABLE   | full path to SRK_1_2_3_4_table.bin                           |
> ++--------------------+-------------+--------------------------------------------------------------+
> +| nxp,srk-crt        | SRK_KEY     | full path to the SRK Key SRK1_sha384_secp384r1_v3_usr_crt.pem|

Just to clarify for the reader - this points at the SRK certificate
(_crt.pem), not the private key. The DT property is nxp,srk-crt but
the env var is SRK_KEY, which is confusing on its own; please spell
out in the Description column that it is the SRK certificate. Also,
the matching _key.pem file must sit next to the cert for CST to find
it - worth stating explicitly, since there is no knob to point at it
separately.

> +See the introduction_ahab.txt document for the PKI tree generation
> +procedure (ahab_pki_tree tool) and for the SRK Table generation
> +(srktool, use the SHA256 variant for i.MX93).

Just to check - the default key material the etype uses is
'sha384_secp384r1' (see KEY_NAME in nxp_imx93cst.py), so telling the
reader to use the SHA256 srktool variant looks inconsistent with what
CST is then asked to sign with. Can you confirm which srktool hash
flag matches the shipped default, and align this sentence with it?

Regards,
Simon