Follow Slashdot stories on Twitter

 


Forgot your password?
Close
typodupeerror
×
Linux Software

LinuxBIOS Gains Steam 126

Posted by michael from the sleek-penguin-under-arctic-ice dept.
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."
This discussion has been archived. No new comments can be posted.

LinuxBIOS Gains Steam More

LinuxBIOS Gains Steam

Comments Filter:

  • Heroic bird (Score:5, Funny)

    by david duncan scott ( 206421 ) on Saturday December 15, 2001 @11:08AM (#2708163)
    Moving like a sleek penguin under arctic ice? I'm thinking brave but lost and alone, thousands of miles from his home at the Antipodes, almost certain to starve...is there anything we can do to help? A walkathon? A benefit concert? A herring?

    • Re:Heroic bird (Score:1, Offtopic)

      by Proud Geek ( 260376 )
      Well, to me "sleek penguin" seems an oxymoron; being fat is a survival trait for a bird that swims in ice fields.

      The other thing I can think of is that "under arctic ice" (or antarctic ice, as the case may be) would be a place where no one could tell, and I might say that if I had really no clue as to how the project was actually doing. I think that the submitter should really learn some new similes, because his current ones just aren't doing the job.
      • Well, to me "sleek penguin" seems an oxymoron; being fat is a survival trait for a bird that swims in ice fields.

        Their shape is very sleek indeed for cruising under water. Ever see those suckers in the zoo?

    • yeah, my reaction too - he's definitely a lost penguin (of course the 'antipodes' are a place relative to where you are or where you normally live - so he may well actually be there).



      I suspect he's really one of those mythical cartoon pengiuns that wear hats and scarves and hang out with polar bears

    • arctic parsed better than antarctic (a clumsy word) and i just presumed you had penguins in the northern hemisphere as well

      - later i thought to check, realised my error and knew i'd be picked up by the slashdot crowd straight away

      more on-topic, here's [lanl.gov] a link to the linuxbios homepage

      • Actually, there are. There are equatorial penguins (really!) that do live in the northern hemisphere. Not all penguins are snow-and-ice.

  • Not Boot to Windows (Score:3, Interesting)

    by ecliptik ( 160746 ) on Saturday December 15, 2001 @11:23AM (#2708188) Homepage
    As LinuxBIOS currently does not provide a compatibility layer for booting other operating systems besides Linux (notably Windows)...


    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...
    • Basically, I think it means Tough shit for microsoft.
      BTW, what about BSD?
    • The good news is, the requirements placed on the BIOS by Linux are a subset of the requirements placed on it by Win2000 (AFAIK).

      For now, at least.

    • That's one nightmare that would not be permitted because of the antitrust suit. It works for Apple, and for XBOX, because the hardware manufacturer can decide what to put in it (so long as they are not a monopoly--IBM got nailed for not allowing third party software, back in the day). But MS is not allowed to do something that would prevent OEM's from installing a different OS.

      Even the secure DRM computer mentioned here earlier is likely to limit authentication to authorized OS's (of which Windows is likely to be the only one using x86 hardware), rather than prohibiting unauthenticated OS's from running. Unless that law that requires OS's to be secure gets passed... That would be bad all over, though.
      • ...XBOX, because the hardware manufacturer can decide what to put in it (so long as they are not a monopoly--IBM got nailed for not allowing third party software, back in the day). But MS is not allowed to do something that would prevent OEM's from installing a different OS.

        Maybe I should start a new /. account called ParanoiaTroll, but I think that this is EXACTLY what MS is about with the EcchsBox.
        What a sweet trojan, this Internet appliance disguised as a console. You get the market built, you come out with great games, then a keyboard, and start offering MSN to EcchsBox owners. Mix in some broadband, and away you go!
        • You get the market built, you come out with great games, then a keyboard, and start offering MSN to EcchsBox owners.

          Microsoft has said on many occasions that they have no plans to release a keyboard for the Xbox (you seem to have been mispelling throughout your whole comment, perhaps you should get spellcheck :). I really don't see what MS would gain out of a Internet Appliance (well, turning the Xbox into one anyway, there is alot to gain out of Internet Appliances). I mean, Xbox has a stripped 2k kernel, that probably isn't much of cost of the final Xbox (probably in that $100 they lose per console); while a full-fledged Internet Appliance could have a real verison of XP Embedded (or something to fit) which they could make additional profit off of (and charge for upgrades, as they have done with every single market they have entered since their birth).
          • Microsoft has said on many occasions that they have no plans to release a keyboard for the Xbox

            Microsoft has also said at each release of Windows, that "this one is reeeeaaaaally stable now." I woulden't place too much faith in what they say, after all they are a corporate criminal in the eyes of the US justice system.
          • Regret the humor of my spelling of XBox was lost on you.
            Additionally, please follow included link to a place where your apparent regard for MS practices can do Mr. Softy the most good [usdoj.gov].
            A groovy day to ya. 8^)

    • What LinuxBIOS is NOT (Score:5, Informative)

      by CatherineCornelius ( 543166 ) <tonysidaway@gmail.com> on Saturday December 15, 2001 @12:50PM (#2708368) Journal
      The importance of this Linux BIOS project is not that it provides a way of doctoring motherboards so that they will not load Windows (and in any case, such an effort could hardly pose any commercial threat to Microsoft).

      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 you read the linux journal article you will see that SIS is an early adopter of this idea. Which is interesting considering that my sis 630 chipset equipped mobo doesn't behave well , or at all, with X.
        • "If you read the linux journal article you will see that SIS is an early adopter of this idea. Which is interesting considering that my sis 630 chipset equipped mobo doesn't behave well , or at all, with X."

          What sort of problems are you having? I have a 730 based system (basically the Athlon version of the 630) which works just fine in X.

    • Re:Not Boot to Windows (Score:2, Informative)

      by cygnusx ( 193092 )
      >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 [geocities.com].
    • I don't even want to think about what MS could retaliate with...

      Well that's good, because that's not the thinking behind the project as others have pointed out.

      At the same time, don't get to comfortable with your head in the sand. M$ is already up to those kinds of tricks. Heard about the DRM OS? I'm sure it has a BIOS component to check the OS for complience. Less speculatively, I've got a motherboard that uses a Norton utility that identifies LILO as a boot sector virus. Very annoying but I can turn it off, for now. Also you should not forget all the work M$ has done to make things non standard and impossible to write drivers to: WinModems, the death of OpenGL, Sound board wierdness, and the list goes on and on.

      Don't think of hardware with Open/Free standards as anti M$. Think of it as something that will simply work that M$ can use if they want. If M$ chooses to go their own way and keeps making things difficult for for their users, too bad. That's no reason to give in and have things difficult for yourself all the time.

  • (hint : moving like a sleek penguin under arctic ice).

    [quibble]Any penguin under arctic ice is seriously lost. Antarctic ice, certainly. The Falklands, and other land masses of the high southern latitudes, certainly. But not in the Arctic.[/quibble]

    • Yep, Polar Bears north, Penguins south. I think the Polar bears might be the reason there are no penguins north
      • Or the penguins are the reason there are no polar bears on the southern hemisphere (well, apart from zoos obviously, which also applies to the penguins).

        But I'm quite sure the real answer is somehing in the neighbourhood of .. say ... evolution.

        No - not the Ximian you dunce!
      • Well actually, polar bears (if I'm remembering my animal science correctly) _eat_ penguins. As well, penguins live just about everywhere. There are penguins that swim up from lower South America to Brazil; penguins in coastal South Africa. Lots of penguins! While most of know the (ant)artic sort, (kings, emperors, puffins, Tux and the like) there are many others (gentoos, the one that sounds like macoroni, rock hoppers) that move about or live in temperate areas all year round!

  • and the bios is for what, exactly? (Score:1, Interesting)

    by Anonymous Coward
    Bootstrapping? Anything else?

    Typical, when they're not decrying Microsoft for embracing and extending, they themselves are embracing and debilitating.

    Even Compaq, today's best known advanced technology destroyer, managed to make a *faithful* copy of the IBM PC BIOS.

    Anyway, why an embedded device would want to use x86 hardware is beyond me...

    • Re:and the bios is for what, exactly? (Score:2, Interesting)

      by Anonymous Coward
      Well, many non-PC systems have sophisticated boot ROMs with powerful debugger/monitors built right in. I worked with a VME bus system that had a diagnositic boot ROM that was almost an operating system in itself. You could interactively diagnose bus faults, hardware lockups, all sorts of problems. A powerful boot ROM is wonderful to have in embedded systems. I'd love to see the LinuxBIOS offer the level of power which I've seen in other industrial systems.

    • Re:and the bios is for what, exactly? (Score:5, Interesting)

      by TandyMasterControl ( 136043 ) on Saturday December 15, 2001 @03:07PM (#2708800) Homepage
      Typical, when they're not decrying Microsoft for embracing and extending, they themselves are embracing and debilitating. ..
      Anyway, why an embedded device would want to use x86 hardware is beyond me...

      because it's incredibly cheap maybe, with a mind boggling array of useful peripheral hardwares?

      The aim of LinuxBIOS doesn't even remotely touch on some competitive manuevering as you ignorantly suggest.
      Installing a LinuxBIOS ROM in place of normal DOS compatible microcode is something you do to modify I>commodity off the shelf hardware hardware to -for example- make your appliance system boot Linux to multiuser + network runlevel from a cold start in 3 seconds or less. It is a very specialized aftermarket improvement for hardware integrators - not motherboard OEMs or PC sellers- and has nothing whatever to do with the kinds of exclusionary practices Microsoft is famous for. It is not practical for general use PC system design, since kernel upgrades mean plugging in a new ROM or reprogramming the old one in a special ROM burner. It is for dedicated appliances only.

      In short, Anonymous Coward, if you can't comment intelligently, and without smallminded paranoia, you may want to forgo commenting at all.

      • It is not practical for general use PC system design, since kernel upgrades mean plugging in a new ROM or reprogramming the old one in a special ROM burner. It is for dedicated appliances only.

        I don't think you read the article. Because the ROM is typically 256K, and the author could not squeeze a kernel down to that size, his code does not use a Linux kernel. Therefore, upgrading the kernel would have no impact on the code in the ROM. Second, there is no need to remove the ROM or use a "special burner". The article specifically mentions that the ROM is re-flashed in place, and onlyl removed if the flash fails.

        And it is not just for appliances. The author states that his focus is on compute clusters. I see this as a logical technology for server farms and even managed workstations. I have worked on automating boot and install for servers, and the antiquated BIOS is always a stumbling block. It would be great to have firmware that works with you instead of against you. For example, as mentioned in the article, moving the console to serial and eliminating video hardware.
  • >LinuxJournal has a good overview article about linuxBIOS and where it's currently at (hint : moving like a sleek penguin under arctic ice).

    Umm .. last time I checked .. there were no Penguins under the Artic Ice .. so maybe you are saying that the LinuxBios is NOWHERE?
    • last time I checked .. there were no Penguins under the Artic Ice .. so maybe you are saying that the LinuxBios is NOWHERE?

      dictionary.com:

      arctic (ärk t k, är t k) adj. Extremely cold; frigid. See Synonyms at cold.

      • The difference being the capital A, one being a generic adjective the other referring to a specific location on this great ball o spinning mud.

        Afterall that was definition #2. Try definition #1
        and a little etymology
        [ME artik, fr. L arcticus,
        fr. Gk arktikos, fr. arktos]bear, Ursa Major, north; akin to L ursus bear
        often cap 1: of, characteristic of, or relating to the region around the
        north pole to approximately 65^ N

  • BIOSes should not be operating system-specific. (Score:4, Insightful)

    by Brett Glass ( 98525 ) on Saturday December 15, 2001 @12:26PM (#2708308) Homepage
    It is no better to be locked into running Linux on a machine than to be locked into running Windows. The BIOS should be a generic facility that can load any desired operating system.
    • Brett, this is not about hurting Windows, this is all about promoting linux at any cost.

      They don't actually CARE about Open Source, just about establishing a NEW default standard *Linux.

      When people talk about how *Linux just copied the UNIX API, want to copy the Windows API, or copy program X, you can add copy Microsoft's monopoly position via creating hardware that only runs one OS.

    • Re:BIOSes should not be operating system-specific. (Score:5, Interesting)

      by DGolden ( 17848 ) on Saturday December 15, 2001 @01:30PM (#2708486) Homepage Journal
      I quite like OpenFirmware, but have yet to see a x86 PC motherboard which uses it - PPC ones do, of course. The specification standard includes support for x86 computers, but the mobo manufacturers have deals with the BIOS producers (if they're not already the same company), and the BIOS producers have deals with MS, which means they've had financial incentives for years for keeping the BIOS in the dark ages of DOS.

      Most current BIOSes are extremely biased toward DOS and DOS-derivatives like windows 95 - they're pretty ill suited to even Windows 2000, I'm sure microsoft now would prefer them to be replaced too (but with something that still ties you to MS, of course - no doubt MS will be prodding at x86 BIOS manufacturers to get this).

      At the same time, perhaps what's needed is a open standard for the provision of a wodge of on-mobo flash-ram - the main reason people want to replace the BIOS with linux, so that the OS loads in a blink of an eye, perhaps without even requiring a HD. It's just silly that the BIOS spends a good while screwing around in Real Mode when Linux (or newer versions of Windows!) just go back and do all the setup again...

      I thik it's be REALLY nice to have an OpenFirmware-type BIOS on x86, but with a few megs of flash on the motherboard that one could load the OS kernel and perhaps an initrd from, instead of having to mess about with the harddrive.
      • Most current BIOSes are extremely biased toward DOS and DOS-derivatives like windows 95 - they're pretty ill suited to even Windows 2000, I'm sure microsoft now would prefer them to be replaced too (but with something that still ties you to MS, of course - no doubt MS will be prodding at x86 BIOS manufacturers to get this).

        Intel is pushing a new BIOS standard called EFI (Extensible Firmware Interface?); it's not really clear why they're not just using Open Firmware except maybe the conspiracy theory you mentioned.
        • Grr... got the 1.02 EFI specification from Intel, it doesn't look like a technologically particularly bad way of doing things or anything, especially given that it's all quite logical and neat, despite the fact they're still trying for a degree of backward-compatibility (which is all parcelled off into its own little section, thankfully) - it's just an easily followed tree of c structures - it's a definite improvement on PC-AT BIOSes, but it's pretty much intel-architecture-specific, of course.

          OF's forth-bytecode intended to act as cross-platform on-card boot-time init and bare-bones device drivers and so on is replaced by in-rom snippets of "PE32+" 32/64-bit IA code, etc., etc.

          It's well-defined support for reading boot-time image files from FAT filesystems, and net-booting, should make the boot process a lot less painful for Microsoft OSes, and a bit less painful for Linux - actually, I presume the Linux-Itanium project's already got this sorted.

          It's certainly well-suited for integration with Microsoft OSes (certain aspects, like the Vendor Device Path look tailor-made for their end-to-end "DRM OS" recently mentioned on /. :-(( ), and it definitely doesn't have the cool forthy hackability of OpenFirmware. ;-) It's still a much better match than the legacy BIOS to modern 32/64-bit OSes though.

          All that said, I think one could, in theory, have a BIOS that was largely x86 EFI and Open Firmware compliant at the same time, if a designer really put his mind to it - one could probably write an EFI-compliant implementation in a mixture of forth and asm in the first place, and have it call legacy x86 PC ("PCI ROM type 0"), Open Firmware ("PCI ROM type 1") or EFI ("Proposed PCI ROM type 3") boot code segments on the PCI cards as it saw fit! The "Firmware Boot Manager" that EFI eventually drops into could be a full forth console, for all intel care, by my reading of the spec, and producing the EFI/ACPI device tree from the Open Firmware tree or vice-versa would just be a "simple" transform, I suppose.

          I very, very much doubt anyone will bother doing this, though, unless Apple paid them a very large bung to encourage the proliferation of OpenFirmware-compliant devices...

          So the fix is in already, as usual. Obviously, they've wheel-reinvented, presumably because OF is (was (afaik it's lapsed, like Scheme)) an IEEE standard they didn't control.
        • Intel is pushing a new BIOS standard called EFI (Extensible Firmware Interface?); it's not really clear why they're not just using Open Firmware except maybe the conspiracy theory you mentioned.
          Intel has its own reasons and incentives to keep its customers isolated from and ignorant of good engineering, not the least of which is good old Not Invented Here syndrome. Instead of putting a command line on the serial port for lights-out system management, they instead rolled their own binary proprietary protocol called EMP, through which you can make some configuration changes, reset the system, power it on/off, and the like. There are even clients for Linux that speak this protocol (VACM by VA Whatever This Week) but that doesn't necessarily make it any more useful in a pinch when you most need it. Compare that with OpenFirmware and Sun's LOM facility on the Netra line, which is easy to learn and easy to use, even if all you have handy is a dumb terminal or a Palm with a serial cable.

          If a card is to be used in the boot process, it needs to have initialization code and some sort of basic driver code on-board. Intel's continuing ability to define the direction of the computing market and thus maintain a ready market for its half-arsed "innovations" depends on lock-in. If that init/driver code becomes portable, then the hardware is instantly useful without and independent of the Intel architecture, and customers' barriers to mixing or even switching architectures drop as quickly as the load in Intel's skivvies. Vendors like Adaptec that can double or more the list price on a SCSI card just by replacing the x86 SCSI BIOS code with OpenFirmware code wouldn't be thrilled by such a move either.

          Large bureaucracies exist primarily to perpetuate themselves, and the customer is only a means to this end. (It only takes a little bit of dot-connecting to conclude that capitalism serves only itself, just like 1984's Ingsoc and the Party, but that's another flame war for another time.)

          -jhp

        • EFI is indeed likely to be part of a M$ conspiracy, seeing how closely it resembles DOS.

          Get to the correct boot drive by typing "fs0:". YUCK!
      • Most current BIOSes are extremely biased toward DOS and DOS-derivatives like windows 95 - they're pretty ill suited to even Windows 2000, I'm sure microsoft now would prefer them to be replaced too (but with something that still ties you to MS, of course - no doubt MS will be prodding at x86 BIOS manufacturers to get this).

        Anyone remember the IBM PS/2 and it's ABIOS (protected mode BIOS)?

    • Code talks, BS walks (Score:1)

      by Anonymous Coward
      It's none of your business what people do in their spare time. Who are you to tell people what kind of software they are "supposed" to write? What are you, some kind of software commisar? If you want something different, YOU code it, YOU sweat it out, and YOU promote it.

      The subject line says it all: Code talks; BS walks.

    • The BIOS should be a generic facility that can load any desired operating system.

      Although the name may make you think otherwise, LinuxBios is a bios that will load any operating system. However, once that OS is booted, it won't provide extensive eighties-compatibility to allow a windows-like OS to continue booting. It provides just the bare minimum to get the OS up and running. Linux then quickly takes over.

      Roger.

    • 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.

      • The fact that windows isn't supported is a side effect of the technology, not an attack on "The Enemy".

        I'd put it differently. The fact that Windows isn't supported is a side effect of the development path. Somebody may implement Dos-bios compatability into the Linux BIOS at a later date, but for people who want a box that can more easily and powerfully boot into Linux, it hasn't been a high enoug priority (yet).

        Probably the quickest way to get DOS compatability put in would be to get a large-market wintel distributer interested in the idea. I can think of a few reasons why a general motherboard manufacturer might be interested in an open-source BIOS. Has anybody approached them with the idea?

    • No one's locking anyone into Linux. People who use LinuxBIOS know what they're getting into.

    • Re:BIOSes should not be operating system-specific. (Score:5, Interesting)

      by sjames ( 1099 ) on Saturday December 15, 2001 @02:42PM (#2708701) Homepage Journal

      The BIOS should be a generic facility that can load any desired operating system.

      That is a desirable goal. Linux was chosen first because that was what the developer needed (meeting personal or professional need is the start of most Free software projects). Secondly, Windows is much more difficult since it is quite dependant on the legacy BIOS calls at startup while Linux is not.

      The upshot is that if you can load the linux image into ram and jump to it, it will boot. With windows, you'd have to re-implement a good bit of the original BIOS.

      Currently, LinuxBIOS just needs an ELF formatted binary image to load and execute. If you'd care to write a second stage that implements all of the necessary BIOS calls and boots Windows, feel free. There are a few people on the developer's list that would love to see that.

      As a side note, it doesn't look like it would be all that hard to get *BSD or The HURD booting from LinuxBIOS.

      • 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.

        • I'm not sure if that has any bearing on being able to boot from LinuxBIOS, just wanted to point it out.

          It's good to know. For linux, it's fairly easy to just skip over the real mode stuff by using the protected mode entry point.

          Presumably, for BSD, the part that makes the V86 calls for parameters could be replaced by a part that grabs the parameters from a 'well known location'.

      • Not everybody at MicroSoft is an idiot. Why is it that they depend on details of the BIOS, which they do not have complete control over, and has lousy archaic interfaces?

        It is true that anybody that makes a motherboard will test that it runs Windows, but that testing is not going to be very complete and there are many machines that are older than the newest versions of MicroSoft software. I can be pretty sure that if somebody loads WinXP on a machine and it fails, they will blame MicroSoft rather than the unusual BIOS chip in their machine.

        So why is this?

    • The BIOS should be a generic facility that can load any desired operating system.

      The instant DRM meets with a Disk-On-Chip that is spacious enough and cheap enough for OEMs, the BIOS will be gone before you can say "Hey! Why won't Linux boot on this new motherboard?!" Not that it won't be hackable (just buy a new DoC, if you can bypass the CPU's DRM support) but I strongly suspect Microsoft would like nothing better than to make it nearly impossible to dual-boot or install a new OS without special OEM tools.
    • Locked into Linux?? You flash the EEPROM to load Linux BIOS, flash it back to OEM for Windows... What's the problem again??

      The biggest problem I could even forsee would be boards with an integrated RAID controller. The OEM updates contain the RAID bios updates and can wipe your RAID settings. Use RAID 1 and select rebuild, problem solved.

      Since when should the BIOS not be optimized for the software?? The x86 BIOS has been the bitch of Windows ever since they started making plug-n-pray a part of it. ACPI was supposed to implement the "Instant On" feature in Win98. (Which still doesn't work in XP.)

      The reality of it is that the BIOS should be flexible enough to be modified to run what you need. The open source nature of this BIOS may eventually provide a "royalty-free" product that doesn't force manufacturers to pay BIOS licensing. In addition, manufacturers also have the option of modifying the BIOS to do more than fix bugs.

      Friends, there are more BIOSes out there than the x86, and everything doesn't "work like Windows". I can't friggin' stand this new generation of "geeks" who think the computer began and ended with Wintel. Same wackos who have never seen a board with jumpers, think VB is a kick-ass lang., and think the DOS prompt is what causes crackers to attack people. The x86 for the most part is a cheap kludge swimming in a sea of cruft.

      The real question is this.... When will we get past 15 IRQ's??

      ~Hammy
      "I write the mooky, my verse is Xtra spooky"
      MR. Xcitement
      nothing4sale.org

      • Re:BIOSes should not be operating system-specific. (Score:1, Informative)

        by Anonymous Coward
        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.
        • Actually, slight correction. Every Intel chip since the Pentium has an APIC on the chip itself. While the APIC can emulate the classic PIC, you lose functionality in doing so. The part that is on the motherboard is the I/O APIC, and that acts at a higher level than the APIC, coordinating device intterupts between multiple-processors.
    • It is no better to be locked into running Linux on a machine than to be locked into running Windows. The BIOS should be a generic facility that can load any desired operating system.

      This BIOS is unlikely to be bundled with new motherboards; therefore it is unlikely to restrict anyone's choices. It is currently aimed at embedded devices and clusters. Anyone who sets up a large cluster of identical computers to crunch numbers probably doesn't mind being "locked in" to the family of OS for which the cluster is intended. And if they decide to repurpose the machines as general-purpose PC's (which is unlikely if they have no disk, floppy, cdrom or video, as the author intends) they can just re-flash the BIOS.

      Given that writing this firmware is a pretty difficult project, I have no wish for the author to go out of his way to also support Windows.

  • Not generally useful.. (Score:3, Interesting)

    by A Commentor ( 459578 ) on Saturday December 15, 2001 @12:27PM (#2708313) Homepage
    Looks like the supported Chipsets are quite limited. And I could find no information on their site about extra hardware that is typically included on the motherboard.

    For example I've got a 440LX motherboard with Adaptec SCSI built-in. The 440LX is not supported and there was absolutely no information about the SCSI. It seems like all the new motherboards include RAID controllers... I found no information about these either..

    So for the markets they mentioned(embedded, and clusters), this is useful... but I don't see normal users needing this.

    • Looks like the supported Chipsets are quite limited. And I could find no information on their site about extra hardware that is typically included on the motherboard.

      The list of supported chipsets is quite limited. That is a combination of there being more chipsets than time, and chipset vendors who refuse to release programming information without an NDA (impossable for a GPL project).

      Reverse engineering is possable, but difficult.

      One objective is to NOT support any extra hardware. The idea is to load Linux out of flash, and let it initialise and support the other hardware. That Linux kernel (and possably minimal filesystem) would then use kexec or monte to boot your final OS (probably another linux kernel).

      • One objective is to NOT support any extra hardware.


        So with my board's original BIOS, the SCSI BIOS comes up after the regular BIOS. This allows configuring of the controller, each device, low-level disk formating, etc. So will the SCSI BIOS still be displayed on boot-up? If not, I would have lost alot of functionality by using the LinuxBIOS.

        • So will the SCSI BIOS still be displayed on boot-up? If not, I would have lost alot of functionality by using the LinuxBIOS.

          It will not. The problem is that that BIOS extension expects to run in real mode with access to at least int 0x10 (and probably much more) which simply isn't there with LinuxBIOS.

          Note that those config settings primarily affect the SCSI devices when accessed through int 13 in real mode. The Linux (or other) protected mode drivers will blow most of that configuration away anyway.

          There are several tools in Linux that replace the functionality of the extension ROM.

          I have used LinuxBIOS with SCSI, and never missed the SCSI BIOS (especially not when accessing from a serial console!!!

  • Arctic Penguins? (Score:5, Funny)

    by Anonymous Coward on Saturday December 15, 2001 @12:54PM (#2708376)
    Well, if it's "moving like a sleek penguin under arctic ice", it isn't going anywhere, there are no penguins in the Arctic, they are all Antarctic residents. :)

  • Reminds me of my ? to RMS about a free BIOS (Score:5, Insightful)

    by weave ( 48069 ) on Saturday December 15, 2001 @01:04PM (#2708404) Journal
    I attended a talk by RMS at H2K. He mentioned how he doesn't use any software that isn't free. I asked him if the BIOS code that boots his computer was free (as in speech).

    He said it was a good question. His position on it is if it's flashable and programmable, source should be free.

    He kind of dodged the question about whether or not his computer BIOS was flashable, free, whatever...

    Don't get me wrong, unlike most people, I have a lot of respect for the guy and I don't believe for a second Linux or Open Source would be where it is today without the efforts of him and his team. It's just that there are always little contradictions that trip up even the best of zealots. Like, I wonder if his life is in danger, will he approve of being hooked up to a computer that provides life support but is running non-free software! :-)

    • Don't get me wrong, unlike most people, I have a lot of respect for the guy and I don't believe for a second Linux or Open Source would be where it is today without the efforts of him and his team. It's just that there are always little contradictions that trip up even the best of zealots. Like, I wonder if his life is in danger, will he approve of being hooked up to a computer that provides life support but is running non-free software! :-)

      There is no contradiction. The GNU developers have faced this problem before when they needed to run a proprietary UNIX (eg, Solaris/Sparc) in order to develop free software (eg, GCC). After much debate they decided that it's perfectly OK to use proprietary tools in order to create their free replacements. This is all documented on http://www.gnu.org/.

  • Karma Whoring: (Score:4, Informative)

    by brad3378 ( 155304 ) on Saturday December 15, 2001 @02:01PM (#2708597)
    I'm surprised nobody posted this link yet:

    The Linux Bios Homepage [lanl.gov]
  • "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.

    I can see it now... (delicate fade...)

    CT: Gee, we're really getting hammered on these duplicate stories.

    Timothy: Yeah, we should do a little more checking. Ah, here comes a submission now. Wow, this is cool! It's Linux! It's a BIOS! Post it, Taco!

    CT: Hold on pardner, what did we just talk about?

    Timothy: Alright, alright, hold on... aww gee, we posted this back in March! Darn it, this is just so cool, too! It's Linux, it's a BIOS, it's LinuxBIOS!

    CT: Calm down, Timmy boy. I tell you what we'll do. We'll link to the original story, and justify this one by calling it an update, with new information.

    Timothy: Can we really do that, Taco? That would be great!

    CT: Sure. This way, we can't get flamed for re-posting an old story, you get to post a cool article, and all our readers can learn about what's new with LinuxBIOS. Everybody wins!

    Timothy: Gosh Taco, you're the greatest.

    CT: Just doin' my job, just doin' my job.

    (Fade back to reality) And that's how this story was posted.

  • other OSs? (Score:2, Interesting)

    by h4x0r-3l337 ( 219532 )
    Can LinuxBIOS be made to boot other operating systems as well? I'd really like to boot BeOS (to the desktop, all services started) in 5 seconds flat. Right now the BIOS takes up the majority of the boot time.


  • That looks very promising, connect to the box via serial on BIOS level, control BIOS settings from the runinng OS, this should turn a PC running Linux in a real server, no need for keyboard/graphic...:-)

    No need for something like http://www.realweasel.com/, which has some other limitations.

    Nuff said, fast to the download area....

    Michael

  • What should be in the ROM (Score:5, Insightful)

    by tsprad ( 160992 ) on Saturday December 15, 2001 @04:51PM (#2709067) Homepage
    1. Initialize all the programmable chips so the board can come up and run.

    2. A quick self-test to make sure that everything looks like it's basically working.

    3. Offer the option of a more extensive self-test to provide some assurance that weird behavior is not a hardware problem.

    4. Load a bootstrap loader from *any* I/O device on the board that might be practical. If the board has an Ethernet interface, it must be able to boot from that. If not, then perhaps from a serial port. This is for initial system installation. Normally you'd boot from the disc controller, of course.

    5. Not require any equipment that's not permanently attached to the motherboard, i.e., if you don't know you've got a keyboard and a local video display, then use the Ethernet (preferably) or a serial port for operator control. Load the loader unattended if there's no operator present.

    6. A remote reset sure would be nice if you could make sure you could keep it out of the hands of the jokers.

    With all that and a 100Mbit Ethernet, the admin could reinstall the officially-approved software on the luser's workstation in a few minutes, without getting out of his own chair, and without having to walk the luser through any complicated procedure like finding the reset button and pressing it, let alone finding some special floppy or CD. And not just luser's workstations, servers, too. once the power and the Ethernet are plugged in you'd never have to turn the lights on in the server room again.
    • That sounds alot like OpenFirmware used by both Sun and Apple on their systems. Sun systems can be controlled from a serial or network interface from firmware load to OS load. Your standard Mac can boot off just about anything you can attach to the thing. With portable systems you can also use components in dumb mode. Like being able ot mount a laptop as an external SCSI (in the case of PB models predating the Pismo) or FireWire drive.
  • It seems to me that any independant effort would be wasted writing a new BIOS-like system. My I suggest implementing IEEE Standard 1275-1994 (aka OpenBOOT). Works on Suns, and Macs, it should work for PCs too!

    cfs
  • Does anyone have any information concerning a realtime linuxBIOS system? I think that the PC platform would make a nice, cheap realtime system and RTlinux would work well but wouldn't provide for quick-booting, industrial strength (vibration resistance) and cheapness (diskless). RTlinuxBIOS? It'd be nice if I could put together a PC system with BIOS-level sensor inputs and digital/analog outputs.

    Anyone?
    • Before you wet yourself look up information on running an x86 is realtime protected mode. IIRC PCs would make shitty RT computing devices by and large. If you want a cheapo little sensor system with digital and analog inputs you'd be better off using real microcontrollers than trying to adapt a vanilla PC system for the task.
  • Last time I checked the LinuxBIOS page, there was talk of creating a minimal Linux kernel that would do the basic init stuff, and then replace itself with the real kernal on the boot drive.
    Is there any reason why they could not modify LILO (or GRUB, etc...) so that it could do the init stuff, and then load Linux/BSD/M$-NT?

    If this is totally off-beam, that I should point out that all thought I'm a programmer, I've never studied PC raw hardware, so my knowlage of a PC boot process is basically

    • Bios inits hardware
    • Bios loads MBR from first boot harddrive
    • MBR loads partion boot sector
    • Boot sector loads IBMBIOS.SYS etc (if your going to DOS), etc..
  • So I can't burn LinuxBIOS to my BP6 (BX chipset) motherboard and boot Linux in two seconds flat? I'm having a hard time getting information about this project on a level that I can comprehend.
  • It's really good to see people thinking of new ways to boot a computer. I think the whole "Small bootloader in ROM finding and loading an OS from a hard drive" is getting a bit old. Personally, I'd like to see mobos with a decent size flash rom on them that you could put a full sized kernel + some more commonly used programs on. I'm talking about shells, server processes etc not the GIMP. You'd boot a fully running computer in seconds! After all, turning a laptop off when you're not using it is the best way to conserve battery life. A fast boot time makes this convenient.

    I wonder if we'll even invent a RAM-like thing that doesn't loose it's state on power off. Sort of like magnetic core memory but at modern RAM speeds. Oh well, I can dream...

Slashdot Top Deals

I program, therefore I am.

Close