Skip to content

HPS GSRD User Guide for the Agilex™ 5 FPGA E-Series 065B Modular Development Kit (ES)

Introduction

GSRD Overview

The Golden System Reference Design (GSRD) is a reference design running on the Agilex™ 5 E-Series 065B Modular Development Kit(ES).

The GSRD is comprised of the following components:

  • Golden Hardware Reference Design (GHRD)
  • Reference HPS software including:
    • Arm Trusted Firmware
    • U-Boot
    • Linux Kernel
    • Linux Drivers
    • Sample Applications

Important Note: In order to simplify the GSRD build process, Altera introduced GSRD 2.0, which uses Kas as a lightweight build orchestration layer on top of BitBake / Yocto. In this release, the HPS Enablement daughter card is supported, for both booting from SD card and QSPI. In future releases, all HPS daughtercards will be supported by GSRD 2.0.

Prerequisites

The following are required to be able to fully exercise the Agilex 5 E-Series 065B Modular Development Kit(ES) GSRD:

  • Altera® Agilex™ 5 FPGA E-Series 065B Modular Development Kit, ordering code MK-A5E065BB32AES1. Refer to board documentation for more information about the development kit.
    • Power supply
    • 2 x Micro USB Cable
    • Ethernet Cable
    • Micro SD card and USB card writer
  • Host PC with
    • 64 GB of RAM. Less will be fine for only exercising the binaries, and not rebuilding the GSRD.
    • Linux OS installed. Ubuntu 22.04LTS was used to create this page, other versions and distributions may work too
    • Serial terminal (for example GtkTerm or Minicom on Linux and TeraTerm or PuTTY on Windows)
    • Altera® Quartus® Prime Pro Edition Version 26.1
  • Local Ethernet network, with DHCP server
  • Internet connection. For downloading the files, especially when rebuilding the GSRD.

Prebuilt Binaries

The Agilex 5 Modular Development Kit GSRD binaries are located at https://releases.rocketboards.org/2026.04/:

Boot Source Link
SD Card https://releases.rocketboards.org/2026.04/gsrd/agilex5_mk_a5e065bb32aes1_gsrd/
QSPI https://releases.rocketboards.org/2026.04/qspi/agilex5_mk_a5e065bb32aes1_qspi/

Note: The GSRD release for the HPS Enablement Board comes in two versions: one which uses a Cortex-A55 as the boot core, and one which uses a Cortex-A76 as the boot core. The rest of the functionality is the same, and all cores are enabled in Linux by default. The instructions on how to exercise the binaries are the same for both versions. And the instructions for rebuilding the binaries are similar, just using a different version of the GHRD which has the respective option selected.

Component Versions

Altera® Quartus® Prime Pro Edition Version 26.1 and the following software component versions integrate the 26.1 release.

Component Location Branch Commit ID/Tag
Agilex 5 Design https://github.com/altera-fpga/agilex5e-ed-gsrd main QPDS26.1_REL_GSRD_PR
Linux https://github.com/altera-fpga/linux-socfpga socfpga-6.18.2-lts QPDS26.1_REL_GSRD_PR
Arm Trusted Firmware https://github.com/altera-fpga/arm-trusted-firmware socfpga_v2.14.0 QPDS26.1_REL_GSRD_PR
U-Boot https://github.com/altera-fpga/u-boot-socfpga socfpga_v2026.01 QPDS26.1_REL_GSRD_PR
Yocto Project https://git.yoctoproject.org/poky scarthgap latest
Yocto meta-altera-fpga Layer https://github.com/altera-fpga/meta-altera-fpga scarthgap QPDS26.1_REL_GSRD_PR

Note: The combination of the component versions indicated in the table above has been validated through the use cases described in this page and it is strongly recommended to use these versions together. If you decided to use any component with different version than the indicated, there is not warranty that this will work.

Release Notes

See https://github.com/altera-fpga/gsrd-socfpga/releases/tag/QPDS26.1_REL_GSRD_PR

Development Kit

This release targets the Agilex 5 FPGA E-Series 065B Modular Development Kit. It is composed of a carrier board which offers additional connectivity, and a SOM board which contains the FPGA part, HPS DDRAM and all other required circuitry. Refer to board documentation for more information about the development kit.

Changing MSEL

MSEL signals instruct the FPGA device on which configuration scheme to use. Configuration schemes used by the scenarios presented in this guide are JTAG and ASx4 (QSPI). MSEL is changed through dipswitch S4 on the top left cornet of the SOM board. Only change the settings while the board is powered off.

The MSEL settings are:

  • JTAG: SW4[2:1]=OFF:OFF
  • ASx4 (QSPI): SW4[2:1]=ON:ON

GHRD Overview

The Golden Hardware Reference Design is an important part of the GSRD and consists of the following components:

  • Hard Processor System (HPS)
    • Dual core Arm Cortex-A76 processor
    • Dual core Arm Cortex-A55 processor
    • HPS Peripherals
      • Micro SD Card
      • EMAC
      • HPS JTAG debug
      • UART
      • I2C
      • USB 3.1
  • Multi-Ported Front End (MPFE) for HPS External Memory Interface (EMIF)
  • FPGA Peripherals connected to Lightweight HPS-to-FPGA (LWH2F) AXI Bridge and JTAG to Avalon Master Bridge
    • One user LED output
    • Two user DIP switch inputs
    • One user push-button input
    • System ID
  • FPGA Peripherals connected to HPS-to-FPGA (H2F) AXI Bridge
    • 256KB of FPGA on-chip memory

The GHRD allows hardware designers to access each peripheral in the FPGA portion of the SoC with System Console, through the JTAG master module. This signal-level access is independent of the driver readiness of each peripheral.

MPU Address Maps

This section presents the address maps as seen from the MPU side.

HPS-to-FPGA Address Map

The three FPGA windows in the MPU address map provide access to 256 GB of FPGA space. First window is 1 GB from 00_4000_0000, second window is 15 GB from 04_4000_0000, third window is 240 GB from 44_0000_0000. The following table lists the offset of each peripheral from the HPS-to-FPGA bridge in the FPGA portion of the SoC.

Peripheral Address Offset Size (bytes) Attribute
onchip_memory2_0 0x0 256K On-chip RAM as scratch pad
Lightweight HPS-to-FPGA Address Map

The the memory map of system peripherals in the FPGA portion of the SoC as viewed by the MPU, which starts at the lightweight HPS-to-FPGA base address of 0x00_2000_0000, is listed in the following table.

Peripheral Address Offset Size (bytes) Attribute
sysid 0x0001_0000 32 Unique system ID
button_pio 0x0001_0060 16 Push button inputs
dipsw_pio 0x0001_0070 16 DIP switch inputs
led_pio 0x0001_0080 16 LED outputs
JTAG Master Address Map

There are three JTAG master interfaces in the design, one for accessing non-secure peripherals in the FPGA fabric, and another for accessing secure peripheral in the HPS through the FPGA-to-HPS Interface and another for FPGA fabric to SDRAM.

The following table lists the address of each peripheral in the FPGA portion of the SoC, as seen through the non-secure JTAG master interface.

Peripheral Address Offset Size (bytes) Attribute
onchip_memory2_0 0x0004_0000 256K On-chip RAM
sysid 0x0001_0000 32 Unique system ID
button_pio 0x0001_0060 16 Push button inputs
dipsw_pio 0x0001_0070 16 DIP switch inputs
led_pio 0x0001_0080 16 LED outputs

Interrupt Routing

The HPS exposes 64 interrupt inputs for the FPGA logic. The following table lists the interrupt connections from soft IP peripherals to the HPS interrupt input interface.

Peripheral Interrupt Number Attribute
dipsw_pio f2h_irq0[1] DIP switch input
button_pio f2h_irq0[0] Push button input

Exercising Prebuilt Binaries

This section presents how to use the prebuilt binaries included with the GSRD release.

Configure Board

1. Leave all jumpers and switches in their default configuration.

2. Connect micro USB cable from bottom left of the carrier board to PC. This will be used for JTAG communication.

3. Connect micro USB cable from bottom right of the SOM board to PC. This will be used for HPS UART communication.

4. Connect Ethernet cable from SOM board to an Ethernet switch connected to local network. Local network must provide a DCHP server.

Configure Serial Console

All the scenarios included in this release require a serial connection. This section presents how to configure the serial connection.

Each of the USB connections listed above will enumerate 4 USB serial ports on your host computer. The HPS UART port is the 3rd one enumerated by the connection to the SOM board.

1. Install a serial terminal emulator application on your host PC:

  • For Windows: TeraTerm or PuTTY are available
  • For Linux: GtkTerm or Minicom are available

2. Remove USB cables, and power down your board if powered up. Look at what USB serial ports are enumerated on your computer by default, without board being connected.

3. Power up the board.

4. Connect micro USB cable from bottom left of the carrier board to PC. This will be used for JTAG communication. Look at what ports are enumerated on your host computer, there should be a series of four.

5. Connect micro USB cable from bottom right of the SOM board to PC. This will be used for HPS UART communication. Look at what ports are enumerated on your host computer, there should be a series of four. Use the 3rd one in the list as the HPS serial port.

Possible serial port allocation in Windows

  • COM3: already there before board was installed
  • COM4-7: enumerated by the JTAG connection
  • COM8-11: enumerated by the HPS connection

In the above case, the port to use for HPS serial communication would be COM10.

Possible serial port allocation in Linux

  • /dev/ttyUSB0-3: enumerated by the JTAG connection
  • /dev/ttyUSB4-7:enumerated by the HPS connection

In the above case, the port to use for HPS serial communication would be /dev/ttyUSB6.

Notes:

  • On Windows, the port number may be kept between power cycles, but not always.
  • On Linux, the port numbe may change depending on the order in which cables are inserted.

6. Configure your serial terminal emulator to use the following settings:

  • Serial port: as mentioned above
  • Baud rate: 115,200
  • Data bits: 8
  • Stop bits: 1
  • CRC: disabled
  • Hardware flow control: disabled

7. Connect your terminal emulator

Booting from SD Card

Write SD Card

1. Download SD card image from the prebuilt binaries https://releases.rocketboards.org/2026.04/gsrd/agilex5_mk_a5e065bb32aes1_gsrd/sdimage.tar.gz and extract the archive, obtaining the file gsrd-console-image-agilex5_devkit.wic.

2. Write the gsrd-console-image-agilex5_devkit.wic. SD card image to the micro SD card using the included USB writer in the host computer:

  • On Linux, use the dd utility as shown next: 
    # Determine the device asociated with the SD card on the host computer. 
cat /proc/partitions
# This will return for example /dev/sdx
# Use dd to write the image in the corresponding device
sudo dd if=gsrd-console-image-agilex5_devkit.wic of=/dev/sdx bs=1M
# Flush the changes to the SD card
sync
  • On Windows, use the Win32DiskImager program, available at https://sourceforge.net/projects/win32diskimager. For this, first rename the gsrd-console-image-agilex5_devkit.wic to an .img file (sdcard.img for example) and write the image as shown in the next figure:

Write QSPI Flash

1. Power down board

2. Set MSEL dipswitch S4 on SOM to JTAG: OFF-OFF

3. Power up the board

4. Download and extract the JIC image, then write it to QSPI 

wget https://releases.rocketboards.org/2026.04/gsrd/agilex5_mk_a5e065bb32aes1_gsrd/ghrd_a5ed065bb32ae6sr0.hps.jic.tar.gz
tar xf ghrd_a5ed065bb32ae6sr0.hps.jic.tar.gz
jtagconfig --setparam 1 JtagClock 16M
quartus_pgm -c 1 -m jtag -o "pvi;ghrd_a5ed065bb32ae6sr0.hps.jic"

Boot Linux

1. Power down board

2. Set MSEL dipswitch S4 on SOM to ASX4 (QSpI): ON-ON

3. Power up the board

4. Wait for Linux to boot, use root as user name, and no password wil be requested.

Run Sample Applications

1. Boot to Linux

2. Change current folder to alteraFPGA folder 

cd alteraFPGA
3. Run the hello world application 
./hello
4. Run the syscheck application 
./syscheck
Press q to exit the syscheck application.

Control LED

1. Boot to Linux

2. Control LED by using the following sysfs entries:

  • /sys/class/leds/fpga_led0/brightness
  • /sys/class/leds/hps_led1/brightness

using commands such as: 

cat /sys/class/leds/fpga_led0/brightness
echo 0 > /sys/class/leds/fpga_led0/brightness
echo 1 > /sys/class/leds/fpga_led1/brightness

Because of how the LEDs are connected, for the above commands 0 means LED is turned on, 1 means LED is turned off.

Connect to Board Using SSH

1. Boot to Linux

2. Determine the board IP address using the ifconfig command: 

root@agilex5devkit:~# ifconfig
eth0: flags=-28605<UP,BROADCAST,RUNNING,MULTICAST,DYNAMIC>  mtu 1500
        inet 192.168.1.153  netmask 255.255.255.0  broadcast 192.168.1.255
        inet6 fe80::f0eb:c8ff:fec4:eed7  prefixlen 64  scopeid 0x20<link>
        ether f2:eb:c8:c4:ee:d7  txqueuelen 1000  (Ethernet)
        RX packets 649  bytes 45132 (44.0 KiB)
        RX errors 0  dropped 226  overruns 0  frame 0
        TX packets 56  bytes 8789 (8.5 KiB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0
        device interrupt 23  

lo: flags=73<UP,LOOPBACK,RUNNING>  mtu 65536
        inet 127.0.0.1  netmask 255.0.0.0
        inet6 ::1  prefixlen 128  scopeid 0x10<host>
        loop  txqueuelen 1000  (Local Loopback)
        RX packets 100  bytes 8408 (8.2 KiB)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 100  bytes 8408 (8.2 KiB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0
3. Connect to the board over SSH using root username, no password will be requested: 
ssh root@192.168.1.153
Note: Make sure to replace the above IP address to the one matching the output of running ifconfig on youir board.

Visit Board Web Page

1. Boot to Linux

2. Determine board IP address using ifconfig like in the previous scenario

3. Start a web browser and enter the IP address in the address bar

4. The web browser will display a page served by the web server running on the board.

Note: Current release has a limitation, in that the LEDs are not controllable from the web page. This will be resolved in the next release.

Booting from QSPI

This section presents how to boot from QSPI. One notable aspect is that you need to wipe the SD card partitioning information, as otherwise U-Boot SPL could find a valid SD card image, and try to boot from that first.

Wipe SD Card

Either write 1MB of zeroes at the beginning of the SD card, or remove the SD card from the dev kit. You can use dd on Linux, or Win32DiskImager on Windows to achieve this.

Write QSPI Flash

1. Power down board

2. Set MSEL dipswitch S4 on SOM to JTAG: OFF-OFF

3. Power up the board

4. Download and extract the JIC image, then write it to QSPI: 

wget https://releases.rocketboards.org/2026.04/qspi/agilex5_mk_a5e065bb32aes1_qspi/agilex_flash_image.hps.jic.tar.gz
tar xf agilex_flash_image.hps.jic.tar.gz
jtagconfig --setparam 1 JtagClock 16M
quartus_pgm -c 1 -m jtag -o "pvi;agilex_flash_image.hps.jic"

Boot Linux

1. Power down board

2. Set MSEL dipswitch S4 on SOM to ASX4 (QSpI): ON-ON

3. Power up the board

4. Wait for Linux to boot, use root as user name, and no password wil be requested.

Note: On first boot, the UBIFS rootfilesystem is initialized, and that takes a few minutes. This will not happen on next reboots. See a sample log below:

[   17.033558] UBIFS (ubi0:4): Mounting in unauthenticated mode
[   17.039470] UBIFS (ubi0:4): background thread "ubifs_bgt0_4" started, PID 130
[   17.061510] UBIFS (ubi0:4): start fixing up free space
[   20.644496] random: crng init done
[   27.120040] platform soc:leds: deferred probe pending
[  243.190874] UBIFS (ubi0:4): free space fixup complete
[  243.315909] UBIFS (ubi0:4): UBIFS: mounted UBI device 0, volume 4, name "rootfs"
[  243.323290] UBIFS (ubi0:4): LEB size: 65408 bytes (63 KiB), min./max. I/O unit sizes: 8 bytes/256 bytes
[  243.332653] UBIFS (ubi0:4): FS size: 167117440 bytes (159 MiB, 2555 LEBs), max 6500 LEBs, journal size

Build GSRD 2.0 Binaries

Kas is a Python-based lightweight build orchestration layer on top of BitBake/Yocto. Kas allows you to define your build environment in a YAML manifest, so you can perform checkout, environment setup, configuration, and build invocation with a single command.

In order to simplify the GSRD build process, Altera introduces GSRD 2.0, which uses Kas. In this release, the HPS Enablement daughter card is supported, for both booting from SD card and QSPI. In the future, more boards and daughter cards will be supported.

Kas replaces the gsrd-socfpga repository, providing a more maintainable build description. It offers improved reproducibility, reduced setup friction, and a clearer abstraction for managing multiple layers, revisions, and configuration fragments. Once all GSRD variations move to Kas, the gsrd-soc-fpga repository and GSRD build script will be retired.

The GSRD 2.0 software source code is released inside the software/yocto_linux directory of the Agilex 5 E-Series Golden Hardware Reference Design (GHRD). Accessing the link will display a README page with details on how the GSRD 2.0 is organized around the Kas tool.

For more details about Kas, refer to the official documentation at https://kas.readthedocs.io/en/latest/.

Kas Build Prerequisites

The same prerequisites as for regular Yocto build are required.

1. Make sure you have Yocto system requirements met: https://docs.yoctoproject.org/scarthgap/ref-manual/system-requirements.html#supported-linux-distributions.

The command to install the required packages on Ubuntu 22.04 is:

sudo apt-get update
sudo apt-get upgrade
sudo apt-get install openssh-server mc libgmp3-dev libmpc-dev gawk wget git diffstat unzip texinfo gcc \
build-essential chrpath socat cpio python3 python3-pip python3-pexpect xz-utils debianutils iputils-ping \
python3-git python3-jinja2 libegl1-mesa libsdl1.2-dev pylint xterm python3-subunit mesa-common-dev zstd \
liblz4-tool git fakeroot build-essential ncurses-dev xz-utils libssl-dev bc flex libelf-dev bison xinetd \
tftpd tftp nfs-kernel-server libncurses5 libc6-i386 libstdc++6:i386 libgcc++1:i386 lib32z1 \
device-tree-compiler curl mtd-utils u-boot-tools net-tools swig -y

On Ubuntu 22.04 you will also need to point the /bin/sh to /bin/bash, as the default is a link to /bin/dash:

 sudo ln -sf /bin/bash /bin/sh

Note: You can also use a Docker container to build the Yocto recipes, refer to https://rocketboards.org/foswiki/Documentation/DockerYoctoBuild for details. When using a Docker container, it does not matter what Linux distribution or packages you have installed on your host, as all dependencies are provided by the Docker container.

In addition to the above, you must also install python3-newt, and python3.10-venv with a command like this:

sudo apt-get install python3-newt python3.10-venv

Build SD Card Binaries

Setup Environment

1. Create the top folder to store all the build artifacts:

sudo rm -rf agilex5_gsrd_20.mdk_sd
mkdir agilex5_gsrd_20.mdk_sd
cd agilex5_gsrd_20.mdk_sd
export TOP_FOLDER=`pwd`

Enable Quartus tools to be called from command line:

source ~/altera_pro/26.1/qinit.sh
Build Hardware Design
cd $TOP_FOLDER
rm -rf agilex5_soc_devkit_ghrd && mkdir agilex5_soc_devkit_ghrd && cd agilex5_soc_devkit_ghrd
wget https://github.com/altera-fpga/agilex5e-ed-gsrd/releases/download/QPDS26.1_REL_GSRD_PR/a5ed065es-modular-devkit-som-baseline-a55.zip
unzip a5ed065es-modular-devkit-som-baseline-a55.zip
rm -f a5ed065es-modular-devkit-som-baseline-a55.zip
make baseline_a55-build
make baseline_a55-install-core-rbf
cd ..

The following files are created:

  • $TOP_FOLDER/agilex5_soc_devkit_ghrd/output_files/baseline_a55.sof
  • $TOP_FOLDER/agilex5_soc_devkit_ghrd/install/binaries/ghrd.core.rbf

Important Note: Please refer to Migrate Hardware Design from GSRD 1.0 to GSRD 2.0 section for important information about how to migrate from a hardware design based on GSRD 1.0 to GSRD 2.0.

Build Yocto Using Kas

1. Create and enter a new Python virtual environment:

cd $TOP_FOLDER/agilex5_soc_devkit_ghrd/software/yocto_linux
python3 -m venv venv --system-site-packages
source venv/bin/activate
pip install --upgrade pip
pip install kas
pip install --upgrade kas
pip install kconfiglib

2. Copy the core.rbf file to where Kas expects it to be:

cp $TOP_FOLDER/agilex5_soc_devkit_ghrd/install/binaries/ghrd.core.rbf \
   $TOP_FOLDER/agilex5_soc_devkit_ghrd/software/yocto_linux/meta-custom/recipes-fpga/fpga-bitstream/files/baseline_a55_hps_debug.core.rbf

3. Build Yocto with Kas:

kas build kas.yml gsrd-console-image

The following relevant files are created in $TOP_FOLDER/agilex5_soc_devkit_ghrd/software/yocto_linux/build/tmp/deploy/images/agilex5e/:

  • gsrd-console-image-agilex5e.rootfs.wic
  • u-boot-spl-dtb.hex

Note: If you experience build failures related to file-locks, you can work around these by reducing the parallelism of your build by running the following commands before running kas:

export PARALLEL_MAKE="-j 8"
export BB_NUMBER_THREADS="8"
export BB_ENV_PASSTHROUGH_ADDITIONS="$BB_ENV_PASSTHROUGH_ADDITIONS PARALLEL_MAKE BB_NUMBER_THREADS"
Build QSPI Image
cd $TOP_FOLDER
rm -f baseline_a55.hps.jic baseline_a55.core.rbf
quartus_pfg \
-c agilex5_soc_devkit_ghrd/output_files/baseline_a55.sof baseline_a55.jic \
-o device=MT25QU128 \
-o flash_loader=A5ED065BB32AE6SR0 \
-o hps_path=agilex5_soc_devkit_ghrd/software/yocto_linux/build/tmp/deploy/images/agilex5e/u-boot-spl-dtb.hex \
-o mode=ASX4 \
-o hps=1

The following file is created:

  • $TOP_FOLDER/baseline.hps.jic

Build QSPI Binaries

Setup Environment

1. Create the top folder to store all the build artifacts:

sudo rm -rf agilex5_gsrd_20.mdk_qspi
mkdir agilex5_gsrd_20.mdk_qspi
cd agilex5_gsrd_20.mdk_qspi
export TOP_FOLDER=`pwd`

Enable Quartus tools to be called from command line:

source ~/altera_pro/26.1/qinit.sh
Build Hardware Design
cd $TOP_FOLDER
rm -rf agilex5_soc_devkit_ghrd && mkdir agilex5_soc_devkit_ghrd && cd agilex5_soc_devkit_ghrd
wget https://github.com/altera-fpga/agilex5e-ed-gsrd/releases/download/QPDS26.1_REL_GSRD_PR/a5ed065es-modular-devkit-som-baseline-a55.zip
unzip a5ed065es-modular-devkit-som-baseline-a55.zip
rm -f a5ed065es-modular-devkit-som-baseline-a55.zip
make baseline_a55-build
make baseline_a55-install-core-rbf
cd ..

The following files are created:

  • $TOP_FOLDER/agilex5_soc_devkit_ghrd/output_files/baseline_a55.sof
  • $TOP_FOLDER/agilex5_soc_devkit_ghrd/install/binaries/ghrd.core.rbf

Important Note: Please refer to Migrate Hardware Design from GSRD 1.0 to GSRD 2.0 section for important information about how to migrate from a hardware design based on GSRD 1.0 to GSRD 2.0.

Build Yocto Using Kas

1. Create and enter a new Python virtual environment. A virtual environment allows you to install packages without impacting your global environment:

cd $TOP_FOLDER/agilex5_soc_devkit_ghrd/software/yocto_linux
python3 -m venv venv --system-site-packages
source venv/bin/activate
pip install --upgrade pip
pip install kas
pip install --upgrade kas
pip install kconfiglib

2. Copy the core.rbf file to where Kas expects it to be:

cp $TOP_FOLDER/agilex5_soc_devkit_ghrd/install/binaries/ghrd.core.rbf \
   $TOP_FOLDER/agilex5_soc_devkit_ghrd/software/yocto_linux/meta-custom/recipes-fpga/fpga-bitstream/files/baseline_a55_hps_debug.core.rbf

3. Build Yocto with Kas:

kas build kas.yml:qspi_boot_src.yml console-image-minimal

Note: If you wish to customize your Linux image, you can use the kas menu command instead. The options here are explained in section Customizing Yocto Kas Build below.

The following relevant files are created in $TOP_FOLDER/agilex5_soc_devkit_ghrd/software/yocto_linux/build/tmp/deploy/images/agilex5e/:

  • u-boot-spl-dtb.hex
  • u-boot.itb
  • core-image-minimal-agilex5e.rootfs_nor.ubifs
  • kernel.itb
  • boot.scr.uimg
Build QSPI Image

1. Create the folder to contain all the files:

cd $TOP_FOLDER
sudo rm -rf qspi_boot
mkdir qspi_boot
cd qspi_boot

2. Get the ubinize_nor.cfg file which contains the details on how to build the root.ubi volume, and agilex5_devkit_flash_image_hps.pfg which contains the instructions for Programming File Generator on how to create the .jic filem and the uboot.env containing the U-Boot environment:

wget https://releases.rocketboards.org/2026.04/qspi/agilex5_mk_a5e065bb32aes1_qspi.baseline-a55/ubinize_nor.cfg
wget https://releases.rocketboards.org/2026.04/qspi/agilex5_mk_a5e065bb32aes1_qspi.baseline-a55/qspi_boot.pfg
wget https://releases.rocketboards.org/2026.04/qspi/agilex5_mk_a5e065bb32aes1_qspi.baseline-a55/uboot.env

3. Link to the files that are needed from building the hardware design, and yocto:

ln -s $TOP_FOLDER/agilex5_soc_devkit_ghrd/output_files/baseline_a55.sof ghrd.sof
ln -s $TOP_FOLDER/agilex5_soc_devkit_ghrd/software/yocto_linux/build/tmp/deploy/images/agilex5e/u-boot-spl-dtb.hex .
ln -s $TOP_FOLDER/agilex5_soc_devkit_ghrd/software/yocto_linux/build/tmp/deploy/images/agilex5e/u-boot.itb u-boot.bin
ln -s $TOP_FOLDER/agilex5_soc_devkit_ghrd/software/yocto_linux/build/tmp/deploy/images/agilex5e/console-image-minimal-agilex5e.rootfs_nor.ubifs .
ln -s $TOP_FOLDER/agilex5_soc_devkit_ghrd/software/yocto_linux/build/tmp/deploy/images/agilex5e/kernel.itb .
ln -s $TOP_FOLDER/agilex5_soc_devkit_ghrd/software/yocto_linux/build/tmp/deploy/images/agilex5e/boot.scr.uimg .

4. Create the root.ubi file and rename it to hps.bin as Programming File Generator needs the .bin extension:

ubinize -o root.ubi -p 65536 -m 1 -s 1 ubinize_nor.cfg
ln -s root.ubi hps.bin

5. Create the JIC file:

quartus_pfg -c qspi_boot.pfg

The following file will be created:

  • $TOP_FOLDER/qspi_boot/qspi_boot.hps.jic

Additional Guides

Customize Kas Build

The kas.yml file is the central configuration file used by Kas to define all components required for a reproducible Yocto build environment. It specifies the repositories, branches, layers, and build targets, as well as optional environment variables and machine settings. By consolidating this information into a single YAML file, kas.yml eliminates manual setup steps and ensures that builds can be easily replicated across systems or shared with collaborators. This makes it an essential part of version-controlled, automated build workflows.

Kas also offers Kconfig-based customizations to provide a flexible and user-friendly configuration experience. This enables you to select repositories, layers, and build targets through a structured menu interface instead of editing YAML files directly. This approach combines the clarity and reproducibility of Kas with the modular configurability of the Linux kernel’s Kconfig system, making it easier to tailor builds for different platforms or use cases while maintaining a consistent and automated setup.

Review the kas.yml file, the Kconfig options and associated documentation at https://github.com/altera-fpga/agilex5e-ed-gsrd/tree/QPDS26.1_REL_GSRD_PR/a5ed065es-modular-devkit-som/baseline-a55/software/yocto_linux.

In the build instructions presented in Rebuilding GSRD 2.0 Binaries, we did not use the Kconfig options, only the default options from kas.yml were used. This section shows how you can use kas menu to customize the build.

When using kas menu, the initial settings from kas.yml are customized with the user selected options through Kconfig, and are saved to a file called .config.yaml which is then used for build purposes.

1. Build the hardware design as mentioned before. Note the same hardware design is used for both booting from SD card and booting from QSPI.

2. Copy the core.rbf file to where Kas needs it to be. Note that the filename when using Kconfig is different than when using the kas.yml alone (top.core.rbf vs ghrd.core.rbf)

cp $TOP_FOLDER/agilex5_soc_devkit_ghrd/install/binaries/ghrd.core.rbf \
   $TOP_FOLDER/agilex5_soc_devkit_ghrd/software/yocto_linux/meta-custom/recipes-fpga/fpga-bitstream/files/top.core.rbf

3. Create an enter a new Python virtual environment, not to interfere with the current system Python packages:

cd $TOP_FOLDER/agilex5_soc_devkit_ghrd/software/yocto_linux
python3 -m venv venv --system-site-packages
source venv/bin/activate
pip install --upgrade pip
pip install kas
pip install --upgrade kas
pip install kconfiglib

4. Run kas menu:

kas menu

5. You will be presented with a Kconfig text menu, similar to the ones from Linux Kernel & U-Boot:

6. Go to FPGA Options screen and make any changes you desire:

7. Go to Image Target Selection screen and select which images to be built:

8. Go to Networking Libraries and Apllications screen and select desired options:

9. Go to Altera Linux Applications screen and select the desired applications:

10. Go to Example Applications screen and select what you need:

11. Once you have selected all the options you want, you can clik the Build button to start the build process:

See below the locations where different components selected above are located in the generated filesystem:

Build Kas Interactively

In addition to using kas build to build Yocto based on the kas.yml and kas menu to build Yocto based on Kconfig options selected from the text GUI, there is also the kas shell option, which allows you to build Yocto interactively.

1. Build the hardware design as mentioned before. Note the same hardware design is used for both booting from SD card and booting from QSPI.

2. Copy the core.rbf file to where bitbake needs it to be. 

cp $TOP_FOLDER/agilex5_soc_devkit_ghrd/install/binaries/ghrd.core.rbf \
   $TOP_FOLDER/agilex5_soc_devkit_ghrd/software/yocto_linux/meta-custom/recipes-fpga/fpga-bitstream/files/

3. Create an enter a new Python virtual environment, not to interfere with the current system Python packages:

cd $TOP_FOLDER/agilex5_soc_devkit_ghrd/software/yocto_linux
python3 -m venv venv --system-site-packages
source venv/bin/activate
pip install --upgrade pip
pip install kas
pip install --upgrade kas
pip install kconfiglib

4. You can optionally use kas menu to change settings, and at the end press the Save button instead of the Build button. This will save the custom configuration in the file .config.yaml.

5. Run kas shell, there are several options:

Command Description
kas shell Use the configuration from the .config.yaml resulted from using kas menu
kas shell kas.yml Use the default configuration for SD card boot
kas shell kas.yml:qspi_boot_src.yml Use the default configuration for QSPI boot

6. Use regular bitbake commands. For example to simply build the rootfs, use:

bitbake core-image-minimal
bitbake console-image-minimal
bitbake gsrd-console-image

Migrate Hardware Design from GSRD 1.0 to GSRD 2.0

If your hardware design was originally based on the HPS Legacy System Example Design 1.0, and you want to migrate it to be used with HPS Baseline System Example Design 2.0, you must ensure that the JTAG user code parameter gets defined with a value of 0 or not defined (FFFFFFFF). This parameter can be found in Quartus Pro from the Assignments >> Device >> Device and Pin Options >> General menu. Alternatively, this parameter can also be defined in the .qsf file  in your Quartus project directory as STRATIX_JTAG_USER_CODE, so you can set this parameter to 0 or just delete the assignment line. This change is needed because in the HPS Legacy System Example Design 1.0, this parameter is used to indicate to U-Boot which configuration components (kernel image, device tree and 2nd phase fabric design) need to be loaded from the kernel.itb binary. The most relevant configurations supported in HPS Legacy System Example Design 1.0 were for booting from OOO daughter card, booting from eMMC/NAND daughter card and exercise Partial Reconfiguration. In each one of these configurations a specific value in the JTAG user code/STRATIX_JTAG_USER_CODE was used. In the case of HPS Baseline System Example Design 2.0, the valid value for this parameter are:

  • 0: Load kernel image, device tree and 2nd phase fabric design from kernel.itb. FPGA is configured.
  • 1: Load kernel image and device tree from kernel.itb. FPGA is not configured. Used for debug purposes.
  • FFFFFFFF or undefined: U-Boot assumes that the parameter is 0 and performs the actions described above.

For any other value, U-Boot will fail to load a valid set of Linux components and 2nd phase fabric design.

Update kernel.itb File

The kernel.itb file is a Flattattened Image Tree (FIT) file that includes the following components:

  • Linux kernel.
  • Board configurations* that indicate what components from the kernel.itb (Linux kernel, device tree and Phase 2 FPGA configuration bitstream) should be used for a specific board.
  • Linux device tree*.
  • Phase 2 FPGA configuration bitstream*.

* One or more of these components to support the different board configurations.

The kernel.itb is created from a .its (Image Tree Source file) that describes its structure. In the HPS Baseline System Example Design, the kernel.itb file is generated in the following directory. In this directory you can also find the .its files and all other the components needed to create the kernel.itb :

  • $TOP_FOLDER/<gsrd-directory>/<project-directory>/software/yocto_linux/build/tmp/work/<device>-poky-linux/linux-socfpga-lts/<linux-branch>+git/linux-<device>-standard-build/

As an example of this path, for the Agilex 5 device you will find this directory as $TOP_FOLDER/a5ed065es-premium-devkit-oobe/baseline-a55/software/yocto_linux/build/tmp/work/agilex5e-poky-linux/linux-socfpga-lts/6.12.43-lts+git/linux-agilex5e-standard-build

If you want to modify the kernel.itb by replacing one of the component or modifying any board configuration, you can do the following:

  1. Install mtools package in your Linux machine. 

    $ sudo apt update
$ sudo apt install mtools

  2. Go to the folder in which the kernel.itb is being created under the HPS Baseline System Example Design. 

    $ cd $TOP_FOLDER/<gsrd-directory>/<project-directory>/software/yocto_linux/build/tmp/work/<device>-poky-linux/linux-socfpga-lts/<linux-branch>+git/linux-<device>-standard-build/
$ ls *.its
fit_<device>_kernel_.its

  3. In the .its file, observe the components that integrates the kernel.itb identifying the nodes as indicated next:

    images node:
    - kernel node - Linux kernel defined with the data parameter in the node.
    - fdt-X node - Device tree X defined with the data parameter in the node.
    - fpga-X node - Phase 2 FPGA configuration bitstream .rbf defined with the data parameter in the node.

    configurations node:
    - board-X node - Board configuration with the name defined with the description parameter. The components for a specific board configuration are defined with the kernel, fdt and fpga parameters.

  4. In this directory, you can replace any of the file components that integrate the kernel.itb, or you can also modify the .its to change the structure and components of the kernel.itb.

  5. Finally, you need to re-generate the new kernel.itb running the following command in the same linux--standard-build/ directory. 

    $ rm kernel.itb
$ mkimage -f fit_<device>_kernel.its kernel.itb

Once that you have completed this procedure, you can use the new kernel.itb as needed. Some options could be:

  • Use U-Boot to load this into the SDRAM board through TFTP to boot Linux or to write it to a flash device
  • Directly update the flash image in your board (QSPI, SD Card, eMMC or NAND) from your working machine.

Update SD Card Image

As part of the Yocto HPS Baseline System Example Designbuild flow, the SD Card image is built for the SD Card boot flow. This image includes a couple of partitions. One of these partition (a FAT32) includes the U-Boot proper, the Distroboot boot script, U-Boot environment and the Linux .itb - which includes the Linux kernel image, the Linux device tree, the phase 2 FPGA configuration bitstream and board configuration (there may be several versions of these last 3 components). The 2nd partition (an EXT3 or EXT4 ) includes the Linux file system.

If you want to replace any the components or add a new item in any of these partitions, without having to run again the Yocto build flow.

This can be done through the wic script available on the Poky repository that is included as part of the HPS Baseline System Example Design build directory:

  • $TOP_FOLDER/<gsrd-directory>/<project-directory>/software/yocto_linux/poky/scripts/wic

The wic command requires to be run in the Yocto build environment that can be setup as shown next in a Linux terminal:

cd $TOP_FOLDER/<gsrd-directory>/<project-directory>/software/yocto_linux/
source poky/oe-init-build-env build
You can verify that the Yocto environment has been setup using the which bitbake command, which will respond with the path of the bitbake command located at poky/bitbake/bin/bitbake.

The wic command allows you to inspect the content of a SD Card image, delete, add or replace any component inside of the image. This command is also provided with help support:

$ $TOP_FOLDER/<gsrd-directory>/<project-directory>/software/yocto_linux/poky/scripts/wic help

Creates a customized OpenEmbedded image.

Usage:  wic [--version]
        wic help [COMMAND or TOPIC]
        wic COMMAND [ARGS]

    usage 1: Returns the current version of Wic
    usage 2: Returns detailed help for a COMMAND or TOPIC
    usage 3: Executes COMMAND

COMMAND:

 list   -   List available canned images and source plugins
 ls     -   List contents of partitioned image or partition
 rm     -   Remove files or directories from the vfat or ext* partitions
 help   -   Show help for a wic COMMAND or TOPIC
 write  -   Write an image to a device
 cp     -   Copy files and directories to the vfat or ext* partitions
 create -   Create a new OpenEmbedded image
 :
 :

The following steps show you how to replace the kernel.itb file inside of the fat32 partition in a .wic image.

  1. The wic ls command allows you to inspect or navigate over the directory structure inside of the SD Card image. For example you can observe the partitions in the SD Card image in this way.

    # Here you can inspect the content a wic image see the 2 partitions inside of the SD Card image
$ $TOP_FOLDER/<gsrd-directory>/<project-directory>/software/yocto_linux/poky/scripts/wic ls my_image.wic
 Num     Start        End          Size      Fstype
 1       1048576    525336575    524288000  fat32
 2     525336576   2098200575   1572864000  ext4


# Here you can naviagate inside of the partition 1
 $ $TOP_FOLDER/<gsrd-directory>/<project-directory>/software/yocto_linux/poky/scripts/wic ls my_image.wic:1
Volume in drive : is boot       
Volume Serial Number is 8F65-ACE9
Directory for ::/

BOOTSC~1 UIM      2739 2011-04-05  23:00  boot.scr.uimg
kernel   itb  12885831 2011-04-05  23:00 
uboot    env      8192 2011-04-05  23:00 
u-boot   itb    938816 2011-04-05  23:00 
      4 files          13 835 578 bytes
                      509 370 368 bytes free

  2. The wic rm command allows you to delete any of the components in the selected partition. For example, you can delete the kernel.itb image from the partition 1(fat32 partition).

    $ $TOP_FOLDER/<gsrd-directory>/<project-directory>/software/yocto_linux/poky/scripts/wic rm my_image.wic:1/kernel.itb

  3. The wic cp command allows you to copy any new item or file from your Linux machine to a specific partition and location inside of the SD Card image. For example, you can copy a new kernel.itb to the partition 1.

    $ $TOP_FOLDER/<gsrd-directory>/<project-directory>/software/yocto_linux/poky/scripts/wic cp <path_new_kernel.itb> my_image.wic:1/kernel.itb

NOTE: The wic application also allows you to modify any image with compatible vfat and ext* type partitions which also covers images used for eMMC boot flow.

Notices & Disclaimers

Altera® Corporation technologies may require enabled hardware, software or service activation. No product or component can be absolutely secure. Performance varies by use, configuration and other factors. Your costs and results may vary. You may not use or facilitate the use of this document in connection with any infringement or other legal analysis concerning Altera or Intel products described herein. You agree to grant Altera Corporation a non-exclusive, royalty-free license to any patent claim thereafter drafted which includes subject matter disclosed herein. No license (express or implied, by estoppel or otherwise) to any intellectual property rights is granted by this document, with the sole exception that you may publish an unmodified copy. You may create software implementations based on this document and in compliance with the foregoing that are intended to execute on the Altera or Intel product(s) referenced in this document. No rights are granted to create modifications or derivatives of this document. The products described may contain design defects or errors known as errata which may cause the product to deviate from published specifications. Current characterized errata are available on request. Altera disclaims all express and implied warranties, including without limitation, the implied warranties of merchantability, fitness for a particular purpose, and non-infringement, as well as any warranty arising from course of performance, course of dealing, or usage in trade. You are responsible for safety of the overall system, including compliance with applicable safety-related requirements or standards. © Altera Corporation. Altera, the Altera logo, and other Altera marks are trademarks of Altera Corporation. Other names and brands may be claimed as the property of others.

OpenCL* and the OpenCL* logo are trademarks of Apple Inc. used by permission of the Khronos Group™.

Last update: April 30, 2026
Created: August 7, 2024
Ask in the Forum