Start to Finish: Grub
From XOmB wiki
|This page is part of a series on XBB From Start to Finish.
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.
 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.
 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.
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.
 GRUB and the Kernel
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.