SPRUI30H November 2015 – May 2024 DRA745 , DRA746 , DRA750 , DRA756
This paragraph describes functions used by the ROM code to recognize whether an MBR with a FAT is used. It is not intended to fully describe the MBR and the FAT file system detection and reading procedure. The ROM code can detect FAT12/16/32 allocation table types. It cannot boot on devices with NTFS or Linux® FS partitions. Some memory devices that support file systems can be formatted with or without MBR; therefore, the first task of the ROM code is to detect whether the device is holding an MBR in the first sector.
The MBR is the first sector of a memory device. It consists of executable code, four partition entries, and one signature. The aim of such a structure is to divide the hard disk in partitions used primarily to boot different systems (for instance, Microsoft Windows®). Table 32-43 describes this structure, and Table 32-44 describes the partition table entry.
Offset | Length (Bytes) | Entry Description |
---|---|---|
0000h | 446 | Optional code |
01BEh | 16 | Partition table entry |
01CEh | 16 | Partition table entry |
01DEh | 16 | Partition table entry |
01EEh | 16 | Partition table entry |
01FEh | 2 | Signature (0xAA55) |
Offset | Length (Bytes) | Entry Description | Value |
---|---|---|---|
0000h | 1 | Partition state | 00h: Inactive |
80h: Active | |||
0001h | 1 | Partition start head | Hs |
0002h | 2 | Partition start cylinder and sector | Cs[7:0] – Cs[9:8] – Ss[5:0] |
0004h | 1 | Partition type | 01h: FAT12 |
04h, 06h, 0Eh: FAT16 | |||
0Bh, 0Ch, 0Fh: FAT32 | |||
0005h | 1 | Partition end head | He |
0006h | 2 | Partition end cylinder and sector | Ce[7:0]–Ce[9:8]–Se[5:0] |
0008h | 4 | First sector position relative to the beginning of media | LBAs = Cs.H.S + Hs.S + Ss – 1 |
000Ch | 4 | Number of sectors in partition | LBAe = Ce.H.S + He.S + Se – 1 Nb s = LBAe – LBAs + 1 |
SD/eMMC booting consists of the following steps:
The ROM code first checks whether the MBR signature is present, and then it searches an active FAT12/16/32 partition in all four MBR partition entries, based on the Type field. If the MBR entries are not valid, or if no usable partition is found, the ROM code returns to the booting procedure with FAIL. The extended partitions are not checked; the booting file must reside in a primary partition. Each partition entry is checked to determine the following:
See Figure 32-28 for more information about MBR detection.
Once identified, the ROM code gets the partition using the procedure described in Figure 32-28. The partition type is checked to be FAT12/16 or FAT32. Its state must be 00h (inactive) or 80h (active). The ROM code returns with FAIL if no active primary FAT12/16/32 is found, or the test fails if there is more than one active partition. If an active partition is found, its first sector is read and used later. If no MBR is present (in case of a floppy-like system), the first sector of the device is read and used later. The read sector is checked to be a valid FAT12/16 or FAT32 partition. If this fails, the ROM code returns with FAIL if another partition type is used (for instance, Linux FS) or if the partition is not valid.
The FAT file system consists of several parts:
To check whether a sector holds a valid FAT12/16/32 partition, many fields of the boot sector (used by all FAT types) that require specific values are checked. Figure 32-29 shows more about getting the partition.
When a partition is found, the root directory entries are searched for a booting file named MLO in the root directory of the FAT12/16/32 file system. The file is not searched in any other location. For a FAT12/16 file system, the root directory has a fixed location, which is cluster 0. For a FAT32 file system, its cluster location is given by BPB_RootClus. The formula to find the sector number (relative to device sector 0, not partition sector 0) of a cluster is given by the following equation:
BPB_FATSz is BPB_FATSz16 for FAT12/16, or BPB_FATSz32 for FAT32.
The BPB_HiddSec field can contain 0, even though the FAT file system is somewhere other than on sector 0 (floppy-like). The ROM code uses the partition offset taken from the MBR instead of this field, which can be wrong. If no MBR is found (floppy-like), the value 0 is used.
Each entry in the root directory is 32 bytes and holds information about the file (the filename, date of creation, rights, cluster location, and so forth). See Table 32-45.
Offset | Length (Bytes) | Name | Description |
---|---|---|---|
0000h | 11 | DIR_Name | Short Name (8 + 3) |
000Bh | 1 | DIR_Attr | File attributes: |
01h – ATTR_READ_ONLY | |||
02h – ATTR_HIDDEN | |||
04h – ATTR_SYSTEM | |||
08h – ATTR_VOLUME_ID | |||
10h – ATTR_DIRECTORY | |||
20h – ATTR_ARCHIVE | |||
0Fh – ATTR_LONG_NAME | |||
000Ch | 1 | DIR_NTRes | Reserved. Set to 00h. |
000Dh | 1 | DIR_CrtTimeTenth | Millisecond stamp at file creation |
000Eh | 2 | DIR_CrtTime | Time file was created. |
0010h | 2 | DIR_CrtDate | Date file was created. |
0012h | 2 | DIR_LstAccDate | Last access date |
0014h | 2 | DIR_FstClusHi | High word of the first cluster number of this entry |
0016h | 2 | DIR_WrtTime | Time of last write |
0018h | 2 | DIR_WrtDate | Date of last write |
001Ah | 2 | DIR_FstClusLo | Low word of the first cluster number of this entry |
001Ch | 4 | DIR_FileSize | File size in bytes |
The ROM code checks each entry in the root directory until either the booting file is found or the entry is empty (first byte is 00h), or when the end of the root directory is reached. Entries with the ATTR_LONG_NAME attribute (LFN) and first byte at E5h (erased file) are ignored. When found, the first cluster offset of the file is read from the DIR_FstClusHi/DIR_FstClusLo fields. There is a slight difference between FAT12/16 and FAT32 when handling the root directory. On FAT12/16, this directory has a fixed location (see Table 32-45) and length fixed by BPB_RootEntCnt, which is the total of 32-byte entries. Therefore, handling this directory is straightforward. On FAT32, the root directory is like a standard file. The FAT must be used to retrieve each sector of the directory. Step 4 describes the way in which the FAT is handled.
When the booting file is found, the ROM code reads the FAT and buffers the singly-linked chain of clusters in the FAT buffer that is used during boot to access the booting file directly, sector by sector. For FAT12/16 and for FAT32, multiple copies of the FAT exist (ROM code supports only two copies), after the boot sector.
The size of the FAT buffer is given by BPB_FATSz16 or BPB_FATSz32. The ROM code checks each copy of the FAT if the values are identical. If the values are different, the ROM code uses the value from the last FAT copy. With the FAT32 file system, the copy system can be disabled according to a flag in BPB_ExtFlags[7]. If this flag is set, the FAT BPB_ExtFlags[3:0] bit field is used. In this case, no verification is made by the ROM code with other copies of FAT.
The FAT is a simple array of values, each referring to a cluster in the data area. One entry of the array is 12, 16, or 32 bits, depending on the file system in use. The value in an entry defines whether the cluster is being used or not, and if another cluster must be considered. This creates a singly-linked chain of clusters defining the file. Table 32-46 describes the meaning of an entry.
For compatibility, cluster 0 and cluster 1 are not used for files, and these entries must contain:
FAT12 | FAT16 | FAT32 | Description |
---|---|---|---|
000h | 0000h | 00000000h | Free cluster |
001h | 0001h | 00000001h | Reserved cluster |
002h–FEFh | 0002h– | 00000002h– | Used cluster; value points to next cluster |
FFEFh | 0FFFFFEFh | ||
FF0h–FF6h | FFF0h– | 0FFFFFF0h– | Reserved values |
FFF6h | 0FFFFFF6h | ||
FF7h | FFF7h | 0FFFFFF7h | Bad cluster |
FF8h–FFFh | FFF8h– | 0FFFFFF8h– | Last cluster in file |
FFFFh | 0FFFFFFFh |
FAT32 uses only bits [27:0]; the upper 4 bits are usually 0 and must remain untouched.
When accessing the root directory for FAT32, the ROM code starts from the root directory cluster entry and follows the linked chain to retrieve the clusters.
When the booting file has been found, the ROM code buffers each FAT entry corresponding to the file in a sector way. This means each cluster is translated to one or several sectors, depending on how many sectors are in a cluster (BPB_SecPerClus). This buffer is used later by the booting procedure to access the file.