grub-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

TSC on coreboot (Re: [PATCH] High resolution time/TSC patch v3)


From: Robert Millan
Subject: TSC on coreboot (Re: [PATCH] High resolution time/TSC patch v3)
Date: Mon, 4 Aug 2008 01:53:48 +0200
User-agent: Mutt/1.5.13 (2006-08-11)

On Sun, Aug 03, 2008 at 09:48:16PM +0200, Robert Millan wrote:
> On Mon, Jul 28, 2008 at 10:05:33AM -0700, Colin D Bennett wrote:
> > +/* Calibrate the TSC based on the RTC.  */
> > +static void
> > +calibrate_tsc (void)
> > +{
> > +  /* First calbrate the TSC rate (relative, not absolute time). */
> > +  grub_uint64_t start_tsc;
> > +  grub_uint64_t end_tsc;
> > +  grub_uint32_t initial_tick;
> > +  grub_uint32_t start_tick;
> > +  grub_uint32_t end_tick;
> > +
> > +  /* Wait for the start of the next tick;
> > +     we'll base out timing off this edge. */
> > +  initial_tick = grub_get_rtc ();
> 
> Ah, I see the problem.  It calls grub_get_rtc() which in grub-coreboot is just
> a stub.
> 
> How about using the interval timer for calibration instead?

Here.  With this patch your code works on coreboot too.

Note:  AFAICT we can't calculate the epoch without RTC.  But then again, this
epoch is just as defined by the time BIOS enables RTC interrupts, so why not
define it ourselves?  I propose that we define epoch as the time in which our
TSC code is initialized.

If knowing the time in which BIOS was started is really useful, maybe we could
#ifdef it instead.  Though if it's not I'd prefer the simplicity.

-- 
Robert Millan

  The DRM opt-in fallacy: "Your data belongs to us. We will decide when (and
  how) you may access your data; but nobody's threatening your freedom: we
  still allow you to remove your data and not access it at all."

Attachment: tsc_coreboot.diff
Description: Text Data


reply via email to

[Prev in Thread] Current Thread [Next in Thread]