Hi Wolfgang,
On Wed, 12 Nov 2003, Wolfgang Denk wrote:
In message Pine.CYG.4.55.0311121116060.828@sniper.ultra.si you wrote:
There is no real limit on the size of the image's segments, but due to the broken memory layout of the ARM you have to be careful where you place your image in RAM, and for other memory mapping details like stack size.
memory map for this board:
...
0xA000 0000 - 0xA1FF FFFF (32 MiB) SD-RAM - 0xA3FF FFFF (64 MiB)
And where did you place the U-Boot image? What's the stack size?
I'm downloading U-boot to 0x00000000 (FLASH), but it's relocating to 0xa1fe0000 (TEXT_ADDRESS).
Stack size: #define CONFIG_STACKSIZE (120<<10) /* stack size */
That tells me it's in _undefined_instruction, if I'm not mistaken. But 0xa1fe003c is making me confused since it's _fiq. Does that mean that the interrupt has been raised ?
Another explanation is that you're attempting to run bogus code as a result of stack corruption.
[ - snip - ]
Answer this question yourself: is a C function supposed to have a valid stack pointer or not?
yes Sir, but I might not know everything that could be used/is a valid hack.
I'm used to debug regular programs and if I enter a function, backtrace will always show all the stack frames. Am I missing something here or is that saying that the stack is corrupt ?
2 x yes.
I've also noticed that after running "help help" command, the run_command is executed and has a valid cmd ptr. But when the function processes the input parameters (calling processes_macros and then parse_line) the cmd ptr points to 0x0. This indicates that the stack is being corrupted, am I right ?
I will investigate the stack setup and will get back on that.