• State
  • Locked Locked
  • Replies 6 replies
  • Subscribers 100 subscribers
  • Views 846 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: MSMC registers access rights / procedure

user6432699
Prodigy 80 points
Part Number: TDA4VM

Hello,

For our application, we need to configure the MSMC to optimize data transfers / paths between the A72 & R5 cores and the MSMC SRAM.
We are using a TDA4VM (J721EVM).

For now, we start the J7 in "NO-BOOT" mode and the initialization is done per debugger script (from CCS1020 / Blackhawk by using ...\ti\drv\sciclient\tools\ccsLoadDmsc\j721e\launch.js, or from Lauterbach Trace32 with similar script).

From the Main Domain R5F_0 ("MCU2_0"), we can read the MSMC registers (e.g. the MSMC_CACHE_CTRL / 0x6E000000, MSMC_RT_WAY_SELECT / 0x6E001010), but by writing them the processor generates an exception (jumps to 0x00000010, "Abort (data)"). The same exception occurs by writing the MSMC registers with the debugger.

I suppose that the MSMC registers must be written only in a specific processor state. But unfortunately, in the TRM we did not found the pre-conditions to access the MSMC registers - searched in chapter 8.1 MSMC, 4. Initialization, and 5. Device Configuration. (Are there any other relevant chapters or documents to be explored?)

What should be the right procedure to set the MSMC registers?
Is it possible to set the configuration state or to change the registers values from the debugger (Blackhawk or Lauterbach Trace32) after the J7-boot phase, firstly to make some performance tests?

Many thanks in advance
Lad

  • 0
    TI__Mastermind 23615 points
    Hello,
    It appears like you are likely trying to adjust the L3 cache size or a related parameter.  In the debugger flows you mention this is access is done by the firmware which is run as part of the launch.js flow on the system manager core. This will be a one time only setting. You can see from older E2E questions and from the online documentation the procedure needed to access the registers.
    Its expected these registers will be setup by the system firmware during early boot.  Later settings if hacked (by skipping setup in the DMSC-M3) tend to result in a non-working system for one reason or the other.
    Regards,
    Richard W.
  • 0 in reply to Richard Woodruff
    Prodigy 80 points

    Hello Richard,

    thanks for your reply.

    In the pointed docs, it is only explained how to change the CACHE_CTRL register, and only by the means of the TISCI.

    I took much time to search forwards in the SDK documentation, and also to search in the SDK / PDK directly in the source files, in order to find a way to configure the other registers (a.o. MSMC_RT_WAY_SELECT). Unfortunately, I did not found nothing how to program the configuration directly from the DMSC-M3 core.

    Do you know where I can find documentation to do that?

    Thanks a lot

    Best regards, 

    Lad

  • 0 in reply to user6432699
    TI__Guru** 113810 points

    Lad,

    The DMSC M3 core is not publicly, only the firmware binary is part of the SDK release.

    You can find the TISCI API documentation at this link: https://software-dl.ti.com/tisci/esd/latest/index.html

    I will let Richard confirm if he has suggestions on how to program MSMC_RT_WAY_SELECT, if not we will internally reach out to others in the team and provide this information.

    Regards

    Karthik

  • 0 in reply to Karthik Ramanan
    Prodigy 80 points

    Hello Karthik, hello Richard,

    could you make progress on this topic?

    Thanks for the link to the TISCI API. But as far as I've understood, by this mean we can only access the MSMC CACHE_CTRL register.

    Note that the setting of the MSMC_RT_WAY_SELECT / MSMC_NRT_WAY_SELECT registers will be not enough to comply with our needs. We will probably have to set among other the starvation bound registers, maybe other ones too. This is why I've asked to have a global solution to access (write) all the MSMC registers.

    Regards

    Lad

  • 0 in reply to user6432699
    TI__Mastermind 23615 points
    Hello Lad,
    It seems this question dropped down in my stack. Sorry for the late reply. I believe your analysis and what Karthik have stated about access is correct.  This register will need to be set early at about the same time as the CACHE_CTRL.  The setting will have to be made before first accesses and the address space it exists in is controlled by the firmware and it can be firewall protect them. I do not see an entry in the boardcfg_msmc for this.  I suspect this structure may need to be extended on an additional API added for the RT setup. As you have seen, JTAG writes before firmware executes can allow for experiments to help figure out a setting but something codeable would be needed.
    I am wondering how much your application concept will benefit from using this feature.  Execution on an A72 cluster running something like Linux can have a lot of jitter and while these types of traffic shaping knobs can help their will be a limit how much can be realized.  If you are running an RTOS and controlling all the code the chances of it panning out seem higher.
    Regards,
    Richard W.
  • 0 in reply to Richard Woodruff
    Prodigy 80 points

    Hallo Richard, Hello Karthik,

    OK, many thanks for these explanations.

    Yes, we are using a RTOS, not Linux.

    As conclusion: we thus need to have access to the configuration of the processor done at the M3-level (a.o. for certification reasons), and in particular to have access to the MSMC configuration registers. How can we get the documentation to program the DMSC-M3 by ourself, and if possible the source-code of the current Firmware running on the M3?

    Regards

    Lad