| |||||||||||||
The Extensible Firmware Interface vs early LinuxThe Extensible Firmware Interface vs early LinuxPosted Aug 14, 2011 21:33 UTC (Sun) by giraffedata (subscriber, #1954)In reply to: The Extensible Firmware Interface - an introduction by mturquette Parent article: The Extensible Firmware Interface - an introduction I think it goes to show it would be simpler just to use Linux in place of DXE. It doesn't have to be the same Linux that will ultimately run on the machine; just something to load the real OS. That's probably naive, but what's the problem? Is Linux too big? Too slow? Reflecting on the fact that one often has to get a new motherboard or at least risk an in-situ BIOS upgrade in order to boot from a new type of device, I've often thought that motherboards should be able to do one thing at boot time: read bytes from USB storage device plugged into a particular socket inside the box and branch to them. I'd put a Linux boot image on there, configured to load and bring up the real system. If I got a new kind of boot device, I'd just build a new Linux system with a driver for it and store it on that USB stick. If I accidentally bricked the system that way, I'd just plug in a different USB stick and recover.
(Log in to post comments)
The Extensible Firmware Interface vs early Linux Posted Aug 15, 2011 9:25 UTC (Mon) by marcH (subscriber, #57642) [Link]
You favor USB but other people/platforms favor something else. Anything else.
> I think it goes to show it would be simpler just to use Linux in place of DXE.
Isn't there any actual "LinuxBIOS" project out there?
> That's probably naive, but what's the problem? Is Linux too big? Too slow?
Not in the right place at the right time? GPLed?
Maybe a bit of all these.
The Extensible Firmware Interface vs early Linux Posted Aug 15, 2011 14:23 UTC (Mon) by giraffedata (subscriber, #1954) [Link] You favor USB but other people/platforms favor something else. Anything else. It doesn't matter to me if it's USB, and I'm not aware of anyone proposing anything else. The essential element of the concept is a separate removable storage device just for the bootloader. I can't think of anything other than a USB memory stick that would be practical for that, but if there is something, I'm all for it.
The Extensible Firmware Interface vs early Linux Posted Aug 15, 2011 22:08 UTC (Mon) by marcH (subscriber, #57642) [Link]
The Extensible Firmware Interface vs early Linux Posted Aug 18, 2011 19:36 UTC (Thu) by giraffedata (subscriber, #1954) [Link] I can't tell what point posting the URL listing lots of serial communication protocols is supposed to make. Is this perhaps a response to my saying I don't know of anyone proposing a protocol other than USB for talking to a bootstrap-only device? Has someone proposed some other serial communications protocol for that? Is there one you would recommend?
The Extensible Firmware Interface vs early Linux Posted Aug 22, 2011 12:41 UTC (Mon) by marcH (subscriber, #57642) [Link]
A significant number of the interfaces in this list are used for booting. If you "simplify" your firmware design by hardcoding to any of these you will make users of the others unhappy.
Granted, you can imagine dream and modular firmware code that can be selectively trimmed down on a per-platform basis. EFI might get there but why would you do this for (expensive) PC motherboards? A development effort to lose some of your customers?!
By the way USB + managed flash is among the most expensive solutions; this matters for low cost embedded systems.
The Extensible Firmware Interface vs early Linux Posted Aug 22, 2011 19:53 UTC (Mon) by giraffedata (subscriber, #1954) [Link] A significant number of the interfaces in this list are used for booting. If you "simplify" your firmware design by hardcoding to any of these you will make users of the others unhappy. I think you're pointing out the dilemma of standardization. You pick one of many paths in order to reap the benefits of uniformity, but at the cost of going down a path that isn't ideal for some, or even all, particular cases. Of course, we standardize all the time and companies that were relying on the protocol that didn't get chosen suck it up and switch.
A development effort to lose some of your customers?! Unless you're talking about losing customers because it costs more, you've misunderstood the proposal, because customers can still use all of those boot protocols -- the ROM loads from the USB device the bootloader that knows how to load Windows from a SATA drive. By the way USB + managed flash is among the most expensive solutions; this matters for low cost embedded systems. I agree my scheme is not appropriate for embedded systems. It would add very little and cost a lot.
The Extensible Firmware Interface vs early Linux Posted Aug 22, 2011 22:35 UTC (Mon) by marcH (subscriber, #57642) [Link]
> I think you're pointing out the dilemma of standardization.
Yes something like that.
> you've misunderstood the proposal, because customers can still use all of those boot protocols -- the ROM loads from the USB device the bootloader that knows how to load Windows from a SATA drive.
I think I understood the proposal; it looks like we have different customers in mind. I am considering the "ROM loads from X" part while you are considering the "bootloader that knows..." part.
The Extensible Firmware Interface vs early Linux Posted Aug 19, 2011 9:53 UTC (Fri) by etienne (subscriber, #25256) [Link]
> read bytes from USB storage device plugged into a particular socket inside the box and branch to them
Well, they have first to recognise that the USB disk first sector contains executable code, else they will often jump to a lot of zero instructions.
But what I wanted to say is that at the bootloader level you do not have USB, you have OHCI, UHCI, EHCI or xHCI - and more in the embedded world.
The Extensible Firmware Interface vs early Linux Posted Aug 19, 2011 16:10 UTC (Fri) by giraffedata (subscriber, #1954) [Link] Well, they have first to recognise that the USB disk first sector contains executable code, else they will often jump to a lot of zero instructions. I think I'd prefer that it not do that check. It's an opportunity for something to become incompatible. at the bootloader level you do not have USB, you have OHCI, UHCI, EHCI or xHCI - and more in the embedded world. But that is just between the bootstrap ROM and the USB host controller, both of which are permanently attached to the same piece of hardware in my scheme. So there's no chance of incompatibility. The standardness of USB that I'm interested in is between the host controller/hub and the USB stick, such that you can 1) easily get media; and 2) easily write the media using pretty much any computer.
The Extensible Firmware Interface vs early Linux Posted Aug 22, 2011 14:39 UTC (Mon) by etienne (subscriber, #25256) [Link]
> I think I'd prefer that it not do that check. It's an opportunity for something to become incompatible.
Well, they could have trusted that if the device contains a partition which is marked bootable, the device is itself bootable, but most BIOS manufacturer did not do so.
Note that in your scheme, you still want to simply write you Linux kernel to the USB disk (and not do "cat kernel > /dev/sdb") so you need a bootloader which will analyse the partitions and the filesystem inside it - so once the bootloader is running it still need access to the underlying device to access that file (using BIOS/EFI disk services), the BIOS/EFI still need to respond to USB interrupts.
The Extensible Firmware Interface vs early Linux Posted Aug 22, 2011 20:13 UTC (Mon) by giraffedata (subscriber, #1954) [Link] I would say, checking that the beginning of the MBR is not completely blank is still acceptable, to allow someone to boot without removing all USB stick plugged-in - but checking Windows MBR assembly crosses the limit. I think you've misunderstood what the ROM bootloader does in this scheme. It is intentionally too dumb to choose a boot device. It always loads the next stage from the same physical place (a particular USB socket inside the box). The code loaded can use fancy intelligence that evolves with technology to choose a boot device from which to load the OS. Note that in your scheme, you still want to simply write your Linux kernel to the USB disk (and not do "cat kernel > /dev/sdb") so you need a bootloader which will analyse the partitions and the filesystem inside it - so once the bootloader is running it still need access to the underlying device to access that file I don't know what you're saying because there are at least 3 things that can be called "bootloader" here. One is in ROM, one is in the first block of the USB first-level boot device, and one is the complete Linux system that resides on the first-level boot device. The ROM boot loader doesn't know anything about partition tables or filesystems. It knows how to read the first block of a USB storage volume, plugged into a socket/hub/controller permanently married to that ROM. The contents of the USB volume is much like we once put on floppy disks: not "cat kernel >/dev/sdb", but "cat bootstrap loader2 kernel >/dev/sdb". Maybe the volume actually has a partition table and the kernel thus loaded knows how to find filesystems on the volume.
The Extensible Firmware Interface vs early Linux Posted Aug 23, 2011 9:36 UTC (Tue) by etienne (subscriber, #25256) [Link]
> I think you've misunderstood what the ROM bootloader does in this scheme.
> It is intentionally too dumb to choose a boot device.
I wish it worked that way in the real world.
The Extensible Firmware Interface vs early Linux Posted Aug 23, 2011 18:05 UTC (Tue) by giraffedata (subscriber, #1954) [Link] The BIOS should be dumb, but in practice it [isn't]. And in case it wasn't clear, this is exactly the point I opened the thread with, if BIOS means "the code fixed to the motherboard that boots the OS." I would like to see that intelligence moved into a physically changeable, easily creatable storage device and suggest that a Linux system on a USB disk is the best choice for that.
|
|||||||||||||