[U-Boot-Users] U-Boot hang

[Leon KUKOVEC]

Hi everybody,

On Wed, 29 Oct 2003, Wolfgang Denk wrote:

> > Is there any limits with regards to U-Boot's size and by me putting too much
> > inside U-boot's .text section and hitting some marker/border ?
>
> 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:

0x0000 0000 - 0x01FF FFFF (32 MiB) Synchronous FLASH-ROM
	    - 0x03FF FFFF (64 MiB)
0x0400 0000 - 0x0400 0FFF 8051 type interface
0x2000 0000 - 0x2FFF FFFF CF card, slot 0
0x4000 0000 - 0x4BFF FFFF Registers of the processor
0xA000 0000 - 0xA1FF FFFF (32 MiB) SD-RAM
	    - 0xA3FF FFFF (64 MiB)

[ - snip - ]

> Well - attach a debugger and check  where  it's  hanging.  And  check
> where your stack pointer is pointing to.

After the hang, I interrupted the debugger and did some stepping. Here's
the debugger output:

Program received signal SIGTRAP, Trace/breakpoint trap.
_start () at /home/leonk/cvs-remote/u-boot/cpu/pxa/start.S:40
40              ldr     pc, _not_used
(gdb) list
35      _start: b       reset
36              ldr     pc, _undefined_instruction
37              ldr     pc, _software_interrupt
38              ldr     pc, _prefetch_abort
39              ldr     pc, _data_abort
40              ldr     pc, _not_used
41              ldr     pc, _irq
42              ldr     pc, _fiq
43
44      _undefined_instruction: .word undefined_instruction
(gdb) si
41              ldr     pc, _irq
(gdb)
42              ldr     pc, _fiq
(gdb)
0xa1fe0020      42              ldr     pc, _fiq
(gdb)
0xa1fe0024      42              ldr     pc, _fiq
(gdb)
0xa1fe0028      42              ldr     pc, _fiq
(gdb)
0xa1fe002c      42              ldr     pc, _fiq
(gdb)
0xa1fe0030      42              ldr     pc, _fiq
(gdb)
0xa1fe0034      42              ldr     pc, _fiq
(gdb)
0xa1fe0038      42              ldr     pc, _fiq
(gdb)
0xa1fe003c      42              ldr     pc, _fiq
(gdb)
0x00000004 in ?? ()

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 ?

I did some investigations and here's the backtrace:

[ ---- paste ---- ]
(gdb) where
#0  run_command (cmd=0xa1ff6091 "help", flag=0) at main.c:849
#1  0xa1fe0cfc in main_loop () at main.c:489
#2  0xa1fe0b48 in start_armboot () at board.c:347
#3  0x00000074 in ?? ()
(gdb) list
844             printf ("[RUN_COMMAND] cmd[%p]=\"", cmd);
845             puts (cmd ? cmd : "NULL");      /* use puts - string may be loooong */
846             puts ("\"\n");
847     #endif
848
849             clear_ctrlc();          /* forget any previous Control C */
850
851             if (!cmd || !*cmd) {
852                     return -1;      /* empty command */
853             }
(gdb) info frame
Stack level 0, frame at 0xa1fbdf2c:
 pc = 0xa1fe12ac in run_command (main.c:849); saved pc 0xa1fe0cfc
 called by frame at 0xa1fbdf48
 source language c.
 Arglist at 0xa1fbdf2c, args: cmd=0xa1ff6091 "help", flag=0
 Locals at 0xa1fbdf2c, Previous frame's sp is 0x0
 Saved registers:
  r4 at 0xa1fbdf08, r5 at 0xa1fbdf0c, r6 at 0xa1fbdf10, r7 at 0xa1fbdf14,
  r9 at 0xa1fbdf18, r10 at 0xa1fbdf1c, r11 at 0xa1fbdf20, r12 at 0xa1fbdf24,
  lr at 0xa1fbdf28, pc at 0xa1fbdf2c
(gdb) si
clear_ctrlc () at console.c:287
287             ctrlc_was_pressed = 0;
(gdb) where
#0  clear_ctrlc () at console.c:287
(gdb) info frame
Stack level 0, frame at 0x0:
 pc = 0xa1fe7284 in clear_ctrlc (console.c:287); saved pc 0x0
 (FRAMELESS), source language c.
 Arglist at unknown address.
 Locals at unknown address, Previous frame's sp is 0x0
(gdb)
Stack level 0, frame at 0x0:
 pc = 0xa1fe7284 in clear_ctrlc (console.c:287); saved pc 0x0
 (FRAMELESS), source language c.
 Arglist at unknown address.
 Locals at unknown address, Previous frame's sp is 0x0
(gdb)
[ ---- end of paste ---- ]

I set a breakpoint at run_command, restarted and U-boot stopped correctly.
$sp was 0x0 and info frame showed that local variables were located at
0xa1fbdf2c. The question here is: is $sp supposed to point to some location or
is it OK if it's 0x0 ?

Next thing, after going into clear_ctrlc() and executing 'where', there was
a single stack frame.

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 ?

Thanks,
-- 

Best Regards,
	Leon.