The resource management service offers the possibility to divide the system into groups of resources or partitions. Resources within a partition can not access resources outside of it's partition.
Partitioning a system is useful to isolate resources from one another, this gives you the ability to have for instance FreeRTOS and Linux each running simultaneously with its own set of resources. In the FreeRTOS/Linux example you could partition/divide the system into two groups/partitions where all resources/peripherals needed by FreeRTOS would be completely isolated from the resources needed by Linux, if any of the resources on the Linux partition tried to access a resource on the FreeRTOS partition the transaction would result in a bus error, as if the resource tried to access a region outside of its memory map.
The partitioning mechanism is enforced by hardware and the configuration of the underlying hardware is completely abstracted by the SCFW API. The system partitioning can be performed in two ways:
A partition can have:
All of the items mentioned above can be grouped within a partition.
It is important to note that:
At boot time the system is initially configured in three partitions:
Once Linux and the M4 boot a typical use case is to partition the system as follows:
In this case the boot partition is split into the ATF/Linux partition and the M4 partition.
The ARM Trusted Firmware environment add a layer of abstraction to secure the environment and it is assigned cores and memory to execute in this privileged state, all the remaining resources, pads and memory are assigned to the Linux partition.
The M4 partition contains all the resources required by the M4 to execute, as well as the resources required by the application running on the M4.
The SCFW porting kit provides an example on doing boot time configuration at the board.c file under platform/board/mx8q<x or m>_<your board>/board.c, board_system_config is the function in charge of partitioning the system at boot time.
From the sc_fw_port.pdf (porting guide) document included in the porting kit - Boot Flags chapter:
Here are a few important points to highlight:
flash_linux_m4: $(MKIMG) mx8qx-ahab-container.img scfw_tcm.bin u-boot-atf.bin m4_image.bin
./$(MKIMG) -soc QX -rev B0 -append mx8qx-ahab-container.img -c -flags 0x00200000 -scfw scfw_tcm.bin -ap u-boot-atf.bin a35 0x80000000 -p3 -m4 m4_image.bin 0 0x34FE0000 -out flash.bin
The example above can be found under your i.MX8 variant on the soc.mak file, in the example above the SC_BD_FLAGS_ALT_CONFIG flag is being set by -flags 0x00200000 and the partition for the M4 is defined as the third one by the -p3 parameter.
Without the -flags 0x00200000 (setting SC_BD_FLAGS_ALT_CONFIG) parameter on mkimage NO partition happens at boot time, if the target used to build the image does not set this flag, then the SCU does not partition the system.
On the board.c file the code in charge of checking for this flag is the following:
/* Configure initial resource allocation (note additional allocation
and assignments can be made by the SCFW clients at run-time */
if (alt_config != SC_FALSE)
{
if the alt_config flag is not set, then the partitioning is skipped.
*** Partitions **********************************
Partition: 0
Parent: 0
DID: 2
Flags:
Used
Secure
Isolated
Partition: 1
Parent: 0
DID: 0
Flags:
Used
Isolated
Partition: 2
Parent: 0
DID: 1
Flags:
Used
Secure
Restricted
Isolated
*** Resources ***********************************
Partition: 0
SC_PID0
SC_SEMA42
SC_TPM
SC_PIT
SC_UART
... Continues ....
DBLOGIC
DRC_0
DRC_1
Partition: 1
SC_PID1
SC_PID2
SC_PID3
SC_PID4
... Continues ....
BOARD_R5
BOARD_R6
BOARD_R7
Partition: 2
SECO
CAAM_JR1
CAAM_JR1_OUT
*** Memory Regions ******************************
Partition: 0
000: 0x030FE0000 - 0x03101FFFF
Partition: 1
001: 0x000000000 - 0x01BFFFFFF
002: 0x034000000 - 0x037FFFFFF
003: 0x038000000 - 0x03BFFFFFF
004: 0x060000000 - 0x06FFFFFFF
005: 0x070000000 - 0x07FFFFFFF
006: 0x080000000 - 0x0FFFFFFFF
007: 0x400000000 - 0x43FFFFFFF
008: 0x880000000 - 0xFFFFFFFFF
Partition: 2
*** Pads ****************************************
Partition: 0
M40_I2C0_SCL
M40_I2C0_SDA
... Continues ....
SCU_BOOT_MODE4
SCU_BOOT_MODE5
Partition: 1
SIM0_CLK
SIM0_RST
SIM0_IO
... Continues ....
ENET1_RGMII_RXD2
ENET1_RGMII_RXD3
COMP_CTL_GPIO_1V8_3V3_ENET_ENETA
Partition: 2
The dump contains the configuration of the partition, for instance:
*** Partitions **********************************
Partition: 0
Parent: 0
DID: 2
Flags:
Used
Secure
Isolated
On the example above the Partition parent is partition 0 (itself, this is the System Controller partition, all partitions spawn from this one). The Domain ID (DID) is 2, this ID is used to identify the partition by the hardware, it is used to enforce hardware isolation. It is also a secure and isolated partition, the meaning of these flags can be found below and in the sc_fw document:
The rest of the sections of the dump highlight all the resources, pads and memory regions enclosed in each partition.
The run time partitioning doesn't differ from the example provided on the porting kit, that example can be used as a base to create a partition at run time by calling the SCFW API.
The following examples will show how to modify the default partition configuration on the evaluation boards, i.MX8QM MEK will be used as a reference. With BSP 4.14.98_2.3.0, the porting kit can be obtained from i.MX Software and Development Tools | NXP .
First we will dump the default configuration without partition, e.g. without setting the ALT_CONFIG flag, most mkimage targets with a single image are configured this way, see the soc.mak and related files under scripts:
soc.mak\iMX8QM - imx-mkimage - i.MX Mkimage Bootloader Tool
For details on how to create a bootable image see i.MX8 Boot process and creating a bootable image
We can see that the targets flash and flash_spl do not set any flags on the image, therefore no partition of the system will occur at boot time.
flash: $(MKIMG) $(AHAB_IMG) scfw_tcm.bin u-boot-atf.bin
./$(MKIMG) -soc QM -rev B0 -append $(AHAB_IMG) -c -scfw scfw_tcm.bin -ap u-boot-atf.bin a53 0x80000000 -out flash.bin
We will build the SCFW with the Debug Monitor enabled in order to be able to dump the partitions:
make qm R=B0 B=mek M=1
Now we copy the SCFW binary we just build (scfw_tcm.bin under build_mx8qm_b0) to the mkimage iMX8QM folder, along with the SECO FW, ATF (bl31.bin) and u-boot.
On mkimage the flash target will be used to create a bootable image with the SCFW we just build:
make SOC=iMX8QM flash
Flash the image to your sd card
sudo dd if=iMX8QM/flash.bin of=/dev/mmcblkXX bs=1k seek=32
sync
The MEK has two serial ports, the first one (usually ttyUSB0) is used by the A cores (u-boot/Linux in this case), the second one is used by one of the M4 cores OR the SCFW, in this case it will be used by the SCFW.
Unfortunately there aren't enough serial ports on the MEK board to allow a dedicated port for SCU, M4 cores and A cores, so in order to use the Debug Monitor on the MEK the SCFW has to take over the M4_0 UART terminal.
On the SCFW Debug monitor terminal type "dump rm" this will dump all the partition information, the full log is attached to this document (imx8qm_mek_no_partition.txt). On this log it can be seen that 4 partitions are created:
Partition 0 --> SCFW
Partition 1 --> ATF
Partition 2 --> SECO
Partition 3 --> U-boot/Linux/M4 cores/Rest of the system
The ATF partition is created at run time by the ATF to run in its secure state, no extra partition is created at boot time, if an image without ATF where to be used only three partitions would be seen:
Partition 0 --> SCFW
Partition 1 --> U-boot/Linux/M4 cores/Rest of the system
Partition 2 --> SECO
Now we will create an image with the SC_BD_FLAGS_ALT_CONFIG flag set, so that partitioning occurs at boot time, for demonstration purpose we will use the same target previously used but we will modify it to set the ALT_CONFIG flag, so on mkimage modify the flash target as follows:
On iMX8QM/soc.mak
flash: $(MKIMG) $(AHAB_IMG) scfw_tcm.bin u-boot-atf.bin
./$(MKIMG) -soc QM -rev B0 -append $(AHAB_IMG) -c -flags 0x00200000 -scfw scfw_tcm.bin -ap u-boot-atf.bin a53 0x80000000 -out flash.bin
After the modification build the image again
make clean
make SOC=iMX8QM flash
On mkimage's output you should be able to see:
FLAG: 0x00200000
Note how the same SCFW is used as in the previous example, same for ATF, SECO, U-boot the only required change in this case is to enable the ALT_CONFIG flag in the image.
Flash the sd card with the new image
sudo dd if=iMX8QM/flash.bin of=/dev/mmcblkXX bs=1k seek=32
Dumping again the partitioning on the Debug monitor shows how the system now created additional partitions for the M4 cores and a shared partition:
Partition 0 --> SCFW
Partition 1 --> ATF (Created at run time by the ARM Trusted Firmware)
Partition 2 --> SECO
Partition 3 --> M4_0
Partition 4 --> M4_1
Partition 5 --> Shared partition
Partition 6 --> U-boot/Linux/rest of the system
The full log is attached as well.
Now we will modify the default SCFW configuration to move some resources/pads from the M4 partition to the A cores partition (u-boot/Linux).
All FlexCAN resources and pads will be moved from the M4 partition to the A core partition.
From sc_fw_api_qm_b0.pdf Resource List:
From sc_fw_api_qm_b0.pdf Pad List:
Not all resources are available on all variants, for details on what resources/pads are available on your device please refer to its respective api document.
Go back to the SCFW porting kit and open platform/board/mx8qm_mek/board.c, go to the definition of board_system_config which is the function where partitioning occurs.
The code first verifies if the alt_config flag is set, and if not it skips partitioning, so all partitioning happens within the following if statement:
/* Configure initial resource allocation (note additional allocation
and assignments can be made by the SCFW clients at run-time */
if (alt_config != SC_FALSE)
The following partitions and memory regions are declared within this if statement:
sc_rm_pt_t pt_m4_0;
sc_rm_pt_t pt_m4_1;
sc_rm_mr_t mr_m4_0, mr_m4_1;
sc_rm_pt_t pt_sh;
sc_rm_mr_t mr_sh;
pt_m4_0 is the partition for the M4_0 core, its memory region is declared as mr_m4_0.
Likewise for the M4_1 pt_m4_1 and mr_m4_1 are the partitions and memory regions assigned to the M4.
pt_sh and mr_sh are the shared partition and memory region.
A shared partition is created but it can only have a shared memory region. Pads and resources CANNOT BE SHARED there is no mechanism to protect the pads and resources from contention, if access to a resource is required by multiple partitions a virtual resource needs to be created, in this way the partition that requires access asks the partition that owns the resource to configure/use the resource on its behalf. See the VIRT_I2C example on the Linux BSP.
The partition that hosts all remaining resources is the pt_boot partition, this can be seen as the A cores partition, all resources and memory regions not assigned to the M4 partitions will be left on the pt_boot partition where the A cores are.
The code is documented well and self-explanatory, for instance the following line marks all resources within the M4_0 subsystem to be moved to the M4_0 partition:
/* Mark all M4_0 subsystem resources as movable */
BRD_ERR(rm_set_subsys_rsrc_movable(pt_boot, SC_R_M4_0_PID0,
SC_TRUE));
BRD_ERR(rm_set_pad_movable(pt_boot, SC_P_M40_I2C0_SCL,
SC_P_M40_GPIO0_01, SC_TRUE));
The resource list in the sc_fw_api_qm_b0.pdf document shows what resources belong to the M4 subsystem:
Next some other resources required by the M4 are assigned to its partition, such as MUs used to communicate with the other cores, timers and the IRQ steer resource.
In this case we are interested on having the FlexCAN resources/pads on the A cores side, these resources/pads are being assigned to the M4_1 partition as can be seen on the previous partitions dumps and the following code:
/* Move some resources not in the M4_1 subsystem */
BRD_ERR(rm_set_resource_movable(pt_boot, SC_R_IRQSTR_M4_1,
SC_R_IRQSTR_M4_1, SC_TRUE));
BRD_ERR(rm_set_resource_movable(pt_boot, SC_R_UART_2,
SC_R_UART_2, SC_TRUE));
BRD_ERR(rm_set_pad_movable(pt_boot, SC_P_UART0_CTS_B,
SC_P_UART0_RTS_B, SC_TRUE));
BRD_ERR(rm_set_resource_movable(pt_boot, SC_R_MU_6B,
SC_R_MU_6B, SC_TRUE));
BRD_ERR(rm_set_resource_movable(pt_boot, SC_R_MU_7B,
SC_R_MU_7B, SC_TRUE));
BRD_ERR(rm_set_resource_movable(pt_boot, SC_R_MU_9B,
SC_R_MU_9B, SC_TRUE));
BRD_ERR(rm_set_resource_movable(pt_boot, SC_R_GPT_3,
SC_R_GPT_3, SC_TRUE));
BRD_ERR(rm_set_resource_movable(pt_boot, SC_R_CAN_0,
SC_R_CAN_2, SC_TRUE));
BRD_ERR(rm_set_resource_movable(pt_boot, SC_R_FSPI_0,
SC_R_FSPI_0, SC_TRUE));
/* Move some pads not in the M4_1 subsystem */
BRD_ERR(rm_set_pad_movable(pt_boot, SC_P_FLEXCAN0_RX,
SC_P_FLEXCAN2_TX, SC_TRUE));
BRD_ERR(rm_set_pad_movable(pt_boot, SC_P_QSPI0A_DATA0,
SC_P_COMP_CTL_GPIO_1V8_3V3_QSPI0, SC_TRUE));
Previous dump:
*** Resources ***********************************
Partition: 4
M4_1_PID0
UART_2
CAN_0
CAN_1
CAN_2
IRQSTR_M4_1*** Pads ****************************************
Partition: 4
M41_I2C0_SCL
M41_I2C0_SDA
M41_GPIO0_00
M41_GPIO0_01
UART0_RTS_B
UART0_CTS_B
FLEXCAN0_RX
FLEXCAN0_TX
FLEXCAN1_RX
FLEXCAN1_TX
FLEXCAN2_RX
FLEXCAN2_TX
So we just need to remove the following lines from the board.c:
BRD_ERR(rm_set_resource_movable(pt_boot, SC_R_CAN_0,
SC_R_CAN_2, SC_TRUE));
BRD_ERR(rm_set_pad_movable(pt_boot, SC_P_FLEXCAN0_RX,
SC_P_FLEXCAN2_TX, SC_TRUE));
That way the resources/pads won't be marked to be moved to the M4_1 partition and they will be left on the pt_boot partition (A core partition). If a resource needs to be added to the M4 partition just add the calls to rm_set_resource_movable to assign it.
Now we just need to rebuild the scfw and our image:
make qm R=B0 B=mek M=1
Then on mkimage (with the flags set modification above):
make SOC=iMX8QM flash
Flash the sd card with the new image:
sudo dd if=iMX8QM/flash.bin of=/dev/mmcblkXX bs=1k seek=32
Now when the dump is done we can see that the FlexCAN resources and pads belong to the same partition as the A cores (partition 6).
*** Resources ***********************************
Partition: 6
FTM_1
CAN_0
CAN_1
CAN_2DMA_1_CH0
*** Pads ****************************************
Partition: 6
COMP_CTL_GPIO_1V8_3V3_GPIOLHT
FLEXCAN0_RX
FLEXCAN0_TX
FLEXCAN1_RX
FLEXCAN1_TX
FLEXCAN2_RX
FLEXCAN2_TXCOMP_CTL_GPIO_1V8_3V3_GPIOTHR
The device tree would still need to be modified to configure the pads and FlexCAN resources.