| View previous topic :: View next topic |
| Author |
Message |
TyRaNiD
Joined: 18 Jan 2004
Posts: 918
|
 Posted: Thu Oct 12, 2006 5:32 am Post subject: Accessing the extra 4Megs of RAM on 1.5+ |
 |
|
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: | 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: | 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: | | 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. |
|
| Back to top |
|
 |
harleyg
Joined: 05 Oct 2005
Posts: 123
|
| Posted: Thu Oct 12, 2006 6:12 am Post subject: |
|
|
| Nice find tyranid. |
|
| Back to top |
|
|
jimparis
Joined: 10 Jun 2005
Posts: 1179
Location: Boston
|
| Posted: Thu Oct 12, 2006 6:12 am Post subject: |
|
|
| Nice work as always :) |
|
| Back to top |
|
|
Raphael
Joined: 17 Jan 2006
Posts: 646
Location: Germany
|
| Posted: Thu Oct 12, 2006 4:22 pm Post subject: |
|
|
Very nice finding and good documentation of the finding :) Thanks Tyranid!
_________________
<Don't push the river, it flows.>
http://wordpress.fx-world.org - my devblog
http://wiki.fx-world.org - VFPU documentation wiki
Alexander Berl |
|
| Back to top |
|
|
zshadow
Joined: 26 Dec 2005
Posts: 42
|
| Posted: Fri Oct 13, 2006 1:44 am Post subject: |
|
|
| Very nice work. |
|
| Back to top |
|
|
Fanjita
Joined: 28 Sep 2005
Posts: 217
|
| Posted: Fri Oct 13, 2006 4:05 am Post subject: |
|
|
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...
_________________
Got a v2.0-v2.80 firmware PSP? Download the eLoader here to run homebrew on it!
The PSP Homebrew Database needs you! |
|
| Back to top |
|
|
SamuraiX
Joined: 31 Jan 2006
Posts: 76
Location: USA
|
| Posted: Fri Oct 13, 2006 11:57 am Post subject: |
|
|
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: |
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! |
|
| Back to top |
|
|
TyRaNiD
Joined: 18 Jan 2004
Posts: 918
|
| Posted: Fri Oct 13, 2006 4:14 pm Post subject: |
|
|
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: | 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 |
|
|
| Back to top |
|
|
moonlight
Joined: 26 Oct 2005
Posts: 567
|
| Posted: Fri Oct 13, 2006 5:40 pm Post subject: |
|
|
| Fanjita wrote: | 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. |
|
| Back to top |
|
|
moonlight
Joined: 26 Oct 2005
Posts: 567
|
| Posted: Fri Oct 13, 2006 5:56 pm Post subject: |
|
|
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 |
|
| Back to top |
|
|
SamuraiX
Joined: 31 Jan 2006
Posts: 76
Location: USA
|
| Posted: Sat Oct 14, 2006 12:36 am Post subject: |
|
|
What a great find TyRaNiD!!! Works like a charm. The extra memory does come handy...:)
It also works great in 2.71SE-A |
|
| Back to top |
|
|
TyRaNiD
Joined: 18 Jan 2004
Posts: 918
|
| Posted: Sat Oct 14, 2006 1:31 am Post subject: |
|
|
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 |
|
| Back to top |
|
|
groepaz
Joined: 01 Sep 2005
Posts: 305
|
| Posted: Wed Oct 18, 2006 1:26 am Post subject: |
|
|
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).
_________________
http://www.hitmen-console.org
http://hitmen.c02.at/files/yapspd/ |
|
| Back to top |
|
|
weltall
Joined: 20 Feb 2004
Posts: 310
|
| Posted: Wed Oct 18, 2006 3:21 pm Post subject: |
|
|
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 :) |
|
| Back to top |
|
|
be2003
Joined: 20 Apr 2006
Posts: 144
|
| Posted: Tue Apr 24, 2007 2:23 pm Post subject: Re: Accessing the extra 4Megs of RAM on 1.5+ |
|
|
| TyRaNiD wrote: | 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: | 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: | 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: | | 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: |
#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
_________________
- be2003
blog |
|
| Back to top |
|
|
Pit0711
Joined: 24 Mar 2005
Posts: 54
Location: Old Europe -Germany-
|
| Posted: Sat Jul 14, 2007 8:54 am Post subject: |
|
|
| PSP2 has 64 Megs RAM :-) |
|
| Back to top |
|
|
Anti-QJ
Joined: 03 May 2007
Posts: 16
|
| Posted: Sat Jul 14, 2007 10:13 am Post subject: |
|
|
Link?
Please... |
|
| Back to top |
|
|
kururin
Joined: 05 Jul 2006
Posts: 36
|
|
| Back to top |
|
|
dot_blank
Joined: 28 Sep 2005
Posts: 498
Location: Brasil
|
| Posted: Sun Jul 15, 2007 7:01 am Post subject: |
|
|
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
_________________
10011011 00101010 11010111 10001001 10111010 |
|
| Back to top |
|
|
|
FAQ
Search
Memberlist
Usergroups
Register
Profile
Log in to check your private messages
Log in
