b8? Anybody know what that one is?
The vgabios itself has a bug in it. The b8 is an invalid INT # and what has happened is the vgabios code itself has crashed and is executing randomly. On the EPIA-M I had seen this problem on certain units where if the motherboard got too hot (but not really that hot) and you reboot, it would just sit there beeping forever with its onboard noisemaker. This was with the stock AWARD bios. The problem would go away if I set up a fan to blow on the motherboard and cool it down.
Under linuxbios the problem would manifest itself where during the vgabios init code you'd get into an endless loop of invalid INT callbacks. So it would stop the system from booting.
My "fix" was to only allow certain INT's in the callback and so if an invalid one happens, we just abort out of the VGA init code. This worked fine for our purposes, the vgabios had been able to init the hardware enough to get the system working, and life could go on. Note also when this endless INT callback thingy happened in linuxbios, if I blasted the fan on the motherboard to cool it down, that would fix the problem.
I really don't know how a bug in the vgabios could manifest itself only on certain motherboards and only when they get hot. But it's not impossible.
Note these int21 handler code was required for getting the vgabios working on the EPIA-M. Whether the thing is a case statement or a table is irrelevant, the case statement approach allows for endless customization. The point is the int21 callbacks must be implemented. That's how a black box like the vgabios can be delivered to VIA without source, yet VIA can integrate it into their AWARD bios. The INT 21 callbacks like 4F01 are for the vgabios to query the system to find out how much video ram has been reserved for the display (I default to 8M), what is the preferred output device, and other mysterious and poorly documented settings. The documentation I was going on was the CLE266 BIOS PORTING GUIDE from VIA, an NDA document. It is cryptic and incomplete (typical). It doesn't cover all of the INT21 callbacks that the vgabios makes use of.
Even if you boot off the AWARD bios, then run the vgabios with the emulator and make use of the AWARD bios to know what to return for these 4fxx INT21 callbacks, you're still left with the bug in the vgabios itself. I'm satisfied there is a bug there so I haven't spent any more time trying to improve the situation.
Long story short I don't know why Ignacio Verona's not getting VGA output on his EPIA-MII. However there is a reason for all the business in linuxbios with the unsupport int printing + aborting the vgabios execution and the code in the epia-m tree that handles the callbacks, so don't start thinking about ripping it out unless you really know what you're doing.
-Dave
* Dave Ashley linuxbios@xdr.com [040518 02:39]:
Note these int21 handler code was required for getting the vgabios working on the EPIA-M. Whether the thing is a case statement or a table is irrelevant, the case statement approach allows for endless customization.
So, in an award setup this is provided by award bios rather than being setup by the video bios itself? Sounds like a specific issue of Via onboard graphics in this case then.
Thus the way it is implemented is perfectly fine, except that the int21 handler has to be advanced to cope with all the AX values fed into it. I suggest also adding a default case to notify the user about unimplemented values for AX.
Stefan
-
Dave Ashley -
Stefan Reinauer