[coreboot] coreboot certified hardware

Carl-Daniel Hailfinger c-d.hailfinger.devel.2006 at gmx.net
Mon Oct 4 03:22:46 CEST 2010

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.

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

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

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

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

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

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

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

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

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



More information about the coreboot mailing list