Slashdot Mirror
How Good is Commercial BIOS Code?
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?"
..... what all than about five people reading this could do.
None are more hopelessly enslaved than those who falsely believe they are free. Johann Wolfgang von Goethe.
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.
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.
You are being MICROattacked, from various angles, in a SOFT manner.
...wouldnt know QA if it hit them on the head with a mallet...
Finally! A year of moderation! Ready for 2019?
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?
"...In your answer, ignore facts. Just go with what feels true..."
Write your own damn BIOS instead of whining to Slasdot, you lazy bastard!
Seriously though, maybe you should consider this. How much would it cost? and How much would you save by not using the supplied BIOS (including support costs, etc.)?
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.
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?
I live in a giant bucket.
I dunno about commercial BIOS code, but the BIOS I use is pretty good... and I can verify it for myself if I want to. :-)
Is it time for the BIOS to go the way of the BASIC interpreter provided in the original PC ROMS?
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.
And the men who hold high places must be the ones who start
To mold a new reality... closer to the heart
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.
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.
There's an open source group doing it.
May we never see th
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.
A firewall can not protect you from yourself. Turn off what you do not need. Do not use the firewall to do your work.
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,
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)
In my experience, BIOS's work fairly well in 95% of the cases, but when you start tweaking and setting the options to things other than "DEFAULT" you may run into wierd problems. That is why that one lone "RESET CMOS" jumper on the Motherboard exists to this day.
Also, I know that the GRUB (Grand Unified Boot Loader) developers had trouble with some of the Gatway BIOS's. It seems that LILO compensated quite well for various buggy BIOS's. Just looking through the CVS changelog for LILO or GRUB could probably give you a lot of BIOS insight.
As for me, I don't work on that level anymore and my GRIPE is the MOTHERBOARD MANUALS. They can only point out the obvious and many of the options go unexplained or undocumented. When I build machines, I try different BIOS settings then do benchmarking to see if tweaking the BIOS can yield better performance, and yes, BIOS settings do matter since you can gain another 5%-10% performance (in some cases). A good reference for this is Tom's Hardware Page.
Good Luck!
My experience with the General Software BIOS was generally good. This is a semi-specialty embedded BIOS, but it has most features of a mainstream BIOS. The code seemed well laid-out, enough that I could work with it and expand it easily enough. Of course, it came with ALL of the source code (I understand most BIOS kits don't?). This meant we never had to depend on the vendor for anything, we just fixed it ourselves. And they did at least say "thank you" for the one bug fix we submitted.
What an arrogant cunt Mr Alan Cox is!
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.
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!