Flat Design on A10 SoC Devkit using HPS - uboot from SDcard


I started my A10 work by carrying forward my earlier work using a Cyclone V. To do this I planned to migrate my code - a bit at a time - and get it working similarly on the A10 SoC Devkit board. That created a problem in getting a flat design project to start, so the info posted here is the solution I discovered. This is a rather long post so I hope I m not breaking protocol with this board with the long post. (It gets a bit wordy so read on if you are interested.)

This outline documents the steps I have used to get a flat design with an HPS loadable from an SDCard and running on the Arria 10 SoC Devkit Board starting with the projects in GHRD ver 16.1, with modification of one project setting.

I am running using Quartus Ver 17.0.2 using an Arria 10 SoC Devkit from Altera, and the rest of the tools provided by Altera with the DevKit Board (SOCEDS, and ARM DS-5 v5.26.0 with Eclipse IDE)

I was advised to use the GHRD version 16.1 (instead of the ver 17.0 GHRD) because it does not contain IP components that I was having trouble compiling in the ver17.0 GHRD since I do not have the added license for them. I had started trimming the project back but each time it adds the risk that I am adding errors to the project as I modify it if I did not make changes correctly.

There are two Quartus projects for Arria 10 in the GHRDv16.1
One is in an archive file named a10_soc_devkit_ghrd.tar.gz
The second is in an archive named a10_soc_devkit_pr.tar.gz This version is specifically using partial reconfiguration, which is what I do not want to do so I will not be following up with work on it. (I’ve tried before at peeling away the partial reconfiguration code but it does not get me any closer to my goal of loading a flat design with an HPS component.)

I am only working here with the first project (a10_soc_soc_devkit_ghrd).
The only change I made was to the ‘Early Release’ setting found by selecting the ‘Assignments’ menu, then selecting the ‘Device …’ item, then (in the dialog that follows) selecting the ‘Device and Pin Options…’ button. This presents a new dialog where you need to select the ‘General’ category, then scroll to the bottom of the Options list-box and turn off the checkbox titled ‘Enables the HPS early release of HPS IO’

This project loads in Quartusv17 without problem or requiring IP upgrade
It runs through QSYS ok (and converted to Quartus v17, you need to do this)
The project compiled Ok and produced a SOF file which I converted to an RBF (using the Convert Programming Files menu item). I named the file Flat_HPS.rbf
The QSYS and Compile generated the handoff files in /hps_isw_handoff subdirectory which will be used to create the uboot loader file
I run the bsp-editor tool from a SOCEDS shell window to create files to make a uboot boot file I can use to start my application from the SDCard when the board powers up.

I have copied the Flat_HPS.rbf file to partition 1 of the SDCard and the uboot_w_dtb-mkpimage.bin to my /home/root directory on the SDCard in Linux
I copy the uboot_w_dtm-mkpimage.bin file into partition3 of the SDCard starting at the beginning of the partition using the command
dd if=uboot_w_dtb-mkpimage.bin of=/dev/mmcblk0p3 bs=64k seek=0
Then I shut down Linux so I can reboot to start the application I just installed, and the result is successful as shown in the next page

This shows the step I was missing was to disable the ‘Early Release’ setting. Using ‘Early Release’ from the ‘Device and Pin Options…” dialog makes a requirement that you use a xxx.periph.rbf and a xxx.core.rbf file. It does not cause the periph and core files to be generated, it only makes them required to boot using uboot. Since I don’t plan to use partial reconfiguration I don’t see why I would want to use a .periph.rbf and .core.rbf
I believe Altera states that the two RBF file method produces a faster startup time, but I think they are referring to a startup after a reconfiguration, which again I do not plan to do.

If you do want to generate a xxx.periph.rbf and a xxx.core.rbf file to support the Early release option there doesn’t seem to be a way (in Quartus v17) to do that from the ‘Convert Programming Files” dialog, but you can create them using the command line command below;
quartus_cpf –c –hps -0 bitstream_compression=on output_files/ghrd_10as066n2.sof output_files/ghrd_10as066n2.rbf
This creates the following two files
ghrd_10as066n2.periph.rbf <-I/O ring configurstion file
ghrd_10as066n2.core.rbf <-FPGA fabric configuration file

I worked my GHRD design down to a (fairly) minimal size by deleting the parts I do not need so I would have a baseline to start adding my code testing. Along the way I discovered there are several elements that are not easily deleted because they have Linux – FPGA connections that need to be disconnected from the Linux side. These didn’t stop me so I just kept the unneeded code since it was small anyway.

If you attempt to load a single RBF design without disabling ‘Early Release” as shown before you end up failing the second stage of the uboot process, as shown in the case below.

In most of my discussion of loading a flat design there are a few terminology mismatches as I began investigating the problem with some wrong assumptions. The result is that I conflate the conflict with ‘flat design’ and ‘partial reconfiguration’ with the use of the .periph and .core programming files.

The .periph and .core files just separate the I/O definition and initialization from the main body of the FPGA code. This does not necessarily imply that the application you create would not be a flat or partial configuration design, it just separates the I/O and code portions. However if you want partial reconfiguration you need to use the .periph/.core files. And if you program using one RBF file you can only make a flat design (which as I see it is a design that uses the entire FPGA for one application – and of course is not reconfigurable). I could be mistaken in some of the details in this but it has allowed me to get this far so as long as it works it is Ok by me.

Also, there is an ‘Early Release’ setting in the configuration dialog of the EMIF for HPS IP component in QSYS Pro, but this does not seem to have any impact on making the .periph and .core files required by uboot. I do believe the two ‘Early Release’ selections (EMIF in QSYS_Pro and ‘Device and Pin Options…’ dialog) should agree with each other.

I hope this can help someone stuck in the same loop I was in a week ago.


I forgot to mention … Many thanks to JHaberly from this forum, and to the kind folks at System Level Solutions for listening to my problems and giving sage advice (which I didn’t always follow, but maybe just enough).


I’ve found that when you use the GHRD as a baseline and modify it away from the GHRD code you get some Linux interaction that is undesirable. If you are using the Angstrom Linux that was part of the default download for the A10 SoC DevKit you will find that there is a system service ‘udev’ that is polling and times out every 180 seconds if your hardware (via your FPGA design) doesn’t respond. Not a huge problem but it spews a dump onto your terminal window, which is bothersome. You can turn the timeout off by using the command below after you log on to Linux.

systemctl stop systemd-udev-trigger

This will stop the 180 second polling. You can check that the trigger service is off with the command below.

systemctl is-active systemd-udev-trigger

It should now say it is inactive. It will be back to its default state (active) after you power cycle the board. I did not find out what the udev service is polling for but turning the polling off does not seem to have impacted anything as far as I can see.