[coreboot] build service results for r6254

Dear coreboot readers! This is the automatic build system of coreboot. The developer oxygene checked in revision 6254 to the coreboot repository. This caused the following changes: Change Log: Improved GPIO setup for roda/rk886ex, and some documentation on what the GPIOs are used for.

[coreboot] [commit] r6255 - in trunk/src: arch/x86 pc80

Author: oxygene Date: Fri Jan 14 09:36:34 2011 New Revision: 6255 URL: https://tracker.coreboot.org/trac/coreboot/changeset/6255 Log: Disable CMOS recovery code for ROMCC boards as the CBFS code used for that feature is not ROMCC compatible. Fixes build errors introduced in r6253.

Re: [coreboot] [PATCH] SECC Pentium 2/3 users are gonna love this

On Tue, Jan 11, 2011 at 11:17:17PM -0500, Keith Hui wrote: Hi all, Here is the new L2 cache patch. Sign-off in the patch itself. Still very juicy and tasty at 25k. :D Also done is including cpu/intel/model_68x again in slot_1. Otherwise it will die with a Coppermine P3 installed. My boot log on

[coreboot] build service results for r6255

Dear coreboot readers! This is the automatic build system of coreboot. The developer oxygene checked in revision 6255 to the coreboot repository. This caused the following changes: Change Log: Disable CMOS recovery code for ROMCC boards as the CBFS code used for that feature is not ROMCC

[coreboot] [PATCH]Move option table to CBFS

Hi, currently the option table (which contains the metadata necessary to parse CMOS data properly) is stored in ramstage. This patch moves it to CBFS, making it available for inspection by utilities. The idea is to allow nvramtool to configure cmos defaults (which are stored in CBFS) by using

Re: [coreboot] [PATCH]Improve YABEL compatibility

Looks great to me... Acked-by: Pattrick Hueper phue...@hueper.net On Thu, Jan 13, 2011 at 12:00 PM, Joseph Smith j...@settoplinux.org wrote: On Thu, 13 Jan 2011 11:05:55 +0100, Patrick Georgi patrick.geo...@secunet.com wrote: Hi, attached patch improves compatibility of YABEL with

Re: [coreboot] [patch] AMD MCT DDR3 for register DIMMs

ping. Any comment before it is drowned? Zheng Date: Mon, 10 Jan 2011 13:29:49 +0800 From: zheng@amd.com To: coreboot@coreboot.org Subject: [coreboot] [patch] AMD MCT DDR3 for register DIMMs The code is tested on my board with register DIMMs. More tests need to be done. Please send the

[coreboot] [PATCH]Remove warnings in nvramtool

Hi, there are some strict aliasing related warnings in nvramtool. This patch fixes them. Signed-off-by: Patrick Georgi patrick.geo...@secunet.com Index: util/nvramtool/lbtable.c === --- util/nvramtool/lbtable.c (Revision 6254) +++

Re: [coreboot] [patch] AMD MCT DDR3 for register DIMMs

_ From: coreboot-bounces+scott=notabs@coreboot.org [mailto:coreboot-bounces+scott=notabs@coreboot.org] On Behalf Of Zheng Bao Sent: Friday, January 14, 2011 07:51 AM To: coreboot@coreboot.org Subject: Re: [coreboot] [patch] AMD MCT DDR3 for register DIMMs ]ping. ]Any comment

Re: [coreboot] abuild error

Hi Stefan, You wrote: It doesn't occur with the coreboot toolchain iirc though I did a fresh unmoddified checkout on r6255. Then i did buildgcc. The downloading/building of this beast takes more than an hour on my old laptop. :) Then i got the same result: nils@debian:~/coreboot_6255$

Re: [coreboot] [patch] AMD MCT DDR3 for register DIMMs

On Fri, Jan 14, 2011 at 7:23 AM, Scott Duplichan sc...@notabs.org wrote: From: coreboot-bounces+scott=notabs@coreboot.org [mailto:coreboot-bounces+scott=notabs@coreboot.org] On Behalf Of Zheng Bao Sent: Friday, January 14, 2011 07:51 AM To:

Re: [coreboot] [PATCH]Move option table to CBFS

* Patrick Georgi patrick.geo...@secunet.com [110114 11:39]: Hi, currently the option table (which contains the metadata necessary to parse CMOS data properly) is stored in ramstage. This patch moves it to CBFS, making it available for inspection by utilities. The idea is to allow

Re: [coreboot] [PATCH]Remove warnings in nvramtool

* Patrick Georgi patrick.geo...@secunet.com [110114 15:40]: Hi, there are some strict aliasing related warnings in nvramtool. This patch fixes them. Signed-off-by: Patrick Georgi patrick.geo...@secunet.com Acked-by: Stefan Reinauer ste...@coreboot.org -- coreboot mailing list:

Re: [coreboot] abuild error

* Nils njaco...@hetnet.nl [110114 17:36]: Hi Stefan, You wrote: It doesn't occur with the coreboot toolchain iirc though I did a fresh unmoddified checkout on r6255. Then i did buildgcc. The downloading/building of this beast takes more than an hour on my old laptop. :) Then i got the

Re: [coreboot] NULL pointer dereference in search_bus_device()

* Myles Watson myle...@gmail.com [110110 14:29]: On Mon, Jan 10, 2011 at 6:27 AM, Sven Schnelle sv...@stackframe.org wrote: Myles Watson myle...@gmail.com writes: diff --git a/src/devices/device_util.c b/src/devices/device_util.c index 9081a36..d761cba 100644 ---

Re: [coreboot] abuild error

OK i spent the whole evening experimenting with crossgcc again but i don't get it running. How can i check if the crosscompiler is used? cat .xcompile That doesn't find anything when executed in my topmost coreboot directory. I have tried : cd /util/crossgcc ./buildgcc this builds xgcc in

Re: [coreboot] abuild error

* Nils njaco...@hetnet.nl [110114 23:44]: OK i spent the whole evening experimenting with crossgcc again but i don't get it running. How can i check if the crosscompiler is used? cat .xcompile That doesn't find anything when executed in my topmost coreboot directory. This is

Re: [coreboot] NULL pointer dereference in search_bus_device()

That doesn't happen, because the if (subbus... is in the for loop, which checks for NULL. the search_bus_resources() is always called outside the for loop. You're right.  I should have looked at the code first, instead of just the patch.  There wasn't enough context. If there is no bus