This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

Cortex-A9 MPCore with L2 Cache Controller (L2C-310)

Note: This was originally posted on 16th July 2012 at http://forums.arm.com

On a quick introduction note, I am working on Cortex-A9 with MPCore configuration where Number of cores is 1. We have L2C- 310 L2 Cache Controller.

[color=#1F497D]This is regarding resolving the issue after enabling L2 cache controller.[/color]

[color=#1F497D]I've followed therecommendation from the L2-310 specification before enabling the L2 Cache.[/color]

[color=#1F497D] [/color][color=#1F497D][A] Invalidate by way, offset0x77c to invalidate all entries in cache; poll cache maintenance register untilinvalidate operation is complete[/color]

[color=#1F497D] [/color][color=#1F497D][B] Write to interrupt clearregister to clear any residual raw interrupts set.[/color]

[color=#1F497D] [/color][color=#1F497D]The following recommendation I havealready taken care in the boot reset code for A9.[/color]

[color=#1F497D] [/color][color=#1F497D][1] Invalidate the data cache (L1)[/color]

[color=#1F497D] [/color][color=#1F497D][2] Invalidate the SCU duplicatetags[/color]

[color=#1F497D] [/color][color=#1F497D][3] Invalidate the L2-310[/color]

[color=#1F497D] [/color][color=#1F497D][4] Enable the SCU[/color]

[color=#1F497D] [/color][color=#1F497D][5] Enable the data cache[/color]

[color=#1F497D] [/color][color=#1F497D][6] Enable the L2C-310[/color]

[color=#1F497D]I enable MMU along with [5]above. For me as soon as I enable the L2 cache [6], the processor startgenerating aborts or sometimes it hangs. If I don't enable L2 Cache (just byskipping [6]), everything seems to be working fine.[/color][color=#1F497D] [/color]

[color=#1F497D]As an alternative steps ortrials, I have tried draining STB, EB, LRB, and LFB after invalidating theL2-310. This also doesn't help. I am also making sure that the L2-Cache isdisabled whenever I attempt any management operation such as invalidate, syncetc. [/color]

[color=#1F497D]There are registers such asauxiliary, Tag RAM Latency, Data RAM Latency, pre-fetch, and power controlregisters which I have working with valid values. [/color]

To me, it looks like I have followed recommendations as suggestion in specification. [color=#1F497D]I am also making sure to set the data endianne[/color][color=#1F497D]ss for L2 Cache controller as per my firmware build. [/color]

[color=#1F497D][Q1] Is there anything I have missed above?[/color]

[color=#1F497D][Q2] Is there any specific page table entries I have to mark explicitly with TEX and C and B (considering outer cache)? I am for the moment left my page table entries as what I have for the L1 Cache (as skipping [6] above leaves the L1 cache enabled and everything works fine). If yes, how does it should be for L1 and L2 Cache together where one region attributes are reflected from both inner and outer cache attributes?[/color]

Thanks

[color=#1F497D]    Vaibhav[/color]

[color=#1F497D]
[/color]

  • Note: This was originally posted on 16th July 2012 at http://forums.arm.com


    What you are doing seems broadly correct. Can you give any details about the aborts (contents of IFAR, IFSR, DFAR, DFSR could be useful)?

    It smells like the L2 is returning bad data, so how are are you that you are correctly invalidating all of it? Can you explain how you are performing the invalidate?


    Thanks for the response.

    It is random from the address but from the Instruction Fault Status register, it appears as Translation Fault "MMU" (not seeing as valid translation for the address). This appears to be working if only L2 cache is disable, keeping L1 enabled. That's the reason I asked whether do I have to change anything in the page table entries for L2 explicitly?

    Regarding invalidating L2 Cache, I am using maintenance operation "Invalidate by Way" Register offset 0x77c where I am putting Way bits to 0xffff and since it is a background operation, I am polling the same register till it becomes 0 again from all ways which confirms that the invalidation is completed.

        Vaibhav




  • Note: This was originally posted on 16th July 2012 at http://forums.arm.com

    On another quick note, I have also tried enabling "Auxiliary Control Register" EXCL bit (Exclusive Cache Bit) using coprocessor instruction on A9 processor and also on cache controller using register at offset 0x104. Though the error was related to translation fault but I thought to attempt this as well for completeness.

        Vaibhav
  • Note: This was originally posted on 16th July 2012 at http://forums.arm.com

    It looks like the issue is random after enabling the L2 Cache. It's doesn't always go to the same error, I am afraid

    Unfortunately, I don't have cache view :-(

    Any suggestions?



  • Note: This was originally posted on 17th July 2012 at http://forums.arm.com


    You mention this is an SMP system, you are not trying to enable the cache twice in parallel from multiples cores by and chance are you? It is obviously a shared resource, so you will usually need to bootstrap CPU0, init the L2, and then start up the other cores.

    My only other thought is to check you have barriers in all of the appropriate places to ensure you are not getting memory accesses leaking across critical instructions.


    No, it's not. As I mentioned above, it is multi-core configuration with single core (i.e. number of cores within Cortex-A9 is set to 1).
  • Note: This was originally posted on 16th July 2012 at http://forums.arm.com

    What you are doing seems broadly correct. Can you give any details about the aborts (contents of IFAR, IFSR, DFAR, DFSR could be useful)?

    It smells like the L2 is returning bad data, so how are are you that you are correctly invalidating all of it? Can you explain how you are performing the invalidate?
  • Note: This was originally posted on 16th July 2012 at http://forums.arm.com

    You mention this is an SMP system, you are not trying to enable the cache twice in parallel from multiples cores by and chance are you? It is obviously a shared resource, so you will usually need to bootstrap CPU0, init the L2, and then start up the other cores.

    My only other thought is to check you have barriers in all of the appropriate places to ensure you are not getting memory accesses leaking across critical instructions.