linux - para - musicbrainz picard debian
¿Por qué necesitamos un gestor de arranque en un dispositivo integrado? (6)
¿Por qué no podemos cargar directamente el kernel en la RAM desde la memoria flash sin el cargador de arranque? Si lo cargamos ¿qué pasará? De hecho, el procesador no lo admite, pero ¿por qué seguimos el procedimiento?
Bartek, Artless y Felipe dan partes de la imagen.
Cada tipo de procesador integrado (EG 386EX, Coretex-A53, EM5200) hará algo automáticamente cuando se reinicie o encienda. A veces, algo es diferente dependiendo de si la alimentación se cicla o el dispositivo se reinicia. Algunos procesadores integrados le permiten cambiar eso en función de los voltajes aplicados a diferentes pines cuando el dispositivo recibe alimentación o se reinicia.
En cualquier caso, hay una cantidad limitada de algo que puede hacer un procesador, debido al espacio físico en el procesador requerido para definir ese elemento, ya sea un FLASH en el chip, un microcódigo de instrucciones o algún otro mecanismo.
Este límite significa que el algo es
- Propósito fijo, hace una cosa lo más rápido posible.
- de alcance y capacidad limitados, normalmente se 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 al reinicio o al ciclo de encendido no se puede cambiar ni hacer mucho, y no queremos que copie automáticamente cientos de megabytes o gigabytes en la memoria que puede que no exista o que no se pueda inicializar. y que podría tardar muchísimo tiempo.
Asi que....
Configuramos un programa pequeño que es más pequeño que el tamaño más pequeño permitido en todos los dispositivos que vamos a utilizar. Ese programa se almacena donde el algo necesita que 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 a su vez carga U-Boot.
El punto es que cualquier cosa que se cargue 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 cargador de arranque).
U-Boot (hablando de los cargadores de arranque en general) luego configura un conjunto mínimo de dispositivos, memoria, configuración de chip, etc., para permitir que el sistema operativo principal se cargue y arranque. El principal OS init se encarga de cualquier configuración adicional o inicialización.
Así que la secuencia es:
- Procesador encendido o reinicio
- Algo carga el código de arranque inicial (o el cargador de arranque incorporado estilo U-Boot)
- Código de arranque inicial (puede no ser necesario)
- U-Boot (u otro gestor de arranque incorporado general)
- Inicio de Linux
Estoy trabajando con el núcleo ELinux en ARM cortex-A8.
Sé cómo funciona el gestor de arranque y qué trabajo está haciendo. Pero tengo una pregunta: ¿por qué necesitamos un gestor de arranque, por qué nació el gestor de arranque ?
¿Por qué no podemos cargar directamente el kernel en la RAM desde la memoria flash sin el cargador de arranque? Si lo cargamos ¿qué pasará? De hecho, el procesador no lo admite, pero ¿por qué seguimos el procedimiento?
Un cargador de arranque es un programa informático que carga el sistema operativo principal o el entorno de ejecución para la computadora después de completar las autopruebas.
^ Del artículo de Wikipedia
Así que, básicamente, el gestor de arranque está haciendo lo que usted quería: copiar datos de flash en la memoria operativa. Es realmente tan simple.
Si desea saber más sobre boostrapping el sistema operativo, le recomiendo que lea el artículo vinculado. La fase de arranque consiste, además de las pruebas, en la comprobación de periféricos y algunas otras cosas. Omitirlos tiene sentido solo 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 están activados, simplemente ejecutan programas operativos que están almacenados en la ROM.
La misma fuente
Aparte de lo que se indica en todas las demás respuestas, lo que es correcto, en algunos casos el sistema tiene que pasar por diferentes modos de ejecución, tome como ejemplo TrustZone para obtener chips ARM seguros. Todavía es posible considerarlo como una especie de inicialización HW, pero lo que lo hace peculiar es el hecho de que hay limitaciones adicionales (por ejemplo, memoria disponible) que hacen que sea poco práctico, si no imposible, hacer todo en un solo binario, por lo tanto múltiples etapas del gestor de arranque están disponibles.
Además, por razones de seguridad, cada uno de ellos está firmado y puede realizar su trabajo solo si cumple con los requisitos de seguridad.
El gestor 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 hay 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 función del gestor de arranque localizarlo.
Una vez que el código de usuario se carga y se ejecuta, el gestor 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 incrustada, el gestor de arranque principal configurará y ejecutará Uboot. Entonces Uboot encontrará el núcleo de Linux y lo cargará.
El núcleo requiere que el hardware en el que está trabajando se encuentre en un estado particular. Todo el hardware que utilizó necesita ser verificado para su estado e inicializado para su posterior operación. Esta es una de las razones principales para usar un cargador de arranque en un entorno integrado (o en cualquier otro entorno), aparte de su uso para cargar una imagen del núcleo en la RAM.
Cuando enciendes un sistema, la RAM tampoco se encuentra en un estado útil (totalmente inicializado para usar) para que podamos cargar el kernel en él. Por lo tanto, no podemos cargar un kernel directamente (para responder a su pregunta) y, por lo tanto, surge la necesidad de una construcción para inicializarlo.
En el contexto de Linux, el cargador de arranque es responsable de algunas tareas predefinidas. Como esta pregunta está etiquetada con un arm , creo que el arranque ARM podría ser un recurso útil. Específicamente, el cargador de arranque fue / es responsable de configurar una lista ATAG que describa 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 los árboles de dispositivos , se pasa una descripción completa del tablero. Esto hace que un ARM Linux común sea imposible de arrancar sin algún código para configurar los parámetros como se describe.
Los parámetros permiten que un Linux genérico sea compatible con 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 estar codificada para la placa.
Es posible que también desee ver la página de información del cargador de arranque aquí en el desbordamiento de pila.
Un sistema básico podría ser capaz de configurar ATAGS y copiar NOR flash a SRAM. Sin embargo, suele ser un poco más complejo que esto. Linux necesita una configuración de RAM, por lo que es posible que tenga que inicializar un controlador SDRAM. Si usa NAND Flash, tiene que manejar bloques defectuosos y la copia puede ser un poco más compleja que memcpy() .
Linux a menudo tiene algunos errores de controladores latentes en los que un controlador asumirá que se inicializa un reloj. Por ejemplo, si Uboot siempre inicializa un reloj Ethernet para una máquina en particular, el controlador Ethernet de Linux puede haber descuidado la configuración de 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 hardware inmediatamente; Como configurar los devices para leer el código inicial de. Además, a menudo hay hardware que debe configurarse inmediatamente; un cargador de arranque puede hacer esto rápidamente, mientras que la estructura normal de Linux puede demorar esto, lo que puede generar conflictos de E / S, etc.
Desde una perspectiva pragmática, es más sencillo utilizar un cargador 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 código del cargador de arranque directamente al inicio de Linux.
Ver también: comparación de Coreboot , Uboot y Wikipedia . Barebox es un cargador de arranque menos conocido, pero bien estructurado y moderno para el ARM. RedBoot también se utiliza en algunos sistemas ARM; Las particiones de RedBoot son compatibles con el árbol del núcleo.