¿Cuál es el proceso de arranque para ARM?

boot bootloader

Question

Como sabemos, para la arquitectura X86: después de presionar el botón de encendido, la máquina comienza a ejecutar el código en 0xFFFFFFF0, luego comienza a ejecutar el código en el BIOS para realizar la inicialización del hardware. Después de la ejecución del BIOS, utiliza el gestor de arranque para cargar la imagen del sistema operativo en la memoria. Al final, el código del sistema operativo comienza a ejecutarse. Para la arquitectura ARM, ¿cuál es el proceso de arranque después del uso, presione el botón de encendido? ¡Gracias!

Answer 1

Actualmente, hay dos modelos de excepciones en la arquitectura ARM (el restablecimiento se considera un tipo de excepción):

El modelo clásico, utilizado en chip Pre-Cortex y chips Cortex-A / R actuales. En él, la memoria en 0 contiene varios manejadores de excepciones:

 Offset Handler
===============
00 Reset
04 Undefined Instruction
08 Supervisor Call (SVC)
0C Prefetch Abort
10 Data Abort
14 (Reserved)
18 Interrupt (IRQ)
1C Fast Interrupt (FIQ)

Cuando ocurre la excepción, el procesador simplemente comienza la ejecución desde un desplazamiento específico, por lo que generalmente esta tabla contiene ramas de instrucción única para los manejadores completos más allá en el código. Una típica tabla de vectores clásicos se ve como sigue:

00000000 LDR PC, =Reset
00000004 LDR PC, =Undef
00000008 LDR PC, =SVC
0000000C LDR PC, =PrefAbort
00000010 LDR PC, =DataAbort
00000014 NOP
00000018 LDR PC, =IRQ
0000001C LDR PC, =FIQ

En tiempo de ejecución, la tabla vectorial puede reubicarse en 0xFFFF0000, que a menudo se implementa como un rango de memoria estrechamente acoplado para el manejo de excepciones más rápido. Sin embargo, el reinicio de encendido generalmente comienza en 0x00000000 (pero en algunos chips se puede establecer en 0xFFFF0000 mediante un pin de procesador).

El nuevo modelo de microcontrolador se usa en la línea de chips Cortex-M. Allí, la tabla de vectores en 0 es en realidad una tabla de vectores (punteros), no instrucciones. La primera entrada contiene el valor de inicio para el registro SP, el segundo es el vector de reinicio. Esto permite escribir el controlador de reinicio directamente en C, ya que el procesador configura la pila. Nuevamente, la tabla puede ser reubicada en tiempo de ejecución. La tabla vectorial típica para Cortex-M comienza así:

__Vectors DCD __initial_sp ; Top of Stack
DCD Reset_Handler ; Reset Handler
DCD NMI_Handler ; NMI Handler
DCD HardFault_Handler ; Hard Fault Handler
DCD MemManage_Handler ; MPU Fault Handler
DCD BusFault_Handler ; Bus Fault Handler
DCD UsageFault_Handler ; Usage Fault Handler
[...more vectors...]

Tenga en cuenta que en los modernos chips complejos como OMAP3 o A4 de Apple, la primera pieza de código que se ejecuta normalmente no es el código de usuario sino el ROM de arranque en chip. Podría verificar varias condiciones para determinar dónde cargar el código de usuario y si cargarlo en absoluto (por ejemplo, podría requerir una firma digital válida). En tales casos, el código de usuario podría tener que ajustarse a diferentes convenciones de inicio.

Answer 2

Después de encender está encendido La CPU comenzará a ejecutar el modo de excepción. El 1er. Reinicio. Como el reinicio debe ejecutarse como modo de supervisor ya que la CPU no conoce el estado del registro en este momento de ejecución, no puede pasar al modo de supervisor. Para lograr esto se debe escribir un código pequeño (Ver al final). después de esto, otras excepciones se pueden manejar cargando la dirección en la PC.

.globl _start
_start: b reset
ldr pc, _undefined_instruction
ldr pc, _software_interrupt
ldr pc, _prefetch_abort
ldr pc, _data_abort
ldr pc, _not_used
ldr pc, _irq
ldr pc, _fiq
reset:
mrs r0,cpsr /* set the cpu to SVC32 mode */
bic r0,r0,#0x1f /* (superviser mode, M=10011) */
orr r0,r0,#0x13
msr cpsr,r0

Answer 3

... Al final, el código del sistema operativo comienza a ejecutarse. Para la arquitectura ARM, ¿cuál es el proceso de arranque después del uso, presione el botón de encendido?

Esta respuesta se encuentra principalmente en el contexto de las modernas CPU Cortex-A; hay una gran variedad de plataformas ARM. Sin embargo, para un ARM similar a PC (tableta, teléfono celular, etc.) ...

La CPU ARM obtendrá una instrucción de 0x0 o 0xffff0000 (para un Cortex-M, se trata de datos en oposición a una instrucción). Los típicos ARM SOC tienen algunos rom de arranque que usan este mecanismo. Para un usuario final, debe consultar un manual para determinar cómo ejecutar su código. Es decir, hay un BIOS integrado en muchos ARM SOC que usa el vector, pero necesita usar algo diferente para que su código se ejecute.

Normalmente, ARM SOC admite varios dispositivos de arranque. El dispositivo está determinado por algunos FUSE (establecidos por una herramienta de fabricación) o por pines de muestreo. Los pines serán salidas de CPU en un sistema en ejecución, pero se han desplegado hacia arriba / abajo para configurar un dispositivo de arranque. Cada dispositivo de arranque tendrá detalles peculiares; ROM es simple, pero NAND flash, SPI flash, MMC, etc. necesitan algunos detalles de configuración. Estos también a menudo son proporcionados por un FUSE en el chip y / o pines de muestreo. Se puede leer una pequeña porción del dispositivo para configurar aún más el dispositivo.

Para un chip ARM profundamente incrustado, solo puede arrancar desde el flash incorporado y este proceso es mucho más simple; pero creo que, desde el contexto de la pregunta, se refiere a CPU ARM más avanzadas. Los sistemas ARM más avanzados tienen un gestor de arranque. Esto se debe a que la cantidad de código que cargará un cargador de ROM a menudo está limitada y / o restringida. También suele ser complejo configurar SDRAM y el gestor de arranque puede estar estructurado para ejecutarse desde la RAM estática interna, que configura la SDRAM.

Ver: ¿Por qué necesitamos un gestor de arranque?

Ejecutar el sistema operativo tiene sus propios problemas peculiares. Para ARM Linux, era ATAGS y ahora es Devicetree. Las personas pueden codificar su propio gestor de arranque o usar uno de los muchos proyectos de código abierto con u-boot siendo el más común. U-boots admite vxWorks, Linux, NetBSD, Plan9, OSE, QNX, Integrity y OpenRTOS, así como imágenes binarias.

Muchos dispositivos ARM Linux originales admiten un arranque directo de Linux sin un gestor de arranque. Sin embargo, Linux no es compatible con esto en la línea principal a excepción de algunos SOC / núcleos ARM muy antiguos.