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@gmx.de wrote:
On 28.11.18 16:10, Jay Talbott wrote:
"Jay Talbott" jaytalbott@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@coreboot.org https://mail.coreboot.org/mailman/listinfo/coreboot