Slashdot Mirror

Ok, first why should I switch from the current BIOS I have to this one, make the case.

You shouldn't. Ok, that's unnecessarily harsh, but as it stands right now LinuxBIOS is primarily for people who are between very and highly technically inclined... Kind of like linux was shortly after it's release. That's why their website "SUCKS," because this isn't yet ready for the KDE crowd. You'd have to be comfortable finding the status of your motherboard, downloading and compiling the appropriate files, reflashing your onboard FlashROM, and other nasty, dirty things. I wouldn't consider myself qualified to get their best documented system up and running unless I was between jobs, and even then I consider it iffy.

Linux BIOS as it stands is useful for a few specific things: Building clusters and building robots. Any embedded system running on linux on a traditional motherboard can be sped up significantly by using Linux BIOS. But it does require quite a bit of work and knowledge to get it running... If you want a computer pre-flashed with LinuxBIOS, you can purchase one off the shelf, but I would be hesitant to try and build one without a lot of time and / or skill.

It isn't that the LinuxBIOS people don't want that kind of end-user friendliness, it's just that the project is still in the mode of getting things working at all, let alone in an easy fashion.

Secondly, as you might have figured out, it is not a drop-in BIOS replacement. Your computer enters the boot phase and exists the other side with Linux running. You'll not get Windows to run directly on that, and I'd be surprised if it ran virtually (as the BIOS windows is expecting doesn't exist). If anyone here has experience running Windows on a LinuxBIOS, please let us know.

None of this is to say that the goals of the project are bad. Imagine being able to boot to command line in 3 seconds! You could start an ssh session before your monitor was done de-gaussing. Attach a 4 line LED display to one of these motherboards, and you would have a great tool for debugging network problems. Or just speed things up significantly, and spend more time doing what you are supposed to be doing, with the added bonus of being able to shut down your computer when you are done (gasp!). It just needs a lot more work, and a lot of developer support. I'm glad to see it posted to Slashdot, as the exposure might net a few more eager helpers.

here.

Here's a list.

This isn't really aimed at Joe Linux, but that may change when DRM starts getting imbedded in the major BIOSes.

Ah, to answer my own post, it looks like it does, for many motherboards

I mean, we've got the OpenBIOS project, Linux BIOS, and FreeBIOS.

Isn't it time to cut out the last bits of non-free software in the computer?

Sure there is a BIOS alternative, here you go: linuxbios.org

Well, there is linuxbios but what I would really like to see is open firmware for intel architecture (not sure if that is possible)

there's already something for this, it's called linuxbios

could it now be the time for an open source BIOS project?

Yes it could. As mentioned in a previous post, check out The Linux Bios Project

You might want to take a look at the LinuxBIOS project if you're interested in an unrestricted alternative.

Thanks for info.

In answer to your question: it depends. In the case of current hardware, no. If the 'driver' were simply a trivial wrapper around the firmware, then I would consider that closed-source but in name.

BTW, LinuxBIOS does not do that much. See (PDF) The Linux BIOS, page 4: five steps: protected mode setup, DRAM setup, transition to C, mainboard fixup, kernel unzip and jump.

The parent should read linuxbios.org.

A less elegant alternative would be to use one of the seveal multimedia oriented linux distributions. Geexbox is about 4 megs and intended to be included in the media containing the multimeida files.

Granted it takes more than 8 sec to boot but it has 0 cost and can be used on any moderately standard x86 hardware

... this project!

Seriously folks, I don't mean to get embroiled in the issue of semantics, but there are all sorts of devices in which their OS is lightweight enough to reside in ROM. If the boot code never hands control of the system off to a secondary module (loaded from a disk, for example) how is it not the OS?

First, look at the various OSes already out there. There are a wide variety for various hardware and with various underlying archetectural philosophies. There's a lot more to an os than hacking together a bootloader et-al. For example, do you want it to be POSIXish? Micro,Mono,Exo kernel? None of the above? What is it's central theme? Persistant objects?, namespaces? files?

What is your primary interest? Do you want to get into the nuts and bolts of the hardware, the semantics of a system/OS, or both?

If your primary interest is the semantics of the OS and archetectural aspects, consider writing a hosted OS. That is an OS that runs as a user application(s) on another OS such as *BSD and/or Linux. With careful abstraction, you can start out hosted (with the MANY advantages for debugging that presents) and later migrate to the bare metal by replacing OS calls with low-level code.

By going that route, you'll avoid many frustrating days of having nothing at all working after a bunch of ASM code (depending on the sort of challenge you're looking for, that could be good or bad).

Some OSes can run themselves. With the user-mode-linux port, linux is moving in that direction. Mainframes have been doing that sort of thing for a long time.

Starting with a hosted OS will also remove much of the grunt work from bootstrapping the OS. Not bootloading, bootstrapping. That is, producing the binaries for the OS before the OS itself exists.

That bootstrapping process will be quite eye opening. Do you want to do that the easy way or the hard way? The hard way is to hand assemble a simple monitor and assembler and load up the raw binary code. Then write a simple compiler in assembler, then a more advanced compiler for the simple one to compile. Now, compile a more advanced monitor. Use that environment to generate the OS. As an alternative, use the existant environment of a modern OS to create a hosted OS. If/when ready, use the hosted OS to generate the bare metal version of the OS.

If you want to check out the lowest level of the system, see LinuxBIOS. LinuxBIOS is a complete replacement of the firmware BIOS in a PC. Unless you want to design your own CPU, you won't get any lower level than that.

An interesting line of thought there is that "Any sufficiently advanced bootloader becomes an OS". The conclusion there is to use Linux as that OS! In the interem, since flash chips aren't big enough, there's various bootloaders loader by LinuxBIOS including etherboot, openfirmware, filo, and a few things built with bare metal toolkit.

If you choose to implement (or emulate) POSIX semantics, you get to use GNU's userspace. In that case, glibc becomes the glue. Otherwise, you might use them as a guideline, or just hack and patch until they run.

Keep in mind, you never know where it might lead. It'll probably join the ranks of the many toy OSes out there that are used by one or two people. Of course, That's where Linux thought his kernel was heading when he started it. Much to his surprise (as I understand it anyway), it took off BIG from there :-)

With the above in mind, how much does the potential (however small) for it to take off like that matter to you? If it matters, you might consider doing something really different. That will tend to remove the middle of the road and cause it to either take off or be run only by you. Which of those happens depends in part on your design and in part on random chance.

If you had a larger cache than program code and memory requirements (and I guess I/O buffers) then you _could_ get everthing into a CPU level cache. That said caches are typically much smaller than the actuall RAM size so to fit the memory contents into cache a hashing algorithm is used. (eg use some of the bits from the memory address to index into the cache.)

Because of the hashing you might still get collisions, it depends, but when you get a collision then the "old" contents already in the cache have to be written back to memory or disk (if they are different then the original copy aka "dirty") or they could just be written over. This is why using a cache can possibly give you really bad performance if things in your code happen to occupy the same cache line in say an often repeated loop. (They keep bumping each other out of cache.)

Your idea leads to another interesting idea; what if the OS got it's own chunk of fast memory that the CPU could access quickly, possibly on a second bus. This relates to the LinuxBIOS project and something called a Harvard architecture (first link I found).

RISC OS is an operating system. ROM is a medium. In general, you can mix and match. See linuxbios, knoppix, etc.

And no, RISC OS is not a good solution if you want security ;-)

A motherboard is a load of hardware, a processor and a chunk of flash memory, right? When you turn it on, it looks in the flash memory and runs the code there. It could be the good ol' BIOS, it could be LinuxBios, Open Firmware, the Intel/Microsoft DRM thing, whatever.

So would it be unreasonable to expect to see a motherboard shipped with a CD with several alternative BIOS-like interfaces for the customer to choose the one they would like to re-flash the board with? Most boards would stick with the Wintel route, that's what monopolies are about, but if customers want an alternative someone will sell it to them.

The players to watch here are not Intel or M$. They are the motherboard and chipset makers in Taiwan. These are the people to whom what the customer wants _really_ matters and they have proved themselves quite capable of going against the party line when it suits them in the past. Just as a graphics card manufacturer has to provide Linux support these days, so will a motherboard manufacturer in the future if they expect to be taken seriously by the early adopters.

I want hardware and software crypto, but I can only reasonably trust people who share the same values as I do.

If ASUS and A-BIT start putting out motherboards that only support the NGSCB BIOS (is it more than BIOS? is there hardware too?), you can bet I'll be supporting the underdog motherboard manufacturer that uses verifiable code built from open source.

save us linuxbios! What other open source BIOS projects are out there?

I've heard somewhere that there's been a cycle in computer architecture going to more on the hardware side to get great performance, to more on the software side to get great flexibility.

Nowadays, I have some computers with a GPU faster than the CPU. I don't need to tell you which extreme we're at right now.

I've always hoped that we just make a processor so simple that we can make it fast enough, cheaply enough, that we need very little other hardware -- and therefore all the hardware would be open and standard, because there'd be so little of it.

Every time I mention this, people point to the "failure" of Transmeta's Crusoe. The failure of Transmeta (and I am writing this at a Crusoe-powered laptop) is that they have (to my knowledge) no way of disabling the Code-Morphing Software. This means that one has to write x86 code and have it be translated at runtime. I bet this machine would be at least twice as fast if I had a compiler for the native VLIW code, or at least a way to cache it to disk.

Imagine if a new card of some sort cost $5 instead of $50, yet performed just as well? And the BIOS, for that matter, is unnecessary. All we really need it for, last I checked, is booting -- at least Linux proves that you can ignore the rest of this. (I may be entirely wrong on that.) The LinuxBIOS project is the right idea, but I'd rather have some simple firmware that boots software from some pre-defined place (a flash card if need be), then the software takes over and finishes the boot.

I don't have to tell you that I hate this idea of "trusted computing" -- it's the Norton AntiVirus approach, sort of modeled after a firewall, but this time, with a deny by default policy. It'd be more secure, if the programs listed as "trusted" weren't developed by the companies I trust least.

So to summarize -- if hardware is so hard to develop, we should make it easier to have enough in software so that problems like this don't happen.

Open Firmware, anyone?

By design, Phoenix's CSS transfers digital security, network management and disaster recovery away from the control of software to hardware...

... That is unless you would like your computer to lock up the way Win95 used to make it lock up...

General Acess Error!
You have no Right to use your computer. If you feel you have received this message in error, please return computer unit to your nearest vendor for a reset for a small fee. Please remember to bring biometrically enabled identification for proof of your identity and right to access this computer. We apologize sincerely for any inconvenience caused and wish you a nice day.

CCS and EFI are both trying to be more like an OS rather than just a BIOS. If you really dig into either of them they are just quite a mess.

Time for LinuxBIOS www.LinuxBIOS.org

Hey, free your firmware! Goodies and thus the kernel is bieng uses on your entire SYSTEM muaahahahahahah said the penguin. How's that for a trusting extensible hardware independant piece of firmware? (Good enough sandia, good enough for me.)

This is braindead. Introducing a huge layer of complexity between the OS and hardware etc. Really the job of the BIOS should be to do as little as necessary and then hand things off to the OS. Does a BIOS truly need a TCP/IP stack? Perhaps it is time to put a bit more effort in to linuxBIOS.

Maybe it's time to start helping out/using LinuxBIOS. I went to SCALE over the weekend and saw a interesting presentaion on LinuxBIOS, it has lots of benifits over other commercial BIOS's.

Free firmware? Hey, it could happen.

Check out DQ some time.

You're right about heat and density. Heat and density are directly associated. It's the reason 1.6U Evelocity nodes were chosen for Orange instead of .8U nodes used in Pink.

Check out DQ some time.

You're right about heat and density. Heat and density are directly associated. It's the reason 1.6U Evelocity nodes were chosen for Orange instead of .8U nodes used in Pink.

You might want to check with the developers of LinuxBIOS. I know that they have had some luck working with VIA. There knowldge should be sufficiently low-level for you to be able to write drivers.

Looks like we need to start checking to be sure our next motherboard's flash can be reprogrammed with LinuxBIOS.

if you are interesting in making a regular PC that boots up very quickly, you should definately check out www.linuxbios.org

i last played with this almost 2 years ago, and i was able to build a PC which booted from power off to playing MP3s in 6 seconds.

if that 6 seconds could be reduced to 200ms, that would be awesome! then the PC would probalby boot up faster than my hard drive could spin up and be ready.

cheers,
-zach

Just like the innovative technology being offered by this company, something an opensource solution would never be able to offer. Sure you can wait around for an open solution, but the rest of the world will advance at a steady pace while linux/bsd zealots trail in our dust. The answer is not in opensource, but in propietary solutions that meet the cutting edge that industry is demands.

#!/bin/sh
/bin/cat /dev/null > /var/run/utmp
/sbin/insmod /modules/nvnet.o
/sbin/ifconfig lo 127.0.0.1
/sbin/mount -o remount,rw /
/sbin/mount -t proc /proc /proc
/sbin/insmod /modules/nvidia.o
/usr/X11R6/bin/X -broadcast
/bin/sh

No shutdown script is necessary because Xterminal users simply logout and turn them off.

I think one of the biggest slowdowns on PCs is the lame PCBIOS which takes a very long time to run through all the hardware. I remember following LinuxBIOS development. It is so fast, that it was finished checking the computer's hardware before the disk drives finished spinning up.

LinuxBIOS

The Right Thing to do is of course to support the LinuxBIOS project.

LinuxBIOS. It does not support all boards or anything, but it does support many of them. Here is the list of supported hardware.

LinuxBIOS. It does not support all boards or anything, but it does support many of them. Here is the list of supported hardware.

As Well as LinuxBIOS
though I haven't had the balls to try it on my ECS K7(SiS735). perhaps one of these days.......

One thing that makes this country great, is the freedom to choose. Even if all the OEMs decide it's a good thing, we can still buy off the shelf motherboards and build the PCs ourselves like we did in the good ole days. Also, there is always LinuxBIOS (Google cache). I'm sure they'd kick it into high gear and come up with viable solutions.

I will be certain not to purchase products containing Phoenix BIOS now.

Matter of fact, I'm seriously considering using the Linux BIOS .

I am trying to decide, going by the list of supported mobos, which mobo to buy next.

I'm tired of all this big brother crap. Mark me down as a refusnik.

This simply means it is time for more people to contribute to the following Open Source BIOS projects:

See: LinuxBIOS and
Open BIOS.

Also of interest is this announcement of an Open Source BIOS that successfully booted Windows 2000. (It also boots Linux and OpenBSD.) This was in November of 2002, so there may have been more progress since. They also got help from the bochs project.

Sign up to help these teams today!

You should check out LinuxBIOS for some answers, but I think you'll still need a flashable BIOS to use it.

Open Source "BIOS" Its basically a very small wrapper around a Linux kernel. The kernel is ungziped and booted at power on, and they have reported boot times of 3 seconds. Smart.

Don't do it, you're pretty easy to replace.

A Mini-ITX Linux system that used the functionality provided by this driver, had a 3-second BIOS bootup time using Linuxbios, plus a PCI TV tuner card with hardware MPEG-2 encoding, would be a pretty impressive media center.

You may have a look at Linux on IBM laptops and Linux on Sony laptops. There are entries for laptops equipped with a LinuxBIOS.

On a serious note since it's based on LinuxBIOS they have a system where you can launch another Kernel without taking the system down. It is quite clever and you can optimize alternative kernels for the program you are running, incl 32 vs 64 bit.

...is that AMD opened their platform well enough to the LinuxBIOS developers while Intel basically told them to screw off and live with EFI. Here is what Ron Minnich had to say earlier on the LinuxBIOS mailing list.

Pitty this is getting so little support

Have you tried recently to make a program in ASM?
A 3D program? how about a game? It'll take you hundreds of times the amount of time it takes in C/C++/Perl/Java so on.

That's how languages evolve. Less speed, more features for the programmer. This is to make more complex programs feasible, otherwise, every new program would take 2 times the amount of time it took for the older version. Point is.. faster development time, more features go into it. Hardware today is underused anyway.

PCs are slow to start up because of the BIOS. There are many people pushing for it's removal and replacement by other things. www.linuxbios.org

As for the predictions:

HURD (yeahh.. righhttt)
A few new programming languges. One to replace C/C++. That would be much simpler to learn, faster to use, and have more features.

More advances in Language processing.. maybe even a more natural programming language that could be learned very quickly.

Computers will become part of the house, and controll everything from lights to stove. (You come into the house.. lights come on automatically, Star Trek type voice controll)

A better way of interacting with computers, maybe hand gestures, coupled with voice recognition.
Much better voice recognition :)

Games with storyline and with graphics.

Linux maturing and taking up a big share of the desktop market.

Intuitive desktops and applications. Try looking at someone when they first come to a computer and seeing what they try. I'm doing this with Linux (trying on people with no Linux exprience just windows). When I've gathered enough data I'm starting an app to make migration simpler. (a unified setup utility)

Surprises.. things we never thought of, actual innovation :)