I use a Custom Filesystem - What Bootloader Solution is right for me?: Difference between revisions

[unchecked revision]

← Older edit

Content deleted Content added

VisualWikitext

Revision as of 16:57, 6 September 2010 view source osdev>Hangin10 mNo edit summary ← Older edit		Latest revision as of 04:32, 9 June 2024 view source Xtex (talk \| contribs) Interface administrators, Administrators 977 edits m Bot: Replace deprecated source tag with syntaxhighlight
(3 intermediate revisions by 2 users not shown)
Line 13: * 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 GRUB filesystems, you have the convenience of being able to ask GRUB to look into the partition and ''find'' your kernel file and load it into memory. * For OSs that do ''not'' use a GRUB supported File system, the convention has been to simply ask GRUB to chainload the partition boot sector for your OSs partition and jump to it. 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 FSfile system, and have GRUB do all the work. === The GRUB 'kernel' and 'chainloader' commands === Line 20: * Simply take note of the fact that the user wants to set that partition as the root, or * If the partition has a recognizable Fsfile system (one known by GRUB), GRUB can also ''mount'' it for file system parsing to actually locate a kernel image on disk. When a partition is chosen as the root for GRUB's operations, there are two ways to load an executable image: Line 29: '''The 'chainloader' command:''' The chainloader command loads an executable image of the assumed format 'binary' at 0x7C00 and jumps to the address 0x7C00. == How may I use this information to ensure that GRUB can load an executable image off my custom FS? == Line 37 ⟶ 36: To load the program, your instructions to GRUB will be something like the following: <~~source~~syntaxhighlight lang="text">rootnoverify (hd0,PARTITION_NUMBER) kernel 0+BOOT_RESERVED_OFFSET boot</~~source~~syntaxhighlight> The kernel command loads a ~~multiboot~~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 GRUB ELF load the kernel as absolute sectors, and not have to worry about parsing your custom FS at all.'' Your kernel image, now loaded into memory (if it's an ELF, you can link it to 1MB physical), can then set itself up painlessly, and it also gets the benefit of the GRUB ~~multiboot~~Multiboot Data structure passed to it. This method completely invalidates the need to write a real mode bootloader. There are other reasons why it is probably ''best'' that Hobbyist OS Developers use this method: The method implies that GRUB is placed into the MBR of a hobby OS partition installation, or even whole disk installation. If all hobby OSs use this method, whether or not they use a custom FS, it gives them the advantage of being able to load a full program, in ''protected mode'' via GRUB, and bypassing the Real Mode bootloader stage ''completely''. No more problems with writing an efficient program in 446 bytes. [[Category:Filesystems]] [[Category:Bootloaders]] [[Category:FAQ]]