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."

Comments

Heroic bird

[david duncan scott]

Moving like a sleek penguin under arctic ice? I'm thinking brave but lost and alone, thousands of miles from his home at the Antipodes, almost certain to starve...is there anything we can do to help? A walkathon? A benefit concert? A herring?

Not Boot to Windows

[ecliptik]

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...

BIOSes should not be operating system-specific.

[Brett Glass]

It is no better to be locked into running Linux on a machine than to be locked into running Windows. The BIOS should be a generic facility that can load any desired operating system.

Re:BIOSes should not be operating system-specific.

[DGolden]

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.

Re:BIOSes should not be operating system-specific.

[Wesley Felter]

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).

Intel is pushing a new BIOS standard called EFI (Extensible Firmware Interface?); it's not really clear why they're not just using Open Firmware except maybe the conspiracy theory you mentioned.

Re:BIOSes should not be operating system-specific.

[Wesley Felter]

No one's locking anyone into Linux. People who use LinuxBIOS know what they're getting into.

Re:BIOSes should not be operating system-specific.

[sjames]

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.

Re:BIOSes should not be operating system-specific.

[DGolden]

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.

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 /. :-(( ), 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.

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.

Re:BIOSes should not be operating system-specific.

[jquirke]

As a side note, it doesn't look like it would be all that hard to get *BSD or The HURD booting from LinuxBIOS

Just want to point out the differences in the BSD and Linux booting process.

Linux has a 16-bit slab of code that does all the BIOS calls in arch/i386/boot/setup.s. This code works out the memory requirements (does the E820 map), gets any paramaters about any hard disks, APM,etc. Some of the information it finds out may or may not be used. Then it does the protected mode setup (GDT, IDT, etc) and jumps into the protected mode code (head.S)

BSD on the otherhand pretty much is entered already in protected mode, and obtains this information by spawning a V86 (Virtual 8086 mode) task that performs any BIOS calls.

I'm not sure if that has any bearing on being able to boot from LinuxBIOS, just wanted to point it out.

Not generally useful..

[A Commentor]

Looks like the supported Chipsets are quite limited. And I could find no information on their site about extra hardware that is typically included on the motherboard.

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.

Re:Not generally useful..

[A Commentor]

One objective is to NOT support any extra hardware.

So with my board's original BIOS, the SCSI BIOS comes up after the regular BIOS. This allows configuring of the controller, each device, low-level disk formating, etc. So will the SCSI BIOS still be displayed on boot-up? If not, I would have lost alot of functionality by using the LinuxBIOS.

What LinuxBIOS is NOT

[CatherineCornelius]

The importance of this Linux BIOS project is not that it provides a way of doctoring motherboards so that they will not load Windows (and in any case, such an effort could hardly pose any commercial threat to Microsoft).

Nor is it that the BIOS is free software--there are other open source BIOS projects that can perform a DOS/Windows boot.

It isn't even that LinuxBIOS is suitable for embedded systems--other free BIOS's will support embedded systems and can perform a DOS/Windows boot.

In any case, there's nothing to stop someone writing a DOS/Windows boot loader and booting it from LinuxBIOS.

The point, surely, is that "LinuxBIOS generally weighs in under 64KB and doesn't waste ROM space with unnecessary functionality. Because it isn't a legacy design, LinuxBIOS starts up fast, even without code optimization."

It really just provides a nice slimmed down boot cycle suitable for embedded systems that do not require the PC BIOS baggage. We're not even talking about manufacturers dropping DOS/Windows compatibility, simply one or two equipment providers considering using LinuxBIOS in situations where compatibility is unnecessary and speed to boot is an important factor.

Arctic Penguins?

[Anonymous Coward]

Well, if it's "moving like a sleek penguin under arctic ice", it isn't going anywhere, there are no penguins in the Arctic, they are all Antarctic residents. :)

Reminds me of my ? to RMS about a free BIOS

[weave]

I attended a talk by RMS at H2K. He mentioned how he doesn't use any software that isn't free. I asked him if the BIOS code that boots his computer was free (as in speech).

He said it was a good question. His position on it is if it's flashable and programmable, source should be free.

He kind of dodged the question about whether or not his computer BIOS was flashable, free, whatever...

Don't get me wrong, unlike most people, I have a lot of respect for the guy and I don't believe for a second Linux or Open Source would be where it is today without the efforts of him and his team. It's just that there are always little contradictions that trip up even the best of zealots. Like, I wonder if his life is in danger, will he approve of being hooked up to a computer that provides life support but is running non-free software! :-)

Re:Reminds me of my ? to RMS about a free BIOS

[Scooby Snacks]

If his life is in danger and a medical team chooses to hook him up to one of their systems that runs commercial software, then RMS isn't the guy using it, is he?

Even if he requested to be put on life support, this wouldn't be a contradiction. (More in a moment.)

If you can't find a free BIOS replacement for your motherboard, do you really think it's logical to go on a rampage and refuse to boot up that machine ever again, until it can be replaced with an open-source BIOS? I think not. A reasonable individual would say "Well, either I care enough about this to develop my own BIOS - or I don't."

Actually, how do you think the GNU project started? They didn't toggle front-panel switches to write their first programs. There is a history of the GNU project which has a section which explains this:

Donated computers

As the GNU project's reputation grew, people began offering to donate machines running UNIX to the project. These were very useful, because the easiest way to develop components of GNU was to do it on a UNIX system, and replace the components of that system one by one. But they raised an ethical issue: whether it was right for us to have a copy of UNIX at all.

UNIX was (and is) proprietary software, and the GNU project's philosophy said that we should not use proprietary software. But, applying the same reasoning that leads to the conclusion that violence in self defense is justified, I concluded that it was legitimate to use a proprietary package when that was crucial for developing free replacement that would help others stop using the proprietary package.

But, even if this was a justifiable evil, it was still an evil. Today we no longer have any copies of Unix, because we have replaced them with free operating systems. If we could not replace a machine's operating system with a free one, we replaced the machine instead.

Re:Windows-only BIOS unlikely

[zulux]

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.

Karma Whoring:

[brad3378]

I'm surprised nobody posted this link yet:

The Linux Bios Homepage

Re:and the bios is for what, exactly?

[TandyMasterControl]

Typical, when they're not decrying Microsoft for embracing and extending, they themselves are embracing and debilitating. ..
Anyway, why an embedded device would want to use x86 hardware is beyond me...

because it's incredibly cheap maybe, with a mind boggling array of useful peripheral hardwares?

The aim of LinuxBIOS doesn't even remotely touch on some competitive manuevering as you ignorantly suggest.
Installing a LinuxBIOS ROM in place of normal DOS compatible microcode is something you do to modify I>commodity off the shelf hardware hardware to -for example- make your appliance system boot Linux to multiuser + network runlevel from a cold start in 3 seconds or less. It is a very specialized aftermarket improvement for hardware integrators - not motherboard OEMs or PC sellers- and has nothing whatever to do with the kinds of exclusionary practices Microsoft is famous for. It is not practical for general use PC system design, since kernel upgrades mean plugging in a new ROM or reprogramming the old one in a special ROM burner. It is for dedicated appliances only.

In short, Anonymous Coward, if you can't comment intelligently, and without smallminded paranoia, you may want to forgo commenting at all.

What should be in the ROM

[tsprad]

1. Initialize all the programmable chips so the board can come up and run.

2. A quick self-test to make sure that everything looks like it's basically working.

3. Offer the option of a more extensive self-test to provide some assurance that weird behavior is not a hardware problem.

4. Load a bootstrap loader from *any* I/O device on the board that might be practical. If the board has an Ethernet interface, it must be able to boot from that. If not, then perhaps from a serial port. This is for initial system installation. Normally you'd boot from the disc controller, of course.

5. Not require any equipment that's not permanently attached to the motherboard, i.e., if you don't know you've got a keyboard and a local video display, then use the Ethernet (preferably) or a serial port for operator control. Load the loader unattended if there's no operator present.

6. A remote reset sure would be nice if you could make sure you could keep it out of the hands of the jokers.

With all that and a 100Mbit Ethernet, the admin could reinstall the officially-approved software on the luser's workstation in a few minutes, without getting out of his own chair, and without having to walk the luser through any complicated procedure like finding the reset button and pressing it, let alone finding some special floppy or CD. And not just luser's workstations, servers, too. once the power and the Ethernet are plugged in you'd never have to turn the lights on in the server room again.