PS3 Frankenstein PHAT PS3: CECHA with 40nm RSX

[DeadEnd]

Perhaps I should have said no one has successfully replicated SONY's method yet. @M4j0r seems to think it'd would work. I got the impression from @sandungas statements we don't know what every change to the eeprom does, or if all of them are necessary to make it work. But I don't pretend to understand the coding aspect.

I guess until someone proves it, it's all academic isn't it?

I think what i'm getting at is that it has been already proven among the developers circles. I might be wrong, but it's possible Sandungas is not always up to speed with what m4jor has been doing. And as we are also sometimes communicating off the forum, I got the impression there is nothing left to test. But of course when somebody makes a video of an actual working motherboard, then everybody can be more assured.

 

[ad-min]

@DeadEnd
Where does one get a flashable variant of a syscon?

 

[DeadEnd]

@DeadEnd
Where does one get a flashable variant of a syscon?

https://www.utsource.net/pro/CXR713F120A.html But the version from refurbished boards (CXR714120-304GB) would also work.

 

[ad-min]

Okay, I've probably figured out how to dump a syscon. The community at psdevwiki did a great job explaining the process.

Missing piece of the puzzle:

Then you copy your stock syscon eeprom through bus pirate and patch it , then load it into the new syscon.

What kind of values need to be patched?

 

[vyktormvmpay25]

Okay, I've probably figured out how to dump a syscon. The community at psdevwiki did a great job explaining the process.

Missing piece of the puzzle:


What kind of values need to be patched?

This is something per unit, only software developers programming can do/ understand, from there I'm noob completely, but if someone wants to test, ask here for help when all already prepared. Probably M4j0r may take a look and confirm if dump is good and if get time it may patch it.

 

[DeadEnd]

Okay, I've probably figured out how to dump a syscon. The community at psdevwiki did a great job explaining the process.

Missing piece of the puzzle:


What kind of values need to be patched?

I believe it was explained somewhere in this thread. I will refresh my memory when I actually get around to doing it

 

[sandungas]

Perhaps I should have said no one has successfully replicated SONY's method yet. @M4j0r seems to think it'd would work. I got the impression from @sandungas statements we don't know what every change to the eeprom does, or if all of them are necessary to make it work. But I don't pretend to understand the coding aspect.

I guess until someone proves it, it's all academic isn't it?

Lets put it this way... in the EEPROM of the first syscon models there are many writable areas (intended to store settings) that are "unused", but in newer syscons some of that areas contains isolated bytes with values that seems to be valid
That bytes are not garbage, but we dont know what they are, i guess the reason why are unknown is because most of the reverse engineering of the syscon firmware was made with the first retail and pre-retail syscons and the old syscon firmwares doesnt have any function to read that isolated bytes. The newer syscons probably have them (by studying them it would be posible to identify the isolated bytes) but this new features has not been reverse engineered completly

Also, we alwas need to keep in mind the syscon does some kind of "emulation" with the EEPROM offsets, i mean... every kind of syscon access (SPI, UART, syscalls or other software services) have his own offsets that are "mapped" internally
Some days ago i was doing a table in wiki, is just an experiment (not accurate, and maybe there is some mistake in it) https://www.psdevwiki.com/ps3/Talk:SC_EEPROM#Experimental_table

Click in the arrows at the table header for the column "CXR713" and "CRX714"... and you are going to notice there is a displacement at the bottom areas, basically... in the way how is represented in the table it looks what they did for CRX714 is to move an empty area of 0x3000 bytes to the most bottom, but the fact is the EEPROM is smaller, check the EEPROM sizes here
https://www.psdevwiki.com/ps3/Syscon_Hardware#PS3_Syscon_models
CXR713 have 32KB (0x8000) while CRX714 have 20KB (0x5000), thats the reason of the 0x3000 displacement

For this frankenstein experiments 99% of the people is going to use a modern mullion syscon from the CRX714 series (the special 304GB, or the more common 302GB from the DIA-002) in a COK-001 or COK-002 motherboard (shipped from factory with a syscon from the CRX713 series)... so this displacement of 0x3000 bytes is a "must do" because we need to take the settings from the old syscon to use them in the new syscon (at a different offset)
Thats something trivial though, is one of the things i was trying to represent in the post i wrote some weeks ago here in this thread, same concept but with photoshop

Another thing that worths to be mentioned is a detail that can be seen in the comments of the official syscon patches here https://www.psdevwiki.com/ps3/Syscon_Firmware#Syscon_patches

Fix 1) System firmware 1.30 (December 6, 2006). Disables UART access to the Syscon EEPROM patch region (not for 0832)

The official patches marked as "(fix1)" in the table of the link prevents to write in the EEPROM areas dedicated to store the patch data. There is an exploit to delete the official patch, thsi way we recover the write access to that areas, and allows to install a custom syscon patch, and this allows to modify the syscon base firmware (lets say.. when syscon boots it loads the firmware to RAM, then applyes the patch on top... either that... or by using the concept of EEPROM "emulation", im not sure)

All and all, yeah, we have access to all the areas involved for the frankenxperiments, the exact steps could be a bit tricky because we dont have a friendly "EEPROM memory map" to check by ourselfs (the table i been doing in wiki is an attempt to do it though), the couple of bytes required to be changed (for the RSX revision and others that we are 100% sure are a must do) are easy, and the other unknown isolated bytes are just a matter of trying with and without them (in the meantime someones identifyes them by reverse engineering). I dont think that kind of experiments are much risky (software side) because the EEPROM areas where we can write are just settings

 

[DeadEnd]

Okay, I've probably figured out how to dump a syscon. The community at psdevwiki did a great job explaining the process.

Missing piece of the puzzle:


What kind of values need to be patched?

I have to say this. DON'T DO IT it until one of us has truly confirmed it to be working. It's not that simple and it's not meant for beginners. I get enthusiastic and forget to warn people who are new to this. If you screw it up, you will need to remarry it and that means flashing firmware to NANDs. You don't want to do that. Or worse, you'd need to swap Cell...

As for devwiki, the only method that works for writing the EEPROM is the bus pirate method. And fitting wires under the syscon isn't going to work so well if you're thinking of trying that. So you need to desolder syscon and solder bus pirate wires to it. A very fragile work as well because pads may come off if you're not careful. I've tried Arduino and Teensy way, they work for reading, but not so much for writing. Psdevwiki is for the developers, and when things don't go right, then you need to get in touch with them. And the process ends up being a bit more complex than you had anticipated.

 

[vyktormvmpay25]

Yes DeadEnd is right, we did all kind of tests after modchip install.
Yes I just need free time to focus well doing again those tests.

 

[sandungas]

Psdevwiki is for the developers, and when things don't go right, then you need to get in touch with them. And the process ends up being a bit more complex than you had anticipated.

Yep, a good example of that is the table i mentioned the other day at the bottom of this page
https://www.psdevwiki.com/ps3/Talk:SC_EEPROM#Experimental_table

I started it as my own initiative because i been interested in understanding the secrets stored inside syscon since many time ago but the info related with it in wiki has been always very confusing to me
As far i remember m4j0r released some IDA databases where i guess there is lot on info about reverse engineering (probably was like the workpad of the team that hacked syscon), but as far i know there is not a public piece of source code where could be seen the structure in detail, with the name of each value, his data type, how are ordered, divided in regions, etc...
Thats the purpose of the table i was trying to do, and it implyes to include all the info from all the other tables in the front "SC EEPROM" page + some more, lol
Is a big challengue so is temporally freezed, but in wiki there is no step back, the actual version of the table is handy so i dont think nobody is going to delete it ever.. so the only option is to improve it

 

[truemaster]

hello guys. looks like my ps3 start to backfire at me. here the symptoms: when try to powerup when is cold in wont boot fan wont spin to 40% as i set it and screen is black after 3 tryes the console will work without issues. also heres the syslog from frontend.


Firmware Version: 4.88 (build 50731)
Platform ID: Cok14
Product Code: 00 83
Product Sub Code: 00 01
Hardware Config: 00000000FFFFFFFF
Syscon Fimware Version: 0B8E.0001000000000006 (EEPROM: 0001000000000006)

Bringup Count: 1852, Shutdown Count: 1787
Runtime: 159 Days, 19 Hours, 32 Minutes, 4 Seconds

Error Log
01: A0A02031 Tue Apr 11 03:37:26 2006
02: A0801001 Tue Apr 11 03:37:23 2006
03: A0A02031 Tue Apr 11 03:36:37 2006
04: A0A02031 Mon Apr 10 18:41:42 2006
05: A0801001 Mon Apr 10 18:40:46 2006
06: A0A02031 Mon Apr 10 18:40:34 2006
07: A0801001 Mon Apr 10 18:39:03 2006
08: A0A02031 Mon Apr 10 18:38:43 2006
09: A0801001 Mon Apr 10 18:38:27 2006
10: A0A02031 Mon Apr 10 18:38:07 2006
11: A0A02031 Mon Apr 10 18:34:09 2006
12: A0A02031 Mon Apr 10 18:30:55 2006
13: A0A02031 Mon Apr 10 17:29:24 2006
14: A0801701 Mon Apr 10 16:43:42 2006
15: A0A02031 Mon Apr 10 16:43:39 2006
16: A0A02031 Mon Apr 10 07:08:54 2006
17: A0A02031 Mon Apr 10 06:05:11 2006
18: A0A02031 Mon Apr 10 05:24:41 2006
19: A0A02031 Mon Apr 10 05:05:00 2006
20: A0A02031 Mon Apr 10 04:58:39 2006
21: A0A02031 Sun Apr 9 19:49:21 2006
22: A0A02031 Sun Apr 9 18:44:50 2006
23: A0A02031 Sun Apr 9 01:48:27 2006
24: A0A02031 Sun Apr 9 00:59:02 2006
25: A0A02031 Sat Apr 8 06:28:31 2006
26: A0A02031 Sat Apr 8 06:25:21 2006
27: A0A02031 Sat Apr 8 06:24:42 2006
28: A0A02031 Thu Apr 6 17:34:56 2006
29: A0A02031 Wed Apr 5 20:16:22 2006
30: A0A02031 Tue Apr 4 05:58:46 2006
31: A0A02031 Tue Apr 4 03:53:10 2006
32: FFFFFFFF Sun Apr 2 05:35:14 2006

 

[DeadEnd]

Thermal sensor error. https://www.psdevwiki.com/ps3/Syscon_Error_Codes#2031_.28Thermal_Sensor.2C_RSX.29

 

[truemaster]

yeah im aware of 2031 is there a possibility that other component exept rsx that can trigger it? on syscon errorlogs explanations is say only about rsx bga

 

[DeadEnd]

yeah im aware of 2031 is there a possibility that other component exept rsx that can trigger it? on syscon errorlogs explanations is say only about rsx bga

It happened to me when there was a loose connection on the resistor next to syscon . The line goes from the thermal sensor to the syscon through that resistor. But I doubt it's your case because I haven't touched the resistors there. I think, here is also an example of how difficult the mod can be. And how difficult it is to get it done on a home made equipment. I suspect the board had flexed too much during the process after all, and now heating cycles are relaxing it or causing some kind of bga issues. But if you want to send it back, I can take a look at it again. However, I think best would be if you ship it to Victor this time (he's located closer to you and his tools are better). My equipment is in the improvement stages at the moment.

You could also try installing Rebug just in case. Unlikely to change anything, but doesn't hurt to try.

 

[truemaster]

ok after new year i would send it. cause now the packages are take long or even disapear. is anything near rsx that can come loose and do this? cause if is a simple resolder like an ic or smd i can do it no problem if needs another bga rework thats out of my reach. also dont give up on moding consoles. shit happents

 

[DeadEnd]

ok after new year i would send it. cause now the packages are take long or even disapear. is anything near rsx that can come loose and do this? cause if is a simple resolder like an ic or smd i can do it no problem if needs another bga rework thats out of my reach. also dont give up on moding consoles. shit happents

I doubt anything would really come loose in there. I suppose reflowing would be an option... But can you do that?

 

[truemaster]

if you meen reflow the bga? no im not gona do it on such rare console. but this time is bad for sending packages. after the new year i will do

 

[RIP-Felix]

Has it escaped anyone else's attention that the PS4/5 APU has a support bracket around the edge of the interposer?

What do we know about the PS3? Oh yeah, it had issues with the YLOD! Hmm...

I just want to point out that the edges of the chip is where we are seeing the most BGA defects (FlexIO and VDDIO errors). Perhaps the purpose of this bracket (which add cost to the BOM BTW) is to provide support to the solderballs underneath.

Effectively there are 2 problems that cause YLOD:

1. Bump failures = reduced to acceptable levels with better underfill and cooling. Perhaps by abandoning the diamond pattern that could cause tortional stresses as the interposer twists from the geometry mismatch.
   
2. BGA failures = reduced with interposer support bracket, better soldering process, and better cooling.

For comparison sake...

Why is the PS3 CPU reliable then, you ask?

The CPU IHS has a ring and is silconed around the edge, effectively providing support.

This brings up a serious oversight and concern about delidding! We really should be gluing the IHS back on after repasting. Both the RSX and CPU IHS! With that in mind, then it changes the TIC decision for me immensely! I think a graphite thermal pad is the way to go. It can be taped (kapton) to the IHS so it never moves out of position and shorts anything out. It prevents die hot spots by transferring thermals laterally extremely fast. And it never degrades. It will perform the same forever, so the IHS can be glued down and never delidded again. You may even be able to silicone the RSX IHS down, to provide extra support for the interposer. Perhaps that wiould make the RSX more reliable. The downside is that graphite thermal pads don't transfer heat to the IHS as well as high quality pastes do. They're a few C worse. Not bad, mind you! They are still good, just not great.

 

[vyktormvmpay25]

That support is a pain, I've got merged balls because people add washers to those 2 screws. Well apu will become bended and deformed to those corners. If you even get one desolder, clean and put on straight surface as window I'm using. Will see quick test that deformation by pressing /flushing down each corner. In some cases rsx get same situation but is going to get back onto his normal form in heat/reball process.
Well in ps4 is totally different and harder to fix that deformation.
Even if you manage to do it you may end up with glitch graphics in games and issues as my last SAC board finished today. Apart from that menu is fine, nothing wrong, reballed 3 times apu in order to get as straight as possible, added those micro caps on corners as in ps3, still those 2 corners tend to be on lower level than rest of points.
So please guys don't do more damages to ic pushing pressure thinking that you fixed.

 

[RIP-Felix]

So please guys don't do more damages to ic pushing pressure thinking that you fixed.

Yeah the old bolt trick. Better at making a bowl out of a motherboard than it is at preventing BGA failures. That and cracking the DIE!