| |||||||||||||
The Extensible Firmware Interface - an introductionThe Extensible Firmware Interface - an introductionPosted Aug 11, 2011 15:31 UTC (Thu) by jhhaller (subscriber, #56103)Parent article: The Extensible Firmware Interface - an introduction
One of the slowest things with BIOS is the multitude of BIOS plugins, each of which enumerates hardware, spins up drives, or adds a delay allowing the user to interact with that plugin. This includes things like RAID controller(s)and PXE Boot. On some server configurations, the BIOS takes longer to run than the OS boot.
Does EFI make this any better, such as integrating all of the delays for individual device/capability setups into the main setup, or enumerating hardware in parallel? If you can work that back into a future article, that would be great.
(Log in to post comments)
The Extensible Firmware Interface - an introduction Posted Aug 11, 2011 15:39 UTC (Thu) by mjg59 (subscriber, #23239) [Link]
Hardware enumeration's only done once. It'll typically be a matter of pulling a device tree out of ACPI, adding on any additional enumerated PCI or USB devices. Beyond that? I don't think the driver model handles parallel driver init, but haven't looked closely. Remember that we're talking about something that's closer to DOS than anything with a scheduler.
The Extensible Firmware Interface - an introduction Posted Aug 12, 2011 8:06 UTC (Fri) by marcH (subscriber, #57642) [Link]
There is something like a primitive scheduler in EFI. You can init the initialization of a device and come back later.
The Extensible Firmware Interface - an introduction Posted Aug 11, 2011 15:50 UTC (Thu) by nye (guest, #51576) [Link]
>On some server configurations, the BIOS takes longer to run than the OS boot.
Not just server configurations. For about 3 years now all my Debian systems have taken around as long, if not longer, to get from power on->grub than from grub->login screen.
Sometimes there are options you can disable to improve matters, eg my main desktop has two SATA controllers built in to the motherboard, one of which also does PATA. Disabling it means losing PATA and a couple of SATA ports, but saving about 10s from each boot. When grub->desktop takes ~40-50s, that's a lot. With an SSD grub->desktop is likely to be more like 20-30s, so it's even more significant.
The Extensible Firmware Interface - an introduction Posted Aug 14, 2011 20:32 UTC (Sun) by cortana (subscriber, #24596) [Link]
Check out the kexec-tools package, if you haven't already.
The Extensible Firmware Interface - an introduction Posted Aug 15, 2011 17:58 UTC (Mon) by knobunc (subscriber, #4678) [Link]
kexec helps reduce reboot time, does it help with a cold boot?
The Extensible Firmware Interface - an introduction Posted Aug 23, 2011 10:22 UTC (Tue) by etienne (subscriber, #25256) [Link]
If I may, I would like to say something about kexec.
It is not to criticise kexec, that probably works perfectly, it is just about one use case: booting a different kernel release.
Let's imagine yesterday kernel managing yesterday device.
Back to today, I have currently booted the today kernel, which knows how to drive the super-duper function, and because it has recognised the more powerful today's device, it has enabled the super-duper function in the device by setting the previously "do not touch" bit (now enable super-duper function bit) to the device register.
Now, if I kexec yesterday's kernel, it will not change the "do not touch" bit, but it does not have the super-duper function driver neither.
The Extensible Firmware Interface - an introduction Posted Aug 23, 2011 10:28 UTC (Tue) by cortana (subscriber, #24596) [Link]
It is a real risk, to be certain: but not in kexec itself; just in the tools that decide which kernel will be kexec'd when the shutdown command is issued.
Debian's kexec-tools package for instance always boots /vmlinuz, which is a symlink maintained by the various linux-image-* packages and which usually points to the latest installed kernel. IMO this is a mistake, and kexec should attempt to boot into the currently installed kernel, if it still exists.
This doesn't sound too hard--just look at the results of uname(2) and then look for a matching file in /boot. I think this would make your scenario less likely, however (at least in Debian's case) they only use a different filename for different kernel releases and ABI-changing updates to the same release, so the file /boot/vmlinux-3.0.0-1-amd64 that currently exists on my system may have been updated since the system booted with a file of the same name.
The Extensible Firmware Interface - an introduction Posted Aug 11, 2011 17:17 UTC (Thu) by jcm (subscriber, #18262) [Link]
I don't think the driver model does parallelism :) It's written using polled IO and is only supposed to be used for as long as you're explicitly driving some device.
FWIW, I'm a huge fan of things like EFI. And layers aren't a problem if you don't have to care about the layer beneath. For example, on ARM systems, we are increasingly booting using EFI (a good thing) and sometimes even doing so in convoluted ways (x-loader->u-boot->tianocore) but it doesn't matter because the time taken to do these steps is minimal overall. I'm far more worried about layers of complexity being added in the desktop than in EFI, which is at least a cross-vendor, cross-platform standard we can all use.
Jon.
The Extensible Firmware Interface - an introduction Posted Aug 11, 2011 23:14 UTC (Thu) by nix (subscriber, #2304) [Link]
Of course, you don't have to care about the layers underneath as long as they are bug-free and do what you want.
I'm sure that in future articles Matthew will assure us that EFI implementations are bug-free flawless jewels of perfect software engineering which work brilliantly on all operating systems, just as we would expect from the geniuses and wizards who work on BIOSes. (It's true: they do, as long as the set of operating systems consists of one single version of Windows on one single hardware configuration and it was only booted once during testing while holding a horseshoe and a rabbit's foot above the monitor.)
The Extensible Firmware Interface - an introduction Posted Aug 13, 2011 0:54 UTC (Sat) by Lennie (subscriber, #49641) [Link]
On my desktop the BIOS takes longer than the Linux-based OS on my SSD. :-(
I keep looking at the CoreBoot supported mainboards list, but it isn't on it.
The Extensible Firmware Interface - an introduction Posted Aug 18, 2011 21:20 UTC (Thu) by jd (guest, #26381) [Link]
Check the source, rather than the website. They don't always link boards that are supported.
|
|||||||||||||