<div dir="ltr">I plan to use the intel code as as guide, but not pull it in directly. We have source, we should do it right. I am going to take Aaron's suggestion and structure it as baytrail is structured.<div><br></div>
<div>FSP is fine for binary distros, but it's not a good fit if we have the ability to do the whole thing in source form.<br><div><br></div><div>ron</div></div></div><div class="gmail_extra"><br><br><div class="gmail_quote">
On Tue, Feb 25, 2014 at 5:41 AM, Stojsavljevic, Zoran <span dir="ltr"><<a href="mailto:zoran.stojsavljevic@intel.com" target="_blank">zoran.stojsavljevic@intel.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="">-----Original Message-----<br>
> From: <a href="mailto:coreboot-bounces@coreboot.org">coreboot-bounces@coreboot.org</a> [mailto:<a href="mailto:coreboot-bounces@coreboot.org">coreboot-bounces@coreboot.org</a>] On Behalf Of Patrick Georgi<br>
> Sent: Tuesday, February 25, 2014 1:13 PM<br>
> To: <a href="mailto:coreboot@coreboot.org">coreboot@coreboot.org</a><br>
> Subject: Re: [coreboot] how to model the Quark architecture<br>
><br>
</div><div class="">> One problem is that in coreboot development we care about style (although there will be disagreement to which degree).<br>
> And not just in a formal way (which indent could solve), but I'd rather not see things like<br>
> (BIT31 | BIT30 | BIT29 | .. all the way down to .. | BIT 1 | BIT 0) in our tree.<br>
><br>
> While looking terribly enterprisey, it's just terrible.<br>
> 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.<br>
<br>
</div>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:<br>

ROM stage - FSP calls:<br>
        TempRamInitEntry();<br>
        FspInitEntry();<br>
<br>
RAM stage - FSP calls:<br>
        NotifyPhaseEntry() - twice invoked!<br>
<br>
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!<br>

<br>
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!<br>
<br>
Zoran<br>
_______<br>
<div class="im HOEnZb">coreboot mailing list: <a href="mailto:coreboot@coreboot.org">coreboot@coreboot.org</a> <a href="http://www.coreboot.org/mailman/listinfo/coreboot" target="_blank">http://www.coreboot.org/mailman/listinfo/coreboot</a><br>

</div><div class="im HOEnZb">Intel GmbH<br>
Dornacher Strasse 1<br>
85622 Feldkirchen/Muenchen, Deutschland<br>
Sitz der Gesellschaft: Feldkirchen bei Muenchen<br>
Geschaeftsfuehrer: Christian Lamprechter, Hannes Schwaderer, Douglas Lusk<br>
Registergericht: Muenchen HRB 47456<br>
Ust.-IdNr./VAT Registration No.: DE129385895<br>
Citibank Frankfurt a.M. (BLZ 502 109 00) 600119052<br>
<br>
<br>
</div><div class="HOEnZb"><div class="h5">--<br>
coreboot mailing list: <a href="mailto:coreboot@coreboot.org">coreboot@coreboot.org</a><br>
<a href="http://www.coreboot.org/mailman/listinfo/coreboot" target="_blank">http://www.coreboot.org/mailman/listinfo/coreboot</a><br>
</div></div></blockquote></div><br></div>