ME processor : 0x84000000-0x841FFFFF is a RAM-like region

[hlide]

Okay, I played with ME.

I first tried to access this address 0x04000000 on ME processor but get a bus error. I tried to access this another address 0x84000000 and it works ! I can have the value at this address increasing.

Okay what could this address be ? a mirror from 0x80000000 (internal 2MB RAM of ME processor) ? so i tried to increase the value in both addresses and let SC get their values to compare them, they are totally different, so they don't point on the same physical address. Trying to access 0x83FFFFFC and 0x84200000, I got a bus error, so there is a valid address range between 0x84000000 and 0x84200000 non included, 2 MB long. What's the hell may this memory be ? i wonder...

EDIT:
very weird region, it seems only accessible as a cached memory, when trying to access this region as a uncached memory I got a bus error.

EDIT2:

ok, since this region is only accessible via cached memory, I tried to fool the cache by doing it in ME processor :

while (1)
{
...
*pctr2 = vptr2[0];
vptr2[0] = vptr2[0] + 1;
vptr2[0x400] = 0;
vptr2[0x800] = 0;
}

where vptr2 points to 0x84000000;

normally vptr2[0x400] and vptr2[0x800] should discard value of vptr2[0] in cache. Indeed pctr2 doesn't increase anymore whereas it should do so !
weirder i got a value of 0x0000001a.

So we have a phantom RAM between 0x84000000-0x841FFFFF here !

[J.F.]

Well, this is the video ram on the main cpu. Maybe on the ME, you can only access vram through the cached segment.

[hlide]

Well, this is the video ram on the main cpu. Maybe on the ME, you can only access vram through the cached segment.

i don't think so, the fact you lose the data after writing back the cache seems to indicate that you can write on ME cache at this address instead of getting a bus error and read it but still there is no permanent storage where cache could write back if necessary. This is why I talking about a PHANTOM "RAM".

Maybe this region has something to have with a PSP for development purpose and would point to nowhere in a standard PSP.

Or you may need to activate this region to access it properly. Still the fact we don't trigger a bus error is weird in that case.


when ME cache fetches words after forced writeback :
0x84000000 -> 0x0000001a
0x84000004 -> 0x00000000
0x84000008 -> 0x00000000

since I increase their values before forcing ME cache to writeback them, they should increase their value. Instead of that, they are not increasing because their value is seemingly written back to nowhere.

Anyway, i'm quite disappointed, this region has no interest.

[J.F.]

If you don't force the cache, what happens? Maybe this is a special form of scratch pad ram using the cache in the the ME... it gives you XXX amount of space that acts like ram, but is in the cache, so you have a small, VERY fast, section of ram to use for frequent data.

Try writing an increasing number to an increasing address and see if what you read back mirrors after a certain range. Find out how large the area you really can use is.

[hlide]

As I told there is no point to use it because it IS very dangerous. If you don't force the cache and if you're not accessing another address else 0x84000000 which can conflicts in cache , yes its value keeps increasing because nothing is disturbing the cache. But if you use a more complex program which has a better probability to disturb the cache, the value at that address is unreliable. Worse, if you have some asynchronous events occuring (exceptions like SC processor signaling ME processor) you may greatly have an undetermined behavior of the cache too.

as a result, you mustn't rely on a cache contents without a REAL writeback storage to have "a small, VERY fast, section of ram to use for frequent data."

[groepaz]

maybe this is something like "locked cache" on ppc?

[hlide]

maybe this is something like "locked cache" on ppc?

You need to use a cache instruction to do so, and you need to be sure that nothing is calling an INVALIDATE or INDEX UNLOCK cache operation at the same address.

Code: Select all

  // FILL AND LOCK 0x84000000
  asm volatile("cache 0x1F, %0" : : "m"(*vptr2) : "memory");

  while(1)
  {
    long long x;
    for &#40;x = 0; x < 50*1024*1024; x ++&#41;; // sleep a little bit
    &#40;*pctr1&#41; = &#40;*vptr1&#41;; // witness to be sure ME is running
    *vptr1 = *vptr1 + 1;
    &#40;*pctr2&#41; = &#40;*vptr2&#41;;
    vptr2&#91;0&#93; = vptr2&#91;0&#93; + 1; // try to increase its value
    vptr2&#91;0x400&#93; = 0; 
    vptr2&#91;0x800&#93; = 0xffffffff; 
  &#125;

and yes now i can see the value at 0x84000000 increasing

[J.F.]

I was thinking it's more like the cache in the SH processors. They have a special mode where half the cache becomes a special scratch pad at a certain address. There's no real memory, just the cache, but it's completely safe to use it as if it were memory (but no DMA, cpu access only).

[hlide]

I was thinking it's more like the cache in the SH processors. They have a special mode where half the cache becomes a special scratch pad at a certain address. There's no real memory, just the cache, but it's completely safe to use it as if it were memory (but no DMA, cpu access only).

ohh that, i remember so. But here i'm doubtful that we have a 2MB cache !

[dot_blank]

this might prove to be very useful :)

[J.F.]

I was thinking it's more like the cache in the SH processors. They have a special mode where half the cache becomes a special scratch pad at a certain address. There's no real memory, just the cache, but it's completely safe to use it as if it were memory (but no DMA, cpu access only).

ohh that, i remember so. But here i'm doubtful that we have a 2MB cache !

I didn't figure it filled the whole space. More like 2K mirrored many times over the 2M space. That's why I asked if you saw some kind of wrap boundary. For example, let's assume it was only 2K. If you write out 64K of data, only the last 2K would be seen mirrored over and over on 2K blocks.

[hlide]

Here is what you can read between 0x84000000-0x840FFFFF :

Code: Select all

1A 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00

notice they have the same 64-byte pattern (does a cache line contain 64 bytes ?)

and between 0x84100000-0x841FFFFF :

Code: Select all

00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00

Now i use this code on ME processor :

Code: Select all

  int i = 0;
  int j = 0;
  (*pctr1) = (int)0;
  while(1)
  {
    long long x;
    (*pctr2) = (*vptr2);
    vptr2[0] = vptr2[0] + i++;
    vptr1[0] = vptr2[0];
    vptr1++;
    vptr2++;
    if ((int)vptr2 == 0x84200000)
    {
      if (++j == 2)
      {
        (*pctr1) = (int)-1;
        for (;;);
      }
      vptr2 = (volatile unsigned int *)(0x84000000);
      i = 0;
    }
  }

so there are 2 passes, if there is a real storage i would have their values increases twice. But i got this :

Code: Select all

1A 00 00 00 01 00 00 00 02 00 00 00 03 00 00 00
1E 00 00 00 05 00 00 00 06 00 00 00 07 00 00 00
22 00 00 00 09 00 00 00 0A 00 00 00 0B 00 00 00
26 00 00 00 0D 00 00 00 0E 00 00 00 0F 00 00 00
2A 00 00 00 11 00 00 00 12 00 00 00 13 00 00 00
2E 00 00 00 15 00 00 00 16 00 00 00 17 00 00 00
32 00 00 00 19 00 00 00 1A 00 00 00 1B 00 00 00
36 00 00 00 1D 00 00 00 1E 00 00 00 1F 00 00 00
and so on

as if there is only one pass. So my hunch would be that : what we see is the contents of a cache line which are never written back (so you need absolutely to use "cache 31, %0" to lock the cache line at the address you are interested with).

I'm doubtful that Sony adds a possibility to use half of a cache as a extermely fast small ram. Sony really sucks with the poor design of the scratch pad (it should have been an internal memory but it isn't) so I'm pretty sure they don't even bother with having such a possibility.

EDIT:

oh sorry ! i did a mistake on my code i forgot to increase their values the right way ://////

i corrected the code but the result is the same anyway.

[hlide]

address starting at 0xA0000000 is readable too, there is a lot of pattern but i don't think it is vram.