blob: f8071f71d445935ff087d08cf19657798634bd73 [file] [log] [blame]
Paul Beesleyf3653a62019-05-22 11:22:44 +01001NXP i.MX 8M Series
2==================
Bai Ping06e325e2018-10-28 00:12:34 +08003
4The i.MX 8M family of applications processors based on Arm Corte-A53 and Cortex-M4
5cores provide high-performance computing, power efficiency, enhanced system
6reliability and embedded security needed to drive the growth of fast-growing
7edge node computing, streaming multimedia, and machine learning applications.
8
Jacky Bai98074512021-06-07 10:11:04 +08009imx8mq is dropped in TF-A CI build due to the small OCRAM size, but still actively
10maintained in NXP official release.
11
Bai Ping06e325e2018-10-28 00:12:34 +080012Boot Sequence
Paul Beesleyf3653a62019-05-22 11:22:44 +010013-------------
Bai Ping06e325e2018-10-28 00:12:34 +080014
15Bootrom --> SPL --> BL31 --> BL33(u-boot) --> Linux kernel
16
17How to build
Paul Beesleyf3653a62019-05-22 11:22:44 +010018------------
Bai Ping06e325e2018-10-28 00:12:34 +080019
20Build Procedure
Paul Beesleyf3653a62019-05-22 11:22:44 +010021~~~~~~~~~~~~~~~
Bai Ping06e325e2018-10-28 00:12:34 +080022
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 Dykesef3a4562020-01-08 20:37:18 +000034 CROSS_COMPILE=aarch64-linux-gnu- make PLAT=<Target_SoC> bl31
Bai Ping06e325e2018-10-28 00:12:34 +080035
36 Target_SoC should be "imx8mq" for i.MX8MQ SoC.
Jacky Baia6177002019-03-06 17:15:06 +080037 Target_SoC should be "imx8mm" for i.MX8MM SoC.
Jacky Bai9bd2f842019-11-28 13:16:33 +080038 Target_SoC should be "imx8mn" for i.MX8MN SoC.
Jacky Bai07ed02c2020-06-03 14:28:45 +080039 Target_SoC should be "imx8mp" for i.MX8MP SoC.
Bai Ping06e325e2018-10-28 00:12:34 +080040
41Deploy TF-A Images
Paul Beesleyf3653a62019-05-22 11:22:44 +010042~~~~~~~~~~~~~~~~~~
Bai Ping06e325e2018-10-28 00:12:34 +080043
44TF-A binary(bl31.bin), u-boot-spl.bin u-boot-nodtb.bin and dtb are combined
45together to generate a binary file called flash.bin, the imx-mkimage tool is
46used to generate flash.bin, and flash.bin needs to be flashed into SD card
47with certain offset for BOOT ROM. the u-boot and imx-mkimage will be upstreamed
48soon, this doc will be updated once they are ready, and the link will be posted.
Ying-Chun Liu (PaulLiu)234c2712020-12-22 02:56:00 +080049
50TBBR Boot Sequence
51------------------
52
53When setting NEED_BL2=1 on imx8mm. We support an alternative way of
54boot sequence to support TBBR.
55
56Bootrom --> SPL --> BL2 --> BL31 --> BL33(u-boot with UEFI) --> grub
57
58This helps us to fulfill the SystemReady EBBR standard.
59BL2 will be in the FIT image and SPL will verify it.
60All of the BL3x will be put in the FIP image. BL2 will verify them.
61In U-boot we turn on the UEFI secure boot features so it can verify
62grub. And we use grub to verify linux kernel.
Ying-Chun Liu (PaulLiu)da039c82021-11-15 16:13:10 +080063
64Measured Boot
65-------------
66
67When setting MEASURED_BOOT=1 on imx8mm we can let TF-A generate event logs
68with a DTB overlay. The overlay will be put at PLAT_IMX8M_DTO_BASE with
69maximum size PLAT_IMX8M_DTO_MAX_SIZE. Then in U-boot we can apply the DTB
70overlay and let U-boot to parse the event log and update the PCRs.
Andrey Zhizhikin916ac602022-09-26 22:51:47 +020071
72High Assurance Boot (HABv4)
73---------------------------
74
75All actively maintained platforms have a support for High Assurance
76Boot (HABv4), which is implemented via ROM Vector Table (RVT) API to
77extend the Root-of-Trust beyond the SPL. Those calls are done via SMC
78and are executed in EL3, with results returned back to original caller.
79
80Note on DRAM Memory Mapping
81~~~~~~~~~~~~~~~~~~~~~~~~~~~
82
83There is a special case of mapping the DRAM: entire DRAM available on the
84platform is mapped into the EL3 with MT_RW attributes.
85
86Mapping the entire DRAM allows the usage of 2MB block mapping in Level-2
87Translation Table entries, which use less Page Table Entries (PTEs). If
88Level-3 PTE mapping is used instead then additional PTEs would be required,
89which leads to the increase of translation table size.
90
91Due to the fact that the size of SRAM is limited on some platforms in the
92family it should rather be avoided creating additional Level-3 mapping and
93introduce more PTEs, hence the implementation uses Level-2 mapping which
94maps entire DRAM space.
95
96The reason for the MT_RW attribute mapping scheme is the fact that the SMC
97API to get the status and events is called from NS world passing destination
98pointers which are located in DRAM. Mapping DRAM without MT_RW permissions
99causes those locations not to be filled, which in turn causing EL1&0 software
100not to receive replies.
101
102Therefore, DRAM mapping is done with MT_RW attributes, as it is required for
103data exchange between EL3 and EL1&0 software.
104
105Reference Documentation
106~~~~~~~~~~~~~~~~~~~~~~~
107
108Details 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