The Secure Monitor and the implementation of Trusted Board Boot Requirements (TBBR) make the ATF layer a mandatory requirement to load Linux on an APU on Zynq UltraScale+.įSBL loads the ATF to be executed by the APU, which keeps running in E元 awaiting a service request. The ATF includes a Secure Monitor layer for switching between the secure and non-secure world. The ATF is a transparent bare-metal application layer executed in Exception Level 3 (E元) on the APU. When the DDR initialization is completed in FSBL, the memory attributes for the DDR region are changed to “memory” so that they are cacheable.
This is to avoid speculative access to DDR before it is initialized. In the FSBL application, the xfsbl_translation_table.S differs from the translation_table.S of the Cortex-A53 in only one aspect, to mark the DDR region as reserved.
#List of boot.elf files software#
For more information, see the Zynq UltraScale+ MPSoC: Software Developers Guide ( UG1137).įor this chapter, you can use the FSBL executable that you created in Building Software for PS Subsystems. U-Boot to be executed by the APU Cortex-A53 Core-0.
In this example, the FSBL loads a bare-metal application in DDR and hands off to the RPU Cortex-R5F in lockstep mode, and then loads This includes clearing the reset of the processors and initializing clocks, memory, UART, and so on before handing over the control of the next partition in DDR, to either the RPU or APU. The first stage boot loader initializes important blocks in the processing subsystem. The last 512 bytes of this region are used by FSBL to share the hand-off parameters corresponding to the applications handed off by the ATF. In this example, the FSBL is targeted for APU Cortex™-A53Ĭore 0. The FSBL can be run from either APU A53_0, RPU R5_0, or RPU R5_lockstep. Unit loads the first stage boot loader (FSBL) into on-chip memory (OCM). At this stage, the configuration security In non-secure boot mode, the platform management unit (PMU) releases the reset of the configuration security unit, and enters the PMU server mode to monitor power. Design Example 1: Using GPIOs, Timers, and Interrupts covers the boot image which will include the PS partitions used in this chapter and a bitstream targeted for the PL fabric. This chapter makes use of a processing system block. The Bootgen GUI facilitates the creation of the BIF input file. It can be used to program non-volatile memories such as QSPI and SD cards. It can also create cryptographic keys.įunctionally, Bootgen uses a BIF (Bootgen image format) file as an input, and generates a single file image in binary BIN or MCS format. It allows you to specify security options. The principle function of the Create Boot Image wizard or Bootgen is to integrate the partitions (hardware-bitstreamĪnd software) in the proper format. To create a boot image, you can either use the Create Boot Image wizard in the Vitis IDE, or the BootgenĬommand line tool (the Create Boot Image wizard calls the Bootgen tool as well). The PS, this chapter explains how these blocks can be loaded as a part of a bigger system. While previous sections focused only on creating software blocks for each processing unit in
#List of boot.elf files manual#
Note: For more information on RPU lockstep, see the Zynq UltraScale+ Device Technical Reference Manual ( UG1085). Vitis Embedded Software Debugging Guide (UG1515) 2021.1.Profiling Applications with System Debugger.Configuring FSBL to Enable USB Boot Mode.
Loading the boot.bin Image in QSPI Using U-Boot.Boot Sequence for QSPI-Boot Mode Using JTAG.Running the Image in QSPI Boot Mode on ZCU102 Board.Creating Linux Images Using PetaLinux for QSPI Flash.Platform Management Unit Firmware (PMUFW).System Design Example: Using GPIO, Timer and Interrupts.Building and Debugging Linux Applications.Debugging Standalone Applications with the Vitis Debugger.Zynq UltraScale+ MPSoC System Configuration with Vivado.Zynq UltraScale+ MPSoC Embedded Design Tutorial.
0 kommentar(er)
