testbios and the system timer
Richard Smith
rsmith at bitworks.com
Thu Jun 3 03:34:01 CEST 2004
I've been pouring over various logs from testbios and what my M1 Vbios
does in various conditions. Man what a bitch.
One thing I've found testbios dosen't handle properly is the 8254 system
timer. In numerious locations my Vbios is writing a 0x00 to IO 0x43 and
then does 2 reads from 0x40. So its latching the value of counter 0 and
then reading it out.
I'm guesing that what it uses for delays. Since I'm lucky enought to
have the Vbios source I did some grep work and found out that indeed it
uses timer 0 for delays. With preset delays ranging from 2uS all the
way to 50mS and a generic delay that delays CX number of 1mS loops.
The delay routine is written such that it polls for a rollover to mark
the increment of 838.1 ns. For this to happen the latch values must be
equal. In a system where the cpu instructions are running much faster
than one timer clock cycle I guess would not be much of a problem.
Of course the emulator totally munges this system since the elapsed
timer ticks between timer reads for the emulator is way longer than one
timer tick and its just blind chance when the timer delay routine reads
the value it needs.
What I don't understand though was how this ever was reliable. Don't
ISA cycles take ~.6us to complete? So 1 out and 2 ins to the legach
time thats 1.8us which should be 2 ticks so the routine should miss. I
must not fully understand the delay routine. (Yes I have permission to
post this snippit)
Consider the following:
DX = entry latch value
AX = sucessive latch values
BX = number of loops to do
enter:
read timer and store in DX
loop:
read the timer place result in AX
sub AX,DX
neg AX
or AX,AX
jnz check_loops
and bl,not 1
dec bx
dec bx
check_loops:
cmp ax,bx
jb loop
exit:
Am I missing somthing?
What i've noticed that the emulator causes the Vbios to get stuck in
some delay loops. Eventually it probally would exit but its currently
making my logs huge and causing the knashing of much teeth.
So I'm thinking that the emulator needs to intercept reads and writes to
the system timer and provide a fake timer that increments 1 tick per
some x instructions emulated. And hopfully the chips and the bioses
that need this won't mind that the actuall delay is longer than what was
requested.
Any comments before I hack this in?
I'm off to bed.
More information about the coreboot
mailing list