[coreboot] Porting Kabylake laptop

[ron minnich]

On Wed, Jun 27, 2018 at 8:18 AM Nico Huber <nico.h at 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.coreboot.org/pipermail/coreboot/attachments/20180627/0ed8d178/attachment.html>