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

Tanzu15 said:
Bro you don't want to try that 850/1000. That's an insane OC that can cause a brick. 25xx consoles cannot do that stable. Hell the risk of brick is high.


This was pretty educational. But I knew a few things. Luckily I've fully understand what ps3s can handle depending on the model. And what frequency ranges.
Click to expand...
Hello, what cause the brick on slim cfw? What is safe oc for slim cfw?
Why we cant use slot fw switch has a base for patch 1 slot with oc code and use the other one for safe boot?
Is possible make a homebrew with oc data patch for make the change in 1 slot and point it after a reboot? I have read is possible tell to ps3 what fw slot read on boot. But idk if brick status close the possibility to execute the code for bank switching. Or if the brick is hw problem. For sure (for my opinion) sony make the ps3 with the overclock in mind, but after ylod problem never use it...
Iam curios if official linux for early ps3 fw can trigger the kernel for change mhz value,governor ecc like cpufreqd
 
I could test new models for vrams easy if I find to buy, that would make 40nm at 512 MB. In theory if rsx ram are good it would boot in sb uart log I should get some errors with glod. Well it may need some patches I assume. Well if I don't get it working I know someone who can make it work, M4j0r if he gets time.
Even easier when I get rsx tester finished on a simplified version where we reball one interpouser I've remake, after version with am4 pins is a pain to build(didn't finish to solder like 300 pins left to solder). Hope interpouser won't deform as previous ones were not touching all pads or alloy was flowing throu holes up and no connection with board. This new interpouser should reball as rsx and middle vias were set as micro vias, alloy should not pass from bottom to top anymore
 
please, be careful with this...
for those of you, who want to push this further, I have experienced now how the brick happens. this really is indeed dangerous without any recoverable option, like hardware flasher. unfortunately, my DECR does not have superior 65nm RSX, which could be pushed like a champ. it seems only viable for latest Slim models. though, I won't need and do any OC.

probably the PS3 can startup without hdd (if at all), but then it will shutdown with 3 beeps, or this happens during boot. you all have been warned!!!
 
haxxxen said:
please, be careful with this...
for those of you, who want to push this further, I have experienced now how the brick happens. this really is indeed dangerous without any recoverable option, like hardware flasher. unfortunately, my DECR does not have superior 65nm RSX, which could be pushed like a champ. it seems only viable for latest Slim models. though, I won't need and do any OC.

probably the PS3 can startup without hdd (if at all), but then it will shutdown with 3 beeps, or this happens during boot. you all have been warned!!!
Click to expand...
Hi, nice to read you. What cause the perma brick?
 
LuanTeles said:
So i need to uncheck the "Sign isoleted modules(s) with iso_rebuilder" and "Sign self/sprx(s) with self rebuilder" right?

Can you add a warning on these two option, AFAIK you told me using it on OFW is fine, but not on CFW.

Or maybe a check can added, to disable those if a CFW is detected.
Click to expand...
have to fix so much with mfwbuilder, dang. but yeah, I want to also include some kind of nag screen telling potential risk, which won't let you proceed.

about the _rebuilders, I personally prefer them over scetool, since they do not change the compression, and will let file stay as original as it could be, with only minor signature changing. as soon, as original filesize has changed, the _rebuilders won't work.

unfortunately, on coreos, most files are compressed (let alone for free space on cos - see Rebug flavour), and as soon as original filesize has changed, it cannot be rebuilt using _rebuilders. so precaution, using a CFW to mod, you have to use scetool and disable both global options for now. dunno, if I can get this done automatically, have to try and see...
 
Well I personally never test this oc mod, I'm going to try only that hw side of 512 ram swap. Atm I'm only one getting rsx ram decap test and only that could build one rsx tester board without reball rsx (test with pogo pins).
Some of my test are in this link
https://s.go.ro/8lcdk9cq
Once ready I'll ask Felix to write a complete understanding for all tutorial. Is just hard to explain in each case particular how to build it.
This is just reference build, tech's with experience will understand ideas for sure.
 
haxxxen said:
sorry, but I have no idea. I won't solder to my TOOL, but maybe to my CECH-L, now I have fixed it

ah, I can use software syscon error dump...will get it then
Click to expand...
C"mon we thought you know, if you manage to get out of brick u still have errors there stored, all 32 in syscon, use bgtoolset for dump or see errors at least. I think there is a software tool for clear log? Felix?
Or this was the tool https://store.brewology.com/ahomebrew.php?brewid=329#google_vignette
 
Well didn't test it to much to know what is working. If there is a simple solution take your time to to post for further help support.
I have one sem001 I'll have a look tonight, I think is bricked and needs some patches didn't look at it over few months when it was reballed with new 40 and shutdown itself over 40 seconds like. Rsx data swapped, didn't look into sb uart log.

Another stupid idea if inside a mman or any app that could run just an terminal as SSM type acces would be something new. Assumed Linux was compatible thought this idea may help reach easy access from inside then external tied. Idk almost nothing at software side.
 
Last edited by a moderator:
haxxxen said:
yeah, I will dump the errors soon, but no bgtoolset unfortunately, no support for 4.21 CEX/DEX/DEH
Click to expand...
If you are up for a little offset hunting and testing, we could try to add support together for the versions you need..
If ONLY in a test version with restricted access to you and me for starters..

That work wouldn't be wasted, originally I intend to bring support right down to 4.21 anyway UNLESS there are complications (ie leading to having to make extra code changes) from a certain version down, it's always possible in practice..
The real problem for me is the impact on testing to be honest, esc0 does all my testing, it's already quite a lot of work as it is from 4.75 up, I cannot really ask him to test all Toolset features on all fw versions from 4.21 up to validate each new release I make, even if there's ONLY one or 2 per year... The amount of work would be multiplied to a point it would no longer be reasonable... The alternative is to release untested stuff, but I don't want to do that either.. Dilemma..

Send me a pm, we can discuss this further if you want to.
 
Yes I shall do so.
Bioshock is running close to 80fps I did not believe it and goes down to about 40-60 during hard combat. I was also able to finish Oblivion, although it was capped to 30 and 20 in final battle
Tanzu15 said:
Not bad at all. Though I hope you test a large number of games, cause it might take certain games to see the instability. It's why I test new games every day. So far I'm blessed with 750/950.
Click to expand...
 
Ketxxx said:
Probably 650/750 max for 20XX models not just because of the 65nm node but also because NEC/TOKINS, they are a weak link as it is.
Click to expand...

Interesting post !
Just received a new Slim (same model as before. I was expecting a 21XX but... this is fine.).

On CECH-2004 models (65nm RSX - CXD2991EGB), 700/750 works like a charm BUT I will follow your advice and keep it at 650/750, you seem to know what you're talking about (way more than me :') ).
Thank you for sharing your knowledge !

RIP-Felix said:
AFAIK the 65nm RSX has good underfill. I tested a 2982 (1st revision) and it wasnt the the same low Tg stuff the 90nm has. So unless you have information I've not seen the 65nm are all in the clear as far as defects go. They are tanks.
Click to expand...
You can't even imagine how reassuring that is.
 
Last edited:
Mitsu™ said:
Interesting post !
Just received a new Slim (same model as before. I was expecting a 21XX but... this is fine.).

On CECH-2004 models (65nm RSX - CXD2991EGB), 700/750 works like a charm BUT I will follow your advice and keep it at 650/750, you seem to know what you're talking about (way more than me :') ).
Thank you for sharing your knowledge !


You can't even imagine how reassuring that is.
Click to expand...
Wait is the slim you got like a 2009 model?
 
RIP-Felix said:
When bricked, what SYSCON errors are produced?
Click to expand...

vyktormvmpay25 said:
C"mon we thought you know, if you manage to get out of brick u still have errors there stored, all 32 in syscon, use bgtoolset for dump or see errors at least. I think there is a software tool for clear log? Felix?
Or this was the tool https://store.brewology.com/ahomebrew.php?brewid=329#google_vignette
Click to expand...

here you go, it is from my Debby ;)
Code: 
Firmware Version: 4.21 (build 49277)
Platform ID: Deb01
Product Code: 00 81
Product Sub Code: 00 09
Hardware Config: 4610FFFF8107FFFF
Syscon Fimware Version: 0E69.0001000400040001 (EEPROM: 0001000400040001)
Bringup Count: 1387, Shutdown Count: 962
Runtime: 153 Days, 20 Hours, 8 Minutes, 34 Seconds
Error Log
01: A0902120  Tue Sep  5 03:27:58 2006
02: A0801002  Tue Sep  5 03:27:58 2006
03: A0801002  Tue Sep  5 02:56:15 2006
04: A0801001  Tue Sep  5 02:53:07 2006
05: A0801002  Tue Sep  5 02:45:33 2006
06: A0801001  Tue Sep  5 02:44:29 2006
07: A0801001  Tue Sep  5 02:30:04 2006
08: A0801001  Tue Sep  5 02:27:44 2006
09: A0801001  Tue Sep  5 02:12:12 2006
10: A0801002  Tue Sep  5 02:08:33 2006
11: A0801001  Sun Sep  3 15:01:40 2006
12: A0801001  Sun Sep  3 14:59:48 2006
13: A0801001  Sun Sep  3 14:57:59 2006
14: A0801001  Sun Sep  3 14:56:16 2006
15: A0801001  Sun Sep  3 14:53:52 2006
16: A0801001  Fri May 19 13:06:04 2006
17: A0801001  Fri May 19 12:59:38 2006
18: A0801001  Fri May 19 12:57:56 2006
19: A0801001  Fri May 19 12:56:12 2006
20: A0801001  Fri May 19 12:55:03 2006
21: A0801001  Fri May 19 12:53:51 2006
22: A0801001  Fri May 19 12:52:57 2006
23: A0802022  Mon Feb 27 15:33:21 2006
24: A0802022  Mon Feb 27 15:25:06 2006
25: A0802022  Mon Feb 27 15:23:24 2006
26: A0802022  Mon Feb 27 15:21:04 2006
27: A0801001  Mon Feb 27 13:56:07 2006
28: A0801001  Mon Feb 20 01:26:18 2006
29: A0801001  Sun Feb 19 10:02:29 2006
30: A0802022  Fri Feb 17 10:59:40 2006
31: A0802022  Fri Feb 17 09:55:44 2006
32: FFFFFFFF  Tue Feb 14 09:09:26 2006
does this help in any way? have bricked it with 1000, 950, 900MHz memory clock
last is reverted back to normal

@RIP-Felix
do you think the Tokins could be culprit on 65nm, they can't be pushed like 40nm?

@bguerville
will talk to you in pm :)
 
Tanzu15 said:
Wait is the slim you got like a 2009 model?
Click to expand...
According to the datecode (9C), yes.
My first one was a 2010 model (0A).

Some pieces are different (fan/SKU for example) but they have the exact same RSX model.
Besides, while cleaning/repasting/reassembling, I put the "more modern" (and less used too) parts of the 2010 model in the 2009 one.
 
Last edited:
Guys, my cech 2501a with overclock 750-950 turned off abruptly when starting street fighter iv and the data was corrupted. I had to zero fill the HDD to be able to install the firmware again. I tested the game again and this time it worked.

Now I wonder if it was because of overclocking or if my HDD is already defective.
 
You must log in or register to reply here.

Similar threads

Back
Top