Intel Stratix 10 SoC FPGA Boot User Guide

RSS

UG-20101 | 2020.12.04

Version Information

Updated for:
Intel® Quartus® Prime Design Suite 20.2

1. Introduction

This user guide describes the Intel^® Stratix^® 10 SoC FPGA boot flow, boot sources, and how to generate a bitstream required for successful booting of the device. The details provided in this boot user guide include:

The typical boot flows and boot stages of the Intel^® Stratix^® 10 SoC FPGA.
The supported system layout for different hard processor system (HPS) boot modes.
How to use Intel^® Quartus^® Prime Pro Edition to generate the configuration bitstream.
Examples of how to generate the HPS first-stage boot loader (FSBL) and second stage boot loader (SSBL).

1.1. Glossary

Table 1. Intel^® Stratix^® 10 SoC FPGA Boot Glossary
Term	Definition
EMIF	External memory interface
*.pof	Programming object file; contains data to configure the FPGA portion of the SoC and additionally, may contain the HPS first-stage payload. This file is typically stored in external flash such as quad serial peripheral interface (Quad SPI) or common flash interface (CFI) flash.
FW	Firmware; Controls and monitors software stored in Secure Device Manager's (SDM) read-only memory.
HPS	Hard Processor System; the SoC portion of the device, consisting of a quad core Arm* Cortex-A53 processor, hard IPs, and HPS I/Os in the Intel^® Stratix^® 10 SoC FPGA.
HPS EMIF I/O section	Part of the raw binary file (*.rbf) that configures the EMIF I/O used by the HPS
FPGA I/O section	Part of the *.rbf that configures the I/O assigned to the FPGA core
Core *.rbf	Core raw binary file; FPGA core image file that includes logic array blocks (LABs), digital signal processing (DSP), and embedded memory. The core image consists of a single reconfigurable region, or both static and reconfigurable regions.
FSBL	First-stage Boot Loader for HPS
*.jic	JTAG Indirect Configuration file that allows programming through JTAG
OS	Operating system
*.rbf	Raw binary file representing the FPGA bitstream
*.rpd	Raw Programming Data file for AS devices
*.sof	SRAM object file which contains the bitstream for the primary FPGA design. Firmware is not part of the *.sof.
SSBL	Second-stage Boot Loader for HPS
SDM	Secure Device Manager; a triple-redundant processor-based block that manages FPGA configuration and hard processor system (HPS) secure boot process in Intel^® Stratix^® 10 devices.

1.2. Prerequisites

Intel^® Quartus^® Prime Pro Edition version 19.3 or later
Intel^® SoC FPGA Embedded Development Suite (SoC EDS) version 19.3 or later
Note: The versions of Intel^® Quartus^® Prime Pro Edition and SoC EDS must match.
Arm* Development Studio 5* Intel^® SoC FPGA Edition version 5.28 or later

1.3. Intel Stratix 10 SoC FPGA Boot Overview

The Intel^® Stratix^® 10 SoC FPGA combines an FPGA with a hard processor system (HPS) that is capable of booting Bare Metal applications or operating systems such as Linux*.

When booting the device from a power-on reset, you can choose between two different methods of booting:

FPGA Configuration First Mode—When you select the FPGA First option, the SDM fully configures the FPGA, then configures the HPS SDRAM pins, loads the HPS first-stage boot loader (FSBL) and takes the HPS out of reset.
Note: The FPGA and all of the I/Os are fully configured before the HPS is released from reset. Thus, when the HPS boots, the FPGA is in user mode and is ready to interact with the HPS. Optionally, the SDM can hold the HPS in reset until instructed by the user. To release the HPS from reset, you can use soft IP such as a mailbox client to send a mailbox request to the SDM.
HPS Boot First Mode—When you select the HPS First option, the SDM first configures the HPS SDRAM pins, loads the HPS FSBL and takes the HPS out of reset. Then the HPS configures the FPGA I/O and FPGA fabric at a later time.
Note: This mode is also referred to as Early I/O Release Mode or Early I/O Configuration. After power-on, the device configures a minimal amount of I/O required by the HPS before releasing the HPS from reset. This mode allows the HPS to boot quickly without having to wait for the full configuration to complete. Subsequently, the HPS may trigger an FPGA configuration request during the SSBL or OS stage.

2. FPGA Configuration First Mode

2.1. Boot Flow Overview for FPGA Configuration First Mode

You can program the Intel Stratix 10 SoC device to configure the FPGA first and then boot the HPS. The available configuration data sources configure the FPGA core and periphery first in this mode. After completion, you may optionally boot the HPS. All of the I/O, including the HPS-allocated I/O, are configured and brought out of tri-state. If the HPS is not booted:

The HPS is held in reset.
HPS-dedicated I/O are held in reset.
HPS-allocated I/O are driven with reset values from the HPS.

If the FPGA is configured before the HPS boots, the boot flow looks like the example figure below. The flow includes the time from power-on-reset (T_POR) to boot completion (T_{Boot_Complete}).

Figure 1. Typical FPGA Configuration First Boot Flow

Table 2. FPGA Configuration First StagesThe sections following this table describe each stage in more detail.
Time	Boot Stage	Device State
T_POR to T₁	POR	Power-on reset
T₁ to T₂	Secure Device Manager (SDM)- Boot ROM	SDM samples the `MSEL` pins to determine the configuration scheme and boot source. SDM establishes the device security level based on eFuse values. SDM initializes the device by reading the configuration firmware (initial part of the bitstream) from the boot source. SDM authenticates and decrypts the configuration firmware (this process occurs as necessary throughout the configuration). SDM starts executing the configuration firmware.
T₂ to T₃	SDM- configuration firmware	SDM I/O are enabled. SDM configures the FPGA I/O and core (full configuration) and enables the rest of your configured SDM I/O. SDM loads the FSBL from the bitstream into HPS on-chip RAM. SDM enables HPS SDRAM I/O and optionally enables HPS debug. FPGA is in user mode. HPS is released from reset. CPU1-CPU3 are in a wait-for-interrupt (WFI) state.
T₃ to T₄	First-Stage Boot Loader (FSBL)	HPS verifies the FPGA is in user mode. The FSBL initializes the HPS, including the SDRAM. HPS loads SSBL into SDRAM. HPS peripheral I/O pin mux and buffers are configured. Clocks, resets, and bridges are also configured. HPS I/O peripherals are available.
T₄ to T₅	Second-Stage Boot Loader (SSBL)	HPS bootstrap completes. OS is loaded into SDRAM.
T₅ to T_{Boot_Complete}	Operating System (OS)	The OS boots and applications are scheduled for runtime launch.

Note: The location of the source files for configuration, FSBL, SSBL, and OS can vary and are described in the System Layout for FPGA Configuration First Mode section.

2.1.1. Power-On Reset (POR)

Ensure you power each of the power rails according to the power sequencing consideration until they reach the required voltage levels. In addition, the power-up sequence must meet either the standard or the fast power-on reset (POR) delay time.

2.1.2. Secure Device Manager

Once the Intel Stratix 10 SoC FPGA exits POR, the SDM samples the MSEL[2:0] pins¹ to determine the boot source. Next, the device configures the SDM I/Os according to the selected boot source interface and the SDM retrieves the configuration bitstream through the interface. SDM can boot from the following boot sources listed in the following table.

Table 3. Available SDM Boot Sources for the Intel Stratix 10 SoC FPGA
SDM Boot Source	Details
Avalon-ST (x8/x16/x32)	Supported
JTAG	Supported
Active Serial (AS)/ Quad SPI	Supported. SDM only boots in x4 mode for active serial flash and Micron* MT25Q flash. Other serial flash discoverable parameters (SFDP) JEDEC-compliant flash boot in x1 mode. After the configuration firmware loads into the SDM, the SDM can switch the flash into x4 mode.

The typical configuration bitstream for FPGA configuration first contains:

Configuration firmware for the SDM
FPGA I/O and HPS external memory interface (EMIF) I/O configuration data
FPGA core configuration data
HPS FSBL code and FSBL hardware handoff binary data

The SDM completes the configuration of the FPGA core and I/O, and then copies the HPS FSBL code and HPS FSBL hardware handoff binary to the HPS on-chip RAM.

¹ The MSEL[2:0] pins are multiplexed with the SDM_IO[9], SDM_IO[7], SDM_IO[5] pins respectively.

2.1.3. First-Stage Boot Loader

The first-stage boot loader (FSBL) is the first boot stage for the HPS. In FPGA Configuration First mode, the SDM extracts and loads the FSBL into the on-chip RAM of the HPS. The SDM releases the HPS from reset after the FPGA has entered user mode. After the HPS exits reset, it uses the FSBL hardware handoff file to setup the clocks, HPS dedicated I/Os, and peripherals. Typically, the FSBL then loads the SSBL into HPS SDRAM and passes the control to the SSBL.

Note: The SDM can optionally hold the HPS in reset until instructed by the user. Refer to the Compiling the SRAM Object File section to enable this setting.

You can create the FSBL from one of the following sources:

U-Boot secondary program loader (SPL)
- Intel provides the source code for U-Boot SPL on the public git repository.
Arm* Trusted Firmware
- Intel provides the source code for the Arm* Trusted Firmware on public git.
Real-time operating system (RTOS)
Bare Metal application

The steps to generate, update, and integrate the HPS FSBL into the configuration bitstream are discussed in the Bitstream Creation and Programming Overview section.

2.1.4. Second-Stage Boot Loader

The second-stage boot loader (SSBL) is the second boot stage for the HPS. The FSBL initiates the copy of the SSBL to the HPS SDRAM. The SSBL typically enables more advanced peripherals such as Ethernet and supports command line interface.

You can create the SSBL from one of the following sources:

U-Boot
- Intel provides the source code for U-Boot SSBL on the public git repository.
UEFI
- Intel provides the source code for UEFI SSBL on public git.
RTOS
Bare Metal application

Intel provides the U-boot source code for the Intel^® Stratix^® 10 HPS SSBL on the Intel^® public git repository.

2.1.5. Operating System

Typically, the SSBL loads the operating system (OS) stage into SDRAM. The OS executes from SDRAM. Depending on your application requirements, you may implement a conventional OS or an RTOS.

Intel provides an example of the Intel^® Stratix^® 10 SoC Linux kernel and Ångström recipe that is available on the Intel^® public git repository. Refer to the Generating the Linux Kernel Image section for more information.

2.1.63.1.6. Application

The application that runs on the OS is the last boot stage. The application can also replace the OS stage as a dedicated, Bare Metal runtime code.

2.2. System Layout for FPGA Configuration First Mode

The following sections describe the supported system layout for FPGA Configuration First mode. The OS is assumed to be Linux* in the following examples, but you may replace Linux* with other supported operating systems.

2.2.1. External Configuration Host Only

Figure 2. External Configuration Host Only

In this example, the external configuration host ( Avalon^® streaming or JTAG) provides the SDM with a configuration bitstream that consist of:

SDM configuration firmware
FPGA I/O and HPS EMIF I/O configuration data
FPGA core configuration data
HPS FSBL code and HPS FSBL hardware handoff binary

Because the HPS SSBL (or subsequent OS files) is not part of the bitstream, the HPS can only boot up to the FSBL stage. This setup is applicable if you are using the FSBL to run simple applications (for example, Bare Metal applications).

You can use the FSBL to retrieve the SSBL from other sources, such as through the HPS Ethernet MAC interface. To implement these modes of access, you must create a working Ethernet software stack in the FSBL.

Table 4. Supported Configuration Boot and SSBL Source
SDM Configuration Host	SSBL Source	Details
Avalon^® streaming	HPS Ethernet	Not supported in U-Boot FSBL code provided by Intel.
JTAG	HPS Ethernet	Not supported in U-Boot FSBL code provided by Intel.

2.2.2. External Configuration Host with HPS Flash

Figure 3. External Configuration Host with HPS Flash

An external configuration host with HPS flash provides an SDM configuration bitstream containing:

SDM configuration firmware
FPGA I/O and HPS EMIF I/O configuration data
FPGA core configuration data
HPS FSBL code and HPS FSBL hardware handoff binary

In this system layout, you can use the HPS flash to store the HPS SSBL, Linux* image device tree information and OS file system. This layout enables the device to boot into an OS such as Linux*.

Table 5. Supported Configuration Boot Source and HPS Flash Combinations
SDM Configuration Host	HPS Flash	Details
Avalon^® streaming	SD/MMC	Pre-built HPS SD image (for booting the SSBL and OS) and *.sof (for JTAG Programming) are included in the SoC EDS.
JTAG	SD/MMC
Avalon^® streaming	NAND
JTAG	NAND

2.2.3. Single SDM Flash

In a single flash attached to SDM layout, the flash contains all of the files required for booting, including the configuration bitstream and OS files.

Table 6. Single SDM Flash Sources
SDM Flash Type	Details
Active serial/Quad SPI	Refer to the Intel Stratix 10 SoC Single QSPI Flash Boot example on RocketBoards. Note: When you use the HPS to access the SDM Quad SPI, the speed access is reduced due to the additional delays between the path from the HPS to SDM.

Software running on the HPS such as the FSBL) must request permission from the SDM to access the flash attached to the SDM.

In the Quad SPI flash example, the SSBL, OS and file system reside in the Unsorted Block Image File System (UBIFS).

Figure 4. FPGA Configuration First Layout with Quad SPI

Note: Due to a problem in the Intel^® Quartus^® Prime Pro Edition Software, if you specify the HPS boot from FPGA parameter on the FPGA Interfaces tab of the Intel^® Stratix^® 10 Hard Processor System Intel^® Stratix^® 10 FPGA IP GUI, this information has no effect on HPS behavior. For more information about this problem refer to the following article Why does the HPS Boot source in the Hard Processor System Intel^® Stratix^® 10 FPGA IP not change where the HPS looks for the second stage boot loader?

2.2.4. FPGA Configuration First Dual Flash System

In a dual flash system, the SDM flash (for example, active serial flash) stores the configuration bitstream, while the HPS flash (for example, an SD card) stores the HPS SSBL and the rest of the OS files.

Table 7. Dual SDM and HPS Flash Combinations
SDM Flash Type	HPS Flash Type	Details
Active serial/Quad SPI	SD/MMC	Refer to the Intel Stratix 10 GSRD on RocketBoards website for implementation support.
Active serial/Quad SPI	NAND

Figure 5. FPGA Configuration First Dual SDM and HPS Flash

3. HPS Boot First Mode

3.1. Boot Flow Overview

You can boot the HPS and HPS EMIF I/O first before configuring the FPGA core and periphery. The MSEL[2:0] settings determine the source for booting the HPS. In this mode, any of the I/O allocated to the FPGA remain tri-stated while the HPS is booting. The HPS can subsequently request the SDM to configure the FPGA core and periphery, excluding the HPS EMIF I/O. Software determines the configuration source for the FPGA core and periphery. In HPS First Boot mode, you have the option of configuring the FPGA core during the SSBL stage or after the operating system boots.

Note: Configuring the HPS EMIF I/O for the first time and then loading the HPS FSBL is called "Phase 1 configuration". The subsequent configuration of FPGA core and periphery by HPS is called "Phase 2 configuration". The phase 1 and phase 2 configuration files must be generated from the same Intel^® Quartus^® Prime Pro Edition software version, this includes patches installed if applicable.

A typical HPS First Boot flow may look like the following figure. You can use U-Boot, Unified Extensible Firmware Interface (UEFI), or a custom boot loader for your FSBL or SSBL. An example of an OS is Linux or an RTOS. The flow includes the time from power-on-reset (T_POR) to boot completion (T_{Boot_Complete}).

Figure 6. Typical HPS Boot First Flow

Table 8. HPS Boot First Stages
Time	Boot Stage	Device State
T_POR	POR	Power-on reset
T₁ to T₂	SDM- Boot ROM	SDM samples the `MSEL` pins to determine the configuration and boot source. It also establishes the device security level based on eFuse values. SDM firmware initializes the device. SDM authenticates and decrypts the bitstream (this process occurs as necessary throughout the configuration).
T₂ to T₃	SDM- Configuration Firmware	SDM configures the HPS EMIF I/O and the rest of the user-configured SDM I/O. SDM loads the FSBL from the bitstream into HPS on-chip RAM. SDM enables HPS SDRAM I/O and optionally enables HPS debug. HPS is released from reset.
T₃ to T₄	FSBL	The FSBL initializes the HPS, including the SDRAM. FSBL obtains the SSBL from HPS flash or by requesting flash access from the SDM. FSBL loads the SSBL into SDRAM. HPS peripheral I/O pin multiplexer and buffers are configured. Clocks, resets and bridges are also configured. HPS I/O peripherals are available. HPS bootstrap completes.
T₄ to T₅	SSBL	After bootstrap completes, any of the following steps may occur: The FPGA core configuration loads into SDRAM from one of the following sources: SDM flash HPS alternate flash EMAC interface HPS requests that the SDM configure the FPGA core.² FPGA enters user mode. OS is loaded into SDRAM.
T₅ to T_{Boot_Complete}	OS	OS boot occurs and the OS schedules applications for runtime launch. (Optional step)The OS initiates FPGA configuration through a secure monitor call (SMC) to the resident SMC handler (typically SSBL), which then initiates the request to the SDM.

Note: The location of the source files for configuration, FSBL, SSBL and OS can vary. For more information, refer to the System Layout for HPS Boot First Mode section.

Note: To avoid configuration failures, the Intel^® Stratix^® 10 device requires clocks for the PCIe* and all E-tile transceiver reference clocks. You must provide the input reference clock, refclk, and it must be free-running and stable at device power up for a successful device configuration.

L- and H-tile (does not apply to E-tile)—the refclk requirement is mandatory if you are configuring your Intel^® Stratix^® 10 device over a PCIe* link; otherwise the refclk requirement is not mandatory for a non PCIe* use case.

For PCIe* use case, the firmware waits for the PLL calibration code to ensure the PLL is calibrated properly in order to release the device for entering into user mode. Therefore, refclk is mandatory for PLL calibration.
For non PCIe* use case, without refclk supply during configuration, the firmware does not gate device configuration without a proper PLL calibration code. You can calibrate the XCVR PLL in user mode for XCVR channels to operate properly.

E-tile (does not apply to L- and H-tile)—the refclk requirement is mandatory. E-tile does not support the PCIe* use case.

The refclk is needed for the SPICO controller to load the firmware (this is part of configuration bit stream) into E-tile.

² FPGA I/O and FPGA core configuration can occur at the SSBL or OS stage, but is typically configured during the SSBL stage.

3.1.1. Power-On Reset (POR)

3.1.2. Secure Device Manager

After the Intel Stratix 10 SoC FPGA exits POR, the SDM samples the MSEL[2:0] pins to determine the boot source. Next, the device configures the SDM I/Os according to the selected boot source interface and the SDM retrieves the configuration bitstream through the interface.

Table 9. Available SDM Boot Sources for the Intel Stratix 10 SoC FPGA
SDM Boot Source	Details
Avalon-ST (x8/x16/x32)	Supported
JTAG	Supported
Active Serial (AS)/ Quad SPI	Supported. SDM only boots in x4 mode for active serial flash and Micron* MT25Q flash. Other serial flash discoverable parameters (SFDP) JEDEC-compliant flash devices boot in x1 mode. Once the device initialization code loads into the SDM, the SDM can switch these flash into x4 mode.

The typical configuration bitstream for HPS boot first mode contains:

SDM configuration firmware
HPS external memory interface (EMIF) I/O configuration data
HPS FSBL code and HPS FSBL hardware handoff binary

The SDM completes the configuration of the HPS EMIF I/O and then copies the HPS FSBL to the HPS on-chip RAM.

3.1.3. First-Stage Boot Loader

After the SDM releases the HPS from reset, the FSBL initializes the HPS. Initialization includes configuring clocks, HPS dedicated I/Os, and peripherals.

Note: In HPS first boot mode, the SDM, HPS OSC and HPS EMIF clocks must be running stable and set at the correct frequency before you begin any part of the configuration sequence.

In HPS first boot mode, phase 1 configuration is successful as long as HPS OSC and HPS EMIF clocks are running stable.

For a generic transceiver use case, if the XCVR ref clock is not running during phase 2 configuration, the phase 2 configuration still succeeds.

For a PCIe use case, if the PCIe ref clock is not running during phase 2 configuration, the configuration fails.

You can create the FSBL from one of the following sources:

U-Boot secondary program loader (SPL)
- Intel^® provides the source code for U-Boot SSBL on the public git repository.
Arm* Trusted Firmware
- Intel provides the source code for the Arm* Trusted Firmware FSBL on the public git.
Real-time operating system (RTOS)
Bare Metal application

The latest source code is also available on the Intel public git repository.

The Bitstream Creation and Programming Overview section describes the steps to generate, update and integrate the HPS FSBL into the configuration bitstream.

3.1.4. Second-Stage Boot Loader

The second-stage boot loader (SSBL) is the second boot stage for the HPS. The FSBL initiates the copy of the SSBL to the HPS SDRAM. The SSBL typically enables more advance peripherals such as Ethernet and supports the command line interface.

You can create the HPS SSBL from one of the following sources:

U-Boot
- Intel provides the source code for U-Boot SSBL the public git repository.
UEFI
- Intel provides the source code for UEFI SSBL on public git.
RTOS
Bare Metal application

Intel provides the U-boot source code for the Intel^® Stratix^® 10 HPS SSBL on the Intel^® public git repository.

You can optionally perform FPGA core and I/O configuration in during the SSBL stage. The SSBL copies the FPGA configuration files from one of the following sources to the HPS SDRAM:

HPS Flash
SDM Flash
External host via the HPS Ethernet (for example, TFTP)

After the SSBL copies the FPGA configuration files to the HPS SDRAM, the SSBL can initiate a configuration request to the SDM to begin the configuration process. Refer to the Configuring the FPGA from SSBL and OS section for more details.

3.1.5. Operating System

The SSBL loads the operating system (OS) stage into SDRAM. The OS executes from SDRAM. Depending on your application requirements you may implement a conventional OS or an RTOS.

2.1.63.1.6. Application

The application that runs on the OS is the last boot stage. The application can also replace the OS stage as a dedicated, Bare Metal runtime code.

3.2. System Layout for HPS Boot First Mode

3.2.1. External Configuration Host Only

Figure 7. External Configuration Host Only

In this example, the external configuration host ( Avalon^® Streaming or JTAG) provides the SDM a configuration bitstream that consists of the following components:

SDM configuration firmware
HPS EMIF I/O configuration data
HPS FSBL code and HPS FSBL hardware handoff binary

However, because the HPS SSBL or subsequent OS files are not part of the bitstream, the HPS can only boot up to the FSBL stage. This setup is applicable if you are using the FSBL to run simple applications such as Bare Metal applications.

Because the FPGA core is not configured, the FSBL must retrieve the SSBL from external sources, such as the HPS EMAC interface. The U-Boot FSBL source code that is generated through the SoC EDS does not include source code to support SSBL retrieval through the HPS EMAC interface. You must implement the Ethernet software stack in the FSBL separately. Similarly, after the SSBL loads, the SSBL must retrieve the FPGA core and I/O configuration file from an external source as well.

Table 10. Supported Configuration Boot and SSBL Sources
SDM Configuration Host	SSBL Source	Details
Avalon^® streaming	HPS Ethernet	Not supported in U-Boot FSBL code that Intel provides.
JTAG	HPS Ethernet	Not supported in U-Boot FSBL code that Intel provides.
SDM Configuration Host	Details
Avalon^® streaming	Supported in a future version of the SoC EDS.
JTAG	Supported in a future version of the SoC EDS.

3.2.2. External Configuration Host with HPS Flash

Figure 8. External Configuration Host with HPS Flash

An external configuration host provides an SDM configuration bitstream containing the following components:

SDM configuration firmware
HPS EMIF I/O configuration data
HPS FSBL code and HPS FSBL hardware handoff binary

In this system layout, the HPS flash such as an SD card, contains the HPS SSBL, Linux* image device tree information, and the OS file system.

Depending on the boot stage that performs the FPGA configuration, you have the following options for storing the FPGA core and I/O configuration file:

In the HPS flash partition—The SSBL initiates configuration.
In the OS file system—The OS initiates configuration

Table 11. Supported Configuration Boot Source and HPS Flash Combinations
SDM Configuration Host	HPS Flash	Details
Avalon^® streaming	SD/MMC	Not supported in Intel Stratix 10 GSRD. You must recompile your design with the HPS Boot First Option in Intel^® Quartus^® Prime Pro Edition and manually store their FPGA configuration file in the HPS SD/MMC.
JTAG	SD/MMC
Avalon^® streaming	NAND
JTAG	NAND

3.2.3. Single SDM Flash

In a single flash attached to SDM layout, the flash contains all of the files required for booting, including the configuration bitstream and the OS files.

Depending on the boot stage that performs the FPGA configuration, you have the following options for storing the FPGA core and I/O configuration file:

An SDM flash storage partition—In this case the SSBL initiates configuration
In the OS file system—In this case the OS initiates configuration

Table 12. Supported Single SDM Flash Sources
SDM Flash Type	Details
Active serial/Quad SPI	Not supported in Intel Stratix 10 GSRD. You must recompile your design with the HPS First option in Intel^® Quartus^® Prime Pro Edition and manually create the flash image for SDM Quad SPI. Refer to the Creating the *.jic File for System Layout with a Single SDM Flash for more information.

In order for the software running in the HPS (for example, the FSBL and SSBL) to access the flash attached to the SDM, it must request permission from the SDM.

In the Quad SPI flash example, the SSBL, OS and file system reside in the Unsorted Block Image File System (UBIFS).

Figure 9. HPS Boot First Layout with Quad SPI

3.2.4. HPS Boot First Dual Flash System

In a dual flash system, the SDM flash such as an active serial flash stores the configuration bitstream. The HPS flash such as an SD card stores the HPS SSBL and the rest of the OS files.

Table 13. Supported Dual SDM and HPS Flash Combinations
SDM Flash Type	HPS Flash Type	Details
Active serial/Quad SPI	SD/MMC	Not supported in Intel Stratix 10 GSRD. You must recompile your design with the HPS First Option in Intel^® Quartus^® Prime and manually update the SDM Quad SPI flash image and the HPS SD card.
Active serial/Quad SPI	NAND

Depending on the boot stage that performs the FPGA configuration, you have the following options for storing the FPGA core and I/O configuration file:

In the HPS flash partition—The SSBL initiates configuration.
In the OS file system—The OS initiates configuration

Figure 10. HPS Boot First Dual SDM and HPS Flash

4. Creating a Configuration Bitstream for Intel Stratix 10 SoC FPGA

4.1. Bitstream Creation and Programming Overview

This section describes how to create the configuration bitstream for Intel^® Stratix^® 10 FPGA and the steps to write the resulting files to memory. Steps listed in this section apply to both the FPGA Configuration First mode and HPS Boot First mode unless explicitly mentioned.

Figure 11. Bitstream Creation and Programming Overview

The numbers in the figure correspond to the following sections:

4.2. Compiling the SRAM Object File

Create an Intel^® Quartus^® Prime Pro Edition project that uses the HPS component in the Platform Designer tool. If you are using the Intel^® Stratix^® 10 SoC development kit, you can navigate to the Intel^® Stratix^® 10 SoC Golden Hardware Reference Design (GHRD) project that is preinstalled with the SoC EDS. The default path for the GHRD project is shown below.
On Windows:
```
c:\intelFPGA_pro\19.3\embedded\examples\hardware\s10_soc_devkit_ghrd
```
On Linux:
```
~/intelFPGA_pro/19.3/embedded/hardware/s10_soc_devkit_ghrd
```
Ensure that the HPS dedicated I/O and clock settings are set correctly in the HPS component within the Platform Designer tool. These settings are part of the HPS handoff data that the HPS FSBL consumes.
1. Configure the HPS clock settings in the HPS Clocks and resets tab.
  
  Figure 12. Configure HPS Clock Settings
2. Update the pin multiplexing configuration in the Pin Mux and Peripherals tab.
  
  Figure 13. Configure Pin Multiplexing
Save your settings and run Generate HDL... in Platform Designer to complete the HPS component instantiation process before returning to the main Intel^® Quartus^® Prime Pro Edition.
Open the project in Intel^® Quartus^® Prime Pro Edition and go to Assignments > Device > Device and Pin Options.
Specify the boot mode through the HPS/FPGA configuration order pulldown in the Configuration project category.
- After INIT_DONE: This option selects FPGA Configuration First. The SDM configures the FPGA core and all the periphery I/O before loading the FSBL into the HPS on-chip RAM and releasing the HPS from reset. If any errors exist during initial configuration, the HPS is not released from reset.
- HPS First: This option selects HPS Boot First. The SDM only configures the I/O required for the HPS SDRAM, and then loads the FSBL into the HPS on-chip RAM before releasing the HPS from reset. The FPGA core and the other unused I/O, remain unconfigured.
- When requested by FPGA: This option is similar to FPGA Configuration First, except that the SDM does not release the HPS from reset. You can implement an IP in the FPGA, or use the mailbox client IP, in order to initiate the request to SDM to release the HPS from reset.
When you select HPS First or After INIT_DONE, you must ensure that the Use configuration device option is unchecked. The Intel^® Quartus^® Prime software includes the FSBL in the configuration bitstream. the bitstream generates.

Figure 14. Configuration Scheme and Boot Mode Selection
After you complete your design, run the Start Compilation option. After the compilation is complete, the output files, including the *.sof, are available in the <Project_Directory>/output_files folder.

Note: If you are using the GHRD project, the pre-built *.sof file found in the output_files sub-directory is named ghrd_1sx280lu2f50e2vg.sof.

4.3. Compiling the First Stage Boot Loader (FSBL) and the Second Stage Boot Loader (SSBL)

4.3.1. Compiling U-Boot FSBL and SSBL

For the latest U-Boot FSBL and SSBL compilation information, always refer to the Rocketboards.org website.

You can only compile the Intel^® Stratix^® 10 SoC FPGA U-Boot in Linux*. To begin, follow the steps below.

Note: These steps are tested in Ubuntu 16.04 LTS and may not be similar when used in other Linux* distributions.

Launch the SoC EDS command shell.

<SoC_FPGA_EDS installation directory>/embedded_command_shell.sh.

Download and extract the Linaro* toolchain and configure the environment.

$ wget https://releases.linaro.org/components/toolchain/binaries/7.2-2017.11/aarch64-linux-gnu/gcc-linaro-7.2.1-2017.11-x86_64_aarch64-linux-gnu.tar.xz 

$ tar xf gcc-linaro-7.2.1-2017.11-x86_64_aarch64-linux-gnu.tar.xz 

$ export PATH=$PWD/gcc-linaro-7.2.1-2017.11-x86_64_aarch64-linux-gnu/bin/:$PATH

$ export CROSS_COMPILE=aarch64-linux-gnu- 

$ export ARCH=arm64

Obtain the U-Boot source code from the Intel GitHub repository using one of the following methods.
- Get current release of U-Boot by using the current GSRD tag:
```
$ git clone https://github.com/altera-opensource/u-boot-socfpga
$ cd u-boot-socfpga 
$ git checkout -b test ACDS19.3_REL_GSRD_PR 
$ cd .. 
```
- Get the latest version of U-Boot that was upstreamed to git on the current development branch:
```
$ git clone https://github.com/altera-opensource/u-boot-socfpga 
$ cd u-boot-socfpga 
$ git checkout -t -b test origin/socfpga_v2019.04 
```
Note: This version may include newer functionality that may not be fully compatible with the rest of the components.

Note: Intel policy specifies that only the current and immediately previous U-Boot and Linux branches are available on GitHub. As Intel makes a new branch available, Intel removes the oldest branch. You must keep a local copy of the sources used to build your binaries if you need to reproduce the build or make changes in the future.
If needed, update the settings for console, environment and configurations within U-Boot by editing the configuration header file at include/configs/stratix10_socdk.h. Save the file after you complete your edits.

Build U-Boot. In the u-boot-socfpga folder, run make:

$ cd u-boot-socfpga

$ make mrproper

$ make socfpga_stratix10_defconfig

$ make

Successful compilation creates key U-Boot FSBL and SSBL files in the uboot-socfpga directory.

File	Description
u-boot.elf	U-Boot SSBL ELF file
u-boot\.img	U-Boot SSBL image file
spl\u-boot-spl-dtb.bin	U-Boot FSBL binary file
`spl\u-boot-spl-dtb.hex`	U-Boot FSBL hex file

4.3.2. Compiling the Arm Trusted Firmware FSBL and UEFI SSBL

As an alternative to U-boot, you can use the Arm* Trusted Firmware for FSBL, followed by UEFI as the SSBL. Intel provides the source code for both the Arm* Trusted Firmware and UEFI on the public git repository. Follow the steps listed in the Intel Stratix 10 SoC UEFI Boot Loader User Guide in order to generate the FSBL and SSBL files required for your system.

4.4. Creating the *.sof and Handoff and FSBL File

After you have both the *.sof file from the Intel^® Quartus^® Prime Pro Edition compilation, and the FSBL *.hex file, you can use the Intel^® Quartus^® Prime Pro EditionProgramming File Generator (quartus_pfg) to merge these two files. The tool creates a single *.sof file that includes both the hardware design information and the FSBL content.

The bitstream section that contains the HPS FSBL full image is shown below.

Figure 15. HPS FSBL Full Image Components

During full compilation, the Intel^® Quartus^® Prime Pro Edition generates the data in the HPS FSBL handoff binary based on the settings inside the Platform Designer. The file contains information on:

HPS pin multiplexing configuration, including HPS dedicated I/O settings and export to FPGA settings
HPS clock configuration
HPS SSBL boot source

During configuration, the SDM copies the entire HPS FSBL image into the HPS on-chip memory. When the HPS FSBL runs , it uses the information on the HPS FSBL handoff binary to set up the hardware.

To merge the *.sof file and the HPS FSBL *.hex file, type the following quartus_pfg command:

$ quartus_pfg -c -o hps_path=<hex_file> <input_sof> <output_sof>

Table 14. Merging the .hex and .sof Files
File	Input or Output	Description
`.hex`	Input	The FSBL `.hex`.
`input.sof`	Input	The existing `.sof`.
`output.sof`	Output	The final .sof containing the first-stage boot image. If you compile a new FSBL .hex, you can re-run the command to overwrite the existing FSBL image in the output *.sof file.

The Intel^® Quartus^® Prime Pro Edition can also use this merged file to program the Intel^® Stratix^® 10 SoC FPGA using JTAG. Using JTAG enables you to test your design quickly without having to write to the SDM Flash first. After programming is successful, the HPS runs the embedded FSBL code.

Note: If you are using the GHRD, the prebuilt *.sof , handoff binary data, and FSBL file is ghrd_1sx280lu2f50e2vg_hps.sof.

4.5. Creating the Raw Binary File (*.rbf) for FPGA Configuration

You can use the *.rbf with a third-party programmer, Configuration via Protocol (CvP), configuration via Avalon^® Streaming, or the HPS to initiate the FPGA programming.

To create the *.rbf file, type the Intel^® Quartus^® Prime Pro Edition Programming File Generator command as shown below:

$ quartus_pfg -c <input_sof> <output_rbf>

For example, if you are using the GHRD output ghrd_1sx280lu2f50e2vg_hps.sof, the command is:

$ quartus_pfg -c  ghrd_1sx280lu2f50e2vg_hps.sof ghrd_1sx280lu2f50e2vg_hps.rbf

For HPS Boot First mode you can store the .rbf files which contain the FPGA core and I/O configuration in external storage such as a TFTP server or a USB device. The HPS retrieves these files and initiates the FPGA configuration during the boot process. To generate the .rbf files, you must add the hps option as shown below:

$  quartus_pfg -c -o hps=on <input_sof> <output_rbf>

Adding the hps=on option generates two *.rbfs.

Note: You can also use the -option (abbreviated -o) option to provide a list of key-value pairs to provide additional arguments such as the configuration device or flash loader.

Table 15. Generated *.rbf Using hps=on Option
File Name	Description
ghrd_1sx280lu2f50e2vg_hps.core.rbf	This *.rbf contains the FPGA core and I/O configuration file. Depending on your system layout, you may store this file in the SDM Flash, HPS Flash, or external storage such as a TFTP server.
ghrd_1sx280lu2f50e2vg_hps.hps.rbf	The *.rbf contains the initial bitstream to set the HPS EMIF I/O and HPS FSBL. The external configuration host can perform the initial configuration of the device using this file.

Refer to the Configuring the FPGA from SSBL and OS section for more information on using the HPS to initiate FPGA configuration.

4.6. Creating the Raw Programming Data (*.rpd) File For Flash Programming

You can use the quartus_pfg tool to generate a raw programming data File (*.rpd) for flash programming with a third-party programming tool. Alternatively, you can use the U-Boot software running in the HPS to program the SDM flash device.

You can create the *.rpd file during *.jic file creation or directly from the *.sof file.

Note: If you are using the *.rpd in the GHRD, the pre-built *.rpd file name is ghrd_1sx280lu2f50e2vg_hps_auto.rpd.

Generating the .rpd File During .jic Creation

You can generate the *.rpd file while creating a *.jic file by adding the auto_create_rpd=on command line option.

quartus_pfg -c -o device=MT25QU02G -o flash_loader=1SX280LU2 -o mode=ASX4 \ 
ghrd_1sx280lu2f50e2vg_hps.sof ghrd_1sx280lu2f50e2vg_hps.jic \ 
ghrd_1sx280lu2f50e2vg_hps.rpd

If you are using the GUI option in Intel^® Quartus^® Prime Pro Edition to generate the *.rpd file, you can set the bit-level endianness of the *.rpd file from the Options/Boot Info... selection.

In the example above, the resultant *.rpd file is named ghrd_1sx280lu2f50e2vg_hps_auto.rpd. This file contains only the relevant content from the design, and does not necessarily have a file size equal to the size of the flash device.

Generating the .rpd File from the .sof File

You can create an *.rpd file from the *.pof file that is generated from the *.sof file.

Create a *.pof file by typing the command below:

$ quartus_pfg -c -o mode=ASX4 -o device=MT25QU02G \ 
ghrd_1sx280lu2f50e2vg_hps.sof ghrd_1sx280lu2f50e2vg_hps.pof

Create the *.rpd file from the *.pof file by typing the commands below:

$ quartus_pfg -c- o mode=ASX4 ghrd_1sx280lu2f50e2vg_hps.pof \ 
ghrd_1sx280lu2f50e2vg_hps.rpd

The *.sof data is placed at the beginning of the *.rpd file and is padded with 0xFFs to the end of the image. You can write a script to strip the unnecessary trailing 0xFFs or you can use the Linux* dd command to grab enough of the *.rpd file to capture the required data as shown in the example below.

Info: Command: quartus_pfg -c ghrd_1sx280lu2f50e2vg_hps.pof
ghrd_1sx280lu2f50e2vg_hps.rpd
Info: Quartus Prime Convert_programming_file was successful. 0 errors, 0
warnings
Info: Peak virtual memory: 420 megabytes
Info: Processing ended: Wed Sep 27 13:10:00 2017
Info: Elapsed time: 00:00:11
Info: Total CPU time (on all processors): 00:00:11
$$ ls -l
total 266940
-rw-rw-r--. 1 XXXXXXX XXXXXXX 134217970 Sep 27 13:08
ghrd_1sx280lu2f50e2vg_hps.pof
-rw-rw-r--. 1 XXXXXXX XXXXXXX 134217728 Sep 27 13:10
ghrd_1sx280lu2f50e2vg_hps.rpd
-rw-r--r--. 1 XXXXXXX XXXXXXX 4900067 Sep 27 12:42
ghrd_1sx280lu2f50e2vg_hps.sof
$$ hexdump -s 0x793898 ghrd_1sx280lu2f50e2vg_hps.rpd
0793898 431b 5895 357e 8632 702a 24fd 6156 d0f8
07938a8 d6d8 aa44 f1c3 b4a9 5381 e887 b3f2 c60f
07938b8 c786 65b3 1f56 4d8d 8a66 3f9c 954c 7e38
07938c8 2b98 fc10 0000 0000 0000 0000 0000 0000
07938d8 0000 0000 0000 0000 0000 0000 0000 0000
*
0793ff8 0000 0000 0000 0000 ffff ffff ffff ffff
0794008 ffff ffff ffff ffff ffff ffff ffff ffff // NOTE: The start of the PAD
is
* design specific
7fffff8 ffff ffff ffff ffff
8000000
$$ dd bs=1M count=8 if=ghrd_1sx280lu2f50e2vg_hps.rpd
of=ghrd_1sx280lu2f50e2vg_hps_shorter.rpd
8+0 records in
8+0 records out
8388608 bytes (8.4 MB) copied, 0.00619553 s, 1.4 GB/s
$$ hexdump -s 0x793898 ghrd_1sx280lu2f50e2vg_hps_shorter.rpd
0793898 431b 5895 357e 8632 702a 24fd 6156 d0f8
07938a8 d6d8 aa44 f1c3 b4a9 5381 e887 b3f2 c60f
07938b8 c786 65b3 1f56 4d8d 8a66 3f9c 954c 7e38
07938c8 2b98 fc10 0000 0000 0000 0000 0000 0000
07938d8 0000 0000 0000 0000 0000 0000 0000 0000
*
0793ff8 0000 0000 0000 0000 ffff ffff ffff ffff
0794008 ffff ffff ffff ffff ffff ffff ffff ffff
* // NOTE: Much, much less 0xFFFF fill
07ffff8 ffff ffff ffff ffff
0800000
$$ ls -l
total 275140
-rw-rw-r--. 1 XXXXXXX XXXXXXX 134217970 Sep 27 13:08
ghrd_1sx280lu2f50e2vg_hps.pof
-rw-rw-r--. 1 XXXXXXX XXXXXXX 134217728 Sep 27 13:10
ghrd_1sx280lu2f50e2vg_hps.rpd
-rw-rw-r--. 1 XXXXXXX XXXXXXX 8388608 Sep 27 13:15
ghrd_1sx280lu2f50e2vg_hps_shorter.rpd
-rw-r--r--. 1 XXXXXXX XXXXXXX 4900067 Sep 27 12:42
ghrd_1sx280lu2f50e2vg_hps.sof

4.7. Creating the JTAG Indirect Configuration (*.jic) File for Flash Programming

The Intel^® Quartus^® Prime Pro Edition Programmer tool uses the JTAG Indirect Configuration file (*.jic) to program Active Serial (AS) flash such as the Micron* MT25Q series.

You can generate the *.jic file using the quartus_pfg command or the Programming File Generator GUI. Use the following command to generate the .jic on the command line:

$ quartus_pfg -c -o device=MT25QU02G  -o flash loader=1SX280LU2 -o mode=ASX4 \ 
ghrd_1sx280lu2f50e2vg_hps.sof ghrd_1sx280lu2f50e2vg_hps.jic

Complete the following steps to generate using the Programming File Generator GUI:

On the Intel^® Quartus^® Prime Pro Edition File menu, click Programming File Generator.
Select Intel^® Stratix^® 10 from the Device family drop-down list.
Select the configuration mode from the AS x4 Configuration mode drop-down list.
On the Output Files tab, assign the Output directory and Name.
Select the JTAG Indirect Configuration File (.jic) output file type and the Memory Mapped File (map) file.
You can also select the Raw Programming Data File (.rpd). By default, the .rpd file type is little-endian. If you are using a third-party programmer that does not support the little-endian format, complete the following steps to turn Bit swap to generate the .rpd file in big endian format.
1. Select the Raw Programming Data File (.rpd) file.
2. Select Edit.
3. In the RPD Properties dialog box, turn Bit swap On.
  
  Figure 16. Specifying Parameters for .jic File Generation on the Output Files Tab
On the Input Files tab, click Add Bitstream. Browse to and select your .sof.

Figure 17. Specify the .sof File on the Input Files Tab
On the Configuration Device tab, click Add Device. You can select your flash device from the from the Configuration Device list, or define a custom device using the available menu options. For more information about defining a custom configuration device, refer to the Configuration Device Tab Settings (Programming File Generator) in the Intel^® Quartus^® Prime Pro Edition User Guide: Programmer

Figure 18. Programming File Generator Configuration Device

Note: You do not need to specify the flash device for .rpd files because the .rpd format is independent of the flash device. In contrast, the .pof and .jic files include both programming data and additional data specific to the configuration device. The Intel^® Quartus^® Prime Programmer uses this additional data to establish communication with the configuration device and then write the programming data.
For Flash loader click Select and select Intel^® Stratix^® 10 from Device family list. Select the device name that matches your OPN. Click OK.

Figure 19. Select the Flash Loader
Click Generate to generate the programming files.
After you program the AS or Quad SPI device with the *.jic file, the flash contains the following sections:
- In FPGA Configuration First mode:
  - SDM Configuration Firmware
  - FPGA I/O and HPS external memory interface (EMIF) I/O configuration data
  - FPGA core configuration data
  - HPS FSBL code and FSBL hardware handoff binary
- HPS Boot First
  - SDM Configuration Firmware
  - HPS external memory interface (EMIF) I/O configuration data
  - HPS FSBL code and HPS FSBL hardware handoff binary

4.7.1. Creating *.jic File for System Layout with a Single SDM Flash

For system layout that uses a single SDM Flash, you have the option to include OS files (SSBL, Linux* kernel image and OS file system) in the *.jic file before you program the active serial or Quad SPI flash device. Refer to the Intel^® Stratix^® 10 SoC Single QSPI Flash Boot example on RocketBoards for step-by-step guide to enable Single QSPI Flash Boot.

5. Generating the Linux Kernel Image

The Intel^® Stratix^® 10 SoC FPGA Golden System Reference Design (GSRD) provides the Ångström meta layer for building the U-Boot, Linux* kernel, and root file system. This design provides you a working example for booting the system into Linux*. Refer to the Rocketboards.org website for more information about using the Ångström build recipes. Refer to the RocketBoards website for latest Linux* Kernel branch information.

5.1. Compiling the Linux Kernel Image

You can retrieve the Linux* kernel sources from the Intel public git repository to build the kernel image separately. Assuming that you have set up the tool chain as described in the Compiling U-Boot FSBL and SSBL section, type the following commands to build the Linux* kernel.

$ cd ~

$ git clone https://github.com/altera-opensource/linux-socfpga

$ cd linux-socfpga

$ git checkout socfpga-4.14.130-ltsi .

$ make defconfig

$ make

You may make changes to the default configuration (for example, adding GPIO drivers) by typing make menuconfig after the make defconfig command.

Refer to the RocketBoards website for latest Linux Kernel branch information.

Note: Intel policy specifies that only the current and immediately previous U-Boot and Linux branches are available on GitHub. As Intel makes a new branch available, Intel removes the oldest branch. You must keep a local copy of the sources used to build your binaries if you need to reproduce the build or make changes in the future.

$ make defconfig

$ make menuconfig

Make your desired changes and remember to save the *.config file before proceeding to the final make command.

Completing these commands creates the following files:

Table 16. Resultant Files
File	Description
vmlinux	Linux* kernel ELF file
arch/arm64/boot/Image	Linux* kernel image
arch/arm64/boot/dts/altera/socfpga_stratix10_socdk.dtb	Device tree blob for Linux

Note: If you are using the Intel^® Stratix^® 10 SoC development kit, the default location of the kernel image (file name: Image) and the device tree blob (filename: socfpga_stratix10_socdk.dtb) is located in the FAT partition of the HPS SD Card.

6. Configuring the FPGA from SSBL and OS

In the HPS Boot First mode, you can use either the U-Boot SSBL or OS to initiate the FPGA configuration.

6.1. Configuring the FPGA Using the U-Boot SSBL

Boot the device until U-Boot SSBL stage.

Load the FPGA Configuration *.rbf from either SDM flash, HPS flash, or through HPS Ethernet to HPS SDRAM. By using a simple command, fpga load, the HPS requests the SDM to begin the FPGA configuration using the *.rbf file that has been loaded to the HPS SDRAM.

Below is the example of the serial output when using the SSBL to initiate the FPGA configuration. The FPGA configuration file is located in the HPS SD Card FAT partition.

SOCFPGA_STRATIX10 # fatls mmc 0:1
 12827136 image
    18490 socfpga_stratix10_socdk.dtb 
   398447 u-boot-dtb.img
  6979584 ghrd_1sx280lu2f50e2vg_hps.core.rbf 
4 file(s), 0 dir(s)
SOCFPGA_STRATIX10 # fatload mmc 0:1 0x8000 ghrd_1sx280lu2f50e2vg_hps.core.rbf
reading ghrd_1sx280lu2f50e2vg_hps.core.rbf
6979584 bytes read in 477 ms (14 MiB/s)
SOCFPGA_STRATIX10 # fpga load 0 0x8000 $filesize
.......
FPGA reconfiguration OK!

The following code is a similar example, except that the FPGA configuration file is being transferred through the TFTP server. The dcache flush command is required after the transfer from TFTP server to ensure content is loaded onto the HPS SDRAM.

SOCFPGA_STRATIX10 # dhcp 0x8000 /xxx/ghrd_1sx280lu2f50e2vg_hps.core.rbf
Speed: 100, full duplex
DHCP client bound to address xxx.xxx.xxx.xxx (1004 ms)
Using ethernet@ff800000 device
TFTP from server xxx.xxx.xxx.xxx; our IP address is xxx.xxx.xxx.xxx
Filename '/xxx/ghrd_1sx280lu2f50e2vg_hps.core.rbf'.
Load address: 0x8000
Loading: #################################################################
 #################################################################
 #################################################################
 #################################################################
 #################################################################
 #################################################################
 #################################################################
 #####################
 608.4 KiB/s
done
Bytes transferred = 6979584 (6a8000 hex)
SOCFPGA_STRATIX10 # dcache flush
SOCFPGA_STRATIX10 # fpga load 0 0x8000 $filesize
.......
FPGA reconfiguration OK!

6.2. Configuring the FPGA Using the Linux Operating System

Note: This feature is supported with Linux* kernel v4.9 LTSI and onwards. Refer to RocketBoards.org and the Intel^® public git repository for the latest information regarding this feature.

The Linux* kernel for Intel^® Stratix^® 10 SoC FPGA allows you to enable the programming of FPGA from within the OS.

Testing FPGA Reconfiguration at Kernel Level

If you want to test the FPGA reconfiguration at kernel level, make the following changes to the kernel source code:

In the file arch/arm64/boot/dts/altera/Makefile, add a second .dtb file. For example:
```
dtb-$(CONFIG_ARCH_STRATIX10) += socfpga_stratix10_socdk.dtb socfpga_stratix10_ovl1.dtb
```

Create a new .dts file (for example: socfpga_stratix10_ovl1.dts) and add the overlay information of the RBF file into the file as shown below:

/dts-v1/;
/plugin/;
/ {
	fragment@0 {
		target-path = "/soc/base_fpga_region";
		#address-cells = <1>;
		#size-cells = <1>;
		__overlay__ {
			#address-cells = <1>;
			#size-cells = <1>;

			firmware-name = "soc_s10_ovl1.rbf";
			config-complete-timeout-us = <30000000>;
		};
	};
};

When you build the Linux* kernel for this feature, the build generates two *.dtb files.

Table 17. Resultant Files
Device Tree File	Description
socfpga_stratix10_socdk.dtb	The default *.dtb file used with the kernel image to boot the system.
socfpga_stratix10_ovl1.dtb	The *.dtb file used to trigger FPGA configuration in OS.

In your compilation output folder, rename the FPGA configuration file (*.rbf) to the following name: soc_s10_ovl1.rbf. Then, copy both the FPGA configuration file (*.rbf) and the socfpga_stratix10_ovl1.dtb file to the following location in your Root File System:

$ mkdir <your_ROOTFS>/lib/firmware

$ cp socfpga_stratix10_ovl1.dtb <your_ROOTFS>/lib/firmware/

$ cp soc_s10_ovl1.rbf <your_ROOTFS>/lib/firmware/

The changes above allow you to program the FPGA in Linux* by applying an overlay on the system. After you boot to Linux* and log in with root privilege, use the following command to begin FPGA configuration:

# mkdir /sys/kernel/config/device-tree/overlays/0

# echo socfpga_stratix10_ovl1.dtb >

/sys/kernel/config/device-tree/overlays/0/path/

If you want to re-apply the overlay, you have to first remove the existing overlay, and then re-run the previous steps:

# rmdir /sys/kernel/config/device-tree/overlays/0

# mkdir /sys/kernel/config/device-tree/overlays/0

# echo socfpga_stratix10_ovl1.dtb >/sys/kernel/config/device-tree/overlays/0/path

7. Debugging the Intel Stratix 10 SoC FPGA Boot Flow

To debug the Intel^® Stratix^® 10 SoC FPGA boot flow, you must understand the different conditions that may impact the system, such as reset and hardware configuration settings. In addition, you may also use debug tools such as Arm* Development Studio 5* Intel^® SoC FPGA Edition to load and debug the boot loader software used in your design.

7.1. Reset

Table 18. Reset Effects on Booting and Configuration
Reset Type	Initiated By	Details
Power-on Reset	An external event	The entire HPS and FPGA are reset. When the device is released from POR, SDM begins initialization. A POR is the only way initialization can begin. POR is the only way to recover from a tamper event.
`nCONFIG` Reset	`nCONFIG` pin	An SoC device-wide reset input that cold resets the HPS and reconfigures the FPGA.
Cold Reset	SDM `HPS_COLD_nRESET` pin Watchdog Timeout Event (calls SDM)	All of HPS, except the HPS I/O, Clock Manager, Reset Manager, and the TAP controller, are reset. An HPS cold reset does not impact the FPGA core and FPGA I/O (the device is not reconfigured). The SDM reloads the FSBL into on-chip RAM. When the `HPS_COLD_nRESET` pin asserts, the SDM begins the reset sequence.
Cold and Trigger Remote Update Reset	Watchdog Timeout Event (calls SDM)	SDM requests reset manager to assert or de-assert cold reset. When the HPS_COLD_nRESET pin asserts, the SDM begins the reset sequence. The SDM loads the FSBL from the next bitstream or factory bitstream into on-chip RAM. The FPGA is first erased and then loaded with an image from the next bitstream or factory bitstream. There must always be a factory image present.
Warm Reset	FSBL or any software that makes a warm reset request through the EL3 register³ software write to the RMR_EL3 register to trigger a warm reset to the CPUs. You can still use debug tools after a warm reset because it does not reset the debug modules. The SDM does not reload the FSBL on a warm reset. You must ensure that your FSBL can support reentry, or that your on-chip RAM contains the FSBL or minimum required to boot the system. Watchdog Timeout Event (calls SDM)	Before you can write to the RMR_EL3 register, CPU0 must ensure that the other CPUs are in WFI mode. Immediately after the RMR_EL3 register is written, the WFI instruction must be executed. All of the HPS, except debug, MPU debug, and the boot scratch registers in the System Manager are reset. A warm reset does not reload the FSBL into the HPS. The FSBL remains in the on-chip RAM during a warm reset. Warm reset of the HPS does not impact the FPGA core and I/O (the device is not reconfigured). In the case of a single configuration and boot source, warm reset returns flash control from HPS to SDM.
Software Reset	A software write to the Reset Manager	A software reset of a CPU does not affect SDM functionality.
Watchdog Reset	Timeout from a user configurable watchdog timer register.	Each CPU has a dedicated watchdog timer. L4 Watchdog Timer 0 is configured during HPS initialization. Use the Intel^® Quartus^® Prime Pro Edition to configure the watchdog reset for an HPS cold, HPS warm, or HPS cold and trigger remote update reset. See other entries in this table for details on each reset type.
Debug Reset	JTAG `SRST` pin	To control reset, you must connect the `HPS_COLD_nRESET` pin to the JTAG `SRST` pin. A debug reset initiates a cold reset.
JTAG Reset	JTAG `SRST` pin	JTAG can reset the entire device regardless of the `MSEL[2:0]` settings and reload a new configuration or test through JTAG.

When the device is reset in secure mode, all system warm and watchdog resets are treated as a POR reset. When the HPS is released from reset, all CPUs begin executing the FSBL. The FSBL ensures that CPUs 1 through 3 are in wait-for-interrupt (WFI) mode.

³ The Cortex* -A53 has four levels of exception from EL3 to EL0. EL3 is the highest privilege and EL0 is the lowest.

7.1.1. HPS Reset Pin

You can configure this pin through Intel^® Quartus^® Prime Pro Edition.

Table 19. HPS Reset Pins
Pin Function	Possible Settings	Functional Description
`HPS cold nreset`	`SDM_IO0`, `SDM_IO10-16`	Assert this pin to trigger cold reset to the HPS. If the HPS is cold reset via software, this pin becomes an output pin and remain low until the HPS cold reset sequence is complete.

7.1.2. L4 Watchdog Timer 0

Each CPU has its own L4 Watchdog Timer. The HPS FSBL enables L4 Watchdog Timer 0 for CPU0. L4 Watchdog Timer 0 issues a reset when a timeout occurs because of a corrupted bitstream or HPS image or any other issue that causes the HPS to hang.

This watchdog is active until the second-stage boot loader indicates that it has started correctly and taken control of the exception vectors. The timeout is configurable at the FSBL source. U-Boot SPL default is 3 seconds for timeout.

7.2. Debugging the HPS Boot Loader Using the Arm DS-5 Intel SoC FPGA Edition

7.2.1. Selecting the HPS Debug Interface

In Intel^® Stratix^® 10 SoC FPGA, you have the option to use split FPGA and HPS JTAG, or combined JTAG. To set this in Intel^® Quartus^® Prime Pro Edition, go to Assignments > Device > Device and Pin Options... . Select the Configuration category and choose from the HPS debug access port (DAP) drop down options.

Figure 20. Selecting Debug Interface from Configuration Window

The available options are:

Disabled: The HPS JTAG is not enabled.
HPS Pins: The HPS JTAG is routed to the HPS dedicated I/O.
- You must assign the HPS dedicated pins to the HPS JTAG function in the Intel^® Stratix^® 10 HPS component inside the Platform Designer.
- After the HPS FSBL completes the HPS pin multiplexing configuration, the HPS JTAG interface becomes available.
SDM Pins: The HPS JTAG is chained to the FPGA JTAG.
- With this option, after the device completes configuration, the HPS JTAG interface is included in the JTAG chain of the device. The HPS becomes the first device in the chain, even if the FPGA was the first device in the JTAG chain prior to configuration. If you use JTAG for configuration, ensure that you select the correct device in the JTAG chain because the index changes before and after configuration with this selection.

7.2.2. Configure the FPGA and run the Debug FSBL

To enable JTAG as a boot source, set the MSEL[2:0] pins to 0x7.
Power cycle your design. Intel recommends that you power cycle for each debugging session.
Load the debug *.sof, <ghrd_directory>/output_files/ <design>_hps_debug.sof, using the Intel^® Quartus^® Prime Pro Edition Programmer. This *.sof includes the hps_debug FSBL file from the <ghrd_directory>/software/hps_debug/ folder. This first stage boot example HPS (*.elf) provides the bare minimum required to put the HPS in a known initial state. This *.sof programs the entire FPGA. Consequently, the HPS does not need to take further action to program the FPGA.
You can now load the secondary program loader (SPL) using the debugger.

7.2.3. Creating the Debug Configuration

Before debugging, you must create a Debug Configuration for the Intel^® Stratix^® 10 SoC FPGA device in the Arm* DS-5* Intel^® SoC FPGA Edition tool.

Connect the device to the host PC using the Intel^® FPGA Download Cable or Arm* DSTREAM interface connector.

Note: The Intel^® FPGA Download Cable requires Arm* DS-5* Intel^® SoC FPGA Edition version 5.29 or later.
Start Arm* DS-5* Intel^® SoC FPGA Edition and select the workspace when prompted.
Launch the Debug Configuration windows by selecting Run > Debug Configuration from the main menu.
Create a new Debug Configuration by right clicking DS-5 Debugger on the left pane and select New from the displayed menu.
Rename the new Debug Configuration accordingly (example: Debug Boot Loader).
From the Connection tab, select the target as Intel SoC FPGA > Stratix 10 SoC > Bare Metal Debug > Debug Cortex A53_0.
Select the Target Connection as Intel^® FPGA Download Cable or DSTREAM accordingly.
Click the Browse button in the Connections group and select the appropriate connection.

7.2.4. Debugging the First Stage Boot Loader (FSBL)

On the Debugger tab from the Run Control option, select Connect Only.

On the same tab, turn on Execute Debugger Commands and enter the following commands in the text box:

stop
wait 5s
reset system
wait 10s
stop
wait 5s
set trust-ro-sections-for-opcodes off
delete
loadfile "<local_path>/u-boot-socfpga/spl/u-boot-spl" 0x0
set debug-from *$entrypoint
restore <local_path>/u-boot-socfpga/spl/u-boot-spl.dtb binary &_end 
start

Note: Replace <local_path> with the absolute path on your host machine where the U-Boot is compiled.

Click the Debug button to close the Debug Configurations Window and start a debug session. After this step, you can apply standard debugging techniques.
If you want to run the FSBL to completion, use the following debugger commands at any point after you initiate the debug session:
```
delete
thbreak spl_boot_device
continue
wait 15s
```
You can also add the above commands to the list of commands to run when the debugging session starts. If you do add these commands to your list, the FSBL always runs to completion.

7.2.5. Debugging U-Boot

Once the FSBL runs successfully to completion, use the following debugger commands to load U-Boot:

restore "<local_path>t/u-boot-socfpga/u-boot-dtb.bin" binary 0x1000
add-symbols-file <local_path>/u-boot-socfpga/u-boot
set $PC=0x1000

Note: Replace <local_path> with the absolute path on your host machine where you compiled the U-Boot.

After this step, you can apply standard debugging techniques.

7.3. Other Debug Considerations

Peripherals

The first step in the board bring-up process is peripheral testing. Add one interface at a time to your design. After a peripheral passes the tests you create for it, remove it from the test design. Avoid leaving peripherals that pass testing in your design as you move to other peripheral tests. Multiple peripherals can create instability due to noise or crosstalk. By testing peripherals in a system individually, you can isolate issues in your design to a particular interface.

A common failure in any system involves memory. The most problematic memory devices operate at high speeds, which can result in timing failures. High performance memory also requires many board traces to transfer data, address, and control signals, which cause failures if they are not routed properly. You can use the Nios^® II processor to verify your memory devices using verification software or a debugger such as the Intel^® Stratix^® 10 EMIF Toolkit. The Nios^® II processor is not capable of stress testing your memory but you can use it to detect memory address and data line issues.

Data Trace Failure

If your board fabrication facility does not perform bare board testing, you must perform these tests. To detect data trace failures on your memory interface, use a “walking ones" pattern. The "walking ones" pattern shifts a logical 1 through all of the data traces between the FPGA and the memory device.

The pattern can be increasing or decreasing; the important factor is that only one data signal is 1 at any given time. The increasing version of this pattern is as follows: 1, 2, 4, 8, 16, and so on. Using this pattern, you can detect a few issues with the data traces such as short or open circuit signals. A signal is short circuited when it is accidentally connected to another signal. A signal is open circuited when it is accidentally left unconnected. Open circuits can have a random signal behavior unless you connect a pull-up or pull-down resistor to the trace. If you use a pull-up or pull-down resistor, the signal drives a 0 or 1; however, the resistor is weak relative to a signal being driven by the test, so that test value overrides the pull-up or pull-down resistor. To avoid mixing potential address and data trace issues in the same test, test only one address location at a time. To perform the test, write the test value out to memory, and then read it back. After verifying that the two values are equal, proceed to testing the next value in the pattern. If the verification stage detects a variation between the written and read values, a bit failure has occurred. The table below provides an example of the process used to find a data trace failure. It makes the simplifying assumption that sequential data bits are routed consecutively on the PCB.

Table 20. Data Trace Test ("Walking Ones") Example
Written Value	Read Value	Failure Detected
00000001	00000001	No failure detected.
00000010	00000000	Error, most likely the second data bit, `D[1]`, is stuck low or shorted to ground.
00000100	00000100	No failure detected, confirmed `D[1]` is stuck low or shorted to another trace that is not listed in this table.
00001000	00001000	No failure detected.
00010000	00010000	No failure detected.
00100000	01100000	Error, most likely `D[6]` and `D[5` are short circuited.
01000000	01100000	Error, confirmed that `D[6]` and `D[5]` are short circuited.
10000000	10000000	No failure detected.

Address Trace Failure

The address trace test is similar to the "walking ones" test used for data with one exception. For this test, you must write to all the test locations before reading back the data. Using address locations that are powers of two, you can quickly verify all the address traces of your circuit board. The address trace test detects the aliasing effects that short or open circuits can have on your memory interface. For this reason, it is important to write to each location with a different data value so that you can detect the address aliasing. You can use increasing numbers such as 1, 2, 3, 4, and so on while you verify the address traces in your system. The table below shows how to use powers of two in the process of finding an address trace failure.

Table 21. Address Trace Test (Powers of Two) Example
Address	Written Value	Read Value	Failure Detected
00000000	1	1	No failure detected.
00000001	2	2	No failure detected.
00000010	3	1	Error, the second address bit, `A[1]`, is stuck low.
00000100	4	4	No failure detected.
00001000	5	5	No failure detected.
00010000	6	6	No failure detected.
00100000	7	6	Error, `A[5]` and `A[4]` are short circuited.
01000000	8	8	No failure detected.
10000000	9	9	No failure detected.

Device Isolation

Using device isolation techniques, you can disable features of devices on your PCB that cause your design to fail. Typically, designers use device isolation for early revisions of the PCB, and then remove these capabilities before shipping the product. Most designs use crystal oscillators or other discrete components to create clock signals for the digital logic. If the clock signal is distorted by noise or jitter, failures may occur. To guard against distorted clocks, you can route alternative clock pins to your FPGA. If you include SMA connectors on your board, you can use an external clock generator to create a clean clock signal. Having an alternative clock source is very useful when debugging clock-related issues.

Sometimes the noise generated by a particular device on your board can cause problems with other devices or interfaces. Having the ability to reduce the noise levels of selected components can help you determine the device that is causing issues in your design. The simplest way to isolate a noisy component is to remove the power source for the device in question. For devices that have a limited number of power pins, if you include 0 ohm resistors in the path between the power source and the pin, you can cut the power to the device by removing the resistor. This strategy is typically not possible with larger devices that contain multiple power source pins connecting directly to a board power plane. Instead of removing the power source from a noisy device, you can often put the device into a reset state by driving the reset pin to an active state. Another option is to simply not exercise the device so that it remains idle. A noisy power supply or ground plane can create signal integrity issues. With the typical voltage swing of digital devices frequently below a single volt, the power supply noise margin of devices on the PCB can be as little as 0.2 volts. Power supply noise can cause digital logic to fail. For this reason, it is important to be able to isolate the power supplies on your board. You can isolate your power supply by using fuses that are removed so that a stable external power supply can be substituted temporarily in your design.

JTAG

FPGAs use the JTAG interface for programming, communication, and verification. Designers frequently connect several components, including FPGAs, discrete processors, and memory devices, communicating with them through a single JTAG chain. Sometimes the JTAG signal is distorted by electrical noise, causing a communication failure for the entire group of devices. To guarantee a stable connection, you must isolate the FPGA under test from the other devices in the same JTAG chain.

A. Document Revision History for Intel Stratix 10 SoC FPGA Boot User Guide

Document Version	Changes
2020.12.04	Added a restriction to the Boot Flow Overview section that the phase 1 and phase 2 configuration files must be generated from the same Intel^® Quartus^® Prime Pro Edition software version.
2020.09.15	Added information about the differences between H- and L-tile regarding clock requirements prior to configuration in Boot Flow Overview. Added information clock requirements for HPS first boot mode; and what is required for phase 1 and phase 2 in First-Stage Boot Loader.
2020.06.30	Removed support for the SD/MMC configuration scheme in Intel Stratix 10 devices.
2019.12.19	Made the following changes: Removed all references to EPCQ-L. This flash device is obsolete. Replaced EPCQL1024 with MT25QU02G in `quartus_pfg` commands. Removed all references to prebuilt binaries or sources inside the SoC EDS. These files are no longer included in the distribution. Corrected directory path in Compiling the SRAM Object File. It should include 19.3. Revised Compiling U-Boot FSBL and SSBL to get the source code from the GitHub repository. Updated the version of `socfpga` in Compiling the Linux Kernel Image Revised the debugging section.
2019.12.16	Made the following changes: Changed all commands to convert programming files to use the `quartus_pfg` instead of `quartus_cpf`. The `quartus_cpf` command does not handle some of the advanced security features that Intel^® Stratix^® 10 devices support. Added the following note to the Single SDM Flash topic: Due to a problem in the Intel^® Quartus^® Prime Pro Edition Software, if you specify the HPS boot from FPGA parameter on the FPGA Interfaces tab of the Intel^® Arria^® 10 Hard Processor System Intel^® Arria^® 10 FPGA IP GUI, this information has no effect on HPS behavior. Removed statement in Creating the Raw Programming Data ( *.rpd ) File For Flash Programming topic saying that the .rpd file generated is the same size as the configuration device. This statement is not true for Intel^® Stratix^® 10 and later device families.
2019.07.25	Note added to explain HPS First "Phase 1 configuration" and "Phase 2 configuration" terminology in Boot Flow Overview .
2018.09.24	Added references to the Single QSPI Flash Boot Example. Updated the filenames in accordance to the SoC EDS 18.1 version. Added reference to the Micron MT25Q Support knowledge base. Added the information about Testing FPGA Reconfiguration at Kernel Level.
2018.05.01	Initial release.

Generating the *.rpd File During *.jic Creation

Generating the *.rpd File from the *.sof File

Peripherals

Data Trace Failure

Address Trace Failure

Generating the .rpd File During .jic Creation

Generating the .rpd File from the .sof File