coreboot February 2017

coreboot@coreboot.org

66 participants
212 discussions

Libreboot X220 pre-order from Minifree - libre firmware preinstalled
by Leah Rowe 23 Feb '17

23 Feb '17

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Hi all, Minifree has launched a new freedom-friendly laptop, with the free and open source Libreboot BIOS replacement, and Debian GNU+Linux preinstalled. This is the first modern laptop available with entirely libre software at every level, with no backdoors or rootkits like with the larger companies, and it's available on pre-order today. This is good for security-conscious people who believe in Free Software, and want a system that they can trust. This includes businesses, professionals, governments and any other application where data privacy is a must. It's also good generally for those who wish to use a system that respects their freedom. Here it is (more information is on the page): https://minifree.org/product/libreboot-x220/ This has positive implications for security in terms of auditability, and therefore privacy in general (no backdoors!). It's also free software friendly, so there are zero binary blobs and zero proprietary software running on it in the OS or BIOS. You have all of the four freedoms over each part of the boot process, which means that you the user are in full control. For the first time ever, it is possible for companies to use libreboot-enabled hardware. The Libreboot X220 is an upgrade from the existing Libreboot X200 that was sold previously. Here are just some of the improvements with the X22 0: * Has a touchpad and trackpoint mouse pointer. The X200 only had the trackpoint * Higher battery life * SATA III support (6Gbps possible on SSD. The X200 can only do 3Gbps SATA II) * 2nd mSATA SSD possible in the 2nd mini PCI-E slot (mSATA drives not yet sold by Minifree) * much faster CPU (core i5/i7 on X220, core 2 duo on X200) *per CPU core*, and has more CPU cores (X220 is quad-core, vs X200 which is dual-core). This makes serious professional software development possible, aswell as enabling all kinds of other high performance use case scenarios which previously the libre software community had fallen short on. * LED backlit panel instead of CCFL (X200 uses CCFL). LED is more reliable (lasts longer without dimming over time). Better colour/contrast compared to X200. Brighter backlight. * much faster video performance (Intel HD 3000 on X220, vs Intel GMA 4500MHD on X200) * higher screen resolution (1366×768 on X220, vs 1280×800 on X200) * DisplayPort digital video output built in (X200 only has VGA) * supports more RAM (up to 16GiB, versus X200 which only supports 8GiB) * current hardware. Moores law has slowed down in recent years; the X220 is roughly on par with performance standards for even the most demanding of software developers. The X220 is a popular laptop for hackers and professional users alike * larger ESC key * better CPU cooling (and more power-efficient CPU) * USB 3.0 possible (with the Core i7 model. NOTE: untested) * Better webcam (720p HD with a decent microphone, compared to X200 which has low resolution webcam) – NOTE: not all X220 laptops from Minifree have webcams. If you want it, tell us and we’ll make sure to ship one that has it. Spread the word! - -- Leah Rowe Libreboot developer Use free software. Free as in freedom. https://en.wikipedia.org/wiki/Free_software Use a free operating system, GNU+Linux. https://libreboot.org/docs/distros/ Or BSD: https://libreboot.org/docs/bsd/ Use a free BIOS. https://libreboot.org/ Support computer user freedom. https://peers.community/ Minifree Ltd, trading as Ministry of Freedom | Registered in England, No. 9361826 | VAT No. GB202190462 Registered Office: 19 Hilton Road, Canvey Island, Essex SS8 9QA, UK | Web: https://minifree.org/ - -- Leah Rowe Libreboot developer Use free software. Free as in freedom. https://en.wikipedia.org/wiki/Free_software Use a free operating system, GNU+Linux. https://libreboot.org/docs/distros/ Or BSD: https://libreboot.org/docs/bsd/ Use a free BIOS. https://libreboot.org/ Support computer user freedom. https://peers.community/ Minifree Ltd, trading as Ministry of Freedom | Registered in England, No. 9361826 | VAT No. GB202190462 Registered Office: 19 Hilton Road, Canvey Island, Essex SS8 9QA, UK | Web: https://minifree.org/ -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEE+JRrnG26iGmvPhSA/0W3TPnRz5QFAlimyuEACgkQ/0W3TPnR z5QIfwf/dJWD7vrIZf8WHKvCxbvPdiAellQkgZjzOY9CWWeARufwrT21IlZ+YJCK 6wkhhl4yYysEv72WkRqPv30sPBLoNse95fmp+laA34ifPpUeQ6mAoJIYC01GdVTk kHLYGid1KtLfk2aRvEkWeXWa4u5GOivA6Ef7DGBa2lQveKJx7WpLhYHHBKljVzsg aqqf/mgYntjgh9s31mqR1z57DtvpXuyjrgwZkZOcrD78Msx8s0T6VmGIX+O8c6uc C9B0C1FsddLJfhIN9wmv63JWxYdqf6loNVGdSzwQI/0WR7uUgHR9sFPQDEN296rS snIN2CfEx8bzvFOs71mwUSXl4hMmSw== =L04I -----END PGP SIGNATURE-----

6 6

Re: [coreboot] T520 2630QM 16GB DIMM
by i1w5d7gf38keg＠tutanota.com 23 Feb '17

23 Feb '17

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 mytbk920423(a)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, <> i1w5d7gf38keg(a)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 >> coreboot(a)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(a)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/

1 0

Re: [coreboot] [VERY IMPORTANT] Announcement regarding Apollo Lake Coreboot building
by Youness Alaoui 23 Feb '17

23 Feb '17

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.stojsavljevic(a)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 <adurbin(a)google.com> wrote: > >> On Wed, Feb 22, 2017 at 10:18 AM, Zoran Stojsavljevic >> <zoran.stojsavljevic(a)gmail.com> wrote: >> > Aaron, >> > >> > Not that I am trying to be pest/bad guy. Please, believe me on this. >> Just >> > about the simple logic, which SHOULD NOT be deniable! >> > >> > I did what I know about Coreboot, hands on, from 3.3 years ago. Then, I >> > built the VERY first Emerald Lake 2 (CCG CRB) -> Cougar Canyon 2 CRB as >> > payload SeaBIOS, and WIN 8.0 32bit. I was really amazed. Then. >> > >> > And I read much more these days, and a bit emailed with Martin >> (forth/back), >> > so Martin can give me a jump start. And then I read more. And more. And >> for >> > 5 full days I was doing this exercise (with lot of pain). >> > >> > So, I'll quote you: >> > >> >> That file is the FSP blob. Nothing more. As Nico pointed out that is >> >> something completely different from the flash descriptor. The flash >> >> descriptor can be obtained from the original released BIOS or you have >> >> to generate it using Intel's FIT tool. >> > >> > Please, guide me through this process. Or point to some documents about >> this >> > process I can read about? >> >> IIRC, FIT is provided by Intel to its customers under NDA. You'll have >> to contact your Intel rep for that. It's quite the barrier to entry >> for using these devices, but that's a policy decision from Intel. >> >> Or you can take a previously released bios for this board and do >> similar as the instructions on the Minnow Max page: >> http://elinux.org/Minnowboard:MinnowMaxCoreboot#TXE_and_SPI_descriptor >> >> Note, TXE/CSE on apollolake does not have its own region in the flash. >> It's in something intel calls IFWI and has its own new format that >> lives in the "BIOS" region. There's a tool (util/cbfstool/ifwitool.c) >> which takes an existing image with the IFWI and makes it work with >> coreboot's implementation/support for apollolake. >> >> > >> > Thank you, >> > Zoran >> > >> > On Wed, Feb 22, 2017 at 5:05 PM, Aaron Durbin <adurbin(a)google.com> >> wrote: >> >> >> >> On Wed, Feb 22, 2017 at 10:01 AM, Zoran Stojsavljevic >> >> <zoran.stojsavljevic(a)gmail.com> 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 <nico.huber(a)secunet.com> >> >> > wrote: >> >> >> >> >> >> On 22.02.2017 08:12, Zoran Stojsavljevic wrote: >> >> >> > Hello to community, >> >> >> > >> >> >> > I finally, after 3 days of additional very hard struggle, found >> out >> >> >> > why >> >> >> > I >> >> >> > have (while I am in the last stage of building CBFS) nonsense >> while >> >> >> > building APL-I Coreboot coreboot.rom?! >> >> >> > >> >> >> > Please, read carefully this announcement. >> >> >> > >> >> >> > For last three days I came to hard stop because of this failure: >> >> >> > >> >> >> > Just quick look into the final failure (all passed, but last >> stage - >> >> >> > IFD >> >> >> > failed): >> >> >> > >> >> >> > Compile IFDTOOL >> >> >> > HOSTCC util/ifdfake/ifdfake >> >> >> > DD Adding Intel Firmware Descriptor >> >> >> > IFDTOOL Unlocking Management Engine >> >> >> > File build/coreboot.pre is 8388608 bytes >> >> >> > No Flash Descriptor found in this image >> >> >> > *src/southbridge/intel/common/firmware/Makefile.inc:50: recipe >> for >> >> >> > target >> >> >> > 'add_intel_firmware' failed* >> >> >> > *make: *** [add_intel_firmware] Error 1* >> >> >> > [user@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(a)coreboot.org >> >> > https://www.coreboot.org/mailman/listinfo/coreboot >> > >> > >> > > > -- > coreboot mailing list: coreboot(a)coreboot.org > https://www.coreboot.org/mailman/listinfo/coreboot >

1 0

New on blogs.coreboot.org: coreboot is joining the Software Freedom Conservancy
by WordPress 22 Feb '17

22 Feb '17

1 0

Re: [coreboot] [VERY IMPORTANT] Announcement regarding Apollo Lake Coreboot building
by Zoran Stojsavljevic 22 Feb '17

22 Feb '17

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 <adurbin(a)google.com> wrote: > On Wed, Feb 22, 2017 at 10:18 AM, Zoran Stojsavljevic > <zoran.stojsavljevic(a)gmail.com> wrote: > > Aaron, > > > > Not that I am trying to be pest/bad guy. Please, believe me on this. Just > > about the simple logic, which SHOULD NOT be deniable! > > > > I did what I know about Coreboot, hands on, from 3.3 years ago. Then, I > > built the VERY first Emerald Lake 2 (CCG CRB) -> Cougar Canyon 2 CRB as > > payload SeaBIOS, and WIN 8.0 32bit. I was really amazed. Then. > > > > And I read much more these days, and a bit emailed with Martin > (forth/back), > > so Martin can give me a jump start. And then I read more. And more. And > for > > 5 full days I was doing this exercise (with lot of pain). > > > > So, I'll quote you: > > > >> That file is the FSP blob. Nothing more. As Nico pointed out that is > >> something completely different from the flash descriptor. The flash > >> descriptor can be obtained from the original released BIOS or you have > >> to generate it using Intel's FIT tool. > > > > Please, guide me through this process. Or point to some documents about > this > > process I can read about? > > IIRC, FIT is provided by Intel to its customers under NDA. You'll have > to contact your Intel rep for that. It's quite the barrier to entry > for using these devices, but that's a policy decision from Intel. > > Or you can take a previously released bios for this board and do > similar as the instructions on the Minnow Max page: > http://elinux.org/Minnowboard:MinnowMaxCoreboot#TXE_and_SPI_descriptor > > Note, TXE/CSE on apollolake does not have its own region in the flash. > It's in something intel calls IFWI and has its own new format that > lives in the "BIOS" region. There's a tool (util/cbfstool/ifwitool.c) > which takes an existing image with the IFWI and makes it work with > coreboot's implementation/support for apollolake. > > > > > Thank you, > > Zoran > > > > On Wed, Feb 22, 2017 at 5:05 PM, Aaron Durbin <adurbin(a)google.com> > wrote: > >> > >> On Wed, Feb 22, 2017 at 10:01 AM, Zoran Stojsavljevic > >> <zoran.stojsavljevic(a)gmail.com> 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 <nico.huber(a)secunet.com> > >> > wrote: > >> >> > >> >> On 22.02.2017 08:12, Zoran Stojsavljevic wrote: > >> >> > Hello to community, > >> >> > > >> >> > I finally, after 3 days of additional very hard struggle, found out > >> >> > why > >> >> > I > >> >> > have (while I am in the last stage of building CBFS) nonsense while > >> >> > building APL-I Coreboot coreboot.rom?! > >> >> > > >> >> > Please, read carefully this announcement. > >> >> > > >> >> > For last three days I came to hard stop because of this failure: > >> >> > > >> >> > Just quick look into the final failure (all passed, but last stage > - > >> >> > IFD > >> >> > failed): > >> >> > > >> >> > Compile IFDTOOL > >> >> > HOSTCC util/ifdfake/ifdfake > >> >> > DD Adding Intel Firmware Descriptor > >> >> > IFDTOOL Unlocking Management Engine > >> >> > File build/coreboot.pre is 8388608 bytes > >> >> > No Flash Descriptor found in this image > >> >> > *src/southbridge/intel/common/firmware/Makefile.inc:50: recipe for > >> >> > target > >> >> > 'add_intel_firmware' failed* > >> >> > *make: *** [add_intel_firmware] Error 1* > >> >> > [user@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(a)coreboot.org > >> > https://www.coreboot.org/mailman/listinfo/coreboot > > > > >

1 0

Re: [coreboot] [VERY IMPORTANT] Announcement regarding Apollo Lake Coreboot building
by Aaron Durbin 22 Feb '17

22 Feb '17

On Wed, Feb 22, 2017 at 10:18 AM, Zoran Stojsavljevic <zoran.stojsavljevic(a)gmail.com> wrote: > Aaron, > > Not that I am trying to be pest/bad guy. Please, believe me on this. Just > about the simple logic, which SHOULD NOT be deniable! > > I did what I know about Coreboot, hands on, from 3.3 years ago. Then, I > built the VERY first Emerald Lake 2 (CCG CRB) -> Cougar Canyon 2 CRB as > payload SeaBIOS, and WIN 8.0 32bit. I was really amazed. Then. > > And I read much more these days, and a bit emailed with Martin (forth/back), > so Martin can give me a jump start. And then I read more. And more. And for > 5 full days I was doing this exercise (with lot of pain). > > So, I'll quote you: > >> That file is the FSP blob. Nothing more. As Nico pointed out that is >> something completely different from the flash descriptor. The flash >> descriptor can be obtained from the original released BIOS or you have >> to generate it using Intel's FIT tool. > > Please, guide me through this process. Or point to some documents about this > process I can read about? IIRC, FIT is provided by Intel to its customers under NDA. You'll have to contact your Intel rep for that. It's quite the barrier to entry for using these devices, but that's a policy decision from Intel. Or you can take a previously released bios for this board and do similar as the instructions on the Minnow Max page: http://elinux.org/Minnowboard:MinnowMaxCoreboot#TXE_and_SPI_descriptor Note, TXE/CSE on apollolake does not have its own region in the flash. It's in something intel calls IFWI and has its own new format that lives in the "BIOS" region. There's a tool (util/cbfstool/ifwitool.c) which takes an existing image with the IFWI and makes it work with coreboot's implementation/support for apollolake. > > Thank you, > Zoran > > On Wed, Feb 22, 2017 at 5:05 PM, Aaron Durbin <adurbin(a)google.com> wrote: >> >> On Wed, Feb 22, 2017 at 10:01 AM, Zoran Stojsavljevic >> <zoran.stojsavljevic(a)gmail.com> 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 <nico.huber(a)secunet.com> >> > wrote: >> >> >> >> On 22.02.2017 08:12, Zoran Stojsavljevic wrote: >> >> > Hello to community, >> >> > >> >> > I finally, after 3 days of additional very hard struggle, found out >> >> > why >> >> > I >> >> > have (while I am in the last stage of building CBFS) nonsense while >> >> > building APL-I Coreboot coreboot.rom?! >> >> > >> >> > Please, read carefully this announcement. >> >> > >> >> > For last three days I came to hard stop because of this failure: >> >> > >> >> > Just quick look into the final failure (all passed, but last stage - >> >> > IFD >> >> > failed): >> >> > >> >> > Compile IFDTOOL >> >> > HOSTCC util/ifdfake/ifdfake >> >> > DD Adding Intel Firmware Descriptor >> >> > IFDTOOL Unlocking Management Engine >> >> > File build/coreboot.pre is 8388608 bytes >> >> > No Flash Descriptor found in this image >> >> > *src/southbridge/intel/common/firmware/Makefile.inc:50: recipe for >> >> > target >> >> > 'add_intel_firmware' failed* >> >> > *make: *** [add_intel_firmware] Error 1* >> >> > [user@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(a)coreboot.org >> > https://www.coreboot.org/mailman/listinfo/coreboot > >

1 0

Re: [coreboot] [VERY IMPORTANT] Announcement regarding Apollo Lake Coreboot building
by Zoran Stojsavljevic 22 Feb '17

22 Feb '17

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 <adurbin(a)google.com> wrote: > On Wed, Feb 22, 2017 at 10:01 AM, Zoran Stojsavljevic > <zoran.stojsavljevic(a)gmail.com> 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 <nico.huber(a)secunet.com> > wrote: > >> > >> On 22.02.2017 08:12, Zoran Stojsavljevic wrote: > >> > Hello to community, > >> > > >> > I finally, after 3 days of additional very hard struggle, found out > why > >> > I > >> > have (while I am in the last stage of building CBFS) nonsense while > >> > building APL-I Coreboot coreboot.rom?! > >> > > >> > Please, read carefully this announcement. > >> > > >> > For last three days I came to hard stop because of this failure: > >> > > >> > Just quick look into the final failure (all passed, but last stage - > IFD > >> > failed): > >> > > >> > Compile IFDTOOL > >> > HOSTCC util/ifdfake/ifdfake > >> > DD Adding Intel Firmware Descriptor > >> > IFDTOOL Unlocking Management Engine > >> > File build/coreboot.pre is 8388608 bytes > >> > No Flash Descriptor found in this image > >> > *src/southbridge/intel/common/firmware/Makefile.inc:50: recipe for > >> > target > >> > 'add_intel_firmware' failed* > >> > *make: *** [add_intel_firmware] Error 1* > >> > [user@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(a)coreboot.org > > https://www.coreboot.org/mailman/listinfo/coreboot >

1 0

Re: [coreboot] [VERY IMPORTANT] Announcement regarding Apollo Lake Coreboot building
by Aaron Durbin 22 Feb '17

22 Feb '17

On Wed, Feb 22, 2017 at 10:01 AM, Zoran Stojsavljevic <zoran.stojsavljevic(a)gmail.com> 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 <nico.huber(a)secunet.com> wrote: >> >> On 22.02.2017 08:12, Zoran Stojsavljevic wrote: >> > Hello to community, >> > >> > I finally, after 3 days of additional very hard struggle, found out why >> > I >> > have (while I am in the last stage of building CBFS) nonsense while >> > building APL-I Coreboot coreboot.rom?! >> > >> > Please, read carefully this announcement. >> > >> > For last three days I came to hard stop because of this failure: >> > >> > Just quick look into the final failure (all passed, but last stage - IFD >> > failed): >> > >> > Compile IFDTOOL >> > HOSTCC util/ifdfake/ifdfake >> > DD Adding Intel Firmware Descriptor >> > IFDTOOL Unlocking Management Engine >> > File build/coreboot.pre is 8388608 bytes >> > No Flash Descriptor found in this image >> > *src/southbridge/intel/common/firmware/Makefile.inc:50: recipe for >> > target >> > 'add_intel_firmware' failed* >> > *make: *** [add_intel_firmware] Error 1* >> > [user@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(a)coreboot.org > https://www.coreboot.org/mailman/listinfo/coreboot

1 0

Re: [coreboot] [VERY IMPORTANT] Announcement regarding Apollo Lake Coreboot building
by Nico Huber 22 Feb '17

22 Feb '17

On 22.02.2017 08:12, Zoran Stojsavljevic wrote: > Hello to community, > > I finally, after 3 days of additional very hard struggle, found out why I > have (while I am in the last stage of building CBFS) nonsense while > building APL-I Coreboot coreboot.rom?! > > Please, read carefully this announcement. > > For last three days I came to hard stop because of this failure: > > Just quick look into the final failure (all passed, but last stage - IFD > failed): > > Compile IFDTOOL > HOSTCC util/ifdfake/ifdfake > DD Adding Intel Firmware Descriptor > IFDTOOL Unlocking Management Engine > File build/coreboot.pre is 8388608 bytes > No Flash Descriptor found in this image > *src/southbridge/intel/common/firmware/Makefile.inc:50: recipe for target > 'add_intel_firmware' failed* > *make: *** [add_intel_firmware] Error 1* > [user@localhost coreboot]$ > > At first, I suspect that culprit my .config file, but I have checked it > several times (maybe > dozen), and I could NOT find any problem with it > (except minor doubts). > > Then I switched to inspect -southbridge- setup, but these is none, since > (simplified explanation/view) APL-I is SoC. > > The next phase was to inspect > *src/southbridge/intel/common/firmware/Makefile.inc* , but there (although > my make scripting is rusty) I could NOT find any problem... > > Finally, somewhere around 2:00 AM I noticed/determined the root cause of > the problem: the util/ifdtool/ifdtool.c, line: > if (*(uint32_t *) (image + i) == *0x0FF0A55A*) { > > YET another INTEL IOTG PED hidden road bomb: the latest APL-I FSP: APL-I_ > FSP/ApolloLakeFspBinPkg/FspBin/ApolloLakeFsp.fd does NOT have pattern > *0x0FF0A55A* embedded in it (I have checked with HxD WIN tool). Looks like this [VERY IMPORTANT] Announcement is about you, confusing two very different concepts. FSP is a binary program run by coreboot and has nothing in common with the Intel Firmware Descriptor. It's called *.fd for some reason I don't know, but I'm pretty sure it's another binary. The Firmware Descriptor describes some flash parameters and soft straps. It's just data, no program. You only need it as an OEM to build a full ROM image for a new system. If you have a system that already runs another firmware, you can just keep the existing descriptor in place. Nico

3 2

Re: [coreboot] [VERY IMPORTANT] Announcement regarding Apollo Lake Coreboot building
by Zoran Stojsavljevic 22 Feb '17

22 Feb '17

> 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 <adurbin(a)google.com> wrote: > > > On Wed, Feb 22, 2017 at 9:36 AM, Zoran Stojsavljevic < > zoran.stojsavljevic(a)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 <adurbin(a)google.com> wrote: >> >>> >>> >>> On Wed, Feb 22, 2017 at 9:25 AM, Zoran Stojsavljevic < >>> zoran.stojsavljevic(a)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 <adurbin(a)google.com> >>>> wrote: >>>> >>>>> >>>>> >>>>> On Wed, Feb 22, 2017 at 9:08 AM, Zoran Stojsavljevic < >>>>> zoran.stojsavljevic(a)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 <adurbin(a)google.com> >>>>>> wrote: >>>>>> >>>>>>> On Wed, Feb 22, 2017 at 1:12 AM, Zoran Stojsavljevic >>>>>>> <zoran.stojsavljevic(a)gmail.com> wrote: >>>>>>> > Hello to community, >>>>>>> > >>>>>>> > I finally, after 3 days of additional very hard struggle, found >>>>>>> out why I >>>>>>> > have (while I am in the last stage of building CBFS) nonsense >>>>>>> while building >>>>>>> > APL-I Coreboot coreboot.rom?! >>>>>>> > >>>>>>> > Please, read carefully this announcement. >>>>>>> > >>>>>>> > For last three days I came to hard stop because of this failure: >>>>>>> > >>>>>>> > Just quick look into the final failure (all passed, but last stage >>>>>>> - IFD >>>>>>> > failed): >>>>>>> > >>>>>>> > Compile IFDTOOL >>>>>>> > HOSTCC util/ifdfake/ifdfake >>>>>>> > DD Adding Intel Firmware Descriptor >>>>>>> > IFDTOOL Unlocking Management Engine >>>>>>> > File build/coreboot.pre is 8388608 bytes >>>>>>> > No Flash Descriptor found in this image >>>>>>> > src/southbridge/intel/common/firmware/Makefile.inc:50: recipe for >>>>>>> target >>>>>>> > 'add_intel_firmware' failed >>>>>>> > make: *** [add_intel_firmware] Error 1 >>>>>>> > [user@localhost coreboot]$ >>>>>>> > >>>>>>> > At first, I suspect that culprit my .config file, but I have >>>>>>> checked it >>>>>>> > several times (maybe > dozen), and I could NOT find any problem >>>>>>> with it >>>>>>> > (except minor doubts). >>>>>>> > >>>>>>> > Then I switched to inspect -southbridge- setup, but these is none, >>>>>>> since >>>>>>> > (simplified explanation/view) APL-I is SoC. >>>>>>> > >>>>>>> > The next phase was to inspect >>>>>>> > src/southbridge/intel/common/firmware/Makefile.inc , but there >>>>>>> (although my >>>>>>> > make scripting is rusty) I could NOT find any problem... >>>>>>> > >>>>>>> > Finally, somewhere around 2:00 AM I noticed/determined the root >>>>>>> cause of the >>>>>>> > problem: the util/ifdtool/ifdtool.c, line: >>>>>>> > if (*(uint32_t *) (image + i) == 0x0FF0A55A) { >>>>>>> > >>>>>>> > YET another INTEL IOTG PED hidden road bomb: the latest APL-I FSP: >>>>>>> > APL-I_FSP/ApolloLakeFspBinPkg/FspBin/ApolloLakeFsp.fd does NOT >>>>>>> have pattern >>>>>>> > 0x0FF0A55A embedded in it (I have checked with HxD WIN tool). >>>>>>> >>>>>>> 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(a)coreboot.org >>>>>>> > https://www.coreboot.org/mailman/listinfo/coreboot >>>>>>> >>>>>> >>>>>> >>>>> >>>> >>> >> >

1 0

← Newer
1
...
4
5
6
7
8
9
10
...
22
Older →

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

coreboot February 2017