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