Since the first IBM PC, the hardware architecture of the boot ROM has evolved considerably, so that today virtually every machine has a BIOS that can be upgraded in the field or recovered from a failed upgrade. The common technique to accomplish this is to have a socketed Flash ROM on the motherboard. The Flash chip allows software to update it while the socket allows replacement of the chip if the update somehow fails. With this type of hardware architecture, developing custom boot firmware is now possible. For production machines, you can update firmware with no special hardware, and during development you can recover if something goes wrong.
A downside to current PC hardware architectures is that normally boot ROMs, at 256KB, are too small. This is enough space for firmware, but it isn't large enough for the Linux kernel.
The Linux kernel can run from LinuxBIOS as well as it does from a standard PCBIOS, when the port is done correctly. To date I successfully have ported LinuxBIOS to three motherboards. On the latest board, the results of booting Linux from LinuxBIOS and the PCBIOS are indistinguishable. So while there are significant technical hurdles in porting LinuxBIOS to new platforms, these can be and have been overcome.
Having access to adequate documentation is a nontechnical factor to consider. Convincing hardware vendors to support LinuxBIOS, or to release the documentation for someone else to code it, has met limited success to date. Missing or limited vendor support is not a new issue for free software, and it has been overcome in the past—now is not the point in the game to be discouraged. It is worth remembering that without these kinds of efforts there would be no new hardware on which we could run free software.
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.
LinuxBIOS has a lot to recommend itself for embedded applications. As it is released under the GPL, LinuxBIOS is royalty-free. 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.
In August 2001, General Software announced a 0.8-second boot to LILO on an embedded board after a hardware reset. This is a reasonable amount of time to do the job, but under LinuxBIOS such impressive results are routine. I can load the kernel over the network from a cold power-on in two seconds flat on a dual-processor server board—without optimizing LinuxBIOS.
The small footprint of LinuxBIOS has impressed SiS enough that they have devoted a developer to port LinuxBIOS to their chipsets, aiming at embedded applications. This demonstrates one well-supported platform.
For computer clusters, which is what Linux NetworX specializes in, LinuxBIOS has a lot to recommend itself as well. The serial port is the native console, so you don't need video hardware. Serial connections can be redirected easily into a terminal server for remote console access. The early setup of the serial console also brings benefits. For example, LinuxBIOS can report all errors and hardware failures over the serial console. A normal BIOS, even with serial console extensions, will initialize the serial port too late in the game for some failures to be detected, and it will usually fail if the CMOS is cleared.
LinuxBIOS also supports network booting on most hardware platforms, allowing changes to boot options to be made simply by altering a setting on a DHCP server. Since the code is open source, if the network booting policy is not to your liking it can be changed. The fast booting of LinuxBIOS means that if you are debugging something and have to reboot a node, the hardware doesn't waste the valuable time of the system administrator.
The openness of LinuxBIOS and its focus on Linux allow it to be configured and managed from user space under the Linux kernel. Anything done from user space also can be set up to be done remotely. This is a great advantage in homogeneous clusters, allowing firmware changes to be made and managed globally instead of one node at a time.
With large numbers of machines, the probability of hardware failure is much larger than for a single machine. The reduced hardware requirements of LinuxBIOS—such as unneeded floppy drives, CD-ROMs or hard drives to boot from, and no need for a video card and keyboard to control the system—can lead to a less expensive and more reliable system. Fewer hardware components lead to a reduced risk of hardware failures.
For clusters, LinuxBIOS also brings the potential to plug in to the cluster and, with nothing more than the firmware running, have a machine that acts as a single system, instead of a rack that looks like a collection of nodes.
Getting Started with DevOps - Including New Data on IT Performance from Puppet Labs 2015 State of DevOps Report
August 27, 2015
12:00 PM CDT
DevOps represents a profound change from the way most IT departments have traditionally worked: from siloed teams and high-anxiety releases to everyone collaborating on uneventful and more frequent releases of higher-quality code. It doesn't matter how large or small an organization is, or even whether it's historically slow moving or risk averse — there are ways to adopt DevOps sanely, and get measurable results in just weeks.
Free to Linux Journal readers.Register Now!
- Hacking a Safe with Bash
- Django Models and Migrations
- Secure Server Deployments in Hostile Territory, Part II
- The Controversy Behind Canonical's Intellectual Property Policy
- Home Automation with Raspberry Pi
- Huge Package Overhaul for Debian and Ubuntu
- Shashlik - a Tasty New Android Simulator
- Embed Linux in Monitoring and Control Systems
- KDE Reveals Plasma Mobile
- diff -u: What's New in Kernel Development