PS3 Frankenstein PHAT PS3: CECHA with 40nm RSX

[Pacorretaco]

Wow, thank you, I also mean a link for syscon, sorry for not following the rules

Don't worry. I'm not a moderator but I think talking about how to diagnose a bad RSX is very relevant here.

Because for a frankenstein the first step is to make sure that the RSX is bad and needs to be replaced.
We are just trying to answer the question:
Is my RSX actually bad, Do I really need to replace it? Not always necessary.

And yeah CPU problems, CPU XDR RAM problems, NAND/NOR problems... HDMI IC problems... Probably belong in the other thread BUT they could still be confused with RSX problems or RSX VRAM problems. Because they can all cause "no video" or "blank" GLOD.

And it would be a mistake to replace RSX thinking it was the cause for GLOD when in reality it was XDR RAM for example.

But yes the other thread more appropriate for general syscon diagnosis.

 

[sandungas]

El Gato_malo.jpg is right, a bit of offtopic is fine because there are many details that are still under research so eventually someone is going to start speculating or brainstorming about things that are not directly related with the RSX frankensteins
But keep in mind the ratio of posts in this thread talking about the frankensteins with the other posts not talking about the frankensteins, in the last pages of the thread that ratio is a bit excesive

The other thread started as a research for YLOD but is not only about the YLOD, it became something more generic, so is better to write there

 

[RIP-Felix]

Don't worry. I'm not a moderator but I think talking about how to diagnose a bad RSX is very relevant here.

Because for a frankenstein the first step is to make sure that the RSX is bad and needs to be replaced.
We are just trying to answer the question:
Is my RSX actually bad, Do I really need to replace it? Not always necessary.

And yeah CPU problems, CPU XDR RAM problems, NAND/NOR problems... HDMI IC problems... Probably belong in the other thread BUT they could still be confused with RSX problems or RSX VRAM problems. Because they can all cause "no video" or "blank" GLOD.

And it would be a mistake to replace RSX thinking it was the cause for GLOD when in reality it was XDR RAM for example.

But yes the other thread more appropriate for general syscon diagnosis.

In my case, I'm looking for any excuse to replace the damn thing!

"oh good! A 3034, let's rip it out of there and put a 40nm in it's place."
"Ohm test? What Ohm test? I don't care about no ohm test?"
"If the 90nm RSX is good, great. It can be good in my spare parts bin!"

 

[DeadEnd]

In my case, I'm looking for any excuse to replace the damn thing!

"oh good! A 3034, let's rip it out of there and put a 40nm in it's place."
"Ohm test? What Ohm test? I don't care about no ohm test?"
"If the 90nm RSX is good, great. It can be good in my spare parts bin!"

I think my sarcasm meter just broke

 

[RIP-Felix]

3. Rules 3 (CellBe To RSX)
We arrived at rules 3, below I will give a 2 video "Pulse CLK" : video1 enters "rules3" and video2 final of "rules3"

When entering "rules3" you can say there is no problem with the voltage in CellBe and RSX, so the problem that occurs with "rules3" is usually only a problem with the relationship between CellBe and RSX, CellBe and sub (CXD9964)
I will give examples of problems that are often encountered from ps3, especially on the RSX CXD2971, I took pictures from the DIA-001

remember !!!, this is just an example, in my picture the pin-pin connection data from CellBe to RSX, a common problem that occurs in the CXD2971, when measuring resistance in IC using a digital meter (fluxe) pin 1 and pin 2 is drawn shot , pin1 and pin2 are connected internally in RSX, which shouldn't happen, that's what causes PS3 YLOD. Then I heat the RSX CXD2971 with a temperature increase of max 200c for 15 minutes, after it cools down I re-measure pin1 and pin2 that were previously connected, the RESULT? pin1 and pin2 separate back to normal, no longer connected, from such conditions I conclude that using heat can change the conditions inside the RSX CXD2971, but such repairs cannot last long, 2-3 days later pin1 and pin2 are shot again, reconnected Internally in RSX, there are a lot of similar cases like this with different results, but from the many ps3s that have been treated like this, I conclude:
1. RSX that has never been HEATED, will last quite a long time, approx. 3-6 months, will have a longer lifespan if it is used frequently, harvested continuously
2. RSX that has been HEATED, DON'T WASTE YOUR TIME, REPLACE RSX CXD530XX IMMEDIATELY !!!!!
That's why my brother("KIAW'S) made the MODRSX IC so that the old CXD2971 could be replaced.
how to heat RSX like this can only be done on RSX CXD2971, does not apply to other RSX, why? Ask Sony ...(what is clear is that the make is different)
BUT if you don't have a problem doing that, it's okay too, in principle heating to 2,3,4,5 makes the PS3's life time less and less, it's good that it doesn't interfere with other components, until it's time you replace the RSX ...
other than heating (CXD2971 only), repairing ps3 that enters "rules3" is by:
1. Replace tin ore, reballing either RSX or Cellbe, just one of them
2. Replace RSX or Cellbe because it is damaged

It seems that I also explain it for a long time, I leave it up here, hopefully it will be useful and keep up the spirit, as usual, no method is perfect, take the important parts, combine it with other methods, make it more perfect, that too is my hope , I am 47 years old, my ability to service has decreased, my eyes are also myopic, I like your enthusiasm in finding and learning something new, I hope that in the future you can produce more perfect methods I pray everyone will be well always (

Am I right in that this case causes a GLOD and not a YLOD? I didn't hear one in the background of your video at least.

Can you tell the difference between a BGA defect and an internal short with this method? If you can, that would allow us to narrow it down to electromigration in rule 3 (or damaged traces between RSX/CELL). As opposed to potential BGA defects in rules 1 & 2.

If it were a simple BGA defect, SYSCON codes 3034 and an associated 40xx data error would occur. We should have a YLOD in that case. Especially if you see a bittraining error in the bringup after the YLOD. That indicates an error in the communication line between RSX and CELL. Which could be a BGA defect or short in the traces.

If it is a BGA defect causing it, thermomechanical reconnections due to warping could explain why some of your heating tests only last a few days. If it just melted the bumps with their old lead-free solder, that may not last very long the more you do it. And the heat is going to slowly degrade the tiny transistors too. So there is a finite number of times you can reflow the RSX, even if you reball the BGA. It needs replaced!

On the other hand if it is indeed is a GLOD, then that indicates RAM issues, yes? So rules 4 or 6? Or is this a speacial case where you're pretty sure that the RAM is okay and there must be electromigration causing an internal short in the die itself?

 

[botakompong]

Am I right in that this case causes a GLOD and not a YLOD? I didn't hear one in the background of your video at least.

Can you tell the difference between a BGA defect and an internal short with this method? If you can, that would allow us to narrow it down to electromigration in rule 3 (or damaged traces between RSX/CELL). As opposed to potential BGA defects in rules 1 & 2.

If it were a simple BGA defect, SYSCON codes 3034 and an associated 40xx data error would occur. We should have a YLOD in that case. Especially if you see a bittraining error in the bringup after the YLOD. That indicates an error in the communication line between RSX and CELL. Which could be a BGA defect or short in the traces.

If it is a BGA defect causing it, thermomechanical reconnections due to warping could explain why some of your heating tests only last a few days. If it just melted the bumps with their old lead-free solder, that may not last very long the more you do it. And the heat is going to slowly degrade the tiny transistors too. So there is a finite number of times you can reflow the RSX, even if you reball the BGA. It needs replaced!

On the other hand if it is indeed is a GLOD, then that indicates RAM issues, yes? So rules 4 or 6? Or is this a speacial case where you're pretty sure that the RAM is okay and there must be electromigration causing an internal short in the die itself?

I said earlier, only the ylod/lost power part
Rules1,2,3
Rules 4 cellbe relationship with ramcellbe (glod)
Rules 6 relation between rsx and ramrsx (glod)
If the "clk pulse" is normal, the screen is blank, it can be ascertained that the hdmi ic or av ic
I have also explained each of them about the symptoms rules4 & 6
Now I'm still in the shop later when I get home I will explain further, because I have a lot of work to do, keep the spirit all

 

[sandungas]

This post is a review of the software modifications made by squeept in the second attempt of the frankenstein, is also a continuation of the recap written by @RIP-Felix here

After thinking a bit in it... i realized the best way to discuss all this details is if some of you gets used to the software procedures, we need at least 4 or 5 persons used to it, also some of the steps are optional, is like a cook recipe which ingredients needs to be discussed so please dedicate some time to this explanation and practise a bit with the file samples im going to upload in this post
First download this samples ---> https://workupload.com/file/H9RJAPHxpy6

And take a read at the README.TXT ... is like a tutorial for people not used to hexeditors, i suggest to download HxD and follow the steps "like a robot" to generate some files and to see by yourself what squeept did

Also, is included this image that is a resume in itself, this is what we need to do
As you can see there are 3 steps that are optional, squeept did 2 of the 3 optional steps (missed one of them... but we dont know if that one was important)

In resume... the only things that can be considered controversial in the "2nd_try_modified_by_squeept.bin" was the invalid thermal config region, and 1 of the options missing

Please @RIP-Felix @dead-end @vyktormvmpay25 @DoublesAdvocate try to complete the exercise at the bottom of the README.TXT

 

[DeadEnd]

Thanks for the help @sandungas . I am able to use hexeditors. I still have a board where I tried to experiment with syscon, but since I was using unreliable Arduino and Teensy tools for writing (it was difficult to overwrite syscon data), and also made several mistakes with overheating the board too much, basically after soldering the chip back there was no more red light on the board. Standby voltages are all fine, but the eeprom in the syscon probably got damaged. I dropped the idea because I don't have a bus pirate. And at the moment, I can't justify spending 50 euros on it. I have already splurged a lot of money over the course of testing the modchip.

Edit: After checking voltages once more, it seems that syscon and board have a hardware issue. I am getting 1.6v instead of 3.3v at the TX point.

 

[vyktormvmpay25]

Thanks for the help. I am able to use hexeditors. I still have a board where I tried to experiment with syscon, but because of using unreliable Arduino and Teensy tools, I probably have messed it up to the point that there is no red light on the board. Standby voltages are all fine, but the eeprom in the syscon probably got damaged. I dropped the idea because I don't have a bus pirate. And at the moment, I can't justify spending 50 euros on it. I have already splurged a lot of money over the course of testing the modchip. So unless somebody is willing to send me bus pirate, I am out.

Just copy over rxtx your syscon, if does not work do kind manual from 40 to 40 bytes and create a dump. Just run and compare to understand, don't have to flash nothing. It's just a test on pc so we can talk together before anything has to be flashed/changed inside syscon. Reply for sandungas where you need help, I will try to understand first before giving any suggestions.

 

[RIP-Felix]

I did the thing and got it to work @sundungas. EDIT: by that, I mean that I followed your readme and got the checksum to match the 40nm example. I did not get a frankenstein attempt to work...lol. End of edit...The Readme works like a charm! However, what's the purpose of the F6 mismatches? The readme just kida stops there and doesn't explain the purpose.

Also what's the point now? The modchip makes this easier. Don't we still need to replace the SYSCON chip, dump the EEPROM, and a bunch of other unfriendly tools like a bus pirate? Maybe it'll be easier once we can JTAG read/write the EEPROM?

 

[M4j0r]

Also what's the point now? The modchip makes this easier. Don't we still need to replace the SYSCON chip, dump the EEPROM, and a bunch of other unfriendly tools like a bus pirate? Maybe it'll be easier once we can JTAG read/write the EEPROM?

The modchip makes it easier but the syscon swap is the official method, but no ones uses the official method for the NAND dump either lol. Sony likes to over-engineer things for the mass produced items. They used modchips themself on PSP devkits.
Maybe one important point is that you're able to replicate the official method, but you can't replicate the modchip (you can but that involves again some "hacking").
About the JTAG: That's the one thing Sony knows how to handle. You won't find any active security relevant JTAG port on any Playstation. Sometimes it's disabled in the bootloader, sometimes using fuses.

 

[RIP-Felix]

About the JTAG: That's the one thing Sony knows how to handle. You won't find any active security relevant JTAG port on any Playstation. Sometimes it's disabled in the bootloader, sometimes using fuses.

I suspected that SONY wouldn't just leave it enabled. I was hoping they just disabled it by leaving a few resistors off the board, or setting a bit we can enable. If they permanently disabled it using fuse, well that's a dirty trick! I'm hoping the bitrraining is using the JTAG to gather the information about which pins are not communicating, meaning it's not permanently disabled. Now it could be disabled in software by the bootloader and not accessible after the Power Sequence when it's polled. But if that's the case, we could re-enable it. If we can find what's disabling it and modify it.

I would imagine they wouldn't want to disable it permanently for diagnostic reasons during repair (so they can use a bed of nails to diagnose and reprogram it). And if they were going to blow a buried fuse, then who cares about security measures, like not showing the pinouts on the schematic or labeling them on the silkscreen? Or are they just paranoid freaks who like to obfuscate everything?

Or am I a silly rabbit looking for a carrot in a mine filed?

 

[M4j0r]

I suspected that SONY wouldn't just leave it enabled. I was hoping they just disabled it by leaving a few resistors off the board, or setting a bit we can enable. If they permanently disabled it using fuse, well that's a dirty trick! I'm hoping the bitrraining is using the JTAG to gather the information about which pins are not communicating, meaning it's not permanently disabled. Now it could be disabled in software by the bootloader and not accessible after the Power Sequence when it's polled. But if that's the case, we could re-enable it. If we can find what's disabling it and modify it.

I would imagine they wouldn't want to disable it permanently for diagnostic reasons during repair (so they can use a bed of nails to diagnose and reprogram it). And if they were going to blow a buried fuse, then who cares about security measures, like not showing the pinouts on the schematic or labeling them on the silkscreen? Or are they just paranoid freaks who like to obfuscate everything?

Or am I a silly rabbit looking for a carrot in a mine filed?

The SC doesn't have JTAG access to any component, instead e.g. the bit training errors are transferred from the BE to Syscon via SPI.
And yes they permanently disable the JTAG on any component even though it doesn't help them in the service center.
The PinJig in the service center doesn't use any JTAG pads.
Even if e.g. the CELL JTAG would be enabled you'll notice that it doesn't follow the software standard. You'd need the special IBM JTAG tool and the right firmware (fpga bitstream) for it and also the software on your PC.
About the RSX: The JTAG is mainly for the FlexIO integration. Well, Rambus developed it - they're one of the leaders in hardware security solutions. The SB JTAG was only available on alpha prototypes, it was mainly developed by Toshiba.

 

[RIP-Felix]

The SC doesn't have JTAG access to any component, instead e.g. the bit training errors are transferred from the BE to Syscon via SPI.
And yes they permanently disable the JTAG on any component even though it doesn't help them in the service center.
The PinJig in the service center doesn't use any JTAG pads.
Even if e.g. the CELL JTAG would be enabled you'll notice that it doesn't follow the software standard. You'd need the special IBM JTAG tool and the right firmware (fpga bitstream) for it and also the software on your PC.
About the RSX: The JTAG is mainly for the FlexIO integration. Well, Rambus developed it - they're one of the leaders in hardware security solutions. The SB JTAG was only available on alpha prototypes, it was mainly developed by Toshiba.

Maybe I'm not getting something. JTAG is an industry standard built into most chips today. Each chip has a JTAG controller that can communicate with the rest of the chipset, say by SPI to the Flash controller, Debug controller, SYSCON or other chips.

The way I understood it, during POST the JTAG boundary scan checks circuit integrity, continuity/open circuits are flagged by the JTAG contoller and sent to the SYSCON (via SPI) as say, a BitTraining error and the general area affected. If all is good, it's safe for the Power Sequence to finish. And then perhaps JTAG is disabled before the bootloader starts. How can it be permanently disabled without a redundant circuit integrity check process? If they permanently disable it, then there is no way to pinpoint a broken I/O line at the RSX for example. I mean, how does the CPU or RSX itself know which pins are not connected? Is that information not polled from the JTAG boundary scan on boot? Is it some other, redundant, method?

I could see them blowing fuses that connect the daisy chain, so that you can't tap into the entire JTAG. You'd only have access to one chp at a time. But they should be in a physical location you can replce.

Do you mean the JTAG Boundary Scan Description Language (BDSL) are proprietary and developed specifically for SONY by IBM under NDA? That would have to also be a parthnership with Nvidia too for the RSX as well, no? Unless it leaked, we're SOL just as they had in mind. But that doesn't mean we can't mess around in there, like we are with the UART, does it? Maybe we can't use fancy commercial software GUI's with live pinouts and everything. But could we putty our way around in there?

 

[sandungas]

I did the thing and got it to work @sundungas. EDIT: by that, I mean that I followed your readme and got the checksum to match the 40nm example. I did not get a frankenstein attempt to work...lol. End of edit...The Readme works like a charm! However, what's the purpose of the F6 mismatches? The readme just kida stops there and doesn't explain the purpose.

Is nice you completed the exercise for the 40nm RSX, now is easyer for us to discuss the details and if someone have some doubt you can help them

The [Analisys]>[Data comparison]>[Compare]>F6>F6>F6>F6... is something you are going to use a lot
Try to open the 2 thermal config files included, compare them and press the F6 several times... and you will realize there are only 2 bytes that differs in between them (0x88 for 40nm... or 0x8B for 65nm). That bytes are completly unknown, i think are related with the thermal monitor chips i was talking about here, and the speculation written here but i dont have any proof, so by now the best we can do is to copy sony

Another comparison you could do is to open the file "2nd_try_dump_original.bin", and [Edit]>[Select Block]: Start offset 3300, Length 200
Then copy that block... create a new file... paste it in the new file... and save it as "COK-001 original thermal config.bin"
After that compare it with the thermal configs i provided to see how different they are, this is why i said initially that was looking very broken, there are a lot of differences

Anyway... another of the reasons why i made that guide is to show the different combinations of the optional steps that needs to be tryed
In the file i named "test_1" i didnt made any of the optional steps (this is like the basic test without any optional step). In "test_2" i also deleted the XDR init config. And in "test_3" i made all the optional steps
There are more combinations posibles, but i think this ones worths a try

Also what's the point now? The modchip makes this easier. Don't we still need to replace the SYSCON chip, dump the EEPROM, and a bunch of other unfriendly tools like a bus pirate? Maybe it'll be easier once we can JTAG read/write the EEPROM?

Well, this is just theory... but at some point someone could find how to generate the valid data for the different RSX revisions just by patching any of the retail syscons
In that case it could be posible to do the frankenstein in the same syscon that was shipped with the motherboard from factory (in other words, without replacing syscon)

Or are they just paranoid freaks who like to obfuscate everything?

Bingo !, this is specially true when talking about playstation's software, in the PS3 the securty is breached very deep and there are many examples, sometimes they encrypts the same thing several times, like a matroska, and after decrypting it several times you realize the only thing it was storing was a single byte with value 0x01 (wtf moment). Or the PKG's for the classics games from PSN... at the most deep there is an ISO but is packed and encrypted several times
I remember also a conference about the PS4 security by team overflow when they went cruel with the hdd security because how much hits the performance the obfuscations method they uses (in the PS3 happens a bit the same, the hdd access speeds sucks, and network speeds, etc....)
It seems in the PS5 they had to change a bit that philosophy because is designed for performance, but... is sony they cant change too much XD

With hardware im not so sure if we could use the word obfuscation, but yeah, they are very used to counterfeit hackers, there are lot of times when they "hides" the critical traces of the circuit in internal layers of the motherboard because this way is not posible to connect to them, JTAG ports fryed and things like that
The huge amount of "missing" components in the PS3 motherboards uses to be because when they are upgrading a component or subcircuit they prepares solder pads to add components that could be considered optional (capacitors to stabilish lines, or protections to prevent electrical problems). In the initial revisions they could populate that pads but in later revisions of the motherboard (when they are confident that components are not needed) they removes the pads, traces, etc...

 

[M4j0r]

Maybe I'm not getting something. JTAG is an industry standard built into most chips today. Each chip has a JTAG controller that can communicate with the rest of the chipset, say by SPI to the Flash controller, Debug controller, SYSCON or other chips.

Yes, all the chips do have a JTAG interface but it's disable and not connected to anything.

The way I understood it, during POST the JTAG boundary scan checks circuit integrity, continuity/open circuits are flagged by the JTAG contoller and sent to the SYSCON (via SPI) as say, a BitTraining error and the general area affected. If all is good, it's safe for the Power Sequence to finish. And then perhaps JTAG is disabled before the bootloader starts. How can it be permanently disabled without a redundant circuit integrity check process? If they permanently disable it, then there is no way to pinpoint a broken I/O line at the RSX for example. I mean, how does the CPU or RSX itself know which pins are not connected? Is that information not polled from the JTAG boundary scan on boot? Is it some other, redundant, method?

None of the error info is retrieved over JTAG (as I said it's dead and not connected), everything is done over the SPI control ports (BE, RSX, SB). The rsx modchip also just connects to the RSX SPI interface. These SPI interfaces have nothing to do with JTAG.

I could see them blowing fuses that connect the daisy chain, so that you can't tap into the entire JTAG. You'd only have access to one chp at a time. But they should be in a physical location you can replce.

Sony doesn't daisy chain different chips, only multiple function units (on different dies).

Do you mean the JTAG Boundary Scan Description Language (BDSL) are proprietary and developed specifically for SONY by IBM under NDA? That would have to also be a parthnership with Nvidia too for the RSX as well, no? Unless it leaked, we're SOL just as they had in mind. But that doesn't mean we can't mess around in there, like we are with the UART, does it? Maybe we can't use fancy commercial software GUI's with live pinouts and everything. But could we putty our way around in there?

The langugage description for the standard commands is just the normal one but everything else is custom.
Also note that the CELL JTAG isn't even designed for error checking, instead it has a whole bunch of other pins for that. Here're some documents: https://pastebin.com/X35tZdZY .

You can probably reenable all of the JTAG ports, but at least for the main chips you need a SEM and a very precise laser (because we're talking about <=90nm).

 

[RIP-Felix]

This post is a review of the software modifications made by squeept in the second attempt of the frankenstein, is also a continuation of the recap written by @RIP-Felix here

After thinking a bit in it... i realized the best way to discuss all this details is if some of you gets used to the software procedures, we need at least 4 or 5 persons used to it, also some of the steps are optional, is like a cook recipe which ingredients needs to be discussed so please dedicate some time to this explanation and practise a bit with the file samples im going to upload in this post
First download this samples ---> https://workupload.com/file/H9RJAPHxpy6

And take a read at the README.TXT ... is like a tutorial for people not used to hexeditors, i suggest to download HxD and follow the steps "like a robot" to generate some files and to see by yourself what squeept did

Also, is included this image that is a resume in itself, this is what we need to do
As you can see there are 3 steps that are optional, squeept did 2 of the 3 optional steps (missed one of them... but we dont know if that one was important)

In resume... the only things that can be considered controversial in the "2nd_try_modified_by_squeept.bin" was the invalid thermal config region, and 1 of the options missing

Please @RIP-Felix @dead-end @vyktormvmpay25 @DoublesAdvocate try to complete the exercise at the bottom of the README.TXT

I sounds to me like another attempt is needed. This time with all the optional steps according to your tutorial! So if @squeept is willing to give it another go and send us his original dump. We can follow the steps also, and upload a checksum. If everybody's check sum matches, then we know everyone did it right. If not, everybody rechecks the steps and generates a new checksum. Once they match we know it good to upload to the SYSCON ship and make another attempt. I think we have the hardware changes nailed down. Let's hope we finally have the software figured out.

So I guess it's up to @squeept or perhaps @vyktormvmpay25 to give it a try. It's beyond my abilities.

 

[squeept]

The frankenstein with the swapped syscon, I used the syscon from the board that I pulled the 65nm RSX from. I thought that's what y'all told me to do? I'm afraid at this point, I don't remember which files/dumps are which to any sort of certainty since it's been months since I was dicking with the syscon swap.

I was just peeking in, though. Looks like I missed a few dozen pages on multiple threads, so I'll try to catch up on what I missed and see if I can help later this week. I don't have it in me right now.

I just had a re-fail from a 3034 reball during stress testing, that will be my next try with the mod chip.

 

[sandungas]

I sounds to me like another attempt is needed. This time with all the optional steps according to your tutorial! So if @squeept is willing to give it another go and send us his original dump. We can follow the steps also, and upload a checksum. If everybody's check sum matches, then we know everyone did it right. If not, everybody rechecks the steps and generates a new checksum. Once they match we know it good to upload to the SYSCON ship and make another attempt. I think we have the hardware changes nailed down. Let's hope we finally have the software figured out.

So I guess it's up to @squeept or perhaps @vyktormvmpay25 to give it a try. It's beyond my abilities.

Yes, incase someone is having a lot of problems with the software side we can prepare the file that needs to be written
And we can even calculate the checksums for the modifyed regions and add them to it, so the other person only needs to write it and boot the PS3 (no need to do the command "eepcsum" to check and fix them because all them will be correct). Honestly, is faster and easyer to do it in the PS3 than in PC, but im just mentioning it just because is posible to do it with this python script released by @M4j0r
You just need to copypaste the python code from the post, and save it in your PC with a name like... "Calculate_eepcsum.py" and run it with:

C:\Calculate_eepcsum.py filename.bin

The only confusing thing of it is it displays the checkum "byte swapped" when you compare it with the output of the command "eepcsum"

And yeah, im also optimistic with this, the hardware changes should be right

The frankenstein with the swapped syscon, I used the syscon from the board that I pulled the 65nm RSX from. I thought that's what y'all told me to do? I'm afraid at this point, I don't remember which files/dumps are which to any sort of certainty since it's been months since I was dicking with the syscon swap.

I was just peeking in, though. Looks like I missed a few dozen pages on multiple threads, so I'll try to catch up on what I missed and see if I can help later this week. I don't have it in me right now.

I just had a re-fail from a 3034 reball during stress testing, that will be my next try with the mod chip.

When i was reviewing your files from the first attempt i was not sure, initially i just knew one of them was from the COK-001 and they was very different, and when i relized the other was from a DIA-002 it made more sense that you took it from the same DIA-002 retail motherboard where you got the 65nm RSX
Thats the only way to do it with components from retail motherboards because the syscon 302GB from the DIA-002 keeps the support for the COK-001 and is the first time it was introduced the support for the RSX 65nm

I was confused because later you bought a syscon 304GB, right ?, the software procedures are the same, the only difference is this one supports the 40nm RSX and never was used in retail motherboards

You didnt made any mistake in the software changes of your second attempt btw
Is just we was not keeping attention when @M4j0r mentioned in one of his posts that it was needed to modify the thermal config region, also one of the optional changes i added in the guide was mentioned only one time (from the 2 times that m4j0r mentioned the required software changes), it seems you missed that post... but anyway is needed to write to the EEPROM a few times to try all the optional steps, without them etc...

The point is... in the image i used in the guide some of that optional steps are represented as "not used" regions, but thats probably because the image is older than the RSX 65nm/40nm support
The fact m4j0r found some unknown bytes in that "not used" regions probably means that they added some new internal syscon functions to read them

 

[RIP-Felix]

I just had a re-fail from a 3034 reball during stress testing, that will be my next try with the mod chip.

I know you don't like using internal access mode, but if you use bringup command or lasterrlog and get something like "[POWERSEQ] Error : BitTraining BE:RRAC:RX2:GLOBAL:RX_Status" then you should try reflowing/reballing the CPU. I suspect that's what happened to the first attempt. The board I sent you had the above error, which I not believe is the 1.2v_YC_RC_VDDIO RX2 "Recieve line" on the CPU. It's one of the communication lines between the CPU/RSX. It either means it's not recieving anything from the RSX on it's TX2 line (because the RSX BGA broke there), or that the RX2 line is broken at the CPU's BGA. Since you reballed the RSX, then it was probably the CPU.

I don't remember if you said reflowed the CPU? I do remember you saying you reballed the RSX to a GLOD and set it aside to perform the first frankensten mod on it. @botakompong says that a GLOD usually means a break in the connection to RAM (CPU<-->RAM or RSX<-->RAM). So if all voltages were good and the RSX was reballed, the only explanation left is the CPU's BGA or bumps on RSX RAM. If you still have that board, you could try reflowing/reballing the cpu. Perhaps just verify the voltages again first. @sandungas did you say his eeprom changes looked okay from the first attempt?