How many sectors to load yhe whole kernel
How many sectors to load yhe whole kernel
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 !
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 !
-
- Member
- Posts: 5563
- Joined: Mon Mar 25, 2013 7:01 pm
Re: How many sectors to load yhe whole kernel
Most bootloaders use the filesystem.
Some bootloaders use an installer that automatically updates the boot sector with the location and length of the kernel.
Some bootloaders use an installer that automatically updates the boot sector with the location and length of the kernel.
Re: How many sectors to load yhe whole kernel
So choosing for example FAT12 wouldn't be a great idea if the kernel is big enough right ?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.
Re: How many sectors to load yhe whole kernel
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.liwinux wrote: So choosing for example FAT12 wouldn't be a great idea if the kernel is big enough right ?
Re: How many sectors to load yhe whole kernel
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 ?laen wrote: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.liwinux wrote: So choosing for example FAT12 wouldn't be a great idea if the kernel is big enough right ?
-
- Member
- Posts: 5563
- Joined: Mon Mar 25, 2013 7:01 pm
Re: How many sectors to load yhe whole kernel
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.
Re: How many sectors to load yhe whole kernel
Thank you, I think I now have a better understanding on how this process is done under the hood !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.
Re: How many sectors to load yhe whole kernel
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.
Having said that, I'd give FAT12 a miss; the 12-bit FAT entries make life more complicated than -say - FAT16.
Re: How many sectors to load yhe whole kernel
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 ?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.
-
- Member
- Posts: 797
- Joined: Fri Aug 26, 2016 1:41 pm
- Libera.chat IRC: mpetch
Re: How many sectors to load yhe whole kernel
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.
Re: How many sectors to load yhe whole kernel
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.
Re: How many sectors to load yhe whole kernel
Thank you, I'll have a look when it's possible for me. However I think that's what I was looking forMichaelPetch 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.
Re: How many sectors to load yhe whole kernel
ELF files contains informations about their size in bytes ?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.
So for example for a one stage boot loader, having the 513th bytes to store this info right ?iansjack wrote:One simple solution would be to reserve the first few bytes of the kernel to store this information.
Re: How many sectors to load yhe whole kernel
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.
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.
Re: How many sectors to load yhe whole kernel
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.
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.