Intel SoC FPGA Embedded Development Suite User Guide
Version Information
| Updated for: |
|---|
| Intel® Quartus® Prime Design Suite 19.1 Standard and 19.3 Pro |
1. Introduction to the Intel SoC FPGA EDS
The SoC EDS contains development tools, utility programs, run-time software, and application examples that enable firmware and application software development on Intel® SoC hardware platforms.
- SoC EDS Standard Edition —The SoC EDS Standard Edition targets the Arria® V SoC, Cyclone® V SoC, and Intel® Arria® 10 SoC and must be used only with FPGA projects created in Intel® Quartus® Prime Standard Edition. Although the Intel® FPGA SoC devices and Intel® Quartus® Prime Standard Edition support Intel® Arria® 10 SoC, Intel® recommends that you use the Intel® Quartus® Prime Pro Edition and SoC EDS Professional Edition versions for new Intel® Arria® 10 SoC Projects.
-
SoC EDS Professional Edition
—The
SoC EDS Professional Edition targets the
Intel®
Arria® 10 SoC,
Intel®
Stratix® 10 SoC,
and
Intel®
Agilex™
and must be used only with
FPGA projects created in
Intel®
Quartus® Prime Pro Edition.Note: The SoC EDS Professional Edition does not support Cyclone® V SoC and Arria® V SoC, as they are not supported by Intel® Quartus® Prime Pro Edition.
1.1. Tool Versions
| Tool | Version |
|---|---|
| Mentor Graphics* BareMetal GCC Compiler | 6.2.0 (Sourcery CodeBench Lite 2019.05-16) which includes GCC version 8.3.1 20190416 |
| Linux* Compiler | 4.8.3 (Linaro* GCC 7.2-2017.11) |
| Arm* Compiler 5 | 5.06 update 6 |
| Arm* Compiler 6 | 6.10.1 |
| Arm* Development Studio 5* (DS-5*) Intel® SoC FPGA Edition | 5.29.2 |
1.2. Differences Between Standard and Professional Editions
The main difference between the two different editions exists in the SoC devices that are supported, as mentioned in the previous section.
- The default installation paths are different between editions. For details on the default installation paths, refer to the "Installing the Intel® SoC FPGA EDS" chapter.
- There are no licensing differences between SoC EDS editions. The same DS-5* Intel® SoC FPGA Edition License works for both Standard and Pro editions. For details about licensing, refer to the " Intel® SoC FPGA EDS Licensing" chapter.
1.3. Overview
- Board bring-up
- Device driver development
- Operating system (OS) porting
- Bare-Metal application development and debugging
- OS- and Linux*-based application development and debugging
- Debug systems running symmetric multiprocessing (SMP)
- Debug software targeting soft IP residing on the FPGA portion of the device
- Arm* Development Studio 5* Intel® SoC FPGA Edition AE Toolkit
- Compiler tool
chains:
- BareMetal GNU Compiler Collection (GCC) tool chain from Mentor Graphics*
- Arm* BareMetal compiler 5
- Arm* BareMetal compiler 6
- Linux* GCC compiler tool chain from Linaro*
- SoC Hardware Library (HWLIB)
- Hardware-to-software interface utilities:
- Second stage bootloader generator
- Linux* device tree generator
- Sample applications
- Golden Hardware Reference Designs
(GHRD) including:
- FPGA hardware project
- FPGA hardware SRAM Object File (.sof) file
- Embedded command shell allowing easy invocation of the included tools
- SD Card Boot Utility
- Intel® Quartus® Prime Programmer and Signal Tap
1.4. Hardware and Software Development Roles
Depending on your role in hardware or software development, you need a different subset of the SoC EDS toolkit. The following table lists some typical engineering development roles and indicates the tools that each role typically requires.
For more information about each of these tools, refer to the Intel SoC FPGA Embedded Development Suite page.
|
Tool |
Hardware Engineer |
BareMetal Developer |
RTOS Developer |
Linux* Kernel and Driver Developer |
Linux* Application Developer |
|---|---|---|---|---|---|
|
Arm* DS-5* Intel® SoC FPGA Edition Debugging |
√ | √ | √ | √ | √ |
|
Arm* DS-5* Intel® SoC FPGA Edition Tracing |
√ | √ | √ | ||
|
Arm* DS-5* Intel® SoC FPGA Edition Cross Triggering |
√ | √ | √ | ||
|
Hardware Libraries |
√ | √ | √ | ||
|
Second Stage Bootloader Generator |
√ | √ | √ | √ | |
|
Flash Programmer |
√ | √ | √ | √ | |
|
BareMetal Compiler |
√ | √ | √ | √ | |
|
Linux* Compiler |
√ | √ | |||
|
Linux* Device Tree Generator Note: This tool is obsolete. For more information, refer to section
Linux Device Tree Generator.
|
√ |
1.4.1. Hardware Engineer
As a hardware engineer, you typically design the FPGA hardware in Platform Designer (Standard). You can use the debugger of Arm* DS-5* Intel® SoC FPGA Edition AE to connect to the Arm* cores and test the hardware. A convenient feature of the DS-5 debugger is the soft IP register visibility, using Cortex Microcontroller Software Interface Standard (CMSIS) System View Description (.svd) files. With this feature, you can easily read and modify the soft IP registers from the Arm* side.
As a hardware engineer, you may generate the Preloader for your hardware configuration. The Preloader is a piece of software that configures the HPS component according to the hardware design.
As a hardware engineer, you may also perform the board bring-up. You can use Arm* DS-5* Intel® SoC FPGA Edition debugger to verify that they can connect to the Arm and the board is working correctly.
These tasks require JTAG debugging, which is enabled only in the Arm* DS-5* Intel® SoC FPGA Edition, which is part of the paid Intel® SoC FPGA EDS license.
For more information, refer to the Intel® SoC FPGA EDS Licensing section.
1.4.2. BareMetal and RTOS Developer
As a BareMetal or a RTOS developer, you need JTAG debugging and low-level visibility into the system. The following tasks require JTAG debugging, which is enabled only in the Arm* DS-5* Intel® SoC FPGA Edition.
- To compile your code and the SoC Hardware Library to control the hardware in a convenient and consistent way, use the BareMetal compiler.
- To program the flash memory on the target board, use the Flash Programmer.
For more information, see the "Licensing" section.
1.4.3. Linux Kernel and Driver Developer
As a Linux* kernel or driver developer, you may use the same tools the RTOS developers use, because you need low-level access and visibility into the system. However, you must use the Linux* compiler instead of the BareMetal compiler.
These tasks require JTAG debugging, which is enabled only in the Arm* DS-5* Intel® SoC FPGA Edition, which is part of the paid Intel® SoC FPGA EDS license.
For more information, refer to the Intel® SoC FPGA EDS Licensing section.
For information about how to create a device tree, refer to the "HOWTO Create a Device Tree" web page on Rocketboards.org.
1.4.4. Linux Application Developer
As a Linux* application developer, you write code that targets the Linux* OS running on the board. Because the OS provides drivers for all the hardware, you do not need low-level visibility over JTAG. DS-5 offers a very detailed view of the OS, showing information about the threads that are running and the drivers that are loaded.
These tasks do not require JTAG debugging. You can perform these tasks with both the paid and free SoC EDS FPGA licenses. For more information, see the "Licensing" section.
1.5. Hardware – Software Development Flow
The Intel hardware-to-software handoff utilities allow hardware and software teams to work independently and follow their respective familiar design flows.
The following handoff files are created when the hardware project is compiled:
-
Handoff folder – contains information about how the HPS
component is configured, including things like which peripherals are enabled,
the pin MUXing and IOCSR settings, and memory parameters. The handoff folder is
used by the second stage bootloader generator to create the preloader.
For more information about the handoff folder, refer to the "BSP Generation Flow" section.
- .svd file – contains descriptions of the HPS registers and of the soft IP registers on the FPGA side implemented in the FPGA portion of the device. The .svd file contains register descriptions for the HPS peripheral registers and soft IP components in the FPGA portion of the SoC. This file is used by the Arm* DS-5* Intel® SoC FPGA Edition Debugger to allow you to inspect and modify these registers.
-
.sopcinfo file – contains a description of the entire
system. The SOPC Information (.sopcinfo) file, containing
a description of the entire system, is used by the Linux* device tree generator to create the device tree
used by the Linux* kernel. For more information, refer to the "Linux* Device Tree Generator" section.Note: The soft IP register descriptions are not generated for all soft IP cores.Note: For Intel® Stratix® 10 SoC and Intel® Agilex™ SoC, the handoff information is part of the configuration bitstream, and the bootloader has direct access to it. Because of that there is no need for a Bootloader Generator tool in this case.
1.6. Introduction to the Intel SoC FPGA EDS Revision History
| Document Version | Changes |
|---|---|
| 2019.12.20 | Supported
with
Intel®
Quartus® Prime Standard Edition version
19.1 and
Intel®
Quartus® Prime Pro Edition version
19.3
|
| 2019.05.16 |
|
| 2018.09.24 | Updated the Tool versions for Arm* Compiler 6 and Arm* Development Studio 5* (DS-5*) Intel® SoC FPGA Edition |
| 2018.06.18 |
|
| 2017.05.08 |
|
| 2016.11.07 | Maintenance release |
| 2016.05.27 | Renamed the Web and Subscription Editions to align with Quartus Prime naming |
| 2016.02.17 | Maintenance release |
| 2015.08.06 | Added Intel® Arria® 10 SoC support |
2. Installing the Intel SoC FPGA EDS
2.1. Installation Folders
- Standard Edition:
- c:\intelFPGA\19.1\embedded on Windows
- ~/intelFPGA/19.1/embedded on Linux*
- Professional Edition:
- c:\intelFPGA_pro\19.3\embedded on Windows
- ~/intelFPGA_pro/19.3/embedded on Linux*
- Standard Edition:
- c:\intelFPGA\19.1\qprogrammer on Windows
- ~/intelFPGA/19.1/qprogrammer on Linux*
- Professional Edition:
- c:\intelFPGA_pro\19.3\qprogrammer on Windows
- ~/intelFPGA_pro/19.3/qprogrammer on Linux*
2.2. Installing the SoC EDS on Windows
2.2.1. Installing Cygwin on Windows
Starting with SoC EDS version 19.1, the Windows* version of SoC EDS requires the Cygwin component to be manually installed. You need to have administrative privileges on the PC in order to perform the Cygwin installation.
The procedure for installing Cygwin is:
2.3. Installing the SoC EDS on Linux
On some Linux*-based machines, you can install the SoC EDS with a setup GUI similar to the Windows-based setup GUI. Because of the variety of Linux* distributions and package requirements, not all Linux* machines can use the setup GUI. If the GUI is not available, use an equivalent command-line process. You can download the Linux* installation program from the Download Center for FPGAs web page on the Intel® FPGA website.
2.4. Installing the Arm Development Studio 5 (DS-5) Intel SoC FPGA Edition Toolkit
- Ensure that you have the proper setting to access the internet.
- Ensure that the Arm* DS-5* Intel® SoC FPGA Edition installer starts automatically as the last step of the SoC EDS installer.
- Intel® recommends that you do not start the Arm* DS-5* Intel® SoC FPGA Edition installer manually.
- The installation folder is defined as <SoC FPGA EDS installation directory>\embedded for Windows* and <SoC FPGA EDS installation directory>/embedded for Linux*.
- $QUARTUS_ROOTDIR needs to be set to <quartus install>/quartus before launch.
For more information about the Intel® SoC FPGA EDS and Intel® Quartus® Prime installation folders, refer to the Installation Folders section.
2.5. Installing the Intel SoC FPGA EDS Document Revision History
| Document Version | Changes |
|---|---|
| 2019.12.20 | Supported with
Intel®
Quartus® Prime Standard Edition version 19.1
and
Intel®
Quartus® Prime Pro Edition version
19.3
|
| 2019.05.16 |
|
| 2018.09.24 | Updated the path names for the 18.1 release. |
| 2018.06.18 | Maintenance release |
| 2018.05.07 | Maintenance release |
| 2017.05.08 |
|
| 2016.11.07 | Maintenance release |
| 2016.05.27 | Maintenance release |
| 2016.02.17 | Updated the installation path to 15.1 |
| 2015.08.06 | Added Intel® Arria® 10 SoC support |
3. Arm Development Studio 5 Intel SoC FPGA Edition
For the current version, refer to Table 1.
- File editing, supporting syntax highlighting and source code indexing
- Build support, based on makefiles
- BareMetal debugging
- Linux* application debugging
- Linux* kernel and driver debugging
- Multicore debugging
- Access to HPS peripheral registers
- Access to FPGA soft IP peripheral registers
- Tracing of program execution through Program Trace Macrocells (PTM)
- Tracing of system events through System Trace Macrocells (STM)
- Cross-triggering between HPS and FPGA
- Connecting to the target using Intel® FPGA Download Cable II
The Arm* Development Studio 5* Intel® SoC FPGA Edition is a complex tool with many features and options. It is the only SoC EDS component that requires a license.
For information about the licensing options and how to obtain them, refer to the Intel® SoC FPGA EDS Licensing section.
This chapter only describes the most common features and options and provides getting started scenarios to help you get started, quickly.
You can access the Arm* Development Studio 5* Intel® SoC FPGA Edition reference material from Eclipse, by navigating to or on the Arm* website.
3.1. Starting Eclipse Arm Development Studio 5 Intel SoC FPGA Edition
Arm* Development Studio 5* Intel® SoC FPGA Edition must be started from the Embedded Command Shell.
Eclipse needs to be started from the Embedded Command Shell so that all the utilities are added to the search path, and they can be used directly from the makefiles without the full path.
To start the Eclipse IDE that the Arm* Development Studio 5* Intel® SoC FPGA Edition uses, you must type eclipse & at the command line.
3.2. BareMetal Project Management
Arm* Development Studio 5* Intel® SoC FPGA Edition enables convenient project management for BareMetal projects using two different methods:
- Using Makefiles
- Using the Arm* Development Studio 5* Intel® SoC FPGA Edition graphical interface
| Method | Advantages | Compiler Toolchain Support |
|---|---|---|
| Makefile | Scripted compilation | GCC |
| Arm* Development Studio 5* Intel® SoC FPGA Edition graphical interface | Multiple toolchain support | GCC, Arm* DS-5* Intel® SoC FPGA Edition Compiler |
3.2.1. BareMetal Project Management Using Makefiles
The Arm* Development Studio 5* Intel® SoC FPGA Edition enables convenient project management using makefiles. The sample projects that are provided with SoC EDS use makefiles to manage the build process.
To allow Arm* Development Studio 5* Intel® SoC FPGA Edition to manage a makefile-based project, create a project, as follows:
-
Create the project by selecting .
Figure 2. Creating a Project with Existing Code
-
Type the folder name in the Existing Code
Location edit box and then click Finish.
Figure 3. Import Existing Code
-
Create a Makefile in that folder, and define the rules required
for compiling the code. Make sure it has the all and the
clean targets.
Arm* Development Studio 5* Intel® SoC FPGA Edition now offers the possibility of invoking the build process from the IDE and allows you to build your project, as shown in the following figure:Figure 4. Eclipse IDE - Build Process Invoked - Building a Software Project in Arm* Development Studio 5* Intel® SoC FPGA Edition
If the compilation tools issue errors, Arm* Development Studio 5* Intel® SoC FPGA Edition parses and formats them for you and displays them in the Problems view.
3.2.2. GCC-Based BareMetal Project Management
3.2.2.1. Creating Project
- Start Eclipse.
- Go to .
-
Determine if you want to create an
Executable
empty project or a BareMetal library
empty project.
-
BareMetal executable
Select Project Type to be then Toolchain to be Intel FPGA Baremetal GCC then click Finish.Figure 5. BareMetal Executable Project Type
-
Static
Library
Select and click Finish.Figure 6. BareMetal Library Project Type
-
BareMetal executable
3.2.2.2. Build Settings
Once the project is created, the project properties can be accessed by going to .
The Build Settings include detailed settings for all tools:
- Compiler
- Assembler
- Linker
3.2.3. Arm Compiler 5 BareMetal Project Management
For the current version, refer to Table 1. The Arm* DS-5* Intel® SoC FPGA Edition can be used to manage Arm* compiler projects in a GUI environment.
3.2.3.1. Creating a Project
- Start Eclipse.
- Go to .
-
Select
one of the following options:
-
Select "Project Type" as and then for "Toolchains", select Arm Compiler 5. Click Finish.
Figure 9. Create an Empty Arm Compiler BareMetal Executable Project
-
Select and then for "Toolchains", select Arm Compiler 5. Click Finish.
Figure 10. Create an Empty Arm Compiler BareMetal Library Project
-
Select "Project Type" as and then for "Toolchains", select Arm Compiler 5. Click Finish.
3.2.3.2. Linker Script
Arm* Development Studio 5* Intel® SoC FPGA Edition offers a visual tool to help create linker scripts.
-
Go to
Figure 11. Creating a Linker Script
-
Select and press .
Figure 12. Creating a Scatter File
-
Select the location of the new file, type in the file name and press
Finish.
Figure 13. Create a New Scatter File Resource
-
The linker script file can be edited directly as shown in the example
below.
Figure 14. Linker Script Example
-
The file can also be edited by using the tools on the Outline view for the
file.
Figure 15. Editing "Scatter.scat" File Using Tools on the Outline View
3.2.3.3. Build Settings
-
Once the project is created, the project properties can
be accessed by going to .
Figure 16. Project Properties
-
Then, in the Project Properties window, the "Compilation"
settings can be accessed by selecting .
Figure 17. Project Settings
The build settings include detailed settings for all tools:- Compiler
- Assembler
- Linker
The "Getting Started with Arm* DS-5* Intel® SoC FPGA Edition Compiler Bare Metal Project Management" contains a link to complete instructions on how to create a project from scratch, compile it and run it on an Intel SoC development board.
3.3. Debugging
The Arm* Development Studio 5* Intel® SoC FPGA Edition offers you a variety of debugging features.
3.3.1. Accessing Debug Configurations
The settings for a debugging session are stored in a Debug Configuration. The Debug Configurations window is accessible from the menu.
For more information, refer to the Debugging the HPS Boot Loader Using the Arm* DS-5* Intel® SoC FPGA Edition section in the Intel® Stratix® 10 SoC FPGA Boot User Guide.
3.3.2. Creating a New Debug Configuration
A Debug Configuration is created in the Debug Configurations window by selecting DS-5 Debugger as the type of configuration in the left panel and then right-clicking with the mouse and selecting the New menu option.
In the Arm* Development Studio 5* Intel® SoC FPGA Edition, you can assign a default name to the configuration, which you can edit.
3.3.3. Debug Configuration Options
This section lists the Debug Configuration options, which allows you to specify the desired debugging options for a project:
- Connection Options
- File Options
- Debugger Options
- RTOS Awareness
- Arguments
- Environment
- Event Viewer
3.3.3.1. Connection Options
The Connection tab allows you to select the desired target. You must select the debugging target from the provided options, which cover BareMetal applications, Linux* kernel and Linux* application debugging for all Intel SoC FPGA devices.
The Connections panel looks differently, based on the selected Target. For BareMetal Debug, Linux* Kernel, and Device Driver Debug target types, the following items appear:
- A Target Connection option appears and it allows you to select the type of connection to the target. Intel Intel® FPGA Download Cable and DSTREAM are two of the most common options.
- A DTSL option appears, allowing you to configure the Debug and Traces Services Layer (detailed later).
- A Connections Browse button appears, allowing you to browse and
select either of the specific instances for the connection— Intel
Intel® FPGA Download Cable or the DSTREAM instance.Figure 21. Connection Options for BareMetal, Linux* Kernel and Device Driver Debug
3.3.3.2. Files Options
The Files tab allows the following settings to be configured:
- Application on host to download – the file name of the application to be downloaded to the target. It can be entered directly in the edit box or it can be browsed for in the Workspace or on the File System.
-
Files – contains a set of files. A file can be added to the set using the “+” button, and files can be removed from the set using the “–“ button. Each file can be one of the following two types:
- Load symbols from file – the debugger uses that file to load symbols from it,
- Add peripheral description files from directory – the debugger to load peripheral register descriptions from the .SVD files stored in that directory. The SVD file is a result of the compilation of the hardware project.
3.3.3.3. Debugger Options
The Debugger tab offers the following configurable options
-
Run Control Options
- Option to connect only, debug from entry point or debug from user-defined symbol,
- Option to run user-specified target initialization script,
- Option to run user-specified debug initialization script,
- Option to execute user-defined debugger commands
- Host working directory – used by semihosting
- Paths – allows you to enter multiple paths for the debugger to search for sources. Paths can be added with “+” button and removed with “-“ button.
3.3.3.4. RTOS Awareness
The RTOS Awareness tab allows you to enable RTOS awareness for the debugger.
3.3.3.5. Arguments
The Arguments tab allows you to enter program arguments as text.
3.3.3.6. Environment
The Environment tab allows you to enter environment variables for the program to be executed.
3.3.4. DTSL Options
The Debug and Trace Services Layer (DTSL) provides tracing features. To configure trace options, in your project's Debug Configuration window, in the "Connection" tab, click the Edit button to open the DTSL Configuration window.
3.3.4.1. Cross Trigger Settings
The Cross Trigger tab allows the configuration of the cross triggering option of the SoC FPGA.
The following options are available:
- Enable FPGA > HPS Cross Trigger – for enabling triggers coming from FPGA to HPS
- Enable HPS > FPGA Cross Trigger – for enabling triggers coming from HPS to FPGA
3.3.4.2. Trace Capture Settings
The Trace Capture tab allows the selection of the destination of the trace information. As mentioned in the introduction, the destination can be one of the following:
- None – meaning the tracing is disabled
- ETR – using any memory buffer accessible by HPS
- ETF – using the 32KB on-chip trace buffer
- DSTREAM – using the 4GB buffer located in the DSTREAM
The DSTREAM option is available only if the Target connection is selected as DSTREAM in the Debug Configuration.
The Trace Buffer tab provides the option of selecting the timestamp frequency.
3.3.4.3. Cortex-A9 Settings
The Cortex-A9 tab allows the selection of the desired core tracing options.
The following Core Tracing Options are available:
- Enable Cortex-A9 0 core trace – check to enable tracing for core #0
- Enable Cortex-A9 1 core trace – check to enable tracing for core #1
- PTM Triggers halt execution – check to cause the execution to halt when tracing
- Enable PTM Timestamps – check to enable time stamping
- Enable PMT Context IDs – check to enable the context IDs to be traced
- Context ID Size – select 8-, 16- or 32-bit context IDs. Used only if Context IDs are enabled
- Cycle Accurate – check to create cycle accurate tracing
- Trace capture range – check to enable tracing only a certain address interval
- Start Address, End Address – define the tracing address interval (Used only if the Trace Capture Range is enabled)
3.3.4.4. STM Settings
The STM tab allows you to configure the System Trace Macrocell (STM).
Only one option is available:
- Enable STM Trace – check to enable STM tracing.
3.3.4.5. ETR Settings
The ETR settings allow the configuration of the Embedded Trace Router (ETR) settings.
The Embedded Trace Router is used to direct the tracing information to a memory buffer accessible by HPS.
The following options are available:
- Configure the system memory trace buffer – check this if the ETR is selected for trace destination on the Trace Capture tab.
- Start Address, Size – define the trace buffer location in system memory and its size.
- Enable scatter-gather mode – use when the OS cannot guarantee a contiguous piece of physical memory. The scatter-gather table is setup by the operating system using a device driver and is read automatically by the ETR.
3.3.4.6. ETF Settings
The ETF tab allows the configuration of the Embedded Trace FIFO (ETF) settings.
The Embedded Trace FIFO is a 32KB buffer residing on HPS that can be used to store tracing data to be retrieved by the debugger, but also as an elastic buffer for the scenarios where the tracing data is stored in memory through ETR or on the external DSTREAM device using TPIU.
The following options are available:
- Configure the on-chip trace buffer – check this if ETF is selected for trace destination on the Trace Capture tab.
- Size – define the ETF size. The default size is set to 0x8000 (32KB).
3.4. Arm Development Studio 5 Intel SoC FPGA Edition Revision History
| Document Version | Changes |
|---|---|
| 2019.12.20 | Supported with
Intel®
Quartus® Prime Standard Edition
version 19.1 and
Intel®
Quartus® Prime Pro Edition
version
19.3
|
| 2019.05.16 | Maintenance release |
| 2018.09.24 | Maintenance release |
| 2018.06.18 | Maintenance release |
| 2017.05.08 |
|
| 2016.11.07 | Maintenance release |
| 2016.05.27 | Maintenance release |
| 2016.02.17 | Updated default size in ETF Settings |
| 2015.08.06 | Added Intel® Arria® 10 SoC support |
4. Intel SoC FPGA EDS Licensing
The only SoC EDS component that requires a license is the Arm* DS-5* Intel® SoC FPGA Edition. The rest of the SoC EDS components, such as tools and software, do not require a license. This is the same for both Standard and Professional editions of SoC EDS.
- Arm* DS-5* Intel® SoC FPGA Edition License
- Arm* DS-5* Intel® SoC FPGA Edition Community Edition License
- 30-day Evaluation of Arm* DS-5* Intel® SoC FPGA Edition License
The following table shows the different debugging capabilities of the Arm* DS-5* Intel® SoC FPGA Edition Licenses:
| Licensing Option | Debugging Scenarios Enabled |
|---|---|
|
Arm* DS-5* Intel® SoC FPGA Edition Community Edition License |
|
|
Arm* DS-5* Intel® SoC FPGA Edition License, including the 30 day evaluation version |
|
- SoC EDS Paid license - using Arm* DS-5* Intel® SoC FPGA Edition license
- SoC EDS Free license - using Arm* DS-5* Intel® SoC FPGA Edition Community Edition license
4.1. Getting the License
Depending on the licensing option, it is necessary to follow the steps detailed for each option to obtain the license.
DS-5* Intel® SoC FPGA Edition Community Edition License - If you are using the SoC EDS Lite Edition, you are able to use the DS-5* Intel® SoC FPGA Edition perpetually to debug Linux* applications over an Ethernet connection. Get your Arm license activation code from the " DS-5* Intel® SoC FPGA Edition Community Edition" section on the DS-5* Intel® SoC FPGA Edition Development Studio page on the Arm website and then activate your license in DS-5* Intel® SoC FPGA Edition, as shown in the "Activating the License" section.
30-Day Evaluation of DS-5* Intel® SoC FPGA Edition License - If you want to evaluate the DS-5* Intel® SoC FPGA Edition, you can get a 30-Day Evaluation activation code from the " DS-5* Intel® SoC FPGA Edition 30-Day Evaluation" section on the DS-5* Intel® SoC FPGA Edition Development Studio page on the Arm website and then activate your license in Arm* DS-5* Intel® SoC FPGA Edition, as shown in the "Activating the License" section.
4.2. Activating the License
This section presents the steps required for activating the license in the Arm* DS-5* Intel® SoC FPGA Edition by using the serial license number or activation code that were mentioned in the "Getting the License" chapter.
-
The first time the
Arm*
DS-5*
Intel® SoC FPGA Edition is run, it notifies you that it
requires a license. Click the Open License
Manager button.
Figure 37. No License Found
-
If at any time it is required to change the license, select
to open the License
Manager.
Figure 38. Accessing Arm* License Manager
-
The
License Manager - View and edit licenses dialog
box opens and shows that a license is not available. Click the
Add License button.
Figure 39. Arm* License Manager
-
In the
Add License - Obtain a new licenses dialog box,
select the type of license to enter. In this example, select the radio button,
“Enter a serial number or activation code to obtain a license”
to enter the choices listed, below. When done, click
Enter.
- Arm* DS-5* Intel® SoC FPGA Edition—Enter the Arm* License Number.
- Arm* DS-5* Intel® SoC FPGA Edition Community Edition and 30-day Evaluation of Arm* DS-5* Intel® SoC FPGA Edition—Enter the Arm License Activation Code.
Figure 40. Add License - Obtain a New License
-
In the
Add License - Choose Host ID dialog box, select
the Host ID (Network Adapter MAC address) to tie the license to. If there are
more than one option, select the one you desire to lock the license to, and
click
Next.
Figure 41. Add License - Choose host ID
-
In the Add License - Developer
account details dialog box, enter an
Arm
developer (Silver) account. If you do not have an account, it can be created
easily by clicking the provided link. After entering the account information,
click Finish.
Figure 42. Add License - Developer Account Details
Note: The License Manager needs to be able to connect to the Internet in order to activate the license. If you do not have an Internet connection, you need to write down your Ethernet MAC address and generate the license directly from the Arm Self-Service web page on the Arm website, then select the "Already have a license" option in the License Manger.Note: Only the Arm* DS-5* Intel® SoC FPGA Edition, with an associated license number can be activated this way. The Arm* DS-5* Intel® SoC FPGA Edition Community Edition and 30-day Evaluation of Arm* DS-5* Intel® SoC FPGA Edition are based on activation codes, and these codes cannot be used on the Arm Self-Service web page on the Arm website. They need to be entered directly in the License Manager; which means an Internet connection is a requirement for licensing.The Arm License Manager uses the Eclipse settings to connect to the Internet. The default Eclipse settings use the system-wide configuration for accessing the Internet. In case the License Manager cannot connect to the Internet, you can try to change the Proxy settings by going to . Ensure that "HTTPS" proxy entry is configured and enabled.
-
After a few moments, the
Arm*
DS-5*
Intel® SoC FPGA Edition
activates the license
and display it in the License Manager.
Click Close.
Figure 43. Arm License Manager
4.3. Intel SoC FPGA EDS Licensing Revision History
| Document Version | Changes |
|---|---|
| 2019.12.20 | Supported with
Intel®
Quartus® Prime Standard Edition version 19.1
and
Intel®
Quartus® Prime Pro Edition version 19.3
|
| 2019.05.16 | Maintenance release |
| 2018.09.24 | Maintenance release |
| 2018.06.18 | Maintenance release |
| 2017.05.08 |
|
| 2016.11.07 | Maintenance release |
| 2016.05.27 | Renamed the Web and Subscription Editions to align with Quartus Prime naming |
| 2016.02.17 | Maintenance release |
| 2015.08.06 | Added Intel® Arria® 10 SoC support |
5. Embedded Command Shell
The purpose of the embedded command shell is to enable you to invoke the SoC EDS tools. It enables you to invoke the SoC EDS tools without qualifying them with the full path. Commands like eclipse, bsp-editor, or arm-altera-eabi-gcc can be executed directly.
<SoC EDS installation directory>\Embedded_Command_Shell.bat
<SoC EDS installation directory>/embedded_command_shell.sh
5.1. Embedded Command Shell Revision History
| Document Version | Changes |
|---|---|
| 2019.12.20 | Supported with Intel® Quartus® Prime Standard Edition version 19.1 and Intel® Quartus® Prime Pro Edition version 19.3 |
| 2019.05.16 | Maintenance release |
| 2018.09.24 | Maintenance release |
| 2018.06.18 | Maintenance release |
| 2017.05.08 |
|
| 2016.11.07 | Maintenance release |
| 2016.05.27 | Maintenance release |
| 2016.02.17 | Maintenance release |
| 2015.08.06 | Added Intel® Arria® 10 SoC support |
6. Boot Tools User Guide
6.1. Introduction
The boot flow for all the Intel SoC devices includes a bootloader. The bootloader has two stages called First Stage Bootloader (FSBL) and Second Stage Bootloader (SSBL). The FSBL is also known as Preloader.
The FSBL needs to fit into the on-chip RAM (OCRAM) and has limited functionality. It performs the tasks of initializing the HPS, bringing up the DDRAM and then loading and executing the next stage in the boot process. The next stage can be the SSBL, the end application, or an Operating System (OS).
The SSBL resides in DDRAM and therefore can have a larger size. Besides the ability to load and execute the next stage in the booting process, it typically offers a lot more functionality such as filesystem support, networking services, and command line interface.
On Cyclone® V SoC, Arria® V SoC and Intel® Arria® 10 SoC devices, the very first code run by HPS is the BootROM. For Intel® Stratix® 10 SoC and Intel® Agilex™ devices, the very first code run by HPS is the FSBL which is loaded by Secure Device Manager (SDM).
This chapter presents the tools that are used to enable the bootloader management:
- BSP Generator – enables you to get the Intel® Quartus® Prime handoff information and use it for the initial configuration of the bootloader for Cyclone® V SoC, Arria® V SoC and Intel® Arria® 10 SoC devices.
- Bootloader Image Tool ( mkpimage ) — enables you to add the BootROM-required header on top of the bootloader for Cyclone® V SoC, Arria® V SoC and Intel® Arria® 10 SoC devices.
- U-Boot Image Tool ( mkimage )— enables you to add the bootloader-required header on top of the files loaded by bootloader.
This chapter also includes instructions on how to build the bootloader for Intel® Stratix® 10 SoC and Intel® Agilex™ devices. For instructions on how to build the bootloader for Cyclone® V SoC, Arria® V SoC and Intel® Arria® 10 SoC, please visit "Building Bootloader" on RocketBoards.org.
6.2. BSP Generator
The BSP Generator allows you to create a new BSP with the default settings, based on the handoff information from Intel® Quartus® Prime.
The generated BSP includes a makefile, which outputs a message pointing you to visit "Building Bootloader" on RocketBoards.org to get details on how to build the bootloader.
6.2.1. BSP Generation Flow
This section presents the BSP generation flow for the Cyclone® V SoC, Arria® V SoC, and Intel® Arria® 10 SoC bootloader. While the flows are similar, there are some important differences.
6.2.1.1. Cyclone V SoC and Arria V SoC Flow
For Cyclone® V SoC and Arria® V SoC, the BSP Generator is required to be run first, to convert some of the handoff files into C source code. After that, you need to clone the U-Boot source code from github. Then you use an U-Boot script called qts-filter to extract the information from the handoff folder, and the set of files created by the BSP Generator, and put them in the U-Boot source code folder. Then you use the U-Boot makefile to build the SPL image. The SPL image can then be downloaded to a Flash device or FPGA RAM to be used for booting HPS.
The hardware handoff information contains various settings that you entered when creating the hardware design in Platform Designer (Standard) and Intel® Quartus® Prime Standard Edition. These include the following:
- Pin-muxing for the HPS dedicated pins
- I/O settings for the HPS dedicated pins:
- Voltage
- Slew rate
- Pull up/ down
- State of HPS peripherals:
- Enabled
- Disabled
- Configuration of the bridges between HPS and FPGA
- Clock tree settings:
- PLL settings
- Clock divider settings
- Clock gating settings
- DDR settings:
- Technology
- Width
- Speed
The handoff settings are output from the Intel® Quartus® Prime Standard Edition compilation and are located in the <quartus project directory>/hps_isw_handoff/<hps entity name> directory (where <hps entity name > is the HPS component name in Platform Designer (Standard)).
You must update the hardware handoff files and regenerate the BSP each time a hardware change impacts the HPS, such as after pin multiplexing or pin assignment changes.
For complete instructions on how to build the bootloader for Cyclone® V SoC and Arria® V SoC, please visit "Building Bootloader" on RocketBoards.org.
6.2.1.2. Intel Arria 10 SoC Flow
The next step is to clone the U-Boot source code from GitHub, and copy the generated device tree into U-Boot source code. For complete instructions, go to the Building Bootloader web page on RocketBoards.org. Then the U-Boot is compiled using the make utility and it creates the combined bootloader image, which contains both the bootloader executable and the bootloader device tree. You can download the combined image to a Flash device or FPGA RAM to use for booting the HPS.
The hardware handoff information contains various settings that you entered when creating the hardware design in Platform Designer.. These include the following:
- Pin-muxing for the HPS dedicated pins
- I/O settings for the HPS dedicated pins:
- Voltage
- Slew rate
- Pull up/ down
- Pin-muxing for the shared pins
- State of HPS peripherals:
- Enabled
- Disabled
- Configuration of the bridges between HPS and FPGA
- Clock tree settings:
- PLL settings
- Clock divider settings
- Clock gating settings
The handoff settings are output from the Intel® Quartus® Prime Standard Edition compilation and are located in the <quartus project directory>/hps_isw_handoff directory.
The user must run the BSP Generator and re-generate the Bootloader device tree each time a hardware change results in a change of the above parameters.
However, you does not have to always recompile the Bootloader whenever a hardware setting is changed. The Bootloader needs to be recompiled only when changing the boot source.
6.2.2. BSP Generator Graphical User Interface
The BSP generator GUI is deprecated, and you do not need to use it anymore. The settings are now customized directly in the bootloader files, and not from the BSP Generator. Only the bsp-create-settings command line tool needs to be ran, but without customized options, as they are not taken into consideration.
6.2.3. BSP Generator Command Line Interface
The BSP command-line tools can be invoked from the embedded command shell, and provide the following feature:
bsp-create-settings—a tool that converts the Intel® Quartus® Prime handoff information to source code for Cyclone® V SoC and Arria® V SoC, and to a Device Tree for Intel® Arria® 10 SoC.
- bsp-update-settings
- bsp-query-settings
- bsp-generate-files
6.2.3.1. bsp-create-settings
The bsp-create-settings tool converts the Intel® Quartus® Prime handoff information to source code for Cyclone® V SoC and Arria® V SoC, and to a Device Tree for Intel® Arria® 10 SoC.
| Option | Required | Description |
|---|---|---|
| --type <bsp-type> |
Yes |
This option specifies the type of BSP. Allowed values
are:
|
| --settings <filename> |
Yes |
This option specifies the path to a BSP settings file. The file is created with default settings.Intel recommends that you name the BSP settings file settings.bsp. |
| --preloader-settings-dir <directory> |
Yes |
This option specifies the path to the hardware handoff files. |
| --bsp-dir <directory> |
Yes |
This option specifies the path where the BSP files are generated. When specified, bsp-create-settings generates the files after the settings file has been created.Intel recommends that you always specify this parameter with bsp-create-settings. |
| --set <name> <value> |
No |
This option sets the BSP setting <name> to the value <value>. Multiple instances of this option can be used with the same command. Refer to BSP Settings for a complete list of available setting names and descriptions. |
6.2.4. BSP Files and Folders
The files and folders created with the BSP Generator are stored in the location you specified in BSP target directory in the New BSP dialog box.
For Cyclone® V SoC/Arria Preloader BSPs, the generated files include the following:
- settings.bsp – file containing all BSP settings
- Makefile – makefile used to compile the Preloader and create the preloader image; for more information, refer to Preloader Compilation
- preloader.ds – deprecated, and not used
- generated – folder containing files generated from the hardware handoff files
For Intel® Arria® 10 SoC Bootloader BSPs the generated files include the following:
- settings.bsp – file containing all BSP settings
- Makefile – makefile used to compile the Bootloader, convert the Bootloader device tree file to binary, and create the combined Bootloader and Bootloader Device Tree image; for more information, refer to Preloader Compilation
- config.mk – deprecated, and not used
- devicetree.dts – Bootloader device tree, containing the Bootloader customization details, derived from the handoff files and you settings
6.2.5. BSP Settings
6.3. Bootloader Image Tool (mkpimage)
The Bootloader Image Tool (mkpimage) creates an Intel BootROM-compatible image of the Arria® V SoC and Cyclone® V SoC Preloader or Intel® Arria® 10 SoC Bootloader. The tool can also decode the header of previously generated images.
The mkpimage tool makes the following assumptions:
- The input file format is raw binary. You must use the objcopy utility provided with the GNU Compiler Collection (GCC) tool chain from the Mentor Graphics* website to convert other file formats, such as Executable and Linking Format File (.elf), Hexadecimal (Intel-Format) File (.hex), or S-Record File (. srec), to a binary format.
- The output file format is binary.
- The tool always creates the output image at the beginning of the binary file. If the image must be programmed at a specific base address, you must supply the address information to the flash programming tool.
- The output file contains only Preloader or Bootloader images. Other
images such as Linux*, SRAM Object File (.sof) and user data are programmed separately
using a flash programming tool or related utilities in the U-boot on the target
system.Figure 48. Basic Operation of the mkpimage Tool
6.3.1. Operation
The mkpimage tool runs on a host machine. The tool generates the header and CRC checksum and inserts them into the output image with the bootloader program image and its exception vector.
For certain flash memory tools, the position of the bootloader images must be aligned to a specific block size; the mkpimage tool generates any padding data that may be required.
The mkpimage tool optionally decodes and validates header information when given a pre-generated bootloader image.
As illustrated, the binary bootloader image is an input to the mkpimage tool. The compiler leaves an empty space between the bootloader exception vector and the program. The mkpimage tool overwrites this empty region with header information and calculates a checksum for the whole image.
When necessary, the mkpimage tool appends the padding data to the output image.
The mkpimage tool can operate with either one or four input files. Operation on four input files consists in processing each file individually, then concatenating the four resulted images.
6.3.2. Header File Format
The mkpimage header file format has two versions:
- Version 0, used for Cyclone® V SoC and Arria® V SoC FSBL (Preloader)
- Version 1, used for Intel® Arria® 10 SoC Bootloader
For Version 0, used for Cyclone® V SoC and Arria® V SoC Preloader, the header includes the following:
- Validation word (0x31305341)
- Version field (set to 0x0)
- Flags field (set to 0x0)
- Program length measured by the number of 32 bit words in the Preloader program
- 16-bit checksum of the header contents (0x40 – 0x49)
For Version 1, used for Intel® Arria® 10 SoC Bootloader, the header includes the following:
- Validation word (0x31305341).
- Version field (set to 0x1).
- Flags field (set to 0x0).
- Header length, in bytes, set to 0x14 (20 bytes).
- Total program length (including the exception vectors and the CRC field) in bytes. For an image to be valid, length must be a minimum of 0x5C (92 bytes) and a maximum of 0x32000 (200KiB).
- Program entry offset relative to the start of header (0x40) and should be 32-bit word-aligned. Default is 0x14, any value smaller than that is invalid.
- 16-bit checksum of the header contents (0x40 – 0x51):Figure 50. Header Format Version 1
The header checksum for both versions of the mkpimage header is the CRC checksum of the byte value from offset 0x0 to (n*4)-4 bytes where n is the program length.
x32 + x26 + x23 + x22 + x16 + x12 + x11 + x10 + x8 + x7 + x5 + x4 + x2 + x + 1There is no reflection of the bits and the initial value of the remainder is 0xFFFFFFFF and the final value is exclusive OR-ed with 0xFFFFFFFF.
6.3.3. Tool Usage
The mkimage tool has three usage models:
- Single image creation
- Quad image creation
- Single or quad image decoding
If an error is found during the make image process, the tool stops and reports the error. Possible error conditions include:
- For Cyclone® V SoC and Arria® V SoC Preloaders: input image is smaller than 81 bytes or larger than 60 KB.
- For Intel® Arria® 10 SoC Bootloaders: input image is smaller than 92 bytes or larger than 200 KB.
Type mkpimage to launch the tool. The --help option provides a tool description and tool usage and option information.
$ mkpimage --help mkpimage version 19.1 Description: This tool creates an Intel BootROM-compatible image of Second Stage Boot Loader (SSBL). The input and output files are in binary format. It can also decode and check the validity of previously generated image. Usage: Create quad image: mkpimage [options] -hv <num> -o <outfile> <infile> <infile> <infile> <infile> Create single image: mkpimage [options] -hv <num> -o <outfile> <infile> Decode single/quad image: mkpimage -d [-a <num>] <infile> Options: -a (--alignment) <num> : Address alignment in kilobytes for output image (64, 128, 256, etc.), default to 64 for header version 0 and 256 for header version 1, override if the NAND flash has a different block size. If outputting a single image, value of '0' is permitted to specify no flash block padding (needed for SSBL image encryption). -d (--decode) : Flag to decode the header information from input file and display it -f (--force) : Flag to force decoding even if the input file is an unpadded image -h (--help) : Display this help message and exit -hv (--header-version) <num> : Header version to be created (Arria/ Cyclone® V SoC = 0, Intel® Arria® 10 SoC = 1) -o (--output) <outfile> : Output file, relative and absolute path supported -off (--offset) <num> : Program entry offset relative to start of header (0x40), default to 0x14. Used for header version 1 only -v (--version) : Display version and exit
6.3.4. Output Image Layout
6.3.4.1. Base Address
The bootable SSBL image must be placed at 0x0 for NAND and QSPI flash. For SD/MMC the image can also be placed at 0x0, but typically the image is placed at offset 0x0 in a custom partition of type 0xA2. The custom partition does not have a filesystem on it. The BootROM is able to locate the partition using the MBR (Master Boot Record) located at 0x0 on the SD/MMC card.
The mkpimage tool always places the output image at the start of the output binary file, regardless of the target flash memory type. The flash programming tool is responsible for placing the image at the desired location on the flash memory device.
6.3.4.2. Size
For Cyclone® V SoC and Arria® V SoC, a single Preloader has a maximum 60 KB image size. You can store up to four preloader images in flash. If the BootROM does not find a valid preloader image at the first location, it attempts to read an image from the next location and so on. To take advantage of this feature, program four preloader images in flash.
For Intel® Arria® 10 SoC, a single Bootloader has a maximum 200 KB image size. You can store up to four Bootloader images in flash. If the BootROM does not find a valid Bootloader image at the first location, it attempts to read the next one and so on. To take advantage of this feature, program four Bootloader images in flash.
6.3.4.3. Address Alignment
For Cyclone® V SoC and Arria® V SoC, every Preloader image has to be aligned to a 64KB boundary, except for NAND devices. For NAND devices, each Preloader image has to be aligned to the greater of 64 KB or NAND block size.
For Intel® Arria® 10 SoC, every Bootloader image has to be aligned to a 256 KB boundary, except for NAND devices. For NAND devices, each Bootloader image has to be aligned to the greater of 256 KB or NAND block size.
The following tables present typical image layouts, that are used for QSPI, SD/MMC and NAND devices with NAND erase block size equal or less to 64 KB (for Cyclone® V SoC/ Arria® V SoC) or 256 KB (for Intel® Arria® 10 SoC).
|
Offset |
Image |
|---|---|
|
0x30000 |
Preloader Image 3 |
|
0x20000 |
Preloader Image 2 |
|
0x10000 |
Preloader Image 1 |
|
0x00000 |
Preloader Image 0 |
|
Offset |
Image |
|---|---|
|
0xC0000 |
Bootloader Image 3 |
|
0x80000 |
Bootloader Image 2 |
|
0x40000 |
Bootloader Image 1 |
|
0x00000 |
Bootloader Image 0 |
The mkpimage tool is unaware of the target flash memory type. If you do not specify the block size, the default is 64 KB.
6.3.4.3.1. NAND Flash
Each Preloader or Bootloader image occupies an integer number of blocks. A block is the smallest entity that can be erased, so updates to a particular boot image do not impact the other images.
For example for Cyclone® V SoC and Arria® V SoC, a single Preloader image has a maximum size of 64 KB. But it the NAND block is 128 KB, then the Preloader images will need to be located at 128 KB intervals.
6.3.4.3.2. Serial NOR Flash
Each QSPI boot image occupies an integer number of sectors unless subsector erase is supported; this ensures that updating one image does not affect other images.
6.3.4.3.3. SD/MMC
The master boot record, located at the first 512 bytes of the device memory, contains partition address and size information. The Preloader and Bootloader images are stored in partitions of type 0xA2. Other items may be stored in other partition types according to the target file system format.
You can use the fdisk tool to set up and manage the master boot record. When the fdisk tool partitions an SD/MMC device, the tool creates the master boot record at the first sector, with partition address and size information for each partition on the SD/MMC.
6.3.4.4. Padding
The mkimage tool inserts a CRC checksum in the unused region of the image. Padding fills the remaining unused regions. The contents of the padded and unused regions of the image are undefined.
6.4. U-Boot Image Tool (mkimage)
Both the FSBL and SSBL require the presence of the U-Boot image header at the beginning of the next stage boot image. Depending on usage scenario, other items that are loaded by either Preloader or Bootloader may also require the presence of the U-Boot image header.
The mkimage utility is delivered with SoC EDS and can be used to append the U-Boot image header to the next stage boot image or any other required files.
The header consists of the following items:
- Image magic number - determines if the image is a valid boot image
- Image data size - the length of the image to be copied
- Data load address - the entry point of the boot image (not used for items that are not bootable images)
- Operating system - determines the type of image
- Image name - the name of the boot image
- Image CRC - the checksum value of the boot image
6.4.1. Tool Options
$ mkimage --help
Usage: mkimage -l image
-l ==> list image header information
mkimage [-x] -A arch -O os -T type -C comp -a addr -e ep -n name -d data_file[:data_file...] image
-A ==> set architecture to 'arch'
-O ==> set operating system to 'os'
-T ==> set image type to 'type'
-C ==> set compression type 'comp'
-a ==> set load address to 'addr' (hex)
-e ==> set entry point to 'ep' (hex)
-n ==> set image name to 'name'
-d ==> use image data from 'datafile'
-x ==> set XIP (execute in place)
mkimage [-D dtc_options] [-f fit-image.its|-F] fit-image
-D => set options for device tree compiler
-f => input filename for FIT source
Signing / verified boot not supported (CONFIG_FIT_SIGNATURE undefined)
mkimage -V ==> print version information and exit
6.4.2. Usage Examples
Creating a U-boot Image
mkimage –A arm –T firmware –C none –O u-boot –a 0x08000040 –e 0 –n "U-Boot 2014.10 for SOCFGPA board" –d u-boot.bin u-boot.img
Creating a BareMetal Application Image
mkimage -A arm -O u-boot -T standalone -C none -a 0x02100000 -e 0 -n "baremetal image" -d hello_world.bin hello_world.img
6.5. Building the Bootloader
6.5.1. Building the Cyclone V SoC and Arria V SoC Preloader
For complete details on how to build the Cyclone® V SoC and Arria® V SoC bootloaders, please visit "Building Bootloader" on RocketBoards.org.
6.5.2. Building the Intel Arria 10 SoC Bootloader
For complete details on how to build the Intel® Arria® 10 SoC bootloaders, please visit "Building Bootloader" on RocketBoards.org.
6.5.3. Building the Intel Stratix 10 SoC and Intel Agilex Devices
On Intel® Stratix® 10 SoC and Intel® Agilex™ devices, the SDM loads the FSBL from the configuration bitstream. The configuration bitstream contains the hardware handoff data, which is made available to the FSBL. Because of this, there is no need for a Bootloader Generator tool to pass additional information to the Bootloader building process.
For details about ATF and UEFI, refer to Intel® Stratix® 10 SoC UEFI Boot Loader User Guide.
For details about the Intel® Stratix® 10 SoC bootloaders, refer to the Intel® Stratix® 10 SoC FPGA Boot User Guide.
6.6. Boot Tools User Guide Revision History
| Document Version | Changes |
|---|---|
| 2019.12.20 | Supported with
Intel®
Quartus® Prime Standard Edition
version 19.1 and
Intel®
Quartus® Prime Pro Edition
version
19.3
|
| 2019.05.16 |
|
| 2018.09.24 | Updated the path names, in the "Building the Intel® Stratix® 10 SoC Bootloader" section, to coincide with the 18.1 release. |
| 2018.06.18 |
|
| 2017.05.08 |
|
| 2016.11.7 | Added an "UEFI Build Flow" section |
| 2016.05.27 | Added a link to the Intel® Arria® 10 SoC Secure Boot User Guide |
| 2016.02.17 |
|
| 2015.08.06 | Added Intel® Arria® 10 SoC support |
7. Hardware Library
The Intel SoC FPGA Hardware Library (HWLIB) was created to address the needs of low-level software programmers who require full access to the configuration and control facilities of SoC FPGA hardware. An additional purpose of the HWLIB is to mitigate the complexities of managing the operation of a sophisticated, multi-core application processor and its integration with hardened IP peripheral blocks and programmable logic in a SoC architecture.
Within the context of the SoC hardware and software ecosystem, the HWLIB is capable of supporting software development in conjunction with full featured operating systems or standalone BareMetal programming environments. The relationship of the HWLIB within a complete SoC HW/SW environment is illustrated in the above figure.
The HWLIB provides a symbolic register abstraction layer known as the SoC Abstraction Layer (SoCAL) that enables direct access and control of HPS device registers within the address space. This layer is necessary for enabling several key stakeholders (boot loader developers, driver developers, BSP developers, debug agent developers, and board bring-up engineers) requiring a precise degree of access and control of the hardware resources.
The HWLIB also deploys a set of Hardware Manager (HW Manager) APIs that provides more complex functionality and drivers for higher level use case scenarios.
The HWLIB has been developed as a source code distribution. The intent of this model is to provide a useful set of out-of-the-box functionality and to serve as a source code reference implementation that a user can tailor accordingly to meet their target system requirements.
The capabilities of the HWLIB are expected to evolve and expand over time particularly as common use case patterns become apparent from practical application in actual systems.
In general, the HWLIB assumes to be part of the system software that is executing on the Hard Processor System (HPS) in privileged supervisor mode and in the secure state.
The anticipated HWLIB clients include:
- BareMetal application developers
- Custom preloader and boot loader software developers
- BSP developers
- Diagnostic tool developers
- Software driver developers
- Debug agent developers
- Board bring-up engineers
- Other developers requiring full access to SoC FPGA hardware capabilities
7.1. Feature Description
This section provides a description of the operational features and functional capabilities present in the HWLIB. An overview and brief description of the HWLIB architecture is also presented.
The HWLIB is a software library architecturally comprised of two major functional components:
- SoC Abstraction Layer (SoCAL)
- HW Manager
7.1.1. SoC Abstraction Layer (SoCAL)
The SoC Abstraction Layer (SoCAL) presents the software API closest to the actual HPS hardware. Its purpose is to provide a logical interface abstraction and decoupling layer to the physical devices and registers that comprise the hardware interface of the HPS.
The SoCAL provides the benefits of:
- A logical interface abstraction to the HPS physical devices and registers including the bit-fields comprising them.
- A loosely coupled software interface to the underlying hardware that promotes software isolation from hardware changes in the system address map and device register bit field layouts.
7.1.2. HW Manager
The HW Manager component provides a group of functional APIs that address more complex configuration and operational control aspects of selected HPS resources.
The HW Manager functions have the following characteristics:
- Functions employ a combination of low level device operations provided by the SoCAL executed in a specific sequence to effect a desired operation.
- Functions may employ cross functional (such as from different IP blocks) device operations to implement a desired effect.
- Functions may have to satisfy specific timing constraints for the application of operations and validation of expected device responses.
- Functions provide a level of user protection and error diagnostics through parameter constraint and validation checks.
The HW Manager functions are implemented using elemental operations provided by the SoCAL API to implement more complex functional capabilities and services. The HW Manager functions may also be implemented by the compound application of other functions in the HW Manager API to build more complex operations (for example, software controlled configuration of the FPGA).
7.2. Hardware Library Reference Documentation
Reference documentation for the SoCAL and HW Manager are distributed as part of the Intel® SoC FPGA EDS. The documentation is in HTML format and is located at <SoC EDS installation directory>/ip/altera/hps/doc. You can view this documentation with any web browser.
7.3. System Memory Map
The addresses of the HPS hard IP modules are accessible through the provided SoCAL macros. SoCAL also provides macros for accessing the individual registers and register fields of the HPS hard IP modules.
For the FPGA IP modules, the macros for accessing IP registers and register fields are usually part of the IP deliverables. However, the actual IP modules-based addresses are often changed at system integration time, in the Platform Designer (Standard) tool.
The basic usage of the tool is to invoke it with the .sopcinfo file as a single parameter. For example, in order to generate the include files for the Intel® Arria® 10 SoC GHRD, the following command can be executed in that folder: sopc-create-header-files ghrd_10as066n2.sopcinfo.
The tool creates a separate include file for each of the masters in the system, showing the system addresses from that master's point of view. Use the file <hps_component_name>_a9_0.h for HPS software development, as it shows the system addresses from the HPS point of view.
sopc-create-header-files ghrd_10as066n2.sopcinfo --module\ arria10_hps_0_arm_a9_0 --single arria10_hps_0_arm_a9_0.h
This creates just one file, called "arria10_hps_0_arm_a9_0.h".
You can also run "sopc-create-header-files --help" for more details about the tool, or refer to Intel® Quartus® Prime Standard Edition documentation.
7.4. Hardware Library Revision History
| Document Version | Changes |
|---|---|
| 2019.12.20 | Supported with
Intel®
Quartus® Prime Standard Edition version 19.1 and
Intel®
Quartus® Prime Pro Edition version
19.3
|
| 2019.05.16 | Maintenance release |
| 2018.09.24 | Updated the location and format to find the reference documentation for the SoCAL and HW Manager. |
| 2018.06.18 |
|
| 2017.05.08 |
|
| 2016.11.07 | Maintenance release |
| 2016.05.27 | Maintenance release |
| 2016.02.17 |
|
| 2015.08.06 | Added Intel® Arria® 10 SoC support |
8. HPS Flash Programmer User Guide
The Intel® Quartus® Prime software and Intel® Quartus® Prime Programmer include the HPS flash programmer. Hardware designs, such as HPS, incorporate flash memory on the board to store FPGA configuration data or HPS program data. The HPS flash programmer programs the data into a flash memory device connected to an Intel® FPGA SoC. The programmer sends file contents over an Intel® download cable, such as the Intel® FPGA Download Cable II, to the HPS and instructs the HPS to write the data to the flash memory.
The HPS flash programmer programs the following content types to flash memory:
- HPS software executable
files — Many systems use flash memory to store non-volatile program code or
firmware. HPS systems can boot from flash memory. Note: The HPS Flash Programmer is mainly intended to be used for programming the Preloader image to QSPI or NAND flash. Because of the low speed of operation, it is not recommended to be used for programming large files.
- FPGA configuration data — At system power-up, the FPGA configuration controller on the board or HPS read FPGA configuration data from the flash memory to program the FPGA. The configuration controller or HPS may be able to choose between multiple FPGA configuration files stored in flash memory.
- Other arbitrary data files — The HPS flash programmer programs a binary file to any location in a flash memory for any purpose. For example, a HPS program can use this data as a coefficient table or a sine lookup table.
- Quad serial peripheral interface (QSPI) Flash
- Open NAND Flash Interface (ONFI) compliant NAND Flash
- Use a bus switch to route the EPCQ-L/QSPI signals to an external master that does the programming.
- Use software running on HPS to do the programming. For example, U-Boot can be loaded with an Arm* debugger or System Console, and then used to program the flash.
8.1. HPS Flash Programmer Command-Line Utility
- For the Quartus Prime software, the HPS flash programmer is located in the <Quartus Prime installation directory>/quartus/bin directory.
- For the SoC EDS software, the HPS flash programmer is located in the <SoC EDS installation directory>/ qprogrammer/bin directory.
8.2. How the HPS Flash Programmer Works
The HPS flash programmer determines the type of flash to program by sampling the boot select (BSEL) pins during cold reset; you do not need to specify the type of flash to program.
8.3. Using the Flash Programmer from the Command Line
8.3.1. HPS Flash Programmer
The HPS flash programmer command-line syntax is:
quartus_hps <options> <file.bin>
| Option | Short Option | Required | Description |
|---|---|---|---|
| --addr | -a |
Yes (if the start address is not 0) |
This option specifies the start address of the operation to be performed. |
| --cable | -c |
Yes |
This option specifies what download cable to use. To obtain the list of programming cables, run the command "jtagconfig". It lists the available cables, like in the following example:
jtagconfig
The "-c"
parameter can be the number of the programming cable, or its
name. The following are valid examples for the above case:
|
| --device | -d |
Yes (if there are multiple HPS devices in the chain) |
This option specifies the index of the HPS device. The tool automatically detects the chain and determine the position of the HPS device; however, if there are multiple HPS devices in the chain, the targeted device index must be specified. |
| --boot | N/A | Yes |
Option to reconfigure the HPS IOCSR and PINMUX before starting flash programming. The
Intel®
Quartus® Prime HPS Flash Programmer options are:
Available options are:
Cyclone® V SoC and Intel® Arria® 10 SoC support values: 1, 2 and 16.
Intel®
Arria® 10 SoC supports values: 2, 3 and
16
Note: For the first three options, add up integer
of 16, so that the HPS cold reset is performed
|
| --exit_xip | N/A | Yes (if the QSPI flash device has been put into XIP mode) | This option exits the QSPI flash device from XIP mode. A non-zero value has to be specified for the argument. For example, quartus_hps -c <cable> -o <operation> --exit_xip=0x80. |
| --operation | -o |
Yes |
This option specifies the operation to be performed. The following operations are supported:
Note: The program begins with erasing the flash operation before
programming the flash by default.
|
| --size | -s |
No |
This option specifies the number of bytes of data to be performed by the operation. size is optional. |
|
Note: The following options: repeat
and interval must be used
together and are optional.
The HPS BOOT flow supports up to four images where each image is identical. These options duplicate the operation data; therefore you do not need embedded software to create a large file containing duplicate images. |
|||
| --repeat | -t | No | repeat—specifies the number of duplicate images for the operation to perform. |
| --interval | -i | No | interval—specifies the repeated address. The default value is 64 kilobytes (KB). |
8.3.2. HPS Flash Programmer Command Line Examples
Program File to Address 0 of Flash
quartus_hps –c 1 –o P input.bin programs the input file (input.bin) into the flash, starting at flash address 0 using a cable M.Program First 500 Bytes of File to Flash (Decimal)
quartus_hps –c 1 –o PV –a 1024 –s 500 input.bin programs the first 500 bytes of the input file (input.bin) into the flash, starting at flash address 1024, followed by a verification using a cable M.Program First 500 Bytes of File to Flash (Hexadecimal)
quartus_hps –c 1 –o PV –a 0x400 –s 500 input.bin programs the first 500 bytes of the input file (input.bin) into the flash, starting at flash address 1024, followed by a verification using a cable M.Program File to Flash Repeating Twice at Every 1 MB
quartus_hps –c 1 –o BPV –t 2 –i 0x100000 input.bin programs the input file (input.bin) into the flash, using a cable M. The operation repeats itself twice at every 1 megabyte (MB) of the flash address. Before the program operation, the tool ensures the flash is blank. After the program operation, the tool verifies the data programmed.Erase Flash on the Flash Addresses
quartus_hps –c 1 –o EB input.bin erases the flash on the flash addresses where the input file (input.bin) resides, followed by a blank-check using a cable M.Erase Full Chip
quartus_hps –c 1 –o E erases the full chip, using a cable M. When no input file (input.bin) is specified, it erases all the flash contents.Erase Specified Memory Contents of Flash
quartus_hps –c 1 –o E –a 0x100000 –s 0x400000 erases specified memory contents of the flash. For example, 4 MB worth of memory content residing in the flash address, starting at 1 MB, are erased using a cable M.Examine Data from Flash
quartus_hps –c 1 –o X –a 0x98679 –s 56789 output.bin examines 56789 bytes of data from the flash with a 0x98679 flash start address, using a cable M.8.4. Supported Memory Devices
| Flash Device | Manufacturer | Device ID | DIE # | Density (Mb) | Voltage |
|---|---|---|---|---|---|
| M25P40 | Micron | 0x132020 | 1 | 4 | 3.3 |
| N25Q064 | Micron | 0x17BA20 | 1 | 64 | 3.3 |
| N25Q128 | Micron | 0x18BA20 | 1 | 128 | 3.3 |
| N25Q128 | Micron | 0x18BB20 | 1 | 128 | 1.8 |
| N25Q256 | Micron | 0x19BA20 | 1 | 256 | 3.3 |
| N25Q256 | Micron | 0x19BB20 | 1 | 256 | 1.8 |
| MT25QL512 | Micron | 0x20BA20 | 1 | 512 | 3.3 |
| N25Q512 | Micron | 0x20BA20 | 2 | 512 | 3.3 |
| MT25QU512 | Micron | 0x20BB20 | 1 | 512 | 1.8 |
| N25Q512A | Micron | 0x20BB20 | 2 | 512 | 1.8 |
| N25Q00AA | Micron | 0x21BA20 | 4 | 1024 | 3.3 |
| MT25QU01G | Micron | 0x21BB20 | 2 | 1024 | 1.8 |
| N25Q00AA | Micron | 0x21BB20 | 4 | 1024 | 1.8 |
| MT25QL02G | Micron | 0x22BA20 | 4 | 2048 | 3.3 |
| MT25QU02G | Micron | 0x22BB20 | 4 | 2048 | 1.8 |
| S25FL128S | Cypress | 0x182001 | 1 | 128 (64KB Sectors) | 3.3 |
| S25FL128S | Cypress | 0x182001 | 1 | 128 (256KB Sectors) | 3.3 |
| S25FL256S | Cypress | 0x190201 | 1 | 256 (64KB Sectors) | 3.3 |
| S25FL256S | Cypress | 0x190201 | 1 | 256 (256KB Sectors) | 3.3 |
| S25FL512S | Cypress | 0x200201 | 1 | 512 | 3.3 |
| MX25L12835E | Macronix | 0x1820C2 | 1 | 128 | 3.3 |
| MX25L25635 | Macronix | 0x1920C2 | 1 | 256 | 3.3 |
| MX66L51235F | Macronix | 0x1A20C2 | 1 | 512 | 3.3 |
| MX66L1G45 | Macronix | 0x1B20C2 | 1 | 1024 | 3.3 |
| MX66U51235 | Macronix | 0x3A25C2 | 1 | 512 | 1.8 |
| GD25Q127C | GigaDevice | 0x1840C8 | 1 | 128 | 3.3 |
| Manufacturer | MFC ID | Device ID | Density (Gb) |
|---|---|---|---|
|
Micron |
0x2C |
0x68 |
32 |
|
Micron |
0x2C |
0x48 |
16 |
|
Micron |
0x2C |
0xA1 |
8 |
|
Micron |
0x2C |
0xF1 |
8 |
8.5. HPS Flash Programmer User Guide Revision History
| Document Version | Changes |
|---|---|
| 2019.12.20 | Supported with
Intel®
Quartus® Prime Standard Edition version 19.1
and
Intel®
Quartus® Prime Pro Edition version 19.3
|
| 2019.05.16 | HPS Flash Programmer: Documented --boot=18 for QSPI programming |
| 2018.09.24 | Added supported memory devices in the "QSPI Flash" table; and updated voltages for several flash devices. |
| 2018.06.18 |
|
| 2017.05.08 |
|
| 2016.11.07 | Maintenance release |
| 2016.05.27 | Maintenance release |
| 2016.02.17 | Added QSPI Flash part number to the QSPI Flash table in the "Supported Memory Devices" chapter |
| 2015.08.06 | Added Intel® Arria® 10 SoC support |
9. BareMetal Compilers
- Arm* BareMetal Compiler 5 (ARMCC)
- Arm* BareMetal Compiler 6 (LLVM-based)
- Mentor Graphics* Sourcery™ CodeBench Lite Edition (GCC based)
9.1. Arm BareMetal Compilers
The Arm* BareMetal compilers are part of the Arm* DS-5* Intel® SoC FPGA Edition.
The Arm* BareMetal Compiler 5 targets 32-bit platforms (Cortex-A9 on Cyclone® V SoC, Arria® V SoC and Intel® Arria® 10 SoC).
The Arm* BareMetal Compiler 6 targets both 32-bit platforms and 64-bit platforms (Cortex-A53 on Intel® Stratix® 10 SoC).
The Arm* BareMetal compilers documentation is integrated in Arm* DS-5* Intel® SoC FPGA Edition, like with all the Arm* DS-5* Intel® SoC FPGA Edition components.
9.2. Mentor Graphics Code Sourcery Compiler
The BareMetal compiler that is shipped with the SoC EDS is the Mentor Graphics* Sourcery™ CodeBench Lite. For the current version, refer to Table 1.
For more information on the Sourcery CodeBench Lite Edition and to download the latest version of the tools, refer to the Mentor Graphics* website.
- Targets the Arm* processor
- Assumes BareMetal operation
- Uses the standard Arm* embedded-application binary interface (EABI) conventions.
<SoC EDS installation directory>/host_tools/mentor/gnu/arm/baremetal
The Embedded Command Shell sets the correct environment PATH variables for the BareMetal compilation tools to be invoked. You can open the shell from the <SoC EDS installation directory>. After starting the shell, commands like arm-altera-eabi-gcc can be invoked directly. When the Arm* Development Studio 5* Intel® SoC FPGA Edition environment is started from the embedded command shell, it inherits the environment settings, and it can call these compilation tools directly.
<SoC EDS installation directory>/host_tools/mentor/gnu/arm/baremetal/bin
<SoC EDS installation directory>/host_tools/mentor/gnu/arm/baremetal/share/doc/sourceryg++-arm-altera-eabi
- HTML files
- Info files
- Man pages
- PDF files
- Compiler manual
- Assembler manual
- Linker manual
- Binutils manual
- GDB manual
- Libraries Manual
9.3. BareMetal Compilers Revision History
| Document Version | Changes |
|---|---|
| 2019.12.20 | Supported with
Intel®
Quartus® Prime Standard Edition version 19.1 and
Intel®
Quartus® Prime Pro Edition version
19.3
|
| 2019.05.16 | Maintenance release |
| 2018.09.24 | Maintenance release |
| 2018.06.18 |
|
| 2017.05.08 |
|
| 2016.11.07 | Added a "Mentor Code Sourcery Compiler" section |
| 2016.05.27 | Maintenance release |
| 2016.02.17 | Updated the compiler version for Mentor Graphics* Sourcery™ CodeBench Lite Edition |
| 2015.08.06 | Added Intel® Arria® 10 SoC support |
10. SD Card Boot Utility
The Preloader is typically stored in a custom partition (with type = 0xA2) on the SD card. Optionally, the next boot stage (usually the Bootloader) can also be stored on the same custom partition.
Since it is a custom partition without a file-system, the Preloader, Bootloader, or both cannot be updated by copying the new file to the card; and a software tool is needed.
The SD card boot utility allows you to update the Preloader, Bootloader, or both on a physical SD card or a disk image file. The utility is not intended to create a new bootable SD card or disk image file from scratch. In order to do that, it is recommended to use fdisk on a Linux* host OS.
10.1. Usage Scenarios
This utility is intended to update boot software on that resides on an existing:
- Existing SD card
- Existing disk image file
- Cyclone® V SoC and Arria® V SoC Preloader—The Preloader file needs to have the mkpimage header, as required by the bootROM.
- Cyclone® V SoC and Arria® V SoC Bootloader—The Bootloader file needs to have the mkimage header, as required by the Preloader.
- Intel® Arria® 10 SoC Bootloader—The Bootloader needs to have the mkpimage header, as required by the bootROM.
The tool only updates the custom partition that stores the Intel SoC boot code. The rest of the SD card or disk image file is not touched. This includes the Master Boot Record (MBR) and any other partitions (such as FAT and EXT3) and free space.
Warning: The users of this tool need administrative or root access to their computer to use this tool to write to physical SD cards. These rights are not required when only working with disk image files. Please contact the IT department if you do not have the proper rights on your PC.
10.2. Tool Options
Sample Output from Utility
The utility is a command line program. The table describes all the command line options; and the figure shows the --help output from the tool.
| Command line Argument | Required? | Description |
|---|---|---|
| -p filename | Optional | Specifies Preloader file to write |
| -b filename | Optional | Specifies Cyclone V or Arria® V SoC Bootloader file to write |
| -B filename | Optional | Specifies Intel® Arria® 10 SoC Bootloader file to write |
| -a write | Required | Specifies action to take. Only "write" action is supported. Example: "-a write" |
| disk_file | Required(unless -d option is used) | Specifies disk image file or physical disk to write to. A disk image file is a file that contains all the data for a storage volume including the partition table. This can be written to a physical disk later with another tool. For physical disks in Linux*, just specify the device file. For example: /dev/mmcblk0 For physical disks in Windows, specify the physical drive path such as \\.\physicaldrive2 or use the drive letter option(-d) to specify a drive letter. The drive letter option is the easiest method in Windows |
| -d | Optional | specify disk drive letter to write to. Example: "-d E". When using this option, the disk_file option cannot be specified. |
| -h | Optional | Displays help message and exits |
| --version | Optional | Displays script version number and exits |
$ alt-boot-disk-util --help
Altera Boot Disk Utility
Copyright (C) 1991-2014 Altera Corporation
Usage:
#write preloader to disk
alt-boot-disk-util -p preloader -a write disk_file
#write bootloader to disk
alt-boot-disk-util -b bootloader -a write disk_file
#write BOOTloader and PREloader to disk
alt-boot-disk-util -p preloader -b bootloader -a write disk_file
#write Arria10 Bootloader to disk
alt-boot-disk-util -B a10bootloader -a write disk_file
#write BOOTloader and PREloader to disk drive 'E'
alt-boot-disk-util -p preloader -b bootloader -a write -d E
Options:
--version show program's version number and exit
-h, --help show this help message and exit
-b FILE, --bootloader=FILE
bootloader image file'
-p FILE, --preloader=FILE
preloader image file'
-a ACTION, --action=ACTION
only supports 'write' action'
-B FILE, --a10-bootloader=FILE
arria10 bootloader image file
-d DRIVE, --drive=DRIVE
specify disk drive letter to write to
10.3. SD Card Boot Utility Revision History
| Document Version | Changes |
|---|---|
| 2019.12.20 | Supported with
Intel®
Quartus® Prime Standard Edition version 19.1
and
Intel®
Quartus® Prime Pro Edition version 19.3
|
| 2019.05.16 | Maintenance release |
| 2018.09.24 | Maintenance release |
| 2018.06.18 |
|
| 2017.05.08 |
|
| 2016.11.07 | Maintenance release |
| 2016.05.27 | Maintenance release |
| 2016.02.17 | Maintenance release |
| 2015.08.06 | Added Intel® Arria® 10 SoC support |
11. Linux Software Development Tools
The Linux* software development tools are listed below. The Linux* compiler and the linux device tree generator are described in the following sections of this chapter.
- Linux* compiler
- SD card boot utility
- Linux* device tree generator (DTG)
11.1. Linux Compiler
The Linaro* Linux* compiler is shipped with the SoC EDS. For the current version, refer to Table 1.
For more information about the Linux* compiler and to download the latest version of the tools, refer to the download page at the Linaro* website.
The compiler is a GCC-based arm-linux-gnueabihf port. It targets the Arm* processor, it assumes the target platform is running Linux*, and it uses the GNU embedded-application binary interface (EABI) hard-float (HF) conventions.
<SoC EDS installation directory>/ds-5/bin.
<SoC EDS installation directory>/ds-5/documents/gcc.
- Compiler manual
- Assembler manual
- Linker manual
- Binutils manual
- GDB manual
- Getting Started Guide
11.2. Linux Device Tree Generator
A device tree is a data structure that describes the underlying hardware to an operating system - primarily Linux*. By passing this data structure to the OS kernel, a single OS binary may be able to support many variations of hardware. This flexibility is particularly important when the hardware includes an FPGA.
The Linux* Device Tree Generator (DTG) tool is part of SoC EDS and is used to create Linux* device trees for the Cyclone® V SoC, Arria® V SoC, and Intel® Arria® 10 SoC systems that contain FPGA designs created using Platform Designer (Standard). The generated device tree describes the HPS peripherals, selected FPGA Soft IP, and peripherals that are board dependent. The Intel® Arria® 10 SoC Bootloader also has an associated Device Tree called Bootloader Device Tree that is created and managed by the BSP Editor tool.
Warning: The Linux* Device Tree Generator is obsolete and does not support Intel® Stratix® 10 SoC and newer devices. However, it is tested with and supports only the Linux* kernel version targeted by the associated GSRD. Intel® does not recommend that you use the Linux* Device Tree Generator if your design targets a different Linux* kernel version. Instead, Intel® recommends that you manage the Device Tree manually by using the Device Tree files provided by the kernel as a baseline, and by adding the FPGA IP and board information manually.
Refer to HOWTOCreateADeviceTree, which supports all kernels.
11.3. Linux Software Development Tools Revision History
| Document Version | Changes |
|---|---|
| 2019.12.20 | Supported with
Intel®
Quartus® Prime Standard Edition version 19.1 and
Intel®
Quartus® Prime Pro Edition version 19.3 |
| 2019.05.16 | Maintenance release |
| 2018.09.24 | Maintenance release |
| 2018.06.18 |
|
| 2017.05.08 |
|
| 2016.11.07 | Maintenance release |
| 2016.05.27 | Maintenance release |
| 2016.02.17 | Maintenance release |
| 2015.08.06 | Added Intel® Arria® 10 SoC support |
12. Support and Feedback
12.1. Support and Feedback Revision History
| Document Version | Changes |
|---|---|
| 2019.12.20 | Supported with
Intel®
Quartus® Prime Standard Edition version 19.1
and
Intel®
Quartus® Prime Pro Edition version 19.3
|
| 2019.05.16 | Maintenance release |
| 2018.09.24 | Maintenance release |
| 2018.06.18 | Updated chapter to include support for Intel® Stratix® 10 SoC |
| 2017.05.08 |
|
| 2016.11.07 | Maintenance release |
| 2016.05.27 | Maintenance release |
| 2016.02.17 | Maintenance release |
| 2015.08.06 | Added Intel® Arria® 10 SoC support |