0, ZYNQ external start conditions
1. Power requirements:
in stage 0 BootROM, both PS and PL must be powered on in safe mode; PS in non-secure mode needs to be powered on, as shown
in the figure: in stage 1 FSBL, both PS and PL must be powered on , Because the PL will be configured at this stage, and the PS will be responsible for the configuration process.
2. Clock requirements: the clock must be met.
3. Reset requirements: There are mainly two external reset sources that will affect the execution of BootROM. (Power reset signal, system reset signal)
4. Start-up pin settings: Need to configure the pins to start the platform correctly.
1、Stage 0 ：BootROM
1. After power-on reset, the PS side will begin to configure. Without using JTAG, ARM will start executing code in the on-chip BootROM.
2. The code in BootROM initializes the basic peripheral controllers of NAND, NOR, Quad-SPI, SD and PCAP, so that the ARM core can access and use these peripherals.
3. Load the boot image (Bin file: including fsbl application program, bit file, application program) of stage 1 to OCM.
4. It should be noted that the configuration of PL is not completed in BootROM, and BootROM is only ready for configuring PL.
Other peripherals such as DDR will be initialized in phase 1 or later.
The boot source of the PS is selected by the high and low levels of the external mode pins, which means that BootROM will load the stage 1 boot image from different external storages according to the settings of the external configuration pins.
After non-POR or POR, Zynq will complete:
1 Latch the configuration pins, as shown in the figure below,
2 Initialize the PLL (select to initialize or not initialize according to the latch at reset)
3 Initialize the APU (by two ARM CPUs) Composition)
4ROM CRC check
5 Initialize the pins for boot (Q-spi, NOR, SD, NAND, etc.), select according to the configuration pins latched in the previous step.
6 Start and wait for the PL to complete initialization, provided that the PL part has been powered on. If the PL is not powered on at this time, skip this step and
start searching for BootROM Header. If a legal header is found, FSBL will be loaded based on this header (encrypted or unencrypted).
8 The loaded FSBL may be XIP (Execute in place, run directly in the memory) or be loaded into the DDR. After the loading is completed, the BootROM completes the task and transfers the control to the FSBL.
2、Stage 1 ：FSBL
1. FSBL is a boot program that starts after BootROM. Load to OCM from BootROM or run directly on linear Flash. FSBL mainly completes the following tasks:
1) According to the configuration in XPS (or vivado), complete the initialization of the PS side. (MIO, Clock, DDR)
2) Use the bitstream file to configure the PL.
3) Load the second stage boot program (SSBL) or bare running program (when there is no operating system) to DDR.
4) Jump to DDR to execute SSBL or bare running program.
Note: FSBL does not enable MMU before jumping to SSBL or running program. This is because many operating systems, such as Linux, assume that the MMU is disabled at startup. FSBL startup process:
Another thing to note is: (fsbl.elf, PL bitstream files, SSBL or bare-running applications), etc. must all be organized into Bin mirrors. FSBL will traverse the partition header table to find the location of the bitstream file, SSBL or bare running program, and then load the DDR or configure it.
3. Stage 1: SSBL (not needed when there is no operating system)
1. The bootloader of SSBL is called BootLoader. The embedded linux in the Zynq platform is U-Boot, and FSBL helps us guide U-Boot into the memory.
2. U-Boot has very powerful functions, providing many user commands, reading and writing memory, flash, and USB devices. U-Boot will help us complete the necessary hardware initialization before the Linux kernel starts, such as serial ports, DDR controllers, etc.
4. Linux boot process:
Embedded linux can be divided into the following four parts from the perspective of software:
BootLoader,
linux kernel,
file system, and
application.
U-Boot will initialize the memory and necessary peripherals for the linux kernel, and set the startup parameters. In the zynq platform, the device tree is used to transfer the parameters of the driver part, so U-Boot will also copy the device tree image file to the memory for the kernel. The startup parameters passed by U-Boot to the kernel usually contain information such as the address of the device tree, the type and address of the file system. Then U-Boot will transfer system control to the linux kernel.
After the Linux kernel has control of the system, it will be initialized first, and it is recommended to start the kernel's operating environment. After the Linux kernel completes the virtual address-to-physical address mapping, there is also the initialization and mounting of the drive device. In the zynq platform, the device driver information is transmitted by the device tree. If a driver is written for the IP core in the PL, the modular method can also be used, and the device can be mounted after linux is started.
The Linux kernel will select the format and mount point of the mounted file system according to the parameter information passed by U-Boot. Finally, the linux kernel will run the init function, which is the end of the kernel boot and the starting point of all processes in the system. Applications are placed in the file system.
Original link: https://www.sohu.com/a/343257597_467791
-------------------------------------Dividing line----------- -------------------------------------------------- -----------------------------
FSBL time test:
The soft restart begins:
To the end of Status = ps7_init(); ---------------- about 107ms
To the end of DDRInitCheck------about 1ms
To PcapCtrlRegVal = XDcfg_GetControlRegister(DcfgInstPtr); ----------about 0ms
To HandoffAddress = LoadBootImage(); end----------about 676ms
FsblHandoff(HandoffAddress); After entering the function, run to FsblHandoffExit(FsblStartAddr); exit the fsbl main program directly ----- about 2ms
From the end of the above steps to entering the application ------ about 721ms (it should be the time for FSBL to load the application to OCM)
∴Soft restart to the beginning of the application: it takes 1.507s.
fsbl.h:
#define EFUSE_STATUS_REG (0xF800D010) /**< Efuse Status Register */
#define EFUSE_STATUS_RSA_ENABLE_MASK (0x400) /**< Status of RSA enable */
eFuse Write Protection (2-bits) = Bit[8:9]
OCM ROM 128KB CRC Enable = Bit[10]
RSA Authenticaiton Enable = Bit[11]
DFT JTAG Disable = Bit[12]
DFT Mode Disable = Bit[13]
Bit value : 0 = unprogrammed; 1 = programmed