PS3 Frankenstein PHAT PS3: CECHA with 40nm RSX

[DeadEnd]

Perhaps more service manual leaks would help ...

 

[botakompong]

That would take all the fun out of reverse engineering. Besides, the cat and mouse aren't supposed to be friends! The cat is supposed to get fat and happy. The mouse comes along later and picks up the breadcrumbs he leaves behind. That's the natural way!

hahaha, it looks like cats and mouse are both happy, because they both get food ...

 

[RIP-Felix]

Common voltage terminology:

VDD = "Voltage Drain Drain" (Positive Supply Voltage for an FET).

• A microcontroller is basically a bunch of transistors, which are dominated by FET's in today's processors. That's why the proper abbreviation for their positive supply voltage is VDD. If BJT's were used, it'd be VCC, because they use the term collector instead.
• The letter(s) after VDD stand for...
  • C = Core
  • A = Analog
  • IO = Input/Output

So for example, VDDA stands for the "positive supply voltage to the FET transistors in the Analog circuitry of the microprocessor." I'm not exacly sure which analog circuits, however. The reason it's separate from the Core voltage is because they want to keep digital noise out of the analog voltage line, and visa-versa. Same thing with the IO.

Doesn anyone know what YC stands for? YC_VDDA, for example? Could it be referring to Y/C, Luma/Chroma? Analog voltage for a video DAC perhaps? I'd check the PS3 developer wiki but the server's been down all day. I wonder what that's about.

 

[lovetohax]

I mean Y is usually only for outputs, do you have a copy of the schematic I can look at?


Sent from my iPhone using Tapatalk

 

[vyktormvmpay25]

Common voltage terminology:

VDD = "Voltage Drain Drain" (Positive Supply Voltage for an FET).

• A microcontroller is basically a bunch of transistors, which are dominated by FET's in today's processors. That's why the proper abbreviation for their positive supply voltage is VDD. If BJT's were used, it'd be VCC, because they use the term collector instead.
• The letter(s) after VDD stand for...
  • C = Core
  • A = Analog
  • IO = Input/Output

So for example, VDDA stands for the "positive supply voltage to the FET transistors in the Analog circuitry of the microprocessor." I'm not exacly sure which analog circuits, however. The reason it's separate from the Core voltage is because they want to keep digital noise out of the analog voltage line, and visa-versa. Same thing with the IO.

Doesn anyone know what YC stands for? YC_VDDA, for example? Could it be referring to Y/C, Luma/Chroma? Analog voltage for a video DAC perhaps? I'd check the PS3 developer wiki but the server's been down all day. I wonder what that's about.

Psdevwiki should work fine, just checked. If not there is a thread.

 

[M4j0r]

Doesn anyone know what YC stands for? YC_VDDA, for example? Could it be referring to Y/C, Luma/Chroma? Analog voltage for a video DAC perhaps?.

It's only used for the BE <-> SB and BE <-> RSX (FlexIO) interfaces for reference voltages.
I guess the YC (as well as Y1 others) names are dictated by Rambus (FlexIO = Rambus Redwood). The XDR interface is called Rambus Yellowstone.

I'd check the PS3 developer wiki but the server's been down all day. I wonder what that's about

The DNS is broken
http://51.15.111.28/ps3
http://51.15.111.28/ps4

I mean Y is usually only for outputs, do you have a copy of the schematic I can look at?

You can check the COK-001, COK-002 and SEM-001 service manuals.

 

[RIP-Felix]

@DeadEnd @vyktormvmpay25 Can we get some test results from you guys? I'm interested in seeing a fair comparison between 90nm, 65nm, and 40nm RSX temperatures under load.

Test Methods: GTA 6 first introductory race after install. Take screen shot after playing the race for 5 minutes (restart if necessary). Alternatively, TLOU. You just need to agree on a game and lenght of time before taking the screenshot. This way we can know the consoles were worked to the same degree. It would be nice if there were a Prime95 PS3 edition or something, but this will have to suffice.

Also, lets agree upon 2 test parameters for the fan settings:

1. SYSCON Default Fan management.
2. webMAN setpoint 67C (it's default setting).

In both cases we're interested in the fan % needed to maintain temps. Basically, exactly how much cooler does the 65nm and 40nm chips cool compared to the 90nm? Assuming the same game and amount of play time.

 

[vyktormvmpay25]

Ok I will do this test.

 

[DeadEnd]

@DeadEnd @vyktormvmpay25 Can we get some test results from you guys? I'm interested in seeing a fair comparison between 90nm, 65nm, and 40nm RSX temperatures under load.

Test Methods: GTA 6 first introductory race after install. Take screen shot after playing the race for 5 minutes (restart if necessary). Alternatively, TLOU. You just need to agree on a game and lenght of time before taking the screenshot. This way we can know the consoles were worked to the same degree. It would be nice if there were a Prime95 PS3 edition or something, but this will have to suffice.

Also, lets agree upon 2 test parameters for the fan settings:

1. SYSCON Default Fan management.
2. webMAN setpoint 67C (it's default setting).

In both cases we're interested in the fan % needed to maintain temps. Basically, exactly how much cooler does the 65nm and 40nm chips cool compared to the 90nm? Assuming the same game and amount of play time.

I will test it your way later. I have also delidded Cell and put Arctic MX2 compound on both RSX and Cell. In the few games I have tested with ambient temp of 26 degrees Celsius, RSX almost never goes over 60 degrees. As for Cell, it stays in around 63-65 in games at around 25% fan, but in physics intensive or CPU-intensive scenes it reaches 67 easily and the fan ramps up to 40 % for a short period of time, then calms down to around 30%.

 

[RIP-Felix]

@vyktormvmpay25 what TIC are you using? Would it be too much to ask for you to use MX-2 to keep the variables the same with @DeadEnd ? Also, it would be good if you both measured the ambient temperature of the room so we know what the delta T is.

Basically what happens is the CPU get above 67 and then the fan kicks in to keep the CPU cool. Since the 65nm and 40nm chips don't produce as much heat as a 90nm, they will probably be kept cooler. So all else being equal, your fan % should be the same but Delta T be different. That number would directly correlate to the performance improvement of the smaller chips. But we need a 90nm result for control too.

 

[RIP-Felix]

I will test it your way later. I have also delidded Cell and put Arctic MX2 compound on both RSX and Cell. In the few games I have tested with ambient temp of 26 degrees Celsius, RSX almost never goes over 60 degrees. As for Cell, it stays in around 63-65 in games at around 25% fan, but in physics intensive or CPU-intensive scenes it reaches 67 easily and the fan ramps up to 40 % for a short period of time, then calms down to around 30%.

That's pretty similar to what I've seen on a 90nm RSX using MX-4 on delidded CPU/RSX. Fans idle around 30% and kick up to around 40% max to keep the CPU @67C. The RSX tends to run about 5C cooler than the CPU, around 60-63C. Ambient temp. 20C.

I'm planning another go at attaching a 40nm to a COK-001.

I still need to jailbreak PS3#7 and see how my cooling mods have improved thermal over a stock COK-001 (I soldered an Indium foil pad between the HS & IHS. I want to compare the Die/IHS TIC using a graphite pad, MX-5, and liquid metal). Once I decide on the best solution I'll use that with a 40nm. The we'll get an Idea of what the best case scenario for a BC PS3 is.

What I'm hoping is that the RSX can be kept under 50C under load, with fan speeds under 40%. Above that and the fan is brutally loud. Is there a way in webMAN to choose the RSX temperature specifically? Like, specify 67C max CPU and 50C max RSX?

 

[vyktormvmpay25]

I will use mx2, didn't got time to it, I had problems with one sur001 board that I have rsx defect, board în glod.
Now rhis slim will be left assembled for experimental tests via uart.

 

[DeadEnd]

A little video I made to share our discovery with the world... Perhaps, more folks will learn about the method and actually bring their ps3s back to life again. @botakompong what do you think?

 

[RIP-Felix]

A little video I made to share our discovery with the world... Perhaps, more folks will learn about the method and actually bring their ps3s back to life again. @botakompong what do you think?

Great video, the only thing it's missing is a bit of YLOD backstory (NEC/TOKIN specifically), and a head-to-head heat test with a stock PS3. That would make for a more complete video, but it's great nonetheless.

 

[DeadEnd]

Great video, the only thing it's missing is a bit of YLOD backstory (NEC/TOKIN specifically), and a head-to-head heat test with a stock PS3. That would make for a more complete video, but it's great nonetheless.

Thanks. Well, to be fair, I think you would be better at explaining extra details related to the hardware subtleties and the whole NEC/Tokin debacle. You are the kind of guy who is very thorough, plus you have done a lot of research on the filtering circuits. You have also created detailed guides for syscon testing, which I have linked in the description. So, it would be fun to watch your vids as well

 

[botakompong]

A little video I made to share our discovery with the world... Perhaps, more folks will learn about the method and actually bring their ps3s back to life again. @botakompong what do you think?

I like the explanation, it's detailed and clear, thank you for making this video..., keep it up my friend

 

[RIP-Felix]

Thanks. Well, to be fair, I think you would be better at explaining extra details related to the hardware subtleties and the whole NEC/Tokin debacle. You are the kind of guy who is very thorough, plus you have done a lot of research on the filtering circuits. You have also created detailed guides for syscon testing, which I have linked in the description. So, it would be fun to watch your vids as well

Haha...I started writing a script and it became a novella.

This would need a 4 part series to do justice to it.
1) The Truth and lies of the YLOD (Backstory and Drama).
2) SYSCON Tutorial
3) YLOD troubleshooting and Repair
4) The Ultamate PS3 (with 40nm RSX and moded to the hilt)

 

[sandungas]

Does this mean my 65nm GPU or the board is dead? Looks like there was no reason it shouldn't have worked. Or did I not need to swap those resistors around underneath the RSX like we originally thought?

Do you still have that motherboard ?, i been checking the syscon dumps you uploaded (the original and the other modifyed by you) and there are some things that worths to be mentioned, the most important is the thermal config area is completly invalid, syscon is not able to load a single byte from it (but there are some unknown bytes in the thermal config area that seems to be related with thermal sensor calibrations of CELL, RSX, etc...)
Long story short... this unknown bytes seems to be important so the best we can do with them is to "dont touch them with a 10 feet pole"... but the new syscon model is not loading them (as said, this new syscon firmware version is not able to load any byte from the thermal config, are 0x100 bytes of garbage)
The conversion of the thermal config area from the "old mullion format" to the "new mullion format" requires some work to preserve that unknown bytes
The other day i was doing something similar to figure the official thermal config used by sony in the other official frankensteins combinations (COK-001+65nm, COK-001+40nm, COK-002+65nm, COK-002+40nm, etc... everyone needs his specific thermal config). I realized the rules they follows to make that conversions and can be replicated easilly in a few steps
So... in another post later i will upload your dump modifyed by me with a valid thermal config to make a test i you are still interested to make another test


---------
But before that i have a doubt of one of the frankensteps mentioned by @M4j0r
When you said to delete the "XDR init config" by overwriting 0x3230-0x3290 with 0xFF's you meant ?
Offset 0x3230, length 0x60 ?
or...
Offset 0x3230, length 0x61 ?

This is making me doubt because in the other steps we are dealing with complete regions wich sizes are a multiplyer of 0x100 (when we move the "system software config" or when we fill with 0xFF's the "patch1" and "patch2" regions)
But the cleanup of the "XDR init config" is made by overwriting a group of settings inside a region

*Squeept cleaned up the "XDR init config" area by filling with 0xFF's from offset 0x3230, length 0x60 (so the byte at 0x3290 was preserved... it contains the value 0x03 that smells a bit fishy)

 

[M4j0r]

Do you still have that motherboard ?, i been checking the syscon dumps you uploaded (the original and the other modifyed by you) and there are some things that worths to be mentioned, the most important is the thermal config area is completly invalid, syscon is not able to load a single byte from it (but there are some unknown bytes in the thermal config area that seems to be related with thermal sensor calibrations of CELL, RSX, etc...)
Long story short... this unknown bytes seems to be important so the best we can do with them is to "dont touch them with a 10 feet pole"... but the new syscon model is not loading them (as said, this new syscon firmware version is not able to load any byte from the thermal config, are 0x100 bytes of garbage)
The conversion of the thermal config area from the "old mullion format" to the "new mullion format" requires some work to preserve that unknown bytes
The other day i was doing something similar to figure the official thermal config used by sony in the other official frankensteins combinations (COK-001+65nm, COK-001+40nm, COK-002+65nm, COK-002+40nm, etc... everyone needs his specific thermal config). I realized the rules they follows to make that conversions and can be replicated easilly in a few steps
So... in another post later i will upload your dump modifyed by me with a valid thermal config to make a test i you are still interested to make another test

Well, the error codes are related to the AV Encoder/HDMI sub system, Syscon doesn't really care about the thermal control data.

But before that i have a doubt of one of the frankensteps mentioned by @M4j0r
When you said to delete the "XDR init config" by overwriting 0x3230-0x3290 with 0xFF's you meant ?
Offset 0x3230, length 0x60 ?
or...
Offset 0x3230, length 0x61 ?

This is making me doubt because in the other steps we are dealing with complete regions wich sizes are a multiplyer of 0x100 (when we move the "system software config" or when we fill with 0xFF's the "patch1" and "patch2" regions)
But the cleanup of the "XDR init config" is made by overwriting a group of settings inside a region

*Squeept cleaned up the "XDR init config" area by filling with 0xFF's from offset 0x3230, length 0x60 (so the byte at 0x3290 was preserved... it contains the value 0x03 that smells a bit fishy)

I meant 0x3230 length 0x60, although this optional modification I described was meant for the latest Mullion firmware (and it's maybe prohibited / different on lower firmwares).

 

[sandungas]

Well, the error codes are related to the AV Encoder/HDMI sub system, Syscon doesn't really care about the thermal control data.

Let me explain better what i said about the invalid thermal config region, his dump uses the old format composed by 6*0x40 "fan tables" + 1*0x80 "special section" because is a dump of a COK-001/CXR713120-201GB or a COK-002/CXR713120-202GB (at this point im not sure about which one, but there are only this 2 posible options), but the syscon firmware of the new CXR714120-304GB requires to have the thermal config region composed by 3*0x80 "fan tables" + 1*0x80 "special section"... so the "fan tables" are not valid
He was lucky the "special section" is still in the same position (at relative offset 0x180 for all the mullions)... but we need to change the bytes related with the RSX from "unk_2" and "unk_3"
Anyway... i think the console is not going to boot with the thermal config he was using, probably it was throwing some errors related with the [SERV THERM] we was talking about here

This problem with the incompatible thermal config region only happens when doing the frankenstein in a COK-001 or COK-002 motherboards... but lets say... if we do the frankenstein with a SEM-001 motherboard then the format of the thermal config region would be valid so the PS3 should boot (but the values of "tempU", "tempD" and "duty" from the fan tables will be weird, and it would be missing the "unk_2" and "unk_3")

About the UART errors he was having after the procedures... well, is hard to find his reports in between all this talk, i see he mentioned 3034, 2120 in this post
https://www.psx-place.com/threads/f...cecha-with-40nm-rsx.28069/page-28#post-289149
And A0902120, A0403034, and A0404001 in this post
https://www.psx-place.com/threads/f...cecha-with-40nm-rsx.28069/page-18#post-281929

It cold be nice if someone makes a recap, maybe @RIP-Felix or @DeadEnd that was following the experiments with attention can make a resume ?

I meant 0x3230 length 0x60, although this optional modification I described was meant for the latest Mullion firmware (and it's maybe prohibited / different on lower firmwares).

Ok, i was not sure because i dont know how many setting we are "cleaning" in that region, lets make a recap of the process for others interested in it, the names and offsets im using follows this layout

1) Copy offset 0x7000 length 0x400 to offset 0x4000 length 0x400 ("system_software_config_old" to "system_software_config_new" region)
2) Overwrite offset 0x2800 length 0x400 with 0xFF ("patch1_new" region)
3) Overwrite offset 0x4400 length 0xC00 with 0xFF ("patch2_new" region)
4) Overwrite offset 0x7000 length 0x1000 with 0xFF ("system_software_config_old" and "patch2_old" regions)
5) Set offset 0x3912 to 0x21 (RSX revision, 0x11=90nm, 0x21=65nm, 0x30=40nm)
6) Replace the thermal config region at offset 0x3300 length 0x200 (this procedure is better explained at bottom of this page)
7) Overwrite offset 0x3230 length 0x60 with 0xFF (XDR init config)
8) Set offset 0x2E33 to 0xFE (unknown, located in a "not used" area)
9) Set offset 0x3FA2 to 0x03 0x61 0x82 0x80 0x01 0x91 (unknown, located in a "not used" area)
10) Use the UART command "eepcsum" to check and fix all the checksums

Steps 1,2,3,4,5 are mandatory, step 6 is mandatory only for COcK's but recommended for all other motherboards, and steps 7,8,9 are optional
I dont know how works the step 7, but it seems to be some kind of reset
Steps 8 and 9 is some weird data found by m4j0r that is located in areas of the EPROM that appears marked as "not used" in the image above... so... yeah... we dont really know if this is needed, the only thing we can do is to do several test "with and without" that data