alpha - generic_init_pit - why using RTC for calibration?

    we've a bunch of UP2000/UP2000+ boards (similar to DP264) with 666MHz

EV67 Alphas (we're building large Alpha cluster). And we're regulary see "HWRPB cycle frequency bogus" and the measured value for the speed in the range of 519 MHz - 666 MHz. And this value changes in this range from boot to boot. So why this happens???

So, the final question: why we're not using the aproach which is used by
x86 time.c? I.e. why not to use CTC channel 2 for calibration?

Quoted 1 line

    we've a bunch of UP2000/UP2000+ boards (similar to DP264) with

Quoted 2 lines

EV67 Alphas (we're building large Alpha cluster). And we're regulary see "HWRPB cycle frequency bogus" and the measured value for the speed in

Quoted 1 line

range of 519 MHz - 666 MHz. And this value changes in this range from

Quoted 1 line

to boot. So why this happens???

This is known problem with Cypress cy82c693 SIO. The RTC on this chip sometimes need a very long time (up to several minutes) to settle down after reset/power-up. But I thought it's fixed on newer systems with "ub" revision of the chip... :-(

Quoted 1 line

So, the final question: why we're not using the aproach which is

Quoted 1 line

x86 time.c? I.e. why not to use CTC channel 2 for calibration?

Good idea. The patch below works reliably on my sx164.

Ivan.

arch/alpha/kernel/time.c Fri Jun 29 20:58:09 2001 renamed from arch/alpha/kernel/time.c Mon Nov 13 06:27:11 2000 +60 -0

@@ -169,6 +169,63 @@ common_init_rtc(void)
  init_rtc_irq();
 }
 
+/*
+ * Calibrate CPU clock using legacy 8254 timer/counter. Stolen from
+ * arch/i386/time.c.
+ */
+
+#define CALIBRATE_LATCH (52 * LATCH)
+#define CALIBRATE_TIME (52 * 1000020 / HZ)
+
+static unsigned long __init
+calibrate_cc(void)
+{
+ int cc;
+ unsigned long count = 0;
+
+       /* Set the Gate high, disable speaker */
+ outb((inb(0x61) & ~0x02) | 0x01, 0x61);
+
+ /*
+ * Now let's take care of CTC channel 2
+ *
+ * Set the Gate high, program CTC channel 2 for mode 0,
+ * (interrupt on terminal count mode), binary count,
+ * load 5 * LATCH count, (LSB and MSB) to begin countdown.
+ */
+ outb(0xb0, 0x43); /* binary, mode 0, LSB/MSB, Ch 2 */
+ outb(CALIBRATE_LATCH & 0xff, 0x42); /* LSB of count */
+ outb(CALIBRATE_LATCH >> 8, 0x42); /* MSB of count */
+
+ cc = rpcc();
+ do {
+ count++;
+ } while ((inb(0x61) & 0x20) == 0);
+ cc = rpcc() - cc;
+
+ /* Error: ECTCNEVERSET */
+ if (count <= 1)
+ goto bad_ctc;
+
+ /* Error: ECPUTOOFAST */
+ if (count >> 32)
+ goto bad_ctc;
+
+ /* Error: ECPUTOOSLOW */
+ if (cc <= CALIBRATE_TIME)
+ goto bad_ctc;
+
+ return ((long)cc * 1000000) / CALIBRATE_TIME;
+
+ /*
+ * The CTC wasn't reliable: we got a hit on the very first read,
+ * or the CPU was so fast/slow that the quotient wouldn't fit in
+ * 32 bits..
+ */
+bad_ctc:
+ return 0;
+}
+
 void __init
 time_init(void)
 {

@@ -176,6 +233,9 @@ time_init(void)
  unsigned long cycle_freq, one_percent;
  long diff;
 
+ /* Calibrate CPU clock -- attempt #1. If this fails, use RTC. */
+ if (!est_cycle_freq)
+ est_cycle_freq = calibrate_cc();
  /*
  * The Linux interpretation of the CMOS clock register contents:
  * When the Update-In-Progress (UIP) flag goes from 1 to 0, the

Good idea. The patch below works reliably on my sx164.

Quoted 1 line

Good idea. The patch below works reliably on my sx164.

Reasonable. Here I've cleaned up time_init a tad as well.

r~

alpha/kernel/time.c Fri Jun 29 11:35:52 2001 renamed from alpha/kernel/time.c.orig Fri Jun 29 11:24:03 2001 +77 -16

@@ -169,6 +169,77 @@ common_init_rtc(void)
  init_rtc_irq();
 }
 
+/*
+ * Calibrate CPU clock using legacy 8254 timer/counter. Stolen from
+ * arch/i386/time.c.
+ */
+
+#define CALIBRATE_LATCH (52 * LATCH)
+#define CALIBRATE_TIME (52 * 1000020 / HZ)
+
+static unsigned long __init
+calibrate_cc_with_pic(void)
+{
+ int cc;
+ unsigned long count = 0;
+
+ /* Set the Gate high, disable speaker */
+ outb((inb(0x61) & ~0x02) | 0x01, 0x61);
+
+ /*
+ * Now let's take care of CTC channel 2
+ *
+ * Set the Gate high, program CTC channel 2 for mode 0,
+ * (interrupt on terminal count mode), binary count,
+ * load 5 * LATCH count, (LSB and MSB) to begin countdown.
+ */
+ outb(0xb0, 0x43); /* binary, mode 0, LSB/MSB, Ch 2 */
+ outb(CALIBRATE_LATCH & 0xff, 0x42); /* LSB of count */
+ outb(CALIBRATE_LATCH >> 8, 0x42); /* MSB of count */
+
+ cc = rpcc();
+ do {
+ count++;
+ } while ((inb(0x61) & 0x20) == 0);
+ cc = rpcc() - cc;
+
+ /* Error: ECTCNEVERSET */
+ if (count <= 1)
+ goto bad_ctc;
+
+ /* Error: ECPUTOOFAST */
+ if (count >> 32)
+ goto bad_ctc;
+
+ /* Error: ECPUTOOSLOW */
+ if (cc <= CALIBRATE_TIME)
+ goto bad_ctc;
+
+ return ((long)cc * 1000000) / CALIBRATE_TIME;
+
+ /*
+ * The CTC wasn't reliable: we got a hit on the very first read,
+ * or the CPU was so fast/slow that the quotient wouldn't fit in
+ * 32 bits..
+ */
+ bad_ctc:
+ return 0;
+}
+
+/* The Linux interpretation of the CMOS clock register contents:
+   When the Update-In-Progress (UIP) flag goes from 1 to 0, the
+   RTC registers show the second which has precisely just started.
+   Let's hope other operating systems interpret the RTC the same way.  */
+
+static unsigned long __init
+rpcc_after_update_in_progress(void)
+{
+ do { } while (!(CMOS_READ(RTC_FREQ_SELECT) & RTC_UIP));
+ do { } while (CMOS_READ(RTC_FREQ_SELECT) & RTC_UIP);
+
+ return rpcc();
+}
+
 void __init
 time_init(void)
 {

@@ -176,24 +247,15 @@ time_init(void)
  unsigned long cycle_freq, one_percent;
  long diff;
 
- /*
- * The Linux interpretation of the CMOS clock register contents:
- * When the Update-In-Progress (UIP) flag goes from 1 to 0, the
- * RTC registers show the second which has precisely just started.
- * Let's hope other operating systems interpret the RTC the same way.
- */
- do { } while (!(CMOS_READ(RTC_FREQ_SELECT) & RTC_UIP));
- do { } while (CMOS_READ(RTC_FREQ_SELECT) & RTC_UIP);
+ /* Calibrate CPU clock -- attempt #1.  */
+ if (!est_cycle_freq)
+ est_cycle_freq = calibrate_cc_with_pic();
 
- /* Read cycle counter exactly on falling edge of update flag */
- cc1 = rpcc();
+ cc1 = rpcc_after_update_in_progress();
 
+ /* Calibrate CPU clock -- attempt #2.  */
  if (!est_cycle_freq) {
- /* Sometimes the hwrpb->cycle_freq value is bogus.
-    Go another round to check up on it and see.  */
- do { } while (!(CMOS_READ(RTC_FREQ_SELECT) & RTC_UIP));
- do { } while (CMOS_READ(RTC_FREQ_SELECT) & RTC_UIP);
- cc2 = rpcc();
+ cc2 = rpcc_after_update_in_progress();
  est_cycle_freq = cc2 - cc1;
  cc1 = cc2;
  }
-

To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

Oleg,

The official kernel now carries Richard's version. Can you post a diff on linux-kernel against version 2.4.7-pre2 perhaps, which cleans up Richard's code to yours?
--

Jeff Garzik      | Thalidomide, eh?
Building 1024    | So you're saying the eggplant has an accomplice?
MandrakeSoft     |

(quoted diff) +1 -2

-#define CALIBRATE_LATCH        (52 * LATCH)
-#define CALIBRATE_TIME (52 * 1000020 / HZ)
+#define CALIBRATE_LATCH        0xffff

#define CLOCK_TICK_RATE 1193180 /* Underlying HZ */

Richard, thanks. But please use calibrate_cc version which I've submited
as a patch - it gives more accuracy with maximum latch we can ever use and

has cc's type changed to 'unsigned int' to prevent problems when rpcc overflows.

Oleg,

How is this relative to HZ, when you remove all references to HZ?

Quoted 3 lines

(quoted diff) +1 -2

-#define CALIBRATE_LATCH        (52 * LATCH)
-#define CALIBRATE_TIME (52 * 1000020 / HZ)
+#define CALIBRATE_LATCH        0xffff

[...]

Review

Quoted 2 lines

(quoted diff) +2 -0

+       /* and the final result in HZ */
+       return ((unsigned long)cc * CLOCK_TICK_RATE) / CALIBRATE_LATCH;

and in asm-alpha/timex.h,

Quoted 1 line

#define CLOCK_TICK_RATE 1193180 /* Underlying HZ */

--

Jeff Garzik      | Thalidomide, eh?
Building 1024    | So you're saying the eggplant has an accomplice?
MandrakeSoft     |

With both variants even on a 166MHz CPU you'll get above 1e-7 precision, which is way above accuracy of any crystal oscillator.

Quoted 3 lines

has cc's type changed to 'unsigned int' to prevent problems when rpcc overflows.

The only difference is that you'll have extra 'zap' instruction converting 'unsigned int' to 'unsigned long'.

return ((long)cc * 1000000) / CALIBRATE_TIME;

truncates the result to the MHZ because of the '* 1000000' statement (cc
is an int value, so you just loose the precision).

This works ok for x86,
because x86 uses this value with an accuracy to MHz, but this is not enough for Alphas (see gettimeofday - we're relies rpcc for calculation). Try to pass 'cycle=666000000' to your kernel and when run ntp - you're out of luck for clock sync.

But the most innacuracy comes from

#define CALIBRATE_TIME (5 * 1000020/HZ)

    (long)(int)0x80000000 != (long)(unsigned int)0x80000000, and

(long)(int)0x80000000 < 0 and you will get negative frequency value (yes we current boxes we're not overflowing, but let's look for the future).

Funny?
;-))

P.S. Ivan, you can reach me by dialing 938-6412 in Moscow.