GHRD Overview
The hardware component, or “Golden Hardware Reference Design” (GHRD), is a complete Quartus reference design targeting the Arria® 10 FPGA. The design includes the Hard Processor Subsystem (HPS) and custom logic running in the FPGA logic fabric. The HPS is configured using the Platform Designer tool in Quartus. After the HPS subsystem is generated, its HDL output is integrated in a top level HDL file that can be modified to include the user’s custom logic. The GHRD is available on the
REFLEX CES achilles-hardware github repository page and is automatically downloaded by the build scripts or can be manually cloned (more details below). The achilles-hardware repository branches are named according to the Quartus Prime Pro version tested with that release.
Beginning with the ghrd-v22.1 branch, the GHRD is now generated from TCL scripts. If you want to use the Quartus GUI, you must first generate the design using the scripted flow. Use the GSRD build script (see instructions on the
START HERE page) to specify the SOM version and the type of GHRD to build (standard or Partial Reconfiguration reference design).
The latest recommanded branch is ghrd-v23.1 . All versions of the Achilles SOM (V2 & V5) are supported by this branch.
While this branch is fully tested with Quartus Prime Pro v23.1, the user has the option to specify a different Quartus version. Only the version specified by any given branch name will be eligible for technical support when working with that branch.
The script-generated Platform Designer .qsys design file enables the following HPS peripherals:
HPS Hard Peripherals
- SDMMC
- EMAC1 (RGMII with MDIO)
- EMAC2 (RGMII with MDIO)
- USB1
- I2C0
- UART0
- GPIO (2x in HPS Dedicated I/O block)
- EMIF HPS (DDR4)
FPGA Soft Peripherals
- JTAG to Avalon Master Bridge
- PIO
- System ID
- RS232 UART to communicate with MAX 10
The GHRD is based on the Full_Featured.zip design archive available in the latest Achilles board support package Test Design folder. Refer to the README.txt file or the release notes in the header of the top level VHDL file of the GHRD for details of changes made to the Full_Featured design. Below is a block diagram of the GHRD.
There are 2 variations of the GHRD: a standard flat version and a partial reconfiguration version. In both cases, one of the main functions demonstrated is using the HPS to configure the FPGA. This requires the Early I/O Release feature to be enabled in the Quartus project. This feature splits the FPGA configuration sequence into two parts. The first part is the periphery image, which configures the FPGA I/O, Shared I/O, and enables the HPS External Memory Interface (EMIF). The second part is the core image, which configures the FPGA fabric.
In the flat design, there is only the base revision in the Quartus project. After full compilation, this version is used to generate programming files (periph.rbf and core.rbf) for full configuration of the FPGA from U-Boot/SPL. FPGA configuration file updates can be sent to the Achilles SOM remotely, but the entire FPGA needs to be reconfigured by rebooting the system and allowing the SPL and U-Boot to configure the FPGA periphery and core images.
In the partial reconfiguration version, there is a base revision that defines the static region containing design logic that does not change, and the PR region containing logic that can be dynamically reconfigured. Additional revisions are used to define the function of each PR persona. In the GHRD, the PR region contains logic to blink the red LED connected to FPGA user I/O pins. The default configuration will cause the LED to blink once every 0.67 sec. Three additional revisions contain logic to make the LED blink fast, slow, or return to the default blinking rate. This version is used to generate programming files for the static region as well as partial reconfiguration files for each persona. This is a very simplified example used to demonstrate partial reconfiguration controlled by the HPS. Using a standard feature available in the most recent Linux kernels, we can apply a devicetree overlay from Linux to update the PR region with the desired persona configuration file.
So why are there two different versions of the reference design? Due to the architecture of Arria 10 SoC, it is not possible to reconfigure only the core FPGA image from the HPS after the periphery image has been loaded. Only full FPGA reconfiguration is possible, which will reset the FPGA and reconfigure FPGA/HPS shared I/O and DDR memory controllers, causing the HPS to crash. By using partial reconfiguration and the associated Linux drivers available, the HPS can reconfigure only the specified regions of the FPGA while the memory controllers and shared I/O continue to operate. If you only need the HPS to configure the FPGA at power up and can tolerate down time for future upgrades, then you can use a standard flat design without specifying PR regions. Otherwise, if you need to support FPGA configuration file updates through Linux without rebooting your system, then you will need to implement PR regions in your design. Refer to the documentation links provided on the
RESOURCES page for implementing the PR flow in your design.
The image below describes the new GHRD build flow starting with the ghrd-v22.1 branch:
- The primary TCL script is achilles_ghrd_build_flow.tcl and is launched with the quartus_sh -t command from the achilles-ghrd-build.sh script.
- The achilles_ghrd_build_flow.tcl script then sources create_achilles_ghrd_project.tcl.
- Process are run within create_achilles_ghrd_project.tcl to create the the Quaruts project and make project assignments for the user specified SOM and GHRD
- Another process generates the achilles_qsys_script_GENERATED.tcl.
- If the user chose the Partial Reconfiguration GHRD, the PR revisions are created.
- The generated script then creates the Platform Designer .qsys file, instantiates the HPS and peripheral IP, and sets their configuration parameters.
- After the Platform Designer .qsys file and IP files are created, the Platform Designer system is generated.
- When this completes, the full Quartus compilation flow begins.
- Finally, after compilation finishes, the resulting .sof file is converted to the split .periph.rbf and .core.rbf configuration files which are used by the HPS to configure the FPGA.
Suggested Quartus Hardware reference designs available for Achilles SOM:
Directory structure of the GHRD (ghrd-v21.3 and older)
achilles-hardware
├── devicetree (contains devicetree overlay source files and pre-compiled dtbo binaries used for configuring the PR region; explained in more detail on the *SOFTWARE* page)
├── hps_isw_handoff (contains the software handoff files generated during compilation)
├── output_files (contains the programming files generated during compilation; fetched during software build and included on eMMC image file)
└── src (main source file directory)
└── ip (contains Platform Designer source files)
Directory structure of the GHRD (ghrd-v22.1 and newer)
achilles-hardware
├── precompiled
| ├── hps_isw_handoff (contains precompiled software handoff files for each SOM version, generated during compilation)
| └── rbf (contains precompiled FPGA configuration files for each SOM version; fetched during software build and included on eMMC image file)
└── src
├── hdl (contains VHDL source files)
└── script (contains Platform Designing source script files
Compiling the GHRD (ghrd-v22.1 and newer)
For the best user experience, it is recommended to use the GSRD build script described on the
START HERE page.
Advanced users may choose to run the
achilles-ghrd-build.sh script separately by following these instructions.
1. Open a terminal console and create a working directory for the build:
mkdir achilles-ghrd-2023.07
cd achilles-ghrd-2023.07
2. Download and run the Achilles GHRD Build Script. Running the script without any arguments will display the usage instructions. The SOM version and GHRD type are the minimum required arguments for the script. The example below will build the Partial Reconfiguration GHRD for the v5 Indus SOM:
wget https://raw.githubusercontent.com/reflexces/build-scripts/2023.07/achilles-ghrd-build.sh
chmod +x achilles-ghrd-build.sh
./achilles-ghrd-build.sh -s v5-indus -g pr
Compiling the GHRD (ghrd-v21.3 and older)
Detailed instructions for compiling the GHRD are not provided here. It is assumed that the user has sufficient knowledge of FPGA design and the Quartus development tools GUI to open a project and start the compilation process. This can be done on either a Windows or Linux system using the Quartus GUI (command line build scripts are not provided). The software build described on the
SOFTWARE page
must be done on Linux. It will simplify the process to work completely in Linux if possible, since you will not need to transfer files from Windows to Linux when moving on to the Software build stage. To use the GHRD as a starting point for your own design or to recompile it, download the ZIP archive using the github link above, or using
git to clone the repository and checkout the desired branch:
git clone https://github.com/reflexces/achilles-hardware.git
cd achilles-hardware
git checkout ghrd-v21.3
#OR
git checkout ghrd-v21.3-pr
Open the Quartus project and start a full compilation. If using the Partial Reconfiguration GHRD, remember to run a full compilation for each design revision persona after compiling the base revision.
Refer to the Partial Reconfiguration documentation listed on the
RESOURCES page for more information on the Partial Reconfiguration design flow. After the Quartus project compilation successfully completes, you will find the required software handoff files in the
hps_isw_handoff folder and the FPGA programming files in the
output_files folder of the Quartus project directory. Pre-compiled FPGA configuration files (.sof/.rbf) are provided with the GHRD in the github repository and are fetched and included in the generated eMMC image during the software build stage. If the GHRD was modified, then you will need to convert the generated achilles_ghrd.sof (or your_project.sof) file to split .rbf files (peripheral and core images). Do this by opening a command line terminal on your host build machine (Windows or Linux), browse to your project
output_files directory, and run the following command:
quartus_cpf --convert --hps -o bitstream_compression=on achilles_ghrd.sof achilles_ghrd.rbf
Note: To run the quartus_cpf command, it may be necessary to specify the full path to your quartus/bin64 installation directory if not already set in your environment PATH variable (e.g. ~/intelFPGA_pro/20.1/quartus/bin64/quartus_cpf …).
Warning: The .periph.rbf and .core.rbf configuration files must come from the same Quartus project and version. Attempting to mix configuration files from different projects or compilations will result in FPGA configuration failure.
The above step is the same for both the flat and PR versions of the GHRD. In the PR version, run this above command using the base revision .sof file (achilles_ghrd.sof) to generate the split .rbf files. For each of the PR region persona revisions, there is a setting enabled in each of the corresponding .qsf files that generates the PR region .rbf files during compilation:
set_global_assignment -name GENERATE_PR_RBF_FILE ON
Without this .qsf setting, you would have to run a similar
quartus_cpf command to convert the partial-mask file for the PR region for each persona revision in your design, for example:
quartus_cpf --convert blink_led_fast.pr_partition.pmsf blink_led_fast.pr_partition.rbf
These PR region .rbf files must be copied to the Achilles Linux root filesystem (
/lib/firmware is default) and are then referenced in a devicetree overlay file and applied to the base devicetree that is loaded with the Linux kernel during the boot process. The devicetree overlay process is described in more detail on the
SOFTWARE page. The .rbf and devicetree overlay files are automatically copied to the generated root filesystem based on instructions in the
achilles-firmware.bb recipe during the scripted build flow on the
SOFTWARE page. If using your own .rbf files generated from your project, you must ensure that they are copied correctly to the root filesystem if not using the scripted flow.
There is one additional step we need to manually perform to convert the periph.rbf and core.rbf files to the FIT image format used by U-Boot. This is explained on the
SOFTWARE page under the
Option 2: Generate FIT Images section.
Preparing for Software Handoff
If working in Windows to compile the FPGA design and transitioning to Linux at this time, open a terminal and create a top level working directory on your Linux host build system:
mkdir -p ~/achilles && cd ~/achilles
Make a copy of the
hps_isw_handoff folder to this working directory. If you are already working in Linux at this time, you can work with the existing directory on your Linux PC. You should have the following files in the
hps_isw_handoff folder:
achilles
└── hps_isw_handoff
├── emif.xml
├── hps.xml
└── id
Now you are ready to move on to building the
SOFTWARE components.
Software Build Instructions
All software compilation in this section must be done on a Linux host system.
Three options are presented here for generating the software components used to update the eMMC boot flash:
- A script-driven Yocto build which will generate all required software components in a WIC image file that can be copied to the eMMC flash on the Achilles SOM.
- Build individual software components and create your own eMMC image file.
- Use the provided WIC image to update the eMMC, and then build the individual software components and only update the partitions as needed for your application.
Option 1: Yocto Build
For an overview of the Yocto Project, visit the
Yocto Project Getting Started webpage.
For the best user experience, it is recommended to use the GSRD build script described on the
START HERE page.
Advanced users may choose to run the
reflex-yocto-build script separately by following these instructions.
The Yocto build is done by simply running 2 scripts:
- yocto-packages.sh - detects your host build system Linux distribution and installs a set of essential packages required by Yocto
- reflex-yocto-build - script used to build individual components or a complete image for the Achilles SOM (use --help to see available build options).
One advantage to the Yocto build is that at the end of the build process, you have a complete image ready to copy to the Achilles eMMC. A disadvantage is that the intial build time can be long (over an hour depending on your host build system). Subsequent builds complete much faster, as only required tasks will run (e.g. no need to fetch source code again). Also, customizing the Yocto BSP layer to your application requirements has a steep learning curve if you are not familiar with the Yocto/OpenEmbedded build system.
1. If not already done in the
HARDWARE section, open a system terminal console and create a working directory:
mkdir -p ~/achilles && cd ~/achilles
2. Install packages required for the Yocto build:
wget https://raw.githubusercontent.com/reflexces/build-scripts/2023.07/yocto-packages.sh
chmod +x yocto-packages.sh
sudo ./yocto-packages.sh
3. Download the Yocto Build Script:
wget https://raw.githubusercontent.com/reflexces/build-scripts/2023.07/reflex-yocto-build
chmod +x reflex-yocto-build
4. Choose one of the script build options below.
To see all available boards and build options:
./reflex-yocto-build --help
To build the default console image for the Achilles module (this option generates the WIC image file):
./reflex-yocto-build --board achilles-v5-indus --image console
To build U-Boot only:
./reflex-yocto-build --board achilles-v5-indus --image virtual/bootloader
To build the Linux kernel only:
./reflex-yocto-build --board achilles-v5-indus --image virtual/kernel
After the build completes successfully, all of the generated output files can be found in the directory
achilles-build-files/tmp/deploy/images/achilles-v5-indus. The main file of interest,
achilles-console-image-achilles-v5-indus.wic, is copied to copied to the directory
achilles-emmc-image. This file can be used to program the entire eMMC. Go to the
PROGRAM EMMC page to view the table detailing the full list of files generated and for instructions to program the eMMC flash.
For Achilles Yocto builds using the
meta-achilles layer, starting with the
kirkstone branch and newer, the FPGA FIT images and optional devicetree overlays (used by the Partial Reconfiguration GHRD example) are now automatically generated during the Yocto build process.
For Yocto builds using the
meta-achilles layer
honister branch or older, these items are
not automatically generated. Instead, they are fetched from the
achilles-hardware github repository and added to the WIC image during the Yocto build process. If bringing your own Quartus hardware design, the FIT images will need to be manually generated and copied to the eMMC partition 1 (FAT partition). FIT image generation is explained below under
Option 2: Generate FIT Images.
Achilles Yocto BSP Layer Description
The tree below describes the directory structure found in the
meta-achilles Yocto BSP layer and the function of each recipe. If you want to further examine
meta-achilles or any other layer used in the Yocto build process, you can find them in the generated build directory within the
layers sub-directory.
meta-achilles
├── conf (contains Achilles machine configuration file that defines HW configuration options, including U-Boot and kernel versions to build, instructions for files to include on the FAT partition of the WIC image, and other options)
├── recipes-achilles (recipes specific to Achilles !SOM to demonstrate various features)
│ ├── achilles-firmware (recipe to add FPGA configuration files to image)
│ ├── achilles-fpga-init (recipe to create a systemd service to apply devicetree overlay)
│ └── achilles-usb-gadget (recipe to create a systemd service to enable USB Gadget support)
├── recipes-bsp (recipe to patch and build U-Boot)
├── recipes-core (recipes for misc. system configuration)
├── recipes-images (recipes for complete images for Achilles SOM)
├── recipes-kernel (recipes to patch, configure, and build Linux kernel)
└── wic (contains WIC kick start file to configure the generated WIC image)
Option 2: Build U-Boot and Linux Kernel Individually
One advantage to building components individually is that the build time can be faster. A disadvantage is that you need to manually create the image for programming the eMMC device, or update partitions separately. You also still need a root filesystem, which can be built with other tools like Buildroot, or using "ready-made" root filesystem archives (e.g. Linaro).
Download the
Arm GNU Toolchain to build the individual software components:
mkdir -p ~/armgcc && cd ~/armgcc
wget https://developer.arm.com/-/media/Files/downloads/gnu-a/10.2-2020.11/binrel/gcc-arm-10.2-2020.11-x86_64-arm-none-linux-gnueabihf.tar.xz
tar xf gcc-arm-10.2-2020.11-x86_64-arm-none-linux-gnueabihf.tar.xz
Build U-Boot
1. If not already done previously, create a working directory:
mkdir -p ~/achilles && cd ~/achilles
1. Setup the Arm tools build environment:
export ARCH=arm
export CROSS_COMPILE=~/armgcc/gcc-arm-10.2-2020.11-x86_64-arm-none-linux-gnueabihf/bin/arm-none-linux-gnueabihf-
3. Clone the
u-boot-socfpga source repository. Create and switch to a new branch (achilles) for our build. We are checking out a specific revision within the socfpga_v2021.01 branch:
git clone https://github.com/altera-opensource/u-boot-socfpga
cd u-boot-socfpga
git checkout -b achilles 24e26ba4a0d8fe816e32e760537a3f356823ba7b
4. Download and apply the Achilles U-Boot patch:
# For Achilles v2 only
wget https://raw.githubusercontent.com/reflexces/meta-achilles/kirkstone-2023.07/recipes-bsp/u-boot/files/v2021.07/0001-Add-Achilles-V2-support-for-u-boot-socfpga.patch
git apply 0001-Add-Achilles-V2-support-for-u-boot-socfpga.patch
#For Achilles v5 only
wget https://raw.githubusercontent.com/reflexces/meta-achilles/kirkstone-2023.07/recipes-bsp/u-boot/files/v2021.07/0001-Add-Achilles-V5-support-for-u-boot-socfpga.patch
git apply 0001-Add-Achilles-V5-support-for-u-boot-socfpga.patch
4.1. If you are building U-Boot for Achilles v2 Turbo or Achilles v5 you need to apply a second patch:
wget https://raw.githubusercontent.com/reflexces/meta-achilles/kirkstone-2023.07/recipes-bsp/u-boot/files/v2021.07/0002-remove-sdram-size-check.patch
git apply 0002-remove-sdram-size-check.patch
5. If you are bringing in your own FPGA design, run the Quartus handoff filter script to convert your hps.xml file to U-Boot header file to be used by the Achilles U-Boot devicetree.
NOTE: If you used the Achilles GHRD as a starting point for your design and did not make changes to the HPS, this step is not required.
./arch/arm/mach-socfpga/qts-filter-a10.sh <path/to/your/quartus/project>/hps_isw_handoff/hps.xml arch/arm/dts/socfpga_arria10_achilles_handoff.h
6. Configure and build U-Boot for your version of Achilles SOM:
make socfpga_arria10_achilles_v2_indus_defconfig
#OR
make socfpga_arria10_achilles_v2_lite_defconfig
#OR
make socfpga_arria10_achilles_v2_turbo_defconfig
#OR
make socfpga_arria10_achilles_v5_indus_defconfig
#OR
make socfpga_arria10_achilles_v5_lite_defconfig
make -j 64
Generate FIT Images
This step is required only if you are not using the scripted build flow.
Now we can generate the FIT images using the split .rbf FPGA programming files generated in the
HARDWARE section. These are used by the SPL and U-Boot to configure the FPGA. The Achilles U-Boot patch has configured the U-Boot source code to have the SPL load only the peripheral FPGA image, and then U-Boot loads the core image. This is significantly faster than having the SPL load both images.
NOTE: this process of generating FIT images is currently not run automatically during the Yocto build. Instead, pre-generated FIT files using the Achilles GHRD .rbf files are fetched and included in the generated WIC eMMC image. You must complete these steps if using your own custom FPGA design.
First create symbolic links to point to the location of the .rbf files generated in the
HARDWARE section. References below are to the Achilles GHRD .rbf files. Replace with your own file names if applicable, but do not rename the .its or .itb file references since these are defined in U-Boot source code. The .its files define the locataion and names of the .rbf files to be used when creating the .itb files.
ln -s <path/to/rbf/files>/achilles_ghrd.periph.rbf
ln -s <path/to/rbf/files>/achilles_ghrd.core.rbf
tools/mkimage -E -f board/reflexces/achilles-v5-indus/fit_spl_fpga_periph_only.its fit_spl_fpga_periph_only.itb
tools/mkimage -E -f board/reflexces/achilles-v5-indus/fit_spl_fpga.its fit_spl_fpga.itb
Now we have the following files that can be copied to the eMMC:
| File |
Description |
eMMC Partition |
| spl/u-boot-splx4.sfp |
Multiple SPL binaries with devicetree and header info |
Partition 2 (A2 raw) |
| u-boot.img |
U-Boot binary image |
Partition 1 (VFAT) |
| achilles_ghrd.core.rbf |
core.rbf image for FPGA core image configuration |
| fit_spl_fpga_periph_only.itb |
FIT image for FPGA peripheral image configuration only |
| fit_spl_fpga.itb |
FIT image for FPGA core image configuration |
If you compiled your own FPGA design or made modifications to the GHRD, you must manually copy the generated files listed above to the appropriate eMMC partition. Refer to the instructions on the
PROGRAM EMMC page.
Note: Either the .rbf or .itb file can be used for FPGA core image configuration in U-Boot. The .itb file is used by default U-Boot environment commands. Both files are included for completeness of the example.
To load the .rbf file from U-Boot, enter the command at the U-Boot prompt:
load mmc 0:1 ${loadaddr} achilles_ghrd.core.rbf
fpga load 0 ${loadaddr} 0xE20000
Build Linux Kernel
1. If not already done previously, create a working directory:
$ mkdir -p ~/achilles && cd ~/achilles
2. Clone the
linux-socfpga kernel source repository. Create and switch to a new branch (achilles) for our build, specifying the branch corresponding to the kernel version you want to build:
git clone https://github.com/altera-opensource/linux-socfpga
cd linux-socfpga
git checkout -b achilles -t origin/socfpga-5.10.100-lts
3. Download and apply the Achilles Linux devicetree patch:
wget https://raw.githubusercontent.com/reflexces/meta-achilles/kirkstone-2023.07/recipes-kernel/linux/config/socfpga-5.10-lts/patches/0001-add-achilles-devicetree.patch
git apply 0001-add-achilles-devicetree.patch
4. If working in a different terminal session from the one used previously to build U-Boot, you will need to setup the Arm tools build environment again:
export ARCH=arm
export CROSS_COMPILE=~/armgcc/gcc-arm-10.2-2020.11-x86_64-arm-none-linux-gnueabihf/bin/arm-none-linux-gnueabihf-
Configure and build the Linux kernel:
make mrproper
make socfpga_defconfig
5. If you want to include support for USB Gadget (as done in the Yocto build), then add that kernel configuration fragment. You can add any additional kernel configuration options as required for your application at this time.
wget https://raw.githubusercontent.com/reflexces/meta-achilles/kirkstone-2023.07/recipes-kernel/linux/config/socfpga-5.10-lts/cfg/usb-gadget.cfg
./scripts/kconfig/merge_config.sh .config usb-gadget.cfg
6. Build the kernel image, Achilles devicetree, and kernel modules.
make -j 64 zImage socfpga_arria10_achilles_v5_indus.dtb modules
7. Install the kernel modules:
make modules_install INSTALL_MOD_PATH=modules_install
rm -rf modules_install/lib/modules/*/build
rm -rf modules_install/lib/modules/*/source
mkdir -p linux-bin/a9
ln -s arch/arm/boot/zImage linux-bin/a9/
ln -s arch/arm/boot/dts/socfpga_arria10_achilles_v5_indus.dtb linux-bin/a9/
ln -s modules_install/lib/modules linux-bin/a9/
8. Archive the modules for transfer to the eMMC.
kernel_mod_dir=$(ls modules_install/lib/modules/)
tar -czvf modules_install/lib/modules/modules.tar.gz modules_install/lib/modules/$kernel_mod_dir
Now we have the following files that will be copied to the eMMC:
| File Name |
Description |
eMMC Partition |
| arch/arm/boot/zImage |
Compressed kernel image |
Partition 1 (VFAT) |
| arch/arm/boot/dts/socfpga_arria10_achilles_v5_indus.dtb |
Achilles Linux devicetree |
Partition 1 (VFAT) |
| modules_install/lib/modules/modules.tar.gz |
Kernel modules archive |
Partition 3 (EXT4) /lib/modules |
Devicetree Overlays
A devicetree overlay is used to dynamically add additional device nodes to the "live" devicetree currently loaded by the kernel. An overlay can add peripherals that are implemented in FPGA logic (e.g. UART, soft Ethernet MAC, PIO, etc.) or external peripherals that connect to the hard interfaces in the HPS (e.g. I2C or SPI devices, USB, or Ethernet). External peripherals would typically connect through the FMC connector to the baseboard that the Achilles SOM is plugged into, or through an FMC daughterboard plugged into the Achilles top FMC connectors. Overlays can also be used to configure or reconfigure the FPGA. Alternatively, any custom peripheral (in the FPGA or external) could be added to the base devicetree source file provided here in the GSRD, but reconfiguring PR regions through Linux can only be done with the use of an overlay. Note that there are kernel configuration elements that are required to support this and they are included in the standard default
defconfig file used to build the kernel for Arria 10 SoC devices. More information is available in the kernel Documentation folder.
Creating and Compiling an Overlay
For Achilles Yocto builds using the
meta-achilles layer, starting with the
kirkstone branch and newer, the optional devicetree overlays (used by the Partial Reconfiguration GHRD example) are now automatically generated during the Yocto build process.
For Yocto builds using the
meta-achilles layer
honister branch or older, you will still need to manually compile your devicetree overlays. Pre-compiled binaries (.dtbo files) specific to the GHRD PR example are fetched and added to the generated eMMC image during the Yocto build. To compile your own overlays, you will need to follow the steps above for
Build Linux Kernel under Option 2 to clone the
socfpga-linux repository and compile the .dtso files. Several example devicetree source overlay (.dtso) files are included in the
devicetree directory of the GHRD to demonstrate adding peripherals to the base devicetree, as well as configuring the partial reconfiguration region defined in the GHRD. If you want to recompile the source files, or need to modify them to fit your application, follow these steps:
Clone the
linux-socfpga kernel source repository as instructed above.
Copy the .dtso files to the kernel source tree folder containing all of the mainlined devicetrees (
arch/arm/boot/dts).
Compile the .dtso files using either of these 2 method:
Then build the devicetree overlays:
make -j 64 achilles_ghrd_base.dtb achilles_sysid.dtb blink_led_default.dtb blink_led_fast.dtb blink_led_slow.dtb
Note that the make utility expects to see the .dts filename extension for devicetree input source files and will generate .dtb output files. If you plan to use the test script provided in the meta-achilles layer to apply the overlays, you will need to manually rename the input .dtso to .dts, and the output .dtb to .dtbo. There is no requirement in Linux to use these extensions; however, these are the extensions used in the GHRD example to differentiate them as devicetree overlays.
Copy the generated .dtbo files to the Achilles root filesystem
/lib/firmware directory. This is the default directory used by
configfs, but other directories can be specified if desired. Refer to the
PROGRAM EMMC page for instructions on copying files to the various eMMC parititions. In this case, you will be copying to partition 3 (the Linux EXT4 partition).
Applying an Overlay
An devicetree overlay is applied using the Linux
configfs.
Create a
configfs config_item and apply the overlay:
mkdir /sys/kernel/config/device-tree/overlays/my-overlay-dir-name
echo my-overlay-file.dtbo > /sys/kernel/config/device-tree/overlays/my-overlay-dir-name/path
where
my-overlay-dir-name can be any arbitrary descriptive name, typically similar to the .dtbo file name.
You can check the status of the overlay:
cat /sys/kernel/config/device-tree/overlays/my-overlay-dir-name/status
applied
A script is provided as part of the GSRD and can be used to apply the various PR region overlays to change the LED blink rate, as demonstrated on the
START HERE page. The script is located on the Achilles root filesystem at
/home/root/pr_overlay.sh.
Program eMMC
The scripted Yocto build process will generate a WIC image file with the partition layout as shown in the image below.
A script is available to make the eMMC programming process easier. The script can be run as part of the full GSRD build process by running the GSRD build script (see the
START HERE page), or it can run independently. This script can run in Linux or Windows (using Nios II Command Shell or WSL shell). To manually download and run the script:
wget https://raw.githubusercontent.com/reflexces/build-scripts/2023.07/program-emmc.sh
chmod +x program-emmc.sh
./program-emmc.sh
The table below summarizes the files included in the WIC image and how each file is generated. The latest released version of each of these files can be downloaded from the
meta-achilles github release page
| File Name |
Description |
Partition |
Source of File |
| achilles-console...rootfs.tar.gz |
Poky root filesystem |
Partition 3 (EXT4) |
Yocto build |
| u-boot-splx4.sfp |
SPL image with devicetree |
Partition 2 (A2) |
Yocto build or U-Boot make |
| socfpga_arria10_achilles.dtb |
Devicetree binary |
Partition 1 (FAT) |
Yocto build or dtbs make |
| achilles_ghrd.core.rbf |
FPGA core configuration file |
quartus_cpf after Quartus GHRD build |
| fit_spl_fpga_periph_only.itb |
FPGA periphery FIT image |
U-Boot mkimage |
| fit_spl_fpga.itb |
FPGA core FIT image |
U-Boot mkimage |
| zImage |
compressed Linux kernel image |
Yocto build or kernel make |
| u-boot.img |
U-Boot binary image |
Yocto build or U-Boot make |
| extlinux/extlinux.conf |
boot configuration file |
Yocto build (achilles.conf) |
The precompiled WIC image can be downloaded from here, or they can be downloaded automatically by using the programming script:
Older releases for Turbo SOM
Older releases for V2 SOM versions
Latest releases for all SOM versions
Prerequisites for Programming eMMC
Note: when using the eMMC Programming script, you must still setup a TFTP server and complete Steps 1 - 3 below. The remaining steps are done automatically by the programming script.
In order to write a full eMMC image or update any partition of the eMMC, it is necessary to setup a TFTP server and boot the Achilles SOM from the network instead of booting from the eMMC. This is necessary in most cases (especially for full WIC image programming) because we don't want to modify a live mounted eMMC that we just booted from. Booting an initramfs from TFTP leaves the eMMC unmounted and safe to modify. REFLEX CES provides the example design
RefDesign_HPS_boot_from_FPGA in the Achilles board support package that faciltates this process. You can configure the Arria® 10 FPGA with the .sof image that contains U-Boot running from FPGA on-chip RAM, which then boots the initramfs image containing the Linux kernel and minimal root filesystem running from RAM. Once fully booted, you can then use standard Linux commands to program the eMMC. It is not necessary to recompile this reference design in Quartus. Downloading and configuring the FPGA with this design is done automatically by the programming script.
The zImage Linux kernel with embedded initramfs can be downloaded from the links in the table or by using the command line examples below:
| SOM Version |
File Name |
Description |
md5sum |
| V2 Turbo |
linuxDT.dtb |
Linux devicetree binary |
4b7301146c1f148006440f7f63c2399b |
| zImage |
Linux kernel image with initramfs |
957e27a44e286975ad674f9545106fc8 |
| V2 Indus |
linuxDT.dtb |
Linux devicetree binary |
93d9b250c05ec63930ee4f2f2a967af2 |
| zImage |
Linux kernel image with initramfs |
1a43531bb37d4d421d5016c5e1c52879 |
| V2 Lite |
linuxDT.dtb |
Linux devicetree binary |
ea379d51668c5a5574a5a8603dbac9b6 |
| zImage |
Linux kernel image with initramfs |
5b3e731a57cbeca4340f149f7a3e7ca4 |
| V5 Indus |
linuxDT.dtb |
Linux devicetree binary |
d9ad385183620563336a89ae94a7a4e0 |
| zImage |
Linux kernel image with initramfs |
9bef9b5987012f0562103117792052f2 |
| V5 Lite |
linuxDT.dtb |
Linux devicetree binary |
865f7c055a575bc8422f2c24ad0cbe50 |
| zImage |
Linux kernel image with initramfs |
efdf57b80dd2185cc520ba43eb3580b5 |
For V2 Turbo SOM:
wget https://raw.githubusercontent.com/reflexces/build-scripts/2023.07/prog-files/tftp-boot-files/SomA10-V2/Turbo/linuxDT.dtb
wget https://raw.githubusercontent.com/reflexces/build-scripts/2023.07/prog-files/tftp-boot-files/SomA10-V2/Turbo/zImage
For V2 Indus SOM:
wget https://raw.githubusercontent.com/reflexces/build-scripts/2023.07/prog-files/tftp-boot-files/SomA10-V2/Indus/linuxDT.dtb
wget https://raw.githubusercontent.com/reflexces/build-scripts/2023.07/prog-files/tftp-boot-files/SomA10-V2/Indus/zImage
For V2 Lite SOM:
wget https://raw.githubusercontent.com/reflexces/build-scripts/2023.07/prog-files/tftp-boot-files/SomA10-V2/Lite/linuxDT.dtb
wget https://raw.githubusercontent.com/reflexces/build-scripts/2023.07/prog-files/tftp-boot-files/SomA10-V2/Lite/zImage
For V5 Indus SOM:
wget https://raw.githubusercontent.com/reflexces/build-scripts/2023.07/prog-files/tftp-boot-files/SomA10-V5/Indus/linuxDT.dtb
wget https://raw.githubusercontent.com/reflexces/build-scripts/2023.07/prog-files/tftp-boot-files/SomA10-V5/Indus/zImage
For V5 Lite SOM:
wget https://raw.githubusercontent.com/reflexces/build-scripts/2023.07/prog-files/tftp-boot-files/SomA10-V5/Lite/linuxDT.dtb
wget https://raw.githubusercontent.com/reflexces/build-scripts/2023.07/prog-files/tftp-boot-files/SomA10-V5/Lite/zImage
Whether you already have a TFTP server setup, or you need to
configure one first, it is necessary to change or set some parameters to match the expected values specified in the U-Boot environment variables used in the “RefDesign_HPS_boot_from_FPGA” reference design. The default U-Boot environment values are summarized in the table below. Refer to the Achilles Reference Manual "HPS Development" chapter for addtional details.
| TFTP Server Parameter |
u-boot env variable setting |
| server IP address (v2): 192.168.1.200 |
serverip=192.168.1.200 |
| server path: SomA10-V2/Turbo/ |
tftppath=SomA10-V2/Turbo/ |
| server path: SomA10-V2/Indus/ |
tftppath=SomA10-V2/Indus/ |
| server path: SomA10-V2/Lite/ |
tftppath=SomA10-V2/Lite/ |
| server IP address (v5): 192.168.200.200 |
serverip=192.168.200.200 |
| server path: SomA10-V5/Indus/ |
tftppath=SomA10-V5/Indus/ |
| server path: SomA10-V5/Lite/ |
tftppath=SomA10-V5/Lite/ |
These files must be located in the TFTP server path specified in the
tftppath variable (see download information above):
| File Name |
u-boot env variable setting |
| linuxDT.dtb |
fdtfile=linuxDT.dtb |
| zImage |
bootimage=zImage |
With a network managed by a DHCP server, interrupt the boot process in U-Boot and modify some U-Boot environment variables with the commands:
setenv serverip <tftp-server-ip-addr>
setenv rxcethboot "setenv bootargs console=ttyS0,115200 ip=dhcp ; bootz ${loadaddr} - ${fdtaddr}"
setenv rxcethload "dhcp ; tftp ${loadaddr} ${tftppath}${bootimage} ; tftp ${fdtaddr} ${tftppath}${fdtimage} ;"
# Restart the boot process
run bootcmd
On a network without a DHCP server, interrupt the boot process in U-Boot and modify some U-Boot environment variables with the commands:
setenv ipaddr <board-ip-addr>
setenv serverip <tftp-server-ip-addr>
setenv rxcethboot "setenv bootargs console=ttyS0,115200 ip=none ; bootz ${loadaddr} - ${fdtaddr}"
setenv rxcethload "tftp ${loadaddr} ${tftppath}${bootimage} ; tftp ${fdtaddr} ${tftppath}${fdtimage} ;"
# Restart the boot process
run bootcmd
After changing the variables, you can make them permanent by using the
saveenv command before restarting the boot process by using the
run bootcmd comand.
Writing Full WIC Image to eMMC
Once the TFTP server is setup, you can perform a network boot and program the Achilles eMMC by following these steps. Some knowledge of connecting to the Achilles SOM usinng terminal emulator software (e.g.
PuTTY, Minicom, etc) and use of the Quartus Programmer is assumed for these steps. Refer to the Achilles Reference Manual if you need assistance.
Boot the initramfs Image
1. With the Achilles SOM and carrier board powered off, carefully remove the SOM from the carrier board and move the MSEL1 switch on the reverse side of the board to the ON position as shown in the image below. This will enable the FPP x32 configuration mode of the Arria® 10 FPGA, as required for the HPS to configure the FPGA.
2. Plug the SOM back into the carrier board. Plug in a microUSB cable between the host PC and the microUSB connector on the carrier board labeled “BLASTER”. Plug in an Ethernet cable between your network router and the RJ-45 Ethernet port labeled “ETH1”. Verify that the BSEL pins are set as shown in the image below (0x5) to enable boot from 3.0V SD/MMC flash.
3. Open your preferred terminal emulator software. Power on the board and establish a connection between the board and the terminal emulator. If using the Achilles SOM in factory condition, you should not see any output on the terminal at this time because the new MSEL switch position will prevent FPGA configuration in AS mode. If you have already programmed the eMMC with this example image and U-Boot loads the FPGA core.rbf file, you will need to interrupt the boot process at U-Boot to prevent core.rbf programming. Otherwise, the Quartus programmer will fail in the next step.
4. Open the Quartus Programmer tool and click the “Hardware Setup” button and establish a connection to the Achilles SOM (“Arria10 IDK”). Auto detect the JTAG chain and accept all detected device defaults. Click to select the Arria® 10 device in the list and click "Add File" to add a programming file. Browse to the location of the .sof file downloaded from the link above and select it. If a second Arria® 10 device appears in the list below the one with the file just added, then delete it. Check the “Program/Configure” box, and click "Start" to program the FPGA. Once programming completes, you should start to see output to the serial terminal.
Program the eMMC (through USB key)
5.a. Copy the Yocto generated WIC image on a USB key and plug the USB key in the USB OTG port of the Carrier Board.
NOTE: The USB adapter must be On-The-Go compliant.
5.b. On Achilles SOM serial terminal emulator session, mount the USB key partition.
mkdir -p /mnt/key
mount -o ro /dev/sda1 /mnt/key
5.c. On Achilles SOM serial terminal emulator session, clone the image file to the eMMC. There is no need to mount the eMMC device first to clone the full image.
dd if=/mnt/key/achilles-console-image-achilles-v5-indus.wic of=/dev/mmcblk0 && sync
5.d. After the cloning process is complete, shut down the initramfs session on Achilles:
poweroff
5.e. Power cycle the Achilles board. Do not just issue a
reboot command from the Linux command prompt; you must power cycle the board after the
dd process completes. You should now observe the boot process in your terminal emulator. First, the FPGA periphery image is loaded by the SPL. The SPL then loads the u-boot.img file from the FAT partition and U-Boot starts. The FPGA core image is then programmed by U-Boot and then the Linux kernel, devicetree, and root filesystem are loaded. You should finally arrive at the Poky linux prompt.
Program the eMMC (through Ethernet)
6.a. If the board is connected on a network with a DHCP server, just get the IP address affected to the board, otherwise set a static IP address to the board.
Get Ethernet IP addresses on Achilles SOM via serial terminal emulator:
ip address show up
If needed, set Eth0 static IP address on Achilles SOM via serial terminal emulator:
ip link set eth0 up
ip address add 192.168.200.42/24 dev eth0
6.b. To copy the Yocto generated WIC image to the Achilles eMMC, open a terminal window on your Linux host and browse to the directory containing the WIC image.
6.c. Copy the WIC image to the initramfs session running on the Achilles SOM:
scp achilles-console-image-achilles-v5-indus.wic root@<board-ip-addr>:/
Be sure to enter the correct IP address for the Achilles board that you noted in step 6.a above.
Type
yes to accept the connection and then enter the Achilles initramfs password
root.
The file will take about 2 minutes to transfer.
6.d. After the transfer is complete, go back to the Achilles serial terminal emulator session and clone the image file to the eMMC. There is no need to mount the eMMC device first to clone the full image.
dd if=achilles-console-image-achilles-v5-indus.wic of=/dev/mmcblk0 && sync
6.e. Continue at the step 5.d in the previous chapter.
Updating Individual eMMC Partitions
If you want to update individual files on any of the partitions, follow the steps above to load the initramfs image over your network. Then copy the files you want to update to the corresponding Achilles eMMC partition. Note that you can update individual eMMC partitions on the REFLEX CES factory default eMMC layout with the binary files provided here, but you will need to update several U-Boot environment variables to point to the correct FAT partition.
Mount the partition you want to update:
Partition 1 (FAT)
On Achilles SOM via serial terminal emulator:
mkdir -p /media/emmcp1; mount -t vfat /dev/mmcblk0p1 /media/emmcp1; cd /media/emmcp1
On Linux host, copy files to the mounted partition:
scp <filename> root@<board-ip-addr>:/media/emmcp1
Partition 2 (A2)
It is not necessary to mount the raw A2 partition to update it with a new U-Boot/SPL image:
On Linux host, copy files to root (/) on the initramfs session:
scp <u-boot-spl-image-name> root@<board-ip-addr>:/
On Achilles SOM via serial terminal emulator:
dd if=<u-boot-spl-image-name> of=/dev/mmcblk0p2 && sync
Partition 3 (EXT4)
NOTE: This step is only required if you booted from the initramfs and the eMMC is not mounted. If booting to Poky Linux from eMMC, it is not necessary to mount this partition since it is already mounted.
On Achilles SOM via serial terminal emulator:
mkdir -p /media/emmcp3; mount -t ext4 /dev/mmcblk0p3 /media/emmcp3; cd /media/emmcp3
On Linux host, copy files to the mounted partition:
scp <rootfs_archive.tar.xz> root@<board-ip-addr>:/media/emmcp3
or
scp <new_fpga_prog_file.rbf> root@<board-ip-addr>:/lib/firmware
When file copying is complete, shut down the initramfs session on Achilles:
poweroff
Power cycle the Achilles board
Creating Your Own eMMC Image
If you built the individual hardware and software system components and want to create your own eMMC image, you can follow the example available on the
Building Bootloader article page. Scroll down to section
C. Build SD Card Image. Then follow the steps above to clone the image to the Achilles eMMC.
The Achilles SOM by REFLEX CES features an Intel® PSG Arria® 10 SX SoC FPGA. With an ARM dual-core Cortex-A9 MPCore and up to 660 KLEs of advanced low-power FPGA logic elements, the Arria® 10 SoC combines the flexibility and ease of programming of a CPU with the configurability and parallel processing power of an FPGA. The SOM is available to purchase as part of a development kit for evaluation and prototyping, or as a production-ready module designed into your electronic assembly. The SOM also features industry standard FMC connectors to allow for easy integration of additional connectivity, video interfaces, data converters, and many other options available through FMC daughter cards.
Achilles offers developers an excellent out-of-box experience. With our intuitive software GUI environment, users can power-up the board and demonstrate functionality of the major interfaces in just a few minutes. The board support package includes full documentation and a suite of reference designs to quickly enable the FPGA development process.
Ideal target markets include Automotive, Video Broadcast, Machine and Intelligent Vision, Industrial, Military, Test & Measurement, and Medical.
There are 6 versions of the SOM available:
| SOM Version |
v2 Lite |
v2 Indus |
v2 Turbo |
v5 Indus |
v5 Indus 12G |
v5 Lite |
| FPGA Density |
270 KLE |
660 KLE |
660 KLE |
660 KLE |
660 KLE |
270 KLE |
| FPGA Speed Grade |
-2 |
-1 |
-1 |
-1 |
-1 |
-2 |
| DDR4 SDRAM FPGA |
2 GB, 2133 MT/s |
2 GB, 2400 MT/s |
4 GB, 2400 MT/s |
4 GB, 2400 MT/s |
4 GB, 2400 MT/s |
4 GB, 2133 MT/s |
| DDR4 SDRAM HPS |
2 GB, 2133 MT/s |
2 GB, 2400 MT/s |
3 GB, 2400 MT/s |
3 GB, 2400 MT/s |
3 GB, 2400 MT/s |
3 GB, 2133 MT/s |
| eMMC |
8 GB |
32 GB |
32 GB |
32 GB |
32 GB |
32 GB |
| FMC Connectors |
Bottom Only |
Top & Bottom |
Top & Bottom |
Top & Bottom |
Bottom Only |
Bottom Only |
Note: Achilles Development Kit comes with v2 Turbo version SOM
SOM Specifications
FPGA
- Arria® 10 SX, 10AS066H2F34I1HG, F34 package, -1 speed grade
- Up to 660K Logic Elements (KLEs) with over 1M registers
- Up to 2,133 M20K memory blocks, offering 42 Mb of memory
- Up to 5.7 Mb of MLAB memory
- Up to 3,376 18 x 19 multipliers providing 1,519 GFLOPS of peak floating-point performance
FPGA Hard Processor Subsystem
- Dual-core ARM® Cortex™-A9 MPCore processor
- Up to 1.5 GHz max processor frequency
- Enhanced with NEON Extension and Single & Double Precision Floating point unit
- 32 KB L1 Instruction & Data Cache
- Shared 512KB L2 Cache
- 256 KB on-chip RAM
FPGA Configuration & HPS boot
- AS configuration supported with EPCQL512, remote upgrade support and fail-safe functionality: AS, Configuration via Protocol (CvP)
- Up to 32 GB eMMC for HPS boot flash to store U-Boot, Linux kernel, and root filesystem
Communication Interfaces on SOM
- 2x 10/100/1000 Ethernet PHYs connected to HPS
- 1x USB 3.0 device connectivity using Cypress FX3 super speed controller (Indus/Turbo only)
- 1x USB 2.0 Device/Host PHY
- 1x USB OTG support connected to the HPS
- 1x I²C slave interface (HPS can drive external device)
- 1x UART connected to the HPS (UART over USB interface)
- 1x UART connected to System controller (MAX10 / UART over USB interface)
- 1x PCIe Gen3 x8 Hard IP interface routed through FMC
Memory
| SOM Version |
v2 Lite |
v2 Indus |
v2 Turbo |
v5 Indus |
v5 Indus 12G |
v5 Lite |
| 1 bank on-board DDR4 connected to FPGA |
2 GB, x32, 2133 MT/s |
2 GB, x32, 2400 MT/s |
4 GB, x32, 2400 MT/s |
4 GB, x32, 2400 MT/s |
4 GB, x32, 2400 MT/s |
4 GB, x32, 2133 MT/s |
| 1 bank on-board DDR4 connected to HPS |
2 GB, x32, 2133 MT/s |
2 GB, x32, 2400 MT/s |
3 GB, x32, 2400 MT/s |
3 GB, x32, 2400 MT/s |
3 GB, x32, 2400 MT/s |
3 GB, x32, 2133 MT/s |
Peripherals
- 1x Real Time Clock (RTC) connected to HPS I²C interface
- 1x Temperature Sensor connected to HPS I²C interface
- 1x EEPROM on Carrier board connected to HPS I²C interface (through FMC bottom right connector)
- 2x User LEDs connected to FPGA I/O
- 2x User LEDs connected to HPS I/O
FMC Connectivity Features
- 1x FMC LPC bottom connector with HPS signals and 14 transceivers (Bottom-Right)
- 1x FMC HPC (Indus/Turbo) or LPC (Lite) bottom connector (Bottom-Left)
- Up to 24 transceivers available:
- 10x XCVR dedicated to FMC HPC Top connector or to the FMC HPC Bottom connector (Top or Bottom-Left)
- 10x XCVR dedicated to FMC LPC Top connector or to the FMC LPC Bottom connector (Top or Bottom-Right)
- 4x additional XCVR dedicated to the FMC LPC Bottom connector (Bottom-right)
- LVDS and LVCMOS (1.8V FMC VITA 57.1 compliant)
- 80 LVDS bidirectional (or 160 Single ended) on FMC HPC Top connector (Top or Bottom-Left)
- 32 LVDS bidirectional (or 64 Single ended) on FMC LPC Top connector (Top or Bottom-Left)
Mechanical & Thermal
- Size: 86 mm x 95mm (3.4" x 3.8")
- Custom heat spreader, heat sink, and fan delivered with every module
Achilles SOM Block Diagram
SOM Carrier Board Options
The Achilles SOM cannot operate stand-alone and requires a carrier card. There are 3 options available:
Option 1: Achilles Starter Board (included with purchase of Development Kit)
- Evaluation mode on desktop with AC power supply
- 2x Ethernet RJ-45 connectors
- 1x USB 3.0 Micro B connector (FPGA)
- 1x USB OTG Mini AB (HPS)
- 1x USB micro A connector for UART connection to HPS and MAX 10 System Controller interface and on-board USB Blaster II for FPGA programming
- 1x I²C 4 pin header (HPS)
- 1x PMBus connector for Digital Power System management, configure and interrogate the PSM Devices with LTpowerPlay using the Linear Powerplay DC1613A USB cable (cable not included)
- Size: 100 mm x 140 mm (3.94" x 5.51")
Achilles Starter Board and Block Diagram
Option 2: Achilles PCIe Carrier Board (sold separately)
- Evaluation mode plugged into PCIe slot OR on desktop with AC power supply (not included with PCIe Carrier)
- Includes all the interfaces available on the Starter Board, plus:
- PCIe Gen3 x8 card edge connector * 1x QSFP+ quad optical cage (4 XCVR @ 10.3125 Gbps per link)
- 2x SFP+ single optical cage (2 XCVR @ 10.3125 Gbps per link)
- 1x WiFi 802.11 b/g/n IoT module with SPI and SDIO interface to host controller
- 1x 10 pin LCD connector * Size: PCIe Standard height, half length - 111.15 mm x 167.65 mm (4.38" x 6.60")
Achilles PCIe Carrier Board and Block Diagram
Option 3: Custom Carrier
- Design your own carrier using our Carrier Design Guide
- Use REFLEX CES custom design services
Development Kit Deliverables
- Achilles Arria® 10 SoC SOM
- Starter Board
- VHDL test and reference designs
- Documentation package
- Reference manual, Starter Guide, and Carrier Design Guide * Starter board schematics * SOM Super Pinout file (showing all FPGA ↔ FMC connections, trace length, etc.)
- Mechanical files (3D DWF/STEP models and 2D drawing available upon request)
- LTPowerPlay project
Purchase
Please contact REFLEX CES Sales:
Europe, Japan:
sales @ reflexces.com
Americas, Asia Pacific:
salesusa @ reflexces.com
Achilles GSRD Overview
The GSRD (Golden System Reference Design) example presented here for the Achilles SOM consists of a Hardware component and a Software component. The GSRD demonstrates the following features:
- Quartus Prime Pro FPGA reference design with HPS system configuring the available hardware peripherals on Achilles SOM and Starter carrier board
- Generation of HPS software components required to boot to Linux
- SPL/U-Boot
- Linux kernel
- Achilles devicetree binary
- Root filesystem
- FPGA configuration from HPS:
- From SPL/U-Boot (peripheral image only)
- From U-Boot proper (core image only)
- Application of devicetree overlay
- FPGA partial reconfiguration from Linux
- Dynamically update devicetree with new peripherals
- Web server
- USB gadget support
- Achilles SOM appears as mass storage device
- Ethernet over USB
GSRD version history and release table
| GSRD Version |
Release Date |
GHRD Quartus Version |
meta-achilles branch |
U-Boot Version |
Kernel Version |
Root Filesystem Version |
| v1.0 |
May 2020 |
v20.1 |
warrior |
v2019.10 |
4.14.130-ltsi |
Angstrom v2019.06-warrior |
| v2021.08 |
August 2021 |
v21.1 |
gatesgarth |
v2021.01 |
5.4.104-lts |
Yocto Poky gatesgarth 3.2.4 |
| v2021.12 |
December 2021 |
v21.3 |
honister |
v2021.07 |
5.10.60-lts |
Yocto Poky honister 3.4.1 |
| v2022.06 |
June 2022 |
v22.1* |
kirkstone |
v2021.07 |
5.10.100-lts |
Yocto Poky kirkstone 4.0.1 |
| v2023.07 |
June 2023 |
v23.1* |
kirkstone |
v2021.07 |
5.10.100-lts |
Yocto Poky kirkstone 4.0.8 |
Getting Started
The 2022.06 GSRD release introduces a new and more user-friendly script (reflex-gsrd-build.sh) to complete all of the GSRD build tasks. The three main tasks, which correspond to the Tabs at the top of this page, are:
- Build the FPGA reference design - HARDWARE
- Build the HPS software components using the Yocto project tool flow - SOFTWARE
- Program the eMMC flash on the SOM using the generated WIC image from step 2. - PROGRAM EMMC
The script uses a series of menus to choose the build task(s) to run, apply the required settings for each task, and then begin processing those tasks. For the best user experience, it is recommended to use the GSRD build script. Advanced users may choose to run the individual build steps on each subsequent page. From this
START HERE page, follow these instructions to launch the full GSRD build script:
1. Open a terminal console and create a working directory for the build:
mkdir achilles-gsrd-2023.07
cd achilles-gsrd-2023.07
2. Install required packages (most are used by Yocto but some are used by other build tasks). Note that this is the only script that should be run with the
sudo command:
wget https://raw.githubusercontent.com/reflexces/build-scripts/2023.07/yocto-packages.sh
chmod +x yocto-packages.sh
sudo ./yocto-packages.sh
3. Download and run the GSRD Build Script:
wget https://raw.githubusercontent.com/reflexces/build-scripts/2023.07/reflex-gsrd-build.sh
chmod +x reflex-gsrd-build.sh
./reflex-gsrd-build.sh
Then follow the on-screen instructions to continue.
The diagram below summarizes the Achilles GSRD Hardware and Software design flows. Each color-coded section corresponds to a tab (or button) at the top of this page where you will find instructions for each step in the process. The Yocto build process can perform multiple steps of the build process (U-Boot, Linux kernel, and root filesystem) to generate a single bootable image file for the Achilles eMMC boot flash.
Using Precompiled eMMC Image
It is strongly recommended that you first test the working eMMC image provided here in order to become familiar with the the required process of booting the SOM from network, updating the eMMC, and demonstrating the features highlighted in the next section below. You can then move onto modifying the GHRD or working with your own FPGA design, following the steps outlined here. To use the precompiled binaries to update your Achilles SOM, go to the
PROGRAM EMMC page and follow the instruction there to download and update the eMMC.
Requesting Support
To request support, registered users can visit the
REFLEX CES support page and submit a support ticket.
Hardware and Software Prerequisites (see GSRD release table above for latest supported versions):
Hardware
- Achilles Instant Development Kit, which includes a Turbo SOM (v2 PCB) and Starter carrier board
- Achilles Indus or Lite SOM and Starter carrier board
- Linux host build system (tested on Ubuntu 22.04; other distributions may work)
Software
- Quartus Prime Pro v22.1 or newer (required if modifying/compiling the GHRD or bringing your own Quartus design)
- SoC EDS v20.1 with Arm DS v2020.0 or newer (required for custom software development & debug)
Refer to the image below for the location of the connectors referenced in the list of features demonstrated.
Refer to the
PROGRAM EMMC page to update your Achilles SOM with the new eMMC image file. After programming is complete, the following features can be demonstrated:
- FPGA configuration from HPS - take note of the messages displayed during the boot process.
- From SPL/U-Boot (peripheral image only)
- From U-Boot proper (core image only)
- Application of devicetree overlay
- FPGA partial reconfiguration from Linux
During Linux boot, the
achilles-fpga-init systemd service applies an overlay to add the FPGA base static PR region to the live devicetree and enable the freeze_controller. After this PR region is applied, you can use the
pr_overlay.sh script provided in the
/home/root folder to apply 3 different available overlays to partially reconfigure the PR region setup in the GHRD. Use the -h or --help switch to view valid options:
root@achilles:~# ./pr_overlay.sh -h
Usage: ./pr_overlay [options]
Apply Achilles GHRD example PR region overlays
Options:
-d, --default Apply the blink_led_default.dtbo overlay.
The HPS red LED blinks every 0.67 sec.
-f, --fast Apply the blink_led_fast.dtbo overlay.
The HPS red LED blinks every 0.34 sec.
-s, --slow Apply the blink_led_slow.dtbo overlay.
The HPS red LED blinks every 1.34 sec.
-h, --help Display this help message and exit.
You can observe the change in the blinking rate of the LED by applying the fast or slow overlay. Applying the default overlay will return the LED blink rate to the default that is seen after the initial board power-up FPGA configuration completes.
root@achilles:~# ./pr_overlay.sh -f
[ 1853.379087] fpga_manager fpga0: writing blink_led_fast.pr_partition.rbf to SoCFPGA Arria10 FPGA Manager
-
- Dynamically update devicetree with new peripherals
An overlay is provided to add the GHRD Platform Designer System ID peripheral to the live devicetree. Apply this overlay and observe the value of the System ID:
root@achilles:~# mkdir /sys/kernel/config/device-tree/overlays/sysid-overlay
root@achilles:~# echo achilles_sysid.dtbo > /sys/kernel/config/device-tree/overlays/sysid-overlay/path
root@achilles:~# cat /sys/kernel/config/device-tree/overlays/sysid-overlay/status
applied
root@achilles:~# cat /sys/bus/platform/drivers/altera_sysid/ff200000.sysid/sysid/id
537006847
root@achilles:~# printf '0x%x\n' 536941311
0x200212ff
- Peripheral Test Scripts provided in /home/root folder
- eepromtest.sh - write & read the EEPROM device on Carrier board
- ledtest.sh - blink the user LEDs
- memtest.sh - extensive DDR4 memory test
- mount_fat.sh - mount the FAT partition of the eMMC for updating
- rtctest.sh - test & update the Real Time Clock
- tempsensortest.sh - read the board temperature
- usbtest.sh - test the USB OTG interface with a USB memory drive
- Web server - The Achilles SOM is running the lightpd open source webserver.
After powering on the Achilles Dev Kit, connect an Ethernet cable between the ETH1 or ETH2 RJ-45 connector and your network router. In your terminal program connected to the Achilles target, identify the IP address assigned to the board using the ifconfig command. Open a web browser on a PC connected to the same network and enter that IP address in the browser address bar. Using the Board Interface webpage served by the Achilles SOM, you can perform some simple interactions with the board.
- USB gadget support - after powering on the Achilles Dev Kit, connect a USB cable between the Achilles USB OTG port and a host PC.
- Achilles SOM is automatically detected and appears as a mass storage device
Open the start.htm webpage to view more information on connecting to and interacting with the Achilles SOM.
-
As shown on the start.htm page, you can connect to the same Board Interface webpage using "Ethernet over USB". After powering on the Achilles Dev Kit, connect a USB cable between the Achilles USB OTG port and a host PC. Open a browser on the host PC and connect to the board at address 192.168.10.1.
GHRD Overview
The hardware component, or “Golden Hardware Reference Design” (GHRD), is a complete Quartus reference design targeting the Arria® 10 FPGA. The design includes the Hard Processor Subsystem (HPS) and custom logic running in the FPGA logic fabric. The HPS is configured using the Platform Designer tool in Quartus. After the HPS subsystem is generated, its HDL output is integrated in a top level HDL file that can be modified to include the user’s custom logic. The GHRD is available on the
REFLEX CES achilles-hardware github repository page and is automatically downloaded by the build scripts or can be manually cloned (more details below). The achilles-hardware repository branches are named according to the Quartus Prime Pro version tested with that release.
Beginning with the ghrd-v22.1 branch, the GHRD is now generated from TCL scripts. If you want to use the Quartus GUI, you must first generate the design using the scripted flow. Use the GSRD build script (see instructions on the
START HERE page) to specify the SOM version and the type of GHRD to build (standard or Partial Reconfiguration reference design).
The latest recommanded branch is ghrd-v23.1 . All versions of the Achilles SOM (V2 & V5) are supported by this branch.
While this branch is fully tested with Quartus Prime Pro v23.1, the user has the option to specify a different Quartus version. Only the version specified by any given branch name will be eligible for technical support when working with that branch.
The script-generated Platform Designer .qsys design file enables the following HPS peripherals:
HPS Hard Peripherals
- SDMMC
- EMAC1 (RGMII with MDIO)
- EMAC2 (RGMII with MDIO)
- USB1
- I2C0
- UART0
- GPIO (2x in HPS Dedicated I/O block)
- EMIF HPS (DDR4)
FPGA Soft Peripherals
- JTAG to Avalon Master Bridge
- PIO
- System ID
- RS232 UART to communicate with MAX 10
The GHRD is based on the Full_Featured.zip design archive available in the latest Achilles board support package Test Design folder. Refer to the README.txt file or the release notes in the header of the top level VHDL file of the GHRD for details of changes made to the Full_Featured design. Below is a block diagram of the GHRD.
There are 2 variations of the GHRD: a standard flat version and a partial reconfiguration version. In both cases, one of the main functions demonstrated is using the HPS to configure the FPGA. This requires the Early I/O Release feature to be enabled in the Quartus project. This feature splits the FPGA configuration sequence into two parts. The first part is the periphery image, which configures the FPGA I/O, Shared I/O, and enables the HPS External Memory Interface (EMIF). The second part is the core image, which configures the FPGA fabric.
In the flat design, there is only the base revision in the Quartus project. After full compilation, this version is used to generate programming files (periph.rbf and core.rbf) for full configuration of the FPGA from U-Boot/SPL. FPGA configuration file updates can be sent to the Achilles SOM remotely, but the entire FPGA needs to be reconfigured by rebooting the system and allowing the SPL and U-Boot to configure the FPGA periphery and core images.
In the partial reconfiguration version, there is a base revision that defines the static region containing design logic that does not change, and the PR region containing logic that can be dynamically reconfigured. Additional revisions are used to define the function of each PR persona. In the GHRD, the PR region contains logic to blink the red LED connected to FPGA user I/O pins. The default configuration will cause the LED to blink once every 0.67 sec. Three additional revisions contain logic to make the LED blink fast, slow, or return to the default blinking rate. This version is used to generate programming files for the static region as well as partial reconfiguration files for each persona. This is a very simplified example used to demonstrate partial reconfiguration controlled by the HPS. Using a standard feature available in the most recent Linux kernels, we can apply a devicetree overlay from Linux to update the PR region with the desired persona configuration file.
So why are there two different versions of the reference design? Due to the architecture of Arria 10 SoC, it is not possible to reconfigure only the core FPGA image from the HPS after the periphery image has been loaded. Only full FPGA reconfiguration is possible, which will reset the FPGA and reconfigure FPGA/HPS shared I/O and DDR memory controllers, causing the HPS to crash. By using partial reconfiguration and the associated Linux drivers available, the HPS can reconfigure only the specified regions of the FPGA while the memory controllers and shared I/O continue to operate. If you only need the HPS to configure the FPGA at power up and can tolerate down time for future upgrades, then you can use a standard flat design without specifying PR regions. Otherwise, if you need to support FPGA configuration file updates through Linux without rebooting your system, then you will need to implement PR regions in your design. Refer to the documentation links provided on the
RESOURCES page for implementing the PR flow in your design.
The image below describes the new GHRD build flow starting with the ghrd-v22.1 branch:
- The primary TCL script is achilles_ghrd_build_flow.tcl and is launched with the quartus_sh -t command from the achilles-ghrd-build.sh script.
- The achilles_ghrd_build_flow.tcl script then sources create_achilles_ghrd_project.tcl.
- Process are run within create_achilles_ghrd_project.tcl to create the the Quaruts project and make project assignments for the user specified SOM and GHRD
- Another process generates the achilles_qsys_script_GENERATED.tcl.
- If the user chose the Partial Reconfiguration GHRD, the PR revisions are created.
- The generated script then creates the Platform Designer .qsys file, instantiates the HPS and peripheral IP, and sets their configuration parameters.
- After the Platform Designer .qsys file and IP files are created, the Platform Designer system is generated.
- When this completes, the full Quartus compilation flow begins.
- Finally, after compilation finishes, the resulting .sof file is converted to the split .periph.rbf and .core.rbf configuration files which are used by the HPS to configure the FPGA.
Suggested Quartus Hardware reference designs available for Achilles SOM:
Directory structure of the GHRD (ghrd-v21.3 and older)
achilles-hardware
├── devicetree (contains devicetree overlay source files and pre-compiled dtbo binaries used for configuring the PR region; explained in more detail on the *SOFTWARE* page)
├── hps_isw_handoff (contains the software handoff files generated during compilation)
├── output_files (contains the programming files generated during compilation; fetched during software build and included on eMMC image file)
└── src (main source file directory)
└── ip (contains Platform Designer source files)
Directory structure of the GHRD (ghrd-v22.1 and newer)
achilles-hardware
├── precompiled
| ├── hps_isw_handoff (contains precompiled software handoff files for each SOM version, generated during compilation)
| └── rbf (contains precompiled FPGA configuration files for each SOM version; fetched during software build and included on eMMC image file)
└── src
├── hdl (contains VHDL source files)
└── script (contains Platform Designing source script files
Compiling the GHRD (ghrd-v22.1 and newer)
For the best user experience, it is recommended to use the GSRD build script described on the
START HERE page.
Advanced users may choose to run the
achilles-ghrd-build.sh script separately by following these instructions.
1. Open a terminal console and create a working directory for the build:
mkdir achilles-ghrd-2023.07
cd achilles-ghrd-2023.07
2. Download and run the Achilles GHRD Build Script. Running the script without any arguments will display the usage instructions. The SOM version and GHRD type are the minimum required arguments for the script. The example below will build the Partial Reconfiguration GHRD for the v5 Indus SOM:
wget https://raw.githubusercontent.com/reflexces/build-scripts/2023.07/achilles-ghrd-build.sh
chmod +x achilles-ghrd-build.sh
./achilles-ghrd-build.sh -s v5-indus -g pr
Compiling the GHRD (ghrd-v21.3 and older)
Detailed instructions for compiling the GHRD are not provided here. It is assumed that the user has sufficient knowledge of FPGA design and the Quartus development tools GUI to open a project and start the compilation process. This can be done on either a Windows or Linux system using the Quartus GUI (command line build scripts are not provided). The software build described on the
SOFTWARE page
must be done on Linux. It will simplify the process to work completely in Linux if possible, since you will not need to transfer files from Windows to Linux when moving on to the Software build stage. To use the GHRD as a starting point for your own design or to recompile it, download the ZIP archive using the github link above, or using
git to clone the repository and checkout the desired branch:
git clone https://github.com/reflexces/achilles-hardware.git
cd achilles-hardware
git checkout ghrd-v21.3
#OR
git checkout ghrd-v21.3-pr
Open the Quartus project and start a full compilation. If using the Partial Reconfiguration GHRD, remember to run a full compilation for each design revision persona after compiling the base revision.
Refer to the Partial Reconfiguration documentation listed on the
RESOURCES page for more information on the Partial Reconfiguration design flow. After the Quartus project compilation successfully completes, you will find the required software handoff files in the
hps_isw_handoff folder and the FPGA programming files in the
output_files folder of the Quartus project directory. Pre-compiled FPGA configuration files (.sof/.rbf) are provided with the GHRD in the github repository and are fetched and included in the generated eMMC image during the software build stage. If the GHRD was modified, then you will need to convert the generated achilles_ghrd.sof (or your_project.sof) file to split .rbf files (peripheral and core images). Do this by opening a command line terminal on your host build machine (Windows or Linux), browse to your project
output_files directory, and run the following command:
quartus_cpf --convert --hps -o bitstream_compression=on achilles_ghrd.sof achilles_ghrd.rbf
Note: To run the quartus_cpf command, it may be necessary to specify the full path to your quartus/bin64 installation directory if not already set in your environment PATH variable (e.g. ~/intelFPGA_pro/20.1/quartus/bin64/quartus_cpf …).
Warning: The .periph.rbf and .core.rbf configuration files must come from the same Quartus project and version. Attempting to mix configuration files from different projects or compilations will result in FPGA configuration failure.
The above step is the same for both the flat and PR versions of the GHRD. In the PR version, run this above command using the base revision .sof file (achilles_ghrd.sof) to generate the split .rbf files. For each of the PR region persona revisions, there is a setting enabled in each of the corresponding .qsf files that generates the PR region .rbf files during compilation:
set_global_assignment -name GENERATE_PR_RBF_FILE ON
Without this .qsf setting, you would have to run a similar
quartus_cpf command to convert the partial-mask file for the PR region for each persona revision in your design, for example:
quartus_cpf --convert blink_led_fast.pr_partition.pmsf blink_led_fast.pr_partition.rbf
These PR region .rbf files must be copied to the Achilles Linux root filesystem (
/lib/firmware is default) and are then referenced in a devicetree overlay file and applied to the base devicetree that is loaded with the Linux kernel during the boot process. The devicetree overlay process is described in more detail on the
SOFTWARE page. The .rbf and devicetree overlay files are automatically copied to the generated root filesystem based on instructions in the
achilles-firmware.bb recipe during the scripted build flow on the
SOFTWARE page. If using your own .rbf files generated from your project, you must ensure that they are copied correctly to the root filesystem if not using the scripted flow.
There is one additional step we need to manually perform to convert the periph.rbf and core.rbf files to the FIT image format used by U-Boot. This is explained on the
SOFTWARE page under the
Option 2: Generate FIT Images section.
Preparing for Software Handoff
If working in Windows to compile the FPGA design and transitioning to Linux at this time, open a terminal and create a top level working directory on your Linux host build system:
mkdir -p ~/achilles && cd ~/achilles
Make a copy of the
hps_isw_handoff folder to this working directory. If you are already working in Linux at this time, you can work with the existing directory on your Linux PC. You should have the following files in the
hps_isw_handoff folder:
achilles
└── hps_isw_handoff
├── emif.xml
├── hps.xml
└── id
Now you are ready to move on to building the
SOFTWARE components.
Software Build Instructions
All software compilation in this section must be done on a Linux host system.
Three options are presented here for generating the software components used to update the eMMC boot flash:
- A script-driven Yocto build which will generate all required software components in a WIC image file that can be copied to the eMMC flash on the Achilles SOM.
- Build individual software components and create your own eMMC image file.
- Use the provided WIC image to update the eMMC, and then build the individual software components and only update the partitions as needed for your application.
Option 1: Yocto Build
For an overview of the Yocto Project, visit the
Yocto Project Getting Started webpage.
For the best user experience, it is recommended to use the GSRD build script described on the
START HERE page.
Advanced users may choose to run the
reflex-yocto-build script separately by following these instructions.
The Yocto build is done by simply running 2 scripts:
- yocto-packages.sh - detects your host build system Linux distribution and installs a set of essential packages required by Yocto
- reflex-yocto-build - script used to build individual components or a complete image for the Achilles SOM (use --help to see available build options).
One advantage to the Yocto build is that at the end of the build process, you have a complete image ready to copy to the Achilles eMMC. A disadvantage is that the intial build time can be long (over an hour depending on your host build system). Subsequent builds complete much faster, as only required tasks will run (e.g. no need to fetch source code again). Also, customizing the Yocto BSP layer to your application requirements has a steep learning curve if you are not familiar with the Yocto/OpenEmbedded build system.
1. If not already done in the
HARDWARE section, open a system terminal console and create a working directory:
mkdir -p ~/achilles && cd ~/achilles
2. Install packages required for the Yocto build:
wget https://raw.githubusercontent.com/reflexces/build-scripts/2023.07/yocto-packages.sh
chmod +x yocto-packages.sh
sudo ./yocto-packages.sh
3. Download the Yocto Build Script:
wget https://raw.githubusercontent.com/reflexces/build-scripts/2023.07/reflex-yocto-build
chmod +x reflex-yocto-build
4. Choose one of the script build options below.
To see all available boards and build options:
./reflex-yocto-build --help
To build the default console image for the Achilles module (this option generates the WIC image file):
./reflex-yocto-build --board achilles-v5-indus --image console
To build U-Boot only:
./reflex-yocto-build --board achilles-v5-indus --image virtual/bootloader
To build the Linux kernel only:
./reflex-yocto-build --board achilles-v5-indus --image virtual/kernel
After the build completes successfully, all of the generated output files can be found in the directory
achilles-build-files/tmp/deploy/images/achilles-v5-indus. The main file of interest,
achilles-console-image-achilles-v5-indus.wic, is copied to copied to the directory
achilles-emmc-image. This file can be used to program the entire eMMC. Go to the
PROGRAM EMMC page to view the table detailing the full list of files generated and for instructions to program the eMMC flash.
For Achilles Yocto builds using the
meta-achilles layer, starting with the
kirkstone branch and newer, the FPGA FIT images and optional devicetree overlays (used by the Partial Reconfiguration GHRD example) are now automatically generated during the Yocto build process.
For Yocto builds using the
meta-achilles layer
honister branch or older, these items are
not automatically generated. Instead, they are fetched from the
achilles-hardware github repository and added to the WIC image during the Yocto build process. If bringing your own Quartus hardware design, the FIT images will need to be manually generated and copied to the eMMC partition 1 (FAT partition). FIT image generation is explained below under
Option 2: Generate FIT Images.
Achilles Yocto BSP Layer Description
The tree below describes the directory structure found in the
meta-achilles Yocto BSP layer and the function of each recipe. If you want to further examine
meta-achilles or any other layer used in the Yocto build process, you can find them in the generated build directory within the
layers sub-directory.
meta-achilles
├── conf (contains Achilles machine configuration file that defines HW configuration options, including U-Boot and kernel versions to build, instructions for files to include on the FAT partition of the WIC image, and other options)
├── recipes-achilles (recipes specific to Achilles !SOM to demonstrate various features)
│ ├── achilles-firmware (recipe to add FPGA configuration files to image)
│ ├── achilles-fpga-init (recipe to create a systemd service to apply devicetree overlay)
│ └── achilles-usb-gadget (recipe to create a systemd service to enable USB Gadget support)
├── recipes-bsp (recipe to patch and build U-Boot)
├── recipes-core (recipes for misc. system configuration)
├── recipes-images (recipes for complete images for Achilles SOM)
├── recipes-kernel (recipes to patch, configure, and build Linux kernel)
└── wic (contains WIC kick start file to configure the generated WIC image)
Option 2: Build U-Boot and Linux Kernel Individually
One advantage to building components individually is that the build time can be faster. A disadvantage is that you need to manually create the image for programming the eMMC device, or update partitions separately. You also still need a root filesystem, which can be built with other tools like Buildroot, or using "ready-made" root filesystem archives (e.g. Linaro).
Download the
Arm GNU Toolchain to build the individual software components:
mkdir -p ~/armgcc && cd ~/armgcc
wget https://developer.arm.com/-/media/Files/downloads/gnu-a/10.2-2020.11/binrel/gcc-arm-10.2-2020.11-x86_64-arm-none-linux-gnueabihf.tar.xz
tar xf gcc-arm-10.2-2020.11-x86_64-arm-none-linux-gnueabihf.tar.xz
Build U-Boot
1. If not already done previously, create a working directory:
mkdir -p ~/achilles && cd ~/achilles
1. Setup the Arm tools build environment:
export ARCH=arm
export CROSS_COMPILE=~/armgcc/gcc-arm-10.2-2020.11-x86_64-arm-none-linux-gnueabihf/bin/arm-none-linux-gnueabihf-
3. Clone the
u-boot-socfpga source repository. Create and switch to a new branch (achilles) for our build. We are checking out a specific revision within the socfpga_v2021.01 branch:
git clone https://github.com/altera-opensource/u-boot-socfpga
cd u-boot-socfpga
git checkout -b achilles 24e26ba4a0d8fe816e32e760537a3f356823ba7b
4. Download and apply the Achilles U-Boot patch:
# For Achilles v2 only
wget https://raw.githubusercontent.com/reflexces/meta-achilles/kirkstone-2023.07/recipes-bsp/u-boot/files/v2021.07/0001-Add-Achilles-V2-support-for-u-boot-socfpga.patch
git apply 0001-Add-Achilles-V2-support-for-u-boot-socfpga.patch
#For Achilles v5 only
wget https://raw.githubusercontent.com/reflexces/meta-achilles/kirkstone-2023.07/recipes-bsp/u-boot/files/v2021.07/0001-Add-Achilles-V5-support-for-u-boot-socfpga.patch
git apply 0001-Add-Achilles-V5-support-for-u-boot-socfpga.patch
4.1. If you are building U-Boot for Achilles v2 Turbo or Achilles v5 you need to apply a second patch:
wget https://raw.githubusercontent.com/reflexces/meta-achilles/kirkstone-2023.07/recipes-bsp/u-boot/files/v2021.07/0002-remove-sdram-size-check.patch
git apply 0002-remove-sdram-size-check.patch
5. If you are bringing in your own FPGA design, run the Quartus handoff filter script to convert your hps.xml file to U-Boot header file to be used by the Achilles U-Boot devicetree.
NOTE: If you used the Achilles GHRD as a starting point for your design and did not make changes to the HPS, this step is not required.
./arch/arm/mach-socfpga/qts-filter-a10.sh <path/to/your/quartus/project>/hps_isw_handoff/hps.xml arch/arm/dts/socfpga_arria10_achilles_handoff.h
6. Configure and build U-Boot for your version of Achilles SOM:
make socfpga_arria10_achilles_v2_indus_defconfig
#OR
make socfpga_arria10_achilles_v2_lite_defconfig
#OR
make socfpga_arria10_achilles_v2_turbo_defconfig
#OR
make socfpga_arria10_achilles_v5_indus_defconfig
#OR
make socfpga_arria10_achilles_v5_lite_defconfig
make -j 64
Generate FIT Images
This step is required only if you are not using the scripted build flow.
Now we can generate the FIT images using the split .rbf FPGA programming files generated in the
HARDWARE section. These are used by the SPL and U-Boot to configure the FPGA. The Achilles U-Boot patch has configured the U-Boot source code to have the SPL load only the peripheral FPGA image, and then U-Boot loads the core image. This is significantly faster than having the SPL load both images.
NOTE: this process of generating FIT images is currently not run automatically during the Yocto build. Instead, pre-generated FIT files using the Achilles GHRD .rbf files are fetched and included in the generated WIC eMMC image. You must complete these steps if using your own custom FPGA design.
First create symbolic links to point to the location of the .rbf files generated in the
HARDWARE section. References below are to the Achilles GHRD .rbf files. Replace with your own file names if applicable, but do not rename the .its or .itb file references since these are defined in U-Boot source code. The .its files define the locataion and names of the .rbf files to be used when creating the .itb files.
ln -s <path/to/rbf/files>/achilles_ghrd.periph.rbf
ln -s <path/to/rbf/files>/achilles_ghrd.core.rbf
tools/mkimage -E -f board/reflexces/achilles-v5-indus/fit_spl_fpga_periph_only.its fit_spl_fpga_periph_only.itb
tools/mkimage -E -f board/reflexces/achilles-v5-indus/fit_spl_fpga.its fit_spl_fpga.itb
Now we have the following files that can be copied to the eMMC:
| File |
Description |
eMMC Partition |
| spl/u-boot-splx4.sfp |
Multiple SPL binaries with devicetree and header info |
Partition 2 (A2 raw) |
| u-boot.img |
U-Boot binary image |
Partition 1 (VFAT) |
| achilles_ghrd.core.rbf |
core.rbf image for FPGA core image configuration |
| fit_spl_fpga_periph_only.itb |
FIT image for FPGA peripheral image configuration only |
| fit_spl_fpga.itb |
FIT image for FPGA core image configuration |
If you compiled your own FPGA design or made modifications to the GHRD, you must manually copy the generated files listed above to the appropriate eMMC partition. Refer to the instructions on the
PROGRAM EMMC page.
Note: Either the .rbf or .itb file can be used for FPGA core image configuration in U-Boot. The .itb file is used by default U-Boot environment commands. Both files are included for completeness of the example.
To load the .rbf file from U-Boot, enter the command at the U-Boot prompt:
load mmc 0:1 ${loadaddr} achilles_ghrd.core.rbf
fpga load 0 ${loadaddr} 0xE20000
Build Linux Kernel
1. If not already done previously, create a working directory:
$ mkdir -p ~/achilles && cd ~/achilles
2. Clone the
linux-socfpga kernel source repository. Create and switch to a new branch (achilles) for our build, specifying the branch corresponding to the kernel version you want to build:
git clone https://github.com/altera-opensource/linux-socfpga
cd linux-socfpga
git checkout -b achilles -t origin/socfpga-5.10.100-lts
3. Download and apply the Achilles Linux devicetree patch:
wget https://raw.githubusercontent.com/reflexces/meta-achilles/kirkstone-2023.07/recipes-kernel/linux/config/socfpga-5.10-lts/patches/0001-add-achilles-devicetree.patch
git apply 0001-add-achilles-devicetree.patch
4. If working in a different terminal session from the one used previously to build U-Boot, you will need to setup the Arm tools build environment again:
export ARCH=arm
export CROSS_COMPILE=~/armgcc/gcc-arm-10.2-2020.11-x86_64-arm-none-linux-gnueabihf/bin/arm-none-linux-gnueabihf-
Configure and build the Linux kernel:
make mrproper
make socfpga_defconfig
5. If you want to include support for USB Gadget (as done in the Yocto build), then add that kernel configuration fragment. You can add any additional kernel configuration options as required for your application at this time.
wget https://raw.githubusercontent.com/reflexces/meta-achilles/kirkstone-2023.07/recipes-kernel/linux/config/socfpga-5.10-lts/cfg/usb-gadget.cfg
./scripts/kconfig/merge_config.sh .config usb-gadget.cfg
6. Build the kernel image, Achilles devicetree, and kernel modules.
make -j 64 zImage socfpga_arria10_achilles_v5_indus.dtb modules
7. Install the kernel modules:
make modules_install INSTALL_MOD_PATH=modules_install
rm -rf modules_install/lib/modules/*/build
rm -rf modules_install/lib/modules/*/source
mkdir -p linux-bin/a9
ln -s arch/arm/boot/zImage linux-bin/a9/
ln -s arch/arm/boot/dts/socfpga_arria10_achilles_v5_indus.dtb linux-bin/a9/
ln -s modules_install/lib/modules linux-bin/a9/
8. Archive the modules for transfer to the eMMC.
kernel_mod_dir=$(ls modules_install/lib/modules/)
tar -czvf modules_install/lib/modules/modules.tar.gz modules_install/lib/modules/$kernel_mod_dir
Now we have the following files that will be copied to the eMMC:
| File Name |
Description |
eMMC Partition |
| arch/arm/boot/zImage |
Compressed kernel image |
Partition 1 (VFAT) |
| arch/arm/boot/dts/socfpga_arria10_achilles_v5_indus.dtb |
Achilles Linux devicetree |
Partition 1 (VFAT) |
| modules_install/lib/modules/modules.tar.gz |
Kernel modules archive |
Partition 3 (EXT4) /lib/modules |
Devicetree Overlays
A devicetree overlay is used to dynamically add additional device nodes to the "live" devicetree currently loaded by the kernel. An overlay can add peripherals that are implemented in FPGA logic (e.g. UART, soft Ethernet MAC, PIO, etc.) or external peripherals that connect to the hard interfaces in the HPS (e.g. I2C or SPI devices, USB, or Ethernet). External peripherals would typically connect through the FMC connector to the baseboard that the Achilles SOM is plugged into, or through an FMC daughterboard plugged into the Achilles top FMC connectors. Overlays can also be used to configure or reconfigure the FPGA. Alternatively, any custom peripheral (in the FPGA or external) could be added to the base devicetree source file provided here in the GSRD, but reconfiguring PR regions through Linux can only be done with the use of an overlay. Note that there are kernel configuration elements that are required to support this and they are included in the standard default
defconfig file used to build the kernel for Arria 10 SoC devices. More information is available in the kernel Documentation folder.
Creating and Compiling an Overlay
For Achilles Yocto builds using the
meta-achilles layer, starting with the
kirkstone branch and newer, the optional devicetree overlays (used by the Partial Reconfiguration GHRD example) are now automatically generated during the Yocto build process.
For Yocto builds using the
meta-achilles layer
honister branch or older, you will still need to manually compile your devicetree overlays. Pre-compiled binaries (.dtbo files) specific to the GHRD PR example are fetched and added to the generated eMMC image during the Yocto build. To compile your own overlays, you will need to follow the steps above for
Build Linux Kernel under Option 2 to clone the
socfpga-linux repository and compile the .dtso files. Several example devicetree source overlay (.dtso) files are included in the
devicetree directory of the GHRD to demonstrate adding peripherals to the base devicetree, as well as configuring the partial reconfiguration region defined in the GHRD. If you want to recompile the source files, or need to modify them to fit your application, follow these steps:
Clone the
linux-socfpga kernel source repository as instructed above.
Copy the .dtso files to the kernel source tree folder containing all of the mainlined devicetrees (
arch/arm/boot/dts).
Compile the .dtso files using either of these 2 method:
Then build the devicetree overlays:
make -j 64 achilles_ghrd_base.dtb achilles_sysid.dtb blink_led_default.dtb blink_led_fast.dtb blink_led_slow.dtb
Note that the make utility expects to see the .dts filename extension for devicetree input source files and will generate .dtb output files. If you plan to use the test script provided in the meta-achilles layer to apply the overlays, you will need to manually rename the input .dtso to .dts, and the output .dtb to .dtbo. There is no requirement in Linux to use these extensions; however, these are the extensions used in the GHRD example to differentiate them as devicetree overlays.
Copy the generated .dtbo files to the Achilles root filesystem
/lib/firmware directory. This is the default directory used by
configfs, but other directories can be specified if desired. Refer to the
PROGRAM EMMC page for instructions on copying files to the various eMMC parititions. In this case, you will be copying to partition 3 (the Linux EXT4 partition).
Applying an Overlay
An devicetree overlay is applied using the Linux
configfs.
Create a
configfs config_item and apply the overlay:
mkdir /sys/kernel/config/device-tree/overlays/my-overlay-dir-name
echo my-overlay-file.dtbo > /sys/kernel/config/device-tree/overlays/my-overlay-dir-name/path
where
my-overlay-dir-name can be any arbitrary descriptive name, typically similar to the .dtbo file name.
You can check the status of the overlay:
cat /sys/kernel/config/device-tree/overlays/my-overlay-dir-name/status
applied
A script is provided as part of the GSRD and can be used to apply the various PR region overlays to change the LED blink rate, as demonstrated on the
START HERE page. The script is located on the Achilles root filesystem at
/home/root/pr_overlay.sh.
Program eMMC
The scripted Yocto build process will generate a WIC image file with the partition layout as shown in the image below.
A script is available to make the eMMC programming process easier. The script can be run as part of the full GSRD build process by running the GSRD build script (see the
START HERE page), or it can run independently. This script can run in Linux or Windows (using Nios II Command Shell or WSL shell). To manually download and run the script:
wget https://raw.githubusercontent.com/reflexces/build-scripts/2023.07/program-emmc.sh
chmod +x program-emmc.sh
./program-emmc.sh
The table below summarizes the files included in the WIC image and how each file is generated. The latest released version of each of these files can be downloaded from the
meta-achilles github release page
| File Name |
Description |
Partition |
Source of File |
| achilles-console...rootfs.tar.gz |
Poky root filesystem |
Partition 3 (EXT4) |
Yocto build |
| u-boot-splx4.sfp |
SPL image with devicetree |
Partition 2 (A2) |
Yocto build or U-Boot make |
| socfpga_arria10_achilles.dtb |
Devicetree binary |
Partition 1 (FAT) |
Yocto build or dtbs make |
| achilles_ghrd.core.rbf |
FPGA core configuration file |
quartus_cpf after Quartus GHRD build |
| fit_spl_fpga_periph_only.itb |
FPGA periphery FIT image |
U-Boot mkimage |
| fit_spl_fpga.itb |
FPGA core FIT image |
U-Boot mkimage |
| zImage |
compressed Linux kernel image |
Yocto build or kernel make |
| u-boot.img |
U-Boot binary image |
Yocto build or U-Boot make |
| extlinux/extlinux.conf |
boot configuration file |
Yocto build (achilles.conf) |
The precompiled WIC image can be downloaded from here, or they can be downloaded automatically by using the programming script:
Older releases for Turbo SOM
Older releases for V2 SOM versions
Latest releases for all SOM versions
Prerequisites for Programming eMMC
Note: when using the eMMC Programming script, you must still setup a TFTP server and complete Steps 1 - 3 below. The remaining steps are done automatically by the programming script.
In order to write a full eMMC image or update any partition of the eMMC, it is necessary to setup a TFTP server and boot the Achilles SOM from the network instead of booting from the eMMC. This is necessary in most cases (especially for full WIC image programming) because we don't want to modify a live mounted eMMC that we just booted from. Booting an initramfs from TFTP leaves the eMMC unmounted and safe to modify. REFLEX CES provides the example design
RefDesign_HPS_boot_from_FPGA in the Achilles board support package that faciltates this process. You can configure the Arria® 10 FPGA with the .sof image that contains U-Boot running from FPGA on-chip RAM, which then boots the initramfs image containing the Linux kernel and minimal root filesystem running from RAM. Once fully booted, you can then use standard Linux commands to program the eMMC. It is not necessary to recompile this reference design in Quartus. Downloading and configuring the FPGA with this design is done automatically by the programming script.
The zImage Linux kernel with embedded initramfs can be downloaded from the links in the table or by using the command line examples below:
| SOM Version |
File Name |
Description |
md5sum |
| V2 Turbo |
linuxDT.dtb |
Linux devicetree binary |
4b7301146c1f148006440f7f63c2399b |
| zImage |
Linux kernel image with initramfs |
957e27a44e286975ad674f9545106fc8 |
| V2 Indus |
linuxDT.dtb |
Linux devicetree binary |
93d9b250c05ec63930ee4f2f2a967af2 |
| zImage |
Linux kernel image with initramfs |
1a43531bb37d4d421d5016c5e1c52879 |
| V2 Lite |
linuxDT.dtb |
Linux devicetree binary |
ea379d51668c5a5574a5a8603dbac9b6 |
| zImage |
Linux kernel image with initramfs |
5b3e731a57cbeca4340f149f7a3e7ca4 |
| V5 Indus |
linuxDT.dtb |
Linux devicetree binary |
d9ad385183620563336a89ae94a7a4e0 |
| zImage |
Linux kernel image with initramfs |
9bef9b5987012f0562103117792052f2 |
| V5 Lite |
linuxDT.dtb |
Linux devicetree binary |
865f7c055a575bc8422f2c24ad0cbe50 |
| zImage |
Linux kernel image with initramfs |
efdf57b80dd2185cc520ba43eb3580b5 |
For V2 Turbo SOM:
wget https://raw.githubusercontent.com/reflexces/build-scripts/2023.07/prog-files/tftp-boot-files/SomA10-V2/Turbo/linuxDT.dtb
wget https://raw.githubusercontent.com/reflexces/build-scripts/2023.07/prog-files/tftp-boot-files/SomA10-V2/Turbo/zImage
For V2 Indus SOM:
wget https://raw.githubusercontent.com/reflexces/build-scripts/2023.07/prog-files/tftp-boot-files/SomA10-V2/Indus/linuxDT.dtb
wget https://raw.githubusercontent.com/reflexces/build-scripts/2023.07/prog-files/tftp-boot-files/SomA10-V2/Indus/zImage
For V2 Lite SOM:
wget https://raw.githubusercontent.com/reflexces/build-scripts/2023.07/prog-files/tftp-boot-files/SomA10-V2/Lite/linuxDT.dtb
wget https://raw.githubusercontent.com/reflexces/build-scripts/2023.07/prog-files/tftp-boot-files/SomA10-V2/Lite/zImage
For V5 Indus SOM:
wget https://raw.githubusercontent.com/reflexces/build-scripts/2023.07/prog-files/tftp-boot-files/SomA10-V5/Indus/linuxDT.dtb
wget https://raw.githubusercontent.com/reflexces/build-scripts/2023.07/prog-files/tftp-boot-files/SomA10-V5/Indus/zImage
For V5 Lite SOM:
wget https://raw.githubusercontent.com/reflexces/build-scripts/2023.07/prog-files/tftp-boot-files/SomA10-V5/Lite/linuxDT.dtb
wget https://raw.githubusercontent.com/reflexces/build-scripts/2023.07/prog-files/tftp-boot-files/SomA10-V5/Lite/zImage
Whether you already have a TFTP server setup, or you need to
configure one first, it is necessary to change or set some parameters to match the expected values specified in the U-Boot environment variables used in the “RefDesign_HPS_boot_from_FPGA” reference design. The default U-Boot environment values are summarized in the table below. Refer to the Achilles Reference Manual "HPS Development" chapter for addtional details.
| TFTP Server Parameter |
u-boot env variable setting |
| server IP address (v2): 192.168.1.200 |
serverip=192.168.1.200 |
| server path: SomA10-V2/Turbo/ |
tftppath=SomA10-V2/Turbo/ |
| server path: SomA10-V2/Indus/ |
tftppath=SomA10-V2/Indus/ |
| server path: SomA10-V2/Lite/ |
tftppath=SomA10-V2/Lite/ |
| server IP address (v5): 192.168.200.200 |
serverip=192.168.200.200 |
| server path: SomA10-V5/Indus/ |
tftppath=SomA10-V5/Indus/ |
| server path: SomA10-V5/Lite/ |
tftppath=SomA10-V5/Lite/ |
These files must be located in the TFTP server path specified in the
tftppath variable (see download information above):
| File Name |
u-boot env variable setting |
| linuxDT.dtb |
fdtfile=linuxDT.dtb |
| zImage |
bootimage=zImage |
With a network managed by a DHCP server, interrupt the boot process in U-Boot and modify some U-Boot environment variables with the commands:
setenv serverip <tftp-server-ip-addr>
setenv rxcethboot "setenv bootargs console=ttyS0,115200 ip=dhcp ; bootz ${loadaddr} - ${fdtaddr}"
setenv rxcethload "dhcp ; tftp ${loadaddr} ${tftppath}${bootimage} ; tftp ${fdtaddr} ${tftppath}${fdtimage} ;"
# Restart the boot process
run bootcmd
On a network without a DHCP server, interrupt the boot process in U-Boot and modify some U-Boot environment variables with the commands:
setenv ipaddr <board-ip-addr>
setenv serverip <tftp-server-ip-addr>
setenv rxcethboot "setenv bootargs console=ttyS0,115200 ip=none ; bootz ${loadaddr} - ${fdtaddr}"
setenv rxcethload "tftp ${loadaddr} ${tftppath}${bootimage} ; tftp ${fdtaddr} ${tftppath}${fdtimage} ;"
# Restart the boot process
run bootcmd
After changing the variables, you can make them permanent by using the
saveenv command before restarting the boot process by using the
run bootcmd comand.
Writing Full WIC Image to eMMC
Once the TFTP server is setup, you can perform a network boot and program the Achilles eMMC by following these steps. Some knowledge of connecting to the Achilles SOM usinng terminal emulator software (e.g.
PuTTY, Minicom, etc) and use of the Quartus Programmer is assumed for these steps. Refer to the Achilles Reference Manual if you need assistance.
Boot the initramfs Image
1. With the Achilles SOM and carrier board powered off, carefully remove the SOM from the carrier board and move the MSEL1 switch on the reverse side of the board to the ON position as shown in the image below. This will enable the FPP x32 configuration mode of the Arria® 10 FPGA, as required for the HPS to configure the FPGA.
2. Plug the SOM back into the carrier board. Plug in a microUSB cable between the host PC and the microUSB connector on the carrier board labeled “BLASTER”. Plug in an Ethernet cable between your network router and the RJ-45 Ethernet port labeled “ETH1”. Verify that the BSEL pins are set as shown in the image below (0x5) to enable boot from 3.0V SD/MMC flash.
3. Open your preferred terminal emulator software. Power on the board and establish a connection between the board and the terminal emulator. If using the Achilles SOM in factory condition, you should not see any output on the terminal at this time because the new MSEL switch position will prevent FPGA configuration in AS mode. If you have already programmed the eMMC with this example image and U-Boot loads the FPGA core.rbf file, you will need to interrupt the boot process at U-Boot to prevent core.rbf programming. Otherwise, the Quartus programmer will fail in the next step.
4. Open the Quartus Programmer tool and click the “Hardware Setup” button and establish a connection to the Achilles SOM (“Arria10 IDK”). Auto detect the JTAG chain and accept all detected device defaults. Click to select the Arria® 10 device in the list and click "Add File" to add a programming file. Browse to the location of the .sof file downloaded from the link above and select it. If a second Arria® 10 device appears in the list below the one with the file just added, then delete it. Check the “Program/Configure” box, and click "Start" to program the FPGA. Once programming completes, you should start to see output to the serial terminal.
Program the eMMC (through USB key)
5.a. Copy the Yocto generated WIC image on a USB key and plug the USB key in the USB OTG port of the Carrier Board.
NOTE: The USB adapter must be On-The-Go compliant.
5.b. On Achilles SOM serial terminal emulator session, mount the USB key partition.
mkdir -p /mnt/key
mount -o ro /dev/sda1 /mnt/key
5.c. On Achilles SOM serial terminal emulator session, clone the image file to the eMMC. There is no need to mount the eMMC device first to clone the full image.
dd if=/mnt/key/achilles-console-image-achilles-v5-indus.wic of=/dev/mmcblk0 && sync
5.d. After the cloning process is complete, shut down the initramfs session on Achilles:
poweroff
5.e. Power cycle the Achilles board. Do not just issue a
reboot command from the Linux command prompt; you must power cycle the board after the
dd process completes. You should now observe the boot process in your terminal emulator. First, the FPGA periphery image is loaded by the SPL. The SPL then loads the u-boot.img file from the FAT partition and U-Boot starts. The FPGA core image is then programmed by U-Boot and then the Linux kernel, devicetree, and root filesystem are loaded. You should finally arrive at the Poky linux prompt.
Program the eMMC (through Ethernet)
6.a. If the board is connected on a network with a DHCP server, just get the IP address affected to the board, otherwise set a static IP address to the board.
Get Ethernet IP addresses on Achilles SOM via serial terminal emulator:
ip address show up
If needed, set Eth0 static IP address on Achilles SOM via serial terminal emulator:
ip link set eth0 up
ip address add 192.168.200.42/24 dev eth0
6.b. To copy the Yocto generated WIC image to the Achilles eMMC, open a terminal window on your Linux host and browse to the directory containing the WIC image.
6.c. Copy the WIC image to the initramfs session running on the Achilles SOM:
scp achilles-console-image-achilles-v5-indus.wic root@<board-ip-addr>:/
Be sure to enter the correct IP address for the Achilles board that you noted in step 6.a above.
Type
yes to accept the connection and then enter the Achilles initramfs password
root.
The file will take about 2 minutes to transfer.
6.d. After the transfer is complete, go back to the Achilles serial terminal emulator session and clone the image file to the eMMC. There is no need to mount the eMMC device first to clone the full image.
dd if=achilles-console-image-achilles-v5-indus.wic of=/dev/mmcblk0 && sync
6.e. Continue at the step 5.d in the previous chapter.
Updating Individual eMMC Partitions
If you want to update individual files on any of the partitions, follow the steps above to load the initramfs image over your network. Then copy the files you want to update to the corresponding Achilles eMMC partition. Note that you can update individual eMMC partitions on the REFLEX CES factory default eMMC layout with the binary files provided here, but you will need to update several U-Boot environment variables to point to the correct FAT partition.
Mount the partition you want to update:
Partition 1 (FAT)
On Achilles SOM via serial terminal emulator:
mkdir -p /media/emmcp1; mount -t vfat /dev/mmcblk0p1 /media/emmcp1; cd /media/emmcp1
On Linux host, copy files to the mounted partition:
scp <filename> root@<board-ip-addr>:/media/emmcp1
Partition 2 (A2)
It is not necessary to mount the raw A2 partition to update it with a new U-Boot/SPL image:
On Linux host, copy files to root (/) on the initramfs session:
scp <u-boot-spl-image-name> root@<board-ip-addr>:/
On Achilles SOM via serial terminal emulator:
dd if=<u-boot-spl-image-name> of=/dev/mmcblk0p2 && sync
Partition 3 (EXT4)
NOTE: This step is only required if you booted from the initramfs and the eMMC is not mounted. If booting to Poky Linux from eMMC, it is not necessary to mount this partition since it is already mounted.
On Achilles SOM via serial terminal emulator:
mkdir -p /media/emmcp3; mount -t ext4 /dev/mmcblk0p3 /media/emmcp3; cd /media/emmcp3
On Linux host, copy files to the mounted partition:
scp <rootfs_archive.tar.xz> root@<board-ip-addr>:/media/emmcp3
or
scp <new_fpga_prog_file.rbf> root@<board-ip-addr>:/lib/firmware
When file copying is complete, shut down the initramfs session on Achilles:
poweroff
Power cycle the Achilles board
Creating Your Own eMMC Image
If you built the individual hardware and software system components and want to create your own eMMC image, you can follow the example available on the
Building Bootloader article page. Scroll down to section
C. Build SD Card Image. Then follow the steps above to clone the image to the Achilles eMMC.
Additional Resources & References
Intel® PSG Arria® 10 Documentation
Intel® PSG Partial Reconfiguration Documentation
Related Rocketboards Articles
RocketBoards
ARIES Embedded - MCV System on Module
Terasic Agilex 7 FPGA Starter Kit
GSRD for Agilex 7 I-Series Transceiver-SoC DevKit (4x F-Tile)
Golden System Reference Design for DK SI AGI027FB and DK SI AGI027FA
Building Bootloader for Cyclone V and Arria 10
Information abut latest bootloaders for Cortex A9 based SoC FPGA devices
Arria 10 SoC GSRD
Arria 10 SoC Golden System Reference Design
Building Bootloader for Stratix10
Building latest bootloaders for Stratix 10 SoC Devices
The Achilles SOM by REFLEX CES features an Intel® PSG Arria® 10 SX SoC FPGA. With an ARM dual-core Cortex-A9 MPCore and up to 660 KLEs of advanced low-power FPGA logic elements, the Arria® 10 SoC combines the flexibility and ease of programming of a CPU with the configurability and parallel processing power of an FPGA. The SOM is available to purchase as part of a development kit for evaluation and prototyping, or as a production-ready module designed into your electronic assembly. The SOM also features industry standard FMC connectors to allow for easy integration of additional connectivity, video interfaces, data converters, and many other options available through FMC daughter cards.
Achilles offers developers an excellent out-of-box experience. With our intuitive software GUI environment, users can power-up the board and demonstrate functionality of the major interfaces in just a few minutes. The board support package includes full documentation and a suite of reference designs to quickly enable the FPGA development process.
Ideal target markets include Automotive, Video Broadcast, Machine and Intelligent Vision, Industrial, Military, Test & Measurement, and Medical.
There are 6 versions of the SOM available:
Refer to the PROGRAM EMMC page to update your Achilles SOM with the new eMMC image file. After programming is complete, the following features can be demonstrated: 
There are 2 variations of the GHRD: a standard flat version and a partial reconfiguration version. In both cases, one of the main functions demonstrated is using the HPS to configure the FPGA. This requires the Early I/O Release feature to be enabled in the Quartus project. This feature splits the FPGA configuration sequence into two parts. The first part is the periphery image, which configures the FPGA I/O, Shared I/O, and enables the HPS External Memory Interface (EMIF). The second part is the core image, which configures the FPGA fabric.
In the flat design, there is only the base revision in the Quartus project. After full compilation, this version is used to generate programming files (periph.rbf and core.rbf) for full configuration of the FPGA from U-Boot/SPL. FPGA configuration file updates can be sent to the Achilles SOM remotely, but the entire FPGA needs to be reconfigured by rebooting the system and allowing the SPL and U-Boot to configure the FPGA periphery and core images.
In the partial reconfiguration version, there is a base revision that defines the static region containing design logic that does not change, and the PR region containing logic that can be dynamically reconfigured. Additional revisions are used to define the function of each PR persona. In the GHRD, the PR region contains logic to blink the red LED connected to FPGA user I/O pins. The default configuration will cause the LED to blink once every 0.67 sec. Three additional revisions contain logic to make the LED blink fast, slow, or return to the default blinking rate. This version is used to generate programming files for the static region as well as partial reconfiguration files for each persona. This is a very simplified example used to demonstrate partial reconfiguration controlled by the HPS. Using a standard feature available in the most recent Linux kernels, we can apply a devicetree overlay from Linux to update the PR region with the desired persona configuration file.
So why are there two different versions of the reference design? Due to the architecture of Arria 10 SoC, it is not possible to reconfigure only the core FPGA image from the HPS after the periphery image has been loaded. Only full FPGA reconfiguration is possible, which will reset the FPGA and reconfigure FPGA/HPS shared I/O and DDR memory controllers, causing the HPS to crash. By using partial reconfiguration and the associated Linux drivers available, the HPS can reconfigure only the specified regions of the FPGA while the memory controllers and shared I/O continue to operate. If you only need the HPS to configure the FPGA at power up and can tolerate down time for future upgrades, then you can use a standard flat design without specifying PR regions. Otherwise, if you need to support FPGA configuration file updates through Linux without rebooting your system, then you will need to implement PR regions in your design. Refer to the documentation links provided on the RESOURCES page for implementing the PR flow in your design.
The image below describes the new GHRD build flow starting with the ghrd-v22.1 branch:
Suggested Quartus Hardware reference designs available for Achilles SOM:
Refer to the Partial Reconfiguration documentation listed on the RESOURCES page for more information on the Partial Reconfiguration design flow. After the Quartus project compilation successfully completes, you will find the required software handoff files in the hps_isw_handoff folder and the FPGA programming files in the output_files folder of the Quartus project directory. Pre-compiled FPGA configuration files (.sof/.rbf) are provided with the GHRD in the github repository and are fetched and included in the generated eMMC image during the software build stage. If the GHRD was modified, then you will need to convert the generated achilles_ghrd.sof (or your_project.sof) file to split .rbf files (peripheral and core images). Do this by opening a command line terminal on your host build machine (Windows or Linux), browse to your project output_files directory, and run the following command:
A script is available to make the eMMC programming process easier. The script can be run as part of the full GSRD build process by running the GSRD build script (see the START HERE page), or it can run independently. This script can run in Linux or Windows (using Nios II Command Shell or WSL shell). To manually download and run the script:
2. Plug the SOM back into the carrier board. Plug in a microUSB cable between the host PC and the microUSB connector on the carrier board labeled “BLASTER”. Plug in an Ethernet cable between your network router and the RJ-45 Ethernet port labeled “ETH1”. Verify that the BSEL pins are set as shown in the image below (0x5) to enable boot from 3.0V SD/MMC flash.
3. Open your preferred terminal emulator software. Power on the board and establish a connection between the board and the terminal emulator. If using the Achilles SOM in factory condition, you should not see any output on the terminal at this time because the new MSEL switch position will prevent FPGA configuration in AS mode. If you have already programmed the eMMC with this example image and U-Boot loads the FPGA core.rbf file, you will need to interrupt the boot process at U-Boot to prevent core.rbf programming. Otherwise, the Quartus programmer will fail in the next step.
4. Open the Quartus Programmer tool and click the “Hardware Setup” button and establish a connection to the Achilles SOM (“Arria10 IDK”). Auto detect the JTAG chain and accept all detected device defaults. Click to select the Arria® 10 device in the list and click "Add File" to add a programming file. Browse to the location of the .sof file downloaded from the link above and select it. If a second Arria® 10 device appears in the list below the one with the file just added, then delete it. Check the “Program/Configure” box, and click "Start" to program the FPGA. Once programming completes, you should start to see output to the serial terminal.