Am 2014-02-25 09:37, schrieb Stojsavljevic, Zoran:
Then to do minimalistic configuration of EDK2, and practically to assemble Quark FSP. And to extract this FSP (SEC and PEI phases, which is not easy at all) as source code from Quark EDK2 source code. Incorporate this into Coreboot as Quark FSP source code.
One problem is that in coreboot development we care about style (although there will be disagreement to which degree).
And not just in a formal way (which indent could solve), but I'd rather not see things like (BIT31 | BIT30 | BIT29 | .. all the way down to .. | BIT 1 | BIT 0) in our tree.
While looking terribly enterprisey, it's just terrible. Intel code, at least as far as it is public and not part of the Linux kernel, manages to collect all the horrible code standards in a single place.
Rest supposed to be straight forward... As Sage did it for IVB (using IVB FSP as binary blob), similar idea for Quark, as then it complies to Coreboot model, with all done by source code (strange to read this for INTEL, isn't it!).
"Luckily", Intel being Intel, the boot code is signed, so it's not as simple as it sounds.
Other idea is old one, from this thread, to incorporate the whole EDK2 into Coreboot, but then, EDK2 is UEFI compliant BIOS, as my best understanding is (why then to run Coreboot, instead from UEFI BIOS to transition to legacy GRUB 0.97 with some security features incorporated)!
Indeed. There is no need to bloat coreboot by factor 6. I measured.
Regards, Patrick