[U-Boot-Users] Using GDB with u-boot and BDI2000 on MPC8245

[Peter Hanson <peterh@google.com>]

Hello all.

I'm new to the list, so forgive me if this is in the archive somewhere.

We're porting Linux to a new 8245-based platform.  We selected u-boot
as the boot-loader that plays nicest with Linux.  Of course, we needed
to create a new board configuration -- no existing configuration was
close.  And, recognizing the difficulting of testing such low-level
code, we bought a BDI2000.

Most of the instructions for using GDB to debug u-boot are clear
enough, but we have run into several gotchas.  I saw several earlier
posts on the topic of GDB with BDI2000, one of which included a
pointer to the Ultimate Solutions, Inc FAQ.  That FAQ does not explain
the behavior we see with various builds and versions of toolchain and
GDB, so I thought I would share my findings here.

Item 1.  Existing instructions and code don't support modern
toolchains.  For example, when we built u-boot-1.1.3 with gcc-4.0.1,
we immediately found three odious treatments of lvalue++ (and close
relatives) as lvalues.  Just install a recent toolchain: the error
messages are crystal clear.

Item 2.  GDB requires careful crafting to build and kinda limps in flash.

Four subitems:
  a. Recommended GDB 5.x => segfault
  b. Vanilla GDB 6.3 => <signal handler called>
  c. Best GDB 6.3 <= mysterious source
  d. Debug with single hardware breakpoint partly broken

  a. We initially tested with the recommended GDB 5.x versions.  We
received mainly seg faults for our efforts.  Likely something new and
unexpected in gcc-4.* symbol tables.

  b. We're using crosstool scripts [http://kegel.com/crosstool/] to
build our shiny new toolchain.  Crosstool has a hidden option to build
a vanilla GDB 6.3@the same time as the chain.  Seems like a good
way to ensure consistent configuration, right?  Yup.  At least the
segfaults are banished.

But . . . vanilla GDB 6.3 does not work reliably with the BDI2000. 
Perhaps this will be familiar to some of you:

    (gdb) targ rem 192.168.3.201:2001
    Remote debugging using 192.168.3.201:2001
    <signal handler called>

It seems some black magic is still missing.

  c. A gentleman was kind enough to send a tarball with markings of
6.3.50.20050725-cvs that can be built and does work.  My main concern
with this is we don't really know what is in this tarball.  Those
don't look like normal release markings.

If possible, I would like to forward whatever magic is needed to the
crosstool script, be it configuration tips, key patches, or druidic
incantations.  I'm fine with magic, I merely want it under source code
control.

  d. Our working-if-mysterious GDB is reliable, but still doesn't play
nicely with the BDI2000 and flash memory.  Perhaps this will be
familiar to some of you:

    (gdb) d b
    Delete all breakpoints? (y or n) y
    (gdb) tb 325
    Breakpoint 3 at 0xfff08ba4: file cpu_init.c, line 325.
    (gdb) c
    Continuing.
    Warning:
    Cannot insert breakpoint 3.
    Error accessing memory address 0xfff08ba4: Unknown error 4294967295.

    (gdb) c
    Continuing.

   Breakpoint 4, cpu_init_f () at cpu_init.c:325
   325     }

Yes, that's right: we see the error even after deleting all
breakpoints!  And then retrying the failed command works!  Why? 
Perhaps error recovery logic clears the condition.  Anyway, it seems
GDB logic doesn't handle this correctly.

The good news is, with a bit of care, you should be able to plow ahead
until u-boot relocates to RAM, switch to software breakpoints, and
finish the job.

Hoping this helps someone else,
 -- Peter

P.S., Labor day weekend is starting in the US.  If that's you, enjoy! 
If not, enjoy the mental image of a whole country sweltering in
immense traffic jams!