OSDev.org

How do I set 80 x 25 text mode or change to text mode using UEFI?

I'm new to UEFI. Please, can anyone help me to set the video mode for a matrox vga card using UEFI.

hey22 wrote:How do I set 80 x 25 text mode or change to text mode using UEFI?

I'm new to UEFI. Please, can anyone help me to set the video mode for a matrox vga card using UEFI.

You don't. Simple as that. UEFI does not assume or require a "VGA compatible controller", and the UEFI drivers for your card likely run it in native mode.

If you want text mode, you must do what the UEFI implementation does: Draw it yourself.

Hi,

To clarify; for UEFI there's 3 different things.

First there's the "Console I/O Protocol". This is an API you can use to output text to the console, without knowing or caring what the console is (e.g. it could be a serial port or something) and without having any control over various things (like what video mode is being used, if any). Basically this is like using stdout/stdin (except it's UTF16 and not UTF8 or crusty old ASCII).

Next is the "Universal Graphics Adapter Protocol" (or "UGA"). This only supports graphics video modes, and is obsolete now (except for Apple systems which are a mangled mixture EFI 1.0 and UEFI 2 and later, as far as I know).

Finally there's "Graphics Ouput Protocol" (or "GOP"). This was introduced in UEFI 2 and replaced UGA. Like, UGA, it doesn't support any text modes either.

In general, for the best compatability you'd have to support both UGA and GOP and detect what is supported during boot; and you'd use the Console I/O Protocol (for things like error messages, etc) until your code has got UGA or GOP setup and working.

Also note that EFI/UEFI provides no way for software to read/access any font data built into the firmware or video card ROM - you have to provide your own font data (and then use it to draw your own characters).


Cheers,

Brendan

I find the Console I/O Protocol being quite elegant. The idea of abstracting the text I/O like that is very reasonable.

Brendan wrote:"Universal Graphics Adapter Protocol" (or "UGA"). [...] ...and is obsolete now (except for Apple systems which are a mangled mixture EFI 1.0 and UEFI 2 and later, as far as I know).

Currently, I have not taken into account that. I currently have a GOP support and I thought it would be enough. There are some much to learn. Supporting the Apple systems is very important for me and perhaps I should buy a suitable Apple hardware just for testing. However, it would be quite an expensive investment just for that.

I would make use of this UEFI topic and ask an extra question. Which graphics modes you have usually found supported with GOP on real hardware? Are they limited to "standard" 1024x768-like resolutions that are usually supported by VBE? Can I easily found a typical modern native display resolution like 1920x1080 or 1920x1200? I have a feeling that the GOP might just be like a wrapper and it would not really bring nothing new compared to VBE. Of course, this depends on hardware and UEFI driver manufacturers. Theoretically, VBE can also support arbitrary resolutions but I only have found these "standard" resolutions on real hardware. Does it look like that it is the same thing with UEFI's GOP? If so, I am unhappy.

I do not ask much from the video hardware: just the linear framebuffer with "a modern native resolution". Hopefully I can achieve this some day. Of course, I can buy a native 1024x768 or 1280x1024 monitor that is probably "natively supported" by VBE or GOP.

Usually there are 2 functions, EFI_SIMPLE_TEXT_OUTPUT_PROTOCOL.QueryMode
and EFI_SIMPLE_TEXT_OUTPUT_PROTOCOL.Set Mode.
The 80x25 Text Mode is standard Mode number 0.
First you call Query Mode: If Mode 0 is supported you can set the mode with Set Mode Function:

Antti wrote:I find the Console I/O Protocol being quite elegant. The idea of abstracting the text I/O like that is very reasonable.

Of course, Console I/O Protocol ceases to be an option once you invoke ExitBootServices

djmauretto wrote:Usually there are 2 functions, EFI_SIMPLE_TEXT_OUTPUT_PROTOCOL.QueryMode
and EFI_SIMPLE_TEXT_OUTPUT_PROTOCOL.Set Mode.
The 80x25 Text Mode is standard Mode number 0.

Which is completely irrelevant, because on much extant and real firmware, this will set a hardware graphics mode

Which is completely irrelevant

The User wants that resolution and this is a way to get it,
I do not see why it is irrelevant

because on much extant and real firmware, this will set a hardware graphics mode

Even though, this video mode is emulated,you can treat as the 80x25 text mode
and use Output String function to write to Screen

djmauretto wrote:

because on much extant and real firmware, this will set a hardware graphics mode

Even though, this video mode is emulated,you can treat as the 80x25 text mode
and use Output String function to write to Screen

Read my above post:

Owen wrote:Of course, Console I/O Protocol ceases to be an option once you invoke ExitBootServices

But I do not know what the user wants to do,
I do not assume anything,
He asked how to set the video mode, and I told him how to do

And if the user never wants to leave the boot services?

Antti wrote:I find the Console I/O Protocol being quite elegant. The idea of abstracting the text I/O like that is very reasonable.

Owen wrote:Of course, Console I/O Protocol ceases to be an option once you invoke ExitBootServices

I currently treat the UEFI like the BIOS: just loading the OS, get a memory map, set the video mode and so on. I have not used any runtime services that are available after the ExitBootServices(). In the future, I might start using some of those.

What is a text mode? It might be tricky to define. My opinion is that the text mode is something like "put character bytes with attributes directly to the video memory" and the video hardware take care of the drawing the characters. This "real" text mode seems to be obsolete just like you are suggesting. Other people might consider the definition of the text mode more liberally.

djmauretto wrote:And if the user never wants to leave the boot services?

I understand the point djmauretto have. It is correct not to assume anything. What are the limitations of how extensive a UEFI application can be? Maybe it would be possible to do an application that actually resembles an operating system? I have not considered that.

Currently, I see UEFI as no more than another fancy boot-protocol. I have one machine (a portable Compaq), where Linux GRUB-2 boot-loader seems to run in graphics mode, and GRUB presents very small (almost unreadable) text. However, once control is transfered to RDOS (via multiboot 1), and RDOS calls the video BIOS to change to text mode, the PC easily goes to text mode. However, Linux seems to be unable to use text mode, and instead in the fault-tolerant state uses the same video-mode as GRUB 2.

So I don't think this is a revolution. Behind many UEFI BIOSes lies a legacy video BIOS with VBE. At least the machines I've tested behaves like this.

Therefore I suggest to execute the BIOS int that sets video-mode to text (preferently in real-mode). It will probably work on most machines (at least today it will).

rdos wrote:Therefore I suggest to execute the BIOS int that sets video-mode to text (preferently in real-mode). It will probably work on most machines (at least today it will).

Meanwhile, on my laptop... you will find that the BIOS is still sitting on the hard disk!

Antti wrote:

djmauretto wrote:And if the user never wants to leave the boot services?

I understand the point djmauretto have. It is correct not to assume anything. What are the limitations of how extensive a UEFI application can be? Maybe it would be possible to do an application that actually resembles an operating system? I have not considered that.

No paging, no interrupts, no hardware access except through UEFI drivers. You're pretty buggered.

It's bad enough that some UEFI implementations are buggy enough that you have to go through and disable everything before you can reclaim any boot services memory (e.g. some Macs have buggy firmware which forgets to turn off the Wi-Fi chip... and it DMAs onto said memory. The Linux kernel devs discovered this to their displeasure)

rdos wrote:Currently, I see UEFI as no more than another fancy boot-protocol.

rdos wrote:...lies a legacy video BIOS with VBE

rdos wrote:...execute the BIOS int that sets video-mode to text (preferently in real-mode). It will probably work on most machines (at least today it will).

Perhaps the basic idea of UEFI is good. However, the current implementations seem to make this as an unelegant mess. The old BIOS interrupt calls being still available on most machines today and BIOS working as a backend... I do not what to think about it but it does not make UEFI look like very revolutionary. Of course, tested BIOS code base and knowledge of it affect to this.

When the PCs were best when looking from the OS developing viewpoint? At the beginning, when the "real mode" was only supported? About 1995 when there were no ACPI, APIC, IOAPIC etc. but the VBE was available? Year 2012 when there are UEFI, <abbreviation>, <abbreviation>, <abbreviation>, <abbreviation>, <abbreviation>, and <abbreviation>?

Owen wrote:No paging, no interrupts, no hardware access except through UEFI drivers. You're pretty buggered.

All being software implemented? Interrupts implementation with some weird "polling-message-passing-cooperative-multitasking system"? I am not serious but that just came to mind.

rdos wrote:So I don't think this is a revolution. Behind many UEFI BIOSes lies a legacy video BIOS with VBE. At least the machines I've tested behaves like this.

Therefore I suggest to execute the BIOS int that sets video-mode to text (preferently in real-mode). It will probably work on most machines (at least today it will).

This notably does not apply to Apple hardware. And as a consequence, this does *not* work on a significant part of EFI-based machines - if not the majority of them.

If you want a VGA text mode, you had better boot from the legacy pc-bios.

hey, Thanks for ur reply.

i know by using Simple_Text_Output protocol i can set and change vga text mode but, this protcol is availble after DXE state and before BDS state of booting process.

I want to set vga text mode if possible than at PEI state or at beginnnig of DXE state and without any legacy interrupt function so i have to write my own vga driver which intialize vga.

I search for implimentation of Simple_Text_Output protocol so that i can write my own protocol and put it to where i need.but i didn't get any particular implimentation and setting of vga registers.

So i need to know how can i set vga text mode before DXE and i want to know the required register setting of vga to set text mode without int 10h(intterupt call).

plzzz help me
Thanks in advance...