Estoy desarrollando mi gestor de arranque personalizado para microcontroladores STM32 (por ejemplo, STM32F072). Utiliza su propio formato de archivo de firmware, por lo que necesito desarrollar una herramienta para convertir el archivo de firmware producido por el compilador y el enlazador.
Mi gestor de arranque se coloca en FLASH desde la dirección 0x08000000, y el área para la aplicación de usuario comienza desde 0x08006000. El cargador de arranque utiliza los primeros 0x100 bytes de RAM para la reubicación de la tabla de vectores de la aplicación.
Construyo la aplicación de usuario en Atollic Truestudio para la versión 9.1.0 de STM32. De forma predeterminada (cuando acabo de crear un proyecto con STM32CubeMX), el archivo .ld contiene definiciones de áreas de memoria:
RAM (xrw) : ORIGIN = 0x20000000, LENGTH = 16K
FLASH (rx) : ORIGIN = 0x08000000, LENGTH = 64K
y el encabezado del programa del archivo ELF resultante es:
>arm-atollic-eabi-objdump -p f072.elf
f072.elf: file format elf32-littlearm
Program Header:
LOAD off 0x00010000 vaddr 0x08000000 paddr 0x08000000 align 2**16
filesz 0x00002ee0 memsz 0x00002ee0 flags rwx
LOAD off 0x00020000 vaddr 0x20000000 paddr 0x08002ee0 align 2**16
filesz 0x00000158 memsz 0x000011f8 flags rw-
LOAD off 0x000211f8 vaddr 0x200011f8 paddr 0x08003038 align 2**16
filesz 0x00000000 memsz 0x00000600 flags rw-
private flags = 5000200: [Version5 EABI] [soft-float ABI]
Todo se ve bien. Cuando redefino el área de memoria para crear un proyecto para usar con el cargador de arranque:
RAM (xrw) : ORIGIN = 0x20000100, LENGTH = 0x3f00
FLASH (rx) : ORIGIN = 0x08006000, LENGTH = 40K
el encabezado del programa del archivo ELF resultante es:
Program Header:
LOAD off 0x00000000 vaddr 0x08000000 paddr 0x08000000 align 2**16
filesz 0x00008ee0 memsz 0x00008ee0 flags rwx
LOAD off 0x00010100 vaddr 0x20000100 paddr 0x08008ee0 align 2**16
filesz 0x00000158 memsz 0x000011f8 flags rw-
LOAD off 0x000112f8 vaddr 0x200012f8 paddr 0x08009038 align 2**16
filesz 0x00000000 memsz 0x00000600 flags rw-
La dirección base del segmento de código no cambió como lo esperaba, pero su tamaño aumenta en 0x6000 (igual a la diferencia entre las direcciones base nuevas y antiguas del área de memoria en el script del vinculador).
Entonces, si mi convertidor solo analizará el encabezado del programa (y no las secciones), no pudo detectar que el programa comienza realmente desde la dirección 0x08006000.
Además, cuando uso STM32CubeProgrammer e intento abrir este archivo ELF, no reconoce que no hay ningún código o datos de la dirección 0x08000000 a 0x08006000, y se muestra en su registro:
Segment[0]: address= 0x8000000, size= 0x9038
Cuando convierto el archivo ELF a binario está bien (no hay bytes "extra" de 0x6000 al principio), pero quiero usar el archivo ELF porque en este caso puedo verificar que el programa está vinculado correctamente para usar con gestor de arranque. Por supuesto, puedo analizar los encabezados de las secciones, pero primero quiero entender qué sucede con el encabezado del programa.
Entonces, mis preguntas:
1) ¿Por qué el enlazador produce tal encabezado de programa en el archivo ELF de salida? ¿Es un error del enlazador, resultado de un uso incorrecto o un comportamiento normal y documentado del enlazador?
2) ¿Existe algún argumento de línea de comando o directiva de script de vinculador para hacer que el vinculador escriba la dirección base real (0x08006000 en mi caso) en los campos VADDR y PADDR registro del segmento de código del encabezado del programa?