coreboot October 2015

coreboot@coreboot.org

44 participants
137 discussions

Re: [coreboot] Trying to flash coreboot onto on-board SPI chip of HP Envy H87 haswell chipset.
by David Hendricks 20 Oct '15

20 Oct '15

On Tue, Oct 20, 2015 at 12:26 PM, Arpita Biswas <arpita.biswas07(a)gmail.com> wrote: > Hi all, > > I am trying to update BIOS with coreboot onto HP Envy H87 haswell chipset > (ipm87_mp) > <http://www.newegg.com/Product/Product.aspx?Item=9SIA6392VN4810>. I am > using Dediprog + SOIC 8-pin flash clip for flashing the SPI chip (W25Q64). > However dediprog doesn't detect the chip when it's soldered on-board. On > removing the chip from board, I can detect/read/write onto it without any > issues. > > I've tried (and failed) with the following configurations : > (1) SPI pin ------> Dediprog : /CS ---> CS, DO (IO1) ---> MISO, /WP (IO2) > ---> 3.3V, GND ---> GND, DI (IO0) ---> MOSI, CLK ---> CLK, /HOLD (IO3) ---> > 3.3V, VCC ---> 3.3V with motherboard power ON. > > (2) Same config as above but I tried to isolate the chip by removing CMOS > battery + removing jumper on SPI header + powering OFF the motherboard. > > (3) Similar as (1) and (2), but let /HOLD, /Vcc and /WP float. > > (4) I tried using flashrom on the box too as internal programmer, but it > did not recognize the SPI chip. Error log says "Found Programmer flash chip > "Opaque flash chip" (8192 kB, Programmer-specific)." > > I've a feeling that something on the motherboard is interfering with the > SPI chip since an off-board chip is working fine. Does anybody have any > pointers on what could be going wrong ? > I suspect your motherboard does not isolate the SPI ROM's voltage supply and thus your Dediprog is effectively powering other components on the board. If you can find a way to hold the PCH and ME in reset while the board is powered on, that might work. Or, with the board off, you can try using an external power supply (the usual warnings about possibly frying your board apply). > > Thanks in advance, > - Arpita > > -- > coreboot mailing list: coreboot(a)coreboot.org > http://www.coreboot.org/mailman/listinfo/coreboot > -- David Hendricks (dhendrix) Systems Software Engineer, Google Inc.

1 0

Trying to flash coreboot onto on-board SPI chip of HP Envy H87 haswell chipset.
by Arpita Biswas 20 Oct '15

20 Oct '15

Hi all, I am trying to update BIOS with coreboot onto HP Envy H87 haswell chipset (ipm87_mp) <http://www.newegg.com/Product/Product.aspx?Item=9SIA6392VN4810>. I am using Dediprog + SOIC 8-pin flash clip for flashing the SPI chip (W25Q64). However dediprog doesn't detect the chip when it's soldered on-board. On removing the chip from board, I can detect/read/write onto it without any issues. I've tried (and failed) with the following configurations : (1) SPI pin ------> Dediprog : /CS ---> CS, DO (IO1) ---> MISO, /WP (IO2) ---> 3.3V, GND ---> GND, DI (IO0) ---> MOSI, CLK ---> CLK, /HOLD (IO3) ---> 3.3V, VCC ---> 3.3V with motherboard power ON. (2) Same config as above but I tried to isolate the chip by removing CMOS battery + removing jumper on SPI header + powering OFF the motherboard. (3) Similar as (1) and (2), but let /HOLD, /Vcc and /WP float. (4) I tried using flashrom on the box too as internal programmer, but it did not recognize the SPI chip. Error log says "Found Programmer flash chip "Opaque flash chip" (8192 kB, Programmer-specific)." I've a feeling that something on the motherboard is interfering with the SPI chip since an off-board chip is working fine. Does anybody have any pointers on what could be going wrong ? Thanks in advance, - Arpita

1 0

Re: [coreboot] GPL license headers
by ron minnich 20 Oct '15

20 Oct '15

Eben Moglen, who ought to know, guided us on the release rules for the Plan 9 GPL release. Here is what he told us could go in each file: /* * This file is part of the UCB release of Plan 9. It is subject to the license * terms in the LICENSE file found in the top-level directory of this * distribution and at http://akaros.cs.berkeley.edu/files/Plan9License. No * part of the UCB release of Plan 9, including this file, may be copied, * modified, propagated, or distributed except according to the terms contained * in the LICENSE file. */ And, then, to see the file: https://github.com/Harvey-OS/harvey/blob/master/LICENSE You really don't need all the text in each file. You don't have to believe me but you can definitely believe Eben :-) ron On Tue, Oct 20, 2015 at 10:30 AM Patrick Georgi <pgeorgi(a)google.com> wrote: > 2015-10-20 3:42 GMT+02:00 Alex G. <mr.nuke.me(a)gmail.com>: > > I'd go as far as removing the last two paragraphs completely. The "this > > comes with no warranty" boilerplate is only binding because it is also > > included in the GPL proper, not because it's slapped in developers' > > faces all so often. > Get (the right set of) lawyers to sign off on that. > So far, there's clearance to get rid of the last paragraph, but > dropping actual legalese sounds scary. > > > Patrick > -- > Google Germany GmbH, ABC-Str. 19, 20354 Hamburg > Registergericht und -nummer: Hamburg, HRB 86891, Sitz der Gesellschaft: > Hamburg > Geschäftsführer: Matthew Scott Sucherman, Paul Terence Manicle > > -- > coreboot mailing list: coreboot(a)coreboot.org > http://www.coreboot.org/mailman/listinfo/coreboot

1 0

Re: [coreboot] GPL license headers
by Alex G. 20 Oct '15

20 Oct '15

On 10/19/2015 11:44 AM, Patrick Georgi wrote: > Hi all, > > we recently removed the FSF addresses from license headers in our > files to avoid the maintenance of updating them every time the FSF > decides to move their office. +2 > Now we also added checkpatch.pl that comes from Linux to automatically > ensure some consistency across the tree, and it looks for removal of > the entire paragraph. +2 > Now, that may just make sense and I'm willing to update the scripts to > do that and update the tree. +2 > Opinions? I'd go as far as removing the last two paragraphs completely. The "this comes with no warranty" boilerplate is only binding because it is also included in the GPL proper, not because it's slapped in developers' faces all so often. > Patrick Alex

2 1

screwdriver 0.3.0 released
by Alexander Couzens 20 Oct '15

20 Oct '15

hi, I'm happy to announce the release of screwdriver 0.3.0. screwdriver is a small distribution for bbb (beagleboneblack) based on OpenWrt supporting spi flashing and usbdebug. Take a look on the wiki page [1] for more infomation. Best lynxis PS. help or feedback is welcome! [1] http://www.coreboot.org/BBB_screwdriver [2] https://github.com/lynxis/bbb_screwdriver_builder [3] http://repo.fe80.eu/screwdriver/0.3.0/omap/generic/default/openwrt-0.3.0-om… -- Alexander Couzens mail: lynxis(a)fe80.eu jabber: lynxis(a)fe80.eu mobile: +4915123277221

2 1

Re: [coreboot] [help]build cbfstool fail with cygwin64
by Stefan Reinauer 20 Oct '15

20 Oct '15

I think switching to c99 per default is a great idea. The problem below should be fixed by http://review.coreboot.org/#/c/11666/ and the following patch. Stefan On Oct 19, 2015, Julius Werner <jwerner(a)chromium.org> wrote: >> is there anyway to dynamic define std to gnu99 when detect build with >cygwin? > >cbfstool is already defining -std=c99. I don't see a strong reason why >we shouldn't just change that to gnu99 globally. > >>>> 2. default build will error as below, >>>> HOSTCC cbfstool/cbfstool.o >>>> /cygdrive/d/FW/coreboot/util/cbfstool/cbfstool.c: In function >'main': >>>> /cygdrive/d/FW/coreboot/util/cbfstool/cbfstool.c:1075:5: error: >array >>>> subscript has type 'char' [-Werror=char-subscripts] >>>> if (tolower(suffix[0])=='k') { >>>> ^ > >This sounds like an bug in cygwin and you should file it with them. >They're probably implementing tolower() in their standard header as a >macro which directly indexes an array with an argument. They should at >least be casting the argument inside that macro or they are not >POSIX-compliant. -- Sent with <a href="https://play.google.com/store/apps/details?id=com.onegravity.k10.pro2"><b>K-@ Mail</b></a> - the evolution of emailing.

1 0

Re: [coreboot] [help]build cbfstool fail with cygwin64
by Julius Werner 20 Oct '15

20 Oct '15

> is there anyway to dynamic define std to gnu99 when detect build with cygwin? cbfstool is already defining -std=c99. I don't see a strong reason why we shouldn't just change that to gnu99 globally. >>> 2. default build will error as below, >>> HOSTCC cbfstool/cbfstool.o >>> /cygdrive/d/FW/coreboot/util/cbfstool/cbfstool.c: In function 'main': >>> /cygdrive/d/FW/coreboot/util/cbfstool/cbfstool.c:1075:5: error: array >>> subscript has type 'char' [-Werror=char-subscripts] >>> if (tolower(suffix[0])=='k') { >>> ^ This sounds like an bug in cygwin and you should file it with them. They're probably implementing tolower() in their standard header as a macro which directly indexes an array with an argument. They should at least be casting the argument inside that macro or they are not POSIX-compliant.

1 0

Re: [coreboot] GPL license headers
by Vadim Bendebury 19 Oct '15

19 Oct '15

oh, I thought you'd say +1^2 :) --vb On Mon, Oct 19, 2015 at 1:05 PM, ron minnich <rminnich(a)gmail.com> wrote: > I won't say +1, that's so 2014. > > Plus Two! > > ron > > On Mon, Oct 19, 2015 at 11:53 AM Peter Stuge <peter(a)stuge.se> wrote: >> >> Patrick Georgi wrote: >> > The paragraph in question is: >> > ---- >> > You should have received a copy of the GNU General Public License >> > along with this program; if not, write to the Free Software >> > Foundation, Inc. >> > ---- >> > >> > Since the GPL is fairly well-known (incl where to find it), and our >> > tree already contains the license in the toplevel directory, that >> > paragraph shouldn't be necessary. >> > >> > Opinions? >> >> I agree with removing it. >> >> >> //Peter >> >> -- >> coreboot mailing list: coreboot(a)coreboot.org >> http://www.coreboot.org/mailman/listinfo/coreboot > > > -- > coreboot mailing list: coreboot(a)coreboot.org > http://www.coreboot.org/mailman/listinfo/coreboot

1 0

Re: [coreboot] GPL license headers
by Peter Stuge 19 Oct '15

19 Oct '15

Patrick Georgi wrote: > The paragraph in question is: > ---- > You should have received a copy of the GNU General Public License > along with this program; if not, write to the Free Software > Foundation, Inc. > ---- > > Since the GPL is fairly well-known (incl where to find it), and our > tree already contains the license in the toplevel directory, that > paragraph shouldn't be necessary. > > Opinions? I agree with removing it. //Peter

2 1

GPL license headers
by Patrick Georgi 19 Oct '15

19 Oct '15

Hi all, we recently removed the FSF addresses from license headers in our files to avoid the maintenance of updating them every time the FSF decides to move their office. Now we also added checkpatch.pl that comes from Linux to automatically ensure some consistency across the tree, and it looks for removal of the entire paragraph. Now, that may just make sense and I'm willing to update the scripts to do that and update the tree. The paragraph in question is: ---- You should have received a copy of the GNU General Public License along with this program; if not, write to the Free Software Foundation, Inc. ---- Since the GPL is fairly well-known (incl where to find it), and our tree already contains the license in the toplevel directory, that paragraph shouldn't be necessary. Opinions? Patrick -- Google Germany GmbH, ABC-Str. 19, 20354 Hamburg Registergericht und -nummer: Hamburg, HRB 86891, Sitz der Gesellschaft: Hamburg Geschäftsführer: Matthew Scott Sucherman, Paul Terence Manicle

1 0

← Newer
1
...
7
8
9
10
11
12
13
14
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 October 2015