PS3 Frankenstein PHAT PS3: CECHA with 40nm RSX

[vyktormvmpay25]

I will let you know when I have time to test it M4j0r. I have that cok002 still working, not very happy with cell temperatures but still boots and running both games ps3/ps2.

 

[truemaster]

victor how try it on mine board. i think is not a bad idea since this board is dying.

 

[vyktormvmpay25]

victor how try it on mine board. i think is not a bad idea since this board is dying.

Well at this moment rsx is toasted, trying to get another install new rsx only 3034 error and one rsx ram popped solder out of it. Well I will test when is ready.

 

[truemaster]

oh shit trouble already? how after reflow?

 

[vyktormvmpay25]

They just want stand on many reheating processes

 

[truemaster]

the only thing that pisses me off is that is make more trouble for you.

 

[RIP-Felix]

Oh man! Now we're getting somewhere!

So If I understand this right, we can leave the stock SYSCON on the COK-001/2? WHy did SONY change it then?

 

[vyktormvmpay25]

Feel free to test before me @RIP-Felix , I had to take a break, still not in right mood for doing anything at this moment. I feel really tired after this week.
Yes just recovering that area first, remove orbis, write and share. I don't have any idea but may work, same way I've been questions for myself why Sony did it hard-way.

 

[BwE]

Nice

 

[truemaster]

maybe sony coders suck. but it needs to be tested more. if that can happen then we can replicate sony refibrish 100%

 

[DeadEnd]

For 65nm:
w 3242 03 A2 03 B0 07 71
w 3254 21 E8
Fix checksum @ 0x32FE
Reset syscon, start console

Tested on cok-002 with 65nm. Works. All hail @M4j0r - ps3 scene guru coding genius extraordinaire!!!

 

[sandungas]

Some interesting news:
I received a test console (DIA-002 with 40nm RSX and CXR713F120A Syscon) from @vyktormvmpay25
And that did some extreme speed up to the 40nm RSX Syscon patches development.

First I tried to copy the official Sony procedure, for that I flashed the 304GB (v1.5.1k2) firmware to the Syscon and performed the following patches to the original (DIA-002) EEPROM:

Fix thermal config unk:     w 348B 8B
                            w 34AF 8B
Change RSX version to 40nm: w 3912 30
Write new training data:    w 3F62 EF 87 F9 19
                            w 3F69 07 F9 1D
                            w 3F6F 1F F9 0D
                            w 3F74 EF 0F F9 0D
                            w 3FA2 03 61 82 80 01 91

(the thermal config fix isn't mandatory)
And it worked! That's the first "official" 40nm swap that wasn't done by Sony.
But of course that's not really surprising since we just copy what Sony did.

After that test I flashed the 302GB (v1.4.4k2) firmware to Syson, that's the DIA-002 standard Syscon firmware.
I did apply many patches to that firmware to debug the RSX FlexIO training and discovered something very interesting! Even though the 90nm/65nm/40nm RSX need different FlexIO training data/algorithm you can just use the 90nm/65nm data/algorithm to train a 40nm chip and it'll work. RSX will complain a lot to Syscon but Syscon can ignore that.

To further test that I removed all my custom patches from the firmware, so now it's a stock 302GB Syscon.
By applying these patches to the EEPROM:

w 3242 03 61 82 80 01 91
w 3254 21 EC

a stock 302GB Syscon will train the 40nm RSX and the console will boot without any error.
And it doesn't matter wether 0x3912 is set to 0x11 for 90nm or 0x21 for 65nm. So you can train a 40nm RSX with the 90nm or 65nm data as long as you applied these patches to the EEPROM.
Just one note: If w 3254 21 EC doesn't work, use w 3254 21 EB since there're two different 40nm chip variants.

I also did test that on the 203GB (v1.2.3k1) and 301GB (v1.3.3k1) Syscon firmwares and it works too!
(I needed to patch these firmwares in order to work on the DIA-002 but I didn't touch anything RSX related).
That means the same patches work on SEM-001 and DIA-001 (and of course DEB-001).

I can't perform the final test since I have no COK board with a 40nm RSX, but since the other chips can train a 40nm RSX with the 90nm training data, the same EEPROM patches should do the job on the 201GB/202GB Syscon. Maybe someone can test that .

In summary (TLDR): A 203GB/301GB/302GB Syscon supports 40nm RSX after applying two EEPROM patches. 201GB/202GB haven't been tested yet but should in theory work since it's the same code.

A little extra: If you plan on replacing the 90nm RSX with a 65nm one, try these patches:

w 3242 03 A2 03 B0 07 71
w 3254 21 E8

Edit (NOT TESTED):
1) For SW/2 Syscons use offset 0x182 instead of 0x3242 and 0x194 instead of 0x3254
2) For SW3 Syscons use offset 0x212 instead of 0x3242 and 0x224 instead of 0x3254
3) For the 28nm RSX replace the second command with w 3254 21 EE

Awesome progress, i never had any good argument or proof but i always had the intuition that there was some way to tamper with the bittraining

 

[DoublesAdvocate]

Guys maybe you can try to launch ps2 games on these units when temperature is around 75? I know it's sounds strange, but last cecha unit I had was unmodded and it had same issue. PS2 games were working only on temps above 75, it had either freezing issues or black screen (basically it freezes on black screen during ps2 logo boot sequence, hence you see black screen)

Might be capacitor issue? I doubt it's related to ee+gs

Yes, I've noted this in a number of similar posts from people saying they get a black screen on their PS2 games when it drops below a certain temperature.
Although I've also seen people say that updating/disabling webman worked for them too so who knows.
Also it could be a resistor issue as well.

Also amazing work @M4j0r !

 

[sandungas]

Fix thermal config unk:     w 348B 8B
                            w 34AF 8B
Change RSX version to 40nm: w 3912 30
Write new training data:    w 3F62 EF 87 F9 19
                            w 3F69 07 F9 1D
                            w 3F6F 1F F9 0D
                            w 3F74 EF 0F F9 0D
                            w 3FA2 03 61 82 80 01 91

(the thermal config fix isn't mandatory)

Ok, not mandatory, the people using the orbis chip was not doing it anyway, but i would say is recommended, just as a small recap from the samples collected here
For a 65nm RSX we need to write the value 0x88
For a 40nm RSX we need to write the value 0x8B
For a 28nm RSX we need to write the value 0x89

To further test that I removed all my custom patches from the firmware, so now it's a stock 302GB Syscon.
By applying these patches to the EEPROM:

w 3242 03 61 82 80 01 91
w 3254 21 EC

a stock 302GB Syscon will train the 40nm RSX and the console will boot without any error.
And it doesn't matter wether 0x3912 is set to 0x11 for 90nm or 0x21 for 65nm. So you can train a 40nm RSX with the 90nm or 65nm data as long as you applied these patches to the EEPROM.
Just one note: If w 3254 21 EC doesn't work, use w 3254 21 EB since there're two different 40nm chip variants.
...
..
.

A little extra: If you plan on replacing the 90nm RSX with a 65nm one, try these patches:

w 3242 03 A2 03 B0 07 71
w 3254 21 E8

Edit (NOT TESTED):
3) For the 28nm RSX replace the second command with w 3254 21 EE

There is some way to identify that 2 versions of the 40nm RSX visually ?, im wondering if it matches with the presence of the IHS this way:
CXD2982xx = 65nm RSX with IHS so we need to write E8 ?
CXD2991xx = 65nm RSX with IHS so we need to write E8 ?
CXD5300xx = 40nm RSX with IHS so we need to write EB ?
CXD5301xx = 40nm RSX with IHS so we need to write EC ?
CXD5302xx = 40nm RSX without IHS so we need to write EC ?
D5305x = 28nm RSX without IHS so we need to write EE ?

Im assigning EC to CXD5301xx because in the way you explained the results of your tests it seems you achieved it when using EC and i guess it was a RSX with IHS (older than CXD5302xx anyway)
Dunno, in wiki we dont have enought info from that last RSX models

Edit (NOT TESTED):
3) For the 28nm RSX replace the second command with w 3254 21 EE

Btw, if someone finds the way to bring life into this frankenstein remember to share some photos of the monster. The pad layout is different, this differences doesnt means that is imposible, in theory if all the signals are present it could be posible but is a big challengue

 

[RIP-Felix]

Tutorial - Frankenstein Phat PlayStation 3
(How to Swap an unreliable 90nm RSX with a more reliable 65nn or 40nm)​

This is not an upgrade! It's is a path forward for repair when your RSX dies! The process is EXTREMELY difficult and likely to cause damage to the motherboard. There is a high chance your motherboard will be destroyed in the attempt. So it's better to consider performing this ONLY to repair a MB that already has a dead RSX.

Dr. Frankenstein reanimated the Dead. Only a Monster would kill the living

Spoiler: DISCLAIMER

If your console is running a FW revision below that which supports your RSX, then the MOD will cause a Green Light Of Death (GLOD)! You can enter safe mode, but can't see any video.

• 40nm RSX will not work with Firmware below 3.40. It should work from 3.40+, but we have only confirmed it as low as FW 3.55. So 3.55 should be considered the lowest safe FW for the 40nm RSX install.
• 65nm RSX "should" work with Firmware 3.20, but we're not sure how low you can downgrade. Possibly as low as 2.30, but we don't recommend it!

Why this matters:

1. You need to check that the console you are installing it on has a compatible firmware revision before performing the mod. Sometimes you can't because the console was YLOD and you are replacing the RSX to repair it. If that console was running a FW revision that's too low then you may get a GLOD. In this special case, you will need to use a Hardware Flasher to install a supported Firmware onto the NAND/NOR. Alternatively you can use a Factory Service Mode (FSM) JIG, but YOU MUST BE SURE THE FW IS NOT HIGHER THAN 3.55!!! Otherwise, you will be stuck in Factory Service Mode! Once you confirm the FW is too low, you can used the FSM JIG to update to 3.55, but DO NOT UPDATE TO 3.56 OR HIGHER! If you do you'll be stuck in service mode!!!
   • Don't assume that the GLOD is caused by the FW being too low. You need to be sure! Use the Southbridge UART output to see what FW revision is installed! If it's 3.55 or higher then the RSX should be working and this doesn't explain your GLOD. It's likly the reflow failed or the RSX you installed is dead.
2. OtherOS was removed after Firmware 3.20. Some people want to downgrade to 3.20 in order to enable it. If that's the case then you can't use the 40nm RSX. It isn't supported! The 65nm RSX should be, however. So that's your hucklberry.

Many thank to @mathieulh and @vyktormvmpay25 for bringing this to my attention and for helping me get the above information correct.

Spoiler: Backstory

Let's face it, the launch model PS3's are awesome! Whether you have the A/B models with Full Hardware based Backwards compatibility with PS2 games or the C/E models with Hybrid backwards compatibility, these are the most desirable consoles to own. However, due to their high launch price, SONY only sold 5.63 Million Backwards Compatible PS3's (models A - E). But there's a catch - the Dreaded Yellow Light of Death (YLOD)!

Sadly these early "Phat" model PS3's are dropping like flies! Their hot 90nm Graphics Processor, the "Reality Synthesizer (RSX)," has a flawed thermal design. You can read more about it here, but this post isn't about the problem, it's about the solution! Suffice it to say that you beloved Backwards compatible PlayStation 3 is going to crap out on you at some point, no matter what you do to prolong the inevitable. For the longest time you had to replace the 90nm RSX with another 90nm RSX...if you could find a working one! And that's the problem!

SONY sold 14.41 million PS3's with 90nm RSXs. G & H models for example have a 90nm and are not backwards compatible. So they have been a source of working 90nm RSX's for those who are willing to sacrifice a working console for it's GPU. But those consoles also go bad right and left. So the supply of 90nm RSX's has been steadily shrinking. And it's a crap shoot how long that used 90nm RSX will last! At one time there may have been "New Old Stock (NOS)" 90nm RSXs produced, but never installed. However, those were all bought up by reballers long ago. So now, 90nm RSXs are in short supply and those that are available are either bad or plucked from a working, albeit less desirable console - killing the living to resurrect the dead (Technomancer non-sense). It ain't natural!

That's just skirting the issue though. It's a war of attrition! Eventually the supply of 90nm RSX's will be gone. Then what?

Enter the Frankenstein Phat Playstation 3....

Around 2012 SONY's hardware and repair division had a problem. Early model PlayStation 3's were failing with bad RSXs. However by this time the 90nm RSX was out of production and not available anymore. Later model Phats with 65nm RSXs and then Slim models with 40nm RSXs were being manufactured. So SONY repair technicians had to find a way to replace the failing 90nm RSX with a more reliable, but really more available, 65nm RSX. Then again with 40nm RSX's.

About 2 years ago the OP started this thread. That's when we first became aware of he fact SONY had done this. Of course we were super stoked! The idea that we might be able to reverse engineer this method meant that we could finally resurrect and save these desirable consoles. But more than that, make it as reliable as the slim model!

A year went by. We knew what Sony had done, but hadn't been able to replicate the mod yet. Then we learned about the ORBIS modchip! 4-5 years before we even learned it was possable to swap a 90nm, @botakompong's brother "Kiaw" made a modchip that allows it! He and @botakompong could interchange 90nm, 65nm, and 40nm RSX's by just installing a chip and moving a few resistors! That wasn't possible before, because the console would recognize there wasn't a 90nm chip and refuse to boot (YLOD). The mod chip spoofs the RSX_ID and tricks the system into booting. An amazing accomplishment way before any of us had any idea this was going on!

Unfortunately, Kiaw passed away a few years ago and we never got to pick his talented brain about the modchip. His brother @botakompong has carried on the torch selling/installing the modchip out of his shop in Jakarta, Indonesia. @botakompong had been offering this service for years before we knew it was possible.

The ORBIS modchip made the swap even easier than SONY's method, which at the time we thought required replacing the SYSCON with a variant flashed with custom firmware. That's on top of the resistor and voltage mods. Kiaw's ORBIS modechip doesn't require any changes to the SYSCON at all! So it's an easier install.

We thought the ORBIS modchip was the ultimate solution! There are 21.5 Million 65nm RSXs in J -20xx model PS3s and at least 30 million 40nm RSXs in 21xx - 40xx models! And we can still source NOS 40nm RSX's! For the longest time we thought that those RSX's weren't compatible with the Backward Compatible models. They're pin compatible, yes. But they would just error in BitTraining with A0403034 if you tried. The SYSCON could not train the RSX. That's wht the ORBIS mod fixed! It allows the SYSCON to train a 65nm or 40nm RSX and get the system to boot!

There are many, MANY more Slim PS3's than there are BC models. This modchip makes sourcing replacement RSX's for BC PS3's sustainable. Every single BC model could easily get a 40nm RSX, since there are so many more slims out there! We don't have to throw Backward compatible PS3's away anymore!

Here is a good video summary of the above, for those interested in the details. @DeadEnd explains what SONY did in their official refurbished boards and summarizes our struggle to understand. Up to this point in the story...

Fast forward another year and @vyktormvmpay25 and @M4j0r made a MAJOR breakthrough! @M4j0r had sucessfully replicated SONY's method, but improved upon it! We thought that it would require a new SYSCON chip flashed with a special firmware to accomplish. That made it much more difficult than the ORBIS modchip. But @M4j0r's method only required a couple of writes to the eeprom over UART!

What this means is that it's now possible to replicate SONY's method! And more than that, we don't even need to flash custom firmware on a special variant SYSCON chip! We can leave the stock SYSCON on the on the board. We only need to write a few changes to the EEPROM over UART. That make this method cheaper and easier than the ORBIS mod! WOW!

That's the backstory. Now for the tutorials...

Note:

• I don't see the appeal of doing this mod to any console other than the Backwards compatible models, but if for some reason you want to install a 65nm or 40nm RSX on a non-BC model, you can. I'm just not familiar with those model revisions. They may follow the same general procedure or be very different. It's up to you to do your homework.
• The Tutorial below is written for COK-001 and COK-002 Motherboards. You will need to adapt it for your model, if you choose to do it on a different model MB. You have been warned!

Spoiler: (Required) Resistor mod

1. Remove R2054 & R2001*. They are not needed anymore.
   • Note: R2001 is only present on COK-001 motherboards. It is not populated on a COK-002 Motherboard. If you have a COK-002 Motherboard, you don't have to do anything to R2001.
   • Note 2: In official SONY refirbs they replace R2002 (49.9 ohm) with a 47k resistor. However, I don't understand why. It works fine leaving the 49.9 ohm in place. Removing R2001 effectively cuts off +1.5V_RSX_VDDIO to CGCLKI. The only thing I can remotely think of is that they wanted to increase the resistance to GND from 49.9 to 47k. Perhaps to prevent noise or shorting? But then, why not just remove it entirely? IDK
2. Scratch the GND plane next to R2054 to expose bare copper. We will use this to attach R2153.
   
3. Move R2153 (10kΩ) to the lower pad of R2054. Solder it diagonally to the GND pad you made in step 2. Confirm with a multimeter that the upper pad is not bridging, that it is isolated.
   

Spoiler: (Required) Replace RSX

1. Remove the 90nm RSX and replace with either a 65nm or 40nm RSX. This is a very difficult process and is only recommended for experts. It takes great skill and confidence in your equipment.

Spoiler: Pictures for those who like to see stuff

Masking the Bottom side of board to protect tokins, CPU and resistor mod...

Masking top side to prevent Flux from dripping through the Thermal Vias onto the preheater and catching fire! It also keeps the surrounding SMD's in place. However, the adhesive on the aluminum tape does leave a gross sticky residue that's harder to clean off. I think the trade off is worth it, but everyone's process is different.

This is my Ghetto Reballing setup. I don't recommend it, but it does work for me. It took alot of practice, and requires more babysitting than a proper SMD rework station, but can yield good result with practice. It cost me about $350 total to put together. And I've ruined 3 consoles learning to use it (so far)!

Prevent drafting air currents underneath the board...

Beyond this, I'm not going to bore you with the details. If you are contemplating this, you should already be familiar with reballing. To finish off show an tell, here's a Frankie with a 40...

Spoiler: (Required) Training/Tricking SYSCON

The SYSCON is expecting the original Model RSX to be installed. You can replace the RSX with the same model no problem. The SYSCON sees the same model is there and will go about it's merry business. However, now that you have replaced it with a 65nm or 40nm RSX, it will see there's an incompatible RSX model and loose it's mind!

We have to convince the SYSCON to accept the new RSX. There are 2 ways to do this.

Spoiler: (Optional) ORBIS Modchip

It works by spoofing the RSX_ID so the SCSCON believes there is still a 90nm RSX installed. As of February 2022 you can buy these from @David Rainer if you are in the United States. He purchased 100 of them to make them easily available to the community. Otherwise, @feel2death can hook you up.

Note:

• You will get a 3034/4xxx error if you do not hook the ORBIS up right. If you did it right, try another ORBIS chip. You may have damaged it or it may be defective.

Spoiler: (Optional) SYSCON EEPROM

Connect a UART adapter to the SYSCON. You will need to write some changes to the eeprom so the SYSCON can train the new RSX. If you don't already know how to do this, here is a SYSCON Tutorial.

The following sections contain the commands you will need to write to swap any 65nm or 40nm RSX into any motherboard revision. First, find the section that corresponds to the RSX you want to swap into your motherboard. Make sure your motherboard revision and SYSCON model number matches that section! Then write the commands listed there. Make note of the address where you need to fix the checksum. It's in the bullet point beneath each section.

There is an example of how to fix the checksum at the end.
________________________________________________________________
PS3 Models: CECHAxx, CECHBxx, CECHCxx, CECHExx, CECHGxx, CECHHxx, CECHJxx, CECHKxx, DECR-1400
Motherboards: COK-001, COK-002, SEM-001, DIA-001, DIA-002, DEB-001
Syscons: CXR713120-201GB, CXR713120-202GB, CXR713120-203GB, CXR714120-301GB, CXR714120-302GB

65nm RSX Series (with IHS): CXD2982xxx, CXD2991xxx

w 3242 03 A2 03 B0 07 71 w 3254 21 E8 w 348B 88 w 34AF 88

40nm RSX Series: CXD5300xxx, CDX5301xxx, & CXD5302xxx

w 3242 03 61 82 80 01 91 w 3254 21 EC w 348B 8B w 34AF 8B

• Fix checksums at addresses 32FE and 34FE
• Note: "EC" may not work with all 40nm RSX's. If you still get an error, try "EB." It has been noted that the CXD5300GGB needed the EB command

________________________________________________________________
PS3 Models: CECHLxx, CECHMxx, CECHPxx, CECHQxx, CECH-20xx
Motherboards: VER-001, DYN-001
Syscons: SW-301, SW-302, SW2-301

40nm RSX Series: CXD5300xxx, CXD5301xxx, & CXD5302xxx

w 182 03 61 82 80 01 91 w 194 21 EC w 3AC 8B

• Fix checksum at address 7FE
• Note: "EC" may not work with all 40nm RSX's. If you get a 3034 error (often with 4002 and a BitTraining FlexIO_ID error), try "EB." It has been noted that the CXD5300GGB needed the EB command.

________________________________________________________________
PS3 Models: CECH-21xx
Motherboards: SUR-001
Syscons: SW2-302

40nm RSX Series (without IHS): CXD5302xxx

w 182 03 61 82 80 01 91 w 194 21 EC

• Fix checksum at address 7FE
• Note: "EC" may not work with all 40nm RSX's. If you get a 3034 error (often with 4002 and a BitTraining FlexIO_ID error), try "EB." It has been noted that the CXD5300GGB needed the EB command.
  ________________________________________________________________

PS3 Models: CECH-25xx, CECH-30xx
Motherboards: JTP-001, JSD-001, KTE-001
Syscons: SW2-303, SW3-301

40nm RSX Series (without IHS): CXD5302xxx

w 224 21 EC

• Fix checksum at address 7FE
• Note: "EC" may not work with all 40nm RSX's. If you get a 3034 error (often with 4002 and a BitTraining FlexIO_ID error), try "EB." It has been noted that the CXD5300GGB needed the EB command.

________________________________________________________________
PS3 Models: CECH-40xx
Motherboards: MPX-001, MSX-001
Syscons: SW3-302

40nm RSX Series: CXD5300xxx, CXD5301xxx, & CXD5302xxx

w 224 21 EC

• Fix checksum at address 7FE
• Note: "EC" may not work with all 40nm RSX's. If you get a 3034 error (often with 4002 and a BitTraining FlexIO_ID error), try "EB." It has been noted that the CXD5300GGB needed the EB command.

________________________________________________________________
Note: These changes will cause a checksum mismatch. You need to Fix the checksums at the addresses listed in the bullet point beneath each section above.

Here is an example of me fixing the checksum at address 32FE on a COK-001 after a 40nm swap :

>$ eepcsum
eepcsum
sum:0xee10
Addr:0x000032fe should be 0xffff64a7
Addr:0x000034fe should be 0x7115
Addr:0x000039fe should be 0x0f38
Addr:0x00003dfe should be 0x00ff
Addr:0x00003ffe should be 0x00ff
​

You can see the line after "sum:0xee10" says that the checksum at address "32fe" should be "0xffff64a7." You can ignore the "ffff." 64a7 is what I needed to write to fix the checksum, but yours may be different. So you need to read what your checksum should be and write that.

However, endian byte swapping requires us to write it "a7 64." They are just flipped around...

>$ w 32fe a7 64
w 32fe a7 64
w complete!
[mullion]$​

I command I needed to write was "w 32fe a7 64." It completed successfully! I then used the eepcsum command again to see if there were any more checksum mismatches.

>$ eepcsum
eepcsum
Addr:0x000032fe should be 0x64a7
Addr:0x000034fe should be 0x7115
Addr:0x000039fe should be 0x0f38
Addr:0x00003dfe should be 0x00ff
Addr:0x00003ffe should be 0x00ff
>$​

You can see this time the "sum:0xee10" line disappeared. That means I had no mismatches. I have successfully written the change to enable the new 40nm RSX and fixed the checksum so the console will boot. However, that's only because I didn't make any changes at address 34FE. You will need to repeat this procedure one more time for address 34FE to fix there checksum you change there. But the procedure is the same.

Note: You can choose either option, but you must choose 1 of the 2 methods or you will get a YLOD with SYSCON errors 3034/4002.

Spoiler: (Required) VDDR Voltage MOD

If replacing with a 40nm RSX, VDDR needs a voltage mod to reduce the nominal 1.2V to 0.95V. For a 65nm RSX, VDDR needs to be reduced to 1.0v. Both 40nm and 65nm will function without doing this, but reduce it's lifespan. We want the lifespan of the RSX to be as long as possible, that's the whole point! So you should do this.

There are 2 ways to accomplish this for the 40nm (1.2v --> 0.95v). For 65nm (1.2v --> 1.0v), you'll have to use option 2.

• NOTE: If either of these fail and the RSX_VDDR voltage does not form, is short, or not soldered correctly, you will get an A0403034 (often with A0404002) and a BitTraining FlexIO_ID error. This is the same error you would get if you input the wrong SYSCON training data or did not do so at all. If you perform the VDDR voltage mod before testing the console 1st, it can be hard to know if the SYSCON training went wrong, or the voltage mod did. Therefore it's advisable to train the syscon to accept the new RSX 1st and then test to see if it worked, before continuing to the voltage mod. Just so you know that the replacement is good and training is successful. Then if you have an issue during the voltage mod, you know it's related to the voltage mod, not the RSX training or soldering.

1. @botakompong's method works and is easier. But it's also hackier. It only works on 40nm RSX.
   
   Spoiler: 40nm Only

   We need to remove the Voltage regulator that supplies VDDR from a slim model that has a 40nm RSX. The Regulator you are looking for will be in the same location next to the RSX. It's the only one so you can't miss it

   

   
   

   1. Lift Pins 2, 3, and 4 so they will be floating.
   2. Remove Q6200 from the phat and replace it with the Regulator you harvested from the slim. Pins 2, 3, & 4 should be floating
      
   3. Bridge Pins 2 & 3 and run a jumper wire to C6202 as seen in the image above. Pin 4 should be floating.
   4. This will will reduce the voltage to 0.95V and extend the operating life of the 40nm RSX. But this IC only outputs 0.95v. I can't be used on a 65nm that needs 1.0v.

   Note: This method dissconnects the SYSCON's control of this voltage. IC6200 is a MOSFET controller that drives Q6200 (The MOSFET you removed). SYSCON enables the controller, which in turn gates the MOSFET. By removing the MOSFET and replacing it with a Voltage regulator, the SYSCON in non the wiser. It's still connected to the controller and assumes all is fine.
   
   The Voltage regulator bypasses the controller. It doesn't wait to be turned on by the controller. It regulates as soon as it is powered. I have done some voltage testing and found that VDDR is one of the earliest voltages enabled. It turns on almost as soon as it's supply voltage is. So it just so happens that removing the control doesn't matter in this case. In general, it would be a bad idea, because voktages are supposed to be sequenced. Brought up in order. It just doesn't matter here.
   
   That's what I mean by it works, but is hacky.​
2. SONY's Method is cleaner and more proper, but requires difficult micro-soldering.
   
   Spoiler: 40nm or 65nm

   1. SONY's approach was to replace IC6200 (BD3520 N-Channel MOSFET controller) with a model that allows user selected output voltage using external resistors (BD3504). IC6200 drives MOSFET Q6200. So SONY's method is better because it doesn't circumvent the circuit protection and control. But it works for both the 40nm and 65nm RSX. You just need to use different resistors.
      
      
      
   2. Here are where you can harvest BD3504's on a COK-00X motherboard. Also the locations of 3.9k, 2.2k, and 4.7k resistors for the voltage mods Myself and @DeadEnd calculated. They are not exactly equal to what SONY did, but they are close enough to not matter.
      Spoiler: Part Locations

      

      

      
   3. Replace BD3520 with BD3504 and populate a few resistors to Set Vout to approximately 0.95 Volts (for 40nm RSX) or 1.0v (for 65nm RSX).
      • Math:
        • R1 = R6216 (3900) = VFB/GND
        • R2 = R6222 (1800) = VFB/VS
        • R1'= R6214 (3900) = VD/GND
        • R2' = R6219 (1800) = VD/Vin
      • Vout = VFB ( [R1' + R2] / R1' ), where VFB is 0.65v.
        • Vout 40nm RSX = 0.65 ( [3900+1800] / 3900) = 0.95v_VDDR
          Spoiler: SONY's Resistor network

          
        • Vout 65nm RSX = 0.65 ( [3900 +2100] / 3900) = 1.00v_VDDR
          Spoiler: SONY's Resistor Network

          
      • SONY's method above works well, but you need to buy resistors for it to work, since 1.8k and 2.1k resistors can't be found on COK-00X motherboards. @DeadEnd and I have calculated the following resistor networks to come close, but with the added advantage that all the resistors can be harvested from COK-00X donor boards.
        • Vout 40nm RSX = 0.65 ( [4.7k+2.2k] / 4.7k) = 0.951v_VDDR
          Spoiler: DeadEnd's Resistor network

          
        • Vout 65nm RSX = 0.65 ( [3.9k+2.2k] / 3.9k) = 1.02v_VDDR
          Spoiler: RIP-Felix's Resistor Network

          

Spoiler: (Not Reccomended) Lowering Power Good Low Voltage Threshold

SONY Adjusted the Power Good Low Voltage Threshold in some of their Frankenstein Phat PS3s. My hypothesis is SONY did this to reduce the frequency of 1001 and 1002's errors, which can be caused by bad TOKINS (among other VRM related issues). That would explain why they did it to the buck controllers for both the CPU and GPU. A sort of admission of guilt that they either set it too aggressively or were compensating for bad NEC/TOKINs, without replacing them.

The benefit is reduce the likelyhood that failing NEC/TOKIN's cause a YLOD. Essentially, it allows more voltage ripple into the CELL and RSX before triggering an error. Replacing aged bulk filter capacitors certainly works, but just because replacing NEC/TOKIN works doesn't mean that's the only way to prevent a YLOD.

Power good low voltage threshold protects the system from instability. Evidently, SONY repair technicians decided it was "preferable " (for them) to lower it in some of these officially refurbished consoles.

Vid pins VID0-5 on IC6201 and IC6103 (RSX & CELL Buck controllers respectively) form a 6-digit code corresponding to the Vout No load setpoint. Power Good Vmin and Vmax thresholds are relative to that set point. With the stock COK-00X (A - E models) voltage divider values (15K and 20k), Vmin = -163mV. Vmax is always +100mV. The Vout voltage cannot deviate more than that. If it does power good goes low and the SYSCON will error.



In some official SONY refurbished consoles, new resistor values (27K and 10K) change Vmin = -400mV. So the Low Voltage threshold is now more than twice as low, allowing much more voltage ripple before it triggers an error.

It is my opinion this modification is harmful, not proper. Just because SONY authorized service center performed this "repair" doesn't mean it's a good idea. I think SONY technitions chose to go this route on some consoles, rather than replace the NEC/TOKINs. Perhaps because they were expensive or unavailable, but more likely because they are very difficult to replace without risking damage to the board.

I believe it is irresponsible to allow more ripple/noise to enter the processors before the SYSCON registers an error. That is lazy and will cause the console to die sooner! The real solution to bad capacitors is to REPLACE THEM! By way of analogy, "if the check engine light on your car is on, this hack is like unplugging the bulb instead of getting the car serviced!" You didn't fix the problem, you disabled the warning!

If you choose to perform this hack, you'll need to figure it out on your own. It will force you to become somewhat familiar with what I'm talking about. Perhaps you'll rethink your decision. I will not help you any further with this hack, because it believe it does more harm to the console and any future owner, than good. If you can't figure it out without help, good! You shouldn't be performing this anyway!

Shame on SONY for charging customers the refurbishing fee, only to disable a safety feature that protects much more critical components, without which the console is truly unfixable. Killing the GPU and CPU to avoid a recap is irresponsible and unprofessional. If not libelous!

 

[truemaster]

amazing progress here.

 

[Computer Booter]

@M4j0r @RIP-Felix @vyktormvmpay25 we can try this on the one I just did, it has 40nm on it.

By the way, do we have a thread for just RSX readings? I was wondering where I should upload either the link to the document, or just paste the readings for those RSX readings we did? I can share the document link which ill be updating with further readings, ill also be updating the document to say if the RSX worked after installing it, or maybe didn't

Link to RSX Readings Document (will update with more readings/results):
https://1drv.ms/x/s!AoLlar2_zQeitfgm-Pr6SVzcUTog2A?e=qucXoc

 

[vyktormvmpay25]

http://s.go.ro/sm984sd4 it is booting but need more patches not sure where now?
OK added boot after writing this but after off/on it comes with csum error which I can't remember but it is kind eppcsum need patch.
So is per case patch? Should I write 32FE 7c 64? Or bring it back to initial stage to be sent to @M4j0r ?
Edit
It says fine so we need to test more case, this is per case situation mine fixed with w 32FE 7c 64.
Dang guys it boot!

 

[BwE]

Frankenstein Phat PlayStation 3
(How to Swap an unreliable 90nm RSX with a more reliable 65nn or 40nm)​

@M4j0r @DeadEnd @sandungas please double check my work below. I would like this post to become the de facto tutorial to get this working:

Spoiler: Backstory

Let's face it, the launch model PS3's are awesome! Whether you have the A/B models with Full Hardware based Backwards compatibility with PS2 games or the C/E models with Hybrid backwards compatibility, thse are the most desirable consoles to own. But there's a catch - the Dreaded Yellow Light of Death (YLOD)!

Sadly these early "Phat" model PS3's are dropping like flies! Their hot 90nm Graphics Processor, the "Reality Synthesizer (RSX)," has a flawed thermal design. You can read more about it here, but this post isn't about the problem, it's about the solution! Suffice it to say that you beloved Backwards compatible PlayStation 3 is going to crap out on you at some point, no matter what you do to prolong the inevitable...Until now!

Enter the Frankenstein Phat Playstation 3....

Around 2012 SONY's hardware and repair division had a problem. Early model PlayStation 3's were failing with bad RSXs. However by this time the 90nm RSX was out of production and not available anymore. Later model Phats with 65nm RSXs and then Slim models with 40nm RSXs were being manufactured. So SONY repair technicians had to find a way to replace the failing 90nm RSX with a more reliable, but really more available, 65nm RSX. Then again with 40nm RSX's.

About 2 years ago the OP started this thread. That's when we first became aware of he fact SONY had done this. Of course we were super stoked! The idea that we might be able to reverse engineer this method meant that we could finally ressurect and save these desirable consoles. But more than that, make as reliable as the slim model!

A year went by. We knew what Sony had done, but hadn't been able to replicate the mod yet. Then we learned about the ORBIS modchip! 4-5 years before we even learned it was possable to swap a 90nm, @botakompong's brother "Kiaw" made a modchip that allows it! He and @botakompong could interchange 90nm, 65nm, and 40nm RSX's by just installing a chip and moving a few resistors! That wasn't possible before, because the console would recognize there wasn't a 90nm chip and refuse to boot (YLOD). The mod chip spoofs the RSX_ID and tricks the system into booting. An amazing accomplishment way before any of us had any idea this was going on!

Unfortunately, Kiaw passed away a few years ago and we never got to pick his talented brain about the modchip. His brother @botakompong has carried on the torch selling/installing the modchip out of his shop in Jakarta, Indonesia. @botakompong had been offering this service for years before we knew it was possible.

The ORBIS modchip made the swap even easier than SONY's method, which at the time we thought required replacing the SYSCON with a variant flashed with custom firmware. That's on top of the resistor and voltage mods. Kiaw's ORBIS modechip doesn't require any changes to the SYSCON at all! So it's an easier install.

We thought the ORBIS modchip was the ultimate solution! We can still source NOS 40nm RSX's! And there are many, MANY more Slim PS3's than there are BC models. This modchip makes sourcing replacement RSX's for BC PS3's sustainable. Every single BC model could easily get a 40nm RSX, since there are so many more slims out there! We don't have to throw them away anymore!

Fast forward another year and @vyktormvmpay25 and @M4j0r made a MAJOR breakthrough!

@M4j0r said, quote:

"Some interesting news:
I received a test console (DIA-002 with 40nm RSX and CXR713F120A Syscon) from @vyktormvmpay25
And that did some extreme speed up to the 40nm RSX Syscon patches development.

First I tried to copy the official Sony procedure, for that I flashed the 304GB (v1.5.1k2) firmware to the Syscon and performed the following patches to the original (DIA-002) EEPROM:

Fix thermal config unk:     w 348B 8B
                            w 34AF 8B
Change RSX version to 40nm: w 3912 30
Write new training data:    w 3F62 EF 87 F9 19
                            w 3F69 07 F9 1D
                            w 3F6F 1F F9 0D
                            w 3F74 EF 0F F9 0D
                            w 3FA2 03 61 82 80 01 91

(the thermal config fix isn't mandatory)
And it worked! That's the first "official" 40nm swap that wasn't done by Sony.
But of course that's not really surprising since we just copy what Sony did.

After that test I flashed the 302GB (v1.4.4k2) firmware to Syson, that's the DIA-002 standard Syscon firmware.
I did apply many patches to that firmware to debug the RSX FlexIO training and discovered something very interesting! Even though the 90nm/65nm/40nm RSX need different FlexIO training data/algorithm you can just use the 90nm/65nm data/algorithm to train a 40nm chip and it'll work. RSX will complain a lot to Syscon but Syscon can ignore that.

To further test that I removed all my custom patches from the firmware, so now it's a stock 302GB Syscon.
By applying these patches to the EEPROM:

w 3242 03 61 82 80 01 91
w 3254 21 EC

a stock 302GB Syscon will train the 40nm RSX and the console will boot without any error.
And it doesn't matter wether 0x3912 is set to 0x11 for 90nm or 0x21 for 65nm. So you can train a 40nm RSX with the 90nm or 65nm data as long as you applied these patches to the EEPROM.
Just one note: If w 3254 21 EC doesn't work, use w 3254 21 EB since there're two different 40nm chip variants.

I also did test that on the 203GB (v1.2.3k1) and 301GB (v1.3.3k1) Syscon firmwares and it works too!
(I needed to patch these firmwares in order to work on the DIA-002 but I didn't touch anything RSX related).
That means the same patches work on SEM-001 and DIA-001 (and of course DEB-001).

I can't perform the final test since I have no COK board with a 40nm RSX, but since the other chips can train a 40nm RSX with the 90nm training data, the same EEPROM patches should do the job on the 201GB/202GB Syscon. Maybe someone can test that .

In summary (TLDR): A 203GB/301GB/302GB Syscon supports 40nm RSX after applying two EEPROM patches. 201GB/202GB haven't been tested yet but should in theory work since it's the same code.

A little extra: If you plan on replacing the 90nm RSX with a 65nm one, try these patches:

w 3242 03 A2 03 B0 07 71
w 3254 21 E8

Edit (NOT TESTED):
1) For SW/2 Syscons use offset 0x182 instead of 0x3242 and 0x194 instead of 0x3254
2) For SW3 Syscons use offset 0x212 instead of 0x3242 and 0x224 instead of 0x3254
3) For the 28nm RSX replace the second command with w 3254 21 EE"​

End of quote.

What this means is that it's now possible to replicate SONY's method! And more than that, we don't even need to flash custom firmware on a special variant SYSCON chip! We can leave the stock SYSCON on the on the board. We only need to write a few changes to the EEPROM over UART. That make this method cheaper and easier than the ORBIS mod! WOW!

Why SONY changed the SYSCON chip in the first place is still a mystery.

That's the backstory. Now for the tutorials...

TUTORIAL​

Resistor mod

1. Remove R2054 & R2001*. They are not needed anymore.
   • Note: R2001 is only present on COK-001 motherboards. It is not populated on a COK-002 Motherboard. If you have a COK-002 Motherboard, you don't have to do anything to R2001.
2. Scratch the GND plane next to R2054 to expose bare copper. We will use this to attach R2153. View attachment 36347
3. Move R2153 (10kΩ) to the lower pad of R2054. Solder it diagonally to the GND pad you made in step 2. Confirm with a multimeter that the upper pad is not bridging, that it is isolated.View attachment 36348

Replace RSX

1. Remove the 90nm RSX and replace with either a 65nm or 40nm RSX. This is a very difficult process and is only recommended for experts. It takes great skill and confidence in your equipment.
   
2. If replacing with a 40nm RSX there is an additional step. VDDR needs a voltage mod to reduce the nominal 1.2V to 0.95V. This is not needed for a 65nm RSX. There are 2 ways to accomplish this. @botakompong's method works and is easier. But it's also hackier. SONY's Method is cleaner and more proper, but requires difficult micro-soldering.

Spoiler: @Botakompong's Method

1. We need to remove Q6200 (N-Channel MOSFET) from a slim model which has a 40nm RSX. The MOSFET you are looking for will be in the same location next to the RSX. It's the only one so you can't miss itView attachment 36349
2. Lift Pins 2, 3, and 4 so they will be floating.
3. Remove Q6200 from and replace it with the one you harvested from the slim. Pins 2, 3, & 4 should be floatingView attachment 36345
4. Bridge Pins 2 & 3 and run a jumper wire to C6202 as seen in image above. Pin 4 should be floating.
5. This will reduce the voltage to 0.95V and extend the operating life of the 40nm RSX.

Spoiler: SONY's Method

1. SONY's approach was to replace IC6200 (BD3520 N-Channel MOSFET driver) with a model that allows user selected output voltage using external resistors (BD3504). IC6200 drives MOSFET Q6200. So SONY's method is better because it uses a cotroller to set and control the voltage instead of hacking the MOSFET. But both methods work.View attachment 36352 View attachment 36351
2. Replace BD3502 with BD3504 and populate a few resistore to Set Vout to 0.95 Volts.
   • Populate R6216 with 3900 Ohm resistor
   • Populate R6214 with a 3900 Ohm Resistor
   • Math:
     • R1 = R6216 (3900) = VFB/GND
     • R2 = R6222 (1800) = VFB/VS
     • R1'= R6214 (3900) = VD/GND
     • R2' = R6219 (1800) = VD/Vin
   • Vout = VFB ( [R1' + R2] / R1' ), where VFB is 0.65v.
   • Vout = 0.65 ( [3900+1800] / 3900) = 0.95v_VDDR
3. Lastly, SONY Adjusted the Power Good Low Voltage Threshold. Vid pins VID0-5 on the IC6201 and IC6103 (RSX & CELL Buck controllers respectively) form a 6-digit code corresponding to the Vout No load setpoint. Power Good Vmin and Vmax thresholds are relative to that set point. With the stock COK-00X voltage divider values (15K and 20k), Vmin = -163mV. Vmax is always +100mV. The Vout voltage cannot deviate more than that. If it does power good goes low and the SYSCON will error.
   
   
   
   In some official SONY refurbished consoles, new resistor values (27K and 10K) change Vmin = -400mV. So the Low Voltage threshold is now more than twice as low, allowing much more voltage ripple before it triggers an error. My hypothesis is SONY did this to reduce the frequency of 1001 and 1002's errors, which can be caused by bad TOKINS (for example). That would explain why they did it to both buck controllers (CPU and GPU). A sort of admission of guilt that they either set it too aggressively or were compensating for bad NEC/TOKINs, without replacing them.
   
   Power good low voltage threshold is there to prevent system instability, but if SONY decided it was okay to lower it, then perhaps we can follow suit. It could be particularly important because we're seeing a lot of unexplained 1001's recently. Currently, 1002's are assumed to be bad NEC/TOKIN's. Replacing aged bulk filter capacitors certainly works, but just because changing them fixes the error doesn't mean that's the only way to skin a cat.

Training/Tricking SYSCON:
There are 2 ways to do this.

Spoiler: ORBIS Modchip

It works by spoofing the RSX_ID so the SCSCON believes there is still a 90nm RSX installed. As of February 2022 you can buy these from @David Rainer if you are in the United States. He purchased 100 of them to make them easily available to the community. Otherwise, @feel2death can hook you up.
View attachment 36353

Note:

• You will get a 3034/4xxx error if you do not hook the ORBIS up right. If you did it right, try another ORBIS chip. You may have damaged it or it may be defective.

Spoiler: SYSCON EEPROM

For 65nm RSX:

w 3242 03 A2 03 B0 07 71
w 3254 21 E8

Fix checksum @ 0x32FE
Reset syscon, start console

For a 40nm RSX...
I'm quoting @M4j0r here...

"The easiest test on a COK-001 or COK-002 with 40nm would be to run these commands and see if it'll boot:

w 3242 03 61 82 80 01 91
w 3254 21 EC

or

w 3242 03 61 82 80 01 91
w 3254 21 EB

If that doesn't work I'll need another testbed."

[/QUOTE]
I love you <3

 

[sandungas]

http://s.go.ro/sm984sd4 it is booting but need more patches not sure where now?
OK added boot after writing this but after off/on it comes with csum error which I can't remember but it is kind eppcsum need patch.
So is per case patch? Should I write 32FE 7c 64? Or bring it back to initial stage to be sent to @M4j0r ?
Edit
It says fine so we need to test more case, this is per case situation mine fixed with w 32FE 7c 64.
Dang guys it boot!

Yes, the checksum that needs to be fixed at 32FE probably is different for every motherboard, in the output of the command "eepcsum" it was telling what to write (but is displayed with a bug starting with ffff)... we need to ignore the first ffff and write the other 2 next bytes (64 7C in this case)

>$ eepcsum
eepcsum
sum:0xee10
Addr:0x000032fe should be 0xffff647c
Addr:0x000034fe should be 0x710b
Addr:0x000039fe should be 0x0038
Addr:0x00003dfe should be 0x00ff
Addr:0x00003ffe should be 0x00ff

It can be seen in the output of this command, are the last 2 bytes (originally 8C 52)

>$ r 3200 100
r 3200 100
+0 +1 +2 +3 +4 +5 +6 +7 +8 +9 +A +B +C +D +E +F
-----------------------------------------------
FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF
FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF
FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF
FF FF FF FF 80 40 80 80 FF FF FF FF FF FF FF FF
FF FF 03 61 82 80 01 91 FF FF FF FF FF FF FF FF
80 40 FF FF 21 EC FF FF FF FF FF FF FF FF FF FF
FF FF FF FF FF FF 80 40 FF FF FF FF FF FF FF FF
FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF
FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF
03 00 00 00 20 00 00 00 FF FF FE FF 00 FF FF FF
FF FF 19 FF FF FF FF FF FF FF FF FF FF FF FF FF
FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF
FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF
FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF
FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF
FF FF FF FF FF FF FF FF FF FF FF FF FF FF 8C 52

Is nice it works, so COK-002 also confirmed, @DeadEnd also confirmed the patch published by m4j0r is valid for another COK-002 with 65nm RSX here
Now is only missing a confirmation for COK-001