Slashdot Mirror

A couple of things that have changed, from the top of my head:

  - Those old machines had an OS dedicated to support exactly the hardware that was shipped. OTOH, Linux distros are usually generic, and detect hardware on boot.

  - There's a huge difference between a BASIC interpreter and a full-fledged multi-user OS with networking, GUI, etc.

  - PC hardware spends a lot of time during boot before actually handing control to the software. Server hardware is often a lot worse.

  - The code involved in booting those old machines was probably written by Real Programmers, who knew the ins and outs of the hardware they were programming for. It's probably horrible to maintain, but ridiculously fast. By contrast, most of the code involved in booting your Linux distro is written in a variety of languages, by a whole lot of people, few of whom are Real Programmers, and it's probably optimized for genericity and maintainability, rather than efficiency.

Having said all that, you _can_ boot Linux ridiculously fast. I used to have a 486 where the boot process basically consisted of (1) POST (2) Load GRUB (3) Load kernel (4) Run init (5) Run login. Pretty much a normal boot process. What was special about it is that the kernel had all required modules compiled in, and nothing else. init (IIRC) only spawned a single tty and ran login. And both init and login were BusyBox statically linked against dietlibc. From GRUB to login prompt took less than 5 seconds, IIRC. You could further improve on this by foregoing the BIOS in favor of something like coreboot.

For additional extra credit, google for the following:

Walmart/Everex GPC TC2502 (VIA CN700 + VT8237R Chipset), PC2500E

Or just check the LinuxBIOS Mailing List thread about this very board, which is available from ClubIT.com for about $60.00 with free shipping.

You mean like LinuxBIOS? Boots to a Linux console in 3 seconds.

Seriously though, it really is old technology.
http://www.linuxbios.org/

BTW, a few weeks ago, I read an article about some MoBo manufacturers considering adding 512MB-2GB of flash memory to boot an embedded Linux desktop from the BIOS for disk-less web-browsing and other stuff...

Considering? Done! In stock!

a BIOS with embedded Linux does not seem that far-fetched, we only need 1GB firmware hubs to plug into Intel's chipsets and hope we will not need to flash our 1GB BIOS too often.

People have been replacing the traditional BIOS with Linux for about eight years now, so yeah, I would say it's feasible. :) Would make more sense to just embed a flash drive for the userspace filesystem and just put the bootstrap and kernel in the firmware proper.

Appropriately geeked by the prospect of LinuxBIOS and OpenBIOS, I recently picked up the first AM2 desktop mobo supported by LinuxBIOS, the Gigabyte M57SLI-S4. Now the MSI K9N-Neo has been added, and I hope to see more recent sockets & chipsets on the supported mobos.

http://linuxbios.org/index.php/Supported_Motherboards

I thought I'd done my homework, too, but wasn't as thorough as required. Replacing proprietary BIOS with LinuxBIOS is more than simply flashing the BIOS.

The Gigabyte M57SLI-S4 has one of two types of BIOS chips, determined by the revision. I was unable to get the revision type from my vendor before purchase, and wound up with the more difficult (and more recent) version. While this motherboard has the space for an additional BIOS chip, both revisions require hardware modification of the sort that includes soldering either a socket (if you're lucky and got the 'easy' revision) or a chip onto your motherboard (among other things.)

I'm very excited at the future possibilities for LinuxBIOS and OpenBIOS. But in reality, at this point and on this mobo, LinuxBIOS on the desktop requires precision soldering. While I'm not adverse to developing this skill, getting a LinuxBIOS desktop will take more time (and hardware) than I initially realized.

>>I might try it if someone had it running on the exact same hardware, down to part #'s for the ram.

Fortunately, you don't need exact matching hardware to recover from a botched BIOS update if you have a socketed BIOS chip. The flash memory your BIOS is stored on can be easily removed, placed in someone else's computer with a compatible socket (It can be a whole different architecture, even), and reprogrammed with the vendor's BIOS using Linux+Windows compatible utilities such as Flashrom ( http://linuxbios.org/Flashrom ), vendor-provided flash utilities which usually run in DOS, or through Linux MTD. There are even services set up to do it for you ( http://www.badflash.com/ ) if you don't have access to another mainboard with a compatible socket.

Unfortunately, BIOS upgrades can become necessary after purchasing a machine if only to support more advanced CPUs (Remember the transition to dual-core CPUs?), to get power management right, etc. The lesson: If you're worried about BIOS updates, buy a motherboard with a socketed BIOS.

Sorry, but I think you are a bit optimistic here. I recommend that you have a look at some of the videos of people on youtube that boot xp on ramdrives. You should also notice another great lag. Hint: the time spent from pushing the power button to booting the OS. http://linuxbios.org/ could fix this.

Linspire (back in the day - I've been on Ubuntu for quite a while now) worked this way. IIRC you had to hold down a key to rescan for hardware, otherwise it assumed nothing changed and booted very briskly. I'm surprised it didn't catch on with more popular distros.

Also, I thought http://www.linuxbios.org/Welcome_to_LinuxBIOS would get through POST and to the payload in just a couple of seconds.

Never heard of this? LinuxBIOS

If you're going to say that hardware isn't open, that's solvable as well.

They're called errata. The most recent bunch are more plentiful than usual but it's not unheard of. Get your microcode updates, whichever vendor you get your chip from. AMD calls them BIOS updates which partly makes sense since you usually patch the BIOS at the same time. You get them from the OEM of your motherboard or system usually but as you see from those links operating system vendors can put them out too. The errata that have been in the press lately are unlikely to affect chips you buy right now because new chips and systems will almost certainly have their BIOS and microcode updated from those issues before they ship.

No computer is future proof. You can get some extra months on one by buying above average, but the best desktop you can get today will still look sad in three years. Pay extra for bleeding edge if you want to but the best value is middle of the road and frequent upgrades.

Another Gigabyte motherboard (Gigabyte M57SLI-S4) does run LinuxBIOS, and is one of the only desktop motherboards to do so. It would be cool if the most performat desktop motherboard in existense also ran a 100% Free/Open Source BIOS such as LinuxBIOS.

Another Gigabyte motherboard (Gigabyte M57SLI-S4) does run LinuxBIOS, and is one of the only desktop motherboards to do so. It would be cool if the most performat desktop motherboard in existense also ran a 100% Free/Open Source BIOS such as LinuxBIOS.

One of the key requirements for the OLPC is that all the components are open source (even the firmware for the wireless component). AMD has worked very hard to make the OLPC compatible with LinuxBIOS and OpenFirmware, which are 100% Free/Open Source. I certainly hope Intel will do the same.

are the affordable (not necessarily 'cheap') laptops, using LinuxBIOS to boot minimal X (in under 10 seconds) that can login over the network, using no local hard drive or flash drive (of course you can always add those), with CPU's that don't run hot enough to cook your sperm, with a battery life actually measured in days instead of pitiful hours?

They could make linuxBios chainload ADLO. It is not complete, but implements enough BIOS calls to boot Win2k.

For desktop systems an optimised boot process isn't much of an issue but for embedded systems it is critical. You don't want a client asking "Why does it take a minute for my VoIP server to reboot?" "Why does my multimedia player take two minutes before I can watch a movie?" These people can't sit at a console and watch all the pretty boot messages scroll by. All they can do is sit and wait and get annoyed because their system hasn't come back up yet. Articles like this are interesting reading for anyone wanting to squeeze every last second out of the boot time of their embedded linux device.

Another big contributor to boot times that the article didn't cover is the amount of time spent sitting in the BIOS. If you're serious about shaving off a few more seconds you might also want to look at http://linuxbios.org/.

{{ You have the source code for your BIOS? }}

http://linuxbios.org/Welcome_to_LinuxBIOS

FreeBIOS has become LinuxBIOS.

But nobody cares about that. What we really want to know is: does it run DOS?

LinuxBIOS of course! http://linuxbios.org/index.php/Main_Page

According to http://kvm.sourceforge.net/faq.html is will support VMWare images and it does run win32.

Now turn that kernel into a BIOS http://linuxbios.org/Welcome_to_LinuxBIOS and you will be able to use the same images for all your machines.

There's always Linux BIOS. It doesn't go through all the long processes the 2 commercial BIOSes do, so it boots faster. Unfortunately, it's only available for a limited number of mobos, but the list is growing quickly.

http://linuxbios.org/

I'm suprised that no one has mentioned the Linux BIOS Project yet.

From the page:

• 100% Free Software BIOS (GPL)
• No royalties or license fees!
• Fast boot times (3 seconds from power-on to Linux console)
• Avoids the need for a slow, buggy, proprietary BIOS
• Runs in 32-Bit protected mode almost from the start
• Written in C, contains virtually no assembly code

I think you are perhaps using the wrong OS. If you want a linux console within 3 seconds of power on, use this:

http://linuxbios.org/index.php/Main_Page

The truth is, this subject is an old one. The main answer is that it just takes time to get a DHCP lease, set up a few dozen services, and generally get all of the "junk" you need up and working without crashing the system. If your main complaint is Windows XP there are a few tuning guides that can reduce your boot time dramatically.

As of a few weeks ago, the OLPC project isn't using LinuxBIOS anymore, they have moved to OpenFirmware from Sun, which was recently open sourced. Sorry to burst the bubble.

That's incorrect. The OLPC project is still using LinuxBIOS to boot the machine, but they are using OpenFirmware as a payload. I have seen both OpenFirmware and a linux kernel payload demonstrated on the OLPC revA developer boards. They chose OpenFirmware because it can fit in a smaller ROM chip.

If you don't understand what that means, just read up on things at http://linuxbios.org/

LinuxBIOS supports several different types of payloads: Linux, Open Firmware, Etherboot, etc. If you are using a Linux kernel payload, then you probably don't want to be upgrading it often. In that case, you can set up the first kernel to kexec a second kernel (before kexec, there was a patch called the two kernel monte).

AMD64's 64-bit mode is definitely supported.

It's not trivial (yet) to boot a version of MS Windows with LinuxBIOS, but using Linux as a BIOS can give all sorts of benefits. One very interesting capability for people running beowulf clusters is that you can boot over any network device that Linux supports (e.g. Myrinet or Infiniband). That may not mean anything to a regular home user, but the point is that you have a whole lot more flexibility in what you can do. Even if you don't want to make it boot your home system over your wireless LAN, it does increase your freedom and it prevents people from nibbling away at the freedom you already have.

I would say freedom from future DRM really is the biggest incentive for trying out LinuxBIOS at home. You can avoid Intel's EFI standard (they're pushing for it to be on all desktops and servers), which will enable companies to inflict DRM on you. Linus has made some very good points about why EFI is not good. One way to look at EFI is that it is basically an OS, and not a very good one.

There are several white papers and tutorials that do a good job of explaining how LinuxBIOS works. Look at the LinuxBIOS documentation section.

Try starting with the Products page at LinuxBIOS.

LinuxBIOS is not compatible with legacy DOS-based PC operating systems

If its fuctory BIOS is replaced with LinuxBIOS http://www.linuxbios.org/ then it is able to boot into Linux.

Does your computer have an open source BIOS ?

Mine doesn't, but some other computers run LinuxBIOS, including the laptop computers that will be distributed to children in developing countries.

Um...

http://www.linuxbios.org/
http://www.openbios.org/

Not sure how well either of these will work for you, but you could try LinuxBIOS and/or InitNG. Either of these alone should speed up your boot time, both together could make it near instant.

...and that's what projects like LinuxBIOS and The Open Graphics Project are for!

LinuxBIOS ( http://www.linuxbios.org/ ) has good support for recent AMD-based boards. I don't think there is a similar free VGA BIOS project, though.

Maybe the solution is linuxbios?. Presumably this would prevent any vector for a virus to take over the bios except a compromised kernel or physical access to the hardware.

Yeah, but is it hardened against me booting BartPE and reflashing the BIOS with this?

Hastening the launch date by a couple of weeks isn't too significant, but AMD certainly deserves to be congratulated for (apparently) leaving DRM out of their AM2 microprocessors. In contrast, Intel has succumbed to RIAA/MPAA pressure and betrayed their customers by stuffing Treacherous Computing down their throats.

I'm also happy to see that AMD has not put DRM into its AMD Live! technology, which competes with Intel's DRM-ridden Viiv. I'm sure AMD is taking a lot of heat from the entertainment cartel for not handcuffing users, and I hope they'll continue to keep their products DRM-free.

And let's not forget that AMD has been supportive of LinuxBIOS by actively ensuring that their motherboards can run it.

Another noteworthy thing about this project is that it's going to be based on entirely free software. Free as in beer, and free as in speech, right down to the BIOS (LinuxBIOS in this case). And seeing how LinuxBIOS + GNU/Linux breaks their dreams of controlling everyone's machine via "Trusted Computing" (Or whatever they're calling it these days) I doubt Intel and Microsoft are very fond of the deployment of this machine on a grand scale. Their own greed has caused them to be cut out of the picture like a cancer.

OLPC is on the virge of doing what the fossils in these companies and in governments have only been able to talk about for the past several years--Bridge the digital divide. I'll bet the FSF people are happy they can now have their 100% free software+firmware laptop, though maybe not in the form they were expecting it ;-)

My thoughts too. There is a Linux BIOS project. Could something be written that makes EFI boot into a Linux BIOS which then allows Vista to be booted?

That would be the biggest boot salad ever seen!

I mean, Real ROM -> EFI -> rEFIt -> eLILO -> Linux BIOS -> Vista!!!

You state that users want a BIOS.

That is not true. Users do not want a BIOS, they do not even
want an operating system.
They only want functionality and productivity.

Therefore, I do not see any point in having a flashable BIOS at
all. A BIOS should be smart enough to initialize all the hardware
that is necessary to boot the operating system. After this step,
the OS should take over.

Actually, most operating systems hardly need any BIOS functionality.
LinuxBios http://www.linuxbios.org/ can even replace most BIOSes.

Not currently. I've looked at LinuxBIOS, at http://www.linuxbios.org/, and the way they seem to be protected right now is through massive fragementation and extremely poor documentation of the BIOS editing facilities. There really is no fundamental defense in place against editing the BIOS, since Microsoft's operating systems sometimes do it as part of their normal system manipulations. The result is amazing contortions that software vendors do to get things set just the right way for their particular requirements.

Microsoft and their friends are actually looking at this with their "Trusted Computing" tool, formerly called "Palladium". The danger of Palladium is that it can be used to lock out non-Microsoft-signed boot loaders or hardware drivers that the user may actually want to use, especially the master-boot-record or MBR. That can directly prevent the use of non-Microsoft-signed operating systems by any means whatsoever on PC hardware.

yeah nowadays they have up to 4 MB flashable BIOS that run linux http://www.linuxbios.org/index.php/Main_Page.

"when i was a kid, to set the CPU clock we had to manually insert jumpers, And we Loved it!"

Someone in the LinuxBIOS project wanted to be able to boot other OS's, but needed BIOS emulation.

Bochs already had a BIOS written, but needed a wrapper layer. Such a wrapper now exists and is called ALDO, and is part of the LinuxBIOS V1 source tree. From what is mentioned, it's not in V2 simply because no one wants it currently.

From what I can gather, ALDO is actually just an ELF executable, so it's quite possible that EFI could load it off disk - Viola, you've got a BIOS.

The Security Enhanced Bootloader for Operating Systems - Phase 2 page covers detail on how it all works (not a detailed explanation).

Someone in the LinuxBIOS project wanted to be able to boot other OS's, but needed BIOS emulation.

Bochs already had a BIOS written, but needed a wrapper layer. Such a wrapper now exists and is called ALDO, and is part of the LinuxBIOS V1 source tree. From what is mentioned, it's not in V2 simply because no one wants it currently.

From what I can gather, ALDO is actually just an ELF executable, so it's quite possible that EFI could load it off disk - Viola, you've got a BIOS.

The Security Enhanced Bootloader for Operating Systems - Phase 2 page covers detail on how it all works (not a detailed explanation).

As far as I can see, this is not about Diebold being (fairly or unfairly) ordered to release a damn thing about Microsoft's software. This is about Diebold not wanting to release Diebold's software, and that is all. (Either that, or Diebold is totally ignorant on computer architecture, in which case I don't want it within a million lightyears of a voting machine.)

If we were to assume that ALL software - every last bit - had to be released under these orders, then the only way to do so would be to build from hardware on OpenCores and to have LinuxBIOS (or something like that for another F/OSS Operating System) as the sum total of all BIOS support on the system. Clearly it is possible, as I've supplied the links necessary to do it. I doubt it would be considered reasonable, from a legal standpoint, though.

Demonstrably, then, a total publication of ALL software and software-related material was not what was intended, which means Diebold's move has nothing to do with inability to follow the directives but rather has more to do with an attempt at blackmailing the State government.

I guess the next step would be for someone to take Diebold to court, for Diebold to make their (provably false) remarks in court and for the plaintiff to rake Diebold over the legal coals for it. Lawyers are smart. If there any lawyers on Slashdot, could there be any way of presenting an argument that deliberate FUD, when under oath, constituted perjury or contempt of court?

For that matter, nobody likes being taken for a ride - or even believing they have. The danger of FUD is that it is two-edged - particularly when the public are daily being fed reports of scandal, bribery and corruption from people in authority. It would be easy enough, if anyone had the desire, to use Diebold's own FUD and the current media epidemic to have Diebold branded so deep the PR scars will never heal. That is the danger of such weapons - they can turn against those who wield them.

Diebold, IMHO, is in an extremely vulnerable and dangerous position - whether there are any security flaws in their code or not (and we're all pretty sure there are). If we want provably honest electronic voting (and there are ways to do that), then now is the time we need to take the battle to them. Not just between geeks, but to those who haven't a clue as to what a BIOS is. If there's a way to force Diebold through the courts to give the REAL reason for the withdrawl, it might shake faith in them. Particularly if that reason includes security flaws.

Here's a bootstrapper that's written in over 99% C, boots Linux off several commercial mainboards, and isn't limited to just x86.

I guess TFA is a good technical resource, but it's also a good reminder as to why big wads of assembly suck.