PS3 Frankenstein PHAT PS3: CECHA with 40nm RSX

[RIP-Felix]

Take another look at my post with the frankie patches, i been updatiing it with a new style, is more clear, and there is an important change, now im mentioning the RSX model names "by series" and i removed all mentions to the concept of "RSX 40nm v1" and "RSX 40nm v2" completly because if the IDs are swapped is veeery misleading
You know... if we tell someone the "40nm RSX v1" was used in the first superslim motherboards, and the "40nm RSX v2" was used in the last slim motherboards the first thing the other person is going to tell is "wait, can you confirm that again? because it looks like you did a typo when you wrote it", lol
https://www.psx-place.com/threads/f...cecha-with-40nm-rsx.28069/page-77#post-324662

Anyway... im wondering if i have to update the patches to replace all the mentions of 21EC by 21EB. In the current version of the patches im not doing yet, waiting for a confirmation from #m4j0r

Yes, if you look at the list of FlexIO IDs that's not the first time (the SX SB has a lower ID than the PX SB).

I don't know which chip corresponds to which ID, but the SUR-001 came only with the 21 EC. All later boards support 21 EC or 21 EB, Syscon detects which chip is used and selects the right data.

I can confirm @David Rainer's results with my own CXD5301. His was a CXD5301 on a COK-001 (US model CECHA01) and mine was COK-002 (US model CECHE01, non-MG edition). Both required the 21 EC data.

Now, @David Rainer asked a question about the 21 EB data. I had him write that data first, then test. It didn't work. Then I had him write the 21 EC data, which did work. Am I correct in thinking that the second write overwrites the EB bit with EC? That we don't need to revert it back to it's original state before writing the bit EC? I am under the impression that the change to the eeprom at address 32FE 21 EB is just overwritten with EC. The checksum is only one number off (Addr:0x000032fe should be 0xffff657c after changing to 21 EB, vs Addr:0x000032fe should be 0x647c after changing to 21 EC), which makes sense to me since EB is one letter lower than EC. So the checksum should be 64 for EB and 65 for EC. So even though the write to fix the checksum is different, all we did was overwrite the same bit with the correct identifier. Everything else was correctly changed.

Here's my log to show the process. You can see that 21 EB resulted in the same BitTraining error (3034/4002) that we expect to see before the new RSX training data is written (or ORBIS modchip installed)...

>$ w 3242 03 61 82 80 01 91
w 3242 03 61 82 80 01 91
w complete!
[mullion]$
>$ w 3254 21 EB
w 3254 21 EB
w complete!
[mullion]$
>$ w 348B 8B
w 348B 8B
w complete!
[mullion]$
>$ w 34AF 8B
w 34AF 8B
w complete!
[mullion]$
>$ eepcsum
eepcsum
sum:0xed10
Addr:0x000032fe should be 0xffff657c
sum:0x1800
Addr:0x000034fe should be 0x5915
Addr:0x000039fe should be 0x0038
Addr:0x00003dfe should be 0x00ff
Addr:0x00003ffe should be 0x00ff
>$ w 32fe 7c 65
w 32fe 7c 65
w complete!
[mullion]$
>$ eepcsum
eepcsum
Addr:0x000032fe should be 0x657c
sum:0x1800
Addr:0x000034fe should be 0x5915
Addr:0x000039fe should be 0x0038
Addr:0x00003dfe should be 0x00ff
Addr:0x00003ffe should be 0x00ff
>$ w 32fe 7c 65
w 32fe 7c 65
w complete!
[mullion]$
>$ w 34fe 15 59
w 34fe 15 59
w complete!
[mullion]$
>$ eepcsum
eepcsum
Addr:0x000032fe should be 0x657c
Addr:0x000034fe should be 0x5915
Addr:0x000039fe should be 0x0038
Addr:0x00003dfe should be 0x00ff
Addr:0x00003ffe should be 0x00ff
>$ AUTH
Auth successful
>$ bringup
bringup
[SSM] state: 0000 -> 0101
Bringup Mode #0 (0xFF)
[SSM] ssmCb_OnStartingBePowOn() called.
[SSM] First Boot.
[SSM] Bringup mode : syspm_stat=00000000/00000000
[POWSEQ] PowerSeq_Setup called.
[SSM] state: 0101 -> 0201
[POWSEQ] AV Backend Setup
[SSM] state: 0201 -> 0102
[SSM] state: 0102 -> 0202
[SSM] state: 0202 -> 0103
[SSM] state: 0103 -> 0203
[SSM] ssmCb_BeforeBeOn() called.
[SSM] state: 0203 -> 0104
Psbd_SbTransMode_Half:0x21e2
>$
[POWERSEQ] Error : BitTraining RSX:RRAC:BX0:BX:FLEXIO_ID
[SSM] state: 0104 -> 0304
[SSM] ssmCb_AfterBeOn2() called.
[SSM] PowSeq Fail : Detected !
[SSM] state: 0304 -> 0700
[POWSEQ] AV Backend Letup
[SSM] Shutdown mode : syspm_stat=00000000/00000000
[ERROR]: 0xa0404002
[ERROR]: 0xa0403034
[POWSEQ] PowerSeq_Letup called.
[SSM] state: 0700 -> 0600
(PowerOff State) (Fatal)

[mullion]$
>$ shutdown
shutdown
[SSM] state: 0600 -> 0000
[SSM] Error state is cleared.
(PowerOff State)
>$ w 3254 21 EC
w 3254 21 EC
w complete!
[mullion]$
>$ eepcsum
eepcsum
sum:0x0100
Addr:0x000032fe should be 0x647c
Addr:0x000034fe should be 0x5915
Addr:0x000039fe should be 0x0038
Addr:0x00003dfe should be 0x00ff
Addr:0x00003ffe should be 0x00ff
>$ w 32fe 7c 64
w 32fe 7c 64
w complete!
[mullion]$
>$ eepcsum
eepcsum
Addr:0x000032fe should be 0x647c
Addr:0x000034fe should be 0x5915
Addr:0x000039fe should be 0x0038
Addr:0x00003dfe should be 0x00ff
Addr:0x00003ffe should be 0x00ff
>$ AUTH
Auth successful
>$ bringup
bringup
[SSM] state: 0000 -> 0101
Bringup Mode #0 (0xFF)
[SSM] ssmCb_OnStartingBePowOn() called.
[SSM] First Boot.
[SSM] Bringup mode : syspm_stat=00000000/00000000
[POWSEQ] PowerSeq_Setup called.
[SSM] state: 0101 -> 0201
[POWSEQ] AV Backend Setup
[SSM] state: 0201 -> 0102
[SSM] state: 0102 -> 0202
[SSM] state: 0202 -> 0103
[SSM] state: 0103 -> 0203
[SSM] ssmCb_BeforeBeOn() called.
[SSM] state: 0203 -> 0104
Psbd_SbTransMode_Half:0x21e2
>$
[SSM] state: 0104 -> 0204
[SSM] state: 0204 -> 0105
[SSM] state: 0105 -> 0400
(PowerOn State)
[SERV NVS] READ CMD

Boot Loader SE Version 1.5.0 (Build ID: 1798,18531, Build Data: 2007-01-10_12:09:26)
Copyright(C) 2006 Sony Computer Entertainment Inc.All Rights Reserved.
[SERV SETCFG] XDR (CH0,CH1) ASSERT
[SERV SETCFG] XDR (CH0,CH1) DEASSERT
[INFO]: Connecting to Debug Device (SB UART)
[SERV NVS] READ CMD

...It boots up fine after that!

So @sandungas I have copied your new format into my tutorial. But I flipped them around. So now CXD5300 & 5301 use EC and 5302 (no IHS) is EB. Does that seem right? Link to tutorial.

 

[sandungas]

I can confirm @David Rainer's results with my own CXD5301. His was a CXD5301 on a COK-001 (US model CECHA01) and mine was COK-002 (US model CECHE01, non-MG edition). Both required the 21 EC data.

Well, we already had one report of CXD5301 requiring ID=21EC from david, dont get me wrong, all reports are important but we are at the same point, what we have by now is:

CXD5300xxx = posible 21EC ? (m4j0r)
CXD5301xxx = 21EC (david, felix)
CXD5302xxx = no reports

Now, @David Rainer asked a question about the 21 EB data. I had him write that data first, then test. It didn't work. Then I had him write the 21 EC data, which did work. Am I correct in thinking that the second write overwrites the EB bit with EC? That we don't need to revert it back to it's original state before writing the bit EC?

Right, we are writing them at the same offset
For curiosity sake... as far i remember, in the syscons configured for 90nm RSX the value of those 2 bytes is FF FF

I am under the impression that the change to the eeprom at address 32FE 21 EB is just overwritten with EC. The checksum is only one number off (Addr:0x000032fe should be 0xffff657c after changing to 21 EB, vs Addr:0x000032fe should be 0x647c after changing to 21 EC), which makes sense to me since EB is one letter lower than EC. So the checksum should be 64 for EB and 65 for EC. So even though the write to fix the checksum is different, all we did was overwrite the same bit with the correct identifier. Everything else was correctly changed.

Right too, the algorithm to calculate the checksums does simple maths operations and the result depends of the data we are checking. If we modify only 1 or 2 bytes the resulting checksum is going to be very similar than the original. With the changes inside the thermal config region happens the same because we are just changing 1 or 2 bytes in it... and also something that is popular, to enable the SB debug output in mullions is also needed to write 1 byte... same stuff, the resultiing checksum is going to be similar to the original

Btw, not sure if you did it, but in general... after writing something (and incase is needed to update a checksum for it) i dont suggest to indicate the new checksum because we are not completly sure if all the PS3 contains the same exact data in the region we are writing. If we give the new checksum we are taking the risk of making a mistake, instead of that is a lot better to explain how to update it manually by looking at the info given by the command eepcsum, we are lucky the command is telling us what to do

So @sandungas I have copied your new format into my tutorial. But I flipped them around. So now CXD5300 & 5301 use EC and 5302 (no IHS) is EB. Does that seem right? Link to tutorial.

Right, i was waiting at least one report from a CXD5300 before modifying my post, but i was almost convinced to flip the IDs since the other day. Anyway, i just updated it right now
https://www.psx-place.com/threads/f...cecha-with-40nm-rsx.28069/page-77#post-324662
Btw, check the patches in your tutorial again... you forgot to flip the IDs in some of them

Spoiler

Lolol, congrats for the graduate, i can feel that gif, the kind of insanity win where you are not believing your eyes, lol
Is not only that you upgraded the RSX, but also you got the final confirmation that the old 90nm RSX was the problem. Also it feels nice to know you didnt killed the motherboard in the previous experiments
Is great to have some positive reward after all the time and effort you are investing in fixing PS3's, it seems at the end of the story the DR. was not completly crazy

 

[alty75]

For curiosity sake... as far i remember, in the syscons configured for 90nm RSX the value of those 2 bytes is FF FF

This is correct

 

[Computer Booter]

Hi friend, to be honest by the time you buy all the equipment needed, it might be cheaper and better to ship everything off to @David Rainer who is a professional with amazing tech repair equipment, experience and knowledge. Hopefully David will see these messages soon and can help you out.

Appreciate the compliment I wouldn't call myself a professional yet, but I am trying my best to put in the time and effort to refine the process. Ill likely be formally offering these services locally soon and would be willing to talk to anyone interested in the service. Either message me or join our discord. https://discord.gg/y22M4Y3H


Sent from my iPhone using Tapatalk

 

[Ben Leeth]

Hi friend, to be honest by the time you buy all the equipment needed, it might be cheaper and better to ship everything off to @David Rainer who is a professional with amazing tech repair equipment, experience and knowledge. Hopefully David will see these messages soon and can help you out.

Thanks so much! I know there are people on here that can but it's hard to sift through 80+ pages to figure out exactly who could help.

 

[RIP-Felix]

@M4j0r @sandungas

Last night @Computer Booter attempted a second Frankenstein with a 40nm CXD5301 on a COK-001. Just like the first one this console is not displaying out HDMI!

They output via analog multiAV and the HDMI cord is detected, but will not switch. Once could be bad luck, but twice makes a pattern!

So now we would like to try reverting the SYSCON changes to stock and installing an ORBIS modchip to see if that will narrow the issue down to our method. So can you confirm the original settings to write?

I will note that I have sucessfully installed a 40nm CXD5301 on a COK-002 using those writes and do not have this issue. So it appears to be isolated to COK-001 MB's.

 

[vyktormvmpay25]

Yes Felix please try writing ID code for 90nm rsx back for cok001 model and try orbismodchip. If that isn't working, maybe his wrong rsx soldering with one corner to vdda around or merged balls around that area.
This is why I don't like those cok001, most problems are with them, bumps inside board, to sensitive on heat. Anyway if I don't catch that please let him desolder one and add on all 4 corners 4 caps 03mm as most ps3 have on all boards after cok002. Just may help, remember he tested software mod on his orbis modchip and after that is working fine without modchip. Make sure working board is cok001. Atm I did not tested yet any cok001, I have board but no good rsx atm. Hope I catch with stream in the morning.

 

[Computer Booter]

@M4j0r @sandungas

Last night @David Rainer attempted a second Frankenstein with a 40nm CXD5301 on a COK-001. Just like the first one this console is not displaying out HDMI!

They output via analog multiAV and the HDMI cord is detected, but will not switch. Once could be bad luck, but twice makes a pattern!

So now we would like to try reverting the SYSCON changes to stock and installing an ORBIS modchip to see if that will narrow the issue down to our method. So can you confirm the original settings to write?

I will note that I have sucessfully installed a 40nm CXD5301 on a COK-002 using those writes and do not have this issue. So it appears to be isolated to COK-001 MB's.

One difference is, the first one initially worked on HDMI until I scrubbed and ultrasonic cleaned it. It still blinks to signal black screen and then back to no signal. This second one doesn't even detect a signal and also overheats so I think either bad RSX resoldering OR other damaged components. Has been a good learning experience so far haha.


Sent from my iPhone using Tapatalk

 

[vyktormvmpay25]

David you can try desolder one and add 4 caps on rsx corners and test each sides to look even. It should be from there. Not sure yet you can choose easy way to test orbis modchip.
Edit
I'm not surprised if on that corner one pad is not soldered/deformed while clamps were tied back. Those caps are used as spacers on all 40nm up to 28 nm. Even in ps4 are totally removed and I add them. Most people won't admit they are necessarily but I do it like that.

 

[sandungas]

@M4j0r @sandungas

Last night @David Rainer attempted a second Frankenstein with a 40nm CXD5301 on a COK-001. Just like the first one this console is not displaying out HDMI!

They output via analog multiAV and the HDMI cord is detected, but will not switch. Once could be bad luck, but twice makes a pattern!

So now we would like to try reverting the SYSCON changes to stock and installing an ORBIS modchip to see if that will narrow the issue down to our method. So can you confirm the original settings to write?

I will note that I have sucessfully installed a 40nm CXD5301 on a COK-002 using those writes and do not have this issue. So it appears to be isolated to COK-001 MB's.

COK-001 with 90nm RSX (to return to factory settings)

w 3242 09 70 89 70 06 90
w 3254 FF FF
w 348B FF
w 34AF FF

Edit: Btw, as far i remember the COK-001 required some special configuration in that resistors specific for COK-001, have you re-checked that ?
Right now i still dont understand what needs to be made with that resistors for every motherboard/rsx combo, so dont ask me about what im talking about ... is just i remember a bunch of post ago some of you was telling that one of the changes related with the resitors was not needed in COK-001... or it was the otherway around and only the COK-001 needed it ?, dunno

 

[Computer Booter]

David you can try desolder one and add 4 caps on rsx corners and test each sides to look even. It should be from there. Not sure yet you can choose easy way to test orbis modchip.
Edit
I'm not surprised if on that corner one pad is not soldered/deformed while clamps were tied back. Those caps are used as spacers on all 40nm up to 28 nm. Even in ps4 are totally removed and I add them. Most people won't admit they are necessarily but I do it like that.

Both of the frankies we have done recently are displaying slightly different actions. The first one is sensing an HDMI signal and making the TV go from "no signal" to a black screen for a second, and then back to "no signal" which makes me think that something is wrong with the board and not the reball. The second one we were working on tonight, we reflowed the RSX again and are still getting the "no signal" with NO flash of recognition at all from the TV which is slightly different behavior than the first one. That one I do believe that possibly the board is warped in the VDDA area causing it, but not 100% sure. Both of the boards have kind of been through hell so I am not surprised that they have issues. As a last last last resort before reballing the first one again I might do some more troubleshooting and/or replace the HDMI connector.

Yes we will try that next, I will probably wait to reball another until I get the proper jig. I am going to take a break from ps3's for a few days as I have been spending too much time working on them and I have other things around the shop that need attention. Really appreciate all the help it has been a blast. In the meantime while we wait for more equipment including the jig/microscope+camera/lights to arrive ill help @RIP-Felix "sabotage" and get more readings for the error codes. Also if I find some free time I will reball and ready some more 40nm RSX chips.

 

[Jasont755]

Hi all, Been watching this thread for a while and love the work you are all doing... I have a CECHB00 which I believe may be on its last legs looking to preserve the console and give it a fresh(ish) set of legs with having the RSX replaced. I'm based in the UK and by googling I cannot find anyone that would offer this service so I've resorted to commenting here thanks in advance

 

[_XBrD4shDOE_808_]

the hdmi is identified but nothing happens? Could it be a problem with the HDMI controller? such as, for example, the controller does not identify the new Rsx or the controller has a different firmware or configuration that the 40 nm rsx does not recognize. if it's a software thing, I think they can make a patch that "changes" the firmware or reconfigures it @sandungas ?

I ask because, from what I remember, the HDMI controller of the first model for the slim/SS as far as I can remember has changed but I don't know to what level, if it would be possible to change the HDMI controller together with the RSX for one used in PS3's Slim, for example, or if the pinout is different.

taking advantage, we had some report of this error but on motherboard COK 002/002w or are they on boards that were exchanged for 65nm RSX instead of 40nm?

 

[Workz_777]

Hi all, Been watching this thread for a while and love the work you are all doing... I have a CECHB00 which I believe may be on its last legs looking to preserve the console and give it a fresh(ish) set of legs with having the RSX replaced. I'm based in the UK and by googling I cannot find anyone that would offer this service so I've resorted to commenting here thanks in advance

Hi Jason, maybe as an idea you could retrieve your Syscon error logs first, to see under the hood what's going on. Here is the link to Felix's guide:- https://www.psx-place.com/threads/r...s-replacement-ylod.25260/page-192#post-295119

If your PS3 is working then maybe don't fix it until it actually stops working. Reason being, transplanting / swapping an RSX (90nm to 40nm) if not done correctly might kill the PS3 mechanically, it's risky business. Also trying to find someone who can do this for you professionally and also give you a warranty / guarantee is going to be very rare. I'm not trying to put you off, but if your PS3 is working then don't look a gift horse in the mouth (for now). If ever your PS3 does break-down, you could always sell it to me, i'm in the UK too ...or you could attempt this RSX Franken-Mod at that point, having nothing to lose (kinda). Just my penny's worth.

 

[RIP-Felix]

Just to recount what we tried on stream last night. @Computer Booter applied @sandungas' fallback codes to revert the SYSCON eeprom back to stock. Then he installed an ORBIS modchip. The ORBIS did it's job of spoofing the RSX_ID and the console booted. However, it had exactly the same problem. No HDMI out. AV only.

So that confirms the SYSCON patches are good and were not the problem. @M4j0r can rest easy!

 

[Computer Booter]

the hdmi is identified but nothing happens? Could it be a problem with the HDMI controller? such as, for example, the controller does not identify the new Rsx or the controller has a different firmware or configuration that the 40 nm rsx does not recognize. if it's a software thing, I think they can make a patch that "changes" the firmware or reconfigures it @sandungas ?

I ask because, from what I remember, the HDMI controller of the first model for the slim/SS as far as I can remember has changed but I don't know to what level, if it would be possible to change the HDMI controller together with the RSX for one used in PS3's Slim, for example, or if the pinout is different.

taking advantage, we had some report of this error but on motherboard COK 002/002w or are they on boards that were exchanged for 65nm RSX instead of 40nm?

Well the first of two WAS displaying through HDMI before I scrubbed and ultrasonic cleaned it, so I either damaged a component or the bga under rsx. I don't think that one is the encoder. The second one simply does nothing on hdmi. Will update if we figure it out.


Sent from my iPhone using Tapatalk

 

[RIP-Felix]

Well the first of two WAS displaying through HDMI before I scrubbed and ultrasonic cleaned it, so I either damaged a component or the bga under rsx. I don't think that one is the encoder. The second one simply does nothing on hdmi. Will update if we figure it out.


Sent from my iPhone using Tapatalk

The HDMI transmitter seems like an unlikely candidate to me, but it's not out of the realm of possibility. The fact that 2 of your COK-001's in a row had an identical issue smack me as some kind of pattern, but we have to be careful not to fall victim to that bias. It could just be coincidence.

So we should perform due diligence with this console and troubleshoot the HDMI circuit like you did with the first one. Just to rule that out and because there is a non-zero chance it'll work.

I also suggest you replace the Thermal fuse. I know it tested fine and isn't giving us an error, but my goal is 2 fold...

1. I'd like to know the error it produces without it.
2. They can be bad and not be open. They tend to read 2-3 ohms nominal, but it could have some funny business going on. Not reacting to temperature like it's supposed to, for example.

The JOVY is OP! It might be cooking a component like that. I'm not sure how susceptible thermal fuse chemistry is to that much heat.

 

[alty75]

Thats the kind of win that feels nice, after fighting with it and having an "eureka" moment
3 custom frankensteins so far and counting

I've got a COK-002 here that I put an 65nm RSX on and it produced the GLOD.
Yes I had carried out the resistor modifications as required,so it's not the problem.
I kinda though ah maybe the RSX is foobarred so I put another RSX on only to have the same issue GLOD.
That tells me that it's not the RSX's as 2 in a row with the GLOD would befew and far between.
Another FRANKENSTEIN giving me grief.
Out of 4 x COK-002 units I have 2 successful mods and 2 that just don't want to play the game
Any suggestions would be greatly appeciated

ADDED INFO.
I am able to boot the console with all 3 FLEX_IO RSX Training datas and the one FLEX_IO ID 21 E8
There is something on the board producing the GLOD,as far as I can tell it is not the resistors as I have carried out the mod and even removing the diagonal to ground(R2054 replaced with R2153) resistors, it still boots but with tthe GLOD and no HDD activity as though the RSX is no good or pads are pulled from thre top right corner,which I have come across many times over the years. Repaired the missing pads and all good but there are no missing pads on this init.
I have even istalled a 47k on the R2002/2001 points with the same result

 

[sandungas]

the hdmi is identified but nothing happens? Could it be a problem with the HDMI controller? such as, for example, the controller does not identify the new Rsx or the controller has a different firmware or configuration that the 40 nm rsx does not recognize. if it's a software thing, I think they can make a patch that "changes" the firmware or reconfigures it @sandungas ?

I ask because, from what I remember, the HDMI controller of the first model for the slim/SS as far as I can remember has changed but I don't know to what level, if it would be possible to change the HDMI controller together with the RSX for one used in PS3's Slim, for example, or if the pinout is different.

taking advantage, we had some report of this error but on motherboard COK 002/002w or are they on boards that were exchanged for 65nm RSX instead of 40nm?

There are a couple of HDMI controllers (and as far i remember 4 or 5 IDs for them), and a huge amount of the syscon firmware is related with it, just to throw some random numbers... around 10% or 20%, there is also a dedicated SPI channel in between them that allows to exchange data in both directions, i dont know how it works but it seems syscon handles some of the HDMI data... i guess some of this data are the CEC commands, one of them allows to boot the PS3 with the TV remote controller, this command is sent by the TV to the PS3 (HDMI controller first), then syscon catchs it and boots the PS3, i guess with the others could happen something similar
And im wondering is syscon have a reserved EEPROM region to configur the HDMI controller, this could be the kind of data that is send in a stream to configure it
But i dont think thats the problem because we are using the factory syscon with the factory HDMI controllers, so both should be compatibles with each other
My only suggestion is to try to boot the PS3 several times just incase this kind of "software init process" is stucked for some reason, lets say... because the motherboard had a burned HDMI controller before
Dunno, probably all you are doing it... is just a matter of booting the PS3 without any display cable (a couple of times), and with a HDMI cable only (another couple of times), and with AV cable only (another couple of times)... maybe some of this stupid tests could make the HDMI chip to wake up

Just to recount what we tried on stream last night. @David Rainer applied @sandungas' fallback codes to revert the SYSCON eeprom back to stock. Then he installed an ORBIS modchip. The ORBIS did it's job of spoofing the RSX_ID and the console booted. However, it had exactly the same problem. No HDMI out. AV only.

So that confirms the SYSCON patches are good and were not the problem. @M4j0r can rest easy!

Good to know, in the COK-001 the video output is more tricky than any other PS3 model because the EE+GS for PS2 emulation, so are a bit more prone to problems, i would not do more reballs to that boards, i guess it should be something else

I've got a COK-002 here that I put an 65nm RSX on and it produced the GLOD.
Yes I had carried out the resistor modifications as required,so it's not the problem.
I kinda though ah maybe the RSX is foobarred so I put another RSX on only to have the same issue GLOD.
That tells me that it's not the RSX's as 2 in a row with the GLOD would befew and far between.
Another FRANKENSTEIN giving me grief.
Out of 4 x COK-002 units I have 2 successful mods and 2 that just don't want to play the game
Any suggestions would be greatly appeciated

ADDED INFO.
I am able to boot the console with all 3 FLEX_IO RSX Training datas and the one FLEX_IO ID 21 E8
There is something on the board producing the GLOD,as far as I can tell it is not the resistors as I have carried out the mod and even removing the diagonal to ground(R2054 replaced with R2153) resistors, it still boots but with tthe GLOD and no HDD activity as though the RSX is no good or pads are pulled from thre top right corner,which I have come across many times over the years. Repaired the missing pads and all good but there are no missing pads on this init.
I have even istalled a 47k on the R2002/2001 points with the same result

Deadend made a frankie 65nm the first day the patches was published, you made 2 more, and the 3 consoles was working without problems so the patches are working
The only thing i can deduce from your post is the problem doesnt seems to be the new RSX, but i dont have anything to suggest
Other than... if everything else in the motehrboard looks fine, you still need to keep in mind that some copper traces could have been broken in internal layers of the motherboard, this is imposible to identify visually

 

[alty75]

@ Sandungas
Deadend made a frankie 65nm the first day the patches was published, you made 2 more, and the 3 consoles was working without problems so the patches are working
The only thing i can deduce from your post is the problem doesnt seems to be the new RSX, but i dont have anything to suggest
Other than... if everything else in the motehrboard looks fine, you still need to keep in mind that some copper traces could have been broken in internal layers of the motherboard, this is imposible to identify visually[/QUOTE]

Yeah from my experience reballing PS3's over the last 12 odd years that the RSX nor the layers of the board are not the problem, I've never had a PS3 board delam or the like from rework and is always another repairable issue. Something is missing possibly or I do happen to have 2 x RSX that just happen to have the GLOD,In which is quite possible.
The only way to diagnose that is to replace the RSX one more time and if the GLOD is still there then it's an issue board wise ,but again,I highly doubt it's a traces or layers issue, more likely a missing pad or component.
I've had many troubleshooting issues over the years fo rther GLOD and they are always repairable, the fact I am utilising a franky mod makes me thinkk twice.
another way to tell where the issue lies is to convert it back to a 90nm and see what happens