Anonymous user
I use a Custom Filesystem - What Bootloader Solution is right for me?: Difference between revisions
I use a Custom Filesystem - What Bootloader Solution is right for me? (view source)
Revision as of 07:31, 21 November 2009
, 14 years agoIN UR WIKI FIXIN UR CAPITALLIZASHUNZ
[unchecked revision] | [unchecked revision] |
(New page: The answer is GrUB. == Installing your OS on a partition == It has occurred to me that GrUB can be used to load a boot partition OS from any kind of File System. In light of this, I've w...) |
(IN UR WIKI FIXIN UR CAPITALLIZASHUNZ) |
||
Line 1:
The answer is
== Installing your OS on a partition ==
It has occurred to me that
I must give a small overview of the boot process for an OS that is installed in a partition other than the first partition, which is also not the only OS installed on the Hard Disk.
The Master Boot Record holds the Boot Manager for the disk.
Upon completion of its initialization sequence, the BIOS, in order of the priority set in the CMOS, loads a bootloader from the default boot disk. Assume that the HDD is given priority for our example.
Line 15:
So the BIOS loads the first HDD's (or second, or third, or fourth, depending on what you set the boot order to), [[Master Boot Record]] into RAM at 0x7C00 and jumps to it, passing the drive number via a register.
The MBR contains code to bootstrap an OS, or a second stage of itself, depending on how considerate the bootloader in question is.
These OSs have given
For Windows, a record is placed which indicates the partition Windows is installed on, and an instruction to ''chainload'' one sector (512 bytes) into RAM at 0x7C00, and jump to it; In other words, simply load the Windows bootloader into RAM as if it was placed there by the BIOS.
For OSs that use EXT, ReiserFS, or other directly supported
For OSs that do ''not'' use a
However, using some logic, it is possible to avoid having to do anything whatsoever in real mode, or having to write a bootloader, even for a custom FS, and have
== The
* Simply take note of the fact that the user wants to set that partition as the root, or
* If the partition has a recognizible Fs (one known by
When a partition is chosen as the root for
'''The 'kernel' command:'''
Line 43:
== How may I use this information to ensure that
Take some time to think. You are designing a custom filesystem. There is therefore no restriction on ''where'' on the partition (which absolute sector) the FS header, and therefore the FS itself should start.
Line 53:
This way, we replace the old, completely illogical standard which dictates that a partition's boot sector contains boot code, and, using the reserved sectors for your FS, place an executable image at the absolute beginning of the partition containing a full, conveniently sized boot program for your OS.
To load the program, your instructions to
<source lang="C">
Line 61:
</source>
The kernel command loads a multiboot compliant kernel, and in this case, we have specified an absolute number of sectors to load. The 'kernel' command can automatically detect if the file it's loading from the sectors is an ELF program. In other words, your 'bootloader' may even be a full ELF program, using this trick. In fact, you may even decide to place your kernel's executable image ''as the first N sectors, and have
Your kernel image, now loaded into memory (if it's an ELF, you an link it to 1MB physical), can then set itself up painlessly, and it also gets the benefit of the
This method completely invalidates the need to write a real mode bootloader.
Line 69:
There are other reasons why it is probably ''best'' that Hobbyist OS Developers use this method:
The method implies that
No more problems with writing an efficient program in 446 bytes.
And, the best advantage of all is that again,
The unification of all hobbyist OSs under one bootloader. This will mean that every OS coming out will be using
Also,
There are too many benefits for this method not to become the champion of the boot process for hobbyist OSs.
|