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
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); } } }
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
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
-- Richard A. Smith
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
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
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
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
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
-- Richard A. Smith
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
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 A. 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
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
On 12/28/05, Ronald G Minnich rminnich@lanl.gov 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
Richard Smith schrieb:
On 12/28/05, Ronald G Minnich rminnich@lanl.gov 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.
-- Richard A. Smith
chris
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
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
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
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 A. 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
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
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
I can't believe it.
It works :D
Many thanks for your help.
Now I will look for the next failure :D
On 12/29/05, Christian Sühs chris@suehsi.de 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
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
-----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
-
Christian Sühs -
Kevin O'Connor -
Nick Barker -
Richard Smith -
Ronald G Minnich