[coreboot] how to model the Quark architecture
zoran.stojsavljevic at intel.com
Tue Feb 25 14:41:37 CET 2014
> From: coreboot-bounces at coreboot.org [mailto:coreboot-bounces at coreboot.org] On Behalf Of Patrick Georgi
> Sent: Tuesday, February 25, 2014 1:13 PM
> To: coreboot at 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:
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!
coreboot mailing list: coreboot at coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
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
More information about the coreboot