[coreboot] Memory clock cycles -> microseconds (us)
joe at settoplinux.org
Tue Jun 10 03:37:45 CEST 2008
> -----Original Message-----
> From: coreboot-bounces at coreboot.org [mailto:coreboot-bounces at coreboot.org]
> On Behalf Of Peter Stuge
> Sent: Monday, June 09, 2008 6:03 PM
> To: coreboot at coreboot.org
> Subject: Re: [coreboot] Memory clock cycles -> microseconds (us)
> On Mon, Jun 09, 2008 at 05:48:11PM -0400, Joseph Smith wrote:
> > On Mon, 9 Jun 2008 23:43:10 +0200, Peter Stuge <peter at stuge.se> wrote:
> > > On Mon, Jun 09, 2008 at 03:15:46PM -0400, Joseph Smith wrote:
> > >> How hard would it be to add a nanoseconds delay to delay.h?
> > >
> > > It would probably have to be a busy wait with compensation for
> > > the current CPU frequency.
> > I'm not sure what you mean, Peter?
> Busy wait is a loop of some number of NOP instructions, as opposed to
> relying on some CPU peripheral such as a timer to signal elapsed
> time. The number of NOP instructions has to be calculated from the
> current CPU frequency.
That seems more complicated than it needs to be. Here is what I am thinking:
JEDEC specifies what the wait/delay is supposed to be between memory
initialization steps. They specify/measure these in memory clock cycles.
Currently we just guess, and round up in microseconds (us) (I guess it is
better to wait too long than not enough). But, even if we wait 1/2 a
microsecond or more than needed on each step, That's 3 or 4 microseconds
longer than needed. See where I am going with this?
More information about the coreboot