[Adding the coreboot list to CC. Please ignore the moderation messages, your addresses will be whitelisted ASAP.]
On 02.10.2009 20:53, Anthony Liguori wrote:
Carl-Daniel Hailfinger wrote:
Given that you can easily pack coreboot+SeaBIOS+UEFI into one ROM and have coreboot boot either SeaBIOS (BIOS interface) or UEFI (EFI interface), wouldn't that solve all problems in one go? You get an unified stack and don't have to mess around with different firmware files because coreboot can read in a Qemu machine config option (or NVRAM/CMOS) and select the interface based on that.
If you want to to work seamlessly, you need to check for the EFI system partition to see whether it's an EFI capable OS and then fallback gracefully to SeaBIOS boot.
Hm. Wouldn't that be a layering violation (hw init != reading the disk) and also cause problems if you want to boot an EFI capable OS from SeaBIOS? I can think of someone having an EFI bootable disk image who wants to boot that disk image with EFI and BIOS without having to repartition.
The hardware init part would be identical for all variants, only the interface would differ. coreboot works now and has the benefit of supporting real hardware as well, so the difference between a setup inside Qemu and a setup on real hardware is minimal.
Tianocore's OVMF project should provide all the required initialization for EFI on QEMU.
Yes, but then we'd have two sets of hardware init: OVMF for EFI, SeaBIOS for SeaBIOS. That also means each hw init codebase has to support the new Q35 chipset proposed for Qemu.
It's not any better if SeaBIOS gets changed into a CSM for EFI. Then you have SeaBIOS on top of EFI on top of OVMF. As I understand it, OVMF had less testing than the Bochs BIOS or SeaBIOS on Qemu.
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. 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 ported/modified existing code, I'd be interested in the original codebase to learn from it (especially what you had to change).
The coreboot solution would also avoid converting SeaBIOS because SeaBIOS already works as coreboot payload (that's how coreboot developers call the CSM).
I'll bite, what's the advantage of doing coreboot + SeaBIOS vs. SeaBIOS alone? Forget about EFI for the moment, should be considering switching to coreboot + SeaBIOS for 0.12?
Advantages: - Code coverage increase: SeaBIOS is used with coreboot on real hardware, so the BIOS interface part of SeaBIOS gets a lot more testing than the Qemu hardware init part of SeaBIOS.
- coreboot supports real 440BX hardware besides Qemu, so the coreboot init code is exercised more (and there is still a sizable number of such machines around (clusters), many of them running coreboot).
- Only one ROM image needed. A coreboot ROM can pack the VGA BIOS into the ROM image and SeaBIOS will automatically load it from there. Same for network card ROMs (with gPXE etc.).
- coreboot ROMs (including those with SeaBIOS and/or EFI and/or VGABIOS) are archives and can be listed/edited with cbfstool if you want to know what's in there.
- coreboot ROMs use compression, so you can stuff more code (and PCI option ROMs) into smaller ROMs.
- coreboot has pretty verbose hardware init messages (if you want that) and can be totally silent as well. The messages end up in a log buffer which can be read by the OS (experimental feature, not available by default).
There are a lot more advantages, but I want to give other coreboot developers a chance to chime in. If you add EFI to the mix, the synergies increase.
Regards, Carl-Daniel
On Fri, Oct 2, 2009 at 14:39, Carl-Daniel Hailfinger c-d.hailfinger.devel.2006@gmx.net wrote:
[Adding the coreboot list to CC. Please ignore the moderation messages, your addresses will be whitelisted ASAP.]
On 02.10.2009 20:53, Anthony Liguori wrote:
Carl-Daniel Hailfinger wrote:
Given that you can easily pack coreboot+SeaBIOS+UEFI into one ROM and have coreboot boot either SeaBIOS (BIOS interface) or UEFI (EFI interface), wouldn't that solve all problems in one go? You get an unified stack and don't have to mess around with different firmware files because coreboot can read in a Qemu machine config option (or NVRAM/CMOS) and select the interface based on that.
If you want to to work seamlessly, you need to check for the EFI system partition to see whether it's an EFI capable OS and then fallback gracefully to SeaBIOS boot.
Hm. Wouldn't that be a layering violation (hw init != reading the disk) and also cause problems if you want to boot an EFI capable OS from SeaBIOS? I can think of someone having an EFI bootable disk image who wants to boot that disk image with EFI and BIOS without having to repartition.
The hardware init part would be identical for all variants, only the interface would differ. coreboot works now and has the benefit of supporting real hardware as well, so the difference between a setup inside Qemu and a setup on real hardware is minimal.
Tianocore's OVMF project should provide all the required initialization for EFI on QEMU.
Yes, but then we'd have two sets of hardware init: OVMF for EFI, SeaBIOS for SeaBIOS. That also means each hw init codebase has to support the new Q35 chipset proposed for Qemu.
It's not any better if SeaBIOS gets changed into a CSM for EFI. Then you have SeaBIOS on top of EFI on top of OVMF. As I understand it, OVMF had less testing than the Bochs BIOS or SeaBIOS on Qemu.
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.
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 firmware.
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'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.
If 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. Edk2 is BSD licensed, and therefore from a licensing perspective should be easy for your project to utilize.
The coreboot solution would also avoid converting SeaBIOS because SeaBIOS already works as coreboot payload (that's how coreboot developers call the CSM).
I'll bite, what's the advantage of doing coreboot + SeaBIOS vs. SeaBIOS alone? Forget about EFI for the moment, should be considering switching to coreboot + SeaBIOS for 0.12?
Advantages:
- Code coverage increase: SeaBIOS is used with coreboot on real
hardware, so the BIOS interface part of SeaBIOS gets a lot more testing than the Qemu hardware init part of SeaBIOS.
- coreboot supports real 440BX hardware besides Qemu, so the coreboot
init code is exercised more (and there is still a sizable number of such machines around (clusters), many of them running coreboot).
- Only one ROM image needed. A coreboot ROM can pack the VGA BIOS into
the ROM image and SeaBIOS will automatically load it from there. Same for network card ROMs (with gPXE etc.).
- coreboot ROMs (including those with SeaBIOS and/or EFI and/or VGABIOS)
are archives and can be listed/edited with cbfstool if you want to know what's in there.
- coreboot ROMs use compression, so you can stuff more code (and PCI
option ROMs) into smaller ROMs.
- coreboot has pretty verbose hardware init messages (if you want that)
and can be totally silent as well. The messages end up in a log buffer which can be read by the OS (experimental feature, not available by default).
There are a lot more advantages, but I want to give other coreboot developers a chance to chime in. If you add EFI to the mix, the synergies increase.
Regards, Carl-Daniel
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@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 firmware.
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.
If 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.
Regards, Carl-Daniel
Carl-Daniel,
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.
Thanks,
-Jordan
On Fri, Oct 2, 2009 at 16:05, Carl-Daniel Hailfinger c-d.hailfinger.devel.2006@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@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 firmware.
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.
If 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.
Regards, Carl-Daniel
Jordan Justen wrote:
Anyway, it sounds like a useful project might be to develop a UEFI coreboot payload based on the tianocore.org code.
I believe it might have been done already.
http://www.coreboot.org/File:Tianocoreboot.png
//Peter
On Sat, Oct 3, 2009 at 10:30, Peter Stuge peter@stuge.se wrote:
Jordan Justen wrote:
Anyway, it sounds like a useful project might be to develop a UEFI coreboot payload based on the tianocore.org code.
I believe it might have been done already.
That screenshot mentions DUET which is the tianocore.org UEFI emulator that boots on top of a legacy BIOS. But, it's unclear if it was just DUET, or something based modified specifically for coreboot based on DUET.
I will not dispute that DUET might be a potential solution to achieve UEFI compatibility for QEMU. (I'm not sure, but I think DUET may not be able to boot UEFI OS's at this time.) However, we thought a project such as OVMF was a more direct approach to achieve UEFI compatibility for QEMU.
I see that there was a gnufi project that is mentioned on http://www.coreboot.org/Payloads, but it looks like this project may be stalled. ??
-Jordan
Am Samstag, den 03.10.2009, 14:49 -0700 schrieb Jordan Justen:
On Sat, Oct 3, 2009 at 10:30, Peter Stuge peter@stuge.se wrote:
Jordan Justen wrote:
Anyway, it sounds like a useful project might be to develop a UEFI coreboot payload based on the tianocore.org code.
I believe it might have been done already.
That screenshot mentions DUET which is the tianocore.org UEFI emulator that boots on top of a legacy BIOS. But, it's unclear if it was just DUET, or something based modified specifically for coreboot based on DUET.
Modified: The 16bit loader stub was dropped and replaced by 32bit C code that did mostly the same (pushing code to the right address, jump to the real entry point, as determined by some PE data structures). With some minor modification to Duet it's even possible to remove the 470k limit Duet suffers from, by moving the data chunk to >1MB.
Interaction with BIOS seems to be restricted to expecting the right tables (ACPI, MP table, SMBIOS stuff), which coreboot can provide.
be able to boot UEFI OS's at this time.) However, we thought a project such as OVMF was a more direct approach to achieve UEFI compatibility for QEMU.
With coreboot, seabios and Duet, it should be reasonably simple to provide a single BIOS image that selects (based on nvram - ie. configuration) which interface to provide: PCBIOS or UEFI.
If that is just as simple with OVMF, and easier to maintain, then it's hard to argue with that.
Patrick
Patrick Georgi wrote:
With coreboot, seabios and Duet, it should be reasonably simple to provide a single BIOS image that selects (based on nvram - ie. configuration) which interface to provide: PCBIOS or UEFI.
That isn't terribly useful for QEMU because it implies that QEMU needs to make the decision about which one to use. If QEMU was capable of making that decision without user intervention, then we could just select to load PCBIOS or UEFI.
If that is just as simple with OVMF, and easier to maintain, then it's hard to argue with that.
I don't know enough about EFI, but my concern is that down the road, hardware devices will start to exist that require EFI because they implement EFI modules and not legacy option ROMs. In order to support PCI passthrough of such devices, we will need to provide an EFI capable firmware.
It's really just a matter of how long before this becomes a problem for us.
Anthony Liguori wrote:
Patrick Georgi wrote:
With coreboot, seabios and Duet, it should be reasonably simple to provide a single BIOS image that selects (based on nvram - ie. configuration) which interface to provide: PCBIOS or UEFI.
That isn't terribly useful for QEMU because it implies that QEMU needs to make the decision about which one to use. If QEMU was capable of making that decision without user intervention, then we could just select to load PCBIOS or UEFI.
Are you guys sure you want to go down that road rather than using an UEFI with a CSM? There may be cases when you really want to boot legacy even though your client can do UEFI.
I don't know enough about EFI, but my concern is that down the road, hardware devices will start to exist that require EFI because they implement EFI modules and not legacy option ROMs. In order to support PCI passthrough of such devices, we will need to provide an EFI capable firmware.
It's really just a matter of how long before this becomes a problem for us.
This was attempted for Open Firmware and never happened during its life time. I doubt there is any incentive for vendors to ship devices without legacy option roms, especially since there is no advantage in doing so.
Stefan
Stefan Reinauer wrote:
Anthony Liguori wrote:
Patrick Georgi wrote:
With coreboot, seabios and Duet, it should be reasonably simple to provide a single BIOS image that selects (based on nvram - ie. configuration) which interface to provide: PCBIOS or UEFI.
That isn't terribly useful for QEMU because it implies that QEMU needs to make the decision about which one to use. If QEMU was capable of making that decision without user intervention, then we could just select to load PCBIOS or UEFI.
Are you guys sure you want to go down that road rather than using an UEFI with a CSM?
We'll I've been advocating UEFI + CSM (based on SeaBIOS) so I'm not sure what you meant by 'that road'.
This was attempted for Open Firmware and never happened during its life time. I doubt there is any incentive for vendors to ship devices without legacy option roms, especially since there is no advantage in doing so.
We'll be stuck with legacy option roms for a long, long time. But I also expect there will be a few devices out there that only provide EFI modules.
On 05.10.2009 15:03, Anthony Liguori wrote:
Stefan Reinauer wrote:
Anthony Liguori wrote:
Patrick Georgi wrote:
With coreboot, seabios and Duet, it should be reasonably simple to provide a single BIOS image that selects (based on nvram - ie. configuration) which interface to provide: PCBIOS or UEFI.
That isn't terribly useful for QEMU because it implies that QEMU needs to make the decision about which one to use. If QEMU was capable of making that decision without user intervention, then we could just select to load PCBIOS or UEFI.
Are you guys sure you want to go down that road rather than using an UEFI with a CSM?
We'll I've been advocating UEFI + CSM (based on SeaBIOS) so I'm not sure what you meant by 'that road'.
What about SeaBIOS + CSM (based on DUET)? That allows you to continue using all the Qemu specific init code in SeaBIOS and optionally load UEFI if some hardware needs it. A SeaBIOS based CSM will probably never get merged/supported at tianocore.org because of licensing, but the SeaBIOS + DUET solution should be supportable by upstream.
I can't speak for Patrick, but he probably was concerned about making EFI the default with BIOS as fallback instead of the other way round. Forcing any EFI capable (or semi-capable) OS to be booted with EFI instead of leaving the choice in the hand of the user (NVRAM) or picking the sane default (what almost all boards out there are doing) sounds like a non-sustainable way for Qemu.
This was attempted for Open Firmware and never happened during its life time. I doubt there is any incentive for vendors to ship devices without legacy option roms, especially since there is no advantage in doing so.
We'll be stuck with legacy option roms for a long, long time. But I also expect there will be a few devices out there that only provide EFI modules.
I expect that it will be some time before we see such devices (maybe only at trade show demos if at all). It will start to get interesting once such EFI modules have to interact with classic option ROMs.
Regards, Carl-Daniel
Carl-Daniel Hailfinger wrote:
What about SeaBIOS + CSM (based on DUET)?
That's not quite the same thing.
In EFI, CSM is a specification that defines how to port a legacy BIOS such that it runs as basically an EFI module providing the old legacy BIOS interfaces that OSes support. If you have a set of legacy option roms and efi modules, it defines how all of those things interact with each other to provide a consistent experience.
It's is not at all the same as just switching between EFI and BIOS. It's much more tightly integrated than that.
I can't speak for Patrick, but he probably was concerned about making EFI the default with BIOS as fallback instead of the other way round. Forcing any EFI capable (or semi-capable) OS to be booted with EFI instead of leaving the choice in the hand of the user (NVRAM) or picking the sane default (what almost all boards out there are doing) sounds like a non-sustainable way for Qemu.
Why? As long as it Just Works, I don't think it will ever even cross a users mind.
We'll be stuck with legacy option roms for a long, long time. But I also expect there will be a few devices out there that only provide EFI modules.
I expect that it will be some time before we see such devices (maybe only at trade show demos if at all). It will start to get interesting once such EFI modules have to interact with classic option ROMs.
I think at the high end, we'll see these sooner than you think.
Regards,
Anthony Liguori
On 05.10.2009 15:51, Anthony Liguori wrote:
Carl-Daniel Hailfinger wrote:
What about SeaBIOS + CSM (based on DUET)?
That's not quite the same thing.
In EFI, CSM is a specification that defines how to port a legacy BIOS such that it runs as basically an EFI module providing the old legacy BIOS interfaces that OSes support. If you have a set of legacy option roms and efi modules, it defines how all of those things interact with each other to provide a consistent experience.
That's the design, but how do the implementations hold up? If we ignore the "it's a spec" vs. "it's an industry standard not formalized anywhere" distinction, DUET is an EFI compatibility layer/plugin/module on top of a BIOS and a CSM is a BIOS compatibility layer/plugin/module on top of EFI. If DUET still uses the BIOS as claimed in the FAQ, is should be able to reuse the handlers installed by classic option ROMs without problems.
It's is not at all the same as just switching between EFI and BIOS. It's much more tightly integrated than that.
OK, and how does a user specify "do not, under any circumstance, try to boot with EFI" if a theoretically EFI capable OS (with broken EFI support) is on disk? With current Qemu firmware, it just works (because there is no EFI support). AFAICS EFI by default breaks such installations.
I can't speak for Patrick, but he probably was concerned about making EFI the default with BIOS as fallback instead of the other way round. Forcing any EFI capable (or semi-capable) OS to be booted with EFI instead of leaving the choice in the hand of the user (NVRAM) or picking the sane default (what almost all boards out there are doing) sounds like a non-sustainable way for Qemu.
Why? As long as it Just Works, I don't think it will ever even cross a users mind.
EFI support in enterprise Linux distributions is often not really good. If the firmware tries EFI booting "just because it can", such distributions will be booted with an almost untested path.
We'll be stuck with legacy option roms for a long, long time. But I also expect there will be a few devices out there that only provide EFI modules.
I expect that it will be some time before we see such devices (maybe only at trade show demos if at all). It will start to get interesting once such EFI modules have to interact with classic option ROMs.
I think at the high end, we'll see these sooner than you think.
I just noticed that one big (>4000 nodes) Dell S1850 cluster deployment (sort of mentioned as EFI example in older Intel literature) is considering to drop EFI and use coreboot, maybe with SeaBIOS on top. The journey ahead will be really interesting, regardless of where it ends.
Regards, Carl-Daniel
Am Sonntag, den 04.10.2009, 14:31 -0500 schrieb Anthony Liguori:
I don't know enough about EFI, but my concern is that down the road, hardware devices will start to exist that require EFI because they implement EFI modules and not legacy option ROMs. In order to support PCI passthrough of such devices, we will need to provide an EFI capable firmware.
Why? They're initialized at boot time (by the host's EFI firmware, if necessary), and are usable by the OS then.
Look at OpenFirmware, the drivers initialize the hardware and provide just enough support to be able to start an operating system, but as soon as the operating system runs, it takes over as much as possible, as quickly as possible.
For good reasons, as external drivers (no matter if OF or EFI) impose the same flaw as ACPI: Hardware state changes outside the control of the operating system.
Beyond boot loaders and toy kernels, firmware level drivers hurt more than they help. The world changed since the invention of BIOS in CP/M.
Regards, Patrick Georgi
Patrick Georgi wrote:
Am Sonntag, den 04.10.2009, 14:31 -0500 schrieb Anthony Liguori:
I don't know enough about EFI, but my concern is that down the road, hardware devices will start to exist that require EFI because they implement EFI modules and not legacy option ROMs. In order to support PCI passthrough of such devices, we will need to provide an EFI capable firmware.
Why? They're initialized at boot time (by the host's EFI firmware, if necessary), and are usable by the OS then.
EFI defines new interfaces for OSes to use. A device is going to want to provide drivers for those new interfaces.
For instance, EFI defines a SCSI passthrough protocol such that a RAID controller could install an EFI SCSI driver and that would allow OSes to install to it without requiring special drivers. Of course, I'm sure we'll still see special drivers.
I assume that future RAID controllers will provide both a legacy option ROM (int13 hook) and an EFI SCSI driver. However, I'm also pretty sure that we'll see some subset of devices that only provide the EFI modules because they target a very specific class of hardware/software that will be EFI enabled.
Beyond boot loaders and toy kernels, firmware level drivers hurt more than they help. The world changed since the invention of BIOS in CP/M.
Except that VESA and VGA are still pretty popular. It's not at all uncommon to either use a VESA driver or at least to complete an install with just a VESA driver.
Jordan Justen wrote:
On Sat, Oct 3, 2009 at 10:30, Peter Stuge peter@stuge.se wrote:
Jordan Justen wrote:
Anyway, it sounds like a useful project might be to develop a UEFI coreboot payload based on the tianocore.org code.
I believe it might have been done already.
That screenshot mentions DUET which is the tianocore.org UEFI emulator that boots on top of a legacy BIOS. But, it's unclear if it was just DUET, or something based modified specifically for coreboot based on DUET.
I will not dispute that DUET might be a potential solution to achieve UEFI compatibility for QEMU. (I'm not sure, but I think DUET may not be able to boot UEFI OS's at this time.) However, we thought a project such as OVMF was a more direct approach to achieve UEFI compatibility for QEMU.
We have DUET running as a coreboot payload with a small coreboot specific PE payload loader.
DUET is, however, not an emulator, it is executing much of the same code as all other TianoCore based UEFI implementations.
It is possible to boot an OS just fine with DUET.
Can you explain what you think would be more direct about OVMF than about DUET? As far as I understand it's another build target of EDK2 but besides that shares exactly the same design and even 99% of the code.
Stefan
On Sat, Oct 3, 2009 at 15:02, Stefan Reinauer stepan@coresystems.de wrote:
Jordan Justen wrote:
On Sat, Oct 3, 2009 at 10:30, Peter Stuge peter@stuge.se wrote:
Jordan Justen wrote:
Anyway, it sounds like a useful project might be to develop a UEFI coreboot payload based on the tianocore.org code.
I believe it might have been done already.
That screenshot mentions DUET which is the tianocore.org UEFI emulator that boots on top of a legacy BIOS. But, it's unclear if it was just DUET, or something based modified specifically for coreboot based on DUET.
I will not dispute that DUET might be a potential solution to achieve UEFI compatibility for QEMU. (I'm not sure, but I think DUET may not be able to boot UEFI OS's at this time.) However, we thought a project such as OVMF was a more direct approach to achieve UEFI compatibility for QEMU.
We have DUET running as a coreboot payload with a small coreboot specific PE payload loader.
Meaning you bring up a legacy BIOS compatible interface before starting DUET? DUET depends on a legacy BIOS. My point is that a tianocore.org based coreboot payload ought be able to do away with this legacy BIOS dependency.
DUET is, however, not an emulator, it is executing much of the same code as all other TianoCore based UEFI implementations.
According to the ReadMe.txt for our edk2 DuetPkg, DUET stands for Developer's UEFI Emulation. (Seems a bit of a stretch as an acronym. :) But, 'emulation' is a very squishy word at times, and this doesn't imply that it can't accomplish a lot in terms of UEFI compatibility.
It is possible to boot an OS just fine with DUET.
Can you explain what you think would be more direct about OVMF than about DUET? As far as I understand it's another build target of EDK2 but besides that shares exactly the same design and even 99% of the code.
DUET expects that you boot a legacy BIOS, and then you load DUET off the disk. Once DUET is loaded, there is a (mostly) UEFI compatible environment.
OVMF initializes the VM hardware and at the same time brings up the (mostly) UEFI compatible environment. This is basically the same thing that would normally be done in most UEFI compatible systems. To me, this is a more direct approach to UEFI compatibility for QEMU.
Both DUET and OVMF have some slight issues with providing a fully compatible UEFI variable interface. But I know OVMF can still boot a UEFI OS, and I thought DUET might have a problem in this area. But, I was fairly sure this could have been fixed in DUET, and it appears that perhaps it has been.
Yes, DUET and OVMF likely share 90+% of the same code.
-Jordan
Jordan Justen wrote:
On Sat, Oct 3, 2009 at 15:02, Stefan Reinauer stepan@coresystems.de wrote:
Jordan Justen wrote:
On Sat, Oct 3, 2009 at 10:30, Peter Stuge peter@stuge.se wrote:
Jordan Justen wrote:
Anyway, it sounds like a useful project might be to develop a UEFI coreboot payload based on the tianocore.org code.
I believe it might have been done already.
That screenshot mentions DUET which is the tianocore.org UEFI emulator that boots on top of a legacy BIOS. But, it's unclear if it was just DUET, or something based modified specifically for coreboot based on DUET.
I will not dispute that DUET might be a potential solution to achieve UEFI compatibility for QEMU. (I'm not sure, but I think DUET may not be able to boot UEFI OS's at this time.) However, we thought a project such as OVMF was a more direct approach to achieve UEFI compatibility for QEMU.
We have DUET running as a coreboot payload with a small coreboot specific PE payload loader.
Meaning you bring up a legacy BIOS compatible interface before starting DUET?
No.
DUET depends on a legacy BIOS.
It did not for us, except for the loader which was replaced. We might have been lucky though...
My point is that a tianocore.org based coreboot payload ought be able to do away with this legacy BIOS dependency.
Absolutely agreed.
At some point it might make sense to have a coreboot specific target next to OVMF and DUET, some corebootPkg with specific adaptions and the loader integrated.
The requirements for a coreboot target are very similar to those of OVMF and/or Duet, I guess. No hardware specific code is required, but in addition to what OVMF provides, we feature an in-flash filesystem and we export a coreboot table which contains memory information, cmos layout among other things...
What are the chances to get something like this integrated upstream TianoCore.org?
Can you explain what you think would be more direct about OVMF than about DUET? As far as I understand it's another build target of EDK2 but besides that shares exactly the same design and even 99% of the code.
DUET expects that you boot a legacy BIOS, and then you load DUET off the disk.
It does expect a few tables, but does not seem to make any 16bit calls once loaded.
Once DUET is loaded, there is a (mostly) UEFI compatible environment.
I'm curious on the "mostly" here... what's missing? We certainly want to make sure what we do is fully UEFI compatible.
Both DUET and OVMF have some slight issues with providing a fully compatible UEFI variable interface.
Is that about saving settings in an NVRAM/flash memory?
Stefan
On Sat, Oct 3, 2009 at 16:03, Stefan Reinauer stepan@coresystems.de wrote:
Jordan Justen wrote:
On Sat, Oct 3, 2009 at 15:02, Stefan Reinauer stepan@coresystems.de wrote:
Jordan Justen wrote:
On Sat, Oct 3, 2009 at 10:30, Peter Stuge peter@stuge.se wrote:
Jordan Justen wrote:
Anyway, it sounds like a useful project might be to develop a UEFI coreboot payload based on the tianocore.org code.
I believe it might have been done already.
That screenshot mentions DUET which is the tianocore.org UEFI emulator that boots on top of a legacy BIOS. But, it's unclear if it was just DUET, or something based modified specifically for coreboot based on DUET.
I will not dispute that DUET might be a potential solution to achieve UEFI compatibility for QEMU. (I'm not sure, but I think DUET may not be able to boot UEFI OS's at this time.) However, we thought a project such as OVMF was a more direct approach to achieve UEFI compatibility for QEMU.
We have DUET running as a coreboot payload with a small coreboot specific PE payload loader.
Meaning you bring up a legacy BIOS compatible interface before starting DUET?
No.
DUET depends on a legacy BIOS.
It did not for us, except for the loader which was replaced. We might have been lucky though...
My point is that a tianocore.org based coreboot payload ought be able to do away with this legacy BIOS dependency.
Absolutely agreed.
At some point it might make sense to have a coreboot specific target next to OVMF and DUET, some corebootPkg with specific adaptions and the loader integrated. LegacyBiosInt86 The requirements for a coreboot target are very similar to those of OVMF and/or Duet, I guess. No hardware specific code is required, but in addition to what OVMF provides, we feature an in-flash filesystem and we export a coreboot table which contains memory information, cmos layout among other things...
What are the chances to get something like this integrated upstream TianoCore.org?
I'll refrain from making a prediction on this. But, by my view, tianocore.org is supposed to be an open source community that encourages UEFI related contributions.
However, (at this time) it is going to tougher to get it included at tianocore.org if it is not BSD licensed. I would also suggest discussing the situation on the tianocore.org email lists beforehand to get somewhat of a confirmation before investing a lot into it.
Can you explain what you think would be more direct about OVMF than about DUET? As far as I understand it's another build target of EDK2 but besides that shares exactly the same design and even 99% of the code.
DUET expects that you boot a legacy BIOS, and then you load DUET off the disk.
It does expect a few tables, but does not seem to make any 16bit calls once loaded.
Once DUET is loaded, there is a (mostly) UEFI compatible environment.
I'm curious on the "mostly" here... what's missing? We certainly want to make sure what we do is fully UEFI compatible.
I think tianocore.org will not call these fully UEFI compatible projects, since that implies a lot. Normally these platforms are not run through the UEFI Self-Certification Tests, for example. (Although, this is something I plan to try on OVMF at some point.)
Also, there is the variable situation. (see below)
Both DUET and OVMF have some slight issues with providing a fully compatible UEFI variable interface.
Is that about saving settings in an NVRAM/flash memory?
Yes. Neither platform provides proper UEFI NV variables support. The NV variables can be lost depending on when the platform is shut off, and when the variable has been written to.
But in addition, for DUET, I thought that accessing the NV variable services at OS runtime might not work correctly. (Perhaps cause an exception. Perhaps just always return an error.)
-Jordan
On Fri, Oct 02, 2009 at 11:39:50PM +0200, Carl-Daniel Hailfinger wrote:
I'll bite, what's the advantage of doing coreboot + SeaBIOS vs. SeaBIOS alone? Forget about EFI for the moment, should be considering switching to coreboot + SeaBIOS for 0.12?
Advantages:
- Code coverage increase: SeaBIOS is used with coreboot on real
hardware, so the BIOS interface part of SeaBIOS gets a lot more testing than the Qemu hardware init part of SeaBIOS.
- coreboot supports real 440BX hardware besides Qemu, so the coreboot
init code is exercised more (and there is still a sizable number of such machines around (clusters), many of them running coreboot).
QEMU goal is to run popular OSes and OS usually don't care about low level chipset details. That's way QEMU's chipset emulation implements only bare minimum that is needed for OS to run: no need to initialize memory controller for instance. Coreboot goal, on the other hand, is to talk to real HW, so to use it on QEMU will require implementing chipset features that are not needed to accomplish QEMU goal. So for me real 440BX hardware support of coreboot is actually disadvantage. QEMU don't have real 440BX hardware and there is not point in having one. It is possible to implement 440BX-qemu support in coreboot of course if there are other advantages worth having.
- Only one ROM image needed. A coreboot ROM can pack the VGA BIOS into
the ROM image and SeaBIOS will automatically load it from there. Same for network card ROMs (with gPXE etc.).
- coreboot ROMs (including those with SeaBIOS and/or EFI and/or VGABIOS)
are archives and can be listed/edited with cbfstool if you want to know what's in there.
- coreboot ROMs use compression, so you can stuff more code (and PCI
option ROMs) into smaller ROMs.
- coreboot has pretty verbose hardware init messages (if you want that)
and can be totally silent as well. The messages end up in a log buffer which can be read by the OS (experimental feature, not available by default).
There are a lot more advantages, but I want to give other coreboot developers a chance to chime in. If you add EFI to the mix, the synergies increase.
Regards, Carl-Daniel
-- Gleb.
Hi Gleb,
Gleb Natapov wrote:
So for me real 440BX hardware support of coreboot is actually disadvantage. QEMU don't have real 440BX hardware and there is not point in having one. It is possible to implement 440BX-qemu support in coreboot of course if there are other advantages worth having.
coreboot supports both Intel 440BX and QEMU 440BX since many years. The QEMU support in particular is used intensively by many coreboot developers.
//Peter
I use qemu for a lot of coreboot work. I really depend on qemu for many things I do, not just coreboot related. The qemu target in coreboot has been very heavily used by us to test out new ideas.
That said, I don't see a compelling need to augment seabios with coreboot on qemu *in the standard distribution*. If seabios gets the job done, and gets OSes booted, I think that's sufficient. I don't see a need to complicate anyone's life with something that is, after all, a sideshow for qemu users.
Conversely, I don't see the need to add the huge pile of stuff that comes with UEFI/OVMF/whatever to qemu either. One might argue that having any BIOS callbacks in the OS is a huge mistake, and certainly I've learned in practice that this argument is true.
thanks
ron
On Sat, Oct 03, 2009 at 10:40:35AM -0700, ron minnich wrote:
I use qemu for a lot of coreboot work. I really depend on qemu for many things I do, not just coreboot related. The qemu target in coreboot has been very heavily used by us to test out new ideas.
That said, I don't see a compelling need to augment seabios with coreboot on qemu *in the standard distribution*. If seabios gets the job done, and gets OSes booted, I think that's sufficient. I don't see a need to complicate anyone's life with something that is, after all, a sideshow for qemu users.
Exactly. I am glad to hear that coreboot has support for QEMU, but seabios does the job already, so why add more layers?
Conversely, I don't see the need to add the huge pile of stuff that comes with UEFI/OVMF/whatever to qemu either. One might argue that having any BIOS callbacks in the OS is a huge mistake, and certainly I've learned in practice that this argument is true.
thanks
ron
-- Gleb.
Gleb Natapov wrote:
Exactly. I am glad to hear that coreboot has support for QEMU, but seabios does the job already, so why add more layers?
If SeaBIOS does not need any code at all for QEMU machine init I agree there's no point in considering coreboot.
If QEMU machine specific init is in fact needed in that SeaBIOS, then the answer isn't as obvious..
//Peter
On Sat, Oct 03, 2009 at 08:30:30PM +0200, Peter Stuge wrote:
Gleb Natapov wrote:
Exactly. I am glad to hear that coreboot has support for QEMU, but seabios does the job already, so why add more layers?
If SeaBIOS does not need any code at all for QEMU machine init I agree there's no point in considering coreboot.
SeaBIOS contains the code necessary to initialize the qemu hardware.
For the details see src/mtrr.c, src/pciinit.c, src/shadow.c, and src/smm.c. These codepaths are disabled when SeaBIOS is compiled for coreboot.
-Kevin
On Sat, Oct 03, 2009 at 08:30:30PM +0200, Peter Stuge wrote:
Gleb Natapov wrote:
Exactly. I am glad to hear that coreboot has support for QEMU, but seabios does the job already, so why add more layers?
If SeaBIOS does not need any code at all for QEMU machine init I agree there's no point in considering coreboot.
The code is there already.
If QEMU machine specific init is in fact needed in that SeaBIOS, then the answer isn't as obvious..
May be it is possible to drop seabios init code and use coreboot, but I prefer to dial with one codebase for all BIOS needs. By moving to seabios we try to improve situation not make it worse.
-- Gleb.
On Sat, Oct 3, 2009 at 10:40, ron minnich rminnich@gmail.com wrote:
I use qemu for a lot of coreboot work. I really depend on qemu for many things I do, not just coreboot related. The qemu target in coreboot has been very heavily used by us to test out new ideas.
That said, I don't see a compelling need to augment seabios with coreboot on qemu *in the standard distribution*. If seabios gets the job done, and gets OSes booted, I think that's sufficient. I don't see a need to complicate anyone's life with something that is, after all, a sideshow for qemu users.
Conversely, I don't see the need to add the huge pile of stuff that comes with UEFI/OVMF/whatever to qemu either. One might argue that
This is a valid argument right now. OS X is the only OS today that targets UEFI, and specifically not legacy BIOS. But, in 5 ~ 10 years that might not be the case.
I'll admit that this is a fairly dumb argument to make while we are talking about a QEMU release only a few months from now. But, as UEFI seems to be gaining ground in the industry, I think the sooner QEMU can get this support, the better.
We're specifically trying to help out with this with OVMF. But if a better solution is developed, then so be it.
having any BIOS callbacks in the OS is a huge mistake, and certainly I've learned in practice that this argument is true.
I'm not going to take a side on this matter. But, I think what will be more important is what is used in the majority of OS's and systems. This is why we still put the 16-bit legacy BIOS as the #1 priority after ~30 years. But, like I mention, I think there are signs that this may shift towards UEFI at some point.
-Jordan
Am Samstag, den 03.10.2009, 15:13 -0700 schrieb Jordan Justen:
I'll admit that this is a fairly dumb argument to make while we are talking about a QEMU release only a few months from now. But, as UEFI seems to be gaining ground in the industry, I think the sooner QEMU can get this support, the better.
This smells like self-fulfulling prophecy: Let QEmu support EFI in the hope that EFI actually gains ground (for example by better testability due to available emulation environments)
So you want QEmu as a marketing device - nothing wrong with saying that, right?
Regards, Patrick
On Sat, Oct 3, 2009 at 15:19, Patrick Georgi patrick@georgi-clan.de wrote:
Am Samstag, den 03.10.2009, 15:13 -0700 schrieb Jordan Justen:
I'll admit that this is a fairly dumb argument to make while we are talking about a QEMU release only a few months from now. But, as UEFI seems to be gaining ground in the industry, I think the sooner QEMU can get this support, the better.
This smells like self-fulfulling prophecy: Let QEmu support EFI in the hope that EFI actually gains ground (for example by better testability due to available emulation environments)
So you want QEmu as a marketing device - nothing wrong with saying that, right?
I'm not in marketing. :) But, I do work for Intel, on tianocore.org and thus UEFI. I've been working with Tiano/EFI since ~2003, when Intel started converting its desktop motherboards over to a Tiano code base. So yes, I have a bias.
I think (but no, I cannot back this up) that tens of millions of UEFI compatible motherboards are shipping out each year now. Microsoft has implemented UEFI support in Vista and Win7. Several Linux vendor have or are enabling UEFI support now. Mac OS X implements UEFI.
My point? Well, while I think QEMU support for UEFI is still valuable to help support UEFI adoption, I think it could have done a lot more for UEFI if it was done several years ago. :)
On the flip side, I also think it could have done a lot more to assist Linux to have first rate UEFI support now if it was done several years ago. :(
-Jordan
Jordan Justen wrote:
So you want QEmu as a marketing device - nothing wrong with saying that, right?
I'm not in marketing. :) But, I do work for Intel, on tianocore.org and thus UEFI. I've been working with Tiano/EFI since ~2003, when Intel started converting its desktop motherboards over to a Tiano code base. So yes, I have a bias.
I think (but no, I cannot back this up) that tens of millions of UEFI compatible motherboards are shipping out each year now. Microsoft has implemented UEFI support in Vista and Win7. Several Linux vendor have or are enabling UEFI support now. Mac OS X implements UEFI.
My point? Well, while I think QEMU support for UEFI is still valuable to help support UEFI adoption, I think it could have done a lot more for UEFI if it was done several years ago. :)
Many major vendors (like IBM) are starting to ship (and will eventually exclusively ship) UEFI firmwares. Hardware, particularly the kind targeted at higher end systems, will eventually start to assume the presence of EFI. If we want to support PCI passthrough of these devices, then we'll have to support EFI in some form.
I don't think that's the case.
EFI actually DOES HAVE ground.
Itanium machines are still worldwide used, manufactured and sold. Intel-based Macintoshes used them and ALL of their facilities.
The disadvantages can be a lot. The advantages that I see, are the following (implemented by Apple's EFI): Hardware drivers, so the OS loader can use ANY hardware present. Hardware testing easily programable, as you can use the EFI to call the hardware (unlike PC diagnostics that makes direct and real mode calls to the hardware, making them imposible to test different hardware without implementing all variations -SCSI cards, wifi cards, so on-) Filesystem independent bootloader (it just expects the EFI to have the filesystem and disk driver, then searches the disk for the OS loader) Upgradable drivers without firmware patching (so if I add a wifi card, I can put a driver for netbooting it) Extensive input devices support (USB keyb and mice, bluetooth keyb and mice and infrared remote)
I think that this is impossible (if not nearly to) make using BIOS. I think it is only possible with OpenFirmware or EFI.
And I prefer EFI for the matters of being programable in C (personal distaste for Forth) and the EFI System Partition usability.
A bootloader can fuckinly easy put a good splash without limiting to 12 colors or making calls to the VGA system (for example). What will happen with the GRUB if tomorrow VGA disappears? What a mess...
And I don't work for Intel, IBM, HP, Apple, etc.
In QEMU' side I see that maybe not for 0.12.0 but anyway, EFI is a MUST have if we want to emulate, support, test, patch, anything that uses it, starting with Itanium, continuing with Intel Macintosh, and finishing with all the thousands of PCs (not only from Intel, as I've seen a bunch from Asus and Asrock) that instead of using a BIOS are using a hidden EFI with a boot-by-default CSM.
I'm sure, EFI will prevail over BIOS and sooner or later, also over OpenFirmware. And we need to move with the world, not against it.
Regards, Natalia Portillo
El 03/10/2009, a las 23:19, Patrick Georgi escribió:
Am Samstag, den 03.10.2009, 15:13 -0700 schrieb Jordan Justen:
I'll admit that this is a fairly dumb argument to make while we are talking about a QEMU release only a few months from now. But, as UEFI seems to be gaining ground in the industry, I think the sooner QEMU can get this support, the better.
This smells like self-fulfulling prophecy: Let QEmu support EFI in the hope that EFI actually gains ground (for example by better testability due to available emulation environments)
So you want QEmu as a marketing device - nothing wrong with saying that, right?
Regards, Patrick
Hi Natalia,
I tried to understand your points. Please correct me where I'm wrong.
On 04.10.2009 06:10, Natalia Portillo wrote:
EFI actually DOES HAVE ground.
Itanium machines are still worldwide used, manufactured and sold.
Unless I'm mistaken, Itanium is not x86. Now if we consider EFI for x86 because it has solid standing on Itanium, shouldn't we also consider U-Boot and OpenFirmware for x86 because they have solid standing on ARM/PowerPC?
Intel-based Macintoshes used them and ALL of their facilities.
True.
The disadvantages can be a lot. The advantages that I see, are the following (implemented by Apple's EFI): Hardware drivers, so the OS loader can use ANY hardware present.
Same for BIOS.
Hardware testing easily programable, as you can use the EFI to call the hardware (unlike PC diagnostics that makes direct and real mode calls to the hardware, making them imposible to test different hardware without implementing all variations -SCSI cards, wifi cards, so on-)
Same for BIOS (the only difference is that the interface to the BIOS provides a 16bit interface and EFI provides a 32bit interface).
Filesystem independent bootloader (it just expects the EFI to have the filesystem and disk driver, then searches the disk for the OS loader)
Burn a BIOS together with DOS in the ROM and you get the same functionality. I have seen youtube videos of such systems.
Upgradable drivers without firmware patching (so if I add a wifi card, I can put a driver for netbooting it)
Install DOS with a boot agent on the disk and you get exactly the same feature.
Extensive input devices support (USB keyb and mice, bluetooth keyb and mice and infrared remote)
AFAIK USB keyboard+mouse is supported in pretty much every BIOS out there. Not sure about bluetooth keyboard and infrared remote, but the boards with builtin bluetooth support probably also have a bluetooth keyboard driver in the BIOS.
I think that this is impossible (if not nearly to) make using BIOS. I think it is only possible with OpenFirmware or EFI.
Except for bluetooth keyboard and infrared remote which I'm not sure about, everything you listed above is the same for BIOS and EFI.
And I prefer EFI for the matters of being programable in C (personal distaste for Forth)
Now the Forth argument is something I can agree with. ;-)
and the EFI System Partition usability.
I don't understand what an EFI System Partition is used for. The wikipedia entry suggests that it is essentially a special partition where bootloaders live (instead of using a normal partition for that) and where EFI loads drivers and DOS/Windows PE commandline executables from. That sounds suspiciously like a DOS partition with NTLDR and loadlin.
A bootloader can fuckinly easy put a good splash without limiting to 12 colors or making calls to the VGA system (for example). What will happen with the GRUB if tomorrow VGA disappears? What a mess...
I've seen quite a few GRUB installations with 24-bit color splash screens in high resolutions. Graphics hardware won't disappear from computers any time soon, only the interfaces may change.
And I don't work for Intel, IBM, HP, Apple, etc.
In QEMU' side I see that maybe not for 0.12.0 but anyway, EFI is a MUST have if we want to emulate, support, test, patch, anything that uses it, starting with Itanium, continuing with Intel Macintosh, and finishing with all the thousands of PCs (not only from Intel, as I've seen a bunch from Asus and Asrock) that instead of using a BIOS are using a hidden EFI with a boot-by-default CSM.
Interesting. Do these boards still have a 20-30 second wait time from poweron to bootloader? I've seen coreboot+SeaBIOS achieve 1 second from poweron to bootloader on real x86 hardware, so I always wonder what the commercial BIOSes do during the time we wait for them.
I'm sure, EFI will prevail over BIOS and sooner or later, also over OpenFirmware.
I'm not so sure about that. EFI is "cool", but so were Linux netbooks and nowadays people buy mostly Windows netbooks.
And we need to move with the world, not against it.
Fully agreed.
Many years ago, some EFI proponent told me: "EFI is great. It is a 32-bit BIOS with builtin 32-bit DOS. Now every operating system can use EFI drivers in compatibility mode like Windows 95 used DOS drivers in compatibility mode." That statement had a lasting impression on me and I've yet to see any explanation why that statement would be incorrect. I'm very willing to learn, so if I got something wrong, please educate me.
Regards, Carl-Daniel
Jordan Justen wrote:
I'm not going to take a side on this matter. But, I think what will be more important is what is used in the majority of OS's and systems. This is why we still put the 16-bit legacy BIOS as the #1 priority after ~30 years. But, like I mention, I think there are signs that this may shift towards UEFI at some point.
Looking at today's OSes, the BIOS "interface" is basically completely unused except for loading the OS kernel. For future generations of firmware and computers and virtual machines it might make sense to optimize with that situation in mind.
The industry we're working in does not see UEFI can cope with the problems firmware has today, unfortunately. After seeing EFI fail so badly with the Itanium it would certainly be nice to see if something can evolve from it in a decade, or two. We're watching excitedly.
All the best, Stefan
-
Anthony Liguori -
Anthony Liguori -
Carl-Daniel Hailfinger -
Gleb Natapov -
Jordan Justen -
Kevin O'Connor -
Natalia Portillo -
Patrick Georgi -
Peter Stuge -
ron minnich -
Stefan Reinauer