PS3 B01 troubles of a different kind

ElGris said:
It's a disgrace for a console that imo is the best looking model Sony ever made.

On the topic, there're a lot of threads made by users asking on how to going up from a very old firmware version to a newer one. You didn't do your homework, but it's not your fault. The previous and post behaviour of your console is a clue (GLOD with countdown), and pretty obvious if you ask me.

That 1001 you see on syscon could be related to a bad tokins change, or bga damage when you replaced them. It's gonna be hard to recover this one.
Click to expand...
It definitely sucks that this console is down for the count but I've been messing with it for over a year off and on now and I dont plan on giving up. The B01 is my favorite looking console out of all of them and I'd really like to get this one working again.

I'm going to order more caps of a different brand and try swapping them in to see if things get any better. I'd rather not scavenge any from my other boards as they're ylod but they're still 100% intact.

And I didn't look up updating firmwares because its never given me issue in the past going from a low to a high number FW. But now I know I guess.

Sent from my SM-G965U using Tapatalk
 
Coro said:
i found an old post by @DeViL303. i don't know anything about it.



if you think the update actually wrote any files, then i would try to get into recovery mode one time. worth a shot.
Click to expand...
I really haven't got the slightest clue if it wrote any files as it's been so long since this issue arose and well it's only staying on for around 40 to 50 seconds.

Sent from my SM-G965U using Tapatalk
 
Look, if the console stills does the same as it did post "brick", I mean, stays for seconds on GLOD, just leave it like that and start seeing info for unbricking methods on old fats. You need to buy a teensy++ 2.0

It's something like this:

 
RCWD21 said:
I really haven't got the slightest clue if it wrote any files as it's been so long since this issue arose and well it's only staying on for around 40 to 50 seconds.

Sent from my SM-G965U using Tapatalk
Click to expand...
Hook up tri-state, ?....probably watch it burn up I don't know ?
 
RCWD21 said:
I've got a little kit made up for delidding, no razor blade needed [emoji16]

Sent from my SM-G965U using Tapatalk
Click to expand...

Sorry but off topic. What kit did you use? Been wanting to do this to a BC unit I have sitting here. Just do not want to screw it up if it can be avoided.
 
IMG_20181223_110522.jpg
IMG_20190425_093717.jpg
ElGris said:
Look, if the console stills does the same as it did post "brick", I mean, stays for seconds on GLOD, just leave it like that and start seeing info for unbricking methods on old fats. You need to buy a teensy++ 2.0

It's something like this:

Click to expand...
getting a good dump should rule out any firmware problems?
 
Yugonibblit said:
View attachment 37398 View attachment 37399 getting a good dump should rule out any firmware problems?
Click to expand...
I'm not sure. But by getting a good dump you can notice if something is corrupt in the firmware aspect I believe.

I also have a super slim mobo with the exact same behaviour as this B01, the problem is it doesn't seem to be a firmware failure, because I took a NOR sample of it and it shows no anomalies (when something is wrong littlebalup's script tells you what's going on).

Meaning that the issue is somewhere else.I didn't try a reballing on that Cell yet, but it could show us some light to the problem. Syscon in this mobo shows only "FFFF"s, and that's wierd. @vyktormvmpay25 says the Cell could be dead. Maybe he can help with the revival using teensy since he has a long history with PS3s repairing.

I still believe that if the console was functioning COMPLETELY NORMAL before the update, then it could be a firmware issue.
 
ElGris said:
I'm not sure. But by getting a good dump you can notice if something is corrupt in the firmware aspect I believe.

I also have a super slim mobo with the exact same behaviour as this B01, the problem is it doesn't seem to be a firmware failure, because I took a NOR sample of it and it shows no anomalies (when something is wrong littlebalup's script tells you what's going on).

Meaning that the issue is somewhere else.I didn't try a reballing on that Cell yet, but it could show us some light to the problem. Syscon in this mobo shows only "FFFF"s, and that's wierd. @vyktormvmpay25 says the Cell could be dead. Maybe he can help with the revival using teensy since he has a long history with PS3s repairing.

I still believe that if the console was functioning COMPLETELY NORMAL before the update, then it could be a firmware issue.
Click to expand...
Yes I agree, is why I suggested to make a dump. This would rule out everything and at least give a good direction of diagnostic. Syscon diagnostic is good thing also.imo the system has hardware problems. Dead cpu,bga,etc. Tantalums should be 4 for each tokin imo.
 
Wait I can't see bringup log. Usually if we run bringup and looking at that log we understand is is brick or dead rsx, if he tries to go on recovery mode and it passes from 2 beeps and control paired wired with one red, is just dead rsx. No hdd or bdrom need to be connected. Usually I clean all errors in syscon and create new ones then run bringup semi assembled unit to see what voltages failed or if rsx is dead.
A ps3 deformation of connection with cell/rsx is always going to show issue after a while on right temperatures, maybe in middle of update? Heard many people happen those years back, they don't deal with ps3 anymore.
This is happened to good technicians by simply exchange of thermal paste.
 
Last edited:
atreyu187 said:
Sorry but off topic. What kit did you use? Been wanting to do this to a BC unit I have sitting here. Just do not want to screw it up if it can be avoided.
Click to expand...
I use a set of these painters knives, #1 specifically along with plastic razor blades for removing the hardened thermal paste.
9bbd7c3fe8a246722c93c57de42b16ec.jpg


Sent from my SM-G965U using Tapatalk
 
ElGris said:
Look, if the console stills does the same as it did post "brick", I mean, stays for seconds on GLOD, just leave it like that and start seeing info for unbricking methods on old fats. You need to buy a teensy++ 2.0

It's something like this:

Click to expand...
I already have a teensy, a 360 clip AND a tsop socket. I just need to pull the nand chips to get a dump since the socket isn't wanting to make contact with the chip on the board still.

I'm starting on that currently since I'll either need to remove the chips or use more pressure on the board to seat the socket further.

If there is an issue however with the dump how do I go about fixing that?

Sent from my SM-G965U using Tapatalk
 
ElGris said:
I'm not sure. But by getting a good dump you can notice if something is corrupt in the firmware aspect I believe.

I also have a super slim mobo with the exact same behaviour as this B01, the problem is it doesn't seem to be a firmware failure, because I took a NOR sample of it and it shows no anomalies (when something is wrong littlebalup's script tells you what's going on).

Meaning that the issue is somewhere else.I didn't try a reballing on that Cell yet, but it could show us some light to the problem. Syscon in this mobo shows only "FFFF"s, and that's wierd. @vyktormvmpay25 says the Cell could be dead. Maybe he can help with the revival using teensy since he has a long history with PS3s repairing.

I still believe that if the console was functioning COMPLETELY NORMAL before the update, then it could be a firmware issue.
Click to expand...
Yes, this console was working completely normally before the update except the bluray drive not reading discs which is why I swapped lasers with a known good working one.

Sent from my SM-G965U using Tapatalk
 
I just want to see that bringup log before jumping on dumps.
Syscon have a magic way to recover from bad updates. I've got it few times, David (Computer Booter) got it few times live. We just went to recovery and reinstall fw from there.
If is a hw problem and in same time corruption of nand/nor, after hw problems are fixed syscon can recover some unexpected bad updates. Not those when we already patch and we do not know if is hw problem or brick.
 
Last edited:
vyktormvmpay25 said:
I just want to see that bringup log before jumping on dumps.
Syscon have a magic way to recover from bad updates. I've got it few times, David (Computer Booter) got it few times live. We just went to recovery and reinstall fw from there.
If is a hw problem and in same time corruption of nand/nor, after hw problems are fixed syscon can recover some unexpected bad updates. Not those when we already patch and we do not know if is hw problem or brick.
Click to expand...

Ive posted this in the syscon thread as well and RIP Felix is looking into the string but I'm not sure when I'll hear back on that. Here's the full string though.

>$ 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 -> 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 THERM] NOTIFY_MODE CMD
[SERV NOTIF] CONTROL_LED
[SERV NOTIF] RING_BUZZER
[SERV NOTIF] CONTROL_LED
[SERV THERM] NOTIFY_MODE CMD
[SERV NVS] READ CMD
[SERV NVS] WRITE CMD
[SERV DEVPM] CONTROL_PCI_BUS_POWER_STATE CMD
[SSM] state: 0400 -> 0500
[POWSEQ] AV Backend Letup
[SSM] ssmCb_AfterBeOn() called.
[SSM] Shutdown mode ... req_wake_src = 00000274, ctxt=00/00
[SSM] Shutdown mode : syspm_stat=00000000/00000000
[POWSEQ] PowerSeq_Letup called.
[SSM] state: 0500 -> 0000
(PowerOff State)
[mullion]$
 
So I have my teensy hooked up and all I get is " Pinging Teensy... Ping failed (expected v0.65, got v0.63) Closing serial device... Done."

I'm not fully set up to remove the chip from the board so I'm currently stuck with using the nand clip.

Sent from my SM-G965U using Tapatalk
 
Usually python is getting issues, use teensy on older python and Windows 7, teensy2++ is bit obsolete and I could make it work with nand/nor on Windows 10. Worked well for a while with Windows 10 for Sysglitch then after few windows updates did not work. So Windows 7 and python with right modules should be fine.
Also speed of com port în dev manager should be 115200 for teensy
 
vyktormvmpay25 said:
Usually python is getting issues, use teensy on older python and Windows 7, teensy2++ is bit obsolete and I could make it work with nand/nor on Windows 10. Worked well for a while with Windows 10 for Sysglitch then after few windows updates did not work. So Windows 7 and python with right modules should be fine.
Also speed of com port în dev manager should be 115200 for teensy
Click to expand...
I have a whole drive just for Win 7 and I'm getting the exact same error. Not really sure what's going on now and I'm not the greatest with computers so any help would be greatly appreciated

Sent from my SM-G965U using Tapatalk
 
if pyserial and pythom 2.7.18 is intalled,teensy loader was programmed with right .hex file is impossible to fail ,
also if you already have syscon running, teensy it must work for sure,same dependencies and modules are used, not good at explaining software side ,ill wait for someone else to explain it well.
cant remember if teesy need to be attached to ic in order to read.i couldnt find anything better then this where is explained how is done and show hw/soft sides well in same time.
he is patching and writing patchs fsm 355 blind method but you shoul stop after read,some devs here need to check if your dumps are good enough.
'file(script-nand).py comX ' should work unless right com of teensy isnt used.
 
vyktormvmpay25 said:
if pyserial and pythom 2.7.18 is intalled,teensy loader was programmed with right .hex file is impossible to fail ,
also if you already have syscon running, teensy it must work for sure,same dependencies and modules are used, not good at explaining software side ,ill wait for someone else to explain it well.
cant remember if teesy need to be attached to ic in order to read.i couldnt find anything better then this where is explained how is done and show hw/soft sides well in same time.
he is patching and writing patchs fsm 355 blind method but you shoul stop after read,some devs here need to check if your dumps are good enough.
'file(script-nand).py comX ' should work unless right com of teensy isnt used.
Click to expand...
I'm using python 2.7.2 (what was hot linked in the dev wiki for the teensy stuff) and pyserial 2.5. They don't show any signs of being installed incorrectly or incomplete.

I'm using an external 3.3v supply.

Do you think I should try 2.7.18 instead of 2.7.2 though? I don't think it would make much of a difference.

Sent from my SM-G965U using Tapatalk
 
You must log in or register to reply here.

Similar threads

Back
Top