Update on the warranty returned 65nm swap. Does not appear to be RSX related. It has new tantalums, but both signals appear unusually dirty. It is back to the original errors and freezing, with random 1001/1601/1701.
I am unable to find anything obviously off, and the dirty signals give me the feeling I'd be chasing a ghost or spending more time on it than it would be worth versus just starting the next one, so it's going to end up on a shelf and then recycled when I finally realize I'm never going to circle back around to it even when I'm not swamped with personal stuff. Unless someone wants it to do a deep dive on what's happening... Any takers? @RIP-Felix ?
I was mistaken about the sheet when I mentioned it in the Frankenstein thread a few weeks ago, it's #4 on page 135.
Hi every body
I managed to get a BC PS3 CECHA12 in working state that factory seal is not broken. the first thing I did to this device was a syscon errlog dump (just a bunch of 801001) so I upload the code here to see what your opinion is and any suggestions
Firmware Version: 4.88 (build 50731)
Platform ID: Cok14
Product Code: 00 8E
Product Sub Code: 00 01
Hardware Config: 00000000FFFFFFFF
Syscon Fimware Version: 0B8E.0001000000000006 (EEPROM: 0001000000000006)
Bringup Count: 1242, Shutdown Count: 1118
Runtime: 81 Days, 13 Hours, 44 Minutes, 15 Seconds
Error Log
01: A0801001 Mon Mar 23 14:05:01 2020
02: A0801001 Mon Mar 23 14:02:10 2020
03: A0801001 Mon Mar 23 13:57:47 2020
04: A0801001 Thu Apr 18 17:48:02 2019
05: A0801001 Sun Apr 2 02:06:49 2017
06: A0801001 Thu Oct 6 13:41:34 2016
07: A0801001 Thu Sep 8 16:19:50 2016
08: A0801001 Wed Jul 27 23:16:29 2016
09: A0801001 Sun Feb 28 23:33:06 2016
10: A0801001 Sun Feb 28 23:23:32 2016
11: A0801001 Wed Feb 24 15:42:44 2016
12: A0801001 Wed Feb 24 15:17:12 2016
13: A0801001 Mon Feb 1 22:19:52 2016
14: A0801001 Wed Nov 11 17:54:54 2015
15: A0801001 Tue Dec 2 10:41:37 2014
16: A0801001 Tue Jul 22 17:07:42 2014
17: A0801001 Sun Jun 8 10:34:01 2014
18: A0801001 Thu Nov 28 19:06:56 2013
19: A0801004 Wed Oct 23 17:21:13 2013
20: A0801001 Sat Mar 2 16:41:30 2013
21: A0801001 Thu Nov 3 15:06:42 2011
22: A0801001 Wed Aug 10 15:32:34 2011
23: A0801001 Tue Aug 9 12:28:53 2011
24: A0801001 Thu Jul 28 21:24:31 2011
25: A0801001 Sun Jul 10 17:18:35 2011
26: A0801001 Sun Jul 10 10:31:36 2011
27: A0801001 Wed Feb 16 20:00:45 2011
28: A0801001 Wed Feb 16 15:21:38 2011
29: A0801001 Sun Feb 13 14:13:09 2011
30: A0801001 Sun Feb 13 14:10:27 2011
31: A0801001 Sun Feb 13 13:56:25 2011
32: FFFFFFFF Tue Feb 8 19:33:39 2011
The dates are all different. Meaning to me they either are the caps failing or the console wasn't always turned off properly. Try playing TLOU to see if you can trigger a YLOD, if not I wouldn't worry about it until the caps are actually bad.
The dates are all different. Meaning to me they either are the caps failing or the console wasn't always turned off properly. Try playing TLOU to see if you can trigger a YLOD, if not I wouldn't worry about it until the caps are actually bad.
Thank you for your reply. I tested TLOU, the console ran normally and no YLOD happened. Temps were fine but I'm not going to stress it so much before a nice clean and a safe delid. Considering the less amount of working time of this console, does the difference between turn ON/OFF counts prove that 801001s are all related to force shutdowns?
Could you please explain more about the dates?
there is also a 801004. Is it related to PSU?
Thanks again.
Thank you for your reply. I tested TLOU, the console ran normally and no YLOD happened. Temps were fine but I'm not going to stress it so much before a nice clean and a safe delid. Considering the less amount of working time of this console, does the difference between turn ON/OFF counts prove that 801001s are all related to force shutdowns?
Could you please explain more about the dates?
there is also a 801004. Is it related to PSU?
Thanks again.
So if' it's stable in intense games, don't sweat it. The errors are probably a non-issue. Some local power grids are pretty spotty, so This is a pretty normal errorlog to see in a perfectly working console. It would be better to have no errors, but that's not likely for something this old.
So the 1004 can happen when the PWR is interrupted while the console was on. 1001 and 1004 can both happen when you flip the rocker at the back without gracefully shutting down first, like a power outage or disruption. It's also possible the PSU is going out. If you are opening it anyway, check if it's a ZSSR. They are less efficient anyway, so maybe consider replacing it with an APS-226 while you're in there.
Yours has a pretty close startup/shutdown ratio, so the 81 days of use should be accurate. Only 1 out of 10 times it wasn't shutdown properly.
My dia-001 has the 2110 error. I have removed the ic5001 and got another one off a broken board. The challenge is to solder it correctly since it's such a small chip. Hopefully this makes 2110 go away. Has anyone had success with 2110 and replacing the chip?
Hello, got a bit of an odd error I've not seen before. This is from a PS3 slim CECH-2003, the error code it keeps spitting out in the syscon is A0092114.
I have attached the bringup output and the error log. Any help would be appreciated!
I see in several places on youtube that this error (8002f147) is related to the BD drive.
After trying another BD drive, what else could be the problem?
Hello,
today I had free time and looked at the motherboard again, I compared with another working one and I don't see any differences.
With a hardware flasher, is it possible to install official firmware bypassing the error?
COK-001 board. GLOD, no video output on either HDMI or A/V, with or without HDD connected, won't cycle off for Safe mode without 4th beep and hard shutting down. Also DS3 controllers won't pair via USB, so I don't think it's RSX not displaying anything. Tried applying new paste to processers, swapping PSUs and controller DBs. No aval.
Any insights? Wish there was a GLOD thread but this seems to be the most relevant area for this to go.
This is strange. It says it's running a prerelease bootloader version (0.9.5). A build ID that's not on the wiki too.
It should be a GLOD if it's running a system FW lower than 2.30, or there about, which is when the 65nm got support. @vyktormvmpay25 ran into this with @mathieulh board. So what I don't understand is how you managed to get it working at all? It says it was sucessful and had 7 days of use at that point. It has 9 days of use now.
How can it have a pre-release bootloader on it? One with a build ID not on the dev wiki? I've ordered a FlashcatUSB Xport and TSOP-48 NAND programmer. I'll try dumping the NAND and flashing with FW 3.55 to see if that fixes the GLOD, but i don't get how this console ever worked with a 65nm in the first place if it was a prototype with low firmware.
This is strange. It says it's running a prerelease bootloader version (0.9.5). A build ID that's not on the wiki too.
It should be a GLOD if it's running a system FW lower than 2.30, or there about, which is when the 65nm got support. @vyktormvmpay25 ran into this with @mathieulh board. So what I don't understand is how you managed to get it working at all? It says it was sucessful and had 7 days of use at that point. It has 9 days of use now.
How can it have a pre-release bootloader on it? One with a build ID not on the dev wiki? I've ordered a FlashcatUSB Xport and TSOP-48 NAND programmer. I'll try dumping the NAND and flashing with FW 3.55 to see if that fixes the GLOD, but i don't get how this console ever worked with a 65nm in the first place if it was a prototype with low firmware.
This is strange. It says it's running a prerelease bootloader version (0.9.5). A build ID that's not on the wiki too.
It should be a GLOD if it's running a system FW lower than 2.30, or there about, which is when the 65nm got support. @vyktormvmpay25 ran into this with @mathieulh board. So what I don't understand is how you managed to get it working at all? It says it was sucessful and had 7 days of use at that point. It has 9 days of use now.
How can it have a pre-release bootloader on it? One with a build ID not on the dev wiki? I've ordered a FlashcatUSB Xport and TSOP-48 NAND programmer. I'll try dumping the NAND and flashing with FW 3.55 to see if that fixes the GLOD, but i don't get how this console ever worked with a 65nm in the first place if it was a prototype with low firmware.
I update all consoles to the latest official firmware release prior to stress testing, and the customer had it for 2 or 3 months before he started having problems.
I don't mess around with custom firmware on these beyond knowing enough to remarry drives and remove custom firmware, so anything exotic that happened to it from that direction would have been the customer's doing.
And you're saying in the future, I need to pay attention for Frankenstein's because I may need to hardware flash newer firmware to get them up and running if I encounter any with super low firmware?
And you're saying in the future, I need to pay attention for Frankenstein's because I may need to hardware flash newer firmware to get them up and running if I encounter any with super low firmware?
Yeah, I added a disclaimer to the tutorial about that. To be safe 3.55 should be considered the min FW for both. Tenchnically the 65nm should work below that (possibly 2.30), but we're not 100% sure how low and if that applies to every model revision. But 3.55 is a safe assumption and has been tested.
The there is a possibility the customer attempted to install an early FW. If they did the only way to recover from the GLOD is a FSM jig or HW flasher.
And you're saying in the future, I need to pay attention for Frankenstein's because I may need to hardware flash newer firmware to get them up and running if I encounter any with super low firmware?
Perhaps you would like to try playing with u COK-001 board that YLODs only under heavy load (example, sewers in TLOU). Would make an interesting example for this thread and the other nec/tokin thread
Update on the warranty returned 65nm swap. Does not appear to be RSX related. It has new tantalums, but both signals appear unusually dirty. It is back to the original errors and freezing, with random 1001/1601/1701.
I am unable to find anything obviously off, and the dirty signals give me the feeling I'd be chasing a ghost or spending more time on it than it would be worth versus just starting the next one, so it's going to end up on a shelf and then recycled when I finally realize I'm never going to circle back around to it even when I'm not swamped with personal stuff. Unless someone wants it to do a deep dive on what's happening... Any takers? @RIP-Felix ?
I was mistaken about the sheet when I mentioned it in the Frankenstein thread a few weeks ago, it's #4 on page 135.
I took him up on that offer and here it is on the bench...
He just sent me the MB, nothing else. My first impressions were this is the cleanest board I've ever seen. Board is immaculate and shiny. On the bench today we have a COK-001 with a 65nm CXD2982 RSX previously installed by @squeept. This was a warranty return that came back to him only a few months later. Squeept prides himself on quality. His repairs are of the top tier you can find, so I have little doubt the mod was done right! Here's the inspection sheet from this motherboard before it left the shop...
First up was to dump the errorlog. It's always nice when the previous guy already enabled internal SYSCON access so you can AUTH strait in...
Errors are as squeept described. Mainly 1001. One 1200 (CPU overheat), I assume from HS not being on during first test. Probably expected a YLOD, not a GLOD. There is a 1701/1601 in there too. All of these occurred at step# 80 (power on state), so the console doesn't have any power related issue that prevent it from making POST.
Becount is super low! Only 9 days of use.
After saving the log I cleared it and used the bringup command to start the console. It compleated Power On Sequencing and began the FW sequence that starts the Boot Loader. There were no errors that triggered a YLOD or that would indicate there's an issue with HW. The only one that I found confusing was the "[ERROR]: 0xb0002002 (FATAL) XDR Link not initilized."
It then proceeded to Dump the ITC, PTC, MIC, and XIO. I do not know how to make sense of the specific information they might contain. Perhaps someone more familiar with the bootloader can shed some light on whether or not this is useful.
Powerstate says everything is powered and available (Except PCI, which is only enabled when you load a PS2 game). Temps suggest the CPU is on and the RSX is idle.
Beyond that the only other interesting this I learned from the SYSCON "Boot Loader SE Version 0.9.5 (Build ID: 1634,16289, Build Data: 2006-09-21_19:11:09)." According to the PS3 Dev Wiki, this version (0.9.5) is not on CEX (Retail) models and this particular Build ID (1634) isn't listed there. But @DeadEnddid find it here.
Ok, so we have a console that Squeept updated before selling. Then it comes back to him running a pre-release Bootloader version?!
I attempted a SB UART, but couldn't get anything to output. I think it's not getting far enough into the bootloader for the SB to output anything, but I'm not %100 sure I did it correctly. This was the first time I've attempted the SB UART.
The only thing I can think of is the customer downgraded the console to a system firmware that is incompatible with the 65nm RSX. Anything below 2.15 - 2.30 (Not sure exactly) will cause a GLOD. @vyktormvmpay25 discovered this in a MB he Frankied for @mathieulh. He was able to get into Safe mode, but couldn't see anything.
I tried to get into safe mode, but it doesn't trigger. The procedure just turns the console off every time. No 1-beep, 2-beep, etc. However, safe mode isn't present on early system firmware, so if the customer did downgrade that could be normal. I'm not 100% sure that's what's going on here, but I have suspicions.
Can anyone confirm that the "Boot Loader Version" is updated when "System Firmware" is? Would the bootloder being at 0.9.5 confirm that they must have downgraded the FW below 2.30?
I've ordered a FlashcatUSB xPort and a TSOP-48 NAND Programmer.
@vyktormvmpay25@sandungas@M4j0r you guy's would have a better idea of how I should proceed. I think dumping the NAND and then attempting to upgrade to 3.55 would be the first place to start, but if you have any other suggestion I'm all ears.
This is strange. It says it's running a prerelease bootloader version (0.9.5). A build ID that's not on the wiki too.
It should be a GLOD if it's running a system FW lower than 2.30, or there about, which is when the 65nm got support. @vyktormvmpay25 ran into this with @mathieulh board. So what I don't understand is how you managed to get it working at all? It says it was sucessful and had 7 days of use at that point. It has 9 days of use now.
How can it have a pre-release bootloader on it? One with a build ID not on the dev wiki? I've ordered a FlashcatUSB Xport and TSOP-48 NAND programmer. I'll try dumping the NAND and flashing with FW 3.55 to see if that fixes the GLOD, but i don't get how this console ever worked with a 65nm in the first place if it was a prototype with low firmware.
Hey Felix, sorry to bother u during your busy day. May I know if is it possible for me to dm u somewhere to seek your direct help regarding ps3 repairs? (Thanks)
After saving the log I cleared it and used the bringup command to start the console. It compleated Power On Sequencing and began the FW sequence that starts the Boot Loader. There were no errors that triggered a YLOD or that would indicate there's an issue with HW. The only one that I found confusing was the "[ERROR]: 0xb0002002 (FATAL) XDR Link not initilized."
It then proceeded to Dump the ITC, PTC, MIC, and XIO. I do not know how to make sense of the specific information they might contain. Perhaps someone more familiar with the bootloader can shed some light on whether or not this is useful.
That means either the XDR RAM can't be initialized or it can't be run at full speed. You can get that error if the clock sources are configured wrong (e.g. from wrong CELL overclocking) or not working.
Beyond that the only other interesting this I learned from the SYSCON "Boot Loader SE Version 0.9.5 (Build ID: 1634,16289, Build Data: 2006-09-21_19:11:09)." According to the PS3 Dev Wiki, this version (0.9.5) is not on CEX (Retail) models and this particular Build ID (1634) isn't listed there. But @DeadEnddid find it here.
Ok, so we have a console that Squeept updated before selling. Then it comes back to him running a pre-release Bootloader version?!
The Syscon log is from lv0ldr which loads lv0. lv0 will then output over Syscon UART and South Bridge UART. lv0ldr Version 0.9.5 is not pre-release and bound to the console at the factory.
The only thing I can think of is the customer downgraded the console to a system firmware that is incompatible with the 65nm RSX. Anything below 2.15 - 2.30 (Not sure exactly) will cause a GLOD. @vyktormvmpay25 discovered this in a MB he Frankied for @mathieulh. He was able to get into Safe mode, but couldn't see anything.
Idk if you see those M4j0r, it was 3,15 I've dumped and installed 3554drex in fsm, once software installed and got XMB in fsm I just used that level 2 file to get out of fsm then up to 4842 drex and all fine. I found sur board with first 40nm rsx is on 3,20 min fw but I'll say stages of 355 is most compatible with fsm patches to use fsm old ways.
That means either the XDR RAM can't be initialized or it can't be run at full speed. You can get that error if the clock sources are configured wrong (e.g. from wrong CELL overclocking) or not working.
The Syscon log is from lv0ldr which loads lv0. lv0 will then output over Syscon UART and South Bridge UART. lv0ldr Version 0.9.5 is not pre-release and bound to the console at the factory.
The firmware isn't even loaded at that stage, lv0ldr would tell you if lv0 was loaded - it wasn't (since the RAM has to be initialized for that).