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

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

[Wolfgang Wegner]

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

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

[Wolfgang Denk]

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

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

-- 
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
Death, when unnecessary, is a tragic thing.
	-- Flint, "Requiem for Methuselah", stardate 5843.7

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

[Wolfgang Wegner]

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