coreboot March 2017

coreboot@coreboot.org

79 participants
267 discussions

Re: [coreboot] [coreboot-gerrit] Change in coreboot[master]: KBL: Update FSP headers - upgrade to FSP.2.0.0
by Manigandan, Balaji 29 Mar '17

29 Mar '17

Hi Aaron, The patches are in draft as the migration was in progress, hence you were not able to access. Not sure how this triggered email even when you were not added yet Will publish it later today. Thanks and Regards Balaji -----Original Message----- From: Aaron Durbin [mailto:adurbin@google.com] Sent: Tuesday, March 28, 2017 8:43 PM To: Coreboot <coreboot(a)coreboot.org>; Banik, Subrata <subrata.banik(a)intel.com> Cc: Manigandan, Balaji <balaji.manigandan(a)intel.com>; coreboot-gerrit(a)coreboot.org; Solanki, Naresh <naresh.solanki(a)intel.com>; Sarkar, Barnali <barnali.sarkar(a)intel.com>; Qureshi, Rizwan <rizwan.qureshi(a)intel.com> Subject: Re: [coreboot-gerrit] Change in coreboot[master]: KBL: Update FSP headers - upgrade to FSP.2.0.0 Why can't I access this CL on gerrit, but I'm getting emails for it? On Tue, Mar 28, 2017 at 10:10 AM, Subrata Banik (Code Review) <gerrit(a)coreboot.org> wrote: > Subrata Banik has posted comments on this change. ( > https://review.coreboot.org/19023 ) > > Change subject: KBL: Update FSP headers - upgrade to FSP.2.0.0 > ...................................................................... > > > Patch Set 3: > > (2 comments) > > https://review.coreboot.org/#/c/19023/3/src/vendorcode/intel/fsp/fsp2_ > 0/skykabylake/ConfigBlock/CpuConfigFspData.h > File src/vendorcode/intel/fsp/fsp2_0/skykabylake/ConfigBlock/CpuConfigFspData.h: > > PS3, Line 66: } Bits; > : UINT32 Uint32[2]; > : } CPU_CONFIG_FSP_DATA; > why added space? don't we run clean up script? > > > https://review.coreboot.org/#/c/19023/3/src/vendorcode/intel/fsp/fsp2_ > 0/skykabylake/FspmUpd.h File > src/vendorcode/intel/fsp/fsp2_0/skykabylake/FspmUpd.h: > > PS3, Line 41: #include <MemInfoHob.h> > directory structure change > ?? > > > -- > To view, visit https://review.coreboot.org/19023 To unsubscribe, visit > https://review.coreboot.org/settings > > Gerrit-MessageType: comment > Gerrit-Change-Id: Id8ecea6fa5f4e7a72410f8da535ab9c4808b3482 > Gerrit-PatchSet: 3 > Gerrit-Project: coreboot > Gerrit-Branch: master > Gerrit-Owner: Balaji Manigandan <balaji.manigandan(a)intel.com> > Gerrit-Reviewer: Barnali Sarkar <barnali.sarkar(a)intel.com> > Gerrit-Reviewer: Naresh Solanki <naresh.solanki(a)intel.com> > Gerrit-Reviewer: Rizwan Qureshi <rizwan.qureshi(a)intel.com> > Gerrit-Reviewer: Subrata Banik <subrata.banik(a)intel.com> > Gerrit-HasComments: Yes > > -- > coreboot-gerrit mailing list: coreboot-gerrit(a)coreboot.org > https://www.coreboot.org/mailman/listinfo/coreboot-gerrit

1 0

Re: [coreboot] SPI Flash does not work on Intel LeafHill CRB
by Zoran Stojsavljevic 29 Mar '17

29 Mar '17

> ...tried flashing SPI chip (Winbond W25Q128FW)... Flashing with what (context in question)? (we'll come later to INTEL stitching tool, I have good perception/anticipation, developed for by INTEL) ;-) Thank you, Zoran On Wed, Mar 29, 2017 at 1:29 PM, Toan Le manh <lemanhtoantb(a)gmail.com> wrote: > I got the LeafHill CRB from Intel, tried flashing SPI chip (Winbond > W25Q128FW) using BeeProg2C. > However nothing worked. The Status Code remained "0". > Does anyone face the same problem? Could you please give me some advice? > Thanks a lot. > > > > -- > coreboot mailing list: coreboot(a)coreboot.org > https://www.coreboot.org/mailman/listinfo/coreboot >

1 0

Coreboot 4.5: No early serial output
by Naveed Ghori 29 Mar '17

29 Mar '17

Hi all, In Coreboot 4.4 (Intel baytrail FSP) early serial output use to work (first line being coreboot version followed by RTC Init) In Coreboot 4.5 it seems that serial output only works once the FSP initializes the serial port (first line being romstage_main_continue). Notes: Setup for spew output, using the debug serial port lines. I am looking at what might have caused this but though I'd ask if this was a known issue, possibly already fixed with a patch or if it was an error on my part. Note sure exactly where to search as I have already reviewed the changes in src/drivers/uart/uart8250io.c Regards, Naveed Naveed Ghori | Lead Firmware & Driver Engineer DTI Group Ltd | Transit Security & Surveillance 31 Affleck Road, Perth Airport, Western Australia 6105, Australia P +61 8 9373 2905,151 | F +61 8 9479 1190 | naveed.ghori(a)dti.com.au<mailto:naveed.ghori@dti.com.au> Visit our website www.dti.com.au<http://www.dti.com.au> The information contained in this email is confidential. If you receive this email in error, please inform DTI Group Ltd via the above contact details. If you are not the intended recipient, you may not use or disclose the information contained in this email or attachments.

2 1

How to update the repository and avoid dirty tree with submodules?
by Paul Menzel 29 Mar '17

29 Mar '17

Dear coreboot folks, Often I am running into problems, when updating the tree. Normally I do `git pull --rebase` to update my branch, and rebase my changes on top of the upstream master branch. But if something in the submodules, under `3rdparty` changes, I get a dirty tree. The same is true, when bisecting or checking out a very old commit. Just today, after running `git pull --rebase` ``` $ git show commit 3c645391c0b7272f66d842bed454c29ceb9ce0bf Author: Marshall Dawson <marshalldawson3rd(a)gmail.com> Date: Sat Mar 25 17:49:45 2017 -0600 3rdparty/blobs: Update for AMD Stoney Ridge Add the binaryPI file for the FT4 package and add SMU firmware to be consumed by fanless OPNs. Change-Id: I1c9b5ded6b494fac1553cc2ec7756a7a47386ecf Signed-off-by: Marshall Dawson <marshalldawson3rd(a)gmail.com> Reviewed-on: https://review.coreboot.org/18988 Tested-by: build bot (Jenkins) Reviewed-by: Martin Roth <martinroth(a)google.com> diff --git a/3rdparty/blobs b/3rdparty/blobs index 8090bdd598..b5e64d7cf4 160000 --- a/3rdparty/blobs +++ b/3rdparty/blobs @@ -1 +1 @@ -Subproject commit 8090bdd59853599e469b7503ea473ca12e8c681b +Subproject commit b5e64d7cf4984dcf8e284c1878d943e88d53de5d $ git diff diff --git a/3rdparty/blobs b/3rdparty/blobs index b5e64d7cf4..8090bdd598 160000 --- a/3rdparty/blobs +++ b/3rdparty/blobs @@ -1 +1 @@ -Subproject commit b5e64d7cf4984dcf8e284c1878d943e88d53de5d +Subproject commit 8090bdd59853599e469b7503ea473ca12e8c681b ``` In this situation, I am manually changing the directory under `3rdparty/`, in this case `blobs`, and do `git reset --hard <hash>` there to get a clean state. Do you know of tricks that the submodules are, by default, always in the state of the commits noted in the coreboot branch? Do you have other hints or suggestions on how to work with git submodules? Thanks, Paul

2 1

SPI Flash does not work on Intel LeafHill CRB
by Toan Le manh 29 Mar '17

29 Mar '17

I got the LeafHill CRB from Intel, tried flashing SPI chip (Winbond W25Q128FW) using BeeProg2C. However nothing worked. The Status Code remained "0". Does anyone face the same problem? Could you please give me some advice? Thanks a lot.

1 0

Re: [coreboot] Fwd: Ethernet problem in x200
by Denis 'GNUtoo' Carikli 29 Mar '17

29 Mar '17

On Mon, 27 Mar 2017 16:14:53 +0200 Zoran Stojsavljevic <zoran.stojsavljevic(a)gmail.com> wrote: > [user@localhost projects]$ cat dmesg.txt | grep 00:19.0 > [ 0.151652] pci 0000:00:19.0: *[8086:294c*] type 00 class 0x020000 > [ 0.151694] pci 0000:00:19.0: reg 0x10: [mem 0xe1600000-0xe161ffff] > [ 0.151707] pci 0000:00:19.0: reg 0x14: [mem 0xe1624000-0xe1624fff] > [ 0.151721] pci 0000:00:19.0: reg 0x18: [io 0x3000-0x301f] > [ 0.151802] pci 0000:00:19.0: PME# supported from D0 D3hot D3cold > [ 1.489719] e1000e 0000:00:19.0: Interrupt Throttling Rate > (ints/sec) set to dynamic conservative mode > [ 1.611526] e1000e 0000:00:19.0: The NVM Checksum Is Not Valid > *[ 1.635873] e1000e: probe of 0000:00:19.0 failed with error -5* The Lenovo Thinkpad X200 uses a GM45 chipset. This chipset supports different ways of booting: (1) Having a boot fimrware occupy all the flash chip, if you do that the Ethernet will not work, according to the datasheet. (2) Having a boot firmware with the management engine firmware. (3) Having a boot firmware without the management engine firmware. It is strongly advised to do (3) and follow the corresponding coreboot documentation. To get a working Ethernet with (3) you need to set a valid mac address: In the installation documentation, you are expected to use ich9gen, however if you use it this way: > $ ./ich9gen It will not produce a valid MAC address. You must instead do something like that, and replace <A-VALID-MAC-ADDRESS> by a valid MAC address: > $ ./ich9gen --macaddress <A-VALID-MAC-ADDRESS> To find such MAC address, you have several options: - Look if it can be found on a sticker on the bottom of your laptop. - Reflash the original flash content and get it with: > $ ifconfig -a or: > ip link == Side note == According to the wikipedia article on MAC Address[1], the 3 bytes on the left correspond to a vendor/organisation. So I got a valid MAC address with the methods mentioned above, and only kept the 3 bytes on the left, and tested that MAC address: > 00:1f:16:00:00:00 And it worked on my Lenovo Thinkpad X200. To use that MAC address, just use: > $ ./ich9gen --macaddress It might be possible that all addresses between 00:1f:16:00:00:00 and 00:1f:16:FF:FF:FF work, but I didn't test that. References: ----------- [1]https://en.wikipedia.org/wiki/MAC_address#Address_details Denis.

3 3

Have a anyidea? that change the serial number of DMI?
by 김유석 29 Mar '17

29 Mar '17

Dear Sir. Currently, I was successed the read a serial number, and product name useded the DMI, in kernel space and user space. - kernel space. use the "dmi_get_system_info()" - user space use the "dmidecode" - coreboot space I don't know any soultion. READ is OK. But, i want to write or chage the serial number. But, i can't found the any solution. I try to find the some API in kernel source tree. for example) grep "dmi_set" * -Rn But can't found the API. *Question.* How to write or change the serial number using DMI? in kernel or in userspace or in coreboot? Thank you.

2 1

Re: [coreboot] Coreboot wiki: what license is the content under?
by David Hendricks 28 Mar '17

28 Mar '17

This would be a good topic to bring up in the next community chat. On Tue, Mar 21, 2017 at 1:21 PM, Sam Kuper <sam.kuper(a)uclmail.net> wrote: > On 21/03/2017, Martin Roth <gaumless(a)gmail.com> wrote: >> Is there a reason we shouldn't switch to CC BY 4.0? > > Arguably, yes: doing so would permit the use of Coreboot wiki material > in proprietary works, which some wiki contributors might be opposed > to. Do these licenses separate the notions of "proprietary" and "commercial?" For example, a hardware vendor might wish to sell a device that uses coreboot and write the manual using some wiki content. That aligns perfectly with the project and I think we should strive toward removing legal obstacles for such cases. AIUI, the GFDL would require the vendor to append or archive the original wiki article in such cases (assuming >100 copies are made). It's kind of a silly impediment to impose if we're trying to increase adoption, IMO. > It would also prevent importing material from Wikipedia or Stack > Exchange into the Coreboot wiki. I think the flow usually goes the other way, from coreboot.org to other places. For cases where it's the opposite direction, we can still link to Wikipedia or SE rather than reprinting, or perhaps seek permission from the author to post under the license chosen for coreboot.org. >> - Do we really care what Stack Exchange or any other group is using? >> How much are we copying from them? > > At the moment, I don't know of any Coreboot wiki content that was > copied from SE or Wikipedia. *nod* > > But as Coreboot becomes more popular, the likelihood increases that > someone might post an answer on SE, or a description on Wikipedia, > that is good enough that it is worth including it (either verbatim or > appropriately edited) in the Coreboot wiki. For such inclusion to be > possible, the Coreboot wiki's license obviously needs to be compatible > with SE's license and Wikipedia's license. We could just ask the author's permission in those cases, right? While sub-optimal, I think it could be worth the tradeoff to use the more permissive license so that we optimize for the general case and then handle corner cases as needed. > As an aside: it is certainly possible in principle to dual-license (or > even triple-license, etc) the Coreboot wiki's content. So, Coreboot > could, for instance, decide to use CC BY-SA 3.0 *and* GFDL, with the > licensee allowed to choose whichever they prefer. On the plus side, > this would avoid the community having to choose between them (i.e. it > avoids the "versus" aspect of the discussion you linked to). On the > down side, it would prevent bi-directional compatibility with SE, as I > pointed out here: > https://www.coreboot.org/pipermail/coreboot/2017-March/083614.html . Seems overly complicated IMO. For simplicity's sake it would be nice to use a single license for coreboot.org that satisfies the most users and those who strongly disagree can post elsewhere (maybe libreboot/librecore) and link to it.

1 0

Re: [coreboot] Group demographics
by tturne＠codeaurora.org 28 Mar '17

28 Mar '17

On 2017-03-24 17:42, Julius Werner wrote: >> * Google's recovery manifest (from linux_recovery.sh) can pull a >> recovery image for a specific product, I have yet to find >> depthcharge as a payload >> * Obviously I haven't pulled all of the recovery images, but have >> looked at ~10 >> * those interested in recovery image, >> /usr/sbin/chromeos_firmwareupdate --sb_extract yields a bios.bin >> file that cbfstool can parse (i.e. is a coreboot.rom file) > > All non-x86 Chromebooks that use coreboot also use depthcharge. What > exactly do you mean when you say you can't find it? If you parse > bios.bin with cbfstool print, you should see a "fallback/payload" > file... that is depthcharge. (coreboot always requires the payload to > just be called "payload" in CBFS, regardless of what it actually is.) > You can extract it and run 'strings' on it to confirm. This was my understanding (Depthcharge being used as payload for all recent Chromebooks). What led me to question this understanding was: * limited number of libpayload config files in coreboot source tree * chromiumos build tree explicitly setting CONFIG_PAYLOAD="n" for all coreboot boards * u-boot.dtb file being present in all bios.bin files I looked at from linux_recovery.sh manifest (including Kevin) As fallback/payload is compressed in bios.bin, I'm not sure what strings will provide. I did run strings on bios.bin (as well as looking at it in hex editor) and found nothing explicitly suggesting depthcharge (or u-boot for that matter) was the payload. I made assumption u-boot was payload based on presence of u-boot.dtb file in bios.bin. As has already been explained in this thread the coreboot build within chromiumos tree does not include building payload, this is a later step. My work to date has been solely within confines of coreboot build tree and directly generating depthcharge, etc. so this deferred building of the payload came as a surprise. I welcome pointers to online documentation (either coreboot or chromiumos) that more clearly discuss coreboot inclusion within chromiumos build and development cycle. Thanks to all who have contributed to my current level of knowledge and I know I am just scratching the surface. Cheers, T.mike

3 2

Re: [coreboot] Group demographics
by tturne＠codeaurora.org 28 Mar '17

28 Mar '17

On 2017-03-28 13:24, Aaron Durbin wrote: > On Tue, Mar 28, 2017 at 3:20 PM, <tturne(a)codeaurora.org> wrote: >> On 2017-03-24 17:42, Julius Werner wrote: >>>> >>>> * Google's recovery manifest (from linux_recovery.sh) can pull a >>>> recovery image for a specific product, I have yet to find >>>> depthcharge as a payload >>>> * Obviously I haven't pulled all of the recovery images, but have >>>> looked at ~10 >>>> * those interested in recovery image, >>>> /usr/sbin/chromeos_firmwareupdate --sb_extract yields a bios.bin >>>> file that cbfstool can parse (i.e. is a coreboot.rom file) >>> >>> >>> All non-x86 Chromebooks that use coreboot also use depthcharge. What >>> exactly do you mean when you say you can't find it? If you parse >>> bios.bin with cbfstool print, you should see a "fallback/payload" >>> file... that is depthcharge. (coreboot always requires the payload to >>> just be called "payload" in CBFS, regardless of what it actually is.) >>> You can extract it and run 'strings' on it to confirm. >> >> >> This was my understanding (Depthcharge being used as payload for all >> recent >> Chromebooks). >> What led me to question this understanding was: >> * limited number of libpayload config files in coreboot source tree >> * chromiumos build tree explicitly setting CONFIG_PAYLOAD="n" for all >> coreboot boards >> * u-boot.dtb file being present in all bios.bin files I looked at >> from >> linux_recovery.sh manifest (including Kevin) >> >> As fallback/payload is compressed in bios.bin, I'm not sure what >> strings >> will provide. >> I did run strings on bios.bin (as well as looking at it in hex editor) >> and >> found nothing >> explicitly suggesting depthcharge (or u-boot for that matter) was the >> payload. I made >> assumption u-boot was payload based on presence of u-boot.dtb file in >> bios.bin. > > FWIW, you can 'cbfstool extract' the fallback/payload file from an > existing image. It'll write an ELF file that you should be familiar > with for inspection purposes (strings, readelf, objdump, etc). Thanks for this heads-up, I didn't realize extract would decompress. I have extracted the payload and based on the symbols concur that it is depthcharge. Cheers, T.mike > >> >> As has already been explained in this thread the coreboot build within >> chromiumos tree does not include >> building payload, this is a later step. My work to date has been >> solely >> within confines of coreboot >> build tree and directly generating depthcharge, etc. so this deferred >> building of the payload came as a surprise. >> >> I welcome pointers to online documentation (either coreboot or >> chromiumos) >> that more clearly discuss coreboot inclusion within chromiumos build >> and >> development cycle. >> >> Thanks to all who have contributed to my current level of knowledge >> and I >> know I am just scratching the surface. >> Cheers, >> T.mike

1 0

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