overall arrangement
We all know that UFS supports a maximum of 8 LUs, but we often do not use so many in actual use. Taking a certain company as an example, the partition overview is as follows:
The size and attributes of each partition are as follows:
/*lu_index, bootable, log2blksz, blkcnt, lu_context, memory_type*/
{0x00, MAIN_BOOT,0x0C, 1024, 0x0, ENHANCED_MEMORY_1},
{0x01, ALTERNATE_BOOT, 0x0C,1024, 0x0, ENHANCED_MEMORY_1},
{0x02, NONE_BOOT, 0x0C, 0 , 0xFF, NORMAL_MEMORY}
none_boot
The next partition is the same as emmc, and it must be the same because the codes must be compatible with each other.
In fact, the operations of writing the partition table and reading and writing partitions in the software are all based on the above structure. The specific data structure is as follows:
MBR: MBR supports disks up to 2TB, it cannot handle disks with a capacity larger than 2TB. MBR also only supports up to 4 primary partitions; if this part of the data is overwritten or corrupted, it is difficult to repair typedef struct _legacy_mbr { u8 boot_code[440]; __le32 unique_mbr_signature; __le16 unknown; struct partition partition_record[4]; __le16 signature;} __packed legacy_mbr;
GPT: Disk drives can be much larger than the operating system and file system can support. It also supports an almost unlimited number of partitions, limited only by the operating system; GPT saves a copy of this information on the entire disk
typedef struct _gpt_header { __le64 signature; __le32 revision; __le32 header_size; __le32 header_crc32; __le32 reserved1; __le64 my_lba; __le64 alternate_lba; __le64 first_usable_lba; __le64 last_usable_lba; efi_guid_t disk_guid; __le64 partition_entry_lba; __le32 num_partition_entries; __le32 sizeof_partition_entry; __le32 partition_entry_array_crc32;} __packed gpt_header;
Partition table entry structure:
typedef struct _gpt_entry {efi_guid_t partition_type_guid;
efi_guid_t unique_partition_guid;
__le64 starting_lba;
__le64 ending_lba;
gpt_entry_attributes attributes;
efi_char16_t partition_name[PARTNAME_SZ];
} __packed gpt_entry;
Often when we operate a partition, we first need to know which hardware partition the current partition is: (main_boot, alternate_boot, none_boot). Generally, the first two are used to burn uboot or spl or boot image. , which is a read-only partition for users. For users, for example, when we operate the userdata partition, we first find the hardware partition as none_boot, then read the response header to obtain the partition table entry, and then the for loop queries the gpt_entry whose partition name partition_name is userdata. Correspondingly, we know the partition In fact, the block address starting_lba and the ending block address ending_lba, then we can operate the specified partition. For details on how to locate which file to operate, please refer to my other blog: ext4 file system file positioning process .
At this point, we have a general understanding of the software partition management of ufs. However, how the driver initializes and obtains the information of each hardware partition, I will continue to introduce to you in the following blog.