Más tarde, intentaré responder a su pregunta, pero para obtener una descripción más completa del proceso de arranque, consulte este artículo de IBM.
Ok, asumo que está usando GRUB o GRUB2 como su cargador de arranque para una explicación. En primer lugar, cuando BIOS accede a su disco para cargar el gestor de arranque, utiliza sus rutinas integradas para acceder al disco, que se almacenan en la famosa interrupción de 13 horas. El cargador de arranque (y el kernel en la fase de configuración) hacen uso de esas rutinas cuando acceden al disco. Tenga en cuenta que el BIOS se ejecuta en modo real (modo de 16 bits) del procesador, por lo que no puede direccionar más de 2^20 bytes de RAM (2^20, no 2^16, porque cada dirección en modo real se compone de segment_address* 16 + desplazamiento, donde tanto la dirección del segmento como el desplazamiento son de 16 bits, consulte "segmentación de memoria x86" en Wikipedia). Por lo tanto, estas rutinas no pueden acceder a más de 1MiB de RAM, lo cual es una limitación estricta y un gran inconveniente.
El BIOS carga el código del gestor de arranque directamente desde el MBR (los primeros 512 bytes de su disco) y lo ejecuta. Si usa GRUB, ese código es GRUB etapa 1. Ese código carga GRUB etapa 1.5, que se encuentra en los primeros 32 KiB de espacio en disco, llamada región de compatibilidad con DOS, o desde una dirección fija del sistema de archivos. No necesita comprender la estructura del sistema de archivos para hacer esto, porque incluso si la etapa 1.5 está en el sistema de archivos, es un código "sin procesar" y puede cargarse directamente en la RAM y ejecutarse:Consulte "Detalles de GRUB en la PC " en pixelbeat.org, que es la fuente de la imagen de abajo. La carga de la etapa 1.5 desde el disco a la RAM utiliza las rutinas de acceso al disco del BIOS.
Stage1.5 contiene las utilidades del sistema de archivos, de modo que puede leer la etapa 2 del sistema de archivos (bueno, todavía usa BIOS 13h para leer del disco a la RAM, pero ahora puede descifrar información del sistema de archivos sobre inodos, etc., y obtener código sin formato fuera del disco). Es posible que los BIOS más antiguos no puedan acceder a todo el disco duro debido a las limitaciones en su modo de direccionamiento del disco; es posible que usen el sistema de sector de cabeza cilíndrica y no puedan direccionar más de los primeros 8 GiB de espacio en disco:http://en.wikipedia. org/wiki/Cylinder-head-sector.
La etapa 2 carga el kernel en la RAM (nuevamente, usando las utilidades de disco del BIOS). Si es kernel 2.6+, también tiene initramfs compilado, por lo que no es necesario cargarlo. Si se trata de un núcleo más antiguo, el cargador de arranque también carga una imagen initrd independiente en la memoria, de modo que el núcleo pueda montarlo y obtener controladores para montar un sistema de archivos real desde el disco.
El problema es que el kernel (y el ramdisk) pesan más de 1MiB; por lo tanto, para cargarlos en la RAM, debe cargar el kernel en el primer 1MiB, luego saltar al modo protegido (32 bits), mover el kernel cargado a memoria alta (liberar el primer 1MiB para el modo real), luego regresar al modo real (16 bits) nuevamente, obtenga ramdisk del disco a los primeros 1MiB (si es un initrd separado y un kernel anterior), posiblemente cambie al modo protegido (32 bits) nuevamente, colóquelo donde pertenece, posiblemente obtenga vuelva al modo real (o no:https://stackoverflow.com/questions/4821911/does-grub-switch-to-protected-mode) y ejecute el código del kernel. Advertencia:no estoy completamente seguro de la exhaustividad y precisión de esta parte de la descripción.
Ahora, cuando finalmente ejecuta el kernel, ya lo tiene y ramdisk cargado en la RAM mediante el gestor de arranque , por lo que el kernel puede usar las utilidades de disco de ramdisk para montar su sistema de archivos raíz real y convertirlo en raíz. Los controladores ramfs están presentes en el núcleo, por lo que puede comprender el contenido de initramfs, por supuesto.