StackOverflow2013

Note that there are some explanatory texts on larger screens.

plurals

PO
text
Body
copied!<p>"How to load a kernel" comes down to knowing where the kernel is on disk and where you want it in memory, and then using BIOS disk services to read it. If you want the kernel to be loaded above 0x00100000 then you may need to load each part into a temporary buffer (that the BIOS can access in real mode), then use either protected mode or "unreal mode" to copy it from the buffer to where you actually want it. If you want to support compression, then you may need to load files then decompress them. If you want the kernel to use a complex file format (e.g. ELF or PE, rather than a simple flat binary) then you may need to parse headers, relocate sections, etc too.</p> <p>My boot loaders are typically much larger than 1 sector. Code in the first sector loads the second sector, and code in the first and second sectors load the remainder of the boot loader. In this way the boot loader can be 20 KiB (for e.g.), as long as you're careful and don't try to use any code or data that hasn't been loaded yet. You could also have a second stage (and third, fourth, etc stages if you felt like it) where the boot loader loads the second stage, and the second stage loads the next piece, etc.</p> <p>For where to store the binaries, this depends on what file system/s you're planning to use. If you don't want any file system (or if the file system you want to use has enough "reserved" space at the beginning), then you could just concatenate the binary files together and store them immediately after the boot loader. Otherwise, the boot loader (and/or additional stages) will need to find files in whichever file system you're using.</p> <p>Note: Different boot loaders work differently. For something like booting from network, the boot loader can be 512 KiB and needs to download data from the network using the PXE API. For CD-ROM you'll probably end up using the ISO9660 file system (and 2 KiB sectors). For hard disks you'll need to handle partitions (and maybe have one boot loader for "MBR partitions" and another boot loader for "GPT partitions"). What you'll end up with is several completely different boot loaders, that all load the kernel (or maybe some sort of RAM disk image if it's a micro-kernel) and leave the computer in a certain state when starting the kernel (e.g. a specific CPU mode, the kernel at a specific address, other file/s at specific places, etc), such that the kernel itself needn't care which boot loader loaded it. For extra complexity, it's possible to include a lot more in this "predefined state" (e.g. address of ACPI tables, description of preconfigured video mode, etc) so that it's possible to write boot loaders for other types of systems and the kernel won't need to care if it booted from "PC BIOS" or UEFI or OpenFirmware or whatever else.</p>

Querying!

Guidance

An individual column

Larger individual text columns get their own page to allow for proper reading.

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload