forums.ps2dev.org

kururin · Joined: 05 Jul 2006 Posts: 36

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 · Joined: 15 Jun 2005 Posts: 58

Nice info, thanks :)

jas0nuk · Joined: 27 Apr 2006 Posts: 137

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

J.F. · Joined: 22 Feb 2004 Posts: 2906

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 · Posted: Thu Sep 13, 2007 9:47 am Post subject:

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

Wally · Joined: 26 Sep 2005 Posts: 672

Sure enough it can be changed somehow :)

FreePlay · Posted: Thu Sep 13, 2007 11:47 am Post subject:

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 · Joined: 26 Sep 2005 Posts: 672

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

J.F. · Joined: 22 Feb 2004 Posts: 2906

Vincent_M · Joined: 03 Apr 2007 Posts: 73

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 · Joined: 26 Sep 2005 Posts: 672

Play UMD's quicker :)

J.F. · Joined: 22 Feb 2004 Posts: 2906

tacoSunday · Joined: 31 Aug 2007 Posts: 34

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. · Joined: 22 Feb 2004 Posts: 2906

Vincent_M · Joined: 03 Apr 2007 Posts: 73

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 · Joined: 17 Aug 2006 Posts: 86

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 · Joined: 29 May 2005 Posts: 46

Vincent_M · Joined: 03 Apr 2007 Posts: 73

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 · Joined: 16 Mar 2006 Posts: 277

kururin · Joined: 05 Jul 2006 Posts: 36

Be3f · Joined: 15 Mar 2007 Posts: 59

Viper8896 · Joined: 26 Jan 2006 Posts: 110

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 · Joined: 15 Mar 2007 Posts: 59

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...
_________________
00000110 00000110 00000110

Wally · Joined: 26 Sep 2005 Posts: 672

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 · Joined: 15 Mar 2007 Posts: 59

Wally · Joined: 26 Sep 2005 Posts: 672

Noobz have released an Eloader for the slim..

Perhaps this is the solution :)

www.noobz.eu

Be3f · Joined: 15 Mar 2007 Posts: 59

Jim · Joined: 02 Jul 2005 Posts: 487 Location: Sydney

Be3f · Joined: 15 Mar 2007 Posts: 59

moonlight · Joined: 26 Oct 2005 Posts: 567

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.