Kernel on Siddharth Mishra

Implementing Descriptor Tables

Mon, 10 Jan 2022 00:00:00 +0000

WARNING : From here onwards you need some experience with x86_64 assembly. I’ve done some reverse engineering stuffs so I have some basic knowledge to find my way out of this. You’ll need something similar! You must have knowledge of what are registers, how many registers are there in amd64 architecture, what are the uses of those registers, etc… Knowledge of more low level concepts will be a cherry on the top.

Creating Our Own 'puts'

Sun, 09 Jan 2022 00:00:00 +0000

Well, the title can be misleading. We will be eventually implementing our own ‘puts’ function but for now it’s not named puts. The function will be analogous to puts. This function will actually be to help us debug things. After this chapter we will be adding more and more features to our OS and we need a method to see if it worked or not. This method can be anything! For eg : changing the screen colour to red (for error) or blue (for success). We print an error message if something bad happens.

Project Initialisation

Sat, 08 Jan 2022 00:00:00 +0000

We’ll use limine bootloader and use stivale2 as our boot protocol. There are multiple boot protocols and stivale2 provides many advanced features. Limine supports stivale2 by default. It also gives us a way to instantly print anything on screen but we won’t be using that. To read more about stivale2 boot specification, read here

Create project with following directory structure

.
├── CMakeLists.txt
├── kernel
│   ├── kernel.c
│   ├── kernel.h
│   └── stivale2.h
└── limine
 ├── bochsrc
 ├── build-aux
.
.
.

19 directories, 183 files

kernel will contain our kernel code. Soon we’ll be creating many other folders. Use wget to get stivale2 header file. Initialise a git repository and add limine boot loader as a submodule.

System Boot

Sat, 08 Jan 2022 00:00:00 +0000

This will be a post on what actually happens when a system boots up.

When system boots up motherboard first checks if all necessary components are attached or not. If they are not then it shows it’s tantrums that one needs to debug. Motherboard first initialises it’s firmware, i.e the chipset and other things needed for normal startup.

Then the control is sent to the bootloader that is responsible for further initialisation of kernel which ultimately loads the complete OS. If on a multicore processor, one of the core is chosen dynamically (the bootstrap processor : BSP) and is given the responsibility to run the code for bootloader and kernel. The remaining cores remain halted unless being used explicitly by kernel or bootloader.