Dear coreboot community
While the next coreboot release is due for november 2018, I think it is worthwhile to think about further releases and standards we want to set.
In the past coreboot adapted numerous general improvements, which were not always ported to all coreboot targets. Keeping those platforms and their respective codepath then typically becomes a burden often accompanied with regressions. The reasonable decision to drop these targets was then made. A few examples of this were dropping targets that had a romcc compiled romstage (in favor of GCC compiled romstage running in Cache As Ram) and dropping targets without early_cbmem.
Coreboot hasn't stood still and it might be time to set some new standards again which platforms have to conform. Since I mostly know x86 the following ideas will be quite x86 centric. I'd argue for requiring the following:
- getting rid of NO_RELOCATABLE_RAMSTAGE on x86
This allows the ramstage to be relocated in a place out of the way of the OS such that copying the memory is unnecessary during S3 resume.
- config NO_CAR_GLOBAL_MIGRATION on all x86 targets
This is now achieved using postcar stage. This would mean that all x86 targets have a common way to set up and get rid of the CAR environment and car globals.
- config C_ENVIRONMENT_BOOTBLOCK on all x86 targets
This means that the bootblock is responsible to set up the CAR, which means that the rest of the bootblock can be compiled with GCC. This effectively makes ROMCC bootblocks obsolete. Having a bootblock with access to a working stack effectively increases the bootflow flexibility. This is reflected in for instance when using VBOOT, which can then verify all stages starting from the romstage, hence also allowing a fallback with regards to ram initialization (vs. having the romstage only in the RO_WP region). It would be a important step in making vboot useful and usable and maybe default on all targets.
Any suggestions, reflections, ideas, remarks?
Kind regards
Arthur
Am Fr., 23. Nov. 2018 um 14:43 Uhr schrieb Arthur Heymans < arthur@aheymans.xyz>:
I'd argue for requiring the following:
In which time frame? The next release, ie May 2019? In two releases, November 2019?
Patrick
Patrick Georgi via coreboot coreboot@coreboot.org writes:
Am Fr., 23. Nov. 2018 um 14:43 Uhr schrieb Arthur Heymans arthur@aheymans.xyz:
I'd argue for requiring the following:
In which time frame? The next release, ie May 2019? In two releases, November 2019?
That is indeed worthy item of discussion.
NO_RELOCATABLE_RAMSTAGE on x86 is only selected by: NORTHBRIDGE_AMD_AMDFAM10, NORTHBRIDGE_AMD_LX, NORTHBRIDGE_VIA_VX900, SOC_INTEL_FSP_BAYTRAIL, SOC_INTEL_FSP_BROADWELL_DE
POSTCAR_STAGE is selected by: cpu/amd/agesa cpu/amd/pi mainboard/intel/galileo northbridge/intel/i440bx northbridge/intel/i945 northbridge/intel/e7505 northbridge/intel/gm45 northbridge/intel/haswell northbridge/intel/nehalem northbridge/intel/pineview northbridge/intel/sandybridge northbridge/intel/sandybridge northbridge/intel/x4x soc/amd/stoneyridge soc/intel/apollolake soc/intel/cannonlake soc/intel/denverton_ns soc/intel/skylake soc/intel/icelake so all other x86 targets don't implement it and therefore lack NO_CAR_GLOBAL_MIGRATION.
C_ENVIRONMENT_BOOTBLOCK is even less used since it is a relatively new feature (was introduced with INTEL_APOLLOLAKE and INTEL_SKYLAKE) so most x86 targets don't implement it but there are already many patches for it lying around for review (like most targets in northbridge/intel/*). It is however a very useful feature to have.
So it would seem reasonable to drop NO_RELOCATABLE_RAMSTAGE in may 2019 and mandate NO_CAR_GLOBAL_MIGRATION and C_ENVIRONMENT_BOOTBLOCK in november 2019? Any thoughts on this?
Nico also suggested to set the timeframe 2 weeks before the release, to avoid last minute WIP patches attempting to tackle the issue right before the release.
Am Fr., 23. Nov. 2018 um 16:32 Uhr schrieb Arthur Heymans < arthur@aheymans.xyz>:
Nico also suggested to set the timeframe 2 weeks before the release, to avoid last minute WIP patches attempting to tackle the issue right before the release.
The more regular approach is to drop the features and boards right _after_ release. That way 4.9 will be the last release with the boards in question, and 4.9+ will be the first cleaned up release.
Patrick
On 23.11.18 17:00, Patrick Georgi via coreboot wrote:
Am Fr., 23. Nov. 2018 um 16:32 Uhr schrieb Arthur Heymans < arthur@aheymans.xyz>:
Nico also suggested to set the timeframe 2 weeks before the release, to avoid last minute WIP patches attempting to tackle the issue right before the release.
The more regular approach is to drop the features and boards right _after_ release.
Sorry, that wasn't thought through. What I meant is somewhat: If a board doesn't have the required features after a release, it should be removed unless there is a review ongoing that started earlier than two weeks before the release (i.e. the patches had a real chance to get in).
Background: A year ago (iirc), somebody was working on patches around the release and didn't want the affected board(s) removed even it was too late. Delaying the removal means a lot extra work for maintainers, probably more work than to add the boards back later again. I don't want that to happen again, but also don't want to remove boards that have a patch that wasn't reviewed yet (e.g. because nobody had the time).
With that in mind, maybe make it 2 months.
Nico
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.
I can’t find any commits from you for example.
git log --author=sysproc
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.
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.
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.
If that is not possible, please answer, what the problem would be for you to just use the current code from a separate branch.
Kind regards,
Paul
PS: Your mailer doesn’t set the References header field, causing the threading to be broken.
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.)
[1]: https://mail.coreboot.org/pipermail/coreboot/2018-November/087852.html
On 2018-11-23 04:32 PM, Arthur Heymans wrote:
Patrick Georgi via coreboot coreboot@coreboot.org writes:
Am Fr., 23. Nov. 2018 um 14:43 Uhr schrieb Arthur Heymans arthur@aheymans.xyz:
I'd argue for requiring the following:
In which time frame? The next release, ie May 2019? In two releases, November 2019?
That is indeed worthy item of discussion.
NO_RELOCATABLE_RAMSTAGE on x86 is only selected by: NORTHBRIDGE_AMD_AMDFAM10, NORTHBRIDGE_AMD_LX, NORTHBRIDGE_VIA_VX900, SOC_INTEL_FSP_BAYTRAIL, SOC_INTEL_FSP_BROADWELL_DE
POSTCAR_STAGE is selected by: cpu/amd/agesa cpu/amd/pi mainboard/intel/galileo northbridge/intel/i440bx northbridge/intel/i945 northbridge/intel/e7505 northbridge/intel/gm45 northbridge/intel/haswell northbridge/intel/nehalem northbridge/intel/pineview northbridge/intel/sandybridge northbridge/intel/sandybridge northbridge/intel/x4x soc/amd/stoneyridge soc/intel/apollolake soc/intel/cannonlake soc/intel/denverton_ns soc/intel/skylake soc/intel/icelake so all other x86 targets don't implement it and therefore lack NO_CAR_GLOBAL_MIGRATION.
Not sure what to do here. I haven't looked at it and there's no documentation.
C_ENVIRONMENT_BOOTBLOCK is even less used since it is a relatively new feature (was introduced with INTEL_APOLLOLAKE and INTEL_SKYLAKE) so most x86 targets don't implement it but there are already many patches for it lying around for review (like most targets in northbridge/intel/*). It is however a very useful feature to have.
So it would seem reasonable to drop NO_RELOCATABLE_RAMSTAGE in may 2019 and mandate NO_CAR_GLOBAL_MIGRATION and C_ENVIRONMENT_BOOTBLOCK in november 2019? Any thoughts on this?
Sound like a good plan. All maintainers (via git log/gerrit/MAINTAINERS) should be notified now, if this is going to happen, to make sure that they are aware of the (bad) code quality. I don't think that it'll be a problem of time or money if everybody has been properly warned.
Nico also suggested to set the timeframe 2 weeks before the release, to avoid last minute WIP patches attempting to tackle the issue right before the release.
--
Arthur Heymans
"Jay Talbott" jaytalbott@sysproconsulting.com writes:
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.
Could you test with "select NO_RELOCATABLE_RAMSTAGE"?
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.
It's not about old or new. For instance the Intel i440bx (20y old) is still supported by coreboot, uses many recent features like POSTCAR_STAGE and relocatable ramstage, so it would be flagged 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.
If they are still popular and actively used, it would mean that someone has interest towards achieving new coreboot standards? Pushing standards is not really about active use or not but about improving the code base.
My $0.02.
- Jay
Jay Talbott SysPro Consulting, LLC 3057 E. Muirfield St. Gilbert, AZ 85297 (480) 704-8045 (480) 445-9895 (FAX) JayTalbott@sysproconsulting.com http://www.sysproconsulting.com
-------- Original Message -------- Subject: Re: [coreboot] Further coreboot releases, setting new standards From: Arthur Heymans arthur@aheymans.xyz Date: Fri, November 23, 2018 8:32 am To: Patrick Georgi via coreboot coreboot@coreboot.org Cc: Patrick Georgi pgeorgi@google.com
Patrick Georgi via coreboot coreboot@coreboot.org writes:
Am Fr., 23. Nov. 2018 um 14:43 Uhr schrieb Arthur Heymans arthur@aheymans.xyz:
I'd argue for requiring the following:
In which time frame? The next release, ie May 2019? In two releases, November 2019?
That is indeed worthy item of discussion.
NO_RELOCATABLE_RAMSTAGE on x86 is only selected by: NORTHBRIDGE_AMD_AMDFAM10, NORTHBRIDGE_AMD_LX, NORTHBRIDGE_VIA_VX900, SOC_INTEL_FSP_BAYTRAIL, SOC_INTEL_FSP_BROADWELL_DE
POSTCAR_STAGE is selected by: cpu/amd/agesa cpu/amd/pi mainboard/intel/galileo northbridge/intel/i440bx northbridge/intel/i945 northbridge/intel/e7505 northbridge/intel/gm45 northbridge/intel/haswell northbridge/intel/nehalem northbridge/intel/pineview northbridge/intel/sandybridge northbridge/intel/sandybridge northbridge/intel/x4x soc/amd/stoneyridge soc/intel/apollolake soc/intel/cannonlake soc/intel/denverton_ns soc/intel/skylake soc/intel/icelake so all other x86 targets don't implement it and therefore lack NO_CAR_GLOBAL_MIGRATION.
C_ENVIRONMENT_BOOTBLOCK is even less used since it is a relatively new feature (was introduced with INTEL_APOLLOLAKE and INTEL_SKYLAKE) so most x86 targets don't implement it but there are already many patches for it lying around for review (like most targets in northbridge/intel/*). It is however a very useful feature to have.
So it would seem reasonable to drop NO_RELOCATABLE_RAMSTAGE in may 2019 and mandate NO_CAR_GLOBAL_MIGRATION and C_ENVIRONMENT_BOOTBLOCK in november 2019? Any thoughts on this?
Nico also suggested to set the timeframe 2 weeks before the release, to avoid last minute WIP patches attempting to tackle the issue right before the release.
--
Arthur Heymans
-- coreboot mailing list: coreboot@coreboot.org https://mail.coreboot.org/mailman/listinfo/coreboot
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=sysproc
Although 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
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
Hello Mike,
Am 28.11.18 um 13:27 schrieb Mike Banon:
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.
They wouldn't break "this GPLv2 license" (what ever that means) *but* they'd likely break copyright as the changes aren't GPLv2 licensed (yet) in this case. But... I'm not a lawyer, you are not a lawyer (I assume), please *do not give legal advice on this mailing list*.
And please read the GPL. Don't make claims about it, unless you under- stood it as a whole (hint: there's a part about products and distri- bution in binary form, iirc, that you should read carefully).
I agree that the changes might contain cherries to pick. But that doesn't change the way licenses work. If you want to change that, go out on the street, protest against copyright.
Nico
"Jay Talbott" jaytalbott@sysproconsulting.com writes:
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.
I looked into that FSP 1.0 integration code a little. It would seem to me that relocatable ramstage and C_ENVIRONMENT_BOOTBLOCK are possible. NO_CAR_GLOBAL_MIGRATION however seems rather impossible as the FSP has total control over the environment and destroys the CAR environment itself. Since I propose the standards I could offer some help to reach them.
It looks like FSP 1.0 will be dragging coreboot down for some time. Maybe we can agree not to integrate such monsters into coreboot in the future? BTW baytrail has a non FSP port that will likely be in better shape.
Kind regards
Arthur Heymans
-----Original Message----- From: Arthur Heymans [mailto:arthur@aheymans.xyz] Sent: Wednesday, November 28, 2018 6:26 AM To: Jay Talbott Cc: Patrick Georgi via coreboot; Patrick Georgi Subject: Re: [coreboot] Further coreboot releases, setting new standards
"Jay Talbott" jaytalbott@sysproconsulting.com writes:
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.
I looked into that FSP 1.0 integration code a little. It would seem to me that relocatable ramstage and C_ENVIRONMENT_BOOTBLOCK are possible. NO_CAR_GLOBAL_MIGRATION however seems rather impossible as the FSP has total control over the environment and destroys the CAR environment itself. Since I propose the standards I could offer some help to reach them.
It looks like FSP 1.0 will be dragging coreboot down for some time. Maybe we can agree not to integrate such monsters into coreboot in the future?
As far as I'm aware, Intel won't be developing anymore FSP 1.0 FSPs. It was all part of a learning curve on everybody's part during the early days of the FSP. At the same time, even for popular platforms, they won't be going back and respinning old FSP 1.0 FSPs as FSP 2.0 FSPs. So as long as these platforms are still popular, we will need to continue to support these platforms for a while even though they don't nicely fit into the utopian future of coreboot.
BTW baytrail has a non FSP port that will likely be in better shape.
Kind regards
Arthur Heymans
On 28.11.18 14:25, Arthur Heymans wrote:
"Jay Talbott" jaytalbott@sysproconsulting.com writes:
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.
I looked into that FSP 1.0 integration code a little. It would seem to me that relocatable ramstage and C_ENVIRONMENT_BOOTBLOCK are possible. NO_CAR_GLOBAL_MIGRATION however seems rather impossible as the FSP has total control over the environment and destroys the CAR environment itself. Since I propose the standards I could offer some help to reach them.
It looks like FSP 1.0 will be dragging coreboot down for some time.
One way to mitigate would be to port the x86emu to CAR stages. Then just do what we always did with incompatible binaries, cage them. Would be a nice exercise for those that think FSP 1.0 needs to be maintained up- stream.
Maybe we can agree not to integrate such monsters into coreboot in the future? BTW baytrail has a non FSP port that will likely be in better shape.
Yes please.
Nico
On 28.11.18 16:10, Jay Talbott wrote:
"Jay Talbott" jaytalbott@sysproconsulting.com writes:
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.
I looked into that FSP 1.0 integration code a little. It would seem to me that relocatable ramstage and C_ENVIRONMENT_BOOTBLOCK are possible. NO_CAR_GLOBAL_MIGRATION however seems rather impossible as the FSP has total control over the environment and destroys the CAR environment itself. Since I propose the standards I could offer some help to reach them.
It looks like FSP 1.0 will be dragging coreboot down for some time. Maybe we can agree not to integrate such monsters into coreboot in the future?
As far as I'm aware, Intel won't be developing anymore FSP 1.0 FSPs. It was all part of a learning curve on everybody's part during the early days of the FSP. At the same time, even for popular platforms, they won't be going back and respinning old FSP 1.0 FSPs as FSP 2.0 FSPs. So as long as these platforms are still popular, we will need to continue to support these platforms for a while even though they don't nicely fit into the utopian future of coreboot.
Well, support what you want to support. It doesn't have to happen upstream. I really don't understand what all the fuss is about. Apart from build tests, these platforms are effectively unmaintained. They gain nothing on the master branch unless somebody is forced to update them in any way (and when that happens, it's unlikely to get tested before the commits land). The code looks ugly, it was never really reviewed. Apart from being a disgrace for the project, I don't see what difference it makes.
Nico
On 28.11.18 02:59, Jay Talbott wrote:
Although 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.
You could change the terms, I guess. Many people don't care that much. So you could ask your clients ahead if they'd agree to license the code under the GPL (or maybe only the parts that are not in their mainboard/ dir). If somebody agrees and it turns out later that there is a commit that could benefit upstream, you can push it.
Nico
FYI https://review.coreboot.org/c/coreboot/+/29820/3/MAINTAINERS#219
We will take care of the SoC support. I think Werner will jump in as well.
On 28.11.18 22:04, Nico Huber wrote:
On 28.11.18 02:59, Jay Talbott wrote:
Although 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.
You could change the terms, I guess. Many people don't care that much. So you could ask your clients ahead if they'd agree to license the code under the GPL (or maybe only the parts that are not in their mainboard/ dir). If somebody agrees and it turns out later that there is a commit that could benefit upstream, you can push it.
Nico
I think, while Jay's board stays upstream it is benefiting from the "universal improvements": great commits to ./payloads/ ./util/ and also to the "not-MB-specific" parts of ./src . If his board will be removed from upstream he will have to track all these improvements and "copy/paste" them to his local repo - this will result in extra maintenance on his part and significantly lower his desire to contribute. Right now it is possible that (after the discussions with his clients) Jay will contribute some great patches for us, maybe including the "universal" ones that benefit all the boards! - to compensate for us bearing with his board's not-pretty-code. On the other hand, if we will just "fork him out" I guess he will not contribute anything... So it could be beneficial to find a way to keep his board instead of removing. On Thu, Nov 29, 2018 at 12:01 AM Nico Huber nico.h@gmx.de wrote:
On 28.11.18 16:10, Jay Talbott wrote:
"Jay Talbott" jaytalbott@sysproconsulting.com writes:
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.
I looked into that FSP 1.0 integration code a little. It would seem to me that relocatable ramstage and C_ENVIRONMENT_BOOTBLOCK are possible. NO_CAR_GLOBAL_MIGRATION however seems rather impossible as the FSP has total control over the environment and destroys the CAR environment itself. Since I propose the standards I could offer some help to reach them.
It looks like FSP 1.0 will be dragging coreboot down for some time. Maybe we can agree not to integrate such monsters into coreboot in the future?
As far as I'm aware, Intel won't be developing anymore FSP 1.0 FSPs. It was all part of a learning curve on everybody's part during the early days of the FSP. At the same time, even for popular platforms, they won't be going back and respinning old FSP 1.0 FSPs as FSP 2.0 FSPs. So as long as these platforms are still popular, we will need to continue to support these platforms for a while even though they don't nicely fit into the utopian future of coreboot.
Well, support what you want to support. It doesn't have to happen upstream. I really don't understand what all the fuss is about. Apart from build tests, these platforms are effectively unmaintained. They gain nothing on the master branch unless somebody is forced to update them in any way (and when that happens, it's unlikely to get tested before the commits land). The code looks ugly, it was never really reviewed. Apart from being a disgrace for the project, I don't see what difference it makes.
Nico
-- coreboot mailing list: coreboot@coreboot.org https://mail.coreboot.org/mailman/listinfo/coreboot
Am Do., 29. Nov. 2018 um 11:59 Uhr schrieb Mike Banon mikebdp2@gmail.com:
I think, while Jay's board stays upstream it is benefiting from the "universal improvements": great commits to ./payloads/ ./util/ and also to the "not-MB-specific" parts of ./src .
And any of these changes (in particular to src) can break the board. It probably is already broken in master.
If his board will be removed from upstream he will have to track all these improvements and "copy/paste" them to his local repo - this will result in extra maintenance on his part and significantly lower his desire to contribute.
On the other hand, it is ensured that the tree he creates is working (simply because he'll test the commits he imports). I'm not a fan of that development model though. (it's the old copy&paste BIOS model that leads to stagnation).
Ideally he'd be testing master with some regularity and fix (or at least report) issues as they pop up. Arthur already started providing patches to retrofit the features he proposed should be mandatory in 6-12 months. Once these are sorted out, Jay's chipsets are off the hook!
We can easily make the support for Jay's boards in coreboot keep on building - we can't easily test that we're just carrying along non-functional bits.
That's where the "remove boards from master" movement is coming from: Truth in advertising, in that instead of claiming that we support 200 boards of which 180 were built with a tree from 3 years ago, we have a rather good idea what does. Both by taking the board-status system into account, and by dropping code paths that nobody-who's-testing uses anymore.
Right now you're just reiterating that us spending work on keeping boards in the tree is a nice service to Jay. Thanks, but we're well aware. Can you also convince us that it's a good service to the users of Jay's boards who expect master (and any future release) to work, given that there's code for boards of that specific name?
(Jay, sorry for singling you out like that)
Regards, Patrick
What we've learned over the almost 20 years of this project is that having a board in the tree that builds and fails on boot is really bad.
Keeping such broken boards in because someone has the best of intentions to "make it work when I get time" is bad policy.
Having watched this cycle of good intentions/broken boards for several years now, I'm in favor of biasing toward removing boards that have no known users.
It's git. It's all in there.
ron
From: Patrick Georgi [mailto:pgeorgi@google.com] Sent: Thursday, November 29, 2018 4:23 AM To: mikebdp2@gmail.com Cc: Nico Huber; JayTalbott@sysproconsulting.com; coreboot Subject: Re: [coreboot] Further coreboot releases, setting new standards
Am Do., 29. Nov. 2018 um 11:59 Uhr schrieb Mike Banon mikebdp2@gmail.com:
I think, while Jay's board stays upstream it is benefiting from the "universal improvements": great commits to ./payloads/ ./util/ and also to the "not-MB-specific" parts of ./src .
And any of these changes (in particular to src) can break the board. It probably is already broken in master.
I will attest that everything still builds/boots for the Broadwell-DE based Camelback Mountain Intel reference board as of release 4.8.1. However, I can't speak for the status at the current head of the master branch. For our particular current client projects that are using Broadwell-DE SoCs, we have branched off of master from 4.8.1 and have cherry picked commits from master as needed. Many customizations we have made on our branch are not suitable for the general masses since they are highly custom for this particular application, and thus are not suitable to upstream. But we may want to rebase our branch someday to be branched off of a future release, so we would like to see continued support for the Broadwell-DE SoC and the Camelback Mountain Intel reference board.
As we continue to get future business for projects that are based on Broadwell-DE, we certainly want to see ongoing support for the platform, as it's not going away anytime soon.
We are also looking at a Bay Trail coreboot project coming up this year, so it would sure be nice if the Bay Trail SoC and Bayley Bay Intel reference board both continue to be supported by coreboot.
If his board will be removed from upstream he will have to track all these improvements and "copy/paste" them to his local repo - this will result in extra maintenance on his part and significantly lower his desire to contribute.
On the other hand, it is ensured that the tree he creates is working (simply because he'll test the commits he imports). I'm not a fan of that development model though. (it's the old copy&paste BIOS model that leads to stagnation).
The Camelback Mountain Intel reference board is not "my board" per se, but an Intel board for which Intel provided the initial coreboot implementation. We use that as a baseline for porting to client boards and systems that are also based on Broadwell-DE.
Ideally he'd be testing master with some regularity and fix (or at least report) issues as they pop up.
Isn't that the responsibility of the maintainers for the Camelback Mountain Intel reference board and for the Broadwell-DE SoC?
Arthur already started providing patches to retrofit the features he proposed should be mandatory in 6-12 months.
That's not possible unless Intel creates FSP 2.0 compliant FSPs for these platforms, which I highly doubt is going to happen.
I would argue that making anything mandatory that alienates platforms that are still popular and actively being used is not the right answer here.
Once these are sorted out, Jay's chipsets are off the hook!
We can easily make the support for Jay's boards in coreboot keep on building - we can't easily test that we're just carrying along non-functional bits.
That's where the "remove boards from master" movement is coming from: Truth in advertising, in that instead of claiming that we support 200 boards of which 180 were built with a tree from 3 years ago, we have a rather good idea what does. Both by taking the board-status system into account, and by dropping code paths that nobody-who's-testing uses anymore.
I fully support removing code that nobody uses anymore - if you can ensure that nobody is actually using it. I don't support removing code for platforms that are still popular and actively being used just because you want to pretty up the codebase and make everything conformant to one individual's proposal that isn't necessarily applicable to all members of the coreboot community. Coreboot is used for a very diverse range of applications, from Chromebooks and laptops to IoT devices to banks of servers in a server farm to industrial control systems, and even to military applications. That's why I chimed into this discussion... to give a voice to those other members of the community with applications that use the platforms that would otherwise be eliminated from master per this proposal. And I know I'm not alone here.
Right now you're just reiterating that us spending work on keeping boards in the tree is a nice service to Jay. Thanks, but we're well aware. Can you also convince us that it's a good service to the users of Jay's boards who expect master (and any future release) to work, given that there's code for boards of that specific name?
First, it's more than just me. I know for a fact that we aren't the only ones developing coreboot-based solutions based on both Broadwell-DE and Bay Trail that would like to see support continued, not arbitrarily removed because it didn't conform to the proposal. So please don't belittle it down to being just a "nice service to Jay". This is much bigger than just me, my company, or our clients.
(Jay, sorry for singling you out like that)
Regards, Patrick -- Google Germany GmbH, ABC-Str. 19, 20354 Hamburg Registergericht und -nummer: Hamburg, HRB 86891, Sitz der Gesellschaft: Hamburg Geschäftsführer: Paul Manicle, Halimah DeLaine Prado
Hey guys.
I have followed the discussion now for a while in the background. It seems to be the time to step in.
For those of you who do not know me: My name is Werner Zeh and I am working for Siemens AG. I am an active coreboot developer for a few years now working on x86 systems, most of the time based on chips from Intel.
I can understand the demand to keep the tree well-shaped. And yes, from time to time we need to get rid of old, bad or not at all maintained mainboards and even chipsets. This need especially becomes more important if a deprecated code path prevents us from moving forward in the tree. I do not see this demand that urgent if the new features have no hard dependencies on removal of old code.
Speaking of the two chipsets in question in this thread I do not see the real demand of getting rid of them yet. Why is coreboot not able to move forward if we keep fsp_baytrail and fsp_broadwell_de in the tree? Sure, we cannot expect to get all the fancy new features in them, but why should these chipsets stop working? What kind of source tree refactoring can hit theses chipsets that hard?
I am (or more precise: my company is), as Jay already pointed out, one of these users of both chipsets. We do have active boards based on Broadwell-DE (mc_bdx1) and Baytrail (mc_tcu3). And this mainboards will not die that fast, we target our product availability to a range of >10 years as we are in the industry market (sure, we have hard dependencies on the chip availability).
We always have followed the policy of giving back. So every patch I do is reviewed on gerrit and gets merged once it is ready. This is the reason why you can build a working image for them on top of master. So we do not have a branch we rely on. That will be needed if the chipsets will be dropped in the future. And this will increase my effort on maintenance.
I am completely with you Ron that it is a bad idea of keeping boards in the tree which are not relay tested on hardware for a long time. And just because of this reason I have a test setup around where every of these boards it tested on real hardware several times a day with the latest master tree. This setup ensures that the mainboards can boot without issues into the OS. So the argument that the chipsets in question are not tested on real hardware is not valid now.
Don't get me wrong: If there is a need to tailor the code in order to get special features in or just for maintenance I will be glad to help. We currently are working together with Philipp on measured boot in coreboot where we maintain fsp_broadwell_de and fsp_baytrail. And I think we will continue doing so in the feature. If we some time should hit the point where a special feature cannot be ported to one of this chipsets because of the boundaries that FSP1.0 dictates I will vote for keeping the chipsets nevertheless in the tree. In the end this chips are working fine so far and I guess we can keep them working with a small effort. And I am willing to do whatever is needed to keep this chipsets in the tree...in the scope of FSP1.0 boundaries.
@Arthur: Thanks for providing the patches to implement postcar. I will test them on our mainboards next week and provide you the feedback in gerrit.
Werner
-----Ursprüngliche Nachricht----- Von: coreboot [mailto:coreboot-bounces@coreboot.org] Im Auftrag von Jay Talbott Gesendet: Freitag, 30. November 2018 01:23 An: 'Patrick Georgi'; mikebdp2@gmail.com Cc: 'coreboot' Betreff: Re: [coreboot] Further coreboot releases, setting new standards
From: Patrick Georgi [mailto:pgeorgi@google.com] Sent: Thursday, November 29, 2018 4:23 AM To: mikebdp2@gmail.com Cc: Nico Huber; JayTalbott@sysproconsulting.com; coreboot Subject: Re: [coreboot] Further coreboot releases, setting new standards
Am Do., 29. Nov. 2018 um 11:59 Uhr schrieb Mike Banon mikebdp2@gmail.com:
I think, while Jay's board stays upstream it is benefiting from the "universal improvements": great commits to ./payloads/ ./util/ and also to the "not-MB-specific" parts of ./src .
And any of these changes (in particular to src) can break the board. It probably is already broken in master.
I will attest that everything still builds/boots for the Broadwell-DE based Camelback Mountain Intel reference board as of release 4.8.1. However, I can't speak for the status at the current head of the master branch. For our particular current client projects that are using Broadwell-DE SoCs, we have branched off of master from 4.8.1 and have cherry picked commits from master as needed. Many customizations we have made on our branch are not suitable for the general masses since they are highly custom for this particular application, and thus are not suitable to upstream. But we may want to rebase our branch someday to be branched off of a future release, so we would like to see continued support for the Broadwell-DE SoC and the Camelback Mountain Intel reference board.
As we continue to get future business for projects that are based on Broadwell-DE, we certainly want to see ongoing support for the platform, as it's not going away anytime soon.
We are also looking at a Bay Trail coreboot project coming up this year, so it would sure be nice if the Bay Trail SoC and Bayley Bay Intel reference board both continue to be supported by coreboot.
If his board will be removed from upstream he will have to track all these improvements and "copy/paste" them to his local repo - this will result in extra maintenance on his part and significantly lower his desire to contribute.
On the other hand, it is ensured that the tree he creates is working (simply because he'll test the commits he imports). I'm not a fan of that development model though. (it's the old copy&paste BIOS model that leads to stagnation).
The Camelback Mountain Intel reference board is not "my board" per se, but an Intel board for which Intel provided the initial coreboot implementation. We use that as a baseline for porting to client boards and systems that are also based on Broadwell-DE.
Ideally he'd be testing master with some regularity and fix (or at least report) issues as they pop up.
Isn't that the responsibility of the maintainers for the Camelback Mountain Intel reference board and for the Broadwell-DE SoC?
Arthur already started providing patches to retrofit the features he proposed should be mandatory in 6-12 months.
That's not possible unless Intel creates FSP 2.0 compliant FSPs for these platforms, which I highly doubt is going to happen.
I would argue that making anything mandatory that alienates platforms that are still popular and actively being used is not the right answer here.
Once these are sorted out, Jay's chipsets are off the hook!
We can easily make the support for Jay's boards in coreboot keep on building - we can't easily test that we're just carrying along non-functional bits.
That's where the "remove boards from master" movement is coming from: Truth in advertising, in that instead of claiming that we support 200 boards of which 180 were built with a tree from 3 years ago, we have a
rather good idea what does.
Both by taking the board-status system into account, and by dropping code paths that nobody-who's-testing uses anymore.
I fully support removing code that nobody uses anymore - if you can ensure that nobody is actually using it. I don't support removing code for platforms that are still popular and actively being used just because you want to pretty up the codebase and make everything conformant to one individual's proposal that isn't necessarily applicable to all members of the coreboot community. Coreboot is used for a very diverse range of applications, from Chromebooks and laptops to IoT devices to banks of servers in a server farm to industrial control systems, and even to military applications. That's why I chimed into this discussion... to give a voice to those other members of the community with applications that use the platforms that would otherwise be eliminated from master per this proposal. And I know I'm not alone here.
Right now you're just reiterating that us spending work on keeping boards in the tree is a nice service to Jay. Thanks, but we're well
aware.
Can you also convince us that it's a good service to the users of Jay's boards who expect master (and any future release) to work, given that there's code for boards of that specific name?
First, it's more than just me. I know for a fact that we aren't the only ones developing coreboot-based solutions based on both Broadwell-DE and Bay Trail that would like to see support continued, not arbitrarily removed because it didn't conform to the proposal. So please don't belittle it down to being just a "nice service to Jay". This is much bigger than just me, my company, or our clients.
(Jay, sorry for singling you out like that)
Regards, Patrick -- Google Germany GmbH, ABC-Str. 19, 20354 Hamburg Registergericht und -nummer: Hamburg, HRB 86891, Sitz der Gesellschaft: Hamburg Geschäftsführer: Paul Manicle, Halimah DeLaine Prado
-- coreboot mailing list: coreboot@coreboot.org https://mail.coreboot.org/mailman/listinfo/coreboot
"Zeh, Werner" werner.zeh@siemens.com writes:
Hey guys.
I have followed the discussion now for a while in the background. It seems to be the time to step in.
For those of you who do not know me: My name is Werner Zeh and I am working for Siemens AG. I am an active coreboot developer for a few years now working on x86 systems, most of the time based on chips from Intel.
I can understand the demand to keep the tree well-shaped. And yes, from time to time we need to get rid of old, bad or not at all maintained mainboards and even chipsets.
This need especially becomes more important if a deprecated code path prevents us from moving forward in the tree. I do not see this demand that urgent if the new features have no hard dependencies on removal of old code.
I would not call the time delay of 1 year urgent. The proposed features are not that much work and have many precedent implementations, which ought to be very similar across Intel Platforms.
Speaking of the two chipsets in question in this thread I do not see the real demand of getting rid of them yet. Why is coreboot not able to move forward if we keep fsp_baytrail and fsp_broadwell_de in the tree? Sure, we cannot expect to get all the fancy new features in them, but why should these chipsets stop working? What kind of source tree refactoring can hit theses chipsets that hard?
It has never been about removal of targets, but more a call to see whether those targets are in fact maintained at all. In the post boards with LATE_CBMEM init were removed as this was set as a requirement. When this was announced many targets were modified to have EARLY_CBMEM, which indicates that someone can actually work on the code.
I am (or more precise: my company is), as Jay already pointed out, one of these users of both chipsets. We do have active boards based on Broadwell-DE (mc_bdx1) and Baytrail (mc_tcu3). And this mainboards will not die that fast, we target our product availability to a range of >10 years as we are in the industry market (sure, we have hard dependencies on the chip availability).
Having an unified bootflow is very valuable and makes maintenance of 10y old hardware in coreboot much easier. For instance 'what if' GCC12 starts compiling errors into ROMCC, which no-one will or can fix. Than you'd be much better of using a GCC compiled bootblock like proposed. Same with other old features/codeflows, at one point no one will care fixing them if they break, which will be at the loss of those platforms.
We always have followed the policy of giving back. So every patch I do is reviewed on gerrit and gets merged once it is ready. This is the reason why you can build a working image for them on top of master. So we do not have a branch we rely on. That will be needed if the chipsets will be dropped in the future. And this will increase my effort on maintenance.
Good to hear, having stuff merged in master ought to reduce maintenance or else coreboot would be in really bad shape! :p
I am completely with you Ron that it is a bad idea of keeping boards in the tree which are not relay tested on hardware for a long time.
Totally different discussion IMO. It has always been about improving coreboots codebase and never about removing this or that platform or about keeping working hardware in the three. But yes making sure stuff works with coreboot master is an issue that needs to be tackled (automated hardware testing, yes please!)
And just because of this reason I have a test setup around where every of these boards it tested on real hardware several times a day with the latest master tree. This setup ensures that the mainboards can boot without issues into the OS. So the argument that the chipsets in question are not tested on real hardware is not valid now.
Great, this should make it easy to get the desired features in.
Don't get me wrong: If there is a need to tailor the code in order to get special features in or just for maintenance I will be glad to help.
I think C_ENVIRONMENT_BOOTBLOCK might be the most work. I already posted patches for relocatable ramstage and postcar stage.
We currently are working together with Philipp on measured boot in coreboot where we maintain fsp_broadwell_de and fsp_baytrail. And I think we will continue doing so in the feature.
vboot gets a lot better with C_ENVIRONMENT_BOOTBLOCK because it allows for a separate verstage right after the bootblock. Definitely worth it investing some time into.
If we some time should hit the point where a special feature cannot be ported to one of this chipsets because of the boundaries that FSP1.0 dictates I will vote for keeping the chipsets nevertheless in the tree.
I revisited the code and I think all the proposed features should have no issue being implemented. It's just a bit sad to see that things like FSP1.0 were ever merged into coreboot, since it does require more twisting and shaping of the bootflow than any other platform. This is not mere 'internal soup', you really miss out on features like S3 resume because of it, as there seems to be no sane way of implementing it.
In the end this chips are working fine so far and I guess we can keep them working with a small effort. And I am willing to do whatever is needed to keep this chipsets in the tree...in the scope of FSP1.0 boundaries.
Great.
@Arthur: Thanks for providing the patches to implement postcar. I will test them on our mainboards next week and provide you the feedback in gerrit.
Werner
-----Ursprüngliche Nachricht----- Von: coreboot [mailto:coreboot-bounces@coreboot.org] Im Auftrag von Jay Talbott Gesendet: Freitag, 30. November 2018 01:23 An: 'Patrick Georgi'; mikebdp2@gmail.com Cc: 'coreboot' Betreff: Re: [coreboot] Further coreboot releases, setting new standards
From: Patrick Georgi [mailto:pgeorgi@google.com] Sent: Thursday, November 29, 2018 4:23 AM To: mikebdp2@gmail.com Cc: Nico Huber; JayTalbott@sysproconsulting.com; coreboot Subject: Re: [coreboot] Further coreboot releases, setting new standards
Am Do., 29. Nov. 2018 um 11:59 Uhr schrieb Mike Banon mikebdp2@gmail.com:
I think, while Jay's board stays upstream it is benefiting from the "universal improvements": great commits to ./payloads/ ./util/ and also to the "not-MB-specific" parts of ./src .
And any of these changes (in particular to src) can break the board. It probably is already broken in master.
I will attest that everything still builds/boots for the Broadwell-DE based Camelback Mountain Intel reference board as of release 4.8.1. However, I can't speak for the status at the current head of the master branch. For our particular current client projects that are using Broadwell-DE SoCs, we have branched off of master from 4.8.1 and have cherry picked commits from master as needed. Many customizations we have made on our branch are not suitable for the general masses since they are highly custom for this particular application, and thus are not suitable to upstream. But we may want to rebase our branch someday to be branched off of a future release, so we would like to see continued support for the Broadwell-DE SoC and the Camelback Mountain Intel reference board.
As we continue to get future business for projects that are based on Broadwell-DE, we certainly want to see ongoing support for the platform, as it's not going away anytime soon.
We are also looking at a Bay Trail coreboot project coming up this year, so it would sure be nice if the Bay Trail SoC and Bayley Bay Intel reference board both continue to be supported by coreboot.
If his board will be removed from upstream he will have to track all these improvements and "copy/paste" them to his local repo - this will result in extra maintenance on his part and significantly lower his desire to contribute.
On the other hand, it is ensured that the tree he creates is working (simply because he'll test the commits he imports). I'm not a fan of that development model though. (it's the old copy&paste BIOS model that leads to stagnation).
The Camelback Mountain Intel reference board is not "my board" per se, but an Intel board for which Intel provided the initial coreboot implementation. We use that as a baseline for porting to client boards and systems that are also based on Broadwell-DE.
Ideally he'd be testing master with some regularity and fix (or at least report) issues as they pop up.
Isn't that the responsibility of the maintainers for the Camelback Mountain Intel reference board and for the Broadwell-DE SoC?
Arthur already started providing patches to retrofit the features he proposed should be mandatory in 6-12 months.
That's not possible unless Intel creates FSP 2.0 compliant FSPs for these platforms, which I highly doubt is going to happen.
I would argue that making anything mandatory that alienates platforms that are still popular and actively being used is not the right answer here.
Once these are sorted out, Jay's chipsets are off the hook!
We can easily make the support for Jay's boards in coreboot keep on building - we can't easily test that we're just carrying along non-functional bits.
That's where the "remove boards from master" movement is coming from: Truth in advertising, in that instead of claiming that we support 200 boards of which 180 were built with a tree from 3 years ago, we have a
rather good idea what does.
Both by taking the board-status system into account, and by dropping code paths that nobody-who's-testing uses anymore.
I fully support removing code that nobody uses anymore - if you can ensure that nobody is actually using it. I don't support removing code for platforms that are still popular and actively being used just because you want to pretty up the codebase and make everything conformant to one individual's proposal that isn't necessarily applicable to all members of the coreboot community. Coreboot is used for a very diverse range of applications, from Chromebooks and laptops to IoT devices to banks of servers in a server farm to industrial control systems, and even to military applications. That's why I chimed into this discussion... to give a voice to those other members of the community with applications that use the platforms that would otherwise be eliminated from master per this proposal. And I know I'm not alone here.
Right now you're just reiterating that us spending work on keeping boards in the tree is a nice service to Jay. Thanks, but we're well
aware.
Can you also convince us that it's a good service to the users of Jay's boards who expect master (and any future release) to work, given that there's code for boards of that specific name?
First, it's more than just me. I know for a fact that we aren't the only ones developing coreboot-based solutions based on both Broadwell-DE and Bay Trail that would like to see support continued, not arbitrarily removed because it didn't conform to the proposal. So please don't belittle it down to being just a "nice service to Jay". This is much bigger than just me, my company, or our clients.
(Jay, sorry for singling you out like that)
Regards, Patrick -- Google Germany GmbH, ABC-Str. 19, 20354 Hamburg Registergericht und -nummer: Hamburg, HRB 86891, Sitz der Gesellschaft: Hamburg Geschäftsführer: Paul Manicle, Halimah DeLaine Prado
-- coreboot mailing list: coreboot@coreboot.org https://mail.coreboot.org/mailman/listinfo/coreboot
Hi Werner,
thanks for getting the discussion back on track :-)
Am Fr., 30. Nov. 2018 um 09:23 Uhr schrieb Zeh, Werner < werner.zeh@siemens.com>:
Speaking of the two chipsets in question in this thread I do not see the real demand of getting rid of them yet.
Why is coreboot not able to move forward if we keep fsp_baytrail and
fsp_broadwell_de in the tree? Sure, we cannot expect to get all the fancy new features in them, but why should these chipsets stop working? What kind of source tree refactoring can hit theses chipsets that hard?
First things first: Arthur proposed making a number of features mandatory so that the bootflow becomes more predictable across chipsets and boards. Mandatory features imply that chipsets or boards that can't comply to these new requirements for whatever reason will be dropped. There was no decision yet whether to make anything mandatory, and on what schedule and with what effect.
As I understand Arthur's first analysis, he considered postcar to be impossible to do with FSP 1.0 due to FSP 1.0's design. Now he's providing patches, so apparently it's not that impossible after all?
In that case, the main concern is finding people who are willing to test such changes (and more ideally: help lifting older chipsets to new standards). Theoretically, and we did that in the past, we could just review patches like Arthur's on a best effort basis and get them in because they look reasonable and pass the build test. I'm not fundamentally opposed to such a treatment for inactive code (ie. where no maintainer is known), but I'd rather not see that happen all that often going forward.
In that light I'd like to bring up our MAINTAINERS file again: It's now used to automatically add people as reviewers to patches, and it has two tiers of reviewers: "maintainers" (declared with an M: prefix) and "reviewers" (declared with an R: prefix). I encourage people who want/need to keep up to speed on chipsets to add themselves as reviewer for these subdirectories, so they're notified when significant changes are proposed to the code they rely on.
So maybe people like you and Jay want to register yourselves as reviewers to fsp_baytrail and fsp_broadwell_de, so you'll notice changes early and can test and comment on them?
I am completely with you Ron that it is a bad idea of keeping boards in the
tree which are not relay tested on hardware for a long time.
And just because of this reason I have a test setup around where every of
these boards it tested on real hardware several times a day with the latest master tree.
I guess that's approaching better coverage than 90% of the tree (unless there's another huge test operation out there that doesn't report to the public). So if we were to review changes to make these fsp 1.0 boards "somehow" postcar-capable, you'd notice shortly after we checked them in if that broke anything?
This setup ensures that the mainboards can boot without issues into the OS.
So the argument that the chipsets in question are not tested on real hardware is not valid now.
Indeed, but it's not visible.
I'll work on improving the board-status infrastructure "soon". Is publicly reporting which commits on master work on your boards something you could do, or is that off-limits for some operational reason? (not talking about any implementation details, since those are subject to change, just if there's a problem with sending coreboot and kernel logs of test machines, likely with some pruning of sensitive data, from some corporate environment to a public system).
If we some time should hit the point where a special feature cannot be
ported to one of this chipsets because of the boundaries that FSP1.0 dictates I will vote for keeping the chipsets nevertheless in the tree. In the end this chips are working fine so far and I guess we can keep them working with a small effort. And I am willing to do whatever is needed to keep this chipsets in the tree...in the scope of FSP1.0 boundaries.
"It depends". romstage is in a much better place now that we dropped the requirement that it needs to be compilable by romcc. It also left CPUs without cache-as-RAM out in the cold. I don't see anything that might require a similar drastic rework though.
Going forward, to keep everybody's blood pressure at a sensible level, maybe we should insert another escalation level before "make stuff mandatory (at the threat of dropping it)"? A call for making such adjustments on a voluntary basis, eg "We have this new way of doing things that makes stuff better/faster/securer/shinier. It's already supported on these chipsets: a, b, c. coreboot could benefit if everything moved to that. Any takers?"
Patrick
Arthur proposed making a number of features mandatory so that the bootflow becomes more predictable across chipsets and boards. Mandatory features imply that chipsets or boards that can't comply to these new requirements for whatever reason will be dropped. There was no decision yet whether to make anything mandatory, and on what schedule and with what effect.
Sure, this is exactly the way I got it. I just wanted to depict my point of view without being afraid that this will happen in the very near future.
So maybe people like you and Jay want to register yourselves as reviewers to fsp_baytrail and fsp_broadwell_de, so you'll notice changes early and can test and comment on them?
Yes, this is a really nice feature. Thank you for implementing it into gerrit Patrick! I will add myself as reviewer for both platforms.
So if we were to review changes to make these fsp 1.0 boards "somehow" postcar-capable, you'd notice shortly after we checked them in if that broke anything?
Yes that is exactly what would happen. I got a few catches in the past already with that setup. In the first glance I wanted to test even unmerged patches from gerrit but realized very soon that my system will not be able to handle this amount. So for now I trigger the test setup every 4 hours for a complete test which includes mc_tcu3, mc_bdx1 and since September even mc_apl1.
Is publicly reporting which commits on master work on your boards something you could do, or is that off-limits for some operational reason?
Yes, I have that in mind for some time already. I simply hadn't the time yet to think about a way on how to feed back this test results in detail. Though it should be possible. If you have an idea of how we can reasonable feed back this test results let me know. I can think about implementing it in the spare time (once I will get some).
Werner
-
Arthur Heymans -
Jay Talbott -
Jay Talbott
-
Mike Banon -
Nico Huber -
Nico Huber -
Patrick Georgi -
Patrick Rudolph -
Paul Menzel -
ron minnich -
Zaolin -
Zeh, Werner