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

[Zoran Stojsavljevic]

> Zoran, and others,

>

> I wanted to build coreboot for APL CRP too. Tried to compile but failed
at last command I think.


First email thread to read ([coreboot] Intel Leaf Hill Coreboot Trouble):

https://mail.coreboot.org/pipermail/coreboot/2017-September/085210.html


Second community thread to read (to get the idea about APL-I IFWI):

https://embedded.communities.intel.com/thread/13129


Please, let us know if these threads are helpful!


Zoran

On Fri, Nov 3, 2017 at 2:14 AM, ahW@n via coreboot 
wrote:

> Zoran,
>
> and others,
>
>
>
> I wanted to build coreboot for APL CRP too.
>
> Tried to compile but failed at last command I think.
>
>
>
> *Image written successfully to build/cbfs/fallback/ifwi.bin.tmp.*
>
> *INFO: Performing operation on 'IFWI' region...*
>
> *E: Image is missing 'IFWI' region*
>
> *E: The image will be left unmodified.*
>
> *src/soc/intel/apollolake/Makefile.inc:128: recipe for target
> 'files_added' failed*
>
> *make: *** [files_added] Error 1*
>
>
>
> Have been searching around for solution and correct steps to do so but
> still no luck...
>
> Have you get your APL coreboot working?
>
>
>
> I tried CONFIG_IFWI_FILE_NAME pointed to an original UEFI BIOS file
> (direct SPI flashable binary, tested).
>
> Also tried use FIT to regenerate new file with changes below:-
>
>   Platform Protection/Platform Integrity OOEM Public Key Hash => 00..00
>
>   Platform Protection/Boot Guard Configuration/ Boot profile 2 => 0
>
>
>
> I am not sure I have the correct .config
>
> Anyone here can advise  what I am doing wrong or am I missing anything?
>
> Thank you.
>
>
>
> user@localhost:~/coreboot$ build/util/cbfstool/cbfstool
> build/coreboot.rom print
>
> Name   Offset Type   Size   Comp
>
> cbfs master header 0x0cbfs header32 none
>
> fallback/romstage  0x80   stage   26852 none
>
> cpu_microcode_blob.bin 0x69c0 microcode   0 none
>
> fallback/ramstage  0x6a40 stage   67533 none
>
> vgaroms/seavgabios.bin 0x17280raw 26624 none
>
> config 0x1db00raw   424 none
>
> revision   0x1dd00raw   576 none
>
> fallback/postcar   0x1df80stage   16464 none
>
> fallback/dsdt.aml  0x22040raw99 none
>
> fallback/payload   0x22100payload 63073 none
>
> payload_config 0x317c0raw  1632 none
>
> payload_revision   0x31e80raw   239 none
>
> (empty)0x31fc0null  8052440 none
>
> mrc.cache  0x7dfec0   mrc_cache   65536 none
>
> (empty)0x7eff00   null32664 none
>
> bootblock  0x7f7ec0   bootblock   32768 none
>
>
>
> user@localhost:~/coreboot$ build/util/cbfstool/ifwitool
> ./build/cbfs/fallback/ifwi.bin.tmp print
>
> HeaderBPDT
>
> Signature 0x55aa
>
> Descriptor count  13
>
> BPDT Version  1
>
> XOR checksum  0x0
>
> IFWI Version  0x0
>
> FIT Tool Version  0x472000c0003
>
> BPDT entries
>
> Entry #  Sub-PartitionName
> Type Flags
> Offset   Size File Offset
>
> 
> 
> 
> =
>
> 1DLMP CSE_IDLM
> 90x   0x0
> 0x0  0x0
>
> 2IFP_OVERRIDE IFP_OVERRIDE
> 10   0x   0x200
> 0x10 0x200
>
> 3S_BPDT   S-BPDT
> 50x   0xe9000
> 0x149000 0xe9000
>
> 4RBEP CSE_RBE
> 10x   0x69000
> 0xa000   0x69000
>
> 5UFS_PHY  UFS Phy
> 12   0x   0x0
> 0x0  0x0
>
> 6UFS_GPP  UFS GPP
>   13   0x
> 0x0  0x0  0x0
>
> 7UEP  UEP
> 17   0x   0x210
> 0x1080x210
>
> 8IBBP Bootblock
> 40x   0x1000
> 0x64000  0x1000
>
> 9SMIP 

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

[ahW@n via coreboot]

Zoran,

and others,



I wanted to build coreboot for APL CRP too.

Tried to compile but failed at last command I think.



*Image written successfully to build/cbfs/fallback/ifwi.bin.tmp.*

*INFO: Performing operation on 'IFWI' region...*

*E: Image is missing 'IFWI' region*

*E: The image will be left unmodified.*

*src/soc/intel/apollolake/Makefile.inc:128: recipe for target 'files_added'
failed*

*make: *** [files_added] Error 1*



Have been searching around for solution and correct steps to do so but
still no luck...

Have you get your APL coreboot working?



I tried CONFIG_IFWI_FILE_NAME pointed to an original UEFI BIOS file (direct
SPI flashable binary, tested).

Also tried use FIT to regenerate new file with changes below:-

  Platform Protection/Platform Integrity OOEM Public Key Hash => 00..00

  Platform Protection/Boot Guard Configuration/ Boot profile 2 => 0



I am not sure I have the correct .config

Anyone here can advise  what I am doing wrong or am I missing anything?

Thank you.



user@localhost:~/coreboot$ build/util/cbfstool/cbfstool build/coreboot.rom
print

Name   Offset Type   Size   Comp

cbfs master header 0x0cbfs header32 none

fallback/romstage  0x80   stage   26852 none

cpu_microcode_blob.bin 0x69c0 microcode   0 none

fallback/ramstage  0x6a40 stage   67533 none

vgaroms/seavgabios.bin 0x17280raw 26624 none

config 0x1db00raw   424 none

revision   0x1dd00raw   576 none

fallback/postcar   0x1df80stage   16464 none

fallback/dsdt.aml  0x22040raw99 none

fallback/payload   0x22100payload 63073 none

payload_config 0x317c0raw  1632 none

payload_revision   0x31e80raw   239 none

(empty)0x31fc0null  8052440 none

mrc.cache  0x7dfec0   mrc_cache   65536 none

(empty)0x7eff00   null32664 none

bootblock  0x7f7ec0   bootblock   32768 none



user@localhost:~/coreboot$ build/util/cbfstool/ifwitool
./build/cbfs/fallback/ifwi.bin.tmp print

HeaderBPDT

Signature 0x55aa

Descriptor count  13

BPDT Version  1

XOR checksum  0x0

IFWI Version  0x0

FIT Tool Version  0x472000c0003

BPDT entries

Entry #  Sub-PartitionName
Type FlagsOffset
Size File Offset

=

1DLMP CSE_IDLM
90x   0x0
0x0  0x0

2IFP_OVERRIDE IFP_OVERRIDE
10   0x   0x200
0x10 0x200

3S_BPDT   S-BPDT
50x   0xe9000
0x149000 0xe9000

4RBEP CSE_RBE
10x   0x69000
0xa000   0x69000

5UFS_PHY  UFS Phy
12   0x   0x0
0x0  0x0

6UFS_GPP  UFS GPP
  13   0x
0x0  0x0  0x0

7UEP  UEP
17   0x   0x210
0x1080x210

8IBBP Bootblock
40x   0x1000
0x64000  0x1000

9SMIP SMIP
00x   0x65000
0x4000   0x65000

10   PMCP PMC firmware
14   0x   0x73000
0x1  0x73000

11   FTPR CSE_BUP
20x   0x83000
0x5c000  0x83000

12   UCOD Microcode
30x   0xdf000
0x8000   0xdf000

13   DEBUG_TOKENS Debug Tokens
11   0x   0xe7000
0x2000   0xe7000

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

[Zoran Stojsavljevic]

You see, Youness,

The documentation is very scarse, and scares people out of this... If you
would like to bring lot of people, it should be well documented, and the
path well set.

When I do/help some Linux users out of Fedora forum, there I am as blast...
Since most of the stuff is well documented, well explained, and millions of
people use it, so you can find tons of explanation over the www. (and I do
it for years). Here, every here and while everything changes, and there are
handful of people using Coreboot.

Not formula for success, does it? ;-)

Good Luck to you as well,
Zoran

On Thu, Feb 23, 2017 at 5:49 PM, Youness Alaoui <
kakar...@kakaroto.homelinux.net> wrote:

> Zoran,
>
> The blog post is not meant to be documentation, it's just a progress
> report and a *blog post* about the experience and I'm sure it's much less
> confusing than your emails have been so far.
> in menuconfig, in the Chipset section, there's "Add Intel descriptor.bin
> file" (which is what you had enabled, causing the build to fail) and under
> it, there is "Path and filename of the descriptor.bin file", you set it
> there.
> You'll also probably need to extract and include the ME region as well,
> and clone the blobs repository for the microcode updates to be generated
> from tree.
> Apart from that, I suggest you be careful with what you're doing to avoid
> bricking your device, learn what you can about the process, read
> documentation and even read the code if you need to. Randomly thinking that
> there's a "very important announcement" because you didn't understand how
> to compile coreboot (and then refusing to give your config and telling
> developers to look into this 'bug' without giving any more information) is
> not really the way to incite people to help you.
>
> Good luck
> Youness.
>
> On Thu, Feb 23, 2017 at 10:29 AM, Zoran Stojsavljevic <
> zoran.stojsavlje...@gmail.com> wrote:
>
>> Hello Youness (and others),
>>
>> Here, I need to apologize to all Coreboot recipients. Since it was a
>> while, I did peak into that. But... It is NOT You(ness). You got my
>> attention, and, since you blog is very confusing (lack of  some systematic
>> knowledge) about INTEL BSP Technology.
>>
>> I really admire your effort. And just because of that I (after some 6+
>> hours of investigation) I'll try to strengthen out your logs, which are, I
>> should say, puzzled, scrambled all over place. Pieces of Truth are there,
>> and you got on the right path. Although... Labyrinth (unsorted kludges and
>> facts) for most of folks.
>>
>> *I did NOT expect that ... will make out of this Rocket Science.* And
>> yes, they did make it??? Why, that is the question? ;-)
>>
>> I got it. Not quite up to ground level (I need to understand more about
>> make menuconfig setup). But in order to make (example) 8MB Coreboot, you
>> need to take the TRUE APL-I BIOS and to apply IFD tool, in order to extract
>> first 4K (4096) File Descriptor. And SBIOS part as well. Not sure how many
>> parts should be extracted?!
>>
>> Here is what GOOGLE designers posted for Emerald Lake 2, in 3rdparty:
>>
>> [user@localhost emeraldlake2]$ ls -al
>> total 2120
>> drwxrwxr-x. 2 user user4096 Feb 18 01:57 .
>> drwxrwxr-x. 3 user user4096 Feb 18 01:57 ..
>> -rw-rw-r--. 1 user user   4096 Feb 18 01:57 descriptor.bin
>> -rw-rw-r--. 1 user user   2093056 Feb 18 01:57 me.bin
>> -rw-rw-r--. 1 user user   65536 Feb 18 01:57 snm_2120.dat
>> [user@localhost emeraldlake2]$ pwd
>> /home/intel/projects/coreboot/coreboot/3rdparty/blobs/mainbo
>> ard/intel/emeraldlake2
>> [user@localhost emeraldlake2]$
>>
>> And, for descriptor.bin, there is the following:
>>
>> [image: Inline image 1]
>>
>> This (location 0x0010) I have checked with many BIOSes found on the
>> open net, . Most, but I did not find any instance of Apollo Lake, to build
>> proper Coreboot.com.
>>
>> So, I need to extract at least SBIOS and descriptor.bin from real (UEFI)
>> BIOS, and put, where?
>>
>> And then, to add to the Coreboot image. Using make menuconfig. Where and
>> how?
>>
>> (Courtesy Aaron Durbin): http://elinux.org/Min
>> nowboard:MinnowMaxCoreboot#TXE_and_SPI_descriptor
>>
>> Thank you all,
>> Zoran
>>
>> On Thu, Feb 23, 2017 at 12:30 AM, Youness Alaoui <
>> kakar...@kakaroto.homelinux.net> wrote:
>>
>>> 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 <
>>> zoran.stojsavlje...@gmail.com> 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 

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

[Youness Alaoui]

Zoran,

The blog post is not meant to be documentation, it's just a progress report
and a *blog post* about the experience and I'm sure it's much less
confusing than your emails have been so far.
in menuconfig, in the Chipset section, there's "Add Intel descriptor.bin
file" (which is what you had enabled, causing the build to fail) and under
it, there is "Path and filename of the descriptor.bin file", you set it
there.
You'll also probably need to extract and include the ME region as well, and
clone the blobs repository for the microcode updates to be generated from
tree.
Apart from that, I suggest you be careful with what you're doing to avoid
bricking your device, learn what you can about the process, read
documentation and even read the code if you need to. Randomly thinking that
there's a "very important announcement" because you didn't understand how
to compile coreboot (and then refusing to give your config and telling
developers to look into this 'bug' without giving any more information) is
not really the way to incite people to help you.

Good luck
Youness.

On Thu, Feb 23, 2017 at 10:29 AM, Zoran Stojsavljevic <
zoran.stojsavlje...@gmail.com> wrote:

> Hello Youness (and others),
>
> Here, I need to apologize to all Coreboot recipients. Since it was a
> while, I did peak into that. But... It is NOT You(ness). You got my
> attention, and, since you blog is very confusing (lack of  some systematic
> knowledge) about INTEL BSP Technology.
>
> I really admire your effort. And just because of that I (after some 6+
> hours of investigation) I'll try to strengthen out your logs, which are, I
> should say, puzzled, scrambled all over place. Pieces of Truth are there,
> and you got on the right path. Although... Labyrinth (unsorted kludges and
> facts) for most of folks.
>
> *I did NOT expect that ... will make out of this Rocket Science.* And
> yes, they did make it??? Why, that is the question? ;-)
>
> I got it. Not quite up to ground level (I need to understand more about
> make menuconfig setup). But in order to make (example) 8MB Coreboot, you
> need to take the TRUE APL-I BIOS and to apply IFD tool, in order to extract
> first 4K (4096) File Descriptor. And SBIOS part as well. Not sure how many
> parts should be extracted?!
>
> Here is what GOOGLE designers posted for Emerald Lake 2, in 3rdparty:
>
> [user@localhost emeraldlake2]$ ls -al
> total 2120
> drwxrwxr-x. 2 user user4096 Feb 18 01:57 .
> drwxrwxr-x. 3 user user4096 Feb 18 01:57 ..
> -rw-rw-r--. 1 user user   4096 Feb 18 01:57 descriptor.bin
> -rw-rw-r--. 1 user user   2093056 Feb 18 01:57 me.bin
> -rw-rw-r--. 1 user user   65536 Feb 18 01:57 snm_2120.dat
> [user@localhost emeraldlake2]$ pwd
> /home/intel/projects/coreboot/coreboot/3rdparty/blobs/mainbo
> ard/intel/emeraldlake2
> [user@localhost emeraldlake2]$
>
> And, for descriptor.bin, there is the following:
>
> [image: Inline image 1]
>
> This (location 0x0010) I have checked with many BIOSes found on the
> open net, . Most, but I did not find any instance of Apollo Lake, to build
> proper Coreboot.com.
>
> So, I need to extract at least SBIOS and descriptor.bin from real (UEFI)
> BIOS, and put, where?
>
> And then, to add to the Coreboot image. Using make menuconfig. Where and
> how?
>
> (Courtesy Aaron Durbin): http://elinux.org/Minnowboard:MinnowMaxCoreboot#
> TXE_and_SPI_descriptor
>
> Thank you all,
> Zoran
>
> On Thu, Feb 23, 2017 at 12:30 AM, Youness Alaoui <
> kakar...@kakaroto.homelinux.net> wrote:
>
>> 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 <
>> zoran.stojsavlje...@gmail.com> 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 
>>> wrote:
>>>
 On Wed, Feb 22, 2017 at 10:18 AM, Zoran Stojsavljevic
  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 

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

[Zoran Stojsavljevic]

Hello Youness (and others),

Here, I need to apologize to all Coreboot recipients. Since it was a while,
I did peak into that. But... It is NOT You(ness). You got my attention,
and, since you blog is very confusing (lack of  some systematic knowledge)
about INTEL BSP Technology.

I really admire your effort. And just because of that I (after some 6+
hours of investigation) I'll try to strengthen out your logs, which are, I
should say, puzzled, scrambled all over place. Pieces of Truth are there,
and you got on the right path. Although... Labyrinth (unsorted kludges and
facts) for most of folks.

*I did NOT expect that ... will make out of this Rocket Science.* And yes,
they did make it??? Why, that is the question? ;-)

I got it. Not quite up to ground level (I need to understand more about
make menuconfig setup). But in order to make (example) 8MB Coreboot, you
need to take the TRUE APL-I BIOS and to apply IFD tool, in order to extract
first 4K (4096) File Descriptor. And SBIOS part as well. Not sure how many
parts should be extracted?!

Here is what GOOGLE designers posted for Emerald Lake 2, in 3rdparty:

[user@localhost emeraldlake2]$ ls -al
total 2120
drwxrwxr-x. 2 user user4096 Feb 18 01:57 .
drwxrwxr-x. 3 user user4096 Feb 18 01:57 ..
-rw-rw-r--. 1 user user   4096 Feb 18 01:57 descriptor.bin
-rw-rw-r--. 1 user user   2093056 Feb 18 01:57 me.bin
-rw-rw-r--. 1 user user   65536 Feb 18 01:57 snm_2120.dat
[user@localhost emeraldlake2]$ pwd
/home/intel/projects/coreboot/coreboot/3rdparty/blobs/
mainboard/intel/emeraldlake2
[user@localhost emeraldlake2]$

And, for descriptor.bin, there is the following:

[image: Inline image 1]

This (location 0x0010) I have checked with many BIOSes found on the
open net, . Most, but I did not find any instance of Apollo Lake, to build
proper Coreboot.com.

So, I need to extract at least SBIOS and descriptor.bin from real (UEFI)
BIOS, and put, where?

And then, to add to the Coreboot image. Using make menuconfig. Where and
how?

(Courtesy Aaron Durbin): http://elinux.org/Minnowboard:
MinnowMaxCoreboot#TXE_and_SPI_descriptor

Thank you all,
Zoran

On Thu, Feb 23, 2017 at 12:30 AM, Youness Alaoui <
kakar...@kakaroto.homelinux.net> wrote:

> 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 <
> zoran.stojsavlje...@gmail.com> 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  wrote:
>>
>>> On Wed, Feb 22, 2017 at 10:18 AM, Zoran Stojsavljevic
>>>  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 

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

[Youness Alaoui]

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 <
zoran.stojsavlje...@gmail.com> 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  wrote:
>
>> On Wed, Feb 22, 2017 at 10:18 AM, Zoran Stojsavljevic
>>  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 
>> wrote:
>> >>
>> >> On Wed, Feb 22, 2017 at 10:01 AM, Zoran Stojsavljevic
>> >>  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 
>> >> > 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
>> >> >> > IFDTOOLUnlocking Management Engine
>> >> >> > File build/coreboot.pre is 8388608 bytes
>> >> >> > 

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

[Zoran Stojsavljevic]

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  wrote:

> On Wed, Feb 22, 2017 at 10:18 AM, Zoran Stojsavljevic
>  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 
> wrote:
> >>
> >> On Wed, Feb 22, 2017 at 10:01 AM, Zoran Stojsavljevic
> >>  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 
> >> > 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
> >> >> > IFDTOOLUnlocking 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 

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

[Aaron Durbin via coreboot]

On Wed, Feb 22, 2017 at 10:18 AM, Zoran Stojsavljevic
 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  wrote:
>>
>> On Wed, Feb 22, 2017 at 10:01 AM, Zoran Stojsavljevic
>>  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 
>> > 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
>> >> > IFDTOOLUnlocking 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* 

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

[Zoran Stojsavljevic]

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?

Thank you,
Zoran

On Wed, Feb 22, 2017 at 5:05 PM, Aaron Durbin  wrote:

> On Wed, Feb 22, 2017 at 10:01 AM, Zoran Stojsavljevic
>  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 
> 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
> >> > IFDTOOLUnlocking 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

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

[Aaron Durbin via coreboot]

On Wed, Feb 22, 2017 at 10:01 AM, Zoran Stojsavljevic
 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  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
>> > IFDTOOLUnlocking 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

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

[Zoran Stojsavljevic]

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.

Zoran

On Wed, Feb 22, 2017 at 4:56 PM, Nico Huber  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
> > IFDTOOLUnlocking 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

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

[Aaron Durbin via coreboot]

On Wed, Feb 22, 2017 at 9:56 AM, Nico Huber  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
>> IFDTOOLUnlocking 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.

I missed that bit. Yes, the .fd is just the extension FSP decided to
use for their blob.

>
> 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

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

[Nico Huber]

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
> IFDTOOLUnlocking 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

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

[Zoran Stojsavljevic]

> I don't know what PED dept. is at Intel. I also haven't been working with
IOTG so it's not
> clear to me what APL-I device you are trying to use or its
characteristics.

If you do not know what is going on here, you should investigate... And not
to try to do (empty) demagogy! ;-)

Thank you,
Zoran

On Wed, Feb 22, 2017 at 4:44 PM, Aaron Durbin  wrote:

>
>
> On Wed, Feb 22, 2017 at 9:36 AM, Zoran Stojsavljevic <
> zoran.stojsavlje...@gmail.com> wrote:
>
>> > Still not enough information.  Good luck with your problem.
>>
>> I have no problem that you believe to INTEL IOTG 100x more than me. ;-)
>>
>
> That has nothing to do with it. You have not presented enough information
> for me to actually help. That's the crux of the current situation.
>
>
>>
>> Good luck to you, Google, with INTEL IOTG PED dept. problem (please, do
>> not input to me other people problems, could I ask?).
>>
>> And, you need to work, and try to reproduce this problem, because I DO
>> (certainly) know that another people trying to build APL-I Coreboot have
>> this problem?! ;-)
>>
>
> I don't know what PED dept. is at Intel. I also haven't been working with
> IOTG so it's not clear to me what APL-I device you are trying to use or its
> characteristics. I was attempting to help with the situation, but as you
> are purposefully being opaque about settings it's impossible for me to
> help.
>
>
>
>>
>> Thank you,
>> Zoran
>>
>> On Wed, Feb 22, 2017 at 4:29 PM, Aaron Durbin  wrote:
>>
>>>
>>>
>>> On Wed, Feb 22, 2017 at 9:25 AM, Zoran Stojsavljevic <
>>> zoran.stojsavlje...@gmail.com> wrote:
>>>
 Not possible to share with you the details of my .config, until you
 understand that you need to investigate this problem as well. :-)

>>>
>>> I'm not sure I understand what you are saying. You are asking for help
>>> but won't share more details? If that's the case, then good luck as I can't
>>> be much help. You telling me to investigate something doesn't make me want
>>> to continue helping in the slightest.
>>>
>>>

 CLI transcript follows:

 [user@localhost coreboot]$ pwd
 /home/user/projects/coreboot/coreboot
 [user@localhost coreboot]$ cat .config | grep FIRMWARE
 CONFIG_CPU_INTEL_FIRMWARE_INTERFACE_TABLE=y
 CONFIG_HAVE_INTEL_FIRMWARE=y

>>>
>>> Still not enough information.  Good luck with your problem.
>>>
>>>
 [user@localhost coreboot]$
 ___

 [user@localhost firmware]$ pwd
 /home/user/projects/coreboot/coreboot/src/southbridge/intel/
 common/firmware
 [user@localhost firmware]$ emacs Kconfig &

 Beginning of the file: Kconfig?

 *config HAVE_INTEL_FIRMWARE*
 * bool*
 * help*
 *  Chipset uses the Intel Firmware Descriptor to describe the*
 *  layout of the SPI ROM chip.*

 *if HAVE_INTEL_FIRMWARE*

 *comment "Intel Firmware"*

 *config HAVE_IFD_BIN*

 Zoran

 On Wed, Feb 22, 2017 at 4:13 PM, Aaron Durbin 
 wrote:

>
>
> On Wed, Feb 22, 2017 at 9:08 AM, Zoran Stojsavljevic <
> zoran.stojsavlje...@gmail.com> wrote:
>
>> You mean, this one (in *RED*)?
>>
>> [user@localhost coreboot]$ cat .config | grep SPI
>> CONFIG_BOOT_DEVICE_SPI_FLASH_BUS=0
>> # CONFIG_TPM_ON_FAST_SPI is not set
>> # CONFIG_SPI_FLASH_INCLUDE_ALL_DRIVERS is not set
>> CONFIG_SOC_INTEL_COMMON_SPI_FLASH_PROTECT=y
>> # CONFIG_BOOTBLOCK_DEBUG_SPINLOOP is not set
>> # CONFIG_VERSTAGE_DEBUG_SPINLOOP is not set
>> # CONFIG_ROMSTAGE_DEBUG_SPINLOOP is not set
>> *CONFIG_SPI_FLASH=y*
>> CONFIG_BOOT_DEVICE_SPI_FLASH_RW_NOMMAP=y
>> CONFIG_BOOT_DEVICE_SPI_FLASH_RW_NOMMAP_EARLY=y
>> # CONFIG_SPI_FLASH_SMM is not set
>> # CONFIG_SPI_FLASH_NO_FAST_READ is not set
>> # CONFIG_SPI_FLASH_FAST_READ_DUAL_OUTPUT_3B is not set
>> # CONFIG_SPI_FLASH_HAS_VOLATILE_GROUP is not set
>> # CONFIG_HAVE_SPI_CONSOLE_SUPPORT is not set
>> # CONFIG_BOOT_DEVICE_NOT_SPI_FLASH is not set
>> *CONFIG_BOOT_DEVICE_SPI_FLASH=y*
>> # CONFIG_HAVE_ROMSTAGE_CONSOLE_SPINLOCK is not set
>> # CONFIG_HAVE_ROMSTAGE_NVRAM_CBFS_SPINLOCK is not set
>> # CONFIG_HAVE_ROMSTAGE_MICROCODE_CBFS_SPINLOCK is not set
>> # CONFIG_DEBUG_SPI_FLASH is not set
>> [user@localhost coreboot]$
>> Which one (but, anyway, I think you are on the wrong mental tread,
>> unless *you explicitly prove to me that I am wrong*)? [image: Inline
>> image 1]
>>
>>
> Where are you setting the descriptor to use during the build? Those
> settings highlighted in red have nothing to do with the flash descriptor
> settings. Please look in src/southbridge/intel/common/firmware/Kconfig
> for that list. Also, without the full details of your config it's
> impossible to know what you are or aren't doing.
>
>
>
>> Zoran
>>
>> On Wed, Feb 22, 2017 at 3:39 PM, Aaron 

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

[Aaron Durbin via coreboot]

On Wed, Feb 22, 2017 at 9:36 AM, Zoran Stojsavljevic <
zoran.stojsavlje...@gmail.com> wrote:

> > Still not enough information.  Good luck with your problem.
>
> I have no problem that you believe to INTEL IOTG 100x more than me. ;-)
>

That has nothing to do with it. You have not presented enough information
for me to actually help. That's the crux of the current situation.


>
> Good luck to you, Google, with INTEL IOTG PED dept. problem (please, do
> not input to me other people problems, could I ask?).
>
> And, you need to work, and try to reproduce this problem, because I DO
> (certainly) know that another people trying to build APL-I Coreboot have
> this problem?! ;-)
>

I don't know what PED dept. is at Intel. I also haven't been working with
IOTG so it's not clear to me what APL-I device you are trying to use or its
characteristics. I was attempting to help with the situation, but as you
are purposefully being opaque about settings it's impossible for me to
help.



>
> Thank you,
> Zoran
>
> On Wed, Feb 22, 2017 at 4:29 PM, Aaron Durbin  wrote:
>
>>
>>
>> On Wed, Feb 22, 2017 at 9:25 AM, Zoran Stojsavljevic <
>> zoran.stojsavlje...@gmail.com> wrote:
>>
>>> Not possible to share with you the details of my .config, until you
>>> understand that you need to investigate this problem as well. :-)
>>>
>>
>> I'm not sure I understand what you are saying. You are asking for help
>> but won't share more details? If that's the case, then good luck as I can't
>> be much help. You telling me to investigate something doesn't make me want
>> to continue helping in the slightest.
>>
>>
>>>
>>> CLI transcript follows:
>>>
>>> [user@localhost coreboot]$ pwd
>>> /home/user/projects/coreboot/coreboot
>>> [user@localhost coreboot]$ cat .config | grep FIRMWARE
>>> CONFIG_CPU_INTEL_FIRMWARE_INTERFACE_TABLE=y
>>> CONFIG_HAVE_INTEL_FIRMWARE=y
>>>
>>
>> Still not enough information.  Good luck with your problem.
>>
>>
>>> [user@localhost coreboot]$
>>> ___
>>>
>>> [user@localhost firmware]$ pwd
>>> /home/user/projects/coreboot/coreboot/src/southbridge/intel/
>>> common/firmware
>>> [user@localhost firmware]$ emacs Kconfig &
>>>
>>> Beginning of the file: Kconfig?
>>>
>>> *config HAVE_INTEL_FIRMWARE*
>>> * bool*
>>> * help*
>>> *  Chipset uses the Intel Firmware Descriptor to describe the*
>>> *  layout of the SPI ROM chip.*
>>>
>>> *if HAVE_INTEL_FIRMWARE*
>>>
>>> *comment "Intel Firmware"*
>>>
>>> *config HAVE_IFD_BIN*
>>>
>>> Zoran
>>>
>>> On Wed, Feb 22, 2017 at 4:13 PM, Aaron Durbin 
>>> wrote:
>>>


 On Wed, Feb 22, 2017 at 9:08 AM, Zoran Stojsavljevic <
 zoran.stojsavlje...@gmail.com> wrote:

> You mean, this one (in *RED*)?
>
> [user@localhost coreboot]$ cat .config | grep SPI
> CONFIG_BOOT_DEVICE_SPI_FLASH_BUS=0
> # CONFIG_TPM_ON_FAST_SPI is not set
> # CONFIG_SPI_FLASH_INCLUDE_ALL_DRIVERS is not set
> CONFIG_SOC_INTEL_COMMON_SPI_FLASH_PROTECT=y
> # CONFIG_BOOTBLOCK_DEBUG_SPINLOOP is not set
> # CONFIG_VERSTAGE_DEBUG_SPINLOOP is not set
> # CONFIG_ROMSTAGE_DEBUG_SPINLOOP is not set
> *CONFIG_SPI_FLASH=y*
> CONFIG_BOOT_DEVICE_SPI_FLASH_RW_NOMMAP=y
> CONFIG_BOOT_DEVICE_SPI_FLASH_RW_NOMMAP_EARLY=y
> # CONFIG_SPI_FLASH_SMM is not set
> # CONFIG_SPI_FLASH_NO_FAST_READ is not set
> # CONFIG_SPI_FLASH_FAST_READ_DUAL_OUTPUT_3B is not set
> # CONFIG_SPI_FLASH_HAS_VOLATILE_GROUP is not set
> # CONFIG_HAVE_SPI_CONSOLE_SUPPORT is not set
> # CONFIG_BOOT_DEVICE_NOT_SPI_FLASH is not set
> *CONFIG_BOOT_DEVICE_SPI_FLASH=y*
> # CONFIG_HAVE_ROMSTAGE_CONSOLE_SPINLOCK is not set
> # CONFIG_HAVE_ROMSTAGE_NVRAM_CBFS_SPINLOCK is not set
> # CONFIG_HAVE_ROMSTAGE_MICROCODE_CBFS_SPINLOCK is not set
> # CONFIG_DEBUG_SPI_FLASH is not set
> [user@localhost coreboot]$
> Which one (but, anyway, I think you are on the wrong mental tread,
> unless *you explicitly prove to me that I am wrong*)? [image: Inline
> image 1]
>
>
 Where are you setting the descriptor to use during the build? Those
 settings highlighted in red have nothing to do with the flash descriptor
 settings. Please look in src/southbridge/intel/common/firmware/Kconfig
 for that list. Also, without the full details of your config it's
 impossible to know what you are or aren't doing.



> Zoran
>
> On Wed, Feb 22, 2017 at 3:39 PM, Aaron Durbin 
> wrote:
>
>> On Wed, Feb 22, 2017 at 1:12 AM, 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 

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

[Zoran Stojsavljevic]

> Still not enough information.  Good luck with your problem.

I have no problem that you believe to INTEL IOTG 100x more than me. ;-)

Good luck to you, Google, with INTEL IOTG PED dept. problem (please, do not
input to me other people problems, could I ask?).

And, you need to work, and try to reproduce this problem, because I DO
(certainly) know that another people trying to build APL-I Coreboot have
this problem?! ;-)

Thank you,
Zoran

On Wed, Feb 22, 2017 at 4:29 PM, Aaron Durbin  wrote:

>
>
> On Wed, Feb 22, 2017 at 9:25 AM, Zoran Stojsavljevic <
> zoran.stojsavlje...@gmail.com> wrote:
>
>> Not possible to share with you the details of my .config, until you
>> understand that you need to investigate this problem as well. :-)
>>
>
> I'm not sure I understand what you are saying. You are asking for help but
> won't share more details? If that's the case, then good luck as I can't be
> much help. You telling me to investigate something doesn't make me want to
> continue helping in the slightest.
>
>
>>
>> CLI transcript follows:
>>
>> [user@localhost coreboot]$ pwd
>> /home/user/projects/coreboot/coreboot
>> [user@localhost coreboot]$ cat .config | grep FIRMWARE
>> CONFIG_CPU_INTEL_FIRMWARE_INTERFACE_TABLE=y
>> CONFIG_HAVE_INTEL_FIRMWARE=y
>>
>
> Still not enough information.  Good luck with your problem.
>
>
>> [user@localhost coreboot]$
>> ___
>>
>> [user@localhost firmware]$ pwd
>> /home/user/projects/coreboot/coreboot/src/southbridge/intel/
>> common/firmware
>> [user@localhost firmware]$ emacs Kconfig &
>>
>> Beginning of the file: Kconfig?
>>
>> *config HAVE_INTEL_FIRMWARE*
>> * bool*
>> * help*
>> *  Chipset uses the Intel Firmware Descriptor to describe the*
>> *  layout of the SPI ROM chip.*
>>
>> *if HAVE_INTEL_FIRMWARE*
>>
>> *comment "Intel Firmware"*
>>
>> *config HAVE_IFD_BIN*
>>
>> Zoran
>>
>> On Wed, Feb 22, 2017 at 4:13 PM, Aaron Durbin  wrote:
>>
>>>
>>>
>>> On Wed, Feb 22, 2017 at 9:08 AM, Zoran Stojsavljevic <
>>> zoran.stojsavlje...@gmail.com> wrote:
>>>
 You mean, this one (in *RED*)?

 [user@localhost coreboot]$ cat .config | grep SPI
 CONFIG_BOOT_DEVICE_SPI_FLASH_BUS=0
 # CONFIG_TPM_ON_FAST_SPI is not set
 # CONFIG_SPI_FLASH_INCLUDE_ALL_DRIVERS is not set
 CONFIG_SOC_INTEL_COMMON_SPI_FLASH_PROTECT=y
 # CONFIG_BOOTBLOCK_DEBUG_SPINLOOP is not set
 # CONFIG_VERSTAGE_DEBUG_SPINLOOP is not set
 # CONFIG_ROMSTAGE_DEBUG_SPINLOOP is not set
 *CONFIG_SPI_FLASH=y*
 CONFIG_BOOT_DEVICE_SPI_FLASH_RW_NOMMAP=y
 CONFIG_BOOT_DEVICE_SPI_FLASH_RW_NOMMAP_EARLY=y
 # CONFIG_SPI_FLASH_SMM is not set
 # CONFIG_SPI_FLASH_NO_FAST_READ is not set
 # CONFIG_SPI_FLASH_FAST_READ_DUAL_OUTPUT_3B is not set
 # CONFIG_SPI_FLASH_HAS_VOLATILE_GROUP is not set
 # CONFIG_HAVE_SPI_CONSOLE_SUPPORT is not set
 # CONFIG_BOOT_DEVICE_NOT_SPI_FLASH is not set
 *CONFIG_BOOT_DEVICE_SPI_FLASH=y*
 # CONFIG_HAVE_ROMSTAGE_CONSOLE_SPINLOCK is not set
 # CONFIG_HAVE_ROMSTAGE_NVRAM_CBFS_SPINLOCK is not set
 # CONFIG_HAVE_ROMSTAGE_MICROCODE_CBFS_SPINLOCK is not set
 # CONFIG_DEBUG_SPI_FLASH is not set
 [user@localhost coreboot]$
 Which one (but, anyway, I think you are on the wrong mental tread,
 unless *you explicitly prove to me that I am wrong*)? [image: Inline
 image 1]


>>> Where are you setting the descriptor to use during the build? Those
>>> settings highlighted in red have nothing to do with the flash descriptor
>>> settings. Please look in src/southbridge/intel/common/firmware/Kconfig
>>> for that list. Also, without the full details of your config it's
>>> impossible to know what you are or aren't doing.
>>>
>>>
>>>
 Zoran

 On Wed, Feb 22, 2017 at 3:39 PM, Aaron Durbin 
 wrote:

> On Wed, Feb 22, 2017 at 1:12 AM, 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
> > IFDTOOLUnlocking 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 

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

[Aaron Durbin via coreboot]

On Wed, Feb 22, 2017 at 9:25 AM, Zoran Stojsavljevic <
zoran.stojsavlje...@gmail.com> wrote:

> Not possible to share with you the details of my .config, until you
> understand that you need to investigate this problem as well. :-)
>

I'm not sure I understand what you are saying. You are asking for help but
won't share more details? If that's the case, then good luck as I can't be
much help. You telling me to investigate something doesn't make me want to
continue helping in the slightest.


>
> CLI transcript follows:
>
> [user@localhost coreboot]$ pwd
> /home/user/projects/coreboot/coreboot
> [user@localhost coreboot]$ cat .config | grep FIRMWARE
> CONFIG_CPU_INTEL_FIRMWARE_INTERFACE_TABLE=y
> CONFIG_HAVE_INTEL_FIRMWARE=y
>

Still not enough information.  Good luck with your problem.


> [user@localhost coreboot]$
> ___
>
> [user@localhost firmware]$ pwd
> /home/user/projects/coreboot/coreboot/src/southbridge/
> intel/common/firmware
> [user@localhost firmware]$ emacs Kconfig &
>
> Beginning of the file: Kconfig?
>
> *config HAVE_INTEL_FIRMWARE*
> * bool*
> * help*
> *  Chipset uses the Intel Firmware Descriptor to describe the*
> *  layout of the SPI ROM chip.*
>
> *if HAVE_INTEL_FIRMWARE*
>
> *comment "Intel Firmware"*
>
> *config HAVE_IFD_BIN*
>
> Zoran
>
> On Wed, Feb 22, 2017 at 4:13 PM, Aaron Durbin  wrote:
>
>>
>>
>> On Wed, Feb 22, 2017 at 9:08 AM, Zoran Stojsavljevic <
>> zoran.stojsavlje...@gmail.com> wrote:
>>
>>> You mean, this one (in *RED*)?
>>>
>>> [user@localhost coreboot]$ cat .config | grep SPI
>>> CONFIG_BOOT_DEVICE_SPI_FLASH_BUS=0
>>> # CONFIG_TPM_ON_FAST_SPI is not set
>>> # CONFIG_SPI_FLASH_INCLUDE_ALL_DRIVERS is not set
>>> CONFIG_SOC_INTEL_COMMON_SPI_FLASH_PROTECT=y
>>> # CONFIG_BOOTBLOCK_DEBUG_SPINLOOP is not set
>>> # CONFIG_VERSTAGE_DEBUG_SPINLOOP is not set
>>> # CONFIG_ROMSTAGE_DEBUG_SPINLOOP is not set
>>> *CONFIG_SPI_FLASH=y*
>>> CONFIG_BOOT_DEVICE_SPI_FLASH_RW_NOMMAP=y
>>> CONFIG_BOOT_DEVICE_SPI_FLASH_RW_NOMMAP_EARLY=y
>>> # CONFIG_SPI_FLASH_SMM is not set
>>> # CONFIG_SPI_FLASH_NO_FAST_READ is not set
>>> # CONFIG_SPI_FLASH_FAST_READ_DUAL_OUTPUT_3B is not set
>>> # CONFIG_SPI_FLASH_HAS_VOLATILE_GROUP is not set
>>> # CONFIG_HAVE_SPI_CONSOLE_SUPPORT is not set
>>> # CONFIG_BOOT_DEVICE_NOT_SPI_FLASH is not set
>>> *CONFIG_BOOT_DEVICE_SPI_FLASH=y*
>>> # CONFIG_HAVE_ROMSTAGE_CONSOLE_SPINLOCK is not set
>>> # CONFIG_HAVE_ROMSTAGE_NVRAM_CBFS_SPINLOCK is not set
>>> # CONFIG_HAVE_ROMSTAGE_MICROCODE_CBFS_SPINLOCK is not set
>>> # CONFIG_DEBUG_SPI_FLASH is not set
>>> [user@localhost coreboot]$
>>> Which one (but, anyway, I think you are on the wrong mental tread,
>>> unless *you explicitly prove to me that I am wrong*)? [image: Inline
>>> image 1]
>>>
>>>
>> Where are you setting the descriptor to use during the build? Those
>> settings highlighted in red have nothing to do with the flash descriptor
>> settings. Please look in src/southbridge/intel/common/firmware/Kconfig
>> for that list. Also, without the full details of your config it's
>> impossible to know what you are or aren't doing.
>>
>>
>>
>>> Zoran
>>>
>>> On Wed, Feb 22, 2017 at 3:39 PM, Aaron Durbin 
>>> wrote:
>>>
 On Wed, Feb 22, 2017 at 1:12 AM, 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
 > IFDTOOLUnlocking 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 *) 

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

[Zoran Stojsavljevic]

Not possible to share with you the details of my .config, until you
understand that you need to investigate this problem as well. :-)

CLI transcript follows:

[user@localhost coreboot]$ pwd
/home/user/projects/coreboot/coreboot
[user@localhost coreboot]$ cat .config | grep FIRMWARE
CONFIG_CPU_INTEL_FIRMWARE_INTERFACE_TABLE=y
CONFIG_HAVE_INTEL_FIRMWARE=y
[user@localhost coreboot]$
___

[user@localhost firmware]$ pwd
/home/user/projects/coreboot/coreboot/src/southbridge/intel/common/firmware
[user@localhost firmware]$ emacs Kconfig &

Beginning of the file: Kconfig?

*config HAVE_INTEL_FIRMWARE*
* bool*
* help*
*  Chipset uses the Intel Firmware Descriptor to describe the*
*  layout of the SPI ROM chip.*

*if HAVE_INTEL_FIRMWARE*

*comment "Intel Firmware"*

*config HAVE_IFD_BIN*

Zoran

On Wed, Feb 22, 2017 at 4:13 PM, Aaron Durbin  wrote:

>
>
> On Wed, Feb 22, 2017 at 9:08 AM, Zoran Stojsavljevic <
> zoran.stojsavlje...@gmail.com> wrote:
>
>> You mean, this one (in *RED*)?
>>
>> [user@localhost coreboot]$ cat .config | grep SPI
>> CONFIG_BOOT_DEVICE_SPI_FLASH_BUS=0
>> # CONFIG_TPM_ON_FAST_SPI is not set
>> # CONFIG_SPI_FLASH_INCLUDE_ALL_DRIVERS is not set
>> CONFIG_SOC_INTEL_COMMON_SPI_FLASH_PROTECT=y
>> # CONFIG_BOOTBLOCK_DEBUG_SPINLOOP is not set
>> # CONFIG_VERSTAGE_DEBUG_SPINLOOP is not set
>> # CONFIG_ROMSTAGE_DEBUG_SPINLOOP is not set
>> *CONFIG_SPI_FLASH=y*
>> CONFIG_BOOT_DEVICE_SPI_FLASH_RW_NOMMAP=y
>> CONFIG_BOOT_DEVICE_SPI_FLASH_RW_NOMMAP_EARLY=y
>> # CONFIG_SPI_FLASH_SMM is not set
>> # CONFIG_SPI_FLASH_NO_FAST_READ is not set
>> # CONFIG_SPI_FLASH_FAST_READ_DUAL_OUTPUT_3B is not set
>> # CONFIG_SPI_FLASH_HAS_VOLATILE_GROUP is not set
>> # CONFIG_HAVE_SPI_CONSOLE_SUPPORT is not set
>> # CONFIG_BOOT_DEVICE_NOT_SPI_FLASH is not set
>> *CONFIG_BOOT_DEVICE_SPI_FLASH=y*
>> # CONFIG_HAVE_ROMSTAGE_CONSOLE_SPINLOCK is not set
>> # CONFIG_HAVE_ROMSTAGE_NVRAM_CBFS_SPINLOCK is not set
>> # CONFIG_HAVE_ROMSTAGE_MICROCODE_CBFS_SPINLOCK is not set
>> # CONFIG_DEBUG_SPI_FLASH is not set
>> [user@localhost coreboot]$
>> Which one (but, anyway, I think you are on the wrong mental tread, unless 
>> *you
>> explicitly prove to me that I am wrong*)? [image: Inline image 1]
>>
>>
> Where are you setting the descriptor to use during the build? Those
> settings highlighted in red have nothing to do with the flash descriptor
> settings. Please look in src/southbridge/intel/common/firmware/Kconfig
> for that list. Also, without the full details of your config it's
> impossible to know what you are or aren't doing.
>
>
>
>> Zoran
>>
>> On Wed, Feb 22, 2017 at 3:39 PM, Aaron Durbin  wrote:
>>
>>> On Wed, Feb 22, 2017 at 1:12 AM, 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
>>> > IFDTOOLUnlocking 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).
>>>
>>> So this device isn't supporting SPI boot? If so, then it's not
>>> surprise that there's no SPI descriptor. And you didn't add one it
>>> seems.
>>> >
>>> > Then, modifying the C f-n static fdbar_t *find_fd(char *image, int
>>> size),
>>> > finally I've got success! :-(
>>> >
>>> > Hello Martin,
>>> >
>>> > Thank you for 

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

[Aaron Durbin via coreboot]

On Wed, Feb 22, 2017 at 9:08 AM, Zoran Stojsavljevic <
zoran.stojsavlje...@gmail.com> wrote:

> You mean, this one (in *RED*)?
>
> [user@localhost coreboot]$ cat .config | grep SPI
> CONFIG_BOOT_DEVICE_SPI_FLASH_BUS=0
> # CONFIG_TPM_ON_FAST_SPI is not set
> # CONFIG_SPI_FLASH_INCLUDE_ALL_DRIVERS is not set
> CONFIG_SOC_INTEL_COMMON_SPI_FLASH_PROTECT=y
> # CONFIG_BOOTBLOCK_DEBUG_SPINLOOP is not set
> # CONFIG_VERSTAGE_DEBUG_SPINLOOP is not set
> # CONFIG_ROMSTAGE_DEBUG_SPINLOOP is not set
> *CONFIG_SPI_FLASH=y*
> CONFIG_BOOT_DEVICE_SPI_FLASH_RW_NOMMAP=y
> CONFIG_BOOT_DEVICE_SPI_FLASH_RW_NOMMAP_EARLY=y
> # CONFIG_SPI_FLASH_SMM is not set
> # CONFIG_SPI_FLASH_NO_FAST_READ is not set
> # CONFIG_SPI_FLASH_FAST_READ_DUAL_OUTPUT_3B is not set
> # CONFIG_SPI_FLASH_HAS_VOLATILE_GROUP is not set
> # CONFIG_HAVE_SPI_CONSOLE_SUPPORT is not set
> # CONFIG_BOOT_DEVICE_NOT_SPI_FLASH is not set
> *CONFIG_BOOT_DEVICE_SPI_FLASH=y*
> # CONFIG_HAVE_ROMSTAGE_CONSOLE_SPINLOCK is not set
> # CONFIG_HAVE_ROMSTAGE_NVRAM_CBFS_SPINLOCK is not set
> # CONFIG_HAVE_ROMSTAGE_MICROCODE_CBFS_SPINLOCK is not set
> # CONFIG_DEBUG_SPI_FLASH is not set
> [user@localhost coreboot]$
> Which one (but, anyway, I think you are on the wrong mental tread, unless *you
> explicitly prove to me that I am wrong*)? [image: Inline image 1]
>
>
Where are you setting the descriptor to use during the build? Those
settings highlighted in red have nothing to do with the flash descriptor
settings. Please look in src/southbridge/intel/common/firmware/Kconfig for
that list. Also, without the full details of your config it's impossible to
know what you are or aren't doing.



> Zoran
>
> On Wed, Feb 22, 2017 at 3:39 PM, Aaron Durbin  wrote:
>
>> On Wed, Feb 22, 2017 at 1:12 AM, 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
>> > IFDTOOLUnlocking 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).
>>
>> So this device isn't supporting SPI boot? If so, then it's not
>> surprise that there's no SPI descriptor. And you didn't add one it
>> seems.
>> >
>> > Then, modifying the C f-n static fdbar_t *find_fd(char *image, int
>> size),
>> > finally I've got success! :-(
>> >
>> > Hello Martin,
>> >
>> > Thank you for unselfish help.
>> >
>> > Best Regards,
>> > Zoran Stojsavljevic
>> >
>> >
>> > --
>> > 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

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

[Zoran Stojsavljevic]

You mean, this one (in *RED*)?

[user@localhost coreboot]$ cat .config | grep SPI
CONFIG_BOOT_DEVICE_SPI_FLASH_BUS=0
# CONFIG_TPM_ON_FAST_SPI is not set
# CONFIG_SPI_FLASH_INCLUDE_ALL_DRIVERS is not set
CONFIG_SOC_INTEL_COMMON_SPI_FLASH_PROTECT=y
# CONFIG_BOOTBLOCK_DEBUG_SPINLOOP is not set
# CONFIG_VERSTAGE_DEBUG_SPINLOOP is not set
# CONFIG_ROMSTAGE_DEBUG_SPINLOOP is not set
*CONFIG_SPI_FLASH=y*
CONFIG_BOOT_DEVICE_SPI_FLASH_RW_NOMMAP=y
CONFIG_BOOT_DEVICE_SPI_FLASH_RW_NOMMAP_EARLY=y
# CONFIG_SPI_FLASH_SMM is not set
# CONFIG_SPI_FLASH_NO_FAST_READ is not set
# CONFIG_SPI_FLASH_FAST_READ_DUAL_OUTPUT_3B is not set
# CONFIG_SPI_FLASH_HAS_VOLATILE_GROUP is not set
# CONFIG_HAVE_SPI_CONSOLE_SUPPORT is not set
# CONFIG_BOOT_DEVICE_NOT_SPI_FLASH is not set
*CONFIG_BOOT_DEVICE_SPI_FLASH=y*
# CONFIG_HAVE_ROMSTAGE_CONSOLE_SPINLOCK is not set
# CONFIG_HAVE_ROMSTAGE_NVRAM_CBFS_SPINLOCK is not set
# CONFIG_HAVE_ROMSTAGE_MICROCODE_CBFS_SPINLOCK is not set
# CONFIG_DEBUG_SPI_FLASH is not set
[user@localhost coreboot]$
Which one (but, anyway, I think you are on the wrong mental tread, unless *you
explicitly prove to me that I am wrong*)? [image: Inline image 1]

Zoran

On Wed, Feb 22, 2017 at 3:39 PM, Aaron Durbin  wrote:

> On Wed, Feb 22, 2017 at 1:12 AM, 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
> > IFDTOOLUnlocking 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).
>
> So this device isn't supporting SPI boot? If so, then it's not
> surprise that there's no SPI descriptor. And you didn't add one it
> seems.
> >
> > Then, modifying the C f-n static fdbar_t *find_fd(char *image, int size),
> > finally I've got success! :-(
> >
> > Hello Martin,
> >
> > Thank you for unselfish help.
> >
> > Best Regards,
> > Zoran Stojsavljevic
> >
> >
> > --
> > 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

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

[Aaron Durbin via coreboot]

On Wed, Feb 22, 2017 at 1:12 AM, 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
> IFDTOOLUnlocking 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).

So this device isn't supporting SPI boot? If so, then it's not
surprise that there's no SPI descriptor. And you didn't add one it
seems.
>
> Then, modifying the C f-n static fdbar_t *find_fd(char *image, int size),
> finally I've got success! :-(
>
> Hello Martin,
>
> Thank you for unselfish help.
>
> Best Regards,
> Zoran Stojsavljevic
>
>
> --
> 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

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

[Zoran Stojsavljevic]

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
IFDTOOLUnlocking 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).

Then, modifying the C f-n static fdbar_t *find_fd(char *image, int size),
finally I've got success! :-(

Hello Martin,

Thank you for unselfish help.

Best Regards,
Zoran Stojsavljevic
-- 
coreboot mailing list: coreboot@coreboot.org
https://www.coreboot.org/mailman/listinfo/coreboot