27 Aug
2003
27 Aug
'03
1:25 a.m.
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
27 Aug
27 Aug
2:44 a.m.
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
4:58 a.m.
On Tue, Aug 26, 2003 at 11:00:27PM -0600, ron minnich wrote:
On Wed, 27 Aug 2003, elife elife wrote:
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
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.
11:21 a.m.
On Wed, 27 Aug 2003, SONE Takeshi wrote:
On Tue, Aug 26, 2003 at 11:00:27PM -0600, ron minnich
wrote:
yes, I think something is going wrong.
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.
that's a very good thing to know!
Where would you like to see the stubs moved?
ron
11:40 a.m.
On Wed, Aug 27, 2003 at 07:37:58AM -0600, ron minnich wrote:
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
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?
11:58 a.m.
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
28 Aug
28 Aug
4:26 a.m.
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
11:09 a.m.
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
11:32 a.m.
On Thu, Aug 28, 2003 at 07:26:30AM -0600, ron minnich wrote:
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.
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?
Sure.
My EPIA doesn't need the fix but I can confirm the fix doesn't break it.
--
Takeshi
11:35 a.m.
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
29 Aug
29 Aug
7:55 a.m.
On Thu, Aug 28, 2003 at 07:51:41AM -0600, ron minnich wrote:
On Thu, 28 Aug 2003, SONE Takeshi wrote:
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
(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.?
11:56 a.m.
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
27 Aug
27 Aug
3:08 p.m.
On Wed, Aug 27, 2003 at 04:14:42PM +0900, SONE Takeshi wrote:
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
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,
6545
days inactive
6548
days old
12 comments
4 participants
participants (4)
-
elife elife -
Peter Stuge -
ron minnich -
SONE Takeshi