OSDev.org

Hi,

So I was wondering how bootloaders usually know how many sectors they should load to have the whole kernel in memory. I'm in the situation where I have to manually tell my bootloader to load X sectors, so I have to calculate myself the right number and update the bootloader code. But I want it to be an "automatic thing". So is this process based on a filesystem ? Do I have to let's say implement a FAT12 filesystem and therefore load sectors ? I'm confuses on how bootloaders generally load the whole kernel and therefore know that they are X sectors that it has to read.

I was looking at many bootloaders code but I never actually found how they implement a such thing.
Some explanation would be very welcome. Have a great day !

Most bootloaders use the filesystem.

Some bootloaders use an installer that automatically updates the boot sector with the location and length of the kernel.

Octocontrabass wrote:Most bootloaders use the filesystem.

Some bootloaders use an installer that automatically updates the boot sector with the location and length of the kernel.

So choosing for example FAT12 wouldn't be a great idea if the kernel is big enough right ?

liwinux wrote: So choosing for example FAT12 wouldn't be a great idea if the kernel is big enough right ?

It seems very unlikely that your kernel one day becomes bigger that what FAT12 can support. The thing that matter when choosing the filesystem is more what amount of file data you want to handle. When writing your 2nd stage bootloader, there's nothing preventing you to support multiple filesystems as you should have plenty of space to do so.

laen wrote:

liwinux wrote: So choosing for example FAT12 wouldn't be a great idea if the kernel is big enough right ?

It seems very unlikely that your kernel one day becomes bigger that what FAT12 can support. The thing that matter when choosing the filesystem is more what amount of file data you want to handle. When writing your 2nd stage bootloader, there's nothing preventing you to support multiple filesystems as you should have plenty of space to do so.

Of course, I'm not planing to have a bigger kernel that FAT12 can support but it was rather an example to better understand what's going on when loading sectors into memory. I was more thinking for example the situation with grub and how it can load Linux into memory and start executing it. Surely FAT12 isn't enough for it. As you said, I guess grub uses an installer and therefore knows the total size of the kernel right ?

GRUB uses both methods. First it uses a list of sectors to find and load the rest of itself, then it uses the filesystem to find and load the kernel.

Octocontrabass wrote:GRUB uses both methods. First it uses a list of sectors to find and load the rest of itself, then it uses the filesystem to find and load the kernel.

Thank you, I think I now have a better understanding on how this process is done under the hood !

You have great ambitions if you think your kernel is going to exceed 32MB; that's about twice the size of an uncompressed Linux kernel.

Having said that, I'd give FAT12 a miss; the 12-bit FAT entries make life more complicated than -say - FAT16.

iansjack wrote:You have great ambitions if you think your kernel is going to exceed 32MB; that's about twice the size of an uncompressed Linux kernel.

Having said that, I'd give FAT12 a miss; the 12-bit FAT entries make life more complicated than -say - FAT16.

Well yeah that's 100% sure it won't exceed 32MB. But let's take the example of having the boot loader and the kernel placed right after it. Let's also say there isn't any filesystem implemented. How could the boot loader therefore know how many sectors it has to read and load ?

One way to do it (without a file system) with NASM is to assemble and link the kernel into a binary and then include the kernel binary inside the bootloader at the end. An example of this is here: https://stackoverflow.com/a/54894586/3857942 . This example works with floppies but you can use the idea of including the kernel binary and compute the sectors for your own purposes.

However you load your kernel you have to somehow tell the loader how large the kernel is and which address to load it to. This is why kernels are often compiled as ELF files (or Windows PE files) that already contain all the necessary information. If you don’t want to do this then it’s up to you how you pass the information of where the kernel is loaded and how large it is. One simple solution would be to reserve the first few bytes of the kernel to store this information.

MichaelPetch wrote:One way to do it (without a file system) with NASM is to assemble and link the kernel into a binary and then include the kernel binary inside the bootloader at the end. An example of this is here: https://stackoverflow.com/a/54894586/3857942 . This example works with floppies but you can use the idea of including the kernel binary and compute the sectors for your own purposes.

Thank you, I'll have a look when it's possible for me. However I think that's what I was looking for

iansjack wrote:However you load your kernel you have to somehow tell the loader how large the kernel is and which address to load it to. This is why kernels are often compiled as ELF files (or Windows PE files) that already contain all the necessary information.

ELF files contains informations about their size in bytes ?

iansjack wrote:One simple solution would be to reserve the first few bytes of the kernel to store this information.

So for example for a one stage boot loader, having the 513th bytes to store this info right ?

Yes, an ELF file contains information about the size and location of all its sections.

You’d need more than one byte to store the size of the kernel, but you could reserve the first 16 bytes of the kernel to store a couple of variables for the size and load address. Personally, I would use an ELF file and some file system, and I’d use GRUB to load the kernel. As well as loading the kernel it provides other useful information - e.g. the memory map.

Having a file system doesn’t mean that you have to implement it before you can load the kernel - GRUB takes care of that. But you’re going to need a file system sooner or later; your OS can’t do a lot without it.

This solution is probably not applicable to many kernels, but this is what my bootloader does:

There is a /boot partition where I store the kernel binary and several other binaries that are important for the system to use immediately (e.g. disk driver, file system drivers). A monolithic kernel probably wouldn't have as much to put here.

The MBR passes the partition number to the partitions bootloader, so it can know which entry it is. It then uses this information to lookup the size of the partition and load the entire thing into memory. The partition uses an extremely simple file system (there is a list of file names, sizes and sector offsets at the start, then all the data), so the bootloader just jumps straight into the first file on disk, which is at a known offset.

The kernel can also use this entire partition as a kind of initial ram disk, which makes it practical to load more without a disk driver running yet.

Basically, don't parse the file system in the bootloader, just load the whole partition into memory and let the kernel do the parsing work. This way you can use whatever file system you want very easily.