PS3 Frankenstein PHAT PS3: CECHA with 40nm RSX

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
I know what you mean, but we also know that the console throws these RSX/HDMI error codes (as reported) so syscon has at least tried to power it up, which means it doesn't need the correct thermal region for that.

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
Yes, that's what you do when you go from <= 202GB to >= 203GB.
Step 4 can be omitted on >= 301GB.
 
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 ?
A quick recap of @squeept's attempts (pleural) to frankenstein a 65nm RSX:

First Attempt:
  1. He started on page 16 pulling the 65nm RSX and posting his initial EEPROM dump. He used a buspirate to make all the necessary changes "except the checksums." He had some trouble with them in a hex editor.
  2. He makes note of a delaminated ground plane that he didn't think was consequential. Noted the board had been through 4 thermal cycles at reflow temps and would have go through one more installing the new SYSCON chip.
  3. Reports failure to get working. "Errors A0902120, A0403034, and A0404001 at once." Posts eeprom dumps for this attempt.
Second attempt:
  1. On page 18 he began another attempt using good candidates for the MB and 65nm RSX. Said the HW swaps went without incident, but he was getting "a nearly instant YLOD with syscon errors A0902120, A0403034, and A0404001 all at once." He also posed the EEPROM before and after dumps of that attempt as well.
  2. He offered to send the board to someone interested in playing with it further.
  3. I mentioned trying some different configurations with the resistors just to see how it affected the error codes...
    • Note, he was tying the 0K resistor on pad R2054 to GND. That's a pull down resistor. Basically it's shorting to GND. That's not correct. He also forgot to remove R2153 in these tests.
    • Note, this was before we knew that you needed to remove R2054 (0K). We thought that it was supposed to be diagonal at that time. The correct way is to remove it, then take R2153 (10K) and move it to that spot. So R2153 is unpopulated and R2054 is pulled high to GND through the 10K. Basically the opposite logic to how he had it in this test.
    • On page 19 he says, "Moving it [the 0K R2054] back to normal gets rid of the 2120. Still gets 3034 and 4001 at once."
    • Later he removes R2153 and puts the 0K back tied to GND, without sucess (no surprise at it's still wrong). No error codes, he was too tired."
    • On Page 20 I notice that R2153 needs to be moved to R2054. That the 0K resistor is the wrong value. @squeept was gone for a hot minute and returns on page 23, that's when I point out the error. He finally gets the HW soldered correct on Page 24 and reports, "3034 and 4001 at once still."
    • He asks that @sandungas & @M4j0r look at this attempt's EEPROM (posted on Page 18) to double check he got the software changes right.
    • As a side note, just to make the point for you SYSCON people out there, he replaces a R2002 with a 47K unnecessarily. He was working with a COK-001, which already has it anyway. So nothing should have changed when he replaced it. Except he reported, "47K added, now back to 902120, 403034, and 404001 at once." That 2120 wasn't there before and nothing has changed! That's because you get that error when experiencing a YLOD with the HDMI cord plugged in. All it means is that he didn't have the HDMI cord plugged in when testing it before...lol! I though that was worth mentioning, in case you were wondering where it came from.
After that he starts down the modchip path. So from a HW standpoint I think he had it right (assuming nothing died during the reflow cycles). He was getting the same 3034 and 4001 that is expected when the SYSCON is not recieving the correct information from the RSX. We see the same errors with the MOD Chip not wired up correctly. That's what makes me suspect it's a software issue.

You guys will have to evaluate his software changes as that is over my head.
 
Last edited:
Alright. So I tried to make a temperature test, but a lot of things went south during it. First of all, I let the game update and that lasted for around 6 hours only for the console to automatically turn off in the middle of an install (automatic setting I forgot to change). 2 hours of recovering later, I finally got it to run, but used a weak laptop that could barely handle recording HD stream (it recorded with 20 fps only). So the video is laggy, there is no sound. I wasnt' entirely focused on the game as a fun movie came up on TV. My room temp was 28 degrees celsius. When I finally started the game, the machine had already been on for like 8 hours. So first, I let it run with a syscon default. The temps are high. After it I switched to 67 degrees limit, the temps were much better then.

 
Last edited:
Thx @RIP-Felix you are like a ram buffer :encouragement:
I will try to comment some details of your resume later, but there is something that is confusing me a bit, in both attempts syscon was giving errors 3034 and 4001, but in the error code sheet we have that errors are described as "BE Error (IC1001)". And the name BE is the short codename of "CELL Broadband Engine" (not RSX)
Why is that ?, im so so used to the syscon error codes


Edit:
I almost forgot he uploaded the files from the first attempt (but i got them now, nice sample for me to study and compare it with other dumps for research purposes)
All i said about the thermal config region in my posts of the last couple of days applyes only to the files he uploaded after the "second attempt", the other day i was replicating the procedures suggested by m4j0r as an exercise to get used to it and taking notes about the details in a .txt then comparing my files with the ones from squeept etc... and i can say that was fine overal, there are only a couple of details that worths to de mentioned

At some point in the next days i will upload all the files for both attempts, the originals, the others modifyed by squeept, and some more modifyed by me... together with a .txt explaining the modification procedures in a noob friendly way... for everyone to practise a bit, to allow you to see by yourself if what squeept and me are doing is right, and to continue with the research
 
Last edited:
Thx @RIP-Felix you are like a ram buffer :encouragement:
I will try to comment some details of your resume later, but there is something that is confusing me a bit, in both attempts syscon was giving errors 3034 and 4001, but in the error code sheet we have that errors are described as "BE Error (IC1001)". And the name BE is the short codename of "CELL Broadband Engine" (not RSX)
Why is that ?, im so so used to the syscon error codes

Speaking about CELL BE, why we can't swap it too ?
 
Thx @RIP-Felix you are like a ram buffer :encouragement:
I will try to comment some details of your resume later, but there is something that is confusing me a bit, in both attempts syscon was giving errors 3034 and 4001, but in the error code sheet we have that errors are described as "BE Error (IC1001)". And the name BE is the short codename of "CELL Broadband Engine" (not RSX)
Why is that ?, im so so used to the syscon error codes
If you just look at the power up stage (0x40) you'll see that it's related to the FlexIO bit training.
The system can't determine if the error is caused by the ICs, bad traces or bad soldering.
Syscon can although print on which transfer the error happens.

Speaking about CELL BE, why we can't swap it too ?
You can swap it with the same model but you also need to copy all the perconsole data from the NAND (and if e.g. the board model doesn't match you need to modify eid0 which will break on newer OFW), remarry Syscon and the BD Drive.
 
Wow..., looks like I'm far behind, I just found out syscon can be mated, can you teach me how? where can i study? because there is some damage in the syscon, if we can move the data to another syscon, we don't need to change the Set Cellbe :
1. Ic Cellbe
2. Ic Nor/Nand (data can be taken to be transferred to another IC Nor/Nand)
3. Ic Syscon
4. Ic EEprom bd room (can be mated using special software min fw 3.55 and below). I've found several ps3s that can't be turned on because the reset point has no voltage (3.3 volts) at all, because the x'tal part of the syscon is damaged or the syscon itself has a problem, it's very helpful if the syscon data can be moved to another syscon.
Is it possible?
did i misinterpret it? "Remarry syscon"
 
Last edited:
Wow..., looks like I'm far behind, I just found out syscon can be mated, can you teach me how? where can i study? because there is some damage in the syscon, if we can move the data to another syscon, we don't need to change the Set Cellbe :
1. Ic Cellbe
2. Ic Nor/Nand (data can be taken to be transferred to another IC Nor/Nand)
3. Ic Syscon
4. Ic EEprom bd room (can be mated using special software min fw 3.55 and below). I've found several ps3s that can't be turned on because the reset point has no voltage (3.3 volts) at all, because the x'tal part of the syscon is damaged or the syscon itself has a problem, it's very helpful if the syscon data can be moved to another syscon.
Is it possible?
did i misinterpret it? "Remarry syscon"
Most informations are on https://www.psdevwiki.com/ps3/Main_Page
@M4j0r and probably @sandungas can give details about bits/bytes level knowledge .
I'm also interested to learn this swapping only cpu then rsx (with opensource ic programmed for everyone) . It will take me some years to get focus on documentation.
 
Last edited:
Wow..., looks like I'm far behind, I just found out syscon can be mated, can you teach me how? where can i study? because there is some damage in the syscon, if we can move the data to another syscon, we don't need to change the Set Cellbe :
1. Ic Cellbe
2. Ic Nor/Nand (data can be taken to be transferred to another IC Nor/Nand)
3. Ic Syscon
4. Ic EEprom bd room (can be mated using special software min fw 3.55 and below). I've found several ps3s that can't be turned on because the reset point has no voltage (3.3 volts) at all, because the x'tal part of the syscon is damaged or the syscon itself has a problem, it's very helpful if the syscon data can be moved to another syscon.
Is it possible?
did i misinterpret it? "Remarry syscon"
I can't really teach you to remarry syscon myself but,
Have you started playing with the syscon serial connection to begin? Getting error codes, running commands... Etc.
For the first steps maybe you like this video we made for beginners.
It's long and slow but it covers the basics. How to connect, get the 32 error logs, enable internal mode access etc...

Hopefully you will understand something even if it's a language circus! Very crazy Portuguese guy from Germany and Crazy Spanish guy on telephone teaching him on the fly!... making video in English for you to translate to Indonesian hahaha.
But you speak technical language very well so probably it's OK.

And you may be behind on some things. But on most things you are years ahead!
 
Last edited:
I can't really teach you to remarry syscon myself but,
Have you started playing with the syscon serial connection to begin? Getting error codes, running commands... Etc.
For the first steps maybe you like this video we made for beginners.
It's long and slow but it covers the basics. How to connect, get the 32 error logs, enable internal mode access etc...

Hopefully you will understand something even if it's a language circus! Very crazy Portuguese guy from Germany and Crazy Spanish guy on telephone teaching him on the fly!... making video in English for you to translate to Indonesian hahaha.
But you speak technical language very well so probably it's OK.

And you may be behind on some things. But on most things you are years ahead!

Alternatively, I would recommend Felix's guide. It is very detailed and to the point. It is just burried in the NecTokin thread. It would make sense to repost in a separate thread as a "revamped noob friendly tutorial".

https://www.psx-place.com/threads/t...placement-ylod-fix.25260/page-192#post-295119
 
I can't really teach you to remarry syscon myself but,
Have you started playing with the syscon serial connection to begin? Getting error codes, running commands... Etc.
For the first steps maybe you like this video we made for beginners.
It's long and slow but it covers the basics. How to connect, get the 32 error logs, enable internal mode access etc...

Hopefully you will understand something even if it's a language circus! Very crazy Portuguese guy from Germany and Crazy Spanish guy on telephone teaching him on the fly!... making video in English for you to translate to Indonesian hahaha.
But you speak technical language very well so probably it's OK.

And you may be behind on some things. But on most things you are years ahead!
Now I'm trying it, and get used to reading the errors that exist, while analyzing the errors, I'll let you know later. Tq my friend..
 
Now I'm trying it, and get used to reading the errors that exist, while analyzing the errors, I'll let you know later. Tq my friend..
http://s.go.ro/ax49drsu
I have added thermal pinout from cpu 90nm/dyn001 and rsx. Now can you check and give me some values from good working units. To get read real value those two resistor of 100 ohms in front of tmp ic have to be desolder and take measurements on cpu traces directly to cpu/rsx. I will do it myself for compensation, didn't get time to do much more.
 
@botakompong, just noticed your profile picture. I couldn't think of a more fitting choice...lol!
Thank you my friend, your tutorial is very clear, I have tried it and immediately understood, regarding my profile, I was initially confused about what profile to use, I wanted to use this profile
IMG_20210612_153141.jpg
Botakompong= toothless bald...lol, hahaha
 
If you just look at the power up stage (0x40) you'll see that it's related to the FlexIO bit training.
The system can't determine if the error is caused by the ICs, bad traces or bad soldering.
Syscon can although print on which transfer the error happens.
Where can i see a list of the powerup stages and his identifyers ?

Anyway, i dont get what you mean, my question is why the syscon is throwing the errors 3034 and 4001 that belongs to CELL in both of the squeept attempts ?
I dont think he damaged the CELL in both attempts (2 different motherboards), and as rip-felix was mentioning we can use the intuition to deduce syscon was complaining about RSX... so in theory syscon should be throwing errors related with the RSX
I know the error code list we have doesnt applyes for some motherboards/syscon models, but it have the error codes for the EEGS... so it should be 100% valid for COK-001

Wow..., looks like I'm far behind, I just found out syscon can be mated, can you teach me how? where can i study? because there is some damage in the syscon, if we can move the data to another syscon, we don't need to change the Set Cellbe :
1. Ic Cellbe
2. Ic Nor/Nand (data can be taken to be transferred to another IC Nor/Nand)
3. Ic Syscon
4. Ic EEprom bd room (can be mated using special software min fw 3.55 and below). I've found several ps3s that can't be turned on because the reset point has no voltage (3.3 volts) at all, because the x'tal part of the syscon is damaged or the syscon itself has a problem, it's very helpful if the syscon data can be moved to another syscon.
Is it possible?
did i misinterpret it? "Remarry syscon"
Check this page https://www.psdevwiki.com/ps3/Remarry_Syscon
There are 2 ways to do it, if the factory syscon is still working... you can "copypaste" a group of bytes (used as the CELL identifyer) from the old syscon EEPROM to the new syscon EEPROM
If the factory syscon is dead (in other words, you cant copypaste the CELL identifyer)... the procedure is a bit different, you need to enable some "flags" in the syscon EEPROM (and use a service mode USB dongle) that forces the syscon do to an automatic CELL remarry

And yeah... this procedure eventually can be useful for some repairs, i remember to read in forums people that was doing the fan hardware mods with a potentiometer (connecting the fan PWM wire to a voltage source throught the potentiometer) and while doing it they joined several wires together by mistake and made a shortcircuit and fryed the internal circuits of the syscon dedicated to the fan
The syscon was working fine, everything except the fan control (they was lucky that it was still alive, lol), the only difference is syscon was not able to control the fan anymore
Now we can replace syscon to fix this kind of problems :)
 
Where can i see a list of the powerup stages and his identifyers ?

Anyway, i dont get what you mean, my question is why the syscon is throwing the errors 3034 and 4001 that belongs to CELL in both of the squeept attempts ?
I dont think he damaged the CELL in both attempts (2 different motherboards), and as rip-felix was mentioning we can use the intuition to deduce syscon was complaining about RSX... so in theory syscon should be throwing errors related with the RSX
I know the error code list we have doesnt applyes for some motherboards/syscon models, but it have the error codes for the EEGS... so it should be 100% valid for COK-001


Check this page https://www.psdevwiki.com/ps3/Remarry_Syscon
There are 2 ways to do it, if the factory syscon is still working... you can "copypaste" a group of bytes (used as the CELL identifyer) from the old syscon EEPROM to the new syscon EEPROM
If the factory syscon is dead (in other words, you cant copypaste the CELL identifyer)... the procedure is a bit different, you need to enable some "flags" in the syscon EEPROM (and use a service mode USB dongle) that forces the syscon do to an automatic CELL remarry

And yeah... this procedure eventually can be useful for some repairs, i remember to read in forums people that was doing the fan hardware mods with a potentiometer (connecting the fan PWM wire to a voltage source throught the potentiometer) and while doing it they joined several wires together by mistake and made a shortcircuit and fryed the internal circuits of the syscon dedicated to the fan
The syscon was working fine, everything except the fan control (they was lucky that it was still alive, lol), the only difference is syscon was not able to control the fan anymore
Now we can replace syscon to fix this kind of problems :)
Right, I understand, there are some ps3 problems that can be fixed by moving the syscon data (hardware problems, usually there are broken lines in the syscon ic), as long as the syscon data is not disturbed it should work, this is a new thing for me and I am very happy, and i will give it a try.
 
Where can i see a list of the powerup stages and his identifyers ?
In the firmware (called power sequence steps).

Anyway, i dont get what you mean, my question is why the syscon is throwing the errors 3034 and 4001 that belongs to CELL in both of the squeept attempts ?
If you take a look at the firmware you can see that these error codes can be caused by CELL being not able to train the Yellowstone interfaces for the RSX or SB. The error code can't tell you where it exactly happened (CELL, RSX, SB, or maybe just the connection). Even though it says BE Error in the manual it's handled differently in the firmware.
 
Anyway, i dont get what you mean, my question is why the syscon is throwing the errors 3034 and 4001 that belongs to CELL in both of the squeept attempts ?
I dont think he damaged the CELL in both attempts (2 different motherboards), and as rip-felix was mentioning we can use the intuition to deduce syscon was complaining about RSX... so in theory syscon should be throwing errors related with the RSX
I know the error code list we have doesnt applyes for some motherboards/syscon models, but it have the error codes for the EEGS... so it should be 100% valid for COK-001
3034 is a data error. Failure in communication between CPU and... Whatever. But in this case we know it's between CPU and RSX. Normally indicated by the additional 4xxx error and with bringup, the syscon will say it's a "RSX bittraining error" or something like that.

This occurs at stage 40 of the boot sequence. 00 to 40 was OK and there were no errors (around 3 seconds), so this is more or less a late error in the sequence. Severe power fails tend to manifest around step 20 and "80" would be the final "ON" state.
If the data inside the syscon was the problem (unrelated to RSX)... Then we would expect a failure much sooner. Like A0.

The point is, that even if this sony document is "100% relevant" to this board... At the end of the day the information always needs to be taken very carefully and not definitively. It is only indicating the area where you should "look". And this is why it's a document for trained Sony technicians.
If you only look at the error log and see 3034, or 3013 CPU errors... You can see that the problem maybe has something to do with the CPU. But it's probably not being caused by the CPU itself. It could be perfectly fine.

As @M4j0r says, the system knows something is wrong between the CPU and the RSX, but can never know if the problem is the CPU, its connections, the pads and traces on the board... The RSX itself, it's connections...
In our case we have an "unsupported" RSX, so that could be suspicious and probably causing the "CPU" error 3034 too.
 
Back
Top