• State
  • Locked Locked
  • Replies 2 replies
  • Subscribers 101 subscribers
  • Views 386 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.

PROCESSOR-SDK-AM57X: Linux/remoteproc: Loading sections to L1D/L1P does not work properly due to default cache configuration

Butters
Expert 2021 points

Part Number: PROCESSOR-SDK-AM57X

Hello, support for loading sections to AM57x L1D/L1P memory via remoteproc was added to Linux in the following commit authored by s-anna@ti.com:

https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=0aaf19130262059591be51bb745b59788a18c24c

A problem that I am running into is that, by default, the AM57x DSP cores have their L1D/L1P SRAM configured as "all cache" (see registers L1DCFG and L1PCFG in the TRM). In general, a user would work around this by running a small piece of code that changes those registers so that L1D/L1P are treated as normal SRAM; this would be done prior to whatever bootloader is being used. However, in the case of using remoteproc, the remoteproc driver places the DSP core into a reset state prior to loading the firmware sections to memories. This reset state returns the L1D/L1P cache configuration to "all cache." Therefore, I have not been able to find a way (short of modifying remoteproc itself) to disable the L1D/L1P caches prior to loading the firmware sections.

Best regards,
Dave

  • 0
    Expert 2021 points

    I have been trying for a couple of days to come up with some workaround for this without modifying remoteproc, but have not been able to. One of the data sections that I need to allocate to L1D memory is the DSP system stack (.stack). Even though _c_int00() disables L1 cache (as instructed by my RTSC platform), there are still accesses to the stack (register B15) in _c_int00() prior to the L1D cache being disabled. I am concerned that any read or write to L1D while it is configured as cache could cause some of its contents (which were loaded by remoteproc) to be "stomped" by the operation of the cache.

  • 0
    Expert 2021 points

    I have one idea, but I am not sure if I can trust it to work reliably in practice, and would need some feedback from TI regarding it. Suppose that I write a custom entry point in assembly that configures L1DCFG and L1PCFG to turn off caching. After configuring those registers, the assembly branches to _c_int00 to continue booting the DSP normally. I specifically have the following questions:

    1. If the custom entry point were itself loaded to L1P and run from L1P, would this cause an L1P cache "miss" to occur? In other words, I am not sure how the L1P cache behaves in the situation where the DSP program counter is actually pointing into L1P itself.
    2. If the custom entry point does not access data from any memory -- only core registers and the L1DCFG and L1PCFG registers themselves -- could this cause any L1D cache "miss" to occur? I would think not...

    My hope is that even though remoteproc loads the L1D and L1P memories while they are still configured as cache, but my custom entry point does not cause either an L1D or L1P cache "miss" to occur, then this will be a valid workaround that does not involve any modification of remoteproc itself.

    I am looking forward to feedback from TI regarding this possibility.

    Thanks,
    Dave