[OpenBIOS] milliseconds isn't unique.

[Mark Cave-Ayland]

On 08/06/14 13:02, BALATON Zoltan wrote:

>>> The interrupt routine is probably do-able in about 20 lines or less of
>>> PPC asm but it's beyond my current PPC-fu. It would be a good project
>>> for you though, and would probably fix the incorrect timing CIF
>>> milliseconds with -M mac99 :)
>>
>> There is no reason at all to use the decrementer and interrupts, with
>> all the problems inherent in that; just use the timebase, it's what
>> it's for.  The decrementer and timebase tick at the same frequency.
>
> That's what I thought and the current code already does that only using
> the wrong TBFREQ value. This could be easily fixed the same way as is
> done in arch/ppc/qemu/init.c:223:

Part of the motivation for the previous timer changes was to ensure that 
we only drop into C for the minimum time required for the 
architecture-specific code.

Currently that code was based on accessing a counter updated via 
interrupt, and given that this is the way it works on all other 
architectures then it makes more sense to do things this way. I 
appreciate that the accessing the timebase register directly is the more 
PPC way to do this, however there are other features such as alarms that 
aren't yet implemented in OpenBIOS which would require Forth routines to 
be invoked under timer interrupt control, and so if we're changing this 
I'd like to do it in a way that doesn't rule out this option later.

> /* From drivers/timer.c */
> extern unsigned long timer_freq;
>
> but probably it would be better to clean this up at the same time. The
> definition in drivers/timer.c:79 says:
>
> /*
>   * TODO: pass via lb table
>   */
> unsigned long timer_freq = 10000000 / 4;
>
> What is the lb table and where is it?

I would hazard a guess that "lb table" means "LinuxBIOS table" which I 
would imagine is similar to the QEMU fw_cfg interface?


ATB,

Mark.