[coreboot] coreboot certified hardware
xdrudis at tinet.cat
Sun Oct 3 21:28:39 CEST 2010
My .02 from an end user (wannabe) pov:
In general I agree with Warren Turkal:
I'd like a certification that ensures coreboot and free sofware work
with the hardware, irrelevant of what happens with non-free
software. I don't mind having other certification (tags) for non-free
software for whoever cares about it. What I would regret having less
hardware certified because there wasn't a certification option for
free software uses. Coreboot is good for many things and one of them
is getting rid of legacy where possible. Requiring everyone to support
legacy just because it is a current big market segment will only
perpetuate this legacy burdened market. The argument works exchanging
non-free software with legacy, only that non-free software is nastier
than legacy. So legacy, nonfre-software should be optional for certification.
Free software support should be required for any certification,
then some would also tag windows7 or whatever.
It would require some credible organization doing the tests, I
guess. Or maybe it would be a kind of trust system ? (the different
certificates and their exact meaning would be clear, then anyone could
certify some hard and customers would decide whether they believe a
certificate signed by one or other party, or even self signed by
The tests should be reproducible, so the exact versions of kernel,
distribution, etc. should be stated, even if a particular choice is
not a requirement, documenting the choice tested should be.
There should be non-technical requirements too:
- support code GPLed and integrated
- maybe security criteria ? I don't know about it
- something on availability of the tested hardware ?
A problem I can see is what gets certified precisely . a mainboard?
a whole computer ? whatever as long as it is clearly stated ?
My experience is that of a consumer trying to buy hardware to
use with coreboot. I picked every component in my new PC according
to price, the performance I wanted and the information on coreboot.org,
more or less accepting the risk for the parts apparently less well
And I mostly got what I expected except partly with the CPU.
I would have liked more precise lists of what CPU models have
been tested. I can't be sure but I suspect that my particular CPU wouldn't
work on any supported mainboard right now (well, not even the shipped
BIOS worked until I upgraded it). I've found out that the
information on documentation of the CPU was accurate, an so it is
just a matter of time/effort until it works, but the
site gave the impression that any AMD CPU would work (there were lists
of mainboards and chipsets, but the CPU part was not very detailed, beyond
brand or family). Then looking at the code I found some revisions didn't
even have a position in a bitfield.
What I mean is that if it is a board that gets certified, then a customer
may buy it and put a new CPU there that doesn't work with coreboot. It may
happen with other hardware, but I can't think of any example. Maybe RAM ?
On Sun, Oct 03, 2010 at 02:15:44AM -0700, Warren Turkal wrote:
> On Sat, Oct 2, 2010 at 5:06 PM, Carl-Daniel Hailfinger
> <c-d.hailfinger.devel.2006 at gmx.net> wrote:
> > Well, if we only care about Linux, you can avoid most (if not all) of
> > ACPI on many machines, and you can avoid SeaBIOS as well. Heck, you
> > could even avoid FILO and require a Linux kernel in flash. Whether such
> > ab board would be usable for end users is a totally different question.
So what ? If a consumer can buy a system with coreboot and gnu and linux
that works and gives her all due freedoms why should she care for ACPI,etc?
I understand most users will want more, I just wouldn't rule out a certificate
option unrelated to legacy or current standards. Maybe some vendor wants
to offer some advanced features that is too cumbersome to adapt to ACPI...
Or open hardware vendors may opt for just skipping ACPI and just giving
the hardware details and linux drivers...
> Booting into a certain OS is clearly not the only bar that we should
> be looking for. It would need to comply with various standards like
> ACPI, etc.
It might be one of the bars. On the other hand ACPI compliance could
be certified by the ACPI consortium (there is one, I guess...), maybe .
Likewise for any other standard.
> > IMHO being able to install a Linux distribution from CD is an absolute
> > must even if you only target professional users in clusters etc.
> I agree.
I agree one of the certification options should require it
> > Windows support means a board is usable by the general population, and
> > this is something vendors care about deeply.
And is something we don't need to help stay the same. So I say require it
only for some of the optional tags.
> > We renamed LinuxBIOS to
> > coreboot exactly because people said all the time "I don't want Linux",
> > and EFI marketing would love to make fun of us if we ever said "Linux
> > only is good enough for certification".
Laughing is healthy. Let them laugh.
I don't see the marketing problem if there are windows tags.
> I believe that most of the folks who care enough to use Coreboot at
> this time are probably running Linux or some other free OS. I also
> believe that most developers who have access to systems are probably
> running on or have easy access to some free OS. I also know that
> non-free OSes are not easily available to everyone. It's not that I
> believe that we can't test for non-free software support. It's just
> that I believe that certifying the boards for Coreboot should not gate
> on that having been done.
Well, if A wants B to certify that coreboot supports OS W
on hardware H I guess A should contribute any changes to coreboot and
give B the hardware H and the necessary W licenses, if A can find some
B willing to use W. If W was free software the requirement would be
the same but it'd be much easier to comply with. If W license was
particulary nasty it might even be impossible to use W for testing
But A shouldn't be required to have any deal with windows to certificate
coreboot works in H without windows. SO corebot+windows certification
should generally be more expensive/cumbersome than
coreboot+freesoftware certification only (depending on the case, maybe
coreboot+hurd may be difficult to certify...). Sounds logical.
> Ideally, having some OS independent test suite would be the best
> approach I think, but I don't see that getting developed overnight. :)
Is that feasible at all?
> Maybe we should have multiple compliance levels like "Coreboot
> minimal" and "Coreboot standard"? The minimal could be some set of
> requirements. The standard could be the minimal requirements plus some
> extra set of requirements. We could also have tags for the compliance.
> These could be used to indicate special support like Windows or
> something like that.
> * ACPI
> - DSDT should exist
Is that needed to develop coreboot further ? Not sure it should be
required for minimal. Maybe split minimal and minimal + DSDT
> * Able to load VGA option ROM
unless they find a way not to use it, like free framebuffer drivers
or so on ? If propietary software is not a requirement, propietary
firmware shouldn't either, whenever it can be worked around.
> * Able to boot into an OS not stored as a coreboot payload (e.g. boot
> from CD, USB, or SATA drive). For the minimal certfication, I believe
> that OS should be Debian since it's a well supported environment for
> developing coreboot.
I would simply say that it should boot a system that allows coreboot
development using only free software, and it should document which precise system,
version, etc. it is. Of course depending on what it is it may be easier
or harder to find certifiers (or customers once certified).
And then we come to the thorny issue of what does "only free software" mean,
since debian for instance includes kernel blobs or similar issues...
> Possible tags:
The process for adding tags to the certification criteria should be
clear and simple. We won't be able to find all useful tags from the
Something about power saving capabilities would be useful, not sure
what or how...
> We should probably note the known revisions that are compliant for
> each board. This doesn't mean that every revision that would pass the
> requirements needs to be listed. Only tested versions should be
> listed. Those revisions would be the recommended revisions with users
> using other revisions at their own risk. I could imagine something
> like the following for a mobo:
> minimal: 11 99 103 150
> standard: 50 75 135 155
> minimal+Win7: 77
Ok. Adding the rest of hardware and software tested, like
Debian lenny , AMD Phenom II X4 910e, such and such DDR3 DIMMs,
The more diverse hardware and software tested the more work
to certify it, and the more tempting for consumers, who would
evaluate the risk of using it with other hardware or software.
One could risk buying a certified system with different amount
of RAM than tested and install a different distribution, etc.
> >> Frankly, I think that ability to use the free drivers should be good
> >> enough. We shouldn't be hold out any kind of coreboot certification on
> >> the condition that non-free drivers work.
> > There are two aspects of the problem:
> > - We can't test everything (fact of life)
> > - Closed-source drivers have a huge market share, and won't go away any
> > time soon
> Agreed. I also think that some developers won't be able to test
> certain non-free software. For instance, I wouldn't be able to test
> that Windows 7 boots. I also don't have an Nvidia card to test their
And if you test and find that it doesn't work with non-free drivers,
that is an answer, but not very productive, is there a problem in some
initialisation in coreboot or in the driver? You can't fix the driver,
so supporting it is a tall order, so optional.
> If the code's not merged into SeaBIOS, we shouldn't certify the build.
Yes. Not sure SeaBIOS is needed for the most basic certification,
but in general if any support code is not commited then certification
should wait. Not sure this is a huge problem, I'd say one wants to
benefit from the community testing stuff before paying or otherwise
causing someone to thoroughly test for certification. So waiting
until a little after committed would be wise. Although I guess
hardware is obsoleted quickly and vendors may want certification
before they put it on the market... so I don't know how much of a
burden this is, but I think it should be required. If Google Summer
of Code candidates where required to send patches, vendors should
be required to have support code good enough for being merged.
Sorry for being verbose.
More information about the coreboot