[ECOS] Success with AT91EB40 and RedBoot!

[ECOS] Success with AT91EB40 and RedBoot!

[Scott Dattalo]

At last!

For those of you who have been following this saga, it turns out that my 
hardware is corrupted in some way. Dammit! Fortunately, I purchased 2 
evaluation boards and the other board works fine. For posterity, I'll 
summarize the specifics:

$ arm-elf-gdb -v
GNU gdb 5.1.1

$ arm-elf-gcc -v
gcc version 2.95.2 19991024 (release)
 (This also has the ecos-gcc-2952.pat patch applied)

binutils: binutils-2.10.1

Reboot images:
redboot_RAM.elf
redboot_ROMRAM.srec

from eCos CVS.


(I even managed to successfully build and download my own version of the
redboot_RAM image that blinked the diagnostic LED's [although I didn't 
build the accompanying .srec image]).

I essentially followed the directions to a T as described:
http://sources.redhat.com/ecos/tools/linux-arm-elf.html

-----

My advice to others... check your hardware! 

Special thanks goes to: Gary Thomas, Tim Drury and Kjell Svensson.

Scott


-- 
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] Success with AT91EB40 and RedBoot!

[Tim Drury]

Congrats!  I scrapped my whole build and rebuilt using your setup.
Again, because I have the EB40A with the unsupported onboard
SRAM I have to turn on CS1.  I found out my previous problem
with the SIGTRAP upon running redboot was because the uploaded
elf was improperly written to the sram because I needed a waitstate
added.  so instead of,

set *0xffe00004=0x02002001

I do

set *0xffe00004=0x02002021

and it appears that redboot get loaded properly.  I do this set command
right after the 'set $ps=0xd3' command in the at91/redboot instructions.
However, when I 'c' and ctrl-z gdb and fire up 'minicom -o' I still get 
nothing from the target board.  Well, I do get some garbage characters
which is the best results I've had so far, but no 'redboot>' prompt.

So I started playing with the baud rate.  I started with 38400 N81 as
per the instructions and started dropping it.  Most characters I type
would be echoed back as something else.  But at 57600, I was getting
a good echo for all letters, but not the enter key.  If redboot isn't seeing
that I could see why it does nothing for me.

-tim


On Wednesday 12 June 2002 06:49 pm, Scott Dattalo wrote:
> At last!
>
> For those of you who have been following this saga, it turns out that my
> hardware is corrupted in some way. Dammit! Fortunately, I purchased 2
> evaluation boards and the other board works fine. For posterity, I'll
> summarize the specifics:
>
> $ arm-elf-gdb -v
> GNU gdb 5.1.1
>
> $ arm-elf-gcc -v
> gcc version 2.95.2 19991024 (release)
>  (This also has the ecos-gcc-2952.pat patch applied)
>
> binutils: binutils-2.10.1
>
> Reboot images:
> redboot_RAM.elf
> redboot_ROMRAM.srec
>
> from eCos CVS.
>
>
> (I even managed to successfully build and download my own version of the
> redboot_RAM image that blinked the diagnostic LED's [although I didn't
> build the accompanying .srec image]).
>
> I essentially followed the directions to a T as described:
> http://sources.redhat.com/ecos/tools/linux-arm-elf.html
>
> -----
>
> My advice to others... check your hardware!
>
> Special thanks goes to: Gary Thomas, Tim Drury and Kjell Svensson.
>
> Scott


-- 
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] Success with AT91EB40 and RedBoot!

[Scott Dattalo]

On Wed, 12 Jun 2002, Tim Drury wrote:

> 
> Congrats!  

Thanks, it was a big relief to get this working!

>           I scrapped my whole build and rebuilt using your setup.
> Again, because I have the EB40A with the unsupported onboard
> SRAM I have to turn on CS1.  I found out my previous problem
> with the SIGTRAP upon running redboot was because the uploaded
> elf was improperly written to the sram because I needed a waitstate
> added.  so instead of,
> 
> set *0xffe00004=0x02002001
> 
> I do
> 
> set *0xffe00004=0x02002021

This is good to know when I move to the EB40a...

> 
> and it appears that redboot get loaded properly.  I do this set command
> right after the 'set $ps=0xd3' command in the at91/redboot instructions.
> However, when I 'c' and ctrl-z gdb and fire up 'minicom -o' I still get 
> nothing from the target board.  Well, I do get some garbage characters
> which is the best results I've had so far, but no 'redboot>' prompt.
> 
> So I started playing with the baud rate.  I started with 38400 N81 as
> per the instructions and started dropping it.  Most characters I type
> would be echoed back as something else.  But at 57600, I was getting
> a good echo for all letters, but not the enter key.  If redboot isn't seeing
> that I could see why it does nothing for me.


Tim,

The thing that concerns me about the EB40a is that, well, it's not an 
EB40. For example, the EB40 is equipped with an AT29LV1024 flash and the 
EB40A AT49BV1604 flash. Without sifting through the data sheets, I'm not 
sure if the write algorithm for these is the same. 

Also, the memory maps are different betweent the EB40 and EB40A. The upper 
half of Flash in which RedBoot is download is at address 0x01010000. In 
the EB40A, this adress is somewhere in the middle of the Angel Debug 
Monitor (which resides at 0x1006000-0x1011fff). 

It might be easier to get RedBoot into the EB40A using the window's tools.  
The EB40A has a flash loader application already in the Flash. This
program can communicate with a Window's host using an Atmel supplied
program. I don't know the format of the file expected by this downloader,
but I'd assume that it would be capable of dumping a raw binary image or
some other reasonable format to flash.

I hope this helps,
Scott


-- 
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] Success with AT91EB40 and RedBoot!

[Tim Drury]

> >
> > set *0xffe00004=0x02002001
> >
> > I do
> >
> > set *0xffe00004=0x02002021
>
> This is good to know when I move to the EB40a...

Even though this setup worked for me, Atmel says to use 0x02002525.
That is 2 WS and 2 data hold clocks.

I'm going to try to just stick some blinking LED code in the hal right
at the start to see if I can get anything to run on the board.  I know the
board works because I was able to use some of the windows eval tools
they sent to write "hello world".

> The thing that concerns me about the EB40a is that, well, it's not an
> EB40. For example, the EB40 is equipped with an AT29LV1024 flash and the
> EB40A AT49BV1604 flash. Without sifting through the data sheets, I'm not
> sure if the write algorithm for these is the same.
>
> Also, the memory maps are different betweent the EB40 and EB40A. The upper
> half of Flash in which RedBoot is download is at address 0x01010000. In
> the EB40A, this adress is somewhere in the middle of the Angel Debug
> Monitor (which resides at 0x1006000-0x1011fff).

Right now, I'd be happy if redboot would run from RAM.  I'll worry about the
flash later.  I wish there were some way to verify the contents of the RAM
against the elf/bin/srec on the host to make sure everything got uploaded
correctly.

-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