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
On Wed, Jun 27, 2018 at 8:18 AM Nico Huber nico.h@gmx.de wrote:
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.
This is probably my imprecise language, sorry about that.
We take SEC and PEI as a given, and the goal, over time, is to replace all DXEs, including the binary DXECore, with an open source version. I'd ideally like to see *zero* proprietary DXEs, but I don't expect to get there. Here's a number: on one board, Trammell reports going from 400 DXEs to 79. A good start. On another board, we got down to 4.
Of course it's easier when somebody else already did the hard part.
Yes. That's the whole point. We aren't doing the hard part. And on Intel server, with QPI or Omnipath, we will *never* get the information we need to do that part anyway. It's not hard in that case, it's impossible. So we have decided not to do the impossible part either :-)
What about PEI, is that manageable too?
it's a blob. What can I say? We take that blob. It's manageable. If you accept that you'll have to use a blob, my experience is still that UEFI is easier than FSP.
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).
No, they don't do the port. They use the SEC and PEI as given.
People who have done ports know how hard it is. People who have not done ports have no idea, as you know. Many people still think installing coreboot is as easy as installing an OS with a DVD ...
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.
I think what you just said here is that FSP could be, and should be, easy, but Intel makes it hard? I think I'm agreeing with you.
I've noticed with some dismay that the scope of FSP continues to grow, as it takes on more and more responsibility.
Architectures don't matter, commitment to documentation is what makes OpenPower open.
I think you're right as far as it goes, but further, silicon companies need either vertical integration on their hardware, so they are able to release docs; or they need to use IP cores that have documents they can release.
On Power, it seems, IBM has the ability to release docs, and further, it releases them. Intel has the ability to release docs, and has declined to do so for almost 15 years. SiFive can't release some of their docs, as I understand, because it had to license IP.
Commitment to document is necessary but not sufficient.
ron
-
Nico Huber -
ron minnich