Introduction
The boot flow for the Stratix® 10 FPGA, Agilex™ 7 FPGA, and other SoC FPGA families that use the Arm® Cortex®-A53 processor uses a program called Arm Trusted Firmware (ATF).
This article describes some notes on the boot flow using ATF.
Differences between old and new boot flows (with / without ATF)
ATF was not used when the Stratix® 10 / Agilex™ 7 devices were first released, only the U-Boot SPL "First Stage Boot Loader (FSBL)" and U-Boot "Second Stage Boot Loader (SSBL)" were used. ATF is now used in the reference design environment (gsrd under 2020.11 on Rocetboards.org) for version 20.3 of Intel® Quartus® Prime development software.
The following are the old and new boot flows.
[Figure 1] Old boot flow (without ATF)
[Figure 2] New boot flow (with ATF, current standard boot flow)
Point:
The major difference between the old and new boot flows is the SSBL execution authority. In the old boot flow, SSBL operates at Exception Level 3 (EL3), whereas in the new boot flow, it operates at EL2. Since EL2 has lower privileges compared to EL3, there are restrictions on the registers that can be accessed. This results in differences when accessing registers using U-Boot commands.
Point:
In the new boot flow, access to high-security level registers is performed by ATF via Secure Monitor Call (SMC). Similarly, mailbox communication with the Secure Device Manager (SDM) is also carried out by ATF through SMC.
Note:
To execute SMC Call as a U-Boot command, the appropriate configuration must be enabled.
Please add CONFIG_CMD_SMC=y.
Reference:
Supplemental information on high-security registers and SMC Call
Managing Secure L3 Registers on Stratix® 10, Agilex™ and N5X®
Using the Old and New Boot Flow Methods
Although the current standard boot flow is the ATF-based flow, there may be times when you want to use the old boot flow for debugging or other purposes.
The U-Boot source tree contains configuration files for building FSBL / SSBL corresponding to the old boot flow, so it is possible to use the old and new boot flows by simply changing the file name specified in defconfig.
defconfig file for standard boot flow
Note:
Execute make socfpga_stratix10_defconfig or make socfpga_agilex_defconfig when building FSBL / SSBL to set config options.
Reference:
See the following page for build instructions for the standard boot flow:
Building Bootloader for Stratix 10 and Agilex | Documentation | RocketBoards.org
defconfig file for old boot flow
- socfpga_stratix10_legacy_defconfig at socfpga_v2022.01
- socfpga_stratix10_nand_legacy_defconfig at socfpga_v2022.01
- socfpga_stratix10_qspi_legacy_defconfig at socfpga_v2022.01
- socfpga_agilex_legacy_defconfig at socfpga_v2022.01
- socfpga_agilex_nand_legacy_defconfig at socfpga_v2022.01
- socfpga_agilex_qspi_legacy_defconfig at socfpga_v2022.01
Point:
The file name for the old boot flow is "*_legacy_defconfig". Also, the file for the old boot flow is different for each memory device used for booting, such as SD / NAND / QSPI.
Note:
The image file including SSBL used for boot must also be different for the old and new boot flows. The standard boot flow uses the u-boot.itb file containing both ATF and SSBL, while the old boot flow uses u-boot.img.
Note on the new boot flow: memory space used by ATF
As mentioned earlier, the ATF must continue to operate after Linux boot in order to handle SMC Calls. For this reason, it is necessary to understand the memory area used by the ATF and take care not to use this area for other purposes.
The memory area used by the ATF is shown below.
[Figure 3] Memory Area Used by the ATF
Note:
The first 1MB area of SDRAM is occupied by the ATF, so rewriting from other than the ATF is strictly prohibited. If the memory area used by the ATF is accidentally rewritten, it may cause an exception, Kernel panic, system hang-up, or other troubles by extending the execution of the SMC Call that triggers the ATF operation.
Points to note in practice: Linux device tree
The following is a practical point to note.
The Linux device tree has a reserved-memory definition in addition to the definition of memory area used by Linux Kernel.
Reserved-memory is an area reserved for a specific use, but it is safer to exclude the area used by ATF from the target area because rewriting may occur under certain conditions.
[Figure 4] Points to note (Linux device tree)
Point:
It is also possible to check the reserved-memory area from the contents of the log output immediately after the Linux boot starts. The following "Reserved memory: created DMA memory pool at 0x00000000000000100000, size 31 MiB" is the relevant information (log output after taking measures to avoid the first 1MB area).
Starting kernel ... . .
Deasserting all peripheral resets
[ 0.000000] Booting Linux on physical CPU 0x0000000000 [0x410fd034]
[ 0.000000] Linux version 5.15.30 (user@ machine) (aarch64-none-linux-gnu-gcc (GNU Toolchain for the Arm Architecture 11.2-2022.02 (arm-11.14)) 11.2.1 20220111, GNU ld (GNU Toolchain for the Arm Architecture 11.2-2022.02 (arm-11.14)) 2.37.20220122) #2 SMP PREEMPT Fri Jul 29 18:47:14 JST 2022
[ 0.000000] Machine model: SoCFPGA Agilex SoCDK
[ 0.000000] efi: UEFI not found.
[ 0.000000] Reserved memory: created DMA memory pool at 0x0000000000100000, size 31 MiB
[ 0.000000] OF: reserved mem: initialized node svcbuffer@0, compatible id shared-dma-pool
Conclusion
In this article, we introduced the old and new boot flows for Stratix® 10 and Agilex™ 7, as well as some points to note when using ATF. We share this information based on actual troubles we have experienced.
If the area used by the ATF is accidentally rewritten, it will result in program destruction, so there are various events depending on the target address / data. If the cause is not noticed at an early stage, it may cause time-consuming debugging, so please be careful.