While the next coreboot release is due for november 2018, I think itis worthwhile to think about further releases and standards we want toset.

In the past coreboot adapted numerous general improvements, which were notalways ported to all coreboot targets. Keeping those platforms and theirrespective codepath then typically becomes a burden often accompaniedwith regressions. The reasonable decision to drop these targets was thenmade. A few examples of this were dropping targets that had a romcccompiled romstage (in favor of GCC compiled romstage running in Cache AsRam) and dropping targets without early_cbmem.

Coreboot hasn't stood still and it might be time to set some newstandards 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 ofthe 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 x86targets have a common way to set up and get rid of the CAR environmentand car globals.

- config C_ENVIRONMENT_BOOTBLOCK on all x86 targets

This means that the bootblock is responsible to set up the CAR, whichmeans 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 increasesthe bootflow flexibility. This is reflected in for instance when usingVBOOT, 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 importantstep in making vboot useful and usable and maybe default on all targets.

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/agesacpu/amd/pimainboard/intel/galileonorthbridge/intel/i440bxnorthbridge/intel/i945northbridge/intel/e7505northbridge/intel/gm45northbridge/intel/haswellnorthbridge/intel/nehalemnorthbridge/intel/pineviewnorthbridge/intel/sandybridgenorthbridge/intel/sandybridgenorthbridge/intel/x4xsoc/amd/stoneyridgesoc/intel/apollolakesoc/intel/cannonlakesoc/intel/denverton_nssoc/intel/skylakesoc/intel/icelakeso all other x86 targets don't implement it and therefore lackNO_CAR_GLOBAL_MIGRATION.

C_ENVIRONMENT_BOOTBLOCK is even less used since it is a relatively newfeature (was introduced with INTEL_APOLLOLAKE and INTEL_SKYLAKE) so mostx86 targets don't implement it but there are already many patches for it lyingaround for review (like most targets in northbridge/intel/*). It ishowever a very useful feature to have.

So it would seem reasonable to drop NO_RELOCATABLE_RAMSTAGE in may 2019and mandate NO_CAR_GLOBAL_MIGRATION and C_ENVIRONMENT_BOOTBLOCK innovember 2019? Any thoughts on this?

Nico also suggested to set the timeframe 2 weeks before the release, toavoid last minute WIP patches attempting to tackle the issue rightbefore the release.

Post by Arthur HeymansNico also suggested to set the timeframe 2 weeks before the release, toavoid last minute WIP patches attempting to tackle the issue rightbefore 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 boarddoesn't have the required features after a release, it should be removedunless there is a review ongoing that started earlier than two weeksbefore the release (i.e. the patches had a real chance to get in).

Background: A year ago (iirc), somebody was working on patches aroundthe release and didn't want the affected board(s) removed even it wastoo 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 wantthat to happen again, but also don't want to remove boards that have apatch that wasn't reviewed yet (e.g. because nobody had the time).

I know I don't post much here, but I feel like I need to chime in onthis thread... Perhaps it's time that SysPro becomes a louder voicein the community.Bay Trail and Broadwell DE are both still very popular platforms, yetneither one of them meets the cut for any of the three criteria. So Icaution against removing the support for either of them too hastily.

Itâd be nice if you gave a little bit more background, what yourcompany 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, andcertainly support for platforms that are old enough that they are nolonger being used by anybody are good candidates for cleanup andremoval. But support for platforms that are still popular and stillactively being used by people shouldn't be stripped out of thecoreboot code base.

How should coreboot upstream know, what is popular or not? So itâs goodthat you engage with the community.

On the other hand, you didnât answer any of the issues raised byArthur, that maintaining outdated chipsets and boards puts the burdenon â often freetime â developers.

How can SysPro help here improve the boards and implement the thingsArthur raised? Itâd be nice to have SysPro as a more active member ofthe coreboot community by contributing code, documentation, or money.

If that is not possible, please answer, what the problem would be foryou to just use the current code from a separate branch.

PPS: Please also at least send a plain text part. A lot of peopleprefer to look at that, and it also works better with the mailing listarchive. (Iâd even prefer to not get any HTML stuff at all. The LinuxKernel Mailing List even rejects such messages.)

I know I don't post much here, but I feel like I need to chime in onthis thread... Perhaps it's time that SysPro becomes a louder voicein the community.Bay Trail and Broadwell DE are both still very popular platforms, yetneither one of them meets the cut for any of the three criteria. So Icaution against removing the support for either of them too hastily.

It’d be nice if you gave a little bit more background, what yourcompany 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, andcertainly support for platforms that are old enough that they are nolonger being used by anybody are good candidates for cleanup andremoval. But support for platforms that are still popular and stillactively being used by people shouldn't be stripped out of thecoreboot code base.

How should coreboot upstream know, what is popular or not? So it’s goodthat 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 byArthur, that maintaining outdated chipsets and boards puts the burdenon – 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 thingsArthur raised? It’d be nice to have SysPro as a more active member ofthe 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 foryou 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.

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 peopleprefer to look at that, and it also works better with the mailing listarchive. (I’d even prefer to not get any HTML stuff at all. The LinuxKernel Mailing List even rejects such messages.)

I strongly agree with you that no currently-used-boards should bedropped from coreboot, because even a person who is "just a user"could become a contributor eventually, and it would have been reallyfoolish to artificially reduce the userbase/coderbase by "forking out"the people... However,

Post by Jay TalbottAs 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 chooseto 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 somecommercial closed-source proprietary license, and you will not bebreaking this GPLv2 license by contributing your patches even thoughthey have been created by the request of your clients. If you areproviding the coreboot consulting to your clients, it is quite likelythat they don't know much about coreboot (at least compared to you)and would not be able to contribute the patches in the mergeablequality even if they wanted, so you shouldn't rely on them here.

It would be really nice if you could look through your patches andcontribute at least those which are "not motherboard-specific". If youwould start giving back more than you are currently, there would besmaller chance of your boards dropped. And your clients shouldunderstand that, although no client's approval is required tocontribute these patches for GPLv2 open source software

I know I don't post much here, but I feel like I need to chime in onthis thread... Perhaps it's time that SysPro becomes a louder voicein the community.Bay Trail and Broadwell DE are both still very popular platforms, yetneither one of them meets the cut for any of the three criteria. So Icaution against removing the support for either of them too hastily.

It’d be nice if you gave a little bit more background, what yourcompany 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, andcertainly support for platforms that are old enough that they are nolonger being used by anybody are good candidates for cleanup andremoval. But support for platforms that are still popular and stillactively being used by people shouldn't be stripped out of thecoreboot code base.

How should coreboot upstream know, what is popular or not? So it’s goodthat 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 byArthur, that maintaining outdated chipsets and boards puts the burdenon – 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 thingsArthur raised? It’d be nice to have SysPro as a more active member ofthe 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 foryou 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.

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 peopleprefer to look at that, and it also works better with the mailing listarchive. (I’d even prefer to not get any HTML stuff at all. The LinuxKernel Mailing List even rejects such messages.)

Post by Jay TalbottAs a pure consulting service, the ports and customizations that we havemade to coreboot to support our clients' hardware (including the workdone for Intel) is turned over to the client at the end of each projectto do with as they please. If they choose to upstream it or not tocoreboot.org is really up to them, and if they do, it would getupstreamed by them, not by us, since they then own the code. <--- ???

Almost all the coreboot source code is GPLv2 licensed, not somecommercial closed-source proprietary license, and you will not bebreaking this GPLv2 license by contributing your patches even thoughthey 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 thatdoesn't change the way licenses work. If you want to change that, goout on the street, protest against copyright.

Post by Jay TalbottAlthough I have participated in a number of reviews of coreboot patches,I/we have not directly upstreamed any patches to coreboot.org. As a pureconsulting service, the ports and customizations that we have made tocoreboot to support our clients' hardware (including the work done forIntel) is turned over to the client at the end of each project to dowith as they please. If they choose to upstream it or not tocoreboot.org is really up to them, and if they do, it would getupstreamed 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 codeunder 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 committhat could benefit upstream, you can push it.

Post by Jay TalbottAlthough I have participated in a number of reviews of coreboot patches,I/we have not directly upstreamed any patches to coreboot.org. As a pureconsulting service, the ports and customizations that we have made tocoreboot to support our clients' hardware (including the work done forIntel) is turned over to the client at the end of each project to dowith as they please. If they choose to upstream it or not tocoreboot.org is really up to them, and if they do, it would getupstreamed 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 codeunder 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 committhat could benefit upstream, you can push it.Nico

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, yetneither one of them meets the cut for any of the three criteria. So Icaution 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 andremoval.

It's not about old or new. For instance the Intel i440bx (20y old) is stillsupported by coreboot, uses many recent features like POSTCAR_STAGE andrelocatable 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 someonehas interest towards achieving new coreboot standards? Pushing standardsis not really about active use or not but about improving the code base.

In which time frame? The next release, ie May 2019? In two releases,November 2019?

That is indeed worthy item of discussion.NORTHBRIDGE_AMD_AMDFAM10,NORTHBRIDGE_AMD_LX,NORTHBRIDGE_VIA_VX900,SOC_INTEL_FSP_BAYTRAIL,SOC_INTEL_FSP_BROADWELL_DEcpu/amd/agesacpu/amd/pimainboard/intel/galileonorthbridge/intel/i440bxnorthbridge/intel/i945northbridge/intel/e7505northbridge/intel/gm45northbridge/intel/haswellnorthbridge/intel/nehalemnorthbridge/intel/pineviewnorthbridge/intel/sandybridgenorthbridge/intel/sandybridgenorthbridge/intel/x4xsoc/amd/stoneyridgesoc/intel/apollolakesoc/intel/cannonlakesoc/intel/denverton_nssoc/intel/skylakesoc/intel/icelakeso all other x86 targets don't implement it and therefore lackNO_CAR_GLOBAL_MIGRATION.C_ENVIRONMENT_BOOTBLOCK is even less used since it is a relatively newfeature (was introduced with INTEL_APOLLOLAKE and INTEL_SKYLAKE) so mostx86 targets don't implement it but there are already many patches for it lyingaround for review (like most targets in northbridge/intel/*). It ishowever a very useful feature to have.So it would seem reasonable to drop NO_RELOCATABLE_RAMSTAGE in may 2019and mandate NO_CAR_GLOBAL_MIGRATION and C_ENVIRONMENT_BOOTBLOCK innovember 2019? Any thoughts on this?Nico also suggested to set the timeframe 2 weeks before the release, toavoid last minute WIP patches attempting to tackle the issue rightbefore the release.--==============Arthur Heymans--https://mail.coreboot.org/mailman/listinfo/coreboot

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 tome that relocatable ramstage and C_ENVIRONMENT_BOOTBLOCK are possible.NO_CAR_GLOBAL_MIGRATION however seems rather impossible as the FSP hastotal control over the environment and destroys the CAR environmentitself. Since I propose the standards I could offer some help to reachthem.

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.

thread... Perhaps it's time that SysPro becomes a louder voice in thecommunity.

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 tome that relocatable ramstage and C_ENVIRONMENT_BOOTBLOCK arepossible.NO_CAR_GLOBAL_MIGRATION however seems rather impossible as the FSP hastotal control over the environment and destroys the CAR environmentitself. Since I propose the standards I could offer some help to reachthem.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 wasall part of a learning curve on everybody's part during the early days ofthe FSP. At the same time, even for popular platforms, they won't be goingback and respinning old FSP 1.0 FSPs as FSP 2.0 FSPs. So as long as theseplatforms are still popular, we will need to continue to support theseplatforms for a while even though they don't nicely fit into the utopianfuture of coreboot.

BTW baytrail has a non FSP port that will likely be in better shape.Kind regardsArthur Heymans

I know I don't post much here, but I feel like I need to chime in on thisthread... Perhaps it's time that SysPro becomes a louder voice in thecommunity.Bay Trail and Broadwell DE are both still very popular platforms, yetneither one of them meets the cut for any of the three criteria. So Icaution against removing the support for either of them too hastily.

I looked into that FSP 1.0 integration code a little. It would seem tome that relocatable ramstage and C_ENVIRONMENT_BOOTBLOCK arepossible.NO_CAR_GLOBAL_MIGRATION however seems rather impossible as the FSP hastotal control over the environment and destroys the CAR environmentitself. Since I propose the standards I could offer some help to reachthem.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 wasall part of a learning curve on everybody's part during the early days ofthe FSP. At the same time, even for popular platforms, they won't be goingback and respinning old FSP 1.0 FSPs as FSP 2.0 FSPs. So as long as theseplatforms are still popular, we will need to continue to support theseplatforms for a while even though they don't nicely fit into the utopianfuture of coreboot.

Well, support what you want to support. It doesn't have to happenupstream. I really don't understand what all the fuss is about. Apartfrom build tests, these platforms are effectively unmaintained. Theygain nothing on the master branch unless somebody is forced to updatethem in any way (and when that happens, it's unlikely to get testedbefore the commits land). The code looks ugly, it was never reallyreviewed. Apart from being a disgrace for the project, I don't see whatdifference it makes.

I think, while Jay's board stays upstream it is benefiting from the"universal improvements": great commits to ./payloads/ ./util/ andalso to the "not-MB-specific" parts of ./src . If his board will beremoved from upstream he will have to track all these improvements and"copy/paste" them to his local repo - this will result in extramaintenance on his part and significantly lower his desire tocontribute. Right now it is possible that (after the discussions withhis clients) Jay will contribute some great patches for us, maybeincluding the "universal" ones that benefit all the boards! - tocompensate for us bearing with his board's not-pretty-code. On theother hand, if we will just "fork him out" I guess he will notcontribute anything... So it could be beneficial to find a way to keephis board instead of removing.

I know I don't post much here, but I feel like I need to chime in on thisthread... Perhaps it's time that SysPro becomes a louder voice in thecommunity.Bay Trail and Broadwell DE are both still very popular platforms, yetneither one of them meets the cut for any of the three criteria. So Icaution against removing the support for either of them too hastily.

I looked into that FSP 1.0 integration code a little. It would seem tome that relocatable ramstage and C_ENVIRONMENT_BOOTBLOCK are possible.NO_CAR_GLOBAL_MIGRATION however seems rather impossible as the FSP hastotal control over the environment and destroys the CAR environmentitself. Since I propose the standards I could offer some help to reachthem.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 wasall part of a learning curve on everybody's part during the early days ofthe FSP. At the same time, even for popular platforms, they won't be goingback and respinning old FSP 1.0 FSPs as FSP 2.0 FSPs. So as long as theseplatforms are still popular, we will need to continue to support theseplatforms for a while even though they don't nicely fit into the utopianfuture of coreboot.

Well, support what you want to support. It doesn't have to happenupstream. I really don't understand what all the fuss is about. Apartfrom build tests, these platforms are effectively unmaintained. Theygain nothing on the master branch unless somebody is forced to updatethem in any way (and when that happens, it's unlikely to get testedbefore the commits land). The code looks ugly, it was never reallyreviewed. Apart from being a disgrace for the project, I don't see whatdifference it makes.Nico--https://mail.coreboot.org/mailman/listinfo/coreboot

Post by Mike BanonI think, while Jay's board stays upstream it is benefiting from the"universal improvements": great commits to ./payloads/ ./util/ andalso 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.

Post by Mike BanonIf his board will beremoved from upstream he will have to track all these improvements and"copy/paste" them to his local repo - this will result in extramaintenance on his part and significantly lower his desire tocontribute.

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-functionalbits.That's where the "remove boards from master" movement is coming from: Truth in advertising, in that instead of claiming that we support 200boards 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 thatthere'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.

I know I don't post much here, but I feel like I need to chime in on thisthread... Perhaps it's time that SysPro becomes a louder voice in thecommunity.Bay Trail and Broadwell DE are both still very popular platforms, yetneither one of them meets the cut for any of the three criteria. So Icaution against removing the support for either of them too hastily.

I looked into that FSP 1.0 integration code a little. It would seem tome that relocatable ramstage and C_ENVIRONMENT_BOOTBLOCK are possible.NO_CAR_GLOBAL_MIGRATION however seems rather impossible as the FSP hastotal control over the environment and destroys the CAR environmentitself. Since I propose the standards I could offer some help to reachthem.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 justdo what we always did with incompatible binaries, cage them. Would be anice exercise for those that think FSP 1.0 needs to be maintained up-stream.

Post by Arthur HeymansMaybe we can agree not to integrate such monsters into coreboot in thefuture? BTW baytrail has a non FSP port that will likely be in bettershape.

In which time frame? The next release, ie May 2019? In two releases,November 2019?

That is indeed worthy item of discussion.NORTHBRIDGE_AMD_AMDFAM10,NORTHBRIDGE_AMD_LX,NORTHBRIDGE_VIA_VX900,SOC_INTEL_FSP_BAYTRAIL,SOC_INTEL_FSP_BROADWELL_DEcpu/amd/agesacpu/amd/pimainboard/intel/galileonorthbridge/intel/i440bxnorthbridge/intel/i945northbridge/intel/e7505northbridge/intel/gm45northbridge/intel/haswellnorthbridge/intel/nehalemnorthbridge/intel/pineviewnorthbridge/intel/sandybridgenorthbridge/intel/sandybridgenorthbridge/intel/x4xsoc/amd/stoneyridgesoc/intel/apollolakesoc/intel/cannonlakesoc/intel/denverton_nssoc/intel/skylakesoc/intel/icelakeso all other x86 targets don't implement it and therefore lackNO_CAR_GLOBAL_MIGRATION.

Not sure what to do here. I haven't looked at it and there's nodocumentation.

Post by Arthur HeymansC_ENVIRONMENT_BOOTBLOCK is even less used since it is a relatively newfeature (was introduced with INTEL_APOLLOLAKE and INTEL_SKYLAKE) so mostx86 targets don't implement it but there are already many patches for it lyingaround for review (like most targets in northbridge/intel/*). It ishowever a very useful feature to have.So it would seem reasonable to drop NO_RELOCATABLE_RAMSTAGE in may 2019and mandate NO_CAR_GLOBAL_MIGRATION and C_ENVIRONMENT_BOOTBLOCK innovember 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 ormoney if everybody has been properly warned.

Post by Arthur HeymansNico also suggested to set the timeframe 2 weeks before the release, toavoid last minute WIP patches attempting to tackle the issue rightbefore the release.--==============Arthur Heymans

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.

Post by Mike BanonI think, while Jay's board stays upstream it is benefiting from the"universal improvements": great commits to ./payloads/ ./util/ andalso 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 usingBroadwell-DE SoCs, we have branched off of master from 4.8.1 and have cherry picked commits from master as needed. Manycustomizations we have made on our branch are not suitable for the general masses since they are highly custom for this particularapplication, 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 theplatform, 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 Intelreference board both continue to be supported by coreboot.

Post by Mike BanonIf his board will beremoved from upstream he will have to track all these improvementsand "copy/paste" them to his local repo - this will result in extramaintenance on his part and significantly lower his desire tocontribute.

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 corebootimplementation. 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 answerhere.

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 onbuilding - we can't easily test that we're just carrying along non-functional bits.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 codefor platforms that are still popular and actively being used just because you want to pretty up the codebase and make everythingconformant to one individual's proposal that isn't necessarily applicable to all members of the coreboot community. Coreboot is used for avery diverse range of applications, from Chromebooks and laptops to IoT devices to banks of servers in a server farm to industrial controlsystems, and even to military applications. That's why I chimed into this discussion... to give a voice to those other members of thecommunity with applications that use the platforms that would otherwise be eliminated from master per this proposal. And I know I'm notalone 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 ofJay'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-DEand Bay Trail that would like to see support continued, not arbitrarily removed because it didn't conform to the proposal. So please don'tbelittle it down to being just a "nice service to Jay". This is much bigger than just me, my company, or our clients.

Post by Zeh, WernerHey 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 totime we need to get rid of old, bad or not at all maintained mainboards and evenchipsets.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 featuresare not that much work and have many precedent implementations, whichought to be very similar across Intel Platforms.

Post by Zeh, WernerSpeaking 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 shouldthese chipsets stop working? What kind of source tree refactoring can hit theseschipsets that hard?

It has never been about removal of targets, but more a call to seewhether those targets are in fact maintained at all. In the post boardswith LATE_CBMEM init were removed as this was set as a requirement. Whenthis was announced many targets were modified to have EARLY_CBMEM, whichindicates that someone can actually work on the code.

Post by Zeh, WernerI am (or more precise: my company is), as Jay already pointed out, one of theseusers 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 availabilityto a range of >10 years as we are in the industry market (sure, we have harddependencies on the chip availability).

Having an unified bootflow is very valuable and makes maintenance of 10yold hardware in coreboot much easier. For instance 'what if' GCC12 startscompiling errors into ROMCC, which no-one will or can fix. Than you'd be muchbetter of using a GCC compiled bootblock like proposed. Same with otherold features/codeflows, at one point no one will care fixing them if they break,which will be at the loss of those platforms.

Post by Zeh, WernerWe always have followed the policy of giving back. So every patch I do isreviewed on gerrit and gets merged once it is ready. This is the reason why youcan 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 maintenanceor else coreboot would be in really bad shape! :p

Post by Zeh, WernerI am completely with you Ron that it is a bad idea of keeping boardsin the tree which are not relay tested on hardware for a long time.

Totally different discussion IMO. It has always been about improvingcoreboots codebase and never about removing this or that platform or aboutkeeping working hardware in the three.But yes making sure stuff works with coreboot master is an issue thatneeds to be tackled (automated hardware testing, yes please!)

Post by Zeh, WernerAnd just because of this reason I have a test setup around where everyof these boards it tested on real hardware several times a day withthe latest master tree.This setup ensures that the mainboards can boot without issues into the OS. Sothe argument that the chipsets in question are not tested on real hardware isnot valid now.

Great, this should make it easy to get the desired features in.

Post by Zeh, WernerDon't get me wrong: If there is a need to tailor the code in order toget special features in or just for maintenance I will be glad tohelp.

I think C_ENVIRONMENT_BOOTBLOCK might be the most work. I already postedpatches for relocatable ramstage and postcar stage.

Post by Zeh, WernerWe currently are working together with Philipp on measured boot in corebootwhere we maintain fsp_broadwell_de and fsp_baytrail. And I think we willcontinue doing so in the feature.

vboot gets a lot better with C_ENVIRONMENT_BOOTBLOCK because it allowsfor a separate verstage right after the bootblock. Definitely worth itinvesting some time into.

Post by Zeh, WernerIf we some time should hit the point where a special feature cannot be ported toone of this chipsets because of the boundaries that FSP1.0 dictates I will votefor keeping the chipsets nevertheless in the tree.

I revisited the code and I think all the proposed features should haveno issue being implemented. It's just a bit sad to see that things likeFSP1.0 were ever merged into coreboot, since it does require moretwisting and shaping of the bootflow than any other platform. This isnot mere 'internal soup', you really miss out on features like S3 resumebecause of it, as there seems to be no sane way of implementing it.

Post by Zeh, WernerIn the end this chips are working fine so far and I guess we can keep themworking with a small effort. And I am willing to do whatever is needed to keepthis chipsets in the tree...in the scope of FSP1.0 boundaries.

Great.

Post by Zeh, Werner@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

Post by Mike BanonI think, while Jay's board stays upstream it is benefiting from the"universal improvements": great commits to ./payloads/ ./util/ andalso 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 usingBroadwell-DE SoCs, we have branched off of master from 4.8.1 and have cherry picked commits from master as needed. Manycustomizations we have made on our branch are not suitable for the general masses since they are highly custom for this particularapplication, 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 theplatform, 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 Intelreference board both continue to be supported by coreboot.

Post by Mike BanonIf his board will beremoved from upstream he will have to track all these improvementsand "copy/paste" them to his local repo - this will result in extramaintenance on his part and significantly lower his desire tocontribute.

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 corebootimplementation. 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 answerhere.

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 onbuilding - we can't easily test that we're just carrying along non-functional bits.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 codefor platforms that are still popular and actively being used just because you want to pretty up the codebase and make everythingconformant to one individual's proposal that isn't necessarily applicable to all members of the coreboot community. Coreboot is used for avery diverse range of applications, from Chromebooks and laptops to IoT devices to banks of servers in a server farm to industrial controlsystems, and even to military applications. That's why I chimed into this discussion... to give a voice to those other members of thecommunity with applications that use the platforms that would otherwise be eliminated from master per this proposal. And I know I'm notalone 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 ofJay'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-DEand Bay Trail that would like to see support continued, not arbitrarily removed because it didn't conform to the proposal. So please don'tbelittle it down to being just a "nice service to Jay". This is much bigger than just me, my company, or our clients.

Arthur proposed making a number of features mandatory so that the bootflow becomes morepredictable across chipsets and boards. Mandatory features imply that chipsets or boards thatcan't comply to these new requirements for whatever reason will be dropped. There was nodecision 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 afraidthat this will happen in the very near future.

So maybe people like you and Jay want to register yourselves as reviewers to fsp_baytrail andfsp_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 thatmy system will not be able to handle this amount. So for now I trigger the test setup every 4 hoursfor 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 wayon 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 testresults let me know. I can think about implementing it in the spare time (once I will get some).