[coreboot] [VERY IMPORTANT] Announcement regarding Apollo Lake Coreboot building

[Aaron Durbin]

On Wed, Feb 22, 2017 at 10:18 AM, Zoran Stojsavljevic
<zoran.stojsavljevic at 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 <adurbin at google.com> wrote:
>>
>> On Wed, Feb 22, 2017 at 10:01 AM, Zoran Stojsavljevic
>> <zoran.stojsavljevic at gmail.com> wrote:
>> > I can admit my errors:
>> >
>> > This is what I have:
>> >
>> > user at localhost FspBin]$ pwd
>> >
>> > /home/user/projects/coreboot/coreboot/APL-I_FSP/ApolloLakeFspBinPkg/FspBin
>> > [user at 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 at 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.huber at 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 at 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 at coreboot.org
>> > https://www.coreboot.org/mailman/listinfo/coreboot
>
>