• State
  • Locked Locked
  • Replies 4 replies
  • Subscribers 103 subscribers
  • Views 2574 views
  • Users 0 members are here
Support feedback
Options
Options
Similar topics

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.

AM335x Enabling and disabling the L2 cache controller

Devin Sale
Prodigy 30 points
Other Parts Discussed in Thread: AM3352

I am using LINUXEZSDK-AM335X v07.00 with a custom board that uses a DRA608BIZCZ (equivalent to AM3352, correct?) and have some questions about L2 cache.

I've instrumented u-boot's startup code and determined that L2 cache is enabled prior to u-boot's reset vector.
Reading the auxiliary control register at the start of board_init_f shows that the L2EN bit is set. 
When I clear L2EN in cpu_init_cp15, it stays cleared. i.e. printf of aux control reg prior to main_loop() shows L2EN bit is set.

It appears that the ROM code is enabling L2 cache prior to public boot.

Q1.  Is that expected?

I understand from the AM335x TRM that the ROM code L1 cache is disabled, but there's no mention of L2.

The L2 cache section in ARM's Cortex A8 TRM has this note

http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.ddi0344k/Babigfeh.html

Note
To keep memory coherent when using cache maintenance operations, you must follow the L2 cache disabling sequence. Cache maintenance operations have an effect on the L1 and L2 caches when they are disabled. A cache maintenance operation can evict a cache line from the L1 data cache. If the L2EN bit is set to 1, the evicted cache line can be allocated to the L2 cache. If the L2EN bit is not set to 1, then evictions from the L1 data cache are sent directly to external memory using the AXI interface.

Q2.  Is this a concern?

Q3.  Where is the kernel code that controls L2EN ?

I've looked at the kernel code and could not find any place where it is toggling the L2EN bit in the AM355x configuration.

  • 0
    TI__Expert 7155 points

    Devin,

    Regarding Q1: L2EN is set to 1 by default at reset. ROM code doesn't touch it.

    Whether L2 cache is actually enabled or not depends on state of I & C bit of the c1, Control Reg per Table 3.48.

    The I & C bits are set to 0 @ reset by default to disable instruction & data caches & this means that L2 cache is also disabled per the Table.

     

     

  • 0 in reply to Mark Utter
    Prodigy 30 points

    Thanks Mark

    Q1.  When I read the instructions for enabling after a reset it says "set the L2EN bit to 1".  Guess I was blinded by that.

    On Q2, Forgot to mention in the original post that u-boot leaves L2 cache enabled on the jump to Linux after L1 is invalidated and disabled.

    That qualifies as a maintenance operation.  Does that make it possible for an evicted cache line to stick in L2 per the description?

  • 0 in reply to Devin Sale
    Prodigy 30 points

    Q2.  Likewise, within u-boot's c_runtime_cpu_setup routine, L1 I cache is invalidated, but L2 is still enabled.

  • 0 in reply to Devin Sale
    Mastermind 8020 points

    Is it normal and expected for the L2EN bit (which, btw, is not banked, contrary to what the cortex-A8 TRM says) to be set at all times.  Afaik all caches are cleared after reset by the initialization code in secure ROM.  As the table Mark Utter shows, no L1 data caching nor any kind of L2 caching occurs as long as the 'C' bit of the control register is cleared, which it is by default at the start of public ROM and will stay that way until the OS enables it (you need to configure and enable the MMU before you're allowed to set the C-bit, otherwise erratic behaviour can be expected).  This means the only cache-related concern during bootloading is clearing of the L1 instruction cache after loading new code into memory, which u-boot will do.

    The only worry about stale data in caches exists when for example loading new code onto the CPU via JTAG after it has already previously booted, without resetting the system.  There are various solutions to this, such as always resetting the target before loading new code, cleanly exiting/halting the OS/app (and making sure this includes code to disable/clear the caches and MMU), or performing appropriate cache maintainance via debug server scripting as part of the upload procedure.