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