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.

DM3730: Issue with L1 Dcache with L2EN=0

Part Number: DM3730

So I have the MMU and Dcache enabled (C-bit=1, M-bit=1, and L2EN=0) and I have the page tables set up for writeback and full-access (AP=11b, TEX=000b, C=1, B=1, bits[1:0]=10b).  If I do a read (to load a cacheline into L1 Dcache), then do a single word store to the same cacheline, I expect the L1 Dcache to hold valid and dirty data.  If I then disable the C-bit, and read the location, I expect to read the value from SDRAM which should be the old data.  This is not what I get.  In all cases (with or without the L2 enabled), the L1 (and the L2) act like they're in writethrough and the stores always make their way to SDRAM.

I believe it's true that I have to have the MMU enable to use the L1 Dcache (although the TRM is not clearly stating that).  I'm wondering if it's true that the page table C and B bits are actually the bits which tell the cache to operate as writethrough or writeback, or if there's some other cfg bits I haven't yet discovered.  These are the relevant pages upon which I'm basing my assertions:

  • Hi Eric,

    Do you mean Cortex-A8 TRM at:
    infocenter.arm.com/.../DDI0344K_cortex_a8_r3p2_trm.pdf
    Could you specify which section of it needs additional clarifying.

    BR
    Tsvetolin Shulev
  • I just wanted to confirm my understanding that if the C and B bits in the page table entry are 11b the caches will operate as writeback and if they are 10b, the caches will operate as writethrough (TEX=000b) and that I can operate the MMU M-bit=1 with C-bit=0 in the control register.  I'm just trying to prove that I can write data to the L1 data cache, disable it, then read old data from SDRAM.  All of this with L2EN=0.  I've had some trouble with the CPU locking up (some unhandled exception since, at this point, I have no exception handling) when I clear the C-bit=0.

  • Eric,

    Yes, your understanding seems correct.

    BR
    Tsvetolin Shulev
  • So what I've discovered is that if I do not clean and invalidate the dcache at all levels, then the CPU locks up (not sure if it's an exception or what, I'm just in u-boot at the time).  So there must be some unspecified requirement to clean and invalidate the dcache before disabling the C-bit and M-bit.  It's not clear in the spec why this is the case.

    I'm wondering if there is some issue where there's a hit in a Dcache which is disabled (by having C-bit and M-bit cleared) and the load never completes.  The spec indicates this should not happen, but nonetheless something has gone awry.  I tried just to invalidate the Dcache without cleaning it, but that also locked up.  I don't know if the TI folks monitor these boards.  This is a bit of a conundrum for me in trying to implement my solution.