coreboot May 2012

coreboot@coreboot.org

31 participants
287 discussions

Patch merged into coreboot/master: e3e901d Modify DMI init for IvyBridge
by gerrit＠coreboot.org 01 May '12

01 May '12

the following patch was just integrated into master: commit e3e901db657591603411402a1ceb581873480442 Author: Vincent Palatin <vpalatin(a)chromium.org> Date: Wed Mar 28 16:10:29 2012 -0700 Modify DMI init for IvyBridge The ASPM setting for the Direct Media Interface should no longer be done on Ivybridge/PantherPoint based systems. Change-Id: Id30de1beb1b162564048e76712736ccf7049dc7c Signed-off-by: Vincent Palatin <vpalatin(a)chromium.org> Build-Tested: build bot (Jenkins) at Tue May 1 04:08:11 2012, giving +1 See http://review.coreboot.org/969 for details. -gerrit

1 0

Patch merged into coreboot/master: e1b81de add new LPC controller device ID value
by gerrit＠coreboot.org 01 May '12

01 May '12

the following patch was just integrated into master: commit e1b81deaf1c17cb2c6723b8a35a595e0e6edf162 Author: Vadim Bendebury <vbendeb(a)chromium.org> Date: Sat Apr 7 02:11:36 2012 +0000 add new LPC controller device ID value This adds the PCI device id of the LPC controller identifying the QPRJ/QS stepping of the Panther Point southbridge. Change-Id: Idcaa7dbd30224e3690ea469c6cb74f75de287631 Signed-off-by: Vadim Bendebury <vbendeb(a)chromium.org> Build-Tested: build bot (Jenkins) at Tue May 1 03:52:28 2012, giving +1 See http://review.coreboot.org/968 for details. -gerrit

1 0

Patch merged into coreboot/master: 9297200 Allow device ID arrays in the PCI driver structure
by gerrit＠coreboot.org 01 May '12

01 May '12

the following patch was just integrated into master: commit 929720020030761885433ef7027005480812424b Author: Vadim Bendebury <vbendeb(a)chromium.org> Date: Tue Apr 24 12:53:19 2012 -0700 Allow device ID arrays in the PCI driver structure Many PCI devices share the very same driver despite having different PCI device IDs, which causes a lot of copy and paste of driver definitions. This change introduces a way to specify the array of acceptable device IDs in a single driver entry. As an example the Intel {Sandy|Ivy} Bridge SATA driver is being modified to use a single driver structure for all different SATA controller flavors, a few more Ivy Bridge IDs are being added as well. BUG=none TEST=manual . modified coreboot brought up an Ivy Bridge platform all the way to Linux login screen. Change-Id: I761c5611b93ef946053783f7a755e6c456dd6991 Signed-off-by: Vadim Bendebury <vbendeb(a)chromium.org> Reviewed-By: Patrick Georgi <patrick(a)georgi-clan.de> at Tue May 1 20:01:39 2012, giving +2 See http://review.coreboot.org/982 for details. -gerrit

1 0

Patch merged into coreboot/master: ea39273 Clean up Emerald Lake 2 mainboard directory
by gerrit＠coreboot.org 01 May '12

01 May '12

the following patch was just integrated into master: commit ea39273f80f64da5992b79e86ec950d6e0a3b420 Author: Gabe Black <gabeblack(a)google.com> Date: Fri Mar 30 14:33:02 2012 -0700 Clean up Emerald Lake 2 mainboard directory Change-Id: I4a64a56dda22050a31232807096e15565a665377 Signed-off-by: Gabe Black <gabeblack(a)google.com> Build-Tested: build bot (Jenkins) at Tue May 1 03:39:13 2012, giving +1 See http://review.coreboot.org/967 for details. -gerrit

1 0

Patch merged into coreboot/master: d7f3d69 Allow more CPU cores on Emerald Lake 2 CRB
by gerrit＠coreboot.org 01 May '12

01 May '12

the following patch was just integrated into master: commit d7f3d6996e3d67f69533a69d773e4fde897d347a Author: Stefan Reinauer <reinauer(a)chromium.org> Date: Wed Mar 28 13:19:15 2012 -0700 Allow more CPU cores on Emerald Lake 2 CRB The Emerald Lake 2 CRB can potentially have more than 8 CPU cores, so update the number of max cores accordingly. Change-Id: Ia42ed8a84916f66dfbfdf2a72cbbed5cea61899b Signed-off-by: Stefan Reinauer <reinauer(a)google.com> Build-Tested: build bot (Jenkins) at Tue May 1 03:27:01 2012, giving +1 See http://review.coreboot.org/966 for details. -gerrit

1 0

Patch merged into coreboot/master: db4ce07 Set up ChromeOS dev mode, recovery, and write protect GPIOs on Emerald Lake 2.
by gerrit＠coreboot.org 01 May '12

01 May '12

the following patch was just integrated into master: commit db4ce0735688cb695465e162974d88f95e8a4833 Author: Gabe Black <gabeblack(a)google.com> Date: Thu Mar 29 18:04:56 2012 -0700 Set up ChromeOS dev mode, recovery, and write protect GPIOs on Emerald Lake 2. The Emerald Lake 2 CRB wasn't designed with ChromeOS in mind, so there aren't any actual developer mode, recovery mode, or write protect switches, let alone GPIOs to read them from. Instead, I've commandeered signals connected to GPIOs which are for other things but which aren't used by hardware or, for instance, the EC to do something Coreboot doesn't control. The recovery mode switch is connected to GPIO 22 and is called BIOS_REC on the schematic. The name is at least very reminiscent of the right thing even if it's supposed to be used for something else. There's a jumper on the board labelled J8G1 which can force the line to ground, and if not, there's a switch on the front of the case which toggles its value. "RECOVER" is for recovery mode and "KEEP" is for normal mode. The developer mode switch is connected to GPIO 57 and is called SV_DET on the schematic. It's connected to a jumper labelled J8E2 on the board and, as far as I can tell, can't be controlled in any other way. When the jumper is in place and the pins are shorted, developer mode is selected. When the jumper is removed, normal mode is selected. The write protect is connected to GPIO 48 which is called BIOS_RESP on the schematic. It's connected to a jumper labelled J8E3 which, like j8E2, seems to be the only way to control the line it's on. When the jumper is in place, write protect is "disabled", and when it's in place it's "enabled" even though there's no functional difference. The input for the recovery mode switch was chosen because of the name it already had on the CRB, BIOS recovery, and because there's a switch to control it on the front of the case which makes it easy to get at. The jumpers for developer mode and recovery mode were chosen because there weren't very many options available, and of those these were next to each other which should make them easier to find and work with. It might be a good idea to wire toggle switches up to the pins of those jumpers so they'll be easy to identify, can be labelled, and would be easier to work with than little jumpers in the middle of the motherboard. Change-Id: Ib2c3dc05077dacfbede596dae143ed81a99dbebd Signed-off-by: Gabe Black <gabeblack(a)google.com> Build-Tested: build bot (Jenkins) at Tue May 1 03:15:02 2012, giving +1 See http://review.coreboot.org/965 for details. -gerrit

1 0

Patch merged into coreboot/master: faffebf Fix Sandybridge/Ivybridge mainboards according to code review
by gerrit＠coreboot.org 01 May '12

01 May '12

the following patch was just integrated into master: commit faffebf1bf40107559cf965e5d547c2a82d6db87 Author: Stefan Reinauer <reinauer(a)chromium.org> Date: Mon Apr 30 14:57:51 2012 -0700 Fix Sandybridge/Ivybridge mainboards according to code review This fixes a few cosmetics with the following three boards: - Intel Emerald Lake 2 - Samsung ChromeBook - Samsung ChromeBox The following issues were fixed: - rely on include path in ASL code instead of specifying relative paths - use updated ALIGN_CURRENT in acpi_tables.c - use preprocessor defines instead of hard coded values where possible Change-Id: Ia5941be3873aa84c30c13ff2f0428d1c52daa563 Signed-off-by: Stefan Reinauer <reinauer(a)google.com> Build-Tested: build bot (Jenkins) at Tue May 1 02:48:50 2012, giving +1 See http://review.coreboot.org/963 for details. -gerrit

1 0

bluetooth on Thinkpad X60s
by Motiejus Jakštys 01 May '12

01 May '12

Hi, bluetooth was not working for me on Thinkpad X60s. Rfkill was not showing the device and the bluetooth led was off. The way I managed to make it work is with this patch: diff --git a/src/ec/lenovo/h8/h8.c b/src/ec/lenovo/h8/h8.c index ecd34b2..b13d687 100644 --- a/src/ec/lenovo/h8/h8.c +++ b/src/ec/lenovo/h8/h8.c @@ -151,8 +151,7 @@ static void h8_enable(device_t dev) ec_write(H8_VOLUME_CONTROL, val); - if (!get_option(&val, "bluetooth")) - h8_bluetooth_enable(val); + h8_bluetooth_enable(1); if (!get_option(&val, "first_battery")) { tmp = ec_read(H8_CONFIG3); What would be a better way to do it? -- Motiejus Jakštys

1 0

New patch to review for coreboot: 1bf5cea Fix build with CMOS support on various platforms
by Patrick Georgi 01 May '12

01 May '12

Patrick Georgi (patrick(a)georgi-clan.de) just uploaded a new patch set to gerrit, which you can find at http://review.coreboot.org/983 -gerrit commit 1bf5cea9b5902d27029725611a947e09db529201 Author: Patrick Georgi <patrick(a)georgi-clan.de> Date: Tue May 1 12:10:45 2012 +0200 Fix build with CMOS support on various platforms When bringing in nvramtool as build_opt_tbl replacement, various platforms where left in the cold that don't provide direct IO support from userland (or at least not in a way we support). Build nvramtool without CMOS support when done as part of a coreboot build. We don't need to touch CMOS in this case. Change-Id: Icc88d1d32f10384867a5d44b065f9aa119bb0d50 Signed-off-by: Patrick Georgi <patrick(a)georgi-clan.de> --- util/nvramtool/Makefile | 2 +- util/nvramtool/Makefile.inc | 2 +- util/nvramtool/cmos_lowlevel.c | 9 ++++++++- 3 files changed, 10 insertions(+), 3 deletions(-) diff --git a/util/nvramtool/Makefile b/util/nvramtool/Makefile index 063bb1a..6723a48 100644 --- a/util/nvramtool/Makefile +++ b/util/nvramtool/Makefile @@ -24,7 +24,7 @@ CC = gcc STRIP = strip INSTALL = /usr/bin/install PREFIX = /usr/local -CFLAGS = -O2 -g -Wall -W -I. +CFLAGS = -O2 -g -Wall -W -I. -DCMOS_HAL=1 #CFLAGS = -Os -Wall CLI_OBJS = cli/nvramtool.o cli/opts.o diff --git a/util/nvramtool/Makefile.inc b/util/nvramtool/Makefile.inc index b356720..0acda04 100644 --- a/util/nvramtool/Makefile.inc +++ b/util/nvramtool/Makefile.inc @@ -37,7 +37,7 @@ nvramtoolobj := nvramtoolobj += cli/nvramtool.o cli/opts.o nvramtoolobj += cmos_lowlevel.o cmos_ops.o common.o compute_ip_checksum.o nvramtoolobj += hexdump.o input_file.o layout.o accessors/layout-common.o accessors/layout-text.o accessors/layout-bin.o lbtable.o -nvramtoolobj += reg_expr.o cbfs.o accessors/cmos-hw-unix.o accessors/cmos-mem.o +nvramtoolobj += reg_expr.o cbfs.o accessors/cmos-mem.o $(objutil)/nvramtool $(objutil)/nvramtool/accessors $(objutil)/nvramtool/cli: mkdir -p $@ diff --git a/util/nvramtool/cmos_lowlevel.c b/util/nvramtool/cmos_lowlevel.c index 58494f9..55b1879 100644 --- a/util/nvramtool/cmos_lowlevel.c +++ b/util/nvramtool/cmos_lowlevel.c @@ -39,14 +39,21 @@ /* Hardware Abstraction Layer: lowlevel byte-wise write access */ extern cmos_access_t cmos_hal, memory_hal; -static cmos_access_t *current_access = &cmos_hal; +static cmos_access_t *current_access = +#ifdef CMOS_HAL + &cmos_hal; +#else + &memory_hal; +#endif void select_hal(hal_t hal, void *data) { switch(hal) { +#ifdef CMOS_HAL case HAL_CMOS: current_access = &cmos_hal; break; +#endif case HAL_MEMORY: current_access = &memory_hal; break;

1 0

Re: [coreboot] Grub2 for Coreboot
by Nachiketh G 01 May '12

01 May '12

Hi Gregg, You were spot an about updating my build tools, I did that and also downgraded to a different version of Grub2 from the repository(1.99) and I was able to compile it! I now have an elf file ready to integrate with Coreboot. Thanks! Regards, Nachiketh On Sun, Apr 29, 2012 at 2:26 AM, Gregg Levine <gregg.drwho8(a)gmail.com>wrote: > On Sat, Apr 28, 2012 at 4:53 PM, Nachiketh G <nachiketh(a)gmail.com> wrote: > > Hi Greg, > > Please find the answers below: > > > > > > 1) What release of Grub2 did you select? (There are many numbered ones > > each running towards the 2.00 release one.) > >>> I checked out the latest version on > >>> http://bzr.savannah.gnu.org/r/grub/trunk/grub (Using bzr branch > >>> http://bzr.savannah.gnu.org/r/grub/trunk/grub) > > > > 2) Was this release of Grub2 retrieved from their storage point recently? > >>> Yes > > > > > > 3) Was Coreboot updated recently? > >>>I have checked out the latest copy of Coreboot from their repository as > >>> well, I have not yet compiled it though... thought I would compile the > >>> payload first before compiling Coreboot. > > > > > > 4) What is your build environment? What distribution is this on? > >>> I'm using a Ubuntu(2.6.38 Kernel) with a gcc (Ubuntu/Linaro > >>> 4.5.2-8ubuntu4) 4.5.2 compiler. > > > > Please let me know if there is something wrong in what I'm doing. > > Thanks! > > -Nachiketh > > > > > > On Sun, Apr 29, 2012 at 1:38 AM, Gregg Levine <gregg.drwho8(a)gmail.com> > > wrote: > >> > >> On Sat, Apr 28, 2012 at 3:07 PM, Nachiketh G <nachiketh(a)gmail.com> > wrote: > >> > Hi Folks, > >> > I'm new on Coreboot and I'm trying to compile Grub2 as a payload for > >> > Coreboot. I'm following the steps provided under > >> > http://www.coreboot.org/Talk:GRUB2 and i'm getting the following > >> > compilation > >> > error: > >> > > >> > cc1: warnings being treated as errors > >> > kern/i386/coreboot/init.c:45:9: error: unknown option after '#pragma > GCC > >> > diagnostic' kind > >> > make[3]: *** [kern/i386/coreboot/kernel_exec-init.o] Error 1 > >> > make[3]: Leaving directory `/home/nachiketh/coreboot/grub/grub-core' > >> > make[2]: *** [all] Error 2 > >> > make[2]: Leaving directory `/home/nachiketh/coreboot/grub/grub-core' > >> > make[1]: *** [all-recursive] Error 1 > >> > make[1]: Leaving directory `/home/nachiketh/coreboot/grub' > >> > make: *** [all] Error 2 > >> > > >> > Please let me know what I'm doing wrong or is there any step that has > >> > got > >> > missed out which is causing this problem. > >> > Thanks in advance! > >> > > >> > Regards, > >> > Nachiketh > >> > > >> > -- > >> > coreboot mailing list: coreboot(a)coreboot.org > >> > http://www.coreboot.org/mailman/listinfo/coreboot > >> > >> Hello! > >> Let's start it out this way: > >> 1) What release of Grub2 did you select? (There are many numbered ones > >> each running towards the 2.00 release one.) > >> > >> 2) Was this release of Grub2 retrieved from their storage point > recently? > >> > >> 3) Was Coreboot updated recently? > >> > >> 4) What is your build environment? What distribution is this on? > >> ------ > >> Gregg C Levine gregg.drwho8(a)gmail.com > >> "This signature fought the Time Wars, time and again." > > Hello! > About the only thing I can suggest is that there is yet another drift > to be explained inside the Ubuntu set you have. Please make sure your > build tools are properly updated. > > Also please consider keeping the list (both the help grub list and > this one) informed. > > ----- > Gregg C Levine gregg.drwho8(a)gmail.com > "This signature fought the Time Wars, time and again." > > -- > coreboot mailing list: coreboot(a)coreboot.org > http://www.coreboot.org/mailman/listinfo/coreboot >

1 0

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 May 2012