OSDev.org

Posted: **Tue Jun 18, 2013 7:17 pm**

The topic of video services after invocation of ExitBootServices() from a UEFI application has been discussed at some length in a few other posts. Having read through those posts and having spent some time writing a UEFI application using the EDK2 kit targeting the virtualized UEFI firmware provided on VMWare Workstation 9, I am seeking some additional clarification.

The UEFI specification states (spec 2.3.1D, section 2.3.4) that, when building for x86-64, the boot state is uniprocessor, long mode, paging enabled with all pages identity mapped, and selectors flat. If I write directly to 0xb8000 before or after ExitBootServices(), no output is produced. This is not surprising, and presumably implies that the VGA subsystem has not been initialized by UEFI. For giggles, immediately after ExitBootServices(), I manually attempted to initialize VGA using code lifted directly from coreboot. After this, a write to 0xb8000 again produced no output.

I assume that after ExitBootServices(), the system state is the same as before invocation of that method (i.e., uniprocessor, long mode, paging enabled with all pages identity mapped, flat selectors, and so forth). Without any video output, this is challenging to test. I further presume that the code I lifted from coreboot can be used to initialize VGA on my virtualized system (perhaps a bold assumption). If these two assumptions are true, then I suspect VGA can actually only be initialized when the system is in real-mode.

So:
Question 1: after ExitBootServices(), is the system in the state described in section 2.3.4?
Question 2: is it the case that the VGA subsystem can only be initialized in real-mode?

If I accept that VGA and its relatives (e.g., VESA) are not the best or right way for basic video when using UEFI firmware to boot, what is the alternative? I assume there are two possibilities: 1. there is a different standard that is generally supported across cards; and/or 2. one must write drivers for each card type. It seems, from the "Accelerated Graphic Cards" wiki entry that, although many modern cards support acceleration for OpenGL, the actual driver interface is not standardized. In the absence of a cross-card standard interface for graphics or text, it seems that one is left with option #2. I assume, based on the aforementioned posts, that this is the only option. UDI certainly looks interesting, because it allows one to leverage the work done by others ... possibly even in cases where one can get nothing but binaries from the card manufacturers? At any rate, VMWare does provide what appears to be reasonable documenation for their virtualized video adapter, at least for basic 2D rendering, and I'm willing to give writing a driver a go.

So:
Question 3: Are there standards other than VGA and VESA that can be used across most modern graphics cards to do basic 2D graphics output?
Question 4: If not, when using UEFI firmware, is the only option at this point to write a driver for the video hardware being used?

This is my first post, and although I've spent some time writing a (very) basic hobby OS for ia32 using GRUB and a system booting from a BIOS, this is my first expedition into the world of x86-64 and UEFI. One wonders if biting off both simultaneously provides a bit much to chew. In any case, if my phrasing is unclear, my markup is broken, or my questions are naive, I do apologize. Any and all assistance is appreciated.

Posted: **Tue Jun 18, 2013 8:15 pm**

Hi,

blort wrote:The UEFI specification states (spec 2.3.1D, section 2.3.4) that, when building for x86-64, the boot state is uniprocessor, long mode, paging enabled with all pages identity mapped, and selectors flat. If I write directly to 0xb8000 before or after ExitBootServices(), no output is produced. This is not surprising, and presumably implies that the VGA subsystem has not been initialized by UEFI.

Not necessarily. VGA is obsolete (and has been obsolete for over 20 years now); and it's very likely that UEFI did initialise some sort of SVGA that doesn't comply with your obsolete expectations. More specifically, it's likely that UEFI is using a LFB at some physical address in the "memory mapped PCI" space (e.g. maybe something like 0xE0000000) rather than the obsolete/legacy VGA display window.

blort wrote:For giggles, immediately after ExitBootServices(), I manually attempted to initialize VGA using code lifted directly from coreboot. After this, a write to 0xb8000 again produced no output.

Please note that a lot of effort is involved in maintaining backward compatibility with VGA; including special support in video cards but also including special support in chipsets and the PCI bus. The single greatest advantage of UEFI is that all this extra support (baggage) for backward compatibility with obsolete hardware can be discarded in hardware, firmware and software. For example, to handle "VGA" properly you need any/all PCI to PCI bridges in the path from CPU to video card to be configured to forward legacy/ISA IO port and memory accesses to the video card; and the video card itself needs to be in a special "VGA emulation mode". If UEFI is used, then the chipset (e.g. PCI to PCI bridges) can be configured by firmware properly (without the unnecessary legacy stuff) and the video card itself can be used properly (without the obsolete legacy stuff).

Attempting to initialise the video card using "VGA code" when it isn't in its special "VGA emulation mode", and when the chipset is not setup for it, is almost guaranteed to fail. You'd actually need a special device driver designed for the video card just to take it out of its native mode and put it back into its special "VGA emulation mode" (in addition to code to reconfigure the chipset, PCI bridges, etc).

Of course once the industry has fully adopted UEFI, hardware manufacturers can stop bothering with the obsolete legacy stuff. For example; eventually we will start to see video cards that don't have any special "VGA emulation mode", and chipsets and PCI bridges that don't support legacy IO forwarding. The end result will be cleaner and cheaper hardware; as less time and money will be wasted on obsolete legacy baggage (especially for things like regression testing).

Obviously this means that the only future-proof ways of handling video is to use the UEFI services to setup a video mode and LFB during boot (before the OS takes control of the computer by calling "ExitBootServices()") and/or to implement native video drivers designed for the specific video card/s. Note: Relying on native video drivers alone isn't practical; as there will always be some time after a new video card is released before a driver for that card is available; which means that being able to use UEFI services to setup a video mode and LFB during boot is an almost unavoidable requirement. Furthermore; this approach can also be compatible with legacy BIOS systems (e.g. use VBE to setup a video mode and LFB during boot on BIOS systems in case the OS doesn't have suitable native video drivers).

blort wrote:So:
Question 1: after ExitBootServices(), is the system in the state described in section 2.3.4?

I'd expect so (but this section describes very little of the computer's entire state - e.g. not including the state/s of PIC, IO APIC, PCI bridges, any PCI device, etc).

blort wrote:Question 2: is it the case that the VGA subsystem can only be initialized in real-mode?

No - if you switch to real mode and attempt to configure VGA you'll have the same problems described above (PCI bridges, etc potentially not configured for "legacy IO", and video card potentially not in a special "VGA emulation mode", and all hardware potentially not even supporting the legacy/emulation you'd need in future).

blort wrote:If I accept that VGA and its relatives (e.g., VESA) are not the best or right way for basic video when using UEFI firmware to boot, what is the alternative?

For UEFI there's 2 different alternatives (not including the "EFI_SIMPLE_TEXT_OUPUT_PROTOCOL" that can only be used for UTF-16 text output before "ExitBootServices()" is called):

EFI_UGA_DRAW_PROTOCOL (older, now deprecated)
EFI_GRAPHICS_OUTPUT_PROTOCOL (newer)

Both of these provide functionality that is roughly equivalent to what VBE provided - e.g. getting video modes, setting video modes, etc.

Cheers,

Brendan

Posted: **Wed Jun 19, 2013 6:58 am**

Not a direct answer to your questions but I can tell you what i do.

I use Grub header to request video mode. Grub EFI and Grub MBR will both honor this bit. So if you try to request for example 1024x768x32 you are in most cases going to get your wish granted.

You need to parse both VBE and FB info structure from multiboot info. Have been running on various EFI bios machines with 1.99 or 2.xx of grub and got some small variations in the result but all working.

So you probably will be required to write a FB driver if you haven't already. I use serial (pci or onboard) to get a text console to my dev machine and use FB for drawing stuff or a graphics console. The serial part helped me alot during debugging when FB was not working due to some issues with data in VBE or FB struct was incomplete.

It also seems that EFI bios will leave the LFB used when you requested a gfx_term in grub.conf so that you can basically hook onto that after boot if you know where it is located as well. I did also do some patching of grub source for video to output more debug. This was kind of usefull during early phase of the process. "set pager=1" is also something that will help you consuming grub debug output

So as you understand i dont't use EFI interface at all for video (at this point).

regards
Thomas

Posted: **Sat Jun 22, 2013 12:50 am**

mutex wrote:I use Grub header to request video mode. Grub EFI and Grub MBR will both honor this bit. So if you try to request for example 1024x768x32 you are in most cases going to get your wish granted.

mutex, I definitely appreciate the thoughts. I don't, however, use Grub, instead relying on the UEFI framework alone to launch the OS.

brendan wrote:Not necessarily. VGA is obsolete (and has been obsolete for over 20 years now)...

Understood. To be clear, I was specifically working to avoid using VGA. I was just curious about why it generally does not appear to be initialized when using UEFI and what the sensible alternative is. Your explanation was thorough, and I appreciate that, as well.

brendan wrote:Obviously this means that the only future-proof ways of handling video is to use the UEFI services to setup a video mode and LFB during boot...

This turns out to be the key I was seeking. In my previous perusal of the UEFI spec, I assumed that only services explicitly identified as run-time (i.e., in section 7) are available. However, section 11.9 -- regarding the Graphics Output Protocol -- reads:

Graphics output may also be required as part of the startup of an operating system. There are potentially times in modern operating systems prior to the loading of a high performance OS graphics driver where access to graphics output device is required. The Graphics Output Protocol supports this capability by providing the EFI OS loader access to a hardware frame buffer and enough information to allow the OS to draw directly to the graphics output device.

I didn't realize that the GOP provided a facility upon which one could rely at run-time (i.e., after ExitBootServices() is invoked). However, one can get a frame buffer via an instance of EFI_GRAPHICS_OUTPUT_PROTOCOL_MODE before exiting boot services. The exact details of how one draws in this region can vary, but the possibilities are constrained and described by the enum EFI_GRAPHICS_PIXEL_FORMAT for the selected mode. This means that, to write text, one must implement a font renderer and provide a font definition, but that's pretty straight-forward.

In case others may have this question, I provide code below that compiles using the edk2 package, and which works, at least on the UEFI firmware provided in VMWare Workstation 9. For brevity, I omitted comments. The error checking is obviously not particularly robust. One may receive more than one handler for the EFI_GRAPHICS_OUTPUT_PROTOCOL (e.g., if there is more than one connected display), but I just grab the first one. I look for a particular desired mode, and if it doesn't exist, I bail. The HandleProtocol() method is deprecated (section 6.3), but it was easy and the specification contains an example using it. Again, these are all simplifications to illustrate the main point. Assuming this is not foolishly done, perhaps others may find it either instructive or helpful.

Code: Select all

#include <Library/UefiApplicationEntryPoint.h>
#include <Library/UefiLib.h>
#include <stdio.h>
#include <wchar.h>

#define MEMMAP_SIZE 1024*1024
UINT8 memmap[MEMMAP_SIZE * sizeof(EFI_MEMORY_DESCRIPTOR)];

void AwaitKeyboardInput( EFI_SIMPLE_TEXT_INPUT_PROTOCOL* conin );
void writeStringAt( const char* s, EFI_PHYSICAL_ADDRESS lfb_base_addr, UINT16 row, UINT16 col );
void drawTriangle( EFI_PHYSICAL_ADDRESS lfb_base_addr, UINTN center_x, UINTN center_y, UINTN width, UINT32 color );
void PreBootHalt( EFI_SIMPLE_TEXT_OUTPUT_PROTOCOL* conerr, UINT16* msg );

#define DESIRED_HREZ            1024
#define DESIRED_VREZ             768
#define DESIRED_PIXEL_FORMAT    PixelBlueGreenRedReserved8BitPerColor

EFI_STATUS
EFIAPI
UefiMain(
    IN EFI_HANDLE       ImageHandle,
    IN EFI_SYSTEM_TABLE *SystemTable
)
{   
    EFI_SYSTEM_TABLE   *gST;
    EFI_BOOT_SERVICES  *gBS;
    UINTN memmap_size = MEMMAP_SIZE;
    UINTN map_key, descriptor_size;
    UINT32 descriptor_version;
    UINTN mode_num;
    EFI_STATUS status;
    EFI_HANDLE* handle_buffer;
    UINTN handle_count = 0;
    EFI_GRAPHICS_OUTPUT_PROTOCOL* gop;
    EFI_GRAPHICS_OUTPUT_MODE_INFORMATION* gop_mode_info;
    UINTN size_of_info;

    if (!(gST = SystemTable))
        return EFI_LOAD_ERROR;

    if (!(gBS = SystemTable->BootServices))
        return EFI_LOAD_ERROR;

    if (!(gST->ConIn) || gST->ConIn->Reset( gST->ConIn, 0 ) != EFI_SUCCESS)
        PreBootHalt( gST->ConOut, L"Input Connection Device Unavailable" );

    status = gBS->LocateHandleBuffer( ByProtocol,
                                      &gEfiGraphicsOutputProtocolGuid,
                                      NULL,
                                      &handle_count,
                                      &handle_buffer );

    if (status != EFI_SUCCESS)
        PreBootHalt( gST->ConOut, L"LocateHandleBuffer() failed" );

    status = gBS->HandleProtocol( handle_buffer[0],
                                  &gEfiGraphicsOutputProtocolGuid,
                                  (VOID **)&gop );

    if (status != EFI_SUCCESS)
        PreBootHalt( gST->ConOut, L"HandleProtocol() failed" );

    for (mode_num = 0;
         (status = gop->QueryMode( gop, mode_num, &size_of_info, &gop_mode_info )) == EFI_SUCCESS;
         mode_num++) {
        if (gop_mode_info->HorizontalResolution == DESIRED_HREZ &&
              gop_mode_info->VerticalResolution == DESIRED_VREZ &&
              gop_mode_info->PixelFormat        == DESIRED_PIXEL_FORMAT)
            break;
    }

    if (status != EFI_SUCCESS)
        PreBootHalt( gST->ConOut, L"Failed to find desired mode" );

    if (gop->SetMode( gop, mode_num) != EFI_SUCCESS)
        PreBootHalt( gST->ConOut, L"SetMode() failed" );

    status = gBS->GetMemoryMap( &memmap_size,
                                (EFI_MEMORY_DESCRIPTOR*)memmap,
                                &map_key,
                                &descriptor_size,
                                &descriptor_version );

    if (status != EFI_SUCCESS)
        PreBootHalt( gST->ConOut, L"GetMemoryMap() failed" );

    if (gBS->ExitBootServices( ImageHandle, map_key ) != EFI_SUCCESS)
        PreBootHalt( gST->ConOut, L"ExitBootServices() failed" );

    drawTriangle( gop->Mode->FrameBufferBase, DESIRED_HREZ / 2, DESIRED_VREZ / 2 - 25, 100, 0x00ff99ff );

    for ( ;; ) ;
}

void drawTriangle( EFI_PHYSICAL_ADDRESS lfb_base_addr, UINTN center_x, UINTN center_y, UINTN width, UINT32 color ) {
    UINT32* at = (UINT32*)lfb_base_addr;
    UINTN row, col;

    at += (DESIRED_HREZ * (center_y - width / 2) + center_x - width / 2);

    for (row = 0; row < width / 2; row++) {
        for (col = 0; col < width - row * 2; col++)
            *at++ = color;
        at += (DESIRED_HREZ - col);
        for (col = 0; col < width - row * 2; col++)
            *at++ = color;
        at += (DESIRED_HREZ - col + 1);
    }
}


void PreBootHalt( EFI_SIMPLE_TEXT_OUTPUT_PROTOCOL* conerr, UINT16* msg ) {
    conerr->OutputString( conerr, msg );
    for (;;) ;
}

Posted: **Tue Jan 16, 2018 9:17 pm**

blort

I provide code below that compiles using the edk2 package

Hi blort, thank you for your code, now I can draw the Triangle on real pc.
In graphic mode, I know how to draw text, but I still prefer text mode.

I use the code to switch text mode 80X25, and after call exit_boot_services, I write 0xb8000 to want to show a character, but fail.
I see nothing. It's look like the 0xb8000 is wrong address.

If like your example code, how to get the text mode video buffer address?

Code: Select all

  ret = sys_table->con_out->query_mode(sys_table->con_out, 0, &columns, &rows);
  if (EFI_SUCCESS == ret)
  {
    sys_table->con_out->output_string(sys_table->con_out, L"\r\nset vga mode to 0. (80X25)\n\r");
    sys_table->con_out->set_mode(sys_table->con_out, 0);
    sys_table->con_out->output_string(sys_table->con_out, L"\r\nset vga mode to 0. (80X25) okok\n\r");
  }

Posted: **Wed Jan 17, 2018 4:47 am**

Hi,

descent wrote:I use the code to switch text mode 80X25, and after call exit_boot_services, I write 0xb8000 to want to show a character, but fail.
I see nothing. It's look like the 0xb8000 is wrong address.

You're confusing the virtual console with the video card.

For an example; assume that the video mode was 1920 * 1600 graphics mode and UEFI was using a 48 * 64 font to emulate 40 * 25 characters for the virtual console. Then you tell the virtual console to emulate 80 * 25 characters, so UEFI starts using a 24 * 64 font instead (and doesn't change the underlying video mode at all).

For another example; assume that UEFI is using a network card (and something like SSH/telnet) to emulate 40 * 25 characters for the virtual console. Then you tell the virtual console to emulate 80 * 25 characters, so UEFI returns an "EFI_UNSUPPORTED" error (because the other end of the connection doesn't support the "window size" telnet option) and you don't even bother to check if an error was returned.

Cheers,

Brendan

Posted: **Wed Jan 17, 2018 6:44 am**

descent, after calling ExitBootServices(), you have to draw your own text "you prefer" into the linear buffer of graphics you've got.
Or maybe you don't need to be hasty and try UEFI protocols (console) for text output from your loader/whatever.
It's not a trivial task to manage display system in such a limited environment as the hand off between OS loader and OS. Actually that capability of the GOP is for drawing Logo in between OS is deploying, nothing else. not for text output with cursor blinking. of course you could draw your bitmap font the same way as logo, but it's you who does everything that. FW has quit after ExitBootServices(). your modesetting is in vain.
Just an example. On a board I try to write something on, the HDMI controller alone has frigging 346 registers! bunch of interrupts and all that is so messy.

Posted: **Sat Jan 20, 2018 8:11 am**

Brendan wrote: You're confusing the virtual console with the video card.

For an example; assume that the video mode was 1920 * 1600 graphics mode and UEFI was using a 48 * 64 font to emulate 40 * 25 characters for the virtual console. Then you tell the virtual console to emulate 80 * 25 characters, so UEFI starts using a 24 * 64 font instead (and doesn't change the underlying video mode at all).

zaval wrote:descent, after calling ExitBootServices(), you have to draw your own text "you prefer" into the linear buffer of graphics you've got.

thanks for your reply.

I have another question, the pc uses uefi, do their VGA card have any text mode？
In legacy bios, I wrote a os can switch text mode/vga mode, I test it in real pc.
I hope my os can to the same thing in uefi pc.

Posted: **Sat Jan 20, 2018 8:21 am**

You need to determine if you have VGA compatible hardware in the first place. Enumerate the PCI bus to see if you have a VGA card. All (?) modern graphics cards should still should show up as VGA compatible. If you have such a card, it should be able to switch into text mode if you setup the VGA registers properly.

Posted: **Sat Jan 20, 2018 8:28 am**

This is not (always) true for arm mini-PCs. there, it's better to forget about vga at all. but here only a few persons think "not only x86"...
It's funny people got so concerned with such an irrelevant thing as Meltdown/Spectre, but they don't pay any attention to frigging portability of their OS!

But descent, again, why don't you wanna use UEFI input/output protocols? It's easier (both to learn and use). Only at the very end of your OS loader work you cannot use them. but then text mode isn't needed.

Posted: **Sun Jan 21, 2018 3:23 pm**

Hi,

Korona wrote:You need to determine if you have VGA compatible hardware in the first place. Enumerate the PCI bus to see if you have a VGA card. All (?) modern graphics cards should still should show up as VGA compatible. If you have such a card, it should be able to switch into text mode if you setup the VGA registers properly.

For 80x86; the video card's ROM can contain a BIOS ROM image, a UEFI driver, or both. For BIOS the firmware has to setup ugly compatibility hacks elsewhere (e.g. legacy VGA port forwarding in PCI bridges, the legacy display area in MTRRs, etc) just to make VGA work. For UEFI, so that UEFI drivers work the same when there's 2 or more video cards none of the ugly compatibility hacks (in the chipset, in the MTRRs, etc) are used.

This means that for UEFI on 80x86, it's not just a matter of finding some undocumented proprietary method of enabling "VGA mode" in the video card itself, and not just a matter of finding and executing/initialising the video card's "BIOS ROM image" (which may not exist and requires making the legacy ROM area "read/write"); but it can also mean reconfiguring the chipset and MTRRs (possibly with motherboard specific code) so that things like legacy VGA IO ports can work.

However; Intel have also stated that support for BIOS will be dropped in 2020. This means that (especially for integrated video) you can expect that VGA support will cease to exist in video cards and you can expect that the ugly compatibility hacks in the chipset will disappear too; making it impossible to inflict the disgustingly ugly and obsolete VGA puke on unsuspecting victims/users.

In other words, on UEFI systems VGA is simply not worth bothering with (far too much work to force video to suck, with a high probability that it's impossible to make VGA work in as little as 2 years).

Cheers,

Brendan

Posted: **Sun Jan 21, 2018 3:36 pm**

At least for the documented cards, there actually are bits to enable VGA mode. I don't know about NVIDIA cards though and of course, this is only a statistic sampled over the cards that I have implemented drivers for. MTRR-remapping might be necessary though, if the UEFI implementation does not expect VGA mode. And of course, the PCIe hubs need to support ISA forwarding.

The option ROM only contains the BIOS' VGA driver, it does not contain magical "VGA emulation code" (again, this is only for Intel and AMD). The VGA stuff is still implemented in hardware (at least from the OS' perspective).

But you're right in the aspect that this is too complicated to be worthwhile - after all, it will only give you worse resolutions than UEFI.

Posted: **Wed Jan 24, 2018 4:48 am**

zaval wrote: But descent, again, why don't you wanna use UEFI input/output protocols? It's easier (both to learn and use). Only at the very end of your OS loader work you cannot use them. but then text mode isn't needed.

I want to show character after call exitbootservices, so I think I need draw char by myself, cannot call uefi function.
Or my os kernel need to show some character, I don't know how to do before.

Now I know use the video buffer to draw char, don't consider vga/text mode.

Posted: **Wed Jan 24, 2018 7:17 am**

well, if you need this. you should prepare some bitmap font and draw it directly into "framebuffer" just like the example above drew triangle.

Posted: **Thu Jan 25, 2018 9:10 pm**

zaval wrote:well, if you need this. you should prepare some bitmap font and draw it directly into "framebuffer" just like the example above drew triangle.

yes, I prepare to do this.

thanks for everyone replying.

OSDev.org

UEFI Video after ExitBootServices()

UEFI Video after ExitBootServices()

Re: UEFI Video after ExitBootServices()

Re: UEFI Video after ExitBootServices()

Re: UEFI Video after ExitBootServices()

Re: UEFI Video after ExitBootServices()

Re: UEFI Video after ExitBootServices()

Re: UEFI Video after ExitBootServices()

Re: UEFI Video after ExitBootServices()

Re: UEFI Video after ExitBootServices()

Re: UEFI Video after ExitBootServices()

Re: UEFI Video after ExitBootServices()

Re: UEFI Video after ExitBootServices()

Re: UEFI Video after ExitBootServices()

Re: UEFI Video after ExitBootServices()

Re: UEFI Video after ExitBootServices()