-----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