> 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. If?
Bin, Did you integrate FSP to U-Boot for BDX-DE (Camelback CRB)? _______ The good thing about this approach is that: [1] 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); [2] U-Boot is a standard ingredient of YOCTO layering, whereas for Coreboot I would not say so, (much) easier to handle U-Boot; [3] Do NOT listen about the linuxboot bootloader, since you need to create your own YOCTO mate-bsp layer with linuxboot specifics; [4] If you use Lava framework for the BSP testing, U-Boot is (definitely) your saviour! Best Regards, Zoran _______ On Thu, Apr 12, 2018 at 4:37 PM, ron minnich <[email protected]> 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 > 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. > > -- > coreboot mailing list: [email protected] > https://mail.coreboot.org/mailman/listinfo/coreboot -- coreboot mailing list: [email protected] https://mail.coreboot.org/mailman/listinfo/coreboot
