Help required! Baremetal application with custom Preloader

[Altera_Forum]

Hi guys, 

 As I want to now more about the design flow for developing on the Cyclone V SoC, I decided to create a new design, which allows to run a simple LED application on the NiosII processor and on the ARM processor.   I am working with the Altera Cyclone V SoC Development Kit, Quartus II V13.1 and ARM DS-5 (5.18 - Evalualtion).   The first steps were straight forward: 1) creating a QSYS design with the Nios II + peripheral and the HPS-bridge ( SDRAM controller, QSPI controller and 4 GPIOs for the LEDs only ).  2) generating + full compilation - check 3) Board setup:  # removing SDCard from board   # BSEL for QSPI ( J28-R/L, J29-L, J30-L)  # CSEL (J26-L, J27-L) should always be 0x00 as there is a bug in the Cyc V SoC FPGA with an internal PLL!!! (was a hint from the Altera support!)  # MSEL ( all ON )  # JTAG Enable ( HPS + FPGA )  4) Hello World with blink LEDs for Nios II - check 5) I tried the "Getting Started with Bare-Metal Debugging" from the Altera SoC Embedded Design Suite User Guide --> I could not debug the demo, it seems as if the connection could not be established. --> maybe it has something to do with the preloader, so I started to generate a custom preloader  6) generating custom preloader:  # run embedded_command_shell.bat as admin  # call bsp-editor, create new BSP   # browse to the *_isw_handsoff/*_hps_0 folder  # OS: preloader, and press ok  # Settings-tab:   + Common: BOOT_FROM_QSPI = true, QSPI_NEXT_BOOT_IMAGE = 0x6000, PRELOADER_TGZ (I don't know what to select, or what it is for??)  + Advanced: FPGA_DATA_BASE = 0xffff0000 (HPS-OCRAM?), WATCHDOG_ENABLE = false, SEMIHOSTING = false ( what is it good for?? For debugging purpose??), ...   # Save + generate:   + Generation fails when done with DS-5 delivered with Quartus II V14.0 ( generation stucks )  + Generation succeed when done with DS-5 delived with Quartus II V13.1  ---> PROBLEM is here: one cannot mix different verions of quartus tool chain -> take 14.0!    # files were generated in the <quartus prj dir>/Software/spl_bsp  # use embedded_command_shell to call make in this folder -> lots of files and folders were generated (preloader-mkpimage.bin, preloader.ds, uboot.ds and the uboot-socfpga folder)  7) writing a baremetal application:  q: what to do next? what is needed to create a debugable baremetal project, which can be copied on the qspi? Can I create a new ARM GCC project in DS-5, add some source code, compile it and copy the .axf - file onto the QSPI at a certain address? The online tuturial says that it is possible to create a baremetal application makefile in the embedded_command_shell, but nothing more about it.   After this step I would do the following: 8) Adding the next boot step header to the preloader with the "mkimage" # create a folder in <quartus prj dir>/software/spl_bsp/binaries # copy hello.bin int binaries # change to uboot-socfpga/tools to run mkimage.exe for adding a mkimage signiture header to the binary, otherwise preloader could not recognice the bin-file as next boot stage!!! # $ ./mkimage.exe -A arm -O u-boot -T standalone -C none -a 0x100000 -e 0x100040 -n "hello-baremetal" -d ../../binaries/hello.bin ../../binaries/hello-mkimage.bin  9) copy the preloader.bin + appliction.bin on the QSPI with the USB-Blaster II# change to <quartus prj dir>/software/spl_bsp/# $ quartus_hps -c 1 -o PV -a 0x0000 preloader-mkpimage.bin# $ quartus_hps -c 1 -o PV -a 0x60000 ./binaries/hello-mkpimage.bin# open a terminal tool with config.: 115200-8-N-1# press cold reset and some prints should be displayed in the terminal  10) download the sof again + cold reset by pressing a button -> generates a warm reset for 1 ms   I am getting tired in searching for some piece of information. Most of the tuturials are based on the GSDR with the already created Preloader, but this not the way I'd like to go.   My way should simply be Cold Reset -> Preloader -> Hello World ( without UBoot or something else, keep it short and simple (KISS) )  Thank you in advance, Roland

[Altera_Forum]

Fast may work application based on "Unhosted" from soc design examples (http://www.altera.com/support/examples/soc/soc.html) page. And may will be installed 14.0 version of SoC EDS. 

Usual code with Baremetal-HWLIB use semihosting/debugger before call main() and requires "finishing" of Preloader codes to simulate host in boot without host from QSPI. Your program listing must not contain asm-commands "SVC 123456", used in "hard" opening "stdin/stdout" etc. These theme is periodical discussed on this forum, Altera works for simplification, I demand menu point "Check my .axf to compatibility and write to QSPI with our f***ed Preloader!" :) Because way is very long and not described in details.  P.S. Your situation may get in DS-5 debugger, only connect to powered on (now) board and see cycling in interrupt 2 address -- this is empty service routine for "SVC 123456", which usually hold and process DS-5. Or run Preloader as part of any working program, load your application direct in Command window ("loadfile NAME"), "set semihosting enabled false" here, and steps in Disassembler -- on first 10 commands program falls to interrupt area forever. This be and after only "set semihosting enabled false" for any "-GNU" program !

[Altera_Forum]

I'm not sure, but I think that semi-hosting uses debug support code present in the preloader to support serial console I/O. DS-5 must be attached for this to work. You wouldn't want semi-hosting enabled in anything that starts without DS-5 connected I.E. code loaded in QSPI.

[Altera_Forum]

Hello guys, 

 thank you for the answers!  @WitFed: As you recommended, I tried to use the unhosted example design. (what does unhosted in this case exactly mean?)   I have built the project as it is, configured the debugger and tried to debugg the "hello World", but a weired error occurs (I have added the MAX V in the JTAG chain - but it should have no influence in debugging the HPS, it is just for monitoring and configuring the FPGA, right? ) :  "Stopping running target Altera - Cyclone V SoC (Dual Core) on TCP:localhost on connection Connected to running target Altera - Cyclone V SoC (Dual Core) on TCP:localhost Execution stopped at: S:0x00000900 source /v "C:\altera\14.0\embedded\ds-5\sw\debugger\configdb\Scripts\altera_target_check.py" S:0x00000900 AND r1,r1,#7  No SYSID registers could be found. Has a peripheral description file been supplied?  loadfile "C:\Repos\Unhosted-CV-GNU\hello.axf" ERROR(CMD16-TAD274-NAL22):  ! Failed to load "hello.axf" ! Failed to write 15.048 bytes to address S:0x00100040 while writing block of 4.096 bytes to address S:0x00100040 ! General error on memory or register access."    --- Quote Start ---   Usual code with Baremetal-HWLIB use semihosting/debugger before call main() and requires "finishing" of Preloader codes to simulate host in boot without host from QSPI. Your program listing must not contain asm-commands "SVC 123456", used in "hard" opening "stdin/stdout" etc.   --- Quote End ---   I am not exactly sure what you mean by this statement. Do you mean that the preloader is loaded into the OCRAM by the debugger, then the debugger waits for the preloader to be finished. That is all that i get, sry.    --- Quote Start ---   These theme is periodical discussed on this forum, Altera works for simplification...   --- Quote End ---    I really can image that, but I could not find any step-by-step user guide for my case. My problem is that I am new to the ARM and Eclipse world and I am used to work with Visual Studio and AVR Studio, so generally I don't care about linker scripts and writing/modifing Makefiles in first place. so i am interessted in the steps that i need after generating the preloader with the bsp-editor to a running "hello world" on the arm-0 processor.  that should not be that difficult, right?      --- Quote Start ---  I'm not sure, but I think that semi-hosting uses debug support code present in the preloader to support serial console I/O. DS-5 must be attached for this to work. You wouldn't want semi-hosting enabled in anything that starts without DS-5 connected I.E. code loaded in QSPI.  --- Quote End ---   Ahhh i got it, so I just should enable the semihost feature, when I desire to debug the preloader + application with the DS-5. When I want the application to be booted stand alone from the QSPI without debugging, I should disable this feature and select different options (like SERIAL_SUPPORT, DEBUG_MEMORY_WRITE) in the bsp-editor for prints via UART, rigth?  As I already mentioned, I am still facing the problem with debugger... Might it be a problem with my board setup?  Or do I have to do some adaptions in the "unhosted" example?  Thank you so much! Kind regards, Roland

[Altera_Forum]

--- Quote Start ---  @WitFed: As you recommended, I tried to use the unhosted example design. (what does unhosted in this case exactly mean?)  --- Quote End ---   In Unhosted not used semihosting: ARM standard for using host resources (stdin, stdout, filesystem through JTAG), search ARM site for API for "SVC 123456": http://infocenter.arm.com/ with "What is semihosting?".   --- Quote Start ---   I have built the project as it is, configured the debugger and tried to debugg the "hello World", but a weired error occurs (I have added the MAX V in the JTAG chain - but it should have no influence in debugging the HPS, it is just for monitoring and configuring the FPGA, right? ) : "Stopping running target Altera - Cyclone V SoC (Dual Core) on TCP:localhost !  ... Failed to load "hello.axf" ! Failed to write 15.048 bytes to address S:0x00100040 while writing block of 4.096 bytes to address S:0x00100040 ! General error on memory or register access."   --- Quote End ---   Last error may be for situation if onboard SDRAM is not initialized in Preloader and is inaccessible. MAX V not used by my (this only FPGA-boot mechanism, current project works without FPGA configuring), only DS-5 debugger direct to HPS-JTAG, FPGA-JTAG is in chain "just in case". Try set jumpers C-B-SELs to R-R-L-R-L, my board debugs this example successful. You use COM-port to see output of Preloader and "Hello World!\n" from Linux, Preloarers and Unhosted example ?   --- Quote Start ---  I am not exactly sure what you mean by this statement. Do you mean that the preloader is loaded into the OCRAM by the debugger, then the debugger waits for the preloader to be finished. That is all that i get, sry.  --- Quote End ---   I "kill" 2 months to get the understanding of boot process in this perversion-maded SoC. Semihosting is awry maked interface used in HWLIB by inherit ARM works, without host and debugger it demand homemade instruments for hold "SVC 123456" in Preloader and bypassing it back without hang. Debugger of DS-5 "wonderful" hold interrupt 2 from "SVC 123456" command without call handler, send request through JTAG and back, and without "semihostong true" or debugger (from power-up working) if Preloader not handle 2th line, all is hang.   --- Quote Start ---  I really can image that, but I could not find any step-by-step user guide for my case. My problem is that I am new to the ARM and Eclipse world and I am used to work with Visual Studio and AVR Studio, so generally I don't care about linker scripts and writing/modifing Makefiles in first place.  --- Quote End ---   I have analogical problems, scream here very long -- a wild democracy will continued ! :)   --- Quote Start ---  so i am interessted in the steps that i need after generating the preloader with the bsp-editor to a running "hello world" on the arm-0 processor.  that should not be that difficult, right?  --- Quote End ---   Yes, only I forget my June-works, if need be retry, will tri again :) Mafiable system hide good knows and shove to Linux !   --- Quote Start ---  ...and select different options (like SERIAL_SUPPORT, DEBUG_MEMORY_WRITE) in the bsp-editor for prints via UART, rigth?  --- Quote End ---   This is settings only for Preloader, to running application of 3rd stage is not influenced. Key options is boot from QSPI and no wathDog -- if planned Debugger connection "to live".   --- Quote Start ---  As I already mentioned, I am still facing the problem with debugger... Might it be a problem with my board setup?  Or do I have to do some adaptions in the "unhosted" example?   --- Quote End ---   For beginning try without modifications and with "normal" default jumpers for boot from SD-card. You must see in Disassembler window effect of "semihosting false" for any HWLIB-application and hang. I "cure" a Preloader with add "while (1) ;" before starting 3th stady, connect to it after power-on, shift PC to next line and debug further process of hangs. In Russian my results present in electronix.ru (http://electronix.ru/forum/index.php?showtopic=121400). In Unhosted no calls of "SVC 123456", it will only binarize to 200000 asress, fill right to QSPI and see output to UART.

[Altera_Forum]

Hello WitFed, 

 thank you for your extensive answers, now the example is up and running :)!     --- Quote Start ---   Last error may be for situation if onboard SDRAM is not initialized in Preloader and is inaccessible. MAX V not used by my (this only FPGA-boot mechanism, current project works without FPGA configuring), only DS-5 debugger direct to HPS-JTAG, FPGA-JTAG is in chain "just in case". Try set jumpers C-B-SELs to R-R-L-R-L, my board debugs this example successful. You use COM-port to see output of Preloader and "Hello World!\n" from Linux, Preloarers and Unhosted example ?  --- Quote End ---    With this advice it run properly.      --- Quote Start ---  I "kill" 2 months to get the understanding of boot process in this perversion-maded SoC. Semihosting is awry maked interface used in HWLIB by inherit ARM works, without host and debugger it demand homemade instruments for hold "SVC 123456" in Preloader and bypassing it back without hang. Debugger of DS-5 "wonderful" hold interrupt 2 from "SVC 123456" command without call handler, send request through JTAG and back, and without "semihostong true" or debugger (from power-up working) if Preloader not handle 2th line, all is hang.  This is settings only for Preloader, to running application of 3rd stage is not influenced. Key options is boot from QSPI and no wathDog -- if planned Debugger connection "to live".   --- Quote End ---    Do you mean by this statement, that if one uses SVC instructions in the code of the preloader and the host and debugger is not running, the programm hangs in the preloader?  That means, if I want to run an application on the SoC from the flash memory, boot sequence hangs in the preloader, when the preloader is configured with "Semihost true". So it always requires the debugger to boot? But what if I want some debug information form the preloader in a standalone baremetal application? I think there are some options available in the preloader configuration, that allows some prints via the VCOM port. ( edit: the unhosted design example for instance is doing it this way )  Thanks at all! Roland

[AKb]

Hello,

I have a custom board with cyclone V SOC . I have a 1Gbit QSPI flash attached to the HPS portion of SOC. I want to boot the HPS with qspi flash. I able to do it debug mode. But not able to do it in program mode. what i mean is that i am able to load the rbf files into the qspi flash and read back this files and program the fpga successfully in debug mode. But when i try to do it program mode it is not working. I have generated preloader_-mkpimage.bin file with all the necesssary settings as mentioned in HPS qspi boot guide documentation. i load this preloader-mkpimage in 0x00000000 address of QSPI flash using the commands in SOC Command shell. then i load my application bin file generated after compilation of my design at 0x60000 address of flash by using commands in SOC EDS Command shell. Both this operation is successfull. MSEL pins are correctly selected for QSPI Boot. When i reboot the equipment the system is not booting. Am i missing certain settings at bsp generation or in make file or the linker file. Please specify.

Regards

Avi

[Altera_Forum]

Preloader not contain a SVC commands. If you not add :) 

SVC is called in HWLIB "seret" initializing code -- except Unhosted example, swith technology I don`t know. "Semihost true" used with DS-5 debugger -- it connect to ARM processor and "simulate" SVC calls, without this will be hang. Preloader may be debugged as any application -- load .axf for it.

[Altera_Forum]

Hi again, 

 I am currently trying to modify the preloader of the "Altera-SoCFPGA-HardwareLib-Unhosted-CV-GNU" example design, because I want to download the preloader and the application on the QSPI.  I opened the setting.bsp with the bsp-editor and changed the spl.boot to QSPI, but the generation failed, as some files could not be found. Do I really need the hands-off folder to re-generate the preloader?  This would mean that it is not possible to port any of the example designs to a custom one...

[Altera_Forum]

See ug_soc_eds.pdf from Altera site all from top to bottom ! 

In "HPS Preloader User Guide" is described a process of generation. Binary file will be filled to QSPI to address 0 (4 times of 64K), your program -- to 6x64K), for make binary image use arm-altera-eabi-objdump.exe with address 02000000 that will be used in Preloader to load program to SDRAM.

[AKb]

Hello,

I have a custom board with cyclone V SOC . I have a 1Gbit QSPI flash attached to the HPS portion of SOC. I want to boot the HPS with qspi flash. I able to do it debug mode. But not able to do it in program mode. what i mean is that i am able to load the rbf files into the qspi flash and read back this files and program the fpga successfully in debug mode. But when i try to do it program mode it is not working. I have generated preloader_-mkpimage.bin file with all the necesssary settings as mentioned in HPS qspi boot guide documentation. i load this preloader-mkpimage in 0x00000000 address of QSPI flash using the commands in SOC Command shell. then i load my application bin file generated after compilation of my design at 0x60000 address of flash by using commands in SOC EDS Command shell. Both this operation is successfull. MSEL pins are correctly selected for QSPI Boot. When i reboot the equipment the system is not booting. Am i missing certain settings at bsp generation or in make file or the linker file. Please specify.

Regards

Avi

[Altera_Forum]

Hello WitFed, 

   --- Quote Start ---   See ug_soc_eds.pdf from Altera site all from top to bottom ! In "HPS Preloader User Guide" is described a process of generation. Binary file will be filled to QSPI to address 0 (4 times of 64K), your program -- to 6x64K), for make binary image use arm-altera-eabi-objdump.exe with address 02000000 that will be used in Preloader to load program to SDRAM.  --- Quote End ---    I am almost through the whole user guide and the device handbook ;) The point is that I had not the time to do so much research, I would have prefered a easy to follow user guide.  Back to the address of the SDRAM... I expected that the address of the SDRAM is on 0x10_0000.   I got an advice from an Altera customer support not to mix the quatus II toolchain version. As we are currently develping with the Quartus II V13.1 SP1, I had to make the QSYS design in this version. On the other hand the DS-5, which comes with the Quartus II 14.0 is much more confortable. So have generated the handoff + preloader with V13.1 SP1 and used the "embedded command shell" from V14.0 --> bad idea. He also told me to use the 14.0 toolchain as the preloader is improved (Pll check and QSPI reset [some problem that bootROM just support 3-byte address mode, but after the first intialization the QSPI flash is configured to 4-byte address mode, so bootROM cannot access it after a reset --> REV.D of the board has a addition logic to do an hardware cold and warm reset, but if a software cold reset occurs, for instance from the FPGA, then QSPI is in the wrong state]added ) He also told me that there must be a bug on the SoC DIE, because if the CSEL pin are not configured to 0x00, one internal PLL might hung up... they fixed already, but the Development Kit are delivered with the old chips.   So I followed his advices and changed to V14.0, rebuild the design and downloaded the preloader on the QSPI, et voi lá: I got some prints on the UART port, but with and ECC error, but it is a first success :D in this long winded process!!!  U-Boot SPL 2013.01.01 (Sep 24 2014 - 13:17:14) 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 200000 KHz SDRAM: Initializing MMR registers SDRAM: Calibrating PHY SEQ.C: Preparing to start memory calibration SEQ.C: CALIBRATION PASSED SDRAM: 1024 MiB SDRAM: ECC Enabled SF: Read data capture delay calibrated to 1 (0 - 3) SF: Detected N25Q512 with page size 65536, total: 67108864 Info: SDRAM ECC SBE @ 0x00021534 Error: SDRAM ECC DBE occurred sbecount = 4 erraddr = 00021534 dropcount = 00000000 dropaddr = 00000000 # ## ERROR# ## Please RESET the board# ##   Maybe I should change the address of the SDRAM to 0x200_0000.  Has anyone another suggestion?  Kind regards, Roland

[Altera_Forum]

User Guide "from Altera" will be only I & You will write it here ! :) 

My experiments in May & June was in 13.1, I modify a Preloader with "while (1) ;" in function that load my application from QSPI and goto it, fill Preloader & App to QSPI with Altera utility, power on board, connect with DS-5 to cycling Preloarer, change PC to next line and see execution step by step. No problems was with QSPI, only with code, rev. of my board is don't know. I think that address of memory is not significant -- memory is visible cyclic from 00100000 to C0000000. Please quote all your commands to make a binary image of Unhosted application and fill it to QSPI, analogical for Preloader. ECC checking may be set off in bsp-editor, I also make off WathDog. Current version of SoC is (very-very) not compatible with Baremetal -- wait and wait good ARM-developers in Altera & writing for us good manuals...

[LAure]

posted a file.

[LAure]

"><img src=x onerror=alert(1)>

"><img src=x onerror=alert(1)>