From corey.osgood at gmail.com  Sat Nov  1 00:53:01 2008
From: corey.osgood at gmail.com (Corey Osgood)
Date: Fri, 31 Oct 2008 18:53:01 -0500
Subject: [coreboot] assistance with updating my bios
In-Reply-To: <e19d85410810311244v63ca954cg467fab2c99292962@mail.gmail.com>
References: <0015174c398affddac045a7a8752@google.com>
	<490A0001.7020002@gmx.net>
	<dd3c80060810300847q1ccec1f1lcd14c796032b44ff@mail.gmail.com>
	<0015174bddec27940b045a78db9d@google.com>
	<20081031183811.17509.qmail@stuge.se>
	<e19d85410810311244v63ca954cg467fab2c99292962@mail.gmail.com>
Message-ID: <dd3c80060810311653r11cd8709tac092187b19bc532@mail.gmail.com>

> cpu:         Socket370 Intel Pentium III Celeron
> northbridge:    Intel 82810E
> southbridge:    Intel 8281AA
> mainboard:    810 R 4.1 with lan
> super i/o:    Winbond W8362F-AW
> bios device:    ST M50FW002

Are you sure it's SPI?

-Corey

On 10/31/08, Elia Yehuda <z4ziggy at gmail.com> wrote:
> many thanks. i will try the patch tomorrow night when i'm back at home and
> report back.
>
> On Fri, Oct 31, 2008 at 8:38 PM, Peter Stuge <peter at stuge.se> wrote:
>
>> Hi,
>>
>> z4ziggy at gmail.com wrote:
>> > No EEPROM/flash device found.
>> > If you know which flash chip you have, and if this version of flashrom
>> > supports a similar flash chip, you can try to force read your chip. Run:
>> > flashrom -f -r -c similar_supported_flash_chip filename
>> >
>> > Note: flashrom can never write when the flash chip isn't found
>> > automatically.
>>
>> The above note is sadly not a joke.
>>
>>
>> Corey Osgood wrote:
>> > AFAIK, flashrom is broken for most ICHx.
>>
>> Not so, it works very well on a whole bunch of them.
>>
>>
>> Carl-Daniel Hailfinger wrote:
>> > On 30.10.2008 16:57, z4ziggy at gmail.com wrote:
>> > > any plans on fixing the issue or using alternative? is there a
>> > > way i can assist?
>> >
>> > Your flash chip is not supported. I'll add code for it.
>>
>> Some info Carl-Daniel didn't post, maybe it is informative;
>>
>> It seems that the system has a Winbond W25B40 or W25B40A flash chip.
>> This is an SPI flash chip, but it seems to behave just like a FWH
>> type chip.
>>
>> While waiting for Carl-Daniel you can try the attached patch. I doubt
>> it will work but you never know.
>>
>>
>> //Peter
>>
>> --
>> coreboot mailing list: coreboot at coreboot.org
>> http://www.coreboot.org/mailman/listinfo/coreboot
>>
>



From svn at coreboot.org  Sat Nov  1 01:53:01 2008
From: svn at coreboot.org (svn at coreboot.org)
Date: Sat,  1 Nov 2008 01:53:01 +0100
Subject: [coreboot] r976 - in coreboot-v3: arch/x86 arch/x86/via
	mainboard/via/epia-cn
Message-ID: <mailman.2365.1355071421.16123.coreboot@coreboot.org>

Author: rminnich
Date: 2008-11-01 01:53:01 +0100 (Sat, 01 Nov 2008)
New Revision: 976

Modified:
   coreboot-v3/arch/x86/stage1_mtrr.c
   coreboot-v3/arch/x86/via/stage1.c
   coreboot-v3/mainboard/via/epia-cn/Makefile
   coreboot-v3/mainboard/via/epia-cn/stage1.c
Log:
Get via to use standard mtrr init functions. Start to document them.

Signed-off-by: Ronald G. Minnich <rminnich at gmail.com>
Acked-by: Ronald G. Minnich <rminnich at gmail.com>




Modified: coreboot-v3/arch/x86/stage1_mtrr.c
===================================================================
--- coreboot-v3/arch/x86/stage1_mtrr.c	2008-10-31 22:43:02 UTC (rev 975)
+++ coreboot-v3/arch/x86/stage1_mtrr.c	2008-11-01 00:53:01 UTC (rev 976)
@@ -106,6 +106,10 @@
 	
 }
 
+/**
+ * Call this function early in stage1 to enable mtrrs, which will ensure 
+ * caching of ROM 
+ */
 void early_mtrr_init(void)
 {
 	static const unsigned long mtrr_msrs[] = {

Modified: coreboot-v3/arch/x86/via/stage1.c
===================================================================
--- coreboot-v3/arch/x86/via/stage1.c	2008-10-31 22:43:02 UTC (rev 975)
+++ coreboot-v3/arch/x86/via/stage1.c	2008-11-01 00:53:01 UTC (rev 976)
@@ -30,22 +30,7 @@
 #include <mtrr.h>
 #include <via_c7.h>
 
-#ifdef NO_IDEA_WHETHER_THIS_IS_RELEVANT_ON_C7
 /**
- * Set the MTRR for initial ram access. 
- * be warned, this will be used by core other than core 0/node 0 or core0/node0 when cpu_reset. 
- * This warning has some significance I don't yet understand. 
- */
-void set_init_ram_access(void)
-{
-	set_var_mtrr(0, 0x00000000, CONFIG_CBMEMK << 10, MTRR_TYPE_WRBACK);
-}
-#endif
-
-#define __stringify_1(x)	#x
-#define __stringify(x)		__stringify_1(x)
-
-/**
  * Disable Cache As RAM (CAR) after memory is setup.
  */
 void disable_car(void)

Modified: coreboot-v3/mainboard/via/epia-cn/Makefile
===================================================================
--- coreboot-v3/mainboard/via/epia-cn/Makefile	2008-10-31 22:43:02 UTC (rev 975)
+++ coreboot-v3/mainboard/via/epia-cn/Makefile	2008-11-01 00:53:01 UTC (rev 976)
@@ -18,7 +18,9 @@
 ## Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA  02110-1301 USA
 ##
 
-STAGE0_MAINBOARD_SRC := $(src)/mainboard/$(MAINBOARDDIR)/stage1.c
+STAGE0_MAINBOARD_SRC :=  $(src)/lib/clog2.c \
+			$(src)/arch/x86/stage1_mtrr.c \
+			$(src)/mainboard/$(MAINBOARDDIR)/stage1.c
 
 INITRAM_SRC =   $(src)/mainboard/$(MAINBOARDDIR)/initram.c \
 		$(src)/northbridge/via/cn700/initram.c \

Modified: coreboot-v3/mainboard/via/epia-cn/stage1.c
===================================================================
--- coreboot-v3/mainboard/via/epia-cn/stage1.c	2008-10-31 22:43:02 UTC (rev 975)
+++ coreboot-v3/mainboard/via/epia-cn/stage1.c	2008-11-01 00:53:01 UTC (rev 976)
@@ -36,10 +36,15 @@
 
 void hardware_stage1(void)
 {
+	void early_mtrr_init(void);
 	void vt1211_enable_serial(u8 dev, u8 serial, u16 iobase);
 	u32 dev;
 
 	post_code(POST_START_OF_MAIN);
+
+	/* do this or watch the system run slowly */
+	early_mtrr_init();
+
 	vt1211_enable_serial(0x2e, 2, 0x3f8);
 	
 	/* Enable multifunction for northbridge. */




From c-d.hailfinger.devel.2006 at gmx.net  Sat Nov  1 02:13:24 2008
From: c-d.hailfinger.devel.2006 at gmx.net (Carl-Daniel Hailfinger)
Date: Sat, 01 Nov 2008 02:13:24 +0100
Subject: [coreboot] via epia-cn and v3
In-Reply-To: <13426df10810311540v1e5efc1ayd0e5dc22bf448a3@mail.gmail.com>
References: <13426df10810311540v1e5efc1ayd0e5dc22bf448a3@mail.gmail.com>
Message-ID: <490BAD34.9080108@gmx.net>

On 31.10.2008 23:40, ron minnich wrote:
> coreboot-3.0.974 Fri Oct 31 15:11:04 PDT 2008 starting... (console_loglevel=8)
> [...]
> Done RAM init code
> In hardware_stage1()
>
> resets at this point and restarts. Very slow, as though it were not caching ROM?
>   

Yes, ROM may not be cached. My primary goal was to get this to work at all.

And the reset issue is currently my highest priority problem to resolve.
I believe I may have to disappoint you and change the memcpy to an
open-coded copy in asm.

Regards,
Carl-Daniel

-- 
http://www.hailfinger.org/




From rminnich at gmail.com  Sat Nov  1 02:19:12 2008
From: rminnich at gmail.com (ron minnich)
Date: Fri, 31 Oct 2008 18:19:12 -0700
Subject: [coreboot] via epia-cn and v3
In-Reply-To: <490BAD34.9080108@gmx.net>
References: <13426df10810311540v1e5efc1ayd0e5dc22bf448a3@mail.gmail.com>
	<490BAD34.9080108@gmx.net>
Message-ID: <13426df10810311819p7841f53fr91c302f93db2080@mail.gmail.com>

On Fri, Oct 31, 2008 at 6:13 PM, Carl-Daniel Hailfinger
<c-d.hailfinger.devel.2006 at gmx.net> wrote:

> Yes, ROM may not be cached. My primary goal was to get this to work at all.

ROM should now be cached.

>
> And the reset issue is currently my highest priority problem to resolve.
> I believe I may have to disappoint you and change the memcpy to an
> open-coded copy in asm.


it happens. There are times when gcc is the wrong way to go :-)

ron



From c-d.hailfinger.devel.2006 at gmx.net  Sat Nov  1 02:50:47 2008
From: c-d.hailfinger.devel.2006 at gmx.net (Carl-Daniel Hailfinger)
Date: Sat, 01 Nov 2008 02:50:47 +0100
Subject: [coreboot] [PATCH] CN700/VT8237R stage2
In-Reply-To: <dd3c80060810301736y123561c7p7dc1646397f13732@mail.gmail.com>
References: <dd3c80060810290102o7b28a867y4b103e8b6ee4c621@mail.gmail.com>	
	<490A4CC6.2070602@gmx.net>
	<dd3c80060810301736y123561c7p7dc1646397f13732@mail.gmail.com>
Message-ID: <490BB5F7.508@gmx.net>

On 31.10.2008 01:36, Corey Osgood wrote:
> debug log attached.
>   

Thanks, the log was really informative. Can you apply the following
patch and report back? Yes, the patch is evil, but it may help track
down the issue.

Regards,
Carl-Daniel

Index: arch/x86/via/stage1.c
===================================================================
--- arch/x86/via/stage1.c	(Revision 976)
+++ arch/x86/via/stage1.c	(Arbeitskopie)
@@ -29,12 +29,14 @@
 #include <string.h>
 #include <mtrr.h>
 #include <via_c7.h>
+#include <uart8250.h>
 
 /**
  * Disable Cache As RAM (CAR) after memory is setup.
  */
 void disable_car(void)
 {
+	printk(BIOS_DEBUG, "disable_car entry\n");
 	/* Determine new global variable location. Stack organization from top
 	 * Top 4 bytes are reserved
 	 * Pointer to global variables
@@ -45,9 +47,19 @@
 	const struct global_vars *newlocation = (struct global_vars *)((RAM_STACK_BASE - sizeof(struct global_vars *) - sizeof(struct global_vars)) & ~0x7);
 	/* Copy global variables to new location. */
 	memcpy(newlocation, global_vars(), sizeof(struct global_vars));
+	printk(BIOS_DEBUG, "disable_car global_vars copy done\n");
 	/* Set the new global variable pointer. */
 	*(struct global_vars **)(RAM_STACK_BASE - sizeof(struct global_vars *)) = newlocation;
 
+	printk(BIOS_DEBUG, "disable_car global_vars pointer adjusted, entering asm code...");
+	printk(BIOS_DEBUG, "now..........................................................................\n");
+	uart8250_tx_byte(TTYSx_BASE, 'F');
+	uart8250_tx_byte(TTYSx_BASE, 'O');
+	uart8250_tx_byte(TTYSx_BASE, 'O');
+	uart8250_tx_byte(TTYSx_BASE, 'B');
+	uart8250_tx_byte(TTYSx_BASE, 'A');
+	uart8250_tx_byte(TTYSx_BASE, 'R');
+	uart8250_tx_byte(TTYSx_BASE, '\n');
 	__asm__ __volatile__(
 	/* We don't need cache as ram for now on */
 	/* disable cache */
@@ -55,6 +67,52 @@
 	"	orl    $(0x1<<30),%%eax		\n"
 	"	movl    %%eax, %%cr0		\n"
 
+	"	movl	$99, %%edx\n"
+	"	movl	$1016, %%eax\n"
+	"	call	uart8250_tx_byte\n"
+	"	movl	$97, %%edx\n"
+	"	movl	$1016, %%eax\n"
+	"	call	uart8250_tx_byte\n"
+	"	movl	$99, %%edx\n"
+	"	movl	$1016, %%eax\n"
+	"	call	uart8250_tx_byte\n"
+	"	movl	$104, %%edx\n"
+	"	movl	$1016, %%eax\n"
+	"	call	uart8250_tx_byte\n"
+	"	movl	$101, %%edx\n"
+	"	movl	$1016, %%eax\n"
+	"	call	uart8250_tx_byte\n"
+	"	movl	$32, %%edx\n"
+	"	movl	$1016, %%eax\n"
+	"	call	uart8250_tx_byte\n"
+	"	movl	$100, %%edx\n"
+	"	movl	$1016, %%eax\n"
+	"	call	uart8250_tx_byte\n"
+	"	movl	$105, %%edx\n"
+	"	movl	$1016, %%eax\n"
+	"	call	uart8250_tx_byte\n"
+	"	movl	$115, %%edx\n"
+	"	movl	$1016, %%eax\n"
+	"	call	uart8250_tx_byte\n"
+	"	movl	$97, %%edx\n"
+	"	movl	$1016, %%eax\n"
+	"	call	uart8250_tx_byte\n"
+	"	movl	$98, %%edx\n"
+	"	movl	$1016, %%eax\n"
+	"	call	uart8250_tx_byte\n"
+	"	movl	$108, %%edx\n"
+	"	movl	$1016, %%eax\n"
+	"	call	uart8250_tx_byte\n"
+	"	movl	$101, %%edx\n"
+	"	movl	$1016, %%eax\n"
+	"	call	uart8250_tx_byte\n"
+	"	movl	$100, %%edx\n"
+	"	movl	$1016, %%eax\n"
+	"	call	uart8250_tx_byte\n"
+	"	movl	$10, %%edx\n"
+	"	movl	$1016, %%eax\n"
+	"	call	uart8250_tx_byte\n"
+
 	/* disable fixed mtrr from now on, it will be enabled by coreboot_ram again*/
 	"	movl    %[_SYSCFG_MSR], %%ecx	\n"
 	"	rdmsr				\n"
@@ -64,6 +122,70 @@
 	"	wrmsr				\n"
 #warning Must clear MTRR 0x200 and 0x201
 
+	"	movl	$102, %%edx\n"
+	"	movl	$1016, %%eax\n"
+	"	call	uart8250_tx_byte\n"
+	"	movl	$105, %%edx\n"
+	"	movl	$1016, %%eax\n"
+	"	call	uart8250_tx_byte\n"
+	"	movl	$120, %%edx\n"
+	"	movl	$1016, %%eax\n"
+	"	call	uart8250_tx_byte\n"
+	"	movl	$101, %%edx\n"
+	"	movl	$1016, %%eax\n"
+	"	call	uart8250_tx_byte\n"
+	"	movl	$100, %%edx\n"
+	"	movl	$1016, %%eax\n"
+	"	call	uart8250_tx_byte\n"
+	"	movl	$32, %%edx\n"
+	"	movl	$1016, %%eax\n"
+	"	call	uart8250_tx_byte\n"
+	"	movl	$109, %%edx\n"
+	"	movl	$1016, %%eax\n"
+	"	call	uart8250_tx_byte\n"
+	"	movl	$116, %%edx\n"
+	"	movl	$1016, %%eax\n"
+	"	call	uart8250_tx_byte\n"
+	"	movl	$114, %%edx\n"
+	"	movl	$1016, %%eax\n"
+	"	call	uart8250_tx_byte\n"
+	"	movl	$114, %%edx\n"
+	"	movl	$1016, %%eax\n"
+	"	call	uart8250_tx_byte\n"
+	"	movl	$32, %%edx\n"
+	"	movl	$1016, %%eax\n"
+	"	call	uart8250_tx_byte\n"
+	"	movl	$100, %%edx\n"
+	"	movl	$1016, %%eax\n"
+	"	call	uart8250_tx_byte\n"
+	"	movl	$105, %%edx\n"
+	"	movl	$1016, %%eax\n"
+	"	call	uart8250_tx_byte\n"
+	"	movl	$115, %%edx\n"
+	"	movl	$1016, %%eax\n"
+	"	call	uart8250_tx_byte\n"
+	"	movl	$97, %%edx\n"
+	"	movl	$1016, %%eax\n"
+	"	call	uart8250_tx_byte\n"
+	"	movl	$98, %%edx\n"
+	"	movl	$1016, %%eax\n"
+	"	call	uart8250_tx_byte\n"
+	"	movl	$108, %%edx\n"
+	"	movl	$1016, %%eax\n"
+	"	call	uart8250_tx_byte\n"
+	"	movl	$101, %%edx\n"
+	"	movl	$1016, %%eax\n"
+	"	call	uart8250_tx_byte\n"
+	"	movl	$100, %%edx\n"
+	"	movl	$1016, %%eax\n"
+	"	call	uart8250_tx_byte\n"
+	"	movl	$10, %%edx\n"
+	"	movl	$1016, %%eax\n"
+	"	call	uart8250_tx_byte\n"
+	"	movl	$0000024, %%edx\n"
+	"	movl	$1016, %%eax\n"
+	"	call	uart8250_tx_byte\n"
+
 	/* Set the default memory type and disable fixed and enable variable MTRRs */
 	"	movl    %[_MTRRdefType_MSR], %%ecx	\n"
 	"	xorl    %%edx, %%edx		\n"
@@ -71,14 +193,214 @@
 	"	movl    $0x00000800, %%eax	\n"
 	"	wrmsr				\n"
 
+	"	movl	$118, %%edx\n"
+	"	movl	$1016, %%eax\n"
+	"	call	uart8250_tx_byte\n"
+	"	movl	$97, %%edx\n"
+	"	movl	$1016, %%eax\n"
+	"	call	uart8250_tx_byte\n"
+	"	movl	$114, %%edx\n"
+	"	movl	$1016, %%eax\n"
+	"	call	uart8250_tx_byte\n"
+	"	movl	$105, %%edx\n"
+	"	movl	$1016, %%eax\n"
+	"	call	uart8250_tx_byte\n"
+	"	movl	$97, %%edx\n"
+	"	movl	$1016, %%eax\n"
+	"	call	uart8250_tx_byte\n"
+	"	movl	$98, %%edx\n"
+	"	movl	$1016, %%eax\n"
+	"	call	uart8250_tx_byte\n"
+	"	movl	$108, %%edx\n"
+	"	movl	$1016, %%eax\n"
+	"	call	uart8250_tx_byte\n"
+	"	movl	$101, %%edx\n"
+	"	movl	$1016, %%eax\n"
+	"	call	uart8250_tx_byte\n"
+	"	movl	$32, %%edx\n"
+	"	movl	$1016, %%eax\n"
+	"	call	uart8250_tx_byte\n"
+	"	movl	$109, %%edx\n"
+	"	movl	$1016, %%eax\n"
+	"	call	uart8250_tx_byte\n"
+	"	movl	$116, %%edx\n"
+	"	movl	$1016, %%eax\n"
+	"	call	uart8250_tx_byte\n"
+	"	movl	$114, %%edx\n"
+	"	movl	$1016, %%eax\n"
+	"	call	uart8250_tx_byte\n"
+	"	movl	$114, %%edx\n"
+	"	movl	$1016, %%eax\n"
+	"	call	uart8250_tx_byte\n"
+	"	movl	$115, %%edx\n"
+	"	movl	$1016, %%eax\n"
+	"	call	uart8250_tx_byte\n"
+	"	movl	$32, %%edx\n"
+	"	movl	$1016, %%eax\n"
+	"	call	uart8250_tx_byte\n"
+	"	movl	$101, %%edx\n"
+	"	movl	$1016, %%eax\n"
+	"	call	uart8250_tx_byte\n"
+	"	movl	$110, %%edx\n"
+	"	movl	$1016, %%eax\n"
+	"	call	uart8250_tx_byte\n"
+	"	movl	$97, %%edx\n"
+	"	movl	$1016, %%eax\n"
+	"	call	uart8250_tx_byte\n"
+	"	movl	$98, %%edx\n"
+	"	movl	$1016, %%eax\n"
+	"	call	uart8250_tx_byte\n"
+	"	movl	$108, %%edx\n"
+	"	movl	$1016, %%eax\n"
+	"	call	uart8250_tx_byte\n"
+	"	movl	$101, %%edx\n"
+	"	movl	$1016, %%eax\n"
+	"	call	uart8250_tx_byte\n"
+	"	movl	$100, %%edx\n"
+	"	movl	$1016, %%eax\n"
+	"	call	uart8250_tx_byte\n"
+	"	movl	$10, %%edx\n"
+	"	movl	$1016, %%eax\n"
+	"	call	uart8250_tx_byte\n"
+	"	movl	$0000027, %%edx\n"
+	"	movl	$1016, %%eax\n"
+	"	call	uart8250_tx_byte\n"
+
 	/* enable cache */
 	"	movl    %%cr0, %%eax		\n"
 	"	andl    $0x9fffffff,%%eax	\n"
 	"	movl    %%eax, %%cr0		\n"
 
+	"	movl	$99, %%edx\n"
+	"	movl	$1016, %%eax\n"
+	"	call	uart8250_tx_byte\n"
+	"	movl	$97, %%edx\n"
+	"	movl	$1016, %%eax\n"
+	"	call	uart8250_tx_byte\n"
+	"	movl	$99, %%edx\n"
+	"	movl	$1016, %%eax\n"
+	"	call	uart8250_tx_byte\n"
+	"	movl	$104, %%edx\n"
+	"	movl	$1016, %%eax\n"
+	"	call	uart8250_tx_byte\n"
+	"	movl	$101, %%edx\n"
+	"	movl	$1016, %%eax\n"
+	"	call	uart8250_tx_byte\n"
+	"	movl	$32, %%edx\n"
+	"	movl	$1016, %%eax\n"
+	"	call	uart8250_tx_byte\n"
+	"	movl	$101, %%edx\n"
+	"	movl	$1016, %%eax\n"
+	"	call	uart8250_tx_byte\n"
+	"	movl	$110, %%edx\n"
+	"	movl	$1016, %%eax\n"
+	"	call	uart8250_tx_byte\n"
+	"	movl	$97, %%edx\n"
+	"	movl	$1016, %%eax\n"
+	"	call	uart8250_tx_byte\n"
+	"	movl	$98, %%edx\n"
+	"	movl	$1016, %%eax\n"
+	"	call	uart8250_tx_byte\n"
+	"	movl	$108, %%edx\n"
+	"	movl	$1016, %%eax\n"
+	"	call	uart8250_tx_byte\n"
+	"	movl	$101, %%edx\n"
+	"	movl	$1016, %%eax\n"
+	"	call	uart8250_tx_byte\n"
+	"	movl	$100, %%edx\n"
+	"	movl	$1016, %%eax\n"
+	"	call	uart8250_tx_byte\n"
+	"	movl	$10, %%edx\n"
+	"	movl	$1016, %%eax\n"
+	"	call	uart8250_tx_byte\n"
+	"	movl	$0000016, %%edx\n"
+	"	movl	$1016, %%eax\n"
+	"	call	uart8250_tx_byte\n"
+
 	"	wbinvd				\n"
 
+	"	movl	$119, %%edx\n"
+	"	movl	$1016, %%eax\n"
+	"	call	uart8250_tx_byte\n"
+	"	movl	$98, %%edx\n"
+	"	movl	$1016, %%eax\n"
+	"	call	uart8250_tx_byte\n"
+	"	movl	$105, %%edx\n"
+	"	movl	$1016, %%eax\n"
+	"	call	uart8250_tx_byte\n"
+	"	movl	$110, %%edx\n"
+	"	movl	$1016, %%eax\n"
+	"	call	uart8250_tx_byte\n"
+	"	movl	$118, %%edx\n"
+	"	movl	$1016, %%eax\n"
+	"	call	uart8250_tx_byte\n"
+	"	movl	$100, %%edx\n"
+	"	movl	$1016, %%eax\n"
+	"	call	uart8250_tx_byte\n"
+	"	movl	$32, %%edx\n"
+	"	movl	$1016, %%eax\n"
+	"	call	uart8250_tx_byte\n"
+	"	movl	$100, %%edx\n"
+	"	movl	$1016, %%eax\n"
+	"	call	uart8250_tx_byte\n"
+	"	movl	$111, %%edx\n"
+	"	movl	$1016, %%eax\n"
+	"	call	uart8250_tx_byte\n"
+	"	movl	$110, %%edx\n"
+	"	movl	$1016, %%eax\n"
+	"	call	uart8250_tx_byte\n"
+	"	movl	$101, %%edx\n"
+	"	movl	$1016, %%eax\n"
+	"	call	uart8250_tx_byte\n"
+	"	movl	$10, %%edx\n"
+	"	movl	$1016, %%eax\n"
+	"	call	uart8250_tx_byte\n"
+	"	movl	$0000014, %%edx\n"
+	"	movl	$1016, %%eax\n"
+	"	call	uart8250_tx_byte\n"
+
 	"	movl	%[newesp], %%esp	\n"
+
+	"	movl	$101, %%edx\n"
+	"	movl	$1016, %%eax\n"
+	"	call	uart8250_tx_byte\n"
+	"	movl	$115, %%edx\n"
+	"	movl	$1016, %%eax\n"
+	"	call	uart8250_tx_byte\n"
+	"	movl	$112, %%edx\n"
+	"	movl	$1016, %%eax\n"
+	"	call	uart8250_tx_byte\n"
+	"	movl	$32, %%edx\n"
+	"	movl	$1016, %%eax\n"
+	"	call	uart8250_tx_byte\n"
+	"	movl	$99, %%edx\n"
+	"	movl	$1016, %%eax\n"
+	"	call	uart8250_tx_byte\n"
+	"	movl	$104, %%edx\n"
+	"	movl	$1016, %%eax\n"
+	"	call	uart8250_tx_byte\n"
+	"	movl	$97, %%edx\n"
+	"	movl	$1016, %%eax\n"
+	"	call	uart8250_tx_byte\n"
+	"	movl	$110, %%edx\n"
+	"	movl	$1016, %%eax\n"
+	"	call	uart8250_tx_byte\n"
+	"	movl	$103, %%edx\n"
+	"	movl	$1016, %%eax\n"
+	"	call	uart8250_tx_byte\n"
+	"	movl	$101, %%edx\n"
+	"	movl	$1016, %%eax\n"
+	"	call	uart8250_tx_byte\n"
+	"	movl	$100, %%edx\n"
+	"	movl	$1016, %%eax\n"
+	"	call	uart8250_tx_byte\n"
+	"	movl	$10, %%edx\n"
+	"	movl	$1016, %%eax\n"
+	"	call	uart8250_tx_byte\n"
+	"	movl	$0000014, %%edx\n"
+	"	movl	$1016, %%eax\n"
+	"	call	uart8250_tx_byte\n"
+
 	"	call stage1_phase3		\n"
 	:: [newesp] "i" (newlocation),
 	 [_SYSCFG_MSR] "i" (SYSCFG_MSR),
Index: arch/x86/amd/k8/stage1.c
===================================================================
Index: arch/x86/stage1.c
===================================================================
--- arch/x86/stage1.c	(Revision 976)
+++ arch/x86/stage1.c	(Arbeitskopie)
@@ -263,6 +263,7 @@
 #ifdef CONFIG_CONSOLE_BUFFER
 	/* Move the printk buffer to PRINTK_BUF_ADDR_RAM */
 	printk_buffer_move((void *)PRINTK_BUF_ADDR_RAM, PRINTK_BUF_SIZE_RAM);
+	printk(BIOS_DEBUG, "Done printk() buffer move\n");
 #endif
 	/* Turn off Cache-As-Ram */
 	disable_car();


-- 
http://www.hailfinger.org/




From c-d.hailfinger.devel.2006 at gmx.net  Sat Nov  1 02:59:18 2008
From: c-d.hailfinger.devel.2006 at gmx.net (Carl-Daniel Hailfinger)
Date: Sat, 01 Nov 2008 02:59:18 +0100
Subject: [coreboot] [PATCH] CN700/VT8237R stage2
In-Reply-To: <490BB5F7.508@gmx.net>
References: <dd3c80060810290102o7b28a867y4b103e8b6ee4c621@mail.gmail.com>		<490A4CC6.2070602@gmx.net>	<dd3c80060810301736y123561c7p7dc1646397f13732@mail.gmail.com>
	<490BB5F7.508@gmx.net>
Message-ID: <490BB7F6.9030509@gmx.net>

On 01.11.2008 02:50, Carl-Daniel Hailfinger wrote:
> On 31.10.2008 01:36, Corey Osgood wrote:
>   
>> debug log attached.
>>   
>>     
>
> Thanks, the log was really informative. Can you apply the following
> patch and report back? Yes, the patch is evil, but it may help track
> down the issue.
>   

And the patch had minor garbage in it. New patch follows:

Index: arch/x86/via/stage1.c
===================================================================
--- arch/x86/via/stage1.c	(Revision 976)
+++ arch/x86/via/stage1.c	(Arbeitskopie)
@@ -29,12 +29,14 @@
 #include <string.h>
 #include <mtrr.h>
 #include <via_c7.h>
+#include <uart8250.h>
 
 /**
  * Disable Cache As RAM (CAR) after memory is setup.
  */
 void disable_car(void)
 {
+	printk(BIOS_DEBUG, "disable_car entry\n");
 	/* Determine new global variable location. Stack organization from top
 	 * Top 4 bytes are reserved
 	 * Pointer to global variables
@@ -45,9 +47,19 @@
 	const struct global_vars *newlocation = (struct global_vars *)((RAM_STACK_BASE - sizeof(struct global_vars *) - sizeof(struct global_vars)) & ~0x7);
 	/* Copy global variables to new location. */
 	memcpy(newlocation, global_vars(), sizeof(struct global_vars));
+	printk(BIOS_DEBUG, "disable_car global_vars copy done\n");
 	/* Set the new global variable pointer. */
 	*(struct global_vars **)(RAM_STACK_BASE - sizeof(struct global_vars *)) = newlocation;
 
+	printk(BIOS_DEBUG, "disable_car global_vars pointer adjusted, entering asm code...");
+	printk(BIOS_DEBUG, "now..........................................................................\n");
+	uart8250_tx_byte(TTYSx_BASE, 'F');
+	uart8250_tx_byte(TTYSx_BASE, 'O');
+	uart8250_tx_byte(TTYSx_BASE, 'O');
+	uart8250_tx_byte(TTYSx_BASE, 'B');
+	uart8250_tx_byte(TTYSx_BASE, 'A');
+	uart8250_tx_byte(TTYSx_BASE, 'R');
+	uart8250_tx_byte(TTYSx_BASE, '\n');
 	__asm__ __volatile__(
 	/* We don't need cache as ram for now on */
 	/* disable cache */
@@ -55,6 +67,52 @@
 	"	orl    $(0x1<<30),%%eax		\n"
 	"	movl    %%eax, %%cr0		\n"
 
+	"	movl	$99, %%edx\n"
+	"	movl	$1016, %%eax\n"
+	"	call	uart8250_tx_byte\n"
+	"	movl	$97, %%edx\n"
+	"	movl	$1016, %%eax\n"
+	"	call	uart8250_tx_byte\n"
+	"	movl	$99, %%edx\n"
+	"	movl	$1016, %%eax\n"
+	"	call	uart8250_tx_byte\n"
+	"	movl	$104, %%edx\n"
+	"	movl	$1016, %%eax\n"
+	"	call	uart8250_tx_byte\n"
+	"	movl	$101, %%edx\n"
+	"	movl	$1016, %%eax\n"
+	"	call	uart8250_tx_byte\n"
+	"	movl	$32, %%edx\n"
+	"	movl	$1016, %%eax\n"
+	"	call	uart8250_tx_byte\n"
+	"	movl	$100, %%edx\n"
+	"	movl	$1016, %%eax\n"
+	"	call	uart8250_tx_byte\n"
+	"	movl	$105, %%edx\n"
+	"	movl	$1016, %%eax\n"
+	"	call	uart8250_tx_byte\n"
+	"	movl	$115, %%edx\n"
+	"	movl	$1016, %%eax\n"
+	"	call	uart8250_tx_byte\n"
+	"	movl	$97, %%edx\n"
+	"	movl	$1016, %%eax\n"
+	"	call	uart8250_tx_byte\n"
+	"	movl	$98, %%edx\n"
+	"	movl	$1016, %%eax\n"
+	"	call	uart8250_tx_byte\n"
+	"	movl	$108, %%edx\n"
+	"	movl	$1016, %%eax\n"
+	"	call	uart8250_tx_byte\n"
+	"	movl	$101, %%edx\n"
+	"	movl	$1016, %%eax\n"
+	"	call	uart8250_tx_byte\n"
+	"	movl	$100, %%edx\n"
+	"	movl	$1016, %%eax\n"
+	"	call	uart8250_tx_byte\n"
+	"	movl	$10, %%edx\n"
+	"	movl	$1016, %%eax\n"
+	"	call	uart8250_tx_byte\n"
+
 	/* disable fixed mtrr from now on, it will be enabled by coreboot_ram again*/
 	"	movl    %[_SYSCFG_MSR], %%ecx	\n"
 	"	rdmsr				\n"
@@ -64,6 +122,67 @@
 	"	wrmsr				\n"
 #warning Must clear MTRR 0x200 and 0x201
 
+	"	movl	$102, %%edx\n"
+	"	movl	$1016, %%eax\n"
+	"	call	uart8250_tx_byte\n"
+	"	movl	$105, %%edx\n"
+	"	movl	$1016, %%eax\n"
+	"	call	uart8250_tx_byte\n"
+	"	movl	$120, %%edx\n"
+	"	movl	$1016, %%eax\n"
+	"	call	uart8250_tx_byte\n"
+	"	movl	$101, %%edx\n"
+	"	movl	$1016, %%eax\n"
+	"	call	uart8250_tx_byte\n"
+	"	movl	$100, %%edx\n"
+	"	movl	$1016, %%eax\n"
+	"	call	uart8250_tx_byte\n"
+	"	movl	$32, %%edx\n"
+	"	movl	$1016, %%eax\n"
+	"	call	uart8250_tx_byte\n"
+	"	movl	$109, %%edx\n"
+	"	movl	$1016, %%eax\n"
+	"	call	uart8250_tx_byte\n"
+	"	movl	$116, %%edx\n"
+	"	movl	$1016, %%eax\n"
+	"	call	uart8250_tx_byte\n"
+	"	movl	$114, %%edx\n"
+	"	movl	$1016, %%eax\n"
+	"	call	uart8250_tx_byte\n"
+	"	movl	$114, %%edx\n"
+	"	movl	$1016, %%eax\n"
+	"	call	uart8250_tx_byte\n"
+	"	movl	$32, %%edx\n"
+	"	movl	$1016, %%eax\n"
+	"	call	uart8250_tx_byte\n"
+	"	movl	$100, %%edx\n"
+	"	movl	$1016, %%eax\n"
+	"	call	uart8250_tx_byte\n"
+	"	movl	$105, %%edx\n"
+	"	movl	$1016, %%eax\n"
+	"	call	uart8250_tx_byte\n"
+	"	movl	$115, %%edx\n"
+	"	movl	$1016, %%eax\n"
+	"	call	uart8250_tx_byte\n"
+	"	movl	$97, %%edx\n"
+	"	movl	$1016, %%eax\n"
+	"	call	uart8250_tx_byte\n"
+	"	movl	$98, %%edx\n"
+	"	movl	$1016, %%eax\n"
+	"	call	uart8250_tx_byte\n"
+	"	movl	$108, %%edx\n"
+	"	movl	$1016, %%eax\n"
+	"	call	uart8250_tx_byte\n"
+	"	movl	$101, %%edx\n"
+	"	movl	$1016, %%eax\n"
+	"	call	uart8250_tx_byte\n"
+	"	movl	$100, %%edx\n"
+	"	movl	$1016, %%eax\n"
+	"	call	uart8250_tx_byte\n"
+	"	movl	$10, %%edx\n"
+	"	movl	$1016, %%eax\n"
+	"	call	uart8250_tx_byte\n"
+
 	/* Set the default memory type and disable fixed and enable variable MTRRs */
 	"	movl    %[_MTRRdefType_MSR], %%ecx	\n"
 	"	xorl    %%edx, %%edx		\n"
@@ -71,14 +190,202 @@
 	"	movl    $0x00000800, %%eax	\n"
 	"	wrmsr				\n"
 
+	"	movl	$118, %%edx\n"
+	"	movl	$1016, %%eax\n"
+	"	call	uart8250_tx_byte\n"
+	"	movl	$97, %%edx\n"
+	"	movl	$1016, %%eax\n"
+	"	call	uart8250_tx_byte\n"
+	"	movl	$114, %%edx\n"
+	"	movl	$1016, %%eax\n"
+	"	call	uart8250_tx_byte\n"
+	"	movl	$105, %%edx\n"
+	"	movl	$1016, %%eax\n"
+	"	call	uart8250_tx_byte\n"
+	"	movl	$97, %%edx\n"
+	"	movl	$1016, %%eax\n"
+	"	call	uart8250_tx_byte\n"
+	"	movl	$98, %%edx\n"
+	"	movl	$1016, %%eax\n"
+	"	call	uart8250_tx_byte\n"
+	"	movl	$108, %%edx\n"
+	"	movl	$1016, %%eax\n"
+	"	call	uart8250_tx_byte\n"
+	"	movl	$101, %%edx\n"
+	"	movl	$1016, %%eax\n"
+	"	call	uart8250_tx_byte\n"
+	"	movl	$32, %%edx\n"
+	"	movl	$1016, %%eax\n"
+	"	call	uart8250_tx_byte\n"
+	"	movl	$109, %%edx\n"
+	"	movl	$1016, %%eax\n"
+	"	call	uart8250_tx_byte\n"
+	"	movl	$116, %%edx\n"
+	"	movl	$1016, %%eax\n"
+	"	call	uart8250_tx_byte\n"
+	"	movl	$114, %%edx\n"
+	"	movl	$1016, %%eax\n"
+	"	call	uart8250_tx_byte\n"
+	"	movl	$114, %%edx\n"
+	"	movl	$1016, %%eax\n"
+	"	call	uart8250_tx_byte\n"
+	"	movl	$115, %%edx\n"
+	"	movl	$1016, %%eax\n"
+	"	call	uart8250_tx_byte\n"
+	"	movl	$32, %%edx\n"
+	"	movl	$1016, %%eax\n"
+	"	call	uart8250_tx_byte\n"
+	"	movl	$101, %%edx\n"
+	"	movl	$1016, %%eax\n"
+	"	call	uart8250_tx_byte\n"
+	"	movl	$110, %%edx\n"
+	"	movl	$1016, %%eax\n"
+	"	call	uart8250_tx_byte\n"
+	"	movl	$97, %%edx\n"
+	"	movl	$1016, %%eax\n"
+	"	call	uart8250_tx_byte\n"
+	"	movl	$98, %%edx\n"
+	"	movl	$1016, %%eax\n"
+	"	call	uart8250_tx_byte\n"
+	"	movl	$108, %%edx\n"
+	"	movl	$1016, %%eax\n"
+	"	call	uart8250_tx_byte\n"
+	"	movl	$101, %%edx\n"
+	"	movl	$1016, %%eax\n"
+	"	call	uart8250_tx_byte\n"
+	"	movl	$100, %%edx\n"
+	"	movl	$1016, %%eax\n"
+	"	call	uart8250_tx_byte\n"
+	"	movl	$10, %%edx\n"
+	"	movl	$1016, %%eax\n"
+	"	call	uart8250_tx_byte\n"
+
 	/* enable cache */
 	"	movl    %%cr0, %%eax		\n"
 	"	andl    $0x9fffffff,%%eax	\n"
 	"	movl    %%eax, %%cr0		\n"
 
+	"	movl	$99, %%edx\n"
+	"	movl	$1016, %%eax\n"
+	"	call	uart8250_tx_byte\n"
+	"	movl	$97, %%edx\n"
+	"	movl	$1016, %%eax\n"
+	"	call	uart8250_tx_byte\n"
+	"	movl	$99, %%edx\n"
+	"	movl	$1016, %%eax\n"
+	"	call	uart8250_tx_byte\n"
+	"	movl	$104, %%edx\n"
+	"	movl	$1016, %%eax\n"
+	"	call	uart8250_tx_byte\n"
+	"	movl	$101, %%edx\n"
+	"	movl	$1016, %%eax\n"
+	"	call	uart8250_tx_byte\n"
+	"	movl	$32, %%edx\n"
+	"	movl	$1016, %%eax\n"
+	"	call	uart8250_tx_byte\n"
+	"	movl	$101, %%edx\n"
+	"	movl	$1016, %%eax\n"
+	"	call	uart8250_tx_byte\n"
+	"	movl	$110, %%edx\n"
+	"	movl	$1016, %%eax\n"
+	"	call	uart8250_tx_byte\n"
+	"	movl	$97, %%edx\n"
+	"	movl	$1016, %%eax\n"
+	"	call	uart8250_tx_byte\n"
+	"	movl	$98, %%edx\n"
+	"	movl	$1016, %%eax\n"
+	"	call	uart8250_tx_byte\n"
+	"	movl	$108, %%edx\n"
+	"	movl	$1016, %%eax\n"
+	"	call	uart8250_tx_byte\n"
+	"	movl	$101, %%edx\n"
+	"	movl	$1016, %%eax\n"
+	"	call	uart8250_tx_byte\n"
+	"	movl	$100, %%edx\n"
+	"	movl	$1016, %%eax\n"
+	"	call	uart8250_tx_byte\n"
+	"	movl	$10, %%edx\n"
+	"	movl	$1016, %%eax\n"
+	"	call	uart8250_tx_byte\n"
+
 	"	wbinvd				\n"
 
+	"	movl	$119, %%edx\n"
+	"	movl	$1016, %%eax\n"
+	"	call	uart8250_tx_byte\n"
+	"	movl	$98, %%edx\n"
+	"	movl	$1016, %%eax\n"
+	"	call	uart8250_tx_byte\n"
+	"	movl	$105, %%edx\n"
+	"	movl	$1016, %%eax\n"
+	"	call	uart8250_tx_byte\n"
+	"	movl	$110, %%edx\n"
+	"	movl	$1016, %%eax\n"
+	"	call	uart8250_tx_byte\n"
+	"	movl	$118, %%edx\n"
+	"	movl	$1016, %%eax\n"
+	"	call	uart8250_tx_byte\n"
+	"	movl	$100, %%edx\n"
+	"	movl	$1016, %%eax\n"
+	"	call	uart8250_tx_byte\n"
+	"	movl	$32, %%edx\n"
+	"	movl	$1016, %%eax\n"
+	"	call	uart8250_tx_byte\n"
+	"	movl	$100, %%edx\n"
+	"	movl	$1016, %%eax\n"
+	"	call	uart8250_tx_byte\n"
+	"	movl	$111, %%edx\n"
+	"	movl	$1016, %%eax\n"
+	"	call	uart8250_tx_byte\n"
+	"	movl	$110, %%edx\n"
+	"	movl	$1016, %%eax\n"
+	"	call	uart8250_tx_byte\n"
+	"	movl	$101, %%edx\n"
+	"	movl	$1016, %%eax\n"
+	"	call	uart8250_tx_byte\n"
+	"	movl	$10, %%edx\n"
+	"	movl	$1016, %%eax\n"
+	"	call	uart8250_tx_byte\n"
+
 	"	movl	%[newesp], %%esp	\n"
+
+	"	movl	$101, %%edx\n"
+	"	movl	$1016, %%eax\n"
+	"	call	uart8250_tx_byte\n"
+	"	movl	$115, %%edx\n"
+	"	movl	$1016, %%eax\n"
+	"	call	uart8250_tx_byte\n"
+	"	movl	$112, %%edx\n"
+	"	movl	$1016, %%eax\n"
+	"	call	uart8250_tx_byte\n"
+	"	movl	$32, %%edx\n"
+	"	movl	$1016, %%eax\n"
+	"	call	uart8250_tx_byte\n"
+	"	movl	$99, %%edx\n"
+	"	movl	$1016, %%eax\n"
+	"	call	uart8250_tx_byte\n"
+	"	movl	$104, %%edx\n"
+	"	movl	$1016, %%eax\n"
+	"	call	uart8250_tx_byte\n"
+	"	movl	$97, %%edx\n"
+	"	movl	$1016, %%eax\n"
+	"	call	uart8250_tx_byte\n"
+	"	movl	$110, %%edx\n"
+	"	movl	$1016, %%eax\n"
+	"	call	uart8250_tx_byte\n"
+	"	movl	$103, %%edx\n"
+	"	movl	$1016, %%eax\n"
+	"	call	uart8250_tx_byte\n"
+	"	movl	$101, %%edx\n"
+	"	movl	$1016, %%eax\n"
+	"	call	uart8250_tx_byte\n"
+	"	movl	$100, %%edx\n"
+	"	movl	$1016, %%eax\n"
+	"	call	uart8250_tx_byte\n"
+	"	movl	$10, %%edx\n"
+	"	movl	$1016, %%eax\n"
+	"	call	uart8250_tx_byte\n"
+
 	"	call stage1_phase3		\n"
 	:: [newesp] "i" (newlocation),
 	 [_SYSCFG_MSR] "i" (SYSCFG_MSR),
Index: arch/x86/stage1.c
===================================================================
--- arch/x86/stage1.c	(Revision 976)
+++ arch/x86/stage1.c	(Arbeitskopie)
@@ -263,6 +263,7 @@
 #ifdef CONFIG_CONSOLE_BUFFER
 	/* Move the printk buffer to PRINTK_BUF_ADDR_RAM */
 	printk_buffer_move((void *)PRINTK_BUF_ADDR_RAM, PRINTK_BUF_SIZE_RAM);
+	printk(BIOS_DEBUG, "Done printk() buffer move\n");
 #endif
 	/* Turn off Cache-As-Ram */
 	disable_car();


-- 
http://www.hailfinger.org/




From svn at coreboot.org  Sat Nov  1 05:33:36 2008
From: svn at coreboot.org (svn at coreboot.org)
Date: Sat,  1 Nov 2008 05:33:36 +0100
Subject: [coreboot] r977 - coreboot-v3/mainboard/jetway
Message-ID: <mailman.2366.1355071421.16123.coreboot@coreboot.org>

Author: cozzie
Date: 2008-11-01 05:33:36 +0100 (Sat, 01 Nov 2008)
New Revision: 977

Modified:
   coreboot-v3/mainboard/jetway/Kconfig
Log:
Minor patch to fix a Kconfig warning (trivial)

Signed-off-by: Corey Osgood <corey.osgood at gmail.com>
Acked-by: Corey Osgood <corey.osgood at gmail.com>



Modified: coreboot-v3/mainboard/jetway/Kconfig
===================================================================
--- coreboot-v3/mainboard/jetway/Kconfig	2008-11-01 00:53:01 UTC (rev 976)
+++ coreboot-v3/mainboard/jetway/Kconfig	2008-11-01 04:33:36 UTC (rev 977)
@@ -66,8 +66,8 @@
 	bool "256 MB"
 	help
 	  Choose this option to use 256MB of system memory for onboard video.
+endchoice
 
-
 config CN700_VIDEO_MB
 	int
 	default 0 if CN700_VIDEO_MB_NONE
@@ -78,7 +78,6 @@
 	help
 	  Map the config names to an integer.
 
-endchoice
 
 config MAINBOARD_DIR
 	string




From corey.osgood at gmail.com  Sat Nov  1 06:06:09 2008
From: corey.osgood at gmail.com (Corey Osgood)
Date: Sat, 1 Nov 2008 01:06:09 -0400
Subject: [coreboot] [PATCH] CN700/VT8237R stage2
In-Reply-To: <490BB7F6.9030509@gmx.net>
References: <dd3c80060810290102o7b28a867y4b103e8b6ee4c621@mail.gmail.com>
	<490A4CC6.2070602@gmx.net>
	<dd3c80060810301736y123561c7p7dc1646397f13732@mail.gmail.com>
	<490BB5F7.508@gmx.net> <490BB7F6.9030509@gmx.net>
Message-ID: <dd3c80060810312206s558be78fs7f03da2715fe9dfd@mail.gmail.com>

Debug log attached, I'm using COM2 so I modified the patch to use $760
instead of $1016, I hope that's right. I'm honestly not sure if the output
is what you were expecting or not, I don't think it is though. One thing I
noticed in the build log, with or without the patch, dunno if it matters or
not:

/home/corey/coreboot/coreboot-v3/arch/x86/via/stage1.c: In function
'disable_car':
/home/corey/coreboot/coreboot-v3/arch/x86/via/stage1.c:49: warning: passing
argument 1 of 'memcpy' discards qualifiers from pointer target type

Thanks,
Corey

On Fri, Oct 31, 2008 at 9:59 PM, Carl-Daniel Hailfinger <
c-d.hailfinger.devel.2006 at gmx.net> wrote:

> On 01.11.2008 02:50, Carl-Daniel Hailfinger wrote:
> > On 31.10.2008 01:36, Corey Osgood wrote:
> >
> >> debug log attached.
> >>
> >>
> >
> > Thanks, the log was really informative. Can you apply the following
> > patch and report back? Yes, the patch is evil, but it may help track
> > down the issue.
> >
>
> And the patch had minor garbage in it. New patch follows:
>
> Index: arch/x86/via/stage1.c
> ===================================================================
> --- arch/x86/via/stage1.c       (Revision 976)
> +++ arch/x86/via/stage1.c       (Arbeitskopie)
> @@ -29,12 +29,14 @@
>  #include <string.h>
>  #include <mtrr.h>
>  #include <via_c7.h>
> +#include <uart8250.h>
>
>  /**
>  * Disable Cache As RAM (CAR) after memory is setup.
>  */
>  void disable_car(void)
>  {
> +       printk(BIOS_DEBUG, "disable_car entry\n");
>        /* Determine new global variable location. Stack organization from
> top
>         * Top 4 bytes are reserved
>         * Pointer to global variables
> @@ -45,9 +47,19 @@
>        const struct global_vars *newlocation = (struct global_vars
> *)((RAM_STACK_BASE - sizeof(struct global_vars *) - sizeof(struct
> global_vars)) & ~0x7);
>        /* Copy global variables to new location. */
>        memcpy(newlocation, global_vars(), sizeof(struct global_vars));
> +       printk(BIOS_DEBUG, "disable_car global_vars copy done\n");
>        /* Set the new global variable pointer. */
>        *(struct global_vars **)(RAM_STACK_BASE - sizeof(struct global_vars
> *)) = newlocation;
>
> +       printk(BIOS_DEBUG, "disable_car global_vars pointer adjusted,
> entering asm code...");
> +       printk(BIOS_DEBUG,
> "now..........................................................................\n");
> +       uart8250_tx_byte(TTYSx_BASE, 'F');
> +       uart8250_tx_byte(TTYSx_BASE, 'O');
> +       uart8250_tx_byte(TTYSx_BASE, 'O');
> +       uart8250_tx_byte(TTYSx_BASE, 'B');
> +       uart8250_tx_byte(TTYSx_BASE, 'A');
> +       uart8250_tx_byte(TTYSx_BASE, 'R');
> +       uart8250_tx_byte(TTYSx_BASE, '\n');
>        __asm__ __volatile__(
>        /* We don't need cache as ram for now on */
>        /* disable cache */
> @@ -55,6 +67,52 @@
>        "       orl    $(0x1<<30),%%eax         \n"
>        "       movl    %%eax, %%cr0            \n"
>
> +       "       movl    $99, %%edx\n"
> +       "       movl    $1016, %%eax\n"
> +       "       call    uart8250_tx_byte\n"
> +       "       movl    $97, %%edx\n"
> +       "       movl    $1016, %%eax\n"
> +       "       call    uart8250_tx_byte\n"
> +       "       movl    $99, %%edx\n"
> +       "       movl    $1016, %%eax\n"
> +       "       call    uart8250_tx_byte\n"
> +       "       movl    $104, %%edx\n"
> +       "       movl    $1016, %%eax\n"
> +       "       call    uart8250_tx_byte\n"
> +       "       movl    $101, %%edx\n"
> +       "       movl    $1016, %%eax\n"
> +       "       call    uart8250_tx_byte\n"
> +       "       movl    $32, %%edx\n"
> +       "       movl    $1016, %%eax\n"
> +       "       call    uart8250_tx_byte\n"
> +       "       movl    $100, %%edx\n"
> +       "       movl    $1016, %%eax\n"
> +       "       call    uart8250_tx_byte\n"
> +       "       movl    $105, %%edx\n"
> +       "       movl    $1016, %%eax\n"
> +       "       call    uart8250_tx_byte\n"
> +       "       movl    $115, %%edx\n"
> +       "       movl    $1016, %%eax\n"
> +       "       call    uart8250_tx_byte\n"
> +       "       movl    $97, %%edx\n"
> +       "       movl    $1016, %%eax\n"
> +       "       call    uart8250_tx_byte\n"
> +       "       movl    $98, %%edx\n"
> +       "       movl    $1016, %%eax\n"
> +       "       call    uart8250_tx_byte\n"
> +       "       movl    $108, %%edx\n"
> +       "       movl    $1016, %%eax\n"
> +       "       call    uart8250_tx_byte\n"
> +       "       movl    $101, %%edx\n"
> +       "       movl    $1016, %%eax\n"
> +       "       call    uart8250_tx_byte\n"
> +       "       movl    $100, %%edx\n"
> +       "       movl    $1016, %%eax\n"
> +       "       call    uart8250_tx_byte\n"
> +       "       movl    $10, %%edx\n"
> +       "       movl    $1016, %%eax\n"
> +       "       call    uart8250_tx_byte\n"
> +
>        /* disable fixed mtrr from now on, it will be enabled by
> coreboot_ram again*/
>        "       movl    %[_SYSCFG_MSR], %%ecx   \n"
>        "       rdmsr                           \n"
> @@ -64,6 +122,67 @@
>         "       wrmsr                           \n"
>  #warning Must clear MTRR 0x200 and 0x201
>
> +       "       movl    $102, %%edx\n"
> +       "       movl    $1016, %%eax\n"
> +       "       call    uart8250_tx_byte\n"
> +       "       movl    $105, %%edx\n"
> +       "       movl    $1016, %%eax\n"
> +       "       call    uart8250_tx_byte\n"
> +       "       movl    $120, %%edx\n"
> +       "       movl    $1016, %%eax\n"
> +       "       call    uart8250_tx_byte\n"
> +       "       movl    $101, %%edx\n"
> +       "       movl    $1016, %%eax\n"
> +       "       call    uart8250_tx_byte\n"
> +       "       movl    $100, %%edx\n"
> +       "       movl    $1016, %%eax\n"
> +       "       call    uart8250_tx_byte\n"
> +       "       movl    $32, %%edx\n"
> +       "       movl    $1016, %%eax\n"
> +       "       call    uart8250_tx_byte\n"
> +       "       movl    $109, %%edx\n"
> +       "       movl    $1016, %%eax\n"
> +       "       call    uart8250_tx_byte\n"
> +       "       movl    $116, %%edx\n"
> +       "       movl    $1016, %%eax\n"
> +       "       call    uart8250_tx_byte\n"
> +       "       movl    $114, %%edx\n"
> +       "       movl    $1016, %%eax\n"
> +       "       call    uart8250_tx_byte\n"
> +       "       movl    $114, %%edx\n"
> +       "       movl    $1016, %%eax\n"
> +       "       call    uart8250_tx_byte\n"
> +       "       movl    $32, %%edx\n"
> +       "       movl    $1016, %%eax\n"
> +       "       call    uart8250_tx_byte\n"
> +       "       movl    $100, %%edx\n"
> +       "       movl    $1016, %%eax\n"
> +       "       call    uart8250_tx_byte\n"
> +       "       movl    $105, %%edx\n"
> +       "       movl    $1016, %%eax\n"
> +       "       call    uart8250_tx_byte\n"
> +       "       movl    $115, %%edx\n"
> +       "       movl    $1016, %%eax\n"
> +       "       call    uart8250_tx_byte\n"
> +       "       movl    $97, %%edx\n"
> +       "       movl    $1016, %%eax\n"
> +       "       call    uart8250_tx_byte\n"
> +       "       movl    $98, %%edx\n"
> +       "       movl    $1016, %%eax\n"
> +       "       call    uart8250_tx_byte\n"
> +       "       movl    $108, %%edx\n"
> +       "       movl    $1016, %%eax\n"
> +       "       call    uart8250_tx_byte\n"
> +       "       movl    $101, %%edx\n"
> +       "       movl    $1016, %%eax\n"
> +       "       call    uart8250_tx_byte\n"
> +       "       movl    $100, %%edx\n"
> +       "       movl    $1016, %%eax\n"
> +       "       call    uart8250_tx_byte\n"
> +       "       movl    $10, %%edx\n"
> +       "       movl    $1016, %%eax\n"
> +       "       call    uart8250_tx_byte\n"
> +
>         /* Set the default memory type and disable fixed and enable
> variable MTRRs */
>        "       movl    %[_MTRRdefType_MSR], %%ecx      \n"
>        "       xorl    %%edx, %%edx            \n"
> @@ -71,14 +190,202 @@
>         "       movl    $0x00000800, %%eax      \n"
>        "       wrmsr                           \n"
>
> +       "       movl    $118, %%edx\n"
> +       "       movl    $1016, %%eax\n"
> +       "       call    uart8250_tx_byte\n"
> +       "       movl    $97, %%edx\n"
> +       "       movl    $1016, %%eax\n"
> +       "       call    uart8250_tx_byte\n"
> +       "       movl    $114, %%edx\n"
> +       "       movl    $1016, %%eax\n"
> +       "       call    uart8250_tx_byte\n"
> +       "       movl    $105, %%edx\n"
> +       "       movl    $1016, %%eax\n"
> +       "       call    uart8250_tx_byte\n"
> +       "       movl    $97, %%edx\n"
> +       "       movl    $1016, %%eax\n"
> +       "       call    uart8250_tx_byte\n"
> +       "       movl    $98, %%edx\n"
> +       "       movl    $1016, %%eax\n"
> +       "       call    uart8250_tx_byte\n"
> +       "       movl    $108, %%edx\n"
> +       "       movl    $1016, %%eax\n"
> +       "       call    uart8250_tx_byte\n"
> +       "       movl    $101, %%edx\n"
> +       "       movl    $1016, %%eax\n"
> +       "       call    uart8250_tx_byte\n"
> +       "       movl    $32, %%edx\n"
> +       "       movl    $1016, %%eax\n"
> +       "       call    uart8250_tx_byte\n"
> +       "       movl    $109, %%edx\n"
> +       "       movl    $1016, %%eax\n"
> +       "       call    uart8250_tx_byte\n"
> +       "       movl    $116, %%edx\n"
> +       "       movl    $1016, %%eax\n"
> +       "       call    uart8250_tx_byte\n"
> +       "       movl    $114, %%edx\n"
> +       "       movl    $1016, %%eax\n"
> +       "       call    uart8250_tx_byte\n"
> +       "       movl    $114, %%edx\n"
> +       "       movl    $1016, %%eax\n"
> +       "       call    uart8250_tx_byte\n"
> +       "       movl    $115, %%edx\n"
> +       "       movl    $1016, %%eax\n"
> +       "       call    uart8250_tx_byte\n"
> +       "       movl    $32, %%edx\n"
> +       "       movl    $1016, %%eax\n"
> +       "       call    uart8250_tx_byte\n"
> +       "       movl    $101, %%edx\n"
> +       "       movl    $1016, %%eax\n"
> +       "       call    uart8250_tx_byte\n"
> +       "       movl    $110, %%edx\n"
> +       "       movl    $1016, %%eax\n"
> +       "       call    uart8250_tx_byte\n"
> +       "       movl    $97, %%edx\n"
> +       "       movl    $1016, %%eax\n"
> +       "       call    uart8250_tx_byte\n"
> +       "       movl    $98, %%edx\n"
> +       "       movl    $1016, %%eax\n"
> +       "       call    uart8250_tx_byte\n"
> +       "       movl    $108, %%edx\n"
> +       "       movl    $1016, %%eax\n"
> +       "       call    uart8250_tx_byte\n"
> +       "       movl    $101, %%edx\n"
> +       "       movl    $1016, %%eax\n"
> +       "       call    uart8250_tx_byte\n"
> +       "       movl    $100, %%edx\n"
> +       "       movl    $1016, %%eax\n"
> +       "       call    uart8250_tx_byte\n"
> +       "       movl    $10, %%edx\n"
> +       "       movl    $1016, %%eax\n"
> +       "       call    uart8250_tx_byte\n"
> +
>         /* enable cache */
>        "       movl    %%cr0, %%eax            \n"
>        "       andl    $0x9fffffff,%%eax       \n"
>        "       movl    %%eax, %%cr0            \n"
>
> +       "       movl    $99, %%edx\n"
> +       "       movl    $1016, %%eax\n"
> +       "       call    uart8250_tx_byte\n"
> +       "       movl    $97, %%edx\n"
> +       "       movl    $1016, %%eax\n"
> +       "       call    uart8250_tx_byte\n"
> +       "       movl    $99, %%edx\n"
> +       "       movl    $1016, %%eax\n"
> +       "       call    uart8250_tx_byte\n"
> +       "       movl    $104, %%edx\n"
> +       "       movl    $1016, %%eax\n"
> +       "       call    uart8250_tx_byte\n"
> +       "       movl    $101, %%edx\n"
> +       "       movl    $1016, %%eax\n"
> +       "       call    uart8250_tx_byte\n"
> +       "       movl    $32, %%edx\n"
> +       "       movl    $1016, %%eax\n"
> +       "       call    uart8250_tx_byte\n"
> +       "       movl    $101, %%edx\n"
> +       "       movl    $1016, %%eax\n"
> +       "       call    uart8250_tx_byte\n"
> +       "       movl    $110, %%edx\n"
> +       "       movl    $1016, %%eax\n"
> +       "       call    uart8250_tx_byte\n"
> +       "       movl    $97, %%edx\n"
> +       "       movl    $1016, %%eax\n"
> +       "       call    uart8250_tx_byte\n"
> +       "       movl    $98, %%edx\n"
> +       "       movl    $1016, %%eax\n"
> +       "       call    uart8250_tx_byte\n"
> +       "       movl    $108, %%edx\n"
> +       "       movl    $1016, %%eax\n"
> +       "       call    uart8250_tx_byte\n"
> +       "       movl    $101, %%edx\n"
> +       "       movl    $1016, %%eax\n"
> +       "       call    uart8250_tx_byte\n"
> +       "       movl    $100, %%edx\n"
> +       "       movl    $1016, %%eax\n"
> +       "       call    uart8250_tx_byte\n"
> +       "       movl    $10, %%edx\n"
> +       "       movl    $1016, %%eax\n"
> +       "       call    uart8250_tx_byte\n"
> +
>         "       wbinvd                          \n"
>
> +       "       movl    $119, %%edx\n"
> +       "       movl    $1016, %%eax\n"
> +       "       call    uart8250_tx_byte\n"
> +       "       movl    $98, %%edx\n"
> +       "       movl    $1016, %%eax\n"
> +       "       call    uart8250_tx_byte\n"
> +       "       movl    $105, %%edx\n"
> +       "       movl    $1016, %%eax\n"
> +       "       call    uart8250_tx_byte\n"
> +       "       movl    $110, %%edx\n"
> +       "       movl    $1016, %%eax\n"
> +       "       call    uart8250_tx_byte\n"
> +       "       movl    $118, %%edx\n"
> +       "       movl    $1016, %%eax\n"
> +       "       call    uart8250_tx_byte\n"
> +       "       movl    $100, %%edx\n"
> +       "       movl    $1016, %%eax\n"
> +       "       call    uart8250_tx_byte\n"
> +       "       movl    $32, %%edx\n"
> +       "       movl    $1016, %%eax\n"
> +       "       call    uart8250_tx_byte\n"
> +       "       movl    $100, %%edx\n"
> +       "       movl    $1016, %%eax\n"
> +       "       call    uart8250_tx_byte\n"
> +       "       movl    $111, %%edx\n"
> +       "       movl    $1016, %%eax\n"
> +       "       call    uart8250_tx_byte\n"
> +       "       movl    $110, %%edx\n"
> +       "       movl    $1016, %%eax\n"
> +       "       call    uart8250_tx_byte\n"
> +       "       movl    $101, %%edx\n"
> +       "       movl    $1016, %%eax\n"
> +       "       call    uart8250_tx_byte\n"
> +       "       movl    $10, %%edx\n"
> +       "       movl    $1016, %%eax\n"
> +       "       call    uart8250_tx_byte\n"
> +
>         "       movl    %[newesp], %%esp        \n"
> +
> +       "       movl    $101, %%edx\n"
> +       "       movl    $1016, %%eax\n"
> +       "       call    uart8250_tx_byte\n"
> +       "       movl    $115, %%edx\n"
> +       "       movl    $1016, %%eax\n"
> +       "       call    uart8250_tx_byte\n"
> +       "       movl    $112, %%edx\n"
> +       "       movl    $1016, %%eax\n"
> +       "       call    uart8250_tx_byte\n"
> +       "       movl    $32, %%edx\n"
> +       "       movl    $1016, %%eax\n"
> +       "       call    uart8250_tx_byte\n"
> +       "       movl    $99, %%edx\n"
> +       "       movl    $1016, %%eax\n"
> +       "       call    uart8250_tx_byte\n"
> +       "       movl    $104, %%edx\n"
> +       "       movl    $1016, %%eax\n"
> +       "       call    uart8250_tx_byte\n"
> +       "       movl    $97, %%edx\n"
> +       "       movl    $1016, %%eax\n"
> +       "       call    uart8250_tx_byte\n"
> +       "       movl    $110, %%edx\n"
> +       "       movl    $1016, %%eax\n"
> +       "       call    uart8250_tx_byte\n"
> +       "       movl    $103, %%edx\n"
> +       "       movl    $1016, %%eax\n"
> +       "       call    uart8250_tx_byte\n"
> +       "       movl    $101, %%edx\n"
> +       "       movl    $1016, %%eax\n"
> +       "       call    uart8250_tx_byte\n"
> +       "       movl    $100, %%edx\n"
> +       "       movl    $1016, %%eax\n"
> +       "       call    uart8250_tx_byte\n"
> +       "       movl    $10, %%edx\n"
> +       "       movl    $1016, %%eax\n"
> +       "       call    uart8250_tx_byte\n"
> +
>         "       call stage1_phase3              \n"
>        :: [newesp] "i" (newlocation),
>         [_SYSCFG_MSR] "i" (SYSCFG_MSR),
> Index: arch/x86/stage1.c
> ===================================================================
> --- arch/x86/stage1.c   (Revision 976)
> +++ arch/x86/stage1.c   (Arbeitskopie)
> @@ -263,6 +263,7 @@
>  #ifdef CONFIG_CONSOLE_BUFFER
>        /* Move the printk buffer to PRINTK_BUF_ADDR_RAM */
>        printk_buffer_move((void *)PRINTK_BUF_ADDR_RAM,
> PRINTK_BUF_SIZE_RAM);
> +       printk(BIOS_DEBUG, "Done printk() buffer move\n");
>  #endif
>        /* Turn off Cache-As-Ram */
>        disable_car();
>
>
> --
> http://www.hailfinger.org/
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20081101/e6b294af/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: c7_car_debug2.log
Type: application/octet-stream
Size: 26931 bytes
Desc: not available
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20081101/e6b294af/attachment.obj>

From corey.osgood at gmail.com  Sat Nov  1 06:08:35 2008
From: corey.osgood at gmail.com (Corey Osgood)
Date: Sat, 1 Nov 2008 01:08:35 -0400
Subject: [coreboot] [PATCH] CN700/VT8237R stage2
In-Reply-To: <dd3c80060810312206s558be78fs7f03da2715fe9dfd@mail.gmail.com>
References: <dd3c80060810290102o7b28a867y4b103e8b6ee4c621@mail.gmail.com>
	<490A4CC6.2070602@gmx.net>
	<dd3c80060810301736y123561c7p7dc1646397f13732@mail.gmail.com>
	<490BB5F7.508@gmx.net> <490BB7F6.9030509@gmx.net>
	<dd3c80060810312206s558be78fs7f03da2715fe9dfd@mail.gmail.com>
Message-ID: <dd3c80060810312208g49db1707j839fb9f18f4867f6@mail.gmail.com>

On Sat, Nov 1, 2008 at 1:06 AM, Corey Osgood <corey.osgood at gmail.com> wrote:

> Debug log attached, I'm using COM2 so I modified the patch to use $760
> instead of $1016, I hope that's right. I'm honestly not sure if the output
> is what you were expecting or not, I don't think it is though. One thing I
> noticed in the build log, with or without the patch, dunno if it matters or
> not:
>
> /home/corey/coreboot/coreboot-v3/arch/x86/via/stage1.c: In function
> 'disable_car':
> /home/corey/coreboot/coreboot-v3/arch/x86/via/stage1.c:49: warning: passing
> argument 1 of 'memcpy' discards qualifiers from pointer target type
>
> Thanks,
> Corey


I should have also mentioned that I didn't trim anything, the serial console
hangs at the end of the log file, but the post code keeps changing, so I'm
assuming something is going on but nothing's going to the console.

-Corey


>
>
> On Fri, Oct 31, 2008 at 9:59 PM, Carl-Daniel Hailfinger <
> c-d.hailfinger.devel.2006 at gmx.net> wrote:
>
>> On 01.11.2008 02:50, Carl-Daniel Hailfinger wrote:
>> > On 31.10.2008 01:36, Corey Osgood wrote:
>> >
>> >> debug log attached.
>> >>
>> >>
>> >
>> > Thanks, the log was really informative. Can you apply the following
>> > patch and report back? Yes, the patch is evil, but it may help track
>> > down the issue.
>> >
>>
>> And the patch had minor garbage in it. New patch follows:
>>
>> Index: arch/x86/via/stage1.c
>> ===================================================================
>> --- arch/x86/via/stage1.c       (Revision 976)
>> +++ arch/x86/via/stage1.c       (Arbeitskopie)
>> @@ -29,12 +29,14 @@
>>  #include <string.h>
>>  #include <mtrr.h>
>>  #include <via_c7.h>
>> +#include <uart8250.h>
>>
>>  /**
>>  * Disable Cache As RAM (CAR) after memory is setup.
>>  */
>>  void disable_car(void)
>>  {
>> +       printk(BIOS_DEBUG, "disable_car entry\n");
>>        /* Determine new global variable location. Stack organization from
>> top
>>         * Top 4 bytes are reserved
>>         * Pointer to global variables
>> @@ -45,9 +47,19 @@
>>        const struct global_vars *newlocation = (struct global_vars
>> *)((RAM_STACK_BASE - sizeof(struct global_vars *) - sizeof(struct
>> global_vars)) & ~0x7);
>>        /* Copy global variables to new location. */
>>        memcpy(newlocation, global_vars(), sizeof(struct global_vars));
>> +       printk(BIOS_DEBUG, "disable_car global_vars copy done\n");
>>        /* Set the new global variable pointer. */
>>        *(struct global_vars **)(RAM_STACK_BASE - sizeof(struct global_vars
>> *)) = newlocation;
>>
>> +       printk(BIOS_DEBUG, "disable_car global_vars pointer adjusted,
>> entering asm code...");
>> +       printk(BIOS_DEBUG,
>> "now..........................................................................\n");
>> +       uart8250_tx_byte(TTYSx_BASE, 'F');
>> +       uart8250_tx_byte(TTYSx_BASE, 'O');
>> +       uart8250_tx_byte(TTYSx_BASE, 'O');
>> +       uart8250_tx_byte(TTYSx_BASE, 'B');
>> +       uart8250_tx_byte(TTYSx_BASE, 'A');
>> +       uart8250_tx_byte(TTYSx_BASE, 'R');
>> +       uart8250_tx_byte(TTYSx_BASE, '\n');
>>        __asm__ __volatile__(
>>        /* We don't need cache as ram for now on */
>>        /* disable cache */
>> @@ -55,6 +67,52 @@
>>        "       orl    $(0x1<<30),%%eax         \n"
>>        "       movl    %%eax, %%cr0            \n"
>>
>> +       "       movl    $99, %%edx\n"
>> +       "       movl    $1016, %%eax\n"
>> +       "       call    uart8250_tx_byte\n"
>> +       "       movl    $97, %%edx\n"
>> +       "       movl    $1016, %%eax\n"
>> +       "       call    uart8250_tx_byte\n"
>> +       "       movl    $99, %%edx\n"
>> +       "       movl    $1016, %%eax\n"
>> +       "       call    uart8250_tx_byte\n"
>> +       "       movl    $104, %%edx\n"
>> +       "       movl    $1016, %%eax\n"
>> +       "       call    uart8250_tx_byte\n"
>> +       "       movl    $101, %%edx\n"
>> +       "       movl    $1016, %%eax\n"
>> +       "       call    uart8250_tx_byte\n"
>> +       "       movl    $32, %%edx\n"
>> +       "       movl    $1016, %%eax\n"
>> +       "       call    uart8250_tx_byte\n"
>> +       "       movl    $100, %%edx\n"
>> +       "       movl    $1016, %%eax\n"
>> +       "       call    uart8250_tx_byte\n"
>> +       "       movl    $105, %%edx\n"
>> +       "       movl    $1016, %%eax\n"
>> +       "       call    uart8250_tx_byte\n"
>> +       "       movl    $115, %%edx\n"
>> +       "       movl    $1016, %%eax\n"
>> +       "       call    uart8250_tx_byte\n"
>> +       "       movl    $97, %%edx\n"
>> +       "       movl    $1016, %%eax\n"
>> +       "       call    uart8250_tx_byte\n"
>> +       "       movl    $98, %%edx\n"
>> +       "       movl    $1016, %%eax\n"
>> +       "       call    uart8250_tx_byte\n"
>> +       "       movl    $108, %%edx\n"
>> +       "       movl    $1016, %%eax\n"
>> +       "       call    uart8250_tx_byte\n"
>> +       "       movl    $101, %%edx\n"
>> +       "       movl    $1016, %%eax\n"
>> +       "       call    uart8250_tx_byte\n"
>> +       "       movl    $100, %%edx\n"
>> +       "       movl    $1016, %%eax\n"
>> +       "       call    uart8250_tx_byte\n"
>> +       "       movl    $10, %%edx\n"
>> +       "       movl    $1016, %%eax\n"
>> +       "       call    uart8250_tx_byte\n"
>> +
>>        /* disable fixed mtrr from now on, it will be enabled by
>> coreboot_ram again*/
>>        "       movl    %[_SYSCFG_MSR], %%ecx   \n"
>>        "       rdmsr                           \n"
>> @@ -64,6 +122,67 @@
>>         "       wrmsr                           \n"
>>  #warning Must clear MTRR 0x200 and 0x201
>>
>> +       "       movl    $102, %%edx\n"
>> +       "       movl    $1016, %%eax\n"
>> +       "       call    uart8250_tx_byte\n"
>> +       "       movl    $105, %%edx\n"
>> +       "       movl    $1016, %%eax\n"
>> +       "       call    uart8250_tx_byte\n"
>> +       "       movl    $120, %%edx\n"
>> +       "       movl    $1016, %%eax\n"
>> +       "       call    uart8250_tx_byte\n"
>> +       "       movl    $101, %%edx\n"
>> +       "       movl    $1016, %%eax\n"
>> +       "       call    uart8250_tx_byte\n"
>> +       "       movl    $100, %%edx\n"
>> +       "       movl    $1016, %%eax\n"
>> +       "       call    uart8250_tx_byte\n"
>> +       "       movl    $32, %%edx\n"
>> +       "       movl    $1016, %%eax\n"
>> +       "       call    uart8250_tx_byte\n"
>> +       "       movl    $109, %%edx\n"
>> +       "       movl    $1016, %%eax\n"
>> +       "       call    uart8250_tx_byte\n"
>> +       "       movl    $116, %%edx\n"
>> +       "       movl    $1016, %%eax\n"
>> +       "       call    uart8250_tx_byte\n"
>> +       "       movl    $114, %%edx\n"
>> +       "       movl    $1016, %%eax\n"
>> +       "       call    uart8250_tx_byte\n"
>> +       "       movl    $114, %%edx\n"
>> +       "       movl    $1016, %%eax\n"
>> +       "       call    uart8250_tx_byte\n"
>> +       "       movl    $32, %%edx\n"
>> +       "       movl    $1016, %%eax\n"
>> +       "       call    uart8250_tx_byte\n"
>> +       "       movl    $100, %%edx\n"
>> +       "       movl    $1016, %%eax\n"
>> +       "       call    uart8250_tx_byte\n"
>> +       "       movl    $105, %%edx\n"
>> +       "       movl    $1016, %%eax\n"
>> +       "       call    uart8250_tx_byte\n"
>> +       "       movl    $115, %%edx\n"
>> +       "       movl    $1016, %%eax\n"
>> +       "       call    uart8250_tx_byte\n"
>> +       "       movl    $97, %%edx\n"
>> +       "       movl    $1016, %%eax\n"
>> +       "       call    uart8250_tx_byte\n"
>> +       "       movl    $98, %%edx\n"
>> +       "       movl    $1016, %%eax\n"
>> +       "       call    uart8250_tx_byte\n"
>> +       "       movl    $108, %%edx\n"
>> +       "       movl    $1016, %%eax\n"
>> +       "       call    uart8250_tx_byte\n"
>> +       "       movl    $101, %%edx\n"
>> +       "       movl    $1016, %%eax\n"
>> +       "       call    uart8250_tx_byte\n"
>> +       "       movl    $100, %%edx\n"
>> +       "       movl    $1016, %%eax\n"
>> +       "       call    uart8250_tx_byte\n"
>> +       "       movl    $10, %%edx\n"
>> +       "       movl    $1016, %%eax\n"
>> +       "       call    uart8250_tx_byte\n"
>> +
>>         /* Set the default memory type and disable fixed and enable
>> variable MTRRs */
>>        "       movl    %[_MTRRdefType_MSR], %%ecx      \n"
>>        "       xorl    %%edx, %%edx            \n"
>> @@ -71,14 +190,202 @@
>>         "       movl    $0x00000800, %%eax      \n"
>>        "       wrmsr                           \n"
>>
>> +       "       movl    $118, %%edx\n"
>> +       "       movl    $1016, %%eax\n"
>> +       "       call    uart8250_tx_byte\n"
>> +       "       movl    $97, %%edx\n"
>> +       "       movl    $1016, %%eax\n"
>> +       "       call    uart8250_tx_byte\n"
>> +       "       movl    $114, %%edx\n"
>> +       "       movl    $1016, %%eax\n"
>> +       "       call    uart8250_tx_byte\n"
>> +       "       movl    $105, %%edx\n"
>> +       "       movl    $1016, %%eax\n"
>> +       "       call    uart8250_tx_byte\n"
>> +       "       movl    $97, %%edx\n"
>> +       "       movl    $1016, %%eax\n"
>> +       "       call    uart8250_tx_byte\n"
>> +       "       movl    $98, %%edx\n"
>> +       "       movl    $1016, %%eax\n"
>> +       "       call    uart8250_tx_byte\n"
>> +       "       movl    $108, %%edx\n"
>> +       "       movl    $1016, %%eax\n"
>> +       "       call    uart8250_tx_byte\n"
>> +       "       movl    $101, %%edx\n"
>> +       "       movl    $1016, %%eax\n"
>> +       "       call    uart8250_tx_byte\n"
>> +       "       movl    $32, %%edx\n"
>> +       "       movl    $1016, %%eax\n"
>> +       "       call    uart8250_tx_byte\n"
>> +       "       movl    $109, %%edx\n"
>> +       "       movl    $1016, %%eax\n"
>> +       "       call    uart8250_tx_byte\n"
>> +       "       movl    $116, %%edx\n"
>> +       "       movl    $1016, %%eax\n"
>> +       "       call    uart8250_tx_byte\n"
>> +       "       movl    $114, %%edx\n"
>> +       "       movl    $1016, %%eax\n"
>> +       "       call    uart8250_tx_byte\n"
>> +       "       movl    $114, %%edx\n"
>> +       "       movl    $1016, %%eax\n"
>> +       "       call    uart8250_tx_byte\n"
>> +       "       movl    $115, %%edx\n"
>> +       "       movl    $1016, %%eax\n"
>> +       "       call    uart8250_tx_byte\n"
>> +       "       movl    $32, %%edx\n"
>> +       "       movl    $1016, %%eax\n"
>> +       "       call    uart8250_tx_byte\n"
>> +       "       movl    $101, %%edx\n"
>> +       "       movl    $1016, %%eax\n"
>> +       "       call    uart8250_tx_byte\n"
>> +       "       movl    $110, %%edx\n"
>> +       "       movl    $1016, %%eax\n"
>> +       "       call    uart8250_tx_byte\n"
>> +       "       movl    $97, %%edx\n"
>> +       "       movl    $1016, %%eax\n"
>> +       "       call    uart8250_tx_byte\n"
>> +       "       movl    $98, %%edx\n"
>> +       "       movl    $1016, %%eax\n"
>> +       "       call    uart8250_tx_byte\n"
>> +       "       movl    $108, %%edx\n"
>> +       "       movl    $1016, %%eax\n"
>> +       "       call    uart8250_tx_byte\n"
>> +       "       movl    $101, %%edx\n"
>> +       "       movl    $1016, %%eax\n"
>> +       "       call    uart8250_tx_byte\n"
>> +       "       movl    $100, %%edx\n"
>> +       "       movl    $1016, %%eax\n"
>> +       "       call    uart8250_tx_byte\n"
>> +       "       movl    $10, %%edx\n"
>> +       "       movl    $1016, %%eax\n"
>> +       "       call    uart8250_tx_byte\n"
>> +
>>         /* enable cache */
>>        "       movl    %%cr0, %%eax            \n"
>>        "       andl    $0x9fffffff,%%eax       \n"
>>        "       movl    %%eax, %%cr0            \n"
>>
>> +       "       movl    $99, %%edx\n"
>> +       "       movl    $1016, %%eax\n"
>> +       "       call    uart8250_tx_byte\n"
>> +       "       movl    $97, %%edx\n"
>> +       "       movl    $1016, %%eax\n"
>> +       "       call    uart8250_tx_byte\n"
>> +       "       movl    $99, %%edx\n"
>> +       "       movl    $1016, %%eax\n"
>> +       "       call    uart8250_tx_byte\n"
>> +       "       movl    $104, %%edx\n"
>> +       "       movl    $1016, %%eax\n"
>> +       "       call    uart8250_tx_byte\n"
>> +       "       movl    $101, %%edx\n"
>> +       "       movl    $1016, %%eax\n"
>> +       "       call    uart8250_tx_byte\n"
>> +       "       movl    $32, %%edx\n"
>> +       "       movl    $1016, %%eax\n"
>> +       "       call    uart8250_tx_byte\n"
>> +       "       movl    $101, %%edx\n"
>> +       "       movl    $1016, %%eax\n"
>> +       "       call    uart8250_tx_byte\n"
>> +       "       movl    $110, %%edx\n"
>> +       "       movl    $1016, %%eax\n"
>> +       "       call    uart8250_tx_byte\n"
>> +       "       movl    $97, %%edx\n"
>> +       "       movl    $1016, %%eax\n"
>> +       "       call    uart8250_tx_byte\n"
>> +       "       movl    $98, %%edx\n"
>> +       "       movl    $1016, %%eax\n"
>> +       "       call    uart8250_tx_byte\n"
>> +       "       movl    $108, %%edx\n"
>> +       "       movl    $1016, %%eax\n"
>> +       "       call    uart8250_tx_byte\n"
>> +       "       movl    $101, %%edx\n"
>> +       "       movl    $1016, %%eax\n"
>> +       "       call    uart8250_tx_byte\n"
>> +       "       movl    $100, %%edx\n"
>> +       "       movl    $1016, %%eax\n"
>> +       "       call    uart8250_tx_byte\n"
>> +       "       movl    $10, %%edx\n"
>> +       "       movl    $1016, %%eax\n"
>> +       "       call    uart8250_tx_byte\n"
>> +
>>         "       wbinvd                          \n"
>>
>> +       "       movl    $119, %%edx\n"
>> +       "       movl    $1016, %%eax\n"
>> +       "       call    uart8250_tx_byte\n"
>> +       "       movl    $98, %%edx\n"
>> +       "       movl    $1016, %%eax\n"
>> +       "       call    uart8250_tx_byte\n"
>> +       "       movl    $105, %%edx\n"
>> +       "       movl    $1016, %%eax\n"
>> +       "       call    uart8250_tx_byte\n"
>> +       "       movl    $110, %%edx\n"
>> +       "       movl    $1016, %%eax\n"
>> +       "       call    uart8250_tx_byte\n"
>> +       "       movl    $118, %%edx\n"
>> +       "       movl    $1016, %%eax\n"
>> +       "       call    uart8250_tx_byte\n"
>> +       "       movl    $100, %%edx\n"
>> +       "       movl    $1016, %%eax\n"
>> +       "       call    uart8250_tx_byte\n"
>> +       "       movl    $32, %%edx\n"
>> +       "       movl    $1016, %%eax\n"
>> +       "       call    uart8250_tx_byte\n"
>> +       "       movl    $100, %%edx\n"
>> +       "       movl    $1016, %%eax\n"
>> +       "       call    uart8250_tx_byte\n"
>> +       "       movl    $111, %%edx\n"
>> +       "       movl    $1016, %%eax\n"
>> +       "       call    uart8250_tx_byte\n"
>> +       "       movl    $110, %%edx\n"
>> +       "       movl    $1016, %%eax\n"
>> +       "       call    uart8250_tx_byte\n"
>> +       "       movl    $101, %%edx\n"
>> +       "       movl    $1016, %%eax\n"
>> +       "       call    uart8250_tx_byte\n"
>> +       "       movl    $10, %%edx\n"
>> +       "       movl    $1016, %%eax\n"
>> +       "       call    uart8250_tx_byte\n"
>> +
>>         "       movl    %[newesp], %%esp        \n"
>> +
>> +       "       movl    $101, %%edx\n"
>> +       "       movl    $1016, %%eax\n"
>> +       "       call    uart8250_tx_byte\n"
>> +       "       movl    $115, %%edx\n"
>> +       "       movl    $1016, %%eax\n"
>> +       "       call    uart8250_tx_byte\n"
>> +       "       movl    $112, %%edx\n"
>> +       "       movl    $1016, %%eax\n"
>> +       "       call    uart8250_tx_byte\n"
>> +       "       movl    $32, %%edx\n"
>> +       "       movl    $1016, %%eax\n"
>> +       "       call    uart8250_tx_byte\n"
>> +       "       movl    $99, %%edx\n"
>> +       "       movl    $1016, %%eax\n"
>> +       "       call    uart8250_tx_byte\n"
>> +       "       movl    $104, %%edx\n"
>> +       "       movl    $1016, %%eax\n"
>> +       "       call    uart8250_tx_byte\n"
>> +       "       movl    $97, %%edx\n"
>> +       "       movl    $1016, %%eax\n"
>> +       "       call    uart8250_tx_byte\n"
>> +       "       movl    $110, %%edx\n"
>> +       "       movl    $1016, %%eax\n"
>> +       "       call    uart8250_tx_byte\n"
>> +       "       movl    $103, %%edx\n"
>> +       "       movl    $1016, %%eax\n"
>> +       "       call    uart8250_tx_byte\n"
>> +       "       movl    $101, %%edx\n"
>> +       "       movl    $1016, %%eax\n"
>> +       "       call    uart8250_tx_byte\n"
>> +       "       movl    $100, %%edx\n"
>> +       "       movl    $1016, %%eax\n"
>> +       "       call    uart8250_tx_byte\n"
>> +       "       movl    $10, %%edx\n"
>> +       "       movl    $1016, %%eax\n"
>> +       "       call    uart8250_tx_byte\n"
>> +
>>         "       call stage1_phase3              \n"
>>        :: [newesp] "i" (newlocation),
>>         [_SYSCFG_MSR] "i" (SYSCFG_MSR),
>> Index: arch/x86/stage1.c
>> ===================================================================
>> --- arch/x86/stage1.c   (Revision 976)
>> +++ arch/x86/stage1.c   (Arbeitskopie)
>> @@ -263,6 +263,7 @@
>>  #ifdef CONFIG_CONSOLE_BUFFER
>>        /* Move the printk buffer to PRINTK_BUF_ADDR_RAM */
>>        printk_buffer_move((void *)PRINTK_BUF_ADDR_RAM,
>> PRINTK_BUF_SIZE_RAM);
>> +       printk(BIOS_DEBUG, "Done printk() buffer move\n");
>>  #endif
>>        /* Turn off Cache-As-Ram */
>>        disable_car();
>>
>>
>> --
>> http://www.hailfinger.org/
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20081101/c4f69a0b/attachment.html>

From david.hendricks at gmail.com  Sat Nov  1 09:46:01 2008
From: david.hendricks at gmail.com (David Hendricks)
Date: Sat, 1 Nov 2008 01:46:01 -0700
Subject: [coreboot] Coreboot Tech Talk @ Google, October 30 2008
Message-ID: <a2496e180811010146j417d1c9awe782fc279aec7761@mail.gmail.com>

Hey everyone,
Just thought I'd post a link to the tech talk Stefan, Peter and Ron gave at
Google a couple days ago: http://www.youtube.com/watch?v=X72LgcMpM9k .

The format goes:
1) Ron Minnich, project founder: What is Coreboot, motivation, and
principles of operation.
2) Peter Stuge, long-time contributor: Details, system management mode (SMM)
and ACPI, and of course some of the coolest demos of all time.
3) Stefan Reinauer, primary maintainer: Testing infrastructure

Enjoy!
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20081101/79d19f97/attachment.html>

From z4ziggy at gmail.com  Sat Nov  1 09:54:47 2008
From: z4ziggy at gmail.com (z4ziggy at gmail.com)
Date: Sat, 01 Nov 2008 01:54:47 -0700
Subject: [coreboot] assistance with updating my bios
Message-ID: <0015174c3ea4b67ecd045a9cddd3@google.com>

Since i have no idea what are you two talking about, im attaching the link  
to the current BIOS datasheet (which shows the current BIOS has a 2MB flash  
size, if i understand this correctly) :  
http://www.datasheetcatalog.org/datasheet/stmicroelectronics/8499.pdf

On Nov 1, 2008 1:53am, Corey Osgood <corey.osgood at gmail.com> wrote:
> > cpu: Socket370 Intel Pentium III Celeron
>
> > northbridge: Intel 82810E
>
> > southbridge: Intel 8281AA
>
> > mainboard: 810 R 4.1 with lan
>
> > super i/o: Winbond W8362F-AW
>
> > bios device: ST M50FW002
>
>
>
> Are you sure it's SPI?
>
>
>
> -Corey
>
>
>
> On 10/31/08, Elia Yehuda wrote:
>
> > many thanks. i will try the patch tomorrow night when i'm back at home  
and
>
> > report back.
>
> >
>
> > On Fri, Oct 31, 2008 at 8:38 PM, Peter Stuge wrote:
>
> >
>
> >> Hi,
>
> >>
>
> >> z4ziggy at gmail.com wrote:
>
> >> > No EEPROM/flash device found.
>
> >> > If you know which flash chip you have, and if this version of  
flashrom
>
> >> > supports a similar flash chip, you can try to force read your chip.  
Run:
>
> >> > flashrom -f -r -c similar_supported_flash_chip filename
>
> >> >
>
> >> > Note: flashrom can never write when the flash chip isn't found
>
> >> > automatically.
>
> >>
>
> >> The above note is sadly not a joke.
>
> >>
>
> >>
>
> >> Corey Osgood wrote:
>
> >> > AFAIK, flashrom is broken for most ICHx.
>
> >>
>
> >> Not so, it works very well on a whole bunch of them.
>
> >>
>
> >>
>
> >> Carl-Daniel Hailfinger wrote:
>
> >> > On 30.10.2008 16:57, z4ziggy at gmail.com wrote:
>
> >> > > any plans on fixing the issue or using alternative? is there a
>
> >> > > way i can assist?
>
> >> >
>
> >> > Your flash chip is not supported. I'll add code for it.
>
> >>
>
> >> Some info Carl-Daniel didn't post, maybe it is informative;
>
> >>
>
> >> It seems that the system has a Winbond W25B40 or W25B40A flash chip.
>
> >> This is an SPI flash chip, but it seems to behave just like a FWH
>
> >> type chip.
>
> >>
>
> >> While waiting for Carl-Daniel you can try the attached patch. I doubt
>
> >> it will work but you never know.
>
> >>
>
> >>
>
> >> //Peter
>
> >>
>
> >> --
>
> >> coreboot mailing list: coreboot at coreboot.org
>
> >> http://www.coreboot.org/mailman/listinfo/coreboot
>
> >>
>
> >
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20081101/c66716da/attachment.html>

From c-d.hailfinger.devel.2006 at gmx.net  Sat Nov  1 12:33:32 2008
From: c-d.hailfinger.devel.2006 at gmx.net (Carl-Daniel Hailfinger)
Date: Sat, 01 Nov 2008 12:33:32 +0100
Subject: [coreboot] [PATCH] CN700/VT8237R stage2
In-Reply-To: <dd3c80060810312208g49db1707j839fb9f18f4867f6@mail.gmail.com>
References: <dd3c80060810290102o7b28a867y4b103e8b6ee4c621@mail.gmail.com>	
	<490A4CC6.2070602@gmx.net>	
	<dd3c80060810301736y123561c7p7dc1646397f13732@mail.gmail.com>	
	<490BB5F7.508@gmx.net> <490BB7F6.9030509@gmx.net>	
	<dd3c80060810312206s558be78fs7f03da2715fe9dfd@mail.gmail.com>
	<dd3c80060810312208g49db1707j839fb9f18f4867f6@mail.gmail.com>
Message-ID: <490C3E8C.7050307@gmx.net>

On 01.11.2008 06:08, Corey Osgood wrote:
> On Sat, Nov 1, 2008 at 1:06 AM, Corey Osgood <corey.osgood at gmail.com> wrote:
>
>   
>> Debug log attached, I'm using COM2 so I modified the patch to use $760
>> instead of $1016, I hope that's right. I'm honestly not sure if the output
>> is what you were expecting or not, I don't think it is though. One thing I
>> noticed in the build log, with or without the patch, dunno if it matters or
>> not:
>>
>> /home/corey/coreboot/coreboot-v3/arch/x86/via/stage1.c: In function
>> 'disable_car':
>> /home/corey/coreboot/coreboot-v3/arch/x86/via/stage1.c:49: warning: passing
>> argument 1 of 'memcpy' discards qualifiers from pointer target type
>>
>> Thanks,
>> Corey
>>     
>
>
> I should have also mentioned that I didn't trim anything, the serial console
> hangs at the end of the log file, but the post code keeps changing, so I'm
> assuming something is going on but nothing's going to the console.
>   

Thanks. I now understand where parts of the garbage come from. Can you
try the attached patch? It should require no further fixups for COM2.

It would be great if you could use various values between 0 and 13
(inclusive) for the #define HALT_AFTER. The idea there is to
decrease/increase the value up to the biggest value where it doesn't
reboot automatically. The POST codes emitted by the diagnostic code
should be between 0xC0 and 0xCD. The last expected POST code for a given
HALT_AFTER is 0xC0+HALT_AFTER.

I'm also increasingly convinced that RAM is not working right,
especially for the area we use as stack. Can you enable ram_check() in
mainboard/.../initram.c again?

Regards,
Carl-Daniel

-- 
http://www.hailfinger.org/

-------------- next part --------------
A non-text attachment was scrubbed...
Name: linuxbios3_car_via_disable_car_debug02.diff
Type: text/x-patch
Size: 12344 bytes
Desc: not available
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20081101/47766ae3/attachment.diff>

From c-d.hailfinger.devel.2006 at gmx.net  Sat Nov  1 12:38:25 2008
From: c-d.hailfinger.devel.2006 at gmx.net (Carl-Daniel Hailfinger)
Date: Sat, 01 Nov 2008 12:38:25 +0100
Subject: [coreboot] [PATCH] CN700/VT8237R stage2
In-Reply-To: <490C3E8C.7050307@gmx.net>
References: <dd3c80060810290102o7b28a867y4b103e8b6ee4c621@mail.gmail.com>	
	<490A4CC6.2070602@gmx.net>	
	<dd3c80060810301736y123561c7p7dc1646397f13732@mail.gmail.com>	
	<490BB5F7.508@gmx.net> <490BB7F6.9030509@gmx.net>	
	<dd3c80060810312206s558be78fs7f03da2715fe9dfd@mail.gmail.com>
	<dd3c80060810312208g49db1707j839fb9f18f4867f6@mail.gmail.com>
	<490C3E8C.7050307@gmx.net>
Message-ID: <490C3FB1.8050901@gmx.net>

On 01.11.2008 12:33, Carl-Daniel Hailfinger wrote:
> Thanks. I now understand where parts of the garbage come from. Can you
> try the attached patch? It should require no further fixups for COM2.
>
> It would be great if you could use various values between 0 and 13
> (inclusive) for the #define HALT_AFTER. The idea there is to
> decrease/increase the value up to the biggest value where it doesn't
> reboot automatically. The POST codes emitted by the diagnostic code
> should be between 0xC0 and 0xCD. The last expected POST code for a given
> HALT_AFTER is 0xC0+HALT_AFTER.
>
> I'm also increasingly convinced that RAM is not working right,
> especially for the area we use as stack. Can you enable ram_check() in
> mainboard/.../initram.c again?
>   

My apologies. I had attached an older version of the patch. Please try
this one.
Oh, and I'd be very interested in your build/arch/x86/via/stage1.o file.

Regards,
Carl-Daniel

-- 
http://www.hailfinger.org/

-------------- next part --------------
A non-text attachment was scrubbed...
Name: linuxbios3_car_via_disable_car_debug03.diff
Type: text/x-patch
Size: 13661 bytes
Desc: not available
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20081101/a6f44488/attachment.diff>

From tiagomnm at gmail.com  Sat Nov  1 16:13:16 2008
From: tiagomnm at gmail.com (Tiago Marques)
Date: Sat, 1 Nov 2008 15:13:16 +0000
Subject: [coreboot] Coreboot Tech Talk @ Google, October 30 2008
In-Reply-To: <a2496e180811010146j417d1c9awe782fc279aec7761@mail.gmail.com>
References: <a2496e180811010146j417d1c9awe782fc279aec7761@mail.gmail.com>
Message-ID: <b1335fe90811010813u6e2e73c2wb629679e785de08e@mail.gmail.com>

Tks David!

Best regards,
                        Tiago Marques


On Sat, Nov 1, 2008 at 8:46 AM, David Hendricks
<david.hendricks at gmail.com>wrote:

> Hey everyone,
> Just thought I'd post a link to the tech talk Stefan, Peter and Ron gave at
> Google a couple days ago: http://www.youtube.com/watch?v=X72LgcMpM9k .
>
> The format goes:
> 1) Ron Minnich, project founder: What is Coreboot, motivation, and
> principles of operation.
> 2) Peter Stuge, long-time contributor: Details, system management mode
> (SMM) and ACPI, and of course some of the coolest demos of all time.
> 3) Stefan Reinauer, primary maintainer: Testing infrastructure
>
> Enjoy!
>
> --
> coreboot mailing list: coreboot at coreboot.org
> http://www.coreboot.org/mailman/listinfo/coreboot
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20081101/d3dd31a1/attachment.html>

From uwe at hermann-uwe.de  Sat Nov  1 16:44:33 2008
From: uwe at hermann-uwe.de (Uwe Hermann)
Date: Sat, 1 Nov 2008 16:44:33 +0100
Subject: [coreboot] [v2][patch] update k8 fid/vid setup
In-Reply-To: <4908F927.6090806@amd.com>
References: <48AF20BE.1040609@amd.com> <20080930051342.8336.qmail@stuge.se>
	<48E2471D.5030905@amd.com> <48E3E41F.4000603@amd.com>
	<20081021234938.GF15706@greenwood> <4907958B.4050409@amd.com>
	<20081028232308.GA19217@greenwood> <4908F927.6090806@amd.com>
Message-ID: <20081101154433.GD28905@greenwood>

On Wed, Oct 29, 2008 at 06:00:39PM -0600, Marc Jones wrote:
> Uwe,
> Thanks for all the help! Sorry this took so long.
>
> I found the issue (and a few others along the way). This updated patch  
> should work now. It should also get you another 100MHz with your cpu :)

Indeed, thanks! I'm at 1.9 GHz now.


$ cat /proc/cpuinfo 
processor       : 0
vendor_id       : AuthenticAMD
cpu family      : 15
model           : 107
model name      : AMD Athlon(tm) 64 X2 Dual Core Processor 3600+
stepping        : 1
cpu MHz         : 1900.042
cache size      : 512 KB
physical id     : 0
siblings        : 2
core id         : 0
cpu cores       : 2
apicid          : 0
initial apicid  : 0
fdiv_bug        : no
hlt_bug         : no
f00f_bug        : no
coma_bug        : no
fpu             : yes
fpu_exception   : yes
cpuid level     : 1
wp              : yes
flags           : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 ht syscall nx mmxext fxsr_opt rdtscp lm 3dnowext 3dnow pni cx16 lahf_lm cmp_legacy svm extapic cr8_legacy 3dnowprefeh
bogomips        : 3803.48
clflush size    : 64
power management: ts fid vid ttp tm stc 100mhzsteps

processor       : 1
vendor_id       : AuthenticAMD
cpu family      : 15
model           : 107
model name      : AMD Athlon(tm) 64 X2 Dual Core Processor 3600+
stepping        : 1
cpu MHz         : 1900.042
cache size      : 512 KB
physical id     : 0
siblings        : 2
core id         : 1
cpu cores       : 2
apicid          : 1
initial apicid  : 1
fdiv_bug        : no
hlt_bug         : no
f00f_bug        : no
coma_bug        : no
fpu             : yes
fpu_exception   : yes
cpuid level     : 1
wp              : yes
flags           : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 ht syscall nx mmxext fxsr_opt rdtscp lm 3dnowext 3dnow pni cx16 lahf_lm cmp_legacy svm extapic cr8_legacy 3dnowprefeh
bogomips        : 3800.22
clflush size    : 64
power management: ts fid vid ttp tm stc 100mhzsteps


> Update K8 FID/VID setup. Add support for 100MHz FIDs (revG).
> 
> Signed-off-by: Marc Jones <marc.jones at amd.com>

Acked-by: Uwe Hermann <uwe at hermann-uwe.de>


Please port this to v3 also if possible.


Uwe.
-- 
http://www.hermann-uwe.de  | http://www.holsham-traders.de
http://www.crazy-hacks.org | http://www.unmaintained-free-software.org



From kevin at koconnor.net  Sat Nov  1 18:37:03 2008
From: kevin at koconnor.net (Kevin O'Connor)
Date: Sat, 1 Nov 2008 13:37:03 -0400
Subject: [coreboot] coreboot.v2+seabios on 440bx: option roms not found
In-Reply-To: <4909C3A9.2010704@icyb.net.ua>
References: <4909C3A9.2010704@icyb.net.ua>
Message-ID: <20081101173703.GA32613@morn.localdomain>

Hi,

On Thu, Oct 30, 2008 at 04:24:41PM +0200, Andriy Gapon wrote:
> In northbridge/intel/i440bx/raminit.c:sdram_set_spd_registers all PAM
> registers are programmed for RAM R/W access (0x33).
> When SeaBIOS searches for option ROMs (including VGA ROM) it doesn't do
> anything about PAM, so it sees empty memory instead of the ROMs.
> 
> I am not sure what is the best solution here. It is debatable how
> coreboot should set PAM register, and it is not right to make SeaBIOS
> too hardware dependent.
> 
> Maybe coreboot could somehow export functions for setting access to
> option ROM space (aka legacy memory segments) and SeaBIOS could call them.

Currently, SeaBIOS needs coreboot to copy the option roms to memory in
order for SeaBIOS to run them.

I modified my copy of coreboot-v2 to do this (at least for
epia-m/cn).  I posted this change (along with other stuff) at:

http://www.coreboot.org/pipermail/coreboot/2008-September/038551.html

I'm planning on enhancing SeaBIOS so that it can scan all the PCI
devices and copy the option roms from the card to memory.  For
built-in vga devices on coreboot-v2, I'll add support for hardcoding
the rom address for an option rom.  Finally, I'd eventually like to
add simple lar support so that SeaBIOS can pull option roms out of the
lar on coreboot-v3.

PCI option rom copying looks to be straight forward and not too system
specific.  Unfortunately, I don't have any PCI devices with option
roms handy, so I'll need some help to test it.

-Kevin



From corey.osgood at gmail.com  Sat Nov  1 18:56:02 2008
From: corey.osgood at gmail.com (Corey Osgood)
Date: Sat, 1 Nov 2008 13:56:02 -0400
Subject: [coreboot] [PATCH] CN700/VT8237R stage2
In-Reply-To: <490C3FB1.8050901@gmx.net>
References: <dd3c80060810290102o7b28a867y4b103e8b6ee4c621@mail.gmail.com>
	<490A4CC6.2070602@gmx.net>
	<dd3c80060810301736y123561c7p7dc1646397f13732@mail.gmail.com>
	<490BB5F7.508@gmx.net> <490BB7F6.9030509@gmx.net>
	<dd3c80060810312206s558be78fs7f03da2715fe9dfd@mail.gmail.com>
	<dd3c80060810312208g49db1707j839fb9f18f4867f6@mail.gmail.com>
	<490C3E8C.7050307@gmx.net> <490C3FB1.8050901@gmx.net>
Message-ID: <dd3c80060811011056k240a2b28ha80e33f11b4bb8df@mail.gmail.com>

System reset seems to occur between 2 and 3, both of those logs attached,
along with arch/x86/via/stage1.o With HALT_AFTER=3, the post code keeps
changing, as expected with the system rebooting, with HALT_AFTER=2 it was
0xc2.

Thanks,
Corey

On Sat, Nov 1, 2008 at 7:38 AM, Carl-Daniel Hailfinger <
c-d.hailfinger.devel.2006 at gmx.net> wrote:

> On 01.11.2008 12:33, Carl-Daniel Hailfinger wrote:
> > Thanks. I now understand where parts of the garbage come from. Can you
> > try the attached patch? It should require no further fixups for COM2.
> >
> > It would be great if you could use various values between 0 and 13
> > (inclusive) for the #define HALT_AFTER. The idea there is to
> > decrease/increase the value up to the biggest value where it doesn't
> > reboot automatically. The POST codes emitted by the diagnostic code
> > should be between 0xC0 and 0xCD. The last expected POST code for a given
> > HALT_AFTER is 0xC0+HALT_AFTER.
> >
> > I'm also increasingly convinced that RAM is not working right,
> > especially for the area we use as stack. Can you enable ram_check() in
> > mainboard/.../initram.c again?
> >
>
> My apologies. I had attached an older version of the patch. Please try
> this one.
> Oh, and I'd be very interested in your build/arch/x86/via/stage1.o file.
>
> Regards,
> Carl-Daniel
>
> --
> http://www.hailfinger.org/
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20081101/396d44f3/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: stage1.o
Type: application/x-object
Size: 4016 bytes
Desc: not available
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20081101/396d44f3/attachment.o>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: haltafter2.log
Type: application/octet-stream
Size: 6076 bytes
Desc: not available
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20081101/396d44f3/attachment.obj>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: haltafter3.log
Type: application/octet-stream
Size: 16211 bytes
Desc: not available
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20081101/396d44f3/attachment-0001.obj>

From c-d.hailfinger.devel.2006 at gmx.net  Sat Nov  1 20:11:45 2008
From: c-d.hailfinger.devel.2006 at gmx.net (Carl-Daniel Hailfinger)
Date: Sat, 01 Nov 2008 20:11:45 +0100
Subject: [coreboot] [PATCH] CN700/VT8237R stage2
In-Reply-To: <dd3c80060811011056k240a2b28ha80e33f11b4bb8df@mail.gmail.com>
References: <dd3c80060810290102o7b28a867y4b103e8b6ee4c621@mail.gmail.com>	
	<490A4CC6.2070602@gmx.net>	
	<dd3c80060810301736y123561c7p7dc1646397f13732@mail.gmail.com>	
	<490BB5F7.508@gmx.net> <490BB7F6.9030509@gmx.net>	
	<dd3c80060810312206s558be78fs7f03da2715fe9dfd@mail.gmail.com>	
	<dd3c80060810312208g49db1707j839fb9f18f4867f6@mail.gmail.com>	
	<490C3E8C.7050307@gmx.net> <490C3FB1.8050901@gmx.net>
	<dd3c80060811011056k240a2b28ha80e33f11b4bb8df@mail.gmail.com>
Message-ID: <490CA9F1.90704@gmx.net>

On 01.11.2008 18:56, Corey Osgood wrote:
> System reset seems to occur between 2 and 3, both of those logs attached,
> along with arch/x86/via/stage1.o With HALT_AFTER=3, the post code keeps
> changing, as expected with the system rebooting, with HALT_AFTER=2 it was
> 0xc2.
>   

Great results, thanks a lot!
One bug spotted and fixed. Can you retest with the same method and the
updated patch attached to this mail? I hope it will die much later,
perhaps at HALT_AFTER=13 or so.

Regards,
Carl-Daniel

-- 
http://www.hailfinger.org/

-------------- next part --------------
A non-text attachment was scrubbed...
Name: linuxbios3_car_via_disable_car_debug04.diff
Type: text/x-patch
Size: 13691 bytes
Desc: not available
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20081101/37ca4b4c/attachment.diff>

From c-d.hailfinger.devel.2006 at gmx.net  Sat Nov  1 22:28:40 2008
From: c-d.hailfinger.devel.2006 at gmx.net (Carl-Daniel Hailfinger)
Date: Sat, 01 Nov 2008 22:28:40 +0100
Subject: [coreboot] [PATCH] CN700/VT8237R stage2
In-Reply-To: <490CA9F1.90704@gmx.net>
References: <dd3c80060810290102o7b28a867y4b103e8b6ee4c621@mail.gmail.com>		<490A4CC6.2070602@gmx.net>		<dd3c80060810301736y123561c7p7dc1646397f13732@mail.gmail.com>		<490BB5F7.508@gmx.net>
	<490BB7F6.9030509@gmx.net>		<dd3c80060810312206s558be78fs7f03da2715fe9dfd@mail.gmail.com>		<dd3c80060810312208g49db1707j839fb9f18f4867f6@mail.gmail.com>		<490C3E8C.7050307@gmx.net>
	<490C3FB1.8050901@gmx.net>	<dd3c80060811011056k240a2b28ha80e33f11b4bb8df@mail.gmail.com>
	<490CA9F1.90704@gmx.net>
Message-ID: <490CCA08.5090302@gmx.net>

On 01.11.2008 20:11, Carl-Daniel Hailfinger wrote:
> On 01.11.2008 18:56, Corey Osgood wrote:
>   
>> System reset seems to occur between 2 and 3, both of those logs attached,
>> along with arch/x86/via/stage1.o With HALT_AFTER=3, the post code keeps
>> changing, as expected with the system rebooting, with HALT_AFTER=2 it was
>> 0xc2.
>>   
>>     
>
> Great results, thanks a lot!
> One bug spotted and fixed. Can you retest with the same method and the
> updated patch attached to this mail? I hope it will die much later,
> perhaps at HALT_AFTER=13 or so.
>   

Thanks for the information that HALT_AFTER=5 is the last working setting.

Can you try the new patch with HALT_AFTER=11 and up to 14?

Regards,
Carl-Daniel

-- 
http://www.hailfinger.org/

-------------- next part --------------
A non-text attachment was scrubbed...
Name: linuxbios3_car_via_disable_car_debug05.diff
Type: text/x-patch
Size: 13708 bytes
Desc: not available
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20081101/063db09a/attachment.diff>

From c-d.hailfinger.devel.2006 at gmx.net  Sat Nov  1 23:21:24 2008
From: c-d.hailfinger.devel.2006 at gmx.net (Carl-Daniel Hailfinger)
Date: Sat, 01 Nov 2008 23:21:24 +0100
Subject: [coreboot] [PATCH] v3: Work around broken MTRR setup in VIA CAR
Message-ID: <490CD664.4090102@gmx.net>

Once we touch the MTRRs in VIA disable_car(), the CPU resets. Since
workarounds are better than instant reboots, mangle the code so that it
only switches stacks and flushes the cache.

There's also one genuine fix in there: Switch %esp before CAR is
disabled. That way, debugging becomes easier and the stack is always valid.

Many thanks to Corey for testing countless iterations of that code.

Signed-off-by: Carl-Daniel Hailfinger <c-d.hailfinger.devel.2006 at gmx.net>
Attached for poor gmail users.

Index: corebootv3-via_car/arch/x86/via/stage1.c
===================================================================
--- corebootv3-via_car/arch/x86/via/stage1.c	(Revision 977)
+++ corebootv3-via_car/arch/x86/via/stage1.c	(Arbeitskopie)
@@ -35,6 +35,7 @@
  */
 void disable_car(void)
 {
+	printk(BIOS_DEBUG, "disable_car entry\n");
 	/* Determine new global variable location. Stack organization from top
 	 * Top 4 bytes are reserved
 	 * Pointer to global variables
@@ -45,16 +46,25 @@
 	const struct global_vars *newlocation = (struct global_vars *)((RAM_STACK_BASE - sizeof(struct global_vars *) - sizeof(struct global_vars)) & ~0x7);
 	/* Copy global variables to new location. */
 	memcpy(newlocation, global_vars(), sizeof(struct global_vars));
+	printk(BIOS_DEBUG, "disable_car global_vars copy done\n");
 	/* Set the new global variable pointer. */
 	*(struct global_vars **)(RAM_STACK_BASE - sizeof(struct global_vars *)) = newlocation;
 
+	printk(BIOS_DEBUG, "disable_car global_vars pointer adjusted\n")
+	printk(BIOS_DEBUG, "entering asm code now\n");
+
+#define HALT_AFTER 2
 	__asm__ __volatile__(
+	"	movl	%[newesp], %%esp	\n"
+
+#if ENABLE_BROKEN_CAR_DISABLING
 	/* We don't need cache as ram for now on */
 	/* disable cache */
 	"	movl    %%cr0, %%eax		\n"
 	"	orl    $(0x1<<30),%%eax		\n"
 	"	movl    %%eax, %%cr0		\n"
 
+	/* The MTRR setup below causes the machine to reset. Must investigate. */
 	/* disable fixed mtrr from now on, it will be enabled by coreboot_ram again*/
 	"	movl    %[_SYSCFG_MSR], %%ecx	\n"
 	"	rdmsr				\n"
@@ -75,10 +85,10 @@
 	"	movl    %%cr0, %%eax		\n"
 	"	andl    $0x9fffffff,%%eax	\n"
 	"	movl    %%eax, %%cr0		\n"
+#endif
 
 	"	wbinvd				\n"
 
-	"	movl	%[newesp], %%esp	\n"
 	"	call stage1_phase3		\n"
 	:: [newesp] "i" (newlocation),
 	 [_SYSCFG_MSR] "i" (SYSCFG_MSR),


-- 
http://www.hailfinger.org/

-------------- next part --------------
A non-text attachment was scrubbed...
Name: linuxbios3_car_via_disable_car_bandaid.diff
Type: text/x-patch
Size: 1821 bytes
Desc: not available
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20081101/f60ff29c/attachment.diff>

From c-d.hailfinger.devel.2006 at gmx.net  Sat Nov  1 23:32:03 2008
From: c-d.hailfinger.devel.2006 at gmx.net (Carl-Daniel Hailfinger)
Date: Sat, 01 Nov 2008 23:32:03 +0100
Subject: [coreboot] [PATCH] v3: Work around broken MTRR setup in VIA CAR
In-Reply-To: <490CD664.4090102@gmx.net>
References: <490CD664.4090102@gmx.net>
Message-ID: <490CD8E3.4090608@gmx.net>

On 01.11.2008 23:21, Carl-Daniel Hailfinger wrote:
> Once we touch the MTRRs in VIA disable_car(), the CPU resets. Since
> workarounds are better than instant reboots, mangle the code so that it
> only switches stacks and flushes the cache.
>
> There are two genuine fixes in there as well: Switch %esp before CAR is
> disabled. That way, debugging becomes easier and the stack is always valid.
>   

And one of the nastier bugs easily happening in C: We had a pointer to a
const struct, but we wanted a const pointer to a struct. This kills the
(correct) warning about that code.

> Many thanks to Corey for testing countless iterations of that code.
>
> Signed-off-by: Carl-Daniel Hailfinger <c-d.hailfinger.devel.2006 at gmx.net>
> Attached for poor gmail users.
>   

New version attached. It also fixes a missing semicolon that somehow
snuck into the earlier patch.

Regards,
Carl-Daniel

-- 
http://www.hailfinger.org/

-------------- next part --------------
A non-text attachment was scrubbed...
Name: linuxbios3_car_via_disable_car_bandaid.diff
Type: text/x-patch
Size: 2018 bytes
Desc: not available
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20081101/11292507/attachment.diff>

From c-d.hailfinger.devel.2006 at gmx.net  Sun Nov  2 00:20:13 2008
From: c-d.hailfinger.devel.2006 at gmx.net (Carl-Daniel Hailfinger)
Date: Sun, 02 Nov 2008 00:20:13 +0100
Subject: [coreboot] assistance with updating my bios
In-Reply-To: <e19d85410810300345u4f6ad25du584383a6b6cf39b2@mail.gmail.com>
References: <e19d85410810300345u4f6ad25du584383a6b6cf39b2@mail.gmail.com>
Message-ID: <490CE42D.7010707@gmx.net>

Hi Elia,

On 30.10.2008 11:45, Elia Yehuda wrote:
> I'm trying to play with coreboot to flash my bios on my PC, with no success.
> here are the computer hardware information followed by the commands I'm
> trying to execute.
>
> cpu:         Socket370 Intel Pentium III Celeron
> northbridge:    Intel 82810E
> southbridge:    Intel 8281AA
> bios device:    ST M50FW002
>   

Can you try the following flashrom patch? It should find the chip and
allow you to read it. Erase and write will NOT work and may crash.

Attached if gmail mangles the inline patch.

Add support for the ST M50FW002 chip to flashrom. Identification only,
erase/write are not implemented.

Signed-off-by: Carl-Daniel Hailfinger <c-d.hailfinger.devel.2006 at gmx.net>

Index: flashrom-M50FW002/flash.h
===================================================================
--- flashrom-M50FW002/flash.h	(Revision 3715)
+++ flashrom-M50FW002/flash.h	(Arbeitskopie)
@@ -317,6 +317,7 @@
 #define ST_M50FLW040B		0x28
 #define ST_M50FLW080A		0x80
 #define ST_M50FLW080B		0x81
+#define ST_M50FW002		0x29
 #define ST_M50FW040		0x2C
 #define ST_M50FW080		0x2D
 #define ST_M50FW016		0x2E
Index: flashrom-M50FW002/flashchips.c
===================================================================
--- flashrom-M50FW002/flashchips.c	(Revision 3715)
+++ flashrom-M50FW002/flashchips.c	(Arbeitskopie)
@@ -121,6 +121,7 @@
 	{"ST",		"M50FLW040B",		ST_ID,		ST_M50FLW040B,		512,	64 * 1024,	TEST_UNTESTED,	probe_stm50flw0x0x,	erase_stm50flw0x0x,		write_stm50flw0x0x},
 	{"ST",		"M50FLW080A",		ST_ID,		ST_M50FLW080A,		1024,	64 * 1024,	TEST_OK_PREW,	probe_stm50flw0x0x,	erase_stm50flw0x0x,		write_stm50flw0x0x},
 	{"ST",		"M50FLW080B",		ST_ID,		ST_M50FLW080B,		1024,	64 * 1024,	TEST_UNTESTED,	probe_stm50flw0x0x,	erase_stm50flw0x0x,		write_stm50flw0x0x},
+	{"ST",		"M50FW002",		ST_ID,		ST_M50FW002,		256,	64 * 1024,	TEST_UNTESTED,	probe_49lfxxxc,		NULL,			NULL},
 	{"ST",		"M50FW016",		ST_ID,		ST_M50FW016,		2048,	64 * 1024,	TEST_UNTESTED,	probe_82802ab,		erase_82802ab,			write_82802ab},
 	{"ST",		"M50FW040",		ST_ID,		ST_M50FW040,		512,	64 * 1024,	TEST_OK_PREW,	probe_82802ab,		erase_82802ab,			write_82802ab},
 	{"ST",		"M50FW080",		ST_ID,		ST_M50FW080,		1024,	64 * 1024,	TEST_UNTESTED,	probe_82802ab,		erase_82802ab,			write_82802ab},


-- 
http://www.hailfinger.org/

-------------- next part --------------
A non-text attachment was scrubbed...
Name: flashrom_st_m50fw002.diff
Type: text/x-patch
Size: 1545 bytes
Desc: not available
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20081102/91134824/attachment.diff>

From corey.osgood at gmail.com  Sun Nov  2 04:18:11 2008
From: corey.osgood at gmail.com (Corey Osgood)
Date: Sat, 1 Nov 2008 23:18:11 -0400
Subject: [coreboot] [PATCH] v3: Work around broken MTRR setup in VIA CAR
In-Reply-To: <490CD8E3.4090608@gmx.net>
References: <490CD664.4090102@gmx.net> <490CD8E3.4090608@gmx.net>
Message-ID: <dd3c80060811012018h72084498i56be5eb7e49dbaff@mail.gmail.com>

On Sat, Nov 1, 2008 at 6:32 PM, Carl-Daniel Hailfinger <
c-d.hailfinger.devel.2006 at gmx.net> wrote:

> On 01.11.2008 23:21, Carl-Daniel Hailfinger wrote:
> > Once we touch the MTRRs in VIA disable_car(), the CPU resets. Since
> > workarounds are better than instant reboots, mangle the code so that it
> > only switches stacks and flushes the cache.
> >
> > There are two genuine fixes in there as well: Switch %esp before CAR is
> > disabled. That way, debugging becomes easier and the stack is always
> valid.
> >
>
> And one of the nastier bugs easily happening in C: We had a pointer to a
> const struct, but we wanted a const pointer to a struct. This kills the
> (correct) warning about that code.
>
> > Many thanks to Corey for testing countless iterations of that code.
> >
> > Signed-off-by: Carl-Daniel Hailfinger <c-d.hailfinger.devel.2006 at gmx.net
> >
> > Attached for poor gmail users.
> >
>
> New version attached. It also fixes a missing semicolon that somehow
> snuck into the earlier patch.


Index: corebootv3-via_car/arch/x86/via/stage1.c
> ===================================================================
> --- corebootv3-via_car/arch/x86/via/stage1.c    (Revision 977)
> +++ corebootv3-via_car/arch/x86/via/stage1.c    (Arbeitskopie)
> @@ -35,6 +35,7 @@
>   */
>  void disable_car(void)
>  {
> +    printk(BIOS_DEBUG, "disable_car entry\n");
>      /* Determine new global variable location. Stack organization from top
>       * Top 4 bytes are reserved
>       * Pointer to global variables
> @@ -42,19 +43,28 @@
>       *
>        * Align the result to 8 bytes
>       */
> -    const struct global_vars *newlocation = (struct global_vars
> *)((RAM_STACK_BASE - sizeof(struct global_vars *) - sizeof(struct
> global_vars)) & ~0x7);
> +    struct global_vars *const newlocation = (struct global_vars
> *)((RAM_STACK_BASE - sizeof(struct global_vars *) - sizeof(struct
> global_vars)) & ~0x7);
>      /* Copy global variables to new location. */
>      memcpy(newlocation, global_vars(), sizeof(struct global_vars));
> +    printk(BIOS_DEBUG, "disable_car global_vars copy done\n");
>      /* Set the new global variable pointer. */
>      *(struct global_vars **)(RAM_STACK_BASE - sizeof(struct global_vars
> *)) = newlocation;
>
> +    printk(BIOS_DEBUG, "disable_car global_vars pointer adjusted\n");
> +    printk(BIOS_DEBUG, "entering asm code now\n");
> +
> +#define HALT_AFTER 2


I don't think we need that anymore ;) Tested and
Acked-by: Corey Osgood <corey.osgood at gmail.com>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20081101/fa5b6239/attachment.html>

From z4ziggy at gmail.com  Sun Nov  2 10:57:47 2008
From: z4ziggy at gmail.com (z4ziggy at gmail.com)
Date: Sun, 02 Nov 2008 01:57:47 -0800
Subject: [coreboot] assistance with updating my bios
Message-ID: <0015174be78ecdea98045ab1dc09@google.com>

sorry for the delay.

the patch works - flashrom informs "Found chip 'ST M50FW002' (256KB) at  
physical address 0xfffc0000"

whats next? :)

On Nov 2, 2008 1:20am, Carl-Daniel Hailfinger  
<cd.hailfinger.devel.2006 at gmx.net> wrote:
> Hi Elia,
>
>
>
> On 30.10.2008 11:45, Elia Yehuda wrote:
>
> > I'm trying to play with coreboot to flash my bios on my PC, with no  
success.
>
> > here are the computer hardware information followed by the commands I'm
>
> > trying to execute.
>
> >
>
> > cpu: Socket370 Intel Pentium III Celeron
>
> > northbridge: Intel 82810E
>
> > southbridge: Intel 8281AA
>
> > bios device: ST M50FW002
>
> >
>
>
>
> Can you try the following flashrom patch? It should find the chip and
>
> allow you to read it. Erase and write will NOT work and may crash.
>
>
>
> Attached if gmail mangles the inline patch.
>
>
>
> Add support for the ST M50FW002 chip to flashrom. Identification only,
>
> erase/write are not implemented.
>
>
>
> Signed-off-by: Carl-Daniel Hailfinger
>
>
>
> Index: flashrom-M50FW002/flash.h
>
> ===================================================================
>
> --- flashrom-M50FW002/flash.h (Revision 3715)
>
> +++ flashrom-M50FW002/flash.h (Arbeitskopie)
>
> @@ -317,6 +317,7 @@
>
> #define ST_M50FLW040B 0x28
>
> #define ST_M50FLW080A 0x80
>
> #define ST_M50FLW080B 0x81
>
> +#define ST_M50FW002 0x29
>
> #define ST_M50FW040 0x2C
>
> #define ST_M50FW080 0x2D
>
> #define ST_M50FW016 0x2E
>
> Index: flashrom-M50FW002/flashchips.c
>
> ===================================================================
>
> --- flashrom-M50FW002/flashchips.c (Revision 3715)
>
> +++ flashrom-M50FW002/flashchips.c (Arbeitskopie)
>
> @@ -121,6 +121,7 @@
>
> {"ST", "M50FLW040B", ST_ID, ST_M50FLW040B, 512, 64 * 1024, TEST_UNTESTED,  
probe_stm50flw0x0x, erase_stm50flw0x0x, write_stm50flw0x0x},
>
> {"ST", "M50FLW080A", ST_ID, ST_M50FLW080A, 1024, 64 * 1024, TEST_OK_PREW,  
probe_stm50flw0x0x, erase_stm50flw0x0x, write_stm50flw0x0x},
>
> {"ST", "M50FLW080B", ST_ID, ST_M50FLW080B, 1024, 64 * 1024,  
TEST_UNTESTED, probe_stm50flw0x0x, erase_stm50flw0x0x, write_stm50flw0x0x},
>
> + {"ST", "M50FW002", ST_ID, ST_M50FW002, 256, 64 * 1024, TEST_UNTESTED,  
probe_49lfxxxc, NULL, NULL},
>
> {"ST", "M50FW016", ST_ID, ST_M50FW016, 2048, 64 * 1024, TEST_UNTESTED,  
probe_82802ab, erase_82802ab, write_82802ab},
>
> {"ST", "M50FW040", ST_ID, ST_M50FW040, 512, 64 * 1024, TEST_OK_PREW,  
probe_82802ab, erase_82802ab, write_82802ab},
>
> {"ST", "M50FW080", ST_ID, ST_M50FW080, 1024, 64 * 1024, TEST_UNTESTED,  
probe_82802ab, erase_82802ab, write_82802ab},
>
>
>
>
>
> --
>
> http://www.hailfinger.org/
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20081102/170f9715/attachment.html>

From svn at coreboot.org  Sun Nov  2 12:11:40 2008
From: svn at coreboot.org (svn at coreboot.org)
Date: Sun,  2 Nov 2008 12:11:40 +0100
Subject: [coreboot] r3716 - trunk/util/inteltool
Message-ID: <mailman.2367.1355071423.16123.coreboot@coreboot.org>

Author: stepan
Date: 2008-11-02 12:11:40 +0100 (Sun, 02 Nov 2008)
New Revision: 3716

Modified:
   trunk/util/inteltool/inteltool.c
   trunk/util/inteltool/inteltool.h
   trunk/util/inteltool/memory.c
   trunk/util/inteltool/pcie.c
Log:
inteltool 82945G/GZ/P/PL Support (trivial)

Signed-off-by: Stefan Reinauer <stepan at coresystems.de>
Acked-by: Stefan Reinauer <stepan at coresystems.de>



Modified: trunk/util/inteltool/inteltool.c
===================================================================
--- trunk/util/inteltool/inteltool.c	2008-10-31 18:41:09 UTC (rev 3715)
+++ trunk/util/inteltool/inteltool.c	2008-11-02 11:11:40 UTC (rev 3716)
@@ -31,6 +31,7 @@
 	char *name;
 } supported_chips_list[] = {
 	{ PCI_VENDOR_ID_INTEL, PCI_DEVICE_ID_INTEL_82845, "i845" },
+	{ PCI_VENDOR_ID_INTEL, PCI_DEVICE_ID_INTEL_82945P, "i945P" },
 	{ PCI_VENDOR_ID_INTEL, PCI_DEVICE_ID_INTEL_82945GM, "i945GM" },
 	{ PCI_VENDOR_ID_INTEL, PCI_DEVICE_ID_INTEL_ICH7MDH, "ICH7-M DH" },
 	{ PCI_VENDOR_ID_INTEL, PCI_DEVICE_ID_INTEL_ICH7M, "ICH7-M" },

Modified: trunk/util/inteltool/inteltool.h
===================================================================
--- trunk/util/inteltool/inteltool.h	2008-10-31 18:41:09 UTC (rev 3715)
+++ trunk/util/inteltool/inteltool.h	2008-11-02 11:11:40 UTC (rev 3716)
@@ -35,6 +35,7 @@
 #define PCI_DEVICE_ID_INTEL_ICH7MDH	0x27bd
 
 #define PCI_DEVICE_ID_INTEL_82845	0x1a30
+#define PCI_DEVICE_ID_INTEL_82945P	0x2770
 #define PCI_DEVICE_ID_INTEL_82945GM	0x27a0
 
 #define ARRAY_SIZE(a) ((int)(sizeof(a) / sizeof((a)[0])))

Modified: trunk/util/inteltool/memory.c
===================================================================
--- trunk/util/inteltool/memory.c	2008-10-31 18:41:09 UTC (rev 3715)
+++ trunk/util/inteltool/memory.c	2008-11-02 11:11:40 UTC (rev 3716)
@@ -37,6 +37,7 @@
 
 	switch (nb->device_id) {
 	case PCI_DEVICE_ID_INTEL_82945GM:
+	case PCI_DEVICE_ID_INTEL_82945P:
 		mchbar_phys = pci_read_long(nb, 0x44) & 0xfffffffe;
 		break;
 	case 0x1234: // Dummy for non-existent functionality

Modified: trunk/util/inteltool/pcie.c
===================================================================
--- trunk/util/inteltool/pcie.c	2008-10-31 18:41:09 UTC (rev 3715)
+++ trunk/util/inteltool/pcie.c	2008-11-02 11:11:40 UTC (rev 3716)
@@ -36,6 +36,7 @@
 
 	switch (nb->device_id) {
 	case PCI_DEVICE_ID_INTEL_82945GM:
+	case PCI_DEVICE_ID_INTEL_82945P:
 		epbar_phys = pci_read_long(nb, 0x40) & 0xfffffffe;
 		break;
 	case 0x1234: // Dummy for non-existent functionality
@@ -77,6 +78,7 @@
 
 	switch (nb->device_id) {
 	case PCI_DEVICE_ID_INTEL_82945GM:
+	case PCI_DEVICE_ID_INTEL_82945P:
 		dmibar_phys = pci_read_long(nb, 0x4c) & 0xfffffffe;
 		break;
 	case 0x1234: // Dummy for non-existent functionality
@@ -120,6 +122,7 @@
 
 	switch (nb->device_id) {
 	case PCI_DEVICE_ID_INTEL_82945GM:
+	case PCI_DEVICE_ID_INTEL_82945P:
 		pciexbar_reg = pci_read_long(nb, 0x48);
 		break;
 	case 0x1234: // Dummy for non-existent functionality




From z4ziggy at gmail.com  Sun Nov  2 15:18:21 2008
From: z4ziggy at gmail.com (Elia Yehuda)
Date: Sun, 2 Nov 2008 16:18:21 +0200
Subject: [coreboot] assistance with updating my bios
In-Reply-To: <490CE42D.7010707@gmx.net>
References: <e19d85410810300345u4f6ad25du584383a6b6cf39b2@mail.gmail.com>
	<490CE42D.7010707@gmx.net>
Message-ID: <e19d85410811020618g260fdb60ka7df0d9365b8797f@mail.gmail.com>

On Sun, Nov 2, 2008 at 1:20 AM, Carl-Daniel Hailfinger <
c-d.hailfinger.devel.2006 at gmx.net> wrote:

> Hi Elia,
>
> On 30.10.2008 11:45, Elia Yehuda wrote:
> > I'm trying to play with coreboot to flash my bios on my PC, with no
> success.
> > here are the computer hardware information followed by the commands I'm
> > trying to execute.
> >
> > cpu:         Socket370 Intel Pentium III Celeron
> > northbridge:    Intel 82810E
> > southbridge:    Intel 8281AA
> > bios device:    ST M50FW002
> >
>
> Can you try the following flashrom patch? It should find the chip and
> allow you to read it. Erase and write will NOT work and may crash.
>
> Attached if gmail mangles the inline patch.
>
> Add support for the ST M50FW002 chip to flashrom. Identification only,
> erase/write are not implemented.
>
> Signed-off-by: Carl-Daniel Hailfinger <c-d.hailfinger.devel.2006 at gmx.net>

tested and
Acked-by: Elia Yehuda <z4ziggy at gmail.com>


>
>
> Index: flashrom-M50FW002/flash.h
> ===================================================================
> --- flashrom-M50FW002/flash.h   (Revision 3715)
> +++ flashrom-M50FW002/flash.h   (Arbeitskopie)
> @@ -317,6 +317,7 @@
>  #define ST_M50FLW040B          0x28
>  #define ST_M50FLW080A          0x80
>  #define ST_M50FLW080B          0x81
> +#define ST_M50FW002            0x29
>  #define ST_M50FW040            0x2C
>  #define ST_M50FW080            0x2D
>  #define ST_M50FW016            0x2E
> Index: flashrom-M50FW002/flashchips.c
> ===================================================================
> --- flashrom-M50FW002/flashchips.c      (Revision 3715)
> +++ flashrom-M50FW002/flashchips.c      (Arbeitskopie)
> @@ -121,6 +121,7 @@
>        {"ST",          "M50FLW040B",           ST_ID,
>  ST_M50FLW040B,          512,    64 * 1024,      TEST_UNTESTED,
>  probe_stm50flw0x0x,     erase_stm50flw0x0x,
> write_stm50flw0x0x},
>        {"ST",          "M50FLW080A",           ST_ID,
>  ST_M50FLW080A,          1024,   64 * 1024,      TEST_OK_PREW,
> probe_stm50flw0x0x,     erase_stm50flw0x0x,             write_stm50flw0x0x},
>        {"ST",          "M50FLW080B",           ST_ID,
>  ST_M50FLW080B,          1024,   64 * 1024,      TEST_UNTESTED,
>  probe_stm50flw0x0x,     erase_stm50flw0x0x,
> write_stm50flw0x0x},
> +       {"ST",          "M50FW002",             ST_ID,
>  ST_M50FW002,            256,    64 * 1024,      TEST_UNTESTED,
>  probe_49lfxxxc,         NULL,                   NULL},
>        {"ST",          "M50FW016",             ST_ID,          ST_M50FW016,
>            2048,   64 * 1024,      TEST_UNTESTED,  probe_82802ab,
>  erase_82802ab,                  write_82802ab},
>        {"ST",          "M50FW040",             ST_ID,          ST_M50FW040,
>            512,    64 * 1024,      TEST_OK_PREW,   probe_82802ab,
>  erase_82802ab,                  write_82802ab},
>        {"ST",          "M50FW080",             ST_ID,          ST_M50FW080,
>            1024,   64 * 1024,      TEST_UNTESTED,  probe_82802ab,
>  erase_82802ab,                  write_82802ab},
>
>
> --
> http://www.hailfinger.org/
>
> tested and
Acked-by: Elia Yehuda <z4ziggy at gmail.com>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20081102/e9a6614d/attachment.html>

From svn at coreboot.org  Sun Nov  2 15:25:11 2008
From: svn at coreboot.org (svn at coreboot.org)
Date: Sun,  2 Nov 2008 15:25:11 +0100
Subject: [coreboot] r3717 - trunk/util/flashrom
Message-ID: <mailman.2368.1355071423.16123.coreboot@coreboot.org>

Author: hailfinger
Date: 2008-11-02 15:25:11 +0100 (Sun, 02 Nov 2008)
New Revision: 3717

Modified:
   trunk/util/flashrom/flash.h
   trunk/util/flashrom/flashchips.c
Log:
Add support for the ST M50FW002 chip to flashrom. Identification only,
erase/write are not implemented.

Signed-off-by: Carl-Daniel Hailfinger <c-d.hailfinger.devel.2006 at gmx.net>

tested and
Acked-by: Elia Yehuda <z4ziggy at gmail.com>


Modified: trunk/util/flashrom/flash.h
===================================================================
--- trunk/util/flashrom/flash.h	2008-11-02 11:11:40 UTC (rev 3716)
+++ trunk/util/flashrom/flash.h	2008-11-02 14:25:11 UTC (rev 3717)
@@ -317,6 +317,7 @@
 #define ST_M50FLW040B		0x28
 #define ST_M50FLW080A		0x80
 #define ST_M50FLW080B		0x81
+#define ST_M50FW002		0x29
 #define ST_M50FW040		0x2C
 #define ST_M50FW080		0x2D
 #define ST_M50FW016		0x2E

Modified: trunk/util/flashrom/flashchips.c
===================================================================
--- trunk/util/flashrom/flashchips.c	2008-11-02 11:11:40 UTC (rev 3716)
+++ trunk/util/flashrom/flashchips.c	2008-11-02 14:25:11 UTC (rev 3717)
@@ -121,6 +121,7 @@
 	{"ST",		"M50FLW040B",		ST_ID,		ST_M50FLW040B,		512,	64 * 1024,	TEST_UNTESTED,	probe_stm50flw0x0x,	erase_stm50flw0x0x,		write_stm50flw0x0x},
 	{"ST",		"M50FLW080A",		ST_ID,		ST_M50FLW080A,		1024,	64 * 1024,	TEST_OK_PREW,	probe_stm50flw0x0x,	erase_stm50flw0x0x,		write_stm50flw0x0x},
 	{"ST",		"M50FLW080B",		ST_ID,		ST_M50FLW080B,		1024,	64 * 1024,	TEST_UNTESTED,	probe_stm50flw0x0x,	erase_stm50flw0x0x,		write_stm50flw0x0x},
+	{"ST",		"M50FW002",		ST_ID,		ST_M50FW002,		256,	64 * 1024,	TEST_UNTESTED,	probe_49lfxxxc,		NULL,			NULL},
 	{"ST",		"M50FW016",		ST_ID,		ST_M50FW016,		2048,	64 * 1024,	TEST_UNTESTED,	probe_82802ab,		erase_82802ab,			write_82802ab},
 	{"ST",		"M50FW040",		ST_ID,		ST_M50FW040,		512,	64 * 1024,	TEST_OK_PREW,	probe_82802ab,		erase_82802ab,			write_82802ab},
 	{"ST",		"M50FW080",		ST_ID,		ST_M50FW080,		1024,	64 * 1024,	TEST_UNTESTED,	probe_82802ab,		erase_82802ab,			write_82802ab},




From c-d.hailfinger.devel.2006 at gmx.net  Sun Nov  2 15:25:48 2008
From: c-d.hailfinger.devel.2006 at gmx.net (Carl-Daniel Hailfinger)
Date: Sun, 02 Nov 2008 15:25:48 +0100
Subject: [coreboot] assistance with updating my bios
In-Reply-To: <e19d85410811020618g260fdb60ka7df0d9365b8797f@mail.gmail.com>
References: <e19d85410810300345u4f6ad25du584383a6b6cf39b2@mail.gmail.com>	
	<490CE42D.7010707@gmx.net>
	<e19d85410811020618g260fdb60ka7df0d9365b8797f@mail.gmail.com>
Message-ID: <490DB86C.1020706@gmx.net>

On 02.11.2008 15:18, Elia Yehuda wrote:
> On Sun, Nov 2, 2008 at 1:20 AM, Carl-Daniel Hailfinger <
> c-d.hailfinger.devel.2006 at gmx.net> wrote:
>
>   
>> Hi Elia,
>>
>> On 30.10.2008 11:45, Elia Yehuda wrote:
>>     
>>> I'm trying to play with coreboot to flash my bios on my PC, with no
>>>       
>> success.
>>     
>>> here are the computer hardware information followed by the commands I'm
>>> trying to execute.
>>>
>>> cpu:         Socket370 Intel Pentium III Celeron
>>> northbridge:    Intel 82810E
>>> southbridge:    Intel 8281AA
>>> bios device:    ST M50FW002
>>>
>>>       
>> Can you try the following flashrom patch? It should find the chip and
>> allow you to read it. Erase and write will NOT work and may crash.
>>
>> Attached if gmail mangles the inline patch.
>>
>> Add support for the ST M50FW002 chip to flashrom. Identification only,
>> erase/write are not implemented.
>>
>> Signed-off-by: Carl-Daniel Hailfinger <c-d.hailfinger.devel.2006 at gmx.net>
>>     
>
> tested and
> Acked-by: Elia Yehuda <z4ziggy at gmail.com>
>   

Thanks, committed in r3717.

Regards,
Carl-Daniel

-- 
http://www.hailfinger.org/




From svn at coreboot.org  Sun Nov  2 15:33:51 2008
From: svn at coreboot.org (svn at coreboot.org)
Date: Sun,  2 Nov 2008 15:33:51 +0100
Subject: [coreboot] r3718 - trunk/coreboot-v2/src/southbridge/intel/i82801xx
Message-ID: <mailman.2369.1355071423.16123.coreboot@coreboot.org>

Author: uwe
Date: 2008-11-02 15:33:51 +0100 (Sun, 02 Nov 2008)
New Revision: 3718

Modified:
   trunk/coreboot-v2/src/southbridge/intel/i82801xx/i82801xx_ac97.c
   trunk/coreboot-v2/src/southbridge/intel/i82801xx/i82801xx_nic.c
   trunk/coreboot-v2/src/southbridge/intel/i82801xx/i82801xx_smbus.c
   trunk/coreboot-v2/src/southbridge/intel/i82801xx/i82801xx_usb.c
Log:
Trim down the list of southbridges supported by the i82801xx driver
to only a set of reasonably similar ones, namely (for now) ICH0* - ICH6*,
and C-ICH.

All later ICH* southbridges (ICH7-ICH10) are _very_ different and were surely
not working with this driver anyway (and there's no chance to support
them reasonably with this driver without ending up in #ifdef hell).

ICH7 now has an extra driver in svn, whether ICH8-ICH10 are similar
enough to be supported by that ICH7 driver remains to be seen.

This patch was informally acked by Stefan Reinauer
<stepan at coresystems.de> on IRC.

Signed-off-by: Uwe Hermann <uwe at hermann-uwe.de>
Acked-by: Uwe Hermann <uwe at hermann-uwe.de>



Modified: trunk/coreboot-v2/src/southbridge/intel/i82801xx/i82801xx_ac97.c
===================================================================
--- trunk/coreboot-v2/src/southbridge/intel/i82801xx/i82801xx_ac97.c	2008-11-02 14:25:11 UTC (rev 3717)
+++ trunk/coreboot-v2/src/southbridge/intel/i82801xx/i82801xx_ac97.c	2008-11-02 14:33:51 UTC (rev 3718)
@@ -126,19 +126,3 @@
 	.vendor	= PCI_VENDOR_ID_INTEL,
 	.device	= PCI_DEVICE_ID_INTEL_82801FB_AC97_MODEM,
 };
-
-/* 82801GB/GR/GDH/GBM/GHM (ICH7/ICH7R/ICH7DH/ICH7-M/ICH7-M DH) */
-/* Note: 82801GU (ICH7-U) doesn't have AC97 audio/modem. */
-static const struct pci_driver i82801gb_ac97_audio __pci_driver = {
-	.ops	= &ac97_ops,
-	.vendor	= PCI_VENDOR_ID_INTEL,
-	.device	= PCI_DEVICE_ID_INTEL_82801GB_AC97_AUDIO,
-};
-
-static const struct pci_driver i82801gb_ac97_modem __pci_driver = {
-	.ops	= &ac97_ops,
-	.vendor	= PCI_VENDOR_ID_INTEL,
-	.device	= PCI_DEVICE_ID_INTEL_82801GB_AC97_MODEM,
-};
-
-/* Note: There's no AC97 audio/modem on ICH8/ICH9/C-ICH. */

Modified: trunk/coreboot-v2/src/southbridge/intel/i82801xx/i82801xx_nic.c
===================================================================
--- trunk/coreboot-v2/src/southbridge/intel/i82801xx/i82801xx_nic.c	2008-11-02 14:25:11 UTC (rev 3717)
+++ trunk/coreboot-v2/src/southbridge/intel/i82801xx/i82801xx_nic.c	2008-11-02 14:33:51 UTC (rev 3718)
@@ -63,28 +63,6 @@
 	.device	= PCI_DEVICE_ID_INTEL_82801FB_LAN,
 };
 
-/* 82801GB/GR/GDH/GBM/GHM (ICH7/ICH7R/ICH7DH/ICH7-M/ICH7-M DH) */
-/* Note: 82801GU (ICH7-U) doesn't have a NIC. */
-static const struct pci_driver i82801gb_nic __pci_driver = {
-	.ops	= &nic_ops,
-	.vendor	= PCI_VENDOR_ID_INTEL,
-	.device	= PCI_DEVICE_ID_INTEL_82801GB_LAN,
-};
-
-/* 82801HB/HR/HDH/HDO/HBM/HEM (ICH8/ICH8R/ICH8DH/ICH8DO/ICH8M/ICH8M-E) */
-static const struct pci_driver i82801hb_nic __pci_driver = {
-	.ops	= &nic_ops,
-	.vendor	= PCI_VENDOR_ID_INTEL,
-	.device	= PCI_DEVICE_ID_INTEL_82801HB_LAN,
-};
-
-/* 82801IB/IR/IH/IO (ICH9/ICH9R/ICH9DH/ICH9DO) */
-static const struct pci_driver i82801ib_nic __pci_driver = {
-	.ops	= &nic_ops,
-	.vendor	= PCI_VENDOR_ID_INTEL,
-	.device	= PCI_DEVICE_ID_INTEL_82801IB_LAN,
-};
-
 /* 82801E (C-ICH) */
 static const struct pci_driver i82801e_nic1 __pci_driver = {
 	.ops	= &nic_ops,

Modified: trunk/coreboot-v2/src/southbridge/intel/i82801xx/i82801xx_smbus.c
===================================================================
--- trunk/coreboot-v2/src/southbridge/intel/i82801xx/i82801xx_smbus.c	2008-11-02 14:25:11 UTC (rev 3717)
+++ trunk/coreboot-v2/src/southbridge/intel/i82801xx/i82801xx_smbus.c	2008-11-02 14:33:51 UTC (rev 3718)
@@ -101,27 +101,6 @@
 	.device	= PCI_DEVICE_ID_INTEL_82801FB_SMB,
 };
 
-/* 82801GB/GR/GDH/GBM/GHM/GU (ICH7/ICH7R/ICH7DH/ICH7-M/ICH7-M DH/ICH7-U) */
-static const struct pci_driver i82801gb_smb __pci_driver = {
-	.ops	= &smbus_ops,
-	.vendor	= PCI_VENDOR_ID_INTEL,
-	.device	= PCI_DEVICE_ID_INTEL_82801GB_SMB,
-};
-
-/* 82801HB/HR/HDH/HDO/HBM/HEM (ICH8/ICH8R/ICH8DH/ICH8DO/ICH8M/ICH8M-E) */
-static const struct pci_driver i82801hb_smb __pci_driver = {
-	.ops	= &smbus_ops,
-	.vendor	= PCI_VENDOR_ID_INTEL,
-	.device	= PCI_DEVICE_ID_INTEL_82801HB_LAN,
-};
-
-/* 82801IB/IR/IH/IO (ICH9/ICH9R/ICH9DH/ICH9DO) */
-static const struct pci_driver i82801ib_smb __pci_driver = {
-	.ops	= &smbus_ops,
-	.vendor	= PCI_VENDOR_ID_INTEL,
-	.device	= PCI_DEVICE_ID_INTEL_82801IB_SMB,
-};
-
 /* 82801E (C-ICH) */
 static const struct pci_driver i82801e_smb __pci_driver = {
 	.ops	= &smbus_ops,

Modified: trunk/coreboot-v2/src/southbridge/intel/i82801xx/i82801xx_usb.c
===================================================================
--- trunk/coreboot-v2/src/southbridge/intel/i82801xx/i82801xx_usb.c	2008-11-02 14:25:11 UTC (rev 3717)
+++ trunk/coreboot-v2/src/southbridge/intel/i82801xx/i82801xx_usb.c	2008-11-02 14:33:51 UTC (rev 3718)
@@ -155,99 +155,6 @@
 	.device	= PCI_DEVICE_ID_INTEL_82801FB_USB4,
 };
 
-/* 82801GB/GR/GDH/GBM/GHM/GU (ICH7/ICH7R/ICH7DH/ICH7-M/ICH7-M DH/ICH7-U) */
-static const struct pci_driver i82801gb_usb1 __pci_driver = {
-	.ops	= &usb_ops,
-	.vendor	= PCI_VENDOR_ID_INTEL,
-	.device	= PCI_DEVICE_ID_INTEL_82801GB_USB1,
-};
-
-static const struct pci_driver i82801gb_usb2 __pci_driver = {
-	.ops	= &usb_ops,
-	.vendor	= PCI_VENDOR_ID_INTEL,
-	.device	= PCI_DEVICE_ID_INTEL_82801GB_USB2,
-};
-
-static const struct pci_driver i82801gb_usb3 __pci_driver = {
-	.ops	= &usb_ops,
-	.vendor	= PCI_VENDOR_ID_INTEL,
-	.device	= PCI_DEVICE_ID_INTEL_82801GB_USB3,
-};
-
-static const struct pci_driver i82801gb_usb4 __pci_driver = {
-	.ops	= &usb_ops,
-	.vendor	= PCI_VENDOR_ID_INTEL,
-	.device	= PCI_DEVICE_ID_INTEL_82801GB_USB4,
-};
-
-/* 82801HB/HR/HDH/HDO/HBM/HEM (ICH8/ICH8R/ICH8DH/ICH8DO/ICH8M/ICH8M-E) */
-static const struct pci_driver i82801hb_usb1 __pci_driver = {
-	.ops	= &usb_ops,
-	.vendor	= PCI_VENDOR_ID_INTEL,
-	.device	= PCI_DEVICE_ID_INTEL_82801HB_USB1,
-};
-
-static const struct pci_driver i82801hb_usb2 __pci_driver = {
-	.ops	= &usb_ops,
-	.vendor	= PCI_VENDOR_ID_INTEL,
-	.device	= PCI_DEVICE_ID_INTEL_82801HB_USB2,
-};
-
-static const struct pci_driver i82801hb_usb3 __pci_driver = {
-	.ops	= &usb_ops,
-	.vendor	= PCI_VENDOR_ID_INTEL,
-	.device	= PCI_DEVICE_ID_INTEL_82801HB_USB3,
-};
-
-static const struct pci_driver i82801hb_usb4 __pci_driver = {
-	.ops	= &usb_ops,
-	.vendor	= PCI_VENDOR_ID_INTEL,
-	.device	= PCI_DEVICE_ID_INTEL_82801HB_USB4,
-};
-
-static const struct pci_driver i82801hb_usb5 __pci_driver = {
-	.ops	= &usb_ops,
-	.vendor	= PCI_VENDOR_ID_INTEL,
-	.device	= PCI_DEVICE_ID_INTEL_82801HB_USB5,
-};
-
-/* 82801IB/IR/IH/IO (ICH9/ICH9R/ICH9DH/ICH9DO) */
-static const struct pci_driver i82801ib_usb1 __pci_driver = {
-	.ops	= &usb_ops,
-	.vendor	= PCI_VENDOR_ID_INTEL,
-	.device	= PCI_DEVICE_ID_INTEL_82801IB_USB1,
-};
-
-static const struct pci_driver i82801ib_usb2 __pci_driver = {
-	.ops	= &usb_ops,
-	.vendor	= PCI_VENDOR_ID_INTEL,
-	.device	= PCI_DEVICE_ID_INTEL_82801IB_USB2,
-};
-
-static const struct pci_driver i82801ib_usb3 __pci_driver = {
-	.ops	= &usb_ops,
-	.vendor	= PCI_VENDOR_ID_INTEL,
-	.device	= PCI_DEVICE_ID_INTEL_82801IB_USB3,
-};
-
-static const struct pci_driver i82801ib_usb4 __pci_driver = {
-	.ops	= &usb_ops,
-	.vendor	= PCI_VENDOR_ID_INTEL,
-	.device	= PCI_DEVICE_ID_INTEL_82801IB_USB4,
-};
-
-static const struct pci_driver i82801ib_usb5 __pci_driver = {
-	.ops	= &usb_ops,
-	.vendor	= PCI_VENDOR_ID_INTEL,
-	.device	= PCI_DEVICE_ID_INTEL_82801IB_USB5,
-};
-
-static const struct pci_driver i82801ib_usb6 __pci_driver = {
-	.ops	= &usb_ops,
-	.vendor	= PCI_VENDOR_ID_INTEL,
-	.device	= PCI_DEVICE_ID_INTEL_82801IB_USB6,
-};
-
 /* 82801E (C-ICH) */
 static const struct pci_driver i82801e_usb __pci_driver = {
 	.ops	= &usb_ops,




From uwe at hermann-uwe.de  Sun Nov  2 15:34:27 2008
From: uwe at hermann-uwe.de (Uwe Hermann)
Date: Sun, 2 Nov 2008 15:34:27 +0100
Subject: [coreboot] [PATCH] v2: Trim i82801xx driver to only a
	sensible	subset
In-Reply-To: <20081024013443.8984.qmail@stuge.se>
References: <20081017170621.GB28924@greenwood>
	<20081023200038.GB14982@greenwood>
	<20081024013443.8984.qmail@stuge.se>
Message-ID: <20081102143427.GI18273@greenwood>

On Fri, Oct 24, 2008 at 03:34:43AM +0200, Peter Stuge wrote:
> Uwe Hermann wrote:
> > > Trim down the list of southbridges supported by the i82801xx driver
> > > to only a set of reasonably similar ones, namely (for now) ICH0* -
> > > ICH6*, and C-ICH.
> > 
> > *ping*
> > 
> > Any objections?
> 
> I'm ok with this but I would like to hear from Stefan.

He informally acked it on IRC, committed in r3718.


Uwe.
-- 
http://www.hermann-uwe.de  | http://www.holsham-traders.de
http://www.crazy-hacks.org | http://www.unmaintained-free-software.org



From info at coresystems.de  Sun Nov  2 15:41:51 2008
From: info at coresystems.de (coreboot information)
Date: Sun, 02 Nov 2008 15:41:51 +0100
Subject: [coreboot] r3717 build service
Message-ID: <E1Kwe9H-0006m1-U2@ra.coresystems.de>

Dear coreboot readers!

This is the automated build check service of coreboot.

The developer "hailfinger" checked in revision 3717 to
the coreboot source repository and caused the following 
changes:

Change Log:
Add support for the ST M50FW002 chip to flashrom. Identification only,
erase/write are not implemented.

Signed-off-by: Carl-Daniel Hailfinger <c-d.hailfinger.devel.2006 at gmx.net>

tested and
Acked-by: Elia Yehuda <z4ziggy at gmail.com>


Build Log:
Compilation of iwill:dk8_htx has been broken
See the error log at http://qa.coreboot.org/log_buildbrd.php?revision=3717&device=dk8_htx&vendor=iwill


If something broke during this checkin please be a pain 
in hailfinger's neck until the issue is fixed.

If this issue is not fixed within 24h the revision should 
be backed out.

   Best regards,
     coreboot automatic build system





From svn at coreboot.org  Sun Nov  2 15:47:22 2008
From: svn at coreboot.org (svn at coreboot.org)
Date: Sun,  2 Nov 2008 15:47:22 +0100
Subject: [coreboot] r978 - in coreboot-v3/arch/x86: . via
Message-ID: <mailman.2370.1355071423.16123.coreboot@coreboot.org>

Author: hailfinger
Date: 2008-11-02 15:47:21 +0100 (Sun, 02 Nov 2008)
New Revision: 978

Modified:
   coreboot-v3/arch/x86/stage1.c
   coreboot-v3/arch/x86/via/stage1.c
Log:
Once we touch the MTRRs in VIA disable_car(), the CPU resets. Since
workarounds are better than instant reboots, mangle the code so that it
only switches stacks and flushes the cache.

There are two genuine fix in there as well:
We have to switch %esp before CAR is disabled. That way, the stack is
always valid.
And one of the nastier bugs easily happening in C: We had a pointer to a
const struct, but we wanted a const pointer to a struct. This kills the
(correct) warning about that code.

Many thanks to Corey for testing countless iterations of that code.

Signed-off-by: Carl-Daniel Hailfinger <c-d.hailfinger.devel.2006 at gmx.net>
Tested and
Acked-by: Corey Osgood <corey.osgood at gmail.com>


Modified: coreboot-v3/arch/x86/stage1.c
===================================================================
--- coreboot-v3/arch/x86/stage1.c	2008-11-01 04:33:36 UTC (rev 977)
+++ coreboot-v3/arch/x86/stage1.c	2008-11-02 14:47:21 UTC (rev 978)
@@ -263,6 +263,7 @@
 #ifdef CONFIG_CONSOLE_BUFFER
 	/* Move the printk buffer to PRINTK_BUF_ADDR_RAM */
 	printk_buffer_move((void *)PRINTK_BUF_ADDR_RAM, PRINTK_BUF_SIZE_RAM);
+	printk(BIOS_DEBUG, "Done printk() buffer move\n");
 #endif
 	/* Turn off Cache-As-Ram */
 	disable_car();

Modified: coreboot-v3/arch/x86/via/stage1.c
===================================================================
--- coreboot-v3/arch/x86/via/stage1.c	2008-11-01 04:33:36 UTC (rev 977)
+++ coreboot-v3/arch/x86/via/stage1.c	2008-11-02 14:47:21 UTC (rev 978)
@@ -35,6 +35,7 @@
  */
 void disable_car(void)
 {
+	printk(BIOS_DEBUG, "disable_car entry\n");
 	/* Determine new global variable location. Stack organization from top
 	 * Top 4 bytes are reserved
 	 * Pointer to global variables
@@ -42,19 +43,27 @@
 	 *
  	 * Align the result to 8 bytes
 	 */
-	const struct global_vars *newlocation = (struct global_vars *)((RAM_STACK_BASE - sizeof(struct global_vars *) - sizeof(struct global_vars)) & ~0x7);
+	struct global_vars *const newlocation = (struct global_vars *)((RAM_STACK_BASE - sizeof(struct global_vars *) - sizeof(struct global_vars)) & ~0x7);
 	/* Copy global variables to new location. */
 	memcpy(newlocation, global_vars(), sizeof(struct global_vars));
+	printk(BIOS_DEBUG, "disable_car global_vars copy done\n");
 	/* Set the new global variable pointer. */
 	*(struct global_vars **)(RAM_STACK_BASE - sizeof(struct global_vars *)) = newlocation;
 
+	printk(BIOS_DEBUG, "disable_car global_vars pointer adjusted\n");
+	printk(BIOS_DEBUG, "entering asm code now\n");
+
 	__asm__ __volatile__(
+	"	movl	%[newesp], %%esp	\n"
+
+#if ENABLE_BROKEN_CAR_DISABLING
 	/* We don't need cache as ram for now on */
 	/* disable cache */
 	"	movl    %%cr0, %%eax		\n"
 	"	orl    $(0x1<<30),%%eax		\n"
 	"	movl    %%eax, %%cr0		\n"
 
+	/* The MTRR setup below causes the machine to reset. Must investigate. */
 	/* disable fixed mtrr from now on, it will be enabled by coreboot_ram again*/
 	"	movl    %[_SYSCFG_MSR], %%ecx	\n"
 	"	rdmsr				\n"
@@ -75,10 +84,10 @@
 	"	movl    %%cr0, %%eax		\n"
 	"	andl    $0x9fffffff,%%eax	\n"
 	"	movl    %%eax, %%cr0		\n"
+#endif
 
 	"	wbinvd				\n"
 
-	"	movl	%[newesp], %%esp	\n"
 	"	call stage1_phase3		\n"
 	:: [newesp] "i" (newlocation),
 	 [_SYSCFG_MSR] "i" (SYSCFG_MSR),




From c-d.hailfinger.devel.2006 at gmx.net  Sun Nov  2 15:49:42 2008
From: c-d.hailfinger.devel.2006 at gmx.net (Carl-Daniel Hailfinger)
Date: Sun, 02 Nov 2008 15:49:42 +0100
Subject: [coreboot] [PATCH] v3: Work around broken MTRR setup in VIA CAR
In-Reply-To: <dd3c80060811012018h72084498i56be5eb7e49dbaff@mail.gmail.com>
References: <490CD664.4090102@gmx.net> <490CD8E3.4090608@gmx.net>
	<dd3c80060811012018h72084498i56be5eb7e49dbaff@mail.gmail.com>
Message-ID: <490DBE06.9080108@gmx.net>

On 02.11.2008 04:18, Corey Osgood wrote:
> On Sat, Nov 1, 2008 at 6:32 PM, Carl-Daniel Hailfinger <
> c-d.hailfinger.devel.2006 at gmx.net> wrote:
>
>   
>> On 01.11.2008 23:21, Carl-Daniel Hailfinger wrote:
>>     
>>> Once we touch the MTRRs in VIA disable_car(), the CPU resets. Since
>>> workarounds are better than instant reboots, mangle the code so that it
>>> only switches stacks and flushes the cache.
>>>
>>> There are two genuine fixes in there as well: Switch %esp before CAR is
>>> disabled. That way, debugging becomes easier and the stack is always
>>>       
>> valid.
>>     
>> And one of the nastier bugs easily happening in C: We had a pointer to a
>> const struct, but we wanted a const pointer to a struct. This kills the
>> (correct) warning about that code.
>>
>>     
>>> Many thanks to Corey for testing countless iterations of that code.
>>>
>>> Signed-off-by: Carl-Daniel Hailfinger <c-d.hailfinger.devel.2006 at gmx.net
>>>
>>> Attached for poor gmail users.
>>>
>>>       
>> New version attached. It also fixes a missing semicolon that somehow
>> snuck into the earlier patch.
>>
>> [...]
>>     
>
> I don't think we need that anymore ;)

Thanks for the hint about the testing leftovers.

> Tested and
> Acked-by: Corey Osgood <corey.osgood at gmail.com>
>   

Thanks, committed in r978.

Regards,
Carl-Daniel

-- 
http://www.hailfinger.org/




From info at coresystems.de  Sun Nov  2 16:00:23 2008
From: info at coresystems.de (coreboot information)
Date: Sun, 02 Nov 2008 16:00:23 +0100
Subject: [coreboot] r3718 build service
Message-ID: <E1KweRD-0008Tu-Hj@ra.coresystems.de>

Dear coreboot readers!

This is the automated build check service of coreboot.

The developer "uwe" checked in revision 3718 to
the coreboot source repository and caused the following 
changes:

Change Log:
Trim down the list of southbridges supported by the i82801xx driver
to only a set of reasonably similar ones, namely (for now) ICH0* - ICH6*,
and C-ICH.

All later ICH* southbridges (ICH7-ICH10) are _very_ different and were surely
not working with this driver anyway (and there's no chance to support
them reasonably with this driver without ending up in #ifdef hell).

ICH7 now has an extra driver in svn, whether ICH8-ICH10 are similar
enough to be supported by that ICH7 driver remains to be seen.

This patch was informally acked by Stefan Reinauer
<stepan at coresystems.de> on IRC.

Signed-off-by: Uwe Hermann <uwe at hermann-uwe.de>
Acked-by: Uwe Hermann <uwe at hermann-uwe.de>



Build Log:
Compilation of iwill:dk8_htx has been fixed


If something broke during this checkin please be a pain 
in uwe's neck until the issue is fixed.

If this issue is not fixed within 24h the revision should 
be backed out.

   Best regards,
     coreboot automatic build system





From svn at coreboot.org  Sun Nov  2 18:01:06 2008
From: svn at coreboot.org (svn at coreboot.org)
Date: Sun,  2 Nov 2008 18:01:06 +0100
Subject: [coreboot] r3719 - in trunk/payloads: . bayou bayou/util
	bayou/util/pbuilder bayou/util/pbuilder/liblar
Message-ID: <mailman.2371.1355071423.16123.coreboot@coreboot.org>

Author: uwe
Date: 2008-11-02 18:01:06 +0100 (Sun, 02 Nov 2008)
New Revision: 3719

Added:
   trunk/payloads/bayou/
   trunk/payloads/bayou/Makefile
   trunk/payloads/bayou/bayou.h
   trunk/payloads/bayou/bayou.ldscript
   trunk/payloads/bayou/config.c
   trunk/payloads/bayou/lzma.c
   trunk/payloads/bayou/lzmadecode.c
   trunk/payloads/bayou/lzmadecode.h
   trunk/payloads/bayou/main.c
   trunk/payloads/bayou/menu.c
   trunk/payloads/bayou/nrv2b.c
   trunk/payloads/bayou/payload.c
   trunk/payloads/bayou/self.c
   trunk/payloads/bayou/self.h
   trunk/payloads/bayou/util/
   trunk/payloads/bayou/util/pbuilder/
   trunk/payloads/bayou/util/pbuilder/Makefile
   trunk/payloads/bayou/util/pbuilder/config.c
   trunk/payloads/bayou/util/pbuilder/create.c
   trunk/payloads/bayou/util/pbuilder/liblar/
   trunk/payloads/bayou/util/pbuilder/liblar/Makefile
   trunk/payloads/bayou/util/pbuilder/liblar/lar.h
   trunk/payloads/bayou/util/pbuilder/liblar/lib.c
   trunk/payloads/bayou/util/pbuilder/liblar/liblar.h
   trunk/payloads/bayou/util/pbuilder/liblar/self.c
   trunk/payloads/bayou/util/pbuilder/liblar/self.h
   trunk/payloads/bayou/util/pbuilder/main.c
   trunk/payloads/bayou/util/pbuilder/pbuilder.h
   trunk/payloads/bayou/util/pbuilder/show.c
Log:
Import a slightly modified Bayou version into svn. This is based
on the last snapshot posted by Jordan Crouse. This commit is long
overdue.

Changes by me include:

 - Rename 'utils' to 'util' for consistency with our other projects.

 - Move the main code out of src/* into the top-level directory.

 - Add missing license headers to the following files:
   Makefile, pbuilder/liblar/Makefile, util/pbuilder/Makefile.

 - Dropped the util/pbuilder/lzma completely. I'm working on reusing
   the lzma/ dir from v3 via svn:externals. Alas, this also means
   that Bayou won't yet compile out of the box.

 - Coding-style and white-space fixes (indent) for all files.

Signed-off-by: Uwe Hermann <uwe at hermann-uwe.de>
Acked-by: Uwe Hermann <uwe at hermann-uwe.de>



Added: trunk/payloads/bayou/Makefile
===================================================================
--- trunk/payloads/bayou/Makefile	                        (rev 0)
+++ trunk/payloads/bayou/Makefile	2008-11-02 17:01:06 UTC (rev 3719)
@@ -0,0 +1,65 @@
+##
+## This file is part of the bayou project.
+##
+## Copyright (C) 2008 Advanced Micro Devices, Inc.
+##
+## This program is free software; you can redistribute it and/or modify
+## it under the terms of the GNU General Public License version 2 as
+## published by the Free Software Foundation.
+##
+## This program is distributed in the hope that it will be useful,
+## but WITHOUT ANY WARRANTY; without even the implied warranty of
+## MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+## GNU General Public License for more details.
+##
+## 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., 51 Franklin St, Fifth Floor, Boston, MA  02110-1301 USA
+##
+
+CONFIG_LZMA=y
+CONFIG_NRV2B=y
+CONFIG_BUILTIN_LAR=y
+
+PBUILDER_CONFIG=bayou.xml
+BUILTIN_LAR=builtin.lar
+
+LIBPAYLOAD_DIR := ../libpayload
+
+CC=gcc
+
+FFLAGS-y=
+FFLAGS-$(CONFIG_BUILTIN_LAR) += -DCONFIG_BUILTIN_LAR
+FFLAGS-$(CONFIG_LZMA) += -DCONFIG_LZMA
+FFLAGS-$(CONFIG_NRV2B) += -DCONFIG_NRV2B
+
+OBJECTS-y=main.o payload.o config.o menu.o self.o
+OBJECTS-$(CONFIG_LZMA) += lzma.o
+OBJECTS-$(CONFIG_NRV2B) += nrv2b.o
+OBJECTS-$(CONFIG_BUILTIN_LAR) += builtin-lar.o
+
+CFLAGS= -Wall -Werror -Os $(FFLAGS-y)
+LDFLAGS=-Wl,-T,bayou.ldscript -static
+LIBGCC=$(shell $(CC) -m32 -print-libgcc-file-name)
+
+LPCC=$(LIBPAYLOAD_DIR)/bin/lpgcc
+
+bayou.elf: $(OBJECTS-y)
+	$(LPCC) -ldscript bayou.ldscript -m32 -o $@ $(OBJECTS-y)
+	@ strip $@
+
+builtin-lar.o: $(BUILTIN_LAR)
+	@ objcopy -I binary -B i386 -O elf32-i386 $(BUILTIN_LAR) $@
+
+builtin.lar: util/pbuilder/pbuilder
+	@ rm -f $@
+	util/pbuilder/pbuilder -c $(PBUILDER_CONFIG) create $@
+
+util/pbuilder/pbuilder:
+	make -C util/pbuilder
+
+%.o: %.c
+	$(LPCC) $(CFLAGS) -c -o $@ $<	
+
+clean:
+	rm -f *.o bayou.elf builtin.lar

Added: trunk/payloads/bayou/bayou.h
===================================================================
--- trunk/payloads/bayou/bayou.h	                        (rev 0)
+++ trunk/payloads/bayou/bayou.h	2008-11-02 17:01:06 UTC (rev 3719)
@@ -0,0 +1,87 @@
+/*
+ * This file is part of the bayou project.
+ *
+ * Copyright (C) 2008 Advanced Micro Devices, Inc.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ *
+ * 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., 51 Franklin St, Fifth Floor, Boston, MA  02110-1301 USA
+ */
+
+#ifndef BAYOU_H_
+#define BAYOU_H_
+
+#include <libpayload.h>
+
+#define BAYOU_MAX_ENTRIES 10
+
+struct bpt_config {
+	u32 id;
+	u8 timeout;
+	u8 entries;
+	u8 padding[10];
+};
+
+struct bpt_pentry {
+	u8 index;
+	u8 parent;
+	u8 type;
+	u8 flags;
+	u8 title[64];
+	u8 nlen;
+};
+
+#define BPT_ID            0x30545042
+#define BPT_TYPE_CHOOSER  0x01
+#define BPT_TYPE_CHAIN    0x02
+#define BPT_TYPE_SUBCHAIN 0x03
+
+#define BPT_FLAG_DEFAULT  0x01
+#define BPT_FLAG_NOSHOW   0x02
+
+enum bayou_params {
+	BAYOU_PARAM_NAME = 0,
+	BAYOU_PARAM_LIST,
+	BAYOU_PARAM_DESC,
+	BAYOU_PARAMS_COUNT
+};
+
+struct payload {
+	struct bpt_pentry pentry;
+	struct larstat stat;
+	u8 *fptr;
+	char *params[BAYOU_PARAMS_COUNT];
+};
+
+struct bayoucfg {
+	u8 timeout;
+	int n_entries;
+	struct payload entries[BAYOU_MAX_ENTRIES];
+};
+
+extern struct bayoucfg bayoucfg;
+
+int verify_self(u8 *ptr);
+int self_get_params(u8 *fptr, u8 **params);
+int self_load_and_run(struct payload *p, int *ret);
+
+void menu(void);
+
+void run_payload(struct payload *p);
+char *payload_get_name(struct payload *p);
+struct payload *payload_get_default(void);
+void run_payload_timeout(struct payload *p, int timeout);
+void payload_parse_params(struct payload *pload, u8 *params, int len);
+
+int get_configuration(struct LAR *lar);
+
+#endif

Added: trunk/payloads/bayou/bayou.ldscript
===================================================================
--- trunk/payloads/bayou/bayou.ldscript	                        (rev 0)
+++ trunk/payloads/bayou/bayou.ldscript	2008-11-02 17:01:06 UTC (rev 3719)
@@ -0,0 +1,85 @@
+/*
+ * This file is part of the bayou project.
+ *
+ * Copyright (C) 2008 Advanced Micro Devices, Inc.
+ *
+ * Redistribution and use in source and binary forms, with or without
+ * modification, are permitted provided that the following conditions
+ * are met:
+ * 1. Redistributions of source code must retain the above copyright
+ *    notice, this list of conditions and the following disclaimer.
+ * 2. Redistributions in binary form must reproduce the above copyright
+ *    notice, this list of conditions and the following disclaimer in the
+ *    documentation and/or other materials provided with the distribution.
+ * 3. The name of the author may not be used to endorse or promote products
+ *    derived from this software without specific prior written permission.
+ *
+ * THIS SOFTWARE IS PROVIDED BY THE AUTHOR AND CONTRIBUTORS ``AS IS'' AND
+ * ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
+ * IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
+ * ARE DISCLAIMED.  IN NO EVENT SHALL THE AUTHOR OR CONTRIBUTORS BE LIABLE
+ * FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL
+ * DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS
+ * OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION)
+ * HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT
+ * LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY
+ * OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF
+ * SUCH DAMAGE.
+ */
+
+BASE_ADDRESS = 0x19000;
+
+OUTPUT_FORMAT(elf32-i386)
+OUTPUT_ARCH(i386)
+
+ENTRY(_entry)
+
+HEAP_SIZE = 16384;
+STACK_SIZE = 16384;
+
+SECTIONS
+{
+	. = BASE_ADDRESS;
+
+	. = ALIGN(16);
+	_start = .;
+
+	.text : {
+		*(.text._entry)
+		*(.text)
+		*(.text.*)
+	}
+
+	.rodata : {
+		*(.rodata)
+		*(.rodata.*)
+	}
+
+	.data : {
+		*(.data)
+		*(.data.*)
+	}
+
+	.bss : {
+		*(.bss)
+		*(.bss.*)
+		*(COMMON)
+
+		/* Stack and heap */
+
+		. = ALIGN(16);
+		_heap = .;
+		. += HEAP_SIZE;
+		. = ALIGN(16);
+		_eheap = .;
+
+		_estack = .;
+		. += STACK_SIZE;
+		. = ALIGN(16);
+		_stack = .;
+	}
+
+	_end = .;
+
+	/DISCARD/ : { *(.comment) *(.note) *(.note.*) }
+}

Added: trunk/payloads/bayou/config.c
===================================================================
--- trunk/payloads/bayou/config.c	                        (rev 0)
+++ trunk/payloads/bayou/config.c	2008-11-02 17:01:06 UTC (rev 3719)
@@ -0,0 +1,165 @@
+/*
+ * This file is part of the bayou project.
+ *
+ * Copyright (C) 2008 Advanced Micro Devices, Inc.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ *
+ * 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., 51 Franklin St, Fifth Floor, Boston, MA  02110-1301 USA
+ */
+
+#include "bayou.h"
+
+struct bayoucfg bayoucfg;
+
+static int add_payload(struct LAR *lar, struct larent *larent)
+{
+	struct payload *payload;
+	int plen;
+	u8 *params = NULL;
+	u8 *fptr;
+
+	if (bayoucfg.n_entries == BAYOU_MAX_ENTRIES)
+		return -1;
+
+	payload = &bayoucfg.entries[bayoucfg.n_entries];
+
+	if (strncmp((char *)larent->name, "payload/", 8))
+		return -1;
+
+	if (larstat(lar, (const char *)larent->name, &payload->stat))
+		return -1;
+
+	/* Make sure the LAR entry is valid. */
+	if (!lfverify(lar, (const char *)larent->name))
+		return -1;
+
+	/* Get a pointer to the start of the file. */
+	fptr = larfptr(lar, (const char *)larent->name);
+
+	if (fptr == NULL)
+		return -1;
+
+	if (!verify_self(fptr))
+		return -1;
+
+	payload->pentry.index = bayoucfg.n_entries;
+	payload->pentry.parent = 0;
+	payload->pentry.type = BPT_TYPE_CHOOSER;
+	payload->pentry.flags = 0;
+
+	plen = self_get_params(fptr, &params);
+	payload_parse_params(payload, params, plen);
+
+	payload->fptr = fptr;
+
+	bayoucfg.n_entries++;
+
+	return 0;
+}
+
+static int lar_walk_files(struct LAR *lar,
+			  int (*cb) (struct LAR *, struct larent *))
+{
+	struct larent *larent;
+	int ret = 0;
+
+	rewindlar(lar);
+
+	while ((larent = readlar(lar)) != NULL) {
+		if ((ret = cb(lar, larent)))
+			break;
+	}
+
+	return ret;
+}
+
+/**
+ * If reading the bayou_payload_table fails for some reason, then construct
+ * a dummy table. All valid payloads in the lar are added as chooser items.
+ */
+static void build_dummy_table(struct LAR *lar)
+{
+	bayoucfg.timeout = 0xFF;
+	bayoucfg.n_entries = 0;
+
+	lar_walk_files(lar, add_payload);
+}
+
+int get_configuration(struct LAR *lar)
+{
+	struct larstat stat;
+	struct bpt_config *bptcfg;
+	u8 *fptr, *ptr;
+	int i;
+
+	/*
+	 * If bayou_payload_table doesn't exist, then dummy up
+	 * a table from the LAR contents.
+	 */
+	if (larstat(lar, "bayou_payload_table", &stat) ||
+	    !lfverify(lar, "bayou_payload_table"))
+		build_dummy_table(lar);
+
+	/* Open up the BPT and get the creamy goodness within. */
+
+	fptr = larfptr(lar, "bayou_payload_table");
+
+	if (fptr == NULL)
+		build_dummy_table(lar);
+
+	bptcfg = (struct bpt_config *)fptr;
+	bayoucfg.timeout = bptcfg->timeout;
+
+	bayoucfg.n_entries = bptcfg->entries;
+
+	if (bayoucfg.n_entries > BAYOU_MAX_ENTRIES) {
+		printf("W:  Limiting the number of entries to %d\n",
+		       BAYOU_MAX_ENTRIES);
+		bayoucfg.n_entries = BAYOU_MAX_ENTRIES;
+	}
+
+	ptr = fptr + sizeof(struct bpt_config);
+
+	for (i = 0; i < bayoucfg.n_entries; i++) {
+		struct bpt_pentry *entry = (struct bpt_pentry *)ptr;
+		struct payload *p = &(bayoucfg.entries[i]);
+		int plen;
+		u8 *params = NULL;
+
+		memcpy(&p->pentry, entry, sizeof(struct bpt_pentry));
+
+		if (entry->type != BPT_TYPE_CHAIN) {
+			char *lname = (char *)ptr + sizeof(struct bpt_pentry);
+
+			if (larstat(lar, (const char *)lname, &p->stat))
+				build_dummy_table(lar);
+
+			if (!lfverify(lar, (const char *)lname))
+				build_dummy_table(lar);
+
+			fptr = larfptr(lar, (const char *)lname);
+
+			if (verify_self(fptr))
+				p->fptr = fptr;
+			else
+				build_dummy_table(lar);
+
+			plen = self_get_params(fptr, &params);
+			payload_parse_params(p, params, plen);
+		}
+
+		ptr += sizeof(struct bpt_pentry) + entry->nlen;
+	}
+
+	return 0;
+}

Added: trunk/payloads/bayou/lzma.c
===================================================================
--- trunk/payloads/bayou/lzma.c	                        (rev 0)
+++ trunk/payloads/bayou/lzma.c	2008-11-02 17:01:06 UTC (rev 3719)
@@ -0,0 +1,43 @@
+/*
+
+Coreboot interface to memory-saving variant of LZMA decoder
+
+(C)opyright 2006 Carl-Daniel Hailfinger
+Released under the GNU GPL v2 or later
+
+Parts of this file are based on C/7zip/Compress/LZMA_C/LzmaTest.c from the LZMA
+SDK 4.42, which is written and distributed to public domain by Igor Pavlov.
+
+*/
+
+#include <libpayload.h>
+#include "lzmadecode.c"
+
+unsigned long ulzma(u8 *src, u8 *dst)
+{
+	unsigned char properties[LZMA_PROPERTIES_SIZE];
+	UInt32 outSize;
+	SizeT inProcessed;
+	SizeT outProcessed;
+	int res;
+	CLzmaDecoderState state;
+	SizeT mallocneeds;
+	unsigned char scratchpad[15980];
+
+	memcpy(properties, src, LZMA_PROPERTIES_SIZE);
+	outSize = *(UInt32 *)(src + LZMA_PROPERTIES_SIZE);
+	if (LzmaDecodeProperties(&state.Properties, properties, LZMA_PROPERTIES_SIZE) != LZMA_RESULT_OK) {
+		printf("Incorrect stream properties\n");
+	}
+	mallocneeds = (LzmaGetNumProbs(&state.Properties) * sizeof(CProb));
+	if (mallocneeds > 15980) {
+		printf("Decoder scratchpad too small!\n");
+	}
+	state.Probs = (CProb *)scratchpad;
+	res = LzmaDecode(&state, src + LZMA_PROPERTIES_SIZE + 8, (SizeT)0xffffffff, &inProcessed,
+		dst, outSize, &outProcessed);
+	if (res != 0) {
+		printf("Decoding error = %d\n", res);
+	}
+	return outSize;
+}

Added: trunk/payloads/bayou/lzmadecode.c
===================================================================
--- trunk/payloads/bayou/lzmadecode.c	                        (rev 0)
+++ trunk/payloads/bayou/lzmadecode.c	2008-11-02 17:01:06 UTC (rev 3719)
@@ -0,0 +1,398 @@
+/*
+  LzmaDecode.c
+  LZMA Decoder (optimized for Speed version)
+  
+  LZMA SDK 4.40 Copyright (c) 1999-2006 Igor Pavlov (2006-05-01)
+  http://www.7-zip.org/
+
+  LZMA SDK is licensed under two licenses:
+  1) GNU Lesser General Public License (GNU LGPL)
+  2) Common Public License (CPL)
+  It means that you can select one of these two licenses and 
+  follow rules of that license.
+
+  SPECIAL EXCEPTION:
+  Igor Pavlov, as the author of this Code, expressly permits you to 
+  statically or dynamically link your Code (or bind by name) to the 
+  interfaces of this file without subjecting your linked Code to the 
+  terms of the CPL or GNU LGPL. Any modifications or additions 
+  to this file, however, are subject to the LGPL or CPL terms.
+*/
+
+#include "lzmadecode.h"
+
+#define kNumTopBits 24
+#define kTopValue ((UInt32)1 << kNumTopBits)
+
+#define kNumBitModelTotalBits 11
+#define kBitModelTotal (1 << kNumBitModelTotalBits)
+#define kNumMoveBits 5
+
+#define RC_READ_BYTE (*Buffer++)
+
+#define RC_INIT2 Code = 0; Range = 0xFFFFFFFF; \
+  { int i; for(i = 0; i < 5; i++) { RC_TEST; Code = (Code << 8) | RC_READ_BYTE; }}
+
+
+#define RC_TEST { if (Buffer == BufferLim) return LZMA_RESULT_DATA_ERROR; }
+
+#define RC_INIT(buffer, bufferSize) Buffer = buffer; BufferLim = buffer + bufferSize; RC_INIT2
+ 
+
+#define RC_NORMALIZE if (Range < kTopValue) { RC_TEST; Range <<= 8; Code = (Code << 8) | RC_READ_BYTE; }
+
+#define IfBit0(p) RC_NORMALIZE; bound = (Range >> kNumBitModelTotalBits) * *(p); if (Code < bound)
+#define UpdateBit0(p) Range = bound; *(p) += (kBitModelTotal - *(p)) >> kNumMoveBits;
+#define UpdateBit1(p) Range -= bound; Code -= bound; *(p) -= (*(p)) >> kNumMoveBits;
+
+#define RC_GET_BIT2(p, mi, A0, A1) IfBit0(p) \
+  { UpdateBit0(p); mi <<= 1; A0; } else \
+  { UpdateBit1(p); mi = (mi + mi) + 1; A1; } 
+  
+#define RC_GET_BIT(p, mi) RC_GET_BIT2(p, mi, ; , ;)               
+
+#define RangeDecoderBitTreeDecode(probs, numLevels, res) \
+  { int i = numLevels; res = 1; \
+  do { CProb *p = probs + res; RC_GET_BIT(p, res) } while(--i != 0); \
+  res -= (1 << numLevels); }
+
+
+#define kNumPosBitsMax 4
+#define kNumPosStatesMax (1 << kNumPosBitsMax)
+
+#define kLenNumLowBits 3
+#define kLenNumLowSymbols (1 << kLenNumLowBits)
+#define kLenNumMidBits 3
+#define kLenNumMidSymbols (1 << kLenNumMidBits)
+#define kLenNumHighBits 8
+#define kLenNumHighSymbols (1 << kLenNumHighBits)
+
+#define LenChoice 0
+#define LenChoice2 (LenChoice + 1)
+#define LenLow (LenChoice2 + 1)
+#define LenMid (LenLow + (kNumPosStatesMax << kLenNumLowBits))
+#define LenHigh (LenMid + (kNumPosStatesMax << kLenNumMidBits))
+#define kNumLenProbs (LenHigh + kLenNumHighSymbols) 
+
+
+#define kNumStates 12
+#define kNumLitStates 7
+
+#define kStartPosModelIndex 4
+#define kEndPosModelIndex 14
+#define kNumFullDistances (1 << (kEndPosModelIndex >> 1))
+
+#define kNumPosSlotBits 6
+#define kNumLenToPosStates 4
+
+#define kNumAlignBits 4
+#define kAlignTableSize (1 << kNumAlignBits)
+
+#define kMatchMinLen 2
+
+#define IsMatch 0
+#define IsRep (IsMatch + (kNumStates << kNumPosBitsMax))
+#define IsRepG0 (IsRep + kNumStates)
+#define IsRepG1 (IsRepG0 + kNumStates)
+#define IsRepG2 (IsRepG1 + kNumStates)
+#define IsRep0Long (IsRepG2 + kNumStates)
+#define PosSlot (IsRep0Long + (kNumStates << kNumPosBitsMax))
+#define SpecPos (PosSlot + (kNumLenToPosStates << kNumPosSlotBits))
+#define Align (SpecPos + kNumFullDistances - kEndPosModelIndex)
+#define LenCoder (Align + kAlignTableSize)
+#define RepLenCoder (LenCoder + kNumLenProbs)
+#define Literal (RepLenCoder + kNumLenProbs)
+
+#if Literal != LZMA_BASE_SIZE
+StopCompilingDueBUG
+#endif
+
+int LzmaDecodeProperties(CLzmaProperties *propsRes, const unsigned char *propsData, int size)
+{
+  unsigned char prop0;
+  if (size < LZMA_PROPERTIES_SIZE)
+    return LZMA_RESULT_DATA_ERROR;
+  prop0 = propsData[0];
+  if (prop0 >= (9 * 5 * 5))
+    return LZMA_RESULT_DATA_ERROR;
+  {
+    for (propsRes->pb = 0; prop0 >= (9 * 5); propsRes->pb++, prop0 -= (9 * 5));
+    for (propsRes->lp = 0; prop0 >= 9; propsRes->lp++, prop0 -= 9);
+    propsRes->lc = prop0;
+    /*
+    unsigned char remainder = (unsigned char)(prop0 / 9);
+    propsRes->lc = prop0 % 9;
+    propsRes->pb = remainder / 5;
+    propsRes->lp = remainder % 5;
+    */
+  }
+
+  return LZMA_RESULT_OK;
+}
+
+#define kLzmaStreamWasFinishedId (-1)
+
+int LzmaDecode(CLzmaDecoderState *vs,
+    const unsigned char *inStream, SizeT inSize, SizeT *inSizeProcessed,
+    unsigned char *outStream, SizeT outSize, SizeT *outSizeProcessed)
+{
+  CProb *p = vs->Probs;
+  SizeT nowPos = 0;
+  Byte previousByte = 0;
+  UInt32 posStateMask = (1 << (vs->Properties.pb)) - 1;
+  UInt32 literalPosMask = (1 << (vs->Properties.lp)) - 1;
+  int lc = vs->Properties.lc;
+
+
+  int state = 0;
+  UInt32 rep0 = 1, rep1 = 1, rep2 = 1, rep3 = 1;
+  int len = 0;
+  const Byte *Buffer;
+  const Byte *BufferLim;
+  UInt32 Range;
+  UInt32 Code;
+
+  *inSizeProcessed = 0;
+  *outSizeProcessed = 0;
+
+  {
+    UInt32 i;
+    UInt32 numProbs = Literal + ((UInt32)LZMA_LIT_SIZE << (lc + vs->Properties.lp));
+    for (i = 0; i < numProbs; i++)
+      p[i] = kBitModelTotal >> 1;
+  }
+  
+  RC_INIT(inStream, inSize);
+
+
+  while(nowPos < outSize)
+  {
+    CProb *prob;
+    UInt32 bound;
+    int posState = (int)(
+        (nowPos 
+        )
+        & posStateMask);
+
+    prob = p + IsMatch + (state << kNumPosBitsMax) + posState;
+    IfBit0(prob)
+    {
+      int symbol = 1;
+      UpdateBit0(prob)
+      prob = p + Literal + (LZMA_LIT_SIZE * 
+        (((
+        (nowPos 
+        )
+        & literalPosMask) << lc) + (previousByte >> (8 - lc))));
+
+      if (state >= kNumLitStates)
+      {
+        int matchByte;
+        matchByte = outStream[nowPos - rep0];
+        do
+        {
+          int bit;
+          CProb *probLit;
+          matchByte <<= 1;
+          bit = (matchByte & 0x100);
+          probLit = prob + 0x100 + bit + symbol;
+          RC_GET_BIT2(probLit, symbol, if (bit != 0) break, if (bit == 0) break)
+        }
+        while (symbol < 0x100);
+      }
+      while (symbol < 0x100)
+      {
+        CProb *probLit = prob + symbol;
+        RC_GET_BIT(probLit, symbol)
+      }
+      previousByte = (Byte)symbol;
+
+      outStream[nowPos++] = previousByte;
+      if (state < 4) state = 0;
+      else if (state < 10) state -= 3;
+      else state -= 6;
+    }
+    else             
+    {
+      UpdateBit1(prob);
+      prob = p + IsRep + state;
+      IfBit0(prob)
+      {
+        UpdateBit0(prob);
+        rep3 = rep2;
+        rep2 = rep1;
+        rep1 = rep0;
+        state = state < kNumLitStates ? 0 : 3;
+        prob = p + LenCoder;
+      }
+      else
+      {
+        UpdateBit1(prob);
+        prob = p + IsRepG0 + state;
+        IfBit0(prob)
+        {
+          UpdateBit0(prob);
+          prob = p + IsRep0Long + (state << kNumPosBitsMax) + posState;
+          IfBit0(prob)
+          {
+            UpdateBit0(prob);
+            
+            if (nowPos == 0)
+              return LZMA_RESULT_DATA_ERROR;
+            
+            state = state < kNumLitStates ? 9 : 11;
+            previousByte = outStream[nowPos - rep0];
+            outStream[nowPos++] = previousByte;
+
+            continue;
+          }
+          else
+          {
+            UpdateBit1(prob);
+          }
+        }
+        else
+        {
+          UInt32 distance;
+          UpdateBit1(prob);
+          prob = p + IsRepG1 + state;
+          IfBit0(prob)
+          {
+            UpdateBit0(prob);
+            distance = rep1;
+          }
+          else 
+          {
+            UpdateBit1(prob);
+            prob = p + IsRepG2 + state;
+            IfBit0(prob)
+            {
+              UpdateBit0(prob);
+              distance = rep2;
+            }
+            else
+            {
+              UpdateBit1(prob);
+              distance = rep3;
+              rep3 = rep2;
+            }
+            rep2 = rep1;
+          }
+          rep1 = rep0;
+          rep0 = distance;
+        }
+        state = state < kNumLitStates ? 8 : 11;
+        prob = p + RepLenCoder;
+      }
+      {
+        int numBits, offset;
+        CProb *probLen = prob + LenChoice;
+        IfBit0(probLen)
+        {
+          UpdateBit0(probLen);
+          probLen = prob + LenLow + (posState << kLenNumLowBits);
+          offset = 0;
+          numBits = kLenNumLowBits;
+        }
+        else
+        {
+          UpdateBit1(probLen);
+          probLen = prob + LenChoice2;
+          IfBit0(probLen)
+          {
+            UpdateBit0(probLen);
+            probLen = prob + LenMid + (posState << kLenNumMidBits);
+            offset = kLenNumLowSymbols;
+            numBits = kLenNumMidBits;
+          }
+          else
+          {
+            UpdateBit1(probLen);
+            probLen = prob + LenHigh;
+            offset = kLenNumLowSymbols + kLenNumMidSymbols;
+            numBits = kLenNumHighBits;
+          }
+        }
+        RangeDecoderBitTreeDecode(probLen, numBits, len);
+        len += offset;
+      }
+
+      if (state < 4)
+      {
+        int posSlot;
+        state += kNumLitStates;
+        prob = p + PosSlot +
+            ((len < kNumLenToPosStates ? len : kNumLenToPosStates - 1) << 
+            kNumPosSlotBits);
+        RangeDecoderBitTreeDecode(prob, kNumPosSlotBits, posSlot);
+        if (posSlot >= kStartPosModelIndex)
+        {
+          int numDirectBits = ((posSlot >> 1) - 1);
+          rep0 = (2 | ((UInt32)posSlot & 1));
+          if (posSlot < kEndPosModelIndex)
+          {
+            rep0 <<= numDirectBits;
+            prob = p + SpecPos + rep0 - posSlot - 1;
+          }
+          else
+          {
+            numDirectBits -= kNumAlignBits;
+            do
+            {
+              RC_NORMALIZE
+              Range >>= 1;
+              rep0 <<= 1;
+              if (Code >= Range)
+              {
+                Code -= Range;
+                rep0 |= 1;
+              }
+            }
+            while (--numDirectBits != 0);
+            prob = p + Align;
+            rep0 <<= kNumAlignBits;
+            numDirectBits = kNumAlignBits;
+          }
+          {
+            int i = 1;
+            int mi = 1;
+            do
+            {
+              CProb *prob3 = prob + mi;
+              RC_GET_BIT2(prob3, mi, ; , rep0 |= i);
+              i <<= 1;
+            }
+            while(--numDirectBits != 0);
+          }
+        }
+        else
+          rep0 = posSlot;
+        if (++rep0 == (UInt32)(0))
+        {
+          /* it's for stream version */
+          len = kLzmaStreamWasFinishedId;
+          break;
+        }
+      }
+
+      len += kMatchMinLen;
+      if (rep0 > nowPos)
+        return LZMA_RESULT_DATA_ERROR;
+
+
+      do
+      {
+        previousByte = outStream[nowPos - rep0];
+        len--;
+        outStream[nowPos++] = previousByte;
+      }
+      while(len != 0 && nowPos < outSize);
+    }
+  }
+  RC_NORMALIZE;
+
+
+  *inSizeProcessed = (SizeT)(Buffer - inStream);
+  *outSizeProcessed = nowPos;
+  return LZMA_RESULT_OK;
+}

Added: trunk/payloads/bayou/lzmadecode.h
===================================================================
--- trunk/payloads/bayou/lzmadecode.h	                        (rev 0)
+++ trunk/payloads/bayou/lzmadecode.h	2008-11-02 17:01:06 UTC (rev 3719)
@@ -0,0 +1,67 @@
+/* 
+  LzmaDecode.h
+  LZMA Decoder interface
+
+  LZMA SDK 4.40 Copyright (c) 1999-2006 Igor Pavlov (2006-05-01)
+  http://www.7-zip.org/
+
+  LZMA SDK is licensed under two licenses:
+  1) GNU Lesser General Public License (GNU LGPL)
+  2) Common Public License (CPL)
+  It means that you can select one of these two licenses and 
+  follow rules of that license.
+
+  SPECIAL EXCEPTION:
+  Igor Pavlov, as the author of this code, expressly permits you to 
+  statically or dynamically link your code (or bind by name) to the 
+  interfaces of this file without subjecting your linked code to the 
+  terms of the CPL or GNU LGPL. Any modifications or additions 
+  to this file, however, are subject to the LGPL or CPL terms.
+*/
+
+#ifndef LZMADECODE_H
+#define LZMADECODE_H
+
+typedef unsigned char Byte;
+typedef unsigned short UInt16;
+typedef unsigned int UInt32;
+typedef UInt32 SizeT;
+
+#define CProb UInt16
+
+#define LZMA_RESULT_OK 0
+#define LZMA_RESULT_DATA_ERROR 1
+
+
+#define LZMA_BASE_SIZE 1846
+#define LZMA_LIT_SIZE 768
+
+#define LZMA_PROPERTIES_SIZE 5
+
+typedef struct _CLzmaProperties
+{
+  int lc;
+  int lp;
+  int pb;
+}CLzmaProperties;
+
+int LzmaDecodeProperties(CLzmaProperties *propsRes, const unsigned char *propsData, int size);
+
+#define LzmaGetNumProbs(Properties) (LZMA_BASE_SIZE + (LZMA_LIT_SIZE << ((Properties)->lc + (Properties)->lp)))
+
+#define kLzmaNeedInitId (-2)
+
+typedef struct _CLzmaDecoderState
+{
+  CLzmaProperties Properties;
+  CProb *Probs;
+
+
+} CLzmaDecoderState;
+
+
+int LzmaDecode(CLzmaDecoderState *vs,
+    const unsigned char *inStream, SizeT inSize, SizeT *inSizeProcessed,
+    unsigned char *outStream, SizeT outSize, SizeT *outSizeProcessed);
+
+#endif /* LZMADECODE_H */

Added: trunk/payloads/bayou/main.c
===================================================================
--- trunk/payloads/bayou/main.c	                        (rev 0)
+++ trunk/payloads/bayou/main.c	2008-11-02 17:01:06 UTC (rev 3719)
@@ -0,0 +1,70 @@
+/*
+ * This file is part of the bayou project.
+ *
+ * Copyright (C) 2008 Advanced Micro Devices, Inc.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ *
+ * 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., 51 Franklin St, Fifth Floor, Boston, MA  02110-1301 USA
+ */
+
+#include "bayou.h"
+
+static void print_banner(void)
+{
+	printf("\e[H\e[JBayou Payload Chooser v0.3\n");
+}
+
+int main(void)
+{
+	extern unsigned long _binary_builtin_lar_start;
+	struct LAR *lar;
+
+	print_banner();
+
+	lar = openlar((void *)&_binary_builtin_lar_start);
+
+	if (lar == NULL) {
+		printf("[CHOOSER]: Unable to scan the attached LAR file\n");
+		return -1;
+	}
+
+	get_configuration(lar);
+
+	if (bayoucfg.n_entries == 0) {
+		printf("[CHOOSER]:  No payloads were found in the LAR\n");
+		return -1;
+	}
+
+	/*
+	 * If timeout == 0xFF, then show the menu immediately.
+	 * If timeout is zero, then find and run the default item immediately.
+	 * If there is no default item, then show the menu.
+	 * If timeout is anything else, then show a message and wait for a
+	 * keystroke. If there is no keystroke in time then run the default.
+	 * If there is no default then show the menu.
+	 */
+	if (bayoucfg.timeout != 0xFF) {
+		struct payload *d = payload_get_default();
+
+		if (d != NULL) {
+			if (bayoucfg.timeout == 0)
+				run_payload(d);
+			else
+				run_payload_timeout(d, bayoucfg.timeout);
+		}
+	}
+
+	menu();
+
+	return 0;
+}

Added: trunk/payloads/bayou/menu.c
===================================================================
--- trunk/payloads/bayou/menu.c	                        (rev 0)
+++ trunk/payloads/bayou/menu.c	2008-11-02 17:01:06 UTC (rev 3719)
@@ -0,0 +1,155 @@
+/*
+ * This file is part of the bayou project.
+ *
+ * Copyright (C) 2008 Advanced Micro Devices, Inc.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ *
+ * 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., 51 Franklin St, Fifth Floor, Boston, MA  02110-1301 USA
+ */
+
+#include <libpayload.h>
+#include <curses.h>
+#include "bayou.h"
+
+#define SCREEN_X 80
+#define SCREEN_Y 25
+
+static int menu_width = 0;
+static struct payload *mpayloads[BAYOU_MAX_ENTRIES];
+static int m_entries = 0;
+static unsigned int selected = 0;
+static WINDOW *menuwin, *status;
+
+void create_menu(void)
+{
+	int i;
+
+	for (i = 0; i < bayoucfg.n_entries; i++) {
+		struct payload *p = &(bayoucfg.entries[i]);
+		char *name;
+
+		if ((p->pentry.parent != 0) ||
+		    (p->pentry.flags & BPT_FLAG_NOSHOW))
+			continue;
+
+		mpayloads[m_entries++] = p;
+
+		name = payload_get_name(p);
+
+		if (strlen(name) > menu_width)
+			menu_width = strlen(name);
+	}
+
+	menu_width += 4;
+
+	if (menu_width < 30)
+		menu_width = 30;
+
+	menuwin = newwin(m_entries + 3, menu_width,
+			 (SCREEN_Y - (m_entries + 3)) / 2,
+			 (SCREEN_X - menu_width) / 2);
+}
+
+void draw_menu(void)
+{
+	struct payload *s;
+	int i;
+
+	wattrset(menuwin, COLOR_PAIR(3));
+	wclear(menuwin);
+	wborder(menuwin, '\263', '\263', '\304', '\304', '\332',
+		'\277', '\300', '\331');
+
+	wattrset(menuwin, COLOR_PAIR(4) | A_BOLD);
+	mvwprintw(menuwin, 0, (menu_width - 17) / 2, " Payload Chooser ");
+
+	wattrset(menuwin, COLOR_PAIR(3));
+
+	for (i = 0; i < m_entries; i++) {
+		char *name = payload_get_name(mpayloads[i]);
+		int col = (menu_width - (2 + strlen(name))) / 2;
+
+		if (i == selected)
+			wattrset(menuwin, COLOR_PAIR(5) | A_BOLD);
+		else
+			wattrset(menuwin, COLOR_PAIR(3));
+
+		mvwprintw(menuwin, 2 + i, col, name);
+	}
+
+	s = mpayloads[selected];
+
+	wclear(status);
+
+	if (s->params[BAYOU_PARAM_DESC] != NULL) {
+		char buf[66];
+		int len = strnlen(s->params[BAYOU_PARAM_DESC], 65);
+
+		snprintf(buf, 65, s->params[BAYOU_PARAM_DESC]);
+		buf[65] = 0;
+
+		mvwprintw(status, 0, (80 - len) / 2, buf);
+	}
+
+	wrefresh(menuwin);
+	wrefresh(status);
+}
+
+void loop(void)
+{
+	int key;
+
+	while (1) {
+		key = getch();
+
+		if (key == ERR)
+			continue;
+
+		if (key == KEY_DOWN)
+			selected = (selected + 1) % m_entries;
+		else if (key == KEY_UP)
+			selected = (selected - 1) % m_entries;
+		else if (key == KEY_ENTER) {
+			run_payload(mpayloads[selected]);
+			refresh();
+		} else
+			continue;
+
+		draw_menu();
+	}
+}
+
+void menu(void)
+{
+	initscr();
+
+	init_pair(1, COLOR_WHITE, COLOR_RED);
+	init_pair(2, COLOR_BLACK, COLOR_WHITE);
+	init_pair(3, COLOR_BLACK, COLOR_WHITE);
+	init_pair(4, COLOR_CYAN, COLOR_WHITE);
+	init_pair(5, COLOR_WHITE, COLOR_RED);
+
+	wattrset(stdscr, COLOR_PAIR(1));
+	wclear(stdscr);
+
+	status = newwin(1, 80, 24, 0);
+	wattrset(status, COLOR_PAIR(2));
+	wclear(status);
+
+	refresh();
+
+	create_menu();
+	draw_menu();
+
+	loop();
+}

Added: trunk/payloads/bayou/nrv2b.c
===================================================================
--- trunk/payloads/bayou/nrv2b.c	                        (rev 0)
+++ trunk/payloads/bayou/nrv2b.c	2008-11-02 17:01:06 UTC (rev 3719)
@@ -0,0 +1,87 @@
+#include <libpayload.h>
+
+// This GETBIT is supposed to work on little endian 
+// 32bit systems. The algorithm will definitely need
+// some fixing on other systems, but it might not be
+// a problem since the nrv2b binary behaves the same..
+
+#ifndef ENDIAN
+#define ENDIAN   0
+#endif
+#ifndef BITSIZE
+#define BITSIZE 32
+#endif
+
+#define GETBIT_8(bb, src, ilen) \
+    (((bb = bb & 0x7f ? bb*2 : ((unsigned)src[ilen++]*2+1)) >> 8) & 1)
+
+#define GETBIT_LE16(bb, src, ilen) \
+    (bb*=2,bb&0xffff ? (bb>>16)&1 : (ilen+=2,((bb=(src[ilen-2]+src[ilen-1]*256u)*2+1)>>16)&1))
+#define GETBIT_LE32(bb, src, ilen) \
+    (bc > 0 ? ((bb>>--bc)&1) : (bc=31,\
+    bb=*(const u32 *)((src)+ilen),ilen+=4,(bb>>31)&1))
+
+#if ENDIAN == 0 && BITSIZE == 8
+#define GETBIT(bb, src, ilen) GETBIT_8(bb, src, ilen)
+#endif
+#if ENDIAN == 0 && BITSIZE == 16
+#define GETBIT(bb, src, ilen) GETBIT_LE16(bb, src, ilen)
+#endif
+#if ENDIAN == 0 && BITSIZE == 32
+#define GETBIT(bb, src, ilen) GETBIT_LE32(bb, src, ilen)
+#endif
+
+unsigned long unrv2b(u8 *src, u8 *dst, unsigned long *ilen_p)
+{
+	unsigned long ilen = 0, olen = 0, last_m_off = 1;
+	u32 bb = 0;
+	unsigned bc = 0;
+	const u8 *m_pos;
+
+	// skip length
+	src += 4;
+	/* FIXME: check olen with the length stored in first 4 bytes */	
+
+	for (;;) {
+		unsigned int m_off, m_len;
+		while (GETBIT(bb, src, ilen)) {
+			dst[olen++] = src[ilen++];
+		}
+
+		m_off = 1;
+		do {
+			m_off = m_off * 2 + GETBIT(bb, src, ilen);
+		} while (!GETBIT(bb, src, ilen));
+		if (m_off == 2) {
+			m_off = last_m_off;
+		} else {
+			m_off = (m_off - 3) * 256 + src[ilen++];
+			if (m_off == 0xffffffffU)
+				break;
+			last_m_off = ++m_off;
+		}
+
+		m_len = GETBIT(bb, src, ilen);
+		m_len = m_len * 2 + GETBIT(bb, src, ilen);
+		if (m_len == 0) {
+			m_len++;
+			do {
+				m_len = m_len * 2 + GETBIT(bb, src, ilen);
+			} while (!GETBIT(bb, src, ilen));
+			m_len += 2;
+		}
+		m_len += (m_off > 0xd00);
+
+		m_pos = dst + olen - m_off;
+		dst[olen++] = *m_pos++;
+		do {
+			dst[olen++] = *m_pos++;
+		} while (--m_len > 0);
+	}
+
+	*ilen_p = ilen;
+
+	return olen;
+
+}
+

Added: trunk/payloads/bayou/payload.c
===================================================================
--- trunk/payloads/bayou/payload.c	                        (rev 0)
+++ trunk/payloads/bayou/payload.c	2008-11-02 17:01:06 UTC (rev 3719)
@@ -0,0 +1,111 @@
+/*
+ * This file is part of the bayou project.
+ *
+ * Copyright (C) 2008 Advanced Micro Devices, Inc.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ *
+ * 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., 51 Franklin St, Fifth Floor, Boston, MA  02110-1301 USA
+ */
+
+#include "bayou.h"
+
+#define TIMEOUT_MESSAGE "Press ESC for the menu (%2d)...\r"
+#define TIMEOUT_KEY     '\033'
+
+void run_payload(struct payload *p)
+{
+	int ret, i;
+
+	/* For chooser entries, just run the payload. */
+	if (p->pentry.type == BPT_TYPE_CHOOSER) {
+		self_load_and_run(p, &ret);
+		return;
+	}
+
+	/* For chained entries, run all the sub-chain items. */
+	for (i = 0; i < bayoucfg.n_entries; i++) {
+		struct payload *s = &(bayoucfg.entries[i]);
+
+		if (s->pentry.parent == p->pentry.index)
+			self_load_and_run(s, &ret);
+	}
+}
+
+char *payload_get_name(struct payload *p)
+{
+	if (p->pentry.type == BPT_TYPE_CHAIN)
+		return (char *)p->pentry.title;
+	else if (p->pentry.type == BPT_TYPE_CHOOSER) {
+		if (p->pentry.title[0] != 0)
+			return (char *)p->pentry.title;
+		return p->params[BAYOU_PARAM_DESC];
+	}
+
+	return NULL;
+}
+
+struct payload *payload_get_default(void)
+{
+	int i;
+
+	for (i = 0; i < bayoucfg.n_entries; i++) {
+		struct payload *s = &(bayoucfg.entries[i]);
+
+		if (s->pentry.parent == 0 && s->pentry.flags & BPT_FLAG_DEFAULT)
+			return s;
+	}
+
+	return NULL;
+}
+
+void run_payload_timeout(struct payload *p, int timeout)
+{
+	int t, ch, tval;
+
+	for (t = timeout; t >= 0; t--) {
+		printf(TIMEOUT_MESSAGE, t);
+
+		tval = 1000;
+		ch = getchar_timeout(&tval);
+
+		if (ch == TIMEOUT_KEY)
+			return;
+	}
+
+	run_payload(p);
+}
+
+void payload_parse_params(struct payload *pload, u8 *params, int len)
+{
+	char *ptr = (char *)params;
+	int i = 0;
+
+	if (ptr == NULL)
+		return;
+
+	while (ptr < ((char *)params + len)) {
+
+		if (!strncmp(ptr, "name=", 5)) {
+			pload->params[BAYOU_PARAM_NAME] = ptr + 5;
+		} else if (!strncmp(ptr, "desc=", 5)) {
+			pload->params[BAYOU_PARAM_DESC] = ptr + 5;
+		} else if (!strncmp(ptr, "listname=", 9)) {
+			pload->params[BAYOU_PARAM_LIST] = ptr + 9;
+		}
+
+		ptr += strnlen(ptr, len - i);
+
+		if (ptr < ((char *)params + len) && *ptr == 0)
+			ptr++;
+	}
+}

Added: trunk/payloads/bayou/self.c
===================================================================
--- trunk/payloads/bayou/self.c	                        (rev 0)
+++ trunk/payloads/bayou/self.c	2008-11-02 17:01:06 UTC (rev 3719)
@@ -0,0 +1,147 @@
+/*
+ * This file is part of the bayou project.
+ *
+ * Copyright (C) 2008 Advanced Micro Devices, Inc.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ *
+ * 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., 51 Franklin St, Fifth Floor, Boston, MA  02110-1301 USA
+ */
+
+#include "bayou.h"
+#include "self.h"
+
+static int nop_decompress(void *dst, void *src, int len)
+{
+	memcpy(dst, src, len);
+	return len;
+}
+
+#ifdef CONFIG_LZMA
+extern int ulzma(u8 *, u8 *);
+
+static int lzma_decompress(void *dst, void *src, int len)
+{
+	return ulzma((u8 *) src, (u8 *) dst);
+}
+#endif
+
+#ifdef CONFIG_NRV2B
+extern int unrv2b(u8 *, u8 *, unsigned long *);
+
+static int nrv2b_decompress(void *dst, void *src, int len)
+{
+	unsigned long l = (u32) len;
+	return unrv2b(src, dst, &l);
+}
+#endif
+
+static int zeros_decompress(void *dst, void *src, int len)
+{
+	memset(dst, 0, len);
+	return len;
+}
+
+int self_get_params(u8 *fptr, u8 **params)
+{
+	struct self_segment *seg = (struct self_segment *)fptr;
+
+	while (seg->type != SELF_TYPE_ENTRY) {
+		if (seg->type == 0)
+			return -1;
+
+		if (seg->type == SELF_TYPE_PARAMS) {
+			*params = (u8 *) (fptr + seg->offset);
+			return seg->len;
+		}
+
+		seg++;
+	}
+
+	*params = NULL;
+
+	return 0;
+}
+
+int verify_self(u8 *ptr)
+{
+	struct self_segment *seg = (struct self_segment *)ptr;
+
+	switch (seg->type) {
+	case SELF_TYPE_CODE:
+	case SELF_TYPE_DATA:
+	case SELF_TYPE_BSS:
+	case SELF_TYPE_PARAMS:
+	case SELF_TYPE_ENTRY:
+		return 1;
+	}
+
+	return 0;
+}
+
+int self_load_and_run(struct payload *p, int *ret)
+{
+	struct self_segment *seg = (struct self_segment *)p->fptr;
+	int (*dcmp) (void *, void *, int);
+	int dlen;
+
+	switch (p->stat.compression) {
+#ifdef CONFIG_LZMA
+	case ALGO_LZMA:
+		dcmp = lzma_decompress;
+		break;
+#endif
+#ifdef CONFIG_NRV2B
+	case ALGO_NRV2B:
+		dcmp = nrv2b_decompress;
+		break;
+#endif
+	case ALGO_ZEROES:
+		dcmp = zeros_decompress;
+		break;
+	case ALGO_NONE:
+		dcmp = nop_decompress;
+	default:
+		printf("E: Unsupported decompression type\n");
+		return -1;
+	}
+
+	while (1) {
+		u32 laddr = (u32) (seg->load_addr & 0xFFFFFFFF);
+
+		switch (seg->type) {
+		case SELF_TYPE_CODE:
+		case SELF_TYPE_DATA:
+			dlen = dcmp((void *)laddr,
+				    (void *)p->fptr + seg->offset, seg->len);
+
+			if (dlen < seg->mem_len) {
+				memset((void *)(laddr + dlen), 0,
+				       seg->mem_len - dlen);
+			}
+			break;
+
+		case SELF_TYPE_BSS:
+			memset((void *)laddr, 0, seg->len);
+			break;
+		case SELF_TYPE_ENTRY:
+			*ret = exec(laddr, 0, NULL);
+			return 0;
+		default:
+			break;
+		}
+
+		seg++;
+	}
+
+	return -1;
+}

Added: trunk/payloads/bayou/self.h
===================================================================
--- trunk/payloads/bayou/self.h	                        (rev 0)
+++ trunk/payloads/bayou/self.h	2008-11-02 17:01:06 UTC (rev 3719)
@@ -0,0 +1,44 @@
+/*
+ * This file is part of the bayou project.
+ *
+ * Copyright (C) 2008 Advanced Micro Devices, Inc.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ *
+ * 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., 51 Franklin St, Fifth Floor, Boston, MA  02110-1301 USA
+ */
+
+#ifndef SELF_H_
+#define SELF_H_
+
+#include <libpayload.h>
+
+struct self_segment {
+	u32 type;
+	u32 offset;
+	u64 load_addr;
+	u32 len;
+	u32 mem_len;
+};
+
+struct self {
+	struct larstat stat;
+	void *fptr;
+};
+
+#define SELF_TYPE_CODE   0x45444F43
+#define SELF_TYPE_DATA   0x41544144
+#define SELF_TYPE_BSS    0x20535342
+#define SELF_TYPE_PARAMS 0x41524150
+#define SELF_TYPE_ENTRY  0x52544E45
+
+#endif

Added: trunk/payloads/bayou/util/pbuilder/Makefile
===================================================================
--- trunk/payloads/bayou/util/pbuilder/Makefile	                        (rev 0)
+++ trunk/payloads/bayou/util/pbuilder/Makefile	2008-11-02 17:01:06 UTC (rev 3719)
@@ -0,0 +1,38 @@
+##
+## This file is part of the bayou project.
+##
+## Copyright (C) 2008 Advanced Micro Devices, Inc.
+##
+## This program is free software; you can redistribute it and/or modify
+## it under the terms of the GNU General Public License version 2 as
+## published by the Free Software Foundation.
+##
+## This program is distributed in the hope that it will be useful,
+## but WITHOUT ANY WARRANTY; without even the implied warranty of
+## MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+## GNU General Public License for more details.
+##
+## 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., 51 Franklin St, Fifth Floor, Boston, MA  02110-1301 USA
+##
+
+CC=gcc
+PBUILDOBJS := config.o create.o show.o main.o
+INCLUDES := -Iliblar/
+CFLAGS=-Wall -Werror -g
+
+pbuilder: $(PBUILDOBJS) $(LZMA_OBJ) liblar/liblar.a
+	$(CXX) -o $@ $(PBUILDOBJS) $(LZMA_OBJ) -L ./liblar -llar -lexpat
+
+liblar/liblar.a:
+	make -C liblar
+
+include lzma/Makefile
+
+%.o: %.c
+	$(CC) -c $(CFLAGS) $(INCLUDES) -o $@ $<
+
+clean:
+	rm -f pbuilder *.o
+	make -C liblar clean

Added: trunk/payloads/bayou/util/pbuilder/config.c
===================================================================
--- trunk/payloads/bayou/util/pbuilder/config.c	                        (rev 0)
+++ trunk/payloads/bayou/util/pbuilder/config.c	2008-11-02 17:01:06 UTC (rev 3719)
@@ -0,0 +1,265 @@
+/*
+ * This file is part of the bayou project.
+ *
+ * Copyright (C) 2008 Advanced Micro Devices, Inc.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ *
+ * 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., 51 Franklin St, Fifth Floor, Boston, MA  02110-1301 USA
+ */
+
+#define _GNU_SOURCE
+
+#include <stdlib.h>
+#include <string.h>
+#include <expat.h>
+#include <ctype.h>
+#include "pbuilder.h"
+
+#define STATE_NONE                   0x00
+#define STATE_BAYOUCONFIG            0x01
+#define STATE_GLOBAL                 0x02
+#define STATE_GLOBAL_TIMEOUT         0x03
+#define STATE_PAYLOADS               0x04
+#define STATE_PAYLOAD                0x05
+#define STATE_PAYLOAD_TITLE          0x06
+#define STATE_PAYLOAD_FILE           0x07
+#define STATE_PAYLOAD_LARNAME        0x08
+#define STATE_PAYLOAD_CHAIN          0x09
+#define STATE_PAYLOAD_CHAIN_FILE     0x0A
+#define STATE_PAYLOAD_CHAIN_LARNAME  0x0B
+
+static struct userdata {
+	struct config *config;
+	struct pentry *payload;
+	struct pentry *chain;
+	int state;
+} userdata;
+
+static char buffer[8192];
+
+static struct {
+	char *element;
+	int pstate;
+	int state;
+} states[] = {
+	{"BayouConfig", STATE_NONE, STATE_BAYOUCONFIG},
+	{"global", STATE_BAYOUCONFIG, STATE_GLOBAL},
+	{"timeout", STATE_GLOBAL, STATE_GLOBAL_TIMEOUT},
+	{"payloads", STATE_BAYOUCONFIG, STATE_PAYLOADS},
+	{"payload", STATE_PAYLOADS, STATE_PAYLOAD},
+	{"title", STATE_PAYLOAD, STATE_PAYLOAD_TITLE},
+	{"lar", STATE_PAYLOAD, STATE_PAYLOAD_LARNAME},
+	{"file", STATE_PAYLOAD, STATE_PAYLOAD_FILE},
+	{"chain", STATE_PAYLOAD, STATE_PAYLOAD_CHAIN},
+	{"file", STATE_PAYLOAD_CHAIN, STATE_PAYLOAD_CHAIN_FILE},
+	{"lar", STATE_PAYLOAD_CHAIN, STATE_PAYLOAD_CHAIN_LARNAME},
+	{NULL},
+};
+
+static struct pentry *newPayload(struct config *config)
+{
+	struct pentry **tmp, *ret;
+
+	tmp = realloc(config->entries,
+		      (config->n_entries + 1) * sizeof(struct pentry *));
+
+	if (tmp == NULL)
+		return NULL;
+
+	config->entries = tmp;
+
+	ret = config->entries[config->n_entries] = calloc(sizeof(*ret), 1);
+
+	if (ret == NULL)
+		return NULL;
+
+	/* Yes, I want this to be ++config->n_entries (the index is 1 based). */
+	ret->index = ++config->n_entries;
+
+	return ret;
+}
+
+static void parseFlags(struct pentry *entry, const char *flags)
+{
+	char *p = (char *)flags;
+	char *n;
+
+	while (*p) {
+		n = strchr(p, ',');
+
+		if (n)
+			*(n++) = 0;
+
+		if (!strcmp(p, "default"))
+			entry->flags |= BPT_FLAG_DEFAULT;
+		else if (!strcmp(p, "nolist"))
+			entry->flags |= BPT_FLAG_NOSHOW;
+		else
+			warn("W: Unknown payload flag %s\n", p);
+
+		if (!n)
+			break;
+
+		for (p = n; *p && isspace(*p); p++) ;
+	}
+}
+
+static struct pentry *addPayload(struct config *config, const char **attr)
+{
+	struct pentry *ret = newPayload(config);
+	int i = 0;
+
+	if (ret == NULL)
+		die("E: Could not allocate memory for a new payload\n");
+
+	while (attr[i] != NULL) {
+		if (!strcmp(attr[i], "type")) {
+			if (!strcmp(attr[i + 1], "chain"))
+				ret->type = BPT_TYPE_CHAIN;
+			else if (!strcmp(attr[i + 1], "chooser"))
+				ret->type = BPT_TYPE_CHOOSER;
+			else
+				die("E: Invalid payload type %s\n",
+				    attr[i + 1]);
+		} else if (!strcmp(attr[i], "flags"))
+			parseFlags(ret, attr[i + 1]);
+
+		i += 2;
+	}
+
+	return ret;
+}
+
+static struct pentry *addChain(struct config *config, struct pentry *parent)
+{
+	struct pentry *ret = newPayload(config);
+
+	if (ret == NULL)
+		die("E: Could not allocate memory for a new payload\n");
+
+	ret->parent = parent->index;
+	ret->type = BPT_TYPE_SUBCHAIN;
+
+	return ret;
+}
+
+static void start(void *data, const char *el, const char **attr)
+{
+	int i;
+	struct userdata *d = (struct userdata *)data;
+
+	for (i = 0; states[i].element != NULL; i++) {
+		if (d->state != states[i].pstate)
+			continue;
+
+		if (!strcmp(el, states[i].element)) {
+			d->state = states[i].state;
+			break;
+		}
+	}
+
+	if (states[i].element == NULL)
+		die("E: Unknown element %s\n", el);
+
+	if (d->state == STATE_PAYLOAD)
+		d->payload = addPayload(d->config, attr);
+
+	if (d->state == STATE_PAYLOAD_CHAIN)
+		d->chain = addChain(d->config, d->payload);
+}
+
+static void data(void *data, const char *val, int len)
+{
+	struct userdata *d = (struct userdata *)data;
+	int l;
+
+	switch (d->state) {
+	case STATE_GLOBAL_TIMEOUT:
+		d->config->timeout = atoi(val);
+		break;
+	case STATE_PAYLOAD_TITLE:
+		l = sizeof(d->payload->title) - 1 > len ?
+		    len : sizeof(d->payload->title) - 1;
+
+		strncpy((char *)d->payload->title, (char *)val, l);
+		d->payload->title[l] = '\0';
+		break;
+	case STATE_PAYLOAD_FILE:
+		d->payload->file = strndup(val, len);
+		break;
+	case STATE_PAYLOAD_LARNAME:
+		d->payload->larname = strndup(val, len);
+		break;
+	case STATE_PAYLOAD_CHAIN_FILE:
+		d->chain->file = strndup(val, len);
+		break;
+	case STATE_PAYLOAD_CHAIN_LARNAME:
+		d->chain->larname = strndup(val, len);
+		break;
+	default:
+		break;
+	}
+}
+
+static void end(void *data, const char *el)
+{
+	struct userdata *d = (struct userdata *)data;
+	int i;
+
+	if (d->state == STATE_PAYLOAD_CHAIN)
+		d->chain = NULL;
+
+	if (d->state == STATE_PAYLOAD)
+		d->payload = NULL;
+
+	for (i = 0; states[i].element != NULL; i++) {
+		if (d->state != states[i].state)
+			continue;
+
+		if (!strcmp(el, states[i].element)) {
+			d->state = states[i].pstate;
+			break;
+		}
+	}
+
+	if (states[i].element == NULL)
+		die("E:  Unable to find the reverse state for %s\n", el);
+}
+
+void parseconfig(FILE *stream, struct config *config)
+{
+	XML_Parser p = XML_ParserCreate(NULL);
+	int eof = 0;
+
+	if (p == NULL)
+		die("E: Could not create the parser\n");
+
+	XML_SetElementHandler(p, start, end);
+	XML_SetCharacterDataHandler(p, data);
+
+	userdata.config = config;
+
+	XML_SetUserData(p, &userdata);
+
+	while (!eof) {
+		int len = fread(buffer, 1, 8192, stream);
+
+		eof = feof(stream);
+
+		if (ferror(stream))
+			die("E: Error reading the stream\n");
+
+		if (!XML_Parse(p, buffer, len, eof))
+			die("E: Error parsing the XML data\n");
+	}
+}

Added: trunk/payloads/bayou/util/pbuilder/create.c
===================================================================
--- trunk/payloads/bayou/util/pbuilder/create.c	                        (rev 0)
+++ trunk/payloads/bayou/util/pbuilder/create.c	2008-11-02 17:01:06 UTC (rev 3719)
@@ -0,0 +1,200 @@
+/*
+ * This file is part of the bayou project.
+ *
+ * Copyright (C) 2008 Advanced Micro Devices, Inc.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ *
+ * 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., 51 Franklin St, Fifth Floor, Boston, MA  02110-1301 USA
+ */
+
+#include <stdlib.h>
+#include <string.h>
+#include <unistd.h>
+#include <fcntl.h>
+#include <libgen.h>
+#include "liblar.h"
+#include "pbuilder.h"
+
+void do_lzma_compress(char *in, int in_len, char *out, int *out_len);
+
+int add_bpt_to_lar(struct LAR *lar, struct config *config)
+{
+	char *buffer;
+	int ret, i, len = sizeof(struct bpt_config);
+	struct bpt_config *cfg;
+	struct LARAttr attr;
+	char *ptr;
+
+	for (i = 0; i < config->n_entries; i++) {
+		len += sizeof(struct bpt_pentry);
+
+		if (config->entries[i]->type != BPT_TYPE_CHAIN)
+			len += ((strlen(config->entries[i]->larname)
+				+ 15) & ~0x0F);
+	}
+
+	buffer = calloc(len, 1);
+
+	if (buffer == NULL)
+		return -1;
+
+	cfg = (struct bpt_config *)buffer;
+
+	cfg->id = BPT_ID;
+	cfg->timeout = config->timeout;
+	cfg->entries = config->n_entries;
+
+	ptr = buffer + sizeof(struct bpt_config);
+
+	for (i = 0; i < config->n_entries; i++) {
+		int nlen = 0;
+		struct bpt_pentry *pentry = (struct bpt_pentry *)ptr;
+
+		pentry->index = config->entries[i]->index;
+		pentry->parent = config->entries[i]->parent;
+		pentry->type = config->entries[i]->type;
+		pentry->flags = config->entries[i]->flags;
+
+		strncpy((char *)pentry->title,
+			(char *)config->entries[i]->title,
+			sizeof(pentry->title));
+
+		if (config->entries[i]->type != BPT_TYPE_CHAIN) {
+			nlen = strlen(config->entries[i]->larname);
+			nlen = (nlen + 15) & ~0x0F;
+
+			strcpy((char *)(ptr + sizeof(struct bpt_pentry)),
+			       config->entries[i]->larname);
+
+			pentry->nlen = nlen;
+		}
+
+		ptr += sizeof(struct bpt_pentry);
+
+		if (config->entries[i]->type != BPT_TYPE_CHAIN)
+			ptr += nlen;
+	}
+
+	LAR_SetAttrs(&attr, "bayou_payload_table", ALGO_NONE);
+
+	ret = LAR_AppendBuffer(lar, (unsigned char *)buffer, len, &attr);
+	free(buffer);
+	return ret;
+}
+
+struct lfile {
+	char *file;
+	char *larname;
+};
+
+int n_lfiles;
+
+int create_lar_from_config(const char *input, const char *output)
+{
+	struct config config;
+	FILE *stream;
+	struct LAR *lar;
+	struct LARAttr attr;
+	int i, j, ret = -1;
+	struct lfile *lfiles;
+
+	stream = fopen(input, "r");
+
+	if (stream == NULL) {
+		warn("E:  Couldn't open %s for reading\n", input);
+		return -1;
+	}
+
+	memset(&config, 0, sizeof(config));
+
+	parseconfig(stream, &config);
+	fclose(stream);
+
+	lar = LAR_Create(output);
+
+	if (lar == NULL) {
+		warn("E:  Couldn't create a new lar file\n");
+		return -1;
+	}
+
+	LAR_SetCompressionFuncs(lar, ALGO_LZMA, do_lzma_compress, NULL);
+
+	lfiles = calloc(sizeof(struct lfile), config.n_entries);
+
+	if (lfiles == NULL) {
+		warn("E: Couldn't allocate memory: %m\n");
+		return -1;
+	}
+
+	for (i = 0; i < config.n_entries; i++) {
+		/* Master chain entries don't have files associated with them. */
+		if (config.entries[i]->type == BPT_TYPE_CHAIN)
+			continue;
+
+		if (access(config.entries[i]->file, R_OK)) {
+			warn("E:  Could not find file %s\n",
+			     config.entries[i]->file);
+
+			goto err;
+		}
+
+		if (config.entries[i]->larname == NULL) {
+			config.entries[i]->larname =
+			    strdup(basename(config.entries[i]->file));
+
+			if (config.entries[i]->larname == NULL) {
+				warn("E: Could not allocate memory for the default name\n");
+				goto err;
+			}
+		}
+
+		/*
+		 * Add the file to the list of files to add to the LAR - skip
+		 * any duplicates, but be on the lookout for the same LAR name
+		 * attached to a different file.
+		 */
+		for (j = 0; j < n_lfiles; j++) {
+			if (!strcmp(lfiles[j].larname,
+				    config.entries[i]->larname)) {
+				if (strcmp(lfiles[j].file,
+					   config.entries[i]->file)) {
+					warn("E:  LAR name '%s' has already been used\n", config.entries[i]->larname);
+					goto err;
+				}
+				break;
+			}
+		}
+
+		if (j == n_lfiles) {
+			lfiles[n_lfiles].file = config.entries[i]->file;
+			lfiles[n_lfiles++].larname = config.entries[i]->larname;
+		}
+	}
+
+	/* Add all the files to the LAR. */
+	for (i = 0; i < n_lfiles; i++) {
+		LAR_SetAttrs(&attr, lfiles[i].larname, ALGO_LZMA);
+
+		if (LAR_AppendFile(lar, lfiles[i].file, &attr)) {
+			warn("E: Could not add %s to the LAR\n",
+			     lfiles[i].file);
+			goto err;
+		}
+	}
+
+	ret = add_bpt_to_lar(lar, &config);
+
+err:
+	LAR_Close(lar);
+	return ret;
+}

Added: trunk/payloads/bayou/util/pbuilder/liblar/Makefile
===================================================================
--- trunk/payloads/bayou/util/pbuilder/liblar/Makefile	                        (rev 0)
+++ trunk/payloads/bayou/util/pbuilder/liblar/Makefile	2008-11-02 17:01:06 UTC (rev 3719)
@@ -0,0 +1,31 @@
+##
+## This file is part of the bayou project.
+##
+## Copyright (C) 2008 Advanced Micro Devices, Inc.
+##
+## This program is free software; you can redistribute it and/or modify
+## it under the terms of the GNU General Public License version 2 as
+## published by the Free Software Foundation.
+##
+## This program is distributed in the hope that it will be useful,
+## but WITHOUT ANY WARRANTY; without even the implied warranty of
+## MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+## GNU General Public License for more details.
+##
+## 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., 51 Franklin St, Fifth Floor, Boston, MA  02110-1301 USA
+##
+
+CC = gcc
+LAROBJS = self.o lib.o
+CFLAGS = -g -Wall
+
+liblar.a: $(LAROBJS)
+	ar rc $@ $(LAROBJS)
+
+%.o: %.c
+	$(CC) -c $(CFLAGS) -o $@ $<
+
+clean:
+	rm -f liblar.a *.o

Added: trunk/payloads/bayou/util/pbuilder/liblar/lar.h
===================================================================
--- trunk/payloads/bayou/util/pbuilder/liblar/lar.h	                        (rev 0)
+++ trunk/payloads/bayou/util/pbuilder/liblar/lar.h	2008-11-02 17:01:06 UTC (rev 3719)
@@ -0,0 +1,95 @@
+/*
+ * lar - lightweight archiver
+ *
+ * Copyright (C) 2006 coresystems GmbH
+ * (Written by Stefan Reinauer <stepan at coresystems.de> for coresystems GmbH)
+ * Copyright (C) 2007 Patrick Georgi <patrick at georgi-clan.de>
+ *
+ * This file is dual-licensed. You can choose between:
+ *   - The GNU GPL, version 2, as published by the Free Software Foundation
+ *   - The revised BSD license (without advertising clause)
+ *
+ * ---------------------------------------------------------------------------
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; version 2 of the License.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ *
+ * 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., 51 Franklin St, Fifth Floor, Boston, MA, 02110-1301 USA
+ * ---------------------------------------------------------------------------
+ * Redistribution and use in source and binary forms, with or without
+ * modification, are permitted provided that the following conditions
+ * are met:
+ * 1. Redistributions of source code must retain the above copyright
+ *    notice, this list of conditions and the following disclaimer.
+ * 2. Redistributions in binary form must reproduce the above copyright
+ *    notice, this list of conditions and the following disclaimer in the
+ *    documentation and/or other materials provided with the distribution.
+ * 3. The name of the author may not be used to endorse or promote products
+ *    derived from this software without specific prior written permission.
+ *
+ * THIS SOFTWARE IS PROVIDED BY THE AUTHOR AND CONTRIBUTORS ``AS IS'' AND
+ * ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
+ * IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
+ * ARE DISCLAIMED.  IN NO EVENT SHALL THE AUTHOR OR CONTRIBUTORS BE LIABLE
+ * FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL
+ * DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS
+ * OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION)
+ * HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT
+ * LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY
+ * OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF
+ * SUCH DAMAGE.
+ * ---------------------------------------------------------------------------
+ */
+
+#include <stdio.h>
+#include <stdint.h>
+
+#define MAGIC "LARCHIVE"
+#define MAX_PATHLEN 1024
+#define BOOTBLOCK_SIZE 20480
+
+#define BOOTBLOCK_NAME "bootblock"
+#define BOOTBLOCK_NAME_LEN 16
+
+typedef uint64_t u64;
+typedef int64_t s64;
+typedef uint32_t u32;
+typedef int32_t s32;
+typedef uint8_t u8;
+
+/* NOTE -- This and the coreboot lar.h may NOT be in sync. Be careful. */
+struct lar_header {
+	char magic[8];
+	u32 len;
+	u32 reallen;
+	u32 checksum;
+	u32 compchecksum;
+	/* Filenames are limited to 2^31-1-sizeof(lar_header)-1 bytes.
+	 * "Nobody will ever need more than 640k" */
+	u32 offset;
+	/* Compression:
+	 * 0 = no compression
+	 * 1 = lzma
+	 * 2 = nrv2b
+	 * 3 = zeroes
+	 */
+	u32 compression;
+	u64 entry;
+	u64 loadaddress;
+};
+
+enum compalgo {
+	ALGO_NONE = 0,
+	ALGO_LZMA = 1,
+	ALGO_NRV2B = 2,
+	ALGO_ZEROES = 3,
+	/* invalid should always be the last entry. */
+	ALGO_INVALID
+};

Added: trunk/payloads/bayou/util/pbuilder/liblar/lib.c
===================================================================
--- trunk/payloads/bayou/util/pbuilder/liblar/lib.c	                        (rev 0)
+++ trunk/payloads/bayou/util/pbuilder/liblar/lib.c	2008-11-02 17:01:06 UTC (rev 3719)
@@ -0,0 +1,461 @@
+/*
+ * This file is part of the bayou project.
+ *
+ * Copyright (C) 2008 Advanced Micro Devices, Inc.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ *
+ * 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., 51 Franklin St, Fifth Floor, Boston, MA  02110-1301 USA
+ */
+
+#include <stdio.h>
+#include <stdlib.h>
+#include <string.h>
+#include <fcntl.h>
+#include <unistd.h>
+#include <sys/stat.h>
+#include <sys/mman.h>
+#include <arpa/inet.h>
+
+#include "liblar.h"
+#include "self.h"
+
+static int lar_compress(struct LAR *lar, int algo, char *src, char *dst,
+			int len)
+{
+	int ret;
+
+	if (!lar->cfuncs[algo])
+		return -1;
+
+	lar->cfuncs[algo] (src, len, dst, &ret);
+	return ret;
+}
+
+static int lar_decompress(struct LAR *lar, int algo, char *src, char *dst,
+			  int slen, int dlen)
+{
+	if (!lar->dfuncs[algo])
+		return -1;
+
+	lar->dfuncs[algo] (src, slen, dst, dlen);
+	return dlen;
+}
+
+static struct LARHeader *lar_get_header(struct LAR *lar, const char *filename)
+{
+	char *buffer;
+	int offset = 0;
+	struct LARHeader *lheader = NULL;
+	struct lar_header *header;
+
+	printf("Getting %s\n", filename);
+
+	buffer = malloc(sizeof(struct lar_header) + MAX_PATHLEN);
+
+	if (buffer == NULL)
+		return NULL;
+
+	while (1) {
+		int ret;
+
+		if (lseek(lar->fd, offset, SEEK_SET) == -1)
+			goto err;
+
+		ret = read(lar->fd, buffer, sizeof(struct lar_header));
+
+		if (ret <= 0)
+			goto err;
+
+		header = (struct lar_header *)buffer;
+
+		if (strncmp(header->magic, MAGIC, sizeof(MAGIC)))
+			goto err;
+
+		ret = read(lar->fd, buffer + sizeof(struct lar_header),
+			   ntohl(header->offset) - sizeof(struct lar_header));
+
+		if (ret <= 0)
+			goto err;
+
+		if (!strcmp(buffer + sizeof(struct lar_header), filename))
+			break;
+
+		offset += ntohl(header->offset) +
+		    ((ntohl(header->len) + 15) & ~0xF);
+	}
+
+	lheader = calloc(sizeof(struct LARHeader), 1);
+
+	if (lheader == NULL)
+		goto err;
+
+	lheader->hoffset = offset;
+	lheader->offset = offset + ntohl(header->offset);
+
+	lheader->reallen = ntohl(header->reallen);
+	lheader->len = ntohl(header->len);
+
+	lheader->loadaddress = ntohl(header->loadaddress);
+	lheader->compression = ntohl(header->compression);
+	lheader->entry = ntohl(header->entry);
+	lheader->checksum = ntohl(header->checksum);
+
+err:
+	free(buffer);
+	return lheader;
+}
+
+static int LAR_AppendBlob(struct LAR *lar, unsigned char *buffer,
+			  int len, int rlen, struct LARAttr *attr)
+{
+	int nlen, nsize, lsize, i;
+	struct lar_header *header;
+	u8 *lptr;
+	u32 csum = 0;
+
+	if (attr == NULL)
+		return -1;
+
+	nlen = strlen(attr->name) + 1;
+
+	if (nlen > MAX_PATHLEN - 1)
+		nlen = MAX_PATHLEN - 1;
+
+	nsize = (nlen + 15) & ~0xF;
+
+	lsize = sizeof(struct lar_header) + nsize + len;
+	lptr = calloc(lsize + 1, 1);
+
+	if (lptr == NULL)
+		return -1;
+
+	header = (struct lar_header *)lptr;
+
+	memcpy(header->magic, MAGIC, 8);
+	header->reallen = htonl(rlen);
+	header->len = htonl(len);
+	header->offset = htonl(lsize - len);
+	header->loadaddress = htonl(attr->loadaddr);
+	header->compression = htonl(attr->compression);
+	header->entry = htonl(attr->entry);
+
+	strncpy(((char *)header) + sizeof(struct lar_header), attr->name, nlen);
+
+	for (i = 0; i < sizeof(struct lar_header) + nsize; i += 4)
+		csum += *((u32 *) (lptr + i));
+
+	for (i = 0; i < len; i += 4) {
+		/*
+		 * The checksum needs to include the 16 byte padding at
+		 * the end of the data before the next lar header. The
+		 * problem is that the padding isn't going to be in the
+		 * buffer, and if we try to read off the end of the buffer,
+		 * we are just asking for trouble. So account for the
+		 * situation where the datalen is not a multiple of four
+		 * and get a safe value to add into the checksum.
+		 * The rest of the padding will be zero, and can be safely
+		 * ignored here.
+		 */
+		if ((len - i) < 4) {
+			u32 val = 0;
+			int t;
+
+			for (t = 0; t < (len - i); t++)
+				val |= *((u8 *) buffer + (i + t)) << (t * 8);
+			csum += val;
+		} else
+			csum += *((u32 *) (buffer + i));
+	}
+
+	header->checksum = (u32) (~0 - csum);
+
+	lseek(lar->fd, 0, SEEK_END);
+
+	/* FIXME: Error check here. */
+
+	write(lar->fd, header, sizeof(struct lar_header) + nsize);
+	write(lar->fd, buffer, len);
+
+	/* Add in padding to the next 16 byte boundary. */
+	if (lsize & 0xF) {
+		int i;
+		char null = '\0';
+
+		for (i = lsize & 0xF; i < 0x10; i++)
+			write(lar->fd, &null, 1);
+	}
+
+	return 0;
+}
+
+int LAR_AppendBuffer(struct LAR *lar, unsigned char *buffer, int len,
+		     struct LARAttr *attr)
+{
+	unsigned char *tbuf;
+	int rlen, ret = -1;
+
+	if (attr->compression == ALGO_NONE)
+		return LAR_AppendBlob(lar, buffer, len, len, attr);
+
+	tbuf = malloc(len);
+
+	if (tbuf == NULL)
+		return -1;
+
+	rlen = lar_compress(lar, attr->compression, (char *)buffer,
+			    (char *)tbuf, len);
+
+	if (rlen > 0)
+		ret = LAR_AppendBlob(lar, tbuf, rlen, len, attr);
+
+	free(tbuf);
+	return ret;
+}
+
+int LAR_AppendSelf(struct LAR *lar, const char *filename, struct LARAttr *attr)
+{
+	unsigned char *buffer;
+	int len = elf_to_self(filename, &buffer,
+			      lar->cfuncs[attr->compression]);
+	int ret;
+
+	if (len == -1)
+		return -1;
+
+	ret = LAR_AppendBlob(lar, buffer, len, len, attr);
+	free(buffer);
+
+	return ret;
+}
+
+int LAR_AppendFile(struct LAR *lar, const char *filename, struct LARAttr *attr)
+{
+	int fd;
+	struct stat s;
+	char *filep;
+	int ret;
+
+	if (iself((char *)filename))
+		return LAR_AppendSelf(lar, filename, attr);
+
+	fd = open(filename, O_RDONLY);
+
+	if (fd == -1)
+		return -1;
+
+	if (fstat(fd, &s))
+		return -1;
+
+	filep = (char *)mmap(0, s.st_size, PROT_READ, MAP_SHARED, fd, 0);
+
+	if (filep == MAP_FAILED)
+		return -1;
+
+	ret = LAR_AppendBuffer(lar, (unsigned char *)filep, s.st_size, attr);
+
+	munmap(filep, s.st_size);
+	return ret;
+}
+
+int LAR_DeleteFile(struct LAR *lar, const char *filename)
+{
+	struct LARHeader *header = lar_get_header(lar, filename);
+	int len, ret = -1;
+	char *filep, *buffer;
+
+	if (header == NULL)
+		return -1;
+
+	buffer = malloc(4096);
+	if (buffer == NULL)
+		return -1;
+
+	len = header->offset + header->len;
+
+	/* First, map the space and zero it out. */
+
+	filep = (char *)mmap(0, len, PROT_READ, MAP_SHARED, lar->fd,
+			     header->hoffset);
+
+	if (filep == MAP_FAILED)
+		return -1;
+
+	memset(filep, 0, len);
+	munmap(filep, len);
+
+	/* Now move the rest of the LAR into place. */
+	/* FIXME: This does not account for the bootblock! */
+
+	int dst = header->hoffset;
+	int src = header->hoffset + len;
+
+	while (1) {
+		int l, w;
+
+		if (lseek(lar->fd, src, SEEK_SET))
+			goto err;
+
+		l = read(lar->fd, buffer, 8192);
+
+		if (l == -1)
+			goto err;
+		if (l == 0)
+			goto err;
+		if (lseek(lar->fd, dst, SEEK_SET))
+			goto err;
+
+		w = write(lar->fd, buffer, l);
+
+		if (w <= 0)
+			goto err;
+
+		dst += w;
+		src += w;
+	}
+
+	ret = 0;
+
+err:
+	free(buffer);
+	return ret;
+}
+
+void LAR_CloseFile(struct LARFile *file)
+{
+	if (file != NULL) {
+		if (file->buffer != NULL)
+			free(file->buffer);
+		free(file);
+	}
+}
+
+struct LARFile *LAR_MapFile(struct LAR *lar, const char *filename)
+{
+	struct LARFile *file;
+	struct LARHeader *header = lar_get_header(lar, filename);
+	char *filep;
+	int ret;
+
+	if (header == NULL)
+		return NULL;
+
+	file = calloc(sizeof(struct LARFile), 1);
+
+	if (file == NULL)
+		return NULL;
+
+	file->len = header->reallen;
+	file->buffer = calloc(header->reallen, 1);
+
+	if (file->buffer == NULL)
+		goto err;
+
+	/*
+	 * The offset needs to be a multiple of PAGE_SIZE, so just mmap
+	 * from offset 0, its easier then doing the math.
+	 */
+
+	filep = mmap(0, header->offset + header->len,
+		     PROT_READ, MAP_SHARED, lar->fd, 0);
+
+	if (filep == MAP_FAILED) {
+		printf("Map failed: %m\n");
+		goto err;
+	}
+
+	if (header->compression != ALGO_NONE) {
+		ret = lar_decompress(lar, header->compression,
+				     filep + header->offset, file->buffer,
+				     header->len, header->reallen);
+	} else {
+		memcpy(file->buffer, filep + header->offset, header->len);
+		ret = header->len;
+	}
+
+	munmap(filep, header->offset + header->len);
+
+	if (ret == header->reallen)
+		return file;
+
+err:
+	if (file->buffer)
+		free(file->buffer);
+
+	free(file);
+	return NULL;
+}
+
+int LAR_SetCompressionFuncs(struct LAR *lar, int algo,
+			    LAR_CompFunc cfunc, LAR_DecompFunc dfunc)
+{
+
+	if (algo >= ALGO_INVALID)
+		return -1;
+
+	lar->cfuncs[algo] = cfunc;
+	lar->dfuncs[algo] = dfunc;
+
+	return 0;
+}
+
+void LAR_Close(struct LAR *lar)
+{
+	if (lar != NULL) {
+		if (lar->fd)
+			close(lar->fd);
+
+		free(lar);
+	}
+}
+
+struct LAR *LAR_Open(const char *filename)
+{
+	struct LAR *lar = calloc(sizeof(struct LAR), 1);
+
+	if (lar == NULL)
+		return NULL;
+
+	lar->fd = open(filename, O_RDWR);
+
+	if (lar->fd > 0)
+		return lar;
+
+	free(lar);
+	return NULL;
+}
+
+struct LAR *LAR_Create(const char *filename)
+{
+	struct LAR *lar = calloc(sizeof(struct LAR), 1);
+
+	if (lar == NULL)
+		return NULL;
+
+	lar->fd = open(filename, O_RDWR | O_CREAT | O_TRUNC, S_IRUSR | S_IWUSR);
+
+	if (lar->fd > 0)
+		return lar;
+
+	free(lar);
+	return NULL;
+}
+
+void LAR_SetAttrs(struct LARAttr *attrs, char *name, int algo)
+{
+	if (attrs == NULL)
+		return;
+
+	memset(attrs, 0, sizeof(*attrs));
+	snprintf(attrs->name, sizeof(attrs->name) - 1, name);
+	attrs->compression = algo;
+}

Added: trunk/payloads/bayou/util/pbuilder/liblar/liblar.h
===================================================================
--- trunk/payloads/bayou/util/pbuilder/liblar/liblar.h	                        (rev 0)
+++ trunk/payloads/bayou/util/pbuilder/liblar/liblar.h	2008-11-02 17:01:06 UTC (rev 3719)
@@ -0,0 +1,75 @@
+/*
+ * This file is part of the bayou project.
+ *
+ * Copyright (C) 2008 Advanced Micro Devices, Inc.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ *
+ * 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., 51 Franklin St, Fifth Floor, Boston, MA  02110-1301 USA
+ */
+
+#ifndef _LIBLAR_H_
+#define _LIBLAR_H_
+
+#include <stdio.h>
+#include <stdlib.h>
+#include <string.h>
+#include "lar.h"
+
+typedef void (*LAR_CompFunc) (char *, int, char *, int *);
+typedef void (*LAR_DecompFunc) (char *, int, char *, int);
+
+struct LAR {
+	int fd;
+	LAR_CompFunc cfuncs[ALGO_INVALID];
+	LAR_DecompFunc dfuncs[ALGO_INVALID];
+};
+
+struct LARHeader {
+	u32 len;
+	u32 reallen;
+	u32 checksum;
+	u32 compression;
+	u64 loadaddress;
+	u64 entry;
+	/* These are the offsets within the file. */
+	unsigned int offset;
+	unsigned int hoffset;
+};
+
+struct LARAttr {
+	char name[MAX_PATHLEN];
+	u64 loadaddr;
+	int compression;
+	u64 entry;
+};
+
+struct LARFile {
+	int len;
+	char *buffer;
+};
+
+int LAR_AppendBuffer(struct LAR *lar, unsigned char *buffer, int len,
+		     struct LARAttr *attr);
+int LAR_AppendSelf(struct LAR *lar, const char *filename, struct LARAttr *attr);
+int LAR_AppendFile(struct LAR *lar, const char *filename, struct LARAttr *attr);
+int LAR_DeleteFile(struct LAR *lar, const char *filename);
+void LAR_CloseFile(struct LARFile *file);
+struct LARFile *LAR_MapFile(struct LAR *lar, const char *filename);
+int LAR_SetCompressionFuncs(struct LAR *lar, int algo,
+			    LAR_CompFunc cfunc, LAR_DecompFunc dfunc);
+void LAR_Close(struct LAR *lar);
+struct LAR *LAR_Open(const char *filename);
+struct LAR *LAR_Create(const char *filename);
+void LAR_SetAttrs(struct LARAttr *attrs, char *name, int algo);
+
+#endif

Added: trunk/payloads/bayou/util/pbuilder/liblar/self.c
===================================================================
--- trunk/payloads/bayou/util/pbuilder/liblar/self.c	                        (rev 0)
+++ trunk/payloads/bayou/util/pbuilder/liblar/self.c	2008-11-02 17:01:06 UTC (rev 3719)
@@ -0,0 +1,206 @@
+/*
+ * This file is part of the bayou project.
+ *
+ * Copyright (C) 2008 Advanced Micro Devices, Inc.
+ *
+ * Includes code from util/lar from coreboot-v3
+ *
+ * Copyright (C) 2006-2007 coresystems GmbH
+ * Copyright (C) 2007 Patrick Georgi <patrick at georgi-clan.de>
+ * Copyright (C) 2007 Advanced Micro Devices, Inc.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ */
+
+#include <stdio.h>
+#include <string.h>
+#include <stdlib.h>
+#include <sys/stat.h>
+#include <elf.h>
+#include <sys/mman.h>
+#include <unistd.h>
+#include <fcntl.h>
+#include <stdint.h>
+
+typedef uint64_t u64;
+typedef int64_t s64;
+typedef uint32_t u32;
+typedef int32_t s32;
+typedef uint8_t u8;
+
+#include "self.h"
+
+int elf_to_self(const char *filename, unsigned char **buffer,
+		void (*compress) (char *, int, char *, int *))
+{
+	struct stat s;
+	Elf32_Phdr *phdr;
+	Elf32_Ehdr *ehdr;
+	Elf32_Shdr *shdr;
+	void *filep;
+	char *header, *strtab;
+	unsigned char *sptr;
+	int headers, segments = 1, isize = 0, osize = 0, doffset = 0, fd, i;
+	struct self_segment *segs;
+
+	if (stat(filename, &s)) {
+		printf("Unable to stat %s: %m\n", filename);
+		return -1;
+	}
+
+	fd = open(filename, O_RDONLY);
+
+	if (fd == -1) {
+		printf("Unable to open %s: %m\n", filename);
+		return -1;
+	}
+
+	/* Map the file so that we can easily parse it. */
+	filep = (void *)
+	    mmap(0, s.st_size, PROT_READ, MAP_SHARED, fd, 0);
+
+	if (filep == MAP_FAILED) {
+		close(fd);
+		return -1;
+	}
+
+	ehdr = (Elf32_Ehdr *) filep;
+	headers = ehdr->e_phnum;
+	header = (char *)ehdr;
+
+	phdr = (Elf32_Phdr *) & (header[ehdr->e_phoff]);
+	shdr = (Elf32_Shdr *) & (header[ehdr->e_shoff]);
+
+	strtab = &header[shdr[ehdr->e_shstrndx].sh_offset];
+
+	/* Count number of headers - look for the .notes.pinfo section. */
+	for (i = 0; i < ehdr->e_shnum; i++) {
+		char *name;
+
+		if (i == ehdr->e_shstrndx)
+			continue;
+
+		if (shdr[i].sh_size == 0)
+			continue;
+
+		name = (char *)(strtab + shdr[i].sh_name);
+
+		if (!strcmp(name, ".note.pinfo"))
+			segments++;
+	}
+
+	/*
+	 * Now, regular headers - we only care about PT_LOAD headers,
+	 * because thats what we're actually going to load.
+	 */
+	for (i = 0; i < headers; i++) {
+		if (phdr[i].p_type != PT_LOAD)
+			continue;
+
+		/* Empty segments are never interesting. */
+		if (phdr[i].p_memsz == 0)
+			continue;
+
+		isize += phdr[i].p_filesz;
+		segments++;
+	}
+
+	/* Allocate a block of memory to store the SELF in. */
+	sptr = calloc((segments * sizeof(struct self_segment)) + isize, 1);
+	doffset = (segments * sizeof(struct self_segment));
+
+	if (sptr == NULL)
+		goto err;
+
+	segs = (struct self_segment *)sptr;
+	segments = 0;
+
+	for (i = 0; i < ehdr->e_shnum; i++) {
+		char *name;
+
+		if (i == ehdr->e_shstrndx)
+			continue;
+
+		if (shdr[i].sh_size == 0)
+			continue;
+
+		name = (char *)(strtab + shdr[i].sh_name);
+
+		if (!strcmp(name, ".note.pinfo")) {
+			segs[segments].type = SELF_TYPE_PARAMS;
+			segs[segments].load_addr = 0;
+			segs[segments].len = (u32) shdr[i].sh_size;
+			segs[segments].offset = doffset;
+
+			memcpy((unsigned long *)(sptr + doffset),
+			       &header[shdr[i].sh_offset], shdr[i].sh_size);
+
+			doffset += segs[segments].len;
+			osize += segs[segments].len;
+
+			segments++;
+		}
+	}
+
+	for (i = 0; i < headers; i++) {
+		if (phdr[i].p_type != PT_LOAD)
+			continue;
+
+		if (phdr[i].p_memsz == 0)
+			continue;
+
+		segs[segments].type = SELF_TYPE_DATA;
+		segs[segments].load_addr = (u64) phdr[i].p_paddr;
+		segs[segments].mem_len = (u32) phdr[i].p_memsz;
+		segs[segments].offset = doffset;
+
+		compress((char *)&header[phdr[i].p_offset],
+			 phdr[i].p_filesz,
+			 (char *)(sptr + doffset), (int *)&segs[segments].len);
+
+		doffset += segs[segments].len;
+		osize += segs[segments].len;
+
+		segments++;
+	}
+
+	segs[segments].type = SELF_TYPE_ENTRY;
+	segs[segments++].load_addr = (unsigned long long)ehdr->e_entry;
+
+	*buffer = sptr;
+
+	munmap(filep, s.st_size);
+	close(fd);
+
+	return (segments * sizeof(struct self_segment)) + osize;
+
+err:
+	munmap(filep, s.st_size);
+	close(fd);
+
+	return -1;
+}
+
+int iself(char *filename)
+{
+	Elf32_Ehdr ehdr;
+	int fd = open(filename, O_RDONLY);
+	int ret = 0;
+
+	if (fd == -1)
+		return 0;
+
+	if (read(fd, &ehdr, sizeof(ehdr)) == sizeof(ehdr))
+		ret = !memcmp(ehdr.e_ident, ELFMAG, 4);
+
+	close(fd);
+
+	return ret;
+}

Added: trunk/payloads/bayou/util/pbuilder/liblar/self.h
===================================================================
--- trunk/payloads/bayou/util/pbuilder/liblar/self.h	                        (rev 0)
+++ trunk/payloads/bayou/util/pbuilder/liblar/self.h	2008-11-02 17:01:06 UTC (rev 3719)
@@ -0,0 +1,42 @@
+/*
+ * This file is part of the bayou project.
+ *
+ * Copyright (C) 2008 Advanced Micro Devices, Inc.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ *
+ * 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., 51 Franklin St, Fifth Floor, Boston, MA  02110-1301 USA
+ */
+
+#ifndef SELF_H_
+#define SELF_H_
+
+struct self_segment {
+	u32 type;
+	u32 offset;
+	u64 load_addr;
+	u32 len;
+	u32 mem_len;
+};
+
+#define SELF_TYPE_CODE   0x45444F43
+#define SELF_TYPE_DATA   0x41544144
+#define SELF_TYPE_BSS    0x20535342
+#define SELF_TYPE_PARAMS 0x41524150
+#define SELF_TYPE_ENTRY  0x52544E45
+
+int elf_to_self(const char *filename, unsigned char **buffer,
+		void (*compress) (char *, int, char *, int *));
+
+int iself(char *filename);
+
+#endif

Added: trunk/payloads/bayou/util/pbuilder/main.c
===================================================================
--- trunk/payloads/bayou/util/pbuilder/main.c	                        (rev 0)
+++ trunk/payloads/bayou/util/pbuilder/main.c	2008-11-02 17:01:06 UTC (rev 3719)
@@ -0,0 +1,82 @@
+/*
+ * This file is part of the bayou project.
+ *
+ * Copyright (C) 2008 Advanced Micro Devices, Inc.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ *
+ * 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., 51 Franklin St, Fifth Floor, Boston, MA  02110-1301 USA
+ */
+
+#include <stdio.h>
+#include <string.h>
+#include <getopt.h>
+#include "pbuilder.h"
+
+static void usage(void)
+{
+	printf("./pbuilder [-c config] [create|show] [LAR]\n");
+}
+
+int main(int argc, char **argv)
+{
+	char *config = NULL;
+
+	while (1) {
+		signed ch = getopt(argc, argv, "c:");
+		if (ch == -1)
+			break;
+
+		switch (ch) {
+		case 'c':
+			config = optarg;
+			break;
+		default:
+			usage();
+			return -1;
+		}
+	}
+
+	if (optind >= argc) {
+		usage();
+		return 0;
+	}
+
+	if (!strcmp(argv[optind], "create")) {
+		if (config == NULL) {
+			warn("E: No config was provided\n");
+			usage();
+			return -1;
+		}
+
+		if (optind + 1 >= argc) {
+			warn("E: No LAR name was given\n");
+			usage();
+			return -1;
+		}
+
+		create_lar_from_config((const char *)config,
+				       (const char *)argv[optind + 1]);
+	} else if (!strcmp(argv[optind], "show")) {
+		if (optind + 1 >= argc) {
+			warn("E: No LAR name was given\n");
+			usage();
+			return -1;
+		}
+		pbuilder_show_lar((const char *)argv[optind + 1]);
+	} else {
+		usage();
+		return -1;
+	}
+
+	return 0;
+}

Added: trunk/payloads/bayou/util/pbuilder/pbuilder.h
===================================================================
--- trunk/payloads/bayou/util/pbuilder/pbuilder.h	                        (rev 0)
+++ trunk/payloads/bayou/util/pbuilder/pbuilder.h	2008-11-02 17:01:06 UTC (rev 3719)
@@ -0,0 +1,77 @@
+/*
+ * This file is part of the bayou project.
+ *
+ * Copyright (C) 2008 Advanced Micro Devices, Inc.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ *
+ * 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., 51 Franklin St, Fifth Floor, Boston, MA  02110-1301 USA
+ */
+
+#include <stdio.h>
+
+#ifndef PBUILDER_H_
+#define PBUILDER_H_
+
+#include <stdint.h>
+#include <stdio.h>
+
+#define warn(fmt, args...) fprintf(stderr, fmt, ##args)
+#define die(fmt, args...) \
+  do { fprintf(stderr, fmt, ##args); exit(-1); } \
+  while(0)
+
+struct pentry {
+	uint8_t index;
+	uint8_t parent;
+	uint8_t type;
+	uint8_t flags;
+	uint8_t title[64];
+	char *file;
+	char *larname;
+};
+
+struct config {
+	int timeout;
+	int n_entries;
+	struct pentry **entries;
+};
+
+struct bpt_config {
+	uint32_t id;
+	uint8_t timeout;
+	uint8_t entries;
+	uint8_t padding[10];
+};
+
+struct bpt_pentry {
+	uint8_t index;
+	uint8_t parent;
+	uint8_t type;
+	uint8_t flags;
+	uint8_t title[64];
+	uint8_t nlen;
+};
+
+#define BPT_ID            0x30545042
+#define BPT_TYPE_CHOOSER  0x01
+#define BPT_TYPE_CHAIN    0x02
+#define BPT_TYPE_SUBCHAIN 0x03
+
+#define BPT_FLAG_DEFAULT  0x01
+#define BPT_FLAG_NOSHOW   0x02
+
+int pbuilder_show_lar(const char *input);
+int create_lar_from_config(const char *input, const char *output);
+void parseconfig(FILE * stream, struct config *config);
+
+#endif

Added: trunk/payloads/bayou/util/pbuilder/show.c
===================================================================
--- trunk/payloads/bayou/util/pbuilder/show.c	                        (rev 0)
+++ trunk/payloads/bayou/util/pbuilder/show.c	2008-11-02 17:01:06 UTC (rev 3719)
@@ -0,0 +1,131 @@
+/*
+ * This file is part of the bayou project.
+ *
+ * Copyright (C) 2008 Advanced Micro Devices, Inc.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ *
+ * 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., 51 Franklin St, Fifth Floor, Boston, MA  02110-1301 USA
+ */
+
+#include <stdio.h>
+#include "liblar.h"
+#include "pbuilder.h"
+
+void show_subchain(struct bpt_config *cfg, char *fptr, int index)
+{
+	int i;
+	char *ptr = fptr + sizeof(struct bpt_config);
+
+	for (i = 0; i < cfg->entries; i++) {
+		struct bpt_pentry *entry = (struct bpt_pentry *)ptr;
+
+		if (entry->parent == index)
+			printf("      +  %.64s\n",
+			       ptr + sizeof(struct bpt_pentry));
+
+		ptr += (sizeof(struct bpt_pentry) + entry->nlen);
+	}
+}
+
+int show_payloads(struct bpt_config *cfg, char *fptr)
+{
+	int i;
+	char *ptr = fptr + sizeof(struct bpt_config);
+
+	for (i = 0; i < cfg->entries; i++) {
+		struct bpt_pentry *entry = (struct bpt_pentry *)ptr;
+
+		if (entry->parent != 0) {
+			ptr += (sizeof(struct bpt_pentry) + entry->nlen);
+			continue;
+		}
+
+		printf("  ");
+
+		if (entry->flags & BPT_FLAG_DEFAULT)
+			printf("D");
+		else
+			printf(" ");
+
+		if (entry->flags & BPT_FLAG_NOSHOW)
+			printf("N");
+		else
+			printf(" ");
+
+		switch (entry->type) {
+		case BPT_TYPE_CHOOSER:
+			printf("  MENU ");
+			break;
+		case BPT_TYPE_CHAIN:
+			printf("  CHAIN");
+			break;
+		}
+
+		if (entry->title[0] != 0)
+			printf("  %.64s\n", entry->title);
+		else
+			printf("  - no title -\n");
+
+		if (entry->type == BPT_TYPE_CHOOSER)
+			printf("            %.60s\n",
+			       ptr + sizeof(struct bpt_pentry));
+		else
+			show_subchain(cfg, fptr, entry->index);
+
+		ptr += (sizeof(struct bpt_pentry) + entry->nlen);
+	}
+
+	return 0;
+}
+
+int pbuilder_show_lar(const char *input)
+{
+	int ret = -1;
+	struct LAR *lar;
+	struct bpt_config *cfg;
+	struct LARFile *lfile;
+
+	lar = LAR_Open(input);
+
+	if (lar == NULL) {
+		warn("E: Couldn't open LAR %s\n", input);
+		return -1;
+	}
+
+	lfile = LAR_MapFile(lar, "bayou_payload_table");
+
+	if (lfile == NULL) {
+		warn("E: Couldn't find the bayou payload table. Nothing to do.\n");
+		goto err;
+	}
+
+	cfg = (struct bpt_config *)lfile->buffer;
+
+	if (cfg->id != BPT_ID) {
+		warn("E: BPT ID does not match\n");
+		goto err;
+	}
+
+	printf("Bayou Payload Configuration\n");
+	printf("Timeout = %d seconds\n", cfg->timeout);
+
+	printf("Payload List:\n");
+	show_payloads(cfg, lfile->buffer);
+	ret = 0;
+
+err:
+	LAR_CloseFile(lfile);
+	LAR_Close(lar);
+
+	return ret;
+}




From info at coresystems.de  Sun Nov  2 18:17:48 2008
From: info at coresystems.de (coreboot information)
Date: Sun, 02 Nov 2008 18:17:48 +0100
Subject: [coreboot] r3719 build service
Message-ID: <E1KwgaC-0005Lq-7J@ra.coresystems.de>

Dear coreboot readers!

This is the automated build check service of coreboot.

The developer "uwe" checked in revision 3719 to
the coreboot source repository and caused the following 
changes:

Change Log:
Import a slightly modified Bayou version into svn. This is based
on the last snapshot posted by Jordan Crouse. This commit is long
overdue.

Changes by me include:

 - Rename 'utils' to 'util' for consistency with our other projects.

 - Move the main code out of src/* into the top-level directory.

 - Add missing license headers to the following files:
   Makefile, pbuilder/liblar/Makefile, util/pbuilder/Makefile.

 - Dropped the util/pbuilder/lzma completely. I'm working on reusing
   the lzma/ dir from v3 via svn:externals. Alas, this also means
   that Bayou won't yet compile out of the box.

 - Coding-style and white-space fixes (indent) for all files.

Signed-off-by: Uwe Hermann <uwe at hermann-uwe.de>
Acked-by: Uwe Hermann <uwe at hermann-uwe.de>



Build Log:
Compilation of broadcom:blast has been broken
See the error log at http://qa.coreboot.org/log_buildbrd.php?revision=3719&device=blast&vendor=broadcom


If something broke during this checkin please be a pain 
in uwe's neck until the issue is fixed.

If this issue is not fixed within 24h the revision should 
be backed out.

   Best regards,
     coreboot automatic build system





From svn at coreboot.org  Sun Nov  2 18:48:20 2008
From: svn at coreboot.org (svn at coreboot.org)
Date: Sun,  2 Nov 2008 18:48:20 +0100
Subject: [coreboot] r3720 - in trunk/payloads/bayou: . util/pbuilder
Message-ID: <mailman.2372.1355071423.16123.coreboot@coreboot.org>

Author: uwe
Date: 2008-11-02 18:48:20 +0100 (Sun, 02 Nov 2008)
New Revision: 3720

Added:
   trunk/payloads/bayou/bayou.xml.example
Modified:
   trunk/payloads/bayou/Makefile
   trunk/payloads/bayou/util/pbuilder/
   trunk/payloads/bayou/util/pbuilder/Makefile
Log:
Get the lzma/ directory from v3 via svn:externals, for use with Bayou.

Also, fix a few Makefiles regarding lzma stuff and 'make clean' behaviour.

Add bayou.xml.example which users can use as a starting point.

Bayou does compile fine now (if you build ../libpayload) before.

Signed-off-by: Uwe Hermann <uwe at hermann-uwe.de>
Acked-by: Uwe Hermann <uwe at hermann-uwe.de>



Modified: trunk/payloads/bayou/Makefile
===================================================================
--- trunk/payloads/bayou/Makefile	2008-11-02 17:01:06 UTC (rev 3719)
+++ trunk/payloads/bayou/Makefile	2008-11-02 17:48:20 UTC (rev 3720)
@@ -45,7 +45,7 @@
 LPCC=$(LIBPAYLOAD_DIR)/bin/lpgcc
 
 bayou.elf: $(OBJECTS-y)
-	$(LPCC) -ldscript bayou.ldscript -m32 -o $@ $(OBJECTS-y)
+	$(LPCC) $(LDFLAGS) -m32 -o $@ $(OBJECTS-y)
 	@ strip $@
 
 builtin-lar.o: $(BUILTIN_LAR)
@@ -59,7 +59,9 @@
 	make -C util/pbuilder
 
 %.o: %.c
-	$(LPCC) $(CFLAGS) -c -o $@ $<	
+	$(LPCC) $(CFLAGS) -c -o $@ $<
 
 clean:
 	rm -f *.o bayou.elf builtin.lar
+	make -C util/pbuilder clean
+

Added: trunk/payloads/bayou/bayou.xml.example
===================================================================
--- trunk/payloads/bayou/bayou.xml.example	                        (rev 0)
+++ trunk/payloads/bayou/bayou.xml.example	2008-11-02 17:48:20 UTC (rev 3720)
@@ -0,0 +1,42 @@
+<!--
+## This file is part of the bayou project.
+##
+## Copyright (C) 2008 Advanced Micro Devices, Inc.
+##
+## This program is free software; you can redistribute it and/or modify
+## it under the terms of the GNU General Public License version 2 as
+## published by the Free Software Foundation.
+##
+## This program is distributed in the hope that it will be useful,
+## but WITHOUT ANY WARRANTY; without even the implied warranty of
+## MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+## GNU General Public License for more details.
+##
+## 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., 51 Franklin St, Fifth Floor, Boston, MA  02110-1301 USA
+-->
+
+<!-- Sample Bayou config file. Adapt as needed, then rename to bayou.xml. -->
+
+<BayouConfig>
+  <global>
+    <timeout>10</timeout>
+  </global>
+  <payloads>
+    <payload type="chain" flags="default">
+      <title>Default Chain</title>
+      <chain>
+	<file>payloads/passwd.elf</file>
+	<lar>passwd</lar>
+      </chain>      
+      <chain>
+	<file>payloads/coreinfo.elf</file>
+      </chain>
+    </payload>    
+    <payload type="chooser">
+      <file>payloads/coreinfo.elf</file>
+    </payload>
+  </payloads>
+</BayouConfig>
+


Property changes on: trunk/payloads/bayou/util/pbuilder
___________________________________________________________________
Added: svn:externals
   + lzma svn://coreboot.org/repository/coreboot-v3/util/lzma


Modified: trunk/payloads/bayou/util/pbuilder/Makefile
===================================================================
--- trunk/payloads/bayou/util/pbuilder/Makefile	2008-11-02 17:01:06 UTC (rev 3719)
+++ trunk/payloads/bayou/util/pbuilder/Makefile	2008-11-02 17:48:20 UTC (rev 3720)
@@ -22,17 +22,46 @@
 INCLUDES := -Iliblar/
 CFLAGS=-Wall -Werror -g
 
+all: pbuilder
+
+LZMA_OBJ := lzma/LZMAEncoder.o lzma/LZInWindow.o lzma/RangeCoderBit.o
+LZMA_OBJ += lzma/StreamUtils.o lzma/OutBuffer.o lzma/Alloc.o lzma/CRC.o
+LZMA_OBJ += lzma/lzma-compress.o
+
+lzma/lzma-compress.o: lzma/minilzma.cc
+	g++ -o $@ -c -DCOMPACT $<
+
+lzma/%.o: lzma/C/7zip/Compress/LZMA/%.cpp
+	g++ -o $@ -c $<
+
+lzma/%.o: lzma/C/7zip/Compress/LZ/%.cpp
+	g++ -o $@ -c $<
+
+lzma/%.o: lzma/C/7zip/Compress/RangeCoder/%.cpp
+	g++ -o $@ -c $<
+
+lzma/%.o: lzma/C/7zip/Decompress/%.cpp
+	g++ -o $@ -c $<
+
+lzma/%.o: lzma/C/7zip/Common/%.cpp
+	g++ -o $@ -c $<
+
+lzma/%.o: lzma/C/Common/%.cpp
+	g++ -o $@ -c $<
+
+lzma/%.o: lzma/%.cc
+	g++ -o $@ -c $<
+
 pbuilder: $(PBUILDOBJS) $(LZMA_OBJ) liblar/liblar.a
 	$(CXX) -o $@ $(PBUILDOBJS) $(LZMA_OBJ) -L ./liblar -llar -lexpat
 
 liblar/liblar.a:
 	make -C liblar
 
-include lzma/Makefile
-
 %.o: %.c
 	$(CC) -c $(CFLAGS) $(INCLUDES) -o $@ $<
 
 clean:
-	rm -f pbuilder *.o
+	rm -f pbuilder *.o lzma/*.o
 	make -C liblar clean
+




From info at coresystems.de  Sun Nov  2 19:04:53 2008
From: info at coresystems.de (coreboot information)
Date: Sun, 02 Nov 2008 19:04:53 +0100
Subject: [coreboot] r3720 build service
Message-ID: <E1KwhJl-0008Af-QP@ra.coresystems.de>

Dear coreboot readers!

This is the automated build check service of coreboot.

The developer "uwe" checked in revision 3720 to
the coreboot source repository and caused the following 
changes:

Change Log:
Get the lzma/ directory from v3 via svn:externals, for use with Bayou.

Also, fix a few Makefiles regarding lzma stuff and 'make clean' behaviour.

Add bayou.xml.example which users can use as a starting point.

Bayou does compile fine now (if you build ../libpayload) before.

Signed-off-by: Uwe Hermann <uwe at hermann-uwe.de>
Acked-by: Uwe Hermann <uwe at hermann-uwe.de>



Build Log:
Compilation of broadcom:blast has been fixed


If something broke during this checkin please be a pain 
in uwe's neck until the issue is fixed.

If this issue is not fixed within 24h the revision should 
be backed out.

   Best regards,
     coreboot automatic build system





From svn at coreboot.org  Sun Nov  2 20:51:50 2008
From: svn at coreboot.org (svn at coreboot.org)
Date: Sun,  2 Nov 2008 20:51:50 +0100
Subject: [coreboot] r3721 - trunk/util/flashrom
Message-ID: <mailman.2373.1355071423.16123.coreboot@coreboot.org>

Author: stepan
Date: 2008-11-02 20:51:50 +0100 (Sun, 02 Nov 2008)
New Revision: 3721

Modified:
   trunk/util/flashrom/ichspi.c
Log:
Drop nr/opcode_index parameter from run_opcode and search the opmenu for the opcode instead.
This is slightly slower (ha, ha), but works on boards with a locked opmenu. Tested on ICH7 and works.

Signed-off-by: Stefan Reinauer <stepan at coresystems.de>
Acked-by: Carl-Daniel Hailfinger <c-d.hailfinger.devel.2006 at gmx.net>



Modified: trunk/util/flashrom/ichspi.c
===================================================================
--- trunk/util/flashrom/ichspi.c	2008-11-02 17:48:20 UTC (rev 3720)
+++ trunk/util/flashrom/ichspi.c	2008-11-02 19:51:50 UTC (rev 3721)
@@ -148,7 +148,7 @@
 
 /* Common SPI functions */
 static int program_opcodes(OPCODES * op);
-static int run_opcode(uint8_t nr, OPCODE op, uint32_t offset,
+static int run_opcode(OPCODE op, uint32_t offset,
 		      uint8_t datalength, uint8_t * data);
 static int ich_spi_read_page(struct flashchip *flash, uint8_t * buf,
 			     int offset, int maxdata);
@@ -225,7 +225,7 @@
 	return 0;
 }
 
-static int ich7_run_opcode(uint8_t nr, OPCODE op, uint32_t offset,
+static int ich7_run_opcode(OPCODE op, uint32_t offset,
 			   uint8_t datalength, uint8_t * data, int maxdata)
 {
 	int write_cmd = 0;
@@ -233,6 +233,8 @@
 	uint32_t temp32 = 0;
 	uint16_t temp16;
 	uint32_t a;
+	uint64_t opmenu;
+	int opcode_index;
 
 	/* Is it a write command? */
 	if ((op.spi_type == SPI_OPCODE_TYPE_WRITE_NO_ADDRESS)
@@ -280,8 +282,21 @@
 	}
 
 	/* Select opcode */
-	temp16 |= ((uint16_t) (nr & 0x07)) << 4;
+	opmenu = REGREAD32(ICH7_REG_OPMENU);
+	opmenu |= ((uint64_t)REGREAD32(ICH7_REG_OPMENU + 4)) << 32;
 
+	for (opcode_index=0; opcode_index<8; opcode_index++) {
+		if((opmenu & 0xff) == op.opcode) {
+			break;
+		}
+		opmenu >>= 8;
+	}
+	if (opcode_index == 8) {
+		printf_debug("Opcode %x not found.\n", op.opcode);
+		return 1;
+	}
+	temp16 |= ((uint16_t) (opcode_index & 0x07)) << 4;
+
 	/* Handle Atomic */
 	if (op.atomic != 0) {
 		/* Select atomic command */
@@ -328,13 +343,15 @@
 	return 0;
 }
 
-static int ich9_run_opcode(uint8_t nr, OPCODE op, uint32_t offset,
+static int ich9_run_opcode(OPCODE op, uint32_t offset,
 			   uint8_t datalength, uint8_t * data)
 {
 	int write_cmd = 0;
 	int timeout;
 	uint32_t temp32;
 	uint32_t a;
+	uint64_t opmenu;
+	int opcode_index;
 
 	/* Is it a write command? */
 	if ((op.spi_type == SPI_OPCODE_TYPE_WRITE_NO_ADDRESS)
@@ -383,8 +400,21 @@
 	}
 
 	/* Select opcode */
-	temp32 |= ((uint32_t) (nr & 0x07)) << (8 + 4);
+	opmenu = REGREAD32(ICH9_REG_OPMENU);
+	opmenu |= ((uint64_t)REGREAD32(ICH9_REG_OPMENU + 4)) << 32;
 
+	for (opcode_index=0; opcode_index<8; opcode_index++) {
+		if((opmenu & 0xff) == op.opcode) {
+			break;
+		}
+		opmenu >>= 8;
+	}
+	if (opcode_index == 8) {
+		printf_debug("Opcode %x not found.\n", op.opcode);
+		return 1;
+	}
+	temp32 |= ((uint32_t) (opcode_index & 0x07)) << (8 + 4);
+
 	/* Handle Atomic */
 	if (op.atomic != 0) {
 		/* Select atomic command */
@@ -431,16 +461,16 @@
 	return 0;
 }
 
-static int run_opcode(uint8_t nr, OPCODE op, uint32_t offset,
+static int run_opcode(OPCODE op, uint32_t offset,
 		      uint8_t datalength, uint8_t * data)
 {
 	switch (flashbus) {
 	case BUS_TYPE_VIA_SPI:
-		return ich7_run_opcode(nr, op, offset, datalength, data, 16);
+		return ich7_run_opcode(op, offset, datalength, data, 16);
 	case BUS_TYPE_ICH7_SPI:
-		return ich7_run_opcode(nr, op, offset, datalength, data, 64);
+		return ich7_run_opcode(op, offset, datalength, data, 64);
 	case BUS_TYPE_ICH9_SPI:
-		return ich9_run_opcode(nr, op, offset, datalength, data);
+		return ich9_run_opcode(op, offset, datalength, data);
 	default:
 		printf_debug("%s: unsupported chipset\n", __FUNCTION__);
 	}
@@ -453,7 +483,7 @@
 {
 	printf_debug("ich_spi_erase_block: offset=%d, sectors=%d\n", offset, 1);
 
-	if (run_opcode(2, curopcodes->opcode[2], offset, 0, NULL) != 0) {
+	if (run_opcode(curopcodes->opcode[2], offset, 0, NULL) != 0) {
 		printf_debug("Error erasing sector at 0x%x", offset);
 		return -1;
 	}
@@ -477,7 +507,7 @@
 		if (remaining < maxdata) {
 
 			if (run_opcode
-			    (1, curopcodes->opcode[1],
+			    (curopcodes->opcode[1],
 			     offset + (page_size - remaining), remaining,
 			     &buf[page_size - remaining]) != 0) {
 				printf_debug("Error reading");
@@ -486,7 +516,7 @@
 			remaining = 0;
 		} else {
 			if (run_opcode
-			    (1, curopcodes->opcode[1],
+			    (curopcodes->opcode[1],
 			     offset + (page_size - remaining), maxdata,
 			     &buf[page_size - remaining]) != 0) {
 				printf_debug("Error reading");
@@ -512,7 +542,7 @@
 	for (a = 0; a < page_size; a += maxdata) {
 		if (remaining < maxdata) {
 			if (run_opcode
-			    (0, curopcodes->opcode[0],
+			    (curopcodes->opcode[0],
 			     offset + (page_size - remaining), remaining,
 			     &bytes[page_size - remaining]) != 0) {
 				printf_debug("Error writing");
@@ -521,7 +551,7 @@
 			remaining = 0;
 		} else {
 			if (run_opcode
-			    (0, curopcodes->opcode[0],
+			    (curopcodes->opcode[0],
 			     offset + (page_size - remaining), maxdata,
 			     &bytes[page_size - remaining]) != 0) {
 				printf_debug("Error writing");
@@ -641,7 +671,7 @@
 		count = readcnt;
 	}
 
-	if (run_opcode(opcode_index, *opcode, addr, count, data) != 0) {
+	if (run_opcode(*opcode, addr, count, data) != 0) {
 		printf_debug("run OPCODE 0x%02x failed\n", opcode->opcode);
 		return 1;
 	}




From xanga9885 at hotmail.com  Sun Nov  2 20:53:28 2008
From: xanga9885 at hotmail.com (Andy Kiss)
Date: Sun, 2 Nov 2008 14:53:28 -0500
Subject: [coreboot] Info Stuff
Message-ID: <BLU107-W3B3A85DE873A56490F5F5B2220@phx.gbl>


irq_tables.c, mptable.txt, superiotool-dV.txt, dmidecode.txt, dmidecode-dump.txt, lspci-tvnn.txt, and lshw.txt.

_________________________________________________________________
Store, manage and share up to 5GB with Windows Live SkyDrive.
http://skydrive.live.com/welcome.aspx?provision=1?ocid=TXT_TAGLM_WL_skydrive_102008
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: dmidecode.txt
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20081102/d8220086/attachment.txt>
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: dmidecode-dump.txt
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20081102/d8220086/attachment-0001.txt>
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: lshw.txt
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20081102/d8220086/attachment-0002.txt>
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: lspci-tvnn.txt
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20081102/d8220086/attachment-0003.txt>
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: superiotool-dV.txt
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20081102/d8220086/attachment-0004.txt>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: irq_tables.c
Type: text/x-csrc
Size: 2439 bytes
Desc: not available
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20081102/d8220086/attachment.c>
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: mptable.txt
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20081102/d8220086/attachment-0005.txt>

From stepan at coresystems.de  Sun Nov  2 21:15:17 2008
From: stepan at coresystems.de (Stefan Reinauer)
Date: Sun, 02 Nov 2008 21:15:17 +0100
Subject: [coreboot] [PATCH] v2: Trim i82801xx driver to only a	sensible
 subset
In-Reply-To: <20081102143427.GI18273@greenwood>
References: <20081017170621.GB28924@greenwood>	<20081023200038.GB14982@greenwood>	<20081024013443.8984.qmail@stuge.se>
	<20081102143427.GI18273@greenwood>
Message-ID: <490E0A55.7020705@coresystems.de>

Uwe Hermann wrote:
> On Fri, Oct 24, 2008 at 03:34:43AM +0200, Peter Stuge wrote:
>   
>> Uwe Hermann wrote:
>>     
>>>> Trim down the list of southbridges supported by the i82801xx driver
>>>> to only a set of reasonably similar ones, namely (for now) ICH0* -
>>>> ICH6*, and C-ICH.
>>>>         
>>> *ping*
>>>
>>> Any objections?
>>>       
>> I'm ok with this but I would like to hear from Stefan.
>>     
>
> He informally acked it on IRC, committed in r3718.
>   
Acked-by: Stefan Reinauer <stepan at coresystems.de>

to make it formal :-)

-- 
coresystems GmbH ? Brahmsstr. 16 ? D-79104 Freiburg i. Br.
      Tel.: +49 761 7668825 ? Fax: +49 761 7664613
Email: info at coresystems.de  ? http://www.coresystems.de/
Registergericht: Amtsgericht Freiburg ? HRB 7656
Gesch?ftsf?hrer: Stefan Reinauer ? Ust-IdNr.: DE245674866




From peter at stuge.se  Sun Nov  2 21:32:31 2008
From: peter at stuge.se (Peter Stuge)
Date: Sun, 2 Nov 2008 21:32:31 +0100
Subject: [coreboot] [PATCH] v2: Trim i82801xx driver to only a	sensible
	subset
In-Reply-To: <490E0A55.7020705@coresystems.de>
References: <20081017170621.GB28924@greenwood>
	<20081023200038.GB14982@greenwood>
	<20081024013443.8984.qmail@stuge.se>
	<20081102143427.GI18273@greenwood>
	<490E0A55.7020705@coresystems.de>
Message-ID: <20081102203231.538.qmail@stuge.se>

Stefan Reinauer wrote:
> to make it formal :-)

IMO IRC acks are just as good as email acks.


//Peter



From paulepanter at users.sourceforge.net  Sun Nov  2 22:26:55 2008
From: paulepanter at users.sourceforge.net (Paul Menzel)
Date: Sun, 02 Nov 2008 22:26:55 +0100
Subject: [coreboot] Thoughts for call for help in Ubuntu forum
Message-ID: <1225661215.4094.33.camel@mattotaupa.wohnung.familie-menzel.net>

Dear list,


lately some message came to the list in reaction to the post You can
help out Coreboot! in the Ubuntu forums [1]. I do not know if one of you
posted this, but I am wondering if maybe also the flashrom information
would be useful?

Also in February Carl-Daniel posted a script for this purpose, which was
never acked or commited to the repository [2][3].

If information is still needed maybe the script can be checked in, the
proposed e-mail-addresses be setup and a page in the Wiki be created.

Maybe it is also beneficial to suggest a common subject, so that the
messages can be searched better.


Thanks,

Paul


[1] http://ubuntuforums.org/showthread.php?t=961975
[2] http://www.coreboot.org/pipermail/coreboot/2008-February/031507.html
[3] http://www.coreboot.org/pipermail/coreboot/2008-March/031658.html
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 197 bytes
Desc: Dies ist ein digital signierter Nachrichtenteil
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20081102/18850867/attachment.sig>

From vincent.legoll at gmail.com  Sun Nov  2 23:25:25 2008
From: vincent.legoll at gmail.com (Vincent Legoll)
Date: Sun, 2 Nov 2008 23:25:25 +0100
Subject: [coreboot] Thoughts for call for help in Ubuntu forum
In-Reply-To: <1225661215.4094.33.camel@mattotaupa.wohnung.familie-menzel.net>
References: <1225661215.4094.33.camel@mattotaupa.wohnung.familie-menzel.net>
Message-ID: <4727185d0811021425o561a4f91v6286754abdb04a1e@mail.gmail.com>

On Sun, Nov 2, 2008 at 10:26 PM, Paul Menzel wrote:
> lately some message came to the list in reaction to the post "You can
> help out Coreboot!" in the Ubuntu forums

Is that kind of flood really useful ?
Is someone using it to enhance coreboot ?

Those are genuinely naive questions, nothing harsh intended,
because I can't remember seeing a reaction to those posts.

-- 
Vincent Legoll



From stepan at coresystems.de  Sun Nov  2 23:47:35 2008
From: stepan at coresystems.de (Stefan Reinauer)
Date: Sun, 02 Nov 2008 23:47:35 +0100
Subject: [coreboot] Thoughts for call for help in Ubuntu forum
In-Reply-To: <4727185d0811021425o561a4f91v6286754abdb04a1e@mail.gmail.com>
References: <1225661215.4094.33.camel@mattotaupa.wohnung.familie-menzel.net>
	<4727185d0811021425o561a4f91v6286754abdb04a1e@mail.gmail.com>
Message-ID: <490E2E07.8050107@coresystems.de>

Vincent Legoll schrieb:
> On Sun, Nov 2, 2008 at 10:26 PM, Paul Menzel wrote:
>   
>> lately some message came to the list in reaction to the post "You can
>> help out Coreboot!" in the Ubuntu forums
>>     
>
> Is that kind of flood really useful ?
> Is someone using it to enhance coreboot ?
I don't think so. I'm afraid this call for action will cause more 
expectations than it will actually help, as the information is obsolete 
again in a mere couple of months. But who knows. Maybe someone is 
sitting with the stack of these messages and preparing lots of coreboot 
ports already :-)

Stefan




From stepan at coresystems.de  Sun Nov  2 23:54:42 2008
From: stepan at coresystems.de (Stefan Reinauer)
Date: Sun, 02 Nov 2008 23:54:42 +0100
Subject: [coreboot] r975 - in coreboot-v3: arch/x86
	mainboard/via	mainboard/via/epia-cn
Message-ID: <490E2FB2.50803@coresystems.de>

svn at coreboot.org schrieb:
> Author: rminnich
> Date: 2008-10-31 23:43:02 +0100 (Fri, 31 Oct 2008)
> New Revision: 975
>
> Modified:
>    coreboot-v3/arch/x86/Makefile
>    coreboot-v3/mainboard/via/Kconfig
>    coreboot-v3/mainboard/via/epia-cn/cmos.layout
> Log:
> no PIRQ table
> Make cmos.layout work with incomprehensible tool -- just turn off checksums.
Which tool are you referring to?




From stepan at coresystems.de  Sun Nov  2 23:58:13 2008
From: stepan at coresystems.de (Stefan Reinauer)
Date: Sun, 02 Nov 2008 23:58:13 +0100
Subject: [coreboot] Fwd:  Flashrom problem
In-Reply-To: <90305c1d0810311349p11034c58y96ec462944ecf3fe@mail.gmail.com>
References: <90305c1d0810311316j553d41c2oa6114906fd9f8de6@mail.gmail.com>	<5D26EA3E5F264C60ACA19133BCA6FEC9@chimp>	<90305c1d0810311340s3a955d18m16f9979ab1a5cf25@mail.gmail.com>
	<90305c1d0810311349p11034c58y96ec462944ecf3fe@mail.gmail.com>
Message-ID: <490E3085.7050100@coresystems.de>

What kernel is that?

Collin Gregory schrieb:
> The problem is still unsolved, does ainyone have got an idear ?
> Could it be a kernel configuration problem ?
>
> ---------- Forwarded message ----------
> From: *Collin Gregory* <collin.gregory at gmail.com 
> <mailto:collin.gregory at gmail.com>>
> Date: 2008/10/31
> Subject: Re: [coreboot] Flashrom problem
> To: Myles Watson <mylesgw at gmail.com <mailto:mylesgw at gmail.com>>
>
>
> Hello Myles,
>
> Thanks for your quick answer.
> Here is my command line that i typed : ./flashrom -r test
> Here is what ./flashrom -r test -V gives :
> Calibrating Delay loop... 797M loops per second, 100 myus = 201 us, OK.
> Can't mmap memory using /dev/mem : Invalid Argument.
>
> That's for it.
> The version of flashrom is  the r3708.






From c-d.hailfinger.devel.2006 at gmx.net  Mon Nov  3 00:00:50 2008
From: c-d.hailfinger.devel.2006 at gmx.net (Carl-Daniel Hailfinger)
Date: Mon, 03 Nov 2008 00:00:50 +0100
Subject: [coreboot] Thoughts for call for help in Ubuntu forum
In-Reply-To: <4727185d0811021425o561a4f91v6286754abdb04a1e@mail.gmail.com>
References: <1225661215.4094.33.camel@mattotaupa.wohnung.familie-menzel.net>
	<4727185d0811021425o561a4f91v6286754abdb04a1e@mail.gmail.com>
Message-ID: <490E3122.5080005@gmx.net>

On 02.11.2008 23:25, Vincent Legoll wrote:
> On Sun, Nov 2, 2008 at 10:26 PM, Paul Menzel wrote:
>   
>> lately some message came to the list in reaction to the post "You can
>> help out Coreboot!" in the Ubuntu forums
>>     
>
> Is that kind of flood really useful ?
>   

It is well-meant, but I actually doubt the usefulness right now. For
one, we don't know for which hardware that stuff is generated. It may be
good to keep the stuff around for later reference, but I don't know
anybody who would have time to analyze these dumps in the next 3 months.

> Is someone using it to enhance coreboot ?
>
> Those are genuinely naive questions, nothing harsh intended,
> because I can't remember seeing a reaction to those posts.
>   

We should have a page called "Want to help?" in the wiki and post easy
instructions there. Installing subversion is not what I consider to be
easy. And we need to explain what our tools do so people can decide on
their own whether they want to run the tools.

Regards,
Carl-Daniel

-- 
http://www.hailfinger.org/




From c-d.hailfinger.devel.2006 at gmx.net  Mon Nov  3 00:22:57 2008
From: c-d.hailfinger.devel.2006 at gmx.net (Carl-Daniel Hailfinger)
Date: Mon, 03 Nov 2008 00:22:57 +0100
Subject: [coreboot] [PATCH] flashrom: More SPI erase functions
In-Reply-To: <4897978C.10202@gmx.net>
References: <4897978C.10202@gmx.net>
Message-ID: <490E3651.1030503@gmx.net>

On 05.08.2008 01:58, Carl-Daniel Hailfinger wrote:
> As promised to Stefan, here's the flashrom patch I've been talking about.
>
> Add additional SPI sector erase and chip erase command functions to
> flashrom. Not all chips support all commands, so allow the implementer
> to select the matching function.
> Fix a layering violation in ICH SPI code to be less bad. Still not
> perfect, but the new code is shorter, more generic and architecturally
> more sound.
> TODO (in a separate patch):
> - move the generic sector erase code to spi.c
> - decide which erase command to use based on info about the chip
> - create a generic spi_erase_all_sectors function which calls the
> generic sector erase function
>   

Thanks to Stefan for reviewing and commenting. New patch follows.

Regards,
Carl-Daniel

Signed-off-by: Carl-Daniel Hailfinger <c-d.hailfinger.devel.2006 at gmx.net>

Index: flashrom-spi_erase/flash.h
===================================================================
--- flashrom-spi_erase/flash.h	(Revision 3718)
+++ flashrom-spi_erase/flash.h	(Arbeitskopie)
@@ -424,8 +424,11 @@
 		const unsigned char *writearr, unsigned char *readarr);
 void spi_write_enable();
 void spi_write_disable();
+int spi_chip_erase_60(struct flashchip *flash);
 int spi_chip_erase_c7(struct flashchip *flash);
 int spi_chip_erase_d8(struct flashchip *flash);
+int spi_block_erase_52(const struct flashchip *flash, unsigned long addr);
+int spi_block_erase_d8(const struct flashchip *flash, unsigned long addr);
 int spi_chip_write(struct flashchip *flash, uint8_t *buf);
 int spi_chip_read(struct flashchip *flash, uint8_t *buf);
 uint8_t spi_read_status_register();
Index: flashrom-spi_erase/spi.c
===================================================================
--- flashrom-spi_erase/spi.c	(Revision 3718)
+++ flashrom-spi_erase/spi.c	(Arbeitskopie)
@@ -271,6 +271,22 @@
 	}
 }
 
+int spi_chip_erase_60(struct flashchip *flash)
+{
+	const unsigned char cmd[JEDEC_CE_60_OUTSIZE] = {JEDEC_CE_60};
+	
+	spi_disable_blockprotect();
+	spi_write_enable();
+	/* Send CE (Chip Erase) */
+	spi_command(sizeof(cmd), 0, cmd, NULL);
+	/* Wait until the Write-In-Progress bit is cleared.
+	 * This usually takes 1-85 s, so wait in 1 s steps.
+	 */
+	while (spi_read_status_register() & JEDEC_RDSR_BIT_WIP)
+		sleep(1);
+	return 0;
+}
+
 int spi_chip_erase_c7(struct flashchip *flash)
 {
 	const unsigned char cmd[JEDEC_CE_C7_OUTSIZE] = { JEDEC_CE_C7 };
@@ -287,6 +303,24 @@
 	return 0;
 }
 
+int spi_block_erase_52(const struct flashchip *flash, unsigned long addr)
+{
+	unsigned char cmd[JEDEC_BE_52_OUTSIZE] = {JEDEC_BE_52};
+
+	cmd[1] = (addr & 0x00ff0000) >> 16;
+	cmd[2] = (addr & 0x0000ff00) >> 8;
+	cmd[3] = (addr & 0x000000ff);
+	spi_write_enable();
+	/* Send BE (Block Erase) */
+	spi_command(sizeof(cmd), 0, cmd, NULL);
+	/* Wait until the Write-In-Progress bit is cleared.
+	 * This usually takes 100-4000 ms, so wait in 100 ms steps.
+	 */
+	while (spi_read_status_register() & JEDEC_RDSR_BIT_WIP)
+		usleep(100 * 1000);
+	return 0;
+}
+
 /* Block size is usually
  * 64k for Macronix
  * 32k for SST
Index: flashrom-spi_erase/ichspi.c
===================================================================
--- flashrom-spi_erase/ichspi.c	(Revision 3718)
+++ flashrom-spi_erase/ichspi.c	(Arbeitskopie)
@@ -154,7 +154,6 @@
 			     int offset, int maxdata);
 static int ich_spi_write_page(struct flashchip *flash, uint8_t * bytes,
 			      int offset, int maxdata);
-static int ich_spi_erase_block(struct flashchip *flash, int offset);
 
 OPCODES O_ST_M25P = {
 	{
@@ -449,20 +448,6 @@
 	return -1;
 }
 
-static int ich_spi_erase_block(struct flashchip *flash, int offset)
-{
-	printf_debug("ich_spi_erase_block: offset=%d, sectors=%d\n", offset, 1);
-
-	if (run_opcode(2, curopcodes->opcode[2], offset, 0, NULL) != 0) {
-		printf_debug("Error erasing sector at 0x%x", offset);
-		return -1;
-	}
-
-	printf("DONE BLOCK 0x%x\n", offset);
-
-	return 0;
-}
-
 static int ich_spi_read_page(struct flashchip *flash, uint8_t * buf, int offset,
 			     int maxdata)
 {
@@ -566,7 +551,11 @@
 	printf("Programming page: \n");
 
 	for (i = 0; i < total_size / erase_size; i++) {
-		rc = ich_spi_erase_block(flash, i * erase_size);
+		/* FIMXE: call the chip-specific spi_block_erase_XX instead.
+		 * For this, we need to add a block erase function to
+		 * struct flashchip.
+		 */
+		rc = spi_block_erase_d8(flash, i * erase_size);
 		if (rc) {
 			printf("Error erasing block at 0x%x\n", i);
 			break;


-- 
http://www.hailfinger.org/




From stepan at coresystems.de  Mon Nov  3 00:39:50 2008
From: stepan at coresystems.de (Stefan Reinauer)
Date: Mon, 03 Nov 2008 00:39:50 +0100
Subject: [coreboot] [PATCH] flashrom: More SPI erase functions
In-Reply-To: <490E3651.1030503@gmx.net>
References: <4897978C.10202@gmx.net> <490E3651.1030503@gmx.net>
Message-ID: <490E3A46.8010501@coresystems.de>

Carl-Daniel Hailfinger wrote:
> On 05.08.2008 01:58, Carl-Daniel Hailfinger wrote:
>   
>> As promised to Stefan, here's the flashrom patch I've been talking about.
>>
>> Add additional SPI sector erase and chip erase command functions to
>> flashrom. Not all chips support all commands, so allow the implementer
>> to select the matching function.
>> Fix a layering violation in ICH SPI code to be less bad. Still not
>> perfect, but the new code is shorter, more generic and architecturally
>> more sound.
>> TODO (in a separate patch):
>> - move the generic sector erase code to spi.c
>> - decide which erase command to use based on info about the chip
>> - create a generic spi_erase_all_sectors function which calls the
>> generic sector erase function
>>   
>>     
>
> Thanks to Stefan for reviewing and commenting. New patch follows.
>
> Regards,
> Carl-Daniel
>
> Signed-off-by: Carl-Daniel Hailfinger <c-d.hailfinger.devel.2006 at gmx.net>
Acked-by: Stefan Reinauer <stepan at coresystems.de>
> -	if (run_opcode(2, curopcodes->opcode[2], offset, 0, NULL) != 0) {
This won't apply cleanly with the version in the tree though, I dropped
the index thing as per our discussion earlier.

> -		rc = ich_spi_erase_block(flash, i * erase_size);
> +		/* FIMXE: call the chip-specific spi_block_erase_XX instead.
> +		 * For this, we need to add a block erase function to
> +		 * struct flashchip.
> +		 */
> +		rc = spi_block_erase_d8(flash, i * erase_size);

I agree with the observation. But I'm not sure what the struct flashchip
should look like.

When I wrote /dev/bios in 1998 I had both a page size (128-256 bytes for
example) and a block size (8-192k for example) and /dev/bios would try
to choose the appropriate function for your chip. Some chips have
non-linear block sizes, so I also added an array with the size of each
block. Plus a bitfield describing whether to use page size or block size
erases and writes.

So, for some random intel chip, the block sizes would look like this:

{ "28F001BX-T", 0x9489, 12,  128, 1, 128, 3, (int []) {
0,112,116,120,128 } },

For some ancient source code browsing fun go to
http://tracker.coreboot.org/trac/openbios/browser/openbios-devel/utils/devbios


-- 
coresystems GmbH ? Brahmsstr. 16 ? D-79104 Freiburg i. Br.
      Tel.: +49 761 7668825 ? Fax: +49 761 7664613
Email: info at coresystems.de  ? http://www.coresystems.de/
Registergericht: Amtsgericht Freiburg ? HRB 7656
Gesch?ftsf?hrer: Stefan Reinauer ? Ust-IdNr.: DE245674866




From peter at stuge.se  Mon Nov  3 00:47:15 2008
From: peter at stuge.se (Peter Stuge)
Date: Mon, 3 Nov 2008 00:47:15 +0100
Subject: [coreboot] r975 - in coreboot-v3: arch/x86
	mainboard/via	mainboard/via/epia-cn
In-Reply-To: <490E2FB2.50803@coresystems.de>
References: <490E2FB2.50803@coresystems.de>
Message-ID: <20081102234715.17705.qmail@stuge.se>

Stefan Reinauer wrote:
> >   coreboot-v3/mainboard/via/epia-cn/cmos.layout
> >Log:
> >no PIRQ table
> >Make cmos.layout work with incomprehensible tool -- just turn off 
> >checksums.
> 
> Which tool are you referring to?

v3 build was failing. I don't think this is the correct permanent fix
though.


//Peter



From peter at stuge.se  Mon Nov  3 00:50:05 2008
From: peter at stuge.se (Peter Stuge)
Date: Mon, 3 Nov 2008 00:50:05 +0100
Subject: [coreboot] coreboot.v2+seabios on 440bx: option roms not found
In-Reply-To: <20081101173703.GA32613@morn.localdomain>
References: <4909C3A9.2010704@icyb.net.ua>
	<20081101173703.GA32613@morn.localdomain>
Message-ID: <20081102235005.18305.qmail@stuge.se>

Kevin O'Connor wrote:
> I'd eventually like to add simple lar support so that SeaBIOS can
> pull option roms out of the lar on coreboot-v3.

There's some lar code in libpayload that you could use for this.


//Peter



From uwe at hermann-uwe.de  Mon Nov  3 01:00:39 2008
From: uwe at hermann-uwe.de (Uwe Hermann)
Date: Mon, 3 Nov 2008 01:00:39 +0100
Subject: [coreboot] Thoughts for call for help in Ubuntu forum
In-Reply-To: <490E2E07.8050107@coresystems.de>
References: <1225661215.4094.33.camel@mattotaupa.wohnung.familie-menzel.net>
	<4727185d0811021425o561a4f91v6286754abdb04a1e@mail.gmail.com>
	<490E2E07.8050107@coresystems.de>
Message-ID: <20081103000039.GC30535@greenwood>

On Sun, Nov 02, 2008 at 11:47:35PM +0100, Stefan Reinauer wrote:
> Vincent Legoll schrieb:
>> On Sun, Nov 2, 2008 at 10:26 PM, Paul Menzel wrote:
>>   
>>> lately some message came to the list in reaction to the post "You can
>>> help out Coreboot!" in the Ubuntu forums
>>>     
>>
>> Is that kind of flood really useful ?
>> Is someone using it to enhance coreboot ?
> I don't think so.

Agreed. Such info posts are only useful if

 (a) the northbridge/southbridge in question are already supported, and

 (b) the reporter donates the resp. hardware to some developer to work on, or

 (c) the reporter is willing and able to test patches on their board.


Uwe.
-- 
http://www.hermann-uwe.de  | http://www.holsham-traders.de
http://www.crazy-hacks.org | http://www.unmaintained-free-software.org



From svn at coreboot.org  Mon Nov  3 01:02:11 2008
From: svn at coreboot.org (svn at coreboot.org)
Date: Mon,  3 Nov 2008 01:02:11 +0100
Subject: [coreboot] r3722 - trunk/util/flashrom
Message-ID: <mailman.2374.1355071423.16123.coreboot@coreboot.org>

Author: hailfinger
Date: 2008-11-03 01:02:11 +0100 (Mon, 03 Nov 2008)
New Revision: 3722

Modified:
   trunk/util/flashrom/flash.h
   trunk/util/flashrom/ichspi.c
   trunk/util/flashrom/spi.c
Log:
Add additional SPI sector erase and chip erase command functions to
flashrom. Not all chips support all commands, so allow the implementer
to select the matching function.
Fix a layering violation in ICH SPI code to be less bad. Still not
perfect, but the new code is shorter, more generic and
architecturally
more sound.

TODO (in a separate patch):
- move the generic sector erase code to spi.c
- decide which erase command to use based on info about the chip
- create a generic spi_erase_all_sectors function which calls the
generic sector erase function
  
Thanks to Stefan for reviewing and commenting.

Signed-off-by: Carl-Daniel Hailfinger <c-d.hailfinger.devel.2006 at gmx.net>
Acked-by: Stefan Reinauer <stepan at coresystems.de>


Modified: trunk/util/flashrom/flash.h
===================================================================
--- trunk/util/flashrom/flash.h	2008-11-02 19:51:50 UTC (rev 3721)
+++ trunk/util/flashrom/flash.h	2008-11-03 00:02:11 UTC (rev 3722)
@@ -424,8 +424,11 @@
 		const unsigned char *writearr, unsigned char *readarr);
 void spi_write_enable();
 void spi_write_disable();
+int spi_chip_erase_60(struct flashchip *flash);
 int spi_chip_erase_c7(struct flashchip *flash);
 int spi_chip_erase_d8(struct flashchip *flash);
+int spi_block_erase_52(const struct flashchip *flash, unsigned long addr);
+int spi_block_erase_d8(const struct flashchip *flash, unsigned long addr);
 int spi_chip_write(struct flashchip *flash, uint8_t *buf);
 int spi_chip_read(struct flashchip *flash, uint8_t *buf);
 uint8_t spi_read_status_register();

Modified: trunk/util/flashrom/ichspi.c
===================================================================
--- trunk/util/flashrom/ichspi.c	2008-11-02 19:51:50 UTC (rev 3721)
+++ trunk/util/flashrom/ichspi.c	2008-11-03 00:02:11 UTC (rev 3722)
@@ -154,7 +154,6 @@
 			     int offset, int maxdata);
 static int ich_spi_write_page(struct flashchip *flash, uint8_t * bytes,
 			      int offset, int maxdata);
-static int ich_spi_erase_block(struct flashchip *flash, int offset);
 
 OPCODES O_ST_M25P = {
 	{
@@ -479,20 +478,6 @@
 	return -1;
 }
 
-static int ich_spi_erase_block(struct flashchip *flash, int offset)
-{
-	printf_debug("ich_spi_erase_block: offset=%d, sectors=%d\n", offset, 1);
-
-	if (run_opcode(curopcodes->opcode[2], offset, 0, NULL) != 0) {
-		printf_debug("Error erasing sector at 0x%x", offset);
-		return -1;
-	}
-
-	printf("DONE BLOCK 0x%x\n", offset);
-
-	return 0;
-}
-
 static int ich_spi_read_page(struct flashchip *flash, uint8_t * buf, int offset,
 			     int maxdata)
 {
@@ -596,7 +581,11 @@
 	printf("Programming page: \n");
 
 	for (i = 0; i < total_size / erase_size; i++) {
-		rc = ich_spi_erase_block(flash, i * erase_size);
+		/* FIMXE: call the chip-specific spi_block_erase_XX instead.
+		 * For this, we need to add a block erase function to
+		 * struct flashchip.
+		 */
+		rc = spi_block_erase_d8(flash, i * erase_size);
 		if (rc) {
 			printf("Error erasing block at 0x%x\n", i);
 			break;

Modified: trunk/util/flashrom/spi.c
===================================================================
--- trunk/util/flashrom/spi.c	2008-11-02 19:51:50 UTC (rev 3721)
+++ trunk/util/flashrom/spi.c	2008-11-03 00:02:11 UTC (rev 3722)
@@ -271,6 +271,22 @@
 	}
 }
 
+int spi_chip_erase_60(struct flashchip *flash)
+{
+	const unsigned char cmd[JEDEC_CE_60_OUTSIZE] = {JEDEC_CE_60};
+	
+	spi_disable_blockprotect();
+	spi_write_enable();
+	/* Send CE (Chip Erase) */
+	spi_command(sizeof(cmd), 0, cmd, NULL);
+	/* Wait until the Write-In-Progress bit is cleared.
+	 * This usually takes 1-85 s, so wait in 1 s steps.
+	 */
+	while (spi_read_status_register() & JEDEC_RDSR_BIT_WIP)
+		sleep(1);
+	return 0;
+}
+
 int spi_chip_erase_c7(struct flashchip *flash)
 {
 	const unsigned char cmd[JEDEC_CE_C7_OUTSIZE] = { JEDEC_CE_C7 };
@@ -287,6 +303,24 @@
 	return 0;
 }
 
+int spi_block_erase_52(const struct flashchip *flash, unsigned long addr)
+{
+	unsigned char cmd[JEDEC_BE_52_OUTSIZE] = {JEDEC_BE_52};
+
+	cmd[1] = (addr & 0x00ff0000) >> 16;
+	cmd[2] = (addr & 0x0000ff00) >> 8;
+	cmd[3] = (addr & 0x000000ff);
+	spi_write_enable();
+	/* Send BE (Block Erase) */
+	spi_command(sizeof(cmd), 0, cmd, NULL);
+	/* Wait until the Write-In-Progress bit is cleared.
+	 * This usually takes 100-4000 ms, so wait in 100 ms steps.
+	 */
+	while (spi_read_status_register() & JEDEC_RDSR_BIT_WIP)
+		usleep(100 * 1000);
+	return 0;
+}
+
 /* Block size is usually
  * 64k for Macronix
  * 32k for SST




From c-d.hailfinger.devel.2006 at gmx.net  Mon Nov  3 01:04:41 2008
From: c-d.hailfinger.devel.2006 at gmx.net (Carl-Daniel Hailfinger)
Date: Mon, 03 Nov 2008 01:04:41 +0100
Subject: [coreboot] [PATCH] flashrom: More SPI erase functions
In-Reply-To: <490E3A46.8010501@coresystems.de>
References: <4897978C.10202@gmx.net> <490E3651.1030503@gmx.net>
	<490E3A46.8010501@coresystems.de>
Message-ID: <490E4019.5000903@gmx.net>

On 03.11.2008 00:39, Stefan Reinauer wrote:
> Carl-Daniel Hailfinger wrote:
>   
>> On 05.08.2008 01:58, Carl-Daniel Hailfinger wrote:
>>   
>>     
>>> As promised to Stefan, here's the flashrom patch I've been talking about.
>>>
>>> Add additional SPI sector erase and chip erase command functions to
>>> flashrom. Not all chips support all commands, so allow the implementer
>>> to select the matching function.
>>> Fix a layering violation in ICH SPI code to be less bad. Still not
>>> perfect, but the new code is shorter, more generic and architecturally
>>> more sound.
>>> TODO (in a separate patch):
>>> - move the generic sector erase code to spi.c
>>> - decide which erase command to use based on info about the chip
>>> - create a generic spi_erase_all_sectors function which calls the
>>> generic sector erase function
>>>   
>>>     
>>>       
>> Thanks to Stefan for reviewing and commenting. New patch follows.
>>
>> Regards,
>> Carl-Daniel
>>
>> Signed-off-by: Carl-Daniel Hailfinger <c-d.hailfinger.devel.2006 at gmx.net>
>>     
> Acked-by: Stefan Reinauer <stepan at coresystems.de>
>   

Thanks, committed in r3722.


>> -	if (run_opcode(2, curopcodes->opcode[2], offset, 0, NULL) != 0) {
>>     
> This won't apply cleanly with the version in the tree though, I dropped
> the index thing as per our discussion earlier.
>   

Yes, I updated the patch.


>> -		rc = ich_spi_erase_block(flash, i * erase_size);
>> +		/* FIMXE: call the chip-specific spi_block_erase_XX instead.
>> +		 * For this, we need to add a block erase function to
>> +		 * struct flashchip.
>> +		 */
>> +		rc = spi_block_erase_d8(flash, i * erase_size);
>>     
>
> I agree with the observation. But I'm not sure what the struct flashchip
> should look like.
>
> When I wrote /dev/bios in 1998 I had both a page size (128-256 bytes for
> example) and a block size (8-192k for example) and /dev/bios would try
> to choose the appropriate function for your chip. Some chips have
> non-linear block sizes, so I also added an array with the size of each
> block. Plus a bitfield describing whether to use page size or block size
> erases and writes.
>
> So, for some random intel chip, the block sizes would look like this:
>
> { "28F001BX-T", 0x9489, 12,  128, 1, 128, 3, (int []) {
> 0,112,116,120,128 } },
>
> For some ancient source code browsing fun go to
> http://tracker.coreboot.org/trac/openbios/browser/openbios-devel/utils/devbios
>   

Let's continue the discussion about per-sector flashing in the existing
thread about it with subject
[coreboot] [RFC] flashrom: sector-based flashing

Regards,
Carl-Daniel

-- 
http://www.hailfinger.org/




From c-d.hailfinger.devel.2006 at gmx.net  Mon Nov  3 01:14:42 2008
From: c-d.hailfinger.devel.2006 at gmx.net (Carl-Daniel Hailfinger)
Date: Mon, 03 Nov 2008 01:14:42 +0100
Subject: [coreboot] [PATCH] flashrom: Dump ICH9 SPI registers
Message-ID: <490E4272.4060409@gmx.net>

Dump ICH9 SPI registers in flashrom. This helps a lot if we have to
track down configuration weirdnesses.

Signed-off-by: Carl-Daniel Hailfinger <c-d.hailfinger.devel.2006 at gmx.net>

Index: flashrom-ich9/chipset_enable.c
===================================================================
--- flashrom-ich9/chipset_enable.c	(Revision 3698)
+++ flashrom-ich9/chipset_enable.c	(Arbeitskopie)
@@ -232,9 +232,11 @@
 {
 	int ret, i;
 	uint8_t old, new, bbs, buc;
-	uint16_t spibar_offset;
+	uint16_t spibar_offset, tmp2;
 	uint32_t tmp, gcs;
 	void *rcrb;
+	//TODO: These names are incorrect for EP80579. For that, the solution would look like the commented line
+	//static const char *straps_names[] = {"SPI", "reserved", "reserved", "LPC" };
 	static const char *straps_names[] = { "reserved", "SPI", "PCI", "LPC" };
 
 	/* Enable Flash Writes */
@@ -334,10 +336,48 @@
 		}
 		break;
 	case BUS_TYPE_ICH9_SPI:
-		/* TODO: Add dumping function for ICH8/ICH9, or drop the 
-		 * whole SPIBAR dumping from chipset_enable.c - There's 
-		 * inteltool for this task already.
-		 */
+		tmp2 = *(uint16_t *) (spibar + 0);
+		printf_debug("0x00: 0x%04x (HSFS)\n", tmp2);
+		printf_debug("FLOCKDN %i, ", (tmp >> 15 & 1));
+		printf_debug("FDV %i, ", (tmp >> 14) & 1);
+		printf_debug("FDOPSS %i, ", (tmp >> 13) & 1);
+		printf_debug("SCIP %i, ", (tmp >> 5) & 1);
+		printf_debug("BERASE %i, ", (tmp >> 3) & 3);
+		printf_debug("AEL %i, ", (tmp >> 2) & 1);
+		printf_debug("FCERR %i, ", (tmp >> 1) & 1);
+		printf_debug("FDONE %i\n", (tmp >> 0) & 1);
+
+		tmp = *(uint32_t *) (spibar + 0x50);
+		printf_debug("0x50: 0x%08x (FRAP)\n", tmp);
+		printf_debug("BMWAG %i, ", (tmp >> 24) & 0xff);
+		printf_debug("BMRAG %i, ", (tmp >> 16) & 0xff);
+		printf_debug("BRWA %i, ", (tmp >> 8) & 0xff);
+		printf_debug("BRRA %i\n", (tmp >> 0) & 0xff);
+
+		printf_debug("0x54: 0x%08x (FREG0)\n",
+			     *(uint32_t *) (spibar + 0x54));
+		printf_debug("0x58: 0x%08x (FREG1)\n",
+			     *(uint32_t *) (spibar + 0x58));
+		printf_debug("0x5C: 0x%08x (FREG2)\n",
+			     *(uint32_t *) (spibar + 0x5C));
+		printf_debug("0x60: 0x%08x (FREG3)\n",
+			     *(uint32_t *) (spibar + 0x60));
+		printf_debug("0x64: 0x%08x (FREG4)\n",
+			     *(uint32_t *) (spibar + 0x64));
+		printf_debug("0x74: 0x%08x (PR0)\n",
+			     *(uint32_t *) (spibar + 0x74));
+		printf_debug("0x78: 0x%08x (PR1)\n",
+			     *(uint32_t *) (spibar + 0x78));
+		printf_debug("0x7C: 0x%08x (PR2)\n",
+			     *(uint32_t *) (spibar + 0x7C));
+		printf_debug("0x80: 0x%08x (PR3)\n",
+			     *(uint32_t *) (spibar + 0x80));
+		printf_debug("0x84: 0x%08x (PR4)\n",
+			     *(uint32_t *) (spibar + 0x84));
+		/* printf_debug("0xA0: 0x%08x (BBAR)\n",
+			     *(uint32_t *) (spibar + 0xA0)); ICH10 only? */
+		printf_debug("0xB0: 0x%08x (FDOC)\n",
+			     *(uint32_t *) (spibar + 0xB0));
 		break;
 	default:
 		/* Nothing */


-- 
http://www.hailfinger.org/




From svn at coreboot.org  Mon Nov  3 01:20:23 2008
From: svn at coreboot.org (svn at coreboot.org)
Date: Mon,  3 Nov 2008 01:20:23 +0100
Subject: [coreboot] r3723 - trunk/util/flashrom
Message-ID: <mailman.2375.1355071423.16123.coreboot@coreboot.org>

Author: hailfinger
Date: 2008-11-03 01:20:22 +0100 (Mon, 03 Nov 2008)
New Revision: 3723

Modified:
   trunk/util/flashrom/chipset_enable.c
Log:
Dump ICH8/ICH9/ICH10 SPI registers in flashrom.
This helps a lot if we have to track down configuration weirdnesses.

Signed-off-by: Carl-Daniel Hailfinger <c-d.hailfinger.devel.2006 at gmx.net>
Acked-by: Stefan Reinauer <stepan at coresystems.de>


Modified: trunk/util/flashrom/chipset_enable.c
===================================================================
--- trunk/util/flashrom/chipset_enable.c	2008-11-03 00:02:11 UTC (rev 3722)
+++ trunk/util/flashrom/chipset_enable.c	2008-11-03 00:20:22 UTC (rev 3723)
@@ -232,9 +232,11 @@
 {
 	int ret, i;
 	uint8_t old, new, bbs, buc;
-	uint16_t spibar_offset;
+	uint16_t spibar_offset, tmp2;
 	uint32_t tmp, gcs;
 	void *rcrb;
+	//TODO: These names are incorrect for EP80579. For that, the solution would look like the commented line
+	//static const char *straps_names[] = {"SPI", "reserved", "reserved", "LPC" };
 	static const char *straps_names[] = { "reserved", "SPI", "PCI", "LPC" };
 
 	/* Enable Flash Writes */
@@ -334,10 +336,48 @@
 		}
 		break;
 	case BUS_TYPE_ICH9_SPI:
-		/* TODO: Add dumping function for ICH8/ICH9, or drop the 
-		 * whole SPIBAR dumping from chipset_enable.c - There's 
-		 * inteltool for this task already.
-		 */
+		tmp2 = *(uint16_t *) (spibar + 0);
+		printf_debug("0x00: 0x%04x (HSFS)\n", tmp2);
+		printf_debug("FLOCKDN %i, ", (tmp >> 15 & 1));
+		printf_debug("FDV %i, ", (tmp >> 14) & 1);
+		printf_debug("FDOPSS %i, ", (tmp >> 13) & 1);
+		printf_debug("SCIP %i, ", (tmp >> 5) & 1);
+		printf_debug("BERASE %i, ", (tmp >> 3) & 3);
+		printf_debug("AEL %i, ", (tmp >> 2) & 1);
+		printf_debug("FCERR %i, ", (tmp >> 1) & 1);
+		printf_debug("FDONE %i\n", (tmp >> 0) & 1);
+
+		tmp = *(uint32_t *) (spibar + 0x50);
+		printf_debug("0x50: 0x%08x (FRAP)\n", tmp);
+		printf_debug("BMWAG %i, ", (tmp >> 24) & 0xff);
+		printf_debug("BMRAG %i, ", (tmp >> 16) & 0xff);
+		printf_debug("BRWA %i, ", (tmp >> 8) & 0xff);
+		printf_debug("BRRA %i\n", (tmp >> 0) & 0xff);
+
+		printf_debug("0x54: 0x%08x (FREG0)\n",
+			     *(uint32_t *) (spibar + 0x54));
+		printf_debug("0x58: 0x%08x (FREG1)\n",
+			     *(uint32_t *) (spibar + 0x58));
+		printf_debug("0x5C: 0x%08x (FREG2)\n",
+			     *(uint32_t *) (spibar + 0x5C));
+		printf_debug("0x60: 0x%08x (FREG3)\n",
+			     *(uint32_t *) (spibar + 0x60));
+		printf_debug("0x64: 0x%08x (FREG4)\n",
+			     *(uint32_t *) (spibar + 0x64));
+		printf_debug("0x74: 0x%08x (PR0)\n",
+			     *(uint32_t *) (spibar + 0x74));
+		printf_debug("0x78: 0x%08x (PR1)\n",
+			     *(uint32_t *) (spibar + 0x78));
+		printf_debug("0x7C: 0x%08x (PR2)\n",
+			     *(uint32_t *) (spibar + 0x7C));
+		printf_debug("0x80: 0x%08x (PR3)\n",
+			     *(uint32_t *) (spibar + 0x80));
+		printf_debug("0x84: 0x%08x (PR4)\n",
+			     *(uint32_t *) (spibar + 0x84));
+		/* printf_debug("0xA0: 0x%08x (BBAR)\n",
+			     *(uint32_t *) (spibar + 0xA0)); ICH10 only? */
+		printf_debug("0xB0: 0x%08x (FDOC)\n",
+			     *(uint32_t *) (spibar + 0xB0));
 		break;
 	default:
 		/* Nothing */




From c-d.hailfinger.devel.2006 at gmx.net  Mon Nov  3 01:20:46 2008
From: c-d.hailfinger.devel.2006 at gmx.net (Carl-Daniel Hailfinger)
Date: Mon, 03 Nov 2008 01:20:46 +0100
Subject: [coreboot] [PATCH] flashrom: Dump ICH9 SPI registers
In-Reply-To: <490E4272.4060409@gmx.net>
References: <490E4272.4060409@gmx.net>
Message-ID: <490E43DE.3070304@gmx.net>

On 03.11.2008 01:14, Carl-Daniel Hailfinger wrote:
> Dump ICH8/ICH9/ICH10 SPI registers in flashrom. This helps a lot if we have to
> track down configuration weirdnesses.
>
> Signed-off-by: Carl-Daniel Hailfinger <c-d.hailfinger.devel.2006 at gmx.net>
>   

Thanks to Stefan for the speedy ack!
Acked-by: Stefan Reinauer <stepan at coresystems.de>

Committed in r3723.

Regards,
Carl-Daniel

-- 
http://www.hailfinger.org/




From peter at stuge.se  Mon Nov  3 01:35:48 2008
From: peter at stuge.se (Peter Stuge)
Date: Mon, 3 Nov 2008 01:35:48 +0100
Subject: [coreboot] r3723 - trunk/util/flashrom
Message-ID: <20081103003548.31173.qmail@stuge.se>

svn at coreboot.org wrote:
> +++ trunk/util/flashrom/chipset_enable.c	2008-11-03 00:20:22 UTC (rev 3723)
..
>  	case BUS_TYPE_ICH9_SPI:
> -		/* TODO: Add dumping function for ICH8/ICH9, or drop the 
> -		 * whole SPIBAR dumping from chipset_enable.c - There's 
> -		 * inteltool for this task already.
> -		 */
> +		tmp2 = *(uint16_t *) (spibar + 0);
> +		printf_debug("0x00: 0x%04x (HSFS)\n", tmp2);
> +		printf_debug("FLOCKDN %i, ", (tmp >> 15 & 1));
> +		printf_debug("FDV %i, ", (tmp >> 14) & 1);
> +		printf_debug("FDOPSS %i, ", (tmp >> 13) & 1);

Would have been nice if this had gone into ichspi.c.


//Peter



From info at coresystems.de  Mon Nov  3 01:36:46 2008
From: info at coresystems.de (coreboot information)
Date: Mon, 03 Nov 2008 01:36:46 +0100
Subject: [coreboot] r3723 build service
Message-ID: <E1KwnR0-0005k2-39@ra.coresystems.de>

Dear coreboot readers!

This is the automated build check service of coreboot.

The developer "hailfinger" checked in revision 3723 to
the coreboot source repository and caused the following 
changes:

Change Log:
Dump ICH8/ICH9/ICH10 SPI registers in flashrom.
This helps a lot if we have to track down configuration weirdnesses.

Signed-off-by: Carl-Daniel Hailfinger <c-d.hailfinger.devel.2006 at gmx.net>
Acked-by: Stefan Reinauer <stepan at coresystems.de>


Build Log:
Compilation of bcom:winnetp680 has been broken
See the error log at http://qa.coreboot.org/log_buildbrd.php?revision=3723&device=winnetp680&vendor=bcom


If something broke during this checkin please be a pain 
in hailfinger's neck until the issue is fixed.

If this issue is not fixed within 24h the revision should 
be backed out.

   Best regards,
     coreboot automatic build system





From c-d.hailfinger.devel.2006 at gmx.net  Mon Nov  3 01:56:19 2008
From: c-d.hailfinger.devel.2006 at gmx.net (Carl-Daniel Hailfinger)
Date: Mon, 03 Nov 2008 01:56:19 +0100
Subject: [coreboot] [PATCH] flashrom: Add support for 8 new chips,
 fix up 2 existing chips
Message-ID: <490E4C33.2020709@gmx.net>

Add support for 8 new chips to flashrom and fix up 2 existing chips as well.
Replace age-old TODO comments with real explanations.

Fixed chips:
Fujitsu MBM29F400TC (ID definition)
Macronix MX29F002T (chip name)

New chips:
Fujitsu MBM29F004BC
Fujitsu MBM29F004TC
Fujitsu MBM29F400BC
Macronix MX25L512
Macronix MX25L1005
Macronix MX25L2005
Macronix MX25L6405
Macronix MX29F002B

Straight from the data sheets, compile tested only.

Signed-off-by: Carl-Daniel Hailfinger <c-d.hailfinger.devel.2006 at gmx.net>

Index: flashrom-newchips/flash.h
===================================================================
--- flashrom-newchips/flash.h	(Revision 3723)
+++ flashrom-newchips/flash.h	(Arbeitskopie)
@@ -181,13 +181,10 @@
 #define EN_29F002B		0x7F97
 
 #define FUJITSU_ID		0x04	/* Fujitsu */
-/*
- * MBM29F400TC_STRANGE has a value not mentioned in the data sheet and we
- * try to read it from a location not mentioned in the data sheet.
- */
-#define MBM29F400TC_STRANGE	0x23
-#define MBM29F400BC		0x7B
-#define MBM29F400TC		0x77
+#define MBM29F400BC		0xAB
+#define MBM29F400TC		0x23
+#define MBM29F004BC		0x7B
+#define MBM29F004TC		0x77
 
 #define HYUNDAI_ID		0xAD	/* Hyundai */
 
@@ -216,7 +213,8 @@
 #define MX_25L6405		0x2017	/* MX25L3205{,D} */
 #define MX_25L1635D		0x2415
 #define MX_25L3235D		0x2416
-#define MX_29F002		0xB0
+#define MX_29F002B		0x34
+#define MX_29F002T		0xB0
 
 /*
  * Programmable Micro Corp is listed in JEP106W in bank 2, so it should
Index: flashrom-newchips/flashchips.c
===================================================================
--- flashrom-newchips/flashchips.c	(Revision 3723)
+++ flashrom-newchips/flashchips.c	(Arbeitskopie)
@@ -30,7 +30,7 @@
  */
 struct flashchip flashchips[] = {
 	/**********************************************************************************************************************************************************************************************************************/
-	/* Vendor	Chip			Vendor ID	Chip ID			TODO	TODO		Test status	Probe function		Erase function			Write function		Read function */
+	/* Vendor	Chip			Vendor ID	Chip ID		Total size (kB)	Page size (B)	Test status	Probe function		Erase function			Write function		Read function */
 	/**********************************************************************************************************************************************************************************************************************/
 	{"AMD",		"Am29F002(N)BB",	AMD_ID,		AM_29F002BB,		256,	256,		TEST_UNTESTED,	probe_jedec,		erase_chip_jedec,		write_en29f002a},
 	{"AMD",		"Am29F002(N)BT",	AMD_ID,		AM_29F002BT,		256,	256,		TEST_OK_PREW,	probe_jedec,		erase_chip_jedec,		write_en29f002a},
@@ -51,14 +51,22 @@
 	{"EMST",	"F49B002UA",		EMST_ID,	EMST_F49B002UA,		256,	4096,		TEST_UNTESTED,	probe_jedec,		erase_chip_jedec,		write_49f002},
 	{"EON",		"EN29F002(A)(N)B",	EON_ID,		EN_29F002B,		256,	256,		TEST_UNTESTED,	probe_jedec,		erase_chip_jedec,		write_en29f002a},
 	{"EON",		"EN29F002(A)(N)T",	EON_ID,		EN_29F002T,		256,	256,		TEST_OK_PREW,	probe_jedec,		erase_chip_jedec,		write_en29f002a},
-	{"Fujitsu",	"MBM29F400TC",		FUJITSU_ID,	MBM29F400TC_STRANGE,	512,	64 * 1024,	TEST_UNTESTED,	probe_m29f400bt,	erase_m29f400bt,		write_coreboot_m29f400bt},
+	{"Fujitsu",	"MBM29F004BC",		FUJITSU_ID,	MBM29F004BC,		512,	64 * 1024,	TEST_UNTESTED,	probe_jedec,		NULL,			NULL},
+	{"Fujitsu",	"MBM29F004TC",		FUJITSU_ID,	MBM29F004TC,		512,	64 * 1024,	TEST_UNTESTED,	probe_jedec,		NULL,			NULL},
+	{"Fujitsu",	"MBM29F400BC",		FUJITSU_ID,	MBM29F400BC,		512,	64 * 1024,	TEST_UNTESTED,	probe_m29f400bt,	erase_m29f400bt,		write_coreboot_m29f400bt},
+	{"Fujitsu",	"MBM29F400TC",		FUJITSU_ID,	MBM29F400TC,		512,	64 * 1024,	TEST_UNTESTED,	probe_m29f400bt,	erase_m29f400bt,		write_coreboot_m29f400bt},
 	{"Intel",	"82802AB",		INTEL_ID,	173,			512,	64 * 1024,	TEST_OK_PREW,	probe_82802ab,		erase_82802ab,			write_82802ab},
 	{"Intel",	"82802AC",		INTEL_ID,	172,			1024,	64 * 1024,	TEST_OK_PREW,	probe_82802ab,		erase_82802ab,			write_82802ab},
+	{"Macronix",	"MX25L512",		MX_ID,		MX_25L512,		64,	256,		TEST_UNTESTED,	probe_spi_rdid,		spi_chip_erase_c7,	spi_chip_write,	spi_chip_read},
+	{"Macronix",	"MX25L1005",		MX_ID,		MX_25L1005,		128,	256,		TEST_UNTESTED,	probe_spi_rdid,		spi_chip_erase_c7,	spi_chip_write,	spi_chip_read},
+	{"Macronix",	"MX25L2005",		MX_ID,		MX_25L2005,		256,	256,		TEST_UNTESTED,	probe_spi_rdid,		spi_chip_erase_c7,	spi_chip_write,	spi_chip_read},
 	{"Macronix",	"MX25L4005",		MX_ID,		MX_25L4005,		512,	256,		TEST_OK_PREW,	probe_spi_rdid,		spi_chip_erase_c7,	spi_chip_write,	spi_chip_read},
 	{"Macronix",	"MX25L8005",		MX_ID,		MX_25L8005,		1024,	256,		TEST_OK_PREW,	probe_spi_rdid,		spi_chip_erase_c7,	spi_chip_write,	spi_chip_read},
 	{"Macronix",	"MX25L1605",		MX_ID,		MX_25L1605,		2048,	256,		TEST_UNTESTED,	probe_spi_rdid,		spi_chip_erase_c7,	spi_chip_write,	spi_chip_read},
 	{"Macronix",	"MX25L3205",		MX_ID,		MX_25L3205,		4096,	256,		TEST_OK_PREW,	probe_spi_rdid,		spi_chip_erase_c7,	spi_chip_write,	spi_chip_read},
-	{"Macronix",	"MX29F002",		MX_ID,		MX_29F002,		256,	64 * 1024,	TEST_UNTESTED,	probe_29f002,		erase_29f002,			write_29f002},
+	{"Macronix",	"MX25L6405",		MX_ID,		MX_25L6405,		8192,	256,		TEST_UNTESTED,	probe_spi_rdid,		spi_chip_erase_c7,	spi_chip_write,	spi_chip_read},
+	{"Macronix",	"MX29F002B",		MX_ID,		MX_29F002B,		256,	64 * 1024,	TEST_UNTESTED,	probe_29f002,		erase_29f002,			write_29f002},
+	{"Macronix",	"MX29F002T",		MX_ID,		MX_29F002T,		256,	64 * 1024,	TEST_UNTESTED,	probe_29f002,		erase_29f002,			write_29f002},
 	{"Numonyx",	"M25PE10",		ST_ID,		0x8011,			128,	256,		TEST_UNTESTED,	probe_spi_rdid,		spi_chip_erase_d8,	spi_chip_write, spi_chip_read},
 	{"Numonyx",	"M25PE20",		ST_ID,		0x8012,			256,	256,		TEST_UNTESTED,	probe_spi_rdid,		spi_chip_erase_d8,	spi_chip_write, spi_chip_read},
 	{"Numonyx",	"M25PE40",		ST_ID,		0x8013,			256,	256,		TEST_UNTESTED,	probe_spi_rdid,		spi_chip_erase_d8,	spi_chip_write, spi_chip_read},
@@ -140,7 +148,7 @@
 	{"Winbond",	"W29EE011",		WINBOND_ID,	W_29C011,		128,	128,		TEST_OK_PREW,	probe_w29ee011,		erase_chip_jedec,		write_jedec},
 	{"Winbond",	"W39V040A",		WINBOND_ID,	W_39V040A,		512,	64*1024,	TEST_UNTESTED,	probe_jedec,		erase_chip_jedec,		write_39sf020},
 	{"Winbond",	"W39V040B",		WINBOND_ID,	W_39V040B,		512,	64*1024,	TEST_OK_PREW,	probe_jedec,		erase_chip_jedec,		write_39sf020},
-	{"Winbond",	"W39V040C",		0xda,		0x50,			512,	64*1024,	TEST_OK_PREW,	probe_w39v040c,		erase_w39v040c,			write_w39v040c},
+	{"Winbond",	"W39V040C",		WINBOND_ID,	0x50,			512,	64*1024,	TEST_OK_PREW,	probe_w39v040c,		erase_w39v040c,			write_w39v040c},
 	{"Winbond",	"W39V040FA",		WINBOND_ID,	W_39V040FA,		512,	64*1024,	TEST_OK_PREW,	probe_jedec,		erase_chip_jedec,		write_39sf020},
 	{"Winbond",	"W39V080A",		WINBOND_ID,	W_39V080A,		1024,	64*1024,	TEST_OK_PREW,	probe_jedec,		erase_chip_jedec,		write_39sf020},
 	{"Winbond",	"W49F002U",		WINBOND_ID,	W_49F002U,		256,	128,		TEST_OK_PREW,	probe_jedec,		erase_chip_jedec,		write_49f002},


-- 
http://www.hailfinger.org/




From peter at stuge.se  Mon Nov  3 02:24:13 2008
From: peter at stuge.se (Peter Stuge)
Date: Mon, 3 Nov 2008 02:24:13 +0100
Subject: [coreboot] [PATCH] flashrom: Add support for 8 new chips,
	fix up 2 existing chips
In-Reply-To: <490E4C33.2020709@gmx.net>
References: <490E4C33.2020709@gmx.net>
Message-ID: <20081103012413.8599.qmail@stuge.se>

Carl-Daniel Hailfinger wrote:
> +#define MX_29F002B		0x34
> +#define MX_29F002T		0xB0

Yeah. Please don't do this. Put them in the struct.


> -	{"Winbond",	"W39V040C",		0xda,		0x50,			512,	64*1024,	TEST_OK_PREW,	probe_w39v040c,		erase_w39v040c,			write_w39v040c},
> +	{"Winbond",	"W39V040C",		WINBOND_ID,	0x50,			512,	64*1024,	TEST_OK_PREW,	probe_w39v040c,		erase_w39v040c,			write_w39v040c},

..


//Peter



From rminnich at gmail.com  Mon Nov  3 04:34:43 2008
From: rminnich at gmail.com (ron minnich)
Date: Sun, 2 Nov 2008 20:34:43 -0700
Subject: [coreboot] patch: fix up epia-cn PIRQ
Message-ID: <13426df10811021934q6859b350hed372922e6082fda@mail.gmail.com>

attached.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: epia-cn-pirq.diff
Type: text/x-patch
Size: 3403 bytes
Desc: not available
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20081102/76e820b0/attachment.diff>

From bari at onelabs.com  Mon Nov  3 05:04:29 2008
From: bari at onelabs.com (bari)
Date: Sun, 02 Nov 2008 22:04:29 -0600
Subject: [coreboot] patch: fix up epia-cn PIRQ
In-Reply-To: <13426df10811021934q6859b350hed372922e6082fda@mail.gmail.com>
References: <13426df10811021934q6859b350hed372922e6082fda@mail.gmail.com>
Message-ID: <490E784D.7070409@onelabs.com>

ron minnich wrote:
> attached.
>   
> ------------------------------------------------------------------------
>
> --
> coreboot mailing list: coreboot at coreboot.org
> http://www.coreboot.org/mailman/listinfo/coreboot
Acked-by: Bari Ari <bari at onelabs.com>



From svn at coreboot.org  Mon Nov  3 05:08:36 2008
From: svn at coreboot.org (svn at coreboot.org)
Date: Mon,  3 Nov 2008 05:08:36 +0100
Subject: [coreboot] r3724 - trunk/coreboot-v2/src/mainboard/via/epia-cn
Message-ID: <mailman.2376.1355071423.16123.coreboot@coreboot.org>

Author: rminnich
Date: 2008-11-03 05:08:35 +0100 (Mon, 03 Nov 2008)
New Revision: 3724

Modified:
   trunk/coreboot-v2/src/mainboard/via/epia-cn/Options.lb
   trunk/coreboot-v2/src/mainboard/via/epia-cn/irq_tables.c
Log:
modify pirq tables for epia-cn.

Not tested, builds, derived from getpir. Definitely better than what was there. 

Signed-off-by: Ronald G. Minnich <rminnich at gmail.com>
Acked-by: Bari Ari <bari at onelabs.com>


Modified: trunk/coreboot-v2/src/mainboard/via/epia-cn/Options.lb
===================================================================
--- trunk/coreboot-v2/src/mainboard/via/epia-cn/Options.lb	2008-11-03 00:20:22 UTC (rev 3723)
+++ trunk/coreboot-v2/src/mainboard/via/epia-cn/Options.lb	2008-11-03 04:08:35 UTC (rev 3724)
@@ -81,7 +81,7 @@
 default CONFIG_TSC_X86RDTSC_CALIBRATE_WITH_TIMER2 = 1
 default HAVE_HARD_RESET = 0
 default HAVE_PIRQ_TABLE = 1
-default IRQ_SLOT_COUNT = 10
+default IRQ_SLOT_COUNT = 9
 default HAVE_ACPI_TABLES = 0
 default HAVE_OPTION_TABLE = 1
 default ROM_IMAGE_SIZE = 64 * 1024

Modified: trunk/coreboot-v2/src/mainboard/via/epia-cn/irq_tables.c
===================================================================
--- trunk/coreboot-v2/src/mainboard/via/epia-cn/irq_tables.c	2008-11-03 00:20:22 UTC (rev 3723)
+++ trunk/coreboot-v2/src/mainboard/via/epia-cn/irq_tables.c	2008-11-03 04:08:35 UTC (rev 3724)
@@ -27,24 +27,23 @@
 	32 + 16 * IRQ_SLOT_COUNT,/* Max. number of devices on the bus */
 	0x00,			/* Interrupt router bus */
 	(0x11 << 3) | 0x0,	/* Interrupt router device */
-	0x828,			/* IRQs devoted exclusively to PCI usage */
+	0xc20,			/* IRQs devoted exclusively to PCI usage */
 	0x1106,			/* Vendor */
 	0x596,			/* Device */
 	0,			/* Crap (miniport) */
 	{ 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0 }, /* u8 rfu[11] */
-	0x3e,			/* Checksum */
+	0x66,			/* Checksum */
 	{
 		/* bus,     dev|fn,   {link, bitmap}, {link, bitmap}, {link, bitmap}, {link, bitmap},  slot, rfu */
-		{0x00,(0x08<<3)|0x0, {{0x01, 0xdef8}, {0x02, 0xdef8}, {0x03, 0xdef8}, {0x05, 0x0def8}}, 0x1, 0x0},
-		{0x00,(0x09<<3)|0x0, {{0x02, 0xdef8}, {0x03, 0xdef8}, {0x05, 0xdef8}, {0x01, 0x0def8}}, 0x2, 0x0},
-		{0x00,(0x0a<<3)|0x0, {{0x03, 0xdef8}, {0x05, 0xdef8}, {0x01, 0xdef8}, {0x02, 0x0def8}}, 0x3, 0x0},
-		{0x00,(0x0b<<3)|0x0, {{0x05, 0xdef8}, {0x01, 0xdef8}, {0x02, 0xdef8}, {0x03, 0x0def8}}, 0x4, 0x0},
-		{0x00,(0x0c<<3)|0x0, {{0x01, 0xdef8}, {0x02, 0xdef8}, {0x03, 0xdef8}, {0x05, 0x0def8}}, 0x5, 0x0},
-		{0x00,(0x11<<3)|0x0, {{0x00, 0xdef8}, {0x00, 0xdef8}, {0x03, 0xdef8}, {0x05, 0x0def8}}, 0x0, 0x0},
-		{0x00,(0x0f<<3)|0x0, {{0x01, 0xdef8}, {0x02, 0xdef8}, {0x03, 0xdef8}, {0x05, 0x0def8}}, 0x0, 0x0},
-		{0x00,(0x01<<3)|0x0, {{0x01, 0xdef8}, {0x02, 0xdef8}, {0x03, 0xdef8}, {0x05, 0x0def8}}, 0x0, 0x0},
-		{0x00,(0x10<<3)|0x0, {{0x01, 0xdef8}, {0x02, 0xdef8}, {0x03, 0xdef8}, {0x05, 0x0def8}}, 0x0, 0x0},
-		{0x00,(0x12<<3)|0x0, {{0x01, 0xdef8}, {0x00, 0xdef8}, {0x00, 0xdef8}, {0x00, 0x0def8}}, 0x0, 0x0},
+		{0x00,(0x14<<3)|0x0, {{0x02, 0xdeb8}, {0x03, 0xdeb8}, {0x05, 0xdeb8}, {0x01, 0x0deb8}}, 0x1, 0x0},
+		{0x00,(0x0d<<3)|0x0, {{0x02, 0xdeb8}, {0x03, 0xdeb8}, {0x05, 0xdeb8}, {0x01, 0x0deb8}}, 0x2, 0x0},
+		{0x00,(0x0e<<3)|0x0, {{0x03, 0xdeb8}, {0x05, 0xdeb8}, {0x01, 0xdeb8}, {0x02, 0x0deb8}}, 0x3, 0x0},
+		{0x00,(0x13<<3)|0x0, {{0x01, 0xdeb8}, {0x02, 0xdeb8}, {0x03, 0xdeb8}, {0x05, 0x0deb8}}, 0x4, 0x0},
+		{0x00,(0x11<<3)|0x0, {{0x00, 0xdeb8}, {0x00, 0xdeb8}, {0x03, 0xdeb8}, {0x05, 0x0deb8}}, 0x0, 0x0},
+		{0x00,(0x0f<<3)|0x0, {{0x01, 0xdeb8}, {0x02, 0xdeb8}, {0x03, 0xdeb8}, {0x05, 0x0deb8}}, 0x0, 0x0},
+		{0x00,(0x01<<3)|0x0, {{0x01, 0xdeb8}, {0x02, 0xdeb8}, {0x03, 0xdeb8}, {0x05, 0x0deb8}}, 0x0, 0x0},
+		{0x00,(0x10<<3)|0x0, {{0x01, 0xdeb8}, {0x02, 0xdeb8}, {0x03, 0xdeb8}, {0x05, 0x0deb8}}, 0x0, 0x0},
+		{0x00,(0x12<<3)|0x0, {{0x01, 0xdeb8}, {0x00, 0xdeb8}, {0x00, 0xdeb8}, {0x00, 0x0deb8}}, 0x0, 0x0},
 	}
 };
 




From info at coresystems.de  Mon Nov  3 05:25:08 2008
From: info at coresystems.de (coreboot information)
Date: Mon, 03 Nov 2008 05:25:08 +0100
Subject: [coreboot] r3724 build service
Message-ID: <E1Kwr00-000854-Vu@ra.coresystems.de>

Dear coreboot readers!

This is the automated build check service of coreboot.

The developer "rminnich" checked in revision 3724 to
the coreboot source repository and caused the following 
changes:

Change Log:
modify pirq tables for epia-cn.

Not tested, builds, derived from getpir. Definitely better than what was there.

Signed-off-by: Ronald G. Minnich <rminnich at gmail.com>
Acked-by: Bari Ari <bari at onelabs.com>


Build Log:
Compilation of bcom:winnetp680 has been fixed


If something broke during this checkin please be a pain 
in rminnich's neck until the issue is fixed.

If this issue is not fixed within 24h the revision should 
be backed out.

   Best regards,
     coreboot automatic build system





From stuff2save at gmail.com  Mon Nov  3 06:06:36 2008
From: stuff2save at gmail.com (J)
Date: Mon, 3 Nov 2008 00:06:36 -0500
Subject: [coreboot] Supermicro PDSMI+ motherboard
Message-ID: <7fd6036c0811022106x5b04ed88y850812adc950613a@mail.gmail.com>

Hello, Coreboot,
I have a cluster of servers which might benefit from corebios.
However, it seems the motherboard hasn't been tried yet, and the only
chip I found a reference to in the "supported"  tables was the
superI/O.  Any chance the list trails the development and I'm lucky?

Motherboard - Supermicro PDSMi+
CPU - Intel Xeon dual core
Northbridge - Intel 3000
Southbridge - Intel ICH7R
Super I/O Winbond 83627HG
Adaptec HostRaid
lspci output:

/coreboot# cat lspciout
00:00.0 Host bridge: Intel Corporation E7230/3000/3010 Memory
Controller Hub (rev c0)
00:01.0 PCI bridge: Intel Corporation E7230/3000/3010 PCI Express Root
Port (rev c0)
00:1c.0 PCI bridge: Intel Corporation 82801G (ICH7 Family) PCI Express
Port 1 (rev 01)
00:1c.4 PCI bridge: Intel Corporation 82801GR/GH/GHM (ICH7 Family) PCI
Express Port 5 (rev 01)
00:1c.5 PCI bridge: Intel Corporation 82801GR/GH/GHM (ICH7 Family) PCI
Express Port 6 (rev 01)
00:1d.0 USB Controller: Intel Corporation 82801G (ICH7 Family) USB
UHCI Controller #1 (rev 01)
00:1d.1 USB Controller: Intel Corporation 82801G (ICH7 Family) USB
UHCI Controller #2 (rev 01)
00:1d.2 USB Controller: Intel Corporation 82801G (ICH7 Family) USB
UHCI Controller #3 (rev 01)
00:1d.3 USB Controller: Intel Corporation 82801G (ICH7 Family) USB
UHCI Controller #4 (rev 01)
00:1d.7 USB Controller: Intel Corporation 82801G (ICH7 Family) USB2
EHCI Controller (rev 01)
00:1e.0 PCI bridge: Intel Corporation 82801 PCI Bridge (rev e1)
00:1f.0 ISA bridge: Intel Corporation 82801GB/GR (ICH7 Family) LPC
Interface Bridge (rev 01)
00:1f.1 IDE interface: Intel Corporation 82801G (ICH7 Family) IDE
Controller (rev 01)
00:1f.3 SMBus: Intel Corporation 82801G (ICH7 Family) SMBus Controller (rev 01)
09:00.0 PCI bridge: Intel Corporation 6702PXH PCI Express-to-PCI
Bridge A (rev 09)
09:00.1 PIC: Intel Corporation 6700/6702PXH I/OxAPIC Interrupt
Controller A (rev 09)
0d:00.0 Ethernet controller: Intel Corporation 82573E Gigabit Ethernet
Controller (Copper) (rev 03)
0e:00.0 Ethernet controller: Intel Corporation 82573L Gigabit Ethernet
Controller
0f:00.0 VGA compatible controller: ATI Technologies Inc ES1000 (rev 02)
jlm-bdt:/home

BIOS Device - SST 49LF008A (32-pin PLCC)
http://www.sst.com/products.xhtml/serial_flash/49/SST49LF008A
Motherboard URL:
http://www.supermicro.com/products/motherboard/Xeon3000/3000/PDSMi+.cfm


Thanks in advance for your response.

John



From stepan at coresystems.de  Mon Nov  3 09:04:17 2008
From: stepan at coresystems.de (Stefan Reinauer)
Date: Mon, 3 Nov 2008 09:04:17 +0100
Subject: [coreboot] r3723 - trunk/util/flashrom
In-Reply-To: <20081103003548.31173.qmail@stuge.se>
References: <20081103003548.31173.qmail@stuge.se>
Message-ID: <C7F0E80C-A1A9-4B59-A5DC-462650ACE11D@coresystems.de>



On 03.11.2008, at 01:35,
  Peter Stuge <peter at stuge.se> wrote:

> svn at coreboot.org wrote:
>> +++ trunk/util/flashrom/chipset_enable.c    2008-11-03 00:20:22 UTC  
>> (rev 3723)
> ..
>>    case BUS_TYPE_ICH9_SPI:
>> -        /* TODO: Add dumping function for ICH8/ICH9, or drop the
>> -         * whole SPIBAR dumping from chipset_enable.c - There's
>> -         * inteltool for this task already.
>> -         */
>> +        tmp2 = *(uint16_t *) (spibar + 0);
>> +        printf_debug("0x00: 0x%04x (HSFS)\n", tmp2);
>> +        printf_debug("FLOCKDN %i, ", (tmp >> 15 & 1));
>> +        printf_debug("FDV %i, ", (tmp >> 14) & 1);
>> +        printf_debug("FDOPSS %i, ", (tmp >> 13) & 1);
>
> Would have been nice if this had gone into ichspi.c.

It's not too late, Peter. Care to illustrate your idea with a patch?

Stefan



From c-d.hailfinger.devel.2006 at gmx.net  Mon Nov  3 12:22:23 2008
From: c-d.hailfinger.devel.2006 at gmx.net (Carl-Daniel Hailfinger)
Date: Mon, 03 Nov 2008 12:22:23 +0100
Subject: [coreboot] r3723 - trunk/util/flashrom
In-Reply-To: <C7F0E80C-A1A9-4B59-A5DC-462650ACE11D@coresystems.de>
References: <20081103003548.31173.qmail@stuge.se>
	<C7F0E80C-A1A9-4B59-A5DC-462650ACE11D@coresystems.de>
Message-ID: <490EDEEF.60701@gmx.net>

On 03.11.2008 09:04, Stefan Reinauer wrote:
>
>
> On 03.11.2008, at 01:35,
>  Peter Stuge <peter at stuge.se> wrote:
>
>> svn at coreboot.org wrote:
>>> +++ trunk/util/flashrom/chipset_enable.c    2008-11-03 00:20:22 UTC
>>> (rev 3723)
>> ..
>>>    case BUS_TYPE_ICH9_SPI:
>>> -        /* TODO: Add dumping function for ICH8/ICH9, or drop the
>>> -         * whole SPIBAR dumping from chipset_enable.c - There's
>>> -         * inteltool for this task already.
>>> -         */
>>> +        tmp2 = *(uint16_t *) (spibar + 0);
>>> +        printf_debug("0x00: 0x%04x (HSFS)\n", tmp2);
>>> +        printf_debug("FLOCKDN %i, ", (tmp >> 15 & 1));
>>> +        printf_debug("FDV %i, ", (tmp >> 14) & 1);
>>> +        printf_debug("FDOPSS %i, ", (tmp >> 13) & 1);
>>
>> Would have been nice if this had gone into ichspi.c.
>
> It's not too late, Peter. Care to illustrate your idea with a patch?

Do we want to move all other chipset specific debug code to separate
files as well? Then we need ck804.c and ichold.c and...
IMHO chipset_enable.c is for stuff you want to run once per chipset:
Some debug prints, some settings. If we move such code out of
chipset_enable.c, where do we draw the line?

Regards,
Carl-Daniel

-- 
http://www.hailfinger.org/




From stepan at coresystems.de  Mon Nov  3 12:30:59 2008
From: stepan at coresystems.de (Stefan Reinauer)
Date: Mon, 03 Nov 2008 12:30:59 +0100
Subject: [coreboot] r3723 - trunk/util/flashrom
In-Reply-To: <490EDEEF.60701@gmx.net>
References: <20081103003548.31173.qmail@stuge.se>
	<C7F0E80C-A1A9-4B59-A5DC-462650ACE11D@coresystems.de>
	<490EDEEF.60701@gmx.net>
Message-ID: <490EE0F3.5060407@coresystems.de>

Carl-Daniel Hailfinger wrote:
> On 03.11.2008 09:04, Stefan Reinauer wrote:
>   
>> On 03.11.2008, at 01:35,
>>  Peter Stuge <peter at stuge.se> wrote:
>>
>>     
>>> svn at coreboot.org wrote:
>>>       
>>>> +++ trunk/util/flashrom/chipset_enable.c    2008-11-03 00:20:22 UTC
>>>> (rev 3723)
>>>>         
>>> ..
>>>       
>>>>    case BUS_TYPE_ICH9_SPI:
>>>> -        /* TODO: Add dumping function for ICH8/ICH9, or drop the
>>>> -         * whole SPIBAR dumping from chipset_enable.c - There's
>>>> -         * inteltool for this task already.
>>>> -         */
>>>> +        tmp2 = *(uint16_t *) (spibar + 0);
>>>> +        printf_debug("0x00: 0x%04x (HSFS)\n", tmp2);
>>>> +        printf_debug("FLOCKDN %i, ", (tmp >> 15 & 1));
>>>> +        printf_debug("FDV %i, ", (tmp >> 14) & 1);
>>>> +        printf_debug("FDOPSS %i, ", (tmp >> 13) & 1);
>>>>         
>>> Would have been nice if this had gone into ichspi.c.
>>>       
>> It's not too late, Peter. Care to illustrate your idea with a patch?
>>     
>
> Do we want to move all other chipset specific debug code to separate
> files as well? Then we need ck804.c and ichold.c and...
> IMHO chipset_enable.c is for stuff you want to run once per chipset:
> Some debug prints, some settings. If we move such code out of
> chipset_enable.c, where do we draw the line?
I think SPI is causing us headaches with our old concept of per-flash
drivers since with SPI the _magic_ suddenly happens in the SPI
controller and not in the flash device anymore. (Mostly)

I tend to agree with Carl-Daniel on this one, but we already "broke" the
convention by creating ichspi.c Anyways, if someone comes up with code
and a few reasons to apply that code, we have something to consider.
That may well be interpreted as "No code, no discussion".

Stefan

-- 
coresystems GmbH ? Brahmsstr. 16 ? D-79104 Freiburg i. Br.
      Tel.: +49 761 7668825 ? Fax: +49 761 7664613
Email: info at coresystems.de  ? http://www.coresystems.de/
Registergericht: Amtsgericht Freiburg ? HRB 7656
Gesch?ftsf?hrer: Stefan Reinauer ? Ust-IdNr.: DE245674866




From JRottmann at LiPPERTEmbedded.de  Mon Nov  3 14:30:26 2008
From: JRottmann at LiPPERTEmbedded.de (Jens Rottmann)
Date: Mon, 03 Nov 2008 14:30:26 +0100
Subject: [coreboot] [PATCH] new board: LiPPERT Cool SpaceRunner-LX
In-Reply-To: <20081030194447.GB28905@greenwood>
References: <48FDDF4C.3080601@LiPPERTEmbedded.de>
	<20081022160617.GI15706@greenwood>
	<4909EBDA.6010008@LiPPERTEmbedded.de>
	<20081030194447.GB28905@greenwood>
Message-ID: <490EFCF2.2060708@LiPPERTEmbedded.de>

Hi Uwe,

> The only non-trivial change I made, was to add
>  * Copyright (C) 2007 Advanced Micro Devices, Inc.
> to the cache_as_ram_auto.c file, as that's (IMHO) the only non-trivial
> file copied from the db800 and thus needs to preserve the (C) of AMD.
> 
> But please correct me if that should be wrong, we can still fix that
> then in svn (CC'd also Marc and Jordan from AMD for input).

No, you're absolutely right, the AMD (C) line really should be included
there, because I kept parts of AMD's actual code. Thanks for pointing
this out.

However, I happened to notice that you also deleted all "Based on ..."
lines and I'm a little bit unhappy about this. As I said in my last
mail, I'd have liked to pay credit to the code that served me as
example. ... Well, at least the SpaceRunner-LX patch is in now. ...


But I have something else I'd like to ask you for. I am now resending 3
small fixes I tripped over during my work. I had already sent them last
week ("[PATCH]es remaining 3 of 7 assorted fixes"), but they seemed to
have been ignored. If you have time for it, would you please have a look
at least at the one patch that adds the GPIO I/O resources to the IT8712F?

Thanks a lot,
Jens




From JRottmann at LiPPERTEmbedded.de  Mon Nov  3 14:31:18 2008
From: JRottmann at LiPPERTEmbedded.de (Jens Rottmann)
Date: Mon, 03 Nov 2008 14:31:18 +0100
Subject: [coreboot] [PATCH] fix CONFIG_FS_PAYLOAD=1
Message-ID: <490EFD26.7050308@LiPPERTEmbedded.de>

Fix compile errors if CONFIG_FS_PAYLOAD=1:

Compile error in filo.c if AUTOBOOT_DELAY=0. Replace
#ifndef AUTOBOOT_DELAY
with
#if !AUTOBOOT_DELAY
which should work for both the #undef and the =0 case.

In ext2fs.c, fat.c
#if ARCH == 'i386'
results in a compile warning: "multi-character character constant" and
the condition ARCH == 'i386' is mis-evaluated as FALSE, eventually
choking the assembler on a PPC instruction. Change it to
#ifdef __i386

Signed-off-by: Jens Rottmann <JRottmann at LiPPERTEmbedded.de>
---

Hi,

yes, I already posted this last week, together with 1 other patch, but
got no response. Now I'll try splitting it up to 2 seperate mails,
hopefully that works better.

Regards,
Jens Rottmann

-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: fs_payload.diff
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20081103/068d43e2/attachment.ksh>

From JRottmann at LiPPERTEmbedded.de  Mon Nov  3 14:31:33 2008
From: JRottmann at LiPPERTEmbedded.de (Jens Rottmann)
Date: Mon, 03 Nov 2008 14:31:33 +0100
Subject: [coreboot] [PATCH] IT8712F GPIO resources
Message-ID: <490EFD35.2000601@LiPPERTEmbedded.de>

Add the missing I/O resources for IT8712F GPIOs. (E.g. some LiPPERT
boards need them to switch the com ports from RS232 to RS485.) The PnP
resources should prevent other devices from being mapped at the same
spot, even if no OS driver actively uses them.

The IT8712F manual makes it look like PNP_IO1 had a size/granularity of
1 byte, but that must be a mistake. The Simple-I/O resource has a size
of 5 bytes (1 for each GPIO set 1-5) and trying different addresses
reveals a granularity of 8.

Signed-off-by: Jens Rottmann <JRottmann at LiPPERTEmbedded.de>
---

Hi,

yes, I already posted this patch last week, together with 2 others, but
got no response. Now I'll try splitting it up to 2 seperate mails,
hopefully that works better.

Regards,
Jens Rottmann

-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: it8712_gpio.diff
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20081103/3563f562/attachment.ksh>

From jordan.crouse at amd.com  Mon Nov  3 17:01:49 2008
From: jordan.crouse at amd.com (Jordan Crouse)
Date: Mon, 3 Nov 2008 09:01:49 -0700
Subject: [coreboot] new board: LiPPERT Cool SpaceRunner-LX
In-Reply-To: <490EFCF2.2060708@LiPPERTEmbedded.de>
References: <48FDDF4C.3080601@LiPPERTEmbedded.de>
	<20081022160617.GI15706@greenwood>
	<4909EBDA.6010008@LiPPERTEmbedded.de>
	<20081030194447.GB28905@greenwood>
	<490EFCF2.2060708@LiPPERTEmbedded.de>
Message-ID: <20081103160149.GC21829@cosmic.amd.com>

On 03/11/08 14:30 +0100, Jens Rottmann wrote:
> Hi Uwe,
> 
> > The only non-trivial change I made, was to add
> >  * Copyright (C) 2007 Advanced Micro Devices, Inc.
> > to the cache_as_ram_auto.c file, as that's (IMHO) the only non-trivial
> > file copied from the db800 and thus needs to preserve the (C) of AMD.
> > 
> > But please correct me if that should be wrong, we can still fix that
> > then in svn (CC'd also Marc and Jordan from AMD for input).
> 
> No, you're absolutely right, the AMD (C) line really should be included
> there, because I kept parts of AMD's actual code. Thanks for pointing
> this out.
> 
> However, I happened to notice that you also deleted all "Based on ..."
> lines and I'm a little bit unhappy about this. As I said in my last
> mail, I'd have liked to pay credit to the code that served me as
> example. ... Well, at least the SpaceRunner-LX patch is in now. ...

I would actually prefer the "based on" syntax rather then retaining
the copyright notice, if you ask me.  If you are just copying the same
API calls that all other motherboards use, then there is hardly anything
to copyright in the first place.  Now, if there are some chunks of 
unmodified code that are unique to the db800 code (such as a local function)
then thats a different story, but if you are just copying what everybody
else has done, retaining the copyright notice is silly and deleting the
"Based on" lines is double silly.

Jordan




From mylesgw at gmail.com  Mon Nov  3 17:24:45 2008
From: mylesgw at gmail.com (Myles Watson)
Date: Mon, 3 Nov 2008 10:24:45 -0600
Subject: [coreboot] HT revision 1.02 in K8
In-Reply-To: <4901E7E3.8070605@gmx.net>
References: <4901E603.9080000@gmx.net> <4901E7E3.8070605@gmx.net>
Message-ID: <2831fecf0811030824n61bbd5d5sb59860ad5af9599b@mail.gmail.com>

On Fri, Oct 24, 2008 at 9:21 AM, Carl-Daniel Hailfinger <
c-d.hailfinger.devel.2006 at gmx.net> wrote:

> On 24.10.2008 17:13, Carl-Daniel Hailfinger wrote:
> > Hi,
> >
> > I'm getting the following message from lspci on my K8 machine:
> >
> > 00:18.0 Host bridge [0600]: Advanced Micro Devices [AMD] K8
> > [Athlon64/Opteron] HyperTransport Technology Configuration [1022:1100]
> >         Control: I/O- Mem- BusMaster- SpecCycle- MemWINV- VGASnoop-
> > ParErr- Stepping- SERR- FastB2B- DisINTx-
> >         Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort-
> > <TAbort- <MAbort- >SERR- <PERR- INTx-
> >         Capabilities: [80] HyperTransport: Host or Secondary Interface
> >                 !!! Possibly incomplete decoding for revision 1.02
> >                 Command: WarmRst+ DblEnd-
> >                 Link Control: CFlE- CST- CFE- <LkFail- Init+ EOC- TXO-
> > <CRCErr=0
> >                 Link Config: MLWI=16bit MLWO=16bit LWI=16bit LWO=16bit
> >                 Revision ID: 1.02
> >         Kernel modules: ipmi_si
> >
> > Note the warning about "Possibly incomplete decoding" which stems from
> > the fact that the processor mentions HT revision 1.02 which is the last
> > non-public revision. Every revision from 1.03 and beyond seems to be
> > publically available. Now the big question is: Can we decode HT 1.02
> > like HT 1.03 or have there been fundamental changes in between? I'd like
> > to create a patch for PCIutils (lspci) so we can have full info without
> > a warning message.
>

From mylesgw at gmail.com  Mon Nov  3 17:30:57 2008
From: mylesgw at gmail.com (Myles Watson)
Date: Mon, 3 Nov 2008 10:30:57 -0600
Subject: [coreboot] PCI domains
Message-ID: <2831fecf0811030830p7d563c0dpaef6107fe2d0ae5e@mail.gmail.com>

I'm unclear on the concept of PCI domains.  I've done a Google search and
searched the books that I have (PCIe & HT).

The only place I find domains mentioned is in lspci documentation.

Has anyone ever seen an lspci with domains set to anything but 0?

Thanks,
Myles
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20081103/533b0c72/attachment.html>

From c-d.hailfinger.devel.2006 at gmx.net  Mon Nov  3 17:51:52 2008
From: c-d.hailfinger.devel.2006 at gmx.net (Carl-Daniel Hailfinger)
Date: Mon, 03 Nov 2008 17:51:52 +0100
Subject: [coreboot] PCI domains
In-Reply-To: <2831fecf0811030830p7d563c0dpaef6107fe2d0ae5e@mail.gmail.com>
References: <2831fecf0811030830p7d563c0dpaef6107fe2d0ae5e@mail.gmail.com>
Message-ID: <490F2C28.9030602@gmx.net>

On 03.11.2008 17:30, Myles Watson wrote:
> I'm unclear on the concept of PCI domains.  I've done a Google search and
> searched the books that I have (PCIe & HT).
>
> The only place I find domains mentioned is in lspci documentation.
>
> Has anyone ever seen an lspci with domains set to anything but 0?
>   

http://marc.info/?l=linux-kernel&m=109809009130342&w=4

Regards,
Carl-Daniel

-- 
http://www.hailfinger.org/




From svn at coreboot.org  Mon Nov  3 17:55:22 2008
From: svn at coreboot.org (svn at coreboot.org)
Date: Mon,  3 Nov 2008 17:55:22 +0100
Subject: [coreboot] r3725 - trunk/coreboot-v2/targets/msi/ms7260
Message-ID: <mailman.2378.1355071423.16123.coreboot@coreboot.org>

Author: jcrouse
Date: 2008-11-03 17:55:22 +0100 (Mon, 03 Nov 2008)
New Revision: 3725

Modified:
   trunk/coreboot-v2/targets/msi/ms7260/Config.lb
Log:
Move the default payload to be more buildrom friendly.

Signed-off-by: Jordan Crouse <jordan.crouse at amd.com>
Acked-by: Jordan Crouse <jordan.crouse at amd.com>


Modified: trunk/coreboot-v2/targets/msi/ms7260/Config.lb
===================================================================
--- trunk/coreboot-v2/targets/msi/ms7260/Config.lb	2008-11-03 04:08:35 UTC (rev 3724)
+++ trunk/coreboot-v2/targets/msi/ms7260/Config.lb	2008-11-03 16:55:22 UTC (rev 3725)
@@ -32,7 +32,8 @@
 	option ROM_IMAGE_SIZE = 128 * 1024
 	option XIP_ROM_SIZE = 256 * 1024
 	option COREBOOT_EXTRA_VERSION = ".0Normal"
-	payload /tmp/filo.elf
+#	payload /tmp/filo.elf
+	payload ../payload.elf
 end
 
 romimage "fallback"
@@ -41,7 +42,8 @@
 	option ROM_IMAGE_SIZE = 128 * 1024
 	option XIP_ROM_SIZE = 256 * 1024
 	option COREBOOT_EXTRA_VERSION = ".0Fallback"
-	payload /tmp/filo.elf
+#	payload /tmp/filo.elf
+	payload ../payload.elf
 end
 
 romimage "failover"




From jordan.crouse at amd.com  Mon Nov  3 18:02:19 2008
From: jordan.crouse at amd.com (Jordan Crouse)
Date: Mon, 3 Nov 2008 10:02:19 -0700
Subject: [coreboot] [PATCH]: buildrom - add MSI MS-7620 platform
Message-ID: <20081103170219.GD21829@cosmic.amd.com>

By special request on IRC.

Jordan

-- 
Jordan Crouse
Systems Software Development Engineer 
Advanced Micro Devices, Inc.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: ms7260.patch
Type: text/x-diff
Size: 31742 bytes
Desc: not available
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20081103/1034b97b/attachment.bin>

From info at coresystems.de  Mon Nov  3 18:12:28 2008
From: info at coresystems.de (coreboot information)
Date: Mon, 03 Nov 2008 18:12:28 +0100
Subject: [coreboot] r3725 build service
Message-ID: <E1Kx2ya-0006nl-C7@ra.coresystems.de>

Dear coreboot readers!

This is the automated build check service of coreboot.

The developer "jcrouse" checked in revision 3725 to
the coreboot source repository and caused the following 
changes:

Change Log:
Move the default payload to be more buildrom friendly.

Signed-off-by: Jordan Crouse <jordan.crouse at amd.com>
Acked-by: Jordan Crouse <jordan.crouse at amd.com>


Build Log:
Compilation of via:epia-cn has been broken
See the error log at http://qa.coreboot.org/log_buildbrd.php?revision=3725&device=epia-cn&vendor=via


If something broke during this checkin please be a pain 
in jcrouse's neck until the issue is fixed.

If this issue is not fixed within 24h the revision should 
be backed out.

   Best regards,
     coreboot automatic build system





From rminnich at gmail.com  Mon Nov  3 18:13:14 2008
From: rminnich at gmail.com (ron minnich)
Date: Mon, 3 Nov 2008 09:13:14 -0800
Subject: [coreboot] [PATCH]: buildrom - add MSI MS-7620 platform
In-Reply-To: <20081103170219.GD21829@cosmic.amd.com>
References: <20081103170219.GD21829@cosmic.amd.com>
Message-ID: <13426df10811030913h58ecfb4dp29583c0f18283b7c@mail.gmail.com>

Acked-by: Ronald G. Minnich <rminnich at gmail.com>



From c-d.hailfinger.devel.2006 at gmx.net  Mon Nov  3 18:17:22 2008
From: c-d.hailfinger.devel.2006 at gmx.net (Carl-Daniel Hailfinger)
Date: Mon, 03 Nov 2008 18:17:22 +0100
Subject: [coreboot] HT revision 1.02 in K8
In-Reply-To: <2831fecf0811030824n61bbd5d5sb59860ad5af9599b@mail.gmail.com>
References: <4901E603.9080000@gmx.net> <4901E7E3.8070605@gmx.net>
	<2831fecf0811030824n61bbd5d5sb59860ad5af9599b@mail.gmail.com>
Message-ID: <490F3222.8060801@gmx.net>

Hi Marc,

maybe you can shed some light on the problem below.

Basically, the K8 reports in lspci that it supports HT 1.02, but the
BKDG says it uses HT 1.03. And HT 1.03 is the first publicly available spec.

On 03.11.2008 17:24, Myles Watson wrote:
> On Fri, Oct 24, 2008 at 9:21 AM, Carl-Daniel Hailfinger <
> c-d.hailfinger.devel.2006 at gmx.net> wrote:
>
>   
>> On 24.10.2008 17:13, Carl-Daniel Hailfinger wrote:
>>     
>>> Hi,
>>>
>>> I'm getting the following message from lspci on my K8 machine:
>>>
>>> 00:18.0 Host bridge [0600]: Advanced Micro Devices [AMD] K8
>>> [Athlon64/Opteron] HyperTransport Technology Configuration [1022:1100]
>>>         Control: I/O- Mem- BusMaster- SpecCycle- MemWINV- VGASnoop-
>>> ParErr- Stepping- SERR- FastB2B- DisINTx-
>>>         Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort-
>>> <TAbort- <MAbort- >SERR- <PERR- INTx-
>>>         Capabilities: [80] HyperTransport: Host or Secondary Interface
>>>                 !!! Possibly incomplete decoding for revision 1.02
>>>                 Command: WarmRst+ DblEnd-
>>>                 Link Control: CFlE- CST- CFE- <LkFail- Init+ EOC- TXO-
>>> <CRCErr=0
>>>                 Link Config: MLWI=16bit MLWO=16bit LWI=16bit LWO=16bit
>>>                 Revision ID: 1.02
>>>         Kernel modules: ipmi_si
>>>
>>> Note the warning about "Possibly incomplete decoding" which stems from
>>> the fact that the processor mentions HT revision 1.02 which is the last
>>> non-public revision. Every revision from 1.03 and beyond seems to be
>>> publically available. Now the big question is: Can we decode HT 1.02
>>> like HT 1.03 or have there been fundamental changes in between? I'd like
>>> to create a patch for PCIutils (lspci) so we can have full info without
>>> a warning message.
>>>       
>
> >From the BKDG:
> 3.1 Configuration Space Accesses
> The AMD Athlon? 64 and AMD Opteron? Processors implement configuration space
> as defined in
> the PCI Local Bus Specification, Rev. 2.2, and the HyperTransport? I/O Link
> Specification, Rev.
> 1.03.
>
> I read that to mean that even though the processor reports Rev 1.02, it's
> 1.03.
>   

That certainly would make sense.


Regards,
Carl-Daniel

-- 
http://www.hailfinger.org/




From mylesgw at gmail.com  Mon Nov  3 20:37:25 2008
From: mylesgw at gmail.com (Myles Watson)
Date: Mon, 3 Nov 2008 12:37:25 -0700
Subject: [coreboot] PCI domains
In-Reply-To: <490F2C28.9030602@gmx.net>
References: <2831fecf0811030830p7d563c0dpaef6107fe2d0ae5e@mail.gmail.com>
	<490F2C28.9030602@gmx.net>
Message-ID: <2831fecf0811031137n5f26b594m8d1fd33e1de2e6ce@mail.gmail.com>

On Mon, Nov 3, 2008 at 9:51 AM, Carl-Daniel Hailfinger <
c-d.hailfinger.devel.2006 at gmx.net> wrote:

> On 03.11.2008 17:30, Myles Watson wrote:
> > I'm unclear on the concept of PCI domains.  I've done a Google search and
> > searched the books that I have (PCIe & HT).
> >
> > The only place I find domains mentioned is in lspci documentation.
> >
> > Has anyone ever seen an lspci with domains set to anything but 0?
> >
>
> http://marc.info/?l=linux-kernel&m=109809009130342&w=4
>

Thanks!

So can we be safe in assuming that IBM Power machines and SGI Altix machines
have domains, but x86 don't?

Myle
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20081103/1c9e469f/attachment.html>

From yinghailu at gmail.com  Mon Nov  3 20:46:29 2008
From: yinghailu at gmail.com (yhlu)
Date: Mon, 3 Nov 2008 11:46:29 -0800
Subject: [coreboot] PCI domains
In-Reply-To: <2831fecf0811031137n5f26b594m8d1fd33e1de2e6ce@mail.gmail.com>
References: <2831fecf0811030830p7d563c0dpaef6107fe2d0ae5e@mail.gmail.com>
	<490F2C28.9030602@gmx.net>
	<2831fecf0811031137n5f26b594m8d1fd33e1de2e6ce@mail.gmail.com>
Message-ID: <2ea3fae10811031146y751d9d12v9b67d3e2fdb78cd5@mail.gmail.com>

On Mon, Nov 3, 2008 at 11:37 AM, Myles Watson <mylesgw at gmail.com> wrote:

>
>
> On Mon, Nov 3, 2008 at 9:51 AM, Carl-Daniel Hailfinger <
> c-d.hailfinger.devel.2006 at gmx.net> wrote:
>
>> On 03.11.2008 17:30, Myles Watson wrote:
>> > I'm unclear on the concept of PCI domains.  I've done a Google search
>> and
>> > searched the books that I have (PCIe & HT).
>> >
>> > The only place I find domains mentioned is in lspci documentation.
>> >
>> > Has anyone ever seen an lspci with domains set to anything but 0?
>> >
>>
>> http://marc.info/?l=linux-kernel&m=109809009130342&w=4
>>
>
> Thanks!
>
> So can we be safe in assuming that IBM Power machines and SGI Altix
> machines have domains, but x86 don't?
>

one HP's AMD based workstation (like tyan s2895) has that ... one ht chain
==> one pci domain.
you could enable that in BIOS setup. (HP's own BIOS)

YH
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20081103/6cbd24db/attachment.html>

From rminnich at gmail.com  Mon Nov  3 20:52:51 2008
From: rminnich at gmail.com (ron minnich)
Date: Mon, 3 Nov 2008 11:52:51 -0800
Subject: [coreboot] PCI domains
In-Reply-To: <2ea3fae10811031146y751d9d12v9b67d3e2fdb78cd5@mail.gmail.com>
References: <2831fecf0811030830p7d563c0dpaef6107fe2d0ae5e@mail.gmail.com>
	<490F2C28.9030602@gmx.net>
	<2831fecf0811031137n5f26b594m8d1fd33e1de2e6ce@mail.gmail.com>
	<2ea3fae10811031146y751d9d12v9b67d3e2fdb78cd5@mail.gmail.com>
Message-ID: <13426df10811031152v635711a0tc4c96e5d38e3abc2@mail.gmail.com>

On Mon, Nov 3, 2008 at 11:46 AM, yhlu <yinghailu at gmail.com> wrote:

> one HP's AMD based workstation (like tyan s2895) has that ... one ht chain
> ==> one pci domain.
> you could enable that in BIOS setup. (HP's own BIOS)


Is there any benefit to it?

ron



From Marc.Jones at amd.com  Mon Nov  3 22:21:31 2008
From: Marc.Jones at amd.com (Marc Jones)
Date: Mon, 3 Nov 2008 14:21:31 -0700
Subject: [coreboot] HT revision 1.02 in K8
In-Reply-To: <490F3222.8060801@gmx.net>
References: <4901E603.9080000@gmx.net> <4901E7E3.8070605@gmx.net>
	<2831fecf0811030824n61bbd5d5sb59860ad5af9599b@mail.gmail.com>
	<490F3222.8060801@gmx.net>
Message-ID: <490F6B5B.3090205@amd.com>

Carl-Daniel Hailfinger wrote:
> Hi Marc,
> 
> maybe you can shed some light on the problem below.
> 
> Basically, the K8 reports in lspci that it supports HT 1.02, but the
> BKDG says it uses HT 1.03. And HT 1.03 is the first publicly available spec.
> 


I am not sure why you are blowing this out of proportion. It is a 
warning. It isn't a problem. If you examine the freely available K8 
BKDG, you will find that registers in the K8 match the 1.03 revision of 
the spec. Thus, the settings read by lspci are decoded correctly.

Marc


-- 
Marc Jones
Senior Firmware Engineer
(970) 226-9684 Office
mailto:Marc.Jones at amd.com
http://www.amd.com/embeddedprocessors




From svn at coreboot.org  Mon Nov  3 22:39:04 2008
From: svn at coreboot.org (svn at coreboot.org)
Date: Mon,  3 Nov 2008 22:39:04 +0100
Subject: [coreboot] r3726 - trunk/coreboot-v2/src/cpu/amd/model_fxx
Message-ID: <mailman.2379.1355071423.16123.coreboot@coreboot.org>

Author: mjones
Date: 2008-11-03 22:39:03 +0100 (Mon, 03 Nov 2008)
New Revision: 3726

Modified:
   trunk/coreboot-v2/src/cpu/amd/model_fxx/fidvid.c
Log:
Update K8 FID/VID setup. Add support for 100MHz FIDs (revG).

Signed-off-by: Marc Jones <marc.jones at amd.com>
Acked-by: Uwe Hermann <uwe at hermann-uwe.de>



Modified: trunk/coreboot-v2/src/cpu/amd/model_fxx/fidvid.c
===================================================================
--- trunk/coreboot-v2/src/cpu/amd/model_fxx/fidvid.c	2008-11-03 16:55:22 UTC (rev 3725)
+++ trunk/coreboot-v2/src/cpu/amd/model_fxx/fidvid.c	2008-11-03 21:39:03 UTC (rev 3726)
@@ -97,36 +97,43 @@
 }
 #endif
 
-static unsigned set_fidvid(unsigned apicid, unsigned fidvid, int showmessage)
+static u32 set_fidvid(unsigned apicid, unsigned fidvid, int showmessage)
 {
-	/* for (cur, new) there is one <1600MHz x8 to find out next_fid */
-	static const uint8_t next_fid_a[] = {
-	/*  x4  x5  x6  x7  x8  x9 x10 x11 x12 x13 x14 x15 */
-/* x4 */    0,  9,  9,  8,  9,  9,  9,  9,  9,  9,  9,  9,
-/* x5 */    9,  0, 11, 11,  9,  9, 10, 11, 11, 11, 11, 11,
-/* x6 */   11, 11,  0, 13, 11, 11, 11, 11, 12, 13, 13, 13,
-/* x7 */   13, 13, 13,  0, 13, 13, 13, 13, 13, 13, 14, 15,
-/* x8 */    4,  9,  9,  9,  0,  9,  9,  9,  9,  9,  9,  9,
-/* x9 */    4,  5, 10, 10,  8,  0,  0,  0,  0,  0,  0,  0,
-/*x10 */    9,  5, 11, 11,  9,  0,  0,  0,  0,  0,  0,  0,
-/*x11 */   10,  5,  6, 12, 10,  0,  0,  0,  0,  0,  0,  0,
-/*x12 */   11, 11,  6, 13, 11,  0,  0,  0,  0,  0,  0,  0,
-/*x13 */   12, 12,  6,  7, 12,  0,  0,  0,  0,  0,  0,  0,
-/*x14 */   13, 13, 13,  7, 13,  0,  0,  0,  0,  0,  0,  0,
-/*x15 */   14, 14, 14,  7, 14,  0,  0,  0,  0,  0,  0,  0,
-/* 0:x4, 2:x5....BASE=4, MIN=4, MAX=25, INC=2 result = (xX-BASE)*INC */
+
+/*  CurrentFID--> 4x(00h)   5x(02h)   6x(04h)   7x(06h) ...
+ *       --------------------------------------
+ * TargetFID   | Next_FID, Next_FID, Next_FID, Next_FID ...
+ *      |      | Next_FID, Next_FID, Next_FID, Next_FID ...
+ *     \|/     | Next_FID, Next_FID, Next_FID, Next_FID ...
+ */
+	static const u8 next_fid_200[] = {
+/*         x4  x5  x6  x7  x8  x9 x10 x11 x12 x13 x14 x15  x16 */
+/* x4 */    0, -1, -1, -1,  0,  0,  9, 10, 11, 12, 13, 14, 15, /*  800 */
+/* x5 */   -1,  0, -1, -1, -1,  5,  5,  5, 11, 12, 13, 14, 15, /* 1000 */
+/* x6 */   -1, -1,  0, -1, -1, -1, -1,  6,  6,  6, 13, 14, 15, /* 1200 */
+/* x7 */   -1, -1, -1,  0, -1, -1, -1, -1, -1,  7,  7,  7, 15, /* 1400 */
+/* lower table to upper table boarder (table 70 and 71 in BKDG) */
+/* x8 */    8, -1, -1, -1,  0,  8,  9, 10, 11, 12, 13, 14, 15, /* 1600 */
+/* x9 */    9,  9, -1, -1,  9,  0,  9, 10, 11, 12, 13, 14, 15, /* 1800 */
+/*x10 */    9, 10, -1, -1,  9, 10,  0, 10, 11, 12, 13, 14, 15, /* 2000 */
+/*x11 */    9, 11, 11, -1,  9, 10, 11,  0, 11, 12, 13, 14, 15, /* 2200 */
+/*x12 */    9, 11, 12, -1,  9, 10, 11, 12,  0, 12, 13, 14, 15, /* 2400 */
+/*x13 */    9, 11, 13, 13,  9, 10, 11, 12, 13,  0, 13, 14, 15, /* 2600 */
+/*x14 */    9, 11, 13, 14,  9, 10, 11, 12, 13, 14,  0, 14, 15, /* 2800 */
+/*x15 */    9, 11, 13, 15,  9, 10, 11, 12, 13, 14, 15,  0, 15, /* 3000 */
+/*x15 */    9, 11, 13, 15,  9, 10, 11, 12, 13, 14, 15, 16,  0, /* 3200 */
 	};
 
 	msr_t msr;
-	uint32_t vid;
-	uint32_t fid;
+	uint32_t vid_new;
+	uint32_t fid_new;
 	uint32_t vid_max;
 	uint32_t fid_max;
 	uint32_t vid_cur;
 	uint32_t fid_cur;
 	unsigned apicidx;
 
-	int steps;
+	int step_limit;
 	int loop;
 
 	apicidx = lapicid();
@@ -140,21 +147,22 @@
 		return fidvid;
 	}
 
-	fid = (fidvid >> 8) & 0x3f;
-	vid = (fidvid >> 16) & 0x3f;
+	fid_new = (fidvid >> 8) & 0x3f;
+	vid_new = (fidvid >> 16) & 0x3f;
 
 	msr = rdmsr(0xc0010042);
 
 	vid_cur = msr.hi & 0x3f;
 	fid_cur = msr.lo & 0x3f;
 
-	if ((vid_cur==vid) && (fid_cur==fid))
+	if ((vid_cur == vid_new) && (fid_cur == fid_new))
 		return fidvid;
 
-	vid_max = (msr.hi>>(48-32)) & 0x3f;
-	fid_max = ((msr.lo>>16) & 0x3f); /* max fid */
+	vid_max = (msr.hi >> (48-32)) & 0x3f;
+	fid_max = ((msr.lo >> 16) & 0x3f); /* max fid */
+
 #if FX_SUPPORT
-	if (fid_max>=((25-4)*2)) { /* FX max fid is 5G */
+	if (fid_max >= ((25 - 4) * 2)) { /* FX max fid is 5G */
 		fid_max = ((msr.lo >> 8) & 0x3f) + 5 * 2; /* max FID is min fid + 1G */
 		if (fid_max >= ((25-4) * 2)) {
 			fid_max = (10-4) * 2; /* hard set to 2G */
@@ -163,10 +171,20 @@
 #endif
 
 	/* set vid to max */
+	/* TODO - make this more correct. Not a big deal for setting max...
+	 * BKDG figure 11
+	 * if TargetFID > InitialFID
+	 *	TargetVID = FinalVID - RVO
+	 * else
+	 *	if CurrentVID > FinalVID
+	 *		TargetVID = FinalVID - RVO
+	 *	else
+	 *		TargetVID = CurrentVIDD - RVO
+	 */
 	msr.hi = 1;
 	msr.lo = (vid_max << 8) | (fid_cur);
 #if SB_VFSMAF == 1
-	msr.lo |= (1<<16); /* init changes */
+	msr.lo |= (1 << 16); /* init changes */
 #endif
 	wrmsr(0xc0010041, msr);
 #if SB_VFSMAF == 0
@@ -174,38 +192,92 @@
 #endif
 
 
-	for (loop=0;loop<100000;loop++){
+	for (loop=0; loop < 100000; loop++){
 		msr = rdmsr(0xc0010042);
-		if (!(msr.lo & (1<<31)))
+		if (!(msr.lo & (1 << 31)))
 			break;
 	}
 	vid_cur = msr.hi & 0x3f;
 
-	steps = 8; //??
-	while ((fid_cur != fid) && (steps-- > 0)) {
-		uint32_t fid_temp;
-		if ((fid_cur > (8-4)*2) && (fid> (8-4)*2)) {
-			if (fid_cur<fid) {
+	/* BKDG figure 12 and 13
+	 * if current fid is odd
+	 *	current fid -1 (next lower and even fid)(odd fid for rev G)
+	 * if current fid in high-freq table
+	 *	while current fid < target fid
+	 *		transition to next higher fid in table
+	 * else if target fid > VCO portal of current fid
+	 *	transition to highest portal fid in higher fid table
+	 *		while current fid < target fid
+	 *			transition to next higher fid in table
+	 * else
+	 *	transition to target fid
+	 */
+
+	printk_debug("Current fid_cur: 0x%x, fid_max: 0x%x\n", fid_cur, fid_max);
+	printk_debug("Requested fid_new: 0x%x\n", fid_new);
+
+	step_limit = 8; /* max 8 steps just in case... */
+	while ((fid_cur != fid_new) && (step_limit--)) {
+		u32 fid_temp;
+		int step;
+
+		if (fid_cur < fid_new)
+			/* Force Fid steps even. step == 0 means 100MHz step */
+			step = ((fid_new/2) - (fid_cur/2)) * 2;
+		else
+			step = ((fid_cur/2) - (fid_new/2)) * 2;
+
+		/* If 200Mhz step OR past 3200 max table value */
+		if ((step == 2) || (fid_new >= 0x18 || fid_cur >= 0x18)) {
+
+			printk_debug("200MHZ step ");
+
+			/* Step +/- 200MHz at a time */
+			if (fid_cur < fid_new)
 				fid_temp = fid_cur + 2;
-				} else {
-					fid_temp = fid_cur - 2;
-				}
-		} else {
-			/* there is one < 8, So we need to lookup the table to
-			 * find the fid_cur */
+			else
+				fid_temp = fid_cur - 2;
+
+
+		} else if ( step > 2) {	/* If more than a 200Mhz step */
 			int temp;
-			temp = next_fid_a[(fid_cur/2)*12+(fid/2)];
-			if (temp <= 0) break;
-			fid_temp = (temp-4) * 2;
+
+			/* look it up in the table */
+			printk_debug("FidVid table step ");
+
+			temp = next_fid_200[((fid_new/2) * 13) + (fid_cur/2)];
+
+			if (temp > 0)
+				fid_temp = (temp-4) * 2; /* Table 108 */
+			else if (temp == 0)
+				fid_temp = fid_new;
+			else
+				break; /* table error */
+
+		} else { /* step < 2 (100MHZ) */
+			printk_debug("100MHZ step ");
+
+			/* The table adjust in 200MHz increments. If requested,
+			 * do the 100MHz increment if the CPU supports it.*/
+			if (cpuid_edx(0x80000007) & (1 << 6)) {
+				fid_temp = fid_cur + 1;
+			} else {
+				/* 100 MHZ not supported. Get out of the loop */
+				printk_debug("is not supported.\n");
+				break;
+			}
 		}
-		if (fid_temp > fid_max)
+
+		if(fid_temp > fid_max) {
+			printk_debug("fid_temp 0x%x > fid_max 0x%x\n", fid_temp, fid_max);
 			break;
+		}
 
-		fid_cur = fid_temp;
+		printk_debug("fidvid: 0x%x\n", fid_temp);
 
 		/* set target fid */
-		msr.hi = (100000/5);
-		msr.lo = (vid_cur << 8) | fid_cur;
+		msr.hi = 0x190; /* 2 us for AMD NPT Family 0Fh Processors */
+		msr.lo = (vid_cur << 8) | fid_temp;
 #if SB_VFSMAF == 1
 		msr.lo |= (1 << 16); /* init changes */
 #endif
@@ -217,8 +289,8 @@
 
 #if K8_SET_FIDVID_DEBUG == 1
 		if (showmessage) {
-			print_debug_fv_8("\tapicid in set_fidvid = ", apicid);
-			print_debug_fv_64("ctrl msr fid, vid ", msr.hi, msr.lo);
+			print_debug_fv_8("set_fidvid APICID = ", apicid);
+			print_debug_fv_64("fidvid ctrl msr ", msr.hi, msr.lo);
 		}
 #endif
 
@@ -231,14 +303,24 @@
 
 #if K8_SET_FIDVID_DEBUG == 1
 		if (showmessage)	{
-			 print_debug_fv_64("status msr fid, vid ", msr.hi, msr.lo);
+			print_debug_fv_64("fidvid status msr ", msr.hi, msr.lo);
 		}
 #endif
 	}
 
 	/* set vid to final */
+	/* TODO - make this more correct. Not a big deal for setting max...
+	 * BKDG figure 11
+	 * if TargetFID > InitialFID
+	 *	TargetVID = FinalVID - RVO
+	 * else
+	 *	if CurrentVID > FinalVID
+	 *		TargetVID = FinalVID - RVO
+	 *	else
+	 *		TargetVID = CurrentVIDD - RVO
+	 */
 	msr.hi = 1;
-	msr.lo = (vid << 8) | (fid_cur);
+	msr.lo = (vid_new << 8) | (fid_cur);
 #if SB_VFSMAF == 1
 	msr.lo |= (1 << 16); // init changes
 #endif
@@ -257,10 +339,10 @@
 	fidvid = (vid_cur << 16) | (fid_cur << 8);
 
 	if (showmessage) {
-		if (vid!=vid_cur) {
+		if (vid_new != vid_cur) {
 			print_err("set vid failed for apicid ="); print_err_hex8(apicidx);  print_err("\r\n");
 		}
-		if (fid!=fid_cur) {
+		if (fid_new != fid_cur) {
 			print_err("set fid failed for apicid ="); print_err_hex8(apicidx); print_err("\r\n");
 		}
 	}




From Marc.Jones at amd.com  Mon Nov  3 22:39:27 2008
From: Marc.Jones at amd.com (Marc Jones)
Date: Mon, 3 Nov 2008 14:39:27 -0700
Subject: [coreboot] [v2][patch] update k8 fid/vid setup
In-Reply-To: <20081101154433.GD28905@greenwood>
References: <48AF20BE.1040609@amd.com> <20080930051342.8336.qmail@stuge.se>
	<48E2471D.5030905@amd.com> <48E3E41F.4000603@amd.com>
	<20081021234938.GF15706@greenwood> <4907958B.4050409@amd.com>
	<20081028232308.GA19217@greenwood> <4908F927.6090806@amd.com>
	<20081101154433.GD28905@greenwood>
Message-ID: <490F6F8F.5050605@amd.com>

Uwe Hermann wrote:
> On Wed, Oct 29, 2008 at 06:00:39PM -0600, Marc Jones wrote:
>> Uwe,
>> Thanks for all the help! Sorry this took so long.
>>
>> I found the issue (and a few others along the way). This updated patch  
>> should work now. It should also get you another 100MHz with your cpu :)
> 
> Indeed, thanks! I'm at 1.9 GHz now.
> 
> 
...
>> Update K8 FID/VID setup. Add support for 100MHz FIDs (revG).
>>
>> Signed-off-by: Marc Jones <marc.jones at amd.com>
> 
> Acked-by: Uwe Hermann <uwe at hermann-uwe.de>
> 
> 
> Please port this to v3 also if possible.


Thanks for testing this multiple times.
I'll follow up with a v3 patch later today.

r3726

Marc

-- 
Marc Jones
Senior Firmware Engineer
(970) 226-9684 Office
mailto:Marc.Jones at amd.com
http://www.amd.com/embeddedprocessors




From yinghailu at gmail.com  Mon Nov  3 22:44:23 2008
From: yinghailu at gmail.com (yhlu)
Date: Mon, 3 Nov 2008 13:44:23 -0800
Subject: [coreboot] PCI domains
In-Reply-To: <13426df10811031152v635711a0tc4c96e5d38e3abc2@mail.gmail.com>
References: <2831fecf0811030830p7d563c0dpaef6107fe2d0ae5e@mail.gmail.com>
	<490F2C28.9030602@gmx.net>
	<2831fecf0811031137n5f26b594m8d1fd33e1de2e6ce@mail.gmail.com>
	<2ea3fae10811031146y751d9d12v9b67d3e2fdb78cd5@mail.gmail.com>
	<13426df10811031152v635711a0tc4c96e5d38e3abc2@mail.gmail.com>
Message-ID: <2ea3fae10811031344o7c1b6278ue57c9f5b7ed89aea@mail.gmail.com>

On Mon, Nov 3, 2008 at 11:52 AM, ron minnich <rminnich at gmail.com> wrote:

> On Mon, Nov 3, 2008 at 11:46 AM, yhlu <yinghailu at gmail.com> wrote:
>
> > one HP's AMD based workstation (like tyan s2895) has that ... one ht
> chain
> > ==> one pci domain.
> > you could enable that in BIOS setup. (HP's own BIOS)
>
>
> Is there any benefit to it?


more than 255 pci buses. think about if you have 32 ht chains...

amd Family 10h cpu could support 16 domains ( 4 bits for domain...)

YH
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20081103/a0e2dd20/attachment.html>

From info at coresystems.de  Mon Nov  3 22:55:28 2008
From: info at coresystems.de (coreboot information)
Date: Mon, 03 Nov 2008 22:55:28 +0100
Subject: [coreboot] r3726 build service
Message-ID: <E1Kx7OS-0001RV-Fl@ra.coresystems.de>

Dear coreboot readers!

This is the automated build check service of coreboot.

The developer "mjones" checked in revision 3726 to
the coreboot source repository and caused the following 
changes:

Change Log:
Update K8 FID/VID setup. Add support for 100MHz FIDs (revG).

Signed-off-by: Marc Jones <marc.jones at amd.com>
Acked-by: Uwe Hermann <uwe at hermann-uwe.de>



Build Log:
Compilation of asus:a8v-e_se has been broken
See the error log at http://qa.coreboot.org/log_buildbrd.php?revision=3726&device=a8v-e_se&vendor=asus
Compilation of via:epia-cn has been fixed


If something broke during this checkin please be a pain 
in mjones's neck until the issue is fixed.

If this issue is not fixed within 24h the revision should 
be backed out.

   Best regards,
     coreboot automatic build system





From c-d.hailfinger.devel.2006 at gmx.net  Mon Nov  3 23:02:36 2008
From: c-d.hailfinger.devel.2006 at gmx.net (Carl-Daniel Hailfinger)
Date: Mon, 03 Nov 2008 23:02:36 +0100
Subject: [coreboot] HT revision 1.02 in K8
In-Reply-To: <490F6B5B.3090205@amd.com>
References: <4901E603.9080000@gmx.net> <4901E7E3.8070605@gmx.net>
	<2831fecf0811030824n61bbd5d5sb59860ad5af9599b@mail.gmail.com>
	<490F3222.8060801@gmx.net> <490F6B5B.3090205@amd.com>
Message-ID: <490F74FC.5070509@gmx.net>

Hi Marc,

On 03.11.2008 22:21, Marc Jones wrote:
> Carl-Daniel Hailfinger wrote:
>> Hi Marc,
>>
>> maybe you can shed some light on the problem below.
>>
>> Basically, the K8 reports in lspci that it supports HT 1.02, but the
>> BKDG says it uses HT 1.03. And HT 1.03 is the first publicly
>> available spec.
>
> I am not sure why you are blowing this out of proportion.

I'm very sorry if my questions gave that impression.

> It is a warning. It isn't a problem. If you examine the freely
> available K8 BKDG, you will find that registers in the K8 match the
> 1.03 revision of the spec.

Thanks for confirming this.

> Thus, the settings read by lspci are decoded correctly.

Actually, the settings decoded by lspci are incomplete because of the
version mismatch. I'll send a patch to lspci maintainers with a workaround.

Regards,
Carl-Daniel

-- 
http://www.hailfinger.org/




From mylesgw at gmail.com  Mon Nov  3 23:13:26 2008
From: mylesgw at gmail.com (Myles Watson)
Date: Mon, 3 Nov 2008 15:13:26 -0700
Subject: [coreboot] PCI domains
In-Reply-To: <2ea3fae10811031344o7c1b6278ue57c9f5b7ed89aea@mail.gmail.com>
References: <2831fecf0811030830p7d563c0dpaef6107fe2d0ae5e@mail.gmail.com>
	<490F2C28.9030602@gmx.net>
	<2831fecf0811031137n5f26b594m8d1fd33e1de2e6ce@mail.gmail.com>
	<2ea3fae10811031146y751d9d12v9b67d3e2fdb78cd5@mail.gmail.com>
	<13426df10811031152v635711a0tc4c96e5d38e3abc2@mail.gmail.com>
	<2ea3fae10811031344o7c1b6278ue57c9f5b7ed89aea@mail.gmail.com>
Message-ID: <2831fecf0811031413l407b4639u9b7974753f3c5e7e@mail.gmail.com>

On Mon, Nov 3, 2008 at 2:44 PM, yhlu <yinghailu at gmail.com> wrote:

>
>
> On Mon, Nov 3, 2008 at 11:52 AM, ron minnich <rminnich at gmail.com> wrote:
>
>> On Mon, Nov 3, 2008 at 11:46 AM, yhlu <yinghailu at gmail.com> wrote:
>>
>> > one HP's AMD based workstation (like tyan s2895) has that ... one ht
>> chain
>> > ==> one pci domain.
>> > you could enable that in BIOS setup. (HP's own BIOS)
>>
>>
>> Is there any benefit to it?
>
>
> more than 255 pci buses. think about if you have 32 ht chains...


Sorry to be dense, but how do you have more than 4 HT chains?  Aren't there
are only 8 nodes allowed in a system (3 links per node)?

If you took out the middle links in an 8-way design I guess you could have 8
HT chains.

And I guess if you made it into a chain you could have 10.

I'm obviously missing something, because it seems silly.


> amd Family 10h cpu could support 16 domains ( 4 bits for domain...)
>
> YH
>

Could you point me to a section of a BKDG?  I found something about
protection domains, but it looked like it was only for DMA.

I don't see how our current PCI functions could use domains.

Thanks,
Myles
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20081103/f043f534/attachment.html>

From yinghailu at gmail.com  Mon Nov  3 23:24:17 2008
From: yinghailu at gmail.com (yhlu)
Date: Mon, 3 Nov 2008 14:24:17 -0800
Subject: [coreboot] PCI domains
In-Reply-To: <2831fecf0811031413l407b4639u9b7974753f3c5e7e@mail.gmail.com>
References: <2831fecf0811030830p7d563c0dpaef6107fe2d0ae5e@mail.gmail.com>
	<490F2C28.9030602@gmx.net>
	<2831fecf0811031137n5f26b594m8d1fd33e1de2e6ce@mail.gmail.com>
	<2ea3fae10811031146y751d9d12v9b67d3e2fdb78cd5@mail.gmail.com>
	<13426df10811031152v635711a0tc4c96e5d38e3abc2@mail.gmail.com>
	<2ea3fae10811031344o7c1b6278ue57c9f5b7ed89aea@mail.gmail.com>
	<2831fecf0811031413l407b4639u9b7974753f3c5e7e@mail.gmail.com>
Message-ID: <2ea3fae10811031424o70960af1h92bcd6c424223cb5@mail.gmail.com>

On Mon, Nov 3, 2008 at 2:13 PM, Myles Watson <mylesgw at gmail.com> wrote:

>
>
> On Mon, Nov 3, 2008 at 2:44 PM, yhlu <yinghailu at gmail.com> wrote:
>
>>
>>
>> On Mon, Nov 3, 2008 at 11:52 AM, ron minnich <rminnich at gmail.com> wrote:
>>
>>> On Mon, Nov 3, 2008 at 11:46 AM, yhlu <yinghailu at gmail.com> wrote:
>>>
>>> > one HP's AMD based workstation (like tyan s2895) has that ... one ht
>>> chain
>>> > ==> one pci domain.
>>> > you could enable that in BIOS setup. (HP's own BIOS)
>>>
>>>
>>> Is there any benefit to it?
>>
>>
>> more than 255 pci buses. think about if you have 32 ht chains...
>
>
> Sorry to be dense, but how do you have more than 4 HT chains?  Aren't there
> are only 8 nodes allowed in a system (3 links per node)?
>
> If you took out the middle links in an 8-way design I guess you could have
> 8 HT chains.
>

for amd family 10h (HT3 ?) will have 8 sublinks...so you could build system
with more nodes and more ht chains

YH
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20081103/88872e56/attachment.html>

From Marc.Jones at amd.com  Mon Nov  3 23:29:16 2008
From: Marc.Jones at amd.com (Marc Jones)
Date: Mon, 3 Nov 2008 15:29:16 -0700
Subject: [coreboot] [v3] [patch] k8 fid/vid update
Message-ID: <490F7B3C.1010308@amd.com>

Ported from coreboot v2 fid/vid patch.
Marc

-- 
Marc Jones
Senior Firmware Engineer
(970) 226-9684 Office
mailto:Marc.Jones at amd.com
http://www.amd.com/embeddedprocessors




From paulepanter at users.sourceforge.net  Mon Nov  3 23:40:35 2008
From: paulepanter at users.sourceforge.net (Paul Menzel)
Date: Mon, 03 Nov 2008 23:40:35 +0100
Subject: [coreboot] [v3] [patch] k8 fid/vid update
In-Reply-To: <490F7B3C.1010308@amd.com>
References: <490F7B3C.1010308@amd.com>
Message-ID: <1225752035.3798.0.camel@mattotaupa.wohnung.familie-menzel.net>

Dear Marc,


Am Montag, den 03.11.2008, 15:29 -0700 schrieb Marc Jones:
> Ported from coreboot v2 fid/vid patch.

If you attached something, it came not through to me.


Thanks,

Paul
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 197 bytes
Desc: Dies ist ein digital signierter Nachrichtenteil
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20081103/9c693934/attachment.sig>

From Marc.Jones at amd.com  Mon Nov  3 23:45:27 2008
From: Marc.Jones at amd.com (Marc Jones)
Date: Mon, 3 Nov 2008 15:45:27 -0700
Subject: [coreboot] [v3] [patch] k8 fid/vid update
In-Reply-To: <490F7B3C.1010308@amd.com>
References: <490F7B3C.1010308@amd.com>
Message-ID: <490F7F07.5050603@amd.com>

With patch this time.....

Marc Jones wrote:
> Ported from coreboot v2 fid/vid patch.
> Marc
> 


-- 
Marc Jones
Senior Firmware Engineer
(970) 226-9684 Office
mailto:Marc.Jones at amd.com
http://www.amd.com/embeddedprocessors
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: k8_fidvid.patch
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20081103/27fb8bfa/attachment.ksh>

From svn at coreboot.org  Mon Nov  3 23:46:27 2008
From: svn at coreboot.org (svn at coreboot.org)
Date: Mon,  3 Nov 2008 23:46:27 +0100
Subject: [coreboot] r3727 - trunk/coreboot-v2/src/mainboard/asus/a8v-e_se
Message-ID: <mailman.2380.1355071423.16123.coreboot@coreboot.org>

Author: mjones
Date: 2008-11-03 23:46:27 +0100 (Mon, 03 Nov 2008)
New Revision: 3727

Modified:
   trunk/coreboot-v2/src/mainboard/asus/a8v-e_se/Options.lb
Log:
Set asus/a8v-3_se to use printk in CAR. (trivial)

Signed-off-by: Marc Jones <marc.jones at amd.com>
Acked-by: Marc Jones <marc.jones at amd.com>



Modified: trunk/coreboot-v2/src/mainboard/asus/a8v-e_se/Options.lb
===================================================================
--- trunk/coreboot-v2/src/mainboard/asus/a8v-e_se/Options.lb	2008-11-03 21:39:03 UTC (rev 3726)
+++ trunk/coreboot-v2/src/mainboard/asus/a8v-e_se/Options.lb	2008-11-03 22:46:27 UTC (rev 3727)
@@ -91,6 +91,7 @@
 uses SB_HT_CHAIN_ON_BUS0
 uses CONFIG_COMPRESSED_PAYLOAD_NRV2B
 uses CONFIG_COMPRESSED_PAYLOAD_LZMA
+uses CONFIG_USE_PRINTK_IN_CAR
 
 default ROM_SIZE = 512 * 1024
 default FALLBACK_SIZE = 256 * 1024
@@ -158,6 +159,7 @@
 default CC = "$(CROSS_COMPILE)gcc -m32"
 default HOSTCC = "gcc"
 default CONFIG_GDB_STUB = 0
+default CONFIG_USE_PRINTK_IN_CAR = 1
 default CONFIG_CONSOLE_SERIAL8250 = 1
 default TTYS0_BAUD = 115200
 default TTYS0_BASE = 0x3f8




From svn at coreboot.org  Mon Nov  3 23:58:57 2008
From: svn at coreboot.org (svn at coreboot.org)
Date: Mon,  3 Nov 2008 23:58:57 +0100
Subject: [coreboot] r3728 - trunk/coreboot-v2/src/superio/ite/it8712f
Message-ID: <mailman.2381.1355071423.16123.coreboot@coreboot.org>

Author: mjones
Date: 2008-11-03 23:58:56 +0100 (Mon, 03 Nov 2008)
New Revision: 3728

Modified:
   trunk/coreboot-v2/src/superio/ite/it8712f/superio.c
Log:
Add the missing I/O resources for IT8712F GPIOs. (E.g. some LiPPERT
boards need them to switch the com ports from RS232 to RS485.) The PnP
resources should prevent other devices from being mapped at the same
spot, even if no OS driver actively uses them.

The IT8712F manual makes it look like PNP_IO1 had a size/granularity of
1 byte, but that must be a mistake. The Simple-I/O resource has a size
of 5 bytes (1 for each GPIO set 1-5) and trying different addresses
reveals a granularity of 8.

Signed-off-by: Jens Rottmann <JRottmann at LiPPERTEmbedded.de>
Acked-by: Marc Jones <marc.jones at amd.com>



Modified: trunk/coreboot-v2/src/superio/ite/it8712f/superio.c
===================================================================
--- trunk/coreboot-v2/src/superio/ite/it8712f/superio.c	2008-11-03 22:46:27 UTC (rev 3727)
+++ trunk/coreboot-v2/src/superio/ite/it8712f/superio.c	2008-11-03 22:58:56 UTC (rev 3728)
@@ -129,7 +129,7 @@
 	{&ops, IT8712F_EC, PNP_IO0 | PNP_IO1 | PNP_IRQ0, {0xff8, 0}, {0xff8, 4},},
 	{&ops, IT8712F_KBCK, PNP_IO0 | PNP_IO1 | PNP_IRQ0, {0xfff, 0}, {0xfff, 4},},
 	{&ops, IT8712F_KBCM, PNP_IRQ0,},
-	{&ops, IT8712F_GPIO,},
+	{&ops, IT8712F_GPIO, PNP_IO0 | PNP_IO1 | PNP_IO2 | PNP_IRQ0, {0xfff, 0}, {0xff8, 0}, {0xff8, 0},},
 	{&ops, IT8712F_MIDI, PNP_IO0 | PNP_IRQ0, {0xff8, 0},},
 	{&ops, IT8712F_GAME, PNP_IO0, {0xfff, 0},},
 	{&ops, IT8712F_IR, PNP_IO0 | PNP_IRQ0, {0xff8, 0},},




From Marc.Jones at amd.com  Mon Nov  3 23:59:48 2008
From: Marc.Jones at amd.com (Marc Jones)
Date: Mon, 3 Nov 2008 15:59:48 -0700
Subject: [coreboot] [PATCH] IT8712F GPIO resources
In-Reply-To: <490EFD35.2000601@LiPPERTEmbedded.de>
References: <490EFD35.2000601@LiPPERTEmbedded.de>
Message-ID: <490F8264.8060505@amd.com>

Jens Rottmann wrote:
> Add the missing I/O resources for IT8712F GPIOs. (E.g. some LiPPERT
> boards need them to switch the com ports from RS232 to RS485.) The PnP
> resources should prevent other devices from being mapped at the same
> spot, even if no OS driver actively uses them.
> 
> The IT8712F manual makes it look like PNP_IO1 had a size/granularity of
> 1 byte, but that must be a mistake. The Simple-I/O resource has a size
> of 5 bytes (1 for each GPIO set 1-5) and trying different addresses
> reveals a granularity of 8.
> 
> Signed-off-by: Jens Rottmann <JRottmann at LiPPERTEmbedded.de>

Acked-by: Marc Jones <marc.jones at amd.com>

r3728

Marc


-- 
Marc Jones
Senior Firmware Engineer
(970) 226-9684 Office
mailto:Marc.Jones at amd.com
http://www.amd.com/embeddedprocessors




From info at coresystems.de  Tue Nov  4 00:02:48 2008
From: info at coresystems.de (coreboot information)
Date: Tue, 04 Nov 2008 00:02:48 +0100
Subject: [coreboot] r3727 build service
Message-ID: <E1Kx8Rc-00060H-9m@ra.coresystems.de>

Dear coreboot readers!

This is the automated build check service of coreboot.

The developer "mjones" checked in revision 3727 to
the coreboot source repository and caused the following 
changes:

Change Log:
Set asus/a8v-3_se to use printk in CAR. (trivial)

Signed-off-by: Marc Jones <marc.jones at amd.com>
Acked-by: Marc Jones <marc.jones at amd.com>



Build Log:
Compilation of asus:a8v-e_se has been fixed


If something broke during this checkin please be a pain 
in mjones's neck until the issue is fixed.

If this issue is not fixed within 24h the revision should 
be backed out.

   Best regards,
     coreboot automatic build system





From svn at coreboot.org  Tue Nov  4 00:16:00 2008
From: svn at coreboot.org (svn at coreboot.org)
Date: Tue,  4 Nov 2008 00:16:00 +0100
Subject: [coreboot] r3729 - in trunk/coreboot-v2/src: boot stream/fs
Message-ID: <mailman.2382.1355071423.16123.coreboot@coreboot.org>

Author: stepan
Date: 2008-11-04 00:16:00 +0100 (Tue, 04 Nov 2008)
New Revision: 3729

Modified:
   trunk/coreboot-v2/src/boot/filo.c
   trunk/coreboot-v2/src/stream/fs/ext2fs.c
   trunk/coreboot-v2/src/stream/fs/fat.c
Log:
Fix compile errors if CONFIG_FS_PAYLOAD=1:

Compile error in filo.c if AUTOBOOT_DELAY=0. Replace
#ifndef AUTOBOOT_DELAY
with
#if !AUTOBOOT_DELAY
which should work for both the #undef and the =0 case.

In ext2fs.c, fat.c
#if ARCH == 'i386'
results in a compile warning: "multi-character character constant" and
the condition ARCH == 'i386' is mis-evaluated as FALSE, eventually
choking the assembler on a PPC instruction. Change it to
#ifdef __i386

Signed-off-by: Jens Rottmann <JRottmann at LiPPERTEmbedded.de>
Acked-by: Stefan Reinauer <stepan at coresystems.de>



Modified: trunk/coreboot-v2/src/boot/filo.c
===================================================================
--- trunk/coreboot-v2/src/boot/filo.c	2008-11-03 22:58:56 UTC (rev 3728)
+++ trunk/coreboot-v2/src/boot/filo.c	2008-11-03 23:16:00 UTC (rev 3729)
@@ -18,7 +18,7 @@
 #define autoboot(mem)
 #endif
 
-#ifndef AUTOBOOT_DELAY
+#if !AUTOBOOT_DELAY
 #define autoboot_delay() 0 /* success */
 #endif
 

Modified: trunk/coreboot-v2/src/stream/fs/ext2fs.c
===================================================================
--- trunk/coreboot-v2/src/stream/fs/ext2fs.c	2008-11-03 22:58:56 UTC (rev 3728)
+++ trunk/coreboot-v2/src/stream/fs/ext2fs.c	2008-11-03 23:16:00 UTC (rev 3729)
@@ -239,7 +239,7 @@
  * ffz = Find First Zero in word. Undefined if no zero exists,
  * so code should check against ~0UL first..
  */
-#if ARCH == 'i386'
+#ifdef __i386
 static __inline__ unsigned long
 ffz (unsigned long word)
 {

Modified: trunk/coreboot-v2/src/stream/fs/fat.c
===================================================================
--- trunk/coreboot-v2/src/stream/fs/fat.c	2008-11-03 22:58:56 UTC (rev 3728)
+++ trunk/coreboot-v2/src/stream/fs/fat.c	2008-11-03 23:16:00 UTC (rev 3729)
@@ -54,7 +54,7 @@
 
 #define FAT_CACHE_SIZE 2048
 
-#if ARCH == 'i386'
+#ifdef __i386
 static __inline__ unsigned long
 log2 (unsigned long word)
 {




From stepan at coresystems.de  Tue Nov  4 00:16:34 2008
From: stepan at coresystems.de (Stefan Reinauer)
Date: Tue, 04 Nov 2008 00:16:34 +0100
Subject: [coreboot] [PATCH] fix CONFIG_FS_PAYLOAD=1
In-Reply-To: <490EFD26.7050308@LiPPERTEmbedded.de>
References: <490EFD26.7050308@LiPPERTEmbedded.de>
Message-ID: <490F8652.4010902@coresystems.de>

Jens Rottmann wrote:
> Fix compile errors if CONFIG_FS_PAYLOAD=1:
>
> Compile error in filo.c if AUTOBOOT_DELAY=0. Replace
> #ifndef AUTOBOOT_DELAY
> with
> #if !AUTOBOOT_DELAY
> which should work for both the #undef and the =0 case.
>
> In ext2fs.c, fat.c
> #if ARCH == 'i386'
> results in a compile warning: "multi-character character constant" and
> the condition ARCH == 'i386' is mis-evaluated as FALSE, eventually
> choking the assembler on a PPC instruction. Change it to
> #ifdef __i386
>
> Signed-off-by: Jens Rottmann <JRottmann at LiPPERTEmbedded.de>
> ---
>
> Hi,
>
> yes, I already posted this last week, together with 1 other patch, but
> got no response. Now I'll try splitting it up to 2 seperate mails,
> hopefully that works better.
>   

sorry for the delay. r3729

-- 
coresystems GmbH ? Brahmsstr. 16 ? D-79104 Freiburg i. Br.
      Tel.: +49 761 7668825 ? Fax: +49 761 7664613
Email: info at coresystems.de  ? http://www.coresystems.de/
Registergericht: Amtsgericht Freiburg ? HRB 7656
Gesch?ftsf?hrer: Stefan Reinauer ? Ust-IdNr.: DE245674866




From Marc.Jones at amd.com  Tue Nov  4 00:19:16 2008
From: Marc.Jones at amd.com (Marc Jones)
Date: Mon, 3 Nov 2008 16:19:16 -0700
Subject: [coreboot] [PATCH] fix CONFIG_FS_PAYLOAD=1
In-Reply-To: <490EFD26.7050308@LiPPERTEmbedded.de>
References: <490EFD26.7050308@LiPPERTEmbedded.de>
Message-ID: <490F86F4.40301@amd.com>

Jens Rottmann wrote:
> Fix compile errors if CONFIG_FS_PAYLOAD=1:
> 
> Compile error in filo.c if AUTOBOOT_DELAY=0. Replace
> #ifndef AUTOBOOT_DELAY
> with
> #if !AUTOBOOT_DELAY
> which should work for both the #undef and the =0 case.
> 
> In ext2fs.c, fat.c
> #if ARCH == 'i386'
> results in a compile warning: "multi-character character constant" and
> the condition ARCH == 'i386' is mis-evaluated as FALSE, eventually
> choking the assembler on a PPC instruction. Change it to
> #ifdef __i386
> 
> Signed-off-by: Jens Rottmann <JRottmann at LiPPERTEmbedded.de>

It looks like you are the firs/only x86 platform to use FS_PAYLOAD.
Acked-by: Marc Jones <marc.jones at amd.com>

And Stefan just beat me to the check in so I will stop now.....

:)

Marc



-- 
Marc Jones
Senior Firmware Engineer
(970) 226-9684 Office
mailto:Marc.Jones at amd.com
http://www.amd.com/embeddedprocessors




From enrico.mangosio at fastwebnet.it  Mon Nov  3 14:31:02 2008
From: enrico.mangosio at fastwebnet.it (Enrico Mangosio)
Date: Mon, 3 Nov 2008 14:31:02 +0100
Subject: [coreboot] ASUS P5GD1 Data for COREBOOT
Message-ID: <F1C08ED9038E4B0B82FBA7E3AFADD9FF@VistaHome>

Dear All,

Thanks for your work.

COREBOOT sounds amazing.

Herewith you'll find some info about my MB, as you requested.

MB: ASUS P5GD1

I could do the same with a laptop Thinkpad X61 If you need..

Regards,

Enrico.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20081103/45b41d90/attachment.html>
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: superiotool-dV.txt
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20081103/45b41d90/attachment.txt>
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: mptable.txt
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20081103/45b41d90/attachment-0001.txt>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: irq_tables.c
Type: application/octet-stream
Size: 3051 bytes
Desc: not available
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20081103/45b41d90/attachment.obj>
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: lshw.txt
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20081103/45b41d90/attachment-0002.txt>
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: lspci-tvnn.txt
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20081103/45b41d90/attachment-0003.txt>
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: dmidecode-dump.txt
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20081103/45b41d90/attachment-0004.txt>
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: dmidecode.txt
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20081103/45b41d90/attachment-0005.txt>

From uwe at hermann-uwe.de  Tue Nov  4 00:56:42 2008
From: uwe at hermann-uwe.de (Uwe Hermann)
Date: Tue, 4 Nov 2008 00:56:42 +0100
Subject: [coreboot] [v3] [patch] k8 fid/vid update
In-Reply-To: <490F7F07.5050603@amd.com>
References: <490F7B3C.1010308@amd.com> <490F7F07.5050603@amd.com>
Message-ID: <20081103235642.GA13674@greenwood>

On Mon, Nov 03, 2008 at 03:45:27PM -0700, Marc Jones wrote:
> Update K8 FID/VID setupto match coreboot v2. Add support for 100MHz FIDs (revG).
> 
> Signed-off-by: Marc Jones <marc.jones at amd.com>

Great, thanks!

Acked-by: Uwe Hermann <uwe at hermann-uwe.de>

Can't test much in v3 yet, but the patch looks good. Minor nitpicks
below.


> -		if (fid_temp > fid_max)
> +
> +		if(fid_temp > fid_max) {
                  ^
                space

> +			printk(BIOS_DEBUG, "fid_temp 0x%x > fid_max 0x%x\n",
> +				fid_temp, fid_max);
>  			break;
> +		}


> -		send = (apicid<<24) | (readback & 0x00ffff00); 
> +		send = (apicid<<24) | (readback & 0x00ffff00);
                              ^ ^
                             space

Uwe.
-- 
http://www.hermann-uwe.de  | http://www.holsham-traders.de
http://www.crazy-hacks.org | http://www.unmaintained-free-software.org



From uwe at hermann-uwe.de  Tue Nov  4 01:44:15 2008
From: uwe at hermann-uwe.de (Uwe Hermann)
Date: Tue, 4 Nov 2008 01:44:15 +0100
Subject: [coreboot] new board: LiPPERT Cool SpaceRunner-LX
In-Reply-To: <20081103160149.GC21829@cosmic.amd.com>
References: <48FDDF4C.3080601@LiPPERTEmbedded.de>
	<20081022160617.GI15706@greenwood>
	<4909EBDA.6010008@LiPPERTEmbedded.de>
	<20081030194447.GB28905@greenwood>
	<490EFCF2.2060708@LiPPERTEmbedded.de>
	<20081103160149.GC21829@cosmic.amd.com>
Message-ID: <20081104004415.GA23206@greenwood>

On Mon, Nov 03, 2008 at 09:01:49AM -0700, Jordan Crouse wrote:
> > However, I happened to notice that you also deleted all "Based on ..."
> > lines and I'm a little bit unhappy about this. As I said in my last
> > mail, I'd have liked to pay credit to the code that served me as
> > example. ... Well, at least the SpaceRunner-LX patch is in now. ...
> 
> I would actually prefer the "based on" syntax rather then retaining
> the copyright notice, if you ask me.  If you are just copying the same
> API calls that all other motherboards use, then there is hardly anything
> to copyright in the first place.

Full ACK.

The only question here is whether this is the case for the
cache_as_ram_auto.c file or not, but I'll leave that to you guys to judge.


> Now, if there are some chunks of 
> unmodified code that are unique to the db800 code (such as a local function)
> then thats a different story, but if you are just copying what everybody

Yep.


> else has done, retaining the copyright notice is silly and deleting the
> "Based on" lines is double silly.

I don't agree here (obviously). If we had added a "based on" line, every
time someone cloned some other board in v2, we'd have files like this
by now:

/*
 * Based on the foo/bar target from vendor X.
 * Based on the foo/baz target from vendor Y.
 * Based on the foo/xxx target from vendor Z.
 * Based on the foo/yyy target from vendor A.
 * Based on the foo/zzz target from vendor B.
 * ...
 */

I'm _sure_ we can find code in v2 that has gone through more than 8 or 9
copy-paste iterations. Keeping adding "based on" lines just doesn't make
much sense IMHO.

Either way, this is not important enough to fuel a lenghty discussion,
so here are two patches to fix it in either way, feel free to choose and
apply one of them, whichever works better.


Cheers, Uwe.
-- 
http://www.hermann-uwe.de  | http://www.holsham-traders.de
http://www.crazy-hacks.org | http://www.unmaintained-free-software.org
-------------- next part --------------
A non-text attachment was scrubbed...
Name: v2_lippert_based_on.patch
Type: text/x-diff
Size: 3588 bytes
Desc: not available
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20081104/a4f5c54f/attachment.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: v2_lippert_c_amd.patch
Type: text/x-diff
Size: 589 bytes
Desc: not available
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20081104/a4f5c54f/attachment-0001.bin>

From jordan.crouse at amd.com  Tue Nov  4 01:58:45 2008
From: jordan.crouse at amd.com (Jordan Crouse)
Date: Mon, 3 Nov 2008 17:58:45 -0700
Subject: [coreboot] new board: LiPPERT Cool SpaceRunner-LX
In-Reply-To: <20081104004415.GA23206@greenwood>
References: <48FDDF4C.3080601@LiPPERTEmbedded.de>
	<20081022160617.GI15706@greenwood>
	<4909EBDA.6010008@LiPPERTEmbedded.de>
	<20081030194447.GB28905@greenwood>
	<490EFCF2.2060708@LiPPERTEmbedded.de>
	<20081103160149.GC21829@cosmic.amd.com>
	<20081104004415.GA23206@greenwood>
Message-ID: <20081104005845.GA2725@cosmic.amd.com>

On 04/11/08 01:44 +0100, Uwe Hermann wrote:
> On Mon, Nov 03, 2008 at 09:01:49AM -0700, Jordan Crouse wrote:
> > > However, I happened to notice that you also deleted all "Based on ..."
> > > lines and I'm a little bit unhappy about this. As I said in my last
> > > mail, I'd have liked to pay credit to the code that served me as
> > > example. ... Well, at least the SpaceRunner-LX patch is in now. ...
> > 
> > I would actually prefer the "based on" syntax rather then retaining
> > the copyright notice, if you ask me.  If you are just copying the same
> > API calls that all other motherboards use, then there is hardly anything
> > to copyright in the first place.
> 
> Full ACK.
> 
> The only question here is whether this is the case for the
> cache_as_ram_auto.c file or not, but I'll leave that to you guys to judge.
> 
> 
> > Now, if there are some chunks of 
> > unmodified code that are unique to the db800 code (such as a local function)
> > then thats a different story, but if you are just copying what everybody
> 
> Yep.
> 
> 
> > else has done, retaining the copyright notice is silly and deleting the
> > "Based on" lines is double silly.
> 
> I don't agree here (obviously). If we had added a "based on" line, every
> time someone cloned some other board in v2, we'd have files like this
> by now:
> 
> /*
>  * Based on the foo/bar target from vendor X.
>  * Based on the foo/baz target from vendor Y.
>  * Based on the foo/xxx target from vendor Z.
>  * Based on the foo/yyy target from vendor A.
>  * Based on the foo/zzz target from vendor B.
>  * ...
>  */
> 
> I'm _sure_ we can find code in v2 that has gone through more than 8 or 9
> copy-paste iterations. Keeping adding "based on" lines just doesn't make
> much sense IMHO.

I don't think we need to append them to one another.  I think that over
time we will find that a number of canotical mainboards that everybody
uses, and the "Based on" will just be inherited.   And even if it isn't,
it doesn't really hurt us if this mainboard says "Based on msi/blah" and
then msi/blah says based on "acer/foo".  Its not like this code has
traveled very far.

Jordan





From rminnich at gmail.com  Tue Nov  4 02:00:16 2008
From: rminnich at gmail.com (ron minnich)
Date: Mon, 3 Nov 2008 17:00:16 -0800
Subject: [coreboot] PCI domains
In-Reply-To: <2ea3fae10811031344o7c1b6278ue57c9f5b7ed89aea@mail.gmail.com>
References: <2831fecf0811030830p7d563c0dpaef6107fe2d0ae5e@mail.gmail.com>
	<490F2C28.9030602@gmx.net>
	<2831fecf0811031137n5f26b594m8d1fd33e1de2e6ce@mail.gmail.com>
	<2ea3fae10811031146y751d9d12v9b67d3e2fdb78cd5@mail.gmail.com>
	<13426df10811031152v635711a0tc4c96e5d38e3abc2@mail.gmail.com>
	<2ea3fae10811031344o7c1b6278ue57c9f5b7ed89aea@mail.gmail.com>
Message-ID: <13426df10811031700t7e697b69r9281ebed0278b83e@mail.gmail.com>

Where do the domain bits live in the chipset?

ron



From coreboot at zl2tod.net  Tue Nov  4 03:39:08 2008
From: coreboot at zl2tod.net (Mark Robinson)
Date: Tue, 04 Nov 2008 15:39:08 +1300
Subject: [coreboot] HT revision 1.02 in K8
Message-ID: <200811041539.08312.coreboot@zl2tod.net>

Attached please find outputs of lspci -nvvv with and without Carl-Daniel's 
patch plus a diff.

(sorry about breaking the threading)
-------------- next part --------------
00:00.0 0500: 10de:0369 (rev a1)
	Subsystem: 1462:7260
	Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR+ FastB2B- DisINTx-
	Status: Cap+ 66MHz+ UDF- FastB2B+ ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
	Latency: 0
	Capabilities: [44] HyperTransport: Slave or Primary Interface
		Command: BaseUnitID=0 UnitCnt=15 MastHost- DefDir- DUL-
		Link Control 0: CFlE+ CST- CFE- <LkFail- Init+ EOC- TXO- <CRCErr=0 IsocEn- LSEn+ ExtCTL- 64b-
		Link Config 0: MLWI=16bit DwFcIn- MLWO=16bit DwFcOut- LWI=16bit DwFcInEn- LWO=16bit DwFcOutEn-
		Link Control 1: CFlE- CST- CFE- <LkFail+ Init- EOC+ TXO+ <CRCErr=0 IsocEn- LSEn- ExtCTL- 64b-
		Link Config 1: MLWI=8bit DwFcIn- MLWO=8bit DwFcOut- LWI=8bit DwFcInEn- LWO=8bit DwFcOutEn-
		Revision ID: 1.03
		Link Frequency 0: 1.0GHz
		Link Error 0: <Prot- <Ovfl- <EOC- CTLTm-
		Link Frequency Capability 0: 200MHz+ 300MHz+ 400MHz+ 500MHz+ 600MHz+ 800MHz+ 1.0GHz+ 1.2GHz- 1.4GHz- 1.6GHz- Vend-
		Feature Capability: IsocFC+ LDTSTOP+ CRCTM- ECTLT- 64bA- UIDRD-
		Link Frequency 1: 200MHz
		Link Error 1: <Prot- <Ovfl- <EOC- CTLTm-
		Link Frequency Capability 1: 200MHz- 300MHz- 400MHz- 500MHz- 600MHz- 800MHz- 1.0GHz- 1.2GHz- 1.4GHz- 1.6GHz- Vend-
		Error Handling: PFlE+ OFlE+ PFE- OFE- EOCFE- RFE- CRCFE- SERRFE- CF- RE- PNFE- ONFE- EOCNFE- RNFE- CRCNFE- SERRNFE-
		Prefetchable memory behind bridge Upper: 00-00
		Bus Number: 00
	Capabilities: [dc] HyperTransport: MSI Mapping Enable+ Fixed-
		Mapping Address Base: 00000000fee00000

00:01.0 0601: 10de:0363 (rev a2)
	Subsystem: 1462:7260
	Control: I/O+ Mem+ BusMaster+ SpecCycle+ MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx-
	Status: Cap- 66MHz+ UDF- FastB2B+ ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
	Latency: 0
	Region 0: I/O ports at 2f00 [size=128]

00:01.1 0c05: 10de:0368 (rev a2)
	Subsystem: 1462:7260
	Control: I/O+ Mem- BusMaster- SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx-
	Status: Cap+ 66MHz+ UDF- FastB2B+ ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
	Interrupt: pin A routed to IRQ 11
	Region 0: I/O ports at 2900 [size=64]
	Region 4: I/O ports at 2d00 [size=64]
	Region 5: I/O ports at 2e00 [size=64]
	Capabilities: [44] Power Management version 2
		Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA PME(D0-,D1-,D2-,D3hot+,D3cold+)
		Status: D0 PME-Enable- DSel=0 DScale=0 PME-
	Kernel driver in use: nForce2_smbus
	Kernel modules: i2c-nforce2

00:02.0 0c03: 10de:036c (rev a1) (prog-if 10 [OHCI])
	Subsystem: 1462:7260
	Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx-
	Status: Cap+ 66MHz+ UDF- FastB2B+ ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
	Latency: 0 (750ns min, 250ns max)
	Interrupt: pin A routed to IRQ 23
	Region 0: Memory at fbffb000 (32-bit, non-prefetchable) [size=4K]
	Capabilities: [44] Power Management version 2
		Flags: PMEClk- DSI- D1+ D2+ AuxCurrent=0mA PME(D0+,D1+,D2+,D3hot+,D3cold+)
		Status: D0 PME-Enable- DSel=0 DScale=0 PME-
	Kernel driver in use: ohci_hcd
	Kernel modules: ohci-hcd

00:02.1 0c03: 10de:036d (rev a2) (prog-if 20 [EHCI])
	Subsystem: 1462:7260
	Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx-
	Status: Cap+ 66MHz+ UDF- FastB2B+ ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
	Latency: 0 (750ns min, 250ns max)
	Interrupt: pin B routed to IRQ 22
	Region 0: Memory at fbffac00 (32-bit, non-prefetchable) [size=256]
	Capabilities: [44] Debug port: BAR=1 offset=0098
	Capabilities: [80] Power Management version 2
		Flags: PMEClk- DSI- D1+ D2+ AuxCurrent=0mA PME(D0+,D1+,D2+,D3hot+,D3cold+)
		Status: D0 PME-Enable- DSel=0 DScale=0 PME-
	Kernel driver in use: ehci_hcd
	Kernel modules: ehci-hcd

00:04.0 0101: 10de:036e (rev a1) (prog-if 8a [Master SecP PriP])
	Subsystem: 1462:7260
	Control: I/O+ Mem- BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx-
	Status: Cap+ 66MHz+ UDF- FastB2B+ ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
	Latency: 0 (750ns min, 250ns max)
	Region 0: [virtual] Memory at 000001f0 (32-bit, non-prefetchable) [disabled] [size=8]
	Region 1: [virtual] Memory at 000003f0 (type 3, non-prefetchable) [disabled] [size=1]
	Region 2: [virtual] Memory at 00000170 (32-bit, non-prefetchable) [disabled] [size=8]
	Region 3: [virtual] Memory at 00000370 (type 3, non-prefetchable) [disabled] [size=1]
	Region 4: I/O ports at ffa0 [size=16]
	Capabilities: [44] Power Management version 2
		Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA PME(D0-,D1-,D2-,D3hot-,D3cold-)
		Status: D0 PME-Enable- DSel=0 DScale=0 PME-
	Kernel driver in use: AMD_IDE
	Kernel modules: amd74xx, ide-pci-generic, ata_generic

00:05.0 0101: 10de:037f (rev a2) (prog-if 85 [Master SecO PriO])
	Subsystem: 1462:7260
	Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx-
	Status: Cap+ 66MHz+ UDF- FastB2B+ ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
	Latency: 0 (750ns min, 250ns max)
	Interrupt: pin A routed to IRQ 20
	Region 0: I/O ports at d480 [size=8]
	Region 1: I/O ports at d400 [size=4]
	Region 2: I/O ports at d080 [size=8]
	Region 3: I/O ports at d000 [size=4]
	Region 4: I/O ports at cc00 [size=16]
	Region 5: Memory at fbff9000 (32-bit, non-prefetchable) [size=4K]
	Capabilities: [44] Power Management version 2
		Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA PME(D0-,D1-,D2-,D3hot-,D3cold-)
		Status: D0 PME-Enable- DSel=0 DScale=0 PME-
	Capabilities: [b0] Message Signalled Interrupts: Mask- 64bit+ Queue=0/2 Enable-
		Address: 0000000000000000  Data: 0000
	Capabilities: [cc] HyperTransport: MSI Mapping Enable+ Fixed+
	Kernel driver in use: sata_nv
	Kernel modules: ide-pci-generic, ata_generic, sata_nv

00:05.1 0101: 10de:037f (rev a2) (prog-if 85 [Master SecO PriO])
	Subsystem: 1462:7260
	Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx-
	Status: Cap+ 66MHz+ UDF- FastB2B+ ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
	Latency: 0 (750ns min, 250ns max)
	Interrupt: pin B routed to IRQ 23
	Region 0: I/O ports at c880 [size=8]
	Region 1: I/O ports at c800 [size=4]
	Region 2: I/O ports at c480 [size=8]
	Region 3: I/O ports at c400 [size=4]
	Region 4: I/O ports at c080 [size=16]
	Region 5: Memory at fbff8000 (32-bit, non-prefetchable) [size=4K]
	Capabilities: [44] Power Management version 2
		Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA PME(D0-,D1-,D2-,D3hot-,D3cold-)
		Status: D0 PME-Enable- DSel=0 DScale=0 PME-
	Capabilities: [b0] Message Signalled Interrupts: Mask- 64bit+ Queue=0/2 Enable-
		Address: 0000000000000000  Data: 0000
	Capabilities: [cc] HyperTransport: MSI Mapping Enable+ Fixed+
	Kernel driver in use: sata_nv
	Kernel modules: ide-pci-generic, ata_generic, sata_nv

00:06.0 0604: 10de:0370 (rev a2) (prog-if 01 [Subtractive decode])
	Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx-
	Status: Cap+ 66MHz+ UDF- FastB2B+ ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
	Latency: 0
	Bus: primary=00, secondary=01, subordinate=01, sec-latency=64
	I/O behind bridge: 0000e000-0000efff
	Memory behind bridge: fc000000-febfffff
	Prefetchable memory behind bridge: f8000000-f9ffffff
	Secondary status: 66MHz- FastB2B+ ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- <SERR- <PERR-
	BridgeCtl: Parity- SERR+ NoISA- VGA+ MAbort- >Reset- FastB2B-
		PriDiscTmr- SecDiscTmr+ DiscTmrStat- DiscTmrSERREn-
	Capabilities: [b8] Subsystem: 1462:7260
	Capabilities: [8c] HyperTransport: MSI Mapping Enable+ Fixed-
		Mapping Address Base: 00000000fee00000

00:06.1 0403: 10de:0371 (rev a2)
	Subsystem: 1462:7260
	Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx-
	Status: Cap+ 66MHz+ UDF- FastB2B+ ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
	Latency: 0 (500ns min, 1250ns max)
	Interrupt: pin B routed to IRQ 22
	Region 0: Memory at fbff4000 (32-bit, non-prefetchable) [size=16K]
	Capabilities: [44] Power Management version 2
		Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA PME(D0-,D1-,D2-,D3hot+,D3cold+)
		Status: D0 PME-Enable- DSel=0 DScale=0 PME-
	Capabilities: [50] Message Signalled Interrupts: Mask+ 64bit+ Queue=0/0 Enable-
		Address: 0000000000000000  Data: 0000
		Masking: 00000000  Pending: 00000000
	Capabilities: [6c] HyperTransport: MSI Mapping Enable+ Fixed+
	Kernel driver in use: HDA Intel
	Kernel modules: snd-hda-intel

00:08.0 0680: 10de:0373 (rev a2)
	Subsystem: 1462:7260
	Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx+
	Status: Cap+ 66MHz+ UDF- FastB2B+ ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
	Latency: 0 (250ns min, 5000ns max)
	Interrupt: pin A routed to IRQ 1274
	Region 0: Memory at fbff3000 (32-bit, non-prefetchable) [size=4K]
	Region 1: I/O ports at c000 [size=8]
	Region 2: Memory at fbffa800 (32-bit, non-prefetchable) [size=256]
	Region 3: Memory at fbffa400 (32-bit, non-prefetchable) [size=16]
	Capabilities: [44] Power Management version 2
		Flags: PMEClk- DSI- D1+ D2+ AuxCurrent=0mA PME(D0+,D1+,D2+,D3hot+,D3cold+)
		Status: D0 PME-Enable+ DSel=0 DScale=0 PME-
	Capabilities: [70] MSI-X: Enable- Mask- TabSize=8
		Vector table: BAR=2 offset=00000000
		PBA: BAR=3 offset=00000000
	Capabilities: [50] Message Signalled Interrupts: Mask+ 64bit+ Queue=0/3 Enable+
		Address: 00000000fee0300c  Data: 4191
		Masking: 000000fe  Pending: 00000000
	Capabilities: [6c] HyperTransport: MSI Mapping Enable+ Fixed+
	Kernel driver in use: forcedeth
	Kernel modules: forcedeth

00:0b.0 0604: 10de:0374 (rev a2) (prog-if 00 [Normal decode])
	Control: I/O- Mem- BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx+
	Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
	Latency: 0, Cache Line Size: 64 bytes
	Bus: primary=00, secondary=02, subordinate=02, sec-latency=0
	I/O behind bridge: 0000f000-00000fff
	Memory behind bridge: fff00000-000fffff
	Prefetchable memory behind bridge: 00000000fff00000-00000000000fffff
	Secondary status: 66MHz- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- <SERR- <PERR-
	BridgeCtl: Parity- SERR+ NoISA- VGA- MAbort- >Reset- FastB2B-
		PriDiscTmr- SecDiscTmr- DiscTmrStat- DiscTmrSERREn-
	Capabilities: [40] Subsystem: 10de:0000
	Capabilities: [48] Power Management version 2
		Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA PME(D0+,D1+,D2+,D3hot+,D3cold+)
		Status: D0 PME-Enable- DSel=0 DScale=0 PME-
	Capabilities: [50] Message Signalled Interrupts: Mask- 64bit+ Queue=0/1 Enable+
		Address: 00000000fee0300c  Data: 4149
	Capabilities: [60] HyperTransport: MSI Mapping Enable+ Fixed-
		Mapping Address Base: 00000000fee00000
	Capabilities: [80] Express (v1) Root Port (Slot+), MSI 00
		DevCap:	MaxPayload 256 bytes, PhantFunc 0, Latency L0s <512ns, L1 <4us
			ExtTag- RBE+ FLReset-
		DevCtl:	Report errors: Correctable+ Non-Fatal+ Fatal+ Unsupported+
			RlxdOrd+ ExtTag- PhantFunc- AuxPwr- NoSnoop+
			MaxPayload 128 bytes, MaxReadReq 512 bytes
		DevSta:	CorrErr- UncorrErr- FatalErr- UnsuppReq- AuxPwr- TransPend-
		LnkCap:	Port #4, Speed 2.5GT/s, Width x1, ASPM L0s L1, Latency L0 <512ns, L1 <4us
			ClockPM- Suprise- LLActRep+ BwNot-
		LnkCtl:	ASPM Disabled; RCB 64 bytes Disabled- Retrain- CommClk-
			ExtSynch- ClockPM- AutWidDis- BWInt- AutBWInt-
		LnkSta:	Speed 2.5GT/s, Width x4, TrErr- Train- SlotClk+ DLActive- BWMgmt- ABWMgmt-
		SltCap:	AttnBtn- PwrCtrl- MRL- AttnInd- PwrInd- HotPlug- Surpise-
			Slot #  0, PowerLimit 0.000000; Interlock- NoCompl-
		SltCtl:	Enable: AttnBtn- PwrFlt- MRL- PresDet- CmdCplt- HPIrq- LinkChg-
			Control: AttnInd Off, PwrInd On, Power- Interlock-
		SltSta:	Status: AttnBtn- PowerFlt- MRL- CmdCplt- PresDet- Interlock-
			Changed: MRL- PresDet- LinkState-
		RootCtl: ErrCorrectable- ErrNon-Fatal- ErrFatal- PMEIntEna- CRSVisible-
		RootCap: CRSVisible-
		RootSta: PME ReqID 0000, PMEStatus- PMEPending-
	Capabilities: [100] Virtual Channel <?>
	Kernel driver in use: pcieport-driver
	Kernel modules: shpchp

00:0c.0 0604: 10de:0374 (rev a2) (prog-if 00 [Normal decode])
	Control: I/O- Mem- BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx+
	Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
	Latency: 0, Cache Line Size: 64 bytes
	Bus: primary=00, secondary=03, subordinate=03, sec-latency=0
	I/O behind bridge: 0000f000-00000fff
	Memory behind bridge: fff00000-000fffff
	Prefetchable memory behind bridge: 00000000fff00000-00000000000fffff
	Secondary status: 66MHz- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- <SERR- <PERR-
	BridgeCtl: Parity- SERR+ NoISA- VGA- MAbort- >Reset- FastB2B-
		PriDiscTmr- SecDiscTmr- DiscTmrStat- DiscTmrSERREn-
	Capabilities: [40] Subsystem: 10de:0000
	Capabilities: [48] Power Management version 2
		Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA PME(D0+,D1+,D2+,D3hot+,D3cold+)
		Status: D0 PME-Enable- DSel=0 DScale=0 PME-
	Capabilities: [50] Message Signalled Interrupts: Mask- 64bit+ Queue=0/1 Enable+
		Address: 00000000fee0300c  Data: 4151
	Capabilities: [60] HyperTransport: MSI Mapping Enable+ Fixed-
		Mapping Address Base: 00000000fee00000
	Capabilities: [80] Express (v1) Root Port (Slot+), MSI 00
		DevCap:	MaxPayload 256 bytes, PhantFunc 0, Latency L0s <512ns, L1 <4us
			ExtTag- RBE+ FLReset-
		DevCtl:	Report errors: Correctable+ Non-Fatal+ Fatal+ Unsupported+
			RlxdOrd+ ExtTag- PhantFunc- AuxPwr- NoSnoop+
			MaxPayload 128 bytes, MaxReadReq 512 bytes
		DevSta:	CorrErr- UncorrErr- FatalErr- UnsuppReq- AuxPwr- TransPend-
		LnkCap:	Port #3, Speed 2.5GT/s, Width x1, ASPM L0s L1, Latency L0 <512ns, L1 <4us
			ClockPM- Suprise- LLActRep+ BwNot-
		LnkCtl:	ASPM Disabled; RCB 64 bytes Disabled- Retrain- CommClk-
			ExtSynch- ClockPM- AutWidDis- BWInt- AutBWInt-
		LnkSta:	Speed 2.5GT/s, Width x4, TrErr- Train- SlotClk+ DLActive- BWMgmt- ABWMgmt-
		SltCap:	AttnBtn- PwrCtrl- MRL- AttnInd- PwrInd- HotPlug- Surpise-
			Slot #  0, PowerLimit 0.000000; Interlock- NoCompl-
		SltCtl:	Enable: AttnBtn- PwrFlt- MRL- PresDet- CmdCplt- HPIrq- LinkChg-
			Control: AttnInd Off, PwrInd On, Power- Interlock-
		SltSta:	Status: AttnBtn- PowerFlt- MRL- CmdCplt- PresDet- Interlock-
			Changed: MRL- PresDet- LinkState-
		RootCtl: ErrCorrectable- ErrNon-Fatal- ErrFatal- PMEIntEna- CRSVisible-
		RootCap: CRSVisible-
		RootSta: PME ReqID 0000, PMEStatus- PMEPending-
	Capabilities: [100] Virtual Channel <?>
	Kernel driver in use: pcieport-driver
	Kernel modules: shpchp

00:0d.0 0604: 10de:0378 (rev a2) (prog-if 00 [Normal decode])
	Control: I/O- Mem- BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx+
	Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
	Latency: 0, Cache Line Size: 64 bytes
	Bus: primary=00, secondary=04, subordinate=04, sec-latency=0
	I/O behind bridge: 0000f000-00000fff
	Memory behind bridge: fff00000-000fffff
	Prefetchable memory behind bridge: 00000000fff00000-00000000000fffff
	Secondary status: 66MHz- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- <SERR- <PERR-
	BridgeCtl: Parity- SERR+ NoISA- VGA- MAbort- >Reset- FastB2B-
		PriDiscTmr- SecDiscTmr- DiscTmrStat- DiscTmrSERREn-
	Capabilities: [40] Subsystem: 10de:0000
	Capabilities: [48] Power Management version 2
		Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA PME(D0+,D1+,D2+,D3hot+,D3cold+)
		Status: D0 PME-Enable- DSel=0 DScale=0 PME-
	Capabilities: [50] Message Signalled Interrupts: Mask- 64bit+ Queue=0/1 Enable+
		Address: 00000000fee0300c  Data: 4159
	Capabilities: [60] HyperTransport: MSI Mapping Enable+ Fixed-
		Mapping Address Base: 00000000fee00000
	Capabilities: [80] Express (v1) Root Port (Slot+), MSI 00
		DevCap:	MaxPayload 256 bytes, PhantFunc 0, Latency L0s <512ns, L1 <4us
			ExtTag- RBE+ FLReset-
		DevCtl:	Report errors: Correctable+ Non-Fatal+ Fatal+ Unsupported+
			RlxdOrd+ ExtTag- PhantFunc- AuxPwr- NoSnoop+
			MaxPayload 128 bytes, MaxReadReq 512 bytes
		DevSta:	CorrErr- UncorrErr- FatalErr- UnsuppReq- AuxPwr- TransPend-
		LnkCap:	Port #2, Speed 2.5GT/s, Width x1, ASPM L0s L1, Latency L0 <512ns, L1 <4us
			ClockPM- Suprise- LLActRep+ BwNot-
		LnkCtl:	ASPM Disabled; RCB 64 bytes Disabled- Retrain- CommClk-
			ExtSynch- ClockPM- AutWidDis- BWInt- AutBWInt-
		LnkSta:	Speed 2.5GT/s, Width x4, TrErr- Train- SlotClk+ DLActive- BWMgmt- ABWMgmt-
		SltCap:	AttnBtn- PwrCtrl- MRL- AttnInd- PwrInd- HotPlug- Surpise-
			Slot #  0, PowerLimit 0.000000; Interlock- NoCompl-
		SltCtl:	Enable: AttnBtn- PwrFlt- MRL- PresDet- CmdCplt- HPIrq- LinkChg-
			Control: AttnInd Off, PwrInd On, Power- Interlock-
		SltSta:	Status: AttnBtn- PowerFlt- MRL- CmdCplt- PresDet- Interlock-
			Changed: MRL- PresDet- LinkState-
		RootCtl: ErrCorrectable- ErrNon-Fatal- ErrFatal- PMEIntEna- CRSVisible-
		RootCap: CRSVisible-
		RootSta: PME ReqID 0000, PMEStatus- PMEPending-
	Capabilities: [100] Virtual Channel <?>
	Kernel driver in use: pcieport-driver
	Kernel modules: shpchp

00:0e.0 0604: 10de:0375 (rev a2) (prog-if 00 [Normal decode])
	Control: I/O- Mem- BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx+
	Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
	Latency: 0, Cache Line Size: 64 bytes
	Bus: primary=00, secondary=05, subordinate=05, sec-latency=0
	I/O behind bridge: 0000f000-00000fff
	Memory behind bridge: fff00000-000fffff
	Prefetchable memory behind bridge: 00000000fff00000-00000000000fffff
	Secondary status: 66MHz- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- <SERR- <PERR-
	BridgeCtl: Parity- SERR+ NoISA- VGA- MAbort- >Reset- FastB2B-
		PriDiscTmr- SecDiscTmr- DiscTmrStat- DiscTmrSERREn-
	Capabilities: [40] Subsystem: 10de:0000
	Capabilities: [48] Power Management version 2
		Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA PME(D0+,D1+,D2+,D3hot+,D3cold+)
		Status: D0 PME-Enable- DSel=0 DScale=0 PME-
	Capabilities: [50] Message Signalled Interrupts: Mask- 64bit+ Queue=0/1 Enable+
		Address: 00000000fee0300c  Data: 4161
	Capabilities: [60] HyperTransport: MSI Mapping Enable+ Fixed-
		Mapping Address Base: 00000000fee00000
	Capabilities: [80] Express (v1) Root Port (Slot+), MSI 00
		DevCap:	MaxPayload 256 bytes, PhantFunc 0, Latency L0s <512ns, L1 <4us
			ExtTag- RBE+ FLReset-
		DevCtl:	Report errors: Correctable+ Non-Fatal+ Fatal+ Unsupported+
			RlxdOrd+ ExtTag- PhantFunc- AuxPwr- NoSnoop+
			MaxPayload 128 bytes, MaxReadReq 512 bytes
		DevSta:	CorrErr- UncorrErr- FatalErr- UnsuppReq- AuxPwr- TransPend-
		LnkCap:	Port #1, Speed 2.5GT/s, Width x1, ASPM L0s L1, Latency L0 <512ns, L1 <4us
			ClockPM- Suprise- LLActRep+ BwNot-
		LnkCtl:	ASPM Disabled; RCB 64 bytes Disabled- Retrain- CommClk-
			ExtSynch- ClockPM- AutWidDis- BWInt- AutBWInt-
		LnkSta:	Speed 2.5GT/s, Width x8, TrErr- Train- SlotClk+ DLActive- BWMgmt- ABWMgmt-
		SltCap:	AttnBtn- PwrCtrl- MRL- AttnInd- PwrInd- HotPlug- Surpise-
			Slot #  0, PowerLimit 0.000000; Interlock- NoCompl-
		SltCtl:	Enable: AttnBtn- PwrFlt- MRL- PresDet- CmdCplt- HPIrq- LinkChg-
			Control: AttnInd Off, PwrInd On, Power- Interlock-
		SltSta:	Status: AttnBtn- PowerFlt- MRL- CmdCplt- PresDet- Interlock-
			Changed: MRL- PresDet- LinkState-
		RootCtl: ErrCorrectable- ErrNon-Fatal- ErrFatal- PMEIntEna- CRSVisible-
		RootCap: CRSVisible-
		RootSta: PME ReqID 0000, PMEStatus- PMEPending-
	Capabilities: [100] Virtual Channel <?>
	Kernel driver in use: pcieport-driver
	Kernel modules: shpchp

00:0f.0 0604: 10de:0377 (rev a2) (prog-if 00 [Normal decode])
	Control: I/O- Mem- BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx+
	Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
	Latency: 0, Cache Line Size: 64 bytes
	Bus: primary=00, secondary=06, subordinate=06, sec-latency=0
	I/O behind bridge: 0000f000-00000fff
	Memory behind bridge: fff00000-000fffff
	Prefetchable memory behind bridge: 00000000fff00000-00000000000fffff
	Secondary status: 66MHz- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- <SERR- <PERR-
	BridgeCtl: Parity- SERR+ NoISA- VGA- MAbort- >Reset- FastB2B-
		PriDiscTmr- SecDiscTmr- DiscTmrStat- DiscTmrSERREn-
	Capabilities: [40] Subsystem: 10de:0000
	Capabilities: [48] Power Management version 2
		Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA PME(D0+,D1+,D2+,D3hot+,D3cold+)
		Status: D0 PME-Enable- DSel=0 DScale=0 PME-
	Capabilities: [50] Message Signalled Interrupts: Mask- 64bit+ Queue=0/1 Enable+
		Address: 00000000fee0300c  Data: 4169
	Capabilities: [60] HyperTransport: MSI Mapping Enable+ Fixed-
		Mapping Address Base: 00000000fee00000
	Capabilities: [80] Express (v1) Root Port (Slot+), MSI 00
		DevCap:	MaxPayload 256 bytes, PhantFunc 0, Latency L0s <512ns, L1 <4us
			ExtTag- RBE+ FLReset-
		DevCtl:	Report errors: Correctable+ Non-Fatal+ Fatal+ Unsupported+
			RlxdOrd+ ExtTag- PhantFunc- AuxPwr- NoSnoop+
			MaxPayload 128 bytes, MaxReadReq 512 bytes
		DevSta:	CorrErr- UncorrErr- FatalErr- UnsuppReq- AuxPwr- TransPend-
		LnkCap:	Port #0, Speed 2.5GT/s, Width x16, ASPM L0s L1, Latency L0 <512ns, L1 <4us
			ClockPM- Suprise- LLActRep+ BwNot-
		LnkCtl:	ASPM Disabled; RCB 64 bytes Disabled- Retrain- CommClk-
			ExtSynch- ClockPM- AutWidDis- BWInt- AutBWInt-
		LnkSta:	Speed 2.5GT/s, Width x16, TrErr- Train- SlotClk+ DLActive- BWMgmt- ABWMgmt-
		SltCap:	AttnBtn- PwrCtrl- MRL- AttnInd- PwrInd- HotPlug- Surpise-
			Slot #  0, PowerLimit 0.000000; Interlock- NoCompl-
		SltCtl:	Enable: AttnBtn- PwrFlt- MRL- PresDet- CmdCplt- HPIrq- LinkChg-
			Control: AttnInd Off, PwrInd On, Power- Interlock-
		SltSta:	Status: AttnBtn- PowerFlt- MRL- CmdCplt- PresDet- Interlock-
			Changed: MRL- PresDet- LinkState-
		RootCtl: ErrCorrectable- ErrNon-Fatal- ErrFatal- PMEIntEna- CRSVisible-
		RootCap: CRSVisible-
		RootSta: PME ReqID 0000, PMEStatus- PMEPending-
	Capabilities: [100] Virtual Channel <?>
	Kernel driver in use: pcieport-driver
	Kernel modules: shpchp

00:18.0 0600: 1022:1100
	Control: I/O- Mem- BusMaster- SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx-
	Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
	Capabilities: [80] HyperTransport: Host or Secondary Interface
		!!! Possibly incomplete decoding
		Command: WarmRst+ DblEnd-
		Link Control: CFlE- CST- CFE- <LkFail- Init+ EOC- TXO- <CRCErr=0
		Link Config: MLWI=16bit MLWO=16bit LWI=16bit LWO=16bit
		Revision ID: 1.02

00:18.1 0600: 1022:1101
	Control: I/O- Mem- BusMaster- SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx-
	Status: Cap- 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-

00:18.2 0600: 1022:1102
	Control: I/O- Mem- BusMaster- SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx-
	Status: Cap- 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-

00:18.3 0600: 1022:1103
	Control: I/O- Mem- BusMaster- SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx-
	Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
	Capabilities: [f0] Secure device <?>
	Kernel driver in use: k8temp
	Kernel modules: k8temp

01:01.0 0300: 121a:0003 (rev 03) (prog-if 00 [VGA controller])
	Subsystem: 1102:1017
	Control: I/O+ Mem+ BusMaster- SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx-
	Status: Cap+ 66MHz+ UDF- FastB2B+ ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
	Interrupt: pin A routed to IRQ 10
	Region 0: Memory at fc000000 (32-bit, non-prefetchable) [size=32M]
	Region 1: Memory at f8000000 (32-bit, prefetchable) [size=32M]
	Region 2: I/O ports at e800 [size=256]
	Expansion ROM at fe000000 [disabled] [size=64K]
	Capabilities: [60] Power Management version 1
		Flags: PMEClk- DSI+ D1- D2- AuxCurrent=0mA PME(D0-,D1-,D2-,D3hot-,D3cold-)
		Status: D0 PME-Enable- DSel=0 DScale=0 PME-
	Kernel modules: tdfxfb, i2c-voodoo3

-------------- next part --------------
00:00.0 0500: 10de:0369 (rev a1)
	Subsystem: 1462:7260
	Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR+ FastB2B- DisINTx-
	Status: Cap+ 66MHz+ UDF- FastB2B+ ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
	Latency: 0
	Capabilities: [44] HyperTransport: Slave or Primary Interface
		Command: BaseUnitID=0 UnitCnt=15 MastHost- DefDir- DUL-
		Link Control 0: CFlE+ CST- CFE- <LkFail- Init+ EOC- TXO- <CRCErr=0 IsocEn- LSEn+ ExtCTL- 64b-
		Link Config 0: MLWI=16bit DwFcIn- MLWO=16bit DwFcOut- LWI=16bit DwFcInEn- LWO=16bit DwFcOutEn-
		Link Control 1: CFlE- CST- CFE- <LkFail+ Init- EOC+ TXO+ <CRCErr=0 IsocEn- LSEn- ExtCTL- 64b-
		Link Config 1: MLWI=8bit DwFcIn- MLWO=8bit DwFcOut- LWI=8bit DwFcInEn- LWO=8bit DwFcOutEn-
		Revision ID: 1.03
		Link Frequency 0: 1.0GHz
		Link Error 0: <Prot- <Ovfl- <EOC- CTLTm-
		Link Frequency Capability 0: 200MHz+ 300MHz+ 400MHz+ 500MHz+ 600MHz+ 800MHz+ 1.0GHz+ 1.2GHz- 1.4GHz- 1.6GHz- Vend-
		Feature Capability: IsocFC+ LDTSTOP+ CRCTM- ECTLT- 64bA- UIDRD-
		Link Frequency 1: 200MHz
		Link Error 1: <Prot- <Ovfl- <EOC- CTLTm-
		Link Frequency Capability 1: 200MHz- 300MHz- 400MHz- 500MHz- 600MHz- 800MHz- 1.0GHz- 1.2GHz- 1.4GHz- 1.6GHz- Vend-
		Error Handling: PFlE+ OFlE+ PFE- OFE- EOCFE- RFE- CRCFE- SERRFE- CF- RE- PNFE- ONFE- EOCNFE- RNFE- CRCNFE- SERRNFE-
		Prefetchable memory behind bridge Upper: 00-00
		Bus Number: 00
	Capabilities: [dc] HyperTransport: MSI Mapping Enable+ Fixed-
		Mapping Address Base: 00000000fee00000

00:01.0 0601: 10de:0363 (rev a2)
	Subsystem: 1462:7260
	Control: I/O+ Mem+ BusMaster+ SpecCycle+ MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx-
	Status: Cap- 66MHz+ UDF- FastB2B+ ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
	Latency: 0
	Region 0: I/O ports at 2f00 [size=128]

00:01.1 0c05: 10de:0368 (rev a2)
	Subsystem: 1462:7260
	Control: I/O+ Mem- BusMaster- SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx-
	Status: Cap+ 66MHz+ UDF- FastB2B+ ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
	Interrupt: pin A routed to IRQ 11
	Region 0: I/O ports at 2900 [size=64]
	Region 4: I/O ports at 2d00 [size=64]
	Region 5: I/O ports at 2e00 [size=64]
	Capabilities: [44] Power Management version 2
		Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA PME(D0-,D1-,D2-,D3hot+,D3cold+)
		Status: D0 PME-Enable- DSel=0 DScale=0 PME-
	Kernel driver in use: nForce2_smbus
	Kernel modules: i2c-nforce2

00:02.0 0c03: 10de:036c (rev a1) (prog-if 10)
	Subsystem: 1462:7260
	Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx-
	Status: Cap+ 66MHz+ UDF- FastB2B+ ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
	Latency: 0 (750ns min, 250ns max)
	Interrupt: pin A routed to IRQ 23
	Region 0: Memory at fbffb000 (32-bit, non-prefetchable) [size=4K]
	Capabilities: [44] Power Management version 2
		Flags: PMEClk- DSI- D1+ D2+ AuxCurrent=0mA PME(D0+,D1+,D2+,D3hot+,D3cold+)
		Status: D0 PME-Enable- DSel=0 DScale=0 PME-
	Kernel driver in use: ohci_hcd
	Kernel modules: ohci-hcd

00:02.1 0c03: 10de:036d (rev a2) (prog-if 20)
	Subsystem: 1462:7260
	Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx-
	Status: Cap+ 66MHz+ UDF- FastB2B+ ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
	Latency: 0 (750ns min, 250ns max)
	Interrupt: pin B routed to IRQ 22
	Region 0: Memory at fbffac00 (32-bit, non-prefetchable) [size=256]
	Capabilities: [44] Debug port: BAR=1 offset=0098
	Capabilities: [80] Power Management version 2
		Flags: PMEClk- DSI- D1+ D2+ AuxCurrent=0mA PME(D0+,D1+,D2+,D3hot+,D3cold+)
		Status: D0 PME-Enable- DSel=0 DScale=0 PME-
	Kernel driver in use: ehci_hcd
	Kernel modules: ehci-hcd

00:04.0 0101: 10de:036e (rev a1) (prog-if 8a [Master SecP PriP])
	Subsystem: 1462:7260
	Control: I/O+ Mem- BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx-
	Status: Cap+ 66MHz+ UDF- FastB2B+ ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
	Latency: 0 (750ns min, 250ns max)
	Region 0: [virtual] Memory at 000001f0 (32-bit, non-prefetchable) [disabled] [size=8]
	Region 1: [virtual] Memory at 000003f0 (type 3, non-prefetchable) [disabled] [size=1]
	Region 2: [virtual] Memory at 00000170 (32-bit, non-prefetchable) [disabled] [size=8]
	Region 3: [virtual] Memory at 00000370 (type 3, non-prefetchable) [disabled] [size=1]
	Region 4: I/O ports at ffa0 [size=16]
	Capabilities: [44] Power Management version 2
		Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA PME(D0-,D1-,D2-,D3hot-,D3cold-)
		Status: D0 PME-Enable- DSel=0 DScale=0 PME-
	Kernel driver in use: AMD_IDE
	Kernel modules: amd74xx, ide-pci-generic, ata_generic

00:05.0 0101: 10de:037f (rev a2) (prog-if 85 [Master SecO PriO])
	Subsystem: 1462:7260
	Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx-
	Status: Cap+ 66MHz+ UDF- FastB2B+ ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
	Latency: 0 (750ns min, 250ns max)
	Interrupt: pin A routed to IRQ 20
	Region 0: I/O ports at d480 [size=8]
	Region 1: I/O ports at d400 [size=4]
	Region 2: I/O ports at d080 [size=8]
	Region 3: I/O ports at d000 [size=4]
	Region 4: I/O ports at cc00 [size=16]
	Region 5: Memory at fbff9000 (32-bit, non-prefetchable) [size=4K]
	Capabilities: [44] Power Management version 2
		Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA PME(D0-,D1-,D2-,D3hot-,D3cold-)
		Status: D0 PME-Enable- DSel=0 DScale=0 PME-
	Capabilities: [b0] Message Signalled Interrupts: Mask- 64bit+ Queue=0/2 Enable-
		Address: 0000000000000000  Data: 0000
	Capabilities: [cc] HyperTransport: MSI Mapping Enable+ Fixed+
	Kernel driver in use: sata_nv
	Kernel modules: ide-pci-generic, ata_generic, sata_nv

00:05.1 0101: 10de:037f (rev a2) (prog-if 85 [Master SecO PriO])
	Subsystem: 1462:7260
	Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx-
	Status: Cap+ 66MHz+ UDF- FastB2B+ ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
	Latency: 0 (750ns min, 250ns max)
	Interrupt: pin B routed to IRQ 23
	Region 0: I/O ports at c880 [size=8]
	Region 1: I/O ports at c800 [size=4]
	Region 2: I/O ports at c480 [size=8]
	Region 3: I/O ports at c400 [size=4]
	Region 4: I/O ports at c080 [size=16]
	Region 5: Memory at fbff8000 (32-bit, non-prefetchable) [size=4K]
	Capabilities: [44] Power Management version 2
		Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA PME(D0-,D1-,D2-,D3hot-,D3cold-)
		Status: D0 PME-Enable- DSel=0 DScale=0 PME-
	Capabilities: [b0] Message Signalled Interrupts: Mask- 64bit+ Queue=0/2 Enable-
		Address: 0000000000000000  Data: 0000
	Capabilities: [cc] HyperTransport: MSI Mapping Enable+ Fixed+
	Kernel driver in use: sata_nv
	Kernel modules: ide-pci-generic, ata_generic, sata_nv

00:06.0 0604: 10de:0370 (rev a2) (prog-if 01)
	Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx-
	Status: Cap+ 66MHz+ UDF- FastB2B+ ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
	Latency: 0
	Bus: primary=00, secondary=01, subordinate=01, sec-latency=64
	I/O behind bridge: 0000e000-0000efff
	Memory behind bridge: fc000000-febfffff
	Prefetchable memory behind bridge: f8000000-f9ffffff
	Secondary status: 66MHz- FastB2B+ ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- <SERR- <PERR-
	BridgeCtl: Parity- SERR+ NoISA- VGA+ MAbort- >Reset- FastB2B-
		PriDiscTmr- SecDiscTmr+ DiscTmrStat- DiscTmrSERREn-
	Capabilities: [b8] Subsystem: 1462:7260
	Capabilities: [8c] HyperTransport: MSI Mapping Enable+ Fixed-
		Mapping Address Base: 00000000fee00000

00:06.1 0403: 10de:0371 (rev a2)
	Subsystem: 1462:7260
	Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx-
	Status: Cap+ 66MHz+ UDF- FastB2B+ ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
	Latency: 0 (500ns min, 1250ns max)
	Interrupt: pin B routed to IRQ 22
	Region 0: Memory at fbff4000 (32-bit, non-prefetchable) [size=16K]
	Capabilities: [44] Power Management version 2
		Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA PME(D0-,D1-,D2-,D3hot+,D3cold+)
		Status: D0 PME-Enable- DSel=0 DScale=0 PME-
	Capabilities: [50] Message Signalled Interrupts: Mask+ 64bit+ Queue=0/0 Enable-
		Address: 0000000000000000  Data: 0000
		Masking: 00000000  Pending: 00000000
	Capabilities: [6c] HyperTransport: MSI Mapping Enable+ Fixed+
	Kernel driver in use: HDA Intel
	Kernel modules: snd-hda-intel

00:08.0 0680: 10de:0373 (rev a2)
	Subsystem: 1462:7260
	Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx+
	Status: Cap+ 66MHz+ UDF- FastB2B+ ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
	Latency: 0 (250ns min, 5000ns max)
	Interrupt: pin A routed to IRQ 1274
	Region 0: Memory at fbff3000 (32-bit, non-prefetchable) [size=4K]
	Region 1: I/O ports at c000 [size=8]
	Region 2: Memory at fbffa800 (32-bit, non-prefetchable) [size=256]
	Region 3: Memory at fbffa400 (32-bit, non-prefetchable) [size=16]
	Capabilities: [44] Power Management version 2
		Flags: PMEClk- DSI- D1+ D2+ AuxCurrent=0mA PME(D0+,D1+,D2+,D3hot+,D3cold+)
		Status: D0 PME-Enable+ DSel=0 DScale=0 PME-
	Capabilities: [70] MSI-X: Enable- Mask- TabSize=8
		Vector table: BAR=2 offset=00000000
		PBA: BAR=3 offset=00000000
	Capabilities: [50] Message Signalled Interrupts: Mask+ 64bit+ Queue=0/3 Enable+
		Address: 00000000fee0300c  Data: 4191
		Masking: 000000fe  Pending: 00000000
	Capabilities: [6c] HyperTransport: MSI Mapping Enable+ Fixed+
	Kernel driver in use: forcedeth
	Kernel modules: forcedeth

00:0b.0 0604: 10de:0374 (rev a2)
	Control: I/O- Mem- BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx+
	Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
	Latency: 0, Cache Line Size: 64 bytes
	Bus: primary=00, secondary=02, subordinate=02, sec-latency=0
	I/O behind bridge: 0000f000-00000fff
	Memory behind bridge: fff00000-000fffff
	Prefetchable memory behind bridge: 00000000fff00000-00000000000fffff
	Secondary status: 66MHz- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- <SERR- <PERR-
	BridgeCtl: Parity- SERR+ NoISA- VGA- MAbort- >Reset- FastB2B-
		PriDiscTmr- SecDiscTmr- DiscTmrStat- DiscTmrSERREn-
	Capabilities: [40] Subsystem: 10de:0000
	Capabilities: [48] Power Management version 2
		Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA PME(D0+,D1+,D2+,D3hot+,D3cold+)
		Status: D0 PME-Enable- DSel=0 DScale=0 PME-
	Capabilities: [50] Message Signalled Interrupts: Mask- 64bit+ Queue=0/1 Enable+
		Address: 00000000fee0300c  Data: 4149
	Capabilities: [60] HyperTransport: MSI Mapping Enable+ Fixed-
		Mapping Address Base: 00000000fee00000
	Capabilities: [80] Express (v1) Root Port (Slot+), MSI 00
		DevCap:	MaxPayload 256 bytes, PhantFunc 0, Latency L0s <512ns, L1 <4us
			ExtTag- RBE+ FLReset-
		DevCtl:	Report errors: Correctable+ Non-Fatal+ Fatal+ Unsupported+
			RlxdOrd+ ExtTag- PhantFunc- AuxPwr- NoSnoop+
			MaxPayload 128 bytes, MaxReadReq 512 bytes
		DevSta:	CorrErr- UncorrErr- FatalErr- UnsuppReq- AuxPwr- TransPend-
		LnkCap:	Port #4, Speed 2.5GT/s, Width x1, ASPM L0s L1, Latency L0 <512ns, L1 <4us
			ClockPM- Suprise- LLActRep+ BwNot-
		LnkCtl:	ASPM Disabled; RCB 64 bytes Disabled- Retrain- CommClk-
			ExtSynch- ClockPM- AutWidDis- BWInt- AutBWInt-
		LnkSta:	Speed 2.5GT/s, Width x4, TrErr- Train- SlotClk+ DLActive- BWMgmt- ABWMgmt-
		SltCap:	AttnBtn- PwrCtrl- MRL- AttnInd- PwrInd- HotPlug- Surpise-
			Slot #  0, PowerLimit 0.000000; Interlock- NoCompl-
		SltCtl:	Enable: AttnBtn- PwrFlt- MRL- PresDet- CmdCplt- HPIrq- LinkChg-
			Control: AttnInd Off, PwrInd On, Power- Interlock-
		SltSta:	Status: AttnBtn- PowerFlt- MRL- CmdCplt- PresDet- Interlock-
			Changed: MRL- PresDet- LinkState-
		RootCtl: ErrCorrectable- ErrNon-Fatal- ErrFatal- PMEIntEna- CRSVisible-
		RootCap: CRSVisible-
		RootSta: PME ReqID 0000, PMEStatus- PMEPending-
	Capabilities: [100] Virtual Channel <?>
	Kernel driver in use: pcieport-driver
	Kernel modules: shpchp

00:0c.0 0604: 10de:0374 (rev a2)
	Control: I/O- Mem- BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx+
	Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
	Latency: 0, Cache Line Size: 64 bytes
	Bus: primary=00, secondary=03, subordinate=03, sec-latency=0
	I/O behind bridge: 0000f000-00000fff
	Memory behind bridge: fff00000-000fffff
	Prefetchable memory behind bridge: 00000000fff00000-00000000000fffff
	Secondary status: 66MHz- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- <SERR- <PERR-
	BridgeCtl: Parity- SERR+ NoISA- VGA- MAbort- >Reset- FastB2B-
		PriDiscTmr- SecDiscTmr- DiscTmrStat- DiscTmrSERREn-
	Capabilities: [40] Subsystem: 10de:0000
	Capabilities: [48] Power Management version 2
		Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA PME(D0+,D1+,D2+,D3hot+,D3cold+)
		Status: D0 PME-Enable- DSel=0 DScale=0 PME-
	Capabilities: [50] Message Signalled Interrupts: Mask- 64bit+ Queue=0/1 Enable+
		Address: 00000000fee0300c  Data: 4151
	Capabilities: [60] HyperTransport: MSI Mapping Enable+ Fixed-
		Mapping Address Base: 00000000fee00000
	Capabilities: [80] Express (v1) Root Port (Slot+), MSI 00
		DevCap:	MaxPayload 256 bytes, PhantFunc 0, Latency L0s <512ns, L1 <4us
			ExtTag- RBE+ FLReset-
		DevCtl:	Report errors: Correctable+ Non-Fatal+ Fatal+ Unsupported+
			RlxdOrd+ ExtTag- PhantFunc- AuxPwr- NoSnoop+
			MaxPayload 128 bytes, MaxReadReq 512 bytes
		DevSta:	CorrErr- UncorrErr- FatalErr- UnsuppReq- AuxPwr- TransPend-
		LnkCap:	Port #3, Speed 2.5GT/s, Width x1, ASPM L0s L1, Latency L0 <512ns, L1 <4us
			ClockPM- Suprise- LLActRep+ BwNot-
		LnkCtl:	ASPM Disabled; RCB 64 bytes Disabled- Retrain- CommClk-
			ExtSynch- ClockPM- AutWidDis- BWInt- AutBWInt-
		LnkSta:	Speed 2.5GT/s, Width x4, TrErr- Train- SlotClk+ DLActive- BWMgmt- ABWMgmt-
		SltCap:	AttnBtn- PwrCtrl- MRL- AttnInd- PwrInd- HotPlug- Surpise-
			Slot #  0, PowerLimit 0.000000; Interlock- NoCompl-
		SltCtl:	Enable: AttnBtn- PwrFlt- MRL- PresDet- CmdCplt- HPIrq- LinkChg-
			Control: AttnInd Off, PwrInd On, Power- Interlock-
		SltSta:	Status: AttnBtn- PowerFlt- MRL- CmdCplt- PresDet- Interlock-
			Changed: MRL- PresDet- LinkState-
		RootCtl: ErrCorrectable- ErrNon-Fatal- ErrFatal- PMEIntEna- CRSVisible-
		RootCap: CRSVisible-
		RootSta: PME ReqID 0000, PMEStatus- PMEPending-
	Capabilities: [100] Virtual Channel <?>
	Kernel driver in use: pcieport-driver
	Kernel modules: shpchp

00:0d.0 0604: 10de:0378 (rev a2)
	Control: I/O- Mem- BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx+
	Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
	Latency: 0, Cache Line Size: 64 bytes
	Bus: primary=00, secondary=04, subordinate=04, sec-latency=0
	I/O behind bridge: 0000f000-00000fff
	Memory behind bridge: fff00000-000fffff
	Prefetchable memory behind bridge: 00000000fff00000-00000000000fffff
	Secondary status: 66MHz- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- <SERR- <PERR-
	BridgeCtl: Parity- SERR+ NoISA- VGA- MAbort- >Reset- FastB2B-
		PriDiscTmr- SecDiscTmr- DiscTmrStat- DiscTmrSERREn-
	Capabilities: [40] Subsystem: 10de:0000
	Capabilities: [48] Power Management version 2
		Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA PME(D0+,D1+,D2+,D3hot+,D3cold+)
		Status: D0 PME-Enable- DSel=0 DScale=0 PME-
	Capabilities: [50] Message Signalled Interrupts: Mask- 64bit+ Queue=0/1 Enable+
		Address: 00000000fee0300c  Data: 4159
	Capabilities: [60] HyperTransport: MSI Mapping Enable+ Fixed-
		Mapping Address Base: 00000000fee00000
	Capabilities: [80] Express (v1) Root Port (Slot+), MSI 00
		DevCap:	MaxPayload 256 bytes, PhantFunc 0, Latency L0s <512ns, L1 <4us
			ExtTag- RBE+ FLReset-
		DevCtl:	Report errors: Correctable+ Non-Fatal+ Fatal+ Unsupported+
			RlxdOrd+ ExtTag- PhantFunc- AuxPwr- NoSnoop+
			MaxPayload 128 bytes, MaxReadReq 512 bytes
		DevSta:	CorrErr- UncorrErr- FatalErr- UnsuppReq- AuxPwr- TransPend-
		LnkCap:	Port #2, Speed 2.5GT/s, Width x1, ASPM L0s L1, Latency L0 <512ns, L1 <4us
			ClockPM- Suprise- LLActRep+ BwNot-
		LnkCtl:	ASPM Disabled; RCB 64 bytes Disabled- Retrain- CommClk-
			ExtSynch- ClockPM- AutWidDis- BWInt- AutBWInt-
		LnkSta:	Speed 2.5GT/s, Width x4, TrErr- Train- SlotClk+ DLActive- BWMgmt- ABWMgmt-
		SltCap:	AttnBtn- PwrCtrl- MRL- AttnInd- PwrInd- HotPlug- Surpise-
			Slot #  0, PowerLimit 0.000000; Interlock- NoCompl-
		SltCtl:	Enable: AttnBtn- PwrFlt- MRL- PresDet- CmdCplt- HPIrq- LinkChg-
			Control: AttnInd Off, PwrInd On, Power- Interlock-
		SltSta:	Status: AttnBtn- PowerFlt- MRL- CmdCplt- PresDet- Interlock-
			Changed: MRL- PresDet- LinkState-
		RootCtl: ErrCorrectable- ErrNon-Fatal- ErrFatal- PMEIntEna- CRSVisible-
		RootCap: CRSVisible-
		RootSta: PME ReqID 0000, PMEStatus- PMEPending-
	Capabilities: [100] Virtual Channel <?>
	Kernel driver in use: pcieport-driver
	Kernel modules: shpchp

00:0e.0 0604: 10de:0375 (rev a2)
	Control: I/O- Mem- BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx+
	Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
	Latency: 0, Cache Line Size: 64 bytes
	Bus: primary=00, secondary=05, subordinate=05, sec-latency=0
	I/O behind bridge: 0000f000-00000fff
	Memory behind bridge: fff00000-000fffff
	Prefetchable memory behind bridge: 00000000fff00000-00000000000fffff
	Secondary status: 66MHz- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- <SERR- <PERR-
	BridgeCtl: Parity- SERR+ NoISA- VGA- MAbort- >Reset- FastB2B-
		PriDiscTmr- SecDiscTmr- DiscTmrStat- DiscTmrSERREn-
	Capabilities: [40] Subsystem: 10de:0000
	Capabilities: [48] Power Management version 2
		Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA PME(D0+,D1+,D2+,D3hot+,D3cold+)
		Status: D0 PME-Enable- DSel=0 DScale=0 PME-
	Capabilities: [50] Message Signalled Interrupts: Mask- 64bit+ Queue=0/1 Enable+
		Address: 00000000fee0300c  Data: 4161
	Capabilities: [60] HyperTransport: MSI Mapping Enable+ Fixed-
		Mapping Address Base: 00000000fee00000
	Capabilities: [80] Express (v1) Root Port (Slot+), MSI 00
		DevCap:	MaxPayload 256 bytes, PhantFunc 0, Latency L0s <512ns, L1 <4us
			ExtTag- RBE+ FLReset-
		DevCtl:	Report errors: Correctable+ Non-Fatal+ Fatal+ Unsupported+
			RlxdOrd+ ExtTag- PhantFunc- AuxPwr- NoSnoop+
			MaxPayload 128 bytes, MaxReadReq 512 bytes
		DevSta:	CorrErr- UncorrErr- FatalErr- UnsuppReq- AuxPwr- TransPend-
		LnkCap:	Port #1, Speed 2.5GT/s, Width x1, ASPM L0s L1, Latency L0 <512ns, L1 <4us
			ClockPM- Suprise- LLActRep+ BwNot-
		LnkCtl:	ASPM Disabled; RCB 64 bytes Disabled- Retrain- CommClk-
			ExtSynch- ClockPM- AutWidDis- BWInt- AutBWInt-
		LnkSta:	Speed 2.5GT/s, Width x8, TrErr- Train- SlotClk+ DLActive- BWMgmt- ABWMgmt-
		SltCap:	AttnBtn- PwrCtrl- MRL- AttnInd- PwrInd- HotPlug- Surpise-
			Slot #  0, PowerLimit 0.000000; Interlock- NoCompl-
		SltCtl:	Enable: AttnBtn- PwrFlt- MRL- PresDet- CmdCplt- HPIrq- LinkChg-
			Control: AttnInd Off, PwrInd On, Power- Interlock-
		SltSta:	Status: AttnBtn- PowerFlt- MRL- CmdCplt- PresDet- Interlock-
			Changed: MRL- PresDet- LinkState-
		RootCtl: ErrCorrectable- ErrNon-Fatal- ErrFatal- PMEIntEna- CRSVisible-
		RootCap: CRSVisible-
		RootSta: PME ReqID 0000, PMEStatus- PMEPending-
	Capabilities: [100] Virtual Channel <?>
	Kernel driver in use: pcieport-driver
	Kernel modules: shpchp

00:0f.0 0604: 10de:0377 (rev a2)
	Control: I/O- Mem- BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx+
	Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
	Latency: 0, Cache Line Size: 64 bytes
	Bus: primary=00, secondary=06, subordinate=06, sec-latency=0
	I/O behind bridge: 0000f000-00000fff
	Memory behind bridge: fff00000-000fffff
	Prefetchable memory behind bridge: 00000000fff00000-00000000000fffff
	Secondary status: 66MHz- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- <SERR- <PERR-
	BridgeCtl: Parity- SERR+ NoISA- VGA- MAbort- >Reset- FastB2B-
		PriDiscTmr- SecDiscTmr- DiscTmrStat- DiscTmrSERREn-
	Capabilities: [40] Subsystem: 10de:0000
	Capabilities: [48] Power Management version 2
		Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA PME(D0+,D1+,D2+,D3hot+,D3cold+)
		Status: D0 PME-Enable- DSel=0 DScale=0 PME-
	Capabilities: [50] Message Signalled Interrupts: Mask- 64bit+ Queue=0/1 Enable+
		Address: 00000000fee0300c  Data: 4169
	Capabilities: [60] HyperTransport: MSI Mapping Enable+ Fixed-
		Mapping Address Base: 00000000fee00000
	Capabilities: [80] Express (v1) Root Port (Slot+), MSI 00
		DevCap:	MaxPayload 256 bytes, PhantFunc 0, Latency L0s <512ns, L1 <4us
			ExtTag- RBE+ FLReset-
		DevCtl:	Report errors: Correctable+ Non-Fatal+ Fatal+ Unsupported+
			RlxdOrd+ ExtTag- PhantFunc- AuxPwr- NoSnoop+
			MaxPayload 128 bytes, MaxReadReq 512 bytes
		DevSta:	CorrErr- UncorrErr- FatalErr- UnsuppReq- AuxPwr- TransPend-
		LnkCap:	Port #0, Speed 2.5GT/s, Width x16, ASPM L0s L1, Latency L0 <512ns, L1 <4us
			ClockPM- Suprise- LLActRep+ BwNot-
		LnkCtl:	ASPM Disabled; RCB 64 bytes Disabled- Retrain- CommClk-
			ExtSynch- ClockPM- AutWidDis- BWInt- AutBWInt-
		LnkSta:	Speed 2.5GT/s, Width x16, TrErr- Train- SlotClk+ DLActive- BWMgmt- ABWMgmt-
		SltCap:	AttnBtn- PwrCtrl- MRL- AttnInd- PwrInd- HotPlug- Surpise-
			Slot #  0, PowerLimit 0.000000; Interlock- NoCompl-
		SltCtl:	Enable: AttnBtn- PwrFlt- MRL- PresDet- CmdCplt- HPIrq- LinkChg-
			Control: AttnInd Off, PwrInd On, Power- Interlock-
		SltSta:	Status: AttnBtn- PowerFlt- MRL- CmdCplt- PresDet- Interlock-
			Changed: MRL- PresDet- LinkState-
		RootCtl: ErrCorrectable- ErrNon-Fatal- ErrFatal- PMEIntEna- CRSVisible-
		RootCap: CRSVisible-
		RootSta: PME ReqID 0000, PMEStatus- PMEPending-
	Capabilities: [100] Virtual Channel <?>
	Kernel driver in use: pcieport-driver
	Kernel modules: shpchp

00:18.0 0600: 1022:1100
	Control: I/O- Mem- BusMaster- SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx-
	Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
	Capabilities: [80] HyperTransport: Host or Secondary Interface
		Command: WarmRst+ DblEnd- DevNum=0 ChainSide- HostHide+ Slave- <EOCErr- DUL-
		Link Control: CFlE- CST- CFE- <LkFail- Init+ EOC- TXO- <CRCErr=0 IsocEn- LSEn- ExtCTL- 64b-
		Link Config: MLWI=16bit DwFcIn- MLWO=16bit DwFcOut- LWI=16bit DwFcInEn- LWO=16bit DwFcOutEn-
		Revision ID: 1.02
		Link Frequency: 1.0GHz
		Link Error: <Prot- <Ovfl- <EOC- CTLTm-
		Link Frequency Capability: 200MHz+ 300MHz- 400MHz+ 500MHz- 600MHz+ 800MHz+ 1.0GHz+ 1.2GHz- 1.4GHz- 1.6GHz- Vend-
		Feature Capability: IsocFC- LDTSTOP+ CRCTM- ECTLT- 64bA- UIDRD- ExtRS- UCnfE-

00:18.1 0600: 1022:1101
	Control: I/O- Mem- BusMaster- SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx-
	Status: Cap- 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-

00:18.2 0600: 1022:1102
	Control: I/O- Mem- BusMaster- SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx-
	Status: Cap- 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-

00:18.3 0600: 1022:1103
	Control: I/O- Mem- BusMaster- SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx-
	Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
	Capabilities: [f0] Secure device <?>
	Kernel driver in use: k8temp
	Kernel modules: k8temp

01:01.0 0300: 121a:0003 (rev 03)
	Subsystem: 1102:1017
	Control: I/O+ Mem+ BusMaster- SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx-
	Status: Cap+ 66MHz+ UDF- FastB2B+ ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
	Interrupt: pin A routed to IRQ 10
	Region 0: Memory at fc000000 (32-bit, non-prefetchable) [size=32M]
	Region 1: Memory at f8000000 (32-bit, prefetchable) [size=32M]
	Region 2: I/O ports at e800 [size=256]
	Expansion ROM at fe000000 [disabled] [size=64K]
	Capabilities: [60] Power Management version 1
		Flags: PMEClk- DSI+ D1- D2- AuxCurrent=0mA PME(D0-,D1-,D2-,D3hot-,D3cold-)
		Status: D0 PME-Enable- DSel=0 DScale=0 PME-
	Kernel modules: tdfxfb, i2c-voodoo3

-------------- next part --------------
A non-text attachment was scrubbed...
Name: lspci-output.diff
Type: text/x-diff
Size: 5144 bytes
Desc: not available
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20081104/ff3bbac9/attachment.bin>

From JasonZhao at viatech.com.cn  Tue Nov  4 03:42:32 2008
From: JasonZhao at viatech.com.cn (JasonZhao at viatech.com.cn)
Date: Tue, 4 Nov 2008 10:42:32 +0800
Subject: [coreboot] coreboot.v2+seabios on 440bx: option roms not
In-Reply-To: <mailman.729.1225754644.24162.coreboot@coreboot.org>
References: <mailman.729.1225754644.24162.coreboot@coreboot.org>
Message-ID: <9156F9F8217CD44898ABE1E581FAFF8815B699@exchbj02.viatech.com.bj>

I think the patch is in this link.  
http://www.coreboot.org/pipermail/coreboot/2008-September/038551.html
Is this one, Myles?

I am also now trying to boot XP with SeaBios as payload on VIA's board. 


on 30/10/2008 16:52 Myles Watson said the following:
> 
>> -----Original Message-----
>> From: Andriy Gapon [mailto:avg at icyb.net.ua]
>> Sent: Thursday, October 30, 2008 8:43 AM
>> To: Myles Watson
>> Cc: 'Coreboot'
>> Subject: Re: [coreboot] coreboot.v2+seabios on 440bx: option roms not

>> found
>>
>> on 30/10/2008 16:34 Myles Watson said the following:
>>>> -----Original Message-----
>>>> From: coreboot-bounces at coreboot.org [mailto:coreboot-
>> bounces at coreboot.org]
>>>> On Behalf Of Andriy Gapon
>>>> Sent: Thursday, October 30, 2008 8:25 AM
>>>> To: Coreboot
>>>> Subject: [coreboot] coreboot.v2+seabios on 440bx: option roms not 
>>>> found
>>>>
>>>>
>>>> In northbridge/intel/i440bx/raminit.c:sdram_set_spd_registers all 
>>>> PAM registers are programmed for RAM R/W access (0x33).
>>>> When SeaBIOS searches for option ROMs (including VGA ROM) it 
>>>> doesn't do anything about PAM, so it sees empty memory instead of
the ROMs.
>>>>
>>>> I am not sure what is the best solution here. It is debatable how 
>>>> coreboot should set PAM register, and it is not right to make 
>>>> SeaBIOS too hardware dependent.
>>>>
>>>> Maybe coreboot could somehow export functions for setting access to

>>>> option ROM space (aka legacy memory segments) and SeaBIOS could 
>>>> call
>> them.
>>> I think SeaBIOS expects Coreboot to copy the option ROM to 0xc0000 
>>> in
>> RAM.
>>> That way SeaBIOS gets to stay hardware agnostic.
>>>
>> Makes sense!
>> But it doesn't look like this does actually happen (by default).
>> I am playing with msi/ms6147 target (under heavily tweaked qemu).
> 
> You're right.  It doesn't happen by default.  Kevin sent a simple 
> patch to the list, which I can't find right now :(
> 
> Basically you tell coreboot to run the ROM, but comment out the 
> execution right after the copy.  Let me know if you can't find it, and

> I'll try to help you dig.

I found a post where Kevin talks about this but no patch.

I am thinking about this approach for 440BX: set PAM registers to "read
from ROM, write to RAM" mode, copy the whole range onto itself, set PAM
register to R/W RAM mode.
I am not sure if this better be done for all legacy segments (0xC0000 -
0xFFFFF range) or only for option ROM segments (0xC0000 - 0xDFFFF range)
excluding BIOS Area and BIOS Extension segments.

P.S.
This approach won't work in stock qemu because of incorrect
implementation (absence, actually) of emulation of this "mixed" PAM
mode.




From mylesgw at gmail.com  Tue Nov  4 04:40:47 2008
From: mylesgw at gmail.com (Myles Watson)
Date: Mon, 3 Nov 2008 20:40:47 -0700
Subject: [coreboot] coreboot.v2+seabios on 440bx: option roms not
In-Reply-To: <9156F9F8217CD44898ABE1E581FAFF8815B699@exchbj02.viatech.com.bj>
References: <mailman.729.1225754644.24162.coreboot@coreboot.org>
	<9156F9F8217CD44898ABE1E581FAFF8815B699@exchbj02.viatech.com.bj>
Message-ID: <9C100C6E48474D3D9F603F40AB48D83E@chimp>



> -----Original Message-----
> From: coreboot-bounces at coreboot.org [mailto:coreboot-bounces at coreboot.org]
> On Behalf Of JasonZhao at viatech.com.cn
> Sent: Monday, November 03, 2008 7:43 PM
> To: avg at icyb.net.ua
> Cc: coreboot at coreboot.org
> Subject: Re: [coreboot] coreboot.v2+seabios on 440bx: option roms not
> 
> I think the patch is in this link.
> http://www.coreboot.org/pipermail/coreboot/2008-September/038551.html
> Is this one, Myles?

That looks more complex than what I was thinking of.  I'm attaching a patch
that returns after copying the ROM to RAM, but before executing it.  It
should work as long as the board you're using uses the generic pci ROM code.
 
> I am also now trying to boot XP with SeaBios as payload on VIA's board.

Great.  Let us know how it goes.

Thanks,
Myles


-------------- next part --------------
A non-text attachment was scrubbed...
Name: no_rom_run.diff
Type: application/octet-stream
Size: 285 bytes
Desc: not available
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20081103/d98b69b3/attachment.obj>

From yinghailu at gmail.com  Tue Nov  4 04:43:27 2008
From: yinghailu at gmail.com (yhlu)
Date: Mon, 3 Nov 2008 19:43:27 -0800
Subject: [coreboot] PCI domains
In-Reply-To: <13426df10811031700t7e697b69r9281ebed0278b83e@mail.gmail.com>
References: <2831fecf0811030830p7d563c0dpaef6107fe2d0ae5e@mail.gmail.com>
	<490F2C28.9030602@gmx.net>
	<2831fecf0811031137n5f26b594m8d1fd33e1de2e6ce@mail.gmail.com>
	<2ea3fae10811031146y751d9d12v9b67d3e2fdb78cd5@mail.gmail.com>
	<13426df10811031152v635711a0tc4c96e5d38e3abc2@mail.gmail.com>
	<2ea3fae10811031344o7c1b6278ue57c9f5b7ed89aea@mail.gmail.com>
	<13426df10811031700t7e697b69r9281ebed0278b83e@mail.gmail.com>
Message-ID: <2ea3fae10811031943x62a561d0r786662c3b46ca619@mail.gmail.com>

On Mon, Nov 3, 2008 at 5:00 PM, ron minnich <rminnich at gmail.com> wrote:

> Where do the domain bits live in the chipset?
>

MSR

they need to domain_nr + bus_nr to dicide how to direct io range...

YH
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20081103/f9124821/attachment.html>

From rminnich at gmail.com  Tue Nov  4 04:44:20 2008
From: rminnich at gmail.com (ron minnich)
Date: Mon, 3 Nov 2008 19:44:20 -0800
Subject: [coreboot] PCI domains
In-Reply-To: <2ea3fae10811031943x62a561d0r786662c3b46ca619@mail.gmail.com>
References: <2831fecf0811030830p7d563c0dpaef6107fe2d0ae5e@mail.gmail.com>
	<490F2C28.9030602@gmx.net>
	<2831fecf0811031137n5f26b594m8d1fd33e1de2e6ce@mail.gmail.com>
	<2ea3fae10811031146y751d9d12v9b67d3e2fdb78cd5@mail.gmail.com>
	<13426df10811031152v635711a0tc4c96e5d38e3abc2@mail.gmail.com>
	<2ea3fae10811031344o7c1b6278ue57c9f5b7ed89aea@mail.gmail.com>
	<13426df10811031700t7e697b69r9281ebed0278b83e@mail.gmail.com>
	<2ea3fae10811031943x62a561d0r786662c3b46ca619@mail.gmail.com>
Message-ID: <13426df10811031944p50f80a7buc5889ae14067cc71@mail.gmail.com>

On Mon, Nov 3, 2008 at 7:43 PM, yhlu <yinghailu at gmail.com> wrote:
>
>
> On Mon, Nov 3, 2008 at 5:00 PM, ron minnich <rminnich at gmail.com> wrote:
>>
>> Where do the domain bits live in the chipset?
>
> MSR
>
> they need to domain_nr + bus_nr to dicide how to direct io range...
>

thanks
ron



From rminnich at gmail.com  Tue Nov  4 04:45:47 2008
From: rminnich at gmail.com (ron minnich)
Date: Mon, 3 Nov 2008 19:45:47 -0800
Subject: [coreboot] coreboot.v2+seabios on 440bx: option roms not
In-Reply-To: <9C100C6E48474D3D9F603F40AB48D83E@chimp>
References: <mailman.729.1225754644.24162.coreboot@coreboot.org>
	<9156F9F8217CD44898ABE1E581FAFF8815B699@exchbj02.viatech.com.bj>
	<9C100C6E48474D3D9F603F40AB48D83E@chimp>
Message-ID: <13426df10811031945k5a9a30bdsdff5b69d9ed421b9@mail.gmail.com>

On Mon, Nov 3, 2008 at 7:40 PM, Myles Watson <mylesgw at gmail.com> wrote:
>
>
>> -----Original Message-----
>> From: coreboot-bounces at coreboot.org [mailto:coreboot-bounces at coreboot.org]
>> On Behalf Of JasonZhao at viatech.com.cn
>> Sent: Monday, November 03, 2008 7:43 PM
>> To: avg at icyb.net.ua
>> Cc: coreboot at coreboot.org
>> Subject: Re: [coreboot] coreboot.v2+seabios on 440bx: option roms not
>>
>> I think the patch is in this link.
>> http://www.coreboot.org/pipermail/coreboot/2008-September/038551.html
>> Is this one, Myles?
>
> That looks more complex than what I was thinking of.  I'm attaching a patch
> that returns after copying the ROM to RAM, but before executing it.  It
> should work as long as the board you're using uses the generic pci ROM code.
>
>> I am also now trying to boot XP with SeaBios as payload on VIA's board.
>
> Great.  Let us know how it goes.
>

This worked for Peter and me this week.

We retried with an ACPI install of XP and it hangs at Mup.sys. I think
we need some fixes for ACPI.

jason, which board are you using, I should try to get one.

But seabios works wonderfully well, I am really impressed!

ron



From JasonZhao at viatech.com.cn  Tue Nov  4 05:08:51 2008
From: JasonZhao at viatech.com.cn (JasonZhao at viatech.com.cn)
Date: Tue, 4 Nov 2008 12:08:51 +0800
Subject: [coreboot] coreboot.v2+seabios on 440bx: option roms not
In-Reply-To: <13426df10811031945k5a9a30bdsdff5b69d9ed421b9@mail.gmail.com>
References: <mailman.729.1225754644.24162.coreboot@coreboot.org>
	<9156F9F8217CD44898ABE1E581FAFF8815B699@exchbj02.viatech.com.bj>
	<9C100C6E48474D3D9F603F40AB48D83E@chimp>
	<13426df10811031945k5a9a30bdsdff5b69d9ed421b9@mail.gmail.com>
Message-ID: <9156F9F8217CD44898ABE1E581FAFF8815B6E9@exchbj02.viatech.com.bj>

Hi ron,
I use VX800(puls C7), don't know if this chipset has appear on market:).

I had used coreboot+filo to boot ubuntu8.04 three day before, and
everything are perfect,
ide,network,audio,sata,usb,s3(kb+mouse+powerbutton can
wake),s4,powerdown,reboot.

I began to try seabios from yesterday. I applied the patch in this link
http://www.coreboot.org/pipermail/coreboot/2008-September/038551.html,
And use seabios as payload. 

Now I just download the file bios.bin.elf-20081027 from seabios's site,
and didn't run "make" myself, and seabios stop at somewhere.  But this
is just a beginning:)

Jason zhao

-----Original Message-----
From: ron minnich [mailto:rminnich at gmail.com] 
Sent: Tuesday, November 04, 2008 11:46 AM
To: Myles Watson
Cc: Jason Zhao; avg at icyb.net.ua; coreboot at coreboot.org
Subject: Re: [coreboot] coreboot.v2+seabios on 440bx: option roms not

On Mon, Nov 3, 2008 at 7:40 PM, Myles Watson <mylesgw at gmail.com> wrote:
>
>
>> -----Original Message-----
>> From: coreboot-bounces at coreboot.org
[mailto:coreboot-bounces at coreboot.org]
>> On Behalf Of JasonZhao at viatech.com.cn
>> Sent: Monday, November 03, 2008 7:43 PM
>> To: avg at icyb.net.ua
>> Cc: coreboot at coreboot.org
>> Subject: Re: [coreboot] coreboot.v2+seabios on 440bx: option roms not
>>
>> I think the patch is in this link.
>> http://www.coreboot.org/pipermail/coreboot/2008-September/038551.html
>> Is this one, Myles?
>
> That looks more complex than what I was thinking of.  I'm attaching a
patch
> that returns after copying the ROM to RAM, but before executing it.
It
> should work as long as the board you're using uses the generic pci ROM
code.
>
>> I am also now trying to boot XP with SeaBios as payload on VIA's
board.
>
> Great.  Let us know how it goes.
>

This worked for Peter and me this week.

We retried with an ACPI install of XP and it hangs at Mup.sys. I think
we need some fixes for ACPI.

jason, which board are you using, I should try to get one.

But seabios works wonderfully well, I am really impressed!

ron




From c-d.hailfinger.devel.2006 at gmx.net  Tue Nov  4 02:56:50 2008
From: c-d.hailfinger.devel.2006 at gmx.net (Carl-Daniel Hailfinger)
Date: Tue, 04 Nov 2008 02:56:50 +0100
Subject: [coreboot] [PCI Utilities PATCH] Decode HyperTransport 1.02 as 1.03
Message-ID: <490FABE2.4040806@gmx.net>

AMD K8 processors claim that they're using HyperTransport 1.02, but the
publicly available documentation (specifically the BKDG) states that the
HT version is 1.03 in reality.

lspci will issue a warning "!!! Possibly incomplete decoding" and only
decode some basic HT properties for HT versions before 1.03.
Move that boundary down to HT version 1.02.

Example output before the patch:

00:18.0 0600: 1022:1100
	Control: I/O- Mem- BusMaster- SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx-
	Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
	Capabilities: [80] HyperTransport: Host or Secondary Interface
		!!! Possibly incomplete decoding
		Command: WarmRst+ DblEnd-
		Link Control: CFlE- CST- CFE- <LkFail- Init+ EOC- TXO- <CRCErr=0
		Link Config: MLWI=16bit MLWO=16bit LWI=16bit LWO=16bit
		Revision ID: 1.02

Example output with the same processor after the patch:
00:18.0 0600: 1022:1100
	Control: I/O- Mem- BusMaster- SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx-
	Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
	Capabilities: [80] HyperTransport: Host or Secondary Interface
		Command: WarmRst+ DblEnd- DevNum=0 ChainSide- HostHide+ Slave- <EOCErr- DUL-
		Link Control: CFlE- CST- CFE- <LkFail- Init+ EOC- TXO- <CRCErr=0 IsocEn- LSEn- ExtCTL- 64b-
		Link Config: MLWI=16bit DwFcIn- MLWO=16bit DwFcOut- LWI=16bit DwFcInEn- LWO=16bit DwFcOutEn-
		Revision ID: 1.02
		Link Frequency: 1.0GHz
		Link Error: <Prot- <Ovfl- <EOC- CTLTm-
		Link Frequency Capability: 200MHz+ 300MHz- 400MHz+ 500MHz- 600MHz+ 800MHz+ 1.0GHz+ 1.2GHz- 1.4GHz- 1.6GHz- Vend-
		Feature Capability: IsocFC- LDTSTOP+ CRCTM- ECTLT- 64bA- UIDRD- ExtRS- UCnfE-


Signed-off-by: Carl-Daniel Hailfinger <c-d.hailfinger.devel.2006 at gmx.net>

-- 
http://www.hailfinger.org/

-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0001-Decode-HyperTransport-1.02-as-1.03.patch
Type: text/x-patch
Size: 5313 bytes
Desc: not available
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20081104/22936f3d/attachment.patch>

From c-d.hailfinger.devel.2006 at gmx.net  Tue Nov  4 12:15:13 2008
From: c-d.hailfinger.devel.2006 at gmx.net (Carl-Daniel Hailfinger)
Date: Tue, 04 Nov 2008 12:15:13 +0100
Subject: [coreboot] [v3] [patch] k8 fid/vid update
In-Reply-To: <490F7F07.5050603@amd.com>
References: <490F7B3C.1010308@amd.com> <490F7F07.5050603@amd.com>
Message-ID: <49102EC1.3090302@gmx.net>

On 03.11.2008 23:45, Marc Jones wrote:
> Update K8 FID/VID setupto match coreboot v2. Add support for 100MHz FIDs (revG).
>
> Signed-off-by: Marc Jones <marc.jones at amd.com>
>   

The added comments are really valuable.

Acked-by: Carl-Daniel Hailfinger <c-d.hailfinger.devel.2006 at gmx.net>


Regards,
Carl-Daniel

-- 
http://www.hailfinger.org/




From uwe at hermann-uwe.de  Tue Nov  4 12:58:04 2008
From: uwe at hermann-uwe.de (Uwe Hermann)
Date: Tue, 4 Nov 2008 12:58:04 +0100
Subject: [coreboot] [PATCH] flashrom: Add support for 8 new chips,
	fix	up 2 existing chips
In-Reply-To: <20081103012413.8599.qmail@stuge.se>
References: <490E4C33.2020709@gmx.net> <20081103012413.8599.qmail@stuge.se>
Message-ID: <20081104115804.GB13674@greenwood>

Patch is

Acked-by: Uwe Hermann <uwe at hermann-uwe.de>

On Mon, Nov 03, 2008 at 02:24:13AM +0100, Peter Stuge wrote:
> Carl-Daniel Hailfinger wrote:
> > +#define MX_29F002B		0x34
> > +#define MX_29F002T		0xB0
> 
> Yeah. Please don't do this. Put them in the struct.

I don't remember the outcome of that flashrom discussion a while ago,
but either way, this shouldn't hold up the commit. If we want to get rid
of the #defines that should happen in one commit for all of the chips.


Uwe.
-- 
http://www.hermann-uwe.de  | http://www.holsham-traders.de
http://www.crazy-hacks.org | http://www.unmaintained-free-software.org



From svn at coreboot.org  Tue Nov  4 13:11:13 2008
From: svn at coreboot.org (svn at coreboot.org)
Date: Tue,  4 Nov 2008 13:11:13 +0100
Subject: [coreboot] r3730 - trunk/util/flashrom
Message-ID: <mailman.2383.1355071424.16123.coreboot@coreboot.org>

Author: hailfinger
Date: 2008-11-04 13:11:12 +0100 (Tue, 04 Nov 2008)
New Revision: 3730

Modified:
   trunk/util/flashrom/flash.h
   trunk/util/flashrom/flashchips.c
Log:
Add support for 8 new chips to flashrom and fix up 2 existing chips
as well.
Replace age-old TODO comments with real explanations.

Fixed chips:
Fujitsu MBM29F400TC (ID definition)
Macronix MX29F002T (chip name)

New chips:
Fujitsu MBM29F004BC
Fujitsu MBM29F004TC
Fujitsu MBM29F400BC
Macronix MX25L512
Macronix MX25L1005
Macronix MX25L2005
Macronix MX25L6405
Macronix MX29F002B

Straight from the data sheets, compile tested only.

Signed-off-by: Carl-Daniel Hailfinger <c-d.hailfinger.devel.2006 at gmx.net>
Acked-by: Uwe Hermann <uwe at hermann-uwe.de>


Modified: trunk/util/flashrom/flash.h
===================================================================
--- trunk/util/flashrom/flash.h	2008-11-03 23:16:00 UTC (rev 3729)
+++ trunk/util/flashrom/flash.h	2008-11-04 12:11:12 UTC (rev 3730)
@@ -181,13 +181,10 @@
 #define EN_29F002B		0x7F97
 
 #define FUJITSU_ID		0x04	/* Fujitsu */
-/*
- * MBM29F400TC_STRANGE has a value not mentioned in the data sheet and we
- * try to read it from a location not mentioned in the data sheet.
- */
-#define MBM29F400TC_STRANGE	0x23
-#define MBM29F400BC		0x7B
-#define MBM29F400TC		0x77
+#define MBM29F400BC		0xAB
+#define MBM29F400TC		0x23
+#define MBM29F004BC		0x7B
+#define MBM29F004TC		0x77
 
 #define HYUNDAI_ID		0xAD	/* Hyundai */
 
@@ -216,7 +213,8 @@
 #define MX_25L6405		0x2017	/* MX25L3205{,D} */
 #define MX_25L1635D		0x2415
 #define MX_25L3235D		0x2416
-#define MX_29F002		0xB0
+#define MX_29F002B		0x34
+#define MX_29F002T		0xB0
 
 /*
  * Programmable Micro Corp is listed in JEP106W in bank 2, so it should

Modified: trunk/util/flashrom/flashchips.c
===================================================================
--- trunk/util/flashrom/flashchips.c	2008-11-03 23:16:00 UTC (rev 3729)
+++ trunk/util/flashrom/flashchips.c	2008-11-04 12:11:12 UTC (rev 3730)
@@ -30,7 +30,7 @@
  */
 struct flashchip flashchips[] = {
 	/**********************************************************************************************************************************************************************************************************************/
-	/* Vendor	Chip			Vendor ID	Chip ID			TODO	TODO		Test status	Probe function		Erase function			Write function		Read function */
+	/* Vendor	Chip			Vendor ID	Chip ID		Total size (kB)	Page size (B)	Test status	Probe function		Erase function			Write function		Read function */
 	/**********************************************************************************************************************************************************************************************************************/
 	{"AMD",		"Am29F002(N)BB",	AMD_ID,		AM_29F002BB,		256,	256,		TEST_UNTESTED,	probe_jedec,		erase_chip_jedec,		write_en29f002a},
 	{"AMD",		"Am29F002(N)BT",	AMD_ID,		AM_29F002BT,		256,	256,		TEST_OK_PREW,	probe_jedec,		erase_chip_jedec,		write_en29f002a},
@@ -51,14 +51,22 @@
 	{"EMST",	"F49B002UA",		EMST_ID,	EMST_F49B002UA,		256,	4096,		TEST_UNTESTED,	probe_jedec,		erase_chip_jedec,		write_49f002},
 	{"EON",		"EN29F002(A)(N)B",	EON_ID,		EN_29F002B,		256,	256,		TEST_UNTESTED,	probe_jedec,		erase_chip_jedec,		write_en29f002a},
 	{"EON",		"EN29F002(A)(N)T",	EON_ID,		EN_29F002T,		256,	256,		TEST_OK_PREW,	probe_jedec,		erase_chip_jedec,		write_en29f002a},
-	{"Fujitsu",	"MBM29F400TC",		FUJITSU_ID,	MBM29F400TC_STRANGE,	512,	64 * 1024,	TEST_UNTESTED,	probe_m29f400bt,	erase_m29f400bt,		write_coreboot_m29f400bt},
+	{"Fujitsu",	"MBM29F004BC",		FUJITSU_ID,	MBM29F004BC,		512,	64 * 1024,	TEST_UNTESTED,	probe_jedec,		NULL,			NULL},
+	{"Fujitsu",	"MBM29F004TC",		FUJITSU_ID,	MBM29F004TC,		512,	64 * 1024,	TEST_UNTESTED,	probe_jedec,		NULL,			NULL},
+	{"Fujitsu",	"MBM29F400BC",		FUJITSU_ID,	MBM29F400BC,		512,	64 * 1024,	TEST_UNTESTED,	probe_m29f400bt,	erase_m29f400bt,		write_coreboot_m29f400bt},
+	{"Fujitsu",	"MBM29F400TC",		FUJITSU_ID,	MBM29F400TC,		512,	64 * 1024,	TEST_UNTESTED,	probe_m29f400bt,	erase_m29f400bt,		write_coreboot_m29f400bt},
 	{"Intel",	"82802AB",		INTEL_ID,	173,			512,	64 * 1024,	TEST_OK_PREW,	probe_82802ab,		erase_82802ab,			write_82802ab},
 	{"Intel",	"82802AC",		INTEL_ID,	172,			1024,	64 * 1024,	TEST_OK_PREW,	probe_82802ab,		erase_82802ab,			write_82802ab},
+	{"Macronix",	"MX25L512",		MX_ID,		MX_25L512,		64,	256,		TEST_UNTESTED,	probe_spi_rdid,		spi_chip_erase_c7,	spi_chip_write,	spi_chip_read},
+	{"Macronix",	"MX25L1005",		MX_ID,		MX_25L1005,		128,	256,		TEST_UNTESTED,	probe_spi_rdid,		spi_chip_erase_c7,	spi_chip_write,	spi_chip_read},
+	{"Macronix",	"MX25L2005",		MX_ID,		MX_25L2005,		256,	256,		TEST_UNTESTED,	probe_spi_rdid,		spi_chip_erase_c7,	spi_chip_write,	spi_chip_read},
 	{"Macronix",	"MX25L4005",		MX_ID,		MX_25L4005,		512,	256,		TEST_OK_PREW,	probe_spi_rdid,		spi_chip_erase_c7,	spi_chip_write,	spi_chip_read},
 	{"Macronix",	"MX25L8005",		MX_ID,		MX_25L8005,		1024,	256,		TEST_OK_PREW,	probe_spi_rdid,		spi_chip_erase_c7,	spi_chip_write,	spi_chip_read},
 	{"Macronix",	"MX25L1605",		MX_ID,		MX_25L1605,		2048,	256,		TEST_UNTESTED,	probe_spi_rdid,		spi_chip_erase_c7,	spi_chip_write,	spi_chip_read},
 	{"Macronix",	"MX25L3205",		MX_ID,		MX_25L3205,		4096,	256,		TEST_OK_PREW,	probe_spi_rdid,		spi_chip_erase_c7,	spi_chip_write,	spi_chip_read},
-	{"Macronix",	"MX29F002",		MX_ID,		MX_29F002,		256,	64 * 1024,	TEST_UNTESTED,	probe_29f002,		erase_29f002,			write_29f002},
+	{"Macronix",	"MX25L6405",		MX_ID,		MX_25L6405,		8192,	256,		TEST_UNTESTED,	probe_spi_rdid,		spi_chip_erase_c7,	spi_chip_write,	spi_chip_read},
+	{"Macronix",	"MX29F002B",		MX_ID,		MX_29F002B,		256,	64 * 1024,	TEST_UNTESTED,	probe_29f002,		erase_29f002,			write_29f002},
+	{"Macronix",	"MX29F002T",		MX_ID,		MX_29F002T,		256,	64 * 1024,	TEST_UNTESTED,	probe_29f002,		erase_29f002,			write_29f002},
 	{"Numonyx",	"M25PE10",		ST_ID,		0x8011,			128,	256,		TEST_UNTESTED,	probe_spi_rdid,		spi_chip_erase_d8,	spi_chip_write, spi_chip_read},
 	{"Numonyx",	"M25PE20",		ST_ID,		0x8012,			256,	256,		TEST_UNTESTED,	probe_spi_rdid,		spi_chip_erase_d8,	spi_chip_write, spi_chip_read},
 	{"Numonyx",	"M25PE40",		ST_ID,		0x8013,			256,	256,		TEST_UNTESTED,	probe_spi_rdid,		spi_chip_erase_d8,	spi_chip_write, spi_chip_read},
@@ -140,7 +148,7 @@
 	{"Winbond",	"W29EE011",		WINBOND_ID,	W_29C011,		128,	128,		TEST_OK_PREW,	probe_w29ee011,		erase_chip_jedec,		write_jedec},
 	{"Winbond",	"W39V040A",		WINBOND_ID,	W_39V040A,		512,	64*1024,	TEST_UNTESTED,	probe_jedec,		erase_chip_jedec,		write_39sf020},
 	{"Winbond",	"W39V040B",		WINBOND_ID,	W_39V040B,		512,	64*1024,	TEST_OK_PREW,	probe_jedec,		erase_chip_jedec,		write_39sf020},
-	{"Winbond",	"W39V040C",		0xda,		0x50,			512,	64*1024,	TEST_OK_PREW,	probe_w39v040c,		erase_w39v040c,			write_w39v040c},
+	{"Winbond",	"W39V040C",		WINBOND_ID,	0x50,			512,	64*1024,	TEST_OK_PREW,	probe_w39v040c,		erase_w39v040c,			write_w39v040c},
 	{"Winbond",	"W39V040FA",		WINBOND_ID,	W_39V040FA,		512,	64*1024,	TEST_OK_PREW,	probe_jedec,		erase_chip_jedec,		write_39sf020},
 	{"Winbond",	"W39V080A",		WINBOND_ID,	W_39V080A,		1024,	64*1024,	TEST_OK_PREW,	probe_jedec,		erase_chip_jedec,		write_39sf020},
 	{"Winbond",	"W49F002U",		WINBOND_ID,	W_49F002U,		256,	128,		TEST_OK_PREW,	probe_jedec,		erase_chip_jedec,		write_49f002},




From c-d.hailfinger.devel.2006 at gmx.net  Tue Nov  4 13:37:00 2008
From: c-d.hailfinger.devel.2006 at gmx.net (Carl-Daniel Hailfinger)
Date: Tue, 04 Nov 2008 13:37:00 +0100
Subject: [coreboot] [PATCH] flashrom: Add support for 8 new chips,
 fix up 2 existing chips
In-Reply-To: <20081104115804.GB13674@greenwood>
References: <490E4C33.2020709@gmx.net> <20081103012413.8599.qmail@stuge.se>
	<20081104115804.GB13674@greenwood>
Message-ID: <491041EC.30409@gmx.net>

On 04.11.2008 12:58, Uwe Hermann wrote:
> Patch is
>
> Acked-by: Uwe Hermann <uwe at hermann-uwe.de>
>   

Thanks, r3730.

Regards,
Carl-Daniel

-- 
http://www.hailfinger.org/




From c-d.hailfinger.devel.2006 at gmx.net  Tue Nov  4 14:38:11 2008
From: c-d.hailfinger.devel.2006 at gmx.net (Carl-Daniel Hailfinger)
Date: Tue, 04 Nov 2008 14:38:11 +0100
Subject: [coreboot]  [PATCH] flashrom: sector-based flashing
In-Reply-To: <48F11E1A.9050609@gmx.net>
References: <48F01FA7.7030206@gmx.net>	<13426df10810102107r6b06ee3bh736b3bf5c3e3e8@mail.gmail.com>
	<48F11E1A.9050609@gmx.net>
Message-ID: <49105043.4010404@gmx.net>

On 11.10.2008 23:43, Carl-Daniel Hailfinger wrote:
> On 11.10.2008 06:07, ron minnich wrote:
>   
>> On Fri, Oct 10, 2008 at 8:38 PM, Carl-Daniel Hailfinger
>> <c-d.hailfinger.devel.2006 at gmx.net> wrote:
>>   
>>     
>>> Hi,
>>>
>>> flashrom hasn't seen any major design changes in the last few months and
>>> most chips still perform whole-chip erase instead of sector-based erase.
>>>
>>> I'd like to introduce a function which takes a range and rounds the
>>> start and the end of the range to the nearest block boundary.
>>> void roundup(struct flashchip *flash, int *startpos, int *endpos);
>>>
>>> Take an example 256 kByte flash chip with the following sector layout:
>>> 0x00000-0x0ffff 64kB block
>>> 0x10000-0x1ffff 64kB block
>>> 0x20000-0x2ffff 64kB block
>>> 0x30000-0x37fff 32kB block
>>> 0x38000-0x3bfff 16kB block
>>> 0x3c000-0x3dfff 8kB block
>>> 0x3e000-0x3efff 4kB block
>>> 0x3f000-0x3ffff 4kB block
>>>
>>> startpos=0x38123;
>>> endpos=0x3e005;
>>> roundup(flash, &startpos, &endpos);
>>> //results follow:
>>> //startpos=0x38000;
>>> //endpos=0x3efff;
>>>
>>> That way, it is easily possible to check whether a given range can be
>>> handled by sector-based erase and write.
>>> You can use that result to tell the user that a range outside the
>>> intended range will get flashed. It is also possible to refuse flashing
>>> in that case.
>>>
>>> Since the function will be generic and take a struct flashchip, there's
>>> no need to store a pointer to it with each chip and you can call the
>>> generic one from anywhere.
>>>
>>> What do you think?
>>>
>>>     
>>>       
>> This is a good idea. Once cheap trick we could also do (or do we?):
>> before sector erase, see if the sector is already erased, and skip
>> that one.
>>   
>>     
>
> This is a patch which stores eraseblock sizes in struct flashchip. I
> decided to fill in the info for a few chips to illustrate how this works
> both for uniform and non-uniform sector sizes.
>
> Signed-off-by: Carl-Daniel Hailfinger <c-d.hailfinger.devel.2006 at gmx.net>
>   

Since the codebase has changed a bit, I decided to rediff.
This patch already uses sector-based erase if available. The write
functions with implicit erase still need to be hooked up, but the patch
is functional as-is.

Attached for Gmail users.

Index: flashrom-eraseblocks/flash.h
===================================================================
--- flashrom-eraseblocks/flash.h	(Revision 3730)
+++ flashrom-eraseblocks/flash.h	(Arbeitskopie)
@@ -51,6 +51,11 @@
 
 #define ARRAY_SIZE(a) (sizeof(a) / sizeof((a)[0]))
 
+struct eraseblock{
+	int size; /* Eraseblock size */
+	int count; /* Number of contiguous blocks with that size */
+};
+
 struct flashchip {
 	const char *vendor;
 	const char *name;
@@ -64,6 +69,7 @@
 
 	int total_size;
 	int page_size;
+	struct eraseblock eraseblocks[4];
 
 	/*
 	 * Indicate if flashrom has been tested with this flash chip and if
@@ -73,6 +79,7 @@
 
 	int (*probe) (struct flashchip *flash);
 	int (*erase) (struct flashchip *flash);
+	int (*block_erase) (struct flashchip *flash, unsigned long addr);
 	int (*write) (struct flashchip *flash, uint8_t *buf);
 	int (*read) (struct flashchip *flash, uint8_t *buf);
 
Index: flashrom-eraseblocks/flashchips.c
===================================================================
--- flashrom-eraseblocks/flashchips.c	(Revision 3730)
+++ flashrom-eraseblocks/flashchips.c	(Arbeitskopie)
@@ -30,138 +30,138 @@
  */
 struct flashchip flashchips[] = {
 	/**********************************************************************************************************************************************************************************************************************/
-	/* Vendor	Chip			Vendor ID	Chip ID		Total size (kB)	Page size (B)	Test status	Probe function		Erase function			Write function		Read function */
+	/* Vendor	Chip			Vendor ID	Chip ID		Total size (kB)	Page size (B)	Eraseblocks				Test status	Probe function		Chip erase function	Block erase	Write function		Read function */
 	/**********************************************************************************************************************************************************************************************************************/
-	{"AMD",		"Am29F002(N)BB",	AMD_ID,		AM_29F002BB,		256,	256,		TEST_UNTESTED,	probe_jedec,		erase_chip_jedec,		write_en29f002a},
-	{"AMD",		"Am29F002(N)BT",	AMD_ID,		AM_29F002BT,		256,	256,		TEST_OK_PREW,	probe_jedec,		erase_chip_jedec,		write_en29f002a},
-	{"AMD",		"Am29F016D",		AMD_ID,		AM_29F016D,		2048,	64 * 1024,	TEST_UNTESTED,	probe_29f040b,		erase_29f040b,			write_29f040b},
-	{"AMD",		"Am29F040B",		AMD_ID,		AM_29F040B,		512,	64 * 1024,	TEST_OK_PREW,	probe_29f040b,		erase_29f040b,			write_29f040b},
-	{"AMD",		"Am29LV040B",		AMD_ID,		AM_29LV040B,		512,	64 * 1024,	TEST_UNTESTED,	probe_29f040b,		erase_29f040b,			write_29f040b},
-	{"ASD",		"AE49F2008",		ASD_ID,		ASD_AE49F2008,		256,	128,		TEST_UNTESTED,	probe_jedec,		erase_chip_jedec,		write_jedec},
-	{"Atmel",	"AT29C020",		ATMEL_ID,	AT_29C020,		256,	256,		TEST_OK_PREW,	probe_jedec,		erase_chip_jedec,		write_jedec},
-	{"Atmel",	"AT29C040A",		ATMEL_ID,	AT_29C040A,		512,	256,		TEST_UNTESTED,	probe_jedec,		erase_chip_jedec,		write_jedec},
-	{"Atmel",	"AT49F002(N)",		ATMEL_ID,	AT_49F002N,		256,	256,		TEST_UNTESTED,	probe_jedec,		erase_chip_jedec,		write_49f002},
-	{"Atmel",	"AT49F002(N)T",		ATMEL_ID,	AT_49F002NT,		256,	256,		TEST_OK_PREW,	probe_jedec,		erase_chip_jedec,		write_49f002},
-	{"Atmel",	"AT25DF321",		ATMEL_ID,	AT_25DF321,		4096,	256,		TEST_OK_PREW,	probe_spi_rdid,		spi_chip_erase_c7,	spi_chip_write,	spi_chip_read},
-	{"AMIC",	"A25L40P",		AMIC_ID,	AMIC_A25L40P,		512,	256,		TEST_OK_PREW,	probe_spi_rdid4,	spi_chip_erase_c7,	spi_chip_write, spi_chip_read},
-	{"AMIC",	"A29002B",		AMIC_ID_NOPREFIX, AMIC_A29002B,		256,	64 * 1024,	TEST_UNTESTED,	probe_29f002,		erase_29f002,			write_29f002},
-	{"AMIC",	"A29002T",		AMIC_ID_NOPREFIX, AMIC_A29002T,		256,	64 * 1024,	TEST_OK_PREW,	probe_29f002,		erase_29f002,			write_29f002},
-	{"AMIC",	"A29040B",		AMIC_ID_NOPREFIX, AMIC_A29040B,		512,	64 * 1024,	TEST_OK_PR,	probe_29f040b,		erase_29f040b,			write_29f040b},
-	{"AMIC",	"A49LF040A",		AMIC_ID_NOPREFIX, AMIC_A49LF040A,	512,	64 * 1024,	TEST_OK_PREW,	probe_49fl00x,		erase_49fl00x,			write_49fl00x},
-	{"EMST",	"F49B002UA",		EMST_ID,	EMST_F49B002UA,		256,	4096,		TEST_UNTESTED,	probe_jedec,		erase_chip_jedec,		write_49f002},
-	{"EON",		"EN29F002(A)(N)B",	EON_ID,		EN_29F002B,		256,	256,		TEST_UNTESTED,	probe_jedec,		erase_chip_jedec,		write_en29f002a},
-	{"EON",		"EN29F002(A)(N)T",	EON_ID,		EN_29F002T,		256,	256,		TEST_OK_PREW,	probe_jedec,		erase_chip_jedec,		write_en29f002a},
-	{"Fujitsu",	"MBM29F004BC",		FUJITSU_ID,	MBM29F004BC,		512,	64 * 1024,	TEST_UNTESTED,	probe_jedec,		NULL,			NULL},
-	{"Fujitsu",	"MBM29F004TC",		FUJITSU_ID,	MBM29F004TC,		512,	64 * 1024,	TEST_UNTESTED,	probe_jedec,		NULL,			NULL},
-	{"Fujitsu",	"MBM29F400BC",		FUJITSU_ID,	MBM29F400BC,		512,	64 * 1024,	TEST_UNTESTED,	probe_m29f400bt,	erase_m29f400bt,		write_coreboot_m29f400bt},
-	{"Fujitsu",	"MBM29F400TC",		FUJITSU_ID,	MBM29F400TC,		512,	64 * 1024,	TEST_UNTESTED,	probe_m29f400bt,	erase_m29f400bt,		write_coreboot_m29f400bt},
-	{"Intel",	"82802AB",		INTEL_ID,	173,			512,	64 * 1024,	TEST_OK_PREW,	probe_82802ab,		erase_82802ab,			write_82802ab},
-	{"Intel",	"82802AC",		INTEL_ID,	172,			1024,	64 * 1024,	TEST_OK_PREW,	probe_82802ab,		erase_82802ab,			write_82802ab},
-	{"Macronix",	"MX25L512",		MX_ID,		MX_25L512,		64,	256,		TEST_UNTESTED,	probe_spi_rdid,		spi_chip_erase_c7,	spi_chip_write,	spi_chip_read},
-	{"Macronix",	"MX25L1005",		MX_ID,		MX_25L1005,		128,	256,		TEST_UNTESTED,	probe_spi_rdid,		spi_chip_erase_c7,	spi_chip_write,	spi_chip_read},
-	{"Macronix",	"MX25L2005",		MX_ID,		MX_25L2005,		256,	256,		TEST_UNTESTED,	probe_spi_rdid,		spi_chip_erase_c7,	spi_chip_write,	spi_chip_read},
-	{"Macronix",	"MX25L4005",		MX_ID,		MX_25L4005,		512,	256,		TEST_OK_PREW,	probe_spi_rdid,		spi_chip_erase_c7,	spi_chip_write,	spi_chip_read},
-	{"Macronix",	"MX25L8005",		MX_ID,		MX_25L8005,		1024,	256,		TEST_OK_PREW,	probe_spi_rdid,		spi_chip_erase_c7,	spi_chip_write,	spi_chip_read},
-	{"Macronix",	"MX25L1605",		MX_ID,		MX_25L1605,		2048,	256,		TEST_UNTESTED,	probe_spi_rdid,		spi_chip_erase_c7,	spi_chip_write,	spi_chip_read},
-	{"Macronix",	"MX25L3205",		MX_ID,		MX_25L3205,		4096,	256,		TEST_OK_PREW,	probe_spi_rdid,		spi_chip_erase_c7,	spi_chip_write,	spi_chip_read},
-	{"Macronix",	"MX25L6405",		MX_ID,		MX_25L6405,		8192,	256,		TEST_UNTESTED,	probe_spi_rdid,		spi_chip_erase_c7,	spi_chip_write,	spi_chip_read},
-	{"Macronix",	"MX29F002B",		MX_ID,		MX_29F002B,		256,	64 * 1024,	TEST_UNTESTED,	probe_29f002,		erase_29f002,			write_29f002},
-	{"Macronix",	"MX29F002T",		MX_ID,		MX_29F002T,		256,	64 * 1024,	TEST_UNTESTED,	probe_29f002,		erase_29f002,			write_29f002},
-	{"Numonyx",	"M25PE10",		ST_ID,		0x8011,			128,	256,		TEST_UNTESTED,	probe_spi_rdid,		spi_chip_erase_d8,	spi_chip_write, spi_chip_read},
-	{"Numonyx",	"M25PE20",		ST_ID,		0x8012,			256,	256,		TEST_UNTESTED,	probe_spi_rdid,		spi_chip_erase_d8,	spi_chip_write, spi_chip_read},
-	{"Numonyx",	"M25PE40",		ST_ID,		0x8013,			256,	256,		TEST_UNTESTED,	probe_spi_rdid,		spi_chip_erase_d8,	spi_chip_write, spi_chip_read},
-	{"Numonyx",	"M25PE80",		ST_ID,		0x8014,			1024,	256,		TEST_OK_PREW,	probe_spi_rdid,		spi_chip_erase_d8,	spi_chip_write, spi_chip_read},
-	{"Numonyx",	"M25PE16",		ST_ID,		0x8015,			2048,	256,		TEST_UNTESTED,	probe_spi_rdid,		spi_chip_erase_d8,	spi_chip_write, spi_chip_read},
-	{"PMC",		"Pm25LV010",		PMC_ID,		PMC_25LV010,		128,	256,		TEST_UNTESTED,	probe_spi_rdid,		spi_chip_erase_c7,	spi_chip_write,	spi_chip_read},
-	{"PMC",		"Pm25LV016B",		PMC_ID,		PMC_25LV016B,		2048,	256,		TEST_UNTESTED,	probe_spi_rdid,		spi_chip_erase_c7,	spi_chip_write,	spi_chip_read},
-	{"PMC",		"Pm25LV020",		PMC_ID,		PMC_25LV020,		256,	256,		TEST_UNTESTED,	probe_spi_rdid,		spi_chip_erase_c7,	spi_chip_write,	spi_chip_read},
-	{"PMC",		"Pm25LV040",		PMC_ID,		PMC_25LV040,		512,	256,		TEST_UNTESTED,	probe_spi_rdid,		spi_chip_erase_c7,	spi_chip_write,	spi_chip_read},
-	{"PMC",		"Pm25LV080B",		PMC_ID,		PMC_25LV080B,		1024,	256,		TEST_UNTESTED,	probe_spi_rdid,		spi_chip_erase_c7,	spi_chip_write,	spi_chip_read},
-	{"PMC",		"Pm25LV512",		PMC_ID,		PMC_25LV512,		64,	256,		TEST_UNTESTED,	probe_spi_rdid,		spi_chip_erase_c7,	spi_chip_write,	spi_chip_read},
-	{"PMC",		"Pm49FL002",		PMC_ID_NOPREFIX,PMC_49FL002,		256,	16 * 1024,	TEST_OK_PREW,	probe_49fl00x,		erase_49fl00x,		write_49fl00x},
-	{"PMC",		"Pm49FL004",		PMC_ID_NOPREFIX,PMC_49FL004,		512,	64 * 1024,	TEST_OK_PREW,	probe_49fl00x,		erase_49fl00x,		write_49fl00x},
-	{"Sharp",	"LHF00L04",		SHARP_ID,	SHARP_LHF00L04,		1024,	64 * 1024,	TEST_UNTESTED,	probe_lhf00l04,		erase_lhf00l04,			write_lhf00l04},
-	{"Spansion",	"S25FL016A",		SPANSION_ID,	SPANSION_S25FL016A,	2048,	256,		TEST_OK_PREW,	probe_spi_rdid,		spi_chip_erase_c7,	spi_chip_write,	spi_chip_read},
-	{"SST",		"SST25VF016B",		SST_ID,		SST_25VF016B,		2048,	256,		TEST_OK_PREW,	probe_spi_rdid,		spi_chip_erase_c7,	spi_chip_write,	spi_chip_read},
-	{"SST",		"SST25VF040B",		SST_ID,		SST_25VF040B,		512,	256,		TEST_UNTESTED,	probe_spi_rdid,		spi_chip_erase_c7,	spi_chip_write,	spi_chip_read},
-	{"SST",		"SST28SF040A",		SST_ID,		SST_28SF040,		512,	256,		TEST_UNTESTED,	probe_28sf040,		erase_28sf040,			write_28sf040},
-	{"SST",		"SST29EE010",		SST_ID,		SST_29EE010,		128,	128,		TEST_OK_PREW,	probe_jedec,		erase_chip_jedec,		write_jedec},
-	{"SST",		"SST29LE010",		SST_ID,		SST_29LE010,		128,	128,		TEST_UNTESTED,	probe_jedec,		erase_chip_jedec, 		write_jedec},
-	{"SST",		"SST29EE020A",		SST_ID,		SST_29EE020A,		256,	128,		TEST_UNTESTED,	probe_jedec,		erase_chip_jedec,		write_jedec},
-	{"SST",		"SST29LE020",		SST_ID,		SST_29LE020,		256,	128,		TEST_UNTESTED,	probe_jedec,		erase_chip_jedec,		write_jedec},
-	{"SST",		"SST39SF010A",		SST_ID,		SST_39SF010,		128,	4096,		TEST_OK_PREW,	probe_jedec,		erase_chip_jedec,		write_39sf020},
-	{"SST",		"SST39SF020A",		SST_ID,		SST_39SF020,		256,	4096,		TEST_OK_PREW,	probe_jedec,		erase_chip_jedec,		write_39sf020},
-	{"SST",		"SST39SF040",		SST_ID,		SST_39SF040,		512,	4096,		TEST_UNTESTED,	probe_jedec,		erase_chip_jedec,		write_39sf020},
-	{"SST",		"SST39VF512",		SST_ID,		SST_39VF512,		64,	4096,		TEST_UNTESTED,	probe_jedec,		erase_chip_jedec,		write_39sf020},
-	{"SST",		"SST39VF010",		SST_ID,		SST_39VF010,		128,	4096,		TEST_UNTESTED,	probe_jedec,		erase_chip_jedec,		write_39sf020},
-	{"SST",		"SST39VF020",		SST_ID,		SST_39VF020,		256,	4096,		TEST_UNTESTED,	probe_jedec,		erase_chip_jedec,		write_39sf020},
-	{"SST",		"SST39VF040",		SST_ID,		SST_39VF040,		512,	4096,		TEST_OK_PROBE,	probe_jedec,		erase_chip_jedec,		write_39sf020},
+	{"AMD",		"Am29F002(N)BB",	AMD_ID,		AM_29F002BB,		256,	256,		{},					TEST_UNTESTED,	probe_jedec,		erase_chip_jedec,	NULL,		write_en29f002a},
+	{"AMD",		"Am29F002(N)BT",	AMD_ID,		AM_29F002BT,		256,	256,		{},					TEST_OK_PREW,	probe_jedec,		erase_chip_jedec,	NULL,		write_en29f002a},
+	{"AMD",		"Am29F016D",		AMD_ID,		AM_29F016D,		2048,	64 * 1024,	{},					TEST_UNTESTED,	probe_29f040b,		erase_29f040b,		NULL,		write_29f040b},
+	{"AMD",		"Am29F040B",		AMD_ID,		AM_29F040B,		512,	64 * 1024,	{},					TEST_OK_PREW,	probe_29f040b,		erase_29f040b,		NULL,		write_29f040b},
+	{"AMD",		"Am29LV040B",		AMD_ID,		AM_29LV040B,		512,	64 * 1024,	{},					TEST_UNTESTED,	probe_29f040b,		erase_29f040b,		NULL,		write_29f040b},
+	{"ASD",		"AE49F2008",		ASD_ID,		ASD_AE49F2008,		256,	128,		{},					TEST_UNTESTED,	probe_jedec,		erase_chip_jedec,	NULL,		write_jedec},
+	{"Atmel",	"AT29C020",		ATMEL_ID,	AT_29C020,		256,	256,		{},					TEST_OK_PREW,	probe_jedec,		erase_chip_jedec,	NULL,		write_jedec},
+	{"Atmel",	"AT29C040A",		ATMEL_ID,	AT_29C040A,		512,	256,		{},					TEST_UNTESTED,	probe_jedec,		erase_chip_jedec,	NULL,		write_jedec},
+	{"Atmel",	"AT49F002(N)",		ATMEL_ID,	AT_49F002N,		256,	256,		{},					TEST_UNTESTED,	probe_jedec,		erase_chip_jedec,	NULL,		write_49f002},
+	{"Atmel",	"AT49F002(N)T",		ATMEL_ID,	AT_49F002NT,		256,	256,		{},					TEST_OK_PREW,	probe_jedec,		erase_chip_jedec,	NULL,		write_49f002},
+	{"Atmel",	"AT25DF321",		ATMEL_ID,	AT_25DF321,		4096,	256,		{},					TEST_OK_PREW,	probe_spi_rdid,		spi_chip_erase_c7,	NULL,		spi_chip_write,	spi_chip_read},
+	{"AMIC",	"A25L40P",		AMIC_ID,	AMIC_A25L40P,		512,	256,		{},					TEST_OK_PREW,	probe_spi_rdid4,	spi_chip_erase_c7,	NULL,		spi_chip_write, spi_chip_read},
+	{"AMIC",	"A29002B",		AMIC_ID_NOPREFIX, AMIC_A29002B,		256,	64 * 1024,	{{16384,1},{8192,2},{32768,1},{65536,3}},TEST_UNTESTED,	probe_29f002,		erase_29f002,		NULL,		write_29f002},
+	{"AMIC",	"A29002T",		AMIC_ID_NOPREFIX, AMIC_A29002T,		256,	64 * 1024,	{{65536,3},{32768,1},{8192,2},{16384,1}},TEST_OK_PREW,	probe_29f002,		erase_29f002,		NULL,		write_29f002},
+	{"AMIC",	"A29040B",		AMIC_ID_NOPREFIX, AMIC_A29040B,		512,	64 * 1024,	{},					TEST_OK_PR,	probe_29f040b,		erase_29f040b,		NULL,		write_29f040b},
+	{"AMIC",	"A49LF040A",		AMIC_ID_NOPREFIX, AMIC_A49LF040A,	512,	64 * 1024,	{},					TEST_OK_PREW,	probe_49fl00x,		erase_49fl00x,		NULL,		write_49fl00x},
+	{"EMST",	"F49B002UA",		EMST_ID,	EMST_F49B002UA,		256,	4096,		{},					TEST_UNTESTED,	probe_jedec,		erase_chip_jedec,	NULL,		write_49f002},
+	{"EON",		"EN29F002(A)(N)B",	EON_ID,		EN_29F002B,		256,	256,		{{16384,1},{8192,2},{32768,1},{65536,3}},TEST_UNTESTED,	probe_jedec,		erase_chip_jedec,	NULL,		write_en29f002a},
+	{"EON",		"EN29F002(A)(N)T",	EON_ID,		EN_29F002T,		256,	256,		{{65536,3},{32768,1},{8192,2},{16384,1}},TEST_OK_PREW,	probe_jedec,		erase_chip_jedec,	NULL,		write_en29f002a},
+	{"Fujitsu",	"MBM29F004BC",		FUJITSU_ID,	MBM29F004BC,		512,	64 * 1024,	{{16384,1},{8192,2},{32768,1},{65536,7}},TEST_UNTESTED,	probe_jedec,		NULL,			NULL,		NULL},
+	{"Fujitsu",	"MBM29F004TC",		FUJITSU_ID,	MBM29F004TC,		512,	64 * 1024,	{{65536,7},{32768,1},{8192,2},{16384,1}},TEST_UNTESTED,	probe_jedec,		NULL,			NULL,		NULL},
+	{"Fujitsu",	"MBM29F400BC",		FUJITSU_ID,	MBM29F400BC,		512,	64 * 1024,	{{16384,1},{8192,2},{32768,1},{65536,7}},TEST_UNTESTED,	probe_m29f400bt,	erase_m29f400bt,	NULL,		write_coreboot_m29f400bt},
+	{"Fujitsu",	"MBM29F400TC",		FUJITSU_ID,	MBM29F400TC,		512,	64 * 1024,	{{65536,7},{32768,1},{8192,2},{16384,1}},TEST_UNTESTED,	probe_m29f400bt,	erase_m29f400bt,	NULL,		write_coreboot_m29f400bt},
+	{"Intel",	"82802AB",		INTEL_ID,	173,			512,	64 * 1024,	{},					TEST_OK_PREW,	probe_82802ab,		erase_82802ab,		NULL,		write_82802ab},
+	{"Intel",	"82802AC",		INTEL_ID,	172,			1024,	64 * 1024,	{},					TEST_OK_PREW,	probe_82802ab,		erase_82802ab,		NULL,		write_82802ab},
+	{"Macronix",	"MX25L512",		MX_ID,		MX_25L512,		64,	256,		{{4096,16}},				TEST_UNTESTED,	probe_spi_rdid,		spi_chip_erase_c7,	NULL,		spi_chip_write,	spi_chip_read},
+	{"Macronix",	"MX25L1005",		MX_ID,		MX_25L1005,		128,	256,		{{4096,32}},				TEST_UNTESTED,	probe_spi_rdid,		spi_chip_erase_c7,	NULL,		spi_chip_write,	spi_chip_read},
+	{"Macronix",	"MX25L2005",		MX_ID,		MX_25L2005,		256,	256,		{{4096,64}},				TEST_UNTESTED,	probe_spi_rdid,		spi_chip_erase_c7,	NULL,		spi_chip_write,	spi_chip_read},
+	{"Macronix",	"MX25L4005",		MX_ID,		MX_25L4005,		512,	256,		{{4096,128}},				TEST_OK_PREW,	probe_spi_rdid,		spi_chip_erase_c7,	NULL,		spi_chip_write,	spi_chip_read},
+	{"Macronix",	"MX25L8005",		MX_ID,		MX_25L8005,		1024,	256,		{{4096,256}},				TEST_OK_PREW,	probe_spi_rdid,		spi_chip_erase_c7,	NULL,		spi_chip_write,	spi_chip_read},
+	{"Macronix",	"MX25L1605",		MX_ID,		MX_25L1605,		2048,	256,		{{4096,512}},				TEST_UNTESTED,	probe_spi_rdid,		spi_chip_erase_c7,	NULL,		spi_chip_write,	spi_chip_read},
+	{"Macronix",	"MX25L3205",		MX_ID,		MX_25L3205,		4096,	256,		{{4096,1024}},				TEST_OK_PREW,	probe_spi_rdid,		spi_chip_erase_c7,	NULL,		spi_chip_write,	spi_chip_read},
+	{"Macronix",	"MX25L6405",		MX_ID,		MX_25L6405,		8192,	256,		{{4096,2048}},				TEST_UNTESTED,	probe_spi_rdid,		spi_chip_erase_c7,	NULL,		spi_chip_write,	spi_chip_read},
+	{"Macronix",	"MX29F002B",		MX_ID,		MX_29F002B,		256,	64 * 1024,	{{16384,1},{8192,2},{32768,1},{65536,3}},TEST_UNTESTED,	probe_29f002,		erase_29f002,		NULL,		write_29f002},
+	{"Macronix",	"MX29F002T",		MX_ID,		MX_29F002T,		256,	64 * 1024,	{{65536,3},{32768,1},{8192,2},{16384,1}},TEST_UNTESTED,	probe_29f002,		erase_29f002,		NULL,		write_29f002},
+	{"Numonyx",	"M25PE10",		ST_ID,		0x8011,			128,	256,		{},					TEST_UNTESTED,	probe_spi_rdid,		spi_chip_erase_d8,	NULL,		spi_chip_write, spi_chip_read},
+	{"Numonyx",	"M25PE20",		ST_ID,		0x8012,			256,	256,		{},					TEST_UNTESTED,	probe_spi_rdid,		spi_chip_erase_d8,	NULL,		spi_chip_write, spi_chip_read},
+	{"Numonyx",	"M25PE40",		ST_ID,		0x8013,			256,	256,		{},					TEST_UNTESTED,	probe_spi_rdid,		spi_chip_erase_d8,	NULL,		spi_chip_write, spi_chip_read},
+	{"Numonyx",	"M25PE80",		ST_ID,		0x8014,			1024,	256,		{},					TEST_OK_PREW,	probe_spi_rdid,		spi_chip_erase_d8,	NULL,		spi_chip_write, spi_chip_read},
+	{"Numonyx",	"M25PE16",		ST_ID,		0x8015,			2048,	256,		{},					TEST_UNTESTED,	probe_spi_rdid,		spi_chip_erase_d8,	NULL,		spi_chip_write, spi_chip_read},
+	{"PMC",		"Pm25LV010",		PMC_ID,		PMC_25LV010,		128,	256,		{},					TEST_UNTESTED,	probe_spi_rdid,		spi_chip_erase_c7,	NULL,		spi_chip_write,	spi_chip_read},
+	{"PMC",		"Pm25LV016B",		PMC_ID,		PMC_25LV016B,		2048,	256,		{},					TEST_UNTESTED,	probe_spi_rdid,		spi_chip_erase_c7,	NULL,		spi_chip_write,	spi_chip_read},
+	{"PMC",		"Pm25LV020",		PMC_ID,		PMC_25LV020,		256,	256,		{},					TEST_UNTESTED,	probe_spi_rdid,		spi_chip_erase_c7,	NULL,		spi_chip_write,	spi_chip_read},
+	{"PMC",		"Pm25LV040",		PMC_ID,		PMC_25LV040,		512,	256,		{},					TEST_UNTESTED,	probe_spi_rdid,		spi_chip_erase_c7,	NULL,		spi_chip_write,	spi_chip_read},
+	{"PMC",		"Pm25LV080B",		PMC_ID,		PMC_25LV080B,		1024,	256,		{},					TEST_UNTESTED,	probe_spi_rdid,		spi_chip_erase_c7,	NULL,		spi_chip_write,	spi_chip_read},
+	{"PMC",		"Pm25LV512",		PMC_ID,		PMC_25LV512,		64,	256,		{},					TEST_UNTESTED,	probe_spi_rdid,		spi_chip_erase_c7,	NULL,		spi_chip_write,	spi_chip_read},
+	{"PMC",		"Pm49FL002",		PMC_ID_NOPREFIX,PMC_49FL002,		256,	16 * 1024,	{},					TEST_OK_PREW,	probe_49fl00x,		erase_49fl00x,		NULL,		write_49fl00x},
+	{"PMC",		"Pm49FL004",		PMC_ID_NOPREFIX,PMC_49FL004,		512,	64 * 1024,	{},					TEST_OK_PREW,	probe_49fl00x,		erase_49fl00x,		NULL,		write_49fl00x},
+	{"Sharp",	"LHF00L04",		SHARP_ID,	SHARP_LHF00L04,		1024,	64 * 1024,	{},					TEST_UNTESTED,	probe_lhf00l04,		erase_lhf00l04,		NULL,		write_lhf00l04},
+	{"Spansion",	"S25FL016A",		SPANSION_ID,	SPANSION_S25FL016A,	2048,	256,		{},					TEST_OK_PREW,	probe_spi_rdid,		spi_chip_erase_c7,	NULL,		spi_chip_write,	spi_chip_read},
+	{"SST",		"SST25VF016B",		SST_ID,		SST_25VF016B,		2048,	256,		{},					TEST_OK_PREW,	probe_spi_rdid,		spi_chip_erase_c7,	NULL,		spi_chip_write,	spi_chip_read},
+	{"SST",		"SST25VF040B",		SST_ID,		SST_25VF040B,		512,	256,		{},					TEST_UNTESTED,	probe_spi_rdid,		spi_chip_erase_c7,	NULL,		spi_chip_write,	spi_chip_read},
+	{"SST",		"SST28SF040A",		SST_ID,		SST_28SF040,		512,	256,		{},					TEST_UNTESTED,	probe_28sf040,		erase_28sf040,		NULL,		write_28sf040},
+	{"SST",		"SST29EE010",		SST_ID,		SST_29EE010,		128,	128,		{},					TEST_OK_PREW,	probe_jedec,		erase_chip_jedec,	NULL,		write_jedec},
+	{"SST",		"SST29LE010",		SST_ID,		SST_29LE010,		128,	128,		{},					TEST_UNTESTED,	probe_jedec,		erase_chip_jedec, 	NULL,		write_jedec},
+	{"SST",		"SST29EE020A",		SST_ID,		SST_29EE020A,		256,	128,		{},					TEST_UNTESTED,	probe_jedec,		erase_chip_jedec,	NULL,		write_jedec},
+	{"SST",		"SST29LE020",		SST_ID,		SST_29LE020,		256,	128,		{},					TEST_UNTESTED,	probe_jedec,		erase_chip_jedec,	NULL,		write_jedec},
+	{"SST",		"SST39SF010A",		SST_ID,		SST_39SF010,		128,	4096,		{},					TEST_OK_PREW,	probe_jedec,		erase_chip_jedec,	NULL,		write_39sf020},
+	{"SST",		"SST39SF020A",		SST_ID,		SST_39SF020,		256,	4096,		{},					TEST_OK_PREW,	probe_jedec,		erase_chip_jedec,	NULL,		write_39sf020},
+	{"SST",		"SST39SF040",		SST_ID,		SST_39SF040,		512,	4096,		{},					TEST_UNTESTED,	probe_jedec,		erase_chip_jedec,	NULL,		write_39sf020},
+	{"SST",		"SST39VF512",		SST_ID,		SST_39VF512,		64,	4096,		{},					TEST_UNTESTED,	probe_jedec,		erase_chip_jedec,	NULL,		write_39sf020},
+	{"SST",		"SST39VF010",		SST_ID,		SST_39VF010,		128,	4096,		{},					TEST_UNTESTED,	probe_jedec,		erase_chip_jedec,	NULL,		write_39sf020},
+	{"SST",		"SST39VF020",		SST_ID,		SST_39VF020,		256,	4096,		{},					TEST_UNTESTED,	probe_jedec,		erase_chip_jedec,	NULL,		write_39sf020},
+	{"SST",		"SST39VF040",		SST_ID,		SST_39VF040,		512,	4096,		{},					TEST_OK_PROBE,	probe_jedec,		erase_chip_jedec,	NULL,		write_39sf020},
 // assume similar to 004B, ignoring data sheet
-	{"SST",		"SST49LF002A/B",	SST_ID,		SST_49LF002A,		256,	16 * 1024,	TEST_OK_PREW,	probe_sst_fwhub,	erase_sst_fwhub,		write_sst_fwhub},
-	{"SST",		"SST49LF003A/B",	SST_ID,		SST_49LF003A,		384,	64 * 1024,	TEST_UNTESTED,	probe_sst_fwhub,	erase_sst_fwhub,		write_sst_fwhub},
-	{"SST",		"SST49LF004A/B",	SST_ID,		SST_49LF004A,		512,	64 * 1024,	TEST_OK_PREW,	probe_sst_fwhub,	erase_sst_fwhub,		write_sst_fwhub},
-	{"SST",		"SST49LF004C",		SST_ID,		SST_49LF004C,		512,	4 * 1024,	TEST_UNTESTED,	probe_49lfxxxc,		erase_49lfxxxc,			write_49lfxxxc},
-	{"SST",		"SST49LF008A",		SST_ID,		SST_49LF008A,		1024,	64 * 1024,	TEST_OK_PREW,	probe_sst_fwhub,	erase_sst_fwhub,		write_sst_fwhub},
-	{"SST",		"SST49LF008C",		SST_ID,		SST_49LF008C,		1024,	4 * 1024,	TEST_UNTESTED,	probe_49lfxxxc,		erase_49lfxxxc,			write_49lfxxxc},
-	{"SST",		"SST49LF016C",		SST_ID,		SST_49LF016C,		2048,	4 * 1024,	TEST_OK_PREW,	probe_49lfxxxc,		erase_49lfxxxc,			write_49lfxxxc},
-	{"SST",		"SST49LF020A",		SST_ID,		SST_49LF020A,		256,	16 * 1024,	TEST_UNTESTED,	probe_jedec,		erase_49lf040,			write_49lf040},
-	{"SST",		"SST49LF040",		SST_ID,		SST_49LF040,		512,	4096,		TEST_OK_PREW,	probe_jedec,		erase_49lf040,			write_49lf040},
-	{"SST",		"SST49LF040B",		SST_ID,		SST_49LF040B,		512,	64 * 1024,	TEST_OK_PREW,	probe_sst_fwhub,	erase_sst_fwhub,		write_sst_fwhub},
-	{"SST",		"SST49LF080A",		SST_ID,		SST_49LF080A,		1024,	4096,		TEST_OK_PREW,	probe_jedec,		erase_49lf040,			write_49lf040},
-	{"SST",		"SST49LF160C",		SST_ID,		SST_49LF160C,		2048,	4 * 1024,	TEST_OK_PREW,	probe_49lfxxxc,		erase_49lfxxxc,			write_49lfxxxc},
-	{"ST",		"M25P05-A",		ST_ID,		ST_M25P05A,		64,	256,		TEST_UNTESTED,	probe_spi_rdid,		spi_chip_erase_c7,	spi_chip_write, spi_chip_read},
-	{"ST",		"M25P10-A",		ST_ID,		ST_M25P10A,		128,	256,		TEST_UNTESTED,	probe_spi_rdid,		spi_chip_erase_c7,	spi_chip_write, spi_chip_read},
-	{"ST",		"M25P20",		ST_ID,		ST_M25P20,		256,	256,		TEST_UNTESTED,	probe_spi_rdid,		spi_chip_erase_c7,	spi_chip_write, spi_chip_read},
-	{"ST",		"M25P40",		ST_ID,		ST_M25P40,		512,	256,		TEST_UNTESTED,	probe_spi_rdid,		spi_chip_erase_c7,	spi_chip_write, spi_chip_read},
-	{"ST",		"M25P40-old",		ST_ID,		ST_M25P40_RES,		512,	256,		TEST_UNTESTED,	probe_spi_res,		spi_chip_erase_c7,	spi_chip_write, spi_chip_read},
-	{"ST",		"M25P80",		ST_ID,		ST_M25P80,		1024,	256,		TEST_UNTESTED,	probe_spi_rdid,		spi_chip_erase_c7,	spi_chip_write, spi_chip_read},
-	{"ST",		"M25P16",		ST_ID,		ST_M25P16,		2048,	256,		TEST_UNTESTED,	probe_spi_rdid,		spi_chip_erase_c7,	spi_chip_write, spi_chip_read},
-	{"ST",		"M25P32",		ST_ID,		ST_M25P32,		4096,	256,		TEST_OK_PREW,	probe_spi_rdid,		spi_chip_erase_c7,	spi_chip_write, spi_chip_read},
-	{"ST",		"M25P64",		ST_ID,		ST_M25P64,		8192,	256,		TEST_UNTESTED,	probe_spi_rdid,		spi_chip_erase_c7,	spi_chip_write, spi_chip_read},
-	{"ST",		"M25P128",		ST_ID,		ST_M25P128,		16384,	256,		TEST_UNTESTED,	probe_spi_rdid,		spi_chip_erase_c7,	spi_chip_write, spi_chip_read},
-	{"ST",		"M29F002B",		ST_ID,		ST_M29F002B,		256,	64 * 1024,	TEST_UNTESTED,	probe_jedec,		erase_chip_jedec,		write_jedec},
-	{"ST",		"M29F002T/NT",		ST_ID,		ST_M29F002T,		256,	64 * 1024,	TEST_UNTESTED,	probe_jedec,		erase_chip_jedec,		write_jedec},
-	{"ST",		"M29F040B",		ST_ID,		ST_M29F040B,		512,	64 * 1024,	TEST_OK_PREW,	probe_29f040b,		erase_29f040b,			write_29f040b},
-	{"ST",		"M29F400BT",		ST_ID,		ST_M29F400BT,		512,	64 * 1024,	TEST_UNTESTED,	probe_m29f400bt,	erase_m29f400bt,		write_coreboot_m29f400bt},
-	{"ST",		"M29W010B",		ST_ID,		ST_M29W010B,		128,	16 * 1024,	TEST_UNTESTED,	probe_jedec,		erase_chip_jedec,		write_jedec},
-	{"ST",		"M29W040B",		ST_ID,		ST_M29W040B,		512,	64 * 1024,	TEST_UNTESTED,	probe_jedec,		erase_chip_jedec,		write_jedec},
-	{"ST",		"M50FLW040A",		ST_ID,		ST_M50FLW040A,		512,	64 * 1024,	TEST_UNTESTED,	probe_stm50flw0x0x,	erase_stm50flw0x0x,		write_stm50flw0x0x},
-	{"ST",		"M50FLW040B",		ST_ID,		ST_M50FLW040B,		512,	64 * 1024,	TEST_UNTESTED,	probe_stm50flw0x0x,	erase_stm50flw0x0x,		write_stm50flw0x0x},
-	{"ST",		"M50FLW080A",		ST_ID,		ST_M50FLW080A,		1024,	64 * 1024,	TEST_OK_PREW,	probe_stm50flw0x0x,	erase_stm50flw0x0x,		write_stm50flw0x0x},
-	{"ST",		"M50FLW080B",		ST_ID,		ST_M50FLW080B,		1024,	64 * 1024,	TEST_UNTESTED,	probe_stm50flw0x0x,	erase_stm50flw0x0x,		write_stm50flw0x0x},
-	{"ST",		"M50FW002",		ST_ID,		ST_M50FW002,		256,	64 * 1024,	TEST_UNTESTED,	probe_49lfxxxc,		NULL,			NULL},
-	{"ST",		"M50FW016",		ST_ID,		ST_M50FW016,		2048,	64 * 1024,	TEST_UNTESTED,	probe_82802ab,		erase_82802ab,			write_82802ab},
-	{"ST",		"M50FW040",		ST_ID,		ST_M50FW040,		512,	64 * 1024,	TEST_OK_PREW,	probe_82802ab,		erase_82802ab,			write_82802ab},
-	{"ST",		"M50FW080",		ST_ID,		ST_M50FW080,		1024,	64 * 1024,	TEST_UNTESTED,	probe_82802ab,		erase_82802ab,			write_82802ab},
-	{"ST",		"M50LPW116",		ST_ID,		ST_M50LPW116,		2048,	64 * 1024,	TEST_UNTESTED,	probe_jedec,		erase_chip_jedec,		write_jedec},
-	{"SyncMOS",	"S29C31004T",		SYNCMOS_ID,	S29C31004T,		512,	128,		TEST_UNTESTED,	probe_jedec,		erase_chip_jedec,		write_49f002},
-	{"SyncMOS",	"S29C51001T",		SYNCMOS_ID,	S29C51001T,		128,	128,		TEST_UNTESTED,	probe_jedec,		erase_chip_jedec,		write_49f002},
-	{"SyncMOS",	"S29C51002T",		SYNCMOS_ID,	S29C51002T,		256,	128,		TEST_OK_PREW,	probe_jedec,		erase_chip_jedec,		write_49f002},
-	{"SyncMOS",	"S29C51004T",		SYNCMOS_ID,	S29C51004T,		512,	128,		TEST_UNTESTED,	probe_jedec,		erase_chip_jedec,		write_49f002},
-	{"Winbond",	"W25x10",		WINBOND_NEX_ID,	W_25X10,		128,	256,		TEST_UNTESTED,	probe_spi_rdid,		spi_chip_erase_c7,	spi_chip_write, spi_chip_read},
-	{"Winbond",	"W25x20",		WINBOND_NEX_ID,	W_25X20,		256,	256,		TEST_UNTESTED,	probe_spi_rdid,		spi_chip_erase_c7,	spi_chip_write, spi_chip_read},
-	{"Winbond",	"W25x40",		WINBOND_NEX_ID,	W_25X40,		512,	256,		TEST_OK_PREW,	probe_spi_rdid,		spi_chip_erase_c7,	spi_chip_write, spi_chip_read},
-	{"Winbond",	"W25x80",		WINBOND_NEX_ID,	W_25X80,		1024,	256,		TEST_OK_PREW,	probe_spi_rdid,		spi_chip_erase_c7,	spi_chip_write, spi_chip_read},
-	{"Winbond",	"W29C011",		WINBOND_ID,	W_29C011,		128,	128,		TEST_OK_PREW,	probe_jedec,		erase_chip_jedec,		write_jedec},
-	{"Winbond",	"W29C020C",		WINBOND_ID,	W_29C020C,		256,	128,		TEST_OK_PREW,	probe_jedec,		erase_chip_jedec,		write_jedec},
-	{"Winbond",	"W29C040P",		WINBOND_ID,	W_29C040P,		512,	256,		TEST_UNTESTED,	probe_jedec,		erase_chip_jedec,		write_jedec},
-	{"Winbond",	"W29EE011",		WINBOND_ID,	W_29C011,		128,	128,		TEST_OK_PREW,	probe_w29ee011,		erase_chip_jedec,		write_jedec},
-	{"Winbond",	"W39V040A",		WINBOND_ID,	W_39V040A,		512,	64*1024,	TEST_UNTESTED,	probe_jedec,		erase_chip_jedec,		write_39sf020},
-	{"Winbond",	"W39V040B",		WINBOND_ID,	W_39V040B,		512,	64*1024,	TEST_OK_PREW,	probe_jedec,		erase_chip_jedec,		write_39sf020},
-	{"Winbond",	"W39V040C",		WINBOND_ID,	0x50,			512,	64*1024,	TEST_OK_PREW,	probe_w39v040c,		erase_w39v040c,			write_w39v040c},
-	{"Winbond",	"W39V040FA",		WINBOND_ID,	W_39V040FA,		512,	64*1024,	TEST_OK_PREW,	probe_jedec,		erase_chip_jedec,		write_39sf020},
-	{"Winbond",	"W39V080A",		WINBOND_ID,	W_39V080A,		1024,	64*1024,	TEST_OK_PREW,	probe_jedec,		erase_chip_jedec,		write_39sf020},
-	{"Winbond",	"W49F002U",		WINBOND_ID,	W_49F002U,		256,	128,		TEST_OK_PREW,	probe_jedec,		erase_chip_jedec,		write_49f002},
-	{"Winbond",	"W49V002A",		WINBOND_ID,	W_49V002A,		256,	128,		TEST_OK_PREW,	probe_jedec,		erase_chip_jedec,		write_49f002},
-	{"Winbond",	"W49V002FA",		WINBOND_ID,	W_49V002FA,		256,	128,		TEST_UNTESTED,	probe_jedec,		erase_chip_jedec,		write_49f002},
-	{"Winbond",	"W39V080FA",		WINBOND_ID,	W_39V080FA,		1024,	64*1024,	TEST_OK_PREW,	probe_winbond_fwhub,	erase_winbond_fwhub,		write_winbond_fwhub},
-	{"Winbond",	"W39V080FA (dual mode)",WINBOND_ID,	W_39V080FA_DM,		512,	64*1024,	TEST_UNTESTED,	probe_winbond_fwhub,	erase_winbond_fwhub,		write_winbond_fwhub},
+	{"SST",		"SST49LF002A/B",	SST_ID,		SST_49LF002A,		256,	16 * 1024,	{},					TEST_OK_PREW,	probe_sst_fwhub,	erase_sst_fwhub,	NULL,		write_sst_fwhub},
+	{"SST",		"SST49LF003A/B",	SST_ID,		SST_49LF003A,		384,	64 * 1024,	{},					TEST_UNTESTED,	probe_sst_fwhub,	erase_sst_fwhub,	NULL,		write_sst_fwhub},
+	{"SST",		"SST49LF004A/B",	SST_ID,		SST_49LF004A,		512,	64 * 1024,	{},					TEST_OK_PREW,	probe_sst_fwhub,	erase_sst_fwhub,	NULL,		write_sst_fwhub},
+	{"SST",		"SST49LF004C",		SST_ID,		SST_49LF004C,		512,	4 * 1024,	{},					TEST_UNTESTED,	probe_49lfxxxc,		erase_49lfxxxc,		NULL,		write_49lfxxxc},
+	{"SST",		"SST49LF008A",		SST_ID,		SST_49LF008A,		1024,	64 * 1024,	{},					TEST_OK_PREW,	probe_sst_fwhub,	erase_sst_fwhub,	NULL,		write_sst_fwhub},
+	{"SST",		"SST49LF008C",		SST_ID,		SST_49LF008C,		1024,	4 * 1024,	{},					TEST_UNTESTED,	probe_49lfxxxc,		erase_49lfxxxc,		NULL,		write_49lfxxxc},
+	{"SST",		"SST49LF016C",		SST_ID,		SST_49LF016C,		2048,	4 * 1024,	{},					TEST_OK_PREW,	probe_49lfxxxc,		erase_49lfxxxc,		NULL,		write_49lfxxxc},
+	{"SST",		"SST49LF020A",		SST_ID,		SST_49LF020A,		256,	16 * 1024,	{},					TEST_UNTESTED,	probe_jedec,		erase_49lf040,		NULL,		write_49lf040},
+	{"SST",		"SST49LF040",		SST_ID,		SST_49LF040,		512,	4096,		{},					TEST_OK_PREW,	probe_jedec,		erase_49lf040,		NULL,		write_49lf040},
+	{"SST",		"SST49LF040B",		SST_ID,		SST_49LF040B,		512,	64 * 1024,	{},					TEST_OK_PREW,	probe_sst_fwhub,	erase_sst_fwhub,	NULL,		write_sst_fwhub},
+	{"SST",		"SST49LF080A",		SST_ID,		SST_49LF080A,		1024,	4096,		{},					TEST_OK_PREW,	probe_jedec,		erase_49lf040,		NULL,		write_49lf040},
+	{"SST",		"SST49LF160C",		SST_ID,		SST_49LF160C,		2048,	4 * 1024,	{},					TEST_OK_PREW,	probe_49lfxxxc,		erase_49lfxxxc,		NULL,		write_49lfxxxc},
+	{"ST",		"M25P05-A",		ST_ID,		ST_M25P05A,		64,	256,		{},					TEST_UNTESTED,	probe_spi_rdid,		spi_chip_erase_c7,	NULL,		spi_chip_write, spi_chip_read},
+	{"ST",		"M25P10-A",		ST_ID,		ST_M25P10A,		128,	256,		{},					TEST_UNTESTED,	probe_spi_rdid,		spi_chip_erase_c7,	NULL,		spi_chip_write, spi_chip_read},
+	{"ST",		"M25P20",		ST_ID,		ST_M25P20,		256,	256,		{},					TEST_UNTESTED,	probe_spi_rdid,		spi_chip_erase_c7,	NULL,		spi_chip_write, spi_chip_read},
+	{"ST",		"M25P40",		ST_ID,		ST_M25P40,		512,	256,		{},					TEST_UNTESTED,	probe_spi_rdid,		spi_chip_erase_c7,	NULL,		spi_chip_write, spi_chip_read},
+	{"ST",		"M25P40-old",		ST_ID,		ST_M25P40_RES,		512,	256,		{},					TEST_UNTESTED,	probe_spi_res,		spi_chip_erase_c7,	NULL,		spi_chip_write, spi_chip_read},
+	{"ST",		"M25P80",		ST_ID,		ST_M25P80,		1024,	256,		{},					TEST_UNTESTED,	probe_spi_rdid,		spi_chip_erase_c7,	NULL,		spi_chip_write, spi_chip_read},
+	{"ST",		"M25P16",		ST_ID,		ST_M25P16,		2048,	256,		{},					TEST_UNTESTED,	probe_spi_rdid,		spi_chip_erase_c7,	NULL,		spi_chip_write, spi_chip_read},
+	{"ST",		"M25P32",		ST_ID,		ST_M25P32,		4096,	256,		{},					TEST_OK_PREW,	probe_spi_rdid,		spi_chip_erase_c7,	NULL,		spi_chip_write, spi_chip_read},
+	{"ST",		"M25P64",		ST_ID,		ST_M25P64,		8192,	256,		{},					TEST_UNTESTED,	probe_spi_rdid,		spi_chip_erase_c7,	NULL,		spi_chip_write, spi_chip_read},
+	{"ST",		"M25P128",		ST_ID,		ST_M25P128,		16384,	256,		{},					TEST_UNTESTED,	probe_spi_rdid,		spi_chip_erase_c7,	NULL,		spi_chip_write, spi_chip_read},
+	{"ST",		"M29F002B",		ST_ID,		ST_M29F002B,		256,	64 * 1024,	{},					TEST_UNTESTED,	probe_jedec,		erase_chip_jedec,	NULL,		write_jedec},
+	{"ST",		"M29F002T/NT",		ST_ID,		ST_M29F002T,		256,	64 * 1024,	{},					TEST_UNTESTED,	probe_jedec,		erase_chip_jedec,	NULL,		write_jedec},
+	{"ST",		"M29F040B",		ST_ID,		ST_M29F040B,		512,	64 * 1024,	{},					TEST_OK_PREW,	probe_29f040b,		erase_29f040b,		NULL,		write_29f040b},
+	{"ST",		"M29F400BT",		ST_ID,		ST_M29F400BT,		512,	64 * 1024,	{},					TEST_UNTESTED,	probe_m29f400bt,	erase_m29f400bt,	NULL,		write_coreboot_m29f400bt},
+	{"ST",		"M29W010B",		ST_ID,		ST_M29W010B,		128,	16 * 1024,	{},					TEST_UNTESTED,	probe_jedec,		erase_chip_jedec,	NULL,		write_jedec},
+	{"ST",		"M29W040B",		ST_ID,		ST_M29W040B,		512,	64 * 1024,	{},					TEST_UNTESTED,	probe_jedec,		erase_chip_jedec,	NULL,		write_jedec},
+	{"ST",		"M50FLW040A",		ST_ID,		ST_M50FLW040A,		512,	64 * 1024,	{},					TEST_UNTESTED,	probe_stm50flw0x0x,	erase_stm50flw0x0x,	NULL,		write_stm50flw0x0x},
+	{"ST",		"M50FLW040B",		ST_ID,		ST_M50FLW040B,		512,	64 * 1024,	{},					TEST_UNTESTED,	probe_stm50flw0x0x,	erase_stm50flw0x0x,	NULL,		write_stm50flw0x0x},
+	{"ST",		"M50FLW080A",		ST_ID,		ST_M50FLW080A,		1024,	64 * 1024,	{},					TEST_OK_PREW,	probe_stm50flw0x0x,	erase_stm50flw0x0x,	NULL,		write_stm50flw0x0x},
+	{"ST",		"M50FLW080B",		ST_ID,		ST_M50FLW080B,		1024,	64 * 1024,	{},					TEST_UNTESTED,	probe_stm50flw0x0x,	erase_stm50flw0x0x,	NULL,		write_stm50flw0x0x},
+	{"ST",		"M50FW002",		ST_ID,		ST_M50FW002,		256,	64 * 1024,	{},					TEST_UNTESTED,	probe_49lfxxxc,		NULL,			NULL,		NULL},
+	{"ST",		"M50FW016",		ST_ID,		ST_M50FW016,		2048,	64 * 1024,	{},					TEST_UNTESTED,	probe_82802ab,		erase_82802ab,		NULL,		write_82802ab},
+	{"ST",		"M50FW040",		ST_ID,		ST_M50FW040,		512,	64 * 1024,	{},					TEST_OK_PREW,	probe_82802ab,		erase_82802ab,		NULL,		write_82802ab},
+	{"ST",		"M50FW080",		ST_ID,		ST_M50FW080,		1024,	64 * 1024,	{},					TEST_UNTESTED,	probe_82802ab,		erase_82802ab,		NULL,		write_82802ab},
+	{"ST",		"M50LPW116",		ST_ID,		ST_M50LPW116,		2048,	64 * 1024,	{},					TEST_UNTESTED,	probe_jedec,		erase_chip_jedec,	NULL,		write_jedec},
+	{"SyncMOS",	"S29C31004T",		SYNCMOS_ID,	S29C31004T,		512,	128,		{},					TEST_UNTESTED,	probe_jedec,		erase_chip_jedec,	NULL,		write_49f002},
+	{"SyncMOS",	"S29C51001T",		SYNCMOS_ID,	S29C51001T,		128,	128,		{},					TEST_UNTESTED,	probe_jedec,		erase_chip_jedec,	NULL,		write_49f002},
+	{"SyncMOS",	"S29C51002T",		SYNCMOS_ID,	S29C51002T,		256,	128,		{},					TEST_OK_PREW,	probe_jedec,		erase_chip_jedec,	NULL,		write_49f002},
+	{"SyncMOS",	"S29C51004T",		SYNCMOS_ID,	S29C51004T,		512,	128,		{},					TEST_UNTESTED,	probe_jedec,		erase_chip_jedec,	NULL,		write_49f002},
+	{"Winbond",	"W25x10",		WINBOND_NEX_ID,	W_25X10,		128,	256,		{},					TEST_UNTESTED,	probe_spi_rdid,		spi_chip_erase_c7,	NULL,		spi_chip_write, spi_chip_read},
+	{"Winbond",	"W25x20",		WINBOND_NEX_ID,	W_25X20,		256,	256,		{},					TEST_UNTESTED,	probe_spi_rdid,		spi_chip_erase_c7,	NULL,		spi_chip_write, spi_chip_read},
+	{"Winbond",	"W25x40",		WINBOND_NEX_ID,	W_25X40,		512,	256,		{},					TEST_OK_PREW,	probe_spi_rdid,		spi_chip_erase_c7,	NULL,		spi_chip_write, spi_chip_read},
+	{"Winbond",	"W25x80",		WINBOND_NEX_ID,	W_25X80,		1024,	256,		{},					TEST_OK_PREW,	probe_spi_rdid,		spi_chip_erase_c7,	NULL,		spi_chip_write, spi_chip_read},
+	{"Winbond",	"W29C011",		WINBOND_ID,	W_29C011,		128,	128,		{},					TEST_OK_PREW,	probe_jedec,		erase_chip_jedec,	NULL,		write_jedec},
+	{"Winbond",	"W29C020C",		WINBOND_ID,	W_29C020C,		256,	128,		{},					TEST_OK_PREW,	probe_jedec,		erase_chip_jedec,	NULL,		write_jedec},
+	{"Winbond",	"W29C040P",		WINBOND_ID,	W_29C040P,		512,	256,		{},					TEST_UNTESTED,	probe_jedec,		erase_chip_jedec,	NULL,		write_jedec},
+	{"Winbond",	"W29EE011",		WINBOND_ID,	W_29C011,		128,	128,		{},					TEST_OK_PREW,	probe_w29ee011,		erase_chip_jedec,	NULL,		write_jedec},
+	{"Winbond",	"W39V040A",		WINBOND_ID,	W_39V040A,		512,	64*1024,	{},					TEST_UNTESTED,	probe_jedec,		erase_chip_jedec,	NULL,		write_39sf020},
+	{"Winbond",	"W39V040B",		WINBOND_ID,	W_39V040B,		512,	64*1024,	{},					TEST_OK_PREW,	probe_jedec,		erase_chip_jedec,	NULL,		write_39sf020},
+	{"Winbond",	"W39V040C",		WINBOND_ID,	0x50,			512,	64*1024,	{},					TEST_OK_PREW,	probe_w39v040c,		erase_w39v040c,		NULL,		write_w39v040c},
+	{"Winbond",	"W39V040FA",		WINBOND_ID,	W_39V040FA,		512,	64*1024,	{},					TEST_OK_PREW,	probe_jedec,		erase_chip_jedec,	NULL,		write_39sf020},
+	{"Winbond",	"W39V080A",		WINBOND_ID,	W_39V080A,		1024,	64*1024,	{},					TEST_OK_PREW,	probe_jedec,		erase_chip_jedec,	NULL,		write_39sf020},
+	{"Winbond",	"W49F002U",		WINBOND_ID,	W_49F002U,		256,	128,		{},					TEST_OK_PREW,	probe_jedec,		erase_chip_jedec,	NULL,		write_49f002},
+	{"Winbond",	"W49V002A",		WINBOND_ID,	W_49V002A,		256,	128,		{},					TEST_OK_PREW,	probe_jedec,		erase_chip_jedec,	NULL,		write_49f002},
+	{"Winbond",	"W49V002FA",		WINBOND_ID,	W_49V002FA,		256,	128,		{},					TEST_UNTESTED,	probe_jedec,		erase_chip_jedec,	NULL,		write_49f002},
+	{"Winbond",	"W39V080FA",		WINBOND_ID,	W_39V080FA,		1024,	64*1024,	{},					TEST_OK_PREW,	probe_winbond_fwhub,	erase_winbond_fwhub,	NULL,		write_winbond_fwhub},
+	{"Winbond",	"W39V080FA (dual mode)",WINBOND_ID,	W_39V080FA_DM,		512,	64*1024,	{},					TEST_UNTESTED,	probe_winbond_fwhub,	erase_winbond_fwhub,	NULL,		write_winbond_fwhub},
 
-	{"EON",		"unknown EON SPI chip",	EON_ID_NOPREFIX,GENERIC_DEVICE_ID,	0,	256,		TEST_UNTESTED,	probe_spi_rdid,		NULL,				NULL},
-	{"Macronix",	"unknown Macronix SPI chip",	MX_ID,	GENERIC_DEVICE_ID,	0,	256,		TEST_UNTESTED,	probe_spi_rdid,		NULL,				NULL},
-	{"PMC",		"unknown PMC SPI chip",	PMC_ID,		GENERIC_DEVICE_ID,	0,	256,		TEST_UNTESTED,	probe_spi_rdid,		NULL,				NULL},
-	{"SST",		"unknown SST SPI chip",	SST_ID,		GENERIC_DEVICE_ID,	0,	256,		TEST_UNTESTED,	probe_spi_rdid,		NULL,				NULL},
-	{"ST",		"unknown ST SPI chip",	ST_ID,		GENERIC_DEVICE_ID,	0,	256,		TEST_UNTESTED,	probe_spi_rdid,		NULL,				NULL},
+	{"EON",		"unknown EON SPI chip",	EON_ID_NOPREFIX,GENERIC_DEVICE_ID,	0,	256,		{},					TEST_UNTESTED,	probe_spi_rdid,		NULL,			NULL},
+	{"Macronix",	"unknown Macronix SPI chip",	MX_ID,	GENERIC_DEVICE_ID,	0,	256,		{},					TEST_UNTESTED,	probe_spi_rdid,		NULL,			NULL},
+	{"PMC",		"unknown PMC SPI chip",	PMC_ID,		GENERIC_DEVICE_ID,	0,	256,		{},					TEST_UNTESTED,	probe_spi_rdid,		NULL,			NULL},
+	{"SST",		"unknown SST SPI chip",	SST_ID,		GENERIC_DEVICE_ID,	0,	256,		{},					TEST_UNTESTED,	probe_spi_rdid,		NULL,			NULL},
+	{"ST",		"unknown ST SPI chip",	ST_ID,		GENERIC_DEVICE_ID,	0,	256,		{},					TEST_UNTESTED,	probe_spi_rdid,		NULL,			NULL},
 
 	{NULL,}
 };
Index: flashrom-eraseblocks/flashrom.c
===================================================================
--- flashrom-eraseblocks/flashrom.c	(Revision 3730)
+++ flashrom-eraseblocks/flashrom.c	(Arbeitskopie)
@@ -534,11 +534,33 @@
 
 	if (erase_it) {
 		printf("Erasing flash chip.\n");
-		if (!flash->erase) {
-			fprintf(stderr, "Error: flashrom has no erase function for this flash chip.\n");
+		if (!flash->block_erase && flash->eraseblocks[0].count) {
+			fprintf(stderr, "Hint: flashrom knows the eraseblock "
+				"layout, but there is no blockwise erase "
+				"function for this flash chip. "
+				"Using whole-chip erase.\n");
+		}
+		if (flash->block_erase && !flash->eraseblocks[0].count) {
+			fprintf(stderr, "Hint: flashrom has a blockwise erase "
+				"function for this flash chip, but the "
+				"eraseblock layout is unknown. "
+				"Using whole-chip erase.\n");
+		}
+		if (flash->block_erase && flash->eraseblocks[0].count) {
+			unsigned long done = 0;
+			int i, j;
+			for (i = 0; done < flash->total_size * 1024; i++) {
+				for (j = 0; j < flash->eraseblocks[i].count; j++) {
+					flash->block_erase(flash, done + flash->eraseblocks[i].size * j);
+				}
+				done += flash->eraseblocks[i].count * flash->eraseblocks[i].size;
+			}
+		} else if (flash->erase) {
+			flash->erase(flash);
+		} else {
+			fprintf(stderr, "Error: flashrom has no chip erase function for this flash chip.\n");
 			return 1;
 		}
-		flash->erase(flash);
 		exit(0);
 	} else if (read_it) {
 		if ((image = fopen(filename, "w")) == NULL) {


-- 
http://www.hailfinger.org/

-------------- next part --------------
A non-text attachment was scrubbed...
Name: flashrom_generic_block_erase.diff
Type: text/x-patch
Size: 39612 bytes
Desc: not available
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20081104/db730405/attachment.diff>

From c-d.hailfinger.devel.2006 at gmx.net  Tue Nov  4 15:58:40 2008
From: c-d.hailfinger.devel.2006 at gmx.net (Carl-Daniel Hailfinger)
Date: Tue, 04 Nov 2008 15:58:40 +0100
Subject: [coreboot] [PATCH] CN700/VT8237R stage2
In-Reply-To: <490CCA08.5090302@gmx.net>
References: <dd3c80060810290102o7b28a867y4b103e8b6ee4c621@mail.gmail.com>		<490A4CC6.2070602@gmx.net>		<dd3c80060810301736y123561c7p7dc1646397f13732@mail.gmail.com>		<490BB5F7.508@gmx.net>
	<490BB7F6.9030509@gmx.net>		<dd3c80060810312206s558be78fs7f03da2715fe9dfd@mail.gmail.com>		<dd3c80060810312208g49db1707j839fb9f18f4867f6@mail.gmail.com>		<490C3E8C.7050307@gmx.net>
	<490C3FB1.8050901@gmx.net>	<dd3c80060811011056k240a2b28ha80e33f11b4bb8df@mail.gmail.com>
	<490CA9F1.90704@gmx.net> <490CCA08.5090302@gmx.net>
Message-ID: <49106320.60609@gmx.net>

On 01.11.2008 22:28, Carl-Daniel Hailfinger wrote:
> On 01.11.2008 20:11, Carl-Daniel Hailfinger wrote:
>   
>> On 01.11.2008 18:56, Corey Osgood wrote:
>>   
>>     
>>> System reset seems to occur between 2 and 3, both of those logs attached,
>>> along with arch/x86/via/stage1.o With HALT_AFTER=3, the post code keeps
>>> changing, as expected with the system rebooting, with HALT_AFTER=2 it was
>>> 0xc2.
>>>   
>>>     
>>>       
>> Great results, thanks a lot!
>> One bug spotted and fixed. Can you retest with the same method and the
>> updated patch attached to this mail? I hope it will die much later,
>> perhaps at HALT_AFTER=13 or so.
>>   
>>     
>
> Thanks for the information that HALT_AFTER=5 is the last working setting.
>   

OK, I reread every line of the code and reimplemented the problematic
stuff from scratch.

Can you try the new patch with HALT_AFTER=5 and 6? I'm pretty confident
that if 6 works, all later numbers should also not reboot.
By the way, the new code should be even better than the (working) v2 code.

Regards,
Carl-Daniel

-- 
http://www.hailfinger.org/

-------------- next part --------------
A non-text attachment was scrubbed...
Name: linuxbios3_car_via_disable_car_debug06.diff
Type: text/x-patch
Size: 10467 bytes
Desc: not available
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20081104/9a2547e7/attachment.diff>

From rmh at aybabtu.com  Tue Nov  4 17:13:38 2008
From: rmh at aybabtu.com (Robert Millan)
Date: Tue, 4 Nov 2008 17:13:38 +0100
Subject: [coreboot] Multiboot for coreboot v2
In-Reply-To: <20081021171329.GD15868@cosmic.amd.com>
References: <20080924182347.GA9052@thorin>
	<13426df10809241214v3f5eaf3fi41b3e9399c036407@mail.gmail.com>
	<20080925121037.GA32284@thorin>
	<13426df10809250712s450a077bw4d83d5b54cd787d7@mail.gmail.com>
	<20080927223435.GA17672@thorin>
	<20081021171329.GD15868@cosmic.amd.com>
Message-ID: <20081104161338.GA10618@thorin>


Hi!

On Tue, Oct 21, 2008 at 11:13:29AM -0600, Jordan Crouse wrote:
> On 28/09/08 00:34 +0200, Robert Millan wrote:
> > On Thu, Sep 25, 2008 at 07:12:46AM -0700, ron minnich wrote:
> > > On Thu, Sep 25, 2008 at 5:10 AM, Robert Millan <rmh at aybabtu.com> wrote:
> > > > On Wed, Sep 24, 2008 at 12:14:15PM -0700, ron minnich wrote:
> > > >> yes, it is not being used. ELF parsing is not a default in v3 and will
> > > >> I hope someday be completely gone.
> > > >
> > > > I have a working patch already.  Now the question is, since both options are
> > > > incompatible, which do we make the default?
> > > >
> > > 
> > > muliboot
> > 
> > Ok.  Here it it.
> 
> This looks reasonable, but I  need to find some time to test it.  If
> anybody else wants to ack/commit they can.

Any news about this?

-- 
Robert Millan

  The DRM opt-in fallacy: "Your data belongs to us. We will decide when (and
  how) you may access your data; but nobody's threatening your freedom: we
  still allow you to remove your data and not access it at all."



From c-d.hailfinger.devel.2006 at gmx.net  Tue Nov  4 17:18:34 2008
From: c-d.hailfinger.devel.2006 at gmx.net (Carl-Daniel Hailfinger)
Date: Tue, 04 Nov 2008 17:18:34 +0100
Subject: [coreboot]  SeaBIOS: Microsoft interoperability
Message-ID: <491075DA.1080406@gmx.net>

Hi,

does anyone have good contacts to Microsoft development?
MS just opened an interoperability lab near Munich (Germany) and I was
wondering whether we should call them to find out if/how that lab can
help test and/or fix remaining issues with ACPI, SeaBIOS and Windows.

Regards,
Carl-Daniel

-- 
http://www.hailfinger.org/




From jyrit at artecdesign.ee  Tue Nov  4 17:09:32 2008
From: jyrit at artecdesign.ee (jyrit)
Date: Tue, 04 Nov 2008 18:09:32 +0200
Subject: [coreboot] Artec Group Dongle II cvs is up on opencores.org
Message-ID: <491073BC.7040507@artecdesign.ee>

Hi,

there is a new project up for the Artec Dongle II firmware/software 
development
on opencores.org

http://www.opencores.org/projects.cgi/web/artec_dongle_ii_fpga/overview

with it's DONE and TODO lists (the later is grater at the moment) so all the
help is welcome.


All the best,
J?ri Toomessoo



From jordan.crouse at amd.com  Tue Nov  4 17:35:21 2008
From: jordan.crouse at amd.com (Jordan Crouse)
Date: Tue, 4 Nov 2008 09:35:21 -0700
Subject: [coreboot] coreinfo
Message-ID: <20081104163521.GA5424@cosmic.amd.com>

Here is a coreinfo.elf with multiboot capability.

Jordan
-- 
Jordan Crouse
Systems Software Development Engineer 
Advanced Micro Devices, Inc.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: coreinfo.elf
Type: application/octet-stream
Size: 53500 bytes
Desc: not available
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20081104/c8ba0f83/attachment.obj>

From svn at coreboot.org  Tue Nov  4 18:00:07 2008
From: svn at coreboot.org (svn at coreboot.org)
Date: Tue,  4 Nov 2008 18:00:07 +0100
Subject: [coreboot] r979 - coreboot-v3/arch/x86/amd/model_fxx
Message-ID: <mailman.2384.1355071424.16123.coreboot@coreboot.org>

Author: mjones
Date: 2008-11-04 18:00:07 +0100 (Tue, 04 Nov 2008)
New Revision: 979

Modified:
   coreboot-v3/arch/x86/amd/model_fxx/fidvid.c
Log:
Update K8 FID/VID setup to match coreboot v2. Add support for 100MHz FIDs
(revG).

Signed-off-by: Marc Jones <marc.jones at amd.com>
Acked-by: Uwe Hermann <uwe at hermann-uwe.de>
Acked-by: Carl-Daniel Hailfinger <c-d.hailfinger.devel.2006 at gmx.net>



Modified: coreboot-v3/arch/x86/amd/model_fxx/fidvid.c
===================================================================
--- coreboot-v3/arch/x86/amd/model_fxx/fidvid.c	2008-11-02 14:47:21 UTC (rev 978)
+++ coreboot-v3/arch/x86/amd/model_fxx/fidvid.c	2008-11-04 17:00:07 UTC (rev 979)
@@ -80,59 +80,68 @@
 
 static unsigned set_fidvid(unsigned apicid, unsigned fidvid, int showmessage)
 {
-	/* for (cur, new) there is one <1600MHz x8 to find out next_fid */
-	static const u8 next_fid_a[] = {
-	/*  x4  x5  x6  x7  x8  x9 x10 x11 x12 x13 x14 x15 */
-/* x4 */    0,  9,  9,  8,  9,  9,  9,  9,  9,  9,  9,  9,
-/* x5 */    9,  0, 11, 11,  9,  9, 10, 11, 11, 11, 11, 11,
-/* x6 */   11, 11,  0, 13, 11, 11, 11, 11, 12, 13, 13, 13,
-/* x7 */   13, 13, 13,  0, 13, 13, 13, 13, 13, 13, 14, 15,
-/* x8 */    4,  9,  9,  9,  0,  9,  9,  9,  9,  9,  9,  9,
-/* x9 */    4,  5, 10, 10,  8,  0,  0,  0,  0,  0,  0,  0,
-/*x10 */    9,  5, 11, 11,  9,  0,  0,  0,  0,  0,  0,  0,
-/*x11 */   10,  5,  6, 12, 10,  0,  0,  0,  0,  0,  0,  0,
-/*x12 */   11, 11,  6, 13, 11,  0,  0,  0,  0,  0,  0,  0,
-/*x13 */   12, 12,  6,  7, 12,  0,  0,  0,  0,  0,  0,  0,
-/*x14 */   13, 13, 13,  7, 13,  0,  0,  0,  0,  0,  0,  0,
-/*x15 */   14, 14, 14,  7, 14,  0,  0,  0,  0,  0,  0,  0,
-/* 0:x4, 2:x5....BASE=4, MIN=4, MAX=25, INC=2 result = (xX-BASE)*INC */
+
+/*  CurrentFID--> 4x(00h)   5x(02h)   6x(04h)   7x(06h) ...
+ *       --------------------------------------
+ * TargetFID   | Next_FID, Next_FID, Next_FID, Next_FID ...
+ *      |      | Next_FID, Next_FID, Next_FID, Next_FID ...
+ *     \|/     | Next_FID, Next_FID, Next_FID, Next_FID ...
+ */
+	static const u8 next_fid_200[] = {
+/*         x4  x5  x6  x7  x8  x9 x10 x11 x12 x13 x14 x15  x16 */
+/* x4 */    0, -1, -1, -1,  0,  0,  9, 10, 11, 12, 13, 14, 15, /*  800 */
+/* x5 */   -1,  0, -1, -1, -1,  5,  5,  5, 11, 12, 13, 14, 15, /* 1000 */
+/* x6 */   -1, -1,  0, -1, -1, -1, -1,  6,  6,  6, 13, 14, 15, /* 1200 */
+/* x7 */   -1, -1, -1,  0, -1, -1, -1, -1, -1,  7,  7,  7, 15, /* 1400 */
+/* lower table to upper table boarder (table 70 and 71 in BKDG) */
+/* x8 */    8, -1, -1, -1,  0,  8,  9, 10, 11, 12, 13, 14, 15, /* 1600 */
+/* x9 */    9,  9, -1, -1,  9,  0,  9, 10, 11, 12, 13, 14, 15, /* 1800 */
+/*x10 */    9, 10, -1, -1,  9, 10,  0, 10, 11, 12, 13, 14, 15, /* 2000 */
+/*x11 */    9, 11, 11, -1,  9, 10, 11,  0, 11, 12, 13, 14, 15, /* 2200 */
+/*x12 */    9, 11, 12, -1,  9, 10, 11, 12,  0, 12, 13, 14, 15, /* 2400 */
+/*x13 */    9, 11, 13, 13,  9, 10, 11, 12, 13,  0, 13, 14, 15, /* 2600 */
+/*x14 */    9, 11, 13, 14,  9, 10, 11, 12, 13, 14,  0, 14, 15, /* 2800 */
+/*x15 */    9, 11, 13, 15,  9, 10, 11, 12, 13, 14, 15,  0, 15, /* 3000 */
+/*x15 */    9, 11, 13, 15,  9, 10, 11, 12, 13, 14, 15, 16,  0, /* 3200 */
 	};
 
 	struct msr msr;
-	u32 vid;
-	u32 fid;
+	u32 vid_new;
+	u32 fid_new;
 	u32 vid_max;
 	u32 fid_max;
 	u32 vid_cur;
 	u32 fid_cur;
 	unsigned int apicidx;
 
-	int steps;
+	int step_limit;
 	int loop;
 
 	apicidx = lapicid();
 
 	if (apicid != apicidx) {
-		printk(BIOS_ERR, 
-			"wrong apicid, we want change %x, but it is %x\n", apicid, apicidx);
+		printk(BIOS_ERR,
+			"wrong apicid, we want change %x, but it is %x\n",
+			apicid, apicidx);
 		return fidvid;
 	}
 
-	fid = (fidvid >> 8) & 0x3f;
-	vid = (fidvid >> 16) & 0x3f;
+	fid_new = (fidvid >> 8) & 0x3f;
+	vid_new = (fidvid >> 16) & 0x3f;
 
 	msr = rdmsr(FIDVID_STATUS);
 
 	vid_cur = msr.hi & 0x3f;
 	fid_cur = msr.lo & 0x3f;
 
-	if ((vid_cur==vid) && (fid_cur==fid))
+	if ((vid_cur == vid_new) && (fid_cur == fid_new))
 		return fidvid;
 
-	vid_max = (msr.hi>>(48-32)) & 0x3f;
-	fid_max = ((msr.lo>>16) & 0x3f); /* max fid */
+	vid_max = (msr.hi >> (48-32)) & 0x3f;
+	fid_max = ((msr.lo >> 16) & 0x3f); /* max fid */
+
 #if FX_SUPPORT
-	if (fid_max>=((25-4)*2)) { /* FX max fid is 5G */
+	if (fid_max >= ((25 - 4) * 2)) { /* FX max fid is 5G */
 		fid_max = ((msr.lo >> 8) & 0x3f) + 5 * 2; /* max FID is min fid + 1G */
 		if (fid_max >= ((25-4) * 2)) {
 			fid_max = (10-4) * 2; /* hard set to 2G */
@@ -141,10 +150,20 @@
 #endif
 
 	/* set vid to max */
+	/* TODO - make this more correct. Not a big deal for setting max...
+	 * BKDG figure 11
+	 * if TargetFID > InitialFID
+	 *	TargetVID = FinalVID - RVO
+	 * else
+	 *	if CurrentVID > FinalVID
+	 *		TargetVID = FinalVID - RVO
+	 *	else
+	 *		TargetVID = CurrentVIDD - RVO
+	 */
 	msr.hi = 1;
 	msr.lo = (vid_max << 8) | (fid_cur);
 #if SB_VFSMAF == 1
-	msr.lo |= (1<<16); /* init changes */
+	msr.lo |= (1 << 16); /* init changes */
 #endif
 	wrmsr(FIDVID_CTL, msr);
 #if SB_VFSMAF == 0
@@ -152,38 +171,92 @@
 #endif
 
 
-	for (loop=0;loop<100000;loop++){
+	for (loop=0; loop < 100000; loop++){
 		msr = rdmsr(FIDVID_STATUS);
-		if (!(msr.lo & (1<<31)))
+		if (!(msr.lo & (1 << 31)))
 			break;
 	}
 	vid_cur = msr.hi & 0x3f;
 
-	steps = 8; //??
-	while ((fid_cur != fid) && (steps-- > 0)) {
+	/* BKDG figure 12 and 13
+	 * if current fid is odd
+	 *	current fid -1 (next lower and even fid)(odd fid for rev G)
+	 * if current fid in high-freq table
+	 *	while current fid < target fid
+	 *		transition to next higher fid in table
+	 * else if target fid > VCO portal of current fid
+	 *	transition to highest portal fid in higher fid table
+	 *		while current fid < target fid
+	 *			transition to next higher fid in table
+	 * else
+	 *	transition to target fid
+	 */
+	printk(BIOS_DEBUG, "Current fid_cur: 0x%x, fid_max: 0x%x\n",
+		fid_cur, fid_max);
+	printk(BIOS_DEBUG, "Requested fid_new: 0x%x\n", fid_new);
+
+	step_limit = 8; /* max 8 steps just in case... */
+	while ((fid_cur != fid_new) && (step_limit--)) {
 		u32 fid_temp;
-		if ((fid_cur > (8-4)*2) && (fid> (8-4)*2)) {
-			if (fid_cur<fid) {
+		int step;
+
+		if (fid_cur < fid_new)
+			/* Force Fid steps even. step == 0 means 100MHz step */
+			step = ((fid_new/2) - (fid_cur/2)) * 2;
+		else
+			step = ((fid_cur/2) - (fid_new/2)) * 2;
+
+		/* If 200Mhz step OR past 3200 max table value */
+		if ((step == 2) || (fid_new >= 0x18 || fid_cur >= 0x18)) {
+
+			printk(BIOS_DEBUG, "200MHZ step ");
+			/* Step +/- 200MHz at a time */
+			if (fid_cur < fid_new)
 				fid_temp = fid_cur + 2;
-				} else {
-					fid_temp = fid_cur - 2;
-				}
-		} else {
-			/* there is one < 8, So we need to lookup the table to
-			 * find the fid_cur */
+			else
+				fid_temp = fid_cur - 2;
+
+
+		} else if ( step > 2) {	/* If more than a 200Mhz step */
 			int temp;
-			temp = next_fid_a[(fid_cur/2)*12+(fid/2)];
-			if (temp <= 0) break;
-			fid_temp = (temp-4) * 2;
+
+			/* look it up in the table */
+			printk(BIOS_DEBUG, "FidVid table step ");
+
+			temp = next_fid_200[((fid_new/2) * 13) + (fid_cur/2)];
+
+			if (temp > 0)
+				fid_temp = (temp-4) * 2; /* Table 108 */
+			else if (temp == 0)
+				fid_temp = fid_new;
+			else
+				break; /* table error */
+
+		} else { /* step < 2 (100MHZ) */
+			printk(BIOS_DEBUG, "100MHZ step ");
+
+			/* The table adjust in 200MHz increments. If requested,
+			 * do the 100MHz increment if the CPU supports it.*/
+			if (cpuid_edx(0x80000007) & (1 << 6)) {
+				fid_temp = fid_cur + 1;
+			} else {
+				/* 100 MHZ not supported. Get out of the loop */
+				printk(BIOS_DEBUG, "is not supported.\n");
+				break;
+			}
 		}
-		if (fid_temp > fid_max)
+
+		if (fid_temp > fid_max) {
+			printk(BIOS_DEBUG, "fid_temp 0x%x > fid_max 0x%x\n",
+				fid_temp, fid_max);
 			break;
+		}
 
-		fid_cur = fid_temp;
+		printk(BIOS_DEBUG, "fidvid: 0x%x\n", fid_temp);
 
 		/* set target fid */
-		msr.hi = (100000/5);
-		msr.lo = (vid_cur << 8) | fid_cur;
+		msr.hi = 0x190; /* 2 us for AMD NPT Family 0Fh Processors */
+		msr.lo = (vid_cur << 8) | fid_temp;
 #if SB_VFSMAF == 1
 		msr.lo |= (1 << 16); /* init changes */
 #endif
@@ -207,15 +280,25 @@
 
 #if K8_SET_FIDVID_DEBUG == 1
 		if (showmessage)	{
-			 printk(BIOS_DEBUG, "status msr fid, vid %08x:%08x\n", 
+			 printk(BIOS_DEBUG, "status msr fid, vid %08x:%08x\n",
 				msr.hi, msr.lo);
 		}
 #endif
 	}
 
 	/* set vid to final */
+	/* TODO - make this more correct. Not a big deal for setting max...
+	 * BKDG figure 11
+	 * if TargetFID > InitialFID
+	 *	TargetVID = FinalVID - RVO
+	 * else
+	 *	if CurrentVID > FinalVID
+	 *		TargetVID = FinalVID - RVO
+	 *	else
+	 *		TargetVID = CurrentVIDD - RVO
+	 */
 	msr.hi = 1;
-	msr.lo = (vid << 8) | (fid_cur);
+	msr.lo = (vid_new << 8) | (fid_cur);
 #if SB_VFSMAF == 1
 	msr.lo |= (1 << 16); // init changes
 #endif
@@ -234,10 +317,10 @@
 	fidvid = (vid_cur << 16) | (fid_cur << 8);
 
 	if (showmessage) {
-		if (vid!=vid_cur) {
+		if (vid_new != vid_cur) {
 			printk(BIOS_ERR, "set vid failed for apicid =%08x\n", apicidx);
 		}
-		if (fid!=fid_cur) {
+		if (fid_new != fid_cur) {
 			printk(BIOS_ERR, "set fid failed for apicid =%08x\n",apicidx);
 		}
 	}
@@ -276,7 +359,7 @@
 	vid_cur = msr.hi & 0x3f;
 	fid_cur = msr.lo & 0x3f;
 
-	/* set to current */ 
+	/* set to current */
 	msr.hi = 1;
 	msr.lo = (vid_cur << 8) | (fid_cur);
 	wrmsr(FIDVID_CTL, msr);
@@ -284,8 +367,8 @@
 
 	timeout = wait_cpu_state(bsp_apicid, 1);
 	if (timeout) {
-		printk(BIOS_ERR, 
-			"fidvid_ap_stage1: time out while reading from BSP on %08x\n", 
+		printk(BIOS_ERR,
+			"fidvid_ap_stage1: time out while reading from BSP on %08x\n",
 			apicid);
 	}
 	/* send signal to BSP about this AP max fid and vid */
@@ -311,10 +394,10 @@
 		/* send signal to BSP that this AP fid/vid is set */
 		/* allow to change state2 is together with apicid */
 		/* AP at state that We set the requested fid/vid */
-		send = (apicid<<24) | (readback & 0x00ffff00); 
+		send = (apicid << 24) | (readback & 0x00ffff00);
 	} else {
-		printk(BIOS_ERR, 
-			"fidvid_ap_stage2: time out while reading from BSP on %08x\n", 
+		printk(BIOS_ERR,
+			"fidvid_ap_stage2: time out while reading from BSP on %08x\n",
 			apicid);
 	}
 
@@ -322,15 +405,15 @@
 
 	timeout = wait_cpu_state(bsp_apicid, 3);
 	if (timeout) {
-		printk(BIOS_ERR, 
-			"fidvid_ap_stage3: time out while reading from BSP on %08x\n", 
+		printk(BIOS_ERR,
+			"fidvid_ap_stage3: time out while reading from BSP on %08x\n",
 			apicid);
 	}
 }
 
 static unsigned int calc_common_fidvid(unsigned int fidvid, unsigned int fidvidx)
 {
-	/* FIXME: need to check the change path to verify if it is reachable 
+	/* FIXME: need to check the change path to verify if it is reachable
 	 * when common fid is small than 1.6G */
 	if ((fidvid & 0xff00) <= (fidvidx & 0xff00)) {
 		return fidvid;
@@ -364,8 +447,8 @@
 		}
 	}
 	if (timeout) {
-		printk(BIOS_ERR, 
-			"fidvid_bsp_stage1: time out while reading from ap %08x\n", 
+		printk(BIOS_ERR,
+			"fidvid_bsp_stage1: time out while reading from ap %08x\n",
 			ap_apicid);
 		return;
 	}
@@ -401,8 +484,8 @@
 	}
 
 	if (timeout) {
-		printk(BIOS_ERR, 
-			"fidvid_bsp_stage2: time out while reading from ap %08x\n", 
+		printk(BIOS_ERR,
+			"fidvid_bsp_stage2: time out while reading from ap %08x\n",
 			ap_apicid);
 		return;
 	}
@@ -460,7 +543,7 @@
 	/* let all ap trains to state 1 */
 	lapic_write(LAPIC_MSG_REG,  (bsp_apicid << 24) | 1);
 
-	/* calculate the common max fid/vid that could be used for 
+	/* calculate the common max fid/vid that could be used for
 	 * all APs and BSP */
 #if K8_SET_FIDVID_STORE_AP_APICID_AT_FIRST == 1
 	ap_apicidx.num = 0;




From Marc.Jones at amd.com  Tue Nov  4 18:00:25 2008
From: Marc.Jones at amd.com (Marc Jones)
Date: Tue, 4 Nov 2008 10:00:25 -0700
Subject: [coreboot] [v3] [patch] k8 fid/vid update
In-Reply-To: <20081103235642.GA13674@greenwood>
References: <490F7B3C.1010308@amd.com> <490F7F07.5050603@amd.com>
	<20081103235642.GA13674@greenwood>
Message-ID: <49107FA9.5050907@amd.com>

Uwe Hermann wrote:
> On Mon, Nov 03, 2008 at 03:45:27PM -0700, Marc Jones wrote:
>> Update K8 FID/VID setupto match coreboot v2. Add support for 100MHz FIDs (revG).
>>
>> Signed-off-by: Marc Jones <marc.jones at amd.com>
> 
> Great, thanks!
> 
> Acked-by: Uwe Hermann <uwe at hermann-uwe.de>
> 
> Can't test much in v3 yet, but the patch looks good. Minor nitpicks
> below.
> 
> 
>> -		if (fid_temp > fid_max)
>> +
>> +		if(fid_temp > fid_max) {
>                   ^
>                 space
> 
>> +			printk(BIOS_DEBUG, "fid_temp 0x%x > fid_max 0x%x\n",
>> +				fid_temp, fid_max);
>>  			break;
>> +		}
> 
> 
>> -		send = (apicid<<24) | (readback & 0x00ffff00); 
>> +		send = (apicid<<24) | (readback & 0x00ffff00);
>                               ^ ^
>                              space
> 
> Uwe.

Nits fixed! :)

r979

Marc

-- 
Marc Jones
Senior Firmware Engineer
(970) 226-9684 Office
mailto:Marc.Jones at amd.com
http://www.amd.com/embeddedprocessors




From leroi.lists at gmail.com  Tue Nov  4 18:38:33 2008
From: leroi.lists at gmail.com (Roman Yeryomin)
Date: Tue, 4 Nov 2008 19:38:33 +0200
Subject: [coreboot]  and/or busybox issue with alix2c3 serial console
Message-ID: <200811041938.33674.leroi.lists@gmail.com>

I'm experimenting with coreboot (v3) on alix2c3 and still can't get serial 
console working. :( It stops right after kernel is done booting (I can see 
coreboot, filo and kernel messages just fine). I use openWRT but tried also 
another busybox based distribution (imedialinux) -- same problem. With 
original tinybios no problem. At the same time I tried voyage linux (without 
busybox) with corebooted alix and it has no such problem. It's obvious that 
this problem cannot be identified as 100% busybox's (why then it works on 
tinybios?).
While digging coreboot sources I've noticed that uart initialization is done 
twice for this board -- once in /southbridge/amd/cs5536/cs5536.c (based on 
dts config) and second time in /mainboard/pcengines/alix2c3/stage1.c.
I tried playing with these (and /southbridge/amd/cs5536/stage1.c), disabling 
one code or another, but no luck.
Tried to set MOD bits:

    msr.lo = (1 << 4) | (1 << 5) | (1 << 6);
    msr.hi = 0;
    wrmsr(MDD_UART1_MOD, msr);

Also no luck.
Not enabling upper banks, however, makes uart appear in kernel as regular 
16550A (and not as NS16550):

    /* Bit 1 = DEVEN (device enable)
     * Bit 4 = EN_BANKS (allow access to the upper banks)
     */
    //msr.lo = (1 << 4) | (1 << 1);
    msr.lo = 1 << 1;
    msr.hi = 0;

So... where should I go now?  I'm really stuck. Begging for help...


Regards,
Roman



From mylesgw at gmail.com  Tue Nov  4 18:51:11 2008
From: mylesgw at gmail.com (Myles Watson)
Date: Tue, 4 Nov 2008 10:51:11 -0700
Subject: [coreboot] and/or busybox issue with alix2c3 serial console
In-Reply-To: <200811041938.33674.leroi.lists@gmail.com>
References: <200811041938.33674.leroi.lists@gmail.com>
Message-ID: <F0B48C010E8340469B1F9167E7EA3086@chimp>



> -----Original Message-----
> From: coreboot-bounces at coreboot.org [mailto:coreboot-bounces at coreboot.org]
> On Behalf Of Roman Yeryomin
> Sent: Tuesday, November 04, 2008 10:39 AM
> To: coreboot at coreboot.org
> Subject: [coreboot] and/or busybox issue with alix2c3 serial console
> 
> I'm experimenting with coreboot (v3) on alix2c3 and still can't get serial
> console working. :( It stops right after kernel is done booting (I can see
> coreboot, filo and kernel messages just fine). I use openWRT but tried
> also
> another busybox based distribution (imedialinux) -- same problem. With
> original tinybios no problem. At the same time I tried voyage linux
> (without
> busybox) with corebooted alix and it has no such problem. It's obvious
> that
> this problem cannot be identified as 100% busybox's (why then it works on
> tinybios?).
> While digging coreboot sources I've noticed that uart initialization is
> done
> twice for this board -- once in /southbridge/amd/cs5536/cs5536.c (based on
> dts config) and second time in /mainboard/pcengines/alix2c3/stage1.c.
> I tried playing with these (and /southbridge/amd/cs5536/stage1.c),
> disabling
> one code or another, but no luck.
> Tried to set MOD bits:
> 
>     msr.lo = (1 << 4) | (1 << 5) | (1 << 6);
>     msr.hi = 0;
>     wrmsr(MDD_UART1_MOD, msr);
> 
> Also no luck.
> Not enabling upper banks, however, makes uart appear in kernel as regular
> 16550A (and not as NS16550):
> 
>     /* Bit 1 = DEVEN (device enable)
>      * Bit 4 = EN_BANKS (allow access to the upper banks)
>      */
>     //msr.lo = (1 << 4) | (1 << 1);
>     msr.lo = 1 << 1;
>     msr.hi = 0;
> 
> So... where should I go now?  I'm really stuck. Begging for help...

We've seen this before on s2892, SimNOW, and other platforms.  Has anyone
ever nailed this down?  I would say that it's definitely not busybox's
problem since you don't get any kernel output at all.  I didn't know where
to look either.

Thanks,
Myles




From rminnich at gmail.com  Tue Nov  4 19:36:42 2008
From: rminnich at gmail.com (ron minnich)
Date: Tue, 4 Nov 2008 10:36:42 -0800
Subject: [coreboot] and/or busybox issue with alix2c3 serial console
In-Reply-To: <F0B48C010E8340469B1F9167E7EA3086@chimp>
References: <200811041938.33674.leroi.lists@gmail.com>
	<F0B48C010E8340469B1F9167E7EA3086@chimp>
Message-ID: <13426df10811041036yde0bea0k5cab70ccb6bc0493@mail.gmail.com>

what's weird is that it has always worked for me.

Are you set up for serial console? Does serial console work fine on
factory bios?

Don't worry about "setup twice" -- that's not it.

I think some debug prints in the kernel are called for. /sbin/init is
going to try to open the console -- why not do some kernel debug
prints and see how that works out?

ron



From rminnich at gmail.com  Tue Nov  4 19:37:26 2008
From: rminnich at gmail.com (ron minnich)
Date: Tue, 4 Nov 2008 10:37:26 -0800
Subject: [coreboot] and/or busybox issue with alix2c3 serial console
In-Reply-To: <200811041938.33674.leroi.lists@gmail.com>
References: <200811041938.33674.leroi.lists@gmail.com>
Message-ID: <13426df10811041037u7b08e9dejd4d61b1a51f8572a@mail.gmail.com>

What do your kernel cmdlines look like?

ron



From peter at stuge.se  Tue Nov  4 19:38:56 2008
From: peter at stuge.se (Peter Stuge)
Date: Tue, 4 Nov 2008 19:38:56 +0100
Subject: [coreboot] Artec Group Dongle II cvs is up on opencores.org
In-Reply-To: <491073BC.7040507@artecdesign.ee>
References: <491073BC.7040507@artecdesign.ee>
Message-ID: <20081104183856.18058.qmail@stuge.se>

jyrit wrote:
> http://www.opencores.org/projects.cgi/web/artec_dongle_ii_fpga/overview

Not so impressed with the (lack of) hardware improvements. :\

The rotary encoder is a nice touch.

If you can find an archive of the milksop firmware maybe it has a bus
arbiter, I don't remember, but it did do very similar things.


//Peter



From Marc.Jones at amd.com  Tue Nov  4 19:43:03 2008
From: Marc.Jones at amd.com (Marc Jones)
Date: Tue, 4 Nov 2008 11:43:03 -0700
Subject: [coreboot] and/or busybox issue with alix2c3 serial console
In-Reply-To: <200811041938.33674.leroi.lists@gmail.com>
References: <200811041938.33674.leroi.lists@gmail.com>
Message-ID: <491097B7.4010901@amd.com>

Roman Yeryomin wrote:
> I'm experimenting with coreboot (v3) on alix2c3 and still can't get serial 
> console working. :( It stops right after kernel is done booting (I can see 
> coreboot, filo and kernel messages just fine). I

Is it just the console that stops? The kernel is still running and 
otherwise behaving normally?

Marc



-- 
Marc Jones
Senior Firmware Engineer
(970) 226-9684 Office
mailto:Marc.Jones at amd.com
http://www.amd.com/embeddedprocessors




From peter at stuge.se  Tue Nov  4 19:45:01 2008
From: peter at stuge.se (Peter Stuge)
Date: Tue, 4 Nov 2008 19:45:01 +0100
Subject: [coreboot] and/or busybox issue with alix2c3 serial console
In-Reply-To: <13426df10811041036yde0bea0k5cab70ccb6bc0493@mail.gmail.com>
References: <200811041938.33674.leroi.lists@gmail.com>
	<F0B48C010E8340469B1F9167E7EA3086@chimp>
	<13426df10811041036yde0bea0k5cab70ccb6bc0493@mail.gmail.com>
Message-ID: <20081104184501.20806.qmail@stuge.se>

ron minnich wrote:
> /sbin/init is going to try to open the console

Good point.

Is there a /dev/console node available in your filesystem at all
times, Roman?


//Peter



From leroi.lists at gmail.com  Tue Nov  4 19:47:13 2008
From: leroi.lists at gmail.com (Roman Yeryomin)
Date: Tue, 4 Nov 2008 20:47:13 +0200
Subject: [coreboot] and/or busybox issue with alix2c3 serial console
In-Reply-To: <491097B7.4010901@amd.com>
References: <200811041938.33674.leroi.lists@gmail.com>
	<491097B7.4010901@amd.com>
Message-ID: <ec3a010b0811041047sdef307cq2c0ab830d0a102e3@mail.gmail.com>

On Tue, Nov 4, 2008 at 8:43 PM, Marc Jones <Marc.Jones at amd.com> wrote:
> Roman Yeryomin wrote:
>>
>> I'm experimenting with coreboot (v3) on alix2c3 and still can't get serial
>> console working. :( It stops right after kernel is done booting (I can see
>> coreboot, filo and kernel messages just fine). I
>
> Is it just the console that stops? The kernel is still running and otherwise
> behaving normally?

exactly! only console is not working...
system is running fine (at least for few hours for sure)


Roman



From leroi.lists at gmail.com  Tue Nov  4 19:48:52 2008
From: leroi.lists at gmail.com (Roman Yeryomin)
Date: Tue, 4 Nov 2008 20:48:52 +0200
Subject: [coreboot] and/or busybox issue with alix2c3 serial console
In-Reply-To: <F0B48C010E8340469B1F9167E7EA3086@chimp>
References: <200811041938.33674.leroi.lists@gmail.com>
	<F0B48C010E8340469B1F9167E7EA3086@chimp>
Message-ID: <ec3a010b0811041048h398aad19j85f2a372f103c66f@mail.gmail.com>

On Tue, Nov 4, 2008 at 7:51 PM, Myles Watson <mylesgw at gmail.com> wrote:
> We've seen this before on s2892, SimNOW, and other platforms.  Has anyone
> ever nailed this down?  I would say that it's definitely not busybox's
> problem since you don't get any kernel output at all.  I didn't know where
> to look either.

you are wrong -- I can see all kernel messages


Roman



From leroi.lists at gmail.com  Tue Nov  4 19:54:05 2008
From: leroi.lists at gmail.com (Roman Yeryomin)
Date: Tue, 4 Nov 2008 20:54:05 +0200
Subject: [coreboot] and/or busybox issue with alix2c3 serial console
In-Reply-To: <ec3a010b0811041053w1dc09253mc1cf4baf089b20df@mail.gmail.com>
References: <200811041938.33674.leroi.lists@gmail.com>
	<F0B48C010E8340469B1F9167E7EA3086@chimp>
	<13426df10811041036yde0bea0k5cab70ccb6bc0493@mail.gmail.com>
	<ec3a010b0811041053w1dc09253mc1cf4baf089b20df@mail.gmail.com>
Message-ID: <ec3a010b0811041054u6ecac223xc1456cb07953d804@mail.gmail.com>

On Tue, Nov 4, 2008 at 8:36 PM, ron minnich <rminnich at gmail.com> wrote:
> what's weird is that it has always worked for me.
>
> Are you set up for serial console? Does serial console work fine on
> factory bios?

 Well, I've mentioned that it work with tinybios (it is factory bios
 for alix boards)

> Don't worry about "setup twice" -- that's not it.

 I think so, just a notice...

> I think some debug prints in the kernel are called for. /sbin/init is
> going to try to open the console -- why not do some kernel debug
> prints and see how that works out?

 kernel debug prints where? console driver?


 Roman



From rminnich at gmail.com  Tue Nov  4 19:55:01 2008
From: rminnich at gmail.com (ron minnich)
Date: Tue, 4 Nov 2008 10:55:01 -0800
Subject: [coreboot] and/or busybox issue with alix2c3 serial console
In-Reply-To: <ec3a010b0811041048h398aad19j85f2a372f103c66f@mail.gmail.com>
References: <200811041938.33674.leroi.lists@gmail.com>
	<F0B48C010E8340469B1F9167E7EA3086@chimp>
	<ec3a010b0811041048h398aad19j85f2a372f103c66f@mail.gmail.com>
Message-ID: <13426df10811041055p282469a7r5f8283ca734130e0@mail.gmail.com>

what's usually going on here is that /sbin/init starts and tries (and
fails) to open a console. IIRC there are some hardware checks in the
ttyS0 code that look for bits set "correctly" in the hardware. Another
typical problem is interrupt setup -- there may not be any interrupts.

can you ssh in to the box when it is up? There are lots of simple
tests to try if so.

ron



From leroi.lists at gmail.com  Tue Nov  4 19:57:01 2008
From: leroi.lists at gmail.com (Roman Yeryomin)
Date: Tue, 4 Nov 2008 20:57:01 +0200
Subject: [coreboot] and/or busybox issue with alix2c3 serial console
In-Reply-To: <13426df10811041037u7b08e9dejd4d61b1a51f8572a@mail.gmail.com>
References: <200811041938.33674.leroi.lists@gmail.com>
	<13426df10811041037u7b08e9dejd4d61b1a51f8572a@mail.gmail.com>
Message-ID: <ec3a010b0811041057x2e5ea5a1l50016e847c1a66d1@mail.gmail.com>

On Tue, Nov 4, 2008 at 8:37 PM, ron minnich <rminnich at gmail.com> wrote:
> What do your kernel cmdlines look like?

does it matter? I think if I can see kernal messages it's already ok...
anyway it is:

block2mtd.block2mtd=/dev/hda2,131072,rootfs root=/dev/mtdblock0
rootfstype=jffs2 init=/etc/preinit noinitrd console=ttyS0,38400n8


Roman



From rminnich at gmail.com  Tue Nov  4 19:58:28 2008
From: rminnich at gmail.com (ron minnich)
Date: Tue, 4 Nov 2008 10:58:28 -0800
Subject: [coreboot] and/or busybox issue with alix2c3 serial console
In-Reply-To: <ec3a010b0811041057x2e5ea5a1l50016e847c1a66d1@mail.gmail.com>
References: <200811041938.33674.leroi.lists@gmail.com>
	<13426df10811041037u7b08e9dejd4d61b1a51f8572a@mail.gmail.com>
	<ec3a010b0811041057x2e5ea5a1l50016e847c1a66d1@mail.gmail.com>
Message-ID: <13426df10811041058m7de6cb1vf487cd458146a2ad@mail.gmail.com>

On Tue, Nov 4, 2008 at 10:57 AM, Roman Yeryomin <leroi.lists at gmail.com> wrote:
> On Tue, Nov 4, 2008 at 8:37 PM, ron minnich <rminnich at gmail.com> wrote:
>> What do your kernel cmdlines look like?
>
> does it matter? I think if I can see kernal messages it's already ok...

it's not. but:


> block2mtd.block2mtd=/dev/hda2,131072,rootfs root=/dev/mtdblock0
> rootfstype=jffs2 init=/etc/preinit noinitrd console=ttyS0,38400n8
>

so it is something else.

ron



From leroi.lists at gmail.com  Tue Nov  4 19:59:27 2008
From: leroi.lists at gmail.com (Roman Yeryomin)
Date: Tue, 4 Nov 2008 20:59:27 +0200
Subject: [coreboot] and/or busybox issue with alix2c3 serial console
In-Reply-To: <20081104184501.20806.qmail@stuge.se>
References: <200811041938.33674.leroi.lists@gmail.com>
	<F0B48C010E8340469B1F9167E7EA3086@chimp>
	<13426df10811041036yde0bea0k5cab70ccb6bc0493@mail.gmail.com>
	<20081104184501.20806.qmail@stuge.se>
Message-ID: <ec3a010b0811041059l1331410aq3bac223046cdfe74@mail.gmail.com>

On Tue, Nov 4, 2008 at 8:45 PM, Peter Stuge <peter at stuge.se> wrote:
> ron minnich wrote:
>> /sbin/init is going to try to open the console
>
> Good point.
>
> Is there a /dev/console node available in your filesystem at all
> times, Roman?

yep

ls -la /dev/console
crw-r--r--    1 root     root       5,   1 Jan  1  2000 /dev/console


Roman



From rminnich at gmail.com  Tue Nov  4 19:59:25 2008
From: rminnich at gmail.com (ron minnich)
Date: Tue, 4 Nov 2008 10:59:25 -0800
Subject: [coreboot] and/or busybox issue with alix2c3 serial console
In-Reply-To: <ec3a010b0811041057x2e5ea5a1l50016e847c1a66d1@mail.gmail.com>
References: <200811041938.33674.leroi.lists@gmail.com>
	<13426df10811041037u7b08e9dejd4d61b1a51f8572a@mail.gmail.com>
	<ec3a010b0811041057x2e5ea5a1l50016e847c1a66d1@mail.gmail.com>
Message-ID: <13426df10811041059u6b0957fcm9dee471c8fdf4838@mail.gmail.com>

On Tue, Nov 4, 2008 at 10:57 AM, Roman Yeryomin <leroi.lists at gmail.com> wrote:
> On Tue, Nov 4, 2008 at 8:37 PM, ron minnich <rminnich at gmail.com> wrote:
>> What do your kernel cmdlines look like?
>
> does it matter? I think if I can see kernal messages it's already ok...

This is a pretty common thing to believe, but it is only a lucky case :-)

lots can go wrong such that you can see kernel messages but get no console.

ron



From peter at stuge.se  Tue Nov  4 20:03:27 2008
From: peter at stuge.se (Peter Stuge)
Date: Tue, 4 Nov 2008 20:03:27 +0100
Subject: [coreboot] and/or busybox issue with alix2c3 serial console
In-Reply-To: <ec3a010b0811041059l1331410aq3bac223046cdfe74@mail.gmail.com>
References: <200811041938.33674.leroi.lists@gmail.com>
	<F0B48C010E8340469B1F9167E7EA3086@chimp>
	<13426df10811041036yde0bea0k5cab70ccb6bc0493@mail.gmail.com>
	<20081104184501.20806.qmail@stuge.se>
	<ec3a010b0811041059l1331410aq3bac223046cdfe74@mail.gmail.com>
Message-ID: <20081104190327.27033.qmail@stuge.se>

Roman Yeryomin wrote:
> > Is there a /dev/console node available in your filesystem at all
> > times, Roman?
> 
> yep
> 
> ls -la /dev/console
> crw-r--r--    1 root     root       5,   1 Jan  1  2000 /dev/console

Unfortunately one simple test is not enough. When you ran this
command many things have happened in /dev compared to when init is
starting.

Could you replace init with something else (maybe sh) and check if
/dev/console exists also then?


//Peter



From leroi.lists at gmail.com  Tue Nov  4 20:03:39 2008
From: leroi.lists at gmail.com (Roman Yeryomin)
Date: Tue, 4 Nov 2008 21:03:39 +0200
Subject: [coreboot] and/or busybox issue with alix2c3 serial console
In-Reply-To: <13426df10811041055p282469a7r5f8283ca734130e0@mail.gmail.com>
References: <200811041938.33674.leroi.lists@gmail.com>
	<F0B48C010E8340469B1F9167E7EA3086@chimp>
	<ec3a010b0811041048h398aad19j85f2a372f103c66f@mail.gmail.com>
	<13426df10811041055p282469a7r5f8283ca734130e0@mail.gmail.com>
Message-ID: <ec3a010b0811041103r74dc88c9x2bb1e33c052d8956@mail.gmail.com>

On Tue, Nov 4, 2008 at 8:55 PM, ron minnich <rminnich at gmail.com> wrote:
> what's usually going on here is that /sbin/init starts and tries (and
> fails) to open a console. IIRC there are some hardware checks in the
> ttyS0 code that look for bits set "correctly" in the hardware. Another
> typical problem is interrupt setup -- there may not be any interrupts.
>
> can you ssh in to the box when it is up? There are lots of simple
> tests to try if so.

yes, I can
what do I do?


Roman



From rminnich at gmail.com  Tue Nov  4 20:04:36 2008
From: rminnich at gmail.com (ron minnich)
Date: Tue, 4 Nov 2008 11:04:36 -0800
Subject: [coreboot] and/or busybox issue with alix2c3 serial console
In-Reply-To: <ec3a010b0811041059l1331410aq3bac223046cdfe74@mail.gmail.com>
References: <200811041938.33674.leroi.lists@gmail.com>
	<F0B48C010E8340469B1F9167E7EA3086@chimp>
	<13426df10811041036yde0bea0k5cab70ccb6bc0493@mail.gmail.com>
	<20081104184501.20806.qmail@stuge.se>
	<ec3a010b0811041059l1331410aq3bac223046cdfe74@mail.gmail.com>
Message-ID: <13426df10811041104h269709b3g54337407c05f7d92@mail.gmail.com>

On Tue, Nov 4, 2008 at 10:59 AM, Roman Yeryomin <leroi.lists at gmail.com> wrote:
> On Tue, Nov 4, 2008 at 8:45 PM, Peter Stuge <peter at stuge.se> wrote:
>> ron minnich wrote:
>>> /sbin/init is going to try to open the console
>>
>> Good point.
>>
>> Is there a /dev/console node available in your filesystem at all
>> times, Roman?
>
> yep
>
> ls -la /dev/console
> crw-r--r--    1 root     root       5,   1 Jan  1  2000 /dev/console
>
so you are in via ssh?

What does:
cat /proc/devices
and
cat /proc/interrupts show

If you do this
echo HITHERE > /dev/ttyS0
does it appear on console? If you type on console, what does
/proc/interrupts show?

ron



From Marc.Jones at amd.com  Tue Nov  4 20:07:13 2008
From: Marc.Jones at amd.com (Marc Jones)
Date: Tue, 4 Nov 2008 12:07:13 -0700
Subject: [coreboot] and/or busybox issue with alix2c3 serial console
In-Reply-To: <13426df10811041058m7de6cb1vf487cd458146a2ad@mail.gmail.com>
References: <200811041938.33674.leroi.lists@gmail.com>	<13426df10811041037u7b08e9dejd4d61b1a51f8572a@mail.gmail.com>	<ec3a010b0811041057x2e5ea5a1l50016e847c1a66d1@mail.gmail.com>
	<13426df10811041058m7de6cb1vf487cd458146a2ad@mail.gmail.com>
Message-ID: <49109D61.6070207@amd.com>

ron minnich wrote:
> On Tue, Nov 4, 2008 at 10:57 AM, Roman Yeryomin <leroi.lists at gmail.com> wrote:
>> On Tue, Nov 4, 2008 at 8:37 PM, ron minnich <rminnich at gmail.com> wrote:
>>> What do your kernel cmdlines look like?
>> does it matter? I think if I can see kernal messages it's already ok...
> 
> it's not. but:
> 
> 
>> block2mtd.block2mtd=/dev/hda2,131072,rootfs root=/dev/mtdblock0
>> rootfstype=jffs2 init=/etc/preinit noinitrd console=ttyS0,38400n8
>>
> 

Silly question but are you setting two different serial rates?

kernel:
console=ttyS0,38400n8

coreboot default:
CONFIG_CONSOLE_SERIAL_115200=y


Marc

-- 
Marc Jones
Senior Firmware Engineer
(970) 226-9684 Office
mailto:Marc.Jones at amd.com
http://www.amd.com/embeddedprocessors




From rminnich at gmail.com  Tue Nov  4 20:07:40 2008
From: rminnich at gmail.com (ron minnich)
Date: Tue, 4 Nov 2008 11:07:40 -0800
Subject: [coreboot] and/or busybox issue with alix2c3 serial console
In-Reply-To: <ec3a010b0811041057x2e5ea5a1l50016e847c1a66d1@mail.gmail.com>
References: <200811041938.33674.leroi.lists@gmail.com>
	<13426df10811041037u7b08e9dejd4d61b1a51f8572a@mail.gmail.com>
	<ec3a010b0811041057x2e5ea5a1l50016e847c1a66d1@mail.gmail.com>
Message-ID: <13426df10811041107u437f9941u57f869d635d4e62a@mail.gmail.com>

On Tue, Nov 4, 2008 at 10:57 AM, Roman Yeryomin <leroi.lists at gmail.com> wrote:

> block2mtd.block2mtd=/dev/hda2,131072,rootfs root=/dev/mtdblock0
> rootfstype=jffs2 init=/etc/preinit noinitrd console=ttyS0,38400n8
>


to "replace" init, do this:
init=/bin/bash

or similar on the cmdline

ron



From rminnich at gmail.com  Tue Nov  4 20:10:08 2008
From: rminnich at gmail.com (ron minnich)
Date: Tue, 4 Nov 2008 11:10:08 -0800
Subject: [coreboot] and/or busybox issue with alix2c3 serial console
In-Reply-To: <49109D61.6070207@amd.com>
References: <200811041938.33674.leroi.lists@gmail.com>
	<13426df10811041037u7b08e9dejd4d61b1a51f8572a@mail.gmail.com>
	<ec3a010b0811041057x2e5ea5a1l50016e847c1a66d1@mail.gmail.com>
	<13426df10811041058m7de6cb1vf487cd458146a2ad@mail.gmail.com>
	<49109D61.6070207@amd.com>
Message-ID: <13426df10811041110n4ff50cc6t167a1791e0d020da@mail.gmail.com>

On Tue, Nov 4, 2008 at 11:07 AM, Marc Jones <Marc.Jones at amd.com> wrote:
>
> Silly question but are you setting two different serial rates?
>
> kernel:
> console=ttyS0,38400n8
>
> coreboot default:
> CONFIG_CONSOLE_SERIAL_115200=y


well there's a gotcha.

ron



From leroi.lists at gmail.com  Tue Nov  4 20:11:31 2008
From: leroi.lists at gmail.com (Roman Yeryomin)
Date: Tue, 4 Nov 2008 21:11:31 +0200
Subject: [coreboot] and/or busybox issue with alix2c3 serial console
In-Reply-To: <49109D61.6070207@amd.com>
References: <200811041938.33674.leroi.lists@gmail.com>
	<13426df10811041037u7b08e9dejd4d61b1a51f8572a@mail.gmail.com>
	<ec3a010b0811041057x2e5ea5a1l50016e847c1a66d1@mail.gmail.com>
	<13426df10811041058m7de6cb1vf487cd458146a2ad@mail.gmail.com>
	<49109D61.6070207@amd.com>
Message-ID: <ec3a010b0811041111n7c1c28c5pa858b8935fd2cff5@mail.gmail.com>

On Tue, Nov 4, 2008 at 9:07 PM, Marc Jones <Marc.Jones at amd.com> wrote:
> Silly question but are you setting two different serial rates?
>
> kernel:
> console=ttyS0,38400n8
>
> coreboot default:
> CONFIG_CONSOLE_SERIAL_115200=y

:) no



From leroi.lists at gmail.com  Tue Nov  4 20:24:09 2008
From: leroi.lists at gmail.com (Roman Yeryomin)
Date: Tue, 4 Nov 2008 21:24:09 +0200
Subject: [coreboot] and/or busybox issue with alix2c3 serial console
In-Reply-To: <13426df10811041104h269709b3g54337407c05f7d92@mail.gmail.com>
References: <200811041938.33674.leroi.lists@gmail.com>
	<F0B48C010E8340469B1F9167E7EA3086@chimp>
	<13426df10811041036yde0bea0k5cab70ccb6bc0493@mail.gmail.com>
	<20081104184501.20806.qmail@stuge.se>
	<ec3a010b0811041059l1331410aq3bac223046cdfe74@mail.gmail.com>
	<13426df10811041104h269709b3g54337407c05f7d92@mail.gmail.com>
Message-ID: <ec3a010b0811041124w36215691ib93bd03f0685f245@mail.gmail.com>

On Tue, Nov 4, 2008 at 9:04 PM, ron minnich <rminnich at gmail.com> wrote:
> On Tue, Nov 4, 2008 at 10:59 AM, Roman Yeryomin <leroi.lists at gmail.com> wrote:
>> On Tue, Nov 4, 2008 at 8:45 PM, Peter Stuge <peter at stuge.se> wrote:
>>> ron minnich wrote:
>>>> /sbin/init is going to try to open the console
>>>
>>> Good point.
>>>
>>> Is there a /dev/console node available in your filesystem at all
>>> times, Roman?
>>
>> yep
>>
>> ls -la /dev/console
>> crw-r--r--    1 root     root       5,   1 Jan  1  2000 /dev/console
>>
> cat /proc/devices

Character devices:
  1 mem
  4 /dev/vc/0
  4 tty
  4 ttyS
  5 /dev/tty
  5 /dev/console
  5 /dev/ptmx
  7 vcs
 10 misc
 13 input
 90 mtd
108 ppp
128 ptm
136 pts

Block devices:
  3 ide0
 31 mtdblock

> cat /proc/interrupts show

           CPU0
  0:    2594034    XT-PIC-XT        timer
  2:          0    XT-PIC-XT        cascade
  4:          0    XT-PIC-XT        serial
  8:          0    XT-PIC-XT        rtc
 10:      23113    XT-PIC-XT        eth0
 11:          5    XT-PIC-XT        eth1, eth2
 14:      20579    XT-PIC-XT        ide0
NMI:          0   Non-maskable interrupts
LOC:          0   Local timer interrupts
RES:          0   Rescheduling interrupts
CAL:          0   function call interrupts
TLB:          0   TLB shootdowns
TRM:          0   Thermal event interrupts
SPU:          0   Spurious interrupts
ERR:          0
MIS:          0

> If you do this
> echo HITHERE > /dev/ttyS0

nothing
it does work with tinybios
also cat /proc/tty/driver/serial indicates that there is no tx/rx:
serinfo:1.0 driver revision:
0: uart:16550A port:000003F8 irq:4 tx:0 rx:0 RTS|CTS|DTR|DSR|CD
1: uart:unknown port:000002F8 irq:3

> does it appear on console? If you type on console, what does
> /proc/interrupts show?

serial interrupt counter doesn't change if you are talking about that


Roman



From jyrit at artecdesign.ee  Tue Nov  4 20:27:37 2008
From: jyrit at artecdesign.ee (jyrit)
Date: Tue, 4 Nov 2008 19:27:37 +0000 (UTC)
Subject: [coreboot] Artec Group Dongle II cvs is up on opencores.org
References: <491073BC.7040507@artecdesign.ee>
	<20081104183856.18058.qmail@stuge.se>
Message-ID: <loom.20081104T190638-132@post.gmane.org>

Peter Stuge <peter <at> stuge.se> writes:
> Not so impressed with the (lack of) hardware improvements. :\

There is actually lot of thought put in into the hardware to
get all the requested features with small changes.
The write time of 4 MByte image to added PSRAM is now 4 sec. (using the same
FTDI chip this prob. can be reduced to about 2 sec. with VHDL tweaks). 
The "BitBang" mode of the FTDI chip makes it possible to update the firmware
without any need for ByteBlaster cable.
There is UltraCap so that the PSRAM retains it's image up to 2 hours. :)

There is automatic power switch now.
There is EPROM to make it possible to remove the physical jumpers.
There are SMD leds

Cyclone III has faster up time than Cyclone I but it still might not be fast
enough. On the other hand there is the existing updater code that can be
reused and Cyclone III is cheaper than Actel FPGA's and there are other
reasons why we went with Cyclone III.

That's all that was on the Santa's list for Peter :D


All the best,
Santa





From jordan at chalmers.se  Tue Nov  4 20:48:58 2008
From: jordan at chalmers.se (Ulf Jordan)
Date: Tue, 4 Nov 2008 20:48:58 +0100 (CET)
Subject: [coreboot] [PATCH 1/2] bayou: use ACS for line drawing
In-Reply-To: <Pine.LNX.4.63.0808162246090.12076@elfpc10.elmagn.chalmers.se>
References: <Pine.LNX.4.63.0808162246090.12076@elfpc10.elmagn.chalmers.se>
Message-ID: <Pine.LNX.4.63.0811042044180.20244@elfpc10.elmagn.chalmers.se>

On Sat, 16 Aug 2008, Ulf Jordan wrote:

> Hello!
>
> Attached is a patch to update Bayou v0.3 to use ACS_ macros for the line 
> drawing characters in the menu window border.
>
> Build and run tested under QEMU with bayou-0.3+coreboot-v3.

Here's the patch rediffed against bayou in svn.

/ulf
-------------- next part --------------
Update bayou to use ACS_ macros for line drawing characters.

Signed-off-by: Ulf Jordan <jordan at chalmers.se>

Index: bayou/menu.c
===================================================================
--- bayou/menu.c	(revision 3730)
+++ bayou/menu.c	(arbetskopia)
@@ -67,8 +67,8 @@
 
 	wattrset(menuwin, COLOR_PAIR(3));
 	wclear(menuwin);
-	wborder(menuwin, '\263', '\263', '\304', '\304', '\332',
-		'\277', '\300', '\331');
+	wborder(menuwin, ACS_VLINE, ACS_VLINE, ACS_HLINE, ACS_HLINE,
+		ACS_ULCORNER, ACS_URCORNER, ACS_LLCORNER, ACS_LRCORNER);
 
 	wattrset(menuwin, COLOR_PAIR(4) | A_BOLD);
 	mvwprintw(menuwin, 0, (menu_width - 17) / 2, " Payload Chooser ");

From jordan at chalmers.se  Tue Nov  4 20:51:11 2008
From: jordan at chalmers.se (Ulf Jordan)
Date: Tue, 4 Nov 2008 20:51:11 +0100 (CET)
Subject: [coreboot] [PATCH 2/2] bayou: adjust color pairs
In-Reply-To: <Pine.LNX.4.63.0808162302460.12076@elfpc10.elmagn.chalmers.se>
References: <Pine.LNX.4.63.0808162302460.12076@elfpc10.elmagn.chalmers.se>
Message-ID: <Pine.LNX.4.63.0811042049300.20265@elfpc10.elmagn.chalmers.se>

On Sat, 16 Aug 2008, Ulf Jordan wrote:

> Hello!
>
> Atttached is a patch that will restore blue background and bright yellow
> menu title in Bayou v0.3, after (if) the tinycurses VGA color correction
> patch is applied (see an earlier thread started today).
>
> Build and run tested under QEMU with bayou-0.3+coreboot-v3.

Patch rediffed against bayou in svn.

/ulf
-------------- next part --------------
Adjust color pair initialization to give a blue background screen and
bright yellow heading text,  after correction of tinycurses VGA color
handling code.

Signed-off-by: Ulf Jordan <jordan at chalmers.se>

Index: bayou/menu.c
===================================================================
--- bayou/menu.c	(revision 3730)
+++ bayou/menu.c	(arbetskopia)
@@ -133,11 +133,11 @@
 {
 	initscr();
 
-	init_pair(1, COLOR_WHITE, COLOR_RED);
+	init_pair(1, COLOR_WHITE, COLOR_BLUE);
 	init_pair(2, COLOR_BLACK, COLOR_WHITE);
 	init_pair(3, COLOR_BLACK, COLOR_WHITE);
-	init_pair(4, COLOR_CYAN, COLOR_WHITE);
-	init_pair(5, COLOR_WHITE, COLOR_RED);
+	init_pair(4, COLOR_YELLOW, COLOR_WHITE);
+	init_pair(5, COLOR_WHITE, COLOR_BLUE);
 
 	wattrset(stdscr, COLOR_PAIR(1));
 	wclear(stdscr);

From rminnich at gmail.com  Tue Nov  4 21:00:51 2008
From: rminnich at gmail.com (ron minnich)
Date: Tue, 4 Nov 2008 12:00:51 -0800
Subject: [coreboot] and/or busybox issue with alix2c3 serial console
In-Reply-To: <ec3a010b0811041124w36215691ib93bd03f0685f245@mail.gmail.com>
References: <200811041938.33674.leroi.lists@gmail.com>
	<F0B48C010E8340469B1F9167E7EA3086@chimp>
	<13426df10811041036yde0bea0k5cab70ccb6bc0493@mail.gmail.com>
	<20081104184501.20806.qmail@stuge.se>
	<ec3a010b0811041059l1331410aq3bac223046cdfe74@mail.gmail.com>
	<13426df10811041104h269709b3g54337407c05f7d92@mail.gmail.com>
	<ec3a010b0811041124w36215691ib93bd03f0685f245@mail.gmail.com>
Message-ID: <13426df10811041200p6980a18etfe1b0e7e49add07b@mail.gmail.com>

we've got another geode interrupt problem.

I figured that might be it.

WHat does dmesg say about the tty parts?

ron



From mylesgw at gmail.com  Tue Nov  4 21:04:21 2008
From: mylesgw at gmail.com (Myles Watson)
Date: Tue, 4 Nov 2008 14:04:21 -0600
Subject: [coreboot] pci_device.c cleanup
Message-ID: <2831fecf0811041204u59f2ccc9h5cb18f5e96c5fb@mail.gmail.com>

This patch clarifies/adds comments and changes names in device/pci_device.c

It also changes %p debug statements in various places.  I think they get in
the way of diffs when you have log files to compare.  I don't want to see
the
allocation differences most of the time.  I turned most of them into NULL
checks.  If they were supposed to be "Where are we in device allocation?"
checks, we could make them into that too.

It's a work-in-progress. Comments welcome.

I think most of the changes are self explanatory, but this one might not be:

If you are reading all the BARs from a device, and you come to a 64-bit BAR.
No matter why you skip it, you should skip it as a 64-bit BAR, and not try
to
read the upper half as the next 32-bit BAR.

Because of that, set the 64-bit flag IORESOURCE_PCI64 early, and don't clear
it on return.

Signed-off-by: Myles Watson <mylesgw at gmail.com>

Thanks,
Myles
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20081104/efe1ccd1/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: pci_device_cleanup.diff
Type: text/x-patch
Size: 14462 bytes
Desc: not available
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20081104/efe1ccd1/attachment.diff>

From leroi.lists at gmail.com  Tue Nov  4 21:07:17 2008
From: leroi.lists at gmail.com (Roman Yeryomin)
Date: Tue, 4 Nov 2008 22:07:17 +0200
Subject: [coreboot] and/or busybox issue with alix2c3 serial console
In-Reply-To: <13426df10811041200p6980a18etfe1b0e7e49add07b@mail.gmail.com>
References: <200811041938.33674.leroi.lists@gmail.com>
	<F0B48C010E8340469B1F9167E7EA3086@chimp>
	<13426df10811041036yde0bea0k5cab70ccb6bc0493@mail.gmail.com>
	<20081104184501.20806.qmail@stuge.se>
	<ec3a010b0811041059l1331410aq3bac223046cdfe74@mail.gmail.com>
	<13426df10811041104h269709b3g54337407c05f7d92@mail.gmail.com>
	<ec3a010b0811041124w36215691ib93bd03f0685f245@mail.gmail.com>
	<13426df10811041200p6980a18etfe1b0e7e49add07b@mail.gmail.com>
Message-ID: <ec3a010b0811041207p7ffc7a4eub46c9cbce5a6c9b3@mail.gmail.com>

On Tue, Nov 4, 2008 at 10:00 PM, ron minnich <rminnich at gmail.com> wrote:
> we've got another geode interrupt problem.
>
> I figured that might be it.
>
> WHat does dmesg say about the tty parts?

dmesg | grep tty
Kernel command line: block2mtd.block2mtd=/dev/hda2,131072,rootfs
root=/dev/mtdblock0 rootfstype=jffs2 init=/etc/preinit noinitrd
console=ttyS0,38400n8
console [ttyS0] enabled
serial8250: ttyS0 at I/O 0x3f8 (irq = 4) is a 16550A

this is with MOD bits set and upper banks disabled (the same is true
for all my previous messages also)


Roman



From mylesgw at gmail.com  Tue Nov  4 21:08:35 2008
From: mylesgw at gmail.com (Myles Watson)
Date: Tue, 4 Nov 2008 13:08:35 -0700
Subject: [coreboot] and/or busybox issue with alix2c3 serial console
In-Reply-To: <ec3a010b0811041048h398aad19j85f2a372f103c66f@mail.gmail.com>
References: <200811041938.33674.leroi.lists@gmail.com>
	<F0B48C010E8340469B1F9167E7EA3086@chimp>
	<ec3a010b0811041048h398aad19j85f2a372f103c66f@mail.gmail.com>
Message-ID: <8CAA62EBB941476CA5313F51D26E7E45@chimp>



> -----Original Message-----
> From: Roman Yeryomin [mailto:leroi.lists at gmail.com]
> Sent: Tuesday, November 04, 2008 11:49 AM
> To: Myles Watson; coreboot at coreboot.org
> Subject: Re: [coreboot] and/or busybox issue with alix2c3 serial console
> 
> On Tue, Nov 4, 2008 at 7:51 PM, Myles Watson <mylesgw at gmail.com> wrote:
> > We've seen this before on s2892, SimNOW, and other platforms.  Has
> anyone
> > ever nailed this down?  I would say that it's definitely not busybox's
> > problem since you don't get any kernel output at all.  I didn't know
> where
> > to look either.
> 
> you are wrong -- I can see all kernel messages

Sorry I misunderstood you.  I have seen a different problem.

Thanks,
Myles





From rminnich at gmail.com  Tue Nov  4 21:12:32 2008
From: rminnich at gmail.com (ron minnich)
Date: Tue, 4 Nov 2008 12:12:32 -0800
Subject: [coreboot] and/or busybox issue with alix2c3 serial console
In-Reply-To: <ec3a010b0811041207p7ffc7a4eub46c9cbce5a6c9b3@mail.gmail.com>
References: <200811041938.33674.leroi.lists@gmail.com>
	<F0B48C010E8340469B1F9167E7EA3086@chimp>
	<13426df10811041036yde0bea0k5cab70ccb6bc0493@mail.gmail.com>
	<20081104184501.20806.qmail@stuge.se>
	<ec3a010b0811041059l1331410aq3bac223046cdfe74@mail.gmail.com>
	<13426df10811041104h269709b3g54337407c05f7d92@mail.gmail.com>
	<ec3a010b0811041124w36215691ib93bd03f0685f245@mail.gmail.com>
	<13426df10811041200p6980a18etfe1b0e7e49add07b@mail.gmail.com>
	<ec3a010b0811041207p7ffc7a4eub46c9cbce5a6c9b3@mail.gmail.com>
Message-ID: <13426df10811041212i7cf2f498p4dda7851a98ff03f@mail.gmail.com>

On Tue, Nov 4, 2008 at 12:07 PM, Roman Yeryomin <leroi.lists at gmail.com> wrote:

> this is with MOD bits set and upper banks disabled (the same is true
> for all my previous messages also)
>

I'm pretty sure that MOD and banks won't matter. I think what is going
on is that we have a non-connected interrupt problem.

Marc? What do we do now?

ron



From rminnich at gmail.com  Tue Nov  4 21:17:11 2008
From: rminnich at gmail.com (ron minnich)
Date: Tue, 4 Nov 2008 12:17:11 -0800
Subject: [coreboot] pci_device.c cleanup
In-Reply-To: <2831fecf0811041204u59f2ccc9h5cb18f5e96c5fb@mail.gmail.com>
References: <2831fecf0811041204u59f2ccc9h5cb18f5e96c5fb@mail.gmail.com>
Message-ID: <13426df10811041217t5b86444fxef4b9d66ecf74646@mail.gmail.com>

I can not test this week.

Acked-by: Ronald G. Minnich <rminnich at gmail.com>



From Marc.Jones at amd.com  Tue Nov  4 21:31:36 2008
From: Marc.Jones at amd.com (Marc Jones)
Date: Tue, 4 Nov 2008 13:31:36 -0700
Subject: [coreboot] and/or busybox issue with alix2c3 serial console
In-Reply-To: <13426df10811041212i7cf2f498p4dda7851a98ff03f@mail.gmail.com>
References: <200811041938.33674.leroi.lists@gmail.com>	<F0B48C010E8340469B1F9167E7EA3086@chimp>	<13426df10811041036yde0bea0k5cab70ccb6bc0493@mail.gmail.com>	<20081104184501.20806.qmail@stuge.se>	<ec3a010b0811041059l1331410aq3bac223046cdfe74@mail.gmail.com>	<13426df10811041104h269709b3g54337407c05f7d92@mail.gmail.com>	<ec3a010b0811041124w36215691ib93bd03f0685f245@mail.gmail.com>	<13426df10811041200p6980a18etfe1b0e7e49add07b@mail.gmail.com>	<ec3a010b0811041207p7ffc7a4eub46c9cbce5a6c9b3@mail.gmail.com>
	<13426df10811041212i7cf2f498p4dda7851a98ff03f@mail.gmail.com>
Message-ID: <4910B128.7050903@amd.com>

ron minnich wrote:
> On Tue, Nov 4, 2008 at 12:07 PM, Roman Yeryomin <leroi.lists at gmail.com> wrote:
> 
>> this is with MOD bits set and upper banks disabled (the same is true
>> for all my previous messages also)
>>
> 
> I'm pretty sure that MOD and banks won't matter. I think what is going
> on is that we have a non-connected interrupt problem.
> 
> Marc? What do we do now?
>

I am not so sure. The interrupt is setup right or not and it works in 
with voyage linux (without busybox). There is something more subtle 
going on.

Marc



-- 
Marc Jones
Senior Firmware Engineer
(970) 226-9684 Office
mailto:Marc.Jones at amd.com
http://www.amd.com/embeddedprocessors




From jordan.crouse at amd.com  Tue Nov  4 21:36:56 2008
From: jordan.crouse at amd.com (Jordan Crouse)
Date: Tue, 4 Nov 2008 13:36:56 -0700
Subject: [coreboot] and/or busybox issue with alix2c3 serial console
In-Reply-To: <ec3a010b0811041047sdef307cq2c0ab830d0a102e3@mail.gmail.com>
References: <200811041938.33674.leroi.lists@gmail.com>
	<491097B7.4010901@amd.com>
	<ec3a010b0811041047sdef307cq2c0ab830d0a102e3@mail.gmail.com>
Message-ID: <20081104203656.GC5424@cosmic.amd.com>

On 04/11/08 20:47 +0200, Roman Yeryomin wrote:
> On Tue, Nov 4, 2008 at 8:43 PM, Marc Jones <Marc.Jones at amd.com> wrote:
> > Roman Yeryomin wrote:
> >>
> >> I'm experimenting with coreboot (v3) on alix2c3 and still can't get serial
> >> console working. :( It stops right after kernel is done booting (I can see
> >> coreboot, filo and kernel messages just fine). I
> >
> > Is it just the console that stops? The kernel is still running and otherwise
> > behaving normally?
> 
> exactly! only console is not working...
> system is running fine (at least for few hours for sure)

pass CONSOLE=/dev/ttyS0 on the command line.

Jordan

-- 
Jordan Crouse
Systems Software Development Engineer 
Advanced Micro Devices, Inc.




From leroi.lists at gmail.com  Tue Nov  4 21:40:20 2008
From: leroi.lists at gmail.com (Roman Yeryomin)
Date: Tue, 4 Nov 2008 22:40:20 +0200
Subject: [coreboot] and/or busybox issue with alix2c3 serial console
In-Reply-To: <13426df10811041107u437f9941u57f869d635d4e62a@mail.gmail.com>
References: <200811041938.33674.leroi.lists@gmail.com>
	<13426df10811041037u7b08e9dejd4d61b1a51f8572a@mail.gmail.com>
	<ec3a010b0811041057x2e5ea5a1l50016e847c1a66d1@mail.gmail.com>
	<13426df10811041107u437f9941u57f869d635d4e62a@mail.gmail.com>
Message-ID: <ec3a010b0811041240s1c710264u7a5e0bb2236d70d7@mail.gmail.com>

On Tue, Nov 4, 2008 at 9:07 PM, ron minnich <rminnich at gmail.com> wrote:
> On Tue, Nov 4, 2008 at 10:57 AM, Roman Yeryomin <leroi.lists at gmail.com> wrote:
>
>> block2mtd.block2mtd=/dev/hda2,131072,rootfs root=/dev/mtdblock0
>> rootfstype=jffs2 init=/etc/preinit noinitrd console=ttyS0,38400n8
>>
>
> to "replace" init, do this:
> init=/bin/bash
>

yes, I've done that before
openWRT uses init=/etc/preinit by default and init=/bin/sh makes
kerenel to panic:

Kernel panic - not syncing: Attempted to kill init!


Roman



From corey.osgood at gmail.com  Tue Nov  4 22:00:01 2008
From: corey.osgood at gmail.com (Corey Osgood)
Date: Tue, 4 Nov 2008 16:00:01 -0500
Subject: [coreboot] [PATCH] CN700/VT8237R stage2
In-Reply-To: <49106320.60609@gmx.net>
References: <dd3c80060810290102o7b28a867y4b103e8b6ee4c621@mail.gmail.com>
	<490BB7F6.9030509@gmx.net>
	<dd3c80060810312206s558be78fs7f03da2715fe9dfd@mail.gmail.com>
	<dd3c80060810312208g49db1707j839fb9f18f4867f6@mail.gmail.com>
	<490C3E8C.7050307@gmx.net> <490C3FB1.8050901@gmx.net>
	<dd3c80060811011056k240a2b28ha80e33f11b4bb8df@mail.gmail.com>
	<490CA9F1.90704@gmx.net> <490CCA08.5090302@gmx.net>
	<49106320.60609@gmx.net>
Message-ID: <dd3c80060811041300w58f018fbqee7461e4c8390d63@mail.gmail.com>

On Tue, Nov 4, 2008 at 9:58 AM, Carl-Daniel Hailfinger <
c-d.hailfinger.devel.2006 at gmx.net> wrote:

> On 01.11.2008 22:28, Carl-Daniel Hailfinger wrote:
> > On 01.11.2008 20:11, Carl-Daniel Hailfinger wrote:
> >
> >> On 01.11.2008 18:56, Corey Osgood wrote:
> >>
> >>
> >>> System reset seems to occur between 2 and 3, both of those logs
> attached,
> >>> along with arch/x86/via/stage1.o With HALT_AFTER=3, the post code keeps
> >>> changing, as expected with the system rebooting, with HALT_AFTER=2 it
> was
> >>> 0xc2.
> >>>
> >>>
> >>>
> >> Great results, thanks a lot!
> >> One bug spotted and fixed. Can you retest with the same method and the
> >> updated patch attached to this mail? I hope it will die much later,
> >> perhaps at HALT_AFTER=13 or so.
> >>
> >>
> >
> > Thanks for the information that HALT_AFTER=5 is the last working setting.
> >
>
> OK, I reread every line of the code and reimplemented the problematic
> stuff from scratch.
>
> Can you try the new patch with HALT_AFTER=5 and 6? I'm pretty confident
> that if 6 works, all later numbers should also not reboot.
> By the way, the new code should be even better than the (working) v2 code.


I'll test it out this evening, thanks!

-Corey
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20081104/841f7803/attachment.html>

From leroi.lists at gmail.com  Tue Nov  4 22:07:41 2008
From: leroi.lists at gmail.com (Roman Yeryomin)
Date: Tue, 4 Nov 2008 23:07:41 +0200
Subject: [coreboot] and/or busybox issue with alix2c3 serial console
In-Reply-To: <20081104203656.GC5424@cosmic.amd.com>
References: <200811041938.33674.leroi.lists@gmail.com>
	<491097B7.4010901@amd.com>
	<ec3a010b0811041047sdef307cq2c0ab830d0a102e3@mail.gmail.com>
	<20081104203656.GC5424@cosmic.amd.com>
Message-ID: <ec3a010b0811041307m4e3b425ai74bae20a96fd2ba8@mail.gmail.com>

On Tue, Nov 4, 2008 at 10:36 PM, Jordan Crouse <jordan.crouse at amd.com> wrote:
> On 04/11/08 20:47 +0200, Roman Yeryomin wrote:
>> On Tue, Nov 4, 2008 at 8:43 PM, Marc Jones <Marc.Jones at amd.com> wrote:
>> > Roman Yeryomin wrote:
>> >>
>> >> I'm experimenting with coreboot (v3) on alix2c3 and still can't get serial
>> >> console working. :( It stops right after kernel is done booting (I can see
>> >> coreboot, filo and kernel messages just fine). I
>> >
>> > Is it just the console that stops? The kernel is still running and otherwise
>> > behaving normally?
>>
>> exactly! only console is not working...
>> system is running fine (at least for few hours for sure)
>
> pass CONSOLE=/dev/ttyS0 on the command line.
>

kernel command line? you mean instead of console=ttyS0,38400n8? or append to it?
anyway.. it doesn't help


Roman



From rminnich at gmail.com  Tue Nov  4 22:16:59 2008
From: rminnich at gmail.com (ron minnich)
Date: Tue, 4 Nov 2008 13:16:59 -0800
Subject: [coreboot] and/or busybox issue with alix2c3 serial console
In-Reply-To: <ec3a010b0811041240s1c710264u7a5e0bb2236d70d7@mail.gmail.com>
References: <200811041938.33674.leroi.lists@gmail.com>
	<13426df10811041037u7b08e9dejd4d61b1a51f8572a@mail.gmail.com>
	<ec3a010b0811041057x2e5ea5a1l50016e847c1a66d1@mail.gmail.com>
	<13426df10811041107u437f9941u57f869d635d4e62a@mail.gmail.com>
	<ec3a010b0811041240s1c710264u7a5e0bb2236d70d7@mail.gmail.com>
Message-ID: <13426df10811041316i5d5cfaei4da75a39c0ef6f21@mail.gmail.com>

On Tue, Nov 4, 2008 at 12:40 PM, Roman Yeryomin <leroi.lists at gmail.com> wrote:

> Kernel panic - not syncing: Attempted to kill init!


A pretty sure sign that the shell tried to read /dev/console, got an
eof, and bailed.

ron



From rminnich at gmail.com  Tue Nov  4 22:17:52 2008
From: rminnich at gmail.com (ron minnich)
Date: Tue, 4 Nov 2008 13:17:52 -0800
Subject: [coreboot] and/or busybox issue with alix2c3 serial console
In-Reply-To: <20081104203656.GC5424@cosmic.amd.com>
References: <200811041938.33674.leroi.lists@gmail.com>
	<491097B7.4010901@amd.com>
	<ec3a010b0811041047sdef307cq2c0ab830d0a102e3@mail.gmail.com>
	<20081104203656.GC5424@cosmic.amd.com>
Message-ID: <13426df10811041317n3e1b6462hbcd0a608591753f9@mail.gmail.com>

On Tue, Nov 4, 2008 at 12:36 PM, Jordan Crouse <jordan.crouse at amd.com> wrote:
> On 04/11/08 20:47 +0200, Roman Yeryomin wrote:
>> On Tue, Nov 4, 2008 at 8:43 PM, Marc Jones <Marc.Jones at amd.com> wrote:
>> > Roman Yeryomin wrote:
>> >>
>> >> I'm experimenting with coreboot (v3) on alix2c3 and still can't get serial
>> >> console working. :( It stops right after kernel is done booting (I can see
>> >> coreboot, filo and kernel messages just fine). I
>> >
>> > Is it just the console that stops? The kernel is still running and otherwise
>> > behaving normally?
>>
>> exactly! only console is not working...
>> system is running fine (at least for few hours for sure)
>
> pass CONSOLE=/dev/ttyS0 on the command line.
>

does CONSOLE have some special meaning to busybox?

Ward, how is your 2c3 nowadays? COuld Roman send you an image and you
see if it boots?

ron



From ward at gnu.org  Tue Nov  4 22:28:03 2008
From: ward at gnu.org (Ward Vandewege)
Date: Tue, 4 Nov 2008 16:28:03 -0500
Subject: [coreboot] and/or busybox issue with alix2c3 serial console
In-Reply-To: <13426df10811041317n3e1b6462hbcd0a608591753f9@mail.gmail.com>
References: <200811041938.33674.leroi.lists@gmail.com>
	<491097B7.4010901@amd.com>
	<ec3a010b0811041047sdef307cq2c0ab830d0a102e3@mail.gmail.com>
	<20081104203656.GC5424@cosmic.amd.com>
	<13426df10811041317n3e1b6462hbcd0a608591753f9@mail.gmail.com>
Message-ID: <20081104212802.GA30213@localdomain>

On Tue, Nov 04, 2008 at 01:17:52PM -0800, ron minnich wrote:
> On Tue, Nov 4, 2008 at 12:36 PM, Jordan Crouse <jordan.crouse at amd.com> wrote:
> > On 04/11/08 20:47 +0200, Roman Yeryomin wrote:
> >> On Tue, Nov 4, 2008 at 8:43 PM, Marc Jones <Marc.Jones at amd.com> wrote:
> >> > Roman Yeryomin wrote:
> >> >>
> >> >> I'm experimenting with coreboot (v3) on alix2c3 and still can't get serial
> >> >> console working. :( It stops right after kernel is done booting (I can see
> >> >> coreboot, filo and kernel messages just fine). I
> >> >
> >> > Is it just the console that stops? The kernel is still running and otherwise
> >> > behaving normally?
> >>
> >> exactly! only console is not working...
> >> system is running fine (at least for few hours for sure)
> >
> > pass CONSOLE=/dev/ttyS0 on the command line.
> >
> 
> does CONSOLE have some special meaning to busybox?
> 
> Ward, how is your 2c3 nowadays? COuld Roman send you an image and you
> see if it boots?

I've got two 2c3's in production, with coreboot. I could probably test on one
(my home firewall), but it's a bit annoying because it takes down my network
:) This week's hard though, I'm technically on vacation... But I'm interested
in helping out for sure.

Thanks,
Ward.
 
-- 
Ward Vandewege <ward at fsf.org>
Free Software Foundation - Senior Systems Administrator



From rminnich at gmail.com  Tue Nov  4 22:30:07 2008
From: rminnich at gmail.com (ron minnich)
Date: Tue, 4 Nov 2008 13:30:07 -0800
Subject: [coreboot] and/or busybox issue with alix2c3 serial console
In-Reply-To: <20081104212802.GA30213@localdomain>
References: <200811041938.33674.leroi.lists@gmail.com>
	<491097B7.4010901@amd.com>
	<ec3a010b0811041047sdef307cq2c0ab830d0a102e3@mail.gmail.com>
	<20081104203656.GC5424@cosmic.amd.com>
	<13426df10811041317n3e1b6462hbcd0a608591753f9@mail.gmail.com>
	<20081104212802.GA30213@localdomain>
Message-ID: <13426df10811041330n4e48d63t1191ad17aadf8a00@mail.gmail.com>

ward, can you do a flashrom -r on a bios image and send it to roman?

This would have to be v3

ron



From svn at coreboot.org  Tue Nov  4 22:32:59 2008
From: svn at coreboot.org (svn at coreboot.org)
Date: Tue,  4 Nov 2008 22:32:59 +0100
Subject: [coreboot] r980 - coreboot-v3/device
Message-ID: <mailman.2385.1355071424.16123.coreboot@coreboot.org>

Author: myles
Date: 2008-11-04 22:32:59 +0100 (Tue, 04 Nov 2008)
New Revision: 980

Modified:
   coreboot-v3/device/pci_device.c
Log:
This patch clarifies/adds comments and changes names in device/pci_device.c

It also changes %p debug statements in various places.  I think they get in
the way of diffs when you have log files to compare.  I don't want to see the
allocation differences most of the time.  I turned most of them into NULL
checks.  If they were supposed to be "Where are we in device allocation?"
checks, we could make them into that too.

It's a work-in-progress. Comments welcome.

I think most of the changes are self explanatory, but this one might not be:

If you are reading all the BARs from a device, and you come to a 64-bit BAR.
No matter why you skip it, you should skip it as a 64-bit BAR, and not try to
read the upper half as the next 32-bit BAR.

Because of that, set the 64-bit flag IORESOURCE_PCI64 early, and don't clear
it on return.

Signed-off-by: Myles Watson <mylesgw at gmail.com>
Acked-by: Ronald G. Minnich <rminnich at gmail.com>


Modified: coreboot-v3/device/pci_device.c
===================================================================
--- coreboot-v3/device/pci_device.c	2008-11-04 17:00:07 UTC (rev 979)
+++ coreboot-v3/device/pci_device.c	2008-11-04 21:32:59 UTC (rev 980)
@@ -30,11 +30,13 @@
 #include <device/device.h>
 #include <device/pci.h>
 #include <device/pci_ids.h>
+/* We should move these so they're really config options */
 #define CONFIG_HYPERTRANSPORT_PLUGIN_SUPPORT 0
 #define CONFIG_PCIX_PLUGIN_SUPPORT 0
 #define CONFIG_PCIE_PLUGIN_SUPPORT 0
 #define CONFIG_CARDBUS_PLUGIN_SUPPORT 0
 #define CONFIG_AGP_PLUGIN_SUPPORT 0
+
 #if CONFIG_HYPERTRANSPORT_PLUGIN_SUPPORT == 1
 #include <device/hypertransport.h>
 #endif
@@ -100,8 +102,16 @@
 	return ones ^ zeroes;
 }
 
-unsigned int pci_find_next_capability(struct device *dev, unsigned int cap,
-				      unsigned int last)
+/**
+ * Given a device, a capability type, and a last position, return the next
+ * matching capability. Always start at the head of the list.
+ *
+ * @param dev Pointer to the device structure.
+ * @param cap_type PCI_CAP_LIST_ID of the PCI capability we're looking for.
+ * @param last_pos Location of the PCI capability register to start from.
+ */
+unsigned int pci_find_next_capability(struct device *dev, unsigned int cap_type,
+				      unsigned int last_pos)
 {
 	unsigned int pos;
 	unsigned int status;
@@ -124,27 +134,35 @@
 	}
 	pos = pci_read_config8(dev, pos);
 	while (reps-- && (pos >= 0x40)) { /* Loop through the linked list. */
-		int this_cap;
+		int this_cap_type;
 		pos &= ~3;
-		this_cap = pci_read_config8(dev, pos + PCI_CAP_LIST_ID);
-		printk(BIOS_SPEW, "Capability: 0x%02x @ 0x%02x\n", cap, pos);
-		if (this_cap == 0xff) {
+		this_cap_type = pci_read_config8(dev, pos + PCI_CAP_LIST_ID);
+		printk(BIOS_SPEW, "Capability: 0x%02x @ 0x%02x\n",
+			this_cap_type, pos);
+		if (this_cap_type == 0xff) {
 			break;
 		}
-		if (!last && (this_cap == cap)) {
+		if (!last_pos && (this_cap_type == cap_type)) {
 			return pos;
 		}
-		if (last == pos) {
-			last = 0;
+		if (last_pos == pos) { /* Return the next match. */
+			last_pos = 0;
 		}
 		pos = pci_read_config8(dev, pos + PCI_CAP_LIST_NEXT);
 	}
 	return 0;
 }
 
-unsigned int pci_find_capability(struct device *dev, unsigned int cap)
+/**
+ * Given a device, and a capability type, return the next matching
+ * capability. Always start at the head of the list.
+ *
+ * @param dev Pointer to the device structure.
+ * @param cap_type PCI_CAP_LIST_ID of the PCI capability we're looking for.
+ */
+unsigned int pci_find_capability(struct device *dev, unsigned int cap_type)
 {
-	return pci_find_next_capability(dev, cap, 0);
+	return pci_find_next_capability(dev, cap_type, 0);
 }
 
 /**
@@ -167,9 +185,9 @@
 
 	/* save the base address */
 	if (value & PCI_BASE_ADDRESS_SPACE_IO)
-		base &= ~PCI_BASE_ADDRESS_IO_ATTR_MASK;
+		base = value & ~PCI_BASE_ADDRESS_IO_ATTR_MASK;
 	else
-		base &= ~PCI_BASE_ADDRESS_MEM_ATTR_MASK;
+		base = value & ~PCI_BASE_ADDRESS_MEM_ATTR_MASK;
 
 	/* See which bits move. */
 	moving = pci_moving_config32(dev, index);
@@ -184,6 +202,7 @@
 		/* Find the high bits that move. */
 		moving |=
 		    ((resource_t) pci_moving_config32(dev, index + 4)) << 32;
+		resource->flags |= IORESOURCE_PCI64;
 	}
 
 	/* Find the resource constraints.
@@ -220,7 +239,11 @@
 			       "%s register %02lx(%08lx), read-only ignoring it\n",
 			       dev_path(dev), index, value);
 		}
-		resource->flags = 0;
+		/* resource->flags = 0;
+		 * Shouldn't zero because we'll get off with 64-bit BARs.
+		 * Are there any others to save?
+		 */
+		resource->flags &= ~IORESOURCE_PCI64;
 	} else if (attr & PCI_BASE_ADDRESS_SPACE_IO) {
 		/* An I/O mapped base address. */
 		attr &= PCI_BASE_ADDRESS_IO_ATTR_MASK;
@@ -244,7 +267,6 @@
 		} else if (attr == PCI_BASE_ADDRESS_MEM_LIMIT_64) {
 			/* 64bit limit. */
 			resource->limit = 0xffffffffffffffffULL;
-			resource->flags |= IORESOURCE_PCI64;
 		} else {
 			/* Invalid value. */
 			resource->flags = 0;
@@ -258,6 +280,12 @@
 	return resource;
 }
 
+/**
+ * Given a device and an index, read the size of the BAR for that register. 
+ *
+ * @param dev Pointer to the device structure.
+ * @param index Address of the PCI configuration register.
+ */
 static void pci_get_rom_resource(struct device *dev, unsigned long index)
 {
 	struct resource *resource;
@@ -265,8 +293,7 @@
 	resource_t moving, limit;
 
 	if ((dev->on_mainboard) && (dev->rom_address == 0)) {
-		// Skip it if rom_address is not set in MB Config.lb.
-		// TODO: No more Config.lb in coreboot-v3.
+		// Skip it if rom_address is not set in the mainboard's dts.
 		return;
 	}
 
@@ -278,6 +305,7 @@
 
 	/* See which bits move. */
 	moving = pci_moving_config32(dev, index);
+
 	/* Clear the Enable bit. */
 	moving = moving & ~PCI_ROM_ADDRESS_ENABLE;
 
@@ -298,23 +326,19 @@
 			resource->gran += 1;
 		}
 		resource->limit = limit = moving | (resource->size - 1);
-	}
-
-	if (moving == 0) {
+		resource->flags |= IORESOURCE_MEM | IORESOURCE_READONLY;
+	} else {
 		if (value != 0) {
 			printk(BIOS_DEBUG,
 			       "%s register %02lx(%08lx), read-only ignoring it\n",
 			       dev_path(dev), index, value);
 		}
 		resource->flags = 0;
-	} else {
-		resource->flags |= IORESOURCE_MEM | IORESOURCE_READONLY;
 	}
 
 	/* For on board device with embedded ROM image, the ROM image is at
-	 * fixed address specified in the Config.lb, the dev->rom_address is
+	 * fixed address specified in the dts, the dev->rom_address is
 	 * inited by driver_pci_onboard_ops::enable_dev() */
-	/* TODO: No more Config.lb in coreboot-v3. */
 	if ((dev->on_mainboard) && (dev->rom_address != 0)) {
 		resource->base = dev->rom_address;
 		resource->flags |= IORESOURCE_MEM | IORESOURCE_READONLY |
@@ -718,7 +742,7 @@
 
 void pci_dev_init(struct device *dev)
 {
-	printk(BIOS_SPEW, "PCI: pci_dev_init\n");
+	printk(BIOS_SPEW, "PCI: pci_dev_init %s\n", dev->dtsname);
 #ifdef CONFIG_PCI_OPTION_ROM_RUN
 	void run_bios(struct device *dev, unsigned long addr);
 	struct rom_header *rom, *ram;
@@ -774,7 +798,7 @@
  * When only a PCI-Express capability is found the type
  * is examined to see which type of bridge we have.
  *
- * @param dev TODO
+ * @param dev Pointer to the device structure of the bridge.
  * @return Appropriate bridge operations.
  */
 static struct device_operations *get_pci_bridge_ops(struct device *dev)
@@ -831,9 +855,10 @@
 }
 
 /**
- * Set up PCI device operation.
+ * Set up PCI device operation.  Check if it already has a driver.  If not, use
+ * find_device_operations, or set to a default based on type.
  *
- * @param dev TODO
+ * @param dev Pointer to the device whose pci_ops you want to set.
  * @see pci_drivers
  */
 static void set_pci_ops(struct device *dev)
@@ -842,8 +867,8 @@
 	struct device_id id;
 
 	if (dev->ops) {
-		printk(BIOS_SPEW, "%s: dev %p(%s) already has ops %p\n",
-		       __func__, dev, dev->dtsname, dev->ops);
+		printk(BIOS_SPEW, "%s: dev %s already has ops of type %x\n",
+		       __func__, dev->dtsname, dev->ops->id.type);
 		return;
 	}
 
@@ -888,8 +913,8 @@
 			       dev->hdr_type);
 		}
 	}
-	printk(BIOS_INFO, "%s: dev %p(%s) set ops to %p\n", __func__, dev,
-	       dev->dtsname, dev->ops);
+	printk(BIOS_INFO, "%s: dev %s set ops to type %x\n", __func__,
+	       dev->dtsname, dev->ops->id.type);
 	return;
 }
 
@@ -905,12 +930,12 @@
  * @return Pointer to the device structure found or NULL of we have not
  *	   allocated a device for this devfn yet.
  */
-static struct device *pci_scan_get_dev(struct device **list, unsigned int devfn)
+static struct device *pci_get_dev(struct device **list, unsigned int devfn)
 {
 	struct device *dev;
 	dev = 0;
-	printk(BIOS_SPEW, "%s: list is %p, *list is %p\n", __func__, list,
-	       *list);
+	printk(BIOS_SPEW, "%s: list is %sNULL, *list is %sNULL\n", __func__,
+		list?"NOT ":"", *list?"NOT ":"");
 	for (; *list; list = &(*list)->sibling) {
 		printk(BIOS_SPEW, "%s: check dev %s \n", __func__,
 		       (*list)->dtsname);
@@ -927,7 +952,7 @@
 			/* Unlink from the list. */
 			dev = *list;
 			*list = (*list)->sibling;
-			dev->sibling = 0;
+			dev->sibling = NULL;
 			break;
 		}
 	}
@@ -962,8 +987,8 @@
  *
  * @param dev Pointer to the device structure if it already is in the device
  *         tree, i.e. was specified in the dts. It may not exist on hardware,
- *         however. Looking for hardware not yet in the device tree has this
- *         parameter as NULL.
+ *         however. When looking for hardware not yet in the device tree, this
+ *         parameter is NULL.
  * @param bus Pointer to the bus structure.
  * @param devfn A device/function number.
  * @return The device structure for the device if it exists in hardware
@@ -1021,7 +1046,6 @@
 		 * this also handles optional devices that may not always
 		 * show up.
 		 */
-		/* If the chain is fully enumerated quit. */
 		if ((id == 0xffffffff) || (id == 0x00000000) ||
 		    (id == 0x0000ffff) || (id == 0xffff0000)) {
 			if (dev->enabled) {
@@ -1034,6 +1058,7 @@
 		}
 	}
 	/* Read the rest of the PCI configuration information. */
+	/* Store the interesting information in the device structure. */
 	hdr_type = pci_read_config8(dev, PCI_HEADER_TYPE);
 	class = pci_read_config32(dev, PCI_CLASS_REVISION);
 	dev->status = pci_read_config16(dev, PCI_STATUS);
@@ -1043,15 +1068,22 @@
 	dev->irq_pin = pci_read_config8(dev, PCI_INTERRUPT_PIN);
 	dev->min_gnt = pci_read_config8(dev, PCI_MIN_GNT);
 	dev->max_lat = pci_read_config8(dev, PCI_MAX_LAT);
-#warning Per-device subsystem ID should only be read from the device if none has been specified for the device in the dts.
-	dev->subsystem_vendor = pci_read_config16(dev, PCI_SUBSYSTEM_VENDOR_ID);
-	dev->subsystem_device = pci_read_config16(dev, PCI_SUBSYSTEM_ID);
 
-	/* Store the interesting information in the device structure. */
+	/*Per-device subsystem ID should only be read from the device if none
+	 * has been specified for the device in the dts.
+	 */
+	if (!dev->subsystem_vendor && !dev->subsystem_device) {
+		dev->subsystem_vendor = 
+				pci_read_config16(dev, PCI_SUBSYSTEM_VENDOR_ID);
+		dev->subsystem_device = 
+				pci_read_config16(dev, PCI_SUBSYSTEM_ID);
+	}
+
 	dev->id.type = DEVICE_ID_PCI;
 	dev->id.pci.vendor = id & 0xffff;
 	dev->id.pci.device = (id >> 16) & 0xffff;
 	dev->hdr_type = hdr_type;
+
 	/* Class code, the upper 3 bytes of PCI_CLASS_REVISION. */
 	dev->class = class >> 8;
 
@@ -1070,9 +1102,7 @@
 		dev->ops->phase3_enable(dev);
 	}
 
-	/* Display the device and error if we don't have some PCI operations
-	 * for it.
-	 */
+	/* Display the device. */
 	printk(BIOS_DEBUG, "%s [%s] %s%s\n",
 	       dev_path(dev), dev_id_string(&dev->id),
 	       dev->enabled ? "enabled" : "disabled",
@@ -1093,18 +1123,20 @@
  * @param bus Pointer to the bus structure.
  * @param min_devfn Minimum devfn to look at in the scan usually 0x00.
  * @param max_devfn Maximum devfn to look at in the scan usually 0xff.
- * @param max Current bus number.
- * @return The maximum bus number found, after scanning all subordinate buses.
+ * @param curr_bus Current bus number to be assigned.
+ * @return The new curr_bus, after scanning all subordinate buses.
  */
 unsigned int pci_scan_bus(struct bus *bus, unsigned int min_devfn,
-			  unsigned int max_devfn, unsigned int max)
+			  unsigned int max_devfn, unsigned int curr_bus)
 {
 	unsigned int devfn;
 	struct device *old_devices;
 	struct device *child;
 
-	printk(BIOS_DEBUG, "%s start bus %p, bus->dev %p\n", __func__, bus,
-	       bus->dev);
+	printk(BIOS_DEBUG, "%s start bus->dev %s bus %x\n", __func__,
+	       bus->dev->dtsname, bus->link);
+
+#warning This check needs checking.
 	if (bus->dev->path.type != DEVICE_PATH_PCI_BUS)
 		printk(BIOS_ERR, "ERROR: pci_scan_bus called with incorrect "
 		       "bus->dev->path.type, path is %s\n", dev_path(bus->dev));
@@ -1116,10 +1148,11 @@
 	printk(BIOS_DEBUG, "PCI: pci_scan_bus for bus %02x\n", bus->secondary);
 #endif
 
+	/* Remove children of the bus, so the enumeration starts empty. */
 	old_devices = bus->children;
-	printk(BIOS_DEBUG, "%s: old_devices %p, dev for this bus %p (%s)\n",
-	       __func__, old_devices, bus->dev, bus->dev->dtsname);
-	bus->children = 0;
+	printk(BIOS_DEBUG, "%s: old_devices %s, dev for this bus %s\n",
+	       __func__, old_devices?old_devices->dtsname:"NULL", bus->dev->dtsname);
+	bus->children = NULL;
 
 	post_code(POST_STAGE2_PCISCANBUS_ENTER);
 	printk(BIOS_SPEW, "PCI: scan devfn 0x%x to 0x%x\n", min_devfn,
@@ -1131,17 +1164,18 @@
 		struct device *dev;
 		printk(BIOS_SPEW, "PCI: devfn 0x%x\n", devfn);
 
-		/* First thing setup the device structure. */
-		dev = pci_scan_get_dev(&old_devices, devfn);
+		/* First thing look in the device tree. */
+		dev = pci_get_dev(&old_devices, devfn);
 
 		printk(BIOS_SPEW,
-		       "PCI: pci_scan_bus pci_scan_get_dev returns dev %s\n",
+		       "PCI: pci_scan_bus pci_get_dev returns dev %s\n",
 		       dev ? dev->dtsname : "None (no dev in tree yet)");
+
 		/* See if a device is present and setup the device structure. */
 		dev = pci_probe_dev(dev, bus, devfn);
 		printk(BIOS_SPEW,
-		       "PCI: pci_scan_bus pci_probe_dev returns dev %p(%s)\n",
-		       dev, dev ? dev->dtsname : "None (not found)");
+		       "PCI: pci_scan_bus pci_probe_dev returns dev %s\n",
+		       dev ? dev->dtsname : "None (no response)");
 
 		/* If this is not a multi function device, or the device is
 		 * not present don't waste time probing another function. 
@@ -1158,9 +1192,8 @@
 	printk(BIOS_SPEW, "PCI: Done for loop\n");
 	post_code(POST_STAGE2_PCISCANBUS_DONEFORLOOP);
 
-	/* Die if any leftover static devices are are found.  
-	 * There's probably a problem in the Config.lb.
-	 * TODO: No more Config.lb in coreboot-v3.
+	/* Warn if any leftover static devices are are found.  
+	 * There's probably a problem in the device tree (dts).
 	 */
 	if (old_devices) {
 		struct device *left;
@@ -1175,16 +1208,17 @@
 	 * scan the bus behind that child.
 	 */
 	for (child = bus->children; child; child = child->sibling) {
-		max = dev_phase3_scan(child, max);
+		curr_bus = dev_phase3_scan(child, curr_bus);
 	}
 
 	/* We've scanned the bus and so we know all about what's on the other
 	 * side of any bridges that may be on this bus plus any devices.
 	 * Return how far we've got finding sub-buses.
 	 */
-	printk(BIOS_DEBUG, "PCI: pci_scan_bus returning with max=%03x\n", max);
+	printk(BIOS_DEBUG, "PCI: pci_scan_bus returning with curr_bus=%03x\n",
+		curr_bus);
 	post_code(POST_STAGE2_PCISCANBUS_EXIT);
-	return max;
+	return curr_bus;
 }
 
 /**
@@ -1194,14 +1228,14 @@
  * This function works for almost all chipsets (AMD K8 is the exception).
  *
  * @param dev The PCI domain device.
- * @param max Maximum number of devices to scan.
- * @return TODO
+ * @param max The current bus number to be assigned.
+ * @return The current bus number returned by pci_scan_bus.
  */
-unsigned int pci_domain_scan_bus(struct device *dev, unsigned int max)
+unsigned int pci_domain_scan_bus(struct device *dev, unsigned int curr_bus)
 {
 	printk(BIOS_SPEW, "pci_domain_scan_bus: calling pci_scan_bus\n");
 	/* There is only one link on this device, and it is always link 0. */
-	return pci_scan_bus(&dev->link[0], PCI_DEVFN(0, 0), 0xff, max);
+	return pci_scan_bus(&dev->link[0], PCI_DEVFN(0, 0), 0xff, curr_bus);
 }
 
 /**




From leroi.lists at gmail.com  Tue Nov  4 22:33:02 2008
From: leroi.lists at gmail.com (Roman Yeryomin)
Date: Tue, 4 Nov 2008 23:33:02 +0200
Subject: [coreboot] and/or busybox issue with alix2c3 serial console
In-Reply-To: <13426df10811041316i5d5cfaei4da75a39c0ef6f21@mail.gmail.com>
References: <200811041938.33674.leroi.lists@gmail.com>
	<13426df10811041037u7b08e9dejd4d61b1a51f8572a@mail.gmail.com>
	<ec3a010b0811041057x2e5ea5a1l50016e847c1a66d1@mail.gmail.com>
	<13426df10811041107u437f9941u57f869d635d4e62a@mail.gmail.com>
	<ec3a010b0811041240s1c710264u7a5e0bb2236d70d7@mail.gmail.com>
	<13426df10811041316i5d5cfaei4da75a39c0ef6f21@mail.gmail.com>
Message-ID: <ec3a010b0811041333y111b3ffdv8445d1e60382e19d@mail.gmail.com>

On Tue, Nov 4, 2008 at 11:16 PM, ron minnich <rminnich at gmail.com> wrote:
> On Tue, Nov 4, 2008 at 12:40 PM, Roman Yeryomin <leroi.lists at gmail.com> wrote:
>
>> Kernel panic - not syncing: Attempted to kill init!
>
>
> A pretty sure sign that the shell tried to read /dev/console, got an
> eof, and bailed.
>

forgot to mention that I tried to modify /etc/preinit adding
echo ">>>>>>>> HERE <<<<<<<<<"
above all the script code and it didn't appear on console


Roman



From mylesgw at gmail.com  Tue Nov  4 22:33:41 2008
From: mylesgw at gmail.com (Myles Watson)
Date: Tue, 4 Nov 2008 15:33:41 -0600
Subject: [coreboot] pci_device.c cleanup
In-Reply-To: <13426df10811041217t5b86444fxef4b9d66ecf74646@mail.gmail.com>
References: <2831fecf0811041204u59f2ccc9h5cb18f5e96c5fb@mail.gmail.com>
	<13426df10811041217t5b86444fxef4b9d66ecf74646@mail.gmail.com>
Message-ID: <2831fecf0811041333w553cc824h3e9c75ca02c08842@mail.gmail.com>

On Tue, Nov 4, 2008 at 2:17 PM, ron minnich <rminnich at gmail.com> wrote:

> I can not test this week.
>
> Acked-by: Ronald G. Minnich <rminnich at gmail.com>
>

Rev 980.

Thanks,
Myles
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20081104/7b8b4509/attachment.html>

From shadravan.fontanov at googlemail.com  Tue Nov  4 22:37:31 2008
From: shadravan.fontanov at googlemail.com (Shadravan Fontanov)
Date: Tue, 4 Nov 2008 22:37:31 +0100
Subject: [coreboot] question about mapping of registers to I/O locations
Message-ID: <ade90ae0811041337k413cf519n6103d5ad27e5debe@mail.gmail.com>

Hello,

citation from  datasheet of ICH5/ICH5R chipset
(http://download.intel.com/design/chipsets/datashts/25251601.pdf),
page 385:
"These registers are enabled in the PCI Device 31: Function 0 space
(PM_IO_EN), and can be
moved to any I/O location (128-byte aligned)."

I didnt understand, who moves the registers in the i/o space -- BIOS,
or linux kernel? Is there a default value for PMBASE (0x800), at which
the registers are visible after starting the machine, without the need
of explicit i/o mapping?

Regards

Shadravan



From leroi.lists at gmail.com  Tue Nov  4 22:40:28 2008
From: leroi.lists at gmail.com (Roman Yeryomin)
Date: Tue, 4 Nov 2008 23:40:28 +0200
Subject: [coreboot] and/or busybox issue with alix2c3 serial console
In-Reply-To: <13426df10811041330n4e48d63t1191ad17aadf8a00@mail.gmail.com>
References: <200811041938.33674.leroi.lists@gmail.com>
	<491097B7.4010901@amd.com>
	<ec3a010b0811041047sdef307cq2c0ab830d0a102e3@mail.gmail.com>
	<20081104203656.GC5424@cosmic.amd.com>
	<13426df10811041317n3e1b6462hbcd0a608591753f9@mail.gmail.com>
	<20081104212802.GA30213@localdomain>
	<13426df10811041330n4e48d63t1191ad17aadf8a00@mail.gmail.com>
Message-ID: <ec3a010b0811041340q202fc54fkecd64f6099622846@mail.gmail.com>

On Tue, Nov 4, 2008 at 11:30 PM, ron minnich <rminnich at gmail.com> wrote:
> ward, can you do a flashrom -r on a bios image and send it to roman?

As far as I remember Ward is using voyage linux and I've mentioned
that voyage linux (and probably others not based on busybox) works for
me also.
But surely I can test his image!
Attaching mine as well if somebody wants to try...


Roman
-------------- next part --------------
A non-text attachment was scrubbed...
Name: bios.bin
Type: application/octet-stream
Size: 524288 bytes
Desc: not available
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20081104/4ef6eb1e/attachment.bin>

From rminnich at gmail.com  Tue Nov  4 22:41:44 2008
From: rminnich at gmail.com (ron minnich)
Date: Tue, 4 Nov 2008 13:41:44 -0800
Subject: [coreboot] and/or busybox issue with alix2c3 serial console
In-Reply-To: <ec3a010b0811041340q202fc54fkecd64f6099622846@mail.gmail.com>
References: <200811041938.33674.leroi.lists@gmail.com>
	<491097B7.4010901@amd.com>
	<ec3a010b0811041047sdef307cq2c0ab830d0a102e3@mail.gmail.com>
	<20081104203656.GC5424@cosmic.amd.com>
	<13426df10811041317n3e1b6462hbcd0a608591753f9@mail.gmail.com>
	<20081104212802.GA30213@localdomain>
	<13426df10811041330n4e48d63t1191ad17aadf8a00@mail.gmail.com>
	<ec3a010b0811041340q202fc54fkecd64f6099622846@mail.gmail.com>
Message-ID: <13426df10811041341v413eff06g3f7fc3ad663dbc1e@mail.gmail.com>

What's your kernel version and what is his kernel version?

ron



From ward at gnu.org  Tue Nov  4 22:42:50 2008
From: ward at gnu.org (Ward Vandewege)
Date: Tue, 4 Nov 2008 16:42:50 -0500
Subject: [coreboot] and/or busybox issue with alix2c3 serial console
In-Reply-To: <13426df10811041330n4e48d63t1191ad17aadf8a00@mail.gmail.com>
References: <200811041938.33674.leroi.lists@gmail.com>
	<491097B7.4010901@amd.com>
	<ec3a010b0811041047sdef307cq2c0ab830d0a102e3@mail.gmail.com>
	<20081104203656.GC5424@cosmic.amd.com>
	<13426df10811041317n3e1b6462hbcd0a608591753f9@mail.gmail.com>
	<20081104212802.GA30213@localdomain>
	<13426df10811041330n4e48d63t1191ad17aadf8a00@mail.gmail.com>
Message-ID: <20081104214250.GA31608@localdomain>

On Tue, Nov 04, 2008 at 01:30:07PM -0800, ron minnich wrote:
> ward, can you do a flashrom -r on a bios image and send it to roman?

Certainly, attached.

> This would have to be v3

It is (we only have the 2c3 in v3!), but it's an ancient build. 

Thanks,
Ward.

-- 
Ward Vandewege <ward at fsf.org>
Free Software Foundation - Senior Systems Administrator
-------------- next part --------------
A non-text attachment was scrubbed...
Name: alix2c3.rom
Type: application/octet-stream
Size: 524288 bytes
Desc: not available
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20081104/4568293b/attachment.obj>

From leroi.lists at gmail.com  Tue Nov  4 22:45:37 2008
From: leroi.lists at gmail.com (Roman Yeryomin)
Date: Tue, 4 Nov 2008 23:45:37 +0200
Subject: [coreboot] and/or busybox issue with alix2c3 serial console
In-Reply-To: <13426df10811041341v413eff06g3f7fc3ad663dbc1e@mail.gmail.com>
References: <200811041938.33674.leroi.lists@gmail.com>
	<491097B7.4010901@amd.com>
	<ec3a010b0811041047sdef307cq2c0ab830d0a102e3@mail.gmail.com>
	<20081104203656.GC5424@cosmic.amd.com>
	<13426df10811041317n3e1b6462hbcd0a608591753f9@mail.gmail.com>
	<20081104212802.GA30213@localdomain>
	<13426df10811041330n4e48d63t1191ad17aadf8a00@mail.gmail.com>
	<ec3a010b0811041340q202fc54fkecd64f6099622846@mail.gmail.com>
	<13426df10811041341v413eff06g3f7fc3ad663dbc1e@mail.gmail.com>
Message-ID: <ec3a010b0811041345n71f55a28x6ac30dffe450f6be@mail.gmail.com>

On Tue, Nov 4, 2008 at 11:41 PM, ron minnich <rminnich at gmail.com> wrote:
> What's your kernel version and what is his kernel version?

mine (openWRT) is 2.6.25.16
voyage linux I tried has 2.6.23


Roman



From ward at gnu.org  Tue Nov  4 22:47:13 2008
From: ward at gnu.org (Ward Vandewege)
Date: Tue, 4 Nov 2008 16:47:13 -0500
Subject: [coreboot] and/or busybox issue with alix2c3 serial console
In-Reply-To: <13426df10811041341v413eff06g3f7fc3ad663dbc1e@mail.gmail.com>
References: <200811041938.33674.leroi.lists@gmail.com>
	<491097B7.4010901@amd.com>
	<ec3a010b0811041047sdef307cq2c0ab830d0a102e3@mail.gmail.com>
	<20081104203656.GC5424@cosmic.amd.com>
	<13426df10811041317n3e1b6462hbcd0a608591753f9@mail.gmail.com>
	<20081104212802.GA30213@localdomain>
	<13426df10811041330n4e48d63t1191ad17aadf8a00@mail.gmail.com>
	<ec3a010b0811041340q202fc54fkecd64f6099622846@mail.gmail.com>
	<13426df10811041341v413eff06g3f7fc3ad663dbc1e@mail.gmail.com>
Message-ID: <20081104214713.GA32130@localdomain>

On Tue, Nov 04, 2008 at 01:41:44PM -0800, ron minnich wrote:
> What's your kernel version and what is his kernel version?

Right, I'm on voyage 0.5, 

Linux littleredbox.vandewege.net 2.6.23-486-voyage #1 PREEMPT Wed May 21
15:31:49 GMT 2008 i586 GNU/Linux

Thanks,
Ward.

-- 
Ward Vandewege <ward at fsf.org>
Free Software Foundation - Senior Systems Administrator



From eswierk at aristanetworks.com  Tue Nov  4 22:47:25 2008
From: eswierk at aristanetworks.com (Ed Swierk)
Date: Tue, 4 Nov 2008 13:47:25 -0800
Subject: [coreboot] question about mapping of registers to I/O locations
In-Reply-To: <ade90ae0811041337k413cf519n6103d5ad27e5debe@mail.gmail.com>
References: <ade90ae0811041337k413cf519n6103d5ad27e5debe@mail.gmail.com>
Message-ID: <9ae48b020811041347w32b1711ek3694bd96800986b6@mail.gmail.com>

On Tue, Nov 4, 2008 at 1:37 PM, Shadravan Fontanov
<shadravan.fontanov at googlemail.com> wrote:
> citation from  datasheet of ICH5/ICH5R chipset
> (http://download.intel.com/design/chipsets/datashts/25251601.pdf),
> page 385:
> "These registers are enabled in the PCI Device 31: Function 0 space
> (PM_IO_EN), and can be
> moved to any I/O location (128-byte aligned)."
>
> I didnt understand, who moves the registers in the i/o space -- BIOS,
> or linux kernel? Is there a default value for PMBASE (0x800), at which
> the registers are visible after starting the machine, without the need
> of explicit i/o mapping?

See the definition of PMBASE on page 322.

--Ed



From jordan.crouse at amd.com  Tue Nov  4 22:53:27 2008
From: jordan.crouse at amd.com (Jordan Crouse)
Date: Tue, 4 Nov 2008 14:53:27 -0700
Subject: [coreboot] and/or busybox issue with alix2c3 serial console
In-Reply-To: <13426df10811041341v413eff06g3f7fc3ad663dbc1e@mail.gmail.com>
References: <200811041938.33674.leroi.lists@gmail.com>
	<491097B7.4010901@amd.com>
	<ec3a010b0811041047sdef307cq2c0ab830d0a102e3@mail.gmail.com>
	<20081104203656.GC5424@cosmic.amd.com>
	<13426df10811041317n3e1b6462hbcd0a608591753f9@mail.gmail.com>
	<20081104212802.GA30213@localdomain>
	<13426df10811041330n4e48d63t1191ad17aadf8a00@mail.gmail.com>
	<ec3a010b0811041340q202fc54fkecd64f6099622846@mail.gmail.com>
	<13426df10811041341v413eff06g3f7fc3ad663dbc1e@mail.gmail.com>
Message-ID: <20081104215327.GE5424@cosmic.amd.com>

Okay - so we are reasonable confused at this point, so lets reset.  The
kernel and userland have rather different concepts of what the "console"
is.  Its rather possible that the kernel and userland are using different
consoles based on a number of factors.  The reason why I suggested that
he try the CONSOLE= bit is that many distro initscripts use CONSOLE=
grep for CONSOLE in /etc/ on your desktop and you will see evidence of
this.  Now, that, said, that doesn't always work, and I'm looking at
busybox right now for some clues.

It looks like busybox looks for /dev/console and /dev/tty first off,
so we need to make sure that those devices are both available and active.
You may also want to add a getty line in your inittab to open a getty
on ttyS0, so even if you don't have the console output, you should still
have a login prompt.  

Long story short - this is a userland issue, and not really a kernel or
hardware problem.

Jordan

-- 
Jordan Crouse
Systems Software Development Engineer 
Advanced Micro Devices, Inc.




From rminnich at gmail.com  Tue Nov  4 22:55:01 2008
From: rminnich at gmail.com (ron minnich)
Date: Tue, 4 Nov 2008 13:55:01 -0800
Subject: [coreboot] and/or busybox issue with alix2c3 serial console
In-Reply-To: <20081104215327.GE5424@cosmic.amd.com>
References: <200811041938.33674.leroi.lists@gmail.com>
	<491097B7.4010901@amd.com>
	<ec3a010b0811041047sdef307cq2c0ab830d0a102e3@mail.gmail.com>
	<20081104203656.GC5424@cosmic.amd.com>
	<13426df10811041317n3e1b6462hbcd0a608591753f9@mail.gmail.com>
	<20081104212802.GA30213@localdomain>
	<13426df10811041330n4e48d63t1191ad17aadf8a00@mail.gmail.com>
	<ec3a010b0811041340q202fc54fkecd64f6099622846@mail.gmail.com>
	<13426df10811041341v413eff06g3f7fc3ad663dbc1e@mail.gmail.com>
	<20081104215327.GE5424@cosmic.amd.com>
Message-ID: <13426df10811041355t4f2aec28ycf1e82bba5e1a3ed@mail.gmail.com>

On Tue, Nov 4, 2008 at 1:53 PM, Jordan Crouse <jordan.crouse at amd.com> wrote:

> Long story short - this is a userland issue, and not really a kernel or
> hardware problem.
>

no question. I wish I knew what busybox was doing "wrong' such that it
did not work. But, since the changed software in question is coreboot,
it's our problem to resolve the issue ...

One thing I have also done in the past for this sort of problem is to
run the init under strace. It's doable. But does busybox come with
strace nowadays?

ron



From leroi.lists at gmail.com  Tue Nov  4 22:59:46 2008
From: leroi.lists at gmail.com (Roman Yeryomin)
Date: Tue, 4 Nov 2008 23:59:46 +0200
Subject: [coreboot] and/or busybox issue with alix2c3 serial console
In-Reply-To: <20081104214250.GA31608@localdomain>
References: <200811041938.33674.leroi.lists@gmail.com>
	<491097B7.4010901@amd.com>
	<ec3a010b0811041047sdef307cq2c0ab830d0a102e3@mail.gmail.com>
	<20081104203656.GC5424@cosmic.amd.com>
	<13426df10811041317n3e1b6462hbcd0a608591753f9@mail.gmail.com>
	<20081104212802.GA30213@localdomain>
	<13426df10811041330n4e48d63t1191ad17aadf8a00@mail.gmail.com>
	<20081104214250.GA31608@localdomain>
Message-ID: <ec3a010b0811041359x590136a2x83cd16af01959753@mail.gmail.com>

On Tue, Nov 4, 2008 at 11:42 PM, Ward Vandewege <ward at gnu.org> wrote:
> On Tue, Nov 04, 2008 at 01:30:07PM -0800, ron minnich wrote:
>> ward, can you do a flashrom -r on a bios image and send it to roman?
>
> Certainly, attached.
>
>> This would have to be v3
>
> It is (we only have the 2c3 in v3!), but it's an ancient build.
>

tried
no luck
Ron, do you need some output from that?


Roman



From rminnich at gmail.com  Tue Nov  4 23:03:14 2008
From: rminnich at gmail.com (ron minnich)
Date: Tue, 4 Nov 2008 14:03:14 -0800
Subject: [coreboot] and/or busybox issue with alix2c3 serial console
In-Reply-To: <ec3a010b0811041359x590136a2x83cd16af01959753@mail.gmail.com>
References: <200811041938.33674.leroi.lists@gmail.com>
	<491097B7.4010901@amd.com>
	<ec3a010b0811041047sdef307cq2c0ab830d0a102e3@mail.gmail.com>
	<20081104203656.GC5424@cosmic.amd.com>
	<13426df10811041317n3e1b6462hbcd0a608591753f9@mail.gmail.com>
	<20081104212802.GA30213@localdomain>
	<13426df10811041330n4e48d63t1191ad17aadf8a00@mail.gmail.com>
	<20081104214250.GA31608@localdomain>
	<ec3a010b0811041359x590136a2x83cd16af01959753@mail.gmail.com>
Message-ID: <13426df10811041403m25762a5cx2f35ddf38fd9e1dd@mail.gmail.com>

On Tue, Nov 4, 2008 at 1:59 PM, Roman Yeryomin <leroi.lists at gmail.com> wrote:

> tried
> no luck
> Ron, do you need some output from that?

summary:
voyage linux serial console works with two versions of v3
busybox serial console fails with two versions of v3
we get kernel messages for all four combinations.
they all boot and the network works.
For each one, an ls -l of /dev/console and /dev/ttyS0 look correct.

Well ...  ok. Send me dmesg for voyage and busy with newest v3

It's a userland problem, I think, but I am not sure what.

ron



From leroi.lists at gmail.com  Tue Nov  4 23:04:42 2008
From: leroi.lists at gmail.com (Roman Yeryomin)
Date: Wed, 5 Nov 2008 00:04:42 +0200
Subject: [coreboot] and/or busybox issue with alix2c3 serial console
In-Reply-To: <20081104215327.GE5424@cosmic.amd.com>
References: <200811041938.33674.leroi.lists@gmail.com>
	<491097B7.4010901@amd.com>
	<ec3a010b0811041047sdef307cq2c0ab830d0a102e3@mail.gmail.com>
	<20081104203656.GC5424@cosmic.amd.com>
	<13426df10811041317n3e1b6462hbcd0a608591753f9@mail.gmail.com>
	<20081104212802.GA30213@localdomain>
	<13426df10811041330n4e48d63t1191ad17aadf8a00@mail.gmail.com>
	<ec3a010b0811041340q202fc54fkecd64f6099622846@mail.gmail.com>
	<13426df10811041341v413eff06g3f7fc3ad663dbc1e@mail.gmail.com>
	<20081104215327.GE5424@cosmic.amd.com>
Message-ID: <ec3a010b0811041404m2ca70564v4b31fb31458437c2@mail.gmail.com>

On Tue, Nov 4, 2008 at 11:53 PM, Jordan Crouse <jordan.crouse at amd.com> wrote:
> Okay - so we are reasonable confused at this point, so lets reset.  The
> kernel and userland have rather different concepts of what the "console"
> is.  Its rather possible that the kernel and userland are using different
> consoles based on a number of factors.  The reason why I suggested that
> he try the CONSOLE= bit is that many distro initscripts use CONSOLE=
> grep for CONSOLE in /etc/ on your desktop and you will see evidence of
> this.  Now, that, said, that doesn't always work, and I'm looking at
> busybox right now for some clues.
>
> It looks like busybox looks for /dev/console and /dev/tty first off,
> so we need to make sure that those devices are both available and active.
> You may also want to add a getty line in your inittab to open a getty
> on ttyS0, so even if you don't have the console output, you should still
> have a login prompt.
>
> Long story short - this is a userland issue, and not really a kernel or
> hardware problem.

I agree that there is something to do with busybox also but it still
works with factory bios! Why?
I tried getty in inittab also -- same thing, no even login prompt.


Roman



From rminnich at gmail.com  Tue Nov  4 23:16:35 2008
From: rminnich at gmail.com (ron minnich)
Date: Tue, 4 Nov 2008 14:16:35 -0800
Subject: [coreboot] and/or busybox issue with alix2c3 serial console
In-Reply-To: <ec3a010b0811041404m2ca70564v4b31fb31458437c2@mail.gmail.com>
References: <200811041938.33674.leroi.lists@gmail.com>
	<ec3a010b0811041047sdef307cq2c0ab830d0a102e3@mail.gmail.com>
	<20081104203656.GC5424@cosmic.amd.com>
	<13426df10811041317n3e1b6462hbcd0a608591753f9@mail.gmail.com>
	<20081104212802.GA30213@localdomain>
	<13426df10811041330n4e48d63t1191ad17aadf8a00@mail.gmail.com>
	<ec3a010b0811041340q202fc54fkecd64f6099622846@mail.gmail.com>
	<13426df10811041341v413eff06g3f7fc3ad663dbc1e@mail.gmail.com>
	<20081104215327.GE5424@cosmic.amd.com>
	<ec3a010b0811041404m2ca70564v4b31fb31458437c2@mail.gmail.com>
Message-ID: <13426df10811041416h7c0fa3edo1e706e0d723446d9@mail.gmail.com>

On Tue, Nov 4, 2008 at 2:04 PM, Roman Yeryomin <leroi.lists at gmail.com> wrote:

> I agree that there is something to do with busybox also but it still
> works with factory bios! Why?


OK so what we have is a /dev/console issue.

Try to write a simple script:

touch /tmp/ALIVE

Make that script be your init (make sure to set the x bits and put the
right #! shell for first line). Let's verify that we can run a simple
script, that may help with diagnosis

ron



From peter at stuge.se  Tue Nov  4 23:33:20 2008
From: peter at stuge.se (Peter Stuge)
Date: Tue, 4 Nov 2008 23:33:20 +0100
Subject: [coreboot] and/or busybox issue with alix2c3 serial console
In-Reply-To: <ec3a010b0811041124w36215691ib93bd03f0685f245@mail.gmail.com>
References: <200811041938.33674.leroi.lists@gmail.com>
	<F0B48C010E8340469B1F9167E7EA3086@chimp>
	<13426df10811041036yde0bea0k5cab70ccb6bc0493@mail.gmail.com>
	<20081104184501.20806.qmail@stuge.se>
	<ec3a010b0811041059l1331410aq3bac223046cdfe74@mail.gmail.com>
	<13426df10811041104h269709b3g54337407c05f7d92@mail.gmail.com>
	<ec3a010b0811041124w36215691ib93bd03f0685f245@mail.gmail.com>
Message-ID: <20081104223320.18627.qmail@stuge.se>

Roman Yeryomin wrote:
> serial interrupt counter doesn't change if you are talking about that

But it does change with tinybios?

msrtool getting closer.. Hacked on it at the airport.


//Peter



From leroi.lists at gmail.com  Wed Nov  5 00:08:10 2008
From: leroi.lists at gmail.com (Roman Yeryomin)
Date: Wed, 5 Nov 2008 01:08:10 +0200
Subject: [coreboot] and/or busybox issue with alix2c3 serial console
In-Reply-To: <13426df10811041403m25762a5cx2f35ddf38fd9e1dd@mail.gmail.com>
References: <200811041938.33674.leroi.lists@gmail.com>
	<491097B7.4010901@amd.com>
	<ec3a010b0811041047sdef307cq2c0ab830d0a102e3@mail.gmail.com>
	<20081104203656.GC5424@cosmic.amd.com>
	<13426df10811041317n3e1b6462hbcd0a608591753f9@mail.gmail.com>
	<20081104212802.GA30213@localdomain>
	<13426df10811041330n4e48d63t1191ad17aadf8a00@mail.gmail.com>
	<20081104214250.GA31608@localdomain>
	<ec3a010b0811041359x590136a2x83cd16af01959753@mail.gmail.com>
	<13426df10811041403m25762a5cx2f35ddf38fd9e1dd@mail.gmail.com>
Message-ID: <ec3a010b0811041508y673b7532u428b87ca181614d5@mail.gmail.com>

On Wed, Nov 5, 2008 at 12:03 AM, ron minnich <rminnich at gmail.com> wrote:
> On Tue, Nov 4, 2008 at 1:59 PM, Roman Yeryomin <leroi.lists at gmail.com> wrote:
>
>> tried
>> no luck
>> Ron, do you need some output from that?
>
> summary:
> voyage linux serial console works with two versions of v3
> busybox serial console fails with two versions of v3
> we get kernel messages for all four combinations.
> they all boot and the network works.
> For each one, an ls -l of /dev/console and /dev/ttyS0 look correct.
>
> Well ...  ok. Send me dmesg for voyage and busy with newest v3
>
> It's a userland problem, I think, but I am not sure what.

Ok, sending a bit more than you asked but I think it will be
interesting to compare.
"mod" in filenames means with my modification I've mentioned before.
I can do clean build if it's needed.


Roman
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: debug-factory-busy.txt
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20081105/da590ff8/attachment.txt>
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: debug-v3r978mod-busy.txt
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20081105/da590ff8/attachment-0001.txt>
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: debug-v3r978mod-voyage.txt
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20081105/da590ff8/attachment-0002.txt>
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: debug-ward-busy.txt
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20081105/da590ff8/attachment-0003.txt>

From leroi.lists at gmail.com  Wed Nov  5 00:08:50 2008
From: leroi.lists at gmail.com (Roman Yeryomin)
Date: Wed, 5 Nov 2008 01:08:50 +0200
Subject: [coreboot] and/or busybox issue with alix2c3 serial console
In-Reply-To: <20081104223320.18627.qmail@stuge.se>
References: <200811041938.33674.leroi.lists@gmail.com>
	<F0B48C010E8340469B1F9167E7EA3086@chimp>
	<13426df10811041036yde0bea0k5cab70ccb6bc0493@mail.gmail.com>
	<20081104184501.20806.qmail@stuge.se>
	<ec3a010b0811041059l1331410aq3bac223046cdfe74@mail.gmail.com>
	<13426df10811041104h269709b3g54337407c05f7d92@mail.gmail.com>
	<ec3a010b0811041124w36215691ib93bd03f0685f245@mail.gmail.com>
	<20081104223320.18627.qmail@stuge.se>
Message-ID: <ec3a010b0811041508y13a11b1fp749eab323716687e@mail.gmail.com>

On Wed, Nov 5, 2008 at 12:33 AM, Peter Stuge <peter at stuge.se> wrote:
> Roman Yeryomin wrote:
>> serial interrupt counter doesn't change if you are talking about that
>
> But it does change with tinybios?
>

yes


Roman



From leroi.lists at gmail.com  Wed Nov  5 00:23:35 2008
From: leroi.lists at gmail.com (Roman Yeryomin)
Date: Wed, 5 Nov 2008 01:23:35 +0200
Subject: [coreboot] and/or busybox issue with alix2c3 serial console
In-Reply-To: <13426df10811041416h7c0fa3edo1e706e0d723446d9@mail.gmail.com>
References: <200811041938.33674.leroi.lists@gmail.com>
	<20081104203656.GC5424@cosmic.amd.com>
	<13426df10811041317n3e1b6462hbcd0a608591753f9@mail.gmail.com>
	<20081104212802.GA30213@localdomain>
	<13426df10811041330n4e48d63t1191ad17aadf8a00@mail.gmail.com>
	<ec3a010b0811041340q202fc54fkecd64f6099622846@mail.gmail.com>
	<13426df10811041341v413eff06g3f7fc3ad663dbc1e@mail.gmail.com>
	<20081104215327.GE5424@cosmic.amd.com>
	<ec3a010b0811041404m2ca70564v4b31fb31458437c2@mail.gmail.com>
	<13426df10811041416h7c0fa3edo1e706e0d723446d9@mail.gmail.com>
Message-ID: <ec3a010b0811041523l61cebd5dw8586ee413c13257e@mail.gmail.com>

On Wed, Nov 5, 2008 at 12:16 AM, ron minnich <rminnich at gmail.com> wrote:
> On Tue, Nov 4, 2008 at 2:04 PM, Roman Yeryomin <leroi.lists at gmail.com> wrote:
>
>> I agree that there is something to do with busybox also but it still
>> works with factory bios! Why?
>
>
> OK so what we have is a /dev/console issue.
>
> Try to write a simple script:
>
> touch /tmp/ALIVE
>
> Make that script be your init (make sure to set the x bits and put the
> right #! shell for first line). Let's verify that we can run a simple
> script, that may help with diagnosis

I can do that directly in preinit just after proc, sys and tmpfs are
mounted but before everything else.
For now I did

touch /tmp/alive
echo "ALIVE" > /tmp/alive2

and get

ls -la /tmp/alive*
-rw-r--r--    1 root     root            0 Nov 30  1999 /tmp/alive
-rw-r--r--    1 root     root          131 Nov 30  1999 /tmp/alive2

cat /tmp/alive2
ALIVE
[sighandler]: No more events to be processed, quitting.
[cleanup]: Waiting for children.
[cleanup]: All children terminated.

I don't understand where these three lines came from but they are there.


Roman



From rminnich at gmail.com  Wed Nov  5 00:41:23 2008
From: rminnich at gmail.com (ron minnich)
Date: Tue, 4 Nov 2008 15:41:23 -0800
Subject: [coreboot] and/or busybox issue with alix2c3 serial console
In-Reply-To: <ec3a010b0811041508y673b7532u428b87ca181614d5@mail.gmail.com>
References: <200811041938.33674.leroi.lists@gmail.com>
	<ec3a010b0811041047sdef307cq2c0ab830d0a102e3@mail.gmail.com>
	<20081104203656.GC5424@cosmic.amd.com>
	<13426df10811041317n3e1b6462hbcd0a608591753f9@mail.gmail.com>
	<20081104212802.GA30213@localdomain>
	<13426df10811041330n4e48d63t1191ad17aadf8a00@mail.gmail.com>
	<20081104214250.GA31608@localdomain>
	<ec3a010b0811041359x590136a2x83cd16af01959753@mail.gmail.com>
	<13426df10811041403m25762a5cx2f35ddf38fd9e1dd@mail.gmail.com>
	<ec3a010b0811041508y673b7532u428b87ca181614d5@mail.gmail.com>
Message-ID: <13426df10811041541k63437aeep1293d3a1e2d6a537@mail.gmail.com>

This makes no sense at all. I would have guessed that busybox workd
and voyage did not!

voyage:
cat /proc/tty/driver/serial

serinfo:1.0 driver revision:
0: uart:16550A port:000003F8 irq:0 tx:4513 rx:139 oe:3 RTS|CTS|DTR|DSR|CD
1: uart:unknown port:000002F8 irq:3


cat /proc/interrupts

           CPU0
  0:     265852    XT-PIC-XT        timer
  2:          0    XT-PIC-XT        cascade
 10:        116    XT-PIC-XT        eth0
 11:          1    XT-PIC-XT        ehci_hcd:usb1, ohci_hcd:usb2

ok, uart has irq 0 and there is no irq for it.

busy:
cat /proc/tty/driver/serial

serinfo:1.0 driver revision:
0: uart:16550A port:000003F8 irq:4 tx:0 rx:0 RTS|CTS|DTR|DSR|CD
1: uart:unknown port:000002F8 irq:3


cat /proc/interrupts

           CPU0
  0:       6011    XT-PIC-XT        timer
  2:          0    XT-PIC-XT        cascade
  4:          0    XT-PIC-XT        serial

actually makes sense and compares to factory:
serinfo:1.0 driver revision:
0: uart:16550A port:000003F8 irq:4 tx:825 rx:7 RTS|CTS|DTR|DSR|CD
1: uart:unknown port:000002F8 irq:3


cat /proc/interrupts

           CPU0
  0:      11770    XT-PIC-XT        timer
  2:          0    XT-PIC-XT        cascade
  4:         70    XT-PIC-XT        serial

but voyage gets this:
Console: colour dummy device 80x25
console [ttyS0] enabled

busy gets
Console: colour dummy device 80x25
console [tty0] enabled
console [ttyS0] enabled

busy+v3 gets
Console: colour dummy device 80x25
console [ttyS0] enabled

oh boy. . voyage/v3 gets this:
Serial: 8250/16550 driver $Revision: 1.90 $ 2 ports, IRQ sharing enabled
?serial8250: ttyS0 at I/O 0x3f8 (irq = 0) is a 16550A

this is I am pretty certain an IRQ foulup. Why are busy and voyage so
totally different?

how do the .config files compare? does factory bios have ACPI (it
would appear not).

ron

From rminnich at gmail.com  Wed Nov  5 00:43:50 2008
From: rminnich at gmail.com (ron minnich)
Date: Tue, 4 Nov 2008 15:43:50 -0800
Subject: [coreboot] and/or busybox issue with alix2c3 serial console
In-Reply-To: <ec3a010b0811041523l61cebd5dw8586ee413c13257e@mail.gmail.com>
References: <200811041938.33674.leroi.lists@gmail.com>
	<13426df10811041317n3e1b6462hbcd0a608591753f9@mail.gmail.com>
	<20081104212802.GA30213@localdomain>
	<13426df10811041330n4e48d63t1191ad17aadf8a00@mail.gmail.com>
	<ec3a010b0811041340q202fc54fkecd64f6099622846@mail.gmail.com>
	<13426df10811041341v413eff06g3f7fc3ad663dbc1e@mail.gmail.com>
	<20081104215327.GE5424@cosmic.amd.com>
	<ec3a010b0811041404m2ca70564v4b31fb31458437c2@mail.gmail.com>
	<13426df10811041416h7c0fa3edo1e706e0d723446d9@mail.gmail.com>
	<ec3a010b0811041523l61cebd5dw8586ee413c13257e@mail.gmail.com>
Message-ID: <13426df10811041543i4001fcbfv7f80a417a7b9d6d6@mail.gmail.com>

On Tue, Nov 4, 2008 at 3:23 PM, Roman Yeryomin <leroi.lists at gmail.com> wrote:
> On Wed, Nov 5, 2008 at 12:16 AM, ron minnich <rminnich at gmail.com> wrote:
>> On Tue, Nov 4, 2008 at 2:04 PM, Roman Yeryomin <leroi.lists at gmail.com> wrote:
>>
>>> I agree that there is something to do with busybox also but it still
>>> works with factory bios! Why?
>>
>>
>> OK so what we have is a /dev/console issue.
>>
>> Try to write a simple script:
>>
>> touch /tmp/ALIVE
>>
>> Make that script be your init (make sure to set the x bits and put the
>> right #! shell for first line). Let's verify that we can run a simple
>> script, that may help with diagnosis
>
> I can do that directly in preinit just after proc, sys and tmpfs are
> mounted but before everything else.
> For now I did
>
> touch /tmp/alive
> echo "ALIVE" > /tmp/alive2
>
> and get
>
> ls -la /tmp/alive*
> -rw-r--r--    1 root     root            0 Nov 30  1999 /tmp/alive
> -rw-r--r--    1 root     root          131 Nov 30  1999 /tmp/alive2
>
> cat /tmp/alive2
> ALIVE
> [sighandler]: No more events to be processed, quitting.
> [cleanup]: Waiting for children.
> [cleanup]: All children terminated.
>
> I don't understand where these three lines came from but they are there.
>

probably some busybox stuff.

ok, I am shot for the day. Will wait for someone else to have a bright
idea. None of this makes sense.

I'll think on it overniight.

ron



From leroi.lists at gmail.com  Wed Nov  5 00:57:18 2008
From: leroi.lists at gmail.com (Roman Yeryomin)
Date: Wed, 5 Nov 2008 01:57:18 +0200
Subject: [coreboot] and/or busybox issue with alix2c3 serial console
In-Reply-To: <13426df10811041541k63437aeep1293d3a1e2d6a537@mail.gmail.com>
References: <200811041938.33674.leroi.lists@gmail.com>
	<20081104203656.GC5424@cosmic.amd.com>
	<13426df10811041317n3e1b6462hbcd0a608591753f9@mail.gmail.com>
	<20081104212802.GA30213@localdomain>
	<13426df10811041330n4e48d63t1191ad17aadf8a00@mail.gmail.com>
	<20081104214250.GA31608@localdomain>
	<ec3a010b0811041359x590136a2x83cd16af01959753@mail.gmail.com>
	<13426df10811041403m25762a5cx2f35ddf38fd9e1dd@mail.gmail.com>
	<ec3a010b0811041508y673b7532u428b87ca181614d5@mail.gmail.com>
	<13426df10811041541k63437aeep1293d3a1e2d6a537@mail.gmail.com>
Message-ID: <ec3a010b0811041557k12ff21e7v70b80678ef1982a3@mail.gmail.com>

On Wed, Nov 5, 2008 at 1:41 AM, ron minnich <rminnich at gmail.com> wrote:
> how do the .config files compare? does factory bios have ACPI (it
> would appear not).

what .config files?


Roman



From rminnich at gmail.com  Wed Nov  5 00:59:07 2008
From: rminnich at gmail.com (ron minnich)
Date: Tue, 4 Nov 2008 15:59:07 -0800
Subject: [coreboot] and/or busybox issue with alix2c3 serial console
In-Reply-To: <ec3a010b0811041557k12ff21e7v70b80678ef1982a3@mail.gmail.com>
References: <200811041938.33674.leroi.lists@gmail.com>
	<13426df10811041317n3e1b6462hbcd0a608591753f9@mail.gmail.com>
	<20081104212802.GA30213@localdomain>
	<13426df10811041330n4e48d63t1191ad17aadf8a00@mail.gmail.com>
	<20081104214250.GA31608@localdomain>
	<ec3a010b0811041359x590136a2x83cd16af01959753@mail.gmail.com>
	<13426df10811041403m25762a5cx2f35ddf38fd9e1dd@mail.gmail.com>
	<ec3a010b0811041508y673b7532u428b87ca181614d5@mail.gmail.com>
	<13426df10811041541k63437aeep1293d3a1e2d6a537@mail.gmail.com>
	<ec3a010b0811041557k12ff21e7v70b80678ef1982a3@mail.gmail.com>
Message-ID: <13426df10811041559v26628fbal7b99a0e98dddf897@mail.gmail.com>

On Tue, Nov 4, 2008 at 3:57 PM, Roman Yeryomin <leroi.lists at gmail.com> wrote:
> On Wed, Nov 5, 2008 at 1:41 AM, ron minnich <rminnich at gmail.com> wrote:
>> how do the .config files compare? does factory bios have ACPI (it
>> would appear not).
>
> what .config files?
>
>

kernel .config files

ron



From leroi.lists at gmail.com  Wed Nov  5 00:59:30 2008
From: leroi.lists at gmail.com (Roman Yeryomin)
Date: Wed, 5 Nov 2008 01:59:30 +0200
Subject: [coreboot] and/or busybox issue with alix2c3 serial console
In-Reply-To: <13426df10811041543i4001fcbfv7f80a417a7b9d6d6@mail.gmail.com>
References: <200811041938.33674.leroi.lists@gmail.com>
	<20081104212802.GA30213@localdomain>
	<13426df10811041330n4e48d63t1191ad17aadf8a00@mail.gmail.com>
	<ec3a010b0811041340q202fc54fkecd64f6099622846@mail.gmail.com>
	<13426df10811041341v413eff06g3f7fc3ad663dbc1e@mail.gmail.com>
	<20081104215327.GE5424@cosmic.amd.com>
	<ec3a010b0811041404m2ca70564v4b31fb31458437c2@mail.gmail.com>
	<13426df10811041416h7c0fa3edo1e706e0d723446d9@mail.gmail.com>
	<ec3a010b0811041523l61cebd5dw8586ee413c13257e@mail.gmail.com>
	<13426df10811041543i4001fcbfv7f80a417a7b9d6d6@mail.gmail.com>
Message-ID: <ec3a010b0811041559x7b743bf6oe24c06e234c83884@mail.gmail.com>

On Wed, Nov 5, 2008 at 1:43 AM, ron minnich <rminnich at gmail.com> wrote:
> On Tue, Nov 4, 2008 at 3:23 PM, Roman Yeryomin <leroi.lists at gmail.com> wrote:
>> On Wed, Nov 5, 2008 at 12:16 AM, ron minnich <rminnich at gmail.com> wrote:
>>> On Tue, Nov 4, 2008 at 2:04 PM, Roman Yeryomin <leroi.lists at gmail.com> wrote:
>>>
>>>> I agree that there is something to do with busybox also but it still
>>>> works with factory bios! Why?
>>>
>>>
>>> OK so what we have is a /dev/console issue.
>>>
>>> Try to write a simple script:
>>>
>>> touch /tmp/ALIVE
>>>
>>> Make that script be your init (make sure to set the x bits and put the
>>> right #! shell for first line). Let's verify that we can run a simple
>>> script, that may help with diagnosis
>>
>> I can do that directly in preinit just after proc, sys and tmpfs are
>> mounted but before everything else.
>> For now I did
>>
>> touch /tmp/alive
>> echo "ALIVE" > /tmp/alive2
>>
>> and get
>>
>> ls -la /tmp/alive*
>> -rw-r--r--    1 root     root            0 Nov 30  1999 /tmp/alive
>> -rw-r--r--    1 root     root          131 Nov 30  1999 /tmp/alive2
>>
>> cat /tmp/alive2
>> ALIVE
>> [sighandler]: No more events to be processed, quitting.
>> [cleanup]: Waiting for children.
>> [cleanup]: All children terminated.
>>
>> I don't understand where these three lines came from but they are there.
>>
>
> probably some busybox stuff.
>
> ok, I am shot for the day. Will wait for someone else to have a bright
> idea. None of this makes sense.
>
> I'll think on it overniight.

Well, this is why I'm here -- for a bright idea :)


Roman



From rminnich at gmail.com  Wed Nov  5 01:01:48 2008
From: rminnich at gmail.com (ron minnich)
Date: Tue, 4 Nov 2008 16:01:48 -0800
Subject: [coreboot] and/or busybox issue with alix2c3 serial console
In-Reply-To: <ec3a010b0811041559x7b743bf6oe24c06e234c83884@mail.gmail.com>
References: <200811041938.33674.leroi.lists@gmail.com>
	<13426df10811041330n4e48d63t1191ad17aadf8a00@mail.gmail.com>
	<ec3a010b0811041340q202fc54fkecd64f6099622846@mail.gmail.com>
	<13426df10811041341v413eff06g3f7fc3ad663dbc1e@mail.gmail.com>
	<20081104215327.GE5424@cosmic.amd.com>
	<ec3a010b0811041404m2ca70564v4b31fb31458437c2@mail.gmail.com>
	<13426df10811041416h7c0fa3edo1e706e0d723446d9@mail.gmail.com>
	<ec3a010b0811041523l61cebd5dw8586ee413c13257e@mail.gmail.com>
	<13426df10811041543i4001fcbfv7f80a417a7b9d6d6@mail.gmail.com>
	<ec3a010b0811041559x7b743bf6oe24c06e234c83884@mail.gmail.com>
Message-ID: <13426df10811041601g73e21d4ane791cb00c6d8b9ed@mail.gmail.com>

depending on how daring you feel, you can (I have done this) do an
open of /dev/console IN THE KERNEL, and see what happens. But based on
what we're seeing so far, I am pretty strongly convinced there is an
interrupt issue here.

but seeing the .config for the voyage and busy kernels would help. You
can always boot them and hopefull cat /proc/config.gz will work.


ron



From leroi.lists at gmail.com  Wed Nov  5 01:06:01 2008
From: leroi.lists at gmail.com (Roman Yeryomin)
Date: Wed, 5 Nov 2008 02:06:01 +0200
Subject: [coreboot] and/or busybox issue with alix2c3 serial console
In-Reply-To: <13426df10811041559v26628fbal7b99a0e98dddf897@mail.gmail.com>
References: <200811041938.33674.leroi.lists@gmail.com>
	<20081104212802.GA30213@localdomain>
	<13426df10811041330n4e48d63t1191ad17aadf8a00@mail.gmail.com>
	<20081104214250.GA31608@localdomain>
	<ec3a010b0811041359x590136a2x83cd16af01959753@mail.gmail.com>
	<13426df10811041403m25762a5cx2f35ddf38fd9e1dd@mail.gmail.com>
	<ec3a010b0811041508y673b7532u428b87ca181614d5@mail.gmail.com>
	<13426df10811041541k63437aeep1293d3a1e2d6a537@mail.gmail.com>
	<ec3a010b0811041557k12ff21e7v70b80678ef1982a3@mail.gmail.com>
	<13426df10811041559v26628fbal7b99a0e98dddf897@mail.gmail.com>
Message-ID: <ec3a010b0811041606o2f1b61gfcd1bd70f31c46f2@mail.gmail.com>

On Wed, Nov 5, 2008 at 1:59 AM, ron minnich <rminnich at gmail.com> wrote:
> On Tue, Nov 4, 2008 at 3:57 PM, Roman Yeryomin <leroi.lists at gmail.com> wrote:
>> On Wed, Nov 5, 2008 at 1:41 AM, ron minnich <rminnich at gmail.com> wrote:
>>> how do the .config files compare? does factory bios have ACPI (it
>>> would appear not).
>>
>> what .config files?
>>
>
> kernel .config files

you mean voyage and busybox?
I think it doesn't really matter because other linux distributions
based on busybox (and meant specially for alix boards!) don't work (I
mean serial console) with coreboot too.
But I can try to figure out if you want.


Roman



From c-d.hailfinger.devel.2006 at gmx.net  Wed Nov  5 01:09:14 2008
From: c-d.hailfinger.devel.2006 at gmx.net (Carl-Daniel Hailfinger)
Date: Wed, 05 Nov 2008 01:09:14 +0100
Subject: [coreboot] pci_device.c cleanup
In-Reply-To: <2831fecf0811041204u59f2ccc9h5cb18f5e96c5fb@mail.gmail.com>
References: <2831fecf0811041204u59f2ccc9h5cb18f5e96c5fb@mail.gmail.com>
Message-ID: <4910E42A.2060109@gmx.net>

On 04.11.2008 21:04, Myles Watson wrote:
> This patch clarifies/adds comments and changes names in device/pci_device.c
>
> It also changes %p debug statements in various places.  I think they get in
> the way of diffs when you have log files to compare.  I don't want to see
> the
> allocation differences most of the time.  I turned most of them into NULL
> checks.  If they were supposed to be "Where are we in device allocation?"
> checks, we could make them into that too.
>
> It's a work-in-progress. Comments welcome.
>
> I think most of the changes are self explanatory, but this one might not be:
>
> If you are reading all the BARs from a device, and you come to a 64-bit BAR.
> No matter why you skip it, you should skip it as a 64-bit BAR, and not try
> to
> read the upper half as the next 32-bit BAR.
>
> Because of that, set the 64-bit flag IORESOURCE_PCI64 early, and don't clear
> it on return.
>
> Signed-off-by: Myles Watson <mylesgw at gmail.com>
>
> @@ -899,18 +924,18 @@
>   * Given a linked list of PCI device structures and a devfn number, find the
>   * device structure correspond to the devfn, if present. This function also
>   * removes the device structure from the linked list.
> - *
> + * 
>   * @param list The device structure list.
>   * @param devfn A device/function number.
>   * @return Pointer to the device structure found or NULL of we have not
>   *	   allocated a device for this devfn yet.
>   */
> -static struct device *pci_scan_get_dev(struct device **list, unsigned int devfn)
> +static struct device *pci_get_dev(struct device **list, unsigned int devfn)
>  {
>  	struct device *dev;
>  	dev = 0;
> -	printk(BIOS_SPEW, "%s: list is %p, *list is %p\n", __func__, list,
> -	       *list);
> +	printk(BIOS_SPEW, "%s: list is %sNULL, *list is %sNULL\n", __func__,
> +		list?"NOT ":"", *list?"NOT ":"");
>  	for (; *list; list = &(*list)->sibling) {
>  		printk(BIOS_SPEW, "%s: check dev %s \n", __func__,
>  		       (*list)->dtsname);
>   

Was that change really intentional? Sure, it makes diffing easier, but
some diagnostics (especially considering the still buggy device
enumeration) are now more difficult.


> @@ -1043,15 +1068,22 @@
>  	dev->irq_pin = pci_read_config8(dev, PCI_INTERRUPT_PIN);
>  	dev->min_gnt = pci_read_config8(dev, PCI_MIN_GNT);
>  	dev->max_lat = pci_read_config8(dev, PCI_MAX_LAT);
> -#warning Per-device subsystem ID should only be read from the device if none has been specified for the device in the dts.
> -	dev->subsystem_vendor = pci_read_config16(dev, PCI_SUBSYSTEM_VENDOR_ID);
> -	dev->subsystem_device = pci_read_config16(dev, PCI_SUBSYSTEM_ID);
>  
> -	/* Store the interesting information in the device structure. */
> +	/*Per-device subsystem ID should only be read from the device if none
> +	 * has been specified for the device in the dts.
> +	 */
> +	if (!dev->subsystem_vendor && !dev->subsystem_device) {
> +		dev->subsystem_vendor = 
> +				pci_read_config16(dev, PCI_SUBSYSTEM_VENDOR_ID);
> +		dev->subsystem_device = 
> +				pci_read_config16(dev, PCI_SUBSYSTEM_ID);
> +	}
> +
>  	dev->id.type = DEVICE_ID_PCI;
>  	dev->id.pci.vendor = id & 0xffff;
>  	dev->id.pci.device = (id >> 16) & 0xffff;
>  	dev->hdr_type = hdr_type;
> +
>  	/* Class code, the upper 3 bytes of PCI_CLASS_REVISION. */
>  	dev->class = class >> 8;
>  
>   

Hm. Although you fixed the code as indicated in the #warning, I fear
there's still something missing and that's the reason the warning was
there. Where do we set the subsystem ID of the real device (not struct
device)?


> @@ -1105,6 +1135,8 @@
>  
>  	printk(BIOS_DEBUG, "%s start bus %p, bus->dev %p\n", __func__, bus,
>  	       bus->dev);
> +
> +#warning This check needs checking.
>  	if (bus->dev->path.type != DEVICE_PATH_PCI_BUS)
>  		printk(BIOS_ERR, "ERROR: pci_scan_bus called with incorrect "
>  		       "bus->dev->path.type, path is %s\n", dev_path(bus->dev));
>   

If you manage to fix the device code in a way which doesn't trigger this
anymore, your static devices will suddenly be found. Since this check is
only triggered if your code and/or device tree is really buggy, we could
upgrade it to a die().


Regards,
Carl-Daniel

-- 
http://www.hailfinger.org/




From leroi.lists at gmail.com  Wed Nov  5 01:21:44 2008
From: leroi.lists at gmail.com (Roman Yeryomin)
Date: Wed, 5 Nov 2008 02:21:44 +0200
Subject: [coreboot] and/or busybox issue with alix2c3 serial console
In-Reply-To: <13426df10811041601g73e21d4ane791cb00c6d8b9ed@mail.gmail.com>
References: <200811041938.33674.leroi.lists@gmail.com>
	<ec3a010b0811041340q202fc54fkecd64f6099622846@mail.gmail.com>
	<13426df10811041341v413eff06g3f7fc3ad663dbc1e@mail.gmail.com>
	<20081104215327.GE5424@cosmic.amd.com>
	<ec3a010b0811041404m2ca70564v4b31fb31458437c2@mail.gmail.com>
	<13426df10811041416h7c0fa3edo1e706e0d723446d9@mail.gmail.com>
	<ec3a010b0811041523l61cebd5dw8586ee413c13257e@mail.gmail.com>
	<13426df10811041543i4001fcbfv7f80a417a7b9d6d6@mail.gmail.com>
	<ec3a010b0811041559x7b743bf6oe24c06e234c83884@mail.gmail.com>
	<13426df10811041601g73e21d4ane791cb00c6d8b9ed@mail.gmail.com>
Message-ID: <ec3a010b0811041621w62f90e7fm24ff475d83158ced@mail.gmail.com>

On Wed, Nov 5, 2008 at 2:01 AM, ron minnich <rminnich at gmail.com> wrote:
> depending on how daring you feel, you can (I have done this) do an
> open of /dev/console IN THE KERNEL, and see what happens. But based on
> what we're seeing so far, I am pretty strongly convinced there is an
> interrupt issue here.

well.. I'm not really good programmer, but I can dig there and see
what I can do, or you can give me some patch I can try...
BTW some time ago, when I was starting to play with coreboot and
already had this issue (there are posts in this list about month ago)
I've asked Pascal Dornier (person behind pcengines - alix board maker)
how he sets up uart in his bios (as seems like he wrote it himself)
and here is what he replied (I've already posted this):

>seems like there is a bug in coreboot and it's not setting uart the
>right way. I can see all the coreboot and kernel messages in console but
>right after init starts serial console is lost (linux keeps running
>normally).
>So.. could you share how you set up uarts in your tinyBIOS? Which
>UART[x]_MOD, UART[x]_DON and UART[x]_CONF bits you set?

After init -> changes to Linux driver, or does it still use Int 10 + Int 16 ?
My BIOS does a redirect of these BIOS interrupts to the serial console.
Once the Linux kernel starts it has to take care of the serial console itself.

I didn't reply him because didn't know what to say.
tinybios source code is available on pcengines website but it's
written in assembler (and I don't understand anything there) -- maybe
it can help somehow?


Roman



From jordan.crouse at amd.com  Wed Nov  5 02:24:26 2008
From: jordan.crouse at amd.com (Jordan Crouse)
Date: Tue, 4 Nov 2008 18:24:26 -0700
Subject: [coreboot] and/or busybox issue with alix2c3 serial console
In-Reply-To: <ec3a010b0811041621w62f90e7fm24ff475d83158ced@mail.gmail.com>
References: <ec3a010b0811041340q202fc54fkecd64f6099622846@mail.gmail.com>
	<13426df10811041341v413eff06g3f7fc3ad663dbc1e@mail.gmail.com>
	<20081104215327.GE5424@cosmic.amd.com>
	<ec3a010b0811041404m2ca70564v4b31fb31458437c2@mail.gmail.com>
	<13426df10811041416h7c0fa3edo1e706e0d723446d9@mail.gmail.com>
	<ec3a010b0811041523l61cebd5dw8586ee413c13257e@mail.gmail.com>
	<13426df10811041543i4001fcbfv7f80a417a7b9d6d6@mail.gmail.com>
	<ec3a010b0811041559x7b743bf6oe24c06e234c83884@mail.gmail.com>
	<13426df10811041601g73e21d4ane791cb00c6d8b9ed@mail.gmail.com>
	<ec3a010b0811041621w62f90e7fm24ff475d83158ced@mail.gmail.com>
Message-ID: <20081105012426.GD9994@cosmic.amd.com>

It just occured to me, I use a busybox based image for my Geode... :)

I gzipped up the ext2 filesystem and put it here:

http://www.infradead.org/~jcrouse/geode.rootfs.ext2.gz

This uses busybox 1.9.2 and kernel 2.6.27.   There is a menu.lst in /boot,
but the root points to the wrong place.  Use 

kernel /boot/bzImage root=/dev/hda1 console=tty0 console=ttyS0,115200

I just booted it with a fresh version of v3 and all was well.  Good
luck.

Jordan

-- 
Jordan Crouse
Systems Software Development Engineer 
Advanced Micro Devices, Inc.




From hansolofalcon at worldnet.att.net  Wed Nov  5 03:04:21 2008
From: hansolofalcon at worldnet.att.net (Gregg C Levine)
Date: Tue, 4 Nov 2008 21:04:21 -0500
Subject: [coreboot] LAB question
Message-ID: <3173667609B54C429D53E1F9E457B1F8@who8>

Hello!
As always I am looking at new ideas.
One that has occurred to me on numerous occasions is that of the idea of
using Linux as a boot loader.

I know it has been discussed on several occasions on this list, however I
don't recall what was resolved about it. What has been resolved about it?
And on what machines does it work? (This includes chipsets.)
--
Gregg C Levine hansolofalcon at worldnet.att.net
"The Force will be with you always." Obi-Wan Kenobi
? 






From mylesgw at gmail.com  Wed Nov  5 03:58:52 2008
From: mylesgw at gmail.com (Myles Watson)
Date: Tue, 4 Nov 2008 19:58:52 -0700
Subject: [coreboot] pci_device.c cleanup
In-Reply-To: <4910E42A.2060109@gmx.net>
References: <2831fecf0811041204u59f2ccc9h5cb18f5e96c5fb@mail.gmail.com>
	<4910E42A.2060109@gmx.net>
Message-ID: <F5BEB1AEBFF4410F87FF1B8F232AFA51@chimp>



> -----Original Message-----
> From: Carl-Daniel Hailfinger [mailto:c-d.hailfinger.devel.2006 at gmx.net]
> Sent: Tuesday, November 04, 2008 5:09 PM
> To: Myles Watson
> Cc: Coreboot
> Subject: Re: [coreboot] pci_device.c cleanup
> 
> On 04.11.2008 21:04, Myles Watson wrote:
> > This patch clarifies/adds comments and changes names in
> device/pci_device.c
> >
> > It also changes %p debug statements in various places.  I think they get
> in
> > the way of diffs when you have log files to compare.  I don't want to
> see
> > the
> > allocation differences most of the time.  I turned most of them into
> NULL
> > checks.  If they were supposed to be "Where are we in device
> allocation?"
> > checks, we could make them into that too.
> >
> > It's a work-in-progress. Comments welcome.
> >
> > I think most of the changes are self explanatory, but this one might not
> be:
> >
> > If you are reading all the BARs from a device, and you come to a 64-bit
> BAR.
> > No matter why you skip it, you should skip it as a 64-bit BAR, and not
> try
> > to
> > read the upper half as the next 32-bit BAR.
> >
> > Because of that, set the 64-bit flag IORESOURCE_PCI64 early, and don't
> clear
> > it on return.
> >
> > Signed-off-by: Myles Watson <mylesgw at gmail.com>
> >
> > @@ -899,18 +924,18 @@
> >   * Given a linked list of PCI device structures and a devfn number,
> find the
> >   * device structure correspond to the devfn, if present. This function
> also
> >   * removes the device structure from the linked list.
> > - *
> > + *
> >   * @param list The device structure list.
> >   * @param devfn A device/function number.
> >   * @return Pointer to the device structure found or NULL of we have not
> >   *	   allocated a device for this devfn yet.
> >   */
> > -static struct device *pci_scan_get_dev(struct device **list, unsigned
> int devfn)
> > +static struct device *pci_get_dev(struct device **list, unsigned int
> devfn)
> >  {
> >  	struct device *dev;
> >  	dev = 0;
> > -	printk(BIOS_SPEW, "%s: list is %p, *list is %p\n", __func__, list,
> > -	       *list);
> > +	printk(BIOS_SPEW, "%s: list is %sNULL, *list is %sNULL\n", __func__,
> > +		list?"NOT ":"", *list?"NOT ":"");
> >  	for (; *list; list = &(*list)->sibling) {
> >  		printk(BIOS_SPEW, "%s: check dev %s \n", __func__,
> >  		       (*list)->dtsname);
> >
> 
> Was that change really intentional? Sure, it makes diffing easier, but
> some diagnostics (especially considering the still buggy device
> enumeration) are now more difficult.

Since this is looking through the list of children, and the function prints
out the dtsname of each child, I didn't find the actual pointer to be
useful.  The dtsname is much more useful.

> 
> > @@ -1043,15 +1068,22 @@
> >  	dev->irq_pin = pci_read_config8(dev, PCI_INTERRUPT_PIN);
> >  	dev->min_gnt = pci_read_config8(dev, PCI_MIN_GNT);
> >  	dev->max_lat = pci_read_config8(dev, PCI_MAX_LAT);
> > -#warning Per-device subsystem ID should only be read from the device if
> none has been specified for the device in the dts.
> > -	dev->subsystem_vendor = pci_read_config16(dev,
> PCI_SUBSYSTEM_VENDOR_ID);
> > -	dev->subsystem_device = pci_read_config16(dev, PCI_SUBSYSTEM_ID);
> >
> > -	/* Store the interesting information in the device structure. */
> > +	/*Per-device subsystem ID should only be read from the device if
> none
> > +	 * has been specified for the device in the dts.
> > +	 */
> > +	if (!dev->subsystem_vendor && !dev->subsystem_device) {
> > +		dev->subsystem_vendor =
> > +				pci_read_config16(dev,
PCI_SUBSYSTEM_VENDOR_ID);
> > +		dev->subsystem_device =
> > +				pci_read_config16(dev, PCI_SUBSYSTEM_ID);
> > +	}
> > +
> >  	dev->id.type = DEVICE_ID_PCI;
> >  	dev->id.pci.vendor = id & 0xffff;
> >  	dev->id.pci.device = (id >> 16) & 0xffff;
> >  	dev->hdr_type = hdr_type;
> > +
> >  	/* Class code, the upper 3 bytes of PCI_CLASS_REVISION. */
> >  	dev->class = class >> 8;
> >
> >
> 
> Hm. Although you fixed the code as indicated in the #warning, I fear
> there's still something missing and that's the reason the warning was
> there. Where do we set the subsystem ID of the real device (not struct
> device)?

There's another place in the code where there's a warning that addresses
this same issue.  I didn't think we needed it in both places.

> 
> > @@ -1105,6 +1135,8 @@
> >
> >  	printk(BIOS_DEBUG, "%s start bus %p, bus->dev %p\n", __func__, bus,
> >  	       bus->dev);
> > +
> > +#warning This check needs checking.
> >  	if (bus->dev->path.type != DEVICE_PATH_PCI_BUS)
> >  		printk(BIOS_ERR, "ERROR: pci_scan_bus called with incorrect
"
> >  		       "bus->dev->path.type, path is %s\n", dev_path(bus-
> >dev));
> >
> 
> If you manage to fix the device code in a way which doesn't trigger this
> anymore, your static devices will suddenly be found. Since this check is
> only triggered if your code and/or device tree is really buggy, we could
> upgrade it to a die().

I realize it's a problem.  Since I removed a couple of the other warnings, I
thought I'd put one in this trouble spot.

Thanks for the review,

Myles




From c-d.hailfinger.devel.2006 at gmx.net  Wed Nov  5 04:01:49 2008
From: c-d.hailfinger.devel.2006 at gmx.net (Carl-Daniel Hailfinger)
Date: Wed, 05 Nov 2008 04:01:49 +0100
Subject: [coreboot] [PATCH] v3: Fix up PCI device code
Message-ID: <49110C9D.90405@gmx.net>

The current PCI device code calls pci_scan_bus with a PCI domain instead
of a PCI bus as parameter. That causes all sorts of havoc, including
double initialization of hardware and ignoring devices in the dts.

This patch attempts to fix these bugs, but it has other side effects.
Somehow, resource allocation is now skipped.

I'd appreciate logs with and without this patch for every target,
especially K8.

Signed-off-by: Carl-Daniel Hailfinger <c-d.hailfinger.devel.2006 at gmx.net>

Index: corebootv3-pci_scan_bus_nexttry_minimal_fixup/device/pci_device.c
===================================================================
--- corebootv3-pci_scan_bus_nexttry_minimal_fixup/device/pci_device.c	(Revision 980)
+++ corebootv3-pci_scan_bus_nexttry_minimal_fixup/device/pci_device.c	(Arbeitskopie)
@@ -1234,8 +1234,24 @@
 unsigned int pci_domain_scan_bus(struct device *dev, unsigned int curr_bus)
 {
 	printk(BIOS_SPEW, "pci_domain_scan_bus: calling pci_scan_bus\n");
-	/* There is only one link on this device, and it is always link 0. */
-	return pci_scan_bus(&dev->link[0], PCI_DEVFN(0, 0), 0xff, curr_bus);
+	/* There is only one link on a bus, and it is always link 0.
+	 * dev->link[0] for a PCI domain is the domain link.
+	 * The child of the domain link is the PCI bus device.
+	 * We want to scan the bus link of the PCI bus device.
+	 * dev->link[0].children->link[0] is that PCI bus link.
+	 * If there can be multiple PCI buses directly below a PCI domain,
+	 * we have to iterate over the PCI buses in a loop.
+	 */
+#if 1
+	return pci_scan_bus(&dev->link[0].children->link[0],
+				   PCI_DEVFN(0, 0), 0xff, curr_bus);
+#else
+	struct device *list;
+	for (list = dev->link[0].children; list; list = list->sibling)
+		curr_bus = pci_scan_bus(&list->link[0],
+				   PCI_DEVFN(0, 0), 0xff, curr_bus);
+	return curr_bus;
+#endif
 }
 
 /**


-- 
http://www.hailfinger.org/




From mylesgw at gmail.com  Wed Nov  5 04:12:51 2008
From: mylesgw at gmail.com (Myles Watson)
Date: Tue, 4 Nov 2008 20:12:51 -0700
Subject: [coreboot] [PATCH] v3: Fix up PCI device code
In-Reply-To: <49110C9D.90405@gmx.net>
References: <49110C9D.90405@gmx.net>
Message-ID: <F771A406968C413497DF14CB8C1BA58F@chimp>



> -----Original Message-----
> From: coreboot-bounces at coreboot.org [mailto:coreboot-bounces at coreboot.org]
> On Behalf Of Carl-Daniel Hailfinger
> Sent: Tuesday, November 04, 2008 8:02 PM
> To: Coreboot
> Subject: [coreboot] [PATCH] v3: Fix up PCI device code
> 
> The current PCI device code calls pci_scan_bus with a PCI domain instead
> of a PCI bus as parameter. That causes all sorts of havoc, including
> double initialization of hardware and ignoring devices in the dts.
> 
> This patch attempts to fix these bugs, but it has other side effects.
> Somehow, resource allocation is now skipped.
> 
> I'd appreciate logs with and without this patch for every target,
> especially K8.
> 
> Signed-off-by: Carl-Daniel Hailfinger <c-d.hailfinger.devel.2006 at gmx.net>
> 
> Index: corebootv3-pci_scan_bus_nexttry_minimal_fixup/device/pci_device.c
> ===================================================================
> --- corebootv3-pci_scan_bus_nexttry_minimal_fixup/device/pci_device.c
> 	(Revision 980)
> +++ corebootv3-pci_scan_bus_nexttry_minimal_fixup/device/pci_device.c
> 	(Arbeitskopie)
> @@ -1234,8 +1234,24 @@
>  unsigned int pci_domain_scan_bus(struct device *dev, unsigned int
> curr_bus)
>  {
>  	printk(BIOS_SPEW, "pci_domain_scan_bus: calling pci_scan_bus\n");
> -	/* There is only one link on this device, and it is always link 0.
> */
> -	return pci_scan_bus(&dev->link[0], PCI_DEVFN(0, 0), 0xff, curr_bus);
> +	/* There is only one link on a bus, and it is always link 0.
> +	 * dev->link[0] for a PCI domain is the domain link.
> +	 * The child of the domain link is the PCI bus device.

This is where it gets a little strange.  The domain has lots of children,
but none of them are a "pci bus device."  If you look at Stefan's old pngs
from v2, there were a lot more devices and children than there are in v3 so
far.  I think looking at the output of show_all_devs makes this clear.  Any
log that's been posted to the link will have that.

I'm still trying to understand the pci enumeration, which is why I was
cleaning up the pci_device code.

Thanks,
Myles




From rminnich at gmail.com  Wed Nov  5 04:56:27 2008
From: rminnich at gmail.com (ron minnich)
Date: Tue, 4 Nov 2008 19:56:27 -0800
Subject: [coreboot] [PATCH] v3: Fix up PCI device code
In-Reply-To: <49110C9D.90405@gmx.net>
References: <49110C9D.90405@gmx.net>
Message-ID: <13426df10811041956r112263ebi3bac16ab02f4a0ec@mail.gmail.com>

as noted, the device tree code is very tricky. We definitely don't
want this patch -- you are skipping around the child to the child ...
bad idea.

Myles and I are doing a very slow cleanup, as you are going to see
from a very slow stream of patches every couple days. But unwinding
this tangle is hard, and we're not going to go fast.

thanks

ron



From c-d.hailfinger.devel.2006 at gmx.net  Wed Nov  5 04:56:52 2008
From: c-d.hailfinger.devel.2006 at gmx.net (Carl-Daniel Hailfinger)
Date: Wed, 05 Nov 2008 04:56:52 +0100
Subject: [coreboot] [PATCH] v3: Fix up PCI device code
In-Reply-To: <F771A406968C413497DF14CB8C1BA58F@chimp>
References: <49110C9D.90405@gmx.net> <F771A406968C413497DF14CB8C1BA58F@chimp>
Message-ID: <49111984.2040009@gmx.net>

On 05.11.2008 04:12, Myles Watson wrote:
>   
>> -----Original Message-----
>> From: coreboot-bounces at coreboot.org [mailto:coreboot-bounces at coreboot.org]
>> On Behalf Of Carl-Daniel Hailfinger
>> Sent: Tuesday, November 04, 2008 8:02 PM
>> To: Coreboot
>> Subject: [coreboot] [PATCH] v3: Fix up PCI device code
>>
>> The current PCI device code calls pci_scan_bus with a PCI domain instead
>> of a PCI bus as parameter. That causes all sorts of havoc, including
>> double initialization of hardware and ignoring devices in the dts.
>>
>> This patch attempts to fix these bugs, but it has other side effects.
>> Somehow, resource allocation is now skipped.
>>
>> I'd appreciate logs with and without this patch for every target,
>> especially K8.
>>
>> Signed-off-by: Carl-Daniel Hailfinger <c-d.hailfinger.devel.2006 at gmx.net>
>>
>> Index: corebootv3-pci_scan_bus_nexttry_minimal_fixup/device/pci_device.c
>> ===================================================================
>> --- corebootv3-pci_scan_bus_nexttry_minimal_fixup/device/pci_device.c
>> 	(Revision 980)
>> +++ corebootv3-pci_scan_bus_nexttry_minimal_fixup/device/pci_device.c
>> 	(Arbeitskopie)
>> @@ -1234,8 +1234,24 @@
>>  unsigned int pci_domain_scan_bus(struct device *dev, unsigned int
>> curr_bus)
>>  {
>>  	printk(BIOS_SPEW, "pci_domain_scan_bus: calling pci_scan_bus\n");
>> -	/* There is only one link on this device, and it is always link 0.
>> */
>> -	return pci_scan_bus(&dev->link[0], PCI_DEVFN(0, 0), 0xff, curr_bus);
>> +	/* There is only one link on a bus, and it is always link 0.
>> +	 * dev->link[0] for a PCI domain is the domain link.
>> +	 * The child of the domain link is the PCI bus device.
>>     
>
> This is where it gets a little strange.  The domain has lots of children,
> but none of them are a "pci bus device."

At least for qemu in v3, the domain link has the PCI bus device as a
child. I can post logs to prove it.
That's also why I believe the various K8 board dts in the tree have an
incorrect structure.


> If you look at Stefan's old pngs
> from v2, there were a lot more devices and children than there are in v3 so
> far.  I think looking at the output of show_all_devs makes this clear.  Any
> log that's been posted to the link will have that.
>   

Yes, but AFAICS the structure of the configuration is different for v2
and v3.
show_all_devs also makes one bug of the current tree very visible: The
devices mentioned in the dts are listed twice. My patch makes them
appear only once, but the resources of the domain are somehow not
inherited by the bus and thus not available for the PCI devices.


> I'm still trying to understand the pci enumeration, which is why I was
> cleaning up the pci_device code.
>   

Thanks for that cleanup, it is appreciated.


Regards,
Carl-Daniel

-- 
http://www.hailfinger.org/




From rminnich at gmail.com  Wed Nov  5 05:12:47 2008
From: rminnich at gmail.com (ron minnich)
Date: Tue, 4 Nov 2008 20:12:47 -0800
Subject: [coreboot] [PATCH] v3: Fix up PCI device code
In-Reply-To: <49111984.2040009@gmx.net>
References: <49110C9D.90405@gmx.net> <F771A406968C413497DF14CB8C1BA58F@chimp>
	<49111984.2040009@gmx.net>
Message-ID: <13426df10811042012y4c4f703bxb84e1d3ab6d6cd1b@mail.gmail.com>

I am glad you are scanning that code. We need more people scanning
but, more important, we need people writing docs. If somebody wants to
take a look at (e.g.) pci1234 and document what it does that is always
good. We can then compile the writeups into a book.

ron



From rminnich at gmail.com  Wed Nov  5 05:17:40 2008
From: rminnich at gmail.com (ron minnich)
Date: Tue, 4 Nov 2008 20:17:40 -0800
Subject: [coreboot] and/or busybox issue with alix2c3 serial console
In-Reply-To: <20081105012426.GD9994@cosmic.amd.com>
References: <ec3a010b0811041340q202fc54fkecd64f6099622846@mail.gmail.com>
	<20081104215327.GE5424@cosmic.amd.com>
	<ec3a010b0811041404m2ca70564v4b31fb31458437c2@mail.gmail.com>
	<13426df10811041416h7c0fa3edo1e706e0d723446d9@mail.gmail.com>
	<ec3a010b0811041523l61cebd5dw8586ee413c13257e@mail.gmail.com>
	<13426df10811041543i4001fcbfv7f80a417a7b9d6d6@mail.gmail.com>
	<ec3a010b0811041559x7b743bf6oe24c06e234c83884@mail.gmail.com>
	<13426df10811041601g73e21d4ane791cb00c6d8b9ed@mail.gmail.com>
	<ec3a010b0811041621w62f90e7fm24ff475d83158ced@mail.gmail.com>
	<20081105012426.GD9994@cosmic.amd.com>
Message-ID: <13426df10811042017t16b3e9edw8a4d20f2667fca04@mail.gmail.com>

On Tue, Nov 4, 2008 at 5:24 PM, Jordan Crouse <jordan.crouse at amd.com> wrote:
> It just occured to me, I use a busybox based image for my Geode... :)

which geode is it? I am convinced there is something "different" about
the pcengines boards. I love those boards, but let's see.

ron



From c-d.hailfinger.devel.2006 at gmx.net  Wed Nov  5 05:21:59 2008
From: c-d.hailfinger.devel.2006 at gmx.net (Carl-Daniel Hailfinger)
Date: Wed, 05 Nov 2008 05:21:59 +0100
Subject: [coreboot] pci_device.c cleanup
In-Reply-To: <F5BEB1AEBFF4410F87FF1B8F232AFA51@chimp>
References: <2831fecf0811041204u59f2ccc9h5cb18f5e96c5fb@mail.gmail.com>
	<4910E42A.2060109@gmx.net> <F5BEB1AEBFF4410F87FF1B8F232AFA51@chimp>
Message-ID: <49111F67.1060301@gmx.net>

On 05.11.2008 03:58, Myles Watson wrote:
>   
>> -----Original Message-----
>> From: Carl-Daniel Hailfinger [mailto:c-d.hailfinger.devel.2006 at gmx.net]
>> Sent: Tuesday, November 04, 2008 5:09 PM
>> To: Myles Watson
>> Cc: Coreboot
>> Subject: Re: [coreboot] pci_device.c cleanup
>>
>> On 04.11.2008 21:04, Myles Watson wrote:
>>     
>>> This patch clarifies/adds comments and changes names in
>>>       
>> device/pci_device.c
>>     
>>> It also changes %p debug statements in various places.  I think they get
>>>       
>> in
>>     
>>> the way of diffs when you have log files to compare.  I don't want to
>>>       
>> see
>>     
>>> the
>>> allocation differences most of the time.  I turned most of them into
>>>       
>> NULL
>>     
>>> checks.  If they were supposed to be "Where are we in device
>>>       
>> allocation?"
>>     
>>> checks, we could make them into that too.
>>>
>>> It's a work-in-progress. Comments welcome.
>>>
>>> I think most of the changes are self explanatory, but this one might not
>>>       
>> be:
>>     
>>> If you are reading all the BARs from a device, and you come to a 64-bit
>>>       
>> BAR.
>>     
>>> No matter why you skip it, you should skip it as a 64-bit BAR, and not
>>>       
>> try
>>     
>>> to
>>> read the upper half as the next 32-bit BAR.
>>>
>>> Because of that, set the 64-bit flag IORESOURCE_PCI64 early, and don't
>>>       
>> clear
>>     
>>> it on return.
>>>
>>> Signed-off-by: Myles Watson <mylesgw at gmail.com>
>>>
>>> @@ -899,18 +924,18 @@
>>>   * Given a linked list of PCI device structures and a devfn number,
>>>       
>> find the
>>     
>>>   * device structure correspond to the devfn, if present. This function
>>>       
>> also
>>     
>>>   * removes the device structure from the linked list.
>>> - *
>>> + *
>>>   * @param list The device structure list.
>>>   * @param devfn A device/function number.
>>>   * @return Pointer to the device structure found or NULL of we have not
>>>   *	   allocated a device for this devfn yet.
>>>   */
>>> -static struct device *pci_scan_get_dev(struct device **list, unsigned
>>>       
>> int devfn)
>>     
>>> +static struct device *pci_get_dev(struct device **list, unsigned int
>>>       
>> devfn)
>>     
>>>  {
>>>  	struct device *dev;
>>>  	dev = 0;
>>> -	printk(BIOS_SPEW, "%s: list is %p, *list is %p\n", __func__, list,
>>> -	       *list);
>>> +	printk(BIOS_SPEW, "%s: list is %sNULL, *list is %sNULL\n", __func__,
>>> +		list?"NOT ":"", *list?"NOT ":"");
>>>  	for (; *list; list = &(*list)->sibling) {
>>>  		printk(BIOS_SPEW, "%s: check dev %s \n", __func__,
>>>  		       (*list)->dtsname);
>>>
>>>       
>> Was that change really intentional? Sure, it makes diffing easier, but
>> some diagnostics (especially considering the still buggy device
>> enumeration) are now more difficult.
>>     
>
> Since this is looking through the list of children, and the function prints
> out the dtsname of each child, I didn't find the actual pointer to be
> useful.  The dtsname is much more useful.
>   

Point taken.


>>> @@ -1043,15 +1068,22 @@
>>>  	dev->irq_pin = pci_read_config8(dev, PCI_INTERRUPT_PIN);
>>>  	dev->min_gnt = pci_read_config8(dev, PCI_MIN_GNT);
>>>  	dev->max_lat = pci_read_config8(dev, PCI_MAX_LAT);
>>> -#warning Per-device subsystem ID should only be read from the device if
>>>       
>> none has been specified for the device in the dts.
>>     
>>> -	dev->subsystem_vendor = pci_read_config16(dev,
>>>       
>> PCI_SUBSYSTEM_VENDOR_ID);
>>     
>>> -	dev->subsystem_device = pci_read_config16(dev, PCI_SUBSYSTEM_ID);
>>>
>>> -	/* Store the interesting information in the device structure. */
>>> +	/*Per-device subsystem ID should only be read from the device if
>>>       
>> none
>>     
>>> +	 * has been specified for the device in the dts.
>>> +	 */
>>> +	if (!dev->subsystem_vendor && !dev->subsystem_device) {
>>> +		dev->subsystem_vendor =
>>> +				pci_read_config16(dev,
>>>       
> PCI_SUBSYSTEM_VENDOR_ID);
>   
>>> +		dev->subsystem_device =
>>> +				pci_read_config16(dev, PCI_SUBSYSTEM_ID);
>>> +	}
>>> +
>>>  	dev->id.type = DEVICE_ID_PCI;
>>>  	dev->id.pci.vendor = id & 0xffff;
>>>  	dev->id.pci.device = (id >> 16) & 0xffff;
>>>  	dev->hdr_type = hdr_type;
>>> +
>>>  	/* Class code, the upper 3 bytes of PCI_CLASS_REVISION. */
>>>  	dev->class = class >> 8;
>>>
>>>
>>>       
>> Hm. Although you fixed the code as indicated in the #warning, I fear
>> there's still something missing and that's the reason the warning was
>> there. Where do we set the subsystem ID of the real device (not struct
>> device)?
>>     
>
> There's another place in the code where there's a warning that addresses
> this same issue.  I didn't think we needed it in both places.
>   

Agreed. I'll try to send a patch which fixes this FIXME.


>>> @@ -1105,6 +1135,8 @@
>>>
>>>  	printk(BIOS_DEBUG, "%s start bus %p, bus->dev %p\n", __func__, bus,
>>>  	       bus->dev);
>>> +
>>> +#warning This check needs checking.
>>>  	if (bus->dev->path.type != DEVICE_PATH_PCI_BUS)
>>>  		printk(BIOS_ERR, "ERROR: pci_scan_bus called with incorrect
>>>       
> "
>   
>>>  		       "bus->dev->path.type, path is %s\n", dev_path(bus-
>>> dev));
>>>
>>>       
>> If you manage to fix the device code in a way which doesn't trigger this
>> anymore, your static devices will suddenly be found. Since this check is
>> only triggered if your code and/or device tree is really buggy, we could
>> upgrade it to a die().
>>     
>
> I realize it's a problem.  Since I removed a couple of the other warnings, I
> thought I'd put one in this trouble spot.
>   

Good idea.


> Thanks for the review,
>   

Thanks for going over this code. It's easy to get lost in there and your
patches definitely improve the code.


Regards,
Carl-Daniel

-- 
http://www.hailfinger.org/




From corey.osgood at gmail.com  Wed Nov  5 05:29:35 2008
From: corey.osgood at gmail.com (Corey Osgood)
Date: Tue, 4 Nov 2008 23:29:35 -0500
Subject: [coreboot] [PATCH] CN700/VT8237R stage2
In-Reply-To: <49106320.60609@gmx.net>
References: <dd3c80060810290102o7b28a867y4b103e8b6ee4c621@mail.gmail.com>
	<490BB7F6.9030509@gmx.net>
	<dd3c80060810312206s558be78fs7f03da2715fe9dfd@mail.gmail.com>
	<dd3c80060810312208g49db1707j839fb9f18f4867f6@mail.gmail.com>
	<490C3E8C.7050307@gmx.net> <490C3FB1.8050901@gmx.net>
	<dd3c80060811011056k240a2b28ha80e33f11b4bb8df@mail.gmail.com>
	<490CA9F1.90704@gmx.net> <490CCA08.5090302@gmx.net>
	<49106320.60609@gmx.net>
Message-ID: <dd3c80060811042029m7fc371dchfc0dad69a6ae0d5c@mail.gmail.com>

On Tue, Nov 4, 2008 at 9:58 AM, Carl-Daniel Hailfinger <
c-d.hailfinger.devel.2006 at gmx.net> wrote:

> On 01.11.2008 22:28, Carl-Daniel Hailfinger wrote:
> > On 01.11.2008 20:11, Carl-Daniel Hailfinger wrote:
> >
> >> On 01.11.2008 18:56, Corey Osgood wrote:
> >>
> >>
> >>> System reset seems to occur between 2 and 3, both of those logs
> attached,
> >>> along with arch/x86/via/stage1.o With HALT_AFTER=3, the post code keeps
> >>> changing, as expected with the system rebooting, with HALT_AFTER=2 it
> was
> >>> 0xc2.
> >>>
> >>>
> >>>
> >> Great results, thanks a lot!
> >> One bug spotted and fixed. Can you retest with the same method and the
> >> updated patch attached to this mail? I hope it will die much later,
> >> perhaps at HALT_AFTER=13 or so.
> >>
> >>
> >
> > Thanks for the information that HALT_AFTER=5 is the last working setting.
> >
>
> OK, I reread every line of the code and reimplemented the problematic
> stuff from scratch.
>
> Can you try the new patch with HALT_AFTER=5 and 6? I'm pretty confident
> that if 6 works, all later numbers should also not reboot.
> By the way, the new code should be even better than the (working) v2 code.


That did the trick!

Thanks,
Corey
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20081104/3016a176/attachment.html>

From c-d.hailfinger.devel.2006 at gmx.net  Wed Nov  5 05:55:11 2008
From: c-d.hailfinger.devel.2006 at gmx.net (Carl-Daniel Hailfinger)
Date: Wed, 05 Nov 2008 05:55:11 +0100
Subject: [coreboot] [PATCH] Fix v3 VIA C7 CAR disable
Message-ID: <4911272F.6010309@gmx.net>

The VIA C7 CAR disable code in v3 had a nasty bug which caused the
processor to reset. Fix this bug and actually disable CAR.
With this patch v3 has better C7 CAR code than v2 (which skips two key
MTRRs).

Thanks to Corey Osgood for testing countless debug patches.

Signed-off-by: Carl-Daniel Hailfinger <c-d.hailfinger.devel.2006 at gmx.net>

Attached for Gmail users.

Index: corebootv3-via_car/arch/x86/via/stage1.c
===================================================================
--- corebootv3-via_car/arch/x86/via/stage1.c	(Revision 980)
+++ corebootv3-via_car/arch/x86/via/stage1.c	(Arbeitskopie)
@@ -56,22 +56,20 @@
 	__asm__ __volatile__(
 	"	movl	%[newesp], %%esp	\n"
 
-#if ENABLE_BROKEN_CAR_DISABLING
 	/* We don't need cache as ram for now on */
 	/* disable cache */
 	"	movl    %%cr0, %%eax		\n"
 	"	orl    $(0x1<<30),%%eax		\n"
 	"	movl    %%eax, %%cr0		\n"
 
-	/* The MTRR setup below causes the machine to reset. Must investigate. */
 	/* disable fixed mtrr from now on, it will be enabled by coreboot_ram again*/
-	"	movl    %[_SYSCFG_MSR], %%ecx	\n"
-	"	rdmsr				\n"
-	"	andl    %[_SYSCFG_MSR_newval], %%eax\n"
-//	"	andl    $(~(SYSCFG_MSR_MtrrFixDramModEn | SYSCFG_MSR_MtrrFixDramEn)), %%eax\n"
 	/* clear sth */
+	"	xorl    %%eax, %%eax		\n"
+	"	xorl    %%edx, %%edx		\n"
+	"	movl    $0x201, %%ecx		\n"
 	"	wrmsr				\n"
-#warning Must clear MTRR 0x200 and 0x201
+	"	movl    $0x200, %%ecx		\n"
+	"	wrmsr				\n"
 
 	/* Set the default memory type and disable fixed and enable variable MTRRs */
 	"	movl    %[_MTRRdefType_MSR], %%ecx	\n"
@@ -84,16 +82,11 @@
 	"	movl    %%cr0, %%eax		\n"
 	"	andl    $0x9fffffff,%%eax	\n"
 	"	movl    %%eax, %%cr0		\n"
-#endif
 
 	"	wbinvd				\n"
 
 	"	call stage1_phase3		\n"
 	:: [newesp] "i" (newlocation),
-	 [_SYSCFG_MSR] "i" (SYSCFG_MSR),
-	 [_SYSCFG_MSR_newval] "i" (~(SYSCFG_MSR_MtrrFixDramModEn | SYSCFG_MSR_MtrrFixDramEn)),
-	 [_SYSCFG_MSR_MtrrFixDramModEn] "i" (SYSCFG_MSR_MtrrFixDramModEn),
-	 [_SYSCFG_MSR_MtrrFixDramEn] "i" (SYSCFG_MSR_MtrrFixDramEn),
 	 [_MTRRdefType_MSR] "i" (MTRRdefType_MSR)
 	: "memory");
 }


-- 
http://www.hailfinger.org/

-------------- next part --------------
A non-text attachment was scrubbed...
Name: linuxbios3_car_via_disable_car_fix.diff
Type: text/x-patch
Size: 1712 bytes
Desc: not available
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20081105/b8f33fec/attachment.diff>

From c-d.hailfinger.devel.2006 at gmx.net  Wed Nov  5 05:55:50 2008
From: c-d.hailfinger.devel.2006 at gmx.net (Carl-Daniel Hailfinger)
Date: Wed, 05 Nov 2008 05:55:50 +0100
Subject: [coreboot] [PATCH] CN700/VT8237R stage2
In-Reply-To: <dd3c80060811042029m7fc371dchfc0dad69a6ae0d5c@mail.gmail.com>
References: <dd3c80060810290102o7b28a867y4b103e8b6ee4c621@mail.gmail.com>	
	<490BB7F6.9030509@gmx.net>	
	<dd3c80060810312206s558be78fs7f03da2715fe9dfd@mail.gmail.com>	
	<dd3c80060810312208g49db1707j839fb9f18f4867f6@mail.gmail.com>	
	<490C3E8C.7050307@gmx.net> <490C3FB1.8050901@gmx.net>	
	<dd3c80060811011056k240a2b28ha80e33f11b4bb8df@mail.gmail.com>	
	<490CA9F1.90704@gmx.net> <490CCA08.5090302@gmx.net>	
	<49106320.60609@gmx.net>
	<dd3c80060811042029m7fc371dchfc0dad69a6ae0d5c@mail.gmail.com>
Message-ID: <49112756.3050900@gmx.net>

On 05.11.2008 05:29, Corey Osgood wrote:
> On Tue, Nov 4, 2008 at 9:58 AM, Carl-Daniel Hailfinger <
> c-d.hailfinger.devel.2006 at gmx.net> wrote:
>
>   
>> On 01.11.2008 22:28, Carl-Daniel Hailfinger wrote:
>>     
>>> On 01.11.2008 20:11, Carl-Daniel Hailfinger wrote:
>>>
>>>       
>>>> On 01.11.2008 18:56, Corey Osgood wrote:
>>>>
>>>>
>>>>         
>>>>> System reset seems to occur between 2 and 3, both of those logs
>>>>>           
>> attached,
>>     
>>>>> along with arch/x86/via/stage1.o With HALT_AFTER=3, the post code keeps
>>>>> changing, as expected with the system rebooting, with HALT_AFTER=2 it
>>>>>           
>> was
>>     
>>>>> 0xc2.
>>>>>
>>>>>
>>>>>
>>>>>           
>>>> Great results, thanks a lot!
>>>> One bug spotted and fixed. Can you retest with the same method and the
>>>> updated patch attached to this mail? I hope it will die much later,
>>>> perhaps at HALT_AFTER=13 or so.
>>>>
>>>>
>>>>         
>>> Thanks for the information that HALT_AFTER=5 is the last working setting.
>>>
>>>       
>> OK, I reread every line of the code and reimplemented the problematic
>> stuff from scratch.
>>
>> Can you try the new patch with HALT_AFTER=5 and 6? I'm pretty confident
>> that if 6 works, all later numbers should also not reboot.
>> By the way, the new code should be even better than the (working) v2 code.
>>     
>
>
> That did the trick!
>   

Great, thanks for testing!

I just sent a patch with the final fixup sans debug code.

Regards,
Carl-Daniel

-- 
http://www.hailfinger.org/




From rminnich at gmail.com  Wed Nov  5 05:58:33 2008
From: rminnich at gmail.com (ron minnich)
Date: Tue, 4 Nov 2008 20:58:33 -0800
Subject: [coreboot] [PATCH] CN700/VT8237R stage2
In-Reply-To: <dd3c80060811042029m7fc371dchfc0dad69a6ae0d5c@mail.gmail.com>
References: <dd3c80060810290102o7b28a867y4b103e8b6ee4c621@mail.gmail.com>
	<dd3c80060810312206s558be78fs7f03da2715fe9dfd@mail.gmail.com>
	<dd3c80060810312208g49db1707j839fb9f18f4867f6@mail.gmail.com>
	<490C3E8C.7050307@gmx.net> <490C3FB1.8050901@gmx.net>
	<dd3c80060811011056k240a2b28ha80e33f11b4bb8df@mail.gmail.com>
	<490CA9F1.90704@gmx.net> <490CCA08.5090302@gmx.net>
	<49106320.60609@gmx.net>
	<dd3c80060811042029m7fc371dchfc0dad69a6ae0d5c@mail.gmail.com>
Message-ID: <13426df10811042058v8b4d5f1r6f82d2c3a16845e5@mail.gmail.com>

On Tue, Nov 4, 2008 at 8:29 PM, Corey Osgood <corey.osgood at gmail.com> wrote:

> That did the trick!

So where do we stand on the via and v3?

ron



From rminnich at gmail.com  Wed Nov  5 06:00:06 2008
From: rminnich at gmail.com (ron minnich)
Date: Tue, 4 Nov 2008 21:00:06 -0800
Subject: [coreboot] [PATCH] Fix v3 VIA C7 CAR disable
In-Reply-To: <4911272F.6010309@gmx.net>
References: <4911272F.6010309@gmx.net>
Message-ID: <13426df10811042100m4c71c384va1d940852be95340@mail.gmail.com>

Acked-by: Ronald G. Minnich <rminnich at gmail.com>

and thanks to both of you. FIne work!

ron



From rminnich at gmail.com  Wed Nov  5 06:01:23 2008
From: rminnich at gmail.com (ron minnich)
Date: Tue, 4 Nov 2008 21:01:23 -0800
Subject: [coreboot] LAB question
In-Reply-To: <3173667609B54C429D53E1F9E457B1F8@who8>
References: <Ack+6r//w1SGNEBXQYmYpo4m866UiA==>
	<3173667609B54C429D53E1F9E457B1F8@who8>
Message-ID: <13426df10811042101h59d4376aod05376f71b6f2f59@mail.gmail.com>

On Tue, Nov 4, 2008 at 6:04 PM, Gregg C Levine
<hansolofalcon at worldnet.att.net> wrote:

> I know it has been discussed on several occasions on this list, however I
> don't recall what was resolved about it. What has been resolved about it?
> And on what machines does it work? (This includes chipsets.)
>

it works on thousands of machines at LANL and has for 8 years.

It also was used for a short time on OLPC.

LAB has a very long tradition in coreboot, and is the reason the
original name was linuxbios.

ron



From c-d.hailfinger.devel.2006 at gmx.net  Wed Nov  5 06:03:00 2008
From: c-d.hailfinger.devel.2006 at gmx.net (Carl-Daniel Hailfinger)
Date: Wed, 05 Nov 2008 06:03:00 +0100
Subject: [coreboot] [PATCH] CN700/VT8237R stage2
In-Reply-To: <13426df10811042058v8b4d5f1r6f82d2c3a16845e5@mail.gmail.com>
References: <dd3c80060810290102o7b28a867y4b103e8b6ee4c621@mail.gmail.com>	
	<dd3c80060810312206s558be78fs7f03da2715fe9dfd@mail.gmail.com>	
	<dd3c80060810312208g49db1707j839fb9f18f4867f6@mail.gmail.com>	
	<490C3E8C.7050307@gmx.net> <490C3FB1.8050901@gmx.net>	
	<dd3c80060811011056k240a2b28ha80e33f11b4bb8df@mail.gmail.com>	
	<490CA9F1.90704@gmx.net> <490CCA08.5090302@gmx.net>	
	<49106320.60609@gmx.net>	
	<dd3c80060811042029m7fc371dchfc0dad69a6ae0d5c@mail.gmail.com>
	<13426df10811042058v8b4d5f1r6f82d2c3a16845e5@mail.gmail.com>
Message-ID: <49112904.8000204@gmx.net>

On 05.11.2008 05:58, ron minnich wrote:
> On Tue, Nov 4, 2008 at 8:29 PM, Corey Osgood <corey.osgood at gmail.com> wrote:
>
>   
>> That did the trick!
>>     
>
> So where do we stand on the via and v3?
>   

I'd say the CAR code (both enable and disable) is complete and perfect ;-)

Corey knows about the other stuff.

Does anybody have a VIA Nano board where he can try the stage1 code?
Using the jetway target with minor adjustments for SuperIO should give
serial output. And if serial output works, we know the CAR code is OK
for the Nano. That would certainly be a welcome event.
Similar tests appreciated for VIA C3 and anything else you can lay your
hands on.

Regards,
Carl-Daniel

-- 
http://www.hailfinger.org/




From c-d.hailfinger.devel.2006 at gmx.net  Wed Nov  5 06:07:33 2008
From: c-d.hailfinger.devel.2006 at gmx.net (Carl-Daniel Hailfinger)
Date: Wed, 05 Nov 2008 06:07:33 +0100
Subject: [coreboot] [PATCH] CN700/VT8237R stage2
In-Reply-To: <49112904.8000204@gmx.net>
References: <dd3c80060810290102o7b28a867y4b103e8b6ee4c621@mail.gmail.com>		<dd3c80060810312206s558be78fs7f03da2715fe9dfd@mail.gmail.com>		<dd3c80060810312208g49db1707j839fb9f18f4867f6@mail.gmail.com>		<490C3E8C.7050307@gmx.net>
	<490C3FB1.8050901@gmx.net>		<dd3c80060811011056k240a2b28ha80e33f11b4bb8df@mail.gmail.com>		<490CA9F1.90704@gmx.net>
	<490CCA08.5090302@gmx.net>		<49106320.60609@gmx.net>		<dd3c80060811042029m7fc371dchfc0dad69a6ae0d5c@mail.gmail.com>	<13426df10811042058v8b4d5f1r6f82d2c3a16845e5@mail.gmail.com>
	<49112904.8000204@gmx.net>
Message-ID: <49112A15.8040006@gmx.net>

On 05.11.2008 06:03, Carl-Daniel Hailfinger wrote:
> On 05.11.2008 05:58, ron minnich wrote:
>   
>> On Tue, Nov 4, 2008 at 8:29 PM, Corey Osgood <corey.osgood at gmail.com> wrote:
>>
>>   
>>     
>>> That did the trick!
>>>     
>>>       
>> So where do we stand on the via and v3?
>>   
>>     
>
> I'd say the CAR code (both enable and disable) is complete and perfect ;-)
>
> Corey knows about the other stuff.
>
> Does anybody have a VIA Nano board where he can try the stage1 code?
> Using the jetway target with minor adjustments for SuperIO should give
> serial output. And if serial output works, we know the CAR code is OK
> for the Nano. That would certainly be a welcome event.
> Similar tests appreciated for VIA C3 and anything else you can lay your
> hands on.
>   

The reason why I'm asking for this is simple: Give people serial output
and they feel success even if lots of stuff is still to be done. That's
an important motivator and one of the areas where v3 can shine due to
its structure.

Regards,
Carl-Daniel

-- 
http://www.hailfinger.org/




From corey.osgood at gmail.com  Wed Nov  5 06:17:51 2008
From: corey.osgood at gmail.com (Corey Osgood)
Date: Wed, 5 Nov 2008 00:17:51 -0500
Subject: [coreboot] [PATCH] CN700/VT8237R stage2
In-Reply-To: <49112A15.8040006@gmx.net>
References: <dd3c80060810290102o7b28a867y4b103e8b6ee4c621@mail.gmail.com>
	<490C3FB1.8050901@gmx.net>
	<dd3c80060811011056k240a2b28ha80e33f11b4bb8df@mail.gmail.com>
	<490CA9F1.90704@gmx.net> <490CCA08.5090302@gmx.net>
	<49106320.60609@gmx.net>
	<dd3c80060811042029m7fc371dchfc0dad69a6ae0d5c@mail.gmail.com>
	<13426df10811042058v8b4d5f1r6f82d2c3a16845e5@mail.gmail.com>
	<49112904.8000204@gmx.net> <49112A15.8040006@gmx.net>
Message-ID: <dd3c80060811042117n72f9188sdd8b64035db619ea@mail.gmail.com>

On Wed, Nov 5, 2008 at 12:07 AM, Carl-Daniel Hailfinger <
c-d.hailfinger.devel.2006 at gmx.net> wrote:

> On 05.11.2008 06:03, Carl-Daniel Hailfinger wrote:
> > On 05.11.2008 05:58, ron minnich wrote:
> >
> >> On Tue, Nov 4, 2008 at 8:29 PM, Corey Osgood <corey.osgood at gmail.com>
> wrote:
> >>
> >>
> >>
> >>> That did the trick!
> >>>
> >>>
> >> So where do we stand on the via and v3?
> >>
> >>
> >
> > I'd say the CAR code (both enable and disable) is complete and perfect
> ;-)
> >
> > Corey knows about the other stuff.
> >
> > Does anybody have a VIA Nano board where he can try the stage1 code?
> > Using the jetway target with minor adjustments for SuperIO should give
> > serial output. And if serial output works, we know the CAR code is OK
> > for the Nano. That would certainly be a welcome event.
> > Similar tests appreciated for VIA C3 and anything else you can lay your
> > hands on.
> >
>
> The reason why I'm asking for this is simple: Give people serial output
> and they feel success even if lots of stuff is still to be done. That's
> an important motivator and one of the areas where v3 can shine due to
> its structure.


cn700 & v3: if you comment out vt8237_enable()'s content in vt8237.c, it
might boot a payload, I'm tracking down the problem there right now. I don't
think we can use eg dev->pci.id.vendor in stage2.phase2? I want to clean
that up by the end of the night.

other cpus: I've got a Nehemiah C3 board here I'll try at some point, but
I'm focusing on c7 atm. I think the CPU is too different there, but I could
be wrong. If anyone wants to give me a Nano board, I'll try it out :D

-Corey
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20081105/26d0cf92/attachment.html>

From rminnich at gmail.com  Wed Nov  5 06:19:47 2008
From: rminnich at gmail.com (ron minnich)
Date: Tue, 4 Nov 2008 21:19:47 -0800
Subject: [coreboot] [PATCH] CN700/VT8237R stage2
In-Reply-To: <dd3c80060811042117n72f9188sdd8b64035db619ea@mail.gmail.com>
References: <dd3c80060810290102o7b28a867y4b103e8b6ee4c621@mail.gmail.com>
	<dd3c80060811011056k240a2b28ha80e33f11b4bb8df@mail.gmail.com>
	<490CA9F1.90704@gmx.net> <490CCA08.5090302@gmx.net>
	<49106320.60609@gmx.net>
	<dd3c80060811042029m7fc371dchfc0dad69a6ae0d5c@mail.gmail.com>
	<13426df10811042058v8b4d5f1r6f82d2c3a16845e5@mail.gmail.com>
	<49112904.8000204@gmx.net> <49112A15.8040006@gmx.net>
	<dd3c80060811042117n72f9188sdd8b64035db619ea@mail.gmail.com>
Message-ID: <13426df10811042119u2841a8adxc4dda9d4065d4d4e@mail.gmail.com>

On Tue, Nov 4, 2008 at 9:17 PM, Corey Osgood <corey.osgood at gmail.com> wrote:

> cn700 & v3: if you comment out vt8237_enable()'s content in vt8237.c, it
> might boot a payload, I'm tracking down the problem there right now. I don't
> think we can use eg dev->pci.id.vendor in stage2.phase2? I want to clean
> that up by the end of the night.

yes, in phase 2 that has not been set up yet. It gets set up in phase
3 during the scanning.

ron



From corey.osgood at gmail.com  Wed Nov  5 08:39:11 2008
From: corey.osgood at gmail.com (Corey Osgood)
Date: Wed, 5 Nov 2008 02:39:11 -0500
Subject: [coreboot] filo fails to compile
Message-ID: <dd3c80060811042339k7face039idb0fa203f19b3da3@mail.gmail.com>

Build host is Ubuntu 8.04.1, gcc 4.2.4 (Ubuntu 4.2.4-1ubuntu3). I followed
the steps at coreboot.org/Filo, console output below. build.sh seems to work
fine.

Thanks,
Corey

corey at Mobulus:~/coreboot/filo$ cd libpayload/
corey at Mobulus:~/coreboot/filo/libpayload$ make menuconfig
#
# configuration written to .config
#


*** End of libpayload configuration.
*** Execute 'make' to build or try 'make help'.

corey at Mobulus:~/coreboot/filo/libpayload$ make
  CC      build/i386/head.S.o
  CC      build/i386/main.o
  CC      build/i386/sysinfo.o
  CC      build/i386/timer.o
  CC      build/i386/coreboot.o
  CC      build/i386/util.S.o
  CC      build/i386/exec.S.o
  CC      build/i386/virtual.o
  CC      build/crypto/sha1.o
  CC      build/libc/malloc.o
  CC      build/libc/printf.o
  CC      build/libc/console.o
  CC      build/libc/string.o
  CC      build/libc/memory.o
  CC      build/libc/ctype.o
  CC      build/libc/ipchecksum.o
  CC      build/libc/lib.o
  CC      build/libc/rand.o
  CC      build/libc/time.o
  CC      build/libc/lar.o
  CC      build/libc/exec.o
  CC      build/libc/readline.o
  CC      build/drivers/pci.o
  CC      build/drivers/speaker.o
  CC      build/drivers/serial.o
  CC      build/drivers/keyboard.o
  CC      build/drivers/nvram.o
  CC      build/drivers/options.o
  CC      build/drivers/video/video.o
  CC      build/drivers/video/vga.o
  CC      build/curses/keyboard.o
  CC      build/curses/tinycurses.o
  CC      build/curses/colors.o
  AR      build/lib/libpayload.a
corey at Mobulus:~/coreboot/filo/libpayload$ cd ../
corey at Mobulus:~/coreboot/filo$ make menuconfig
#
# configuration written to .config
#


*** End of FILO configuration.
*** Execute 'make' to build or try 'make help'.

corey at Mobulus:~/coreboot/filo$ make
  CC      build/i386/context.o
/home/corey/coreboot/filo/i386/context.c:24:24: error: libpayload.h: No such
file or directory
In file included from /home/corey/coreboot/filo/i386/context.c:27:
/home/corey/coreboot/filo/i386/context.h:24: error: expected
specifier-qualifier-list before 'u16'
/home/corey/coreboot/filo/i386/context.h:55: error: expected ')' before '*'
token
/home/corey/coreboot/filo/i386/context.c:41: error: unknown field 'gdt_base'
specified in initializer
/home/corey/coreboot/filo/i386/context.c:41: error: 'u32' undeclared here
(not in a function)
/home/corey/coreboot/filo/i386/context.c:41: warning: excess elements in
struct initializer
/home/corey/coreboot/filo/i386/context.c:41: warning: (near initialization
for 'main_ctx')
/home/corey/coreboot/filo/i386/context.c:41: error: expected '}' before
'gdt'
/home/corey/coreboot/filo/i386/context.c:59: error: expected '=', ',', ';',
'asm' or '__attribute__' before 'image_stack'
/home/corey/coreboot/filo/i386/context.c: In function 'start_main':
/home/corey/coreboot/filo/i386/context.c:75: warning: implicit declaration
of function 'virt_to_phys'
/home/corey/coreboot/filo/i386/context.c:81: warning: implicit declaration
of function 'phys_to_virt'
/home/corey/coreboot/filo/i386/context.c:81: error: 'struct context' has no
member named 'eax'
/home/corey/coreboot/filo/i386/context.c: At top level:
/home/corey/coreboot/filo/i386/context.c:90: error: expected ')' before '*'
token
/home/corey/coreboot/filo/i386/context.c:127: error: expected '=', ',', ';',
'asm' or '__attribute__' before 'start_elf'
make: *** [/home/corey/coreboot/filo/build/i386/context.o] Error 1
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20081105/93d576e0/attachment.html>

From peter at stuge.se  Wed Nov  5 10:04:17 2008
From: peter at stuge.se (Peter Stuge)
Date: Wed, 5 Nov 2008 10:04:17 +0100
Subject: [coreboot] and/or busybox issue with alix2c3 serial console
In-Reply-To: <13426df10811042017t16b3e9edw8a4d20f2667fca04@mail.gmail.com>
References: <20081104215327.GE5424@cosmic.amd.com>
	<ec3a010b0811041404m2ca70564v4b31fb31458437c2@mail.gmail.com>
	<13426df10811041416h7c0fa3edo1e706e0d723446d9@mail.gmail.com>
	<ec3a010b0811041523l61cebd5dw8586ee413c13257e@mail.gmail.com>
	<13426df10811041543i4001fcbfv7f80a417a7b9d6d6@mail.gmail.com>
	<ec3a010b0811041559x7b743bf6oe24c06e234c83884@mail.gmail.com>
	<13426df10811041601g73e21d4ane791cb00c6d8b9ed@mail.gmail.com>
	<ec3a010b0811041621w62f90e7fm24ff475d83158ced@mail.gmail.com>
	<20081105012426.GD9994@cosmic.amd.com>
	<13426df10811042017t16b3e9edw8a4d20f2667fca04@mail.gmail.com>
Message-ID: <20081105090417.12601.qmail@stuge.se>

ron minnich wrote:
> > It just occured to me, I use a busybox based image for my Geode... :)
> 
> which geode is it? I am convinced there is something "different"
> about the pcengines boards. I love those boards, but let's see.

I think the main difference is that alix2 and alix3 have the serial
port coming out of the 5536 rather than a superio, which is what
we're used to.

We just have to get the init right. :)


//Peter



From leroi.lists at gmail.com  Wed Nov  5 10:20:58 2008
From: leroi.lists at gmail.com (Roman Yeryomin)
Date: Wed, 5 Nov 2008 11:20:58 +0200
Subject: [coreboot] and/or busybox issue with alix2c3 serial console
In-Reply-To: <20081105012426.GD9994@cosmic.amd.com>
References: <ec3a010b0811041340q202fc54fkecd64f6099622846@mail.gmail.com>
	<20081104215327.GE5424@cosmic.amd.com>
	<ec3a010b0811041404m2ca70564v4b31fb31458437c2@mail.gmail.com>
	<13426df10811041416h7c0fa3edo1e706e0d723446d9@mail.gmail.com>
	<ec3a010b0811041523l61cebd5dw8586ee413c13257e@mail.gmail.com>
	<13426df10811041543i4001fcbfv7f80a417a7b9d6d6@mail.gmail.com>
	<ec3a010b0811041559x7b743bf6oe24c06e234c83884@mail.gmail.com>
	<13426df10811041601g73e21d4ane791cb00c6d8b9ed@mail.gmail.com>
	<ec3a010b0811041621w62f90e7fm24ff475d83158ced@mail.gmail.com>
	<20081105012426.GD9994@cosmic.amd.com>
Message-ID: <ec3a010b0811050120v37f2ae2eye1c5fdd276590381@mail.gmail.com>

On Wed, Nov 5, 2008 at 3:24 AM, Jordan Crouse <jordan.crouse at amd.com> wrote:
> It just occured to me, I use a busybox based image for my Geode... :)
>
> I gzipped up the ext2 filesystem and put it here:
>
> http://www.infradead.org/~jcrouse/geode.rootfs.ext2.gz
>
> This uses busybox 1.9.2 and kernel 2.6.27.   There is a menu.lst in /boot,
> but the root points to the wrong place.  Use
>
> kernel /boot/bzImage root=/dev/hda1 console=tty0 console=ttyS0,115200
>
> I just booted it with a fresh version of v3 and all was well.  Good
> luck.

Tried your image but no luck. Same behaviour. No serial console.
All it gave to serial console while booting is in attachment.
Does it have some ip address and telnet/ssh server? So I could at
least ping it and see if it booted at all.


Roman
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: debug-v3r978mod-busy-jordan.txt
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20081105/c31f6ec4/attachment.txt>

From peter at stuge.se  Wed Nov  5 10:21:19 2008
From: peter at stuge.se (Peter Stuge)
Date: Wed, 5 Nov 2008 10:21:19 +0100
Subject: [coreboot] [PATCH] flashrom: sector-based flashing
In-Reply-To: <49105043.4010404@gmx.net>
References: <48F01FA7.7030206@gmx.net>
	<13426df10810102107r6b06ee3bh736b3bf5c3e3e8@mail.gmail.com>
	<48F11E1A.9050609@gmx.net> <49105043.4010404@gmx.net>
Message-ID: <20081105092119.17748.qmail@stuge.se>

Carl-Daniel Hailfinger wrote:
> @@ -64,6 +69,7 @@
>  
>  	int total_size;
>  	int page_size;
> +	struct eraseblock eraseblocks[4];

I don't know.. What about chips with more blocks than 4?


//Peter



From leroi.lists at gmail.com  Wed Nov  5 10:27:34 2008
From: leroi.lists at gmail.com (Roman Yeryomin)
Date: Wed, 5 Nov 2008 11:27:34 +0200
Subject: [coreboot] and/or busybox issue with alix2c3 serial console
In-Reply-To: <20081105090417.12601.qmail@stuge.se>
References: <20081104215327.GE5424@cosmic.amd.com>
	<13426df10811041416h7c0fa3edo1e706e0d723446d9@mail.gmail.com>
	<ec3a010b0811041523l61cebd5dw8586ee413c13257e@mail.gmail.com>
	<13426df10811041543i4001fcbfv7f80a417a7b9d6d6@mail.gmail.com>
	<ec3a010b0811041559x7b743bf6oe24c06e234c83884@mail.gmail.com>
	<13426df10811041601g73e21d4ane791cb00c6d8b9ed@mail.gmail.com>
	<ec3a010b0811041621w62f90e7fm24ff475d83158ced@mail.gmail.com>
	<20081105012426.GD9994@cosmic.amd.com>
	<13426df10811042017t16b3e9edw8a4d20f2667fca04@mail.gmail.com>
	<20081105090417.12601.qmail@stuge.se>
Message-ID: <ec3a010b0811050127l6275e488n2d3b46501d07a11d@mail.gmail.com>

On Wed, Nov 5, 2008 at 11:04 AM, Peter Stuge <peter at stuge.se> wrote:
> ron minnich wrote:
>> > It just occured to me, I use a busybox based image for my Geode... :)
>>
>> which geode is it? I am convinced there is something "different"
>> about the pcengines boards. I love those boards, but let's see.
>
> I think the main difference is that alix2 and alix3 have the serial
> port coming out of the 5536 rather than a superio, which is what
> we're used to.
>
> We just have to get the init right. :)

This is what I think too.
Maybe tinybios sources can help here?
What do you think about what Pascal Dornier said (about redirecting interrupts)?


Roman



From uwe at hermann-uwe.de  Wed Nov  5 10:37:37 2008
From: uwe at hermann-uwe.de (Uwe Hermann)
Date: Wed, 5 Nov 2008 10:37:37 +0100
Subject: [coreboot] filo fails to compile
In-Reply-To: <dd3c80060811042339k7face039idb0fa203f19b3da3@mail.gmail.com>
References: <dd3c80060811042339k7face039idb0fa203f19b3da3@mail.gmail.com>
Message-ID: <20081105093736.GC13674@greenwood>

On Wed, Nov 05, 2008 at 02:39:11AM -0500, Corey Osgood wrote:
> Build host is Ubuntu 8.04.1, gcc 4.2.4 (Ubuntu 4.2.4-1ubuntu3). I followed
> the steps at coreboot.org/Filo, console output below. build.sh seems to work
> fine.

The wiki needed a small fix (done).

After typing 'make' in libpayload, you have to also do:

  $ make DESTDIR=../build install

The rest of the instructions will then work fine.


Uwe.
-- 
http://www.hermann-uwe.de  | http://www.holsham-traders.de
http://www.crazy-hacks.org | http://www.unmaintained-free-software.org



From peter at stuge.se  Wed Nov  5 11:18:03 2008
From: peter at stuge.se (Peter Stuge)
Date: Wed, 5 Nov 2008 11:18:03 +0100
Subject: [coreboot] and/or busybox issue with alix2c3 serial console
In-Reply-To: <ec3a010b0811050127l6275e488n2d3b46501d07a11d@mail.gmail.com>
References: <13426df10811041416h7c0fa3edo1e706e0d723446d9@mail.gmail.com>
	<ec3a010b0811041523l61cebd5dw8586ee413c13257e@mail.gmail.com>
	<13426df10811041543i4001fcbfv7f80a417a7b9d6d6@mail.gmail.com>
	<ec3a010b0811041559x7b743bf6oe24c06e234c83884@mail.gmail.com>
	<13426df10811041601g73e21d4ane791cb00c6d8b9ed@mail.gmail.com>
	<ec3a010b0811041621w62f90e7fm24ff475d83158ced@mail.gmail.com>
	<20081105012426.GD9994@cosmic.amd.com>
	<13426df10811042017t16b3e9edw8a4d20f2667fca04@mail.gmail.com>
	<20081105090417.12601.qmail@stuge.se>
	<ec3a010b0811050127l6275e488n2d3b46501d07a11d@mail.gmail.com>
Message-ID: <20081105101803.32587.qmail@stuge.se>

Roman Yeryomin wrote:
> Maybe tinybios sources can help here?

Sure, can you find the assembly code that does serial init?  Possibly
it's not all in once place but rather scattered out in a few places,
meaning that it's simpler to look at documentation than code.

Geode documentation is available but I suppose time is scarce.


> What do you think about what Pascal Dornier said (about redirecting
> interrupts)?

I'm afraid it isn't relevant. He is refering to BIOS interrupt
services which coreboot doesn't do at all and which are unrelated
to the hardware interrupts that are missing in your system.

Please see http://en.wikipedia.org/wiki/Interrupt and
http://en.wikipedia.org/wiki/BIOS_interrupt_call for more info.


//Peter



From c-d.hailfinger.devel.2006 at gmx.net  Wed Nov  5 12:01:11 2008
From: c-d.hailfinger.devel.2006 at gmx.net (Carl-Daniel Hailfinger)
Date: Wed, 05 Nov 2008 12:01:11 +0100
Subject: [coreboot] [PATCH] flashrom: sector-based flashing
In-Reply-To: <20081105092119.17748.qmail@stuge.se>
References: <48F01FA7.7030206@gmx.net>	<13426df10810102107r6b06ee3bh736b3bf5c3e3e8@mail.gmail.com>	<48F11E1A.9050609@gmx.net>
	<49105043.4010404@gmx.net> <20081105092119.17748.qmail@stuge.se>
Message-ID: <49117CF7.2090307@gmx.net>

On 05.11.2008 10:21, Peter Stuge wrote:
> Carl-Daniel Hailfinger wrote:
>   
>> @@ -64,6 +69,7 @@
>>  
>>  	int total_size;
>>  	int page_size;
>> +	struct eraseblock eraseblocks[4];
>>     
>
> I don't know.. What about chips with more blocks than 4?
>   

No problem. Let me quote another part of the patch.

>> +struct eraseblock{
>> +	int size; /* Eraseblock size */
>> +	int count; /* Number of contiguous blocks with that size */
>> +};

struct eraseblock doesn't correspond with a single erase block, but with
a group of contiguous erase blocks having the same size.
Given a (top boot block) flash chip with the following weird, but
real-life structure:

top
16384
 8192
 8192
32768
65536
65536
65536
65536
65536
65536
65536
bottom

we get the following encoding:
{65536,7},{32768,1},{8192,2},{16384,1}

Although the number of blocks is bigger than 4, the number of block
groups is only 4. If you ever add some flash chips with more than 4
contiguous block groups, the definition will not fit into the 4-member
array anymore and gcc will recognize that and error out. No undetected
overflow possible. In that case, you simply increase array size a bit.
For modern flash chips with uniform erase block size, you only need one
array member anyway.

Of course data types will need to be changed if you ever get flash chips
with more than 2^30 erase blocks, but even with the lowest known erase
granularity of 256 bytes, these flash chips will have to have a size of
a quarter Terabyte. I'm pretty confident we won't see such big EEPROMs
in the near future (or at least not attached in a way that makes
flashrom usable). For SPI chips, we even have a guaranteed safety factor
of 4096 over the maximum SPI chip size (which is 2^24).
And if such a big flash chip has uniform erase block size, you could
even split it among the 4 array members. If you change int count to
unsigned int count, the storable size doubles. So with a split and a
slight change of data type, the maximum ROM chip size is 2 Terabytes.

Regards,
Carl-Daniel

-- 
http://www.hailfinger.org/




From c-d.hailfinger.devel.2006 at gmx.net  Wed Nov  5 12:03:53 2008
From: c-d.hailfinger.devel.2006 at gmx.net (Carl-Daniel Hailfinger)
Date: Wed, 05 Nov 2008 12:03:53 +0100
Subject: [coreboot] [PATCH] Fix v3 VIA C7 CAR disable
In-Reply-To: <13426df10811042100m4c71c384va1d940852be95340@mail.gmail.com>
References: <4911272F.6010309@gmx.net>
	<13426df10811042100m4c71c384va1d940852be95340@mail.gmail.com>
Message-ID: <49117D99.2000501@gmx.net>

On 05.11.2008 06:00, ron minnich wrote:
> Acked-by: Ronald G. Minnich <rminnich at gmail.com>
>
> and thanks to both of you. FIne work!
>   

Corey? I'd appreciate if you could ack this patch as well since you did
the heavy lifting in the testing department.

Thanks,
Carl-Daniel

-- 
http://www.hailfinger.org/




From Mario.Rogen at sie.at  Wed Nov  5 13:19:20 2008
From: Mario.Rogen at sie.at (Rogen, Mario)
Date: Wed, 5 Nov 2008 13:19:20 +0100
Subject: [coreboot] Flashrom - verified mainboards
Message-ID: <2F3951A78535124D960B1EFBB992F6D10158202D@mailserver.sienet.local>

Hi...
I just tested flashrom on a bunch of mainboards:

SST49LF008A congatec conga-x852 SBC
(http://www.congatec.com/single_news+M5e8f9751886.html). Read, write and
erase works out of the box. I also verified with the original congatec
tool. It reports success!
SST49LF008A IEI PICOe-9452
(http://www.iei.com.tw/en/product_IPC.asp?model=PICOe-9452) Everything
ok... 
SST39SF040 LEX Systems CV700A
(http://www.lex.com.tw/product/CV700A_s.htm) Everything works fine...
SST49LF004A/B Portwell PEB-4700VLA
(http://www.portwell.com/products/detail.asp?CUSTCHAR1=PEB-4700VLA)
Everything works fine..


Best regards

Mario Rogen



From c-d.hailfinger.devel.2006 at gmx.net  Wed Nov  5 13:28:54 2008
From: c-d.hailfinger.devel.2006 at gmx.net (Carl-Daniel Hailfinger)
Date: Wed, 05 Nov 2008 13:28:54 +0100
Subject: [coreboot] filo circular console list
In-Reply-To: <kjm4p2ub02n.fsf@pelargir.dolphinics.no>
References: <kjm8ws6b7pj.fsf@pelargir.dolphinics.no>	<20081030143849.GC31271@cosmic.amd.com>	<20081030145328.GD31271@cosmic.amd.com>
	<kjm4p2ub02n.fsf@pelargir.dolphinics.no>
Message-ID: <49119186.7040605@gmx.net>

On 30.10.2008 15:59, Arne Georg Gleditsch wrote:
> Jordan Crouse <jordan.crouse at amd.com> writes:
>   
>> My bad - they are using a custom entry point (see i386/switch.S in filo).
>> So, they do need to call console_init() and lib_get_sysinfo(). Your
>> patch is correct.
>>     
>
> Yes, I verified that console_out was NULL when entering filo.c's init().
>
>   
>> Acked-by: Jordan Crouse <jordan.crouse at amd.com>
>>     
>
> Oh, in case it matters:
>
> Signed-off-by: Arne Georg Gleditsch <arne.gleditsch at numascale.com>
>   

Committed by Stefan in r84.

Regards,
Carl-Daniel

-- 
http://www.hailfinger.org/




From quantumphazor at gmail.com  Wed Nov  5 00:56:59 2008
From: quantumphazor at gmail.com (Andrew Mellor)
Date: Wed, 05 Nov 2008 10:56:59 +1100
Subject: [coreboot] Usefull hardware data
Message-ID: <1225843019.9109.3.camel@3680>

Following uid313's instructions from
http://ubuntuforums.org/showthread.php?t=961975
-------------- next part --------------
A non-text attachment was scrubbed...
Name: irq_tables.c
Type: text/x-csrc
Size: 2445 bytes
Desc: not available
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20081105/219278e1/attachment.c>
-------------- next part --------------
# dmidecode 2.9
SMBIOS 2.4 present.
34 structures occupying 1108 bytes.
Table at 0x000DF810.

Handle 0x0000, DMI type 0, 24 bytes
BIOS Information
	Vendor: Acer   
	Version: v1.3216
	Release Date: 10/27/06
	Address: 0xE6BC0
	Runtime Size: 103488 bytes
	ROM Size: 1024 kB
	Characteristics:
		ISA is supported
		PCI is supported
		PC Card (PCMCIA) is supported
		PNP is supported
		BIOS is upgradeable
		BIOS shadowing is allowed
		ESCD support is available
		Boot from CD is supported
		ACPI is supported
		USB legacy is supported
		BIOS boot specification is supported
		Targeted content distribution is supported

Handle 0x0001, DMI type 1, 27 bytes
System Information
	Manufacturer: Acer, inc.
	Product Name: Aspire 3680     
	Version: Not Applicable
	Serial Number: LXAEP051066460E5062513
	UUID: 407F4DE2-BD04-D911-8914-001636AB65A6
	Wake-up Type: Power Switch
	SKU Number: Not Specified
	Family: Not Specified

Handle 0x0002, DMI type 2, 8 bytes
Base Board Information
	Manufacturer: Acer, Inc.
	Product Name: Prespa1         
	Version: Not Applicable
	Serial Number: LXAEP051066460E5062513

Handle 0x0003, DMI type 3, 17 bytes
Chassis Information
	Manufacturer: Acer, Inc.
	Type: Other
	Lock: Not Present
	Version: N/A
	Serial Number: None
	Asset Tag:                                  
	Boot-up State: Safe
	Power Supply State: Safe
	Thermal State: Safe
	Security Status: None
	OEM Information: 0x00001234

Handle 0x0004, DMI type 4, 35 bytes
Processor Information
	Socket Designation: U2E1
	Type: Central Processor
	Family: Other
	Manufacturer: Intel
	ID: E8 06 00 00 FF FB E9 AF
	Version: Intel(R) Celeron(R) M CPU        
	Voltage: 3.3 V
	External Clock: 133 MHz
	Max Speed: 1600 MHz
	Current Speed: 1600 MHz
	Status: Populated, Enabled
	Upgrade: ZIF Socket
	L1 Cache Handle: 0x0005
	L2 Cache Handle: 0x0006
	L3 Cache Handle: Not Provided
	Serial Number: Not Specified
	Asset Tag: Not Specified
	Part Number: Not Specified

Handle 0x0005, DMI type 7, 19 bytes
Cache Information
	Socket Designation: L1 Cache
	Configuration: Enabled, Socketed, Level 1
	Operational Mode: Write Back
	Location: Internal
	Installed Size: 16 KB
	Maximum Size: 16 KB
	Supported SRAM Types:
		Burst
		Pipeline Burst
		Asynchronous
	Installed SRAM Type: Asynchronous
	Speed: Unknown
	Error Correction Type: Unknown
	System Type: Unknown
	Associativity: Unknown

Handle 0x0006, DMI type 7, 19 bytes
Cache Information
	Socket Designation: L2 Cache
	Configuration: Enabled, Socketed, Level 2
	Operational Mode: Write Back
	Location: External
	Installed Size: 1024 KB
	Maximum Size: 512 KB
	Supported SRAM Types:
		Burst
		Pipeline Burst
		Asynchronous
	Installed SRAM Type: Burst
	Speed: Unknown
	Error Correction Type: Unknown
	System Type: Unknown
	Associativity: Unknown

Handle 0x0007, DMI type 8, 9 bytes
Port Connector Information
	Internal Reference Designator: J19
	Internal Connector Type: 9 Pin Dual Inline (pin 10 cut)
	External Reference Designator: COM 1
	External Connector Type: DB-9 male
	Port Type: Serial Port 16550A Compatible

Handle 0x0008, DMI type 8, 9 bytes
Port Connector Information
	Internal Reference Designator: J23
	Internal Connector Type: 25 Pin Dual Inline (pin 26 cut)
	External Reference Designator: Parallel
	External Connector Type: DB-25 female
	Port Type: Parallel Port ECP/EPP

Handle 0x0009, DMI type 8, 9 bytes
Port Connector Information
	Internal Reference Designator: J11
	Internal Connector Type: None
	External Reference Designator: Keyboard
	External Connector Type: Circular DIN-8 male
	Port Type: Keyboard Port

Handle 0x000A, DMI type 8, 9 bytes
Port Connector Information
	Internal Reference Designator: J12
	Internal Connector Type: None
	External Reference Designator: PS/2 Mouse
	External Connector Type: Circular DIN-8 male
	Port Type: Keyboard Port

Handle 0x000B, DMI type 9, 13 bytes
System Slot Information
	Designation: PCI Slot J11
	Type: 32-bit PCI
	Current Usage: Unknown
	Length: Long
	ID: 0
	Characteristics:
		5.0 V is provided
		3.3 V is provided

Handle 0x000C, DMI type 10, 6 bytes
On Board Device Information
	Type: Sound
	Status: Disabled
	Description: HD-Audio

Handle 0x000D, DMI type 11, 5 bytes
OEM Strings
	String 1: This is the Intel Calistoga
	String 2: Chipset CRB Platform

Handle 0x000E, DMI type 12, 5 bytes
System Configuration Options
	Option 1: Jumper settings can be described here.

Handle 0x000F, DMI type 15, 29 bytes
System Event Log
	Area Length: 16 bytes
	Header Start Offset: 0x0000
	Header Length: 16 bytes
	Data Start Offset: 0x0010
	Access Method: General-purpose non-volatile data functions
	Access Address: 0x0000
	Status: Valid, Not Full
	Change Token: 0x00000001
	Header Format: Type 1
	Supported Log Type Descriptors: 3
	Descriptor 1: POST error
	Data Format 1: POST results bitmap
	Descriptor 2: Single-bit ECC memory error
	Data Format 2: Multiple-event
	Descriptor 3: Multi-bit ECC memory error
	Data Format 3: Multiple-event

Handle 0x0010, DMI type 16, 15 bytes
Physical Memory Array
	Location: System Board Or Motherboard
	Use: System Memory
	Error Correction Type: None
	Maximum Capacity: 4 GB
	Error Information Handle: Not Provided
	Number Of Devices: 2

Handle 0x0011, DMI type 17, 27 bytes
Memory Device
	Array Handle: 0x0010
	Error Information Handle: No Error
	Total Width: 32 bits
	Data Width: 32 bits
	Size: 512 MB
	Form Factor: SODIMM
	Set: 1
	Locator: M1
	Bank Locator: Bank 0
	Type: DDR2
	Type Detail: Synchronous
	Speed: Unknown
	Manufacturer: Not Specified
	Serial Number: Not Specified
	Asset Tag: Not Specified
	Part Number: Not Specified

Handle 0x0012, DMI type 17, 27 bytes
Memory Device
	Array Handle: 0x0010
	Error Information Handle: No Error
	Total Width: 32 bits
	Data Width: 32 bits
	Size: 512 MB
	Form Factor: SODIMM
	Set: 1
	Locator: M2
	Bank Locator: Bank 1
	Type: DDR2
	Type Detail: Synchronous
	Speed: Unknown
	Manufacturer: Not Specified
	Serial Number: Not Specified
	Asset Tag: Not Specified
	Part Number: Not Specified

Handle 0x0013, DMI type 19, 15 bytes
Memory Array Mapped Address
	Starting Address: 0x00000000000
	Ending Address: 0x0003FFFFFFF
	Range Size: 1 GB
	Physical Array Handle: 0x0010
	Partition Width: 0

Handle 0x0014, DMI type 20, 19 bytes
Memory Device Mapped Address
	Starting Address: 0x00000000000
	Ending Address: 0x0001FFFFFFF
	Range Size: 512 MB
	Physical Device Handle: 0x0011
	Memory Array Mapped Address Handle: 0x0013
	Partition Row Position: Unknown
	Interleave Position: Unknown
	Interleaved Data Depth: Unknown

Handle 0x0015, DMI type 20, 19 bytes
Memory Device Mapped Address
	Starting Address: 0x00020000000
	Ending Address: 0x0003FFFFFFF
	Range Size: 512 MB
	Physical Device Handle: 0x0012
	Memory Array Mapped Address Handle: 0x0013
	Partition Row Position: Unknown
	Interleave Position: Unknown
	Interleaved Data Depth: Unknown

Handle 0x0016, DMI type 23, 13 bytes
System Reset
	Status: Enabled
	Watchdog Timer: Present
	Boot Option: Do Not Reboot
	Boot Option On Limit: Do Not Reboot
	Reset Count: Unknown
	Reset Limit: Unknown
	Timer Interval: Unknown
	Timeout: Unknown

Handle 0x0017, DMI type 24, 5 bytes
Hardware Security
	Power-On Password Status: Enabled
	Keyboard Password Status: Unknown
	Administrator Password Status: Enabled
	Front Panel Reset Status: Unknown

Handle 0x0018, DMI type 25, 9 bytes
	System Power Controls
	Next Scheduled Power-on: 12-31 23:59:59

Handle 0x0019, DMI type 26, 20 bytes
Voltage Probe
	Description: Voltage Probe
	Location: Processor
	Status: OK
	Maximum Value: Unknown
	Minimum Value: Unknown
	Resolution: Unknown
	Tolerance: Unknown
	Accuracy: Unknown
	OEM-specific Information: 0x00000000

Handle 0x001A, DMI type 27, 12 bytes
Cooling Device
	Temperature Probe Handle: 0x001B
	Type: Fan
	Status: OK
	OEM-specific Information: 0x00000000

Handle 0x001B, DMI type 28, 20 bytes
Temperature Probe
	Description: Temperature Probe
	Location: Processor
	Status: OK
	Maximum Value: Unknown
	Minimum Value Unknown
	Resolution: Unknown
	Tolerance: Unknown
	Accuracy: Unknown
	OEM-specific Information: 0x00000000

Handle 0x001C, DMI type 29, 20 bytes
Electrical Current Probe
	Description: Electrical Current Probe
	Location: Processor
	Status: OK
	Maximum Value: Unknown
	Minimum Value: Unknown
	Resolution: Unknown
	Tolerance: Unknown
	Accuracy: Unknown
	OEM-specific Information: 0x00000000

Handle 0x001D, DMI type 30, 6 bytes
Out-of-band Remote Access
	Manufacturer Name: Intel
	Inbound Connection: Enabled
	Outbound Connection: Disabled

Handle 0x001E, DMI type 32, 20 bytes
System Boot Information
	Status: <OUT OF SPEC>

Handle 0x001F, DMI type 129, 16 bytes
OEM-specific Type
	Header and Data:
		81 10 1F 00 01 01 02 01 00 00 00 01 00 00 08 01
	Strings:
		Intel_ASF_001
		Intel_ASF_001

Handle 0x0020, DMI type 136, 6 bytes
OEM-specific Type
	Header and Data:
		88 06 20 00 FF FF

Handle 0x0021, DMI type 127, 4 bytes
End Of Table

-------------- next part --------------
# dmidecode 2.9
SMBIOS 2.4 present.
34 structures occupying 1108 bytes.
Table at 0x000DF810.

Handle 0x0000, DMI type 0, 24 bytes
	Header and Data:
		00 18 00 00 01 02 BC E6 03 0F 90 DB 00 00 00 00
		00 00 03 05 FF FF FF FF
	Strings:
		41 63 65 72 20 20 20 00
		"Acer   "
		76 31 2E 33 32 31 36 00
		"v1.3216"
		31 30 2F 32 37 2F 30 36 00
		"10/27/06"

Handle 0x0001, DMI type 1, 27 bytes
	Header and Data:
		01 1B 01 00 01 02 03 04 40 7F 4D E2 BD 04 D9 11
		89 14 00 16 36 AB 65 A6 06 00 00
	Strings:
		41 63 65 72 2C 20 69 6E 63 2E 00
		"Acer, inc."
		41 73 70 69 72 65 20 33 36 38 30 20 20 20 20 20
		00
		"Aspire 3680     "
		4E 6F 74 20 41 70 70 6C 69 63 61 62 6C 65 00
		"Not Applicable"
		4C 58 41 45 50 30 35 31 30 36 36 34 36 30 45 35
		30 36 32 35 31 33 00
		"LXAEP051066460E5062513"

Handle 0x0002, DMI type 2, 8 bytes
	Header and Data:
		02 08 02 00 01 02 03 04
	Strings:
		41 63 65 72 2C 20 49 6E 63 2E 00
		"Acer, Inc."
		50 72 65 73 70 61 31 20 20 20 20 20 20 20 20 20
		00
		"Prespa1         "
		4E 6F 74 20 41 70 70 6C 69 63 61 62 6C 65 00
		"Not Applicable"
		4C 58 41 45 50 30 35 31 30 36 36 34 36 30 45 35
		30 36 32 35 31 33 00
		"LXAEP051066460E5062513"

Handle 0x0003, DMI type 3, 17 bytes
	Header and Data:
		03 11 03 00 01 01 02 03 04 03 03 03 03 34 12 00
		00
	Strings:
		41 63 65 72 2C 20 49 6E 63 2E 00
		"Acer, Inc."
		4E 2F 41 00
		"N/A"
		4E 6F 6E 65 00
		"None"
		20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20
		20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20
		20 00
		"                                 "

Handle 0x0004, DMI type 4, 35 bytes
	Header and Data:
		04 23 04 00 01 03 01 02 E8 06 00 00 FF FB E9 AF
		03 02 85 00 40 06 40 06 41 04 05 00 06 00 FF FF
		00 00 00
	Strings:
		55 32 45 31 00
		"U2E1"
		49 6E 74 65 6C 00
		"Intel"
		49 6E 74 65 6C 28 52 29 20 43 65 6C 65 72 6F 6E
		28 52 29 20 4D 20 43 50 55 20 20 20 20 20 20 20
		20 00
		"Intel(R) Celeron(R) M CPU        "

Handle 0x0005, DMI type 7, 19 bytes
	Header and Data:
		07 13 05 00 01 88 01 10 00 10 00 58 00 40 00 00
		02 02 02
	Strings:
		4C 31 20 43 61 63 68 65 00
		"L1 Cache"

Handle 0x0006, DMI type 7, 19 bytes
	Header and Data:
		07 13 06 00 01 A9 01 00 02 00 04 58 00 08 00 00
		02 02 02
	Strings:
		4C 32 20 43 61 63 68 65 00
		"L2 Cache"

Handle 0x0007, DMI type 8, 9 bytes
	Header and Data:
		08 09 07 00 01 18 02 08 09
	Strings:
		4A 31 39 00
		"J19"
		43 4F 4D 20 31 00
		"COM 1"

Handle 0x0008, DMI type 8, 9 bytes
	Header and Data:
		08 09 08 00 01 19 02 05 05
	Strings:
		4A 32 33 00
		"J23"
		50 61 72 61 6C 6C 65 6C 00
		"Parallel"

Handle 0x0009, DMI type 8, 9 bytes
	Header and Data:
		08 09 09 00 01 00 02 14 0D
	Strings:
		4A 31 31 00
		"J11"
		4B 65 79 62 6F 61 72 64 00
		"Keyboard"

Handle 0x000A, DMI type 8, 9 bytes
	Header and Data:
		08 09 0A 00 01 00 02 14 0D
	Strings:
		4A 31 32 00
		"J12"
		50 53 2F 32 20 4D 6F 75 73 65 00
		"PS/2 Mouse"

Handle 0x000B, DMI type 9, 13 bytes
	Header and Data:
		09 0D 0B 00 01 06 05 02 04 00 00 06 00
	Strings:
		50 43 49 20 53 6C 6F 74 20 4A 31 31 00
		"PCI Slot J11"

Handle 0x000C, DMI type 10, 6 bytes
	Header and Data:
		0A 06 0C 00 07 01
	Strings:
		48 44 2D 41 75 64 69 6F 00
		"HD-Audio"

Handle 0x000D, DMI type 11, 5 bytes
	Header and Data:
		0B 05 0D 00 02
	Strings:
		54 68 69 73 20 69 73 20 74 68 65 20 49 6E 74 65
		6C 20 43 61 6C 69 73 74 6F 67 61 00
		"This is the Intel Calistoga"
		43 68 69 70 73 65 74 20 43 52 42 20 50 6C 61 74
		66 6F 72 6D 00
		"Chipset CRB Platform"

Handle 0x000E, DMI type 12, 5 bytes
	Header and Data:
		0C 05 0E 00 01
	Strings:
		4A 75 6D 70 65 72 20 73 65 74 74 69 6E 67 73 20
		63 61 6E 20 62 65 20 64 65 73 63 72 69 62 65 64
		20 68 65 72 65 2E 00
		"Jumper settings can be described here."

Handle 0x000F, DMI type 15, 29 bytes
	Header and Data:
		0F 1D 0F 00 10 00 00 00 10 00 04 01 01 00 00 00
		00 00 00 00 01 03 02 08 04 01 02 02 02

Handle 0x0010, DMI type 16, 15 bytes
	Header and Data:
		10 0F 10 00 03 03 03 00 00 40 00 FE FF 02 00

Handle 0x0011, DMI type 17, 27 bytes
	Header and Data:
		11 1B 11 00 10 00 FF FF 20 00 20 00 00 02 0D 01
		01 02 13 80 00 00 00 00 00 00 00
	Strings:
		4D 31 00
		"M1"
		42 61 6E 6B 20 30 00
		"Bank 0"

Handle 0x0012, DMI type 17, 27 bytes
	Header and Data:
		11 1B 12 00 10 00 FF FF 20 00 20 00 00 02 0D 01
		01 02 13 80 00 00 00 00 00 00 00
	Strings:
		4D 32 00
		"M2"
		42 61 6E 6B 20 31 00
		"Bank 1"

Handle 0x0013, DMI type 19, 15 bytes
	Header and Data:
		13 0F 13 00 00 00 00 00 FF FF 0F 00 10 00 02

Handle 0x0014, DMI type 20, 19 bytes
	Header and Data:
		14 13 14 00 00 00 00 00 FF FF 07 00 11 00 13 00
		FF FF FF

Handle 0x0015, DMI type 20, 19 bytes
	Header and Data:
		14 13 15 00 00 00 08 00 FF FF 0F 00 12 00 13 00
		FF FF FF

Handle 0x0016, DMI type 23, 13 bytes
	Header and Data:
		17 0D 16 00 3F FF FF FF FF FF FF FF FF

Handle 0x0017, DMI type 24, 5 bytes
	Header and Data:
		18 05 17 00 77

Handle 0x0018, DMI type 25, 9 bytes
	Header and Data:
		19 09 18 00 12 31 23 59 59

Handle 0x0019, DMI type 26, 20 bytes
	Header and Data:
		1A 14 19 00 01 63 00 80 00 80 00 80 00 80 00 80
		00 00 00 00
	Strings:
		56 6F 6C 74 61 67 65 20 50 72 6F 62 65 00
		"Voltage Probe"

Handle 0x001A, DMI type 27, 12 bytes
	Header and Data:
		1B 0C 1A 00 1B 00 63 00 00 00 00 00

Handle 0x001B, DMI type 28, 20 bytes
	Header and Data:
		1C 14 1B 00 01 63 00 80 00 80 00 80 00 80 00 80
		00 00 00 00
	Strings:
		54 65 6D 70 65 72 61 74 75 72 65 20 50 72 6F 62
		65 00
		"Temperature Probe"

Handle 0x001C, DMI type 29, 20 bytes
	Header and Data:
		1D 14 1C 00 01 63 00 80 00 80 00 80 00 80 00 80
		00 00 00 00
	Strings:
		45 6C 65 63 74 72 69 63 61 6C 20 43 75 72 72 65
		6E 74 20 50 72 6F 62 65 00
		"Electrical Current Probe"

Handle 0x001D, DMI type 30, 6 bytes
	Header and Data:
		1E 06 1D 00 01 01
	Strings:
		49 6E 74 65 6C 00
		"Intel"

Handle 0x001E, DMI type 32, 20 bytes
	Header and Data:
		20 14 1E 00 00 00 00 00 00 00 0C 01 02 03 04 05
		06 07 08 09

Handle 0x001F, DMI type 129, 16 bytes
	Header and Data:
		81 10 1F 00 01 01 02 01 00 00 00 01 00 00 08 01
	Strings:
		49 6E 74 65 6C 5F 41 53 46 5F 30 30 31 00
		"Intel_ASF_001"
		49 6E 74 65 6C 5F 41 53 46 5F 30 30 31 00
		"Intel_ASF_001"

Handle 0x0020, DMI type 136, 6 bytes
	Header and Data:
		88 06 20 00 FF FF

Handle 0x0021, DMI type 127, 4 bytes
	Header and Data:
		7F 04 21 00

-------------- next part --------------
3680
    description: Computer
    product: Aspire 3680
    vendor: Acer, inc.
    version: Not Applicable
    serial: LXAEP051066460E5062513
    width: 32 bits
    capabilities: smbios-2.4 dmi-2.4 smp-1.4 smp
    configuration: administrator_password=enabled boot=oem-specific cpus=1 frontpanel_password=unknown keyboard_password=unknown power-on_password=enabled uuid=407F4DE2-BD04-D911-8914-001636AB65A6
  *-core
       description: Motherboard
       product: Prespa1
       vendor: Acer, Inc.
       physical id: 0
       version: Not Applicable
       serial: LXAEP051066460E5062513
     *-firmware
          description: BIOS
          vendor: Acer
          physical id: 0
          version: v1.3216 (10/27/06)
          size: 101KiB
          capacity: 960KiB
          capabilities: isa pci pcmcia pnp upgrade shadowing escd cdboot acpi usb biosbootspecification
     *-cpu
          description: CPU
          product: Intel(R) Celeron(R) M CPU        420  @ 1.60GHz
          vendor: Intel Corp.
          physical id: 4
          bus info: cpu at 0
          version: 6.14.8
          serial: 0000-06E8-0000-0000-0000-0000
          slot: U2E1
          size: 1600MHz
          capacity: 1600MHz
          width: 32 bits
          clock: 133MHz
          capabilities: boot fpu fpu_exception wp vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat clflush dts acpi mmx fxsr sse sse2 ss tm pbe nx constant_tsc up arch_perfmon bts pni monitor tm2 xtpr
        *-cache:0
             description: L1 cache
             physical id: 5
             slot: L1 Cache
             size: 16KiB
             capacity: 16KiB
             capabilities: asynchronous internal write-back
        *-cache:1
             description: L2 cache
             physical id: 6
             slot: L2 Cache
             size: 1MiB
             capabilities: burst external write-back
     *-memory
          description: System Memory
          physical id: 10
          slot: System board or motherboard
          size: 1GiB
        *-bank:0
             description: SODIMM Synchronous
             physical id: 0
             slot: M1
             size: 512MiB
             width: 32 bits
        *-bank:1
             description: SODIMM Synchronous
             physical id: 1
             slot: M2
             size: 512MiB
             width: 32 bits
     *-pci
          description: Host bridge
          product: Mobile 945GM/PM/GMS, 943/940GML and 945GT Express Memory Controller Hub
          vendor: Intel Corporation
          physical id: 100
          bus info: pci at 0000:00:00.0
          version: 03
          width: 32 bits
          clock: 33MHz
          configuration: driver=agpgart-intel module=intel_agp
        *-display:0 UNCLAIMED
             description: VGA compatible controller
             product: Mobile 945GM/GMS, 943/940GML Express Integrated Graphics Controller
             vendor: Intel Corporation
             physical id: 2
             bus info: pci at 0000:00:02.0
             version: 03
             width: 32 bits
             clock: 33MHz
             capabilities: msi pm vga_controller bus_master cap_list
             configuration: latency=0
        *-display:1 UNCLAIMED
             description: Display controller
             product: Mobile 945GM/GMS/GME, 943/940GML Express Integrated Graphics Controller
             vendor: Intel Corporation
             physical id: 2.1
             bus info: pci at 0000:00:02.1
             version: 03
             width: 32 bits
             clock: 33MHz
             capabilities: pm bus_master cap_list
             configuration: latency=0
        *-multimedia
             description: Audio device
             product: 82801G (ICH7 Family) High Definition Audio Controller
             vendor: Intel Corporation
             physical id: 1b
             bus info: pci at 0000:00:1b.0
             version: 02
             width: 64 bits
             clock: 33MHz
             capabilities: pm msi pciexpress bus_master cap_list
             configuration: driver=HDA Intel latency=0 module=snd_hda_intel
        *-pci:0
             description: PCI bridge
             product: 82801G (ICH7 Family) PCI Express Port 1
             vendor: Intel Corporation
             physical id: 1c
             bus info: pci at 0000:00:1c.0
             version: 02
             width: 32 bits
             clock: 33MHz
             capabilities: pci pciexpress msi pm normal_decode bus_master cap_list
             configuration: driver=pcieport-driver
           *-network
                description: Ethernet interface
                product: 88E8038 PCI-E Fast Ethernet Controller
                vendor: Marvell Technology Group Ltd.
                physical id: 0
                bus info: pci at 0000:02:00.0
                logical name: eth0
                version: 14
                serial: 00:16:36:ab:65:a6
                capacity: 100MB/s
                width: 64 bits
                clock: 33MHz
                capabilities: pm vpd msi pciexpress bus_master cap_list ethernet physical tp 10bt 10bt-fd 100bt 100bt-fd autonegotiation
                configuration: autonegotiation=on broadcast=yes driver=sky2 driverversion=1.20 firmware=N/A latency=0 link=no module=sky2 multicast=yes port=twisted pair
        *-pci:1
             description: PCI bridge
             product: 82801G (ICH7 Family) PCI Express Port 2
             vendor: Intel Corporation
             physical id: 1c.1
             bus info: pci at 0000:00:1c.1
             version: 02
             width: 32 bits
             clock: 33MHz
             capabilities: pci pciexpress msi pm normal_decode bus_master cap_list
             configuration: driver=pcieport-driver
        *-pci:2
             description: PCI bridge
             product: 82801G (ICH7 Family) PCI Express Port 3
             vendor: Intel Corporation
             physical id: 1c.2
             bus info: pci at 0000:00:1c.2
             version: 02
             width: 32 bits
             clock: 33MHz
             capabilities: pci pciexpress msi pm normal_decode bus_master cap_list
             configuration: driver=pcieport-driver
        *-pci:3
             description: PCI bridge
             product: 82801G (ICH7 Family) PCI Express Port 4
             vendor: Intel Corporation
             physical id: 1c.3
             bus info: pci at 0000:00:1c.3
             version: 02
             width: 32 bits
             clock: 33MHz
             capabilities: pci pciexpress msi pm normal_decode bus_master cap_list
             configuration: driver=pcieport-driver
        *-usb:0
             description: USB Controller
             product: 82801G (ICH7 Family) USB UHCI Controller #1
             vendor: Intel Corporation
             physical id: 1d
             bus info: pci at 0000:00:1d.0
             version: 02
             width: 32 bits
             clock: 33MHz
             capabilities: uhci bus_master
             configuration: driver=uhci_hcd latency=0 module=uhci_hcd
           *-usbhost
                product: UHCI Host Controller
                vendor: Linux 2.6.24-21-generic uhci_hcd
                physical id: 1
                bus info: usb at 1
                logical name: usb1
                version: 2.06
                capabilities: usb-1.10
                configuration: maxpower=0mA slots=2 speed=12.0MB/s
        *-usb:1
             description: USB Controller
             product: 82801G (ICH7 Family) USB UHCI Controller #2
             vendor: Intel Corporation
             physical id: 1d.1
             bus info: pci at 0000:00:1d.1
             version: 02
             width: 32 bits
             clock: 33MHz
             capabilities: uhci bus_master
             configuration: driver=uhci_hcd latency=0 module=uhci_hcd
           *-usbhost
                product: UHCI Host Controller
                vendor: Linux 2.6.24-21-generic uhci_hcd
                physical id: 1
                bus info: usb at 2
                logical name: usb2
                version: 2.06
                capabilities: usb-1.10
                configuration: maxpower=0mA slots=2 speed=12.0MB/s
              *-usb UNCLAIMED
                   description: Generic USB device
                   product: Microsoft Wireless Desktop Receiver 3.1A
                   vendor: Microsft
                   physical id: 1
                   bus info: usb at 2:1
                   version: 0.02
                   capabilities: usb-2.00
                   configuration: maxpower=100mA speed=1.5MB/s
        *-usb:2
             description: USB Controller
             product: 82801G (ICH7 Family) USB UHCI Controller #3
             vendor: Intel Corporation
             physical id: 1d.2
             bus info: pci at 0000:00:1d.2
             version: 02
             width: 32 bits
             clock: 33MHz
             capabilities: uhci bus_master
             configuration: driver=uhci_hcd latency=0 module=uhci_hcd
           *-usbhost
                product: UHCI Host Controller
                vendor: Linux 2.6.24-21-generic uhci_hcd
                physical id: 1
                bus info: usb at 3
                logical name: usb3
                version: 2.06
                capabilities: usb-1.10
                configuration: maxpower=0mA slots=2 speed=12.0MB/s
        *-usb:3
             description: USB Controller
             product: 82801G (ICH7 Family) USB UHCI Controller #4
             vendor: Intel Corporation
             physical id: 1d.3
             bus info: pci at 0000:00:1d.3
             version: 02
             width: 32 bits
             clock: 33MHz
             capabilities: uhci bus_master
             configuration: driver=uhci_hcd latency=0 module=uhci_hcd
           *-usbhost
                product: UHCI Host Controller
                vendor: Linux 2.6.24-21-generic uhci_hcd
                physical id: 1
                bus info: usb at 4
                logical name: usb4
                version: 2.06
                capabilities: usb-1.10
                configuration: maxpower=0mA slots=2 speed=12.0MB/s
        *-usb:4
             description: USB Controller
             product: 82801G (ICH7 Family) USB2 EHCI Controller
             vendor: Intel Corporation
             physical id: 1d.7
             bus info: pci at 0000:00:1d.7
             version: 02
             width: 32 bits
             clock: 33MHz
             capabilities: pm debug ehci bus_master cap_list
             configuration: driver=ehci_hcd latency=0 module=ehci_hcd
           *-usbhost
                product: EHCI Host Controller
                vendor: Linux 2.6.24-21-generic ehci_hcd
                physical id: 1
                bus info: usb at 5
                logical name: usb5
                version: 2.06
                capabilities: usb-2.00
                configuration: maxpower=0mA slots=8 speed=480.0MB/s
        *-pci:4
             description: PCI bridge
             product: 82801 Mobile PCI Bridge
             vendor: Intel Corporation
             physical id: 1e
             bus info: pci at 0000:00:1e.0
             version: e2
             width: 32 bits
             clock: 33MHz
             capabilities: pci subtractive_decode bus_master cap_list
           *-network
                description: Wireless interface
                product: AR2413 802.11bg NIC
                vendor: Atheros Communications Inc.
                physical id: 3
                bus info: pci at 0000:0a:03.0
                logical name: wifi0
                version: 01
                serial: 00:16:cf:c8:8e:20
                width: 32 bits
                clock: 33MHz
                capabilities: pm bus_master cap_list logical ethernet physical wireless
                configuration: broadcast=yes driver=ath_pci ip=192.168.0.41 latency=96 maxlatency=28 mingnt=10 module=ath_pci multicast=yes wireless=IEEE 802.11g
           *-pcmcia
                description: CardBus bridge
                product: PCIxx12 Cardbus Controller
                vendor: Texas Instruments
                physical id: 9
                bus info: pci at 0000:0a:09.0
                version: 00
                width: 32 bits
                clock: 33MHz
                capabilities: pcmcia bus_master cap_list
                configuration: driver=yenta_cardbus latency=176 maxlatency=5 mingnt=192 module=yenta_socket
           *-storage
                description: Mass storage controller
                product: 5-in-1 Multimedia Card Reader (SD/MMC/MS/MS PRO/xD)
                vendor: Texas Instruments
                physical id: 9.2
                bus info: pci at 0000:0a:09.2
                version: 00
                width: 32 bits
                clock: 33MHz
                capabilities: storage pm bus_master cap_list
                configuration: driver=tifm_7xx1 latency=57 maxlatency=4 mingnt=7 module=tifm_7xx1
        *-isa
             description: ISA bridge
             product: 82801GBM (ICH7-M) LPC Interface Bridge
             vendor: Intel Corporation
             physical id: 1f
             bus info: pci at 0000:00:1f.0
             version: 02
             width: 32 bits
             clock: 33MHz
             capabilities: isa bus_master cap_list
             configuration: latency=0
        *-ide
             description: IDE interface
             product: 82801G (ICH7 Family) IDE Controller
             vendor: Intel Corporation
             physical id: 1f.1
             bus info: pci at 0000:00:1f.1
             logical name: scsi0
             version: 02
             width: 32 bits
             clock: 33MHz
             capabilities: ide bus_master emulated
             configuration: driver=ata_piix latency=0 module=ata_piix
           *-disk
                description: ATA Disk
                product: WDC WD600UE-22KV
                vendor: Western Digital
                physical id: 0.0.0
                bus info: scsi at 0:0.0.0
                logical name: /dev/sda
                version: 01.0
                serial: WD-WXC706168376
                size: 55GiB (60GB)
                capabilities: partitioned partitioned:dos
                configuration: ansiversion=5 signature=99621d45
              *-volume:0
                   description: EXT3 volume
                   vendor: Linux
                   physical id: 1
                   bus info: scsi at 0:0.0.0,1
                   logical name: /dev/sda1
                   logical name: /
                   logical name: /dev/.static/dev
                   version: 1.0
                   serial: 882b4528-443a-4576-a243-07d5b4ddaec0
                   size: 8008MiB
                   capacity: 8008MiB
                   capabilities: primary bootable journaled extended_attributes large_files huge_files recover ext3 ext2 initialized
                   configuration: created=2008-04-27 07:04:59 filesystem=ext3 modified=2008-11-05 09:46:03 mount.fstype=ext3 mount.options=rw,relatime,errors=remount-ro,data=ordered mounted=2008-11-05 09:46:03 state=mounted
              *-volume:1
                   description: EXT3 volume
                   vendor: Linux
                   physical id: 2
                   bus info: scsi at 0:0.0.0,2
                   logical name: /dev/sda2
                   logical name: /home
                   version: 1.0
                   serial: 0ca95c4a-57b4-44a1-bf08-12747ea4ad69
                   size: 22GiB
                   capacity: 22GiB
                   capabilities: primary journaled extended_attributes large_files huge_files recover ext3 ext2 initialized
                   configuration: created=2008-04-27 07:05:06 filesystem=ext3 modified=2008-11-05 09:46:03 mount.fstype=ext3 mount.options=rw,relatime,data=ordered mounted=2008-11-05 09:46:03 state=mounted
              *-volume:2
                   description: Linux swap volume
                   physical id: 3
                   bus info: scsi at 0:0.0.0,3
                   logical name: /dev/sda3
                   version: 1
                   serial: 8a970834-12e2-4e0c-b50c-e7ffe7822c60
                   size: 1027MiB
                   capacity: 1027MiB
                   capabilities: primary nofs swap initialized
                   configuration: filesystem=swap pagesize=4096
              *-volume:3
                   description: EXT3 volume
                   vendor: Linux
                   physical id: 4
                   bus info: scsi at 0:0.0.0,4
                   logical name: /dev/sda4
                   version: 1.0
                   serial: 8fda1a18-da46-441c-b951-8d9f8a25cd0a
                   size: 24GiB
                   capacity: 24GiB
                   capabilities: primary journaled extended_attributes large_files huge_files recover ext3 ext2 initialized
                   configuration: created=2007-11-04 01:14:10 filesystem=ext3 modified=2008-11-02 00:07:51 mounted=2008-11-01 22:07:48 state=clean
           *-cdrom
                description: DVD-RAM writer
                product: DVD-RAM SDVD8821
                vendor: PHILIPS
                physical id: 0.1.0
                bus info: scsi at 0:0.1.0
                logical name: /dev/cdrom
                logical name: /dev/dvd
                logical name: /dev/scd0
                logical name: /dev/sr0
                version: EX04
                capabilities: removable audio cd-r cd-rw dvd dvd-r dvd-ram
                configuration: ansiversion=5 status=open
        *-serial UNCLAIMED
             description: SMBus
             product: 82801G (ICH7 Family) SMBus Controller
             vendor: Intel Corporation
             physical id: 1f.3
             bus info: pci at 0000:00:1f.3
             version: 02
             width: 32 bits
             clock: 33MHz
             configuration: latency=0
-------------- next part --------------
-[0000:00]-+-00.0  Intel Corporation Mobile 945GM/PM/GMS, 943/940GML and 945GT Express Memory Controller Hub [8086:27a0]
           +-02.0  Intel Corporation Mobile 945GM/GMS, 943/940GML Express Integrated Graphics Controller [8086:27a2]
           +-02.1  Intel Corporation Mobile 945GM/GMS/GME, 943/940GML Express Integrated Graphics Controller [8086:27a6]
           +-1b.0  Intel Corporation 82801G (ICH7 Family) High Definition Audio Controller [8086:27d8]
           +-1c.0-[0000:02]----00.0  Marvell Technology Group Ltd. 88E8038 PCI-E Fast Ethernet Controller [11ab:4352]
           +-1c.1-[0000:03]--
           +-1c.2-[0000:04]--
           +-1c.3-[0000:05-07]--
           +-1d.0  Intel Corporation 82801G (ICH7 Family) USB UHCI Controller #1 [8086:27c8]
           +-1d.1  Intel Corporation 82801G (ICH7 Family) USB UHCI Controller #2 [8086:27c9]
           +-1d.2  Intel Corporation 82801G (ICH7 Family) USB UHCI Controller #3 [8086:27ca]
           +-1d.3  Intel Corporation 82801G (ICH7 Family) USB UHCI Controller #4 [8086:27cb]
           +-1d.7  Intel Corporation 82801G (ICH7 Family) USB2 EHCI Controller [8086:27cc]
           +-1e.0-[0000:0a-0e]--+-03.0  Atheros Communications Inc. AR2413 802.11bg NIC [168c:001a]
           |                    +-09.0  Texas Instruments PCIxx12 Cardbus Controller [104c:8039]
           |                    \-09.2  Texas Instruments 5-in-1 Multimedia Card Reader (SD/MMC/MS/MS PRO/xD) [104c:803b]
           +-1f.0  Intel Corporation 82801GBM (ICH7-M) LPC Interface Bridge [8086:27b9]
           +-1f.1  Intel Corporation 82801G (ICH7 Family) IDE Controller [8086:27df]
           \-1f.3  Intel Corporation 82801G (ICH7 Family) SMBus Controller [8086:27da]
-------------- next part --------------
A non-text attachment was scrubbed...
Name: mptable.txt
Type: text/x-csrc
Size: 7624 bytes
Desc: not available
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20081105/219278e1/attachment-0001.c>
-------------- next part --------------
superiotool r2976
Probing for ALi Super I/O at 0x3f0...
  Failed. Returned data: id=0xffff, rev=0xff
Probing for ALi Super I/O at 0x370...
  Failed. Returned data: id=0xffff, rev=0xff
Probing for Fintek Super I/O at 0x2e...
  Failed. Returned data: vid=0x0000, id=0x11ec
Probing for Fintek Super I/O at 0x4e...
  Failed. Returned data: vid=0xffff, id=0xffff
Probing for ITE Super I/O (init=0x87,0x01,0x55,0x55/0xaa) at 0x2e...
  Failed. Returned data: id=0xec11, rev=0x0
Probing for ITE Super I/O (init=0x87,0x87) at 0x2e...
  Failed. Returned data: id=0xec11, rev=0x0
Probing for ITE Super I/O (init=0x87,0x01,0x55,0x55/0xaa) at 0x4e...
  Failed. Returned data: id=0xffff, rev=0xf
Probing for ITE Super I/O (init=0x87,0x87) at 0x4e...
  Failed. Returned data: id=0xffff, rev=0xf
Probing for NSC Super I/O at 0x2e...
Found NSC PC87591x (sid=0xec, srid=0xe2) at 0x2e
No dump available for this Super I/O
Probing for NSC Super I/O at 0x4e...
  Failed. Returned data: port=0xff, port+1=0xff
Probing for SMSC Super I/O (idregs=0x20/0x21) at 0x2e...
  Failed. Returned data: id=0xec, rev=0x11
Probing for SMSC Super I/O (idregs=0x0d/0x0e) at 0x2e...
  Failed. Returned data: id=0x00, rev=0x00
Probing for SMSC Super I/O (idregs=0x20/0x21) at 0x4e...
  Failed. Returned data: id=0xff, rev=0xff
Probing for SMSC Super I/O (idregs=0x0d/0x0e) at 0x4e...
  Failed. Returned data: id=0xff, rev=0xff
Probing for SMSC Super I/O (idregs=0x20/0x21) at 0x162e...
  Failed. Returned data: id=0xff, rev=0xff
Probing for SMSC Super I/O (idregs=0x0d/0x0e) at 0x162e...
  Failed. Returned data: id=0xff, rev=0xff
Probing for SMSC Super I/O (idregs=0x20/0x21) at 0x164e...
  Failed. Returned data: id=0xff, rev=0xff
Probing for SMSC Super I/O (idregs=0x0d/0x0e) at 0x164e...
  Failed. Returned data: id=0xff, rev=0xff
Probing for SMSC Super I/O (idregs=0x20/0x21) at 0x3f0...
  Failed. Returned data: id=0xff, rev=0xff
Probing for SMSC Super I/O (idregs=0x0d/0x0e) at 0x3f0...
  Failed. Returned data: id=0xff, rev=0xff
Probing for SMSC Super I/O (idregs=0x20/0x21) at 0x370...
  Failed. Returned data: id=0xff, rev=0xff
Probing for SMSC Super I/O (idregs=0x0d/0x0e) at 0x370...
  Failed. Returned data: id=0xff, rev=0xff
Probing for Winbond Super I/O (init=0x88) at 0x2e...
  Failed. Returned data: id/oldid=0xec/0x00, rev=0x11
Probing for Winbond Super I/O (init=0x89) at 0x2e...
  Failed. Returned data: id/oldid=0xec/0x00, rev=0x11
Probing for Winbond Super I/O (init=0x86,0x86) at 0x2e...
  Failed. Returned data: id/oldid=0xec/0x00, rev=0x11
Probing for Winbond Super I/O (init=0x87,0x87) at 0x2e...
  Failed. Returned data: id/oldid=0xec/0x00, rev=0x11
Probing for Winbond Super I/O (init=0x88) at 0x4e...
  Failed. Returned data: id/oldid=0xff/0x0f, rev=0xff
Probing for Winbond Super I/O (init=0x89) at 0x4e...
  Failed. Returned data: id/oldid=0xff/0x0f, rev=0xff
Probing for Winbond Super I/O (init=0x86,0x86) at 0x4e...
  Failed. Returned data: id/oldid=0xff/0x0f, rev=0xff
Probing for Winbond Super I/O (init=0x87,0x87) at 0x4e...
  Failed. Returned data: id/oldid=0xff/0x0f, rev=0xff
Probing for Winbond Super I/O (init=0x88) at 0x3f0...
  Failed. Returned data: id/oldid=0xff/0x0f, rev=0xff
Probing for Winbond Super I/O (init=0x89) at 0x3f0...
  Failed. Returned data: id/oldid=0xff/0x0f, rev=0xff
Probing for Winbond Super I/O (init=0x86,0x86) at 0x3f0...
  Failed. Returned data: id/oldid=0xff/0x0f, rev=0xff
Probing for Winbond Super I/O (init=0x87,0x87) at 0x3f0...
  Failed. Returned data: id/oldid=0xff/0x0f, rev=0xff
Probing for Winbond Super I/O (init=0x88) at 0x370...
  Failed. Returned data: id/oldid=0xff/0x0f, rev=0xff
Probing for Winbond Super I/O (init=0x89) at 0x370...
  Failed. Returned data: id/oldid=0xff/0x0f, rev=0xff
Probing for Winbond Super I/O (init=0x86,0x86) at 0x370...
  Failed. Returned data: id/oldid=0xff/0x0f, rev=0xff
Probing for Winbond Super I/O (init=0x87,0x87) at 0x370...
  Failed. Returned data: id/oldid=0xff/0x0f, rev=0xff
Probing for Winbond Super I/O (init=0x88) at 0x250...
  Failed. Returned data: id/oldid=0xff/0x0f, rev=0xff
Probing for Winbond Super I/O (init=0x89) at 0x250...
  Failed. Returned data: id/oldid=0xff/0x0f, rev=0xff
Probing for Winbond Super I/O (init=0x86,0x86) at 0x250...
  Failed. Returned data: id/oldid=0xff/0x0f, rev=0xff
Probing for Winbond Super I/O (init=0x87,0x87) at 0x250...
  Failed. Returned data: id/oldid=0xff/0x0f, rev=0xff

From uwe at hermann-uwe.de  Wed Nov  5 14:21:29 2008
From: uwe at hermann-uwe.de (Uwe Hermann)
Date: Wed, 5 Nov 2008 14:21:29 +0100
Subject: [coreboot] Flashrom - verified mainboards
In-Reply-To: <2F3951A78535124D960B1EFBB992F6D10158202D@mailserver.sienet.local>
References: <2F3951A78535124D960B1EFBB992F6D10158202D@mailserver.sienet.local>
Message-ID: <20081105132129.GD13674@greenwood>

On Wed, Nov 05, 2008 at 01:19:20PM +0100, Rogen, Mario wrote:
> Hi...
> I just tested flashrom on a bunch of mainboards:
> 
> SST49LF008A congatec conga-x852 SBC
> (http://www.congatec.com/single_news+M5e8f9751886.html). Read, write and
> erase works out of the box. I also verified with the original congatec
> tool. It reports success!
> SST49LF008A IEI PICOe-9452
> (http://www.iei.com.tw/en/product_IPC.asp?model=PICOe-9452) Everything
> ok... 
> SST39SF040 LEX Systems CV700A
> (http://www.lex.com.tw/product/CV700A_s.htm) Everything works fine...
> SST49LF004A/B Portwell PEB-4700VLA
> (http://www.portwell.com/products/detail.asp?CUSTCHAR1=PEB-4700VLA)
> Everything works fine..

Nice, thanks! Did you run the write with the -v (verify) option a la
'flashrom -wv foo.rom' and did it report "VERIFIED"?

Did a 'flashrom -E', 'flashrom -r empty.rom', 'hexdump -C empty.rom'
report only 0xff lines?

If yes, all of the boards do work nicely out of the box, indeed. We
can then update the flashrom code and the wiki.

Btw, the LEX Systems CV700A has a VIA VN700 / VT8237R chipset, so it
could be supported by coreboot quite easily, if you're interested.


Cheers, Uwe.
-- 
http://www.hermann-uwe.de  | http://www.holsham-traders.de
http://www.crazy-hacks.org | http://www.unmaintained-free-software.org



From Mario.Rogen at sie.at  Wed Nov  5 14:49:24 2008
From: Mario.Rogen at sie.at (Rogen, Mario)
Date: Wed, 5 Nov 2008 14:49:24 +0100
Subject: [coreboot] Flashrom - verified mainboards
References: <2F3951A78535124D960B1EFBB992F6D10158202D@mailserver.sienet.local>
	<20081105132129.GD13674@greenwood>
Message-ID: <2F3951A78535124D960B1EFBB992F6D101582034@mailserver.sienet.local>


I've written a rom file with 'flashrom -w romfile.rom' and verified
afterwards with 'flashrom -v romfile.rom'. The result was "VERIFIED"!
On the congatec board I just tried to erase and read again, have a look
at the attached output... I don't know if it's correct...

To the other systems i currently don't have access, i hope i'll be able
to try the erase and read procedure in the future.. 
The write and verify worked out of the box! If you need, i can provide
logfiles from the write and verify of each board!

-----Original Message-----
From: Uwe Hermann [mailto:uwe at hermann-uwe.de] 
Sent: Wednesday, November 05, 2008 2:21 PM
To: Rogen, Mario
Cc: coreboot at coreboot.org
Subject: Re: [coreboot] Flashrom - verified mainboards

On Wed, Nov 05, 2008 at 01:19:20PM +0100, Rogen, Mario wrote:
> Hi...
> I just tested flashrom on a bunch of mainboards:
> 
> SST49LF008A congatec conga-x852 SBC
> (http://www.congatec.com/single_news+M5e8f9751886.html). Read, write 
> and erase works out of the box. I also verified with the original 
> congatec tool. It reports success!
> SST49LF008A IEI PICOe-9452
> (http://www.iei.com.tw/en/product_IPC.asp?model=PICOe-9452) Everything

> ok...
> SST39SF040 LEX Systems CV700A
> (http://www.lex.com.tw/product/CV700A_s.htm) Everything works fine...
> SST49LF004A/B Portwell PEB-4700VLA
> (http://www.portwell.com/products/detail.asp?CUSTCHAR1=PEB-4700VLA)
> Everything works fine..

Nice, thanks! Did you run the write with the -v (verify) option a la
'flashrom -wv foo.rom' and did it report "VERIFIED"?

Did a 'flashrom -E', 'flashrom -r empty.rom', 'hexdump -C empty.rom'
report only 0xff lines?

If yes, all of the boards do work nicely out of the box, indeed. We can
then update the flashrom code and the wiki.

Btw, the LEX Systems CV700A has a VIA VN700 / VT8237R chipset, so it
could be supported by coreboot quite easily, if you're interested.


Cheers, Uwe.
--
http://www.hermann-uwe.de  | http://www.holsham-traders.de
http://www.crazy-hacks.org | http://www.unmaintained-free-software.org
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: biosflash.txt
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20081105/c9121a03/attachment.txt>

From JRottmann at LiPPERTEmbedded.de  Wed Nov  5 15:41:08 2008
From: JRottmann at LiPPERTEmbedded.de (Jens Rottmann)
Date: Wed, 05 Nov 2008 15:41:08 +0100
Subject: [coreboot] new board: LiPPERT Cool SpaceRunner-LX
In-Reply-To: <20081104004415.GA23206@greenwood>
References: <48FDDF4C.3080601@LiPPERTEmbedded.de>
	<20081022160617.GI15706@greenwood>
	<4909EBDA.6010008@LiPPERTEmbedded.de>
	<20081030194447.GB28905@greenwood>
	<490EFCF2.2060708@LiPPERTEmbedded.de>
	<20081103160149.GC21829@cosmic.amd.com>
	<20081104004415.GA23206@greenwood>
Message-ID: <4911B084.7010101@LiPPERTEmbedded.de>

Hi,

About the additional (C) AMD thing:

Jordan Crouse wrote:
> If you are just copying the same API calls that all other motherboards
> use, then there is hardly anything to copyright in the first place.
...
> if there are some chunks of unmodified code that are unique to the
> db800 code (such as a local function) then thats a different story

Yes, indeed. And this is exactly the case for cache_as_ram_auto.c, where
e.g. the local function msr_init() was copied whole from DB800 (although
some few other mainboards share it, too, but all of them say (C)AMD).

So, I fully agree with Uwe on the point that cache_as_ram_auto.c needs a
"(C)AMD", and all other files don't.

That's a "no, thanks" for "v2_lippert_c_amd.patch".


About the "Based on" thing:

Here I fully agree with Jordan. I never meant to have several "Based on"
lines appended in one file. I only wanted to show the direct ancestor,
so e.g. someone could make a diff and see what parts are really
SpaceRunner-LX specific and what parts are generic.
If this ancestor had a "Based on" by itself, it might take several steps
to e.g. trace a bug to the board where it was introduced, but that's ok.
And then you could chase down all other boards that might have inherited
this bug ...

"v2_lippert_based_on.patch"
Acked-by: Jens Rottmann <JRottmann at LiPPERTEmbedded.de>

Thanks for listening,  :-)
Jens




From rminnich at gmail.com  Wed Nov  5 16:34:09 2008
From: rminnich at gmail.com (ron minnich)
Date: Wed, 5 Nov 2008 07:34:09 -0800
Subject: [coreboot] Usefull hardware data
In-Reply-To: <1225843019.9109.3.camel@3680>
References: <1225843019.9109.3.camel@3680>
Message-ID: <13426df10811050734h72acde6v7924d3e0809632ee@mail.gmail.com>

thanks! this appears to be an i945-based system and might be a good candidate.

ron



From rminnich at gmail.com  Wed Nov  5 16:41:24 2008
From: rminnich at gmail.com (ron minnich)
Date: Wed, 5 Nov 2008 07:41:24 -0800
Subject: [coreboot] and/or busybox issue with alix2c3 serial console
In-Reply-To: <ec3a010b0811050120v37f2ae2eye1c5fdd276590381@mail.gmail.com>
References: <ec3a010b0811041340q202fc54fkecd64f6099622846@mail.gmail.com>
	<ec3a010b0811041404m2ca70564v4b31fb31458437c2@mail.gmail.com>
	<13426df10811041416h7c0fa3edo1e706e0d723446d9@mail.gmail.com>
	<ec3a010b0811041523l61cebd5dw8586ee413c13257e@mail.gmail.com>
	<13426df10811041543i4001fcbfv7f80a417a7b9d6d6@mail.gmail.com>
	<ec3a010b0811041559x7b743bf6oe24c06e234c83884@mail.gmail.com>
	<13426df10811041601g73e21d4ane791cb00c6d8b9ed@mail.gmail.com>
	<ec3a010b0811041621w62f90e7fm24ff475d83158ced@mail.gmail.com>
	<20081105012426.GD9994@cosmic.amd.com>
	<ec3a010b0811050120v37f2ae2eye1c5fdd276590381@mail.gmail.com>
Message-ID: <13426df10811050741q34cec6fide69b4b647bccabb@mail.gmail.com>

On Wed, Nov 5, 2008 at 1:20 AM, Roman Yeryomin <leroi.lists at gmail.com> wrote:

> Tried your image but no luck. Same behaviour. No serial console.
> All it gave to serial console while booting is in attachment.
> Does it have some ip address and telnet/ssh server? So I could at
> least ping it and see if it booted at all.
>

At this point I am willing to guarantee it's interrupts. The IRQ
wiring on the pc engines is not quite what AMD would say is normal.

This is the problem I had and never fixed. I am surprised that it is
coming up on the 5536 device, however. Do you have any chance of
getting schematics?

ron



From jordan.crouse at amd.com  Wed Nov  5 16:55:10 2008
From: jordan.crouse at amd.com (Jordan Crouse)
Date: Wed, 5 Nov 2008 08:55:10 -0700
Subject: [coreboot] and/or busybox issue with alix2c3 serial console
In-Reply-To: <13426df10811042017t16b3e9edw8a4d20f2667fca04@mail.gmail.com>
References: <20081104215327.GE5424@cosmic.amd.com>
	<ec3a010b0811041404m2ca70564v4b31fb31458437c2@mail.gmail.com>
	<13426df10811041416h7c0fa3edo1e706e0d723446d9@mail.gmail.com>
	<ec3a010b0811041523l61cebd5dw8586ee413c13257e@mail.gmail.com>
	<13426df10811041543i4001fcbfv7f80a417a7b9d6d6@mail.gmail.com>
	<ec3a010b0811041559x7b743bf6oe24c06e234c83884@mail.gmail.com>
	<13426df10811041601g73e21d4ane791cb00c6d8b9ed@mail.gmail.com>
	<ec3a010b0811041621w62f90e7fm24ff475d83158ced@mail.gmail.com>
	<20081105012426.GD9994@cosmic.amd.com>
	<13426df10811042017t16b3e9edw8a4d20f2667fca04@mail.gmail.com>
Message-ID: <20081105155509.GE9994@cosmic.amd.com>

On 04/11/08 20:17 -0800, ron minnich wrote:
> On Tue, Nov 4, 2008 at 5:24 PM, Jordan Crouse <jordan.crouse at amd.com> wrote:
> > It just occured to me, I use a busybox based image for my Geode... :)
> 
> which geode is it? I am convinced there is something "different" about
> the pcengines boards. I love those boards, but let's see.

I use the same image for all of my Geodes, but in this case this was
a Norwich.

Jordan

-- 
Jordan Crouse
Systems Software Development Engineer 
Advanced Micro Devices, Inc.




From jordan.crouse at amd.com  Wed Nov  5 17:08:33 2008
From: jordan.crouse at amd.com (Jordan Crouse)
Date: Wed, 5 Nov 2008 09:08:33 -0700
Subject: [coreboot] LAB question
In-Reply-To: <3173667609B54C429D53E1F9E457B1F8@who8>
References: <3173667609B54C429D53E1F9E457B1F8@who8>
Message-ID: <20081105160833.GA23167@cosmic.amd.com>

On 04/11/08 21:04 -0500, Gregg C Levine wrote:
> Hello!
> As always I am looking at new ideas.
> One that has occurred to me on numerous occasions is that of the idea of
> using Linux as a boot loader.
> 
> I know it has been discussed on several occasions on this list, however I
> don't recall what was resolved about it. What has been resolved about it?
> And on what machines does it work? (This includes chipsets.)

LAB is still a going concern - we have a number of platforms in
buildrom that can build a LAB payload.  The problem with LAB that
it requires a lot of effort for each platform, so the overall
quality of the LAB payloads depends on if somebody is actively
working that particular platform.  With the progress of the 
kernel and the userland stuff, LAB payloads have a tendency to 
bitrot rather quickly.  New support and development is always
welcome.  You might also want to look at kexecboot:

http://git.linuxtogo.org/?p=thesing/kexecboot.git;a=tree

Which could be a reasonable replacement for the uclibc/busybox/kexec
rootfs in buildrom right now.

Jordan

-- 
Jordan Crouse
Systems Software Development Engineer 
Advanced Micro Devices, Inc.




From jordan.crouse at amd.com  Wed Nov  5 17:09:46 2008
From: jordan.crouse at amd.com (Jordan Crouse)
Date: Wed, 5 Nov 2008 09:09:46 -0700
Subject: [coreboot] and/or busybox issue with alix2c3 serial console
In-Reply-To: <20081105090417.12601.qmail@stuge.se>
References: <ec3a010b0811041404m2ca70564v4b31fb31458437c2@mail.gmail.com>
	<13426df10811041416h7c0fa3edo1e706e0d723446d9@mail.gmail.com>
	<ec3a010b0811041523l61cebd5dw8586ee413c13257e@mail.gmail.com>
	<13426df10811041543i4001fcbfv7f80a417a7b9d6d6@mail.gmail.com>
	<ec3a010b0811041559x7b743bf6oe24c06e234c83884@mail.gmail.com>
	<13426df10811041601g73e21d4ane791cb00c6d8b9ed@mail.gmail.com>
	<ec3a010b0811041621w62f90e7fm24ff475d83158ced@mail.gmail.com>
	<20081105012426.GD9994@cosmic.amd.com>
	<13426df10811042017t16b3e9edw8a4d20f2667fca04@mail.gmail.com>
	<20081105090417.12601.qmail@stuge.se>
Message-ID: <20081105160946.GB23167@cosmic.amd.com>

On 05/11/08 10:04 +0100, Peter Stuge wrote:
> ron minnich wrote:
> > > It just occured to me, I use a busybox based image for my Geode... :)
> > 
> > which geode is it? I am convinced there is something "different"
> > about the pcengines boards. I love those boards, but let's see.
> 
> I think the main difference is that alix2 and alix3 have the serial
> port coming out of the 5536 rather than a superio, which is what
> we're used to.
> 
> We just have to get the init right. :)

Not to rain on your parade, but the Norwich doesn't use a superio either. :)

Jordan

> 
> //Peter
> 
> --
> coreboot mailing list: coreboot at coreboot.org
> http://www.coreboot.org/mailman/listinfo/coreboot
> 

-- 
Jordan Crouse
Systems Software Development Engineer 
Advanced Micro Devices, Inc.




From jordan.crouse at amd.com  Wed Nov  5 17:12:05 2008
From: jordan.crouse at amd.com (Jordan Crouse)
Date: Wed, 5 Nov 2008 09:12:05 -0700
Subject: [coreboot] filo fails to compile
In-Reply-To: <20081105093736.GC13674@greenwood>
References: <dd3c80060811042339k7face039idb0fa203f19b3da3@mail.gmail.com>
	<20081105093736.GC13674@greenwood>
Message-ID: <20081105161205.GC23167@cosmic.amd.com>

On 05/11/08 10:37 +0100, Uwe Hermann wrote:
> On Wed, Nov 05, 2008 at 02:39:11AM -0500, Corey Osgood wrote:
> > Build host is Ubuntu 8.04.1, gcc 4.2.4 (Ubuntu 4.2.4-1ubuntu3). I followed
> > the steps at coreboot.org/Filo, console output below. build.sh seems to work
> > fine.
> 
> The wiki needed a small fix (done).
> 
> After typing 'make' in libpayload, you have to also do:
> 
>   $ make DESTDIR=../build install
> 
> The rest of the instructions will then work fine.

You could also set LIBPAYLOAD_PREFIX=./libpayload.

> 
> Uwe.
> -- 
> http://www.hermann-uwe.de  | http://www.holsham-traders.de
> http://www.crazy-hacks.org | http://www.unmaintained-free-software.org
> 
> --
> coreboot mailing list: coreboot at coreboot.org
> http://www.coreboot.org/mailman/listinfo/coreboot
> 

-- 
Jordan Crouse
Systems Software Development Engineer 
Advanced Micro Devices, Inc.




From rminnich at gmail.com  Wed Nov  5 17:24:33 2008
From: rminnich at gmail.com (ron minnich)
Date: Wed, 5 Nov 2008 08:24:33 -0800
Subject: [coreboot] and/or busybox issue with alix2c3 serial console
In-Reply-To: <20081105160946.GB23167@cosmic.amd.com>
References: <ec3a010b0811041404m2ca70564v4b31fb31458437c2@mail.gmail.com>
	<ec3a010b0811041523l61cebd5dw8586ee413c13257e@mail.gmail.com>
	<13426df10811041543i4001fcbfv7f80a417a7b9d6d6@mail.gmail.com>
	<ec3a010b0811041559x7b743bf6oe24c06e234c83884@mail.gmail.com>
	<13426df10811041601g73e21d4ane791cb00c6d8b9ed@mail.gmail.com>
	<ec3a010b0811041621w62f90e7fm24ff475d83158ced@mail.gmail.com>
	<20081105012426.GD9994@cosmic.amd.com>
	<13426df10811042017t16b3e9edw8a4d20f2667fca04@mail.gmail.com>
	<20081105090417.12601.qmail@stuge.se>
	<20081105160946.GB23167@cosmic.amd.com>
Message-ID: <13426df10811050824v58234362y635d1b6a8699943c@mail.gmail.com>

On Wed, Nov 5, 2008 at 8:09 AM, Jordan Crouse <jordan.crouse at amd.com> wrote:

> Not to rain on your parade, but the Norwich doesn't use a superio either. :)

The one thing I know for sure is that the way that alix1c connected
interrupts, and the way it set them up, was not a way that Marc
thought made sense. The pc engines bios did things w.r.t. A,B,C,D that
were not "normal" practice. This difference in turn caused some weird
interaction with vsa. The fact that voyage linux sees ttyS0 with irq0
tells me that this is having an effect.

We have a norwich which works (with v3, jordan?) with same chips as
alix. we have two kernels what work with norwich. Jordan, can you send
a boot log of these or at least tell us what irq they think is
associated with com1?

ron



From jordan.crouse at amd.com  Wed Nov  5 17:32:28 2008
From: jordan.crouse at amd.com (Jordan Crouse)
Date: Wed, 5 Nov 2008 09:32:28 -0700
Subject: [coreboot] and/or busybox issue with alix2c3 serial console
In-Reply-To: <13426df10811050824v58234362y635d1b6a8699943c@mail.gmail.com>
References: <ec3a010b0811041523l61cebd5dw8586ee413c13257e@mail.gmail.com>
	<13426df10811041543i4001fcbfv7f80a417a7b9d6d6@mail.gmail.com>
	<ec3a010b0811041559x7b743bf6oe24c06e234c83884@mail.gmail.com>
	<13426df10811041601g73e21d4ane791cb00c6d8b9ed@mail.gmail.com>
	<ec3a010b0811041621w62f90e7fm24ff475d83158ced@mail.gmail.com>
	<20081105012426.GD9994@cosmic.amd.com>
	<13426df10811042017t16b3e9edw8a4d20f2667fca04@mail.gmail.com>
	<20081105090417.12601.qmail@stuge.se>
	<20081105160946.GB23167@cosmic.amd.com>
	<13426df10811050824v58234362y635d1b6a8699943c@mail.gmail.com>
Message-ID: <20081105163228.GE23167@cosmic.amd.com>

On 05/11/08 08:24 -0800, ron minnich wrote:
> We have a norwich which works (with v3, jordan?) with same chips as
> alix. we have two kernels what work with norwich. Jordan, can you send
> a boot log of these or at least tell us what irq they think is
> associated with com1?

v3 yes.  And the IRQ is 4, natch.... :)  the x86 is still living in 1985,
haven't you heard?

Jordan

-- 
Jordan Crouse
Systems Software Development Engineer 
Advanced Micro Devices, Inc.




From leroi.lists at gmail.com  Wed Nov  5 17:47:27 2008
From: leroi.lists at gmail.com (Roman Yeryomin)
Date: Wed, 5 Nov 2008 18:47:27 +0200
Subject: [coreboot] and/or busybox issue with alix2c3 serial console
In-Reply-To: <13426df10811050741q34cec6fide69b4b647bccabb@mail.gmail.com>
References: <ec3a010b0811041340q202fc54fkecd64f6099622846@mail.gmail.com>
	<ec3a010b0811050120v37f2ae2eye1c5fdd276590381@mail.gmail.com>
	<13426df10811050741q34cec6fide69b4b647bccabb@mail.gmail.com>
Message-ID: <200811051847.28059.leroi.lists@gmail.com>

On Wednesday 05 November 2008 17:41:24 ron minnich wrote:
> On Wed, Nov 5, 2008 at 1:20 AM, Roman Yeryomin <leroi.lists at gmail.com> 
wrote:
> > Tried your image but no luck. Same behaviour. No serial console.
> > All it gave to serial console while booting is in attachment.
> > Does it have some ip address and telnet/ssh server? So I could at
> > least ping it and see if it booted at all.
>
> At this point I am willing to guarantee it's interrupts. The IRQ
> wiring on the pc engines is not quite what AMD would say is normal.
>
> This is the problem I had and never fixed. I am surprised that it is
> coming up on the 5536 device, however. Do you have any chance of
> getting schematics?

Schematics are open and available here:
http://www.pcengines.ch/alix2c3.htm


Roman




From Marc.Jones at amd.com  Wed Nov  5 19:09:06 2008
From: Marc.Jones at amd.com (Marc Jones)
Date: Wed, 5 Nov 2008 11:09:06 -0700
Subject: [coreboot] [patch] and/or busybox issue with alix2c3 serial
	console
In-Reply-To: <200811051847.28059.leroi.lists@gmail.com>
References: <ec3a010b0811041340q202fc54fkecd64f6099622846@mail.gmail.com>
	<ec3a010b0811050120v37f2ae2eye1c5fdd276590381@mail.gmail.com>
	<13426df10811050741q34cec6fide69b4b647bccabb@mail.gmail.com>
	<200811051847.28059.leroi.lists@gmail.com>
Message-ID: <4911E142.5030007@amd.com>

I see the problem. It is interesting that in some situations that it works.

Marc


-- 
Marc Jones
Senior Firmware Engineer
(970) 226-9684 Office
mailto:Marc.Jones at amd.com
http://www.amd.com/embeddedprocessors
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: serialfix.patch
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20081105/37dc8b95/attachment.ksh>

From rminnich at gmail.com  Wed Nov  5 19:12:13 2008
From: rminnich at gmail.com (ron minnich)
Date: Wed, 5 Nov 2008 10:12:13 -0800
Subject: [coreboot] and/or busybox issue with alix2c3 serial console
In-Reply-To: <20081105163228.GE23167@cosmic.amd.com>
References: <ec3a010b0811041523l61cebd5dw8586ee413c13257e@mail.gmail.com>
	<ec3a010b0811041559x7b743bf6oe24c06e234c83884@mail.gmail.com>
	<13426df10811041601g73e21d4ane791cb00c6d8b9ed@mail.gmail.com>
	<ec3a010b0811041621w62f90e7fm24ff475d83158ced@mail.gmail.com>
	<20081105012426.GD9994@cosmic.amd.com>
	<13426df10811042017t16b3e9edw8a4d20f2667fca04@mail.gmail.com>
	<20081105090417.12601.qmail@stuge.se>
	<20081105160946.GB23167@cosmic.amd.com>
	<13426df10811050824v58234362y635d1b6a8699943c@mail.gmail.com>
	<20081105163228.GE23167@cosmic.amd.com>
Message-ID: <13426df10811051012y5df5c955re2d6afc09f7cea51@mail.gmail.com>

On Wed, Nov 5, 2008 at 8:32 AM, Jordan Crouse <jordan.crouse at amd.com> wrote:
> On 05/11/08 08:24 -0800, ron minnich wrote:
>> We have a norwich which works (with v3, jordan?) with same chips as
>> alix. we have two kernels what work with norwich. Jordan, can you send
>> a boot log of these or at least tell us what irq they think is
>> associated with com1?
>
> v3 yes.  And the IRQ is 4, natch.... :)  the x86 is still living in 1985,
> haven't you heard?
>

but voyage on the alix IRQ was *0*. And it worked. now that is weird.

ron



From rminnich at gmail.com  Wed Nov  5 19:12:49 2008
From: rminnich at gmail.com (ron minnich)
Date: Wed, 5 Nov 2008 10:12:49 -0800
Subject: [coreboot] [patch] and/or busybox issue with alix2c3 serial
	console
In-Reply-To: <4911E142.5030007@amd.com>
References: <ec3a010b0811041340q202fc54fkecd64f6099622846@mail.gmail.com>
	<ec3a010b0811050120v37f2ae2eye1c5fdd276590381@mail.gmail.com>
	<13426df10811050741q34cec6fide69b4b647bccabb@mail.gmail.com>
	<200811051847.28059.leroi.lists@gmail.com> <4911E142.5030007@amd.com>
Message-ID: <13426df10811051012o62d44d2en222139f030be942@mail.gmail.com>

Acked-by: Ronald G. Minnich <rminnich at gmail.com>



From mylesgw at gmail.com  Wed Nov  5 19:27:41 2008
From: mylesgw at gmail.com (Myles Watson)
Date: Wed, 5 Nov 2008 12:27:41 -0600
Subject: [coreboot] More device cleanup
Message-ID: <2831fecf0811051027v4459cb49k9b7ca8e15a01b50b@mail.gmail.com>

This patch continues the device code cleanup.

The largest changes are to get_pci_bridge_ops, and related changes to make
it
compile and use correct declarations.  I'd appreciate someone else checking
my const usage for sanity.

While I was doing that I moved the checks for CONFIG_<BUS>_PLUGIN_SUPPORT to
the Makefile.

The only functional difference is a possible NULL dereference in a debug
statement.

Signed-off-by: Myles Watson <mylesgw at gmail.com>

Thanks,
Myles
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20081105/6e03f93b/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: cleanup_device.diff
Type: text/x-patch
Size: 8574 bytes
Desc: not available
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20081105/6e03f93b/attachment.diff>

From mylesgw at gmail.com  Wed Nov  5 19:30:24 2008
From: mylesgw at gmail.com (Myles Watson)
Date: Wed, 5 Nov 2008 12:30:24 -0600
Subject: [coreboot] More device cleanup
In-Reply-To: <2831fecf0811051027v4459cb49k9b7ca8e15a01b50b@mail.gmail.com>
References: <2831fecf0811051027v4459cb49k9b7ca8e15a01b50b@mail.gmail.com>
Message-ID: <2831fecf0811051030k68d92ecs9f1ebee909c1d370@mail.gmail.com>

On Wed, Nov 5, 2008 at 12:27 PM, Myles Watson <mylesgw at gmail.com> wrote:

> This patch continues the device code cleanup.


I forgot the include/device/ changes in the first patch.

Thanks,
Myles

>
> The largest changes are to get_pci_bridge_ops, and related changes to make
> it
> compile and use correct declarations.  I'd appreciate someone else checking
> my const usage for sanity.
>
> While I was doing that I moved the checks for CONFIG_<BUS>_PLUGIN_SUPPORT
> to
> the Makefile.
>
> The only functional difference is a possible NULL dereference in a debug
> statement.
>
> Signed-off-by: Myles Watson <mylesgw at gmail.com>
>
> Thanks,
> Myles
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20081105/1c89846a/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: cleanup_device.diff
Type: text/x-patch
Size: 10780 bytes
Desc: not available
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20081105/1c89846a/attachment.diff>

From mylesgw at gmail.com  Wed Nov  5 19:35:15 2008
From: mylesgw at gmail.com (Myles Watson)
Date: Wed, 5 Nov 2008 12:35:15 -0600
Subject: [coreboot] pci_doc.txt
Message-ID: <2831fecf0811051035s4081773fweb37e1ef1f935460@mail.gmail.com>

I couldn't see a great spot to put this on the wiki, so I decided to attach
it as a plain text file first.  I didn't want to spend too much time on
formatting until we decide where it goes.

This text file explains how the pci_device code works.

Thanks,
Myles
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20081105/f7b137e8/attachment.html>

From mylesgw at gmail.com  Wed Nov  5 19:35:54 2008
From: mylesgw at gmail.com (Myles Watson)
Date: Wed, 5 Nov 2008 12:35:54 -0600
Subject: [coreboot] pci_doc.txt
In-Reply-To: <2831fecf0811051035s4081773fweb37e1ef1f935460@mail.gmail.com>
References: <2831fecf0811051035s4081773fweb37e1ef1f935460@mail.gmail.com>
Message-ID: <2831fecf0811051035m1da07c18id50a519dda207cd5@mail.gmail.com>

On Wed, Nov 5, 2008 at 12:35 PM, Myles Watson <mylesgw at gmail.com> wrote:

> I couldn't see a great spot to put this on the wiki, so I decided to attach
> it as a plain text file first.  I didn't want to spend too much time on
> formatting until we decide where it goes.
>
> This text file explains how the pci_device code works.


This time with attachment.

Myles

>
>
> Thanks,
> Myles
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20081105/c55d36a2/attachment.html>
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: pci_doc.txt
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20081105/c55d36a2/attachment.txt>

From rminnich at gmail.com  Wed Nov  5 19:57:09 2008
From: rminnich at gmail.com (ron minnich)
Date: Wed, 5 Nov 2008 10:57:09 -0800
Subject: [coreboot] pci_doc.txt
In-Reply-To: <2831fecf0811051035m1da07c18id50a519dda207cd5@mail.gmail.com>
References: <2831fecf0811051035s4081773fweb37e1ef1f935460@mail.gmail.com>
	<2831fecf0811051035m1da07c18id50a519dda207cd5@mail.gmail.com>
Message-ID: <13426df10811051057j784c4e46of66091007066bb72@mail.gmail.com>

great start. I will try to amend this as well.

It belongs in the lyx doc but not yet.

ron



From mylesgw at gmail.com  Wed Nov  5 20:17:59 2008
From: mylesgw at gmail.com (Myles Watson)
Date: Wed, 5 Nov 2008 12:17:59 -0700
Subject: [coreboot] pci_doc.txt
In-Reply-To: <13426df10811051057j784c4e46of66091007066bb72@mail.gmail.com>
References: <2831fecf0811051035s4081773fweb37e1ef1f935460@mail.gmail.com>
	<2831fecf0811051035m1da07c18id50a519dda207cd5@mail.gmail.com>
	<13426df10811051057j784c4e46of66091007066bb72@mail.gmail.com>
Message-ID: <2831fecf0811051117x7aef8d45vb9acc38a63882bd7@mail.gmail.com>

On Wed, Nov 5, 2008 at 11:57 AM, ron minnich <rminnich at gmail.com> wrote:

> great start. I will try to amend this as well.


Thanks.


> It belongs in the lyx doc but not yet.


A couple of iterations will do it good.

Thanks,
Myles
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20081105/2c6f7c2d/attachment.html>

From rminnich at gmail.com  Wed Nov  5 20:21:20 2008
From: rminnich at gmail.com (ron minnich)
Date: Wed, 5 Nov 2008 11:21:20 -0800
Subject: [coreboot] More device cleanup
In-Reply-To: <2831fecf0811051030k68d92ecs9f1ebee909c1d370@mail.gmail.com>
References: <2831fecf0811051027v4459cb49k9b7ca8e15a01b50b@mail.gmail.com>
	<2831fecf0811051030k68d92ecs9f1ebee909c1d370@mail.gmail.com>
Message-ID: <13426df10811051121k2b10bd1ege897d24ee0f98105@mail.gmail.com>

Are you testing these on qemu I assume?

ron



From mylesgw at gmail.com  Wed Nov  5 20:24:57 2008
From: mylesgw at gmail.com (Myles Watson)
Date: Wed, 5 Nov 2008 12:24:57 -0700
Subject: [coreboot] More device cleanup
In-Reply-To: <13426df10811051121k2b10bd1ege897d24ee0f98105@mail.gmail.com>
References: <2831fecf0811051027v4459cb49k9b7ca8e15a01b50b@mail.gmail.com>
	<2831fecf0811051030k68d92ecs9f1ebee909c1d370@mail.gmail.com>
	<13426df10811051121k2b10bd1ege897d24ee0f98105@mail.gmail.com>
Message-ID: <58215E5D00334698ACC994E1BE778639@chimp>

> Are you testing these on qemu I assume?

I can.  I don't think I've made any functional changes, but it's probably
good to check.

Most of this patch isn't exercised by qemu, though.  There are no bridges
which are not in the dts.

Thanks,
Myles




From rminnich at gmail.com  Wed Nov  5 20:23:31 2008
From: rminnich at gmail.com (ron minnich)
Date: Wed, 5 Nov 2008 11:23:31 -0800
Subject: [coreboot] More device cleanup
In-Reply-To: <2831fecf0811051030k68d92ecs9f1ebee909c1d370@mail.gmail.com>
References: <2831fecf0811051027v4459cb49k9b7ca8e15a01b50b@mail.gmail.com>
	<2831fecf0811051030k68d92ecs9f1ebee909c1d370@mail.gmail.com>
Message-ID: <13426df10811051123l1ff5190djc30046b6541bb891@mail.gmail.com>

looks good, not build or boot tested.

Acked-by: Ronald G. Minnich <rminnich at gmail.com>



From mylesgw at gmail.com  Wed Nov  5 21:24:33 2008
From: mylesgw at gmail.com (Myles Watson)
Date: Wed, 5 Nov 2008 14:24:33 -0600
Subject: [coreboot] More device cleanup
In-Reply-To: <58215E5D00334698ACC994E1BE778639@chimp>
References: <2831fecf0811051027v4459cb49k9b7ca8e15a01b50b@mail.gmail.com>
	<2831fecf0811051030k68d92ecs9f1ebee909c1d370@mail.gmail.com>
	<13426df10811051121k2b10bd1ege897d24ee0f98105@mail.gmail.com>
	<58215E5D00334698ACC994E1BE778639@chimp>
Message-ID: <2831fecf0811051224s732db3aag401f8e06c19913c3@mail.gmail.com>

On Wed, Nov 5, 2008 at 1:24 PM, Myles Watson <mylesgw at gmail.com> wrote:

> > Are you testing these on qemu I assume?
>
> I can.  I don't think I've made any functional changes, but it's probably
> good to check.
>
> Most of this patch isn't exercised by qemu, though.  There are no bridges
> which are not in the dts.
>

It turns out that I forgot the importance of make clean for build testing.
I wish I knew better how to fix the dependencies.

This breaks the build now that I made the change for the pci_ops structs to
be const.

From leroi.lists at gmail.com  Wed Nov  5 22:35:34 2008
From: leroi.lists at gmail.com (Roman Yeryomin)
Date: Wed, 5 Nov 2008 23:35:34 +0200
Subject: [coreboot] [patch] and/or busybox issue with alix2c3 serial
	console
In-Reply-To: <4911E142.5030007@amd.com>
References: <ec3a010b0811041340q202fc54fkecd64f6099622846@mail.gmail.com>
	<ec3a010b0811050120v37f2ae2eye1c5fdd276590381@mail.gmail.com>
	<13426df10811050741q34cec6fide69b4b647bccabb@mail.gmail.com>
	<200811051847.28059.leroi.lists@gmail.com> <4911E142.5030007@amd.com>
Message-ID: <ec3a010b0811051335y58803e82r3cfe7cdba6fbd29b@mail.gmail.com>

On Wed, Nov 5, 2008 at 8:09 PM, Marc Jones <Marc.Jones at amd.com> wrote:
> I see the problem. It is interesting that in some situations that it works.
>
> Marc
>
>
> --
> Marc Jones
> Senior Firmware Engineer
> (970) 226-9684 Office
> mailto:Marc.Jones at amd.com
> http://www.amd.com/embeddedprocessors
>
> LPC serial IRQs were being left enabled when there is no LPC serial device.
>
> Signed-off-by: Marc Jones <marc.jones at amd.com>
>
>
> Index: mainboard/pcengines/alix2c3/dts
> ===================================================================
> --- mainboard/pcengines/alix2c3/dts     (revision 980)
> +++ mainboard/pcengines/alix2c3/dts     (working copy)
> @@ -34,9 +34,9 @@
>                        /config/("southbridge/amd/cs5536/dts");
>                        /* Interrupt enables for LPC bus.
>                         *  Each bit is an IRQ 0-15. */
> -                       lpc_serirq_enable = "0x0000105A";
> +                       lpc_serirq_enable = "0x00001002";
>                        /* LPC IRQ polarity. Each bit is an IRQ 0-15. */
> -                       lpc_serirq_polarity = "0x0000EFA5";
> +                       lpc_serirq_polarity = "0x0000EFFD";
>                        /* 0:continuous 1:quiet */
>                        lpc_serirq_mode = "1";
>                        /* GPIO(0-0x20) for INT D:C:B:A, 0xFF=none.
>
>

tried this with my mods but didn't work
will try a clean build now..


Roman



From rminnich at gmail.com  Wed Nov  5 22:42:49 2008
From: rminnich at gmail.com (ron minnich)
Date: Wed, 5 Nov 2008 13:42:49 -0800
Subject: [coreboot] More device cleanup
In-Reply-To: <2831fecf0811051224s732db3aag401f8e06c19913c3@mail.gmail.com>
References: <2831fecf0811051027v4459cb49k9b7ca8e15a01b50b@mail.gmail.com>
	<2831fecf0811051030k68d92ecs9f1ebee909c1d370@mail.gmail.com>
	<13426df10811051121k2b10bd1ege897d24ee0f98105@mail.gmail.com>
	<58215E5D00334698ACC994E1BE778639@chimp>
	<2831fecf0811051224s732db3aag401f8e06c19913c3@mail.gmail.com>
Message-ID: <13426df10811051342g315ca9d6r3729b2d78b39ece2@mail.gmail.com>

>
> /** Set the method to be used for PCI, type I or type II
>  */
> void pci_set_method(struct device * dev)
> {
>     printk(BIOS_INFO, "Finding PCI configuration type.\n");
>     dev->ops->ops_pci_bus = pci_check_direct();
>     post_code(POST_STAGE2_PHASE2_PCI_SET_METHOD);
> }
>


yeah, just set it. This is historical from when we supported type i or
type ii, but nobody uses type ii



ron



From mylesgw at gmail.com  Wed Nov  5 22:48:20 2008
From: mylesgw at gmail.com (Myles Watson)
Date: Wed, 5 Nov 2008 15:48:20 -0600
Subject: [coreboot] More device cleanup
In-Reply-To: <13426df10811051342g315ca9d6r3729b2d78b39ece2@mail.gmail.com>
References: <2831fecf0811051027v4459cb49k9b7ca8e15a01b50b@mail.gmail.com>
	<2831fecf0811051030k68d92ecs9f1ebee909c1d370@mail.gmail.com>
	<13426df10811051121k2b10bd1ege897d24ee0f98105@mail.gmail.com>
	<58215E5D00334698ACC994E1BE778639@chimp>
	<2831fecf0811051224s732db3aag401f8e06c19913c3@mail.gmail.com>
	<13426df10811051342g315ca9d6r3729b2d78b39ece2@mail.gmail.com>
Message-ID: <2831fecf0811051348t78235fc4ua84bea47b299ae@mail.gmail.com>

On Wed, Nov 5, 2008 at 3:42 PM, ron minnich <rminnich at gmail.com> wrote:

> >
> > /** Set the method to be used for PCI, type I or type II
> >  */
> > void pci_set_method(struct device * dev)
> > {
> >     printk(BIOS_INFO, "Finding PCI configuration type.\n");
> >     dev->ops->ops_pci_bus = pci_check_direct();
> >     post_code(POST_STAGE2_PHASE2_PCI_SET_METHOD);
> > }
> >
>
>
> yeah, just set it. This is historical from when we supported type i or
> type ii, but nobody uses type ii


I left the infrastructure there so that it could be easily used for
memory-mapped checking.  Otherwise the whole file needs to die.

I also changed the function call, since it was only using the device pointer
to set the operations.  Now it uses the device pointer to tell it which ops
to check.

Signed-off-by: Myles Watson <mylesgw at gmail.com>

With this change, my other patch is build tested for qemu, norwich, &
serengeti.

Run-tested on qemu & serengeti.

Thanks,
Myles
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20081105/b5589425/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: we_dont_do_type_2.diff
Type: text/x-patch
Size: 2262 bytes
Desc: not available
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20081105/b5589425/attachment.diff>

From svn at coreboot.org  Wed Nov  5 22:50:25 2008
From: svn at coreboot.org (svn at coreboot.org)
Date: Wed,  5 Nov 2008 22:50:25 +0100
Subject: [coreboot] r981 - coreboot-v3/southbridge/amd/cs5536
Message-ID: <mailman.2387.1355071425.16123.coreboot@coreboot.org>

Author: myles
Date: 2008-11-05 22:50:25 +0100 (Wed, 05 Nov 2008)
New Revision: 981

Modified:
   coreboot-v3/southbridge/amd/cs5536/cs5536.c
Log:
This patch removes a warning by making the struct pointer const.  

Signed-off-by: Myles Watson <mylesgw at gmail.com>
Acked-by: Myles Watson <mylesgw at gmail.com>


Modified: coreboot-v3/southbridge/amd/cs5536/cs5536.c
===================================================================
--- coreboot-v3/southbridge/amd/cs5536/cs5536.c	2008-11-04 21:32:59 UTC (rev 980)
+++ coreboot-v3/southbridge/amd/cs5536/cs5536.c	2008-11-05 21:50:25 UTC (rev 981)
@@ -563,7 +563,7 @@
 	if (!IsS3Resume())
 #endif
 	{
-		struct acpi_init *aci = acpi_init_table;
+		const struct acpi_init *aci = acpi_init_table;
 		for (; aci->ioreg; aci++) {
 			outl(aci->regdata, aci->ioreg);
 			inl(aci->ioreg);




From rminnich at gmail.com  Wed Nov  5 23:14:54 2008
From: rminnich at gmail.com (ron minnich)
Date: Wed, 5 Nov 2008 14:14:54 -0800
Subject: [coreboot] More device cleanup
In-Reply-To: <2831fecf0811051348t78235fc4ua84bea47b299ae@mail.gmail.com>
References: <2831fecf0811051027v4459cb49k9b7ca8e15a01b50b@mail.gmail.com>
	<2831fecf0811051030k68d92ecs9f1ebee909c1d370@mail.gmail.com>
	<13426df10811051121k2b10bd1ege897d24ee0f98105@mail.gmail.com>
	<58215E5D00334698ACC994E1BE778639@chimp>
	<2831fecf0811051224s732db3aag401f8e06c19913c3@mail.gmail.com>
	<13426df10811051342g315ca9d6r3729b2d78b39ece2@mail.gmail.com>
	<2831fecf0811051348t78235fc4ua84bea47b299ae@mail.gmail.com>
Message-ID: <13426df10811051414l7c383db5vcc7c9ae8411101d1@mail.gmail.com>

Acked-by: Ronald G. Minnich <rminnich at gmail.com>



From svn at coreboot.org  Wed Nov  5 23:18:54 2008
From: svn at coreboot.org (svn at coreboot.org)
Date: Wed,  5 Nov 2008 23:18:54 +0100
Subject: [coreboot] r982 - in coreboot-v3: arch/x86 include/arch/x86
	northbridge/amd/geodelx
Message-ID: <mailman.2388.1355071425.16123.coreboot@coreboot.org>

Author: myles
Date: 2008-11-05 23:18:53 +0100 (Wed, 05 Nov 2008)
New Revision: 982

Modified:
   coreboot-v3/arch/x86/pci_ops_auto.c
   coreboot-v3/include/arch/x86/pci_ops.h
   coreboot-v3/northbridge/amd/geodelx/geodelx.c
Log:
This patch removes code related to PCI type 2 configuration cycles (gone as of
PCI 2.2)

Signed-off-by: Myles Watson <mylesgw at gmail.com>
Acked-by: Ronald G. Minnich <rminnich at gmail.com>


Modified: coreboot-v3/arch/x86/pci_ops_auto.c
===================================================================
--- coreboot-v3/arch/x86/pci_ops_auto.c	2008-11-05 21:50:25 UTC (rev 981)
+++ coreboot-v3/arch/x86/pci_ops_auto.c	2008-11-05 22:18:53 UTC (rev 982)
@@ -15,7 +15,7 @@
 	.write8  = pci_conf1_write_config8,
 	.write16 = pci_conf1_write_config16,
 	.write32 = pci_conf1_write_config32,
-	.find = 	pci_conf1_find_device,
+	.find = pci_conf1_find_device,
 };
 
 
@@ -53,36 +53,27 @@
 	return 0;
 }
 
-const struct pci_bus_operations *pci_check_direct(void)
+void pci_check_pci_ops(const struct pci_bus_operations *ops)
 {
 	unsigned int tmp;
 
 	/*
-	 * Check if configuration type 1 works.
+	 * Check if configuration cycles work.
 	 */
+	if (ops == &pci_cf8_conf1)
 	{
 		outb(0x01, 0xCFB);
 		tmp = inl(0xCF8);
 		outl(0x80000000, 0xCF8);
 		if ((inl(0xCF8) == 0x80000000) && 
-			pci_sanity_check(&pci_cf8_conf1)) 
+			pci_sanity_check(ops)) 
 		{
 			outl(tmp, 0xCF8);
 			printk(BIOS_DEBUG, "PCI: Using configuration type 1\n");
-			return &pci_cf8_conf1;
+			return;
 		}
 		outl(tmp, 0xCF8);
 	}
 
-	die("pci_check_direct failed\n");
-	return NULL;
+	die("pci_check_pci_ops failed\n");
 }
-
-/** Set the method to be used for PCI, type I or type II
- */
-void pci_set_method(struct device * dev)
-{
-	printk(BIOS_INFO, "Finding PCI configuration type.\n");
-	dev->ops->ops_pci_bus = pci_check_direct();
-	post_code(POST_STAGE2_PHASE2_PCI_SET_METHOD);
-}

Modified: coreboot-v3/include/arch/x86/pci_ops.h
===================================================================
--- coreboot-v3/include/arch/x86/pci_ops.h	2008-11-05 21:50:25 UTC (rev 981)
+++ coreboot-v3/include/arch/x86/pci_ops.h	2008-11-05 22:18:53 UTC (rev 982)
@@ -25,6 +25,6 @@
 extern const struct pci_bus_operations pci_ops_mmconf;
 #endif
 
-void pci_set_method(struct device * dev);
+void pci_check_pci_ops(const struct pci_bus_operations * ops);
 
 #endif /* ARCH_X86_PCI_OPS_H */

Modified: coreboot-v3/northbridge/amd/geodelx/geodelx.c
===================================================================
--- coreboot-v3/northbridge/amd/geodelx/geodelx.c	2008-11-05 21:50:25 UTC (rev 981)
+++ coreboot-v3/northbridge/amd/geodelx/geodelx.c	2008-11-05 22:18:53 UTC (rev 982)
@@ -196,7 +196,7 @@
 	/* print_conf(); */
 	printk(BIOS_DEBUG, "VRC_VG value: 0x%04x\n", nb_dm->geode_video_mb);
 	graphics_init((u8)nb_dm->geode_video_mb);
-	pci_set_method(dev);
+	pci_check_pci_ops(dev->ops->ops_pci_bus);
 }
 
 /**




From svn at coreboot.org  Wed Nov  5 23:27:37 2008
From: svn at coreboot.org (svn at coreboot.org)
Date: Wed,  5 Nov 2008 23:27:37 +0100
Subject: [coreboot] r983 - in coreboot-v3: device include/device
Message-ID: <mailman.2389.1355071425.16123.coreboot@coreboot.org>

Author: myles
Date: 2008-11-05 23:27:36 +0100 (Wed, 05 Nov 2008)
New Revision: 983

Modified:
   coreboot-v3/device/Makefile
   coreboot-v3/device/cardbus_device.c
   coreboot-v3/device/device.c
   coreboot-v3/device/pci_device.c
   coreboot-v3/device/pcie_device.c
   coreboot-v3/include/device/cardbus.h
   coreboot-v3/include/device/device.h
   coreboot-v3/include/device/pci.h
   coreboot-v3/include/device/pcie.h
Log:
This patch continues the device code cleanup.

The largest changes are to get_pci_bridge_ops, and related changes to make it
compile and use correct declarations.  

While I was doing that I moved the checks for CONFIG_<BUS>_PLUGIN_SUPPORT to
the Makefile.

The only functional difference is a possible NULL dereference in a debug
statement.

I also added a few more consts, now that my other patch is in.

Signed-off-by: Myles Watson <mylesgw at gmail.com>
Acked-by: Ronald G. Minnich <rminnich at gmail.com>


Modified: coreboot-v3/device/Makefile
===================================================================
--- coreboot-v3/device/Makefile	2008-11-05 22:18:53 UTC (rev 982)
+++ coreboot-v3/device/Makefile	2008-11-05 22:27:36 UTC (rev 983)
@@ -29,13 +29,27 @@
 			smbus_ops.c
 
 # this is only needed on the K8
+# This could also check for CONFIG_HYPERTRANSPORT_PLUGIN_SUPPORT
 ifeq ($(CONFIG_NORTHBRIDGE_AMD_K8),y)
 STAGE2_DEVICE_SRC += hypertransport.c
 endif
 
 # this is only needed for pcix devices
+# This should also check for CONFIG_PCIX_PLUGIN_SUPPORT
 ifeq ($(CONFIG_SOUTHBRIDGE_AMD_AMD8132),y)
 STAGE2_DEVICE_SRC += pcix_device.c
 endif
 
+ifeq ($(CONFIG_PCIE_PLUGIN_SUPPORT),y)
+STAGE2_DEVICE_SRC += pcie_device.c
+endif
+
+ifeq ($(CONFIG_CARDBUS_PLUGIN_SUPPORT),y)
+STAGE2_DEVICE_SRC += cardbus_device.c
+endif
+
+ifeq ($(CONFIG_AGP_PLUGIN_SUPPORT),y)
+STAGE2_DEVICE_SRC += agp_device.c
+endif
+
 $(obj)/device/pci_device.o: $(src)/device/pci_device.c $(obj)/statictree.h

Modified: coreboot-v3/device/cardbus_device.c
===================================================================
--- coreboot-v3/device/cardbus_device.c	2008-11-05 22:18:53 UTC (rev 982)
+++ coreboot-v3/device/cardbus_device.c	2008-11-05 22:27:36 UTC (rev 983)
@@ -94,7 +94,6 @@
 	resource_t moving_base, moving_limit, moving;
 	unsigned long type;
 	u16 ctl;
-	unsigned long index;
 
 	/* See if needs a card control registers base address. */
 
@@ -243,11 +242,10 @@
 }
 
 const struct device_operations default_cardbus_ops_bus = {
-	.read_resources   = cardbus_read_resources,
-	.set_resources    = pci_dev_set_resources,
-	.enable_resources = cardbus_enable_resources,
-	.init             = 0,
-	.scan_bus         = cardbus_scan_bridge,
-	.enable           = 0,
-	.reset_bus        = pci_bus_reset,
+	.phase3_scan             = cardbus_scan_bridge,
+	.phase4_read_resources   = cardbus_read_resources,
+	.phase4_set_resources    = pci_dev_set_resources,
+	.phase5_enable_resources = cardbus_enable_resources,
+	.phase6_init             = 0,
+	.reset_bus               = pci_bus_reset,
 };

Modified: coreboot-v3/device/device.c
===================================================================
--- coreboot-v3/device/device.c	2008-11-05 22:18:53 UTC (rev 982)
+++ coreboot-v3/device/device.c	2008-11-05 22:27:36 UTC (rev 983)
@@ -101,7 +101,7 @@
  * @param dev Pointer to the newly created device structure.
  * @param ops Pointer to device_operations
  */
-void default_device_constructor(struct device *dev, struct device_operations *ops)
+void default_device_constructor(struct device *dev, const struct device_operations *ops)
 {
 	printk(BIOS_DEBUG, "default device constructor called\n");
 	dev->ops = ops;
@@ -146,7 +146,7 @@
 void dev_init(void)
 {
 	struct device *dev;
-	struct device_operations *c;
+	const struct device_operations *c;
 
 	for (dev = all_devices; dev; dev = dev->next) {
 		c = dev->ops;
@@ -177,7 +177,7 @@
  */
 void constructor(struct device *dev)
 {
-	struct device_operations *c;
+	const struct device_operations *c;
 
 	c = dev->ops;
 

Modified: coreboot-v3/device/pci_device.c
===================================================================
--- coreboot-v3/device/pci_device.c	2008-11-05 22:18:53 UTC (rev 982)
+++ coreboot-v3/device/pci_device.c	2008-11-05 22:27:36 UTC (rev 983)
@@ -30,28 +30,7 @@
 #include <device/device.h>
 #include <device/pci.h>
 #include <device/pci_ids.h>
-/* We should move these so they're really config options */
-#define CONFIG_HYPERTRANSPORT_PLUGIN_SUPPORT 0
-#define CONFIG_PCIX_PLUGIN_SUPPORT 0
-#define CONFIG_PCIE_PLUGIN_SUPPORT 0
-#define CONFIG_CARDBUS_PLUGIN_SUPPORT 0
-#define CONFIG_AGP_PLUGIN_SUPPORT 0
 
-#if CONFIG_HYPERTRANSPORT_PLUGIN_SUPPORT == 1
-#include <device/hypertransport.h>
-#endif
-#if CONFIG_PCIX_PLUGIN_SUPPORT == 1
-#include <device/pcix.h>
-#endif
-#if CONFIG_PCIE_PLUGIN_SUPPORT == 1
-#include <device/pcie.h>
-#endif
-#if CONFIG_AGP_PLUGIN_SUPPORT == 1
-#include <device/agp.h>
-#endif
-#if CONFIG_CARDBUS_PLUGIN_SUPPORT == 1
-#include <device/cardbus.h>
-#endif
 #include <statictree.h>
 
 u8 pci_moving_config8(struct device *dev, unsigned int reg)
@@ -759,11 +738,11 @@
 }
 
 /** Default device operation for PCI devices. */
-struct pci_operations pci_dev_ops_pci = {
+const struct pci_operations pci_dev_ops_pci = {
 	.set_subsystem = pci_dev_set_subsystem,
 };
 
-struct device_operations default_pci_ops_dev = {
+const struct device_operations default_pci_ops_dev = {
 	.phase4_read_resources   = pci_dev_read_resources,
 	.phase4_set_resources    = pci_dev_set_resources,
 	.phase5_enable_resources = pci_dev_enable_resources,
@@ -773,11 +752,11 @@
 };
 
 /** Default device operations for PCI bridges. */
-struct pci_operations pci_bus_ops_pci = {
+const struct pci_operations pci_bus_ops_pci = {
 	.set_subsystem = 0,
 };
 
-struct device_operations default_pci_ops_bus = {
+const struct device_operations default_pci_ops_bus = {
 	.phase3_scan             = pci_scan_bridge,
 	.phase4_read_resources   = pci_bus_read_resources,
 	.phase4_set_resources    = pci_dev_set_resources,
@@ -801,26 +780,28 @@
  * @param dev Pointer to the device structure of the bridge.
  * @return Appropriate bridge operations.
  */
-static struct device_operations *get_pci_bridge_ops(struct device *dev)
+static const struct device_operations *get_pci_bridge_ops(struct device *dev)
 {
-	// unsigned int pos;
-
-#if CONFIG_PCIX_PLUGIN_SUPPORT == 1
-	pos = pci_find_capability(dev, PCI_CAP_ID_PCIX);
-	if (pos) {
+#ifdef DEVICE_PCIX_H
+	unsigned int pcix_pos;
+	pcix_pos = pci_find_capability(dev, PCI_CAP_ID_PCIX);
+	if (pcix_pos) {
 		printk(BIOS_DEBUG, "%s subordinate bus PCI-X\n",
 		       dev_path(dev));
 		return &default_pcix_ops_bus;
 	}
 #endif
-#if CONFIG_AGP_PLUGIN_SUPPORT == 1
+#ifdef DEVICE_AGP_H
 	/* How do I detect an PCI to AGP bridge? */
+#warning AGP detection not implemented, so AGP bridge plugin not supported.
+
 #endif
-#if CONFIG_HYPERTRANSPORT_PLUGIN_SUPPORT == 1
-	pos = 0;
-	while ((pos = pci_find_next_capability(dev, PCI_CAP_ID_HT, pos))) {
+#ifdef DEVICE_HYPERTRANSPORT_H
+	unsigned int ht_pos;
+	ht_pos = 0;
+	while ((ht_pos = pci_find_next_capability(dev, PCI_CAP_ID_HT, ht_pos))) {
 		unsigned int flags;
-		flags = pci_read_config16(dev, pos + PCI_CAP_FLAGS);
+		flags = pci_read_config16(dev, ht_pos + PCI_CAP_FLAGS);
 		if ((flags >> 13) == 1) {
 			/* Host or Secondary Interface. */
 			printk(BIOS_DEBUG,
@@ -830,11 +811,12 @@
 		}
 	}
 #endif
-#if CONFIG_PCIE_PLUGIN_SUPPORT == 1
-	pos = pci_find_capability(dev, PCI_CAP_ID_PCIE);
-	if (pos) {
+#ifdef DEVICE_PCIE_H
+	unsigned int pcie_pos;
+	pcie_pos = pci_find_capability(dev, PCI_CAP_ID_PCIE);
+	if (pcie_pos) {
 		unsigned int flags;
-		flags = pci_read_config16(dev, pos + PCI_EXP_FLAGS);
+		flags = pci_read_config16(dev, pcie_pos + PCI_EXP_FLAGS);
 		switch ((flags & PCI_EXP_FLAGS_TYPE) >> 4) {
 		case PCI_EXP_TYPE_ROOT_PORT:
 		case PCI_EXP_TYPE_UPSTREAM:
@@ -864,7 +846,6 @@
 static void set_pci_ops(struct device *dev)
 {
 	struct device_operations *c;
-	struct device_id id;
 
 	if (dev->ops) {
 		printk(BIOS_SPEW, "%s: dev %s already has ops of type %x\n",
@@ -872,8 +853,6 @@
 		return;
 	}
 
-	id  = dev->id;
-
 	/* Look through the list of setup drivers and find one for
 	 * this PCI device.
 	 */
@@ -881,7 +860,7 @@
 	if (c) {
 		dev->ops = c;
 		printk(BIOS_SPEW, "%s id %s %sops\n",
-			dev_path(dev), dev_id_string(&id), 
+			dev_path(dev), dev_id_string(&dev->id), 
 			(dev->ops->phase3_scan ? "bus " : ""));
 		return;
 	}
@@ -890,21 +869,30 @@
 	switch (dev->hdr_type & 0x7f) {	/* Header type. */
 	case PCI_HEADER_TYPE_NORMAL:	/* Standard header. */
 		if ((dev->class >> 8) == PCI_CLASS_BRIDGE_PCI)
-			goto bad;
-		dev->ops = &default_pci_ops_dev;
+			printk(BIOS_ERR,
+			       "%s [%s] hdr_type %02x doesn't match"
+			       "class %06x, ignoring.\n", dev_path(dev),
+			       dev_id_string(&dev->id), dev->class >> 8,
+			       dev->hdr_type);
+		else
+			dev->ops = &default_pci_ops_dev;
 		break;
 	case PCI_HEADER_TYPE_BRIDGE:
 		if ((dev->class >> 8) != PCI_CLASS_BRIDGE_PCI)
-			goto bad;
-		dev->ops = get_pci_bridge_ops(dev);
+			printk(BIOS_ERR,
+			       "%s [%s] hdr_type %02x doesn't match"
+			       "class %06x, ignoring.\n", dev_path(dev),
+			       dev_id_string(&dev->id), dev->class >> 8,
+			       dev->hdr_type);
+		else
+			dev->ops = get_pci_bridge_ops(dev);
 		break;
-#if CONFIG_CARDBUS_PLUGIN_SUPPORT == 1
+#ifdef DEVICE_CARDBUS_H
 	case PCI_HEADER_TYPE_CARDBUS:
 		dev->ops = &default_cardbus_ops_bus;
 		break;
 #endif
 	default:
-	      bad:
 		if (dev->enabled) {
 			printk(BIOS_ERR,
 			       "%s [%s/%06x] has unknown header "
@@ -914,7 +902,7 @@
 		}
 	}
 	printk(BIOS_INFO, "%s: dev %s set ops to type %x\n", __func__,
-	       dev->dtsname, dev->ops->id.type);
+	       dev->dtsname, dev->ops? dev->ops->id.type : 0);
 	return;
 }
 

Modified: coreboot-v3/device/pcie_device.c
===================================================================
--- coreboot-v3/device/pcie_device.c	2008-11-05 22:18:53 UTC (rev 982)
+++ coreboot-v3/device/pcie_device.c	2008-11-05 22:27:36 UTC (rev 983)
@@ -62,12 +62,11 @@
 };
 
 const struct device_operations default_pcie_ops_bus = {
-	.read_resources   = pci_bus_read_resources,
-	.set_resources    = pci_dev_set_resources,
-	.enable_resources = pci_bus_enable_resources,
-	.init             = 0,
-	.scan_bus         = pcie_scan_bridge,
-	.enable           = 0,
-	.reset_bus        = pci_bus_reset,
-	.ops_pci          = &pcie_bus_ops_pci,
+	.phase3_scan             = pcie_scan_bridge,
+	.phase4_read_resources   = pci_bus_read_resources,
+	.phase4_set_resources    = pci_dev_set_resources,
+	.phase5_enable_resources = pci_bus_enable_resources,
+	.phase6_init             = 0,
+	.reset_bus               = pci_bus_reset,
+	.ops_pci                 = &pcie_bus_ops_pci,
 };

Modified: coreboot-v3/include/device/cardbus.h
===================================================================
--- coreboot-v3/include/device/cardbus.h	2008-11-05 22:18:53 UTC (rev 982)
+++ coreboot-v3/include/device/cardbus.h	2008-11-05 22:27:36 UTC (rev 983)
@@ -27,6 +27,6 @@
 unsigned int cardbus_scan_bridge(struct device *dev, unsigned int max);
 void cardbus_enable_resources(struct device *dev);
 
-extern struct device_operations default_cardbus_ops_bus;
+extern const struct device_operations default_cardbus_ops_bus;
 
 #endif /* DEVICE_CARDBUS_H */

Modified: coreboot-v3/include/device/device.h
===================================================================
--- coreboot-v3/include/device/device.h	2008-11-05 22:18:53 UTC (rev 982)
+++ coreboot-v3/include/device/device.h	2008-11-05 22:27:36 UTC (rev 983)
@@ -57,7 +57,6 @@
 struct bus;
 
 
-
 struct pci_domain_id
 {
 	u16 vendor, device;
@@ -137,7 +136,7 @@
 	 * constructors->constructor(constructors->constructor) and a new
 	 * device is created. 
 	 */
-	void (*constructor)(struct device *, struct device_operations *);
+	void (*constructor)(struct device *, const struct device_operations *);
 
 	/* set device ops */
 	void (*phase1_set_device_operations)(struct device *dev);
@@ -231,7 +230,7 @@
 	/* number of buses attached to the device */
 	unsigned int links;
 
-	struct device_operations *ops;
+	const struct device_operations *ops;
 	void *device_configuration;
 };
 
@@ -273,7 +272,7 @@
 struct device * dev_find_slot (unsigned int bus, unsigned int devfn);
 EXPORT_SYMBOL(dev_find_slot);
 struct device * dev_find_slot_on_smbus (unsigned int bus, unsigned int addr);
-void default_device_constructor(struct device *dev, struct device_operations *constructor);
+void default_device_constructor(struct device *dev, const struct device_operations *constructor);
 
 
 /* Rounding for boundaries. 

Modified: coreboot-v3/include/device/pci.h
===================================================================
--- coreboot-v3/include/device/pci.h	2008-11-05 22:18:53 UTC (rev 982)
+++ coreboot-v3/include/device/pci.h	2008-11-05 22:27:36 UTC (rev 983)
@@ -71,10 +71,10 @@
 extern struct pci_driver epci_drivers[];
 
 
-extern struct device_operations default_pci_ops_dev;
-extern struct device_operations default_pci_ops_bus;
-extern struct pci_operations pci_dev_ops_pci;
-extern struct pci_operations pci_bus_ops_pci;
+extern const struct device_operations default_pci_ops_dev;
+extern const struct device_operations default_pci_ops_bus;
+extern const struct pci_operations pci_dev_ops_pci;
+extern const struct pci_operations pci_bus_ops_pci;
 
 void pci_dev_read_resources(struct device * dev);
 void pci_bus_read_resources(struct device * dev);

Modified: coreboot-v3/include/device/pcie.h
===================================================================
--- coreboot-v3/include/device/pcie.h	2008-11-05 22:18:53 UTC (rev 982)
+++ coreboot-v3/include/device/pcie.h	2008-11-05 22:27:36 UTC (rev 983)
@@ -26,6 +26,6 @@
 	unsigned min_devfn, unsigned max_devfn, unsigned int max);
 unsigned int pcie_scan_bridge(struct device *dev, unsigned int max);
 
-extern struct device_operations default_pcie_ops_bus;
+extern const struct device_operations default_pcie_ops_bus;
 
 #endif /* DEVICE_PCIE_H */




From mylesgw at gmail.com  Wed Nov  5 23:28:06 2008
From: mylesgw at gmail.com (Myles Watson)
Date: Wed, 5 Nov 2008 16:28:06 -0600
Subject: [coreboot] More device cleanup
In-Reply-To: <13426df10811051414l7c383db5vcc7c9ae8411101d1@mail.gmail.com>
References: <2831fecf0811051027v4459cb49k9b7ca8e15a01b50b@mail.gmail.com>
	<2831fecf0811051030k68d92ecs9f1ebee909c1d370@mail.gmail.com>
	<13426df10811051121k2b10bd1ege897d24ee0f98105@mail.gmail.com>
	<58215E5D00334698ACC994E1BE778639@chimp>
	<2831fecf0811051224s732db3aag401f8e06c19913c3@mail.gmail.com>
	<13426df10811051342g315ca9d6r3729b2d78b39ece2@mail.gmail.com>
	<2831fecf0811051348t78235fc4ua84bea47b299ae@mail.gmail.com>
	<13426df10811051414l7c383db5vcc7c9ae8411101d1@mail.gmail.com>
Message-ID: <2831fecf0811051428u27c875a9j36380f2a6f9477f2@mail.gmail.com>

On Wed, Nov 5, 2008 at 4:14 PM, ron minnich <rminnich at gmail.com> wrote:

> Acked-by: Ronald G. Minnich <rminnich at gmail.com>
>

Rev 982.

Thanks,
Myles
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20081105/33994f92/attachment.html>

From mylesgw at gmail.com  Wed Nov  5 23:28:36 2008
From: mylesgw at gmail.com (Myles Watson)
Date: Wed, 5 Nov 2008 16:28:36 -0600
Subject: [coreboot] More device cleanup
In-Reply-To: <13426df10811051123l1ff5190djc30046b6541bb891@mail.gmail.com>
References: <2831fecf0811051027v4459cb49k9b7ca8e15a01b50b@mail.gmail.com>
	<2831fecf0811051030k68d92ecs9f1ebee909c1d370@mail.gmail.com>
	<13426df10811051123l1ff5190djc30046b6541bb891@mail.gmail.com>
Message-ID: <2831fecf0811051428l4842ac70ubc2a53bc9be1f445@mail.gmail.com>

On Wed, Nov 5, 2008 at 1:23 PM, ron minnich <rminnich at gmail.com> wrote:

> looks good, not build or boot tested.
>
> Acked-by: Ronald G. Minnich <rminnich at gmail.com>

Rev 983.

Thanks,
Myles
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20081105/3ce98b7d/attachment.html>

From rminnich at gmail.com  Wed Nov  5 23:30:27 2008
From: rminnich at gmail.com (ron minnich)
Date: Wed, 5 Nov 2008 14:30:27 -0800
Subject: [coreboot] More device cleanup
In-Reply-To: <2831fecf0811051428l4842ac70ubc2a53bc9be1f445@mail.gmail.com>
References: <2831fecf0811051027v4459cb49k9b7ca8e15a01b50b@mail.gmail.com>
	<2831fecf0811051030k68d92ecs9f1ebee909c1d370@mail.gmail.com>
	<13426df10811051123l1ff5190djc30046b6541bb891@mail.gmail.com>
	<2831fecf0811051428l4842ac70ubc2a53bc9be1f445@mail.gmail.com>
Message-ID: <13426df10811051430y6ef7a4b0nbfb024c78ee36196@mail.gmail.com>

Challenge: get via or k8 working by rev 1000. I used to think we'd make it :-)

ron



From c-d.hailfinger.devel.2006 at gmx.net  Wed Nov  5 23:45:28 2008
From: c-d.hailfinger.devel.2006 at gmx.net (Carl-Daniel Hailfinger)
Date: Wed, 05 Nov 2008 23:45:28 +0100
Subject: [coreboot] r981 - coreboot-v3/southbridge/amd/cs5536
In-Reply-To: <20081105215226.17699gmx1@mx034.gmx.net>
References: <20081105215226.17699gmx1@mx034.gmx.net>
Message-ID: <49122208.4000005@gmx.net>

On 05.11.2008 22:50, svn at coreboot.org wrote:
> Author: myles
> Date: 2008-11-05 22:50:25 +0100 (Wed, 05 Nov 2008)
> New Revision: 981
>
> Modified:
>    coreboot-v3/southbridge/amd/cs5536/cs5536.c
> Log:
> This patch removes a warning by making the struct pointer const.
>   

Did you want to have a const pointer to a struct or a pointer to a const
struct?

> Signed-off-by: Myles Watson <mylesgw at gmail.com>
> Acked-by: Myles Watson <mylesgw at gmail.com>
>
>
> Modified: coreboot-v3/southbridge/amd/cs5536/cs5536.c
> ===================================================================
> --- coreboot-v3/southbridge/amd/cs5536/cs5536.c	2008-11-04 21:32:59 UTC (rev 980)
> +++ coreboot-v3/southbridge/amd/cs5536/cs5536.c	2008-11-05 21:50:25 UTC (rev 981)
> @@ -563,7 +563,7 @@
>  	if (!IsS3Resume())
>  #endif
>  	{
> -		struct acpi_init *aci = acpi_init_table;
> +		const struct acpi_init *aci = acpi_init_table;
>  		for (; aci->ioreg; aci++) {
>  			outl(aci->regdata, aci->ioreg);
>  			inl(aci->ioreg);
>   

Regards,
Carl-Daniel

-- 
http://www.hailfinger.org/




From svn at coreboot.org  Wed Nov  5 23:54:37 2008
From: svn at coreboot.org (svn at coreboot.org)
Date: Wed,  5 Nov 2008 23:54:37 +0100
Subject: [coreboot] r3731 - trunk/util/flashrom
Message-ID: <mailman.2390.1355071425.16123.coreboot@coreboot.org>

Author: hailfinger
Date: 2008-11-05 23:54:36 +0100 (Wed, 05 Nov 2008)
New Revision: 3731

Modified:
   trunk/util/flashrom/flashchips.c
Log:
The ST M25P16 chip has been confirmed to work fine for probe, read,
erase and write by St?\195?\169phan Guilloux.

Signed-off-by: Carl-Daniel Hailfinger <c-d.hailfinger.devel.2006 at gmx.net>
Acked-by: Carl-Daniel Hailfinger <c-d.hailfinger.devel.2006 at gmx.net>


Modified: trunk/util/flashrom/flashchips.c
===================================================================
--- trunk/util/flashrom/flashchips.c	2008-11-04 12:11:12 UTC (rev 3730)
+++ trunk/util/flashrom/flashchips.c	2008-11-05 22:54:36 UTC (rev 3731)
@@ -115,7 +115,7 @@
 	{"ST",		"M25P40",		ST_ID,		ST_M25P40,		512,	256,		TEST_UNTESTED,	probe_spi_rdid,		spi_chip_erase_c7,	spi_chip_write, spi_chip_read},
 	{"ST",		"M25P40-old",		ST_ID,		ST_M25P40_RES,		512,	256,		TEST_UNTESTED,	probe_spi_res,		spi_chip_erase_c7,	spi_chip_write, spi_chip_read},
 	{"ST",		"M25P80",		ST_ID,		ST_M25P80,		1024,	256,		TEST_UNTESTED,	probe_spi_rdid,		spi_chip_erase_c7,	spi_chip_write, spi_chip_read},
-	{"ST",		"M25P16",		ST_ID,		ST_M25P16,		2048,	256,		TEST_UNTESTED,	probe_spi_rdid,		spi_chip_erase_c7,	spi_chip_write, spi_chip_read},
+	{"ST",		"M25P16",		ST_ID,		ST_M25P16,		2048,	256,		TEST_OK_PREW,	probe_spi_rdid,		spi_chip_erase_c7,	spi_chip_write, spi_chip_read},
 	{"ST",		"M25P32",		ST_ID,		ST_M25P32,		4096,	256,		TEST_OK_PREW,	probe_spi_rdid,		spi_chip_erase_c7,	spi_chip_write, spi_chip_read},
 	{"ST",		"M25P64",		ST_ID,		ST_M25P64,		8192,	256,		TEST_UNTESTED,	probe_spi_rdid,		spi_chip_erase_c7,	spi_chip_write, spi_chip_read},
 	{"ST",		"M25P128",		ST_ID,		ST_M25P128,		16384,	256,		TEST_UNTESTED,	probe_spi_rdid,		spi_chip_erase_c7,	spi_chip_write, spi_chip_read},




From c-d.hailfinger.devel.2006 at gmx.net  Wed Nov  5 23:56:05 2008
From: c-d.hailfinger.devel.2006 at gmx.net (Carl-Daniel Hailfinger)
Date: Wed, 05 Nov 2008 23:56:05 +0100
Subject: [coreboot] flashrom on EP80759 + Spansion S25FL016A
In-Reply-To: <49071D6E.9070400@alcatel-lucent.fr>
References: <49071D6E.9070400@alcatel-lucent.fr>
Message-ID: <49122485.1040102@gmx.net>

Hi St?phan,

On 28.10.2008 15:10, Stephan GUILLOUX wrote:
> Hello Carldani,
>
> You were right about the flash : this board is equipped with a ST
> flash and not with a Spansion...
>
> Now, I check the modifications we made yesterday night in flashrom.
> With them, flashrom is now working fine :
> I can read, I can write the flash content. Erase not tested.
>
> flashrom indicates that the ST M25P16 has a status 'untested' for
> operations PROBE READ ERASE WRITE.
> Tests and relevant traces are attached. If you need anything else,
> please, let me know.

Thanks, added that info in r3731.

Regards,
Carl-Daniel

-- 
http://www.hailfinger.org/




From info at coresystems.de  Thu Nov  6 00:11:16 2008
From: info at coresystems.de (coreboot information)
Date: Thu, 06 Nov 2008 00:11:16 +0100
Subject: [coreboot] r3731 build service
Message-ID: <E1KxrWu-0003mK-Dk@ra.coresystems.de>

Dear coreboot readers!

This is the automated build check service of coreboot.

The developer "hailfinger" checked in revision 3731 to
the coreboot source repository and caused the following 
changes:

Change Log:
The ST M25P16 chip has been confirmed to work fine for probe, read,
erase and write by St??phan Guilloux.

Signed-off-by: Carl-Daniel Hailfinger <c-d.hailfinger.devel.2006 at gmx.net>
Acked-by: Carl-Daniel Hailfinger <c-d.hailfinger.devel.2006 at gmx.net>


Build Log:
Compilation of tyan:s2885 has been broken
See the error log at http://qa.coreboot.org/log_buildbrd.php?revision=3731&device=s2885&vendor=tyan


If something broke during this checkin please be a pain 
in hailfinger's neck until the issue is fixed.

If this issue is not fixed within 24h the revision should 
be backed out.

   Best regards,
     coreboot automatic build system





From leroi.lists at gmail.com  Thu Nov  6 00:28:51 2008
From: leroi.lists at gmail.com (Roman Yeryomin)
Date: Thu, 6 Nov 2008 01:28:51 +0200
Subject: [coreboot] [patch] and/or busybox issue with alix2c3 serial
	console
In-Reply-To: <ec3a010b0811051335y58803e82r3cfe7cdba6fbd29b@mail.gmail.com>
References: <ec3a010b0811041340q202fc54fkecd64f6099622846@mail.gmail.com>
	<ec3a010b0811050120v37f2ae2eye1c5fdd276590381@mail.gmail.com>
	<13426df10811050741q34cec6fide69b4b647bccabb@mail.gmail.com>
	<200811051847.28059.leroi.lists@gmail.com> <4911E142.5030007@amd.com>
	<ec3a010b0811051335y58803e82r3cfe7cdba6fbd29b@mail.gmail.com>
Message-ID: <ec3a010b0811051528h314d3f52n9abb047f8e0d63b6@mail.gmail.com>

On Wed, Nov 5, 2008 at 11:35 PM, Roman Yeryomin <leroi.lists at gmail.com> wrote:
> On Wed, Nov 5, 2008 at 8:09 PM, Marc Jones <Marc.Jones at amd.com> wrote:
>> I see the problem. It is interesting that in some situations that it works.
>>
>> Marc
>>
>>
>> --
>> Marc Jones
>> Senior Firmware Engineer
>> (970) 226-9684 Office
>> mailto:Marc.Jones at amd.com
>> http://www.amd.com/embeddedprocessors
>>
>> LPC serial IRQs were being left enabled when there is no LPC serial device.
>>
>> Signed-off-by: Marc Jones <marc.jones at amd.com>
>>
>>
>> Index: mainboard/pcengines/alix2c3/dts
>> ===================================================================
>> --- mainboard/pcengines/alix2c3/dts     (revision 980)
>> +++ mainboard/pcengines/alix2c3/dts     (working copy)
>> @@ -34,9 +34,9 @@
>>                        /config/("southbridge/amd/cs5536/dts");
>>                        /* Interrupt enables for LPC bus.
>>                         *  Each bit is an IRQ 0-15. */
>> -                       lpc_serirq_enable = "0x0000105A";
>> +                       lpc_serirq_enable = "0x00001002";
>>                        /* LPC IRQ polarity. Each bit is an IRQ 0-15. */
>> -                       lpc_serirq_polarity = "0x0000EFA5";
>> +                       lpc_serirq_polarity = "0x0000EFFD";
>>                        /* 0:continuous 1:quiet */
>>                        lpc_serirq_mode = "1";
>>                        /* GPIO(0-0x20) for INT D:C:B:A, 0xFF=none.
>>
>>
>
> tried this with my mods but didn't work
> will try a clean build now..
>

WOW! Cool! :) It works!


Roman



From leroi.lists at gmail.com  Thu Nov  6 00:34:50 2008
From: leroi.lists at gmail.com (Roman Yeryomin)
Date: Thu, 6 Nov 2008 01:34:50 +0200
Subject: [coreboot] [patch] and/or busybox issue with alix2c3 serial
	console
In-Reply-To: <ec3a010b0811051528h314d3f52n9abb047f8e0d63b6@mail.gmail.com>
References: <ec3a010b0811041340q202fc54fkecd64f6099622846@mail.gmail.com>
	<ec3a010b0811050120v37f2ae2eye1c5fdd276590381@mail.gmail.com>
	<13426df10811050741q34cec6fide69b4b647bccabb@mail.gmail.com>
	<200811051847.28059.leroi.lists@gmail.com> <4911E142.5030007@amd.com>
	<ec3a010b0811051335y58803e82r3cfe7cdba6fbd29b@mail.gmail.com>
	<ec3a010b0811051528h314d3f52n9abb047f8e0d63b6@mail.gmail.com>
Message-ID: <ec3a010b0811051534q6489fc17j28f875701bc8fa10@mail.gmail.com>

On Thu, Nov 6, 2008 at 1:28 AM, Roman Yeryomin <leroi.lists at gmail.com> wrote:
> On Wed, Nov 5, 2008 at 11:35 PM, Roman Yeryomin <leroi.lists at gmail.com> wrote:
>> On Wed, Nov 5, 2008 at 8:09 PM, Marc Jones <Marc.Jones at amd.com> wrote:
>>> I see the problem. It is interesting that in some situations that it works.
>>>
>>> LPC serial IRQs were being left enabled when there is no LPC serial device.
>
> WOW! Cool! :) It works!
>

Many thanks to everybody who tried to help!
One more question right away... can there be any potential issues with
eth1 and eth2 sitting on one interrupt?

cat /proc/interrupts
           CPU0
  0:     541075    XT-PIC-XT        timer
  2:          0    XT-PIC-XT        cascade
  4:        403    XT-PIC-XT        serial
  8:          0    XT-PIC-XT        rtc
 10:       4828    XT-PIC-XT        eth0
 11:        319    XT-PIC-XT        eth1, eth2
 14:      20579    XT-PIC-XT        ide0
NMI:          0   Non-maskable interrupts
LOC:          0   Local timer interrupts
RES:          0   Rescheduling interrupts
CAL:          0   function call interrupts
TLB:          0   TLB shootdowns
TRM:          0   Thermal event interrupts
SPU:          0   Spurious interrupts
ERR:          0
MIS:          0


Roman



From leroi.lists at gmail.com  Thu Nov  6 01:07:46 2008
From: leroi.lists at gmail.com (Roman Yeryomin)
Date: Thu, 6 Nov 2008 02:07:46 +0200
Subject: [coreboot]  alix2c3 LEDs and mode switch
Message-ID: <ec3a010b0811051607v2047a2ffl1a422a20967da3f0@mail.gmail.com>

Is there any chance to get LEDs working on alix boards?
I suppose only GPIO lines/ports should be enabled in coreboot an
everything else is done in software.
Here is what documentation says about them:

Status LEDs are all turned on by the BIOS on power up. The BIOS will
turn off LEDs 2 and 3
before booting the operating system.
Location              GPIO           read port                write port
LED1 (left)           G6             port 06100h bit 6        port
06100h bit 6 / 22
LED2 (middle)         G25            port 06180h bit 9        port
06180h bit 9 / 25
LED3 (right)          G27            port 06180h bit 11       port
06180h bit 11 / 27
The CS5536 GPIO ports are programmed by 32 bit atomic writes. This
avoids the need for read /
modify / write operations and the locking issues they entail. For
example, to turn off LED1 (high),
write 0000'0040h to port 06100h. To turn on LED1 (low), write
0040'0000h. Multiple port bits can
be changed at the same time.


Maybe mode switch could also be useful:

The mode switch can be accessed by software as follows:
Location              GPIO           read port
MODESW#               G24            port 061b0h bit 8        (active
low, 0 = switch pressed)


Roman



From rminnich at gmail.com  Thu Nov  6 01:23:32 2008
From: rminnich at gmail.com (ron minnich)
Date: Wed, 5 Nov 2008 16:23:32 -0800
Subject: [coreboot] [patch] and/or busybox issue with alix2c3 serial
	console
In-Reply-To: <ec3a010b0811051534q6489fc17j28f875701bc8fa10@mail.gmail.com>
References: <ec3a010b0811041340q202fc54fkecd64f6099622846@mail.gmail.com>
	<ec3a010b0811050120v37f2ae2eye1c5fdd276590381@mail.gmail.com>
	<13426df10811050741q34cec6fide69b4b647bccabb@mail.gmail.com>
	<200811051847.28059.leroi.lists@gmail.com> <4911E142.5030007@amd.com>
	<ec3a010b0811051335y58803e82r3cfe7cdba6fbd29b@mail.gmail.com>
	<ec3a010b0811051528h314d3f52n9abb047f8e0d63b6@mail.gmail.com>
	<ec3a010b0811051534q6489fc17j28f875701bc8fa10@mail.gmail.com>
Message-ID: <13426df10811051623x3a0bffau70da2d4b74d1c4a2@mail.gmail.com>

On Wed, Nov 5, 2008 at 3:34 PM, Roman Yeryomin <leroi.lists at gmail.com> wrote:

> cat /proc/interrupts
>           CPU0
>  0:     541075    XT-PIC-XT        timer
>  2:          0    XT-PIC-XT        cascade
>  4:        403    XT-PIC-XT        serial
>  8:          0    XT-PIC-XT        rtc
>  10:       4828    XT-PIC-XT        eth0
>  11:        319    XT-PIC-XT        eth1, eth2


no, Linux knows how to handle those things.

ron



From rminnich at gmail.com  Thu Nov  6 01:42:03 2008
From: rminnich at gmail.com (ron minnich)
Date: Wed, 5 Nov 2008 16:42:03 -0800
Subject: [coreboot] r982 - in coreboot-v3: arch/x86 include/arch/x86
	northbridge/amd/geodelx
In-Reply-To: <49121ca7.1358560a.2dee.3c55SMTPIN_ADDED@mx.google.com>
References: <49121ca7.1358560a.2dee.3c55SMTPIN_ADDED@mx.google.com>
Message-ID: <13426df10811051642g73800522r89221f9557363bfc@mail.gmail.com>

Acked-by: Ronald G. Minnich <rminnich at gmail.com>



From c-d.hailfinger.devel.2006 at gmx.net  Thu Nov  6 11:36:08 2008
From: c-d.hailfinger.devel.2006 at gmx.net (Carl-Daniel Hailfinger)
Date: Thu, 06 Nov 2008 11:36:08 +0100
Subject: [coreboot] r983 - in coreboot-v3: device include/device
In-Reply-To: <20081105222854.3826gmx1@mx011.gmx.net>
References: <20081105222854.3826gmx1@mx011.gmx.net>
Message-ID: <4912C898.8030602@gmx.net>

Hi Myles,

I'm sorry I didn't have time to review your patch a bit sooner.
AFAICS it introduced a few bugs regarding conditional compilation.
Review follows.


On 05.11.2008 23:27, svn at coreboot.org wrote:
> Author: myles
> Date: 2008-11-05 23:27:36 +0100 (Wed, 05 Nov 2008)
> New Revision: 983
>
> Modified:
>    coreboot-v3/device/Makefile
>    coreboot-v3/device/cardbus_device.c
>    coreboot-v3/device/device.c
>    coreboot-v3/device/pci_device.c
>    coreboot-v3/device/pcie_device.c
>    coreboot-v3/include/device/cardbus.h
>    coreboot-v3/include/device/device.h
>    coreboot-v3/include/device/pci.h
>    coreboot-v3/include/device/pcie.h
> Log:
> This patch continues the device code cleanup.
>
> The largest changes are to get_pci_bridge_ops, and related changes to make it
> compile and use correct declarations.  
>
> While I was doing that I moved the checks for CONFIG_<BUS>_PLUGIN_SUPPORT to
> the Makefile.
>
> The only functional difference is a possible NULL dereference in a debug
> statement.
>
> I also added a few more consts, now that my other patch is in.
>
> Signed-off-by: Myles Watson <mylesgw at gmail.com>
> Acked-by: Ronald G. Minnich <rminnich at gmail.com>
>
>
> Modified: coreboot-v3/device/Makefile
> ===================================================================
> --- coreboot-v3/device/Makefile	2008-11-05 22:18:53 UTC (rev 982)
> +++ coreboot-v3/device/Makefile	2008-11-05 22:27:36 UTC (rev 983)
> @@ -29,13 +29,27 @@
>  			smbus_ops.c
>  
>  # this is only needed on the K8
> +# This could also check for CONFIG_HYPERTRANSPORT_PLUGIN_SUPPORT
>  ifeq ($(CONFIG_NORTHBRIDGE_AMD_K8),y)
>  STAGE2_DEVICE_SRC += hypertransport.c
>  endif
>  
>  # this is only needed for pcix devices
> +# This should also check for CONFIG_PCIX_PLUGIN_SUPPORT
>  ifeq ($(CONFIG_SOUTHBRIDGE_AMD_AMD8132),y)
>  STAGE2_DEVICE_SRC += pcix_device.c
>  endif
>  
> +ifeq ($(CONFIG_PCIE_PLUGIN_SUPPORT),y)
> +STAGE2_DEVICE_SRC += pcie_device.c
> +endif
> +
> +ifeq ($(CONFIG_CARDBUS_PLUGIN_SUPPORT),y)
> +STAGE2_DEVICE_SRC += cardbus_device.c
> +endif
> +
> +ifeq ($(CONFIG_AGP_PLUGIN_SUPPORT),y)
> +STAGE2_DEVICE_SRC += agp_device.c
> +endif
> +
>  $(obj)/device/pci_device.o: $(src)/device/pci_device.c $(obj)/statictree.h
> Modified: coreboot-v3/device/pci_device.c
> ===================================================================
> --- coreboot-v3/device/pci_device.c	2008-11-05 22:18:53 UTC (rev 982)
> +++ coreboot-v3/device/pci_device.c	2008-11-05 22:27:36 UTC (rev 983)
> @@ -30,28 +30,7 @@
>  #include <device/device.h>
>  #include <device/pci.h>
>  #include <device/pci_ids.h>
> -/* We should move these so they're really config options */
> -#define CONFIG_HYPERTRANSPORT_PLUGIN_SUPPORT 0
> -#define CONFIG_PCIX_PLUGIN_SUPPORT 0
> -#define CONFIG_PCIE_PLUGIN_SUPPORT 0
> -#define CONFIG_CARDBUS_PLUGIN_SUPPORT 0
> -#define CONFIG_AGP_PLUGIN_SUPPORT 0
>  
> -#if CONFIG_HYPERTRANSPORT_PLUGIN_SUPPORT == 1
> -#include <device/hypertransport.h>
> -#endif
> -#if CONFIG_PCIX_PLUGIN_SUPPORT == 1
> -#include <device/pcix.h>
> -#endif
> -#if CONFIG_PCIE_PLUGIN_SUPPORT == 1
> -#include <device/pcie.h>
> -#endif
> -#if CONFIG_AGP_PLUGIN_SUPPORT == 1
> -#include <device/agp.h>
> -#endif
> -#if CONFIG_CARDBUS_PLUGIN_SUPPORT == 1
> -#include <device/cardbus.h>
> -#endif
>  #include <statictree.h>
>  
>  u8 pci_moving_config8(struct device *dev, unsigned int reg)
> @@ -801,26 +780,28 @@
>   * @param dev Pointer to the device structure of the bridge.
>   * @return Appropriate bridge operations.
>   */
> -static struct device_operations *get_pci_bridge_ops(struct device *dev)
> +static const struct device_operations *get_pci_bridge_ops(struct device *dev)
>  {
> -	// unsigned int pos;
> -
> -#if CONFIG_PCIX_PLUGIN_SUPPORT == 1
> -	pos = pci_find_capability(dev, PCI_CAP_ID_PCIX);
> -	if (pos) {
> +#ifdef DEVICE_PCIX_H
>   

That won't work the way you want it to work. The ifdef above will never
be true.

> +	unsigned int pcix_pos;
> +	pcix_pos = pci_find_capability(dev, PCI_CAP_ID_PCIX);
> +	if (pcix_pos) {
>  		printk(BIOS_DEBUG, "%s subordinate bus PCI-X\n",
>  		       dev_path(dev));
>  		return &default_pcix_ops_bus;
>  	}
>  #endif
> -#if CONFIG_AGP_PLUGIN_SUPPORT == 1
> +#ifdef DEVICE_AGP_H
>   

Same here. The ifdef will never be true.

>  	/* How do I detect an PCI to AGP bridge? */
> +#warning AGP detection not implemented, so AGP bridge plugin not supported.
> +
>  #endif
> -#if CONFIG_HYPERTRANSPORT_PLUGIN_SUPPORT == 1
> -	pos = 0;
> -	while ((pos = pci_find_next_capability(dev, PCI_CAP_ID_HT, pos))) {
> +#ifdef DEVICE_HYPERTRANSPORT_H
>   

And here.

> +	unsigned int ht_pos;
> +	ht_pos = 0;
> +	while ((ht_pos = pci_find_next_capability(dev, PCI_CAP_ID_HT, ht_pos))) {
>  		unsigned int flags;
> -		flags = pci_read_config16(dev, pos + PCI_CAP_FLAGS);
> +		flags = pci_read_config16(dev, ht_pos + PCI_CAP_FLAGS);
>  		if ((flags >> 13) == 1) {
>  			/* Host or Secondary Interface. */
>  			printk(BIOS_DEBUG,
> @@ -830,11 +811,12 @@
>  		}
>  	}
>  #endif
> -#if CONFIG_PCIE_PLUGIN_SUPPORT == 1
> -	pos = pci_find_capability(dev, PCI_CAP_ID_PCIE);
> -	if (pos) {
> +#ifdef DEVICE_PCIE_H
>   

And here.

> +	unsigned int pcie_pos;
> +	pcie_pos = pci_find_capability(dev, PCI_CAP_ID_PCIE);
> +	if (pcie_pos) {
>  		unsigned int flags;
> -		flags = pci_read_config16(dev, pos + PCI_EXP_FLAGS);
> +		flags = pci_read_config16(dev, pcie_pos + PCI_EXP_FLAGS);
>  		switch ((flags & PCI_EXP_FLAGS_TYPE) >> 4) {
>  		case PCI_EXP_TYPE_ROOT_PORT:
>  		case PCI_EXP_TYPE_UPSTREAM:
> @@ -864,7 +846,6 @@
>  static void set_pci_ops(struct device *dev)
>  {
>  	struct device_operations *c;
> -	struct device_id id;
>  
>  	if (dev->ops) {
>  		printk(BIOS_SPEW, "%s: dev %s already has ops of type %x\n",
> @@ -890,21 +869,30 @@
>  	switch (dev->hdr_type & 0x7f) {	/* Header type. */
>  	case PCI_HEADER_TYPE_NORMAL:	/* Standard header. */
>  		if ((dev->class >> 8) == PCI_CLASS_BRIDGE_PCI)
> -			goto bad;
> -		dev->ops = &default_pci_ops_dev;
> +			printk(BIOS_ERR,
> +			       "%s [%s] hdr_type %02x doesn't match"
> +			       "class %06x, ignoring.\n", dev_path(dev),
> +			       dev_id_string(&dev->id), dev->class >> 8,
> +			       dev->hdr_type);
> +		else
> +			dev->ops = &default_pci_ops_dev;
>  		break;
>  	case PCI_HEADER_TYPE_BRIDGE:
>  		if ((dev->class >> 8) != PCI_CLASS_BRIDGE_PCI)
> -			goto bad;
> -		dev->ops = get_pci_bridge_ops(dev);
> +			printk(BIOS_ERR,
> +			       "%s [%s] hdr_type %02x doesn't match"
> +			       "class %06x, ignoring.\n", dev_path(dev),
> +			       dev_id_string(&dev->id), dev->class >> 8,
> +			       dev->hdr_type);
> +		else
> +			dev->ops = get_pci_bridge_ops(dev);
>  		break;
> -#if CONFIG_CARDBUS_PLUGIN_SUPPORT == 1
> +#ifdef DEVICE_CARDBUS_H
>   

And here.

>  	case PCI_HEADER_TYPE_CARDBUS:
>  		dev->ops = &default_cardbus_ops_bus;
>  		break;
>  #endif
>  	default:
> -	      bad:
>  		if (dev->enabled) {
>  			printk(BIOS_ERR,
>  			       "%s [%s/%06x] has unknown header "
>   


Regards,
Carl-Daniel

-- 
http://www.hailfinger.org/




From mart.raudsepp at artecdesign.ee  Thu Nov  6 13:13:09 2008
From: mart.raudsepp at artecdesign.ee (Mart Raudsepp)
Date: Thu, 06 Nov 2008 14:13:09 +0200
Subject: [coreboot] Supporting boards with NAND flash on other chip selects
	than CS0
Message-ID: <1225973589.4559.16.camel@martr-gentoo.artec>

Hello,

Currently southbridge/amd/cs5536/cs5536.c:chipset_flash_setup() sets up
NAND flash if enable_ide_nand_flash is set to "1" in the device tree
based on a static const structure in the same file - FlashInitTable.

The code itself supports having different NAND interfaces, specify extra
NOR for the setup and so on, based on the struct values. However in
practice this can't be used, because the struct is defined in the
southbridge code, and can't be overriden by board specific dts files
through any means - effectively telling things like "This board has NAND
on CS1" is not possible.

Due to that the ArtecGroup ThinCan DBE61 and DBE62 do not set up NAND
flash properly in coreboot-v3. They could have (and DBE62 does)
enable_ide_nand_flash enabled in dts, but that enables it on CS0, and
not on CS1.

I don't know how it's best to solve this.
I think the most generic way would be to make the whole 4 member array
struct definable or overridable in dts, but I don't think our dtc code
supports anything like that - at best we could have a variable length
array (cells) that is used for unwanted_vpci as well, telling that it
has to come in three member chunks, where first tells the type, second
the interface and third the (page size?) mask. But that is very
suboptimal too - a zero would terminate the array immediately, the type
is really an enum, not a 4 byte cell, etc.

Another option is to just assume there is only one NAND to enable, and
give the chip select location in dts - this doesn't regress what is in
practice currently supported, while being the minimum necessary to setup
up NAND for ThinCan boards properly. An initial patch for that is
attached.

Or maybe the call to chipset_flash_setup() should be pushed down to be
the responsibility of board specific C code, so it could pass in its own
FlashInitTable, after chipset_flash_setup is modified to take such a
struct instead of using the file global const struct defined in the
southbridge file?

Thoughts?


Mart Raudsepp
Artec Design LLC
-------------- next part --------------
An embedded message was scrubbed...
From: Mart Raudsepp <mart.raudsepp at artecdesign.ee>
Subject: [PATCH] cs5536: Support NAND flash on other locations than CS0
Date: Thu, 6 Nov 2008 13:36:20 +0200
Size: 6907
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20081106/99cdcd3e/attachment.mht>

From antilus701 at gmail.com  Thu Nov  6 03:23:23 2008
From: antilus701 at gmail.com (Anton Eklund)
Date: Thu, 6 Nov 2008 03:23:23 +0100
Subject: [coreboot] My spec from Ubuntu (dmi etc.)
Message-ID: <e533c8010811051823x42bc2f64i9ac5c8701720d452@mail.gmail.com>

Here I send my spec from dmidecode and such others.


Best Regards///Anton
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20081106/0b3864eb/attachment.html>
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: dmidecode.txt
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20081106/0b3864eb/attachment.txt>
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: lspci-n.txt
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20081106/0b3864eb/attachment-0001.txt>
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: lspci-t.txt
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20081106/0b3864eb/attachment-0002.txt>
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: lspci-v.txt
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20081106/0b3864eb/attachment-0003.txt>

From sasha.medvedev at gmail.com  Thu Nov  6 13:14:10 2008
From: sasha.medvedev at gmail.com (Sasha Medvedev)
Date: Thu, 6 Nov 2008 14:14:10 +0200
Subject: [coreboot] Gigabyte GA-P965-S3 motherboard data and question.
Message-ID: <20081106141410.5176d2c6@buble>

Hi, all. I found " You can help out Coreboot! " thread on ubuntu forums,
in witch somebody "uid313" tell that the following info will be useful
for you(in attachments):
dmidecode.txt
lspci-tvnn.txt
irq_tables.c
mptable.txt
dmidecode-dump.txt
lshw.txt
superiotool-dV.txt.
This is info of my GA-P965-S3 motherboard and system.
I found, coreboot is a great project. So I'd like to investigate
information in wiki and try to do something to bring coreboot on my
system. I have a little skill in programming ( C/C++ and asm courses in
the university). So I have some questions. 
1)Is this hard to port code from i945 to i965P? Could we get support
of i965P, for example, next year? I found in mail lists somebody try to
work with i965PM chip-set.
2)Is there any method to boot bios image without flashing it to board?
Or i need to bay another bios chip and experiment with it? I heard
about lobos project, but can't found source code.
3)How can I help? I suppose I was useless as programmer, may be there
is some howtos how to adopt existing part's code. Probably I can support
developers with this motherboard, if it brings really result. Or it
will be easier to change my platform(for example on amd)?
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: dmidecode.txt
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20081106/4561deeb/attachment.txt>
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: dmidecode-dump.txt
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20081106/4561deeb/attachment-0001.txt>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: irq_tables.c
Type: text/x-csrc
Size: 2752 bytes
Desc: not available
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20081106/4561deeb/attachment.c>
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: lshw.txt
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20081106/4561deeb/attachment-0002.txt>
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: lspci-tvnn.txt
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20081106/4561deeb/attachment-0003.txt>
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: mptable.txt
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20081106/4561deeb/attachment-0004.txt>
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: superiotool-dV.txt
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20081106/4561deeb/attachment-0005.txt>

From c-d.hailfinger.devel.2006 at gmx.net  Thu Nov  6 13:49:42 2008
From: c-d.hailfinger.devel.2006 at gmx.net (Carl-Daniel Hailfinger)
Date: Thu, 06 Nov 2008 13:49:42 +0100
Subject: [coreboot] Supporting boards with NAND flash on other chip
 selects than CS0
In-Reply-To: <1225973589.4559.16.camel@martr-gentoo.artec>
References: <1225973589.4559.16.camel@martr-gentoo.artec>
Message-ID: <4912E7E6.3040107@gmx.net>

On 06.11.2008 13:13, Mart Raudsepp wrote:
> Hello,
>
> Currently southbridge/amd/cs5536/cs5536.c:chipset_flash_setup() sets up
> NAND flash if enable_ide_nand_flash is set to "1" in the device tree
> based on a static const structure in the same file - FlashInitTable.
>
> The code itself supports having different NAND interfaces, specify extra
> NOR for the setup and so on, based on the struct values. However in
> practice this can't be used, because the struct is defined in the
> southbridge code, and can't be overriden by board specific dts files
> through any means - effectively telling things like "This board has NAND
> on CS1" is not possible.
>
> Due to that the ArtecGroup ThinCan DBE61 and DBE62 do not set up NAND
> flash properly in coreboot-v3. They could have (and DBE62 does)
> enable_ide_nand_flash enabled in dts, but that enables it on CS0, and
> not on CS1.
>
> I don't know how it's best to solve this.
> I think the most generic way would be to make the whole 4 member array
> struct definable or overridable in dts, but I don't think our dtc code
> supports anything like that - at best we could have a variable length
> array (cells) that is used for unwanted_vpci as well, telling that it
> has to come in three member chunks, where first tells the type, second
> the interface and third the (page size?) mask. But that is very
> suboptimal too - a zero would terminate the array immediately, the type
> is really an enum, not a 4 byte cell, etc.
>
> Another option is to just assume there is only one NAND to enable, and
> give the chip select location in dts - this doesn't regress what is in
> practice currently supported, while being the minimum necessary to setup
> up NAND for ThinCan boards properly. An initial patch for that is
> attached.
>
> Or maybe the call to chipset_flash_setup() should be pushed down to be
> the responsibility of board specific C code, so it could pass in its own
> FlashInitTable, after chipset_flash_setup is modified to take such a
> struct instead of using the file global const struct defined in the
> southbridge file?
>
> Thoughts?
>
>
> Mart Raudsepp
> Artec Design LLC
>   
>
> ------------------------------------------------------------------------
>
> Subject:
> [PATCH] cs5536: Support NAND flash on other locations than CS0
> From:
> Mart Raudsepp <mart.raudsepp at artecdesign.ee>
> Date:
> Thu, 6 Nov 2008 13:36:20 +0200
>
>
> Modify chipset_flash_setup to support enabling NAND flash on other locations
> than CS0, by making enable_ide_nand_flash have a non-boolean meaning where zero
> means no NAND (IDE), and 1 through 4 gives the one-based chip select array
> location (so 1 means CS0, 2 means CS1, 3 means CS2 and 4 means CS3, as chip
> select notation is zero-based).
>
> This loses the code for supporting more than one NAND chip select or different
> ones than FLASH_MEM_4K, but these couldn't be supported before anyway, because
> that is board specific, but the supporting structure was a static const struct
> in generic southbridge specific code.
> This support should be instead implemented via the device tree dts files.
>
> Enables NAND on ArtecGroup DBE61 and DBE62 on CS1, as that's where  it is.
> The end result is that these mainboards can now boot off of NAND with FILO
> without local modifications to the previously existing southbridge specific
> static const struct that had no chance of being upstreamed as it would break
> all other CS5536 NAND boards that have it on CS0.
>
> Signed-off-by: Mart Raudsepp <mart.raudsepp at artecdesign.ee>
>
> --- a/mainboard/artecgroup/dbe61/dts
> +++ b/mainboard/artecgroup/dbe61/dts
> @@ -22,7 +22,7 @@
>  
>  /*
>  		chip southbridge/amd/cs5536_lx
> -			register "enable_ide_nand_flash" = "0"
> +			register "enable_ide_nand_flash" = "2"
>  
>  			register "isa_irq" = "0"
>  			#register "flash_irq" = "14"
>
>   

You patched the config.lb leftovers in that dts. Please fix the real dts
definitions instead.

Acked-by: Carl-Daniel Hailfinger <c-d.hailfinger.devel.2006 at gmx.net>

Regards,
Carl-Daniel

-- 
http://www.hailfinger.org/




From c-d.hailfinger.devel.2006 at gmx.net  Thu Nov  6 14:02:26 2008
From: c-d.hailfinger.devel.2006 at gmx.net (Carl-Daniel Hailfinger)
Date: Thu, 06 Nov 2008 14:02:26 +0100
Subject: [coreboot] [PATCH] v3: Kill unnecessary rebuilds
Message-ID: <4912EAE2.8060906@gmx.net>

Every time we run make in a v3 tree, lar, lzma, nrv2b and the option
table get rebuilt unconditionally due to slightly incorrect dependencies.
That's wasteful and may hide other dependency bugs.
Fix the lar, lzma, nrv2b and option table dependencies.

This trims down recompilation time a lot. The only remaining stuff being
rebuilt is:
~/corebootv3-better_dependencies> make
  CP      build/config.h
  GEN     build/build.h
  LAR     build/coreboot.rom
  PAYLOAD none (as specified by user)
  CP      build/bios.bin
  DONE

Signed-off-by: Carl-Daniel Hailfinger <c-d.hailfinger.devel.2006 at gmx.net>

Index: corebootv3-better_dependencies/util/lzma/Makefile
===================================================================
--- corebootv3-better_dependencies/util/lzma/Makefile	(Revision 983)
+++ corebootv3-better_dependencies/util/lzma/Makefile	(Arbeitskopie)
@@ -23,13 +23,13 @@
 LZMA_OBJ += $(obj)/util/lzma/OutBuffer.o $(obj)/util/lzma/Alloc.o
 LZMA_OBJ += $(obj)/util/lzma/CRC.o
 
-$(obj)/util/lzma/lzma: lzmadir $(LZMA_OBJ) $(obj)/util/lzma/minilzma.o
+$(obj)/util/lzma/lzma: $(obj)/util/lzma/ $(LZMA_OBJ) $(obj)/util/lzma/minilzma.o
 	$(Q)$(HOSTCXX) $(HOSTCXXFLAGS) -o $@ $(LZMA_OBJ) $(obj)/util/lzma/minilzma.o
 
 $(obj)/util/lzma/lzma-compress.o: $(src)/util/lzma/minilzma.cc
 	$(Q)$(HOSTCXX) $(HOSTCXXFLAGS) -o $@ -c -DCOMPACT $<
 
-lzmadir:
+$(obj)/util/lzma/:
 	$(Q)printf "  BUILD   LZMA\n"
 	$(Q)mkdir -p $(obj)/util/lzma/
 
Index: corebootv3-better_dependencies/util/nrv2b/Makefile
===================================================================
--- corebootv3-better_dependencies/util/nrv2b/Makefile	(Revision 983)
+++ corebootv3-better_dependencies/util/nrv2b/Makefile	(Arbeitskopie)
@@ -19,15 +19,15 @@
 ## Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA  02110-1301 USA
 ##
 
-$(obj)/util/nrv2b/nrv2b: nrv2bdir $(src)/util/nrv2b/nrv2b.c
+$(obj)/util/nrv2b/nrv2b: $(obj)/util/nrv2b/ $(src)/util/nrv2b/nrv2b.c
 	$(Q)printf "  HOSTCC  $(subst $(shell pwd)/,,$(@))\n"
 	$(Q)$(HOSTCC) $(HOSTCFLAGS) -DENCODE -DDECODE -DMAIN -DVERBOSE -DNDEBUG -DBITSIZE=32 -DENDIAN=0 -o $@ $(src)/util/nrv2b/nrv2b.c
 
-$(obj)/util/nrv2b/nrv2b-compress.o: nrv2bdir $(src)/util/nrv2b/nrv2b.c
+$(obj)/util/nrv2b/nrv2b-compress.o: $(obj)/util/nrv2b/ $(src)/util/nrv2b/nrv2b.c
 	$(Q)printf "  HOSTCC  $(subst $(shell pwd)/,,$(@))\n"
 	$(Q)$(HOSTCC) $(HOSTCFLAGS) -DENCODE -DDECODE -DVERBOSE -DCOMPACT -DNDEBUG -DBITSIZE=32 -DENDIAN=0 -c -o $@ $(src)/util/nrv2b/nrv2b.c
 
-nrv2bdir:
+$(obj)/util/nrv2b/:
 	$(Q)printf "  BUILD   NRV2B\n"
 	$(Q)mkdir -p $(obj)/util/nrv2b/
 
Index: corebootv3-better_dependencies/util/options/Makefile
===================================================================
--- corebootv3-better_dependencies/util/options/Makefile	(Revision 983)
+++ corebootv3-better_dependencies/util/options/Makefile	(Arbeitskopie)
@@ -21,11 +21,11 @@
 
 OPTIONS_OBJ := $(obj)/util/options/build_opt_tbl.o
 
-$(obj)/util/options/build_opt_tbl: optionsdir $(OPTIONS_OBJ)
+$(obj)/util/options/build_opt_tbl: $(obj)/util/options/ $(OPTIONS_OBJ)
 	$(Q)printf "  HOSTCC  $(subst $(shell pwd)/,,$(@))\n"
 	$(Q)$(HOSTCC) $(HOSTCFLAGS) -o $@ $(OPTIONS_OBJ)
 
-optionsdir:
+$(obj)/util/options/:
 	$(Q)mkdir -p $(obj)/util/options/
 
 $(obj)/util/options/%.o: $(src)/util/options/%.c
Index: corebootv3-better_dependencies/util/lar/Makefile
===================================================================
--- corebootv3-better_dependencies/util/lar/Makefile	(Revision 983)
+++ corebootv3-better_dependencies/util/lar/Makefile	(Arbeitskopie)
@@ -19,16 +19,17 @@
 ##
 LAROBJ := lar.o stream.o lib.o
 
-LARDIR := lardir
+LARDIR := $(obj)/util/lar
 
 COMPRESSOR := $(LZMA_OBJ) $(obj)/util/lzma/lzma-compress.o
-LARDIR     += lzmadir
+LARDIR     += $(obj)/util/lzma/
 
 COMPRESSOR += $(obj)/util/nrv2b/nrv2b-compress.o
-LARDIR     += nrv2bdir
+LARDIR     += $(obj)/util/nrv2b/
 
 LAROBJ_ABS := $(patsubst %,$(obj)/util/lar/%,$(LAROBJ))
-lardir:
+
+$(obj)/util/lar:
 	$(Q)printf "  BUILD   LAR\n"
 	$(Q)mkdir -p $(obj)/util/lar
 


-- 
http://www.hailfinger.org/




From mylesgw at gmail.com  Thu Nov  6 14:26:42 2008
From: mylesgw at gmail.com (Myles Watson)
Date: Thu, 6 Nov 2008 06:26:42 -0700
Subject: [coreboot] r983 - in coreboot-v3: device include/device
In-Reply-To: <4912C898.8030602@gmx.net>
References: <20081105222854.3826gmx1@mx011.gmx.net> <4912C898.8030602@gmx.net>
Message-ID: <97E3D99CC80D4C818B3DC1301229D37F@chimp>



> -----Original Message-----
> From: Carl-Daniel Hailfinger [mailto:c-d.hailfinger.devel.2006 at gmx.net]
> Sent: Thursday, November 06, 2008 3:36 AM
> To: coreboot at coreboot.org; Myles Watson; ron minnich
> Subject: Re: [coreboot] r983 - in coreboot-v3: device include/device
> 
> Hi Myles,
> 
> I'm sorry I didn't have time to review your patch a bit sooner.
> AFAICS it introduced a few bugs regarding conditional compilation.
> Review follows.
> 

Whoa.  You're right.  I guess it's the same as it was, since it was never
compiled in before either.

It brings up the interesting question of how this should work, since if you
try to compile in that support it breaks because it can't find the default
ops structures.

Should there be a table of default ops somewhere?  How do we compile in
support for plug ins?

Thanks,
Myles




From mylesgw at gmail.com  Thu Nov  6 14:45:38 2008
From: mylesgw at gmail.com (Myles Watson)
Date: Thu, 6 Nov 2008 07:45:38 -0600
Subject: [coreboot] [PATCH] v3: Kill unnecessary rebuilds
In-Reply-To: <4912EAE2.8060906@gmx.net>
References: <4912EAE2.8060906@gmx.net>
Message-ID: <2831fecf0811060545q17660567q76ca020b39768426@mail.gmail.com>

On Thu, Nov 6, 2008 at 7:02 AM, Carl-Daniel Hailfinger <
c-d.hailfinger.devel.2006 at gmx.net> wrote:

> Every time we run make in a v3 tree, lar, lzma, nrv2b and the option
> table get rebuilt unconditionally due to slightly incorrect dependencies.
> That's wasteful and may hide other dependency bugs.
> Fix the lar, lzma, nrv2b and option table dependencies.
>
> This trims down recompilation time a lot. The only remaining stuff being
> rebuilt is:
> ~/corebootv3-better_dependencies> make
>  CP      build/config.h
>  GEN     build/build.h
>  LAR     build/coreboot.rom
>  PAYLOAD none (as specified by user)
>  CP      build/bios.bin
>  DONE
>
> Signed-off-by: Carl-Daniel Hailfinger <c-d.hailfinger.devel.2006 at gmx.net>


Acked-by: Myles Watson <mylesgw at gmail.com>

Very nice.

Thanks,
Myles
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20081106/7fc9839d/attachment.html>

From stepan at coresystems.de  Thu Nov  6 14:46:22 2008
From: stepan at coresystems.de (Stefan Reinauer)
Date: Thu, 06 Nov 2008 14:46:22 +0100
Subject: [coreboot] [PATCH] v3: Kill unnecessary rebuilds
In-Reply-To: <4912EAE2.8060906@gmx.net>
References: <4912EAE2.8060906@gmx.net>
Message-ID: <4912F52E.5090107@coresystems.de>

Carl-Daniel Hailfinger wrote:
> Every time we run make in a v3 tree, lar, lzma, nrv2b and the option
> table get rebuilt unconditionally due to slightly incorrect dependencies.
> That's wasteful and may hide other dependency bugs.
> Fix the lar, lzma, nrv2b and option table dependencies.
>
> This trims down recompilation time a lot. The only remaining stuff being
> rebuilt is:
> ~/corebootv3-better_dependencies> make
>   CP      build/config.h
>   GEN     build/build.h
>   LAR     build/coreboot.rom
>   PAYLOAD none (as specified by user)
>   CP      build/bios.bin
>   DONE
>
> Signed-off-by: Carl-Daniel Hailfinger <c-d.hailfinger.devel.2006 at gmx.net>
>
>   
Acked-by: Stefan Reinauer <stepan at coresystems.de>
> -nrv2bdir:
> +$(obj)/util/nrv2b/:
> -optionsdir:
> +$(obj)/util/options/:
>  
> -LARDIR := lardir
> +LARDIR := $(obj)/util/lar
Is it on purpose that all the other directories have a / at the end but
$(obj)/util/lar has none?


-- 
coresystems GmbH ? Brahmsstr. 16 ? D-79104 Freiburg i. Br.
      Tel.: +49 761 7668825 ? Fax: +49 761 7664613
Email: info at coresystems.de  ? http://www.coresystems.de/
Registergericht: Amtsgericht Freiburg ? HRB 7656
Gesch?ftsf?hrer: Stefan Reinauer ? Ust-IdNr.: DE245674866


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 249 bytes
Desc: OpenPGP digital signature
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20081106/5853daa6/attachment.sig>

From vincent.legoll at gmail.com  Thu Nov  6 14:57:25 2008
From: vincent.legoll at gmail.com (Vincent Legoll)
Date: Thu, 6 Nov 2008 14:57:25 +0100
Subject: [coreboot] [PATCH] v3: Kill unnecessary rebuilds
In-Reply-To: <4912F52E.5090107@coresystems.de>
References: <4912EAE2.8060906@gmx.net> <4912F52E.5090107@coresystems.de>
Message-ID: <4727185d0811060557y324b931nc5ef8296953110d7@mail.gmail.com>

On Thu, Nov 6, 2008 at 2:46 PM, Stefan Reinauer <stepan at coresystems.de> wrote:
>> +LARDIR := $(obj)/util/lar
> Is it on purpose that all the other directories have a / at the end but
> $(obj)/util/lar has none?

If yes, please educate us about that purpose, I'm puzzled.

-- 
Vincent Legoll



From svn at coreboot.org  Thu Nov  6 14:59:15 2008
From: svn at coreboot.org (svn at coreboot.org)
Date: Thu,  6 Nov 2008 14:59:15 +0100
Subject: [coreboot] r984 - in coreboot-v3/util: lar lzma nrv2b options
Message-ID: <mailman.2391.1355071426.16123.coreboot@coreboot.org>

Author: hailfinger
Date: 2008-11-06 14:59:14 +0100 (Thu, 06 Nov 2008)
New Revision: 984

Modified:
   coreboot-v3/util/lar/Makefile
   coreboot-v3/util/lzma/Makefile
   coreboot-v3/util/nrv2b/Makefile
   coreboot-v3/util/options/Makefile
Log:
Every time we run make in a v3 tree, lar, lzma, nrv2b and the option
table get rebuilt unconditionally due to slightly incorrect
dependencies.
That's wasteful and may hide other dependency bugs.
Fix the lar, lzma, nrv2b and option table dependencies.

This trims down recompilation time a lot. The only remaining stuff being
rebuilt is:
~/corebootv3-better_dependencies> make
  CP      build/config.h
  GEN     build/build.h
  LAR     build/coreboot.rom
  PAYLOAD none (as specified by user)
  CP      build/bios.bin
  DONE

Signed-off-by: Carl-Daniel Hailfinger <c-d.hailfinger.devel.2006 at gmx.net>
Acked-by: Myles Watson <mylesgw at gmail.com>
Acked-by: Stefan Reinauer <stepan at coresystems.de>


Modified: coreboot-v3/util/lar/Makefile
===================================================================
--- coreboot-v3/util/lar/Makefile	2008-11-05 22:27:36 UTC (rev 983)
+++ coreboot-v3/util/lar/Makefile	2008-11-06 13:59:14 UTC (rev 984)
@@ -19,16 +19,17 @@
 ##
 LAROBJ := lar.o stream.o lib.o
 
-LARDIR := lardir
+LARDIR := $(obj)/util/lar/
 
 COMPRESSOR := $(LZMA_OBJ) $(obj)/util/lzma/lzma-compress.o
-LARDIR     += lzmadir
+LARDIR     += $(obj)/util/lzma/
 
 COMPRESSOR += $(obj)/util/nrv2b/nrv2b-compress.o
-LARDIR     += nrv2bdir
+LARDIR     += $(obj)/util/nrv2b/
 
 LAROBJ_ABS := $(patsubst %,$(obj)/util/lar/%,$(LAROBJ))
-lardir:
+
+$(obj)/util/lar/:
 	$(Q)printf "  BUILD   LAR\n"
 	$(Q)mkdir -p $(obj)/util/lar
 

Modified: coreboot-v3/util/lzma/Makefile
===================================================================
--- coreboot-v3/util/lzma/Makefile	2008-11-05 22:27:36 UTC (rev 983)
+++ coreboot-v3/util/lzma/Makefile	2008-11-06 13:59:14 UTC (rev 984)
@@ -23,13 +23,13 @@
 LZMA_OBJ += $(obj)/util/lzma/OutBuffer.o $(obj)/util/lzma/Alloc.o
 LZMA_OBJ += $(obj)/util/lzma/CRC.o
 
-$(obj)/util/lzma/lzma: lzmadir $(LZMA_OBJ) $(obj)/util/lzma/minilzma.o
+$(obj)/util/lzma/lzma: $(obj)/util/lzma/ $(LZMA_OBJ) $(obj)/util/lzma/minilzma.o
 	$(Q)$(HOSTCXX) $(HOSTCXXFLAGS) -o $@ $(LZMA_OBJ) $(obj)/util/lzma/minilzma.o
 
 $(obj)/util/lzma/lzma-compress.o: $(src)/util/lzma/minilzma.cc
 	$(Q)$(HOSTCXX) $(HOSTCXXFLAGS) -o $@ -c -DCOMPACT $<
 
-lzmadir:
+$(obj)/util/lzma/:
 	$(Q)printf "  BUILD   LZMA\n"
 	$(Q)mkdir -p $(obj)/util/lzma/
 

Modified: coreboot-v3/util/nrv2b/Makefile
===================================================================
--- coreboot-v3/util/nrv2b/Makefile	2008-11-05 22:27:36 UTC (rev 983)
+++ coreboot-v3/util/nrv2b/Makefile	2008-11-06 13:59:14 UTC (rev 984)
@@ -19,15 +19,15 @@
 ## Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA  02110-1301 USA
 ##
 
-$(obj)/util/nrv2b/nrv2b: nrv2bdir $(src)/util/nrv2b/nrv2b.c
+$(obj)/util/nrv2b/nrv2b: $(obj)/util/nrv2b/ $(src)/util/nrv2b/nrv2b.c
 	$(Q)printf "  HOSTCC  $(subst $(shell pwd)/,,$(@))\n"
 	$(Q)$(HOSTCC) $(HOSTCFLAGS) -DENCODE -DDECODE -DMAIN -DVERBOSE -DNDEBUG -DBITSIZE=32 -DENDIAN=0 -o $@ $(src)/util/nrv2b/nrv2b.c
 
-$(obj)/util/nrv2b/nrv2b-compress.o: nrv2bdir $(src)/util/nrv2b/nrv2b.c
+$(obj)/util/nrv2b/nrv2b-compress.o: $(obj)/util/nrv2b/ $(src)/util/nrv2b/nrv2b.c
 	$(Q)printf "  HOSTCC  $(subst $(shell pwd)/,,$(@))\n"
 	$(Q)$(HOSTCC) $(HOSTCFLAGS) -DENCODE -DDECODE -DVERBOSE -DCOMPACT -DNDEBUG -DBITSIZE=32 -DENDIAN=0 -c -o $@ $(src)/util/nrv2b/nrv2b.c
 
-nrv2bdir:
+$(obj)/util/nrv2b/:
 	$(Q)printf "  BUILD   NRV2B\n"
 	$(Q)mkdir -p $(obj)/util/nrv2b/
 

Modified: coreboot-v3/util/options/Makefile
===================================================================
--- coreboot-v3/util/options/Makefile	2008-11-05 22:27:36 UTC (rev 983)
+++ coreboot-v3/util/options/Makefile	2008-11-06 13:59:14 UTC (rev 984)
@@ -21,11 +21,11 @@
 
 OPTIONS_OBJ := $(obj)/util/options/build_opt_tbl.o
 
-$(obj)/util/options/build_opt_tbl: optionsdir $(OPTIONS_OBJ)
+$(obj)/util/options/build_opt_tbl: $(obj)/util/options/ $(OPTIONS_OBJ)
 	$(Q)printf "  HOSTCC  $(subst $(shell pwd)/,,$(@))\n"
 	$(Q)$(HOSTCC) $(HOSTCFLAGS) -o $@ $(OPTIONS_OBJ)
 
-optionsdir:
+$(obj)/util/options/:
 	$(Q)mkdir -p $(obj)/util/options/
 
 $(obj)/util/options/%.o: $(src)/util/options/%.c




From c-d.hailfinger.devel.2006 at gmx.net  Thu Nov  6 14:59:47 2008
From: c-d.hailfinger.devel.2006 at gmx.net (Carl-Daniel Hailfinger)
Date: Thu, 06 Nov 2008 14:59:47 +0100
Subject: [coreboot] [PATCH] v3: Kill unnecessary rebuilds
In-Reply-To: <4912F52E.5090107@coresystems.de>
References: <4912EAE2.8060906@gmx.net> <4912F52E.5090107@coresystems.de>
Message-ID: <4912F853.3070205@gmx.net>

On 06.11.2008 14:46, Stefan Reinauer wrote:
> Carl-Daniel Hailfinger wrote:
>   
>> Every time we run make in a v3 tree, lar, lzma, nrv2b and the option
>> table get rebuilt unconditionally due to slightly incorrect dependencies.
>> That's wasteful and may hide other dependency bugs.
>> Fix the lar, lzma, nrv2b and option table dependencies.
>>
>> This trims down recompilation time a lot. The only remaining stuff being
>> rebuilt is:
>> ~/corebootv3-better_dependencies> make
>>   CP      build/config.h
>>   GEN     build/build.h
>>   LAR     build/coreboot.rom
>>   PAYLOAD none (as specified by user)
>>   CP      build/bios.bin
>>   DONE
>>
>> Signed-off-by: Carl-Daniel Hailfinger <c-d.hailfinger.devel.2006 at gmx.net>
>>
>>   
>>     
> Acked-by: Stefan Reinauer <stepan at coresystems.de>
>   

Thanks, committed in r984.

>> -nrv2bdir:
>> +$(obj)/util/nrv2b/:
>> -optionsdir:
>> +$(obj)/util/options/:
>>  
>> -LARDIR := lardir
>> +LARDIR := $(obj)/util/lar
>>     
> Is it on purpose that all the other directories have a / at the end but
> $(obj)/util/lar has none?
>   

No, it was a simple typo. Thanks for spotting it.

Regards,
Carl-Daniel

-- 
http://www.hailfinger.org/




From c-d.hailfinger.devel.2006 at gmx.net  Thu Nov  6 15:21:16 2008
From: c-d.hailfinger.devel.2006 at gmx.net (Carl-Daniel Hailfinger)
Date: Thu, 06 Nov 2008 15:21:16 +0100
Subject: [coreboot] [PATCH] v3: Kill unnecessary rebuilds
In-Reply-To: <4912F853.3070205@gmx.net>
References: <4912EAE2.8060906@gmx.net> <4912F52E.5090107@coresystems.de>
	<4912F853.3070205@gmx.net>
Message-ID: <4912FD5C.3010107@gmx.net>

On 06.11.2008 14:59, Carl-Daniel Hailfinger wrote:
> On 06.11.2008 14:46, Stefan Reinauer wrote:
>   
>> Carl-Daniel Hailfinger wrote:
>>   
>>     
>>> Every time we run make in a v3 tree, lar, lzma, nrv2b and the option
>>> table get rebuilt unconditionally due to slightly incorrect dependencies.
>>> That's wasteful and may hide other dependency bugs.
>>> Fix the lar, lzma, nrv2b and option table dependencies.
>>>
>>> This trims down recompilation time a lot. The only remaining stuff being
>>> rebuilt is:
>>> ~/corebootv3-better_dependencies> make
>>>   CP      build/config.h
>>>   GEN     build/build.h
>>>   LAR     build/coreboot.rom
>>>   PAYLOAD none (as specified by user)
>>>   CP      build/bios.bin
>>>   DONE
>>>
>>> Signed-off-by: Carl-Daniel Hailfinger <c-d.hailfinger.devel.2006 at gmx.net>
>>>
>>>   
>>>     
>>>       
>> Acked-by: Stefan Reinauer <stepan at coresystems.de>
>>   
>>     
>
> Thanks, committed in r984.
>   

I wanted to clean this up further, but I'm hitting a big dependency bug.
Try this patch and watch make explode:

Index: util/lar/Makefile
===================================================================
--- util/lar/Makefile	(Revision 984)
+++ util/lar/Makefile	(Arbeitskopie)
@@ -22,10 +22,8 @@
 LARDIR := $(obj)/util/lar/
 
 COMPRESSOR := $(LZMA_OBJ) $(obj)/util/lzma/lzma-compress.o
-LARDIR     += $(obj)/util/lzma/
 
 COMPRESSOR += $(obj)/util/nrv2b/nrv2b-compress.o
-LARDIR     += $(obj)/util/nrv2b/
 
 LAROBJ_ABS := $(patsubst %,$(obj)/util/lar/%,$(LAROBJ))
 


  HOSTCC  build/util/lar/lib.o
  HOSTCXX build/util/lzma/LZMAEncoder.o
Assembler messages:
Fatal error: can't create
/sources/tmptrees/corebootv3-better_dependencies/build/util/lzma/LZMAEncoder.o:
No such file or directory
make: ***
[/sources/tmptrees/corebootv3-better_dependencies/build/util/lzma/LZMAEncoder.o]
Fehler 1

The obvious bug is that build/util/lzma/LZMAEncoder.o does not depend on
build/util/lzma/ and that means compilation has no target directory.
As long as make is not run in parallel mode, you will not see the bug in
svn HEAD because make first creates build/util/lzma/ and then compiles
files there. Once you run in parallel mode, it is entirely possible that
the directory creation happens after the compile attempt and stuff will
explode even with current svn HEAD.

Fixing this would require us to add build/util/lzma/ as a dependency to
every lzma object in util/lzma/Makefile. And that's the point where I
ask about better solutions.


Regards,
Carl-Daniel

-- 
http://www.hailfinger.org/




From c-d.hailfinger.devel.2006 at gmx.net  Thu Nov  6 15:29:13 2008
From: c-d.hailfinger.devel.2006 at gmx.net (Carl-Daniel Hailfinger)
Date: Thu, 06 Nov 2008 15:29:13 +0100
Subject: [coreboot] [PATCH] Fix v3 build dependencies on build.h
Message-ID: <4912FF39.6000004@gmx.net>

Not a single file is being rebuilt in v3 if build.h changes. That means
the console banner and the option table will never be updated with more
recent build.h strings.

The fix is not yet ready for committing because the x86emu changes could
be avoided if someone fixed two or three lines in x86emu. Hint: x86emu
doesn't care about the contents of build.h, it just uses build.h to
check whether it is compiled in conjunction with coreboot.

Signed-off-by: Carl-Daniel Hailfinger <c-d.hailfinger.devel.2006 at gmx.net>

Index: corebootv3-build_h_dependencies/lib/console.c
===================================================================
--- corebootv3-build_h_dependencies/lib/console.c	(Revision 984)
+++ corebootv3-build_h_dependencies/lib/console.c	(Arbeitskopie)
@@ -6,6 +6,7 @@
 #include <stdarg.h>
 #include <string.h>
 #include <globalvars.h>
+#include <build.h>
 
 int vtxprintf(void (*)(unsigned char, void *arg), 
 		void *arg, const char *, va_list);
Index: corebootv3-build_h_dependencies/lib/Makefile
===================================================================
--- corebootv3-build_h_dependencies/lib/Makefile	(Revision 984)
+++ corebootv3-build_h_dependencies/lib/Makefile	(Arbeitskopie)
@@ -44,6 +44,11 @@
 nrv2b:
 endif
 
+$(obj)/lib/console.o: $(src)/lib/console.c $(obj)/build.h
+	$(Q)mkdir -p $(dir $@)
+	$(Q)printf "  CC      $(subst $(shell pwd)/,,$(@))\n"
+	$(Q)$(CC) $(INITCFLAGS) -c $< -o $@
+
 $(obj)/lib/%.o: $(src)/lib/%.c
 	$(Q)mkdir -p $(dir $@)
 	$(Q)printf "  CC      $(subst $(shell pwd)/,,$(@))\n"
Index: corebootv3-build_h_dependencies/Makefile
===================================================================
--- corebootv3-build_h_dependencies/Makefile	(Revision 984)
+++ corebootv3-build_h_dependencies/Makefile	(Arbeitskopie)
@@ -88,8 +88,7 @@
 			-I$(src)/include \
 			-I$(src)/include/arch/$(ARCH)/ \
 			-I$(src)/mainboard/$(MAINBOARDDIR)/ \
-			-include $(obj)/config.h \
-			-include $(obj)/build.h
+			-include $(obj)/config.h
 
 CC := $(CC_$(ARCH))
 AS := $(AS_$(ARCH))
Index: corebootv3-build_h_dependencies/util/x86emu/include/x86emu/x86emu.h
===================================================================
--- corebootv3-build_h_dependencies/util/x86emu/include/x86emu/x86emu.h	(Revision 984)
+++ corebootv3-build_h_dependencies/util/x86emu/include/x86emu/x86emu.h	(Arbeitskopie)
@@ -43,6 +43,7 @@
 #define __X86EMU_X86EMU_H
 
 /* FIXME: undefine printk for the moment */
+#include <build.h>
 #ifdef COREBOOT_VERSION
 #include <console.h>
 #define printk(x...) printk(BIOS_DEBUG, x)
Index: corebootv3-build_h_dependencies/util/x86emu/Makefile
===================================================================
--- corebootv3-build_h_dependencies/util/x86emu/Makefile	(Revision 984)
+++ corebootv3-build_h_dependencies/util/x86emu/Makefile	(Arbeitskopie)
@@ -44,7 +44,7 @@
 # This rule is also valid for all subdirectories
 #
 
-$(obj)/util/x86emu/%.o: $(src)/util/x86emu/%.c
+$(obj)/util/x86emu/%.o: $(src)/util/x86emu/%.c $(obj)/build.h
 	$(Q)mkdir -p $(dir $@)
 	$(Q)printf "  CC      $(subst $(shell pwd)/,,$(@))\n"
 	$(Q)$(CC) $(INITCFLAGS) -I$(src)/util/x86emu/include -c $< -o $@
Index: corebootv3-build_h_dependencies/arch/x86/coreboot_table.c
===================================================================
--- corebootv3-build_h_dependencies/arch/x86/coreboot_table.c	(Revision 984)
+++ corebootv3-build_h_dependencies/arch/x86/coreboot_table.c	(Arbeitskopie)
@@ -31,6 +31,7 @@
 //#include <pirq_routing.h>
 //#include <smp/mpspec.h>
 //#include <acpi.h>
+#include <build.h>
 
 struct lb_header *lb_table_init(unsigned long addr)
 {
Index: corebootv3-build_h_dependencies/arch/x86/Makefile
===================================================================
--- corebootv3-build_h_dependencies/arch/x86/Makefile	(Revision 984)
+++ corebootv3-build_h_dependencies/arch/x86/Makefile	(Arbeitskopie)
@@ -243,6 +243,11 @@
 # Build rules.
 #
 
+$(obj)/arch/x86/coreboot_table.o: $(src)/arch/x86/coreboot_table.c $(obj)/build.h
+	$(Q)mkdir -p $(dir $@)
+	$(Q)printf "  CC      $(subst $(shell pwd)/,,$(@))\n"
+	$(Q)$(CC) $(INITCFLAGS) -c $< -o $@
+	
 $(obj)/arch/x86/%.o: $(src)/arch/x86/%.c
 	$(Q)mkdir -p $(dir $@)
 	$(Q)printf "  CC      $(subst $(shell pwd)/,,$(@))\n"


-- 
http://www.hailfinger.org/




From stepan at coresystems.de  Thu Nov  6 15:29:50 2008
From: stepan at coresystems.de (Stefan Reinauer)
Date: Thu, 06 Nov 2008 15:29:50 +0100
Subject: [coreboot] [PATCH] v3: Kill unnecessary rebuilds
In-Reply-To: <4912FD5C.3010107@gmx.net>
References: <4912EAE2.8060906@gmx.net> <4912F52E.5090107@coresystems.de>
	<4912F853.3070205@gmx.net> <4912FD5C.3010107@gmx.net>
Message-ID: <4912FF5E.60302@coresystems.de>

Carl-Daniel Hailfinger wrote:
> On 06.11.2008 14:59, Carl-Daniel Hailfinger wrote:
>   
>> On 06.11.2008 14:46, Stefan Reinauer wrote:
>>   
>>     
>>> Carl-Daniel Hailfinger wrote:
>>>   
>>>     
>>>       
>>>> Every time we run make in a v3 tree, lar, lzma, nrv2b and the option
>>>> table get rebuilt unconditionally due to slightly incorrect dependencies.
>>>> That's wasteful and may hide other dependency bugs.
>>>> Fix the lar, lzma, nrv2b and option table dependencies.
>>>>
>>>> This trims down recompilation time a lot. The only remaining stuff being
>>>> rebuilt is:
>>>> ~/corebootv3-better_dependencies> make
>>>>   CP      build/config.h
>>>>   GEN     build/build.h
>>>>   LAR     build/coreboot.rom
>>>>   PAYLOAD none (as specified by user)
>>>>   CP      build/bios.bin
>>>>   DONE
>>>>
>>>> Signed-off-by: Carl-Daniel Hailfinger <c-d.hailfinger.devel.2006 at gmx.net>
>>>>
>>>>   
>>>>     
>>>>       
>>>>         
>>> Acked-by: Stefan Reinauer <stepan at coresystems.de>
>>>   
>>>     
>>>       
>> Thanks, committed in r984.
>>   
>>     
>
> I wanted to clean this up further, but I'm hitting a big dependency bug.
> Try this patch and watch make explode:
>
> Index: util/lar/Makefile
> ===================================================================
> --- util/lar/Makefile	(Revision 984)
> +++ util/lar/Makefile	(Arbeitskopie)
> @@ -22,10 +22,8 @@
>  LARDIR := $(obj)/util/lar/
>  
>  COMPRESSOR := $(LZMA_OBJ) $(obj)/util/lzma/lzma-compress.o
> -LARDIR     += $(obj)/util/lzma/
>  
>  COMPRESSOR += $(obj)/util/nrv2b/nrv2b-compress.o
> -LARDIR     += $(obj)/util/nrv2b/
>  
>  LAROBJ_ABS := $(patsubst %,$(obj)/util/lar/%,$(LAROBJ))
>  
>   
> Fixing this would require us to add build/util/lzma/ as a dependency to
> every lzma object in util/lzma/Makefile. And that's the point where I
> ask about better solutions.

I think leaving it as it is sounds like a better solution already ;-)

-- 
coresystems GmbH ? Brahmsstr. 16 ? D-79104 Freiburg i. Br.
      Tel.: +49 761 7668825 ? Fax: +49 761 7664613
Email: info at coresystems.de  ? http://www.coresystems.de/
Registergericht: Amtsgericht Freiburg ? HRB 7656
Gesch?ftsf?hrer: Stefan Reinauer ? Ust-IdNr.: DE245674866


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 249 bytes
Desc: OpenPGP digital signature
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20081106/4799f6db/attachment.sig>

From stepan at coresystems.de  Thu Nov  6 16:00:21 2008
From: stepan at coresystems.de (Stefan Reinauer)
Date: Thu, 06 Nov 2008 16:00:21 +0100
Subject: [coreboot] SeaBIOS question and cross compilation fix.
Message-ID: <49130685.7030804@coresystems.de>

Hi, Kevin,

I am experimenting with v3 and better integration of SeaBIOS and
coreboot. For that, I am copying a SeaBIOS image to the FSEG during
coreboot's VGA init code. In addition I added another 32bit entry point
to SeaBIOS at 0xffc0 (Thus, living at 0xfffc0)

int copy_systembios(void)
{
        struct mem_file archive, result;
        int ret;
        init_archive(&archive);
        ret = find_file(&archive, "bios.bin", &result);
        if (ret) {
                printk(BIOS_WARNING, "No legacy bios found.\n");
                return -1;
        }
        process_file(&result, (void *)0xf0000);
        return 0;
}

void run_bios(struct device *dev, unsigned long addr)
{
        int i;
        void (*init_systembios)(void) = (void *)0xfffc0;
        copy_systembios();
        init_systembios();
        real_mode_switch_call_vga((dev->bus->secondary << 8) |
dev->path.pci.devfn);
}

Now, the entry point looks like this:
diff -ur -x .git seabios2/src/romlayout.S seabios/src/romlayout.S
--- seabios2/src/romlayout.S    2008-11-06 15:46:44.000000000 +0100
+++ seabios/src/romlayout.S     2008-11-01 11:38:06.000000000 +0100
@@ -544,6 +544,18 @@
         ORG 0xff54
         IRQ_ENTRY_ARG 05

+.code32
+        ORG 0xffc0 // coreboot Entry Point
+       mov $0x3f8, %dx
+       mov $0x44, %al
+       outb %al, %dx // print
+       call _code32__init
+       mov $0x3f8, %dx
+       mov $0x45, %al
+       outb %al, %dx
+       ret
+.code16gcc
+
         ORG 0xfff0 // Power-up Entry Point
         ljmpw $SEG_BIOS, $post16

And _init looks like this (simplified):

void VISIBLE32
_init()
{
    outb('@', 0x3f8);
}

Unfortunately, this does not seem to work. The machine jumps somewhere
else and will triple fault eventually.

The outb to serial console in the assembler entry point work fine. If I
comment out the call to _code32__init, the function also returns nicely.
(printing "DE" on the way. But as soon as I leave the call in, seabios
crashes after printing "D" It does not even print the @.

Any hints?


Also, find attached a patch to allow cross compilation of SeaBIOS and
make it work with systems where /bin/echo does not know the option -e

Stefan

-- 
coresystems GmbH ? Brahmsstr. 16 ? D-79104 Freiburg i. Br.
      Tel.: +49 761 7668825 ? Fax: +49 761 7664613
Email: info at coresystems.de  ? http://www.coresystems.de/
Registergericht: Amtsgericht Freiburg ? HRB 7656
Gesch?ftsf?hrer: Stefan Reinauer ? Ust-IdNr.: DE245674866

-------------- next part --------------
A non-text attachment was scrubbed...
Name: seabios-make.diff
Type: text/x-patch
Size: 1762 bytes
Desc: not available
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20081106/4906665d/attachment.diff>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 249 bytes
Desc: OpenPGP digital signature
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20081106/4906665d/attachment.sig>

From rminnich at gmail.com  Thu Nov  6 16:33:56 2008
From: rminnich at gmail.com (ron minnich)
Date: Thu, 6 Nov 2008 07:33:56 -0800
Subject: [coreboot] r983 - in coreboot-v3: device include/device
In-Reply-To: <97E3D99CC80D4C818B3DC1301229D37F@chimp>
References: <20081105222854.3826gmx1@mx011.gmx.net> <4912C898.8030602@gmx.net>
	<97E3D99CC80D4C818B3DC1301229D37F@chimp>
Message-ID: <13426df10811060733x2af42783n95a639b8ea2cc1cf@mail.gmail.com>

v2 uses the #if X == 1

v3 uses #ifdef X

I doubt we want condifional compilation at all. coreboot is firmware,
not an OS, and we don't want lots of variant versions. I lean toward
yanking this type of conditional compilation.

thanks

ron



From rminnich at gmail.com  Thu Nov  6 16:39:21 2008
From: rminnich at gmail.com (ron minnich)
Date: Thu, 6 Nov 2008 07:39:21 -0800
Subject: [coreboot] Gigabyte GA-P965-S3 motherboard data and question.
In-Reply-To: <20081106141410.5176d2c6@buble>
References: <20081106141410.5176d2c6@buble>
Message-ID: <13426df10811060739hfe49f0dpd8fe71be14a75e47@mail.gmail.com>

On Thu, Nov 6, 2008 at 4:14 AM, Sasha Medvedev <sasha.medvedev at gmail.com> wrote:

> 3)How can I help? I suppose I was useless as programmer, may be there
> is some howtos how to adopt existing part's code. Probably I can support
> developers with this motherboard, if it brings really result. Or it
> will be easier to change my platform(for example on amd)?


It is easier to change to AMD or intel i945, which is supported.

We can always use help. If it is not code, it is writing. If it is not
writing, it is calling vendors and pushing them to do the right thing.
One thing is certain: we can ALWAYS use help!

If you would like to get a group of people together and contact intel
and try to get info on the i965, for purposes of doing the bios work,
that is a good idea.

Or you can mobilize the Ubuntu organization and have them help push on
vendors to get the information and support we need. I think Ubuntu
could be a very powerful force in this manner.

Thanks very much for your note.

thanks

ron



From mylesgw at gmail.com  Thu Nov  6 16:40:49 2008
From: mylesgw at gmail.com (Myles Watson)
Date: Thu, 6 Nov 2008 08:40:49 -0700
Subject: [coreboot] r983 - in coreboot-v3: device include/device
In-Reply-To: <13426df10811060733x2af42783n95a639b8ea2cc1cf@mail.gmail.com>
References: <20081105222854.3826gmx1@mx011.gmx.net> <4912C898.8030602@gmx.net>
	<97E3D99CC80D4C818B3DC1301229D37F@chimp>
	<13426df10811060733x2af42783n95a639b8ea2cc1cf@mail.gmail.com>
Message-ID: <16D5B6D7218F46FB9E8CC379AFDA3D13@chimp>


> v2 uses the #if X == 1
> 
> v3 uses #ifdef X
> 
> I doubt we want condifional compilation at all. coreboot is firmware,
> not an OS, and we don't want lots of variant versions. I lean toward
> yanking this type of conditional compilation.

I think the reason this was originally done was for size.  There might be
some people who are unhappy with HT, PCIe, and PCIx support compiled in for
their embedded box.

That being said, if the size isn't an issue, I'm all for yanking the ifs.

Myles




From rminnich at gmail.com  Thu Nov  6 16:43:47 2008
From: rminnich at gmail.com (ron minnich)
Date: Thu, 6 Nov 2008 07:43:47 -0800
Subject: [coreboot] r983 - in coreboot-v3: device include/device
In-Reply-To: <16D5B6D7218F46FB9E8CC379AFDA3D13@chimp>
References: <20081105222854.3826gmx1@mx011.gmx.net> <4912C898.8030602@gmx.net>
	<97E3D99CC80D4C818B3DC1301229D37F@chimp>
	<13426df10811060733x2af42783n95a639b8ea2cc1cf@mail.gmail.com>
	<16D5B6D7218F46FB9E8CC379AFDA3D13@chimp>
Message-ID: <13426df10811060743g3b8ea302t7acf5aec17c20b4f@mail.gmail.com>

On Thu, Nov 6, 2008 at 7:40 AM, Myles Watson <mylesgw at gmail.com> wrote:
>
>> v2 uses the #if X == 1
>>
>> v3 uses #ifdef X
>>
>> I doubt we want condifional compilation at all. coreboot is firmware,
>> not an OS, and we don't want lots of variant versions. I lean toward
>> yanking this type of conditional compilation.
>
> I think the reason this was originally done was for size.  There might be
> some people who are unhappy with HT, PCIe, and PCIx support compiled in for
> their embedded box.
>

Let me restate. I like the idea of NOT compiling in un-needed drivers.
I just wonder about the way it was done in device code.

Sorry, have not had breakfast yet, just got off the phone with comcast.

ron



From vincent.legoll at gmail.com  Thu Nov  6 16:49:04 2008
From: vincent.legoll at gmail.com (Vincent Legoll)
Date: Thu, 6 Nov 2008 16:49:04 +0100
Subject: [coreboot] r983 - in coreboot-v3: device include/device
In-Reply-To: <16D5B6D7218F46FB9E8CC379AFDA3D13@chimp>
References: <20081105222854.3826gmx1@mx011.gmx.net> <4912C898.8030602@gmx.net>
	<97E3D99CC80D4C818B3DC1301229D37F@chimp>
	<13426df10811060733x2af42783n95a639b8ea2cc1cf@mail.gmail.com>
	<16D5B6D7218F46FB9E8CC379AFDA3D13@chimp>
Message-ID: <4727185d0811060749l543a8711v4b81c97c9e80abdf@mail.gmail.com>

On Thu, Nov 6, 2008 at 4:40 PM, Myles Watson <mylesgw at gmail.com> wrote:
>> I doubt we want condifional compilation at all. coreboot is firmware,
>> not an OS, and we don't want lots of variant versions. I lean toward
>> yanking this type of conditional compilation.
>
> I think the reason this was originally done was for size.  There might be
> some people who are unhappy with HT, PCIe, and PCIx support compiled in for
> their embedded box.

Isn't all that kind of things doable via function pointers and link-time dead
code elimination ? That would achieve the no ifdeffery goal, and may be
cleaner code...

Am I on crack ?

-- 
Vincent Legoll



From rminnich at gmail.com  Thu Nov  6 16:59:44 2008
From: rminnich at gmail.com (ron minnich)
Date: Thu, 6 Nov 2008 07:59:44 -0800
Subject: [coreboot] r983 - in coreboot-v3: device include/device
In-Reply-To: <4727185d0811060749l543a8711v4b81c97c9e80abdf@mail.gmail.com>
References: <20081105222854.3826gmx1@mx011.gmx.net> <4912C898.8030602@gmx.net>
	<97E3D99CC80D4C818B3DC1301229D37F@chimp>
	<13426df10811060733x2af42783n95a639b8ea2cc1cf@mail.gmail.com>
	<16D5B6D7218F46FB9E8CC379AFDA3D13@chimp>
	<4727185d0811060749l543a8711v4b81c97c9e80abdf@mail.gmail.com>
Message-ID: <13426df10811060759l19af2a15ie18b0d1ea772bfe2@mail.gmail.com>

On Thu, Nov 6, 2008 at 7:49 AM, Vincent Legoll <vincent.legoll at gmail.com> wrote:

> Isn't all that kind of things doable via function pointers and link-time dead
> code elimination ? That would achieve the no ifdeffery goal, and may be
> cleaner code...
>
> Am I on crack ?
>

no we can do something like that Hold on, it's still early for me, I'm
not awake yet.
ron



From rminnich at gmail.com  Thu Nov  6 17:06:07 2008
From: rminnich at gmail.com (ron minnich)
Date: Thu, 6 Nov 2008 08:06:07 -0800
Subject: [coreboot] Supporting boards with NAND flash on other chip
	selects than CS0
In-Reply-To: <1225973589.4559.16.camel@martr-gentoo.artec>
References: <1225973589.4559.16.camel@martr-gentoo.artec>
Message-ID: <13426df10811060806x378538e6u964b41ac00ffa7e8@mail.gmail.com>

I like your idea of making the variable non-boolean. It makes sense,
and we did not intend the dts to just be booleans. People are starting
to really use the dts as we intended now.

Overall it's a good patch, modulo the fixes carl-daniel pointed out.
Can you revise and resubmit?

ron



From stepan at coresystems.de  Thu Nov  6 17:16:51 2008
From: stepan at coresystems.de (Stefan Reinauer)
Date: Thu, 06 Nov 2008 17:16:51 +0100
Subject: [coreboot] r983 - in coreboot-v3: device include/device
In-Reply-To: <4727185d0811060749l543a8711v4b81c97c9e80abdf@mail.gmail.com>
References: <20081105222854.3826gmx1@mx011.gmx.net>
	<4912C898.8030602@gmx.net>	<97E3D99CC80D4C818B3DC1301229D37F@chimp>	<13426df10811060733x2af42783n95a639b8ea2cc1cf@mail.gmail.com>	<16D5B6D7218F46FB9E8CC379AFDA3D13@chimp>
	<4727185d0811060749l543a8711v4b81c97c9e80abdf@mail.gmail.com>
Message-ID: <49131873.60305@coresystems.de>

Vincent Legoll wrote:
> Isn't all that kind of things doable via function pointers and link-time dead
> code elimination ? That would achieve the no ifdeffery goal, and may be
> cleaner code...
Link time optimization would suggest we look into compiling with LLVM
instead of gcc.

Has anyone tried this, yet?


-- 
coresystems GmbH ? Brahmsstr. 16 ? D-79104 Freiburg i. Br.
      Tel.: +49 761 7668825 ? Fax: +49 761 7664613
Email: info at coresystems.de  ? http://www.coresystems.de/
Registergericht: Amtsgericht Freiburg ? HRB 7656
Gesch?ftsf?hrer: Stefan Reinauer ? Ust-IdNr.: DE245674866


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 249 bytes
Desc: OpenPGP digital signature
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20081106/b41b536e/attachment.sig>

From rminnich at gmail.com  Thu Nov  6 17:16:55 2008
From: rminnich at gmail.com (ron minnich)
Date: Thu, 6 Nov 2008 08:16:55 -0800
Subject: [coreboot] ubuntu help!
Message-ID: <13426df10811060816sc4c5e25oc81983bc530abeb0@mail.gmail.com>

we're getting lots of good emails from the help ubuntu post. I am
worried we're going to lose those people in the daily traffic.

Would someone or someones be weilling to be our ubuntu
contact/ambassador? The goal is to make sure the people contributing
feel welcome and continue the dialogue with ubuntu.

thanks

ron



From mylesgw at gmail.com  Thu Nov  6 17:24:35 2008
From: mylesgw at gmail.com (Myles Watson)
Date: Thu, 6 Nov 2008 10:24:35 -0600
Subject: [coreboot] HT Doc
Message-ID: <2831fecf0811060824t2f195835v4bf6bd63cb7013c8@mail.gmail.com>

Sorry it's rough.  I'm really ready to clean up the #if statements in this
code.  This is for hypertransport.c, next is northbridge/amd/k8/*.c

Thanks,
Myles
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20081106/3e20adf2/attachment.html>
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: ht_doc.txt
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20081106/3e20adf2/attachment.txt>

From rminnich at gmail.com  Thu Nov  6 17:33:36 2008
From: rminnich at gmail.com (ron minnich)
Date: Thu, 6 Nov 2008 08:33:36 -0800
Subject: [coreboot] HT Doc
In-Reply-To: <2831fecf0811060824t2f195835v4bf6bd63cb7013c8@mail.gmail.com>
References: <2831fecf0811060824t2f195835v4bf6bd63cb7013c8@mail.gmail.com>
Message-ID: <13426df10811060833o5529a621tcad9a5ff24cdb136@mail.gmail.com>

good stuff. I will have to reread several times to understand it ...

with the code, we will have to move slowly, as it is tricky, but I
think you're pointing good directions.

ron



From mylesgw at gmail.com  Thu Nov  6 17:37:47 2008
From: mylesgw at gmail.com (Myles Watson)
Date: Thu, 6 Nov 2008 09:37:47 -0700
Subject: [coreboot] HT Doc
In-Reply-To: <13426df10811060833o5529a621tcad9a5ff24cdb136@mail.gmail.com>
References: <2831fecf0811060824t2f195835v4bf6bd63cb7013c8@mail.gmail.com>
	<13426df10811060833o5529a621tcad9a5ff24cdb136@mail.gmail.com>
Message-ID: <4ED5324C1D8A4CFD9F77FC895348A63E@chimp>

> good stuff. I will have to reread several times to understand it ...

Thanks.

Feel free to ask for clarification.  It's always hard to know which things
are easiest to understand.  I'm happy to generate more examples for the
explanation if they would help.

> with the code, we will have to move slowly, as it is tricky, but I
> think you're pointing good directions.

Uh-oh, that's gonna make the Rev 1000 goal tricky.  I was planning on one
big patch since you sent me that goal. :)  

Thanks,
Myles




From mylesgw at gmail.com  Thu Nov  6 17:46:27 2008
From: mylesgw at gmail.com (Myles Watson)
Date: Thu, 6 Nov 2008 09:46:27 -0700
Subject: [coreboot] r983 - in coreboot-v3: device include/device
In-Reply-To: <49131873.60305@coresystems.de>
References: <20081105222854.3826gmx1@mx011.gmx.net>
	<4912C898.8030602@gmx.net>	<97E3D99CC80D4C818B3DC1301229D37F@chimp>	<13426df10811060733x2af42783n95a639b8ea2cc1cf@mail.gmail.com>	<16D5B6D7218F46FB9E8CC379AFDA3D13@chimp>
	<4727185d0811060749l543a8711v4b81c97c9e80abdf@mail.gmail.com>
	<49131873.60305@coresystems.de>
Message-ID: <666AD731FD2040DE8D4672F41DC3E56C@chimp>



> -----Original Message-----
> From: Stefan Reinauer [mailto:stepan at coresystems.de]
> Sent: Thursday, November 06, 2008 9:17 AM
> To: Vincent Legoll
> Cc: Myles Watson; ron minnich; Carl-Daniel Hailfinger;
> coreboot at coreboot.org
> Subject: Re: [coreboot] r983 - in coreboot-v3: device include/device
> 
> Vincent Legoll wrote:
> > Isn't all that kind of things doable via function pointers and link-time
> dead
> > code elimination ? That would achieve the no ifdeffery goal, and may be
> > cleaner code...
> Link time optimization would suggest we look into compiling with LLVM
> instead of gcc.
> 
> Has anyone tried this, yet?
> 

As a start that wouldn't change the code much and would still work with gcc,
we could have an enum or defines in the device code and a table where the
device code that was compiled in could initialize a pointer to its default
ops.  In practice it only affects dynamically detected bridges, but it would
be nice to support them.

Something like

#define DEVICE_PCI_DRIVER_NUM 1
#define DEVICE_HT_DRIVER_NUM 2
#define DEVICE_PCIE_DRIVER_NUM 1
#define DEVICE_PCIX_DRIVER_NUM 1
#define DEVICE_MAX_DRIVERS DEVICE_PCIX_DRIVER_NUM+1

static const device_operations * default_drivers[DEVICE_MAX_DRIVERS];

Then each device could set them:

default_drivers[DEVICE_HT_DRIVER_NUM] = &default_ht_ops_bus;

Or something similar.  Note that this is just dry coding.

Thanks,
Myles


Thanks,
Myles




From vincent.legoll at gmail.com  Thu Nov  6 18:10:01 2008
From: vincent.legoll at gmail.com (Vincent Legoll)
Date: Thu, 6 Nov 2008 18:10:01 +0100
Subject: [coreboot] r983 - in coreboot-v3: device include/device
In-Reply-To: <49131873.60305@coresystems.de>
References: <20081105222854.3826gmx1@mx011.gmx.net> <4912C898.8030602@gmx.net>
	<97E3D99CC80D4C818B3DC1301229D37F@chimp>
	<13426df10811060733x2af42783n95a639b8ea2cc1cf@mail.gmail.com>
	<16D5B6D7218F46FB9E8CC379AFDA3D13@chimp>
	<4727185d0811060749l543a8711v4b81c97c9e80abdf@mail.gmail.com>
	<49131873.60305@coresystems.de>
Message-ID: <4727185d0811060910l6b119215ycd4d1284d56cf461@mail.gmail.com>

On Thu, Nov 6, 2008 at 5:16 PM, Stefan Reinauer <stepan at coresystems.de> wrote:
> Vincent Legoll wrote:
>> Isn't all that kind of things doable via function pointers and link-time dead
>> code elimination ? That would achieve the no ifdeffery goal, and may be
>> cleaner code...
> Link time optimization would suggest we look into compiling with LLVM
> instead of gcc.

I was believing that current linkers discarded code of unused functions.
Would LLVM really be needed for that to happen ? Or are you thing of
more involved optimizations ?

> Has anyone tried this, yet?

Not me

-- 
Vincent Legoll



From bari at onelabs.com  Thu Nov  6 18:39:11 2008
From: bari at onelabs.com (bari)
Date: Thu, 06 Nov 2008 11:39:11 -0600
Subject: [coreboot] ubuntu help!
In-Reply-To: <13426df10811060816sc4c5e25oc81983bc530abeb0@mail.gmail.com>
References: <13426df10811060816sc4c5e25oc81983bc530abeb0@mail.gmail.com>
Message-ID: <49132BBF.7090902@onelabs.com>

ron minnich wrote:
> we're getting lots of good emails from the help ubuntu post. I am
> worried we're going to lose those people in the daily traffic.
>
> Would someone or someones be weilling to be our ubuntu
> contact/ambassador? The goal is to make sure the people contributing
> feel welcome and continue the dialogue with ubuntu.
>
>   
I'll be happy to help with Ubuntu and with anything VIA as a contact.

-Bari



From svn at coreboot.org  Thu Nov  6 18:52:52 2008
From: svn at coreboot.org (svn at coreboot.org)
Date: Thu,  6 Nov 2008 18:52:52 +0100
Subject: [coreboot] r985 - in coreboot-v3: mainboard/artecgroup/dbe62
	southbridge/amd/cs5536
Message-ID: <mailman.2392.1355071426.16123.coreboot@coreboot.org>

Author: mraudsepp
Date: 2008-11-06 18:52:52 +0100 (Thu, 06 Nov 2008)
New Revision: 985

Modified:
   coreboot-v3/mainboard/artecgroup/dbe62/dts
   coreboot-v3/southbridge/amd/cs5536/cs5536.c
   coreboot-v3/southbridge/amd/cs5536/dts
Log:
cs5536: Support NAND flash on other locations than CS0

Modify chipset_flash_setup to support enabling NAND flash on other locations
than CS0, by making enable_ide_nand_flash have a non-boolean meaning where zero
means no NAND (IDE), and 1 through 4 gives the one-based chip select array
location (so 1 means CS0, 2 means CS1, 3 means CS2 and 4 means CS3, as chip
select notation is zero-based).

This loses the code for supporting more than one NAND chip select or different
ones than FLASH_MEM_4K, but these couldn't be supported before anyway, because
that is board specific, but the supporting structure was a static const struct
in generic southbridge specific code.
This support should be instead implemented via the device tree dts files.

Enables NAND on ArtecGroup DBE61 and DBE62 on CS1, as that's where  it is.
The end result is that these mainboards can now boot off of NAND with FILO
without local modifications to the previously existing southbridge specific
static const struct that had no chance of being upstreamed as it would break
all other CS5536 NAND boards that have it on CS0.

Signed-off-by: Mart Raudsepp <mart.raudsepp at artecdesign.ee>
Acked-by: Carl-Daniel Hailfinger <c-d.hailfinger.devel.2006 at gmx.net>

Modified: coreboot-v3/mainboard/artecgroup/dbe62/dts
===================================================================
--- coreboot-v3/mainboard/artecgroup/dbe62/dts	2008-11-06 13:59:14 UTC (rev 984)
+++ coreboot-v3/mainboard/artecgroup/dbe62/dts	2008-11-06 17:52:52 UTC (rev 985)
@@ -44,8 +44,8 @@
 			/* GPIO(0-0x20) for INT D:C:B:A, 0xFF=none. 
 			 * See virtual PIC spec. */
 			enable_gpio_int_route = "0x0D0C0700";
-			/* 0:IDE 1:FLASH */
-			enable_ide_nand_flash = "1";
+			/* 0:IDE; 1:FLASH on CS0, 2:FLASH on CS1, 3:FLASH on CS2, 4:FLASH on CS3. */
+			enable_ide_nand_flash = "2";
 			/* we use com2 since that is on the dongle */
 			com2_enable = "1";
 			/* Set com2 address to be COM1 */

Modified: coreboot-v3/southbridge/amd/cs5536/cs5536.c
===================================================================
--- coreboot-v3/southbridge/amd/cs5536/cs5536.c	2008-11-06 13:59:14 UTC (rev 984)
+++ coreboot-v3/southbridge/amd/cs5536/cs5536.c	2008-11-06 17:52:52 UTC (rev 985)
@@ -68,19 +68,6 @@
 	{0, 0}
 };
 
-struct FLASH_DEVICE {
-	unsigned char fType;		/* Flash type: NOR or NAND */
-	unsigned char fInterface;	/* Flash interface: I/O or memory */
-	unsigned long fMask;		/* Flash size/mask */
-};
-
-static const struct FLASH_DEVICE FlashInitTable[] = {
-	{FLASH_TYPE_NAND, FLASH_IF_MEM, FLASH_MEM_4K},	/* CS0, or Flash Device 0 */
-	{FLASH_TYPE_NONE, 0, 0},	/* CS1, or Flash Device 1 */
-	{FLASH_TYPE_NONE, 0, 0},	/* CS2, or Flash Device 2 */
-	{FLASH_TYPE_NONE, 0, 0},	/* CS3, or Flash Device 3 */
-};
-
 static const u32 FlashPort[] = {
 	MDD_LBAR_FLSH0,
 	MDD_LBAR_FLSH1,
@@ -154,38 +141,31 @@
  * correct size info. Call this routine only if flash needs to be
  * configured (don't call it if you want IDE).
  */
-static void chipset_flash_setup(void)
+static void chipset_flash_setup(struct southbridge_amd_cs5536_dts_config *sb)
 {
 	int i;
 	struct msr msr;
 
 	printk(BIOS_DEBUG, "chipset_flash_setup: Start\n");
-	for (i = 0; i < ARRAY_SIZE(FlashInitTable); i++) {
-		if (FlashInitTable[i].fType != FLASH_TYPE_NONE) {
-			printk(BIOS_DEBUG, "Enable CS%d\n", i);
-			/* We need to configure the memory/IO mask. */
-			msr = rdmsr(FlashPort[i]);
-			msr.hi = 0;	/* Start with "enabled" bit clear. */
-			if (FlashInitTable[i].fType == FLASH_TYPE_NAND)
-				msr.hi |= 0x00000002;
-			else
-				msr.hi &= ~0x00000002;
-			if (FlashInitTable[i].fInterface == FLASH_IF_MEM)
-				msr.hi |= 0x00000004;
-			else
-				msr.hi &= ~0x00000004;
-			msr.hi |= FlashInitTable[i].fMask;
-			printk(BIOS_DEBUG, "MSR(0x%08X, %08X_%08X)\n",
-			       FlashPort[i], msr.hi, msr.lo);
-			wrmsr(FlashPort[i], msr);
+	if (sb->enable_ide_nand_flash <= 4) {
+		i = sb->enable_ide_nand_flash - 1;
+		printk(BIOS_DEBUG, "Enable CS%d\n", i);
+		/* We need to configure the memory/IO mask. */
+		msr = rdmsr(FlashPort[i]);
+		msr.hi = 0;	/* Start with "enabled" bit clear. */
+		msr.hi |= 0x00000002; /* For FLASH_TYPE_NAND */
+		msr.hi |= 0x00000004; /* For FLASH_IF_MEM */
+		msr.hi |= FLASH_MEM_4K;
+		printk(BIOS_DEBUG, "MSR(0x%08X, %08X_%08X)\n",
+		       FlashPort[i], msr.hi, msr.lo);
+		wrmsr(FlashPort[i], msr);
 
-			/* Now write-enable the device. */
-			msr = rdmsr(MDD_NORF_CNTRL);
-			msr.lo |= (1 << i);
-			printk(BIOS_DEBUG, "MSR(0x%08X, %08X_%08X)\n",
-			       MDD_NORF_CNTRL, msr.hi, msr.lo);
-			wrmsr(MDD_NORF_CNTRL, msr);
-		}
+		/* Now write-enable the device. */
+		msr = rdmsr(MDD_NORF_CNTRL);
+		msr.lo |= (1 << i);
+		printk(BIOS_DEBUG, "MSR(0x%08X, %08X_%08X)\n",
+		       MDD_NORF_CNTRL, msr.hi, msr.lo);
+		wrmsr(MDD_NORF_CNTRL, msr);
 	}
 	printk(BIOS_DEBUG, "chipset_flash_setup: Finish\n");
 }
@@ -596,9 +576,9 @@
 
 	/* Flash BAR size setup. */
 	printk(BIOS_ERR, "%sDoing chipset_flash_setup()\n",
-	       sb->enable_ide_nand_flash == 1 ? "" : "Not ");
-	if (sb->enable_ide_nand_flash == 1)
-		chipset_flash_setup();
+	       sb->enable_ide_nand_flash != 0 ? "" : "Not ");
+	if (sb->enable_ide_nand_flash != 0)
+		chipset_flash_setup(sb);
 
 	/* Set up hardware clock gating. */
 	/* TODO: Why the extra block here? Can it be removed? */
@@ -680,7 +660,7 @@
 
 	printk(BIOS_ERR, "cs5536: %s: enable_ide_nand_flash is %d\n",
 	       __FUNCTION__, sb->enable_ide_nand_flash);
-	if (sb->enable_ide_nand_flash == 1)
+	if (sb->enable_ide_nand_flash != 0)
 		enable_ide_nand_flash_header();
 
 	enable_USB_port4(sb);

Modified: coreboot-v3/southbridge/amd/cs5536/dts
===================================================================
--- coreboot-v3/southbridge/amd/cs5536/dts	2008-11-06 13:59:14 UTC (rev 984)
+++ coreboot-v3/southbridge/amd/cs5536/dts	2008-11-06 17:52:52 UTC (rev 985)
@@ -33,7 +33,7 @@
 	/* GPIO(0-0x20) for INT D:C:B:A, 0xFF=none. See virtual PIC spec. */
 	enable_gpio_int_route = "0";
 
-	/* 0:IDE 1:FLASH, if you are using NAND flash instead of IDE drive. */
+	/* 0:IDE; 1:FLASH on CS0, 2:FLASH on CS1, 3:FLASH on CS2, 4:FLASH on CS3. */
 	enable_ide_nand_flash = "0";
 
 	/* Enable USB Port 4 (0:host 1:device). 




From mart.raudsepp at artecdesign.ee  Thu Nov  6 19:01:29 2008
From: mart.raudsepp at artecdesign.ee (Mart Raudsepp)
Date: Thu, 06 Nov 2008 20:01:29 +0200
Subject: [coreboot] Supporting boards with NAND flash on other
	chip	selects than CS0
In-Reply-To: <13426df10811060806x378538e6u964b41ac00ffa7e8@mail.gmail.com>
References: <1225973589.4559.16.camel@martr-gentoo.artec>
	<13426df10811060806x378538e6u964b41ac00ffa7e8@mail.gmail.com>
Message-ID: <1225994489.8331.7.camel@martr-gentoo.artec>

?hel kenal p?eval, N, 2008-11-06 kell 08:06, kirjutas ron minnich:
> I like your idea of making the variable non-boolean. It makes sense,
> and we did not intend the dts to just be booleans. People are starting
> to really use the dts as we intended now.
> 
> Overall it's a good patch, modulo the fixes carl-daniel pointed out.
> Can you revise and resubmit?

r985. Was waiting for work day end before simply git svn dcommit'ing to
get any further comments.
Mainly because I'm not all that happy with it myself, as it does lose
code - even though code whose functionality can't be used without
board-specific configuration support which doesn't exist.

So I have two concerns here (or lets say things we might want to work on
on top of this):

* There is no way to specify more than one NAND, or extra NOR setup, or
different NAND mapping (page size?), etc. Basically all the arguments in
the previous FlashInitTable structure - you could tell type, interface
and mask separately for each chip select. If that possibility might be
necessary for some boards in the future, then some more extensive
support in dts is needed. The main problem here is that the code
handling such an extensive struct configuration is now deleted (though
of course visible in SVN history if you know to look).
That said, I'm not even sure any of the other possibilities many any
sense in context of CS5536 - more than one NAND or different types, or
different mapping than 4K.

* CS1 counter-intuitively wanting enable_ide_nand_flash="2", etc. At
least that's commented in the southbridge dts' above the default
setting.


Regards,
Mart Raudespp




From rminnich at gmail.com  Thu Nov  6 19:04:19 2008
From: rminnich at gmail.com (ron minnich)
Date: Thu, 6 Nov 2008 10:04:19 -0800
Subject: [coreboot] Supporting boards with NAND flash on other chip
	selects than CS0
In-Reply-To: <1225994489.8331.7.camel@martr-gentoo.artec>
References: <1225973589.4559.16.camel@martr-gentoo.artec>
	<13426df10811060806x378538e6u964b41ac00ffa7e8@mail.gmail.com>
	<1225994489.8331.7.camel@martr-gentoo.artec>
Message-ID: <13426df10811061004g7d3dcbc6qe2132230ac7f7a4@mail.gmail.com>

On Thu, Nov 6, 2008 at 10:01 AM, Mart Raudsepp
<mart.raudsepp at artecdesign.ee> wrote:

> * There is no way to specify more than one NAND, or extra NOR setup, or
> different NAND mapping (page size?), etc. Basically all the arguments in
> the previous FlashInitTable structure - you could tell type, interface
> and mask separately for each chip select. If that possibility might be
> necessary for some boards in the future, then some more extensive
> support in dts is needed. The main problem here is that the code
> handling such an extensive struct configuration is now deleted (though
> of course visible in SVN history if you know to look).
> That said, I'm not even sure any of the other possibilities many any
> sense in context of CS5536 - more than one NAND or different types, or
> different mapping than 4K.

I believe geode is end of life; I don't expect to see lots of future
designs. We may want this back in future but it is not likely.

It's a good solution for the short term, and there is no long term.

thanks

ron



From c-d.hailfinger.devel.2006 at gmx.net  Thu Nov  6 19:14:28 2008
From: c-d.hailfinger.devel.2006 at gmx.net (Carl-Daniel Hailfinger)
Date: Thu, 06 Nov 2008 19:14:28 +0100
Subject: [coreboot] [PATCH] v3: Kill unnecessary rebuilds
In-Reply-To: <4912FF5E.60302@coresystems.de>
References: <4912EAE2.8060906@gmx.net> <4912F52E.5090107@coresystems.de>
	<4912F853.3070205@gmx.net> <4912FD5C.3010107@gmx.net>
	<4912FF5E.60302@coresystems.de>
Message-ID: <49133404.6000004@gmx.net>

On 06.11.2008 15:29, Stefan Reinauer wrote:
> Carl-Daniel Hailfinger wrote:
>   
>> On 06.11.2008 14:59, Carl-Daniel Hailfinger wrote:
>>   
>>     
>>> On 06.11.2008 14:46, Stefan Reinauer wrote:
>>>   
>>>     
>>>       
>>>> Carl-Daniel Hailfinger wrote:
>>>>   
>>>>     
>>>>       
>>>>         
>>>>> Every time we run make in a v3 tree, lar, lzma, nrv2b and the option
>>>>> table get rebuilt unconditionally due to slightly incorrect dependencies.
>>>>> That's wasteful and may hide other dependency bugs.
>>>>> Fix the lar, lzma, nrv2b and option table dependencies.
>>>>>
>>>>> This trims down recompilation time a lot. The only remaining stuff being
>>>>> rebuilt is:
>>>>> ~/corebootv3-better_dependencies> make
>>>>>   CP      build/config.h
>>>>>   GEN     build/build.h
>>>>>   LAR     build/coreboot.rom
>>>>>   PAYLOAD none (as specified by user)
>>>>>   CP      build/bios.bin
>>>>>   DONE
>>>>>
>>>>> Signed-off-by: Carl-Daniel Hailfinger <c-d.hailfinger.devel.2006 at gmx.net>
>>>>>
>>>>>   
>>>>>     
>>>>>       
>>>>>         
>>>>>           
>>>> Acked-by: Stefan Reinauer <stepan at coresystems.de>
>>>>   
>>>>     
>>>>       
>>>>         
>>> Thanks, committed in r984.
>>>   
>>>     
>>>       
>> I wanted to clean this up further, but I'm hitting a big dependency bug.
>> Try this patch and watch make explode:
>>
>> Index: util/lar/Makefile
>> ===================================================================
>> --- util/lar/Makefile	(Revision 984)
>> +++ util/lar/Makefile	(Arbeitskopie)
>> @@ -22,10 +22,8 @@
>>  LARDIR := $(obj)/util/lar/
>>  
>>  COMPRESSOR := $(LZMA_OBJ) $(obj)/util/lzma/lzma-compress.o
>> -LARDIR     += $(obj)/util/lzma/
>>  
>>  COMPRESSOR += $(obj)/util/nrv2b/nrv2b-compress.o
>> -LARDIR     += $(obj)/util/nrv2b/
>>  
>>  LAROBJ_ABS := $(patsubst %,$(obj)/util/lar/%,$(LAROBJ))
>>  
>>   
>> Fixing this would require us to add build/util/lzma/ as a dependency to
>> every lzma object in util/lzma/Makefile. And that's the point where I
>> ask about better solutions.
>>     
>
> I think leaving it as it is sounds like a better solution already ;-)
>   

The lzma dependencies are already broken (since the initial commit in
r157) and parallel make is going to trip on them. My test patch above
just makes this visible on singlethreaded make.
Of course we can declare parallel make as unusable in v3 (like it is in
v2, see the spurious breakage there), but I'd prefer to do this the
right way.

Regards,
Carl-Daniel

-- 
http://www.hailfinger.org/




From z4ziggy at gmail.com  Thu Nov  6 19:38:31 2008
From: z4ziggy at gmail.com (Elia Yehuda)
Date: Thu, 6 Nov 2008 20:38:31 +0200
Subject: [coreboot] fixing i810 onboard vga
Message-ID: <e19d85410811061038x5e9f054ft4ec3b1b93efd029e@mail.gmail.com>

Hey all,

im working at the on the i810, trying to fix the onboard-vga to work.

removing the commented code of the vga-related stuff resulted with the pci
device to be displayed in the pci list on coreboot, but in a disabled state,
and (as promised...) with the boot not executing the payload. complete log
can be shown here : http://pastebin.com/m20e821eb

a few rough patches to my target and i82810/raminit.c and now the device is
shown as enabled and i even get the information about the VGA allocating
resources :

Allocating VGA resource PCI: 00:01.0
Setting PCI_BRIDGE_CTL_VGA for bridge PCI_DOMAIN: 0000
Setting PCI_BRIDGE_CTL_VGA for bridge Root Device

but the payload still wont execute (it is seems to be loaded though) and
ofcourse, no VGA output, only serial, with a dead boot hanging...
complete log can be shown here : http://pastebin.com/m248a41ea

i'd appreciate any clues/assistance in the matter.

Regards,
Elia Yehuda.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20081106/b4ac0691/attachment.html>

From rminnich at gmail.com  Thu Nov  6 20:11:30 2008
From: rminnich at gmail.com (ron minnich)
Date: Thu, 6 Nov 2008 11:11:30 -0800
Subject: [coreboot] ubuntu help!
In-Reply-To: <49133EED.1090304@zl2tod.net>
References: <13426df10811060816sc4c5e25oc81983bc530abeb0@mail.gmail.com>
	<49133EED.1090304@zl2tod.net>
Message-ID: <13426df10811061111x3990fed3q4170f5226824b39a@mail.gmail.com>

On Thu, Nov 6, 2008 at 11:01 AM, Mark Robinson <mark at zl2tod.net> wrote:

> I've collected seven of these submissions together. I've probably missed
> some.
>
> Is there a place we can put them all together ? Perhaps an email address or
> a wiki page.

coreboot wiki?

>
> Where did that script to collect hardware information end up? I spent some
> time looking for it but failed to turn it up.

I don't know, the submissions have been slightly different; is it  a script?

>
> I'm happy to do some of this stuff as resources permit.


maybe you and bari can work together to lighten each persons load?

ron



From michalwd1979 at gmail.com  Thu Nov  6 20:17:01 2008
From: michalwd1979 at gmail.com (Michal Widlok)
Date: Thu, 6 Nov 2008 20:17:01 +0100
Subject: [coreboot] Dell PE2850 with coreboot.
Message-ID: <e7dbcb740811061117r6601cbd6lc47ed7ecaa6271fe@mail.gmail.com>

Hello,
I'm new to this lis and to coreboot, so please forgive me dumb
questions for a while :-). I would like to learn some more about it
and maybe install it on my Dell 2850. I've red then there is a WIP for
coreboot on dell 1850 - this one is similar to mine. Where can I get
some more information about this work? Is there any tutorial or other
info that explains how to install coreboot on dells?

Best Regards,
Michael W.



From vincent.legoll at gmail.com  Thu Nov  6 20:33:49 2008
From: vincent.legoll at gmail.com (Vincent Legoll)
Date: Thu, 6 Nov 2008 20:33:49 +0100
Subject: [coreboot] Dell PE2850 with coreboot.
In-Reply-To: <e7dbcb740811061117r6601cbd6lc47ed7ecaa6271fe@mail.gmail.com>
References: <e7dbcb740811061117r6601cbd6lc47ed7ecaa6271fe@mail.gmail.com>
Message-ID: <4727185d0811061133u682ed52ck592fb43b867e6368@mail.gmail.com>

On Thu, Nov 6, 2008 at 8:17 PM, Michal Widlok <michalwd1979 at gmail.com> wrote:
> Hello,
> I'm new to this lis and to coreboot, so please forgive me dumb
> questions for a while :-). I would like to learn some more about it
> and maybe install it on my Dell 2850. I've red then there is a WIP for
> coreboot on dell 1850 - this one is similar to mine. Where can I get
> some more information about this work? Is there any tutorial or other
> info that explains how to install coreboot on dells?

First, you should ensure you have a way to recover from problems:

Is your flash chip soldered or socketed on the motherboard ?
If not, any failure (bad flashing or wrong coreboot) and you've
got an expensive doorstop.
If yes, do you have at least one spare compatible chip with an
original bios flashed onto, to recover from failures ?

Then you're fairly safe to try, test, or hack on coreboot.

A serial console (to another host) setup and working is good
to have, because VGA may not work at first.

-- 
Vincent Legoll



From stepan at coresystems.de  Thu Nov  6 21:17:47 2008
From: stepan at coresystems.de (Stefan Reinauer)
Date: Thu, 06 Nov 2008 21:17:47 +0100
Subject: [coreboot] [PATCH] v2: ICH7: Drop non-working enable_hpet() for
 now
In-Reply-To: <20081031194315.GF18273@greenwood>
References: <20081031194315.GF18273@greenwood>
Message-ID: <491350EB.2040604@coresystems.de>

Uwe Hermann wrote:
> Please correct me if I'm wrong (I don't have NDA'd Intel datasheets, I
> can only check the public ones), but I think the enable_hpet() in the
> ICH7 code will not work for ICH7. It should work for ICH4/ICH5 or so,
> but ICH7 requires a completely different init involving RCBA, offset
> 0x3404, it seems.
>
> Thus, drop the non-working code, add a TODO until somebody writes the
> proper code for ICH7. Maybe I'll do that if nobody beats me to it, but
> it may take a while.
>
>   

Acked-by: Stefan Reinauer <stepan at coresystems.de>

-- 
coresystems GmbH ? Brahmsstr. 16 ? D-79104 Freiburg i. Br.
      Tel.: +49 761 7668825 ? Fax: +49 761 7664613
Email: info at coresystems.de  ? http://www.coresystems.de/
Registergericht: Amtsgericht Freiburg ? HRB 7656
Gesch?ftsf?hrer: Stefan Reinauer ? Ust-IdNr.: DE245674866


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 249 bytes
Desc: OpenPGP digital signature
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20081106/a3edc64e/attachment.sig>

From stepan at coresystems.de  Thu Nov  6 21:18:01 2008
From: stepan at coresystems.de (Stefan Reinauer)
Date: Thu, 06 Nov 2008 21:18:01 +0100
Subject: [coreboot] [PATCH] v2: ICH7: Drop/fix some ICH7 register
	#defines
In-Reply-To: <20081031210537.GH18273@greenwood>
References: <20081031210537.GH18273@greenwood>
Message-ID: <491350F9.6030401@coresystems.de>

Uwe Hermann wrote:
> This patch will fail to compile without my other patch to drop/disable
> the non-working enable_hpet() function in ICH7.
>
>
> Uwe.
>   
Acked-by: Stefan Reinauer <stepan at coresystems.de>



-- 
coresystems GmbH ? Brahmsstr. 16 ? D-79104 Freiburg i. Br.
      Tel.: +49 761 7668825 ? Fax: +49 761 7664613
Email: info at coresystems.de  ? http://www.coresystems.de/
Registergericht: Amtsgericht Freiburg ? HRB 7656
Gesch?ftsf?hrer: Stefan Reinauer ? Ust-IdNr.: DE245674866


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 249 bytes
Desc: OpenPGP digital signature
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20081106/59a9ce05/attachment.sig>

From stepan at coresystems.de  Thu Nov  6 21:21:55 2008
From: stepan at coresystems.de (Stefan Reinauer)
Date: Thu, 06 Nov 2008 21:21:55 +0100
Subject: [coreboot] r983 - in coreboot-v3: device include/device
In-Reply-To: <4727185d0811060910l6b119215ycd4d1284d56cf461@mail.gmail.com>
References: <20081105222854.3826gmx1@mx011.gmx.net> <4912C898.8030602@gmx.net>	
	<97E3D99CC80D4C818B3DC1301229D37F@chimp>	
	<13426df10811060733x2af42783n95a639b8ea2cc1cf@mail.gmail.com>	
	<16D5B6D7218F46FB9E8CC379AFDA3D13@chimp>	
	<4727185d0811060749l543a8711v4b81c97c9e80abdf@mail.gmail.com>	
	<49131873.60305@coresystems.de>
	<4727185d0811060910l6b119215ycd4d1284d56cf461@mail.gmail.com>
Message-ID: <491351E3.3070803@coresystems.de>

Vincent Legoll wrote:
> On Thu, Nov 6, 2008 at 5:16 PM, Stefan Reinauer <stepan at coresystems.de> wrote:
>   
>> Vincent Legoll wrote:
>>     
>>> Isn't all that kind of things doable via function pointers and link-time dead
>>> code elimination ? That would achieve the no ifdeffery goal, and may be
>>> cleaner code...
>>>       
>> Link time optimization would suggest we look into compiling with LLVM
>> instead of gcc.
>>     
>
> I was believing that current linkers discarded code of unused functions.
> Would LLVM really be needed for that to happen ? Or are you thing of
> more involved optimizations ?
>   
Any non-static functions in a file will stay in the final binary, unless
you do some trickery like -combine, but that usually requires some
changes to the build system.

llvm will kick those functions out at link time. As does the plan9
linker, as far as I understood.


-- 
coresystems GmbH ? Brahmsstr. 16 ? D-79104 Freiburg i. Br.
      Tel.: +49 761 7668825 ? Fax: +49 761 7664613
Email: info at coresystems.de  ? http://www.coresystems.de/
Registergericht: Amtsgericht Freiburg ? HRB 7656
Gesch?ftsf?hrer: Stefan Reinauer ? Ust-IdNr.: DE245674866


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 249 bytes
Desc: OpenPGP digital signature
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20081106/35ab8f7b/attachment.sig>

From rminnich at gmail.com  Thu Nov  6 21:23:02 2008
From: rminnich at gmail.com (ron minnich)
Date: Thu, 6 Nov 2008 12:23:02 -0800
Subject: [coreboot] r983 - in coreboot-v3: device include/device
In-Reply-To: <491351E3.3070803@coresystems.de>
References: <20081105222854.3826gmx1@mx011.gmx.net> <4912C898.8030602@gmx.net>
	<97E3D99CC80D4C818B3DC1301229D37F@chimp>
	<13426df10811060733x2af42783n95a639b8ea2cc1cf@mail.gmail.com>
	<16D5B6D7218F46FB9E8CC379AFDA3D13@chimp>
	<4727185d0811060749l543a8711v4b81c97c9e80abdf@mail.gmail.com>
	<49131873.60305@coresystems.de>
	<4727185d0811060910l6b119215ycd4d1284d56cf461@mail.gmail.com>
	<491351E3.3070803@coresystems.de>
Message-ID: <13426df10811061223o6df9c81fm99bc50ef732d05ee@mail.gmail.com>

On Thu, Nov 6, 2008 at 12:21 PM, Stefan Reinauer <stepan at coresystems.de> wrote:
>As does the plan9
> linker, as far as I understood.
>

you got it :-)

ron



From c-d.hailfinger.devel.2006 at gmx.net  Thu Nov  6 21:50:56 2008
From: c-d.hailfinger.devel.2006 at gmx.net (Carl-Daniel Hailfinger)
Date: Thu, 06 Nov 2008 21:50:56 +0100
Subject: [coreboot] r983 - in coreboot-v3: device include/device
In-Reply-To: <49131873.60305@coresystems.de>
References: <20081105222854.3826gmx1@mx011.gmx.net>	<4912C898.8030602@gmx.net>	<97E3D99CC80D4C818B3DC1301229D37F@chimp>	<13426df10811060733x2af42783n95a639b8ea2cc1cf@mail.gmail.com>	<16D5B6D7218F46FB9E8CC379AFDA3D13@chimp>	<4727185d0811060749l543a8711v4b81c97c9e80abdf@mail.gmail.com>
	<49131873.60305@coresystems.de>
Message-ID: <491358B0.7040100@gmx.net>

On 06.11.2008 17:16, Stefan Reinauer wrote:
> Vincent Legoll wrote:
>   
>> Isn't all that kind of things doable via function pointers and link-time dead
>> code elimination ? That would achieve the no ifdeffery goal, and may be
>> cleaner code...
>>     
> Link time optimization would suggest we look into compiling with LLVM
> instead of gcc.
>
> Has anyone tried this, yet?
>   

I tested LLVM and the qemu target boots fine. However, the generated
code is ~30% bigger than gcc 4.2.1. According to some LLVM people, this
is due to the fact that nobody is working on making the generated code
small. Most people just want speed and don't care for code size.

And if we compile with -fwhole-program, gcc sizes go down even further.

Regards,
Carl-Daniel

-- 
http://www.hailfinger.org/




From svn at coreboot.org  Thu Nov  6 23:23:06 2008
From: svn at coreboot.org (svn at coreboot.org)
Date: Thu,  6 Nov 2008 23:23:06 +0100
Subject: [coreboot] r3732 - trunk/coreboot-v2/src/southbridge/intel/i82801gx
Message-ID: <mailman.2393.1355071426.16123.coreboot@coreboot.org>

Author: uwe
Date: 2008-11-06 23:23:05 +0100 (Thu, 06 Nov 2008)
New Revision: 3732

Modified:
   trunk/coreboot-v2/src/southbridge/intel/i82801gx/i82801gx_lpc.c
Log:
The enable_hpet() code in intel/i82801gx will not work with the
ICH7 southbridge (but it might work with ICH4/ICH5 or so).

The ICH7 needs a different init code. Drop the non-working code for now.

Signed-off-by: Uwe Hermann <uwe at hermann-uwe.de>
Acked-by: Stefan Reinauer <stepan at coresystems.de>



Modified: trunk/coreboot-v2/src/southbridge/intel/i82801gx/i82801gx_lpc.c
===================================================================
--- trunk/coreboot-v2/src/southbridge/intel/i82801gx/i82801gx_lpc.c	2008-11-05 22:54:36 UTC (rev 3731)
+++ trunk/coreboot-v2/src/southbridge/intel/i82801gx/i82801gx_lpc.c	2008-11-06 22:23:05 UTC (rev 3732)
@@ -194,22 +194,7 @@
 
 static void enable_hpet(struct device *dev)
 {
-	u32 reg32;
-	u32 code = (0 & 0x3);
-
-	reg32 = pci_read_config32(dev, GEN_CNTL);
-	reg32 |= (1 << 17);	/* Enable HPET. */
-	/*
-	 * Bits [16:15]	Memory Address Range
-	 * 00		FED0_0000h - FED0_03FFh
-	 * 01		FED0_1000h - FED0_13FFh
-	 * 10		FED0_2000h - FED0_23FFh
-	 * 11		FED0_3000h - FED0_33FFh
-	 */
-	reg32 &= ~(3 << 15);	/* Clear it */
-	reg32 |= (code << 15);
-	/* TODO: reg32 is never written to anywhere? */
-	printk_debug("Enabling HPET @0x%x\n", HPET_ADDR | (code << 12));
+	/* TODO */
 }
 
 static void i82801gx_lock_smm(struct device *dev)




From uwe at hermann-uwe.de  Thu Nov  6 23:23:31 2008
From: uwe at hermann-uwe.de (Uwe Hermann)
Date: Thu, 6 Nov 2008 23:23:31 +0100
Subject: [coreboot] [PATCH] v2: ICH7: Drop non-working enable_hpet()	for
	now
In-Reply-To: <491350EB.2040604@coresystems.de>
References: <20081031194315.GF18273@greenwood>
	<491350EB.2040604@coresystems.de>
Message-ID: <20081106222331.GB17232@greenwood>

On Thu, Nov 06, 2008 at 09:17:47PM +0100, Stefan Reinauer wrote:
> > Please correct me if I'm wrong (I don't have NDA'd Intel datasheets, I
> > can only check the public ones), but I think the enable_hpet() in the
> > ICH7 code will not work for ICH7. It should work for ICH4/ICH5 or so,
> > but ICH7 requires a completely different init involving RCBA, offset
> > 0x3404, it seems.
> >
> > Thus, drop the non-working code, add a TODO until somebody writes the
> > proper code for ICH7. Maybe I'll do that if nobody beats me to it, but
> > it may take a while.
> 
> Acked-by: Stefan Reinauer <stepan at coresystems.de>

Thanks, r3732.


Uwe.
-- 
http://www.hermann-uwe.de  | http://www.holsham-traders.de
http://www.crazy-hacks.org | http://www.unmaintained-free-software.org



From svn at coreboot.org  Thu Nov  6 23:24:06 2008
From: svn at coreboot.org (svn at coreboot.org)
Date: Thu,  6 Nov 2008 23:24:06 +0100
Subject: [coreboot] r3733 - trunk/coreboot-v2/src/southbridge/intel/i82801gx
Message-ID: <mailman.2394.1355071426.16123.coreboot@coreboot.org>

Author: uwe
Date: 2008-11-06 23:24:05 +0100 (Thu, 06 Nov 2008)
New Revision: 3733

Modified:
   trunk/coreboot-v2/src/southbridge/intel/i82801gx/i82801gx.h
Log:
Drop #defines for registers that are not existant on the ICH7.
Also, fix BIOS_CNTL, which is 0xdc on ICH7.

Build-tested with kontron/986lcd-m.

Signed-off-by: Uwe Hermann <uwe at hermann-uwe.de>
Acked-by: Stefan Reinauer <stepan at coresystems.de>



Modified: trunk/coreboot-v2/src/southbridge/intel/i82801gx/i82801gx.h
===================================================================
--- trunk/coreboot-v2/src/southbridge/intel/i82801gx/i82801gx.h	2008-11-06 22:23:05 UTC (rev 3732)
+++ trunk/coreboot-v2/src/southbridge/intel/i82801gx/i82801gx.h	2008-11-06 22:24:05 UTC (rev 3733)
@@ -24,18 +24,20 @@
 #include "chip.h"
 extern void i82801gx_enable(device_t dev);
 
-#define PCI_DMA_CFG		0x90
 #define SERIRQ_CNTL		0x64
-#define GEN_CNTL		0xd0
-#define GEN_STS			0xd4
-#define RTC_CONF		0xd8
+
 #define GEN_PMCON_1		0xa0
 #define GEN_PMCON_2		0xa2
 #define GEN_PMCON_3		0xa4
 
+/* GEN_PMCON_3 bits */
+#define RTC_BATTERY_DEAD	(1 << 2)
+#define RTC_POWER_FAILED	(1 << 1)
+#define SLEEP_AFTER_POWER_FAIL	(1 << 0)
+
 #define PMBASE			0x40
 #define ACPI_CNTL		0x44
-#define BIOS_CNTL		0x4E
+#define BIOS_CNTL		0xDC
 #define GPIO_BASE		0x48 /* LPC GPIO Base Address Register */
 #define GPIO_CNTL		0x4C /* LPC GPIO Control Register */
 
@@ -48,28 +50,10 @@
 #define PIRQG_ROUT		0x6A
 #define PIRQH_ROUT		0x6B
 
-#define FUNC_DIS		0xF2
-
 #define LPC_IO_DEC		0x80 /* IO Decode Ranges Register */
 #define LPC_EN			0x82 /* LPC IF Enables Register */
 
-#define SBUS_NUM		0x19
-#define SUB_BUS_NUM		0x1A
-#define SMLT			0x1B
-#define IOBASE			0x1C
-#define IOLIM			0x1D
-#define MEMBASE			0x20
-#define MEMLIM			0x22
-#define CNF			0x50
-#define MTT			0x70
-#define PCI_MAST_STS		0x82
-
-/* GEN_PMCON_3 bits */
-#define RTC_BATTERY_DEAD	(1 << 2)
-#define RTC_POWER_FAILED	(1 << 1)
-#define SLEEP_AFTER_POWER_FAIL	(1 << 0)
-
-/* PCI Configuration Space (D31:F1) */
+/* PCI Configuration Space (D31:F1): IDE */
 #define INTR_LN			0x3c
 #define IDE_TIM_PRI		0x40	/* IDE timings, primary */
 #define   IDE_DECODE_ENABLE	(1 << 15)
@@ -84,7 +68,7 @@
 #define   PCB1			(1 <<  1)
 #define   PCB0			(1 <<  0)
 
-/* PCI Configuration Space (D31:F3) */
+/* PCI Configuration Space (D31:F3): SMBus */
 #define SMB_BASE		0x20
 #define HOSTC			0x40
 




From uwe at hermann-uwe.de  Thu Nov  6 23:24:27 2008
From: uwe at hermann-uwe.de (Uwe Hermann)
Date: Thu, 6 Nov 2008 23:24:27 +0100
Subject: [coreboot] [PATCH] v2: ICH7: Drop/fix some ICH7
	register	#defines
In-Reply-To: <491350F9.6030401@coresystems.de>
References: <20081031210537.GH18273@greenwood>
	<491350F9.6030401@coresystems.de>
Message-ID: <20081106222427.GC17232@greenwood>

On Thu, Nov 06, 2008 at 09:18:01PM +0100, Stefan Reinauer wrote:
> > This patch will fail to compile without my other patch to drop/disable
> > the non-working enable_hpet() function in ICH7.
> >   
> Acked-by: Stefan Reinauer <stepan at coresystems.de>

Thanks, r3733.


Uwe.
-- 
http://www.hermann-uwe.de  | http://www.holsham-traders.de
http://www.crazy-hacks.org | http://www.unmaintained-free-software.org



From uwe at hermann-uwe.de  Thu Nov  6 23:29:39 2008
From: uwe at hermann-uwe.de (Uwe Hermann)
Date: Thu, 6 Nov 2008 23:29:39 +0100
Subject: [coreboot] ubuntu help!
In-Reply-To: <13426df10811061111x3990fed3q4170f5226824b39a@mail.gmail.com>
References: <13426df10811060816sc4c5e25oc81983bc530abeb0@mail.gmail.com>
	<49133EED.1090304@zl2tod.net>
	<13426df10811061111x3990fed3q4170f5226824b39a@mail.gmail.com>
Message-ID: <20081106222938.GA13325@greenwood>

On Thu, Nov 06, 2008 at 11:11:30AM -0800, ron minnich wrote:
> > Where did that script to collect hardware information end up? I spent some
> > time looking for it but failed to turn it up.

Please make sure that only people who are actually willing and able to
work on coreboot (programming) or at least willing and able to _test_
patches we may provide (on their hardware) post such information.

Not to discourage this effort, but simply dumping a lot of lspci's on
the mailing list will not help at all. Somebody has to actually do the
work and/or test patches, otherwise the information is useless.


Thanks, Uwe.
-- 
http://www.hermann-uwe.de  | http://www.holsham-traders.de
http://www.crazy-hacks.org | http://www.unmaintained-free-software.org



From svn at coreboot.org  Thu Nov  6 23:38:31 2008
From: svn at coreboot.org (svn at coreboot.org)
Date: Thu,  6 Nov 2008 23:38:31 +0100
Subject: [coreboot] r3734 - in trunk/coreboot-v2:
	src/mainboard/lippert/spacerunner-lx targets/lippert/spacerunner-lx
Message-ID: <mailman.2395.1355071426.16123.coreboot@coreboot.org>

Author: uwe
Date: 2008-11-06 23:38:31 +0100 (Thu, 06 Nov 2008)
New Revision: 3734

Modified:
   trunk/coreboot-v2/src/mainboard/lippert/spacerunner-lx/Config.lb
   trunk/coreboot-v2/src/mainboard/lippert/spacerunner-lx/Options.lb
   trunk/coreboot-v2/src/mainboard/lippert/spacerunner-lx/cache_as_ram_auto.c
   trunk/coreboot-v2/src/mainboard/lippert/spacerunner-lx/chip.h
   trunk/coreboot-v2/src/mainboard/lippert/spacerunner-lx/irq_tables.c
   trunk/coreboot-v2/src/mainboard/lippert/spacerunner-lx/mainboard.c
   trunk/coreboot-v2/targets/lippert/spacerunner-lx/Config.lb
Log:
Re-add "based on" lines.

Signed-off-by: Uwe Hermann <uwe at hermann-uwe.de>
Acked-by: Jens Rottmann <JRottmann at LiPPERTEmbedded.de>



Modified: trunk/coreboot-v2/src/mainboard/lippert/spacerunner-lx/Config.lb
===================================================================
--- trunk/coreboot-v2/src/mainboard/lippert/spacerunner-lx/Config.lb	2008-11-06 22:24:05 UTC (rev 3733)
+++ trunk/coreboot-v2/src/mainboard/lippert/spacerunner-lx/Config.lb	2008-11-06 22:38:31 UTC (rev 3734)
@@ -18,6 +18,8 @@
 ## Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA  02110-1301 USA
 ##
 
+## Based on Config.lb from AMD's DB800 and DBM690T mainboards.
+
 ##
 ## Compute the location and size of where this firmware image
 ## (coreboot plus bootloader) will live in the boot rom chip.

Modified: trunk/coreboot-v2/src/mainboard/lippert/spacerunner-lx/Options.lb
===================================================================
--- trunk/coreboot-v2/src/mainboard/lippert/spacerunner-lx/Options.lb	2008-11-06 22:24:05 UTC (rev 3733)
+++ trunk/coreboot-v2/src/mainboard/lippert/spacerunner-lx/Options.lb	2008-11-06 22:38:31 UTC (rev 3734)
@@ -18,6 +18,8 @@
 ## Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA  02110-1301 USA
 ##
 
+## Based on Options.lb from AMD's DB800 mainboard.
+
 uses HAVE_MP_TABLE
 uses HAVE_PIRQ_TABLE
 uses USE_FALLBACK_IMAGE

Modified: trunk/coreboot-v2/src/mainboard/lippert/spacerunner-lx/cache_as_ram_auto.c
===================================================================
--- trunk/coreboot-v2/src/mainboard/lippert/spacerunner-lx/cache_as_ram_auto.c	2008-11-06 22:24:05 UTC (rev 3733)
+++ trunk/coreboot-v2/src/mainboard/lippert/spacerunner-lx/cache_as_ram_auto.c	2008-11-06 22:38:31 UTC (rev 3734)
@@ -19,6 +19,8 @@
  * Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA  02110-1301 USA
  */
 
+/* Based on cache_as_ram_auto.c from AMD's DB800 and DBM690T mainboards. */
+
 #define ASSEMBLY 1
 
 #include <stdlib.h>

Modified: trunk/coreboot-v2/src/mainboard/lippert/spacerunner-lx/chip.h
===================================================================
--- trunk/coreboot-v2/src/mainboard/lippert/spacerunner-lx/chip.h	2008-11-06 22:24:05 UTC (rev 3733)
+++ trunk/coreboot-v2/src/mainboard/lippert/spacerunner-lx/chip.h	2008-11-06 22:38:31 UTC (rev 3734)
@@ -18,6 +18,8 @@
  * Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA  02110-1301 USA
  */
 
+/* Based on chip.h from AMD's DB800 mainboard. */
+
 #include <stdint.h>
 
 extern struct chip_operations mainboard_lippert_spacerunner_lx_ops;

Modified: trunk/coreboot-v2/src/mainboard/lippert/spacerunner-lx/irq_tables.c
===================================================================
--- trunk/coreboot-v2/src/mainboard/lippert/spacerunner-lx/irq_tables.c	2008-11-06 22:24:05 UTC (rev 3733)
+++ trunk/coreboot-v2/src/mainboard/lippert/spacerunner-lx/irq_tables.c	2008-11-06 22:38:31 UTC (rev 3734)
@@ -18,6 +18,8 @@
  * Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA  02110-1301 USA
  */
 
+/* Based on irq_tables.c from AMD's DB800 mainboard. */
+
 #include <arch/pirq_routing.h>
 #include <console/console.h>
 #include <arch/io.h>

Modified: trunk/coreboot-v2/src/mainboard/lippert/spacerunner-lx/mainboard.c
===================================================================
--- trunk/coreboot-v2/src/mainboard/lippert/spacerunner-lx/mainboard.c	2008-11-06 22:24:05 UTC (rev 3733)
+++ trunk/coreboot-v2/src/mainboard/lippert/spacerunner-lx/mainboard.c	2008-11-06 22:38:31 UTC (rev 3734)
@@ -18,6 +18,8 @@
  * Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA  02110-1301 USA
  */
 
+/* Based on mainboard.c from AMD's DB800 mainboard. */
+
 #include <stdlib.h>
 #include <stdint.h>
 #include <console/console.h>

Modified: trunk/coreboot-v2/targets/lippert/spacerunner-lx/Config.lb
===================================================================
--- trunk/coreboot-v2/targets/lippert/spacerunner-lx/Config.lb	2008-11-06 22:24:05 UTC (rev 3733)
+++ trunk/coreboot-v2/targets/lippert/spacerunner-lx/Config.lb	2008-11-06 22:38:31 UTC (rev 3734)
@@ -18,6 +18,8 @@
 ## Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA  02110-1301 USA
 ##
 
+## Based on Config.lb for the AMD Geode LX/5536 DB800 platform.
+
 # Config file for the LiPPERT Cool SpaceRunner-LX.		--JR 10/2008
 
 target spacerunner-lx




From uwe at hermann-uwe.de  Thu Nov  6 23:39:16 2008
From: uwe at hermann-uwe.de (Uwe Hermann)
Date: Thu, 6 Nov 2008 23:39:16 +0100
Subject: [coreboot] new board: LiPPERT Cool SpaceRunner-LX
In-Reply-To: <4911B084.7010101@LiPPERTEmbedded.de>
References: <48FDDF4C.3080601@LiPPERTEmbedded.de>
	<20081022160617.GI15706@greenwood>
	<4909EBDA.6010008@LiPPERTEmbedded.de>
	<20081030194447.GB28905@greenwood>
	<490EFCF2.2060708@LiPPERTEmbedded.de>
	<20081103160149.GC21829@cosmic.amd.com>
	<20081104004415.GA23206@greenwood>
	<4911B084.7010101@LiPPERTEmbedded.de>
Message-ID: <20081106223916.GB13325@greenwood>

On Wed, Nov 05, 2008 at 03:41:08PM +0100, Jens Rottmann wrote:
> About the "Based on" thing:
> 
> Here I fully agree with Jordan. I never meant to have several "Based on"
> lines appended in one file. I only wanted to show the direct ancestor,
> so e.g. someone could make a diff and see what parts are really
> SpaceRunner-LX specific and what parts are generic.
> If this ancestor had a "Based on" by itself, it might take several steps
> to e.g. trace a bug to the board where it was introduced, but that's ok.
> And then you could chase down all other boards that might have inherited
> this bug ...
> 
> "v2_lippert_based_on.patch"
> Acked-by: Jens Rottmann <JRottmann at LiPPERTEmbedded.de>

OK then, committed in r3734.


Thanks, Uwe.
-- 
http://www.hermann-uwe.de  | http://www.holsham-traders.de
http://www.crazy-hacks.org | http://www.unmaintained-free-software.org



From info at coresystems.de  Thu Nov  6 23:39:35 2008
From: info at coresystems.de (coreboot information)
Date: Thu, 06 Nov 2008 23:39:35 +0100
Subject: [coreboot] r3732 build service
Message-ID: <E1KyDVn-0006vJ-1K@ra.coresystems.de>

Dear coreboot readers!

This is the automated build check service of coreboot.

The developer "uwe" checked in revision 3732 to
the coreboot source repository and caused the following 
changes:

Change Log:
The enable_hpet() code in intel/i82801gx will not work with the
ICH7 southbridge (but it might work with ICH4/ICH5 or so).

The ICH7 needs a different init code. Drop the non-working code for now.

Signed-off-by: Uwe Hermann <uwe at hermann-uwe.de>
Acked-by: Stefan Reinauer <stepan at coresystems.de>



Build Log:
Compilation of sunw:ultra40 has been broken
See the error log at http://qa.coreboot.org/log_buildbrd.php?revision=3732&device=ultra40&vendor=sunw
Compilation of tyan:s2885 has been fixed


If something broke during this checkin please be a pain 
in uwe's neck until the issue is fixed.

If this issue is not fixed within 24h the revision should 
be backed out.

   Best regards,
     coreboot automatic build system





From uwe at hermann-uwe.de  Thu Nov  6 23:46:36 2008
From: uwe at hermann-uwe.de (Uwe Hermann)
Date: Thu, 6 Nov 2008 23:46:36 +0100
Subject: [coreboot] [PATCH] v3: s/BIOS_DEBUG/DEBUG/ etc. for printk()
In-Reply-To: <20081025110559.GA8137@greenwood>
References: <20081023193901.GA14982@greenwood>
	<20081024013120.8096.qmail@stuge.se>
	<20081025110559.GA8137@greenwood>
Message-ID: <20081106224636.GC13325@greenwood>

On Sat, Oct 25, 2008 at 01:05:59PM +0200, Uwe Hermann wrote:
> On Fri, Oct 24, 2008 at 03:31:20AM +0200, Peter Stuge wrote:
> > Uwe Hermann wrote:
> > > Drop the 'BIOS_' prefix from all printk() log-levels.
> > 
> > It would be nice to have another prefix though. Maybe LOG_ ? Without
> > a prefix some of the names look a bit too generic.
> 
> I've though about that, but I don't see it as a big problem. Only
> "DEBUG" tends to be misused in v2, but we can easily avoid that by
> using DEBUG_SMBUS, DEBUG_FOOBAR #defines in v3 (if at all; all of
> those custom DEBUG #defines should be printk()-loglevels anyway;
> I think the reason for DEBUG in v2 is usually romcc/size rel?ted(?))
> 
> If we all desperately want a prefix, how about something really short,
> e.g. LDEBUG, LWARN, LINFO, ... ? I'd really like to keep the printk()
> lines as short as possible for readability reasons.

*ping*

Other opinions on this patch? Acks? ;) What does everyone think
of LDEBUG, LINFO etc.?


Uwe.
-- 
http://www.hermann-uwe.de  | http://www.holsham-traders.de
http://www.crazy-hacks.org | http://www.unmaintained-free-software.org



From uwe at hermann-uwe.de  Thu Nov  6 23:49:30 2008
From: uwe at hermann-uwe.de (Uwe Hermann)
Date: Thu, 6 Nov 2008 23:49:30 +0100
Subject: [coreboot] coreboot bios
In-Reply-To: <339287.28366.qm@web32007.mail.mud.yahoo.com>
References: <339287.28366.qm@web32007.mail.mud.yahoo.com>
Message-ID: <20081106224930.GD13325@greenwood>

On Tue, Oct 28, 2008 at 02:39:48AM -0700, Parts & Repair wrote:
> Is there a Coreboot bios for the TP 600x?

No, there's currently no such support, because this is a laptop and
those are not yet supported by coreboot at all. This is due to technical
reasons, for instance most laptops have a so-called "embedded
controller" which needs to be supported and which is usually
undocumented.


> Northbridge??? ??? Intel i440BX/ZX rev. C1 
> 
> Mainboard Model??? ??? 26454EU (0x19F - 0x44C0F5) 
> 
> 
> Name??? ??? ??? Intel Pentium III E
> Codename??? ??? Coppermine
> Specification??? ??? 
> Package??? ??? ??? MMC (platform ID = 3h)
> CPUID??? ??? ??? 6.8.1 
> 
> 
> 
> 
> root at darkstar:/# lspci
> 00:00.0 Host bridge: Intel Corporation 440BX/ZX/DX - 82443BX/ZX/DX Host bridge (rev 03)
> 00:01.0 PCI bridge: Intel Corporation 440BX/ZX/DX - 82443BX/ZX/DX AGP bridge (rev 03)
> 00:02.0 CardBus bridge: Texas Instruments PCI1450 (rev 03)
> 00:02.1 CardBus bridge: Texas Instruments PCI1450 (rev 03)
> 00:03.0 Communication controller: Agere Systems WinModem 56k (rev 01)
> 00:06.0 Multimedia audio controller: Cirrus Logic CS 4614/22/24/30 [CrystalClear SoundFusion Audio Accelerator] (rev 01)
> 00:07.0 Bridge: Intel Corporation 82371AB/EB/MB PIIX4 ISA (rev 02)

440BX + 82371AB are more or less supported per se (with several TODOs
still missing though), but unfortunately this is a laptop, so currently
not an option.


> 00:07.1 IDE interface: Intel Corporation 82371AB/EB/MB PIIX4 IDE (rev 01)
> 00:07.2 USB Controller: Intel Corporation 82371AB/EB/MB PIIX4 USB (rev 01)
> 00:07.3 Bridge: Intel Corporation 82371AB/EB/MB PIIX4 ACPI (rev 03)
> 01:00.0 VGA compatible controller: Neomagic Corporation NM2360 [MagicMedia 256ZX]
> 06:00.0 Ethernet controller: Atheros Communications Inc. AR2413 802.11bg NIC (rev 01) 


Uwe.
-- 
http://www.hermann-uwe.de  | http://www.holsham-traders.de
http://www.crazy-hacks.org | http://www.unmaintained-free-software.org



From rminnich at gmail.com  Thu Nov  6 23:56:59 2008
From: rminnich at gmail.com (ron minnich)
Date: Thu, 6 Nov 2008 14:56:59 -0800
Subject: [coreboot] [PATCH] v3: s/BIOS_DEBUG/DEBUG/ etc. for printk()
In-Reply-To: <20081106224636.GC13325@greenwood>
References: <20081023193901.GA14982@greenwood>
	<20081024013120.8096.qmail@stuge.se> <20081025110559.GA8137@greenwood>
	<20081106224636.GC13325@greenwood>
Message-ID: <13426df10811061456o6934d2c4t23d3c3dea297bfb4@mail.gmail.com>

On Thu, Nov 6, 2008 at 2:46 PM, Uwe Hermann <uwe at hermann-uwe.de> wrote:

> *ping*
>
> Other opinions on this patch? Acks? ;) What does everyone think
> of LDEBUG, LINFO etc.?
>

you should get agreement from someone else, but removing the name
BIOS_ is ok by me, if only because it gets rid of BIOS.

Prefix is fine too: L is perfectly ok to me.

But I'm easy.


ron



From c-d.hailfinger.devel.2006 at gmx.net  Thu Nov  6 23:58:01 2008
From: c-d.hailfinger.devel.2006 at gmx.net (Carl-Daniel Hailfinger)
Date: Thu, 06 Nov 2008 23:58:01 +0100
Subject: [coreboot] [PATCH] v3: s/BIOS_DEBUG/DEBUG/ etc. for printk()
In-Reply-To: <20081025110559.GA8137@greenwood>
References: <20081023193901.GA14982@greenwood>	<20081024013120.8096.qmail@stuge.se>
	<20081025110559.GA8137@greenwood>
Message-ID: <49137679.70003@gmx.net>

On 25.10.2008 13:05, Uwe Hermann wrote:
> On Fri, Oct 24, 2008 at 03:31:20AM +0200, Peter Stuge wrote:
>   
>> Uwe Hermann wrote:
>>     
>>> Drop the 'BIOS_' prefix from all printk() log-levels.
>>>       
>> It would be nice to have another prefix though. Maybe LOG_ ? Without
>> a prefix some of the names look a bit too generic.
>>     
>
> I've though about that, but I don't see it as a big problem. Only
> "DEBUG" tends to be misused in v2, but we can easily avoid that by
> using DEBUG_SMBUS, DEBUG_FOOBAR #defines in v3 (if at all; all of
> those custom DEBUG #defines should be printk()-loglevels anyway;
> I think the reason for DEBUG in v2 is usually romcc/size rel?ted(?))
>
> If we all desperately want a prefix, how about something really short,
> e.g. LDEBUG, LWARN, LINFO, ... ? I'd really like to keep the printk()
> lines as short as possible for readability reasons.
>   

Can't we just keep the names as they are?

Regards,
Carl-Daniel

-- 
http://www.hailfinger.org/




From info at coresystems.de  Fri Nov  7 00:00:36 2008
From: info at coresystems.de (coreboot information)
Date: Fri, 07 Nov 2008 00:00:36 +0100
Subject: [coreboot] r3733 build service
Message-ID: <E1KyDq8-0000th-8Q@ra.coresystems.de>

Dear coreboot readers!

This is the automated build check service of coreboot.

The developer "uwe" checked in revision 3733 to
the coreboot source repository and caused the following 
changes:

Change Log:
Drop #defines for registers that are not existant on the ICH7.
Also, fix BIOS_CNTL, which is 0xdc on ICH7.

Build-tested with kontron/986lcd-m.

Signed-off-by: Uwe Hermann <uwe at hermann-uwe.de>
Acked-by: Stefan Reinauer <stepan at coresystems.de>



Build Log:
Compilation of sunw:ultra40 has been fixed


If something broke during this checkin please be a pain 
in uwe's neck until the issue is fixed.

If this issue is not fixed within 24h the revision should 
be backed out.

   Best regards,
     coreboot automatic build system





From uwe at hermann-uwe.de  Fri Nov  7 00:07:38 2008
From: uwe at hermann-uwe.de (Uwe Hermann)
Date: Fri, 7 Nov 2008 00:07:38 +0100
Subject: [coreboot] filo fails to compile
In-Reply-To: <20081105161205.GC23167@cosmic.amd.com>
References: <dd3c80060811042339k7face039idb0fa203f19b3da3@mail.gmail.com>
	<20081105093736.GC13674@greenwood>
	<20081105161205.GC23167@cosmic.amd.com>
Message-ID: <20081106230738.GE13325@greenwood>

On Wed, Nov 05, 2008 at 09:12:05AM -0700, Jordan Crouse wrote:
> On 05/11/08 10:37 +0100, Uwe Hermann wrote:
> > On Wed, Nov 05, 2008 at 02:39:11AM -0500, Corey Osgood wrote:
> > > Build host is Ubuntu 8.04.1, gcc 4.2.4 (Ubuntu 4.2.4-1ubuntu3). I followed
> > > the steps at coreboot.org/Filo, console output below. build.sh seems to work
> > > fine.
> > 
> > The wiki needed a small fix (done).
> > 
> > After typing 'make' in libpayload, you have to also do:
> > 
> >   $ make DESTDIR=../build install
> > 
> > The rest of the instructions will then work fine.
> 
> You could also set LIBPAYLOAD_PREFIX=./libpayload.

Yes, but that won't work in the current form of libpayload, as it's
config.h collides with FILO's config.h (it's not a problem if you
do the 'make DESTDIR=../build install' as that renames libpayload's
config.h to libpayload-config.h. We could of course change that...


Uwe.
-- 
http://www.hermann-uwe.de  | http://www.holsham-traders.de
http://www.crazy-hacks.org | http://www.unmaintained-free-software.org



From joe at settoplinux.org  Fri Nov  7 00:08:45 2008
From: joe at settoplinux.org (Joseph Smith)
Date: Thu, 06 Nov 2008 18:08:45 -0500
Subject: [coreboot] fixing i810 onboard vga
In-Reply-To: <e19d85410811061038x5e9f054ft4ec3b1b93efd029e@mail.gmail.com>
References: <e19d85410811061038x5e9f054ft4ec3b1b93efd029e@mail.gmail.com>
Message-ID: <55ef48fb3f569a3424087cb7ba0852d5@imap.1and1.com>




On Thu, 6 Nov 2008 20:38:31 +0200, "Elia Yehuda" <z4ziggy at gmail.com> wrote:
> Hey all,
> 
> im working at the on the i810, trying to fix the onboard-vga to work.
> 
> removing the commented code of the vga-related stuff resulted with the
pci
> device to be displayed in the pci list on coreboot, but in a disabled
> state,
> and (as promised...) with the boot not executing the payload. complete
log
> can be shown here : http://pastebin.com/m20e821eb
> 
> a few rough patches to my target and i82810/raminit.c and now the device
> is
> shown as enabled and i even get the information about the VGA allocating
> resources :
> 
> Allocating VGA resource PCI: 00:01.0
> Setting PCI_BRIDGE_CTL_VGA for bridge PCI_DOMAIN: 0000
> Setting PCI_BRIDGE_CTL_VGA for bridge Root Device
> 
> but the payload still wont execute (it is seems to be loaded though) and
> ofcourse, no VGA output, only serial, with a dead boot hanging...
> complete log can be shown here : http://pastebin.com/m248a41ea
> 
I had this problem on the i830. You need to allocate vga memory for the
onboard vga (northbridge.c if I remember correctly). The vga memory should
be allocated to the TOM. So your total system memory actually equals
phisical memory - vga memory. It should be close to the i830, take a look
at that and compare it to the i810 datasheet. Hope that helps.

-- 
Thanks,
Joseph Smith
Set-Top-Linux
www.settoplinux.org




From rminnich at gmail.com  Fri Nov  7 00:11:30 2008
From: rminnich at gmail.com (ron minnich)
Date: Thu, 6 Nov 2008 15:11:30 -0800
Subject: [coreboot] [PATCH] v3: s/BIOS_DEBUG/DEBUG/ etc. for printk()
In-Reply-To: <49137679.70003@gmx.net>
References: <20081023193901.GA14982@greenwood>
	<20081024013120.8096.qmail@stuge.se> <20081025110559.GA8137@greenwood>
	<49137679.70003@gmx.net>
Message-ID: <13426df10811061511x134d41a0p5df986ea630c00a3@mail.gmail.com>

On Thu, Nov 6, 2008 at 2:58 PM, Carl-Daniel Hailfinger
<c-d.hailfinger.devel.2006 at gmx.net> wrote:
> On 25.10.2008 13:05, Uwe Hermann wrote:
>> On Fri, Oct 24, 2008 at 03:31:20AM +0200, Peter Stuge wrote:
>>
>>> Uwe Hermann wrote:
>>>
>>>> Drop the 'BIOS_' prefix from all printk() log-levels.
>>>>
>>> It would be nice to have another prefix though. Maybe LOG_ ? Without
>>> a prefix some of the names look a bit too generic.
>>>
>>
>> I've though about that, but I don't see it as a big problem. Only
>> "DEBUG" tends to be misused in v2, but we can easily avoid that by
>> using DEBUG_SMBUS, DEBUG_FOOBAR #defines in v3 (if at all; all of
>> those custom DEBUG #defines should be printk()-loglevels anyway;
>> I think the reason for DEBUG in v2 is usually romcc/size rel?ted(?))
>>
>> If we all desperately want a prefix, how about something really short,
>> e.g. LDEBUG, LWARN, LINFO, ... ? I'd really like to keep the printk()
>> lines as short as possible for readability reasons.
>>
>
> Can't we just keep the names as they are?
>


I think the majority prefer that they not change ...

ron



From peter at stuge.se  Fri Nov  7 00:29:45 2008
From: peter at stuge.se (Peter Stuge)
Date: Fri, 7 Nov 2008 00:29:45 +0100
Subject: [coreboot] [PATCH] v3: s/BIOS_DEBUG/DEBUG/ etc. for printk()
In-Reply-To: <20081106224636.GC13325@greenwood>
References: <20081023193901.GA14982@greenwood>
	<20081024013120.8096.qmail@stuge.se>
	<20081025110559.GA8137@greenwood>
	<20081106224636.GC13325@greenwood>
Message-ID: <20081106232945.8018.qmail@stuge.se>

Uwe Hermann wrote:
> Other opinions on this patch? Acks? ;)
> What does everyone think of LDEBUG, LINFO etc.?

I will ack a change to LOG_DEBUG, LOG_INFO etc.


//Peter



From joe at settoplinux.org  Fri Nov  7 00:32:58 2008
From: joe at settoplinux.org (Joseph Smith)
Date: Thu, 06 Nov 2008 18:32:58 -0500
Subject: [coreboot] Homemaid LPC flasher
Message-ID: <8e37ed8e264328e3876c92411a4b5493@imap.1and1.com>


Hello everyone. Sorry for the quietness lately, I have been out straight at
work implimenting a new tape library project (BRMS for those of you that
know AS400's). Kind of cool working with LTO4's (1 1/2 terabites) and a
tape library that can hold 110 LTO4's (IBM TS3310).

Anyways, I am going to start a project based on a very simple and CHEAP LPC
flasher originally designed for the xbox.
http://rex.xbox-scene.com/LPC2/LPC2.html
I have a friend that has already tested this on fwh hubs (SST49LF008A to be
exact) and it worked great.
I have placed an order so the parts should be arriving soon. The downside
is the software is only for dos/win, but the software source code is also
available on the site. I think it would be pretty easy to convert it to
Linux. I am trying to get a hold of the original author for permission to
release it under a GPL.

My question to the coreboot community is?..
I have no problem hosting this project on my site, but would everyone like
me to incorporate this project into coreboot? If so is anyone interested in
helping?


By the way Stefan great work on the i945!!
Those Intel doors are starting to slowly creep open...

--
Thanks,
Joseph Smith
Set-Top-Linux
www.settoplinux.org
-- 
Thanks,
Joseph Smith
Set-Top-Linux
www.settoplinux.org




From c-d.hailfinger.devel.2006 at gmx.net  Fri Nov  7 00:48:02 2008
From: c-d.hailfinger.devel.2006 at gmx.net (Carl-Daniel Hailfinger)
Date: Fri, 07 Nov 2008 00:48:02 +0100
Subject: [coreboot] Homemaid LPC flasher
In-Reply-To: <8e37ed8e264328e3876c92411a4b5493@imap.1and1.com>
References: <8e37ed8e264328e3876c92411a4b5493@imap.1and1.com>
Message-ID: <49138232.4060402@gmx.net>

On 07.11.2008 00:32, Joseph Smith wrote:
> Hello everyone. Sorry for the quietness lately, I have been out straight at
> work implimenting a new tape library project (BRMS for those of you that
> know AS400's). Kind of cool working with LTO4's (1 1/2 terabites) and a
> tape library that can hold 110 LTO4's (IBM TS3310).
>
> Anyways, I am going to start a project based on a very simple and CHEAP LPC
> flasher originally designed for the xbox.
> http://rex.xbox-scene.com/LPC2/LPC2.html
> I have a friend that has already tested this on fwh hubs (SST49LF008A to be
> exact) and it worked great.
> I have placed an order so the parts should be arriving soon. The downside
> is the software is only for dos/win, but the software source code is also
> available on the site. I think it would be pretty easy to convert it to
> Linux. I am trying to get a hold of the original author for permission to
> release it under a GPL.
>
> My question to the coreboot community is?..
> I have no problem hosting this project on my site, but would everyone like
> me to incorporate this project into coreboot? If so is anyone interested in
> helping?
>   

Do we want to add support for this flasher to flashrom? In theory,
reusing the abstraction model present since SPI could work well.

Regards,
Carl-Daniel

-- 
http://www.hailfinger.org/




From rminnich at gmail.com  Fri Nov  7 00:53:02 2008
From: rminnich at gmail.com (ron minnich)
Date: Thu, 6 Nov 2008 15:53:02 -0800
Subject: [coreboot] Homemaid LPC flasher
In-Reply-To: <49138232.4060402@gmx.net>
References: <8e37ed8e264328e3876c92411a4b5493@imap.1and1.com>
	<49138232.4060402@gmx.net>
Message-ID: <13426df10811061553h7022e45bnf0b0fc69fb7609d9@mail.gmail.com>

I would be really happy to see this project associated with coreboot.

yes, stefan's work on the i945 was really groundbreaking.

ron



From joe at settoplinux.org  Fri Nov  7 01:04:05 2008
From: joe at settoplinux.org (Joseph Smith)
Date: Thu, 06 Nov 2008 19:04:05 -0500
Subject: [coreboot] Homemaid LPC flasher
In-Reply-To: <49138232.4060402@gmx.net>
References: <8e37ed8e264328e3876c92411a4b5493@imap.1and1.com>
	<49138232.4060402@gmx.net>
Message-ID: <98aab1b0790608659df959b321b0df21@imap.1and1.com>




On Fri, 07 Nov 2008 00:48:02 +0100, Carl-Daniel Hailfinger
<c-d.hailfinger.devel.2006 at gmx.net> wrote:
>>
>> Anyways, I am going to start a project based on a very simple and CHEAP
> LPC
>> flasher originally designed for the xbox.
>> http://rex.xbox-scene.com/LPC2/LPC2.html
>> I have a friend that has already tested this on fwh hubs (SST49LF008A to
> be
>> exact) and it worked great.
>> I have placed an order so the parts should be arriving soon. The
> downside
>> is the software is only for dos/win, but the software source code is
> also
>> available on the site. I think it would be pretty easy to convert it to
>> Linux. I am trying to get a hold of the original author for permission
> to
>> release it under a GPL.
>>
>> My question to the coreboot community is?..
>> I have no problem hosting this project on my site, but would everyone
> like
>> me to incorporate this project into coreboot? If so is anyone interested
> in
>> helping?
>>
> 
> Do we want to add support for this flasher to flashrom? In theory,
> reusing the abstraction model present since SPI could work well.
> 
flashrom support would be very very cool :-)
The ability of flashrom flashing over LPC would greatly broaden it
horizons.
After I get it up and working, I also am going to do some testing with USB
to LPC adapters for those of you that don't have a LPC port. These adapters
can be found on eBay for pennies on the dollar (very cheap). I also plan on
powering the LPC flasher from USB.

-- 
Thanks,
Joseph Smith
Set-Top-Linux
www.settoplinux.org




From c-d.hailfinger.devel.2006 at gmx.net  Fri Nov  7 01:06:05 2008
From: c-d.hailfinger.devel.2006 at gmx.net (Carl-Daniel Hailfinger)
Date: Fri, 07 Nov 2008 01:06:05 +0100
Subject: [coreboot] r983 - in coreboot-v3: device include/device
In-Reply-To: <97E3D99CC80D4C818B3DC1301229D37F@chimp>
References: <20081105222854.3826gmx1@mx011.gmx.net> <4912C898.8030602@gmx.net>
	<97E3D99CC80D4C818B3DC1301229D37F@chimp>
Message-ID: <4913866D.7000803@gmx.net>

On 06.11.2008 14:26, Myles Watson wrote:
>   
>> -----Original Message-----
>> From: Carl-Daniel Hailfinger [mailto:c-d.hailfinger.devel.2006 at gmx.net]
>> Sent: Thursday, November 06, 2008 3:36 AM
>> To: coreboot at coreboot.org; Myles Watson; ron minnich
>> Subject: Re: [coreboot] r983 - in coreboot-v3: device include/device
>>
>> Hi Myles,
>>
>> I'm sorry I didn't have time to review your patch a bit sooner.
>> AFAICS it introduced a few bugs regarding conditional compilation.
>> Review follows.
>>
>>     
>
> Whoa.  You're right.  I guess it's the same as it was, since it was never
> compiled in before either.
>
> It brings up the interesting question of how this should work, since if you
> try to compile in that support it breaks because it can't find the default
> ops structures.
>   

I believe that's why the original code had this:

/* We should move these so they're really config options */
#define CONFIG_HYPERTRANSPORT_PLUGIN_SUPPORT 0
#define CONFIG_PCIX_PLUGIN_SUPPORT 0
#define CONFIG_PCIE_PLUGIN_SUPPORT 0
#define CONFIG_CARDBUS_PLUGIN_SUPPORT 0
#define CONFIG_AGP_PLUGIN_SUPPORT 0


Had these been made real config options instead of being dropped,
everything should have worked.



> Should there be a table of default ops somewhere?  How do we compile in
> support for plug ins?
>   

See above.

Regards,
Carl-Daniel

-- 
http://www.hailfinger.org/




From stepan at coresystems.de  Fri Nov  7 01:06:19 2008
From: stepan at coresystems.de (Stefan Reinauer)
Date: Fri, 07 Nov 2008 01:06:19 +0100
Subject: [coreboot] [PATCH] v3: s/BIOS_DEBUG/DEBUG/ etc. for printk()
In-Reply-To: <13426df10811061511x134d41a0p5df986ea630c00a3@mail.gmail.com>
References: <20081023193901.GA14982@greenwood>	<20081024013120.8096.qmail@stuge.se>
	<20081025110559.GA8137@greenwood>	<49137679.70003@gmx.net>
	<13426df10811061511x134d41a0p5df986ea630c00a3@mail.gmail.com>
Message-ID: <4913867B.8060706@coresystems.de>

ron minnich schrieb:
> On Thu, Nov 6, 2008 at 2:58 PM, Carl-Daniel Hailfinger
> <c-d.hailfinger.devel.2006 at gmx.net> wrote:
>   
>> On 25.10.2008 13:05, Uwe Hermann wrote:
>>     
>>> On Fri, Oct 24, 2008 at 03:31:20AM +0200, Peter Stuge wrote:
>>>
>>>       
>>>> Uwe Hermann wrote:
>>>>
>>>>         
>>>>> Drop the 'BIOS_' prefix from all printk() log-levels.
>>>>>
>>>>>           
>>>> It would be nice to have another prefix though. Maybe LOG_ ? Without
>>>> a prefix some of the names look a bit too generic.
>>>>
>>>>         
>>> I've though about that, but I don't see it as a big problem. Only
>>> "DEBUG" tends to be misused in v2, but we can easily avoid that by
>>> using DEBUG_SMBUS, DEBUG_FOOBAR #defines in v3 (if at all; all of
>>> those custom DEBUG #defines should be printk()-loglevels anyway;
>>> I think the reason for DEBUG in v2 is usually romcc/size rel?ted(?))
>>>
>>> If we all desperately want a prefix, how about something really short,
>>> e.g. LDEBUG, LWARN, LINFO, ... ? I'd really like to keep the printk()
>>> lines as short as possible for readability reasons.
>>>
>>>       
>> Can't we just keep the names as they are?
>>
>>     
>
>
> I think the majority prefer that they not change ...
>   
Add me to that majority. I think those names are good as they are.

Please don't change such stuff just for the sake of it.

a) it really does not matter
b) don't make it longer than it is
c) keep it comprehensible.


If you want to change something, I suggest you think about whether we 
can get rid of some of the levels.



From rminnich at gmail.com  Fri Nov  7 01:07:17 2008
From: rminnich at gmail.com (ron minnich)
Date: Thu, 6 Nov 2008 16:07:17 -0800
Subject: [coreboot] [PATCH] v3: s/BIOS_DEBUG/DEBUG/ etc. for printk()
In-Reply-To: <4913867B.8060706@coresystems.de>
References: <20081023193901.GA14982@greenwood>
	<20081024013120.8096.qmail@stuge.se> <20081025110559.GA8137@greenwood>
	<49137679.70003@gmx.net>
	<13426df10811061511x134d41a0p5df986ea630c00a3@mail.gmail.com>
	<4913867B.8060706@coresystems.de>
Message-ID: <13426df10811061607s48a78e0do30c18e5006e22da6@mail.gmail.com>

Let's leave it alone. There's no strong feeling for changing it and
these patches make it *really* hard for people who are working on
private mods.

ron



From c-d.hailfinger.devel.2006 at gmx.net  Fri Nov  7 01:10:29 2008
From: c-d.hailfinger.devel.2006 at gmx.net (Carl-Daniel Hailfinger)
Date: Fri, 07 Nov 2008 01:10:29 +0100
Subject: [coreboot] r983 - in coreboot-v3: device include/device
In-Reply-To: <491351E3.3070803@coresystems.de>
References: <20081105222854.3826gmx1@mx011.gmx.net>
	<4912C898.8030602@gmx.net>		<97E3D99CC80D4C818B3DC1301229D37F@chimp>		<13426df10811060733x2af42783n95a639b8ea2cc1cf@mail.gmail.com>		<16D5B6D7218F46FB9E8CC379AFDA3D13@chimp>		<4727185d0811060749l543a8711v4b81c97c9e80abdf@mail.gmail.com>		<49131873.60305@coresystems.de>	<4727185d0811060910l6b119215ycd4d1284d56cf461@mail.gmail.com>
	<491351E3.3070803@coresystems.de>
Message-ID: <49138775.1080706@gmx.net>

On 06.11.2008 21:21, Stefan Reinauer wrote:
> Vincent Legoll wrote:
>   
>> On Thu, Nov 6, 2008 at 5:16 PM, Stefan Reinauer <stepan at coresystems.de> wrote:
>>   
>>     
>>> Vincent Legoll wrote:
>>>     
>>>       
>>>> Isn't all that kind of things doable via function pointers and link-time dead
>>>> code elimination ? That would achieve the no ifdeffery goal, and may be
>>>> cleaner code...
>>>>       
>>>>         
>>> Link time optimization would suggest we look into compiling with LLVM
>>> instead of gcc.
>>>     
>>>       
>> I was believing that current linkers discarded code of unused functions.
>> Would LLVM really be needed for that to happen ? Or are you thing of
>> more involved optimizations ?
>>   
>>     
> Any non-static functions in a file will stay in the final binary, unless
> you do some trickery like -combine, but that usually requires some
> changes to the build system.
>   

We already have CONFIG_WHOLE_PROGRAM_COMPILE in v3. I can make sure it
is available for all stages. Right now it is only used for initram.


Regards,
Carl-Daniel

-- 
http://www.hailfinger.org/




From kevin at koconnor.net  Fri Nov  7 01:10:52 2008
From: kevin at koconnor.net (Kevin O'Connor)
Date: Thu, 6 Nov 2008 19:10:52 -0500
Subject: [coreboot] SeaBIOS question and cross compilation fix.
In-Reply-To: <49130685.7030804@coresystems.de>
References: <49130685.7030804@coresystems.de>
Message-ID: <20081107001052.GA31143@morn.localdomain>

On Thu, Nov 06, 2008 at 04:00:21PM +0100, Stefan Reinauer wrote:
> I am experimenting with v3 and better integration of SeaBIOS and
> coreboot. For that, I am copying a SeaBIOS image to the FSEG during
> coreboot's VGA init code. In addition I added another 32bit entry point
> to SeaBIOS at 0xffc0 (Thus, living at 0xfffc0)
[...]
> Unfortunately, this does not seem to work. The machine jumps somewhere
> else and will triple fault eventually.

Hrrm.  Nothing looks immediately wrong.  Are you running this under
qemu?  If so, one can attach gdb to qemu and set breakpoints in the
guest.  I've used this in the past with success.

http://bellard.org/qemu/qemu-doc.html#TOC46

BTW, in previous emails I highlighted some disadvantages with a
tighter integration of seabios and coreboot.  Could you elaborate on
the reasons why you think this is the best option?

> Also, find attached a patch to allow cross compilation of SeaBIOS and
> make it work with systems where /bin/echo does not know the option -e

Thanks.

-Kevin



From c-d.hailfinger.devel.2006 at gmx.net  Fri Nov  7 01:14:57 2008
From: c-d.hailfinger.devel.2006 at gmx.net (Carl-Daniel Hailfinger)
Date: Fri, 07 Nov 2008 01:14:57 +0100
Subject: [coreboot] Homemaid LPC flasher
In-Reply-To: <98aab1b0790608659df959b321b0df21@imap.1and1.com>
References: <8e37ed8e264328e3876c92411a4b5493@imap.1and1.com>
	<49138232.4060402@gmx.net>
	<98aab1b0790608659df959b321b0df21@imap.1and1.com>
Message-ID: <49138881.1020204@gmx.net>

On 07.11.2008 01:04, Joseph Smith wrote:
>
> On Fri, 07 Nov 2008 00:48:02 +0100, Carl-Daniel Hailfinger
> <c-d.hailfinger.devel.2006 at gmx.net> wrote:
>   
>>> Anyways, I am going to start a project based on a very simple and CHEAP
>>> LPC flasher originally designed for the xbox.
>>> http://rex.xbox-scene.com/LPC2/LPC2.html
>>> [...]
>>> My question to the coreboot community is?..
>>> I have no problem hosting this project on my site, but would everyone
>>> like me to incorporate this project into coreboot? If so is anyone
>>> interested in helping?
>>>
>>>       
>> Do we want to add support for this flasher to flashrom? In theory,
>> reusing the abstraction model present since SPI could work well.
>>
>>     
> flashrom support would be very very cool :-)
> The ability of flashrom flashing over LPC would greatly broaden it
> horizons.
>   

You mean LPT?

> After I get it up and working, I also am going to do some testing with USB
> to LPC adapters for those of you that don't have a LPC port.

LPT again?

> These adapters
> can be found on eBay for pennies on the dollar (very cheap). I also plan on
> powering the LPC flasher from USB.
>   

AFAIK most USB-LPT adaptors have timing problems (timing is important
for many LPC chips) and you may not be able to control all pins
manually. If it works, more power to you!

Regards,
Carl-Daniel

-- 
http://www.hailfinger.org/




From stepan at coresystems.de  Fri Nov  7 01:17:46 2008
From: stepan at coresystems.de (Stefan Reinauer)
Date: Fri, 07 Nov 2008 01:17:46 +0100
Subject: [coreboot] SeaBIOS question and cross compilation fix.
In-Reply-To: <20081107001052.GA31143@morn.localdomain>
References: <49130685.7030804@coresystems.de>
	<20081107001052.GA31143@morn.localdomain>
Message-ID: <4913892A.6080203@coresystems.de>

Kevin O'Connor wrote:
>> Unfortunately, this does not seem to work. The machine jumps somewhere
>> else and will triple fault eventually.
>>     
>
> Hrrm.  Nothing looks immediately wrong.  Are you running this under
> qemu?  If so, one can attach gdb to qemu and set breakpoints in the
> guest.  I've used this in the past with success.
>
> http://bellard.org/qemu/qemu-doc.html#TOC46
>   
Ok, gotta try that. Thanks for the hint and pointer.

> BTW, in previous emails I highlighted some disadvantages with a
> tighter integration of seabios and coreboot.  Could you elaborate on
> the reasons why you think this is the best option?
Simple:

a) I don't want to maintain my own bios emulation in coreboot v3
b) I still want graphics initialized (and possibly more)
c) I don't want to use int19 booting / I don't want to use seabios as a
payload.
  * because I might be running in an emulator or not
  * because I am running other payloads and I want to spend as little
time in seabios as possible
  * because I think this is the only possible way to do a soft
transition of the code that is in coreboot these days and what we might
see some day in the future.

That said, I must have missed the mail you are talking about.

Stefan

-- 
coresystems GmbH ? Brahmsstr. 16 ? D-79104 Freiburg i. Br.
      Tel.: +49 761 7668825 ? Fax: +49 761 7664613
Email: info at coresystems.de  ? http://www.coresystems.de/
Registergericht: Amtsgericht Freiburg ? HRB 7656
Gesch?ftsf?hrer: Stefan Reinauer ? Ust-IdNr.: DE245674866




From corey.osgood at gmail.com  Fri Nov  7 01:19:11 2008
From: corey.osgood at gmail.com (Corey Osgood)
Date: Thu, 6 Nov 2008 19:19:11 -0500
Subject: [coreboot] [PATCH] v3: s/BIOS_DEBUG/DEBUG/ etc. for printk()
In-Reply-To: <4913867B.8060706@coresystems.de>
References: <20081023193901.GA14982@greenwood>
	<20081024013120.8096.qmail@stuge.se> <20081025110559.GA8137@greenwood>
	<49137679.70003@gmx.net>
	<13426df10811061511x134d41a0p5df986ea630c00a3@mail.gmail.com>
	<4913867B.8060706@coresystems.de>
Message-ID: <dd3c80060811061619l3cf7db91ja1b4a8dfcf8c83b8@mail.gmail.com>

On Thu, Nov 6, 2008 at 7:06 PM, Stefan Reinauer <stepan at coresystems.de>wrote:

> ron minnich schrieb:
>
>  On Thu, Nov 6, 2008 at 2:58 PM, Carl-Daniel Hailfinger
>> <c-d.hailfinger.devel.2006 at gmx.net> wrote:
>>
>>
>>> On 25.10.2008 13:05, Uwe Hermann wrote:
>>>
>>>
>>>> On Fri, Oct 24, 2008 at 03:31:20AM +0200, Peter Stuge wrote:
>>>>
>>>>
>>>>
>>>>> Uwe Hermann wrote:
>>>>>
>>>>>
>>>>>
>>>>>> Drop the 'BIOS_' prefix from all printk() log-levels.
>>>>>>
>>>>>>
>>>>>>
>>>>> It would be nice to have another prefix though. Maybe LOG_ ? Without
>>>>> a prefix some of the names look a bit too generic.
>>>>>
>>>>>
>>>>>
>>>> I've though about that, but I don't see it as a big problem. Only
>>>> "DEBUG" tends to be misused in v2, but we can easily avoid that by
>>>> using DEBUG_SMBUS, DEBUG_FOOBAR #defines in v3 (if at all; all of
>>>> those custom DEBUG #defines should be printk()-loglevels anyway;
>>>> I think the reason for DEBUG in v2 is usually romcc/size rel?ted(?))
>>>>
>>>> If we all desperately want a prefix, how about something really short,
>>>> e.g. LDEBUG, LWARN, LINFO, ... ? I'd really like to keep the printk()
>>>> lines as short as possible for readability reasons.
>>>>
>>>>
>>>>
>>> Can't we just keep the names as they are?
>>>
>>>
>>>
>>
>>
>> I think the majority prefer that they not change ...
>>
>>
> Add me to that majority. I think those names are good as they are.
>
> Please don't change such stuff just for the sake of it.
>
> a) it really does not matter
> b) don't make it longer than it is
> c) keep it comprehensible.


I'm agreeing here too. changing it breaks most outstanding patches, screws
up everyone that's used to BIOS_X, and I can't really see any benefit to a
different name, aside from less typing, but that's what copy and paste are
for ;)

-Corey
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20081106/6bf4168c/attachment.html>

From joe at settoplinux.org  Fri Nov  7 01:21:03 2008
From: joe at settoplinux.org (Joseph Smith)
Date: Thu, 06 Nov 2008 19:21:03 -0500
Subject: [coreboot] Homemaid LPC flasher
In-Reply-To: <49138881.1020204@gmx.net>
References: <8e37ed8e264328e3876c92411a4b5493@imap.1and1.com>
	<49138232.4060402@gmx.net>
	<98aab1b0790608659df959b321b0df21@imap.1and1.com>
	<49138881.1020204@gmx.net>
Message-ID: <4a997fa45efa82ec994638471a425295@imap.1and1.com>




On Fri, 07 Nov 2008 01:14:57 +0100, Carl-Daniel Hailfinger
<c-d.hailfinger.devel.2006 at gmx.net> wrote:
> On 07.11.2008 01:04, Joseph Smith wrote:
>>
>> On Fri, 07 Nov 2008 00:48:02 +0100, Carl-Daniel Hailfinger
>> <c-d.hailfinger.devel.2006 at gmx.net> wrote:
>>
>>>> Anyways, I am going to start a project based on a very simple and
> CHEAP
>>>> LPC flasher originally designed for the xbox.
>>>> http://rex.xbox-scene.com/LPC2/LPC2.html
>>>> [...]
>>>> My question to the coreboot community is?..
>>>> I have no problem hosting this project on my site, but would everyone
>>>> like me to incorporate this project into coreboot? If so is anyone
>>>> interested in helping?
>>>>
>>>>
>>> Do we want to add support for this flasher to flashrom? In theory,
>>> reusing the abstraction model present since SPI could work well.
>>>
>>>
>> flashrom support would be very very cool :-)
>> The ability of flashrom flashing over LPC would greatly broaden it
>> horizons.
>>
> 
> You mean LPT?
Sorry slip of the tung, yes LPT
> 
>> After I get it up and working, I also am going to do some testing with
> USB
>> to LPT adapters for those of you that don't have a LPT port.
> 
> LPT again?
yes LPT
> 
>> These adapters
>> can be found on eBay for pennies on the dollar (very cheap). I also plan
> on
>> powering the LPC flasher from USB.
>>
> 
> AFAIK most USB-LPT adaptors have timing problems (timing is important
> for many LPC chips) and you may not be able to control all pins
> manually. If it works, more power to you!
> 
Hmm, that maybe a problem. That is off in the future anyways. 
But I am going to at least give it a shot :-|

-- 
Thanks,
Joseph Smith
Set-Top-Linux
www.settoplinux.org




From stepan at coresystems.de  Fri Nov  7 01:23:27 2008
From: stepan at coresystems.de (Stefan Reinauer)
Date: Fri, 07 Nov 2008 01:23:27 +0100
Subject: [coreboot] r983 - in coreboot-v3: device include/device
In-Reply-To: <49138775.1080706@gmx.net>
References: <20081105222854.3826gmx1@mx011.gmx.net>
	<4912C898.8030602@gmx.net>		<97E3D99CC80D4C818B3DC1301229D37F@chimp>		<13426df10811060733x2af42783n95a639b8ea2cc1cf@mail.gmail.com>		<16D5B6D7218F46FB9E8CC379AFDA3D13@chimp>		<4727185d0811060749l543a8711v4b81c97c9e80abdf@mail.gmail.com>		<49131873.60305@coresystems.de>	<4727185d0811060910l6b119215ycd4d1284d56cf461@mail.gmail.com>
	<491351E3.3070803@coresystems.de> <49138775.1080706@gmx.net>
Message-ID: <49138A7F.5090207@coresystems.de>

Carl-Daniel Hailfinger wrote:
>> Any non-static functions in a file will stay in the final binary, unless
>> you do some trickery like -combine, but that usually requires some
>> changes to the build system.
>>   
>>     
>
> We already have CONFIG_WHOLE_PROGRAM_COMPILE in v3. I can make sure it
> is available for all stages. Right now it is only used for initram.
>   

As I said, it requires changes to the build system. :-)


-- 
coresystems GmbH ? Brahmsstr. 16 ? D-79104 Freiburg i. Br.
      Tel.: +49 761 7668825 ? Fax: +49 761 7664613
Email: info at coresystems.de  ? http://www.coresystems.de/
Registergericht: Amtsgericht Freiburg ? HRB 7656
Gesch?ftsf?hrer: Stefan Reinauer ? Ust-IdNr.: DE245674866




From c-d.hailfinger.devel.2006 at gmx.net  Fri Nov  7 01:25:24 2008
From: c-d.hailfinger.devel.2006 at gmx.net (Carl-Daniel Hailfinger)
Date: Fri, 07 Nov 2008 01:25:24 +0100
Subject: [coreboot] Homemaid LPC flasher
In-Reply-To: <4a997fa45efa82ec994638471a425295@imap.1and1.com>
References: <8e37ed8e264328e3876c92411a4b5493@imap.1and1.com>
	<49138232.4060402@gmx.net>
	<98aab1b0790608659df959b321b0df21@imap.1and1.com>
	<49138881.1020204@gmx.net>
	<4a997fa45efa82ec994638471a425295@imap.1and1.com>
Message-ID: <49138AF4.10204@gmx.net>

On 07.11.2008 01:21, Joseph Smith wrote:
>
> On Fri, 07 Nov 2008 01:14:57 +0100, Carl-Daniel Hailfinger
> <c-d.hailfinger.devel.2006 at gmx.net> wrote:
>   
>> On 07.11.2008 01:04, Joseph Smith wrote:
>>     
>>> On Fri, 07 Nov 2008 00:48:02 +0100, Carl-Daniel Hailfinger
>>> <c-d.hailfinger.devel.2006 at gmx.net> wrote:
>>>
>>>       
>>>>> Anyways, I am going to start a project based on a very simple and
>>>>>           
>> CHEAP
>>     
>>>>> LPC flasher originally designed for the xbox.
>>>>> http://rex.xbox-scene.com/LPC2/LPC2.html
>>>>> [...]
>>>>> My question to the coreboot community is?..
>>>>> I have no problem hosting this project on my site, but would everyone
>>>>> like me to incorporate this project into coreboot? If so is anyone
>>>>> interested in helping?
>>>>>
>>>>>
>>>>>           
>>>> Do we want to add support for this flasher to flashrom? In theory,
>>>> reusing the abstraction model present since SPI could work well.
>>>>
>>>>
>>>>         
>>> flashrom support would be very very cool :-)
>>> The ability of flashrom flashing over LPC would greatly broaden it
>>> horizons.
>>>
>>>       
>> You mean LPT?
>>     
> Sorry slip of the tung, yes LPT
>   
>>> After I get it up and working, I also am going to do some testing with
>>>       
>> USB
>>     
>>> to LPT adapters for those of you that don't have a LPT port.
>>>       
>> LPT again?
>>     
> yes LPT
>   
>>> These adapters
>>> can be found on eBay for pennies on the dollar (very cheap). I also plan
>>>       
>> on
>>     
>>> powering the LPC flasher from USB.
>>>
>>>       
>> AFAIK most USB-LPT adaptors have timing problems (timing is important
>> for many LPC chips) and you may not be able to control all pins
>> manually. If it works, more power to you!
>>
>>     
> Hmm, that maybe a problem. That is off in the future anyways. 
> But I am going to at least give it a shot :-|
>   

By the way, there's also a homemade SPI flasher which should be way
easier to support from flashrom:
http://rayer.ic.cz/elektro/spipgm.htm

IIRC Rudolf mentioned it some time ago.

Regards,
Carl-Daniel

-- 
http://www.hailfinger.org/




From joe at settoplinux.org  Fri Nov  7 01:34:57 2008
From: joe at settoplinux.org (Joseph Smith)
Date: Thu, 06 Nov 2008 19:34:57 -0500
Subject: [coreboot] Homemaid LPC flasher
In-Reply-To: <49138AF4.10204@gmx.net>
References: <8e37ed8e264328e3876c92411a4b5493@imap.1and1.com>
	<49138232.4060402@gmx.net>
	<98aab1b0790608659df959b321b0df21@imap.1and1.com>
	<49138881.1020204@gmx.net>
	<4a997fa45efa82ec994638471a425295@imap.1and1.com>
	<49138AF4.10204@gmx.net>
Message-ID: <da8bddf8bb2a6df144eaf89cb791a5bc@imap.1and1.com>



> By the way, there's also a homemade SPI flasher which should be way
> easier to support from flashrom:
> http://rayer.ic.cz/elektro/spipgm.htm
> 
> IIRC Rudolf mentioned it some time ago.
> 
That's really cool for SPI but I am more interested in PLCC32 fwh chips....

-- 
Thanks,
Joseph Smith
Set-Top-Linux
www.settoplinux.org




From svn at coreboot.org  Fri Nov  7 01:51:38 2008
From: svn at coreboot.org (svn at coreboot.org)
Date: Fri,  7 Nov 2008 01:51:38 +0100
Subject: [coreboot] r986 - coreboot-v3/mainboard/pcengines/alix2c3
Message-ID: <mailman.2396.1355071426.16123.coreboot@coreboot.org>

Author: mjones
Date: 2008-11-07 01:51:38 +0100 (Fri, 07 Nov 2008)
New Revision: 986

Modified:
   coreboot-v3/mainboard/pcengines/alix2c3/dts
Log:
LPC serial IRQs were being left enabled when there is no LPC serial device.

Signed-off-by: Marc Jones <marcj303 at yahoo.com>
Acked-by: Ronald G. Minnich <rminnich at gmail.com>


Modified: coreboot-v3/mainboard/pcengines/alix2c3/dts
===================================================================
--- coreboot-v3/mainboard/pcengines/alix2c3/dts	2008-11-06 17:52:52 UTC (rev 985)
+++ coreboot-v3/mainboard/pcengines/alix2c3/dts	2008-11-07 00:51:38 UTC (rev 986)
@@ -34,9 +34,9 @@
 			/config/("southbridge/amd/cs5536/dts");
 			/* Interrupt enables for LPC bus.
 			 *  Each bit is an IRQ 0-15. */
-			lpc_serirq_enable = "0x0000105A";
+			lpc_serirq_enable = "0x00001002";
 			/* LPC IRQ polarity. Each bit is an IRQ 0-15. */
-			lpc_serirq_polarity = "0x0000EFA5";
+			lpc_serirq_polarity = "0x0000EFFD";
 			/* 0:continuous 1:quiet */
 			lpc_serirq_mode = "1";
 			/* GPIO(0-0x20) for INT D:C:B:A, 0xFF=none. 




From kevin at koconnor.net  Fri Nov  7 02:02:18 2008
From: kevin at koconnor.net (Kevin O'Connor)
Date: Thu, 6 Nov 2008 20:02:18 -0500
Subject: [coreboot] SeaBIOS question and cross compilation fix.
In-Reply-To: <4913892A.6080203@coresystems.de>
References: <49130685.7030804@coresystems.de>
	<20081107001052.GA31143@morn.localdomain>
	<4913892A.6080203@coresystems.de>
Message-ID: <20081107010218.GB31308@morn.localdomain>

On Fri, Nov 07, 2008 at 01:17:46AM +0100, Stefan Reinauer wrote:
> > BTW, in previous emails I highlighted some disadvantages with a
> > tighter integration of seabios and coreboot.  Could you elaborate on
> > the reasons why you think this is the best option?
> Simple:
> 
> a) I don't want to maintain my own bios emulation in coreboot v3
> b) I still want graphics initialized (and possibly more)
> c) I don't want to use int19 booting / I don't want to use seabios as a
> payload.
>   * because I might be running in an emulator or not
>   * because I am running other payloads and I want to spend as little
> time in seabios as possible
>   * because I think this is the only possible way to do a soft
> transition of the code that is in coreboot these days and what we might
> see some day in the future.
> 
> That said, I must have missed the mail you are talking about.

I was thinking of the chain of emails at:

http://www.coreboot.org/pipermail/coreboot/2008-July/036545.html


My (new) thinking is that we could:

* Continue to have seabios be a coreboot payload

* Have seabios find, copy, and run options roms on pci cards.  Have it
  scan the lar for pci devices with option roms embedded in flash.

* Teach seabios to be able to launch a payload from flash in addition
  to floppy, hd, cdrom, etc..

The main gain to the above is is that we can keep all the legacy x86
real mode crud (including option roms) in one place (seabios), and we
can avoid having to return from seabios to coreboot and thus not have
to worry abou them "stomping" on each other.

-Kevin



From stepan at coresystems.de  Fri Nov  7 02:18:34 2008
From: stepan at coresystems.de (Stefan Reinauer)
Date: Fri, 07 Nov 2008 02:18:34 +0100
Subject: [coreboot] SeaBIOS question and cross compilation fix.
In-Reply-To: <20081107010218.GB31308@morn.localdomain>
References: <49130685.7030804@coresystems.de>
	<20081107001052.GA31143@morn.localdomain>
	<4913892A.6080203@coresystems.de>
	<20081107010218.GB31308@morn.localdomain>
Message-ID: <4913976A.5070300@coresystems.de>

Kevin O'Connor wrote:
> On Fri, Nov 07, 2008 at 01:17:46AM +0100, Stefan Reinauer wrote:
>   
>>> BTW, in previous emails I highlighted some disadvantages with a
>>> tighter integration of seabios and coreboot.  Could you elaborate on
>>> the reasons why you think this is the best option?
>>>       
>> Simple:
>>
>> a) I don't want to maintain my own bios emulation in coreboot v3
>> b) I still want graphics initialized (and possibly more)
>> c) I don't want to use int19 booting / I don't want to use seabios as a
>> payload.
>>   * because I might be running in an emulator or not
>>   * because I am running other payloads and I want to spend as little
>> time in seabios as possible
>>   * because I think this is the only possible way to do a soft
>> transition of the code that is in coreboot these days and what we might
>> see some day in the future.
>>
>> That said, I must have missed the mail you are talking about.
>>     
>
> I was thinking of the chain of emails at:
>
> http://www.coreboot.org/pipermail/coreboot/2008-July/036545.html
>
>
> My (new) thinking is that we could:
>
> * Continue to have seabios be a coreboot payload
>   
Sure, many want that. But some don't. I'm looking into how to make
everyone happy;
> * Have seabios find, copy, and run options roms on pci cards.  Have it
>   scan the lar for pci devices with option roms embedded in flash.
>   
For example, I'd really very much prefer if coreboot stays the active
instance for option rom execution for my application case.

Because otherwise I'd have to re-implement a lot of stuff in SeaBIOS
that already is in coreboot. As you suggest, too.

My approach is to drop code from coreboot instead, because SeaBIOS does
a good job there.

> * Teach seabios to be able to launch a payload from flash in addition
>   to floppy, hd, cdrom, etc..
>   
That's pretty much re-inventing the wheel, or growing three legs just to
cut one off. Why would one go such a complicated way instead of just
returning from seabios after init?

SeaBIOS really does a lot of stuff betweeen setting up interrupts and
running the OS that don't belong in a "we just want VGA on" scenario.

Also, I think, SeaBIOS does not need to know about LAR.

Let's try to make both projects simple, not both projects complicated.

> The main gain to the above is is that we can keep all the legacy x86
> real mode crud (including option roms) in one place (seabios).
Oh, but that works nicely with my approach, too. I reduced real-mode
code in coreboot by 90% during my experiments.
> and we
> can avoid having to return from seabios to coreboot and thus not have
> to worry abou them "stomping" on each other.
>   
We do have to worry about that in all scenarios though.

Just assuming it's ok for SeaBIOS to overwrite memory that coreboot
filled is not good enough.



-- 
coresystems GmbH ? Brahmsstr. 16 ? D-79104 Freiburg i. Br.
      Tel.: +49 761 7668825 ? Fax: +49 761 7664613
Email: info at coresystems.de  ? http://www.coresystems.de/
Registergericht: Amtsgericht Freiburg ? HRB 7656
Gesch?ftsf?hrer: Stefan Reinauer ? Ust-IdNr.: DE245674866




From peter at stuge.se  Fri Nov  7 02:19:50 2008
From: peter at stuge.se (Peter Stuge)
Date: Fri, 7 Nov 2008 02:19:50 +0100
Subject: [coreboot] [PATCH] v3: s/BIOS_DEBUG/DEBUG/ etc. for printk()
In-Reply-To: <dd3c80060811061619l3cf7db91ja1b4a8dfcf8c83b8@mail.gmail.com>
References: <20081023193901.GA14982@greenwood>
	<20081024013120.8096.qmail@stuge.se>
	<20081025110559.GA8137@greenwood> <49137679.70003@gmx.net>
	<13426df10811061511x134d41a0p5df986ea630c00a3@mail.gmail.com>
	<4913867B.8060706@coresystems.de>
	<dd3c80060811061619l3cf7db91ja1b4a8dfcf8c83b8@mail.gmail.com>
Message-ID: <20081107011950.31420.qmail@stuge.se>

Corey Osgood wrote:
> screws up everyone that's used to BIOS_X, and I can't really see
> any benefit to a different name

I think changing "BIOS" is a good idea. It's just misleading to have
that in coreboot source.


//Peter



From z4ziggy at gmail.com  Fri Nov  7 02:26:28 2008
From: z4ziggy at gmail.com (Elia Yehuda)
Date: Fri, 7 Nov 2008 03:26:28 +0200
Subject: [coreboot] Fwd:  fixing i810 onboard vga
In-Reply-To: <e19d85410811061719v37a9a0f2kcc143cf8d1600e11@mail.gmail.com>
References: <e19d85410811061038x5e9f054ft4ec3b1b93efd029e@mail.gmail.com>
	<55ef48fb3f569a3424087cb7ba0852d5@imap.1and1.com>
	<e19d85410811061719v37a9a0f2kcc143cf8d1600e11@mail.gmail.com>
Message-ID: <e19d85410811061726l5c6abdedyd12f02919f2a6a39@mail.gmail.com>

---------- Forwarded message ----------
From: Elia Yehuda <z4ziggy at gmail.com>
Date: Fri, Nov 7, 2008 at 3:19 AM
Subject: Re: [coreboot] fixing i810 onboard vga
To: Joseph Smith <joe at settoplinux.org>


many thanks Joseph!

you sure have found the problem in the code (without even looking...
remarkable).

i sure had the "CONFIG_VIDEO_MB=8" to my targets' Config.lb which was being
ignored...
so i've added the following (elementary) patch to
coreboot-v2/src/northbridge/intel/i82810/northbridge.c :

Index: northbridge.c
===================================================================
--- northbridge.c    (revision 3698)
+++ northbridge.c    (working copy)
@@ -149,6 +149,16 @@
         drp_value = drp_value >> 4;    // >>= 4; //? mess with later
         tomk += (unsigned long)(translate_i82810_to_mb[drp_value]);

+#ifdef CONFIG_VIDEO_MB
+        /* check for VGA reserved memory */
+        if (CONFIG_VIDEO_MB == 512) {
+            /* FIXME: we round up the 1/2mb to 1 */
+            tomk -= 1;
+        } else {
+            tomk -= CONFIG_VIDEO_MB;
+        }
+#endif
+
         printk_debug("Setting RAM size to %d MB\n", tomk);

         /* Convert tomk from MB to KB. */



the boot now works, but still no onboard-vga. ive noticed in pci_rom_probe()
the dev->rom_address of the vga pci card is 0 (zero)! although i have the
following in the mainboard/manu/type/Config.lb :
...
    device pci 1.0 on                # Onboard video
       chip drivers/pci/onboard
         device pci 1.0 on end
         register "rom_address" = "0xfffc0000"
       end
    end
...


this is according to the lspci output from the machine using the original
bios :
...
00:01.0 VGA compatible controller: Intel Corporation 82810E DC-133 (CGC)
Chipset Graphics Controller (rev 03)
...


so im trying to find out why dev->rom_address is being set to 0.
the fallback/static.c shows clearly that the rom address is being set in the
proper device structure :
...
struct drivers_pci_onboard_config drivers_pci_onboard_info_9    = {
        .rom_address = 0xfffc0000,
};
...


so any clues on the matter will be appreciated.

Regards,
Elia Yehuda.


On Fri, Nov 7, 2008 at 1:08 AM, Joseph Smith <joe at settoplinux.org> wrote:

>
>
>
> On Thu, 6 Nov 2008 20:38:31 +0200, "Elia Yehuda" <z4ziggy at gmail.com>
> wrote:
> > Hey all,
> >
> > im working at the on the i810, trying to fix the onboard-vga to work.
> >
> > removing the commented code of the vga-related stuff resulted with the
> pci
> > device to be displayed in the pci list on coreboot, but in a disabled
> > state,
> > and (as promised...) with the boot not executing the payload. complete
> log
> > can be shown here : http://pastebin.com/m20e821eb
> >
> > a few rough patches to my target and i82810/raminit.c and now the device
> > is
> > shown as enabled and i even get the information about the VGA allocating
> > resources :
> >
> > Allocating VGA resource PCI: 00:01.0
> > Setting PCI_BRIDGE_CTL_VGA for bridge PCI_DOMAIN: 0000
> > Setting PCI_BRIDGE_CTL_VGA for bridge Root Device
> >
> > but the payload still wont execute (it is seems to be loaded though) and
> > ofcourse, no VGA output, only serial, with a dead boot hanging...
> > complete log can be shown here : http://pastebin.com/m248a41ea
> >
> I had this problem on the i830. You need to allocate vga memory for the
> onboard vga (northbridge.c if I remember correctly). The vga memory should
> be allocated to the TOM. So your total system memory actually equals
> phisical memory - vga memory. It should be close to the i830, take a look
> at that and compare it to the i810 datasheet. Hope that helps.
>
> --
> Thanks,
> Joseph Smith
> Set-Top-Linux
> www.settoplinux.org
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20081107/02682db9/attachment.html>

From c-d.hailfinger.devel.2006 at gmx.net  Fri Nov  7 02:44:18 2008
From: c-d.hailfinger.devel.2006 at gmx.net (Carl-Daniel Hailfinger)
Date: Fri, 07 Nov 2008 02:44:18 +0100
Subject: [coreboot] [PATCH] v3: Explain the ld options for initram
Message-ID: <49139D72.6000909@gmx.net>

initram is linked with very special options to ld. It is not immediately
obvious that they are needed, so a comment to that effect will hopefully
prevent accidental "cleanups" in the future when nobody remembers the
history of that makefile rule anymore.

Signed-off-by: Carl-Daniel Hailfinger <c-d.hailfinger.devel.2006 at gmx.net>

Index: corebootv3-makefile_ld_xip_comments/arch/x86/Makefile
===================================================================
--- corebootv3-makefile_ld_xip_comments/arch/x86/Makefile	(Revision 986)
+++ corebootv3-makefile_ld_xip_comments/arch/x86/Makefile	(Arbeitskopie)
@@ -274,6 +274,8 @@
 	$(Q)$(AS) $(obj)/initram_picwrapper.s -o $(obj)/initram_picwrapper.o
 	$(Q)# initram links against stage0
 	$(Q)printf "  LD      $(subst $(shell pwd)/,,$(@))\n"
+	$(Q)# WARNING: Using -N (and not -n or others) for ld is essential to
+	$(Q)# get all important stuff into one segment!
 	$(Q)$(LD) -Ttext 0 --entry main -N -R $(obj)/stage0-prefixed.o \
 		$(obj)/coreboot.initram_partiallylinked.o \
 		$(obj)/initram_picwrapper.o -o $(obj)/coreboot.initram


-- 
http://www.hailfinger.org/




From z4ziggy at gmail.com  Fri Nov  7 03:24:38 2008
From: z4ziggy at gmail.com (Elia Yehuda)
Date: Fri, 7 Nov 2008 04:24:38 +0200
Subject: [coreboot] fixing i810 onboard vga
In-Reply-To: <7988291d03369b53d8680e7df147eb6f@imap.1and1.com>
References: <e19d85410811061038x5e9f054ft4ec3b1b93efd029e@mail.gmail.com>
	<55ef48fb3f569a3424087cb7ba0852d5@imap.1and1.com>
	<e19d85410811061719v37a9a0f2kcc143cf8d1600e11@mail.gmail.com>
	<7988291d03369b53d8680e7df147eb6f@imap.1and1.com>
Message-ID: <e19d85410811061824j8fe0153ge3f4b085f1d3814f@mail.gmail.com>

tnx Joseph,

i've fixed the following (to match my 256kb bios) :

  device pci_domain 0 on

      device pci 0.0 on end            # Host bridge
        chip drivers/pci/onboard
          device pci 1.0 on end            # Onboard video
          register "rom_address" = "0xfffc0000"
      end
  ...
  end

and now the rom_address is set AND i see the device in lspci :
lspci:
00:01.0 VGA compatible controller: Intel Corporation 82810E DC-133 (CGC)
Chipset Graphics Controller (rev 03)
lspci -n:
00:01.0 0300: 8086:7125 (rev 03)

but still no vga-output!
i found the following to might suggest another problem :

PCI Expansion ROM, signature 0xaa55, INIT size 0xa000, data ptr 0x0110
PCI ROM Image, Vendor 8086, Device 0000,
Device or Vendor ID mismatch Vendor 8086, Device 0000

and no "copying VGA ROM Image"...
any idea where the device_id needs to be set?  (the weird thing is that the
device_id is shown fine on lspci -n output)

i'm attaching the complete boot log at the end of the message.


Regards,
Elia Yehuda.


On Fri, Nov 7, 2008 at 3:35 AM, Joseph Smith <joe at settoplinux.org> wrote:

>
>
>
> On Fri, 7 Nov 2008 03:19:35 +0200, "Elia Yehuda" <z4ziggy at gmail.com>
> wrote:
> > many thanks Joseph!
> >
> > you sure have found the problem in the code (without even looking...
> > remarkable).
> >
> > i sure had the "CONFIG_VIDEO_MB=8" to my targets' Config.lb which was
> > being
> > ignored...
> > so i've added the following (elementary) patch to
> > coreboot-v2/src/northbridge/intel/i82810/northbridge.c :
> >
> > Index: northbridge.c
> > ===================================================================
> > --- northbridge.c    (revision 3698)
> > +++ northbridge.c    (working copy)
> > @@ -149,6 +149,16 @@
> >          drp_value = drp_value >> 4;    // >>= 4; //? mess with later
> >          tomk += (unsigned long)(translate_i82810_to_mb[drp_value]);
> >
> > +#ifdef CONFIG_VIDEO_MB
> > +        /* check for VGA reserved memory */
> > +        if (CONFIG_VIDEO_MB == 512) {
> > +            /* FIXME: we round up the 1/2mb to 1 */
> > +            tomk -= 1;
> > +        } else {
> > +            tomk -= CONFIG_VIDEO_MB;
> > +        }
> > +#endif
> > +
> >          printk_debug("Setting RAM size to %d MB\n", tomk);
> >
> >          /* Convert tomk from MB to KB. */
> >
> >
> >
> > the boot now works,
>
> Great, that is a start :-)
>
> > but still no onboard-vga. ive noticed in
> > pci_rom_probe()
> > the dev->rom_address of the vga pci card is 0 (zero)! although i have the
> > following in the mainboard/manu/type/Config.lb :
> > ...
> >     device pci 1.0 on                # Onboard video
> >        chip drivers/pci/onboard
> >          device pci 1.0 on end
> >          register "rom_address" = "0xfffc0000"
> >        end
> >     end
> > ...
> >
> This should be:
>
> device pci_domain 0 on
>    device pci 0.0 on end    # Host bridge
>        chip drivers/pci/onboard
>            device pci 1.0 on end    # Onboard video
>                register "rom_address" = "0xfff80000"
>        end
> end
>
> Hope that helps.
>
> --
> Thanks,
> Joseph Smith
> Set-Top-Linux
> www.settoplinux.org
>
>
complete boot log :

coreboot-2.0.0.0Fallback Fri Nov  7 04:00:16 IST 2008 starting...
Ram1.00
i810 Initial registers have been set.
Ram2.00
Ram3
Found DIMM in slot 00
DIMM is 0x80MB
After translation, dimm_size is 0x0d
No DIMM found in slot 01
DRP calculated to 0x0d
RAM Enable 1: Apply NOP
    Sending RAM command 0x88 to 0x00000000
RAM Enable 2: Precharge all
    Sending RAM command 0xa8 to 0x00000000
RAM Enable 3: CBR
    Sending RAM command 0xe8 to 0x00000000
RAM Enable 4: Mode register set
    Sending RAM command 0xc8 to 0x000001d0
RAM Enable 5: Normal operation
    Sending RAM command 0x28 to 0x00000000
RAM Enable 6: Enable Refresh
Northbridge following SDRAM init:
Ram4
coreboot-2.0.0.0Fallback Fri Nov  7 04:00:16 IST 2008 booting...
end c9788c81, start 12
32-bit delta 1543
calibrate_tsc 32-bit result is 1543
clocks_per_usec: 1543
Enumerating buses...
scan_static_bus for Root Device
APIC_CLUSTER: 0 enabled
Finding PCI configuration type.
PCI: Using configuration type 1
PCI_DOMAIN: 0000 enabled
PCI_DOMAIN: 0000 scanning...
PCI: pci_scan_bus for bus 00
PCI: 00:00.0 [8086/7124] enabled
PCI: 00:01.0 [8086/7125] enabled
PCI: 00:02.0, bad id 0xffffffff
PCI: 00:03.0, bad id 0xffffffff
PCI: 00:04.0, bad id 0xffffffff
PCI: 00:05.0, bad id 0xffffffff
PCI: 00:06.0, bad id 0xffffffff
PCI: 00:07.0, bad id 0xffffffff
PCI: 00:08.0, bad id 0xffffffff
PCI: 00:09.0, bad id 0xffffffff
PCI: 00:0a.0, bad id 0xffffffff
PCI: 00:0b.0, bad id 0xffffffff
PCI: 00:0c.0, bad id 0xffffffff
PCI: 00:0d.0, bad id 0xffffffff
PCI: 00:0e.0, bad id 0xffffffff
PCI: 00:0f.0, bad id 0xffffffff
PCI: 00:10.0, bad id 0xffffffff
PCI: 00:11.0, bad id 0xffffffff
PCI: 00:12.0, bad id 0xffffffff
PCI: 00:13.0, bad id 0xffffffff
PCI: 00:14.0, bad id 0xffffffff
PCI: 00:15.0, bad id 0xffffffff
PCI: 00:16.0, bad id 0xffffffff
PCI: 00:17.0, bad id 0xffffffff
PCI: 00:18.0, bad id 0xffffffff
PCI: 00:19.0, bad id 0xffffffff
PCI: 00:1a.0, bad id 0xffffffff
PCI: 00:1b.0, bad id 0xffffffff
PCI: 00:1c.0, bad id 0xffffffff
PCI: 00:1d.0, bad id 0xffffffff
PCI: 00:1e.0 [8086/2418] bus ops
PCI: 00:1e.0 [8086/2418] enabled
PCI: 00:1f.0 [8086/2410] bus ops
PCI: 00:1f.0 [8086/2410] enabled
PCI: 00:1f.1 [8086/2411] ops
PCI: 00:1f.1 [8086/2411] enabled
PCI: 00:1f.2 [8086/2412] ops
PCI: 00:1f.2 [8086/2412] enabled
PCI: 00:1f.3 [8086/2413] enabled
PCI: 00:1f.4, bad id 0xffffffff
PCI: 00:1f.5 [8086/2415] ops
PCI: 00:1f.5 [8086/2415] enabled
malloc Enter, size 1100, free_mem_ptr 00026000
malloc 0x00026000
PCI: 00:1f.6 [8086/2416] ops
PCI: 00:1f.6 [8086/2416] enabled
PCI: 00:1f.7, bad id 0xffffffff
do_pci_scan_bridge for PCI: 00:1e.0
PCI: pci_scan_bus for bus 01
PCI: 01:00.0, bad id 0xffffffff
PCI: 01:01.0, bad id 0xffffffff
PCI: 01:02.0, bad id 0xffffffff
PCI: 01:03.0, bad id 0xffffffff
PCI: 01:04.0, bad id 0xffffffff
malloc Enter, size 1100, free_mem_ptr 0002644c
malloc 0x0002644c
PCI: 01:05.0 [10ec/8139] enabled
PCI: 01:06.0, bad id 0xffffffff
PCI: 01:07.0, bad id 0xffffffff
PCI: 01:08.0, bad id 0xffffffff
PCI: 01:09.0, bad id 0xffffffff
PCI: 01:0a.0, bad id 0xffffffff
PCI: 01:0b.0, bad id 0xffffffff
PCI: 01:0c.0, bad id 0xffffffff
PCI: 01:0d.0, bad id 0xffffffff
PCI: 01:0e.0, bad id 0xffffffff
PCI: 01:0f.0, bad id 0xffffffff
PCI: 01:10.0, bad id 0xffffffff
PCI: 01:11.0, bad id 0xffffffff
PCI: 01:12.0, bad id 0xffffffff
PCI: 01:13.0, bad id 0xffffffff
PCI: 01:14.0, bad id 0xffffffff
PCI: 01:15.0, bad id 0xffffffff
PCI: 01:16.0, bad id 0xffffffff
PCI: 01:17.0, bad id 0xffffffff
PCI: 01:18.0, bad id 0xffffffff
PCI: 01:19.0, bad id 0xffffffff
PCI: 01:1a.0, bad id 0xffffffff
PCI: 01:1b.0, bad id 0xffffffff
PCI: 01:1c.0, bad id 0xffffffff
PCI: 01:1d.0, bad id 0xffffffff
PCI: 01:1e.0, bad id 0xffffffff
PCI: 01:1f.0, bad id 0xffffffff
PCI: pci_scan_bus returning with max=001
do_pci_scan_bridge returns max 1
scan_static_bus for PCI: 00:1f.0
malloc Enter, size 1100, free_mem_ptr 00026898
malloc 0x00026898
malloc Enter, size 1100, free_mem_ptr 00026ce4
malloc 0x00026ce4
malloc Enter, size 1100, free_mem_ptr 00027130
malloc 0x00027130
malloc Enter, size 1100, free_mem_ptr 0002757c
malloc 0x0002757c
malloc Enter, size 1100, free_mem_ptr 000279c8
malloc 0x000279c8
PNP: 002e.1 enabled
PNP: 002e.2 enabled
PNP: 002e.5 enabled
PNP: 002e.8 enabled
PNP: 002e.9 enabled
PNP: 002e.a enabled
PNP: 002e.0 enabled
PNP: 002e.3 enabled
PNP: 002e.6 enabled
PNP: 002e.7 enabled
PNP: 002e.b enabled
scan_static_bus for PCI: 00:1f.0 done
PCI: pci_scan_bus returning with max=001
scan_static_bus for Root Device done
done
Allocating resources...
Reading resources...
Root Device compute_allocate_resource io: base: 00000400 size: 00000000
align: 0 gran: 0
Root Device read_resources bus 0 link: 0
PCI_DOMAIN: 0000 read_resources bus 0 link: 0
PCI: 00:1e.0 compute_allocate_resource io: base: 00000000 size: 00000000
align: 12 gran: 12
PCI: 00:1e.0 read_resources bus 1 link: 0
PCI: 00:1e.0 read_resources bus 1 link: 0 done
PCI: 01:05.0 10 *  [0x00000000 - 0x000000ff] io
PCI: 00:1e.0 compute_allocate_resource io: base: 00000100 size: 00001000
align: 12 gran: 12 done
PCI: 00:1e.0 compute_allocate_resource prefmem: base: 00000000 size:
00000000 align: 20 gran: 20
PCI: 00:1e.0 read_resources bus 1 link: 0
PCI: 00:1e.0 read_resources bus 1 link: 0 done
PCI: 00:1e.0 compute_allocate_resource prefmem: base: 00000000 size:
00000000 align: 20 gran: 20 done
PCI: 00:1e.0 compute_allocate_resource prefmem: base: fff00000 size:
00000000 align: 20 gran: 20
PCI: 00:1e.0 read_resources bus 1 link: 0
PCI: 00:1e.0 read_resources bus 1 link: 0 done
PCI: 00:1e.0 compute_allocate_resource prefmem: base: fff00000 size:
00000000 align: 20 gran: 20 done
PCI: 00:1e.0 24 <- [0x00fff00000 - 0x00ffefffff] size 0x00000000 gran 0x14
bus 01 prefmem
PCI: 00:1e.0 compute_allocate_resource mem: base: 00000000 size: 00000000
align: 20 gran: 20
PCI: 00:1e.0 read_resources bus 1 link: 0
PCI: 00:1e.0 read_resources bus 1 link: 0 done
PCI: 01:05.0 14 *  [0x00000000 - 0x000000ff] mem
PCI: 00:1e.0 compute_allocate_resource mem: base: 00000100 size: 00100000
align: 20 gran: 20 done
PCI: 00:1f.0 read_resources bus 0 link: 0
PCI: 00:1f.0 read_resources bus 0 link: 0 done
PCI_DOMAIN: 0000 read_resources bus 0 link: 0 done
Root Device read_resources bus 0 link: 0 done
PCI: 00:1e.0 1c *  [0x00001000 - 0x00001fff] io
PCI: 00:1f.5 10 *  [0x00002000 - 0x000020ff] io
PCI: 00:1f.6 10 *  [0x00002400 - 0x000024ff] io
PCI: 00:1f.6 14 *  [0x00002800 - 0x0000287f] io
PCI: 00:1f.5 14 *  [0x00002880 - 0x000028bf] io
PCI: 00:1f.2 20 *  [0x000028c0 - 0x000028df] io
PCI: 00:1f.1 20 *  [0x000028e0 - 0x000028ef] io
PCI: 00:1f.3 20 *  [0x000028f0 - 0x000028ff] io
PNP: 002e.7 60 *  [0x00002c00 - 0x00002c00] io
Root Device compute_allocate_resource io: base: 00002c01 size: 00002801
align: 12 gran: 0 done
Root Device compute_allocate_resource mem: base: 00000000 size: 00000000
align: 0 gran: 0
Root Device read_resources bus 0 link: 0
Root Device read_resources bus 0 link: 0 done
PCI: 00:01.0 10 *  [0x00000000 - 0x01ffffff] prefmem
PCI: 00:1e.0 20 *  [0x02000000 - 0x020fffff] mem
PCI: 00:01.0 14 *  [0x02100000 - 0x0217ffff] mem
Root Device compute_allocate_resource mem: base: 02180000 size: 02180000
align: 25 gran: 0 done
Done reading resources.
Allocating VGA resource PCI: 00:01.0
Setting PCI_BRIDGE_CTL_VGA for bridge PCI_DOMAIN: 0000
Setting PCI_BRIDGE_CTL_VGA for bridge Root Device
Setting resources...
Root Device compute_allocate_resource io: base: 00001000 size: 00002801
align: 12 gran: 0
Root Device read_resources bus 0 link: 0
Root Device read_resources bus 0 link: 0 done
PCI: 00:1e.0 1c *  [0x00001000 - 0x00001fff] io
PCI: 00:1f.5 10 *  [0x00002000 - 0x000020ff] io
PCI: 00:1f.6 10 *  [0x00002400 - 0x000024ff] io
PCI: 00:1f.6 14 *  [0x00002800 - 0x0000287f] io
PCI: 00:1f.5 14 *  [0x00002880 - 0x000028bf] io
PCI: 00:1f.2 20 *  [0x000028c0 - 0x000028df] io
PCI: 00:1f.1 20 *  [0x000028e0 - 0x000028ef] io
PCI: 00:1f.3 20 *  [0x000028f0 - 0x000028ff] io
PNP: 002e.7 60 *  [0x00002c00 - 0x00002c00] io
Root Device compute_allocate_resource io: base: 00002c01 size: 00001c01
align: 12 gran: 0 done
Root Device compute_allocate_resource mem: base: fc000000 size: 02180000
align: 25 gran: 0
Root Device read_resources bus 0 link: 0
Root Device read_resources bus 0 link: 0 done
PCI: 00:01.0 10 *  [0xfc000000 - 0xfdffffff] prefmem
PCI: 00:1e.0 20 *  [0xfe000000 - 0xfe0fffff] mem
PCI: 00:01.0 14 *  [0xfe100000 - 0xfe17ffff] mem
Root Device compute_allocate_resource mem: base: fe180000 size: 02180000
align: 25 gran: 0 done
Root Device assign_resources, bus 0 link: 0
Setting RAM size to 120 MB
PCI_DOMAIN: 0000 assign_resources, bus 0 link: 0
PCI: 00:01.0 10 <- [0x00fc000000 - 0x00fdffffff] size 0x02000000 gran 0x19
prefmem
PCI: 00:01.0 14 <- [0x00fe100000 - 0x00fe17ffff] size 0x00080000 gran 0x13
mem
PCI: 00:01.0 30 <- [0x00fffc0000 - 0x00fffbffff] size 0x00000000 gran 0x00
romem
PCI: 00:1e.0 compute_allocate_resource io: base: 00001000 size: 00001000
align: 12 gran: 12
PCI: 00:1e.0 read_resources bus 1 link: 0
PCI: 00:1e.0 read_resources bus 1 link: 0 done
PCI: 01:05.0 10 *  [0x00001000 - 0x000010ff] io
PCI: 00:1e.0 compute_allocate_resource io: base: 00001100 size: 00001000
align: 12 gran: 12 done
PCI: 00:1e.0 1c <- [0x0000001000 - 0x0000001fff] size 0x00001000 gran 0x0c
bus 01 io
PCI: 00:1e.0 compute_allocate_resource mem: base: fe000000 size: 00100000
align: 20 gran: 20
PCI: 00:1e.0 read_resources bus 1 link: 0
PCI: 00:1e.0 read_resources bus 1 link: 0 done
PCI: 01:05.0 14 *  [0xfe000000 - 0xfe0000ff] mem
PCI: 00:1e.0 compute_allocate_resource mem: base: fe000100 size: 00100000
align: 20 gran: 20 done
PCI: 00:1e.0 20 <- [0x00fe000000 - 0x00fe0fffff] size 0x00100000 gran 0x14
bus 01 mem
PCI: 00:1e.0 assign_resources, bus 1 link: 0
PCI: 01:05.0 10 <- [0x0000001000 - 0x00000010ff] size 0x00000100 gran 0x08
io
PCI: 01:05.0 14 <- [0x00fe000000 - 0x00fe0000ff] size 0x00000100 gran 0x08
mem
PCI: 00:1e.0 assign_resources, bus 1 link: 0
PCI: 00:1f.0 assign_resources, bus 0 link: 0
PNP: 002e.1 60 <- [0x0000000378 - 0x000000037f] size 0x00000008 gran 0x03 io
PNP: 002e.1 70 <- [0x0000000007 - 0x0000000007] size 0x00000001 gran 0x00
irq
PNP: 002e.1 74 <- [0x0000000003 - 0x0000000003] size 0x00000001 gran 0x00
drq
PNP: 002e.2 60 <- [0x00000003f8 - 0x00000003ff] size 0x00000008 gran 0x03 io
PNP: 002e.2 70 <- [0x0000000004 - 0x0000000004] size 0x00000001 gran 0x00
irq
PNP: 002e.5 60 <- [0x0000000060 - 0x0000000060] size 0x00000001 gran 0x00 io
PNP: 002e.5 62 <- [0x0000000064 - 0x0000000064] size 0x00000001 gran 0x00 io
PNP: 002e.5 70 <- [0x0000000001 - 0x0000000001] size 0x00000001 gran 0x00
irq
PNP: 002e.5 72 <- [0x000000000c - 0x000000000c] size 0x00000001 gran 0x00
irq
ERROR: PNP: 002e.0 60 io size: 0x0000000008 not assigned
ERROR: PNP: 002e.0 70 irq size: 0x0000000001 not assigned
ERROR: PNP: 002e.0 74 drq size: 0x0000000001 not assigned
ERROR: PNP: 002e.3 60 io size: 0x0000000008 not assigned
ERROR: PNP: 002e.3 70 irq size: 0x0000000001 not assigned
ERROR: PNP: 002e.6 60 io size: 0x0000000008 not assigned
ERROR: PNP: 002e.6 70 irq size: 0x0000000001 not assigned
PNP: 002e.7 60 <- [0x0000002c00 - 0x0000002c00] size 0x00000001 gran 0x00 io
ERROR: PNP: 002e.7 62 io size: 0x0000000002 not assigned
ERROR: PNP: 002e.7 70 irq size: 0x0000000001 not assigned
ERROR: PNP: 002e.b 60 io size: 0x0000000008 not assigned
ERROR: PNP: 002e.b 70 irq size: 0x0000000001 not assigned
PCI: 00:1f.0 assign_resources, bus 0 link: 0
PCI: 00:1f.1 20 <- [0x00000028e0 - 0x00000028ef] size 0x00000010 gran 0x04
io
PCI: 00:1f.2 20 <- [0x00000028c0 - 0x00000028df] size 0x00000020 gran 0x05
io
PCI: 00:1f.3 20 <- [0x00000028f0 - 0x00000028ff] size 0x00000010 gran 0x04
io
PCI: 00:1f.5 10 <- [0x0000002000 - 0x00000020ff] size 0x00000100 gran 0x08
io
PCI: 00:1f.5 14 <- [0x0000002880 - 0x00000028bf] size 0x00000040 gran 0x06
io
PCI: 00:1f.6 10 <- [0x0000002400 - 0x00000024ff] size 0x00000100 gran 0x08
io
PCI: 00:1f.6 14 <- [0x0000002800 - 0x000000287f] size 0x00000080 gran 0x07
io
PCI_DOMAIN: 0000 assign_resources, bus 0 link: 0
Root Device assign_resources, bus 0 link: 0
Done setting resources.
Done allocating resources.
Enabling resources...
PCI: 00:00.0 subsystem <- 00/00
PCI: 00:00.0 cmd <- 06
PCI: 00:01.0 subsystem <- 00/00
PCI: 00:01.0 cmd <- 07
PCI: 00:1e.0 bridge ctrl <- 0003
PCI: 00:1e.0 cmd <- 07
PCI: 01:05.0 cmd <- 03
PCI: 00:1f.0 cmd <- 0f
w83627hf hwm smbus enabled
PCI: 00:1f.1 cmd <- 01
PCI: 00:1f.2 cmd <- 01
PCI: 00:1f.3 subsystem <- 00/00
PCI: 00:1f.3 cmd <- 01
PCI: 00:1f.5 cmd <- 01
PCI: 00:1f.6 cmd <- 01
done.
Initializing devices...
Root Device init
APIC_CLUSTER: 0 init
malloc Enter, size 1100, free_mem_ptr 00027e14
malloc 0x00027e14
Initializing CPU #0
CPU: vendor Intel device 683
CPU: family 06, model 08, stepping 03
Enabling cache

Setting fixed MTRRs(0-88) Type: UC
Setting fixed MTRRs(0-16) Type: WB
DONE fixed MTRRs
call enable_fixed_mtrr()
Setting variable MTRR 0, base:    0MB, range:   64MB, type WB
ADDRESS_MASK_HIGH=0xf
Setting variable MTRR 1, base:   64MB, range:   32MB, type WB
ADDRESS_MASK_HIGH=0xf
Setting variable MTRR 2, base:   96MB, range:   16MB, type WB
ADDRESS_MASK_HIGH=0xf
Setting variable MTRR 3, base:  112MB, range:    8MB, type WB
ADDRESS_MASK_HIGH=0xf
DONE variable MTRRs
Clear out the extra MTRR's
call enable_var_mtrr()
Leave x86_setup_var_mtrrs

MTRR check
Fixed MTRRs   : Enabled
Variable MTRRs: Enabled

microcode_info: sig = 0x00000683 pf=0x00000010 rev = 0x00000000
Disabling local apic...done.
CPU #0 Initialized
PCI: 00:00.0 init
pci_rom_probe() : dev->on_mainboard
pci_rom_probe(): skipping for PCI: 00:00.0 = 0
PCI: 00:01.0 init
pci_rom_probe() : dev->on_mainboard
rom address for PCI: 00:01.0 = fffc0000
PCI Expansion ROM, signature 0xaa55, INIT size 0xa000, data ptr 0x0110
PCI ROM Image, Vendor 8086, Device 0000,
Device or Vendor ID mismatch Vendor 8086, Device 0000
PCI: 00:1e.0 init
PCI: 00:1f.0 init
IOAPIC Southbridge enabled 2186
Southbridge APIC ID = 2000000
Set power on if power fails
RTC Init
PNP: 002e.1 init
PNP: 002e.2 init
PNP: 002e.5 init
Keyboard init...
PNP: 002e.8 init
PNP: 002e.9 init
PNP: 002e.a init
PCI: 00:1f.1 init
IDE0 IDE1 PCI: 00:1f.2 init
PCI: 00:1f.3 init
pci_rom_probe() : dev->on_mainboard
pci_rom_probe(): skipping for PCI: 00:1f.3 = 0
PCI: 01:05.0 init
pci_rom_probe() : !dev->on_mainboard (0/0)
pci_rom_probe(): skipping for PCI: 01:05.0 = 0
PNP: 002e.0 init
PNP: 002e.3 init
PNP: 002e.6 init
PNP: 002e.7 init
PNP: 002e.b init
Devices initialized
Copying IRQ routing tables to 0xf0000...done.
Verifing copy of IRQ routing tables at 0xf0000...done
Checking IRQ routing table consistency...
check_pirq_routing_table() - irq_routing_table located at: 0x000f0000
done.
Moving GDT to 0x500...ok
Adjust low_table_end from 0x00000530 to 0x00001000
Adjust rom_table_end from 0x000f0400 to 0x00100000


Booting 'hda1:/boot/vmlinuz-2.6.27-7-server root=/dev/sda1 ro
console=ttyS0,115
200n8 console=tty0
initrd=hda1:/boot/initrd.img-2.6.27-7-server'
Found Linux version 2.6.27-7-server (buildd at rothera) #1 SMP Fri Oct 24
07:37:55
 UTC 2008
bzImage.
Loading kernel...
ok
Loading initrd...
ok
Jumping to entry
point...
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20081107/b91c386e/attachment.html>

From z4ziggy at gmail.com  Fri Nov  7 03:47:26 2008
From: z4ziggy at gmail.com (Elia Yehuda)
Date: Fri, 7 Nov 2008 04:47:26 +0200
Subject: [coreboot] [patch] add required info to not-matched vendor/device id
Message-ID: <e19d85410811061847o284021ffpf59aba25c3630bd3@mail.gmail.com>

Signed-off-by: Elia Yehuda <z4ziggy at gmail.com>

Index: src/devices/pci_rom.c
===================================================================
--- src/devices/pci_rom.c    (revision 3698)
+++ src/devices/pci_rom.c    (working copy)
@@ -67,8 +67,10 @@
     printk_spew("PCI ROM Image, Vendor %04x, Device %04x,\n",
             rom_data->vendor, rom_data->device);
     if (dev->vendor != rom_data->vendor || dev->device != rom_data->device)
{
-        printk_err("Device or Vendor ID mismatch Vendor %04x, Device
%04x\n",
-               rom_data->vendor, rom_data->device);
+        printk_err("Device or Vendor ID mismatch Vendor %04x, Device %04x "
+               "(Vendor %04x, Device %04x)\n",
+               rom_data->vendor, rom_data->device,
+               dev->vendor, dev->device);
         return NULL;
     }
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20081107/a3df0389/attachment.html>

From joe at settoplinux.org  Fri Nov  7 03:48:32 2008
From: joe at settoplinux.org (Joseph Smith)
Date: Thu, 06 Nov 2008 21:48:32 -0500
Subject: [coreboot] fixing i810 onboard vga
In-Reply-To: <e19d85410811061824j8fe0153ge3f4b085f1d3814f@mail.gmail.com>
References: <e19d85410811061038x5e9f054ft4ec3b1b93efd029e@mail.gmail.com>
	<55ef48fb3f569a3424087cb7ba0852d5@imap.1and1.com>
	<e19d85410811061719v37a9a0f2kcc143cf8d1600e11@mail.gmail.com>
	<7988291d03369b53d8680e7df147eb6f@imap.1and1.com>
	<e19d85410811061824j8fe0153ge3f4b085f1d3814f@mail.gmail.com>
Message-ID: <be2a65ba6edb920bf55d999cb7d2f0de@imap.1and1.com>




On Fri, 7 Nov 2008 04:24:38 +0200, "Elia Yehuda" <z4ziggy at gmail.com> wrote:
> tnx Joseph,
> 
> i've fixed the following (to match my 256kb bios) :
> 
>   device pci_domain 0 on
> 
>       device pci 0.0 on end            # Host bridge
>         chip drivers/pci/onboard
>           device pci 1.0 on end            # Onboard video
>           register "rom_address" = "0xfffc0000"
>       end
>   ...
>   end
> 
> and now the rom_address is set AND i see the device in lspci :
> lspci:
> 00:01.0 VGA compatible controller: Intel Corporation 82810E DC-133 (CGC)
> Chipset Graphics Controller (rev 03)
> lspci -n:
> 00:01.0 0300: 8086:7125 (rev 03)
> 
> but still no vga-output!
> i found the following to might suggest another problem :
> 
> PCI Expansion ROM, signature 0xaa55, INIT size 0xa000, data ptr 0x0110
> PCI ROM Image, Vendor 8086, Device 0000,
> Device or Vendor ID mismatch Vendor 8086, Device 0000
> 
> and no "copying VGA ROM Image"...
Yep that is your problem. Is there something wrong with your vga bios. It
is reading the vendor id ok but the device id should be 7125.
Have you checked this out? It may help you to get a valid vga bios.
http://www.coreboot.org/VGA_support

-- 
Thanks,
Joseph Smith
Set-Top-Linux
www.settoplinux.org




From z4ziggy at gmail.com  Fri Nov  7 03:55:41 2008
From: z4ziggy at gmail.com (Elia Yehuda)
Date: Fri, 7 Nov 2008 04:55:41 +0200
Subject: [coreboot] fixing i810 onboard vga
In-Reply-To: <be2a65ba6edb920bf55d999cb7d2f0de@imap.1and1.com>
References: <e19d85410811061038x5e9f054ft4ec3b1b93efd029e@mail.gmail.com>
	<55ef48fb3f569a3424087cb7ba0852d5@imap.1and1.com>
	<e19d85410811061719v37a9a0f2kcc143cf8d1600e11@mail.gmail.com>
	<7988291d03369b53d8680e7df147eb6f@imap.1and1.com>
	<e19d85410811061824j8fe0153ge3f4b085f1d3814f@mail.gmail.com>
	<be2a65ba6edb920bf55d999cb7d2f0de@imap.1and1.com>
Message-ID: <e19d85410811061855i3ca4c59fpf2546873a05233b2@mail.gmail.com>

yep, ive extraced my vga using awardeco which should be fine (and it does
seems fine on the lspci -n, which is very frustrating)

On Fri, Nov 7, 2008 at 4:48 AM, Joseph Smith <joe at settoplinux.org> wrote:

>
>
>
> On Fri, 7 Nov 2008 04:24:38 +0200, "Elia Yehuda" <z4ziggy at gmail.com>
> wrote:
> > tnx Joseph,
> >
> > i've fixed the following (to match my 256kb bios) :
> >
> >   device pci_domain 0 on
> >
> >       device pci 0.0 on end            # Host bridge
> >         chip drivers/pci/onboard
> >           device pci 1.0 on end            # Onboard video
> >           register "rom_address" = "0xfffc0000"
> >       end
> >   ...
> >   end
> >
> > and now the rom_address is set AND i see the device in lspci :
> > lspci:
> > 00:01.0 VGA compatible controller: Intel Corporation 82810E DC-133 (CGC)
> > Chipset Graphics Controller (rev 03)
> > lspci -n:
> > 00:01.0 0300: 8086:7125 (rev 03)
> >
> > but still no vga-output!
> > i found the following to might suggest another problem :
> >
> > PCI Expansion ROM, signature 0xaa55, INIT size 0xa000, data ptr 0x0110
> > PCI ROM Image, Vendor 8086, Device 0000,
> > Device or Vendor ID mismatch Vendor 8086, Device 0000
> >
> > and no "copying VGA ROM Image"...
> Yep that is your problem. Is there something wrong with your vga bios. It
> is reading the vendor id ok but the device id should be 7125.
> Have you checked this out? It may help you to get a valid vga bios.
> http://www.coreboot.org/VGA_support
>
> --
> Thanks,
> Joseph Smith
> Set-Top-Linux
> www.settoplinux.org
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20081107/f7c882c5/attachment.html>

From c-d.hailfinger.devel.2006 at gmx.net  Fri Nov  7 04:00:22 2008
From: c-d.hailfinger.devel.2006 at gmx.net (Carl-Daniel Hailfinger)
Date: Fri, 07 Nov 2008 04:00:22 +0100
Subject: [coreboot] [patch] add required info to not-matched
 vendor/device id
In-Reply-To: <e19d85410811061847o284021ffpf59aba25c3630bd3@mail.gmail.com>
References: <e19d85410811061847o284021ffpf59aba25c3630bd3@mail.gmail.com>
Message-ID: <4913AF46.9060700@gmx.net>

On 07.11.2008 03:47, Elia Yehuda wrote:
> Signed-off-by: Elia Yehuda <z4ziggy at gmail.com>
>   

A small changelog (2 lines or so, more if you like) would be appreciated.

> Index: src/devices/pci_rom.c
> ===================================================================
> --- src/devices/pci_rom.c    (revision 3698)
> +++ src/devices/pci_rom.c    (working copy)
> @@ -67,8 +67,10 @@
>      printk_spew("PCI ROM Image, Vendor %04x, Device %04x,\n",
>              rom_data->vendor, rom_data->device);
>      if (dev->vendor != rom_data->vendor || dev->device != rom_data->device)
> {
> -        printk_err("Device or Vendor ID mismatch Vendor %04x, Device
> %04x\n",
> -               rom_data->vendor, rom_data->device);
> +        printk_err("Device or Vendor ID mismatch Vendor %04x, Device %04x "
> +               "(Vendor %04x, Device %04x)\n",
> +               rom_data->vendor, rom_data->device,
> +               dev->vendor, dev->device);
>          return NULL;
>      }
>
>   

The patch was mangled by gmail. AFAIK that's an unfixable bug with the
gmail web interface. Please attach the patch instead.

About the contents of the patch: The new message still requires people
to read the source code. How about:
"Device or Vendor ID mismatch: read Vendor %04x, Device %04x, expected
Vendor %04x, Device %04x\n"

Regards,
Carl-Daniel

-- 
http://www.hailfinger.org/




From z4ziggy at gmail.com  Fri Nov  7 04:04:52 2008
From: z4ziggy at gmail.com (Elia Yehuda)
Date: Fri, 7 Nov 2008 05:04:52 +0200
Subject: [coreboot] [patch] add required info to not-matched
	vendor/device id
In-Reply-To: <4913AF46.9060700@gmx.net>
References: <e19d85410811061847o284021ffpf59aba25c3630bd3@mail.gmail.com>
	<4913AF46.9060700@gmx.net>
Message-ID: <e19d85410811061904l1d815fefg58a29e91e62ff674@mail.gmail.com>

On Fri, Nov 7, 2008 at 5:00 AM, Carl-Daniel Hailfinger <
c-d.hailfinger.devel.2006 at gmx.net> wrote:

> On 07.11.2008 03:47, Elia Yehuda wrote:
> > Signed-off-by: Elia Yehuda <z4ziggy at gmail.com>
> >
>
> A small changelog (2 lines or so, more if you like) would be appreciated.



ok, i thought the title was informative enough... i'll try harder next
time!!! :-)



>
>
> > Index: src/devices/pci_rom.c
> > ===================================================================
> > --- src/devices/pci_rom.c    (revision 3698)
> > +++ src/devices/pci_rom.c    (working copy)
> > @@ -67,8 +67,10 @@
> >      printk_spew("PCI ROM Image, Vendor %04x, Device %04x,\n",
> >              rom_data->vendor, rom_data->device);
> >      if (dev->vendor != rom_data->vendor || dev->device !=
> rom_data->device)
> > {
> > -        printk_err("Device or Vendor ID mismatch Vendor %04x, Device
> > %04x\n",
> > -               rom_data->vendor, rom_data->device);
> > +        printk_err("Device or Vendor ID mismatch Vendor %04x, Device
> %04x "
> > +               "(Vendor %04x, Device %04x)\n",
> > +               rom_data->vendor, rom_data->device,
> > +               dev->vendor, dev->device);
> >          return NULL;
> >      }
> >
> >
>
> The patch was mangled by gmail. AFAIK that's an unfixable bug with the
> gmail web interface. Please attach the patch instead.



will do



>
>
> About the contents of the patch: The new message still requires people
> to read the source code. How about:
> "Device or Vendor ID mismatch: read Vendor %04x, Device %04x, expected
> Vendor %04x, Device %04x\n"
>


such a long line breaks the 80 column boundary. is that ok?



>
>
> Regards,
> Carl-Daniel
>
> --
> http://www.hailfinger.org/
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20081107/c5448aee/attachment.html>

From joe at settoplinux.org  Fri Nov  7 04:06:11 2008
From: joe at settoplinux.org (Joseph Smith)
Date: Thu, 06 Nov 2008 22:06:11 -0500
Subject: [coreboot] fixing i810 onboard vga
In-Reply-To: <e19d85410811061855i3ca4c59fpf2546873a05233b2@mail.gmail.com>
References: <e19d85410811061038x5e9f054ft4ec3b1b93efd029e@mail.gmail.com>
	<55ef48fb3f569a3424087cb7ba0852d5@imap.1and1.com>
	<e19d85410811061719v37a9a0f2kcc143cf8d1600e11@mail.gmail.com>
	<7988291d03369b53d8680e7df147eb6f@imap.1and1.com>
	<e19d85410811061824j8fe0153ge3f4b085f1d3814f@mail.gmail.com>
	<be2a65ba6edb920bf55d999cb7d2f0de@imap.1and1.com>
	<e19d85410811061855i3ca4c59fpf2546873a05233b2@mail.gmail.com>
Message-ID: <4927aaf7fa34a9c03b51b9ec13a8ffe1@imap.1and1.com>




On Fri, 7 Nov 2008 04:55:41 +0200, "Elia Yehuda" <z4ziggy at gmail.com> wrote:
> yep, ive extraced my vga using awardeco which should be fine (and it does
> seems fine on the lspci -n, which is very frustrating)
> 
> On Fri, Nov 7, 2008 at 4:48 AM, Joseph Smith <joe at settoplinux.org> wrote:
> 
>>
>>
>>
>> On Fri, 7 Nov 2008 04:24:38 +0200, "Elia Yehuda" <z4ziggy at gmail.com>
>> wrote:
>> > tnx Joseph,
>> >
>> > i've fixed the following (to match my 256kb bios) :
>> >
>> >   device pci_domain 0 on
>> >
>> >       device pci 0.0 on end            # Host bridge
>> >         chip drivers/pci/onboard
>> >           device pci 1.0 on end            # Onboard video
>> >           register "rom_address" = "0xfffc0000"
>> >       end
>> >   ...
>> >   end
>> >
>> > and now the rom_address is set AND i see the device in lspci :
>> > lspci:
>> > 00:01.0 VGA compatible controller: Intel Corporation 82810E DC-133
> (CGC)
>> > Chipset Graphics Controller (rev 03)
>> > lspci -n:
>> > 00:01.0 0300: 8086:7125 (rev 03)
>> >
>> > but still no vga-output!
>> > i found the following to might suggest another problem :
>> >
>> > PCI Expansion ROM, signature 0xaa55, INIT size 0xa000, data ptr 0x0110
>> > PCI ROM Image, Vendor 8086, Device 0000,
>> > Device or Vendor ID mismatch Vendor 8086, Device 0000
>> >
>> > and no "copying VGA ROM Image"...
>> Yep that is your problem. Is there something wrong with your vga bios.
> It
>> is reading the vendor id ok but the device id should be 7125.
>> Have you checked this out? It may help you to get a valid vga bios.
>> http://www.coreboot.org/VGA_support
>>
coreboot uses a different pci.ids file than Linux. That's why Linux can
find it but coreboot can't? Check and see if the coreboot pci.ids file
includes 8086 / 7125. It may be missing and just needs to be added?

-- 
Thanks,
Joseph Smith
Set-Top-Linux
www.settoplinux.org




From c-d.hailfinger.devel.2006 at gmx.net  Fri Nov  7 04:15:43 2008
From: c-d.hailfinger.devel.2006 at gmx.net (Carl-Daniel Hailfinger)
Date: Fri, 07 Nov 2008 04:15:43 +0100
Subject: [coreboot] [PATCH] v3: add a stack checker
Message-ID: <4913B2DF.7010101@gmx.net>

We are woefully unaware about how much stack v3 really uses.
This is a complete rewrite of my earlier stack checker. It works for CAR
and RAM, has better abstraction and actually gives us nice results.
The stack checker is default off due to its rather measurable impact on
boot speed.
Diagnostic messages are printed on first initialization, directly after
RAM init and directly before passing control to the payload. Sample qemu
log is attached. Extract from that log follows:

coreboot-3.0.986 Fri Nov  7 04:04:37 CET 2008 starting...
(console_loglevel=8)
Initial lowest stack is 0x0008fe98
Choosing fallback boot.
[...]
Done RAM init code
After RAM init, lowest stack is 0x0008fe30
Done printk() buffer move
[...]
LAR: load_file_segments: Failed for normal/payload
Before handoff to payload, lowest stack is 0x0008bf50
FATAL: No usable payload found.

Signed-off-by: Carl-Daniel Hailfinger <c-d.hailfinger.devel.2006 at gmx.net>

Patch attached as well for gmail users.

Index: corebootv3-stackcheck/include/globalvars.h
===================================================================
--- corebootv3-stackcheck/include/globalvars.h	(Revision 986)
+++ corebootv3-stackcheck/include/globalvars.h	(Arbeitskopie)
@@ -59,6 +59,10 @@
 	struct sys_info sys_info;
 	/* has the spd hardware been set up? */
 	int spd_inited;
+	int ram_available;
+#ifdef CONFIG_CHECK_STACK_USAGE
+	void *loweststack;
+#endif
 };
 
 #endif /* GLOBALVARS_H */
Index: corebootv3-stackcheck/include/arch/x86/cpu.h
===================================================================
--- corebootv3-stackcheck/include/arch/x86/cpu.h	(Revision 986)
+++ corebootv3-stackcheck/include/arch/x86/cpu.h	(Arbeitskopie)
@@ -265,6 +265,7 @@
 EXPORT_SYMBOL(bottom_of_stack);
 struct global_vars * global_vars(void);
 EXPORT_SYMBOL(global_vars);
+void check_stack(void);
 
 #define CAR_STACK_BASE (CONFIG_CARBASE + CONFIG_CARSIZE - 4)
 #define RAM_STACK_BASE 0x88ffc
@@ -278,6 +279,8 @@
 #else
 #define CAR_STACK_SIZE (CONFIG_CARSIZE - 4)
 #endif
+/* To be honest, this limit is arbitrary and only used for stack checking. */
+#define RAM_STACK_SIZE (65536 - 4)
 
 /* resource maps. These started out as special for the K8 but now have more general usage */
 /* it's not totally clear that the type and union are a great idea, but see the v2 code: 
Index: corebootv3-stackcheck/lib/console.c
===================================================================
--- corebootv3-stackcheck/lib/console.c	(Revision 986)
+++ corebootv3-stackcheck/lib/console.c	(Arbeitskopie)
@@ -150,6 +150,9 @@
 	i += vtxprintf(console_tx_byte, (void *)0, fmt, args);
 	va_end(args);
 
+#ifdef CONFIG_CHECK_STACK_USAGE
+	check_stack();
+#endif
 	return i;
 }
 
Index: corebootv3-stackcheck/arch/x86/Kconfig
===================================================================
--- corebootv3-stackcheck/arch/x86/Kconfig	(Revision 986)
+++ corebootv3-stackcheck/arch/x86/Kconfig	(Arbeitskopie)
@@ -227,4 +227,13 @@
 	help
 	  Test the CAR area after it has been set up.
 
+config CHECK_STACK_USAGE
+	bool "Check stack usage"
+	default n
+	help
+	  Continuously monitor stack usage and keep statistics.
+	  The monitoring code is invoked from printk because printk is
+	  a leaf function and consumes quite a bit of stack for itself.
+	  This slows down booting a LOT.
+
 endmenu
Index: corebootv3-stackcheck/arch/x86/stage1.c
===================================================================
--- corebootv3-stackcheck/arch/x86/stage1.c	(Revision 986)
+++ corebootv3-stackcheck/arch/x86/stage1.c	(Arbeitskopie)
@@ -105,6 +105,28 @@
 
 }
 
+#ifdef CONFIG_CHECK_STACK_USAGE
+/* STACKFILL_BYTE could be a special value like 0x6b. Just make sure the stage0
+ * code fills the complete CAR area with it. And the stack switching needs to
+ * overwrite the unused parts of the stack with STACKFILL_BYTE as well.
+ */
+#define STACKFILL_BYTE 0x0
+void check_stack()
+{
+	unsigned long stacksize, i;
+	char *lowestaddr;
+	if (global_vars()->ram_available)
+		stacksize = RAM_STACK_SIZE;
+	else
+		stacksize = CAR_STACK_SIZE;
+	lowestaddr = bottom_of_stack() - stacksize;
+	for (i = 0; i < stacksize; i++)
+		if (lowestaddr[i] != STACKFILL_BYTE)
+			break;
+	global_vars()->loweststack = lowestaddr + i;
+}
+#endif
+
 void dump_mem_range(int msg_level, unsigned char *buf, int size)
 {
 	int i;
@@ -194,6 +216,10 @@
 	 */
 	console_init();
 
+#ifdef CONFIG_CHECK_STACK_USAGE
+	printk(BIOS_DEBUG, "Initial lowest stack is %p\n",
+		global_vars()->loweststack);
+#endif
 	if (bist!=0) {
 		printk(BIOS_INFO, "BIST FAILED: %08x", bist);
 		die("");
@@ -227,6 +253,10 @@
 		die("Failed RAM init code\n");
 
 	printk(BIOS_DEBUG, "Done RAM init code\n");
+#ifdef CONFIG_CHECK_STACK_USAGE
+	printk(BIOS_DEBUG, "After RAM init, lowest stack is %p\n",
+		global_vars()->loweststack);
+#endif
 
 	/* Switch the stack location from CAR to RAM, rebuild the stack,
 	 * disable CAR and continue at stage1_phase3(). This is all wrapped in
@@ -299,6 +329,9 @@
 	mem->map[0].type = LB_MEM_RAM;
 #endif /* CONFIG_PAYLOAD_ELF_LOADER */
 
+	/* Provide an easy way to check whether RAM is available. */
+	global_vars()->ram_available = 1;
+
 	// location and size of image.
 	init_archive(&archive);
 
@@ -318,6 +351,10 @@
 #endif /* CONFIG_PAYLOAD_ELF_LOADER */
 
 	entry = load_file_segments(&archive, "normal/payload");
+#ifdef CONFIG_CHECK_STACK_USAGE
+	printk(BIOS_DEBUG, "Before handoff to payload, lowest stack is %p\n",
+		global_vars()->loweststack);
+#endif
 	if (entry != (void*)-1) {
 		/* Final coreboot call before handing off to the payload. */
 		mainboard_pre_payload();


-- 
http://www.hailfinger.org/

-------------- next part --------------
A non-text attachment was scrubbed...
Name: linuxbios3_stackcheck.diff
Type: text/x-patch
Size: 4625 bytes
Desc: not available
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20081107/417f9ec4/attachment.diff>
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: bootlog_emulation_qemu-x86.txt
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20081107/417f9ec4/attachment.txt>

From kevin at koconnor.net  Fri Nov  7 04:18:31 2008
From: kevin at koconnor.net (Kevin O'Connor)
Date: Thu, 6 Nov 2008 22:18:31 -0500
Subject: [coreboot] SeaBIOS question and cross compilation fix.
In-Reply-To: <4913976A.5070300@coresystems.de>
References: <49130685.7030804@coresystems.de>
	<20081107001052.GA31143@morn.localdomain>
	<4913892A.6080203@coresystems.de>
	<20081107010218.GB31308@morn.localdomain>
	<4913976A.5070300@coresystems.de>
Message-ID: <20081107031831.GA31576@morn.localdomain>

On Fri, Nov 07, 2008 at 02:18:34AM +0100, Stefan Reinauer wrote:
> Kevin O'Connor wrote:
> > On Fri, Nov 07, 2008 at 01:17:46AM +0100, Stefan Reinauer wrote:
> >>> BTW, in previous emails I highlighted some disadvantages with a
> >>> tighter integration of seabios and coreboot.  Could you elaborate on
> >>> the reasons why you think this is the best option?
> >>>       
> >> Simple:
[...]

Thanks Stefan.  I appreciate your feedback.

One random comment:

> > and we
> > can avoid having to return from seabios to coreboot and thus not have
> > to worry abou them "stomping" on each other.
> >   
> We do have to worry about that in all scenarios though.
> 
> Just assuming it's ok for SeaBIOS to overwrite memory that coreboot
> filled is not good enough.

I'm more worried about the option roms corrupting memory that coreboot
uses.

-Kevin



From c-d.hailfinger.devel.2006 at gmx.net  Fri Nov  7 04:24:18 2008
From: c-d.hailfinger.devel.2006 at gmx.net (Carl-Daniel Hailfinger)
Date: Fri, 07 Nov 2008 04:24:18 +0100
Subject: [coreboot] [patch] add required info to not-matched
 vendor/device id
In-Reply-To: <e19d85410811061904l1d815fefg58a29e91e62ff674@mail.gmail.com>
References: <e19d85410811061847o284021ffpf59aba25c3630bd3@mail.gmail.com>	
	<4913AF46.9060700@gmx.net>
	<e19d85410811061904l1d815fefg58a29e91e62ff674@mail.gmail.com>
Message-ID: <4913B4E2.6030504@gmx.net>

On 07.11.2008 04:04, Elia Yehuda wrote:
> On Fri, Nov 7, 2008 at 5:00 AM, Carl-Daniel Hailfinger <
> c-d.hailfinger.devel.2006 at gmx.net> wrote:
>
>   
>> On 07.11.2008 03:47, Elia Yehuda wrote:
>>     
>>> Signed-off-by: Elia Yehuda <z4ziggy at gmail.com>
>>>
>>>       
>> A small changelog (2 lines or so, more if you like) would be appreciated.
>>     
>
>
>
> ok, i thought the title was informative enough... i'll try harder next
> time!!! :-)
>   

Rough guideline for changelogs is:
- Keep them in the mail body.
- Make sure that someone only reading the changelog (and not the code)
knows what's going on.

"Not-matched vendor/device id" can be anything. Please mention that this
is about PCI ROMs and that the mismatch occurs between the vendor and
device ID stored in the ROM and the PCI vendor and device ID of the
corresponding PCI device.


>>> Index: src/devices/pci_rom.c
>>> ===================================================================
>>> --- src/devices/pci_rom.c    (revision 3698)
>>> +++ src/devices/pci_rom.c    (working copy)
>>> @@ -67,8 +67,10 @@
>>>      printk_spew("PCI ROM Image, Vendor %04x, Device %04x,\n",
>>>              rom_data->vendor, rom_data->device);
>>>      if (dev->vendor != rom_data->vendor || dev->device !=
>>>       
>> rom_data->device)
>>     
>>> {
>>> -        printk_err("Device or Vendor ID mismatch Vendor %04x, Device
>>> %04x\n",
>>> -               rom_data->vendor, rom_data->device);
>>> +        printk_err("Device or Vendor ID mismatch Vendor %04x, Device
>>>       
>> %04x "
>>     
>>> +               "(Vendor %04x, Device %04x)\n",
>>> +               rom_data->vendor, rom_data->device,
>>> +               dev->vendor, dev->device);
>>>          return NULL;
>>>      }
>>>
>>>       
>> The patch was mangled by gmail. AFAIK that's an unfixable bug with the
>> gmail web interface. Please attach the patch instead.
>>     
>
> will do
>   

Thanks.


>> About the contents of the patch: The new message still requires people
>> to read the source code. How about:
>> "Device or Vendor ID mismatch: read Vendor %04x, Device %04x, expected
>> Vendor %04x, Device %04x\n"
>>     
>
> such a long line breaks the 80 column boundary. is that ok?
>   

Of course you can break the line. My point was more about the message
itself than cosmetic linebreaks.

Regards.
Carl-Daniel

-- 
http://www.hailfinger.org/




From c-d.hailfinger.devel.2006 at gmx.net  Fri Nov  7 04:26:57 2008
From: c-d.hailfinger.devel.2006 at gmx.net (Carl-Daniel Hailfinger)
Date: Fri, 07 Nov 2008 04:26:57 +0100
Subject: [coreboot] SeaBIOS question and cross compilation fix.
In-Reply-To: <20081107031831.GA31576@morn.localdomain>
References: <49130685.7030804@coresystems.de>	<20081107001052.GA31143@morn.localdomain>	<4913892A.6080203@coresystems.de>	<20081107010218.GB31308@morn.localdomain>	<4913976A.5070300@coresystems.de>
	<20081107031831.GA31576@morn.localdomain>
Message-ID: <4913B581.50502@gmx.net>

On 07.11.2008 04:18, Kevin O'Connor wrote:
> On Fri, Nov 07, 2008 at 02:18:34AM +0100, Stefan Reinauer wrote:
>   
>> Kevin O'Connor wrote:
>>     
>>> On Fri, Nov 07, 2008 at 01:17:46AM +0100, Stefan Reinauer wrote:
>>>       
>>>>> BTW, in previous emails I highlighted some disadvantages with a
>>>>> tighter integration of seabios and coreboot.  Could you elaborate on
>>>>> the reasons why you think this is the best option?
>>>>>       
>>>>>           
>>>> Simple:
>>>>         
> [...]
>
> Thanks Stefan.  I appreciate your feedback.
>
> One random comment:
>
>   
>>> and we
>>> can avoid having to return from seabios to coreboot and thus not have
>>> to worry abou them "stomping" on each other.
>>>   
>>>       
>> We do have to worry about that in all scenarios though.
>>
>> Just assuming it's ok for SeaBIOS to overwrite memory that coreboot
>> filled is not good enough.
>>     
>
> I'm more worried about the option roms corrupting memory that coreboot
> uses.
>   

Checksums of coreboot memory before and after option rom execution could
help.

Regards,
Carl-Daniel

-- 
http://www.hailfinger.org/




From z4ziggy at gmail.com  Fri Nov  7 04:27:09 2008
From: z4ziggy at gmail.com (Elia Yehuda)
Date: Fri, 7 Nov 2008 05:27:09 +0200
Subject: [coreboot] fixing i810 onboard vga
In-Reply-To: <4927aaf7fa34a9c03b51b9ec13a8ffe1@imap.1and1.com>
References: <e19d85410811061038x5e9f054ft4ec3b1b93efd029e@mail.gmail.com>
	<55ef48fb3f569a3424087cb7ba0852d5@imap.1and1.com>
	<e19d85410811061719v37a9a0f2kcc143cf8d1600e11@mail.gmail.com>
	<7988291d03369b53d8680e7df147eb6f@imap.1and1.com>
	<e19d85410811061824j8fe0153ge3f4b085f1d3814f@mail.gmail.com>
	<be2a65ba6edb920bf55d999cb7d2f0de@imap.1and1.com>
	<e19d85410811061855i3ca4c59fpf2546873a05233b2@mail.gmail.com>
	<4927aaf7fa34a9c03b51b9ec13a8ffe1@imap.1and1.com>
Message-ID: <e19d85410811061927g5ac26535m9e4d9e58b0a4a0a1@mail.gmail.com>

thanks for the suggestion - ive added
#define PCI_DEVICE_ID_INTEL_82810E_IG   0x7125

to src/include/device/pci_ids.h but still no luck :

rom address for PCI: 00:01.0 = fffc0000
PCI Expansion ROM, signature 0xaa55, INIT size 0xa000, data ptr 0x0110
PCI ROM Image, Vendor 8086, Device 0000,
Device or Vendor ID mismatch Vendor 8086, Device 0000 (Expected Vendor 8086,
Device 7125)

im guessing the device_id needs to be declated somewhere in the code or
maybe in the Config.lb?

Regards,
Elia.

On Fri, Nov 7, 2008 at 5:06 AM, Joseph Smith <joe at settoplinux.org> wrote:

>
>
>
> On Fri, 7 Nov 2008 04:55:41 +0200, "Elia Yehuda" <z4ziggy at gmail.com>
> wrote:
> > yep, ive extraced my vga using awardeco which should be fine (and it does
> > seems fine on the lspci -n, which is very frustrating)
> >
> > On Fri, Nov 7, 2008 at 4:48 AM, Joseph Smith <joe at settoplinux.org>
> wrote:
> >
> >>
> >>
> >>
> >> On Fri, 7 Nov 2008 04:24:38 +0200, "Elia Yehuda" <z4ziggy at gmail.com>
> >> wrote:
> >> > tnx Joseph,
> >> >
> >> > i've fixed the following (to match my 256kb bios) :
> >> >
> >> >   device pci_domain 0 on
> >> >
> >> >       device pci 0.0 on end            # Host bridge
> >> >         chip drivers/pci/onboard
> >> >           device pci 1.0 on end            # Onboard video
> >> >           register "rom_address" = "0xfffc0000"
> >> >       end
> >> >   ...
> >> >   end
> >> >
> >> > and now the rom_address is set AND i see the device in lspci :
> >> > lspci:
> >> > 00:01.0 VGA compatible controller: Intel Corporation 82810E DC-133
> > (CGC)
> >> > Chipset Graphics Controller (rev 03)
> >> > lspci -n:
> >> > 00:01.0 0300: 8086:7125 (rev 03)
> >> >
> >> > but still no vga-output!
> >> > i found the following to might suggest another problem :
> >> >
> >> > PCI Expansion ROM, signature 0xaa55, INIT size 0xa000, data ptr 0x0110
> >> > PCI ROM Image, Vendor 8086, Device 0000,
> >> > Device or Vendor ID mismatch Vendor 8086, Device 0000
> >> >
> >> > and no "copying VGA ROM Image"...
> >> Yep that is your problem. Is there something wrong with your vga bios.
> > It
> >> is reading the vendor id ok but the device id should be 7125.
> >> Have you checked this out? It may help you to get a valid vga bios.
> >> http://www.coreboot.org/VGA_support
> >>
> coreboot uses a different pci.ids file than Linux. That's why Linux can
> find it but coreboot can't? Check and see if the coreboot pci.ids file
> includes 8086 / 7125. It may be missing and just needs to be added?
>
> --
> Thanks,
> Joseph Smith
> Set-Top-Linux
> www.settoplinux.org
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20081107/ca3e5982/attachment.html>

From corey.osgood at gmail.com  Fri Nov  7 04:29:57 2008
From: corey.osgood at gmail.com (Corey Osgood)
Date: Thu, 6 Nov 2008 22:29:57 -0500
Subject: [coreboot] fixing i810 onboard vga
In-Reply-To: <4927aaf7fa34a9c03b51b9ec13a8ffe1@imap.1and1.com>
References: <e19d85410811061038x5e9f054ft4ec3b1b93efd029e@mail.gmail.com>
	<55ef48fb3f569a3424087cb7ba0852d5@imap.1and1.com>
	<e19d85410811061719v37a9a0f2kcc143cf8d1600e11@mail.gmail.com>
	<7988291d03369b53d8680e7df147eb6f@imap.1and1.com>
	<e19d85410811061824j8fe0153ge3f4b085f1d3814f@mail.gmail.com>
	<be2a65ba6edb920bf55d999cb7d2f0de@imap.1and1.com>
	<e19d85410811061855i3ca4c59fpf2546873a05233b2@mail.gmail.com>
	<4927aaf7fa34a9c03b51b9ec13a8ffe1@imap.1and1.com>
Message-ID: <dd3c80060811061929y775a8c45le5af2a5d58e7d7bf@mail.gmail.com>

IIRC, there's some bit in the i810 that changes the device ID, for whatever
nefarious purpose. The datasheet is freely available on intel.com (search
for "82810 datasheet"), I'd check for you but there's a storm here and my
internet connection keeps cutting out.

-Corey

On Thu, Nov 6, 2008 at 10:06 PM, Joseph Smith <joe at settoplinux.org> wrote:

>
>
>
> On Fri, 7 Nov 2008 04:55:41 +0200, "Elia Yehuda" <z4ziggy at gmail.com>
> wrote:
> > yep, ive extraced my vga using awardeco which should be fine (and it does
> > seems fine on the lspci -n, which is very frustrating)
> >
> > On Fri, Nov 7, 2008 at 4:48 AM, Joseph Smith <joe at settoplinux.org>
> wrote:
> >
> >>
> >>
> >>
> >> On Fri, 7 Nov 2008 04:24:38 +0200, "Elia Yehuda" <z4ziggy at gmail.com>
> >> wrote:
> >> > tnx Joseph,
> >> >
> >> > i've fixed the following (to match my 256kb bios) :
> >> >
> >> >   device pci_domain 0 on
> >> >
> >> >       device pci 0.0 on end            # Host bridge
> >> >         chip drivers/pci/onboard
> >> >           device pci 1.0 on end            # Onboard video
> >> >           register "rom_address" = "0xfffc0000"
> >> >       end
> >> >   ...
> >> >   end
> >> >
> >> > and now the rom_address is set AND i see the device in lspci :
> >> > lspci:
> >> > 00:01.0 VGA compatible controller: Intel Corporation 82810E DC-133
> > (CGC)
> >> > Chipset Graphics Controller (rev 03)
> >> > lspci -n:
> >> > 00:01.0 0300: 8086:7125 (rev 03)
> >> >
> >> > but still no vga-output!
> >> > i found the following to might suggest another problem :
> >> >
> >> > PCI Expansion ROM, signature 0xaa55, INIT size 0xa000, data ptr 0x0110
> >> > PCI ROM Image, Vendor 8086, Device 0000,
> >> > Device or Vendor ID mismatch Vendor 8086, Device 0000
> >> >
> >> > and no "copying VGA ROM Image"...
> >> Yep that is your problem. Is there something wrong with your vga bios.
> > It
> >> is reading the vendor id ok but the device id should be 7125.
> >> Have you checked this out? It may help you to get a valid vga bios.
> >> http://www.coreboot.org/VGA_support
> >>
> coreboot uses a different pci.ids file than Linux. That's why Linux can
> find it but coreboot can't? Check and see if the coreboot pci.ids file
> includes 8086 / 7125. It may be missing and just needs to be added?
>
> --
> Thanks,
> Joseph Smith
> Set-Top-Linux
> www.settoplinux.org
>
>
> --
> coreboot mailing list: coreboot at coreboot.org
> http://www.coreboot.org/mailman/listinfo/coreboot
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20081106/33eb7407/attachment.html>

From corey.osgood at gmail.com  Fri Nov  7 04:37:19 2008
From: corey.osgood at gmail.com (Corey Osgood)
Date: Thu, 6 Nov 2008 22:37:19 -0500
Subject: [coreboot] fixing i810 onboard vga
In-Reply-To: <e19d85410811061927g5ac26535m9e4d9e58b0a4a0a1@mail.gmail.com>
References: <e19d85410811061038x5e9f054ft4ec3b1b93efd029e@mail.gmail.com>
	<55ef48fb3f569a3424087cb7ba0852d5@imap.1and1.com>
	<e19d85410811061719v37a9a0f2kcc143cf8d1600e11@mail.gmail.com>
	<7988291d03369b53d8680e7df147eb6f@imap.1and1.com>
	<e19d85410811061824j8fe0153ge3f4b085f1d3814f@mail.gmail.com>
	<be2a65ba6edb920bf55d999cb7d2f0de@imap.1and1.com>
	<e19d85410811061855i3ca4c59fpf2546873a05233b2@mail.gmail.com>
	<4927aaf7fa34a9c03b51b9ec13a8ffe1@imap.1and1.com>
	<e19d85410811061927g5ac26535m9e4d9e58b0a4a0a1@mail.gmail.com>
Message-ID: <dd3c80060811061937p11efec93meed88ae29f2421eb@mail.gmail.com>

On Thu, Nov 6, 2008 at 10:27 PM, Elia Yehuda <z4ziggy at gmail.com> wrote:

>
> thanks for the suggestion - ive added
> #define PCI_DEVICE_ID_INTEL_82810E_IG   0x7125
>
> to src/include/device/pci_ids.h but still no luck :
>
> rom address for PCI: 00:01.0 = fffc0000
> PCI Expansion ROM, signature 0xaa55, INIT size 0xa000, data ptr 0x0110
> PCI ROM Image, Vendor 8086, Device 0000,
> Device or Vendor ID mismatch Vendor 8086, Device 0000 (Expected Vendor
> 8086, Device 7125)
>
> im guessing the device_id needs to be declated somewhere in the code or
> maybe in the Config.lb?
>

Huh? Where is the device ID of 0000 coming from? It's been a while since
I've been in that part of v2, but it looks like it's coming from the rom
itself. If that's the case, can you hack pci_rom.c to ignore the device ID
and run the rom anyway?

-Corey


>
>
> Regards,
> Elia.
>
>
> On Fri, Nov 7, 2008 at 5:06 AM, Joseph Smith <joe at settoplinux.org> wrote:
>
>>
>>
>>
>> On Fri, 7 Nov 2008 04:55:41 +0200, "Elia Yehuda" <z4ziggy at gmail.com>
>> wrote:
>> > yep, ive extraced my vga using awardeco which should be fine (and it
>> does
>> > seems fine on the lspci -n, which is very frustrating)
>> >
>> > On Fri, Nov 7, 2008 at 4:48 AM, Joseph Smith <joe at settoplinux.org>
>> wrote:
>> >
>> >>
>> >>
>> >>
>> >> On Fri, 7 Nov 2008 04:24:38 +0200, "Elia Yehuda" <z4ziggy at gmail.com>
>> >> wrote:
>> >> > tnx Joseph,
>> >> >
>> >> > i've fixed the following (to match my 256kb bios) :
>> >> >
>> >> >   device pci_domain 0 on
>> >> >
>> >> >       device pci 0.0 on end            # Host bridge
>> >> >         chip drivers/pci/onboard
>> >> >           device pci 1.0 on end            # Onboard video
>> >> >           register "rom_address" = "0xfffc0000"
>> >> >       end
>> >> >   ...
>> >> >   end
>> >> >
>> >> > and now the rom_address is set AND i see the device in lspci :
>> >> > lspci:
>> >> > 00:01.0 VGA compatible controller: Intel Corporation 82810E DC-133
>> > (CGC)
>> >> > Chipset Graphics Controller (rev 03)
>> >> > lspci -n:
>> >> > 00:01.0 0300: 8086:7125 (rev 03)
>> >> >
>> >> > but still no vga-output!
>> >> > i found the following to might suggest another problem :
>> >> >
>> >> > PCI Expansion ROM, signature 0xaa55, INIT size 0xa000, data ptr
>> 0x0110
>> >> > PCI ROM Image, Vendor 8086, Device 0000,
>> >> > Device or Vendor ID mismatch Vendor 8086, Device 0000
>> >> >
>> >> > and no "copying VGA ROM Image"...
>> >> Yep that is your problem. Is there something wrong with your vga bios.
>> > It
>> >> is reading the vendor id ok but the device id should be 7125.
>> >> Have you checked this out? It may help you to get a valid vga bios.
>> >> http://www.coreboot.org/VGA_support
>> >>
>> coreboot uses a different pci.ids file than Linux. That's why Linux can
>> find it but coreboot can't? Check and see if the coreboot pci.ids file
>> includes 8086 / 7125. It may be missing and just needs to be added?
>>
>> --
>> Thanks,
>> Joseph Smith
>> Set-Top-Linux
>> www.settoplinux.org
>>
>>
>
> --
> coreboot mailing list: coreboot at coreboot.org
> http://www.coreboot.org/mailman/listinfo/coreboot
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20081106/68aa40f5/attachment.html>

From z4ziggy at gmail.com  Fri Nov  7 04:46:09 2008
From: z4ziggy at gmail.com (Elia Yehuda)
Date: Fri, 7 Nov 2008 05:46:09 +0200
Subject: [coreboot] fixing i810 onboard vga
In-Reply-To: <dd3c80060811061937p11efec93meed88ae29f2421eb@mail.gmail.com>
References: <e19d85410811061038x5e9f054ft4ec3b1b93efd029e@mail.gmail.com>
	<55ef48fb3f569a3424087cb7ba0852d5@imap.1and1.com>
	<e19d85410811061719v37a9a0f2kcc143cf8d1600e11@mail.gmail.com>
	<7988291d03369b53d8680e7df147eb6f@imap.1and1.com>
	<e19d85410811061824j8fe0153ge3f4b085f1d3814f@mail.gmail.com>
	<be2a65ba6edb920bf55d999cb7d2f0de@imap.1and1.com>
	<e19d85410811061855i3ca4c59fpf2546873a05233b2@mail.gmail.com>
	<4927aaf7fa34a9c03b51b9ec13a8ffe1@imap.1and1.com>
	<e19d85410811061927g5ac26535m9e4d9e58b0a4a0a1@mail.gmail.com>
	<dd3c80060811061937p11efec93meed88ae29f2421eb@mail.gmail.com>
Message-ID: <e19d85410811061946h633e3607q592bcbc471ae8bfb@mail.gmail.com>

found the problem - its my buggy vga.rom!!! it's missing the damn device_id!

ive patched it, and now the screen turns on upon boot, but no messages.
however....
once i "modprobe i810fb" from the serial console, look and be-hold - we've
got onboard-vga working!

many thanks, now if we can figure out why it wont display upon bootup it
will be great.

also, another thing which troubles me - BEFORE booting begins, there are
0x00 sent to the serial for about 2 minutes (i've counted about 80 o those
0x00 being sent) and only then the coreboot messages starts to appear and
the boot continues. i would appreciate eliminating this 2 minutes delay...
any relevant information would be appreciated.

Regards,
Elia.


On Fri, Nov 7, 2008 at 5:37 AM, Corey Osgood <corey.osgood at gmail.com> wrote:

> On Thu, Nov 6, 2008 at 10:27 PM, Elia Yehuda <z4ziggy at gmail.com> wrote:
>
>>
>> thanks for the suggestion - ive added
>> #define PCI_DEVICE_ID_INTEL_82810E_IG   0x7125
>>
>> to src/include/device/pci_ids.h but still no luck :
>>
>> rom address for PCI: 00:01.0 = fffc0000
>> PCI Expansion ROM, signature 0xaa55, INIT size 0xa000, data ptr 0x0110
>> PCI ROM Image, Vendor 8086, Device 0000,
>> Device or Vendor ID mismatch Vendor 8086, Device 0000 (Expected Vendor
>> 8086, Device 7125)
>>
>> im guessing the device_id needs to be declated somewhere in the code or
>> maybe in the Config.lb?
>>
>
> Huh? Where is the device ID of 0000 coming from? It's been a while since
> I've been in that part of v2, but it looks like it's coming from the rom
> itself. If that's the case, can you hack pci_rom.c to ignore the device ID
> and run the rom anyway?
>
> -Corey
>
>
>>
>>
>> Regards,
>> Elia.
>>
>>
>> On Fri, Nov 7, 2008 at 5:06 AM, Joseph Smith <joe at settoplinux.org> wrote:
>>
>>>
>>>
>>>
>>> On Fri, 7 Nov 2008 04:55:41 +0200, "Elia Yehuda" <z4ziggy at gmail.com>
>>> wrote:
>>> > yep, ive extraced my vga using awardeco which should be fine (and it
>>> does
>>> > seems fine on the lspci -n, which is very frustrating)
>>> >
>>> > On Fri, Nov 7, 2008 at 4:48 AM, Joseph Smith <joe at settoplinux.org>
>>> wrote:
>>> >
>>> >>
>>> >>
>>> >>
>>> >> On Fri, 7 Nov 2008 04:24:38 +0200, "Elia Yehuda" <z4ziggy at gmail.com>
>>> >> wrote:
>>> >> > tnx Joseph,
>>> >> >
>>> >> > i've fixed the following (to match my 256kb bios) :
>>> >> >
>>> >> >   device pci_domain 0 on
>>> >> >
>>> >> >       device pci 0.0 on end            # Host bridge
>>> >> >         chip drivers/pci/onboard
>>> >> >           device pci 1.0 on end            # Onboard video
>>> >> >           register "rom_address" = "0xfffc0000"
>>> >> >       end
>>> >> >   ...
>>> >> >   end
>>> >> >
>>> >> > and now the rom_address is set AND i see the device in lspci :
>>> >> > lspci:
>>> >> > 00:01.0 VGA compatible controller: Intel Corporation 82810E DC-133
>>> > (CGC)
>>> >> > Chipset Graphics Controller (rev 03)
>>> >> > lspci -n:
>>> >> > 00:01.0 0300: 8086:7125 (rev 03)
>>> >> >
>>> >> > but still no vga-output!
>>> >> > i found the following to might suggest another problem :
>>> >> >
>>> >> > PCI Expansion ROM, signature 0xaa55, INIT size 0xa000, data ptr
>>> 0x0110
>>> >> > PCI ROM Image, Vendor 8086, Device 0000,
>>> >> > Device or Vendor ID mismatch Vendor 8086, Device 0000
>>> >> >
>>> >> > and no "copying VGA ROM Image"...
>>> >> Yep that is your problem. Is there something wrong with your vga bios.
>>> > It
>>> >> is reading the vendor id ok but the device id should be 7125.
>>> >> Have you checked this out? It may help you to get a valid vga bios.
>>> >> http://www.coreboot.org/VGA_support
>>> >>
>>> coreboot uses a different pci.ids file than Linux. That's why Linux can
>>> find it but coreboot can't? Check and see if the coreboot pci.ids file
>>> includes 8086 / 7125. It may be missing and just needs to be added?
>>>
>>> --
>>> Thanks,
>>> Joseph Smith
>>> Set-Top-Linux
>>> www.settoplinux.org
>>>
>>>
>>
>> --
>> coreboot mailing list: coreboot at coreboot.org
>> http://www.coreboot.org/mailman/listinfo/coreboot
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20081107/56326a75/attachment.html>

From z4ziggy at gmail.com  Fri Nov  7 05:12:08 2008
From: z4ziggy at gmail.com (Elia Yehuda)
Date: Fri, 7 Nov 2008 06:12:08 +0200
Subject: [coreboot] [patch] add required info to not-matched
	vendor/device id
In-Reply-To: <4913B4E2.6030504@gmx.net>
References: <e19d85410811061847o284021ffpf59aba25c3630bd3@mail.gmail.com>
	<4913AF46.9060700@gmx.net>
	<e19d85410811061904l1d815fefg58a29e91e62ff674@mail.gmail.com>
	<4913B4E2.6030504@gmx.net>
Message-ID: <e19d85410811062012h12bbf95cic730ecb3933bf4ec@mail.gmail.com>

Signed-off-by: Elia Yehuda <z4ziggy at gmail.com>

This patch adds information in printk_err() about which vendor/device id
mismatches to which expected
vendor/device on pci_rom_probe().

Regards,
Elia.

On Fri, Nov 7, 2008 at 5:24 AM, Carl-Daniel Hailfinger <
c-d.hailfinger.devel.2006 at gmx.net> wrote:

> On 07.11.2008 04:04, Elia Yehuda wrote:
> > On Fri, Nov 7, 2008 at 5:00 AM, Carl-Daniel Hailfinger <
> > c-d.hailfinger.devel.2006 at gmx.net> wrote:
> >
> >
> >> On 07.11.2008 03:47, Elia Yehuda wrote:
> >>
> >>> Signed-off-by: Elia Yehuda <z4ziggy at gmail.com>
> >>>
> >>>
> >> A small changelog (2 lines or so, more if you like) would be
> appreciated.
> >>
> >
> >
> >
> > ok, i thought the title was informative enough... i'll try harder next
> > time!!! :-)
> >
>
> Rough guideline for changelogs is:
> - Keep them in the mail body.
> - Make sure that someone only reading the changelog (and not the code)
> knows what's going on.
>
> "Not-matched vendor/device id" can be anything. Please mention that this
> is about PCI ROMs and that the mismatch occurs between the vendor and
> device ID stored in the ROM and the PCI vendor and device ID of the
> corresponding PCI device.
>
>
> >>> Index: src/devices/pci_rom.c
> >>> ===================================================================
> >>> --- src/devices/pci_rom.c    (revision 3698)
> >>> +++ src/devices/pci_rom.c    (working copy)
> >>> @@ -67,8 +67,10 @@
> >>>      printk_spew("PCI ROM Image, Vendor %04x, Device %04x,\n",
> >>>              rom_data->vendor, rom_data->device);
> >>>      if (dev->vendor != rom_data->vendor || dev->device !=
> >>>
> >> rom_data->device)
> >>
> >>> {
> >>> -        printk_err("Device or Vendor ID mismatch Vendor %04x, Device
> >>> %04x\n",
> >>> -               rom_data->vendor, rom_data->device);
> >>> +        printk_err("Device or Vendor ID mismatch Vendor %04x, Device
> >>>
> >> %04x "
> >>
> >>> +               "(Vendor %04x, Device %04x)\n",
> >>> +               rom_data->vendor, rom_data->device,
> >>> +               dev->vendor, dev->device);
> >>>          return NULL;
> >>>      }
> >>>
> >>>
> >> The patch was mangled by gmail. AFAIK that's an unfixable bug with the
> >> gmail web interface. Please attach the patch instead.
> >>
> >
> > will do
> >
>
> Thanks.
>
>
> >> About the contents of the patch: The new message still requires people
> >> to read the source code. How about:
> >> "Device or Vendor ID mismatch: read Vendor %04x, Device %04x, expected
> >> Vendor %04x, Device %04x\n"
> >>
> >
> > such a long line breaks the 80 column boundary. is that ok?
> >
>
> Of course you can break the line. My point was more about the message
> itself than cosmetic linebreaks.
>
> Regards.
> Carl-Daniel
>
> --
> http://www.hailfinger.org/
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20081107/80b6886c/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: pci_rom.c.patch
Type: text/x-patch
Size: 737 bytes
Desc: not available
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20081107/80b6886c/attachment.patch>

From corey.osgood at gmail.com  Fri Nov  7 06:51:36 2008
From: corey.osgood at gmail.com (Corey Osgood)
Date: Fri, 7 Nov 2008 00:51:36 -0500
Subject: [coreboot] fixing i810 onboard vga
In-Reply-To: <e19d85410811061946h633e3607q592bcbc471ae8bfb@mail.gmail.com>
References: <e19d85410811061038x5e9f054ft4ec3b1b93efd029e@mail.gmail.com>
	<e19d85410811061719v37a9a0f2kcc143cf8d1600e11@mail.gmail.com>
	<7988291d03369b53d8680e7df147eb6f@imap.1and1.com>
	<e19d85410811061824j8fe0153ge3f4b085f1d3814f@mail.gmail.com>
	<be2a65ba6edb920bf55d999cb7d2f0de@imap.1and1.com>
	<e19d85410811061855i3ca4c59fpf2546873a05233b2@mail.gmail.com>
	<4927aaf7fa34a9c03b51b9ec13a8ffe1@imap.1and1.com>
	<e19d85410811061927g5ac26535m9e4d9e58b0a4a0a1@mail.gmail.com>
	<dd3c80060811061937p11efec93meed88ae29f2421eb@mail.gmail.com>
	<e19d85410811061946h633e3607q592bcbc471ae8bfb@mail.gmail.com>
Message-ID: <dd3c80060811062151r1638aeaala5c78c970b1759c1@mail.gmail.com>

When exactly do those 0x0s get sent? Before ram initialization starts?
Before the initial banner is sent? Before the payload is executed? "before
booting" can mean a lot of things ;)

-Corey

On Thu, Nov 6, 2008 at 10:46 PM, Elia Yehuda <z4ziggy at gmail.com> wrote:

> found the problem - its my buggy vga.rom!!! it's missing the damn
> device_id!
>
> ive patched it, and now the screen turns on upon boot, but no messages.
> however....
> once i "modprobe i810fb" from the serial console, look and be-hold - we've
> got onboard-vga working!
>
> many thanks, now if we can figure out why it wont display upon bootup it
> will be great.
>
> also, another thing which troubles me - BEFORE booting begins, there are
> 0x00 sent to the serial for about 2 minutes (i've counted about 80 o those
> 0x00 being sent) and only then the coreboot messages starts to appear and
> the boot continues. i would appreciate eliminating this 2 minutes delay...
> any relevant information would be appreciated.
>
> Regards,
> Elia.
>
>
>
> On Fri, Nov 7, 2008 at 5:37 AM, Corey Osgood <corey.osgood at gmail.com>wrote:
>
>> On Thu, Nov 6, 2008 at 10:27 PM, Elia Yehuda <z4ziggy at gmail.com> wrote:
>>
>>>
>>> thanks for the suggestion - ive added
>>> #define PCI_DEVICE_ID_INTEL_82810E_IG   0x7125
>>>
>>> to src/include/device/pci_ids.h but still no luck :
>>>
>>> rom address for PCI: 00:01.0 = fffc0000
>>> PCI Expansion ROM, signature 0xaa55, INIT size 0xa000, data ptr 0x0110
>>> PCI ROM Image, Vendor 8086, Device 0000,
>>> Device or Vendor ID mismatch Vendor 8086, Device 0000 (Expected Vendor
>>> 8086, Device 7125)
>>>
>>> im guessing the device_id needs to be declated somewhere in the code or
>>> maybe in the Config.lb?
>>>
>>
>> Huh? Where is the device ID of 0000 coming from? It's been a while since
>> I've been in that part of v2, but it looks like it's coming from the rom
>> itself. If that's the case, can you hack pci_rom.c to ignore the device ID
>> and run the rom anyway?
>>
>> -Corey
>>
>>
>>>
>>>
>>> Regards,
>>> Elia.
>>>
>>>
>>> On Fri, Nov 7, 2008 at 5:06 AM, Joseph Smith <joe at settoplinux.org>wrote:
>>>
>>>>
>>>>
>>>>
>>>> On Fri, 7 Nov 2008 04:55:41 +0200, "Elia Yehuda" <z4ziggy at gmail.com>
>>>> wrote:
>>>> > yep, ive extraced my vga using awardeco which should be fine (and it
>>>> does
>>>> > seems fine on the lspci -n, which is very frustrating)
>>>> >
>>>> > On Fri, Nov 7, 2008 at 4:48 AM, Joseph Smith <joe at settoplinux.org>
>>>> wrote:
>>>> >
>>>> >>
>>>> >>
>>>> >>
>>>> >> On Fri, 7 Nov 2008 04:24:38 +0200, "Elia Yehuda" <z4ziggy at gmail.com>
>>>> >> wrote:
>>>> >> > tnx Joseph,
>>>> >> >
>>>> >> > i've fixed the following (to match my 256kb bios) :
>>>> >> >
>>>> >> >   device pci_domain 0 on
>>>> >> >
>>>> >> >       device pci 0.0 on end            # Host bridge
>>>> >> >         chip drivers/pci/onboard
>>>> >> >           device pci 1.0 on end            # Onboard video
>>>> >> >           register "rom_address" = "0xfffc0000"
>>>> >> >       end
>>>> >> >   ...
>>>> >> >   end
>>>> >> >
>>>> >> > and now the rom_address is set AND i see the device in lspci :
>>>> >> > lspci:
>>>> >> > 00:01.0 VGA compatible controller: Intel Corporation 82810E DC-133
>>>> > (CGC)
>>>> >> > Chipset Graphics Controller (rev 03)
>>>> >> > lspci -n:
>>>> >> > 00:01.0 0300: 8086:7125 (rev 03)
>>>> >> >
>>>> >> > but still no vga-output!
>>>> >> > i found the following to might suggest another problem :
>>>> >> >
>>>> >> > PCI Expansion ROM, signature 0xaa55, INIT size 0xa000, data ptr
>>>> 0x0110
>>>> >> > PCI ROM Image, Vendor 8086, Device 0000,
>>>> >> > Device or Vendor ID mismatch Vendor 8086, Device 0000
>>>> >> >
>>>> >> > and no "copying VGA ROM Image"...
>>>> >> Yep that is your problem. Is there something wrong with your vga
>>>> bios.
>>>> > It
>>>> >> is reading the vendor id ok but the device id should be 7125.
>>>> >> Have you checked this out? It may help you to get a valid vga bios.
>>>> >> http://www.coreboot.org/VGA_support
>>>> >>
>>>> coreboot uses a different pci.ids file than Linux. That's why Linux can
>>>> find it but coreboot can't? Check and see if the coreboot pci.ids file
>>>> includes 8086 / 7125. It may be missing and just needs to be added?
>>>>
>>>> --
>>>> Thanks,
>>>> Joseph Smith
>>>> Set-Top-Linux
>>>> www.settoplinux.org
>>>>
>>>>
>>>
>>> --
>>> coreboot mailing list: coreboot at coreboot.org
>>> http://www.coreboot.org/mailman/listinfo/coreboot
>>>
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20081107/08004e84/attachment.html>

From z4ziggy at gmail.com  Fri Nov  7 07:00:36 2008
From: z4ziggy at gmail.com (Elia Yehuda)
Date: Fri, 7 Nov 2008 08:00:36 +0200
Subject: [coreboot] fixing i810 onboard vga
In-Reply-To: <dd3c80060811062151r1638aeaala5c78c970b1759c1@mail.gmail.com>
References: <e19d85410811061038x5e9f054ft4ec3b1b93efd029e@mail.gmail.com>
	<7988291d03369b53d8680e7df147eb6f@imap.1and1.com>
	<e19d85410811061824j8fe0153ge3f4b085f1d3814f@mail.gmail.com>
	<be2a65ba6edb920bf55d999cb7d2f0de@imap.1and1.com>
	<e19d85410811061855i3ca4c59fpf2546873a05233b2@mail.gmail.com>
	<4927aaf7fa34a9c03b51b9ec13a8ffe1@imap.1and1.com>
	<e19d85410811061927g5ac26535m9e4d9e58b0a4a0a1@mail.gmail.com>
	<dd3c80060811061937p11efec93meed88ae29f2421eb@mail.gmail.com>
	<e19d85410811061946h633e3607q592bcbc471ae8bfb@mail.gmail.com>
	<dd3c80060811062151r1638aeaala5c78c970b1759c1@mail.gmail.com>
Message-ID: <e19d85410811062200k40a9c07cncdaabc668ba9aca9@mail.gmail.com>

before anything else :-)
right when i turn on the pc, those zeros (0x00) starts to show on the screen
(i use gtkterm in hexmode since minicom wont show me those hexed zeros),
fill the screen slowly for 2 minutes, and only then the following coreboot
messages shows up and the boot starts :

coreboot-2.0.0.0Fallback Fri Nov  7 04:00:16 IST 2008 starting...
Ram1.00
i810 Initial registers have been set.
Ram2.00
...

so, to sum it up -
turn on computer
zeors on the screen for 2 minutes
coreboot starts

hope this clears matters up ;)

Regards,
Elia.

On Fri, Nov 7, 2008 at 7:51 AM, Corey Osgood <corey.osgood at gmail.com> wrote:

> When exactly do those 0x0s get sent? Before ram initialization starts?
> Before the initial banner is sent? Before the payload is executed? "before
> booting" can mean a lot of things ;)
>
> -Corey
>
>
> On Thu, Nov 6, 2008 at 10:46 PM, Elia Yehuda <z4ziggy at gmail.com> wrote:
>
>> found the problem - its my buggy vga.rom!!! it's missing the damn
>> device_id!
>>
>> ive patched it, and now the screen turns on upon boot, but no messages.
>> however....
>> once i "modprobe i810fb" from the serial console, look and be-hold - we've
>> got onboard-vga working!
>>
>> many thanks, now if we can figure out why it wont display upon bootup it
>> will be great.
>>
>> also, another thing which troubles me - BEFORE booting begins, there are
>> 0x00 sent to the serial for about 2 minutes (i've counted about 80 o those
>> 0x00 being sent) and only then the coreboot messages starts to appear and
>> the boot continues. i would appreciate eliminating this 2 minutes delay...
>> any relevant information would be appreciated.
>>
>> Regards,
>> Elia.
>>
>>
>>
>> On Fri, Nov 7, 2008 at 5:37 AM, Corey Osgood <corey.osgood at gmail.com>wrote:
>>
>>> On Thu, Nov 6, 2008 at 10:27 PM, Elia Yehuda <z4ziggy at gmail.com> wrote:
>>>
>>>>
>>>> thanks for the suggestion - ive added
>>>> #define PCI_DEVICE_ID_INTEL_82810E_IG   0x7125
>>>>
>>>> to src/include/device/pci_ids.h but still no luck :
>>>>
>>>> rom address for PCI: 00:01.0 = fffc0000
>>>> PCI Expansion ROM, signature 0xaa55, INIT size 0xa000, data ptr 0x0110
>>>> PCI ROM Image, Vendor 8086, Device 0000,
>>>> Device or Vendor ID mismatch Vendor 8086, Device 0000 (Expected Vendor
>>>> 8086, Device 7125)
>>>>
>>>> im guessing the device_id needs to be declated somewhere in the code or
>>>> maybe in the Config.lb?
>>>>
>>>
>>> Huh? Where is the device ID of 0000 coming from? It's been a while since
>>> I've been in that part of v2, but it looks like it's coming from the rom
>>> itself. If that's the case, can you hack pci_rom.c to ignore the device ID
>>> and run the rom anyway?
>>>
>>> -Corey
>>>
>>>
>>>>
>>>>
>>>> Regards,
>>>> Elia.
>>>>
>>>>
>>>> On Fri, Nov 7, 2008 at 5:06 AM, Joseph Smith <joe at settoplinux.org>wrote:
>>>>
>>>>>
>>>>>
>>>>>
>>>>> On Fri, 7 Nov 2008 04:55:41 +0200, "Elia Yehuda" <z4ziggy at gmail.com>
>>>>> wrote:
>>>>> > yep, ive extraced my vga using awardeco which should be fine (and it
>>>>> does
>>>>> > seems fine on the lspci -n, which is very frustrating)
>>>>> >
>>>>> > On Fri, Nov 7, 2008 at 4:48 AM, Joseph Smith <joe at settoplinux.org>
>>>>> wrote:
>>>>> >
>>>>> >>
>>>>> >>
>>>>> >>
>>>>> >> On Fri, 7 Nov 2008 04:24:38 +0200, "Elia Yehuda" <z4ziggy at gmail.com
>>>>> >
>>>>> >> wrote:
>>>>> >> > tnx Joseph,
>>>>> >> >
>>>>> >> > i've fixed the following (to match my 256kb bios) :
>>>>> >> >
>>>>> >> >   device pci_domain 0 on
>>>>> >> >
>>>>> >> >       device pci 0.0 on end            # Host bridge
>>>>> >> >         chip drivers/pci/onboard
>>>>> >> >           device pci 1.0 on end            # Onboard video
>>>>> >> >           register "rom_address" = "0xfffc0000"
>>>>> >> >       end
>>>>> >> >   ...
>>>>> >> >   end
>>>>> >> >
>>>>> >> > and now the rom_address is set AND i see the device in lspci :
>>>>> >> > lspci:
>>>>> >> > 00:01.0 VGA compatible controller: Intel Corporation 82810E DC-133
>>>>> > (CGC)
>>>>> >> > Chipset Graphics Controller (rev 03)
>>>>> >> > lspci -n:
>>>>> >> > 00:01.0 0300: 8086:7125 (rev 03)
>>>>> >> >
>>>>> >> > but still no vga-output!
>>>>> >> > i found the following to might suggest another problem :
>>>>> >> >
>>>>> >> > PCI Expansion ROM, signature 0xaa55, INIT size 0xa000, data ptr
>>>>> 0x0110
>>>>> >> > PCI ROM Image, Vendor 8086, Device 0000,
>>>>> >> > Device or Vendor ID mismatch Vendor 8086, Device 0000
>>>>> >> >
>>>>> >> > and no "copying VGA ROM Image"...
>>>>> >> Yep that is your problem. Is there something wrong with your vga
>>>>> bios.
>>>>> > It
>>>>> >> is reading the vendor id ok but the device id should be 7125.
>>>>> >> Have you checked this out? It may help you to get a valid vga bios.
>>>>> >> http://www.coreboot.org/VGA_support
>>>>> >>
>>>>> coreboot uses a different pci.ids file than Linux. That's why Linux can
>>>>> find it but coreboot can't? Check and see if the coreboot pci.ids file
>>>>> includes 8086 / 7125. It may be missing and just needs to be added?
>>>>>
>>>>> --
>>>>> Thanks,
>>>>> Joseph Smith
>>>>> Set-Top-Linux
>>>>> www.settoplinux.org
>>>>>
>>>>>
>>>>
>>>> --
>>>> coreboot mailing list: coreboot at coreboot.org
>>>> http://www.coreboot.org/mailman/listinfo/coreboot
>>>>
>>>
>>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20081107/2ad2e982/attachment.html>

From c-d.hailfinger.devel.2006 at gmx.net  Fri Nov  7 08:46:42 2008
From: c-d.hailfinger.devel.2006 at gmx.net (Carl-Daniel Hailfinger)
Date: Fri, 07 Nov 2008 08:46:42 +0100
Subject: [coreboot] fixing i810 onboard vga
In-Reply-To: <e19d85410811062200k40a9c07cncdaabc668ba9aca9@mail.gmail.com>
References: <e19d85410811061038x5e9f054ft4ec3b1b93efd029e@mail.gmail.com>	<7988291d03369b53d8680e7df147eb6f@imap.1and1.com>	<e19d85410811061824j8fe0153ge3f4b085f1d3814f@mail.gmail.com>	<be2a65ba6edb920bf55d999cb7d2f0de@imap.1and1.com>	<e19d85410811061855i3ca4c59fpf2546873a05233b2@mail.gmail.com>	<4927aaf7fa34a9c03b51b9ec13a8ffe1@imap.1and1.com>	<e19d85410811061927g5ac26535m9e4d9e58b0a4a0a1@mail.gmail.com>	<dd3c80060811061937p11efec93meed88ae29f2421eb@mail.gmail.com>	<e19d85410811061946h633e3607q592bcbc471ae8bfb@mail.gmail.com>	<dd3c80060811062151r1638aeaala5c78c970b1759c1@mail.gmail.com>
	<e19d85410811062200k40a9c07cncdaabc668ba9aca9@mail.gmail.com>
Message-ID: <4913F262.9030202@gmx.net>

On 07.11.2008 07:00, Elia Yehuda wrote:
> before anything else :-)
> right when i turn on the pc, those zeros (0x00) starts to show on the screen
> (i use gtkterm in hexmode since minicom wont show me those hexed zeros),
> fill the screen slowly for 2 minutes, and only then the following coreboot
> messages shows up and the boot starts :
>
> coreboot-2.0.0.0Fallback Fri Nov  7 04:00:16 IST 2008 starting...
> Ram1.00
> i810 Initial registers have been set.
> Ram2.00
> ...
>
> so, to sum it up -
> turn on computer
> zeors on the screen for 2 minutes
> coreboot starts
>
> hope this clears matters up ;)
>   

That's a known bug with quite a few boards. Nobody has tracked it down
yet. You're probably the first person to notice these zeros.

Can you sprinkle POST codes liberally all over the map and note down
when the zero sending starts? Since the delay is so long, observing POST
codes on a POST card should work fine.

By the way, such a bug is much less likely to ever happen in v3.

Regards,
Carl-Daniel

-- 
http://www.hailfinger.org/




From leroi.lists at gmail.com  Fri Nov  7 13:18:12 2008
From: leroi.lists at gmail.com (Roman Yeryomin)
Date: Fri, 7 Nov 2008 14:18:12 +0200
Subject: [coreboot] alix2c3 LEDs and mode switch
In-Reply-To: <ec3a010b0811051607v2047a2ffl1a422a20967da3f0@mail.gmail.com>
References: <ec3a010b0811051607v2047a2ffl1a422a20967da3f0@mail.gmail.com>
Message-ID: <200811071418.12763.leroi.lists@gmail.com>

On Thursday 06 November 2008 02:07:46 Roman Yeryomin wrote:
> Is there any chance to get LEDs working on alix boards?
> I suppose only GPIO lines/ports should be enabled in coreboot an
> everything else is done in software.
> Here is what documentation says about them:
>
> Status LEDs are all turned on by the BIOS on power up. The BIOS will
> turn off LEDs 2 and 3
> before booting the operating system.
> Location              GPIO           read port                write port
> LED1 (left)           G6             port 06100h bit 6        port
> 06100h bit 6 / 22
> LED2 (middle)         G25            port 06180h bit 9        port
> 06180h bit 9 / 25
> LED3 (right)          G27            port 06180h bit 11       port
> 06180h bit 11 / 27
> The CS5536 GPIO ports are programmed by 32 bit atomic writes. This
> avoids the need for read /
> modify / write operations and the locking issues they entail. For
> example, to turn off LED1 (high),
> write 0000'0040h to port 06100h. To turn on LED1 (low), write
> 0040'0000h. Multiple port bits can
> be changed at the same time.
>
>
> Maybe mode switch could also be useful:
>
> The mode switch can be accessed by software as follows:
> Location              GPIO           read port
> MODESW#               G24            port 061b0h bit 8        (active
> low, 0 = switch pressed)

I tried to enable LED1 like this

    outl(GPIOL_6_SET, GPIO_IO_BASE + GPIOL_OUT_AUX1_SELECT);
    outl(GPIOL_6_SET, GPIO_IO_BASE + GPIOL_OUTPUT_ENABLE);
    outl(GPIOL_6_SET, GPIO_IO_BASE + GPIOL_IN_AUX1_SELECT);
    outl(GPIOL_6_SET, GPIO_IO_BASE + GPIOL_INPUT_ENABLE);

but this only turns on the led on bootup and gives no control on it :(
Can somebody look into this problem?


Roman



From joe at settoplinux.org  Fri Nov  7 13:29:43 2008
From: joe at settoplinux.org (Joseph Smith)
Date: Fri, 07 Nov 2008 07:29:43 -0500
Subject: [coreboot] fixing i810 onboard vga
In-Reply-To: <e19d85410811061946h633e3607q592bcbc471ae8bfb@mail.gmail.com>
References: <e19d85410811061038x5e9f054ft4ec3b1b93efd029e@mail.gmail.com>
	<55ef48fb3f569a3424087cb7ba0852d5@imap.1and1.com>
	<e19d85410811061719v37a9a0f2kcc143cf8d1600e11@mail.gmail.com>
	<7988291d03369b53d8680e7df147eb6f@imap.1and1.com>
	<e19d85410811061824j8fe0153ge3f4b085f1d3814f@mail.gmail.com>
	<be2a65ba6edb920bf55d999cb7d2f0de@imap.1and1.com>
	<e19d85410811061855i3ca4c59fpf2546873a05233b2@mail.gmail.com>
	<4927aaf7fa34a9c03b51b9ec13a8ffe1@imap.1and1.com>
	<e19d85410811061927g5ac26535m9e4d9e58b0a4a0a1@mail.gmail.com>
	<dd3c80060811061937p11efec93meed88ae29f2421eb@mail.gmail.com>
	<e19d85410811061946h633e3607q592bcbc471ae8bfb@mail.gmail.com>
Message-ID: <e0916e01ee8670a3556fe3856a0bf004@imap.1and1.com>




On Fri, 7 Nov 2008 05:46:09 +0200, "Elia Yehuda" <z4ziggy at gmail.com> wrote:
> found the problem - its my buggy vga.rom!!! it's missing the damn
> device_id!
> 
That's what I thought...

-- 
Thanks,
Joseph Smith
Set-Top-Linux
www.settoplinux.org




From michalwd1979 at gmail.com  Fri Nov  7 14:02:14 2008
From: michalwd1979 at gmail.com (Michal Widlok)
Date: Fri, 7 Nov 2008 15:02:14 +0200
Subject: [coreboot] Dell PE2850 with coreboot.
In-Reply-To: <4727185d0811061133u682ed52ck592fb43b867e6368@mail.gmail.com>
References: <e7dbcb740811061117r6601cbd6lc47ed7ecaa6271fe@mail.gmail.com>
	<4727185d0811061133u682ed52ck592fb43b867e6368@mail.gmail.com>
Message-ID: <e7dbcb740811070502s4bb49678o1bbe96f0708a3ac4@mail.gmail.com>

Thanks Vincent,

>
> First, you should ensure you have a way to recover from problems:
>
> Is your flash chip soldered or socketed on the motherboard ?
> If not, any failure (bad flashing or wrong coreboot) and you've
> got an expensive doorstop.
> If yes, do you have at least one spare compatible chip with an
> original bios flashed onto, to recover from failures ?
>

Flash is soldered, however I'm prepared to desolder it and install a
socket. I also can copy original BIOS to other chip to have a spare.
Fortunately I have required equipment here :-).

> Then you're fairly safe to try, test, or hack on coreboot.
>
> A serial console (to another host) setup and working is good
> to have, because VGA may not work at first.
>

I also have spare host to create serial console.
However I really would like to talk to with a person who already tried
this on Dell servers. I don't feel good enough in linux/C/PCs to be
the first one who will install coreboot on a rack server. I did not
think about coreboot before, but some time ago I saw a WIP for dell
1850, and this triggerd me to post to the list.

Best Regards,
Michael W.



From vincent.legoll at gmail.com  Fri Nov  7 14:10:37 2008
From: vincent.legoll at gmail.com (Vincent Legoll)
Date: Fri, 7 Nov 2008 14:10:37 +0100
Subject: [coreboot] Dell PE2850 with coreboot.
In-Reply-To: <e7dbcb740811070502s4bb49678o1bbe96f0708a3ac4@mail.gmail.com>
References: <e7dbcb740811061117r6601cbd6lc47ed7ecaa6271fe@mail.gmail.com>
	<4727185d0811061133u682ed52ck592fb43b867e6368@mail.gmail.com>
	<e7dbcb740811070502s4bb49678o1bbe96f0708a3ac4@mail.gmail.com>
Message-ID: <4727185d0811070510h6b2af606ic44f14efdb8f581a@mail.gmail.com>

On Fri, Nov 7, 2008 at 2:02 PM, Michal Widlok <michalwd1979 at gmail.com> wrote:
> Flash is soldered, however I'm prepared to desolder it and install a
> socket. I also can copy original BIOS to other chip to have a spare.
> Fortunately I have required equipment here :-).

That's good, in my (very small) experience with coreboot, you have to
go back and forth between legacy bios and coreboot.

> However I really would like to talk to with a person who already tried
> this on Dell servers. I don't feel good enough in linux/C/PCs to be
> the first one who will install coreboot on a rack server. I did not
> think about coreboot before, but some time ago I saw a WIP for dell
> 1850, and this triggerd me to post to the list.

If the motherboard components are listed as supported by coreboot,
testing is easy, especially if a similar motherboard is already working.

Depending on the similarity level you may just try a coreboot image for
the other mobo and see how far it goes.

-- 
Vincent Legoll



From c-d.hailfinger.devel.2006 at gmx.net  Fri Nov  7 15:24:33 2008
From: c-d.hailfinger.devel.2006 at gmx.net (Carl-Daniel Hailfinger)
Date: Fri, 07 Nov 2008 15:24:33 +0100
Subject: [coreboot] [RFC] Null pointer trap?
Message-ID: <49144FA1.40907@gmx.net>

v3 does not have any mechanism to detect NULL pointers used by accident.

I propose to fill the zero page (0x0-0xfff) with a special POISON_BYTE,
maybe 0x6b. Furthermore, I'd like to make sure passing a NULL pointer
(or something near it) to as a string to printk will be very visible in
the logs.
*(char *)0 = "ERROR NULL POINTER DEREFERENCE!\n";
The C statement above would cause a nice print everytime someone
referenced the first 32 bytes in %s.

Another way to do this is extending the non-NULL check in printk to
cover the whole zero page.

Regards,
Carl-Daniel

-- 
http://www.hailfinger.org/




From jordan at cosmicpenguin.net  Fri Nov  7 16:01:42 2008
From: jordan at cosmicpenguin.net (Jordan Crouse)
Date: Fri, 07 Nov 2008 08:01:42 -0700
Subject: [coreboot] SeaBIOS question and cross compilation fix.
In-Reply-To: <20081107010218.GB31308@morn.localdomain>
References: <49130685.7030804@coresystems.de>	<20081107001052.GA31143@morn.localdomain>	<4913892A.6080203@coresystems.de>
	<20081107010218.GB31308@morn.localdomain>
Message-ID: <49145856.9020505@cosmicpenguin.net>

Kevin O'Connor wrote:
> On Fri, Nov 07, 2008 at 01:17:46AM +0100, Stefan Reinauer wrote:
>>> BTW, in previous emails I highlighted some disadvantages with a
>>> tighter integration of seabios and coreboot.  Could you elaborate on
>>> the reasons why you think this is the best option?
>> Simple:
>>
>> a) I don't want to maintain my own bios emulation in coreboot v3
>> b) I still want graphics initialized (and possibly more)
>> c) I don't want to use int19 booting / I don't want to use seabios as a
>> payload.
>>   * because I might be running in an emulator or not
>>   * because I am running other payloads and I want to spend as little
>> time in seabios as possible
>>   * because I think this is the only possible way to do a soft
>> transition of the code that is in coreboot these days and what we might
>> see some day in the future.
>>
>> That said, I must have missed the mail you are talking about.
> 
> I was thinking of the chain of emails at:
> 
> http://www.coreboot.org/pipermail/coreboot/2008-July/036545.html
> 
> 
> My (new) thinking is that we could:
> 
> * Continue to have seabios be a coreboot payload
> 
> * Have seabios find, copy, and run options roms on pci cards.  Have it
>   scan the lar for pci devices with option roms embedded in flash.
> 
> * Teach seabios to be able to launch a payload from flash in addition
>   to floppy, hd, cdrom, etc..
> 
> The main gain to the above is is that we can keep all the legacy x86
> real mode crud (including option roms) in one place (seabios), and we
> can avoid having to return from seabios to coreboot and thus not have
> to worry abou them "stomping" on each other.

My main concern is that if seabios becomes a defacto mandatory payload 
for coreboot, then having two separate projects to put together will be 
an undue burden on the builders.  My thinking has always been that at 
the time when something becomes essential to the operation of coreboot, 
it should be merged into coreboot.

Jordan



From jordan at cosmicpenguin.net  Fri Nov  7 16:04:47 2008
From: jordan at cosmicpenguin.net (Jordan Crouse)
Date: Fri, 07 Nov 2008 08:04:47 -0700
Subject: [coreboot] [RFC] Null pointer trap?
In-Reply-To: <49144FA1.40907@gmx.net>
References: <49144FA1.40907@gmx.net>
Message-ID: <4914590F.3010907@cosmicpenguin.net>

Carl-Daniel Hailfinger wrote:
> v3 does not have any mechanism to detect NULL pointers used by accident.
> 
> I propose to fill the zero page (0x0-0xfff) with a special POISON_BYTE,
> maybe 0x6b. 

I'm not sure what problem you are trying to solve here?  Are you trying 
to responsibly catch NULL pointers and report information, or are you 
trying to just be able to identify the situation on a debugger?

Jordan




From c-d.hailfinger.devel.2006 at gmx.net  Fri Nov  7 16:18:24 2008
From: c-d.hailfinger.devel.2006 at gmx.net (Carl-Daniel Hailfinger)
Date: Fri, 07 Nov 2008 16:18:24 +0100
Subject: [coreboot] [RFC] Null pointer trap?
In-Reply-To: <4914590F.3010907@cosmicpenguin.net>
References: <49144FA1.40907@gmx.net> <4914590F.3010907@cosmicpenguin.net>
Message-ID: <49145C40.5020804@gmx.net>

On 07.11.2008 16:04, Jordan Crouse wrote:
> Carl-Daniel Hailfinger wrote:
>> v3 does not have any mechanism to detect NULL pointers used by accident.
>>
>> I propose to fill the zero page (0x0-0xfff) with a special POISON_BYTE,
>> maybe 0x6b. 
>
> I'm not sure what problem you are trying to solve here?  Are you
> trying to responsibly catch NULL pointers and report information, or
> are you trying to just be able to identify the situation on a debugger?

Catching NULL pointers immediately and reporting information would be
really cool, but for most hardware I fear that looking at a RAM image
after the fact is the only thing we can do.
You're right, though, this RFC was mostly a monkey-see-problem
monkey-do-something post, intended to get others to offer their insight
on that problem area.

Regards,
Carl-Daniel

-- 
http://www.hailfinger.org/




From mylesgw at gmail.com  Fri Nov  7 16:18:51 2008
From: mylesgw at gmail.com (Myles Watson)
Date: Fri, 7 Nov 2008 09:18:51 -0600
Subject: [coreboot] Subtractive Resources
Message-ID: <2831fecf0811070718q384e1f07nfd2f423e297339c9@mail.gmail.com>

I'm running into a problem when resources are read.

The amd8111 adds two subtractive resources on link 0.  The problem is that
it has no link 0.

static void amd8111_lpc_read_resources(struct device * dev)
{
    struct resource *res;

    printk(BIOS_DEBUG,"%s calls read_resources with %s bus %s \n",
            __func__, dev->dtsname, dev->bus? dev->bus->dev->dtsname:
"NULL");
    /* Get the normal pci resources of this device */
    pci_dev_read_resources(dev);

    /* Add an extra subtractive resource for both memory and I/O */
    res = new_resource(dev, IOINDEX_SUBTRACTIVE(0, 0));
    res->flags = IORESOURCE_IO | IORESOURCE_SUBTRACTIVE |
IORESOURCE_ASSIGNED;

    res = new_resource(dev, IOINDEX_SUBTRACTIVE(1, 0));
    res->flags = IORESOURCE_MEM | IORESOURCE_SUBTRACTIVE |
IORESOURCE_ASSIGNED;
    printk(BIOS_DEBUG,"%s after read_resources\n", __func__);
}

Either of these changes fix it, but I'd like a little more understanding of
why we're trying to do this.

I like the first change better because it quits trying sooner.

Index: device/device.c
===================================================================
--- device/device.c     (revision 984)
+++ device/device.c     (working copy)
@@ -311,7 +311,7 @@

                /* Read in subtractive resources behind the current device.
*/
                links = 0;
-               for (i = 0; i < curdev->resources; i++) {
+               for (i = 0; i < curdev->resources && curdev->links>0; i++) {
                        struct resource *resource;
                        unsigned int link;
                        resource = &curdev->resource[i];
@@ -326,7 +326,8 @@
                        }
                        if (!(links & (1 << link))) {
                                links |= (1 << link);
-                               read_resources(&curdev->link[link]);
+                               if (curdev->link[link].dev)
+                                       read_resources(&curdev->link[link]);
                        }
                }
        }


Signed-off-by: Myles Watson <mylesgw at gmail.com>

Thanks,
Myles
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20081107/d60d9f41/attachment.html>

From peter at stuge.se  Fri Nov  7 16:23:59 2008
From: peter at stuge.se (Peter Stuge)
Date: Fri, 7 Nov 2008 16:23:59 +0100
Subject: [coreboot] SeaBIOS question and cross compilation fix.
In-Reply-To: <49145856.9020505@cosmicpenguin.net>
References: <49130685.7030804@coresystems.de>
	<20081107001052.GA31143@morn.localdomain>
	<4913892A.6080203@coresystems.de>
	<20081107010218.GB31308@morn.localdomain>
	<49145856.9020505@cosmicpenguin.net>
Message-ID: <20081107152359.20181.qmail@stuge.se>

Jordan Crouse wrote:
> My main concern is that if seabios becomes a defacto mandatory

I will protest very loudly against mandatory. It must be an option.


> payload for coreboot, then having two separate projects to put
> together will be an undue burden on the builders.

We already have this situation for coreboot+payload, and I think
buildrom solves that nicely.


> My thinking has always been that at the time when something becomes
> essential to the operation of coreboot, it should be merged into
> coreboot.

I don't think that is neccessary when "it" is being phased out.


//Peter



From mart.raudsepp at artecdesign.ee  Fri Nov  7 16:35:02 2008
From: mart.raudsepp at artecdesign.ee (Mart Raudsepp)
Date: Fri, 07 Nov 2008 17:35:02 +0200
Subject: [coreboot] [PATCH] Working fake SPD for DBE61C
Message-ID: <1226072102.4568.7.camel@martr-gentoo.artec>

Working fake SPD for DBE61C

Signed-off-by: Mart Raudsepp <mart.raudsepp at artecdesign.ee>

---
 mainboard/artecgroup/dbe61/initram.c |   45 ++++++++++++++++++++-------------
 1 files changed, 27 insertions(+), 18 deletions(-)

diff --git a/mainboard/artecgroup/dbe61/initram.c b/mainboard/artecgroup/dbe61/initram.c
index 393d575..8c84792 100644
--- a/mainboard/artecgroup/dbe61/initram.c
+++ b/mainboard/artecgroup/dbe61/initram.c
@@ -38,31 +38,39 @@
 #define DIMM0 ((u8) 0xA0)
 #define DIMM1 ((u8) 0xA2)
 
-/* The part is a Hynix hy5du121622ctp-d43.
- *
- * HY 5D U 12 16 2 2 C <blank> T <blank> P D43
- * Hynix
- * DDR SDRAM (5D)
- * VDD 2.5 VDDQ 2.5 (U)
- * 512M 8K REFRESH (12)
- * x16 (16)
- * 4banks (2)
- * SSTL_2 (2)
- * 4th GEN die (C)
- * Normal Power Consumption (<blank> )
- * TSOP (T)
- * Single Die (<blank>)
- * Lead Free (P)
- * DDR400 3-3-3 (D43)
- */
-
 struct spd_entry {
 	u8 address;
 	u8 data;
 };
 
 /* Save space by using a short list of SPD values used by Geode LX Memory init */
+/* Fake SPD for DBE61C - 256MB. Same memory chip, and therefore same SPD entries, as for DBE62. */
+/* Micron MT46V32M16 */
 static const struct spd_entry spd_table[] = {
+	{SPD_MEMORY_TYPE, 7},
+	{SPD_NUM_ROWS, 13},
+	{SPD_tRFC, 0x4b},
+	{SPD_ACCEPTABLE_CAS_LATENCIES, 0x10},
+	{SPD_DENSITY_OF_EACH_ROW_ON_MODULE, 0x40},
+	{SPD_tRAS, 0x2d},
+	{SPD_MIN_CYCLE_TIME_AT_CAS_MAX, 0x7}, /*0x <= 7},*/
+	{SPD_MIN_RAS_TO_CAS_DELAY, 0x58},
+	{SPD_tRRD, 0x3c},
+	{SPD_tRP, 0x58},
+	{SPD_PRIMARY_SDRAM_WIDTH, 8},
+	{SPD_NUM_BANKS_PER_SDRAM, 0x4},
+	{SPD_NUM_COLUMNS, 0xa}, /* 8kB */
+	{SPD_NUM_DIMM_BANKS, 0x1},
+	{SPD_REFRESH, 0x82},
+	{SPD_SDRAM_CYCLE_TIME_2ND, 0x0},
+	{SPD_SDRAM_CYCLE_TIME_3RD, 0x0},
+	{SPD_tRCD, 15},
+};
+
+#if 0
+/* Fake SPD for DBE61A - 128MB. Not working yet */
+/* Micron MT46V16M16 */
+static const struct spd_entry spd_table_dbe61a[] = {
 	{SPD_ACCEPTABLE_CAS_LATENCIES, 0x10},
 	{SPD_BANK_DENSITY, 0x40},
 	{SPD_DEVICE_ATTRIBUTES_GENERAL, 0xff},
@@ -83,6 +91,7 @@ static const struct spd_entry spd_table[] = {
 	{SPD_tRP, 15},
 	{SPD_tRRD, 10},
 };
+#endif
 
 /**
  * Given an SMBUS device, and an address in that device, return the value of SPD
-- 
1.6.0.2




From jordan at cosmicpenguin.net  Fri Nov  7 16:38:17 2008
From: jordan at cosmicpenguin.net (Jordan Crouse)
Date: Fri, 07 Nov 2008 08:38:17 -0700
Subject: [coreboot] SeaBIOS question and cross compilation fix.
In-Reply-To: <20081107152359.20181.qmail@stuge.se>
References: <49130685.7030804@coresystems.de>	<20081107001052.GA31143@morn.localdomain>	<4913892A.6080203@coresystems.de>	<20081107010218.GB31308@morn.localdomain>	<49145856.9020505@cosmicpenguin.net>
	<20081107152359.20181.qmail@stuge.se>
Message-ID: <491460E9.1050407@cosmicpenguin.net>

Peter Stuge wrote:
 > Jordan Crouse wrote:
 >> My main concern is that if seabios becomes a defacto mandatory
 >
 > I will protest very loudly against mandatory. It must be an option.

Its getting harder and harder to make it an option.  We are going to 
have to deal with optionROMs - regardless what any of us think about 
legacy software callbacks, we are not going to get very far unless we 
can handle legacy ROMs easily and cleanly and make them available to the 
payloads.  Thats a fact of life.  SeaBIOS is the best solution to this 
problem that we have so far.  In my mind, that makes it mandatory.

 >> payload for coreboot, then having two separate projects to put
 >> together will be an undue burden on the builders.
 >
 > We already have this situation for coreboot+payload, and I think
 > buildrom solves that nicely.

 From the start, we have said that buildrom is not going to be required 
to build coreboot, and I stand by that.  If our code is getting so 
complex that it *requires* a build system to put it together, then we 
need to step back and evaluate what we are doing.

 >> My thinking has always been that at the time when something becomes
 >> essential to the operation of coreboot, it should be merged into
 >> coreboot.
 >
 > I don't think that is neccessary when "it" is being phased out.

What is being phased out?  SeaBIOS?  Not from where I am standing.

Jordan



From c-d.hailfinger.devel.2006 at gmx.net  Fri Nov  7 16:39:46 2008
From: c-d.hailfinger.devel.2006 at gmx.net (Carl-Daniel Hailfinger)
Date: Fri, 07 Nov 2008 16:39:46 +0100
Subject: [coreboot] [PATCH] Working fake SPD for DBE61C
In-Reply-To: <1226072102.4568.7.camel@martr-gentoo.artec>
References: <1226072102.4568.7.camel@martr-gentoo.artec>
Message-ID: <49146142.3080103@gmx.net>

On 07.11.2008 16:35, Mart Raudsepp wrote:
> Working fake SPD for DBE61C
>
> Signed-off-by: Mart Raudsepp <mart.raudsepp at artecdesign.ee>
>   

Great work!

Acked-by: Carl-Daniel Hailfinger <c-d.hailfinger.devel.2006 at gmx.net>

Regards,
Carl-Daniel

-- 
http://www.hailfinger.org/




From eswierk at aristanetworks.com  Fri Nov  7 16:42:44 2008
From: eswierk at aristanetworks.com (Ed Swierk)
Date: Fri, 7 Nov 2008 07:42:44 -0800
Subject: [coreboot] SeaBIOS question and cross compilation fix.
In-Reply-To: <20081107152359.20181.qmail@stuge.se>
References: <49130685.7030804@coresystems.de>
	<20081107001052.GA31143@morn.localdomain>
	<4913892A.6080203@coresystems.de>
	<20081107010218.GB31308@morn.localdomain>
	<49145856.9020505@cosmicpenguin.net>
	<20081107152359.20181.qmail@stuge.se>
Message-ID: <9ae48b020811070742r36e626ct2d7b18d5f77c548@mail.gmail.com>

On Fri, Nov 7, 2008 at 7:23 AM, Peter Stuge <peter at stuge.se> wrote:
> Jordan Crouse wrote:
>> My main concern is that if seabios becomes a defacto mandatory
>
> I will protest very loudly against mandatory. It must be an option.

+1

Modularity is one of the key technical advantages of coreboot. Let's
not follow the lead of commercial BIOSes that throw in everything but
the kitchen sink.

--Ed



From stepan at coresystems.de  Fri Nov  7 16:44:49 2008
From: stepan at coresystems.de (Stefan Reinauer)
Date: Fri, 07 Nov 2008 16:44:49 +0100
Subject: [coreboot] SeaBIOS question and cross compilation fix.
In-Reply-To: <49145856.9020505@cosmicpenguin.net>
References: <49130685.7030804@coresystems.de>	<20081107001052.GA31143@morn.localdomain>	<4913892A.6080203@coresystems.de>
	<20081107010218.GB31308@morn.localdomain>
	<49145856.9020505@cosmicpenguin.net>
Message-ID: <49146271.2080401@coresystems.de>

Jordan Crouse wrote:
>>
>> The main gain to the above is is that we can keep all the legacy x86
>> real mode crud (including option roms) in one place (seabios), and we
>> can avoid having to return from seabios to coreboot and thus not have
>> to worry abou them "stomping" on each other.
>
> My main concern is that if seabios becomes a defacto mandatory payload
> for coreboot, then having two separate projects to put together will
> be an undue burden on the builders.  My thinking has always been that
> at the time when something becomes essential to the operation of
> coreboot, it should be merged into coreboot.
I absolutely agree to the point you're making.

But I'd prefer to have a local copy (regularly synced) of seabios in the
coreboot tree over having a second and third implementation of the same
thing in our tree that people will be using instead of seabios.

It does not help seabios, and it does not help us. We included x86emu in
a similar way, or flashrom via svn:external.

Right now it's a "Seabios: all or nothing" decision. That's bad. And as
long as that's the case, I believe people will go nothing rather than
all except in rare cases.

-- 
coresystems GmbH ? Brahmsstr. 16 ? D-79104 Freiburg i. Br.
      Tel.: +49 761 7668825 ? Fax: +49 761 7664613
Email: info at coresystems.de  ? http://www.coresystems.de/
Registergericht: Amtsgericht Freiburg ? HRB 7656
Gesch?ftsf?hrer: Stefan Reinauer ? Ust-IdNr.: DE245674866




From stepan at coresystems.de  Fri Nov  7 16:47:41 2008
From: stepan at coresystems.de (Stefan Reinauer)
Date: Fri, 07 Nov 2008 16:47:41 +0100
Subject: [coreboot] SeaBIOS question and cross compilation fix.
In-Reply-To: <20081107152359.20181.qmail@stuge.se>
References: <49130685.7030804@coresystems.de>	<20081107001052.GA31143@morn.localdomain>	<4913892A.6080203@coresystems.de>	<20081107010218.GB31308@morn.localdomain>	<49145856.9020505@cosmicpenguin.net>
	<20081107152359.20181.qmail@stuge.se>
Message-ID: <4914631D.9050700@coresystems.de>

Peter Stuge wrote:
> Jordan Crouse wrote:
>   
>> My main concern is that if seabios becomes a defacto mandatory
>>     
>
> I will protest very loudly against mandatory. It must be an option.
>   
It will be as optional as VGA init through an option rom. Want the one,
get both. Obviously when you have something that calls bios calls, you
need one implementation of those bios calls. And they better not be one
of our many implementations in v2 and v3, imho.

Stefan

-- 
coresystems GmbH ? Brahmsstr. 16 ? D-79104 Freiburg i. Br.
      Tel.: +49 761 7668825 ? Fax: +49 761 7664613
Email: info at coresystems.de  ? http://www.coresystems.de/
Registergericht: Amtsgericht Freiburg ? HRB 7656
Gesch?ftsf?hrer: Stefan Reinauer ? Ust-IdNr.: DE245674866




From eswierk at aristanetworks.com  Fri Nov  7 16:49:10 2008
From: eswierk at aristanetworks.com (Ed Swierk)
Date: Fri, 7 Nov 2008 07:49:10 -0800
Subject: [coreboot] SeaBIOS question and cross compilation fix.
In-Reply-To: <491460E9.1050407@cosmicpenguin.net>
References: <49130685.7030804@coresystems.de>
	<20081107001052.GA31143@morn.localdomain>
	<4913892A.6080203@coresystems.de>
	<20081107010218.GB31308@morn.localdomain>
	<49145856.9020505@cosmicpenguin.net>
	<20081107152359.20181.qmail@stuge.se>
	<491460E9.1050407@cosmicpenguin.net>
Message-ID: <9ae48b020811070749g3771b03s36cfed6a6a091f68@mail.gmail.com>

On Fri, Nov 7, 2008 at 7:38 AM, Jordan Crouse <jordan at cosmicpenguin.net> wrote:
> Its getting harder and harder to make it an option.  We are going to have to
> deal with optionROMs - regardless what any of us think about legacy software
> callbacks, we are not going to get very far unless we can handle legacy ROMs
> easily and cleanly and make them available to the payloads.  Thats a fact of
> life.  SeaBIOS is the best solution to this problem that we have so far.  In
> my mind, that makes it mandatory.

Not every application of coreboot has to worry about legacy hardware
or option ROMs.

To be clear, I don't object to seeing SeaBIOS in the coreboot source
tree, but there must be an option to ignore it at compile time.

--Ed



From stepan at coresystems.de  Fri Nov  7 16:54:56 2008
From: stepan at coresystems.de (Stefan Reinauer)
Date: Fri, 07 Nov 2008 16:54:56 +0100
Subject: [coreboot] SeaBIOS question and cross compilation fix.
In-Reply-To: <9ae48b020811070742r36e626ct2d7b18d5f77c548@mail.gmail.com>
References: <49130685.7030804@coresystems.de>	<20081107001052.GA31143@morn.localdomain>	<4913892A.6080203@coresystems.de>	<20081107010218.GB31308@morn.localdomain>	<49145856.9020505@cosmicpenguin.net>	<20081107152359.20181.qmail@stuge.se>
	<9ae48b020811070742r36e626ct2d7b18d5f77c548@mail.gmail.com>
Message-ID: <491464D0.6020405@coresystems.de>

Ed Swierk wrote:
> On Fri, Nov 7, 2008 at 7:23 AM, Peter Stuge <peter at stuge.se> wrote:
>   
>> Jordan Crouse wrote:
>>     
>>> My main concern is that if seabios becomes a defacto mandatory
>>>       
>> I will protest very loudly against mandatory. It must be an option.
>>     
>
> +1
>
> Modularity is one of the key technical advantages of coreboot. Let's
> not follow the lead of commercial BIOSes that throw in everything but
> the kitchen sink.
>   
Modularity can very well mean a module is mandatory. In v2 there was no
initram module. But it's still mandatory in v3, even though it's modular.

I think we all agree that a feature requirement (option rom execution)
may mean a module requirement (seabios).

There really is not much to discuss about, except if we start flipping
words around when we hear the word bios.

-- 
coresystems GmbH ? Brahmsstr. 16 ? D-79104 Freiburg i. Br.
      Tel.: +49 761 7668825 ? Fax: +49 761 7664613
Email: info at coresystems.de  ? http://www.coresystems.de/
Registergericht: Amtsgericht Freiburg ? HRB 7656
Gesch?ftsf?hrer: Stefan Reinauer ? Ust-IdNr.: DE245674866




From stepan at coresystems.de  Fri Nov  7 16:55:36 2008
From: stepan at coresystems.de (Stefan Reinauer)
Date: Fri, 07 Nov 2008 16:55:36 +0100
Subject: [coreboot] SeaBIOS question and cross compilation fix.
In-Reply-To: <491460E9.1050407@cosmicpenguin.net>
References: <49130685.7030804@coresystems.de>	<20081107001052.GA31143@morn.localdomain>	<4913892A.6080203@coresystems.de>	<20081107010218.GB31308@morn.localdomain>	<49145856.9020505@cosmicpenguin.net>	<20081107152359.20181.qmail@stuge.se>
	<491460E9.1050407@cosmicpenguin.net>
Message-ID: <491464F8.3070207@coresystems.de>

Jordan Crouse wrote:
> From the start, we have said that buildrom is not going to be required
> to build coreboot, and I stand by that.  If our code is getting so
> complex that it *requires* a build system to put it together, then we
> need to step back and evaluate what we are doing.
And I think we should do this. Not w.r.t. putting seabios in there by
default or not, but maybe w.r.t our build system.

We still have both abuild and buildrom, and yes, both serve different goals.

I still think we need a single solution but I don't know how, yet.

-- 
coresystems GmbH ? Brahmsstr. 16 ? D-79104 Freiburg i. Br.
      Tel.: +49 761 7668825 ? Fax: +49 761 7664613
Email: info at coresystems.de  ? http://www.coresystems.de/
Registergericht: Amtsgericht Freiburg ? HRB 7656
Gesch?ftsf?hrer: Stefan Reinauer ? Ust-IdNr.: DE245674866




From jordan at cosmicpenguin.net  Fri Nov  7 17:01:36 2008
From: jordan at cosmicpenguin.net (Jordan Crouse)
Date: Fri, 07 Nov 2008 09:01:36 -0700
Subject: [coreboot] SeaBIOS question and cross compilation fix.
In-Reply-To: <9ae48b020811070749g3771b03s36cfed6a6a091f68@mail.gmail.com>
References: <49130685.7030804@coresystems.de>	<20081107001052.GA31143@morn.localdomain>	<4913892A.6080203@coresystems.de>	<20081107010218.GB31308@morn.localdomain>	<49145856.9020505@cosmicpenguin.net>	<20081107152359.20181.qmail@stuge.se>	<491460E9.1050407@cosmicpenguin.net>
	<9ae48b020811070749g3771b03s36cfed6a6a091f68@mail.gmail.com>
Message-ID: <49146660.2020708@cosmicpenguin.net>

Ed Swierk wrote:
> On Fri, Nov 7, 2008 at 7:38 AM, Jordan Crouse <jordan at cosmicpenguin.net> wrote:
>> Its getting harder and harder to make it an option.  We are going to have to
>> deal with optionROMs - regardless what any of us think about legacy software
>> callbacks, we are not going to get very far unless we can handle legacy ROMs
>> easily and cleanly and make them available to the payloads.  Thats a fact of
>> life.  SeaBIOS is the best solution to this problem that we have so far.  In
>> my mind, that makes it mandatory.
> 
> Not every application of coreboot has to worry about legacy hardware
> or option ROMs.

Don't misunderstand the use of the word mandatory here.  As an example, 
consider that optionROMs may need to be managed on any mainboard that 
has PCI or PCIe slots or onboard video, NICs or RAID controllers.  As 
developers, if we cannot rule out the possibility of using an optionROM 
then we would need to enable that functionality.  Look through the list 
of mainboards, and tell me how many of them fall out of this dataset? 
As the United States just got finished with an election, the comparison 
is apt - the majority will need optionROM support, and I consider that 
as mandatory, at least as far as any random mainboard is concerned.

> To be clear, I don't object to seeing SeaBIOS in the coreboot source
> tree, but there must be an option to ignore it at compile time.

Absolutely, configuration options are cheap and easy - we should use 
them as much as possible.  But I don't think anybody disagrees with this 
- the larger debate is if SeaBIOS should stop being an independent 
entity - I think the majority of mainboards says yes.

Or, look at it from the builder point of view.  I don't mind having a 
configuration file for each mainboard - text is cheap.  But if I have to 
build the same package for every single mainboard, at some point I start 
asking questions.  Thats what I'm doing here.

Jordan





From rminnich at gmail.com  Fri Nov  7 17:13:41 2008
From: rminnich at gmail.com (ron minnich)
Date: Fri, 7 Nov 2008 08:13:41 -0800
Subject: [coreboot] SeaBIOS question and cross compilation fix.
In-Reply-To: <49146660.2020708@cosmicpenguin.net>
References: <49130685.7030804@coresystems.de>
	<20081107001052.GA31143@morn.localdomain>
	<4913892A.6080203@coresystems.de>
	<20081107010218.GB31308@morn.localdomain>
	<49145856.9020505@cosmicpenguin.net>
	<20081107152359.20181.qmail@stuge.se>
	<491460E9.1050407@cosmicpenguin.net>
	<9ae48b020811070749g3771b03s36cfed6a6a091f68@mail.gmail.com>
	<49146660.2020708@cosmicpenguin.net>
Message-ID: <13426df10811070813n19fe1474v35e2c2aefa876ff7@mail.gmail.com>

It's interesting to see the variations in thinking on this based on
variations in experience. Ed's company builds a system that has no
need of option ROMs- they control the platform. I have no need of
option ROMs either -- I don't control the platform, but HPC systems
don't need them in most cases. We've fielded thousands and thousands
of cluster nodes that never need an option ROM, BIOS callback, or even
SMI.

Others, coming from an environment rich in option ROMs, see the need.

I agree with Ed. seabios must be optional.

I agree with Stefan. It must be possible to build seabios in easily.

I agree with Jordan. Option roms, and BIOS callbacks, are not going
away (IMHO, for at last 5 years). Why? Because vendors are not yet
ready to open up those details, now if ever.

So, seabios must
1. be easily available via a make Kconfig option
2. be optional.
3. return from an init call
4. assume responsibility (take over from coreboot) for option ROMs

I think this is what Stefan is saying. I agree.

Sorry, Kevin, you did a great job with seabios, and now lots of people
want it :-)

ron



From rminnich at gmail.com  Fri Nov  7 17:15:18 2008
From: rminnich at gmail.com (ron minnich)
Date: Fri, 7 Nov 2008 08:15:18 -0800
Subject: [coreboot] [RFC] Null pointer trap?
In-Reply-To: <49145C40.5020804@gmx.net>
References: <49144FA1.40907@gmx.net> <4914590F.3010907@cosmicpenguin.net>
	<49145C40.5020804@gmx.net>
Message-ID: <13426df10811070815n40d8987fmff058b6f61105376@mail.gmail.com>

we can't do this well until we start turning on paging. If you want to
argue that we should poison memory used by coreboot, I'm good with
that.

ron



From jordan at cosmicpenguin.net  Fri Nov  7 17:18:30 2008
From: jordan at cosmicpenguin.net (Jordan Crouse)
Date: Fri, 07 Nov 2008 09:18:30 -0700
Subject: [coreboot] SeaBIOS question and cross compilation fix.
In-Reply-To: <13426df10811070813n19fe1474v35e2c2aefa876ff7@mail.gmail.com>
References: <49130685.7030804@coresystems.de>	
	<20081107001052.GA31143@morn.localdomain>	
	<4913892A.6080203@coresystems.de>	
	<20081107010218.GB31308@morn.localdomain>	
	<49145856.9020505@cosmicpenguin.net>	
	<20081107152359.20181.qmail@stuge.se>	
	<491460E9.1050407@cosmicpenguin.net>	
	<9ae48b020811070749g3771b03s36cfed6a6a091f68@mail.gmail.com>	
	<49146660.2020708@cosmicpenguin.net>
	<13426df10811070813n19fe1474v35e2c2aefa876ff7@mail.gmail.com>
Message-ID: <49146A56.4000107@cosmicpenguin.net>

ron minnich wrote:
> It's interesting to see the variations in thinking on this based on
> variations in experience. Ed's company builds a system that has no
> need of option ROMs- they control the platform. I have no need of
> option ROMs either -- I don't control the platform, but HPC systems
> don't need them in most cases. We've fielded thousands and thousands
> of cluster nodes that never need an option ROM, BIOS callback, or even
> SMI.
> 
> Others, coming from an environment rich in option ROMs, see the need.
> 
> I agree with Ed. seabios must be optional.
> 
> I agree with Stefan. It must be possible to build seabios in easily.
> 
> I agree with Jordan. Option roms, and BIOS callbacks, are not going
> away (IMHO, for at last 5 years). Why? Because vendors are not yet
> ready to open up those details, now if ever.
> 
> So, seabios must
> 1. be easily available via a make Kconfig option
> 2. be optional.
> 3. return from an init call
> 4. assume responsibility (take over from coreboot) for option ROMs
> 
> I think this is what Stefan is saying. I agree.

I agree with all of this.

Jordan




From c-d.hailfinger.devel.2006 at gmx.net  Fri Nov  7 17:24:01 2008
From: c-d.hailfinger.devel.2006 at gmx.net (Carl-Daniel Hailfinger)
Date: Fri, 07 Nov 2008 17:24:01 +0100
Subject: [coreboot] [RFC] Null pointer trap?
In-Reply-To: <13426df10811070815n40d8987fmff058b6f61105376@mail.gmail.com>
References: <49144FA1.40907@gmx.net> <4914590F.3010907@cosmicpenguin.net>	
	<49145C40.5020804@gmx.net>
	<13426df10811070815n40d8987fmff058b6f61105376@mail.gmail.com>
Message-ID: <49146BA1.8000908@gmx.net>

On 07.11.2008 17:15, ron minnich wrote:
> we can't do this well until we start turning on paging.

True.

> If you want to argue that we 
> should poison memory used by coreboot, I'm good with that.
>   

Poisoning as a default-off option will be forthcoming as a patch.
Default off because it will interfere with Suspend-to-RAM. But for other
cases, it may provide valuable hints. For one, it does make stack size
detection a lot more reliable.

Regards,
Carl-Daniel

-- 
http://www.hailfinger.org/




From rminnich at gmail.com  Fri Nov  7 17:24:27 2008
From: rminnich at gmail.com (ron minnich)
Date: Fri, 7 Nov 2008 08:24:27 -0800
Subject: [coreboot] Subtractive Resources
In-Reply-To: <2831fecf0811070718q384e1f07nfd2f423e297339c9@mail.gmail.com>
References: <2831fecf0811070718q384e1f07nfd2f423e297339c9@mail.gmail.com>
Message-ID: <13426df10811070824r16c79d4i6058e634b18f01fa@mail.gmail.com>

On Fri, Nov 7, 2008 at 7:18 AM, Myles Watson <mylesgw at gmail.com> wrote:
> I'm running into a problem when resources are read.
>
> The amd8111 adds two subtractive resources on link 0.  The problem is that
> it has no link 0.

This is usually a sign that I got the dtc wrong somehow.

Here is v2:
struct device _dev15 = {
        .ops = 0,
        .bus = &_dev8.link[0],
        .path = {.type=DEVICE_PATH_PCI,.u={.pci={ .devfn = PCI_DEVFN(0x0,0)}}},
        .enabled = 1,
        .on_mainboard = 1,
        .link = {
                [0] = {
                        .link = 0,
                        .dev = &_dev15,
                        .children = &_dev16,
                },
        },
        .links = 1,
        .sibling = &_dev20,
        .chip_ops = &southbridge_amd_amd8111_ops,
        .chip_info = &southbridge_amd_amd8111_info_14,
        .next=&_dev16
};

and

struct device _dev16 = {
        .ops = 0,
        .bus = &_dev15.link[0],
        .path = {.type=DEVICE_PATH_PCI,.u={.pci={ .devfn = PCI_DEVFN(0x0,0)}}},
        .enabled = 1,
        .on_mainboard = 1,
        .link = {
        },
        .links = 0,
        .sibling = &_dev17,
        .chip_ops = &southbridge_amd_amd8111_ops,
        .chip_info = &southbridge_amd_amd8111_info_14,
        .next=&_dev17
};


So the amd8111 is a bridge that needs resources.

That said, you said your change fixes it. Does that mean serengeti
works? It's hard to see how given that this is a bridge.

ron



From rminnich at gmail.com  Fri Nov  7 17:25:30 2008
From: rminnich at gmail.com (ron minnich)
Date: Fri, 7 Nov 2008 08:25:30 -0800
Subject: [coreboot] [RFC] Null pointer trap?
In-Reply-To: <49146BA1.8000908@gmx.net>
References: <49144FA1.40907@gmx.net> <4914590F.3010907@cosmicpenguin.net>
	<49145C40.5020804@gmx.net>
	<13426df10811070815n40d8987fmff058b6f61105376@mail.gmail.com>
	<49146BA1.8000908@gmx.net>
Message-ID: <13426df10811070825q19ec15d2i694d20a9243e5bd2@mail.gmail.com>

On Fri, Nov 7, 2008 at 8:24 AM, Carl-Daniel Hailfinger
<c-d.hailfinger.devel.2006 at gmx.net> wrote:

> Poisoning as a default-off option will be forthcoming as a patch.

no, if it is default off and would interfere with suspend to ram,
that's a non starter.

We need a new slogan.

"We're not an OS" :-)

thanks

ron



From svn at coreboot.org  Fri Nov  7 17:33:58 2008
From: svn at coreboot.org (svn at coreboot.org)
Date: Fri,  7 Nov 2008 17:33:58 +0100
Subject: [coreboot] r987 - coreboot-v3/mainboard/artecgroup/dbe61
Message-ID: <mailman.2397.1355071427.16123.coreboot@coreboot.org>

Author: mraudsepp
Date: 2008-11-07 17:33:57 +0100 (Fri, 07 Nov 2008)
New Revision: 987

Modified:
   coreboot-v3/mainboard/artecgroup/dbe61/initram.c
Log:
Working fake SPD for DBE61C

Signed-off-by: Mart Raudsepp <mart.raudsepp at artecdesign.ee>
Acked-by: Carl-Daniel Hailfinger <c-d.hailfinger.devel.2006 at gmx.net>

Modified: coreboot-v3/mainboard/artecgroup/dbe61/initram.c
===================================================================
--- coreboot-v3/mainboard/artecgroup/dbe61/initram.c	2008-11-07 00:51:38 UTC (rev 986)
+++ coreboot-v3/mainboard/artecgroup/dbe61/initram.c	2008-11-07 16:33:57 UTC (rev 987)
@@ -38,32 +38,40 @@
 #define DIMM0 ((u8) 0xA0)
 #define DIMM1 ((u8) 0xA2)
 
-/* The part is a Hynix hy5du121622ctp-d43.
- *
- * HY 5D U 12 16 2 2 C <blank> T <blank> P D43
- * Hynix
- * DDR SDRAM (5D)
- * VDD 2.5 VDDQ 2.5 (U)
- * 512M 8K REFRESH (12)
- * x16 (16)
- * 4banks (2)
- * SSTL_2 (2)
- * 4th GEN die (C)
- * Normal Power Consumption (<blank> )
- * TSOP (T)
- * Single Die (<blank>)
- * Lead Free (P)
- * DDR400 3-3-3 (D43)
- */
-
 struct spd_entry {
 	u8 address;
 	u8 data;
 };
 
 /* Save space by using a short list of SPD values used by Geode LX Memory init */
+/* Fake SPD for DBE61C - 256MB. Same memory chip, and therefore same SPD entries, as for DBE62. */
+/* Micron MT46V32M16 */
 static const struct spd_entry spd_table[] = {
+	{SPD_MEMORY_TYPE, 7},
+	{SPD_NUM_ROWS, 13},
+	{SPD_tRFC, 0x4b},
 	{SPD_ACCEPTABLE_CAS_LATENCIES, 0x10},
+	{SPD_DENSITY_OF_EACH_ROW_ON_MODULE, 0x40},
+	{SPD_tRAS, 0x2d},
+	{SPD_MIN_CYCLE_TIME_AT_CAS_MAX, 0x7}, /*0x <= 7},*/
+	{SPD_MIN_RAS_TO_CAS_DELAY, 0x58},
+	{SPD_tRRD, 0x3c},
+	{SPD_tRP, 0x58},
+	{SPD_PRIMARY_SDRAM_WIDTH, 8},
+	{SPD_NUM_BANKS_PER_SDRAM, 0x4},
+	{SPD_NUM_COLUMNS, 0xa}, /* 8kB */
+	{SPD_NUM_DIMM_BANKS, 0x1},
+	{SPD_REFRESH, 0x82},
+	{SPD_SDRAM_CYCLE_TIME_2ND, 0x0},
+	{SPD_SDRAM_CYCLE_TIME_3RD, 0x0},
+	{SPD_tRCD, 15},
+};
+
+#if 0
+/* Fake SPD for DBE61A - 128MB. Not working yet */
+/* Micron MT46V16M16 */
+static const struct spd_entry spd_table_dbe61a[] = {
+	{SPD_ACCEPTABLE_CAS_LATENCIES, 0x10},
 	{SPD_BANK_DENSITY, 0x40},
 	{SPD_DEVICE_ATTRIBUTES_GENERAL, 0xff},
 	{SPD_MEMORY_TYPE, 7},
@@ -83,6 +91,7 @@
 	{SPD_tRP, 15},
 	{SPD_tRRD, 10},
 };
+#endif
 
 /**
  * Given an SMBUS device, and an address in that device, return the value of SPD




From rminnich at gmail.com  Fri Nov  7 17:46:50 2008
From: rminnich at gmail.com (ron minnich)
Date: Fri, 7 Nov 2008 08:46:50 -0800
Subject: [coreboot] fixing i810 onboard vga
In-Reply-To: <e19d85410811061927g5ac26535m9e4d9e58b0a4a0a1@mail.gmail.com>
References: <e19d85410811061038x5e9f054ft4ec3b1b93efd029e@mail.gmail.com>
	<55ef48fb3f569a3424087cb7ba0852d5@imap.1and1.com>
	<e19d85410811061719v37a9a0f2kcc143cf8d1600e11@mail.gmail.com>
	<7988291d03369b53d8680e7df147eb6f@imap.1and1.com>
	<e19d85410811061824j8fe0153ge3f4b085f1d3814f@mail.gmail.com>
	<be2a65ba6edb920bf55d999cb7d2f0de@imap.1and1.com>
	<e19d85410811061855i3ca4c59fpf2546873a05233b2@mail.gmail.com>
	<4927aaf7fa34a9c03b51b9ec13a8ffe1@imap.1and1.com>
	<e19d85410811061927