Intel® SoC FPGA Embedded Development Suite
Support for SoC FPGA Software Development, SoC FPGA HPS Architecture, HPS SoC Boot and Configuration, Operating Systems
413 Discussions

FPGA On-Chip Memory Initialization with Preloader



I am attempting to boot the Cyclone V from the FPGA on-chip memory however when I try to initialize the on-chip memory component with the preloader.hex file by re-compiling the project in Quartus I get the following error:

Error (114016): Out of memory in module quartus_map.exe (5304 megabytes used)
Error (293007): Current module quartus_map ended unexpectedly. Verify that you have sufficient memory available to compile your design. You can view disk space and physical RAM requirements on the System and Software Requirements page of the Intel FPGA website (

I have 16GB of RAM on my computer so memory shouldn't be an issue.  I also have ~12GB free on my one hard drive if that makes a difference.  I am currently using Quartus Prime version 20.1.1 Build 720 and Intel Embedded Command Shell version 20.1 Build 711.  However, when I try to use a different preloader.hex file generated previously using Quartus version 17.0, I do not encounter the error.  I am using Windows 10 and because of our licensing I am unable to use an older version of EDS (i.e the old boot flow).

The steps I used to generate the preloader are given below (I was unable to find documentation of the full preloader generation process on Windows, this is what I was able to piece together and get working):

NOTE: I did have to implement multiple fixes to get this working.  I can provide more details on this if needed.


[WSL] run in the WSL terminal (Ubuntu 18.04 LTS)

[ECS] run in the Embedded Command Shell terminal (C:\intelFPGA\20.1\embedded\Embedded_Command_Shell.bat)


1. [ECS], navigate to project directory

2. [ECS] $ mkdir -p software/bootloader

3. [ECS] $ bsp-create-settings --type spl --bsp-dir software/bootloader --preloader-settings-dir hps_isw_handoff/soc_system_hps_0 --settings software/bootloader/settings.bsp

4. make required edits to software/bootloader/settings.bsp

5. [ECS] $ bsp-generate-files --bsp-dir software/bootloader/ --settings software/bootloader/settings.bsp

6. [WSL] navigate to project directory

7. [WSL] $ cd software/bootloader

8. [WSL] $ git clone

9. [WSL] $ cd u-boot-socfpga

10. [WSL] $ ./arch/arm/mach-socfpga/ cyclone5 ../../.. .. ./board/terasic/de10-nano/qts

11. [WSL] $ export CROSS_COMPILE=<path to toolchain>/gcc-arm-10.2-2020.11-x86_64-arm-none-linux-gnueabihf/bin/arm-none-linux-gnueabihf-

12. [WSL] $ make socfpga_de10_nano_defconfig

13. [WSL] $ make -j 24

14. [WSL] $ export PATH=<path to toolchain>/gcc-arm-10.2-2020.11-x86_64-arm-none-linux-gnueabihf/bin:$PATH

15. [WSL] $ cd ..

16. [WSL] $ arm-none-linux-gnueabihf-objcopy -O ihex --adjust-vma -0xc0000000 u-boot-socfpga/spl/u-boot-spl preloader.hex


If anyone can point out the reason for my error and confirm if my process is correct, I would greatly appreciate it.




0 Kudos
6 Replies



We recommend user to use Linux when building the booting binaries; please refer below documentation on the steps:


0 Kudos

Hello and thank you for your response,


I understand that the preloader generation process works best on Linux however I would like to carry out the process on Windows if at all possible.  I already have a significant amount of the project set up on Windows and I believe it will be easier for people in my organization to follow my design example on Windows.




0 Kudos



If you insist on using the Windows environment to build, then you might need to use version 19.1/19.3 to compile and build in Windows.

0 Kudos

I think this issue may extend beyond just the Preloader.

I tried to initialize a second on-chip memory component with a .hex file containing the HPS bare-metal application image.  I converted the application-mkimage.bin file (which I confirmed works when booting from the SD card) to a .hex file with the following command in the Embedded Command Shell version 17.0:

arm-altera-eabi-objcopy -I binary -O ihex --adjust-vma -0xc0000000 application-mkimage.bin application.hex

When trying to recompile the project so that the preloader.hex and application.hex files are actually synthesized in the FPGA memory, I get the same error as before.  When I rename application.hex so that Quartus can't find the memory initialization file, the error goes away. 

Note that I was actually able to use the Altera Embedded Command Shell version 17.0 to generate the Preloader and convert it to a .hex file without errors.

I also tried changing the size of the on-chip memory component that contains the application.hex file to be much greater than the size of the file and still got the same error.

I have attached the application.hex file (converted to a text document) for anyone interested.  The beginning and the end of the file are similar to the preloader.hex file that I couldn't synthesize in memory  (these sections are missing from the preloader.hex file that did work without error)

0 Kudos

Some updates:


For some background, for my demo I am simply trying to run the Altera-SoCFPGA-HardwareLib-16550-CV-ARMCC example design on the HPS which ships with Quartus (C:\intelFPGA\20.1\embedded\examples\software).  Before building the project, I had to change the toolchain to Arm Compiler 5 (this is the toolchain the project was designed for and it wouldn't build properly otherwise).


Opening the generated application.axf.objdump file I noticed that Section #5: ARM_LIB_STACKHEAP was very large (1072623568 bytes).  To see if this section may have been the cause of the errors, I tried to remove this section while generating the binary file by running the following commands in the Embedded Command Shell:
$ arm-altera-eabi-objcopy -O binary -R ARM_LIB_STACKHEAP application.axf application.bin

mkimage -A arm -O u-boot -T standalone -C none -a 0x00100040 -e 0x00100040 -n “baremetal image” -d application.bin application-mkimage.bin

$ arm-altera-eabi-objcopy -I binary -O ihex --adjust-vma -0xc0000000 application-mkimage.bin application.hex

However, after recompiling the project in Quartus with the new binary file the same error appeared.


I am not sure whether or not these most recent errors are related to similar issues compiling with the preloader image as mentioned above.


As an FYI, the final project will eventually be open source so I can most likely provide additional information/files if it would be useful.

0 Kudos

Great solution

0 Kudos