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

Wolfgang Wegner wolfgang at leila.ping.de
Tue Mar 2 17:05:13 CET 2010


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 at 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



More information about the U-Boot mailing list