This document provides comprehensive information on boot flow, boot
source devices and how to generate and debug a bootloader for the
Arria® 10 SoC.
The details provided in this SoC boot user guide are:
Typical boot flows supported by the
Arria® 10 SoC system
Available boot source devices and their configuration information
First and second boot stages (U-Boot or Unified Extensible Firmware
U-Boot is the primary example covered in this user guide, using UEFI as a second-stage
non-general public license (non-GPL) boot loader source is also introduced. See "Appendix
A: Building the UEFI Boot Loader" for more information.
How to generate a boot loader and configure for a boot source device
How to build a boot loader
Debugging a boot loader
Technical reference appendices for boot memories and the SoC development
Note: This document does not provide details of
secure boot. For information regarding secure boot, please refer to AN-759: Arria 10 SoC Secure Boot User Guide.
The booting of the HPS is a multi-stage process. Each stage is
responsible for loading the next stage.
The first stage is the boot ROM execution. The boot ROM code,
located in the HPS, brings the processor out of reset, puts the processor into a known
and stable state, finds the second-stage boot loader and passes control to the next
stage. The boot ROM code is only aware of the second-stage boot loader and not aware of
any potential subsequent software stages. During this time, the boot ROM also seamlessly
handles any error conditions.
The next stage is when control passes to the second-stage boot
loader. The second-stage boot loader is located external to the HPS, either in external
flash memory or within the FPGA. If the FPGA is used, the second stage boot loader can
execute directly from the FPGA without the need to copy it to on-chip RAM. The
second-stage boot loader locates and loads the next stage software and so on.
Before control is passed to the second stage boot loader, it
can be decrypted and/or authenticated if secure boot is enabled.
After a warm reset, the user can instruct the boot ROM to
find an image in the on-chip RAM and execute directly from that. In this case, the image
that resides in RAM is unauthenticated and clear text, although it may have been
imported into on-chip RAM as authenticated code initially.
The figure below illustrates the typical boot flow. However, there may be
more or less software stages in the user software than shown and the roles of the
software stages may vary.
Figure 1. Typical Boot Flow. An example of a typical boot flow second-stage boot loader is
U-Boot. An example of a typical boot flow OS is Linux.
Bare Metal Boot Flow
The figure below shows a boot flow with a BareMetal application.
Figure 2. BareMetal Boot Flow
Custom Boot Loader
You can also create your own custom boot loader if required.
Figure 3. Custom Boot loader Flow
Reset precedes the boot stages and is an important part of device
initialization. There are two different reset types: cold reset and warm reset.
The FPGA portion of the SoC can trigger a warm or cold reset on
completion of configuration.
The boot process begins when CPU0 in the MPU exits from
the reset state. When CPU0 exits from reset, it starts executing code at the reset
exception address where the boot ROM code is located. CPU1 remains in reset during
this time and is brought out of reset by user software.
With warm reset, some software registers are preserved and the
boot process may skip some steps depending on software settings. In addition, on a
warm reset, the second-stage boot loader has the ability to be executed from on-chip
The boot ROM code is 128 KB in size and located in on-chip ROM
at addresses 0xFFFC0000 to 0xFFFDFFFF. The function of the boot ROM code is to
determine the boot source, initialize the HPS after a reset, and jump to the
second-stage boot loader. If the second-stage boot loader image has already been
loaded from the flash memory to on-chip RAM, the boot ROM jumps to on-chip RAM
location. The boot ROM performs the following actions to initialize the HPS:
Enables instruction cache, branch
predictor, floating point unit, and NEON vector unit of CPU0
Sets up the level 4 (L4) watchdog 0
Configures dedicated pins based on Boot Select (BSEL) settings
Initializes the flash controller to
When booting from flash memory, the boot ROM code uses the top
32 KB of the on-chip RAM as data workspace. This area is reserved for the boot ROM
code after a reset until the boot ROM code passes software control to second-stage
boot loader. The maximum second-stage boot loader size is 208 KB with authentication
and 224 KB without. For a warm boot from RAM or a boot from FPGA, the boot ROM code
does not reserve the top 32 KB of the on-chip RAM, and the user may place user data
in this area without being overwritten by the boot ROM.
Note: The boot ROM only
initializes the portions within the 32 KB of on-chip RAM it uses. If ECC is
required by the second-stage boot loader in on-chip RAM, then you should enable
the security fuse that clears all RAMs on a cold reset. Refer to SoC Security chapter in the Arria 10 Hard Processor System Technical Reference Manual for more
information on secure fuses.
The boot process begins when CPU0 exits from the reset state. The boot ROM
code only executes on CPU0. CPU1 is held in reset until it is released by user
software. When CPU0 exits from reset, it starts executing code at the reset
During boot ROM execution, the clock control fuse information is
automatically sent to the Clock Manager, the memory control fuse information is
automatically sent to the Reset Manager and all other fuse functions
(authentication, encryption, private and public key source, hash functions) are
stored in a memory-mapped location for boot code to read. In normal operation, the
boot ROM is mapped at the reset exception address so code starts executing in the
When CPU0 exits the boot ROM code and starts executing user software, boot ROM
access is disabled. The user software executing on CPU0 must map the user software
exception vectors to 0x0 (which was previously mapped to the boot ROM exception
vectors) and release CPU1 from reset, if required. When CPU1 is released from reset,
CPU1 executes the user software exception instead of the boot ROM.
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
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
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
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
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 will attempt 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
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
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.
Second Stage: Boot Loader (U-Boot)
Note: This section pertains to feature information for U-Boot. For information on UEFI
boot loader features, refer to technical reference documentation for UEFI on
Altera®'s wiki page.
The function of the second-stage boot loader is user-defined. The
Altera-provided second-stage boot
loader is a combination of initialization, configuration and U-Boot code and
contains features such as:
SD/MMC controller driver
QSPI controller driver
NAND Controller driver
Ethernet driver plus protocol support
Drivers for system-level IP, such as Clock Manager, System
Manager, and FPGA Manager
Cache memory drivers
UART, timer and watchdog drivers
FAT file system support
Flat Image Tree (FIT) image processing
U-Boot console support including basic essential debug
U-Boot device tree processing library
System and memory firewall configuration
Initialization code for the interface that loads the next stage
If a secure boot is required, the second-stage boot loader can be
used to increase the level of security and to authenticate and initiate decryption
of the next boot image if necessary.
Configuring the SDRAM firewall allows the second-stage boot loader to
load the next stage of the boot software into SDRAM. The maximum length for a
second-stage boot loader to fit into on-chip RAM is 208 KB with authentication and
224 KB without authentication. A typical next software stage is loading the
application OS software. The second-stage boot loader is allowed to load the next
stage boot software from any device available to the HPS. Typical sources include
the same flash device that contains the second stage boot loader, a different flash
device, or a communication interface such as an EMAC.
If the second-stage boot loader must be authenticated, it must store
a public key. Below is a figure that depicts the second-stage boot loader image
presented to the boot ROM, during a secure, authenticated boot.
Figure 7. High-Level Diagram of Second-Stage Boot Loader Image
Low-level initialization steps include reconfiguring or disabling the
L4 watchdog 0 timer, invalidating the instruction cache and branch predictor,
remapping the on-chip RAM to the lowest memory region, and setting up the data area.
Upon entering the second-stage boot loader, the L4 watchdog 0 timer is active.
The second stage boot loader can disable, reconfigure, or leave the watchdog timer
unchanged. Once enabled after reset, the watchdog timer cannot be disabled, only
paused or reset.
The instruction cache and branch predictor, which were previously enabled by
the boot ROM code, must be invalidated. If the second-stage boot loader enables and
uses the data cache, it must initialize all levels of the data cache before
The second-stage boot loader must remap the exception vector table because the
exception vectors are still pointing to the exception handler in the boot ROM when
it starts executing. By setting the system interconnect remap bit 0 to one, the
on-chip RAM mirrors to the lowest region of the memory map. After this remap, the
exception vectors use the exception handlers in the boot loader image.
The figure below shows the memory map before and after remap. The first
mapping depicts boot ROM execution. The second mapping shows the remap of the
on-chip RAM when the remap bit is set during second-stage boot loader execution.
Figure 9. Remapping the On-Chip RAM
The second-stage boot loader can reconfigure all HPS clocks. During
clock reconfiguration, the boot loader asserts reset to the peripherals in the HPS
affected by the clock changes.
The I/O assignments for the HPS are configured as part of the IOCSR
configuration in the second-stage boot loader. Effectively, a bitstream containing
the I/O assignments is sent to the device as part of the initialization code in the
second-stage boot loader. If the FPGA fabric and I/O have not yet been configured
through the FPGA and the HPS needs to access SDRAM, you should program the HPS to
use the full or early I/O release configuration method to configure the shared and
hard memory controller I/O. Refer to "FPGA Configuration" section of the "Booting
and Configuration" appendix in the Arria 10 Hard Processor System
Technical Reference Manual for details on full and early I/O release
The second-stage boot loader looks for a valid next-stage boot image in the
next-stage boot device by checking the boot image validation data and checksum in
the mirror image. Once validated, the second-stage boot loader copies the next-stage
boot image (OS or application image) from the next-stage boot device to the SDRAM.
Before software passes control to the next-stage boot software, the
second-stage boot loader can write a valid value (0x49535756) to the romcode_initswstate register in the System Manager.
This value indicates that there is a valid boot image in the on-chip RAM. The
romcode_initiswlastld register holds the index
of the last second-stage boot loader software image loaded by the Boot ROM from the
boot device. When a warm reset occurs, the Boot ROM loads the image indicated by the
romcode_initswlastld register if the BSEL value
is the same as the last boot.
The main purpose of secure boot is to pass the chain of trust to the
subsequent boot software. During a secure boot, the second-stage boot loader may
authenticate or decrypt the subsequent boot image, depending on the current state
registers in the Security Manager. In addition, the second-stage boot loader must
ensure that the subsequent boot image is executed from secure memory such as on-chip
RAM. The second-stage boot loader fits into the chain of trust as such:
Figure 10. Secure Boot Flow
The micro OS provides secure APIs to allow the application in the
normal world OS to establish trusted services.
During a verified boot, the second-stage boot loader only
authenticates the OS image and other images required by the OS. A flow for a
verified boot is shown below.
Figure 11. Verified (Authenticated) Boot Flow
For both the secure and verified boot, the subsequent boot image must be
executed in on-chip RAM while the second-stage boot loader is still executing from
on-chip RAM. In order to accommodate this requirement, the authentication and
decryption process might follow the following steps depicted in the next three
diagrams, depending on the type of secure boot chosen.
Figure 12. Second-Stage Boot Loader Authentication Process
Figure 13. Second-Stage Boot Loader Decryption Process
Decryption is optional and is not required for secure boot. Upon
entry into the second-stage boot loader, the CSS engine is enabled. The second-stage
boot loader decrypts the subsequent boot image and disables the CSS engine upon
Figure 14. Second-Stage Boot Loader Authentication and Decryption
The boot select (BSEL) pins offer multiple methods to obtain the
second-stage boot image. On a cold reset, the boot source is determined by a
combination of secure boot fuses and BSEL pins. These fuse values and BSEL pin
values are sent to the Security Manager module of the HPS when the cold reset
occurs. When the HPS is released from reset, the boot ROM reads the bootinfo register of the System Manager to determine
the source of the boot.
Note: If the fpga_boot_f fuse is blown, the BSEL pins are bypassed and the
HPS can only boot from the FPGA. Additionally, the clock select (CSEL) fuse values
are ignored and clock configuration is controlled through the FPGA. This
configuration allows the HPS to boot from encrypted user code in the FPGA. If the
boot source is the FPGA, the boot ROM code does not configure any of the
boot-specific HPS I/Os for booting from flash memory. If the fpga_boot_f fuse is not
blown, then the boot source is determined according to the BSEL pins. If the BSEL
pins are used for determining the boot source, then the following table shows the
flash devices assigned to each encoding.
Note: If a boot from FPGA is
required (BSEL[2:0]=0x1), then you must ensure that the HPS is not released from
reset until after the FPGA has been fully programmed. Otherwise, the bootinfo register to determine the boot source might be
read incorrectly by the boot ROM. FPGA readiness is indicated by handshake signals,
f2h_boot_from_fpga_ready and f2h_boot_from_fpga_on_failure, from the FPGA to the
HPS. The f2h_boot_from_fpga_ready signal must be
pulled up to indicate readiness. Refer to the "Instantiating the HPS Component"
chapter for more information about FPGA boot handshake signals.
Note: The acronyms BSEL
and BOOTSEL are used interchangeably to define the boot select pins.
Table 1. BSEL Values for Boot Source Selection
FPGA (HPS-to-FPGA bridge)
1.8 V NAND flash memory
3.0 V NAND flash memory
1.8 V SD/MMC flash memory with
3.0 V SD/MMC flash memory with
1.8 V quad SPI flash memory
3.0 V quad SPI flash memory
Note: If the BSEL value is set to
0x4 or 0x5, an external translation transceiver may be required to supply
level-shifting and isolation if the SD cards interfacing to the SD/MMC controller
must operate at a different voltage than the controller interface. Please refer to
the SD/MMC Controller chapter for more information.
The typical boot flow is for the boot ROM code to find
the second-stage boot loader image on a flash device, load that into on-chip RAM and
execute it. After a warm reset, the boot ROM code can be instructed to find the
image in RAM and execute that.
The HPS flash sources can store various file types, such as:
FPGA programming files
Second-stage boot loader binary file (up to four
Operating system binary files
Application file system
The second-stage boot loader image in flash can be authenticated
and decrypted by the HPS. A boot directly from the HPS on-chip RAM is always
unauthenticated and in clear text, although it may have an optional CRC if
When the BSEL value is 0x1, the FPGA is selected as the boot
source for that boot. This selection is not permanent as it is when the fpga_boot_f
fuse is enabled. In both cases, the CSEL fuses are also ignored and the HPS must be
held in reset until the FPGA is powered on and programmed to prevent the boot ROM
from misinterpreting the boot source.
If an HPS flash interface has been selected to load the
boot image, then the boot ROM enables and configures that interface before loading
the boot image into on-chip RAM, verifying it and passing software control to the
second-stage boot loader.
If the FPGA fabric is the boot source, the boot ROM
code waits until the FPGA portion of the device is in user mode, and is ready to
execute code and then passes software control to the second-stage boot loader in the
Flash Memory Devices for Booting
The memory controllers and devices that contain the boot loader image
have configuration requirements for proper boot from flash.
On all flash devices, there is an area of memory, called
the boot area that contains up to four second-stage boot loader images. For the QSPI and
SD/MMC devices, the boot area is 1 MB in size. For NAND devices the boot area is four
device blocks in size and may be larger than 1 MB if the NAND erase block is larger than
The SD/MMC, Quad SPI and NAND flash devices all support raw
and MBR (partition) mode. In raw mode, the boot image is located at the start of the
flash memory device, at offset 0x0. In MBR mode:
The boot image is read from a custom partition (0xA2)
The first image is located at the beginning of the partition, at offset 0x0
Start address = partition start address
Quad SPI Flash Devices
The figure below shows the quad SPI flash image layout. The
second-stage boot loader image is always located at offsets that are multiples of 256
Figure 15. Quad SPI Flash Image Layout
The boot ROM code configures the quad SPI controller to default settings for the
supported SPI or quad SPI flash memory.
The following figure shows an SD/MMC flash image layout
example for boot. The master boot record (MBR) is located in the first 512 bytes of the
memory. The MBR contains information about the partitions (address and size of
partition). The second-stage boot loader image is stored in partition A2. Partition A2
is a custom raw partition with no file system.
Figure 16. SD/MMC Flash Image Layout
The SD/MMC controller supports two booting modes:
MBR (partition) mode
The boot image is
read from a custom partition (0xA2)
The first image is
located at the beginning of the partition, at offset 0x0
Start address =
partition start address
If the MBR
signature is not found, SD/MMC driver assumes it is in raw mode
The boot image data
is read directly from sectors in the user area and is located at the first
sector of the SD/MMC
The first image is
located at the start of the memory card, at offset 0x0
Start address =
The MBR contains the partition table, which is always located in the
first sector (LBA0) with a memory size of 512 bytes. The MBR consists of executable
code, four partition entries, and the MBR signature. A MBR can be created by specific
tools like the FDISK program.
Table 2. MBR Structure
Size (In Bytes)
Partition entry for partition 1
Partition entry for partition 2
Partition entry for partition 3
Partition entry for partition 4
MBR signature: 0xAA55
The standard MBR structure contains a partition with four 16-byte
entries. Thus, memory cards using this standard table cannot have more than four primary
partitions or up to three primary partitions and one extended partition.
Each partition type is defined by the partition entry. The boot images
are stored in a primary partition with custom partition type (0xA2). The SD/MMC flash
driver does not support a file system, so the boot images are located in partition A2 at
Table 3. Partition Entry
Size (In Bytes)
Boot indicator. 0x80 indicates that it is bootable.
Starting CHS value
Ending CHS value
LBA of first sector in partition
Number of sectors in partition
The boot ROM code configures the SD/MMC controller to default settings
for the supported SD/MMC flash memory.
The NAND subsystem reserves at least the first 1 MB on the NAND
device. If the NAND flash device has blocks greater than 256 KB, then the NAND subsystem
reserves the first four blocks on the device. For a NAND device with less than 256 KB
block size, the second-stage boot loader image must be placed in multiple blocks. The
NAND subsystem expects to find up to four second-stage boot loader images on the NAND
device. You may have less than four images if required. The second-stage boot loader
image should always be at the start of a physical page. Because a block is the smallest
area used for erase operation, any update to a particular image does not affect other
In the figure below, the FPGA is configured first through one of its non-HPS
configuration sources. The CSS block configures the FPGA fabric as well as the FPGA I/O,
shared I/O and hard memory controller I/O. The HPS executes the second-stage boot loader from
the FPGA. In this situation, the HPS should not be released from reset until the FPGA is
powered on and programmed. Once the FPGA is in user mode and the HPS has been released from
reset, the boot ROM code begins executing. The HPS boot ROM code executes the second-stage
boot loader from the FPGA fabric over the HPS-to-FPGA bridge.
Figure 18. Boot From FPGA Flow
Second-Stage Boot Loader Support Package Generator Tool
The SoC Embedded Design Suite (SoC EDS) includes
the second-stage boot loader support package (BSP) generator tool that allows you to
generate a boot loader for your FPGA design.
The boot generation flow and
BSP Editor tool are described in the following sections.
Boot Loader Generation and Flow
Generating a boot loader involves several steps to produce a final
Each step is dependent on the previous one. Either the associated
Altera® Complete Design Suite (ACDS) or SoC EDS tool is
used to generate information required for the following dependent steps. See the table below
for a list of steps and associated tools:
Table 4. Boot Loader Generation Stages and Tools
Step 1: Compiling the FPGA Design
Step 2: Identifying the hardware hard processor system (HPS)
Step 3: Generating and building a boot loader source
SoC EDS tool chain and BSP Editor
The following figure depicts the complete boot loader generation flow using
Note: A similar flow is
available for a UEFI boot loader. Refer to the "Appendix A: Building a UEFI Boot Loader"
Prior to generating the boot loader, the HPS hand-off files are needed. The
hand-off files are created during "Step 1: Compiling the FPGA Design" and are saved
in the hps_isw_handoff folder.
The HPS hand-off files contain the FPGA hardware design information (as XML
files) and are used to generate the required boot loader device tree for proper FPGA
hardware initialization and run-time access.
Click on the link in the "Related Information" below that corresponds to the
type of external flash device you are using. Each of these links describe the steps
for generating a boot loader for a given boot source.
The BSP Editor tool provides you with guided options to configure and generate
a boot loader image. The BSP Editor tool is also used for editing an existing
generated boot loader by modifying the BSP configuration settings that are saved in
the settings.bsp file. The BSP Editor main
interface is shown below.
Figure 20. BSP Editor
The tool provides the configuration options that include selecting:
Associated HPS hand-off files
Target OS (both U-Boot or UEFI boot use the U-Boot OS selection)
U-Boot is the primary example covered in this user guide, using UEFI as a
second-stage boot loader source is also introduced. See "Appendix A:
Building the UEFI Boot Loader" for more information.
Locations for boot loader
Source and configuration settings (BSP settings).
These options are present whether creating a new or editing an existing boot
loader configuration. The figure below shows the settings for generating a new boot
Figure 21. BSP Settings for New Boot Loader Generation
When creating a new or editing an existing BSP, the BSP-Editor tool
provides the following selections:
directory: Location of the HW HPS hand-off files
Operating system: Target platform
boot loader (U-Boot or UEFI)
Version: Target platform
boot loader version (use default or recommended)
BSP target directory:
Location of generated BSP
BSP Settings File name:
Location of BSP settings file
Enable Additional Tcl Script:
Includes a Tcl script for additional custom settings
Additional Tcl script:
Location of additional Tcl script
After the initial configuration settings are entered, you can edit
the boot loader source device selection, the platform model selection, and the FPGA
configuration files and select whether to automatically build the boot loader after
generation. The BSP Editor window below shows an example configuration.
Figure 22. Example Configuration
The continued configuration selections in this window are:
boot_device: Selects the
target boot device for the generated boot loader
selected, the BSP will not be built (default)
Note: The boot_device configuration is selected in the HPS Qsys component and
should not be changed in the boot_device
pulldown of this window.
Generating a Boot Loader with an External Flash Boot Device
This section describes detailed steps to generate a bootable image for an
SD/MMC, QSPI and NAND flash controller.
For generating a boot loader with
and NAND boot flash, the following tools are required:
Arria® 10 SoC development
SD/MMC, QSPI or NAND boot flash daughter card
U-boot and Linux source code compatible with the
Arria® 10 SoC. The examples in this document use the U-boot
source code included with the SoC EDS installation.
Quartus® Prime 15.0 or later when using
the QSPI or SD/MMC as a boot source;
or later when using the NAND flash controller as a boot source
Quartus® Prime only support
the engineering sample (ES) of the
Arria® 10 SoC. To ensure that you have production device
support, install the latest version of
Quartus® Prime for the
Arria® 10 SoC.
FPGA design with proper pin configuration for SD/MMC, QSPI, or NAND flash
controller boot. Refer to the RocketBoards.org website for examples of the
Golden Hardware Reference Design (GHRD).
ARM® DS-5 development studio
version 5.20.2 or later or GNU debug package
During the boot process, the FPGA can be configured using the second-stage
boot loader. Alternatively, you can configure the FPGA through a non-HPS source such as a
external flash device or by using the
This section presents some techniques that can help with the debug of the
booting process. Considerations are included for Boot ROM and boot loader. The rest of the
boot flow is generic and can be debugged with general purpose techniques.
Cold Boot Debug
A cold boot is initiated by power cycling the board or by issuing a cold reset
Common signs of power-on boot issues are:
No signs of hardware activity (for example, no blinking
Inactive display console (for example, no UART output or no HPS
Interrupted and frozen boot software execution
Although executing the boot ROM is the first boot stage during power up or cold
boot, there are other hardware dependencies that must be examined to verify a
successful boot. Additionally, test measurement equipment, such as a logic analyzer
and oscilloscope can be used to check signal states and levels and monitor the
activity during the boot process. Verifying that the hardware platform is stable and
dependencies of the boot software are within specification ensures that the boot ROM
and boot loader are able to load and run.
Below is a sample of dependencies to check when verifying a successful
Check the board power source. Ensure that it is within
specification and there is not excessive noise present.
Verify the power sequencing is in order and all levels are
within specification for each stage.
Input clock must be verified for amplitude, frequency, noise and
Verify all reset signal are sequenced to the design
specification and levels.
Warm Boot Debug
Some possible causes of a warm debug issue:
The application software enabled the warm boot incorrectly.
The application software modified the warm reset options in a way
that is not consistent with the usage scenario.
The boot source used is not reset during a warm reset.
Using the Boot ROM and Boot Loader Debug Registers
If the HPS
executes the boot loader state, registers maintained by the boot ROM and boot loader
have been updated through the boot process. These registers provide useful status
and information and can be examined to help determine a possible cause of boot
The registers are available in the sysmgr.romcodegrp of the System
Manager. Below are the registers and descriptions:
initswstate – The boot loader writes the magic value 0x49535756
to the register prior to jumping to the next valid boot stage. If this value is
absent, it indicates the boot loader failed to execute the following boot
initswlastld – Contains the index of the last boot loader
software image loaded from the boot source device. Up to four boot loader images
can be loaded.
bootromswstate – Contains the boot ROM state information:
Bit: When this bit is set, it indicates there was a failure to load
all boot images.
Bit: When this bit is set, it indicates the boot loader started or
was running (and may have subsequently failed)
Bits[11:8] This field indicates the boot flash device:
Boot Flash Device Issues
If the HPS is
executing software, but the boot ROM fails to load the boot loader image, possible
causes could be that:
The boot loader images are corrupted in the boot device flash.
The boot loader images are valid but the boot flash device communication has
The boot loader image loads successfully, but runtime execution fails due to a
To help reduce flash device communication issues, set CSEL=0x0. This prevents
the boot ROM from reprogramming the PLLs and forces the boot ROM to use the lowest
communication speed with the device.
Flash memory signals should be monitored, if available, with proper test and
measurement equipment (logic analyzer or oscilloscope) to:
Determine if the duration of the communication is not within specification
Observe if the boot ROM communication is prematurely aborted
Verify signal integrity, such as voltage levels and rise and fall times
Capture (with a logic analyzer) HPS and flash device communication
If problems still persist and a debugger connection is available, then the contents
of the upper 4KB of on-chip RAM can be dumped from the debugger for
Altera® to analyze.
Compiling the UEFI Source Code with the Linaro Tool Chain
This section explains how to compile the UEFI source code with the Linaro tool
Open a terminal window and enter the following command:
$ cd /data/<username>/pggit/uefi-socfpga
$ make clean
Note:make clean deletes your entire
folder and also cleans the BaseTools.
Compile the UEFI boot loader for
Arria® 10 device using the following command. The build
process takes less than three minutes.
make is equivalent to make DEVICE=a10 COMPILER=gcc
After the build has completed, a Build Done message displays.
Compiling the UEFI Source Code with the ARM Tool Chain
This section explains how to compile the UEFI source code with the ARM
Open a terminal window and enter the following command:
$ cd /data/<username>/pggit/uefi-socfpga
$ make clean
Note:make clean deletes your entire
folder and also cleans the BaseTools.
Compile the UEFI boot loader.
$ make DEVICE=a10 COMPILER=gcc HANDOFF_DTB=a10_soc_devkit_ghrd_qspi/software/bootloader/devicetree.dtb
UEFI Generated Files
Compiling the UEFI source code creates the following files in the
Table 8. UEFI Generated Files
This file is generated from the mkpimage tool by adding a header
to the original file located at ~/uefisocfpga/
PART1.fd. The file loads directly into the
on-chip RAM using DS-5 because it is only 256 KB in size.
This file generates the PEI.ROM file.
/uefi-socfpga/Build/PEI.ROM (1MB = 256KB X 4)
This file is programmed onto the flash daughter card. The size of this
file is four times bigger because the the boot ROM can support up to
four backup images. For example, if the first image (256KB) is
corrupted, the boot ROM loads the second image and so on.
This is the DS-5 script template. It is imported
to the DS-5 tool and loads the UEFI firmware for debug and
development purposes. This script loads the debug symbols for the
user. Currently, it only supports the GCC compiler. ARMCC is not
This file is currently not in use. Reserved for