- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hi magic forum,
I've been trying to make a small bare-metal program working on terasic de10 board with altera cyclone V soc ARM on it. I have some trouble when trying to boot the program from sd card. Here is a brief summary what I did: For the FPGA part, I just use the example program called DE10-Standard_GHRD from DE10 system CD, compiled with Quartus and generate preloader from it according to this (https://people.ece.cornell.edu/land/courses/ece5760/de1_soc/soc-fpga%20design%20guide_epfl.pdf)(pg. 69-70) (https://people.ece.cornell.edu/land/courses/ece5760/de1_soc/soc-fpga%20design%20guide_epfl.pdf). Basically I leave everything as default but enabled FAT-SUPPORT, BOOT_FROM_SDMMC, disabled WATCHDOG_ENABLE. Then I run make to get preloader-mkpimage.bin. For the software, I made a small program to blink LED, to load this program, I first tried with DS-5 debugger and load through JTAG to the board, it works fine. Then I tried to load the program from sd card, I've write the preloader(preloader-mkpimage.bin) to a2 partition and put this LED blinking program image(blinking.img) in the fat partition, however, this time it won't work. I can see from putty terminal that the preloader tried to load the image but it stuck at reading blinking.img. However if i replace the blinking.img with linux image, then the linux will be booted. So I think the preloader is ok. Any ideas which part I might do wrong? I double checked the program entry address and matched the image name with the one I specified in bsp editor. Thanks in advance!Link Copied
9 Replies
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hello.
Which options are you set when making binary image of the application? Can we see exact steps? Why not to try to load bootloader and then the app by DS-5 debugger? This could be easily done with simple .ds script.- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
--- Quote Start --- Hello. Which options are you set when making binary image of the application? Can we see exact steps? Why not to try to load bootloader and then the app by DS-5 debugger? This could be easily done with simple .ds script. --- Quote End --- I applied the following command line, basically I've tried different loading address and entry point combinations. mkimage -A arm -O u-boot -T standalone -C none -a 0x00100000 -e 0x00100000 -n "u-boot" -d hps_fpga_test.bin blink.img Because in my case I have to use sd card instead debugger, with debugger it works just fine.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
--- Quote Start --- I applied the following command line, basically I've tried different loading address and entry point combinations. mkimage -A arm -O u-boot -T standalone -C none -a 0x00100000 -e 0x00100000 -n "u-boot" -d hps_fpga_test.bin blink.img --- Quote End --- Mine is: arm-altera-eabi-objcopy -O binary app.axf app_binary.bin mkimage -A arm -T standalone -C none -a 0x100000 -e 0 -n "baremetal image" -d app_binary.bin app.img But i'am using MPL preloader, worked fine with it. --- Quote Start --- Because in my case I have to use sd card instead debugger, with debugger it works just fine. --- Quote End --- You can use debugger with sd card or whatever else you have got there. Just use the script file like this, for example, debug-unhosted.ds
# Reset and stop the system.
reset system
stop
wait 30s
# Disable semihosting.
set semihosting enabled false
#
# Load the preloader into memory.
loadfile "$sdir/../Altera-SoCFPGA-HardwareLib-MPL_de10nano/mpl_C5_s.axf" 0x0
# Delete any existing breakpoints.
delete
# Set a breakpoint just before application code is called
tbreak mpl.c:419
# Set the PC to the entry point and go.
run
# Wait for the breakpoint.
wait
Then step into the code to see what is happening next.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
--- Quote Start --- Mine is: arm-altera-eabi-objcopy -O binary app.axf app_binary.bin mkimage -A arm -T standalone -C none -a 0x100000 -e 0 -n "baremetal image" -d app_binary.bin app.img But i'am using MPL preloader, worked fine with it. You can use debugger with sd card or whatever else you have got there. Just use the script file like this, for example, debug-unhosted.ds
# Reset and stop the system.
reset system
stop
wait 30s
# Disable semihosting.
set semihosting enabled false
# # Load the preloader into memory.
loadfile "$sdir/../Altera-SoCFPGA-HardwareLib-MPL_de10nano/mpl_C5_s.axf" 0x0
# Delete any existing breakpoints.
delete
# Set a breakpoint just before application code is called
tbreak mpl.c:419
# Set the PC to the entry point and go.
run
# Wait for the breakpoint.
wait
Then step into the code to see what is happening next. --- Quote End --- it seems I have lost. With the debugger I mean the DS5, I can load the program with the .ds script and step into the code just fine. But if I need to load the program through the sd-card to achieve the exact same thing, let's say blink the led, it won't work. it shows the following in putty, : U-Boot SPL 2013.01.01 (Aug 17 2017 - 17:27:12) BOARD : Altera SOCFPGA Cyclone V Board CLOCK: EOSC1 clock 25000 KHz CLOCK: EOSC2 clock 25000 KHz CLOCK: F2S_SDR_REF clock 0 KHz CLOCK: F2S_PER_REF clock 0 KHz CLOCK: MPU clock 925 MHz CLOCK: DDR clock 400 MHz CLOCK: UART clock 100000 KHz CLOCK: MMC clock 50000 KHz CLOCK: QSPI clock 370000 KHz RESET: WARM SDRAM: Initializing MMR registers SDRAM: Calibrating PHY SEQ.C: Preparing to start memory calibration SEQ.C: CALIBRATION PASSED SDRAM: 1024 MiB ALTERA DWMMC: 0 reading blink.img reading blink.img It seems the preloader is not loading the program.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
--- Quote Start --- It seems the preloader is not loading the program. --- Quote End --- Can you show me your debugger .ds script? And another moment - if your program uses diagnostic messages (printf etc), make sure they`re mapped to real hardware (UART port) and not using semihosting. Semihosting will not work without debugger and on the first call to printf application will hang. Try to run your app without diagnostic messages at all, for once.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
--- Quote Start --- Can you show me your debugger .ds script? And another moment - if your program uses diagnostic messages (printf etc), make sure they`re mapped to real hardware (UART port) and not using semihosting. Semihosting will not work without debugger and on the first call to printf application will hang. Try to run your app without diagnostic messages at all, for once. --- Quote End --- you the boss! I commented out the printfs then it starts to work. Many thanks sonycman!
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hi sonycman, hi merciyy
Excuse me if I post on this old thread, but I have now the same issue you were discussing here. I need to boot a baremetal application from SD but I don't know how I am supposed to create the bin file from the .axf coming out of build tools. I tried to use objcopy and mkimage as you wrote here: --- Quote Start --- Mine is: arm-altera-eabi-objcopy -O binary app.axf app_binary.bin --- Quote End --- but the objcopy creates a 4GB sized file!!! And then mkimage complaints that it can't read the bin file. I think I'm missing some simple point...- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
4GB sounds like you have the whole 32-bit address space mapped in your .axf file. Do you have any custom link sections in your project? For example if you mapped the HPS OCRAM (address 0xFFFF0000) as a link section to put some of your variables there, then your elf file will use addresses in almost all the space. In that case the bin file needs to be 4GB big to cover the whole space.
I had a similar problem, that I solved by stripping away this section from the elf file with the arm-altera-eabi-strip command. The problem with that solution is that the variables in the OCRAM section won't be initialized (or cleared) at startup so you must do this manually in your application if it is required.- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Thank you Daixiwen for your answer. You are right: the problem came from ocram sections mapped in the 0xFFFF0000 address range.
I had already solved the problem with a few changes in the linker script.
Reply
Topic Options
- Subscribe to RSS Feed
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Bookmark
- Subscribe
- Printer Friendly Page