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

[Carl-Daniel Hailfinger]

On 04.10.2009 18:06, Natalia Portillo wrote:
>
> 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.

All OLPC laptops (which are x86) have OF. Not sure how many of them are
already deployed, but I think it's roughly a million. (Side note: That
OF implementation has a builtin BIOS emulator/CSM in newer versions to
be able to boot Windows).


>>> 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.

EFI searches the drivers on disk, so it's like booting DOS from disk
which has drivers.


>>> 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.

OK, now I'm intrigued. This implies that an EFI driver can not crash the
OS easily. Given that programming bugs sometimes are really nasty, does
the "not crashing easily" promise apply even if it deliberately tries to
overwrite all of the physical RAM (such driver bugs have existed in the
past, I even have a link somewhere). But that also means (if we ignore
virtualization for a moment) that any OS using an EFI driver has to call
the EFI driver in ring 3 because the calling the EFI driver in ring 0
would negate any memory protection. Is that really the case?


>>> 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.

Neither is EFI.
Linux and DOS and EFI can have file system drivers for various file
systems. They all can execute binaries and those binaries can be
bootloaders. Such bootloaders have the option of either using the
existing VFS interface (to use a Linux term for the generic interface to
file systems) or to implement their own file system drivers to search
the various file systems on disk for bootable operating systems.
loadlin is an example which uses the file system drivers present in DOS
and (assuming that DOS has NTFS or ext2 drivers installed) fits your
description of a file system independent bootloader.


> And filesystem drivers for DOS are not drivers, hacks and traps to INT
> 21h.

Erm. Which filesystem driver for DOS is not hooking INT 21h?


>>> 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.

Given that EFI loads these wifi drivers for netbooting from disk as per
your earlier statement about on-disk EFI drivers, does that mean wifi
netbooting breaks once you remove the disk?


>> 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).

Wikipedia says the EFI System Partition is a FAT variant. "load a
bootloader" implies that the thing loading the bootloader is a
bootloader as well. Such a construct is not uncommon, take a look at
GRUB booting Windows where it just acts as a bootloader for the Windows
bootloader.


>>> 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!

What do you want to know?

How to use 24-bit color for boot loader splash screens on systems with
BIOS? I think there are patches floating around for GRUB and LILO, and
some other bootloaders sport graphical interfaces by default.

Or how to deal with systems that don't have a VGA realmode interface
anymore? Such systems already exist (VIA EPIA has that option), and let
me tell you that they run coreboot+Linux instead of EFI.


>> 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.

How long does the normal Apple POST take? Longer than a second? If yes,
where does it spend that time?


>> 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.

I see. Thanks for clarifying this.

Looking at the wikipedia definition for operating systems, EFI fits that
definition pretty well. It has drivers, hardware abstraction, and runs
applications.

There are good reasons to have full operating systems in the firmware.
The programming model is easier, the environment is userfriendly, and if
there are good recovery and diagnosis tools available for that operating
system, you can simply reuse them.

And since having an OS in the firmware is good, people have created
systems which have coreboot+Linux in the firmware flash chip. Some
variants with coreboot+Linux+KVM (the virtualization solution) and
coreboot+Linux+busybox+X(Kdrive)+windowmanager(matchbox)+terminal(rxvt)
are already out there. A boot demo video of the latter variant is here:
http://www.youtube.com/watch?v=nuzRsXKm_NQ

Of course, Linux can act as a boot loader as well (see kboot and
petitboot and runnix), and I've heard of people using Linux in firmware
to boot some Windows variant over Fibrechannel.


Regards,
Carl-Daniel

-- 
http://www.hailfinger.org/