Deprecation of the Intel Quark SoC
Hi all, to me it seems like the Intel Quark SoC has been unmaintained and unused for a long time now. So I'm proposing to deprecate the support for it with coreboot release 4.17 [1], in order to drop the support with release 4.19 so that the community has less maintenance overhead. Does anyone use this platform? Any opinions against this? // Felix [1] https://review.coreboot.org/c/coreboot/+/63283
go for it. Long overdue. On Thu, Mar 31, 2022 at 1:55 PM Felix Singer <felixsinger@posteo.net> wrote:
Hi all,
to me it seems like the Intel Quark SoC has been unmaintained and unused for a long time now. So I'm proposing to deprecate the support for it with coreboot release 4.17 [1], in order to drop the support with release 4.19 so that the community has less maintenance overhead.
Does anyone use this platform? Any opinions against this?
// Felix
[1] https://review.coreboot.org/c/coreboot/+/63283 _______________________________________________ coreboot mailing list -- coreboot@coreboot.org To unsubscribe send an email to coreboot-leave@coreboot.org
Dear Felix, Am 31.03.22 um 22:55 schrieb Felix Singer:
to me it seems like the Intel Quark SoC has been unmaintained and unused for a long time now.
Can you be more specific please?
So I'm proposing to deprecate the support for it with coreboot release 4.17 [1], in order to drop the support with release 4.19 so that the community has less maintenance overhead.
Does anyone use this platform? Any opinions against this?
It’s my understanding, up to now missing maintainership and unknown working status were no reasons for deprecation/removal. It was more, that it’s too difficult to move the chipset/SOC to newer code infrastructure(?) or coreboot features, because of the quality of the code. Can you please give these examples? Kind regards, Paul
Felix Singer wrote:
to me it seems like the Intel Quark SoC has been unmaintained and unused for a long time now. So I'm proposing to deprecate the support for it with coreboot release 4.17 [1], in order to drop the support with release 4.19 so that the community has less maintenance overhead.
Does anyone use this platform? Any opinions against this?
What Paul wrote; are there some practical concerns beyond the academic concern seemingly based on perceived utility? Quark is funny and as I understand also the ME CPU, I find those to be two more good reasons not to delete it. //Peter
Does anyone even have one? Has anyone done a build and burn recently to test? Has anyone volunteered to maintain it? How much does it it impact other code as a special case? I threw mine out years ago. On Fri, Apr 1, 2022 at 6:19 AM Peter Stuge <peter@stuge.se> wrote:
Felix Singer wrote:
to me it seems like the Intel Quark SoC has been unmaintained and unused for a long time now. So I'm proposing to deprecate the support for it with coreboot release 4.17 [1], in order to drop the support with release 4.19 so that the community has less maintenance overhead.
Does anyone use this platform? Any opinions against this?
What Paul wrote; are there some practical concerns beyond the academic concern seemingly based on perceived utility?
Quark is funny and as I understand also the ME CPU, I find those to be two more good reasons not to delete it.
//Peter _______________________________________________ coreboot mailing list -- coreboot@coreboot.org To unsubscribe send an email to coreboot-leave@coreboot.org
On Fri, 2022-04-01 at 14:21 -0700, ron minnich wrote:
Does anyone even have one? Has anyone done a build and burn recently to test? Has anyone volunteered to maintain it? How much does it it impact other code as a special case?
I threw mine out years ago.
On Fri, Apr 1, 2022 at 6:19 AM Peter Stuge <peter(a)stuge.se> wrote:
Felix Singer wrote:
to me it seems like the Intel Quark SoC has been unmaintained and unused for a long time now. So I'm proposing to deprecate the support for it with coreboot release 4.17 [1], in order to drop the support with release 4.19 so that the community has less maintenance overhead.
Does anyone use this platform? Any opinions against this?
What Paul wrote; are there some practical concerns beyond the academic concern seemingly based on perceived utility?
Quark is funny and as I understand also the ME CPU, I find those to be two more good reasons not to delete it.
//Peter _______________________________________________ coreboot mailing list -- coreboot(a)coreboot.org To unsubscribe send an email to coreboot-leave(a)coreboot.org
^this It feels this is the usual "but what if *someone* out there *needs/wants* it?". The last commit with documented boot test was in 2017 (48dbc663d7, correct me if I'm wrong, please). Does anyone know if the platform still works, at all? If not, let's drop it. Michael
Michael Niewöhner wrote:
It feels this is the usual "but what if *someone* out there *needs/wants* it?".
Not quite, it's "why delete it if it might work?". This is still ideological of course, so the question becomes what we find valuable. I e.g. do not consider it at all valuable to only keep code for the last n Intel platform generations, in spite of knowing that only those have any value whatsoever for the vast majority of coreboot users. But coreboot is not a company and thus not restricted to only value market demand or otherwise proven utility. We can have other values and I do.
Does anyone know if the platform still works, at all?
Does anyone know that the platform *doesn't* work? Are there any practical concerns whatsoever? For me, at a very minimum both those questions must have a yes answer to qualify deletion. Reducing scope is always satisfying but that's not a good reason to delete platforms. It is of course very easy to manufacture practical concerns, but maybe that's a fair enough hurdle for arbitrary deletion... //Peter
On Sat, 2022-04-02 at 13:14 +0000, Peter Stuge wrote:
Michael Niewöhner wrote:
It feels this is the usual "but what if *someone* out there *needs/wants* it?".
Not quite, it's "why delete it if it might work?". This is still ideological of course, so the question becomes what we find valuable.
I e.g. do not consider it at all valuable to only keep code for the last n Intel platform generations, in spite of knowing that only those have any value whatsoever for the vast majority of coreboot users.
Keeping platforms where there is no active interest is burden for those doing tree / architecture / platform family wide changes. soc/intel is the best example for that. Also, often changes to common code (like soc/intel, again) have unforseeable impact on untested platforms. Thus, it doesn't make *any* sense, keeping them "just because". Getting such changes merged without anyone being able to test a specific platform that is being kept "just because" is nearly impossible. Take a look at soc/intel/common changes, where xeon-sp and denverton regularly sled in.
But coreboot is not a company and thus not restricted to only value market demand or otherwise proven utility. We can have other values and I do.
Does anyone know if the platform still works, at all?
Does anyone know that the platform *doesn't* work?
See above. I bet it's broken already. (Last publicly known test 2017, as I alreay mentioned.)
Are there any practical concerns whatsoever?
For me, at a very minimum both those questions must have a yes answer to qualify deletion.
No, IMO it's exactly the other way round. Prove that it still works.
Reducing scope is always satisfying but that's not a good reason to delete platforms.
It is of course very easy to manufacture practical concerns, but maybe that's a fair enough hurdle for arbitrary deletion...
Nothing in this discussion is "arbitrary". Reasons are quite clear, but they seem to be ignored.
//Peter
Michael
Hi, I looked up this board: https://en.wikipedia.org/wiki/Intel_Galileo It's discontinued, but it's open hardware, runs linux, and is compatible with arduino sketches and shields. That's very rare and valuable. It should not be removed. If there is specific maintenance burden around a task, this should be identified so it can be addressed. Karl Semich, project visitor
On Sat, 2022-04-02 at 19:08 -0400, Undiscussed Horrific Abuse, One Victim of Many wrote:
Hi,
I looked up this board: https://en.wikipedia.org/wiki/Intel_Galileo
It's discontinued, but it's open hardware, runs linux, and is compatible with arduino sketches and shields.
That's very rare and valuable. It should not be removed.
Well, while that is true, the SoC is not available anymore.
If there is specific maintenance burden around a task, this should be identified so it can be addressed.
It is identified already and can only be addressed by a volunteer taking over maintership of the SoC. This should be someone who owns the board to be able to test changes.
Karl Semich, project visitor
On Sun, Apr 03, 2022 at 11:25:31AM +0200, Michael Niewöhner wrote:
On Sat, 2022-04-02 at 19:08 -0400, Undiscussed Horrific Abuse, One Victim of Many wrote:
I looked up this board: https://en.wikipedia.org/wiki/Intel_Galileo
It's discontinued, but it's open hardware, runs linux, and is compatible with arduino sketches and shields.
That's very rare and valuable. It should not be removed.
Well, while that is true, the SoC is not available anymore.
If there is specific maintenance burden around a task, this should be identified so it can be addressed.
It is identified already and can only be addressed by a volunteer taking over maintership of the SoC. This should be someone who owns the board to be able to test changes.
I checked eBay. £30 plus postage. Anyone tempted? https://www.ebay.co.uk/itm/284509369404
TLDR: 1) Please don't use the term deprecate - use "moved to a branch" 2) Lets set up some rules about moving platforms/chips to a branch. 3) How do we find out what platforms are actually in use? 4) Please don't take this as an argument.We --- First, we are not going to "Deprecate" anything - we are not warning against its use. I'd ask that everyone please stop using that term because it's just too loaded. I understand that the term has been used in coreboot for a while, but let's try to stop using it. What we do is move maintenance of platforms and chips out of the master branch, onto a version branch, but they can always be maintained on or built from that version branch. They can even be moved back into the master branch if desired and if they are brought up to the current standards. We are not deprecating those platforms - they will live on in coreboot as long as we have a git repo that they can be built from. ---- Next, I firmly believe that we need to set up some rules about how long platforms & chips will stay in the coreboot master branch after being introduced, or after they stop being manufactured/sold. Right now, anyone who works to put code into the tree has no way to know when their code will be moved to a branch. Obviously "It's no longer sold" isn't a good reason, because we continue support lots of chips and mainboards that are no longer sold. I think that the argument of "It hasn't been tested in x years" may be valid, but not everyone who uses a platform runs our tests on it. And just because it's being tested may also not reflect that anyone is actually using a platform. Really we have no idea what platforms and chips are actually being used, so it's difficult to determine what should or shouldn't be moved to a branch. Finally, (and apologies to Felix), I hate the argument of getting rid of things simply to "reduce the maintenance burden". If we want to reduce the work that needs to be done to maintain older chips & platforms, let's implement some APIs between things so that there there's a better separation and changes don't affect everything across all of coreboot. If the platform is in the tree, it needs to be supported to the best extent possible, and should be maintained on master as long as it's actually in use. --- My proposals: Let's create some rules about moving platforms & chips to branches to set expectations: - Maybe decide that after being introduced, chips/platforms will stay in the master branch for a minimum of X years unless there's a significant need to remove it. - Maybe say that every SOC/Platform needs a maintainer, and if the maintainer stops responding or working on that platform or doesn't verify that a platform is working, then it will be moved to a branch after X releases / months. If a platform is perfect and doesn't need to be updated, it doesn't need to be on the master branch, right? Because we have no way of really knowing what platforms or chips are being used. It might be good to come up with a way to get some metrics regarding this: -- It looks like FWUPD keeps statistics about updates, so maybe that could help, at least for anything that's up there. -- Set up a poll or something for both anonymous and verified users to say what platforms they're using. Right now, this is done solely by the test results, which aren't trivial. <Terrible_Ideas> -- We can add a Kconfig option (opt in) to hit a website to increase a counter when a platform is being built. This is probably a terrible metric, but better than we have now. Hash the incoming IP address so that we only increment for one build a week from an individual. Yeah, it could be gamed, but meh, who cares. It just lets us know that the platform is still being built by someone. -- Add a script that again hits a website with information about what's running on a coreboot machine. Some data could be in the clear like platform name & build date. Other data could be hashed just so that we can get a rough idea of how many different machines are using an otherwise identical firmware. </Terrible_Ideas> --- Please don't take any of these thought as me trying to argue with anyone. I absolutely agree that if something isn't being used, it doesn't need to be maintained on the master branch. I just want to make sure that things actually aren't being used before moving them to a branch. Thanks everyone, and take care. Martin
Martin Roth via coreboot wrote:
1) Please don't use the term deprecate - use "moved to a branch"
I don't think the wording matters, my points are discoverability and drive-by maintainance.
If a platform is perfect and doesn't need to be updated, it doesn't need to be on the master branch, right?
I think wrong, because being on master is the only chance to receive tree-wide changes, e.g. through coccinelle spatches or sed:its. Missing those rots the code quicker so yes, something getting moved to a non-master branch is de-facto deprecation by degradation to second class.
I absolutely agree that if something isn't being used, it doesn't need to be maintained on the master branch.
I disagree.
I just want to make sure that things actually aren't being used before moving them to a branch.
I think "no usage" alone should be a very weak motivator to move something from master, just like "no availability". (Many SOCs are currently unavailable and will remain so for some time!) If code is perfect or nearly perfect then why move it? If there are *concrete* issues with code then I think it would be reasonable for *that* to count much more than "no/unknown usage", but the current proposal did not reference any such issues, Paul's ask didn't yield any and neither did mine. //Peter
On Mon, 2022-04-11 at 22:23 +0000, Peter Stuge wrote:
Martin Roth via coreboot wrote:
1) Please don't use the term deprecate - use "moved to a branch"
I don't think the wording matters, my points are discoverability and drive-by maintainance.
If a platform is perfect and doesn't need to be updated, it doesn't need to be on the master branch, right?
I think wrong, because being on master is the only chance to receive tree-wide changes, e.g. through coccinelle spatches or sed:its.
Missing those rots the code quicker so yes, something getting moved to a non-master branch is de-facto deprecation by degradation to second class.
Maintaining without ability to test will make it degrade, too.
I absolutely agree that if something isn't being used, it doesn't need to be maintained on the master branch.
I disagree.
I just want to make sure that things actually aren't being used before moving them to a branch.
I think "no usage" alone should be a very weak motivator to move something from master, just like "no availability".
(Many SOCs are currently unavailable and will remain so for some time!)
It's not unavailable for *some time* but forever, bc it's not being produced anymore.
If code is perfect or nearly perfect then why move it?
If there are *concrete* issues with code then I think it would be reasonable for *that* to count much more than "no/unknown usage", but the current proposal did not reference any such issues, Paul's ask didn't yield any and neither did mine.
Not used => not tested.
//Peter _______________________________________________ coreboot mailing list -- coreboot@coreboot.org To unsubscribe send an email to coreboot-leave@coreboot.org
Apr 12, 2022, 12:14 by foss@mniewoehner.de:
On Mon, 2022-04-11 at 22:23 +0000, Peter Stuge wrote:
Martin Roth via coreboot wrote:
1) Please don't use the term deprecate - use "moved to a branch"
I don't think the wording matters, my points are discoverability and drive-by maintainance.
Yes, wording matters. Opinions are changed in politics by just reframing the argument all the time. If you really don't think that wording matters check out this article, and the book that it's about: https://commonslibrary.org/frame-the-debate-insights-from-dont-think-of-an-e...
Every time coreboot says that some platform is being "deprecated", it starts an argument. I'd really like to avoid that argument.
If a platform is perfect and doesn't need to be updated, it doesn't need to be on the master branch, right?
I think wrong, because being on master is the only chance to receive tree-wide changes, e.g. through coccinelle spatches or sed:its.
Missing those rots the code quicker so yes, something getting moved to a non-master branch is de-facto deprecation by degradation to second class.
How can it degrade if it's not being changed? Older platforms that aren't being tested regularly stop working *because* they're in the main branch, receiving lots of code changes without being tested. By moving them to a branch, they're less likely to get additional breaking fixes. So allowing them to be maintained on a branch is much better for stability.
It's absolutely not second class either. If people understand that the older platforms are maintained on these version branches, they can be worked on there without having all of the changes on newer platforms to deal with. It's a matter of getting people used to working on those older branches.
Maintaining without ability to test will make it degrade, too.
Exactly. By moving it to a branch, if someone wants to work on a platform, they can do it in a more stable environment.
I absolutely agree that if something isn't being used, it doesn't need to be maintained on the master branch.
I disagree.
Ok. Any reason why? I don't understand why would we want to maintain something that nobody uses on the master branch. If it's not being used, it can just as easily not be used on a release branch as the master branch, and then we don't have to continue to try to maintain it as the rest of coreboot moves forward.
I just want to make sure that things actually aren't being used before moving them to a branch.
I think "no usage" alone should be a very weak motivator to move something from master, just like "no availability".
(Many SOCs are currently unavailable and will remain so for some time!)
Why It's not unavailable for *some time* but forever, bc it's not being produced anymore.
If code is perfect or nearly perfect then why move it?
Even if the code was "perfect" when it was written, it doesn't exist in a vacuum. As the rest of the coreboot platform changes around it, the perfect code can stop working.
If there are *concrete* issues with code then I think it would be reasonable for *that* to count much more than "no/unknown usage", but the current proposal did not reference any such issues, Paul's ask didn't yield any and neither did mine.
Not used => not tested.
And how do we know whether or not there are concrete issues with it if it's not being tested? Thanks for the discussion. Martin
Obviously a way to sidestep all this would be to simply test the board in question, which is a small investment of money and time. It's sad that automated testing appears to no longer be ongoing. I might wonder whether coreboot sponsors would support a coreboot-associated automated test lab. The arguments for deprecation in this thread do not appear forthright to me.
Am 12.04.2022 um 23:54 schrieb Karl Semich:
Obviously a way to sidestep all this would be to simply test the board in question, which is a small investment of money and time. I appreciate that you volunteer to do that for Quark. Can't be too bad, it's a small investment of money and time, after all.
Regards, Patrick
On Wed, Apr 13, 2022, 6:26 AM Patrick Georgi <patrick@coreboot.org> wrote:
Am 12.04.2022 um 23:54 schrieb Karl Semich:
Obviously a way to sidestep all this would be to simply test the board in question, which is a small investment of money and time. I appreciate that you volunteer to do that for Quark. Can't be too bad, it's a small investment of money and time, after all.
Sorry, have I offended you? What is it you read me as saying? Does this seem lengthy or expensive to you?
Apr 13, 2022, 06:10 by 0xloem@gmail.com:
On Wed, Apr 13, 2022, 6:26 AM Patrick Georgi <> patrick@coreboot.org> > wrote:
Am 12.04.2022 um 23:54 schrieb Karl Semich:
Obviously a way to sidestep all this would be to simply test the board in question, which is a small investment of money and time. I appreciate that you volunteer to do that for Quark. Can't be too bad, it's a small investment of money and time, after all.
Sorry, have I offended you? What is it you read me as saying?
Does this seem lengthy or expensive to you?
Hi Karl, I don't think Patrick felt offended or even meant to offend. Unfortunately, there's been a lot of "Well, coreboot could just..." without a good explanation of how such a thing gets accomplished with the resources we have available to us. Patrick was a little short, but we'd honestly love to have someone offer to take up a task like testing a board or two, but the suggestion usually seems to be that it should just get added to our (already overflowing) plates. You're right that testing a single board isn't a huge amount of work, but it definitely consumes resources. We need space, power, internet, the device to test, time to set the test device up, a hardware flash tool, a server to communicate with the test device, and a person to fix any issues when something breaks. I think we all agree that it'd be good to have test racks that have all of the boards in the coreboot repository for verification, however that's currently not practical with the resources we have. The whole thing just isn't a simple problem to solve. I'm actually also not completely convinced that just testing the boards is the solution to whether or not we keep a board/chip on the mastre branch. If there really aren't any people using coreboot on their quark boards, then personally, I don't see any need to keep it in the master branch. I know others feel differently, but as I said earlier in this thread, I don't think there's actually any harm in moving an aging or little-used platform to be maintained on a branch. If you have thoughts on how we can overcome any of these issues, I'd love to discuss things with you further. Take care. Martin
Hi Martin,
I think we all agree that it'd be good to have test racks that have all of the boards in the coreboot repository for verification, however that's currently not practical with the resources we have. The whole thing just isn't a simple problem to solve.
Often the biggest impediment to something like this is simply holding it as a shared goal, and continuing to do so when issues arise. If public test labs were desired, a callout for donations of space and hardware could be placed on the main page. If somebody had the capacity to do more than that, then local makerspaces and hackerspaces could be reached out to. I'm actually also not completely convinced that just testing the boards is
the solution to whether or not we keep a board/chip on the mastre branch. If there really aren't any people using coreboot on their quark boards, then personally, I don't see any need to keep it in the master branch. I know others feel differently, but as I said earlier in this thread, I don't think there's actually any harm in moving an aging or little-used platform to be maintained on a branch.
Sounds like there is a difference of opinion in the community. It seems obvious to me that there would be people using coreboot on their quark boards. The world is gigantic. But you have a different opinion, which is fine. It seems to me the reason to include a board is because people care about doing so. I care enough about including boards that I'd test this one if it was needed to do so to retain it. But I'm just a visitor. And it seems more productive to discuss public test labs that could grow to support more boards.
Karl, On Thu, 2022-04-14 at 16:06 -0400, Karl Semich wrote:
Hi Martin,
I think we all agree that it'd be good to have test racks that have all of the boards in the coreboot repository for verification, however that's currently not practical with the resources we have. The whole thing just isn't a simple problem to solve.
Often the biggest impediment to something like this is simply holding it as a shared goal, and continuing to do so when issues arise.
If public test labs were desired, a callout for donations of space and hardware could be placed on the main page. If somebody had the capacity to do more than that, then local makerspaces and hackerspaces could be reached out to.
I'm actually also not completely convinced that just testing the boards is the solution to whether or not we keep a board/chip on the mastre branch. If there really aren't any people using coreboot on their quark boards, then personally, I don't see any need to keep it in the master branch. I know others feel differently, but as I said earlier in this thread, I don't think there's actually any harm in moving an aging or little-used platform to be maintained on a branch.
Sounds like there is a difference of opinion in the community.
It seems obvious to me that there would be people using coreboot on their quark boards. The world is gigantic.
Possible. However, if that is the case, why don't they show their interest in this discussion? Yeah, I know, next arguments will be "but maybe they don't know about the ML", "maybe they don't have time", maybe this, maybe that. Once again, nobody is talking about deleting the platform or make it unusable. Actually, moving it to a branch is the exact opposite to that - preserve a *hopefully* working state, while still taking maintaince work from ***VOLUNTEERS***. It's always the same... people making demands (like test labs, maintenance, etc.) and when you ask them to do the job they refuse... well, ... Don't get me wrong, please. The idea of having test labs is great! However, it costs money, like Martin already noted. Also, testing is not the solution for all problems. Someone needs to maintain the platform.
But you have a different opinion, which is fine.
It seems to me the reason to include a board is because people care about doing so.
I care enough about including boards that I'd test this one if it was needed to do so to retain it. But I'm just a visitor. And it seems more productive to discuss public test labs that could grow to support more boards. _______________________________________________ coreboot mailing list -- coreboot@coreboot.org To unsubscribe send an email to coreboot-leave@coreboot.org
Michael
Michael Niewöhner wrote:
Once again, nobody is talking about deleting the platform or make it unusable.
Moving a board to a branch includes deleting it on master. Deleting on master harms the board in two ways: * Board code loses visibility, which also harms the project as a whole. (Less discoverable outside of the project => less newcomers.) * master diverges over time, so future work on master is less likely to apply to the board code. Whether you intend it or not that de-facto deprecates the board code. Added to that is a less quantifiable organizational/psychological aspect, where a board existing only on a historical release branch is likely understood by most to mean that this board code is indeed historical within coreboot. This is "softer" than the two points above, but I believe still of consequence.
Actually, moving it to a branch is the exact opposite to that - preserve a *hopefully* working state,
That state is preserved on master too, so that's not a good argument. If you want to discuss how we can best document the collective experience and test results for all boards then I think that's great! Martin mentioned board-status and how there's room for improvement in this area. But e.g. a branch per board is not an improvement, for the reasons I give in this thread. We could consider using git tags, but they're also not a very good fit. Do you have more ideas? Maybe something concrete for how board-status could be improved? Maybe a first improvement is to split it into two; one small repo for high-level test results with metadata, another for the log files. Perhaps some compression could improve storage requirements for the latter?
while still taking maintaince work
My ask is that such benefits in fact exist and are explained when proposing to delete a board from master, so *those* can be discussed - as opposed to (like in this case) speculatively proposing to delete a board on master based merely on lack of recent (define recent?) test results and development work. (At some point every board code will become complete, so no more work required.) When there is a clear benefit, such as reducing workload in other code then it's possible to have a concrete discussion and it's also possible for people to offer other ways to create the same benefit. To me, deleting from master without clear benefit is premature. I guess one could argue that master should contain as little code as possible, only whatever someone is actively working on, but that doesn't seem at all useful for those who like to use our project.
from ***VOLUNTEERS***.
I wonder what the split is between paid and spare time coreboot folks. //Peter
Karl wrote…
Obviously a way to sidestep all this would be to simply test the board in question, which is a small investment of money and time. There is still one of these boards (Intel Galileo) available on eBay here in the UK. I can likely commit the time to test coreboot on that board but don’t have the money spare to purchase it due to the ongoing cost of living crisis here.
If someone wants to purchase and donate the board, I can have a look at how coreboot is on it. -Andy.
do you have a way to recover if the flash fails? On Thu, Apr 14, 2022 at 1:09 PM Andy Pont <andy.pont@sdcsystems.com> wrote:
Karl wrote…
Obviously a way to sidestep all this would be to simply test the board in question, which is a small investment of money and time. There is still one of these boards (Intel Galileo) available on eBay here in the UK. I can likely commit the time to test coreboot on that board but don’t have the money spare to purchase it due to the ongoing cost of living crisis here.
If someone wants to purchase and donate the board, I can have a look at how coreboot is on it.
-Andy. _______________________________________________ coreboot mailing list -- coreboot@coreboot.org To unsubscribe send an email to coreboot-leave@coreboot.org
I'm sending an email directly to the board committer since nobody has mentioned the history and is responding to my idea a lot. Lee, do you still have your quark galileo board? Are you at all able to test a new build or package equipment to mail to a volunteer? On Thu, Apr 14, 2022, 4:13 PM ron minnich <rminnich@gmail.com> wrote:
do you have a way to recover if the flash fails?
On Thu, Apr 14, 2022 at 1:09 PM Andy Pont <andy.pont@sdcsystems.com> wrote:
Karl wrote…
Obviously a way to sidestep all this would be to simply test the board in question, which is a small investment of money and time. There is still one of these boards (Intel Galileo) available on eBay here in the UK. I can likely commit the time to test coreboot on that board but don’t have the money spare to purchase it due to the ongoing cost of living crisis here.
If someone wants to purchase and donate the board, I can have a look at how coreboot is on it.
-Andy.
Apr 14, 2022, 14:18 by 0xloem@gmail.com:
I'm sending an email directly to the board committer since nobody has mentioned the history and is responding to my idea a lot. Lee, do you still have your quark galileo board? Are you at all able to test a new build or package equipment to mail to a volunteer?
On Thu, Apr 14, 2022, 4:13 PM ron minnich <> rminnich@gmail.com> > wrote:
do you have a way to recover if the flash fails?
On Thu, Apr 14, 2022 at 1:09 PM Andy Pont <>> andy.pont@sdcsystems.com>> > wrote:
Karl wrote…
Obviously a way to sidestep all this would be to simply test the board in question, which is a small investment of money and time. There is still one of these boards (Intel Galileo) available on eBay here in the UK. I can likely commit the time to test coreboot on that board but don’t have the money spare to purchase it due to the ongoing cost of living crisis here.
If someone wants to purchase and donate the board, I can have a look at how coreboot is on it.
-Andy.
Lee Leahy was my former office neighbor and has escaped the rain of Seattle by retiring to Hawaii a few years back. I’m not sure if he’s still monitoring this list. I can provide some Galileo h/w for folks if there is interest in supporting. Vincent From: Karl Semich <0xloem@gmail.com> Sent: Thursday, April 14, 2022 1:19 PM To: lpleahyjr@gmail.com Cc: Coreboot <coreboot@coreboot.org> Subject: [coreboot] Re: Deprecation of the Intel Quark SoC I'm sending an email directly to the board committer since nobody has mentioned the history and is responding to my idea a lot. Lee, do you still have your quark galileo board? Are you at all able to test a new build or package equipment to mail to a volunteer? On Thu, Apr 14, 2022, 4:13 PM ron minnich <rminnich@gmail.com<mailto:rminnich@gmail.com>> wrote: do you have a way to recover if the flash fails? On Thu, Apr 14, 2022 at 1:09 PM Andy Pont <andy.pont@sdcsystems.com<mailto:andy.pont@sdcsystems.com>> wrote:
Karl wrote…
Obviously a way to sidestep all this would be to simply test the board in question, which is a small investment of money and time. There is still one of these boards (Intel Galileo) available on eBay here in the UK. I can likely commit the time to test coreboot on that board but don’t have the money spare to purchase it due to the ongoing cost of living crisis here.
If someone wants to purchase and donate the board, I can have a look at how coreboot is on it.
-Andy.
Vincent wrote...
I can provide some Galileo h/w for folks if there is interest in supporting.
Looking at the configs it looks like both a Gen 1 and Gen 2 Galileo boards are the place to start? If you have both and can get them shipped to the UK that would be great. I suspect I have power supplies and debug cables for them. -Andy
Sure. Send me a mailing address. Unites should have Europe-friendly wall-wart/power supplies and cables, etc. in the box. Vincent From: Andy Pont <andy.pont@sdcsystems.com> Sent: Friday, April 15, 2022 11:13 AM To: Zimmer, Vincent <vincent.zimmer@intel.com>; Karl Semich <0xloem@gmail.com>; lpleahyjr@gmail.com Cc: Coreboot <coreboot@coreboot.org> Subject: Re: [coreboot] Re: Deprecation of the Intel Quark SoC Vincent wrote...
I can provide some Galileo h/w for folks if there is interest in supporting.
Looking at the configs it looks like both a Gen 1 and Gen 2 Galileo boards are the place to start? If you have both and can get them shipped to the UK that would be great. I suspect I have power supplies and debug cables for them. -Andy
I think quark revival should come with a reasonable deadline. IOW, if people are serious about keeping this platform, I think we ought to see commitments as to when they report that it works. I'd suggest July 1. We've had a lot of commitments before, but everyone is busy, and hopes can outrun reality. It should not take more than a few hours to verify that this board or does not work. Keeping an old platform is not zero cost. It comes with costs for running CI, keeping it up to date as other parts of coreboot evolve, and dealing with build failures that can occur as it falls out of date. Those costs are all externalized, for most of us, to Patrick and Martin, but they do exist. In round numbers, coreboot is at about 5k commits/year (last time I looked; maybe it's higher or lower now). Assuming each CL takes around ten builds, that's 50,000 builds, times 350 boards, which translates to "a lot." It keeps Martin's house warm, I suspect. That's not counting the continuous builds that go on for Chromebooks at Google, Intel, and many other places. These builds all include Quark. To put it another way, Quark has a CO2 footprint. There ought to be usage to justify this cost. I'm told that 1% or so of our mainboards are dependent on quark. As far as I know, there are 0 quark boards out there using coreboot. We seem to be putting an awful lot of effort into a board with no users -- a board and chip that, furthermore, has been dead for several years, and was never that great to begin with. On Fri, Apr 15, 2022 at 11:29 AM Zimmer, Vincent <vincent.zimmer@intel.com> wrote:
Sure. Send me a mailing address. Unites should have Europe-friendly wall-wart/power supplies and cables, etc. in the box.
Vincent
From: Andy Pont <andy.pont@sdcsystems.com> Sent: Friday, April 15, 2022 11:13 AM To: Zimmer, Vincent <vincent.zimmer@intel.com>; Karl Semich <0xloem@gmail.com>; lpleahyjr@gmail.com Cc: Coreboot <coreboot@coreboot.org> Subject: Re: [coreboot] Re: Deprecation of the Intel Quark SoC
Vincent wrote...
I can provide some Galileo h/w for folks if there is interest in supporting.
Looking at the configs it looks like both a Gen 1 and Gen 2 Galileo boards are the place to start?
If you have both and can get them shipped to the UK that would be great. I suspect I have power supplies and debug cables for them.
-Andy
_______________________________________________ coreboot mailing list -- coreboot@coreboot.org To unsubscribe send an email to coreboot-leave@coreboot.org
In round numbers, coreboot is at about 5k commits/year (last time I looked; maybe it's higher or lower now). Assuming each CL takes around ten builds, that's 50,000 builds, times 350 boards, which translates to "a lot." It keeps Martin's house warm, I suspect. That's not counting the continuous builds that go on for Chromebooks at Google, Intel, and many other places. These builds all include Quark.
This specific information on what kind of tasks retaining quark can burden is productive. If people preferred to retain quark, it could be important to address things impacted by that choice. Other approaches to this burden could include reducing the frequency of inclusion of boards within CI if their subtrees were not touched by intermediate commits.
Hello Ron, I agree with most what you are saying in general. However, I find it very concerning that you make it about Quark. Are you sure you are not just jumping on the bandwagon because people started to pick on Quark? There are probably many boards in the tree that are even more abandoned and their platform code was in worth shape from the beginning. Let's not make arbitrary choices what to move and what not. On 15.04.22 22:38, ron minnich wrote:
I think quark revival should come with a reasonable deadline. IOW, if people are serious about keeping this platform, I think we ought to see commitments as to when they report that it works. I'd suggest July 1.
We already have rules when to announce and when to actually move things to abandoned branches. Let's not make arbitrary exceptions.
We've had a lot of commitments before, but everyone is busy, and hopes can outrun reality. It should not take more than a few hours to verify that this board or does not work.
The same seems true about many other boards in the tree. Why don't you demand the same for them?
Keeping an old platform is not zero cost. It comes with costs for running CI, keeping it up to date as other parts of coreboot evolve, and dealing with build failures that can occur as it falls out of date. Those costs are all externalized, for most of us, to Patrick and Martin, but they do exist.
In round numbers, coreboot is at about 5k commits/year (last time I looked; maybe it's higher or lower now). Assuming each CL takes around ten builds, that's 50,000 builds, times 350 boards, which translates to "a lot." It keeps Martin's house warm, I suspect. That's not counting the continuous builds that go on for Chromebooks at Google, Intel, and many other places. These builds all include Quark. To put it another way, Quark has a CO2 footprint. There ought to be usage to justify this cost.
Speaking of builds in other places and CO2 footprint, wouldn't it reduce the coreboot CI's CO2 footprint by roughly 33% if we would stop build testing Chromebooks twice (with and without the CHROMEOS option enabled)? I'm not saying we should do it. But there are much lower hanging fruits than Quark. So I don't understand why this is brought up for the latter.
I'm told that 1% or so of our mainboards are dependent on quark. As far as I know, there are 0 quark boards out there using coreboot. We
WDYM? why would you know who is using coreboot on their Galileo board and who isn't?
seem to be putting an awful lot of effort into a board with no users -- a board and chip that, furthermore, has been dead for several years, and was never that great to begin with.
Can you please elaborate on that "awful lot of effort"? Nico
On Fri, Apr 15, 2022 at 06:28:37PM +0000, Zimmer, Vincent wrote:
Andy Pont wrote:
Vincent wrote:
I can provide some Galileo h/w for folks if there is interest in supporting.
[..] If you have both and can get them shipped to the UK that would be great. I suspect I have power supplies and debug cables for them.
Sure. Send me a mailing address. Unites should have Europe-friendly wall-wart/power supplies and cables, etc. in the box.
Note for Vincent: the UK has different mains electricity sockets than most other European countries: - UK uses BS 1363 (aka IEC 60083 Type G): https://en.wikipedia.org/wiki/AC_power_plugs_and_sockets:_British_and_relate... - Much of the rest of Europe uses CEE 7 sockets, but these are not used in the UK: https://en.wikipedia.org/wiki/CEE_7_standard_AC_plugs_and_sockets Mains electrical items shipped to the UK must typically have a BS 1363 plug or risk being delayed/impounded at customs. (I think this stems from The Plugs and Sockets etc. (Safety) Regulations 1994: https://www.legislation.gov.uk/uksi/1994/1768/made .) So, best to check the mains plugs are UK legal before shipping. If they aren't, it may be wise to ship the boards without plugs/PSUs and let Andy source those locally. Sam
Hi all, Adding some thoughts from my side: Firstly, I didn’t expect this topic will be going on for so long, which shows that people really care about the hard work had been put together all these years to support a soc and we need to be sensitive to that. This kind of openness actually keep the coreboot alive and reminds me how much I love about this community :) However, I do share the same frustration with others, talk is cheap, and seems that there is even more cost involved to keep this long discontinued soc. I really appreciate Ron to put the facts and costs out plain and simple, so that everyone here could make their own responsible decision. Let’s go back to this basic question: Do we really need to spend more resources and effort to continue support a soc that has been EoL for 5 years by Intel, unsupported, and impossible to get it cost effectively worldwide (while there are much greater options available)? Personally I think moving Galileo soc to stable branch is a win-win situation for all of us. For the enthusiast who still want to use it are freely to do so without the baggage, and for others it’s a great savings on resources spent, so that we could leave more rooms (and also testing resources)to the more upcoming coreboot products and architecture (I think much more will come, the public has just only warmed up to coreboot ;) ). For the concern about the visibility, it shouldn’t be a problem if we properly document it, and I can help with that. Peace ✌️
On 16. Apr 2022, at 10:05, Sam Kuper <sam.kuper@uclmail.net> wrote:
On Fri, Apr 15, 2022 at 06:28:37PM +0000, Zimmer, Vincent wrote:
Andy Pont wrote:
Vincent wrote:
I can provide some Galileo h/w for folks if there is interest in supporting.
[..] If you have both and can get them shipped to the UK that would be great. I suspect I have power supplies and debug cables for them.
Sure. Send me a mailing address. Unites should have Europe-friendly wall-wart/power supplies and cables, etc. in the box.
Note for Vincent: the UK has different mains electricity sockets than most other European countries:
- UK uses BS 1363 (aka IEC 60083 Type G): https://en.wikipedia.org/wiki/AC_power_plugs_and_sockets:_British_and_relate...
- Much of the rest of Europe uses CEE 7 sockets, but these are not used in the UK: https://en.wikipedia.org/wiki/CEE_7_standard_AC_plugs_and_sockets
Mains electrical items shipped to the UK must typically have a BS 1363 plug or risk being delayed/impounded at customs.
(I think this stems from The Plugs and Sockets etc. (Safety) Regulations 1994: https://www.legislation.gov.uk/uksi/1994/1768/made .)
So, best to check the mains plugs are UK legal before shipping. If they aren't, it may be wise to ship the boards without plugs/PSUs and let Andy source those locally.
Sam _______________________________________________ coreboot mailing list -- coreboot@coreboot.org To unsubscribe send an email to coreboot-leave@coreboot.org
Hi Sheng, On 16.04.22 11:01, Sheng Lean Tan wrote:
Personally I think moving Galileo soc to stable branch is a win-win situation for all of us.
it looks like nobody is maintaining such a stable branch yet. Would you volunteer to maintain one for Quark? AIUI, some people already want to take care of testing. So you'd only have to maintain compatibility with newer toolchain and payload versions and such.
For the enthusiast who still want to use it are freely to do so without the baggage, and for others it’s a great savings on resources spent, so that we could leave more rooms (and also testing resources)to the more upcoming coreboot products and architecture (I think much more will come, the public has just only warmed up to coreboot ;) ).
FWIW, most resources for newer platforms are wasted by copying code (kind of forking the original code in the same repository). So there is much more potential to save resources by adding proper abstraction instead. And what would be better to get the abstractions right than a diverse set of platforms in the tree? I'm not saying, you need Quark for that, but so far I also don't see how it could hurt. Nico
nico, it was not so much a matter of me jumping on the bandwagon, as my reluctance to get involved in another never-ending discussion over retiring a platform that nobody uses or cares about. But let's keep it simple. I think it's clear that the effort to maintain the Quark is > 0. The number of users is zero. The effort per user, depending on what you get when you divide a number by zero, is "high" :-) But there's a bigger issue here. If I have a board, which ran coreboot at some time, which version of coreboot do I use? In many cases, the working version of coreboot will not be master. That is true for chromebooks in many cases, which is why Google maintains a fork for each chromebook, once it is known to work. If you've been doing this for long enough, you've experienced building a mainboard at tip of tree and having it not work; then finding an older commit for which the board does work. This discussion has led me to believe that we should change how we name branches. People get upset that boards are not in master. Should we get rid of the entire idea of a master branch which works for all boards, since that is not quite true anyway? Or is the problem that people don't want to see a name lost to memory (I understand that)? Can we maintain a record of boards, along with the last working commit? In other words, builds != boots. But we continue to act as though boards that build will also boot. This is known not to be true. The issue is not whether my board is in master. The issue is, what's the last known commit in coreboot for which a board was tested and known to work? So we would no longer deprecate boards, or drop them, or do whatever gets people upset. We would have a way to know, for any given board, which commit to check out to build it. The list of boards would grow over time, and it would be easy to checkout a board and build it. Boards would not be lost to memory. We could acknowledge this reality by naming master to tip, or some similar name, which is less likely to get people upset. This was my original goal for the mainboards status page, but we never got there. Maybe it's time to bring that to life. On Sat, Apr 16, 2022 at 7:33 AM Nico Huber <nico.h@gmx.de> wrote:
Hi Sheng,
On 16.04.22 11:01, Sheng Lean Tan wrote:
Personally I think moving Galileo soc to stable branch is a win-win situation for all of us.
it looks like nobody is maintaining such a stable branch yet. Would you volunteer to maintain one for Quark? AIUI, some people already want to take care of testing. So you'd only have to maintain compatibility with newer toolchain and payload versions and such.
For the enthusiast who still want to use it are freely to do so without the baggage, and for others it’s a great savings on resources spent, so that we could leave more rooms (and also testing resources)to the more upcoming coreboot products and architecture (I think much more will come, the public has just only warmed up to coreboot ;) ).
FWIW, most resources for newer platforms are wasted by copying code (kind of forking the original code in the same repository). So there is much more potential to save resources by adding proper abstraction instead. And what would be better to get the abstractions right than a diverse set of platforms in the tree? I'm not saying, you need Quark for that, but so far I also don't see how it could hurt.
Nico _______________________________________________ coreboot mailing list -- coreboot@coreboot.org To unsubscribe send an email to coreboot-leave@coreboot.org
btw, if you are interested in looking at new abstractions intended to resolve some of the issues we are discussing here, that's what oreboot is all about. We did just drop the fsp platforms, because we decided there is no interest in binary blobs for oreboot, but other than that ... if you like the idea of full source, Rust, an effort to work out new abstractions, and to remove some legacy coreboot ideas that did not work out ... we're there every friday, with lots of RISCV focus nowadays. I am taking this discussion to heart, and I think in oreboot we're going to try to find a way to record mainboards we've dropped, with their commit, so memory is not lost. Maybe with tags, maybe with plain text file, not sure. It's possible whatever we try out will work for coreboot, but we'll see. On Sat, Apr 16, 2022 at 8:25 AM ron minnich <rminnich@gmail.com> wrote:
nico, it was not so much a matter of me jumping on the bandwagon, as my reluctance to get involved in another never-ending discussion over retiring a platform that nobody uses or cares about.
But let's keep it simple. I think it's clear that the effort to maintain the Quark is > 0. The number of users is zero. The effort per user, depending on what you get when you divide a number by zero, is "high" :-)
But there's a bigger issue here. If I have a board, which ran coreboot at some time, which version of coreboot do I use? In many cases, the working version of coreboot will not be master. That is true for chromebooks in many cases, which is why Google maintains a fork for each chromebook, once it is known to work. If you've been doing this for long enough, you've experienced building a mainboard at tip of tree and having it not work; then finding an older commit for which the board does work.
This discussion has led me to believe that we should change how we name branches. People get upset that boards are not in master. Should we get rid of the entire idea of a master branch which works for all boards, since that is not quite true anyway? Or is the problem that people don't want to see a name lost to memory (I understand that)? Can we maintain a record of boards, along with the last working commit?
In other words, builds != boots. But we continue to act as though boards that build will also boot. This is known not to be true.
The issue is not whether my board is in master. The issue is, what's the last known commit in coreboot for which a board was tested and known to work?
So we would no longer deprecate boards, or drop them, or do whatever gets people upset. We would have a way to know, for any given board, which commit to check out to build it. The list of boards would grow over time, and it would be easy to checkout a board and build it. Boards would not be lost to memory.
We could acknowledge this reality by naming master to tip, or some similar name, which is less likely to get people upset.
This was my original goal for the mainboards status page, but we never got there. Maybe it's time to bring that to life.
On Sat, Apr 16, 2022 at 7:33 AM Nico Huber <nico.h@gmx.de> wrote:
Hi Sheng,
On 16.04.22 11:01, Sheng Lean Tan wrote:
Personally I think moving Galileo soc to stable branch is a win-win situation for all of us.
it looks like nobody is maintaining such a stable branch yet. Would you volunteer to maintain one for Quark? AIUI, some people already want to take care of testing. So you'd only have to maintain compatibility with newer toolchain and payload versions and such.
For the enthusiast who still want to use it are freely to do so without the baggage, and for others it’s a great savings on resources spent, so that we could leave more rooms (and also testing resources)to the more upcoming coreboot products and architecture (I think much more will come, the public has just only warmed up to coreboot ;) ).
FWIW, most resources for newer platforms are wasted by copying code (kind of forking the original code in the same repository). So there is much more potential to save resources by adding proper abstraction instead. And what would be better to get the abstractions right than a diverse set of platforms in the tree? I'm not saying, you need Quark for that, but so far I also don't see how it could hurt.
Nico _______________________________________________ coreboot mailing list -- coreboot@coreboot.org To unsubscribe send an email to coreboot-leave@coreboot.org
On Sat, 2022-04-16 at 08:25 -0700, ron minnich wrote:
nico, it was not so much a matter of me jumping on the bandwagon, as my reluctance to get involved in another never-ending discussion over retiring a platform that nobody uses or cares about.
But let's keep it simple. I think it's clear that the effort to maintain the Quark is > 0. The number of users is zero. The effort per user, depending on what you get when you divide a number by zero, is "high" :-)
But there's a bigger issue here. If I have a board, which ran coreboot at some time, which version of coreboot do I use? In many cases, the working version of coreboot will not be master. That is true for chromebooks in many cases, which is why Google maintains a fork for each chromebook, once it is known to work. If you've been doing this for long enough, you've experienced building a mainboard at tip of tree and having it not work; then finding an older commit for which the board does work.
This discussion has led me to believe that we should change how we name branches. People get upset that boards are not in master. Should we get rid of the entire idea of a master branch which works for all boards, since that is not quite true anyway? Or is the problem that people don't want to see a name lost to memory (I understand that)? Can we maintain a record of boards, along with the last working commit?
In other words, builds != boots. But we continue to act as though boards that build will also boot. This is known not to be true.
The issue is not whether my board is in master. The issue is, what's the last known commit in coreboot for which a board was tested and known to work?
So we would no longer deprecate boards, or drop them, or do whatever gets people upset. We would have a way to know, for any given board, which commit to check out to build it. The list of boards would grow over time, and it would be easy to checkout a board and build it. Boards would not be lost to memory.
huh, not sure I understand that. No longer drepecating boards = keep them in master forever? ... or do you mean "drop from that list"?
We could acknowledge this reality by naming master to tip, or some similar name, which is less likely to get people upset.
I don't think renaming the branch helps. The reason people get upset seems to be that something that *might possibly work (or not)* get's *lost* (when did git lose anything? \o/) and because their illusion of "maintenance" is disturbed. (You actually named it: builds != boots) Oh well, and of course these boards/platforms won't benefit from new "features" when not in master, as mentioned by Peter. It doesn't seem to matter at all if these "features" even work or not...
This was my original goal for the mainboards status page, but we never got there. Maybe it's time to bring that to life.
On Sat, Apr 16, 2022 at 7:33 AM Nico Huber <nico.h@gmx.de> wrote:
Hi Sheng,
On 16.04.22 11:01, Sheng Lean Tan wrote:
Personally I think moving Galileo soc to stable branch is a win-win situation for all of us.
it looks like nobody is maintaining such a stable branch yet. Would you volunteer to maintain one for Quark? AIUI, some people already want to take care of testing. So you'd only have to maintain compatibility with newer toolchain and payload versions and such.
For the enthusiast who still want to use it are freely to do so without the baggage, and for others it’s a great savings on resources spent, so that we could leave more rooms (and also testing resources)to the more upcoming coreboot products and architecture (I think much more will come, the public has just only warmed up to coreboot ;) ).
FWIW, most resources for newer platforms are wasted by copying code (kind of forking the original code in the same repository). So there is much more potential to save resources by adding proper abstraction instead. And what would be better to get the abstractions right than a diverse set of platforms in the tree? I'm not saying, you need Quark for that, but so far I also don't see how it could hurt.
Nico _______________________________________________ coreboot mailing list -- coreboot@coreboot.org To unsubscribe send an email to coreboot-leave@coreboot.org
_______________________________________________ coreboot mailing list -- coreboot@coreboot.org To unsubscribe send an email to coreboot-leave@coreboot.org
Apr 16, 2022, 08:32 by nico.h@gmx.de:
Hi Sheng,
On 16.04.22 11:01, Sheng Lean Tan wrote:
Personally I think moving Galileo soc to stable branch is a win-win situation for all of us.
it looks like nobody is maintaining such a stable branch yet. Would you volunteer to maintain one for Quark? AIUI, some people already want to take care of testing. So you'd only have to maintain compatibility with newer toolchain and payload versions and such.
The stable branches that Sheng refers to are the release branches. We've had a number of updates on the 4.11 branch. We've now got "stable" release branches for the 4.11, 4.12, 4.14, 4.15 & 4.16 releases. There is a jenkins branch build that should build patches to any of the branches. I think everything's taken care of for these release branches, although we need to update the release checklist to make a new release of any patches pushed to these branches since the last release cycle. I'll handle that on the next release. Martin
Ron wrote...
do you have a way to recover if the flash fails?
Current programming hardware includes... Dataman 40-Pro Dediprog EM100 Dediprog SF100 Totalphase Aardvark Several CH341A devices Failing that, I have a soldering iron and hot air rework station! Hopefully one of them will work! -Andy.
Martin Roth via coreboot wrote:
On Mon, 2022-04-11 at 22:23 +0000, Peter Stuge wrote:
Martin Roth via coreboot wrote:
1) Please don't use the term deprecate - use "moved to a branch"
I don't think the wording matters, my points are discoverability and drive-by maintainance.
Yes, wording matters.
I disagree, since a new name doesn't affect the points I make. Trying to reframe even risks detracting from the actual argument. It has a taste of whataboutism.
If you really don't think that wording matters check out this article, and the book that it's about: https://commonslibrary.org/frame-the-debate-insights-from-dont-think-of-an-e...
Thanks for the link. A quote: "Framing is the art of communicating such that one’s language activates particular unspoken ideas and associations." That could certainly help in political contexts where it may be undesirable to communicate matter of fact, to not reveal true intentions. But I don't think that's something to strive for in open source projects, where my goal is transparency and determinism.
Every time coreboot says that some platform is being "deprecated", it starts an argument.
That's not because of the wording, but because of the foreseeable consequences of the action known as "deprecate" or "move to branch".
I'd really like to avoid that argument.
Let's see what we can achieve.
If a platform is perfect and doesn't need to be updated, it doesn't need to be on the master branch, right?
I think wrong, because being on master is the only chance to receive tree-wide changes, e.g. through coccinelle spatches or sed:its.
Missing those rots the code quicker so yes, something getting moved to a non-master branch is de-facto deprecation by degradation to second class.
How can it degrade if it's not being changed?
Code not in master eventually requires duplicated engineering to reuse desirable bug fixes in master. That's a degradation, since duplicating effort is less efficient.
Older platforms that aren't being tested regularly stop working *because* they're in the main branch, receiving lots of code changes without being tested.
That's an interesting argument. Whether it holds true depends on the particular changes. I understand now that both you and Michael are very test-focused, which explains why you feel that untested code is per definition second class. I view that differently.
By moving them to a branch, they're less likely to get additional breaking fixes. So allowing them to be maintained on a branch is much better for stability.
IBVs have tried that model, it eventually results in one branch per board, essentially a completely silo:ed situation, with reuse across branches approaching zero over time. Do we agree that such a situation is undesirable in coreboot and really any open source project? In companies that generate revenue each time the same change is implemented in another branch the silo model is profitable, but we don't have that driver in coreboot - here I view it as wasteful duplication of already-scarce labour at best and malicious at worst.
It's absolutely not second class either. If people understand that the older platforms are maintained on these version branches, they can be worked on there without having all of the changes on newer platforms to deal with. It's a matter of getting people used to working on those older branches.
I completely disagree with this paragraph. Branches are second class because as they diverge over time (which is their purpose) reusability approaches zero, value for consumers follows that directly and so does the likelihood of future investment into the branch. Deprecation of the code in the branch becomes a self-fulfilling prophecy. Because this is very predictable there's pushback each time something is being proposed for deprecation AKA move to another branch. Every time it reduces the value of engineering that has gone into coreboot in the past. I think everyone understands that there's a tradeoff where such reduction in value can be offset by a significant increase in value which can't happen until the code is moved. I ask that such increase in value must be demonstrated before code can be moved off master. If there's no clear benefit then I disagree with moving something off master, especially based merely on a lack of test datapoints or because current project contributors can no longer buy the hardware. Taking action because there *isn't* any data seems the very opposite of a scientific approach - not something I think we want to do, right?
Maintaining without ability to test will make it degrade, too.
Exactly. By moving it to a branch, if someone wants to work on a platform, they can do it in a more stable environment.
To me, that's a fallacy and a trap. With git, a "stable environment" can be created at any time and point. Anyone can create a branch as they require, when they want. But once code is moved off master reuse of changes on master will eventually become impossible and there's no good path to recover from that situation, so it should be important to avoid such dead ends for any code we want to stay usable - IMO all code. (Again: If there are actual source code issues with platforms then that weighs a lot heavier for me than mere lack of testing.)
I absolutely agree that if something isn't being used, it doesn't need to be maintained on the master branch.
I disagree.
Ok. Any reason why? I don't understand why would we want to maintain something that nobody uses on the master branch.
Ah! I want as much code as possible to be usable as far into the future as possible. Being used today or yesteryear doesn't matter to me, guarding discoverability and the opportunity to use it later while benefiting from work done for completely different targets matters much more to me. This my philosophy is clearly different from that of someone focused strictly on the next product coming to market, for them the only thing that will matter is right now. But I don't invest effort into open source merely for right now, I think that's a waste of time since product lifecycles are so short. I can understand that someone focused on right now is keen to "declutter" and move anything that doesn't seem immediately relevant. That's fine in a private repository for a private project, but I have a fundamentally different mindset within open source.
If code is perfect or nearly perfect then why move it?
Even if the code was "perfect" when it was written, it doesn't exist in a vacuum. As the rest of the coreboot platform changes around it, the perfect code can stop working.
It can, but without evidence that's just as hypothetical as the code continuing to work fine. Mere absence of data isn't a reason to make any change.
If there are *concrete* issues with code then I think it would be reasonable for *that* to count much more than "no/unknown usage", but the current proposal did not reference any such issues, Paul's ask didn't yield any and neither did mine.
Not used => not tested.
And how do we know whether or not there are concrete issues with it if it's not being tested?
Ah! No not run time issues, but source code issues causing problems with other code in the tree. These are, as I wrote, trivial to manufacture if desired, but maybe that's a fair threshold. Kind regards //Peter
On Wed, 2022-04-13 at 01:03 +0000, Peter Stuge wrote:
Martin Roth via coreboot wrote:
On Mon, 2022-04-11 at 22:23 +0000, Peter Stuge wrote:
Martin Roth via coreboot wrote:
1) Please don't use the term deprecate - use "moved to a branch"
I don't think the wording matters, my points are discoverability and drive-by maintainance.
Yes, wording matters.
I disagree, since a new name doesn't affect the points I make.
Trying to reframe even risks detracting from the actual argument. It has a taste of whataboutism.
If you really don't think that wording matters check out this article, and the book that it's about: https://commonslibrary.org/frame-the-debate-insights-from-dont-think-of-an-e...
Thanks for the link. A quote: "Framing is the art of communicating such that one’s language activates particular unspoken ideas and associations."
That could certainly help in political contexts where it may be undesirable to communicate matter of fact, to not reveal true intentions.
But I don't think that's something to strive for in open source projects, where my goal is transparency and determinism.
Every time coreboot says that some platform is being "deprecated", it starts an argument.
That's not because of the wording, but because of the foreseeable consequences of the action known as "deprecate" or "move to branch".
I'd really like to avoid that argument.
Let's see what we can achieve.
If a platform is perfect and doesn't need to be updated, it doesn't need to be on the master branch, right?
I think wrong, because being on master is the only chance to receive tree-wide changes, e.g. through coccinelle spatches or sed:its.
Missing those rots the code quicker so yes, something getting moved to a non-master branch is de-facto deprecation by degradation to second class.
How can it degrade if it's not being changed?
Code not in master eventually requires duplicated engineering to reuse desirable bug fixes in master.
That's a degradation, since duplicating effort is less efficient.
Older platforms that aren't being tested regularly stop working *because* they're in the main branch, receiving lots of code changes without being tested.
That's an interesting argument. Whether it holds true depends on the particular changes. I understand now that both you and Michael are very test-focused, which explains why you feel that untested code is per definition second class. I view that differently.
By moving them to a branch, they're less likely to get additional breaking fixes. So allowing them to be maintained on a branch is much better for stability.
IBVs have tried that model, it eventually results in one branch per board, essentially a completely silo:ed situation, with reuse across branches approaching zero over time.
Do we agree that such a situation is undesirable in coreboot and really any open source project?
IBVs also try to keep everything that "might be needed in the future" and most of that code is just broken. Also see Intel reference code etc. It's a mess af.
In companies that generate revenue each time the same change is implemented in another branch the silo model is profitable, but we don't have that driver in coreboot - here I view it as wasteful duplication of already-scarce labour at best and malicious at worst.
It's absolutely not second class either. If people understand that the older platforms are maintained on these version branches, they can be worked on there without having all of the changes on newer platforms to deal with. It's a matter of getting people used to working on those older branches.
I completely disagree with this paragraph.
Branches are second class because as they diverge over time (which is their purpose) reusability approaches zero, value for consumers follows that directly and so does the likelihood of future investment into the branch.
Deprecation of the code in the branch becomes a self-fulfilling prophecy.
Because this is very predictable there's pushback each time something is being proposed for deprecation AKA move to another branch.
Every time it reduces the value of engineering that has gone into coreboot in the past.
I think everyone understands that there's a tradeoff where such reduction in value can be offset by a significant increase in value which can't happen until the code is moved.
I ask that such increase in value must be demonstrated before code can be moved off master.
If there's no clear benefit then I disagree with moving something off master, especially based merely on a lack of test datapoints or because current project contributors can no longer buy the hardware.
Taking action because there *isn't* any data seems the very opposite of a scientific approach - not something I think we want to do, right?
And this is the difference between science and development...
Maintaining without ability to test will make it degrade, too.
Exactly. By moving it to a branch, if someone wants to work on a platform, they can do it in a more stable environment.
To me, that's a fallacy and a trap.
With git, a "stable environment" can be created at any time and point. Anyone can create a branch as they require, when they want.
But once code is moved off master reuse of changes on master will eventually become impossible and there's no good path to recover from that situation, so it should be important to avoid such dead ends for any code we want to stay usable - IMO all code.
(Again: If there are actual source code issues with platforms then that weighs a lot heavier for me than mere lack of testing.)
How would you "reuse [] changes on master" on a platform, where these changes can't be tested? o.O
I absolutely agree that if something isn't being used, it doesn't need to be maintained on the master branch.
I disagree.
Ok. Any reason why? I don't understand why would we want to maintain something that nobody uses on the master branch.
Ah! I want as much code as possible to be usable as far into the future as possible. Being used today or yesteryear doesn't matter to me, guarding discoverability and the opportunity to use it later while benefiting from work done for completely different targets matters much more to me.
This my philosophy is clearly different from that of someone focused strictly on the next product coming to market, for them the only thing that will matter is right now.
But I don't invest effort into open source merely for right now, I think that's a waste of time since product lifecycles are so short.
I can understand that someone focused on right now is keen to "declutter" and move anything that doesn't seem immediately relevant.
That's fine in a private repository for a private project, but I have a fundamentally different mindset within open source.
If code is perfect or nearly perfect then why move it?
Even if the code was "perfect" when it was written, it doesn't exist in a vacuum. As the rest of the coreboot platform changes around it, the perfect code can stop working.
It can, but without evidence that's just as hypothetical as the code continuing to work fine. Mere absence of data isn't a reason to make any change.
If there are *concrete* issues with code then I think it would be reasonable for *that* to count much more than "no/unknown usage", but the current proposal did not reference any such issues, Paul's ask didn't yield any and neither did mine.
Not used => not tested.
And how do we know whether or not there are concrete issues with it if it's not being tested?
Ah! No not run time issues, but source code issues causing problems with other code in the tree. These are, as I wrote, trivial to manufacture if desired, but maybe that's a fair threshold.
No, it is both about runtime issues and code issues like "can't merge a change that affects multiple platforms because one platform can't be tested". You won't get in an untested change.
Kind regards
//Peter _______________________________________________ coreboot mailing list -- coreboot@coreboot.org To unsubscribe send an email to coreboot-leave@coreboot.org
Michael
Michael Niewöhner wrote:
But once code is moved off master reuse of changes on master will eventually become impossible and there's no good path to recover from that situation, so it should be important to avoid such dead ends for any code we want to stay usable - IMO all code.
How would you "reuse [] changes on master" on a platform, where these changes can't be tested? o.O
By reuse I don't mean that code runs, I mean that a commit benefits also platforms without test coverage. There are many ways to determine whether a commit benefits a platform or not, testing is just one way and testing alone is a weak indicator. That's perhaps foreign to someone with a "test-driven" mindset. I don't hate on testing at all, I just want to preserve value also where there's no coverage when that's possible without much detriment to other parts of the code. I don't think it's reasonable nor is it current practice to require every commit to be tested on every affected platform. That would obviously be nice data points to have but that has not been coreboot reality in the past 20 years and I predict that it will also not be so in the next 20 years. I think that's fine. I hope you can understand that my ask is simply to not erase what might be working well based only on a lack of information. I'm obviously grateful that the leadership meeting settled on keeping quark at least as long as it causes no problems. Thanks for that! Kind regards //Peter
The documentation for this board was removed in 184d5d04296 .
Hi When platforms stand in the way of improving the general code base, I think that's it's not controversial to ask people to either step up and do necessary maintenance or move the platform to a branch. Past examples of that would things like dropping romcc bootblock, car global, ... When a platform is pretty much dead, mainly because it's old or unused, but not standing in the way of general improvements, I don't think there is much to gain from moving it to a branch. For instance with the i440bx platform which is over 20y old (I do hope no one has to really use those!), we had someone maintain it a few years back. I think it was done for the fun of it and I think there is value to that. So maybe someone will have fun with quark in a few years, fix some problems and make it work again, with the upshot of having a new community member? Old platforms should not drag down development on the master branch. If you need to make a change to soc/quark and no one is there to test it, then so be it... That does mean that we can't guarantee that things work in the master branch, which as I see it is already the case to a large extent on a lot of platforms. Not breaking platforms in the master branch is an orthogonal problem that can only be solved with automated hardware testing. It is a *hard* and therefore expensive problem to solve... Now what should we do when something old is suddenly tested to be broken in the master branch? That's a different problem where moving things out of the master branch might make more sense. Kind regards On Wed, Apr 13, 2022 at 2:42 PM Peter Stuge <peter@stuge.se> wrote:
Michael Niewöhner wrote:
But once code is moved off master reuse of changes on master will eventually become impossible and there's no good path to recover from that situation, so it should be important to avoid such dead ends for any code we want to stay usable - IMO all code.
How would you "reuse [] changes on master" on a platform, where these changes can't be tested? o.O
By reuse I don't mean that code runs, I mean that a commit benefits also platforms without test coverage.
There are many ways to determine whether a commit benefits a platform or not, testing is just one way and testing alone is a weak indicator.
That's perhaps foreign to someone with a "test-driven" mindset. I don't hate on testing at all, I just want to preserve value also where there's no coverage when that's possible without much detriment to other parts of the code.
I don't think it's reasonable nor is it current practice to require every commit to be tested on every affected platform. That would obviously be nice data points to have but that has not been coreboot reality in the past 20 years and I predict that it will also not be so in the next 20 years. I think that's fine.
I hope you can understand that my ask is simply to not erase what might be working well based only on a lack of information.
I'm obviously grateful that the leadership meeting settled on keeping quark at least as long as it causes no problems. Thanks for that!
Kind regards
//Peter _______________________________________________ coreboot mailing list -- coreboot@coreboot.org To unsubscribe send an email to coreboot-leave@coreboot.org
On Tue, 2022-04-12 at 23:22 +0200, Martin Roth via coreboot wrote:
Apr 12, 2022, 12:14 by foss@mniewoehner.de:
On Mon, 2022-04-11 at 22:23 +0000, Peter Stuge wrote:
Martin Roth via coreboot wrote:
1) Please don't use the term deprecate - use "moved to a branch"
I don't think the wording matters, my points are discoverability and drive-by maintainance.
Yes, wording matters. Opinions are changed in politics by just reframing the argument all the time. If you really don't think that wording matters check out this article, and the book that it's about: https://commonslibrary.org/frame-the-debate-insights-from-dont-think-of-an-e...
Every time coreboot says that some platform is being "deprecated", it starts an argument. I'd really like to avoid that argument.
Agreed.
If a platform is perfect and doesn't need to be updated, it doesn't need to be on the master branch, right?
I think wrong, because being on master is the only chance to receive tree-wide changes, e.g. through coccinelle spatches or sed:its.
Missing those rots the code quicker so yes, something getting moved to a non-master branch is de-facto deprecation by degradation to second class.
How can it degrade if it's not being changed? Older platforms that aren't being tested regularly stop working *because* they're in the main branch, receiving lots of code changes without being tested. By moving them to a branch, they're less likely to get additional breaking fixes. So allowing them to be maintained on a branch is much better for stability.
It's absolutely not second class either. If people understand that the older platforms are maintained on these version branches, they can be worked on there without having all of the changes on newer platforms to deal with. It's a matter of getting people used to working on those older branches.
Maintaining without ability to test will make it degrade, too.
Exactly. By moving it to a branch, if someone wants to work on a platform, they can do it in a more stable environment.
I absolutely agree that if something isn't being used, it doesn't need to be maintained on the master branch.
I disagree.
Ok. Any reason why? I don't understand why would we want to maintain something that nobody uses on the master branch. If it's not being used, it can just as easily not be used on a release branch as the master branch, and then we don't have to continue to try to maintain it as the rest of coreboot moves forward.
I just want to make sure that things actually aren't being used before moving them to a branch.
I think "no usage" alone should be a very weak motivator to move something from master, just like "no availability".
(Many SOCs are currently unavailable and will remain so for some time!)
Why It's not unavailable for *some time* but forever, bc it's not being produced anymore.
If code is perfect or nearly perfect then why move it?
Even if the code was "perfect" when it was written, it doesn't exist in a vacuum. As the rest of the coreboot platform changes around it, the perfect code can stop working.
Exactly that is the point. Without any testing the platform *cannot* be maintained (as in "make sure it is still usable"). It's like wanting to keep your pet "alive" by stuffing it. Erm. Sorry for this unlovely example... I just feel it fits very well...
If there are *concrete* issues with code then I think it would be reasonable for *that* to count much more than "no/unknown usage", but the current proposal did not reference any such issues, Paul's ask didn't yield any and neither did mine.
Not used => not tested.
And how do we know whether or not there are concrete issues with it if it's not being tested? Thanks for the discussion. Martin
Michael
On 12.04.22 23:22, Martin Roth via coreboot wrote:
Apr 12, 2022, 12:14 by foss@mniewoehner.de:
Maintaining without ability to test will make it degrade, too.
Exactly. By moving it to a branch, if someone wants to work on a platform, they can do it in a more stable environment.
I think it depends a lot how you define "degrade" and how the workflow of potential future contributors looks like. Platforms that are moved forward on the master branch without testing break, that's true. I've not seen any platform where every patch gets the necessary testing, though. So they all break from time to time. And what are the patches doing anyway, that break things? Usually, patches that touch a lot of platforms are about maintenance (e.g. keep things building with a new compiler) or refactoring to ease future development. So even if booting for some platform breaks, is the code really degrading? Or did some of the refactoring actually make it easier to fix it? And talking about slower moving branches as "a more stable environment": FWIW we moved code to such branches because it was in such an unreadable state that maintenance on master was too much effort. Is this true about Quark? IDK, but it seems nobody has said so yet.
I absolutely agree that if something isn't being used, it doesn't need to be maintained on the master branch.
I disagree.
Ok. Any reason why? I don't understand why would we want to maintain something that nobody uses on the master branch. If it's not being used, it can just as easily not be used on a release branch as the master branch, and then we don't have to continue to try to maintain it as the rest of coreboot moves forward.
It's always a trade-off. Is the Quark code really that bad that it is hard to keep it along? Nico
Apr 16, 2022, 08:03 by nico.h@gmx.de:
It's always a trade-off. Is the Quark code really that bad that it is hard to keep it along?
I'm not particularly looking at removing the Quark code right now. I lobbied early on to keep it in the tree. Really, I want 2 things out of this discussion. 1) Make it less harmful to move things to a release branch for maintenance. - After talking to Peter, this could be as simple as keeping the mainboard in the Kconfig with a hash that should be checkout out to build that board.2) Decide on a set of criteria that we can use to evaluate whether or not things should be removed from the master branch and maintained on a release branch. From past experience, we should be realistic and admit that platforms will eventually get moved out of the master branch at some point. If Quark isn't removed now, at some point, 3, 5, or 10 years from now, it's going to get removed from the master branch. As Ron mentioned, keeping platforms in master does have a cost. - The cost of testing isn't really all that high, but it's there. - The cost of maintaining the platform in the tree could also be an issue. That's the cost that Felix was looking at that started this discussion - he founds some code that was required for the quark platforms that he thought should be removed. - From Arthur's email about lb_serial - keeping platforms in the tree may require us to keep old workarounds in place. Currently, the only reason we have specified that a platform will be moved to a release branch is if it's hindering progress. Basically if it's not using an API we want to mark a required, or using code that is being deprecated. If hindering progress is the only reason that something should ever be removed from the master branch, I'm fine with that. Let's decide that and document it so we don't have to have this discussion in the future. Other options we could look at:- A platform has not been sold in X years. - A chip has not been produced for X years. - A platform has not been tested in X years. - A platform hasn't had an active maintainer for X years. (Maybe the maintainer should be asked to test a platform as well?) Hopefully, if we can make it easy enough to maintain a platform on a release branch, it won't be so much of an issue in the future, but it'd still be nice to have some criteria that we can agree on for when to move things. Thanks everyone. As always, I'm not trying to argue with anyone, just looking to get an actual decision of some sort out of this thread. Martin
(I'm not a Coreboot dev/maintainer, so apologies for commenting from the peanut gallery...) On Mon, Apr 18, 2022 at 04:32:36AM +0200, Martin Roth wrote:
[...] 2) Decide on a set of criteria that we can use to evaluate whether or not things should be removed from the master branch and maintained on a release branch.
Makes sense.
Currently, the only reason we have specified that a platform will be moved to a release branch is if it's hindering progress. Basically if it's not using an API we want to mark a required, or using code that is being deprecated.
If hindering progress is the only reason that something should ever be removed from the master branch, I'm fine with that. Let's decide that and document it so we don't have to have this discussion in the future.
Surely there will sometimes be platforms/chips that, for good reason, the community wants to keep in master - even if this would mean rewrites for those platforms/chips re the two matters you mentioned above: a. not using APIs that future versions of coreboot will require; b. using code that is being deprecated? Such "good reasons" could include that the plaform/chip: 1. is in widespread use with coreboot, even if long out of production (e.g. certain server boards or Thinkpad models); or 2. is targeted by related projects (e.g. Heads) that coreboot developers would prefer to avoid unnecessarily inconveniencing; or 3. has active coreboot testers/maintainers able to integrate relevant updates, and is passing all significant CI tests.
Other options we could look at:
- A platform has not been sold in X years.
- A chip has not been produced for X years.
I can see the appeal of these criteria: they are easy to define. However, they are probably not wise criteria, as they may conflict with one or more of the "good reasons" above, especially reason 1.
- A platform has not been tested in X years.
- A platform hasn't had an active maintainer for X years. (Maybe the maintainer should be asked to test a platform as well?)
These seem much better criteria. To make them easier to apply, should coreboot comprehensively track, for platforms/chips (roughly as Debian does for packages): - the current maintainer(s) for that platform/chip, - the current tester(s) for that platform/chip, - when that platform/chip was last tested, and - what the test results were? I think coreboot already tracks some of this data via https://lava.9esec.io or https://qa.coreboot.org/ - I'm not certain. That being so, I propose some draft policy wording (please change/improve...): "For any given platform or chip that has ever been targeted by the coreboot project: - For each coreboot "version" (point release, master, or hardware-specific branch): - if the platform/chip has been tested on that version, but the test was unsuccessful, the platform/chip shall be labelled *broken* re that version; else - if the test was successful, the platform/chip shall be labelled *working* re that version; else - the platform/chip shall be labelled *untested* re that version. - If the platform/chip has known security vulnerabilities on that version, the shall be labelled *vulnerable* re that version. - If the platform/chip has a person/team assigned to test/maintain it re master, it shall be labelled *maintained*, unless it has been *vulnerable*, *broken*, or *untested* re master for at least 6 months in which case it shall be labelled *unmaintained*, - If a platform/chip has been labelled *unmaintained* for at least 6 months, a branch shall be created for it, from the last coreboot point-release for which it was tested and found to be working. Such a platform/chip shall be labelled *relegated*. - A person/team who merges subsequent updates from master into such a branch, such that the branch becomes acceptable to the gatekeepers of master for merging back into master, and who also successfully tests the relegated platform/chip on the resulting codebase, and who volunteers to maintain that platform/chip for the foreseeable future, may become that platform/chip's maintainer, and upon the relevant changes being merged into master, the platform/chip shall no longer be labelled *relegated* but instead shall be labelled *tested* and *maintained*."
Thanks everyone [...] I'm not trying to argue with anyone, just looking to get an actual decision of some sort out of this thread.
Ditto! Sam
The discussion here has been pretty helpful to my thinking. I think the concerns people are raising are important. We are deprecating ALL boards on oreboot that need FSP, as we took the decision a few weeks ago to drop boards that require blobs on the main CPU (we're accepting PSP blobs for now) This leaves two x86 boards behind, not counting qemu. But, based on what has come up here, we decided we did not want to leave all memory of old efforts behind. This is the result: https://github.com/oreboot/oreboot/pull/570/files Not sure if this would be desired for coreboot, but I am mentioning it here for reference. Thanks ron On Mon, Apr 18, 2022 at 11:05 AM Sam Kuper <sam.kuper@uclmail.net> wrote:
(I'm not a Coreboot dev/maintainer, so apologies for commenting from the peanut gallery...)
On Mon, Apr 18, 2022 at 04:32:36AM +0200, Martin Roth wrote:
[...] 2) Decide on a set of criteria that we can use to evaluate whether or not things should be removed from the master branch and maintained on a release branch.
Makes sense.
Currently, the only reason we have specified that a platform will be moved to a release branch is if it's hindering progress. Basically if it's not using an API we want to mark a required, or using code that is being deprecated.
If hindering progress is the only reason that something should ever be removed from the master branch, I'm fine with that. Let's decide that and document it so we don't have to have this discussion in the future.
Surely there will sometimes be platforms/chips that, for good reason, the community wants to keep in master - even if this would mean rewrites for those platforms/chips re the two matters you mentioned above:
a. not using APIs that future versions of coreboot will require;
b. using code that is being deprecated?
Such "good reasons" could include that the plaform/chip:
1. is in widespread use with coreboot, even if long out of production (e.g. certain server boards or Thinkpad models); or
2. is targeted by related projects (e.g. Heads) that coreboot developers would prefer to avoid unnecessarily inconveniencing; or
3. has active coreboot testers/maintainers able to integrate relevant updates, and is passing all significant CI tests.
Other options we could look at:
- A platform has not been sold in X years.
- A chip has not been produced for X years.
I can see the appeal of these criteria: they are easy to define. However, they are probably not wise criteria, as they may conflict with one or more of the "good reasons" above, especially reason 1.
- A platform has not been tested in X years.
- A platform hasn't had an active maintainer for X years. (Maybe the maintainer should be asked to test a platform as well?)
These seem much better criteria.
To make them easier to apply, should coreboot comprehensively track, for platforms/chips (roughly as Debian does for packages):
- the current maintainer(s) for that platform/chip,
- the current tester(s) for that platform/chip,
- when that platform/chip was last tested, and
- what the test results were?
I think coreboot already tracks some of this data via https://lava.9esec.io or https://qa.coreboot.org/ - I'm not certain.
That being so, I propose some draft policy wording (please change/improve...):
"For any given platform or chip that has ever been targeted by the coreboot project:
- For each coreboot "version" (point release, master, or hardware-specific branch):
- if the platform/chip has been tested on that version, but the test was unsuccessful, the platform/chip shall be labelled *broken* re that version; else
- if the test was successful, the platform/chip shall be labelled *working* re that version; else
- the platform/chip shall be labelled *untested* re that version.
- If the platform/chip has known security vulnerabilities on that version, the shall be labelled *vulnerable* re that version.
- If the platform/chip has a person/team assigned to test/maintain it re master, it shall be labelled *maintained*, unless it has been *vulnerable*, *broken*, or *untested* re master for at least 6 months in which case it shall be labelled *unmaintained*,
- If a platform/chip has been labelled *unmaintained* for at least 6 months, a branch shall be created for it, from the last coreboot point-release for which it was tested and found to be working. Such a platform/chip shall be labelled *relegated*.
- A person/team who merges subsequent updates from master into such a branch, such that the branch becomes acceptable to the gatekeepers of master for merging back into master, and who also successfully tests the relegated platform/chip on the resulting codebase, and who volunteers to maintain that platform/chip for the foreseeable future, may become that platform/chip's maintainer, and upon the relevant changes being merged into master, the platform/chip shall no longer be labelled *relegated* but instead shall be labelled *tested* and *maintained*."
Thanks everyone [...] I'm not trying to argue with anyone, just looking to get an actual decision of some sort out of this thread.
Ditto!
Sam _______________________________________________ coreboot mailing list -- coreboot@coreboot.org To unsubscribe send an email to coreboot-leave@coreboot.org
Hey Ron, I think this is a good plan. We can make a markdown file doing the same. I'm not sure that coreboot wants to record where it's deleted, but instead the branch where it would be maintained. This is the solution I was talking about in the coreboot leadership meeting: https://review.coreboot.org/c/coreboot/+/63754 Take care. Martin Apr 22, 2022, 17:24 by rminnich@gmail.com:
The discussion here has been pretty helpful to my thinking. I think the concerns people are raising are important.
We are deprecating ALL boards on oreboot that need FSP, as we took the decision a few weeks ago to drop boards that require blobs on the main CPU (we're accepting PSP blobs for now)
This leaves two x86 boards behind, not counting qemu.
But, based on what has come up here, we decided we did not want to leave all memory of old efforts behind.
This is the result: https://github.com/oreboot/oreboot/pull/570/files
Not sure if this would be desired for coreboot, but I am mentioning it here for reference.
Thanks
ron
On Mon, Apr 18, 2022 at 11:05 AM Sam Kuper <sam.kuper@uclmail.net> wrote:
(I'm not a Coreboot dev/maintainer, so apologies for commenting from the peanut gallery...)
On Mon, Apr 18, 2022 at 04:32:36AM +0200, Martin Roth wrote:
[...] 2) Decide on a set of criteria that we can use to evaluate whether or not things should be removed from the master branch and maintained on a release branch.
Makes sense.
Currently, the only reason we have specified that a platform will be moved to a release branch is if it's hindering progress. Basically if it's not using an API we want to mark a required, or using code that is being deprecated.
If hindering progress is the only reason that something should ever be removed from the master branch, I'm fine with that. Let's decide that and document it so we don't have to have this discussion in the future.
Surely there will sometimes be platforms/chips that, for good reason, the community wants to keep in master - even if this would mean rewrites for those platforms/chips re the two matters you mentioned above:
a. not using APIs that future versions of coreboot will require;
b. using code that is being deprecated?
Such "good reasons" could include that the plaform/chip:
1. is in widespread use with coreboot, even if long out of production (e.g. certain server boards or Thinkpad models); or
2. is targeted by related projects (e.g. Heads) that coreboot developers would prefer to avoid unnecessarily inconveniencing; or
3. has active coreboot testers/maintainers able to integrate relevant updates, and is passing all significant CI tests.
Other options we could look at:
- A platform has not been sold in X years.
- A chip has not been produced for X years.
I can see the appeal of these criteria: they are easy to define. However, they are probably not wise criteria, as they may conflict with one or more of the "good reasons" above, especially reason 1.
- A platform has not been tested in X years.
- A platform hasn't had an active maintainer for X years. (Maybe the maintainer should be asked to test a platform as well?)
These seem much better criteria.
To make them easier to apply, should coreboot comprehensively track, for platforms/chips (roughly as Debian does for packages):
- the current maintainer(s) for that platform/chip,
- the current tester(s) for that platform/chip,
- when that platform/chip was last tested, and
- what the test results were?
I think coreboot already tracks some of this data via https://lava.9esec.io or https://qa.coreboot.org/ - I'm not certain.
That being so, I propose some draft policy wording (please change/improve...):
"For any given platform or chip that has ever been targeted by the coreboot project:
- For each coreboot "version" (point release, master, or hardware-specific branch):
- if the platform/chip has been tested on that version, but the test was unsuccessful, the platform/chip shall be labelled *broken* re that version; else
- if the test was successful, the platform/chip shall be labelled *working* re that version; else
- the platform/chip shall be labelled *untested* re that version.
- If the platform/chip has known security vulnerabilities on that version, the shall be labelled *vulnerable* re that version.
- If the platform/chip has a person/team assigned to test/maintain it re master, it shall be labelled *maintained*, unless it has been *vulnerable*, *broken*, or *untested* re master for at least 6 months in which case it shall be labelled *unmaintained*,
- If a platform/chip has been labelled *unmaintained* for at least 6 months, a branch shall be created for it, from the last coreboot point-release for which it was tested and found to be working. Such a platform/chip shall be labelled *relegated*.
- A person/team who merges subsequent updates from master into such a branch, such that the branch becomes acceptable to the gatekeepers of master for merging back into master, and who also successfully tests the relegated platform/chip on the resulting codebase, and who volunteers to maintain that platform/chip for the foreseeable future, may become that platform/chip's maintainer, and upon the relevant changes being merged into master, the platform/chip shall no longer be labelled *relegated* but instead shall be labelled *tested* and *maintained*."
Thanks everyone [...] I'm not trying to argue with anyone, just looking to get an actual decision of some sort out of this thread.
Ditto!
Sam _______________________________________________ coreboot mailing list -- coreboot@coreboot.org To unsubscribe send an email to coreboot-leave@coreboot.org
_______________________________________________ coreboot mailing list -- coreboot@coreboot.org To unsubscribe send an email to coreboot-leave@coreboot.org
we may be saying the same thing, but that commit in our file is the "check this out to get this board" ref. On Fri, Apr 22, 2022 at 5:41 PM Martin Roth <gaumless@tutanota.com> wrote:
Hey Ron, I think this is a good plan. We can make a markdown file doing the same. I'm not sure that coreboot wants to record where it's deleted, but instead the branch where it would be maintained. This is the solution I was talking about in the coreboot leadership meeting: https://review.coreboot.org/c/coreboot/+/63754
Take care. Martin Apr 22, 2022, 17:24 by rminnich@gmail.com:
The discussion here has been pretty helpful to my thinking. I think the concerns people are raising are important.
We are deprecating ALL boards on oreboot that need FSP, as we took the decision a few weeks ago to drop boards that require blobs on the main CPU (we're accepting PSP blobs for now)
This leaves two x86 boards behind, not counting qemu.
But, based on what has come up here, we decided we did not want to leave all memory of old efforts behind.
This is the result: https://github.com/oreboot/oreboot/pull/570/files
Not sure if this would be desired for coreboot, but I am mentioning it here for reference.
Thanks
ron
On Mon, Apr 18, 2022 at 11:05 AM Sam Kuper <sam.kuper@uclmail.net> wrote:
(I'm not a Coreboot dev/maintainer, so apologies for commenting from the peanut gallery...)
On Mon, Apr 18, 2022 at 04:32:36AM +0200, Martin Roth wrote:
[...] 2) Decide on a set of criteria that we can use to evaluate whether or not things should be removed from the master branch and maintained on a release branch.
Makes sense.
Currently, the only reason we have specified that a platform will be moved to a release branch is if it's hindering progress. Basically if it's not using an API we want to mark a required, or using code that is being deprecated.
If hindering progress is the only reason that something should ever be removed from the master branch, I'm fine with that. Let's decide that and document it so we don't have to have this discussion in the future.
Surely there will sometimes be platforms/chips that, for good reason, the community wants to keep in master - even if this would mean rewrites for those platforms/chips re the two matters you mentioned above:
a. not using APIs that future versions of coreboot will require;
b. using code that is being deprecated?
Such "good reasons" could include that the plaform/chip:
1. is in widespread use with coreboot, even if long out of production (e.g. certain server boards or Thinkpad models); or
2. is targeted by related projects (e.g. Heads) that coreboot developers would prefer to avoid unnecessarily inconveniencing; or
3. has active coreboot testers/maintainers able to integrate relevant updates, and is passing all significant CI tests.
Other options we could look at:
- A platform has not been sold in X years.
- A chip has not been produced for X years.
I can see the appeal of these criteria: they are easy to define. However, they are probably not wise criteria, as they may conflict with one or more of the "good reasons" above, especially reason 1.
- A platform has not been tested in X years.
- A platform hasn't had an active maintainer for X years. (Maybe the maintainer should be asked to test a platform as well?)
These seem much better criteria.
To make them easier to apply, should coreboot comprehensively track, for platforms/chips (roughly as Debian does for packages):
- the current maintainer(s) for that platform/chip,
- the current tester(s) for that platform/chip,
- when that platform/chip was last tested, and
- what the test results were?
I think coreboot already tracks some of this data via https://lava.9esec.io or https://qa.coreboot.org/ - I'm not certain.
That being so, I propose some draft policy wording (please change/improve...):
"For any given platform or chip that has ever been targeted by the coreboot project:
- For each coreboot "version" (point release, master, or hardware-specific branch):
- if the platform/chip has been tested on that version, but the test was unsuccessful, the platform/chip shall be labelled *broken* re that version; else
- if the test was successful, the platform/chip shall be labelled *working* re that version; else
- the platform/chip shall be labelled *untested* re that version.
- If the platform/chip has known security vulnerabilities on that version, the shall be labelled *vulnerable* re that version.
- If the platform/chip has a person/team assigned to test/maintain it re master, it shall be labelled *maintained*, unless it has been *vulnerable*, *broken*, or *untested* re master for at least 6 months in which case it shall be labelled *unmaintained*,
- If a platform/chip has been labelled *unmaintained* for at least 6 months, a branch shall be created for it, from the last coreboot point-release for which it was tested and found to be working. Such a platform/chip shall be labelled *relegated*.
- A person/team who merges subsequent updates from master into such a branch, such that the branch becomes acceptable to the gatekeepers of master for merging back into master, and who also successfully tests the relegated platform/chip on the resulting codebase, and who volunteers to maintain that platform/chip for the foreseeable future, may become that platform/chip's maintainer, and upon the relevant changes being merged into master, the platform/chip shall no longer be labelled *relegated* but instead shall be labelled *tested* and *maintained*."
Thanks everyone [...] I'm not trying to argue with anyone, just looking to get an actual decision of some sort out of this thread.
Ditto!
Sam _______________________________________________ coreboot mailing list -- coreboot@coreboot.org To unsubscribe send an email to coreboot-leave@coreboot.org
_______________________________________________ coreboot mailing list -- coreboot@coreboot.org To unsubscribe send an email to coreboot-leave@coreboot.org
oh oops the person doing that misunderstood me, we'll have to fix it On Fri, Apr 22, 2022 at 5:41 PM Martin Roth <gaumless@tutanota.com> wrote:
Hey Ron, I think this is a good plan. We can make a markdown file doing the same. I'm not sure that coreboot wants to record where it's deleted, but instead the branch where it would be maintained. This is the solution I was talking about in the coreboot leadership meeting: https://review.coreboot.org/c/coreboot/+/63754
Take care. Martin Apr 22, 2022, 17:24 by rminnich@gmail.com:
The discussion here has been pretty helpful to my thinking. I think the concerns people are raising are important.
We are deprecating ALL boards on oreboot that need FSP, as we took the decision a few weeks ago to drop boards that require blobs on the main CPU (we're accepting PSP blobs for now)
This leaves two x86 boards behind, not counting qemu.
But, based on what has come up here, we decided we did not want to leave all memory of old efforts behind.
This is the result: https://github.com/oreboot/oreboot/pull/570/files
Not sure if this would be desired for coreboot, but I am mentioning it here for reference.
Thanks
ron
On Mon, Apr 18, 2022 at 11:05 AM Sam Kuper <sam.kuper@uclmail.net> wrote:
(I'm not a Coreboot dev/maintainer, so apologies for commenting from the peanut gallery...)
On Mon, Apr 18, 2022 at 04:32:36AM +0200, Martin Roth wrote:
[...] 2) Decide on a set of criteria that we can use to evaluate whether or not things should be removed from the master branch and maintained on a release branch.
Makes sense.
Currently, the only reason we have specified that a platform will be moved to a release branch is if it's hindering progress. Basically if it's not using an API we want to mark a required, or using code that is being deprecated.
If hindering progress is the only reason that something should ever be removed from the master branch, I'm fine with that. Let's decide that and document it so we don't have to have this discussion in the future.
Surely there will sometimes be platforms/chips that, for good reason, the community wants to keep in master - even if this would mean rewrites for those platforms/chips re the two matters you mentioned above:
a. not using APIs that future versions of coreboot will require;
b. using code that is being deprecated?
Such "good reasons" could include that the plaform/chip:
1. is in widespread use with coreboot, even if long out of production (e.g. certain server boards or Thinkpad models); or
2. is targeted by related projects (e.g. Heads) that coreboot developers would prefer to avoid unnecessarily inconveniencing; or
3. has active coreboot testers/maintainers able to integrate relevant updates, and is passing all significant CI tests.
Other options we could look at:
- A platform has not been sold in X years.
- A chip has not been produced for X years.
I can see the appeal of these criteria: they are easy to define. However, they are probably not wise criteria, as they may conflict with one or more of the "good reasons" above, especially reason 1.
- A platform has not been tested in X years.
- A platform hasn't had an active maintainer for X years. (Maybe the maintainer should be asked to test a platform as well?)
These seem much better criteria.
To make them easier to apply, should coreboot comprehensively track, for platforms/chips (roughly as Debian does for packages):
- the current maintainer(s) for that platform/chip,
- the current tester(s) for that platform/chip,
- when that platform/chip was last tested, and
- what the test results were?
I think coreboot already tracks some of this data via https://lava.9esec.io or https://qa.coreboot.org/ - I'm not certain.
That being so, I propose some draft policy wording (please change/improve...):
"For any given platform or chip that has ever been targeted by the coreboot project:
- For each coreboot "version" (point release, master, or hardware-specific branch):
- if the platform/chip has been tested on that version, but the test was unsuccessful, the platform/chip shall be labelled *broken* re that version; else
- if the test was successful, the platform/chip shall be labelled *working* re that version; else
- the platform/chip shall be labelled *untested* re that version.
- If the platform/chip has known security vulnerabilities on that version, the shall be labelled *vulnerable* re that version.
- If the platform/chip has a person/team assigned to test/maintain it re master, it shall be labelled *maintained*, unless it has been *vulnerable*, *broken*, or *untested* re master for at least 6 months in which case it shall be labelled *unmaintained*,
- If a platform/chip has been labelled *unmaintained* for at least 6 months, a branch shall be created for it, from the last coreboot point-release for which it was tested and found to be working. Such a platform/chip shall be labelled *relegated*.
- A person/team who merges subsequent updates from master into such a branch, such that the branch becomes acceptable to the gatekeepers of master for merging back into master, and who also successfully tests the relegated platform/chip on the resulting codebase, and who volunteers to maintain that platform/chip for the foreseeable future, may become that platform/chip's maintainer, and upon the relevant changes being merged into master, the platform/chip shall no longer be labelled *relegated* but instead shall be labelled *tested* and *maintained*."
Thanks everyone [...] I'm not trying to argue with anyone, just looking to get an actual decision of some sort out of this thread.
Ditto!
Sam _______________________________________________ coreboot mailing list -- coreboot@coreboot.org To unsubscribe send an email to coreboot-leave@coreboot.org
_______________________________________________ coreboot mailing list -- coreboot@coreboot.org To unsubscribe send an email to coreboot-leave@coreboot.org
We are deprecating ALL boards on oreboot that need FSP, as we took the decision a few weeks ago to drop boards that require blobs on the main CPU (we're accepting PSP blobs for now)
Just a quick note that our society basically has the technology to automatically reimplement binary blobs as differently licensed source. Somebody simply needs to design and train appropriate translation models between interfaces, behavior, and data. Actually doing that would come down to harsh and difficult politics, of course, so it could be quite some time before it happens, during which laws may change.
On Fri, Apr 22, 2022 at 11:59 PM Karl Semich <0xloem@gmail.com> wrote:
We are deprecating ALL boards on oreboot that need FSP, as we took the decision a few weeks ago to drop boards that require blobs on the main CPU (we're accepting PSP blobs for now)
Just a quick note that our society basically has the technology to automatically reimplement binary blobs as differently licensed source.
Absent seeing a demonstration, I'll leave this state as "important if true." :-)
On Sat, Apr 23, 2022, 11:40 AM ron minnich <rminnich@gmail.com> wrote:
On Fri, Apr 22, 2022 at 11:59 PM Karl Semich <0xloem@gmail.com> wrote:
We are deprecating ALL boards on oreboot that need FSP, as we took the decision a few weeks ago to drop boards that require blobs on the main CPU (we're accepting PSP blobs for now)
Just a quick note that our society basically has the technology to automatically reimplement binary blobs as differently licensed source.
Absent seeing a demonstration, I'll leave this state as "important if true." :-)
Here are some examples of mainstream research: https://twitter.com/ak92501 Roughly, transformer models are quite good at converting between conceptual representations, but take a lot of training (can be months of compute cluster use) to learn new kinds of concepts well. Models can be finetuned to make different use of their existing concepts relatively quickly on consumer hardware. There are existing pretrained models that can predict source code. If you'd like to discuss or work on this with me further, let's start a new thread.
participants (15)
-
Andy Pont -
Arthur Heymans -
Felix Singer -
Karl Semich -
Martin Roth -
Michael Niewöhner -
Nico Huber -
Patrick Georgi -
Paul Menzel -
Peter Stuge -
ron minnich -
Sam Kuper -
Sheng Lean Tan -
Undiscussed Horrific Abuse, One Victim of Many -
Zimmer, Vincent