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

M4j0r said:
VDDR is for the Rambus core on all RSX/SB and 65nm or later CELL. The 90nm CELL uses (YC) VDDA for VDDR.
Click to expand...

I feel like my mind is rehashing the same mistaken logic in an endless loop of second guessing. It's been going on for 3 LOOOOOOONG days in a row. It's just complicated enough, that I cannot remember what/why one line of thinking is wrong, flip to another flawed understanding and change all my definitions, just to decide that was wrong and do it again...AAAAAHHHHHHH!!!!!!
:sfun bangdesk:
...

This is the story I came up with and It seems consistent to me. Again, Irreducibly complex...sorry. Pay attention to the abbreviations!

+1.2V_RSX_VDDR = RSX Redwood Rambus FlexIO Core
  • what does core mean? Is it the SPI voltage level? So the actual digital RX/TX signals lines will be at 1.2v?
+1.5V_BE_RC_VDDA = Redwood Rambus FlexIO Controller ADC Interface
+1.5V_RSX_RC_VDDA = Redwood Rambus FlexIO Controller ADC Interface
  • RC stands for Redwood Rambus Controller. And that A is referring to ADC interface - Analog-to-Digital Converter to interface Analog/Digital sources. This is needed because analog and digital signals are incompatible. Analog IO needs to be converted to digital, before it can be processed. I am under the impression that the FlexIO is only for digital signals traveling between SB/CPU/GPU processing cores (all digital sources). So these voltages are for the DAC inside of each processor that interfaces analog signals with the digital ones on the FlexIO.
+1.5V_RSX_VDDIO = VDDP_VO (Voltage for Picture, Video Out to DVE/HDMI)

+1.2V_YC_RC_VDDIO = Yellowstone/Redwood Controller IO
  • This is wehere the theory is challenged. Why is this different than +1.2V_RSX_VDDR? Different IC's power these! And +1.2V_YC_RC_VDDIO is important enought that SONY had plans to use a Themal monitor on Q6310. That suggests it pulls alot of cuurent and was suspected to get hot. If this voltage is for the FlexIO, then why are CPU/SB and RSX FlexIO's separtely powered and controlled? Assuming this is the FlexIO, my hypothesis is that it's so the CPU/SB can be initialized over the FlexIO in a separate step than the RSX. This is supported by the Power On Sequence.
  • If that's all well and good, what's with the YC_RC abbreviations then? Why doesn't it say BE_SB_VDDIO? They're specifically abbreviating YC_RC, drawing our attention to the XIO/FlexIO Controllers. Why? Well, the null hypothesis is that my abbreviations are wrong and this entire theory is wrong. This is what has me confused.
 
Last edited:
feng_ye said:
Hi, I'm in the middle of fixing another COK-002. When it turns on a YLOD almost instantly shut it down, giving a 3001 error. Swapping PSU makes no difference. Checked all the fuses and tried my best to find shorts, no results. IC6003 does get 12V but it doesn't regulate the voltage so there's no 5V_MISC nor 3.3V_MISC at all, no SW_0 signal from SYSCON either. So finally make me think IC6023 which might be broken. From probing, it always outputs 0V(should stay high as it has a pull-up resistor) which probably the reason forces SYSCON to shutdown the console and not even bother to turn on SW_0 (IC6003).

Question is, where can I get a replacement for IC6003? It's a MITSUMI PST3642UL according to the service manual. I have some donor boards like DIA001 and DIA002 and DYN001. I'm wondering if I can get any same spec chip off them. Thanks!
Click to expand...
Nevermind, I did find one with same form factor and marking on a DIA002. Replaced and it seems working now(1200 error without fan)! Will post details later if it actually revived this BC model.
 
feng_ye said:
Nevermind, I did find one with same form factor and marking on a DIA002. Replaced and it seems working now(1200 error without fan)! Will post details later if it actually revived this BC model.
Click to expand...

Good job. I agree with your analysis. Looks like IC6023 is an IC for CMOS reset (generates /POW_FAIL signal that triggers Error00 3001). So yes. 1 of 2 things can be happening. Either the PSU is bad and not outputting 12V_MAIN. Or IC6023 is bad. Now this is the interesting part...

12V_MAIN --> Voltage Divider --> VCC Pin 1 (IC6023)
  • If Voltage is present --> Out Pin 4 (IC6023) --> /POW_FAIL = High (Tells SYSCON 12V_MAIN is good to go)
  • If Voltage is Absent --> Out Pin 4 (IC6023) --> /POW_FAIL = Low, but not 0V because of Pull up resistor (Tells SYSCON 12V_MAIN is Bad).
  • If Voltage is present --> IC6023 is Cooked --> /POW_FAIL = 0V (Tells SYSCON 12V_MAIN is Bad, but tells us IC6023 is bad. And perhaps the voltage divider network around it).
 
RIP-Felix said:
Was that a 00 3001? That's what I expect, but want to confirm.
Click to expand...
Yes, 00 stage at very beginning.

To my sadness replacing IC6023 solves 3001 power fail error, but then it became a GLOD and shuts down itself with 1701 and 14ff errors at 80 stage after about 1min. Then subsequent bringup generated 2110 errors.
 
feng_ye said:
Yes, 00 stage at very beginning.

To my sadness replacing IC6023 solves 3001 power fail error, but then it became a GLOD and shuts down itself with 1701 and 14ff errors at 80 stage after about 1min. Then subsequent bringup generated 2110 errors.
Click to expand...
I have a vague lead based on supposition and hunch.

On page 2/24 in the schematic there is a signal tree of +1.2V_MC2_VDDIO with a reference to the "P_L_BYPASS." My mind went to the PLL, which makes me think clock.

IC6012 (JL6063) --> +1.2V_MC2_VDDIO = BE_SPI, CHKSTP, JTAG, TBEN, & P_L_BYPASS
It gets powered by (IC6003/Q6601) --> 3.3V_MISC, so that needs to be present (which it should be, because the errors occurred at step #80 = Power On state. The Power On Sequence had completed successfully without error and +3.3V_MISC is one of the first checks). I thought I'd just mention it for the sake of completeness.

On page 18/24, IC5004 produces/monitors the reference clocks for the SB/CPU/RSX FlexIO Core (+1.2V_RC_VDDIO).

That's where the evidence dries up and previouse experiance comes in. @vyktormvmpay25 has said these errors tend to be and issue with the CPU's BGA. Since they gennerally point toward the CPU's side of the FlexIO, I'd agree that's a plausible conclusion. Remember the CPU's BGA can go bad too.

I'd check the voltages leading to IC5004 & IC6012. Check their respective enable/control Signal states (when do they go low). I'd measure the clock and see if the frequencies match expected (whatever that is. IDK yet). For example, the phase difference between the reference clock and PLL should be locked. But the error says they're not. That makes me suspect the feedback loop or loop filter.

I'm still super uneducated on PLLs and it's one of the MANY EE topics I've been researching lately.

All of this is part of my research project. I've already defined system voltages and created a voltage flowChart for the main ICs in the chain. Next up is to do the same for the Clock generators and Signal transduction pathways. Getting closer to presenting my findings - transcriptions really, all the information is already in the schematics. It's just hard to follow. But I'm not there yet. Especially in the area of clock generators or PLL.

For example, in that video he mentions the importance of the PLL filter in maintaining stability. I suspect PLL instability is a major suspect for producing your errors. That's why the refrence to "P_L_BYPASS" peaked my interest. It could be an area with deteriorating filtering caps (like the tokins were for VDDC). But again, My understanding of this is very preliminary and raw. And I'm grasping at straws.
 
Last edited:
RIP-Felix said:
I have a vague lead based on supposition and hunch.

On page 2/24 in the schematic there is a signal tree of +1.2V_MC2_VDDIO with a reference to the "P_L_BYPASS." My mind went to the PLL, which makes me think clock.

IC6012 (JL6063) --> +1.2V_MC2_VDDIO = BE_SPI, CHKSTP, JTAG, TBEN, & P_L_BYPASS
It gets powered by (IC6003/Q6601) --> 3.3V_MISC, so that needs to be present (which it should be, because the errors occurred at step #80 = Power On state. The Power On Sequence had completed successfully without error and +3.3V_MISC is one of the first checks). I thought I'd just mention it for the sake of completeness.

On page 18/24, IC5004 produces/monitors the reference clocks for the SB/CPU/RSX FlexIO Core (+1.2V_RC_VDDIO).

That's where the evidence dries up and previouse experiance comes in. @vyktormvmpay25 has said these errors tend to be and issue with the CPU's BGA. Since they gennerally point toward the CPU's side of the FlexIO, I'd agree that's a plausible conclusion. Remember the CPU's BGA can go bad too.

I'd check the voltages leading to IC5004 & IC6012. Check their respective enable/control Signal states (when do they go low). I'd measure the clock and see if the frequencies match expected (whatever that is. IDK yet). For example, the phase difference between the reference clock and PLL should be locked. But the error says they're not. That makes me suspect the feedback loop or loop filter.

I'm still super uneducated on PLLs and it's one of the MANY EE topics I've been researching lately.

All of this is part of my research project. I've already defined system voltages and created a voltage flowChart for the main ICs in the chain. Next up is to do the same for the Clock generators and Signal transduction pathways. Getting closer to presenting my findings - transcriptions really, all the information is already in the schematics. It's just hard to follow. But I'm not there yet. Especially in the area of clock generators or PLL.

For example, in that video he mentions the importance of the PLL filter in maintaining stability. I suspect PLL instability is a major suspect for producing your errors. That's why the refrence to "P_L_BYPASS" peaked my interest. It could be an area with deteriorating filtering caps (like the tokins were for VDDC). But again, My understanding of this is very preliminary and raw. And I'm grasping at straws.
Click to expand...
Thanks.. but most of these are above my head. Can you elaborate what PLL stands for? For my 02 2110 errors, I think it all has the same behaviour as my previous fixed COK002. A blown F6001 fuse and one MLCC around Q6002. I briefly checked the resistance and it looks like match my gut feeling - F6001 certainly was broken and some MLCC shown low resistance. This all came very dejavu - same board, same error code(for 02 2110), almost same component. So I will fix those first before diving into circuit analysis. However I used up my spare time so might find some time at the weekend.
 
feng_ye said:
Thanks.. but most of these are above my head. Can you elaborate what PLL stands for? For my 02 2110 errors, I think it all has the same behaviour as my previous fixed COK002. A blown F6001 fuse and one MLCC around Q6002. I briefly checked the resistance and it looks like match my gut feeling - F6001 certainly was broken and some MLCC shown low resistance. This all came very dejavu - same board, same error code(for 02 2110), almost same component. So I will fix those first before diving into circuit analysis. However I used up my spare time so might find some time at the weekend.
Click to expand...
Lol...you know how when you laser focus in on one thing everything seems related? I think that's what may have happened. I focused too hard of the 1701 and 14ff. I missed the key word, that you are now getting 02 2110. That means the fuse popped while the console was on, generating the 1701 and 14ff. So even if you fix the fuse, it'll pop again until you find the short.

More troubleshooting.

So forget about the PLL then. Nothing to see here.
 
On to the 4th PS3 a COK-002 system with these errors:

===================================
ERR 00: 00000000 A0403034 FFFFFFFF
ERR 01: 00000000 A0404401 FFFFFFFF
ERR 02: 00000000 A0403034 FFFFFFFF
ERR 03: 00000000 A0404401 FFFFFFFF
ERR 04: 00000000 A0403034 FFFFFFFF
ERR 05: 00000000 A0404401 FFFFFFFF
ERR 06: 00000000 A0403034 FFFFFFFF
ERR 07: 00000000 A0404401 FFFFFFFF
ERR 08: 00000000 A0403034 FFFFFFFF
ERR 09: 00000000 A0404401 FFFFFFFF
ERR 10: 00000000 A0403034 FFFFFFFF
ERR 11: 00000000 A0404401 FFFFFFFF
ERR 12: 00000000 A0403034 FFFFFFFF
ERR 13: 00000000 A0404401 FFFFFFFF
ERR 14: 00000000 A0403034 FFFFFFFF
ERR 15: 00000000 A0404401 FFFFFFFF
ERR 16: 00000000 A0403034 FFFFFFFF
ERR 17: 00000000 A0404401 FFFFFFFF
ERR 18: 00000000 A0403034 FFFFFFFF
ERR 19: 00000000 A0404401 FFFFFFFF
===================================

I have not fully taken the system apart, just enough to solder on the UART wires so it most likely is another RSX failure as the ohm readings on both the CPU and RSX are above 3 ohms.
 
Yes under 2.5 ohms it is a common issue, probably 1.8 ohms in vdd line. That's why my trick years ago worked. I used to fix cok002 with 90nm rsx by adding another 90 rsx from Sem001 or dia001 if people wanted so hard to save cok002. But again same thing happens with newer versions and 90nm is becoming obsolete.
 
Last edited:
RIP-Felix said:
Lol...you know how when you laser focus in on one thing everything seems related? I think that's what may have happened. I focused too hard of the 1701 and 14ff. I missed the key word, that you are now getting 02 2110. That means the fuse popped while the console was on, generating the 1701 and 14ff. So even if you fix the fuse, it'll pop again until you find the short.

More troubleshooting.

So forget about the PLL then. Nothing to see here.
Click to expand...

Yeah blown F6001 and shorted C6019, exactly the same as my previous fixed COK-002. Looks like a lot of power related problems are stem from here. Then.. still GLOD! Tried AV port, no image. Then unplugged HDD restart from UART bringup, HDMI config screen appears! Done the config, cannot start system(ofcoz). Then re-plug in HDD, GameOS shown up. Done the config and date, turn off before ready to pack up, tried another bringup... boom still GLOD.

Till now I have no way to bring it back. It looks like something to do with HDMI chip or flash memory(it cannot remember the HDMI settings between the two sessions with image). Using the syscon hdmi command has the following output:

Code: 
>$ hdmi chstat 0
hdmi chstat 0
[HDMI] ----------------------------
[HDMI] -- HDMI Channel 0 Context --
[HDMI] ------------------------------------------------------------------------------------
[HDMI]  +-[System Management]
[HDMI]     - SSM Task ID : 13
[HDMI]         * Task Status : WAITING
[HDMI]         * Wait Cause  : EVENT FLAG
[HDMI]     - SSM State : WaitResolution
[HDMI]     - SSM Mutex Information : ID[2] LockTID[0] WaitTID[0]
[HDMI]     - SSM Event Flag Info : ID[2] WaitTID[13] FlagPattern[0]
[HDMI]     - SSM Mode : HDMI
[HDMI] ------------------------------------------------------------------------------------
[HDMI]     - Authentication Status : NotStart
[HDMI]     - Repeater : Sink
[HDMI]     - KSVs     : 0
[HDMI] ------------------------------------------------------------------------------------
[HDMI]  +-[Interrupt]
[HDMI]     - External Interrupt Number of Mullion : 7
[HDMI]     - Interrupt Mask Pattern in SiI : [0x0000E0]
[HDMI]     - Interrupt Register Size : 3
[HDMI]     - Interrupt Task ID : 12
[HDMI]         * Task Status : WAITING
[HDMI]         * Wait Cause  : SLEEPING
[HDMI]     - Semapho Information : ID[38] WaitingTID[0] Count[1]
[HDMI]     - Plug Status : PowerOn
[HDMI] ------------------------------------------------------------------------------------
[HDMI]  +-[SiIType]
[HDMI]     - Chip Type : 9132
[HDMI] ------------------------------------------------------------------------------------
[HDMI]  +-[EDID]
[HDMI]     - EDID Mutex ID : 3
[HDMI]     - EDID Mutex Information : ID[3] LockTID[0] WaitTID[0]
[HDMI]     - EDID Block Size : 2
[HDMI] ------------------------------------------------------------------------------------
[HDMI]  +-[I2C Bus]
[HDMI]     - Device Address 0x72(0) 0x7A(1)
[HDMI]     - Semapho Information : ID[36] WaitingTID[0] Count[1]
[HDMI] ------------------------------------------------------------------------------------
[HDMI]  +-[AV Setting]
[HDMI]     - Audio Setting State : Unset
[HDMI]                     Mute  ; Mute
[HDMI]     - Video Setting State : Unset
[HDMI]                     Mute  ; Mute
[HDMI]                  Setting  : 00 00 00 00 00 00 00 00 00 00 00 00
[HDMI]                           : 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
[HDMI]
>$ hdmi ictype 0
hdmi ictype 0
[HDMI] Chip is SiI9132.
>$ hdmi setup 0
hdmi setup 0
[ERROR]: 0xa0802120
[mullion]$

So hdmi setup doesn't do anything for me, a second call to hdmi setup will result a 80 2120 error. I'm bit of at loss what to do next but happy to see 1701 and 14ff errors gone!

UPDATE: Did some research on the forum and looks like connecting southbridge UART will give more information about GLOD. But how can I do it? https://www.psdevwiki.com/ps3/Service_Connectors and https://www.psdevwiki.com/ps3/PCI both give out the pin/pad of SB_RxD and SB_TxD but from my test they're not directly connected, on COK-002. Shall I just solder wires on those pads or pins and connect RxD, TxD and GND then expect output from the USB-TTL serial port? What's the baud rate settings? Is writing EEPROM to enable redirect output mandatory? There're so much things unclear to me...

UPDATE2: A bit of situation of this COK-002. The leftmost USB port is damaged, looks like someone used a screw driver to destroy it deliberately. I have no other history for this board. But from my testing the four pins inside the damaged USB port aren't shorted. When GLOD happens, there's no power from any of the 4 USB ports. So a damaged USB controller could be preventing the OS from booting?
 
Last edited:
feng_ye said:
Yeah blown F6001 and shorted C6019, exactly the same as my previous fixed COK-002. Looks like a lot of power related problems are stem from here. Then.. still GLOD! Tried AV port, no image. Then unplugged HDD restart from UART bringup, HDMI config screen appears! Done the config, cannot start system(ofcoz). Then re-plug in HDD, GameOS shown up. Done the config and date, turn off before ready to pack up, tried another bringup... boom still GLOD.

Till now I have no way to bring it back. It looks like something to do with HDMI chip or flash memory(it cannot remember the HDMI settings between the two sessions with image). Using the syscon hdmi command has the following output:

Code: 
>$ hdmi chstat 0
hdmi chstat 0
[HDMI] ----------------------------
[HDMI] -- HDMI Channel 0 Context --
[HDMI] ------------------------------------------------------------------------------------
[HDMI]  +-[System Management]
[HDMI]     - SSM Task ID : 13
[HDMI]         * Task Status : WAITING
[HDMI]         * Wait Cause  : EVENT FLAG
[HDMI]     - SSM State : WaitResolution
[HDMI]     - SSM Mutex Information : ID[2] LockTID[0] WaitTID[0]
[HDMI]     - SSM Event Flag Info : ID[2] WaitTID[13] FlagPattern[0]
[HDMI]     - SSM Mode : HDMI
[HDMI] ------------------------------------------------------------------------------------
[HDMI]     - Authentication Status : NotStart
[HDMI]     - Repeater : Sink
[HDMI]     - KSVs     : 0
[HDMI] ------------------------------------------------------------------------------------
[HDMI]  +-[Interrupt]
[HDMI]     - External Interrupt Number of Mullion : 7
[HDMI]     - Interrupt Mask Pattern in SiI : [0x0000E0]
[HDMI]     - Interrupt Register Size : 3
[HDMI]     - Interrupt Task ID : 12
[HDMI]         * Task Status : WAITING
[HDMI]         * Wait Cause  : SLEEPING
[HDMI]     - Semapho Information : ID[38] WaitingTID[0] Count[1]
[HDMI]     - Plug Status : PowerOn
[HDMI] ------------------------------------------------------------------------------------
[HDMI]  +-[SiIType]
[HDMI]     - Chip Type : 9132
[HDMI] ------------------------------------------------------------------------------------
[HDMI]  +-[EDID]
[HDMI]     - EDID Mutex ID : 3
[HDMI]     - EDID Mutex Information : ID[3] LockTID[0] WaitTID[0]
[HDMI]     - EDID Block Size : 2
[HDMI] ------------------------------------------------------------------------------------
[HDMI]  +-[I2C Bus]
[HDMI]     - Device Address 0x72(0) 0x7A(1)
[HDMI]     - Semapho Information : ID[36] WaitingTID[0] Count[1]
[HDMI] ------------------------------------------------------------------------------------
[HDMI]  +-[AV Setting]
[HDMI]     - Audio Setting State : Unset
[HDMI]                     Mute  ; Mute
[HDMI]     - Video Setting State : Unset
[HDMI]                     Mute  ; Mute
[HDMI]                  Setting  : 00 00 00 00 00 00 00 00 00 00 00 00
[HDMI]                           : 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
[HDMI]
>$ hdmi ictype 0
hdmi ictype 0
[HDMI] Chip is SiI9132.
>$ hdmi setup 0
hdmi setup 0
[ERROR]: 0xa0802120
[mullion]$

So hdmi setup doesn't do anything for me, a second call to hdmi setup will result a 80 2120 error. I'm bit of at loss what to do next but happy to see 1701 and 14ff errors gone!

UPDATE: Did some research on the forum and looks like connecting southbridge UART will give more information about GLOD. But how can I do it? https://www.psdevwiki.com/ps3/Service_Connectors and https://www.psdevwiki.com/ps3/PCI both give out the pin/pad of SB_RxD and SB_TxD but from my test they're not directly connected, on COK-002. Shall I just solder wires on those pads or pins and connect RxD, TxD and GND then expect output from the USB-TTL serial port? What's the baud rate settings? Is writing EEPROM to enable redirect output mandatory? There're so much things unclear to me...

UPDATE2: A bit of situation of this COK-002. The leftmost USB port is damaged, looks like someone used a screw driver to destroy it deliberately. I have no other history for this board. But from my testing the four pins inside the damaged USB port aren't shorted. When GLOD happens, there's no power from any of the 4 USB ports. So a damaged USB controller could be preventing the OS from booting?
Click to expand...
@vyktormvmpay25 is the SB Sensei. I've never tried the SB UART myself. I'm also curious if there's more to it than just using the same code/procedure as the SYSCON (which i doubt). So I second the call for a tutorial. Victor, you feel like revealing your SB Code-fu?

That's interesting. I've had something similar happen to me, where the HDMI setting don't persist after shutting down. It would prompt me there was a HDMI device detected and ask If I wanted to switch to it. I say yes and setup 1080p to my HDTV. No problem. That session works fine. But it'd prompt me to do the same on the very next boot, as if it can't remember those settings. I didn't think anything of it, and now I can't even remember which PS3 it was.

I wonder where the AV/HDMI configuration is stored? Probably NAND/NOR. I do know I/O from the HDMI/AV controllers needs to pass through the RSX over the FlexIO to the SB, where it can then be directed to the Starship2 Flash controller for storage. It still has to go through the SB to get to the HDD if that's where the config is stored. So either way, if there's an issue on the BGA/Bumps affecting VDDIO, but not necessarily the FlexIO, then you can conceivably get 2120/2020 errors. I hate to say it, but I don't think we can rule out the RSX BGA. I do know we often see 2120/2020 associated with 3034/4XXX errors. This may be why.

You could try replacing the HDMI encoder just to rule it out. Then reball.

Glad you got the 2110 sorted. C6019 again? Yeah, maybe you have stumbled on a common issue there...or just crap luck.
 
@vyktormvmpay25 Looks like I was wrong on the ohm readings, the RSX measures 2.5 ohms and the CPU measures 3.3 ohms. Also found that the previous repair tech delided the CPU and the die is a bit discolored but the bigger issue is this, I think this one is toast as well.
 

Attachments

  • Thu Dec 16 19-38-31.jpg
    Thu Dec 16 19-38-31.jpg
    58.8 KB · Views: 64
poot36 said:
On to the 4th PS3 a COK-002 system with these errors:

===================================
ERR 00: 00000000 A0403034 FFFFFFFF
ERR 01: 00000000 A0404401 FFFFFFFF
ERR 02: 00000000 A0403034 FFFFFFFF
ERR 03: 00000000 A0404401 FFFFFFFF
ERR 04: 00000000 A0403034 FFFFFFFF
ERR 05: 00000000 A0404401 FFFFFFFF
ERR 06: 00000000 A0403034 FFFFFFFF
ERR 07: 00000000 A0404401 FFFFFFFF
ERR 08: 00000000 A0403034 FFFFFFFF
ERR 09: 00000000 A0404401 FFFFFFFF
ERR 10: 00000000 A0403034 FFFFFFFF
ERR 11: 00000000 A0404401 FFFFFFFF
ERR 12: 00000000 A0403034 FFFFFFFF
ERR 13: 00000000 A0404401 FFFFFFFF
ERR 14: 00000000 A0403034 FFFFFFFF
ERR 15: 00000000 A0404401 FFFFFFFF
ERR 16: 00000000 A0403034 FFFFFFFF
ERR 17: 00000000 A0404401 FFFFFFFF
ERR 18: 00000000 A0403034 FFFFFFFF
ERR 19: 00000000 A0404401 FFFFFFFF
===================================

I have not fully taken the system apart, just enough to solder on the UART wires so it most likely is another RSX failure as the ohm readings on both the CPU and RSX are above 3 ohms.
Click to expand...

This is RSX failure.

poot36 said:
@vyktormvmpay25 Looks like I was wrong on the ohm readings, the RSX measures 2.5 ohms and the CPU measures 3.3 ohms. Also found that the previous repair tech delided the CPU and the die is a bit discolored but the bigger issue is this, I think this one is toast as well.
Click to expand...

Take another picture, too much reflection. The cpu may be just fine.
 
RIP-Felix said:
vyktormvmpay25 is the SB Sensei. I've never tried the SB UART myself. I'm also curious if there's more to it than just using the same code/procedure as the SYSCON (which i doubt). So I second the call for a tutorial. Victor, you feel like revealing your SB Code-fu?
Click to expand...
It's just a plain text output, just use any terminal application.
I wonder where the AV/HDMI configuration is stored?
Click to expand...
Inside the Syscon EEPROM.
 
M4j0r said:
It's just a plain text output, just use any terminal application.

Inside the Syscon EEPROM.
Click to expand...

I forget not everybody realizes the tricks you've shared here and there. So if you don't mind, I'll just copy what you said before.

For the cookie boards (is it the same for others?) first you need to input the command "w 7202 2" into the syscon to activate SB UART port. Then you need to solder the RXD wire to the correct point.

cok-sb log.jpg

After that you can connect to the South Bridge UART with Putty or any other tool. Settings are 115200 baud, 8N1. It will start printing the text automatically.
 
Last edited:
M4j0r said:
It's just a plain text output, just use any terminal application.

Inside the Syscon EEPROM.
Click to expand...
M4j0r said:
Mullion 201GB, 202GB: 0x7202
Mullion 203GB + later : 0x4202
Sherwood : 0x1202


It's used for writing stuff but only on specific firmwares.

You can also activate some lv1 debug messages (level 0x00 to 0x03) to get more information by changing the 0x48CF0 to 0x48CFF NVS offsets.
Click to expand...
Hi M4j0r, I wonder do you need solder any 'missing components' on if you need to use SB UART? It looks like the PCI connector or the Service Connector all having some resistors missing on retail COK-002, if I reference the service manual diagram.
Also, it looks like PCI connector and Service connector both having SB RxD and TxD. Are both of them usable?
Thanks a lot!
 
feng_ye said:
Hi M4j0r, I wonder do you need solder any 'missing components' on if you need to use SB UART? It looks like the PCI connector or the Service Connector all having some resistors missing on retail COK-002, if I reference the service manual diagram.
Also, it looks like PCI connector and Service connector both having SB RxD and TxD. Are both of them usable?
Thanks a lot!
Click to expand...
You have pins for sb uart connection, this is something that may not help too much, more likely to see boot order.
http://s.go.ro/4t2k3p0v
Those missing parts are in case you want to use different connectors on side of pcb, just use bridges.
Before you connect to sb you need to write inside syscon different address:
w 1202 02 - for SW syscon type
w 4202 02 - for dia002 board, it is kind of mixed board and one only with this setup I believe for retail units.
w 7202 02 - for rest of mullion syscon.
Now rest is easy use any port terminal software in pc, like M4j0r says is just text.
If you don't see SB debugging starting after running bringup command, that hardware problem needs to be fixed.There won't be any information on SB uart if unit isn't starting well, at least all parts less rsx when it is kind of special glod.
Just run bringup twice and add all info will help to understand
 
@DeadEnd Sorry about the low quality photo, it is from my cheap $20 China microscope. I have more pictures from the better camera on my tablet.
 

Attachments

  • 20211217_214942_HDR[1].jpg
    20211217_214942_HDR[1].jpg
    861 KB · Views: 65
  • 20211217_215112_HDR[1].jpg
    20211217_215112_HDR[1].jpg
    813.7 KB · Views: 67
You must log in or register to reply here.

Similar threads

Back
Top