I am shipping a product based on Broadwell-DE and FSP 1.0. It’s very disappointing to have to rely on binary blobs and I wish I could do better, but I’d rather ship with coreboot than proprietary UEFI.
I expected to upstream my code at some point but if FSP 1.0 support is being deprecated I can live with the code as it is today. I have 8-core systems working but there are bugs that keep us from shipping the 12 and 16 core systems. I will probably be having a consultant with a FSP source license help us when we want to ship those systems. I would love to develop open alternatives, but don’t have the tools (hardware JTAG debugger, etc) to pull it off. I’m a lot more comfortable on ARM, MIPS, PowerPC, where there are available hardware debuggers. x86 is a painful mystery to me. We are too early stage in my company to fund others to do this development as well. Kevin > On Jan 26, 2020, at 14:23, Nico Huber <[email protected]> wrote: > > On 26.01.20 20:36, Martin Roth wrote: >> While it's not my preference, I'm fine with pulling picasso out of the >> tree and doing the development in private if that's the community >> desire. When we're done, it can go in, or not, as the coreboot >> community chooses. Because we can't boot what's in coreboot >> currently, we're being forced to develop the platforms in private >> anyway. > > I know, there is a lot discussion about Picasso going on in private for > reasons you can't control. But is it possible to give us an update on > the binary situation? So far, what I could grasp is that it might end > up being a Chromebook only solution? > > Nico > _______________________________________________ > coreboot mailing list -- [email protected] > To unsubscribe send an email to [email protected] _______________________________________________ coreboot mailing list -- [email protected] To unsubscribe send an email to [email protected]
