On Sun, Oct 3, 2010 at 6:22 PM, Carl-Daniel Hailfinger <[email protected]> wrote: > On 04.10.2010 02:11, Warren Turkal wrote: >> On Sun, Oct 3, 2010 at 10:58 AM, phorsyon <[email protected]> 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 with. > 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. Thanks, wt -- coreboot mailing list: [email protected] http://www.coreboot.org/mailman/listinfo/coreboot
