Slashdot Mirror

This is an ideal application for LinuxBIOS [linuxbios.org]. The article says an average of 14 minutes per flight were spent rebooting computers. Even 36 seconds per reboot is too much, and would be totally unacceptable if it were say, a navigation computer on a 737 with a hundred civilians on-board.

Nasa has an interesting project called FlightLinux [nasa.gov] specifically geared for this sort of application. Unfortunately, they have yet to release code (export restrictions), but they supposedly use LinuxBIOS for their system.

Of course, having software that never crashes (no pun intended) would be best, but it never hurts to have a system that can boot up in just a couple seconds anyway!

This is an ideal application for LinuxBIOS. The article says an average of 14 minutes per flight were spent rebooting computers. Even 36 seconds per reboot is too much, and would be totally unacceptable if it were say, a navigation computer on a 737 with a hundred civilians on-board.

Nasa has an interesting project called FlightLinux specifically geared for this sort of application. Unfortunately, they have yet to release code (export restrictions), but they supposedly use LinuxBIOS for their system.

Of course, having software that never crashes (no pun intended) would be best, but it never hurts to have a system that can boot up in just a couple seconds anyway.

then you'd know about the Open Source Bios along with CPUs, Motherboards and other support stuff

Pink is the largest LinuxBIOS cluster in the world to date. The only moving parts in each node are cooling fans. This translates into a small savings on hardware, but more importantly means the nodes are by design more reliable thanks to fewer moving parts. Each node is powered by two 2.4GHz Xeon processors with four gigs of RAM and Myrinet 2000 interconnects.

The raw hardware power, while impressive, isn't what makes this cluster unique. The kicker is in the software, more specifically Clustermatic 3 featuring LinuxBIOS. Stuff happens and nodes fail, but thanks to LinuxBIOS they can be back up in a matter of seconds, not minutes.

Additional tools for the frontend node from Linux Networx makes updating nodes super-easy. You can flash each node's BIOS with a single command all in a matter of seconds. BProc allows you to run basic shell commands on any node without even installing a distribution on those nodes. w00t!

What we see here is a big shift away from expensive hardware and proprietary software. The software powering this cluster is 100% GPL, so users save a fortune in software licensing costs alone. And while these P4 nodes in particular aren't exactly cheap, they provide pretty darn good power and are far less expensive than Alpha servers. Also, using the x86 architecture means that consumer boards are not far behind in clustering. In fact, you can check out the LinuxBIOS homepage and see some pretty cheap boards that are supported already. So if you have some spare cash lying around and a couple weekends to kill, you can pick up a cheap board + cpu + memory combo and set it up as a slave node for your desktop machine with the same software these guys use to power this huge cluster.

Pink is the largest LinuxBIOS cluster in the world to date. The only moving parts in each node are cooling fans. This translates into a small savings on hardware, but more importantly means the nodes are by design more reliable thanks to fewer moving parts. Each node is powered by two 2.4GHz Xeon processors with four gigs of RAM and Myrinet 2000 interconnects.

The raw hardware power, while impressive, isn't what makes this cluster unique. The kicker is in the software, more specifically Clustermatic 3 featuring LinuxBIOS. Stuff happens and nodes fail, but thanks to LinuxBIOS they can be back up in a matter of seconds, not minutes.

Additional tools for the frontend node from Linux Networx makes updating nodes super-easy. You can flash each node's BIOS with a single command all in a matter of seconds. BProc allows you to run basic shell commands on any node without even installing a distribution on those nodes. w00t!

What we see here is a big shift away from expensive hardware and proprietary software. The software powering this cluster is 100% GPL, so users save a fortune in software licensing costs alone. And while these P4 nodes in particular aren't exactly cheap, they provide pretty darn good power and are far less expensive than Alpha servers. Also, using the x86 architecture means that consumer boards are not far behind in clustering. In fact, you can check out the LinuxBIOS homepage and see some pretty cheap boards that are supported already. So if you have some spare cash lying around and a couple weekends to kill, you can pick up a cheap board + cpu + memory combo and set it up as a slave node for your desktop machine with the same software these guys use to power this huge cluster.

It does a minimal amount of hardware initialization before jumping to the kernel start and lets Linux do the rest. As a result, it is much faster (current record 3 seconds)

So, I wonder when these people will get up to speed and include this "feature".
Perhaps it will call Linus himself for permission to boot?

Linux BIOS Project

According to http://www.linuxbios.org/ you can do anything while booting a machine with a linux bios. You don't really need some trade mark protected stuff from phoenix which you most probably have to pay for decently...

Maybe the same way copyright inspired copyleft, the DMCA is a form for companies to protect their products, and stop other people from profiting on those products (god forbid!), but since this really throws onto the pile, and adds hardware materials in to the copyright bin, maybe it will inspire some hardware enthousiasts to create copylefted hardware?

There's already a couple projects with exactly that in mind:

• OpenBIOS
• MyLinux PLW (Pocket Linux Workstation) (i.e., open Palm-like hardware for running Linux on, which they plan to sell for $20 above cost)
• LinuxBIOS
• The Open Hardware Certification Program
• OpenCores (for open-sourced processor designs)
• and finally a page dedicated to Writings on Open Source Hardware.

It's interesting to note that the OpenBIOS project was a recipient of funding from LinuxFund .

DRM or DRR: Digital Rights "Management" -- should really be called Digital Rights Removal. This is a quote from the article:

Because it gives a new level of control over the hardware, it's also of interest to digital rights management and security designers.

With LinuxBIOS you can also ditch your BIOS. It really only is "easy" to do if you have your BIOS on a EEPROM thats a DIP. You can flash a slimed down version of the Linux kernel into an EEPROM (512KB min) and boot up in a couple seconds.

Provided your motherboard has a 40pin DIP socket for the EEPROM, you can replace it with a DoC (Disk on Chip) and even have a small FS on it.

For a Linux HTPC, this would be perfect. You could have your basic root FS flashed into a DoC and it could boot up to your HTPC gui in just a couple seconds -- completely tollerable by any non-geek.

Also, LinuxBIOS isn't just for x86. There are some Alpha clusters that use LinuxBIOS for their "BIOS".

The only problem with it, is that you can't easily salvage old hardware like your old P1 because usually, the EEPROM is too small.

This is exactly the *point* - a lot of the time, you DON'T need to have something between the hardware and the OS. Look at Linux, or Windows NT, or any other robust 32-bit OS - they don't use BIOS calls, they access the hardware directly. The BIOS in the system I put my first 20 gig drive in couldn't comprehend drives bigger than 8 gigs, so it kept telling me that's what it was - Linux saw it fine though, because it didn't ever *use* the BIOS.

There are two situations I can easily think of, really. First, you're running a modern operating system that works fine, and you just plain don't need a BIOS. You need to initialize all your hardware, but you don't need to be all configuring it and everything, when the OS will dot hat for you. Second, you're debugging new hardware, or teseting it, or installing a new hard drive and don't want to boot to see if it works, or (and this is my favourite) you want to netboot/Firewire boot/USB boot/TCP/IP over avian carrier boot. In this case, you need a boot rom, or an 'advanced BIOS' that supports that stuff, or a boot pigeon, or whatever. With a decent replacement for the BIOS, which could actually have USB drivers or FireWire awareness or a TCP/IP and NE2K stack or pigeon calls loaded up out of firmware, you could easily boot over the network without having to go to the trouble of getting a boot rom and doing a bunch of jerking around to get the system to recognize it. Alternately, for hardware problems or deep hacking, you could boot into the bios shell (OpenFirmware has one of these) and do things like manually reset where it wants to load the OS from (you can do this on Macs to install yaboot).

For people who think this is useless, look at it a few ways. First of all, there is a group that is doing something very similar - namely, the LinuxBIOS people. It's not the same, but it has a lot of the same ideas - replace the bios with something that's actually useful. Second of all, there's already LILO, sure, but LILO doesn't work on all systems, or from other hard drives, or this, or that, or whatever other thousand possibilities (It's always worked for me, but I don't have any esoteric hardware). With a decent preboot setup, you could set it up to boot from any partition on any drive, or firewire, or USB, or avian carrier, or whatever you liked. You could go to a friend's place with your firewire drive and then just pop into the preboot shell and tell it to load firewire support and boot from the firewire drive instead. No installing LILO, no screwing up XP, it'd just work.

--Dan

People are always complaining about "Closed" operating systems but don't bat an eye that their BIOS is closed...

Probably because their favorite OSes don't use the BIOS at all after booting... and don't get rebooted often.

And if your BIOS is still too closed for your tastes, there's always the LinuxBIOS project.

When i am doing a fresh install of WIN2K and REDHAT on my comps (a once-in-6-months exercise) i make sure the machine is not even physically hooked up to the net untill i have a software firewall configured, up and running. I keep the firewall packages on CDs, along with config files, and ONLY AFTER these are setup, i go online to install other things, update drivers, etc (usually, only for win2k, not for redhat, which is trivial to bring back to my customized setup)...

having TCP/IP built into the bios, with no firewalling support, and no possibility of frequent/safe upating, no easy way to check for "being" owned is a very bad idea. Also, Phoenix being a popular bios manufacturer, there will be a lot of worms targetting this bios tcp/ip stack.

I dont see a single genuine advantage of having all this crap in the BIOS anyway. I mean, if u hose ur drive, and need to go online for some critical information/software before u can bring ur comp back up, just keep a KNOPPIX cd handy. I personally think BIOS shud be thinning down even further, given none of the modern OSes really use most of the services, and the BIOS mostly just gets in their way. All the bios shud be capable of, is to bring up the OS, and then let the OS configure everything. It wud be so neat to have the OS kernel setup all the hardware, the powersaving policies, everything when it starts up. Of course, the best is to just have the OS kernel as the bios!! just throw this anachronism completely out. (yeah for ppl whos fav os is not linux, sumthing else might need to be worked out ;) ...

Ghoul

No, you don't always have to trust the firmware. Take a look at the LinuxBIOS project. You can also pressure makers of video cards, network adapters, and other hardware, to open up their firmware.

Open source drivers are nice, but they aren't much of a concession. These days, drivers don't do much more than act as an abstraction layer for the operating system to communicate with the firmware on the hardware. There aren't any nuts-and-bolts of substance to look at in device driver code, just translation. And the card manufacturers know that.

Presumably, the TCPA-specific parts of your new AMIBIOS8 will be intellectual property that your company will guard closely, and if not, working around it to get a LinuxBIOS/OpenBIOS working will surely be a violation of the DMCA. So how will this affect the LinuxBIOS and OpenBIOS projects?

http://www.linuxbios.org

You mean like http://www.linuxbios.org/? ;)

The answer lies in the datasheets. Many RTC chips have more than 128 bytes of NVRAM, and use a bank swapping technique to select the alternate banks. Dallas Semiconductor is one such source, although most new systems have the RTC embedded in one of the main ICs of the chipset or on the super IO chip. Here is one example, the SMC FDC37N958FR, which is used in the Dauphin Orasis v1, an SBC I am experimenting with putting LinuxBIOS on to get around certain limitations. Page 215 is the start of the RTC/NVRAM access. This particular device has 256 bytes of NVRAM, several of which are reserved for the RTC and 8051 scratchpad. Since there is only 256 bytes, there is no bank switching. The DS1251 is an RTC/NVRAM chip with 512KB of static RAM. The little bitch is expensive, too. :-) It uses a banking method where one of the normally user-available registers is now a bank selection register.

I seriously doubt many systems have more than 256 bytes of NVRAM. That is a LOT of space for settings.

Is that old news as it was posted in July on CNET, here which reportedly had 962 nodes and was/is an "Evolocity" cluster.

Is this one for the sister lab(LANL):
A powerful new 2,048-processor, $6 million Linux supercomputer is being built for the Los Alamos National Laboratory to run unclassified analyses and ... (NetworX built it with 959 nodes and 2050 processors) in-addition-to "Pink" named after "Pink"
-or- it it "Pink"
-or- is the post about another one that going to LLNL and has nothing to do with "Pink"?

Is that 2, 3 or 4 this year?

This is getting strange.

Extreme Linux at http://www.extremelinux.org/ seems to have vaporized (behind the LANL firewall, I suppose).

It also seems kind of odd that LinuxBIOS is not mentioned in these articles and is, IMO, a critical part of the builds as well as being an outstandingly innovative use of the Linux kernel.

I think I need a Beowulf cluster to figure this out and tell me ?WHY? LLNL and LANL are suddenly in need of more SC's that are in addition to the ones that they already have. :?)

Strange that the linuxbios link provided above is to a commercial website. Here's the link to the proper linuxbios site, at linuxbios.org.

On a similar note, LinuxBIOS is some sort of ubercompressed, stripped-down linux kernel with some hardware-specific instructions that replaces a conventional BIOS, and then can activate a second-level boot loader like LILO. I don't know motherboard models, so I'm not sure if the project is geared more toward servers. The list of supported motherboards is here.

Even though you'll need spinning media for the storage itself, LinuxBIOS booting Linux either from Disc on Chip, or CF is worth considering. With that, even if a disc fails, at least you'll get a decent diagnostic, and the other discs in the system (if any) will still be usable. The 3 second boot (power on to init running) is also useful in an embedded box.

I'm absolutely amazed at the number of people who cannot spell 'kernel'.

"KERNAL" (with an A) was the name of the BIOS in the Commodore 64 computer. It contained some basic drivers and a BASIC interpreter. Don't ask me what it stood for; I was an Apple ][ user.

"MONITOR" was the name of the BIOS in the Apple ][ computer. It included Applesoft BASIC, some drivers, and a simple machine-level debugger.

ObTopic: "LINUX" is the name of the kernel (with an E) in the GNU/Linux operating system. It is also the name of the BIOS in computers that use LinuxBIOS.

Time to switch my machine BIOS to the Linux BIOS...
I may even hack around my future systems in order to get them bug-free :-)

http://www.linuxbios.org/

Huh. Just overwrite your bios itself with linux. It _will_ report the speed it sees. AMD don't have a hope in hell of stopping it.

What I'd like to see is an EPROM to contain a kernel.

What is it that prevents this sort of thing?

I maintain that OS'es should save as much system state across power-downs as they can, along the lines of APM sleep/wake (or better yet using an OS built out of persistent objects that can boot instantly and page in whatever is needed, on demand). Hell, with that no-POSTing BIOS and APM sleep/wake, you can already do a ten-second power-on without harming any non-volatile memory devices whatsoever. THIS IS NOT ROCKET SURGERY, FFOLKES.

-jhp

Mine boots up at a nice consistent 12 seconds. I'm running a Fic VA 503+ and a POS Cyrix space heater chip (it was cheap). You can gain a little time by sticking the kernel right in the boot sector, but you've gotta strip it down enough to make it fit. Did you turn off all of the BIOS auto-detect crap you could?

You might look into the Linux BIOS project at http://www.linuxbios.org/ as well. I'm sure it's mentioned farther down in teh comments here, but I haven't read that far yet. ;)

Perhaps this link will work better.

You want fast boots? Put the KERNEL in the BIOS. No need to run BIOS code if you don't have to.

I think it may have already been done.
------