Hi Ron,
On 27.06.2018 16:47, ron minnich wrote:
On Wed, Jun 27, 2018 at 4:37 AM chrisglowaki@tutanota.com wrote:
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
so you are doing UEFI board ports yourself now? I always had the impres- sion that you merely reuse existing ports and plug in the kernel. Of course it's easier when somebody else already did the hard part. So what is it exactly that you are comparing here?
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.
What about PEI, is that manageable too?
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.
I wonder if they would do the UEFI port themselves. I have the feeling that some people still try coreboot with the wrong expectations, they hope because it's free software everything will just work as if they had paid an IBV (but at no cost).
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.
We still own the first instructions (at least those that run from flash memory). FSP and what Intel hides in there is not about the processor or any architectural bring-up, it's about peripherals. One of them is the memory controller, but most are just random bits of Intel's chipsets. The part that makes FSP hard to handle is the latter. It could be super easy to handle if Intel would concentrate on the parts that they want to hide. But they just want to do it wrong.
What's the right architecture for full control? My RISC-V hopes are in tatters, so I guess it's back to Power.
Architectures don't matter, commitment to documentation is what makes OpenPower open.
Nico