OSDev.org

YDeeps1 wrote:Mind showing me a way I can find low-level manufacturer documentation for things like this? I don't really see much documentation for them (I am using an Nvidia GPU to start off with).

These are very difficult to find at best. Nvidia doesn't publish such information nor does it provide source code. You can take a look at Linux's Nouveau drivers for Nvidia, but I doubt that there are using any bank switching there. If you are going to bother writing low-level code like this, might as well just map the entire framebuffer somewhere instead of using bank switcing.

YDeeps1 wrote:And does GRUB not provide this kind of information?

It doesn't. How could it possibly do that? Every video card is different.

Above you said you can't use BIOS/VBE and now you say you are using Grub. This seems curious as Grub basically relies on VBE to set the video mode and give you a linear frame buffer. Something doesn't seem to be adding up here.

I am not entirely sure what you are trying to achieve here, but I have some code that allows one to call VBE (and other BIOS functions) from protected mode. I did this in a previous version of my bootloader that was loaded by Grub.

https://github.com/kiznit/rainbow-os/bl ... s/bios.hpp
https://github.com/kiznit/rainbow-os/bl ... s/bios.cpp
https://github.com/kiznit/rainbow-os/bl ... ios/bios.S

Examples of usage:
https://github.com/kiznit/rainbow-os/bl ... s/vesa.cpp

YDeeps1 wrote:Anything vital I missed here?

GRUB tells you the framebuffer address, dimensions, layout, and everything else you need in the Multiboot information structure.

Octocontrabass wrote:

YDeeps1 wrote:Anything vital I missed here?

GRUB tells you the framebuffer address, dimensions, layout, and everything else you need in the Multiboot information structure.

Thank you! Taking another look at the multiboot specification does indeed reveal the information structure I need.

kzinti wrote:

YDeeps1 wrote:Mind showing me a way I can find low-level manufacturer documentation for things like this? I don't really see much documentation for them (I am using an Nvidia GPU to start off with).

These are very difficult to find at best. Nvidia doesn't publish such information nor does it provide source code. You can take a look at Linux's Nouveau drivers for Nvidia, but I doubt that there are using any bank switching there. If you are going to bother writing low-level code like this, might as well just map the entire framebuffer somewhere instead of using bank switcing.

YDeeps1 wrote:And does GRUB not provide this kind of information?

It doesn't. How could it possibly do that? Every video card is different.

Above you said you can't use BIOS/VBE and now you say you are using Grub. This seems curious as Grub basically relies on VBE to set the video mode and give you a linear frame buffer. Something doesn't seem to be adding up here.

I am not entirely sure what you are trying to achieve here, but I have some code that allows one to call VBE (and other BIOS functions) from protected mode. I did this in a previous version of my bootloader that was loaded by Grub.

https://github.com/kiznit/rainbow-os/bl ... s/bios.hpp
https://github.com/kiznit/rainbow-os/bl ... s/bios.cpp
https://github.com/kiznit/rainbow-os/bl ... ios/bios.S

Examples of usage:
https://github.com/kiznit/rainbow-os/bl ... s/vesa.cpp

By saying I can't use the BIOS I was referring to some traits that would make it difficult for me to exit protected mode and back into real mode and then back again.
And thank you for the repos I'll take a look at them.

Octocontrabass wrote:Modern PCs have UEFI and GOP, so v86 mode won't help you there.

But they typically also support a legacy BIOS booting option, no?

Octocontrabass wrote:Slightly older PCs have a BIOS that assumes you'll run a 64-bit version of Windows, and 64-bit Windows never uses v86 mode, so the BIOS code may not run correctly in v86 mode.

Is that a case of "there are known issues with some BIOSes in v86 mode" (and if so can you give some details) or is it "theoretically, there may be BIOSes which don't work correctly in v86 mode"?

Octocontrabass wrote:Modern PCs don't have VGA hardware.

But again, they typically support the VGA register interface to quite a reasonable degree, and typically the BIOS video functions work just fine. I feel like this level of pedantry is not helpful.

davmac314 wrote:But they typically also support a legacy BIOS booting option, no?

Not always. And even if the support exists, it might require hardware you don't have. (A few years ago, Intel said they planned to get rid of legacy support by 2020. Obviously that hasn't happened yet, but it's only a matter of time.)

davmac314 wrote:Is that a case of "there are known issues with some BIOSes in v86 mode" (and if so can you give some details) or is it "theoretically, there may be BIOSes which don't work correctly in v86 mode"?

Mostly the latter, although I've heard at one point QEMU included a VGA ROM that didn't work in v86 mode.

Octocontrabass wrote:

YDeeps1 wrote:Anything vital I missed here?

GRUB tells you the framebuffer address, dimensions, layout, and everything else you need in the Multiboot information structure.

Yes, because this is information that VBE will provide for you. So, you don't need GRUB, only VBE.

davmac314 wrote:e are known issues with some BIOSes in v86 mode" (and if so can you give some details) or is it "theoretically, there may be BIOSes which don't work correctly in v86 mode"?

In my experience, all BIOSes I've tested work in v86 mode. OTOH, there are at least a few that won't work in protected mode.

The background to this most likely that Windows used to rely on v86 mode, and so BIOSes needed to operate in v86 mode.

rdos wrote:The background to this most likely that Windows used to rely on v86 mode, and so BIOSes needed to operate in v86 mode.

The BIOSes came first, though. I suspect the reason that BIOSes mostly work in v86 mode is because v86 mode is, in fact, largely compatible with real mode which the BIOS "natively" supports and for typical BIOS operations there's no reason to do anything funky enough that would show up an incompatibility between real mode and v86 mode.

rdos wrote:Yes, because this is information that VBE will provide for you. So, you don't need GRUB, only VBE.

...Except on UEFI, where GRUB will work exactly the same way as it does on BIOS, and VBE will not.

davmac314 wrote:The BIOSes came first, though. I suspect the reason that BIOSes mostly work in v86 mode is because v86 mode is, in fact, largely compatible with real mode which the BIOS "natively" supports and for typical BIOS operations there's no reason to do anything funky enough that would show up an incompatibility between real mode and v86 mode.

ISA option ROMs need to maintain backwards compatibility with a 286 (or sometimes 8088), which prevents the use of any funky tricks that wouldn't work in v86 mode. VGA option ROMs completely replace the original BIOS INT 0x10 handler. Microsoft could safely assume the INT 0x10 handler would run in v86 mode, and as Windows took over the PC ecosystem, Microsoft effectively forced later option ROMs to maintain v86 compatibility.

It's perfectly reasonable for a VGA option ROM to switch to protected mode in order to access its MMIO, yet you'll find very few that do so.

Octocontrabass wrote:

rdos wrote:Yes, because this is information that VBE will provide for you. So, you don't need GRUB, only VBE.

...Except on UEFI, where GRUB will work exactly the same way as it does on BIOS, and VBE will not.

True, but UEFI and VBE provide different functions, and so if you rely on GRUB you can only use functionality that works on both.

For instance, VBE allows you to switch video mode at any time, while with UEFI, you need to do it before exiting boot services. VBE also allows the use of text-mode, something that doesn't appear to be supported by UEFI.

So, if you rely on GRUB you cannot dynamically switch video mode (unless you have a native GPU driver) and you cannot take advantage of text mode.

rdos wrote:True, but UEFI and VBE provide different functions, and so if you rely on GRUB you can only use functionality that works on both.

That's not true. GRUB will tell you if VBE exists, and you can use VBE if it exists. The issue is that new computers don't support VBE, so you shouldn't rely on it unless your OS is specifically designed to run on obsolete computers.

Octocontrabass wrote:

rdos wrote:True, but UEFI and VBE provide different functions, and so if you rely on GRUB you can only use functionality that works on both.

That's not true. GRUB will tell you if VBE exists, and you can use VBE if it exists. The issue is that new computers don't support VBE, so you shouldn't rely on it unless your OS is specifically designed to run on obsolete computers.

Generally, a computer will either boot through BIOS (in which case VBE should be available) or through UEFI, in which case it wouldn't be available. If you have your own boot-loader rather than relying on GRUB, you will know if you used a BIOS or UEFI boot, and if VBE is expected to exist or not.

Also, I don't think GRUB will allow my 32-bit OS to boot from 64-bit UEFI, and so I will need my own EFI-loader that switches to protected mode early in the boot process.

I handle VBE and EFI video interfaces by adding different device drivers to the OS image. Therefore, I can boot from both BIOS and UEFI, and also through GRUB (at least I could in the past). To provide a more similar interface, I typically configure BIOS boots to set a fixed resolution at boot time using VBE. However, I could also boot to text mode and support dynamic mode switches.

rdos wrote:Also, I don't think GRUB will allow my 32-bit OS to boot from 64-bit UEFI, and so I will need my own EFI-loader that switches to protected mode early in the boot process.

I don't think GRUB has trouble booting anyone else's 32-bit OS from 64-bit UEFI.