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
> 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
Indeed. There is no need to bloat coreboot by factor 6. I measured.