Re: [coreboot] [announce] coreboot for the 21st century
Dear Stefan, dear coreboot folks, Am Donnerstag, den 20.03.2014, 22:33 +0100 schrieb Stefan Reinauer: coreboot for the 21st century setting up the project for the next decade thank you for starting a public discussion! Purpose: Purge all boards / chipsets / cpus that require ROMCC in romstage and known broken chipsets (sc520, i855) coreboot is now officially 15 years old. One and a half long decades with ups and downs. During this time we collected over 250 different mainboards. A great achievement, but also a great maintenance burden. * It is hard to keep 250+ mainboards working. Actually impossible. * Keeping them working comes at a cost. Keep old infrastructure around. Workarounds, special cases * We don’t test except on the very last stuff we’re working on To fix this issue, we suggest to establish a process to obsolete old hardware in a controlled way. Getting rid of old baggage is great and liberating for future products, but it is also one of the moves the strictly hobbyist community considers corporate driven. Hence, we want to satisfy both a speedy light-weight development process and keeping all the good coreboot legacy alive. For the first time in 2014, and every few years after that (e.g. every two years), we will create a new “community branch” that focusses on older mainboards. This branch will start out as an exact copy of ToT coreboot. Suggested name: “coreboot-community-2014” or “coreboot-v4.0”. Then this branch will not get any further new feature development (of features not available in ToT) but only bug fixes for boards to get them working and potentially backports. A question to the Git expert. Is there a way to model the requirements in a different repository structure, for example having a core coreboot repository and putting the chipset, Super IO and boards in separate repositories? I think, the OpenEmbedded/Yocto project does something like this and they call it layers [1]. I have no idea though how that worked out for them. My impression from when they started it was, that the initial setup was more difficult in comparison to having everything in one repository and I guess the layers break more often. Also incentive to care for all the layers might be not so high. A policy has to set up though, when and how changes to the core repository can be made so that the maintained/supported board layers are not broken. After the branch is created, all obsoleted mainboards are removed from the main repository. The version will be coreboot 4.1. I suggest to bump the major number by one, that means coreboot 5. Why not even use the year, so make it coreboot 2014, which is easier to recognize too. Cleanup shall begin to remove all the cruft that we had around to get those old boards working. Each mainboard in v4.1 will have a supporter / owner. New mainboards are not admitted into V4.1 without a supporter / owner. Where are these supporters/owners documented? What requirements do they have to fulfill, which if not met cause the board removal? If somebody in the community wants to keep a board / chipset alive in the tree, they can re-import them by cleaning up the board to work with the new, cruft free infrastructure. I agree that, people wanting to keep a board in the tree have to help supporting it by at least testing them in a timely manner. In 2016 we will do the same thing again, and it will become coreboot 6.0 As written above take the year as the version would be useful in my opinion. I also would increase the minor number each time a new board is submitted/merged or an unmaintained one is removed. Appendix A: romcc boards to be removed advantech/pcm-5820 asi/mb_5blgp asi/mb_5blmp axus/tc320 bcom/winnet100 bifferos/bifferboard digitallogic/msm586seg dmp/vortex86ex eaglelion/5bcm iei/juki-511p iei/nova4899r intel/jarrell intel/truxton intel/xe7501devkit supermicro/x6dai_g supermicro/x6dhe_g2 supermicro/x6dhe_g supermicro/x6dhr_ig2 supermicro/x6dhr_ig technologic/ts5300 televideo/tc7020 via/epia via/epia-m via/epia-n As others noted, it has to be decided what to do with boards, that do not adhere to current requirements due to missing hardware features and not because of lack of maintenance/support as the Bifferboard and DMP Vortex86 EX. Thanks, Paul [1] http://www.openembedded.org/wiki/Layers_FAQ [2] http://layers.openembedded.org/layerindex/branch/master/layers/ signature.asc Description: This is a digitally signed message part -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] [announce] coreboot for the 21st century
Am Montag, den 24.03.2014, 10:38 +0100 schrieb Paul Menzel: A question to the Git expert. Is there a way to model the requirements in a different repository structure, for example having a core coreboot repository and putting the chipset, Super IO and boards in separate repositories? That's technically possible. It will also multiply the problems people already have with one git submodule (3rdparty) by many, amplified by the fact that these submodules are in no way optional. I think, the OpenEmbedded/Yocto project does something like this and they call it layers [1]. That's something completely different, which happens at the build system layer. It also builds on mostly independent units, while coreboot is quite an integrated package. Cleanup shall begin to remove all the cruft that we had around to get those old boards working. Each mainboard in v4.1 will have a supporter / owner. New mainboards are not admitted into V4.1 without a supporter / owner. Where are these supporters/owners documented? MAINTAINERS What requirements do they have to fulfill, which if not met cause the board removal? they break when useful design changes to the coreboot core are implemented (eg the remove all cruft part) In this concrete situation, the cruft is a bit underspecified. I guess it's about all the __ROMCC__ ifdefs and limits to romstages designed to keep non-CAR boards alive. If somebody in the community wants to keep a board / chipset alive in the tree, they can re-import them by cleaning up the board to work with the new, cruft free infrastructure. I agree that, people wanting to keep a board in the tree have to help supporting it by at least testing them in a timely manner. Testing won't be enough. Regards, Patrick signature.asc Description: This is a digitally signed message part -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] Changes to the coreboot Project Structure
Dear Stefan, dear coreboot folks, Am Donnerstag, den 20.03.2014, 22:55 +0100 schrieb Stefan Reinauer: Changes to the coreboot Project Structure We -- the coreboot project -- have succeeded beyond our wildest expectations, with every major laptop vendor using our code. Going forward, this will require a few structural changes that will ensure that the vendors shipping coreboot products can count on a stable, reliable code base. With that incredible success, there is also a lot of work to be done to make sure the project is scaling and keeping up with the requirements of the millions of new users that coreboot gets every year. There is a large number of new corporate entities investigating their possible involvement in coreboot, and we need to make sure that their integration is working smoothly while still keeping the project’s interests and goals stable and alive. thank you once again for bringing up this discussion on the list! I’ll reply in a separate thread about coreboot’s interests and goals. Moving forward, we need to make sure that we can welcome these possible new contributors without the friction that we have seen in the past. Could you please name the friction seen in the past? The coreboot community currently consists of about 80 contributors with varying levels of activity. Among these contributors, three groups can be identified as the major stakeholders in the project: Sage Electronic Engineering (the largest coreboot IBV), From a community perspective there is currently not a lot of interaction between the community and Sage Electronic Engineering. The last commits in the upstream repository are also a few months back. Secunet and Google Inc. (delivering all new Chrome OS devices with coreboot based firmware). Did you count AMD contributions to Sage Electronic Engineering? Individuals employed by these three stakeholders make up for the majority of code contributions. According to Ohloh, roughly half of the coreboot contributions are done by the top ten contributors. Over the project life time, over 80% of those have been made by corporate contributors. Do you have an URL? As always such statistics should be taken with a grain of salt. Especially how AGESA is counted for example and regarding that a lot of board code is copied over and is not unified. While there is a fairly good understanding of the project direction and interest between those individual contributors, there are also an increasing need for making sure that the coreboot project’s scalability and its viability for mobile / consumer products and servers is guaranteed. As written above, to me the direction and interest is not so clear to me. (See my (future) reply in a separate thread.) Also the reasons for the need is not so clear. Could you please elaborate on that? The only thing I imagine is the long time it takes to upstream a board for Google because they do not use the upstream infrastructure right away. The goal of this proposal is to enable all of the community to have a strong voice and make strong contributions to the project while allowing the major stakeholders to steer the project direction and pursue ownership of the components they provide. I thought that is the case currently. Traditionally the development model of coreboot was very similar to the model of the Linux kernel in many ways, including coding guidelines, the requirement of a sign-off process for contributions, and active leadership provided by a “benevolent dictator”. Commit rights were traditionally given to few of the top contributors of the project. With the introduction of git as coreboot’s version control system and its multi-branch nature as well as gerrit for code reviews, the landscape of the project has slightly shifted towards a more anocratic development model in which different interest groups sometimes worked on opposing strategies, and thus affecting the project’s overall stability and suitability for large scale deployment negatively. The advent of these new tools requires the original project founders and major stakeholders to provide stronger leadership and strategic direction for the project. Could you please give examples? My view is, that the problem is simply missing communication. If the companies develop something in secret without announcing and discussing their plans and miss what the community does, then this is solved by improving the communication with the community. Also in the past, my impression is, that (almost(?)) always the community gave in and reworked their patches and adapted the “corporate” code and improved that. Measures to improve the coreboot Development Model * Require authors to acknowledge changes made in their name (Forge-Author) This change allows contributors to decide when their OWN changes are ready for being integrated into the project, preventing unfinished and experimental work to be submitted accidentally.
Re: [coreboot] Changes to the coreboot Project Structure
Hi folks, ok, sorry to those who thought that I was missing in action. It feels good to have a weekend to get out into the sun every now and then, and let the dust settle a little bit in a maybe too heated discussion. I will address your concerns. * mrnuke mr.nuke...@gmail.com [140320 23:42]: On Thursday, March 20, 2014 10:55:57 PM Stefan Reinauer wrote: * Build a MAINTAINERS file for common code, and encourage people to keep subsystem maintainers in the loop for changes [...] This is somewhat what linux does, and it works well for them. When we (Ron, Marc, Patrick, Peter, Aaron and I) wrote up the document, we tried to introduce some of the Linux kernel habits that might work well for us. Might be a little OT/irrelevant, but why not make gerrit need a maintainer must approve before making the change submittable. Yes, that would be a great way of implementing this. * Look into making gerrit automatically add reviewers based on maintainer lists [...] Can we find something better than gerrit? I think gerrit encourages too much bikeshedding. It also encourages people to filter out gerrit emails, so that any such maintainers would not get the message. This has come up before and we should consider that option. Gerrit is very convenient because it never loses a patch. Our mailing list based approach in previous years was way less reliable. Also, the integration of jenkins is very convenient. There might be other solutions that have both of these advantages. * Import previous code reviews and results The tree major stakeholders in the project all own internal code review systems, some of which are public (e.g. the Google Chrome OS repository) and have code reviews that include representatives outside of Google to ensure general code quality and making sure the improvements made for products don’t negatively impact upstreamability. For those cases it would be extremely helpful to honor the code reviews already done in the upstream repository Status: TO BE INVESTIGATED I couldn't disagree more. First of all, the idea of representatives outside of company to ensure general code quality is contrary to the idea of allowing the community to scrutinize to-be-upstreamed contributions. When you combine that with the idea of [blindly] honoring code reviews already done upstream, you have effectively eliminated the scrutiny and review from the community. When rebasing to a new coreboot version, e.g. the Chromium OS project does [blindly] honor code reviews already done upstream. On the contrary, I think that this strengthens the community instead of eliminating its reviews. I've seen mostly cases of great external reviews, but have also seen a fair share of bodged, nonsensical ones where terrible patches have been accepted without much thought. If the community has to accept code reviews done under closed doors, these contributions are effectively code dumps. I do not remember this ever being beneficial to the community, and usually results in the community needing to clean up afterwards. See linux for details. These reviews are not happening under closed doors. The Chromium OS project is open source and completely transparent in that manner. What do we need to do to allow commercial contributors to work directly upstream? And before you discount this question for menial technical reasons, please take a moment to keep this conversation open, and let's try to find an answer. Will it work for 100% of commercial contributors? No. However, this should be the preferred method for upstreaming contributions. See linux for an explanation why this works best. The intent of these suggestions is to move the non-commercial and commercial contributors in the community closer together. One example is the board ownership that would prevent people from messing with other people's boards without their consent. Also, if you are keeping an eye on both the Chromium OS coreboot tree and the upstream coreboot tree you will notice that basically all structural changes land in the upstream tree first, whereas the only thing that ends up in the Chromium OS tree first is code supporting specific components. This has proven to be somewhat successful as it keeps the person working at three a clock in the morning to ship a product under a tough deadline from going crazy because the target keeps moving under him. This is not a bad thing at all. It's the separation of feature development and product development, in a way. Google even does this for each of the Chrome OS devices, internally (as you can see in the Chromium OS repository) At some point there's a branch of the Chromium OS top of tree coreboot used as the basis for further product development and no new features go into that product branch (e.g. firmware branch) unless needed and carefully selected. I am sorry to say this Stefan, but, in my opinion, you
Re: [coreboot] Changes to the coreboot Project Structure
Hi Carl-Daniel, thank you for your feedback! * Carl-Daniel Hailfinger c-d.hailfinger.devel.2...@gmx.net [140321 01:39]: I see a huge bottleneck in restricting the number of committers to six. - Corporate committers will be primarily obliged to get the stuff of their own employer committed, but if they are ill or on vacation, someone else would have to take over. This would either be another corporate committer (in which case their own employer would have to authorize spending time for a different company) or a community committer. Those six people would not be required to take the full burden of code reviews. Nothing will change w.r.t that, because that would indeed create a huge bottleneck. This is just about the actual push. Any of the six can push any patch (given that the maintainers and/or authors have reviewed) - Community committers are not paid, and commit in their spare time. Spare time is not necessarily abundant all year round. Speaking from experience, the flashrom project has no shortage in developers or submitted patches, but a real and painful shortage in reviewers/committers. That is absolutely understood. However, I truly believe it is important to have community committers in place, even if it is a huge effort. Look at the subsystem maintainers of the Linux kernel, they don't have to review every single patch but often trust their peers in the community. I think that is a good model. The flashrom project patch backlog is huge due to this. Doing a commit is easy, but making sure that a commit follows certain guidelines is a huge time sink with none of the fun of writing code. The problem with flashrom is that in the last six months is has been a one man show (or two men, but only stefanct actually committed stuff). You guys are also worried to brick a system, whereas in the coreboot environment we know that we brick systems. - New contributors (corporate or community) would have to find a sponsor to actually commit their code. With a large committer base, this can happen rather quickly. With only six committers facing their own deadlines or other shortages of time, this could take quite a while. This is not unlike the Linux kernel community. AFAICS the reason to reduce the number of coreboot committers is to have gatekeepers who actually enforce guidelines by looking at patches before they commit them. That essentially introduces an additional review step. While such a step may be desirable, it would have to be made clear whose obligation it is to carry out commit+review step for new contributors, and how any fallback/failover mechanisms are implemented. Let's keep this simple for now. As always, we will adjust our implementation bit by bit to the problems we'll actually hit. If we really go ahead with a fixed number of committers, each person should have a substitute who can take over. That would be a total committer number of twelve. I was thinking that these six would be substitutes for each other. With 12 people we would have more active committers than we have now. To be honest, regardless of who will be the community gatekeepers, some people are going to be disappointed. There would have to be a metric for determining community committers. It should be people that are best suited to act in the interest of the complete project. I don't think simple metrics like lines of code or numbers of reviews is sufficient for making a good decision here. Stefan -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
[coreboot] Expectations, project direction and interest of contributors (was: Changes to the coreboot Project Structure)
Dear Stefan, dear coreboot folks, Am Donnerstag, den 20.03.2014, 22:55 +0100 schrieb Stefan Reinauer: Changes to the coreboot Project Structure We -- the coreboot project -- have succeeded beyond our wildest expectations, with every major laptop vendor using our code. Going forward, this will require a few structural changes that will ensure that the vendors shipping coreboot products can count on a stable, reliable code base. With that incredible success, there is also a lot of work to be done to make sure the project is scaling and keeping up with the requirements of the millions of new users that coreboot gets every year. […] While there is a fairly good understanding of the project direction and interest between those individual contributors, […] reading these lines I realized I do not have that understanding and I am not so certain anymore about the expectations, coreboot’s directions and the interest. First I find “wildest expectations” a little exaggerated seeing the blobs (especially ME) shipped in all current Intel devices [1]. It is even worse that these blobs are not allowed to be distributed making building and flashing an image more difficult. Additionally I heard claims, that the GPLv2 license is violated as it is currently impossible to rebuild the exact same image that is shipped with the devices as it is not even clear what commit was used to build the image and to my knowledge the requests on the list and in the IRC channel were not answered. I suspect that in the beginning of coreboot even Ron and you would not have expected anything like this to happen and not considered that such an image meets your expectations. So I congratulate that coreboot is used by several vendors and has millions of users, but it is to be taken with a grain of salt. It is also clear, that you do not like this situation either, but it would be interesting what the expectation and direction should be. Clearly, getting a system to boot is not the main goal as everybody can do that with the vendor BIOS/UEFI, which, by the way, lately greatly improved boot time too in my experience. For Google and the laptop vendors, I guess the goal is simply to save the money per device that traditionally went to the BIOS/UEFI vendors. Of course the payload concept gives a lot of flexibility, which is nice too. But in the end it seems to come down to saving money and hoping to make more profit. I do not know, if that worked and works out and how much more time it costs to deal with the community and reviews compared to the interaction with the BIOS/UEFI vendors and paying the fee/tax or with the time to deal with Intel’s management engine. The other sad development seems to be that AMD, until now being the company most supportive of coreboot by contributing code and employing developers – unfortunately only in the embedded section – working on coreboot, even *thinks* about only providing binary blobs of AGESA instead of (IP scrubbed) sources for AGESA. Unfortunately they do not seem to get the advantages of free software and understand free software in their AGESA department and although being of much smaller size than Intel, they seem already big enough to not being able to change or only being able to change slowly. And the possible move to blobs is also kind of understandable, as despite being such a first class citizen, seeing that Intel (i945) gets chosen by the German government and Google chooses Intel for their Chromebooks and ships images with blobs. As Intel is bigger, Google probably hired more people from Intel than from AMD. Maybe the Google decision makers know the Intel decision makers and play Golf with each other. Anyway, it is another datapoint that it is not about free software at all. So one could even say, that coreboot’s decision to allow binary blobs as the Management Engine and RAM init (MRC) even supported AMD’s current *plans* to go back to binary blobs as it is currently allowed for Intel. So it is questionable if the past decisions served the project well. I have no clue what would have been better and if this could have been avoided at all. Nobody can look into the future. So we have to take it as it is now, but it is clear that the opponents back then had valid points and that such decisions can have negative long term side effects. It should also not be forgotten that thanks to the leaks from Edward Snowden, the current political and economic(?) situation is as good as never before for free software and coreboot. In the Internet business, companies in the USA already feel the consequences and loose contracts and money when their datacenters/servers are located in the USA. The same will hopefully happen to hardware vendors shipping proprietary BIOS/UEFI firmware. AMD is currently the only feasible (x86) vendor and hopefully policies are going to be implemented only allowing government agencies to by AMD stuff with free firmware. (No idea how much the IT personal is
Re: [coreboot] Expectations, project direction and interest of contributors (was: Changes to the coreboot Project Structure)
I keep wanting to drop out of this discussion but there are some things I just can't let go by, On Mon, Mar 24, 2014 at 4:20 PM, Paul Menzel paulepan...@users.sourceforge.net wrote: First I find wildest expectations a little exaggerated seeing the blobs (especially ME) shipped in all current Intel devices [1]. It is even worse that these blobs are not allowed to be distributed making building and flashing an image more difficult. You're misunderstanding the blob situation completely, not surprising as it is so complex. In The Beginning, we were blob free. Things changed. Now there are blobs. We got our first blobs in 2001 or so so we could do graphics. We did not have the money to do it any other way. We don't like it. But if the choice is to ship on nothing, or ship with blobs, we'll ship with blobs. The X60 ports ship with blobs too, if you look at the big picture, because we still don't have EC source on those boxes. The OLPC shipped with blobs. This is not a simple problem. Additionally I heard claims, that the GPLv2 license is violated as it is currently impossible to rebuild the exact same image that is shipped with the devices as it is not even clear what commit was used to build the image and to my knowledge the requests on the list and in the IRC channel were not answered. Dude, the commit is IN THE IMAGE. At least on the images I work with. As in: ro bios version | Google_Link.2695.1.133 from chrome:system on my link. I also just checked my falco and the hash is right there too from cbmem -c. I don't build all platforms; have you found some where this is not the case? Might you consider fixing it? I'm going to call BS on this not GPL claim until you get a clear statement from the FSF that it is the case. I don't see the point of dropping FUD into this discussion. Make your case. Of course, we have FSF people on this list and if they want to comment on this issue they are most welcome. That said, I've also been talking to those guys (including RMS) for 15 years and they've never hinted to me we're doing something wrong. I realize there are some armchair lawyers on this list who have their own interpretation, but I think I'll use the FSF as my authority in this case. Clearly, getting a system to boot is not the main goal as everybody can do that with the vendor BIOS/UEFI, which, by the way, lately greatly improved boot time too in my experience. Gee, I get to call BS again. I have been telling people for 15 years that boot time is a nice side effect of using coreboot, and while it's key to many users and uses, it was not the primary or in many cases even a secondary goal. Getting control of your platform is one goal. Building custom systems (such as cluster nodes in my case) from generic hardware by changing the BIOS is another goal. There are lots of goals. But if you're happy with UEFI you're more than welcome to use it. For Google and the laptop vendors, I guess the goal is simply to save the money per device that traditionally went to the BIOS/UEFI vendors. You should not impute motive where you have no knowledge and I can tell you that in this case you have no knowledge. So let's move on. The AMD situation, to which you refer, is again one in which you have little or no knowledge, so there's little point in speculation. As Intel is bigger, Google probably hired more people from Intel than from AMD. And still more unfounded speculation. No offense intended, but you have no idea what you're talking about. Maybe the Google decision makers know the Intel decision makers and play Golf with each other. Anyway, it is another datapoint that it is not about free software at all. and more ... and we get the NSA now ... In my opinion, we should get the first AMD laptop supported as soon as possible yes, well, I've been asking for help on this for some time, years in fact, but I can't do it all myself. It's part of my huge disappointment that our volunteers chose to put their time into (quite obsolete, no longer manufactured) X and T thinkpads instead of something modern and open. You can fault Google for their decision to go with Intel; but the volunteers have not done a lot better, in fact worse in my view. Frankly, it's a disappointment. One option here is to focus less on the things you currently put your time on, and focus more on getting that AMD laptop working, eh? Because it's easy to talk about what we should do. It's better to start DOING IT. And getting that AMD laptop going is a lot more important than fixing spelling errors in AGESA. But, Paul, stick with what you know and drop the speculation. Much of what you say is wrong or unfounded and it doesn't help this important discussion. ron -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] Expectations, project direction and interest of contributors (was: Changes to the coreboot Project Structure)
* Paul Menzel paulepan...@users.sourceforge.net [140325 00:20]: Additionally I heard claims, that the GPLv2 license is violated as it is currently impossible to rebuild the exact same image that is shipped with the devices as it is not even clear what commit was used to build the image and to my knowledge the requests on the list and in the IRC channel were not answered. Paul, I am not in the position to make any legal statement, nor do I want to. As a word of advice, you should stop spreading this FUD and allegations when you refuse to do any research on the topic yourself. All firmware builds are coming from open source and completely transparent firmware branches living in the chromium repositories. You can access all of our code revies on the chromium gerrit, and community members can (and do, frequently) participate there. Stefan -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] Changes to the coreboot Project Structure
* David Hubbard david.c.hubbard+coreb...@gmail.com [140323 10:56]: Coreboot can be relevant even if it only supports obsolete silicon. Coreboot was the first to bring sub-second boot times to laptops. There are more examples. Yes, we worked hard to get to that goal. If it were about obsolete hardware it would have never happened though. But Peter, what's your take on Alex's suggestion: What do we need to do to allow commercial contributors to work directly upstream? And before you discount this question for menial technical reasons, please take a moment to keep this conversation open, and let's try to find an answer. For a number of contributions Google's community members have worked upstream first (Think ARM port and rmodtool) A lot of times that was critized, as the expectation is on the other hand, that corporate entities provide ready to ship solutions, and not work in progress. However, we are keeping it up for many patches, especially those that introduce structural changes to coreboot, because we want to make it as easy as possible for our fellow community members to engage in meaningful conversation about these things. Mind you, at no time does any coreboot development work at Google happen behind closed doors. Everything, including the code reviews and up-to-date code repositories are visible and accessible by anyone out there. I don't feel limited. Corporate contributors are of necessity restricted -- e.g. to large commits after the product ships. I grok that. Is there a way to *reduce* the restrictions, and burdens in general, of corporate contributors? To get them to work directly upstream? Yes, and we continue to do that. Timely upstreaming/downstreaming is a vital part of the process, and it's not always easy. There will never be anybody trying to ship coreboot on any device working on top of tree upstream just because nobody wants to do another week of testing because some unrelated patch comes in last minute, or your target is broken overnight on the day that you ship a firmware image to a factory. However, all of the development process is completely open and anybody can look at the changes Google is doing to coreboot, upstreamed or not, in real time. I don't see anywhere in Stefan's *only* email on this subject that he suggested a community branch. Branches were Alex's idea: http://www.coreboot.org/ pipermail/coreboot/2014-March/077660.html My original suggestion for a name of the coreboot branch with the old boards (that get removed from top of tree) was community-2014. I believe this led to a lot of confusion among the ones wild at heart. The name seemed reasonable at the time because it would contain all the boards that you can get on ebay but not in a store anymore. I don't think we need to get hung up on names though, anything is fine, really, as long as it's not too hard to type and somewhat descriptive ;) Stefan -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] Expectations, project direction and interest of contributors (was: Changes to the coreboot Project Structure)
On Mon, Mar 24, 2014 at 5:46 PM, Stefan Reinauer stefan.reina...@coreboot.org wrote: * Paul Menzel paulepan...@users.sourceforge.net [140325 00:20]: Additionally I heard claims, that the GPLv2 license is violated as it is currently impossible to rebuild the exact same image that is shipped with the devices as it is not even clear what commit was used to build the image and to my knowledge the requests on the list and in the IRC channel were not answered. Paul, I am not in the position to make any legal statement, nor do I want to. As a word of advice, you should stop spreading this FUD and allegations when you refuse to do any research on the topic yourself. Also, throwing around such accusations is a great way to shut discussion. You have effectively Godwin'd your own thread. As Ron said, if you have a legitimate concern please feel free to reach out to organizations such as the FSF. Spreading FUD on a mailing list like you have done is far more damaging to coreboot than anything you have accused others of doing. -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] Changes to the coreboot Project Structure
* David Hubbard david.c.hubbard+coreb...@gmail.com [140323 20:33]: On Sun, Mar 23, 2014 at 12:58 PM, Vladimir ' -coder/phcoder' Serbinenko phco...@gmail.com wrote: On 23.03.2014 19:24, ron minnich wrote: So I believe the problem is not the idea of gatekeepers, but the manner in which they are proposed to work. Can you tell me what about this upsets you? I want to understand. The problem is that the proposal is that all commits go through gatekeepers. It's bottleneck. It makes much more sense to have per-path maintainers and tiered code. E.g. we could keep all boards rather than shooting them and the ones that are considered to be too old can have less stringent requirements on commits. This will free the qualified people time to concentrate on boards where it's most important. Also it will benefit unimportant boards as well as they'll be easier to keep. Then per-path maintainer and gatekeeper are contradictory concepts. How one can be maintainer if he can't commit to his maintained code. I feel, for example, that nehalem code and resulting boards are my responsibility and I should be able to commit there easily. Getekeeprs will make this impossible as I'm more or less the only one who knows nehalem code *and* cares about it. I feel like the top-level maintainers would be only about overall structure, not about details in Board:foo/bar they've never even seen and solving disputes. Making everything go through 6 people is unfeasible as 6 people can't represent broad range of interests and some parts of code will get neglected more that they have to be of simple scarceness of resources. Without speaking for anyone or about anything else, can Stefan comment on this proposal by Vladimir? It seems relatively cool and reasonable. Tried to do so in the other mail... There's too much risk involved in working directly on upstream. The downsides just outweigh the benefits (for everybody, really) For example, when getting to the hot phase of a new product, we don't even use our chromium top of tree, but create a firmware branch specifically for a new product. Patches relevant to that product go into that branch (and top of tree, aka HEAD) but NOTHING else. For every firmware image that is released, there are also tests involving thousands and thousands of reboots and suspend/resume cycles to make sure that the product is absolutely stable. Because if 1/100k resumes crashes that means for a million users there are ten users every day whose computers crash. This level of testing is simply not possible when aiming at a moving target. Stefan -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] Changes to the coreboot Project Structure
* Vladimir 'φ-coder/phcoder' Serbinenko phco...@gmail.com [140321 04:31]: The proposition of gatekeepers would essentially kill community effort. Even in current infrastructure reviewing is a major slowdown. With small number of gatekeepers there wouldn't be any significant contributions as the gatekeepers wouldn't be able to review them in reasonable time, which will, in turn discourage contributions. You may as well just stop accepting community contributions right now: it turns out to be the same thing, just a little bit quicker. This is absolute nonsense, Vladimir. You cannot treat community as some kind of corporate entity. Nobody tries to do that. Peter Stuge, Kyösti Mälkki, N.N. (non-commercial part of the coreboot community) Sounds like a joke. While Peter is competent, he's also very busy. I'd expect his review thoughtput of perhaps a patch a week. You can't realistically put such burden on few people. If you want a corporate version of coreboot, I think you have to use a workflow similar to Fedora vs Red Hat Enterprise Linux. Your mere idea that there is some sort of corporate conspiracy acting against the interest of the community from which you automatically exclude anybody working on open source software for a day job is flawed. The changes you proposed would effectively make coreboot into corporate project. I'd expect a community fork to emerge quickly, outside of this new limiting infrastructure and I'll be surely moving to community fork. Please note that the committers don't have to be the ones to do the code reviews. If you feel like you want to work on a fork of coreboot, you are most welcome to do so. Many projects have forked over time, and some forks have died off, or taken over the role of the main project. Good luck. If this helps you get over your negative attitude you are spreading here, I fully support it. Fork is better. With fork we don't have to deal with the same people who pushed the community out in the first place. Vladimir, this has nothing to do with anybody pushing anybody out. Your behavior here is your personal choice. It's fine, but don't blame it one anybody else but yourself. You think I am hurting this project? Do your own. The grass is always greener on the other side, and you can do what you want over there. Stefan -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] [announce] coreboot for the 21st century
* Kyösti Mälkki kyosti.mal...@gmail.com [140322 18:44]: Some changes to review process are certainly welcome. I just hope Stefan would have included separate section of the current problems and more details of the goals his proposal tries to address. Even some of the obvious ones are not answered. For example, are there actual plans to bring coreboot trees from coreboot.org and Chromium back in-sync? Kyösti, thanks a lot for your input. I will try to provide examples in the future. To answer your question, yes, there are very concrete plans of syncing up the coreboot.org and Chromium coreboot trees happening right now. This is where part of this is coming from, and I am working on both sides of the story to resolve this. I am also working on getting Google's internal upstreaming process for coreboot straightened out and making the resources available so that upstreaming happens more timely in the future, and rebasing the chromium tree more against a current upstream version more often. To throw some unconfirmed numbers in here, the current chromium tree is based off of a late 2012 upstream tree (though we have pulled a lot of patches in both directions since then). The ideal would be to move the chromium tree to a new coreboot upstream in an interval of something like 3-6 months. Stefan -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] GSoC-2014 Coreboot project
Allen Yan [mailto:lex...@gmail.com] wrote: ]Oh, sorry, incorrect address! ]http://www.google-]melange.com/gsoc/proposal/public/google/gsoc2014/jinyiyan/5629499534213120 ] ]TianoCore as Coreboot payload ]JinyiYan ] ]Short description: The combination of coreboot + TianoCore ]is the most straightforward option to provide a complete, ]opensource UEFI environment. This proposal should mention that only x86 systems will be supported if that is the case. To provide a complete, opensource x86 UEFI some items not listed in this project proposal are needed: 1) UEFI support for writing to flash memory. The UEFI name is Firmware Volume Block protocol. One module for Intel systems and another module for AMD systems would probably cover most x86 motherboards. All current open source UEFI solutions use a substitute that either fails to capture OS writes to UEFI NVRAM variables, or does not preserve these writes through a power down. The most visible effect of the substitute firmware volume block driver is loss of the NVRAM variable that points to the boot device. When this variable is lost, Linux will no longer boot. Windows can still boot due to an automatic repair mechanism. In all cases, the boot order in a multiboot system will be lost. The use of the substitute firmware volume block driver causes other limitations such as such as loss of configuration settings. 2) USB OHCI support. Without this the USB keyboard on AMD systems will not work until after the OS boots. 3) Another missing item is UEFI MP Services. This one might not be essential. It is needed if UEFI code needs to launch the AP for such things as gathering SMBIOS data or for setting the SMM base address register. There is a discussion on the EDK2 Devel mailing list about the possibility of an open source solution: https://www.mail-archive.com/edk2-devel@lists.sourceforge.net/msg06354.html ]Based on coreboot-pkg, the project intends to implement ]some new features like UEFI CBFS driver and a GOP driver ]based on pre-initialized framebuffer. How will the CBFS Driver be used? Will the GOP driver support multiple video solutions? If so, how? If I use a brand XYZ video card how will the GOP driver find the details of the frame buffer? I know it is possible because operating systems do it. But the proposal should explain it for those of us who are not graphics experts. ]Please complete the standard Google SoC application and project ]proposal. Prospective coreboot GSoC student should provide the ]following information as part of their application. If you are ]applying for a flashrom or SerialICE project use common sense ]when using the template below, this is part of the test. ;) ] ]Name: Jinyi Yan ]Email: lex...@gmail.com ]IM/IRC/Skype/other contact:irc.freenode.net: ] #coreboot, #flashrom nick: Jinyi-Yan ]Web Page / Blog / Microblog / Portfolio: ]Country/Timezone:China/UTC+08 ]Normal working hours(UTC): 10:00~16:00 ]School:University of Chinese Academy of Sciences ]Expected graduation date: 2015 ] ] ]coreboot welcomes students from all backgrounds and levels ]of experience. To be seriously considered for coreboot GSoC, ]we recommend joining the mailing list and IRC channel. ]Introduce yourself and mention that you are a prospective ]GSoC student. Ask questions and discuss the project that ]you are considering. Community involvement is a key ]component of coreboot development. By the time you have ]submitted your application, you should have downloaded, ]built a and booted coreboot in QEMU, SimNow, or on real ]hardware. Please, email your serial output results to ]the mailing list. ] ]The following information will help coreboot match students ]with mentors and projects. ] ] ]Please comment on your software and firmware experience. ] ]I used to be a mainboard BIOS engineer in ASUS Technology ]Suzhou Co., Ltd for about two years (2007.7~2009.2). When at ]AsusTek Suzhou, my work is mainly responsible for bios porting ]and fixing bug. There were four mainboards P5KPL-S, P5QL-E, ]P5QL-SE, P5QL. All based on Intel platform and AMI Legacy BIOS Core. ]In the second half year of 2008, I worked on pre-development ]of EFI-BIOS for ASUS mainboard. I wrote a Dual bootblock module ]and added NTFS support(read only) for AutoRecovery module using ]AMI Apito platform (based on EFI). ] ]The most important is that I still have plenty training ]materials(EFI training and hardware initialization, ]kinds of intel chipset datasheet before 2009) from the company. If the intel chipset documents are not publically available you should not list them in your proposal. The reason is that companies sometimes ask engineers to destroy non-public documents once they leave the company or finish the project. ]They can let me grasp the concepts that I‘ve forgot quickly and ]do proper choice. ] ] ]Have you participated in the coreboot community before? ] ]No. ] ]Have you contributed to an open source project? Which one? ]What was your
[coreboot] A new, modern coreboot long-term support laptop (was: Expectations, project direction and interest of contributors)
On Monday, March 24, 2014 05:00:26 PM ron minnich wrote: I keep wanting to drop out of this discussion but there are some things I just can't let go by, Let's focus on constructicism then (if that is even a word). On Mon, Mar 24, 2014 at 4:20 PM, Paul Menzel paulepan...@users.sourceforge.net wrote: First I find wildest expectations a little exaggerated seeing the blobs (especially ME) shipped in all current Intel devices [1]. It is even worse that these blobs are not allowed to be distributed making building and flashing an image more difficult. [...] We don't like it. But if the choice is to ship on nothing, or ship with blobs, we'll ship with blobs. The X60 ports ship with blobs too, if you look at the big picture, because we still don't have EC source on those boxes. The OLPC shipped with blobs. This is not a simple problem. [slightly OT, feel free to skip] My stance on blobs is a little weird. I try to make sure I have full control of my system. If the blob cannot do any harm to my freedom, or in other words, respects it, then that blob is acceptable. * For example, a hardwired boot blob which has been RE'd so that we know what it does and how it does it, would be acceptable (see Allwinner). Even the FSF, according to RMS's own essays considers this to essentially be hardware. * A non-ISA (a) firmware blob which controls a piece of hardware which i) can only do one thing ii) without compromising the security of the system iii) and is non-essential for the functioning of the system is acceptable. Examples would be USB 3.0 firmware blobs. Examples of blobs which would NOT be are ME (violates all three points), MRC (violates point iii, and potentially ii). * An ISA blob which is NOT essential for the bring-up of the system, and can reasonably be replaced by a free alternative. This basically includes VGA BIOSes. (a) I define an ISA blob to be a blob which contains instructions for the main CPU's architecture, and executes such instructions on the main CPU. Microcode would be a non-ISA blob, as it is not a set of x86 (or ARMv7) instructions, despite it residing in the main CPU. Additionally I heard claims, that the GPLv2 license is violated as it is currently impossible to rebuild the exact same image that is shipped with the devices as it is not even clear what commit was used to build the image and to my knowledge the requests on the list and in the IRC channel were not answered. Dude, the commit is IN THE IMAGE. At least on the images I work with. As in: ro bios version | Google_Link.2695.1.133 [Again, feel free to skip ahead] I made some of the claims Paul is talking about. I have the git hash of the firmware which came with my chromebook, but a branch containing that hash is not available publicly. This is one of the reasons I proposed to allow merging branches from shipping firmware rather than forcing a rebase of all patches. For Google and the laptop vendors, I guess the goal is simply to save [Again, feel free to skip ahead]. Then why do vendors put a $130 CPU in a laptop that sells just shy of $200? the money per device that traditionally went to the BIOS/UEFI vendors. You should not impute motive where you have no knowledge [...] A very tempting point, but I'll stay out of it. In my opinion, we should get the first AMD laptop supported as soon as possible yes, well, I've been asking for help on this for some time, years in fact, but I can't do it all myself. It's part of my huge disappointment that our volunteers chose to put their time into (quite obsolete, no longer manufactured) X and T thinkpads instead of something modern and open. You can fault Google for their decision to go with Intel; but the volunteers have not done a lot better, in fact worse in my view. Frankly, it's a disappointment. This is where I've been meaning to get to. I'm all for doing what the new title of this (hijacked) thread says: a new, modern long-term coreboot supported laptop which is Respects Your Freedom certifiable. A laptop that will become what the X60 is today. I don't have the financials to do this by myself. I don't have the time to do this by myself, and most certainly not the experience to provide an A to Z turnkey solution. I'm glad you asked. Carl-Daniel asked as well. He did a few months ago, and is still in the process of choosing a good candidate. There aren't many that are both durable _and_ RYF-certifiable after our port is made. I am willing to invest whatever limited time, limited knowledge, and limited experience I have into making this project happen. One option here is to focus less on the things you currently put your time on, and focus more on getting that AMD laptop working, eh? Because it's easy to talk about what we should do. It's better to start DOING IT. And getting that AMD laptop going is a lot more important than fixing spelling errors in AGESA. Chose the
Re: [coreboot] [announce] coreboot for the 21st century
* Vladimir 'φ-coder/phcoder' Serbinenko phco...@gmail.com [140321 04:13]: The boards and chipsets are sufficiently well insulated from each other so that it's possible to improve one without breaking the others. With board-status the potential users and devs have a good overview which revisions work on which devices. The breakage will periodically occur no matter if it's 25 board or 250 boards. And it will be fixed by those who care about the particular board. Somewhat agreed. Yet, there is a certain amount of technical debt caused by boards that went out of production in the early 2000s that keep us from creating clean designs across the board instead of hiding features inside of chipsets and boards. This is exactly what then leads to the problem you are describing next: Also I feel like the amount of boards supported is actually a relatively minor maintenance burden compared to number of *options* supported. I think we should first go on killing the options noone really uses like possibility disabling ACPI tables (I have a changeset for this, mixed reception), disabling SMBIOS tables. relocatable modules should be chosen by chipset, not be user-visible, and so on. There are more broken option configurations than broken boards. Absolutely agreed. When we moved from coreboot v2 to v4 with the little v3 detour we recognized that there are several levels of configuration that happened in Config.lb back then. These were: - build rules hidden in a board config. - board specific configuration (device tree) - user configs determined at build time - user configs determined at runtime (cmos etc) A lot of that stuff ended up in the same file, and there was no clear abstraction. Then we moved to Kconfig, and away from creating Makefiles at compile time through a nasty python wrapper. However, parsing the device tree to provide compile time options in Kconfig seemed really troublesome, and so we broke our clean design of having device specific info in the device tree and only options in Kconfig. Once you go down that road, it becomes a dump really quickly, and now we have to clean up that stuff. My personal opinion is that providing non-choice options to users (like turn off ACPI and break booting any OS newer than 10ys) are not real options and just messing with the user at the cost of making the build system more complicated. All in all, there are lots of things awaiting to be fixed in the future. Stefan -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] libpayload for ARM with sprinklings of GPL and coreboot code sharing
* mrnuke mr.nuke...@gmail.com [140320 23:57]: Proposal: * Share these drivers between coreboot and libpayload. * libpayload is BSD. Have a [ ] Enable GPL features config option which unlocks the GPL'd drivers from coreboot. * libpayload core remains BSD. * coreboot drivers are available to GPL users of libpayload * Both the licensing of libpayload-core and coreboot is maintained/respected * Makes maintenance easier * Makes libpayload relevant in the ARM space In the chromium repo we've had an effort to replace the GPLed ARM parts with BSD licensed counterparts. For stuff we wrote from scratch double licensing is easy, but certainly some drivers we'd like to use from other projects (like u-boot) are a lot of work to be rewritten. For ChromeOS firmware we tried working around that by bundling the drivers with depthcharge (the payload) because it's GPL. I don't really know of any non-GPLed users of libpayload, so definitely relicensing libpaylod might be on the table. In the short term having a GPL enabling Kconfig seems like an option. Or we take the effort of rewriting those pieces BSD licensed. The question is: Is there anybody out there caring enough about non-GPLed payloads to put in the effort. Stefan -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] libpayload for ARM with sprinklings of GPL and coreboot code sharing
* Patrick Georgi patr...@georgi-clan.de [140321 18:38]: Am Donnerstag, den 20.03.2014, 17:57 -0500 schrieb mrnuke: * Share these drivers between coreboot and libpayload. Make them BSD-l, like cbfs-core. * libpayload core remains BSD. with strings attached - I'd like to avoid that. Nice pun. It's actually the string functions that are GPLed in the ARM port right now. D'uh. If you need SoC drivers, the *BSDs have their share of drivers, too. Typically of a better quality than the Linux ones (but less battle tested). Is there any single BSD licensed payload out there? That's using libpayload? The work around of stuffing drivers into depthcharge is really, really unfortunate because it causes unnecessary duplication Stefan -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] Changes to the coreboot Project Structure
On 25.03.2014 02:33, Stefan Reinauer wrote: * David Hubbard david.c.hubbard+coreb...@gmail.com [140323 20:33]: On Sun, Mar 23, 2014 at 12:58 PM, Vladimir ' -coder/phcoder' Serbinenko phco...@gmail.com wrote: On 23.03.2014 19:24, ron minnich wrote: So I believe the problem is not the idea of gatekeepers, but the manner in which they are proposed to work. Can you tell me what about this upsets you? I want to understand. The problem is that the proposal is that all commits go through gatekeepers. It's bottleneck. It makes much more sense to have per-path maintainers and tiered code. E.g. we could keep all boards rather than shooting them and the ones that are considered to be too old can have less stringent requirements on commits. This will free the qualified people time to concentrate on boards where it's most important. Also it will benefit unimportant boards as well as they'll be easier to keep. Then per-path maintainer and gatekeeper are contradictory concepts. How one can be maintainer if he can't commit to his maintained code. I feel, for example, that nehalem code and resulting boards are my responsibility and I should be able to commit there easily. Getekeeprs will make this impossible as I'm more or less the only one who knows nehalem code *and* cares about it. I feel like the top-level maintainers would be only about overall structure, not about details in Board:foo/bar they've never even seen and solving disputes. Making everything go through 6 people is unfeasible as 6 people can't represent broad range of interests and some parts of code will get neglected more that they have to be of simple scarceness of resources. Without speaking for anyone or about anything else, can Stefan comment on this proposal by Vladimir? It seems relatively cool and reasonable. Tried to do so in the other mail... There's too much risk involved in working directly on upstream. The downsides just outweigh the benefits (for everybody, really) For example, when getting to the hot phase of a new product, we don't even use our chromium top of tree, but create a firmware branch specifically for a new product. Patches relevant to that product go into that branch (and top of tree, aka HEAD) but NOTHING else. For every firmware image that is released, there are also tests involving thousands and thousands of reboots and suspend/resume cycles to make sure that the product is absolutely stable. Because if 1/100k resumes crashes that means for a million users there are ten users every day whose computers crash. This level of testing is simply not possible when aiming at a moving target. I don't see how this prevents any of my propositions for the bulk of the boards. The problem you describe isn't going away with your proposition. We still want to have a top which is supposed to work on all boards. Stefan signature.asc Description: OpenPGP digital signature -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] A new, modern coreboot long-term support laptop (was: Expectations, project direction and interest of contributors)
On Mon, Mar 24, 2014 at 9:10 PM, mrnuke mr.nuke...@gmail.com wrote: [slightly OT, feel free to skip] My stance on blobs is a little weird. I try to make sure I have full control of my system. If the blob cannot do any harm to my freedom, or in other words, respects it, then that blob is acceptable. * For example, a hardwired boot blob which has been RE'd so that we know what it does and how it does it, would be acceptable (see Allwinner). Hard for me to agree with this, but if that's ok with you, it's ok with me. If you are claiming to understand what an RE'd blob does then you've solved the halting problem, I think. Even the FSF, according to RMS's own essays considers this to essentially be hardware. * A non-ISA (a) firmware blob which controls a piece of hardware which i) can only do one thing ii) without compromising the security of the system iii) and is non-essential for the functioning of the system is acceptable. Examples would be USB 3.0 firmware blobs. Examples of blobs which would NOT be are ME (violates all three points), MRC (violates point iii, and potentially ii). Interesting. From a security POV I'm a lot more worried about usb3 firmware than about the MRC. As far as I'm concerned USB 3 firmware is a persistent embedded threat, violating point ii. The ME is of course far worse. Of these I find the MRC the *least* threatening. Laptops are little networked heterogeneous multicomputers. In many ways the code running on the main CPU is the least important bit. This is a big problem, getting worse, and nobody's thinking hard enough about it, because fixing it requires exposing more info than the vendors want you to have. Sound familiar? :-( * An ISA blob which is NOT essential for the bring-up of the system, and can reasonably be replaced by a free alternative. This basically includes VGA BIOSes. Makes no sense to me either. If the ISA blob is in place, then it's no different than MRC, save that it is almost certainly persistent. In fact it's more dangerous than the ME. Until it's replaced, it can at any point compromise the security of the system. Additionally I heard claims, that the GPLv2 license is violated as it is currently impossible to rebuild the exact same image that is shipped with the devices as it is not even clear what commit was used to build the image and to my knowledge the requests on the list and in the IRC channel were not answered. Dude, the commit is IN THE IMAGE. At least on the images I work with. As in: ro bios version | Google_Link.2695.1.133 [Again, feel free to skip ahead] I made some of the claims Paul is talking about. Well, you were wrong, and those are serious accusations. You should take a lot more care when you sling that type of claim around. We've had to deal with it a lot in the past; some vendors dishonestly and repeatedly made that claim, knowing it was a lie, in order to try to kill coreboot, more than once. They did not stop when we called them on it. It's pure FUD. It will almost certainly be revived again as a result of your claims and Paul's note, and we'll have to deal with it again. Thanks. I have the git hash of the firmware which came with my chromebook, but a branch containing that hash is not available publicly. Baloney. Your not finding it does not mean it's not available. It means you didn't look hard enough. [Again, feel free to skip ahead]. Then why do vendors put a $130 CPU in a laptop that sells just shy of $200? You don't know what it cost them. You only know what it *might* cost you. Hence, this statement is almost certainly wrong. This is where I've been meaning to get to. I'm all for doing what the new title of this (hijacked) thread says: a new, modern long-term coreboot supported laptop which is Respects Your Freedom certifiable. A laptop that will become what the X60 is today. I'm wondering: what's wrong with the HP11? It goes much further today than any x86 laptop toward RYF. The MRC is source. There's no ME. The EC code is also open source. Why not start there? Sure, it's not coreboot; sure, it's not x86; who cares? It's totally RYF. And coreboot can run on it, I bet, if you care. Chose the hardware. Set up a github temporary fork. Send me the hardware. I got Pomona, I got SPI, I got USB debug, and I got the burning desire to make this happen. I think that's wonderful, and you need to find a way to make it happen. Right now, as you have seen, laptop vendors are not breaking down the doors at AMD to use their chipsets in a laptop. There are reasons. The volunteers need to lead this AMD effort, and the first step is finding the person to make it happen, and the next step is finding money. But, first, you really ought to make sure it's AMD you want, not ARM. And once you pick out a laptop, fill out the blob matrix, please, so we know what's going on. Further, you need to make this scale. By the time you're done the first
Re: [coreboot] Changes to the coreboot Project Structure
On Mon, Mar 24, 2014 at 10:20 PM, Vladimir 'φ-coder/phcoder' Serbinenko phco...@gmail.com wrote: I don't see how this prevents any of my propositions for the bulk of the boards. The problem you describe isn't going away with your proposition. We still want to have a top which is supposed to work on all boards. All boards? The Arima HDAMA, 12 years old now, not sold for maybe 10? All boards? Are you sure? ron -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] Changes to the coreboot Project Structure
On 25.03.2014 06:34, ron minnich wrote: On Mon, Mar 24, 2014 at 10:20 PM, Vladimir 'φ-coder/phcoder' Serbinenko phco...@gmail.com mailto:phco...@gmail.com wrote: I don't see how this prevents any of my propositions for the bulk of the boards. The problem you describe isn't going away with your proposition. We still want to have a top which is supposed to work on all boards. All boards? The Arima HDAMA, 12 years old now, not sold for maybe 10? All boards? Are you sure? That's why I added *supposed to*. I'm aware that some boards are probably broken and not much we can do about it. ron signature.asc Description: OpenPGP digital signature -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] A new, modern coreboot long-term support laptop (was: Expectations, project direction and interest of contributors)
On Mon, Mar 24, 2014 at 9:10 PM, mrnuke mr.nuke...@gmail.com wrote: Chose the hardware. Set up a github temporary fork. Send me the hardware. I got Pomona, I got SPI, I got USB debug, and I got the burning desire to make this happen. I like your attitude. See if there's a laptop that looks doable in the ~$500 range, buy two of 'em, and tell me how to reimburse you. Note: $$$ would come from my own pocket and has nothing to do with my employer. Note 2: This might be a good place to start: https://chromium-review.googlesource.com/#/c/188275/ -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] Changes to the coreboot Project Structure
On Mon, Mar 24, 2014 at 10:37 PM, Vladimir 'φ-coder/phcoder' Serbinenko phco...@gmail.com wrote: That's why I added *supposed to*. I'm aware that some boards are probably broken and not much we can do about it. Except remove them, right? ron -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
