860 RTC support

860 RTC support

[Steven Hein]

I've seen some discussions about real-time clocks lately, but (I think)
I scoured the list and can't find any basic information about how
to function the 860's real-time clock.  I'm using the real 2.4.3
kernel right now and I don't see that /dev/rtc would work.

Is there a working method (to read the RTC value at boot-time)?
I see references to 'hwclock', but from what I can tell that won't
work unless there's a /dev/rtc available (since 860 PPC isn't
supported natively by hwclock).

I apologize if I missed this info in the archives.  Any help would
be appreciated!

Thanks,
Steve

** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/

Re: 860 RTC support

[Dan Malek]

Steven Hein wrote:

> Is there a working method (to read the RTC value at boot-time)?

The MPC8xx real-time clock is implicitly managed in the kernel.
At boot time, the register is read and stored in the kernel
time.  Whenever the kernel time is updated, the hardware register
is also updated.  Since the 8xx is simply a 32-bit register
access with an update rate that matches the kernel time, I
chose to do it this way.

If you provide the appropriate crystal and battery to the 8xx,
you get a non-volatile time of day clock.

Most implementations seem to choose an external time of day clock
that is already managed by one of the RTC drivers.


	-- Dan

** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/

Re: 860 RTC support

[Steven Hein]

Dan Malek wrote:
>
> > Is there a working method (to read the RTC value at boot-time)?
>
> The MPC8xx real-time clock is implicitly managed in the kernel.
> At boot time, the register is read and stored in the kernel
> time.  Whenever the kernel time is updated, the hardware register
> is also updated.  Since the 8xx is simply a 32-bit register
> access with an update rate that matches the kernel time, I
> chose to do it this way.
>

Dan,

My question was poorly worded (because at that point I
didn't understand the whole picture.....).  I know that the
860's RTC on my board is working properly, that's not the issue.

My problem is this:   when I set the date via the "date --set"
command (which calls stime()) or by calling settimeofday() directly,
it doesn't result in the 860's RTC being updated.
Yes, do_settimeofday() gets called properly, but it never results
in ppc_md.set_rtc_time ==> m8xx_set_rtc_time getting called!
(The only place I see that called is in timer_interrupt in
arch/ppc/kernel/time.c, and it's only called if the STA_UNSYNC
bit is not set in timer_status.  do_settimeofday() results
in the STA_UNSYNC bit being set and I don't see how it gets
cleared.....).

I also looked at the other approach of configuring in /dev/rtc
and using hwclock, but the kernel won't boot with this
drivers/char/rtc.c
built in, and that doesn't look like it has 8xx support anyway.

In your response, you said "Whenever the kernel time is updated, the
hardware register is also updated.".  Is settimeofday()/stime()
the methods of updating the kernel time that you were talking about?

I know I'm missing something, as it sounds like this works for others,
but I'd greatly appreciate it if someone would clue me in!
(Again, I'm using the 2.4.3 kernel, if that's relevant).

Thanks,
Steve

** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/

Re: 860 RTC support

[Dan Malek]

Steven Hein wrote:

> My problem is this:   when I set the date via the "date --set"
> command (which calls stime()) or by calling settimeofday() directly,
> it doesn't result in the 860's RTC being updated.


Ahh, OK.  I'll take a look at this.  I thought it used to work in
older kernels.  It's on my list (or if someone else wants to take
a look and send a patch ...... :-).

> I know I'm missing something, as it sounds like this works for others,

As I recall, there are events that occur to update the RTC from
the kernel's notion of time, and one used to be some timeout.  Perhaps
after you set the time, if you wait for a while it may update the RTC.


	-- Dan

** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/

Re: 860 RTC support

[Dan Malek]

Dan Malek wrote:

> Ahh, OK.  I'll take a look at this.

Well, hell.....what I used to do is now considered "userland
business."  I guess the right thing to do is create a /dev/rtc
that will manage the MPC8xx RTC.  Sorry I missed this as the
kernel evolved.


	-- Dan

** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/

Re: 860 RTC support

[Steven Hein]

Dan Malek wrote:
>
>
> Ahh, OK.  I'll take a look at this.  I thought it used to work in
> older kernels.  It's on my list (or if someone else wants to take
> a look and send a patch ...... :-).
>

I looked through the source, and the difference between the 2.2.x
(2.2.13
and 2.2.14 mvista kernels) and the 2.4.3 kernel is that, in the
2.2.x kernel, the set_rtc_time function in timer_interrupt()
can only be called if (time_status & STA_UNSYNC) != 0, where
in the 2.4.x kernel set_rtc_time can only be called if the
(time_status & STA_UNSYNC) == 0.  As I see it, the STA_UNSYNC bit
is always set, so the RTC will never be updated!

At first I suspected just a bug in the PPC code regarding this bit,
but I glanced through the time code in some of the other arch's
(sh, sparc, arm, etc.) and saw the identical logic:
    - a call to do_settimeofday() *always* sets the
      STA_UNSYNC bit in time_status
    - the RTC is only updated when STA_UNSYNC is *not* set
And I don't see any way that STA_UNSYNC gets cleared (unless it's
cleared by adjtimex() or something like that......

>
> As I recall, there are events that occur to update the RTC from
> the kernel's notion of time, and one used to be some timeout.  Perhaps
> after you set the time, if you wait for a while it may update the RTC.
>

I had printk's in m8xx_set_rtc, and they never printed.
(even after an hour or more).  Again, it looks like it all boils down
to the value of the STA_UNSYNC bit in 'time_status' and how
that gets manipulated.


--
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Steve Hein (ssh@sgi.com)              Engineering Diagnostics/Software
Silicon Graphics, Inc.
1168 Industrial Blvd.                 Phone: (715) 726-8410
Chippewa Falls, WI 54729              Fax:   (715) 726-6715
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/

Re: 860 RTC support

[Tom Rini]

On Thu, Apr 19, 2001 at 03:16:00PM -0400, Dan Malek wrote:
>
> Steven Hein wrote:
>
> > My problem is this:   when I set the date via the "date --set"
> > command (which calls stime()) or by calling settimeofday() directly,
> > it doesn't result in the 860's RTC being updated.
>
> Ahh, OK.  I'll take a look at this.  I thought it used to work in
> older kernels.  It's on my list (or if someone else wants to take
> a look and send a patch ...... :-).

I think I understand the question/problem too.  We'll see what else I've
got to work on as well. :)  Just checking, Steven have you tried to
enable the "PPC_RTC" driver and gotten this same incorrect behavior?

--
Tom Rini (TR1265)
http://gate.crashing.org/~trini/

** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/

Re: 860 RTC support

[Steven Hein]

Tom Rini wrote:
>
> I think I understand the question/problem too.  We'll see what else I've
> got to work on as well. :)  Just checking, Steven have you tried to
> enable the "PPC_RTC" driver and gotten this same incorrect behavior?
>

Tom,

The only place I see references to PPC_RTC is in some of the PPC
"defconfig" files. I don't see any other places where that is
references in the 2.4.3 kernel.....

Steve

** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/

Re: 860 RTC support

[Steven Hein]

Dan Malek wrote:
>
> Well, hell.....what I used to do is now considered "userland
> business."  I guess the right thing to do is create a /dev/rtc
> that will manage the MPC8xx RTC.  Sorry I missed this as the
> kernel evolved.
>
I know this isn't under your control, but......

If this is the case (that setting the RTC is properly done through
/dev/rtc using hwclock, etc.), then doing a "date --set" no longer
sets the RTC, correct?  And it will never cause the RTC to be set?

.....Seems to me that separating the setting of the RTC from setting
the kernel/system time is a Bad Idea.....There's probably more to it
than that, or maybe "date --set" isn't considered a proper way to
manipulate the system clock anymore (maybe it never was   :).

--
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Steve Hein (ssh@sgi.com)              Engineering Diagnostics/Software
Silicon Graphics, Inc.
1168 Industrial Blvd.                 Phone: (715) 726-8410
Chippewa Falls, WI 54729              Fax:   (715) 726-6715
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/

Re: 860 RTC support

[Dan Malek]

Tom Rini wrote:

> .....Just checking, Steven have you tried to
> enable the "PPC_RTC" driver and gotten this same incorrect behavior?

Yep, Tom's right as usual :-).  If we can get this driver
configured, it is just a generic wrapper to the ppc_md rtc functions
and should work.

Thanks.


	-- Dan

** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/

Re: 860 RTC support

[Tom Rini]

On Thu, Apr 19, 2001 at 02:54:18PM -0500, Steven Hein wrote:
> Tom Rini wrote:
> >
> > I think I understand the question/problem too.  We'll see what else I've
> > got to work on as well. :)  Just checking, Steven have you tried to
> > enable the "PPC_RTC" driver and gotten this same incorrect behavior?
>
> Tom,
>
> The only place I see references to PPC_RTC is in some of the PPC
> "defconfig" files. I don't see any other places where that is
> references in the 2.4.3 kernel.....

Yes, I just noticed this myself when I went to try it on my rpx.
What you'll need to do is:
edit ./Makefile, and compile in drivers/macintosh/macintosh.o on
CONFIG_PPC, not CONFIG_ALL_PPC.
edit drivers/Makefile, and go into drivers/macintosh on CONFIG_PPC, not
CONFIG_ALL_PPC.
Finally, edit arch/ppc/config.in, and remove the test for !8xx around the
PPC_RTC question.  Then it'll either work or die at boot.  I'm not sure
yet :)  I should be able to test shortly tho.

--
Tom Rini (TR1265)
http://gate.crashing.org/~trini/

** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/

Re: 860 RTC support

[Tom Rini]

On Thu, Apr 19, 2001 at 02:54:18PM -0500, Steven Hein wrote:
> Tom Rini wrote:
> >
> > I think I understand the question/problem too.  We'll see what else I've
> > got to work on as well. :)  Just checking, Steven have you tried to
> > enable the "PPC_RTC" driver and gotten this same incorrect behavior?
>
> The only place I see references to PPC_RTC is in some of the PPC
> "defconfig" files. I don't see any other places where that is
> references in the 2.4.3 kernel.....

Okay, it doesn't _quite_ work (hwclock will oops) but hopefully it
won't be too hard to track down.  I'll try and get to it this afternoon
or tomorrow, or when time permits (!+@$*ing classes).  Patches greatly
appreciated. :)

--
Tom Rini (TR1265)
http://gate.crashing.org/~trini/

** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/

Re: 860 RTC support

[Steven Hein]

I'd love to help here, but I can't find the source
you're talking about!!

I've looked in the mvista's 2.2.14 kernel, and in the LSP's
for rpxlite and mbx860, plus the real 2.4.3 kernel, and I
see no reference to PPC_RTC in drivers/macintosh or
arch/ppc/config.in!

Where should I be looking........?



Tom Rini wrote:
>
>
> Yes, I just noticed this myself when I went to try it on my rpx.
> What you'll need to do is:
> edit ./Makefile, and compile in drivers/macintosh/macintosh.o on
> CONFIG_PPC, not CONFIG_ALL_PPC.
> edit drivers/Makefile, and go into drivers/macintosh on CONFIG_PPC, not
> CONFIG_ALL_PPC.
> Finally, edit arch/ppc/config.in, and remove the test for !8xx around the
> PPC_RTC question.  Then it'll either work or die at boot.  I'm not sure
> yet :)  I should be able to test shortly tho.
>
> --
> Tom Rini (TR1265)
> http://gate.crashing.org/~trini/

--
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Steve Hein (ssh@sgi.com)              Engineering Diagnostics/Software
Silicon Graphics, Inc.
1168 Industrial Blvd.                 Phone: (715) 726-8410
Chippewa Falls, WI 54729              Fax:   (715) 726-6715
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/

Re: 860 RTC support

[Tom Rini]

On Thu, Apr 19, 2001 at 03:22:35PM -0500, Steven Hein wrote:

> I'd love to help here, but I can't find the source
> you're talking about!!
>
> I've looked in the mvista's 2.2.14 kernel, and in the LSP's
> for rpxlite and mbx860, plus the real 2.4.3 kernel, and I
> see no reference to PPC_RTC in drivers/macintosh or
> arch/ppc/config.in!
>
> Where should I be looking........?

Er, one of the BK trees, or anything 2.4.x'ish that works normally
on your board.

--
Tom Rini (TR1265)
http://gate.crashing.org/~trini/

** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/

Re: 860 RTC support

[Steve Hein]

Tom Rini wrote:
>
> Er, one of the BK trees, or anything 2.4.x'ish that works normally
> on your board.
>
"Er..." is right! I have no idea where the HELL I was really looking
this
afternoon, but when I look in my 2.4.3 tree tonight, it's there all
right......  I'm going to take a look at it tomorrow.

Sorry for the extra noise!

Thanks,
Steve

** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/

Re: 860 RTC support

[Gabriel Paubert]

On Thu, 19 Apr 2001, Steven Hein wrote:

> I looked through the source, and the difference between the 2.2.x
> (2.2.13
> and 2.2.14 mvista kernels) and the 2.4.3 kernel is that, in the
> 2.2.x kernel, the set_rtc_time function in timer_interrupt()
> can only be called if (time_status & STA_UNSYNC) != 0, where
> in the 2.4.x kernel set_rtc_time can only be called if the
> (time_status & STA_UNSYNC) == 0.  As I see it, the STA_UNSYNC bit
> is always set, so the RTC will never be updated!
>
> At first I suspected just a bug in the PPC code regarding this bit,
> but I glanced through the time code in some of the other arch's
> (sh, sparc, arm, etc.) and saw the identical logic:
>     - a call to do_settimeofday() *always* sets the
>       STA_UNSYNC bit in time_status
>     - the RTC is only updated when STA_UNSYNC is *not* set
> And I don't see any way that STA_UNSYNC gets cleared (unless it's
> cleared by adjtimex() or something like that......

True, the logic is now correct and similar with other archs, this means
that the RTC is regularly updated when the clock is locked to another
reference (ntp mostly). The only difference with x86 is that the clock is
completely rewritten (not only the minutes and the seconds). This means
that you should know whether your RTC is UTC or not.

I'd rather recommend using UTC unless you have to dual-boot with some OS
which requires local time RTC like MacOS, but even then the situation is
not as bad as it seems since Mac also store the timezone which allows
to correct for this.

However, if you don't want to add the /dev/rtc driver to your system,
which I understand (I don't use it either) and still update the rtc
without a process like NTP, it is fairly trivial to write a utility which
clears the STA_UNSYNC bit through adjtimex(2), waits for a quarter of an
hour and sets again STA_UNSYNC. As long as all the PLL variables are zero,
it should do no harm.

But this is a kludge, a much cleaner way would be to define an additional
bit in time_status, like STA_UPDATE_RTC which would bypass the
last_rtc_update and STA_UNSYNC checks in do_timer_interrupt and clear the
flag as soon as the clock has been updated (within one second actually).
Then copying the system clock to the RTC becomes very simple:
- set the time with settimeofday() if necessary (date command)
- adjtimex(...) to get the current status bits
- adjtimex(ADJ_STATUS,...) to set the STA_UPDATE_RTC flag
- sleep one second
- adjtimex(...) to check that STA_UPDATE_RTC has been cleared,
  return error if not.

The required kernel patch would be minimal since you don't even need to
modify kernel/timer.c.

If you are really paranoid because the STA_UPDATE_RTC could be cleared by
another (root) user before the update takes place, you'll define another
mode (ADJ_UPDATE_RTC) that will set STA_UPDATE_RTC (defined as a read-only
flag) and will be cleared by the timer interrupt. But in this case you'll
have to modify kernel/timer.c also.

> I had printk's in m8xx_set_rtc, and they never printed.
> (even after an hour or more).  Again, it looks like it all boils down
> to the value of the STA_UNSYNC bit in 'time_status' and how
> that gets manipulated.

Yes, but the solution is not to try to change these mechanisms, they are
designed to work with ntp (the PPC code has long had some interesting
bugs, like rewriting the RTC just after reading it at boot, but I had to
shutdown ntp to get the RTC updated !) What you need is an additional
mechanism that allows you to access ppc_md.set_rtc_time() with minimal
kernel bloat.

For more info, man {hw,}clock and adjtimex([28]), info date and pointers
from therein.

	Regards,
	Gabriel.


** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/

Re: 860 RTC support

[Gabriel Paubert]

On Thu, 19 Apr 2001, Steven Hein wrote:

> I looked through the source, and the difference between the 2.2.x
> (2.2.13
> and 2.2.14 mvista kernels) and the 2.4.3 kernel is that, in the
> 2.2.x kernel, the set_rtc_time function in timer_interrupt()
> can only be called if (time_status & STA_UNSYNC) != 0, where
> in the 2.4.x kernel set_rtc_time can only be called if the
> (time_status & STA_UNSYNC) == 0.  As I see it, the STA_UNSYNC bit
> is always set, so the RTC will never be updated!
>
> At first I suspected just a bug in the PPC code regarding this bit,
> but I glanced through the time code in some of the other arch's
> (sh, sparc, arm, etc.) and saw the identical logic:
>     - a call to do_settimeofday() *always* sets the
>       STA_UNSYNC bit in time_status
>     - the RTC is only updated when STA_UNSYNC is *not* set
> And I don't see any way that STA_UNSYNC gets cleared (unless it's
> cleared by adjtimex() or something like that......

Right, I modified time handling to work like ther other archs when
rewriting the timer code, mostly to make it more robust, keeping time
despite bad-behaved code which masks interrupts long enough to lose ticks
(framebuffer at the time, it's claimed to be fixed now, and also printk on
serial consoles).

Indeed, only adjtimex can clear STA_UNSYNC. ntp does it as soon as it
acquires lock, don't ask me about adjtimex(8), I never used it.

> I had printk's in m8xx_set_rtc, and they never printed.
> (even after an hour or more).  Again, it looks like it all boils down
> to the value of the STA_UNSYNC bit in 'time_status' and how
> that gets manipulated.

Correct.

	Regards,
	Gabriel.


** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/

Re: 860 RTC support

[Gabriel Paubert]

On Thu, 19 Apr 2001, Steven Hein wrote:

> I know this isn't under your control, but......
>
> If this is the case (that setting the RTC is properly done through
> /dev/rtc using hwclock, etc.), then doing a "date --set" no longer
> sets the RTC, correct?  And it will never cause the RTC to be set?

stime/settimeofday never set the RTC on other archs, PPC was the
exception and as such the one to change.

> .....Seems to me that separating the setting of the RTC from setting
> the kernel/system time is a Bad Idea.....There's probably more to it
> than that, or maybe "date --set" isn't considered a proper way to
> manipulate the system clock anymore (maybe it never was   :).

It never was, and actually it's better like this. You have the RTC and the
kernel notion of time which are not necessarily the same. Explicit
synchronization is better than implicit one, especially for tests.

While it's over now, two years ago people were setting the clock at
1999/12/31 23:xx:xx to check for Y2K effects. In this case you didn't want
the RTC be updated to be able to use clock -s when tests are finished and
you're back to fixing problems (unless you enjoy wrong timestamps on your
files and confusing Make). Besides that some old RTC had problems on
their own AFAIR, but not updating them kept the problems separate.

Right now, for astronomical source tracking I am going to test leap second
handling, so I need to set the date just before midnight after setting the
right flags, run some code touching as few files as possible, and using
ntpdate to go back to normal while hacking. I certainly prefer the RTC not
to be updated back and forth for these tests (they involve kernel code, in
case of crash early rc scripts would be executed with the wrong date and
play havoc with my logs/whatever).

	Regards,
	Gabriel.


** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/

Re: 860 RTC support

[Steven Hein]

Tom Rini wrote:
>
>
> Okay, it doesn't _quite_ work (hwclock will oops) but hopefully it
> won't be too hard to track down.  I'll try and get to it this afternoon
> or tomorrow, or when time permits (!+@$*ing classes).  Patches greatly
> appreciated. :)
>

I don't have a patch put together yet, but I found the problem:
m8xx_get_rtc_time is an __init function in the 2.4.x tree.
Remove the __init and it works great!

--
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Steve Hein (ssh@sgi.com)              Engineering Diagnostics/Software
Silicon Graphics, Inc.
1168 Industrial Blvd.                 Phone: (715) 726-8410
Chippewa Falls, WI 54729              Fax:   (715) 726-6715
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/

Re: 860 RTC support

[Tom Rini]

On Fri, Apr 20, 2001 at 10:51:01AM -0500, Steven Hein wrote:
> Tom Rini wrote:
> >
> >
> > Okay, it doesn't _quite_ work (hwclock will oops) but hopefully it
> > won't be too hard to track down.  I'll try and get to it this afternoon
> > or tomorrow, or when time permits (!+@$*ing classes).  Patches greatly
> > appreciated. :)
> >
>
> I don't have a patch put together yet, but I found the problem:
> m8xx_get_rtc_time is an __init function in the 2.4.x tree.
> Remove the __init and it works great!

That would definatly do it, thanks.  I'll make the necessary changes and
pass this onto Cort.

--
Tom Rini (TR1265)
http://gate.crashing.org/~trini/

** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/