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
He tested all syscon firmwares, except the firmware for 2 syscon models doubtful: 202GB and 201GB
In inverse order ---> 302GB, 301GB, 203GB (confirmed by m4j0r) ---> 202GB (confirmed by deadend and you) ---> 201GB (waiting for confirmation)
That sentence is outdated btw RIP-Felix, this is scalating quickly, if you are going to include it in a tutorial soon is going to be better to say it works for all mullion syscons (the ones soldered by BGA)
-----------
And later is needed to confirm it with VER-001 motherboard (the last PS3 fat models with the first sherwood syscon SW-301) and DYN-001 motherboard (the first Slim CECH-20xx with the second sherwood syscon SW2-301)
The next motherboard models after them (since PS3 model CECH-21xx) already comes from factory with a 40nm RSX so even if it works it seems to be a bit pointless
I knew it was only a matter of time before you guys had this figured out. What an amazing thread to watch unfold. The way you guys go about analyzing and tackling these problems is just amazing to watch. I'd like to thank you all for your efforts here and devotion to this site and scene. Thank you
Just tried the following on COK-002 board with 3034 error
w 3242 03 61 82 80 01 91
w 3254 21 EC
Console now boots!
Thank you guys for all the amazing work!
Just tried the following on COK-002 board with 3034 error
w 3242 03 61 82 80 01 91
w 3254 21 EC
Console now boots!
Thank you guys for all the amazing work!
40nm, my apologies. Had installed it a while back but had 3034 when and didn't have time to look at it until today. Decided to take off orbit, and patch syscon and it decided it wanted to start working!
40nm, my apologies. Had installed it a while back but had 3034 when and didn't have time to look at it until today. Decided to take off orbit, and patch syscon and it decided it wanted to start working!
That's awesome! I thought that was the case, but I couldn't remember for sure. Really thinking of getting that done on my cecha01 if I can find someone states-side willing to do it. I thought about buying my own equipment, but that's probably going to have to wait for now...
That's awesome! I thought that was the case, but I couldn't remember for sure. Really thinking of getting that done on my cecha01 if I can find someone states-side willing to do it. I thought about buying my own equipment, but that's probably going to have to wait for now...
PS3 #11 - Update
(...continued from Part 1 here. Frankenstein Fail #2 - MB was doomed to begin with.)
This morning I installed a "NOS" CXD5301 40nm on PS3 #11, a COK-001 with CPU delid damage and globs of mask over what might be trace repairs. The console only had a 3034, so I thought I'd give a frankenstein attempt a go. Given the damage though, keep your expectations low.
I'm pretty sure the RSX survived the reflow. All voltage lines ohm test good. I was deflated early on however, since while the board was cooling I measured a short on VDDC. And VDDR was only 13 ohms, when it's supposed to be in the hundreds. I thought it was a lost cause. However, this board had bad tokins and someone tried a tantalum mod. I removed the Tantalums and remaining RSX tokins. I left the CPU tokins, but may replace them later, depending on what codes I get. Then I gave the entire board a THOROUGH IPA cleaning and drying. The RSX perked up, so it wasn't short, the tokins were. I always notice the resistance rises after cleaning flux off too. Also VDDR returned to good values. I installed 4 tantalizers and now the RSX ohms tests are marginal, quite low but not dead.
VDD_MEM = 16.0 Ω
BE_VDDC = 1.6 Ω
BE_PLL = 1.685 MΩ
BE_MC2_VDDIO = 17.25kΩ
YC_RC_VDDIO = 12.6Ω
RSX_VDDR = 349Ω
RSX_VDDC = 1.9Ω
RSX_PLL = 325kΩ
RSX_FBVDDQ = 229Ω
RSX_VDDIO = 96.4Ω
VDDA = 3.8Ω
1.7V_MISC = 16.5kΩ
3.3V_MISC = 3.632kΩ
5V_MISC = Fluctuates, rising/falling between 54kΩ to 4kΩ
5V_HDD = 1kΩ
5_USB = 1kΩ
5V_BD = ~4MΩ, not stable it starts falling as soon as it's probed.
12V_BD = 4-5MΩ, fluctuates
What does worry me is that the CPU only has 1.6 ohms. The RSX perked up after I replaced the tokins, so maybe the CPU tokins are shorting as well. I'll keep an eye on the SYSCON readings to see if there are any 3003 or 1001 errors, which would indicate they are a problem. I really don't like how low the RSX and CPU core voltage potential is. Seems too close to ground.
I just tested it and it is an instant YLOD. The fan begins to power and then then it powers off. It doesn't generate an error code at all. @Computer Booter on YT had a console do exactly the same thing in one of his streams last week. We didn't figure that out.
I went ahead and wrote the commands to enable the 40nm RSX, just to see if it would do anything, and then I fixed the checksum. It did not fix the YLOD, which occurs in exactly the same way. No error codes. It gets to SSM state 103 --> 303 when there is a Power sequence Fail detected and the console shuts off.
The SSM state is supposed to proceed from 103 --> 203 for CPU Livelock setup, but it jumped strait to 303 and erred. So I think this means the CPU livelock was not able to setup. I don't think bad CPU tokins would cause this. If they were bad I would expect to see a 09 3003.
SYSCON drives POWER_GOOD and HARD_RESET signals to 'low'.
Power supplies and reference clocks are activated sequentially. SYSCON Switches...
SW_0 = +5V, +3.3V, & +1.7V MISC
SW_1_A = +3.3V_MK_VDD for Clock Synthesizer
SW_1_B = +2.5V_LREG_XCG_500_MEM
Analog Voltage for the core PLL of IC5004, Clock Generator used to support the Rambus XDR memory subsystem and Redwood logic interface.
The Cell BE power supplies must be turned on in the following order:
SW_6 = +1.2V_YC_RC_VDDIO (I/O voltage supplies, VDD_IO)
SW_7_A = +1.0V_BE_VDDC (Cell BE core voltage supply (VDD) then VCS (the core array voltage). Note, the VID values stored on the CELL itself are not available to be read yet. So the default VID of the VRM is used until then.
SW_8_A = +1.5V_YC_RC_VDDA (Analog voltage supplies, VDD_A)
The RSX power supplies must be turned on in the following order:
SW_8_B = +1.5V VDDIO for both AVCG & RSX Analog IO
SW_8_C = +1.8V_RSX_PLL_VDD
Initialize the Cell BE core logic
Reset the internal state
Set up the core phase-locked loop (PLL)
Adjust the VRM voltage according to the voltage identifier (VID) information stored in the Cell BE processor. The CPU is ready to set the VID dynamically now. From SW_7_A to this point takes about 130ms.
Load the configuration-ring data.
Calibrate the FlexIO interface (initialization, BitTraining, and byte calibration).
Initialize the I/O interface.
I think it's failing somewhere between steps 5 and 9, but I really don't know enough about how all that is coordinated and exactly what communication lines are use. I'm assuming SPI? And it might have something to do with the Miscellaneous Channel 2 I/O block (MC2_VDDIO). The ohm test on the line didn't look bad to me, so IDK.
I'm just started live probing the MB to see if I can make sense of the power sequence better. So far I know that 12v forms first. ACDC_STBY (standby signal to enable 12v) goes high when you press the power button. It's the first thing the SYSCON switches. From 12V_Main most of the other voltages are then switched on by the SYSCON in discrete steps See Power on Topology Part 2. I want to characterize these steps to know when each voltage is supposed to be formed, to confirm my order of events outlined in "Power on Topology 1-3," and to be able to identify when one is faulty.
In this case I want to see when 1.2V_MC2_VDDIO, BE_PLL, FBVDDQ, and RSX_PLL are formed. Those should be switched on after the core and logic voltages (VDDC, VDDR, YC_RC_VDDIO). They are needed so the CELL/RSX can access memory and start "processing." It's during one of these early initialization steps that this console is laying an egg. IDK, maybe I'll learn more by doing this.
He might be willing for science and practice. So long as you don't expect it to work and will not be disappointed if it gets wrecked! He's still learning to reball/frankenstein PS3's, which is a STEEP learning curve. And I think it's reasonable to expect he'd need compensation for his time regardless of the outcome.
This morning I installed a "NOS" CXD5301 40nm on PS3 #11, a COK-001 with CPU delid damage and globs of mask over what might be trace repairs. The console only had a 3034, so I thought I'd give a frankenstein attempt a go. Given the damage though, keep your expectations low.
I'm pretty sure the RSX survived the reflow. All voltage lines ohm test good. I was deflated early on however, since while the board was cooling I measured a short on VDDC. And VDDR was only 13 ohms, when it's supposed to be in the hundreds. I thought it was a lost cause. However, this board had bad tokins and someone tried a tantalum mod. I removed the Tantalums and remaining RSX tokins. I left the CPU tokins, but may replace them later, depending on what codes I get. Then I gave the entire board a THOROUGH IPA cleaning and drying. The RSX perked up, so it wasn't short, the tokins were. I always notice the resistance rises after cleaning flux off too. Also VDDR returned to good values. I installed 4 tantalizers and now the RSX ohms tests are marginal, quite low but not dead.
VDD_MEM = 16.0 Ω
BE_VDDC = 1.6 Ω
BE_PLL = 1.685 MΩ
BE_MC2_VDDIO = 17.25kΩ
YC_RC_VDDIO = 12.6Ω
RSX_VDDR = 349Ω
RSX_VDDC = 1.9Ω
RSX_PLL = 325kΩ
RSX_FBVDDQ = 229Ω
RSX_VDDIO = 96.4Ω
VDDA = 3.8Ω
1.7V_MISC = 16.5kΩ
3.3V_MISC = 3.632kΩ
5V_MISC = Fluctuates, rising/falling between 54kΩ to 4kΩ
5V_HDD = 1kΩ
5_USB = 1kΩ
5V_BD = ~4MΩ, not stable it starts falling as soon as it's probed.
12V_BD = 4-5MΩ, fluctuates
What does worry me is that the CPU only has 1.6 ohms. The RSX perked up after I replaced the tokins, so maybe the CPU tokins are shorting as well. I'll keep an eye on the SYSCON readings to see if there are any 3003 or 1001 errors, which would indicate they are a problem. I really don't like how low the RSX and CPU core voltage potential is. Seems too close to ground.
I just tested it and it is an instant YLOD. The fan begins to power and then then it powers off. It doesn't generate an error code at all. @David Rainer AKA ComputerBooter on YT had a console do exactly the same thing in one of his streams last week. We didn't figure that out.
I went ahead and wrote the commands to enable the 40nm RSX, just to see if it would do anything, and then I fixed the checksum. It did not fix the YLOD, which occurs in exactly the same way. No error codes. It gets to SSM state 103 --> 303 when there is a Power sequence Fail detected and the console shuts off.
The SSM state is supposed to proceed from 103 --> 203 for CPU Livelock setup, but it jumped strait to 303 and erred. So I think this means the CPU livelock was not able to setup. I don't think bad CPU tokins would cause this. If they were bad I would expect to see a 09 3003.
SYSCON drives POWER_GOOD and HARD_RESET signals to 'low'.
Power supplies and reference clocks are activated sequentially. SYSCON Switches...
SW_0 = +5V, +3.3V, & +1.7V MISC
SW_1_A = +3.3V_MK_VDD for Clock Synthesizer
SW_1_B = +2.5V_LREG_XCG_500_MEM
Analog Voltage for the core PLL of IC5004, Clock Generator used to support the Rambus XDR memory subsystem and Redwood logic interface.
The Cell BE power supplies must be turned on in the following order:
SW_6 = +1.2V_YC_RC_VDDIO (I/O voltage supplies, VDD_IO)
SW_7_A = +1.0V_BE_VDDC (Cell BE core voltage supply (VDD) then VCS (the core array voltage). Note, the VID values stored on the CELL itself are not available to be read yet. So the default VID of the VRM is used until then.
SW_8_A = +1.5V_YC_RC_VDDA (Analog voltage supplies, VDD_A)
The RSX power supplies must be turned on in the following order:
SW_8_B = +1.5V VDDIO for both AVCG & RSX Analog IO
SW_8_C = +1.8V_RSX_PLL_VDD
Initialize the Cell BE core logic
Reset the internal state
Set up the core phase-locked loop (PLL)
Adjust the VRM voltage according to the voltage identifier (VID) information stored in the Cell BE processor. The CPU is ready to set the VID dynamically now. From SW_7_A to this point takes about 130ms.
Load the configuration-ring data.
Calibrate the FlexIO interface (initialization, BitTraining, and byte calibration).
Initialize the I/O interface.
I think it's failing somewhere between steps 5 and 9, but I really don't know enough about how all that is coordinated and exactly what communication lines are use. I'm assuming SPI? And it might have something to do with the Miscellaneous Channel 2 I/O block (MC2_VDDIO). The ohm test on the line didn't look bad to me, so IDK.
I'm just started live probing the MB to see if I can make sense of the power sequence better. So far I know that 12v forms first. ACDC_STBY (standby signal to enable 12v) goes high when you press the power button. It's the first thing the SYSCON switches. From 12V_Main most of the other voltages are then switched on by the SYSCON in discrete steps See Power on Topology Part 2. I want to characterize these steps to know when each voltage is supposed to be formed, to confirm my order of events outlined in "Power on Topology 1-3," and to be able to identify when one is faulty.
In this case I want to see when 1.2V_MC2_VDDIO, BE_PLL, FBVDDQ, and RSX_PLL are formed. Those should be switched on after the core and logic voltages (VDDC, VDDR, YC_RC_VDDIO). They are needed so the CELL/RSX can access memory and start "processing." It's during one of these early initialization steps that this console is laying an egg. IDK, maybe I'll learn more by doing this.
He might be willing for science and practice. So long as you don't expect it to work and will not be disappointed if it gets wrecked! He's still learning to reball/frankenstein PS3's, which is a STEEP learning curve. And I think it's reasonable to expect he'd need compensation for his time regardless of the outcome.
yeah, for sure. I'm hoping to pay someone for a reball or 40nm replacement with no strings attached, that's all. Id take care of the rest (power mods, tantalizers, etc)
Thanks i think i got it
Im still scratching my head about how you did it, lol, the other day when i was speculating and brainstorming about how to tamper with the rsx training data i was considering for something like this it was going to be needed to "update" the data from some non-rewritable areas (by using the official patch format, etc...) but the patches you published are just writing in the non-protected areas, so in some way it means the syscon firmware was ready to load some data from that areas, and the data is directly related with the rsx training output
By reading about what you said of that (non-problematic) errors that happens with this patches in the communications in between syscon and rsx i can deduce what you are doing is not exactly how is supposed to be made, is the kind of "eureka" enlightment you had while looking at how it works, this is why i was optimistic, there was some probabilities for something like this to happen, specially because the orbis chip is "nerfing" that rsx training communications too
I mean... we dont know exactly wat the orbis chip does, but the rsx training is intended to be something accurate and the orbis chip is simplifying it, also we dont know if the orbis chip have this (non-problematic) errors in the communications too
I made a list of the patches to clarify it, are 5 in total. Im not mentioning the DECR-1000 with the "F" syscons because im not sure if the offsets are the same than retail, and im not including either some other combinations that are technically posible but a bit pointless, like a 90nm RSX in a PS3 slim or things like that. I added the patches for the thermal config region and is mentioned the location of the checksums
