[U-Boot-Users] Debugging u-boot on a custom 8548 board

[Jerry Van Baren]

robert lazarski wrote:
> Hi all, been spending a few days with my board and I see no signs of
> life from u-boot. I'm running my code in u-boot pulled from sept
> 18th's git repo - rc1 I think. I've tried:
> 
> /home/iksrazal/eldk2/usr/bin> ./ppc_85xx-gdb /home/iksrazal/u-boot/u-boot
> GNU gdb Red Hat Linux (6.3.0.0-1.21_3rh)
> Copyright 2004 Free Software Foundation, Inc.
> GDB is free software, covered by the GNU General Public License, and you are
> welcome to change it and/or distribute copies of it under certain conditions.
> Type "show copying" to see the conditions.
> There is absolutely no warranty for GDB.  Type "show warranty" for details.
> This GDB was configured as "--host=i386-redhat-linux --target=ppc-linux".
> The target architecture is set automatically (currently powerpc:e500)
> ..
> (gdb) set verbose on
> (gdb) target remote 10.101.43.42:2001
> Remote debugging using 10.101.43.42:2001
> 0x00000000 in ?? ()
> (gdb) mon break hard
> (gdb) b board_init_f
> Reading in symbols for board.c...done.
> Breakpoint 1 at 0xfff896e8: file board.c, line 365.
> (gdb) c
> Continuing.

Is 0xfff896e8 actually board.c line 365 (gdb's symbols OK)?  Low 
probability of error, but worth verifying.

You might want to telnet directly into the BDI and use the BDI 
breakpoint and go commands directly.

I see you told gdb to use hard breakpoints (good).  Using the BDI 
command interface instead of gdb would eliminate one more piece of 
software to screw up.

Did you dump flash (disassemble if you are using gcc), did it match what 
you programmed?

> Where it just hangs. I've tried 'go' in the bdi to no avail. I see no
> life on the serial port.
> While I have 128MB of flash positioned at 0xf8000000 , I've loaded
> u-boot to 0xff8000000 - the default boot rom location for the 8548. I
> suppose one of the things to try is booting from low memory - but I
> haven't figured out how to do that via the boot sequencer or another
> register just yet. I also tried loading uboot to 0xf8000000 but it
> didn't work either.

I wouldn't switch to low boot until you've exhausted your current 
options.  I would suspect you would work hard for no different results.

> The first culprit is probably our memory - 1GB of DDR2 ram. The
> hardware guys tell me our DDR2 is exactly like the MPC8548CDS
> reference board. I have the memory mapped to 0x00000000 , and I can do
> this:

board_init_f is the flash-based board initialization, run before RAM is 
used.  If you aren't getting there, it isn't RAM's fault.

> ATUM>mmh 0x00000000 0xcafe
> ATUM>mdh 0x00000000 1
> 0_00000000 : 0xcafe  -13570  ..
> ATUM>

It may be RAM's fault later, but not yet...

> 
> I get the feeling that somehow that u-boot isn't being executed yet -
> how can I verify that? Maybe setting a breakpoint in start.S ?

YES!  Set hardware breakpoints right at the start and see if you hit 
them (and I would do it directly with the BDI, since I'm paranoid).

I would also check what your PC register is when you start out, perhaps 
you aren't even starting where you think you are.

When you go/continue and no breakpoints are hit, halt the CPU... where 
is the PC?

Your BDI config file is pretty complex, can you trim out all but the 
essentials?  I see a lot of "moving" and "mapping" and "TLB"ing.  Your 
memory map may be completely different from the normal power up 
configuration, which is what u-boot expects.

Makes me ask my memory readback question again: can you read the flash 
holding u-boot at the memory location you think u-boot lives at???

[snip]

> Thanks!
> Robert

Yerwelcome.  Hope it helps.
gvb