"Zeh, Werner" werner.zeh@siemens.com writes:
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.
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.
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.
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
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!)
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.
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.
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.
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.
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.
@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@coreboot.org] Im Auftrag von Jay Talbott Gesendet: Freitag, 30. November 2018 01:23 An: 'Patrick Georgi'; mikebdp2@gmail.com Cc: 'coreboot' Betreff: Re: [coreboot] Further coreboot releases, setting new standards
From: Patrick Georgi [mailto:pgeorgi@google.com] Sent: Thursday, November 29, 2018 4:23 AM To: mikebdp2@gmail.com Cc: Nico Huber; JayTalbott@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@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@coreboot.org https://mail.coreboot.org/mailman/listinfo/coreboot