[coreboot] coreboot certified hardware

[Warren Turkal]

On Sun, Oct 3, 2010 at 10:58 AM, phorsyon <phorsyon at gmx.net> wrote:
> I consider myself as enthusiast and would like to share my thoughts about
> coreboot certification and PR as a person from outside the coreboot project. I
> hope this will help you to see this project from another perspective and
> therefore helpful for your plans and further actions. Let me say I would
> really appreciate it, if vendors would ship their products preloaded with
> coreboot. ;-)

We are not vendors, and AFAIK no hardware OEM vendors ship with
coreboot pre-loaded.

> On Sunday 03 October 2010, Warren Turkal wrote:
*snip*

> At first it would be helpful to define what you would like to achieve by
> introducing a coreboot certificate. Helping developers to find boards, which
> have basic support (as described earlier) for easy further development or
> helping users/customers to find boards which are coreboot compatible?

I believe that is what this process is trying to do.

*snip*

> To make coreboot popular, it needs (a) a feature people want, (b) major
> vendors to deliver it and (c) available documentation for all components to
> make it work with most boards. These requirements are interdependent and must
> be solved as whole. To get c vendors must be convinced to want b and therefore
> coreboot needs a. So what's a? It surely is fast boot up, but depending on
> what your target audience is, it might also be boot non-free OSes and works
> with proprietary drivers. If you want to make vendors want b it's definitly
> required to target the average user.

I do not believe that (c) is strictly required in that you don't need
detailed bios developer guides once the code is available. It would be
useful, but I don't see it as being required.

We also need to be realistic. OEMs are not taking up coreboot in mass
right now. We need to set the certification bar at the point that it
would be useful for the coreboot project. I believe that setting the
certification bar allow a more rapid development of coreboot code
would be much more productive that pie-in-the-sky arguments about what
to do with all the OEMs that want to ship coreboot.

*snip*

> There is the possibility to depent on the vendors and the community. Vendors
> could test if non-free OSes work with coreboot (they test this anyway with
> their own BIOSes) and the community could assure this as well. That would
> require a place (e.g. the wiki) were the status of each board is tracked and
> an easy way to contribute. A Login would be required to keep the data on a
> sane level.

Vendors do not ship coreboot yet. I believe that we only have the
community at this point. Given that fact, we need to do what we can to
get vendors interested. I believe that maturing the coreboot codebase
is probably the most effective way to do that.

>> Ideally, having some OS independent test suite would be the best
>> approach I think, but I don't see that getting developed overnight. :)
>
> That's automation. Automation is the second step. ;-)

Indeed. For the record, I believe that Linux probably has a mature
enough ACPI stack and other systems to be pretty good barometer of
compliance short of having an independent test suite.

*snip*

> If you think of a little certification logo/mark that vendors print on their
> boxes, then it has to be as simple and clear as possible.

Agreed.

*snip description of coreboot minimal certification level*

> 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"?

*snip description of coreboot standard certification level*

> This would target the normal user, so I would call it "Coreboot compatible" or
> "Coreboot approved".

"Coreboot compatible" is probably a better choice. I like that better
than "standard."

> 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.

> - 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.

> - 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.

> - 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?

> 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
certification.

> - 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.

> - OSes besides the ones they use

Of course.

>> Tags could be used to identify specific extended support. For
>> instance, a system certified to boot Windows 7 could be "Coreboot
>> minimal+MSWin7" certified or "Coreboot standard+MSWin7" certified or
>> something like that. If anyone wanted to display the certification,
>> they could display it with or without the tags.
>>
>> Possible tags:
>> MSWin{XP,7}
>> ReactOS
>> GPXE
>> AOE
>> ISCSI
>> ...
>
> For OSes, users will expect that the major ones (BSD, Linux, Windows) will
> work flawlessy if labeled "Coreboot compatible". So if you focus on the average
> user, this should be respected. Listing the other features separately is a
> good idea, as normal users mostly won't care about them, but experienced users
> get the chance to check for them. To keep the logo itself simple, the feature
> list should be separated from the logo e.g. printed on the backside of a
> package. Or as mentioned above combined to another logo like "Coreboot for
> Professionals"

Frankly, I don't think that we are aiming for average users at this
time. We are aiming for the developers that can advocate coreboot's
use in OEM hardware or folks who see enough of an advantage to pay for
a port to their hardware. These are very sophisticated users.

*snip*

> 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.

> That's were vendors and community could help out. See above.

We don't have vendors shipping coreboot that I am aware of. From a
look at http://www.coreboot.org/Products, the closest we have is VIA,
and they aren't shipping coreboot on any systems that I know of.

*snip*

> That's why I would go for "Coreboot: Developer's Choice" and "Coreboot
> compatible" (or "Coreboot powered" for actual boards preloaded with coreboot),
> it makes it much clearer in my opinion. If there's one think you don't won't a
> certification mark to do, then it's confusing people more than helping them.

I agree that clarity is of the utmost importance. I also think that
"Coreboot: Developer's Choice

*snip*

>> While I agree with this, I think that a minimally certified piece of
>> hardware should not need working fan logic.
>
> True, developers should be able to deal with it, but for users it's a must
> have feature.

That's why I included that as part of the standard certification.

*snip*

> True, but to respect vendors and how they work (e.g. deadlines etc.), it would
> be clever to keep up a communication channel to announce e.g. "no certification
> from X to Y (due to $REASON)". This allows vendors to plan. The point being
> always try to work with, never against each other. ;-)

I think this is somewhat moot since we don't have vendors at this
point, but, of course, I believe that we should make this work with
vendors when they are ready.

>> If it really becomes a problem that vendors want the certification
>> during a time when Kevin isn't around, that would be a good problem
>> for the project to have. :)
>
> Yes that's somehow true, but to some extend this could also be considered
> mismanagement. To prevent those situations each vendor would have to have (at
> least) one employee to stay in contact with coreboot project, which would have
> to ask for one. Also interproject communication (e.g. between flashrom,
> coreboot and seabios) is vital. I can't tell how this works atm., I assume
> quite good, but what I'm trying to point out is, that vendors (and users) are
> always looking for a complete package to solve their problems. Therefore I
> consider the free boot up infrastructure, meaning flashrom, coreboot and
> seabios, as a whole package. This makes working hand in hand very important.

I don't think it's mismanagement unless we think that Kevin is away
enough to warrant adding others who can take this responsibility. If
that happens, it's a good problem to have, and I am sure we can modify
exactly what our definition of code state is to allow a certification.
If we start off with a more conservative definition and expand it in
the future, I think that'd be okay.

*snip*

> Please keep in mind that I'm neither involved in the coreboot project or any
> related projects nor do I work for a hardware vendor. I simply try to express
> how I see the whole picture with the hope this could be of any help for your
> project.

I definitely appreciate your PoV. I think we'll need a lot of
perspective to do something like this successfully.

Thanks,
wt