[coreboot] Re: Deprecation of the Intel Quark SoC
> > > 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. > ___ coreboot mailing list -- coreboot@coreboot.org To unsubscribe send an email to coreboot-le...@coreboot.org
[coreboot] RFC: Clarifying use of GCC extensions in the coding style
Hi, We occasionally get into discussions in code reviews when code uses a GCC extension, and a reviewer asks that it be rewritten to be C standard compliant instead. A recent example was on the use of `void *` arithmetic in this patch https://review.coreboot.org/c/coreboot/+/56791/9/src/soc/mediatek/common/pcie.c#109 , and there have been others in the past. I would like to come to a consensus on this topic here and add some blurb to the coding style document so we don't have to rehash the same discussion over and over again. In my opinion, GCC extensions are absolutely necessary for coreboot development and there should be no reason to reject them. Inline assembly is the most obvious example -- without it we would have to convert a ton of static inline functions that wrap special instructions into full linker-level functions in a separate assembly file instead, and eat all the unnecessary function call overhead that comes with that. Others enable such important features that it would become much more dangerous and cumbersome to develop without them -- most importantly statement expressions (https://gcc.gnu.org/onlinedocs/gcc-11.2.0/gcc/Statement-Exprs.html) which are necessary to write things like double-evaluation safe macros, expression-assertions like dead_code_t() and simple convenience shortcuts like wait_us(). And some extensions just offer a small bit of convenience to reduce boilerplate -- for example, `void *` arithmetic just tends to be useful to prevent cluttering the code with a bunch of unnecessary casts to other types that don't add any additional meaning to the data (e.g. for an unspecified buffer of opaque data I think `void *` is a much more appropriate type than `uint8_t *`, even if I want to add a byte offset to it), and I've never seen a case where I think it would have actually been unclear to anyone what step width the pointer arithmetic was done at (there's no reason to assume anything other than bytewise for a `void *`). If we need some extensions anyway, and coreboot will never be "fully C standards compliant" (not that that would actually be very useful for anything in practice), I don't see a reason why we should still avoid some extensions when we're using others. I think if an (official, long-term supported) extension exists and it allows us to write better code than standard C, there should be no reason not to use it. (Note that for those people who are trying to get coreboot working with clang, it generally supports all the same extensions as GCC.) I've written a draft CL to add a section for this to the coding style, please let me know what you think: https://review.coreboot.org/c/coreboot/+/63660 ___ coreboot mailing list -- coreboot@coreboot.org To unsubscribe send an email to coreboot-le...@coreboot.org
[coreboot] Re: Deprecation of the Intel Quark SoC
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 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 > Sent: Friday, April 15, 2022 11:13 AM > To: Zimmer, Vincent ; Karl Semich > <0xl...@gmail.com>; lpleah...@gmail.com > Cc: Coreboot > 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-le...@coreboot.org ___ coreboot mailing list -- coreboot@coreboot.org To unsubscribe send an email to coreboot-le...@coreboot.org
[coreboot] Re: Deprecation of the Intel Quark SoC
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 Sent: Friday, April 15, 2022 11:13 AM To: Zimmer, Vincent ; Karl Semich <0xl...@gmail.com>; lpleah...@gmail.com Cc: Coreboot 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-le...@coreboot.org
[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-le...@coreboot.org
[coreboot] Re: Deprecation of the Intel Quark SoC
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 ___ coreboot mailing list -- coreboot@coreboot.org To unsubscribe send an email to coreboot-le...@coreboot.org
