Changes between Version 3 and Version 5 of Ticket #4028


Ignore:
Timestamp:
Jun 2, 2011, 5:40:01 PM (13 years ago)
Author:
meianoite
Comment:

Legend:

Unmodified
Added
Removed
Modified

  • Ticket #4028

    • Property Patch 0 → 1

  • Ticket #4028 – Description

    v3 v5  
    1 Attached is a 512 byte PMBR boot loader that looks for the UUID of a Haiku GPT partition and boots it, falling back to MBR partitions if said UUID isn't found or if the (primary) GPT is corrupted or non-existent.
     1Attached is a 432 bytes MBR IPL (Initial Program Loader) that looks for the UUID of a Haiku Boot GUID partition and boots it, falling back to MBR partitions if said UUID isn't found or if the (primary) GPT is corrupted or non-existent.
    22
    3 Its usefulness is in being a generalised IPL that supports both partitioning styles, allowing it to be used transparently and even allowing disks to be converted from one partitioning style to the other with ease, should the need for more partitions or volumes over 2TiB arise (for instance when cloning an older disk to a newer, more capacious one).
     3Its usefulness is in being a versatile, "universal" IPL that supports both partitioning styles, allowing it to be used transparently and even facilitating the conversion between partitioning styles, should the need for more partitions or volumes over 2TiB arise (for instance when cloning an older disk to a newer, more capacious one).
    44
    55It also paves the way for Haiku to create and support booting from multiple volumes larger than 2TiB, which we're in the very privileged position of enjoying efficiently in the near future due to BFS. Another use case is taking a disk from a Intel EFI machine, plugging it on a BIOS machine and boot just fine; and vice-versa.
    … …  
    77As mentioned, if there are valid partitions defined in the MBR, and the primary GPT becomes corrupt, it can fall back to loading the MBR partition with the active flag set, if one is defined.
    88
    9 Currently there's no provision for falling back to the GPT copy that lives in the end of the disk, due to the 512 bytes constraint; supporting this would require either some major refactoring of the code or disabling the support for booting from MBR using calls to int13h other than function 4200h, "LBA Read from Disk".
     9Currently there's no provision for falling back to the GPT copy that  lives in the end of the disk, due to the 512 bytes constraint; supporting  this is unlikely given that the code is packed tight. An alternative would be disabling support for booting from MBR using BIOS calls other than Int13h function 42h, "Extended Read From Disk" (i.e., LBA mode). It's unlikely that any machine that Haiku supports won't have this BIOS function, but having an "universal" IPL should be quite useful to, say, people using Haiku to rewrite a corrupt MBR on another disk using the excellent DiskProbe.
    1010
    11 It was tested on emulators and on my actual, proper computer. Loading Windows, Haiku and FreeBSD was tested (UUID must be changed accordingly, of course); for the GPT boot, the number of sectors to load from the partition is adjustable (needed by FreeBSD's "gptloader" on a freebsd-boot UUID partition), probably needed by Haiku as well since stage1 is 2 sectors big), but beware that int13h 4200h only supports up to 127 (0x7f) sectors, or a loader of almost 64KiB; so don't specify a larger number. This is not checked on the code, again because of space constraints.
     11The number of sectors loaded depends on the boot style. Booting from a MBR partition assumes that the Partition Boot Record is one sector long, whereas booting from a GPT partition assumes a partition exclusive for a system loader and will either copy its entirety into memory starting from address 0x7c00, or will copy up to circa 545KiB, whichever is smaller. Thus, it remains compatible with the FreeBSD gptloader and should work for loading Bootman from an exclusive Haiku boot manager partition as well.
     12
     13It should be easy to adjust the UUID signature as needed. It lives at offset 0x1a0 (416), leaving plenty of space before the 32-bit disk signature at offset 0x1b8 (440), so compatibility with Microsoft Windows and other OSs is maintained.