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."
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.
>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
This.
Linux supports the ACPI spec to the letter - if you have a properly ACPI-compliant BIOS, newish linux 2.4 kernels will support it perfectly.
The problem is most BIOS/mobo combinations, particularly the ones in laptops, have buggy or subset ACPI implementations that are just enough to work with Windows 95/98. Windows XP will have similar difficulties to Linux with those motherboards, which are unfortunately the large majority of laptops greater than 6 months old on the market, and most of the cheapest ones available today. In fact, come to think of it, certain laptops won't even work with version of w95/98 other than the particular, and very carefully patched and tuned, "mobile edition" they shipped with. Sony used to be the worst for this, don't know if that's still the situation.
This isn't meant for home use. If you'll notice the target audience it's embedded devices and large clusters.
I work on large beowulf clusters and there are many advantages to using a linux kernel to boot the machines, and none of them are the fact that you can't boot windows.
Linux boots faster and is able to tell you if something failed, and what it was, and can actually continue past some problems so you're not totally sunk if something dies. You can also redirect the output to a COM port, which is *great* for headless nodes. That way you can see that "oh, I had a stick of memory go out" without making the trip to the server room and pulling out the node and starting a whole troubleshooting series on it.
Not everything relevant to Linux is involved in the Linux/MS holy war. This is about optimizing clusters for speed and ease of management. The fact that windows isn't supported is a side effect of the technology, not an attack on "The Enemy". It's not that the BIOS intentionally prohibits you from using windows, it's that the BIOS *is* a linux kernel.
I'm surprised nobody posted this link yet:
The Linux Bios Homepage
--
Runnin' around, robbin' banks all whacked on the Scooby Snacks...
The PC world is slowly moving past the brain-damaged 15 IRQs - currently Intel x86 SMP machines don't have that limitation, in theory (though they can and do emulate it for (ass-)backward compatibility), since they all have IO-APIC* hardware, making most of the rest of the 255 IRQs that the x86 architecture supports available to motherboard hardware, rather than as merely software interrupts.
Some higher-end Intel x86 single-processor motherboards also have APIC support, but it's not enabled usually, since most Windows versions fail to take advantage of it - however Linux 2.4.x will support APICs on both single and multiprocessor x86 systems, if you use the kernel config option "enable APIC on Uniprocessor systems". It doesn't usually do any harm to do so, since it will silently fall back to PIC IRQs if it doesn't find an APIC.
I presume AMD have similar APIC stuff for SMP Athlons, though I've never looked into it.
*APIC = "advanced programmable interrupt controller", as opposed to the cruddy, crappy 15-IRQ PIC (which is actually 2 even more ancient 7-IRQ PICs kludged together) that PCs have been stuck with since last century. These days, the APIC is actually on-die on SMP-capable Intel chips.
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.