[U-Boot-Users] U-Boot hang
Hi everybody,
I'm in the process of writting PCMCIA support for WEPEP250 (boards/wepep250). Everything seems to be going smooth except one thing:
When I add a debug function and then execute U-Boot command "pinit on" or "ide reset" U-boot hangs on me. I sometimes get "data abort", sometimes "invalid instruction" and sometimes nothing.
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 ?
The situation: ident_cpy() function used in ide_ident() copies firmware, version, ident string from iop structure to dev_desc structure. Since CompactFlash firmware string and model number string are in big endian byte order I wanted to write ident_swap_cpy, but as I wrote the function, re-compiled U-boot, downloaded it and issued "ide reset" I got a hang. I also tried to put just two printf's inside ident_copy() - a hang again.
ident_swap_cpy() worked fine when I compiled and ran it in my examples/ide.c file.
Thanks,
Dear Leon,
in message Pine.CYG.4.55.0310291622220.996@sniper.ultra.si you wrote:
I'm in the process of writting PCMCIA support for WEPEP250 (boards/wepep250). Everything seems to be going smooth except one thing:
When I add a debug function and then execute U-Boot command "pinit on" or "ide reset" U-boot hangs on me. I sometimes get "data abort", sometimes "invalid instruction" and sometimes nothing.
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.
For example, we just fixed a problem in the VFAT filesystem code which would allocate 3 x 64 kB buffers on the stack - this works perfectly fine on PowerPC, but causes a nasty stack overrun situation on most ARM systems.
byte order I wanted to write ident_swap_cpy, but as I wrote the function, re-compiled U-boot, downloaded it and issued "ide reset" I got a hang. I also tried to put just two printf's inside ident_copy() - a hang again.
Well - attach a debugger and check where it's hanging. And check where your stack pointer is pointing to.
Best regards,
Wolfgang Denk
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,
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?
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.
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 ?
Answer this question yourself: is a C function supposed to have a valid stack pointer or not?
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.
Best regards,
Wolfgang Denk
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.
In message Pine.CYG.4.55.0311121218030.828@sniper.ultra.si you wrote:
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).
0xA1FFFFFF - 0xa1fe0000 = 128 kB.
Stack size: #define CONFIG_STACKSIZE (120<<10) /* stack size */
How do you manage to squeeze 120k of stack AND the U-Boot image in a total of 128 kB?
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.
When U-Boot is running from RAM it expects a normal C environment including a unlimited stack (well, in theory at least).
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 ?
Right.
I will investigate the stack setup and will get back on that.
Try what happens when setting TEXT_BASE = 0xA1F00000 ...
Best regards,
Wolfgang Denk
Hi Wolfgang and the gang,
On Wed, 12 Nov 2003, Wolfgang Denk wrote:
0xA1FFFFFF - 0xa1fe0000 = 128 kB.
Stack size: #define CONFIG_STACKSIZE (120<<10) /* stack size */
How do you manage to squeeze 120k of stack AND the U-Boot image in a total of 128 kB?
I don't know, I'm fairly new to the U-Boot 'level' of programming so I left it untouched. But I see the point here.
Try what happens when setting TEXT_BASE = 0xA1F00000 ...
I've set it to 0xA1000000 to be on a safe side and it works. I still have to find if my debugger is showing me correct values or not, $sp seems to be 0x0 all the time, but the code works ? BTW, thanks for your help.
Since these questions are really adressing memory layout I would like to clarify some of the things myself. I was searching for documentation of U-Boot memory layout for ARM in README and could not find none. Therefore I'm asking you guys to verify the following diagram and update the things that are missing and or are incorrect. This will hopefully help all new guys, like me, joining the U-Boot project.
startup: 0x00000000 is FLASH
0x00000000 .--U-Boot start--. ------------------------------------. . | code | | . | code | | 0x00018ce4 |---U-Boot End---| (u-boot.bin size: 101604 bytes) | . | | | . | | | | U-boot code is relocated to TEXT_ADDRESS as the arrow shows --------> | | 0x00000000 .----------------. | | | FLASH | | | | | . . | . . | | | | | 0xA0000000 |----------------| RAM START | | | | | . Free . | . Memory . | For | | Malloc | | | | | |---STACK END----| | | stack | | | stack | | 0xA1FE00000 |--TEXT_ADDRESS--|<------------------------------------' | code | | code | 0xA1FFFFFF `---U-Boot End---' RAM END
What direction does the stack grow ? From STACK END up(greater address) to TEXT_ADDRESS or from TEXT_ADDRESS down(lower address) to STACK END ?
Thank you all.
participants (2)
-
Leon KUKOVEC -
Wolfgang Denk