Partition Configuration

[中文]

Note

In this section, BL1 specifically refers to the BootROM, and BL2 specifically refers to the Bootloader.

Partition Table

The FLASH partition table is a CSV file, the following is a configuration example:

Name

Offset

Size

Execute

Read

Write

primary_bl2

128k

TRUE

TRUE

primary_cpu0_app

128k

TRUE

TRUE

secondary_cpu0_app

128k

TRUE

TRUE

sys_rf

0x3fe000

4k

TRUE

sys_net

4k

TRUE

Partition table are fixed at six columns:

  • Name - required, indicating the name of the partition.

    • Partition names must be unique. The build system will generate a set of macros based on the partition name. Only the partition name is unique to ensure that the generated macros will not be defined repeatedly.

    • Code partition name format is primary_binname or secondary_binname, where:

      • The primary prefix indicates the corresponding primary partition during OTA upgrade (corresponding to A partition during XIP upgrade).

      • The secondary prefix indicates the corresponding secondary partition during OTA upgrade (corresponding to partition B during XIP upgrade). When the secondary partition does not exist, it means that the BIN cannot be upgraded.

  • binname indicates the name of the binary file placed in the partition, for example, the binary file placed in the primary_cpu0_app partition is cpu0_app.bin.
    • Reserved partitions, reserved partitions are partitions that Armino has used for specific purposes:

      • primary_cpu0_app and secondary_cpu0_app - macros generated by these two partitions are used to link when app.bin is built.

      • primary_bl2 and secondary_bl2 - The macros generated by these two partitions will be used to link when building bl2.bin.

      • primary_tfm_s and secondary_tfm_s - The macros generated by these two partitions will be used to link when building tfm_s.bin.

      • primary_tfm_ns and secondary_tfm_ns - The macros generated by these two partitions will be used to link when building tfm_ns.bin.

      • primary_all and secondary_all - build virtual partitions generated by the system, which are used to merge multiple partitions into one partition for overall signing.

      • sys_ps, sys_its, sys_otp_nv - These three partitions are all unique partitions in tfm_s.bin. When the primary_tfm_s partition exists, this three partitions must exist.

      • sys_rf, sys_net - special partitions in Armino, RF calibration, Wi-Fi/TCPIP will use these two partitions. These two partitions must exist when primary_cpu0_app exists.

      • bl1_control, primary_manifest, secondary_manifest - Secure Boot related partitions.

  • Offset - optional. Indicates the physical offset of the partition in FLASH.

    • When no offset is configured, offset takes the value of the end address of the previous partition. When the first partition is not configured, offset is 0.

    • Holes are allowed between two adjacent partition addresses, but overlapping is not allowed.

    • It is generally not recommended to configure offset, unless you want to place a partition in a specific, discontinuous position, you only need to configure offset.

    • offset alignment requirements:

      • Any partition must be 4K aligned.

      • The two partitions believed at the S/NS junction must be 68K aligned, otherwise a S/NS block will span two partitions during MPC configuration.

  • Size - Required. Indicates the partition size, the unit k/K means Kbytes, m/M means Mbytes, and 4K alignment is usually recommended.

  • Execute - Optional. Partition executable permission, usually the code partition needs to be configured as TRUE, and the data partition needs to be configured as FALSE. When not configured, it means that it cannot be executed.

  • Read - Optional. Partition readable permission, if not configured, the table cannot be read.

  • Write - optional. The partition can be written, and the table cannot be written if it is not configured.

Partition Configuration

Legacyboot Mode Partition Configuration

In legacyboot mode, the minimum partition configuration table is as follows:

Name

Offset

Size

Execute

Read

Write

primary_bl2

128k

TRUE

TRUE

primary_cpu0_app

1024k

TRUE

TRUE

secondary_cpu0_app

1024k

TRUE

TRUE

sys_rf

0x3fe000

4k

TRUE

sys_net

4k

TRUE

Among them, the first three partitions are placed at the head of FLASH, and the last two partitions are placed at the end of FLASH. The uses of each partition are as follows:

  • primary_bl2 - Bootloader partition.

  • primary_cpu0_app - The partition that runs code on CPU0, i.e. cpu0_app.bin.

  • secondary_cpu0_app - OTA partition for upgrading cpu0_app.bin.

Generally, you can configure and expand according to the following steps:

  • Adjust tail partition offset - adjust the tail partition Offset according to the actual size of FLASH. For example, if 8M FLASH is used, the offset of sys_rf is adjusted to 0x7fe000.

  • Adjust the size of each partition in the header - Adjust Size of each partition according to the actual generated binary size.

  • Add user partitions - It is generally recommended to add your partitions between the first and last partitions.

Secureboot Partition Configuration

In safe boot mode, the minimum partition configuration table is as follows:

Name

Offset

Size

Execute

Read

Write

bl1_control

12k

TRUE

TRUE

primary_manifest

4k

TRUE

secondary_manifest

4k

TRUE

primary_bl2

128k

TRUE

TRUE

secondary_bl2

128k

TRUE

TRUE

primary_tfm_s

512k

TRUE

TRUE

primary_cpu0_app

2304k

TRUE

TRUE

secondary_tfm_s

512k

TRUE

TRUE

secondary_cpu0_app

2304k

TRUE

TRUE

sys_ps

0x7er000

32k

TRUE

sys_its

32k

TRUE

sys_otp_nv

8k

TRUE

sys_rf

4k

TRUE

sys_net

4k

TRUE

Among them, the first nine partitions are placed at the head of FLASH, and the last five partitions are placed at the end of FLASH. The uses of each partition are as follows:

  • bl1_control - used for BL1 control, including jump address configuration on hardware restart, OTP simulation, BL1 debugging, etc.

  • primary_manifest - The signing information of primary_bl2 is placed in this partition. After the system is powered on, if boot_flag is primary_bl2, then BL1 will verify the signature of primary_bl2 according to the content of this partition, and then jump to BL2 after the verification is passed.

  • secondary_anifest - The signature information of secondary_bl2 is placed in this partition. After the system is powered on, if boot_flag is secondary_bl2 - Then BL1 will verify the signature of secondary_bl2 according to the content of this partition, and then jump to BL2 after the signature verification is passed.

  • primary_bl2 - BL2 binary with signed information in primary_manifest.

  • secondary_bl2 - BL2 binary with signature information placed in secondary_anifest.

  • primary_tfm_s - Primary TFM_S binary.

  • primary_cpu0_app - Primary CPU0 APP binary.

  • secondary_tfm_s - Secondary TFM_S binary.

  • secondary_cpu0_app - Secondary CPU0 APP binary.

  • sys_ps, sys_its, sys_otp_nv - Secure storage related partitions in TFM_S.

  • sys_rf, sys_net - Armino RF calibration, Wi-Fi/TCPIP configuration related partitions.

Usually, you can configure and expand the secure boot partition in a similar way to Download mode partition configuration and extension.

Note

If it is determined that the product does not need to support BL2 upgrades, secondary_manifest and secondary_bl2 can be removed.

User-defined Partition Configuration

For the partition configuration in the production version, it is recommended that you refer to Download mode partition configuration and Secure boot mode partition configuration to configure your partition table. But in the development stage, you may want to completely redefine your own partition table, for example, do not run Bootloader, do not support OTA, etc. You can refer to the examples in this section to customize own partition table.

Simplify Partition Table

In legacyboot mode, only run cpu0_app.bin:

Name

Offset

Size

Execute

Read

Write

primary_cpu0_app

1024k

TRUE

TRUE

sys_rf

0x3fe000

4k

TRUE

sys_net

4k

TRUE

In legacyboot mode, run bl2.bin and cpu0_app.bin, but don’t need OTA:

Name

Offset

Size

Execute

Read

Write

primary_bl2

128k

TRUE

TRUE

primary_cpu0_app

1024k

TRUE

TRUE

sys_rf

0x3fe000

4k

TRUE

sys_net

4k

TRUE

In safe boot mode, just run cpu0_app.bin:

Name

Offset

Size

Execute

Read

Write

bl1_control

12k

TRUE

TRUE

primary_manifest

4k

TRUE

TRUE

primary_bl2

128k

TRUE

TRUE

primary_cpu0_app

2304k

TRUE

TRUE

sys_rf

0x3fe000

4k

TRUE

sys_net

4k

TRUE

Run Your Own BIN

Taking the legacyboot mode as an example, if you want to add two upgradeable BINs: test1.bin and test2.bin, the partition table configuration is as follows:

Name

Offset

Size

Execute

Read

Write

primary_bl2

128k

TRUE

TRUE

primary_cpu0_app

1024k

TRUE

TRUE

primary_test1

32k

TRUE

TRUE

primary_test2

32k

TRUE

TRUE

secondary_cpu0_app

1024k

TRUE

TRUE

secondary_test1

1024k

TRUE

TRUE

secondary_test2

1024k

TRUE

TRUE

sys_rf

0x3fe000

4k

TRUE

sys_net

4k

TRUE

Code Generation

When building Armino, the build system will generate partitions_gen.h according to the partition table. This section introduces the code generation rules.

Data partition macro generation

Partitions in the partition table will generate a set of macros in partitions_gen.h. For data or system partitions, only the partition offset and size are generated, Take sys rf` and ``sys net as an example:

#define CONFIG_SYS_RF_PHY_PARTITION_OFFSET 0x3fe000
#define CONFIG_SYS_RF_PHY_PARTITION_SIZE 0x1000

#define CONFIG_SYS_NET_PHY_PARTITION_OFFSET 0x3ff000
#define CONFIG_SYS_NET_PHY_PARTITION_SIZE 0x1000

Code Partition

In addition to generating the partition offset and size in the data partition, the code partition containing the BIN also needs to generate the link address used to build the BIN. Taking the primary_bl2 partition as an example, the macros generated in partitions_gen.h are as follows:

#define CONFIG_PRIMARY_BL2_PHY_PARTITION_OFFSET 0x24000
#define CONFIG_PRIMARY_BL2_PHY_PARTITION_SIZE 0x10000
#define CONFIG_PRIMARY_BL2_PHY_CODE_START 0x24068
#define CONFIG_PRIMARY_BL2_VIRTUAL_PARTITION_SIZE 0xf0e0
#define CONFIG_PRIMARY_BL2_VIRTUAL_CODE_START 0x21e80
#define CONFIG_PRIMARY_BL2_VIRTUAL_CODE_SIZE 0xf060

These macros are used in bl2.bin links, bl2 and OTA source code.

The BL2 partition diagram is as follows:

8

Generate macro calculation method:

  • CONFIG_PRIMARY_BL2_PHY_PARTITION_OFFSET - The partition starts at physical address 0x24000, as defined by partitions.

  • CONFIG_PRIMARY_BL2_PHY_CODE_START - automatically calculated and generated, it is 0x21e80, and CRC will be added.

    • The code can be placed at offset 0x24000, but alignment needs to be considered:

      • CRC alignment, the physical address after alignment is ((0x24000 + 33)/34)*34 = 0x24002, and the virtual address is 0x21e20.

      • CPU vector alignment, CM33 is 128B alignment, ((0x21e20 + 127)/128)*128 = 0x21e80, the corresponding physical address is: 0x24068.

  • CONFIG_PRIMARY_BL2_VIRTUAL_CODE_SIZE - Automatically calculated, 0xf060

    • Alignment waste space is 0x24068 - 0x24000 = 0x68, remaining: 0x10000 - 0x68 = 0xff98

    • Subtract 34B protection bytes: 0xff98 - 34 = 0xff76

    • Turn virtual length: (0xff76/34)*32 = 0xf060

Important

From the above calculations, it can be seen that not the entire code partition can be used to place code, because the alignment of CRC and CPU vector must be considered. For using BL2 The partition for signature verification also needs to remove the 4K space at the beginning and end (used to store the signature information). If the compiled bin size is bin_size, It is recommended that the partition size should be configured at least: (bin_size/32)x34 + hdr_size + tail_size + 128 + 34 + unused_size. Where unused_size is the space reserved for future bin growth. Do 4K alignment after this base.