PSP Slim RAM partitions

kururin · Post by **kururin** » Tue Sep 11, 2007 8:28 am

A quick bruteforce using sceKernelQueryMemoryPartitionInfo gave this:

partition 1 (kernel high)

topaddr = 0x88000000, size = 0x300000 (3 MB), attr = 0x0C

partition 2: (user)

topaddr = 0x08800000, size = 0x1800000 (24 MB), attr = 0x0F

partition 3: (mirror of partition 1)

partition 4: (kernel low)

topaddr = 0x88300000, size = 0x100000 (1 MB), attr = 0x0C

Partition 5: (volatile)

topaddr = 0x08400000, size = 0x400000 (4 MB), attr = 0x0F

Partition 6: (mirror of partition 2)

Partition 8: (new in the psp slim!)

topaddr = 0x8A000000, size = 0x1C00000 (28 MB), attr = 0x0C

Partition 10: (new in psp slim!)

topaddr = 0x8BC00000, size = 0x400000 (4 MB), attr = 0x0C

So it seems at first the new partitions are for kernel mode use, but i guess they can be unlocked for user mode use with the SetDdrMemoryProtection function :)

Chrighton · Post by **Chrighton** » Wed Sep 12, 2007 12:58 am

Nice info, thanks :)

jas0nuk · Post by **jas0nuk** » Wed Sep 12, 2007 2:53 am

Interesting info, 0x8A000000 is probably the one used for UMD cache :P

J.F. · Post by **J.F.** » Wed Sep 12, 2007 4:07 am

Whether or not RAM is used for the cache is selectable in the settings. Does turning OFF the UMD cache affect the RAM partitions? It's something to check, at least.

FreePlay · Post by **FreePlay** » Thu Sep 13, 2007 9:47 am

According to Mathieulh the memory is reserved regardless of whether the cache is enabled or not. How wasteful...

Wally · Post by **Wally** » Thu Sep 13, 2007 10:31 am

Sure enough it can be changed somehow :)

FreePlay · Post by **FreePlay** » Thu Sep 13, 2007 11:47 am

Yeah, unload umdcache.prx or (if the memory still stays allocated after unloading) patch sceKernelLoadModule to refuse to load that module :)

Break it! Break it!

Wally · Post by **Wally** » Thu Sep 13, 2007 11:59 am

maybe have an option in recovery mode to enable it :P

J.F. · Post by **J.F.** » Thu Sep 13, 2007 1:15 pm

Wally4000 wrote:maybe have an option in recovery mode to enable it :P

Yeah, patch the firmware to disable the cache and map the mem contiguously. I'd rather have 56MB of contiguous user mem than a UMD cache.

Vincent_M · Post by **Vincent_M** » Thu Sep 13, 2007 2:14 pm

Would it be possible to have both? In other words, have a switch in the firmware recovery mode that could set the system ram from default partition mode to contiguous ram. That way, you still have the default UMD cache if you want. It's just a thought, probably can't work, or probably doesn't make sense, I know... I wouldn't even know what you'd use the UMD cache for anyway.

Wally · Post by **Wally** » Thu Sep 13, 2007 3:12 pm

Play UMD's quicker :)

J.F. · Post by **J.F.** » Thu Sep 13, 2007 4:09 pm

Vincent_M wrote:Would it be possible to have both? In other words, have a switch in the firmware recovery mode that could set the system ram from default partition mode to contiguous ram. That way, you still have the default UMD cache if you want. It's just a thought, probably can't work, or probably doesn't make sense, I know... I wouldn't even know what you'd use the UMD cache for anyway.

They have an M33 VSH Menu that comes up when you press Home. You can change various things like the CPU speed and the UMD ISO mode. Maybe they could work this into that menu. It would be nice, but I'm not holding my breath on that one. :)

tacoSunday · Post by **tacoSunday** » Thu Sep 13, 2007 9:57 pm

I think that the most transparent solution would be to add another flag to PSP_MAIN_THREAD_ATTR. A custom fw should be able to recognize this flag and remap the partition to userspace upon launching the app. I see no reason why the end user should have to bother with this.

J.F. · Post by **J.F.** » Fri Sep 14, 2007 3:47 am

tacoSunday wrote:I think that the most transparent solution would be to add another flag to PSP_MAIN_THREAD_ATTR. A custom fw should be able to recognize this flag and remap the partition to userspace upon launching the app. I see no reason why the end user should have to bother with this.

Yes, if they can do that, it's certainly the best idea so far. :)

Vincent_M · Post by **Vincent_M** » Fri Sep 14, 2007 6:39 am

Yeah, you guys really know your stuff... I don't know much just yet. Is there a way to downgrade the PSP Slim's custom firmware down to version 1.5. I really like using it, but I don't really know if the new PSP can support the older firmware. Do any of you know? The whole point of downgrading for me is so that I can continue to work on my current projects with the extra memory. I've been looking at the compatibility lists, and some homebrew apps created on the original PSP (like the ones that use ME features in particular) don't work on PSP Slim. Also, I've heard that custom firmware doesn't always work as well as version 1.5. Anyway, just wondering. Good work though, mad props!

cloudhunter · Post by **cloudhunter** » Fri Sep 14, 2007 12:53 pm

No, you cannot downgrade the PSP slim. And custom firmwares run just as well as 1.50, with more features.

Besides, 1.50 wouldn't even understand the extra memory - your best bet is coding for M33's firmware.

Cloudy

Marco_N · Post by **Marco_N** » Fri Sep 14, 2007 3:13 pm

cloudhunter wrote:And custom firmwares run just as well as 1.50, with more features.

Has kernel mode been unlocked on 3.60? I thought homebrew had to be usermode?

Until programs like Bookr run on 3.xx my "fat" PSP stays at 1.50 and you might want to try while you still can and obtain a "fat" PSP and downgrade it using Pandora to 1.50.

Vincent_M · Post by **Vincent_M** » Fri Sep 14, 2007 3:32 pm

That's good, because I have 3 of the original PSP's. I still have to revive my oldest one from it's corrupt firmware coma using Pandora's Battery. Yeah, and that was my thought too about v1.5 not being able to realize that there was extra memory on the PSP Slim. The addresses would just simply not exist in the v1.5 firmware, I guess. So, how would I program differently on M33's custom firmware from 1.5 firmware? Also, is there a way to heap all the memory together into 56MB of contiguous memory, or should I just wait until M33 does it. Good work M33!

adrahil · Post by **adrahil** » Fri Sep 14, 2007 4:01 pm

Besides, 1.50 wouldn't even understand the extra memory

Yes it will... It is built (for devkit) to understand it :) There is only the partitioning of the NAND to change.

Has kernel mode been unlocked on 3.60

Yes.

Until programs like Bookr run on 3.xx

It should probably work after recompilation - as it is not the kind of app one expects to use a huge amount of Api.

kururin · Post by **kururin** » Fri Sep 14, 2007 8:18 pm

J.F. wrote:
Wally4000 wrote:maybe have an option in recovery mode to enable it :P
Yeah, patch the firmware to disable the cache and map the mem contiguously. I'd rather have 56MB of contiguous user mem than a UMD cache.

I talked to the guys, and they say they will avoid umdcache module loading when executing homebrew in a future revision. Good to hear, all memory available :)

Be3f · Post by **Be3f** » Fri Sep 14, 2007 10:23 pm

kururin wrote: I talked to the guys, and they say they will avoid umdcache module loading when executing homebrew in a future revision. Good to hear, all memory available :)

Awesome! We need 56 Megs of RAM for the next-gen homebrew :)
Did you ask them about the 1.50 firmware part in any future custom FW for slim? We also need the 1.50 kernel to run old homebrews with no avaluable source code...

Viper8896 · Post by **Viper8896** » Fri Sep 14, 2007 10:27 pm

if 1.5 currently cant be run on new psps. couldnt 1.5 be hacked around and customized so it just can work on new psps. just like the custom ipl enabled 1.5 to be run ta-086 without corrupted keys.

Be3f · Post by **Be3f** » Fri Sep 14, 2007 10:31 pm

But maybe it's possible to take some modules, that don't work on slim (like display.prx) from the higher fws and implement them into 1.50 fw part on slim? m33 can also compare the prxs from the decrypted 3.71 fw for slim and for fat and find the differences, that make 3.71 drivers work on old hardware like ta079 - to understand how to adapt 1.50 to ta-085 (Slim)... BTW, i'm not a fw guru to give them advices...

Wally · Post by **Wally** » Sun Sep 16, 2007 1:02 pm

Why do you people want 1.50 so much?

It doesn't take much to port a game over to the 3.60 kernel and it also encourages many developers to update their projects. :)

If you want something working in 3.60, why not get it working yourself (If of course is Open Source)?

Be3f · Post by **Be3f** » Sun Sep 16, 2007 5:30 pm

Wally4000 wrote:Why do you people want 1.50 so much?

It doesn't take much to port a game over to the 3.60 kernel and it also encourages many developers to update their projects. :)

If you want something working in 3.60, why not get it working yourself (If of course is Open Source)?

Most of the PSP-coders released only binaries (eboots) with no src :( And some of them have left the scene, e.g. PeterM & PSMonkey now work in commercial PSP-developement... So, the 1.50 part in 3.XX custom fw for slim seems to be the ideal solution...

Wally · Post by **Wally** » Sun Sep 16, 2007 5:41 pm

Noobz have released an Eloader for the slim..

Perhaps this is the solution :)

www.noobz.eu

Be3f · Post by **Be3f** » Sun Sep 16, 2007 6:02 pm

Wally4000 wrote:Noobz have released an Eloader for the slim..

Perhaps this is the solution :)

www.noobz.eu

Oh, forget about all my words about 1.50 fw part... I luuuv noobZ! :P
I'm sure that it's possible to integrate the core of this loader into custom fw, hopefully Team m33 will perform it...

Jim · Post by **Jim** » Sun Sep 16, 2007 9:15 pm

Why do you people want 1.50 so much?

It's official Sony firmware ;)

Be3f · Post by **Be3f** » Mon Sep 17, 2007 3:38 am

Jim wrote:
Why do you people want 1.50 so much?
It's official Sony firmware ;)

I don't care, is firmware offical, or modified... i just want to have the ability to run ALL homebrews on Slim ;)

moonlight · Post by **moonlight** » Mon Sep 24, 2007 7:14 am

As you can see, you can now access the extra mem in user mode in 3.71, and without umdcache around there :p

Techincal stuff, the memory protection of te extra slim memory is in these hardware registers: 0xbc000040-0xbc00007F.

Set all to 0xFF, and you have access to it in user mode (note: sceKernelSetDdrMemoryProtection wouldn't do it)., but anyways is done automatically by m33 when launching homebrew, so no need to care about that.