MBR (x86)

A Master Boot Record (MBR) is the bootsector of a hard disk. That is, it is what the BIOS loads and runs, when it boots a hard disk. The MBR is the very first sector of the hard disk; it contains an MBR Bootstrap program (described below), and a Partition Table. Devices that emulate a hard disk during system initialization must also contain an MBR, because they must also have Partition Tables -- even if they are not bootable.

The BIOS will only boot an MBR from a device if that device is in the "boot sequence" stored in CMOS, and if the MBR on the device is formatted correctly. On the other hand, if a device is not in the boot sequence (but has a "drive number"), it is still possible for a Real Mode program (such as another MBR or bootloader) to load and boot that device's MBR directly.

MBR Bootstrap

An MBR is loaded by the BIOS at physical address 0x7c00, with DL set to the "drive number" that the MBR was loaded from. The BIOS then jumps to the very beginning of the loaded MBR (0x7c00), because that part of the MBR contains the "bootstrap" executable code.

Typical MBR bootstrap code will do the following:

• relocate itself away from the 0x7c00 physical address (using a memory copy, and usually a far jump)
• determine which partition (or hard disk) to boot from (either by looking for the active partition, or by presenting the user with a selection of installed operating systems to choose from)
  • if the user selected an "inactive" partition, then set the selected partition entry to "active", and clear the "active" bits of other partition entries
  • use BIOS INT 13h commands to rewrite the MBR if the partition table entries were modified
• use BIOS INT 13h commands to load the Volume Boot Record (VBR, the "bootsector" of the bootloader) from the beginning of the selected partition to physical address 0x7c00
• set DS:SI pointing to the selected partition table entry
• jump to 0x7c00 (with CS set to 0, and DL set to the "drive number")

Note: it is intended for the value of DL, and the DS:SI pointer to be passed all the way into the kernel, for the kernel's use. This also means that the relocated MBR should not be overwritten during the boot process -- because the DS:SI pointer is aimed at a partition table entry inside that MBR, and needs to remain valid.

MBR Format

Notes:

• See the Partition Table article for the format of each partition table entry field.
• It is important to remember that the partition table entries are not aligned on 32-bit boundaries.
• Naming the partition table entries as "First" through "Fourth" is for convenience only. The partition table entries are not required to be in any kind of order.
• Any one of the partitions may be "active".
• There is supposed to be one active partition table entry, at most.
• Windows seems to verify and require that the partition it boots from be marked "active".
• Most other operating systems don't seem to care about the "active" bit in the partition table entry.

Offset	Size (bytes)	Description
0	436 (to 446, if you need a little extra)	MBR Bootstrap (flat binary executable code)
0x1b4	10	Optional "unique" disk ID1
0x1be	64	MBR Partition Table, with 4 entries (below)
0x1be	16	First partition table entry
0x1ce	16	Second partition table entry
0x1de	16	Third partition table entry
0x1ee	16	Fourth partition table entry
0x1fe	2	(0x55, 0xAA) "Valid bootsector" signature bytes

¹ The 10 byte "unique disk ID" field was never standardized. It can contain anything -- even the tail end of the bootstrap code. If there are a few empty bytes left in it, it is nice for the disk partitioning software (that writes this MBR sector in the first place) to try to put unique values into those empty bytes. "Unique" in this case means that the IDs of all the drives attached to a particular system are distinct.

Traditional MBR

The DOS FDISK program was the first to ever use an MBR, so that MBR became the de-facto standard. It also automatically became the standard for the minimum level of functionality of an MBR. It was never changed after it was first introduced.

The whole point of the FDISK program is to manipulate the MBRs of the hard disks attached to a system. When FDISK partitions a blank disk, it writes an MBR to sector 0 of the drive. When FDISK adds a new partition to a disk, it adds an entry into the Partition Table in the MBR. When FDISK makes a partition "active", it sets the "flag" byte in the Partition Table entry to 0x80.

The MBR that FDISK uses is coded to:

• relocate itself to 0x0000:0x0600
• examine the byte at offset 0x1be, 0x1ce, 0x1de, and 0x1ee to determine the active partition
• load only the first sector of the active partition (which is expected to contain a DOS bootsector) to 0x0000:0x7c00 (hence the previous relocation)
• set SI
• jump to 0x7c00 -- transferring control to the DOS bootsector.

It is extremely unfortunate and stupid that this MBR loads only one sector of the booted partition. There is no additional complication to load more than one sector in the code; but doing so makes writing bootloaders much simpler if, perhaps, 8 sectors are loaded instead. So it may be wise to always replace this old MBR with a custom MBR that loads more than one sector, for your OS. DOS/Windows will still boot correctly if more than one sector is loaded.

Dual Booting

A typical system may have several hard disks on it, and each hard disk can have 4 standard partitions (without going into the extra complication of Extended Partitions). Each of those partitions could theoretically hold its own distinct bootable OS, and filesystem.

However, the standard x86 boot sequence will only ever boot the MBR from the "C:" disk (the first disk found during the disk detection phase). And the standard MBR will only allow a single active partition on that disk, and will only ever boot that one partition. This is really completely inadequate.

It is not possible to modify the BIOS/CMOS boot sequence -- but you can change the MBR. So, one solution is to replace the standard MBR with a "custom, Dual Booting" MBR. (For a good example, see John Fine's SMBMBR in the External Links, below.)

A simple dual booting MBR will allow the user to select any partition on the current drive, to boot. A more complicated dual booting MBR will also allow the user to select other hard disks, or even to specifically choose other partitions on other hard disks, to boot.

For one MBR to load and run a different MBR off a different drive is called "chain loading". If all the MBRs are dual booting, then the user can cycle through all the disks, and choose to boot the "correct" partition from the "correct" drive.

A dual booting MBR is a huge improvement over the standard MBR. The only problem is that an MBR bootstrap is limited to a little over 400 bytes of code. Such a tiny program is insufficient to create a "nice" user-friendly dual booting system that has commercial appeal. It is enough space to hack up an interface that is good enough for the person who wrote it.

One way around this size limitation is to note that a bootloader can contain a lot more code than an MBR. So a custom MBR can try to load a "preferred" bootloader (if it can find one on some partition, somewhere) -- and that preferred bootloader can have a very pretty, user-friendly interface that allows the user to select any partition off any drive, to boot.

It is also nice, if there is only one partition on only one drive (ie. there is no choice for a user to make), if the MBR will boot that one partition automatically -- without bothering the user with prompts.

Generic MBRs

As said above, the MBR that is written to the disk by the DOS FDISK program is "the most generic" one. But every disk partitioning app must write some sort of MBR to the disk, and every generic bootloader may well need a custom MBR.

Fortunately, there was a standard for them to conform to (the FDISK MBR), and they all did conform to it. Some of them may be Dual Booting, or have other features -- but they will all end up loading your bootloader at the standard address (0x7c00), with the DL register set to the boot "drive number", and DS:SI pointing at the correct partition table entry of the correct MBR.

Building a Custom MBR Bootstrap program

When the BIOS transfers control to the MBR bootstrap code, the system is in Real mode. The MBR will probably also run entirely in Real mode, so it is important to understand Real mode addressing.

Self-relocation is one of the things C can't do, and most modern C compilers can't create code that is compatible with Real mode, anyway. So an MBR must be written in Assembly.

It is necessary to build an MBR that is exactly 512 bytes long. How this is done depends on your assembler and linker. The last 2 bytes must be the special boot pattern (0x55 followed by 0xAA), and as said above, the bootstrap portion of the MBR must be less than 447 bytes long. You must also copy at least one partition table entry into the Partition Table portion of the MBR.

Initial Environment

When the BIOS loads and runs an MBR, it is loaded into memory at physical address 0x7c00. This is usually 0x0000:0x7c00 (CS = 0, offset address 0x7c00). However, some BIOSes load to 0x7c0:0x0000 (CS = 0x07c0, offset address 0) -- which resolves to the same physical address, but can cause problems. A good practice is to enforce CS:IP with a far jump near the beginning of your bootstrap code. The MBR will probably need to immediately relocate itself anyway, and that is a good time to enforce CS:IP.

The BIOS passes very little useful information directly to the MBR. In fact, the only important number is the value in DL -- the "drive number". It needs to be passed to all later calls to BIOS function INT 13h, so that byte in DL probably needs to be saved carefully.

The values in all the other registers, and in most of memory, are undefined.

Immediate Priorities

It is important to immediately set up a stack, and also to set the rest of the CPU's segment registers (DS, ES, FS, GS) properly. Setting up a stack involves pointing the SS:SP pair of registers at some memory that is not being used for anything else (and the address must be even). The other segment registers should usually be set to 0.

See the Memory Map (x86) article to understand what memory is available during boot (low memory from 0x500 to 0x7ffff, generally).

In general, you do not want to fragment your available memory, or the memory of each 64K "page", if possible. The MBR needs a stack, and a place to relocate itself to. The MBR will be loading a bootloader at 0x7c00, so it is reasonably convenient for the MBR to relocate itself either to somewhere around the 0x500 to 0x600 address range, or to 0x7a00 (ie. just below 0x7c00). The stack can then point to 0x7c00 (if the MBR is not at 0x7a00), or the stack can be just below the relocated MBR.

Storing an MBR to the disk

To write an MBR to the first sector of a disk, you must use special disk I/O tools, because the MBR (by definition) is not inside any disk partition. The MBR only exists on the "raw device". There are quite a few "disk editing" tools available; some are listed in Disk Image Utilities.

See Also

Articles

• System Initialization (x86)

External Links

• Fine's MBR code on osdever
• OSRC -- for more boot sector info
• Ranish Partition Manager -- Disk partitioning software