Forum Discussion
Altera_Forum
Honored Contributor
8 years agoCyclone V SoC Preloader will not run bare metal app
Hello all,
I've been working on this problem for several days now. I've read every website/pdf I can find (e.g. these forums, rocketboards, altera pdfs, etc, etc, etc, etc) regarding bare metal applications on Cyclone V SoC and I still can't get this to work. I've gotten pretty far but I've basically run out of steam. I usually never post on forums unless I've tried every possible thing I can think of and have totally run out of ideas and places to search. I think I must just be missing something very simple. Here's what I've done so far (targetting DE10-Nano board): 1) Created basic HPS design with UART and SDMMC peripherals enabled and DDR3 settings configured same as golden reference design that was provided with the board 2) Built hardware design to .SOF without error and converted SOF to RBF so that it can be loaded by pre-loader 3) Using the 'hps_isw_handoff' I created the spl_bsp with bsp-editor and configured to boot from SDMMC 4) Compiled preloader using 'make' which generated preloader-mkpimage.bin without error 5) Ran alt-boot-disk-util to update pre-loader image on special partition of SD card 6) Created SD/MMC example C project in SoC EDS application (from https://www.altera.com/content/dam/altera-www/global/en_us/others/support/examples/soc/altera-socfpga-hardwarelib-sdmmc-cv-gnu.tar.gz) 7) Compiled example C project to .AXF with no errors using baremetal GCC arm-altera-eabi- toolchain 8) Copied AXF file to SD card FAT partition and inserted SD card into board 9) Powered on board Pre-loader uboot output is as follows:U-Boot SPL 2013.01.01 (Sep 04 2017 - 20:01:43)
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 800 MHz
CLOCK: DDR clock 400 MHz
CLOCK: UART clock 100000 KHz
CLOCK: MMC clock 50000 KHz
CLOCK: QSPI clock 3125 KHz
RESET: COLD
INFO : Watchdog enabled
SDRAM: Initializing MMR registers
SDRAM: Calibrating PHY
SEQ.C: Preparing to start memory calibration
SEQ.C: CALIBRATION PASSED
SDRAM: 1024 MiB
ALTERA DWMMC: 0
U-Boot 2017.03-rc2 (Mar 30 2017 - 19:07:16 -0700)
CPU: Altera SoCFPGA Platform
FPGA: Altera Cyclone V, SE/A6 or SX/C6 or ST/D6, version 0x0
BOOT: SD/MMC Internal Transceiver (3.0V)
Watchdog enabled
I2C: timeout in enabling I2C adapter
timeout in enabling I2C adapter
ready
DRAM: 1 GiB
MMC: dwmmc0@ff704000: 0
timeout in enabling I2C adapter
timeout in enabling I2C adapter
In: serial
Out: serial
Err: serial
Model: Terasic DE10-Nano
Net: No ethernet found.
Hit any key to stop autoboot: 0
=> run fpga_cfg
reading de10-nano.rbf
1952756 bytes read in 192 ms (9.7 MiB/s)
=> load mmc 0:1 0x01000000 sdmmc_example.axf
reading sdmmc_example.axf
669244 bytes read in 73 ms (8.7 MiB/s)
=> bootelf
CACHE: Misaligned operation at range
CACHE: Misaligned operation at range
CACHE: Misaligned operation at range
CACHE: Misaligned operation at range
CACHE: Misaligned operation at range
CACHE: Misaligned operation at range # # Starting application at 0x00100040 ...
INFO: System Initialization.INFO: Setting up Global Timer.INFO: Setting up SDMMC.RESULT: Some failures detected. As you can see the pre-loader loads the FPGA design file. The configuration DONE light turns on so I know configuration is successful. However, the example application fails. Clearly there are some cache issues but I have no idea what they mean or why they are happening. But then the example application starts and just fails with no indication as to why. I inserted some printfs into the example code and it fails at the call to alt_sdmmc_card_identify(). I'm not sure if the 0x01000000 address that I'm loading to makes sense. The only reason that I'm using it is because that's the address that the 'bootelf' command tries to load from. It's obvious that the SD card peripheral is working since the pre-loader can read from it. I also tried changing the u-boot environment variables and writing them back to the SD card and that worked as well. So SD card read/write operation seems OK. It's also obvious that the DDR is working because the pre-loader can clearly write the ELF file to the DDR at address 0x01000000 and the HPS can obviously read from it since the application does in fact run (just not successfully). Can someone please help me figure this out? Regards P.S. I'm not interested in using the debugger to load the application. I need the fpga design and application to be loaded off of the SD card as I've shown. So please don't reply with "use the debugger and make a debug script" or similar. I need the board to boot and just start running without cables attached. UPDATE: I've also tried the GPIO example from the altera website (https://www.altera.com/content/dam/altera-www/global/en_us/others/support/examples/soc/altera-socfpga-hardwarelib-gpio-cv-gnu.tar.gz) and doesn't even successfully print the first printf statement. Instead it just prints a bunch of garbage: => load mmc 0:1 0x01000000 gpio_example.axf
reading gpio_example.axf
610864 bytes read in 64 ms (9.1 MiB/s)
=> bootelf
CACHE: Misaligned operation at range
CACHE: Misaligned operation at range
CACHE: Misaligned operation at range
CACHE: Misaligned operation at range
CACHE: Misaligned operation at range
CACHE: Misaligned operation at range # # Starting application at 0x00100040 ...-ÊÊêJåÍѵ%¹¥Ñ¥±¥é?½¹¹J9=éJ¹¥ÑA%=j½Õ±¹J9=éÑÑ¥¹ÕÁA%=¥¹ÑÉÉÕÁ?J9=??ÕÁ:A%=½Éb?J9=é?ÕÁA%=½ÉAÕÍ¡ ÕÑ?¹¹J9=?¥ÍÑ?¥¹ÑÉÉÕÁ?¢¹±É¹J9=é?ÍÍ"AM}A }UMI}ÁéBAM0? ±¥¹*¹J9=??ÍÍ!AM}A }UMI}ÅéB5b5E5??±±?¡Ñ¹J9=??ÍÍBAM}A }UMI}ÉêBAM"???±±b?J9=??ÍÍ!AM}A }UMI}ÍÒB5b)E5ÒÕ?½¹á¥Ñ¢µ½¹26 Replies
- Altera_Forum
Honored Contributor
Hello Austin,
I've been reading the boot types and I still didn't find a solution for bare-metal application. My goal is to load up a design into FPGA (with the .rbf file) and then load my binary bare-metal application for ARM-A9. Today what I could do is to generate the preloader (preloader-mkpimage.bin) and my FPGA raw files to program (.rbf) but I couldn't find some tutorial of how to generate the u-boot.scr and u-boot.script to program FPGA and load the binary. =/ Btw, if I understood right to loadup the design and boot some bare-metal app you need and SD/MMC with: Partitions: fat32: ------ u-boot.img ------ u-boot.scr ------ baremetalapp.bin ------ soc_design.rbf a2: ------ preloader-mkpimage.bin Am I right about this? - Altera_Forum
Honored Contributor
--- Quote Start --- Hello Austin, I've been reading the boot types and I still didn't find a solution for bare-metal application. My goal is to load up a design into FPGA (with the .rbf file) and then load my binary bare-metal application for ARM-A9. Today what I could do is to generate the preloader (preloader-mkpimage.bin) and my FPGA raw files to program (.rbf) but I couldn't find some tutorial of how to generate the u-boot.scr and u-boot.script to program FPGA and load the binary. =/ Btw, if I understood right to loadup the design and boot some bare-metal app you need and SD/MMC with: Partitions: fat32: ------ u-boot.img ------ u-boot.scr ------ baremetalapp.bin ------ soc_design.rbf a2: ------ preloader-mkpimage.bin Am I right about this? --- Quote End --- I already can generate the binary bare metal with the mkimge header with the command: $(MKIMAGE) -A arm -T standalone -C none -a 0x100040 -e 0 -n "baremetal image" -d $(BIN) $(IMG) but when I try to run the u-boot.scr the output fails to run, my script is: u-boot.script: fatload mmc 0:1 $fpgadata soc_system.rbf; fpga load 0 $fpgadata $filesize; run bridge_enable_handoff; fatload mmc 0:1 0x00100040 hello-mkimage.bin; go 0x00100040; $(MKIMAGE) -A arm -T standalone -C none -a 0x100040 -e 0 -n "uboot script" -d u-boot.script u-boot.scr And the output is: U-Boot 2013.01.01 (Feb 14 2018 - 16:14:30) CPU : Altera SOCFPGA Platform BOARD : Altera SOCFPGA Cyclone V Board I2C: ready DRAM: 1 GiB MMC: ALTERA DWMMC: 0 *** Warning - bad CRC, using default environment In: serial Out: serial Err: serial Skipped ethaddr assignment due to invalid EMAC address in EEPROM Net: mii0 Warning: failed to set MAC address Hit any key to stop autoboot: 0 reading u-boot.scr 228 bytes read in 5 ms (43.9 KiB/s) # # Executing script at 02000000 Bad image type reading zImage ** Unable to read file zImage ** reading socfpga.dtb ** Unable to read file socfpga.dtb ** Bad Linux ARM zImage magic! - Altera_Forum
Honored Contributor
I'm just a beginner myself, so take my advice with a grain of salt, but the options to the mkimage command looks suspect to me:
$(MKIMAGE) -A arm -T standalone -C none -a 0x100040 -e 0 -n "uboot script" -d u-boot.script u-boot.scr I think what you want is something that looks more like that seen in the following web page (URL split with * instead of / to get past spam filter): rocketboards . org * foswiki * Documentation * GSRD131ProgrammingFPGA Here they use: "$ ~/cv_soc_devkit_ghrd/software/spl_bsp/uboot-socfpga/tools/mkimage -A arm -O linux -T script -C none -a 0 -e 0 -n "My script" -d u-boot.txt u-boot.scr" There is another way to get the u-boot.scr script file to work, which allows you to bypass using the mkimage command. When you see this prompt: Hit any key to stop autoboot: 0 Hit a key to stop the boot process. You will be at the bootloader prompt. Then just type in the commands from the u-boot.txt file, one line at a time. Once that works, then there is a way to save these commands in the environment so you don't have to re-type them each time the system boots. - Altera_Forum
Honored Contributor
I found some documentation that explains how to use mkimage for creating the u-boot.scr file (URL has * instead of / to get past spam filter):
www . denx.de * wiki * view * DULG * UBootScripts At the bootloader prompt, can you type "printenv" and attach the output as an attachment? - Altera_Forum
Honored Contributor
Hi austin, hi aignacio
I post in this thread since I think I'm stuck in a similar situation and I hope someone of you can help me. I have a cyclone V de0 nano soc board and I want to boot a bare metal application from SD card. This is what I could do so far: - I built a working baremetal application and I can debug via jtag - I created the u-boot.scr script file to load fpga configuration and baremetal application - I copied the .scr on SD card and it get executed, as I can see in the serial port output log - during the boot process, FPGA can successfullly configure from the .rbf file I copied in the FAT partition of SD card - when the script tries to load the application (fatload mmc 0:1 0x00100040 app_image.bin) I clearly get an error, since I still don't have the app_image.bin which is supposed to contain my application. The point is that I don't understand how to generate it from the .axf file I get from the build tools! I read this and other threads and I believe I simply need this .bin file on the SD card I used objcopy as someone suggested, but this creates a 4GB file! Moreover mkimage then tells me it can't read it. I'm missing some point? - Altera_Forum
Honored Contributor
--- Quote Start --- Hi austin, hi aignacio I post in this thread since I think I'm stuck in a similar situation and I hope someone of you can help me. I have a cyclone V de0 nano soc board and I want to boot a bare metal application from SD card. This is what I could do so far: - I built a working baremetal application and I can debug via jtag - I created the u-boot.scr script file to load fpga configuration and baremetal application - I copied the .scr on SD card and it get executed, as I can see in the serial port output log - during the boot process, FPGA can successfullly configure from the .rbf file I copied in the FAT partition of SD card - when the script tries to load the application (fatload mmc 0:1 0x00100040 app_image.bin) I clearly get an error, since I still don't have the app_image.bin which is supposed to contain my application. The point is that I don't understand how to generate it from the .axf file I get from the build tools! I read this and other threads and I believe I simply need this .bin file on the SD card I used objcopy as someone suggested, but this creates a 4GB file! Moreover mkimage then tells me it can't read it. I'm missing some point? --- Quote End --- Hello Cris72, to generate the .bin file you'll need to use this command after generate your .axf: arm-altera-eabi-objcopy -o binary baremetal.axf baremetal.bin Also as I was stucked in this generation steps, I decided to make a big tutorial for my blog to explain all the process after understand the required files to generate a bootable SD card. As my post is not complete yet I'll paste here a preview that's only accessible through this link (https://blog.aignacio.com/p/b0ed896e-9982-4b40-a3e9-cc8cabea31ff/), try to read my tutorial and check if this could help you through the steps and if you find any error just reply. :) - Altera_Forum
Honored Contributor
Hello ignacio
Thank you very much for your kind answer. I don't have time now to read your tutorial, but at first glimpse it seems very interesting. I'll do it next monday. Regarding the arm-altera-eabi-objcopy command line, I understood this is what I'm supposed to use. But, as I wrote in my post, this generates the full 4GB addressable memory image, and the file is useless. I guess that this happens because my axf file contains both sections in the 0-0x100000 memory range (mainly sdram) and sections in the 0xFFFF0000-0xFFFFFFFF range (I think these are for SoC onchip ram and memory mapped registers, am I right?), then objcopy creates an image from the lowest address 0 to the highest 0xFFFFFFFF, although a miminal part is actually relevant. Infact if I exclude sdram or if I include a single memory section (objcopy options -j or -R) the bin file generates with the correct memory size. I also tried to generate separate files for each memory section and tried to manually load them with the 'fatload' command: using the debugger I can see the memory gets correctly loaded with the bin data, but I really don't know if I'm placing this section where they are supposed to be. Moreover I have no idea where my code must start from: I tried a go 0x00100040, but nothing seems to happen. - Altera_Forum
Honored Contributor
Cris72,
I think your observation about the onchip ram is correct. In my application, I only have symbols defined in the onchip ram at 0xffff0000 and don't allocate any data or code in that space. That allocation is done in the linker script. I guess that's the reason why the .axf file and resulting .bin file don't contain data/code that needs to be initialized in that space. You can check for the condition you mention in the .axf file, with the following command: arm-altera-eabi-objdump -x <name of axf file> In my case, I get these sizes for the various sections in my .axf file. Note that the size is zero for the oc_ram sections. Sections: Idx Name size VMA LMA File off Algn 0 .text 0001df74 00100040 00100040 00010040 2**6 CONTENTS, ALLOC, LOAD, READONLY, CODE 1 .eh_frame 00000004 0011dfb4 0011dfb4 0002dfb4 2**2 CONTENTS, ALLOC, LOAD, READONLY, DATA 2 .ARM.exidx 00000008 0011dfb8 0011dfb8 0002dfb8 2**2 CONTENTS, ALLOC, LOAD, READONLY, DATA 3 .rodata 00000f08 0011dfc0 0011dfc0 0002dfc0 2**3 CONTENTS, ALLOC, LOAD, CODE 4 .cs3.boot_rom 00000000 fffd0000 fffd0000 0002f9c0 2**3 CONTENTS 5 .cs3.boot_rom.bss 00000000 fffd0000 fffd0000 0002f9c0 2**0 CONTENTS 6 .cs3.oc_ram 00000000 ffff0000 ffff0000 0002f9c0 2**3 CONTENTS 7 .cs3.oc_ram.bss 00000000 ffff0000 ffff0000 0002f9c0 2**0 CONTENTS .... - Altera_Forum
Honored Contributor
Thank you for your answer austin944.
I followed your advice and I made a great step forward, although I'm still not able to boot the application. I changed the linker file and mapped all the oc_ram sections to sdram, i.e. at positive address. Now all sections in 0xffff0000 have zero size like in your example and infact I can now generate an image file with a reasonable size! I'm now stuck on another weird point. I created the following img file with mkimage an put it on sdcard. It gets loaded into sdram but, if I inspect memory after the fatload command, I see the data (which is correct) is misplaced. To me it seems an endianess problem, since I see the low and high words swapped. For example, at address 0x100000 I'm supposed to have 0xE59F F018, but I find 0xF018 E59F - Altera_Forum
Honored Contributor
Here is something else I've discovered.
Regarding the endiannes problem, the data is shown as misplaced only in the disassembly window of the usb-blaster debugger. The data appears to be ok in the memory window of the debugger or if I dump the memory with the md command from the serial port interface. Which is correct? The section gets loaded starting at memory address 0x100040, no matter the address I specify in linker or in mkimage. Instead, if I directly load the bin file generated by objcopy, without using mkimage, it loads correctly (i.e. isr vector table at 0x100000 and cs3_reset at 0x100040) What's the actual difference between objcopy and mkimage ouput? **** discard this part: this was my error; see my following post The last point is not completely true, because between interrupt vector and cs3_reset I always find a stray code 0xEA00024 which shifts all the remaining part to higher addresses. I mean: 0x100000 : interrupt vector 0x100040 : stray data 0xEA00024 ??? 0x100044; cs3_reset + cs3_start_c code which is supposed to be @0x100040 **** I'm very puzzled of this. I hope someone can explain me