Hi, I am trying to add VGA support in cocom voyager2 board. The VGA is found but lb complain "biosint: Unsupport int #0x6" endlessly. I dumped the original bios and found besides VGA BIOS I extracted, there is VSA driver. Is VSA driver also needed to work with linuxbios and VGA BIOS? If so, Where should I put it? And need I do more things to make it work?
Best Regards!
******** phoneix.bin BIOS component ********
No. Item-Name Original-Size Compressed-Size Original-File-Name ==============================================================================
0. System BIOS 20000h(128.00K) 12EECh(75.73K) original.tmp 1. XGROUP CODE 07340h(28.81K) 04D70h(19.36K) awardext.rom 2. EPA LOGO 0168Ch(5.64K) 002AAh(0.67K) AwardBmp.bmp 3. VGA ROM[1] 08000h(32.00K) 04229h(16.54K) gxivideo.208 4. PCI ROM[A] 0C800h(50.00K) 07536h(29.30K) RTSROM_M.LOM 5. VSA driver 20000h(128.00K) 09B2Fh(38.80K) GXM55306.BIN 6. LOGO BitMap 2583Ch(150.06K) 0474Bh(17.82K) n5535.bmp
---------------------------------------------------------------------
INSTALL REAL-MODE IDT
DO THE VGA BIOS
found VGA: vid=1078, did=104
0x55 0xaa 0x40 0xeb 0x4b 0x37 0x34 0x30 0x30 0xe9 0x4c 0x19 0x77 0xcc 0x56 0x49 biosint: # 0x6, eax 0x0 ebx 0x10 ecx 0x320 edx 0xaf8c
biosint: ebp 0x11498 esp 0xff6 edi 0xd4d4 esi 0xfffc0000
biosint: ip 0x3 cs 0x0 flags 0x46
biosint: Unsupport int #0x6
biosint: # 0x6, eax 0x0 ebx 0x10 ecx 0x320 edx 0xaf8c
biosint: ebp 0x11498 esp 0xff6 edi 0xd4d4 esi 0xfffc0000
biosint: ip 0x3 cs 0x0 flags 0x46
biosint: Unsupport int #0x6
biosint: # 0x6, eax 0x0 ebx 0x10 ecx 0x320 edx 0xaf8c
biosint: ebp 0x11498 esp 0xff6 edi 0xd4d4 esi 0xfffc0000
biosint: ip 0x3 cs 0x0 flags 0x46
biosint: Unsupport int #0x6
_________________________________________________________________ 享用世界上最大的电子邮件系统― MSN Hotmail。 http://www.hotmail.com
On Wed, 27 Aug 2003, elife elife wrote:
I am trying to add VGA support in cocom voyager2 board. The VGA is found but lb complain "biosint: Unsupport int #0x6" endlessly. I dumped the original bios and found besides VGA BIOS I extracted, there is VSA driver. Is VSA driver also needed to work with linuxbios and VGA BIOS? If so, Where should I put it? And need I do more things to make it work?
you need to confirm that int #5 is a VSA interrupt of some sort.
What I would recommend to make debugging easier is to use the "testbios" program to do the VGA support first. Once that is working, you can see how to make vgabios work. What makes this easier is that you can run testbios under linux.
ron
On Tue, Aug 26, 2003 at 11:00:27PM -0600, ron minnich wrote:
On Wed, 27 Aug 2003, elife elife wrote:
I am trying to add VGA support in cocom voyager2 board. The VGA is found but lb complain "biosint: Unsupport int #0x6" endlessly. I dumped the original bios and found besides VGA BIOS I extracted, there is VSA driver. Is VSA driver also needed to work with linuxbios and VGA BIOS? If so, Where should I put it? And need I do more things to make it work?
you need to confirm that int #5 is a VSA interrupt of some sort.
I don't know what VSA is, but int 6 is the Invalid Opcode Exception, not a BIOS service. This means the execution crashed.
Btw, I've noticed that the idt.c (realmode int handler) puts "stub"s starting at 0x400 (1024). It installs 256 stubs, 9 bytes each, so they occupy 256*9=2304 bytes from 0x400. The 256 bytes (or more?) starting at 0x400 is the BIOS Data Area, and VGABIOS tends to rewrite some bytes in it. So, it might damage the int handler before calling it.
I don't know if this is the case, but the stubs can easily be moved anywhere below 64k, I think.
-- Takeshi
On Wed, 27 Aug 2003, SONE Takeshi wrote:
On Tue, Aug 26, 2003 at 11:00:27PM -0600, ron minnich wrote:
you need to confirm that int #5 is a VSA interrupt of some sort.
I don't know what VSA is, but int 6 is the Invalid Opcode Exception, not a BIOS service. This means the execution crashed.
yes, I think something is going wrong.
Btw, I've noticed that the idt.c (realmode int handler) puts "stub"s starting at 0x400 (1024). It installs 256 stubs, 9 bytes each, so they occupy 256*9=2304 bytes from 0x400. The 256 bytes (or more?) starting at 0x400 is the BIOS Data Area, and VGABIOS tends to rewrite some bytes in it. So, it might damage the int handler before calling it.
that's a very good thing to know!
Where would you like to see the stubs moved?
ron
On Wed, Aug 27, 2003 at 07:37:58AM -0600, ron minnich wrote:
Btw, I've noticed that the idt.c (realmode int handler) puts "stub"s starting at 0x400 (1024). It installs 256 stubs, 9 bytes each, so they occupy 256*9=2304 bytes from 0x400. The 256 bytes (or more?) starting at 0x400 is the BIOS Data Area, and VGABIOS tends to rewrite some bytes in it. So, it might damage the int handler before calling it.
that's a very good thing to know!
Where would you like to see the stubs moved?
I think any address below 64K is ok without more modifications to the code. You put realmode stack at 4K (and below). LinuxBIOS starts at 32K for most configurations(?). So, putting stubs at 4K (0x1000) makes sense, I think.
-- Takeshi
OK, would anyone like to test out my fixed vgabios with the devfn patch?
I will look at moving the table to 0x1000. I actually think there was a reason I kept all this on page 0, but that reason probably no longer matters.
ron
On Wed, Aug 27, 2003 at 08:14:47AM -0600, ron minnich wrote:
OK, would anyone like to test out my fixed vgabios with the devfn patch?
I will look at moving the table to 0x1000. I actually think there was a reason I kept all this on page 0, but that reason probably no longer matters.
I think the page size hardly matters, since nothing does paging. What matters is the 64K limit of 16-bit segments. I found it very clever that current code puts everything below 64K and sets zero to all 16-bit segment registers. It simplfies the code a lot.
It's also worth mentioning that the current code works only if the "trampoline" code is also located below 64K. On my build it is ok, but nothing forces or checks it.
-- Takeshi
On Thu, 28 Aug 2003, SONE Takeshi wrote:
I found it very clever that current code puts everything below 64K and sets zero to all 16-bit segment registers. It simplfies the code a lot.
thanks :-)
It's also worth mentioning that the current code works only if the "trampoline" code is also located below 64K.
oops. What do you mean by "trampoline" here?
Do you think you could test a new vgabios.c for me?
ron
On Thu, Aug 28, 2003 at 07:26:30AM -0600, ron minnich wrote:
It's also worth mentioning that the current code works only if the "trampoline" code is also located below 64K.
oops. What do you mean by "trampoline" here?
32-16-32 transition in vgabios.c and 16-32-16 transition in idt.c. The problem is that 16-bit code segment descriptor (0x28) has base address zero and 64K limit.
(I studied these code to implement my own 32-bit legacy services but abandoned it because vm86 starts looking inevitable...)
Perhaps we can put these functions in a special section and modify the ld script to put this section near the beginning of image so that these functions will be located below 64K for most cases.
Do you think you could test a new vgabios.c for me?
Sure. My EPIA doesn't need the fix but I can confirm the fix doesn't break it.
-- Takeshi
On Thu, 28 Aug 2003, SONE Takeshi wrote:
(I studied these code to implement my own 32-bit legacy services but abandoned it because vm86 starts looking inevitable...)
Why not use the emulation instead, so we can support PPC etc.?
ron
On Thu, Aug 28, 2003 at 07:51:41AM -0600, ron minnich wrote:
On Thu, 28 Aug 2003, SONE Takeshi wrote:
(I studied these code to implement my own 32-bit legacy services but abandoned it because vm86 starts looking inevitable...)
Why not use the emulation instead, so we can support PPC etc.?
I'm interested in more complete PCBIOS functionality, like ADLO, rather than something just for running option ROMs. (Running LILO in an emulator wouldn't be really useful!)
I'm thinking on possibility of implementing BIOS *services* in real mode, and initialization (POST), including option ROM handling, in 32-bit.
Services can be written in normal C. They will be built into a realmode SystemBIOS image when built for x86, and for non-x86, they will be compiled natively and linked together with x86 emulator. Only entry/exit routines (to/from 16-bit code, eg. VGABIOS) will make the difference.
-- Takeshi
On Fri, 29 Aug 2003, SONE Takeshi wrote:
Services can be written in normal C. They will be built into a realmode SystemBIOS image when built for x86, and for non-x86, they will be compiled natively and linked together with x86 emulator. Only entry/exit routines (to/from 16-bit code, eg. VGABIOS) will make the difference.
OK, for the emulation you might want to look at util/vgabios.
ron
On Wed, Aug 27, 2003 at 04:14:42PM +0900, SONE Takeshi wrote:
you need to confirm that int #5 is a VSA interrupt of some sort.
I don't know what VSA is, but int 6 is the Invalid Opcode Exception,
VSA is the name of a NSC system to allow for software implementations of legacy hardware. VSMs (Virtual System Modules) load themselves e.g. from option ROM or part of the BIOS and tell VSA that IO reads and writes to this-and-that address should be trapped, and sent to the VSM for proper handling instead.
E.g. audio and USB require a VSM on SCx2xx/GX1+CS5530 systems, which I believe the voyager2 is.
Unfortunately I don't remember if VSA can be used to trap interrupts as well, but I agree with Ron and Mr. Takeshi that this is likely the VGA BIOS scribbling over the interrupt table, if that's located at 400h.
//Peter
-
elife elife -
Peter Stuge -
ron minnich -
SONE Takeshi