OSDev.org

Hello,
I have recently made my bootloader work on EFI based systems. However, when I call locate LocateHandle for the GOP, two handles are returned, even though I only have one display. This is true on OVMF and most hardware I've tested (an HP Pavillion and a MacBook Pro), but was not true on a Dell OptiPlex. Even stranger is that the only supported mode is 1x120, which doesn't even seem valid to me. My only guess is that this is GOP representation of ConOut, but I'm not sure. Does anyone know what this mysterious handle is?

Thanks,
nexos

One of the GOP entry is the "Console Splitter". It is basically a virtual device used to draw on all screens at the same time. It doesn't represent a real hardware device. You can identify this entry by checking if it has a device path. Here is how I handle it:



Having only one supported mode of 1x120 doesn't make sense, verify that your structures/protocols are properly defined.

That makes sense. I'll check on why it only reports on that resolution

Also, some firmwares expose funny bugs on that instance. e.g. my old laptop HP Probook 4530s. This handle's GOP instance doesn't cause drawing, when using its Blt() even though the latter returns success. But the drawing appears on the screen after the loader exits to the fw, for short duration before the fw's Boot Manager redraws its own UI. You also can make it stay for longer, just don't turn off the event on the redrawing callback.


To kzinti, I am wondering, what made you include that code into your loader? I am asking because for the vast majority of machines, both VMs and real hardware this no DevicePath instance handle works just as fine as the other one. For me, only for the aforementioned laptop it didn't. I didn't see any hints on this in the spec. Without them this trickery looks like a bitter experience, trial and error. I refused to insert this hack, thinking it's just an oddity of a particular FW on a particular group of one vendor hw. What inspired to you insert it?

Also, interesting to note, that the spec says, all the handles must have Device Path instance installed. This weirdo handle returns EFI_NOT_SUPPORTED btw. even the reference implementation screws the spec up.

I am simply doing this to enumerate available display devices that can be used by my kernel. At this time I only have a generic display driver that needs memory-mapped framebuffers.

I discovered this "fake display" while attempting to retrieve EDID data for each display. IIRC, it doesn't have any.

I see, thank you. Well, I just pass the framebuffer base in the loader block so far.

The only problem with checking if the handle has a device path is that U-Boot (oddly) appears to not put device paths on any GOP handles. Which IMO is a bug on their part.

If so, it is certainly a bug. Are you sure, uboot doesn't put a DPP instance at any GOP handles?

After this topic kicked in, I gave it a thought and decided to add filtering out this DDP-less handle in my code. Now my work HP Probook 4530s happily paints the Boot Screen,

but I realized, this new code wouldn't paint anything on "powered by uboot" ARM machines. Which I can't test now on my own, unfortunately.

btw, nexos, in addition to the previous question, could you please tell the board(s), which you've experienced this behavior with? I went through the list of defconfigs in mainline uboot and was shocked to see, that basically only some rk3399 ones have GOP support. Personally, I worked with an exactly such one - Rock Pi 4B, but I believed, there are more SoCs having this level of support. thanks edk2 ports start to appear.

I've personally only tested U-Boot in a QEMU virtual machine on RISC-V. It was using VGA as the display hardware. I'll have to fire up an ARM virtual machine with U-Boot to test it. Normally I test ARM with EDK2 as it superior in almost every way (IMO).