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?
相关问题
- Why should we check WIFEXITED after wait in order
- Null-terminated string, opening file for reading
- What's the difference between 0 and dword 0?
- Linux kernel behaviour on heap overrun or stack ov
- Where is the standard kernel libraries to let kern
相关文章
- How do I get to see DbgPrint output from my kernel
- What happens to dynamic allocated memory when call
- Is it possible to run 16 bit code in an operating
- How to generate assembly code with gcc that can be
- Select unique/deduplication in SSE/AVX
- How to arrange a Makefile to compile a kernel modu
- Optimising this C (AVR) code
- Why does the latency of the sqrtsd instruction cha
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.
"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.