Accessing the extra 4Megs of RAM on 1.5+

[TyRaNiD]

As some will know on 1.0 there was an extra 4megs of RAM from 0x8400000 which you could access, on 1.5 if you access it you get an exception, what is going on here?

Well I just added the functions to the SDK to allow access to these areas, there are in sceSuspendForUser for usermode calls and scePower_driver for kernel mode.

For user mode they are defined in pspsuspend.h as:

Code: Select all

sceSuspendForUser_3E0271D3(int unk, void **ptr, int *size);
int sceSuspendForUser_A14F40B2(int unk, void **ptr, int *size);
int sceSuspendForUser_A569E425(void);

The first is a allocate function, pass in a pointer and a size integer and if you can allocate it it will return the appropriate info. The second is a try allocate, it polls a semaphore and if it is already alloced will return an error. The final one is the deallocate.

For kernel mode they are:

Code: Select all

scePower_driver_23C31FFE
scePower_driver_FA97A599
scePower_driver_B3EDD801

Same prototypes as the suspend ones. The suspend ones just call the power ones anyway through a callback (which then proceeds to call back into sysmem anyway, why Sony why :P).

Now as these are in a suspend library it is a fair chance that the kernel uses them for something, I haven't tested it but it might be used when suspending or sommit therefore you might not be able to use it as a general purpose area :( Still worth a try and see how far you get ;P

Now for the techy minded this is an explanation of how they work :) The core function is sceKernelSetDdrMemoryProtection(void *addr, int size, int prot). By calling this you can set the memory protection bits on certain memory blocks (well only in the first 8Mb of DDR). Addr is obvious, size is a value up to 2 megs in 256KByte blocks, prot is a 4 bit mask which determines the protection.

The prot mask is thus:

Bit 3 - Kernel Write Enable
Bit 2 - Kernel Read Enable
Bit 1 - User Write Enable
Bit 0 - User Read Enable

The first four megs are all set to 0xC prot mask which means kernel only read/write, this is interesting cause you can therefore "unprotect" the kernel only address space and access it in user mode :)

e.g.

Code: Select all

sceKernelSetDdrMemoryProtection((void*) 0x08000000, 2*1024*1024, 0xF);

Will allow the first 2 megs of kernel memory to be accessed from user space.

Now for the real techy minded (i.e. groepaz) this is what that function is doing.

The memory protection registers are 8 32bit words stating at 0xbc000000. Each 32bit is split into 8 4bit protection masks starting LSB first, i.e. bits 0 to 3 are the first 256KBytes of that chunk, bits 4 to 7 are the next etc. And as each register can address 8 256KByte blocks then the address space is split into 2Mbyte chunks.

Do for example 0xbc000000 sets protection on 0x08000000 -> 0x081FFFFFF, 0xbc000004 sets on 0x08200000 -> 0x083FFFFF and so on.

There doesn't seem to be any registers for any addresses greater than this so Sony only protected the first 8Megs.

[harleyg]

Nice find tyranid.

[jimparis]

Nice work as always :)

[Raphael]

Very nice finding and good documentation of the finding :) Thanks Tyranid!

[zshadow]

Very nice work.

[Fanjita]

Great stuff.

I'm puzzled though - I've never had any problems accessing 0x08400000 - 0x08800000 from a user-mode thread, on 2.0 - 2.8.

Perhaps this is normally accessible from VSH threads, but not plain user threads, which would explain why I've never seen an access exception?

Then again, I'm relatively sure that I've dumped that memory space from GTA, too...

[SamuraiX]

Hmmm, perhaps I'm doing something wrong but I keep getting an exception. I'm using 1.5 firmware and I've tried user and kernel mode.

sceSuspendAllocExtraMem sceSuspendForUser_3E0271D3 gives me an exception

sceSuspendTryAllocExtraMem sceSuspendForUser_A14F40B2 is reported as undefined reference to `sceSuspendForUser_A14F40B2' when linking


as for the usuage....

Code: Select all

static void **filecache;
int *size = (int*)(16384*255+64);   // 4177984 Bytes (sceSuspendAllocExtraMem up to 4194304 Bytes)

sceSuspendAllocExtraMem(0, filecache, size);

This keeps causing an exception within the function.

Any help would be much appreciated. Thank You in Advance!

[TyRaNiD]

Fanjita, well perhaps it is just available on 2.0 and greater, it is possible Sony realised noone had used it on 1.5x games and just reverted the change. I Dont do any 2.x development so it wasn't tested by me :)

SamuraiX, ill check on the undefined reference problem, perhaps I have just made a typo somewhere. As for why it is crasing it is cause you are not using it correctly. You are passing in uninitalised pointers, you need to change it to something like.

Code: Select all

static void *filecache;
int size;   // No need to set to anything, its value isn't used

sceSuspendAllocExtraMem(0, &filecache, &size); 
// filecache is now 0x08400000 and size 4Megs

[moonlight]

Great stuff.

I'm puzzled though - I've never had any problems accessing 0x08400000 - 0x08800000 from a user-mode thread, on 2.0 - 2.8.

Perhaps this is normally accessible from VSH threads, but not plain user threads, which would explain why I've never seen an access exception?

Then again, I'm relatively sure that I've dumped that memory space from GTA, too...

I never tested read to that memory in gta, but i tested writing and my test app crashed. In that space of memory is loaded pafmini, common_gui, etc that are loaded by utility.prx whenever a system dialog is created, so it would have sense to have that area not accesible to a user thread.

[moonlight]

Btw, tyranid, the true names of those three functions are known and they are in my prx doc.

sceSuspendForUser_3E0271D3 -> sceKernelVolatileMemLock
sceSuspendForUser_A14F40B2 -> sceKernelVolatileMemTryLock
sceSuspendForUser_A569E425 -> sceKernelVolatileMemUnlock

[SamuraiX]

What a great find TyRaNiD!!! Works like a charm. The extra memory does come handy...:)

It also works great in 2.71SE-A

[TyRaNiD]

moonlight, oh okay you should have said :P Ill change svn just to break everyones stuff, hehe ;)

And perhaps unsurprisingly the corresponding power functions are called scePowerVolatileMemLock etc. Might be worth updating your doc :P

[groepaz]

very nice....finally something lowlevel again =)

about 2.x... 1.5 seems to be the _only_ firmware that actually protects the second 4mb (besides implied protection beeing kernelmode only).

[weltall]

from a kernel prx point of virew i've noticed that the 4mb volatile ram under 2.71 is enabled only when the browser is opened (and the browser itself allocates ~ 2mb of ram) and during the bootup process (at least during the game bootup) then tries to access to that area makes the psp shout down.
plus when the area is enabled partition functions works fine :)

[be2003]

As some will know on 1.0 there was an extra 4megs of RAM from 0x8400000 which you could access, on 1.5 if you access it you get an exception, what is going on here?

Well I just added the functions to the SDK to allow access to these areas, there are in sceSuspendForUser for usermode calls and scePower_driver for kernel mode.

For user mode they are defined in pspsuspend.h as:

Code: Select all

sceSuspendForUser_3E0271D3(int unk, void **ptr, int *size);
int sceSuspendForUser_A14F40B2(int unk, void **ptr, int *size);
int sceSuspendForUser_A569E425(void);

The first is a allocate function, pass in a pointer and a size integer and if you can allocate it it will return the appropriate info. The second is a try allocate, it polls a semaphore and if it is already alloced will return an error. The final one is the deallocate.

For kernel mode they are:

Code: Select all

scePower_driver_23C31FFE
scePower_driver_FA97A599
scePower_driver_B3EDD801

Same prototypes as the suspend ones. The suspend ones just call the power ones anyway through a callback (which then proceeds to call back into sysmem anyway, why Sony why :P).

Now as these are in a suspend library it is a fair chance that the kernel uses them for something, I haven't tested it but it might be used when suspending or sommit therefore you might not be able to use it as a general purpose area :( Still worth a try and see how far you get ;P

Now for the techy minded this is an explanation of how they work :) The core function is sceKernelSetDdrMemoryProtection(void *addr, int size, int prot). By calling this you can set the memory protection bits on certain memory blocks (well only in the first 8Mb of DDR). Addr is obvious, size is a value up to 2 megs in 256KByte blocks, prot is a 4 bit mask which determines the protection.

The prot mask is thus:

Bit 3 - Kernel Write Enable
Bit 2 - Kernel Read Enable
Bit 1 - User Write Enable
Bit 0 - User Read Enable

The first four megs are all set to 0xC prot mask which means kernel only read/write, this is interesting cause you can therefore "unprotect" the kernel only address space and access it in user mode :)

e.g.

Code: Select all

sceKernelSetDdrMemoryProtection((void*) 0x08000000, 2*1024*1024, 0xF);

Will allow the first 2 megs of kernel memory to be accessed from user space.

Now for the real techy minded (i.e. groepaz) this is what that function is doing.

The memory protection registers are 8 32bit words stating at 0xbc000000. Each 32bit is split into 8 4bit protection masks starting LSB first, i.e. bits 0 to 3 are the first 256KBytes of that chunk, bits 4 to 7 are the next etc. And as each register can address 8 256KByte blocks then the address space is split into 2Mbyte chunks.

Do for example 0xbc000000 sets protection on 0x08000000 -> 0x081FFFFFF, 0xbc000004 sets on 0x08200000 -> 0x083FFFFF and so on.

There doesn't seem to be any registers for any addresses greater than this so Sony only protected the first 8Megs.

eh...
my computer gives me an "undefined reference to..." when i try and call sceKernelVolatileMemTryLock(int unk, void **ptr, int *size);
so i think the toolchain might be bugged, lol

so i did a quick prxtool to sysmem.prx (1.50) and built a makeshift libpspsuspend.a and i came up with a few theories about those functions and i need someone to clear them up for me

when i call sceSuspendForUser_3E0271D3 (sceKernelVolatileMemLock) it works just fine until i attempt to call it again after the memory is already allocated. i dont think it causes an exception, it just seems to hang and all other threads seem to be working perfectly fine.
1st call: returns 0
2nd call: hang, doesnt return squat

also when i call sceSuspendForUser_A14F40B2 (sceKernelVolatileMemTryLock) before i call sceKernelVolatileMemLock it returns 0 like it should, but then it makes the psp hang again... letting all other threads run
but if i call sceKernelVolatileMemTryLock after sceKernelVolatileMemLock it returns some random negative int (which is normal i guess), and the psp doesnt hang

so im trying to write a function that will check to see if that 4 mb of memory has been allocated and if it hasnt then allocate it and i need some help. i have:

Code: Select all

#define sceSuspendAllocateExtraMemory 	sceSuspendForUser_3E0271D3
#define sceSuspendTryExtraMemory 		sceSuspendForUser_A14F40B2
#define sceSuspendFreeExtraMemory 		sceSuspendForUser_A569E425
if(sceSuspendTryExtraMemory(0, &temp_loc, &temp_size) == 0) //ram not allocated
	{
		sceSuspendAllocateExtraMemory(0, &temp_loc, &temp_size); //so lets allocate it
	} 

but like i said before it hangs if sceSuspendTryExtraMemory is called before sceSuspendAllocateExtraMemory

[Pit0711]

PSP2 has 64 Megs RAM :-)

[Anti-QJ]

Link?
Please...

[kururin]

Link?
Please...

I saw these images in some forums, i don't know original source though.
http://i202.photobucket.com/albums/aa11 ... SPSPEC.jpg

Nothing is said about the flash, but maybe it will have 64 (well, 66) MB too.

[dot_blank]

well since 64MB RAM is used and 64MB NAND PIN
assignments change ..its a pretty save bet that the
psp200x will use the same 528byte pages