By default, it compiles using gcc.
If you are building on macOS or another non-Linux environment, you will need to change the TOOLPREFIX setting to cross-compile.
Reference: Building and running xv6 on OS X Yosemite - Qiita
\nNext, here is the CFLAGS section:
CFLAGS = -fno-pic -static -fno-builtin -fno-strict-aliasing -O2 -Wall -MD -ggdb -m32 -Werror -fno-omit-frame-pointer\nCFLAGS += $(shell $(CC) -fno-stack-protector -E -x c /dev/null >/dev/null 2>&1 && echo -fno-stack-protector)I will skip a detailed explanation of every option and focus on the defaults.
\nReference: Man page of GCC
\n| Option | \nPurpose | \n
|---|---|
| -fno-pic | \nDo not generate position-independent code (PIC) | \n
| -static | \nCompile the program with static linking | \n
| -fno-builtin | \nDo not use compiler built-in functions | \n
| -fno-strict-aliasing | \nDisable strict aliasing | \n
| -O2 | \nEnable all supported optimization options | \n
| -Wall | \nEnable all compiler warning messages | \n
| -MD | \nList both system and user header files | \n
| -ggdb | \nGenerate debug information targeting gdb | \n
| -m32 | \nCompile as 32-bit object | \n
| -Werror | \nTreat unused function arguments as compile errors | \n
| -fno-omit-frame-pointer | \nRetain the frame pointer even in functions that do not need it | \n
Note: Position-Independent Code (PIC)
\nPosition-independent code (PIC), or position-independent executable (PIE), refers to machine code that can be executed correctly regardless of where it is placed in memory.
\nPIC is primarily used for shared libraries.
\nReference: Position Independent Code (PIC) in shared libraries - Eli Bendersky’s website
\nReference: Why compile with PIC when making a shared library on Linux - bkブログ
\nOverview of bootmain.c
\nWhen building xv6, the first step generates bootmain.o from the following bootmain.c:
// Boot loader.\n//\n// Part of the boot block, along with bootasm.S, which calls bootmain().\n// bootasm.S has put the processor into protected 32-bit mode.\n// bootmain() loads an ELF kernel image from the disk starting at\n// sector 1 and then jumps to the kernel entry routine.\n\n#include \"types.h\"\n#include \"elf.h\"\n#include \"x86.h\"\n#include \"memlayout.h\"\n\n#define SECTSIZE 512\n\nvoid readseg(uchar*, uint, uint);\n\nvoid\nbootmain(void)\n{\n struct elfhdr *elf;\n struct proghdr *ph, *eph;\n void (*entry)(void);\n uchar* pa;\n\n elf = (struct elfhdr*)0x10000; // scratch space\n\n // Read 1st page off disk\n readseg((uchar*)elf, 4096, 0);\n\n // Is this an ELF executable?\n if(elf->magic != ELF_MAGIC)\n return; // let bootasm.S handle error\n\n // Load each program segment (ignores ph flags).\n ph = (struct proghdr*)((uchar*)elf + elf->phoff);\n eph = ph + elf->phnum;\n for(; ph < eph; ph++){\n pa = (uchar*)ph->paddr;\n readseg(pa, ph->filesz, ph->off);\n if(ph->memsz > ph->filesz)\n stosb(pa + ph->filesz, 0, ph->memsz - ph->filesz);\n }\n\n // Call the entry point from the ELF header.\n // Does not return!\n entry = (void(*)(void))(elf->entry);\n entry();\n}\n\nvoid\nwaitdisk(void)\n{\n // Wait for disk ready.\n while((inb(0x1F7) & 0xC0) != 0x40)\n ;\n}\n\n// Read a single sector at offset into dst.\nvoid\nreadsect(void *dst, uint offset)\n{\n // Issue command.\n waitdisk();\n outb(0x1F2, 1); // count = 1\n outb(0x1F3, offset);\n outb(0x1F4, offset >> 8);\n outb(0x1F5, offset >> 16);\n outb(0x1F6, (offset >> 24) | 0xE0);\n outb(0x1F7, 0x20); // cmd 0x20 - read sectors\n\n // Read data.\n waitdisk();\n insl(0x1F0, dst, SECTSIZE/4);\n}\n\n// Read 'count' bytes at 'offset' from kernel into physical address 'pa'.\n// Might copy more than asked.\nvoid\nreadseg(uchar* pa, uint count, uint offset)\n{\n uchar* epa;\n\n epa = pa + count;\n\n // Round down to sector boundary.\n pa -= offset % SECTSIZE;\n\n // Translate from bytes to sectors; kernel starts at sector 1.\n offset = (offset / SECTSIZE) + 1;\n\n // If this is too slow, we could read lots of sectors at a time.\n // We'd write more to memory than asked, but it doesn't matter --\n // we load in increasing order.\n for(; pa < epa; pa += SECTSIZE, offset++)\n readsect(pa, offset);\n}The four functions defined are:
\n- \n
- void bootmain(void) \n
- void waitdisk(void) \n
- void readsect(void *dst, uint offset) \n
- void readsect(void *dst, uint offset) \n
The behavior of each function will be examined later.
\nOverview of bootblock.o
\nNext, bootasm.o is generated from bootasm.S, and linked together with the previously generated bootmain.o to produce bootblock.o.
Here is bootasm.S:
#include "asm.h"\n#include "memlayout.h"\n#include "mmu.h"\n\n# Start the first CPU: switch to 32-bit protected mode, jump into C.\n# The BIOS loads this code from the first sector of the hard disk into\n# memory at physical address 0x7c00 and starts executing in real mode\n# with %cs=0 %ip=7c00.\n\n.code16 # Assemble for 16-bit mode\n.globl start\nstart:\n cli # BIOS enabled interrupts; disable\n\n # Zero data segment registers DS, ES, and SS.\n xorw %ax,%ax # Set %ax to zero\n movw %ax,%ds # -> Data Segment\n movw %ax,%es # -> Extra Segment\n movw %ax,%ss # -> Stack Segment\n\n # Physical address line A20 is tied to zero so that the first PCs \n # with 2 MB would run software that assumed 1 MB. Undo that.\nseta20.1:\n inb $0x64,%al # Wait for not busy\n testb $0x2,%al\n jnz seta20.1\n\n movb $0xd1,%al # 0xd1 -> port 0x64\n outb %al,$0x64\n\nseta20.2:\n inb $0x64,%al # Wait for not busy\n testb $0x2,%al\n jnz seta20.2\n\n movb $0xdf,%al # 0xdf -> port 0x60\n outb %al,$0x60\n\n # Switch from real to protected mode. Use a bootstrap GDT that makes\n # virtual addresses map directly to physical addresses so that the\n # effective memory map doesn't change during the transition.\n lgdt gdtdesc\n movl %cr0, %eax\n orl $CR0_PE, %eax\n movl %eax, %cr0\n\n//PAGEBREAK!\n # Complete the transition to 32-bit protected mode by using a long jmp\n # to reload %cs and %eip. The segment descriptors are set up with no\n # translation, so that the mapping is still the identity mapping.\n ljmp $(SEG_KCODE<<3), $start32\n\n.code32 # Tell assembler to generate 32-bit code now.\nstart32:\n # Set up the protected-mode data segment registers\n movw $(SEG_KDATA<<3), %ax # Our data segment selector\n movw %ax, %ds # -> DS: Data Segment\n movw %ax, %es # -> ES: Extra Segment\n movw %ax, %ss # -> SS: Stack Segment\n movw $0, %ax # Zero segments not ready for use\n movw %ax, %fs # -> FS\n movw %ax, %gs # -> GS\n\n # Set up the stack pointer and call into C.\n movl $start, %esp\n call bootmain\n\n # If bootmain returns (it shouldn't), trigger a Bochs\n # breakpoint if running under Bochs, then loop.\n movw $0x8a00, %ax # 0x8a00 -> port 0x8a00\n movw %ax, %dx\n outw %ax, %dx\n movw $0x8ae0, %ax # 0x8ae0 -> port 0x8a00\n outw %ax, %dx\nspin:\n jmp spin\n\n# Bootstrap GDT\n.p2align 2 # force 4 byte alignment\ngdt:\n SEG_NULLASM # null seg\n SEG_ASM(STA_X|STA_R, 0x0, 0xffffffff) # code seg\n SEG_ASM(STA_W, 0x0, 0xffffffff) # data seg\n\ngdtdesc:\n .word (gdtdesc - gdt - 1) # sizeof(gdt) - 1\n .long gdt # address gdtBefore diving into the content, let us look at how the boot program is linked.
\nLinking the Boot Program
\nLinking is performed with the following command:
\nld -m elf_i386 -N -e start -Ttext 0x7C00 -o bootblock.o bootasm.o bootmain.oThe ld command combines multiple binaries and compiles a new executable program.
Reference: ld command description - Linux command reference
\nIn the command above, it is linked as an elf_i386 binary.
The -N option makes both the text section and data section readable/writable, and the start symbol is treated as the entry point.
The starting address of the entry point is defined at 0x7C00.
For x86 CPUs, after the BIOS POST (Power On Self Test) runs at startup, the boot program is read from the MBR, loaded at 0x7C00, and treated as the boot sector.
The reason this specific address is used is explained in great detail in the following excellent article:
\nReference: Assembler/Why is the MBR loaded at “0x7C00” in x86? (Complete edition) - Glamenv-Septzen.net
\nTo summarize briefly: there was a need to reserve the minimum 32 KB of memory required by the ROM BIOS, and the range from 0x0 to 0x3FF is reserved for interrupt vectors. As a result, it was decided to place the boot sector at the end of the 32 KB region.
\nConsequently, reserving 512 bytes for the boot sector area and 512 bytes for the MBR bootstrap data/stack region, the starting address of the boot sector became 0x7C00 (32KB - 1024B).
This background was not covered in much detail in the DIY OS books I had read before (or so I recall), so it was very informative.
\nNow that the boot program is assembled, let us examine its contents.
\nReal Mode and Protected Mode
\nx86 CPUs start in “real mode,” which is software-compatible with the Intel 8086.
The Intel 8086 is a 16-bit processor.
Therefore, real mode operates as a 16-bit mode.
\nReference: Intel 8086 - Wikipedia
\nFrom here, we will trace the steps for transitioning to 32-bit mode.
\nThe code that runs in real mode is the following:
\n#include "asm.h"\n#include "memlayout.h"\n#include "mmu.h"\n\n# Start the first CPU: switch to 32-bit protected mode, jump into C.\n# The BIOS loads this code from the first sector of the hard disk into\n# memory at physical address 0x7c00 and starts executing in real mode\n# with %cs=0 %ip=7c00.\n\n.code16 # Assemble for 16-bit mode\n.globl start\nstart:\n cli # BIOS enabled interrupts; disable\n\n # Zero data segment registers DS, ES, and SS.\n xorw %ax,%ax # Set %ax to zero\n movw %ax,%ds # -> Data Segment\n movw %ax,%es # -> Extra Segment\n movw %ax,%ss # -> Stack Segment\n\n # Physical address line A20 is tied to zero so that the first PCs \n # with 2 MB would run software that assumed 1 MB. Undo that.\nseta20.1:\n inb $0x64,%al # Wait for not busy\n testb $0x2,%al\n jnz seta20.1\n\n movb $0xd1,%al # 0xd1 -> port 0x64\n outb %al,$0x64\n\nseta20.2:\n inb $0x64,%al # Wait for not busy\n testb $0x2,%al\n jnz seta20.2\n\n movb $0xdf,%al # 0xdf -> port 0x60\n outb %al,$0x60\n\n # Switch from real to protected mode. Use a bootstrap GDT that makes\n # virtual addresses map directly to physical addresses so that the\n # effective memory map doesn't change during the transition.\n lgdt gdtdesc\n movl %cr0, %eax\n orl $CR0_PE, %eax\n movl %eax, %cr0\n\n//PAGEBREAK!\n # Complete the transition to 32-bit protected mode by using a long jmp\n # to reload %cs and %eip. The segment descriptors are set up with no\n # translation, so that the mapping is still the identity mapping.\n ljmp $(SEG_KCODE<<3), $start32\n\n.code32 # Tell assembler to generate 32-bit code now.\nstart32:\n{{ 省略 }}Booting in Real Mode
\nThe .code16 directive at the top tells the assembler that the code is expected to execute in 16-bit mode.
The start section is the symbol that was linked as the entry point earlier.
.code16 # Assemble for 16-bit mode\n.globl start\nstart:\n cli # BIOS enabled interrupts; disable\n\n # Zero data segment registers DS, ES, and SS.\n xorw %ax,%ax # Set %ax to zero\n movw %ax,%ds # -> Data Segment\n movw %ax,%es # -> Extra Segment\n movw %ax,%ss # -> Stack SegmentReference: Objdump of .code16 and .code32 x86 assembly - Stack Overflow
\nDisabling CPU Interrupts with cli and sti
\ncli is an instruction that disables CPU interrupts.
From the point cli is called until the sti instruction is called, CPU interrupts are disabled. (More precisely, interrupt requests from the CPU are still generated but are ignored.)
Reference: CLI : Clear Interrupt Flag (x86 Instruction Set Reference)
\nThis is because if the interrupts set by the BIOS remain enabled, the boot program’s processing will not work correctly.
\nTherefore, while the boot program is setting up the stack pointer and interrupt configuration, interrupts must be disabled.
\nInitializing Segment Registers
\nThe following four lines initialize the AX, DS, ES, and SS registers to 0x0000.
The AX register is the accumulator; the other three are segment registers.
\nReference: Intel 8086 - Wikipedia
\nReference: Intel 8086 CPU Basics - Qiita
\nHere, the segment register values set by the BIOS are being initialized.
\nFor reference, here is a brief summary of each segment register’s purpose:
\n| Register | \nPurpose | \n
|---|---|
| DS register | \nDefault segment register for data | \n
| ES register | \nSegment register for data; normally DS register is used | \n
| SS register | \nSegment register for the stack; used with SP/BP memory references | \n
| CS register | \nSegment register for code; the instruction pointer (IP) uses the CS register | \n
Reference: 8086 Registers
\nEnabling the A20 Line
\nIn the Intel 8086, the A20 Line (bit 21 of memory access) is disabled by default for backward compatibility.
Therefore, to access up to 2 MB of memory, the A20 Line must be enabled.
\nThe A20 Line is initially connected to the KBC (Keyboard Controller).
\nThe KBC is a mechanism for transmitting keyboard input to the CPU.
\nThe KBC receives information from the keyboard via serial communication, buffers it, and then checks whether it is a KBC control command or input data to be forwarded to the CPU.
\nData to be forwarded to the CPU goes through port 0x60; control commands go through port 0x64.
In the following code, each step first confirms that the KBC buffer has no pending input, then sends control commands to ports 0x60 and 0x64 to enable A20.
# Physical address line A20 is tied to zero so that the first PCs \n # with 2 MB would run software that assumed 1 MB. Undo that.\nseta20.1:\n inb $0x64,%al # Wait for not busy\n testb $0x2,%al\n jnz seta20.1\n\n movb $0xd1,%al # 0xd1 -> port 0x64\n outb %al,$0x64\n\nseta20.2:\n inb $0x64,%al # Wait for not busy\n testb $0x2,%al\n jnz seta20.2\n\n movb $0xdf,%al # 0xdf -> port 0x60\n outb %al,$0x60In the example above, control command 0xd1 is sent to port 0x64, followed by 0xdf being sent to port 0x60, which enables A20.
Reference: A20 Line - OSDev Wiki
\nReference: A20 gate and keyboard controller (using xv6 as example) - 私のひらめき日記
\nReference: assembly - The A20 Line with JOS - Stack Overflow
\nSwitching to Protected Mode
\nFrom here, the program switches to protected mode.
\nUnlike real mode, protected mode provides memory protection — programs can only access memory regions they are permitted to access.
\nTherefore, when transitioning from real mode to protected mode, the memory regions accessible to the kernel being loaded must be defined in advance.
\n # Switch from real to protected mode. Use a bootstrap GDT that makes\n # virtual addresses map directly to physical addresses so that the\n # effective memory map doesn't change during the transition.\n lgdt gdtdesc\n movl %cr0, %eax\n orl $CR0_PE, %eax\n movl %eax, %cr0\n\n//PAGEBREAK!\n # Complete the transition to 32-bit protected mode by using a long jmp\n # to reload %cs and %eip. The segment descriptors are set up with no\n # translation, so that the mapping is still the identity mapping.\n ljmp $(SEG_KCODE<<3), $start32\n\n.code32 # Tell assembler to generate 32-bit code now.\nstart32:The actual switch to protected mode happens in these lines:
\nmovl %cr0, %eax\norl $CR0_PE, %eax\nmovl %eax, %cr0On x86 CPUs, enabling protected mode requires setting the PE flag in the control register to 1.
\nThe assembly code above uses an or operation to set the PE flag of the control register to 1.
This completes the transition to protected mode.
\nThe GDT must be initialized before this step.
\nReference: Control register - Wikipedia
\nMemory Address References in Protected Mode
\nIn protected mode, the GDT (Global Descriptor Table) is used for memory address references.
\nThe GDT mechanism is a larger topic, so I have summarized it as a separate article.
\nReference: Notes on x86 CPU Memory Protection (GDT and LDT)
\nlgdt gdtdesc
\nThe lgdt instruction registers a GDT data structure into the GDTR.
The gdtdesc stored here is the following label defined in bootasm.S:
# Bootstrap GDT\n.p2align 2 # force 4 byte alignment\ngdt:\n SEG_NULLASM # null seg\n SEG_ASM(STA_X|STA_R, 0x0, 0xffffffff) # code seg\n SEG_ASM(STA_W, 0x0, 0xffffffff) # data seg\n\ngdtdesc:\n .word (gdtdesc - gdt - 1) # sizeof(gdt) - 1\n .long gdt # address gdt.p2align 2 forces the immediately following instruction or data to be placed on a 4-byte boundary.
This means data is placed starting at an address that is a multiple of 4.
\nReference: c - What is meant by “memory is 8 bytes aligned”? - Stack Overflow
\nThe next line attaches the gdt label to the line where the SEG_NULLASM macro and others are placed.
These macros are defined in asm.h as follows:
//\n// assembler macros to create x86 segments\n//\n\n#define SEG_NULLASM \\\n .word 0, 0; \\\n .byte 0, 0, 0, 0\n\n// The 0xC0 means the limit is in 4096-byte units\n// and (for executable segments) 32-bit mode.\n#define SEG_ASM(type,base,lim) \\\n .word (((lim) >> 12) & 0xffff), ((base) & 0xffff); \\\n .byte (((base) >> 16) & 0xff), (0x90 | (type)), \\\n (0xC0 | (((lim) >> 28) & 0xf)), (((base) >> 24) & 0xff)\n\n#define STA_X 0x8 // Executable segment\n#define STA_W 0x2 // Writeable (non-executable segments)\n#define STA_R 0x2 // Readable (executable segments)The GDT in an x86 CPU is basically a structure consisting of multiple 8-byte descriptors placed consecutively.
\nReference: Global Descriptor Table - Wikipedia
\nReference: Writing an OS from Scratch (ゼロからのOS自作入門)
\nThe following is the descriptor structure introduced in 30-Day OS Development (30日でできる! OS自作入門).
\nIt is easier to understand than the xv6 code, so I am including it here:
\nstruct SEGMENT_DESCRIPTOR{\n short limit_low, base_low;\n char base_mid, access_right;\n char limit_high, base_high;\n};Reference: 30-Day OS Development (30日でできる! OS自作入門)
\nAt the beginning of the GDT (the first descriptor), a null descriptor with all values set to 0 is placed.
\nThis is never referenced by the system.
\nThe null descriptor is used to invalidate segment registers.
\nReference: Why x86 processor need a NULL descriptor in GDT? - Stack Overflow
\nThe second descriptor defines the code segment descriptor, and the third defines the data segment descriptor.
\nThe code segment is granted read and execute permissions; the data segment is granted write permission.
\nFinally, using the address of the GDT created by these macros, the lgdt gdtdesc instruction initializes the GDTR.
The GDTR holds a 48-bit value.
\nThe upper 32 bits hold the starting address of the GDT (the gdt label).
The lower 16 bits hold the limit value (the number of GDT entries).
\nReference: GDTR (Global Descriptor Table Register) - ゆずさん研究所
\nWhen a program uses a descriptor such as LDT, it is referenced as an offset from the starting address set in the GDTR.
\nThis completes the GDTR initialization.
\nReference: assembly - Why in xv6 there’s sizeof(gdt)-1 in gdtdesc - Stack Overflow
\nReference: OS boot series ⑮-2 entryother.S (Reading Unix xv6 ~ OS Code Reading ~) - 野良プログラマーのCS日記
\nStarting 32-bit Mode
\nWith GDTR initialization and the transition to protected mode complete, the system now operates in 32-bit mode.
\n//PAGEBREAK!\n # Complete the transition to 32-bit protected mode by using a long jmp\n # to reload %cs and %eip. The segment descriptors are set up with no\n # translation, so that the mapping is still the identity mapping.\n ljmp $(SEG_KCODE<<3), $start32\n\n.code32 # Tell assembler to generate 32-bit code now.\nstart32:The ljmp instruction takes a segment selector as its first operand and an offset address (the start32 label) as its second operand, then jumps to the address corresponding to the segment base + offset for the given selector.
SEG_KCODE is defined in mmu.h as follows:
// various segment selectors.\n#define SEG_KCODE 1 // kernel code\n#define SEG_KDATA 2 // kernel data+stack\n#define SEG_UCODE 3 // user code\n#define SEG_UDATA 4 // user data+stack\n#define SEG_TSS 5 // this process's task stateFrom the above, the segment selector defined by $(SEG_KCODE<<3) is 0b1000.
This points to the second segment in the GDT, which is the code segment.
\nA segment selector is 16 bits, as described on the following page: the upper 13 bits hold the descriptor index (index from the beginning of the GDT), and the lower 3 bits hold the Table Indicator (TI) and Requestor Privilege Level (RPL).
\nReference: Segment Selector - ゆずさん研究所
\nWhen TI is 0, the GDT is referenced. (When TI is 1, the LDT is referenced.)
\nWhen RPL is 0, it indicates privileged access.
\nHere, the segment selector 0b1000 defined by $(SEG_KCODE<<3) represents a segment register with index 1, TI 0, and RPL 0.
Why Use the ljmp Instruction?
\nThis code raised a question for me.
\nOnce the %cr0 setting is complete and the transition to protected mode has been performed, it should be possible to call the start32 processing without explicitly using the ljmp instruction.
lgdt gdtdesc\n movl %cr0, %eax\n orl $CR0_PE, %eax\n movl %eax, %cr0\n ljmp $(SEG_KCODE<<3), $start32\n\n.code32 # Tell assembler to generate 32-bit code now.\nstart32:\n{{ 省略 }}The reason ljmp is explicitly used here is to discard the instructions that the CPU pre-fetched from memory while still operating in real mode.
CPUs have a mechanism called a pipeline to execute instructions at high speed, which pre-fetches the next instruction.
\nHowever, when transitioning to protected mode, the interpretation of machine code changes from real mode, so this pipeline must be reset.
\nBy calling the ljmp instruction, the values of the cs register and the eip register are reloaded.
Post-Protected-Mode Setup
\nWe are almost done tracing all of bootasm.S.
The last behavior to examine is the following:
\n.code32 # Tell assembler to generate 32-bit code now.\nstart32:\n # Set up the protected-mode data segment registers\n movw $(SEG_KDATA<<3), %ax # Our data segment selector\n movw %ax, %ds # -> DS: Data Segment\n movw %ax, %es # -> ES: Extra Segment\n movw %ax, %ss # -> SS: Stack Segment\n movw $0, %ax # Zero segments not ready for use\n movw %ax, %fs # -> FS\n movw %ax, %gs # -> GS\n\n # Set up the stack pointer and call into C.\n movl $start, %esp\n call bootmain\n\n # If bootmain returns (it shouldn't), trigger a Bochs\n # breakpoint if running under Bochs, then loop.\n movw $0x8a00, %ax # 0x8a00 -> port 0x8a00\n movw %ax, %dx\n outw %ax, %dx\n movw $0x8ae0, %ax # 0x8ae0 -> port 0x8a00\n outw %ax, %dx\nspin:\n jmp spinInitializing Segment Registers
\nHere, segment registers other than CS are initialized.
\nHaving transitioned from real mode to protected mode, the usage of segment selectors has changed.
\nSpecifically, in real mode, memory address references used a scheme of multiplying the segment portion by 16 and adding it to the offset; in protected mode, this changes to referencing segment descriptors.
\nReference: Insider’s Computer Dictionary: What is 8086? - @IT
\nTherefore, in protected mode, segment selectors must be stored in segment registers.
\nstart32:\n # Set up the protected-mode data segment registers\n movw $(SEG_KDATA<<3), %ax # Our data segment selector\n movw %ax, %ds # -> DS: Data Segment\n movw %ax, %es # -> ES: Extra Segment\n movw %ax, %ss # -> SS: Stack Segment\n \n movw $0, %ax # Zero segments not ready for use\n movw %ax, %fs # -> FS\n movw %ax, %gs # -> GSThe segment selector is set by $(SEG_KDATA<<3).
SEG_KDATA was defined as 2 in mmu.h.
Therefore, $(SEG_KDATA<<3) becomes 0b10000.
This is the selector that specifies the third segment descriptor defined in the GDT, SEG_ASM(STA_W, 0x0, 0xffffffff).
Using these values, the DS, ES, and SS segment registers are initialized.
\nFS and GS are set to 0.
\nWhen a segment selector is 0, the segment register is invalidated.
\nCalling bootmain.c
\nFrom here, processing moves to bootmain.c.
As seen earlier, $start is placed at 0x7C00.
That is, the stack pointer (the base address for the stack) is 0x7C00.
# Set up the stack pointer and call into C.\nmovl $start, %esp\ncall bootmainBased on the understanding so far, this diagram shows the layout (please correct me if I am wrong):
\n![\"https://yukituna.com/wp-content/uploads/2022/01/image-15.png\"](\"https://yukituna.com/wp-content/uploads/2022/01/image-15.png\")
Note: the following code handles what happens if bootmain.c returns (which it should not), so it is omitted here.
# If bootmain returns (it shouldn't), trigger a Bochs\n # breakpoint if running under Bochs, then loop.\n movw $0x8a00, %ax # 0x8a00 -> port 0x8a00\n movw %ax, %dx\n outw %ax, %dx\n movw $0x8ae0, %ax # 0x8ae0 -> port 0x8a00\n outw %ax, %dx\nspin:\n jmp spinLoading the Kernel
\nThe transition to protected mode is now complete, and processing has switched to bootmain.c.
bootmain.c defines the following four functions:
- \n
- void bootmain(void) \n
- void waitdisk(void) \n
- void readsect(void *dst, uint offset) \n
- void readsect(void *dst, uint offset) \n
From here, we will trace the behavior of bootmain.c.
Loading the ELF Kernel Image from Disk
\nbootmain() is the function responsible for loading the ELF kernel image from disk.
Let us walk through it from the beginning.
\nvoid bootmain(void)\n{\n struct elfhdr *elf;\n struct proghdr *ph, *eph;\n void (*entry)(void);\n uchar* pa;\n\n elf = (struct elfhdr*)0x10000; // scratch space\n\n // Read 1st page off disk\n readseg((uchar*)elf, 4096, 0);\n\n // Is this an ELF executable?\n if(elf->magic != ELF_MAGIC)\n return; // let bootasm.S handle error\n\n // Load each program segment (ignores ph flags).\n ph = (struct proghdr*)((uchar*)elf + elf->phoff);\n eph = ph + elf->phnum;\n for(; ph < eph; ph++){\n pa = (uchar*)ph->paddr;\n readseg(pa, ph->filesz, ph->off);\n if(ph->memsz > ph->filesz)\n stosb(pa + ph->filesz, 0, ph->memsz - ph->filesz);\n }\n\n // Call the entry point from the ELF header.\n // Does not return!\n entry = (void(*)(void))(elf->entry);\n entry();\n}The structs elfhdr and proghdr declared at the top are both defined in elf.h:
// Format of an ELF executable file\n\n#define ELF_MAGIC 0x464C457FU // \"\\x7FELF\" in little endian\n\n// File header\nstruct elfhdr {\n uint magic; // must equal ELF_MAGIC\n uchar elf[12];\n ushort type;\n ushort machine;\n uint version;\n uint entry;\n uint phoff;\n uint shoff;\n uint flags;\n ushort ehsize;\n ushort phentsize;\n ushort phnum;\n ushort shentsize;\n ushort shnum;\n ushort shstrndx;\n};\n\n// Program section header\nstruct proghdr {\n uint type;\n uint off;\n uint vaddr;\n uint paddr;\n uint filesz;\n uint memsz;\n uint flags;\n uint align;\n};\n\n// Values for Proghdr type\n#define ELF_PROG_LOAD 1\n\n// Flag bits for Proghdr flags\n#define ELF_PROG_FLAG_EXEC 1\n#define ELF_PROG_FLAG_WRITE 2\n#define ELF_PROG_FLAG_READ 4The details of this struct are covered by the following page, so I will skip them here.
\nReference: Executable and Linkable Format - Wikipedia
\nThe line void (*entry)(void); declares a function pointer.
Ultimately, it retrieves the entry point from the loaded ELF header and calls it.
\nReading Sectors from Disk
\nNext, let us look at the following section:
\nelf = (struct elfhdr*)0x10000; // scratch space\n\n// Read 1st page off disk\nreadseg((uchar*)elf, 4096, 0);I was initially unclear about what elf = (struct elfhdr*)0x10000; was doing. It casts the region starting at address 0x10000 as an elfhdr struct, allowing access to that region through the pointer variable elf.
This pointer variable elf is then cast to an unsigned char pointer on the next line and passed as the first argument to the readseg function.
Reference: Reading the xv6 Boot Loader
\nThe line readseg((uchar*)elf, 4096, 0); loads 4096 bytes of data into the address (uchar*)elf.
The reason 4096 bytes are read even though an ELF header is only 52 bytes is explained in the following reference:
\nReference: x86 - XV6: bootmain - loading kernel ELF header - Stack Overflow
\nThe background is that since the combined size of the ELF header and program headers is unknown at call time, one full page of data is read with the expectation that the ELF header and program headers will fit within 4 KB.
\nThe page size for x86 CPUs is 4096 bytes (4 KB) (note: the original source contains a typo of 4069).
\nReference: Why is the page size of Linux (x86) 4 KB, how is that calculated? - Stack Overflow
\nThe readseg function looks like this.
Internally, the readsect function reads 4096 bytes of data from the second sector (sector 1) one sector at a time from disk and writes it to the uchar* pa region.
// Read 'count' bytes at 'offset' from kernel into physical address 'pa'.\n// Might copy more than asked.\nvoid readseg(uchar* pa, uint count, uint offset)\n{\n uchar* epa;\n epa = pa + count;\n\n // Round down to sector boundary.\n pa -= offset % SECTSIZE;\n \n // Translate from bytes to sectors; kernel starts at sector 1.\n offset = (offset / SECTSIZE) + 1;\n\n // If this is too slow, we could read lots of sectors at a time.\n // We'd write more to memory than asked, but it doesn't matter --\n // we load in increasing order.\n for(; pa < epa; pa += SECTSIZE, offset++)\n readsect(pa, offset);\n}Here is the readsect function:
// Read a single sector at offset into dst.\nvoid readsect(void *dst, uint offset)\n{\n // Issue command.\n waitdisk();\n outb(0x1F2, 1); // count = 1\n outb(0x1F3, offset);\n outb(0x1F4, offset >> 8);\n outb(0x1F5, offset >> 16);\n outb(0x1F6, (offset >> 24) | 0xE0);\n outb(0x1F7, 0x20); // cmd 0x20 - read sectors\n\n // Read data.\n waitdisk();\n insl(0x1F0, dst, SECTSIZE/4);\n}This type of disk access uses a method called Cylinder-head-sector (CHS).
Modern operating systems (probably) do not implement disk reads this way, so I will skip the details of CHS.
\nReference: Cylinder-head-sector - Wikipedia
\nReference: c - xv6 boot loader: Reading sectors off disk using CHS - Stack Overflow
\nThe reason the line offset = (offset / SECTSIZE) + 1; reads from the second sector (sector 1) is that, as confirmed in the Makefile section, the kernel program is placed at offset 512 bytes into the image.