Paul Beesley | f3653a6 | 2019-05-22 11:22:44 +0100 | [diff] [blame] | 1 | NXP i.MX 8M Series |
| 2 | ================== |
Bai Ping | 06e325e | 2018-10-28 00:12:34 +0800 | [diff] [blame] | 3 | |
| 4 | The i.MX 8M family of applications processors based on Arm Corte-A53 and Cortex-M4 |
| 5 | cores provide high-performance computing, power efficiency, enhanced system |
| 6 | reliability and embedded security needed to drive the growth of fast-growing |
| 7 | edge node computing, streaming multimedia, and machine learning applications. |
| 8 | |
Jacky Bai | 9807451 | 2021-06-07 10:11:04 +0800 | [diff] [blame] | 9 | imx8mq is dropped in TF-A CI build due to the small OCRAM size, but still actively |
| 10 | maintained in NXP official release. |
| 11 | |
Bai Ping | 06e325e | 2018-10-28 00:12:34 +0800 | [diff] [blame] | 12 | Boot Sequence |
Paul Beesley | f3653a6 | 2019-05-22 11:22:44 +0100 | [diff] [blame] | 13 | ------------- |
Bai Ping | 06e325e | 2018-10-28 00:12:34 +0800 | [diff] [blame] | 14 | |
| 15 | Bootrom --> SPL --> BL31 --> BL33(u-boot) --> Linux kernel |
| 16 | |
| 17 | How to build |
Paul Beesley | f3653a6 | 2019-05-22 11:22:44 +0100 | [diff] [blame] | 18 | ------------ |
Bai Ping | 06e325e | 2018-10-28 00:12:34 +0800 | [diff] [blame] | 19 | |
| 20 | Build Procedure |
Paul Beesley | f3653a6 | 2019-05-22 11:22:44 +0100 | [diff] [blame] | 21 | ~~~~~~~~~~~~~~~ |
Bai Ping | 06e325e | 2018-10-28 00:12:34 +0800 | [diff] [blame] | 22 | |
| 23 | - Prepare AARCH64 toolchain. |
| 24 | |
| 25 | - Build spl and u-boot firstly, and get binary images: u-boot-spl.bin, |
| 26 | u-boot-nodtb.bin and dtb for the target board. |
| 27 | |
| 28 | - Build TF-A |
| 29 | |
| 30 | Build bl31: |
| 31 | |
| 32 | .. code:: shell |
| 33 | |
Mark Dykes | ef3a456 | 2020-01-08 20:37:18 +0000 | [diff] [blame] | 34 | CROSS_COMPILE=aarch64-linux-gnu- make PLAT=<Target_SoC> bl31 |
Bai Ping | 06e325e | 2018-10-28 00:12:34 +0800 | [diff] [blame] | 35 | |
| 36 | Target_SoC should be "imx8mq" for i.MX8MQ SoC. |
Jacky Bai | a617700 | 2019-03-06 17:15:06 +0800 | [diff] [blame] | 37 | Target_SoC should be "imx8mm" for i.MX8MM SoC. |
Jacky Bai | 9bd2f84 | 2019-11-28 13:16:33 +0800 | [diff] [blame] | 38 | Target_SoC should be "imx8mn" for i.MX8MN SoC. |
Jacky Bai | 07ed02c | 2020-06-03 14:28:45 +0800 | [diff] [blame] | 39 | Target_SoC should be "imx8mp" for i.MX8MP SoC. |
Bai Ping | 06e325e | 2018-10-28 00:12:34 +0800 | [diff] [blame] | 40 | |
| 41 | Deploy TF-A Images |
Paul Beesley | f3653a6 | 2019-05-22 11:22:44 +0100 | [diff] [blame] | 42 | ~~~~~~~~~~~~~~~~~~ |
Bai Ping | 06e325e | 2018-10-28 00:12:34 +0800 | [diff] [blame] | 43 | |
| 44 | TF-A binary(bl31.bin), u-boot-spl.bin u-boot-nodtb.bin and dtb are combined |
| 45 | together to generate a binary file called flash.bin, the imx-mkimage tool is |
| 46 | used to generate flash.bin, and flash.bin needs to be flashed into SD card |
| 47 | with certain offset for BOOT ROM. the u-boot and imx-mkimage will be upstreamed |
| 48 | soon, this doc will be updated once they are ready, and the link will be posted. |
Ying-Chun Liu (PaulLiu) | 234c271 | 2020-12-22 02:56:00 +0800 | [diff] [blame] | 49 | |
| 50 | TBBR Boot Sequence |
| 51 | ------------------ |
| 52 | |
| 53 | When setting NEED_BL2=1 on imx8mm. We support an alternative way of |
| 54 | boot sequence to support TBBR. |
| 55 | |
| 56 | Bootrom --> SPL --> BL2 --> BL31 --> BL33(u-boot with UEFI) --> grub |
| 57 | |
| 58 | This helps us to fulfill the SystemReady EBBR standard. |
| 59 | BL2 will be in the FIT image and SPL will verify it. |
| 60 | All of the BL3x will be put in the FIP image. BL2 will verify them. |
| 61 | In U-boot we turn on the UEFI secure boot features so it can verify |
| 62 | grub. And we use grub to verify linux kernel. |
Ying-Chun Liu (PaulLiu) | da039c8 | 2021-11-15 16:13:10 +0800 | [diff] [blame] | 63 | |
| 64 | Measured Boot |
| 65 | ------------- |
| 66 | |
| 67 | When setting MEASURED_BOOT=1 on imx8mm we can let TF-A generate event logs |
| 68 | with a DTB overlay. The overlay will be put at PLAT_IMX8M_DTO_BASE with |
| 69 | maximum size PLAT_IMX8M_DTO_MAX_SIZE. Then in U-boot we can apply the DTB |
| 70 | overlay and let U-boot to parse the event log and update the PCRs. |
Andrey Zhizhikin | 916ac60 | 2022-09-26 22:51:47 +0200 | [diff] [blame] | 71 | |
| 72 | High Assurance Boot (HABv4) |
| 73 | --------------------------- |
| 74 | |
| 75 | All actively maintained platforms have a support for High Assurance |
| 76 | Boot (HABv4), which is implemented via ROM Vector Table (RVT) API to |
| 77 | extend the Root-of-Trust beyond the SPL. Those calls are done via SMC |
| 78 | and are executed in EL3, with results returned back to original caller. |
| 79 | |
| 80 | Note on DRAM Memory Mapping |
| 81 | ~~~~~~~~~~~~~~~~~~~~~~~~~~~ |
| 82 | |
| 83 | There is a special case of mapping the DRAM: entire DRAM available on the |
| 84 | platform is mapped into the EL3 with MT_RW attributes. |
| 85 | |
| 86 | Mapping the entire DRAM allows the usage of 2MB block mapping in Level-2 |
| 87 | Translation Table entries, which use less Page Table Entries (PTEs). If |
| 88 | Level-3 PTE mapping is used instead then additional PTEs would be required, |
| 89 | which leads to the increase of translation table size. |
| 90 | |
| 91 | Due to the fact that the size of SRAM is limited on some platforms in the |
| 92 | family it should rather be avoided creating additional Level-3 mapping and |
| 93 | introduce more PTEs, hence the implementation uses Level-2 mapping which |
| 94 | maps entire DRAM space. |
| 95 | |
| 96 | The reason for the MT_RW attribute mapping scheme is the fact that the SMC |
| 97 | API to get the status and events is called from NS world passing destination |
| 98 | pointers which are located in DRAM. Mapping DRAM without MT_RW permissions |
| 99 | causes those locations not to be filled, which in turn causing EL1&0 software |
| 100 | not to receive replies. |
| 101 | |
| 102 | Therefore, DRAM mapping is done with MT_RW attributes, as it is required for |
| 103 | data exchange between EL3 and EL1&0 software. |
| 104 | |
| 105 | Reference Documentation |
| 106 | ~~~~~~~~~~~~~~~~~~~~~~~ |
| 107 | |
| 108 | Details on HABv4 usage and implementation could be found in following documents: |
| 109 | |
| 110 | - AN4581: "i.MX Secure Boot on HABv4 Supported Devices", Rev. 4 - June 2020 |
| 111 | - AN12263: "HABv4 RVT Guidelines and Recommendations", Rev. 1 - 06/2020 |
| 112 | - "HABv4 API Reference Manual". This document in the part of NXP Code Signing Tool (CST) distribution. |
| 113 | |