zoran.stojsavljevic at gmail.com
Thu Apr 12 18:24:00 CEST 2018
> Is it possible to go from BIOS/UEFI to UBOOT (on-board)? How?
Actually, since you are using, after all, YOCTO Project to build your
BDX-DE BSP, you can freely use U-Boot, if Bin Meng (U-Boot BSP
maintainer) already integrated BDX-DE/Camelback CRB's FSP into U-Boot.
Did you integrate FSP to U-Boot for BDX-DE (Camelback CRB)?
The good thing about this approach is that:
 You will follow YOCTO unwritten protocol. since you can find all
the rootfs and other elements in <project
name>/build/tmp/deploy/images/<platform_name> (where the platform name
is in your case: intel-corei7-64, since you have added meta-intel into
the YOCTO layering);
 U-Boot is a standard ingredient of YOCTO layering, whereas for
Coreboot I would not say so, (much) easier to handle U-Boot;
 Do NOT listen about the linuxboot bootloader, since you need to
create your own YOCTO mate-bsp layer with linuxboot specifics;
 If you use Lava framework for the BSP testing, U-Boot is
(definitely) your saviour!
On Thu, Apr 12, 2018 at 4:37 PM, ron minnich <rminnich at gmail.com> wrote:
> 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
> 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
> 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.
> coreboot mailing list: coreboot at coreboot.org
More information about the coreboot