SYSTEM PARTITION

version 1.4

1. Partition Introduction¶

1.1. Flash Partition Introduce¶

The partition table is saved in the partition_layout.txt output of the compilation. As shown in the figure below, the partition config may be different in different software versions. Please refer to the currently compiled code:

SPI-NOR partition table information：

SPI-NAND partition table information：

CIS：

Spinand is stored in the flash 0 address, and Nor is stored after the IPL partition, it contains three parts:

• GCIS

It contains a general flash info, in order to make the rom code adapt to most flash parameters, boot smoothly enter the IPL.

• flash info

SNI, save some basic information of flash, such as block page count, block count, etc., which will change according to the type of flash.

• partition info

PNI, saved partition information, only IPL/IPL_CUST/RTK can see the information in the PNI. When the linux system is running, the partition information is replaced with uboot's mtdparts to perform the linux native partitioning process.

In addition to the BOOT partition used to make One bin in mtdparts, which can be different from the PNI, the other partition information must be the same as that in the PNI. From the PNI, we can see that the BOOT partition distribution in mtdpars is more detailed, such as the specific location of IPL/IPL_CUST/UBOOT.

IPL/IPL_CUST:

After the CPU is powered on, the rom code runs first. The code is stored in a special ROM and is read-only. After the ROM code runs, it will find the location of the IPL and resolve the location of the IPL address. The difference between NOR and SPINAND will be introduced in the following chapters. The main function of IPL is to do some basic hardware initialization, such as setting the current DDR parameters, and GPIO/IIC related.

There are some common hardware modules during IPL initialization. IPL_CUST will initialize customized hardware executable binary files according to the actual situation of the current board, such as customized GPIO, IIC configuration.

UBOOT： Store UBOOT binary files.

ENV： Store the environment variables of UBOOT。

LOGO: Store the relevant configuration of the boot logo.

MISC: The partition where the system configuration script is stored is the littlefs file system, which contains bootlogo, screen parameter and other related init configuration and resource files. If it is configured, there is no need to add a LOGO partition. For details, please refer to BOOT LOGO Reference

KERNEL： Store the binary files of the kernel.

**ROOTFS：**The root directory file system.

UBI: The content of UBI will not be displayed in the partition table above. UBI will create multiple sub-partitions in ubifs format, which you can create by yourself. Spinand's miservice partition is placed in UBI.

APPLICATION/CUSTOMER： User extended partition.

**MISERVICE:**Store the ko, so, of the MI module, config scripts and bin.

1.2. MISERVICE Partition¶

The contents of the MISERVICE partition are mounted to the root directory /config/. The files in the following table must keep the same path, otherwise the system may not start.

└── config
├── board.ini                                 ---->保存当前板子的信息
├── config_tool                         ---->mi sys初始化mmap内存的应用
├── dump_config -> config_tool          ---->dump config 应用，config_tool的symbol link。
├── dump_mmap -> config_tool                ---->dump mmap应用，config_tool的symbol link。
├── fbdev.ini                           ---->Framebuffer 配置，若无fbdev需求可删除。
├── iqfile
│   ├── imx307_iqfile.bin
│   ├── iqfile0.bin -> imx307_iqfile.bin      ---->Sensor IQ相关的bin
│   ├── iqfile1.bin -> imx307_iqfile.bin
│   ├── iqfile2.bin -> imx307_iqfile.bin
│   ├── iqfile3.bin -> imx307_iqfile.bin
│   └── isp_api.xml
├── mmap.ini                            ---->Mmap。Mmap可以参考《Memory Layout介绍.pdf》
├── model                                     ---->模块相关配置，可以删除。
│   ├── Customer_1.ini
│   ├── Customer_2.ini
│   └── Customer_auto_test.ini
├── modules                                    ---->系统KO存放路径。
│   └── 4.9.84
│       ├── cifs.ko
……
├── pq                                        ---->NVR显示PQ相关。
│   ├── Bandwidth_RegTable.bin
│   ├── Main.bin
│   └── Main_Ex.bin
├── terminfo                                  ---->Console显示相关。
│   └── v
│       ├── vt100
……
└── venc_fw                                   ---->Encoder的firmware
└── chagall.bin


2. CIS Partition¶

The partition of CIS is divided into three parts, starting from address 0 of flash, they are GCIS, PNI, and SNI.

2.1. PNI¶

The partinfo.pni is dynamically generated by pnigenerator, and it will be saved as a separate file in image/boot/ after compilation.

Code and compilation:

Source path of pnigenerator:

project/image/makefiletools/src/pnigenerator/pnigenerator.c


Compile with gcc on the server:

gcc pnigenerator.c -Wall –o pnigenerator


Example：

pnigenerator -c 1024 -s 0x20000 -a "0x140000(CIS),0x60000(IPL),0x60000(IPL_CUST),0xC0000(UBOOT)" -b "0x60000(IPL),0x60000(IPL_CUST),0xC0000(UBOOT)" -t "0x60000(ENV),0x20000(KEY_CUST),0x500000(KERNEL),0x500000(RECOVERY),0x600000(rootfs),0x60000(MISC),-(UBI)" -o /home/malloc.peng/hc/project/image/output/images/boot/partinfo.pni


Parameter definition:

-r: Read the partition in the target PNI file and print it.

-c: All partitions account for the BLOCKS of FLASH.

-s: A BLOCK data size of FLASH, unit: byte.

-a: A collection of BOOT PART partitions, expressed in the grammatical format of mtdparts.

-t: A collection of SYS PART partitions, expressed in the grammatical format of mtdparts.

-o： File name and path of the generated PNI file

The PNI file is not statically stored in the packaged project, it is determined by the compilation configuration used by the user, and is generated by pnigenerator according to the parameters of the incoming configuration partition.

PNI passes the "-a" and "-t" parameters into the partition information to generate the file project/image/output/images/boot/partinfo.pni.

2.2. SNI¶

The path where SNI is stored in the ALKAID board:

• SPINAND:

project/board/$(CHIP)/boot/spinand/partition/flash_list.sni  • NOR: project/board/$(CHIP)/boot/nor/partition/flash_list.nri


2.3. GCIS¶

GCIS is a special SNI, which contains general FLASH initialization parameters, which are used to read the parameters of starting FLASH for the solidified code in ROM CODE, so as to read the data of IPL and start the BOOT stage into IPL.

The path where SNI is stored in the ALKAID board:

• SPINAND:

project/board/$(CHIP)/boot/spinand/partition/flash.sni  • NOR: project/board/$(CHIP)/boot/nor/partition/flash.nri


2.4. CIS Partition Data Structure¶

The CIS partitions are spliced by GCIS, PNI, and SNI in a specific way, and are dynamically generated by Makefile scripts.

The above figure shows the CIS data structure. Both GCIS and PNI are smaller than the size of a PAGE, so they each occupy a PAGE. SNI_LIST saves all FLASH information, it will be added to the back of PAGE1. The PAGE size of NOR FLASH and SPINAND FLASH is related to FLASH specifications, please refer to FLASH SPEC for details.

The size of PAGE can be defined according to the cis$(PGSIZE) defined in the config script of the partition. In the process of making the partition burning script, the bin making and burning of the CIS partition is one of the steps. The making of the CIS bin is executed in the target cis_nofsimage in project/image/image.mk. The cis.bin will be generated in project/image/output/images/ after production, including GCIS/PNI/SNI. 3. Partition Config¶ 3.1. Note Before Config¶ The partitions of spi-nor flash and spi-nand flash can be classified into two categories: • Recommended unmodifiable boot • Changeable sys The partition changes introduced in this chapter are all in sys, including configuration scripts to change the order of partitions, package partitions, and generate burning scripts. If the user has your own packaging and burning process, please ignore this chapter. Special note: The files specially marked in the miservice partition in the previous chapter need to be placed in the specified path for the system to run. When creating the partition, please create /config/ in the root directory to place the relevant files. 3.2. Script Config¶ Partition changes are divided into partition production, packaging and partition burning script production. The following two branches of the flowchart, the left is the partition production and packaging process; the right is the partition burning script production process, which only supports tftp upgrade script, does not support usb upgrade script production. 3.3. Partition Configuration Script¶ Script location for partition config: project/image/config/$(CHIP)/xxx.partition.config


All the codes related to partition adjustment are implemented by this partition configuration information script, which will have many copies, and each different chip, spinand partition or spinor partition will have its own partition config file.

The partition config file used by the project can be found through build config, and the defined variable is IMAGE_CONFIG.

In this configuration script, the variable IMAGE_CONFIG can find the corresponding partition configuration script.

In the config script file, each partition is represented by a set of variables, as shown below:

The CIS partition stores a set of specified partition configuration raw data, which is a special partition generated by a special command.

The partitions are divided into whether they have a file system or not. Their packaging and burning scripts are different. The creation of a partition image file with a file system can be processed by tools in a unified manner, and a partition without a file system needs to be processed separately for each partition.

The above introduced some partitions used by the public version, such as the miservice partition, which can be configured as a read-only squashfs file system, or it can be made into jiffs2 or ubifs. All partitions used by the public version are used by the xxx.mk script to fill the mirror. The content of the file inside the file, miserive.mk will copy the ko and so required by mi to the target folder, rootfs.mk will copy the files needed in the root file system to the target folder, for example, rootfs.mk needs to be copied the busybox tool required by linux.

Examples of miserive partition config:

3.4. Partition Location Change¶

In the CIS partition configuration, the variables cis$(BOOTTAB0), cis$(BOOTTAB1), and cis$(SYSTAB) are used to configure the partition information. cis$(BOOTTAB0) and cis$(BOOTTAB1) are used to specify the A-B partition in the production of one bin, and identify whether the BOOT used is active in the PNI. At present, the A-B partition is introduced in the spi-nand partition, and BOOTTAB0 is active partition, when BOOT0 is abnormal in programming or a invalid block appears, it will jump from BOOT0 to the backup partition of BOOT1, and re-identify the active partition in the PNI, and it will automatically run to the active partition next time it starts. . BOOTTAB0, BOOTTAB1, and SYSTAB are the definitions of the partition table. The syntax format it uses is supported by mtdparts, and the format is as follows: partition0_size(partition0_name), partition0_size(partition0_name),……  The description format of CIS and IPL partition: 0x14000(CIS),0x60000(IPL)  Each partition is separated by ",". If the starting position of the partition is not specified, it will start from the first partition, and the default will start from address 0 of FLASH. If you need to configure from the specified location of the partition, follow the syntax format: partition0_size@offset(partition0_name)  After the starting position of the partition is specified, the starting position of the added partition will increase one by one after the current partition if no position is specified. If the current partition is the last one, you can select the size of the adaptive partition. For example, the UBI partition of spinand is at the end of the partition table, and it can be expressed as follows: xxxx(xxxx), xxxx(xxxx),-(UBI)  The parsing logic of the partition table will refer to the size of the current flash configuration to adapt to the size of the UBI. The modification of the partition location is to change the location of cis$(BOOTTAB0), cis$(BOOTTAB1), and cis$(SYSTAB). The partition of the BOOT part will not change, generally SYSTAB will change.

Use jiffs2 as a readable and writable partition file system on the flash of spinor. The relevant configuration of the customer partition is defined as follows:

customer$(RESOUCE) =$(OUTPUTDIR)/customer
customer$(FSTYPE) = jffs2 customer$(PATSIZE)   = 0x5C0000
customer$(MOUNTTG) = /customer customer$(MOUNTPT)  = mtd:customer
customer$(OPTIONS) = ro customer$(MTDPART) = $(customer$(PATSIZE))(customer)
customer$(OTABLK) = /dev/mtdblock6  • customer$(RESOUCE):

The contents of the folder where the source files to be packaged are located are filled in by the customer.mk script.

• customer$(FSTYPE): The file system type of the package. • customer$(PATSIZE)：

Partition size.

• customer$(MOUNTTG)、customer$(MOUNTPT)、customer$(OPTIONS)： After the partition is working on the board, the path and parameters that need to be mounted will be processed by rootfs.mk. • customer$(OTABLK):

The path of the upgraded device node required for OTA upgrade packaging.

3.5.1. Modification¶

To modify the partition, modify the file system and partition size.

After modifying the file size, check whether the total size of all partitions exceeds the flash size.

You can check whether the partition size overflows in partition_layout.txt.

aaa$(RESOUCE) =$(OUTPUTDIR)/aaa
aaa$(FSTYPE) = jffs2 aaa$(PATSIZE)   = 0x6B0000
aaa$(MOUNTTG) = /aaa aaa$(MOUNTPT)   = mtd:aaa
aaa$(OPTIONS) = rw aaa$(OTABLK)   = /dev/mtdblockX

1. Suppose you add a partition named aaa, and then configure its size, etc.

2. After the partition-related variables are configured, specify their placement in cis$(SYSTAB) = "xxx". 3. Add "aaa" after the variable "IMAGE_LIST". 4. Add "aaa" after the variable "USR_MOUNT_BLOCKS" indicating the node to be mounted. 5. Add the logic of$(OUTPUT)/aaa to copy files in the script before partitioning and packaging.

3.5.3. Delete Partition¶

Contrary to the operation of adding partitions.

3.5.4. Burning Script¶

The system will automatically generate it in script.mk according to the partition configuration.

The partition change of Squashfs is similar to jiffs2, mainly different in xxx$(FSTYPE). In addition to rootfs, the miservice partition is made into squashfs: miservice$(RESOUCE)   = $(OUTPUTDIR)/tvconfig/config miservice$(FSTYPE)    = squashfs

miservice$(PATSIZE) = 0x180000 miservice$(MOUNTTG)  = /config

miservice$(MOUNTPT) = /dev/mtdblock3 miservice$(OPTIONS)   = ro


The system will automatically generate a burning script in script.mk according to the partition configuration.

UBIFS partition is used as a readable and writable partition file system on spinand.

All partitions of UBIFS belong to sub-partitions in the mtd block of UBI. A common UBI partition variable is set as follows:

miservice$(RESOUCE) =$(OUTPUTDIR)/miservice/config

miservice$(FSTYPE) = ubifs miservice$(PATSIZE)   = 0xA00000

miservice$(MOUNTTG) = /config miservice$(MOUNTPT)  = ubi0:miservice

miservice$(OPTIONS) = rw  The ubifs partition does not need to add mtdpart information, that is, there is no need to add the partition location in cis$(SYSTAB)= xxx.

The advantage of the Littlefs partition is that it can be accessed in uboot/linux/rtk.

The MISC partition is used to store files related to system configuration scripts, such as screen parameter information:

misc$(RESOUCE) =$(OUTPUTDIR)/misc
misc$(FSTYPE) = lfs misc$(PATSIZE) = 0x60000
misc$(MOUNTTG) = /misc misc$(MOUNTPT) = /dev/mtd4
misc$(OPTIONS) = rw misc$(MTDPART) = $(misc$(PATSIZE))(MISC)
misc$(OTABLK) = /dev/mtdblock4  For modification methods, please refer to squashfs or jffs2. 3.9. Special Partition Processing¶ KERNEL, uboot, IPL, logo, cis, etc. are special partitions without special file systems and cannot be centrally processed in the Makefile script. Adding a special partition requires the following two steps (Take kernel partition as an example): 1. image.mk needs partition and package script commands: kernel_nofsimage: @echo [[$@]]

cp -rvf $($(patsubst %_nofsimage,%,$@)$(RESOUCE)) (IMAGEDIR)/$(patsubst %_nofsimage,%,$@)

2. script.mk needs the commands generated by the partition burning script:

kernel_$(FLASH_TYPE)__script: @echo "# <- this is for comment / total file size must be less than 4KB" >$(SCRIPTDIR)/[[kernel.es
@echo tftp $(TFTPDOWNLOADADDR) kernel >>$(SCRIPTDIR)/[[kernel.es
@echo $(FLASH_PROBE) >>$(SCRIPTDIR)/[[kernel.es
@echo $(FLASH_ERASE_PART) KERNEL >>$(SCRIPTDIR)/[[kernel.es
@echo $(FLASH_WRITE_PART)$(TFTPDOWNLOADADDR) KERNEL \{filesize} >> $(SCRIPTDIR)/[[kernel.es @echo "% <- this is end of file symbol" >>$(SCRIPTDIR)/[[kernel.es
@echo kernel-image done!!!


4. ONE BIN¶

4.1. ONE BIN Partition¶

The ONE BIN function is based on the ALKAID packaging script to merge the BOOT PART partition into a bin through the dd command. From the perspective of uboot and linux kernel, you can enter the command mtdpart in uboot to see the current partition plan. The difference from pni is BOOT PART does not refine internal partitions, but consists of a BOOT partition.

• NOR FLASH:

• SPINAND FLASH:

After ONE BIN is packaged, a boot.bin will be generated under output/images/, which is spliced from the image of ipl/ipl_cust/uboot, and cis partition will be added to nor flash.

4.2. SPINAND BOOT Partition¶

On nand flash, BOOT0/BOOT1 belong to the A/B partition, and the ROM code is turned on from the BOOT0 partition by default. If an ECC ERROR occurs in the BOOT0 partition or an invalid block is encountered, it will jump to the BOOT1 partition, and after the next boot, the default is from BOOT1 Open in the partition, which can ensure that a set of backup mechanism is established in the BOOT part during the upgrade process to avoid the inability to enter the UBOOT cmd line after the BOOT upgrade fails.

ONE BIN is spliced by the dd command, as shown below:

• SPI-NAND：

The orange part above represents the size of the partition in the MTD PART, boot.bin represents the actual one bin size, and the purple part represents the layout of this part in the PNI.

The image of IPL/IPL_CUST does not exceed the size of one block, so they and their Backup each occupy the size of 3 blocks.

UBOOT's data occupies the size of 2 blocks. Since uboot is often customized, the image size of uboot will change. Configuring 2 blocks cannot guarantee all situations. If you want to modify it, please modify the config file:



4.6. Note¶

If you need to modify the partition configuration of ONE BIN, please read this chapter carefully. Only uboot$(DATASIZE) of spinand and boot and boot$(PATSIZE)ofspinorcan be modified appropriately to deal with theIPL/IPL_CUS/UBOOTimage size changes, please check with FAE after modification.

If the modification is improper, it is easy to cause the BOOT in the production link to fail to start

If the packaging process does not refer to our company's ALKAID, pay special attention to the BL0 PBA and BL1 PBA in spinand's sni_list and gcis, you need to fill in the correct value according to the current BOOT0/BOOT1 position, or after confirming that the BOOT partition is normal, use the partition layout and boot.bin of BOOT compiled by ALKAID.

If you need to make boot.bin by yourself, please refer to the function updatecis of the Makefile in the script image.mk, and the target cis_nofsimage, boot_images`.