On 04.10.2010 02:11, Warren Turkal wrote: *snip*
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 "beta test" sounds like almost done, but needs testing. What about simply calling it "Coreboot: Under development". I can't imagine it to be printed on a box though, but as you said your're focussing on the community, at least for now, a list in the wiki showing all certified products will be more appropriate.
*snip*
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)
I should have explicitly included this in the standard certification level.
- All ports/expansion slots (exceptions: rs232, parallel, floppy)
Already said this in the standard certification level except that I didn't make any exceptions. It's sloppy to leave physical and header ports not working.
This probably was a little unclear. I meant to list what users expectations are, but not what criteria for certification should be. From a technical perspective I totally agree that every connector/header should be funtional.
- Everything related to power management as supported by the underlying
hardware and drivers (All power states, ACPI). Also needed to improve drivers.
For the record, I included this in the "better ACPI support" section of the standard certification. The OSPM part of ACPI includes all power states of all parts of the system.
- 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.
As Carl-Daniel stated, there are practically just ATI/AMD and Nvidia. And I also agree that it can't be expected every developer has both to test with. But you are not the only dev, it's possible to delegate test to each other and probalby to kreep track of that in the wiki. There is a testsystem: http://www.coreboot.org/Distributed_and_Automated_Testsystem I have not digged into it, but it's probably possible to extend it for semi- automatic testing. So that if dev A has written code which also needs testing for hardware only dev B has access to, dev A can call for dev B to test it. To scale well such a system would require information about who has which hardware to run tests on. This would allow for automatic notification.
- 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.
If that's for the development certification, I totally agree. I always had the consumer in mind.
- fast booting
I think this might be a little too subjective for certification. What if a server vendor wanted to ship coreboot firmware that does a longish running operation everytime before booting. Would that never qualify for a coreboot certification?
As mentioned above it's meant as user expectations not certification criteria.
Things normal users don't care about:
- most legacy stuff like rs232, parallel, floppy
As stated above, I think that leaving ports with physical or header connections nonfunctional is just sloppy, and it would not reflect well on the project to allow board in that state to get a standard certification.
Agreed
- pro features like *PXE, AoE, iSCSI (Those could be combined under a
logo like "Coreboot for Professionals")
I agree about things like PXE, AoE, and iSCSI being more important to big iron. I'm not sure that we should have another certification level to support them right out of the gate, however. More certification levels is more confusing.
Probably having these listed as separate features would be best.
*snip*
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.
I am not sure this data is simple enough for wiki. However, I haven't given this too much thought.
It defintely would be helpful for new developers and leave a good impression to verndors/OEMs. Right now it's not that easy for an outstanding person to tell what works and how well (also e.g. has freely available documentations or not). So improving infrastructure on this side will pay off, I guess.
I think of a combination of the automatic testing + semi-automatic testing as described above and a status site to keep track of this details. For example board $FOO has this components where this where tested an that not. Also additional test like with works Nvidia or ATI GPU could be introduced. This system could deliver all the status information needed, so anyone could tell where the project stands. The lazy evaluation would allow to make good use of the rare hardware around the developers. It's also an invitation for testers only, as they would always know what still needs testing and do the test if they find the time. This eliminates the need to setup the full automatic testsystem, which apparently aims for vendors only. So you may want to think that through. ;-)
*snip*
On Monday 04 October 2010, Patrick Georgi wrote:
Am 04.10.2010 07:33, schrieb Warren Turkal:
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?
That's the difference between a certification that's useful for vendors and one that's useful for computing enthusiasts.
Carl-Daniel and myself were refering to the former one and Warrens seems to focus on the latter one. What do you think about doing one after another? Start off with minimal certificate to attract more developers and call it e.g. "Coreboot Beta Test" or "Coreboot under development". And at some later point, if OEMs got interested, go for a consumer certificate like "Coreboot compatible" or "Coreboot certified". The latter one should focus on the average user's needs/expectations, delivering a fire-and-forget solution for OEMs. The minimal certificate won't need to be printed on a box, as a product list on web would do fine. This would also prevent later confusion due to having more than one certificate logo out in the wild at the same time, as minimal and consumer certification time periods may overlap.
Whoever produces and sells boards will have some Windows 7 license (and probably the dev builds to improve testing, as well as the Microsoft test kits) lying around.
True, the OEMs are likely to help out on that matter.
That means, certification would be for different purposes.. a "coreboot
- Linux" certificate would state that the board is actually useful
beyond freedos (eg. networking works, HPET is around, ACPI is at least somewhat useful, even if Linux's ACPI interpreter is more forgiving than perl)
A "coreboot + Windows" certificate could build onto that, stating that Windows operation was tested, too. Stacking them this way would ensure that Windows support doesn't break Linux (or any other free OS).
A "Coreboot + $OS" logo could give a bad impression, as it will look like coreboot can only boot a specific OS. So a minimal and a consumer version of a certificate, where only the latter one would be printed on the box would have a more to-the-point expression to others.
But vendors will (except for some specialty shops or special customer requests) require the latter - with no regard for the former, except maybe to assess how much work they'd have to put in/sponsor to make a coreboot port Windows compatible.
As a side note on "Windows compatible", I'm not 100% sure on this, but I think the "Designed for Windows" set of certificates by Microsoft handle firmware behaviour, too.
This certaintly has the potential to threaten a coreboot certification. Even if there's no criteria now, Microsoft could add one to prevent OEMs to certify for both Windows and Coreboot at the same time. When the time comes for a coreboot consumer certificate some investigation on that matter is needed too.
Patrick