Intel® SoC FPGA Embedded Development Suite
Support for SoC FPGA Software Development, SoC FPGA HPS Architecture, HPS SoC Boot and Configuration, Operating Systems
Announcements
Intel Support hours are Monday-Fridays, 8am-5pm PST, except Holidays. Thanks to our community members who provide support during our down time or before we get to your questions. We appreciate you!

Need Forum Guidance? Click here
Search our FPGA Knowledge Articles here.
305 Discussions

Failed to load "<project.axf>" - Can't run bare-metal application from SDRAM

ESaiv
New Contributor I
853 Views

 

Hi there.

PREMABLE:

I have been following this Bare-Metal User Guide in ARM Development Studio (even though it is written for DS-5) in an attempt to get a bare-metal "Hello World" running from SDRAM (well, I replaced the words "Hello World" with "Don't Panic".) Following the guide, I have successfully ran it from OCRAM. 

I am stuck at the last step for running the application from SDRAM: I run the preloader (a u-boot-spl file; see the guide in the Preloader section, and see attached zip folder with the spl outputs) and my Commands console (see screenshot #1 below) looks very close to Figure 36 in the tutorial ( Figure 36 is the tutorial author's output after running the preloader). So far so good? 

ISSUE:

Then, once I run the actual "Hello World" ("Don't Panic") debug configuration, I get the error in screenshot #2, which, according to the guide, is the exact error received when the preloader has not yet brought up SDRAM , i.e., ERROR (CMD16-TAD274-NAL22). Hence, even though my preloader seems to be working (since my output upon running it looks the same as the guide's), the SDRAM is not being brought up. 

QUESTION:

So, I kinda get what's going on: I'm trying to run the preloader so it brings up SDRAM for me, but it doesn't do it's job. Then, when I try to run my bare-metal project out of SDRAM, it obviously fails to do so. Any hints on where I can start to fix this? 

PS: As per the tutorial, I am using .scat file with SDRAM 0x02000000 0x02000000. I have seen a few others, but this should work if it's in the tutorial.

0 Kudos
1 Solution
ESaiv
New Contributor I
768 Views

 

I have resolved this error. Or at least, the version of the error I was having. 

 

Intel ubiquitously suggests this example for building a preloader which brings up SDRAM, and it is a good example, but it does not make it explicitly clear (at least for a beginner) that it only works for the Cyclone V SoC FPGA Development Kit, which is a specific board with a specific SoC FPGA model. If you are using some other board (DE10-Nano, DE1-SoC, anything) it will not work without modifications. Once I ran the debug-spl.ds script from that example with modifications, the SDRAM HelloWorld (with scatter file, etc) from the Bare Metal User Guide in my original post worked well. 

 

If you want it to work for your particular board, you must ensure three things when going through the example: 

 

1. Make sure your hand-off folder, e.g. 

preloader-settings-dir "hps_isw_handoff/soc_system_hps_0" 

 is built for your board (in my case, it was the DE10-Nano). You can't use the cv_soc_devkit_ghrd because it's not generic - it only works for the that development kit. In my case, I just started the whole example in a new folder with a Quartus-generated hand-off folder for the DE10-Nano, and not inside /intelFPGA/20.1/embedded/examples... etc.

 

2. Replace the qts_filter step with a path specific to your board. For the DE10-Nano, I had to do the below. Note the difference at the end.

./arch/arm/mach-socfpga/qts-filter.sh cyclone5 ../../../ ../ ./board/terasic/de10-nano/qts/ 

 

3. Same with the make command - it's board specific. I had to go:

make socfpga_de10_nano_defconfig

 which is not obvious because we're replacing "Cyclone V" with "DE10-Nano" even though DE10-Nanos have a Cyclone V. All in all, the term "Cyclone V" often actually means "the Cyclone V development kit," so be cognizant of that. 

 

I hope this helps. If you have any questions about my resolution, reply in this thread. If I see the email, I'll answer, because I know what it's like to be stuck on these things.

 

View solution in original post

5 Replies
EBERLAZARE_I_Intel
795 Views

Hi,

 

I see that you are doing "loadfile a ..dont_panic.axf", what is the content of that .axf?  In the tutorial, you are loading the "bare-metal-hello-world-01.axf".

 

For an updated version of the tutorial, I recommend that you refer below which has a debug script for full preloader boot, or you may use the step to boot step by step:

https://rocketboards.org/foswiki/Documentation/SoCEDS#Cyclone_V_Bare_Metal_Example_Using_SoC_EDS_Sta...

 

ESaiv
New Contributor I
788 Views

Hi. Thanks for the response. The "don't panic" is a playful replacement of the words "hello world" in my file based on a book I like, but for all purposes, it's just a simple C program which prints text like a normal Hello World would. I have ran my dont_panic.axf perfectly fine out of OCRAM.

I have tried that tutorial that you linked, but encounter a different error when I run the debug-spl.ds script shown in that tutorial. I have included that error below.  

Do you know why I would get that error after the "wait" command?

ESaiv
New Contributor I
787 Views

Do you know if I need a Quartus project (which includes an HPS component instantiation) already configured on the FPGA on the board before I try to run the preloader script? Or is that just required if I actually wanted to talk to the FPGA with a program? 

EBERLAZARE_I_Intel
742 Views

Hi,

 

I see that in the image attached you "quit" after you have bring up the preloader, which would mean that you did not have the preloader brought up when brining the hello world, which is as describe the error that you are seeing, you need to bring up the preloader to configure the SDRAM, in your case the preloader was disconnected before you bringing up your hello world test.

ESaiv
New Contributor I
769 Views

 

I have resolved this error. Or at least, the version of the error I was having. 

 

Intel ubiquitously suggests this example for building a preloader which brings up SDRAM, and it is a good example, but it does not make it explicitly clear (at least for a beginner) that it only works for the Cyclone V SoC FPGA Development Kit, which is a specific board with a specific SoC FPGA model. If you are using some other board (DE10-Nano, DE1-SoC, anything) it will not work without modifications. Once I ran the debug-spl.ds script from that example with modifications, the SDRAM HelloWorld (with scatter file, etc) from the Bare Metal User Guide in my original post worked well. 

 

If you want it to work for your particular board, you must ensure three things when going through the example: 

 

1. Make sure your hand-off folder, e.g. 

preloader-settings-dir "hps_isw_handoff/soc_system_hps_0" 

 is built for your board (in my case, it was the DE10-Nano). You can't use the cv_soc_devkit_ghrd because it's not generic - it only works for the that development kit. In my case, I just started the whole example in a new folder with a Quartus-generated hand-off folder for the DE10-Nano, and not inside /intelFPGA/20.1/embedded/examples... etc.

 

2. Replace the qts_filter step with a path specific to your board. For the DE10-Nano, I had to do the below. Note the difference at the end.

./arch/arm/mach-socfpga/qts-filter.sh cyclone5 ../../../ ../ ./board/terasic/de10-nano/qts/ 

 

3. Same with the make command - it's board specific. I had to go:

make socfpga_de10_nano_defconfig

 which is not obvious because we're replacing "Cyclone V" with "DE10-Nano" even though DE10-Nanos have a Cyclone V. All in all, the term "Cyclone V" often actually means "the Cyclone V development kit," so be cognizant of that. 

 

I hope this helps. If you have any questions about my resolution, reply in this thread. If I see the email, I'll answer, because I know what it's like to be stuck on these things.

 

Reply