User mode ASM sceKernelDcacheWritebackInvalidateAll

[cswindle]

Whilst trying to get the TIFF's more reliable for eLoader, we worked on getting an assembly version of sceKernelDcacheWritebackInvalidateAll and based on this thread http://forums.ps2dev.org/viewtopic.php? ... ight=cache, we determined that it should be possible to do the functionality that we required in user mode. We found that in sceKernelDcacheInvalidateAll the only thing that would not work in user mode was getting the size of the cache, therefore we need to hardcode this in the procedure. This is what we ended up using as a basis for the new tiff:

Code: Select all

void asmKernelDcacheWritebackInvalidateAll(void) 
{ 
   asm(".set    noreorder\n" 
      "move      $t0,  $0\n" 
      "addiu     $t1,  $0, 0x4000\n" 
      "loop:\n" 
      "cache     0x14, 0($t0)\n" 
      "addiu     $t0,  $t0, 0x40\n" 
      "bne       $t0,  $t1, loop\n" 
      "cache     0x14, -0x40($t0)\n" 
      "sync"); 
}

The above code should be able to run on all firmwares and makes life easier when you do not have syscalls available, but you need to clear the cache. I would expect that the same could be done very easily with icache.



Chris

[hlide]

why do you need to invalidate twice a cache entry at each iteration ?

[hlide]

Can you explain why you need to invalidate all d-cache entries for you TIFF loader ? I dunno if you TIFF loader uses stack overflow but what you need in fact is to WRITEBACK d-cache (overflow stack being in d-cache) then to INVALIDATE i-cache so you can run instructions poked in the stack.

If you only invalidate (that is without writeback) some data modified in d-cache would not be written back to real memory and arises some incoherencies when trying to run them.

On the contrary, if you only need to be sure that d-cache contents are written back to real memory simple d-cache writebacks can be done instead of invalidating them too. the code is : "cache 0x1A, 0($t0)", if i'm not wrong.

Maybe what you want to do is :

Code: Select all

void asmKernelSyncICacheAndDcache(void)
{
   asm(
      ".set push\n"
      ".set noreorder\n"
      "move $t0, $0\n"
      "addiu $t1, $0, 0x4000\n"
      "0:\n" // avoid to name loop if you plan to inline this function 
      "cache 0x1a, 0($t0)\n" // D-cache writeback
      "addiu $t0, $t0, 0x40\n"
      "bne $t0, $t1, 0b\n"
      "cache 0x08, -0x40($t0)\n" // I-cache invalidate
      "sync\n" // reason to do so ?
      ".set pop"
   );
}

[jonny]

why do you need to invalidate twice a cache entry at each iteration ?

i suppose it's because the cache is 2-way set associative

[hlide]

why do you need to invalidate twice a cache entry at each iteration ?

i suppose it's because the cache is 2-way set associative

okay, I think I can understand why now. I thought a cache instruction would affect ALL candidates and not only the FIRST candidate. But I do remember now to have seen an assembly code where cache instructions were executed twice and I was wondering why. It makes sense, you cannot simultaneously write back two entries having the same index in the main memory. Thx for this piece of information, I probably need to update my codes with this fact.

[cswindle]

Can you explain why you need to invalidate all d-cache entries for you TIFF loader ? I dunno if you TIFF loader uses stack overflow but what you need in fact is to WRITEBACK d-cache (overflow stack being in d-cache) then to INVALIDATE i-cache so you can run instructions poked in the stack.

It was meant to be sceKernelDcacheWritebackInvalidateAll (I have updated the main post). As far as clearing the i-cache, there was no need for us to clear the cache because of the way we were using it.


Chris