Zoran, read this : https://puri.sm/posts/librem-13-coreboot-report-january-12-2017/ It might help you understand what that IFD and 0x5aa5f00f is (little endian makes it 0x0FF0A55A) I had the same confusion when I started, and when I figured things out, I wrote that blog post that explained the process.
On Wed, Feb 22, 2017 at 11:51 AM, Zoran Stojsavljevic < [email protected]> wrote: > 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 <[email protected]> wrote: > >> On Wed, Feb 22, 2017 at 10:18 AM, Zoran Stojsavljevic >> <[email protected]> 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 <[email protected]> >> wrote: >> >> >> >> On Wed, Feb 22, 2017 at 10:01 AM, Zoran Stojsavljevic >> >> <[email protected]> wrote: >> >> > I can admit my errors: >> >> > >> >> > This is what I have: >> >> > >> >> > user@localhost FspBin]$ pwd >> >> > >> >> > /home/user/projects/coreboot/coreboot/APL-I_FSP/ApolloLakeFs >> pBinPkg/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 <[email protected]> >> >> > 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: [email protected] >> >> > https://www.coreboot.org/mailman/listinfo/coreboot >> > >> > >> > > > -- > coreboot mailing list: [email protected] > https://www.coreboot.org/mailman/listinfo/coreboot >
-- coreboot mailing list: [email protected] https://www.coreboot.org/mailman/listinfo/coreboot
