[LinuxBIOS] any chance to get X fbdev driver to work ?

[Christian Sühs]

Hey, and Happy X-Mas for all

For non working Bootsplash with vesafb and LinuxBios I use the Viafb 
from Epia2 patch Kernel 2.4.25. Now Bootsplash works, with a little 
trick in the bootsplash sources :D

But I'm not able to bring up a XServer with fbdev as driver. The system 
hangs without any errors. It seems the problem is the viafb inside the 
Kernel. Unfortunatly, I have the same problem with orginal Bios.
Furthermore, the X via driver does not work with the LinuxBios system.
I get an VGA_Bios checksum failure. With original Bios it works.

I have had a look on the X Via driver sources. The file called 
via_bios.c (search for checksum)
It seems the routine looks on 0xc0000 for a valid vga_bios, all other 
checks before are verified as true. Only the last check fails.

I have tried to start X without Bios Callbacks, but fail.

Is there any solution.

It should be a valid bios on 0xc0000, the checksum routine is a loop 
about 65536 bytes. the result must be zero.

As I create the vga bios, I have fill up the rest with OO to 65536. Is 
that the problem? Should I fill up with FF?

chris

[Christian Sühs]

Sorry,

here is a bit from the file


Bool VIAGetBIOSTable(VIABIOSInfoPtr pBIOSInfo)
{
    VIAModeTablePtr pViaModeTable = pBIOSInfo->pModeTable;
    unsigned char   *pBIOS = NULL, *pRom, *pTable, *pFPanel, *pLCDTable, *pSuptTable;
    unsigned char   *pRefreshTableStart;
    unsigned char   *pRefreshIndexTable;
    unsigned char   *pRefreshTable;
    unsigned char   numSuptPanel, numEntry;
    unsigned short  tableSize;
    int             romSize;
    int             i = 0, j, k, m, sum;


    DEBUG(xf86DrvMsg(pBIOSInfo->scrnIndex, X_INFO, "VIAGetBIOSTable\n"));

    if (!(pBIOS=xcalloc(1, 0x10000)))  {
        ErrorF("Allocate memory fail !!\n");
        return FALSE;
    }

    if (xf86ReadBIOS(0xC0000, 0, pBIOS, 0x10000) != 0x10000)  {
        pBIOSInfo->UseBIOS = FALSE;
        xfree(pBIOS);
        ErrorF("Read VGA BIOS image fail !!\n");
    }
    else {
        if (*((CARD16 *) pBIOS) != 0xAA55) {
            pBIOSInfo->UseBIOS = FALSE;
            xfree(pBIOS);
            ErrorF("VGA BIOS image is wrong!!\n");
        }
        else {
            romSize = *((CARD8 *) (pBIOS + VIA_BIOS_SIZE_POS)) * 512;
            pRom = pBIOS;
            sum = 0;

            for (i = 0; i < romSize; i++) {
                sum += *pRom++;
            }

            if (((CARD8) sum) != 0) {
                pBIOSInfo->UseBIOS = FALSE;
                xfree(pBIOS);
                ErrorF("VGA BIOS image is wrong!! CheckSum = %x\n", sum);
            }
        }
    }

[Richard Smith]

Merry x-mas to you as well.  Hopefully Santa will bring you some
working bios code. *grin*
> else {
>             romSize = *((CARD8 *) (pBIOS + VIA_BIOS_SIZE_POS)) * 512;
>             pRom = pBIOS;
>             sum = 0;

What is it getting here?  Bios extensions have a size parameter in the
same area as the signature.  Offset 2. (Right after the 0xaa55) its
the length in 512 byte chunks.  So make sure this number is correct
for your image size.   Does the factory bios have the same values as
your LB image?

For your fill.  The unerased value of a ROM part is 0xFF.  So using
0xFF as a fill value is probally a good idea.

--
Richard A. Smith

[Christian Sühs]

Richard Smith schrieb:
> Merry x-mas to you as well.  Hopefully Santa will bring you some
> working bios code. *grin*

:P
> > else {
> >            romSize = *((CARD8 *) (pBIOS + VIA_BIOS_SIZE_POS)) * 512;
> >            pRom = pBIOS;
> >            sum = 0;
>
> What is it getting here?  Bios extensions have a size parameter in the
> same area as the signature.  Offset 2. (Right after the 0xaa55)

Right, Offset 2 from the Via-M VGA-Bios mvspd_15.rom is 0x7D
0x7D * 512 = 64000
Thats the correct image size before filling.

I have filled up this image with 00 to 65536 and will now try
0x80 for Offset 2
its
> the length in 512 byte chunks.  So make sure this number is correct
> for your image size.   Does the factory bios have the same values as
> your LB image?

No, see before.
> For your fill.  The unerased value of a ROM part is 0xFF.  So using
> 0xFF as a fill value is probally a good idea.

I will try both (0x00 and 0xFF), and see what happens.
Thanks for the hint.

But one question, how can I fill up the image with 0xFF.
My 0x00 way is to create a file with

dd if=/dev/zero of=bios2nd.rom bs=1 count=fill_lenght

and then

cat vga_original.rom bios2nd.rom > finalvga.rom
>

[Christian Sühs]

> But one question, how can I fill up the image with 0xFF.
> My 0x00 way is to create a file with
>
> dd if=/dev/zero of=bios2nd.rom bs=1 count=fill_lenght
>
> and then
>
> cat vga_original.rom bios2nd.rom > finalvga.rom

Ok, I have taken a Hexeditor ;)
> >

[Kevin O'Connor]

On Sun, Dec 25, 2005 at 11:54:07AM +0100, Christian Sühs wrote:
> I will try both (0x00 and 0xFF), and see what happens.
> Thanks for the hint.
>
> But one question, how can I fill up the image with 0xFF.
> My 0x00 way is to create a file with
>
> dd if=/dev/zero of=bios2nd.rom bs=1 count=fill_lenght

head -c<count> /dev/zero | tr '\000' '\377' > bios2nd.rom
> and then
>
> cat vga_original.rom bios2nd.rom > finalvga.rom

-Kevin

[Richard Smith]

> Right, Offset 2 from the Via-M VGA-Bios mvspd_15.rom is 0x7D
> 0x7D * 512 = 64000
> Thats the correct image size before filling.
>
> I have filled up this image with 00 to 65536 and will now try
> 0x80 for Offset 2

Where did you stick the checksum?  Did you compute a checksum?

Also the X driver code you posted outputs the value when its in error.
 You should just be able to change the last byte of your vbios image
to whatever the X driver outputs.

For fill files I either do something like Kevin suggested or just
create one with cut and paste in a hex editor.  I always have some
32k, 64k, and 128k files of just 0xff that I use to [ap,pre]pend to
the file with 'cat'.  Also my flash programmer will do fills.

--
Richard A. Smith

[Christian Sühs]

Richard Smith schrieb:
> > Right, Offset 2 from the Via-M VGA-Bios mvspd_15.rom is 0x7D
> > 0x7D * 512 = 64000
> > Thats the correct image size before filling.
> >
> > I have filled up this image with 00 to 65536 and will now try
> > 0x80 for Offset 2
>
> Where did you stick the checksum?  Did you compute a checksum?

Mmhh, Offset 2 from mvspd_15.rom is 7D
Offset 2 from a newer vga_bios.rom is 76

these are the correct values for the file sizes (Offset 2 * 512) after I
extract they from the orginal Bios with award bios editor.

firstvga.rom is 64000 (7D * 512 = 64000)
secondvga.rom is 60416 (76 * 512 = 60416)

with LinuxBios I use the firstvga.rom, because of the newer ones don't
work with Linuxbios ( could be vgabios.c the reason? ), but after
filling the file size is 65536

So I thought, I must set the Offset 2 to 80
(80 * 512 = 65536) and all will went fine with X (I hope so).

However, it does not work ;)
Unfortunatly I get different checksums, always if I reboot.

For example,

85fd86, 8f753d

I don't no why, I use the same bios and the same configuration for the 
rest and get different checksums, that should be inpossible.

chris

[Richard Smith]

> Unfortunatly I get different checksums, always if I reboot.
>
> For example,
>
> 85fd86, 8f753d
>
> I don't no why, I use the same bios and the same configuration for the
> rest and get different checksums, that should be inpossible.

Not if you really aren't copying the stuff to RAM.  Rememer its not
ROM you are looking at but the ROM shadowed into RAM.  So its possible
that you are checksuming the contents of RAM that has not be
initialized.  That would produce the results you see.

Have you looked at the area in RAM where this stuff is supposed to be?

I'm not near a machine that I can look up the command line but use
'hd' to look at the contents of /dev/ram starting at 0x0c0000 and see
if the next 64k are really what you think they should be.    You could
also might use 'dd' and then 'diff' it against your vbios image.

--
Richard A. Smith

[Christian Sühs]

> Not if you really aren't copying the stuff to RAM.  Rememer its not
> ROM you are looking at but the ROM shadowed into RAM.  So its possible
> that you are checksuming the contents of RAM that has not be
> initialized.  That would produce the results you see.
>
> Have you looked at the area in RAM where this stuff is supposed to be?
>
> I'm not near a machine that I can look up the command line but use
> 'hd' to look at the contents of /dev/ram starting at 0x0c0000 and see
> if the next 64k are really what you think they should be.    You could
> also might use 'dd' and then 'diff' it against your vbios image.

It seems that the content on 0x0c0000 is not the same as the vgabios
Only the first (between Offset 0x00 and Offset 0x7f) words are the same. 
The rest differs from vgabios (Offset 0x80 - 0xFFFF). That is the reason 
why X detects a valid vga-Bios section on Offset 00 and 01 (55aa) and 
the rest fails.

Now, I will have a look why this happens.
Any hint?

chris
>

[Christian Sühs]

> It seems that the content on 0x0c0000 is not the same as the vgabios
> Only the first (between Offset 0x00 and Offset 0x7f) words are the same. 
> The rest differs from vgabios (Offset 0x80 - 0xFFFF). That is the reason 
> why X detects a valid vga-Bios section on Offset 00 and 01 (55aa) and 
> the rest fails.

Not all differs from the orginal vbios, but there are many parts in the 
image which are different. Also, the whole part, which should be FF.

chris

[Christian Sühs]

> It seems that the content on 0x0c0000 is not the same as the vgabios
> Only the first (between Offset 0x00 and Offset 0x7f) words are the same. 
> The rest differs from vgabios (Offset 0x80 - 0xFFFF). That is the reason 
> why X detects a valid vga-Bios section on Offset 00 and 01 (55aa) and 
> the rest fails.
>
> Now, I will have a look why this happens.
> Any hint?

I'm a little bit confused.
Could it be, that Linuxbios override the ram sections?
It seems that vgabios.c in mainboard/via/epia-m do the job.

What about the VGA_LEGACY options from freebios, I can't use these 
options. I get errors by make a ./buildtarget via/epia-m because of, the 
options are not in Options.lb under /config.
> chris
> >

[Richard Smith]

> > Now, I will have a look why this happens.
> > Any hint?

Unfortunatly No.
> I'm a little bit confused.
> Could it be, that Linuxbios override the ram sections?
> It seems that vgabios.c in mainboard/via/epia-m do the

I have no idea what would be stomping on your video bios.

The only way I can think of to find this is to write a small routine
in linuxbios that computes the checksum of the video bios and then
start walking it through all the linuxbios code until you find where
it gets corrupted.

I'll be back at the office tomorrow and I'll try to scratch out some
time to look though the code and see if anything jumps out at me that
might copy itself into the 0xC0000 range other than linuxbios.

Have you run memtest?  Perhaps your RAM isn't really setup properly
and won't hold the right data?

You could try moving it to another section.  0x0b0000, 0x0d0000 and
0x0e0000 _might_ be open.  I don't know what your memory map is.
> What about the VGA_LEGACY options from freebios, I can't use these
> options. I get errors by make a ./buildtarget via/epia-m because of, the
> options are not in Options.lb under /config.

Those are old holdovers from V1.  I doubt any of them do anything anymore.

--
Richard A. Smith

[Ronald G Minnich]

Christian Sühs wrote:
> It seems that the content on 0x0c0000 is not the same as the vgabios
> Only the first (between Offset 0x00 and Offset 0x7f) words are the same. 
> The rest differs from vgabios (Offset 0x80 - 0xFFFF). That is the reason 
> why X detects a valid vga-Bios section on Offset 00 and 01 (55aa) and 
> the rest fails.
>
> Now, I will have a look why this happens.
> Any hint?

as ollie has mentioned, VGA bios are frequently self-modifying code. 
Once the system is up, you are looking at the code AFTER 
self-modification has happened.

PCs are disgusting.

ron

[Richard Smith]

On 12/28/05, Ronald G Minnich <[e-mail]> wrote:
> Christian Sühs wrote:
> > It seems that the content on 0x0c0000 is not the same as the vgabios
> > Only the first (between Offset 0x00 and Offset 0x7f) words are the same.
> > The rest differs from vgabios (Offset 0x80 - 0xFFFF). That is the reason
> > why X detects a valid vga-Bios section on Offset 00 and 01 (55aa) and
> > the rest fails.
> >
> > Now, I will have a look why this happens.
> > Any hint?
>
> as ollie has mentioned, VGA bios are frequently self-modifying code.
> Once the system is up, you are looking at the code AFTER
> self-modification has happened.

I guess I misread.  I though he indicated that large areas of the code
that was supposed to be 0xff was not.

It works with the factory bios but does not with linuxbios. Yes?  So
if thats the case then the self-modification is probally not the
problem.  Also it shouldn't change checksums from run to run.

Is it possible to diff the contents of 0xc0000-0x0d0000 under both the
factory and linux bios?  I think you may have said that you have to
use different copy of the video bios for linuxbios?

Grrrr... We really need to get this stuff going under the emulator to
make it easier to figure out whats up.

--
Richard A. Smith

[Christian Sühs]

Richard Smith schrieb:
> On 12/28/05, Ronald G Minnich <[e-mail]> wrote:
> > Christian Sühs wrote:
> > > It seems that the content on 0x0c0000 is not the same as the vgabios
> > > Only the first (between Offset 0x00 and Offset 0x7f) words are the same.
> > > The rest differs from vgabios (Offset 0x80 - 0xFFFF). That is the reason
> > > why X detects a valid vga-Bios section on Offset 00 and 01 (55aa) and
> > > the rest fails.
> > >
> > > Now, I will have a look why this happens.
> > > Any hint?
> >
> > as ollie has mentioned, VGA bios are frequently self-modifying code.
> > Once the system is up, you are looking at the code AFTER
> > self-modification has happened.

Oh well, it isn't easy for me to explain, I guess I need a translator :D
I will try it again in easy words.

Ok, the factory bios works well. Kernel 2.4.25 with epia-2 patch.
I used viafb on booting, bootsplash works also. The whole system is 
loading into RAM. X works with via driver-modul.

X does not work with fbdev driver modul (system hangs without any 
errors). I think, that is a problem between kernel insided viafb and the 
fbdev driver, because the fbdev driver works on kernel insided vesafb 
and factory bios.

However,
with LinuxBios the system runs as described before, but X does not work 
with via driver modul, the fbdev driver does not work, too.

via driver fails, because of the checksum errors.
fbdev driver fails as described before. I have not tried it on vesafb, 
because vesafb does not work with Linuxbios

Runtime scenarios with Linuxbios:

1. same V_Bios
--> different checksums after reboot, when starting X with via driver

2. changed V_Bios, i.e. Offset 2 or fill up with 00 vs. FF
--> different checksums and more or less failures, when starting X (via)

and so on.

Problem is, that parts of Video Rom between 0xc0000 - 0xd0000 are 
overwritten under Linuxbios. The overwritten part offsets are always the 
same, but it seems, the content changed (a little)
> I guess I misread.  I though he indicated that large areas of the code
> that was supposed to be 0xff was not.
>
> It works with the factory bios but does not with linuxbios. Yes?  So
> if thats the case then the self-modification is probally not the
> problem.  Also it shouldn't change checksums from run to run.

That's right.
> Is it possible to diff the contents of 0xc0000-0x0d0000 under both the
> factory and linux bios?  I think you may have said that you have to
> use different copy of the video bios for linuxbios?

I have not done this, for now. I will make a dd as soon as possible and 
diff it to the original V-Bios, when using the factory bios.

However, I have done this on my host machine, and the part between c0000 
- d0000 looks like the original.
> Grrrr... We really need to get this stuff going under the emulator to
> make it easier to figure out whats up.

chris

[Christian Sühs]

> > Is it possible to diff the contents of 0xc0000-0x0d0000 under both the
> > factory and linux bios?  I think you may have said that you have to
> > use different copy of the video bios for linuxbios?

Ok, first result of factory bios:

Via Epia-ML Bios Version 1.1.16
included VGA-Bios called Mclecomb.rom

get file with

dd if=/dev/mem of=vga1.rom bs=1 count=65536 skip=786432

later I have done a dd on vga1.rom with count 60146, because the 
extracted vga_bios from origbios.bin has a size of 60146

compare:

cmp -cl origvga.rom vga2.rom

Result:

There are two different offsets.
Offset 1A is A5, original Offset 1A is A6
Offset 5D is 01, original Offset 5D is 00

thats all.

Unfortanetly I can not write the differences from Linuxbios, because, 
there are to much :D

LinuxBios
included VGA-Bios Mvpsd_15.rom from Epia-M Bios Version 1.1.13

if you want, you can have a log file ;)
It seems, nearly the half code is overwritten.


chris

[Christian Sühs]

> Result:
>
> There are two different offsets.
> Offset 1A is A5, original Offset 1A is A6
> Offset 5D is 01, original Offset 5D is 00

Think about the X via checksum routine,

First changed offset -1
Second changed offset +1

(-1) + (+1) = :D

[Richard Smith]

> LinuxBios
> included VGA-Bios Mvpsd_15.rom from Epia-M Bios Version 1.1.13

Your VBIOS version number are different between Factory and Linuxbios.
 If you can somehow compare the exact versions that would be best.

If you can't make Linuxbios run .16 can you get (or make) a factory
bios version that is .13?
> Unfortanetly I can not write the differences from Linuxbios, because,
> there are to much :D

What are the address ranges that are different?

If we assume that Ver .13 dosen't do anything radically different from
.16 then we should expect to only see minimal differences from the
self-modify.

Are you sure that all of your shadow areas are setup correctly during the copy?

--
Richard A. Smith

[Christian Sühs]

Richard Smith schrieb:
> > LinuxBios
> > included VGA-Bios Mvpsd_15.rom from Epia-M Bios Version 1.1.13
>
> Your VBIOS version number are different between Factory and Linuxbios.
>  If you can somehow compare the exact versions that would be best.

The Problem is, that the newer vga_bios .16 not work with LinuxBios.
If I remember right, there is no vga console coming up.
It seems the newer Version includes the TV-Ship Routines (VT1622)
> If you can't make Linuxbios run .16 can you get (or make) a factory
> bios version that is .13?

You mean, take the original bios, delete vga-bios .16 and insert 
vga-bios .13 instead?
Well, I can try it and will see what happens :D
Unfortunatly, vga .16 is smaller as .13
> > Unfortanetly I can not write the differences from Linuxbios, because,
> > there are to much :D
>
> What are the address ranges that are different?

Oh, that is a hard work, but I will have a look.
> If we assume that Ver .13 dosen't do anything radically different from
> .16 then we should expect to only see minimal differences from the
> self-modify.

Somewhere in the code of .13 is a line, "Not for factory use, testing 
only" :D I hope it will work ;)
> Are you sure that all of your shadow areas are setup correctly during the copy?

Good question, but I think so. How can I figure out, that all is make well.
As I say, some pieces of vga code is on the right place, you will see 
it, if I write the different ranges. The rest of Linuxbios is okay and 
works.
>

[Richard Smith]

> You mean, take the original bios, delete vga-bios .16 and insert
> vga-bios .13 instead?
> Well, I can try it and will see what happens :D
> Unfortunatly, vga .16 is smaller as .13

Yeah.  Use a hex editor and cut and paste so the size stays the same.
> > Are you sure that all of your shadow areas are setup correctly during the copy?
>
> Good question, but I think so. How can I figure out, that all is make well.
> As I say, some pieces of vga code is on the right place, you will see
> it, if I write the different ranges. The rest of Linuxbios is okay and
> works.

After the code in vgabios.c only checks for the existence of the
signature after the copy is complete.  Change that code so it does a
byte by byte comparison.

After the memcpy but before the call to write_protect_vgabios() put in
a check to see if it matches byte for byte.

--
Richard A. Smith

[Christian Sühs]

Richard Smith schrieb:
> > You mean, take the original bios, delete vga-bios .16 and insert
> > vga-bios .13 instead?
> > Well, I can try it and will see what happens :D
> > Unfortunatly, vga .16 is smaller as .13
>
> Yeah.  Use a hex editor and cut and paste so the size stays the same.

Ok, I have made a new factory bios with cbrom.
Changed out Mclecomb.rom (vgabios .16) with MVPSD_15.rom (vgabios .13)

The new made bios works well, X starts with via modul without errors.

Compare between MVPSD_15.rom and RAM Setcion c0000 have the same results 
as with the orginal bios before.

Offset 1a (d5 goes to d4) and Offset 5d (00 goes to 01) differs from the 
orginal.

Now I will try to build in checksum routines in the linuxbios sources.

chris

[Christian Sühs]

I think, I have found the failure.

if write_protect_vgabios() is called, it searches by 
dev_find_device(0x1106, 0x3123, 0) for the device dev

if dev valid, it write protected the vgabios.

But it seems the via epia-ml vga device ID is 3122. I have seen this on 
the console output before write_protect_vgabios is called.

Found VGA: vid=1106, did=3122

Unfortunatly the printk_info messages "write_protect_vgabios" comes 
before the bios is protected.

I will try a new Linuxbios with changes on dev_find_device()
and hope all will work fine :D

chris

[Christian Sühs]

I can't believe it.

It works :D

Many thanks for your help.

Now I will look for the next failure :D

[Richard Smith]

On 12/29/05, Christian Sühs <[e-mail]> wrote:
> I can't believe it.
>
> It works :D

And there was much rejoicing.
> Many thanks for your help.

No prob.  I'm just glad we were able to make it work.

Now we need to document all this.  Can you list all of the problems
you had (so far) and what their solutions were.  Then I'll edit it and
get it up on the wiki.

Also I think we need to create a new mainboard for this setup with all
your mods.  You have had 2 seperate cases where a device difference
caused you some trouble.

Please create a new mainboard directory and a new target with your
working setup and submit the diff for inclusion back into the tree.

Still un-answered is _what_ was trashing parts of the 0x0c0000 area. 
We have fixed the symptom but not the cause.

I wonder is this a global via epia problem?

It would be helpfull if the rest of the via epia users would comment
out the write protect and see if they see the same thing happen.

--
Richard A. Smith

[Christian Sühs]

> > It works :D
>
> And there was much rejoicing.

:D
> > Many thanks for your help.
>
> No prob.  I'm just glad we were able to make it work.

I'm too.
> Now we need to document all this.  Can you list all of the problems
> you had (so far) and what their solutions were.  Then I'll edit it and
> get it up on the wiki.

Well, I will make it in the next days. Unfortunatly, the X fbdev driver 
does not work. Probably it is a inconsistent between viafb and fbdev. 
Doesn't matter. I have find out, that the TinyX Xfbdev-Server works 
great :D
> Also I think we need to create a new mainboard for this setup with all
> your mods.  You have had 2 seperate cases where a device difference
> caused you some trouble.

Eventually, there are more ie the non exist fdc port
> Please create a new mainboard directory and a new target with your
> working setup and submit the diff for inclusion back into the tree.

No problem. But there are many calls to devices, which the epia-ml not 
have. I think, that makes Linuxbios a little bit slow or there are other 
dev_find_device calls with false device IDs :D. I will try to remove 
these sections before I create a new target.
> Still un-answered is _what_ was trashing parts of the 0x0c0000 area. 
> We have fixed the symptom but not the cause.

That's right. I have looked again and again at the code and it seems it 
is garbage, only. But I'm not sure.
> I wonder is this a global via epia problem?

Not, if the write_protect_vgabios function works :)
I have read somewhere in the net, that newer epias have a new designed 
CLE266 Chipsets. It could be the reason for the different device IDs
In the X source code I have found somewhere:

1106_3122 = VT8623 [Apollo CLE266] integrated CastleRock graphics
1106_3123 = VT8623 [Apollo CLE266]
> It would be helpfull if the rest of the via epia users would comment
> out the write protect and see if they see the same thing happen.

Good idea.
chris

[Nick Barker]

-----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