The following figure illustrates the non-secure boot flow high-level phases.
The three platform management controller (PMC) functional blocks that control the non-secure boot process are:
- PMC hardware dedicated state machines
- PMC ROM code unit (RCU)
- PMC platform processing unit (PPU)
The following figure shows the PMC functional blocks primary responsibilities and their memory source at each phase in the non-secure boot flow. The figure provides one example in which the major partition components (except for Linux) are loaded by the platform loader and manager. Linux is loaded by U-Boot.
There are many different application partition requirements, and the Versal device provides the flexibility to address them. For example, some application protocols might require the RPU partition to be loaded first, or the software to be loaded from U-Boot, while other applications might not require the RPU or other partitions at all. Each phase in the example non-secure boot flow figure is described in this section.
Phase 1 (Pre-boot)
In phase 1, the non-secure and secure boot flows execute the same sequence of steps. The PMC hardware must detect that the power is valid and that the external POR_B pin is released to initiate a boot sequence. Depending on the boot mode selected and application, other power supplies will be required.
After power is applied to the device, the dedicated PMC hardware state machines perform a series of mandatory tasks to prepare the system for the PMC RCU release. The tasks include capturing the value of the boot mode pins into a PMC register for the RCU to read. The test interfaces (for example, JTAG) initialize to a known secure state. This is followed by scan clear, where the registers in the PMC are zeroized and readback to confirm scan clear was successful. Next, the dedicated hardware hashes the PMC immutable BootROM using the SHA-3/384 engine and compares the calculated cryptographic hash against a golden copy stored in the device. If the hashes match, the integrity of the RCU ROM is validated and the PMC is released from reset If the hash comparison fails an error is flagged. The default action is to log and continue until the PLM can determine what action to take.
Phase 2 (Boot Setup)
In phase 2, the PMC RCU non-secure and secure boot flow steps begin to diverge. See Secure Boot Flow for details on the additional security checks available. In the default non-secure boot flow, the PMC RCU performs basic integrity checks. The RCU initializes PMC blocks such as the System Monitor and the PMC PLLs. Checks for voltage and the PLL lock are performed.
After the initial security and integrity checks pass, the RCU reads the boot mode register value to determine the boot mode configuration required. If a JTAG or SBI boot mode is detected, the RCU enables the SelectMAP or JTAG interface path and then hands the control to the user to load the programmable device image.
When an autonomous boot mode is detected, the RCU initializes the corresponding
boot interface and searches for a valid boot header within a programmable device
image (PDI). To validate a boot header, the RCU looks for the image identification
string XLNX (0x584c4e58). When a valid image
identification string is found in the boot header, the checksum for the boot header
is checked. If the checksum is valid, the rest of the programmable device image boot
header and platform loader and manager (PLM) are loaded into the PPU RAM.
If a valid boot header is not found, the image search is initiated for autonomous boot modes. The search works differently depending on the type of autonomous boot mode selected. For OSPI and QSPI boot modes, the programmable device images can be located every 32 KB in the boot memory device, which allows for more than one image to be stored in the flash memory device. If an image header is invalid, the BootROM increments the MultiBoot register ( PMC_MULTI_BOOT ) read address offset by 32 KB and tries again. For SD and eMMC boot modes, the 8191 FAT files can be searched for the identification string.
The RCU checks and validates the image signature, and then copies the platform loader and manager into the PPU RAM. The RCU releases the PPU from reset to begin phase 3 (load platform) and the RCU enters a sleep state, wake on interrupt for service routines throughout Phase 3 and Phase 4.
Phase 3 (Load Platform)
In phase 3, the PMC PPU executes the PLM from the PPU RAM. The PLM reads the programmable device image from the boot source and the PLM configures the components of the system including the NoC initialization, DDR memory initialization, programmable logic, and processing system, and then completes the device boot.
If a boot header is valid, but the PLM determines the programmable device image is corrupt, the PLM can recover by writing the location of another boot header into the MultiBoot register ( PMC_MULTI_BOOT ), and issuing an internal system reset (not an external POR_B reset). After the system reset, the boot header is fetched from the address location equal to the value of the MultiBoot register multiplied by 32 KB. When the fallback boot header is invalid, the RCU continues normally with its boot image search function if the boot device supports image search.
Phase 4 (Post-boot)
After the non-secure boot flow is complete, the PLM is active and numerous services can be run in this phase. Services include power management, partial reconfiguration, system error management, safety monitoring, security monitoring, and soft-error mitigation.
For more information on the Versal adaptive SoC boot process, see the Versal Adaptive SoC System Software Developers Guide (UG1304).