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,