[coreboot] Further coreboot releases, setting new standards

[Jay Talbott]

> 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