[coreboot] Further coreboot releases, setting new standards

[Arthur Heymans]

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

[Arthur Heymans]

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.

[Nico Huber]

Am Fr., 23. Nov. 2018 um 16:32 Uhr schrieb Arthur Heymans <

Post by Arthur Heymans
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

[Jay Talbott]

[Paul Menzel]

Dear Jay,

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

[Jay Talbott]

Hi Paul,

-----Original Message-----
Menzel
Sent: Sunday, November 25, 2018 7:29 AM
To: Jay Talbott; Arthur Heymans; Patrick Georgi
Subject: Re: [coreboot] Further coreboot releases, setting new standards
Dear Jay,

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.

[1]: https://mail.coreboot.org/pipermail/coreboot/2018-
November/087852.html

[Mike Banon]

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,

Post by Jay Talbott
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

Post by Jay Talbott
Hi Paul,

-----Original Message-----
Menzel
Sent: Sunday, November 25, 2018 7:29 AM
To: Jay Talbott; Arthur Heymans; Patrick Georgi
Subject: Re: [coreboot] Further coreboot releases, setting new standards
Dear Jay,

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.

[1]: https://mail.coreboot.org/pipermail/coreboot/2018-
November/087852.html

--
https://mail.coreboot.org/mailman/listinfo/coreboot

[Nico Huber]

Hello Mike,

Post by Mike Banon

Post by Jay Talbott
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

[Nico Huber]

Post by Jay Talbott
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

[Zaolin]

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.

Post by Nico Huber

Post by Jay Talbott
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

[Arthur Heymans]

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
[phone]
[phone] (FAX)
http://www.sysproconsulting.com
-------- Original Message --------
Subject: Re: [coreboot] Further coreboot releases, setting new standards
Date: Fri, November 23, 2018 8:32 am

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_DE
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
--
https://mail.coreboot.org/mailman/listinfo/coreboot

[Arthur Heymans]

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

[Jay Talbott]

-----Original Message-----
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

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

[Nico Huber]

Post by Jay Talbott

Post by Arthur Heymans

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

[Mike Banon]

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.

Post by Nico Huber

Post by Jay Talbott

Post by Arthur Heymans

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
--
https://mail.coreboot.org/mailman/listinfo/coreboot

[ron minnich]

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

[Jay Talbott]

Sent: Thursday, November 29, 2018 4:23 AM
Subject: Re: [coreboot] Further coreboot releases, setting new standards

Post by Mike Banon
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.

Post by Mike Banon
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

[Nico Huber]

Post by Arthur Heymans

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.

Post by Arthur Heymans
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

[Patrick Rudolph]

Post by Arthur Heymans

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_DE
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.

Post by Arthur Heymans
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.

Post by Arthur Heymans
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

[Zeh, Werner]

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-----
Gesendet: Freitag, 30. November 2018 01:23
Cc: 'coreboot'
Betreff: Re: [coreboot] Further coreboot releases, setting new standards

Sent: Thursday, November 29, 2018 4:23 AM
Subject: Re: [coreboot] Further coreboot releases, setting new
standards

Post by Mike Banon
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.

Post by Mike Banon
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.
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

--

[Arthur Heymans]

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

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

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

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

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

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

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

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

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

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

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

-----Ursprüngliche Nachricht-----
Gesendet: Freitag, 30. November 2018 01:23
Cc: 'coreboot'
Betreff: Re: [coreboot] Further coreboot releases, setting new standards

Sent: Thursday, November 29, 2018 4:23 AM
Subject: Re: [coreboot] Further coreboot releases, setting new
standards

Post by Mike Banon
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.

Post by Mike Banon
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.
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

--

[Zeh, Werner]

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