Unable to boot updated SDcard (A10 SoC Devkit)


I have had little success in getting a starting project up and running on an A10 SoC Devkit board. I am using the Angstrom Linux and the default SDcard image provided with the board.

  1. I made a simple HPS project in (Quartus 17.0), nothing fancy, just an HPS and some memory, and created an RBF file from my SOF file after compiling.
  2. I used SocEDS bsp-editor to create device tree and uboot files. (I used my /hps_isw-handoff files created by Qsys Pro and checked the "disable uboot build boot device’ checkbox, then generated my files.
  3. I ran ‘make’ in the /software/uboot_bsp directory creqted by bsp-editor and it created uboot_w_dtb-mpkpimage.bin and u-boot_w_dtb.bin
  4. I copied my project RBF file and uboot_w_dtb-mkpimag.bin files to my /home/root directory on my sdcard.
  5. I copied the RBF file to partition 1 of the sdcard


< sorry the entry above took off on me before I was ready>
5. I copied the RBF file to partition 1 of the sdcard with the usual mount - cp - umount commands and verified that the file was in partition 1 ( /dev/mmcblk0p1 )
6. I wrote the uboot and device tree file into the start of partition 3 using
dd if=uboot_w_dtb-mkpimage.bin of=/dev/mmcblk0p3 bs=64k seek=0
as instructed in Rockboards notes
When I shutdown Linux then do a cold reboot (power cycle) I get nothing. No response on my terminal (TeraTerm) connected and the red LED on the Devkit board. I assume my method of updating the uboot files is the problem but I believe I have followed the process outlined from various manuals and web content. I doubt my project file has any involvement since there is no indication that it ever got to load. If anyone can steer me in the right direction I would greatly appreciate it.


I meant to say the red LED on the Devkit board is ON when I attempt a cold start.


I have the A10 Dev kit running with a custom SD card partitioning and I’m using buildroot for the rootfs and Kernel compilation. I’d be happy to help you get this up and running. this should be rather easy if you stick to the procedcures and don’t get to creative from the start. I suggest getting a working framework in place then moving forward from there with your customizations (etc). Otherwise it’s hard to tell what’s not working. With that said…

Since your not seeing any of the u-boot messages on power-up I suggest first testing to see if it’s your boot-loader that’s not working.

Try putting the original boot-loader (uboot_w_dtb-mkpimage.bin) back in place using the “dd” command. You can copy it off of a stock card using “dd” as follows:

writing to a card

dd if=uboot_w_dtb-mkpimage.bin of=/dev/mmcblk0p3 bs=64k seek=0

reading from a card

dd if=/dev/mmcblk0p3 of=uboot_w_dtb-mkpimage.bin bs=64k seek=0 count=16

If replacing your version with the stock version gets things going then you know where to start.
In order to generate a good (working) boot-loader you must have all the settings correct in your QSYS project. The boot-loader configures the entire HPS system. Things like DDR timing and pin assignments (etc) must be correct. Did you start with a GSRD Quartus project for this board or start from scratch? Starting from scratch will be very problematic if you’re new to any of this.

Here’s the link to one of the GSRD’s for the board:

Let me know how it goes.




You’ve probably already seen these so FYI -

I’ve been working with SoCEDs 16.1 running on CentOS 6 with no issues.

A10 GSRD 16.1 - what I started with to get DDR timing and other board specific settings, etc

A10 GSRD 17.0

A10 GSRD 17.1


Thanks for your reply. I have been working this for a while and tried several approaches (most likely replacing my errors with different errors and not making progress). I have tried working from the gsrd backwards, and tried working forwards with my own program (several different small test versions).

I tried your suggestion of dropping my .rbf file into a gsrd configuration. I had tried this before and did not find sucess in completing a boot and it is the same today. The .rbf file will load but that is as far as it goes. I wouldnt expect much more than that from a mixed “uboot & .RBF file” configuration. I have been able to get past (at least a little farther) the uboot lock up I was seeing earlier.

On my ‘smallest posible footprint’ version it was so pared down that there was no emif interface on the HPS so Qsys did not produce an emif.xml file. Since bsp-editor will not run without an emif.xml and a hps.xml that was a step too far back. I did try dropping in an emif.xml form the gsrd to see if the uboot produced by bsp-editor would go a little farther, and it id - my .rbf file would load and give me the ‘Full Configuration Completed’ message but it would hang after that (I suppose hanging on the SDRAM calibration and check of the emif that was not present in my Qsys).

I started working backwards from a copy of gsrd, paring off parts that I dont need or want (and particularly the parts that I cant compile since I dont have all of the IP library). In this I dropped much of the design to eliminate the partial reconfiguration, the display port, buttons, switches, leds, trace monitors, etc. This did compile and allowed a uboot to be created (via the usual process) and boots a little farther. In this the boot loads my test .rbf file acnowledges the emif interrupt a few trimes then fails the DDRCAL. Since I didnt intentionally alter the SDRAM in Qsys I didnt see why this should occur. I examined the emif.xml file from my pared down project and the one from the gsrd and they are the same.
I tried loading my program (named TestVer.rbf below) and it boots as shown below;

U-Boot 2014.10-00320-g077e579-dirty (Apr 16 2017 - 22:35:05)

CPU : Altera SOCFPGA Arria 10 Platform
BOARD : Altera SOCFPGA Arria 10 Dev Kit
I2C: ready
DRAM: WARNING: Caches not enabled
FPGA: writing TestVer.rbf …
FPGA: Early Release Succeeded.
emif_reset interrupt acknowledged
emif_reset interrupt acknowledged
emif_reset interrupt acknowledged
Error: Could Not Calibrate SDRAM
DDRCAL: Failed
INFO : Skip relocation as SDRAM is non secure memory
Reserving 2048 Bytes for IRQ stack at: ffe386e8
DRAM : 0 Bytes
data abort
pc : [] lr : []
sp : ffe3fff0 ip : 00000016 fp : 00000001
r10: ffd02078 r9 : ffe38ee8 r8 : ffe00000
r7 : ffe20450 r6 : 00000000 r5 : 00000000 r4 : ffeff000
r3 : ffe38faf r2 : ffe40000 r1 : ffe3b000 r0 : ffe38ee8
Flags: nzcv IRQs on FIQs on Mode SVC_32
Resetting CPU …

resetting …

(and then it repeats ad infinitum …)

I beleive the problem is in the uboot file and was about to start experimenting with the command line bsp tools (instead of relying on bsp-editor). I will take some time to try to understand all of the entries in the emif.xml file to see if something odd sticks out. I could have a configuration issue in Qsys and will look into that as well (I did make a lot of changes in reducing the configuration so this is a good place to start).

I am using Quartus ver 17.0 and Angstrom v2015.12. I had very good luck working with the Cyclone V (Terasic DE-1) board and proved in the concept for my project, then switched to the Arria 10, which turned out to be a bigger change than expected. I am working on getting a flat file FPGA design (as opposed to a partial reconfiguration design) working to be compatible with an IP package for USB 3.1 gen 2 that I plan to use (they use a flat file design in the code they distribute and Quartus v17.0). There seems to be a dearth of flat file examples using the HPS processors for the A10 SoC board. My project uses the HPS processors heavily which simplifies the code for the light work and keeps the FPGA free for what its best at, so you would think I am on the easy street, if only I can get a file to load.


It’s difficult to understand what might be happening in light of all the modifications your making to the GSRD Quartus project. A good place to start is to begin with the GSRD (unmodified) and go through all the procedures of generating the files yourself (RBF, bootloader, and DTB) from Quartus. First try with a stock GSRD and make sure your booting and everything is working. After that you can move towards pairing down the QSYS portion and not using the “early release mode” so you have a single RBF and not the pair (if this is what you want). Note that the RBF must be loaded in order to get the HPS DDR working in Arria 10. This was not the case with Cyclone V where the HPS could be used independently (i.e. FPGA not configured until after Linux is booted). The FPGA cannot currently be reloaded in A10 without using the device tree overlay strategy due to the DDR going down in the process. Therefore only a partial reconfiguration can be done after Linux is booted. Some would say they broke things in A10 from the way CV works.

Hope this helps:

You must build uboot on a Linux platform and I’ve only done it for A10 using the SocEDS 16.1 tools.
I’ve followed the procedure below on Ubuntu 16 and Centos 6.5.

  1. Open a SoC EDS embedded_command_shell.sh

  2. cd <your_quartus_project> then open bsp-editor
    % cd
    % bsp-editor &

  3. Create a new HPS BSP via the File Menu “New HPS BSP”

  4. Using the dropdown menu labeled “Operating System” select “U-Boot Bootloader (Arria 10 HPS)”

  5. Point to the software handoff directory (hps_isw_handoff) created from the Quartus Compile and click OK

  6. Edit the RBF filename to match the one you created (usually contained in the output folder)
    Note: specify the “.periph.rbf” for the GSRD
    Note: You can set an option in Quartus to make an RBF at compile time
    Manual method:
    % cd /output
    % quartus_cpf -c -o bitstream_compression=on your_project.sof your_project.rbf

  7. Select the desired boot device (SD/MMC is default for an SD card), Click Generate then Exit

  8. Navigate to the location of the created u-boot in your terminal
    % cd <your_quartus_project>/software/uboot_bsp

  9. Build it
    % make

Output Files:

U-boot executable with device tree binary wrapped in mkpimage header (write this to SD card):

Further Reading:
For SD Card - see page 30:

After 3:00pm EST today I’ll be away from the computer until Monday.
Good Luck!



A couple more comments:

If you cannot compile the stock GSRD then first try using the RBF’s supplied on the card.

When you pair down the GSRD do not change anything related to the EMIF or anything related to clocking or reset. First delete only the obvious non-system related items (like LED, VGA, whatever…).

The EMIF used to be in the HPS block for CV and now it’s required externally for the A10. You should not be changing anything there until moving to a new hardware platform (with different pinout, DDR timing, etc).


I followed your advice and regenerated the uboot_w_dtb-mkpimage.bin for the stock GSRD and installed it and it works well. This seems to indicate that the uboot generation process I am using is Ok and my problem is really in my project. I may have cut too much from the GSRD when I tried paring it down so I am restarting the pare-down and taking it slow. I’ll check at each removal (to the degree I am able to compile). I was intentionally keeping away from the memory but I must have stepped on a clock or reset somewhere and not noticed. this time through I will keep good notes of what connections were removed. I’ll let you know how it goes.


I was successful in getting a clean compile by turning off the display port module and removing its ip support files from the project. The GSRD compiles and creates an RBF as part of the project recipie so I got a new ghrd_10as066n2.rbf which I placed on partition 1 of my SD card and all boots well.
I see that when the GSRD compiled that it does not create an RBF or SOF for ghrd_10as066n2.periph.rbf or gsrd_10as066n2.core.rbf I am Ok with carrying these files along if that helps me be able to load my code into the FPGA but I would like to know how these are created. Earlier I had supposed that these are just part of the partial reconfiguration process but I see from your message that the Arria 10 does not work as I had expected, so maybe partial reconfiguration is not an option. I still would like to know how these files are generated and what I can do with them. I have only scratched the surface of the gsrd pare-down and have more to go so maybe I will find answers as I proceed. Thanks for your sage advice.


I found the Arria 10 CvP manual and see that this is the way to enable the CvP files in the Convert Programming Files dialog. I am going to use the stable (at least able to be compiled) gsrd version I have and make a CvP version that can generate the .periph and .core files. Once I can generate these, and create the uboot (which I have done Ok with so far) I believe I will be in control of creating FPGA code that I can load and execute. (getting pretty close now …)


Great! It sounds like you’re making good progress.

Do you need to load (or reload) the RBF after Linux is booted? The .periph and .core files are part of the “early io release” strategy which I believe is required for partial reconfiguration. You will only get one RBF if you do not have this enabled in Quartus. If you want to re-load the RBF after boot then I believe you must use the early io release strategy and partial reconfiguration. In order to do that with Linux you must use the Device Tree Overlays that Altera supplied and up-sourced in the 4.x kernel releases. You no longer can “dd” an RBF to the FPGA as was done in CV.

It been on my radar but I’ve not yet re-loaded an Arria10 from Linux using the device tree overlay method. So for that I will not be much help. Here are a couple links I previously saved to look at later when I got around to it.

They use the device tree overlay strategy in this workshop

Hints on reloading after boot

A quick presentation on "early io release"



No, I had no plans to reload the FPGA on the fly. I have an application to run and it just runs (and uses as much of the FPGA as needed so no partition fitting issues to deal with). I am only exploring the CvP because that is how I see the Arria 10 boot working (using the .periph and .core RBFs). The CvP doc implies that the reconfigurable part may or may not be used, so in that case my application would all fit into the .core file, and the .periph file describes the interfaces as it does now. This looks like a flat file to me, with an added peripheral description add-on. If there is a second method to accomplish the same I’ll check it out too.


For Arria10 I currently use a single RBF and not the early release pair of RBF’s but both methods will work with the SoCEDS generated bootloader. You just need to specify the RBF filename in the bsp-editor. The only reason I can see to use the early io release (.periph and .core) files is to load or reload the FPGA from Linux.

For your store of semi-worthless knowledge:
We reload Cyclone V’s all the time from Linux using the “dd” command to /dev/fpga0. With Arria10 we’ve decided to have uboot load the Kernel, DTB, and RBF from the Linux ext filesystem rather than the FAT partition. This way we can change which RBF is loaded by using a soft link rather than replacing (or renaming) files on the FAT partition. The only thing left on our FAT partition is a uboot script. Our products only run in one mode or another so this is not something that happens dynamically during normal operation (once at configuration only). One of these days I’ll get around to loading/reloading the RBF’s from Linux but I’ve just not needed to do it yet with our Arria10 product lineup. I understand the power of dynamically reloading a device tree (to match RBF design changes) but I’m also unhappy that they broke the ability to “dd” to /dev/fpga0.



After some work it looks like I circled back to near where I was before.

I have been following the uboot process as before so I beleive it is stable.

I worked backwards in steps from the gsrd to remove more unneeded parts (near to where I was when I saw load failures earlier) and the resulting RBF file loaded and operated (at least Linux was working) with the gsrd uboot in place (so ghrd_10as066n2.periph.rbf was specified in bsp-editor).

When I re-ran bsp-editor to specify the pared down gsrd RBF (which is named ghrd_10as066n2.rbf at present since I have not renamed things) it does not load and shows the same symptoms as reorted earlier. This makes it look like the early release method is preferable over a single part RBF file (which I would call a flat file). My previous assumption was that the earlier failure was because my conversion of the gsrd was somehow faulty, but now I question that.

I had set out to make a CvP (early release) uboot but got side tracked since the available documentation makes it look like you must have a PCIe IP component to get the CvP files (.periph and .core), but I think I can get there without that now. The older documentation for the Cyclone and Arria V FPGAs shows making some manual settings in a quartus.ini file in the project directory to allow the CvP files to be generated. The gsrd does partial reconfiguration with no PCIe component and no quartus.ini file that I can find so I believe I can set the CvP enable in the assignments - Device dialog and try the same test with a .periph and .core file.


I had no success with trying to create CvP configuration using the Quartus ‘Assignments -> Device -> Device and Pin Options’ settings due to errors at the assembler step (it is trying to set up for device EPCQL256 is one, and in other attempts where I changed different options I get pin conflicts - which seem to be irreversible so I have to start the project over again). This was heading in the wrong direction anyway since I really do not want a partial configuration, but i was attempting it just to get something that runs.

Since I was able to boot the trimmed down ghrd with the original ghrd uboot (which uses partial reconfiguration) I took another step at reducing portions of the ghrd and retrying. I was again able to boot and run Linux using the reduced ghrd project (I disabled elements in Qsys, then dropped the IP files in the Quartus project) I further reduced it and tested using the ghrd uboot again. It still boots and operates Linux, so I made another uboot (using bsp-editor) to boot my version of the ghrd_10as066n2.rbf file in anther try at getting a flat file to operate with an HPS. This failed again in the same way as all the past attempts (see below).
what I notice in the messages below is that the response after loading the ghrd_10as066n2.rbf file is that ‘Early Rleease Succeeded’ so it looks like the uboot is still configured for a partial reconfiguration, thugh I intended for a flat file. I was thinking that if I used the RBF that was the result of my project compilation tha t this would create a flat file uboot, but this does not seem to be the case. So there is some other missing step needed to create a uboot that is a flat file configuration. I havent run across it in Altera documentation yet, and I dont see any good indicators in menu options in Quartus or bsp-editor. It look s like I am at a standtill.

U-Boot 2014.10-00320-g077e579-dirty (Apr 16 2017 - 22:35:05)

CPU : Altera SOCFPGA Arria 10 Platform
BOARD : Altera SOCFPGA Arria 10 Dev Kit
I2C: ready
DRAM: WARNING: Caches not enabled
FPGA: writing ghrd_10as066n2.rbf …
FPGA: Early Release Succeeded.
emif_reset interrupt acknowledged
emif_reset interrupt acknowledged
emif_reset interrupt acknowledged
Error: Could Not Calibrate SDRAM
DDRCAL: Failed
INFO : Skip relocation as SDRAM is non secure memory
Reserving 2048 Bytes for IRQ stack at: ffe386e8
DRAM : 0 Bytes
data abort
pc : [] lr : []
sp : ffe3fff0 ip : 00000016 fp : 00000001
r10: ffd02078 r9 : ffe38ee8 r8 : ffe00000
r7 : ffe20450 r6 : 00000000 r5 : 00000000 r4 : ffeff000
r3 : ffe38faf r2 : ffe40000 r1 : ffe3b000 r0 : ffe38ee8
Flags: nzcv IRQs on FIQs on Mode SVC_32
Resetting CPU …

resetting …
(it continues in reboot attempts at this point)

For now I will proceed in faking some progress by using the ghrd and plunking my code into the middle of it. This is not going well.


Still having same problem. Discovered that when I allow the .periph and .core RBFs to boot (so using ghrd uboot) with my ghrd_10as066n2.rbf it does not actually load my file. It is loading the ghrd program. Trying to load my RBF (by naming it in bsp-editor) does load it and start to run it but the re-boot cycle (shown above) resets and re-loads over and over.
If there is something else needed to make the single RF load work (if nameing it in bsp-editor is not enough) then I would like to hear about it. Otherwise I must have something wrong with my Qys setup. Any suggestions?


I thought I found something in the EMIF IP settings in QSys, where the checkbox for ‘Enable HPS Early Release Mode’ was checked. Since this appears to be related to the messages I have been seeing in boot failure I had hopes that a new run at it would show improvement. Unfortunately that doesn’t seem to have changed anything, still the same boot messages and repeat booting.


I have moved ahead some in investigating the problems I have with flat design loading but not far enough to see success. So far I have been unable to get a flat design containing an HPS component to be loadable via the SDCard and am looking for any example of how that can be accomplished. I would be happy to send a link to my example design and the steps I take to make its device tree and uboot code. What I keep ending up with is a boot cycle that continually reboots after it has successfully loaded the RBF file (and I can see that the FPGA design has started to run because the LEDs I set start to operate before the board begins rebooting). If you have any insight into flat design use I would appreciate a tip to get me started.
I am pretty sure the board hardware is Ok because the GHRD project loads and runs without problems. At various points in the search I have been convinced that it is a uboot problem or an HPS or memory configuration problem but none has panned out for me so far.
If you have a loadable flat design example I would like to try it. Even if it doesn’t have an HPS at this point working on adding the HPS component to a working, loadable project is at least productive work for me.


I do not have anything prepared that would work on the A10 Dev kit, I do have a simple flat design Quartus project for one of our test boards that I used to boot Linux. I could send you if you think it would help. There’s not much in it (an led interface, i2c, misc). Let me know how to get it to you if you want it.