En el contexto de Linux, el gestor de arranque es responsable de algunas tareas predefinidas. Como esta pregunta está etiquetada con el brazo, creo que el arranque ARM podría ser un recurso útil. Específicamente, el gestor de arranque fue/es responsable de configurar un ATAG enumere eso que describe la cantidad de RAM, una línea de comando del kernel y otros parámetros. Uno de los parámetros más importantes es el tipo de máquina . Con árboles de dispositivos , se pasa una descripción completa de la placa. Esto hace que un Linux ARM estándar sea imposible de arrancar sin algún código para configurar los parámetros como se describe.
Los parámetros permiten uno genérico Linux para soportar múltiples dispositivos. Por ejemplo, un kernel ARM Debian puede admitir cientos de tipos de placas diferentes. Uboot u otro cargador de arranque puede determinar dinámicamente esta información o puede codificarse para la placa.
También puede consultar la página de información del cargador de arranque aquí en el desbordamiento de pila.
Un sistema básico podría configurar ATAGS y copie NOR flash a SRAM. Sin embargo, suele ser un poco más complejo que esto. Linux necesita configuración de RAM, por lo que es posible que deba inicializar un controlador SDRAM. Si usa NAND flash, debe manejar bloques defectuosos y la copia puede ser un poco más complejo que memcpy() .
Linux a menudo tiene algunos errores de controlador latentes en los que un controlador asumirá que se inicializó un reloj. Por ejemplo, si Uboot siempre inicializa un reloj de Ethernet para una máquina en particular, es posible que el controlador de Ethernet de Linux se haya olvidado de configurar este reloj. Esto puede ser especialmente cierto con los árboles de reloj.
Algunos sistemas requieren formatos de imagen de arranque que no son compatibles con Linux; por ejemplo, un encabezado especial que puede inicializar el hardware inmediatamente; como configurar el devices para leer el código inicial. Además, a menudo hay hardware que debe configurarse de inmediato; un cargador de arranque puede hacer esto rápidamente, mientras que la estructura normal de Linux puede retrasarlo significativamente, lo que resulta en conflictos de E/S, etc.
Desde una perspectiva pragmática, es más sencillo utilizar un gestor de arranque. Sin embargo, no hay nada que le impida alterar la fuente de Linux para arrancar directamente desde ella; aunque tal vez le guste pegar el cargador de arranque código directamente al inicio de Linux.
Ver también:Comparación de Coreboot, Uboot y Wikipedia. Barebox es un gestor de arranque menos conocido, pero bien estructurado y moderno para ARM. RedBoot también se usa en algunos sistemas ARM; Las particiones RedBoot son compatibles con el árbol del kernel.
Un cargador de arranque es un programa informático que carga el sistema operativo principal o el entorno de tiempo de ejecución de la computadora después de completar las autocomprobaciones.
^ De artículo de Wikipedia
Entonces, básicamente, el cargador de arranque está haciendo exactamente lo que quería:copiar datos de flash a la memoria operativa. Es realmente así de simple.
Si desea obtener más información sobre cómo impulsar el sistema operativo, le recomiendo que lea el artículo vinculado. La fase de arranque consiste, además de las pruebas, también en comprobar periféricos y algunas cosas más. Omitirlos solo tiene sentido en dispositivos integrados muy simples, y es por eso que sus cargadores de arranque son aún más simples:
Algunos sistemas integrados no requieren una secuencia de inicio notable para comenzar a funcionar y, cuando se encienden, simplemente ejecutan programas operativos que se almacenan en la ROM.
La misma fuente
¿Por qué no podemos cargar directamente el kernel en la RAM desde la memoria flash sin el gestor de arranque? Si lo cargamos ¿qué pasará? De hecho, el procesador no lo admitirá, pero ¿por qué estamos siguiendo el procedimiento?
Bartek, Artless y Felipe dan partes de la imagen.
Cada tipo de procesador integrado (P. Ej., 386EX, Coretex-A53, EM5200) hará algo automáticamente cuando se reinicia o se enciende. A veces ese algo es diferente dependiendo de si se apaga y se reinicia el dispositivo. Algunos procesadores incorporados le permiten cambiar ese algo basado en voltajes aplicados a diferentes pines cuando el dispositivo está encendido o reiniciado.
Independientemente, hay una cantidad limitada de algo que puede hacer un procesador, debido al espacio físico en el procesador requerido para definir ese algo , ya sea FLASH en el chip, microcódigo de instrucción o algún otro mecanismo.
Este límite significa que algo es
- propósito fijo, hace una cosa lo más rápido posible.
- limitado en alcance y capacidad, por lo general carga un pequeño bloque de código (a menudo unos pocos kilobytes o menos) en una ubicación de memoria fija y se ejecuta desde el inicio del código cargado.
- no modificable.
Entonces, lo que hace un procesador en respuesta a un reinicio o ciclo de encendido no se puede cambiar, y no puede hacer mucho, y no queremos que copie automáticamente cientos de megabytes o gigabytes en la memoria que pueden no existir o no estar inicializados, y que podría llevar muuuucho tiempo.
Entonces....
Configuramos un pequeño programa que es más pequeño que el tamaño más pequeño permitido en todos los dispositivos que vamos a usar. Ese programa se almacena dondequiera que algo necesita que lo sea.
A veces, el pequeño programa es U-Boot. A veces, incluso U-Boot es demasiado grande para la carga inicial, por lo que el pequeño programa carga U-Boot.
El punto es que cualquier cosa que sea cargada por algo , es modificable según sea necesario para un sistema en particular. Si es U-Boot, genial, si no, sabe dónde cargar el sistema operativo principal o dónde cargar U-Boot (o algún otro gestor de arranque).
U-Boot (hablando de cargadores de arranque en general) luego configura un conjunto mínimo de dispositivos, memoria, configuraciones de chips, etc., para permitir que se cargue e inicie el sistema operativo principal. El sistema operativo principal se encarga de cualquier configuración o inicialización adicional.
Entonces la secuencia es:
- Encendido o reinicio del procesador
- Algo carga el código de arranque inicial (o el gestor de arranque integrado estilo U-Boot)
- Código de arranque inicial (puede que no sea necesario)
- U-Boot (u otro gestor de arranque integrado general)
- Iniciar Linux
El cargador de arranque principal generalmente está integrado en el silicio y realiza la carga del primer código de USUARIO que se ejecutará en el sistema.
El gestor de arranque existe porque no existe un protocolo estandarizado para cargar el primer código, ya que depende del chip. A veces, el código se puede cargar a través de un puerto serie, una memoria flash o incluso un disco duro. Es la función del gestor de arranque para localizarlo.
Una vez que el código de usuario se carga y se ejecuta, el cargador de arranque ya no se usa y la corrección de la ejecución del sistema es responsabilidad del usuario.
En la cadena de Linux integrada, el gestor de arranque principal configurará y ejecutará Uboot. Entonces Uboot encontrará el kernel de Linux y lo cargará.