Boot Sector
On non-partitioned devices, e.g., floppy disks, the Boot Sector (VBR) is the first sector (logical sector 0 with physical CHS address 0/0/1 or LBA address 0)). For partitioned devices such as hard drives, the first sector is the Master Boot Record defining partitions, while the first sector of partitions formatted with a FAT file system is again the Boot Sector.
Common structure of the first 11 bytes used by most FAT versions for IBM compatible x86-machines since DOS 2.0 are:
| Byte Offset | Length (bytes) | Description |
|---|---|---|
| 0x000 | 3 | Jump instruction. If the boot sector has a valid signature residing in the last two bytes of the boot sector (tested by most boot loaders residing in the System BIOS or the MBR) and this volume is booted from, the prior boot loader will pass execution to this entry point with certain register values, and the jump instruction will then skip past the rest of the (non-executable) header. See Volume Boot Record.
Since DOS 2.0, valid x86-bootable disks must start with either a short jump followed by a NOP (opstring sequence 0xEB 0x?? 0x90 as seen since DOS 3.0—and on DOS 1.1) or a near jump (0xE9 0x?? 0x?? as seen on DOS 2.x formatted disks). For backward compatibility MS-DOS, PC DOS and DR-DOS also accept a jump (0x69 0x?? 0x??) on removable disks. On hard disks, DR DOS additionally accepts the swapped JMPS sequence starting with a NOP (0x90 0xEB 0x??), whereas MS-DOS/PC DOS do not. (See below for Atari ST compatibility.) The presence of one of these opstring patterns (in combination with a test for a valid media descriptor value at offset 0x015) serves as indicator to DOS 3.3 and higher that some kind of BPB is present (although the exact size should not be determined from the jump target since some boot sectors contain private boot loader data following the BPB), while for DOS 1.x (and some DOS 3.0) volumes, they will have to fall back to the DOS 1.x method to detect the format via the media byte in the FAT (in logical sector 1). |
| 0x003 | 8 | OEM Name (padded with spaces 0x20). This value determines in which system the disk was formatted.
Although officially documented as free for OEM use, MS-DOS/PC DOS (since 3.1), Windows 95/98/SE/ME and OS/2 check this field to determine which other parts of the boot record can be relied upon and how to interpret them. Therefore, setting the OEM label to arbitrary or bogus values may cause MS-DOS, PC DOS and OS/2 to not recognize the volume properly and cause data corruption on writes. Common examples are " Some vendors store licensing info or access keys in this entry. The Volume Tracker in Windows 95/98/SE/ME will overwrite the OEM label with " Some boot loaders make adjustments or refuse to pass control to a boot sector depending on certain values detected here (see f.e. NEWLDR offset 0x018). |
| 0x00B | varies | BIOS Parameter Block (13, 19, 21 or 25 bytes), Extended BIOS Parameter Block (32 or 51 bytes) or FAT32 Extended BIOS Parameter Block (79 bytes); size and contents varies between operating systems and versions, see below |
| varies | varies | File system and operating system specific boot code; often starts immediately behind BPB, but sometimes additional "private" boot loader data is stored between the end of the BPB and the start of the boot code. |
| 0x1FD | 1 | Physical drive number (only in DOS 3.2 to 3.31 boot sectors). With OS/2 1.0 and DOS 4.0, this entry moved to sector offset 0x024 (at offset 0x19 in the EBPB). Most Microsoft and IBM boot sectors maintain values of 0x00 at offset 0x1FC and 0x1FD ever since, although they are not part of the signature at 0x1FE.
If this belongs to a boot volume, the DR-DOS 7.07 enhanced MBR can be configured (see NEWLDR offset 0x014) to dynamically update this entry to the DL value provided at boot time or the value stored in the partition table. This enables booting off alternative drives, even when the VBR code ignores the DL value. |
| 0x1FE | 2 | Boot sector signature (0x55 0xAA). This signature indicates an IBM PC compatible boot code and is tested by most boot loaders residing in the System BIOS or the MBR before passing execution to the boot sector's boot code (but f.e. not by the original IBM PC ROM-BIOS). This signature does not indicate a particular file system or operating system. Since this signature is not present on all FAT-formatted disks (f.e. not on DOS 1.x or non-x86-bootable FAT volumes), operating systems must not rely on this signature to be present when logging in volumes (old issues of MS-DOS/PC DOS prior to 3.3 checked this signature, but newer issues as well as DR-DOS do not). Formatting tools must not write this signature if the written boot sector does not contain at least an x86-compatible dummy boot loader stub; at minimum, it must halt the CPU in an endless loop (0xF4 0xEB 0xFD) or issue an INT 19h and RETF (0xCD 0x19 0xCB). These opstrings should not be used at sector offset 0x000, however, because DOS tests for other opcodes as signatures. Many MSX-DOS 2 floppies use 0xEB 0xFE 0x90 at sector offset 0x000 to catch the CPU in a tight loop while maintaining an opcode pattern recognized by MS-DOS/PC DOS.
This signature must be located at fixed sector offset 0x1FE for sector sizes 512 or higher. If the physical sector size is larger, it may be repeated at the end of the physical sector. Atari STs will assume a disk to be Atari 68000 bootable if the checksum over the 256 big-endian words of the boot sector equals 0x1234. If the boot loader code is IBM compatible, it is important to ensure that the checksum over the boot sector does not match this checksum by accident. If this would happen to be the case, changing an unused bit (f.e. before or after the boot code area) can be used to ensure this condition is not met. In rare cases, a reversed signature 0xAA 0x55 has been observed on disk images. This can be the result of a faulty implementation in the formating tool based on faulty documentation, but it may also indicate a swapped byte order of the disk image, which might have occurred in transfer between platforms using a different endianness. BPB values and FAT12, FAT16 and FAT32 file systems are meant to use little-endian representation only and there are no known implementations of variants using big-endian values instead. |
FAT-formatted Atari ST floppies have a very similar boot sector layout:
| Byte Offset | Length (bytes) | Description |
|---|---|---|
| 0x000 | 2 | Jump instruction. Original Atari ST boot sectors start with a 68000 BRA.S instruction (0x60 0x??). For compatibility with PC operating systems, Atari ST formatted disks since TOS 1.4 start with 0xE9 0x?? instead. |
| 0x002 | 6 | OEM Name (padded with spaces 0x20), e.g., "Loader" (0x4C 0x6F 0x61 0x64 0x65 0x72) on volumes containing an Atari ST boot loader. See OEM Name precautions for PC formatted disks above. Note the different offset and length of this entry compared to the entry on PC formatted disks. |
| 0x008 | 3 | Disk serial number (default: 0x00 0x00 0x00), used by Atari ST to detect a disk change. (Windows 9x Volume Tracker will always store "IHC" here on non-write-protected floppy disks; see above.) This value must be changed if the disk contents is externally changed, otherwise Atari STs may not recognize the change on re-insertion. This entry overlaps the OEM Name field on PC formatted disks. For maximum compatibility, it may be necessary to match certain patterns here; see above. |
| 0x00B | 19 | DOS 3.0 BIOS Parameter Block (little-endian format) |
| 0x01E | varies | Private boot sector data (mixed big-endian and little-endian format) |
| varies | varies | File system and operating system specific Atari ST boot code. No assumptions must be made in regard to the load position of the code, which must be relocatable. If loading an operating system fails, the code can return to the Atari ST BIOS with a 68000 RTS (opcode 0x4E75 with big-endian byte sequence 0x4E 0x75) instruction and all registers unaltered. |
| 0x1FE | 2 | Checksum. The 16-bit checksum over the 256 big-endian words of the 512 bytes boot sector including this word must match the magic value 0x1234 in order to indicate an Atari ST 68000 executable boot sector code. This checksum entry can be used to align the checksum accordingly.
If the logical sector size is larger than 512 bytes, the remainder is not included in the checksum and is typically zero-filled. Since some PC operating systems erroneously do not accept FAT formatted floppies if the 0x55 0xAA signature is not present here, it is advisable to place the 0x55 0xAA in this place (and add an IBM compatible boot loader or stub) and use an unused word in the private data or the boot code area or the serial number in order to ensure that the checksum 0x1234 is not matched (unless the shared fat code overlay would be both IBM PC and Atari ST executable at the same time). |
FAT12-formatted MSX-DOS volumes have a very similar boot sector layout:
| Byte Offset | Length (bytes) | Description |
|---|---|---|
| 0x000 | 3 | Dummy jump instruction (f.e. 0xEB 0xFE 0x90). |
| 0x003 | 8 | OEM Name (padded with spaces 0x20). |
| 0x00B | 19 | DOS 3.0 BPB |
| 0x01E | varies (2) | MSX-DOS 1 code entry point for Z80 processors into MSX boot code. This is where MSX-DOS 1 machines jump to when passing control to the boot sector. This location overlaps with BPB formats since DOS 3.2 or the x86 compatible boot sector code of IBM PC compatible boot sectors and will led to a crash on the MSX machine unless special precautions have been taken such as catching the CPU in a tight loop here (opstring 0x18 0xFE for JR 0x01E). |
| 0x020 | 6 | MSX-DOS 2 volume signature "VOL_ID". |
| 0x026 | 1 | MSX-DOS 2 undelete flag (default: 0x00. If the "VOL_ID" signature is present at sector offset 0x020, this flag indicates, if the volume holds deleted files which can be undeleted (see offset 0x0C in directory entries). |
| 0x027 | 4 | MSX-DOS 2 disk serial number (default: 0x00000000). If the "VOL_ID" signature is present at sector offset 0x020, MSX-DOS 2 stores a volume serial number here for media change detection. |
| 0x02B | 5 | reserved |
| 0x030 | varies (2) | MSX-DOS 2 code entry point for Z80 processors into MSX boot code. This is where MSX-DOS 2 machines jump to when passing control to the boot sector. This location overlaps with EBPB formats since DOS 4.0 / OS/2 1.2 or the x86 compatible boot sector code of IBM PC compatible boot sectors and will led to a crash on the MSX machine unless special precautions have been taken such as catching the CPU in a tight loop here (opstring 0x18 0xFE for JR 0x030). |
| 0x1FE | 2 | Signature |
Read more about this topic: File Allocation Table, Technical Design
Famous quotes containing the word boot:
“... until the shopkeeper plants his boot in our eyes,
and unties our bone and is finished with the case,
and turns to the next customer, forgetting our face
or how we knelt at the yellow bulb with sighs
like moth wings for a short while in a small place.”
—Anne Sexton (1928–1974)