Hm.... I returned from the vacation, and I am reading this thread. The best to adopt Quark to Coreboot will be to go to: http://sourceforge.net/apps/mediawiki/tianocore/index.php?title=EDK2 Then to download EDK2 (or from INTEL site, as mention before) for Quark. This should be all Open Source Code, as my best understanding is (somebody correct me if I am wrong).
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. 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!). _______ 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)! Best Regards, Zoran _______ Most of The Time you should be "intel inside" to be capable to think "out of the box". -----Original Message----- From: [email protected] [mailto:[email protected]] On Behalf Of Aaron Durbin Sent: Tuesday, February 18, 2014 7:40 PM To: coreboot Subject: Re: [coreboot] how to model the Quark architecture On Tue, Feb 18, 2014 at 10:33 AM, Peter Stuge <[email protected]> wrote: > ron minnich wrote: >> I can't understand the point here. >> docs or code would help. > > Aaron Durbin wrote: >> Could you please provide explicit examples having c struct fields >> represented in devicetree that model another address space? > > No I can not. > > I do not have the capacity to deliver the ready-made architecture to > you guys. > > > I'm sorry I said anything, I was silly to think that design discussion > would be possible. I'm sorry you feel that way. I was asking for an example so I could better understand what you were getting at. You mentioned HT being a mistake, and since you noted that I was hoping you had an idea on what you wanted to see. And I don't think anyone was asking for a 'ready-made architecture.' I was seeking clarity. You clearly have opinions on mistakes made in the past, and I was seeking expansion on those opinions aside from the initial statements. Were you wanting some sort of attribute that suggested there is another address space of registers that need to be accessed? And all those registers detailed? -Aaron -- coreboot mailing list: [email protected] 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 -- coreboot mailing list: [email protected] http://www.coreboot.org/mailman/listinfo/coreboot
