Performance Zone is brought to you in partnership with:

I’m a swiss Master student in Computer Science. I’m very interested in C++, open source projects, Linux, Intel Assembly and Agile. I'm currently working on Eddi, a new programming language that I created to improve my skills in C++. I've also worked a lot on Java technologies (Sprint, Osgi, Play!, ...), but I'm not currently working with Java anymore. Baptiste is a DZone MVB and is not an employee of DZone and has posted 51 posts at DZone. You can read more from them at their website. View Full User Profile

Thor OS: Boot Process

01.07.2014
| 7858 views |
  • submit to reddit

Some time ago, I started a hobby project: writing a new operating system. I’m not trying to create a concurrent to Linux, I’m just trying to learn some more stuff about operating systems. I’m gonna try to write some posts about this kernel on this blog.

In this post, I’ll describe the boot process I’ve written for this operating system.

Bootloader Step

The first step is of course the bootloader. The bootloader is in the MBR and is loaded by the system at 0x7C00.

I’m doing the bootloading in two stages. The first stage (one sector) print some messages and then load the second stage (one sector) from floppy at 0×900. The goal of doing it in two stages is just to be able to overwrite the bootloader memory by the stage. The second stage loads the kernel into memory from floppy. The kernel is loaded at 0×1000 and then run directly.

The bootloader stages are written in assembly.

Real mode

When the processor, it boots in real mode (16 bits) and you have to setup plenty of things before you can go into long mode (64 bits). So the first steps of the kernel are running in 16 bits. The kernel is mostly written in C++ with some inline assembly.

Here are all the things that are done in this mode:

  1. The memory is inspected using BIOS E820 function. It is necessary to do that at this point since BIOS function calls are not available after going to protected mode. This function gives a map of the available memory. The map is used later by the dynamic memory allocator.
  2. The interrupts are disabled and a fake Interrupt Descriptor Table is configured to make sure no interrupt are thrown in protected mode
  3. The Global Descriptor Table is setup. This table describes the different portion of the memory and what each process can do with each portion of the memory. I have three descriptors: a 32bit code segment, a data segment and a 64bit code segment.
  4. Protected mode is activated by setting PE bit of CR0 control register.
  5. Disable paging
  6. Jump to the next step. It is necessary to use a far jump so that the code segment is changed.

Protected Mode

At this point, the processor is running in protected mode (32 bits). BIOS interrupts are not available anymore.

Again, several steps are necessary:

  1. To be able to use all memory, Physical Address Extensions are activated.
  2. Long Mode is enabled by setting the EFER.LME bit.
  3. Paging is setup, the first MiB of memory is mapped to the exact same virtual addresses.
  4. The address of the Page-Map Level 4 Table is set in the CR0 register.
  5. Finally paging is activated.
  6. Jump to the real mode kernel, again by using a far jump to change code segment.

Real Mode

The kernel finally runs in 64 bits.

There are still some initialization steps that needs to be done:

  1. SSE extensions are enabled.
  2. The final Interrupt Descriptor Table is setup.
  3. ISRs are created for each possible processor exception
  4. The IRQs are installed in the IDT
  5. Interrupts are enabled

At this point, is kernel is fully loaded and starts initialization stuff like loading drivers, preparing memory, setting up timers…

If you want more information about this process, you can read the different source files involved (stage1.asm, stage2.asm, boot_16.cpp, boot_32.cpp and kernel.cpp) and if you have any question, you can comment on this post.

Published at DZone with permission of Baptiste Wicht, author and DZone MVB. (source)

(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)