what is difference between arm-elf and arm-eabi?
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.