Re: [coreboot] BIOS/CoreBoot/UBOOT

[Zaolin]

Hey Raymond,

you can now start to ship coreboot with LinuxBoot easily
https://review.coreboot.org/#/c/coreboot/+/23071/.

Which gives you a whole Linux environment instead of TFTP. See
www.linuxboot.org for more details.

Regarding my work, I have implemented measured boot support into
coreboot. You can already use Google's verified boot without

pulling changes from coreboot gerrit review. If you want to have a
deeper look into VBoot2, checkout:

https://www.youtube.com/watch?v=4EvTcfcYfMY

We covered this aspect since 2010 ;)

Also if you have questions or problems you can talk to us via IRC, my
IRC handle is zaolin.

Happy Hacking, Philipp

On 12.04.2018 03:54, Raymond Yeung wrote:
> Thanks David for the detailed response.
>
> My main motivation to go down Coreboot/UBOOT route is to attempt to
> simplify the remaining boot-up to Linux.  Instead of using PXE-BOOT,
> we could use tftp only.  Am I correct to say that?
>
> If we're to use whatever that is available today, instead of waiting
> for Philipp's work to complete, does coreboot/UBOOT provide secure
> boot support?  I'd tend to think so, but want to confirm.  UEFI seems
> to already have this aspect covered.
>
> Raymond
>
> *From:* David Hendricks 
> *Sent:* Wednesday, April 11, 2018 6:03 PM
> *To:* Raymond Yeung
> *Cc:* [e-mail]
> *Subject:* Re: [coreboot] BIOS/CoreBoot/UBOOT
>
> On Wed, Apr 11, 2018 at 3:39 PM, Raymond Yeung <[e-mail]
> > wrote:
> I currently have a board that uses Intel Xeon D (previously
> codenamed Broadwell DE).  It boots up with BIOS/UEFI. I 'm
> exploring other oot-up options here.
>
>
> I'm not familiar with this early stage of system initialization. 
> It seems BIOS/UEFI to Linux needs to use PXE, with the need to
> configure DHCP (and possibly Proxy DHCP), TFTP server PXELINUX,
> Linux initial RAM disk (initrd) configuration file, and then
> Linux.  Previously, I'd been using Coreboot/UBOOT environment (as
> a user, not developer).  Prerequisite seemed much simpler.
>
>
> A few questions -
>
>
>  1. Is there even a coreboot support for this CPU already
>     available and stable that I could download and reflash?  Or
>     are we talking about some serious re-development?
>
>
> Yes - See src/mainboard/intel/camelbackmountain_fsp/ for the reference
> platform.
>
> You'll need the Intel FSP blob from
> https://github.com/IntelFsp/FSP/tree/Broadwell-DE
> https://github.com/IntelFsp/FSP/tree/Broadwell-DE. You'll also need
> microcode which you can download from developer.intel.com
> http://developer.intel.com.
>  1. Is it possible to go from BIOS/UEFI to UBOOT (on-board)?  How?
>
>
> I haven't tried uboot as a payload, but yes, it is possible. There are
> other options available to consider depending on your use case.
>  1. Support for Secure Boot - would one approach be simpler than
>     another?
>
>
> It depends on what you want/need. Philipp Deppenwiese is working on
> "vboot" (Google's verified boot implementation) integration with
> upstream: https://review.coreboot.org/#/c/coreboot/+/24993/
>
> More about that approach
> here: https://www.chromium.org/chromium-os/chromiumos-design-docs/verified-boot
>  1. Am I even on the right track thinking this way?
>
>
> You seem to be off to a good start :-)

BIOS/CoreBoot/UBOOT

[ron minnich]

At this point, on this platform, I think your fastest bet to mostly open
sourcing it all is linuxboot. We recently had an experience where we
installed a linux kernel in FLASH on  two new boards in two days and most
of that was just figuring out how to rearrange the UEFI bits, (i.e. move
the furniture around :-) not building code. You can now replace a lot of
UEFI with a linux kernel and the only thing you have to build is ... a
Linux kernel.

We recently found that for supported boards, a git clone of the linuxboot
repo and full build takes 2 minutes 45 seconds, and that's essentially
hands off.

If you have a UEFI system, which that board almost certainly is, I think
you can skip coreboot and u-boot entirely and just take the linuxboot
approach. I'm no longer that big a fan of FSP, it has its own problems.

I realize in this note there's a lot of "Alphabet soup" (many, many names
like UEFI and FSP and all ...) but the short form is this: with modern x86
CPUs, the coreboot port is indeed a very large effort. The linuxboot effort
is, as mentioned, as little as a day in some cases. I can tell you from
experience it is far less work and, ironically, can also result in the use
of fewer binary blobs on these CPUs.

Obviously, for open CPUs, I still prefer coreboot; but x86 CPUs are no
longer open in any meaningful sense of the word.