Start to Finish: Grub

From XOmB wiki

This page is part of a series on XBB From Start to Finish. Start to Finish: Grub Start to Finish: Switching to Long Mode Start to Finish: Moving From Low to High Memory Start to Finish: Calling kmain Start to Finish: Printing to the Screen Start to Finish: The Kernel Runtime

Welcome to XOmB Bare Bones: From Start to Finish. This is the first of several articles explaining the process the kernel goes through from the initial boot code to the familiar interface of kmain.

In this article, we explain the boot loader. In the XOmB Bare Bones project, GRUB is utilized. It is a very flexible and open source boot loader that is fairly popular, primarily with Linux based distributions.

But, we will treat this article as a drastically simplified overview of what a boot loader must contend with. As such, let us start with the moment the computer gains control.

[edit] It's Aliiiive!

When the processor starts, it executes code found at address 0xFFFF0. This generally is just enough code to call a BIOS routine that selects a boot device and call the boot loader associated with that device.

Normally this boot loader code has to be very small to fit the constraints of hardware. For instance, the logic contained in the Master Boot Record of your disk. It is this reason that these boot loaders are typically just one stage of the process. They implement the logic to load and execute what is called a Stage 2 Loader or a Second-Stage Boot Loader. GRUB is one of these.

The processor starts out, as it weren't bad enough, in 16-bit real mode. The boot loader can take on the responsibility of passing control to a kernel in a more modern context, abstracting away the legacy.

[edit] GRUB and the Multiboot Specification

GRUB, as a boot loader, conforms to the multiboot specification. This specification gives the kernel access to all of the lower level, architecture business that GRUB does on its behalf. For instance, information on disks available and information on the physical memory of the system are both provided.

Ref: [1]. In the XOmB Bare Bones Kernel's kmain, a pointer to such a structure can be passed and compared against a boot loader id. If this id signifies GRUB, the structure can be used to provide the multiboot structure that is the result of the multiboot specification implementation.

In the bare bones, none of the information passed is used. It is up to the developer of the bare bones to accept GRUB (or any multiboot implementer) as a possible boot loader and do the work of validating the multiboot information that is passed.

What GRUB does do for us, which is moderately important for us, is give us information about the physical memory (which is a tedious, fairly undocumented, and mysterious task to say the least) and perform the jump to protected mode. This limits the liability of doing these crazy tasks and limits the amount of work necessary to complete it.

[edit] GRUB and the Kernel

Ref: [2]. GRUB will do its magical business first and then worry about loading the kernel from the menu.lst. It will load the kernel module at physical address 0x100000 (1MB in user-speak). From there it will look for a special kludge called the multiboot header within the code section. This should be linked within your code to be somewhere toward the beginning of your kernel.

Ref: [3]. This header contains the entry point where GRUB will pass execution. In the bare bones, it will pass execution to our _start function as GRUB is told in the multiboot header found near that particular function.

From there, it is your code that is executing. From here, you can do anything you like! The XOmB Bare Bones will go from here to execute an architecture independent kmain function. First, however, we must go through the trials of the architecture with some assembly to get ourselves into 64 bit mode and beyond. This will be the subject of the next part of the series.