Article View: comp.sys.nsc.32k
Article #1546Re: Fix to ICM3216 w/ UoTBSD4.2 clock problem
From: Mark Funkenhauser
Date: Fri, 27 Jan 1989 01:38
Date: Fri, 27 Jan 1989 01:38
87 lines
3529 bytes
3529 bytes
In article <509@hocpa.UUCP> rusty@hocpa.UUCP (M.W.HADDOCK) writes:
>
> ... it appears that I've found a fix for the rtc_clock. My patches
>are for the file "/usr/sys/16k/clock.c" and you'll need to recompile/relink
>your kernal! The symptom I was seeing (yours might differ but I can't see
>how) was the console displaying
>
> rtc_clock: Off by 86400 seconds!!!
>
>Anyhoot, here's the patch to /usr/sys/16k/clock.c (or /sys/16k/clock.c).
>====
>
>% diff clock.c.old clock.c
>151c151,152
>< *rtc->rtc_csr = RTCCSR_24HOUR;
>---
>> /* *rtc->rtc_csr = RTCCSR_24HOUR; I know SysVR2R2 does this too
>> but it doesn't seem necessary since we do it RSN */
Yes it does! See below.
>154c155
>< *rtc->rtc_csr = RTCCSR_24HOUR | (gmtp->tm_year % 4);
>---
>> *rtc->rtc_csr = RTCCSR_24HOUR | ((gmtp->tm_year & 3) << 2);
>243c244
>< tim = (365 * y) + ((y - 1) / 4);
>---
>> tim = (365 * y) + ((y + 1) / 4);
>253c254
>< tim += (((i + 1) * 306) / 10) - ((y & 3) ? 64 : 63);
>---
>> tim += (((i + 1) * 306) / 10) - (((y+2) & 3) ? 64 : 63);
=====
I concur (well almost).
I spent last night fixing it ( sans the SysVR2R2 src ).
I would have fixed it sooner but I wanted the data sheet on the clock chip
before changing the code.
You almost got it right.
Line 151 (see above) MUST REMAIN. (i.e. *rtc->rtc_csr = RTCCSR_24HOUR; )
DO NOT comment it out.
The data sheet for the clock chip says that
you cannot set the 12/24 hour clock mode in the csr register at the
*same* time as setting the leap year stuff.
Therefore you must write to *rtc->rtc_csr twice!
(* There's a lesson here somewhere *)
Since RTC_CENTURY and RTC_STARTDATE are defined and used,
I prefer the following so that you can see how the algorithm works
and that if if these constants are ever changed (not too likely),
the bug won't re-occur:
tim = (365 * y) + (( (y + (RTC_STARTDATE & 3) - 1) )/ 4);
and
tim += (((i + 1) * 306) / 10) - (((y + (RTC_STARTDATE & 3)) & 3) ? 64 : 63);
>Oh, in case there are source code differences, I bought my
>BSD (binary license #2) around Feb-March of 1987 so it's possible that newer
>versions of the distribution tape (WERE THERE ANY???) may already have this
>fixed. If so, please let me know about that too!
I don't think there was more than 1 distribution tape.
-----------
By the way, does anyone shutdown their system on a regular basis ?
(i.e. every nite) and if so, has anyone had trouble with the date
when the machine is rebooted ?
I have, and it looks like the 12/24 hr bit in the csr register toggles
on power-off (or power-on).
Unix sets it up to be 24 hr mode, but on power-up, the chip is in 12 hr mode.
It could be the battery but all the other data in the chip registers seem ok.
-------------------------------------------------------
Mark Funkenhauser {decwrl,ihnp4}!utcsri!funke
CSRI funke@csri.toronto.edu
University of Toronto
-------------------------------------------------------
Technical Details
Message-ID:
<89Jan26.203842est.4327@turing.toronto.edu>Path:
arc1-ca.pugleaf.net!utzoo!utgpu!jarvis.csri.toronto.edu!turing.toronto.edu!funkeReferences:
<509@hocpa.UUCP>Show Full Headers
Complete Article Headers
Newsgroups: comp.sys.nsc.32k Path: arc1-ca.pugleaf.net!utzoo!utgpu!jarvis.csri.toronto.edu!turing.toronto.edu!funke From: funke@turing.toronto.edu (Mark Funkenhauser) Subject: Re: Fix to ICM3216 w/ UoTBSD4.2 clock problem Message-ID: <89Jan26.203842est.4327@turing.toronto.edu> Keywords: BSD ICM clock fix Organization: /usr/local/lib/organization References: <509@hocpa.UUCP> Date: Thu, 26 Jan 89 20:38:42 EST