Community
cancel
Showing results for 
Search instead for 
Did you mean: 
Altera_Forum
Honored Contributor I
1,361 Views

preloader not loading u-boot image

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!
0 Kudos
9 Replies
Altera_Forum
Honored Contributor I
148 Views

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.
Altera_Forum
Honored Contributor I
148 Views

 

--- 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.
Altera_Forum
Honored Contributor I
148 Views

 

--- 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.
Altera_Forum
Honored Contributor I
148 Views

 

--- 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.
Altera_Forum
Honored Contributor I
148 Views

 

--- 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.
Altera_Forum
Honored Contributor I
148 Views

 

--- 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!
Altera_Forum
Honored Contributor I
148 Views

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...
Altera_Forum
Honored Contributor I
148 Views

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.
Altera_Forum
Honored Contributor I
148 Views

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.