It allows U-Boot to boot from EFI.
This is a true art of overkill... Really.
Full EFI (around 1 to 2 million lines of code: SEC, PEI, DXE phases, with ME HECI involved, altogether) -> U-Boot -> YOCTO. Wow. ;-)
Zoran
On Mon, Oct 9, 2017 at 4:43 PM, Simon Glass sjg@chromium.org wrote:
Hi,
On 3 October 2017 at 08:58, vnktux vnktux@protonmail.com wrote:
Hi all,
For my graduation project my company asked to use U-Boot as bare metal
boot-loader on one of their product. The product in an embedded board with a Xeon Broadwell-DE D-1527 Quad Core. The current boot-loader consist of Coreboot + U-Boot, but of course they want to get rid of Coreboot. I have almost no experience with U-Boot (Just with ARM processor a little bit) and so far I don't even know if it's possible or not to achieve the final goal. What I have understood is that I need the following binary blobs to work: fsp.bin, vga.bin, descriptor.bin, me.bin, microcode.bin. Is it true? Can somebody point me in the right direction because I am a little bit lost? Plus I don't see many x86 boards implemented in the source code of U-Boot.
The original U-Boot payload support was done with Broadwell-DE (I'm not sure which one though). It allows U-Boot to boot from EFI.
For what you want, yes you will need to obtain various binary blobs. Hopefully you can get the FSP from Intel, and with that the work required in U-Boot is probably not too large. Although I'm sure that the FSP API will have changed a little.
Regards, Simon
Best regards, Vincenzo
Sent with [ProtonMail](https://protonmail.com) Secure Email. _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot