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