Become a fan of Slashdot on Facebook

 


Forgot your password?
Close
typodupeerror
×
Programming IT Technology

How Good is Commercial BIOS Code? 60

Posted by Cliff from the things-users-generally-neglect dept.
Bitten-by-BIOSbugs asks: "My job involves porting PC BIOS code supplied by one of the Big Names to my employer's products. In my experience, this code seems to be so full of holes you could strain pasta with it. However, the vendor seems not to care when I report bugs, and rarely have fixes been made available. What is the experience of other Slashdot readers regarding the quality of commercial BIOS products?"
This discussion has been archived. No new comments can be posted.

How Good is Commercial BIOS Code? More

How Good is Commercial BIOS Code?

Comments Filter:

  • It's a dying concern (Score:3, Insightful)

    by Anonymous Coward on Saturday June 08, 2002 @11:12AM (#3664861)
    Since so few BIOS functions are actually used once the operating system gets into place, it's becoming less and less of a concern to get things perfect. Unless it causes the computer to explode, fixing a bug doesn't get them any more customers so companies don't bother.

    • Since so few BIOS functions are actually used once the operating system gets into place, it's becoming less and less of a concern to get things perfect.

      This is mostly true, but one part which every OS needs is correct ACPI information, which many BIOSs do not have.

  • Another great question. (Score:5, Funny)

    by walt-sjc ( 145127 ) on Saturday June 08, 2002 @12:08PM (#3665006)
    I'm sure at least 70% of slashdot readers have worked with commercial PC bios source. All right people, pony up with the great responses already! Here we are finally with a question perfectly appropriate for /. and nobody is responding.... What's the deal????

    :-)
  • IMO, too many BIOSes are incomplete or are mis-implemented. Most seem to only implement the bare minimum needed for a given motherboard/chipset.
  • ...wouldnt know QA [iu.edu] if it hit them on the head with a mallet...
  • I think you are going to have a hard time finding people with the relevant experience in the slashdot crowd.

    That being said, what *really* needs to be provided by the BIOS these days. I'm suprised they even bother talking with you in the first place. Why fix bugs that aren't used from the OS these days anyway.

    I'm not really sure what features in the BIOS aren't provided by today's popular OS drivers either? Anyone?

    • Re:I Think. (Score:1, Insightful)

      by Anonymous Coward
      APM routines, boot code, and basic chipset managment are the only thing that bios should be doing imo. These should be standardized so that I could hack out an OS with suspend featues on most motherboards in less than the current impossibilty.
    • You're forgetting about embedded applications using "sort-of-standard" hardware. The more you can pack in to the smaller space, the better in those situations. So if a bios provides "service X" then why should you be expected to write "service X" all over again just so you can have two copies in your romset and occupy more space.

  • Haven't seen code, but... (Score:1, Informative)

    by Anonymous Coward
    Judging from my experience with some of the more esoteric functions of mainboard BIOSes, namely booting various operating systems from network, cd and usb, BIOS vendors (and a good deal of bootloader-coders as well) are doing only the bare minimum to get the OS up and running in standard configurations (OS on IDE harddisk, drivers are loaded before other devices are accessed). Deviate from that path and it's a minefield of crashes and instabilities. In a BIOS source, I would expect mostly tables of configuration data and patchy, ugly code.

  • Pasta (Score:4, Funny)

    by ealar dlanvuli ( 523604 ) <froggie6@mchsi.com> on Saturday June 08, 2002 @02:39PM (#3665496) Homepage
    so full of holes I could strain pasta with it

    At least it's not writen in perl. Then how could you tell it from the pasta your straining?

  • Who needs commercial code? (Score:3, Informative)

    by spoonist ( 32012 ) on Saturday June 08, 2002 @04:40PM (#3665888) Journal
    I dunno about commercial BIOS code, but the BIOS [lanl.gov] I use is pretty good... and I can verify it for myself if I want to. :-)

    • Re:Who needs commercial code? (Score:1, Insightful)

      by Anonymous Coward
      Worhy cause, but too bad it only supports a few motherboards that nobody outside of third-world countries, and of course China, where everyone dumps all their shit, can find.

      It also has about two lines of actual documentation on how to set it up, giving anyone who wants to use it a funny look on their face and a need to go look on the poorly archived mailing list for an answer that isn't there. Then the mailing list is sparsely updated with material like, "Hey! Now Linux Bios works on yet another board over a year old that you can't even find on Ebay!", or "Ooh, another company expressed interest in using it, but this has no actual relevance to whether or not you can use it on your computer. Because you still can't."

      If you think this is trolling, you obviously have never tried to use Linux Bios. It is a great idea, and I wish it worked, but it doesn't except in .00000001% of cases where you can find the exact same hardware one of the programmers has. If the developers wanted for it to succeed they would set up a better development cycle and beg (or prominently show strong requests, whatever) for hardware to get working or something.

      • While I agree that it only supports a small percentage of all MBs out there, I think you're overstating the situation a bit.

        I use it all the time on a SiS630 based board that's actually quite good for general purpose use.

        A lot more motherboards would be supported except that it seems many hardware vendors would rather die a horrible screaming death than document their chipset outside of an NDA.

        It takes time to figure out an undocumented motherboard with a somewhat (or not) documented chipset. More developers can solve that problem.

        All things considered, LinuxBIOS has come a long way in a short time.

        I only wish I could devote a greater portion of my time to advancing the LinuxBIOS cause.

    • There are a few free BIOS projects. See Google's Web Directory [google.com].

  • Are there still BIOSs in new PCs? (Score:4, Interesting)

    by Animats ( 122034 ) on Saturday June 08, 2002 @04:41PM (#3665892) Homepage
    Is there still a BIOS, the "basic input-output system" that's the low-level part of DOS, in current boot ROMs? You need a boot loader and a hardware initializer, but is there any remaining need for a basic input-output system in ROM at all? No current production OS uses it. It's 16-bit x86 code. Win95/98/ME might still need it in some modes, but for machines that come with XP or NT preloaded, why bother?

    Is it time for the BIOS to go the way of the BASIC interpreter provided in the original PC ROMS?

    • Re:Are there still BIOSs in new PCs? (Score:1)

      by Anonymous Coward
      There are still BIOSes in billions of machines, and there are still BIOSes in machines being cranked out today.

      Its a small part, but integral to many systems, mostly as an interface between the OS and hardware.

      When I installed Linux on a wintel box (solid linux, not dual-boot), the BIOS still ran before lilo, which shows that even linux (which I view as the best of production OSes) still makes use of the BIOS.
    • Yes, although a lot of it can be trimmed down. You mentioned for example the need for a bootloader. The BIOS allows the bootloader to perform its task without specific knowledge of the hardware. For example, grub uses BIOS functions to do much of its work, such as dealing with disks. Without this, grub would need specific knowedge of various chipsets and interface protocols.
    • Is it time for the BIOS to go the way of the BASIC interpreter provided in the original PC ROMS?
      The trend is in the opposite direction. Things like ACPI have made the BIOS code vastly larger and more complex. This is especially troubling for Linux, since the testing of a BIOS seems to be "Does it boot Windows?" "Most of the time" "Ship it!". Other vendors have taken to putting switches in the BIOS setup where the users pick a BIOS that is suited for the particular OS they intend to use.

      There has been long debates on the linux-kernel list of whether ACPI should be used by Linux. Using it the way it was intended means calling into BIOS code quite often. Since it seems no vendor has managed to produce an ACPI-implementation that is both reasonably bug-free and reasonably complete, there are worries stability and security. Imagine a backdoor in an ACPI BIOS... The shipping Linux kernel uses ACPI as little as possible, but it is not clear that it can be avoided forever.

      The only thing about the BIOS that might go away is the name. It isn't really basic or about I/O anymore.

      • Since it seems no vendor has managed to produce an ACPI-implementation that is both reasonably bug-free and reasonably complete......


        All though not 100% relevant, and not viewed friendly, You can install Windows 2000 (Dunno bout NT, or XP for that matter, never really tried though) without ACPI support, and to my experiance, it seems to run alot better. I Belive you hit F5 when during setup it asks you to hit F6 for the RAID drivers (I think maybe could be SCSI). And then out of the list, pick Standard PC. It seemed to raise the uptime on the boxes I was in charge of (Which was bad because it made my supervisor even less willing to switch to bsd). There are better descriptions online.

  • BIOS developers are generally bad programmers (Score:5, Informative)

    by LordNimon ( 85072 ) on Saturday June 08, 2002 @05:38PM (#3666118)
    I used to work as a BIOS developer for one of the major OEMs. I quit after about two years because I couldn't take it any more. The developers just were awful programmers.

    The reason why is that they've been working with assembly language for most of their careers, while everyone else was learning advanced techniques like object-oriented design and development, and working on multiple languages (C++, Java, C#, etc). There were a dozen BIOS developers in my department, and I was the only one who lnew object-oriented programming. The only one!

    Now, you might be saying, what does OO have to do with BIOS? True, you're not supposed to write OO assembly code, but you are at least supposed to understand the concept, so that you can apply them in some way. The Linux kernel is written like this - the kernel developers know OO concepts, but they use them only where necessary, and the code is still written in C.

    I firmly believe that the only reason why these people worked there was because no one could write this code. Writing BIOS is hard, and it's almost impossible to find someone who knows BIOS and modern programming techniques. I remember this one guy who consumed caffeine all day long and was completely wired. He wrote code really fast, but it was all very poorly designed, and none of it was documented. Every time a new feature was added, the guy had to hack it in somehow, because the original code was always written to just what it was supposed to do, no more.

    Another reason why they were so bad is that BIOS developers are highly resistant to change. Most of them spend all their time updating the code to support new motherboards, but they would never rewrite anything to improve its design. The majority of code was written back in the 80's, and no one wants to touch it. So this code just sits there, from one version to the next.

    What made it more pathetic was that these people were actually better than most BIOS programmers. We would have conference calls with some of these other developers (the company doesn't write the BIOS for all motherboards they sell), and we would ask them technical questions, and they couldn't answer half of them!

    The real solution is to rewrite the entire BIOS from scratch, using proper OO techniques, and writing as much code as possible in C. But today's BIOS programmers aren't qualified for that job.

    • That's a little depressing, if you think about it -- after you get past all the cruft and compromises that make the PC design, things like ACPI and ugly hacks to emulate ISA slots that don't exist eny more, you still have to rely on ancient firmware to get yourself running, and it's like using a gravel driveway as an onramp to a superhighway...

      Mobo makers might be wise to make their specs public. Even just the simple improvement of a 32-bit BIOS would be a good idea (as in start as 16 and switch to 32 first thing on a particular setting).

      /Brian
    • Every time a new feature was added, the guy had to hack it in somehow, because the original code was always written to just what it was supposed to do, no more.

      For most embedded programming, that's the intent and is looked upon as a good thing.
      • I wasn't talking about adding extra features beyond the spec, I was talking about designing the code so that it can be easily maintained and enhanced, without necessarily being any larger or slower.. Any experienced programmers knows what I'm talking about. It's the difference between a good programmer who can think ahead, and one who can't.
    • The developers just were awful programmers. The reason why is that they've been working with assembly language for most of their careers, while everyone else was learning advanced techniques like object-oriented design and development, and working on multiple languages (C++, Java, C#, etc).

      Working with assembly all your life does not a bad programmer make. In fact, quite the opposite. Given the choice between a developer with assembly experience, and one without, I'll take the former, all other things being equal. Of course, an assembly background doesn't automatically make you a good programmer, either, but I think it certainly helps. From observation, I'd be more inclined to say that exposure to C++ and Java makes you a bad programmer, but I doubt that's really true either. I suspect it's just that they're the new sexy languages, and so they're the ones to which newbie and unskilled programmers are drawn, in the hopes of making money...

      • I'll take the former, all other things being equal.

        But that's my point - all other things were not equal with this bunch. All they knew was how to program hardware in assembly language.

        And I think it's inconsistent of you to say that expose to Assembly makes you a better programmer, but exposure to OO languages makes you a worse programmer. A good programmer learns from all the languages he's exposed to. If you're exposed to a language, and it makes you a worse programmer, then you were never a good programer to begin with.

    • To paraphrase someone else, saying you're not suppose to write OO in assembly language is like saying you can't write readable prose using a typewriter.

      OO programming is a state of mind, not a language. OO code is a function of the programmer, not the language. I've seen some of the worst [non-OO code] written in in C++ and Java; I've seen some of the most beautiful [OO-oriented code] written in assembly language.

      Get a clue.
    • During the start-up of a BIOS you don't even have RAM available. Thus, you don't even have a stack and variables and can't even use software development techniques such as function calls. There are ways to fake function calls which are well known to BIOS programmers and are used in places (with severe limitations). Soon, however, you get out of this mess and can start using proper (more normal) coding practices - still with significant limitations. Much of many ??most?? ??all?? BIOS code is written C with assembler used for some freaky bits.

      Sometimes even the assemblers don't do what you really want them to do and you need to do wierd stuff in hex. The last time I did BIOS level code for x86 (actually a WinCE bootloader - not a BIOS) some of the code was written in hex because the freakin assembler would not generate the code that I needed. The resulting code was approx. 1% hex, 10% assembler 89% C. The code was also a mix of 16 and 32 bit (which is what really stumped the assembler).

      C++ Is not a good thing for BIOS work because it hides what's going on. In BIOS-land we don't want beautiful layers of abstraction (we're poking values into registers and we know it), so all that OO design has limited benefit. IMHO, C++ is not even a good idea for operating system code for the same reasons. Linus is more articulate on this point than I am http://www.linuxgazette.com/issue32/rubini.html

      On your generalisation re BIOS programmers.... point taken. I see people like this in many other areas too. People who like to draw a veil of mystery over what they do and seem to get off on clever trickery etc rather than good coding.

      • I never said BIOS should be written in C++. I said that BIOS developers should understand OO concepts and more design principles so that they can be applied when appropriate.

        And FYI, a typical BIOS is 90% Assembly language and 10% C.

    • A very, very insightful post, but I have to pick one nit: equating OO programming with programming in an OO language. In point of fact, you can do OOP in assembler -- there are even assemblers that support it, though I guess they're not very popular. You probably know all this and were just speaking loosely. But it's a sin to encourage well-meaning nitwits who learn a little C++ and tell themselves they are now doing Objects. Which is, of course, the big problem with MFC!
  • Any one ever hacked the BIOS themselves?
    I have a system that hangs at boot up because the BIOS boot order
    code is defective and the manufacturer's tech support is totally clueless.
    • I haven't done it, but you certainly can. Back in the day, the PCChips folks used to publish updated BIOS object code in a form such that it could be flashed into the chip, generally by booting off a suitably-rigged floppy. Doubtless many manufacturers do this. Presumably this thing can be disassembled, hacked, and then flashed and/or burned into an EEPROM.

      I've lost the links, but I looked into something similar for a BIOS that I thought might have a Y2K problem. Downloaded the update, decided to "wait and see", and after Y2K, it was fine, so I never bothered to load it.
    • I've seen some custom bios'es for various mobos on some of the overclocking boards' floating around, so obviously poeople have done it. I'd poke around in the OC boards/newsgroups.

  • Haven't seen source, BUT... (Score:3, Funny)

    by Ashurbanipal ( 578639 ) on Sunday June 09, 2002 @01:34AM (#3667502)
    It's not hard to figure out that BIOS programmers are pretty unprofessional. Just go get a half dozen different motherboards, boot into CMOS config, and select one of the cryptic little configuration options nobody ever messes with, say, "Chronosynclastic Infandibulum". Now, press the "help" key and read the incredibly useful help message: "This option selects Chronosynclastic Infandibulum".

    I'd fire any programmer who did that, but it's de rigeur for BIOSes.

  • ...though it's been about 8 years and the BIOSes I debugged were for IBM PS/2. IBM rarely updated thier BIOS code and they were justified in doing so.

    That said, as a meer admin and user I take it as a rule of thumb that if a new system is acting flaky for no obvious reason, firmware upgrades are on the short list of things to check into along with RAM and video drivers.

  • Most companies don't spend the time or money of good BIOS because the average user never sees it, And the BIOS is still quite important, it loads your operating system, without it, you might as well just toss your computer! I find that BIOS code is getting progressivley worse, AMI bios is okay, but the AMI bios in my pentium 90 is better, as for the award BIOS in my current computer, i'm thinking that writing my own bios could be a good project :) Reece,
  • A while back I spent some time reading up on LinuxBIOS [lanl.gov]. A quick look at that page led me to FreeBIOS [sourceforge.net] (same as LinuxBIOS) and OpenBIOS [linux.de].

    As I recall, poweron to Linux in single user mode was less than 5 seconds. That speed was largely a factor of how fast the code could be read from the EEPROMs.

    Please ask Dell, HPQ, IBM, Gateway, and your favorite mother board manufacturers to dump the crappy old BIOSes and migrate to something modern.

  • Good Day, I can only talk about the AMI BIOS as I work for the Canadian Agent. AMI tests every BIOS they port with the target hardware in their own Compatibility Test Lab. This uses a variety of operating systems and hardware configurations, ensuring reasonable quality. Once at this point, the BIOS has many customizations that would allow that BIOS to work only with the board it was designed for, though it may limp along with Interrupt Routing Table errors etc. on similar hardware using the same chipset. A custom feature of one porting job may appear to be a bug if applied to hardware it was not intended. After a BIOS is ported there are utilities designed to allow OEM customization, such as AMI BCP. (AMIBCP does not require knowledge of Intel Assembler.) For those who do their own code, the new AMI BIOS Core 8 has 20% fewer files than Core 7, and comes with an integrated debugger to help in the debug process. This should help. If you are dealing with AMI, or any ISO 9001 registered company for that matter, ask for a "Non-conformance Report" or the appropriate ISO 9001 paperwork. They must have a formal process for bug correction and customer complaints. Nothing swings employees into action faster than the threat of getting more ISO paperwork.
  • Even though a modern OS doesn't need it. It's still pretty important. It allows you to tweak out your machine. Overclock, set quick post options, etc. There is definately some really poor BIOS out there. Phoenix BIOS in my experience is the worst. Award seems to be the best. BIOS quality seems to be dependent on who made the board. POSTing speed needs to improve. That's my big gripe. I want to leave you with one nugget of knowledge though. If you remove the BIOS and access whatever is left through the OS. And that OS is XP. What you will be left with is a Macintosh. I left the Mac 6 years ago because of things like, booting into my OS to access my BIOS. (PRAM in the Macs case)

Slashdot Top Deals

Suggest you just sit there and wait till life gets easier.

Close