So, the final word here: In building of INTEL skus' Coreboot INTEL FIT tool (under NDA) is A MUST/mandatory, and INTEL is the road block if you are not working with them (having the NDA signed with them)?
What about the concept of an Open Source??? ;-) I am at this point very confused... Really, I am. I did NOT find anywhere in any document that for Coreboot building INTEL FIT is mandatory??? Thank you, Zoran On Wed, Feb 22, 2017 at 5:40 PM, Aaron Durbin <adur...@google.com> wrote: > On Wed, Feb 22, 2017 at 10:18 AM, Zoran Stojsavljevic > <zoran.stojsavlje...@gmail.com> wrote: > > Aaron, > > > > Not that I am trying to be pest/bad guy. Please, believe me on this. Just > > about the simple logic, which SHOULD NOT be deniable! > > > > I did what I know about Coreboot, hands on, from 3.3 years ago. Then, I > > built the VERY first Emerald Lake 2 (CCG CRB) -> Cougar Canyon 2 CRB as > > payload SeaBIOS, and WIN 8.0 32bit. I was really amazed. Then. > > > > And I read much more these days, and a bit emailed with Martin > (forth/back), > > so Martin can give me a jump start. And then I read more. And more. And > for > > 5 full days I was doing this exercise (with lot of pain). > > > > So, I'll quote you: > > > >> That file is the FSP blob. Nothing more. As Nico pointed out that is > >> something completely different from the flash descriptor. The flash > >> descriptor can be obtained from the original released BIOS or you have > >> to generate it using Intel's FIT tool. > > > > Please, guide me through this process. Or point to some documents about > this > > process I can read about? > > IIRC, FIT is provided by Intel to its customers under NDA. You'll have > to contact your Intel rep for that. It's quite the barrier to entry > for using these devices, but that's a policy decision from Intel. > > Or you can take a previously released bios for this board and do > similar as the instructions on the Minnow Max page: > http://elinux.org/Minnowboard:MinnowMaxCoreboot#TXE_and_SPI_descriptor > > Note, TXE/CSE on apollolake does not have its own region in the flash. > It's in something intel calls IFWI and has its own new format that > lives in the "BIOS" region. There's a tool (util/cbfstool/ifwitool.c) > which takes an existing image with the IFWI and makes it work with > coreboot's implementation/support for apollolake. > > > > > Thank you, > > Zoran > > > > On Wed, Feb 22, 2017 at 5:05 PM, Aaron Durbin <adur...@google.com> > wrote: > >> > >> On Wed, Feb 22, 2017 at 10:01 AM, Zoran Stojsavljevic > >> <zoran.stojsavlje...@gmail.com> wrote: > >> > I can admit my errors: > >> > > >> > This is what I have: > >> > > >> > user@localhost FspBin]$ pwd > >> > > >> > /home/user/projects/coreboot/coreboot/APL-I_FSP/ > ApolloLakeFspBinPkg/FspBin > >> > [user@localhost FspBin]$ ls -al > >> > total 672 > >> > drwxr-xr-x. 2 user user 4096 Feb 11 12:19 . > >> > drwxr-xr-x. 6 user user 4096 Feb 11 12:19 .. > >> > -rw-r--r--. 1 user user 136832 Feb 11 12:19 ApolloLakeFsp.bsf > >> > -rw-r--r--. 1 user user 540672 Feb 11 12:19 ApolloLakeFsp.fd > >> > [user@localhost FspBin]$ > >> > > >> > I use one in RED. > >> > > >> > Need the clarification. Please, do it for me. > >> > >> That file is the FSP blob. Nothing more. As Nico pointed out that is > >> something completely different from the flash descriptor. The flash > >> descriptor can be obtained from the original released BIOS or you have > >> to generate it using Intel's FIT tool. > >> > >> > > >> > Zoran > >> > > >> > On Wed, Feb 22, 2017 at 4:56 PM, Nico Huber <nico.hu...@secunet.com> > >> > wrote: > >> >> > >> >> On 22.02.2017 08:12, Zoran Stojsavljevic wrote: > >> >> > Hello to community, > >> >> > > >> >> > I finally, after 3 days of additional very hard struggle, found out > >> >> > why > >> >> > I > >> >> > have (while I am in the last stage of building CBFS) nonsense while > >> >> > building APL-I Coreboot coreboot.rom?! > >> >> > > >> >> > Please, read carefully this announcement. > >> >> > > >> >> > For last three days I came to hard stop because of this failure: > >> >> > > >> >> > Just quick look into the final failure (all passed, but last stage > - > >> >> > IFD > >> >> > failed): > >> >> > > >> >> > Compile IFDTOOL > >> >> > HOSTCC util/ifdfake/ifdfake > >> >> > DD Adding Intel Firmware Descriptor > >> >> > IFDTOOL Unlocking Management Engine > >> >> > File build/coreboot.pre is 8388608 bytes > >> >> > No Flash Descriptor found in this image > >> >> > *src/southbridge/intel/common/firmware/Makefile.inc:50: recipe for > >> >> > target > >> >> > 'add_intel_firmware' failed* > >> >> > *make: *** [add_intel_firmware] Error 1* > >> >> > [user@localhost coreboot]$ > >> >> > > >> >> > At first, I suspect that culprit my .config file, but I have > checked > >> >> > it > >> >> > several times (maybe > dozen), and I could NOT find any problem > with > >> >> > it > >> >> > (except minor doubts). > >> >> > > >> >> > Then I switched to inspect -southbridge- setup, but these is none, > >> >> > since > >> >> > (simplified explanation/view) APL-I is SoC. > >> >> > > >> >> > The next phase was to inspect > >> >> > *src/southbridge/intel/common/firmware/Makefile.inc* , but there > >> >> > (although > >> >> > my make scripting is rusty) I could NOT find any problem... > >> >> > > >> >> > Finally, somewhere around 2:00 AM I noticed/determined the root > cause > >> >> > of > >> >> > the problem: the util/ifdtool/ifdtool.c, line: > >> >> > if (*(uint32_t *) (image + i) == *0x0FF0A55A*) { > >> >> > > >> >> > YET another INTEL IOTG PED hidden road bomb: the latest APL-I FSP: > >> >> > APL-I_ > >> >> > FSP/ApolloLakeFspBinPkg/FspBin/ApolloLakeFsp.fd does NOT have > pattern > >> >> > *0x0FF0A55A* embedded in it (I have checked with HxD WIN tool). > >> >> > >> >> Looks like this [VERY IMPORTANT] Announcement is about you, confusing > >> >> two very different concepts. FSP is a binary program run by coreboot > >> >> and has nothing in common with the Intel Firmware Descriptor. It's > >> >> called *.fd for some reason I don't know, but I'm pretty sure it's > >> >> another binary. The Firmware Descriptor describes some flash > parameters > >> >> and soft straps. It's just data, no program. You only need it as an > OEM > >> >> to build a full ROM image for a new system. If you have a system that > >> >> already runs another firmware, you can just keep the existing > >> >> descriptor > >> >> in place. > >> >> > >> >> Nico > >> > > >> > > >> > > >> > -- > >> > coreboot mailing list: coreboot@coreboot.org > >> > https://www.coreboot.org/mailman/listinfo/coreboot > > > > >
-- coreboot mailing list: coreboot@coreboot.org https://www.coreboot.org/mailman/listinfo/coreboot