The HABv4 library locks certain SoC security-related features on closed devices when exiting the internal boot ROM. The features can be unlocked with "Unlock" commands inserted into the CSF signature, enabling users access to those features after boot.
HABv4 locks the following OCOTP features by default in closed devices. Access to one of these features requires the CSF contain its specific "Unlock" command.
The i.MX7ULP has two independent HABv4 libraries running in each boot core, the unlock command procedure may vary according to the boot mode:
Boot mode | Instructions |
---|---|
Single boot mode | Refer to this document |
Dual boot mode | Add unlock command in both CSF files (Cortex A7- CA7 and Cortex M4 -CM4) |
Low power boot mode | Add unlock command in the M4 CSF file. |
Table 1. OCOTP Unlock procedure according to boot mode
In single boot mode (CA7 core only) the CM4 image is authenticated by CA7 HAB library, hence the Unlock command can be only added in CA7 CSF. Even in single boot mode the CM4 ROM still executes as described below.
1 - CM4 is the first core to run after POR (regardless of boot mode configuration).
2 - CM4 ROM performs minimal system resource setup and retrieves the boot configuration.
3 - If single boot mode configured, the CM4 ROM enables the CA7 and begins polling the SIM0_DGO_GP7 register.
4 - CA7 ROM loads and authenticates its software image (U-Boot + CM4 SW) from the configured boot media (eMMC/SD).
5 - CA7 SW loads the CM4 SW to internal memory and writes the CM4 entry point address to the SIM0_DGO_GP7 register.
6 - CM4 ROM exits the polling routine and uses the supplied entry point address to continue with the CM4 boot process.
In single boot mode, the CM4 ROM does not authenticate its own image. The CA7 ROM is expected to authenticate the CM4 SW image. Therefore the CM4 ROM does not process a CSF signature and is never exposed to any "Unlock" commands. This causes the CM4 ROM to always apply the default locks prior to exiting (after the entry point is supplied by the CA7 SW). This behavior will cause features exposed by an "Unlock" command in the boot image's CSF to be locked when the CM4 is released by the CA7 SW.
Users can check OTP Controller Sticky Bit Register (0x410a6050) from U-Boot terminal to confirm SRK Revoke and/or Field Return fuses are locked:
Fig 1. OTP Controller Sticky Bit Register
=> md 0x410a6050 1
410a6050: 0000001e
All i.MX 7ULP B0 and B1 silicon revisions booting in single boot mode are impacted by this issue. Users should refer to workarounds below.
Our recommendation is to program all necessary fuses prior to setting CM4 entry point in SIM0_DGO_GP7 register. U-Boot is resuming CM4 ROM execution in mcore_early_load_and_boot() function in soc.c:
int mcore_early_load_and_boot(void)
{
u32 *src_addr = (u32 *)&__firmware_image_start;
u32 *dest_addr = (u32 *)TCML_BASE; /*TCML*/
u32 image_size = SZ_128K + SZ_64K; /* 192 KB*/
u32 pc = 0, tag = 0;
memcpy(dest_addr, src_addr, image_size);
/* Set GP register to tell the M4 rom the image entry */
/* We assume the M4 image has IVT head and padding which
* should be same as the one programmed into QSPI flash
*/
tag = *(dest_addr + 1024);
if (tag != 0x402000d1 && tag !=0x412000d1)
return -1;
pc = *(dest_addr + 1025);
writel(pc, SIM0_RBASE + 0x70); /*GP7*/
return 0;
}
Users can modify code above and call fuse_prog() function available in mxc_ocotp.c:
int fuse_prog(u32 bank, u32 word, u32 val)
This workaround is recommended for use cases that require the CM4 core image included in the boot image.
Alternatively, users can disable the CM4 boot by disabling the following U-Boot configuration. In this way users can use U-Boot fuse program as usual:
- Defconfig:
CONFIG_IMX_M4_BIND = N
- Kconfig:
ARM architecture -> Bind ULP M4 image to final u-boot
Please note that CM4 may be needed by Linux Kernel to control power features. Users planning to use UUU to program SRK Revocation fuses must refer to this workaround.
This issue does not compromise the i.MX security.