rt1189 Boot Flow 1. As shown in the figure, does the "Authenticate Image" process verify the hash value during the SHA-512 hashing stage? 2. If I set the hash value, will the BootROM verify the image integrity? And if the BootROM verification fails, will it enter recovery mode? Re: rt1189 Boot Flow 1. Is hash verification enabled only when the signature authentication feature is enabled? How can hash verification be enabled independently? How can the device be transitioned into the OEM_CLOSED lifecycle state? 2. I will enable the Recovery Boot fuse. 3. My goal is to use an unencrypted image. The Boot ROM should calculate and verify the image hash. If the hash verification fails, the Boot ROM should enter the recovery boot flow and boot the recovery image from the LPSPI NOR Flash. Re: rt1189 Boot Flow Hi @yanyanwang ,
A1: Yes. RT1180 uses AHAB with two authentication layers:
Signature layer: ECDSA (SHA-256 / SHA-384) verifies the Container header and image array entry (which stores each image's Hash).
Hash layer: The ROM re-computes the digest of the loaded image body and compares it against the Hash stored in the image array entry.
The SHA hashing stage in your figure is exactly this mandatory integrity check, which does verify the hash value.
A2:The ROM always computes and compares the hash, but whether a failure is enforced depends on the device life cycle: the out-of-fab default is the Open configuration, where authentication runs but all authentication errors are ignored and the image still executes. Only after the device is moved to OEM_CLOSED will a hash mismatch actually block boot.
Whether it enters recovery depends on the Recovery Boot fuse. if enabled, a primary-boot authentication failure triggers a re-load and re-authentication from the recovery device; if not enabled, the flow falls through to Serial Downloader / Fatal Mode / reset loop.
Best regards, Gavin
Re: rt1189 Boot Flow As shown in the figure above, if I only sign the image and do not encrypt it, will it be able to go through the bootrom verification flow? Additionally, with oem_close enabled, will it still be able to enter the bootrom verification flow? Re: rt1189 Boot Flow
Please find answers to your two questions below:
1. Can a signed-only (non-encrypted) image go through the BootROM verification flow? Yes. In the RT1180 AHAB, signing (authentication) is the mandatory part of secure boot, ensuring image authenticity and integrity, while encryption (OTFAD/IEE) is an independent, optional anti-cloning feature and is NOT a prerequisite for verification. Therefore, a signed-only image will go through the full AHAB signature verification flow normally, this is also the standard approach in NXP's official SPSDK rt118x_secure_boot example.
2. With oem_close (OEM_CLOSED) enabled, will it still enter the verification flow? Yes, and verification becomes mandatory.
Recommendation: Before performing oem_close, please program the signed image in the OEM_OPEN state first and confirm it boots successfully with no ELE events, then close the device (SRKH is irreversible once fused) to avoid bricking the part.
(Please refer to: i.MX RT1180 Security Reference Manual. After signing the NDA through your company account, submit a request to the online technic sales representative.)
Re: rt1189 Boot Flow Using the two demos, multicore_trigger and cm7_helloworld, I did not enable ECC for the CM7 ITCM. I used the SPT tool to merge the CM33 image and the CM7 image, which is intended to run from memory, into a single image, and then programmed the merged image into NOR Flash through UART. However, the boot process failed. According to the manual, a container can contain up to 8 OEM image entries. In my test, I only included two images: one CM33 image and one CM7 image. CM7 ITCM ECC was not enabled. Neither the CM33 nor the CM7 image started. However, when I checked the container header, I found that only the CM33 image was present. The CM33 image itself can boot normally without any issues when used alone. I would like to understand why the CM7 image was not included or processed as expected, and whether the lack of CM7 ITCM ECC configuration affects how Boot ROM processes the CM7 image. Question 2: If I merge 8 CM7 images and 1 CM33 image into a single container, what will the Boot ROM do during the startup process? Since there is only one CM7 core, how does Boot ROM determine which CM7 image should be booted? If all 8 image entries are CM7 images, will Boot ROM load all 8 images, select only one image, or leave the selection to the CM33 application? How does Boot ROM identify and process multiple CM7 image entries in the same container? Is there a priority, image index, Core ID, load address, entry point, or another mechanism used to determine which CM7 image is executed? I would also like to understand the exact Boot ROM behavior when CM7 ITCM ECC is enabled and when it is not enabled. When CM7 ITCM ECC is enabled, does Boot ROM initialize the CM7 ITCM ECC memory, copy the CM7 image from NOR Flash into CM7 ITCM, and then release CM7 from reset? Or does Boot ROM only load the CM7 image, while the CM33 application is responsible for releasing CM7 from reset and starting it? When CM7 ITCM ECC is not enabled, what does Boot ROM do when it encounters a CM7 image whose load address is in CM7 ITCM? Does Boot ROM skip the CM7 image, fail to load it, leave CM7 in reset, or cause the entire container boot process to fail? In particular, I would like to clarify whether the following container is supported: Image 0: CM33 Image 1: CM7 Image 2: CM7 Image 3: CM7 Image 4: CM7 Image 5: CM7 Image 6: CM7 Image 7: CM7 Image 8: CM7 If it is supported, what exactly happens to these 8 CM7 images during Boot ROM startup, and which component is responsible for selecting the CM7 image that will actually execute? Finally, I would like to clarify whether the maximum of 8 OEM image entries means that the container can simply store 8 different images, or whether Boot ROM also provides a mechanism to select and boot a specific image for a given core.
View full article
