Hello.
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. 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 my Commands console (see screenshot #1 below) looks very close to Figure 36 (their tutorial author's output after running the preloader). So far so good?
ISSUE:
Then, once I run the actual "Hello World" 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. 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:
Are there any hints in my screenshots or provided information regarding why the preloader (again, attached) isn't doing it's job and bringing up the SDRAM?
I'm not familiar with this board, but to answer in general...The error says that there is no (writable) memory at 0x02000000, is that the SDRAM?Looking above, it says that SYSID registers are not found... are these referenced in the altera_target_check.py script? Perhaps something doesn't execute therein?To specify the peripheral description file, go to Debug Configurations > File
Does that help at all?
Hi Ronan. Thanks for the response.
Indeed, 0x02000000 is the SDRAM. It is what I specified in the scatter file I am using, shown below.
I am not sure about the SYSID registers, but I wasn't concerned by that message - in the Bare Metal Example I am following, that also shows up when they run the preloader and the code which runs from SDRAM, so I figured the fact that I matched up was fine.Nontheless, I have included a capture of that part of altera_target_check.py. To me, it is not very illuminating.
Then, unfortunately, setting the peripheral description file path didn't help. (As an aside, what is that step? The tutorial didn't mention it.)
It still seems that the preloader is running the same as in the example, but the SDRAM isn't being brought up.
Thanks for the suggestion, though.
Adding the peripheral file will allow peripheral registers to be displayed in the registers pane of the debugger. It is not mandatory, but I wondered if that script did something assuming its existence. Looking at the script, it appears to only (attempt to) read that register, so may be irrelevant.
This script and example were developed by Intel - you may have better luck getting focused advice on their forumhttps://community.intel.com/t5/Programmable-Devices/bd-p/programmable-devices
Thanks for the info and the suggestion Ronan. I more or less copied my post here on ARM over there on Intel - we'll see if there are some insights there. Take care.
My post on Intel: https://community.intel.com/t5/Intel-SoC-FPGA-Embedded/Failed-to-load-quot-lt-project-axf-gt-quot-Can-t-run-bare-metal/m-p/1287029/emcs_t/S2h8ZW1haWx8dG9waWNfc3Vic2NyaXB0aW9ufEtQSEhSMEVXQUhXTUpWfDEyODcwMjl8U1VCU0NSSVBUSU9OU3xoSw#M1046
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 the below 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-Nano boards have a Cyclone V chip. 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.