Your Title - bootloader

tOSh para x86 - i386+ | Parte VI | Booteando en Diferentes Tipos de Máquinas

2026-09-18T17:19:19+00:00

Para descargar el Sistema Operativo tOSh, podés hacerlo desde la sección Resources de este mismo sitio.

Partes

Esta serie de artículos tiene las siguientes partes:

tOSh corriendo en 86Box

Release 2026.09 de tOSh

Este mes (Septiembre, 2026) logré que el sistema operativo bootee y funcione consistentemente en hardware real y emuladores. Gracias a amigos por prestarme hardware para probar por todos lados. Falla la disquetera en máquinas muy viejas, onda XTs y 286 que es esperable, porque salto a [Modo Protegido] casi al toque, pero la disquetera en algunas 386+ a veces no termina de poder leer archivos y termina fallando, reportado por el Kernel cosa que no está muy mal. En las pruebas, hubo algunas sugerencias que me hicieron donde quizá podría hacer un fallback al BIOS y hacer un wrapper pero no, creo que no voy a ir tan lejos.

Al menos por ahora.

En cambio cargar tOSh.img en variopintos emuladores es una tarea muy fácil e inclusive, divertida. Solamente bajate la imagen de floppy de Resources y montala en el emulador que más te guste.

Si querés correr tOSh.img en hardware real, vas a tener que transferir la imagen a un disco rígido del hardware que uses y usar algún programa como RAWrite y tener en cuenta que es una imagen de 1.44MB, para disquettes de 3" 1/2.

También dejé el código fuente de la última versión en Resources.

tOSh saludando a cámara

Si alguna vez sigo con este proyecto, no voy a darle más soporte a compus viejas, sino que voy a saltar directamente al Long Mode, habilitar un modo de video moderno, configurar varios CPUs y desbloquear todo lo que la arquitectura intel pueda ofrecer y reescribir todo lo que está incompleto de tOSh.

Referencias

Long Mode

tOSh para x86 - i386+ | Parte IV | Interrupciones

2023-02-06T07:43:04+00:00

Para descargar el Sistema Operativo tOSh, podés hacerlo desde la sección Resources de este mismo sitio.

Partes

Esta serie de artículos tiene las siguientes partes:

tOSh Kernel Panic!

Interrupciones

Que la arquitectura de las PCs de antaño y modernas estén basadas en Interrupciones, es precisamente por este chip, el Chip 8259a PIC de Intel. Una interrupción es una señal que recibe el CPU que frena temporariamente cualquier cosa que esté computando el CPU y de esta manera poder handlear (o manejar) un evento de mayor prioridad.

Para que la PC pueda interactuar con cualquier dispositivo electrónico suficientemente complejo, alguna interacción en mayor o menor medida con un CPU debe haber. Una de las opciones, era directamente ir preguntándole a cada dispositivo "¡Eu!, ¿Qué onda?".

Sin embargo al estar constantemente preguntando a los dispositivos conectados si necesitan algo, se pierde tiempo y recursos en cada una de las preguntas. A esta estrategia se la llama (Polling). Una de las soluciones propuestas para evitar hacer Polling es simplemente permitir que el CPU trabaje en sus cosas y programas normalmente y esperar por una señal en el momento en que se necesita atender una acción de alguien. Los dos dos tipos de interrupciones de CPU más comunes son por ejemplo:

Hardware Interrupts: Son enviadas asincrónicamente desde dispositivos físicos como mouse, teclado, discos rígidos, que cada tanto necesitan atención. Por ejemplo, apretar una tecla del teclado de una PC dispara una interrupción de hardware e INTERRUPE TODO y uno tiene que dejarlo que sea que esté ejecutando sea un Kernel o un programa en "Userspace" y debe atender inmediatamente la interrupción.
Software Interrupts: Excepciones o Traps, generadas internamente por el procesador o por un programa corriendo debido a un error ( como dividir por cero ) o por un request del sistema operativo via un system call.

¿Cómo se Handlea (maneja) una Interrupción?

Diego Silicio en su "sextillas interrumpidas" nos recuerda:

acá le venimo' a canta'
en compás he interrumpido
usted, amigo tupido
pero nunca 'ES' como humano
PICante es el paisano
en su línea se ha unido

Críptico el gaucho nos ha interrumpido, pero después de terminar este artículo desasnante, su canto será atendido por todos.

Cuando ocurre una interrupción, el CPU debería salvar el contexto de ejecución en algún lado. En el stack es un buen lugar. Entonces: Salvar contexto -> Ejecutar un Interrupt Service Routine ISR (vamos muy pronto con esto) -> Recuperar el contexto y seguir laburando. Antes de siquiera empezar a armar las rutinas de interrupción, las cuales vamos a handlear solamente un par y no todas por ahora, tengo que explicar aún más cosas, porque en el mundo del PC nada es, desafortunadamente, sencillo.

El PIC - Programmable Interrupt Controller

En una PC tradicional el Programmable Interrupt Controller o Chip 8259a PIC es el intermediario entro los dispositivos y el procesador. Los dispositivos no le hablan directamente al procesador. Estos están conectados al PIC mediante líneas de interrupción llamadas Interrupt Request o IRQs. El PIC recibe esas señales y se encarga de avisarle al CPU que hay alguien pidiendo atención.

Si leemos un toque el datasheet del Chip 8259a PIC vamos a encontrarnos que tiene 8 líneas de IRQ, de IRQ0 a IRQ7, y está todo bárbaro hasta que tenemos 9 o más dispositivos que conectar simultáneamente porque nos quedamos cortos. En algún momento de los 80s efectivamente se quedaron cortos con los dispositivos y como buenos ingenieros, le chantaron otro más, creando un esquema master/slave dos Chip 8259a PIC conectados en cascada.

Línea de Hardware	8259a PIC Chip	Vector Default	Remapeado Modo Protegido	Dispositivo Asignado	Puerto I/O Usado
IRQ 0	Master	`0x08`	`0x20`	Programmable Interrupt Timer (PIT)	`0x20` (Command), `0x21` (Data)
IRQ 1	Master	`0x09`	`0x21`	PS/2 Keyboard	`0x20` (Command), `0x21` (Data)
IRQ 2	Master	`0x0A`	`0x22`	Cascade Line (Connects Slave PIC)	`0x20` (Command), `0x21` (Data)
IRQ 3	Master	`0x0B`	`0x23`	COM2 / COM4 Serial Ports	`0x20` (Command), `0x21` (Data)
IRQ 4	Master	`0x0C`	`0x24`	COM1 / COM3 Serial Ports	`0x20` (Command), `0x21` (Data)
IRQ 5	Master	`0x0D`	`0x25`	LPT2 Parallel Port / Sound Card	`0x20` (Command), `0x21` (Data)
IRQ 6	Master	`0x0E`	`0x26`	Floppy Disk Controller	`0x20` (Command), `0x21` (Data)
IRQ 7	Master	`0x0F`	`0x27`	LPT1 Parallel Port (Spurious IRQ Line)	`0x20` (Command), `0x21` (Data)
IRQ 8	Slave	`0x70`	`0x28`	CMOS Real-Time Clock (RTC)	`0xA0` (Command), `0xA1` (Data)
IRQ 9	Slave	`0x71`	`0x29`	ACPI / PCI Peripheral Extended	`0xA0` (Command), `0xA1` (Data)
IRQ 10	Slave	`0x72`	`0x2A`	Open PCI Peripheral Slot	`0xA0` (Command), `0xA1` (Data)
IRQ 11	Slave	`0x73`	`0x2B`	Open PCI Peripheral Slot	`0xA0` (Command), `0xA1` (Data)
IRQ 12	Slave	`0x74`	`0x2C`	PS/2 Mouse Port	`0xA0` (Command), `0xA1` (Data)
IRQ 13	Slave	`0x75`	`0x2D`	Floating Point Unit / Coprocessor	`0xA0` (Command), `0xA1` (Data)
IRQ 14	Slave	`0x76`	`0x2E`	Primary ATA / IDE Hard Drive	`0xA0` (Command), `0xA1` (Data)
IRQ 15	Slave	`0x77`	`0x2F`	Secondary ATA / IDE Hard Drive (Spurious)	`0xA0` (Command), `0xA1` (Data)

Al usar el IRQ2 como Cascade Line entonces nos quedamos sin un IRQ pero los dispositivos attachados al slave pueden acceder a través de él.

Dispositivo → Slave → Master → CPU
Dispositivo → Master → CPU

Adicionalmente, el Chip 8259a PIC permite enmascarar interrupciones. Si estamos atendiendo el teclado y no queremos que se nos cuele la disquetera en ese momento, le decimos al PIC "esta IRQ en particular" no le des bola.

Esto es lo que hago cuando configuro las IRQs: tOSh solo implementa 3 nomás:

IRQ0 (timer / pit)
IRQ1 (teclado)
IRQ6 (floppy)

Todas las Interrupciones están enmascaradas menos estas tres que las desenmascaro especialmente para poder ser atendidas:

// idt.c

[...]

void interrupt_handler(uint32_t number)
{
    uint32_t irq = number - 32;
    switch (irq) {

        case 0:
            // timer (IRQ 0)
            pit_irq_handler();
            break;

        case 1:
            // Keyboard (IRQ 1)
            kbd_handler();
            break;

        case 6:
            // Floppy (IRQ 6)
            floppy_irq_handler();
            break;

        default:
            break;
    }

    pic_eoi(irq);
}

La IDT - Interrupt Descriptor Table

La IDT es una estructura de datos binaria específica para las arquitecturas IA-32 y x86-64 y es la contrapartida del Modo Real y el Long Mode IVT. Configurar la IDT nos permite decirle a la CPU donde están nuestras ISR o Interrupt Services Routines, que son las funciones que tenemos que escribir nosotros para poder manejar las interrupciones que el procesador o dispositivos disparen. Es bastante parecida a la estructura de la GDT.

A continuación va la tabla de Interrupciones del Modo Protegido de Intel:

Int. Nº (hex)	Int. Nº (dec)	Mnem.	Type	Err. code	Name	Source
0x00	0	#DE	Fault	No	Divide Error	DIV and IDIV instructions.
0x01	1	#DB	Trap	No	Debug Exception	Instruction, data, and I/O breakpoints; single-step; and others.
0x02	2	NMI	Interrupt	No	NMI Interrupt	Nonmaskable external interrupt.
0x03	3	#BP	Trap	No	Breakpoint	INT3 instruction.
0x04	4	#OF	Trap	No	Overflow	INTO instruction.
0x05	5	#BR	Fault	No	BOUND Range Exceeded	BOUND instruction.
0x06	6	#UD	Fault	No	Invalid Opcode (Undefined Opcode)	UD instruction or reserved opcode.
0x07	7	#NM	Fault	No	Device Not Available (No Math Coprocessor)	Floating-point or WAIT/FWAIT instruction.
0x08	8	#DF	Abort	Yes (zero)	Double Fault	Any instruction that can generate an exception, an NMI (Non-maskable interrupt), or an INTR (external interrupt).
0x09	9	—	Fault	No	Coprocessor Segment Overrun (reserved)	Floating-point instruction.
0x0A	10	#TS	Fault	Yes	Invalid TSS	Task switch or TSS access.
0x0B	11	#NP	Fault	Yes	Segment Not Present	Loading segment registers or accessing system segments.
0x0C	12	#SS	Fault	Yes	Stack-Segment Fault	Stack operations and SS (stack segment) register loads.
0x0D	13	#GP	Fault	Yes	General Protection	Any memory reference and other protection checks.
0x0E	14	#PF	Fault	Yes	Page Fault	Any memory reference.
0x0F	15	—	—	No	Intel reserved. Do not use.	—
0x10	16	#MF	Fault	No	x87 FPU Floating-Point Error (Math Fault)	x87 FPU floating-point or WAIT/FWAIT instruction.
0x11	17	#AC	Fault	Yes (zero)	Alignment Check	Any data reference in memory.
0x12	18	#MC	Abort	No	Machine Check	Error codes (if any) and source are model dependent.
0x13	19	#XM	Fault	No	SIMD Floating-Point Exception	SSE/SSE2/SSE3 floating-point instructions.
0x14	20	#VE	Fault	No	Virtualization Exception	EPT violations.
0x15	21	#CP	Fault	Yes	Control Protection Exception	RET, IRET, RSTORSSP, and SETSSBSY instructions can generate this exception. When CET indirect branch tracking is enabled, this exception can be generated due to a missing ENDBRANCH instruction at target of an indirect call or jump.
0x16–0x1F	22–31	—	—	—	Reserved for future use as CPU exception vectors.	—
0x20–0xFF	32–255	—	Interrupt	No	—	External interrupts.

Un error común es confundir los IRQ del Chip 8259a PIC con las INTerrupciones. NO SON LO MISMO!!!!!1 Una IRQ es la línea física del hardware. El número de interrupción es la entrada que usa el CPU en la IDT. Son dos cosas relacionadas, pero no son lo mismo, y el que las conecta es justamente el remapping del PIC.

El número de interrupción funciona como índice dentro de la tabla: llega la interrupción, el CPU busca la entrada correspondiente y salta directo al código que configuramos para atenderla.

Remapping

Ya se está oliendo el problema, ¿verdad? Los valores de los IRQ y las Interrupciones del CPU (QUE NO SON LO MISMO!!!!!!!!!!1) se solapan. Este solapamiento hace que tengamos que mover o remapear los valores de los IRQ después de la tabla de INTerrupciones del CPU. Las primeras 32 entradas de la IDT (vectores del 0 al 31) están reservadas para excepciones del propio x86 (divide by zero error, general protection fault, etc..) y los IRQ del PIC también arrancan desde del 0, solapándose.

Por eso al arrancar nuestro Kernel tenemos que reconfigurar el PIC para que corra arriba de la zona de la tabla de INTerrupciones del CPU de la siguiente manera:

PIC	IRQ Original	IRQ Destino
Master	IRQ0 - IRQ7	INT 32 - INT 39
Slave	IRQ8 - IRQ15	INT 40 - INT 47

Presione cualquier tecla para continuar…

Pongamos como ejemplo, presionar la tecla cualquiera. La lógica de cualquier teclado de PC, por cada tecla presionada, genera un scancode al controlador del teclado. Este controlador genera un IRQ, que en nuestro caso, es el IRQ1 (ver tabla más arriba). El que recibe este IRQ es el Chip 8259a PIC que verifica que la interrupción esté habilitada (o desenmascarada), la marca como pendiente y le manda una señal al CPU mediante la línea INTR. La CPU acepta la interrupción y el PIC deliverea el vector correspondiente. Si la IRQ1 esta remapeada al vector 0x21, la CPU usa ese vector para consultar la IDT y ver en que posición de memoria va a encontrar el manejador de interrupción correspondiente (interrupt handler).

Este es el de tOSh, solamente soportamos un Timer, el Teclado y el Floppy:

/* de idt.asm, declaramos esta y otras funciones como "extern" */

void interrupt_handler(uint32_t number)
{
    uint32_t irq = number - 32;
    switch (irq) {

        case 0:
            // timer (IRQ 0)
            pit_irq_handler();
            break;

        case 1:
            // Keyboard (IRQ 1)
            kbd_handler();
            break;

        case 6:
            // Floppy (IRQ 6)
            floppy_irq_handler();
            break;

        default:
            break;
    }

    pic_eoi(irq);
}

Y desde las rutinas en idt.asm donde declaramos como vamos a cargar el handler, creamos esta función:

[...]

extern interrupt_handler

[...]

irq_common:
    pusha

    ; ESP apunta ahora al comienzo de pusha:
    ;
    ; [ESP + 0]  EDI
    ; [ESP + 4]  ESI
    ; [ESP + 8]  EBP
    ; [ESP + 12] original ESP
    ; [ESP + 16] EBX
    ; [ESP + 20] EDX
    ; [ESP + 24] ECX
    ; [ESP + 28] EAX
    ; [ESP + 32] interrupt number
    ; [ESP + 36] error code
    ; [ESP + 40] EIP
    ; [ESP + 44] CS
    ; [ESP + 48] EFLAGS

    mov eax, [esp + 32]         ; +32 = interrupt number 
    push eax
    call interrupt_handler
    add esp, 4

    popa
    ; remove interrupt number + fake error code
    add esp, 8
    iret

[...]

La CPU entra al handler correspondiente a través de nuestro extern interrupt_handler que es llamado en irq_common y hace un call a nuestro código en C que termina ejecutando la función kbd_handler(). Como se puede ver, guardamos con pusha el contexto de ejecución porque cualquier cosa que haya estado haciendo la CPU, la tenemos que salvar para hacer lo que tengamos que hacer y al volver de nuestro call interrupt_handler recuperar el contexto y volver con iret de nuestra interrupción.

Tenemos todo cubierto. El kbd_handler() y todo lo que tiene que ver con el teclado es bastante un embole porque es mapear scancodes con funciones de teclado (CTRL+C hacé esto, SHIFT + minúscula transforma a mayúscula, etc…) como phun phakt, este pedazo de Kernel me llevo años desarrollarlo porque al ver lo que tenía que codear, me daba paja y por un par de años me dio cosa copiar algunas implementaciones piolas que encontré de otras personas en GitHub, pero hace poco se me pasó y me inspiré muy fuertemente. Lamentablemente hoy, no recuerdo bien de quienes, pero hey, gracias.

Como pueden ver en la funcion C interrupt_handler() hay una llamada a la función pic_eoi(). No basta con un iret para indicar que se está volviendo de una interrupción, también hay que decírselo al PIC para decirle que terminamos de atender la IRQ también.

La CPU finalmente, vuelve al programa que fue interrumpido, continuando exactamente en el EIP en la que se había detenido.

Y listo. Terminamos.

¡wh0a, te falta el APIC! (Advanced Programmable Interrupt Controller)

¡Ah no! ¡Pará! Me queda hacer una aclaración. APIC es el reemplazo del Chip 8259a PIC y hasta hoy, tOSh no lo soporta. De alguna manera, soportar APIC permitiría poder manejar entre todas las cosas que soporta, más CPUs (dualcore en adelante), pero en este momento del desarrollo me estoy peleando con enmascaramiento de interrupciones y programar un teclado.

Así que lo dejamos para más adelante. :)

Referencias

tOSh para x86 - i386+ | Parte III | Saltando a C

2020-06-23T07:43:04+00:00

Para descargar el Sistema Operativo tOSh, podés hacerlo desde la sección Resources de este mismo sitio.

Partes

Esta serie de artículos tiene las siguientes partes:

Armando Máquina de 1997

Saltando a C

A veces, mientras escribo esta serie, me hago la pregunta que si es necesario estar explicando todos los conceptos de cada palabra especializada que uso como Kernel y nunca sé bien cuán profundo tengo que ir en mis artículos. Después lleno los términos de links y se me pasa. Mientras escribo exactamente esta oración me estoy preguntando: ¿Tengo que explicar que es un Kernel? Me parece que no. Si estás leyendo esto, asumo que sabés un montón. Y si no, igual te lleno de links por cada término técnico que uso para que puedas seguir investigando por tu cuenta.

Bien. Tenemos que armar un Kernel, porque ya estamos saltando a él, pero no hablamos de nada sobre como empezar a escribir bytes para un sistema operativo desde C.

Lo primero y quizá lo más importante de todo lo que tenés que saber sobre desarrollo de Kernel es que no podés programar así nomás, pim pam pum, agarro un gcc o un clang ¡paf! le chanto un main.c y a compilar y meter el binario donde se te cante. ¡Noooooo! Lo que necesitás hacer primero es prepararte un crosscompiler, es decir, un compilador que permita escribir binarios para otras arquitecturas sin depender de las bibliotecas que vienen con el sistema operativo o sus ABI objetivo porque no hay ABI. Es decir, no hay librerias, no hay interfaces, no hay syscalls, no hay nada porque no tenés kernel, ¡porque estás haciendo uno!

Parece una obviedad mencionar esto, pero si nos detenemos un segundo a pensar, uno está acostumbrado a tener cientos de capas de abstracción que evitan estar interactuando con el CPU y resolver cientos de problemas que se computan casi mágicamente con una o dos llamadas a función. Hacer un printf estándar de C es sorprendentemente complicado y es un rabbit hole en el cual hoy no, pero algún día entraré.

Dicho todo esto recomiendo fuertemente leer el artículo GCC Cross-compiler de osdev.

De KMain, Linkers y Bash

Este va a ser nuestro Kernel por ahora. Lo único que va a hacer es escribir el caracter "X" en la posición de memoria VGA xb8000 que es el área de memoria donde la placa de video está mirando su contenido para replicarlo en el monitor correspondiente y eventualmente terminamos crasheando el CPU porque seguimos escribiendo linearmente hasta 2^32 - 1 o mejor aún, hasta el límite de la memoria que tengamos instalada en el hardware.

__attribute__((section(".text.kmain_entrypoint")))
int kmain(void) {

    char * vga = (char *) 0xb8000;
    *vga = 'X';

    while(1){
        *(vga++) ='X';
    };

    char * str = "end of kernel code.";
    return 1;
}

Compilar este código requiere por lo menos el siguiente Makefile. Primero definimos donde tenemos la instalación de nuestra versión Crosscompilada de GCC que compilamos siguiendo las instrucciones en del artículo GCC Cross-compiler de osdev.

ASM=nasm
CROSS_DIR=~/opt/cross/bin
CC=$(CROSS_DIR)/i686-elf-gcc
AS=$(CROSS_DIR)/i686-elf-as 
LD=$(CROSS_DIR)/i686-elf-ld

Luego seteamos los siguientes flags del compilador:

-m32 le dice a GCC que genere código 32 bits. Es decir, registros generales en 32 bits (eax, ebx, ebp, esp, edi, esi, etc…), punteros de 32 bits, ABI de 32 bits, instrucciones compatibles con el modo protegido de 32 bits.
-std=gnu99 es la versión c99 del estándar C con extensiones GNU, del año 1999.
-Ttext 0x10000 flag de linker, le dice al linker que la sección .text comienza en la dirección 0x10000
-ffreestanding le decimos a GCC que no asuma que tenemos funciones estandar del runtime de C como malloc(), printf(), etc…
-fno-pic desactivamos Position Independent Code, con saber que todo el Kernel arranca en 0x10000 en adelante es suficiente.
-fno-asynchronous-unwind-tables y -fno-unwind-tables desactivamos la metadata que genera GCC para reconstruir excepciones, tracebacks, stacktraces, en caso de error. Reducimos el tamaño del binario con esto pero nos limitamos las capacidades para debuggear también.
-march=i486 reducimos el set de instrucciones bien atrás hasta 486 para evitar instrucciones avanzadas (onda, la instruciones de la familia pentium para arriba) limitando la compatibilidad con CPUs más viejas. Por ahora, tOSh corre a partir de i386.
-Map kernel.map es una opción del linker y nos sirve para crear un mapa de memoria y ubicar en que offsets está cada función y sección del binario

CCFLAGS= -m32 -std=gnu99 -Ttext 0x10000 
CCFLAGS+= -ffreestanding -O0 -Wall -Wextra -fno-pic
CCFLAGS+= -fno-asynchronous-unwind-tables
CCFLAGS+= -fno-unwind-tables
CCFLAGS+= -march=i486 # avoid instructions like cmovna to be generated by gcc
LDFLAGS= -Map kernel.map

Finalmente definimos un Makefile estandar. No hay nada loco aca, tenemos .o, .map, y algo especial que es nuestro archivo linker.ld.

KERNEL_SRC=$(wildcard kernel/*.c)
KERNEL_OBJS=$(KERNEL_SRC:.c=.o)
KERNEL_BIN=kernel.bin

all: kernel 

clean:
	rm -rf *.bin 
	rm -rf *.o
	rm -rf *.map
	rm -rf *.img
	rm -rf kernel/*.o
	rm -rf *.lst

%.o: %.c
	$(CC) -o $@ -c $< $(CCFLAGS)


kernel: $(KERNEL_OBJS)
		$(LD) -o $(KERNEL_BIN) $^ $(LDFLAGS) -Tkernel/linker.ld

El script del Linker

Cuando compilás, GCC genera unos archivos .o que contienen código y datos pero cada uno está pensado como un cacho independiente del otro. Además, cada .o tiene varias secciones, como .text, .rodata, .bss, etc… El linker lo que hace es agarrar todos esos .o que se generan al compilar uno o varios archivos .c y construye un programa ubicando cada uno de esos Código OBJeto y posicionarlos decidiendo donde quedan exactamente cada uno de ellos en memoria. Adicionalmente, resuelve referencias. Si la funcion pepito_delicioso() está programada en mi_libreria_de_pepitos.c, ese código va a estar en mi_libreria_de_pepitos.o y si mi funcion kmain.c la llama, el linker se encarga de resolver esas referencia a esa función.

El archivo linker.ld es un linker script y es un archivo que le dice al linker que no ubique los OBJ como se le cante, sino más bien, vos le decís donde querés que ubique cada cosa en memoria. Definiendo secciones nuevas o donde empieza .text uno tiene más control del layout de tu programa en memoria.

OUTPUT_FORMAT("binary")
/*ENTRY(kmain)*/
SECTIONS
{
    /* the start address of the kernel's .text section */
    . = 0x10000;

    .text BLOCK(4K) : ALIGN(4K)
    {
        /* *(.text.prologue) */

        /* 
            set up the program entry point 
            kmain.c should have only one function,
            and it's going to be the first section of code executed
            when jumping to the kernel.
            in the generated kernel.map file, kernel/kmain.o should be 
            set at address 0x0000000000010000

            and void kmain(void); should be the first function written on top 
            of the program
        */
        *(.text.kmain_entrypoint)

        /* and later on, all the kernel objects */
        *(.text)
    }

    .rodata BLOCK(4K) : ALIGN(4K)
    {
        *(.rodata)
    }

    .data BLOCK(4K) : ALIGN(4K)
    {
        *(.data)
    }

    .bss BLOCK(4K) : ALIGN(4K)
    {
        *(.bss)
    }

    .idt BLOCK(4K) : ALIGN(4K)
    {
        *(.idt)
    }
    
    .dma BLOCK(4K) : ALIGN(4K)
    {
        *(.dma)
    }

    end = .;
}

Al principio de todo, definimos OUTPUT_FORMAT(\"binary\"). Esto hace que el linker de gcc, no genere un archivo ejecutable .elf sino un .bin directamente que no tiene ni headers, ni tablas, ni simbolos de debugging, nada. Un binario plano. Nuestro Kernel no sabe nada de formatos binarios ni nada y si saltamos a un .elf el CPU va a ejecutar los bytes del header del formato ELF crasheando el CPU.

Con . = 0x10000; dentro de SECTIONS le decimos a linker que empiece a ubicar los binarios a partir de esa dirección. Esto apunta a .text, o sea que lo que le pasamos al Makefile donde le decimos donde empieza la seccion .text es redundante.

Despues, cada una de las secciones tienen que ser bloques y ademas estar alineados en "páginas de 4 kilobytes". Este tamaño, 4Kb, es el definido como página en x86. No solo las secciones tienen que estar en bloques de 4kb, sino que además tienen que estar alineados de a bloques de 4kb.

La primera sección ejecutable se llama: .text.kmain_entrypoint y lo que hacemos definiendolo asi es que sea cual fuere la función en C que tenga este atributo, se le chanta ahi, que es la dirección de memoria 0x10000 que ya habíamos definido y de esa manera nos aseguramos que esa funcion sea la primer función que se ejecute.

Si te fijás más arriba, en el código en C que presente primero, vas a ver arriba de kmain()el attributo que el linker va a tomar del script para que sea lo primero que se ejecute de todo:

/*
0x10000 <-- arrancando en esta dirección de memoria
*(.text.kmain_entrypoint) <-- primero mete esta función
*(.text) <-- despues el resto de funciones
+-------------------------------+
| kmain_entrypoint              | <- PRIMERO
+-------------------------------+
| otras funciones .text         |
| configurar_cosas()            |
| contemplar_existencia()       |
| handlear_interrupciones()     |
| etc.                          |
+-------------------------------+
*/
__attribute__((section(".text.kmain_entrypoint")))
void kmain(void) { [...] }

Las secciones siguientes como .bss, .rodata y .data son estandard pero las que quedan no, son específicas del diseño de mi Kernel.

La sección .idt la vamos a necesitar en un futuro cuando definamos la tabla de interrupciones de alguna manera como la siguiente:

    .idt BLOCK(4K) : ALIGN(4K)
    {
        *(.idt)
    }

__attribute__((section(".idt")))
struct idt_entry idt[256];

Lo mismo hacemos con la sección .dma que vamos a usar en un futuro también para guardar unos bùferes:

.dma BLOCK(4K) : ALIGN(4K)
{
    *(.dma)
}

__attribute__((section(".dma")))
uint8_t dma_buffer[...];

Entonces más o menos el layout de memoria del Kernel quedaría más o menos así:

0x10000

+--------------------------+
| .text                    |
|                          |
| kmain()                  | <- primera función de todas, el entrypoint
| fs_init()                |
| fs_read()                |
| idt_init()               |
| ...                      |
+--------------------------+
| .rodata                  |
| strings / constantes     |
+--------------------------+
| .data                    |
| variables inicializadas  |
+--------------------------+
| .bss                     |
| variables sin init       |
+--------------------------+
| .idt                     |
| IDT                      |
+--------------------------+
| .dma                     |
| DMA buffers              |
+--------------------------+
|                          |
| end                      |
+--------------------------+

La Gotita

Finalmente para unir y pegar con "La Gotita" todas las piezas del rompecabezas y tener una imagen para chantarle a qemu, bochs o una máquina real, necesitamos generar una imagen donde esté el bootloader, stage1 y el kernel y cada uno de sus binarios estén ubicados de manera tal el bootloader y el stage1 copien las cosas en memoria y que en el proceso de recompilar y programar, no se pisen los binarios entre si y estén lo suficientemente equiespaciados.

Para lograr esto, tuvimos que sentarnos con un papel y decir cuanto espacio suficiente siendo "suficiente" una variable que cambió bastante a lo largo del desarrollo de este Kernel. Más o menos este es mi layout del Floppy 3.5" 1.44MB que uso para meter el Sistema Operativo en él (update agosto 2026):

Sectores	Offset	Contenido	Tamaño
1	`0x000000`	Bootsector (`boot.bin`)	512 B
2–8	`0x000200–0x000FFF`	Espacio reservado / Stage1	hasta 7 sectores
9–136	`0x001000–0x10FFF`	Kernel (`kernel.bin`)	hasta 128 sectores
137–2880	`0x11000–0x167FFF`	Filesystem / espacio restante	~1.37 MB

#!/bin/sh
echo "Cleaning up..."
make clean

echo "Compiling tOSh Kernel..."
make

kernel_size=$(stat -c %s kernel.bin)
kernel_sectors=$(( (kernel_size + 511) / 512 ))

MAX_KERNEL_SECTORS=128
KERNEL_FIRST_SECTOR=9
echo "kernel size: $kernel_size bytes, kernel sectors: $kernel_sectors"


if [ "$kernel_sectors" -gt "$MAX_KERNEL_SECTORS" ]; then
    echo "ERROR: kernel too large!"
    echo "Maximum: $((MAX_KERNEL_SECTORS * 512)) bytes"
    exit 1
fi

echo "Compiling bootsector and stage1..."
echo "taking into account the kernel size of $kernel_size bytes, which is $kernel_sectors sectors..."

echo "bootsector.asm -> boot.bin"
nasm -f bin bootsector.asm -o boot.bin


echo "Kernel first sector: $KERNEL_FIRST_SECTOR"

echo "stage1.asm -> stage1.bin with KERNEL_FIRST_SECTOR=$KERNEL_FIRST_SECTOR and KERNEL_SECTORS=$kernel_sectors"
nasm -D KERNEL_FIRST_SECTOR=$KERNEL_FIRST_SECTOR -D KERNEL_SECTORS=$kernel_sectors -f bin -l stage1.lst stage1.asm -o stage1.bin

stage1_size=$(stat -c%s stage1.bin)
stage1_sectors=$(( (stage1_size + 511) / 512 ))
echo "Stage1 size: $stage1_size bytes, $stage1_sectors sectors"

#nasm -f bin kernel/kernel.asm -o kernel.bin

echo "Creating floppy image..."
dd if=/dev/zero of=tOSh.img bs=512 count=2880

echo "Copying Bootsector at position 0, block 512 bytes..."
dd if=boot.bin of=tOSh.img conv=notrunc # copy the bootsector

echo "Copying stage1 at position 1, block 512 bytes..."
dd if=stage1.bin of=tOSh.img conv=notrunc bs=512 seek=1 # copy stage1

echo "Copying kernel at position $((KERNEL_FIRST_SECTOR -1)) (sector $KERNEL_FIRST_SECTOR), block 512 bytes..."
dd if=kernel.bin of=tOSh.img conv=notrunc bs=512 seek=$(($KERNEL_FIRST_SECTOR -1)) # copy kernel

Ejecutando este script de bash ./build.sh crea el sistema operativo en una imagen de floppy lista para ser booteada en una máquina o un emulador. Hasta acá lo único que hacemos es escribir X en memoria (empezando por el mapping de VGA) hasta que la CPU crashea por escribir fuera de los límites de memoria.

Este es el framework "básico" para poder empezara desarrollar un Kernel en C. A partir de ahora podemos seguir configurando la CPU, programarle drivers y aprovechar todas las bondades de un lenguaje de alto nivel como C abandonando así, el assembly.

Referencias

tOSh para x86 - i386+ | Parte II | Stage 1 y Modo Protegido

2020-06-23T07:43:04+00:00

Para descargar el Sistema Operativo tOSh, podés hacerlo desde la sección Resources de este mismo sitio.

Partes

Esta serie de artículos tiene las siguientes partes:

Turbo Debugger - Not Enough Memory

Stage I - De Modo Real a Modo Protegido

Estamos en el Real Mode, lo último que hicimos fue saltar a otra posición de memoria donde deberíamos haber podido copiar otra parte de código binario que llamaremos stage1 que tomamos de un sector del Floppy donde estamos compilando y guardando todo el bootloader como vimos en la primera parte de esta serie y ahora toca ver que hacemos con el control de nuestra CPU. Esto me hace recordar algunas sextillas gauchescas de nuestro querido Diego Silicio, gaucho del cátodo:

Atendiendo la obligada,
no se haga el distraído
no se olvide la pavada,
ni se pierda el protegido,
que es cuestión de buen formato,
¡memorí laiaut bendito!

Para poder entender mejor que es lo que vamos a hacer, y como vamos a configurar el CPU para que cambie de Modo tenemos que entender nuestro Memory Layout (memorí laiaut) y donde estamos decidiendo casi arbitrariamente –y esto es mucho muy importante, lo ‘casi’ arbitrario– donde vamos a copiar todo en memoria, este mismo stage1.bin el cual cargamos del disco a memoria y saltamos y empezamos a correr con la última instrucción del bootloader: jmp 0x9000.

Primero cabe explicar que el Memory Layout de maquinas x86 ya está definido y hay direcciones de memoria que tienen overlays con componentes y periféricos los cuales usamos para comunicarnos con ellos. Esto significa que no podemos simplemente usar secciones de memoria ya que están siendo usadas por otros dispositivos y la CPU para comunicarse entre si, el BIOS en 0040:0000h y también interfasear con el usuario. Vamos a tomar como ejemplo la tabla que podemos encontrar en el documento Physical Memory Layout of the PC y mezclarla con nuestro layout. La idea es en primer lugar evitar sobreescribir estas regiones de memoria que no nos pertenecen y por el otro, encontrar un hueco donde nos podamos meter nosotros a escribir memoria para nuestro código para el stage1.bin y en un futuro, nuestro kernel.bin. Deberíamos tener suficiente espacio para todo sin sobreescribir nada.

rango de memoria lineal	rango de direccion modo real	tipo de memoria	uso
0- 3FF	0000:0000-0000:03FF	RAM	real-mode interrupt vector table (IVT)
400- 4FF	0040:0000-0040:00FF	RAM	BIOS data area (BDA)
500- 9FBFF	0050:0000-9000:FBFF	RAM	free conventional memory (below 1 meg)
0x9000 + (512bytes * 4 sectores)	0900:0000 – 0900:07FF	RAM (stage1.bin)	nos metemos por aca, debajo el primer mega de memoria
0x10000 + (512bytes * n sectores)	¡NOS CHUPA UN HUEVO!	RAM (kernel.bin)	a estas alturas, ya deberiamos estar en Modo Protegido
0x80000	¡NOS CHUPA UN HUEVO!	RAM (stack)	El stack que va a ser usado por el kernel y nuestros programas
9FC00- 9FFFF	9000:FC00-9000:FFFF	RAM	extended BIOS data area (EBDA)
A0000- BFFFF	A000:0000-B000:FFFF	Video RAM	VGA framebuffers
C0000- C7FFF	C000:0000-C000:7FFF	ROM	video BIOS (32K is typical size)
C8000- EFFFF	C800:0000-E000:FFFF	NOTHING
F0000- FFFFF	F000:0000-F000:FFFF	ROM	motherboard BIOS (64K is typical size)
100000- FEBFFFFF		RAM	free extended memory (1 meg and above)
FEC00000- FFFFFFFF	various		motherboard BIOS, PnP NVRAM, ACPI, etc.

Teniendo todo esto en cuenta, podemos empezar a ver un poco de código, stage1.asm:

; ----------------------------------------------------
; tOSh Operating System, Huh?                 (c) 2019
; stage1.asm                                  by toshi   
; $ nasm -D KERNEL_FIRST_SECTOR=$KERNEL_FIRST_SECTOR \
;   -D KERNEL_SECTORS=$kernel_sectors \
;   -f bin -l stage1.lst stage1.asm -o stage1.bin
; ----------------------------------------------------

bits 16
org 0x9000                  ; we copied sector 2+ here!
[map symbols stage1.map]    ; create a stage1.map file for offsets checking

KERNEL_OFFSET equ 0x10000
STACK_ADDRESS equ 0x80000

Todo lo que se ensamble va a ser en 16 bits relativo a org 0x9000. Adicionalmente vamos a crear un mapa de símbolos que nos va a ayudar a ver los offsets de las funciones en caso que los necesitemos en el desarrollo con la directiva map symbols.

Entre varias ventajas, la que más útil me parece a mi es poder llevar el apunte de los equ, los nombres de función y sus posiciones de memoria al haber sido ensambladas inclusive cuando stage1.asm tiene varios %include.

map symbols stage1.map produce un archivo que tiene la siguiente pinta:

- NASM Map file ---------------------------------------------------------------

Source file:  stage1.asm
Output file:  stage1.bin

-- Symbols --------------------------------------------------------------------

---- No Section ---------------------------------------------------------------

Value     Name
00010000  KERNEL_OFFSET
00080000  STACK_ADDRESS
00000008  CODE_SEGMENT
00000010  DATA_SEGMENT
000B8000  VRAM


---- Section .text ------------------------------------------------------------

Real              Virtual           Name
            9023              9023  prepare_protected_mode
            903B              903B  load_kernel
            9052              9052  load_kernel.next_sector
            9070              9070  load_kernel.destination_ok
            908A              908A  load_kernel.done
            908F              908F  load_error
            909A              909A  kernel_sectors_remaining
            909C              909C  error_hang
            90A7              90A7  init_protected_mode
            90E7              90E7  protected_mode_msg
            9108              9108  kernel_load_fail_msg
            9121              9121  kernel_load_msg
            9148              9148  gdt_start
            9150              9150  gdt_code_segment
            9158              9158  gdt_data_segment
            9160              9160  gdt_descriptor
            9166              9166  gdt_end
            9166              9166  enable_A20
            9196              9196  a20wait
            919D              919D  a20wait2
            91A4              91A4  asm_print_protected
            91AA              91AA  asm_print_protected.loop
            91BD              91BD  asm_print_protected_end
            91BF              91BF  asm_print_hex
            91D0              91D0  asm_print_hex.loop
            91E2              91E2  asm_print_hex.digit
            91E5              91E5  asm_print_hex.write

Después de cambiar el fondo de pantalla a gris -podés ver esto en el código fuente del OS en la sección Resources - hacemos una call a load_kernel que escencialmente lo que hace es copiar el binario del kernel (que todavía está en veremos) a la posición de memoria arbitraria 0x10000, definida en el KERNEL_OFFSET equ 0x10000 más arriba.

load_kernel:
    ; ---------------------------------------------------------
    ; Load KERNEL_SECTORS sectors from floppy into 0x10000
    ;
    ; Floppy geometry:
    ;   80 cylinders
    ;   2 heads
    ;   18 sectors per track
    ;
    ; Kernel starts at KERNEL_FIRST_SECTOR
    ; check build.sh for sector calculations
    ; ---------------------------------------------------------

    push ax
    push bx
    push cx
    push dx

    ; Destination = 0x10000 + n bytes, ES = 0x1000, BX = copy n bytes offset
    xor bx, bx
    mov ax, 0x1000
    mov es, ax

Una cosa para destacar en este listado (phuá, "listado" le mandé, volvimos a los 80s!) es el cuidado que hay que tener haciendo algo que voy a llamar ‘aritméticas de segmentos’ porque no se bien como llamarlo. Cada vez que, en 16 bits, tenés que escribir algo en memoria, tenés que tener en cuenta siempre en el segmento en el que vas a operar y como las instrucciones los usan o no y tener en cuenta la relacion que hay entre la dirección de memoria "logica" y la física teniendo en mente siempre la siguiente fórmula:

Dirección Física = (Segmento * 16) + Desplazamiento

Todo esto tiene que ver con como poder direccionar más de 64 kilobytes (o sea, 2^16 son 16 bits) cuando físicamente tenés uno, dos o más megabytes. Bueno, los muchachos de intel lo resolvieron asi y esto trae bastante dolores de cabeza porque esta aritmética hace que las direcciones no sean únicas y se generen solapamientos. La copia del Kernel a memoria la hago asi y después salto a Modo Protegido donde este problema desaparece y en el momento que estaba tratando de copiar un binario a memoria use las funciones del BIOS para copiar del diskette a memoria el kernel, porque quería darle soporte a 286 que tiene un modo protegido falopa y después se me complicó y quedó asi.

load_kernel funciona y cuando logré darle la vuelta para copiar el kernel y que funcione, no lo quise tocar más.

Si entendés mas o menos que estoy haciendo exactamente en:

    xor bx, bx
    mov ax, 0x1000
    mov es, ax

donde estoy preparando la copia, vas a ver que en vez de pararme en 0x10000 que sería lo lógico, me paro en <--> Segmento:Desplazamiento <--> 0x1000:0x0000 <--> ES:BX estoy haciendo absuso de notación para que se "NOTE BIEN" lo que estoy diciendo porque esto es fundamental para entender porque las cosas nunca caen en memoria donde uno espera.

O sea, por todo lo dicho:

Memoria Fisica: 0x10000 (cinco ceros) <—> 1000:0000 (cuatroceros, cuatroceros)

Y porque el segmento va en ES? cuando llamas a INTerrupciones o algunas instrucciones usan SEGmentos para operar. Es convención y los detalles estan en los manuales de intel y Ralf Brown’s Interrupt List,

pues le digo, mi ingeniero
que tiene la segmentación
pa' que no falte ocasión
y no se le pase el viaje
a esos bites ni el anclaje
ni una horrible excepción

Lo que sigue en la función load_kernel es una rutina estándar de copia de de sectores del disquette a memoria:

    ; Current CHS
    xor ch, ch                  ; cylinder = 0
    mov dh, 0                   ; head = 0
    mov cl, KERNEL_FIRST_SECTOR ; sector

    ; Number of sectors remaining
    mov word [kernel_sectors_remaining], KERNEL_SECTORS

.next_sector:

    cmp word [kernel_sectors_remaining], 0
    je .done

    ; BIOS read: exactly ONE sector
    mov ah, 0x02
    mov al, 1
    mov dl, 0                   ; floppy drive A:

    int 0x13
    jc load_error

    ; ---------------------------------------------------------
    ; Advance destination by 512 bytes
    ; ---------------------------------------------------------

    add bx, 512

    ; If BX wrapped around, advance ES by 0x1000
    ; because 0x1000:0000 -> 0x2000:0000
    jnc .destination_ok

    mov ax, es      ; yuck! 
    add ax, 0x1000  ; we are going to leave all this 
    mov es, ax      ; segment:offset madness very soon!

.destination_ok:

    ; One less sector to load
    dec word [kernel_sectors_remaining]

    ; ---------------------------------------------------------
    ; Advance CHS
    ; ---------------------------------------------------------

    inc cl                      ; next sector

    cmp cl, 19                  ; floppy has sectors 1..18
    jb .next_sector

    ; End of track -> next head
    mov cl, 1
    inc dh

    cmp dh, 2                   ; heads 0 and 1
    jb .next_sector

    ; End of cylinder -> next cylinder
    mov dh, 0
    inc ch

    jmp .next_sector


.done:
    pop dx
    pop cx
    pop bx
    pop ax
    ret


load_error:
    ; BIOS sets carry flag (CF) on error
    ; AX contains BIOS error information

    mov ebx, kernel_load_fail_msg
    call asm_print_protected

    jmp error_hang


kernel_sectors_remaining dw 0


error_hang:
        mov ebx, kernel_load_fail_msg
        call asm_print_protected
        jmp $       ; loop forever 
                    ; Instruction Pointer is self (JMP IP)

Preparando el Modo Protegido

El Real Mode en el que estamos es una porquería de los 70's/80's y en pleno 2019 no deberíamos estar escribiendo este tipo de código, asi que vamos a configurar el CPU para pasar de modo 16 bits a modo 32 bits.

Para esto, tenemos que hacer varias cosas:

Armar un descriptor en la Global Descriptor Table o GDT
Habilitar la línea del bus A20
Armar un Interrupt Descriptor Table IDT (Update: era un bardo mantenerlo en assembly, asi que lo pasé al Kernel en C y esto está en otro artículo)
Habilitar el Modo Protegido después de configurar todo esto a través del registro de control cr0
Saltar a código 32 Bits

; Ok, we now try to switch to protected mode
prepare_protected_mode:
    cli                     ; disable interrupts

    lgdt [gdt_descriptor]   ; load the gdt_descriptor table in gdt.asm
                            ; with the lgdt (load GDT) instruction

    ; Fast A20 Gate 286+ ? 
    ; using this Fast A20 gate resets the computer on 286
    ;in al, 0x92
    ;or al, 2
    ;out 0x92, al
    call enable_A20         ; so we try to use this neat function instead

    ; lidt instruction execution moved to C kernel! 
    ;lidt [idt_descriptor]

    ;xchg bx, bx             ; magic bochs breakpoint

    ; protected mode 286+ ?
    ; we are NOT supporting 286!!!!!111 t_t
    ; tOSh it's 386+ -ONLY-
    ;    lmsw ax        ; pre-cr0 register is the 'msw' register in 286
    ;    or ax, 0x1     ; and this way you enable
    ;    smsw ax        ; protected mode, but cannot make it work,
                        ; don't know what I missed

    mov eax, cr0
    or  eax, 0x1            ; set the 32-bit mode (Protected Mode)...
    mov cr0, eax            ; into cr0

    ; the CODE_SEGMENT is defined in gdt.asm
    jmp CODE_SEGMENT:init_protected_mode        ; far jump! 

Lo que voy a explicar aca es una exagerada superultrasobresimplificación sobre lo que habría que leer al menos dos volúmenes de los seis que componen los manuales de Intel donde se explican con lujo de detalles todo lo necesario para entender como configurar el CPU.

GDT

La GDT es una estructura de datos usada por los procesadores Intel (32/64 bits) para definir segmentos de memoria y permisos para poder escribir, leer y ejecutar en todas sus combinaciones posibles cada uno de esos segmentos. Es un array de 8 bytes que tiene la siguiente pinta en [tOSh]:

; https://wiki.osdev.org/GDT_Tutorial
; https://wiki.osdev.org/Global_Descriptor_Table
bits 32
db 'GDT'    ; GDT mark for bin
gdt_start:
    ; the first entry of the GDT must start with
    ; 8 null bytes

    dd 0x0
    dd 0x0

gdt_code_segment:
    ; this is the entry for the kernel address space
    dw 0xFFFF   ; limit 0:15 - 16 bits - 2 bytes
                ; (all will be pages of 4KiB, so take this into account)
    dw 0x0000   ; base  0:15 - 16 bits - 2 bytes
    db 0x00     ; base  16:23 - 8 bits - 1 byte
                ; Base address will be 0
    db 10011010b ; access byte - 8 bits - 1 byte
                 ; present bit: 1
                 ; privilege, 2 bits, 0 = kernel space, 3 = userspace
                 ; S: Descriptor type: enable for code/data segments, 0 for system segments
                 ; executable bit: 1 
                 ; Direction bit/Conforming bit: 0, code only exec by priv lvl
                 ; RW (code segments read access, data segments always read, set for writing) : 1
                 ; Ac: accessed bit, set to 0 as recommended by osdev
    db 11001111b ; first flags then limit 16:19 / (1 byte) 1 nibble - 1 nibble
                 ; FLAGS (1st most significant nibble): 
                 ; Granularity: 0 = 1 byte blocks, 1= 4KiB blocks (pages)
                 ; Size bit: 0 = 16 bit protected mode, 1 = 32 bit protected mode
                 ; next to bytes in the nibble must be zero
                 ; 2nd nibble: limit 16:19
                 ; 
    db 00000000b ; base 24:31 - 8 bits - 1 byte

gdt_data_segment:
    ; this is the entry for the kernel address space
    dw 0xffff   ; limit 0:15 - 16 bits - 2 bytes
    dw 0x0000   ; base  0:15 - 16 bits - 2 bytes
    db 0x00     ; base  16:23 - 8 bits - 1 byte
    db 10010010b ; access byte - 8 bits - 1 byte
    db 11001111b ; first flags then limit 16:19 / (1 byte) 1 nibble - 1 nibble
    db 00000000b ; base 24:31 - 8 bits - 1 byte

; gdt_tss_segment:
;     ; this is the entry for the kernel address space
;     dw 0x0000   ; limit 0:15 - 16 bits - 2 bytes
;     dw 0x0000   ; base  0:15 - 16 bits - 2 bytes
;     db 0x00     ; base  16:23 - 8 bits - 1 byte
;     db 00000000b ; access byte - 8 bits - 1 byte
;     db 00000000b ; first flags then limit 16:19 / (1 byte) 1 nibble - 1 nibble
;     db 00000000b ; base 24:31 - 8 bits - 1 byte

; gdt_ldt_segment:
;     ; this is the entry for the kernel address space
;     dw 0x0000   ; limit 0:15 - 16 bits - 2 bytes
;     dw 0x0000   ; base  0:15 - 16 bits - 2 bytes
;     db 0x00     ; base  16:23 - 8 bits - 1 byte
;     db 00000000b ; access byte - 8 bits - 1 byte
;     db 00000000b ; first flags then limit 16:19 / (1 byte) 1 nibble - 1 nibble
;     db 00000000b ; base 24:31 - 8 bits - 1 byte

; gdt_user_segment:
;     ; this is the entry for the kernel address space
;     dw 0x0000   ; limit 0:15 - 16 bits - 2 bytes
;     dw 0x0000   ; base  0:15 - 16 bits - 2 bytes
;     db 0x00     ; base  16:23 - 8 bits - 1 byte
;     db 00000000b ; access byte - 8 bits - 1 byte
;     db 00000000b ; first flags then limit 16:19 / (1 byte) 1 nibble - 1 nibble
;     db 00000000b ; base 24:31 - 8 bits - 1 byte

gdt_descriptor:
    dw gdt_end - gdt_start - 1
    dd gdt_start

gdt_end:

; constants to be used by stage1.asm

CODE_SEGMENT equ gdt_code_segment - gdt_start
DATA_SEGMENT equ gdt_data_segment - gdt_start
;TSS_SEGMENT  equ gdt_tss_segment  - gdt_start
;LDT_SEGMENT  equ gdt_ldt_segment  - gdt_start
;USER_SEGMENT equ gdt_user_segment - gdt_start

A20

La línea A20 es una representación física del bit número 21 de cualquier dirección de memoria. Por una cuestión de compatibilidad con procesadores anteriores, los diseñadores de los CPUs de Intel "la ataron con alambre". Hasta el dia de hoy, en procesadores modernos basados en Intel, hay que seguir configurando esta chanchada que se hizo hace como 50 años.

Hacele click a A20 y buscá en internet la historia completa de toda esa subtrama de diseño de procesadores y de Intel que no tiene desperdicio. Nosotros podríamos skippear poskippeamos todo el lore subiendo la vara de nuestro Sistema Operativo para computadoras PC Compatibles IBM PS/2+ usando el metodo mencionado en osdev: Fast A20 Gate:

in al, 0x92
or al, 2
out 0x92, al

Pero mejor incluimos y llamamos un a20.asm que copié y pegué de algún lugar de la mancha el cual no puedo acordarme.

cr0

    mov eax, cr0
    or  eax, 0x1            ; set the 32-bit mode (Protected Mode)...
    mov cr0, eax            ; into cr0

    ; the CODE_SEGMENT is defined in gdt.asm
    jmp CODE_SEGMENT:init_protected_mode        ; far jump! 

Setiamos con un OR el registro de control cr0 el bit 1 para habilitar el Modo Protegido y saltamos directamente al código 32 bits.

Hay banda de cosas más que se pueden configurar en el CPU pero dejamos las otras funcionalidades y configuraciones disponibles como ejercicio para el lector ;-).

Un Mundo de 32 Bits

Llegamos (¡finalmente!) al mundo de los 32 bits y el realm de las direcciones de memoria lineal. Copiamos un "kernel misterioso hecho en C" a memoria pero antes de poder usarlo, tenemos que obviamente seguir configurando el CPU, sus segmentos en el modo 32 bits y además el stack.

pHUN pHAKT: Al stack en criollo le decimos "La Pila".

; ---------------------------------------------------------------------
; 32 bit code! now we are able to use 32 bit instructions at this point
; ---------------------------------------------------------------------
bits 32         
init_protected_mode:
    ; and we need to setup the segments again
    ; with our previously configured GDT configuration addresses
    ; find gdt.asm and other %includes further in this listing
    mov ax, DATA_SEGMENT        ; defined in gdt.asm
    mov ds, ax                  ; data segment
    mov es, ax                  ; extended segment
    mov fs, ax                  ; fuck you segment
    mov ss, ax                  ; stack segment
    ;mov ax, USER_SEGMENT       ; in the future, maybe...
    mov gs, ax                  ; gorgeous segment <3
    ;mov ax, CODE_SEGMENT
    ;mov cs, ax                 ; TODO: why i didn't setup the code segment? 
                                ;       while reviewing the code for the article
                                ;       I found this commented like years ago
                                ;       and I got startled. Maybe for another
                                ;       time...

    ;ret ; !!!!!
    ; set up the stack
    ;mov ebp, 0xf90000        ; 16MB RAM machine! this breaks old 86box / PCem Machines!
    mov ebp, STACK_ADDRESS    ; equ 0x80000 --> stack ~ 576KiB
    mov esp, ebp

Una de las grandes sesiones de debug que tuve que spawnearon pedazos de ISABugger-Related-Code fue entender porque volaba por los aires nuestro kernel y era exactamente setear el stack correctamente. Como se puede apreciar en el asm, estaba usando la dirección 0xf90000 como extended base pointer y extended stack pointer para definir donde iba a vivir nuestro stack y en las VMs que estaba probando, no tenia TANTA memoria, haciendo que me vaya fuera de los boundaries y el CPU me tire una excepción irrecuperable. Solo una instrucción y bastante tiempo de debugging con bochs me hicieron dar cuenta del error. Entonces, el stack ahora vive aproximadamente alrededor de los 576KiB.

    ; [ a lot of debugging stuff ]

    ; PIC Remapping ! (now handled by kernel at pic.c)

    ; mov al, 0x11
    ; out 0x20, al        ; restart pic1
    ; out 0xa0, al        ; restart pic2

    ; mov al, 0x20
    ; out 0x21, al        ; pic1 now starts at 32
    ; mov al, 0x28
    ; out 0xa1, al        ; pic2 now starts at 40

    ; mov al, 0x04
    ; out 0x21, al        ; setup cascading
    ; mov al, 0x02
    ; out 0xa1, al

    ; mov al, 0x01
    ; out 0x21, al
    ; out 0xa1, al        ; listo!


    ; ; IRQ1 = keyboard
    ; mov al, 0xFD
    ; out 0x21, al

    ; ; mask slave PIC
    ; mov al, 0xFF
    ; out 0xA1, al
    
    ; the kernel is the responsible for enabling
    ; the interrupts!
    ; the kernel now initializes IDT --> THEN STI()
    ;sti ; enable interrupts!

    jmp  KERNEL_OFFSET ; execute kernel code
  

Y el último jmp. Todo lo demás fue comentado porque lo pasé al kernel hecho en C el cual vamos a saltar, el próximo artículo. Recapitulando, prácticamente lo que hicimos fue copiar el kernel que todavía no tenemos, saltar a Modo Protegido, una vez ahí, preparar el stack en 32 bits y finalmente saltar al Kernel C Entrypoint.

Referencias

tOSh para x86 - i386+ | Parte I | Bootloader

2019-12-02T14:08:01+00:00

Para descargar el Sistema Operativo tOSh, podés hacerlo desde la sección Resources de este mismo sitio.

Partes

Esta serie de artículos va a tener las siguientes partes:

ISA POST Tester Card

Prefacio

¿Otro Sistema Operativo más? Si. ¿Por qué? Porque puedo. ¡Increíblemente tengo tiempo libre! Y como esto forma parte de un proyecto más grande, en unos meses cuando vuelva a tener el tiempo suficiente como para poder revisarlo, voy a necesitar tener un resumen y documentación y escribir este artículo de alguna manera me va a ayudar a tener todo en un solo lugar para consultarlo luego. ¿Cuál es ese proyecto? ¿Vas a competirle al Kernel de Linux? ¿Vas a tratar de reemplazar Windows por el tuyo? No. Para nada. De hecho, creo que es bastante difícil hacer algo así en estos días individualmente y todo lo que uno pueda llegar a hacer en solitario no podría llegar más lejos que lo que Terry A. Davis haya logrado con Temple OS que es de por si, cuando menos impresionante.

Sinceramente, el objetivo de este Sistema Operativo es demostrar mis habilidades como programador, el entendimiento sobre sistemas operativos, arquitecturas, lenguajes (ASM, C), la creación de herramientas "en el andar" y una ristra de cosas más para un poco cancherearle a mis amigos y otro poco para chapearle a recruiters y futuros empleadores, en caso que tengan dudas de mis habilidades.

En caso de que seas un Recruiter: ¡Hola, mucho gusto!, mandale por favor esta serie de artículos al lider técnico pertinente, le va a encantar.

En caso que seas el "Lider Técnico Pertinente": ¡Hola, ¿que tal? Encantado: ¡Mandame un mail por favor y charlemos!

Si no entrás en alguna de estas dos categorías, quizá a vos también te sirvan esta serie de artículos por vaya a saber que motivo. ¿Universidad? ¿Curiosidad? ¿Masoquismo? Da igual, bienvenido y disfrutalos tanto como yo disfruté y sufrí escribir sobre como hacer un Sistema Operativo para la Arquitectura Intel.

Descarga de tOSh (img / código fuente)

Para descargar el Sistema Operativo tOSh, podés hacerlo desde la sección Resources de este mismo sitio. En la tabla de recursos hay varias secciones, y en Software está la imagen ya compilada del sistema operativo y en la sección Sourcecode la última versión de su código fuente. ¡¡¡Bajátelo YA NO TE LO PIERDAS!!! (?)

¿Por qué se llama tOSh?

Tosh, tsh o Toshi son algunos de mis handles. Quise hacer algo parecido al acrónimo recursivo GNU is Not Unix y me quedó:

"tOSh Operating System, Huh?"

En algún momento me pareció gracioso. Hoy no tanto y me dio paja cambiar el nombre del repo ;D Bueno, basta de introducciones y arranquemos enseguida por lo primero de lo primerísimo que hay que tener en cuenta para hacer un Sistema Operativo para Intel, entender su Secuencia de Booteo.

Secuencia de Booteo en Intel

La Secuencia de booteo ó Boot_Sequence consiste en un conjunto de pasos que necesitan ser ejecutados en cierto orden para poder cargar al final, un kernel en memoria y eventualmente saltar a su código para otorgarle control a la administación los dispositivos de la computadora, interfaz de usuario, ejecución de programas, etc… Vamos a listar muy brevemente estos pasos prestando suma atención a cosas que necesitamos saber sobre como se configura el equipo desde que apretás power-on en tu PC hasta que puedas insertar algunas instrucciones cuando llegás a la instancia de poder ejecutar tu propio código.

P.O.S.T.

Cuando una computadora se enciende, la mayor parte de los registros del CPU tienen valores muy bien definidos, incluyendo el puntero de instrucción (IP) o como en otras arquitecturas o libros de texto lo llaman Program Counter. El valor de IP apenas se enciende la computadora contiene la dirección de memoria que ejecuta la CPU. Esta dirección de memoria se llama reset vector y está hardcodeado en el CPU: la dirección de memoria es particularmente 0xFFFFFFF0. El motherboard de la computadora se asegura que la instrucción que se ejecute en el reset vector sea una instrucción jump a la dirección de memoria mapeada al entry point de la BIOS. Toda esta ensalada de direcciones de memoria del BIOS están organizadas por el chipset del motherboard porque en este momento, la RAM contiene basura random. Finalmente, la CPU ejecuta el código del firmware. En un sistema con BIOS legacy, el BIOS inicializa parte del hardware de la computadora y realiza el POST - Power-On-Self-Test, que consiste en una serie de diagnósticos de algunos componentes esenciales como la placa de video. Por ejemplo, si la placa de video falla en esta instancia, el código del POST generalmente causa que el BIOS emita un par de pitidos en el speaker de la computadora para que vos puedas agarrar el manual, y dependiendo del número de pitidos, saber por qué está fallando la inicialización, y esta información generalmente está en el manual del motherboard para consultar que significan 3 pitidos largos y uno corto, 2 pitidos cortos y uno largo, etc…

Después del P.O.S.T.: Saltar al vacío

Una vez que se terminó de chequear los componentes esenciales, el BIOS va a querer bootear un sistema operativo. Y este sistema operativo debería poder encontrarse en algún lado. Entonces empieza a buscar en discos rígidos, USB sticks, disquettes o CD-ROMs. Si el BIOS no encuentra ningún dispositivo disponible, se detiene la ejecución del CPU y no sin antes mostrar algun texto acorde a lo que sucedió:

Non-System Disk or Disk Error.

Sin embargo, si encuentra algún dispositivo, el BIOS va a tratar de leer el primer sector de 512 bytes en el dispositivo de almacenamiento que haya encontrado primero (o esté configurado en el BIOS, claro). Este primer sector, es llamado coloquialmente MBR (Master Boot Record). El BIOS carga cualquier cosa que haya en este primer sector a la dirección de memoria 0x0000:0x7c00 (segmento 0, dirección 0x7c00) y salta a esa dirección sea cual fuere el código que haya para ejecutar. Un salto de fe. (!)

Sólo 512 bytes disponibles

Bueno, no tenés exactamente 512 bytes disponibles para escribir el código del bootloader si no un poco menos. La BIOS busca en los "dispositivos booteables" una marca o magic number (si) que tiene que ser exactamente la secuencia de bytes 0x55 y 0xAA en los offsets 510 y 511 respectivamente. Ni hablar que estos 510 bytes disponibles son desde un disquette. Si necesitás bootear desde un disco rígido, entonces tu espacio se reduce a 446 bytes. Para colmo, en todo este reducido espacio necesitás hacer las siguientes cosas para tener un bootloader decente:

Determinar desde cual partición bootear
Saber donde está la imagen de tu kernel en la partición de booteo
Cargar la imagen del kernel en memoria (El BIOS tiene funciones para leer sectores y copiar a memoria)
Pasar de Modo Real a Modo Protegido (Estamos en Modo Real con un máximo de 1 MB disponible, aunque nuestra computadora tenga over 9000 GB)

El Modo Protegido es entre otras cosas, saltar de instrucciones y modo de direcciónamiento de 16 bits a 32 bits, lo que nos permite dejar de tener una limitación de acceso a 1 Megabyte de memoria, ampliando el espacio de direcciónamiento hasta 4 Gigabytes

Setear el stack (sí, necesitamos configurar nosotros mismos el stack)
Mensajes de error! (el bootloader no encuentra la imagen? no se pudo copiar el kernel a memoria? que esta pasando?)

Hay formas de resolver estos problemas, ya que de otra manera, no existirían los sistemas operativos actuales. Estos problemas a lo largo de los últimos 40 años en la historia de las PC se resolvieron y discutieron una y otra vez, como estamos haciendo acá también. Y se van a seguir discutiendo y escribiendo artículos sobre este tema.

Escribiendo un Bootloader

La información anterior es la mínima indispensable para poder entender porque algunos valores que parecen totalmente arbitrarios no lo son. A continuación vamos a escribir un bootloader de 512 bytes que nos permita al menos copiar sectores de un dispositivo a memoria y saltar a esa dirección para continuar. Esto se lo llama One-Stage loading: Nuestro bootloader carga una imagen del kernel (que debe de ser menor a 1 Megabyte), saltamos a un stub con el que tenemos que cambiar de Modo Real a Modo Protegido para eventualmente saltar apropiadamente a nuestro kernel.

¡Espera! Antes de empezar…

Vamos a instalar y a hacer los siguientes pasos:

Usar cualquier distribución de Linux
Instalar nasm (compilador de assembly)
Instalar qemu (emulador de varias arquitecturas, nosotros vamos a emular la arquitectura 386+ de Intel)
Instalar PCem (emulador de componentes de PC, emula diferentes tipos de BIOSes, motherboards, CPUs, placas de video, etc…)
Instalar bochs un emulador que te va a hacer compania durante todo el desarrollo del sistema operativo, ya que te permite leer registros especiales como GDT, IDT, CRn. Es un emulador que te permite debuggear, muy parecido de gdb.

… deberás aprobar un examen de historia.

Antes de seguir, una aclaración importante: todo lo que estamos haciendo acá describe el flujo clásico de BIOS legacy. Las máquinas modernas también pueden bootear usando UEFI, cuyo mecanismo de carga es distinto. En esta serie vamos a quedarnos deliberadamente con BIOS porque estamos construyendo un bootloader x86 clásico.

Vamos a crear 3 archivos:

bootsector.asm
build_and_run.sh
stage1.asm

Los tres vacios, salvo build_and_run.sh que más o menos, por conveniencia, debería tener el siguiente contenido:

#!/bin/sh
nasm -f bin bootsector.asm -o boot.bin
nasm -f bin stage1.asm -o stage1.bin

cat boot.bin stage1.bin > tOSh.bin
qemu-system-x86_64 -fda tOSh.bin

Primero que nada, configuramos nasm para que ensamble nuestro código assembly exactamente como queremos.

; ------------------------------------------------
; tOSh Operating System, Huh?             (c) 2019
; bootsector.asm                          by toshi
; $ nasm -f bin bootsector.asm -o boot.bin
; ------------------------------------------------
; 
; docs
; https://wiki.osdev.org/Boot_Sequence
; https://wiki.osdev.org/Rolling_Your_Own_Bootloader
; https://stackoverflow.com/questions/34178717/load-segment-from-floppy-with-int13h

bits 16         ; setup nasm to 16 bit code
cpu 186         ; assemble with 80186 instruction set (ie.: push word label)
org 0x7c00      ; all offsets will be at 0x7c00

; after here we will be able to execute code
; in x86 real mode, so these are the first instructions
section .text

global _start   ; make this symbol global so we can reference
                ; it later in a custom linker script

_start:

jmp boot

La primer instrucción de todas es jmp boot que va a un label más adelante. Para que nasm sepa exactamente hacia donde tiene que saltar (jmp boot) tenemos que forzar al ensamblador a que no tome decisiones por su cuenta y trate de usar lo último de lo último que tenga disponible. Por esto, seteamos a nasm que escriba código 16 bits, que use hasta el máximo set de instrucciones 80186 con la directiva cpu y finalmente con org 0x7c00 le decimos que todos los "ceros" de los offsets de los jumps, labels y demás empiezan en 0x7c00: es decir que nuestro "nuevo cero" relativo es lo que configuremos con org.

Esto es sumamente importante y es un concepto que mejor que lo entiendas ahora que después cuando sea demasiado tarde y que cuando tengas a veces que leer código ensamblado, las instrucciones carezcan de total sentido. Cuando saltás (jmp, jx, jxx) los saltos pueden ser far o near. Para un salto far en x86 16 bits, se tienen en cuenta el segmento y el offset de los **modos de direcciónamiento de memoria de intel 16 bits o Real Mode.

Uno de nuestros objetivos más importantes después de lograr bootear el CPU y copiar el Kernel en memoria va a ser salir del Real Mode y saltar al Modo Protegido. Es infinitamente más fácil trabajar con modos de direcciónamiento de memoria del modo protegido que los del modo real, porque el juego del cálculo de la memoria física entre segmento y offset es confuso y molesto. En cambio, en modo protegido, directamente vas a una posición de memoria de 32bits y listo.

Pulsa ENTER para continuar…

Continuamos con algunas funciones útiles para hacer que nuestra secuencia de booteo sea la más hermosa del barrio:

; http://www.ctyme.com/intr/rb-0097.htm 
; ralf brown scroll down window int10h
clrscr:

    push bp
    mov bp, sp
        mov ah, 0x07    ; set "scroll down window" for int 10h
        mov al, 0       ; clear entire window with null char

        ; https://en.wikipedia.org/wiki/BIOS_color_attributes
        mov bh, 0x4f    ; colors (nibbles background/foreground)
                        ; we choose red background, white characters
        mov cx, 0       ; top left screen (0,0) (cx register)
        mov dh, 24      ; 25 rows (from 0 to n-1) (dx register)
        mov dl, 79      ; 80 cols (from 0 to n-1)
        int 0x10
    mov sp, bp
    pop bp
    ret

sleep:
    push ax
    push cx
    push dx

        mov ah, 0x86    ; int 15h, function 86h, CX:DX interval in microseconds
        mov cx, 0x20    ; just a few seconds 
        mov dx, 0x0000
        int 0x15

    pop dx
    pop cx
    pop ax
    ret

; print(char *msg_string)
print:
    push bp
    mov bp, sp

        ; move the cursor
        ; Set cursor position    AH=02h    BH = Page Number, DH = Row, DL = Column 
        mov dh, 12  ; row
        mov dl, 16  ; col
        mov bh, 0   ; page 0
        mov ah, 0x2 ; move cursor service
        int 0x10

        ; as we have stack, we grab the parameter
        ; of print    
        mov si, [bp+4]  ; move the ptr of the first
                        ; argument
        mov ah, 0x0e    ;  write char teletype style
                        ; http://www.ctyme.com/intr/rb-0106.htm
        mov bh, 0       ; page number 0
        mov bl, 0       ; foreground (only graphics mode) 
        .loop:
            lodsb       ; load a byte from ds:si into al
                        ; glad we setup ds register before,
                    
            cmp al, 0   ; is the null caracter?
            je .print_end
            int 0x10    ;  BIOS Video services
            jmp .loop


    .print_end:
    mov sp, bp
    pop bp
    ret

load_disk:
    push dx
        mov ah, 0x02                ; int 13h, read
        mov al, dh                  ; number of sectors to read
        mov cl, 0x02                ; cl, sector, 0x01 is the boot sector
                                    ; 0x02 is where we will put our
                                    ; 'stage1' data
        mov ch, 0x00                ; ch, cylinder
                                    ; boot_drive_numbers -->
                                    ; drive number, 0 = floppy1, 1 = floppy2
                                    ; 0x80 = hdd1, 0x81 = hdd2
        mov dl, [boot_drive_number] ; the BIOS should have told us what's the 
                                    ; drive number that we grabbed in the very first
                                    ; instructions
        mov dh, 0x00                ; dh, head number (0 to F)

        int 0x13                    ; BIOS interruption
        jc load_error               ; if carry bit set, then error
    pop dx
    cmp al, dh                      ; al is now num of sectors read
    jne sectors_error
    ret

load_error:
    push word load_error_msg
        call print
    add sp, 2
    jmp error_hang

sectors_error:
    push word sectors_error_msg
        call print
    add sp, 2
    jmp error_hang

error_hang:
    jmp $

En todas las funciones que siguen a continuación, como no tengo nada de nada, salvo la parte baja de la memoria, estar en Modo Real y la posibilidad de hacer llamadas de interrupción al BIOS, la única interfaz para poder hacer algo es la BIOS. Para poder obtener una lista exhaustiva de las interrupciones al BIOS y cada una de las funciones que podés usar para interactuar con otros dispositivos sea la disquetera, el teclado o la pantalla es la vieja y quierida Ralf Brown’s Interrupt List, de valor incalculable.

clrscr: hace exactamente lo que promete su acrónimo: limpiar la pantalla.

sleep: detener la ejecución por unos segundos.

print: esta función imprime un texto que esté apuntado por el puntero como parámetro en el stack

load_disk: cargar exactamente el (head) cabezal 0x00, (cylinder) cilindro 0x00, sector 0x02 que es donde va a estar el código del stage1 que vendrá mucho más tarde.

load_error, sectors_error y error_hang: funciones que imprimen el tipo de error en pantalla y terminan colgando la CPU a propósito con un loop infinito con jmp $

Ahora lo que sigue es el código de booteo que viene debajo con boot::

boot:
    nop        ; stylish nop is stylish

    ; save DL register setup by BIOS for getting the drive number
    mov [boot_drive_number], dl

Esencialmente, lo primero que hicimos, si seguís atentamente el código, es saltar al label boot:,
y después de el simpático y elegante nop que puse ahi solamente por ponerlo porque pintó, lo primerísimo que hago es guardar el valor del registro dl en otro label boot_drive_number. Cuando booteamos, el BIOS llena algunos registros con datos, y en dl, el BIOS nos guardó el número del drive en el cual vamos a bootear.

    mov ax, 0x0000      ; if ds is 0x7c0 the ORG directive must be disabled
                        ; but OFC ds is 0, then ORG directive must be enabled!
                        ; TODO: Why? --
                        ;    BECAUSE: every memory position, or
                        ;             memory reference implicitely has
                        ;          ds inside -> [ptr] is [ds:ptr]
                        ; that's why
                        ;    ALSO: segmentation essentialy is
                        ;           << 4, so 0x7c0 << 4 is 0x7c00

    mov ds, ax          ; set the data segment register
                        ; we set ds as 0x0 because we use ORG 0x7c00
                        ; for our offsets assembled in the binary
    mov es, ax          ; and 'extended?' register too

    ; setup the stack
    mov ax, 0x7c00 + 512        ; 512 is the total size of the boot sector
    mov ss, ax                  ; so we set the stack segment
                                ; of this code, TODO: explain segment addresses
                                ; arithmetics

    mov sp, 0x1000              ; let's reserve 4k of stack

Acá seteamos un stack rudimentario para poder hacer uso de nuestras propias funciones en el bootloader. ¿Lo necesitamos? y la verdad que no, pero si voy a estar booteando también me gustaría andar mostrando mensajes en la pantalla –para debuggear o por simple facha nomás– y la forma más fácil de hacerlo es creando "funciones" que necesitan un stack para poder pasar parámetros.

Entonces seteamos a 0x0000 nuestros registros de segmento ds (data segment) y es (extended segment) y configuramos el registro de segmento ss (stack segment) con una dirección de memoria que está al final de nuestro código.

Finalmente con la instrucción mov sp, 0x1000 lo que estamos haciendo es reservar 4 kilobytes del stack asignando 0x1000 al registro stack pointer sp.

    call clrscr

    push word loading_msg
        call print
    add sp, 2

    call sleep

Habiendo configurado el stack, ahora podemos usar la instrucción call y usar nuestra bien extraña calling convention. Para pasar un parámetro a nuestra función, pusheamos el puntero del parámetro, hacemos un call inmediatamente después y al volver, sumamos un word (si el push fue un word) al registro stack pointer sp.

    ; start "stage1"

    ; TODO: make this a function,
    ; https://github.com/cfenollosa/os-tutorial/blob/master/07-bootsector-disk/boot_sect_main.asm

    mov bx, 0x9000  ; es:bx = 0:0x9000 ; where in memory are we
                    ; going to put the stage1 code
    mov dh, 4       ; read 4 sectors
               
    call load_disk

Acá simplemente configuramos los parámetros de nuestra función load_disk diciéndole que los 4 sectores que vaya a leer, los copie a 0:0x9000.

    ; uncomment the following lines from
    ; ------------ here ----------------
    ;push word 0x9000
    ;   call print
    ;add sp, 2
    ;cli
    ;hlt
    ; ------------till here------------
    ; for seeing that the sector data
    ; is displayed

    jmp 0x9000 ; execute stage1

    hlt

Y una vez copiados, saltamos al vacío a una dirección de memoria donde no pusimos todavía nada.

loading_msg: db "Loading tOSh ver -3.1416a | tw/github: @0x705h ...", 0x07, 0
load_error_msg: db "Load error", 0
sectors_error_msg: db "Sectors error", 0

boot_drive_number: db 0

times 510 - ($-$$) db 'T'   ; pad 510 bytes with 't', last two bytes
                            ; in the 512 sector will be the bootloader mark

dw 0xaa55                   ; bootloader mark. These bytes make this sector bootable

; here ends the first 512 bytes sector

Al final de nuestro bootsector.asm, rellenamos con T para poder ver como se va comportando nuestro binario y si nos queda margen. El caracter T lo uso como padding a 512 bytes y ver cuanto espacio me queda. Menos Ts, menos bytes para programar el bootloader.

Finalmente, la dw word 0xaa55 es una marca o número mágico que la BIOS espera encontrarse en ese offset exacto (511b y 512b respectivamente) para darle el hint que ese sector es, efectivamente, booteable.

Mapa de Memoria & Layout Sectores

En cada parte de esta serie de artículos, hay una parada obligada que va a ser mantener actualizado nuestro mapa de memoria. Necesitamos siempre tener en cuenta donde vamos a poner que en memoria y ser prolijo con esto nos va a evitar muchisimos dolores de cabeza.

Floppy

Sector (CHS)	área Lógica	Contenido/Código	Propósito
C:0 H:0 S:1	boot sector	bootloader.asm	Lee contenido del floppy, lo copia a memoria y salta a `stage1.asm`

Memoria (Modo Real)

Dirección Física	Notación Seg:Offset	Tamaño	Propósito
0x00000 - 0x003FF	0000:0000	1 KB	IVT (Interrupt Vector Table de la BIOS)
0x00400 - 0x004FF	0000:0400	256 B	BDA (BIOS Data Area)
0x00500 - 0x07BFF	0000:0500	~29.7 KB	Zona libre / Nuestro Stack (apuntado por SP=0x7C00 decreciendo)
0x07C00 - 0x07DF_	0000:7C00	512 B	Boot Sector (bootsector.asm cargado por la BIOS)
0x07E00 - 0x8FFFF	0000:7E00	~544 KB	Memoria Convencional Libre
0x09000 - 0x097FF	0000:9000	2 KB	Stage 1 (Donde la INT 13h copia los 4 sectores del disco)
0xA0000 - 0xFFFFF	A000:0000	384 KB	"Memoria de Video, VRAM y ROM de la BIOS"