Posso mescolare arm-eabi con arm-elf?

Question

Ho un prodotto che bootloader e applicazione sono compilati usando un compilatore (gnuarm GCC 4.1.1) che genera "arm-elf".

Il bootloader e l'applicazione sono separati in aree di memoria FLASH diverse nello script del linker.

L'applicazione dispone di una funzione che consente di chiamare il bootloader (come una semplice funzione c con 2 parametri).

Devo essere in grado di aggiornare i prodotti esistenti in tutto il mondo, e posso farlo tranquillamente usando sempre lo stesso compilatore.

Ora mi piacerebbe essere in grado di compilare questa applicazione del prodotto utilizzando una nuova versione GCC che emette arm-eabi.

Tutto andrà bene per i nuovi prodotti, in cui sia l'applicazione sia il bootloader vengono compilati utilizzando la stessa toolchain, ma cosa succede con i prodotti esistenti? Se flasho una nuova applicazione, compilata con GCC 4.6.x e arm-none-eabi, la mia applicazione sarà ancora in grado di chiamare la funzione bootloader dal vecchio bootloader arm-elf?

---

Inoltre, non direttamente legati alla domanda di cui sopra, posso mixare i file oggetto compilati con il braccio-elf in un binario compilato con il braccio-EABI?

---

EDIT:

credo sia bene chiarire sto costruendo per un ARM7 metallo nudo, se si fa alcuna differenza ...

Answer 1

No. Un ABI è la magia che rende binari compatibili. L'interfaccia dell'applicazione binaria determina varie convenzioni su come comunicare con altre librerie/applicazioni. Ad esempio, un ABI definirà la convenzione di chiamata, che fa ipotesi implicite su cose come quali registri sono usati per passare argomenti alle funzioni C e come trattare gli argomenti in eccesso.

Non conosco le differenze esatte tra EABI e ABI, ma è possibile trovarne alcune leggendo su EABI. Debian's page menziona la convenzione di syscall è diversa, insieme ad alcune modifiche di allineamento.

Dato quanto sopra, ovviamente, non è possibile combinare oggetti arm-elfo e arm-eabi.

La risposta sopra riportata si basa sul presupposto che si parli al codice del bootloader nell'applicazione principale. Dato che l'interfaccia può essere molto semplice (solo una chiamata di funzione con due parametri), è possibile che funzioni. Sarebbe un esperimento interessante da provare. Tuttavia, non è ** garantito ** funzionare.

Si prega di tenere presente che non è necessario utilizzare EABI. Puoi generare una toolchain arm-elf con gcc 4.6 altrettanto bene che con le versioni precedenti. Dal momento che stai usando una toolchain binaria su Windows, potresti avere più di una sfida. Suggerirei di investigare su crosstool-ng, che funziona abbastanza bene su Linux, e potrebbe funzionare bene su cygwin per costruire la toolchain appropriata.

Answer 2

C'è sempre la possibilità di effettuare la chiamata al bootloader in assembly inline, nel qual caso è possibile rispettare qualsiasi standard di chiamata necessario :).

Tuttavia, oltre alla portabilità emettere introduce, questo approccio sarà anche fare due ipotesi circa il bootloader e l'applicazione:

• si è in grado di rilevare nella vostra app che un particolare dispositivo ha un bootloader costruito con la tua toolchain non EABI, in quanto è possibile chiamare solo il bootloader di tipo precedente utilizzando il codice assembly.
• i due parametri che hai citato sono usati come dati primitivi dal tuo bootloader. Se il bootloader li utilizza, ad esempio, come puntatori alle strutture, si potrebbero riscontrare problemi con allineamento errato, riempimento e così via.

Answer 3

I Think che questo sia OK. Ho fatto una migrazione simile a questa, da quello che ricordo mi sono imbattuto in un problema relativo alla gestione della divisione.

This is the best info I can find about the differences, suggerisce che se non si verificano problemi di allineamento della struttura, potrebbe essere OK.