How to load kernel or be able to use more space in

2019-06-27 11:19发布

I've been following this:
( http://www.codeproject.com/KB/tips/boot-loader.aspx )
But not sure what and how to do next.
How to load self written kernel in it? Or how to make more place than in single segment?
And what to do with binaries? I have to copy bootloader to first sector, ok, but what with kernel, etc, just put on floppy/disc?

2条回答
Evening l夕情丶
2楼-- · 2019-06-27 11:39

Typically, the main thing your boot sector will need to do is load either a second-stage loader or the kernel in to memory. Assuming you are using a PC, you will use the BIOS disk read functions to load sectors. Doing this from a FAT formatted floppy is perfectly possible in the 512b you get for your boot sector. Alternatively, boot from a no-emulation El-Torito CD which gives you more space for your boot loader.

For further information, take a look at OSDev.org or Bona Fide OS Dev.

查看更多
ゆ 、 Hurt°
3楼-- · 2019-06-27 11:50

"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.

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.

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.

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.

查看更多
登录 后发表回答