On Tue, 2013-01-08 at 14:41 -0800, Jordan Justen wrote: > On Tue, Jan 8, 2013 at 1:41 AM, David Woodhouse <dw...@infradead.org> wrote: > > Recent versions of the Linux kernel provide an EFI boot stub of their > > own, for interrogating the runtime services and building up the > > bootparams. Where possible, we should use this instead of doing it for > > ourself. (Theoretically, at least.) > > I have a series that enables -kernel to work with a PE/COFF image. (v1 > sent last Nov.) It seems to me that this + EFI_STUB enabled in the > kernel might be a reasonable alternative to this. What do you think?
Unfortunately this isn't going to work for David's usecase of booting a 32-bit EFI-enabled kernel with a 64-bit OVMF (or vice versa). The EFI_STUB was written with the assumption that the firmware won't *allow* you to execute a 32-bit PE/COFF image from 64-bit firmware (and vice versa). To do what David wants the "handover protocol" is really the best option, which means that OVMF needs to load the kernel image *as* a bzImage, understand the boot protocol, and jump to the handover offset, which will invoke the EFI boot stub code in the kernel, without requiring it to interpret the PE/COFF fields in the kernel header. The EFI boot stub implementation was originally written to allow loading a Linux kernel bzImage as a PE/COFF executable by EFI firmware, which means it contains some smarts to construct the boot_params, etc, and understand the Linux boot protocol. Conversely, the handover protocol was designed for boot loaders that *already* understand the Linux boot protocol, allowing them to skip some of the steps performed in the PE/COFF case (which allows them chance to present graphical menus, load things from file systems, etc). Eventually, both schemes end up in the same "boot stub" within the kernel, they just get there via different callstacks. > > +;------------------------------------------------------------------------------ > > +; VOID > > +; EFIAPI > > +; JumpToKernelEFI ( > > +; EFI_HANDLE ImageHandle, > > +; EFI_SYSTEM_TABLE *SystemTable, > > +; VOID *KernelBootParams, > > +; VOID *KernelStart > > +; ); > > +;------------------------------------------------------------------------------ > > +JumpToKernelEFI PROC > > + > > + mov eax, [esp + 12] > > + mov eax, [eax + 264h] > > Is this really the interface?? Matt? Yeah that's dereferencing the handover_offset field in the boot_params, which is going to be the sanest way of allowing this mixing of kernel/firmware bitness. At least, it will be once we add support to the kernel source. -- Matt Fleming, Intel Open Source Technology Center ------------------------------------------------------------------------------ Master Java SE, Java EE, Eclipse, Spring, Hibernate, JavaScript, jQuery and much more. Keep your Java skills current with LearnJavaNow - 200+ hours of step-by-step video tutorials by Java experts. SALE $49.99 this month only -- learn more at: http://p.sf.net/sfu/learnmore_122612 _______________________________________________ edk2-devel mailing list edk2-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/edk2-devel
