On Fri, May 4, 2018 at 3:20 PM, Youness Alaoui <kakar...@kakaroto.homelinux.net> wrote: > Hi, > > I've just pushed a commit for review on gerrit > (https://review.coreboot.org/#/c/coreboot/+/26108/) and I'm hoping to > open the discussion here on whether the public coreboot code should > have the FSP headers that match the public FSP headers or if they > should match the 'google fsp' headers. > > My understanding of the situation is that chromebooks ship with a > google-modified FSP image and the fsp headers in coreboot have been > added by google employees even before the FSP was officially made > public by Intel. I also somewhat understood that the fsp headers in > coreboot would not be updated to match the public release because it > would break everyone building coreboot for their chromebooks or > something like that.
They aren't modified necessarily. It's more of different views on the same timeline of a development. Granted, the releases are definitely not coordinated. I'm not even sure how/who releases the github blobs/headers on Intel's side. > > I'm a bit tired of always having that commit that fixes the header > applied locally in all my branches, and I think that it makes much > more sense for coreboot to have the fsp headers that match the public > release and for the google/chromebook coreboot repository to have the > "non-standard header" committed to it instead. > Worst case scenario, we could add #ifdefs to determine what the > structure contents should be depending on the target platform. > > Maybe everyone will say "of course, that makes sense" or maybe > everyone will say "nope, I disagree", but hopefully we can have the > discussion here (or on gerrit) and decide how to handle this use case. > Note: I only pushed for skylake/kabylake, but apollolake/canonlake are > probably also affected by this mismatch of headers. I think we should have both that can be selected through a Kconfig such that we can bind to the headers correctly. We already had to do that for edk2 issues as well. I can't think of better alternative at the moment that supports both. > > Thanks, > Youness. > > -- > coreboot mailing list: coreboot@coreboot.org > https://mail.coreboot.org/mailman/listinfo/coreboot -- coreboot mailing list: coreboot@coreboot.org https://mail.coreboot.org/mailman/listinfo/coreboot
