coreboot February 2017

coreboot@coreboot.org

66 participants
212 discussions

The fastest possible intel free-as-in-freedom pattform not supported now?
by i1w5d7gf38keg＠tutanota.com 23 Feb '17

23 Feb '17

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

2 1

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

23 Feb '17

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

23 Feb '17

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

1 0

Re: [coreboot] Lenovo T420 Question
by i1w5d7gf38keg＠tutanota.com 23 Feb '17

23 Feb '17

You can install a quadcore. 2720QM is been tested working. http://forum.notebookreview.com/threads/t420-upgrade-to-i7-2720qm-es-q154-s… 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.

3 3

Improving KBC1126 support for HP laptops
by Iru Cai 23 Feb '17

23 Feb '17

Hi, I'm now doing the port for HP Elitebook 2760p ( https://review.coreboot.org/#/c/18241/) and other HP laptops, but I'm now having trouble with the EC+SuperIO chip KBC1126. Now I can use superio/smsc/kbc1100 to enable keyboard support. However, I still cannot access the EC with ectool, which will give me all 0xff when I run `ectool -d`. Also I cannot use the touchscreen even I write some ACPI code. I have searched and downloaded two SMSC confidential document: a KBC1122 preliminary datasheet and a KBC1122 BIOS porting guide. Is there any problem if I use them to write some code? Thanks, Iru -- 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 Zoran Stojsavljevic 23 Feb '17

23 Feb '17

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

Dont filter supported CPUs on a mainboard by the CPUID
by i1w5d7gf38keg＠tutanota.com 23 Feb '17

23 Feb '17

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.

4 5

Re: [coreboot] Coreboot on Thinkpad "X62" (i7-5600u)?
by Iru Cai 23 Feb '17

23 Feb '17

Hello, On Thu, Feb 23, 2017 at 3:46 PM, Rafael Send <rsend(a)berkeley.edu> wrote: > Hello there- > I'm assuming this is the right way to ask a general question, but please > let me know if it isn't. > > I have an "X62" laptop, which is actually an old Thinkpad X61 with a > custom motherboard in it. > This board has an i7-5600u CPU on it, and I was wondering if it was > possible to build a version of coreboot for this machine. > I see an existing mailing list entry in the archive discussing a > Chromebook Pixel with the same CPU, so I'm thinking it may be possible > unless I'm missing something major. > Since this is a custom motherboard, how would I find out about the Intel > Boot Guard and related issues so that I can provide the details for the > good folks here? > You can try https://review.coreboot.org/#/c/16328/, or modify some instructions in the firmware to see if it still boots. If boot guard is not enabled, I think booting with coreboot is not so hard, but it may be hard to make the EC interface work fine. Iru I'm pretty comfortable around Linux but probably would have trouble > building this from scratch. > Thanks in advance! > > Rafael > > -- > 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] Dont filter supported CPUs on a mainboard by the CPUID
by i1w5d7gf38keg＠tutanota.com 23 Feb '17

23 Feb '17

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 tpearson(a)raptorengineering.com: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > On 02/22/2017 05:31 PM, > i1w5d7gf38keg(a)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(a)coreboot.org > https://www.coreboot.org/mailman/listinfo/coreboot

4 4

Coreboot on Thinkpad "X62" (i7-5600u)?
by Rafael Send 23 Feb '17

23 Feb '17

Hello there- I'm assuming this is the right way to ask a general question, but please let me know if it isn't. I have an "X62" laptop, which is actually an old Thinkpad X61 with a custom motherboard in it. This board has an i7-5600u CPU on it, and I was wondering if it was possible to build a version of coreboot for this machine. I see an existing mailing list entry in the archive discussing a Chromebook Pixel with the same CPU, so I'm thinking it may be possible unless I'm missing something major. Since this is a custom motherboard, how would I find out about the Intel Boot Guard and related issues so that I can provide the details for the good folks here? I'm pretty comfortable around Linux but probably would have trouble building this from scratch. Thanks in advance! Rafael

1 0

← Newer
1
2
3
4
5
6
7
8
9
...
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