Qestions about VESA/VBE

[MadZarx]

IMHO, it's even better to use ready bootloaders and concentrate on things that are more interesting.
Are you sure that you want your own set of bootloaders?
Why don't you want to use, for example, GRUB or OS Boot Tools?

I have tried GRUB. But it doesn't give me correct VBE information. I also want to experience more assembly with writing my own bootloaders. I could use GRUB if it could give me the exact VBE information I ask. But it doesnt
Also writing GRUB inside of my kernel boot image (FAT or ISO) will increase the image size but if I write my own bootloader, the size wont exceed 1MB. I want my kernel to be as small as possible

[Brendan]

Hi,

You will need to write a separate bootloader for each different kind of CPU (e.g. 80x86, ARM, PowerPC, etc); but you won't need a separate bootloader for each different "sub-kind" (e.g. Intel 80x86, AMD 80x86, VIA 80x86, etc).

You will need a separate bootloader for each different kind of firmware (e.g. BIOS, UEFI, OpenFirmware, etc). In some cases (e.g. BIOS) you will also need a separate bootloader for each category of boot device, but in other cases (UEFI) a single bootloader covers all types of boot device.

So is there a way to write a portable bootloader that these frimwares can support? Or they have different interrupts and this is not possible?

No, BIOS is very different to UEFI (different CPU mode, different functions/APIs, etc).

For BIOS boot loaders, in theory it might be possible to have one "generic BIOS boot loader" that auto-detects the type of device it was booted from and does different things to suit different cases, but in practice it'd be extremely hard (due to having less than 512 bytes to work with initially for some of those cases). A better idea (for BIOS boot loaders) might be to have many different versions of "stage 1a" (one for each different type of boot device - floppy, MBR partitioned disk, GPT partitioned disk, network, CD-ROM) that load files from whichever device they're for; with a "stage 1b" that does all the common stuff (like getting a memory map, like setting a video mode, etc).

Of course for UEFI (where the type of boot device doesn't matter) you might just have a single piece of source code for "stage 1"; which is compiled for each different architecture (e.g. one for 64-bit 80x86, one for Itanium, one for ARM, one for 32-bit 80x86, etc).

You probably can find a C compiler that is able to generate 16-bit code. None of the BIOS functions use C calling conventions though, so at a minimum you'd need assembly wrappers for them. Those wrappers could also switch from 32-bit to 16-bit and back (so that you can use 32-bit C); and those wrappers could be implemented in "stage 1" (allowing you to have a stage 2 that only contains 32-bit code, which uses an API provided by stage 1 to do the dirty work).

Aw switching from 32bit to 16bit and reverse is a dirty work to call a BIOS interrupt from C. Its better to write all of the bootloader in assembly

It's better for me to use 100% assembly; but people that don't know and/or don't like assembly might prefer to have the minimum amount of assembly...

IMHO, it's even better to use ready bootloaders and concentrate on things that are more interesting.
Are you sure that you want your own set of bootloaders?
Why don't you want to use, for example, GRUB or OS Boot Tools?

My normal advice is to write your own "temporary boot loader" (just to learn how they work); then throw it away and use GRUB/multiboot; then once your OS has grown to the point where GRUB/multiboot has become a severe limitation write your own boot loaders. MadZarx wants decent/reliable graphics and has therefore reached the "GRUB/multiboot has become a severe limitation" point early.


Cheers,

Brendan

[MadZarx]

So if I write a bootloader using brokentron os development series, will that bootloader work on most of BIOS frimwares??

You mean UEFI systems has a standard and just cpu instructions are different?

1 question. If grub doesnt give correct VBE information, so how linux distributions loads the exact supported resolution we ask?

[Brendan]

Hi,

So if I write a bootloader using brokentron os development series, will that bootloader work on most of BIOS frimwares??

If you write one boot loader for BIOS that's designed to boot from hard disk; then that boot loader should work to boot from hard disk for all computers that support BIOS. However; it won't suddenly support booting from floppy or network or "no emulation El Torito" CD-ROM on any system (because it's only designed to boot from hard disk).

You mean UEFI systems has a standard and just cpu instructions are different?

Yes - the functions provided by UEFI are the same (same return values, same arguments, same behaviour) on all computers that support UEFI (e.g. 80x86, Itanium and ARM); and in addition you can just ask UEFI to load files without caring if the boot device is floppy or hard disk or CD-ROM or network (and don't need different boot loaders for different boot devices).

1 question. If grub doesnt give correct VBE information, so how linux distributions loads the exact supported resolution we ask?

For a start, Linux doesn't use multiboot - Linux uses The Linux/x86 Boot Protocol. In practice the user has to either use text mode, or manually configure both Linux and GRUB to suit their specific computer to avoid problems with video during boot (until the native video driver takes over). Note: what I mean here is that Linux is still "worse than good", even though GRUB developers care a lot about making Linux boot nicely and don't care about making multiboot work at all anymore.


Cheers,

Brendan

[MadZarx]

So the code for the boot devices is different.
Thank you so much brendan for your great informations and helps

[rdos]

Hi,

So as you said, VM86 is not supported in UEFI systems.

Not quite. VM86 is supported in protected mode (and not supported in long mode) regardless of what the firmware is (BIOS or UEFI). VBE functions don't exist if the firmware is UEFI though, so for the "32-bit UEFI" case VM86 can be used but there's nothing to use it for.

That's not correct either. If the video card has a VBE interface, this interface can be used regardless if you booted with BIOS or UEFI. The only problem is that if your computer booted with UEFI, you will have no valid BIOS environment, and thus need to emulate what BIOS does at startup, like detecting cards and starting them up. This can be done in VM86 mode. If you add this when you booted with UEFI (possibly also when you booted with BIOS to make it uniform), you can use VBE regardless of boot-mode from VM86-mode. Of course, you need to switch to protected mode if your OS uses long-mode before using VM86.

[Brendan]

Hi,

Not quite. VM86 is supported in protected mode (and not supported in long mode) regardless of what the firmware is (BIOS or UEFI). VBE functions don't exist if the firmware is UEFI though, so for the "32-bit UEFI" case VM86 can be used but there's nothing to use it for.

That's not correct either. If the video card has a VBE interface, this interface can be used regardless if you booted with BIOS or UEFI. The only problem is that if your computer booted with UEFI, you will have no valid BIOS environment, and thus need to emulate what BIOS does at startup, like detecting cards and starting them up. This can be done in VM86 mode. If you add this when you booted with UEFI (possibly also when you booted with BIOS to make it uniform), you can use VBE regardless of boot-mode from VM86-mode. Of course, you need to switch to protected mode if your OS uses long-mode before using VM86.

VBE is a software interface. That software interface can't exist without BIOS.

You might be able to make it exist; by initialising the video card's ROM (if the video card's ROM actually exists and still contains old code for VBE) and making it usable (e.g. mess with the chipsets/memory controller and any bridges to enable obsolete legacy VGA stuff, if the hardware still supports it). However, this is far too risky (as the BIOS and its obsolete interfaces finishes its slow death, the chance of the necessary ROM and hardware existing will decrease towards zero) and would take far too much effort to do it semi-reliably (note: were not interested in "cowboy hack-jobs"); so only a complete moron would bother doing something so idiotic.


Cheers,

Brendan

[rdos]

VBE is a software interface. That software interface can't exist without BIOS.

Wrong. Today's VBE interfaces don't rely on BIOS. They make a few calls to int 15h with AH=5F and AH=4E, and if these fails, just continues working as expected. They also don't need a functional timer-tic, doesn't need specific variables in the BDA (a zeroed BDA works on 4 out of 4 tested VBEs). Thus, in order to activate VBE, you only need an int 15 vector that returns failure on everything, and an empty BDA.

You might be able to make it exist; by initialising the video card's ROM (if the video card's ROM actually exists and still contains old code for VBE) and making it usable (e.g. mess with the chipsets/memory controller and any bridges to enable obsolete legacy VGA stuff, if the hardware still supports it).

I don't know why you think you need to do this. That's the job of the legacy BIOS or UEFI, not the VBE ROM. The job of the VBE is to inform about available video-modes, and to provide a mode switching entry-point that reprograms the video-card. Exactly what UEFI fails to provide in a reliable way without extensive hacks.

Also, a VBE compatible card doesn't need to support legacy VGA modes. It's entirely up to the card to define what modes it supports. I only use LFB-modes, as legacy VGA modes are useless.

However, this is far too risky (as the BIOS and its obsolete interfaces finishes its slow death, the chance of the necessary ROM and hardware existing will decrease towards zero) and would take far too much effort to do it semi-reliably (note: were not interested in "cowboy hack-jobs"); so only a complete moron would bother doing something so idiotic.

What's so risky about it? Hopefully something better than GOP comes along before VBE dies-out. Preferentially a new hardware spec for doing fast graphics that isn't connected to a specific vendor.

Besides, I think you are contradicting yourself. Before when we talked about my extensive hack (yes, that was a major hack) to be able to use GOP after exiting boot-services this was not considered reliable. But if GOP is provided by the video-card ROM rather than UEFI, then there is no "exit boot-services" in the GOP. The card wouldn't care if it is operated within the UEFI boot environment or after leaving it. This is just a silly distinction defined in UEFI.

[Brendan]

Hi,

VBE is a software interface. That software interface can't exist without BIOS.

Wrong. Today's VBE interfaces don't rely on BIOS. They make a few calls to int 15h with AH=5F and AH=4E, and if these fails, just continues working as expected. They also don't need a functional timer-tic, doesn't need specific variables in the BDA (a zeroed BDA works on 4 out of 4 tested VBEs). Thus, in order to activate VBE, you only need an int 15 vector that returns failure on everything, and an empty BDA.

Wrong. They rely on firmware to setup the chipset (memory controller, PCI bridges, etc) in a compatible way; rely on firmware to find and use a compatible "VBE ROM"; then rely on the existence of "real mode" (or equivalent), an IVT, etc.

You might be able to make it exist; by initialising the video card's ROM (if the video card's ROM actually exists and still contains old code for VBE) and making it usable (e.g. mess with the chipsets/memory controller and any bridges to enable obsolete legacy VGA stuff, if the hardware still supports it).

I don't know why you think you need to do this. That's the job of the legacy BIOS or UEFI, not the VBE ROM. The job of the VBE is to inform about available video-modes, and to provide a mode switching entry-point that reprograms the video-card. Exactly what UEFI fails to provide in a reliable way without extensive hacks.

It is the job of BIOS to do this. I don't know why you think UEFI needs to do it (UEFI is not BIOS). It's the job of UEFI to ignore VBE completely and provide GOP (or UGA) instead; and nothing in any relevant (UEFI) standard says that UEFI will do anything needed for VBE at all in any way whatsoever.

However, this is far too risky (as the BIOS and its obsolete interfaces finishes its slow death, the chance of the necessary ROM and hardware existing will decrease towards zero) and would take far too much effort to do it semi-reliably (note: were not interested in "cowboy hack-jobs"); so only a complete moron would bother doing something so idiotic.

What's so risky about it? Hopefully something better than GOP comes along before VBE dies-out. Preferentially a new hardware spec for doing fast graphics that isn't connected to a specific vendor.

What's risky about relying on something that may not exist? Um, the fact that it may not exist is a good start...

I can't imagine GOP being replaced - it's perfectly fine how it is, and already better than VBE for the intended purpose (it's just that the intended purpose isn't to make badly designed OSs suck less). If you're going to wish for a new hardware spec for fast graphics then you'd have more luck wishing for naked bimbos that ride around on flying unicorns while giving out free money.

Besides, I think you are contradicting yourself. Before when we talked about my extensive hack (yes, that was a major hack) to be able to use GOP after exiting boot-services this was not considered reliable. But if GOP is provided by the video-card ROM rather than UEFI, then there is no "exit boot-services" in the GOP. The card wouldn't care if it is operated within the UEFI boot environment or after leaving it. This is just a silly distinction defined in UEFI.

Sure; if you want to be completely retarded then you could do a large amount of extra work to create code that tricks the "GOP firmware" into thinking that you are the firmware and re-initialise the GOP interface.

It's still stupid to waste so much time and effort trying to get "driverless video mode switching after boot" working, and far easier (and better for many other reasons) to have a system that's designed properly in the first place (e.g. with resolution independence, where video mode switching is only optional and isn't required for anything).


Cheers,

Brendan

[rdos]

Wrong. They rely on firmware to setup the chipset (memory controller, PCI bridges, etc) in a compatible way;

"In a compatible way". I have no idea what you are talking about. VBE typically uses PCI, and have no business messing with memory controller or PCI bridge. It might change base-addresses of memory / IO regions in a way that causes conflict, and thus the PCI device might have to check for memory range conflicts for devices (which it currently doesn't rather relies on BIOS doing sane settings). Other than that, I don't think this will be a problem.

rely on firmware to find and use a compatible "VBE ROM"; then rely on the existence of "real mode" (or equivalent), an IVT, etc.

There is no x86 compatible processor that lacks real mode. Probably never will be either.

Sure; if you want to be completely retarded then you could do a large amount of extra work to create code that tricks the "GOP firmware" into thinking that you are the firmware and re-initialise the GOP interface.

I don't think I need this anymore. Reinitializing VBE would be much easier to do.

[Octocontrabass]

There is no x86 compatible processor that lacks real mode.

That depends on how compatible you want it to be.

[rdos]

There is no x86 compatible processor that lacks real mode.

That depends on how compatible you want it to be.

Nice little chip. No paging means no "modern" OS will ever run on it

[Brynet-Inc]

There is no x86 compatible processor that lacks real mode.

That depends on how compatible you want it to be.

Nice little chip. No paging means no "modern" OS will ever run on it

That's the predecessor of the 386EX, which did include a paging MMU and started in 32-bit mode. I don't think it excluded real-mode, but it certainly could have. I imagine software just used VM86 if needed.

EFI firmware switches to protected mode or long mode very early in the boot process and is otherwise oblivious to the existence of real-mode, which typically is self-contained in the legacy BIOS CSM, an optional component (..missing from some Windows tablets).

No modern OS booting from EFI firmware ever returns to real-mode. It may be possible, but, there was never a BIOS environment configured by the firmware so it is unlikely that devices will be mapped at legacy addresses.

[MadZarx]

Well I got the graphics working. The only thing I was missing was to use grub in my kernel image. Qemu itself couldnt give me VBE and activate it. So I had to put grub in my kernel image file and load vbe module. But it seems VBE doesnt support 32bpp because its always giving me 24bpp or less. I faced another problem now. I dont understand the pixel formats in different bit depths. For example whats the format of placement of RGBA in a 24bpp or RGB in 16bpp?
I couldnt find a useful article in wiki about this.
Also I have another question. How windows loads 32bpp by deafult? Does windows pack drivers for all vga cards? Or how linux does it? When linux boots, its still in textmode then it changes the console resolution. Whats the trick behind these OSs that they support 32bpp and can change the resolution or bit depth at any time?

[Brendan]

Hi,

Wrong. They rely on firmware to setup the chipset (memory controller, PCI bridges, etc) in a compatible way;

"In a compatible way". I have no idea what you are talking about. VBE typically uses PCI, and have no business messing with memory controller or PCI bridge. It might change base-addresses of memory / IO regions in a way that causes conflict, and thus the PCI device might have to check for memory range conflicts for devices (which it currently doesn't rather relies on BIOS doing sane settings). Other than that, I don't think this will be a problem.

To make it work:

• Inside the CPU there's special support to handle the caching of obsolete/legacy areas (the "fixed range MTRRs")
• Inside the memory controller there's special support to determine if reads and writes to the obsolete/legacy areas get forwarded to RAM or to PCI
• In all PCI bridges (including the host controller) there's special support to forward accesses to the obsolete/legacy VGA IO port range and forward accesses to the obsolete/legacy VGA IO "display memory window". Note: see the "VGA Enable" bit (bit 3 of the bridge control register) in your favourite copy of the PCI-to-PCI Bridge Architecture Specification
• In all video cards there's special support to handle the legacy VGA IO and memory accesses

Of course when there are multiple video devices, only one video device can receive the obsolete/legacy VGA accesses at a time. For this reason, all PCI video devices are fully functional without any of the obsolete/legacy VGA stuff listed above (otherwise you'd only ever be able to use one video card in a system).

Note: Technically, "all PCI video devices" isn't 100% correct - I think there were a few dodgy PCI video cards release when PCI was first introduced (that were mostly designed for ISA and slapped onto a PCI interface) which didn't comply with PCI specifications properly and couldn't be used for systems with multiple video cards.

Note: In theory, VBE can exist without any of the obsolete/legacy VGA hardware stuff. In practice, VBE has to run in real mode and therefore can't access anything outside the first 1 MiB of the physical address space; so using normal memory mapped IO (that can't be accessed in real mode) isn't practical. The obsolete/legacy VGA IO ports and "display memory window" are the only practical way for VBE to access the video card's registers; so in practice VBE requires the obsolete/legacy VGA hardware stuff.

For a real OS (e.g. Windows, Linux, etc), all the native video device drivers wouldn't use any of the obsolete/legacy VGA stuff, so that the same device driver works regardless of whether the video device is the "first" device in the system, or the second (or third or..). Otherwise you'd need 2 different drivers for each video card (which would be an annoying pain in the neck for everyone).

UEFI supports multiple video devices in the same system (this is one of the largest reasons why GOP is superior to VBE). Just like native video drivers in a real OS, the "UEFI video drivers" shouldn't rely on any of the obsolete/legacy VGA stuff because the drivers won't work in systems with multiple video cards if they do. This is why video card manufacturers need to provide "UEFI ROM images" (in addition to, in instead of, the obsolete "VBE ROM images"). Note: PCI devices have supported "multiple different ROM images" for an extremely long time, as PCI is intended for many different architectures and isn't intended for 80x86 alone.

Now; for what I call a "pure UEFI system", the CPU doesn't need the obsolete/legacy stuff, the memory controller doesn't need the obsolete/legacy stuff, the PCI controller and PCI bridges don't need the obsolete/legacy stuff, the video devices don't need the obsolete/legacy stuff, and the video device's ROM don't need the obsolete/legacy "VBE ROM images". All of it can be removed to save costs. For an example, the physical memory map can be a clean slab of RAM from 0x00000000 all the way up to the PCI hole, with none of the legacy puss infecting the first 1 MiB of the physical address space at all.

Of course nothing changes overnight. What we will see (especially for 80x86 desktop/server) is a gradual evolution from "BIOS only" to "UEFI + BIOS + hardware support for obsolete/legacy stuff" to "UEFI only + hardware support for obsolete/legacy stuff" and finally "pure UEFI". This slow evolution towards pure UEFI might take as long as 10 years (but to be honest, as soon as nobody cares about Windows XP we could see a fast land-slide to "pure UEFI", because all other OSs that people care about already support pure UEFI). However; this "slow evolution towards pure UEFI" doesn't apply to small/embedded 80x86 systems (e.g. designed for things like tablets and smartphones, where the OS is typically considered a built-in part of the end product); and for these systems there's no reason not to skip straight to "pure UEFI" and rip out all of the unnecessary legacy stuff now. The same applies to Apple's systems (Apple are already about 5 years ahead of "white box 80x86" on the path towards pure UEFI).

If you were designing a new OS today; it'd be extremely foolish to expect VBE (or any of the obsolete/legacy support the hardware needs to provide to make VBE work) to exist 10 years from now - it would be a massive mistake. If you designed an OS 20 years ago, then you couldn't have foreseen the death of the BIOS/VBE, so relying on the existence of VBE would've been perfectly understandable back then (but the clock is ticking and you'd want to start changing the OS to suit "pure UEFI" now so that your OS doesn't end up on the "unusable/obsolete" list itself).

Sure; if you want to be completely retarded then you could do a large amount of extra work to create code that tricks the "GOP firmware" into thinking that you are the firmware and re-initialise the GOP interface.

I don't think I need this anymore. Reinitializing VBE would be much easier to do.

Why don't you ask Alan Turing to write the code for you? I hear he's not working on anything else at the moment...


Cheers,

Brendan