I thought FSP 1.1 was for skylake and FSP 2.0 for Kabylake, I didn't realize 2.0 would be compatible with skylake too. Does this mean a skylake port could use fsp 1.1 or 2.0 ? In that case, is the 2.0 version better maintained, more stable, easier to integrate, etc.. or are both 1.1 and 2.0 implementations equivalent at this point? I also don't see the 2.0 release in https://github.com/IntelFsp/FSP/ so I assume getting my hands on it would mean grabbing it from somewhere else....
Thanks, Youness. On Tue, May 9, 2017 at 11:19 AM, Aaron Durbin <[email protected]> wrote: > On Tue, May 9, 2017 at 10:14 AM, Nico Huber <[email protected]> > wrote: > > Hi, > > > > I was walking through the Skylake FSP1.1 support in coreboot and asked > > myself if it is worth to clean it up and maintain the code? given that > > the upcoming release of Kabylake FSP should be able to supersede it (I > > presume it is?). Are there any plans yet to drop it once the next FSP > > is released? (when will that be anyway?) > > I wanted to get rid of it, but Intel claimed they had customers using it > still. > > > > > Btw. does anybody feel like a maintainer for soc/intel/skylake/? > > Personally feel? Or want? > > > > > In it's current state it's very hard to use from a mainboard porter's > > point of view. Many of the selectable Kconfig settings are useless > > (either don't compile or don't run) for FSP1.1, and there's a `struct > > pei_data` [1] that seems to be a remnant of compatibility for a dif- > > ferent blob ;) > > That's just an old remnant of passing data around. It could be removed > as you annotated isolating those pieces to different structs and/or > variables for passing data around. The name is obviously not > applicable w.r.t. its current use. > > > > > Best regards, > > Nico > > > > PS. Microcode updates are also missing in the upstream blobs repo. Is > > that a licensing problem? If I try to download them from Intel, it > > asks me to click to accept that I'll prevent further distribution. > > I could prepare a patch to add them but somebody else would have > > to sign it off. > > > > [1] https://review.coreboot.org/#/c/19638/ > > >
-- coreboot mailing list: [email protected] https://mail.coreboot.org/mailman/listinfo/coreboot
