[coreboot] coreboot certified hardware

[Warren Turkal]

On Sat, Oct 2, 2010 at 5:06 PM, Carl-Daniel Hailfinger
<c-d.hailfinger.devel.2006 at gmx.net> wrote:
> On 03.10.2010 01:28, Warren Turkal wrote:
>> I think that a base coreboot certification should basically state that
>> all the hardware on the board is usable with a major free OS (e.g.
>> Linux-based OSes like Debian, Ubuntu, and Redhat maybe).
>>
>> We could maybe have extended certifications for things like non-free
>> OS and driver compatibility.
>>
>
> 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.

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.

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

> Windows support means a board is usable by the general population, and
> this is something vendors care about deeply.

Out of curiosity, are there actually non-niche vendors that ship
Coreboot as their system firmware?

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

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.

Ideally, having some OS independent test suite would be the best
approach I think, but I don't see that getting developed overnight. :)

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.

Think of "Coreboot minimal" as enough to conveniently develop coreboot
further without expensive and specialized hardware. Its requirement
might look like the following:
* Full initialization of the cpu and supporting chipset
  - Intialized RAM
  - Cooling systems should work enough to protect the system from
burning itself up
* At least one of the following:
  - Outputs reasonable POST codes to a POST card if one can be plugged in
  - USB debug ports enabled, if available on the board
  - RS232 port enabled, if available on board
  - Some other agreed method for debugging the system during Coreboot
execution (e.g. debug LEDs on mobo, etc.)
* At least one of the following
  - At least one usb hub usable for keyboard, if one exists
  - PS/2 port usable for keyboard, if one exists
* All expansion slots initialized and usable
* ACPI
  - DSDT should exist
* Able to load VGA option ROM
* 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.

Think of "Coreboot Standard" as basically fully tested with free OSes.
Its requirements might look like the following:
* all requirements of the minimal certification
* Any requirement of the minimal certification that allows a subset to
be implemented should implement all the sub-items. For example, both
rs232 and usb debug ports should be enabled if they exists on the same
board instead of implementing one or the other.
* Uses tiny bootblock
* Uses cache-as-ram if the system is capable
* Soft poweroff works
* Extended initialization of supporting chipset
  - Fan uses vary speed based on temperature of CPU
* All legacy io ports (i.e. rs232, parallel, etc.) usable
* All USB ports usable
* All other external (including header) ports usable (e.g. firewire,
sound, etc.)
* better ACPI support
 - OSPM (e.g. G, S, D, and C states, etc.) fully exposed and usable
* CPU frequency scaling works
* After booting into Debian Linux, the OS should be able to rely on
any info provided by the Coreboot and any intervening payloads should
allow the system to be fully enumerated and configured as much as the
hardware will allow.

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

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

The numbers are the Coreboot svn revisions that are tested. These
revisions should probably be listed in the wiki somewhere. There is
probably some better way to visualize the data. We may also need to
list SeaBIOS hashes for the certified builds.

*snip*

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

Given the fact that we can't test everything, we should make a minimal
amount of compliance only include things that can be tested by most
folks. I think that minimally certified hardware should really be
capable enough to develop Coreboot further on the hardware
conveniently. Standard certified hardware should work well for free
OSes if the OSes have appropriate driver support.

Also, minimally certified hardware can support more features. For
example, a minimally certified board could have logic for adjusting
fan speed intelligently. It would still be minimally certified until
someone developed the rest of the functionality for the standard level
certification and tested it.

*snip*

> Fans can be loud. If all fans run at 100% non-stop, machines can be
> essentially unusable for noise reasons.

While I agree with this, I think that a minimally certified piece of
hardware should not need working fan logic.

*snip*

> Indeed, but given that vendor code may not always be suitable for
> merging, do we want to withhold certification if code is available but
> not merged? And what happens if Kevin is on vacation?

If the code's not merged into SeaBIOS, we shouldn't certify the build.
If Kevin is the only person that can merge push the canonical SeaBIOS
tree, then I suppose it would need to wait on him. It's the same way
that a vendor can't really claim that their hardware with compliant
with Microsoft's certifications until MS signs off.

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

*snip*

Comments would be appreciated, especially on the minimal and standard
certification requirements above. Also, please take a look at the tags
and see if you can think of any additions.

Thanks,
wt