Hi,
pragmatic wrote:
Is any of this early memory "off-limits", so to speak? I know regions roughly above 000a:0000 are not safe to use, but what can be said of the lower regions?
For BIOS boot loaders; typically you begin with an assumption like "RAM from 0x00001000 to 0x00080000 is always safe to use, and the CPU might be an ancient 8086", then check if the CPU is ancient (and display a "your CPU is too old" message and refuse to boot if it's a crusty old 8086 or something) before attempting to get a memory map from the BIOS (which should start with trying "int 0x15, eax = 0xE820", which uses 32-bit registers and is the reason why you make sure the CPU is at least 80386 before trying). You'd also make sure the A20 gate is enabled before using memory that needs it enabled.
Of course where and when these things happen is up to you - you can do as much as possible or as little as possible while still using the "RAM from 0x00001000 to 0x00080000 is always safe to use, and the CPU might be an ancient 8086" assumption.
pragmatic wrote:
Brendan wrote:
That depends on the OS and how it's designed. A more important question is, for your OS, how do you want the VBR to find the next stage?
For my OS, I have a reserved area at the start of the partition containing various things (e.g. the boot loader, the second stage, a "boot image" that contains lots of files) plus a few fields in the 1st sector of the partition that says where these other things are. Utilities that create/update files used during boot (in the reserved area) also update the fields in the 1st sector; and the file system (if there is one) doesn't touch anything in the reserved area.
This is true, of course. However, I do not plan to roll my own filesystem for now. That said, I need to play nicely with other filesytems and partitioning schemes.
I don't want to design my own file system yet either (I want to eventually, but not yet). That's the nice thing about "boot code uses reserved area at start of the partition" - you can design the file system much much later. For "boot code uses files from the file systems" you have to design the file system before you can finish writing the boot code.
Your boot code doesn't need to play nicely with other file systems. More specifically; you can put partitions into 3 categories:
- Native partitions that belong your OS, where your boot code must support at least one of them
- Partitions that belong to other OSs that you have no reason to care about or touch
- Partitions that exist for sharing data between different operating systems (e.g. a FAT partition data that can be used by all operating systems that happen to be installed) that no OS boots from and no boot loader needs to support
You do need to play nicely with the partitioning scheme; but on 80x86 there's mostly only 2 partitioning schemes ("MBR partitions" and GPT) and as long as your boot code knows where your partition begins and ends it doesn't need to care which partitioning scheme is being used.
Note: The BSD group of operating systems tend to use "slices", but on 80x86 systems these are implemented on top of other partitioning schemes (e.g. so that you end up with a partition that is split into pieces/slices and don't have a whole disk that is split into slices).pragmatic wrote:
Obviously I will have an MBR at the beginning, and the MBR table will point somewhere in disk allowing me to find the VBR for the active partition. My confusion is with respect to how all of this works together in an orderly way, or at least what the "norms" are. I ask because one could use install GRUB (via a package containing the grub-install command) into an already-existing partitioning scheme and filesystem. In this case GRUB could just overwrite the MBR and VBR (since on an MBR system these would already be in place), but I wonder how it finds and loads its final stage? It is open source .. so perhaps I can find answers there.
GRUB can (and very likely will) overwrite the MBR, but shouldn't overwrite your VBR (unless the user is deliberately removing your OS); and GRUB does support chainloading and can be used to start your VBR the same as any other MBR or boot manager would (e.g. loading your VBR at 0x0007C000 and jumping to it). That's part of what I was saying earlier - the MBR isn't part of the OS.
More generally; the entire first track of the disk and/or the area at the start of the disk before the beginning of the first partition belongs to a "third party whatever the user feels like boot manager" and no OS should touch it ever; the end user can install many different OSs, and after installing many OSs the end user can change their "boot manager" at any time.
Of course (for convenience and no other reason) it's normal for an OS installer to ask the user if they want a (supplied alongside the OS) "minimal MBR with no features" to be installed, because a lot of people only install one OS and for that case it prevents the end user from finding/installing their own MBR or boot manager.
Unfortunately, everything I've said here uses the word "should" because sometimes different OSs don't do what they should. For example, one well known family of operating systems is created by a-holes (Microsoft) and their OS installer/s will overwrite the MBR without asking (not because it's hard to do the right thing, but because they want to care about competing operating systems).
pragmatic wrote:
Brendan wrote:
How you format a partition is up to you - the only restriction is that if you want a VBR then the VBR has to be in the 1st sector of the partition. However; if you decide you want to use an existing file system (rather than using none, or designing your own file system) then you also have to follow the rules of that file system.
Indeed. My first thought was similar to what you describe above: some reservation of memory at the beginning of the partition for these various things. Of course, these various loaders would have knowledge of each other and know how to where to find the next stage and how to load them. However, none of that applies when working with existing filesystems.
That depends - it can apply when working with some file systems (e.g. FAT, which does support "arbitrary number of reserved sectors at start of partition") but can't apply when working with some other file systems.
pragmatic wrote:
There are obviously countless ways to implement this, but there must also be some agreed upon methodology. Otherwise various bootloaders could not be drop-in replacements for each other, right? If there is no "standard" way then it would seem that each partitioning scheme be necessarily bootloader-specific, yet we know this to not be true (i.e. enabling dual boot after installing Windows).
Traditionally; a boot loader is custom designed specifically for one specific OS (and may also be designed for the type of firmware and/or type of boot device - e.g. one boot loader to boot from CD-ROM, another to boot from network, etc); and each OS has it's own "boot protocol" and/or standard/s that describes exactly what the OS expects from boot loaders designed for that specific OS; and there is no standard boot loader for all OSs; and the only standard shared by all OSs are standards that describe the environment that the boot loader begins with (e.g. BIOS, El Torito, PXE, UEFI, OpenFirmware, ...).
The only exception to this (that I know of) is multi-boot; which mostly only exists because GRUB developers wanted to break traditions and ruin everything. They succeeded in ruining a lot, but mostly failed to get multi-boot adopted and ended up implementing multiple different boot protocols/standards for multiple different OSs.
pragmatic wrote:
Are filesystems drivers "MBR-aware"? If the MBR points to a partition, drivers must know to first skip the VBR to get to the filesystem data structures.
There's no reason for file system code to be "MBR-aware". File system code should rely on a lower level "volume" abstraction; where the underlying volume might be a partition, or a whole disk, or many disks combined with RAID, or a file, or an area of RAM, or anything else.
If the file system is designed to support VBR (e.g. and has a "reserved for boot code" area that's at least 512 bytes at the start of the volume) then the file system code has to comply with the design/specification of the file system; and if the file system is not designed to support VBR (and doesn't have any "reserved for boot code" space at the start of the volume) then the file system code has to comply with the design/specification of the file system.
Cheers,
Brendan