[coreboot] Porting Kabylake laptop

[Nico Huber]

Hi Ron,

On 27.06.2018 16:47, ron minnich wrote:
> On Wed, Jun 27, 2018 at 4:37 AM <chrisglowaki at 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