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
-----Original Message-----
From: coreboot-bounces@coreboot.org [mailto:coreboot-bounces@coreboot.org] On Behalf Of Patrick Georgi Sent: Tuesday, February 25, 2014 1:13 PM To: coreboot@coreboot.org Subject: Re: [coreboot] how to model the Quark architecture
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.
I can imagine... Myself, I started looking into the some INTEL source code, and... But maybe for Quark FSP, there are only three functions which need to wrap the above mentioned Quark source code, as per general FSP spec: ROM stage - FSP calls: TempRamInitEntry(); FspInitEntry();
RAM stage - FSP calls: NotifyPhaseEntry() - twice invoked!
Maybe this can isolate (temporarily) the coding style problem, and expose just FSP I/F - APIs as they are created by FSP spec (as to support and unify access for other binary FSP blobs) for another CPUs... For the very beginning!
This what I have proposed binds to current Coreboot FSP support/framework for other INTEL CPUs (and can be easily cloned/replicated for Quark framework, for/per the current INTEL architecture)... I hope!
Zoran _______ coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot Intel GmbH Dornacher Strasse 1 85622 Feldkirchen/Muenchen, Deutschland Sitz der Gesellschaft: Feldkirchen bei Muenchen Geschaeftsfuehrer: Christian Lamprechter, Hannes Schwaderer, Douglas Lusk Registergericht: Muenchen HRB 47456 Ust.-IdNr./VAT Registration No.: DE129385895 Citibank Frankfurt a.M. (BLZ 502 109 00) 600119052
-----Original Message----- From: coreboot-bounces@coreboot.org [mailto:coreboot-bounces@coreboot.org] On Behalf Of Patrick Georgi
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.
// Bit defs #define BIT0 0x0001 #define BIT1 0x0002 #define BIT2 0x0004 #define BIT3 0x0008 #define BIT4 0x0010 #define BIT5 0x0020 #define BIT6 0x0040 #define BIT7 0x0080 #define BIT8 0x0100 #define BIT9 0x0200 #define BIT10 0x0400 #define BIT11 0x0800 #define BIT12 0x1000 #define BIT13 0x2000 #define BIT14 0x4000 #define BIT15 0x8000 #define BIT16 0x00010000 #define BIT17 0x00020000 #define BIT18 0x00040000 #define BIT19 0x00080000 #define BIT20 0x00100000 #define BIT21 0x00200000 #define BIT22 0x00400000 #define BIT23 0x00800000 #define BIT24 0x01000000 #define BIT25 0x02000000 #define BIT26 0x04000000 #define BIT27 0x08000000 #define BIT28 0x10000000 #define BIT29 0x20000000 #define BIT30 0x40000000 #define BIT31 0x80000000
Laugh of The Day! ;-)
Zoran
Intel GmbH Dornacher Strasse 1 85622 Feldkirchen/Muenchen, Deutschland Sitz der Gesellschaft: Feldkirchen bei Muenchen Geschaeftsfuehrer: Christian Lamprechter, Hannes Schwaderer, Douglas Lusk Registergericht: Muenchen HRB 47456 Ust.-IdNr./VAT Registration No.: DE129385895 Citibank Frankfurt a.M. (BLZ 502 109 00) 600119052
-
Patrick Georgi -
Stojsavljevic, Zoran