Emulating BIOS for VBE

[devsau]

Question is, anyone know if I can use the uefi setmode services for GOP to get the same resolution that my card offers using vesa/vbe?

I don't know, but I suspect the answer should be "yes". At least I don't think GOP will offer more resolutions than VBE, especially if GOP gathers information from VBE.

thanks for the response. Yeh I was just hoping I can get the same reso that I get with my OS. So that's mostly what I suspected. Cause my dev machine is uefi board, but I just use legacy boot.

and sorry to hijack your thread. I am done now.

[Owen]

Repeating what I said earlier: the graphics card provides the video BIOS. It also provides the video UEFI.

Possible. However, if you plug in the video card in a stationary PC in some PCI-slot, then the systems UEFI has no idea about the card, and the card thus cannot provide the GOP. The only thing it provides is a VBE BIOS. Which means the systems UEFI must use VBE to provide GOP.

The system's UEFI does exactly the same thing that the BIOS does! That is, it enumerates the PCI bus, looks for option ROMs, and goes "Hey, this card has a UEFI option ROM" and loads it as a UEFI driver!

Sure, some systems might include a backwards compatibility hack using VBE, but for most cases the UEFI entry in the option ROM will be used.

[Brendan]

Hi,

Possible. However, if you plug in the video card in a stationary PC in some PCI-slot, then the systems UEFI has no idea about the card, and the card thus cannot provide the GOP. The only thing it provides is a VBE BIOS. Which means the systems UEFI must use VBE to provide GOP.

The system's UEFI does exactly the same thing that the BIOS does! That is, it enumerates the PCI bus, looks for option ROMs, and goes "Hey, this card has a UEFI option ROM" and loads it as a UEFI driver!

Sure, some systems might include a backwards compatibility hack using VBE, but for most cases the UEFI entry in the option ROM will be used.

Yes.

In addition; both major 80x86 CPU manufacturers have been supplying chips with built-in GPUs for a while now (and this will get even more common - as computers get smaller and the built-in GPUs get faster the extra space/cost/hassle of a separate video cards gets harder and harder to justify). In these cases there may be no separate video card and no "video card ROM". Instead the firmware for the CPU's built-in video is typically built into the system's firmware (not into the video's pretend PCI device). If the system's firmware doesn't include support for legacy BIOS at all (which is extremely likely for small "tablet" devices and possibly also Apple computers now) then there's no reason for the manufacturer to bother including the unnecessary VBE code (for the CPU's video) in its system firmware.

In addition to that addition; VBE tends to rely on obsolete VGA compatibility which requires special hardware support to sustain (legacy VGA port forwarding, the legacy "VGA display window", etc). For "pure UEFI" there's no need for chipsets to include this special support, and (in the long term) it'd be extremely stupid to assume the chipset includes it.

To make this idiotic hack work reliably you'd need a whitelist/blacklist and (eventually) a whole bunch of "motherboard drivers" (to reconfigure chipset specific things like memory controllers, etc); plus a fall-back for the cases were firmware and/or hardware doesn't provide the necessary (now obsolete) requirements. If you do have a fall-back, then you can skip the rest and just use the fall-back on everything.

Finally; typically people want VBE after boot because the video API in their OS is a piece of crud (e.g. no resolution independence and significant other problems). If your OS video API is designed properly, the only reason you have to change video mode after boot is 3D games which require a native video driver anyway.

RDOS is sort of "special"; because his support for video was designed years ago (when it was harder to predict the future) and now he's stuck with very badly designed video support (which makes him desperate to cling on to dying technology). He ignores the fact that nobody else here is cursed with the same problem; and (while continually failing to realise it) serves as a warning against bad design decisions.


Cheers,

Brendan

[rdos]

In addition; both major 80x86 CPU manufacturers have been supplying chips with built-in GPUs for a while now (and this will get even more common - as computers get smaller and the built-in GPUs get faster the extra space/cost/hassle of a separate video cards gets harder and harder to justify). In these cases there may be no separate video card and no "video card ROM". Instead the firmware for the CPU's built-in video is typically built into the system's firmware (not into the video's pretend PCI device). If the system's firmware doesn't include support for legacy BIOS at all (which is extremely likely for small "tablet" devices and possibly also Apple computers now) then there's no reason for the manufacturer to bother including the unnecessary VBE code (for the CPU's video) in its system firmware.

The video card, in addition to network-chips (primarily WiFi chips, because most wired chips today are RTL-compatible) forms an exception in that they have not yet reached standardization, and thus still have vendors doing operating system drivers. I anticipate this will change in the future. We will see some kind of standard implementation of a graphics system and a standard WiFi-chip. Until then, it is just foolish to put down time on making native video-drivers or WiFi-drivers. Of course, if you have a specific project that could afford such a massive work, it might be worthwhile, otherwise it will not be.

In addition to that addition; VBE tends to rely on obsolete VGA compatibility which requires special hardware support to sustain (legacy VGA port forwarding, the legacy "VGA display window", etc). For "pure UEFI" there's no need for chipsets to include this special support, and (in the long term) it'd be extremely stupid to assume the chipset includes it.

VBE was an attempt to standardize graphics, which unfortunately is no longer so attractive. But until there comes a new standardized hardware specification for graphics (along with machines on the market using it), VBE is the best we have. UEFI have severely crippled VBE, so it is most sensible to just kick-out UEFI and "reinstall" VBE.

To make this idiotic hack work reliably you'd need a whitelist/blacklist and (eventually) a whole bunch of "motherboard drivers" (to reconfigure chipset specific things like memory controllers, etc); plus a fall-back for the cases were firmware and/or hardware doesn't provide the necessary (now obsolete) requirements. If you do have a fall-back, then you can skip the rest and just use the fall-back on everything.

Not so. It works with no hacks at all on 4 different machines from different vendors (Intel, AMD, Sony, Samsung). While I have not booted any of them through UEFI yet (at least 3 have UEFI boot support), it is not likely that UEFI has not mapped the video BIOS at 0xC0000, which would be the only reason it wouldn't work under UEFI.

RDOS is sort of "special"; because his support for video was designed years ago (when it was harder to predict the future) and now he's stuck with very badly designed video support (which makes him desperate to cling on to dying technology). He ignores the fact that nobody else here is cursed with the same problem; and (while continually failing to realise it) serves as a warning against bad design decisions.

I think you have failed to notice that the graphics API in RDOS is a standalone module. As such it can be replaced with another module (like a native graphics driver). But in the typical Windowing contexts you advocate, which by the way aren't able to create new consoles, or change resolution, the graphics API is so tightly connected to everything in the OS that changing this interface breaks everything. Not so in RDOS, which is why it is perfectly possible to write native video-drivers. It's just not practical with the large number of vendors that haven't made their interfaces public.

[Brendan]

Hi,

In addition; both major 80x86 CPU manufacturers have been supplying chips with built-in GPUs for a while now (and this will get even more common - as computers get smaller and the built-in GPUs get faster the extra space/cost/hassle of a separate video cards gets harder and harder to justify). In these cases there may be no separate video card and no "video card ROM". Instead the firmware for the CPU's built-in video is typically built into the system's firmware (not into the video's pretend PCI device). If the system's firmware doesn't include support for legacy BIOS at all (which is extremely likely for small "tablet" devices and possibly also Apple computers now) then there's no reason for the manufacturer to bother including the unnecessary VBE code (for the CPU's video) in its system firmware.

The video card, in addition to network-chips (primarily WiFi chips, because most wired chips today are RTL-compatible) forms an exception in that they have not yet reached standardization, and thus still have vendors doing operating system drivers. I anticipate this will change in the future. We will see some kind of standard implementation of a graphics system and a standard WiFi-chip. Until then, it is just foolish to put down time on making native video-drivers or WiFi-drivers. Of course, if you have a specific project that could afford such a massive work, it might be worthwhile, otherwise it will not be.

The only hardware standard we've ever seen for video was a de-facto VGA "standard", which was back when "PC compatible" meant "compatible with IBM's PC hardware". Because VGA wasn't designed as an official standard it didn't cover future extensions, and because video card manufacturers need a reason for people to buy their products they all had to add extensions that weren't covered by the "VGA non-standard".

For 80x86 video, the only thing I can see changing in the next 20 years is NVidia being unable to compete with cheaper/smaller "CPU+GPU" solutions and being pushed out of the market.

In addition to that addition; VBE tends to rely on obsolete VGA compatibility which requires special hardware support to sustain (legacy VGA port forwarding, the legacy "VGA display window", etc). For "pure UEFI" there's no need for chipsets to include this special support, and (in the long term) it'd be extremely stupid to assume the chipset includes it.

VBE was an attempt to standardize graphics, which unfortunately is no longer so attractive. But until there comes a new standardized hardware specification for graphics (along with machines on the market using it), VBE is the best we have.

VBE was an attempt to standardize a very small part of graphics (setting video modes and nothing else). VBE-AF attempted to standardize another part of graphics (2D/3D acceleration) but it failed; and (ignoring software interfaces intended for applications, like OpenGL and OpenCL) there's been no attempt to standardize the remainder (video memory management, GPGPU, etc). Basically; the only thing we've ever had is "something that provides bare minimum functionality during boot" where native video drivers are necessary to get more than the bare minimum.

UEFI have severely crippled VBE, so it is most sensible to just kick-out UEFI and "reinstall" VBE.

UEFI discarded all software interfaces intended for BIOS (including VBE) and replaced them all with newer interfaces (including GOP). What is sensible is to use the correct interface (GOP) instead of attempting to reanimate the corpse of a deceased software interface that was intended for a completely different environment (VBE).

To make this idiotic hack work reliably you'd need a whitelist/blacklist and (eventually) a whole bunch of "motherboard drivers" (to reconfigure chipset specific things like memory controllers, etc); plus a fall-back for the cases were firmware and/or hardware doesn't provide the necessary (now obsolete) requirements. If you do have a fall-back, then you can skip the rest and just use the fall-back on everything.

Not so. It works with no hacks at all on 4 different machines from different vendors (Intel, AMD, Sony, Samsung). While I have not booted any of them through UEFI yet (at least 3 have UEFI boot support), it is not likely that UEFI has not mapped the video BIOS at 0xC0000, which would be the only reason it wouldn't work under UEFI.

Um, what? You failed to test if VBE works when UEFI is used on 4 machines (out of the several million different machines that exist now, and several billion that will exist in future); and from this failure to test anything on an insignificant number of computers you conclude that VBE works now and will continue to work forever?

What you're saying is that VBE works now if you boot using BIOS and don't use UEFI at all. Wow - I'm sure nobody would've expected that.

it is not likely that UEFI has not mapped the video BIOS at 0xC0000, which would be the only reason it wouldn't work under UEFI.

You're a complete moron. I fail to understand how someone could remain so ignorant and wrong.

If the video card has a ROM at all (it may not); then that ROM can contain several different "ROM images" (e.g. one for VBE and one for UEFI) and UEFI firmware may use the "UEFI ROM image" and not use VBE at all. Even if UEFI firmware does happen to use a "VBE ROM image" then it may map the "VBE ROM image" at 0xC00000 and then unmap it when you exit boot services.

Eventually everything will change to "pure UEFI" (rather than the current "BIOS+UEFI hybrid" systems we're seeing now), and then no new systems will need any "VBE ROM image" at all, and the hardware that obsolete VBE ROMs rely on may be completely removed from chipsets (in addition to the removal of A20 gate, PIC chips, PIT chip, PS2 controller, etc).

RDOS is sort of "special"; because his support for video was designed years ago (when it was harder to predict the future) and now he's stuck with very badly designed video support (which makes him desperate to cling on to dying technology). He ignores the fact that nobody else here is cursed with the same problem; and (while continually failing to realise it) serves as a warning against bad design decisions.

I think you have failed to notice that the graphics API in RDOS is a standalone module. As such it can be replaced with another module (like a native graphics driver). But in the typical Windowing contexts you advocate, which by the way aren't able to create new consoles, or change resolution, the graphics API is so tightly connected to everything in the OS that changing this interface breaks everything. Not so in RDOS, which is why it is perfectly possible to write native video-drivers. It's just not practical with the large number of vendors that haven't made their interfaces public.

Um..

You can't change a "graphics API module" and expect all software (GUI, applications) that were designed for the old graphics API to suddenly rewrite themselves to be compatible with a different graphics API. For every (sane) OS you can create as many new consoles as you like whenever you like (but it's impossible for software to make new video/monitor hardware appear out of thin air). For the system I advocate, the only thing that needs to know/care about video modes is the video driver, and the graphics API that applications use is a high-level thing. It's impossible for applications to use "nothing" to describe what they want the user to see, and stupid to complain that applications and GUI both know about the graphics API that allows applications to talk to the GUI (or allows the GUI to talk to the video driver).

For video mode switching after boot; who actually cares? The fact is that modern monitors have a "native resolution", so you use that resolution (or as close to it as you can get) and never change video modes unless you change monitors. If you need to reboot to change video modes (because you don't have any native video driver); then nobody cares because nobody replaces their monitor that often anyway. The only exception to this is modern 3D games (which require 3D acceleration and therefore require a native video driver anyway, where the native video driver that is required anyway would be capable of switching video modes without a reboot).

The real answer here is that only people who have bad graphics APIs (with no resolution independence) need to care about video mode switching; because in this case either all applications have to support all video modes (which is insane) or you have to switch video modes whenever you switch between applications (which is insane, and means you can't have applications running in their own windows regardless of how much you want it and how hard you try to pretend that you don't want it).


Cheers,

Brendan

[rdos]

The only hardware standard we've ever seen for video was a de-facto VGA "standard", which was back when "PC compatible" meant "compatible with IBM's PC hardware". Because VGA wasn't designed as an official standard it didn't cover future extensions, and because video card manufacturers need a reason for people to buy their products they all had to add extensions that weren't covered by the "VGA non-standard".

VBE works as a standard. It defines video modes and how they are arranged + exports a LFB. This is all you need for non-accelerated video. Most importantly, it doesn't restrict this interface to boot-only, so you can use it in your OS.

Um, what? You failed to test if VBE works when UEFI is used on 4 machines (out of the several million different machines that exist now, and several billion that will exist in future); and from this failure to test anything on an insignificant number of computers you conclude that VBE works now and will continue to work forever?

What you're saying is that VBE works now if you boot using BIOS and don't use UEFI at all. Wow - I'm sure nobody would've expected that.

I think what I said is that you can reinitialize the VBE interface without a real BIOS (you only need a mapped IVT to int 15 that returns failure). I wouldn't exactly call that being dependent on a BIOS.

I will eventually check if it works when booting with UEFI, but I have no working UEFI boot-loader yet.

If the video card has a ROM at all (it may not); then that ROM can contain several different "ROM images" (e.g. one for VBE and one for UEFI) and UEFI firmware may use the "UEFI ROM image" and not use VBE at all. Even if UEFI firmware does happen to use a "VBE ROM image" then it may map the "VBE ROM image" at 0xC00000 and then unmap it when you exit boot services.

The machines I tested on obviously had a VBE ROM

Eventually everything will change to "pure UEFI" (rather than the current "BIOS+UEFI hybrid" systems we're seeing now), and then no new systems will need any "VBE ROM image" at all, and the hardware that obsolete VBE ROMs rely on may be completely removed from chipsets (in addition to the removal of A20 gate, PIC chips, PIT chip, PS2 controller, etc).

Sure, but I need a machine that has both VBE and UEFI to make the transition to this kind of crap.

Besides, the presence of A20 gate, PIC, PIT and PS2 controller doesn't have anything to with VBE either. These are completely different issues. My OS runs just fine without all of these.

[Owen]

The thing I don't get, rdos, is why you expect that the VBE ROM will always be at 0xC0000 and try to pull it from there?

As I've said before: the thing you want to do - the thing X11 does on non-PCs - is to enumerate the PCI bus, find the graphics card, and extract the option ROM from it. If you look in that option ROM, you'll find headers - headers telling you what kind of option ROM it is!

For most graphics card, the likelihood is that at least one of these ROM headers will be a BIOS option ROM. That's the one you want to use to animate VBE.

Note that even if the video option ROM is at 0xC0000 - a big if on BIOS machines since PCI 3; very unlikely on EFI, the version that the BIOS has loaded there is not guaranteed to be complete. Indeed, PCI 3 option ROMs can be built such that the BIOS will unmap initialization code after the option ROM has initialized.

Supporting VBE in this way is, well, probably better than nothing, and experience suggests it works quite well. As well as VBE ever does, anyway.

Nb. 1: For some legacy video cards, the mode switching interface is independent of the video acceleration interface. For these, the often done thing - even by the Windows drivers for the card - is to delegate mode switching to VBE. This is especially the case for some cards where there is no external indication which CRTC chip is being used

Nb. 2: For native mode switching support, divide your graphics cards into the three major vendors. For Intel, there is no generic solution, but at least there are good docs. For AMD, you want to implement an interpreter for AtomBIOS, their configuration bytecode interface (if you disassemble the option ROM you'll find it just interprets the AtomBIOS code, too!). For NVIDIA, you want to implement an interpreter for their configuration bytecode interface. Thats the tricky one, being as NVIDIA aren't historically a fan of releasing documentation (though there is evidence that change may be happening in that area)

[rdos]

The thing I don't get, rdos, is why you expect that the VBE ROM will always be at 0xC0000 and try to pull it from there?

As I've said before: the thing you want to do - the thing X11 does on non-PCs - is to enumerate the PCI bus, find the graphics card, and extract the option ROM from it. If you look in that option ROM, you'll find headers - headers telling you what kind of option ROM it is!

I agree. This seems to be the optimal way to do it.

Can you give me a clue as to where the documentation for option ROMs is? I don't remember reading it in the PCI specification as least.

[Brynet-Inc]

Can you give me a clue as to where the documentation for option ROMs is? I don't remember reading it in the PCI specification as least.

It's in the PCI 3.0 specifications, search for "PCI Expansion ROMs". It starts on page 228 and continues until 235.

There's ROM types defined for BIOS (PC-AT), OpenFirmware, HPPA/PA-RISC and EFI.

[rdos]

Can you give me a clue as to where the documentation for option ROMs is? I don't remember reading it in the PCI specification as least.

It's in the PCI 3.0 specifications, search for "PCI Expansion ROMs". It starts on page 228 and continues until 235.

There's ROM types defined for BIOS (PC-AT), OpenFirmware, HPPA/PA-RISC and EFI.

Thanks. I found it.

This is especially important in relation to what Brendan claimed before:

Prior to calling the INIT function, the POST code will allocate resources to the device (via
the Base Address and Interrupt Line registers).

In other words, the VBE ROM does not allocate resources for PCI, this should already be done before initializing VBE, and thus calling the VBE INIT entry-point a second time will not mess-up PCI memory allocation.

[Brynet-Inc]

In other words, the VBE ROM does not allocate resources for PCI, this should already be done before initializing VBE, and thus calling the VBE INIT entry-point a second time will not mess-up PCI memory allocation.

The existence of a VBE ROM does not mean it was ever executed by firmware. A device may contain multiple ROM's.

IMHO, if the EFI firmware initialized the graphics using the EFI expansion ROM module (..either on device or part of the firmware), it would be silly to assume that it would be safe to attempt to initialize it with the VBE ROM.

[rdos]

I think an updated algorithm will be needed. Of my 4 test machines, only one has an option ROM in PCI space. This one has a fairly new AMD mother-board with an add-on graphics card. My almost new Sony Laptop obviously doesn't have option ROMs, and it can boot both legacy and UEFI.

Given this, I think the algorithm will be to first search for option ROMs, and if those are found, map them to physical address 0xC0000, allocate space for the RAM copy, and copy contents of the BIOS ROM version. Then map this RAM copy to 0xC0000 linear. If an option ROM is not found, map physical address 0xC0000 to linear address 0xC0000. After that, check for a value AA55 signature, and if found, do the VBE initialization.

[Owen]

For those machines which no option ROM in PCI space (but instead one at 0xC0000), do they have PCI expansion headers? If so, that would seem like a good cross check (you might also want to scan the entire option ROM space).

(Regardless, I wouldn't assume that they'll be present in the case of UEFI boot)

[rdos]

For those machines which no option ROM in PCI space (but instead one at 0xC0000), do they have PCI expansion headers? If so, that would seem like a good cross check (you might also want to scan the entire option ROM space).

No. When I read PCI register 0x30, it always returns 0. This is regardless of what I write to it, like 0xFFFFF000 or 0xFFFFF001 to detect depth. On the machine that does support register 0x30, it returns 0xFFFE0000.

[Owen]

I mean the PCI expansion header in the option ROM itself. That is, the option ROM should contain a table describing which devices it is for.