Visible to Intel only — GUID: sfo1410070158979
Ixiasoft
1.1. Boot Process
1.2. Boot Stages
1.3. Boot Devices
1.4. Second-Stage Boot Loader Support Package Generator Tool
1.5. Generating a Boot Loader with an External Flash Boot Device
1.6. Boot and FPGA Configuration
1.7. Boot Debugging
1.8. Appendix A: Building the UEFI Boot Loader
1.9. Revision History for Arria 10 SoC Boot User Guide
Visible to Intel only — GUID: sfo1410070158979
Ixiasoft
1.2.2.1. Boot ROM Flow
On a cold reset, the HPS boot process starts when CPU0 is released from reset (for example, on a power up) and executes code in the internal boot ROM at the reset exception address, 0x00000000. The boot ROM code brings the HPS out of reset and into a known state. After boot ROM code is exited, control passes to the next stage of the boot software, referred to as the second-stage boot loader. The second-stage boot loader can be customized and is typically stored external to the HPS in a nonvolatile flash-based memory or in on-chip RAM within the FPGA. The second-stage boot loader can then load an OS, BareMetal application or potentially a third-stage boot loader.
This section describes the software flow from reset until the boot ROM code passes software control to the second-stage boot loader.
The code starts, initializes the system and then depending on the type of boot requested, it may attempt to load the code into the on-chip RAM. An on-chip RAM boot can only occur on a warm reset. Warm boot from on-chip RAM has the highest priority to execute if the warmram_* registers in the system manager has been configured to support booting from on-chip RAM on a warm reset. If the warmram_enable register in the system manager is set to 0xAE9EFEBC, then the boot ROM code attempts to boot from on-chip RAM on a warm reset and the boot ROM does not configure boot I/Os, pin-muxes or clocks. The warmram_datastart and warmram_length registers in System Manager allow you to program the offset of the beginning of code and the length of the region of on-chip RAM for CRC validation. If the warmram_length register is clear, then the boot ROM does not perform a CRC calculation in the on-chip RAM. If the warmram_length register is non-zero, then CRC checking is performed. If CRC checking is successful, then the boot ROM jumps to global address programmed in the warmram_execution register. If for three subsequent load attempts, the boot ROM fails to find code or the CRC check fails, the boot ROM spins, waiting for a watchdog reset.
Figure 4. Main Boot ROM Flow
The boot ROM always executes on CPU0. CPU1 is always held in reset while the main boot ROM code is executing and is only released when required by system software.
As part of determining the boot type, the boot ROM executes a low-level boot flow. The boot ROM code reads the security fuse to determine if the source of the second-stage boot is forced to be the FPGA. If a non-authenticated FPGA boot or a non-CRC on-chip RAM boot is requested or the boot is invalid, it is processed within the low-level boot flow. All other boot types are processed within the high-level boot flow.
Figure 5. Low-Level Boot Flow
During the low-level portion of the boot ROM flow, the boot ROM reads the security fuses to determine if an FPGA-only boot is required. If so, then the boot ROM must also determine if the fuses indicate that authentication of the POF is needed. If no authentication is required, then a standard FPGA configuration occurs.
If an FPGA-only boot is not required, then the boot ROM checks if an on-chip RAM boot is allowed. If it is, then the boot ROM checks to see if the code is valid. If the code is invalid, the boot ROM reads the BSEL pins to determine if it indicated an FPGA boot.
If the secure fuses indicate that authentication is required for the boot image, then a high-level boot (executed in C code) must be performed.
Figure 6. High-Level Boot Flow
During the boot process, authentication and decryption can be performed on the boot image. Authentication is independent of decryption; however, if both authentication and decryption are required, then authentication always occurs first. If an authenticated boot is required, then the boot ROM must have a root key to start the authentication process. This key can be implemented in the user fuses, in the FPGA logic elements or as part of the second-stage boot image header. The device configuration fuses determine the source of the key.
During a cold boot from flash memory, the boot ROM code attempts to load the first second-stage boot loader image from flash memory to on-chip RAM and pass control to the second-stage boot loader. If this initial image is invalid, the boot ROM code indexes the romcode_initswlastld register and attempts to load the next stored image. The boot ROM attempts three subsequent loads after the initial one. If there is still no valid image found after the subsequent loads, the boot ROM code checks the FPGA portion of the device for a fallback image.
Note: During the boot process, the boot ROM enables all of the caches (L1 data and instruction caches and L2 cache). If the second-stage boot loader is not loaded from a boot flash device (SD/MMC, QSPI, NAND) properly, the caches may be left on when the boot ROM checks the FPGA portion the device for a fallback image. This situation can lead to issues of coherency when loading code, so caches must be flushed and disabled in the fallback image.
If the warm RAM boot has failed or if a cold reset has occurred, then the boot ROM reads the BSEL value in the bootinfo register of the System Manager. If the FPGA is selected as the boot source, then the boot ROM code attempts to execute code at address 0xC0000000 across the HPS-to-FPGA bridge (offset 0x00000000 from bridge). No error conditions are generated if the FPGA does not initialize properly and the watchdog is not enabled for time-out. Instead, the boot ROM continues to wait until the FPGA is available.
If the BSEL bits indicate a boot from external flash, then the boot ROM code attempts to load an image from a flash device into the on-chip RAM, verify and execute it. If the BSEL is invalid or the boot ROM code cannot find a valid image in the flash, then the boot ROM code checks if there is a fallback image in the FPGA. If there is, then the boot ROM executes the fallback image. If there is no fallback image then the boot ROM performs a post-mortem dump of information into the on-chip RAM and awaits a reset.
Note: The acronyms BSEL and BOOTSEL are used interchangeably to define the boot select pins.
The boot ROM code verifies the second-stage boot loader in several ways to ensure a corrupted image is not executed. The first test is of the image header, which identifies the magic number, version, block length, and CRC of the image that protects the block. If any of these are invalid, an error occurs.