[coreboot] coreboot certified hardware

Warren Turkal wt at penguintechs.org
Mon Oct 4 07:33:20 CEST 2010

On Sun, Oct 3, 2010 at 6:22 PM, Carl-Daniel Hailfinger
<c-d.hailfinger.devel.2006 at gmx.net> wrote:
> On 04.10.2010 02:11, Warren Turkal wrote:
>> 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.
> I think a few vendors ship some systems with coreboot if you ask nicely,
> but they are either in the server or embedded space, not general
> consumer space.

This is interesting news for me. I think that's really great.

>>> 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.
> OEMs want fire-and-forget solutions without functional regressions.
> coreboot can serve as fire-and-forget solution, but if we certify
> consumer mainboards which can't run Windows, the certificate will be
> essentially worthless.

I agree that OEMs would want that. However, I don't think that all the
coreboot developers could commit to that level of testing right now.
AFAICT, testing of any kind is very difficult to get done if I don't
own the affected hardware.

> Remember the complaints about "Designed for Windows Vista" and the
> machines which were too slow to be useful? People still remember that
> marketing disaster years after it happened. If we ever certify some
> hardware without caring about Windows, we should make that explicit, and
> call it a feature. "Coreboot certified board for the anti-closed-source
> movement, will refuse to run Windows".

First of all, I think you are attacking a straw man. My point has
nothing to do with being anti-closed-source. My point is that I don't
own a license for Windows and wouldn't be able to do the testing
necessary if that's a gate for certification. I have no problem with a
machine running Windows (or any other OS), but I don't think that
should be needed for for minimum compliance.

> The variant which can run Windows
> would be "Coreboot certified board". Except for niche vendors, nobody
> will care about the anti-closed-source certification, making it moot.

I just think that bar is too high to leverage the community of folks
that would like to see and even help coreboot progress.

>> Vendors do not ship coreboot yet.
> AFAIK Artec, Tyan, Technexion, MSI and some other vendors ship coreboot
> for specific systems on request. Not sure about the current state, but
> AFAIK they did that in the past.

With all due respect, I don't think this information has any bearing
on my position.

>> 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.
> Booting Windows 7 on recent consumer boards is probably the best way to
> show vendors that coreboot is a viable BIOS replacement. This needs
> porting work, and of course it needs testing.

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?

>> 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.
> Ummm... Linux will tolerate absolutely crappy ACPI code, and not even
> complain loudly if it has to fix stuff. Given the current market share
> of Linux, there is no money in verifying ACPI code under Linux for any
> consumer mainboard.

Fair enough, but it's certainly got to be better than not running any
OS on the machine as it does demonstrate some level of functionality.

>>> 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, "Developer's choice" implies that the board already works
> perfectly fine, and has all the hardware features which make it easy to
> test new coreboot versions.
> I believe in honest advertising, and if the machine barely works, we
> should not certify it, but we could list it as "fun project if you want
> to finish a port".

I agree that "Developer's choice" implies too much functionality. :)
However, I still think we need a way to invite more people and orgs
into the project. I think that we need some way to say that certain
boards are a good place to start for those looking to contribute.
Ideally, one day we won't even need this level of certification as
everything will just ship with coreboot. :)

>>> - 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.
> Nobody is going to test with Tseng Labs graphics cards because they are
> no longer on sale (actually, they haven't been on sale anytime in the
> last 12 years).
> Nobody is going to test with Intel graphics cards either unless you can
> actually show that such cards are on sale for mere mortals.
> So basically you have ATI(AMD) and Nvidia for external graphics, and
> maybe Matrox in niche markets.
> Intel and S3 and others are only available as onboard options.

I have an ATI PCIe card and would likely use that to test, but
requiring both ATI and Nvidia out of me is a little much.

>>> - 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.
> So FreeDOS would be OK for you? Small, free, and it will probably run
> just fine even if major parts of the board are malfunctioning because
> the port is unfinished.

To be clear, I think you are attacking another straw man. I
specifically suggested Debian of some form. I may not have been clear
with my reasons, so here they are: it does have a chance of having
drivers for the majority of the hardware, it uses more sophisticated
hardware initialization techniques, it's a well supported dev
environment for coreboot, and it's easy to find and download a legal
copy for free.

If there is software that can verify ACPI and other needed
functionality from FreeDOS, maybe it would make a good platform. I
honestly have no idea.

>> 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.
> But OEMs won't care unless we can make average users happy. If you want
> an OEM to ship coreboot by default, you better make sure the OEM won't
> fall into the Linux netbook trap where people returned lots of machines
> because they expected to be able to run Windows applications.

I am not denying that there is a demand for Windows. I am simply
saying that I would like to be able to participate in the
certification of board, and I don't have a copy of Windows to test

> OEMs are
> also extremely cost-conscious, and if they can save a few cents per
> board without risk, they will do it. The key words are "save money" and
> "no risk". Given the per-mainboard licensing cost for BIOS, coreboot can
> serve as an alternative if there is no risk involved.

Makes sense. However, I think that OEMs that need Windows can be sure
to certify their systems for Windows.

Also, I don't think that Windows support should be part of the base
certification as it alienates a number of people who are really
interested in seeing and helping coreboot succeed.

Also, I think that we should start pretty minimally as definitions can
be changed as time goes on, but I don't want us to bite off more than
we can chew and just abandon the effort as a result.


More information about the coreboot mailing list