“Intel is pleased to announce the BIOS Implementation Test Suite, a bootable pre-OS environment for testing BIOSes and in particular their initialization of Intel processors, hardware, and technologies. BITS can verify your BIOS against many Intel recommendations. In addition, BITS includes Intel’s official reference code as provided to BIOS, which you can use to override your BIOS’s hardware initialization with a known-good configuration, and then boot an OS.”
This is a pretty awesome bootloader.
If it can indeed completely bypass the bios, I’m now settled on Core i# for my next mobo.
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
It’s the possibility of it being forked/used in other tools that interests me.
The original intent of any bit of code isn’t necessarily the end result.
What’s this AMD project that allows one to bypass/alter the settings made by proprietary BIOS code with an open solution and requires no hardware modification?
I’d be interested to see it.
Barking sarcasm rather than sharing information seems rather counter-productive.
I have to admit I merely did a quick Google search for “BIOS test suite” and found a few references to such solutions, from AMD, AMI, Award, Intel, and a few others. Looking further I see only two posts anywhere directly related to AMD’s BIOSTestSuite.exe and have found no other information… so for whatever good that might be… ( none it seems, so I’ll just give this one to Intel ).
My overriding point remains the same: the test suite itself is only useful for very few, as is its code.
The fundamental problem resides in the extreme variability of hardware configurations which may exist on a motherboard. Adding a certain model of a certain type of chip may require a few initialization changes, or else the chip does not function properly. That means using Intel’s reference code may not be a viable option for a given motherboard. The results could be completely unpredictable.
Intel’s reference code may merely prevent a temp monitoring chip from working, or it may prevent an important add-on chip such as an IDE or SATA controller from working, a risk you can’t take in most projects.
And that is the best case scenario, there are, undoubtedly, a few outside cases where damage could occur on some more liberal designs.
Not saying that is likely, but it is possible, the risk of which will prevent widespread use of this code – even in cases where it might be useful
So, once again, I don’t see how a BIOS Test Suite could make your choice for platforms on its own merits. Unless, that is, you were a BIOS/kernel/driver developer, then I could easily understand.
Not saying don’t go Intel, mind you, they have some awesome hardware on the CPU side.. though I really don’t like their chip-set offerings. AMD wins in that regard, IMHO, and we’ll see what Bulldozer offers around April/May/June…
Just saying I think your putting too much weight on this project’s effect on the platform. It will have a positive effect, but it will be years down the road, and won’t be universal.
It does offer an interesting potential for repairing faulty BIOS implementations, or re-enabling functionality in an OEM BIOS in a safer manner than today. But, that goes back to being a BIOS developer, I guess…
BTW, I have to keep spare BIOS chips around because of my occasionally faulty BIOS modifications. I would actually benefit from this project, and am adding it to the strengths of an Intel platform.
For me, it makes sense… I hate exposing the code changes straight to hardware for testing after only some rudimentary checks ( mostly I just change boot logos, and lighten the footprint of certain routines – I’m a binary hacker after-all – or add features from other similar, but more expensive, motherboards ) and I hate needing to re-flash the BIOS to test a simple little change – this product could certainly help me out.
But I don’t see how it would help you out.
–The loon
Edited 2011-02-27 08:10 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
So you still haven’t read the specifications.
‘kay.
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.
Wouldn’t it be better to begin phasing out BIOS in favor of UEFI instead of creating yet more tools for BIOS?
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 ?
hopefully. I might just play around with it now.