[coreboot] Memory clock cycles -> microseconds (us)
Tom Sylla
tsylla at gmail.com
Tue Jun 10 07:02:45 CEST 2008
>> 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?
It really can't be less complicated, but a lot of the work is already
done. Take a look at delay_tsc.c, which uses the tsc for delays (which
is a little bit nicer than counting NOPs) It does the tsc calibration
vs. the PIT (or even vs. port 80s) to get the CPU frequency. delay_tsc
has udelay now, but could reasonably easily have ndelay too. Precision
in the 10s of ns should be possible.
Peter's point is that it probably does not matter too much. Even if you
rounded up 5 individual delays to 1 usec each, that is only 5us. You can
reclaim a lot of it, but it may be more work than it is worth.
More information about the coreboot
mailing list