-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Hello,
I managed to catch all I/O for init of K8M890 IGP. Attached patch is for http://www.nongnu.org/vgabios/. With a patch one can have a console and some VGA resolutions also might work.
It is just a interesting result.
I used libx86 library to catch all IO. It was quite painful until I realize that the emulator cannot handle properly opcodes like
0x66 0xe8 .. .. 0xff 0xff and also mov al,cs:[ebx] which I get caught in Sebios int 15 routine.
I somehow managed to fix the emulator (only hacks) and patched the IO backend of emulator and obtained following tracedump:
OUTB to 3c3 is 1 OUTW to 3c4 is 32 OUTB to 3c4 is 10 INB from 3c5 is 0 OUTB to 3c5 is 1 OUTL to cf8 is 80010000 INL from cfc is 32301106 OUTB to 3c4 is 2d INB from 3c5 is aa OUTB to 3c5 is bf OUTW to 3c4 is 816 ... and other ~250 lines
Those were just directly transformed with bash script to IO calls in patch. The BIOS works, it even sets the memory speed grade, but not the mem size to scratch registers (it uses SeaBIOS VIA vga hooks for this)
I can boot X without any problems, Windows 7 boots with VGAfailsafe driver and 16 colors ;)
If someone ever want to write somethink like SeaBIOS but for VGA here is the chance (I dont have time :/)
What is important, some bits in this init fixes also the problem with PowerNow which I had until VGA option rom was run. There must be smth set which enables the HT deliver stop grants or smth like this again.
Rudolf
On Sat, Apr 25, 2009 at 04:01:09PM +0200, Rudolf Marek wrote:
I managed to catch all I/O for init of K8M890 IGP. Attached patch is for http://www.nongnu.org/vgabios/. With a patch one can have a console and some VGA resolutions also might work.
It is just a interesting result.
So, you got the open source vgabios to boot on real hardware. Very nice!
I used libx86 library to catch all IO. It was quite painful until I realize that the emulator cannot handle properly opcodes like
0x66 0xe8 .. .. 0xff 0xff and also mov al,cs:[ebx] which I get caught in Sebios int 15 routine.
Most of SeaBIOS is compiled with gcc. gcc generates regular 32bit code. Then a gnu assembler (gas) hack is used to make that 32bit code run while the processor is in 16bit mode.
As such, I can't think of any way to stop the 0x66/0x67 prefixes - they are inherent to the process.
Those were just directly transformed with bash script to IO calls in patch. The BIOS works, it even sets the memory speed grade, but not the mem size to scratch registers (it uses SeaBIOS VIA vga hooks for this)
It would be nice to port the open source vgabios from bcc to gcc. (Much like what was done with bochs bios/SeaBIOS.) Doing so will make understanding and manipulating the code much easier.
I actually started this 5 months ago - I ported all the assembler to pseudo C code. I realized it was more work than I originally anticipated, and so it stalled.
+mov al, #0x1 +mov dx, #0x3c3 +out dx,al +mov ax, #0x32 +mov dx, #0x3c4 +out dx,ax +mov al, #0x10 +mov dx, #0x3c4 +out dx,al
[...]
I suspect some of these IO accesses would be done by the vgabios anyway - some things like screen clearing and palette selection are standard. Which parts are standard and which parts are via specific is an open question though.
-Kevin
Kevin O'Connor wrote:
I used libx86 library to catch all IO. It was quite painful until I realize that the emulator cannot handle properly opcodes like
0x66 0xe8 .. .. 0xff 0xff and also mov al,cs:[ebx] which I get caught in Sebios int 15 routine.
Most of SeaBIOS is compiled with gcc. gcc generates regular 32bit code. Then a gnu assembler (gas) hack is used to make that 32bit code run while the processor is in 16bit mode.
As such, I can't think of any way to stop the 0x66/0x67 prefixes - they are inherent to the process.
I think the issue is with VGA BIOSes (any option ROMs, really) and that the various emulators used by coreboot don't handle the prefixes.
//Peter
On Sat, Apr 25, 2009 at 8:33 AM, Peter Stuge peter@stuge.se wrote:
I think the issue is with VGA BIOSes (any option ROMs, really) and that the various emulators used by coreboot don't handle the prefixes.
I think that is not quite correct. I vaguely recall having to fix some of them years ago. I doubt we caught them all.
option ROMS are supposed to be 8086 code, but they routinely violate that rule.
ron
On Sat, Apr 25, 2009 at 09:22:56AM -0700, ron minnich wrote:
On Sat, Apr 25, 2009 at 8:33 AM, Peter Stuge peter@stuge.se wrote:
I think the issue is with VGA BIOSes (any option ROMs, really) and that the various emulators used by coreboot don't handle the prefixes.
I think that is not quite correct. I vaguely recall having to fix some of them years ago. I doubt we caught them all.
option ROMS are supposed to be 8086 code, but they routinely violate that rule.
The PCI spec states that option roms must be called in "big real" mode. The only reason to make this demand is so that the option rom can use 32bit registers and memory accesses.
-Kevin
On Sat, Apr 25, 2009 at 9:41 AM, Kevin O'Connor kevin@koconnor.net wrote:
The PCI spec states that option roms must be called in "big real" mode. The only reason to make this demand is so that the option rom can use 32bit registers and memory accesses.
Yes, I'm probably mistaking these 0x66 prefix insns for non-86 instructions ... but I do recall from years back that some of the things we saw in the vga bios looked like more than just bigreal. But then again, my memory may be fuzzy.
ron
On Sat, Apr 25, 2009 at 04:01:09PM +0200, Rudolf Marek wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Hello,
I managed to catch all I/O for init of K8M890 IGP. Attached patch is for http://www.nongnu.org/vgabios/. With a patch one can have a console and some VGA resolutions also might work.
It is just a interesting result.
I used libx86 library to catch all IO. It was quite painful until I realize that the emulator cannot handle properly opcodes like
0x66 0xe8 .. .. 0xff 0xff and also mov al,cs:[ebx] which I get caught in Sebios int 15 routine.
I somehow managed to fix the emulator (only hacks) and patched the IO backend of emulator and obtained following tracedump:
OUTB to 3c3 is 1 OUTW to 3c4 is 32 OUTB to 3c4 is 10 INB from 3c5 is 0 OUTB to 3c5 is 1 OUTL to cf8 is 80010000 INL from cfc is 32301106 OUTB to 3c4 is 2d INB from 3c5 is aa OUTB to 3c5 is bf OUTW to 3c4 is 816 ... and other ~250 lines
Those were just directly transformed with bash script to IO calls in patch. The BIOS works, it even sets the memory speed grade, but not the mem size to scratch registers (it uses SeaBIOS VIA vga hooks for this)
A proper driver doesn't care about the scratch. But sadly such proper driver doesn't support vt3230 fully yet (although it does support the host for finding out those values directly). With this working, i am actually tempted to do the little work needed to get a VGA out working on my driver right away.
I can boot X without any problems, Windows 7 boots with VGAfailsafe driver and 16 colors ;)
If someone ever want to write somethink like SeaBIOS but for VGA here is the chance (I dont have time :/)
I had a first pass at this code last january (2008) for CLE266. Should get the dust off of it.
What is important, some bits in this init fixes also the problem with PowerNow which I had until VGA option rom was run. There must be smth set which enables the HT deliver stop grants or smth like this again.
Rudolf.
Come monday i will look through it and filter out what i think is not relevant as a start for finding out what needs to set up for HT to work properly. It could be multiple registers, but i'm sure that i can reduce this set to 1/10 or even less on the first pass just on sight. After a few iterations, we will have what we need.
Nice work!
Luc Verhaegen.
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Hi,
I think I reduced that quite a bit. If I run this program when I power on a board without VGA BIOS and then do modprobe powernow-k8 it starts to work.
Rudolf
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Rudolf Marek wrote:
Hi,
I think I reduced that quite a bit. If I run this program when I power on a board without VGA BIOS and then do modprobe powernow-k8 it starts to work.
Hmm it does not. It seems there was some bigger timeout :/
But anyway. If i let it run up to those last line without the skip, at least it always work. I'm looking forward what you will find.
Rudolf
2009/4/25 Rudolf Marek r.marek@assembler.cz:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Hello,
I managed to catch all I/O for init of K8M890 IGP. Attached patch is for http://www.nongnu.org/vgabios/. With a patch one can have a console and some VGA resolutions also might work.
It is just a interesting result.
I used libx86 library to catch all IO. It was quite painful until I realize that the emulator cannot handle properly opcodes like
0x66 0xe8 .. .. 0xff 0xff and also mov al,cs:[ebx] which I get caught in Sebios int 15 routine.
I somehow managed to fix the emulator (only hacks) and patched the IO backend of emulator and obtained following tracedump:
OUTB to 3c3 is 1 OUTW to 3c4 is 32 OUTB to 3c4 is 10 INB from 3c5 is 0 OUTB to 3c5 is 1 OUTL to cf8 is 80010000 INL from cfc is 32301106 OUTB to 3c4 is 2d INB from 3c5 is aa OUTB to 3c5 is bf OUTW to 3c4 is 816 ...
Just a note of warning here. We tried this approach in 2001 or so. This approach may work on your board, and will likely work on many boards. What many vendors do, however, is hard-code timing information in their VGA BIOS -- e.g. DRAM info -- and they change parts and timing all the time. We found cards that were the same vendor, same card, same part number, that had different values for setup. We ultimately abandoned the approach you are using because of this problem.
Which is to say, I am glad this worked for you, but I am afraid it will not work in general.
Thanks
ron
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Which is to say, I am glad this worked for you, but I am afraid it will not work in general.
It is "integrated" graphics. It uses main RAM for framebuffer. This is the reason why it worked ;)
Rudolf
On Sat, Apr 25, 2009 at 09:25:58AM -0700, ron minnich wrote:
Just a note of warning here. We tried this approach in 2001 or so. This approach may work on your board, and will likely work on many boards. What many vendors do, however, is hard-code timing information in their VGA BIOS -- e.g. DRAM info -- and they change parts and timing all the time. We found cards that were the same vendor, same card, same part number, that had different values for setup. We ultimately abandoned the approach you are using because of this problem.
Which is to say, I am glad this worked for you, but I am afraid it will not work in general.
Thanks
ron
For unichrome, this will work quite well if you take it per chip version. There's only like 11 out currently. And the amount of work is rather minimal per chip beyond the standard vga modeset (as i have been there on there EPIA M and, at the time, linuxbios v2)..
Luc Verhaegen.
On Sat, Apr 25, 2009 at 8:10 PM, Luc Verhaegen libv@skynet.be wrote:
For unichrome, this will work quite well if you take it per chip version. There's only like 11 out currently. And the amount of work is rather minimal per chip beyond the standard vga modeset (as i have been there on there EPIA M and, at the time, linuxbios v2)..
Neat. OK, what would be very interesting is to start accumulating knowledge about which boards this works on.
Killing the proprietary VGA BIOS is always a good idea :-)
ron
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Hi again,
I'm attaching a rewritten version from VGA ROM, which mimics the BIOS init.
Sadly enough it is still not hitting the all required regs to make powernow working as it is with orig bios.
The rest register spill is the captured IO as it was. The top of the file is what bios is doing during the init. Just before it calls ax=0003 and exits the rom.
There is also one interresting place:
<------>write_cr((read_cr(0x36) & ~0x30) | (0x3 << 4), 0x36); <------>write_cr((read_cr(0x30) & ~0x4), 0x30);
<------>/* just read, hope compiler won't optimize that out */ <------>tmp = inb(0x3da); <------>tmp = inb(0x3ba);
<------>outb(0x0, 0x3c0);
/* original bios has it but if I compile it in I get blank screen */ //<---->tmp = inb(0x3da); <------>tmp = inb(0x3ba);
The bios is doing it exactly like this. But if I enable the inb(0x3da) I get no picture but monitors seems to have some signal. It works fine without those inbs. Any idea what is doing the code?
Rudolf
On Fri, May 01, 2009 at 11:42:17PM +0200, Rudolf Marek wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Hi again,
I'm attaching a rewritten version from VGA ROM, which mimics the BIOS init.
Sadly enough it is still not hitting the all required regs to make powernow working as it is with orig bios.
The rest register spill is the captured IO as it was. The top of the file is what bios is doing during the init. Just before it calls ax=0003 and exits the rom.
There is also one interresting place:
<------>write_cr((read_cr(0x36) & ~0x30) | (0x3 << 4), 0x36);
VGA H/VSync off.
<------>write_cr((read_cr(0x30) & ~0x4), 0x30);
Disable Power Now Signals in CRTC1, as can be read from public via docs.
<------>/* just read, hope compiler won't optimize that out */ <------>tmp = inb(0x3da); <------>tmp = inb(0x3ba);
STAT1 (both colour and mono)
<------>outb(0x0, 0x3c0);
STAT0
/* original bios has it but if I compile it in I get blank screen */ //<---->tmp = inb(0x3da); <------>tmp = inb(0x3ba);
Halfway through the dump the vga device is set from mono to colour.
The bios is doing it exactly like this. But if I enable the inb(0x3da) I get no picture but monitors seems to have some signal. It works fine without those inbs. Any idea what is doing the code?
Hrm. This is the AR register accesses. They require a read from STAT1 for the internal counter to be reset and thus for correct read/write operations.
Luc Verhaegen.
Hrm. This is the AR register accesses. They require a read from STAT1 for the internal counter to be reset and thus for correct read/write operations.
I inserted a delay there, now it works. The bios has there just some CALL and I have it in one instruction stream. Maybe it is too fast.
Rudolf