[ECOS] RedBoot upload memory troubles

[ECOS] RedBoot upload memory troubles

[Jakob Kjaer]

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

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

I can upload programs, but if I try to start them, I get an error. There
is no memory at address 0xe880e880, I know that! :/

The dissassembled RedBoot ROM elf image does not contain any reference to
the above mentioned address...

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.
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.

I don't have access to a JTAG debugger, so I'm pretty lost on what to try
next... The number of ROM chips are somewhat limited (they are
on-time-programmable), so any advice is very welcome! ;)

Kind regards,
Jakob Kjaer

Student Space Exploration and Technology Initiative
European Space Agency

PS: Yes, it's (or at least, going to be) eCos in space! You can find more
about SSETI-Express on the not-yet-finished web-page:

http://sseti.gte.tuwien.ac.at/WSW4/express1.htm

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

Re: [ECOS] RedBoot upload memory troubles

[Andrew Lunn]

> I don't have access to a JTAG debugger, so I'm pretty lost on what to try
> next... The number of ROM chips are somewhat limited (they are
> on-time-programmable), so any advice is very welcome! ;)

Try finding a flash chip that has the same pinout as the ROM. Or find
an eprom you can erase with UV etc.... Having 1Mb of one time ROM is a
silly idea until near the end of developlent work and you are ready to
start production.

        Andrew

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

Re: [ECOS] RedBoot upload memory troubles

[Andrew Lunn]

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.

> 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. 

> 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.

> 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.
 
        Andrew

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

Re: [ECOS] RedBoot upload memory troubles

[Jakob Kjaer]

Hello,

On Thu, 12 Aug 2004, Andrew Lunn wrote:
> > I don't have access to a JTAG debugger, so I'm pretty lost on what to try
> > next... The number of ROM chips are somewhat limited (they are
> > on-time-programmable), so any advice is very welcome! ;)
>
> Try finding a flash chip that has the same pinout as the ROM. Or find
> an eprom you can erase with UV etc.... Having 1Mb of one time ROM is a
> silly idea until near the end of developlent work and you are ready to
> start production.

Yes, that would have been very nice, but since the everything is going
into space the requirements for chips are somewhat different. -Especially
for the ROM, which has to be radiation-hardened. The only rad-hard ROM we
could afford in large quantities does not have any FLASH or EPROM
foorprint/pinout brother or sister :(

We are (next week) going to build a footprint-adapter for some
FLASH or EPROM chip to fit into the ROM-socket.

/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

Re: [ECOS] RedBoot upload memory troubles

[Jakob Kjaer]

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

Re: [ECOS] RedBoot upload memory troubles

[Andrew Lunn]

> > 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:

That sounds like you are overwriting something important in
redboot. Maybe its stack or its data section. What do you have where
in redboot and the hello world application? Any overlap?

        Andrew

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

Re: [ECOS] RedBoot upload memory troubles

[Jakob Kjaer]

Hi!

Ok, we found and corrected the problem: A dangling Output Enable pin from
one of the RAM-chips :(

Everything works like a charm now!

Cheers,
Jakob

On Thu, 12 Aug 2004, Andrew Lunn wrote:
> > > 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:
>
> That sounds like you are overwriting something important in
> redboot. Maybe its stack or its data section. What do you have where
> in redboot and the hello world application? Any overlap?
>
>         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