Hello coreboot fellows,
we've recently seen the deprecation of Intel/Broadwell-DE support because it turned out to be too proprietary to be maintained in the long run. With that in mind, shouldn't additions to coreboot that have high chances to suffer the same fate be discussed in advance? It seems a huge burden for the community to add proprietary support for a platform, and all related effort is wasted if support can't be maintained.
There are currently two new platforms in development that seem to have trouble with public binaries (which would be necessary to make the code useful to the coreboot community). Namely, AMD/Picasso and Intel/Skylake-SP. Support for the former is already partially rotting on our master branch. Shouldn't we discuss their fate before more resources are wasted?
Nico
On Sat, Jan 25, 2020 at 4:44 PM Nico Huber nico.h@gmx.de wrote:
Hello coreboot fellows,
we've recently seen the deprecation of Intel/Broadwell-DE support because it turned out to be too proprietary to be maintained in the long run.
To be fair, the FSP 1.0 platforms (Broadwell-DE, Baytrail, Rangeley) had a pretty long run in master. It was only when certain important coreboot features were introduced and plenty of warning that FSP 1.0 needed to be deprecated that those SoCs were deemed unmaintainable in master and moved to 4.11_branch.
Heck, even after that platforms are still being released using that code such as the Librem Server. It's still used and maintained, just not in the master branch.
There are currently two new platforms in development that seem to have trouble with public binaries (which would be necessary to make the code useful to the coreboot community). Namely, AMD/Picasso and Intel/Skylake-SP. Support for the former is already partially rotting on our master branch. Shouldn't we discuss their fate before more resources are wasted?
I happen to know that for the latter the whole point of uploading it in its current state was to get some feedback. The authors gave a live demo of it last fall at the OCP Summit in Europe and wanted to finally get some code published, which itself was quite a feat.
As for their fate, I think we need to look forward and not just backward. The code was pushed upstream with the intent of being used in real products and not just for the fun of putting a bunch of unusable code on display and making peoples' lives difficult. It also serves as a starting point for future work.
That said, it's fair to say that if nothing uses that code then perhaps it should be removed from the master branch. In Picasso's case, there is a mainboard in progress (CB:33772), and given the timeline I suspect there was a previous board that got cancelled (stuff doesn't always go as planned...). In Skylake-SP and Tioga Pass case, the hardware already exists and is in production but the blob situation might prevent it from being usable by the community, but the code is already being used as a starting point for the next generation platform.
Hi David,
On 26.01.20 20:15, David Hendricks wrote:
On Sat, Jan 25, 2020 at 4:44 PM Nico Huber nico.h@gmx.de wrote:
There are currently two new platforms in development that seem to have trouble with public binaries (which would be necessary to make the code useful to the coreboot community). Namely, AMD/Picasso and Intel/Skylake-SP. Support for the former is already partially rotting on our master branch. Shouldn't we discuss their fate before more resources are wasted?
I happen to know that for the latter the whole point of uploading it in its current state was to get some feedback. The authors gave a live demo of it last fall at the OCP Summit in Europe and wanted to finally get some code published, which itself was quite a feat.
As for their fate, I think we need to look forward and not just backward. The code was pushed upstream with the intent of being used in real products and not just for the fun of putting a bunch of unusable code on display and making peoples' lives difficult. It also serves as a starting point for future work.
That said, it's fair to say that if nothing uses that code then perhaps it should be removed from the master branch. In Picasso's case, there is a mainboard in progress (CB:33772), and given the timeline I suspect there was a previous board that got cancelled (stuff doesn't always go as planned...). In Skylake-SP and Tioga Pass case, the hardware already exists and is in production but the blob situation might prevent it from being usable by the community, but the code is already being used as a starting point for the next generation platform.
sounds like good progress. Though, you make it look like SKL-SP support is just a code drop. If there is no intention to get it into shape and working with upstream coreboot, together with the community, should we merge it? Jonathan seems to work hard to clean the patches "formally into shape" (i.e. fixing checkpatch issues), but that's not all that matters, is it?
Nico
On 1/26/20, 11:32 AM, "Nico Huber" nico.h@gmx.de wrote:
Hi David,
On 26.01.20 20:15, David Hendricks wrote: > On Sat, Jan 25, 2020 at 4:44 PM Nico Huber nico.h@gmx.de wrote: >> There are currently two new platforms in development that seem to >> have trouble with public binaries (which would be necessary to make >> the code useful to the coreboot community). Namely, AMD/Picasso and >> Intel/Skylake-SP. Support for the former is already partially rotting >> on our master branch. Shouldn't we discuss their fate before more >> resources are wasted? > > I happen to know that for the latter the whole point of uploading it > in its current state was to get some feedback. The authors gave a live > demo of it last fall at the OCP Summit in Europe and wanted to finally > get some code published, which itself was quite a feat. > > As for their fate, I think we need to look forward and not just > backward. The code was pushed upstream with the intent of being used > in real products and not just for the fun of putting a bunch of > unusable code on display and making peoples' lives difficult. It also > serves as a starting point for future work. > > That said, it's fair to say that if nothing uses that code then > perhaps it should be removed from the master branch. In Picasso's > case, there is a mainboard in progress (CB:33772), and given the > timeline I suspect there was a previous board that got cancelled > (stuff doesn't always go as planned...). In Skylake-SP and Tioga Pass > case, the hardware already exists and is in production but the blob > situation might prevent it from being usable by the community, but the > code is already being used as a starting point for the next generation > platform.
sounds like good progress. Though, you make it look like SKL-SP support is just a code drop. If there is no intention to get it into shape and working with upstream coreboot, together with the community, should we merge it? Jonathan seems to work hard to clean the patches "formally into shape" (i.e. fixing checkpatch issues), but that's not all that matters, is it?
It is NOT just a code drop. It is backed up by a huge commitment, multi-company collaboration and a long term roadmap. For some context, please refer to [1] and [2]. The intention of this upstream is to get reviews from the community, and in turn to enable the community to work on coreboot support for Xeon Scalable Processors based servers, with this patch set as a start point.
[1] https://www.youtube.com/watch?v=eVmx9n5FyDI [2] https://www.youtube.com/watch?v=lvAnj0k54Jw
Nico _______________________________________________ coreboot mailing list -- coreboot@coreboot.org To unsubscribe send an email to coreboot-leave@coreboot.org
Hi Jonathan,
thanks for your email. It's become very rare that developers take part in mailing-list discussions when they are asked to. So it's really appreciated.
On 27.01.20 17:21, Jonathan Zhang (Infra) wrote:
On 1/26/20, 11:32 AM, "Nico Huber" nico.h@gmx.de wrote:
Hi David,On 26.01.20 20:15, David Hendricks wrote:
On Sat, Jan 25, 2020 at 4:44 PM Nico Huber nico.h@gmx.de wrote:
There are currently two new platforms in development that seem to have trouble with public binaries (which would be necessary to make the code useful to the coreboot community). Namely, AMD/Picasso and Intel/Skylake-SP. Support for the former is already partially rotting on our master branch. Shouldn't we discuss their fate before more resources are wasted?
I happen to know that for the latter the whole point of uploading it in its current state was to get some feedback. The authors gave a live demo of it last fall at the OCP Summit in Europe and wanted to finally get some code published, which itself was quite a feat.
As for their fate, I think we need to look forward and not just backward. The code was pushed upstream with the intent of being used in real products and not just for the fun of putting a bunch of unusable code on display and making peoples' lives difficult. It also serves as a starting point for future work.
That said, it's fair to say that if nothing uses that code then perhaps it should be removed from the master branch. In Picasso's case, there is a mainboard in progress (CB:33772), and given the timeline I suspect there was a previous board that got cancelled (stuff doesn't always go as planned...). In Skylake-SP and Tioga Pass case, the hardware already exists and is in production but the blob situation might prevent it from being usable by the community, but the code is already being used as a starting point for the next generation platform.
sounds like good progress. Though, you make it look like SKL-SP support is just a code drop. If there is no intention to get it into shape and working with upstream coreboot, together with the community, should we merge it? Jonathan seems to work hard to clean the patches "formally into shape" (i.e. fixing checkpatch issues), but that's not all that matters, is it?
It is NOT just a code drop.
Don't worry. Maybe that came out wrong. What I meant is that /if/ the SKL-SP code will not be usable by anyone else, there'll probably be little interest in the community to work on it. Hence, the code would likely just stay as is. So what upstream it for? (that's not a retho- rical question, I'm really asking for expectations)
We had this before: Something that nobody really cared about was upstreamed. And then later, it was copied for newer platforms and people were confused by the feedback that they didn't get for the original platform's code (they expected that what was acceptable for the platform that nobody cared about would always be accepted). I'm not saying that this is the wrong way. Just that from my point of view, we had bad experience with it.
It is backed up by a huge commitment, multi-company collaboration and a long term roadmap.
Sounds nice. If it's really long term, i.e. covering more than a few months, maybe it's even worth to add that roadmap to coreboot's Documentation/ folder? Generally, in my experience, the more infor- mation is available before a review, the better the review will be.
For some context, please refer to [1] and [2]. The intention of this upstream is to get reviews from the community, and in turn to enable the community to work on coreboot support for Xeon Scalable Processors based servers, with this patch set as a start point.
Yeah, but what I don't understand so far: Where is one supposed to get the required blob? And who produced it anyway? Does an NDA with Intel suffice? or does it need a three-party NDA with Intel and Facebook? For which (future?) platform can we expect a public binary if any?
This seems critical to me. With little documentation (if any at all) about the silicon initialization, no documentation about the blob (I assume?) and no binaries to at least test it, what do you expect from the review?
[1] https://www.youtube.com/watch?v=eVmx9n5FyDI [2] https://www.youtube.com/watch?v=lvAnj0k54Jw
Thanks. Um, do you have anything that is not on Youtube? One of the nice things of the mailing list is that it's archived. But that applies only to information inline in the e-mail, of course. Also, personally, I would prefer something with less java-script, less commercials, and less tracking.
Nico
Despite my frustration here, I’m optimistic that this discussion can serve to close out the thread “Copy-first platform additions (was: Re: Re: Proposal to add teeth to our Gerrit guidelines)” https://mail.coreboot.org/hyperkitty/list/coreboot@coreboot.org/thread/JHXCP... which I felt went somewhat unanswered. There were good arguments on both sides of that, many that I agree with, but I don’t think we came away with any solid policies for future development.
Before addressing the main topic, I think a little context of how corporate contributors must develop and add functionality is important.
To paraphrase one very large coreboot consumer, “The fastest time any company has ever demonstrated development from scratch to ship-worthy was eighteen months”. Pick your favorite fraction of this for when code is therefore push-worthy (9 months? The full 18 months?), and consider how much you’ve personally observed the project evolve in that same length of time. I’m sure you can foresee the amount of rebasing/rewriting that would be required. Many years ago, I observed an Asian team attempting to complete 100% of their development internally. When it was time to push, they were so out of date it was a disaster, requiring additional work for both developers and reviewers to point out what was newly wrong.
Predating the discussion of the community preference for development/contribution practices, we had already chosen the path of copy/modify approach for stoneyridge-to-picasso. Despite any detractors’ opinions on the code itself, stoneyridge was (1) the sole AMD product supporting modern coreboot features and directory structure, (2) extensively tested and verified. Therefore, the first order of business was moving as much stoneyridge functionality into a common directory as I was comfortable with.
And yes, there is currently board design and bringup, power measurements, etc. all being conducted on an internal fork of the work-in-progress stack out of the coreboot repo. (You’ll forgive me if I don’t discuss specifics…) I assure you there are many more stakeholders than are visible to the coreboot community. The reality of corporate contributors, is they essentially must seek revenue either by working on a specific product or seeding a roadmap; either pursuing near-term revenue or laying the groundwork for the more distant future. Either way, they must have a reason to believe there will be some reward for the heavy development expenses they shoulder up front. AMD is not unique in this regard. In my judgement of the timeline, i.e. as an outsider looking in at that time, AMD began picasso development much later than any of us would have wanted.
That brings me back to the patch submit effort that would be required if there’s not an acceptable middle ground. Ballparking the number of picasso patches that have already landed, plus what’s on the fork, we could easily be looking at 250-300 individual patches or possibly more. Even if properly sized for easy review, that seems to me to be too many to dump on the community at once. And you can imagine what happens if a revision is requested on the earliest one, i.e. how many others might need to be fixed up, and the unnoticed errors that could result from that process.
I am also sympathetic to the idea that the work-in-progress has not been updated as rapidly as it should have been. YOU”RE RIGHT. I agree, and I’m frustrated too. This has simply been a problem of resource constraints. My responsibility; I’m not blaming anybody. The stakeholders mentioned above simply must be considered too, and it frustrates me that I can’t tip that hand for community people also looking for more rapid changes to picasso.
Let me respond this way, though. Before being asked to return to AMD, I asked very direct questions to my future management trying to gauge how serious AMD _really_ is about being a top-notch contributor and member of the coreboot community, regarding how big do we expect to grow our coreboot team(s), about how they see me as pivotal to growing the team. I don’t need to tell you that AMD has been in a place of “not getting it” for a very long time. Believe me, it would’ve been very easy and very lucrative not returning to AMD but I went back with the personal goal of turning them into a first-class contributor to coreboot. Sure, ambitious. And to that end, surely you understand the time and effort it requires to either hire or create talented coreboot engineers.
I’ll also add that I sense many people are still sore over many of AMD’s sins of the past, especially of creating complete new duplicated directories and then maintaining them. Not unjustified…[*]
Apologies for such a long screed before addressing what got us here, “soc/amd/picasso: Drop forked copy of SMBus source“. I respectfully request that features not be stripped whole-cloth from an soc port actively in development. I fully acknowledge there is no build testing in place, which applies not only to this one feature but the entire amd/picasso directory itself. (Hopefully nobody would seriously advocate for removing the entire picasso directory.) Instead, please give me the opportunity to review any of your changes that touch the picasso directory. If I have any concerns of building, I can test and run it locally, recommend solutions, etc. We can expect a few problems to slip through that process, which I will immediately discover prior to repushing my subsequent work. I will fix it, and allow you to review that work. I am also committed to converting anything resembling a fork to amd/common where it makes sense, and when the development priorities allow. The instant that mb/amd/mandolin lands, it will no longer be work-in-progress and it will undoubtedly build successfully.
As is frequently the case, there is substantial effort, resources and money invested, negotiations, and so on, that the coreboot community would never be able to see. I’m not sure how to best convey to you that AMD is serious about making picasso and subsequent “Zen” processors very viable options for running coreboot. I’ll mention that several of us have already purchased picasso-based laptops, however, with the intent of eventually adding mainboard ports for them. On the outside chance no picasso-coreboot product ever ships, I’ll definitely accept deleting the picasso directory out of the source.
Ironically, I could have commonized the SMBus feature several times over within the time we’ve had this discussion. I feel this is an important topic, however, so thank you for indulging me. Although I still won’t reprioritize this work ahead of what I promised to my stakeholders, I believe the time discussing this was valuable.
Finally a word about blobs. Not that I think it belongs in the context of this discussion, but it seems to have been a source of bias against picasso. This is a long-standing complaint, and for legitimate reasons. I also get a strong sense that the industry (and I’m thinking of OCP in particular) is coming to accept blobs as a necessary downside to using modern x86 processors, but that blobs must be redistributable (and Nico, no ideas either on Intel’s redistribution policies or expectations). I have no knowledge on how discussions within AMD stack up against discussions within Intel, of course. I realize many of you are aware of past broken promises to reopen AGESA, the reverse engineering research done on the PSP, and many other things. However, there are very powerful and influential people in AMD who want both AGESA and PSP open sourced sooner vs. later. If we see the day come when this begins to happen, an inherently slow process will ensue. I think too many people assume source can simply be dumped onto github, but they don’t understand the extensive legal and other processes required leading up to that point.
[*] In my opinion, the entire project and its standards & expectations have matured since those days. And, surely I don’t need to remind anybody of AMD’s financial situation in the not-so-distant past. By “financial situation”, I especially mean the ability to fund development and support efforts. AMD was all but broke, so there was simply no chance they were going to fund the upkeep of those older solutions. And regarding comments about Sage, a preferred AMD partner at the time, the main reason we saw any sanctioned work in the project was due to Sage’s attempting to remain profitable while doing so. Sage also worked on both AMD and Intel products, and supplying to coreboot consumers (names that might surprise you), and yet we saw that profitability ultimately was a real problem.
Thanks, Marshall
On Mon, Jan 27, 2020 at 11:56 AM Nico Huber nico.h@gmx.de wrote:
Hi Jonathan,
thanks for your email. It's become very rare that developers take part in mailing-list discussions when they are asked to. So it's really appreciated.
On 27.01.20 17:21, Jonathan Zhang (Infra) wrote:
On 1/26/20, 11:32 AM, "Nico Huber" nico.h@gmx.de wrote:
Hi David,On 26.01.20 20:15, David Hendricks wrote:
On Sat, Jan 25, 2020 at 4:44 PM Nico Huber nico.h@gmx.de wrote:
There are currently two new platforms in development that seem to have trouble with public binaries (which would be necessary to make the code useful to the coreboot community). Namely, AMD/Picasso and Intel/Skylake-SP. Support for the former is already partially rotting on our master branch. Shouldn't we discuss their fate before more resources are wasted?
I happen to know that for the latter the whole point of uploading it in its current state was to get some feedback. The authors gave a live demo of it last fall at the OCP Summit in Europe and wanted to finally get some code published, which itself was quite a feat.
As for their fate, I think we need to look forward and not just backward. The code was pushed upstream with the intent of being used in real products and not just for the fun of putting a bunch of unusable code on display and making peoples' lives difficult. It also serves as a starting point for future work.
That said, it's fair to say that if nothing uses that code then perhaps it should be removed from the master branch. In Picasso's case, there is a mainboard in progress (CB:33772), and given the timeline I suspect there was a previous board that got cancelled (stuff doesn't always go as planned...). In Skylake-SP and Tioga Pass case, the hardware already exists and is in production but the blob situation might prevent it from being usable by the community, but the code is already being used as a starting point for the next generation platform.
sounds like good progress. Though, you make it look like SKL-SP support is just a code drop. If there is no intention to get it into shape and working with upstream coreboot, together with the community, should we merge it? Jonathan seems to work hard to clean the patches "formally into shape" (i.e. fixing checkpatch issues), but that's not all that matters, is it?
It is NOT just a code drop.
Don't worry. Maybe that came out wrong. What I meant is that /if/ the SKL-SP code will not be usable by anyone else, there'll probably be little interest in the community to work on it. Hence, the code would likely just stay as is. So what upstream it for? (that's not a retho- rical question, I'm really asking for expectations)
We had this before: Something that nobody really cared about was upstreamed. And then later, it was copied for newer platforms and people were confused by the feedback that they didn't get for the original platform's code (they expected that what was acceptable for the platform that nobody cared about would always be accepted). I'm not saying that this is the wrong way. Just that from my point of view, we had bad experience with it.
It is backed up by a huge commitment, multi-company collaboration and a long term roadmap.
Sounds nice. If it's really long term, i.e. covering more than a few months, maybe it's even worth to add that roadmap to coreboot's Documentation/ folder? Generally, in my experience, the more infor- mation is available before a review, the better the review will be.
For some context, please refer to [1] and [2]. The intention of this upstream is to get reviews from the
community, and
in turn to enable the community to work on coreboot support for Xeon
Scalable
Processors based servers, with this patch set as a start point.
Yeah, but what I don't understand so far: Where is one supposed to get the required blob? And who produced it anyway? Does an NDA with Intel suffice? or does it need a three-party NDA with Intel and Facebook? For which (future?) platform can we expect a public binary if any?
This seems critical to me. With little documentation (if any at all) about the silicon initialization, no documentation about the blob (I assume?) and no binaries to at least test it, what do you expect from the review?
[1] https://www.youtube.com/watch?v=eVmx9n5FyDI [2] https://www.youtube.com/watch?v=lvAnj0k54Jw
Thanks. Um, do you have anything that is not on Youtube? One of the nice things of the mailing list is that it's archived. But that applies only to information inline in the e-mail, of course. Also, personally, I would prefer something with less java-script, less commercials, and less tracking.
Nico _______________________________________________ coreboot mailing list -- coreboot@coreboot.org To unsubscribe send an email to coreboot-leave@coreboot.org
Hi Marshall,
thanks for that cohesive report and insight into your development process and the trade-offs involved.
Am Mo., 27. Jan. 2020 um 21:12 Uhr schrieb Marshall Dawson < marshalldawson3rd@gmail.com>:
Instead, please give me the opportunity to review any of your changes that touch the picasso directory. If I have any concerns of building, I can test and run it locally, recommend solutions, etc. We can expect a few problems to slip through that process, which I will immediately discover prior to repushing my subsequent work. I will fix it, and allow you to review that work. I am also committed to converting anything resembling a fork to amd/common where it makes sense, and when the development priorities allow. The instant that mb/amd/mandolin lands, it will no longer be work-in-progress and it will undoubtedly build successfully.
Should we add stub mainboards for new chipsets that build the code as a way to make sure nobody else inadvertently breaks things (at least not too bad)? While it's reassuring to know that you intend to keep track of these things and sort them out, that would help other developers do changes with more confidence that they won't leave a huge mess in a hard-to-test area of the tree.
Ironically, I could have commonized the SMBus feature several times over
within the time we’ve had this discussion. I feel this is an important topic, however, so thank you for indulging me. Although I still won’t reprioritize this work ahead of what I promised to my stakeholders, I believe the time discussing this was valuable.
I'm quite sure that you won't forget all the little places that you intend to clean-up down the road. Would it help to document these somewhere, e.g. as issues on ticket.coreboot.org? Both for helping you keep track of things and to state publicly what you've postponed (so you don't have to argue every time somebody else gets the same idea that there's something that could be deduplicated).
Patrick
On Mon, Jan 27, 2020 at 3:57 PM Patrick Georgi via coreboot < coreboot@coreboot.org> wrote:
Hi Marshall,
thanks for that cohesive report and insight into your development process and the trade-offs involved.
Am Mo., 27. Jan. 2020 um 21:12 Uhr schrieb Marshall Dawson < marshalldawson3rd@gmail.com>:
Instead, please give me the opportunity to review any of your changes that touch the picasso directory. If I have any concerns of building, I can test and run it locally, recommend solutions, etc. We can expect a few problems to slip through that process, which I will immediately discover prior to repushing my subsequent work. I will fix it, and allow you to review that work. I am also committed to converting anything resembling a fork to amd/common where it makes sense, and when the development priorities allow. The instant that mb/amd/mandolin lands, it will no longer be work-in-progress and it will undoubtedly build successfully.
Should we add stub mainboards for new chipsets that build the code as a way to make sure nobody else inadvertently breaks things (at least not too bad)? While it's reassuring to know that you intend to keep track of these things and sort them out, that would help other developers do changes with more confidence that they won't leave a huge mess in a hard-to-test area of the tree.
having a src/mainboard/stub/<soc> for **all** SoC might not be a bad idea, especially if it were to select less common/non-default options that other in-tree boards don't select by default, to ensure full coverage of all SoC options.
Ironically, I could have commonized the SMBus feature several times over
within the time we’ve had this discussion. I feel this is an important topic, however, so thank you for indulging me. Although I still won’t reprioritize this work ahead of what I promised to my stakeholders, I believe the time discussing this was valuable.
I'm quite sure that you won't forget all the little places that you intend to clean-up down the road. Would it help to document these somewhere, e.g. as issues on ticket.coreboot.org? Both for helping you keep track of things and to state publicly what you've postponed (so you don't have to argue every time somebody else gets the same idea that there's something that could be deduplicated).
for a WIP SoC, seems like comments in the code/header files indicating WIP status or need to revisit would be a consistent, visible reminder that the code isn't "finalized"
Patrick
Google Germany GmbH, ABC-Str. 19, 20354 Hamburg Registergericht und -nummer: Hamburg, HRB 86891, Sitz der Gesellschaft: Hamburg Geschäftsführer: Paul Manicle, Halimah DeLaine Prado _______________________________________________ coreboot mailing list -- coreboot@coreboot.org To unsubscribe send an email to coreboot-leave@coreboot.org
On Mon, Jan 27, 2020 at 04:24:00PM -0600, Matt DeVillier wrote:
having a src/mainboard/stub/<soc> for **all** SoC might not be a bad idea, especially if it were to select less common/non-default options that other in-tree boards don't select by default, to ensure full coverage of all SoC options.
I think for non-default options, having more specimen of real world examples in configs/ is better simply because that means that we're optimizing for real-world configurations.
Patrick
Hi Marshall,
thank you very much for your huge elaboration. I had already given up all hope to see public communication from AMD. That's really great to see things change.
It's a lot to digest, I'll try to just briefly comment on my main concern, why I called it controversial: the unclear blob situation.
On 27.01.20 21:12, Marshall Dawson wrote:
Finally a word about blobs. Not that I think it belongs in the context of this discussion, but it seems to have been a source of bias against picasso.
Actually, that's why I started _this_ thread :)
This is a long-standing complaint, and for legitimate reasons. I also get a strong sense that the industry (and I’m thinking of OCP in particular) is coming to accept blobs as a necessary downside to using modern x86 processors, but that blobs must be redistributable (and Nico, no ideas either on Intel’s redistribution policies or expectations). I have no knowledge on how discussions within AMD stack up against discussions within Intel, of course. I realize many of you are aware of past broken promises to reopen AGESA, the reverse engineering research done on the PSP, and many other things. However, there are very powerful and influential people in AMD who want both AGESA and PSP open sourced sooner vs. later. If we see the day come when this begins to happen, an inherently slow process will ensue. I think too many people assume source can simply be dumped onto github, but they don’t understand the extensive legal and other processes required leading up to that point.
That's why I always encourage people to ask for documentation instead of code. Opening code that was developed in private is a pain for both sides. However, I guess it could be taken as a good omen; that a silicon vendor won't forbid open implementations.
Anyway, it's clear to me that we have to accept blobs for Picasso for the time being. The question is more if these blobs will
a) be public, and b) if public, generally usable for new boards (or rather product specific).
For me (maybe for others too) this is the turning point if a platform is worth my time. If small companies and individuals can't make use of the supposedly free software, it obviously doesn't get much support from them... and neither does it before this question is answered.
Nico
Patrick,
Should we add stub mainboards for new chipsets that build the code as a way to make sure nobody else inadvertently breaks things (at least not too bad)?
That's an interesting idea. A benefit that I see is that it's then demonstrable how changes and additions affect the mainboard. For example, one of the patches in my stack adds FSP support into the soc, which places requirements on the mainboard. Currently the very top mb/amd/mandolin patch simply looks like it's dropped into the directory as a rather large change, and will someday expect a reviewer to understand what the soc is doing.
Would it help to document these somewhere, e.g. as issues on
ticket.coreboot.org? Both for helping you keep track of things and to state publicly what you've postponed (so you don't have to argue every time somebody else gets the same idea that there's something that could be deduplicated).
for a WIP SoC, seems like comments in the code/header files indicating WIP
status or need to revisit would be a consistent, visible reminder that the code isn't "finalized"
Another good idea. My plan was to simply audit the work once Mandolin lands, i.e. do a file-file comparison with stoneyridge as that was the intended starting point. All changes should be recognizable.
For "WIP", I've been using that prior to patches landing, i.e. once I remove "WIP" I feel good about its ability to withstand review, etc. While I've not considered tying to land patches with that string present, I've definitely added some "TODO" items. But that's for something that is a "need to" vs. "would be better to". I'm not sure I have a good string in mind for the "would be better to", although occasionally I'll stick in the commit message that "future work may consider".
Nico,
Finally a word about blobs. Not that I think it belongs in the context
of
this discussion, but it seems to have been a source of bias against picasso.
Actually, that's why I started _this_ thread :)
Oh, sorry for making it all about me, then. I read Picasso in the original post, and misinterpreted the intention as purely a continuation of the CB:38221 discussion.
That's why I always encourage people to ask for documentation instead
of code. Opening code that was developed in private is a pain for both sides. However, I guess it could be taken as a good omen; that a silicon vendor won't forbid open implementations.
For our FSP implementation, I intend to rely on the FSP 2.0 EAS published by Intel then document the important differences, which I hope is extremely minimal. Then there will also be a Picasso-specific Integration Guide, again similar to Intel's docs. This leaves us subject to many of the complaints in CB:36328, however I'm trying to do my best to avoid as much of that as possible -- I forwarded your RFC to my team, asked them to read it carefully to understand FSP customers' concerns, and told them I fully expect us to outshine Intel. By the way, picasso now faces some of the same challenges with AGESA that stoneyridge did. The traditional AMD mindset is/was to keep as much as possible in AGESA and there's inertia to keep that in place. For stoneyridge, we wanted as much as possible in coreboot instead, and moving some of it to coreboot was an absolute requirement. Gaining permission to port closed AGESA code to open source was not very difficult in those cases.
On the PSP, if forced to make a prediction, I'd bet the code would be rewritten for the purpose of open sourcing it. Regarding documenting it, however, I've been somewhat careful for several years to not move much into the public domain, as the information was coming from an NDA publication. To date, I've been trying to walk a fine line of the code/utill serving as documentation (I haven't studied the reverse-engineered info carefully, nor lately, but it's likely just as complete.) Recently our PSP team forwarded a text file for the purposes of publishing. I cleaned that up and augmented it with additional information already now publicly known. It's not been a priority to get it reviewed and landed however. That work can be found at CB:37847.
Assuming one day source becomes available for the PSP, the challenge for free software still remains of signing the blobs. It's hard to imagine that ever going away.
Thanks, Marshall
On Mon, Jan 27, 2020 at 4:25 PM Nico Huber nico.h@gmx.de wrote:
Hi Marshall,
thank you very much for your huge elaboration. I had already given up all hope to see public communication from AMD. That's really great to see things change.
It's a lot to digest, I'll try to just briefly comment on my main concern, why I called it controversial: the unclear blob situation.
On 27.01.20 21:12, Marshall Dawson wrote:
Finally a word about blobs. Not that I think it belongs in the context
of
this discussion, but it seems to have been a source of bias against picasso.
Actually, that's why I started _this_ thread :)
This is a long-standing complaint, and for legitimate reasons. I also get a strong sense that the industry (and I’m thinking of OCP in particular) is coming to accept blobs as a necessary downside to using modern x86 processors, but that blobs must be redistributable (and Nico,
no
ideas either on Intel’s redistribution policies or expectations). I have no knowledge on how discussions within AMD stack up against discussions within Intel, of course. I realize many of you are aware of past broken promises to reopen AGESA, the reverse engineering research done on the
PSP,
and many other things. However, there are very powerful and influential people in AMD who want both AGESA and PSP open sourced sooner vs. later. If we see the day come when this begins to happen, an inherently slow process will ensue. I think too many people assume source can simply be dumped onto github, but they don’t understand the extensive legal and
other
processes required leading up to that point.
That's why I always encourage people to ask for documentation instead of code. Opening code that was developed in private is a pain for both sides. However, I guess it could be taken as a good omen; that a silicon vendor won't forbid open implementations.
Anyway, it's clear to me that we have to accept blobs for Picasso for the time being. The question is more if these blobs will
a) be public, and b) if public, generally usable for new boards (or rather product specific).
For me (maybe for others too) this is the turning point if a platform is worth my time. If small companies and individuals can't make use of the supposedly free software, it obviously doesn't get much support from them... and neither does it before this question is answered.
Nico
Hi Marshall,
On 28.01.20 02:12, Marshall Dawson wrote:
That's why I always encourage people to ask for documentation instead of code. Opening code that was developed in private is a pain for both sides. However, I guess it could be taken as a good omen; that a silicon vendor won't forbid open implementations.
For our FSP implementation, I intend to rely on the FSP 2.0 EAS published by Intel then document the important differences, which I hope is extremely minimal. Then there will also be a Picasso-specific Integration Guide, again similar to Intel's docs. This leaves us subject to many of the complaints in CB:36328, however I'm trying to do my best to avoid as much of that as possible -- I forwarded your RFC to my team, asked them to read it carefully to understand FSP customers' concerns, and told them I fully expect us to outshine Intel.
sounds great. But before you can outrun them you have to catch up. And I fear you might try to take shortcuts. I don't want to tell you how to do your job, but here is what I'd try to do (I guess an extreme): Do whatever needs to be done for the priority customers when writing code, but only start writing code for upstream coreboot when there is also public documentation about the chips. If you start earlier, you exclude too many people from collaboration. Just in case you don't know, there is not even a public datasheet to be found that would acknowledge that Ryzen, Picasso etc. are SoCs with FCH like components.
By the way, picasso now faces some of the same challenges with AGESA that stoneyridge did. The traditional AMD mindset is/was to keep as much as possible in AGESA and there's inertia to keep that in place. For stoneyridge, we wanted as much as possible in coreboot instead, and moving some of it to coreboot was an absolute requirement. Gaining permission to port closed AGESA code to open source was not very difficult in those cases.
Thanks. Makes me hope again :)
Nico
On 1/27/20, 10:56 AM, "Nico Huber" nico.h@gmx.de wrote:
Hi Jonathan,
thanks for your email. It's become very rare that developers take part in mailing-list discussions when they are asked to. So it's really appreciated. Jumping to conclusion without knowing context could cause distractions.
On 27.01.20 17:21, Jonathan Zhang (Infra) wrote: > On 1/26/20, 11:32 AM, "Nico Huber" nico.h@gmx.de wrote: >> >> Hi David, >> >>On 26.01.20 20:15, David Hendricks wrote: >>> On Sat, Jan 25, 2020 at 4:44 PM Nico Huber nico.h@gmx.de wrote: >>>> There are currently two new platforms in development that seem to >>>> have trouble with public binaries (which would be necessary to make >>>> the code useful to the coreboot community). Namely, AMD/Picasso and >>>> Intel/Skylake-SP. Support for the former is already partially rotting >>>> on our master branch. Shouldn't we discuss their fate before more >>>> resources are wasted? >>> >>> I happen to know that for the latter the whole point of uploading it >>> in its current state was to get some feedback. The authors gave a live >>> demo of it last fall at the OCP Summit in Europe and wanted to finally >>> get some code published, which itself was quite a feat. >>> >>> As for their fate, I think we need to look forward and not just >>> backward. The code was pushed upstream with the intent of being used >>> in real products and not just for the fun of putting a bunch of >>> unusable code on display and making peoples' lives difficult. It also >>> serves as a starting point for future work. >>> >>> That said, it's fair to say that if nothing uses that code then >>> perhaps it should be removed from the master branch. In Picasso's >>> case, there is a mainboard in progress (CB:33772), and given the >>> timeline I suspect there was a previous board that got cancelled >>> (stuff doesn't always go as planned...). In Skylake-SP and Tioga Pass >>> case, the hardware already exists and is in production but the blob >>> situation might prevent it from being usable by the community, but the >>> code is already being used as a starting point for the next generation >>> platform. >> >> sounds like good progress. Though, you make it look like SKL-SP support >> is just a code drop. If there is no intention to get it into shape and >> working with upstream coreboot, together with the community, should we >> merge it? Jonathan seems to work hard to clean the patches "formally >> into shape" (i.e. fixing checkpatch issues), but that's not all that >> matters, is it? > > It is NOT just a code drop.
Don't worry. Maybe that came out wrong. What I meant is that /if/ the SKL-SP code will not be usable by anyone else, there'll probably be little interest in the community to work on it. Hence, the code would likely just stay as is. So what upstream it for? (that's not a retho- rical question, I'm really asking for expectations) At this moment, I cannot promise that SKL-SP code will be used in data center, even though there is indeed a chance. That being said, our vision is not limited to SKL-SP, our target is all (especially future Xeon SP processors). Making SKL-SP (note that people normally short it to SKX-SP, instead of SKL-SP) supported in Coreboot is an endeavor of starting enablement of coreboot to support Xeon-SP.
We had this before: Something that nobody really cared about was upstreamed. And then later, it was copied for newer platforms and people were confused by the feedback that they didn't get for the original platform's code (they expected that what was acceptable for the platform that nobody cared about would always be accepted). I'm not saying that this is the wrong way. Just that from my point of view, we had bad experience with it. Most industry projects fail in the end. I hope this one does not. Let's work together to make it happens. The difficulty is not just at technology side, it is more on the process side and business side. There is a chicken and egg problems between coreboot support for Xeon-SP and FSP support for Xeon-SP. I hope the community is sensitive to the engineers working in silicon vendor. Let's encourage them and support them, it is not easy to turn around a big ship. al > It is backed up by a huge commitment, multi-company > collaboration and a long term roadmap.
Sounds nice. If it's really long term, i.e. covering more than a few months, maybe it's even worth to add that roadmap to coreboot's Documentation/ folder? Generally, in my experience, the more infor- mation is available before a review, the better the review will be. Good point, we are working on documentations, not aimed for this patch set though, both because of resource constraint and because more work is needed to understand the technology.
> For some context, please refer to [1] and > [2]. The intention of this upstream is to get reviews from the community, and > in turn to enable the community to work on coreboot support for Xeon Scalable > Processors based servers, with this patch set as a start point.
Yeah, but what I don't understand so far: Where is one supposed to get the required blob? And who produced it anyway? Does an NDA with Intel suffice? or does it need a three-party NDA with Intel and Facebook? For which (future?) platform can we expect a public binary if any?
This seems critical to me. With little documentation (if any at all) about the silicon initialization, no documentation about the blob (I assume?) and no binaries to at least test it, what do you expect from the review? Without coreboot able to support Xeon-SP, silicon vendor is rightly hesitate to make Xeon-SP FSP as a product. Instead of wishing others to do something, let's firm up coreboot support, and we have allies helping us.
> [1] https://www.youtube.com/watch?v=eVmx9n5FyDI > [2] https://www.youtube.com/watch?v=lvAnj0k54Jw
Thanks. Um, do you have anything that is not on Youtube? One of the nice things of the mailing list is that it's archived. But that applies only to information inline in the e-mail, of course. Also, personally, I would prefer something with less java-script, less commercials, and less tracking.
Nico
Hi Jonathan,
On 27.01.20 23:01, Jonathan Zhang (Infra) wrote:
On 1/27/20, 10:56 AM, "Nico Huber" nico.h@gmx.de wrote:
We had this before: Something that nobody really cared about was upstreamed. And then later, it was copied for newer platforms and people were confused by the feedback that they didn't get for the original platform's code (they expected that what was acceptable for the platform that nobody cared about would always be accepted). I'm not saying that this is the wrong way. Just that from my point of view, we had bad experience with it.
Most industry projects fail in the end. I hope this one does not. Let's work together to make it happens.
I think we are caught in a loop. How can we work together if only you have the blob?
The difficulty is not just at technology side, it is more on the process side and business side. There is a chicken and egg problems between coreboot support for Xeon-SP and FSP support for Xeon-SP. I hope the community is sensitive to the engineers working in silicon vendor. Let's encourage them and support them, it is not easy to turn around a big ship.
So, the first code would just be in the coreboot repository to raise a flag there? So people (at Intel) can see it, not use it?
This seems critical to me. With little documentation (if any at all) about the silicon initialization, no documentation about the blob (I assume?) and no binaries to at least test it, what do you expect from the review?
Without coreboot able to support Xeon-SP, silicon vendor is rightly hesitate to make Xeon-SP FSP as a product. Instead of wishing others to do something, let's firm up coreboot support, and we have allies helping us.
Here I see another company that wants Intel to write firmware. I'm not convinced that is a good idea. Have you evaluated alternatives? If one looks close at Intel's reference code, it's clear that it's mostly boilerplate. Writing new code could considerably reduce its complexity and make things much easier. After a few years with FSP, I'm convinced that writing clean code would be cheaper than the FSP integration with all its avoidable complexity. Intel might not like it, but you could reach proper coreboot support much faster without FSP.
Nico
Writing new code could considerably reduce its complexity and make things much easier. After a few years with FSP, I'm convinced that writing clean code would be cheaper than the FSP integration with all its avoidable complexity. Intel might not like it, but you could reach proper coreboot support much faster without FSP.
Assuming that's true from an engineering perspective and we're clear to publish all code/info needed, we'd first need to invent a way to send an electric shock thru the keyboard to users who complain to (or about) Intel when something goes wrong with the code.
David Hendricks david.hendricks@gmail.com schrieb am Mi., 29. Jan. 2020, 00:51:
we'd first need to invent a way to send an electric shock thru the keyboard to users who complain to (or about) Intel when something goes wrong with the code.
That may have been necessary in the era of the fdiv bug but I'm not sure this trope is still applicable to today:
The concern is that something outside Intel's control reflected badly onto Intel, but our industry seems fully exempt of consequences (except for revenue being in the up and up) even when participants are fully responsible that I don't know how this can be true:
Take Intel, their chips make news every few weeks because another side channel attack was discovered and besides some (probably uncomfortable) news cycle the only results seem to be that they still sell chips faster than they can produce them and that they provide workarounds that reduce performance by, I think, 25% (and counting) less than what people paid for? Meanwhile Intel's quarterly reports look fabulous.
And this issue is by no means Intel specific, the entire industry managed to somehow replace responsibility with a short uncomfortable news cycle that is forgotten 24 hours later. No matter if hardware, software (what other paid product requires monthly maintenance cycles?) or even users (who opt to not even do that maintenance and instead pretend that any malware they suffer from is a force of nature instead of pain old neglect), there just are no consequences.
And now we need to prevent users from whining at the wrong folks with something as drastic as remote shocks? Something doesn't seem to add up.
Patrick
On 26.01.20 20:15, David Hendricks wrote:
On Sat, Jan 25, 2020 at 4:44 PM Nico Huber nico.h@gmx.de wrote:
we've recently seen the deprecation of Intel/Broadwell-DE support because it turned out to be too proprietary to be maintained in the long run.
To be fair, the FSP 1.0 platforms (Broadwell-DE, Baytrail, Rangeley) had a pretty long run in master. It was only when certain important coreboot features were introduced and plenty of warning that FSP 1.0 needed to be deprecated that those SoCs were deemed unmaintainable in master and moved to 4.11_branch.
Let me briefly explain why I think it wasn't deemed maintainable. There were fundamental problems with the FSP blob. Though, we could have main- tained it by either:
a) Fixing it in the source code (and releasing a new binary). b) Fixing it in the binary. c) Working around the issues in coreboot.
Due to the proprietary nature, a) could only have been done by Intel. b) is forbidden by Intel in the FSP license. c) didn't happen, I guess because people didn't try hard enough as they were promised a).
Heck, even after that platforms are still being released using that code such as the Librem Server. It's still used and maintained, just not in the master branch.
That's actually a good point, "not in the master branch". With the two new platforms that I mentioned initially (Intel/Skylake-SP, AMD/ Picasso), we (potentially, in the Picasso case) have even worse blob situations. By allowing that on the master branch, we're creating demons that guard parts of the source tree from collaboration.
IMO, we have just seen one of these creating a bottleneck that was way too frustrating for three important contributors. I think we should try to prevent such friction in the future, not by trying to work around, but by avoiding the cause.
Nico
Nico,
For our FSP implementation, I intend to rely on the FSP 2.0 EAS published
by Intel then document the important differences, which I hope is
extremely
minimal. Then there will also be a Picasso-specific Integration Guide, again similar to Intel's docs. This leaves us subject to many of the complaints in CB:36328, however I'm trying to do my best to avoid as much of that as possible -- I forwarded your RFC to my team, asked them to
read
it carefully to understand FSP customers' concerns, and told them I fully expect us to outshine Intel.
sounds great. But before you can outrun them you have to catch up. And I fear you might try to take shortcuts. I don't want to tell you how to do your job, but here is what I'd try to do (I guess an extreme): Do whatever needs to be done for the priority customers when writing code, but only start writing code for upstream coreboot when there is also public documentation about the chips. If you start earlier, you exclude too many people from collaboration. Just in case you don't know, there is not even a public datasheet to be found that would acknowledge that Ryzen, Picasso etc. are SoCs with FCH like components.
Nico, I completely agree that we're not there yet. The Picasso FSP is still a work in progress. Anyone with access to the v9 AGESA and historical knowledge of AGESA in coreboot would likely identify similar complaints in the design. Given what my team has learned from the FSP conversion, the intention to minimize FSP efforts for future designs (and potentially better flexibility in deploying AGESA in other ways), we're driving changes back into the AGESA trunk right now. This type of action had been requested of AMD for 6-8 (?) years and we're getting it done now.
Hopefully we'll exceed your expectations. If you suspect the solution will target only priority customers, then it shouldn't be very difficult. I've also personally dealt with shortcomings in the Intel FSP offerings, so I'm sensitive to the consumer's experience. I'll skip further descriptions of our sausage factory, but my team knows I'm adamant we're enabling coreboot and FSP for everyone and not some customer. I'm confident we'll encounter unforeseen gotchas along the way. For example, I recall years ago, our Embedded System customers tried to utilize a particular GPIO and we were all surprised it didn't work properly -- it turned out AGESA had co-opted it, but it was never documented anywhere. All non-Embedded designs were simply instructed not to use the GPIO. About a week ago, we discovered a CMOS location baked into the design. ...still a work in progress. However I recall similar experiences with the earlier Intel FSPs too. BTW I'll infer "here is what I'd try to do..." as "what I would be tempted to do".
Granted Google made modifications to their version of the Stoney Ridge binaryPI and corresponding changes in coreboot to support them. I really hope to get that code back and upstream the binaries so that we're all on the same page. I haven't asked for permission from the right people, or with adequate urgency, yet. BTW behind the scenes I'm also working to solve the problem we've discussed of single-sourced contractors owning the source and creation of AGESA blobs.
Regarding upstream code and documentation, as I mentioned on another thread, AMD's PPR for Picasso (i.e. the equivalent of BKDG on previous generations) was nearly nonexistent when we started. IIRC it was primarily architectural registers you could get from anywhere; hardly anything unique to Picasso except perhaps CPUID indicators. Google and I demanded from AMD that registers we would use had to be openly available. The best we could negotiate was that anything unique would be requested on a case-by-case basis and they would either be opened or denied (precluding their usage). Also, anything that was mostly identical to previous generations, e.g. in the FCH, I had an implied permission to push. The resulting public spec is as holey as you'd expect. I predict this will continue to be a challenge for a while. The PSP specs have always been NDA only, and not likely to change.
but only start writing code for upstream coreboot...
No, Picasso was always "upstream first". Until you mentioned it, I'd forgotten that Stoney Ridge had been developed "internal first", although it was eventually completely revamped. Two things come to mind for Picasso. (1) When AMD first put out the Picasso RFP, they wanted everything to be internal-only. I inferred this was partly because of NDA info and partly hopes of hiding any intentions. This is part of what I now call the "old thinking", and we helped them to see why that would be a huge mistake (for exactly the reasons everyone here would suggest). (2) The "fork" we've talked about was from August-ish; a snapshot of the WIP at coreboot.org. This was done only so that other scheduled effort could continue without waiting for the WIP to land -- that other work doesn't depend on the underlying x86 init sequence.
Thanks, Marshall
On Wed, Jan 29, 2020 at 3:58 AM Nico Huber nico.h@gmx.de wrote:
On 26.01.20 20:15, David Hendricks wrote:
On Sat, Jan 25, 2020 at 4:44 PM Nico Huber nico.h@gmx.de wrote:
we've recently seen the deprecation of Intel/Broadwell-DE support because it turned out to be too proprietary to be maintained in the long run.
To be fair, the FSP 1.0 platforms (Broadwell-DE, Baytrail, Rangeley) had a pretty long run in master. It was only when certain important coreboot features were introduced and plenty of warning that FSP 1.0 needed to be deprecated that those SoCs were deemed unmaintainable in master and moved to 4.11_branch.
Let me briefly explain why I think it wasn't deemed maintainable. There were fundamental problems with the FSP blob. Though, we could have main- tained it by either:
a) Fixing it in the source code (and releasing a new binary). b) Fixing it in the binary. c) Working around the issues in coreboot.
Due to the proprietary nature, a) could only have been done by Intel. b) is forbidden by Intel in the FSP license. c) didn't happen, I guess because people didn't try hard enough as they were promised a).
Heck, even after that platforms are still being released using that code such as the Librem Server. It's still used and maintained, just not in the master branch.
That's actually a good point, "not in the master branch". With the two new platforms that I mentioned initially (Intel/Skylake-SP, AMD/ Picasso), we (potentially, in the Picasso case) have even worse blob situations. By allowing that on the master branch, we're creating demons that guard parts of the source tree from collaboration.
IMO, we have just seen one of these creating a bottleneck that was way too frustrating for three important contributors. I think we should try to prevent such friction in the future, not by trying to work around, but by avoiding the cause.
Nico _______________________________________________ coreboot mailing list -- coreboot@coreboot.org To unsubscribe send an email to coreboot-leave@coreboot.org
While it's not my preference, I'm fine with pulling picasso out of the tree and doing the development in private if that's the community desire. When we're done, it can go in, or not, as the coreboot community chooses. Because we can't boot what's in coreboot currently, we're being forced to develop the platforms in private anyway.
I'd like to note that the only reason it's "Rotting" is because we weren't able to get the patches in to get it working. Sure, they weren't perfect, but it's a new and different architecture. Instead of forcing google to develop it in private so that we can have something working, maybe we could have gotten something working into the codebase, then improved upon it.
Maybe have a look at what's being forced on us before complaining about how we're going about it?
On Sat, Jan 25, 2020 at 5:44 PM Nico Huber nico.h@gmx.de wrote:
Hello coreboot fellows,
we've recently seen the deprecation of Intel/Broadwell-DE support because it turned out to be too proprietary to be maintained in the long run. With that in mind, shouldn't additions to coreboot that have high chances to suffer the same fate be discussed in advance? It seems a huge burden for the community to add proprietary support for a platform, and all related effort is wasted if support can't be maintained.
There are currently two new platforms in development that seem to have trouble with public binaries (which would be necessary to make the code useful to the coreboot community). Namely, AMD/Picasso and Intel/Skylake-SP. Support for the former is already partially rotting on our master branch. Shouldn't we discuss their fate before more resources are wasted?
Nico _______________________________________________ coreboot mailing list -- coreboot@coreboot.org To unsubscribe send an email to coreboot-leave@coreboot.org
Hi Martin,
On 26.01.20 20:36, Martin Roth wrote:
While it's not my preference, I'm fine with pulling picasso out of the tree and doing the development in private if that's the community desire. When we're done, it can go in, or not, as the coreboot community chooses. Because we can't boot what's in coreboot currently, we're being forced to develop the platforms in private anyway.
I'd like to note that the only reason it's "Rotting" is because we weren't able to get the patches in to get it working. Sure, they weren't perfect, but it's a new and different architecture. Instead of forcing google to develop it in private so that we can have something working, maybe we could have gotten something working into the codebase, then improved upon it.
Maybe have a look at what's being forced on us before complaining about how we're going about it?
I'm really confused now, you are the third one that argues that build tests would force you to work in private. I don't see the causality here.
Why is it easier to work in public when you have a stale copy of your platform on the master branch instead of the start of your commit queue?
Or am I just to irritated to unterstand... do you mean private => Gerrit public => master branch?
Nico
On 26.01.20 21:09, Nico Huber wrote:
Hi Martin,
On 26.01.20 20:36, Martin Roth wrote:
While it's not my preference, I'm fine with pulling picasso out of the tree and doing the development in private if that's the community desire. When we're done, it can go in, or not, as the coreboot community chooses. Because we can't boot what's in coreboot currently, we're being forced to develop the platforms in private anyway.
I'd like to note that the only reason it's "Rotting" is because we weren't able to get the patches in to get it working. Sure, they weren't perfect, but it's a new and different architecture. Instead of forcing google to develop it in private so that we can have something working, maybe we could have gotten something working into the codebase, then improved upon it.
Maybe have a look at what's being forced on us before complaining about how we're going about it?
I'm really confused now, you are the third one that argues that build tests would force you to work in private. I don't see the causality here.
Why is it easier to work in public when you have a stale copy of your platform on the master branch instead of the start of your commit queue?
Or am I just to irritated to unterstand... do you mean private => Gerrit public => master branch?
Argh, sorry, forget all I said. I read your mail in the wrong context (got lost between email threads). If it's not too much to ask for, please top quote.
Nico
The picasso platforms are being worked on in a private repo because it's not bootable at coreboot.org. It's not bootable because the patches that would make it bootable were delayed and rejected.
What's the incentive to work on anything at coreboot.org? Why should any company work at coreboot.org when we just get complaints and grief?
Personally, I'm tired of dealing with it. It's become too toxic, so I'm retiring from the project.
Martin
On Sun, Jan 26, 2020 at 1:09 PM Nico Huber nico.h@gmx.de wrote:
Hi Martin,
On 26.01.20 20:36, Martin Roth wrote:
While it's not my preference, I'm fine with pulling picasso out of the tree and doing the development in private if that's the community desire. When we're done, it can go in, or not, as the coreboot community chooses. Because we can't boot what's in coreboot currently, we're being forced to develop the platforms in private anyway.
I'd like to note that the only reason it's "Rotting" is because we weren't able to get the patches in to get it working. Sure, they weren't perfect, but it's a new and different architecture. Instead of forcing google to develop it in private so that we can have something working, maybe we could have gotten something working into the codebase, then improved upon it.
Maybe have a look at what's being forced on us before complaining about how we're going about it?
I'm really confused now, you are the third one that argues that build tests would force you to work in private. I don't see the causality here.
Why is it easier to work in public when you have a stale copy of your platform on the master branch instead of the start of your commit queue?
Or am I just to irritated to unterstand... do you mean private => Gerrit public => master branch?
Nico
Hey Martin,
On 26.01.20 21:21, Martin Roth wrote:
The picasso platforms are being worked on in a private repo because it's not bootable at coreboot.org. It's not bootable because the patches that would make it bootable were delayed and rejected.
I'm sorry that you had trouble with your patches. I didn't know about it.
What's the incentive to work on anything at coreboot.org? Why should any company work at coreboot.org when we just get complaints and grief?
Idealistic goals aside, one can get their code maintained for free! I think there is also great value in working together. One gets a code review for free. Which is, IMHO, one third of the development costs.
I can't say what was going wrong with Picasso. I turned my back on it after the very first commit scared me away, so I really missed the last half year. Maybe the grief came because complaints were ignored? maybe not? Not a single mail passed the mailing list, how are people supposed to know?
Personally, I'm tired of dealing with it. It's become too toxic, so I'm retiring from the project.
Sad to hear that. Especially because I seem to have triggered it. Believe me, when I tried to discuss the binary situation, I had no idea about the feelings that already piled up on Gerrit (or in private conversations, what do I know).
Nico
On 26.01.20 20:36, Martin Roth wrote:
While it's not my preference, I'm fine with pulling picasso out of the tree and doing the development in private if that's the community desire. When we're done, it can go in, or not, as the coreboot community chooses. Because we can't boot what's in coreboot currently, we're being forced to develop the platforms in private anyway.
I know, there is a lot discussion about Picasso going on in private for reasons you can't control. But is it possible to give us an update on the binary situation? So far, what I could grasp is that it might end up being a Chromebook only solution?
Nico
I am shipping a product based on Broadwell-DE and FSP 1.0. It’s very disappointing to have to rely on binary blobs and I wish I could do better, but I’d rather ship with coreboot than proprietary UEFI.
I expected to upstream my code at some point but if FSP 1.0 support is being deprecated I can live with the code as it is today.
I have 8-core systems working but there are bugs that keep us from shipping the 12 and 16 core systems. I will probably be having a consultant with a FSP source license help us when we want to ship those systems.
I would love to develop open alternatives, but don’t have the tools (hardware JTAG debugger, etc) to pull it off. I’m a lot more comfortable on ARM, MIPS, PowerPC, where there are available hardware debuggers. x86 is a painful mystery to me. We are too early stage in my company to fund others to do this development as well.
Kevin
On Jan 26, 2020, at 14:23, Nico Huber nico.h@gmx.de wrote:
On 26.01.20 20:36, Martin Roth wrote:
While it's not my preference, I'm fine with pulling picasso out of the tree and doing the development in private if that's the community desire. When we're done, it can go in, or not, as the coreboot community chooses. Because we can't boot what's in coreboot currently, we're being forced to develop the platforms in private anyway.
I know, there is a lot discussion about Picasso going on in private for reasons you can't control. But is it possible to give us an update on the binary situation? So far, what I could grasp is that it might end up being a Chromebook only solution?
Nico _______________________________________________ coreboot mailing list -- coreboot@coreboot.org To unsubscribe send an email to coreboot-leave@coreboot.org
On Sun, Jan 26, 2020 at 12:38 PM Kevin Paul Herbert kevin@trippers.org wrote:
I am shipping a product based on Broadwell-DE and FSP 1.0. It’s very disappointing to have to rely on binary blobs and I wish I could do better, but I’d rather ship with coreboot than proprietary UEFI.
I expected to upstream my code at some point but if FSP 1.0 support is being deprecated I can live with the code as it is today.
It's still alive and well in 4.11_branch. Please feel free to send patches if you've got 'em ready: `git push origin HEAD:refs/for/4.11_branch`
The reason it was removed from master had to do with some architectural changes that were impossible to reconcile with FSP 1.0. More info is here https://review.coreboot.org/c/coreboot/+/37064
I have 8-core systems working but there are bugs that keep us from shipping the 12 and 16 core systems. I will probably be having a consultant with a FSP source license help us when we want to ship those systems.
I happen to know one who has dealt with this issue. PM me if you'd like to discuss further.
-
David Hendricks -
Jonathan Zhang (Infra) -
Kevin Paul Herbert -
Marshall Dawson -
Martin Roth -
Matt DeVillier -
Nico Huber -
Patrick Georgi