[coreboot] Further coreboot releases, setting new standards

[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.
On Thu, Nov 29, 2018 at 12:01 AM Nico Huber <nico.h at gmx.de> wrote:
>
> On 28.11.18 16:10, Jay Talbott wrote:
> >> "Jay Talbott" <jaytalbott at sysproconsulting.com> writes:
> >>> I know I don't post much here, but I feel like I need to chime in on this
> >>> thread... Perhaps it's time that SysPro becomes a louder voice in the
> >>> community.
> >>>
> >>> Bay Trail and Broadwell DE are both still very popular platforms, yet
> >>> neither one of them meets the cut for any of the three criteria. So I
> >>> caution against removing the support for either of them too hastily.
> >>>
> >>
> >> I looked into that FSP 1.0 integration code a little. It would seem to
> >> me that relocatable ramstage and C_ENVIRONMENT_BOOTBLOCK are
> >> possible.
> >> NO_CAR_GLOBAL_MIGRATION however seems rather impossible as the FSP
> >> has
> >> total control over the environment and destroys the CAR environment
> >> itself. Since I propose the standards I could offer some help to reach
> >> them.
> >>
> >> It looks like FSP 1.0 will be dragging coreboot down for some time.
> >> Maybe we can agree not to integrate such monsters into coreboot in the
> >> future?
> >
> > As far as I'm aware, Intel won't be developing anymore FSP 1.0 FSPs. It was
> > all part of a learning curve on everybody's part during the early days of
> > the FSP. At the same time, even for popular platforms, they won't be going
> > back and respinning old FSP 1.0 FSPs as FSP 2.0 FSPs. So as long as these
> > platforms are still popular, we will need to continue to support these
> > platforms for a while even though they don't nicely fit into the utopian
> > future of coreboot.
>
> Well, support what you want to support. It doesn't have to happen
> upstream. I really don't understand what all the fuss is about. Apart
> from build tests, these platforms are effectively unmaintained. They
> gain nothing on the master branch unless somebody is forced to update
> them in any way (and when that happens, it's unlikely to get tested
> before the commits land). The code looks ugly, it was never really
> reviewed. Apart from being a disgrace for the project, I don't see what
> difference it makes.
>
> Nico
>
> --
> coreboot mailing list: coreboot at coreboot.org
> https://mail.coreboot.org/mailman/listinfo/coreboot