Can I mix arm-eabi with arm-elf?

Question

I have a product which bootloader and application are compiled using a compiler (gnuarm GCC 4.1.1) that generates "arm-elf".

The bootloader and application are segregated in different FLASH memory areas in the linker script.

The application has a feature that enables it to call the bootloader (as a simple c-function with 2 parameters).

I need to be able to upgrade existing products around the world, and I can safely do this using always the same compiler.

Now I'd like to be able to compile this product application using a new GCC version that outputs arm-eabi.

Everything will be fine for new products, where both application and bootloader are compiled using the same toolchain, but what happens with existing products? If I flash a new application, compiled with GCC 4.6.x and arm-none-eabi, will my application still be able to call the bootloader function from the old arm-elf bootloader?

---

Furthermore, not directly related to the above question, can I mix object files compiled with arm-elf into a binary compiled with arm-eabi?

---

EDIT:

I think is good to make clear I am building for a bare metal ARM7, if it makes any difference...

Zounds

Answer 1

No. An ABI is the magic that makes binaries compatible. The Application Binary Interface determines various conventions on how to communicate with other libraries/applications. For example, an ABI will define calling convention, which makes implicit assumptions about things like which registers are used for passing arguments to C functions, and how to deal with excess arguments.

I don't know the exact differences between EABI and ABI, but you can find some of them by reading up on EABI. Debian's page mentions the syscall convention is different, along with some alignment changes.

Given the above, of course, you cannot mix arm-elf and arm-eabi objects.

The above answer is given on the assumption that you talk to the bootloader code in your main application. Given that the interface may be very simple (just a function call with two parameters), it's possible that it might work. It'd be an interesting experiment to try. However, it is not ** guaranteed** to work.

Please keep in mind you do not have to use EABI. You can generate an arm-elf toolchain with gcc 4.6 just as well as with older versions. Since you're using a binary toolchain on windows, you may have more of a challenge. I'd suggest investigating crosstool-ng, which works quite well on Linux, and may work okay on cygwin to build the appropriate toolchain.

Sneed

I am not restricted to Windows, and one big reason to leave it is that I can easily get a ready-to-run and shining new toolchain for Linux, where development is clearly easier. Anyway, I will try the funcion call and I'll come back with the news as soon as I can. Thanks. – Zounds

I shoud note that while I indicated it may work, I definitely do not recommend relying on this behavior in a real system. – Sneed

Hey @fljx - Did it work? You've had 4 years to try this out now :) – Phonogram

Answer 2

There is always the option of making the call to bootloader in inline assembly, in which case you can adhere to any calling standard you need :).

However, besides the portability issue it introduces, this approach will also make two assumptions about your bootloader and application:

• you are able to detect in your app that a particular device has a bootloader built with your non-EABI toolchain, as you can only call the older type bootloader using the assembly code.
• the two parameters you mentioned are used as primitive data by your bootloader. Should the bootloader use them, for example, as pointers to structs then you could be facing issues with incorrect alignment, padding and so forth.

Musquash

Answer 3

I Think that this will be OK. I did a migration something like this myself, from what I remember I only ran into a problem to do with handling division.

This is the best info I can find about the differences, it suggests that if you don't have struct alignment issues, you may be OK.

Phonogram