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

[sandungas]

Hey everyone, I'm trying to get the ERRLOG data out of a PS3, but it doesn't seem to be working for some reason... This is a VER-001, with a SW-301 SYSCON. I have it all connected, and auth/AUTH works just fine. I can use the commands bringup and shutdown, but becount doesn't seem to be recognized, and after using bestat, I get this:

# [SSM] PS3 ok.
# [SSM] PS4 ok.
# (PowerOn State)
#!
#!Boot Loader SE Version 2.4.5
#!(Build ID: 3163,33519,
#!Build Data: 2008-07-14_20:31:16)
#!
#!Copyright(C) 2007 Sony Computer Entertainment Inc.All Rights Reserved.
#!
#![ERROR]: 0xb0000004 lv0 authentication fail
# [SSM] Cond/Fatal received, msg=2649.
# [SSM] Fataldown Start.
# [SSM] Fataldown ok.
# (PowerOff State) (Fatal)
# (Error State) (Fatal)
# State = 07

Not sure if this is normal, but more importantly, my errlog/ERRLOG commands return nothing but FFFFFFFF. Is it blank? I'm not entirely sure where to go from here... I was trying to read the SYSCON logs before replacing the caps, because it seems like my problem is something else... Any help would be appreciated!

The command bestat displays info about CELL processor, i dont know what the info means, but it seems is working fine
The command becount was removed in sherwood syscons, and i dont know if there is a replacement command for it with a different name, but i can tell you that counters still exists inside syscon EEPROM, if you are really interested in it you can read the data in "raw" and do the conversion in PC, there are some samples about how the data is organized here:
https://www.psdevwiki.com/ps3/Talk:SC_EEPROM#BE_Count_region

You can read them by reading 8 bytes at offset 0x800 in sherwoods:

>r 800 8

In the first example in wiki (CokR40, REX-001emmc, SW3-304), you need to convert them from hexadecimal to decimal:
First 2 bytes = 05 B6 = 1462 bringups
Next 2 bytes = 05 23 = 1315 shutdowns
Next 4 bytes = 00 3D AD FA = 4042234 seconds


EDIT:
----------------
And btw, you can read the errolog in raw too, at offset 0x900 in sherwod syscons, the errors are cummulated "from top to bottom" so try to read a chunk of bytes (lets say... 0x40 bytes) from beginning of the errorlog area and if you see is filled with FF then yeah.. your errorlog is empty

>r 900 40

 

[Saaif88]

So I can indeed read offset 0x800 just fine, but unfortunately offset 0x900 is indeed filled with nothing but FF. I'm not entirely sure why this is the case, but I don't really know where else to go at this point.

I'm under the assumption that the CMOS battery has something to do with this, but even hooking up the battery terminals to a bench power supply and giving it 3V, it doesn't seem to affect anything. It seems that no matter what I do, the errlog never gets populated.

Thanks for the help though sandungas, I appreciate it!

 

[sandungas]

So I can indeed read offset 0x800 just fine, but unfortunately offset 0x900 is indeed filled with nothing but FF. I'm not entirely sure why this is the case, but I don't really know where else to go at this point.

I'm under the assumption that the CMOS battery has something to do with this, but even hooking up the battery terminals to a bench power supply and giving it 3V, it doesn't seem to affect anything. It seems that no matter what I do, the errlog never gets populated.

Thanks for the help though sandungas, I appreciate it!

Your errorlog is empty, either because you emptyed with the command "clearerrlog" or because the console never had an error
I guess there must be some setting to disable error logging... i was wondering if your PS3 have the error logging disabled (either from factory or because you disabled it by mistake by writing at random offsets), but i was taking a look at the info in wiki and is not mentioned anywhere so dunno
Are you sure your syscon is a SW-301 ?, can you run the commands "revision" and "version" to check it ?

Btw, you can add an error code manually writing in raw to the errorlog area:

>w 900 1A C0 CA C0

After that you can run the "errlog" command to see if is displayed normally, it should tell "C0CAC01A"

 

[TheAzther]

Hello guys! I wanted to ask if I can read the SYSCON errors using a MAX232 with a resistor divider to lower the voltage from 5V to 3.3V instead of using a FT232, is that possible?

 

[lugh22]

Hello everyone,
I recently got an YLOD CECHA01, for parts to fix another A01 with PS2 playback issues, and decided to look at the SYSCON codes, it's full of 3034's and 4322's wich indicates an RSX BGA issue, I was not planning to fix this unit, reballing prices here are quite expensive, and I don't want to invest much money into this unit so I was thinking about trying to reflow the RSX, I know it's not a permanent fix and the YLOD will probably happen again, but since I will only use it for PS2 games maybe the RSX will not be stressed that much.
I never did a reflow before, I have a smd rework station, so what temperature should I use? And for how long? Should I remove the IHS?
Any other advice are welcome .

 

[N3Star]

Hello,
My second try at creating a COK-002 frankestein (1st was a success, but with 65nm, this time I tried 40nm) failed, but I'm wondering what went wrong here.
bringup
[SSM] state: 0000 -> 0101
Bringup Mode #0 (0xFF)
[SSM] ssmCb_OnStartingBePowOn() called.
[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 BE:RRAC:RX0:GLOBAL1:RX_STATUS
[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]: 0xa0404401
[ERROR]: 0xa0403034
[POWSEQ] PowerSeq_Letup called.
[SSM] state: 0700 -> 0600
(PowerOff State) (Fatal)
[mullion]$
>$

By error codes my RSX has some kind of bit training problem as 3034 shows up, but "BitTraining BE:RRAC:RX0:GLOBAL1:RX_STATUS" suggests a problem with BE-SB communication. So far I've tried reflowing RSX and CELL, but to no effect.

 

[squeept]

We dont have schematics of the RSX itself. So the SMDs on the topside of the interposer is unkown territory. It would be great if we could probe them Rsx to find which pad is in continuity, but that would take a long time.

What we need is an LGA socket dev/service board so we can test every pad at once. Its possable, but expensive.

Was looking for those test points you wanted and I saw this. First, is this still needed? I can tone this stuff out really quick with my little homemade tools.

Second, I've had my eyes on several companies that make test sockets for several years now. All of them are prohibitively expensive for the style and footprint needed. However, I recently got some spam e-mail from one of them and they have some newer "affordable" products coming out. I'll update if I ever find out how much it will cost. (The previous ones were several thousand dollars for a custom part).

 

[squeept]

@RIP-Felix okay, from the image you posted on page 119, here's an apparently absolutely fried RSX, let me know if I'm missing anything here before I put in real effort soon and I'll update my nice, readable worksheets to start keeping better track of things.

I'm finding my scrap pile may not be very useful for readings since I often literally toss them in to the bin when they hit my rework limit, so a lot of them have a bunch of missing little bits, so I may just need to start fresh and only supply new data from new boards.

Spoiler

 

[Saaif88]

Are you sure your syscon is a SW-301 ?, can you run the commands "revision" and "version" to check it ?

Yup, running "version" gives me 0.17.0 and running "revision" gives me 1629(065D).

Btw, you can add an error code manually writing in raw to the errorlog area:

>w 900 1A C0 CA C0

After that you can run the "errlog" command to see if is displayed normally, it should tell "C0CAC01A"

I did this, and it actually does write to the memory location, and I can read it manually, but it does not show up in the errlog/ERRLOG. That is still just filled with FFs. I wonder if it's because it needs a "Clock" associated with it.

Spoiler

Oh well, this is just a PS3 I found in the trash anyways, so no big deal, I just feel bad tossing it out again.

 

[mekmitasdigoat]

It looks okay.

Are you planing frankenstein reanimation?

Thanks for checking. My original plan was to swap this chip into my broken GLOD CECHA. However, the swap process is harder than what I thought so for now I'm going to delay this plan until I found someone who can swap it for me or I practice until I feel confident.

 

[mekmitasdigoat]

Hello guys, I'm coming back to report the tokin fix for my CECHA.

Instead of writing in a paragraph I think its easier for you guys to read if I put them into bullet points.

[Model]: CECHA
[Symptom]: YLOD. It was hard to turn on when the machine is cold. Try several times it may boot but it always crash when start any AAA type of game.
[Syscon]: Mixed of A0801002 (90%+) and A0801001(<10%)
[Fix]: I used piggyback method and soldered one 470uf tantalum cap to the backside NEC cap (of course RSX side lol).
[Status]: Now it boots perfectly fine even when the machine is cold. I used uncharted 3 as the stress test. Ran it over an hour and it works flawlessly.
[Note]: For this fix I only used soldering iron so I think this rules out some false positive case. (like the hot air temporarily fix the connection between the GPU die and the board)

Currently I have another YLOD CECHE which also shows A0801002 error. That machine always YLOD around 4s, and no matter how many times you try to boot it does not boot at all. Once I got time I will also try to piggyback some caps and see if it works.

 

[RIP-Felix]

Yike! There's ton of you all at once so I'll do this in the aggregate:

Hello guys! I wanted to ask if I can read the SYSCON errors using a MAX232 with a resistor divider to lower the voltage from 5V to 3.3V instead of using a FT232, is that possible?

Why not just spend $3 to get one that's selectable?

Hello,
My second try at creating a COK-002 frankestein (1st was a success, but with 65nm, this time I tried 40nm) failed, but I'm wondering what went wrong here.
bringup
[SSM] state: 0000 -> 0101
Bringup Mode #0 (0xFF)
[SSM] ssmCb_OnStartingBePowOn() called.
[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 BE:RRAC:RX0:GLOBAL1:RX_STATUS
[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]: 0xa0404401
[ERROR]: 0xa0403034
[POWSEQ] PowerSeq_Letup called.
[SSM] state: 0700 -> 0600
(PowerOff State) (Fatal)
[mullion]$
>$

By error codes my RSX has some kind of bit training problem as 3034 shows up, but "BitTraining BE:RRAC:RX0:GLOBAL1:RX_STATUS" suggests a problem with BE-SB communication. So far I've tried reflowing RSX and CELL, but to no effect.

Reball failed.

I had a similar error on my last frankie attempt. The first 40nm gave a similar BE bittTraining error. I reflowed CPU to no effect (except lowering VDDC ohms from 2 to 1.5, inching it closer to death). Then I reflowed the RSX again, which caused bridged balls. So I had to attempt a reball, which failed. I managed to kill that 40nm in the process. So I had to use another one 40nm. That worked...so far.

These are not easy!

Was looking for those test points you wanted and I saw this. First, is this still needed? I can tone this stuff out really quick with my little homemade tools.

Second, I've had my eyes on several companies that make test sockets for several years now. All of them are prohibitively expensive for the style and footprint needed. However, I recently got some spam e-mail from one of them and they have some newer "affordable" products coming out. I'll update if I ever find out how much it will cost. (The previous ones were several thousand dollars for a custom part).

@vyktormvmpay25 is working on an adapter board too. I'm not sure exactly what he has in mind with it tho. But he seems motivated.

@RIP-Felix okay, from the image you posted on page 119, here's an apparently absolutely fried RSX, let me know if I'm missing anything here before I put in real effort soon and I'll update my nice, readable worksheets to start keeping better track of things.

I'm finding my scrap pile may not be very useful for readings since I often literally toss them in to the bin when they hit my rework limit, so a lot of them have a bunch of missing little bits, so I may just need to start fresh and only supply new data from new boards.

Spoiler

You forgot MC2_VDDIO and BE_PLL. Otherwise, those look ball park to what I've been measuring. But I need to start recording these somewhere.

Hello guys, I'm coming back to report the tokin fix for my CECHA.

Instead of writing in a paragraph I think its easier for you guys to read if I put them into bullet points.

[Model]: CECHA
[Symptom]: YLOD. It was hard to turn on when the machine is cold. Try several times it may boot but it always crash when start any AAA type of game.
[Syscon]: Mixed of A0801002 (90%+) and A0801001(<10%)
[Fix]: I used piggyback method and soldered one 470uf tantalum cap to the backside NEC cap (of course RSX side lol).
[Status]: Now it boots perfectly fine even when the machine is cold. I used uncharted 3 as the stress test. Ran it over an hour and it works flawlessly.
[Note]: For this fix I only used soldering iron so I think this rules out some false positive case. (like the hot air temporarily fix the connection between the GPU die and the board)

Currently I have another YLOD CECHE which also shows A0801002 error. That machine always YLOD around 4s, and no matter how many times you try to boot it does not boot at all. Once I got time I will also try to piggyback some caps and see if it works.

We're not particularly concerned with BGA false positives when you have already dumped the SYSCON errorlog and diagnosed the issue. If you had a 3034 and then tried tokins and claimed it worked, then we would be expecting it to fail. But since you confirmed the 1002/1001's and console behaviore associated with tokins, you made the correct diagnosis and repair. All is Kosher!

 

[sandungas]

Yup, running "version" gives me 0.17.0 and running "revision" gives me 1629(065D).

Ok, so is a standard SW-301

I did this, and it actually does write to the memory location, and I can read it manually, but it does not show up in the errlog/ERRLOG. That is still just filled with FFs. I wonder if it's because it needs a "Clock" associated with it.

Spoiler

Oh well, this is just a PS3 I found in the trash anyways, so no big deal, I just feel bad tossing it out again.

Well, the goal of this weird experiment was to see if the command "errlog" was displaying the error code C0CAC01A normally, just as a confirmation that everything is working normally, but i dont know why is not displayed, maybe is because the C0CAC01A is a bit weird because doesnt follows the standards of the error codes identifyers
The clock associated with each errorcode doesnt matters, is completly normal to have the clock times filled with FFFFFFFF if you boot the PS3 without the battery cell and is triggered an error
The syscon have an internal timer that depends of the presence of the battery (it starts counting from a date around year 2005), without the battery there is no date

Anyway, what you can do now is to use the command "clearerrlog" to revert the changes, this is going to fill the errorlog area with FF

Spoiler

Or you could do it manually by writing:

>w 900 FF FF FF FF

Btw, what kind of problem have that PS3 ?, im reading your posts but you never mentioned it

 

[N3Star]

Reball failed.

I had a similar error on my last frankie attempt. The first 40nm gave a similar BE bittTraining error. I reflowed CPU to no effect (except lowering VDDC ohms from 2 to 1.5, inching it closer to death). Then I reflowed the RSX again, which caused bridged balls. So I had to attempt a reball, which failed. I managed to kill that 40nm in the process. So I had to use another one 40nm. That worked...so far.

I already have reflown it 2 times, well to be honest first time I soldered it I slightly knocked it while the solder was still melted and it shifted. One hour of way too excessive cursing on my clumsiness later I have reballed it and then reflown it again (reflow was after 3034).
Now that I think of it I did the 65nm with slightly smaller thermocouple, that was able to go under the substrate; the one I have now cannot do that, at least with lead-free solder. I probably have reworked it with new one being under the RX/TX pins - my TC needs to be on the back left side, closer to CELL, that might have messed things up. Pads on that mobo are probably begging me to stop reworking it, but I have to try again, at least BE is still at ~3ohms.

Also, kind of a off-top question, but do You guys rework RSX with IHS still on top of it? I tried delidding 40nm GPU when it was already delsoldered and I had to leave it on, because I couldn't even stick anything between RAMs and IHS. Even after soldering it delid was an absolute nightmare compared to 65/90nm RSXs.

 

[Argonn]

Hi Guys,
I'm reporting this error on a CECHA PS3 (1 second YLOD)

 

[RIP-Felix]

Hi Guys,
I'm reporting this error on a CECHA PS3 (1 second YLOD)

Step 31 is when SYSCON confirms Redwood voltage reference, Clock Generator (IC5004), and CPU PLL (IC5003) are good. Differential Signal Power sequencing for BE_RC_REFCLK is needed for timing the FlexIO interface before proceeding to Bit Training. User @Bbowes had error 31 3031 on a console that shorted RSX:TX1 to ground. It shorted the entire FlexIO reference voltage (+1.2V_YC_RC_VDDIO), preventing checks at this step. He also had 31 3032 by accidentally knocking R5167 off, which disrupted the True side of Differential reference clock pair output (IC5004 Pin 24, BE_RC_REFCLK_P). I guess that the Complementary side of Differential reference clock pair output (IC5004 Pin 23, BE_RC_REFCLK_N), who's external resistor network can be disrupted by knocking off R5170, would generate error 31 3033. But that should be tested to confirm.

You're just going to have to start trouble shooting and voltage testing. These might help.

BTW: You're the first to have reported that 32 3033 error. Could you please also post the bringup?

 

[Argonn]

Step 31 is when SYSCON confirms Redwood voltage reference, Clock Generator (IC5004), and CPU PLL (IC5003) are good. Differential Signal Power sequencing for BE_RC_REFCLK is needed for timing the FlexIO interface before proceeding to Bit Training. User @Bbowes had error 31 3031 on a console that shorted RSX:TX1 to ground. It shorted the entire FlexIO reference voltage (+1.2V_YC_RC_VDDIO), preventing checks at this step. He also had 31 3032 by accidentally knocking R5167 off, which disrupted the True side of Differential reference clock pair output (IC5004 Pin 24, BE_RC_REFCLK_P). I guess that the Complementary side of Differential reference clock pair output (IC5004 Pin 23, BE_RC_REFCLK_N), who's external resistor network can be disrupted by knocking off R5170, would generate error 31 3033. But that should be tested to confirm.

You're just going to have to start trouble shooting and voltage testing. These might help.

BTW: You're the first to have reported that 32 3033 error. Could you please also post the bringup?

Here's the Bringup , Errlog and Becount.

> AUTH
Auth successful
>
[mullion]$
> becount
becount
Bringup : 694 times
Shutdown: 678 times
Power-on: 26day 20hour 22min 25sec
[mullion]$

> 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 -> 0303
[SSM] PowSeq Fail : Detected !
[SSM] state: 0303 -> 0700
[POWSEQ] AV Backend Letup
[SSM] Shutdown mode : syspm_stat=00000000/00000000
[ERROR]: 0xa0233020
> shutdown
[POWSEQ] PowerSeq_Letup called.
[SSM] state: 0700 -> 0600
(PowerOff State) (Fatal)
shutdown
[SSM] state: 0600 -> 0000
[SSM] Error state is cleared.
(PowerOff State)

> errlog
errlog
ofst[ 40]:err_code:0xffffffff, clock:0xffffffff
ofst[ 44]:err_code:0xa0323033, clock:0xffffffff
ofst[ 48]:err_code:0xa0323033, clock:0xffffffff
ofst[ 52]:err_code:0xa0323033, clock:0xffffffff
ofst[ 56]:err_code:0xa0323033, clock:0xffffffff
ofst[ 60]:err_code:0xa0323033, clock:0xffffffff
ofst[ 64]:err_code:0xa0323033, clock:0xffffffff
ofst[ 68]:err_code:0xa0323033, clock:0xffffffff
ofst[ 72]:err_code:0xa0323033, clock:0xffffffff
ofst[ 76]:err_code:0xa0323033, clock:0xffffffff
ofst[ 80]:err_code:0xa0323033, clock:0xffffffff
ofst[ 84]:err_code:0xa0323033, clock:0xffffffff
ofst[ 88]:err_code:0xa0323033, clock:0xffffffff
ofst[ 92]:err_code:0xa0323033, clock:0xffffffff
ofst[ 96]:err_code:0xa0323033, clock:0xffffffff
ofst[100]:err_code:0xa0323033, clock:0xffffffff
ofst[104]:err_code:0xa0323033, clock:0xffffffff
ofst[108]:err_code:0xa0323033, clock:0xffffffff
ofst[112]:err_code:0xa0323033, clock:0xffffffff
ofst[116]:err_code:0xa0323033, clock:0xffffffff
ofst[120]:err_code:0xa0323033, clock:0xffffffff
ofst[124]:err_code:0xa0323033, clock:0xffffffff
ofst[  0]:err_code:0xa0323033, clock:0xffffffff
ofst[  4]:err_code:0xa0323033, clock:0xffffffff
ofst[  8]:err_code:0xa0323033, clock:0xffffffff
ofst[ 12]:err_code:0xa0323033, clock:0xffffffff
ofst[ 16]:err_code:0xa0323033, clock:0xffffffff
ofst[ 20]:err_code:0xa0233020, clock:0xffffffff
ofst[ 24]:err_code:0xa0323033, clock:0xffffffff
ofst[ 28]:err_code:0xa0323033, clock:0xffffffff
ofst[ 32]:err_code:0xa0323033, clock:0xffffffff
ofst[ 36]:err_code:0xa0233020, clock:0xffffffff
[mullion]$
>

Sometimes, Error 0xa0233020 appears, with 0xa0323033

I have checked the MB and the CELL and I haven't noticed that before, but the CPU looks scratched. I guess the last owner has failed the delid, and glued the IHS... I can't even remove it. I guess that's why this PS3 doesn't turn on.

 

[Argonn]

Edit : Ok I found what's wrong with the PS3... I'm sad to see that:

RSX was glued too... No scratches

 

[Argonn]

Step 31 is when SYSCON confirms Redwood voltage reference, Clock Generator (IC5004), and CPU PLL (IC5003) are good. Differential Signal Power sequencing for BE_RC_REFCLK is needed for timing the FlexIO interface before proceeding to Bit Training. User @Bbowes had error 31 3031 on a console that shorted RSX:TX1 to ground. It shorted the entire FlexIO reference voltage (+1.2V_YC_RC_VDDIO), preventing checks at this step. He also had 31 3032 by accidentally knocking R5167 off, which disrupted the True side of Differential reference clock pair output (IC5004 Pin 24, BE_RC_REFCLK_P). I guess that the Complementary side of Differential reference clock pair output (IC5004 Pin 23, BE_RC_REFCLK_N), who's external resistor network can be disrupted by knocking off R5170, would generate error 31 3033. But that should be tested to confirm.

You're just going to have to start trouble shooting and voltage testing. These might help.

BTW: You're the first to have reported that 32 3033 error. Could you please also post the bringup?

Edit : Sorry, the last Bringup posted was about err 0xa0233020 (This error does not appear when I apply pressure on the MB close to the CELL, and I haven't seen this error before)

Here's the bringup for the err 0xa0323033

[mullion]$
> bringup
bringup
[SSM] state: 0000 -> 0101
Bringup Mode #0 (0xFF)
[SSM] ssmCb_OnStartingBePowOn() called.
[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
> shutdown
[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]: 0xa0323033
[POWSEQ] PowerSeq_Letup called.
[SSM] state: 0700 -> 0600
(PowerOff State) (Fatal)
shutdown
[SSM] state: 0600 -> 0000
[SSM] Error state is cleared.
(PowerOff State)
> errlog
errlog
ofst[  8]:err_code:0xffffffff, clock:0xffffffff
ofst[ 12]:err_code:0xffffffff, clock:0xffffffff
ofst[ 16]:err_code:0xffffffff, clock:0xffffffff
ofst[ 20]:err_code:0xffffffff, clock:0xffffffff
ofst[ 24]:err_code:0xffffffff, clock:0xffffffff
ofst[ 28]:err_code:0xffffffff, clock:0xffffffff
ofst[ 32]:err_code:0xffffffff, clock:0xffffffff
ofst[ 36]:err_code:0xffffffff, clock:0xffffffff
ofst[ 40]:err_code:0xffffffff, clock:0xffffffff
ofst[ 44]:err_code:0xffffffff, clock:0xffffffff
ofst[ 48]:err_code:0xffffffff, clock:0xffffffff
ofst[ 52]:err_code:0xffffffff, clock:0xffffffff
ofst[ 56]:err_code:0xffffffff, clock:0xffffffff
ofst[ 60]:err_code:0xffffffff, clock:0xffffffff
ofst[ 64]:err_code:0xffffffff, clock:0xffffffff
ofst[ 68]:err_code:0xffffffff, clock:0xffffffff
ofst[ 72]:err_code:0xffffffff, clock:0xffffffff
ofst[ 76]:err_code:0xffffffff, clock:0xffffffff
ofst[ 80]:err_code:0xffffffff, clock:0xffffffff
ofst[ 84]:err_code:0xffffffff, clock:0xffffffff
ofst[ 88]:err_code:0xffffffff, clock:0xffffffff
ofst[ 92]:err_code:0xffffffff, clock:0xffffffff
ofst[ 96]:err_code:0xffffffff, clock:0xffffffff
ofst[100]:err_code:0xffffffff, clock:0xffffffff
ofst[104]:err_code:0xffffffff, clock:0xffffffff
ofst[108]:err_code:0xffffffff, clock:0xffffffff
ofst[112]:err_code:0xffffffff, clock:0xffffffff
ofst[116]:err_code:0xffffffff, clock:0xffffffff
ofst[120]:err_code:0xffffffff, clock:0xffffffff
ofst[124]:err_code:0xffffffff, clock:0xffffffff
ofst[  0]:err_code:0xa0323033, clock:0xffffffff
ofst[  4]:err_code:0xa0323033, clock:0xffffffff
[mullion]$

 

[mekmitasdigoat]

Just fixed my ylod CECHE.

The symptom of this machine is a constant 4s YLOD. If I keep turning it on and off, sometimes it goes to ~1s YLOD. The syscon report looks like this:

Spoiler: syscon

Since I saw lots of the 1002 error, as usual I piggybacked 1 tantalum cap to the back RSX tokin. However nothing changed. I thought maybe one cap is not enough so I soldered another one. Still, nothing changed, I got mixed of 1s and 4s YLODs.

Clearly the 4s YLOD and the 1s YLOD are complaining the different things. To find the relation between these two types of YLOD and the error code, I clear the log after each run and keep recording. After multiple runs, I found that the 4s YLOD is corresponding to the 801002 code, and the 1s YLOD is corresponding to the 611001 code. (Also seems like if I plug the HDMI cable in, the 902120 is also generated together with 611001).

Since 611001 is related to the CPU power during the POST stage, I piggybacked one cap to the back CELL tokin. You know what, it boots! I still need some time to test the stability of this machine but for now at least it could boot no matter what. (compare to the past it never boots.)

PS: Sorry my writing is a mess. :P