¿Puedo mezclar el brazo eabi con el elfo brazo?

Question

Tengo un producto cuyo gestor de arranque y la aplicación se compilan utilizando un compilador (gnuarm GCC 4.1.1) que genera "arm-elf".

El gestor de arranque y la aplicación están segregados en diferentes áreas de memoria FLASH en el script del enlazador.

La aplicación tiene una función que le permite llamar al gestor de arranque (como una simple función c con 2 parámetros).

Necesito poder actualizar los productos existentes en todo el mundo, y puedo hacerlo de forma segura utilizando siempre el mismo compilador.

Ahora me gustaría poder compilar esta aplicación de producto usando una nueva versión de GCC que emita arm-eabi.

Todo estará bien para los productos nuevos, donde la aplicación y el gestor de arranque se compilan utilizando la misma cadena de herramientas, pero ¿qué ocurre con los productos existentes? Si flasheo una nueva aplicación, compilada con GCC 4.6.x y arm-none-eabi, ¿mi aplicación podrá llamar a la función del gestor de arranque desde el gestor de arranque del brazo-elfo antiguo?

---

Por otra parte, no está relacionado directamente a la pregunta anterior, ¿puedo mezclar archivos objeto compilados con el brazo-Elf en un binario compilado con el brazo-EABI?

---

EDIT:

creo que es bueno para dejar claro que estoy construyendo para un ARM7 metal desnudo, si hace alguna diferencia ...

Answer 1

No. Un ABI es la magia que hace binarios compatibles. La interfaz binaria de aplicaciones determina varias convenciones sobre cómo comunicarse con otras bibliotecas/aplicaciones. Por ejemplo, un ABI definirá la convención de llamadas, que hace suposiciones implícitas sobre cosas como qué registros se usan para pasar argumentos a las funciones de C y cómo tratar con los argumentos en exceso.

No conozco las diferencias exactas entre EABI y ABI, pero puede encontrar algunas al leer en EABI. Debian's page menciona que la convención syscall es diferente, junto con algunos cambios de alineación.

Teniendo en cuenta lo anterior, por supuesto, no se pueden mezclar los objetos de arm-elf y arm-eabi.

La respuesta anterior se da en el supuesto de que hable con el código del gestor de arranque en su aplicación principal. Dado que la interfaz puede ser muy simple (solo una llamada a función con dos parámetros), es posible que funcione. Sería un experimento interesante de probar. Sin embargo, no está ** garantizado ** para funcionar.

Tenga en cuenta que no tiene que usar EABI. Puede generar una cadena de herramientas de brazo-elf con gcc 4.6 tan bien como con versiones anteriores. Como está utilizando una cadena de herramientas binaria en Windows, puede tener más desafíos. Sugeriría investigar crosstool-ng, que funciona bastante bien en Linux, y puede funcionar bien en cygwin para construir la cadena de herramientas adecuada.

Answer 2

Siempre existe la opción de realizar la llamada al gestor de arranque en ensamblado en línea, en cuyo caso puede cumplir con cualquier estándar de llamadas que necesite :).

Sin embargo, además de la portabilidad emitir introduce, este enfoque también hará dos suposiciones acerca de su gestor de arranque y aplicación:

• que son capaces de detectar en su aplicación para que un dispositivo particular tiene un cargador de arranque incorporado con su Toolchain no EABI, ya que solo puedes llamar al gestor de arranque de tipo antiguo utilizando el código de ensamblaje.
• los dos parámetros mencionados son utilizados como datos primitivos por su gestor de arranque. Si el gestor de arranque los utiliza, por ejemplo, como punteros a estructuras, entonces podría enfrentar problemas con una alineación incorrecta, relleno y demás.

Answer 3

I Piensa que esto estará bien. Hice una migración como esta, de lo que recuerdo, solo encontré un problema relacionado con la división de manejo.

This is the best info I can find about the differences, sugiere que si no tiene problemas de alineación de estructuras, puede estar bien.