¿El controlador está en el gestor de arranque o en el sistema operativo? ¿Por qué?
Xinwei es un programa de arranque de Linux desarrollado por Mizi para s3c241x/s3c244x. Después de trasplantar la función de descarga USB, el amigable Arm se convirtió en supervivi. Ahora lo entendemos. U-boot es un gestor de arranque ampliamente utilizado en plataformas ARM. También es compatible con s3c241x/s3c244x y se puede utilizar para iniciar Linux. Eboot es el gestor de arranque de la plataforma WinCE. Uboot es un gestor de arranque que descarga archivos de imágenes del sistema operativo a través de USB. Eboot es un programa de arranque que descarga imágenes del sistema operativo a través de Ethernet.
Los amigos que estén familiarizados con la arquitectura x86 deben saber que el gestor de arranque en la plataforma x86 se compone del BIOS y el gestor de arranque del sistema operativo (como Lilo y Grub) ubicado en el disco duro MBR. Una vez que el BIOS completa la detección de hardware y la asignación de recursos, el cargador de arranque en el MBR del disco duro se leerá en la RAM del sistema. Luego, el cargador de arranque tomará la iniciativa, moverá el kernel a la memoria y realizará algunos trabajos de inicialización necesarios, y luego saltará a. La dirección de entrada del kernel para su ejecución, por lo que se iniciará el kernel, que es el inicio del sistema.
Las plataformas integradas son diferentes de x86, pero son muy similares y, debido a las características de las diferentes arquitecturas de plataforma, el gestor de arranque correspondiente a cada plataforma hará cosas diferentes. En comparación con las plataformas x86, generalmente no hay BIOS (pero no son absolutas, algunas plataformas tendrán programas de arranque integrados similares a la BIOS). La carga de arranque de todo el sistema se completa mediante el gestor de arranque almacenado en una ubicación específica de un dispositivo de almacenamiento como Flash y ROM. Por ejemplo, en 2410 y 2440 de la plataforma del brazo, el gestor de arranque existe en 0x0 en la memoria flash. Después de encender la placa, el sistema cargará automáticamente el primer código 4k del gestor de arranque en SRAM a través de la lógica del hardware y luego comenzará la ejecución desde 0 en Sram. En este programa 4k, se completará la inicialización básica del hardware, el gestor de arranque completo se moverá a la memoria y el gestor de arranque en la RAM saltará para continuar con la ejecución.
Quiero agregar un tema aquí. A través de la introducción anterior, los amigos atentos tendrán una pregunta: ¿Por qué hay un gestor de arranque? Dado que el gestor de arranque solo inicializa el hardware y arranca el kernel, ¿por qué no simplemente agregar este código al kernel e iniciarlo directamente para completar todo el trabajo? De hecho, es posible integrar el gestor de arranque y el kernel, pero si lo hace, el kernel perderá su versatilidad y flexibilidad. Separar el gestor de arranque y el kernel será más propicio para el desarrollo y la administración. Al integrar el código relacionado con el hardware de la plataforma durante el proceso de arranque en el gestor de arranque, el kernel se puede concentrar en aquellas partes que son comunes a la plataforma (por supuesto, no existe una división tan estricta, de hecho, todavía habrá algunas). código relacionado con la plataforma en el kernel, pero también es bastante común).
Volviendo a lo que dije antes, después de iniciar el gestor de arranque, normalmente hay dos modos de funcionamiento:
El modo de carga de arranque inicia el kernel tan pronto como se enciende la computadora. Tenga en cuenta que el punto clave es que no hay participación del usuario en todo el proceso. Este es en realidad el procesamiento predeterminado del gestor de arranque. Generalmente, cuando el diseño del producto está bien, estará en este estado.
Debes estar muy familiarizado con el modo descarga, el entorno en el que estás desarrollando. A menudo utilizamos tftp, erase, cp.b y otros comandos para grabar archivos bin e IMG relevantes en la placa. En este caso, en realidad está en el entorno de ejecución del cargador de arranque, por lo que, en cierto sentido, la mayoría de los cargadores de arranque son en realidad un sistema operativo integrado, pero no es tan poderoso y no tiene la estructura de Linux. Es complicado y no lo hará. soportar múltiples procesos.
Tipos y clasificaciones de cargadores de arranque
La clasificación aquí en realidad se basa en el método de operación del cargador de arranque anterior.
Según si el sistema anterior admite el modo de descarga, aquí dividimos el gestor de arranque en gestor de arranque y monitor (esta no es mi división, bueno, es una referencia a artículos de otras personas, pero creo que lo que dijo tiene sentido). El "cargador de arranque" aquí se refiere al firmware que solo inicia el dispositivo y ejecuta el programa principal, mientras que el "monitor" se refiere al firmware que no solo tiene la función del cargador de arranque, sino que también puede ingresar al modo de descarga.
Como se puede ver en la tabla anterior, muchos gestores de arranque no son monitores. En la actualidad, la mayor parte del desarrollo nacional todavía utiliza u-boot, por lo que el gestor de arranque del que hablamos a continuación se refiere a u-boot.
Para cada arquitectura, existe una variedad de gestores de arranque de código abierto para elegir.
(1)X86
LILO y GRUB se utilizan generalmente en estaciones de trabajo y servidores X86. LILO es el gestor de arranque principal para distribuciones de Linux. Sin embargo, la distribución Redhat Linux ya utiliza GRUB, que tiene una mejor interfaz de visualización y es más flexible y cómodo de usar que LILO.
En algunas computadoras de placa única integradas X86 o dispositivos especiales, se utilizan otros cargadores de arranque, como ROLO. Estos cargadores de arranque pueden reemplazar las funciones del BIOS y arrancar Linux directamente desde FLASH. Ahora las placas de desarrollo compatibles con ROLO se han integrado en U-Boot, por lo que U-Boot también puede admitir la plataforma X86.
(2) Arm
Hay muchos fabricantes de chips para procesadores ARM, por lo que cada placa de desarrollo de chip tiene su propio gestor de arranque. Como resultado, los gestores de arranque ARM también se han diversificado. Hay firmware para la placa de desarrollo del procesador ARM720, blobs en la plataforma armboot y vivi en la placa de desarrollo del procesador S3C2410. Ahora armboot se ha integrado en U-Boot, por lo que U-Boot también es compatible con la plataforma ARM/XSCALE. U-Boot se ha convertido en el programa de arranque estándar de facto para la plataforma ARM.
(3)PowerPC
El procesador de la plataforma PowerPC tiene un gestor de arranque estándar, que es ppcboot. Después de fusionar armboot, etc., PPCBOOT creó U-Boot, que se convirtió en un programa de arranque universal para placas de desarrollo de varias arquitecturas. U-Boot sigue siendo el cargador de arranque principal para la plataforma PowerPC.
(4) Plan de seguro médico
YAMON desarrollado por MIPS es un cargador de arranque estándar. Muchos fabricantes de chips MIPS han escrito cargadores de arranque para sus propias placas de desarrollo. Ahora, U-Boot también es compatible con la plataforma MIPS.
(5)Sh
El gestor de arranque estándar de la plataforma SH es sh-boot. Redboot también es útil en esta plataforma.
(6)M68K
No existe un gestor de arranque estándar en la plataforma M68K. Redboot puede admitir sistemas de la serie m68k.
Vale la pena señalar que Redboot puede admitir casi todas las arquitecturas, incluidas MIPS, SH, M68K, etc.
Redboot es un proyecto de software de código abierto basado en eCos y con licencia GPL.