Re: [ECOS] RM 5231

[Jonathan Larmour <jlarmour at redhat dot co dot uk>]

Warren Jasper wrote:
> 
> I am trying to port eCos to a QED RM 5231 with a custom evaluation board.
> 
> I think I have gdb_module.bin correctly running, as it gives the
> string
> 
> ++14$T0525:0c45c0bf00000000;1d:e81b0080ffffffff;#9e

Looks right.
 
> When I try to load a program via gdb:
> 
> [root@lx39 examples]# mips64vr4300-elf-gdb -nw hello
> GNU gdb 20000502
> Copyright 2000 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=i686-pc-linux-gnu --target=mips64vr4300-elf"...
> (gdb) set remotebaud 19200
> (gdb) set mips-force-32bit-saved-gpregs
> No symbol "mips" in current context.
> (gdb) target remote /dev/ttyS0
> Remote debugging using /dev/ttyS0
> 0xbfc0450c in ?? ()
> (gdb) load
> Loading section .rom_vectors, size 0xdc lma 0x80100000
> Ignoring packet error, continuing...
> Loading section .text, size 0x9018 lma 0x801000dc
> Ignoring packet error, continuing...
> Ignoring packet error, continuing...
> 
> Question:
> 
> 1. What is causing the message: No symbol "mips" in current context.
>    I thought I included all the patches.

We updated the docs on the web, but not in the eCos 1.3.1 distribution.
Instead use "set mips saved-gpreg-size 32".
 
> 2. For the MIPS, what is the most stable version of egcs and gdb?  Do I
>    still need to use the snapshots?

GDB 5.0 is the official stable version, but that shouldn't be very
different from the snapshot you are already using. I don't know about gcc
I'm afraid.
 
> 3. I appears that gdb is communicating with the target.  Any ideas on
>    what is causing the packet errors?  Could it be a byte ordering issue?

GDB determines the byte order from the executable you give to it. And the
"target remote" would have complained if the byte order was wrong too.

Try using "set remotedebug 1" ( or "set debug remote 1" perhaps) to see
whether it's every memory write that is failing or just occasional ones.

Jifl
-- 
Red Hat, 35 Cambridge Place, Cambridge, UK. CB2 1NS  Tel: +44 (1223) 728762
"Plan to be spontaneous tomorrow."  ||  These opinions are all my own fault