Slashdot Mirror
LinuxBIOS Gains Steam
solferino writes: "LinuxJournal has a good overview article about linuxBIOS and where it's currently at (hint : moving like a sleek penguin under arctic ice). Why linuxBIOS? To quote from the article "Currently two different interest groups are working on LinuxBIOS: one working on embedded systems and one building large-scale computer clusters. For these applications the legacy x86 firmware is suboptimal." Yes, this was a slashdot story in March this year but this article is relevant for updating the project status and for providing indepth information."
As LinuxBIOS currently does not provide a compatibility layer for booting other operating systems besides Linux (notably Windows)...
If OpenSource has a project like this and the comptability is never included, I don't even want to think about what MS could retaliate with...
Bootstrapping? Anything else?
Typical, when they're not decrying Microsoft for embracing and extending, they themselves are embracing and debilitating.
Even Compaq, today's best known advanced technology destroyer, managed to make a *faithful* copy of the IBM PC BIOS.
Anyway, why an embedded device would want to use x86 hardware is beyond me...
For example I've got a 440LX motherboard with Adaptec SCSI built-in. The 440LX is not supported and there was absolutely no information about the SCSI. It seems like all the new motherboards include RAID controllers... I found no information about these either..
So for the markets they mentioned(embedded, and clusters), this is useful... but I don't see normal users needing this.
Looking for any old 8-bit Heathkit/Zenith software/hardware - http://heathkit.garlanger.com
I quite like OpenFirmware, but have yet to see a x86 PC motherboard which uses it - PPC ones do, of course. The specification standard includes support for x86 computers, but the mobo manufacturers have deals with the BIOS producers (if they're not already the same company), and the BIOS producers have deals with MS, which means they've had financial incentives for years for keeping the BIOS in the dark ages of DOS.
Most current BIOSes are extremely biased toward DOS and DOS-derivatives like windows 95 - they're pretty ill suited to even Windows 2000, I'm sure microsoft now would prefer them to be replaced too (but with something that still ties you to MS, of course - no doubt MS will be prodding at x86 BIOS manufacturers to get this).
At the same time, perhaps what's needed is a open standard for the provision of a wodge of on-mobo flash-ram - the main reason people want to replace the BIOS with linux, so that the OS loads in a blink of an eye, perhaps without even requiring a HD. It's just silly that the BIOS spends a good while screwing around in Real Mode when Linux (or newer versions of Windows!) just go back and do all the setup again...
I thik it's be REALLY nice to have an OpenFirmware-type BIOS on x86, but with a few megs of flash on the motherboard that one could load the OS kernel and perhaps an initrd from, instead of having to mess about with the harddrive.
Choice of masters is not freedom.
Microsoft has said on many occasions that they have no plans to release a keyboard for the Xbox
Microsoft has also said at each release of Windows, that "this one is reeeeaaaaally stable now." I woulden't place too much faith in what they say, after all they are a corporate criminal in the eyes of the US justice system.
Moneyed corporations, non-working 'poor' and criminal prisoners are turning productive citizens into tax-slaves.
Can LinuxBIOS be made to boot other operating systems as well? I'd really like to boot BeOS (to the desktop, all services started) in 5 seconds flat. Right now the BIOS takes up the majority of the boot time.
The BIOS should be a generic facility that can load any desired operating system.
That is a desirable goal. Linux was chosen first because that was what the developer needed (meeting personal or professional need is the start of most Free software projects). Secondly, Windows is much more difficult since it is quite dependant on the legacy BIOS calls at startup while Linux is not.
The upshot is that if you can load the linux image into ram and jump to it, it will boot. With windows, you'd have to re-implement a good bit of the original BIOS.
Currently, LinuxBIOS just needs an ELF formatted binary image to load and execute. If you'd care to write a second stage that implements all of the necessary BIOS calls and boots Windows, feel free. There are a few people on the developer's list that would love to see that.
As a side note, it doesn't look like it would be all that hard to get *BSD or The HURD booting from LinuxBIOS.
Grr... got the 1.02 EFI specification from Intel, it doesn't look like a technologically particularly bad way of doing things or anything, especially given that it's all quite logical and neat, despite the fact they're still trying for a degree of backward-compatibility (which is all parcelled off into its own little section, thankfully) - it's just an easily followed tree of c structures - it's a definite improvement on PC-AT BIOSes, but it's pretty much intel-architecture-specific, of course.
/. :-(( ), and it definitely doesn't have the cool forthy hackability of OpenFirmware. ;-) It's still a much better match than the legacy BIOS to modern 32/64-bit OSes though.
OF's forth-bytecode intended to act as cross-platform on-card boot-time init and bare-bones device drivers and so on is replaced by in-rom snippets of "PE32+" 32/64-bit IA code, etc., etc.
It's well-defined support for reading boot-time image files from FAT filesystems, and net-booting, should make the boot process a lot less painful for Microsoft OSes, and a bit less painful for Linux - actually, I presume the Linux-Itanium project's already got this sorted.
It's certainly well-suited for integration with Microsoft OSes (certain aspects, like the Vendor Device Path look tailor-made for their end-to-end "DRM OS" recently mentioned on
All that said, I think one could, in theory, have a BIOS that was largely x86 EFI and Open Firmware compliant at the same time, if a designer really put his mind to it - one could probably write an EFI-compliant implementation in a mixture of forth and asm in the first place, and have it call legacy x86 PC ("PCI ROM type 0"), Open Firmware ("PCI ROM type 1") or EFI ("Proposed PCI ROM type 3") boot code segments on the PCI cards as it saw fit! The "Firmware Boot Manager" that EFI eventually drops into could be a full forth console, for all intel care, by my reading of the spec, and producing the EFI/ACPI device tree from the Open Firmware tree or vice-versa would just be a "simple" transform, I suppose.
I very, very much doubt anyone will bother doing this, though, unless Apple paid them a very large bung to encourage the proliferation of OpenFirmware-compliant devices...
So the fix is in already, as usual. Obviously, they've wheel-reinvented, presumably because OF is (was (afaik it's lapsed, like Scheme)) an IEEE standard they didn't control.
Choice of masters is not freedom.
It seems to me that any independant effort would be wasted writing a new BIOS-like system. My I suggest implementing IEEE Standard 1275-1994 (aka OpenBOOT). Works on Suns, and Macs, it should work for PCs too!
cfs