[U-Boot-Users] U-Boot hang

[Leon KUKOVEC]

Hi Wolfgang,

On Wed, 12 Nov 2003, Wolfgang Denk wrote:

> In message <Pine.CYG.4.55.0311121116060.828 at 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.

-- 

Best Regards,
	Leon.