gdb --> Raven loading with wrong "endianness"

Do you have a question? Post it now! No Registration Necessary

Translate This Thread From English to

Threaded View

Hi,

I am using a "raven" type JTAG device with the Sharp LH79520 (a
"little-endian" ARM variant).

GDB always loads the application into the chip with the wrong
endianness! So the instruction opcodes are all scrambled up and the
program is garbage. I have tried all four combinations of "set endian"
and the "monitor" equivalent, they seem to make no difference. (You
can make the program APPEAR correct like this, but it is still wrongly
loaded into the chip and does not run).

I can load and run programs fine using the Macraigor OCD Commander
application. Once loaded like this, I can even use GDB to step through
the application. It is just the loading phase which is going wrong.

Can anyone shed some light on this? Is anyone doing this with a
"little-endian" ARM?

I have currently using V5.3 of arm-elf-gdb, tried on both linux and
windows.

Thanks,

--

John Devereux

Re: gdb --> Raven loading with wrong "endianness"

Quoted text here. Click to load it

Have you tried 'set endian little' before talking to the target?

Tauno Voipio
tauno voipio @ iki fi




Re: gdb --> Raven loading with wrong "endianness"

Quoted text here. Click to load it

Hi Tauno,

Yes, the command is is the startup file before the connection (to the
driver) is made.

Some more information: I am using the OcdLibRemote driver to interface
gdb to the target. Here is my .gdbinit file:

----------------------------------------------
set complaints 1
set output-radix 16
set input-radix 16
set endian little
dir .
set prompt (arm-gdb)

target remote 217.169.15.187:8888

monitor endian big
load ./lpa2.elf
symbol-file ./lpa2.elf
----------------------------------------------

(I tried all the combinations for "set endian" and "monitor endian".

I am using a "stock" gdb 5.3 built for arm-elf. I wonder, can this in fact talk
properly to the OCD driver, or do I need something else?


--

John Devereux

Re: gdb --> Raven loading with wrong "endianness"

I think the OCD Driver only works with GDB 5.0

Quoted text here. Click to load it


Re: gdb --> Raven loading with wrong "endianness"

Quoted text here. Click to load it

I am still having this problem!

Some more information:

GDB uses OCDlibremote to talk to the hardware. The loading process is
incorrectly inverting the "endianness", for instructions, *but not for
data* !!!

How is this even possible? I suppose either gdb or OCDlibremote must
be doing some "interpretation", somehow. This happens even when the
input file is in a raw s-record format.

Could somebody please confirm that they have had this configuration
working:

gdb -> OcdLibremote -> Raven | Wiggler -> LittleEndian ARM

If not via the newsgroup, is there anyone who would be willing to help
via email? Pretty Please?

Thanks,

--

John Devereux

Re: gdb --> Raven loading with wrong "endianness"
Quoted text here. Click to load it

I have had OCDLibremote (running under Cygwin / Win2000)  -> RAVEN ->
LittleEndian ARM 9 and ARM7  processors.

GDB 5.2 was running on a (different ) Linux PC.

It all worked fine.

I assume you have a cross-compiled version of GDB ?










Re: gdb --> Raven loading with wrong "endianness"

Quoted text here. Click to load it

Yes, I am using the same setup as you. OcdLibRemote on a Cygwin/W2K
machine, GDB on linux. I have tried several versions of arm-elf-gdb by
now, 5.0, 5.21, 5.3, mostly on linux.

Simon, thanks for the response, at least I know it should be possible!

Here is what is happening:

I have a machine code file app.sr. It is little-endian for both code
and data (by inspection).

I can load app.sr using the OCD Commander debugger OK. The program
stays little-endian & runs OK. I can even then connect with gdb and
single step etc.

So app.sr -> OCD Commander -> Raven -> LH79520 = OK.

If I use gdb to load it, via OcdLibRemote, it inverts the endianness
of the code, but not the data!

app.sr -> arm-elf-gdb -> OcdLibRemote -> Raven  -> LH79520 = BAD

I don't see how this is possible, the tools should not be able to
decode a hex file well enough to be able to tell the difference
between opcodes and data. But this is what happens.


--

John Devereux

Site Timeline