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 nico.h@gmx.de 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 -- coreboot@coreboot.org To unsubscribe send an email to coreboot-leave@coreboot.org