Nios® V/II Embedded Design Suite (EDS)
Support for Embedded Development Tools, Processors (SoCs and Nios® V/II processor), Embedded Development Suites (EDSs), Boot and Configuration, Operating Systems, C and C++
12626 Discussions

Help in DS-5 debug script to load bare metal application into SDRAM address 0

Honored Contributor II

Hi all, 


I made a small application with some minimal startup code (cache invalidate, clear bss and stack region etc). The application does nothing particularly useful in the main loop right now. Anyway, I'm linking loading it at the 1MB address successfully as how the sample codes show. But I want to load and being execution at (arria V) sdram address 0. 


My .ds script is as follows: 


reset system stop wait 30s memory debug-cache off # run the spl so we'll have some SDRAM to work with loadfile "$sdir/u-boot-spl.axf" 0x0 tbreak spl_boot_device run wait # turn off all caches and mmu set $CP15::$System::$SCTLR.I = 0 set $CP15::$System::$SCTLR.Z = 0 set $CP15::$System::$SCTLR.M = 0 # this is set by the SPL anyway# configure l2 cache address filtering range memory set 0xfffefc04 32 0xc0000000 memory set 0xfffefc00 32 0x00000001 loadfile "$sdir/altera-arm-debug.axf" 0x0 tbreak main run  


the above code works if I load at the 1MB (0x0010000) mark, but I'm running into some problems when I link/load at address 0 for some reason. I've also tried steps like 1) flushing the pipeline by writing nop instructions (at 1MB) and executing them a few times before loadfile-ing my application to address 0 to execute and 2) disabling all caches prior to "loadfile" but I still can't get my small application to execute. 


the MEMORY declaration my linker script is as follows: 


MEMORY { /* link at 1MB */ ddr_prog_mem (rwx) : ORIGIN = 0x00100000, LENGTH = 1M /* or link at 0 ddr_prog_mem (rwx) : ORIGIN = 0x00000000, LENGTH = 1M */ }  


to my knowledge, the address below 1MB is definitely there since i also tried doing a  


memory fill 0 0x1000 4 0xDEADC0DE 


in my script to verify that problematic sdram memory range is readable/writable. 


Furthermore, digging through the uboot-spl and uboot objdumps reveal they are all starting at 1MB. Come to think of it, I've never seen any sample code that starts at address 0 for that matter. 


Please enlighten me on the subject matter above. 


Thank you very much. 



aug 02 2015, clarification

I would like to point out that I've no problems loading my application at address 0. The problem is that the application would not run at all and instead an "arbitrary" code is executing when the script reaches the "run" command. I noticed this when I manually tried to start my application from the entry point by doing set $Core:$PC = 0 then stepi; some other "instruction" happens that is not in my entry point. 


there are a couple of things I think are happening; note that these are just unverified hypotheses as of the moment. 


1) the debugger writing to the <1MB range (when downloading my application) causes an exception, which triggers when the processor begins executing. 

2) the pipeline is dirty and there are some stale instructions left from the SPL which needs to be flushed out before running my code. 


Not so sure with# 2 however, since loading and running at 1MB works without any hitches. 


I would be most grateful if someone could just point me to a sample project (code + ds script) that correctly does what I'm trying to do. 


Again, thank you very much. 



aug 04 2015, solved


I'd like to report that I've solved the issue; bit of an oversight with the startup state. Apparently, my codes are all in ARM format but the processor is still in thumb state as shown by the JT bits. what happens is that an undefined exception is being thrown by the entry point instruction and since I still haven't relocated the exception vector, it jumps to the code of the SPL and things go screwy from there on. Anyways, I've done the relevant changes to the DS script to remedy that and things are going okay now. 


How the same code and DS script works when I link at 1MB before, I didn't bother to find out. 


case closed. Thanks.
0 Kudos
0 Replies