On 26.01.20 20:15, David Hendricks wrote: > On Sat, Jan 25, 2020 at 4:44 PM Nico Huber <nic...@gmx.de> wrote: >> we've recently seen the deprecation of Intel/Broadwell-DE support >> because it turned out to be too proprietary to be maintained in the >> long run. > > To be fair, the FSP 1.0 platforms (Broadwell-DE, Baytrail, Rangeley) > had a pretty long run in master. It was only when certain important > coreboot features were introduced and plenty of warning that FSP 1.0 > needed to be deprecated that those SoCs were deemed unmaintainable in > master and moved to 4.11_branch.
Let me briefly explain why I think it wasn't deemed maintainable. There were fundamental problems with the FSP blob. Though, we could have main- tained it by either: a) Fixing it in the source code (and releasing a new binary). b) Fixing it in the binary. c) Working around the issues in coreboot. Due to the proprietary nature, a) could only have been done by Intel. b) is forbidden by Intel in the FSP license. c) didn't happen, I guess because people didn't try hard enough as they were promised a). > > Heck, even after that platforms are still being released using that > code such as the Librem Server. It's still used and maintained, just > not in the master branch. That's actually a good point, "not in the master branch". With the two new platforms that I mentioned initially (Intel/Skylake-SP, AMD/ Picasso), we (potentially, in the Picasso case) have even worse blob situations. By allowing that on the master branch, we're creating demons that guard parts of the source tree from collaboration. IMO, we have just seen one of these creating a bottleneck that was way too frustrating for three important contributors. I think we should try to prevent such friction in the future, not by trying to work around, but by avoiding the cause. Nico _______________________________________________ coreboot mailing list -- coreboot@coreboot.org To unsubscribe send an email to coreboot-le...@coreboot.org
