Re: [coreboot] Lenovo T420 Question

[i1w5d7gf38keg]

Could you try out "Thermal Grizzly Kryonaut" or even liquid metal based 
products and report about the temperatures? It would be great if you could try 
out first the Thermal Grizzly Kryonaut and later then for example the Thermal 
Grizzly Conductonaut and report here.
http://www.overclock.net/t/1588116/thermal-grizzly-conductonaut-73-w-mk

Please clean up the surface before applying when possible with 
https://en.wikipedia.org/wiki/Isopropyl_alcohol (its cheap and easy to get).

23. Feb 2017 01:28 by coreb...@semioptimal.net:


> Hi
>>
>> Untested/unknown: If a ivy bridge CPU would work. The OEM bios didn't had 
>> support for those.
>
> Ivy Bridge works, have a 3740QM in mine. However, (quoting myself here):
>>
>> I'm running one albeit with an i7-3740qm - which is too much thermal load, 
>> runs up to 2.9 GHz for me reaching 93°C (70K to ambient) with fan set to 
>> disengaged, normal auto fan control works and allows up to 2.5 GHz.
>>
>> with that CPU RAPL does not work, thermald does but out-of-the-box settings 
>> gives me less performance than with fix limits, and I'm sure as hell not 
>> going to configure something with an xml config file.
>>
>> used to have a 2720m which worked without any issues AFAIR, but the 3740qm 
>> effectively gives me double the cores that are a little faster.
>
> Regards, Arian-- 
coreboot mailing list: coreboot@coreboot.org
https://www.coreboot.org/mailman/listinfo/coreboot

[coreboot] The fastest possible intel free-as-in-freedom pattform not supported now?

[i1w5d7gf38keg]

As we know, since Intel have changed from ICH to PCH we can not fully disable 
ME any more (at the moment, lets see how far leah gets with the x220).

After checking the different platforms i find out, that the Intel LGA 1366 
platform can be used!
This platform still use ICH and not PCH.

https://en.wikipedia.org/wiki/LGA_1366
https://en.wikipedia.org/wiki/Intel_X58

Later platforms (LGA 2011, LGA 1356, LGA 1155, ...) are PCH based.

The LGA 1366 (Intel X58) supports great six-core CPUs with 32nm like for 
example the Core i7-990X (6x 3,47ghz, 12MB L3 cache). Also Xeon X5690 would be 
great (probably same CPU like the i7-990X.


An other probably FLOSS-possible and even faster platform could be the LGA 
1567. This is some kind of a rare platform based on the the LGA 1366 but is 
been redesigned to support brutally fast CPUs like for example the 10 core (20 
threads) Xeon E7-2870 / E7-4870 / E7-8870 CPUs.
https://en.wikipedia.org/wiki/Westmere_%28microarchitecture%29
https://en.wikipedia.org/wiki/LGA_1567
-- 
coreboot mailing list: coreboot@coreboot.org
https://www.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] Lenovo T420 Question

[arian]

Hi
> 
> Untested/unknown: If a ivy bridge CPU would work. The OEM bios didn't had 
> support for those.

Ivy Bridge works, have a 3740QM in mine. However, (quoting myself here):
> 
> I'm running one albeit with an i7-3740qm - which is too much thermal load, 
> runs up to 2.9 GHz for me reaching 93°C (70K to ambient) with fan set to 
> disengaged, normal auto fan control works and allows up to 2.5 GHz.
> 
> with that CPU RAPL does not work, thermald does but out-of-the-box settings 
> gives me less performance than with fix limits, and I'm sure as hell not 
> going to configure something with an xml config file.
> 
> used to have a 2720m which worked without any issues AFAIR, but the 3740qm 
> effectively gives me double the cores that are a little faster.

Regards, Arian



signature.asc
Description: OpenPGP digital signature
-- 
coreboot mailing list: coreboot@coreboot.org
https://www.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] T520 2630QM 16GB DIMM

[i1w5d7gf38keg]

You can buy for example a ivy bridge Thinkpad W530 with 32GB of RAM already 
installed from here:

www.ebay.com/itm/122338642287


23. Feb 2017 01:00 by mytbk920...@gmail.com:


> Ivy Bridge doesn't support 16GB DIMMs either. I've opened a ticket before.
> https://ticket.coreboot.org/issues/56
> On Thu, Feb 23, 2017 at 8:33 AM,  <> i1w5d7gf38...@tutanota.com> > wrote:
>
>>   >> It would be really great if you could test out a Core i7-3840QM 
>> in the G2 socket of the Thinkpad T520. Its the best ivy bridge with 45W TDP 
>> and the Core i7-3840QM officialy support 32GB of RAM.
>>
>> The Lenovo OEM Bios wont support ivy bridge. Coreboot didnt have such 
>> limitations ;)
>>
>> Thanks!
>>
>> 21. Feb 2017 22:08 by >> coreb...@tricnet.de>> :
>>
>>
>>> Hi Arthur,Zitat von Arthur Heymans <>>> arthur at aheymans.xyz>>> >:  
>>> Thomas Richter <>>> coreboot at tricnet.de>>> > writes:>>> >  Is Sandy 
>>> Bridge E so different from Sandy Bridge? Would it be possible>>>    
>>> Sandy Bridge E are high end desktop/server CPUs that have a different>>> 
>>>   socket (lga2011) and likely a different memory controller (4 
>>> channels>>>   instead of 2).>>>   A quick look at datasheet says 
>>> nothing about maximum rank size.>>> I see.>  to replace the 2620QM with 
>>> an Ivy Bridge CPU?>>>    Afaik that should be possible since the 
>>> CPU is socketed on that model>>>   but won't overcome your issue. (same 
>>> limitation)>>> Thank your for your time to explain. Seems like I have to 
>>> look for a  new laptop then ;-).It was a fun project, I learned a lot and 
>>> I'm really impressed by the  usability. Will definitely keep coreboot on 
>>> the t520!Best,Thomas
>>   
>> --
>> coreboot mailing list: >> coreboot@coreboot.org
>> https://www.coreboot.org/mailman/listinfo/coreboot
>>
>
>
>
> -- 
> Please do not send me Microsoft Office/Apple iWork documents. Send 
> OpenDocument instead! > http://fsf.org/campaigns/opendocument/-- 
coreboot mailing list: coreboot@coreboot.org
https://www.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] T520 2630QM 16GB DIMM

[Iru Cai]

Ivy Bridge doesn't support 16GB DIMMs either. I've opened a ticket before.
https://ticket.coreboot.org/issues/56

On Thu, Feb 23, 2017 at 8:33 AM,  wrote:

> It would be really great if you could test out a Core i7-3840QM in the G2
> socket of the Thinkpad T520. Its the best ivy bridge with 45W TDP and the
> Core i7-3840QM officialy support 32GB of RAM.
>
> The Lenovo OEM Bios wont support ivy bridge. Coreboot didnt have such
> limitations ;)
>
> Thanks!
>
> 21. Feb 2017 22:08 by coreb...@tricnet.de
> 
> :
>
> Hi Arthur,
>
> Zitat von Arthur Heymans  >:
>
> >* Thomas Richter  >> writes:
> *>>* Is Sandy Bridge E so different from Sandy Bridge? Would it be possible
> *>>* Sandy Bridge E are high end desktop/server CPUs that have a different
> *>* socket (lga2011) and likely a different memory controller (4 channels
> *>* instead of 2).
> *>* A quick look at datasheet says nothing about maximum rank size.
> *
> I see.
>
> >>* to replace the 2620QM with an Ivy Bridge CPU?
> *>>* Afaik that should be possible since the CPU is socketed on that model
> *>* but won't overcome your issue. (same limitation)
> *
> Thank your for your time to explain. Seems like I have to look for a
> new laptop then ;-).
>
> It was a fun project, I learned a lot and I'm really impressed by the
> usability. Will definitely keep coreboot on the t520!
>
> Best,
>
> Thomas
>
>
> --
> coreboot mailing list: coreboot@coreboot.org
> https://www.coreboot.org/mailman/listinfo/coreboot
>



-- 
Please do not send me Microsoft Office/Apple iWork documents. Send
OpenDocument instead! http://fsf.org/campaigns/opendocument/
-- 
coreboot mailing list: coreboot@coreboot.org
https://www.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] Libreboot X220 pre-order from Minifree - libre firmware preinstalled

[Peter Stuge]

taii...@gmx.com wrote:
> The 30 minute thing begs the question of why does intel care so much 
> about making sure people have ME functional?

It's part of the platform.


> It makes no sense to me.

I recommend reading the Platform Embedded Security Technology Revealed
book, ISBN 9781430265719.


//Peter

-- 
coreboot mailing list: coreboot@coreboot.org
https://www.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] T520 2630QM 16GB DIMM

[i1w5d7gf38keg]

It would be really great if you could test out a Core i7-3840QM in the G2 
socket of the Thinkpad T520. Its the best ivy bridge with 45W TDP and the Core 
i7-3840QM officialy support 32GB of RAM.

The Lenovo OEM Bios wont support ivy bridge. Coreboot didnt have such 
limitations ;)

Thanks!

21. Feb 2017 22:08 by coreb...@tricnet.de:


> Hi Arthur,Zitat von Arthur Heymans <> arthur at aheymans.xyz> >:>>  Thomas 
> Richter <> coreboot at tricnet.de> > writes:> >>>  Is Sandy Bridge E so 
> different from Sandy Bridge? Would it be possible> >> >>  Sandy Bridge E are 
> high end desktop/server CPUs that have a different> >>  socket (lga2011) and 
> likely a different memory controller (4 channels> >>  instead of 2).> >>  A 
> quick look at datasheet says nothing about maximum rank size.> I see.>>>  to 
> replace the 2620QM with an Ivy Bridge CPU?> >> >>  Afaik that should be 
> possible since the CPU is socketed on that model> >>  but won't overcome your 
> issue. (same limitation)> Thank your for your time to explain. Seems like I 
> have to look for a  new laptop then ;-).It was a fun project, I learned a lot 
> and I'm really impressed by the  usability. Will definitely keep coreboot on 
> the t520!Best,Thomas-- 
coreboot mailing list: coreboot@coreboot.org
https://www.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] Lenovo T420 Question

[i1w5d7gf38keg]

You can install a quadcore. 2720QM is been tested working. 
http://forum.notebookreview.com/threads/t420-upgrade-to-i7-2720qm-es-q154-successful.624256

The probably fastest CPU that the T420 could get cooled is the Core i7-2860QM 
(45W TDP). 

Official dualcore CPUs have a TDP of 35W.
Those inofficial working quadcore CPUs have a TDP of 45W. 
The minimal requirement to get those quadcore CPUs working is to apply the very 
best thermal paste you can get for money. At the moment this is the "Thermal 
Grizzly Kryonaut". Otherwise your CPU would start overheating and throttling 
when you use for example a old and inefficient Arctic Silver 5.

Untested/unknown: If a ivy bridge CPU would work. The OEM bios didn't had 
support for those.


5. Feb 2017 18:33 by davidthornes at outlook.com   :


> Hello All, I have a question for people running coreboot on T420Can you 
> please suggest the fastest CPU i can upgrade to without too many heat issues 
> ?i can use more powerful ( 90W  i think ) power brick if needed ..thank you 
> everyone.David.-- 
coreboot mailing list: coreboot@coreboot.org
https://www.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] Dont filter supported CPUs on a mainboard by the CPUID

[Timothy Pearson]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 02/22/2017 05:49 PM, i1w5d7gf38...@tutanota.com wrote:
>  Thanks for the information. Then maybe just dont stop booting when
> CPUID is missing. Just add a line to the coreboot log. Something like:
> "WARNING: Unknown CPU ID detected. Please report to the coreboot mailing
> lists if the machine is working fine"
> 
> Then you still have the same functionality as you told. CPUs that
> require different handling on different revisions can still be
> maintained different.
> 
> People are also way more motivated to report some unstable working CPUs
> then when they flash coreboot and the system simply didnt work at all
> and without reading the logfiles it looks like its completely dead (no
> screen, nothing, just fans are on).

And with that, I'll turn this over for the other members on the list to
comment on this suggestion.  I don't care strongly one way or another,
provided the warning is at ALERT status so it shows up even with logging
mostly disabled.

- -- 
Timothy Pearson
Raptor Engineering
+1 (415) 727-8645 (direct line)
+1 (512) 690-0200 (switchboard)
https://www.raptorengineering.com
-BEGIN PGP SIGNATURE-
Version: GnuPG v1
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iQEcBAEBAgAGBQJYriQiAAoJEK+E3vEXDOFbKWcIAIQgDNEdbmh3nTy5rleMlakF
0kph3iwnvAXWynNq8hPu+4iHqbHWpPgUF9GFJly0O3P2gQ23Buo0slLPd6Eq7Xra
fDxHZQWegWM07NPOLi94wtDe0KRMMPmr2M8b4ZVyyIPeRTPW4Dw2UpK4sAbUWaiu
H30Jzb4EaUOjMYo1j9bqn9Mf0mclgbnsLCkDLUnN9f/Va98a+m9KvQ55AwIkn3SX
PReHQ273RRQMIYgCm0qwyySeUovxGWO4bKkViuGE4NkqkA+yXKpPsdMMsw7oTMpY
N4MfISLexn2ZeBR2kxW5gPqoL4gr3ofnivVqLfaKmd2SWMeeua+mXB4EFKurUyk=
=B4xv
-END PGP SIGNATURE-

-- 
coreboot mailing list: coreboot@coreboot.org
https://www.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] Dont filter supported CPUs on a mainboard by the CPUID

[i1w5d7gf38keg]

Thanks for the information. Then maybe just dont stop booting when CPUID is 
missing. Just add a line to the coreboot log. Something like: "WARNING: Unknown 
CPU ID detected. Please report to the coreboot mailing lists if the machine is 
working fine"

Then you still have the same functionality as you told. CPUs that require 
different handling on different revisions can still be maintained different.

People are also way more motivated to report some unstable working CPUs then 
when they flash coreboot and the system simply didnt work at all and without 
reading the logfiles it looks like its completely dead (no screen, nothing, 
just fans are on).

22. Feb 2017 23:35 by tpear...@raptorengineering.com:


> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> On 02/22/2017 05:31 PM, > i1w5d7gf38...@tutanota.com>  wrote:
>>  What is the benefit of such a list? I cant see any benefit. Its only
>> additional work that is useless.
>
> Example: Certain CPUs require special cache handling / setup to avoid
> unusual faults or security vulnerabilities at runtime.  The original
> setup code properly configures model 1 stepping 1 CPUs, but stepping 2
> CPUs require special setup.  User installs coreboot and uses it with a
> stepping 2 CPU without adding in the new setup code -- it seems to run,
> but crashes every once in a while.  User (possibly) figures out coreboot
> is the problem and is very unhappy.
>
> Again, this is very low level stuff; mistakes do not always show up as
> "failure to boot".  If you want to verify your CPUs and add them to the
> list please do so!
>
> - -- 
> Timothy Pearson
> Raptor Engineering
> +1 (415) 727-8645 (direct line)
> +1 (512) 690-0200 (switchboard)
> https://www.raptorengineering.com
> -BEGIN PGP SIGNATURE-
> Version: GnuPG v1
> Comment: Using GnuPG with Mozilla - > http://enigmail.mozdev.org
>
> iQEcBAEBAgAGBQJYriA+AAoJEK+E3vEXDOFbHt4H/ikXwMUu+XJ7cDsb8fx6ivcZ
> RjyiNL3i7hIjIUYRxRbWcKau7FelLVypYtvLAnxqqDgSdZRfR+/oLrfFYpjAEXRG
> A/d9eGq6HPKkF/HmxxkpY4RPLQEB4y85u1vheFXJnmg2AEdtaXG0iAlerPw5qZDL
> bi20R4CQqyT6JL7vRLBawRiozZSpWHUllhbPq1XO2vgRohk78Lb9LlXSOWxBKHlL
> obSL71Q46KJsKIQ3ovWfKgj1Pz+VA/+qhlXsFGp7S9NkHrAXFKPofBTLP4zzz/Nm
> KqUWVn7ehCWFtsdt1rZqNWGtG9xgkPpe90V2f90BfsXJ9xhSVCVMud0EHsqDM6A=
> =tl55
> -END PGP SIGNATURE-
>
> -- 
> 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] Dont filter supported CPUs on a mainboard by the CPUID

[Timothy Pearson]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 02/22/2017 05:31 PM, i1w5d7gf38...@tutanota.com wrote:
>  What is the benefit of such a list? I cant see any benefit. Its only
> additional work that is useless.

Example: Certain CPUs require special cache handling / setup to avoid
unusual faults or security vulnerabilities at runtime.  The original
setup code properly configures model 1 stepping 1 CPUs, but stepping 2
CPUs require special setup.  User installs coreboot and uses it with a
stepping 2 CPU without adding in the new setup code -- it seems to run,
but crashes every once in a while.  User (possibly) figures out coreboot
is the problem and is very unhappy.

Again, this is very low level stuff; mistakes do not always show up as
"failure to boot".  If you want to verify your CPUs and add them to the
list please do so!

- -- 
Timothy Pearson
Raptor Engineering
+1 (415) 727-8645 (direct line)
+1 (512) 690-0200 (switchboard)
https://www.raptorengineering.com
-BEGIN PGP SIGNATURE-
Version: GnuPG v1
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iQEcBAEBAgAGBQJYriA+AAoJEK+E3vEXDOFbHt4H/ikXwMUu+XJ7cDsb8fx6ivcZ
RjyiNL3i7hIjIUYRxRbWcKau7FelLVypYtvLAnxqqDgSdZRfR+/oLrfFYpjAEXRG
A/d9eGq6HPKkF/HmxxkpY4RPLQEB4y85u1vheFXJnmg2AEdtaXG0iAlerPw5qZDL
bi20R4CQqyT6JL7vRLBawRiozZSpWHUllhbPq1XO2vgRohk78Lb9LlXSOWxBKHlL
obSL71Q46KJsKIQ3ovWfKgj1Pz+VA/+qhlXsFGp7S9NkHrAXFKPofBTLP4zzz/Nm
KqUWVn7ehCWFtsdt1rZqNWGtG9xgkPpe90V2f90BfsXJ9xhSVCVMud0EHsqDM6A=
=tl55
-END PGP SIGNATURE-

-- 
coreboot mailing list: coreboot@coreboot.org
https://www.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] Dont filter supported CPUs on a mainboard by the CPUID

[i1w5d7gf38keg]

What is the benefit of such a list? I cant see any benefit. Its only additional 
work that is useless.

A example for CPUID-List blocking functionality is commit 
I63d308477a22a9e55ceed1b6b36e63a3044c2354


22. Feb 2017 23:15 by tpear...@raptorengineering.com:


> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> On 02/22/2017 05:07 PM, > i1w5d7gf38...@tutanota.com>  wrote:
>>  There is a Filter to stop booting when the CPUID is not in a list of
>> supported CPUs. This filter does not make sense in the real world usage.
>> For example socket 775:
>> When you enter a working cpu, then it boots.  In some cases the coreboot
>> code didnt work with a CPU where it should. For example some Pentium-4
>> CPUs. Then it crashes even before raminit.
>> But when you add a CPU that "would" work but is not listed in the CPUID
>> lists from coreboot, the machine didnt boot. If you simply add the CPUID
>> to the list everything works fine.
>>
>> In short: The only thing this CPUID list is doing is blocking
>> functionality and adding work (a list that have to be maintained).
>> Nothing else. If a CPU is not supported, it crashes after 4-5 lines of
>> logfile - even before the raminit. Thats before this CPUID list is been
>> checked.
>>
>> Please remove those CPUID lists.
>>
>
> I would recommend the lists be retained.  Presumably the individual(s)
> that wrote the CPU / northbridge support code are aware of the CPUs that
> the code is designed to work with, and using CPUs that were never
> intended with that code does entail a certain amount of risk.
> Individuals capable of mitigating this risk / verifying processor
> functionality are also capable of modifying the CPUID list.
>
> - -- 
> Timothy Pearson
> Raptor Engineering
> +1 (415) 727-8645 (direct line)
> +1 (512) 690-0200 (switchboard)
> https://www.raptorengineering.com
> -BEGIN PGP SIGNATURE-
> Version: GnuPG v1
> Comment: Using GnuPG with Mozilla - > http://enigmail.mozdev.org
>
> iQEcBAEBAgAGBQJYrht0AAoJEK+E3vEXDOFb/S0H/17w88+kNxBcPm+V+hPkpMDE
> r6FcyfSO4tm96b/lPgkhK78jxqighQHD7sR2keFWAO+5hwRQfuZwHYVsPa1WmrUN
> u3J08Mgl5r/xTyoBEp/CRxAGD5FaN+NOYQgBVFh8J6IGLBeYJxcmv/PdQmctvi+J
> lXuqepsei5TLDIn+9hE3U2Dbh0H/6m8+YFFRbeYbcoNfyuRFE5APks3s+QOjqa4w
> wBR30fafSBkj4DyGMSzD5yZbOLl/SJDhT1FjvWlx5H4YwKv/vltAPYhq1enaJkRf
> 61cpl2Prfin4DvpWGU/geTi94bskBo8D8sE1SHumoGXIQ+maICPh/ndtIRNUJIQ=
> =UsCc
> -END PGP SIGNATURE--- 
coreboot mailing list: coreboot@coreboot.org
https://www.coreboot.org/mailman/listinfo/coreboot

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] Dont filter supported CPUs on a mainboard by the CPUID

[Timothy Pearson]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 02/22/2017 05:07 PM, i1w5d7gf38...@tutanota.com wrote:
>  There is a Filter to stop booting when the CPUID is not in a list of
> supported CPUs. This filter does not make sense in the real world usage.
> For example socket 775:
> When you enter a working cpu, then it boots.  In some cases the coreboot
> code didnt work with a CPU where it should. For example some Pentium-4
> CPUs. Then it crashes even before raminit.
> But when you add a CPU that "would" work but is not listed in the CPUID
> lists from coreboot, the machine didnt boot. If you simply add the CPUID
> to the list everything works fine.
> 
> In short: The only thing this CPUID list is doing is blocking
> functionality and adding work (a list that have to be maintained).
> Nothing else. If a CPU is not supported, it crashes after 4-5 lines of
> logfile - even before the raminit. Thats before this CPUID list is been
> checked.
> 
> Please remove those CPUID lists.
> 

I would recommend the lists be retained.  Presumably the individual(s)
that wrote the CPU / northbridge support code are aware of the CPUs that
the code is designed to work with, and using CPUs that were never
intended with that code does entail a certain amount of risk.
Individuals capable of mitigating this risk / verifying processor
functionality are also capable of modifying the CPUID list.

- -- 
Timothy Pearson
Raptor Engineering
+1 (415) 727-8645 (direct line)
+1 (512) 690-0200 (switchboard)
https://www.raptorengineering.com
-BEGIN PGP SIGNATURE-
Version: GnuPG v1
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iQEcBAEBAgAGBQJYrht0AAoJEK+E3vEXDOFb/S0H/17w88+kNxBcPm+V+hPkpMDE
r6FcyfSO4tm96b/lPgkhK78jxqighQHD7sR2keFWAO+5hwRQfuZwHYVsPa1WmrUN
u3J08Mgl5r/xTyoBEp/CRxAGD5FaN+NOYQgBVFh8J6IGLBeYJxcmv/PdQmctvi+J
lXuqepsei5TLDIn+9hE3U2Dbh0H/6m8+YFFRbeYbcoNfyuRFE5APks3s+QOjqa4w
wBR30fafSBkj4DyGMSzD5yZbOLl/SJDhT1FjvWlx5H4YwKv/vltAPYhq1enaJkRf
61cpl2Prfin4DvpWGU/geTi94bskBo8D8sE1SHumoGXIQ+maICPh/ndtIRNUJIQ=
=UsCc
-END PGP SIGNATURE-

-- 
coreboot mailing list: coreboot@coreboot.org
https://www.coreboot.org/mailman/listinfo/coreboot

[coreboot] Dont filter supported CPUs on a mainboard by the CPUID

[i1w5d7gf38keg]

There is a Filter to stop booting when the CPUID is not in a list of supported 
CPUs. This filter does not make sense in the real world usage.
For example socket 775:
When you enter a working cpu, then it boots.  In some cases the coreboot code 
didnt work with a CPU where it should. For example some Pentium-4 CPUs. Then it 
crashes even before raminit.
But when you add a CPU that "would" work but is not listed in the CPUID lists 
from coreboot, the machine didnt boot. If you simply add the CPUID to the list 
everything works fine.

In short: The only thing this CPUID list is doing is blocking functionality and 
adding work (a list that have to be maintained). Nothing else. If a CPU is not 
supported, it crashes after 4-5 lines of logfile - even before the raminit. 
Thats before this CPUID list is been checked.

Please remove those CPUID lists.
-- 
coreboot mailing list: coreboot@coreboot.org
https://www.coreboot.org/mailman/listinfo/coreboot

[coreboot] New on blogs.coreboot.org: coreboot is joining the Software Freedom Conservancy

[WordPress]

A new post titled "coreboot is joining the Software Freedom Conservancy" has been published on the coreboot blog. Find the full post at http://blogs.coreboot.org/blog/2017/02/22/coreboot-is-joining-the-software-freedom-conservancy/

The coreboot project applied to join the Software Freedom Conservancy and has been approved for membership by their board.  There is still some work to be done in hammering out the governance details, but we hope to have everything completed by April.
Joining the SFC as coreboot’s fiscal sponsor will allow us to go forward with fundraising, and that all donations to the coreboot project from the United States will be tax-deductible.  Up to this point, coreboot hasn’t had any official way to accept donations or payments.  This has meant that the project was mainly supported financially by members of the coreboot leadership, which has put some limitations on what we were able to do.
Another of the things that joining the SFC means is that we will be formalizing and fully documenting the coreboot leadership structure.  This is one of the Conservancy’s requirements, and something that they will help the project with.
The Conservancy offers a number of other services to its members. We encourage everyone to take a look at the SFC, and to consider joining as individual supporters.


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

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