Dan Miller wrote:
> I've been trying, for a couple of days, to build the project which was
> associated with the Embedded.com articles "Building Bare-Metal ARM
> Systems with GNU".  I've been hoping that this will clarify alot of the
> confusion that I've experienced in trying to convert an existing project
> from IAR to gnuarm.
As far as I know the code from the embedded.com tutorial has been tested
with a Codesourcery G++ package (the lite version is free, Codesourcery
gets paid by ARM to improve the GNU tools AFAIK). So maybe this is the
package that should be used to avoid further confusion. Once you have
some basic knowledge of the tools you will see that it is not that
difficult to adapt the code for other GNU-precompiled-packages or
to/from other compilers.

> As it turns out, after three weeks of research,
Three weeks? - Uff.

> I have at least four
> different versions of GNUARM on my system:
> 1. gnuarm (arm-elf)
> 2. winarm (arm-elf) (slightly earlier version than gnuarm)
> 3. Ride (arm-none-eabi)
> 4. Sarm (arm-eabi)
gnuarm (I expect this is a package from gnuarm.org) and "older" versions
of WinARM are very similar. Main differences: WinARM has been created
for "non-cygwin" hosts and uses a slightly different newlib
configuration.

EABI and "old" ABI are different "targets" for which the GNU toolchain
can be build. EABI has been created as a common binary interface so
object code and libraries created with one toolchain/compiler can linked
to a project created with another one. Search on www.arm.com for further
details.

> Ultimately, only ONE of these four packages could actually build the
> project - Ride's arm-none-eabi.
It is well possible that the "Ride binaries" are very similar or even a
copy of the Codesourcery package. So this might be the reason why the
Quantum example-code can be build with this tools without problems.
Until gcc 4.3.0 the Codesourcery package has been the only one which
offered Cortex-M3 support and AFAIK Ride supports STM32 too. Just
speculation, I have never used the Ride tools. I don't know "Sarm" so I
can not comment on it at all.

> All others would fail in different
> ways.
You did not write the error-messages created during the attempts with
the other packages so it's difficult to analyze the reason why they
failed.

If would be interesting to see the error-messages when you try to build
with DevkitARM R23 or WinARM test-version 20080831.

> What's interesting, though, is that the output of the project,
> using arm-none-eabi, is a .elf file!!!
The file-extension is not important. elf and axf are just the usual
extensions. Just look into the makefile. Why "!!!"? What did you expect?

> So... what is the difference between arm-elf, arm-none-eabi, and
> arm-eabi ???
arm-elf is usually the prefix for GNU toolchains created for the arm-elf
target, arm-none-eabi for the target arm-eabi. But this does not mean
much since one can set the prefix when building the toolchain. At least
eabi should be an indicator that the toolchain has been created for
target arm-eabi.

>Obviously, the "none" in arm-none-eabi does not mean
> no-elf ...
This might be wrong. As far as I know it means "no operating-system" on
the target (for "bare metal") compared to for example arm-linux-elf.

I do understand your confusion, so stay with the GNU package that works
for you to get started. Once you know a little bit about the usage of
the GNU tools you will see that the differences are small and porting
code between them is rather easy.
Porting code from IAR to GNU is a more difficult esp. if the EWARM
compiler-extension have been used.

>
>> Ultimately, only ONE of these four packages could actually build the
>> project - Ride's arm-none-eabi.
> It is well possible that the "Ride binaries" are very similar or even a
> copy of the Codesourcery package. So this might be the reason why the
> Quantum example-code can be build with this tools without problems.
> Until gcc 4.3.0 the Codesourcery package has been the only one which
> offered Cortex-M3 support and AFAIK Ride supports STM32 too. Just
> speculation, I have never used the Ride tools. I don't know "Sarm" so I
> can not comment on it at all.
>

I can tell you ride use the codesoucery toolchain as delivered.
sarm is the toolchain delivered with Anglia IDEaliST, it is based on
codesoucery but has a few tweaks with newlib.

Cheers
Spen

Wow, alot of feedback, thanks!!

1. Regarding failures with other compilers:

With gnuarm/winarm (Gcc V4.1.1) compiles and assemblys go fine,
my compiler/assembler flags are:

CCFLAGS = -nostartfiles -mlittle-endian -gdwarf-2 -c -mcpu=$(ARM_CPU)
-mthumb-interwork -O -mlong-calls -ffunction-sections -Wall -o $@

ASMFLAGS = -gdwarf2 -mcpu=$(ARM_CPU) -mthumb-interwork -o $@

but link fails with:

c:/gnuarm/bin/arm-elf-gcc dbg/startup.o dbg/arm_exc.o
dbg/low_level_init.o \
        dbg/bsp.o dbg/isr.o dbg/blinky.o \
        -mlittle-endian -T ./blinky.ld -o dbg/blinky.elf
        -Wl,-Map,dbg/blinky.map,--cref -lm
dbg/startup.o: In function `_start':
/cygdrive/c/download/bare_arm9/startup.s:47: multiple definition of
`_start'
/cygdrive/c/gnuarm/bin/../lib/gcc/arm-elf/4.1.1/../../../../arm-elf/lib/ 
crt0.o:../../../../../../newlib-1.14.0/newlib/libc/sys/arm/crt0.S:46:
first defined here
/cygdrive/c/gnuarm/bin/../lib/gcc/arm-elf/4.1.1/../../../../arm-elf/bin/ 
ld:
ERROR: dbg/startup.o uses VFP instructions,
whereas dbg/blinky.elf does not
/cygdrive/c/gnuarm/bin/../lib/gcc/arm-elf/4.1.1/../../../../arm-elf/bin/ 
ld:
Warning: dbg/startup.o supports interworking, whereas dbg/blinky.elf
does not
/cygdrive/c/gnuarm/bin/../lib/gcc/arm-elf/4.1.1/../../../../arm-elf/bin/ 
ld:
failed to merge target specific data of file dbg/startup.o

If I put -nostartfiles in the linker flags (I'm not actually sure where
it goes), I then fail differently:
/cygdrive/c/gnuarm/bin/../lib/gcc/arm-elf/4.1.1/../../../../arm-elf/bin/ 
ld:
ERROR:
/cygdrive/c/gnuarm/bin/../lib/gcc/arm-elf/4.1.1/../../../../arm-elf/lib/ 
libc.a(init.o)
uses FPA instructions, whereas dbg/blinky.elf does not
/cygdrive/c/gnuarm/bin/../lib/gcc/arm-elf/4.1.1/../../../../arm-elf/bin/ 
ld:
ERROR:
/cygdrive/c/gnuarm/bin/../lib/gcc/arm-elf/4.1.1/../../../../arm-elf/lib/ 
libc.a(init.o)
uses software FP, whereas dbg/blinky.elf uses hardware FP
/cygdrive/c/gnuarm/bin/../lib/gcc/arm-elf/4.1.1/../../../../arm-elf/bin/ 
ld:
Warning:
/cygdrive/c/gnuarm/bin/../lib/gcc/arm-elf/4.1.1/../../../../arm-elf/lib/ 
libc.a(init.o)
does not support interworking, whereas dbg/blinky.elf does
/cygdrive/c/gnuarm/bin/../lib/gcc/arm-elf/4.1.1/../../../../arm-elf/bin/ 
ld:
failed to merge target specific data of file
/cygdrive/c/gnuarm/bin/../lib/gcc/arm-elf/4.1.1/../../../../arm-elf/lib/ 
libc.a(init.o)
dbg/startup.o: In function `_cstartup':
/cygdrive/c/download/bare_arm9/startup.s:163: undefined reference to
`__data_load'
/cygdrive/c/gnuarm/bin/../lib/gcc/arm-elf/4.1.1/../../../../arm-elf/lib/ 
libc.a(init.o):
In function `__libc_fini_array':
../../../../../newlib-1.14.0/newlib/libc/misc/init.c:58: undefined
reference to `_fini'
/cygdrive/c/gnuarm/bin/../lib/gcc/arm-elf/4.1.1/../../../../arm-elf/lib/ 
libc.a(init.o):
In function `__libc_init_array':
../../../../../newlib-1.14.0/newlib/libc/misc/init.c:40: undefined
reference to `_init'
/cygdrive/c/gnuarm/bin/../lib/gcc/arm-elf/4.1.1/../../../../arm-elf/bin/ 
ld:
BFD 2.17 internal error, aborting at ../../binutils-2.17/bfd/elflink.c
line 6509 in elf_link_output_extsym

/cygdrive/c/gnuarm/bin/../lib/gcc/arm-elf/4.1.1/../../../../arm-elf/bin/ 
ld:
Please report this bug.

collect2: ld returned 1 exit status
make: *** [dbg/blinky.elf] Error 1
//*************************************************************
When I use Idealist's sarm version of gnuarm (gcc V4.2.3), assembly is
fine but gcc fails strangely:

C:/sarm/bin/as -gdwarf2 -mcpu=arm966e-s -mthumb-interwork -o
dbg/startup.o startup.s
C:/sarm/bin/as -gdwarf2 -mcpu=arm966e-s -mthumb-interwork -o
dbg/arm_exc.o arm_exc.s
C:/sarm/bin/gcc -marm -nostartfiles -mlittle-endian -gdwarf-2 -c
-mcpu=arm966e-s -mthumb-interwork -O -mlong-calls -ffunction-sections
-Wall -o dbg/low_level_init.o -I. low_level_init.c
gcc.exe: CreateProcess: No such file or directory
make: *** [dbg/low_level_init.o] Error 1
//*************************************************************
In fact, I was about to give up, but then discovered Ride's version
(CodeSourcery gcc V4.2.1)and tried with that... and it worked fine.  In
fact, I had to go back and remove a number of changes that I'd make in
makefiles, trying to get the other versions to work.

I gotta admit, I find it a little disconcerting to find that three
different packages, all based on GnuArm, all gcc V4+, are completely
different in functionality...  Is this a good thing??

LATER NOTE:   ##########
I just went back and tried building our package, which builds fine
with gnuarm, and it does not build successfully using Ride's package.
This cannot be good.  Clearly it won't be sufficient for me to tell the
other engineers "we are using GnuArm", I'll have to have a specific
package which works, and make sure we keep track of it...  sheesh...

results of Ride build on our GnuArm package:
c:/Ride/arm-gcc/bin/arm-none-eabi-gcc -Wall -I. -Iinclude  -MD -DGNUARM
-D_STR912FW44_ -D_STR91x_ -D_STR9x_ -mcpu=arm966e-s -std=c99
-nostartfiles -mlittle-endian -TSTR91xFx44_FLASH.ld -Os -g
-Wl,-Map=odu.map,--cref,--no-warn-mismatch   startup/91x_init.o main.o
91x_it.o feprom.o atmel_flash_memory.o Internal_flash_memory.o
source/91x_adc.o source/91x_caps.o source/91x_gpio.o source/91x_lib.o
source/91x_rtc.o source/91x_uart.o source/91x_vic.o source/91x_wdg.o
source/91x_fmi.o source/91x_scu.o source/91x_emi.o source/91x_dma.o  -o
odu.elf
c:/ride/arm-gcc/bin/../lib/gcc/arm-none-eabi/4.2.1/../../../../arm-none- 
eabi/bin/ld.exe:
section .ARM.extab [0002d75c -> 0002d767] overlaps section .data
[0002d75c -> 0002e26b]
c:/ride/arm-gcc/bin/../lib/gcc/arm-none-eabi/4.2.1/../../../../arm-none- 
eabi/lib\libc.a(lib_a-abort.o):
In function `abort':
abort.c:(.text+0xc): undefined reference to `_exit'
c:/ride/arm-gcc/bin/../lib/gcc/arm-none-eabi/4.2.1/../../../../arm-none- 
eabi/lib\libc.a(lib_a-signalr.o):
In function `_getpid_r':
signalr.c:(.text+0x4): undefined reference to `_getpid'
c:/ride/arm-gcc/bin/../lib/gcc/arm-none-eabi/4.2.1/../../../../arm-none- 
eabi/lib\libc.a(lib_a-signalr.o):
In function `_kill_r':
signalr.c:(.text+0x2c): undefined reference to `_kill'
c:/ride/arm-gcc/bin/../lib/gcc/arm-none-eabi/4.2.1/../../../../arm-none- 
eabi/lib\libc.a(lib_a-makebuf.o):
In function `__smakebuf':
makebuf.c:(.text+0xf8): undefined reference to `isatty'
c:/ride/arm-gcc/bin/../lib/gcc/arm-none-eabi/4.2.1/../../../../arm-none- 
eabi/lib\libc.a(lib_a-sbrkr.o):
In function `_sbrk_r':
sbrkr.c:(.text+0x18): undefined reference to `_sbrk'
c:/ride/arm-gcc/bin/../lib/gcc/arm-none-eabi/4.2.1/../../../../arm-none- 
eabi/lib\libc.a(lib_a-writer.o):
In function `_write_r':
writer.c:(.text+0x20): undefined reference to `_write'
c:/ride/arm-gcc/bin/../lib/gcc/arm-none-eabi/4.2.1/../../../../arm-none- 
eabi/lib\libc.a(lib_a-closer.o):
In function `_close_r':
closer.c:(.text+0x18): undefined reference to `_close'
c:/ride/arm-gcc/bin/../lib/gcc/arm-none-eabi/4.2.1/../../../../arm-none- 
eabi/lib\libc.a(lib_a-fstatr.o):
In function `_fstat_r':
fstatr.c:(.text+0x1c): undefined reference to `_fstat'
c:/ride/arm-gcc/bin/../lib/gcc/arm-none-eabi/4.2.1/../../../../arm-none- 
eabi/lib\libc.a(lib_a-lseekr.o):
In function `_lseek_r':
lseekr.c:(.text+0x20): undefined reference to `_lseek'
c:/ride/arm-gcc/bin/../lib/gcc/arm-none-eabi/4.2.1/../../../../arm-none- 
eabi/lib\libc.a(lib_a-readr.o):
In function `_read_r':
readr.c:(.text+0x20): undefined reference to `_read'
collect2: ld returned 1 exit status
make: *** [odu.elf] Error 1

###  I get the same errors whether or not I use -nostartfiles in LDFLAGS

//*************************************************************
The reason I was surprised to see .elf output from the eabi packages was
because I assumed that when two general packages existed (arm-elf and
arm-eabi), that the second was an alternative to the first, rather than
the two package names having nothing to do with each other, as appears
to be the case...

Dan

> I gotta admit, I find it a little disconcerting to find that three
> different packages, all based on GnuArm, all gcc V4+, are completely
> different in functionality...  Is this a good thing??

This is because there are slight differences in the configuration of the
multilib-support of gcc and the newlib (libc used in most packages). The
reason why I created the first WinARM-package was that all other
packages which have been available at this time did not offer the setup
I needed (for a library called newlib-lpc) beside of Cygwin
dependencies.

> LATER NOTE:   ##########
> I just went back and tried building our package, which builds fine
> with gnuarm, and it does not build successfully using Ride's package.
> This cannot be good.  Clearly it won't be sufficient for me to tell the
> other engineers "we are using GnuArm", I'll have to have a specific
> package which works, and make sure we keep track of it...  sheesh...

Well, first it should be defined what is meant with "GnuArm". I use
GNUARM or gnuarm for packages available from gnuarm.com. There are
several other packages based on GNU sources compiled for Win32 hosts and
ARM targets.

- gnuarm from gnuarm.org (arm-elf, extened multilib settings, newlib for
non-reentrant syscalls.

- Codesourcery G++ ARM "bare metal" (also the tools behind Ride and
Rowley's ARM-projects AFAIK). (arm-eabi, don't know the multilib and
newlib configuration) Some extensions for the "startup" which I have not
investigated but they are described in a pdf-file that comes with the
package.

- Anglia ARM tool (or Sarm as recently learned) similar to Codesourcery
but with newlib "tweaks". Spen is the once who creates it so he can give
further details of needed

- Michael Fischer's Yagarto, should be very similar to gnuarm.org, but
without Cygwin dependency

- DevkitARM from devkitpro (r23b: arm-eabi, newlib for
reentrant-syscalls, small modifications in newlib headers)

- my WinARM, the last "official" release 20060606 has a similar setup
for multilibs as gnuarm.org and Yagarto but the newlib has been
configured to expect "reentrant" syscalls for newlib-lpc compatiblity,
arm-elf

There are more packages but I don't remember or know them.

I suggest you go with the Codesourcery-package. The lite-package is free
but you can buy another package with support which may be important for
you and the "other engineers" and they should help you to port your code
if you bought the commercial version.

> results of Ride build on our GnuArm package:
> c:/Ride/arm-gcc/bin/arm-none-eabi-gcc -Wall -I. -Iinclude  -MD -DGNUARM
> -D_STR912FW44_ -D_STR91x_ -D_STR9x_ -mcpu=arm966e-s -std=c99
> -nostartfiles -mlittle-endian -TSTR91xFx44_FLASH.ld -Os -g
> -Wl,-Map=odu.map,--cref,--no-warn-mismatch   startup/91x_init.o main.o
> 91x_it.o feprom.o atmel_flash_memory.o Internal_flash_memory.o
> source/91x_adc.o source/91x_caps.o source/91x_gpio.o source/91x_lib.o
> source/91x_rtc.o source/91x_uart.o source/91x_vic.o source/91x_wdg.o
> source/91x_fmi.o source/91x_scu.o source/91x_emi.o source/91x_dma.o  -o
> odu.elf
> c:/ride/arm-gcc/bin/../lib/gcc/arm-none-eabi/4.2.1/../../../../arm-none- 
eabi/bin/ld.exe:
> section .ARM.extab [0002d75c -> 0002d767] overlaps section .data
> [0002d75c -> 0002e26b]
> c:/ride/arm-gcc/bin/../lib/gcc/arm-none-eabi/4.2.1/../../../../arm-none- 
eabi/lib\libc.a(lib_a-abort.o):
> In function `abort':
> abort.c:(.text+0xc): undefined reference to `_exit'
> c:/ride/arm-gcc/bin/../lib/gcc/arm-none-eabi/4.2.1/../../../../arm-none- 
eabi/lib\libc.a(lib_a-signalr.o):
> In function `_getpid_r':
> signalr.c:(.text+0x4): undefined reference to `_getpid'
> c:/ride/arm-gcc/bin/../lib/gcc/arm-none-eabi/4.2.1/../../../../arm-none- 
eabi/lib\libc.a(lib_a-signalr.o):
> In function `_kill_r':
> signalr.c:(.text+0x2c): undefined reference to `_kill'
> c:/ride/arm-gcc/bin/../lib/gcc/arm-none-eabi/4.2.1/../../../../arm-none- 
eabi/lib\libc.a(lib_a-makebuf.o):
> In function `__smakebuf':
> makebuf.c:(.text+0xf8): undefined reference to `isatty'
> c:/ride/arm-gcc/bin/../lib/gcc/arm-none-eabi/4.2.1/../../../../arm-none- 
eabi/lib\libc.a(lib_a-sbrkr.o):
> In function `_sbrk_r':
> sbrkr.c:(.text+0x18): undefined reference to `_sbrk'
> c:/ride/arm-gcc/bin/../lib/gcc/arm-none-eabi/4.2.1/../../../../arm-none- 
eabi/lib\libc.a(lib_a-writer.o):
> In function `_write_r':
> writer.c:(.text+0x20): undefined reference to `_write'
> c:/ride/arm-gcc/bin/../lib/gcc/arm-none-eabi/4.2.1/../../../../arm-none- 
eabi/lib\libc.a(lib_a-closer.o):
> In function `_close_r':
> closer.c:(.text+0x18): undefined reference to `_close'
> c:/ride/arm-gcc/bin/../lib/gcc/arm-none-eabi/4.2.1/../../../../arm-none- 
eabi/lib\libc.a(lib_a-fstatr.o):
> In function `_fstat_r':
> fstatr.c:(.text+0x1c): undefined reference to `_fstat'
> c:/ride/arm-gcc/bin/../lib/gcc/arm-none-eabi/4.2.1/../../../../arm-none- 
eabi/lib\libc.a(lib_a-lseekr.o):
> In function `_lseek_r':
> lseekr.c:(.text+0x20): undefined reference to `_lseek'
> c:/ride/arm-gcc/bin/../lib/gcc/arm-none-eabi/4.2.1/../../../../arm-none- 
eabi/lib\libc.a(lib_a-readr.o):
> In function `_read_r':
> readr.c:(.text+0x20): undefined reference to `_read'
> collect2: ld returned 1 exit status
> make: *** [odu.elf] Error 1

The newlib syscalls are missing.

>
> ###  I get the same errors whether or not I use -nostartfiles in LDFLAGS

This is libc-related. The libc needs some basic-interface-functions to
the hardware (i.e. to allocate memory or to write-characters from the
stdio-functions. These functions have to be provided either by a
"board-support-package", an extra library or self-written code.

>
> //*************************************************************
> The reason I was surprised to see .elf output from the eabi packages was
> because I assumed that when two general packages existed (arm-elf and
> arm-eabi), that the second was an alternative to the first, rather than
> the two package names having nothing to do with each other, as appears
> to be the case...

The targets arm-elf and arm-eabi have very much in common. The main
difference is the binary-interface but not "nothing to do with each
other".

Okay, thank you for all that information!!  It clarifies alot for me.
I'm still going to stick with GnuArm (actually, I'm using Yagarto, which
is a more recent compiler version) for now, since it's compiling (even
though the compiled code still has some anomalies).  I won't be able to
build our project under the free CodeSourcery because it's limited to
16K, and our code is much larger than that at this point.  But I'll
know it's there if I need it!

Dan Miller wrote:
> Okay, thank you for all that information!!  It clarifies alot for me.
> I'm still going to stick with GnuArm (actually, I'm using Yagarto, which
> is a more recent compiler version) for now, since it's compiling (even
> though the compiled code still has some anomalies).  I won't be able to
> build our project under the free CodeSourcery because it's limited to
> 16K, and our code is much larger than that at this point.  But I'll
> know it's there if I need it!

codesoucery is not limited to 16k - where is this info from?
some vendors, eg. Raisonance limit the amount of code you can debug, but
they cannot limit the amount of code produced by the tools.

Unless i am mistaken.

Regards
Spen

Spencer Oliver wrote:
> Dan Miller wrote:
>> ...stick with GnuArm (actually, I'm using Yagarto...

You "stick" with an arm-elf cross-compiler based on GNU sources, you are
"using" a package named Yagarto with binaries of the GNU toolchain for
Win32-host.

>> I won't be able to
>> build our project under the free CodeSourcery because it's limited to
>> 16K, and our code is much larger than that at this point.  But I'll
>> know it's there if I need it!
>
> codesoucery is not limited to 16k - where is this info from?

I have also never noticed a limitation in CS G++ ARM lite packages too

> some vendors, eg. Raisonance limit the amount of code you can debug, but
> they cannot limit the amount of code produced by the tools.
>
> Unless i am mistaken.

Martin Thomas wrote:
> Spencer Oliver wrote:
>> Dan Miller wrote:
>>> ...stick with GnuArm (actually, I'm using Yagarto...
>
> You "stick" with an arm-elf cross-compiler based on GNU sources, you are
> "using" a package named Yagarto with binaries of the GNU toolchain for
> Win32-host.
>
>>> I won't be able to
>>> build our project under the free CodeSourcery because it's limited to
>>> 16K, and our code is much larger than that at this point.  But I'll
>>> know it's there if I need it!
>>
>> codesoucery is not limited to 16k - where is this info from?
>
> I have also never noticed a limitation in CS G++ ARM lite packages too
>
>> some vendors, eg. Raisonance limit the amount of code you can debug, but
>> they cannot limit the amount of code produced by the tools.
>>
>> Unless i am mistaken.


Whoops... no, I was confused.  Indeed, it's the Raisonance package which
has the 16KB limit... nevermind.  I'll go back and look at Code Sourcery
again...

>
> Whoops... no, I was confused.  Indeed, it's the Raisonance package which
> has the 16KB limit... nevermind.  I'll go back and look at Code Sourcery
> again...

Only for debugging, you can build and program and size code.

Cheers
Spen