My .02 from an end user (wannabe) pov:
In general I agree with Warren Turkal:
I'd like a certification that ensures coreboot and free sofware work with the hardware, irrelevant of what happens with non-free software. I don't mind having other certification (tags) for non-free software for whoever cares about it. What I would regret having less hardware certified because there wasn't a certification option for free software uses. Coreboot is good for many things and one of them is getting rid of legacy where possible. Requiring everyone to support legacy just because it is a current big market segment will only perpetuate this legacy burdened market. The argument works exchanging non-free software with legacy, only that non-free software is nastier than legacy. So legacy, nonfre-software should be optional for certification. Free software support should be required for any certification, then some would also tag windows7 or whatever.
It would require some credible organization doing the tests, I guess. Or maybe it would be a kind of trust system ? (the different certificates and their exact meaning would be clear, then anyone could certify some hard and customers would decide whether they believe a certificate signed by one or other party, or even self signed by a vendor).
The tests should be reproducible, so the exact versions of kernel, distribution, etc. should be stated, even if a particular choice is not a requirement, documenting the choice tested should be.
There should be non-technical requirements too: - support code GPLed and integrated - maybe security criteria ? I don't know about it - something on availability of the tested hardware ?
A problem I can see is what gets certified precisely . a mainboard? a whole computer ? whatever as long as it is clearly stated ?
My experience is that of a consumer trying to buy hardware to use with coreboot. I picked every component in my new PC according to price, the performance I wanted and the information on coreboot.org, more or less accepting the risk for the parts apparently less well supported.
And I mostly got what I expected except partly with the CPU. I would have liked more precise lists of what CPU models have been tested. I can't be sure but I suspect that my particular CPU wouldn't work on any supported mainboard right now (well, not even the shipped BIOS worked until I upgraded it). I've found out that the information on documentation of the CPU was accurate, an so it is just a matter of time/effort until it works, but the site gave the impression that any AMD CPU would work (there were lists of mainboards and chipsets, but the CPU part was not very detailed, beyond brand or family). Then looking at the code I found some revisions didn't even have a position in a bitfield.
What I mean is that if it is a board that gets certified, then a customer may buy it and put a new CPU there that doesn't work with coreboot. It may happen with other hardware, but I can't think of any example. Maybe RAM ?
On Sun, Oct 03, 2010 at 02:15:44AM -0700, Warren Turkal wrote:
On Sat, Oct 2, 2010 at 5:06 PM, Carl-Daniel Hailfinger c-d.hailfinger.devel.2006@gmx.net wrote:
[...]
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.
So what ? If a consumer can buy a system with coreboot and gnu and linux that works and gives her all due freedoms why should she care for ACPI,etc?
I understand most users will want more, I just wouldn't rule out a certificate option unrelated to legacy or current standards. Maybe some vendor wants to offer some advanced features that is too cumbersome to adapt to ACPI... Or open hardware vendors may opt for just skipping ACPI and just giving the hardware details and linux drivers...
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.
It might be one of the bars. On the other hand ACPI compliance could be certified by the ACPI consortium (there is one, I guess...), maybe . Likewise for any other standard.
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.
I agree one of the certification options should require it
Windows support means a board is usable by the general population, and this is something vendors care about deeply.
And is something we don't need to help stay the same. So I say require it only for some of the optional tags.
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".
Laughing is healthy. Let them laugh. I don't see the marketing problem if there are windows tags.
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.
Well, if A wants B to certify that coreboot supports OS W on hardware H I guess A should contribute any changes to coreboot and give B the hardware H and the necessary W licenses, if A can find some B willing to use W. If W was free software the requirement would be the same but it'd be much easier to comply with. If W license was particulary nasty it might even be impossible to use W for testing coreboot.
But A shouldn't be required to have any deal with windows to certificate coreboot works in H without windows. SO corebot+windows certification should generally be more expensive/cumbersome than coreboot+freesoftware certification only (depending on the case, maybe coreboot+hurd may be difficult to certify...). Sounds logical.
Ideally, having some OS independent test suite would be the best approach I think, but I don't see that getting developed overnight. :)
Is that feasible at all?
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.
Very reasonable.
- ACPI
- DSDT should exist
Is that needed to develop coreboot further ? Not sure it should be required for minimal. Maybe split minimal and minimal + DSDT
- Able to load VGA option ROM
unless they find a way not to use it, like free framebuffer drivers or so on ? If propietary software is not a requirement, propietary firmware shouldn't either, whenever it can be worked around.
- 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.
I would simply say that it should boot a system that allows coreboot development using only free software, and it should document which precise system, version, etc. it is. Of course depending on what it is it may be easier or harder to find certifiers (or customers once certified).
And then we come to the thorny issue of what does "only free software" mean, since debian for instance includes kernel blobs or similar issues...
Possible tags: MSWin{XP,7} ReactOS GPXE AOE ISCSI ...
The process for adding tags to the certification criteria should be clear and simple. We won't be able to find all useful tags from the start.
Something about power saving capabilities would be useful, not sure what or how...
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
Ok. Adding the rest of hardware and software tested, like Debian lenny , AMD Phenom II X4 910e, such and such DDR3 DIMMs, such VGA... The more diverse hardware and software tested the more work to certify it, and the more tempting for consumers, who would evaluate the risk of using it with other hardware or software. One could risk buying a certified system with different amount of RAM than tested and install a different distribution, etc.
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.
ACK
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.
And if you test and find that it doesn't work with non-free drivers, that is an answer, but not very productive, is there a problem in some initialisation in coreboot or in the driver? You can't fix the driver, so supporting it is a tall order, so optional.
If the code's not merged into SeaBIOS, we shouldn't certify the build.
Yes. Not sure SeaBIOS is needed for the most basic certification, but in general if any support code is not commited then certification should wait. Not sure this is a huge problem, I'd say one wants to benefit from the community testing stuff before paying or otherwise causing someone to thoroughly test for certification. So waiting until a little after committed would be wise. Although I guess hardware is obsoleted quickly and vendors may want certification before they put it on the market... so I don't know how much of a burden this is, but I think it should be required. If Google Summer of Code candidates where required to send patches, vendors should be required to have support code good enough for being merged.
Sorry for being verbose.