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

sandungas said:
Btw @marciolsf that photos with some pins soldered directly to the motherboard are extremelly dangerous,
Click to expand...
not really , pretty standard stuff

sandungas said:
Btw @marciolsf
probably thats going to be a game over because there are not alternative solder points to repair the track, we are lucky there is a test point in them that "emerges" to the surface, but most of that syscon tracks are "hidden" in intermediate layers of the motherboard.
Click to expand...
Wanna bet?
syscon_pins_btr.png



sandungas said:
Btw @marciolsf
The PS3 motherboard have up to 8 layers.. the critical or sensitive data tracks are always huidden and "shielded" against interferences in between other copper layers
Click to expand...
Not true!
Using Top or Bottom layer for high speed/sensitive tracks actually the most common way even for the simple reason: the components are there too! Also, much easier to test/inspect those. Using vias to jump layers are ill-advised for length/impedance matched tracks (the very definition of sensitive) that used for eg. RAM or CPU.
You can see those serpentine tracks to the Rambus RAMs and the lot of tracks between the Cell and the RSX.
 
marciolsf said:
Flip-chip bumps? I'm afraid I don't know what you mean...
Click to expand...
Bingle to the rescue!

Flip chip, also known as controlled collapse chip connection or its abbreviation, C4, is a method for interconnecting semiconductor devices, such as IC chips and microelectromechanical systems (MEMS), to external circuitry with solder bumps that have been deposited onto the chip pads. The technique was developed by General Electric's Light Military Electronics Dept., Utica, N.Y. The solder bumps are deposited on the chip pads on the top side of the wafer during the final wafer processing step. In order to mount the chip to external circuitry (e.g., a circuit board or another chip or wafer), it is flipped over so that its top side faces down, and aligned so that its pads align with matching pads on the external circuit, and then the solder is reflowed to complete the interconnect. This is in contrast to wire bonding, in which the chip is mounted upright and wires are used to interconnect the chip pads to external circuitry.
Click to expand...

Good timing! I was in the middle of replying :) I'm short in time now, but I'll watch the linked video (thanks for that, btw) when i get back and have more time to digest it.

And just to confirm your previous post, you had 3034 error and you fixed that with a reflow? Did you do any other repairs/modifications on the board?
 
CodeKiller said:
not really , pretty standard stuff


Wanna bet?
View attachment 26454



Not true!
Using Top or Bottom layer for high speed/sensitive tracks actually the most common way even for the simple reason: the components are there too! Also, much easier to test/inspect those. Using vias to jump layers are ill-advised for length/impedance matched tracks (the very definition of sensitive) that used for eg. RAM or CPU.
You can see those serpentine tracks to the Rambus RAMs and the lot of tracks between the Cell and the RSX.
Click to expand...
The only reason why there are TX and RX pads in the surface layer is because are used in factory, but usually the tracks more sensitive to "hacking" or the ones connected to the slave controllers or power rails and the ones prone to interferences are very well hidden/shielded

I was talking in general, not specificially about the pins used for JTAG
Anyway, a pad lifted under syscon is scary, probably the worst place to happen (together with CELL, RSX, and SB)... again talking in general
 
Last edited:
marciolsf said:
And just to confirm your previous post, you had 3034 error and you fixed that with a reflow? Did you do any other repairs/modifications on the board?
Click to expand...
First replaced the Nec/Tokin capacitors on the "top" (keeping the ones on the side where the Cell and the RSX are) as a lot suggested that is the fix for 90% -- from my experience it does not help (0/2).
Then fixed a power regulator that i messed up during recap. (pretty sure the error codes was different but forgot to check before clearing)
Then tried looking into the syscon to see what's going on. (error codes of 3034 and 4432)
Finally "reflow", and now working.
 
CodeKiller said:
First replaced the Nec/Tokin capacitors on the "top" (keeping the ones on the side where the Cell and the RSX are) as a lot suggested that is the fix for 90% -- from my experience it does not help (0/2).
Then fixed a power regulator that i messed up during recap. (pretty sure the error codes was different but forgot to check before clearing)
Then tried looking into the syscon to see what's going on. (error codes of 3034 and 4432)
Finally "reflow", and now working.
Click to expand...

Very interesting, thanks. Out of curiosity, which power regulator was it?
 
marciolsf said:
I get your point! Those solder points are really tiny, so the wires are naturally thin, and breaking them off won't take much! I don't quite see what you're suggesting, though...
Click to expand...
Sorry, is tricky to explain, i made a couple of photoshop drawing to show you the 2 suggestions i was talking about, both are relativelly easy to do for free and are accurate
kpFoP2U.png

The idea here is to "grab" the motherboard from both sides, the pressure of the needle is generated by the spring... so is really neeeded to "deform" that spring (by forcing the twisting of it until it doesnt returns back) to decrease the pressure of the needle a lot
Keep in mind that sewing needles are very shaped, is relativelly easy to make a "hole" in the motheboard if the pressure is excesive... this is also why i suggested to "blunt" the tip of the needle with sandpaper, a file or something
The restriction of this idea is the "target" needs to be located near the motherboard border, thats a bit bummer but other than that is going to work fine
The good point of this method is if you make it with diffrent materials maybe is posible to create a single "mold" with multiple needles in a single piece (but in that case it woud be specific for a motherboard model)

o4h4Ez9.png

The second idea is about creating a "tripod", with some weight in his "pillars", that weights stabilizes it, and generates the pressure for the needle
As you can see in the image the total weight of the tripod is 100 grams, but the weight is a bit more focused in the pillar with the needle, this distribution of weights is something i imagined right now while making the drawing, also that weights i suggested are just some random numbers... this is the kind of thing that needs to be calculated a bit accuratelly because the pressure of the needle depends completly of that weights

The accuracy is pretty much the same in both, but this idea allows to move your "tripod" to any point of the motherboard, the bad thing is you need 1 "tripod" for every wire
 
Last edited:
sandungas said:
Sorry, is tricky to explain, i made a couple of photoshop drawing to show you the 2 suggestions i was talking about, both are relativelly easy to do for free and are accurate
kpFoP2U.png

The idea here is to "grab" the motherboard from both sides, the pressure of the needle is generated by the spring... so is really neeeded to "deform" that spring (by forcing the twisting of it until it doesnt returns back) to decrease the pressure of the needle a lot
Keep in mind that sewing needles are very shaped, is relativelly easy to make a "hole" in the motheboard if the pressure is excesive... this is also why i suggested to "blunt" the tip of the needle with sandpaper, a file or something
The restriction of this idea is the "target" needs to be located near the motherboard border, thats a bit bummer but other than that is going to work fine
The good point of this method is if you make it with diffrent materials maybe is posible to create a single "mold" with multiple needles in a single piece (but in that case it woud be specific for a motherboard model)

o4h4Ez9.png

The second idea is about creating a "tripod", with some weight in his "pillars", that weights stabilizes it, and generates the pressure for the needle
As you can see in the image the total weight of the tripod is 100 grams, but the weight is a bit more focused in the pillar with the needle, this distribution of weights is something i imagined right now while making the drawing, also that weights i suggested are just some random numbers... this is the kind of thing that needs to be calculated a bit accuratelly because the pressure of the needle depends completly of that weights

The accuracy is pretty much the same in both, but this idea allows to move your "tripod" to any point of the motherboard, the bad thing is you need 1 "tripod" for every wire
Click to expand...

Ah, that does make sense! it's similar in concept to the clips I've seen people use for hard mods.
 
marciolsf said:
I had that problem at first too, but I'm pretty sure I got it working with pyserial. You might try grabbing the newer version of the script here -- https://github.com/db260179/ps3syscon.git


You'll get the hang of it! My suggestion is that once you get connected, play around with the commands until you feel comfortable with the terminal. Most of the commands won't change anything, the ones that do have a parameter of SET, or begin with W (for Write), so stay away from those. Two safe commands are:

  • ERRLOG GET 00 --> gets the most recent error (you can also do 01, 02, all the way up to 19)
  • VER --> Returns the firmware version
Click to expand...
I installed a new lubuntu linux system.
On a clean system, I used the command:

sudo apt-get install python-serial python-crypto

Helpful command:
sudo chmod a + rw / dev / ttyUSB0

Now the program does not throw an error. I remembered that a year ago I was learning Python and installing something - maybe it was a problem.

Now, despite running the script, I can't get any results
Now I get:
1odHNam

w9YSHE0

https://imgur.com/a/VM1Fepf


I have a question about the order of execution:
1. I insert the module into USB.
2. Click the PS3 switch on the back from 0 to 1
3. I press ON on PS3
4. I get YLOD
5. I run the script (the red LED on PS3 flashes)
 
Would someone please post the bringup log from a working system? For example, here's mine

Code: 
>$ 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
Psbd_SbTransMode_Half:0x20e2
>$
[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]: 0xa0403034
[POWSEQ] PowerSeq_Letup called.
[SSM] state: 0700 -> 0600
(PowerOff State) (Fatal)

Here's an earlier one, from @LSL

Code: 
>
[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:0x20e2
[SSM] state: 0104 -> 0204
[SSM] state: 0204 -> 0105
[SSM] state: 0105 -> 0400
(PowerOn State)
[SERV NVS] READ CMD

Boot Loader SE Version 1.0.0 (Build ID: 1673,16934, Build Data: 2006-10-30_12:39:57)
Copyright(C) 2006 Sony Computer Entertainment Inc.All Rights Reserved.
[SERV SETCFG] XDR (CH0,CH1) ASSERT
[SERV SETCFG] XDR (CH0,CH1) DEASSERT
[INFO]: Connecting to Debug Device (SB UART)
[SERV NVS] READ CMD
[SERV NVS] READ CMD
[SERV NVS] READ CMD
[SERV NVS] READ CMD
[SERV NVS] READ CMD
[SERV NVS] READ CMD
[SERV NVS] READ CMD
[SERV NVS] READ CMD
[SERV NVS] READ CMD
[SERV NVS] READ CMD
[SERV NVS] READ CMD
[SERV NVS] READ CMD
[SERV NVS] READ CMD
[SERV NVS] READ CMD
[SERV NVS] READ CMD
[SERV NVS] READ CMD
[SERV NVS] READ CMD
[SERV NVS] READ CMD
[SERV NVS] READ CMD
[SERV NVS] READ CMD
[SERV NVS] READ CMD
[SERV NVS] READ CMD
[SERV NVS] READ CMD
[SERV NVS] READ CMD
[SERV THERM] NOTIFY_MODE CMD
POWER Button released
[SERV NVS] READ CMD
[SERV NVS] READ CMD
[SERV NVS] READ CMD
[SSM] *** Power Fail RS ***
[SSM] state: 0400 -> 0700
[POWSEQ] AV Backend Letup
[SSM] ssmCb_AfterBeOn() called.
[SSM] Shutdown mode : syspm_stat=00000000/00000000
[ERROR]: 0xa0801002
[POWSEQ] PowerSeq_Letup called.
[SSM] state: 0700 -> 0600
(PowerOff State) (Fatal)

Along with specific error messages, we also get function names and returned error codes from those functions. I'm thinking it would be useful to start documenting the function names. For example, so far we have

  • ssmCb_OnStartingBePowOn()
  • ssmCb_BeforeBeOn() (And that fails, on my board, so then it calls the next function, below)
  • ssmCb_AfterBeOn2() (and that returns the error "PowSeq Fail : Detected", and transitions the state to state: 0304 -> 0700)

@LSL goes a bit further, and he successfully boots! Then we get the additional function
  • ssmCb_AfterBeOn()
We can also see the state transitions. We start with the initial transition, and the we transition through several different states. This is the states sequence from my board
  • [SSM] state: 0000 -> 0101 (initial state)
  • [SSM] state: 0101 -> 0201
  • [SSM] state: 0201 -> 0102
  • [SSM] state: 0102 -> 0202
  • [SSM] state: 0202 -> 0103
  • [SSM] state: 0103 -> 0203
  • [SSM] state: 0203 -> 0104
  • [SSM] state: 0104 -> 0304 (and then I fail)
  • [SSM] state: 0304 -> 0700 (every failure gets switched to 0700, it seems)
  • [SSM] state: 0700 -> 0600 (fatal failure state)
And here's the states from LSL
  • [SSM] state: 0000 -> 0101
  • [SSM] state: 0101 -> 0201
  • [SSM] state: 0201 -> 0102
  • [SSM] state: 0102 -> 0202
  • [SSM] state: 0202 -> 0103
  • [SSM] state: 0103 -> 0203
  • [SSM] state: 0203 -> 0104
  • [SSM] state: 0104 -> 0204
  • [SSM] state: 0204 -> 0105
  • [SSM] state: 0105 -> 0400 (PowerOn State, successful boot, but then we fail somewhere down the line)
  • [SSM] state: 0400 -> 0700
  • [SSM] state: 0700 -> 0600


What would be really cool is if we could find a correlation between the states and the syscon error log codes... Identifying the function calls might also help us determine where exactly the hardware is failing.
 
inazuma-akai said:
I installed a new lubuntu linux system.
On a clean system, I used the command:

sudo apt-get install python-serial python-crypto

Helpful command:
sudo chmod a + rw / dev / ttyUSB0

Now the program does not throw an error. I remembered that a year ago I was learning Python and installing something - maybe it was a problem.

Now, despite running the script, I can't get any results
Now I get:
1odHNam

w9YSHE0

https://imgur.com/a/VM1Fepf


I have a question about the order of execution:
1. I insert the module into USB.
2. Click the PS3 switch on the back from 0 to 1
3. I press ON on PS3
4. I get YLOD
5. I run the script (the red LED on PS3 flashes)
Click to expand...
I ran into those issues early on! It means you're successfully talking to syscon, but the auth is failing. When I run into those errors, I can get it to go away by:
  1. quitting the script with EXIT
  2. Powering the PS3 off (via the rear switch)
  3. Turn it back on
  4. Re-run the script
  5. AUTH right away
I spoke with M4J0r a while back about this, and he told me
The auth routine doesn't clear the uart receive buffer prior to executing the auth commands which can lead to errors.
Click to expand...

So by starting over from scratch, you should be able to clear the buffer and successfully auth.

Even without auth, though, you should still be able to run a few external commands. Try ERRLOG GET 00, that's an unprivileged command (it doesn't require any permissions) and see if you get anything.
 
marciolsf said:
I ran into those issues early on! It means you're successfully talking to syscon, but the auth is failing. When I run into those errors, I can get it to go away by:
  1. quitting the script with EXIT
  2. Powering the PS3 off (via the rear switch)
  3. Turn it back on
  4. Re-run the script
  5. AUTH right away
I spoke with M4J0r a while back about this, and he told me


So by starting over from scratch, you should be able to clear the buffer and successfully auth.

Even without auth, though, you should still be able to run a few external commands. Try ERRLOG GET 00, that's an unprivileged command (it doesn't require any permissions) and see if you get anything.
Click to expand...
Finally succeeded!!
KgNOKQi

You should add commands and connection steps to the instructions. This will make it very much easier for others.
I will start reading errors on Tuesday. I have enough of fighting today. I know that for most of you this is a trivial matter. I played Arduino and used some UART, but in this case something is still going wrong; (

Thank you very much for your help. I hope to repay you someday.
 
marciolsf said:
Would someone please post the bringup log from a working system?
Click to expand...

From another PS3
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

Boot Loader SE Version 0.9.5 (Build ID: 1634,16289, Build Data: 2006-09-21_19:11:09)
Copyright(C) 2006 Sony Computer Entertainment Inc.All Rights Reserved.
[SERV SETCFG] XDR (CH0,CH1) ASSERT
[SERV SETCFG] XDR (CH0,CH1) DEASSERT
[INFO]: Connecting to Debug Device (SB UART)
[SERV NVS] READ CMD
[SERV NVS] READ CMD
[SERV NVS] READ CMD
[SERV NVS] READ CMD
[SERV NVS] READ CMD
[SERV NVS] READ CMD
[SERV NVS] READ CMD
[SERV NVS] READ CMD
[SERV NVS] READ CMD
[SERV NVS] READ CMD
[SERV NVS] READ CMD
[SERV NVS] READ CMD
[SERV NVS] READ CMD
[SERV NVS] READ CMD
[SERV NVS] READ CMD
[SERV NVS] READ CMD
[SERV NVS] READ CMD
[SERV NVS] READ CMD
[SERV NVS] READ CMD
[SERV NVS] READ CMD
[SERV NVS] READ CMD
[SERV NVS] READ CMD
[SERV NVS] READ CMD
[SERV NVS] READ CMD
[SERV THERM] NOTIFY_MODE CMD
POWER Button released
[SERV NVS] READ CMD
[SERV NVS] READ CMD

[mullion]$ [SERV NVS] READ CMD
 
Putting hands on repairing a faulty PS3 without using this invaluable tool looks like walking in a big house with closed eyes!
It has been a while l was far from YLOD fight ring but today I came back and boom!! PS3 SYSCON is here.
But to star the journey we need to find RX, TX and diag pins on the motherboard. I have several fat and a slim lying in the box and I want to start with the slim one that is a cech-20 with DYN-001 MOBO.
How can I find the points on it?
 
Dariush Aghaee said:
Putting hands on repairing a faulty PS3 without using this invaluable tool looks like walking in a big house with closed eyes!
It has been a while l was far from YLOD fight ring but today I came back and boom!! PS3 SYSCON is here.
But to star the journey we need to find RX, TX and diag pins on the motherboard. I have several fat and a slim lying in the box and I want to start with the slim one that is a cech-20 with DYN-001 MOBO.
How can I find the points on it?
Click to expand...

https://www.psdevwiki.com/ps3/Service_Connectors
 
Later i will check log from my working PS3 after heat gun.
Now my PS3 YLOD bringup, eepcsum and errlog

Code: 
>$ 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
>$ bringup
[SSM] state: 0102 -> 0202
[SSM] state: 0202 -> 0103
[SSM] state: 0103 -> 0203
[SSM] ssmCb_BeforeBeOn() called.
[SSM] state: 0203 -> 0104
Psbd_SbTransMode_Half:0x20e7
[POWERSEQ] Error : BitTraining RSX:RRAC:RX1: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]: 0xa0404412
[ERROR]: 0xa0403034
[POWSEQ] PowerSeq_Letup called.
[SSM] state: 0700 -> 0600
(PowerOff State) (Fatal)
bringup
Do nothing. (FatalOff State)



>$ eepcsum
eepcsum
Addr:0x000032fe should be 0x1596
Addr:0x000034fe should be 0x86d6
Addr:0x000039fe should be 0x7360
Addr:0x00003dfe should be 0x00ff
Addr:0x00003ffe should be 0x00ff


>$ errlog
errlog
ofst[ 56]:err_code:0xffffffff, clock:0x268a555b  2020/06/27 19:07:07
ofst[ 60]:err_code:0xa0403034, clock:0x268a555b  2020/06/27 19:07:07
ofst[ 64]:err_code:0xa0404412, clock:0x268a55f3  2020/06/27 19:09:39
ofst[ 68]:err_code:0xa0403034, clock:0x268a55f3  2020/06/27 19:09:39
ofst[ 72]:err_code:0xa0404412, clock:0x268a5636  2020/06/27 19:10:46
ofst[ 76]:err_code:0xa0403034, clock:0x268a5636  2020/06/27 19:10:46
ofst[ 80]:err_code:0xa0404412, clock:0x268a5652  2020/06/27 19:11:14
ofst[ 84]:err_code:0xa0403034, clock:0x268a5652  2020/06/27 19:11:14
ofst[ 88]:err_code:0xa0404412, clock:0x268a575a  2020/06/27 19:15:38
ofst[ 92]:err_code:0xa0403034, clock:0x268a575a  2020/06/27 19:15:38
ofst[ 96]:err_code:0xa0404412, clock:0x268a57e1  2020/06/27 19:17:53
ofst[100]:err_code:0xa0403034, clock:0x268a57e1  2020/06/27 19:17:53
ofst[104]:err_code:0xa0404412, clock:0x268a5f82  2020/06/27 19:50:26
ofst[108]:err_code:0xa0403034, clock:0x268a5f82  2020/06/27 19:50:26
ofst[112]:err_code:0xa0404412, clock:0x268a600a  2020/06/27 19:52:42
ofst[116]:err_code:0xa0403034, clock:0x268a600a  2020/06/27 19:52:42
ofst[120]:err_code:0xa0404412, clock:0x268a6089  2020/06/27 19:54:49
ofst[124]:err_code:0xa0403034, clock:0x268a6089  2020/06/27 19:54:49
ofst[  0]:err_code:0xa0404412, clock:0x268a6090  2020/06/27 19:54:56
ofst[  4]:err_code:0xa0403034, clock:0x268a6090  2020/06/27 19:54:56
ofst[  8]:err_code:0xa0404412, clock:0x268a6098  2020/06/27 19:55:04
ofst[ 12]:err_code:0xa0403034, clock:0x268a6098  2020/06/27 19:55:04
ofst[ 16]:err_code:0xa0404412, clock:0x268a70f1  2020/06/27 21:04:49
ofst[ 20]:err_code:0xa0403034, clock:0x268a70f1  2020/06/27 21:04:49
ofst[ 24]:err_code:0xa0404412, clock:0x268a7162  2020/06/27 21:06:42
ofst[ 28]:err_code:0xa0403034, clock:0x268a7162  2020/06/27 21:06:42
ofst[ 32]:err_code:0xa0404412, clock:0x268a71a1  2020/06/27 21:07:45
ofst[ 36]:err_code:0xa0403034, clock:0x268a71a1  2020/06/27 21:07:45
ofst[ 40]:err_code:0xa0404412, clock:0x268a7337  2020/06/27 21:14:31
ofst[ 44]:err_code:0xa0403034, clock:0x268a7337  2020/06/27 21:14:31
ofst[ 48]:err_code:0xa0404412, clock:0x268a7360  2020/06/27 21:15:12
ofst[ 52]:err_code:0xa0403034, clock:0x268a7360  2020/06/27 21:15:12
 
inazuma-akai said:
Later i will check log from my working PS3 after heat gun.
Now my PS3 YLOD bringup, eepcsum and errlog

Code: 
>$ 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
>$ bringup
[SSM] state: 0102 -> 0202
[SSM] state: 0202 -> 0103
[SSM] state: 0103 -> 0203
[SSM] ssmCb_BeforeBeOn() called.
[SSM] state: 0203 -> 0104
Psbd_SbTransMode_Half:0x20e7
[POWERSEQ] Error : BitTraining RSX:RRAC:RX1: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]: 0xa0404412
[ERROR]: 0xa0403034
[POWSEQ] PowerSeq_Letup called.
[SSM] state: 0700 -> 0600
(PowerOff State) (Fatal)
bringup
Do nothing. (FatalOff State)



>$ eepcsum
eepcsum
Addr:0x000032fe should be 0x1596
Addr:0x000034fe should be 0x86d6
Addr:0x000039fe should be 0x7360
Addr:0x00003dfe should be 0x00ff
Addr:0x00003ffe should be 0x00ff


>$ errlog
errlog
ofst[ 56]:err_code:0xffffffff, clock:0x268a555b  2020/06/27 19:07:07
ofst[ 60]:err_code:0xa0403034, clock:0x268a555b  2020/06/27 19:07:07
ofst[ 64]:err_code:0xa0404412, clock:0x268a55f3  2020/06/27 19:09:39
ofst[ 68]:err_code:0xa0403034, clock:0x268a55f3  2020/06/27 19:09:39
ofst[ 72]:err_code:0xa0404412, clock:0x268a5636  2020/06/27 19:10:46
ofst[ 76]:err_code:0xa0403034, clock:0x268a5636  2020/06/27 19:10:46
ofst[ 80]:err_code:0xa0404412, clock:0x268a5652  2020/06/27 19:11:14
ofst[ 84]:err_code:0xa0403034, clock:0x268a5652  2020/06/27 19:11:14
ofst[ 88]:err_code:0xa0404412, clock:0x268a575a  2020/06/27 19:15:38
ofst[ 92]:err_code:0xa0403034, clock:0x268a575a  2020/06/27 19:15:38
ofst[ 96]:err_code:0xa0404412, clock:0x268a57e1  2020/06/27 19:17:53
ofst[100]:err_code:0xa0403034, clock:0x268a57e1  2020/06/27 19:17:53
ofst[104]:err_code:0xa0404412, clock:0x268a5f82  2020/06/27 19:50:26
ofst[108]:err_code:0xa0403034, clock:0x268a5f82  2020/06/27 19:50:26
ofst[112]:err_code:0xa0404412, clock:0x268a600a  2020/06/27 19:52:42
ofst[116]:err_code:0xa0403034, clock:0x268a600a  2020/06/27 19:52:42
ofst[120]:err_code:0xa0404412, clock:0x268a6089  2020/06/27 19:54:49
ofst[124]:err_code:0xa0403034, clock:0x268a6089  2020/06/27 19:54:49
ofst[  0]:err_code:0xa0404412, clock:0x268a6090  2020/06/27 19:54:56
ofst[  4]:err_code:0xa0403034, clock:0x268a6090  2020/06/27 19:54:56
ofst[  8]:err_code:0xa0404412, clock:0x268a6098  2020/06/27 19:55:04
ofst[ 12]:err_code:0xa0403034, clock:0x268a6098  2020/06/27 19:55:04
ofst[ 16]:err_code:0xa0404412, clock:0x268a70f1  2020/06/27 21:04:49
ofst[ 20]:err_code:0xa0403034, clock:0x268a70f1  2020/06/27 21:04:49
ofst[ 24]:err_code:0xa0404412, clock:0x268a7162  2020/06/27 21:06:42
ofst[ 28]:err_code:0xa0403034, clock:0x268a7162  2020/06/27 21:06:42
ofst[ 32]:err_code:0xa0404412, clock:0x268a71a1  2020/06/27 21:07:45
ofst[ 36]:err_code:0xa0403034, clock:0x268a71a1  2020/06/27 21:07:45
ofst[ 40]:err_code:0xa0404412, clock:0x268a7337  2020/06/27 21:14:31
ofst[ 44]:err_code:0xa0403034, clock:0x268a7337  2020/06/27 21:14:31
ofst[ 48]:err_code:0xa0404412, clock:0x268a7360  2020/06/27 21:15:12
ofst[ 52]:err_code:0xa0403034, clock:0x268a7360  2020/06/27 21:15:12
Click to expand...
What I find interesting from your errlog is that you have multiple errors at the same step, #40, namely --
* 3034 BE ERROR (but in the Fatal booting error)
* 4412 BE or RSX Error (But in the data error)

I don't think we've quite nailed the root cause of 3034 errors, but we do have at least 1 confirmed case of disappearing after a reflow. I haven't seen a 4412 error, but since it's in the "Data Error" category, it sounds like it's a communication issue between Cell and RSX? There's not many components between those two ( as seen on pages 29 and 30 of the service manual), pretty much just capacitors, maybe it's worth checking the resistance on those? At the very least, they should not show 0 or infinite resistance.
 
You must log in or register to reply here.

Similar threads

Back
Top