DE10-nano fails to boot from SD


I switched from using the DE0-nano Development Board (Rocketboard) to the DE10-nano Development Board (Rocketboard) for a baremetal-Application. Both use a Cyclone V SoC FPGA. The FPGA is configured trough the onboard EPCS. The MPU main-routine is supposed to be loaded by an external memory card. On that card are two different partitions. One in which I programmed the preloader (A2) and one FAT-partition which hosts my image-file. This image-file includes the main-application which is loaded by the preloader into the MPU.
I successfully designed my FPGA-Design in Qsys and programmed the FPGA. With the generated handoff-files, I build the preloader with the bsp-editor.

When I load the ELF-file (“u-boot-spl”) of the compiled preloader with the DS-5 debugger, the MPU and the FPGA are running correctly. Same applies, when I load just the ELF-file via the debugger and put the HPS-image-file on the FAT-partition of the SD-Card. Thus, both the preloader-ELF-file and the HPS-image-file seem to be flawless.
To get the system working standalone, I need to boot the preloader from the SD-Card. So I programmed the SD-card with the corresponding executable binary of the compiled preloader-files (“preloader-mkpimage.bin”). When I power up the board, the preloader successfully configures the HPS. This can be seen by establishing the UART-connection with Putty. However, this time the main-routine gets stuck. So it seems like the preloader compiled ELF-file works but the corresponding bin-file does not.
When I boot the preloader from the SD-Card and load the axf-file manually (with the help of a debugger script) into the SDRAM I can see that the main-routine gets stuck at the source line “alt_int_handler_abort” of the assembly file “alt_interrupt_armcc.s”. Latter file is part of the HWLIB provided by Altera.

Further investigations show, that this occurs with the first read access from the HPS to the FPGA via the “Lightweigt HPS-to-FPGA Bridge”. So is seems like this bridge is not configured properly!?

Since the boot.img of the HPS is working well, I think the problem is the preloader which starts from the SD-card (preloader-mkpimage.bin). With the debugger-command:
“restore preloader-mkpimage.bin binary 0x0”
I tried to directly load the “preloader-mkpimag.bin” into the the Boot ROM in order to see whether this file is somehow corrupted. Unfortunately this does not work. I get the error “Unable to restore image”.

My Questions:

  • Does anybody encounter similar problems when using the DE10-nano-board? Previously I worked with the DE0-nano board which just worked fine.
  • Does anybody know what the “alt_int_handler_abort” line does? Why gets the main-routine stuck here? Under what conditions do I end up here?
  • Is it possible to load directly the “preloader-mkimage.bin” into the Boot ROM?
    The setup:
  • DE10-nano development board (Cyclone V SoC FPGA)
  • Windows 7 SP1
  • Quatus Prime 16.1
  • Eclipse with DS-5 v5.25.0

I trying to get this Board working for already 2 weeks now, but I just do not get any furhter at this point. Any help is neccessary and would be appreciated!

Best regards


I do not use DE10-nano board and I am also a common user, but this seems to me not to be an issue of the board. Could I ask if You have surely regenerate all necessary things for booting from SD card? Preloader, Device Tree Blob for U-Boot, U-Boot image and U-Boot script (and Device Tree Blob for Linux, if operating system is used) depend on source of booting (as far, as I know). Have You followed the Embedded Linux Beginners Guide at Rocketboards ( and the manual of Intel (Altera) Embedded Development Suite (
I am sorry if my question is silly, but I do many so base faults myself, because there is many places for faults.
By the way, I have thought that U-Boot is not necessary for bare-metal applications, so could I ask You why You want to use it?
I am looking forward to hearing from You. Best regards until that time.

Hello JanKonecny,
Thank you for your reply.
Since I build the preloader for several times, I am pretty sure, that I did not skip any necessary part of the regeneration of the preloader. This is what I did to mitigate from DE0-nano to the DE10-nano:

  1. Quartus Prime --> Change Device Settings: Cyclone V; 5CSSEBA6U2317
  2. Qsys --> Generate
  3. Quartus --> Compile
  4. Create Header-files with the *sopcinfo-file
  5. Create Preloader from the generated spl_bsp-files with the bsp-editor and the SoC EDS mkpimage-tool:
    • U-boot-spl
    • U-boot-spl.bin
    • Preloader-mkpimage.bin
  6. Programme the SD-Card with the bin-file with the alt-boot-disk-util -command
  7. Compile Eclipse DS5-HPS Programme the created Header-Files

Since the boot.img for the HPS is running fine when I boot up the board by the debugger, the “u-boot-spl” file seems to be fine. Thus, the workflow described above seems to be ok.

However, when I boot from SDMMC with the “preloader-mkpimage.bin” (which is also made by the mkpimage-tool) the HPS-Program gets stuck as soon as the main-routine wants to read from the Ligtweight HPS-to FPGA-bridge. So it seems like the only the preloader-mkpimage.bin preloader does not configure the bridge correctly.

I use u-boot since it is suggested in the Intel_SiC_FPGA_embedded Development Suite User Guide.
Do you know whether there an alternative to the mkpimage-tool?

All the reference-design I had a look at, do not differ between the two different SoC-FPGAs used in DE0-nano (Cyclone V SE SoC—5CSEMA4U23C6N) and DE10-nano (Cyclone V SE SoC—5CSEMA6U23I7N). They just refer to the SoC Cyclone V. So apparently, for the preloader there is no difference for the two different SoCs.
I proved this assumption by using the preloader which I initially created for the DE10-nano board in the DE0-nano board. Here, the HPS boots successfully from the SDMMC. Everything works and the main-routine does not get stuck.

Best regards!

well, this looks like a right way of generating. The only step, which I am not familiar with, is generating preloader with mkpimage tool. I use to do it in a more simple way - only do ‘make’ at the direktory /software/spl-bsp because makefile (made by bsp-editor) is set up to doing it automatically. I also generate U-Boot in a similar way with ‘make uboot’.
Please, could You share here, what is printed down by preloader and U-boot during booting to terminal via serial link? I know that U-boot may not be able to program FPGA in cases the switches MSEL being set in a wrong way (You see - not suitable for parametres of Yours RBF file). If FPGA is not programmed, any of bridges would be available, so there would be an error in reading from bridge.


Yes you are right. I also do that with the “make-command”. As far as I understand does the makefile use the mkpimage-tool to produce the mkpimage.bin.

According to the UART-terminal the HPS boots correct:

Unfortunately this output does not say anything about the Bridge-configurations of the HPS-FPGA.

The MSEL is 01001 which configures the FPGA to boot from external EPCS. I do not have a problem with the FPGA-part. The configuraration of the FPGA just works fine.

I am very sorry, but I do not have any other idea how to help You.
Just the last hope: Have You tried to investigate why there are 2 messages reading boot.img. It is a bit strange, isn’t it? I use to observe this message during boot process only one time.