Slashdot Mirror
AMD Provides Fusion Support For Coreboot
An anonymous reader writes "AMD has done a big code drop providing Fusion support for Coreboot, the project that once was called LinuxBIOS for providing an open source BIOS implementation."
A lack of vendor support has long made the task of the coreboot developers difficult. Support for what is slated to be a common chipset is pretty encouraging, and will hopefully make it easier to run an entirely Free Software system for diehards like RMS.
What's this? A Phoronix article where I _don't_ have to click through eleven other articles to find the source?
Other than that: Hopefully this will make coreboot's future brighter, by a lot.
Open source altruism aside, i want a stable, flexible, fast-booting BIOS. The standard BIOS that comes with most motherboards is awful, and is frequently missing important features.
I'm not qualified to say how much exactly this amounts to, but I think even just the willingness to contribute something to an open BIOS implementation is very commendable.
Maybe more hardware will come with gPXE and memtest and correct(!) ACPI information some time in the future.
Does this mean Parallels already supports Coreboot?
"system for diehards like RMS" and me
"The Brady Bunch is back...working homicide"
I think even just the willingness to contribute something to an open BIOS implementation is very commendable.
Additionally, it could be a smart move for AMD. A FOSS BIOS could give them a competitive advantage in sales, as the only/first manufacturer of modern high-end chipsets enabling personal computer products where a full code audit or replacement with user-trusted secure code would be practical.
Compare this to Intel, which includes support for remote administration in the chips, BIOS, and network adapter firmware - as a "feature". This runs under the OS, invisible to it if desired and unstoppable, and provides a hardware man-in-the-middle that can completely control the system - even "phoning home" when traveling or at an IP address not previously known to the "remote administrator".
Bantam Dominique roosters crow a four-note song. Once you've heard it as "Happy BIRTHday" you can't NOT hear it that way
That's very nice. Of course, there's more to motherboard support than the chipset and CPU, but they are two major hurdles.
"You're right," Fisheye says. "I should have set it on 'whip' or 'chop.'"
Or some other "architecturally pure" design?? :)
Though I kind of agree with you, keep 32bit mode.
>will hopefully make it easier to run an entirely Free Software system for diehards like RMS.
Whut? you do NOT have to be a "diehard like RMS" to want a system that boots nearly instantly, or a system that allows you to set default power management values before the OS comes up, or a system that makes bios updates via network easy (clusters comes to mind), or make BIOS changes without a monitor hooked up etc etc.
If you bothered to look at the technical reasons to run Coreboot rather than trying to sneak in covert FSF alienating messages, you would find that there are quite a few. In fact, the majority of the core developers of coreboot happen lean towards the "open-source-mythology-rather-than-free-software-philosophy"-end of the scale, and would rather not be associated with the FSF's campaigns against software patents.
Personally I do happen to be one of those "diehards like RMS", but I do understand and respect that what makes a lot of my fellow computer users tick are hard technical facts... and they tend to drool when they see Coreboot in action... for its technical merits and that alone.
It may come as a surprise, but right now, someone else owns your entire platform. The BIOS/EFI do not merely boot the system, they also provide run time services in the form of System Management Mode.
That's right, your system is running black box code at runtime. The TPM already lives there, and if you are "lucky", the future malware will be limited to DRM which can't be circumvented, or systems that only run signed code. The implications for security are staggering, and considering that modern systems even have access to your network from this code, the opportunity for abuse is truly frightening. (How trivial would it be for your government--or the manufacturers in China--to install backdoors, remote key logging facilities, or root kits and such?)
Support Coreboot, so that we may retain control of our own systems. Many thanks to its authors for their persistence, and AMD for their generous contributions. For further information, there was also an interesting google talk a while back.
The first brand(s) to offer an open BIOS will win new customers, and if they do it right, loyal customers.
"I can't imagine how things could get any worse!" (some guy) "That could just be failure of imaginatioÂn on your p
Screw the paranoia and extremist ideology... I WANT REMOTE MANAGEMENT, DAMMIT.
Maybe 15 years ago, x86 was the red-headed step child... the ONE hardware platform without out-of-band management built-in. Every other platform out there redirected the IO on boot-up to the first serial port, at least if it didn't detect a keyboard plugged-in. And you know what? You could configure every damn option the hardware had, at that first firmware command-prompt, over the serial port. Hell, I ran numerous servers that would never, ever get a video card plugged in...
After that, as x86 continued to grow in popularity, serial port management was added to higher-end, server-class hardware, and trickled down to most servers. But it was always implemented in the most horrible way possible, requiring the cooperation of the video chipset, and still missing many features. And worst of all, often missing the big ones, like having a BREAK signal sent over the serial port power-cycle the hardware, requiring managed PDUs, higher end servers, or more add-on hardware...
Today, it still hasn't damn well been sorted out. Want remote management? Buy a system-specific add-in card from the manufacturer! This is iLO with HP and DRAC with Dell systems. Then run a second set of ethernet switches to each and every system to handle those. And on top of that, better throw-in an IP KVM, too, because those add-in cards do occasionally stop responding all together.
The one sign of light in all of this has been open-source boot-loaders. Lilo, grub, boot0 (fbsd), biosboot (obsd), etc. All can be configured to hand-off full console access/control to the serial port immediately after they are loaded. Additionally, the long-overdue widespread adoption of PXE boot firmware on NICs has made it possible to boot to one of these loaders (usually grub) so the MBR doesn't even need to be there.
Yet, after all these years of this blindingly-obvious missing feature, I still find myself having to buy iLOs, DRACs, or high-end PDUs, just so I can be sure I'll be able to send the power-cycle signal the one time in a million I need it. Linux's magic-sysrq moves us yet a little closer to eliminating this nonsense, but yet we can't seem to ever get there. If nothing else, we still risk being at the mercy of those dammed CMOS checksum failures that dump un-desirable defaults on us.
I want openbios so that I can take any PC I run across (no matter how low-end) drop it in the data-center, plugged-in to power, network, and a terminal server, and know I'll never need to run back out to pull the power on the damn thing. It costs next to nothing to add these features. It was done, prolifically, with non-x86 hardware decades ago, and yet we can't seem to get it done, as everybody wants the extra money and lock-in of their proprietary add-on to do something so simple... and with that comes vast added complexity (setting-up serial-port loopback over ethernet to support my OOB management card? WTF?)
Seriously, it's long past due.
And before I ask for a pony, can we get some movement on developing a standard management interface for a post RS-232 world? I'm fine with the firmware stealing an ethernet port for the job, but do it in some very simple and standard way... no more eye-candy java applets required to manage hundreds of servers, okay? I know execs like the aesthetics of of it, but they also like it when a required feature for each and every server they buy will cost them $50 instead of $500.
I know, spend enough money on the server, and the price of the OOBM isn't significant... yet the overhead of managing them, in all their proprietary glory, is. And besides, I have a moral objection to expensive, complex solutions with features I don't need, and that don't entirely work, when a cheap and simple 100% solution was there before, and would be dammed-easy to put back.
Am I the only one bothered by the regression of OOBM?
Slashdot gets worse every day... Pipedot: News for nerds, without the corporate slant