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

Nascar1243 said:
Basically you can push on the backside of the clamps or on the chips themselves (recommend just the clamps) to see if you can get video from pressure, may take little pressure, may take more than you'd like, just don't go overkill on the pressure, this would determine if it is bga/bump
Click to expand...
By the back of the clamps do you mean the one where the screws are? Unfortunately, that part can only be accessed by removing the fan because it is located underneath. As a guide i found this https://www.psx-place.com/threads/guide-south-bridge-log-with-possible-glods-ylods-solutions.38920/ but the attached images can no longer be seen.
 
RIP-Felix said:
So IDK where u got the idea to solder to that 3.3v pad, but all you need to do is connect 2x wires to the outter most pads on the pci port. Like in the example image I posted before. Did that not work or something?

Victor's just saying you first have to enable the SB UART bit in SYSCON UART before switching over to the SB UART. And that the SB log wont start until the bootloader does. So the console needs to be able to get at least that far into the booting process or it wont start logging anything.

Please post a picture of how you hooked the wires up.
Click to expand...
Hi Felix. Have you by any chance made (or are you planning to make) a guide to access the SB to better understand the causes of a GLOD for example? It might be something that complements your syscon tutorial and is definitely something i would need in my case.
 
RIP-Felix said:
inspection-3-jpg.36289
Click to expand...
Wait, are you telling me that little piece of paper means the ps3 has already been reworked? Because i found the same piece of paper in the same position when i opened my PS3 which had the warranty seals on it.
 
Tomatarto said:
From previous posts it seems that a 1B01 error code relates to a short with the CELL-BE or a component directly related to it. Thus it wouldn't be too out there if we assumed that a 1B02 relates to a short with the RSX or a component directly related to it. The step number 11 could also suggest a short of the RSX thermal monitor. Maybe damage of a component around the RSX due to the attempted reflow?

3034 and 4xxx errors typically represent BGA failures but the step number would have me believe that this is not the issue especially when considering that you have a 65nm RSX. Does the board and specifically the area around the RSX have what appears to be pockets of air underneath its surface, what is known as popcorning? Did you preheat the board beforehand?
Click to expand...


Thank you for the answer.
I preheated the motherboard evenly for a few minutes, then I proceeded with the reflowing.

I honestly didn't notice any 'popcorning' or bulges on the motherboard, everything seems fine. I didn't found any short circuits... at this point I'm completely lost...
 
M4j0r said:
It only depends on the main firmware version, as long as you run anything higher than 0.90 it'll work.
0x00/0xFF means off; 0x01, 0x02, 0x03 are different levels (warning, info, debug). I typically set the first one to 0x03 and then the ones I'm interested in also to 0x03.
This will produce a lot of messages and is only really useful if you're doing research on special (late) error cases.
I used it e.g. to get an idea why prototype syscons can't be remarried or how the VSH Target works.
It'll allow you to get messages from the PME secure services, not from the main Hypervisor code (which does things like RSX init etc.), this would require CFW.
Click to expand...
Hi. Are you saying that to activate hypervisor from syscon you need a CWF?
 
TimeWalker75a said:
As mentioned, it doesn't get into recovery, so that option is out the window. Holding down the power button at any time just shuts the console off, regardless which power cycle it is, never seems to beep twice.
Click to expand...
In my case of GLOD beep twice, what does it mean?
 
M4j0r said:
No, every firmware works. But the secure services log is only needed for special case if the normal SB log isn't enough.
Click to expand...
I did everything as per the guide but for me after enabling the hypervisor codes in syscon, the sb log doesn't tell me anything different.
 
Last edited:
vyktormvmpay25 said:
Beep twice mean cpu is fine with all software side, rsx not working vrams. Simply special glod.
Click to expand...
So what you call a "special glod" is when you have a glod but no syscon/southbridge errors? How many have you seen in your experience and how many have you managed to repair and how did you do it?
 
Hello. I have a fat PS3 with about 100 days of use. It was all working fine until recently when I started having the jet engine fan speeds. I've read about the eraser mod and I tried it and the fan issue went mostly away until it recently started happening again after a few months of use. I added more pressure on the cpu this time but I believe I went a little too far and stressed the solder balls under the CPU.

I've had a 1601 and 1701 but that went away the moment I relieved the stress off the CPU. The console worked for 3 days and I also left it overnight running a game to see if it would YLOD but that never happened. I tried to boot it up today by turning the power switch on(I turn off the power switch when I am not using the console for an extended period of time) only to find out that it would immediately go to flashing red LED, 3 beeps and I never even touched the power button.

As far as I remember that's usually what happens when your CPU/GPU overheats and you try to power cycle the system but in this case it feels more of thermistor/IC problem or there's a problem with the CPU(I don't think it's the GPU but due to the 1601/1701 I can't completely rule it out even if I never got artifacting).

Sorry for the long post but if anyone has anything relevant I could read it would help a lot as all the results I am getting are in regards to YLOD so any helpful information for my case gets obscured or I am not that good at finding it in order to figure out where the problem lies. Sorry for the wall of text.

It's a FAT CECHL04 with the VER-001 board.
Below are the syscon error codes:
>$ ERRLOG
00000000
# CODE CLOCK
# A0801601 0C3B8006
# A0801701 0C3B8005
# A0802022 0B631FCB
# A0802022 0B631FB0
# A0802022 0B631C1B
# A0802022 0B631C08
# A0802131 127EFF91
# A0802131 127EFF8D
# A0222030 127EFF87
# A0802131 108FDA8F
# FFFFFFFF FFFFFFFF
# FFFFFFFF FFFFFFFF
# FFFFFFFF FFFFFFFF
# FFFFFFFF FFFFFFFF

PS: 2030 and 2131 are before I got my hands on this console. 2022 should be because I am using an old sony tv which doesn't like any of the PS3s I have so I either get a blank screen or it's constantly retrying the wrong resolutions.
 
CaptainJJ said:
Hello. I have a fat PS3 with about 100 days of use. It was all working fine until recently when I started having the jet engine fan speeds. I've read about the eraser mod and I tried it and the fan issue went mostly away until it recently started happening again after a few months of use. I added more pressure on the cpu this time but I believe I went a little too far and stressed the solder balls under the CPU.

I've had a 1601 and 1701 but that went away the moment I relieved the stress off the CPU. The console worked for 3 days and I also left it overnight running a game to see if it would YLOD but that never happened. I tried to boot it up today by turning the power switch on(I turn off the power switch when I am not using the console for an extended period of time) only to find out that it would immediately go to flashing red LED, 3 beeps and I never even touched the power button.

As far as I remember that's usually what happens when your CPU/GPU overheats and you try to power cycle the system but in this case it feels more of thermistor/IC problem or there's a problem with the CPU(I don't think it's the GPU but due to the 1601/1701 I can't completely rule it out even if I never got artifacting).

Sorry for the long post but if anyone has anything relevant I could read it would help a lot as all the results I am getting are in regards to YLOD so any helpful information for my case gets obscured or I am not that good at finding it in order to figure out where the problem lies. Sorry for the wall of text.

It's a FAT CECHL04 with the VER-001 board.
Below are the syscon error codes:
>$ ERRLOG
00000000
# CODE CLOCK
# A0801601 0C3B8006
# A0801701 0C3B8005
# A0802022 0B631FCB
# A0802022 0B631FB0
# A0802022 0B631C1B
# A0802022 0B631C08
# A0802131 127EFF91
# A0802131 127EFF8D
# A0222030 127EFF87
# A0802131 108FDA8F
# FFFFFFFF FFFFFFFF
# FFFFFFFF FFFFFFFF
# FFFFFFFF FFFFFFFF
# FFFFFFFF FFFFFFFF

PS: 2030 and 2131 are before I got my hands on this console. 2022 should be because I am using an old sony tv which doesn't like any of the PS3s I have so I either get a blank screen or it's constantly retrying the wrong resolutions.
Click to expand...
Its likely the CPUs BGA/Bumps are cooked. This would make sense as it worked overnight while running a game which would be due to the BGA/Bumps being temporarily connected due to thermal expansion.

Counterintuitively the lack of a 3034 does make that scenario a little less likely. I do not have any firsthand experience with the consequences of the eraser mod so that should be something that would be good to know.

As for the other codes i am not sure. The step number for the 2131 and 2030 is certainly strange.

Sorry to be "That guy" but the eraser mod is not a very good idea. It puts unnecessary strain near the RSX and the CELL which are components that are already under lots of pressure (especially in the CECHA to CECHE period of consoles which already have enough strain as it is)
 
Last edited:
Divano said:
Thank you for the answer.
I preheated the motherboard evenly for a few minutes, then I proceeded with the reflowing.

I honestly didn't notice any 'popcorning' or bulges on the motherboard, everything seems fine. I didn't found any short circuits... at this point I'm completely lost...
Click to expand...
A few minutes is not enough for water to escape the motherboard. That being said my hypothesis as to what happened is that the heat-gun was the final straw that damaged the BGA/Bumps beyond repair by causing them to finally crack.
 
M4j0r said:
I guess you wrote the values to the wrong address?
For your consoles the address for the syscon eeprom values should start with 0x72.., see https://www.psdevwiki.com/ps3/SC_EE..._and_Block_Offset_Mapping_Table_(NVS_Service) .
Click to expand...
In syscon i read "[mullion]$" at the end of messages, so i used the value "w 7202 02" and the success message appeared. After that i tried the sb again but as already said it's the same
Code: 
Boot Loader SE Version 4.9.0 (Build ID: 5370,50747, Build Date: 2022-12-12_15:06:40)
SDK Version: 490.000
Copyright(C) 2022 Sony Computer Entertainment Inc.All Rights Reserved.
[INFO]: === eXtreme Data Rate Memory Subsystem ===
[INFO]: (Configured Memory Size per single XIO channel: 128 MBytes.)
[INFO]: XIO channel[0] is available.
[INFO]: XIO channel[1] is available.
[INFO]: ---> Total 256 MBytes are now in use.
[INFO]: SPU enable [0, 1, 2, 5, 6, 7] 11101111
[INFO]: BE:3.1, SB:PX1.1
Cell OS SDK4.9.0 000 (release build: r50747 2022_12_12_130000)
Copyright 2022 Sony Computer Entertainment Inc.
revision: 50747
date:     Mon Dec 12 15:08:07 JST 2022
skip 2nd initialization step
lv2(0): total memory size: 249MB+640KB
lv2(0): kern memory size:   12MB+640KB (heap:3492KB  page pool:4736KB)
lv2(0): user memory size:  237MB
lv2(2):
lv2(2): Cell OS Lv-2 32 bit version 4.9.0
lv2(2): Copyright 2011 Sony Computer Entertainment Inc.
lv2(2): All Rights Reserved.
lv2(2):
lv2(2): revision: 50747
lv2(2): build date: 2022/12/12 15:11:54
lv2(2): processor: Broadband Engine  Ver 0x0000  Rev 0x0201
lv2(2): PPU:0, Thread:0 is enabled.
lv2(2): PPU:0, Thread:1 is enabled.
lv2(2): rsx:      b02 500/650 vpe:ff shd:3f  [4K0301701:1:3:f:7:5:4:f:1][39:2:1:1:1:3:1][0:0:0]
lv2(2): Available physical SPUs: 6/7
lv2(2): mounting the flash file system : OK
lv2(2): creating the initial system process : OK
lv2(2): entering stand-alone mode.
lv2(2): system software: PS3 console mode (game memsize=200MB)
lv2(2): creating the system software process : OK
lv2(2): sys_init: system software process set-up done.
lv2(2): initial system process done.
Code: 
Boot Loader SE Version 4.9.0 (Build ID: 5370,50747, Build Date: 2022-12-12_15:06:40)
SDK Version: 490.000
Copyright(C) 2022 Sony Computer Entertainment Inc.All Rights Reserved.
[INFO]: === eXtreme Data Rate Memory Subsystem ===
[INFO]: (Configured Memory Size per single XIO channel: 128 MBytes.)
[INFO]: XIO channel[0] is available.
[INFO]: XIO channel[1] is available.
[INFO]: ---> Total 256 MBytes are now in use.
[INFO]: SPU enable [0, 1, 2, 5, 6, 7] 11101111
[INFO]: BE:3.1, SB:PX1.1
Cell OS SDK4.9.0 000 (release build: r50747 2022_12_12_130000)
Copyright 2022 Sony Computer Entertainment Inc.
revision: 50747
date:     Mon Dec 12 15:08:07 JST 2022
skip 2nd initialization step
lv2(0): total memory size: 249MB+640KB
lv2(0): kern memory size:   12MB+640KB (heap:3492KB  page pool:4736KB)
lv2(0): user memory size:  237MB
lv2(2):
lv2(2): Cell OS Lv-2 32 bit version 4.9.0
lv2(2): Copyright 2011 Sony Computer Entertainment Inc.
lv2(2): All Rights Reserved.
lv2(2):
lv2(2): revision: 50747
lv2(2): build date: 2022/12/12 15:11:54
lv2(2): processor: Broadband Engine  Ver 0x0000  Rev 0x0201
lv2(2): PPU:0, Thread:0 is enabled.
lv2(2): PPU:0, Thread:1 is enabled.
lv2(2): rsx:      b02 500/650 vpe:ff shd:3f  [4K0301701:1:3:f:7:5:4:f:1][39:2:1:1:1:3:1][0:0:0]

lv2(2): Available physical SPUs: 6/7
lv2(2): mounting the flash file system : OK
lv2(2): creating the initial system process : OK
lv2(2): entering stand-alone mode.
lv2(2): system software: PS3 console mode (game memsize=200MB)
lv2(2): creating the system software process : OK
lv2(2): sys_init: system software process set-up done.
lv2(2): initial system process done.
I wonder, since i'm experimenting a special GLOD as @vyktormvmpay25 says, without any errors in the syscon and sbouthbridge logs, is it possible that the hypervisor could be blocked at the hardware level by some motherboard malfunction?
 
Nator said:
In syscon i read "[mullion]$" at the end of messages, so i used the value "w 7202 02" and the success message appeared. After that i tried the sb again but as already said it's the same

I wonder, since i'm experimenting a special GLOD as @vyktormvmpay25 says, without any errors in the syscon and sbouthbridge logs, is it possible that the hypervisor could be blocked at the hardware level by some motherboard malfunction?
Click to expand...

There's no "hypervisor" log, there's only the normal south bridge log and additionally logs from the PME and secure services, see 0x48CCF and 0x48CF0+ in this table: https://www.psdevwiki.com/ps3/SC_EEPROM#SC_EEPROM_Offset_Table_-_Flags_and_Tokens .
 
Tomatarto said:
Its likely the CPUs BGA/Bumps are cooked. This would make sense as it worked overnight while running a game which would be due to the BGA/Bumps being temporarily connected due to thermal expansion.

Counterintuitively the lack of a 3034 does make that scenario a little less likely. I do not have any firsthand experience with the consequences of the eraser mod so that should be something that would be good to know.

As for the other codes i am not sure. The step number for the 2131 and 2030 is certainly strange.

Sorry to be "That guy" but the eraser mod is not a very good idea. It puts unnecessary strain near the RSX and the CELL which are components that are already under lots of pressure (especially in the CECHA to CECHE period of consoles which already have enough strain as it is)
Click to expand...
I reported my post so that it would get removed before people spent the time to reply but it didn't happen; and I have no way to edit it. I figured out what the actual problem was though, I must've incorrectly wrote some of the fan settings in the NAND which after a complete power cycle caused the overheat behavior, so it was just me failing to realize that it was the reason it would not boot up.

As for the rest, time will tell and I will make sure to give an update when the PS3 YLODs. At least this is some useful info for anyone who might get the same problem that I just had. Thanks for your time :)
 
Nator said:
I saw the link you posted but i don't know how to interpret it. I only know that after activating the hypervisor i don't receive any further information from it, why? What's stopping it?
Click to expand...

I guess you activated the south bridge log output by executing:
Code: 
w 7202 02
which sets the network device mode to south bridge, see 0x48C02 in https://www.psdevwiki.com/ps3/SC_EEPROM#SC_EEPROM_Offset_Table_-_Flags_and_Tokens .

If you want additional info from the secure services, you need to activate the ss.common.printf.enabled and then a flag of the services you're interested in. I would advise setting both the common log level (0x48CF0) and the ss.common.debug.level+ss.update.debug.level (0x48CF1) to 0x03 - see also https://www.psdevwiki.com/ps3/SC_EEPROM#SC_EEPROM_Offset_Table_-_Flags_and_Tokens .
This translates to the following syscon commands (by using the translation table (https://www.psdevwiki.com/ps3/SC_EE..._and_Block_Offset_Mapping_Table_(NVS_Service)) :
Code: 
w 72F0 03
w 72F1 03

The pme_user debug printf flag (0x48CCF) might also be of help, to enable this output, execute:
Code: 
w 72CF 03

The default value for all of these flags is 0xFF.
 
M4j0r said:
I guess you activated the south bridge log output by executing:
Code: 
w 7202 02
which sets the network device mode to south bridge, see 0x48C02 in https://www.psdevwiki.com/ps3/SC_EEPROM#SC_EEPROM_Offset_Table_-_Flags_and_Tokens .

If you want additional info from the secure services, you need to activate the ss.common.printf.enabled and then a flag of the services you're interested in. I would advise setting both the common log level (0x48CF0) and the ss.common.debug.level+ss.update.debug.level (0x48CF1) to 0x03 - see also https://www.psdevwiki.com/ps3/SC_EEPROM#SC_EEPROM_Offset_Table_-_Flags_and_Tokens .
This translates to the following syscon commands (by using the translation table (https://www.psdevwiki.com/ps3/SC_EE..._and_Block_Offset_Mapping_Table_(NVS_Service)) :
Code: 
w 72F0 03
w 72F1 03

The pme_user debug printf flag (0x48CCF) might also be of help, to enable this output, execute:
Code: 
w 72CF 03

The default value for all of these flags is 0xFF.
Click to expand...
Ok now i understand better. For the old Mullion syscons, all commands are marked with the number 72, while the new Sherwoods sycons with the number 42.

So for Mullion is:

Activating SB log output:
Code: 
w 7202 02
Hypervisor message activation:
Code: 
w 72CF 03
w 72F0 03
w 72F1 03
Disabling Hypervisor Messages:
Code: 
w 72CF FF
w 72F0 FF
w 72F1 FF

For Sherwoods is:
Activating SB log output:
Code: 
w 4202 02
Enabling Hypervisor Messages:
Code: 
w 42CF 03
w 42F0 03
w 42F1 03
Disabling Hypervisor Messages:
Code: 
w 42CF FF
w 42F0 FF
w 42F1 FF
 
You must log in or register to reply here.

Similar threads

Back
Top