xref: /rk3399_ARM-atf/docs/plat/imx8m.rst (revision 4e5d262345b3e3e3b97890b95d1bc72e8972792d)
124dba2b3SPaul BeesleyNXP i.MX 8M Series
224dba2b3SPaul Beesley==================
381136819SBai Ping
481136819SBai PingThe i.MX 8M family of applications processors based on Arm Corte-A53 and Cortex-M4
581136819SBai Pingcores provide high-performance computing, power efficiency, enhanced system
681136819SBai Pingreliability and embedded security needed to drive the growth of fast-growing
781136819SBai Pingedge node computing, streaming multimedia, and machine learning applications.
881136819SBai Ping
9e3c07d2fSJacky Baiimx8mq is dropped in TF-A CI build due to the small OCRAM size, but still actively
10e3c07d2fSJacky Baimaintained in NXP official release.
11e3c07d2fSJacky Bai
1281136819SBai PingBoot Sequence
1324dba2b3SPaul Beesley-------------
1481136819SBai Ping
1581136819SBai PingBootrom --> SPL --> BL31 --> BL33(u-boot) --> Linux kernel
1681136819SBai Ping
1781136819SBai PingHow to build
1824dba2b3SPaul Beesley------------
1981136819SBai Ping
2081136819SBai PingBuild Procedure
2124dba2b3SPaul Beesley~~~~~~~~~~~~~~~
2281136819SBai Ping
2381136819SBai Ping-  Prepare AARCH64 toolchain.
2481136819SBai Ping
2581136819SBai Ping-  Build spl and u-boot firstly, and get binary images: u-boot-spl.bin,
2681136819SBai Ping   u-boot-nodtb.bin and dtb for the target board.
2781136819SBai Ping
2881136819SBai Ping-  Build TF-A
2981136819SBai Ping
3081136819SBai Ping   Build bl31:
3181136819SBai Ping
3281136819SBai Ping   .. code:: shell
3381136819SBai Ping
34650a435cSMark Dykes       CROSS_COMPILE=aarch64-linux-gnu- make PLAT=<Target_SoC> bl31
3581136819SBai Ping
3681136819SBai Ping   Target_SoC should be "imx8mq" for i.MX8MQ SoC.
37179f82a2SJacky Bai   Target_SoC should be "imx8mm" for i.MX8MM SoC.
3858fdd608SJacky Bai   Target_SoC should be "imx8mn" for i.MX8MN SoC.
39a775ef25SJacky Bai   Target_SoC should be "imx8mp" for i.MX8MP SoC.
4081136819SBai Ping
4181136819SBai PingDeploy TF-A Images
4224dba2b3SPaul Beesley~~~~~~~~~~~~~~~~~~
4381136819SBai Ping
4481136819SBai PingTF-A binary(bl31.bin), u-boot-spl.bin u-boot-nodtb.bin and dtb are combined
4581136819SBai Pingtogether to generate a binary file called flash.bin, the imx-mkimage tool is
4681136819SBai Pingused to generate flash.bin, and flash.bin needs to be flashed into SD card
4781136819SBai Pingwith certain offset for BOOT ROM. the u-boot and imx-mkimage will be upstreamed
4881136819SBai Pingsoon, this doc will be updated once they are ready, and the link will be posted.
49ad329e50SYing-Chun Liu (PaulLiu)
50ad329e50SYing-Chun Liu (PaulLiu)TBBR Boot Sequence
51ad329e50SYing-Chun Liu (PaulLiu)------------------
52ad329e50SYing-Chun Liu (PaulLiu)
53ad329e50SYing-Chun Liu (PaulLiu)When setting NEED_BL2=1 on imx8mm. We support an alternative way of
54ad329e50SYing-Chun Liu (PaulLiu)boot sequence to support TBBR.
55ad329e50SYing-Chun Liu (PaulLiu)
56ad329e50SYing-Chun Liu (PaulLiu)Bootrom --> SPL --> BL2 --> BL31 --> BL33(u-boot with UEFI) --> grub
57ad329e50SYing-Chun Liu (PaulLiu)
58ad329e50SYing-Chun Liu (PaulLiu)This helps us to fulfill the SystemReady EBBR standard.
59ad329e50SYing-Chun Liu (PaulLiu)BL2 will be in the FIT image and SPL will verify it.
60ad329e50SYing-Chun Liu (PaulLiu)All of the BL3x will be put in the FIP image. BL2 will verify them.
61ad329e50SYing-Chun Liu (PaulLiu)In U-boot we turn on the UEFI secure boot features so it can verify
62ad329e50SYing-Chun Liu (PaulLiu)grub. And we use grub to verify linux kernel.
6310bf3d7cSYing-Chun Liu (PaulLiu)
6410bf3d7cSYing-Chun Liu (PaulLiu)Measured Boot
6510bf3d7cSYing-Chun Liu (PaulLiu)-------------
6610bf3d7cSYing-Chun Liu (PaulLiu)
6710bf3d7cSYing-Chun Liu (PaulLiu)When setting MEASURED_BOOT=1 on imx8mm we can let TF-A generate event logs
6810bf3d7cSYing-Chun Liu (PaulLiu)with a DTB overlay. The overlay will be put at PLAT_IMX8M_DTO_BASE with
6910bf3d7cSYing-Chun Liu (PaulLiu)maximum size PLAT_IMX8M_DTO_MAX_SIZE. Then in U-boot we can apply the DTB
7010bf3d7cSYing-Chun Liu (PaulLiu)overlay and let U-boot to parse the event log and update the PCRs.
71*de7e9b56SAndrey Zhizhikin
72*de7e9b56SAndrey ZhizhikinHigh Assurance Boot (HABv4)
73*de7e9b56SAndrey Zhizhikin---------------------------
74*de7e9b56SAndrey Zhizhikin
75*de7e9b56SAndrey ZhizhikinAll actively maintained platforms have a support for High Assurance
76*de7e9b56SAndrey ZhizhikinBoot (HABv4), which is implemented via ROM Vector Table (RVT) API to
77*de7e9b56SAndrey Zhizhikinextend the Root-of-Trust beyond the SPL. Those calls are done via SMC
78*de7e9b56SAndrey Zhizhikinand are executed in EL3, with results returned back to original caller.
79*de7e9b56SAndrey Zhizhikin
80*de7e9b56SAndrey ZhizhikinNote on DRAM Memory Mapping
81*de7e9b56SAndrey Zhizhikin~~~~~~~~~~~~~~~~~~~~~~~~~~~
82*de7e9b56SAndrey Zhizhikin
83*de7e9b56SAndrey ZhizhikinThere is a special case of mapping the DRAM: entire DRAM available on the
84*de7e9b56SAndrey Zhizhikinplatform is mapped into the EL3 with MT_RW attributes.
85*de7e9b56SAndrey Zhizhikin
86*de7e9b56SAndrey ZhizhikinMapping the entire DRAM allows the usage of 2MB block mapping in Level-2
87*de7e9b56SAndrey ZhizhikinTranslation Table entries, which use less Page Table Entries (PTEs). If
88*de7e9b56SAndrey ZhizhikinLevel-3 PTE mapping is used instead then additional PTEs would be required,
89*de7e9b56SAndrey Zhizhikinwhich leads to the increase of translation table size.
90*de7e9b56SAndrey Zhizhikin
91*de7e9b56SAndrey ZhizhikinDue to the fact that the size of SRAM is limited on some platforms in the
92*de7e9b56SAndrey Zhizhikinfamily it should rather be avoided creating additional Level-3 mapping and
93*de7e9b56SAndrey Zhizhikinintroduce more PTEs, hence the implementation uses Level-2 mapping which
94*de7e9b56SAndrey Zhizhikinmaps entire DRAM space.
95*de7e9b56SAndrey Zhizhikin
96*de7e9b56SAndrey ZhizhikinThe reason for the MT_RW attribute mapping scheme is the fact that the SMC
97*de7e9b56SAndrey ZhizhikinAPI to get the status and events is called from NS world passing destination
98*de7e9b56SAndrey Zhizhikinpointers which are located in DRAM. Mapping DRAM without MT_RW permissions
99*de7e9b56SAndrey Zhizhikincauses those locations not to be filled, which in turn causing EL1&0 software
100*de7e9b56SAndrey Zhizhikinnot to receive replies.
101*de7e9b56SAndrey Zhizhikin
102*de7e9b56SAndrey ZhizhikinTherefore, DRAM mapping is done with MT_RW attributes, as it is required for
103*de7e9b56SAndrey Zhizhikindata exchange between EL3 and EL1&0 software.
104*de7e9b56SAndrey Zhizhikin
105*de7e9b56SAndrey ZhizhikinReference Documentation
106*de7e9b56SAndrey Zhizhikin~~~~~~~~~~~~~~~~~~~~~~~
107*de7e9b56SAndrey Zhizhikin
108*de7e9b56SAndrey ZhizhikinDetails on HABv4 usage and implementation could be found in following documents:
109*de7e9b56SAndrey Zhizhikin
110*de7e9b56SAndrey Zhizhikin- AN4581: "i.MX Secure Boot on HABv4 Supported Devices",  Rev. 4 - June 2020
111*de7e9b56SAndrey Zhizhikin- AN12263: "HABv4 RVT Guidelines and Recommendations", Rev. 1 - 06/2020
112*de7e9b56SAndrey Zhizhikin- "HABv4 API Reference Manual". This document in the part of NXP Code Signing Tool (CST) distribution.
113*de7e9b56SAndrey Zhizhikin
114