PS3 Frankenstein PHAT PS3: CECHA with 40nm RSX

Bad news, good news. Didn't work. But, the board I was trying it on was inconclusive in all diagnostics I tried, so it doesn't necessarily mean it doesn't work. I'll put the original GPU back on and move the resistor back tomorrow, then put the slim GPU back on the slim system. If both work then, I'd call that conclusive.
Have you checked CGRESET pin on the Slim model? Is it grounded or connected to SYSCON?

Would be cool if @M4j0r could dump that one to see if they passed any special trickery to I via update.
If it's possible to get SYSCON update info via UART, I could do it. But I don't want to install OtherOS or attach logic analyzer - too much hassle and I'm not wiling to turn this PS3 into test bench.
 
Last edited:
Wasn't those last model Phats having the same board as first model slims? Ver-001? I recall when doing my hard mod to my cech l00. That it shared many similarities to 2k slim consoles. Maybe they take the rsx, move that resistor , and swap out syscon from a 2k series board. Would be cool if @M4j0r could dump that one to see if they passed any special trickery to I via update.
Wouldn't that mean if you updated it normally though and syscon was updated, it would make this console break from not being a normal update? So many questions

The CECHL/CECHM/CECHP/CECHQ and slim models don't use the same Syscon like the earlier models. Sony stopped rolling their own Syscon (CXR) with the CECHK and switched to NEC/Renesas components with a different package (called SW = Sherwood).
There's one exception though, the DECR-1400A. This phat devkit is based on a mix of different PS3 models and was released between the last phat console and the first slim console. It's still using the old CXR Syscon.
The latest CXR Syscon which could be found on a PS3 is the CXR714120-302GB. 302GB means FW version 1.4.4k2. This firmware is also used by the DECR-1400A. It says Copyright 2007.
But the Syscon on this console says CXR714120-304GB and Copyright 2010. That's pretty weird, like it has to be a spare part because there was no PS3 anymore in production at that time which uses the CXR Syscon. The slim already launched in 2009.
We know that Sony even released Syscon firmware version 1.5 for the CXR, but we never found it.
So the chances are very high that the 304GB suffix probably means that the Syscon ROM contains a firmware with version > 1.4.

If it's possible to get SYSCON update info via UART, I could do it. But I don't want to install OtherOS or attach logic analyzer - too much hassle and I'm not wiling to turn this PS3 into test bench.

Yes, it's possible by just utilizing the UART interface (3.3V / 57600 baud 8N1).
cok-001.png
You can use this script to get the softid: https://pastebin.com/4ymiFQbi
Code:
./script.py <serial port> CXR
Then
Code:
VER
The diag pin isn't needed for that.
 
Last edited:
It was a known working slim GPU, the CECHA board was not. CGRESET not grounded on the slim, either. I'll leave it on for a day or two while you guys brainstorm and let me know if you come up with any ideas. Screwing with the firmware on these is out of my wheelhouse so you may need to speak slowly and draw a diagram in crayons for anything you want me to do. I don't have a logic analyzer, but my scopes got 4 channels so I can pretend.
 
Last edited:
Ok, I've soldered UART wires, test leads for RSX/CELL VDD and assembled the thing. Quick test, everything works. Here is "More System Info":

photo_2020-02-06_05-46-51.jpg

@M4j0r, how can I check that PS3 UART works (i.e. everything soldered properly) before running the script? If I just connect to UART, setting baud rate to 57600, and restart PS3 - will it send something to UART during startup? Script is only needed for calculating checksum or it is doing something else?

Edit:

Nevermind, already figured that out.
Code:
C:ED:VER
R:3B:OK 00000000 0F38

So it's telling the same thing as "More System Info" - SoftID is 0F38.

If someone is interested in the back sticker, here it is:

photo_2020-02-06_11-58-02.jpg

Unfortunately, it doesn't have production date.
 
Last edited:
Nevermind, already figured that out.
Code:
C:ED:VER
R:3B:OK 00000000 0F38

Thanks, very nice! That's indeed one of the firmwares which Sony never used on any retail PS3. So dumping it would be very useful.
The dump process completely works over UART, but it requires no Syscon patch to be installed in the first place.
The current patch (0001000500010001) needs to be overwritten, which is only possible by using the a special PUP. So the console needs to be expolitable.
Since the sticker says 2012 and Sony tends to update some perconsole stuff at service centers there's a chance that the console is enforced to only run e.g firmware 4.10+.
You can check this by trying to install this version check PUP: https://mega.nz/#!FUVm1C7a!IbCyN_uzCQh7hZb7eu3pRrwBuezLh1r4Ha7eeB9RlZk .
 
This PUP, is it MinVerChk? I presume that if it will say that minimum version is higher than 3.56, then CFW can't be installed?

Yes, it's the mininmal version check pup. We need to either install a PUP or have hypervisor access to delete the Syscon patch. HEN doesn't have hypervisor access.
 
So you CAN get refurbed fat consoles with a minver higher than 3.56 that are not CFW compatible? That is something to take note of if true. I always tell people with fats that there is no need to check minver.
 
All Fat PS3 are cfw compatible. The last fat ps3 has minimum firmware 2.5 so no need for minver on fats.
Except tin frankenmonster. because when is the syscon changed there is probaly another minver.
 
Well yeah, but if there is one fat that is not CFW compatible, then there is probably more than one out there as its unlikely this is one off repair. So maybe we can no longer say "All Fat PS3 are cfw compatible". Maybe we can say "All Fat PS3 are cfw compatible unless the syscon has been changed".
 
Well yeah, but if there is one fat that is not CFW compatible, then there is probably more than one out there as its unlikely this is one off repair. So maybe we can no longer say "All Fat PS3 are cfw compatible". Maybe we can say "All Fat PS3 are cfw compatible unless the syscon has been changed".
correct
 
So to be extra safe when we tell new users that if they have ANY slim they should check minver in case its been refurbished, now that should apply to all consoles really..

As well we would never really know if this effected someone with a fat before now, it would just brick when patching for cfw and we would assume user error or bad flash probably.
 
At this point what do you think about the origins of this frankenstein PS3 @M4j0r ?
I mean, it could be a prototype... but when they does a prototype is because they are trying to test "something"... but wtf was that "something" ?
A motherboard from 2006 + a non-retail syscon from 2010 + a non-retail rsx from 2012... i cant imagine why that megamix could be useful for them

Chronologically the syscon could match with the DECR-1400A/DEB-001 but i dont see the relationship
 
Last edited:
So you CAN get refurbed fat consoles with a minver higher than 3.56 that are not CFW compatible? That is something to take note of if true. I always tell people with fats that there is no need to check minver.

Well, Sony can update lv0ldr and metldr at factory. Also the spare parts can introduce problems on lower firmwares, e.g. firmware 1.00 won't support that rsx.

At this point what do you think about the origins of this frankenstein PS3 @M4j0r ?
I mean, it could be a prototype... but when they does a prototype is because they are trying to test "something"... but wtf was that "something" ?
A motherboard from 2006 + a non-retail syscon from 2010 + a non-retail rsx from 2012... i cant imagine why that megamix could be useful for them

Chronologically could match with the DECR-1400A/DEB-001 but i dont see the relationship

A prototype can be relatively easy distinguished from a repaired console. Sony uses new parts for the repair but reuses parts for prototypes. You can find for example some CEB components on some Cookie prototypes from 2006. That's why Sony wants prototypes back, they reuse the parts.
I think this was a repair covered by some warranty. Syscon is easily exchangeable and they had this model ready since at least 2010. The 40nm RSX was probably used because it was either planned or the only one available with the others being out of stock.
Adapting newer parts was probably cheaper then keeping all the old variants in stock.
 
I think this was a repair covered by some warranty. Syscon is easily exchangeable and they had this model ready since at least 2010. The 40nm RSX was probably used because it was either planned or the only one available with the others being out of stock.
Adapting newer parts was probably cheaper then keeping all the old variants in stock.

Yeah, there's absolutely no way they would have paid to fab an obsolete chip in low numbers just for repairs of a 6 year old system. And with the failure rate of those original chips, they had to have run out of spares long ago no matter how many extra they stockpiled. I'm positive they would use new chips even when it was "just" a BGA issue.

What's the prognosis here for my little monster? Are you expecting that it will just need some kind of simple tweak in the syscon, or can I go ahead and swap them back?

If this is looking like a more complicated issue now, I can always make a new monster later when there's something concrete to try.
 
What's the prognosis here for my little monster? Are you expecting that it will just need some kind of simple tweak in the syscon, or can I go ahead and swap them back?

Sony didn't change the Syscon initialization routine for the RSX between the 90nm and 65nm models. I don't know if the 28/40nm ones require some change.
 
Yeah, there's absolutely no way they would have paid to fab an obsolete chip in low numbers just for repairs of a 6 year old system. And with the failure rate of those original chips, they had to have run out of spares long ago no matter how many extra they stockpiled. I'm positive they would use new chips even when it was "just" a BGA issue.

They wouldn't have to pay for anything. The RSX is there property not Nvidia's, S@ny paid for it to be developed exclusively for them, and S@ny bought entire factories to continue making the RSX and the CELL/BE (These are still currently used in the PS Now servers so are still needed for server repairs etc...) when Nvidia and IBM would not make them anymore.

But I agree they would not manufacture an older chipset just for repair's, that would involve resetting machines and production lines just for a " Few " spares. Would cost thousands just to do, plus all the lost production time on other things would incur production downtime costs as well.

It's like this in any type of warranty repair for anything. If the OG part is not on hand or available to use then closest newest part is used and "made" to work whether it works out of the box or needs some type of modification to work, one way or another it repaired.
 
Good news, everyone!

photo_2020-02-07_01-27-30.jpg

So, the next step needed for the dump is installing CFW? I've already found a good CFW guide on Reddit, so it won't be a problem.
@M4j0r, do you have a guide for the steps after that, installing "special" PUP and dumping SYSCON FW with UART?

The current patch (0001000500010001) needs to be overwritten
Will it be destructive for SYSCON and can it be reverted?

BTW, could you please explain relation between SoftID and SYSCON FW patch? I've read PSDevWiki but haven't found comprehensible explanation. As I understand reading the Wiki, while in dev consoles to upgrade SYSCON FW it just flashed anew, in retail consoles it is upgraded via patches. But what is the real version of installed SYSCON FW? Is it SoftID (0F38) or patch version (v1.5.1r1)? On the Wiki I saw that one SoftID can have several patch releases: 0C16.v1.1.3r2, 0C16.v1.1.3r3, etc. When we make sure that "no SYSCON patches are installed in the first place", what version of SYSCON we will get?
 
Back
Top