• State TI Thinks Resolved
  • Locked Locked
  • Replies 1 reply
  • Answers 1 answer
  • Subscribers 98 subscribers
  • Views 819 views
  • Users 0 members are here
Support feedback
Options
Options
Related

This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

TDA4VM: Resource Reallocation Using RESPART for Interrupt Routing

Can Aksoy
Prodigy 35 points
Part Number: TDA4VM


Tool/software:

Hello,

I am currently working with SDK version 10_00_00_05 (the latest version) and using the RTOS SDK. I understand that if dst_host_irq exceeds 160+31, the corresponding interrupt will not be routed to MCU1_0 but instead to MCU1_1. In my case, I need to adjust this configuration and reallocate the resources accordingly.

I’ve come across the "RESPART" tool in this entry, which I believe is intended for resource reallocation. However, I would appreciate a thorough explanation of the steps involved in this process. Specifically, I am looking for guidance on the following:

  1. How to reallocate resources using RESPART – A step-by-step breakdown of the procedure would be very helpful.
  2. Changes to configuration files – How many files will be affected by the reallocation, and which ones should I expect to modify?
  3. File placement – Once the reallocation is completed, will there be a need to copy the generated files to specific directories? If so, which paths are involved?

Any detailed insight or references to relevant documentation would be greatly appreciated!

Thank you in advance for your help.

  • 0
    TI__Guru** 115435 points

    Hi Can,

    Can Aksoy said:
    I am currently working with SDK version 10_00_00_05 (the latest version) and using the RTOS SDK

    I am assuming then that you are using the RTOS-based SBL for the bootloader.

    Can Aksoy said:
    I understand that if dst_host_irq exceeds 160+31, the corresponding interrupt will not be routed to MCU1_0 but instead to MCU1_1.

    Are you going to be using the MCU R5F cluster in Split-mode to begin with? The MCU R5F is typically the Safety Master core, and is used in LockStep mode, which makes the resource assignments for MCU1_1 moot in general. The TI SDK is generic and the default configuration is to allow all the R5F clusters to be run in Split-mode with the same BootLoader, as this resource configuration is part of the BootLoader, 

    Can Aksoy said:
    I’ve come across the "RESPART" tool in this entry, which I believe is intended for resource reallocation. However, I would appreciate a thorough explanation of the steps involved in this process. Specifically, I am looking for guidance on the following:

    The K3 Resource Partitioning Tool is indeed the graphical tool to assign and visualize the various common resource allocations/partitioning between a number of processor cores.

    Can Aksoy said:
    How to reallocate resources using RESPART – A step-by-step breakdown of the procedure would be very helpful.

    This is all documented in the Linux SDK 4.1.18. K3 Resource Partitioning Tool section. It is recommended that you import the existing configuration and then modify rather than starting over from scratch.

    Can Aksoy said:
    Changes to configuration files – How many files will be affected by the reallocation, and which ones should I expect to modify?

    The resource allocation data is part of the RM Board Configuration data files, and is reflected in the sciclient_defaultBoardcfg_rm.c file.

    Can Aksoy said:
    File placement – Once the reallocation is completed, will there be a need to copy the generated files to specific directories? If so, which paths are involved?

    The existing file in the PDK sciclient directory needs to be replaced with the updated file.

    Please see the 8.1.4. BoardCfg RM section of the PDK documentation to update your RM board configuration. The script takes care of performing all the needed build steps.

    The board configuration process typically requires you to rebuild/regenerate the board configuration data (sciclient_boardcfg/sciclient_boardcfg_hs and sciclient_direct/sciclient_direct_hs libraries depending on GP vs HS device types) and the corresponding SBL libraries and SBL bootloader binaries (eg: sbl_lib_mmcsd/sbl_lib_mmcsd_hs and sbl_img_mmcsd/sbl_img_mmcsd_hs for SDCard boot).

    regards

    Suman