On 06/22/2012 01:02 AM, Duncan wrote: > Richard Yao posted on Thu, 21 Jun 2012 05:33:22 -0400 as excerpted: > >> A firmware replacement for the BIOS does not need to worry about floppy >> drives, hard drives, optical drives, usb devices, isa devices, pci >> devices and pci express drives, etcetera, because those live on buses, >> which the kernel can detect. > > But you have to be able to load the kernel first, before it can do all > that detection. And to load it, you need to be able to read the device > it's located on, which in a modern x86 system (as contrasted with mips/ > arm) generally means detection of what's there, some mechanism to choose > which available devices to check for a kernel or boot loader or whatever, > and some way to dynamically configure it, since many devices are simply > (device info probable) bricks until configured, these days. > > Sure, you can boot directly to a Linux kernel /as/ your firmware (as Ian > S suggested), but then you're back to hard-configuring it in ordered to > do so, thus losing all that extra flexibility that's part of what makes > x86 different. Which was the question that I was addressing. >
Placing it in the firmware is what I suggested. I also later stated that it is possible for the firmware to contain an initramfs that would enable it to start a kernel located on a device. It seems to me that this would work if device trees for motherboards were readily available and the EEPROM chips have sufficient capacity. I am under the impression that UEFI firmware is large enough that capacity on UEFI motherboards should not be an issue. The main issue would be obtaining device trees.
