7.24.NXP i.MX 8M Series

The i.MX 8M family of applications processors based on Arm Corte-A53 and Cortex-M4cores provide high-performance computing, power efficiency, enhanced systemreliability and embedded security needed to drive the growth of fast-growingedge node computing, streaming multimedia, and machine learning applications.

imx8mq is dropped in TF-A CI build due to the small OCRAM size, but still activelymaintained in NXP official release.

7.24.1.Boot Sequence

Bootrom –> SPL –> BL31 –> BL33(u-boot) –> Linux kernel

7.24.2.How to build

7.24.2.1.Build Procedure

  • Prepare AARCH64 toolchain.

  • Build spl and u-boot firstly, and get binary images: u-boot-spl.bin,u-boot-nodtb.bin and dtb for the target board.

  • Build TF-A

    Build bl31:

    CROSS_COMPILE=aarch64-linux-gnu-makePLAT=<Target_SoC>bl31

    Target_SoC should be “imx8mq” for i.MX8MQ SoC.Target_SoC should be “imx8mm” for i.MX8MM SoC.Target_SoC should be “imx8mn” for i.MX8MN SoC.Target_SoC should be “imx8mp” for i.MX8MP SoC.

7.24.2.2.Deploy TF-A Images

TF-A binary(bl31.bin), u-boot-spl.bin u-boot-nodtb.bin and dtb are combinedtogether to generate a binary file called flash.bin, the imx-mkimage tool isused to generate flash.bin, and flash.bin needs to be flashed into SD cardwith certain offset for BOOT ROM. the u-boot and imx-mkimage will be upstreamedsoon, this doc will be updated once they are ready, and the link will be posted.

7.24.3.TBBR Boot Sequence

When setting NEED_BL2=1 on imx8mm. We support an alternative way ofboot sequence to support TBBR.

Bootrom –> SPL –> BL2 –> BL31 –> BL33(u-boot with UEFI) –> grub

This helps us to fulfill the SystemReady EBBR standard.BL2 will be in the FIT image and SPL will verify it.All of the BL3x will be put in the FIP image. BL2 will verify them.In U-boot we turn on the UEFI secure boot features so it can verifygrub. And we use grub to verify linux kernel.

7.24.4.Measured Boot

When setting MEASURED_BOOT=1 on imx8mm we can let TF-A generate event logswith a DTB overlay. The overlay will be put at PLAT_IMX8M_DTO_BASE withmaximum size PLAT_IMX8M_DTO_MAX_SIZE. Then in U-boot we can apply the DTBoverlay and let U-boot to parse the event log and update the PCRs.

7.24.5.High Assurance Boot (HABv4)

All actively maintained platforms have a support for High AssuranceBoot (HABv4), which is implemented via ROM Vector Table (RVT) API toextend the Root-of-Trust beyond the SPL. Those calls are done via SMCand are executed in EL3, with results returned back to original caller.

7.24.5.1.Note on DRAM Memory Mapping

There is a special case of mapping the DRAM: entire DRAM available on theplatform is mapped into the EL3 with MT_RW attributes.

Mapping the entire DRAM allows the usage of 2MB block mapping in Level-2Translation Table entries, which use less Page Table Entries (PTEs). IfLevel-3 PTE mapping is used instead then additional PTEs would be required,which leads to the increase of translation table size.

Due to the fact that the size of SRAM is limited on some platforms in thefamily it should rather be avoided creating additional Level-3 mapping andintroduce more PTEs, hence the implementation uses Level-2 mapping whichmaps entire DRAM space.

The reason for the MT_RW attribute mapping scheme is the fact that the SMCAPI to get the status and events is called from NS world passing destinationpointers which are located in DRAM. Mapping DRAM without MT_RW permissionscauses those locations not to be filled, which in turn causing EL1&0 softwarenot to receive replies.

Therefore, DRAM mapping is done with MT_RW attributes, as it is required fordata exchange between EL3 and EL1&0 software.

7.24.5.2.Reference Documentation

Details on HABv4 usage and implementation could be found in following documents:

  • AN4581: “i.MX Secure Boot on HABv4 Supported Devices”, Rev. 4 - June 2020

  • AN12263: “HABv4 RVT Guidelines and Recommendations”, Rev. 1 - 06/2020

  • “HABv4 API Reference Manual”. This document in the part of NXP Code Signing Tool (CST) distribution.