[coreboot] coreboot certified hardware

[phorsyon]

Hi!

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

On Sunday 03 October 2010, Warren Turkal wrote:
> 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.

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?

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

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.

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

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.

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

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

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. 

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

What about calling it "Coreboot: Developer's Choice". Also freely available 
documentation would be a nice core requirement for that.

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

This would target the normal user, so I would call it "Coreboot compatible" or 
"Coreboot approved". 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)
- All ports/expansion slots (exceptions: rs232, parallel, floppy)
- Everything related to power management as supported by the underlying 
hardware and drivers (All power states, ACPI). Also needed to improve drivers.
- Add-on components most importantly Nvidia/ATI cards
- The OS of choice (BSD, Linux, Windows)
- fast booting

Things normal users don't care about:
- most legacy stuff like rs232, parallel, floppy
- pro features like *PXE, AoE, iSCSI (Those could be combined under a logo 
like "Coreboot for Professionals")
- OSes besides the ones they use

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

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

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.

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

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

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

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.

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

Agreed.

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

True, developers should be able to deal with it, but for users it's a must 
have feature.

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

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

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

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

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.

Thanks,
phorsyon