-----Original Message----- From: Richard Smith Sent: 29 December 2005 19:52
And there was much rejoicing.
Still un-answered is _what_ was trashing parts of the 0x0c0000 area. We have fixed the symptom but not the cause.
Just to add more meat to the knowledge about the Via vga bios, and about what 'might' be going on here:
We do know that the Via vga bios is not entirely 'self sufficient', and makes proprietory calls into the main BIOS through software interrupt 21
During Linuxbios boot and vga initialisation we cater for this by providing an interrupt 21 handler in the Linuxbios code
However I do believe that this bios also makes these int 21 calls during a mode set call, as I believe is done by the various fb drivers, and ceratinly by the Vesa X server. But of course once the kernel is booted the int 21 handler of Linuxbios will have vapourised, although the page 0 vectors to these functions still exist. Consequently any such call will end up wandering around random code, and it is highly probable that this is the cause of the corruption noted.
I have managed to trace the Vesa X server sufficiently to know that it crashes / locks up with its instruction pointer in the 0xf000 segment, where in theory there is no code under Linuxbios, but presumably there is with a stock bios.
Thus the epia M/MII/ML port is not currently VESA compatible - i.e. you can't do a bios call to set the current display mode.
That leaves us with native CLE266 chipset drivers. On my test bed I quite happily run X using the Via X driver for CLE266. I don't have a need for fbdev, and so can't vouch for that.
On my test bed I run either an old homebrew linux built using the Linux >From Scratch project, and more recently the current version of 'Damm Small Linux' (DSL). With the latter I had to download the full X server package to get the Via driver, and change configuration slightly to make sure that this driver was the one that ran rather than the default Vesa driver. Both of these setups use 2.4.x kernels, and I have no experience with 2.6.x.
To make Linuxbios VESA compatible would thus require Linuxbios to create a persistent int 21 handler in 16 bit code. It could be made persistent by creating it somewhere in the 0xf000 segment along with the various tables which it creates.
The int 21 handler itself is fairly trivial - it just seems to return certain values describing the environment in which it is running: - The type and speed of main memory - which in turn is used to limit the max resolution and refresh rate of the display so as not to hog main memory bandwidth on slower memory - The type of display chosen and saved in CMOS - CRT, TV, Flat Panel - The size of a flat panel etc.
The current int 21 handler simply returns hard coded values for these i.e. 266Mhz DDR ram, and CRT display only.
Unless anyone feels that they would like to add such a handler, I would thus recommend that folk stick with the native chipset drivers, and make sure that they are configured to not use Bios calls for setting the graphics mode.
Other mailings have suggested that the Via 1.1.16 vga bios does not work, whereas the 1.1.13 bios does. I suspect that Via have extended or changed their definition of the int 21 call between these two versions - Joy.
Nick Barker