Re: [PATCH] Fix efifb initialisation when the only GOP device implements ConOut.

[David Woodhouse <dwmw2-wEGCiKHe2LqWVfeAwA7xHQ@public.gmane.org>]

[-- Attachment #1: Type: text/plain, Size: 2565 bytes --]

On Mon, 2013-01-07 at 17:15 +0000, Matt Fleming wrote:
> On Mon, 2013-01-07 at 02:04 +0000, David Woodhouse wrote:
> > On Sun, 2013-01-06 at 00:13 +0000, David Woodhouse wrote:
> > > When booting under OVMF we have precisely one GOP device, and it
> > > implements the ConOut protocol.
> > > 
> > > We break out of the loop when we look at it... and then promptly abort
> > > because 'first_gop' never gets set.
> > 
> > Hmmm. I've just fixed OVMF so that when qemu is invoked with the
> > '-kernel' argument, it uses the EFI handover protocol. And now graphics
> > is broken on kernels *without* this patch. I can't even initialise the
> > graphics info in OVMF (as it does for non-EFI handover) because the
> > kernel helpfully zeroes it all out before failing to set it up
> > correctly.
> > 
> > Does it make sense to bump the boot protocol to 2.12 to indicate that
> > this bug is fixed, and then let things like OVMF use the EFI handover
> > protocol only for boot protocol >= 2.12? Or is there a better way...?
> 
> Bumping the boot protocol seems like a sensible idea.
> 
> Peter, any objection to that?

I'd like to fix the 32-bit EFI entry point first. Although the PE entry
point helpfully adds 4 to $esp to effectively pop the unwanted return
address off the stack, the EFI entry point at 0x30 doesn't. So I'm doing
this for now to test OVMF, while I work out why the EFI stub is then
crashing in the PCI ROM handling:

--- a/arch/x86/boot/compressed/head_32.S
+++ b/arch/x86/boot/compressed/head_32.S
@@ -50,8 +50,10 @@ ENTRY(startup_32)
        pushl   %eax
        pushl   %esi
        pushl   %ecx
+       pushl   %ecx
 
        .org 0x30,0x90
+       add     $0x4, %esp
        call    efi_main
        cmpl    $0, %eax
        movl    %eax, %esi

On fact, the whole 32-bit vs 64-bit entry point seems entirely
confusing.

It seems that a bootloader needs to *know* whether it's loading a 64-bit
or a 32-bit kernel image. A quick check shows that grub is always
running non-EFI kernels in 32-bit mode, at the 32-bit entry point. So
that's fine. But for the EFI stub, a 64-bit grub unconditionally jumps
to the undocumented¹ 0x200 + handover_offset, while a 32-bit grub omits
the 0x200. So if you attempt to boot a 64-bit kernel from a 32-bit grub,
or vice versa, it's just going to crash.

What is the bootloader *supposed* to do?

-- 
dwmw2
¹ Not strictly true. It's documented as "THIS MAY CHANGE. BOOTLOADERS
  SHALL USE THE ELF HEADERS TO FIND IT" in .../boot/compressed/head_64.S

[-- Attachment #2: smime.p7s --]
[-- Type: application/x-pkcs7-signature, Size: 6171 bytes --]