Re: [coreboot] Porting Kabylake laptop

26. Jun 2018 20:02 by [e-mail] :
> For a case like this, where your choice is between two binary blobs (FSP or UEFI) I would argue that linuxboot is a better way to go. 
> See > github.com/osresearch/heads http://github.com/osresearch/heads>  or > linuxboot.org http://linuxboot.org>  for more info. 
> ron

Doesn't linuxbootalso require the FSP blob for memory and silicon initialization on any Intel board after Ivy Bridge?

Thanks

Chris

Porting Kabylake laptop

[ron minnich]

On Wed, Jun 27, 2018 at 4:37 AM  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
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

Porting Kabylake laptop

[Nico Huber]

Hi,

On 27.06.2018 13:37, [e-mail] wrote:
> Jun 2018 20:02 by [e-mail] :
> > For a case like this, where your choice is between two binary blobs (FSP
> > or UEFI) I would argue that linuxboot is a better way to go.

Question is, what is this "case"? Chris, what is your motivation for the
coreboot port?
> > See > github.com/osresearch/heads http://github.com/osresearch/heads>
> > or > linuxboot.org http://linuxboot.org>  for more info.
> > ron
>
> Doesn't linuxbootalso require the FSP blob for memory and silicon
> initialization on any Intel board after Ivy Bridge?

LinuxBoot is an ambiguous term. What Ron and Philipp suggest here is
taking an existing UEFI, strip it down to something as light as core-
boot and plug the Linux kernel in. If you just want to get rid of the
bloated, often bug haunted, user visible parts of UEFI, this is a
good way to achieve it. If you want more control over the earlier,
lower level parts of the boot process, coreboot is the way to go, IMO.

The convenient trick of UEFI/LinuxBoot is that you don't have to care
about any mainboard specific things, if somebody else already ported
UEFI for your board. And other than the name suggests, you can boot
any other OS*, the Linux in LinuxBoot is just a fancy boot loader.

Nico

* Not sure about the status of Windows support, but it seems doable
  if you keep enough UEFI.

Porting Kabylake laptop

[ron minnich]

On Wed, Jun 27, 2018 at 8:35 AM Nico Huber  wrote:
> And other than the name suggests, you can boot
> any other OS*, the Linux in LinuxBoot is just a fancy boot loader.

yes, the name LinuxBoot revives an old misconception, that LinuxBoot can
only boot Linux. Same problem we had with the name LinuxBIOS. Oh well ...
my bad.
>