From 5b0a8cf468a38d95b9c8d43fc2bce65849c43720 Mon Sep 17 00:00:00 2001 From: Philipp Oppermann Date: Fri, 31 Jul 2015 19:20:46 +0200 Subject: [PATCH] Improve wording and code --- _posts/2015-07-22-rust-os-boot.md | 59 +++++++++++++++++-------------- 1 file changed, 32 insertions(+), 27 deletions(-) diff --git a/_posts/2015-07-22-rust-os-boot.md b/_posts/2015-07-22-rust-os-boot.md index bea272f0..9cd62fa7 100644 --- a/_posts/2015-07-22-rust-os-boot.md +++ b/_posts/2015-07-22-rust-os-boot.md @@ -43,7 +43,7 @@ If you don't know x86 assembly, here is some quick guide: - `dd` stands for `define double` (32bit) and `dw` stands for `define word` (16bit) - the additional `0x100000000` in the checksum calculation is a small hack[^fn-checksum_hack] to avoid a compiler warning -We can already _assemble_ this file (which I called `multiboot_header.asm`) using `nasm`. As it produces a flat binary by default, the resulting file just contains our 24 bytes (in little endian if you work on a x86 machine): +We can already _assemble_ this file (which I called `multiboot_header.asm`) using `nasm`. It produces a flat binary by default, so the resulting file just contains our 24 bytes (in little endian if you work on a x86 machine): ``` > nasm multiboot_header.asm @@ -57,20 +57,20 @@ We can already _assemble_ this file (which I called `multiboot_header.asm`) usin To boot our kernel, we must add some code that the bootloader can call. Let's create a file named `boot.asm`: ```nasm -global _start +global start BITS 32 section .text -_start: - mov dword [0xb8000], 0x2f4b2f4f - hlt +start: + mov dword [0xb8000], 0x2f4b2f4f + hlt ``` There are some new assembly lines: -- `global` exports a label (makes it public). As `_start` will be the entry point of our kernel, it needs to be public. +- `global` exports a label (makes it public). As `start` will be the entry point of our kernel, it needs to be public. - `BITS 32` specifies that the following lines are 32-bit instructions. We don't need it in our multiboot header file, as it doesn't contain any runnable code. - the `.text` section is the default section for executable code -- the `mov dword` instruction moves the 32bit constant `0x2f4f2f4b` to the memory at address `b8000` (it should write `ok` to the screen) +- the `mov dword` instruction moves the 32bit constant `0x2f4f2f4b` to the memory at address `b8000` (it writes `OK` to the screen, an explanation follows in the [next post]) - `hlt` is the halt instruction and causes the CPU to stop Through assembling, viewing and disassembling it we can see the CPU [Opcodes] in action: @@ -87,47 +87,48 @@ Through assembling, viewing and disassembling it we can see the CPU [Opcodes] in ``` ## Building the Executable -Now we create an [ELF] executable from these two files. We therefore need the object files of the two assembly files and a custom linker script (`linker.ld`): +Now we create an [ELF] executable from these two files. We therefore need the object files of the two assembly files and a custom [linker script], that we call `linker.ld`: ``` -ENTRY(_start) +ENTRY(start) SECTIONS { - . = 2M + SIZEOF_HEADERS; + . = 1M; - .boot : - { - /* ensure that the multiboot header is at the beginning */ - *(.multiboot_header) - } + .boot : + { + /* ensure that the multiboot header is at the beginning */ + *(.multiboot_header) + } - .text : - { - *(.text) - } + .text : + { + *(.text) + } } ``` The important things are: -- `_start` is the entry point, the bootloader will jump to it after loading the kernel +- `start` is the entry point, the bootloader will jump to it after loading the kernel +- `. = 1M;` sets the load address of the first section to 1 MiB, which is a conventional place to load a kernel - the executable will have two sections: `.boot` at the beginning and `.text` afterwards - the `.text` output section contains all input sections named `.text` - sections named `.multiboot_header` are added to the first output section (`.boot`) to ensure they are at the beginning of the executable -So let's create the ELF object files and link them using our new linker script. We can use `objdump` to print the sections of the generated executable. +So let's create the ELF object files and link them using our new linker script. It's important to pass the `-n` flag because otherwise the linker may page align the sections in the executable. If that happens, GRUB isn't able to find the Multiboot header because the `.boot` section isn't at the beginning anymore. We can use `objdump` to print the sections of the generated executable and verify that the `.boot` section has a low file offset. ``` > nasm -f elf64 multiboot_header.asm > nasm -f elf64 boot.asm -> ld -o kernel.bin -T linker.ld multiboot_header.o boot.o +> ld -n -o kernel.bin -T linker.ld multiboot_header.o boot.o > objdump -h kernel.bin kernel.bin: file format elf64-x86-64 Sections: Idx Name Size VMA LMA File off Algn - 0 .boot 00000018 0000000000200078 0000000000200078 00000078 2**0 + 0 .boot 00000018 0000000000100000 0000000000100000 00000080 2**0 CONTENTS, ALLOC, LOAD, READONLY, DATA - 1 .text 0000000b 0000000000200090 0000000000200090 00000090 2**4 + 1 .text 0000000b 0000000000100020 0000000000100020 000000a0 2**4 CONTENTS, ALLOC, LOAD, READONLY, CODE ``` @@ -142,15 +143,15 @@ isofiles └── kernel.bin ``` -The `grub.cfg` specifies the file name of our kernel and that it's Multiboot 2 compliant. It looks like this: +The `grub.cfg` specifies the file name of our kernel and it's Multiboot 2 compliance. It looks like this: ``` set timeout=0 set default=0 menuentry "my os" { - multiboot2 /boot/kernel.bin - boot + multiboot2 /boot/kernel.bin + boot } ``` Now we can create a bootable image using the command: @@ -172,3 +173,7 @@ qemu-system-x86_64 -hda os.iso [multiboot 2]: http://nongnu.askapache.com/grub/phcoder/multiboot.pdf [Opcodes]: https://en.wikipedia.org/wiki/Opcode [ELF]: https://en.wikipedia.org/wiki/Executable_and_Linkable_Format +[linker script]: https://sourceware.org/binutils/docs/ld/Scripts.html +[QEMU]: https://en.wikipedia.org/wiki/QEMU + +[next post]: #TODO