Drives without an MBR Sector
Some storage devices don’t have an MBR sector. Media that requires only a single volume might not want to waste 512 bytes on an MBR sector. Media without an MBR sector begins with the volume’s boot sector.
For maximum compatibility with hosts, however, a device should include the MBR sector. A host can find it challenging to determine whether a device’s media contains an MBR. One approach is to read the locations that would contain a partition table and attempt to determine if the contents describe a valid partition. The first bytes in the media can also offer a clue. In bootable FAT16 media without an MBR, the first three bytes are typically EBh 3Ch 90h. In bootable FAT32 media without an MBR, the first three bytes are typically EBh 58h 90h. A MultiMediaCard or SD Card straight from the package is formatted with an MBR sector.
The FAT file systems were developed for use on the x86 architecture in IBM PCs and their derivatives. The architecture of x86 CPUs is little endian, which means that multi-byte values are stored with the least significant byte at the lowest address. For example, in the MBR sector, addresses 510 and 511 must contain the signature AA55h. Because the storage is little endian, location 510 contains 55h (the least significant byte) and location 511 contains AAh (the most significant byte).
The Master Boot Record Sector
Sector zero, the Master Boot Record (MBR) sector, contains three items: an area for executable code, a partition table, and a boot signature (Figure 7-2).
Figure 7-2: The MBR sector contains a partition table that specifies the location(s) of one or more primary partitions.
Bytes zero through 445 can contain executable code. When a PC boots, the system BIOS jumps to the executable code in the MBR sector of a storage device. The code searches the partition table for an active, or bootable, partition, and on finding one, boots the computer by running code stored in that partition’s first sector. Like any low-level program code, the code stored in the MBR is specific to a CPU family. Executable code for a PC is useless if the system’s CPU is a microcontroller with a different instruction set.
Embedded systems typically boot from a specific location in dedicated program memory rather than from storage media such as a flash-memory card or hard drive. An embedded-system host can ignore any executable code in the MBR sector. Because the partition table is in the same location in the MBR sector in all devices, firmware can read the information directly from the table.
The Partition Table
The partition table enables defining one or more partitions, or logical volumes, in the storage media. Many devices have just one volume. The partition table in the MBR sector has room for four 16-byte entries that each specify the sectors that belong to a partition. The table is in bytes 446 through 509. An entry can begin at byte 446, 462, 478, or 494. Table 7-1 shows the contents of an entry.
Each partition entry has fields that define the partition’s starting location when addressing via the CHS and LBA methods. The LBA field at byte 8 specifies the starting sector of the partition expressed as an offset from the beginning of the media (the MBR sector). The CHS values are ignored when using LBA. If a partition is bootable, executable code in the MBR may use CHS addresses to locate boot code in the partition.
The partition-type field at byte 4 specifies a file system and also indicates something about the partition’s size (Table 7-2). Over the years, Microsoft’s operating systems have expanded their support for file systems and for partition sizes and addressing methods within the file systems. For example, partition type 04h was added in MS-DOS 3.0 for FAT16 partitions of less than 32 MB. MS-DOS 4.0 added partition type 06h for FAT16 partitions between 32 MB and 2 GB. Partition types 0Ch and 0Eh must support LBA to enable PCs to use BIOS interrupt 13h to access the media. If the partition type is 00h, the entry is unused and the partition doesn’t exist.
The final item in a partition-table entry, byte 12, is the total number of sectors in the partition. Most program code ignores this value and instead uses an equivalent value stored by the file system.
Devices with multiple partitions can use extended partitioning, where one of the partition-table entries is for an additional, extended, partition whose first sector contains an extended boot record (EBR) structure with its own partition table (Figure 7-3).
The partition table in the MBR contains information about the media’s primary partition(s). The partition table in an extended partition’s EBR can store at most one entry for a secondary partition and one entry for an additional extended partition. The additional extended partition, if present, contains its own EBR and partition table. The EBR sectors in extended partitions contain a partition table and signature but not executable code.
Any device with more than four partitions must use extended partitioning. Large-capacity FAT16 devices use extended partitioning when the available media is larger than the maximum allowed size for a FAT16 partition. (Many implementations limit FAT16 partitions to 2 GB. Another solution for large-capacity media is to use FAT32.) MS-DOS allows only one primary partition but supports extended partitions. Possibly because of this limitation, some formatting routines use extended partitioning for a second or third partition even though one partition table could hold all of the infor-mation. There is no defined limit to the number of extended partitions a device can contain.
Figure 7-3: With extended partitions, a device can have more than four partitions.
Table 7-1: A partition table entry contains information that enables the master computer to access locations in the storage media.
The Boot Signature
The boot signature is the final item in the MBR sector. Byte 510 (1FEh) must equal 55h and byte 511 (1FFh) must equal AAh.
Table 7-2: The partition-type item in the partition table indicates the file system the partition uses.