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