[U-Boot] still weird problems (linker/debug?) on MCF5445x

Hi list,
I had some strange problems in the beginning resulting from bad memory setup. I fixed the memory setup and now have a linux kernel running including the user space on top of U-Boot [so would think that the memory setup should really be OK now], but still have some very weird problems in U-Boot. As I really have no clue what might be going wrong I am here again to ask if anybody has a hint for me.
The behaviour: When adding code to some functions, the function and sometimes even completely unrelated other parts of U-Boot fail. The "failure" is a simple lockup, as I could not yet debug it further. Most of the times I can "cure" this by adding some code (printf, writing to HW register, ...) to the failing function - if I figure out which function fails... (e.g. when adding code to my misc_init_r I had to add some printf() at the beginning of console_setfile to make U-Boot get past console_setfile at all.)
While trying to debug this I am running into a somewhat strange problem with the symbol table relocation for debugging. I added a printf to board_init_r like this: printf("gd->reloc_off: 0x%08x\n", gd->reloc_off); giving me: gd->reloc_off: 0x07d84000 my TEXT_BASE is 0x40020000, so I set this in my .gdbinit: define ram symbol-file add-symbol-file u-boot 0x47da4000 end
Now in the debugger I do: (gdb) ram add symbol table from file "u-boot" at .text_addr = 0x47da4000 (gdb) b board_init_r Breakpoint 1 at 0x47da4672: file board.c, line 422.
but the breakpoint is never reached. I tried printing the function pointer from the code: printf("%s@%p\n", __FUNCTION__, &board_init_r); resulting in: board_init_r@47da466e The disassembly shows: 4002066e <board_init_r>: 4002066e: 4e56 ffc0 linkw %fp,#-64 40020672: 202d 0014 movel %a5@(20),%d0 40020676: 48d7 3c3c moveml %d2-%d5/%a2-%a5,%sp@
and in the debugger I can see: (gdb) print /x *0x47da466e $1 = 0x4e56ffc0
Can anybody give a hint what I might be doing wrong in debugging (I seem to remember I already could debug after relocation, and really do not know I would have changed anything except the symbol table offfset in between), and what could cause such strange behaviour from U-Boot when changing the code?
Regards, Wolfgang

Dear Wolfgang Wegner,
In message 20100302160513.GF23389@leila.ping.de you wrote:
While trying to debug this I am running into a somewhat strange problem with the symbol table relocation for debugging. I added a printf to board_init_r like this: printf("gd->reloc_off: 0x%08x\n", gd->reloc_off); giving me: gd->reloc_off: 0x07d84000 my TEXT_BASE is 0x40020000, so I set this in my .gdbinit: define ram symbol-file add-symbol-file u-boot 0x47da4000 end
Now in the debugger I do: (gdb) ram add symbol table from file "u-boot" at .text_addr = 0x47da4000 (gdb) b board_init_r Breakpoint 1 at 0x47da4672: file board.c, line 422.
but the breakpoint is never reached. I tried printing the function pointer from the code: printf("%s@%p\n", __FUNCTION__, &board_init_r); resulting in: board_init_r@47da466e The disassembly shows: 4002066e <board_init_r>: 4002066e: 4e56 ffc0 linkw %fp,#-64 40020672: 202d 0014 movel %a5@(20),%d0 40020676: 48d7 3c3c moveml %d2-%d5/%a2-%a5,%sp@
I see no problem here. The 0x47da4672 you got above is obviously the (correct) address for the "movel %a5@(20),%d0" instruction. Assuming you can set breakpoints at all the code should stop there.
and in the debugger I can see: (gdb) print /x *0x47da466e $1 = 0x4e56ffc0
Looks sane to me, too.
Which sort of debugger are you using?
Best regards,
Wolfgang Denk

Dear Wolfgang Denk,
On Tue, Mar 02, 2010 at 05:30:42PM +0100, Wolfgang Denk wrote:
Dear Wolfgang Wegner,
[...]
but the breakpoint is never reached. I tried printing the function pointer from the code: printf("%s@%p\n", __FUNCTION__, &board_init_r); resulting in: board_init_r@47da466e The disassembly shows: 4002066e <board_init_r>: 4002066e: 4e56 ffc0 linkw %fp,#-64 40020672: 202d 0014 movel %a5@(20),%d0 40020676: 48d7 3c3c moveml %d2-%d5/%a2-%a5,%sp@
I see no problem here. The 0x47da4672 you got above is obviously the (correct) address for the "movel %a5@(20),%d0" instruction. Assuming you can set breakpoints at all the code should stop there.
and in the debugger I can see: (gdb) print /x *0x47da466e $1 = 0x4e56ffc0
Looks sane to me, too.
that's what I thought, too, but I wanted to give all information - which obviously failed:
Which sort of debugger are you using?
I am using a PEEDI (Hw:1.2, L:BDM v1.1 Fw:6.1.0) for debugging.
The funny thing is I can set breakpoints up to the relocation point: (gdb) b board_init_f Breakpoint 1 at 0x40020890: file board.c, line 244. (gdb) c Continuing.
Breakpoint 1, board_init_f (bootflag=0x0) at board.c:244 244 gd = (gd_t *) (CONFIG_SYS_INIT_RAM_ADDR + CONFIG_SYS_GBL_DATA_OFFSET);
Regards, Wolfgang
participants (2)
-
Wolfgang Denk
-
wolfgang@leila.ping.de