[ECOS] AT91EB40 and RedBoot

[ECOS] AT91EB40 and RedBoot

[Scott Dattalo]

The short question:

I can establish a communication link to my Atmel AT91EB40 evaluation board 
with gdb (Insight). However, after I download the redboot_RAM.elf, I'm 
unable to obtain a redboot prompt with minicom. The question is, well, why 
not? Specifically (see below), how does one "interrupt 'Angel' with a 
^Z" after the RedBoot binary has been downloaded?

---
Details:

I've grabbed the latest versions of the GNU tool chain:

$ arm-elf-gdb --version
GNU gdb 5.2
$ arm-elf-gcc --version
arm-elf-gcc (GCC) 3.1


I've built gdb with the Insight gui.

I grabbed the latest eb40 redboot monitor from: 
http://sources.redhat.com/ecos/boards/redbootbins/at91eb40/

I followed the RedBoot EB40 install instructions desicribed here:
http://sources.redhat.com/ecos/docs-latest/redboot/at91.html

I've also scoured the archives and sympathize with Lin Ming...

The part that I believe tripping me is this statement in the install 
instructions:

"Once this is started, the Angel session must be interrupted (on Linux
this can be done using ^Z)."

How does one issue a "^Z" (control Z) to interrupt Angel? Is this done 
from with in gdb? Is it done from with the minicom session? 

Any help is of course deeply appreciated.

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

[Gary Thomas]

On Fri, 2002-06-07 at 18:15, Scott Dattalo wrote:
> 
> The short question:
> 
> I can establish a communication link to my Atmel AT91EB40 evaluation board 
> with gdb (Insight). However, after I download the redboot_RAM.elf, I'm 
> unable to obtain a redboot prompt with minicom. The question is, well, why 
> not? Specifically (see below), how does one "interrupt 'Angel' with a 
> ^Z" after the RedBoot binary has been downloaded?
> 
> ---
> Details:
> 
> I've grabbed the latest versions of the GNU tool chain:
> 
> $ arm-elf-gdb --version
> GNU gdb 5.2
> $ arm-elf-gcc --version
> arm-elf-gcc (GCC) 3.1
> 
> 
> I've built gdb with the Insight gui.
> 
> I grabbed the latest eb40 redboot monitor from: 
> http://sources.redhat.com/ecos/boards/redbootbins/at91eb40/
> 
> I followed the RedBoot EB40 install instructions desicribed here:
> http://sources.redhat.com/ecos/docs-latest/redboot/at91.html
> 
> I've also scoured the archives and sympathize with Lin Ming...
> 
> The part that I believe tripping me is this statement in the install 
> instructions:
> 
> "Once this is started, the Angel session must be interrupted (on Linux
> this can be done using ^Z)."
> 
> How does one issue a "^Z" (control Z) to interrupt Angel? Is this done 
> from with in gdb? Is it done from with the minicom session? 
> 
> Any help is of course deeply appreciated.

You don't run minicom at this point, but rather GDB.  Use the command
line form (-nw), not Insight.  Once you start up GDB, you'll be talking
(via GDB) to the Angel on the board.  Download the RedBoot image and 
start it.  Then simply type ^Z - this will send the GDB session into
the background and you can then connect via minicom.  Once you do
that, you'll be able to talk to RedBoot via its command line interface.



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

[Scott Dattalo]

On 7 Jun 2002, Gary Thomas wrote:

> On Fri, 2002-06-07 at 18:15, Scott Dattalo wrote:
> > 
> > The short question:
> > 
> > I can establish a communication link to my Atmel AT91EB40 evaluation board 
> > with gdb (Insight). However, after I download the redboot_RAM.elf, I'm 
> > unable to obtain a redboot prompt with minicom. The question is, well, why 
> > not? Specifically (see below), how does one "interrupt 'Angel' with a 
> > ^Z" after the RedBoot binary has been downloaded?

<snip>

> 
> You don't run minicom at this point, but rather GDB.  Use the command
> line form (-nw), not Insight.  Once you start up GDB, you'll be talking
> (via GDB) to the Angel on the board.  Download the RedBoot image and 
> start it.  Then simply type ^Z - this will send the GDB session into
> the background and you can then connect via minicom.  Once you do
> that, you'll be able to talk to RedBoot via its command line interface.

Wow, that was a really quick response. Invoking gdb with -nw enabled the 
^Z background trick. I should have caught that...

However, minicom is still unable to establish a serial link with the 
AT91EB40 serial port. I've invoked minicom with and without -o. I've tried 
9600 and 38.4k. The only way I can establish a minicom <-> EB40 link is by 
setting the Baud to 9600in minicom and resetting the EB40. Minicom will 
display the start up header (but obviously is unable to sustain the 
communication).

Any idea what else may be happening?

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

[Gary Thomas]

On Fri, 2002-06-07 at 19:05, Scott Dattalo wrote:
> On 7 Jun 2002, Gary Thomas wrote:
> 
> > On Fri, 2002-06-07 at 18:15, Scott Dattalo wrote:
> > > 
> > > The short question:
> > > 
> > > I can establish a communication link to my Atmel AT91EB40 evaluation board 
> > > with gdb (Insight). However, after I download the redboot_RAM.elf, I'm 
> > > unable to obtain a redboot prompt with minicom. The question is, well, why 
> > > not? Specifically (see below), how does one "interrupt 'Angel' with a 
> > > ^Z" after the RedBoot binary has been downloaded?
> 
> <snip>
> 
> > 
> > You don't run minicom at this point, but rather GDB.  Use the command
> > line form (-nw), not Insight.  Once you start up GDB, you'll be talking
> > (via GDB) to the Angel on the board.  Download the RedBoot image and 
> > start it.  Then simply type ^Z - this will send the GDB session into
> > the background and you can then connect via minicom.  Once you do
> > that, you'll be able to talk to RedBoot via its command line interface.
> 
> Wow, that was a really quick response. Invoking gdb with -nw enabled the 
> ^Z background trick. I should have caught that...
> 
> However, minicom is still unable to establish a serial link with the 
> AT91EB40 serial port. I've invoked minicom with and without -o. I've tried 
> 9600 and 38.4k. The only way I can establish a minicom <-> EB40 link is by 
> setting the Baud to 9600in minicom and resetting the EB40. Minicom will 
> display the start up header (but obviously is unable to sustain the 
> communication).
> 
> Any idea what else may be happening?

Are you sure that you loaded & started RedBoot (using the 'load' and
'continue' commands) before typing ^Z?

If you have started RedBoot, but still can't talk to it, something else
may be wrong.  I'm afraid you may be into "debug this on your own" 
territory.  What I would do is to add some code in 
  .../hal/arm/at91/current/include/hal_platform_setup.h
in the path for RAM startup, put something that tickles the LEDs.  Then
you should be able to see it do something when it starts up, and maybe
carry on from there to get RedBoot running full steam.

Sorry I don't have any "pat" answers.  Good luck.


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

[Kjell Svensson]

Hi Tim,

If You are compiling an app in thumb mode, there will still be some 
parts built in arm mode: in an ARM, all exceptions (i.e reset, 
interrupts, swi handlers) are entered in arm mode regardless of the 
execution mode of the app. The exception handler may optionally switch 
over and execute the exception code in thumb mode, but commonly thumb 
apps is a mix of arm mode exception code and thumb mode app code.
Consequently, I don't think there's necessarily anything wrong with Your 
build from that perspective.
Anyhow, the -mcpu=arm7tdmi switch indicates only to the compiler what 
the instruction set version v4t should be used (this is the default 
option, so it may also be omitted in recent compiler versions). It is 
the -mthumb switch that causes the thumb code generation. If the sources 
includes any exception handlers written in C (except reset startup code 
which is anyway entered correctly in arm mode), You should also add the 
-mthumb-interwork switch when building (not always required in certain 
conditions, but it typically adds only 1-2% overhead and makes the code 
interworking safe).
I think I've seen some "build app in thumb mode in the config tool, 
doesn't it work?

As for us for our EB40 stickered with a v2.0 on the flash, we 
successfully ran the pre-built binary that we downloaded from the eCos 
page, so I really think it should be possible for You guys to first do 
the same. We have then also installed the romram version into the upper 
half of the EB40 flash, and this also works fine except from that we 
seem to have some problems running the eCos tests automatically from 
within the eCos config tool.

If You have any doubt that the binary on the site is OK, tell me and 
I'll send You the bianr that works in our board.

Cheers, /Kjell
-- 
Kjell Svensson                 Embedded Technology Manager
Techtribe Solutions AB         Tel:  +46 (0)31 706 06 00
Flöjelbergsgatan 12            GSM:  +46 (0)70 270 76 66
SE-431 37  MÖLNDAL             Mail: kjell@techtribe.se
Sweden



Tim Drury wrote:
> In response to my own problem, I think redboot.elf got built using 
> arm code and not thumb.  When I decompile redboot using 
> 'arm-elf-nm -DS redboot.elf' I see the code is using 32-bit
> arm instructions (which match up to the vectors.S file where
> the SIGTRAP is caught).  These instructions should be 16-bit
> thumb instructions.  In contrast, if I do 'arm-elf-nm -DS -Mforce-thumb
> redboot.elf' the results do not match vectors.S, so I'm very
> sure I'm not getting thumb code out of my cross compiler.
> 
> I build gcc-3.0.4 by doing the following:
> 
> 1) symlink newlib-1.10.0/newlib and newlib-1.10.0/libgloss into
> the gcc-3.0.4 directory
> 2) from build dir I did: ../gcc-3.0.4/configure --target=arm-elf
> --prefix=/usr/local/crossgcc-arm --exec-prefix=/usr/local/crossgcc-arm/
> H-i686-pc-linux-gnu --with-gnu-as --with-gnu-ld --with-newlib
> --with-libgloss --enable-multilib --enable-languages=c,c++,java
> -v 2>&1 | tee configure.out
> 3) make -w all install 2>&1 |tee make.out
> 
> When redboot gets built, the makefile runs gcc using the following:
> 
> arm-elf-gcc -c  -I/usr/local/ecos/build-redboot/install/include 
> -I/usr/local/ecos/cvs/ecos/packages/redboot/current 
> -I/usr/local/ecos/cvs/ecos/packages/redboot/current/src 
> -I/usr/local/ecos/cvs/ecos/packages/redboot/current/tests -I. -mcpu=arm7tdmi 
> -mno-short-load-words -Wall -Wpointer-arith -Wstrict-prototypes -Winline 
> -Wundef -Woverloaded-virtual -g -O2 -ffunction-sections -fdata-sections 
> -fno-rtti -fno-exceptions -fvtable-gc -finit-priority -o 
> /usr/local/ecos/build-redboot/install/lib/version.o 
> /usr/local/ecos/cvs/ecos/packages/redboot/current/src/version.c
> 
> doesn't -mcpu=arm7tdmi cause thumb code to get built or should there
> be a -mthumb in there?  If -mthumb is supposed to be there, how do I
> get it in there (other than editing the makefile)?
> 
> Thanks,
> 
> -tim
> 
> 
> 
> On Monday 10 June 2002 10:25 pm, Tim Drury wrote:
> 
>>I couldn't get RedBoot to run on my EB40A/AT91.  Here is my setup:
>>
>>binutils-2.12.1
>>gcc-2.95.2 + ecos patch
>>gdb-5.2
>>ecos - latest cvs as of 6/10/2002
>>
>>I built redboot according to the instructions and run 'arm-elf-gdb -nw
>>redboot.elf' and do the following:
>>
>>(gdb) tar rdi s=/dev/ttyS0
>>Angel Debug Monitor (serial) 1.04 (Advanced RISC Machines SDT 2.5) for
>>AT91EB40A (1.00)
>>Angel Debug Monitor rebuilt on Feb 03 2002 at 16:09:59
>>Serial Rate:   9600
>>Connected to ARM RDI target.
>>(gdb) set $ps=0xd3
>>
>>//NOTE: the following configures the CS1 register to turn the onboard SRAM
>>on. //without it, the 'lo' command would fail saying it couldn't write to
>>//address 0x0200000.
>>
>>(gdb) set *(0xffe00004)=0x02002001
>>(gdb) lo
>>Loading section .rom_vectors, size 0x40 lma 0x2020000
>>Loading section .text, size 0xb174 lma 0x2020040
>>Loading section .rodata, size 0x1f18 lma 0x202b1b4
>>Loading section .data, size 0x3e0 lma 0x202d0cc
>>Start address 0x2020040, load size 54444
>>Transfer rate: 6405 bits/sec, 504 bytes/write.
>>(gdb) c
>>Continuing.
>>RDI_execute: SWI trapped
>>
>>Program received signal SIGTRAP, Trace/breakpoint trap.
>>0x020201f4 in call_exception_handler ()
>>(gdb)
>>
>>I'm not really sure how to proceed from here.  Any suggestions?
>>
>>-tim
>>
>>On Monday 10 June 2002 07:42 pm, Scott Dattalo wrote:
>>
>>>On Mon, 10 Jun 2002, Scott Dattalo wrote:
>>>
>>>>Now the symptom I have is that minicom spews garbage as I type
>>>>characters. The obvious problem is that the baud rate is wrong.
>>>>Unfortunately, I tried *every* baud rate in addition to the 38.4K 8N1.
>>>>It almost suggests that the Evaluation board is using a non-standard
>>>>baud rate. Hmm. It's time to hook up the scope... (unless of course,
>>>>someone can point out what's obviously wrong!).
>>>
>>>Just to follow up on my own message...
>>>
>>>I added my RS232 break-out box to the comm line and looked at the timing
>>>between my Linux box and the AT91EB40. The gibberish I reported seeing
>>>with minicom is what's being sent by the evaluation board. The bit times
>>>are perfectly timed 38.4k baud bits, but the data is, well, wrong. So the
>>>next likely explanation is that somehow the strings being referenced by
>>>the RedBoot Binary are not getting accessed properly.
>>>
>>>Here's what I've tried:
>>>
>>>gcc version 2.95.2
>>>binutils 2.12.1
>>>ecos - latest from cvs
>>>ecosconfig 1.3.net
>>>
>>>If I change binutils to 2.10.1, then the redboot.bin image doesn't run at
>>>all. Or, If I use binutils-2.12.1 and gcc-3.1, the redboot.bin is bad
>>>too. Or if I use binutils-2.10.1 and ecosconfig 1.3.1.4, redboot is still
>>>bad.
>>>
>>>I'm quickly running out of combinations of things to try! Does anyone
>>>know of a proper combination of the tools? Does anyone know if the
>>>at91eb40 *ever* worked?
>>>
>>>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] AT91EB40 and RedBoot

[Tim Drury]

In response to my own problem, I think redboot.elf got built using 
arm code and not thumb.  When I decompile redboot using 
'arm-elf-nm -DS redboot.elf' I see the code is using 32-bit
arm instructions (which match up to the vectors.S file where
the SIGTRAP is caught).  These instructions should be 16-bit
thumb instructions.  In contrast, if I do 'arm-elf-nm -DS -Mforce-thumb
redboot.elf' the results do not match vectors.S, so I'm very
sure I'm not getting thumb code out of my cross compiler.

I build gcc-3.0.4 by doing the following:

1) symlink newlib-1.10.0/newlib and newlib-1.10.0/libgloss into
the gcc-3.0.4 directory
2) from build dir I did: ../gcc-3.0.4/configure --target=arm-elf
--prefix=/usr/local/crossgcc-arm --exec-prefix=/usr/local/crossgcc-arm/
H-i686-pc-linux-gnu --with-gnu-as --with-gnu-ld --with-newlib
--with-libgloss --enable-multilib --enable-languages=c,c++,java
-v 2>&1 | tee configure.out
3) make -w all install 2>&1 |tee make.out

When redboot gets built, the makefile runs gcc using the following:

arm-elf-gcc -c  -I/usr/local/ecos/build-redboot/install/include 
-I/usr/local/ecos/cvs/ecos/packages/redboot/current 
-I/usr/local/ecos/cvs/ecos/packages/redboot/current/src 
-I/usr/local/ecos/cvs/ecos/packages/redboot/current/tests -I. -mcpu=arm7tdmi 
-mno-short-load-words -Wall -Wpointer-arith -Wstrict-prototypes -Winline 
-Wundef -Woverloaded-virtual -g -O2 -ffunction-sections -fdata-sections 
-fno-rtti -fno-exceptions -fvtable-gc -finit-priority -o 
/usr/local/ecos/build-redboot/install/lib/version.o 
/usr/local/ecos/cvs/ecos/packages/redboot/current/src/version.c

doesn't -mcpu=arm7tdmi cause thumb code to get built or should there
be a -mthumb in there?  If -mthumb is supposed to be there, how do I
get it in there (other than editing the makefile)?

Thanks,

-tim



On Monday 10 June 2002 10:25 pm, Tim Drury wrote:
> I couldn't get RedBoot to run on my EB40A/AT91.  Here is my setup:
>
> binutils-2.12.1
> gcc-2.95.2 + ecos patch
> gdb-5.2
> ecos - latest cvs as of 6/10/2002
>
> I built redboot according to the instructions and run 'arm-elf-gdb -nw
> redboot.elf' and do the following:
>
> (gdb) tar rdi s=/dev/ttyS0
> Angel Debug Monitor (serial) 1.04 (Advanced RISC Machines SDT 2.5) for
> AT91EB40A (1.00)
> Angel Debug Monitor rebuilt on Feb 03 2002 at 16:09:59
> Serial Rate:   9600
> Connected to ARM RDI target.
> (gdb) set $ps=0xd3
>
> //NOTE: the following configures the CS1 register to turn the onboard SRAM
> on. //without it, the 'lo' command would fail saying it couldn't write to
> //address 0x0200000.
>
> (gdb) set *(0xffe00004)=0x02002001
> (gdb) lo
> Loading section .rom_vectors, size 0x40 lma 0x2020000
> Loading section .text, size 0xb174 lma 0x2020040
> Loading section .rodata, size 0x1f18 lma 0x202b1b4
> Loading section .data, size 0x3e0 lma 0x202d0cc
> Start address 0x2020040, load size 54444
> Transfer rate: 6405 bits/sec, 504 bytes/write.
> (gdb) c
> Continuing.
> RDI_execute: SWI trapped
>
> Program received signal SIGTRAP, Trace/breakpoint trap.
> 0x020201f4 in call_exception_handler ()
> (gdb)
>
> I'm not really sure how to proceed from here.  Any suggestions?
>
> -tim
>
> On Monday 10 June 2002 07:42 pm, Scott Dattalo wrote:
> > On Mon, 10 Jun 2002, Scott Dattalo wrote:
> > > Now the symptom I have is that minicom spews garbage as I type
> > > characters. The obvious problem is that the baud rate is wrong.
> > > Unfortunately, I tried *every* baud rate in addition to the 38.4K 8N1.
> > > It almost suggests that the Evaluation board is using a non-standard
> > > baud rate. Hmm. It's time to hook up the scope... (unless of course,
> > > someone can point out what's obviously wrong!).
> >
> > Just to follow up on my own message...
> >
> > I added my RS232 break-out box to the comm line and looked at the timing
> > between my Linux box and the AT91EB40. The gibberish I reported seeing
> > with minicom is what's being sent by the evaluation board. The bit times
> > are perfectly timed 38.4k baud bits, but the data is, well, wrong. So the
> > next likely explanation is that somehow the strings being referenced by
> > the RedBoot Binary are not getting accessed properly.
> >
> > Here's what I've tried:
> >
> > gcc version 2.95.2
> > binutils 2.12.1
> > ecos - latest from cvs
> > ecosconfig 1.3.net
> >
> > If I change binutils to 2.10.1, then the redboot.bin image doesn't run at
> > all. Or, If I use binutils-2.12.1 and gcc-3.1, the redboot.bin is bad
> > too. Or if I use binutils-2.10.1 and ecosconfig 1.3.1.4, redboot is still
> > bad.
> >
> > I'm quickly running out of combinations of things to try! Does anyone
> > know of a proper combination of the tools? Does anyone know if the
> > at91eb40 *ever* worked?
> >
> > 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] AT91EB40 and RedBoot

[Tim Drury]

I couldn't get RedBoot to run on my EB40A/AT91.  Here is my setup:

binutils-2.12.1
gcc-2.95.2 + ecos patch
gdb-5.2
ecos - latest cvs as of 6/10/2002

I built redboot according to the instructions and run 'arm-elf-gdb -nw 
redboot.elf' and do the following:

(gdb) tar rdi s=/dev/ttyS0
Angel Debug Monitor (serial) 1.04 (Advanced RISC Machines SDT 2.5) for 
AT91EB40A (1.00)
Angel Debug Monitor rebuilt on Feb 03 2002 at 16:09:59
Serial Rate:   9600
Connected to ARM RDI target.
(gdb) set $ps=0xd3

//NOTE: the following configures the CS1 register to turn the onboard SRAM on.
//without it, the 'lo' command would fail saying it couldn't write to
//address 0x0200000.

(gdb) set *(0xffe00004)=0x02002001  
(gdb) lo
Loading section .rom_vectors, size 0x40 lma 0x2020000
Loading section .text, size 0xb174 lma 0x2020040
Loading section .rodata, size 0x1f18 lma 0x202b1b4
Loading section .data, size 0x3e0 lma 0x202d0cc
Start address 0x2020040, load size 54444
Transfer rate: 6405 bits/sec, 504 bytes/write.
(gdb) c
Continuing.
RDI_execute: SWI trapped

Program received signal SIGTRAP, Trace/breakpoint trap.
0x020201f4 in call_exception_handler ()
(gdb)

I'm not really sure how to proceed from here.  Any suggestions?

-tim



On Monday 10 June 2002 07:42 pm, Scott Dattalo wrote:
> On Mon, 10 Jun 2002, Scott Dattalo wrote:
> > Now the symptom I have is that minicom spews garbage as I type
> > characters. The obvious problem is that the baud rate is wrong.
> > Unfortunately, I tried *every* baud rate in addition to the 38.4K 8N1. It
> > almost suggests that the Evaluation board is using a non-standard baud
> > rate. Hmm. It's time to hook up the scope... (unless of course, someone
> > can point out what's obviously wrong!).
>
> Just to follow up on my own message...
>
> I added my RS232 break-out box to the comm line and looked at the timing
> between my Linux box and the AT91EB40. The gibberish I reported seeing
> with minicom is what's being sent by the evaluation board. The bit times
> are perfectly timed 38.4k baud bits, but the data is, well, wrong. So the
> next likely explanation is that somehow the strings being referenced by
> the RedBoot Binary are not getting accessed properly.
>
> Here's what I've tried:
>
> gcc version 2.95.2
> binutils 2.12.1
> ecos - latest from cvs
> ecosconfig 1.3.net
>
> If I change binutils to 2.10.1, then the redboot.bin image doesn't run at
> all. Or, If I use binutils-2.12.1 and gcc-3.1, the redboot.bin is bad too.
> Or if I use binutils-2.10.1 and ecosconfig 1.3.1.4, redboot is still bad.
>
> I'm quickly running out of combinations of things to try! Does anyone know
> of a proper combination of the tools? Does anyone know if the at91eb40
> *ever* worked?
>
> 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] AT91EB40 and RedBoot

[Scott Dattalo]

On Mon, 10 Jun 2002, Scott Dattalo wrote:

> Now the symptom I have is that minicom spews garbage as I type characters. 
> The obvious problem is that the baud rate is wrong. Unfortunately, I tried 
> *every* baud rate in addition to the 38.4K 8N1. It almost suggests that 
> the Evaluation board is using a non-standard baud rate. Hmm. It's time to 
> hook up the scope... (unless of course, someone can point out what's 
> obviously wrong!).


Just to follow up on my own message...

I added my RS232 break-out box to the comm line and looked at the timing 
between my Linux box and the AT91EB40. The gibberish I reported seeing 
with minicom is what's being sent by the evaluation board. The bit times 
are perfectly timed 38.4k baud bits, but the data is, well, wrong. So the 
next likely explanation is that somehow the strings being referenced by 
the RedBoot Binary are not getting accessed properly. 

Here's what I've tried:

gcc version 2.95.2
binutils 2.12.1
ecos - latest from cvs
ecosconfig 1.3.net

If I change binutils to 2.10.1, then the redboot.bin image doesn't run at 
all. Or, If I use binutils-2.12.1 and gcc-3.1, the redboot.bin is bad too.
Or if I use binutils-2.10.1 and ecosconfig 1.3.1.4, redboot is still bad.

I'm quickly running out of combinations of things to try! Does anyone know 
of a proper combination of the tools? Does anyone know if the at91eb40 
*ever* worked? 

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

[Scott Dattalo]

On 10 Jun 2002, Gary Thomas wrote:

> 
> Have you tried typing commands?  RedBoot isn't going to just print 
> something when you connect with minicom - those bits have long vanished
> into the air...

Like Tim, I too tried the obvious and typed the commands. There's 
something incompatible between the redboot images in CVS and the EB40 eval 
board.

So I decided to rebuild the redboot images. Unfortunately, the latest gcc 
chokes. So I went back to 2.95.2 with the ecos-gcc-2952.patch. This at 
least compiles the redboot code cleanly. And, more importantly, the 
downloaded image shows some sign of life.

Now the symptom I have is that minicom spews garbage as I type characters. 
The obvious problem is that the baud rate is wrong. Unfortunately, I tried 
*every* baud rate in addition to the 38.4K 8N1. It almost suggests that 
the Evaluation board is using a non-standard baud rate. Hmm. It's time to 
hook up the scope... (unless of course, someone can point out what's 
obviously wrong!).

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

[Tim Drury]

> I strongly suspect that the RedBoot binary is corrupted in some way. The
> "corruption" may be due to a change in the EB40 evaluation board. My
> board, btw, is an EB40 V2.0 (rev sticker on the flash). I've grabbed the
> latest ECOS code from CVS and am planning to rebuild the RedBoot portion
> for the EB40 board.
>
> oh, and to answer your questions, I started minicom with the -o option. I
> also invoked gdb without the Insight gui, gdb -nw.
>
> Since we're in the same boat in this one, let's work together and get the
> problem solved.
>
> Scott

I have an EB40A which is slightly different, but I think we can gain a lot
of mutual understanding if we work the problem out together.  I'll look 
into rebuilding RedBoot today.  I also need to fix whatever the equivelent
to crt0.S is to initialize my CS1 config register since it doesn't get set
properly.  As discussed in another email, the onboard SRAM is supposed
to be optional and, although mine came with it, it doesn't work until I
manually set the CS1 config register.

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

[Tim Drury]

> Have you tried typing commands?  RedBoot isn't going to just print
> something when you connect with minicom - those bits have long vanished
> into the air...

Absolutely - I usually hit enter a few times to get a prompt.  And I tried
the 've' command; I assume that is some kind of version command.

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

[Gary Thomas]

On Mon, 2002-06-10 at 09:29, Scott Dattalo wrote:
> On Mon, 10 Jun 2002, Tim Drury wrote:
> 
> > 
> > I must be having similar problems to Scott.  I tried doing ctrl-z after
> > uploading and (c)ontinuing redboot from gdb.  When minicom comes
> > up I see nothing.  I assume you are doing 'minicom -o' which skips past
> > modem initialization.  Instead of ctrl-z should I completely exit gdb?
> > What kind of feedback are you supposed to get from the EB40 to confirm
> > you are talking to RedBoot?  The 'RedBoot>' prompt?
> 
> 
> Tim,
> 
> 
> I strongly suspect that the RedBoot binary is corrupted in some way. The 
> "corruption" may be due to a change in the EB40 evaluation board. My 
> board, btw, is an EB40 V2.0 (rev sticker on the flash). I've grabbed the 
> latest ECOS code from CVS and am planning to rebuild the RedBoot portion 
> for the EB40 board.
> 
> oh, and to answer your questions, I started minicom with the -o option. I 
> also invoked gdb without the Insight gui, gdb -nw. 
> 
> Since we're in the same boat in this one, let's work together and get the
> problem solved.

Have you tried typing commands?  RedBoot isn't going to just print 
something when you connect with minicom - those bits have long vanished
into the air...


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

[Scott Dattalo]

On Mon, 10 Jun 2002, Tim Drury wrote:

> 
> I must be having similar problems to Scott.  I tried doing ctrl-z after
> uploading and (c)ontinuing redboot from gdb.  When minicom comes
> up I see nothing.  I assume you are doing 'minicom -o' which skips past
> modem initialization.  Instead of ctrl-z should I completely exit gdb?
> What kind of feedback are you supposed to get from the EB40 to confirm
> you are talking to RedBoot?  The 'RedBoot>' prompt?


Tim,


I strongly suspect that the RedBoot binary is corrupted in some way. The 
"corruption" may be due to a change in the EB40 evaluation board. My 
board, btw, is an EB40 V2.0 (rev sticker on the flash). I've grabbed the 
latest ECOS code from CVS and am planning to rebuild the RedBoot portion 
for the EB40 board.

oh, and to answer your questions, I started minicom with the -o option. I 
also invoked gdb without the Insight gui, gdb -nw. 

Since we're in the same boat in this one, let's work together and get the
problem solved.

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

[Tim Drury]

I must be having similar problems to Scott.  I tried doing ctrl-z after
uploading and (c)ontinuing redboot from gdb.  When minicom comes
up I see nothing.  I assume you are doing 'minicom -o' which skips past
modem initialization.  Instead of ctrl-z should I completely exit gdb?
What kind of feedback are you supposed to get from the EB40 to confirm
you are talking to RedBoot?  The 'RedBoot>' prompt?

-tim


On Saturday 08 June 2002 09:44 am, Kjell Svensson wrote:
> Hi Scott,
>
> Redboot is by default configured at 38400, so that what You should be
> using.
>
> One tip worth checking; After downloading and starting the Redboot via
> the GDB using the Angel RDI protocol over the serial port, you need to
> close the gdb application in order for the OS to recognize that the
> serial port is released (at least that goes for my somewhat older
> gdb/insight build). If You dont close it, or kill it with some SIGKILL
> signal, it won't properly release the serial, causing minicom to be
> unable to get working communication over the serial port.
>
> Another thought: check that the minicom serial settings have both
> software- and hardware handshake turned off.
>
> Good luck! /Kjell


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

[Kjell Svensson]

Hi Scott,

Redboot is by default configured at 38400, so that what You should be using.

One tip worth checking; After downloading and starting the Redboot via
the GDB using the Angel RDI protocol over the serial port, you need to
close the gdb application in order for the OS to recognize that the
serial port is released (at least that goes for my somewhat older
gdb/insight build). If You dont close it, or kill it with some SIGKILL
signal, it won't properly release the serial, causing minicom to be
unable to get working communication over the serial port.

Another thought: check that the minicom serial settings have both
software- and hardware handshake turned off.

Good luck! /Kjell
-- 
Kjell Svensson                 Embedded Technology Manager
Techtribe Solutions AB         Tel:  +46 (0)31 706 06 00
Flöjelbergsgatan 12            GSM:  +46 (0)70 270 76 66
SE-431 37  MÖLNDAL             Mail: kjell@techtribe.se
Sweden



Scott Dattalo wrote:
 > On 7 Jun 2002, Gary Thomas wrote:
 >
 >
 >>On Fri, 2002-06-07 at 18:15, Scott Dattalo wrote:
 >>
 >>>The short question:
 >>>
 >>>I can establish a communication link to my Atmel AT91EB40 evaluation 
board
 >>>with gdb (Insight). However, after I download the redboot_RAM.elf, I'm
 >>>unable to obtain a redboot prompt with minicom. The question is, 
well, why
 >>>not? Specifically (see below), how does one "interrupt 'Angel' with a
 >>>^Z" after the RedBoot binary has been downloaded?
 >>
 >
 > <snip>
 >
 >>You don't run minicom at this point, but rather GDB.  Use the command
 >>line form (-nw), not Insight.  Once you start up GDB, you'll be talking
 >>(via GDB) to the Angel on the board.  Download the RedBoot image and
 >>start it.  Then simply type ^Z - this will send the GDB session into
 >>the background and you can then connect via minicom.  Once you do
 >>that, you'll be able to talk to RedBoot via its command line interface.
 >
 >
 > Wow, that was a really quick response. Invoking gdb with -nw enabled the
 > ^Z background trick. I should have caught that...
 >
 > However, minicom is still unable to establish a serial link with the
 > AT91EB40 serial port. I've invoked minicom with and without -o. I've 
tried
 > 9600 and 38.4k. The only way I can establish a minicom <-> EB40 link 
is by
 > setting the Baud to 9600in minicom and resetting the EB40. Minicom will
 > display the start up header (but obviously is unable to sustain the
 > communication).
 >
 > Any idea what else may be happening?
 >
 > 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