Modifying resource allocation

Table of Contents

• Introduction
• Changing a particular resource
• Rebuilding the board configuration

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

Note

At the moment the changes need to made manually by editing C files, but soon a Sysconfig GUI based tool will be available to generate this C file.

• To change the assigned number of a particular resource, the sciclient_defaultBoardcfg_rm.c file at path {SDK_ROOT_DIRECTORY}\source\drivers\sciclient\sciclient_default_boardcfg\am62ax\ location.
• Around line 100 of the file, you should find a line which says .resasg_entries = {. This is an array of resource assignment entries. Resource assignment entries are structs with members
  • num_resource (Number or Count of resources)
  • type (Type of resource, can be DMA channel, or Interrupt Router Output, etc.)
  • start_resource (Starting number of the resource)
  • host_id (Host ID of the core which can request for this resource)

Resource Assignment Entries

• Once you have identified the resource type which you want to modify, you can see if an entry with that type is already part of the array. If yes, you can go ahead and make the changes directly depending on what you want to do. Change the start number, decrease/increase the number of resources etc. Make sure that resources do not overlap when you change this. Another thing to take care is the host_id in the entry you make. If you add the entry with the current resource range but with a wrong host_id, your host won't be able to request for that particular resource. For each core present in the SoC, there will be two host types - Secure and Non-Secure. These host ids are defined in {SDK_ROOT_DIRECTORY}\source\drivers\sciclient\include\tisci\am62px\tisci_hosts.h file.
• 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

• If the resource type required is not present in the array, you need to add this entry and give all the four parameters described above. In this case, make sure that you change the folloing number.

Resource Assignment Entries Size

Rebuilding the board configuration

• Once the changes are made in the file, we need to generate a hex array corresponding to the file and make sure that the bootloader libraries and the sciclient_set_boardcfg application are updated with these changes. For this one can follow SYSFW Board Config Generation section