qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [coreboot] [Qemu-devel] Release plan for 0.12.0


From: Natalia Portillo
Subject: Re: [coreboot] [Qemu-devel] Release plan for 0.12.0
Date: Sun, 4 Oct 2009 17:06:36 +0100


El 04/10/2009, a las 12:16, Carl-Daniel Hailfinger escribió:

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?
EFI is used in x86 as well, contrary to OF.


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.
BIOS searches for them in ROM space.
No manufacturer ROM, no driver.


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).
Not only a 16 bit interface, REAL MODE interface.
Your driver can crash my driver easily.


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.
DOS is not a filesystem independent bootloader.
And filesystem drivers for DOS are not drivers, hacks and traps to INT 21h.


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.
Take any of it, no support.
I know a couple of Asus and Abit motherboards with integrated Wifi and Bluetooth.

Yet to see wifi netboot in ANY wifi card with bios.
Seen EFI netboot in Apple wifis.


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.
The partition is empty by default.
EFI expects a directory structure and loads drivers from this partition if present, without loading any bootloader. That allows it to load a bootloader from an ext3 filesystem, a direct ELF kernel from XFS, or a netboot updated driver for a WiMAX (for example).


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.
So, say me how!


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.
Nope. The only "wait" is the normal Apple POST. Then the CSM takes 1 or 2 seconds to load the OS.


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.

EFI is not a 32-bit BIOS, it is a 32 or 64 bit protected mode hardware initialization and booting interface.



reply via email to

[Prev in Thread] Current Thread [Next in Thread]