System Controller Firmware 101 - Resource management service

Document created by manuelrodriguez Employee on Sep 20, 2018Last modified by manuelrodriguez Employee on Feb 6, 2019
Version 3Show Document
  • View in full screen mode

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:

  • At boot time by modifying the function board_system_config on the board.c portion of the SCFW porting kit that corresponds to your board. This is used for software that is loaded as part of the boot process.
  • At run time by calling the resource management service functions available. This is used to partition software that is launched by an operating system, e.g. an M4 used as sensor fusion and loaded/started by Linux.

 

A partition can have:

  • Resources (peripherals)
  • Pads
  • Memory regions

All of the items mentioned above can be grouped within a partition.

 

It is important to note that:

  • At boot time all resources are grouped into a single partition.
  • Resources can only be assigned to another partition by a resource within it's own partition. 

 

Initial partitioning state of the system

At boot time the system is initially configured in three partitions:

  • The first partition (SCFW) contains all the resources, pads and memory required by the System Controller Unit (SCU) to execute the System Controller Firmware.
  • The second partition (SECO) contains all the resources required by the Security Controller to execute.
  • The third partition (Boot) contains all of the remaining resources, pads and memory available for the whole system.

 

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.

 

Resource partitioning - Boot time configuration

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.

 

Here are a few important points to highlight:

  • The code will only execute if the SC_BD_FLAGS_ALT_CONFIG is set under the boot flags (more details in the Usage chapter of the sc_fw_port.pdf), the flags are set while building the image with mkimage. An example is provided to build an image with partitioning enabled:
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.

 

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.

 

  • The function rm_dump(pt_boot); dumps the partitioning state of the whole system, it can be called before and after the partitioning to make sure the device was partitioned as expected. Here is how a partition dump looks like:
*** 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:

  • Secure - boolean indicating if this partition should be secure; only valid if caller is secure
  • Isolated - boolean indicating if this partition should be HW isolated; set SC_TRUE if new DID
    is desired
  • Restricted - boolean indicating if this partition should be restricted; set SC_TRUE if masters in this
    partition cannot create new partitions
  • Grant - boolean indicating if this partition should always grant access and control to the parent
  • Coherent - boolean indicating if this partition is coherent; set SC_TRUE if only this partition will contain
    both AP clusters and they will be coherent via the CCI

 

The rest of the sections of the dump highlight all the resources, pads and memory regions enclosed in each partition.

 

  • For more details on the definition of all the API calls please refer to the respective sc_fw_api document for each SoC variant.

 

Resource partitioning - Run time configuration 

 

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. 

 

System Controller Firmware 101 

1 person found this helpful

Attachments

    Outcomes