[ECOS] eb40a target submitted

[ECOS] eb40a target submitted

[Tim Drury]

I created the patch for the Atmel eb40a target and posted it
to the ecos-patches mailing list.  There are a few notes regarding
its use.

1. It must be applied on top of Thomas Koeller's eb40 patch.
It makes a couple changes to his patch and adds the eb40a
target.  His patch can be found in the ecos-patches list in an
email dated June 26, 2002.

2. When building the tests, the resulting elf image is not runnable
by redboot.  It has to be converted to srecs first.  Here is how
I built the tests:

ecosconfig target eb40a
ecosconfig tree
make ; make all
<cd into the directory containing a test image>
arm-elf-objcopy -O srec basic basic.srec

You can then upload via ymodem the basic.srec image to
the eb40a and issue the 'g' command to run it.

A few things I love to see here: a) what is the proper way to
make the process create srecs instead of elf images?
b) can we have each test end by returning to redboot so the
target board doesn't have to be reset after each run?
c) can we automate this in Linux?

CAVEAT: I only ran about 25% of all the tests simply because
my hands were starting to hurt after manually converting, uploading,
and running all the test cases.  I chose what I thought would be the
most rigorous tests.  Let me know if any of the tests you run fail.

3) The eb40a board is not supposed to come with on-board SRAM,
but for some reason mine did.  Since it isn't supposed to have SRAM
the bootstrap program (angel) burned into flash doesn't turn the 
SRAM chip select (CS1) on, so you have to do this when you launch 
gdb.  Here is what I do to upload redboot into RAM:

arm-elf-gdb -nw redboot.elf
tar rdi s=/dev/ttyS0
set $ps=0xd3
set *0xffe00004=0x02002121  (to turn on CS1)
lo
c
<ctrl-z to stop gdb and free the serial port>

Then to upload the ROMRAM version of redboot and burn it into the
flash, I run the following:

minicom -o
<may need to hit return to see redboot prompt>
load -m ymodem -b 0x02040000
<upload the ROMRAM version redboot.srec via ymodem>
fis write -f 0x01100000 -b 0x02040000 -l 0xe000

Now the ROMRAM version of redboot is burned into the upper half
of flash (notice the flash address above is different than the eb40
instructions since the flash on the eb40a is much larger).  Change the
jumper to map the upper half of flash to 0x01000000 and press the
reset button on the eb40a.  Viola! you should see the redboot prompt
from the ROMRAM version.  Now you can upload tests, code, etc.
via redboot.

Building redboot for the eb40a is the same for building the redboot for
the eb40, but I'll reiterate it here.  Be sure ECOS_RESPOSITORY points
to the packages directory.

from a clean working directory do:

ecosconfig target eb40a redboot
ecosconfig import 
$ECOS_REPOSITORY/hal/arm/at91/eb40a/current/misc/redboot_XXX.ecm
ecosconfig tree
make

Let me know if you find any problems with this patch.

-tim drury


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

Re: [ECOS] eb40a target submitted

[Gary Thomas]

On Mon, 2002-07-22 at 11:36, Tim Drury wrote:
> 
> I created the patch for the Atmel eb40a target and posted it
> to the ecos-patches mailing list.  There are a few notes regarding
> its use.
> 
> 1. It must be applied on top of Thomas Koeller's eb40 patch.
> It makes a couple changes to his patch and adds the eb40a
> target.  His patch can be found in the ecos-patches list in an
> email dated June 26, 2002.
> 
> 2. When building the tests, the resulting elf image is not runnable
> by redboot.  It has to be converted to srecs first.  Here is how
> I built the tests:

What's the problem?  What errors are you getting?  
> 
> ecosconfig target eb40a
> ecosconfig tree
> make ; make all
> <cd into the directory containing a test image>
> arm-elf-objcopy -O srec basic basic.srec

If arm-elf-objcopy can read the file, GDB should be able to as well,
since they use the same library for reading ELF images.

> 
> You can then upload via ymodem the basic.srec image to
> the eb40a and issue the 'g' command to run it.
> 
> A few things I love to see here: a) what is the proper way to
> make the process create srecs instead of elf images?

Why would you want to do this?  It seems to me that effort should be
spent figuring out what problems you are having with GDB.

> b) can we have each test end by returning to redboot so the
> target board doesn't have to be reset after each run?

You could easily define it to work this way.  All tests go to
'cyg_test_exit()', which is currently defined as a hard loop.

> c) can we automate this in Linux?

Automate what? 




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

Re: [ECOS] eb40a target submitted

[Tim Drury]

> >
> > 2. When building the tests, the resulting elf image is not runnable
> > by redboot.  It has to be converted to srecs first.  Here is how
> > I built the tests:
>
> What's the problem?  What errors are you getting?
>
> If arm-elf-objcopy can read the file, GDB should be able to as well,
> since they use the same library for reading ELF images.

It's not gdb reading it, it's redboot.  Redboot (ROMRAM) appears
to load the elf image, but 'g' does nothing.  Looking at my (kick ass!)
logic analyzer, it's caught in a tight loop of running off in the sticks
then jumping back into the exception hander code in low memory.
I can look into this deeper if necessary.

> > A few things I love to see here: a) what is the proper way to
> > make the process create srecs instead of elf images?
>
> Why would you want to do this?  It seems to me that effort should be
> spent figuring out what problems you are having with GDB.

Well for one, the srecs are much smaller than the elf files so they load
much faster at 38kbaud.  But mainly because of the problem I'm having
with elf images.

>
> > b) can we have each test end by returning to redboot so the
> > target board doesn't have to be reset after each run?
>
> You could easily define it to work this way.  All tests go to
> 'cyg_test_exit()', which is currently defined as a hard loop.

I'd like to do this.  What I'm afraid of doing is making a change to the
entire ecos tree and screwing someone up.  Can I do this in such a
way that only the eb40a (or at91) targets do this?  Or would anyone
care whether I make the change to the entire tree?

> > c) can we automate this in Linux?

The running of _all_ the test cases.  I've been really spoiled with java
and junit.  junit defines a interface that all your test cases must implement,
then running junit's test runner program executes all your test cases
for you.  I'm looking at some c-equivalent programs right now, but that
won't help the test cases that have already been written.

-tim


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

Re: [ECOS] eb40a target submitted

[Gary Thomas]

On Mon, 2002-07-22 at 12:13, Tim Drury wrote:
> 
> > >
> > > 2. When building the tests, the resulting elf image is not runnable
> > > by redboot.  It has to be converted to srecs first.  Here is how
> > > I built the tests:
> >
> > What's the problem?  What errors are you getting?
> >
> > If arm-elf-objcopy can read the file, GDB should be able to as well,
> > since they use the same library for reading ELF images.
> 
> It's not gdb reading it, it's redboot.  Redboot (ROMRAM) appears
> to load the elf image, but 'g' does nothing.  Looking at my (kick ass!)
> logic analyzer, it's caught in a tight loop of running off in the sticks
> then jumping back into the exception hander code in low memory.
> I can look into this deeper if necessary.
> 

This sounds like a problem with the RedBoot ELF loader.  It works fine
for me, so some investigation would be nice/warranted.

> > > A few things I love to see here: a) what is the proper way to
> > > make the process create srecs instead of elf images?
> >
> > Why would you want to do this?  It seems to me that effort should be
> > spent figuring out what problems you are having with GDB.
> 
> Well for one, the srecs are much smaller than the elf files so they load
> much faster at 38kbaud.  But mainly because of the problem I'm having
> with elf images.
> 

Wrong - it may look that way, but most of the ELF image is symbolic
debug information and is never loaded by RedBoot.  The binary (ELF) data
will actually be less than 1/2 the amount necessary for the ASCII hex 
(SREC) format.

> >
> > > b) can we have each test end by returning to redboot so the
> > > target board doesn't have to be reset after each run?
> >
> > You could easily define it to work this way.  All tests go to
> > 'cyg_test_exit()', which is currently defined as a hard loop.
> 
> I'd like to do this.  What I'm afraid of doing is making a change to the
> entire ecos tree and screwing someone up.  Can I do this in such a
> way that only the eb40a (or at91) targets do this?  Or would anyone
> care whether I make the change to the entire tree?
> 

All you have to do is define the macro CYGHWR_TEST_PROGRAM_EXIT, somewhere 
in your HAL .h files.  Look at .../infra/current/src/tcdiag.cxx

> > > c) can we automate this in Linux?
> 
> The running of _all_ the test cases.  I've been really spoiled with java
> and junit.  junit defines a interface that all your test cases must implement,
> then running junit's test runner program executes all your test cases
> for you.  I'm looking at some c-equivalent programs right now, but that
> won't help the test cases that have already been written.

These tests were all written for just such a framework.  Too bad it's
not in the public CVS.



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

Re: [ECOS] eb40a target submitted

[Mark Salter]

>>>>> Gary Thomas writes:

> Wrong - it may look that way, but most of the ELF image is symbolic
> debug information and is never loaded by RedBoot.

Never loaded, but it is sent across the wire. You'd have to strip
it of non-loadable sections first to keep from wasting bandwidth.

--Mark

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

Re: [ECOS] eb40a target submitted

[Gary Thomas]

On Mon, 2002-07-22 at 12:26, Mark Salter wrote:
> >>>>> Gary Thomas writes:
> 
> > Wrong - it may look that way, but most of the ELF image is symbolic
> > debug information and is never loaded by RedBoot.
> 
> Never loaded, but it is sent across the wire. You'd have to strip
> it of non-loadable sections first to keep from wasting bandwidth.

This shouldn't happen - only "loadable" sections are read and they
normally appear at the front of the file.  The file transfer should
be broken (terminated) as soon as all of the loadable sections have
been consumed.

... or at least, that's how I wanted it to work :-)



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

Re: [ECOS] eb40a target submitted

[Tim Drury]

Another note that I forgot about:

The FLASH on the eb40a is Atmel AT49xxxx which Jani
graciously gave the source code to me.  The AT49 FLASH
is divided into two planes (smaller A and larger B).  Because
the drivers assume equal sized sectors I simply ignored the
A plane.  This is a large FLASH device and plane A is pretty
small - besides Angel is burned into it.

This has a side effect.  Assume the FLASH is mapped to
0x01000000.  Plane A goes up to 0x01010000 -1 bytes
so I told the driver that this section is unusable.  When you
load redboot_ROMRAM into 0x01100000 (the upper half
of flash), you cannot have it load a new version of redboot
on top of itself like you can with the EB40 and its more sane
FLASH.  This is because when the redboot_ROMRAM is
mapped down to 0x01000000 by setting the onboard jumper,
you cannot tell the redboot running in RAM to burn the new
redboot image file into 0x01000000 because the driver considers
that address unusable.

So if you want to load a new version of redboot_ROMRAM, you
have to first load up the RAM version of redboot via Angel,
then run the RAM version of redboot to load the ROMRAM
version of redboot.

Ah well.  Perhaps someone can figure out how to make the
AT49 FLASH work with its differing sector sizes.

-tim


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

RE: [ECOS] eb40a target submitted

[James]

512K bytes out of 2Mbytes doesn't seem so small to me to ignore.  But
just
the fact that you got it working is wonderful!
(In the below, loaddr = 0x01000000 and hiaddr = 0x01100000)
If you load/run Redboot ROMRAM at hiaddr why would you 
want to flash it at loaddr?  Why doesn't it just overwrite
itself at hiaddr?  If you have linked Redboot at
loaddr, would it be possible to change it to hiaddr? Perhaps that
would solve the problem?
Also, I didn't think it mattered to Redboot were the program
was linked.  You can load the program into RAM, then program it
into flash at hiaddr.
James

> -----Original Message-----
> From: Tim Drury [mailto:tdrury@siliconmotorsports.com] 
> Sent: Monday, July 22, 2002 7:29 PM
> To: ecos-discuss@sources.redhat.com
> Subject: Re: [ECOS] eb40a target submitted
> 
> 
> 
> Another note that I forgot about:
> 
> The FLASH on the eb40a is Atmel AT49xxxx which Jani
> graciously gave the source code to me.  The AT49 FLASH
> is divided into two planes (smaller A and larger B).  Because
> the drivers assume equal sized sectors I simply ignored the
> A plane.  This is a large FLASH device and plane A is pretty
> small - besides Angel is burned into it.
> 
> This has a side effect.  Assume the FLASH is mapped to
> 0x01000000.  Plane A goes up to 0x01010000 -1 bytes
> so I told the driver that this section is unusable.  When you
> load redboot_ROMRAM into 0x01100000 (the upper half
> of flash), you cannot have it load a new version of redboot
> on top of itself like you can with the EB40 and its more sane
> FLASH.  This is because when the redboot_ROMRAM is
> mapped down to 0x01000000 by setting the onboard jumper,
> you cannot tell the redboot running in RAM to burn the new
> redboot image file into 0x01000000 because the driver considers
> that address unusable.
> 
> So if you want to load a new version of redboot_ROMRAM, you
> have to first load up the RAM version of redboot via Angel,
> then run the RAM version of redboot to load the ROMRAM
> version of redboot.
> 
> Ah well.  Perhaps someone can figure out how to make the
> AT49 FLASH work with its differing sector sizes.
> 
> -tim
> 
> 


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

Re: [ECOS] eb40a target submitted

[Tim Drury]

James,

Point well taken.  I looked further into the problem last night (since I
turned my eb40a into a brick), and there is no easy solution.  I don't
really like the design of the ecos io/flash code since it seems to want
to know things like sector sizes and such.  I would prefer it not know
anything and just let the low level driver handle issues like trying to
write across sectors.  That way my driver could have handled the two
planes more easily.  As it is, I would have to change the way io/flash
works and I'm not going to do that.  I don't intend on using these
FLASH parts on my final system.

-tim


On Tuesday 23 July 2002 01:40 pm, James wrote:
> 512K bytes out of 2Mbytes doesn't seem so small to me to ignore.  But
> just
> the fact that you got it working is wonderful!
> (In the below, loaddr = 0x01000000 and hiaddr = 0x01100000)
> If you load/run Redboot ROMRAM at hiaddr why would you
> want to flash it at loaddr?  Why doesn't it just overwrite
> itself at hiaddr?  If you have linked Redboot at
> loaddr, would it be possible to change it to hiaddr? Perhaps that
> would solve the problem?
> Also, I didn't think it mattered to Redboot were the program
> was linked.  You can load the program into RAM, then program it
> into flash at hiaddr.
> James
>
> > -----Original Message-----
> > From: Tim Drury [mailto:tdrury@siliconmotorsports.com]
> > Sent: Monday, July 22, 2002 7:29 PM
> > To: ecos-discuss@sources.redhat.com
> > Subject: Re: [ECOS] eb40a target submitted
> >
> >
> >
> > Another note that I forgot about:
> >
> > The FLASH on the eb40a is Atmel AT49xxxx which Jani
> > graciously gave the source code to me.  The AT49 FLASH
> > is divided into two planes (smaller A and larger B).  Because
> > the drivers assume equal sized sectors I simply ignored the
> > A plane.  This is a large FLASH device and plane A is pretty
> > small - besides Angel is burned into it.
> >
> > This has a side effect.  Assume the FLASH is mapped to
> > 0x01000000.  Plane A goes up to 0x01010000 -1 bytes
> > so I told the driver that this section is unusable.  When you
> > load redboot_ROMRAM into 0x01100000 (the upper half
> > of flash), you cannot have it load a new version of redboot
> > on top of itself like you can with the EB40 and its more sane
> > FLASH.  This is because when the redboot_ROMRAM is
> > mapped down to 0x01000000 by setting the onboard jumper,
> > you cannot tell the redboot running in RAM to burn the new
> > redboot image file into 0x01000000 because the driver considers
> > that address unusable.
> >
> > So if you want to load a new version of redboot_ROMRAM, you
> > have to first load up the RAM version of redboot via Angel,
> > then run the RAM version of redboot to load the ROMRAM
> > version of redboot.
> >
> > Ah well.  Perhaps someone can figure out how to make the
> > AT49 FLASH work with its differing sector sizes.
> >
> > -tim


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

Re: [ECOS] eb40a target submitted

[GREGHOL]

Well I reported the that the ~1meg elf file wouldn't
load for me either. Now it it works. :) I have no idea
why now since I havn't changed my tools other than get-
ting the 7-20 source image.
I'm using a EB40 (non A) with stock RAM and an EPI
Jeeni JTAG box over ethernet. Insight 5.1, gcc 3.02

Greg

>On Mon, 2002-07-22 at 12:13, Tim Drury wrote:
>> 
>> > >
>> > > 2. When building the tests, the resulting elf 
image is not runnable
>> > > by redboot.  It has to be converted to srecs 
first.  Here is how
>> > > I built the tests:
>> >
>> > What's the problem?  What errors are you getting?
>> >
>> > If arm-elf-objcopy can read the file, GDB should 
be able to as well,
>> > since they use the same library for reading ELF 
images.
>> 
>> It's not gdb reading it, it's redboot.  Redboot 
(ROMRAM) appears
>> to load the elf image, but 'g' does nothing.  
Looking at my (kick ass!)
>> logic analyzer, it's caught in a tight loop of 
running off in the sticks
>> then jumping back into the exception hander code in 
low memory.
>> I can look into this deeper if necessary.
>> 
>
>This sounds like a problem with the RedBoot ELF 
loader.  It works fine
>for me, so some investigation would be nice/warranted.
>

Greg


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