Stallman Calls For Action on Free BIOS 487
Dolda2000 writes "Seeking to achieve 100% software freedom, RMS is now calling for action for a free BIOS. From the article: "The most uncooperative company is Intel, which has started a sham 'open source' BIOS project. The software consists of all the unimportant parts of of a BIOS, minus the hard parts. It won't run, and doesn't bring us any closer to a BIOS that does. It is just a distraction. By contrast, AMD cooperates pretty well." For reference, there are currently two projects for a free BIOS that I know of: LinuxBIOS and OpenBIOS."
Does Anyone KNow (Score:4, Interesting)
Flashing up is hard to do (Score:4, Interesting)
- Unzip the self-extracting archive.
- Find the disk image included therein, and burn it to CD-RW as an ElTorito bootable CD. (With nothing in the data track.)
- Boot from CD and flash BIOS.
- Erase CD-RW.
- Don't Profit!
I'd love to have an alternative to the BIOS which is open source, or free software, or both. That way I can finally claim to have a computer completely free of closed, proprietary software. And maybe have a chance of configuring the hardware a little better as well. Dell's BIOS is painfully short on options.Eat your own dog food.... (Score:5, Interesting)
You can help our campaign by buying AMD CPU chips and not buying Intel, and by publishing statements about what you're doing. Likewise, buy motherboards that support free BIOS.
According to the FreeBIOS website, Acer , Via and SiS support it . And it will probably see a LOT of Bochs [sourceforge.net] in testing too. So I might opt for an Acer laptopt finally (it's cheap too)Re:Ibm (Score:3, Interesting)
Innovation (Score:5, Interesting)
Re:Flashing up is hard to do (Score:3, Interesting)
Aside from that, why do they bother with floppy images? most of their machines dont come with floppy drives anymore anyway.. and a program you run from the os won't work too well if the old bios is causing your os to not boot.
Re:Eat your own dog food.... (Score:3, Interesting)
According to the FreeBIOS website, Acer , Via and SiS support it . And it will probably see a LOT of Bochs in testing too. So I might opt for an Acer laptopt finally (it's cheap too)
Well my new linux box has an AMD64 cpu on an Asus motherboard with a Via chipset. Guess that's at least 2 our of 3.
Re:How would "cooperating"..... (Score:3, Interesting)
I don't really see what they have to lose though, they are mainly interested in selling chips and the BIOS is just something they have to provide in order for them to work.
Re:Liability problems? (Score:3, Interesting)
While there are neat devices out there that will connect to the video card and keyboard and conver it, such as the Real Weasel [realweasel.com], i'd rather see the solution embedded in the existing BIOS infrastructure.
I think the key thing here is to remember what BIOS stands for, which is the Basic Input Output System. Something to talk to the "known" devices, such as Serial Port (not USB folks), int13h disks, video and keyboard.
Re:LinuxBIOS isn't a BIOS (Score:2, Interesting)
The problem is, "what do you mean by BIOS?" (Score:5, Interesting)
There are two extremes to the schools of thought on this.
The first is the minimalist: The BIOS is just enough code to put the machine into a state where it can load the real OS, and once the real OS is loaded the BIOS is no longer relevant. At a minimum this code would just set up the basics of the machine, and then load some section of the hard disk into memory and jump to it.
The second is the maximalist: The BIOS should provide abstract access to all hardware so that the OS does not have to have drivers. The BIOS would provide routines for the disk controller, video, human interface systems (mouse/keyboard/etc.), memory control, system control, you name it. The OS would never get its hands dirty accessing real hardware.
Both of these approaches have problems. The Minimalist approach means the OS has to support all hardware - which is the lament those of us who don't run Microsoft operating systems will sometimes have. If your OS does not know about your shiny new FooCard then you are out of luck. In the ideal Maximalist case, the BIOS would supply routines to access all the functions of the FooCard and your OS would Just Work no matter what.
However, the problem with the ideal Maximalist approach is that desiging a BIOS API that will work with all operating systems is HARD . Your BIOS has to have a means of calling back into the OS (since real, non-trivial drivers need to have things like semaphores, queues, interrupt handlers, rescheduling points, etc.), but then you have to insure that all operating systems supply all those APIs with the same semantics.
Now, ask yourself, if you designed a BIOS callback API around the Windows semantics (drivers cannot block, drivers must schedule a deferred procedure call if they cannot complete, drivers cannot cause a page fault to swap) how different it would be from a Unix-y style callback (drivers can block, drivers can pagefault from swap, drivers run til they are done).
The current thoughts are "The OS knows best what to do, let the OS have the drivers".
Now, in the context of a Free driver, you have to decide where between the Minimalist and the Maximalist you want to draw the line. Do you want to force the OS to have the code to set up the memory handlers and PCI bridges, for example? If the OS can handle reprogramming the PCI bridges it sure makes PCI hotplugging a great deal easier!
If you look at the LinuxBIOS approach, it is more of a maximalist approach targeting the Linux kernel. This is great if you run Linux, but what if you want to run *BSD, or Windows, or CP/M-86?
It would be possible, barely, to do like my old Multia did - provide BOTH a Windows friendly BIOS and a *nix friendly BIOS, and a means to switch between them. But now you've just doubled (actually more than doubled) the work for a system manufacturer - he has to write a BIOS for Windows, a BIOS for Linux, an BIOS for NetBSD....
"Just publish the specs, and we will write the driver!"
Again, publishing all the specs is hard - there's always that little "Oh yeah, we found that if the temp is less than 5C you have to wait an additional 50uS for this part to respond to a query - it's not intended behavior but it is observed behavior, Charlie found that out."
And even if you can completely document all the specs, there is still the little issue of "How do I, the end user, get the BIOS for *my* OS flashed onto this board?" - if you think the manufacturers are going to flash boards with seventeen different BIOSes depending upon the customers whims... I have some oceanfront property in Goddard, KS to sell you.
Then there is the issue of add-in cards - how do you integrate any BIOS they may have on them into the BIOS on your motherboard?
Now, I know somebody will point out OpenFirmware - the idea that the cards provide drivers in a bytecoded language targeting an API
Why rewrite a free version of the same horror? (Score:5, Interesting)
What about making something more useful than what is there now? Something that could have more features, such as replacing grub all together? (as in be able to boot any of your OSes on any any kind of bootable hardware) Maybe even have it run *gasp* in 32/64-bit mode and leave all the old horrors of x86 BIOSes behind, and maybe even make it possible to tailer it to other kinds of hardware (not x86).
If they want people to support this, they really need to add some value to the whole thing, as many do care less about holier-than-thou hippiness.
Open Hardware (Score:3, Interesting)
Why wouldn't vendors want a free BIOS? (Score:3, Interesting)
Is it really just a case of the dominant vendors wanting to use BIOS quirks to lock-in their market share?
It's called free market (Score:3, Interesting)
So what Stallman is trying to do is build a market force that will persuade Intel that it is in its best interest to create a free bios or at least to not stand in the way of creating one.
Hope this answers your question.
Re:It makes sense (Score:2, Interesting)
It seems ppl now want open source software just for the sake of it. For claiming having the hypothetical "free" system. Noone stops to even think whey they need this open-sourced. One thing to keep in mind, open-source and proprietary software should co-exist and everyone should make their peace with that, u'll never get open-source software without proprietary ones, developers need to make a living too!
Re:It makes sense (Score:3, Interesting)
Why does it make sense?
I am very much for Open Source, but for me "Open Source" includes BSD style licensed projects, but not GPL. Not trying to be flame bait, but I think GPL is damaging the Open Source movement. I say this because as a commercial developer I know plenty of managers who won't let me use Open Source on their projects because they think all Open Source has a viral license such as GPL.
"Software should be free..everything should be free, including the BIOS". Nice concept, but reality is we live in what's called a zero-sum game. We as humanity have a finite amount of resources, which means that if I'm going to expend resources by writing software I need to get something in return, in order to provide for my family.
BSD style licenses allow me to get recognition (not much I haven't written a lot of Open Source) and allow me to re-use that software in my commercial projects, which benefits me and Open Source as it allows me to get buy-in from management.
GPL licenses do not. Essentialy I write GPL software and I cannot use it in any commercial projects.
I love the concept of free software, and I think we are on a downward slide to having to pay a micro-payment for each web page you view, but call a spade a spade: IMHO, GPL is not designed to increase free software but to get rid of commercial software. As someone who's method of feeding my newborn baby is writing software you'll have to drag me kicking and screaming to work on any GPL'd code.
More of a rant than I intended but I'll leave it as is, and see open a forum this is.
Btw, I may very well be wrong as I have a limited viewpoint: A commercial developer, supporting a family, who has stayed away from GPL and even LGPL projects as code I write generally has to be re-usable in my commercial projects.
Doing without the BIOS entirely (Score:3, Interesting)
There is trend toward larger and more featureful BIOS. I just don't understand that. Everything that can be done by the OS should be. Updating an OS is much easier than a BIOS, for starter.
And while you are there, why not drop the DOS-supporting cruft ? (like most of the BIOS software interrupts, for example)
Aren't BIOSes hardware-specific? (Score:2, Interesting)
The many and myriad chipsets out there all have quirks and special setup needs, even in really simple configurations. Chipsets have many registers that may need to be configured based on the layout of the traces on the motherboard - I've seen older VIA chipsets with registers for timing delays and (I think) slew rates on IO pins.
This would require a small army (or a company like, say... oh, I don't know... PHOENIX) to not only sift through the mountains of often crappy documentation to squeeze the most out of the chipset, while keeping the board stable.
If it's a choice between a stable, well-tweaked CLOSED BIOS and an unstable, lowest-common-performance-denominator OPEN BIOS, I'll pick the closed one, thanks.
The issue is... (Score:2, Interesting)
Can we live and power our computers without one?
Why don't we strip all obsolete junk away, i.e. the A20 gate? Once we do that, why don't we get rid of the BIOS itself?
The less hardware and software, the more direct access we'll have to the hardware, and the less software-wrappers we'll have around hardware -> higher speed, less code, more time for important things.
I can't answer those questions. Can you?
Re:It makes sense (Score:3, Interesting)
Your welcome, and thank you for that sentiment.
Very good point, 'commercial' and 'proprietary' are very different animals, and I intended 'proprietary'. One such group I believe is JBoss, who IMHO put out an awesome product, and in fact one of the more commercially used FOSS (Free Open Source Software) products.
For the rest, both you and another commenter seem to be talking about dual licensing. Admittedly I do not know much about that. Can you explain how the following scenario would work?
I work for company xyz making product abc. Abc uses some new proprietary algorithms (the 'a' of abc), and per management the source code for the implementation of these algs MUST remain undisclosed to keep competitive advantage. The 'b' and 'c' of 'abc' are known problems, and there's some great GPL's solutions usable off the shelf. So our final product is 'a' (properietary license for binaries only), 'b' (GPL) 'c' (GPL, and glue code (could possibly be GPL).
Can management remain happy by keeping their baby to themselves, or would GPL require that the source to 'a' be made available?
The above assumes someone else wrote 'b' and 'c'. How would the scenario change if I wrote 'b' and 'c'? Would it then be possible to keep management happy, and if so what would the licensing structure be?
Thanks for the help btw. I really don't know much about licensing legal terms, but this is important for me, now more than ever as I used to just do what I love (i.e. code :), but am now taking on more of a managemen role to get more money and more freedom in what I code.
Re:Liability problems? (Score:2, Interesting)
Re:The problem is, "what do you mean by BIOS?" (Score:3, Interesting)
I am not an engineer, but I would go with a Minimalist approach augmented with just enough smart to abstract access to the boot device. Which is, in itself, pretty big if you take into account booting from the network, USB/Firewire devices, etc. From there on, the bootloader or the OS kernel should take control.
Re:Does Anyone KNow (Score:3, Interesting)
Unfortunately, the LinuxBIOS project seems to be dead as open source: none of the source code can be downloaded anonymously from Sourceforge, the alleged CVS tarballs haven't been there in months if not years, and the last available tarball is from 2000.
Intel's Extensible Firmware Interface (Score:3, Interesting)
The license on the download page looks like a standard 2 clause BSD license.
You can't eliminate companies (Score:1, Interesting)
The GPL version of open source is not going to work, especially if you want an entire system from thousands of different vendors to be 100% open source. It's hard enough to get industry-wide standards adopted WITHOUT requiring everyone to give their products away for free.
The only thing that will work is to either reinvent the wheel from scratch, in your own country, under communism, and hope you'll succeed where no one else has. (China seems to be making progress).
-OR-
Come up with an open source license that doesn't take away control of finished products from companies who haven't yet had a chance to earn a profit from their work
The GPL doesn't work, it requires immediate release of source that can be used by competitors or would-be customers, and eliminates the profit motive.
The BSD license doesn't work because it doesn't require the release of source.
The only license I know of that might work is the Zesiger License [zesiger.com] because it allows companies to use open source in their products, and keep their source closed (like BSD) for two years before they're required to release the source (like GPL).
Two years of marketing and sales ought to be enough time for most companies to earn a profit on their work. The end result will be that instead of having two factions, Stallman and his followers, and Gates and his followers, with a fence in the middle, you end up with the two factions cooperating, and using each other's work to produce great products.
Isn't that the real goal anyway?
Re:It makes sense (Score:4, Interesting)
I would hope so. The GPL was created as the license for the Free Software movement, by the same people who founded the movement. The much younger Open Source movement, on the other hand, was hostile towards the Free Software movement from the beginning: as you might remember, RMS was deliberately not invited to the meeting which was later considered the founding meeting of the Open Source movement. As a supporter of the Free Software philosophy, I have no sympathy for the Open Source movement.
This is of course FUD. The license applies to the licensee, not the copyright holder. The copyright holder can use the same code in commercial free, non-commercial free, commercial proprietary and non-commercial proprietary software at the same time.
The GPL is designed to increase the amount of Free Software, so that proprietary software becomes obsolete.
As someone whose method of feeding my family is writing commercial Free Software, you'll have to drag me kicking and screaming to work on any BSD-licensed code. :-)
Seriously, you appear to work for a proprietary software company, i.e. your employer's business model endangers my ability to feed my family as much as my employer's business model endangers your ability to feed your family. That's just how our economy works. My employer wouldn't release anything under the BSD license precisely because he doesn't want to give your employer the ability to use our code without giving anything back.
Re:Aren't BIOSes hardware-specific? (Score:3, Interesting)
Re:It makes sense (Score:2, Interesting)
This way you need to make A quite modular in order to "interact" with B and C, and if you like you could also modify (GPL'd of course) BC in some way to "interact" with your program.
Something like if MSOffice would allow Save As
Re:Wrong implicit assumption! (Score:3, Interesting)
I do not wish to insult you, but many Americans seem terribly narrow-minded and uninformed in that respect, having been tought from childhood that everything related to communism is "bad" without ever going into detail
I am proud to call Stallman a fellow American. Left leanings and all, through his push for the freedom of ideas and cooperation, he exemplifies the patriotic ideals of our founding fathers. Richard Stallman is the Thomas Jefferson of the computer age.
I think Europeans stereotype Americans and their views too narrowly. It makes America easier to understand for them maybe. Having said that, the communism the world has witnessed for the past 100 years deserves all of the scorn that can be heaped upon it.
electronics mass production bottleneck (Score:2, Interesting)
I think in a few years' time, we'll see technology that could be adapted to a garage electronics shop. Some things might still have to be purchased from a commercial vendor, like silicon wafers and such, but I've seen plenty of articles in MIT Technology Review [techreview.com] during the last 5 years that really look like they could allow hobbyists to cheaply produce their own microelectronics.
I think the hard part is going to be getting our hands on the software needed to design the things though. Here's some info that might might get you started if you want to browse for more ideas - http://www.geek.com/news/geeknews/2004May/bch20040 525025304.htm [geek.com]
How to flash motherboard BIOS under Linux? (Score:3, Interesting)
Do we have a UniFlash [uniflash.org] counterpart in GNU/Linux?
(Btw, UniFlash is a DOS utility.)
Because AFAIK, I still have to boot a DOS floppy in order to have my motherboard BIOS flashed; or rely on tricks like creating a Bootable USB flashdrive wilth DOS on it [linuxcompatible.org].
Re:It makes sense (Score:2, Interesting)
Thanks for the long and insightful answer, and thanks to everyone who's posted. I definitely think I have a better understanding of how GPL works now.
The big difference is the copyright-holder. If it's me then I can license it however I wish, say GPL and commercial. If I'm using something where the copyright is held by someone else who's released it under GPL then I have two options (1) Release my product, a derivative work, under GPL, (2) give them money to license their software under a commercial license which allow me to use a commercial license. If it really is that simple, then it is amazing the amount of FUD surrounding GPL. I have some pretty decent managers (most of mine are NOT morons!) and I know they tend to avoid GPL like the plague, so maybe I can help convince them otherwise. On a sidenote I do know of one case (I can't go into details) where a derivative work definition was different than expected. Another team was using MySQL as their database and was told by the MySQL team that using their database made the team's work a derivative and that the team couldn't release a commercial product using MySQL.
Seems weird, and bear in mind this is third or fourth hand info, but it sounds like derivative work means whatever the copyright holders want it to mean as was mentioned in one of the posts.
Would be nice if their was a contract out there by the Open Source movement that said exactly what a derivative work was and excluded anything not specifically covered. It would have to be updated on a regular basis and could hurt the FOSS community if it wasn't detailed and thorough. I gues this would kind of be like a meta-license. Basically the copyright holders of the GPL, LPGPL and other FOSS licenses would agree to license their licenses under this meta-license, thereby establishing a baseline for what a derivative work is or isn't.
I'm a newbie to non-BSDish licenses, but is there some initiative like that out there? If there isn't do people think it's a good idea? Part jest, but also serious:
FYI, IANAL.Why have a BIOS API? Why even have a BIOS? (Score:5, Interesting)
The early BIOS was there to provide basic I/O support ... hence the name. but not all machines in the day had such a thing. This really came about from the fact that microprocessors were also being utilized in embedded applications involving firmware. So it was natural to think of having a firmware do common parts, like low level hardware support. But big computers, such as IBM mainframes, had no such thing. And they didn't need it. And a PC doesn't need it, either ... especially an I/O API part.
What is really needed to get an operating system started? Really, just a boot loader. The first computer I used was a PDP-8 minicomputer. It had a front panel where you could set switches to define data and address, and store the results into core memory. There was a boot loader program we would manually toggle into core memory when we needed to (core memory, BTW, retained its contents when powered off). That boot loader would then read the paper tape reader and load the operating system. But there was no I/O support from the boot loader. There was no firmware. The OS being loaded was self contained.
The next computer I worked on was an IBM mainframe (several of them, actually). Early models (360 series), did what was call IPL (initial program load) by triggering a single CPU instruction to perform a single channel I/O operation to read from a specified device (selected numerically by dials on the front panel). The first read operation loaded in just enough additional instructions to start more read operations to bring in enough of a boot loader to load the entire OS image. Then it branched to the OS and things took off. Again, there was no firmware I/O support other than these machines did have separate "I/O channel processors". The OS had to do whatever it would do on it's own.
Fast forward to the emergence of BSD and Linux on PC. The BIOS is used to load the boot loader which loads the OS. The boot loaders generally do use the BIOS API, but in theory, they should not have to. The OS (32 bit and 64 bit versions now) don't need, and generally can't use, the BIOS API.
So I say, get rid of it. Let's not have an I/O API in the BIOS anymore. Then let's quit calling it a BIOS (because it won't be that anymore).
That leaves 2 functions which what we now call a BIOS does already, which we still need to do. One is to configure the hardware. This is one of the hard parts because it has to be tailored to the chipset and maybe even CPU involved. The other is to load the operating system.
The hardware configuration could be handled in a different way. By adding on a 2nd smaller (maybe 16-bit) CPU, it can run a firmware program separate from the OS (the host CPU) that not only configures the hardware, but can also constantly monitor it while the OS is running. It could even be networked for those 10,000 machine server farms.
This same extra CPU could also do the boot loading. But it wouldn't need to do much device I/O. It should have the ability to read a few basic devices (serial port, USB, Firewire, floppy, CDROM, ethernet, and IDE/SATA hard drives) sequentially from a specified starting point and load blocks into RAM or into flash memory (or flash to RAM). Put it in a loop and it can do this with megabytes of OS images directly (this serving as the full boot loader). Flash memory of 4MB to 16MB would be plenty (for now).
I doubt we'll ever get a totally non-proprietary machine. But at least by having no more OS to firmware interfacing, we can eliminate some of the issues. And the extra control processor (something the later IBM mainframes already have many of anyway) will enhance the hardware support as well.
Beyond a free BIOS (Score:3, Interesting)
Re:You can't eliminate companies (Score:5, Interesting)
First, you seem to assume that there should be a license monoculture. While that eases the learning curve, it isn't necessarily realistic. Each of GPL and BSD licenses has its place today. The GPL works very well for projects that need to establish a "community space" for sharing work. It has been especially successful, IMO, in projects where many parties can come together to distribute the effort of "infrastructure" -- code that would otherwise be a cost-center for everyone involved. The Linux kernel itself is a great example of this. BSD is highly appropriate for projects that prioritize the utility of the work to all parties over the community sharing ethos. It proven to be especially relevant to reference implementations of standards, where acceptance and deployment of the standard itself is more important than any code that merely implements it.
Second, you ignore dual (or N-way) licensing. For example, the folks that released FFTW (Fastest Fourier Transform in the West) at MIT did so with the blessing of the university because they could dual license. Researchers and those willing to contribute back to the work as a community effort reaped the benefits, while commercial entities with different licensing needs could pay as usual.
The Zesiger License is an interesting compromise, but I'm unclear as to how it would work in practice. The GPL and BSD licenses have "social" properties that have proved very valuable to certain projects. Zesiger may simply be another point in a continuum, useful to some, less so to others. Also, it'd be nice if Zesiger or a variant had an escrow clause to help avoid "lost" code, e.g. because the company failed, creator had no backups and a hard drive crash one month before the release deadline, etc. Maybe extend SourceForge with "SourceVault" -- pages with little timers on 'em. 8-)
As some have pointed out, we need business models that will support all the kinds of works that developers produce and users require. Licenses themselves create community rules that support or inhibit certain kinds of interaction, and thus certain ways of users obtaining support and developers earning a living. While it'd be great to have a "silver bullet" license that found that mythical perfect balance, I'm not yet convinced that goal is practical or even possible.
Re:You can't eliminate companies (Score:2, Interesting)
"Requirement #3 under Getting a License Approved says Create a legal analysis of the license as it complies with the terms of the Open Source Definition...The analysis should come from a licensed practitioner of the law in your country. Fortunately, the Zesiger License is completely incompatible with that requirement since it's specifically designed to never need any "practitioners of law" in any country. It's an international license, so we're not to going even try to get legal opinions from every country in the world."
It's intended to be used internationally therefore they HAVEN'T taken legal advice anywhere at all? And you say this isn't insane? It's "designed to never need any 'practitioners of law' in any country"? Nice trick that. Doesn't really fit with your theory of the courts rejecting unsuitable retroactive changes.
I violated my warranty... (Score:2, Interesting)
Then I got a little nervous at the warnings that the update process couldn't be interrupted to avoid grave consequences. See, I didn't have a UPS, so I worried all through the update procedure.
Then it worked! There wasn't any discernible difference, though, and dang it if it still didn't recognize my drive. So I called Customer Support, and the polite woman asked, right off the bat, whether I'd flashed the BIOS. "Why, of course," I answered proudly, thinking I'd passed some kind of test that would otherwise have required me to admit that I hadn't, after which I'd have to call back, etc.
"Oh, I'm sorry, Sir. You've voided the support warranty. I'm afraid I can't help you."
Of course I started spluttering, and I even tried to deny that I had, but she was well-trained. And she already had the board's serial number.
Turned out I had a bad cable, anyway.
So I'm all for open-source BIOSes. And friendly support that charges a reasonable fee. And nice people everywhere. And the end of evil. And religious people who are also tolerant. And rainbows. And stuff that doesn't suck.
Re:Treacherous computing (Score:3, Interesting)
I've seen BIOS bugs in many, many machines, and it is a shame. Many drivers (and even the Linux Kernel, iirc) explicitly blacklist certain hardware because of bugs like this.
Why do we live like this? Capitalism is an opposing force to "correctness". I think Free Software is the ideal way to get to perfect software (excluding agreement among developers).
OpenBIOS is in the wild already... (Score:3, Interesting)
SUN Microsystems and Apple use OpenBIOS. Each
of these vendors, of course, use a different
implimentation which is at least partially
dependent upon the hardware supported. In each
case, it is possible to modify boot parameters
in a (more or less) English readable format, at
the boot console level. At the core of OpenBIOS
(OpenBOOT) is a Forth language bootstrap, which
by definition is extensible. (Various Forth
gurus state that the entire Forth language can
be built from 13 or 15 core commands.) It is
quite possible to extend the OpenBIOS/BOOT core
to support new hardware not envisioned during
OEM R&D.
Given the memory densities currently available,
there is no reason why any system board or chip
level manufacturer, including Intel, could not
offer their customers the flexibility of OpenBIOS.
IMHO, it really boils down to greed of certain
manufacturers - closed source and closed APIs
results in more new motherboard sales. This is
no different, really, than software OEMs that
push upgrades on their customers in leu of the
patches needed to fix bugs and vulnerabilities.
If I were shopping for an OEM system board for
any project that required long term support (like
aviation, spaceflight, military, financial), I
would tend to favor a hardware platform that had
the flexibility and extensibility of OpenBIOS.