[Cbe-oss-dev] Real Time Clock incorrect on PS3

Mauro Montenegro mauro.montenegro at gmail.com
Wed Mar 13 15:56:10 EST 2013


Hello Geert! Step :) Goodnight comment you ..
The console I own is a console model CECHL01 as I mentioned in one of my
previous posts. It has a 80 GB hard drive. And a memory of 16 MB NOR
.. although
that pc already know.
The following occurs .. speak for parties.
GameOS and OtherOS.
GameOS: In GameOS .. the time setting is correct. I can I configure it .. and
restart the console is kept current date. I can also turn it off, unplug
and then back on, and the hours are the internet without being connected to
the console.
You can set the time manually or through internet .. but not so .. Games
stop issuing the error 8001050F.
OtherOS: Well .. not exactly what it means OtherOS .. but for me it means
"Linux" (Fedora, Ubuntu, Red Ribbon, Yellow Dog, etc, etc, etc). In OtherOS
(let's call Red Ribbon) .. at startup .. I get the date and time of 2006. I
figure that will now be on February 4, 2006 or thereabouts. I know that the
console was launched in 2006 .. and from what I read .. launched the first
of January in Japan .. and then in the U.S. And as I also read .. to
console introduced in 2005. But what strikes me is that my console is on a
date less than the originally released.
Well .. The Red Ribbon is scheduled to update the date through internet .. but
it is like that only update a date volatile .. because when you turn off
the console .. or cold restart (not sure how you could do to restart :/
cold is to be able to .. but usually .. is that you must restart hot
because of seeing the legend that the system was abnormally shut and
recommends you perform a check of system files and database). Well .. the
issue is in the RTC .. I think that must be what is causing the problem .. as
far as I could see .. or rather .. by the information I sent a person who
calls r04drunner .. in console .. to run the comendo "hwclock --debug" on
Linux .. throws the correct date.
Deputy:

hwclock from util-linux 2.20.1
Using / dev interface to clock.
Last drift adjustment done at 1361389224 seconds after 1969
Last calibration done at 1361389224 seconds after 1969
Hardware clock is on UTC time
Assuming hardware clock is kept in UTC time.
Waiting for clock tick ...
/Dev/rtc0 does not have interrupt functions. Waiting in loop for time from
/ dev/rtc0 to change
Got clock tick ...
Time read from Hardware Clock: 2013/02/20 21:15:27
Hw clock time: 2013/02/20 21:15:27 = 1361394927 seconds since 1969
Wed 20 February, 2013 22:15:27 CET -0.772625 seconds

And what throws me my on my console is this even something already outdated:

root at redribbon:/home/ps3# hwclock --debug
hwclock from util-linux 2.20.1
Using / dev interface to clock.
Last drift adjustment done at 1360936111 seconds after 1969
Last calibration done at 1360936111 seconds after 1969
Hardware clock is on UTC time
Assuming hardware clock is kept in UTC time.
Waiting for clock tick ...
/Dev/rtc0 does not have interrupt functions. Waiting in loop for time from
/ dev/rtc0 to change
Got clock tick ...
Time read from Hardware Clock: 2006/01/11 23:46:31
Hw clock time: 2006/01/11 23:46:31 = 1137023191 seconds since 1969
Wed 11 Jan 2006 20:46:31 ART -0.118579 seconds

What catches my eye .. is that when you run this command .. the hwclock
--debug in some Linux x86 pc .. not see this legend.

/ Dev/rtc0 does not have interrupt functions. Waiting in loop for time from
/ dev/rtc0 to change

And do not be mean.
My intentions were to update the RTC .. put in the current date .. and with
that I would already be done.
But according Geoff .. can not act. What are the reasons why you can not
update the RTC? I do not know u_u
I've tried everything .. but nothing gave the result I expected.
The internal battery is perfect .. with 3.12 Volts.
In GameOS .. everything works perfect .. but it seems like that the console
has 2 or 3 internal clocks.
The CMOS, the RTC and the third which will not. With the third I mean that
when using the tool ps3vuart-tools package "./ps3dm SRTC set_time" sheds a
different clock to the RTC and GameOS time. Because I can set it to zero .. but
the RTC continues to maintain the date of 2006 and the current date GameOS
with 2013, but that time I started to zero .. (epoch) starts counting .. and
kept at shutdown or restart the console .. but does not affect the RTC.
It's a shame .. a shame for me .. it is as if I had half Console .. and not
an entire console .. and has no solution .. is somewhat sad, xq would
become more electronic waste and I think the PS3 still has a few more years
of life.
I appreciate very much the help of the two .. and the time spent to answer
:) I know SONY engineer Geoff is .. or was .. but not exactly what position
you occupy in the company or in which you are engaged.
But hey .. I'll still hopes to someday repair.
Greetings.

2013/3/9 Geert Uytterhoeven <geert at linux-m68k.org>

> On Fri, Mar 8, 2013 at 3:47 PM, Mauro Montenegro
> <mauro.montenegro at gmail.com> wrote:
> > > First, You have to Set the correct time under GameOS, As This will
> > > update the real RTC. That should fix your games.
> >
> > I've done both .. I seteado time manually and also through internet ..
> And
> > yet the game still throwing the error 8001050F. Only games that require
> the
> > installation of trophies .. as are the Kill Zone 2, MotorStorm and so
> many
> > more.
>
> This really starts to look like a hardware issue.
> Is the date always the same after a cold/warm reboot?
>
> > I hope to someday solve .. or at least get to be certain why it happened.
> > And to know what were the reasons that the RTC is in 2006.
>
> The PS3 was released in 2006.
>
> Gr{oetje,eeting}s,
>
>                         Geert
>
> --
> Geert Uytterhoeven -- There's lots of Linux beyond ia32 --
> geert at linux-m68k.org
>
> In personal conversations with technical people, I call myself a hacker.
> But
> when I'm talking to journalists I just say "programmer" or something like
> that.
>                                 -- Linus Torvalds
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ozlabs.org/pipermail/cbe-oss-dev/attachments/20130313/b672d46f/attachment.html>


More information about the cbe-oss-dev mailing list