OSDev.org

set timeout=30
set default=0
set debug=all

#loadfont /efi/boot/unicode.pf2
#set gfxmode=1024x768
#set gfxmode=auto
#set gfxpayload=keep
#terminal_output gfxterm

#background_image -m normal /efi/boot/background.jpg

menuentry "OSKernel" {
set debug=all
sleep 5 
}

• Does GRUB pass the EFI system table to the loaded OS?
• If not, is there another way to get it?
• Is GOP available after ExitBootServices()?

blm768 wrote:I just recently lost my old BIOS-based code to a partition table corruption, so I decided to start fresh with a UEFI-based kernel. I've gotten QEMU set up with the right firmware and built a GRUB2 EFI image using the instructions in the GRUB page on the wiki (which should really be moved to the GRUB2 page because they don't use legacy GRUB), and everything goes smoothly until I get into GRUB. Instead of displaying a menu, it drops right to the rescue prompt without any indication of what's wrong. Here is my grub.cfg:

blm768 wrote:I also have a few other questions:

• Does GRUB pass the EFI system table to the loaded OS?

blm768 wrote:

• If not, is there another way to get it?

blm768 wrote:

• Is GOP available after ExitBootServices()?

Brendan wrote: I've got no idea what could be wrong. If you run GRUB2 inside Qemu (with UEFI) you might be able to debug it.

Brendan wrote: Finally, if GRUB2 is used to "chainload" a normal UEFI boot loader then it should pass the EFI system table (however, for this case and possibly for UEFI in general, there's no point bothering with GRUB2).

Brendan wrote: No, but you can get information needed to use the frame buffer before calling ExitBootServices() and use that framebuffer after calling ExitBootServices().

blm768 wrote:Ouch. I thought UEFI was supposed to make things easier. I guess I'll have to implement a framebuffer driver for each graphics card. (I'm not planning on messing with 2D acceleration; it's not worth the effort when most window managers are switching to OpenGL).

blm768 wrote:Ouch. I thought UEFI was supposed to make things easier. I guess I'll have to implement a framebuffer driver for each graphics card. (I'm not planning on messing with 2D acceleration; it's not worth the effort when most window managers are switching to OpenGL).

Antti wrote:As far as the hobby OS developing is concerned, I think that playing with GRUB (or similar) is not a good idea. I do not know how to explain this but I feel that it does not belong to the philosophy of doing things from scratch. I would categorize the hobby OS developing to be "doing things from scratch". If you are able to write a kernel, why you do not just take care of the boot procedures also. As an aside, I would find it frustrating to start studying (and debugging!) GRUB because, well, I am doing my own system.

gerryg400 wrote:I feel the opposite. I use Grub. I have no interest whatsoever in writing a boot loader. It's just some sort of driver thingy that loads my kernel and is nothing at all to do with my operating system design. It's just a distraction.

Brendan wrote: The disadvantage is that there's no 2D or 3D acceleration, no hardware mouse pointer support, and no way to change video modes after boot. For these things you'd need native drivers for each card (and not a frame-buffer driver).

blm768 wrote:What I was planning to make was a very minimal driver for each card that would support changing video modes and drawing through an unaccelerated framebuffer-like interface. If 2D acceleration isn't hard to implement in a driver, though, I might add it.

• a function to get a the driver's identification and capabilities (if it supports various optional features or not)
• a function to get a list of supported video modes
• a function to get information about a specific video mode
• a function to set a video mode
• a function to draw a frame of video
• a function to determine what "object ID" happens to be at a specific coordinate (that software can use to determine what part of which icon/widget/window the mouse clicked on)
• a function to set the mouse pointer position
• a function to set the mouse pointer's appearance

blm768 wrote:I just don't want to bother with it if it adds much effort; I'm hoping to get OpenGL drivers anyway (eventually...), so 2D acceleration likely wouldn't even be used much.

Brendan wrote: OpenGL is not a driver - OpenGL is an "Open Graphics Library" (a library that runs in user space). OpenGL may not have anything to do with the native video driver interface at all.

blm768 wrote:

Brendan wrote:OpenGL is not a driver - OpenGL is an "Open Graphics Library" (a library that runs in user space). OpenGL may not have anything to do with the native video driver interface at all.

Good point.
My thought was that I would end up with two components for each card, a driver and a shared library. Each version of the shared library would be tailored to a specific driver, so the interface between the userspace library and the driver would be implementor-defined. Is that actually the way that most systems work?

blm768 wrote:For some strange reason, I can't make calls to UEFI "methods" directly; I have to use uefi_call_wrapper(). Strange...

blm768 wrote:Also, is there a good reference on loading a file with UEFI? I can't figure out how to get the EFI_DEVICE_PATH_PROTOCOL that LoadFile() uses as the file path.

Brendan wrote: Having a different OpenGL library for each different video driver could work, until you start thinking about supporting multiple monitors attached to different video cards and need to dynamically link several different versions of the OpenGL library at the same time.

Brendan wrote: UEFI uses Microsoft's calling conventions. GNU's tools use System V AMD64 ABI calling conventions. I'd assume the "uefi_call_wrapper()" wrapper exists to hide the differences.

Brendan wrote: The only reference I've seen is the UEFI spec/s (which could be described as "convoluted" rather than "good").

blm768 wrote:

Brendan wrote:

blm768 wrote:My thought was that I would end up with two components for each card, a driver and a shared library. Each version of the shared library would be tailored to a specific driver, so the interface between the userspace library and the driver would be implementor-defined. Is that actually the way that most systems work?

Having a different OpenGL library for each different video driver could work, until you start thinking about supporting multiple monitors attached to different video cards and need to dynamically link several different versions of the OpenGL library at the same time.

I thought about that as well. If each application renders into an offscreen buffer, it doesn't really matter which card it's using; I can just allocate each one a card based on load. I'd just have to figure out how the window manager will work with the monitors...
By different versions, do you mean versions of the OpenGL specs or revisions of the driver/libraries?

blm768 wrote:If each application renders into an offscreen buffer...