On Wed, 3 Dec 2008, Ken Hornstein wrote:
Hrm. So, if I were to connect to this via gdb, would it work? I ask because it's likely the RedBoot gdb stub and not NetBSD's, and I only have limited experience using gdb to debug stuff remotely.
Yes I also think this is RedBoot's GDB stub.<disclaimer>I haven't done remote gdb with TS boards and NetBSD specifically, I've only integrated GDB support into an other embedded OS, so this is generically speaking from memory -- YMMV </disclaimer>
Try making the board issue the appropriate boot command itself via the RedBoot "boot script" functionality, and connect a cross-gdb for NetBSD arm-elf to the serial port. If you say (in gdb) "target remote <name of serial port>" it should connect and recognize that string as a trap signal packet. The timing may be important; I'm not sure how it reacts to any garbage the redboot/TS bootloaders spew out before trapping...
If you get it to connect, you should be able to load the symbol tables from a non-stripped copy of the same kernel, so you'll probably have to enable full symbol table in the kernel config. However, if this is the RedBoot GDB stub kicking in, the trap's probably in either the RedBoot or TS bootloader, or in any case so extremely early that NetBSD bootstrap hasn't yet installed its own trap vectors -- so the virtual addresses of the kernel symbol table may not be a whole lot of help. Can you figure out where it bombs from the kernel ELF headers and the PC reported by the GDB stub?
Best regards, ali:)