[coreboot] Further coreboot releases, setting new standards

[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-----
> Von: coreboot [mailto:coreboot-bounces at coreboot.org] Im Auftrag von Jay Talbott
> Gesendet: Freitag, 30. November 2018 01:23
> An: 'Patrick Georgi'; mikebdp2 at gmail.com
> Cc: 'coreboot'
> Betreff: Re: [coreboot] Further coreboot releases, setting new standards
> 
> > From: Patrick Georgi [mailto:pgeorgi at google.com]
> > Sent: Thursday, November 29, 2018 4:23 AM
> > To: mikebdp2 at gmail.com
> > Cc: Nico Huber; JayTalbott at sysproconsulting.com; coreboot
> > Subject: Re: [coreboot] Further coreboot releases, setting new
> > standards
> >
> > Am Do., 29. Nov. 2018 um 11:59 Uhr schrieb Mike Banon <mikebdp2 at gmail.com>:
> > > I think, while Jay's board stays upstream it is benefiting from the
> > > "universal improvements": great commits to ./payloads/ ./util/ and
> > > also to the "not-MB-specific" parts of ./src .
> > And any of these changes (in particular to src) can break the board. It probably is already broken in master.
> >
> 
> I will attest that everything still builds/boots for the Broadwell-DE based Camelback Mountain Intel reference board as of release 4.8.1.
> However, I can't speak for the status at the current head of the master branch. For our particular current client projects that are using
> Broadwell-DE SoCs, we have branched off of master from 4.8.1 and have cherry picked commits from master as needed. Many
> customizations we have made on our branch are not suitable for the general masses since they are highly custom for this particular
> application, and thus are not suitable to upstream. But we may want to rebase our branch someday to be branched off of a future release,
> so we would like to see continued support for the Broadwell-DE SoC and the Camelback Mountain Intel reference board.
> 
> As we continue to get future business for projects that are based on Broadwell-DE, we certainly want to see ongoing support for the
> platform, as it's not going away anytime soon.
> 
> We are also looking at a Bay Trail coreboot project coming up this year, so it would sure be nice if the Bay Trail SoC and Bayley Bay Intel
> reference board both continue to be supported by coreboot.
> 
> > > If his board will be
> > > removed from upstream he will have to track all these improvements
> > > and "copy/paste" them to his local repo - this will result in extra
> > > maintenance on his part and significantly lower his desire to
> > > contribute.
> > On the other hand, it is ensured that the tree he creates is working (simply because he'll test the commits he imports).
> > I'm not a fan of that development model though. (it's the old copy&paste BIOS model that leads to stagnation).
> >
> 
> The Camelback Mountain Intel reference board is not "my board" per se, but an Intel board for which Intel provided the initial coreboot
> implementation. We use that as a baseline for porting to client boards and systems that are also based on Broadwell-DE.
> 
> >
> > Ideally he'd be testing master with some regularity and fix (or at least report) issues as they pop up.
> 
> Isn't that the responsibility of the maintainers for the Camelback Mountain Intel reference board and for the Broadwell-DE SoC?
> 
> > Arthur already started providing patches to retrofit the features he proposed should be mandatory in 6-12 months.
> 
> That's not possible unless Intel creates FSP 2.0 compliant FSPs for these platforms, which I highly doubt is going to happen.
> 
> I would argue that making anything mandatory that alienates platforms that are still popular and actively being used is not the right answer
> here.
> 
> > Once these are sorted out, Jay's chipsets are off the hook!
> >
> > We can easily make the support for Jay's boards in coreboot keep on
> > building - we can't easily test that we're just carrying along non-functional bits.
> >
> > That's where the "remove boards from master" movement is coming from:
> > Truth in advertising, in that instead of claiming that we support 200 boards of which 180 were built with a tree from 3 years ago, we have a
> rather good idea what does.
> > Both by taking the board-status system into account, and by dropping code paths that nobody-who's-testing uses anymore.
> >
> 
> I fully support removing code that nobody uses anymore - if you can ensure that nobody is actually using it. I don't support removing code
> for platforms that are still popular and actively being used just because you want to pretty up the codebase and make everything
> conformant to one individual's proposal that isn't necessarily applicable to all members of the coreboot community. Coreboot is used for a
> very diverse range of applications, from Chromebooks and laptops to IoT devices to banks of servers in a server farm to industrial control
> systems, and even to military applications. That's why I chimed into this discussion... to give a voice to those other members of the
> community with applications that use the platforms that would otherwise be eliminated from master per this proposal. And I know I'm not
> alone here.
> 
> > Right now you're just reiterating that us spending work on keeping boards in the tree is a nice service to Jay. Thanks, but we're well
> aware.
> > Can you also convince us that it's a good service to the users of
> > Jay's boards who expect master (and any future release) to work, given that there's code for boards of that specific name?
> >
> 
> First, it's more than just me. I know for a fact that we aren't the only ones developing coreboot-based solutions based on both Broadwell-DE
> and Bay Trail that would like to see support continued, not arbitrarily removed because it didn't conform to the proposal. So please don't
> belittle it down to being just a "nice service to Jay". This is much bigger than just me, my company, or our clients.
> 
> >
> > (Jay, sorry for singling you out like that)
> >
> > Regards,
> > Patrick
> > --
> > Google Germany GmbH, ABC-Str. 19, 20354 Hamburg Registergericht und
> > -nummer: Hamburg, HRB 86891, Sitz der Gesellschaft: Hamburg
> > Geschäftsführer: Paul Manicle, Halimah DeLaine Prado
> 
> 
> --
> coreboot mailing list: coreboot at coreboot.org https://mail.coreboot.org/mailman/listinfo/coreboot