[ECOS] RedBoot upload memory troubles

Jakob Kjaer makob@makob.dk
Thu Aug 12 18:50:00 GMT 2004


Hi!

On Thu, 12 Aug 2004, Andrew Lunn wrote:
> On Thu, Aug 12, 2004 at 06:48:05PM +0200, Jakob Kjaer wrote:
> > Hello!
> >
> > I'm in the process of porting (debugging) RedBoot for our in-house
> > developed computer for the SSETI-Express satellite ;)
> >
> > The computer is very much alike the AT91 EB40 eval.board, ie. ARM7,
> > and has the following memory layout:
> > 	ROM 	0x01000000, 1MB
> > 	FLASH	0x02000000, 4MB
> > 	RAM	0x03000000, 2MB
>
> In order that the vectors can be changed, RAM is normally mapped into
> address 0. To do this, the ROM must be mapped to some other
> location. It could be your ROM is high up in memory, at
> 0xe8800000. That would explain the gdb information. Having said that,
> 0xe8800000 is a funny number so it does not seem right somehow.

Yes, ROM is (before the REMAP) located at 0x0, which correctly starts the
processor, initializes memory banks, copies the vector table into internal
SRAM (which will be remapped to 0x0) and then remaps the memory to the
layout described above. Then RedBoot starts.

Everything up to this point seems to be just fine...

> > Timing and chip-selects etc. is setup correctly, and RedBoot has
> > succesfully been burned to ROM, and gives me the following pleasant and
> > well-known greeting:
> >
> > ---begin-output---
> > RedBoot(tm) bootstrap and debug environment [ROM]
> > Non-certified release, version SSETI-Express OBC v5 - built 16:20:49, Aug
> > 12 204
> >
> > Platform: Atmel AT91/AAUOBC (ARM7TDMI)
> > Copyright (C) 2000, 2001, 2002, Red Hat, Inc.
> >
> > RAM: 0x03000000-0x03200000, [0x030070e8-0x03200000] available
> > ---end-output---
> >
> > All nice so far, but... The trouble starts if I connect with gdb. It seems
> > like the GDB protocol stub got the RAM size (workspace_end?) all wrong:
> >
> > ---begin-output---
> > Remote debugging using /dev/ttyS0
> > Cannot access memory at address 0xe880e880
> > 0xe880e880 in ?? ()
> > ---end-output---
>
> This address is not a ram address. Its the current program counter. I
> would expect this to be somewhere in redboot.

Hmm, that sound odd to me. RedBoot is only present i ROM, which is
somewhere around 0x03000000... But then again, this address is excactly
what I'm chasing! I just can't seem to find it anywhere in the disassembly
(arm-elf-objdump -D redboot.elf).

If I understand RedBoot correctly, it initiates the GDB stubs if a "$" is
received?

If so, it must be a problem with the GDB stubs, since I'm able to use the
RedBoot console via minicom (terminal program).

> > Redboot also crashes if I try to upload my hello-world program via y-modem
> > in minicom. Forcing other base-addresses for the upload doesn't help.
>
> Nope, that won't work. eCos images are not position independant. They
> have to be loaded to the address they were linked to.

That's correct. But RedBoot crashes even _before_ I get the chance to
start the program:

After the y-modem upload "successfully completed", the RedBoot console
simply goes mayhem :/ Actually, the output looks very much like the gdb
protocol, but gdb refuses to connect (packet errors).

> > I can use all commands in RedBoot, and there are no complaints in s-record
> > or elf upload - but when the upload is complete, RedBoot crashes and gdb
> > protocol stuff gets sent, same error as when using gdb uploads.
>
> Try connecting with gdb, and use the redboot.elf image. It might give
> you a better idea of what went wrong.

The output of "arm-elf-gdb redboot.elf"

...
(gdb) target remote /dev/ttyS0
Remote debugging using /dev/ttyS0
Cannot access memory at address 0xe880e880
0xe880e880 in ?? ()
(gdb) bt
#0  0xe880e880 in ?? ()
#1  0x00000000 in ?? ()
(gdb)

Bugger! -But thanks for the suggestions! Hope you or someone else has
(lots?) of ideas ;-)

/Jakob

>
>         Andrew
>

-- 
Jakob Kjaer
makob@makob.dk


-- 
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss



More information about the Ecos-discuss mailing list