[ECOS] AT91EB40 and RedBoot

Wed Jun 12 02:23:00 GMT 2002

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