I strongly agree with you that no currently-used-boards should be dropped from coreboot, because even a person who is "just a user" could become a contributor eventually, and it would have been really foolish to artificially reduce the userbase/coderbase by "forking out" the people... However,
As a pure consulting service, the ports and customizations that we have made to coreboot to support our clients' hardware (including the work done for Intel) is turned over to the client at the end of each project to do with as they please. If they choose to upstream it or not to coreboot.org is really up to them, and if they do, it would get upstreamed by them, not by us, since they then own the code. <--- ???
Almost all the coreboot source code is GPLv2 licensed, not some commercial closed-source proprietary license, and you will not be breaking this GPLv2 license by contributing your patches even though they have been created by the request of your clients. If you are providing the coreboot consulting to your clients, it is quite likely that they don't know much about coreboot (at least compared to you) and would not be able to contribute the patches in the mergeable quality even if they wanted, so you shouldn't rely on them here.
It would be really nice if you could look through your patches and contribute at least those which are "not motherboard-specific". If you would start giving back more than you are currently, there would be smaller chance of your boards dropped. And your clients should understand that, although no client's approval is required to contribute these patches for GPLv2 open source software
Best regards, Mike Banon On Wed, Nov 28, 2018 at 5:00 AM Jay Talbott JayTalbott@sysproconsulting.com wrote:
Hi Paul,
-----Original Message----- From: coreboot [mailto:coreboot-bounces@coreboot.org] On Behalf Of Paul Menzel Sent: Sunday, November 25, 2018 7:29 AM To: Jay Talbott; Arthur Heymans; Patrick Georgi Cc: coreboot@coreboot.org Subject: Re: [coreboot] Further coreboot releases, setting new standards
Dear Jay,
Am Freitag, den 23.11.2018, 19:20 -0700 schrieb Jay Talbott:
I know I don't post much here, but I feel like I need to chime in on this thread... Perhaps it's time that SysPro becomes a louder voice in the community.
Bay Trail and Broadwell DE are both still very popular platforms, yet neither one of them meets the cut for any of the three criteria. So I caution against removing the support for either of them too hastily.
It’d be nice if you gave a little bit more background, what your company does.
Normally I wouldn't promote what we do in this forum, but since you asked...
SysPro Consulting is a team of low-level software/firmware engineers. Developing coreboot+FSP solutions for Intel-based systems is one of our key areas of expertise, and currently makes up the majority of our business. SysPro is one of the licensed coreboot consulting services listed on the coreboot website. We are also one of Intel's firmware ecosystem partners.
Starting back when Intel first came out with the very first FSP, I spent several years providing consulting services directly to Intel working with Intel's FSP team to help enable coreboot+FSP solutions on customer boards and systems based on various Intel platforms (including Bay Trail and Broadwell-DE, which are still popular platforms today, but are potentially on the chopping block for coreboot, which is why I chimed into this discussion).
Since then, I have worked directly with a number of Intel customers to develop custom coreboot+FSP solutions for their products. During 2018 I have expanded SysPro from being just myself as an independent consultant to become a whole team of consultants, and we are anticipating continued growth in 2019 and beyond. Developing custom BIOS and BIOS alternative (e.g. coreboot+FSP) firmware solutions is anticipated to be a significant part of our business going forward.
We also have an FSP source license from Intel so that we can generate custom FSPs as needed for clients that need certain workarounds, bug fixes, or enhanced functionality.
I can’t find any commits from you for example.
git log --author=sysprocAlthough I have participated in a number of reviews of coreboot patches, I/we have not directly upstreamed any patches to coreboot.org. As a pure consulting service, the ports and customizations that we have made to coreboot to support our clients' hardware (including the work done for Intel) is turned over to the client at the end of each project to do with as they please. If they choose to upstream it or not to coreboot.org is really up to them, and if they do, it would get upstreamed by them, not by us, since they then own the code.
Yes, it can be a pain to keep maintaining old platforms, and certainly support for platforms that are old enough that they are no longer being used by anybody are good candidates for cleanup and removal. But support for platforms that are still popular and still actively being used by people shouldn't be stripped out of the coreboot code base.
How should coreboot upstream know, what is popular or not? So it’s good that you engage with the community.
I anticipate going forward that we will have a greater presence in the coreboot community exactly for that reason.
On the other hand, you didn’t answer any of the issues raised by Arthur, that maintaining outdated chipsets and boards puts the burden on – often freetime – developers.
I wouldn't call either Bay Trail or Broadwell-DE as "outdated" given that Intel customers are still actively designing and building boards and systems based around both of those SoCs. But, I will admit that the FSPs for both were from when FSPs were still being created to the FSP 1.0 spec, which has since been superseded by the FSP 2.0 spec., and it's highly doubtful that Intel would ever go back and make new FSP 2.0 compliant FSPs for these platforms. This obviously puts a burden on the coreboot source code to continue to support platforms based on the older FSP interface, but I don't think that's a good enough reason to decide that support for such platforms should be removed from the coreboot code base just because they don't fully conform to a set of ideal requirements. Yes, it would sure be nice if every platform conformed, but reality isn't always that simple or pretty.
How can SysPro help here improve the boards and implement the things Arthur raised? It’d be nice to have SysPro as a more active member of the coreboot community by contributing code, documentation, or money.
As I previously said, I anticipate going forward that we will have a greater presence in the coreboot community. What exactly that will look like is still TBD.
If that is not possible, please answer, what the problem would be for you to just use the current code from a separate branch.
If it really comes down to it and coreboot drops support for CPUs and SoCs that we are still actively using/supporting for our clients, then we will have to do just that... just work off a branch from the last release when such platforms were still supported, and cherry pick into our branch the subsequent commits of interest on the master branch. But as long as a particular platform is still actively being used, it would be a shame IMHO to drop support for it.
Kind regards,
Paul
PS: Your mailer doesn’t set the References header field, causing the threading to be broken.
Seems to be an issue with the version of Outlook I am using. Not sure there's anything I can do about that.
PPS: Please also at least send a plain text part. A lot of people prefer to look at that, and it also works better with the mailing list archive. (I’d even prefer to not get any HTML stuff at all. The Linux Kernel Mailing List even rejects such messages.)
I'll try to remember to do that. This reply is in plain text.
November/087852.html
-- coreboot mailing list: coreboot@coreboot.org https://mail.coreboot.org/mailman/listinfo/coreboot