PS3 Project RSX Boost: Overclock your Retail PS3 RSX Speeds (ps3 cfw only)

sure, actuallly i did that, and yep, the ssd goes really good, actually i installed an adata SU650 480gb ssd on it, and there is a huge difference compared to the hdd 7200 rpm that i used to have installed, i already did the installations of everything that i had before, i like that ssd due to the slc cache technology that it has, also i bought a cheap p220 patriot SSD as well for 2tb for my games as external SSD and those are going really good, the temps are on aroung 60-64 degress on both rsx and cpu the most at 45% fan speed, really good ones
 
Last edited:
xxjoeyxx said:
I'm currently at 750 MHz RSX with my Slim:anonymous:. With the original cooling, always with a 39-41 percent fan. The temperature must be in the range of 65-68 degrees because otherwise small image errors occur, I haven't had any crashes. So far I'm quite satisfied 50 percent more. I didn't measure any frame rates, but it feels very smooth at first. But there are still fps drops due to the CPU. Later I would like to deal with the Vram clock and build a water cooling system and experiment a little more. If anyone else manages to change the clock of the CPU that would be fantastic.:pig:
Click to expand...

Sounds like you're starting to see artifacting. Would you mind sharing what the "small image errors" look like?
 
quake said:
Sounds like you're starting to see artifacting. Would you mind sharing what the "small image errors" look like?
Click to expand...
Yes , sometimes likePolygonal Artefacts sometimes a flashing incorrectly lit texture,sorry for that bad Englisch.
I only overclocked my 45nm and can't say much about the 65nm but I think the 45nm RSX definitely has more potential than the 65nm. That's physics. I wouldn't like to overclock 65nm models either already known as defectiv.
Today i always keep my Temps at 65-68° and have no artefacts ore crashes.an im Playing A lot :D
 
cha0shacker said:
Don't overclock the RSX models with the defective underfill material because it will breakdown even faster due to the higher current with the OC. That would be all models with a 90nm RSX (CXD2971) and the models with the first gen 65nm RSX (CXD2982). Second gen 65nm RSX (CXD2991) and the 40nm RSX (CXD5300) should be fine.
Click to expand...

Is there any way to determine this without dissembling the PS3 and looking at the RSX directly?
 
cha0shacker said:
Yes, mostly. Your PS3 model will determine what motherboard you have and therefore which components are on it. There are some exceptions though.
Click to expand...

Thanks. My PS3 is the first 'slim' CECH-2001A. Been doing a bit of sleuthing on PSdevwiki and it appears it should have a DYN-001 system board with the CXD2991 RSX, but I vaguely recall reading somewhere that the very first slims could possibly have an RSX with the underfill issue. Can't seem to find that info now though :frown:
 
On a slim you are basically always in the green unless they used really old RSX stock since the first gen slim is the last model to use any 65nm parts and CXD2991 is the fixed RSX
 
Last edited:
LuanTeles said:
About the Overclock toggle

I'm wondering if we can storage an overclocked CoreOS and a default one in the ROS bank and switch between then in the next reboot via xai/cobra, is it possible?

@Evilnat @zecoxao @M4j0r
Click to expand...

The storage of the overclocked CoreOS in both ROS banks is not difficult.
The data about current ROS bank is found in SYSCON.

As far as I know, there isn't a know method to read or change that value (used to switch the ROS bank).

That's the main reason why Flash Writer needs to write both ROS banks, instead of overwrite only the current CoreOS.

And this is the main concern mentioned by bguerville about the Flash Writer 4.90 that writes a partial nofsm patch of only 3MB. If both ROS aren't identical, one of them is corrupted by Flash Writer. That's why it's recommended to install HFW twice before use the Flash Writer 4.90. This potential issue doesn't happen with BGToolset because it overwrites both ROS banks with the full nofsm patch of 7MB.
 
LuanTeles said:
About the Overclock toggle

I'm wondering if we can storage an overclocked CoreOS and a default one in the ROS bank and switch between then in the next reboot via xai/cobra, is it possible?

@Evilnat @zecoxao @M4j0r
Click to expand...
I think it might be doable in CFWs actually, as long as LV1/LV2 patches have been applied to allow write access to syscon, there should ONLY be 1 byte to change there to apply an active ROS switch afaik.

IIRC on NAND only, it might even be possible to switch the active ROS bank without writing to syscon as I recall active ROS data being kept in NAND itself inside the ROS region header, not sure whether the syscon's active ROS bank data is even used for booting in NAND's case.

All this needs to be confirmed though.
@M4j0r ?
 
Last edited:
bguerville said:
I think it might be doable in CFWs actually, as long as LV1/LV2 patches have been applied to allow write access to syscon, there should ONLY be 1 byte to change there to apply an active ROS switch afaik.

IIRC on NAND only, it might even be possible to switch the active ROS bank without writing to syscon as I recall active ROS data being kept in NAND itself inside the ROS region header, not sure whether the syscon's active ROS bank data is even used for booting in NAND's case.

All this needs to be confirmed though.
@M4j0r ?
Click to expand...

Yes, on NOR models the info about the active bank is stored in the NVS while on NAND models it's stored on the NAND.
 
M4j0r said:
Yes, on NOR models the info about the active bank is stored in the NVS while on NAND models it's stored on the NAND.
Click to expand...
so no way of writing to it via software, or can you patch syscon pkg to make NVS readable/writable (without any hardware of course)?
and what about the 1400A's syscon? sorry for the ignorance, but I haven't followed all the syscon developments
 
haxxxen said:
so no way of writing to it via software, or can you patch syscon pkg to make NVS readable/writable (without any hardware of course)?
and what about the 1400A's syscon? sorry for the ignorance, but I haven't followed all the syscon developments
Click to expand...
For NOR, the existing lv1 patch should allow you to write to the active ROS bank NVS offset, pretty much like we already do for QA flagging or FSM. I don't think anything new is needed.

For NAND, no patch required, the official sys_storage_write syscall should be sufficient.
 
Last edited:
bguerville said:
For NOR, the existing lv1 patch should allow you to write to the active ROS bank NVS offset, pretty much like we already do for QA flagging. I don't think anything new is needed.

For NAND, no patch required, the official sys_storage_write syscall should be sufficient.
Click to expand...
hm, didn't even know that the 'usual' eeprom offsets and token are already NVS. thought the unreadable offsets were meant
 
bguerville said:
https://www.psdevwiki.com/ps3/SC_EEPROM

Check that table, the active ROS bank data is in range ie 0x48C00 - 0x48CFF.
IIRC some of the offsets in that range might be read without patch, others cannot be read (or written to) without patch.
Click to expand...
ok, thanks for your effort and reply, really appreciate it. sometimes, I am too lazy for myself, sorry :)

anyways, I have hardpatched lv1, so I can read and write all available offsets. I even have included eeprom dumper into Cobra stage1, so I can dump all readable offsets at startup. useful after update to watch changings. will search for offset.

another thing came to my mind, how about including another lv1? it should fit, even on dual kernel coreos, cause I have made lately some compressing tests on DEH, where lv2 is a bit bigger in size than the other kernels.
 
haxxxen said:
ok, thanks for your effort and reply, really appreciate it. sometimes, I am too lazy for myself, sorry :)

anyways, I have hardpatched lv1, so I can read and write all available offsets. I even have included eeprom dumper into Cobra stage1, so I can dump all readable offsets at startup. useful after update to watch changings. will search for offset.

another thing came to my mind, how about including another lv1? it should fit, even on dual kernel coreos, cause I have made lately some compressing tests on DEH, where lv2 is a bit bigger in size than the other kernels.
Click to expand...
You mean fitting 2 lv1 self on the same bank? Well, if there's enough space, I don't think it would be a problem.
To switch from one to the other, you should only have to modify the ROS entry table entry for lv1.self, tweaking the file offset and file size values, then reboot.

Each entry in that table is 0x30 bytes and structured like so:
First 8 bytes : File offset relative to ROS bank start
Next 8 bytes: File length
Next 32 bytes: File name

All details can be found here:
https://www.psdevwiki.com/ps3/Flash:ROS
 
Last edited:
bguerville said:
You mean fitting 2 lv1 self on the same bank? Well, if there's enough space, I don't think it would be a problem.
To switch from one to the other, you should only have to modify the ROS entry table entry for lv1.self, tweaking the file offset and file size values, then reboot.

Each entry in that table is 0x30 bytes and structured like so:
First 8 bytes : File offset relative to ROS bank start
Next 8 bytes: File length
Next 32 bytes: File name

All details can be found here:
https://www.psdevwiki.com/ps3/Flash:ROS
Click to expand...
it wasn't a question and more a suggestion. instead of changing ROS bank, just switch lv1 in flash, just like lv2kernel. anyways, just have found the answer and verified myself. ros0=FF and ros1=00, but haven't verified myself given offset from devwiki. just compared my eeprom dumps before and after update. now I think of it, changing ros bank is much less hassle than switching file in coreos. just changing a single offset, though both ros regions should match

edit
ok, offset is correct
 
Last edited:
haxxxen said:
it wasn't a question and more a suggestion. instead of changing ROS bank, just switch lv1 in flash, just like lv2kernel. anyways, just have found the answer and verified myself. ros0=FF and ros1=00, but haven't verified myself given offset from devwiki. just compared my eeprom dumps before and after update. now I think of it, changing ros bank is much less hassle than switching file in coreos. just changing a single offset, though both ros regions should match
Click to expand...

I think your idea makes the concept of a dual lv1 feasible, since it's very easy to write to NOR/NAND flash.

If I recall correctly @kostirez1 was also using the free area to optimize the nofsm patching.
Maybe he could adapt his flash tool to write a dual 2 lv1.self and patch the file table.
 
You must log in or register to reply here.

Similar threads

Back
Top