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