Gentoo Archives: gentoo-dev

From: Richard Yao <ryao@g.o>
To: gentoo-dev@l.g.o
Subject: Re: [gentoo-dev] Re: Killing UEFI Secure Boot
Date: Fri, 22 Jun 2012 05:33:14
In Reply to: Re: [gentoo-dev] Re: Killing UEFI Secure Boot by Richard Yao
On 06/22/2012 01:10 AM, Richard Yao wrote:
> 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. >
Before anyone says it, information on how to initialize the memory controller and possibly a few other bits prior to loading the kernel is also necessary. I omitted that by mistake.