On Wed, 2004-06-02 at 11:03, Jay Miller wrote:
Thanks! I just did not know when to run it, but now I should be able to get it working.
did you get the lates version ? The ssh in LANL is broken today so I can't commit my working version to the CVS.
Ollie
-J
-----Original Message----- From: Li-Ta Lo [mailto:ollie@lanl.gov] Sent: Wednesday, June 02, 2004 12:08 PM To: Jay Miller Cc: LinuxBIOS Subject: Re: testbios info?
On Wed, 2004-06-02 at 06:40, Jay Miller wrote:
Can someone post a quick rundown on testbios?
I know that you get the vgabios from the card, and run that through testbios. But how do you get linuxbios to use the results?
Currently it is only used as a userspace program to init VGA cards after Linux is booted. After getting more test case and feedback, I will try to merge it in to LinuxBIOS.
The emulator will be one of the init/configure method of the generic VGA device driver.
Ollie
I'm missing something.
Thanks,
Jay Miller Actuality Systems, Inc. jmiller@acutality-systems.com
Linuxbios mailing list Linuxbios@clustermatic.org http://www.clustermatic.org/mailman/listinfo/linuxbios
* Li-Ta Lo ollie@lanl.gov [040602 19:09]:
On Wed, 2004-06-02 at 11:03, Jay Miller wrote:
did you get the lates version ? The ssh in LANL is broken today so I can't commit my working version to the CVS.
Are you sure it's a LANL problem? I've had problems with the CVS-via-SSH checkout the last few days as I had earlier with anonymous checkout. Only every one in ten attempts gets through, but I did not give up..
Stefan
On Wed, 2004-06-02 at 12:05, Stefan Reinauer wrote:
- Li-Ta Lo ollie@lanl.gov [040602 19:09]:
On Wed, 2004-06-02 at 11:03, Jay Miller wrote:
did you get the lates version ? The ssh in LANL is broken today so I can't commit my working version to the CVS.
Are you sure it's a LANL problem? I've had problems with the CVS-via-SSH checkout the last few days as I had earlier with anonymous checkout. Only every one in ten attempts gets through, but I did not give up..
They are both. I have problems to do anonymous pserver for some other sourceforge projects yesterday from my home. And today the netwrok guys at LANL added new restirctions for using SSH inside LANL.
Ollie
Stefan
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.
On Thu, 2004-06-03 at 02:56, Richard Smith wrote:
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.
The original emulator in xfree86 use the system's gettimeofdate to emulate the timer. Since we are not going to have that function in linuxbios, I removed it.
Probably we need an other way to emulate the timer.
Ollie
Any comments before I hack this in?
I'm off to bed.
On Thu, 3 Jun 2004, Li-Ta Lo wrote:
Probably we need an other way to emulate the timer.
can we just read the timer?
ron
On Thu, 2004-06-03 at 09:35, ron minnich wrote:
On Thu, 3 Jun 2004, Li-Ta Lo wrote:
Probably we need an other way to emulate the timer.
can we just read the timer?
ron
richard's point is that the emulator is much slower than the timer. The delay loop is facing overflow problem with the "emulated" io access to the "physical" counter.
Ollie
On Thu, 3 Jun 2004, Li-Ta Lo wrote:
richard's point is that the emulator is much slower than the timer. The delay loop is facing overflow problem with the "emulated" io access to the "physical" counter.
oops, sorry. Too much email this morning. I did not read his note carefully enough.
Actually I'm surprised that the emulator is that much slower than an old 8086.
OK, now what do we do ...
Ah, we could use the TSC, right?
ron
On Thu, Jun 03, 2004 at 03:56:29AM -0500, Richard Smith wrote:
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.
Right, it also sets counter mode 0, zero detection interrupt. Are there any hints of the code actually using the interrupt anywhere?
I'm guesing that what it uses for delays.
Indeed. It's the only way I know for measuring <ms without rdtsc.
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.
838.1ns is one tick, not a complete 16-bit rollover, right?
What I don't understand though was how this ever was reliable.
[..]
Consider the following:
[..asm..]
Am I missing somthing?
The resolution could be lowered.. Are there any writes to 0x40 setting a divisor? If not, then the snippet will simply not be reliable down to the exact iteration.
Since the code uses jb to detect when to stop looping the count doesn't have to be an exact match. Even if an extra tick passes, the loop will still end.
I don't think the timing is critical in any other way than that it should be as short as possible to keep the user happy, but with a minimum limit decided by hardware.
//Peter
what about this. Build a composite timer with the top X bits coming from TSC, and the bottom Y bits coming from the time-of-day counter. Would that work?
ron
Peter Stuge wrote:
On Thu, Jun 03, 2004 at 03:56:29AM -0500, Richard Smith wrote:
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.
Right, it also sets counter mode 0, zero detection interrupt. Are there any hints of the code actually using the interrupt anywhere?
Um... I don't know. What would I look for? I don't thing so but that does explain why linux whines about "too many timer interrutps" occurring.
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.
838.1ns is one tick, not a complete 16-bit rollover, right?
Yeah sorry. 838.1 ns is one tick. I said rollover which would be 50mS Re-looking at the delay routine I see I was mistaken as the delay routine counts ticks.
Looking at the delay routine is just confusing. There's a comment that says 4 bx counts equals .4290 * 4 or 2uS. So that tells me the VBios thinks the system timer must be running at 2.386 Mhz rather than the 1.19318 Mhz my PC hardware book claims.
All this tells me that I don't understand timer access in a modern system. The code as written just dosen't seem like it would work on a 4.77 Mhz XT.
The resolution could be lowered.. Are there any writes to 0x40 setting a divisor? If not, then the snippet will simply not be reliable down to the exact iteration.
Since the code uses jb to detect when to stop looping the count doesn't have to be an exact match. Even if an extra tick passes, the loop will still end.
I don't understand. The part I'm refering to is the
sub ax,dx neg ax
or ax,ax jnz delay_a
This will only skip the jump (and do the BX decrement) if ax is zero. For ax to be zero the result of the 2's complement subtraction must be zero or the when the 2 reads are the same number. But I just don't see how this would happen repeatably at .6us per ISA IO.
Ate the timer reads really and ISA IO? I guess if those reads are happening much faster then it would work. Where does the timer live now? int the northbridge perhpas? Thats could be the issue. If the northbridge responded to the IO it would happen at cpu clock rates and all would be well.
On Thu, 3 Jun 2004, Richard Smith wrote:
This will only skip the jump (and do the BX decrement) if ax is zero. For ax to be zero the result of the 2's complement subtraction must be zero or the when the 2 reads are the same number. But I just don't see how this would happen repeatably at .6us per ISA IO.
All I know is BIOS code sucks and it looks like VGA BIOS code is worse than BIOS code. IT's amazing that any of it ever worked at all.
ron
ron minnich wrote:
On Thu, 3 Jun 2004, Richard Smith wrote:
This will only skip the jump (and do the BX decrement) if ax is zero. For ax to be zero the result of the 2's complement subtraction must be zero or the when the 2 reads are the same number. But I just don't see how this would happen repeatably at .6us per ISA IO.
Hold up. I'm baked. Gotta get more sleep. The above is obviously wrong. Its should be when they differ by 2.
On Thu, Jun 03, 2004 at 03:32:58PM -0500, Richard Smith wrote:
Peter Stuge wrote:
On Thu, Jun 03, 2004 at 03:56:29AM -0500, Richard Smith wrote:
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.
Right, it also sets counter mode 0, zero detection interrupt. Are there any hints of the code actually using the interrupt anywhere?
Um... I don't know. What would I look for?
Someone writing a segment/offset pair to 0000:0020. (I.e. installing an interrupt handler for IRQ0/INT8.)
I don't thing so but that does explain why linux whines about "too many timer interrutps" occurring.
Yes, if the io accesses are let through the emulator to the real hardware, that's certainly the reason.
You could probably test this, I did some quick testing and it looks like Linux sets the timer divisor so that timer 0 runs at 1kHz. Verify this (grep 0: /proc/interrupts && sleep && grep) followed by a timed run of testbios. If there are extra interrupts on IRQ 0, the real hardware was touched.
[..]
Looking at the delay routine is just confusing.
I agree.
There's a comment that says 4 bx counts equals .4290 * 4 or 2uS. So that tells me the VBios thinks the system timer must be running at 2.386 Mhz rather than the 1.19318 Mhz my PC hardware book claims.
1193180Hz doesn't change, that's the 4.77MHz clock divided by four, your hardware book is correct. I used Ralf Brown's interrupt/port list to refresh my own memory.
All this tells me that I don't understand timer access in a modern system. The code as written just dosen't seem like it would work on a 4.77 Mhz XT.
It may not neccessarily do so. The M1 is a PCI bus chip, right? I can easily imagine that ATI didn't make the video BIOS XT compatible for a graphics controller targeted at newer/mobile/embedded systems.
[..snip..]
This will only skip the jump (and do the BX decrement) if ax is zero. For ax to be zero the result of the 2's complement subtraction must be zero or the when the 2 reads are the same number. But I just don't see how this would happen repeatably at .6us per ISA IO.
Hmm. Let's have another look at the code.
Ok. Pseudocode:
procedure delay(someunit) { bx=someunit dx=read_timer() do { ax=read_timer() ax=-(ax-dx) if(ax==0) bx=bx-(bx mod 2)-2 } while(ax<bx) }
It doesn't make a whole lot of sense, but eventually the loop will end, since -(the_original_timer-current_timer) always gets compared with the requested delay. If the (16bit) timer wraps, bx is decreased but that's not really neccessary for the loop to ever end.
Conclusion; it not a very precise delay, it's just a suitably short delay. :)
Ate the timer reads really and ISA IO?
At least they used to be, port accesses on 486/Pentium took forever and that's when I last did stuff like this and payed any attention to how long it took. :)
I guess if those reads are happening much faster then it would work. Where does the timer live now? int the northbridge perhpas? Thats could be the issue. If the northbridge responded to the IO it would happen at cpu clock rates and all would be well.
Sure, it's part of the northbridge, but all sorts of buses are there, I'd just put the timer where it has always been, on an ISA bus, to minimize breakage. Although, lately I guess ISA isn't included in chipsets, at least externally. LPC is handy for things like this and of course runs a lot faster at 33MHz.
//Peter
OK, I finally read this in detail and I'm sorry for my noise on this subject.
I think it would be useful to keep an 'emulated instruction count' in the emulator, and have a virtual timer that increments very X (pick a number) instructions. X can be constant across different architectures as we are somewhat divorced from time (it's an emulator).
The emulated timer would increment every emulated instruction count ticks.
Would this do it?
ron
ron minnich wrote:
OK, I finally read this in detail and I'm sorry for my noise on this subject.
I think it would be useful to keep an 'emulated instruction count' in the emulator, and have a virtual timer that increments very X (pick a number) instructions. X can be constant across different architectures as we are somewhat divorced from time (it's an emulator).
The emulated timer would increment every emulated instruction count ticks.
Would this do it?
Yes. I think it would. Got any ideas on the implementation? I'm ready to try an implement this.
On Thu, 3 Jun 2004, Richard Smith wrote:
Yes. I think it would. Got any ideas on the implementation? I'm ready to try an implement this.
in the main loop for instruction decode there is a single instruction dispatch function. Create a global counter (emulate_counter?) and increment it once each time the dispatch function returns.
You can in the emulator redirect I/O port access to a function. Write the code to handle read/write on those ports and use the emulate_counter to drive the clock value.
ron
ron minnich rminnich@lanl.gov writes:
You can in the emulator redirect I/O port access to a function. Write the code to handle read/write on those ports and use the emulate_counter to drive the clock value.
Let me ask this quick question. Does the emulator restrict port I/O to just the resources on a particular VGA device? If not that is something we need to do to implement to ensure we flush these kinds of issues into the open and ensure the emulator is portable.
Eric
Eric W. Biederman wrote:
You can in the emulator redirect I/O port access to a function. Write the code to handle read/write on those ports and use the emulate_counter to drive the clock value.
Let me ask this quick question. Does the emulator restrict port I/O to just the resources on a particular VGA device? If not that is something we need to do to implement to ensure we flush these kinds of issues into the open and ensure the emulator is portable.
No. It allows full access to all IO ports. Otherwise it would have never been able to get to the system timer.
So not only will it have to emulate x86 instructions it will have to emulate some of the generic x86 hardware setup.
Richard Smith rsmith@bitworks.com writes:
Eric W. Biederman wrote:
You can in the emulator redirect I/O port access to a function. Write the code to handle read/write on those ports and use the emulate_counter to drive
the clock value.
Let me ask this quick question. Does the emulator restrict port I/O to just the resources on a particular VGA device? If not that is something we need to do to implement to ensure we flush these kinds of issues into the open and ensure the emulator is portable.
No. It allows full access to all IO ports. Otherwise it would have never been able to get to the system timer.
I was afraid of that.
So not only will it have to emulate x86 instructions it will have to emulate some of the generic x86 hardware setup.
Exactly. But in this case emulation is more predictable than making certain your hardware is setup in a legacy conforming mode.
Eric
Eric W. Biederman wrote:
No. It allows full access to all IO ports. Otherwise it would have never been able to get to the system timer.
I was afraid of that.
So not only will it have to emulate x86 instructions it will have to emulate some of the generic x86 hardware setup.
Exactly. But in this case emulation is more predictable than making certain your hardware is setup in a legacy conforming mode.
Hey, I'm totaly in agreement with you. No convincing necessary. *grin*
It probally dosen't have to go all the way emulating a legacy PC enviroment but it looks like a few things will have to be dealt with. Restricting IO to legacy VGA registers and the allocated card IO locations is a good idea. That should flush out any other issues of this sort. There probally aren't that many though.
In other news I recompiled my VBIOS with the delay routine just doing a 'ret' rathen then all that crazy timer stuff and testbios now completes on my target rather than going into the infinite loop it did before.
Still don't get a signon message but it does do pretty much the same thing that ADLO+vbios does. H & V sync with the timeings correct for text mode but only a black screen. So thats some progress. Interesting to note that running the no-delay vbios on my desktop PCI works the same as with the delays.
On 8 Jun 2004, Eric W. Biederman wrote:
ron minnich rminnich@lanl.gov writes:
You can in the emulator redirect I/O port access to a function. Write the code to handle read/write on those ports and use the emulate_counter to drive the clock value.
Let me ask this quick question. Does the emulator restrict port I/O to just the resources on a particular VGA device? If not that is something we need to do to implement to ensure we flush these kinds of issues into the open and ensure the emulator is portable.
well, yes if you wish it to. That stuff is pretty configurable. Ollie is much more current than me on it -- he's hacking it.
ron
-
ebiederman＠lnxi.com -
Li-Ta Lo -
Peter Stuge -
Richard Smith -
ron minnich -
Stefan Reinauer