Arranque del sistema

1. Se inicia el reloj del sistema.

2. Como hay que estar ejecutando instrucciones continuamente, incluso desde el primer tick de reloj, se debe cargar una instrucción de memoria y actualizar el contador del programa.

3. Se lee de una memoria ROM que contiene el programa de arranque escrito desde fábrica, normalmente llamado POST (Power-On Self-Test). Este programa consta de chequeos e inicializaciones para verificar que todo funciona correctamente.

4. Finalmente, se carga el programa de arranque o boot loader en la RAM desde el disco duro y se ejecutan sus instrucciones.

5. Este programa de arranque es el encargado de llamar al cargador, que copia el código del kernel del Sistema Operativo a memoria principal.

6. Una vez hecho eso, será el kernel quien se encargue de todo. Mientras el ordenador siga encendido, el kernel seguirá en memoria.

BIOS

En sistemas compatibles con los IBM PCs, la BIOS (Basic Input/Output System) se trata del firmware encargado de ejecutar POST. Su función principal actualmente es inicializar el hardware, probar los componentes (POST) y cargar el programa de arranque, el encargado de ejecutar el kernel. Para más detalles de cómo carga este programa, puede consultar el artículo sobre archivos.

Fue desarrollado por IBM para los IBM PCs, y alguna compañías hicieron ingeniería inversa con el fin de crear sistemas compatibles. La interfaz original, debido a su gran popularidad en la época, sirve de estándar de facto.

Originalmente, la BIOS se almacenada en una memoria ROM escrita de fábrica. Con el fin de poder actualizar el firmware, ahora se suelen utilizar memorias flash. Nótese que estas actualizaciones son cruciales, dado que si falla dejando la memoria corrupta, no se podrá encender el sistema (brick). La configuración se guarda en una memoria no volátil (CMOS).

A mayores, la BIOS dispone procedimientos (BIOS system calls) para leer el teclado, escribir en la pantalla (texto o gráficos) y realizar operaciones básicas de E/S como por ejemplo acceder al disco. Sin embargo, estas operaciones suelen ser muy lentas y los SO prefieren reimplementarlas.

Otras funciones de la BIOS puede ser proveer la identificación del dispositivo del Original Equipment Manufacturer (OEM) y realizar overclocking.

Fuente: BIOS, Wikipedia (04-02-2024 23:00)

UEFI

[ -d /sys/firmware/efi ] && echo UEFI || echo BIOS

Extensible Firmware Interface (EFI) es una nueva variante diseñada para reemplazar BIOS, que se sitúa entre el firmware y el SO. Unified EFI_ (UEFI) es esencialmente EFI 2.x.

Secure Boot es una característica de EFI que intenta mejorar la seguridad asegurándose de que todos los boot loaders están firmados con una clave criptográfica. Para más información, puedes consultar la página de Rod Smith (tiene una lista de artículos sobre EFI en Linux) sobre Dealing with Secure Boot y Controlling Secure Boot.

La especificación EFI incluye una descripción de una nueva tabla de particiones: la GUID Partition Table (GPT) (más información en Wikipedia GPT), que aunque sistemas EFI puedan iniciarse usando particiones MBR, por lo general será mejor que se particione usando GPT directamente.

Para ver qué tipo de tabla de particiones se está usando, puede usar el siguiente comando:

sudo parted --list

EFI requiere una partición especial conocida como la EFI System Partition (ESP), que debe usar un sistema de archivos FAT32 y tiene un ID 0xEF si se usa MRB o C12A7328-F81F-11D2-BA4B-00A0C93EC93B (a veces representado como EF00) en GPT. Sobre el tamaño no hay un consenso, pero pueden haber problemas si es menor de 512 MiB.

La ESP contiene los drivers EFI, aplicaciones EFI, scripts EFI y programas de arranque EFI, entre otros. Cada programa de arranque tiene su propio subdirectorio: EFI/ubuntu o EFI/redhat, pero hay que tener en cuenta que esta partición se suele montar en /boot/efi, por lo que son /boot/efi/EFI/ubuntu y /boot/efi/EFI/redhat respectivamente. En caso de que no exista ningún programa de arranque, se usará el almacenado en EFI/BOOT.

Estos directorios contienen un archivo de arranque EFI de extensión .efi, otros archivos de configuración relevantes, kernels de Linux, archivos de RAM iniciales… Depende de cada programa.

A la hora de arrancar, EFI ejecuta el gestor de arranque y almacena en memoria principal una lista ordenada de los boot loaders a utilizar. Los va probando en orden iterativamente hasta que uno no regrese/return (los anteriores pudieron volver por algún error). Algunos vendedores disponen de una tecla (como F12) para acceder a este menú por defecto, pero es posible que sea necesario activarlo desde la configuración.

Este boot loader es el encargado de cargar el Sistema Operativo (en el caso de bootmgr de Windows), o a su vez, puede mostrar más menús para más opciones (Linux).

Es decir, cuando se instala un SO, es necesario añadir el boot loader a la partición ESP y además añadir su correspondiente entrada en el boot manager de EFI.

Además de todo esto, los sistemas EFI modernos incluyen un BIOS Compatibility Mode (CSM) que les permite arrancar usando la BIOS como se ha descrito anteriormente. Esto tiene el potencial de añadir muchas complicaciones, así que no se recomienda activar.

Proceso Hardware

Tras completar el proceso de arranque y de haber cargado el kernel en memoria, se debe de escoger qué tarea ejecutar a continuación. De esto se encarga el Gestor de Procesos.

En el caso de la figura solo se dispone de un core para ejecutar las tareas $P_1, P_2, \ldots, P_n$. Si hubiesen más cores, también se tendría que decidir qué hace cada uno, y en la figura se representaría por líneas paralelas, dado que se ejecutan simultáneamente.

Las aplicaciones del usuario (e.g.: un navegador) puede generar cada una muchas de estas tareas, pero hay otras que también se ejecutan, llamadas demonios (daemons). Siempre tiene que existir una tarea a ejecutar, dado que la CPU siempre debe estar ejecutando instrucciones. Por eso, existe la tarea idle, que simplemente ejecuta noop (no hacer nada) continuamente. Debe ser una intrucción que consuma poco. Esta tarea es la última elegible por el Gestor de Procesos.

Como se puede ver en la figura, se cambia de tarea constantemente, por ejemplo cuando hay una operación de Entrada/Salida. Se vuelve al gestor de procesos para decidir qué ejecutar a continuación, porque la tarea anterior está bloqueada, dado que necesita que se termine la operación de Entrada/Salida.

Por otro lado, las interrupciones son avisos que vienen de fuera, de dispositivos de Entrada/Salida: teclado, ratón, disco duro… El SO interrumpe la ejecución actual y salta al gestor de interrupciones para determinar su causa y cómo resolverla. Dicha interrupción podría ser que el usuario termina el scanf de otra tarea. Después de la interrución, es necesario llamar al gestor de procesos para decidir quién continua, puede ser la misma tarea de antes o otra distinta.

Resumiendo:

1. Se completa el Arranque del Sistema.
2. Se carga el Sistema Operativo en memoria principal.
3. Se llama al Gestos de Procesos para decidir qué tarea ejecutar.
4. Se decide ejecutar $P_1$.
5. Después de un rato, $P_1$ solicita una operación de Entrada/Salida que lo bloquea.
6. Se vuelve al planificador y se escoge otra tarea.
7. Después de repetir el proceso un par de veces, mientras se ejecuta la tarea $P_n$, se recibe una interrupción.
8. Se llama al gestor de interrupciones para descubrir la causa.
9. Se vuelve al planificador, que selecciona la tarea $P_2$. Por lo visto, la operación Entrada/Salida que había solicitado, ya está completada.
10. …

Este es el funcionamiento normal del Sistema Operativo.