PS3 Fault finding YLOD with the SYSCON - First steps and Error reporting

[db260179]

Ok guys, to clear up on the offsets - the table is the SC EEPROM offset not the actual offset to write to - the table (physical offset) is what you write to. Be aware not all offsets can be written too as sony had patched some not to be able to write to, there is a way to clear that, but thats for another day.

So look carefully at the sc eeprom table:

0x48C11

1

bootrom trace level (0x00: fatal errors, 0x01: errors, 0x02: information messages, 0x03: debug messages)

Further down that page to find the physical offset to write to

SC EEPROM Offset	Block ID	Block Offset	Description	Physical Offset
0x48000 - 0x480FF	0x00	0x48000 - 0x480FF	?	0x7000
0x48800 - 0x488FF	0x01	0x48800 - 0x488FF	Hypervisor Area	0x7100
0x48C00 - 0x48CFF	0x02	0x48C00 - 0x48CFF	Contains flags and tokens/ see above	0x7200
0x48D00 - 0x48DFF	0x03	0x48D00 - 0x48DFF	System Data Region	0x7300
0x2F00 - 0x2FFF	0x10	0x2F00 - 0x2FFF	"Industry Area" aka OS Version Area	0x2F00
0x3000 - 0x30FF	0x20	0x3000 - 0x30FF	"Customer Service Area"	0x3000
N/A	0xFF	N/A	? sys_boot_gos flag is there	No SC EEPROM activity
All other offsets	Invalid	Invalid	?

So 0x48c11 is the flags and tokens area and is physical located at 0x7211 this only applies to COK-001-002 boards as from SEM-001 boards and later the physical address changed to 0x42**

So do a 'r 7211 ff' to see what is set
Then set accordingly - 'w 7211 03' for debug messages - BE careful as debug could slow your syscon down to a crawl!

Hope this helps?

 

[db260179]

Ok, cool will add to the list

Your pushing down is a clear example of poor BGA connection - reflow is required im afraid or a reball.

Good News, more 2 solutions error:

1001 - BE VRAM Power Fail. It can be NEC Tokins
1002 - RSX VRAM Power Fail. It can be NEC Tokins

I had 3 PS3 with this errors, one with errors 1001 and 1002 and two with error 1002 only.

I made this set on all 3 PS3 and after this no more errors:

On the second PS3 I fixed error 1002, then tested it with The Last of Us and
after 20 minutes, approximately, a Ylod occurs(this unit has been working for over on hour with Gran Turismo HD, in silence). I put the UART and saw the 1001 error, closed the unit without repairing the error 1001, turned on and gets Ylod immediately, re-opened, accessed the SYSCON and errors 2102 and 3034 appear. I fixed the error 1001 but is still in Ylod. Unfortunately these 2 errors are alternated. Example: Error 2102 occurs once and 3034 occurs the other time and so on.

I have 3 PS3 with 3034 error, two of them the Ylod disappears if I press the card. Of the 2, in one there was no Ylod ocorrence after the pressure and the other (which has errors 1001 and 1002) the Ylod returns after undoing the pressure. In both devices, pressure was applied at the same point:

 

[Goopsie]

I tend to have issues with Auth if that's not the very first command I run. You might want to try exiting it out, switching the ps3 off, then back on, run the script and then auth right away.

The current thinking with 3034 errors is BGA failure, we've had 2-3 test cases where they were fixed with either a reflow/reball, or by pushing on different spots on the back of the board until success. It'll definitely not be the same spot from board to board, though!

Error 4432 corresponds to BE or RSX error, so it's likely related to the issues on RSX with 3034.

I'll try hitting it with a heatgun, Could the reason Auth doesn't work be related to the fact i'm using a Particle Photon as my serial-usb bridge?

 

[marciolsf]

Ok guys, to clear up on the offsets - the table is the SC EEPROM offset not the actual offset to write to - the table (physical offset) is what you write to. Be aware not all offsets can be written too as sony had patched some not to be able to write to, there is a way to clear that, but thats for another day.

So look carefully at the sc eeprom table:

0x48C11

1

bootrom trace level (0x00: fatal errors, 0x01: errors, 0x02: information messages, 0x03: debug messages)

Further down that page to find the physical offset to write to

SC EEPROM Offset	Block ID	Block Offset	Description	Physical Offset
0x48000 - 0x480FF	0x00	0x48000 - 0x480FF	?	0x7000
0x48800 - 0x488FF	0x01	0x48800 - 0x488FF	Hypervisor Area	0x7100
0x48C00 - 0x48CFF	0x02	0x48C00 - 0x48CFF	Contains flags and tokens/ see above	0x7200
0x48D00 - 0x48DFF	0x03	0x48D00 - 0x48DFF	System Data Region	0x7300
0x2F00 - 0x2FFF	0x10	0x2F00 - 0x2FFF	"Industry Area" aka OS Version Area	0x2F00
0x3000 - 0x30FF	0x20	0x3000 - 0x30FF	"Customer Service Area"	0x3000
N/A	0xFF	N/A	? sys_boot_gos flag is there	No SC EEPROM activity
All other offsets	Invalid	Invalid	?

So 0x48c11 is the flags and tokens area and is physical located at 0x7211 this only applies to COK-001-002 boards as from SEM-001 boards and later the physical address changed to 0x42**

So do a 'r 7211 ff' to see what is set
Then set accordingly - 'w 7211 03' for debug messages - BE careful as debug could slow your syscon down to a crawl!

Hope this helps?

It does! thanks a ton.

I've gone ahead and updated the flag! Unfortunately, though, bring up doesn't really display anything new. I've confirmed the flag is still there, and that it persisted post a hardware reboot, but no new message.

I did get a print from trace last night, and one from this morning, i'm going to compare the two and see if there's anything new there.

 

[marciolsf]

wow, a lot has happened. I can't keep up with you.
Are you writing about "bootrom trace level (0x00: fatal errors, 0x01: errors, 0x02: information messages, 0x03: debug messages)"?
What does changing the 48c11 bit to 02 or 03 give us?

Additional question. Is UART the right way to read the Blueray driver ID and write other IDs to be able to swap readers?

That is supposed to give us more detailed error messages... or at least, more messages! Nothing so far, though.

 

[CodeKiller]

That is supposed to give us more detailed error messages... or at least, more messages! Nothing so far, though.

Unfortunately there is no more verbose text in retail SysCon. You can check in the dumps made by zecoxao.
As far as i can tell these [SSM].. [POWERSEQ]... messages are the most the fw willing to share.

 

[db260179]

I've noticed using python3 the auth is breaking the script, so for now use python2.

As long as you lead is ttl 3.3v uart lead you will be fine.

I'll try hitting it with a heatgun, Could the reason Auth doesn't work be related to the fact i'm using a Particle Photon as my serial-usb bridge?

 

[marciolsf]

Looking through some old notes, I had tested the following conditions, and got the following syscon errors

Tokins on the Cell side without a bridge wire - 3003 (power fail)
Tokins on the RSX side without a bridge wire - 3004 (power fail)

I find this interesting because @LSL was getting 1001 and 1002 errors (BE VRAM Power Fail and RSX VRAM power fail, respectively), until he built his new bridge/tantalums component, and then he got a successful boot. All the tokins are in parallel, so by removing the bridge i created an open line in the positive line and interrupted the supply line, thus "power fail".

Is it fair to say, then, that 1001/2 errors are indicators of power issues to specific components (VRAM, in this case), and 3003/4 are power failure to the chip as a whole? I'm sure there's a better way to say that...

 

[marciolsf]

Sorry for quality.
NEC RSX 4,2ohm 4,1ohm (left and right site)
NEC CELL 2,8ohm (left and right site)
bottom right 14,2ohm
top right 13,1ohm
top left 13,1ohm
bottom left - twice 82,3/82,6ohm - its interesting.

I'm writing a comparison table, and I'm have a bit of trouble reading this -- the two caps on the bottom left, are they 62.6 and 62.3, or are they 82.6 and 82.3?

EDIT: just saw that you wrote them above... sorry, too early in the day

 

[db260179]

It looks like its broken down into states and in catergories

Catergory 1 = System errors - covering all areas
Catergory 2 = Fatal errors - covering all areas
Catergory 3 = Fatal errors on bootup
Catergory 4 = Data errors

So i would translate the following errors as follows:

3 (boot up fatal error) 0 0 (CELL (3) power failure)
Judging by the errors coming out i would map the last number as the area or zone that is faulty i.e.

0 general power area failure
1 CELL or RSX power areas
2 Southbridge
3 CELL
4 RSX

I could be wrong, it could be a mix or related zones? only sony could confirm?

Looking through some old notes, I had tested the following conditions, and got the following syscon errors

Tokins on the Cell side without a bridge wire - 3003 (power fail)
Tokins on the RSX side without a bridge wire - 3004 (power fail)

I find this interesting because @LSL was getting 1001 and 1002 errors (BE VRAM Power Fail and RSX VRAM power fail, respectively), until he built his new bridge/tantalums component, and then he got a successful boot. All the tokins are in parallel, so by removing the bridge i created an open line in the positive line and interrupted the supply line, thus "power fail".

Is it fair to say, then, that 1001/2 errors are indicators of power issues to specific components (VRAM, in this case), and 3003/4 are power failure to the chip as a whole? I'm sure there's a better way to say that...

 

[db260179]

Looks like 62

I'm writing a comparison table, and I'm have a bit of trouble reading this -- the two caps on the bottom left, are they 62.6 and 62.3, or are they 82.6 and 82.3?

EDIT: just saw that you wrote them above... sorry, too early in the day

 

[db260179]

It could be my adjustments, try using python 2, i've noticed python3 is not outputting the ascii properly

Can't run "AUTH"; "Auth1 response invalid" Print statements show that the "checksum" variable doesn't match, Can't get it to work with python 3.8, I've gotten one error "A0404432" and many error "A0403034"
CECHE-01
View attachment 26574
Where do i go from here? Previously i got this ps3 working again by hitting it with a hot air gun, lasted a couple of months

 

[Goopsie]

It could be my adjustments, try using python 2, i've noticed python3 is not outputting the ascii properly

I've tried python 3.8, Python 2.7, I can't get AUTH to run no matter what i do. Tried exiting the script, turning ps3 on and off (with the back switch), running the script and immediately running auth on both versions of python, always the same thing. I've also gotten a few checksum errors running ERRLOG, if that helps

 

[aminiani]

Hi..please upload some video or photo for training..
how can i start?
what we need?
thanks

 

[sandungas]

Btw, have you took a look at the LED error codes ? ---> https://www.psdevwiki.com/ps3/Boot_modes#LED_Diag_Mode

To activate it you have to do a fan test and wait until after the ps3 powers off...
Then you have to press eject and then power rapidly many times in succession also try holding eject and pressing power...
Once you enter this mode the power light will flash yellow for about 1 second then the status of 4 component's...
The power light blinking 4 times for each 4 component's

We know how to trigger the LED error codes, but we dont know what means the output
It could be CELL, RSX, SB, VREG

 

[db260179]

Ok python2 will be ok, dont try python 3 for now its broke for this script - needs fixing.

What motherboard are you trying this on?
Can you send a picture of your serial wiring
What OS are you using to run the script?
Make sure your python2 install has python-serial and python-crypto is installed otherwise the auth part wont work. especially the crypto module is needed.
Good Grounding is needed otherwise problems occur.

Remember COK-001 - 002, SEM-001 and DIA-001 - 002 boards are tested and working, other boards are unknown.

Make sure to have the latest version from - https://github.com/db260179/ps3syscon

Make sure to follow the guide fully!

There are two modes - External commands and Internal commands
Internal commands only work once the diag mode has been set from external command mode.

Don't ground the diag pin until you have set the internal mode first!.

I've tried python 3.8, Python 2.7, I can't get AUTH to run no matter what i do. Tried exiting the script, turning ps3 on and off (with the back switch), running the script and immediately running auth on both versions of python, always the same thing. I've also gotten a few checksum errors running ERRLOG, if that helps

 

[db260179]

Go to https://github.com/db260179/ps3syscon
Read the guide - i'll upload a pdf format for easier viewing

Hi..please upload some video or photo for training..
how can i start?
what we need?
thanks

 

[inazuma-akai]

Looks like 62

bottom left - twice 82,3/82,6ohm - its interesting.
I'll check it out tomorrow with a test to be sure

 

[Goopsie]

Ok python2 will be ok, dont try python 3 for now its broke for this script - needs fixing.

What motherboard are you trying this on?
Can you send a picture of your serial wiring
What OS are you using to run the script?
Make sure your python2 install has python-serial and python-crypto is installed otherwise the auth part wont work. especially the crypto module is needed.
Good Grounding is needed otherwise problems occur.

Remember COK-001 - 002, SEM-001 and DIA-001 - 002 boards are tested and working, other boards are unknown.

Make sure to have the latest version from - https://github.com/db260179/ps3syscon

Make sure to follow the guide fully!

There are two modes - External commands and Internal commands
Internal commands only work once the diag mode has been set from external command mode.

Don't ground the diag pin until you have set the internal mode first!.

COK-002
Pictures: https://imgur.com/a/VeFZFOH
Windows 10, I've tried Kali linux also.
I've installed pyserial and pycrypto, as "python-serial" and "python-crypto" aren't found by pip
Hitting my ps3's RSX with a heat gun fixed my YLOD

 

[LSL]

Is it fair to say, then, that 1001/2 errors are indicators of power issues to specific components (VRAM, in this case), and 3003/4 are power failure to the chip as a whole? I'm sure there's a better way to say that...

3003/3004 is a error on VRAM sector, but NECs causes this error too