coreboot January 2015

coreboot@coreboot.org

41 participants
58 discussions

Re: [coreboot] coreboot code of conduct
by Carl-Daniel Hailfinger 19 Jan '15

19 Jan '15

Hi Marc, thanks for writing this up. On 16.01.2015 19:15, Marc Jones wrote: > A coreboot code of conduct has been posted on the wiki. > - http://www.coreboot.org/Code_of_Conduct > > I have written a blog post about why we have a code of conduct. > - http://blogs.coreboot.org/blog/2015/01/16/coreboot-code-of-conduct/ > > Feel free to give feedback on the policy and how else we can contribute to > a welcoming and collaborative environment. Given that the Code of … [View More]

2 1

Re: [coreboot] coreboot code of conduct
by Rudolf Marek 19 Jan '15

19 Jan '15

Hi all Just out of curiosity why do we need this? Was there some problem now or in the past? I just read the c c of c and I got this impression that we must be really bad that we need regulation & arbitration. If nothing like this ever happened I would like to see some statement that this c c of c is there just to comply with future problems (or similar like it is trendy ;) Thanks Rudolf

3 2

Re: [coreboot] Access to bug reports in Chromium bug tracker
by Paul Menzel 18 Jan '15

18 Jan '15

Am Donnerstag, den 15.01.2015, 16:08 -0800 schrieb David Hendricks: > On Thu, Jan 15, 2015 at 3:34 PM, Paul Menzel wrote: > > > > Issues which are closed now will almost certainly remain that way. > > > > Should those be referenced in the source code then? > > Probably not, but at some point it just doesn't matter. > > > Or should they at least be marked, for example with `(restricted)`? > > Not at the expense of time/effort that can be better … [View More]

2 1

Help With An R50e!
by waltermusic＠openmailbox.org 17 Jan '15

17 Jan '15

Good Day, I have an IBM ThinkPad R50e (and thinking about getting an X220). Would anybody be able to help me liberate my laptop, and install coreboot, and get rid of the proprietary BIOS that is present on it (and possibly do the same for the X220)? Thank You. Dennis

1 0

Lenovo X60: GRUB_GFXMODE=1024x768 only works with docking station connected
by Paul Menzel 17 Jan '15

17 Jan '15

Dear coreboot folks, on the Lenovo X60s, running coreboot with SeaBIOS as payload, adding the two lines below to GRUB’s configuration in `/etc/default/grub` GRUB_GFXMODE=1024x768 GRUB_GFXPAYLOAD_LINUX=keep and running `update-grub`, which updates GRUB 2.02~beta2-20 (Debian Jessie/testing) in the MBR, it does only work, when the laptop is attached to the docking station (nothing attached to the docking station). Those of you with a Lenovo system, could you please try to … [View More]

1 1

Re: [coreboot] Memory corruption on Resume from S3 Baytrail
by Jin, Huang 17 Jan '15

17 Jan '15

Gailu, I reproduced the same problem with Baytrail FSP. The memory "corrupted" starting 0x1000 after S3 resume is caused by reloading the VGA option rom. There is a Kconfig option called S3_VGA_ROM_RUN to skip reloading. Please refer to this change http://review.coreboot.org/#/c/715/ for additional information. Hope this solves the problem without reserving 64KB memory. Thanks, Aaron From: coreboot [mailto:coreboot-bounces@coreboot.org] On Behalf Of Gailu Singh Sent: Wednesday, December 10,… [View More]

1 0

Re: [coreboot] coreboot code of conduct
by Gregg Levine 17 Jan '15

17 Jan '15

Hello! No problem here Marc. My Linux Users Group adopted similar terms after some decidedly revolting problems surfaced several years previously, and so far its been working. As a matter of fact we may have decided to use the exact same ones..... ----- Gregg C Levine gregg.drwho8(a)gmail.com "This signature fought the Time Wars, time and again." On Fri, Jan 16, 2015 at 1:15 PM, Marc Jones <marcj303(a)gmail.com> wrote: > A coreboot code of conduct has been posted on the wiki. > … [View More]

1 0

coreboot code of conduct
by Marc Jones 16 Jan '15

16 Jan '15

A coreboot code of conduct has been posted on the wiki. - http://www.coreboot.org/Code_of_Conduct I have written a blog post about why we have a code of conduct. - http://blogs.coreboot.org/blog/2015/01/16/coreboot-code-of-conduct/ Feel free to give feedback on the policy and how else we can contribute to a welcoming and collaborative environment. Marc

1 0

Re: [coreboot] Access to bug reports in Chromium bug tracker
by Paul Menzel 16 Jan '15

16 Jan '15

Am Mittwoch, den 14.01.2015, 15:17 -0800 schrieb David Hendricks: > On Wed, Jan 14, 2015 at 2:11 PM, Paul Menzel wrote: > > looking at change set #8214 [1], it adds a comment with a reference to > > the Chromium bug tracker at <code.google.com>. > > > > http://crosbug.com/p/29117 > > > > Unfortunately access to view that is denied to me. > > We use two issue trackers, one which is public (which crosbug.com redirects > to) and one which … [View More]is private. The public tracker is used by default for > most cases, unless it's known that the subject matter will involve > confidential details. The particular issue you cited was likely public to > begin with, but later moved or restricted. Restrictions to issues filed on > the public tracker are sometimes added if resolving a bug involves > discussing confidential details about a chip or product (often in the form > of logs / debug output). > > > Looking at some of the items already in the upstream tree, most of them > > seem to be accessible though. > > > > $ git grep crosbug > > payloads/libpayload/drivers/serial/ipq806x.c: * See > > http://crosbug.com/p/29313 > > payloads/libpayload/drivers/timer/ipq806x.c: * > > http://crosbug.com/p/28880 for details. > > src/ec/google/chromeec/acpi/battery.asl: // a bug in the > > Linux kernel: http://crosbug.com/28747 > > src/ec/google/chromeec/ec_commands.h: * > > TODO(crosbug.com/p/11223): This is effectively useless; protocol > > is > > src/ec/google/chromeec/ec_commands.h: * > > TODO(crosbug.com/p/23570): These commands are deprecated, and > > will be > > src/ec/google/chromeec/ec_commands.h: * > > TODO(crosbug.com/p/23747): This is a confusing name, since it > > doesn't > > src/mainboard/samsung/lumpy/acpi_tables.c: * Provide > > option to enable for http://crosbug.com/p/7925 > > src/soc/intel/broadwell/acpi/gpio.asl: // Disabled due > > to IRQ storm: http://crosbug.com/p/29548 > > src/vendorcode/google/chromeos/vboot.c: * crosbug.com/17017 */ > > > > So my question is, is access granted to all these bugs eventually? > > Issues which are closed now will almost certainly remain that way. Should those be referenced in the source code then? Or should they at least be marked, for example with `(restricted)`? Thanks, Paul > > [1] http://review.coreboot.org/#/c/8214/1/src/mainboard/google/samus/romstage.c [View Less]

2 1

Access to bug reports in Chromium bug tracker
by Paul Menzel 14 Jan '15

14 Jan '15

Dear coreboot folks, looking at change set #8214 [1], it adds a comment with a reference to the Chromium bug tracker at <code.google.com>. http://crosbug.com/p/29117 Unfortunately access to view that is denied to me. Looking at some of the items already in the upstream tree, most of them seem to be accessible though. $ git grep crosbug payloads/libpayload/drivers/serial/ipq806x.c: * See http://crosbug.com/p/29313 payloads/libpayload/drivers/… [View More]

2 1

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

coreboot January 2015