2. CC Linux System Flash Partition Layout

This section will give an overview about the new system flash partition layout has been introduced with the release of CC Linux 4.0 to have more secure and reliable software updates.

2.1 Partition Layout

The new system flash partiton layout for the Vision line platforms can be seen below:

+------------+--------+------------+------------+-----------+-----------+--------+
|            |        |            |            |           |           |        |
|  IMX-Boot  |  Boot  |  Rootfs A  |  Rootfs B  |  Appfs A  |  Appfs B  |  Data  |
|            |        |            |            |           |           |        |
+------------+--------+------------+------------+-----------+-----------+--------+

The Vision line displays are IMX based, for example V700, V1x00. Extreme line displays, for example X1200, are based on an Intel platform, so the flash layout partition layout will differ as shown below:

+--------+------------+------------+-----------+-----------+--------+
|        |            |            |           |           |        |
|  Boot  |  Rootfs A  |  Rootfs B  |  Appfs A  |  Appfs B  |  Data  |
|        |            |            |           |           |        |
+--------+------------+------------+-----------+-----------+--------+

Table 1 gives the detailed information about each flash partitions.

Table 1: Detailed information about each partitions
Partition	Description	Fs Type	Access
IMX-Boot	Boot partition by the IMX where the u-boot binary resides. It has two blocks inside the partition to support the redundant bootloader support. (Not applicatble for X1200 platform)	Raw binary	Read-only
Boot	Boot partition which holds the uboot environment variables for IMX platforms. For X1200, the boot partition holds the grub bootloader image, grub environmental variables and the grub boot script for boot selection.	VFat	Read-only
Rootfs A	Root filesystem which holds the kernel and the image root files.	Ext4	Read-only
Rootfs B	Alternate Root filesystem to support the redundant software updates.	Ext4	Read-only
Appfs A	Application filesystem which holds the user applications.	Ext4	Read-only
Appfs B	Alternate application filesystem to support the redundant software updates.	Ext4	Read-only
Data	Data partition which holds the user data, configuration files, the overlay filesystems and the SW update logs.	Ext4	Read-Write

2.2 Partition Sizes

The size of each partition differs for the different displays based on the flash size of each and the platform. The size of the partitions are inputted in the WIC file of each platforms. Refer [4.2.5] for where the WIC file is in the BSP structure.

The Table 2 gives the details about the sizes of each partition on different platforms.

Table 2: Partition sizes of each platforms
Partitions	V700	V1x00	Vx10	Yukon	X1200
IMX-Boot	4 mb	4 mb	4 mb	4 mb	-NA-
Boot	1 mb	1 mb	1 mb	1 mb	256 mb
Rootfs A	900 mb	1298 mb	900 mb	1298 mb	4096 mb
Rootfs B	900 mb	1298 mb	900 mb	1298 mb	4096 mb
Appfs A	800 mb	1298 mb	800 mb	1298 mb	4096 mb
Appfs B	800 mb	1298 mb	800 mb	1298 mb	4096 mb
Data	128 mb + Extra Flash space	128 mb + Extra Flash space	128 mb + Extra Flash space	128 mb + Extra Flash space	128 mb + Extra Flash space

V700 and Vx10 platform partition sizes are based on 4 GB emmc flash memory
V1x00 and Yukon platform partition sizes are based on 8 GB emmc flash memory
X1200 platform partition sizes are based on 40 GB emmc flash memory

2.3 Partition Block Names

Each partition has a dedicated Block name on the system and the Block name for each partition on each platform will be same (though different between Vision line and Extreme line), which can be seen from the Table 3

Table 3: Block Name for each partitions
Partition	Block Name - X1200	Block Name - Rest of Platforms
IMX-Boot	-NA-	/dev/mmcblk1boot0 /dev/mmcblk1boot1
Boot	/dev/mmcblk0p1	/dev/mmcblk1p1
Rootfs A	/dev/mmcblk0p2	/dev/mmcblk1p2
Rootfs B	/dev/mmcblk0p3	/dev/mmcblk1p3
Appfs A	/dev/mmcblk0p4	/dev/mmcblk1p4
Appfs B	/dev/mmcblk0p5	/dev/mmcblk1p5
Data	/dev/mmcblk0p6	/dev/mmcblk1p6

2.4 Partition Mountpoints

The partitions are mounted to mountpoints during the system bootup, it is not neccessarily true that all the partitions will be mounted at this time. The partitions mounting is based on the boot slot selection, whether it is A or B. Table 4 will show the partition mountpoints with boot slot A and Table 5 will show the partition mountpoints with boot slot B

Table 4: Partition mountpoints with boot slot A
Partition	Block Name - X1200	Block Name - Rest of Platforms
IMX-Boot	-NA-	not mounted
Boot	/efi	not mounted
Rootfs A	/	/
Rootfs B	not mounted	not mounted
Appfs A	/appfs	/appfs
Appfs B	not mounted	not mounted
Data	/data	/data

Table 5: Partition mountpoints with boot slot B
Partition	Block Name - X1200	Block Name - Rest of Platforms
IMX-Boot	-NA-	not mounted
Boot	/efi	not mounted
Rootfs A	not mounted	not mounted
Rootfs B	/	/
Appfs A	not mounted	not mounted
Appfs B	/appfs	/appfs
Data	/data	/data

Note

Appfs A is tightly coupled with Rootfs A and so does Appfs B is tightly coupled with Rootfs B.

When the system boots up with boot slot A, Rootfs A will be mounted and then the Appfs A will be mounted.
When the system boots up with boot slot B, Rootfs B will be mounted and then the Appfs B will be mounted.

The mounting will be done by the Systemd init script.

2.5 Updating Partitions

The flash partitions can be updated by using Linux utilities like dd or cat.

An example of how to update a partition using dd is shown below:

*$ sudo dd if=image.img of=/dev/mmcblk1p2 bs=1M flash=progress*
*$ sync*

Make sure the partition that is going to be updated is not mounted to any mountpoint. If the partition is mounted, unmount it before updating.

For example, if the partition Appfs A which is going to be updated is mounted to mountpoint /appfs, then the partition can be unmounted as below:

*$ sudo umount /appfs*