Via BIOS source code

[Frank Tagliano]

Via bios code on public ftp:
ftp://ftp.via.com.tw/public/sw/

______________________________________________________
Get Your Private, Free Email at http://www.hotmail.com

-
To unsubscribe: send mail to [e-mail]
with 'unsubscribe openbios' in the body of the message

Video

[James]

Ron,
  Everything I can find tells me that we should let the video card
initialize itself.  It looks like we should scan C0000 through E0000 for
the video cards signature and then call its code..  The problem is that I
think we may have to do this in 16 bit mode.
  Can't we get a 16-bit mode C compiler (or even better, a 16-bit mode
gnu assembler)?
    - James
> > > > > > http://members.xoom.com/cattaghia/Tuts/biosstrt.txt

The ROM BIOS, on a system startup, executes the POST (power-on self-test)
routine which usually checks memory, establishes devices etc.  The POST
routine also fills in the BIOS memory area at 0000:0040h and sets up the
real mode interrupt handlers (those connected to IRQ lines are set to
dummy handlers which simply acknowledge the interrupt with the PIC and
return, those assigned to BIOS services are set to the appropriate
address, which may vary with the BIOS manufacturer and revision).  The
POST then checks for extensions ROMs at this point (for example the video
card).  Absolute addresses C0000h through E0000h are searched in 2KB
increments for the signature 55h 0AAh.  If the signature is found, the
next byte is a length indicator for the ROM (in 512 byte blocks) and the
next bytes contain a FAR CALLable address (it should be called as an
empirical address, with the lowest possible offset value.  For example,
absolute address C0003h is called as C000:0003h).  The extension BIOSes
perform initialization and then return. On entry, SS:SP must be set up as
a valid stack.

-
To unsubscribe: send mail to [e-mail]
with 'unsubscribe openbios' in the body of the message

Video

[Ronald G. Minnich]

Well, I still am going to be stubborn about this. X11 servers manage to
drive the cards pretty extensively with no real trouble.

Besides, recall on most motherboards with built-in-video: the video bios
is in the nvram I just over-wrote with Linux. We have to figure this
out. OpenBIOS is going to have to figure it out too, for the same reason,
unless Open BIOS wants to be 1/2-Open. So let's work it out.

ron

-
To unsubscribe: send mail to [e-mail]
with 'unsubscribe openbios' in the body of the message

Video

[Todd Whitesel]

> Well, I still am going to be stubborn about this. X11 servers manage to
> drive the cards pretty extensively with no real trouble.

That is because the VGA BIOS has already been run during POST, before the
kernel or the X11 server ever gets loaded into the machine.
> Besides, recall on most motherboards with built-in-video: the video bios
> is in the nvram I just over-wrote with Linux. We have to figure this
> out. OpenBIOS is going to have to figure it out too, for the same reason,
> unless Open BIOS wants to be 1/2-Open. So let's work it out.

Talk to the XFree86 4.0 guys; they're tackling the problem right now because
they want to handle multi-headed machines, and (except for certain double
headed products from people like Matrox) only one card can occupy the legacy
ISA address area so extra cards never have their VGA BIOS' run at all.

Todd Whitesel
toddpw @ best.com
-
To unsubscribe: send mail to [e-mail]
with 'unsubscribe openbios' in the body of the message

Video

[Ronald G. Minnich]

On Fri, 18 Feb 2000, Todd Whitesel wrote:
> Talk to the XFree86 4.0 guys; they're tackling the problem right now because
> they want to handle multi-headed machines, and (except for certain double
> headed products from people like Matrox) only one card can occupy the legacy
> ISA address area so extra cards never have their VGA BIOS' run at all.

Thanks, that is a *great* idea.

The thing is, the chip on the L440GX is a cirrus, and cirrus has always
been pretty good about open specs on their chips. If it were one of the
other companies I would think about giving up :-) I think we can get this.
We'll be talking to the xfree guys.

Also, in a pinch I can survive in the cluster with serial console until we
get this.

ron

-
To unsubscribe: send mail to [e-mail]
with 'unsubscribe openbios' in the body of the message

Video

[Jeff Garzik]

"Ronald G. Minnich" wrote:
> On Fri, 18 Feb 2000, Todd Whitesel wrote:
> > Talk to the XFree86 4.0 guys; they're tackling the problem right now because
> > they want to handle multi-headed machines, and (except for certain double
> > headed products from people like Matrox) only one card can occupy the legacy
> > ISA address area so extra cards never have their VGA BIOS' run at all.
>
> Thanks, that is a *great* idea.
>
> The thing is, the chip on the L440GX is a cirrus, and cirrus has always
> been pretty good about open specs on their chips. If it were one of the
> other companies I would think about giving up :-) I think we can get this.
> We'll be talking to the xfree guys.

I am an "XFree86 guy"

The current plan is to use BIOS-initialized VGA for the primary head,
and vm86 mode (BIOS and BIOS calls!) to initialize the video BIOS of all
secondary heads.  If vm86 mode is not possible, then an X86 emulator,
x86emu, does the job.

So, you need to run the video BIOS of the first head.

That's solution number one.

Solution number two:  use framebuffer devices inside Linux kernel for
video.  "fbdev" is designed mainly for machines where no text graphics
mode (e.g. vgacon) exists, but it can be used for any platform.

Video

[Ronald G. Minnich]

the thing is, as long as you depend on vga bios support, you're never
going to be openbios. One reason is that graphics are increasingly a chip
on the motherboard, with the vga bios in the motherboard nvram. There
isn't room for linux and that vga bios in the nvram. Second is, until you
get all the secrets out, we're locked in to braindead bios'es.

So we'll figure it out :-)

ron

-
To unsubscribe: send mail to [e-mail]
with 'unsubscribe openbios' in the body of the message

Video

[Jeff Garzik]

"Ronald G. Minnich" wrote:
> the thing is, as long as you depend on vga bios support, you're never
> going to be openbios. One reason is that graphics are increasingly a chip
> on the motherboard, with the vga bios in the motherboard nvram. There
> isn't room for linux and that vga bios in the nvram. Second is, until you
> get all the secrets out, we're locked in to braindead bios'es.

I agree with you!  :)
> So we'll figure it out :-)

VGA is the standard, that is why it is popular.  Linux text mode console
works because VGA works on most PCs.  Executing video BIOS is an
absolute requirement to supporting VGA in a generic fashion.

WARNING:  You are opening a huge can of worms if you ditch VGA and video
BIOS.  I think it is a good idea, but it is difficult to implement.  I
know, I've written graphics drivers.

If you do NOT want to support VGA in a generic fashion, then you MUST
include specific support for each graphics chipset your users may have. 
Those are the only two options.

Some video cards include Open Firmware ROMs.  This is the
platform-independent way of initializing the video card.  Open Firmware
ROM code is somewhat like forth, from what I've heard.

For video cards without Open Firmware support, you need to get the video
card datasheet and figure out how to initialize the card.  You must do
this for each model of each card.  Sometimes initializing to text mode
is easy, sometimes not.

This task is further complicated by the fact that _many_ video cards
invest a lot of tech in their video BIOS's.  BIOS stores critical
undocumented RAM timing information and similar board details which
differ from board to board, but not chip to chip.  Usually you can get
away with 100% conservative video settings, but this is not failsafe.

Once you have code to initialize popular video cards to a sane state,
you can start using linuxbios on different computers...

As i said, ditching VGA and video BIOS is a very good thing.  But it is
also difficult to get right, and requires lots of additional code over
the simply-support-VGA-the-old-way solution.

Choose well, grasshopper.  :)

Video

[Ronald G. Minnich]

ah, such fun. Jeff, can you tell me more.

On Fri, 18 Feb 2000, Jeff Garzik wrote:
> VGA is the standard, that is why it is popular.  Linux text mode console
> works because VGA works on most PCs.  Executing video BIOS is an
> absolute requirement to supporting VGA in a generic fashion.

Let's take the L440GX (please! :-). I want video on it to act like VGA.

On this board you've got to set some things in PCI config registers to
enable 'VGA mode'. These are for such things are mapping of 0xa0000 space,
MDA space, which out/in instructions go to the card, and so on.

My question to you: if I enable the address/IO bits to enable 'VGA', and
then I do VGA-style commands to the card, will the card initialize or sit
there and do nothing?

Is there really no way short of calling the video bios to init the card?

If it's true there's no other way, well, I'm not completely screwed for
cluster use, but it's still bad for everyone else.

Next question then: what's the offset in video bios of the init routine,
or how do you find it, and what's it expect? working stack? return address
in bx? Does it walk the PCI bus to find itself, and then init itself? what
should I expect?

If I can't init video from open source I'll put this one on the back
burner for now and do it later. But we've got to deal with this at some
point.

Also recall that there used to be similar arguments about things like disk
and ethernet controllers. The decision in the open source community is to
support what you can, and not try to do everything. People who really want
you to support their card will come around eventually. Intel once made me
sign a five-year NDA on the pro-100a network card; five months later they
were giving the docs away to anyone willing to write a driver for *bsd or
linux. They learned.

ron

p.s. true story: someone at a famous research lab once wrote a 386
simulator, just so he could figure out how to init a graphics card. He
booted dos on his simulator and waited for the graphics card init to run,
at which point he stopped worrying about his simulator :-) Took about a
day or two, but he said it was worth it :-)

-
To unsubscribe: send mail to [e-mail]
with 'unsubscribe openbios' in the body of the message

Video

[Jeff Garzik]

"Ronald G. Minnich" wrote:
> My question to you: if I enable the address/IO bits to enable 'VGA', and
> then I do VGA-style commands to the card, will the card initialize or sit
> there and do nothing?
>
> Is there really no way short of calling the video bios to init the card?

Each video card has a _lot_ of knowledge stored in the video BIOS.

When a card is made, an OEM takes a video chip and sticks it on their
board.  The only way for the chip to know how to correctly access board
memory, and other crucial details, are stored in the video BIOS.

The rule is:  if you do not init video BIOS, then you must init the
video on a per-chipset basis (ie. no generic VGA)
> Next question then: what's the offset in video bios of the init routine,
> or how do you find it, and what's it expect? working stack? return address
> in bx? Does it walk the PCI bus to find itself, and then init itself? what
> should I expect?

Read the PCI spec on ROMs.  Basically it can be an x86 code image, Open
Firmware code image, or something else.

You will always have the problem of having to deal with x86 code images
in expansion ROMs.  Video BIOS is only one example.

Video

[Ronald G. Minnich]

On Fri, 18 Feb 2000, Edwin Rhodes wrote:
> hi is it posible to replace a 1 meg ibm pc flash bios chip with lets say a 2
> meg or 4 meg or even 8 meg flash rom?
> or are we completely limited to 1 meg?
> edwin

I think it is not practical. The flash is a surface-mount device, and
there are not even the traces on the motherboard to connect higher density
devices. We're stuck.

ron

-
To unsubscribe: send mail to [e-mail]
with 'unsubscribe openbios' in the body of the message

Video

[Edwin Rhodes]

hi is it posible to replace a 1 meg ibm pc flash bios chip with lets say a 2
meg or 4 meg or even 8 meg flash rom?
or are we completely limited to 1 meg?
edwin

----- Original Message -----
From: Ronald G. Minnich 
To: 
Sent: Friday, February 18, 2000 9:33 AM
Subject: Re: [OpenBIOS] Video
> the thing is, as long as you depend on vga bios support, you're never
> going to be openbios. One reason is that graphics are increasingly a chip
> on the motherboard, with the vga bios in the motherboard nvram. There
> isn't room for linux and that vga bios in the nvram. Second is, until you
> get all the secrets out, we're locked in to braindead bios'es.
>
> So we'll figure it out :-)
>
> ron
>
> To unsubscribe: send mail to [e-mail]
> with 'unsubscribe openbios' in the body of the message

-
To unsubscribe: send mail to [e-mail]
with 'unsubscribe openbios' in the body of the message

Video

[Chong Chee Yong]

not familiar with this, but does the integrated graphics chip appear as
another PCI device?

On Fri, 18 Feb 2000, Ronald G. Minnich wrote:
> the thing is, as long as you depend on vga bios support, you're never
> going to be openbios. One reason is that graphics are increasingly a chip
> on the motherboard, with the vga bios in the motherboard nvram. There
> isn't room for linux and that vga bios in the nvram. Second is, until you
> get all the secrets out, we're locked in to braindead bios'es.

-
To unsubscribe: send mail to [e-mail]
with 'unsubscribe openbios' in the body of the message

Video

[Boaz Harrosh]

I know of a flash that can go in the unused ISA slot, the one shared with a
PCI and taken. I think you can go upto Gigas. And it can even be changed on
the fly ...
----- Original Message -----
From: "Ronald G. Minnich" 
To: 
Sent: Saturday, February 19, 00 2:06 AM
Subject: Re: [OpenBIOS] Video
> On Fri, 18 Feb 2000, Edwin Rhodes wrote:
> > hi is it posible to replace a 1 meg ibm pc flash bios chip with lets say

a 2
> > meg or 4 meg or even 8 meg flash rom?
> > or are we completely limited to 1 meg?
> > edwin
>
> I think it is not practical. The flash is a surface-mount device, and
> there are not even the traces on the motherboard to connect higher density
> devices. We're stuck.
>
> ron
>
> To unsubscribe: send mail to [e-mail]
> with 'unsubscribe openbios' in the body of the message

-
To unsubscribe: send mail to [e-mail]
with 'unsubscribe openbios' in the body of the message

Video

[Jeff Garzik]

Edwin Rhodes wrote:
> why dont you have a look at the bocus ibm pc emulator, that boots an image
> of the elpin vga bios, see how bocus does it.

As mentioned in a previous message, the XFree86 team uses 'x86emu' to
boot a video BIOS on any system.  Coder should look at that, it is being
actively maintained across multiple platforms AFAIK.

Video

[Edwin Rhodes]

why dont you have a look at the bocus ibm pc emulator, that boots an image
of the elpin vga bios, see how bocus does it.

----- Original Message -----
From: Jeff Garzik 
To: 
Sent: Friday, February 18, 2000 1:39 PM
Subject: Re: [OpenBIOS] Video
> "Ronald G. Minnich" wrote:
> > My question to you: if I enable the address/IO bits to enable 'VGA', and
> > then I do VGA-style commands to the card, will the card initialize or

sit
> > there and do nothing?
> >
> > Is there really no way short of calling the video bios to init the card?
>
> Each video card has a _lot_ of knowledge stored in the video BIOS.
>
> When a card is made, an OEM takes a video chip and sticks it on their
> board.  The only way for the chip to know how to correctly access board
> memory, and other crucial details, are stored in the video BIOS.
>
> The rule is:  if you do not init video BIOS, then you must init the
> video on a per-chipset basis (ie. no generic VGA)
> > Next question then: what's the offset in video bios of the init routine,
> > or how do you find it, and what's it expect? working stack? return

address
> > in bx? Does it walk the PCI bus to find itself, and then init itself?

what
> > should I expect?
>
> Read the PCI spec on ROMs.  Basically it can be an x86 code image, Open
> Firmware code image, or something else.
>
> You will always have the problem of having to deal with x86 code images
> in expansion ROMs.  Video BIOS is only one example.
>
> To unsubscribe: send mail to [e-mail]
> with 'unsubscribe openbios' in the body of the message

-
To unsubscribe: send mail to [e-mail]
with 'unsubscribe openbios' in the body of the message

Video

[Jeff Garzik]

Bob Dobbs wrote:
> If we are going to be using a BIOS which is compatible with IEEE-1275
> then we do not need to worry about VGA BIOS troubles, as the VGA BIOS
> will be machine independent FCode.

90% of all video BIOS are extremely ugly 16-bit and
32-bit-in-16-bit-mode hacks.

The other 10% are the above but include Open Firmware (for PPC mainly),
or FCode as you describe.

Video

[Bob Dobbs]

If we are going to be using a BIOS which is compatible with IEEE-1275
then we do not need to worry about VGA BIOS troubles, as the VGA BIOS
will be machine independent FCode.

But it is not likely that Open Firmware video cards (and others for that
matter) will appear over night.

-graham
-
To unsubscribe: send mail to [e-mail]
with 'unsubscribe openbios' in the body of the message