Introduction
Various resources of the SOC like the number of DMA channels, number of interrupt router outputs, number of interrupt aggregator virtual interrupt numbers etc. are usually managed by a resource management system or a resource manager.
In the case of AM62PX devices, this is managed by the DM Firmware (Divice Manager Firmware) running on the WKUP R5 / DM R5 core. Once the DM firmware is loaded on DM R5 and is initialized, it will read a certain configuration data regarding the resources we would be using. Rom bootloader (RBL) should have loaded this as part of bootflow. This is largely an array of resource assignment entries, with each entry specifying the start number of the resource, count or number of resource needed, type of resource, host id of the core which will request for this resource, etc. Later when the request for a specific resource is made, the DM firmware will cross check the request parameters with this already sent configuration data, and the requested resources will only be allocated if that falls within the range in this configuration data. We call this the Resource Management Board Configuration or RM boardcfg.
Refer TISCI documentation for more details on the RM board configuration.
Changing a particular resource
- RM Boardcfg is stored in a C file
{SDK_ROOT_DIRECTORY}\source\drivers\sciclient\sciclient_default_boardcfg\
am62px\sciclient_defaultBoardcfg_rm.c
. Ultimately this file needs to be changed and rebuilt for the boardcfg change to take effect.
- This file is autogenerated using a SysConfig based GUI tool (K3 Respart Tool). This tool can be invoked from the commandline. To invoke the tool, run the following from the SDK root directory:
make -s -C tools/sysfw/boardcfg configure SOC=am62px
Resource Partitioning Tool
- Any changes required for any of the resources can be changed using the GUI and doing a File->Save (Ctrl-S) saves it to a *.syscfg file inside the tool.
- Once you have identified for which host you need to assign resources to, and the resource type which you want to modify, click on that particular host to see the currently assigned resources
- A host is defined as a logically distinct high level software entity along with a particular security status. This is mostly a particular piece of software running on a physical core.
- In the RTOS world this does not have a lot of significance, where mostly it is going to be one piece of software which is going to run in a core - be it a bare-metal application or an RTOS based one. In linux/HLOS, it is possible that a core has multiple SW entities running, mostly as VMs.
- In a case where a security firmware and the Linux OS is running in the same core, both these SW entities would be considered as different hosts, because of the difference in security status.
- Each of these 'hosts' are given an ID by the SYSFW:
- Here is the host id to core mapping:
HOST ID | Core |
TISCI_HOST_ID_TIFS (0U) | TIFS ARM Cortex M4 |
TISCI_HOST_ID_A53_0 (10U) | Cortex A53SS0_0 (Secure Context) |
TISCI_HOST_ID_A53_1 (11U) | Cortex A53SS0_0 (Secure Context) |
TISCI_HOST_ID_A53_2 (12U) | Cortex A53SS0_1 (Non-Secure Context) |
TISCI_HOST_ID_A53_3 (13U) | Cortex A53SS0_1 (Non-Secure Context) |
TISCI_HOST_ID_A53_4 (14U) | Cortex Cortex A53SS0_0 (Non-Secure Context) |
TISCI_HOST_ID_MCU_0_R5_0 (30U) | Cortex MCU R5 (Non-Secure Context) |
TISCI_HOST_ID_MAIN_0_R5_0 (35U) | Cortex R5FSS0_0 (Secure Context) |
TISCI_HOST_ID_MAIN_0_R5_1 (36U) | Cortex R5FSS0_0 (Non-Secure Context) |
TISCI_HOST_ID_MAIN_0_R5_2 (37U) | Cortex R5FSS0_0 (Secure Context) |
TISCI_HOST_ID_MAIN_0_R5_3 (38U) | Cortex R5FSS0_0 (Non-Secure Context) |
TISCI_HOST_ID_DM2TIFS (250U) | DM2TIFS(Secure): DM to TIFS communication |
TISCI_HOST_ID_TIFS2DM (251U) | TIFS2DM(Non Secure): TIFS to DM communication |
TISCI_HOST_ID_HSM (253U) | HSM (Secure) |
TISCI_HOST_ID_DM (254U) | DM(Non Secure): Device Management |
Refer TISCI Host descriptions
- For all general purpose use-cases in RTOS, you would want to allocate resources to the non-secure host. Secure hosts in RTOS are reserved special softwares like the secondary bootloader which would need elevated security privileges to perform actions like opening firewalls, booting other cores etc.
Resource Allocation
- You can decrease/increase the number of resources.There are hard restrictions to certain resources. As long as your assignments are within the restrictions, you can change the configuration in the way which suits your application. The tool will throw an error if any of resources exceed their allowed number.
Resource Exceeding Allowed Limits
- Resources can be shared between hosts, but at most 2 hosts can have the same resource. To share a resource, a resource sharing entry needs to be added in the GUI tool.
Resource Allocation Entry
- After the resource is shared, it will show up as an info under the resource.
Resource Allocation Info
- To generate the actual C file from this config file, run the following from the SDK root directory once you have saved the config in GUI:
make -s -C tools/sysfw/boardcfg configure-gen SOC=am62px
- That should update the
{SDK_ROOT_DIRECTORY}\source\drivers\sciclient\sciclient_default_boardcfg\{SOC}\sciclient_defaultBoardcfg_rm.c
file.
Rebuilding the board configuration
- Once the changes are made in the file and sciclient_defaultBoardcfg_rm.c is generated, Re-build the boardcfg binary blob by running the following from SDK root directory:
make -s -C tools/sysfw/boardcfg sciclient_boardcfg SOC=am62px