[coreboot] [Qemu-devel] Release plan for 0.12.0
jljusten at gmail.com
Sat Oct 3 02:32:32 CEST 2009
It sounds like there is a whole lot of overlap in what coreboot and
tianocore are trying to enable.
The key difference is that tianocore is focused on enabling the UEFI
interfaces within platforms.
OS loaders in UEFI are UEFI applications, and therefore just like in
the case of the UEFI shell (which is a UEFI application), they could
be embedded in the ROM. So, this is similar to the coreboot payloads
concept. But, it is not quite as central of a design goal for UEFI
systems as it appears to be within coreboot.
UEFI does provide runtime services that an OS can make use of, so that
sounds a bit different that coreboot. (Linux does have support for
these interfaces.) Essentially you can think of UEFI as a better
spec'd version of what the legacy BIOS was, but with more
extensibility designed into the interfaces.
Anyway, it sounds like a useful project might be to develop a UEFI
coreboot payload based on the tianocore.org code. Our DUET platform
would only work on top of seabios, and OVMF has some overlap in
hardware initialization along with being a VM/QEMU specific solution.
Of course, we are always glad to hear if people are able to make use
of our code, and we like to encourage any UEFI or tianocore related
contributions to tianocore.org.
On Fri, Oct 2, 2009 at 16:05, Carl-Daniel Hailfinger
<c-d.hailfinger.devel.2006 at gmx.net> wrote:
> On 03.10.2009 00:28, Jordan Justen wrote:
>> On Fri, Oct 2, 2009 at 14:39, Carl-Daniel Hailfinger
>> <c-d.hailfinger.devel.2006 at gmx.net> wrote:
>>> Jordan, I have to admit that I'm surprised OVMF was apparently created
>>> from scratch although quite a few (established) hardware init solutions
>>> already exist for Qemu: SeaBIOS, Bochs BIOS, coreboot, and some old
>>> hobbyist projects.
>> The edk2 project provides an infrastructure for building complete UEFI
>> firmware solutions. OVMF is a sample platform which demonstrates how
>> edk2 can be used to build firmware to boot a UEFI platform.
> I wish to apologize for the misunderstanding. I thought OVMF was only
> hardware init. Thanks for correcting me.
>> Aside from just this, OVMF is an effort to support VMs on edk2. (Ie,
>> more than just QEMU.) Ideally the project, and code of OVMF could be
>> used by any VM vendor as a sample for building UEFI compatible
> How does it relate to real hardware? You mention OVMF as an effort to
> support VMs on edk2. Does this mean that VMs need special support or
> that real hardware has different needs?
>> Most of the code required to support QEMU was already open sourced on
>> edk2 before OVMF was launched. At the time that we started OVMF, it
>> did not seem like any project was targeting UEFI support on QEMU.
>> Tristan Gingold had done a port for UEFI QEMU support, but at that
>> time it did not seem to be functional with the current QEMU, nor
>> actively developed.
> I see.
>>> I'd like to understand the reasons for that and fix
>>> them in coreboot (Kevin O'Connor will probably fix them in SeaBIOS).
>> If you want to remove any need for OVMF on QEMU, then I think all that
>> is needed is to support booting UEFI OS's for both i386 and x86-64.
>> Of course, we may still have some use for the OVMF project on edk2 as
>> a sample platform.
> Given that my original statement incorrectly assumed OVMF was only about
> hardware init, please let me try to express what I originally meant (and
> which came across with unintended meaning).
> I hope to use all EFI support code from OVMF, keep SeaBIOS, and have
> coreboot as common hardware init base.
>>> you ported/modified existing code, I'd be interested in the original
>>> codebase to learn from it (especially what you had to change).
>> As I mentioned above, a good portion of the code was already available
>> in edk2.tianocore.org.
> Thanks for the pointer.
>> Edk2 is BSD licensed, and therefore from a
>> licensing perspective should be easy for your project to utilize.
> (Speaking with my coreboot hat on.)
> The goal of coreboot is not to assimilate and change other projects, but
> to provide hardware init for any code which needs it.
> After hardware init, it passes control to a payload (SeaBIOS, UEFI,
> GRUB2, FILO, Linux, Plan9...). There are no callbacks to coreboot, each
> payload is expected to talk to the hardware on its own. Except for ACPI
> tables (and a memory map), nothing of coreboot stays in memory after
> passing control to that payload. If you want some basic hardware drivers
> for your favourite payload, you can use the BSD-licensed libpayload
> library in your code, but most payloads (SeaBIOS, GRUB2, ...) have their
> own drivers anyway.
> Operating systems like Linux and Plan9 which do not need any BIOS/EFI
> interface can be stored in the ROM and will be booted directly by
> coreboot (if in ROM). Boot loaders like GRUB2 or FILO don't need
> BIOS/EFI either, can be stored in ROM and will then be booted directly.
> BIOS and EFI code can be used as a coreboot payload in ROM as well. Some
> people are even working on making U-Boot available as coreboot payload.
> The idea is to have coreboot handle all the hardware-specific
> initialization and allow all other code to be mostly hardware-agnostic
> (unless said code wants to implement drivers). The clean interface
> (well, no interface, coreboot just passes control to the payload) allows
> payloads to do whatever they want as long as they provide a single
> 32-bit entry point coreboot can jump to.
More information about the coreboot