31 Mar
2000
31 Mar
'00
4:50 p.m.
If someone has the *code* example for calling the vga init on a vga card I
could use it.
ron
-
To unsubscribe: send mail to majordomo(a)freiburg.linux.de
with 'unsubscribe openbios' in the body of the message
4 Apr
4 Apr
2:05 p.m.
"Ronald G. Minnich" wrote:
If someone has the *code* example for calling the vga init on a vga card I
could use it.
Sorry for the delay. No distractions this time, only assembly code
for swithing video modes. ;-) This work, at least for me. Obviously,
I'm not writing BIOS usually :o) .. so, I don't know if it lacks
something for functioning as part of firmware.
Included as attachment:
modsrc21.zip -- 18.402 bytes
P.S.: sorry for my bad English.
--
Massimo Dentico
9:41 p.m.
Massimo Dentico wrote:
"Ronald G. Minnich" wrote:
Thanks for posting code, unfortunately this code does not call the VGA
BIOS to initialize the video card -- this code directly programs the VGA
registers to switch modes, just like vga16fb in the Linux kernel.
BIOS init must have already executed in order for this code to work.
Regards,
Jeff
--
Jeff Garzik | Tact is the ability to tell a man
Building 1024 | he has an open mind when he has a
MandrakeSoft, Inc. | hole in his head. (-random fortune)
-
To unsubscribe: send mail to majordomo(a)freiburg.linux.de
with 'unsubscribe openbios' in the body of the message
If someone has the *code* example for calling the vga init on a vga card I
could use it.
Sorry for the delay. No distractions this time, only assembly code
for swithing video modes. ;-) This work, at least for me. Obviously,
I'm not writing BIOS usually :o) .. so, I don't know if it lacks
something for functioning as part of firmware. 
9:58 p.m.
Hi,
Jeff Garzik wrote:
Massimo Dentico wrote:
From a previous pose by 'James' at Berkeley, on Feb 17th 2000:
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.
--
Yours
Matthew
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
More Computer Terminology
-=-=-=-=-=-=-=-=-=-=-=-=-
Hardware: The bit that makes the noise when you throw you computer out the window.
"Ronald G. Minnich" wrote:
Thanks for posting code, unfortunately this code does not call the VGA
BIOS to initialize the video card -- this code directly programs the VGA
registers to switch modes, just like vga16fb in the Linux kernel.
BIOS init must have already executed in order for this code to work.
If someone has the *code* example for calling the vga init on a vga card I
could use it.
Sorry for the delay. No distractions this time, only assembly code
for swithing video modes. ;-) This work, at least for me. Obviously,
I'm not writing BIOS usually :o) .. so, I don't know if it lacks
something for functioning as part of firmware.
11:21 p.m.
Matthew Sullivan wrote:
Jeff Garzik wrote:
From a previous pose by 'James' at Berkeley, on Feb 17th 2000:
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 che
cks 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 extensio!
!
!
!
n BIOSes
perform initialization and then return. On entry,
SS:SP must be set up as a valid stack.
Thanks, I missed that post. Yes, this is exactly what FreeBIOS/OpenBIOS
needs to do in order to be able to display video.
Note that many BIOSs do video POST as soon as possible, but initialize
other expansion ROMs much later in the boot cycle.
Jeff
--
Jeff Garzik | Tact is the ability to tell a man
Building 1024 | he has an open mind when he has a
MandrakeSoft, Inc. | hole in his head. (-random fortune)
-
To unsubscribe: send mail to majordomo(a)freiburg.linux.de
with 'unsubscribe openbios' in the body of the message
11:42 p.m.
Hi,
Jeff Garzik wrote:
Matthew Sullivan wrote:
Actually from my expreience with Award and AM BIOS's they test for 55AA at A000 and
then C000 looking for a mono card then then a colour booting the first card found and
ignoring any second card.... (ie if a mono and colour cards are both present)....
The only thing I haven't worked out is if you have a card not located in the usual
position most BIOS's will still boot it... but none of the BIOS's seem to want to
init any second card.... (That includes the second VGA port on a couple of twin TVGA 9000
series cards I had to work on a while ago...)
My conclusion to this is there must be a global identifier to indicate the card is a
display card... and the current BIOS's look for this so that they can determine, 1/
There is a display card in the system, and 2/ where it is ... I say this because last time
I put 2 PCI VGA cards in a machine (not the same type) no matter what addresses I set them
to and which slot they physically located, the same card booted each time...!?! This may
be worth investigating further....
--
Yours
Matthew
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
I see you've set aside this special time to humiliate yourself in public.
From a previous pose by 'James' at
Berkeley, on Feb 17th 2000:
Thanks, I missed that post. Yes, this is exactly what
FreeBIOS/OpenBIOS
needs to do in order to be able to display video.
Note that many BIOSs do video POST as soon as possible, but initialize
other expansion ROMs much later in the boot cycle.
5 Apr
5 Apr
1:03 a.m.
Can you turn on word wrap in your mailer, Matthew?
Matthew Sullivan wrote:
Actually from my expreience with Award and AM
BIOS's they test for 55AA at A000 and then C000 looking for a mono card then then a
colour booting the first card found and ignoring any second card.... (ie if a mono and
colour cards are both present)....
Yep, sounds like a good plan.
The only thing I haven't worked out is if you have
a card not located in the usual position most BIOS's will still boot it... but none of
the BIOS's seem to want to init any second card.... (That includes the second VGA port
on a couple of twin TVGA 9000 series cards I had to work on a while ago...)
By virtue of the fact that two cards cannot share a single VGA region,
you can only init a single card. So that makes perfect sense. The
standard BIOS reaction to multiple video cards is to -not- execute the
BIOS init sequence for secondary/tertiary cards, but to instead disable
their MMIO and PIO decoding altogether. This is why XFree86 must map
and execute the video BIOS for a secondary card, before it can be used
as a secondary head.
My conclusion to this is there must be a global
identifier to indicate the card is a display card... and the current BIOS's look for
this so that they can determine, 1/ There is a display card in the system, and 2/ where it
is ... I say this because last time I put 2 PCI VGA cards in a machine (not the same type)
no matter what addresses I set them to and which slot they physically located, the same
card booted each time...!?! This may be worth investigating further....
Now -that- is strange. If there is no video BIOS in the standard
location, it would seem logical to initialize the first
PCI_CLASS_DISPLAY card found... or maybe PCI_CLASS_DISPLAY_VGA.
Jeff
--
Jeff Garzik | Tact is the ability to tell a man
Building 1024 | he has an open mind when he has a
MandrakeSoft, Inc. | hole in his head. (-random fortune)
-
To unsubscribe: send mail to majordomo(a)freiburg.linux.de
with 'unsubscribe openbios' in the body of the message
1:16 a.m.
Hi,
Actually you answered the problem....
Jeff Garzik wrote:
Can you turn on word wrap in your mailer, Matthew?
I have but it's set to a high figure to stop it screwing with my mails... Doh! :-)
Matthew Sullivan wrote:
Which answers it...
The only thing I haven't worked out is if you
have a card not located in the usual position most BIOS's will still boot it... but
none of the BIOS's seem to want to init any second card.... (That includes the second
VGA port on a couple of twin TVGA 9000 series cards I had to work on a while ago...)
By virtue of the fact that two cards cannot share a single VGA region,
you can only init a single card. So that makes perfect sense. The
standard BIOS reaction to multiple video cards is to -not- execute the
BIOS init sequence for secondary/tertiary cards, but to instead disable
their MMIO and PIO decoding altogether. This is why XFree86 must map
and execute the video BIOS for a secondary card, before it can be used
as a secondary head.
However cards/the bus seem to have 'priority' between cards (I do _not_ know PCI
bus operation) two different cards would work in different ways and have a different
priority as to what memory areas they get.... As the card is not in the 'default
video' location it's getting picked up on and by the PCI bus/PCI controller/PCI
software and then being initallized...
First one started on the bus reset gets initiallized...? ...The answer...?
--
Yours
Matthew
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
You are validating my inherent mistrust of strangers.
My conclusion to this is there must be a global
identifier to indicate the card is a display card... and the current BIOS's look for
this so that they can determine, 1/ There is a display card in the system, and 2/ where it
is ... I say this because last time I put 2 PCI VGA cards in a machine (not the same type)
no matter what addresses I set them to and which slot they physically located, the same
card booted each time...!?! This may be worth investigating further....
Now -that- is strange. If there is no video BIOS in the standard
location, it would seem logical to initialize the first
PCI_CLASS_DISPLAY card found... or maybe PCI_CLASS_DISPLAY_VGA. 
5:15 a.m.
Jeff,
The order that video cards get initialized is based on the bus they are
operating on (PCI or ISA), the PCI bus scanning order (lowest to highest
device or highest to lowest device) and BIOS setup options (AGP over PCI or
PCI over AGP). An ISA video should be initialized first. If no ISA then
generally the PCI device closest to the host-PCI bridge and with the lowest
device number (swapping two VGA cards between two slots should give an
indication of which PCI slot is the lower device number). Some BIOS have
settings to allow an AGP device to be initialized first (AGP is usually on
PCI bus 1, many PCI VGA cards will be located on PCI bus 0, though some
systems may also have a PCI-PCI bridge and this wouldn't be true). Of
course, vendors are free to make exceptions to this and may have other
criteria of making the decision (a VGA card with the OPROM disabled like
some Matrox cards probably won't be initialized as the boot video device).
The VGA card is identified by its class code in PCI configuration space.
Dave
-----Original Message-----
From: owner-openbios(a)elvis.informatik.uni-freiburg.de
[mailto:owner-openbios@elvis.informatik.uni-freiburg.de]On Behalf Of
Matthew Sullivan
Sent: Tuesday, April 04, 2000 4:16 PM
To: Jeff Garzik
Cc: OpenBIOS
Subject: Re: [OpenBIOS] sorry to ask this again
Hi,
Actually you answered the problem....
Jeff Garzik wrote:
Can you turn on word wrap in your mailer, Matthew?
I have but it's set to a high figure to stop it screwing with my mails...
Doh! :-)
Matthew Sullivan wrote:
> The only thing I haven't worked out is if you have a card not located in
the usual position most BIOS's will still boot it... but none of the BIOS's
seem to want to init any second card.... (That includes the second VGA port
on a couple of twin TVGA 9000 series cards I had to work on a while ago...)
By virtue of the fact that two cards cannot share a single VGA region,
you can only init a single card. So that makes perfect sense. The
standard BIOS reaction to multiple video cards is to -not- execute the
BIOS init sequence for secondary/tertiary cards, but to instead disable
their MMIO and PIO decoding altogether.
Which answers it...
This is why XFree86 must map
and execute the video BIOS for a secondary card, before it can be used
as a secondary head.
> My conclusion to this is there must be a global identifier to indicate
the
card is a display card... and the current BIOS's look for this so that
they can determine, 1/ There is a display card in the system, and 2/ where
it is ... I say this because last time I put 2 PCI VGA cards in a machine
(not the same type) no matter what addresses I set them to and which slot
they physically located, the same card booted each time...!?! This may be
worth investigating further....
Now -that- is strange. If there is no video BIOS in the standard
location, it would seem logical to initialize the first
PCI_CLASS_DISPLAY card found... or maybe PCI_CLASS_DISPLAY_VGA.
However cards/the bus seem to have 'priority' between cards (I do _not_ know
PCI bus operation) two different cards would work in different ways and have
a different priority as to what memory areas they get.... As the card is
not in the 'default video' location it's getting picked up on and by the PCI
bus/PCI controller/PCI software and then being initallized...
First one started on the bus reset gets initiallized...? ...The answer...?
--
Yours
Matthew
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
You are validating my inherent mistrust of strangers.
-
To unsubscribe: send mail to majordomo(a)freiburg.linux.de
with 'unsubscribe openbios' in the body of the message
2:36 a.m.
By virtue of the fact that two cards cannot share a
single VGA region,
you can only init a single card. So that makes perfect sense. The
standard BIOS reaction to multiple video cards is to -not- execute the
BIOS init sequence for secondary/tertiary cards, but to instead disable
their MMIO and PIO decoding altogether. This is why XFree86 must map
and execute the video BIOS for a secondary card, before it can be used
as a secondary head.
I am curious: Does XFree86 drop _back_ into 16-bit mode to initialize
the second video BIOS?
- James
-
To unsubscribe: send mail to majordomo(a)freiburg.linux.de
with 'unsubscribe openbios' in the body of the message
4 Apr
4 Apr
11:13 p.m.
Jeff Garzik wrote:
Massimo Dentico wrote:
Ops .. an error due to my scarce knowledge of PC hardware
and this phrase on the Linux BIOS home page: ".. simple VGA
capability up WITHOUT a VGA BIOS ..". So, is there an absolutely
necessary initialization phase that precede the setting of a
video mode? To switch a video mode requires the setting of dozens
of registers .. I hope that the init phase isn't so complicated.
Sorry again, my intention was only to help.
Best regard.
--
Massimo Dentico
-
To unsubscribe: send mail to majordomo(a)freiburg.linux.de
with 'unsubscribe openbios' in the body of the message
"Ronald G. Minnich" wrote:
Thanks for posting code, unfortunately this code does not call the VGA
BIOS to initialize the video card -- this code directly programs the VGA
registers to switch modes, just like vga16fb in the Linux kernel.
BIOS init must have already executed in order for this code to work.
Regards,
Jeff
If someone has the *code* example for calling the vga init on a vga card I
could use it.
Sorry for the delay. No distractions this time, only assembly code
for swithing video modes. ;-) This work, at least for me. Obviously,
I'm not writing BIOS usually :o) .. so, I don't know if it lacks
something for functioning as part of firmware.
5 Apr
5 Apr
1:10 a.m.
Massimo Dentico wrote:
Jeff Garzik wrote:
> Massimo Dentico wrote:
> > Sorry for the delay. No distractions this time, only assembly code
> > for swithing video modes. ;-) This work, at least for me. Obviously,
> > I'm not writing BIOS usually :o) .. so, I don't know if it lacks
> > something for functioning as part of firmware.
> Thanks for posting code, unfortunately this code
does not call the VGA
> BIOS to initialize the video card -- this code directly programs the VGA
> registers to switch modes, just like vga16fb in the Linux kernel.
>
> BIOS init must have already executed in order for this code to work.
Ops .. an error due to my scarce knowledge of PC
hardware
and this phrase on the Linux BIOS home page: ".. simple VGA
capability up WITHOUT a VGA BIOS ..". So, is there an absolutely
necessary initialization phase that precede the setting of a
video mode? To switch a video mode requires the setting of dozens
of registers .. I hope that the init phase isn't so complicated.
The init phase is not complicated at all -- when your computer is
booted, one of the first things it does is run the video BIOS. The
video BIOS is the only place which contains the information necessary to
set up VGA compatibility. The video BIOS must, for example, program
chipset-specific registers before it may access framebuffer memory.
Once all that initialization is complete, you can access the video card
in one of two ways -- indirectly, by issuing BIOS calls, or directly, by
programming the VGA and/or extended registers built into the video
chip. vesafb in the Linux kernel is an example of using BIOS calls.
vga16fb is an example of directly programming the VGA registers.
Sorry again, my intention was only to help.
no problem at all... all contributions, especially ones with code
included, are valuable
Jeff
--
Jeff Garzik | Tact is the ability to tell a man
Building 1024 | he has an open mind when he has a
MandrakeSoft, Inc. | hole in his head. (-random fortune)
-
To unsubscribe: send mail to majordomo(a)freiburg.linux.de
with 'unsubscribe openbios' in the body of the message
6:09 p.m.
Jeff Garzik wrote:
Massimo Dentico wrote:
You are right, I had sent the e-mail before read the post of
Matthew Sullivan. It doesn't seem so difficult.
Jeff Garzik wrote:
> Massimo Dentico wrote:
> > Sorry for the delay. No distractions this time, only assembly code
> > for swithing video modes. ;-) This work, at least for me. Obviously,
> > I'm not writing BIOS usually :o) .. so, I don't know if it lacks
> > something for functioning as part of firmware.
> Thanks for posting code, unfortunately this
code does not call the VGA
> BIOS to initialize the video card -- this code directly programs the VGA
> registers to switch modes, just like vga16fb in the Linux kernel.
>
> BIOS init must have already executed in order for this code to work.
Ops .. an error due to my scarce knowledge of PC
hardware
and this phrase on the Linux BIOS home page: ".. simple VGA
capability up WITHOUT a VGA BIOS ..". So, is there an absolutely
necessary initialization phase that precede the setting of a
video mode? To switch a video mode requires the setting of dozens
of registers .. I hope that the init phase isn't so complicated.
The init phase is not complicated at all ... -- when your computer is booted, one of the first
things it does is
run the video BIOS. The video BIOS is the only place which contains
the information necessary to set up VGA compatibility. The video BIOS
must, for example, program chipset-specific registers before it may
access framebuffer memory.
Once all that initialization is complete, you can access the video card
in one of two ways -- indirectly, by issuing BIOS calls, or directly, by
programming the VGA and/or extended registers built into the video
chip.
I know this; the only thing that I have missed, until now, is that
the video card doesn't start directly in VGA compatible mode.
vesafb in the Linux kernel is an example of using BIOS
calls.
vga16fb is an example of directly programming the VGA registers.
Thanks for the patience. :-)
--
Massimo Dentico
-
To unsubscribe: send mail to majordomo(a)freiburg.linux.de
with 'unsubscribe openbios' in the body of the message
Sorry again, my intention was only to help.
no problem at all... all contributions, especially ones with code
included, are valuable
7472
days inactive
7477
days old
12 comments
6 participants
participants (6)
-
David Christensen -
James -
Jeff Garzik -
Massimo Dentico -
Matthew Sullivan -
Ronald G. Minnich