Your method can distinguish minor differences in the bootup sequence that the SYSCON error codes don't necessarily capture. Mainly because it doesn't generate a code for GLOD situations.
However, if you use the
bringup command to start the console it will show the power sequence in the log. If there is an error that occurs before the boot-loader starts, it should show in that log. This works in mullion SYSCON's with internal access, at least. Here is what a COK-001 power sequence should look like normally:
Code:
[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:0x20e2
[SSM] state: 0104 -> 0204
[SSM] state: 0204 -> 0105
[SSM] state: 0105 -> 0400
(PowerOn State)
[SERV NVS] READ CMD
If there is an error, it should generate a YLOD and say where in the PowerSEQ it failed, with an error code. If everything is normal, the PowerSEQ only takes about half a second to complete. If the tokins are going out or there is some kind of issue with the power it can take longer. So that can clue you into an possible error. However, in the case of a GLOD it often stalls out in the bootloader which attempt to load just after the PowerSeq. I've seen a bunch of errors and retrys in the log.
I also want to circle back to something I noticed before that hasn't seemed to gain traction. And it's the Bittraining error that can be seen in the lasterrlog. Here's an example:
View attachment 33782
This was PS3#4, a COK-001 that only had a 1.5s YLOD and a single 3034 error. I traded this board to
@squeept for a motherboard that had bad tokins. He reballed the RSX, but it changed to a GLOD with syscon errors 1001. He attempted the first frankenstein mod on it.
The reason I bring it up is that if you look at the bittraining error it says the problem is in the "BE:RRAC:RX2:GLOBAL1:RS_STATUS." BE is the Cell processor and RRAC I recongnize from the "RRAC VDDIO Bypassing" section of the schematic. I came across it last night when I was trying to figure out which BE voltage
@botakompong was referring to as C3. It's the +1.2v_YC_RC_VDDIO. If you search the
CELL pinout wiki for RX2 you can find the pin cordinates for the RC_VDDIO (AD37-41 & AC34-36). It's literally telling you where the signal degraded! IF you measure the voltage at C3 and it's good. Then reball the CPU to fix it! I totally missed that.
View attachment 33786
This explains @squeepts failure to fix this console. He was focusing on the RSX when it was a Cell reball that's needed! And any subsequent frankenstine mod was doomed unless this problem was fixed first!
