Doesn't linuxboot
also require the FSP blob for memory and silicon initialization on any Intel board after Ivy Bridge?
No. On x86 we do assume UEFI, however. That's a safe assumption. From what I've seen, working with UEFI, as we do in LinuxBoot, is far easier than dealing with FSP, ironically. That's partly because we remove at last 75% of the UEFI image so we can replace it with Linux. Once you get rid of most of UEFI it's a lot more manageable.
This is how easy it is: build a linux kernel with UEFI stub support, run the simple command to create an FFS from it, put it in the firmware volume using UEFI tool, done. The DXEcore will eventually find that Linux and run it.
We have done this in as little as one day with two new servers. Several companies are working on tools written in Go to build an automated pipeline. Obviously, we want to remove as much UEFI as possible, but even the manual procedure outlined above is good enough for many companies.
There are tens of thousands of servers being sold this month that use LinuxBoot. There were zero a year ago. Back in the 2000s, we were happy to find out that over a period of 5 years, 100,000 linuxbios-based server systems had been sold. That number will be equalled and exceeded in the next few months with linuxboot nodes.
We just had a meeting yesterday with a server company that had tried and failed a coreboot port; it was just more than they could handle, they got no vendor support (surprise!), and it was going to have FSP anyway, hence no power-on/reset control in the end. They're going to give linuxboot a try.
Things are changing. My hope has always been to own the first instruction after power-on/reset. That's not going to happen in most x86 futures: x86 vendors have worked hard to ensure that you can't get control at POR any more. If you're going to do binary blobs, I've begun to think linuxboot makes the most sense for most scenarios.
What's the right architecture for full control? My RISC-V hopes are in tatters, so I guess it's back to Power.
ron