|
|
@@ -1,10 +1,10 @@
|
|
|
Kernel booting process. Part 1.
|
|
|
================================================================================
|
|
|
|
|
|
-From the bootloader to kernel
|
|
|
+From the bootloader to the kernel
|
|
|
--------------------------------------------------------------------------------
|
|
|
|
|
|
-If you have read my previous [blog posts](http://0xax.blogspot.com/search/label/asm), you can see that sometime ago I started to get involved with low-level programming. I wrote some posts about x86_64 assembly programming for Linux. At the same time, I started to dive into the Linux source code. I have a great interest in understanding how low-level things work, how programs run on my computer, how they are located in memory, how the kernel manages processes and memory, how the network stack works on low-level and many many other things. So, I decided to write yet another series of posts about the Linux kernel for **x86_64**.
|
|
|
+If you have read my previous [blog posts](http://0xax.blogspot.com/search/label/asm), you can see that sometime ago I started to get involved with low-level programming. I wrote some posts about x86_64 assembly programming for Linux. At the same time, I started to dive into the Linux source code. I have a great interest in understanding how low-level things work, how programs run on my computer, how they are located in memory, how the kernel manages processes and memory, how the network stack works at a low level and many many other things. So, I decided to write yet another series of posts about the Linux kernel for **x86_64**.
|
|
|
|
|
|
Note that I'm not a professional kernel hacker and I don't write code for the kernel at work. It's just a hobby. I just like low-level stuff, and it is interesting for me to see how these things work. So if you notice anything confusing, or if you have any questions/remarks, ping me on twitter [0xAX](https://twitter.com/0xAX), drop me an [email](anotherworldofworld@gmail.com) or just create an [issue](https://github.com/0xAX/linux-insides/issues/new). I appreciate it. All posts will also be accessible at [linux-insides](https://github.com/0xAX/linux-insides) and if you find something wrong with my English or the post content, feel free to send a pull request.
|
|
|
|
|
|
@@ -58,7 +58,7 @@ which is 65519 bytes over first megabyte. Since only one megabyte is accessible
|
|
|
|
|
|
Ok, now we know about real mode and memory addressing. Let's get back to discuss about register values after reset:
|
|
|
|
|
|
-`CS` register consists of two parts: the visible segment selector and hidden base address. We know predefined `CS` base and `IP` value, so the logical address will be:
|
|
|
+The `CS` register consists of two parts: the visible segment selector and hidden base address. We know the predefined `CS` base and `IP` value, so the logical address will be:
|
|
|
|
|
|
```
|
|
|
0xffff0000:0xfff0
|
|
|
@@ -127,7 +127,7 @@ Build and run it with:
|
|
|
nasm -f bin boot.nasm && qemu-system-x86_64 boot
|
|
|
```
|
|
|
|
|
|
-This will instruct [QEMU](http://qemu.org) to use the `boot` binary we just built as a disk image. Since the binary generated by the assembly code above fulfills the requirements of the boot sector (the origin is set to `0x7c00`, and we end with the magic sequence), QEMU will treat the binary as the master boot record(MBR) of a disk image.
|
|
|
+This will instruct [QEMU](http://qemu.org) to use the `boot` binary we just built as a disk image. Since the binary generated by the assembly code above fulfills the requirements of the boot sector (the origin is set to `0x7c00`, and we end with the magic sequence), QEMU will treat the binary as the master boot record (MBR) of a disk image.
|
|
|
|
|
|
You will see:
|
|
|
|
|
|
@@ -144,7 +144,7 @@ objdump -D -b binary -mi386 -Maddr16,data16,intel boot
|
|
|
|
|
|
A real-world boot sector has code to continue the boot process and the partition table instead of a bunch of 0's and an exclamation mark :) From this point onwards, BIOS hands over control to the bootloader.
|
|
|
|
|
|
-**NOTE**: As you can read above the CPU is in real mode. In real mode, calculating the physical address in memory is done as following:
|
|
|
+**NOTE**: As you can read above the CPU is in real mode. In real mode, calculating the physical address in memory is done as follows:
|
|
|
|
|
|
```
|
|
|
PhysicalAddress = Segment * 16 + Offset
|
ruthgrace