Exploring Partitions of All Boot Devices
- Wells Lu
This document provides a comprehensive overview of the partitions of all boot devices on SP7350 platform. The SP7350 platform supports 5 boot devices, including SPI-NOR flash, SPI-NAND flash, 8-bit NAND flash, eMMC device, and SD card.
Table of Contents
SPI-NOR Flash
The SP7350 platform supports two kinds of root file-system for SPI-NOR flash. One is initramfs (initial ram file-system) file-system and the other is jffs2 (journalling flash file system version 2) file-system.
initramfs File-system
The initramfs file-system is a RAM-based file system seamlessly integrated into the kernel image. Despite modifications to the root file-system during Linux operations, the kernel image stored in the SPI-NOR flash remains unaffected. This compressed file-system boasts high capacity, providing efficiency in storage utilization for the same root file-system size in flash.
Partitions for initramfs File-system
The SPI-NOR flash is divided into 5 partitions when utilizing the initramfs file system, as illustrated in the partition diagram of the SPI-NOR flash below:
Please refer to the table below for an explanation of each partition:
Partition | Size (kB) | Descriptions |
|---|---|---|
iboot | 96 | image of i-boot for external boot |
xboot | 192 | image of x-boot, including training firmware of DDR |
dtb | 128 | image of device-tree blob (not used) |
uboot | 768 | image of U-Boot |
fip | 864 | image of fip, including TF-A and OP-TEE |
uImage | Actual size of image | image of Linux kernel with built-in initramfs file-system |
Jffs2 File-system
In contrast, the jffs2 file-system resides in a dedicated partition within the SPI-NOR flash. Any alterations made to the root file-system are committed to the SPI-NOR flash. It's important to note that the performance of the jffs2 file-system may be sub-optimal due to the necessity to read and modify the flash.
Partitions for jffs2 File-system
The SPI-NOR flash is divided into 6 partitions with the jffs2 file system, as illustrated in the partition diagram of the SPI-NOR flash below:
Please refer to the table below for an explanation of each partition:
Partition | Size (kB) | Descriptions |
|---|---|---|
iboot | 96 | image of i-boot for external boot |
xboot | 192 | image of x-boot, including training firmware of DDR |
dtb | 128 | image of device-tree blob (not used) |
uboot | 768 | image of U-Boot |
fip | 864 | image of fip, including TF-A and OP-TEE |
kernel | Actual size of image | image of Linux kernel with U-Boot header |
rootfs | Depend on size of flash | image of jfffs2 root file-system |
If a 32MB or 64MB SPI-NOR flash is utilized, the size of the rootfs partition will automatically extend to the end of the SPI-NOR flash. However, the sizes of other partitions will remain unchanged.
Note
For those seeking to adjust partitions, it is crucial to update the definition of the environment variable 'mtdparts' in U-Boot. This adjustment can be made in the header file located at:
boot/uboot/include/configs/pentagram_common_sp7350.h
The existing mtdparts is as follows:
mtdparts=f8000b00.spinor:96k@0(iboot)ro,192k(xboot)ro,128k(dtb)ro,768k(uboot)ro,864k(fip)ro,0x${sz_kernel}(kernel),-(rootfs);SPI-NAND & 8-bit NAND Flash
The SP7350 supports the ubifs (unsorted block image file-system) as the root file-system for both SPI-NAND and 8-bit NAND Flash. Two types of ECC sectors are utilized: the standard 2k sector and the 1K60 sector.
Standard 2k Sector
The standard 2k sector consists of 2048 bytes of user data and 28 bytes of parity. As depicted in the figure below, each 512 bytes of user data is accompanied by 7 bytes (56 bits) of parity, capable of correcting up to 4 errors. Notably, a standard 2k sector occupies 2122 bytes of space. Partitions including env, env_redund, dtb, kernel, and rootfs use the standard 2k sector.
1K60 Sector
The 1K60 sector comprises 1024 bytes of user data and 105 bytes of parity. It is stored within the standard 2k sector and can correct 60 bits for 1024 bytes of user data, thereby enhancing error correction capabilities. Partitions such as nand_header, xboot1, uboot1, uboot2, and fip utilize the 1K60 sector. As depicted in the figure below, 1024 bytes of raw data and 105 bytes of parity are collectively stored within a standard 2k sector.
Partitions
The NAND flash is divided into 10 partitions, as illustrated in the figure below:
Please refer to the table below for an explanation of each partition:
Partition | Size | Descriptions |
|---|---|---|
nand_header | 1 block | header of the NAND flash |
xboot1 | Actual size of image | image of x-boot, including training firmware of DDR |
uboot1 | Actual size of image | image of U-Boot (factory default) |
uboot2 | Actual size of image | image of U-Boot (the latest update) |
fip | 2 MB | image of fip, including TF-A and OP-TEE |
env | 512 kB | image of environment variable of U-Boot |
env_redund | 512 kB | image of environment variable of U-Boot (redundant) |
dtb | 256 kB | image of device-tree blob (not used) |
kernel | 25 MB | image of Linux kernel with U-Boot header |
rootfs | Depend on size of flash | image of ubifs root file-system |
It is essential to ensure that the combined size of the nand_header, xboot1, uboot1, and uboot2 partitions does not exceed 4 MB. This constraint is crucial as the fip partition initiates at a 4 MB offset.
If a 128MB, 512MB, or any other size NAND flash is utilized, the size of the rootfs partition will dynamically adjust to either shrink or extend to occupy the space available on the NAND flash up to its full capacity. However, the sizes of other partitions will remain unchanged.
Note
To adjust partitions, please modify the define MTDPARTS_DEFAULT in the file:
'boot/uboot/include/configs/pentagram_common_sp7350.h'
The existing MTDPARTS_DEFAULT for SPI-NAND flash is as follows:
#define MTDPARTS_DEFAULT "sp_spinand.0:128k(nand_header),384k(xboot1),1536k(uboot1),4096(uboot2),2m(fip),512k(env),512k(env_redund),256k(dtb),25m(kernel),-(rootfs)"The existing MTDPARTS_DEFAULT for 8-bit NAND flash is as follows:
#define MTDPARTS_DEFAULT "sp_paranand.0:128k(nand_header),384k(xboot1),1536k(uboot1),4096k(uboot2),2m(fip),512k(env),512k(env_redund),256k(dtb),25m(kernel),-(rootfs)"Refer to the struct BootProfileHeader defined in xboot/include/nand_boot/nandop.h for the Boot Profile Header.
eMMC Device
An eMMC device is structured into 4 distinct types of areas and supports up to 8 hardware partitions:
Boot Area Partition 1 and 2
Replay Protected Memory Block (RPMB)
General Purpose Partition 1, 2, 3 and 4
User Data Area Partition
Boot Area Partitions
An eMMC device incorporates one or two Boot Area partitions. The SP7350 platform specifically stores the x-boot image in Boot Area Partition 1, as depicted below:
Replay Protected Memory Block (RPMB)
Both U-Boot and Linux on the SP7350 platform support access to the RPMB of the eMMC device.
General Purpose Partitions
The SP7350 platform does not utilize these partitions.
Sub-partitions in User Data Area Partition
The User Data Area Partition of an eMMC device is further divided into 8 sub-partitions, accompanied by a GUID partition table (GPT), as illustrated in the figure below:
Please refer to the table below for an explanation of each partition:
Partition | Size | Descriptions |
|---|---|---|
GPT | 17 kB | GUID partition table, including MBR, header and 128 partition table |
uboot1 | 1 MB | image of U-Boot (factory default) |
uboot2 | 1 MB | image of U-Boot (the latest update) |
fip | 1 MB | image of fip, including TF-A and OP-TEE |
env | 512 kB | image of environment variable of U-Boot |
env_redund | 512 kB | image of environment variable of U-Boot (redundant) |
dtb | 256 kB | image of device-tree blob (not used) |
kernel | 32 MB | image of Linux kernel with U-Boot header |
rootfs | Depend on size of device | image of Linux ext4 root file-system |
If a 2GB, 4GB, or any other size eMMC is utilized, the size of the rootfs partition will dynamically adjust to either shrink or extend to occupy the space available on the eMMC up to its full capacity. However, the sizes of other partitions will remain unchanged.
Overlay File System
If overlay file-system is chosen, an additional partition called overlay is added after rootfs partition. Refer to the figure below where overlay partition is added:
Please refer to the table below for an explanation of rootfs and overlay partitions:
Partition | Size | Descriptions |
|---|---|---|
rootfs | Actual size of rootfs | The lower directory of the overlay file-system. This is a read-only file system containing the base root file-system, in squashfs format. |
overlay | Depend on size of device | The upper directory of the overlay file-system. This is the writable file system where any changes are stored, in ext4 format. |
SD Card
The SP7350 platform offers support for booting from an SD card, providing a convenient solution for updating system images, particularly during the developmental stage or debugging. Although the SD card may exhibit lower performance compared to the eMMC device, its utility in certain scenarios remains valuable.
Partitioning
The SD card is divided into two essential partitions: the Boot (boot) partition and the root file-system (rootfs) partition, as shown in figure below:
Boot (boot) Partition
Size of Boot partition is 256 MB. It contains essential files crucial for system booting. Boot partition should be formatted to DOS/Windows FAT32 or FAT16 file-system and is required to be the first partition on the SD card. Refer to table below for files in root directory in boot partition:
File name | Descriptions |
|---|---|
ISPBOOOT.BIN | image of x-boot |
fip.img | fip image which includes TF-A and OP-TEE images |
u-boot.img | image of U-Boot |
uEnv.txt | uenvcmd command of U-Boot |
uImage | image of Linux kernel with U-Boot header |
Root File-system (rootfs) Partition
The Root file-system (rootfs) partition houses the Linux ext4-formatted root file-system. The size of the rootfs partition for a newly built SD card is close to the actual size of the initial root file-system. Users are advised to extend the partition to the end of the SD card using tools such as fdisk. Following the extension of the partition, the file system should be extended using tools like resize2fs. Alternatively, users can employ integrated tools such as parted or gparted to extend both the partition and file-system simultaneously.