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

239 days in is right on schedule for YLOD in 90nm RSX consoles. However, I'm not sure what model you have?

2022 is the multiAV controller for analog output, but I wouldn't start worrying about that yet.

The bigger issue is the 1002. That's the NEC/TOKIN error. Wow we actually found one! If you'd like to learn more about the NEC/TOKINS and the YLOD I suggest starting here.
thanks for the quick response i have a cechj system and i also have a slim so not really worth trying to fix the nec/tokins for me might just keep it in the closet and one day if i get bored ill have a go at fixing it.. thanks for the help
 
thanks for the quick response i have a cechj system and i also have a slim so not really worth trying to fix the nec/tokins for me might just keep it in the closet and one day if i get bored ill have a go at fixing it.. thanks for the help
Yeah, non-BC models are cheap. No sense spending more to fix it than to replace it.

@M4j0r @joesaiditstrue @reapers2007
I do have a question for you, since you seem to know how to use the SYSCON advanced tool. I'm a noob when it comes to CFW. I just jailbroke and installed the PKG with advanced tools. I ran it and pressed left to the end of the list where the syscon option is. I pressed X to run it. The screen went black, console reset and XMB loaded. Cool, I assume something happened. Now where is the log? IDK what to do next...I'm such a noob! Do I need to FTP into a folder to find it? I'm guessing it generated a TXT file somewhere.

EDIT: Nevermind I figured it out. It automatically placed the errorlog onto my USB drive plugged into the USB port. How convenient! THX M4J0r, super easy!
 
Last edited:
Yeah, non-BC models are cheap. No sense spending more to fix it than to replace it.

@M4j0r @joesaiditstrue @reapers2007
I do have a question for you, since you seem to know how to use the SYSCON advanced tool. I'm a noob when it comes to CFW. I just jailbroke and installed the PKG with advanced tools. I ran it and pressed left to the end of the list where the syscon option is. I pressed X to run it. The screen went black, console reset and XMB loaded. Cool, I assume something happened. Now where is the log? IDJ what to do next...I'm such a noob! Do I need to FTP into a folder to find it? I'm guessing it generated a TXT file somewhere.

EDIT: Nevermind I figured it out. It automatically placed the errorlog onto my USB drive plugged into the USB port. How convenient! THX M4J0r, super easy!

It's super convenient that's for sure, assuming the error log is being reported correctly (@M4j0r any way we can get the timestamps fixed )

I just assumed most people who were buying those small boards for soldering to their PS3 were all using CFW, but I'm starting to notice that not as many people have jailbroken PS3s as I originally thought

The gentleman who you helped in this thread after me, I noticed something interesting about his error log. His Bringup count was over double what mine is, but he has only half the total runtime days accumulated that I did

Bringup = Power On?

So if I'm understanding that correctly, I've turned my system on way fewer times than he has (1178 vs 2837), but my average playtime per session is much longer (559 days vs 239 days)

So doing the crude math, my system was running for about 11 hours per restart, the other guys was a more realistic/acceptable 2 hours per restart

Well I did leave my PS3 running overnight on many occasions.....

Perhaps the YLOD isn't nearly as predictable based on runtime, but rather bringup count? Perhaps a higher frequency of turning the system on/off puts more stress on the power delivery than just how long the PS3 is running in total hours
 
Yeah, bringup is startup.

The runtime doesn't get recorded until shutdown. If the console is powered off unexpectedly (YLOD, power outage, DATA farm flips the power breaker, etc), the runtime won't get recorded and you'll have one fewer shutdowns each time. So lots of consoles end up with a way fewer shutdowns than bringups. If there is a larger difference, that is consistent with a console starting it's life in a DATA farm. Especially launch consoles. They were the most affordable super computer array you could buy in 2007.

His had 94 more bringuips than shutdowns, yours has 132. Here's the console I'm currently using:
Code:
becount
Bringup : 1776 times
Shutdown: 1760 times
Power-on: 70day 19hour 07min 26sec
I would consider that consistent with home use. It can just be how people use their machines. Some only watch a movie on it, so you see a 1.5-2h average. Gamers usually average more, but It's strange that you average so much. Honestly, I don't see how it's possible to average 11 hours/session. Are you a serious gamer? When you sit down to play do you devote half the day? Did you leave the console on for days at a time regularly? Kinda hard to see how that could add up.

The YLOD depends greatly on how the console is used and what causes the YLOD. I'm talking about BGA defects for that 150-300 day YLOD. Why that happens is still a bit of a mystery. Was is the design of the RSX that caused more flexing stresses, or a manufacturing defect on the assembly line because of the switch to LF solder. Maybe a combination of both. We do know that alot of work has been done since to mitigate heat on revisions and future sony products. SONY had heat problems on the PS3 and 4. They over engineered the cooling on the PS5 because of this. The new revision of PS5 that's coming out has a cost down heatsink. It has 300 grams less copper. Point being, we know something about the 90nm RSX design made it unreliable. The CPU does have issues too, but not anywhere close to as bad. PS4 has the BLOD, but it doesn't afflict as many consoles at the YLOD does the PS3. And SONY seems to have learned how to get chips that last longer. Maybe it's just better soldering or thermals. Only the engineers who model and simulate these chips would know.

I still think FCBGA is too unreliable for CPU/GPU's. I'd rather we went back to QFP or socketed wire-bonded PGA/LGA. Get rid of these solid connections without strain relief! No more solder bumps or BGA! They may have density/cost/impeedance advantages, but are too unreliable.
 
@RIP-Felix Your comment regarding DATA Farms piqued my interest. Like I said before, I wasn't the original owner and purchased it about a year after launch, 2007 July... I recall was when it was delivered. Of course I never got to see it's startup/shutdown or usage stats until I installed CFW about 7-8 months ago and it was already over 500 days

I wonder if mine was running Linux on a farm somewhere for a year before I bought it? That would be quite interesting

edit: Launch was Nov 2006, so I got it 8 months after launch, not quite a year
 
It's super convenient that's for sure, assuming the error log is being reported correctly (@M4j0r any way we can get the timestamps fixed )

I just assumed most people who were buying those small boards for soldering to their PS3 were all using CFW, but I'm starting to notice that not as many people have jailbroken PS3s as I originally thought

The gentleman who you helped in this thread after me, I noticed something interesting about his error log. His Bringup count was over double what mine is, but he has only half the total runtime days accumulated that I did

Bringup = Power On?

So if I'm understanding that correctly, I've turned my system on way fewer times than he has (1178 vs 2837), but my average playtime per session is much longer (559 days vs 239 days)

So doing the crude math, my system was running for about 11 hours per restart, the other guys was a more realistic/acceptable 2 hours per restart

Well I did leave my PS3 running overnight on many occasions.....

Perhaps the YLOD isn't nearly as predictable based on runtime, but rather bringup count? Perhaps a higher frequency of turning the system on/off puts more stress on the power delivery than just how long the PS3 is running in total hours
Well this still doesn't replace the proper serial connection with the adapter as you say... Not just because of requiring CFW but mostly because it requires the system to be powered on and working properly in the first place hehe.
Also there's more useful functions via UART beyond just seeing the errlog.

You just have the special case of intermittent problems or the kind of issues that don't exactly prevent the system from turning on. And this tool is especially useful for that!
Also useful for those people whose machines begin working again for "mysterious" reasons. Which is quite common actually. Then again often these same people may not really care to check after the fact. Now they have it easier if they actually want to know, before their issue comes back.

M4j0r did a great job. The timestamp thing isn't really his fault, so there's nothing to fix there.
This is because the PRAM battery was discharged or removed, causing the internal clock to reset the date and time to 2006.

But it's still interesting to mention this. for some time I was wondering how could we manually set this date and time properly to the correct date. I know that the internal command "getrtc"
Can be used to see the current value. And I'm sure we should be able to edit or update this somehow.
This internal value does not get updated from the XMB or anything. So I'm thinking the way to do it must be over UART.


Or just leave it as it is. There's probably reasons why they are making this difficult. We just like to mess with everything hehe.
 
@RIP-Felix Your comment regarding DATA Farms piqued my interest. Like I said before, I wasn't the original owner and purchased it about a year after launch, 2007 July... I recall was when it was delivered. Of course I never got to see it's startup/shutdown or usage stats until I installed CFW about 7-8 months ago and it was already over 500 days

I wonder if mine was running Linux on a farm somewhere for a year before I bought it? That would be quite interesting

edit: Launch was Nov 2006, so I got it 8 months after launch, not quite a year
The E model was released in August of 2007 in NA, so you're mixed up on the date. Maybe you got it in 2008?

Regardless, it could have been used as a linux server. They could stay on 24/7, only being shut off during an outage or error or for routine maintenance. Perhaps the entity that bought it decided to go with another solution after a year and sold it to you on e-bay. Let's say they put 365 days use on it. 559 - 365 = 194 days. That's more like 4.5 hours/day (dividing it by the number of shutdowns). A more reasonable number.

Still, it's hard to figure a scenario where the console was on 24/7 for a whole year! So the math still doesn't add up. Maybe your recollection of the dates is fuzzy. Regardless, yeah the usage time suggests the console was used for long durations of time before you got it, or you had lots of EPIC gaming sessions!
 
M4j0r did a great job. The timestamp thing isn't really his fault, so there's nothing to fix there.
This is because the PRAM battery was discharged or removed, causing the internal clock to reset the date and time to 2006.

Yeah, but what's with those 1999 dates? I thought they might be generated when the console has no errors in the log, but @joesaiditstrue had one at the end of his log too and it gave a 2006 date (what I would expect it to be). Could that be the Y2K bug @M4j0r...lol?
anybody able to help me with this error log system yellow lights when playing intense games

Firmware Version: 4.82 (50677)
Platform ID: CokE10
Hardware Config: 4E00FFFF0107BCBF
Syscon Fimware Version: 0E69.0001000400040002 (0001000400040002)
Bringup Count: 2837, Shutdown Count: 2743
Runtime: 239 Days, 2 Hours, 55 Minutes, 36 Seconds
Error Log
01: A0802203 Mon Aug 17 13:54:07 2020
02: A0801002 Mon Aug 17 13:54:07 2020
03: A0801002 Fri Aug 14 15:31:07 2020
04: A0801002 Sun Jul 5 09:51:11 2020
05: A0801002 Sat Jul 4 08:43:34 2020
06: A0801002 Mon Jun 29 12:29:21 2020
07: A0802022 Sun Nov 24 05:38:37 2019
08: A0802022 Sun Nov 24 05:38:35 2019
09: A0802022 Sun Nov 24 05:37:29 2019
10: A0802022 Sun Nov 24 05:35:16 2019
11: A0802022 Sun Nov 24 05:34:33 2019
12: A0802022 Sun Nov 24 05:26:21 2019
13: A0802022 Sun Nov 24 05:25:30 2019
14: A0802022 Sun Nov 24 05:23:26 2019
15: A0802022 Sun Nov 24 05:22:41 2019
16: A0802022 Sun Nov 24 05:19:20 2019
17: A0802022 Sun Nov 24 05:15:02 2019
18: A0801001 Fri Dec 31 23:59:59 1999
19: A0801001 Thu Feb 4 09:14:22 2010
20: A0801001 Fri Dec 31 23:59:59 1999
21: FFFFFFFF Fri Dec 31 23:59:59 1999
22: FFFFFFFF Fri Dec 31 23:59:59 1999
23: FFFFFFFF Fri Dec 31 23:59:59 1999
24: FFFFFFFF Fri Dec 31 23:59:59 1999
25: FFFFFFFF Fri Dec 31 23:59:59 1999
26: FFFFFFFF Fri Dec 31 23:59:59 1999
27: FFFFFFFF Fri Dec 31 23:59:59 1999
28: FFFFFFFF Fri Dec 31 23:59:59 1999
29: FFFFFFFF Fri Dec 31 23:59:59 1999
30: FFFFFFFF Fri Dec 31 23:59:59 1999
31: FFFFFFFF Fri Dec 31 23:59:59 1999
32: FFFFFFFF Fri Dec 31 23:59:59 1999
 
M4j0r did a great job. The timestamp thing isn't really his fault, so there's nothing to fix there.
This is because the PRAM battery was discharged or removed, causing the internal clock to reset the date and time to 2006.

Yeah, but what's with those 1999 dates? I thought they might be generated when the console has no errors in the log, but @joesaiditstrue had one at the end of his log too and it gave a 2006 date (what I would expect it to be). Could that be the Y2K bug @M4j0r...lol?
The PS3 firmware starts counting the time at 1st January 1970, the Syscon at 1st January 2000. I just add a fixed offsets to it. I didn't add any time zone handling to it, that's why some values might be off. Doing that would require much more work and I don't think it's worth the time. Syscon is doing some weird stuff with the RTC. For some errors Syscon sets the time to -1 which then corresponds to the last second in 1999.

But it's still interesting to mention this. for some time I was wondering how could we manually set this date and time properly to the correct date. I know that the internal command "getrtc"
Can be used to see the current value. And I'm sure we should be able to edit or update this somehow.
This internal value does not get updated from the XMB or anything. So I'm thinking the way to do it must be over UART.
Prototype consoles still have the "diag rtc_set YYMMDDhhmmssddHHS" command but that was removed before the retail release.

The E model was released in August of 2007 in NA, so you're mixed up on the date. Maybe you got it in 2008?
It says CokB10 so it's at least based on a COK-002. (see https://www.psdevwiki.com/ps3/Chassis_ID)
 
Yeah, but what's with those 1999 dates? I thought they might be generated when the console has no errors in the log, but @joesaiditstrue had one at the end of his log too and it gave a 2006 date (what I would expect it to be). Could that be the Y2K bug @M4j0r...lol?
Ahh, to be honest I didn't even notice that haha.
But yeah I'd say it's still nothing to worry about either.
Looks like it's just how the empty errors with empty date are being "translated" and that's why they make no sense.
These are not errors so they never happened. So they never got filled with real data. In other words, I'm guessing those date bytes are still all 0000 (or FFFF?) and the zero point (or -1 point) (or F point?) corresponds to that last second of 1999. (The last second of the last minute of the last hour of the last day of the last month of... The last year) (year 99)

I guess this should only show up in the systems where the error log isn't completely filled with errors yet. (Empty errors with empty date, being translated when there's really nothing to translate)

I was more referring to the internal clock of the syscon, which resets to 2006 as soon as the battery is disconnected or flat.
(Maybe that's simply the 0 point and the "empty" ones are just filled with F)

And maybe we could brute force edit this RTC value even if they removed our command? Hmm, or maybe not
 
Ahh, to be honest I didn't even notice that haha.
But yeah I'd say it's still nothing to worry about either.
Looks like it's just how the empty errors with empty date are being "translated" and that's why they make no sense.
These are not errors so they never happened. So they never got filled with real data. In other words, I'm guessing those date bytes are still all 0000 (or FFFF?) and the zero point (or -1 point) (or F point?) corresponds to that last second of 1999. (The last second of the last minute of the last hour of the last day of the last month of... The last year) (year 99)
Yes, the translation between the data shown to you via UART and the one which Syscon gives to CELL is also different, so it's hard to replicate the UART output 1:1.

I was more referring to the internal clock of the syscon, which resets to 2006 as soon as the battery is disconnected or flat.
(Maybe that's simply the 0 point and the "empty" ones are just filled with F)
It actually resets to 2000 and Syscon adds the 6 year offset - weird since they used the same syscon since 2004 which means they had to change the offset 2 times. I guess they did that because the PS2 Mechacon is based on the same architecture.

And maybe we could brute force edit this RTC value even if they removed our command? Hmm, or maybe not
The official RTC set procedure which is done at the factory is part of the Syscon Remarry process. You can also do that if you skip the "First blank the complete SPCR with hex FF. Then for the first 0x30 bytes write this:" step of "Case #2" on the https://www.psdevwiki.com/ps3/Remarry_Syscon guide.
 
Remove the RF shielding and plug the power supply in to the Motherboard directly. you can use a piece of cardboard to insulate. Then with power connected you can probe the various voltages around the board in the brief moments you have before it YLODs. A good analog meter can actually be very helpful here.

That's all very useful links and information! Thanks! (Well I have to remove your links as the forum believe they're spams)

About the PSU placement issue, I probably will go with alligator cramp + banana plug method to provide the 12V so that I can flip the board easily(described here: https://www.psdevwiki.com/ps3/Power_Supply). Just need to figure out how to connect the 5V connector... this shouldn't be a big problem.

I do have another working DIA-002 which should be a bit like this dead DIA-001. I'll probe some components to see if it has similar values. For now, the only thing I can tell is the two pull up resistors of the SMBus/I2C SCL/SDA line(THR_I2C_SCL and THR_I2C_SDA from the service manual of SEM-001, I know it's of different model :)), from the thermal sensor to the SYSCON chip are of different values(one for 3000ohm and the other is 2400ohm), which is weird but should be okay if they're just pull ups? From the service manual they should be both 3300ohm(R4083 & R4084)

AqND1Qv
https://imgur.com/gallery/deVhspK
deVhspK

https://imgur.com/gallery/AqND1Qv

The other theory from myself is the sensor data line from RSX might be broken. I check the die diagram of the RSX and it appears the D+/D- lines go from the RSX to the thermal sensor is at the edge of the chip(AW-12 and AY-12 https://www.psdevwiki.com/ps3/CXD2971-1GB), which I think could be vulnerable to bending due to the excessive heat, which can break solder points. So... might have to try solder / probe those two pins before they go into the thermal sensor, but no idea what kind of voltage pattern I should expect. If that's the culprit then pfffff reflow/reball is required I guess
 
For now, the only thing I can tell is the two pull up resistors of the SMBus/I2C SCL/SDA line(THR_I2C_SCL and THR_I2C_SDA from the service manual of SEM-001, I know it's of different model :)), from the thermal sensor to the SYSCON chip are of different values(one for 3000ohm and the other is 2400ohm), which is weird but should be okay if they're just pull ups? From the service manual they should be both 3300ohm(R4083 & R4084)
You can't trust the multimeter reading for resistors in circuit. You'd have to remove them first. Parasitic resistance from other components in the line can make it appear off. However, you can compare the relative resistance from a working board to know if it's ballpark. It it's just a pull up resistor, the all that matters is it's higher than the threshold voltage (which we don't really know). 2400ohms isn't far off from 3300. I suspect it's fine. I would be more worried about shorts or open lines.

The other theory from myself is the sensor data line from RSX might be broken. I check the die diagram of the RSX and it appears the D+/D- lines go from the RSX to the thermal sensor is at the edge of the chip(AW-12 and AY-12 https://www.psdevwiki.com/ps3/CXD2971-1GB), which I think could be vulnerable to bending due to the excessive heat, which can break solder points. So... might have to try solder / probe those two pins before they go into the thermal sensor, but no idea what kind of voltage pattern I should expect. If that's the culprit then pfffff reflow/reball is required I guess
You'd need an oscilloscope to see the I2C data signal from the RSX. If there's no data, there could be a break in the line. However, a multimeter would just see a voltage, it's not fast enough to see the pulses. A lack of voltage might be meaningful, I'm not sure. I imagine if it can't send data, it'd be low all the time. So that might be a way to see it.

Being able to check clocks and data signals are two advantages oscilloscopes have over a multimeter. An analog voltmeter might show some slight twitching or unique behavior tho. This is why they can be useful to "get the feel" for a circuit. They are cheap old school tech, but in that department they are quite useful. You don't get to know a circuit as intuitively with digital equipment. An oscilloscope is the more analytical approach and better for this kind of thing, but you can get by with analog meters with lots of practice. @botakompong's method comes to mind. I love my RIGOL DS1054z, but have mad respect for those with their finger on the circuit's pulse rocking analog meters. It's cool as hell!

Yes, that's a good observation. The edges of the chip experience the most thermal strain. @vyktormvmpay25 can attest to that. He showed a picture of oxidized corner pads on a console he reballed recently. The FlexIO data lines are on the outer edge between the RSX/CPU and that's the most common culprit for 3034/4xxx error. So yeah, perhaps thermal errors can be caused by BGA defects too. And perhaps it's more common than we previously thought.

It's a good hypothesis anyway. If your troubleshooting leads nowhere, then you'll have no choice than to test it and confirm the theory (reflow/reball).
 
That's all very useful links and information! Thanks! (Well I have to remove your links as the forum believe they're spams
Do you mean the schematics and voltage pictures stored on @vyktormvmpay25's share drive? Sometimes I get an HTTPS isn't available error, but it's fine if I ignore that. At least from the USA. IDK, maybe his share drive is blocked in your region. If so, VPN is your friend.
 
@feng_ye if chrome is failing to open http link you can use Internet explorer. BwE can access files from Australia so isn't my issue, may be different situation of dns.
I'm sorry did not reply more, quite busy with some glitch on ps4 and testing teensy 4.0.
That cloud drive is something 50 gb free from my Internet provider as bonus if you opt for 1gb connection Internet. Can't expect not to fail, they don't seem to have any problems inside country but outside may fail from time to time.
 
Do you mean the schematics and voltage pictures stored on @vyktormvmpay25's share drive? Sometimes I get an HTTPS isn't available error, but it's fine if I ignore that. At least from the USA. IDK, maybe his share drive is blocked in your region. If so, VPN is your friend.

@feng_ye if chrome is failing to open http link you can use Internet explorer. BwE can access files from Australia so isn't my issue, may be different situation of dns.
I'm sorry did not reply more, quite busy with some glitch on ps4 and testing teensy 4.0.
That cloud drive is something 50 gb free from my Internet provider as bonus if you opt for 1gb connection Internet. Can't expect not to fail, they don't seem to have any problems inside country but outside may fail from time to time.

I have no problem accessing those links, thanks for those tips. It's this forum's some type of bot rule that doesn't allow me to reply with quotes with links in it, probably because I'm a newcomer. I was quite confused at the time it shows a red warning message and says it contains spams, only goes away if I remove the links.
 
I have no problem accessing those links, thanks for those tips. It's this forum's some type of bot rule that doesn't allow me to reply with quotes with links in it, probably because I'm a newcomer. I was quite confused at the time it shows a red warning message and says it contains spams, only goes away if I remove the links.
Oh, that'll go away once you hit like 10 or so posts. It's some new user rule. You'll also be able to directly attach pictures then.
 
Just an observation/FYI.

I have been messing around with Evilnat 4.88 CFW for the last few days on PS3#7 (reballed/tantalums). I have been having all kind of noob mistakes as I learn how to transfer games and install them. The first mistake was trying to FTP over too many games at a time. After awhile the PS3 will stop transferring and 4-5 times it locked up and restarted. The errorlog records these events as 80 1001 in the errorlog!

So it appears that 1001 seems to happen when there are CPU/RAM errors that cause a freeze or system hang. I think it's more to do with the console not shutting down properly, because the console prompts me to scan/fix the HDD after each event. That's a software thing. So if you see 80 1001 errors in the errlog, don't be alarmed. It's probably just normal software instabilities or user error (like me overloading the CPU and system memory with too many transfers or noobing my way around CFW).

I should mention that PS3#7 does have a lot of CPU noise compared to other consoles I've tested. So it could be more unstable than most. I'm not sure about this. I noticed the noise rise after removing the CPU tokins and replacing them with my own array of tantalum/MLCC. More proof that tokins are better, if you can get away with using them. But the TaPol are pretty stable. It may just be my beta PCB design that's causing the excess noise. It's a beta for a reason! Jury's still out on that. Just thought I should mention it.

EDIT: it just happened to me again during an installation of a large game. I was using the SYSCON UART in the background and attempted to use becount, but it returned thermal data instead? I think that must have be webMAN-MOD's doing..IDK for sure tho. Anyway, in the middle of that at about 30% of the installation, the console just shut off without warning at all. No YLOD or beeps. Jut off to a solid red LED. Controller lost it's pair and wouldn't turn the console back on. I had to plug it in VIA USB. The HDD scan prompt greeted me when I PWR'd back on. The package install was corrupted, of course, and I deleted it. I'm currently trying again (53% in so far). Maybe it didn't like me messing with UART while it's installing a game? Or perhaps this is instability due to the noise I was talking about before.

EDIT 2: The install completed successfully. So I guess it may have been webman and/or the UART going on at the same time that messed it up.
 
Last edited:
Yes, the translation between the data shown to you via UART and the one which Syscon gives to CELL is also different, so it's hard to replicate the UART output 1:1.


It actually resets to 2000 and Syscon adds the 6 year offset - weird since they used the same syscon since 2004 which means they had to change the offset 2 times. I guess they did that because the PS2 Mechacon is based on the same architecture.


The official RTC set procedure which is done at the factory is part of the Syscon Remarry process. You can also do that if you skip the "First blank the complete SPCR with hex FF. Then for the first 0x30 bytes write this:" step of "Case #2" on the https://www.psdevwiki.com/ps3/Remarry_Syscon guide.
Here's something wierd. The SYSCON just keeps spitting out 2006 dates for me when the clock on console is set by the internet and correct. They should be reading 2021 on the errors I was getting in the last couple days and was talking about in my previous post.

By way of comparison here's the SYSCON's errorlog:
Code:
errlog
ofst[ 20]:err_code:0xffffffff, clock:0xffffffff
ofst[ 24]:err_code:0xffffffff, clock:0xffffffff
ofst[ 28]:err_code:0xffffffff, clock:0xffffffff
ofst[ 32]:err_code:0xffffffff, clock:0xffffffff
ofst[ 36]:err_code:0xffffffff, clock:0xffffffff
ofst[ 40]:err_code:0xffffffff, clock:0xffffffff
ofst[ 44]:err_code:0xffffffff, clock:0xffffffff
ofst[ 48]:err_code:0xffffffff, clock:0xffffffff
ofst[ 52]:err_code:0xffffffff, clock:0xffffffff
ofst[ 56]:err_code:0xffffffff, clock:0xffffffff
ofst[ 60]:err_code:0xffffffff, clock:0xffffffff
ofst[ 64]:err_code:0xffffffff, clock:0xffffffff
ofst[ 68]:err_code:0xffffffff, clock:0xffffffff
ofst[ 72]:err_code:0xffffffff, clock:0xffffffff
ofst[ 76]:err_code:0xffffffff, clock:0xffffffff
ofst[ 80]:err_code:0xffffffff, clock:0xffffffff
ofst[ 84]:err_code:0xffffffff, clock:0xffffffff
ofst[ 88]:err_code:0xffffffff, clock:0xffffffff
ofst[ 92]:err_code:0xffffffff, clock:0xffffffff
ofst[ 96]:err_code:0xffffffff, clock:0xffffffff
ofst[100]:err_code:0xffffffff, clock:0xffffffff
ofst[104]:err_code:0xffffffff, clock:0xffffffff
ofst[108]:err_code:0xffffffff, clock:0xffffffff
ofst[112]:err_code:0xffffffff, clock:0xffffffff
ofst[116]:err_code:0xffffffff, clock:0xffffffff
ofst[120]:err_code:0xffffffff, clock:0xffffffff
ofst[124]:err_code:0xffffffff, clock:0xffffffff
ofst[  0]:err_code:0xa0801001, clock:0x0be47303  2006/04/28 06:30:27
ofst[  4]:err_code:0xa0801001, clock:0x0be47416  2006/04/28 06:35:02
ofst[  8]:err_code:0xa0801001, clock:0x0be47bc1  2006/04/28 07:07:45
ofst[ 12]:err_code:0xa0801001, clock:0x0be47cc3  2006/04/28 07:12:03
ofst[ 16]:err_code:0xa0801001, clock:0x0be4a0af  2006/04/28 09:45:19
[mullion]$
>$

And here is the one generated by the tool:
Code:
Firmware Version: 4.88 (50731)
Platform ID: Cok14
Hardware Config: 00000000FFFFFFFF
Syscon Fimware Version: 0B8E.0001000000000006 (0001000000000006)

Bringup Count: 1755, Shutdown Count: 714
Runtime: 11 Days, 15 Hours, 20 Minutes, 26 Seconds

Error Log
01: A0801001  Fri Apr 28 09:45:19 2006
02: A0801001  Fri Apr 28 07:12:03 2006
03: A0801001  Fri Apr 28 07:07:45 2006
04: A0801001  Fri Apr 28 06:35:02 2006
05: A0801001  Fri Apr 28 06:30:27 2006
06: FFFFFFFF  Fri Dec 31 23:59:59 1999
07: FFFFFFFF  Fri Dec 31 23:59:59 1999
08: FFFFFFFF  Fri Dec 31 23:59:59 1999
09: FFFFFFFF  Fri Dec 31 23:59:59 1999
10: FFFFFFFF  Fri Dec 31 23:59:59 1999
11: FFFFFFFF  Fri Dec 31 23:59:59 1999
12: FFFFFFFF  Fri Dec 31 23:59:59 1999
13: FFFFFFFF  Fri Dec 31 23:59:59 1999
14: FFFFFFFF  Fri Dec 31 23:59:59 1999
15: FFFFFFFF  Fri Dec 31 23:59:59 1999
16: FFFFFFFF  Fri Dec 31 23:59:59 1999
17: FFFFFFFF  Fri Dec 31 23:59:59 1999
18: FFFFFFFF  Fri Dec 31 23:59:59 1999
19: FFFFFFFF  Fri Dec 31 23:59:59 1999
20: FFFFFFFF  Fri Dec 31 23:59:59 1999
21: FFFFFFFF  Fri Dec 31 23:59:59 1999
22: FFFFFFFF  Fri Dec 31 23:59:59 1999
23: FFFFFFFF  Fri Dec 31 23:59:59 1999
24: FFFFFFFF  Fri Dec 31 23:59:59 1999
25: FFFFFFFF  Fri Dec 31 23:59:59 1999
26: FFFFFFFF  Fri Dec 31 23:59:59 1999
27: FFFFFFFF  Fri Dec 31 23:59:59 1999
28: FFFFFFFF  Fri Dec 31 23:59:59 1999
29: FFFFFFFF  Fri Dec 31 23:59:59 1999
30: FFFFFFFF  Fri Dec 31 23:59:59 1999
31: FFFFFFFF  Fri Dec 31 23:59:59 1999
32: FFFFFFFF  Fri Dec 31 23:59:59 1999

They both agree on the date, but I'm not sure why it's not updating. I didn't check the RTC battery, but I did plug it back in. If it were dead it shouldn't be storing a date at all. But why is it not setting the correct date?
 
They both agree on the date, but I'm not sure why it's not updating. I didn't check the RTC battery, but I did plug it back in. If it were dead it shouldn't be storing a date at all. But why is it not setting the correct date?

You can check if the RTC system works by using the "getrtc" command. If it returns no error the RTC is fine.
If you want to correct the date you have to remarry syscon, but as long as the system firmware doesn't complain I wouldn't do that.
 

Similar threads

Back
Top