[coreboot] coreboot certified hardware
phorsyon at gmx.net
Mon Oct 4 19:50:22 CEST 2010
On 04.10.2010 02:11, Warren Turkal wrote:
> > What about calling it "Coreboot: Developer's Choice". Also freely
> > available documentation would be a nice core requirement for that.
> I actually don't like "minimal." However, I also don't like "Coreboot:
> Developer's Choice." What would you think about "Coreboot beta test"?
For me "beta test" sounds like almost done, but needs testing. What about
simply calling it "Coreboot: Under development". I can't imagine it to be
printed on a box though, but as you said your're focussing on the community,
at least for now, a list in the wiki showing all certified products will be
> > This mark should assure that all parts of the board work,
> > meaning every feature, expected by the average user, hhis is important to
> > please them. So that this mark actually means something to them. If they
> > have a good reason to care about it, also the vendors have one, and this
> > would give the coreboot project the authority dictate such high
> > standards.
> > Things normal users care about to work:
> > - All build-in components (net, snd, gfx)
> I should have explicitly included this in the standard certification level.
> > - All ports/expansion slots (exceptions: rs232, parallel, floppy)
> Already said this in the standard certification level except that I
> didn't make any exceptions. It's sloppy to leave physical and header
> ports not working.
This probably was a little unclear. I meant to list what users expectations
are, but not what criteria for certification should be. From a technical
perspective I totally agree that every connector/header should be funtional.
> > - Everything related to power management as supported by the underlying
> > hardware and drivers (All power states, ACPI). Also needed to improve
> > drivers.
> For the record, I included this in the "better ACPI support" section
> of the standard certification. The OSPM part of ACPI includes all
> power states of all parts of the system.
> > - Add-on components most importantly Nvidia/ATI cards
> I don't believe that we should bias toward some particular class of
> add-on card or some vendor of add-on card.
As Carl-Daniel stated, there are practically just ATI/AMD and Nvidia. And I
also agree that it can't be expected every developer has both to test with.
But you are not the only dev, it's possible to delegate test to each other and
probalby to kreep track of that in the wiki. There is a testsystem:
I have not digged into it, but it's probably possible to extend it for semi-
automatic testing. So that if dev A has written code which also needs testing
for hardware only dev B has access to, dev A can call for dev B to test it. To
scale well such a system would require information about who has which
hardware to run tests on. This would allow for automatic notification.
> > - The OS of choice (BSD, Linux, Windows)
> While I agree with this sentiment, we can't test everything. I think
> that we should agree on a standard test OS. That OS needs to be freely
> obtainable to make the testing bar very low.
If that's for the development certification, I totally agree. I always had the
consumer in mind.
> > - fast booting
> I think this might be a little too subjective for certification. What
> if a server vendor wanted to ship coreboot firmware that does a
> longish running operation everytime before booting. Would that never
> qualify for a coreboot certification?
As mentioned above it's meant as user expectations not certification criteria.
> > Things normal users don't care about:
> > - most legacy stuff like rs232, parallel, floppy
> As stated above, I think that leaving ports with physical or header
> connections nonfunctional is just sloppy, and it would not reflect
> well on the project to allow board in that state to get a standard
> > - pro features like *PXE, AoE, iSCSI (Those could be combined under a
> > logo like "Coreboot for Professionals")
> I agree about things like PXE, AoE, and iSCSI being more important to
> big iron. I'm not sure that we should have another certification level
> to support them right out of the gate, however. More certification
> levels is more confusing.
Probably having these listed as separate features would be best.
> > Keeping track of detailed information in the wiki is a good thing. If
> > vendors decide to deliver coreboot it should be as easy as possible for
> > them.
> I am not sure this data is simple enough for wiki. However, I haven't
> given this too much thought.
It defintely would be helpful for new developers and leave a good impression to
verndors/OEMs. Right now it's not that easy for an outstanding person to tell
what works and how well (also e.g. has freely available documentations or
not). So improving infrastructure on this side will pay off, I guess.
I think of a combination of the automatic testing + semi-automatic testing as
described above and a status site to keep track of this details. For example
board $FOO has this components where this where tested an that not. Also
additional test like with works Nvidia or ATI GPU could be introduced. This
system could deliver all the status information needed, so anyone could tell
where the project stands. The lazy evaluation would allow to make good use of
the rare hardware around the developers. It's also an invitation for testers
only, as they would always know what still needs testing and do the test if
they find the time. This eliminates the need to setup the full automatic
testsystem, which apparently aims for vendors only. So you may want to think
that through. ;-)
On Monday 04 October 2010, Patrick Georgi wrote:
> Am 04.10.2010 07:33, schrieb Warren Turkal:
> > How do I show booting Windows 7 for a board I am working on? If I
> > can't because I don't have a license for Windows, should I not be able
> > to get the coreboot certification?
> That's the difference between a certification that's useful for vendors
> and one that's useful for computing enthusiasts.
Carl-Daniel and myself were refering to the former one and Warrens seems to
focus on the latter one. What do you think about doing one after another?
Start off with minimal certificate to attract more developers and call it e.g.
"Coreboot Beta Test" or "Coreboot under development". And at some later point,
if OEMs got interested, go for a consumer certificate like "Coreboot
compatible" or "Coreboot certified". The latter one should focus on the average
user's needs/expectations, delivering a fire-and-forget solution for OEMs. The
minimal certificate won't need to be printed on a box, as a product list on web
would do fine. This would also prevent later confusion due to having more than
one certificate logo out in the wild at the same time, as minimal and consumer
certification time periods may overlap.
> Whoever produces and sells boards will have some Windows 7 license (and
> probably the dev builds to improve testing, as well as the Microsoft
> test kits) lying around.
True, the OEMs are likely to help out on that matter.
> That means, certification would be for different purposes.. a "coreboot
> + Linux" certificate would state that the board is actually useful
> beyond freedos (eg. networking works, HPET is around, ACPI is at least
> somewhat useful, even if Linux's ACPI interpreter is more forgiving than
> A "coreboot + Windows" certificate could build onto that, stating that
> Windows operation was tested, too. Stacking them this way would ensure
> that Windows support doesn't break Linux (or any other free OS).
A "Coreboot + $OS" logo could give a bad impression, as it will look like
coreboot can only boot a specific OS. So a minimal and a consumer version of a
certificate, where only the latter one would be printed on the box would have a
more to-the-point expression to others.
> But vendors will (except for some specialty shops or special customer
> requests) require the latter - with no regard for the former, except
> maybe to assess how much work they'd have to put in/sponsor to make a
> coreboot port Windows compatible.
> As a side note on "Windows compatible", I'm not 100% sure on this, but I
> think the "Designed for Windows" set of certificates by Microsoft handle
> firmware behaviour, too.
This certaintly has the potential to threaten a coreboot certification. Even if
there's no criteria now, Microsoft could add one to prevent OEMs to certify
for both Windows and Coreboot at the same time. When the time comes for a
coreboot consumer certificate some investigation on that matter is needed too.
More information about the coreboot