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:
smime.p7s
Description: S/MIME cryptographic signature
