Subject: Re: ntpd - does it work?
To: None <port-macppc@netbsd.org>
From: William O Ferry <woferry@iname.com>
List: port-macppc
Date: 03/14/2000 08:23:39
	For what it's worth, I cooked up a quick hack yesterday that
allows the value of ticks_per_sec to be hard-coded rather than pulled
out of the Open Firmware properties.  It also adds the i386-style
rtc_offset variable.  My PowerBook G3/Bronze running xntpd posts a syslog
every 384 seconds saying that it bumped the clock back 0.66 seconds
(really far off, 2.5 minutes per day?!?)  With this patch I was able to
build a kernel with the options:

options		RTC_OFFSET=480		# Minutes west of GMT
options		TIMEBASE=16695373       # Overrides Open Firmware timebase

	This timebase number has been dialed in through some
experimentation, I'm sure I'll be tweaking it a bit more..  =)

	With this patch, both variables rtc_offset and ticks_per_sec are
adjustable through gdb, so the values can be changed without recompiling
the kernel.  This can be done by:

gdb -write /netbsd
set timebase=XXXXXXXX
quit

	Where the X's are the number you want (same goes for rtc_offset).
Note that you may have to compile/install gdb manually.  =)  On most if
not all of the PowerPC's macppc supports I believe this number is 1/4th
of the bus clock, and the value of timebase-frequency in Open Firmware's
"dev /cpus/@0 .properties" should provide a good clue of what value to
start with (OF can display this number in decimal if you do something
like "fe502a .d", or whatever number timebase-frequency says with a " .d"
after it to show it in decimal.  On my machine OF reports 16666666 even
though the real value appears to be about 0.17% higher.

	So I know it's not the "right" solution for either rtc_offset
(there's a bug suggesting the right course of action) or for the timebase
frequency, but it's a quick way to get around both that I figured I'd make
available.  Note that if RTC_OFFSET or TIMEBASE aren't defined in the
kernel config it shouldn't cause any problems, I didn't test it though.
And with my patch once you set TIMEBASE it won't listen to Open Firmware's
value anymore (not that it would be difficult to redo things to look at
the Open Firmware value when TIMEBASE is 0 or something like that.

	Thanks.
                                                Will

--- clock.c.orig        Tue Mar 14 08:15:01 2000
+++ clock.c     Tue Mar 14 08:15:09 2000
@@ -47,7 +47,11 @@
 /*
  * Initially we assume a processor with a bus frequency of 12.5 MHz.
  */
+#ifdef TIMEBASE
+u_long ticks_per_sec = (u_long)TIMEBASE;
+#else
 static u_long ticks_per_sec = 12500000;
+#endif
 static u_long ns_per_tick = 80;
 static long ticks_per_intr;
 static volatile u_long lasttb;
@@ -80,7 +84,7 @@
                return;
        }
        clockinitted = 1;
-       time.tv_sec = rtc_time - DIFF19041970;
+       time.tv_sec = rtc_time - DIFF19041970 + rtc_offset * 60;
 
        deltat = time.tv_sec - base;
        if (deltat < 0)
@@ -104,7 +108,7 @@
        u_int rtc_time;
 
        if (clockinitted) {
-               rtc_time = time.tv_sec + DIFF19041970;
+               rtc_time = time.tv_sec + DIFF19041970 - rtc_offset * 60;
                adb_set_date_time(rtc_time);
        }
 #endif
@@ -189,8 +193,12 @@
        for (qhandle = OF_peer(0); qhandle; qhandle = phandle) {
                if (OF_getprop(qhandle, "device_type", name, sizeof name) >= 0
                    && !strcmp(name, "cpu")
+#ifndef TIMEBASE
                    && OF_getprop(qhandle, "timebase-frequency",
                                  &ticks_per_sec, sizeof ticks_per_sec) >= 0) {
+#else
+                   ) {
+#endif
                        /*
                         * Should check for correct CPU here?           XXX
                         */