Kann ich Arm-Eabi mit Arm-Elfe mischen?

Question

Ich habe ein Produkt, das Bootloader und Anwendung mit einem Compiler (Gnuarm GCC 4.1.1) kompiliert werden, die "Arm-Elf" generiert.

Der Bootloader und die Anwendung sind im Linker-Skript in verschiedene FLASH-Speicherbereiche unterteilt.

Die Anwendung verfügt über eine Funktion, die es ermöglicht, den Bootloader aufzurufen (als einfache c-Funktion mit 2 Parametern).

Ich muss in der Lage sein, bestehende Produkte auf der ganzen Welt zu aktualisieren, und ich kann dies sicher immer mit dem gleichen Compiler tun.

Jetzt möchte ich in der Lage sein, diese Produktanwendung mit einer neuen GCC-Version zu kompilieren, die arm-eabi ausgibt.

Bei neuen Produkten, bei denen sowohl die Anwendung als auch der Bootloader mit der gleichen Toolchain kompiliert werden, ist alles in Ordnung, aber was passiert mit bestehenden Produkten? Wenn ich eine neue Anwendung flash, die mit GCC 4.6.x und arm-none-eabi kompiliert wurde, kann meine Anwendung immer noch die Bootloader-Funktion vom alten arm-elf Bootloader aufrufen?

---

Darüber hinaus können nicht direkt auf die obige Frage bezogen, kann ich Objektdateien mit Arm-Elf in einen mit Arm-EABI kompilierten binären kompilierten mischen?

---

EDIT:

Ich denke, gut ist klar, dass ich für eine Bare-Metal-ARM7 bin Gebäude zu machen, wenn es einen Unterschied macht ...

Answer 1

Nr Ein ABI die Magie ist, die macht Binärdateien kompatibel. Das Application Binary Interface legt verschiedene Konventionen für die Kommunikation mit anderen Bibliotheken/Anwendungen fest. Zum Beispiel wird ein ABI eine Aufrufkonvention definieren, die implizite Annahmen darüber macht, welche Register zum Übergeben von Argumenten an C-Funktionen verwendet werden und wie mit überzähligen Argumenten umgegangen wird.

Ich kenne nicht die genauen Unterschiede zwischen EABI und ABI, aber Sie können einige von ihnen finden, indem Sie auf EABI lesen. Debian's page erwähnt die Syscall-Konvention ist anders, zusammen mit einigen Änderungen der Ausrichtung.

Angesichts der oben genannten, können Sie natürlich nicht Arm-Elf und Arm-Eabi Objekte mischen.

Die obige Antwort wird unter der Annahme gegeben, dass Sie mit dem Bootloader-Code in Ihrer Hauptanwendung sprechen. Da die Schnittstelle sehr einfach sein kann (nur ein Funktionsaufruf mit zwei Parametern), ist es möglich, dass es funktioniert. Es wäre ein interessantes Experiment zu versuchen. Es ist jedoch nicht ** garantiert ** zu arbeiten.

Bitte beachten Sie, dass Sie EABI nicht verwenden müssen. Sie können eine Armelf-Toolchain mit gcc 4.6 ebenso wie mit älteren Versionen generieren. Da Sie eine binäre Toolchain unter Windows verwenden, haben Sie möglicherweise eine größere Herausforderung. Ich würde vorschlagen, zu untersuchen, crosstool-ng, die ziemlich gut unter Linux funktioniert, und kann in Ordnung auf Cygwin arbeiten, um die entsprechende Toolchain zu bauen.

Answer 2

Es gibt immer die Möglichkeit, den Aufruf des Bootloaders in der Inline-Assembly durchzuführen. In diesem Fall können Sie jeden Anrufstandard einhalten, den Sie benötigen :).

jedoch neben der Portabilität ausgibt es einführt, wird dieser Ansatz auch zwei Annahmen über Ihren Bootloader und Anwendung machen:

• Sie in der Lage sind in der App zu erkennen, dass ein bestimmtes Gerät einen Bootloader mit dem eingebauten hat Nicht-EABI-Toolchain, da Sie den Bootloader älteren Typs nur mit dem Assembly-Code aufrufen können.
• Die beiden von Ihnen erwähnten Parameter werden von Ihrem Bootloader als primitive Daten verwendet. Sollte der Bootloader sie beispielsweise als Zeiger auf Strukturen verwenden, könnten Probleme mit falscher Ausrichtung, Auffüllen usw. auftreten.

Answer 3

I Denken Sie, dass dies in Ordnung sein wird. Ich habe selbst eine Migration gemacht, von dem ich mich erinnere, dass ich nur ein Problem mit der Abteilungsdistribution hatte.

This is the best info I can find about the differences, schlägt es vor, dass, wenn Sie keine Struct Alignment Probleme haben, können Sie OK sein.