Unlocking data cache in MPC5674F

[ricardofranca]

Hello,

While doing some experiments with a custom-made hardware that runs a MPC5674F, I ran into some trouble while trying to revert a cache-as-RAM configuration in the data cache.

At some point, during initialization, it seems the data cache is configured as a fast RAM with effective address 0x40040000. For the moment, I cannot modify the initialization code, thus I tried to unlock it during software execution but it crashes whenever I try to unlock its ways - either via dcblc instructions or by setting L1CSR0[DCLFC]. Since the hardware is a bit of a black box (it does not have a crash dump and I do not have a proper debugging environment yet), I have no information about the exception that caused the crash.

In spite of all this vague information, I would like to know if anyone has a clue about something I am missing when trying to unlock this cache.

First, there is the MMU and cache configuration code that I cannot modify (please, warn me if the comments are erroneous or useless, I inserted them but I am still trying to figure out how MMUs work):

============
mmu_config:

e_lis r3, 0x1005 /* TLB entry 5 */
mtmas0 r3
e_lis r3, 0x8 /* valid TLB entry */
e_or2i r3, 0x200 /* page size: 16KB */
mtmas1 r3
e_lis r3, 0x4004 /* link to address 0x40040000? */
mtmas2 r3
e_lis r3, 0x4004 /* link to address 0x40040000? */
e_or2i r3, 0xf /* can read and write in user or supervisor mode */
mtmas3 r3
se_isync
tlbwe
msync
se_isync
============

Then, dcache is invalidated (I am omitting this code because it looks simple). After it is all invalid, it is then enabled and locked:

============
dcache_enable:

e_lis r3, 0x10 /* copyback */
e_or2i r3, 0x1 /* turn dcache on */

dcache_lock:

e_li r3, 512 /* looping over all 512 lines */
mtctr r3
e_lis r3, 0x4004 /* starting with EA 0x40040000 */
loop:
dcbz 0, r3 /* allocate EA to a dcache line and assign 0 to the entire line */
dcbtls 0, r0, r3 /* load cache line and lock it */
e_addi r3, r3, 32 /* go to next block till we map to cache all 16KB starting at 0x40040000 */
e_bdnz loop
============

So far, so good. The code above seems to be working fine.

Finally, there is my own code. I made sure (at least, I tried to) nothing is mapped to the data cache before trying to reconfigure it. My first unlocking attempt was:

============
.globl UnlockDCache
.type UnlockDCache, @function
UnlockDCache:
unlock_start:
e_li r4, 0x100 /* L1CSR0[DCLFC] */
mfspr r3, l1csr0
e_or2i r3, 0x100
msync
se_isync
mtspr l1csr0, r3
se_isync
unlock_wait:
mfspr r3, l1csr0
se_and r3, r4
e_cmp16i r3, 0x100
e_beq unlock_wait
cabt_check:
mfspr r3, l1csr0
e_li r5, 4
se_and r3, r5
e_cmp16i r3, 4
e_beq unlock_start
.size UnlockDCache, $-UnlockDCache
============

My second attempt (which didn't work, either) was:

============
.globl UnlockDCacheAlready
.type UnlockDCacheAlready, @function
UnlockDCacheAlready:
e_li r3, 512
mtCTR r3
e_lis r3, 0x4004
dcache_unlocking_loop:
dcblc 0, r0, r3
e_addi r3, r3, 32
e_bdnz dcache_unlocking_loop
.size UnlockDCacheAlready, $-UnlockDCacheAlready
=============

As I said before, both attempts end up with a crash due to some processor exception, I think. What am I missing here?

Thanks for your attention!
Ricardo

[davidtosenovjan · Accepted solution]

Hi, in this example you are configuring MMU to define address range for cache-as-RAM (0x40040000..). In case you would unlock this area, it would destroy content of this cache-as-RAM as it may be replaced by cache line filling operations. However if it is inteded and cache-as-RAM content may be thrown away, you will need to redefine or delete this MMU entry because from that moment it points to nowhere as it is probably the reason of the issue.

I am attaching presentation slide for MMU. And finally there is a link for excel tool user can use for simple configuration of MMU:
https://community.nxp.com/t5/MPC5xxx-Knowledge-Base/MMU-Assist-Register-CONFIGURATOR/ta-p/1110436

Just noting this configurator omits msync instruction before tlbwe that is necessary.

[ricardofranca]

Thanks for your help! Though we ended up rewriting the initialization code, it is useful to know how to redefine MMU entries during runtime.