OSNews

It's a BIOS validation suite, essentially. It allows board makers & kernel/driver developers to communicate more efficiently by permitting kernel/driver developers access to standard hardware initialization code from Intel in lieu of whatever code is being used by the motherboard used for development.

This is really just a way to keep motherboard venders from straying from the Intel reference by too much, which has advantages for stability and disadvantages for some forms of innovation.

This won't be replacing the BIOS, but may prove useful in running certain OSes on motherboards with non-standard BIOS setups ( read: Haiku ), though that really depends on the overall flexibility of the test suite.

Interjecting custom code would prove useful for only a select few, namely those I've mentioned.

Not really a platform selling point, IMHO.

--The loon

"likely slightly more cool" is enough to sway me from "equal" vs the AMD boards I was looking at.

AMD just added support (working code) for Fam14h CPUs and chipsets to coreboot, while Intel needs enormous pressure to give a few select coreboot developers NDA access to hardware documentation to do the work.

Ah, but do any consumer-grade AMD boards work with coreboot? I'm not setting up a cluster, I'm setting up a workstation.

A BIOS is not a bootloader. I fail to see what difference a BIOS implementation test suite can possibly make to someone purchasing a single workstation.

A number of OS developers who've lived in hatred of the thing for decades disagree with that.
Gee, a bootloader that allows one to completely customise the boot process and replace behaviour set by the vendor of your motherboard... yeah, that sounds completely useless.

But that is not what we are talking about here.

We are talking about a test suite to ensure the viability of the BIOS configuration on Intel hardware. Frankly I'm surprised this hasn't been done before...

Oh wait!! It has... by AMD, no less...

So, now, would you prefer the one who did it first, and has a more mature solution, or the last one to the party?

In any event, this has little benefit to the end user, it is useful for the BIOS authors, and OS developers. It merely makes it easier for people to stay on the same page - not that people like to do that, they just have no choice.

The only case where an end-user could find this useful is if they know the intimate details of how their motherboards are designed AND the issues involved with supporting some obscure operating system. That is the only case I can see. And that only exists because the test suite permits live code injection and hardware re-initialization, thereby overriding possibly flawed BIOS logic / init routines.

That is all.

--The loon

EDIT: embedded quotes... grrr...

Edited 2011-02-27 04:26 UTC

... in other words, you have no clue what a "BIOS test suite" is, does, or what it even implies.

But don't let that stop you from voicing your strong opinion in the matter.


*sigh*

Edited 2011-02-27 09:22 UTC

Also, I don't think you read all the things this is claiming to be capable of doing, like altering the settings made by the BIOS, and not being a binary blob soldered to your motherboard.
Seriously, just because that's the intended purpose doesn't mean that's the only possible use.

GNU Screen was originally intended to add the ability to run multiple programs while on a single serial terminal, but today it's mostly used for its ability to detach and continue running, and it's also been the inspiration for a number of 'run and detach' programs.

In any case, the code looks greatly interesting.

Let's see, I have a SSD in my desktop machine and Ubuntu with me logging in and starting up some applications takes less time to load than the BIOS.

A simpler, slimmer BIOS is definitely something I would want. I think coreboot even can do initialization in parallel so that should really help startup performance.

Linux really needs very little BIOS anyway.

So yes, Coreboot is something I would consider if it was available for my chipset for my desktop machine.

Asrock E350M1 is work in progress, and that's hardly a cluster system.

Cool, but "a work in progress" is still... that.

The only thing worse than the BIOS is UEFI.
Yeah, I want big-content spyware (DRM et al) running _underneath_ my OS with full access to the network.

Don't be so much of a paranoid, big companies and/or governments will never spy on your personal data without you knowing, never. Oh, wait...

Kochise

So thats whats happening with my Macbook Pro ATM, quick trash it! /Sarcasm

Um... Yes. That's what's happening.
Is it affecting you in any meaningful way? Well, there's no way to tell, as it has full control over what your OS has access to.
You'd have to monitor that machine with another one, monitor the all packets sent in/out...

Seriously, what's with the sarcasm. So you don't care. Why chime in?

Well, EFI is not perfect but it is a step above BIOS.

I'm tired of having to boot from MBR (do any bioses support gpt partioning?)

Or that boot partitions have to be in the 1st 128 GB of the hard drive or else the drive will not boot.

Who says that efi has to have drm? Mine certainly doesn't. Get me a BIOS that does those two things above and I'll stop complaining.

Edited 2011-02-27 11:26 UTC

BIOSes generally don't care about partitioning (There are a few broken ones that do).
What they care about is that the bootblock is the first sector of the disk, and that's possible within GPT.

After the bootblock is loaded, BIOS only answers requests for sector reads, and supports up to 128PiB there.

Here we find some common ground. UEFI scares me. That much power that close to the hardware is a very dangerous consideration.

The more standardized the interface the more simple it is to exploit.

That said, any UEFI implementation that I would care to use would provide me with full unfettered access to the ROM and would provide a hardware-based lock-out ( a jumper ). That way I could have the best of all worlds, an extremely powerful BIOS replacement, and the security of an immutable UEFI configuration.

UEFI also has what appears to be a nice test suite... ;-)

--The loon

Are you so eager to replace an open but messy standard with a standard that'll be just as messy in the long run but is also a patent minefield as a bonus feature ?