From peter at stuge.se  Tue Jun  1 07:28:06 2010
From: peter at stuge.se (Peter Stuge)
Date: Tue, 1 Jun 2010 07:28:06 +0200
Subject: [coreboot] Can I run coreboot on my motherboard <P35-DS3R>
In-Reply-To: <4C01780A.7000704@gmail.com>
References: <4C01780A.7000704@gmail.com>
Message-ID: <20100601052806.7919.qmail@stuge.se>

Hi Sebastian,

Sebastian Rust wrote:
> I watched the presentation at the 26C3 and I'm really impressed by
> your work.

It's tricky sometimes, but programming hardware is fun. :)


> So I wonder if i can run coreboot on my board. Forgive in case this
> is the wrong mailinglist.

No problem, this is the only mailing list.


> Okay here are the information:
> It's a GA-P35-DS3R from GYGABYTE, currently running a Intel Q8400
> cpu, here the link to the vendor 
> http://www.gigabyte.us/Support/Motherboard/BIOS_Model.aspx?ProductID=2746&ver=#anchor_os
>
> Here is the output of lspci output:
>> -[0000:00]-+-00.0  Intel Corporation 82G33/G31/P35/P31 Express DRAM Controller [8086:29c0]
>>            +-1f.0  Intel Corporation 82801IR (ICH9R) LPC Interface Controller [8086:2916]

The G33/G31/P35/P31 chipset isn't supported, no. Please check the
Supported boards and Supported chipsets pages on the web.

What's worse, that Intel chipset is most likely so much work to
support that it will never be supported unless there is a strong
business case to do the work or someone has copious amount of free
time along with good hardware knowledge and a passion for reverse
engineering.

Sorry to not give a more encouraging response. :\


//Peter



From peter at stuge.se  Tue Jun  1 07:44:08 2010
From: peter at stuge.se (Peter Stuge)
Date: Tue, 1 Jun 2010 07:44:08 +0200
Subject: [coreboot] [commit] r5600 - in trunk/src:
	cpu/x86/smm	southbridge/intel/i82801dx southbridge/intel/i82801gx
In-Reply-To: <E1OIioa-0007lf-TE@ra.coresystems.de>
References: <E1OIioa-0007lf-TE@ra.coresystems.de>
Message-ID: <20100601054408.10658.qmail@stuge.se>

repository service wrote:
> +++ trunk/src/cpu/x86/smm/Makefile.inc	Sun May 30 15:44:32 2010	(r5600)
..
> +	cd $(obj)/cpu/x86/smm; $(OBJCOPY) -I binary smm -O elf32-i386 -B i386 smm_wrap.o

Could use --redefine-sym and -N to manage symbol names. An example at
http://www.coreboot.org/Initramfs


> +++ trunk/src/southbridge/intel/i82801dx/i82801dx_smi.c	Sun May 30 15:44:32 2010	(r5600)
..
> +extern unsigned char _binary_smm_start;
> +extern unsigned char _binary_smm_size;
..
> +	memcpy((void *)0xa0000, &_binary_smm_start, (size_t)&_binary_smm_size);

> +++ trunk/src/southbridge/intel/i82801gx/i82801gx_smi.c	Sun May 30 15:44:32 2010	(r5600)
..
> +	memcpy((void *)0xa0000, &_binary_smm_start, (size_t)&_binary_smm_size);

Is the pointer to _size really right?


//Peter



From peter at stuge.se  Tue Jun  1 08:02:00 2010
From: peter at stuge.se (Peter Stuge)
Date: Tue, 1 Jun 2010 08:02:00 +0200
Subject: [coreboot] [PATCH] MCP55 azalia driver
In-Reply-To: <4C029E68.1010703@coresystems.de>
References: <4C029E68.1010703@coresystems.de>
Message-ID: <20100601060200.13642.qmail@stuge.se>

Nice! But..

Stefan Reinauer wrote:
> +++ src/devices/oprom/x86.c	(working copy)
> @@ -45,6 +45,43 @@
>  void (*realmode_interrupt)(u32 intno, u32 eax, u32 ebx, u32 ecx, u32 edx, 
>  		u32 esi, u32 edi) __attribute__((regparm(0))) = (void *)&__realmode_interrupt;
>  
> +#define DEBUG_REALMODE
> +#ifdef DEBUG_REALMODE
> +static void
> +dump(u8 * addr, u32 len)

Oops..


..but more importantly:

> +++ src/southbridge/nvidia/mcp55/Makefile.inc	(working copy)
> @@ -1,5 +1,5 @@
>  driver-y += mcp55.o
> -driver-y += mcp55_aza.o
> +driver-y += mcp55_azalia.o

This is so that the driver is built for all boards which

select SOUTHBRIDGE_NVIDIA_MCP55

in their Kconfig.


> +++ src/mainboard/supermicro/h8dmr/mainboard.c	(working copy)
> @@ -3,11 +3,11 @@
>   *
>   * Copyright (C) 2007 AMD
>   * Written by Yinghai Lu <yinghailu at amd.com> for AMD.
> + * Copyright (C) 2010 coresystems GmbH
>   *
>   * 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; either version 2 of the License, or
> - * (at your option) any later version.
> + * 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
> @@ -24,8 +24,21 @@
>  #include <device/pci.h>
>  #include <device/pci_ids.h>
>  #include <device/pci_ops.h>
> +#include "hda_verb.h"
>  #include "chip.h"
>  
> +static void verb_setup(void)
> +{
> +	cim_verb_data = mainboard_cim_verb_data;
> +	cim_verb_data_size = sizeof(mainboard_cim_verb_data);
> +}
> +
> +static void mainboard_enable(device_t dev) 
> +{
> +	verb_setup();
> +}
> +
>  struct chip_operations mainboard_ops = {
>  	CHIP_NAME("Supermicro H8DMR Mainboard")
> +	.enable_dev = mainboard_enable,
>  };

So is there absolutely no way for us to avoid that this code is
duplicated for *every* board with such a select?

It seems wrong to automatically add a driver during build, and then
need to call it manually in boards where it was automatically built!

I think this is pretty important. It seems also related to the VSA
situation for the Geode that I worked around in r5581.


//Peter



From patrick at georgi-clan.de  Tue Jun  1 08:33:55 2010
From: patrick at georgi-clan.de (Patrick Georgi)
Date: Tue, 01 Jun 2010 08:33:55 +0200
Subject: [coreboot] [commit] r5600 - in
 trunk/src:	cpu/x86/smm	southbridge/intel/i82801dx
 southbridge/intel/i82801gx
In-Reply-To: <20100601054408.10658.qmail@stuge.se>
References: <E1OIioa-0007lf-TE@ra.coresystems.de>
	<20100601054408.10658.qmail@stuge.se>
Message-ID: <4C04A9D3.6070507@georgi-clan.de>

Am 01.06.2010 07:44, schrieb Peter Stuge:
> repository service wrote:
>> +++ trunk/src/cpu/x86/smm/Makefile.inc	Sun May 30 15:44:32 2010	(r5600)
> ..
>> +	cd $(obj)/cpu/x86/smm; $(OBJCOPY) -I binary smm -O elf32-i386 -B i386 smm_wrap.o
> 
> Could use --redefine-sym and -N to manage symbol names. An example at
> http://www.coreboot.org/Initramfs
We'd have to cope with all mangling rules that objcopy applies to the
full path. This is more robust.

And we can't use the same symbols we used to use, as the semantics of
size are different. Better use different ones, so any issue breaks the
build instead of breaking runtime.

>> +++ trunk/src/southbridge/intel/i82801dx/i82801dx_smi.c	Sun May 30 15:44:32 2010	(r5600)
> ..
>> +extern unsigned char _binary_smm_start;
>> +extern unsigned char _binary_smm_size;
> ..
>> +	memcpy((void *)0xa0000, &_binary_smm_start, (size_t)&_binary_smm_size);
> 
>> +++ trunk/src/southbridge/intel/i82801gx/i82801gx_smi.c	Sun May 30 15:44:32 2010	(r5600)
> ..
>> +	memcpy((void *)0xa0000, &_binary_smm_start, (size_t)&_binary_smm_size);
> 
> Is the pointer to _size really right?
Yes, objcopy doesn't store the size as a value in memory, but simply
stuffs another symbol into the symbol table.
We don't want the value at *(number of bytes), which is what we'd get
without the dereference.


Patrick



From peter at stuge.se  Tue Jun  1 08:41:10 2010
From: peter at stuge.se (Peter Stuge)
Date: Tue, 1 Jun 2010 08:41:10 +0200
Subject: [coreboot] [commit] r5600 - in trunk/src:
	cpu/x86/smm	southbridge/intel/i82801dx southbridge/intel/i82801gx
In-Reply-To: <4C04A9D3.6070507@georgi-clan.de>
References: <E1OIioa-0007lf-TE@ra.coresystems.de>
	<20100601054408.10658.qmail@stuge.se>
	<4C04A9D3.6070507@georgi-clan.de>
Message-ID: <20100601064110.20935.qmail@stuge.se>

Patrick Georgi wrote:
> > Could use --redefine-sym and -N to manage symbol names.
> 
> We'd have to cope with all mangling rules that objcopy applies to
> the full path. This is more robust.
> 
> And we can't use the same symbols we used to use, as the semantics of
> size are different. Better use different ones, so any issue breaks
> the build instead of breaking runtime.

Sure thing.



> >> +extern unsigned char _binary_smm_size;
> > ..
> >> +	memcpy((void *)0xa0000, &_binary_smm_start, (size_t)&_binary_smm_size);
> > 
> > Is the pointer to _size really right?
> 
> Yes, objcopy doesn't store the size as a value in memory, but
> simply stuffs another symbol into the symbol table.

Nod.


> We don't want the value at *(number of bytes), which is what we'd
> get without the dereference.

Without the *reference* - right?

How about this then? Maybe both for start and size.

extern unsigned char _binary_smm_size[];


//Peter



From stefan.reinauer at coresystems.de  Tue Jun  1 08:56:12 2010
From: stefan.reinauer at coresystems.de (Stefan Reinauer)
Date: Tue, 01 Jun 2010 08:56:12 +0200
Subject: [coreboot] [commit] r5600 - in
 trunk/src:	cpu/x86/smm	southbridge/intel/i82801dx
 southbridge/intel/i82801gx
In-Reply-To: <20100601064110.20935.qmail@stuge.se>
References: <E1OIioa-0007lf-TE@ra.coresystems.de>	<20100601054408.10658.qmail@stuge.se>	<4C04A9D3.6070507@georgi-clan.de>
	<20100601064110.20935.qmail@stuge.se>
Message-ID: <4C04AF0C.2010704@coresystems.de>

On 6/1/10 8:41 AM, Peter Stuge wrote:
>> We don't want the value at *(number of bytes), which is what we'd
>> get without the dereference.
>>     
> Without the *reference* - right?
>
> How about this then? Maybe both for start and size.
>
> extern unsigned char _binary_smm_size[];
>   
Might work... It would sure be nicer than the current solution. if you
can verify it does work, a patch would be very much appreciated!

Stefan



From stefan.reinauer at coresystems.de  Tue Jun  1 09:01:21 2010
From: stefan.reinauer at coresystems.de (Stefan Reinauer)
Date: Tue, 01 Jun 2010 09:01:21 +0200
Subject: [coreboot] [PATCH] MCP55 azalia driver
In-Reply-To: <20100601060200.13642.qmail@stuge.se>
References: <4C029E68.1010703@coresystems.de>
	<20100601060200.13642.qmail@stuge.se>
Message-ID: <4C04B041.1020608@coresystems.de>

On 6/1/10 8:02 AM, Peter Stuge wrote:
> So is there absolutely no way for us to avoid that this code is
> duplicated for *every* board with such a select?
>
> It seems wrong to automatically add a driver during build, and then
> need to call it manually in boards where it was automatically built!
>   
That's actually not what happens. You only need to call it for those
boards that need to load a HDA "VERB table". Many boards should be able
to work without loading a VERB. Unfortuntately I could not test this on
all MCP55 boards, so hence the "safe way".

Providing the HDA VERB table is a mainboard specific thing. So it
belongs into the mainboard.

We could add some magic to load the VERB upon CONFIG_LOAD_VERB. I
considered this back when I implemented the algorithm, but it would even
more mean jumping between components with the code and making it harder
to understand.

> I think this is pretty important. It seems also related to the VSA
> situation for the Geode that I worked around in r5581.
>   
In which way?

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 svn at coreboot.org  Tue Jun  1 12:04:29 2010
From: svn at coreboot.org (repository service)
Date: Tue, 01 Jun 2010 12:04:29 +0200
Subject: [coreboot] [commit] r5601 - trunk/util/inteltool
Message-ID: <E1OJOKj-0004Rg-Ab@ra.coresystems.de>

Author: stepan
Date: Tue Jun  1 12:04:28 2010
New Revision: 5601
URL: https://tracker.coreboot.org/trac/coreboot/changeset/5601

Log:
inteltool: basic poulsbo sch support.
Signed-off-by: Stefan Reinauer <stepan at coresystems.de>
Acked-by: Stefan Reinauer <stepan at coresystems.de>

Modified:
   trunk/util/inteltool/cpu.c
   trunk/util/inteltool/inteltool.c
   trunk/util/inteltool/inteltool.h

Modified: trunk/util/inteltool/cpu.c
==============================================================================
--- trunk/util/inteltool/cpu.c	Sun May 30 15:44:32 2010	(r5600)
+++ trunk/util/inteltool/cpu.c	Tue Jun  1 12:04:28 2010	(r5601)
@@ -464,7 +464,7 @@
 	/* Get CPU family and model, not the stepping
 	 * (TODO: extended family/model)
 	 */
-	id = cpuid(1) & 0xff0;
+	id = cpuid(1) & 0xfffff0;
 	for (i = 0; i < ARRAY_SIZE(cpulist); i++) {
 		if(cpulist[i].model == id) {
 			cpu = &cpulist[i];

Modified: trunk/util/inteltool/inteltool.c
==============================================================================
--- trunk/util/inteltool/inteltool.c	Sun May 30 15:44:32 2010	(r5600)
+++ trunk/util/inteltool/inteltool.c	Tue Jun  1 12:04:28 2010	(r5601)
@@ -45,7 +45,9 @@
 	{ PCI_VENDOR_ID_INTEL, PCI_DEVICE_ID_INTEL_82G33, "P35/G33/G31/P31" },
 	{ PCI_VENDOR_ID_INTEL, PCI_DEVICE_ID_INTEL_82Q33, "Q33" },
 	{ PCI_VENDOR_ID_INTEL, PCI_DEVICE_ID_INTEL_X58, "X58" },
-	{ PCI_VENDOR_ID_INTEL, PCI_DEVICE_ID_INTEL_GS45, "GS45ME-GMCH" },
+	{ PCI_VENDOR_ID_INTEL, PCI_DEVICE_ID_INTEL_GS45, "GS45ME" },
+	{ PCI_VENDOR_ID_INTEL, PCI_DEVICE_ID_INTEL_SCH_POULSBO, "SCH Poulsbo" },
+	{ PCI_VENDOR_ID_INTEL, PCI_DEVICE_ID_INTEL_SCH_POULSBO_LPC, "SCH Poulsbo" },
 	{ PCI_VENDOR_ID_INTEL, PCI_DEVICE_ID_INTEL_ICH10R, "ICH10R" },
 	{ PCI_VENDOR_ID_INTEL, PCI_DEVICE_ID_INTEL_ICH9DH, "ICH9DH" },
 	{ PCI_VENDOR_ID_INTEL, PCI_DEVICE_ID_INTEL_ICH9DO, "ICH9DO" },
@@ -261,8 +263,16 @@
 	}
 
 	id = cpuid(1);
-	printf("Intel CPU: Family %x, Model %x\n",
-			(id >> 8) & 0xf, (id >> 4) & 0xf);
+
+	/* Intel has suggested applications to display the family of a CPU as
+	 * the sum of the "Family" and the "Extended Family" fields shown
+	 * above, and the model as the sum of the "Model" and the 4-bit
+	 * left-shifted "Extended Model" fields.
+	 * http://download.intel.com/design/processor/applnots/24161832.pdf
+	 */
+	printf("Intel CPU: Processor Type: %x, Family %x, Model %x, Stepping %x\n",
+			(id >> 12) & 0x3, ((id >> 8) & 0xf) + ((id >> 20) & 0xff),
+			((id >> 12) & 0xf0) + ((id >> 4) & 0xf), (id & 0xf));
 
 	/* Determine names */
 	for (i = 0; i < ARRAY_SIZE(supported_chips_list); i++)

Modified: trunk/util/inteltool/inteltool.h
==============================================================================
--- trunk/util/inteltool/inteltool.h	Sun May 30 15:44:32 2010	(r5600)
+++ trunk/util/inteltool/inteltool.h	Tue Jun  1 12:04:28 2010	(r5601)
@@ -51,6 +51,7 @@
 #define PCI_DEVICE_ID_INTEL_ICH9M		0x2919
 #define PCI_DEVICE_ID_INTEL_ICH9ME		0x2917
 #define PCI_DEVICE_ID_INTEL_ICH10R		0x3a16
+#define PCI_DEVICE_ID_INTEL_SCH_POULSBO_LPC	0x8119
 
 #define PCI_DEVICE_ID_INTEL_82810		0x7120
 #define PCI_DEVICE_ID_INTEL_82810DC		0x7122
@@ -66,6 +67,7 @@
 #define PCI_DEVICE_ID_INTEL_82Q33		0x29d0
 #define PCI_DEVICE_ID_INTEL_GS45		0x2a40
 #define PCI_DEVICE_ID_INTEL_X58			0x3405
+#define PCI_DEVICE_ID_INTEL_SCH_POULSBO		0x8100
 
 #define PCI_DEVICE_ID_INTEL_82443LX		0x7180
 /* 82443BX has a different device ID if AGP is disabled (hardware-wise). */



From stefan.reinauer at coresystems.de  Tue Jun  1 13:42:39 2010
From: stefan.reinauer at coresystems.de (Stefan Reinauer)
Date: Tue, 01 Jun 2010 13:42:39 +0200
Subject: [coreboot] [PATCH] superiotool support for Fintek F81216
Message-ID: <4C04F22F.7090807@coresystems.de>

See patch...

./superiotool -d
superiotool r5549
Found Fintek F81216A/AG (vid=0x3419, id=0x1602) at 0x4e
Register dump:
idx 25 27
val 00 10
def 00 NA
LDN 0x00 (UART1)
idx 30 60 61 70 f0 f1 f4 f5
val 00 00 00 00 00 44 00 00
def NA NA NA NA 00 40 00 00
LDN 0x01 (UART2)
idx 30 60 61 70 f0 f4 f5
val 00 00 00 00 00 00 00
def NA NA NA NA 00 00 00
LDN 0x02 (UART3)
idx 30 60 61 70 f0 f4 f5
val 00 00 00 00 00 00 00
def NA NA NA NA 00 00 00
LDN 0x03 (UART4)
idx 30 60 61 70 f0 f4 f5
val 00 00 00 00 00 00 00
def NA NA NA NA 00 00 00
LDN 0x08 (WDT)
idx 30 60 61 70 f0 f1
val 00 00 00 00 00 00
def 00 NA NA NA NA NA


-- 
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 --------------
An embedded and charset-unspecified text was scrubbed...
Name: superiotool_f81216.diff
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20100601/554afb24/attachment.ksh>

From r.marek at assembler.cz  Tue Jun  1 13:45:07 2010
From: r.marek at assembler.cz (Rudolf Marek)
Date: Tue, 01 Jun 2010 13:45:07 +0200
Subject: [coreboot] SIS630ET coreboot challenge
In-Reply-To: <AANLkTikFxOKoGfkTAE0vdSpGLHAqZtso0bKKpccs5Dsi@mail.gmail.com>
References: <AANLkTikFxOKoGfkTAE0vdSpGLHAqZtso0bKKpccs5Dsi@mail.gmail.com>
Message-ID: <4C04F2C3.6000509@assembler.cz>

Hi,

http://dev.gentoo.org/~dberkholz/articles/specifications/sis/

There is a docu for sis630 maybe it is enough for you?

Thanks,
Rudolf



From alex.buell at munted.org.uk  Tue Jun  1 14:54:02 2010
From: alex.buell at munted.org.uk (Alex Buell)
Date: Tue, 01 Jun 2010 13:54:02 +0100
Subject: [coreboot] Trying to build MSI 6119 coreboot BIOS
Message-ID: <1275396842.29006.13.camel@lithium.local.net>

I've just downloaded and built SeaBIOS ready to use with CoreBoot on my
old MSI 6119 motherboard. Unfortunately, CoreBoot is stopping with a
build error in src/lib/uart8250.c with an undeclared CONFIG_TTYS0_BASE 
error on line 83. I have checked and serial console output is definitely 
disabled in menuconfig.

Any ideas why? I'm using the latest svn checkout, many thanks!
-- 
http://www.munted.org.uk

One very high maintenance cat living here.



From stepan at coresystems.de  Tue Jun  1 15:16:47 2010
From: stepan at coresystems.de (Stefan Reinauer)
Date: Tue, 01 Jun 2010 15:16:47 +0200
Subject: [coreboot] Trying to build MSI 6119 coreboot BIOS
In-Reply-To: <1275396842.29006.13.camel@lithium.local.net>
References: <1275396842.29006.13.camel@lithium.local.net>
Message-ID: <4C05083F.7020900@coresystems.de>

On 6/1/10 2:54 PM, Alex Buell wrote:
> I've just downloaded and built SeaBIOS ready to use with CoreBoot on my
> old MSI 6119 motherboard. Unfortunately, CoreBoot is stopping with a
> build error in src/lib/uart8250.c with an undeclared CONFIG_TTYS0_BASE 
> error on line 83. I have checked and serial console output is definitely 
> disabled in menuconfig.
>
> Any ideas why? I'm using the latest svn checkout, many thanks!
>   
I think disabling serial console is not supported at this point.

Stefan



From svn at coreboot.org  Tue Jun  1 17:19:25 2010
From: svn at coreboot.org (repository service)
Date: Tue, 01 Jun 2010 17:19:25 +0200
Subject: [coreboot] [commit] r5602 - trunk/src/boot
Message-ID: <E1OJTFV-0002zN-L2@ra.coresystems.de>

Author: myles
Date: Tue Jun  1 17:19:25 2010
New Revision: 5602
URL: https://tracker.coreboot.org/trac/coreboot/changeset/5602

Log:
Check the value of ulzma and do not continue if there was an error.

Print fewer characters for pointers to make the output more concise.

Signed-off-by: Myles Watson <mylesgw at gmail.com>
Acked-by: Stefan Reinauer <stepan at coresystems.de>

Modified:
   trunk/src/boot/selfboot.c

Modified: trunk/src/boot/selfboot.c
==============================================================================
--- trunk/src/boot/selfboot.c	Tue Jun  1 12:04:28 2010	(r5601)
+++ trunk/src/boot/selfboot.c	Tue Jun  1 17:19:25 2010	(r5602)
@@ -473,6 +473,8 @@
 				case CBFS_COMPRESS_LZMA: {
 					printk(BIOS_DEBUG, "using LZMA\n");
 					len = ulzma(src, dest);
+					if (!len) /* Decompression Error. */
+						return 0;
 					break;
 				}
 #if CONFIG_COMPRESSED_PAYLOAD_NRV2B==1
@@ -495,7 +497,7 @@
 			}
 			end = dest + ptr->s_memsz;
 			middle = dest + len;
-			printk(BIOS_SPEW, "[ 0x%016lx, %016lx, 0x%016lx) <- %016lx\n",
+			printk(BIOS_SPEW, "[ 0x%08lx, %08lx, 0x%08lx) <- %08lx\n",
 				(unsigned long)dest,
 				(unsigned long)middle,
 				(unsigned long)end,



From mylesgw at gmail.com  Tue Jun  1 17:21:45 2010
From: mylesgw at gmail.com (Myles Watson)
Date: Tue, 1 Jun 2010 09:21:45 -0600
Subject: [coreboot] Selfboot error checking fix
In-Reply-To: <4C024AB5.6000709@coresystems.de>
References: <p2g2831fecf1005041528kea52cacdp74b217223291f613@mail.gmail.com>
	<4C024AB5.6000709@coresystems.de>
Message-ID: <AANLkTikHN4b7YUw0UykdDqCji5sxprVMFiDHZtY-DkMv@mail.gmail.com>

> Check the return value of ulzma, and quit instead of loading the next
> segment if there's an error.
>
> Size pointers 8 characters instead of 16 to beautify the common case
> where selfboot is loading something into memory below 4GB.
>
> Signed-off-by: Myles Watson <mylesgw at gmail.com>

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

Rev 5602.

Thanks,
Myles



From alex.buell at munted.org.uk  Tue Jun  1 17:47:36 2010
From: alex.buell at munted.org.uk (Alex Buell)
Date: Tue, 01 Jun 2010 16:47:36 +0100
Subject: [coreboot] Trying to build MSI 6119 coreboot BIOS
In-Reply-To: <4C05083F.7020900@coresystems.de>
References: <1275396842.29006.13.camel@lithium.local.net>
	<4C05083F.7020900@coresystems.de>
Message-ID: <1275407256.7063.2.camel@lithium.local.net>

On Tue, 2010-06-01 at 15:16 +0200, Stefan Reinauer wrote:
> On 6/1/10 2:54 PM, Alex Buell wrote:
> > I've just downloaded and built SeaBIOS ready to use with CoreBoot on my
> > old MSI 6119 motherboard. Unfortunately, CoreBoot is stopping with a
> > build error in src/lib/uart8250.c with an undeclared CONFIG_TTYS0_BASE 
> > error on line 83. I have checked and serial console output is definitely 
> > disabled in menuconfig.
> >
> > Any ideas why? I'm using the latest svn checkout, many thanks!
> >   
> I think disabling serial console is not supported at this point.
	
OK, thanks for that one, I've now built CoreBoot and flashed it onto my
MSI 6119 motherboard. Using serial console I can see the following

core-boot-4.0-r5601 Tue Jun 1 14:41:35 BST 2010 starting...
SMBus controller enabled

I have the SeaBIOS built as a payload. The strange thing is that there
seems to be no video. I'll try swapping graphic cards out and see if I
can get video. 

Can the serial console be used as a way to reload firmware if necessary?
-- 
http://www.munted.org.uk

One very high maintenance cat living here.



From stepan at coresystems.de  Tue Jun  1 18:14:54 2010
From: stepan at coresystems.de (Stefan Reinauer)
Date: Tue, 01 Jun 2010 18:14:54 +0200
Subject: [coreboot] Trying to build MSI 6119 coreboot BIOS
In-Reply-To: <1275407256.7063.2.camel@lithium.local.net>
References: <1275396842.29006.13.camel@lithium.local.net>	
	<4C05083F.7020900@coresystems.de>
	<1275407256.7063.2.camel@lithium.local.net>
Message-ID: <4C0531FE.2020800@coresystems.de>

On 6/1/10 5:47 PM, Alex Buell wrote:
> OK, thanks for that one, I've now built CoreBoot and flashed it onto my
> MSI 6119 motherboard. Using serial console I can see the following
>
> core-boot-4.0-r5601 Tue Jun 1 14:41:35 BST 2010 starting...
> SMBus controller enabled
>
>   
Nothing else?

Can you enable CONFIG_DEBUG_RAM_SETUP in Kconfig and reflash?

> I have the SeaBIOS built as a payload. The strange thing is that there
> seems to be no video. I'll try swapping graphic cards out and see if I
> can get video. 
>   
No need. It dies long before it could even theoretically attempt to
initialize VGA according to above log.

> Can the serial console be used as a way to reload firmware if necessary?
>   
Not at this point.

Stefan



From alex.buell at munted.org.uk  Tue Jun  1 18:21:14 2010
From: alex.buell at munted.org.uk (Alex Buell)
Date: Tue, 01 Jun 2010 17:21:14 +0100
Subject: [coreboot] Trying to build MSI 6119 coreboot BIOS
In-Reply-To: <4C0531FE.2020800@coresystems.de>
References: <1275396842.29006.13.camel@lithium.local.net>
	<4C05083F.7020900@coresystems.de>
	<1275407256.7063.2.camel@lithium.local.net>
	<4C0531FE.2020800@coresystems.de>
Message-ID: <1275409274.7063.4.camel@lithium.local.net>

On Tue, 2010-06-01 at 18:14 +0200, Stefan Reinauer wrote:
> On 6/1/10 5:47 PM, Alex Buell wrote:
> > OK, thanks for that one, I've now built CoreBoot and flashed it onto my
> > MSI 6119 motherboard. Using serial console I can see the following
> >
> > core-boot-4.0-r5601 Tue Jun 1 14:41:35 BST 2010 starting...
> > SMBus controller enabled
> >
> >   
> Nothing else?
> 
> Can you enable CONFIG_DEBUG_RAM_SETUP in Kconfig and reflash?

If I could work out a way to boot the machine with Linux in order to
reflash.. ;) (at this point I'm just glad it's a very old box)
-- 
http://www.munted.org.uk

One very high maintenance cat living here.



From peter at stuge.se  Tue Jun  1 19:27:35 2010
From: peter at stuge.se (Peter Stuge)
Date: Tue, 1 Jun 2010 19:27:35 +0200
Subject: [coreboot] Trying to build MSI 6119 coreboot BIOS
In-Reply-To: <1275409274.7063.4.camel@lithium.local.net>
References: <1275396842.29006.13.camel@lithium.local.net>
	<4C05083F.7020900@coresystems.de>
	<1275407256.7063.2.camel@lithium.local.net>
	<4C0531FE.2020800@coresystems.de>
	<1275409274.7063.4.camel@lithium.local.net>
Message-ID: <20100601172735.18534.qmail@stuge.se>

Alex Buell wrote:
> > Can you enable CONFIG_DEBUG_RAM_SETUP in Kconfig and reflash?
> 
> If I could work out a way to boot the machine with Linux in order to
> reflash.. ;)

Is the flash chip socketed? If so you can flash that chip with the
factory BIOS on another, compatible, mainboard.


//Peter



From peter at stuge.se  Tue Jun  1 19:43:33 2010
From: peter at stuge.se (Peter Stuge)
Date: Tue, 1 Jun 2010 19:43:33 +0200
Subject: [coreboot] [PATCH] superiotool support for Fintek F81216
In-Reply-To: <4C04F22F.7090807@coresystems.de>
References: <4C04F22F.7090807@coresystems.de>
Message-ID: <20100601174333.21467.qmail@stuge.se>

Stefan Reinauer wrote:
> Add support for Fintek F81216D/DG/AD
> 
> Signed-off-by: Stefan Reinauer <stepan at coresystems.de>

Acked-by: Peter Stuge <peter at stuge.se>



From mbertens at xs4all.nl  Tue Jun  1 20:31:56 2010
From: mbertens at xs4all.nl (mbertens)
Date: Tue, 01 Jun 2010 20:31:56 +0200
Subject: [coreboot] addition to getpir
In-Reply-To: <1275336426.6402.29.camel@andrala.reboot>
References: <1275336426.6402.29.camel@andrala.reboot>
Message-ID: <1275417116.6402.58.camel@andrala.reboot>

Hi all,

this one was missing a signoff too

Signed-off-by: Marc Bertens <mbertens at xs4all.nl>


On Mon, 2010-05-31 at 22:07 +0200, mbertens wrote:
> hi all,
> 
> i make an addition to getpir, 
> 
> getpir works are before without any commandline parameters.
> when applying for example build\coreboot_ram as parameter
> it looks in the file for the PIRQ table prints it to stdout 
> and shows if the checksum is correct. 
> 
> THis is very handy for developing a PIRQ table.
> 
> Marc
> 
> 
> PS this patch was send before, but was not applied to svn.
>  
> -- 
> coreboot mailing list: coreboot at coreboot.org
> http://www.coreboot.org/mailman/listinfo/coreboot
-- 





From mbertens at xs4all.nl  Tue Jun  1 20:30:32 2010
From: mbertens at xs4all.nl (mbertens)
Date: Tue, 01 Jun 2010 20:30:32 +0200
Subject: [coreboot] Nokia IP530 finally fully working
In-Reply-To: <1275337399.6402.48.camel@andrala.reboot>
References: <1275337399.6402.48.camel@andrala.reboot>
Message-ID: <1275417032.6402.55.camel@andrala.reboot>

Hi all,

a last update the dirty hack in the pirq_routing is not needed, therefor
i made a new diff for it. This contains just the fix in the printk call,
to keep de compiler happy, and me too :-)

	Signed-off : Marc Bertens <mbertens at xs4all.nl>

	on the following patches;
	1.	arch-pirq-rouring.diff
	2.	dec21143-driver.diff
	3.	pcmcia-cardbus-driver.diff
	4.	working-nokia.diff

Marc


On Mon, 2010-05-31 at 22:23 +0200, mbertens wrote:
> hi all,
> 
> i was to fast on the send button, the Nokia IP530 is now finally fully
> working. 
> -	the four on-board NICs (22143PD)
> -	the 2 PCMCIA-Cardbus slots
> -	the 3 compact PCI expansion slots (with 12 NICs)
> 
> I got it working with 16 ethernet controller (all 21143PD), two HDDs on
> the primary IDE controller and two HDD's on the secondary controller.
> The on-board CF slot works as master on the primary IDE controller. very
> nice for silent running (hihi, with those 4 fan's in the back).
> 
> for the NICs i added a driver to the src/drivers/dec/21143. for the
> pcmcia-cardbus controller i added a driver to the
> src/drivers/ti/pcmcia-cardbus. these where required to get the devices
> proberly working. These are added as drivers so that other can use then
> in there configuration to. the parameters can be set in the
> configuration "menuconfig", "xconfig" or "gconfig". 
> 
> all this depends still on a patch to the
> 'src/arch/i386/boot/pirq_routing.c' to get the interrupt routing correct
> working. i will look into this to fix in the near future. 
> 
> I find the coreboot project a great project and i have a lot of fun
> working on it. and i will do so. Next on mylist is the Nokia-IP330, yes
> again a Nokia piece of hardware.
> 
> "That's all folks" 
> 
> Marc 
> 
> 
> 
> 	
> -- 
> coreboot mailing list: coreboot at coreboot.org
> http://www.coreboot.org/mailman/listinfo/coreboot
-------------- next part --------------
A non-text attachment was scrubbed...
Name: arch-pirq-routing.diff
Type: text/x-patch
Size: 1609 bytes
Desc: not available
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20100601/c3c88f51/attachment.diff>

From svn at coreboot.org  Tue Jun  1 21:25:31 2010
From: svn at coreboot.org (repository service)
Date: Tue, 01 Jun 2010 21:25:31 +0200
Subject: [coreboot] [commit] r5603 - in trunk/src: . arch/i386/boot
	mainboard/lippert/spacerunner-lx
Message-ID: <E1OJX5f-00056x-TQ@ra.coresystems.de>

Author: myles
Date: Tue Jun  1 21:25:31 2010
New Revision: 5603
URL: https://tracker.coreboot.org/trac/coreboot/changeset/5603

Log:
CONFIG_DEBUG is too generic.  Remove it and replace it with CONFIG_DEBUG_SMBUS
and CONFIG_DEBUG_PIRQ.

Fix a couple of typos.

Signed-off-by: Myles Watson <mylesgw at gmail.com>
Acked-by: Myles Watson <mylesgw at gmail.com>

Modified:
   trunk/src/Kconfig
   trunk/src/arch/i386/boot/pirq_routing.c
   trunk/src/mainboard/lippert/spacerunner-lx/romstage.c

Modified: trunk/src/Kconfig
==============================================================================
--- trunk/src/Kconfig	Tue Jun  1 17:19:25 2010	(r5602)
+++ trunk/src/Kconfig	Tue Jun  1 21:25:31 2010	(r5603)
@@ -139,10 +139,6 @@
 	hex
 	default 0x4000
 
-config DEBUG
-	bool
-	default n
-
 config USE_PRINTK_IN_CAR
 	bool
 	default n
@@ -520,6 +516,13 @@
 
 	  If unsure, say N.
 
+config DEBUG_PIRQ
+	bool "Check PIRQ table consistency"
+	default n
+	depends on GENERATE_PIRQ_TABLE
+	help
+	  If unsure, say N.
+
 config DEBUG_SMBUS
 	bool "Output verbose SMBus debug messages"
 	default n
@@ -528,6 +531,7 @@
 		 || NORTHBRIDGE_VIA_CX700 \
 		 || NORTHBRIDGE_AMD_AMDK8 \
 		 || NORTHBRIDGE_AMD_AMDFAM10 \
+		 || BOARD_LIPPERT_SPACERUNNER_LX \
 		 || SOUTHBRIDGE_VIA_VT8231)
 	help
 	  This option enables additional SMBus (and SPD) debug messages.

Modified: trunk/src/arch/i386/boot/pirq_routing.c
==============================================================================
--- trunk/src/arch/i386/boot/pirq_routing.c	Tue Jun  1 17:19:25 2010	(r5602)
+++ trunk/src/arch/i386/boot/pirq_routing.c	Tue Jun  1 21:25:31 2010	(r5603)
@@ -3,7 +3,7 @@
 #include <string.h>
 #include <device/pci.h>
 
-#if CONFIG_DEBUG
+#if CONFIG_DEBUG_PIRQ
 static void check_pirq_routing_table(struct irq_routing_table *rt)
 {
 	uint8_t *addr = (uint8_t *)rt;
@@ -13,7 +13,7 @@
 	printk(BIOS_INFO, "Checking Interrupt Routing Table consistency...\n");
 
 	if (sizeof(struct irq_routing_table) != rt->size) {
-		printk(BIOS_WARNING, "Inconsistent Interrupt Routing Table size (0x%x/0x%x).\n",
+		printk(BIOS_WARNING, "Inconsistent Interrupt Routing Table size (0x%lx/0x%x).\n",
 			       sizeof(struct irq_routing_table),
 			       rt->size
 			);
@@ -51,7 +51,7 @@
 	 */
 	if (sum) {
 		printk(BIOS_WARNING, "Checksum error in Interrupt Routing Table "
-				"could not?be fixed.\n");
+				"could not be fixed.\n");
 	}
 
 	printk(BIOS_INFO, "done.\n");
@@ -64,7 +64,7 @@
 
 	rt_curr = (uint8_t*)addr;
 	rt_orig = (uint8_t*)&intel_irq_routing_table;
-	printk(BIOS_INFO, "Verifing copy of Interrupt Routing Table at 0x%08x... ", addr);
+	printk(BIOS_INFO, "Verifying copy of Interrupt Routing Table at 0x%08x... ", addr);
 	for (i = 0; i < intel_irq_routing_table.size; i++) {
 		if (*(rt_curr + i) != *(rt_orig + i)) {
 			printk(BIOS_INFO, "failed\n");
@@ -89,7 +89,7 @@
 	printk(BIOS_INFO, "Copying Interrupt Routing Table to 0x%08lx... ", addr);
 	memcpy((void *)addr, &intel_irq_routing_table, intel_irq_routing_table.size);
 	printk(BIOS_INFO, "done.\n");
-#if CONFIG_DEBUG
+#if CONFIG_DEBUG_PIRQ
 	verify_copy_pirq_routing_table(addr);
 #endif
 	pirq_routing_irqs(addr);

Modified: trunk/src/mainboard/lippert/spacerunner-lx/romstage.c
==============================================================================
--- trunk/src/mainboard/lippert/spacerunner-lx/romstage.c	Tue Jun  1 17:19:25 2010	(r5602)
+++ trunk/src/mainboard/lippert/spacerunner-lx/romstage.c	Tue Jun  1 21:25:31 2010	(r5603)
@@ -84,7 +84,7 @@
 	if (device != DIMM0)
 		return 0xFF;	/* No DIMM1, don't even try. */
 
-#if CONFIG_DEBUG
+#if CONFIG_DEBUG_SMBUS
 	if (address >= sizeof(spdbytes) || spdbytes[address] == 0xFF) {
 		print_err("ERROR: spd_read_byte(DIMM0, 0x");
 		print_err_hex8(address);



From svn at coreboot.org  Tue Jun  1 21:28:45 2010
From: svn at coreboot.org (repository service)
Date: Tue, 01 Jun 2010 21:28:45 +0200
Subject: [coreboot] [commit] r5604 - trunk/src/arch/i386/boot
Message-ID: <E1OJX8n-0003Mp-NK@ra.coresystems.de>

Author: myles
Date: Tue Jun  1 21:28:45 2010
New Revision: 5604
URL: https://tracker.coreboot.org/trac/coreboot/changeset/5604

Log:
Fix a format string to keep the compiler happy.

Signed-off-by: Marc Bertens <mbertens at xs4all.nl>
Acked-by: Myles Watson <mylesgw at gmail.com>

Modified:
   trunk/src/arch/i386/boot/pirq_routing.c

Modified: trunk/src/arch/i386/boot/pirq_routing.c
==============================================================================
--- trunk/src/arch/i386/boot/pirq_routing.c	Tue Jun  1 21:25:31 2010	(r5603)
+++ trunk/src/arch/i386/boot/pirq_routing.c	Tue Jun  1 21:28:45 2010	(r5604)
@@ -64,7 +64,7 @@
 
 	rt_curr = (uint8_t*)addr;
 	rt_orig = (uint8_t*)&intel_irq_routing_table;
-	printk(BIOS_INFO, "Verifying copy of Interrupt Routing Table at 0x%08x... ", addr);
+	printk(BIOS_INFO, "Verifying copy of Interrupt Routing Table at 0x%08lx... ", addr);
 	for (i = 0; i < intel_irq_routing_table.size; i++) {
 		if (*(rt_curr + i) != *(rt_orig + i)) {
 			printk(BIOS_INFO, "failed\n");



From mylesgw at gmail.com  Tue Jun  1 21:36:45 2010
From: mylesgw at gmail.com (Myles Watson)
Date: Tue, 1 Jun 2010 13:36:45 -0600
Subject: [coreboot] Nokia IP530 finally fully working
In-Reply-To: <1275417032.6402.55.camel@andrala.reboot>
References: <1275337399.6402.48.camel@andrala.reboot>
	<1275417032.6402.55.camel@andrala.reboot>
Message-ID: <AANLkTilfebH_hgX3_91Omci_mvic_-JcptON-6gWmKhr@mail.gmail.com>

On Tue, Jun 1, 2010 at 12:30 PM, mbertens <mbertens at xs4all.nl> wrote:
> Hi all,
>
> a last update the dirty hack in the pirq_routing is not needed, therefor
> i made a new diff for it. This contains just the fix in the printk call,
> to keep de compiler happy, and me too :-)
>
> ? ? ? ?Signed-off : Marc Bertens <mbertens at xs4all.nl>
Acked-by: Myles Watson <mylesgw at gmail.com>

Rev 5604.

Thanks,
Myles



From buurin at gmail.com  Tue Jun  1 21:20:35 2010
From: buurin at gmail.com (Keith Hui)
Date: Tue, 1 Jun 2010 15:20:35 -0400
Subject: [coreboot] SIS630ET coreboot challenge
In-Reply-To: <4C04F2C3.6000509@assembler.cz>
References: <AANLkTikFxOKoGfkTAE0vdSpGLHAqZtso0bKKpccs5Dsi@mail.gmail.com>
	<4C04F2C3.6000509@assembler.cz>
Message-ID: <AANLkTik81g44dIUAw3R-SwPgVSdmhoGfba0sPtKdFPp5@mail.gmail.com>

This looks more like it. Thanks!

But pages 88-120 was corrupted... There goes coverage for much of the
RAM init registers.

Keith

On Tue, Jun 1, 2010 at 7:45 AM, Rudolf Marek <r.marek at assembler.cz> wrote:
> Hi,
>
> http://dev.gentoo.org/~dberkholz/articles/specifications/sis/
>
> There is a docu for sis630 maybe it is enough for you?
>
> Thanks,
> Rudolf
>



From anthony.j.mayhall at nasa.gov  Tue Jun  1 21:55:23 2010
From: anthony.j.mayhall at nasa.gov (Mayhall, Anthony J. (MSFC-ES53)[Dynamic Concepts Inc.])
Date: Tue, 1 Jun 2010 14:55:23 -0500
Subject: [coreboot] nVidia CK804 + AMD Fam 10 + Winbond Super I/O
Message-ID: <76E49B2FF96CBE4CB1DB0C8D3E7D90173EB9329284@NDMSSCC06.ndc.nasa.gov>

Has anyone ever put together a motherboard configuration using the nVidia CK804, AMD Fam 10 and Winbond W83627HF SuperI/O chipsets?  And has anyone used CoreBoot with the 6 core AMD Opteron processors?

Thanks,

Anthony Mayhall
Dynamic Concepts, Inc.
(256)544-7620




From mylesgw at gmail.com  Tue Jun  1 22:24:37 2010
From: mylesgw at gmail.com (Myles Watson)
Date: Tue, 1 Jun 2010 14:24:37 -0600
Subject: [coreboot] Nokia IP530 finally fully working
In-Reply-To: <1275337399.6402.48.camel@andrala.reboot>
References: <1275337399.6402.48.camel@andrala.reboot>
Message-ID: <AANLkTim_R66NcUDf-Ul-rAPHlZsVIa_qXJ87Vzf0QkCj@mail.gmail.com>

pcmcia-cardbus-driver.diff:

I think all three chips should be handled by the same file.

Then you'll only have to duplicate this structure:

+static const struct pci_driver ti_pci1420_driver __pci_driver = {
+        .ops    = &ti_pci1420_ops,
+        .vendor = PCI_VENDOR_ID_TI,
+        .device = PCI_DEVICE_ID_TI_1420,
+};

We don't normally use CONFIG values to set registers.  Should they
really be configurable?

+pci_write_config8( dev, 0x0C, CONFIG_DEC21143_CACHE_LINE_SIZE );

Thanks,
Myles



From anders at jenbo.dk  Tue Jun  1 22:35:15 2010
From: anders at jenbo.dk (=?utf-8?B?YW5kZXJzQGplbmJvLmRr?=)
Date: Tue, 01 Jun 2010 22:35:15 +0200
Subject: [coreboot] =?utf-8?q?Indtast_Bcc__SIS630ET_coreboot_challenge?=
Message-ID: <mailman.4188.1355071771.16123.coreboot@coreboot.org>

On my phone I am able to open page 88 to 93.

Mvh Anders

----- Reply message -----
Fra: "Keith Hui" <buurin at gmail.com>
Dato: tir., jun. 1, 2010 21:20
Emne: [coreboot] SIS630ET coreboot challenge
Til: "Rudolf Marek" <r.marek at assembler.cz>
Cc: <coreboot at coreboot.org>


This looks more like it. Thanks!

But pages 88-120 was corrupted... There goes coverage for much of the
RAM init registers.

Keith

On Tue, Jun 1, 2010 at 7:45 AM, Rudolf Marek <r.marek at assembler.cz> wrote:
> Hi,
>
> http://dev.gentoo.org/~dberkholz/articles/specifications/sis/
>
> There is a docu for sis630 maybe it is enough for you?
>
> Thanks,
> Rudolf
>

-- 
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/20100601/43dac75d/attachment.html>

From stefan.reinauer at coresystems.de  Tue Jun  1 22:59:19 2010
From: stefan.reinauer at coresystems.de (Stefan Reinauer)
Date: Tue, 01 Jun 2010 22:59:19 +0200
Subject: [coreboot] nVidia CK804 + AMD Fam 10 + Winbond Super I/O
In-Reply-To: <76E49B2FF96CBE4CB1DB0C8D3E7D90173EB9329284@NDMSSCC06.ndc.nasa.gov>
References: <76E49B2FF96CBE4CB1DB0C8D3E7D90173EB9329284@NDMSSCC06.ndc.nasa.gov>
Message-ID: <4C0574A7.4010509@coresystems.de>

On 6/1/10 9:55 PM, Mayhall, Anthony J. (MSFC-ES53)[Dynamic Concepts
Inc.] wrote:
> Has anyone ever put together a motherboard configuration using the nVidia CK804, AMD Fam 10 and Winbond W83627HF SuperI/O chipsets?  And has anyone used CoreBoot with the 6 core AMD Opteron processors?
We don't have any board like that in the tree, but all the components
seem to be supported, so it might not be too hard.

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 mbertens at xs4all.nl  Tue Jun  1 23:32:41 2010
From: mbertens at xs4all.nl (mbertens)
Date: Tue, 01 Jun 2010 23:32:41 +0200
Subject: [coreboot] Nokia IP530 finally fully working
In-Reply-To: <AANLkTim_R66NcUDf-Ul-rAPHlZsVIa_qXJ87Vzf0QkCj@mail.gmail.com>
References: <1275337399.6402.48.camel@andrala.reboot>
	<AANLkTim_R66NcUDf-Ul-rAPHlZsVIa_qXJ87Vzf0QkCj@mail.gmail.com>
Message-ID: <1275427961.6402.75.camel@andrala.reboot>

On Tue, 2010-06-01 at 14:24 -0600, Myles Watson wrote:
> pcmcia-cardbus-driver.diff:
> 
> I think all three chips should be handled by the same file.
> 
> Then you'll only have to duplicate this structure:
> 
> +static const struct pci_driver ti_pci1420_driver __pci_driver = {
> +        .ops    = &ti_pci1420_ops,
> +        .vendor = PCI_VENDOR_ID_TI,
> +        .device = PCI_DEVICE_ID_TI_1420,
> +};
hmm, when you put then in one file the image size of coreboot increases,
maybe for current systems to a problem, but there are system with less
rom space. And to create an abstraction so that later other chipset
could be easly added to it, that require some additional programming.  
Thats the reason i did it this way. But if you want then in one file no
problem.
> 
> We don't normally use CONFIG values to set registers.  Should they
> really be configurable?
> 
> +pci_write_config8( dev, 0x0C, CONFIG_DEC21143_CACHE_LINE_SIZE );
>
On my system it was needed to set this specific value to 0, but some
will need 0x40 (64). So that why i made it configurable. As for the
registers that i made configurable is for others who have the same
chipset but need for those registers other values, without making for
each board a specific piece of code just made it generic with some
CONFIG_xx values, to my opinion it makes coreboot more flexable for
other implementations.  

For the pcmcia/cardbus contollers i want to do the same thing, due to
the fact that there also are some more speficic board configuration
issues. 
>
> Thanks,
> Myles
> 


Let me know how to continue.

Thanks, Marc





From mylesgw at gmail.com  Tue Jun  1 23:53:49 2010
From: mylesgw at gmail.com (Myles Watson)
Date: Tue, 1 Jun 2010 15:53:49 -0600
Subject: [coreboot] Nokia IP530 finally fully working
In-Reply-To: <1275427961.6402.75.camel@andrala.reboot>
References: <1275337399.6402.48.camel@andrala.reboot>
	<AANLkTim_R66NcUDf-Ul-rAPHlZsVIa_qXJ87Vzf0QkCj@mail.gmail.com>
	<1275427961.6402.75.camel@andrala.reboot>
Message-ID: <AANLkTik6eKrJrFP6pI9qDV1S1k1_54iexGivo42Ck3y6@mail.gmail.com>

On Tue, Jun 1, 2010 at 3:32 PM, mbertens <mbertens at xs4all.nl> wrote:
> On Tue, 2010-06-01 at 14:24 -0600, Myles Watson wrote:
>> pcmcia-cardbus-driver.diff:
>>
>> I think all three chips should be handled by the same file.
>>
>> Then you'll only have to duplicate this structure:
>>
>> +static const struct pci_driver ti_pci1420_driver __pci_driver = {
>> + ? ? ? ?.ops ? ?= &ti_pci1420_ops,
>> + ? ? ? ?.vendor = PCI_VENDOR_ID_TI,
>> + ? ? ? ?.device = PCI_DEVICE_ID_TI_1420,
>> +};
> hmm, when you put then in one file the image size of coreboot increases,
Does it increase a lot? I'd rather have the simpler code if the
increase is less than a couple hundred bytes.

> maybe for current systems to a problem, but there are system with less
> rom space. And to create an abstraction so that later other chipset
> could be easly added to it, that require some additional programming.
> Thats the reason i did it this way. But if you want then in one file no
> problem.
>>
>> We don't normally use CONFIG values to set registers. ?Should they
>> really be configurable?
>>
>> +pci_write_config8( dev, 0x0C, CONFIG_DEC21143_CACHE_LINE_SIZE );
>>
> On my system it was needed to set this specific value to 0, but some
> will need 0x40 (64). So that why i made it configurable. As for the
> registers that i made configurable is for others who have the same
> chipset but need for those registers other values, without making for
> each board a specific piece of code just made it generic with some
> CONFIG_xx values, to my opinion it makes coreboot more flexable for
> other implementations.
If I understand correctly, different boards will need different
values, but different users of the same board will always use the same
value.

In that case, the values shouldn't be visible to the user, but should
be set in the mainboard Kconfig file.  That way only the person who
ports a new board has to care about the values.

> For the pcmcia/cardbus contollers i want to do the same thing, due to
> the fact that there also are some more speficic board configuration
> issues.
If we can move them all out of the menu, that would be great.

>
> Let me know how to continue.

You're doing fine.  It's close.

Thanks,
Myles



From r.marek at assembler.cz  Wed Jun  2 00:39:52 2010
From: r.marek at assembler.cz (Rudolf Marek)
Date: Wed, 02 Jun 2010 00:39:52 +0200
Subject: [coreboot] [RFC] Network console for coreboot
In-Reply-To: <4C02BDA2.1030101@assembler.cz>
References: <4C02BDA2.1030101@assembler.cz>
Message-ID: <4C058C38.7060607@assembler.cz>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi all,

I clean up the patch bit more. Looks way better. Question is if the ne2k.c
belongs to drivers or /lib (and where to put header file)

Otherwise it is nearly ready. I made Kconfig for that which is able to translate
the IP strings to the binary data via new funcs.

Signed-off-by: Rudolf Marek <r.marek at assembler.cz>

I think I need to kill some warnings and add some header prototypes...

Thanks,
Rudolf
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAkwFjDgACgkQ3J9wPJqZRNV3NACfScfUXCIVmspTLABf01PzSKIv
TU4An0K6d3d7jQLyi75cRVZiH9JwU7Qc
=+26L
-----END PGP SIGNATURE-----
-------------- next part --------------
A non-text attachment was scrubbed...
Name: netconsole2.patch
Type: text/x-diff
Size: 22727 bytes
Desc: not available
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20100602/5d45219d/attachment.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: netconsole2.patch.sig
Type: application/octet-stream
Size: 72 bytes
Desc: not available
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20100602/5d45219d/attachment.obj>

From rminnich at gmail.com  Wed Jun  2 04:42:11 2010
From: rminnich at gmail.com (ron minnich)
Date: Wed, 2 Jun 2010 02:42:11 +0000
Subject: [coreboot] [RFC] Network console for coreboot
In-Reply-To: <4C058C38.7060607@assembler.cz>
References: <4C02BDA2.1030101@assembler.cz>
	<4C058C38.7060607@assembler.cz>
Message-ID: <AANLkTimpDM1gHnshM9pUf25eidnJbGARkrKhqEUDuwMI@mail.gmail.com>

That is amazingly great.

BTW: http://supplier.sandia.gov/opportunities/expanded.aspx?ID=768



coreboot is mandatory. Rudolf's kind of work shows why. Sandia is
putting some money on coreboot.

ron



From peter at stuge.se  Wed Jun  2 05:21:58 2010
From: peter at stuge.se (Peter Stuge)
Date: Wed, 2 Jun 2010 05:21:58 +0200
Subject: [coreboot] [RFC] Network console for coreboot
In-Reply-To: <4C058C38.7060607@assembler.cz>
References: <4C02BDA2.1030101@assembler.cz> <4C058C38.7060607@assembler.cz>
Message-ID: <20100602032158.9681.qmail@stuge.se>

Rudolf Marek wrote:
> I clean up the patch bit more. Looks way better. Question is if the
> ne2k.c belongs to drivers or /lib (and where to put header file)

It's not a driver for initialization, it's console code, so I think
it belongs in lib, similar to usbdebug code.


> Otherwise it is nearly ready. I made Kconfig for that which is able
> to translate the IP strings to the binary data via new funcs.

It's starting to look pretty awesome! I would like some small
clarifications for the Kconfig prompts but I can send a patch or do
them myself later.

I just had a thought. Would it make sense to use syslog format for
the packets that are sent out?


> +++ src/console/Kconfig	(working copy)
> @@ -1,5 +1,31 @@
>  menu "Console options"
>  
> +config CONSOLE_NE2K
> +	bool "Ethernet console over NE2K"

Is it only for PCI clones? coreboot supports many boards with ISA
slots. Can the code work there as well if the jumper/jumperless
configured IO base is specified?


> +config CONSOLE_NE2K_DST_MAC
> +	depends on CONSOLE_NE2K
> +	string "DST unicast MAC"

We may need to create some new terminology for the network console.
(What terms are Linux using?)

The destination might be called the "console server" so here it would
say "Console server MAC address" and the help can explain further why
it's neccessary to supply it.


> +config CONSOLE_NE2K_DST_IP
> +	depends on CONSOLE_NE2K
> +	string "DST unicast IP"

Same here, "Console server IP address"


> +config CONSOLE_NE2K_SRC_IP
> +	depends on CONSOLE_NE2K
> +	string "SRC unicast IP"

Hmm, "Source IP address" maybe?


> +config CONSOLE_NE2K_IO_PORT
> +	depends on CONSOLE_NE2K
> +	hex "NE2K adapter fixed IO port"
> +	default 0xe00

If an ISA device is also allowed then it may be more difficult to add
a fixed IO resource to the device tree..


> +++ src/lib/ns8390.h	(revision 0)

This file has a bunch of register defines for various hardware (WDC,
SMC, Digital, 3Com) - are they all relevant?


//Peter



From peter at stuge.se  Wed Jun  2 05:59:59 2010
From: peter at stuge.se (Peter Stuge)
Date: Wed, 2 Jun 2010 05:59:59 +0200
Subject: [coreboot] Nokia IP530 finally fully working
In-Reply-To: <1275427961.6402.75.camel@andrala.reboot>
References: <1275337399.6402.48.camel@andrala.reboot>
	<AANLkTim_R66NcUDf-Ul-rAPHlZsVIa_qXJ87Vzf0QkCj@mail.gmail.com>
	<1275427961.6402.75.camel@andrala.reboot>
Message-ID: <20100602035959.15838.qmail@stuge.se>

mbertens wrote:
> > We don't normally use CONFIG values to set registers.  Should
> > they really be configurable?
> > 
> > +pci_write_config8( dev, 0x0C, CONFIG_DEC21143_CACHE_LINE_SIZE );
> 
> On my system it was needed to set this specific value to 0, but
> some will need 0x40 (64).

What some? Can you explain this more?


//Peter



From r.marek at assembler.cz  Wed Jun  2 09:19:40 2010
From: r.marek at assembler.cz (Rudolf Marek)
Date: Wed, 02 Jun 2010 09:19:40 +0200
Subject: [coreboot] [RFC] Network console for coreboot
In-Reply-To: <20100602032158.9681.qmail@stuge.se>
References: <4C02BDA2.1030101@assembler.cz> <4C058C38.7060607@assembler.cz>
	<20100602032158.9681.qmail@stuge.se>
Message-ID: <4C06060C.9000504@assembler.cz>

Dne 2.6.2010 05:21, Peter Stuge napsal(a):
> Rudolf Marek wrote:
>> I clean up the patch bit more. Looks way better. Question is if the
>> ne2k.c belongs to drivers or /lib (and where to put header file)
>
> It's not a driver for initialization, it's console code, so I think
> it belongs in lib, similar to usbdebug code.

ok.

>> Otherwise it is nearly ready. I made Kconfig for that which is able
>> to translate the IP strings to the binary data via new funcs.
>
> I just had a thought. Would it make sense to use syslog format for
> the packets that are sent out?

Dunno, I just use same port as Linux Netconsole, not sure if I have same format ;)

>> +++ src/console/Kconfig	(working copy)
>> @@ -1,5 +1,31 @@
>>   menu "Console options"
>>
>> +config CONSOLE_NE2K
>> +	bool "Ethernet console over NE2K"
>
> Is it only for PCI clones? coreboot supports many boards with ISA
> slots. Can the code work there as well if the jumper/jumperless
> configured IO base is specified?

Well in theory it should work for ISA cards too (NE2K) Maybe the only problem is 
the address of TX buffer which needs to be adjusted.

>> +config CONSOLE_NE2K_DST_MAC
>> +	depends on CONSOLE_NE2K
>> +	string "DST unicast MAC"
>
> We may need to create some new terminology for the network console.
> (What terms are Linux using?)

Netconsole

>
> The destination might be called the "console server" so here it would
> say "Console server MAC address" and the help can explain further why
> it's neccessary to supply it.
>
>
>> +config CONSOLE_NE2K_DST_IP
>> +	depends on CONSOLE_NE2K
>> +	string "DST unicast IP"
>
> Same here, "Console server IP address"

Yes sure
>
>
>> +config CONSOLE_NE2K_SRC_IP
>> +	depends on CONSOLE_NE2K
>> +	string "SRC unicast IP"
>
> Hmm, "Source IP address" maybe?

Yes... or Coreboot node IP address

>
>
>> +config CONSOLE_NE2K_IO_PORT
>> +	depends on CONSOLE_NE2K
>> +	hex "NE2K adapter fixed IO port"
>> +	default 0xe00
>
> If an ISA device is also allowed then it may be more difficult to add
> a fixed IO resource to the device tree..

Well this is needed because I dont do any IO probing. If we stick with the PCI 
we can just create a function which returns the BAR addr, but at the beginning 
we need some fixed non-conflicting address anyway. I consider console as add-on 
and therefore I did not put that into device tree.

>> +++ src/lib/ns8390.h	(revision 0)
>
> This file has a bunch of register defines for various hardware (WDC,
> SMC, Digital, 3Com) - are they all relevant?

Well those are other PCI clones of NE2K which are not so good compatible. We can 
delete this I think.

I have a question, did someone already test this?

Thanks,

Rudolf




From arne.gleditsch at numascale.com  Wed Jun  2 08:56:40 2010
From: arne.gleditsch at numascale.com (Arne Georg Gleditsch)
Date: Wed, 02 Jun 2010 08:56:40 +0200
Subject: [coreboot] nVidia CK804 + AMD Fam 10 + Winbond Super I/O
In-Reply-To: <76E49B2FF96CBE4CB1DB0C8D3E7D90173EB9329284@NDMSSCC06.ndc.nasa.gov>
	(Anthony J. Mayhall's message of "Tue, 1 Jun 2010 14:55:23 -0500")
References: <76E49B2FF96CBE4CB1DB0C8D3E7D90173EB9329284@NDMSSCC06.ndc.nasa.gov>
Message-ID: <87y6exorbr.fsf@taniquetil.gledits.ch>

"Mayhall, Anthony J. (MSFC-ES53)[Dynamic Concepts Inc.]"
<anthony.j.mayhall at nasa.gov> writes:
> Has anyone ever put together a motherboard configuration using the
> nVidia CK804, AMD Fam 10 and Winbond W83627HF SuperI/O chipsets?  And
> has anyone used CoreBoot with the 6 core AMD Opteron processors?

I'm using coreboot with 8431 Opterons.

-- 
							Arne.



From mbertens at xs4all.nl  Wed Jun  2 18:54:56 2010
From: mbertens at xs4all.nl (mbertens)
Date: Wed, 02 Jun 2010 18:54:56 +0200
Subject: [coreboot] Documentation
Message-ID: <1275497696.3803.3.camel@andrala.reboot>

Hi all,

i wrote a document how to flash an Nokia IP530, it can be found at
http://www.xs4all.nl/~mbertens/Ip530. i think maybe a an idea to put it
on the coreboot webside.

Marc 




From marcj303 at gmail.com  Wed Jun  2 21:08:46 2010
From: marcj303 at gmail.com (Marc Jones)
Date: Wed, 2 Jun 2010 13:08:46 -0600
Subject: [coreboot] Documentation
In-Reply-To: <1275497696.3803.3.camel@andrala.reboot>
References: <1275497696.3803.3.camel@andrala.reboot>
Message-ID: <AANLkTini72W-ag057v_ZW0hBSXt-rHp38UEKhuIk5H2Z@mail.gmail.com>

On Wed, Jun 2, 2010 at 10:54 AM, mbertens <mbertens at xs4all.nl> wrote:
> Hi all,
>
> i wrote a document how to flash an Nokia IP530, it can be found at
> http://www.xs4all.nl/~mbertens/Ip530. i think maybe a an idea to put it
> on the coreboot webside.

Hi Marc,

Very nice. Just get a wiki account and add it. Thanks for the
contributions these last several weeks.

Marc



-- 
http://se-eng.com



From peter at stuge.se  Wed Jun  2 21:54:57 2010
From: peter at stuge.se (Peter Stuge)
Date: Wed, 2 Jun 2010 21:54:57 +0200
Subject: [coreboot] Documentation
In-Reply-To: <1275497696.3803.3.camel@andrala.reboot>
References: <1275497696.3803.3.camel@andrala.reboot>
Message-ID: <20100602195457.28749.qmail@stuge.se>

mbertens wrote:
> http://www.xs4all.nl/~mbertens/Ip530

Very nice! But please remember that coreboot is absolutely not an
open source BIOS. You get an open source BIOS only when coreboot is
combined with SeaBIOS. BIOS implies a ton of stuff that coreboot does
not and does not want to implement. SeaBIOS takes care of that job.


> i think maybe a an idea to put it on the coreboot webside.

I agree!


//Peter



From joe at settoplinux.org  Wed Jun  2 22:49:07 2010
From: joe at settoplinux.org (Joseph Smith)
Date: Wed, 02 Jun 2010 16:49:07 -0400
Subject: [coreboot] Documentation
In-Reply-To: <AANLkTini72W-ag057v_ZW0hBSXt-rHp38UEKhuIk5H2Z@mail.gmail.com>
References: <1275497696.3803.3.camel@andrala.reboot>
	<AANLkTini72W-ag057v_ZW0hBSXt-rHp38UEKhuIk5H2Z@mail.gmail.com>
Message-ID: <4C06C3C3.60301@settoplinux.org>

On 06/02/2010 03:08 PM, Marc Jones wrote:
> On Wed, Jun 2, 2010 at 10:54 AM, mbertens<mbertens at xs4all.nl>  wrote:
>> Hi all,
>>
>> i wrote a document how to flash an Nokia IP530, it can be found at
>> http://www.xs4all.nl/~mbertens/Ip530. i think maybe a an idea to put it
>> on the coreboot webside.
>
> Hi Marc,
>
> Very nice. Just get a wiki account and add it. Thanks for the
> contributions these last several weeks.
>
Yes, I bet if you ask Stefan very nicely he will set you up with a wiki 
account :-)

-- 
Thanks,
Joseph Smith
Set-Top-Linux
www.settoplinux.org



From svn at coreboot.org  Wed Jun  2 23:13:44 2010
From: svn at coreboot.org (repository service)
Date: Wed, 02 Jun 2010 23:13:44 +0200
Subject: [coreboot] [commit] r5605 - trunk/src/devices
Message-ID: <E1OJvFw-0001gP-RB@ra.coresystems.de>

Author: myles
Date: Wed Jun  2 23:13:44 2010
New Revision: 5605
URL: https://tracker.coreboot.org/trac/coreboot/changeset/5605

Log:
Fix hard-coded log levels.

Signed-off-by: Myles Watson <mylesgw at gmail.com>
Acked-by: Myles Watson <mylesgw at gmail.com>

Modified:
   trunk/src/devices/device_util.c

Modified: trunk/src/devices/device_util.c
==============================================================================
--- trunk/src/devices/device_util.c	Tue Jun  1 21:28:45 2010	(r5604)
+++ trunk/src/devices/device_util.c	Wed Jun  2 23:13:44 2010	(r5605)
@@ -599,12 +599,12 @@
 		indent[i] = ' ';
 	indent[i] = '\0';
 
-	do_printk(BIOS_DEBUG, "%s%s links %x child on link 0", indent,
+	do_printk(debug_level, "%s%s links %x child on link 0", indent,
 		  dev_path(root), root->links);
-	do_printk(BIOS_DEBUG, " %s\n", root->link[0].children ?
+	do_printk(debug_level, " %s\n", root->link[0].children ?
 		  dev_path(root->link[0].children) : "NULL");
 	for (res = root->resource_list; res; res = res->next) {
-		do_printk(BIOS_DEBUG,
+		do_printk(debug_level,
 			  "%s%s resource base %llx size %llx align %d gran %d limit %llx flags %lx index %lx\n",
 			  indent, dev_path(root), res->base,
 			  res->size, res->align,



From r.marek at assembler.cz  Wed Jun  2 23:40:39 2010
From: r.marek at assembler.cz (Rudolf Marek)
Date: Wed, 02 Jun 2010 23:40:39 +0200
Subject: [coreboot] [RFC] Network console for coreboot
In-Reply-To: <4C02BDA2.1030101@assembler.cz>
References: <4C02BDA2.1030101@assembler.cz>
Message-ID: <4C06CFD7.3010604@assembler.cz>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi all,

I hope here is a final version. I added the missing header files and did some
random fixes (typos, Kconfig more descriptive, GPL in header file)

Signed-off-by: Rudolf Marek <r.marek at assembler.cz>

This patch adds support for console over Ethernet.

Thanks,
Rudolf

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAkwGz9YACgkQ3J9wPJqZRNWwhACdE33j3MkMrJiZemlI2Jke5k8E
U2IAn3DO8fAzX5wwCzkiSpyxaTmY/5bO
=sdL0
-----END PGP SIGNATURE-----
-------------- next part --------------
A non-text attachment was scrubbed...
Name: netconsole3.patch
Type: text/x-diff
Size: 21180 bytes
Desc: not available
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20100602/91075191/attachment.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: netconsole3.patch.sig
Type: application/octet-stream
Size: 72 bytes
Desc: not available
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20100602/91075191/attachment.obj>

From Zheng.Bao at amd.com  Thu Jun  3 08:24:43 2010
From: Zheng.Bao at amd.com (Bao, Zheng)
Date: Thu, 3 Jun 2010 14:24:43 +0800
Subject: [coreboot] [patch]: fixing a typo in rs780_gfx
Message-ID: <DD1CC71B621B004FA76856E5129D6B1703C75FFE@sbjgexmb1.amd.com>

The code was ported. Now it is what it should be.

Signed-off-by: Zheng Bao <zheng.bao at amd.com>

Index: src/southbridge/amd/rs780/rs780_gfx.c
===================================================================
--- src/southbridge/amd/rs780/rs780_gfx.c	(revision 5605)
+++ src/southbridge/amd/rs780/rs780_gfx.c	(working copy)
@@ -337,7 +337,7 @@
 	value = nbmc_read_index(nb_dev, 0x10);
 	*(GpuF0MMReg + 0x2000/4) = 0x11;
 	*(GpuF0MMReg + 0x2180/4) =
((value&0xff00)>>8)|((value&0xff000000)>>8);
-	*(GpuF0MMReg + 0x2c04/4) = ((value&0xff0)<<8);
+	*(GpuF0MMReg + 0x2c04/4) = ((value&0xff00)<<8);
 	*(GpuF0MMReg + 0x5428/4) =
((value&0xffff0000)+0x10000)-((value&0xffff)<<16);
 	*(GpuF0MMReg + 0x2000/4) = 0x00000011;
 	*(GpuF0MMReg + 0x200c/4) = 0x00000020;
-------------- next part --------------
A non-text attachment was scrubbed...
Name: rs780_gfx_fix_typo.patch
Type: application/octet-stream
Size: 756 bytes
Desc: rs780_gfx_fix_typo.patch
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20100603/c3f96dfa/attachment.obj>

From stepan at coresystems.de  Thu Jun  3 09:33:58 2010
From: stepan at coresystems.de (Stefan Reinauer)
Date: Thu, 03 Jun 2010 09:33:58 +0200
Subject: [coreboot] [patch]: fixing a typo in rs780_gfx
In-Reply-To: <DD1CC71B621B004FA76856E5129D6B1703C75FFE@sbjgexmb1.amd.com>
References: <DD1CC71B621B004FA76856E5129D6B1703C75FFE@sbjgexmb1.amd.com>
Message-ID: <4C075AE6.7090102@coresystems.de>

On 6/3/10 8:24 AM, Bao, Zheng wrote:
> The code was ported. Now it is what it should be.
>
> Signed-off-by: Zheng Bao <zheng.bao at amd.com>
>   
Acked-by: Stefan Reinauer <stepan at coresystems.de>
> Index: src/southbridge/amd/rs780/rs780_gfx.c
> ===================================================================
> --- src/southbridge/amd/rs780/rs780_gfx.c	(revision 5605)
> +++ src/southbridge/amd/rs780/rs780_gfx.c	(working copy)
> @@ -337,7 +337,7 @@
>  	value = nbmc_read_index(nb_dev, 0x10);
>  	*(GpuF0MMReg + 0x2000/4) = 0x11;
>  	*(GpuF0MMReg + 0x2180/4) =
> ((value&0xff00)>>8)|((value&0xff000000)>>8);
> -	*(GpuF0MMReg + 0x2c04/4) = ((value&0xff0)<<8);
> +	*(GpuF0MMReg + 0x2c04/4) = ((value&0xff00)<<8);
>  	*(GpuF0MMReg + 0x5428/4) =
> ((value&0xffff0000)+0x10000)-((value&0xffff)<<16);
>  	*(GpuF0MMReg + 0x2000/4) = 0x00000011;
>  	*(GpuF0MMReg + 0x200c/4) = 0x00000020;
>   




From svn at coreboot.org  Thu Jun  3 09:51:09 2010
From: svn at coreboot.org (repository service)
Date: Thu, 03 Jun 2010 09:51:09 +0200
Subject: [coreboot] [commit] r5606 - trunk/src/southbridge/amd/rs780
Message-ID: <E1OK5Cn-0006Cl-Mp@ra.coresystems.de>

Author: zbao
Date: Thu Jun  3 09:51:09 2010
New Revision: 5606
URL: https://tracker.coreboot.org/trac/coreboot/changeset/5606

Log:
The code was ported. Now it is what it should be.

Signed-off-by: Zheng Bao <zheng.bao at amd.com>
Acked-by: Stefan Reinauer <stepan at coresystems.de>

Modified:
   trunk/src/southbridge/amd/rs780/rs780_gfx.c

Modified: trunk/src/southbridge/amd/rs780/rs780_gfx.c
==============================================================================
--- trunk/src/southbridge/amd/rs780/rs780_gfx.c	Wed Jun  2 23:13:44 2010	(r5605)
+++ trunk/src/southbridge/amd/rs780/rs780_gfx.c	Thu Jun  3 09:51:09 2010	(r5606)
@@ -337,7 +337,7 @@
 	value = nbmc_read_index(nb_dev, 0x10);
 	*(GpuF0MMReg + 0x2000/4) = 0x11;
 	*(GpuF0MMReg + 0x2180/4) = ((value&0xff00)>>8)|((value&0xff000000)>>8);
-	*(GpuF0MMReg + 0x2c04/4) = ((value&0xff0)<<8);
+	*(GpuF0MMReg + 0x2c04/4) = ((value&0xff00)<<8);
 	*(GpuF0MMReg + 0x5428/4) = ((value&0xffff0000)+0x10000)-((value&0xffff)<<16);
 	*(GpuF0MMReg + 0x2000/4) = 0x00000011;
 	*(GpuF0MMReg + 0x200c/4) = 0x00000020;



From svn at coreboot.org  Thu Jun  3 12:06:13 2010
From: svn at coreboot.org (coreboot)
Date: Thu, 03 Jun 2010 10:06:13 -0000
Subject: [coreboot] #165: Geode VSA re-parsing to elf fails on 64 bit
 platforms
Message-ID: <063.c71f8433ce0f07bd94755266a552fc67@coreboot.org>

#165: Geode VSA re-parsing to elf fails on 64 bit platforms
--------------------------------------------+-------------------------------
    Reporter:  edwin_beasant@?              |         Owner:  stepan@?             
        Type:  defect                       |        Status:  new                  
    Priority:  major                        |     Milestone:  Going mainstream     
   Component:  coreboot                     |      Keywords:  VSA Geode ld cbfs    
Dependencies:                               |   Patchstatus:  patch needs review   
--------------------------------------------+-------------------------------
 When compiling coreboot on a platform that uses the elf_x86_64 emulation
 as its default linker emulation, ld barfs when trying to re-mangle the VSA
 for addition to the CBFS.

 The VSA in inherently 32-bit (as determined by the previous objcopy line)
 and therefore the linker emulation option should probably follow the
 convention.

 The attached patch fixes this by adding the "-m elf_i386" option to the ld
 line for converting the VSA.
 Thanks,
 Edwin

-- 
Ticket URL: <https://tracker.coreboot.org/trac/coreboot/ticket/165>
coreboot <http://www.coreboot.org/>


From mbertens at xs4all.nl  Thu Jun  3 19:28:28 2010
From: mbertens at xs4all.nl (mbertens)
Date: Thu, 03 Jun 2010 19:28:28 +0200
Subject: [coreboot] Documentation
In-Reply-To: <4C06C3C3.60301@settoplinux.org>
References: <1275497696.3803.3.camel@andrala.reboot>
	<AANLkTini72W-ag057v_ZW0hBSXt-rHp38UEKhuIk5H2Z@mail.gmail.com>
	<4C06C3C3.60301@settoplinux.org>
Message-ID: <1275586108.3803.8.camel@andrala.reboot>

On Wed, 2010-06-02 at 16:49 -0400, Joseph Smith wrote:
> On 06/02/2010 03:08 PM, Marc Jones wrote:
> > On Wed, Jun 2, 2010 at 10:54 AM, mbertens<mbertens at xs4all.nl>  wrote:
> >> Hi all,
> >>
> >> i wrote a document how to flash an Nokia IP530, it can be found at
> >> http://www.xs4all.nl/~mbertens/Ip530. i think maybe a an idea to put it
> >> on the coreboot webside.
> >
> > Hi Marc,
> >
> > Very nice. Just get a wiki account and add it. Thanks for the
> > contributions these last several weeks.
> >
> Yes, I bet if you ask Stefan very nicely he will set you up with a wiki 
> account :-)
> 
That would realy great, i have lots of ideas for documentation. 
So Stepan the question to you, may i have a WIKI account, and asked
this, how do the reviews work for this ?. Because this is realy
importend to me :-) as you could read in the HOWTO document that i wrote
already.

Marc   





From mbertens at xs4all.nl  Thu Jun  3 19:31:04 2010
From: mbertens at xs4all.nl (mbertens)
Date: Thu, 03 Jun 2010 19:31:04 +0200
Subject: [coreboot] Documentation
In-Reply-To: <AANLkTini72W-ag057v_ZW0hBSXt-rHp38UEKhuIk5H2Z@mail.gmail.com>
References: <1275497696.3803.3.camel@andrala.reboot>
	<AANLkTini72W-ag057v_ZW0hBSXt-rHp38UEKhuIk5H2Z@mail.gmail.com>
Message-ID: <1275586264.3803.11.camel@andrala.reboot>

On Wed, 2010-06-02 at 13:08 -0600, Marc Jones wrote:
> On Wed, Jun 2, 2010 at 10:54 AM, mbertens <mbertens at xs4all.nl> wrote:
> > Hi all,
> >
> > i wrote a document how to flash an Nokia IP530, it can be found at
> > http://www.xs4all.nl/~mbertens/Ip530. i think maybe a an idea to put it
> > on the coreboot webside.
> 
> Hi Marc,
> 
> Very nice. Just get a wiki account and add it. Thanks for the
> contributions these last several weeks.
Do you want the word document ? instead of the PDF? 
Let me known
> 
> Marc
> 
> 
> 
> -- 
> http://se-eng.com
> 

Marc




From svn at coreboot.org  Thu Jun  3 19:36:15 2010
From: svn at coreboot.org (repository service)
Date: Thu, 03 Jun 2010 19:36:15 +0200
Subject: [coreboot] [FILO] r133 - in trunk/filo: fs main/grub
Message-ID: <E1OKEL1-0004wG-Ex@ra.coresystems.de>

Author: stepan
Date: Thu Jun  3 19:36:15 2010
New Revision: 133
URL: http://tracker.coreboot.org/trac/filo/changeset/133

Log:
initial tab completion support. device matching fails, so only commands can be completed so far. 
Signed-off-by: Stefan Reinauer <stepan at coresystems.de>

Modified:
   trunk/filo/fs/vfs.c
   trunk/filo/main/grub/completions.c

Modified: trunk/filo/fs/vfs.c
==============================================================================
--- trunk/filo/fs/vfs.c	Mon May 24 23:59:35 2010	(r132)
+++ trunk/filo/fs/vfs.c	Thu Jun  3 19:36:15 2010	(r133)
@@ -240,3 +240,71 @@
 {
 	devclose();
 }
+
+int dir(char *dirname)
+{
+	char *dev = 0;
+	const char *path;
+	int len;
+	int retval = 0;
+	int reopen;
+
+	path = strchr(dirname, ':');
+	if (path) {
+		len = path - dirname;
+		path++;
+		dev = malloc(len + 1);
+		memcpy(dev, dirname, len);
+		dev[len] = '\0';
+	} else {
+		/* No colon is given. Is this device or dirname? */
+		if (dirname[0] == '/') {
+			/* Anything starts with '/' must be a dirname */
+			dev = 0;
+			path = dirname;
+		} else {
+			dev = strdup(dirname);
+			path = 0;
+		}
+	}
+	debug("dev=%s, path=%s\n", dev, path);
+
+	if (dev && dev[0]) {
+		if (!devopen(dev, &reopen)) {
+			fsys = 0;
+			goto out;
+		}
+		if (!reopen)
+			fsys = 0;
+	}
+
+	if (path) {
+		if (!fsys || fsys == &nullfs) {
+			if (!mount_fs())
+				goto out;
+		}
+		using_devsize = 0;
+		if (!path[0]) {
+			printf("No dirname is given.\n");
+			goto out;
+		}
+	} else {
+		fsys = &nullfs;
+	}
+
+	filepos = 0;
+	errnum = 0;
+
+	/* set "dir" function to list completions */
+	print_possibilities = 1;
+
+	retval = fsys->dir_func((char *) path);
+
+out:
+	if (dev)
+		free(dev);
+
+	return retval;
+}
+
+

Modified: trunk/filo/main/grub/completions.c
==============================================================================
--- trunk/filo/main/grub/completions.c	Mon May 24 23:59:35 2010	(r132)
+++ trunk/filo/main/grub/completions.c	Thu Jun  3 19:36:15 2010	(r133)
@@ -22,11 +22,47 @@
 #include <libpayload.h>
 #include <config.h>
 #include <grub/shared.h>
+#define current_slice 0
 
 static int do_completion;
 static int unique;
 static char *unique_string;
 
+static int incomplete, disk_choice;
+static enum
+{
+	PART_UNSPECIFIED = 0,
+	PART_DISK,
+	PART_CHOSEN,
+} part_choice;
+
+int
+real_open_partition (int flags)
+{
+	errnum = ERR_NONE;
+	return 1;
+}
+
+int
+open_partition (void)
+{
+	return real_open_partition (0);
+}
+
+char *
+set_device (char *device)
+{
+	int result = 0;
+
+	if (result) {
+		return device + 1;
+	} else {
+		if (!*device)
+			incomplete = 1;
+		errnum = ERR_DEV_FORMAT;
+	}
+	return 0;
+}
 
 /* If DO_COMPLETION is true, just print NAME. Otherwise save the unique
    part into UNIQUE_STRING.  */
@@ -62,7 +98,6 @@
 
 int print_completions(int is_filename, int is_completion)
 {
-#ifdef CONFIG_EXPERIMENTAL
 	char *buf = (char *) COMPLETION_BUF;
 	char *ptr = buf;
 
@@ -71,10 +106,162 @@
 	unique = 0;
 	do_completion = is_completion;
 
-#warning FIXME implement print_completions
-	// FIXME: This function is a dummy, returning an error.
-	errnum = ERR_BAD_FILENAME;
+	if (!is_filename) {
+		/* Print the completions of builtin commands.  */
+		struct builtin **builtin;
+
+		if (!is_completion)
+			grub_printf (" Possible commands are:");
+
+		for (builtin = builtin_table; (*builtin); builtin++) {
+			/* If *builtin cannot be run in the command-line, skip it. */
+			if (!((*builtin)->flags & BUILTIN_CMDLINE))
+				continue;
+			if (substring (buf, (*builtin)->name) <= 0)
+				print_a_completion ((*builtin)->name);
+		}
 
+		if (is_completion && *unique_string) {
+			if (unique == 1) {
+				char *u = unique_string + strlen (unique_string);
+				*u++ = ' ';
+				*u = 0;
+			}
+			strcpy (buf, unique_string);
+		}
+
+		if (!is_completion)
+			grub_putchar ('\n');
+
+		print_error();
+		do_completion = 0;
+		if (errnum)
+			return -1;
+		else
+			return unique - 1;
+	}
+
+	if (*buf == '/' || (ptr = set_device (buf)) || incomplete) {
+		errnum = 0;
+		if (*buf == '(' && (incomplete || ! *ptr)) {
+			if (!part_choice) {
+				/* disk completions */
+				int disk_no, i, j;
+
+				if (!is_completion)
+					grub_printf (" Possible disks are: ");
+
+				if (!ptr
+					|| *(ptr-1) != 'd'
+					|| *(ptr-2) != 'n' /* netboot? */
+					|| *(ptr-2) != 'c') {
+					for (i = (ptr && (*(ptr-1) == 'd' && *(ptr-2) == 'h') ? 1:0);
+					     i < (ptr && (*(ptr-1) == 'd' && *(ptr-2) == 'f') ?  1:2);
+					     i++) {
+						for (j = 0; j < 8; j++) {
+							if ((disk_choice)) { // TODO check geometry
+								char dev_name[8];
+								sprintf (dev_name, "%cd%d", i ?  'h':'f', j);
+								print_a_completion(dev_name);
+							}
+						}
+					}
+				}
+
+#if 0
+				if (cdrom_drive != GRUB_INVALID_DRIVE
+				    && (disk_choice || cdrom_drive == current_drive)
+				    && (!ptr
+					|| *(ptr-1) == '('
+					|| (*(ptr-1) == 'd' && *(ptr-2) == 'c')))
+					print_a_completion("cd");
+#endif
+
+				if (is_completion && *unique_string) {
+					ptr = buf;
+					while (*ptr != '(')
+						ptr--;
+					ptr++;
+					strcpy (ptr, unique_string);
+					if (unique == 1) {
+						ptr += strlen (ptr);
+						if (*unique_string == 'h') {
+							*ptr++ = ',';
+							*ptr = 0;
+						} else {
+							*ptr++ = ')';
+							*ptr = 0;
+						}
+					}
+				}
+
+				if (!is_completion)
+					grub_putchar('\n');
+			} else {
+				/* Partition completions */
+				if (part_choice == PART_CHOSEN
+				    && open_partition()
+				    && ! IS_PC_SLICE_TYPE_BSD(current_slice)) {
+					unique = 1;
+					ptr = buf + strlen(buf);
+					if (*(ptr - 1) != ')') {
+						*ptr++ = ')';
+						*ptr = 0;
+					}
+				} else {
+					if (!is_completion)
+						grub_printf (" Possible partitions are:\n");
+					real_open_partition(1);
+					if (is_completion && *unique_string) {
+						ptr = buf;
+						while (*ptr++ != ',')
+							;
+						strcpy (ptr, unique_string);
+					}
+				}
+			}
+		} else if (ptr && *ptr == '/') {
+			/* filename completions */
+			if (!is_completion)
+				grub_printf (" Possible files are:");
+			dir(buf);
+
+			if (is_completion && *unique_string) {
+				ptr += strlen (ptr);
+				while (*ptr != '/')
+					ptr--;
+				ptr++;
+
+				strcpy(ptr, unique_string);
+
+				if (unique == 1) {
+					ptr += strlen (unique_string);
+
+					/* Check if the file UNIQUE_STRING is a directory.  */
+					*ptr = '/';
+					*(ptr + 1) = 0;
+
+					dir (buf);
+
+					/* Restore the original unique value. */
+					unique = 1;
+
+					if (errnum) {
+						/* regular file */
+						errnum = 0;
+						*ptr = ' ';
+						*(ptr + 1) = 0;
+					}
+				}
+			}
+
+			if (!is_completion)
+				grub_putchar ('\n');
+
+		} else {
+			errnum = ERR_BAD_FILENAME;
+		}
+	}
 
 	print_error();
 	do_completion = 0;
@@ -82,9 +269,4 @@
 		return -1;
 	else
 		return unique - 1;
-#else
-	errnum = ERR_BAD_FILENAME;
-	print_error();
-	return -1;
-#endif
 }



From mbertens at xs4all.nl  Thu Jun  3 19:48:18 2010
From: mbertens at xs4all.nl (mbertens)
Date: Thu, 03 Jun 2010 19:48:18 +0200
Subject: [coreboot] Update on NOKIA-IP530
Message-ID: <1275587298.3803.21.camel@andrala.reboot>

Hi all,

I have updated the point that where passed to me.

- Moved the register CONFIG items for the drivers to the board Kconfig.
- Placed the PCMCIA./CardBus drivers all to one file, with #if(s) to
make sure that only included in the code that was selected for a board.
- Unfortunate we still need ti dirty hack in arch\i386\boot
\pirq_routing.c this should be fixed within the code of coreboot. But my
unfamiliarly with that code its not a good idea that i make that fix.
But i'm of cource willing to patch it on the Nokia code and test it. I
hope that you will consider applying the patch for the mean while, its
guarded by the #if CONFIG_BOARD_NOKIA_IP530 so nobody shall have any
problems with it.



Marc 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: arch-pirq-routing.diff
Type: text/x-patch
Size: 745 bytes
Desc: not available
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20100603/24b2efda/attachment.diff>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: drivers.diff
Type: text/x-patch
Size: 10379 bytes
Desc: not available
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20100603/24b2efda/attachment-0001.diff>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: nokia.diff
Type: text/x-patch
Size: 12237 bytes
Desc: not available
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20100603/24b2efda/attachment-0002.diff>

From stepan at coresystems.de  Thu Jun  3 20:04:22 2010
From: stepan at coresystems.de (Stefan Reinauer)
Date: Thu, 03 Jun 2010 20:04:22 +0200
Subject: [coreboot] Documentation
In-Reply-To: <1275586108.3803.8.camel@andrala.reboot>
References: <1275497696.3803.3.camel@andrala.reboot>	
	<AANLkTini72W-ag057v_ZW0hBSXt-rHp38UEKhuIk5H2Z@mail.gmail.com>	
	<4C06C3C3.60301@settoplinux.org>
	<1275586108.3803.8.camel@andrala.reboot>
Message-ID: <4C07EEA6.1080705@coresystems.de>

On 6/3/10 7:28 PM, mbertens wrote:
> On Wed, 2010-06-02 at 16:49 -0400, Joseph Smith wrote:
>   
>> On 06/02/2010 03:08 PM, Marc Jones wrote:
>>     
>>> On Wed, Jun 2, 2010 at 10:54 AM, mbertens<mbertens at xs4all.nl>  wrote:
>>>       
>>>> Hi all,
>>>>
>>>> i wrote a document how to flash an Nokia IP530, it can be found at
>>>> http://www.xs4all.nl/~mbertens/Ip530. i think maybe a an idea to put it
>>>> on the coreboot webside.
>>>>         
>>> Hi Marc,
>>>
>>> Very nice. Just get a wiki account and add it. Thanks for the
>>> contributions these last several weeks.
>>>
>>>       
>> Yes, I bet if you ask Stefan very nicely he will set you up with a wiki 
>> account :-)
>>
>>     
> That would realy great, i have lots of ideas for documentation. 
> So Stepan the question to you, may i have a WIKI account, and asked
> this, how do the reviews work for this ?. Because this is realy
> importend to me :-) as you could read in the HOWTO document that i wrote
> already.
>
>   

Account created. See the other mail for credentials

Stefan





From mbertens at xs4all.nl  Thu Jun  3 21:01:58 2010
From: mbertens at xs4all.nl (mbertens)
Date: Thu, 03 Jun 2010 21:01:58 +0200
Subject: [coreboot] Documentation
In-Reply-To: <4C07EEA6.1080705@coresystems.de>
References: <1275497696.3803.3.camel@andrala.reboot>
	<AANLkTini72W-ag057v_ZW0hBSXt-rHp38UEKhuIk5H2Z@mail.gmail.com>
	<4C06C3C3.60301@settoplinux.org>
	<1275586108.3803.8.camel@andrala.reboot>
	<4C07EEA6.1080705@coresystems.de>
Message-ID: <1275591718.3803.23.camel@andrala.reboot>

On Thu, 2010-06-03 at 20:04 +0200, Stefan Reinauer wrote:
> On 6/3/10 7:28 PM, mbertens wrote:
> > On Wed, 2010-06-02 at 16:49 -0400, Joseph Smith wrote:
> >   
> >> On 06/02/2010 03:08 PM, Marc Jones wrote:
> >>     
> >>> On Wed, Jun 2, 2010 at 10:54 AM, mbertens<mbertens at xs4all.nl>  wrote:
> >>>       
> >>>> Hi all,
> >>>>
> >>>> i wrote a document how to flash an Nokia IP530, it can be found at
> >>>> http://www.xs4all.nl/~mbertens/Ip530. i think maybe a an idea to put it
> >>>> on the coreboot webside.
> >>>>         
> >>> Hi Marc,
> >>>
> >>> Very nice. Just get a wiki account and add it. Thanks for the
> >>> contributions these last several weeks.
> >>>
> >>>       
> >> Yes, I bet if you ask Stefan very nicely he will set you up with a wiki 
> >> account :-)
> >>
> >>     
> > That would realy great, i have lots of ideas for documentation. 
> > So Stepan the question to you, may i have a WIKI account, and asked
> > this, how do the reviews work for this ?. Because this is realy
> > importend to me :-) as you could read in the HOWTO document that i wrote
> > already.
> >
> >   
> 
> Account created. See the other mail for credentials
> 
> Stefan
> 
> 
Thanks Stepan

Marc





From mylesgw at gmail.com  Thu Jun  3 21:29:51 2010
From: mylesgw at gmail.com (Myles Watson)
Date: Thu, 3 Jun 2010 13:29:51 -0600
Subject: [coreboot] Update on NOKIA-IP530
In-Reply-To: <1275587298.3803.21.camel@andrala.reboot>
References: <1275587298.3803.21.camel@andrala.reboot>
Message-ID: <AANLkTin9LTl7QGCMz5vypyx0Y7_9vmDA0UXQPZq4-7ug@mail.gmail.com>

> - Unfortunate we still need ti dirty hack in arch\i386\boot
> \pirq_routing.c this should be fixed within the code of coreboot. But my
> unfamiliarly with that code its not a good idea that i make that fix.
> But i'm of cource willing to patch it on the Nokia code and test it. I
> hope that you will consider applying the patch for the mean while, its
> guarded by the #if CONFIG_BOARD_NOKIA_IP530 so nobody shall have any
> problems with it.
>From your earlier mail:
a last update the dirty hack in the pirq_routing is not needed, therefor
i made a new diff for it.

Was it just a mistake that you didn't need it?

Thanks,
Myles



From mylesgw at gmail.com  Thu Jun  3 23:02:29 2010
From: mylesgw at gmail.com (Myles Watson)
Date: Thu, 3 Jun 2010 15:02:29 -0600
Subject: [coreboot] Update on NOKIA-IP530
In-Reply-To: <1275587298.3803.21.camel@andrala.reboot>
References: <1275587298.3803.21.camel@andrala.reboot>
Message-ID: <AANLkTikkwYfB9HHShBPnGkgjWqpe2m54t9hpqREbwlOH@mail.gmail.com>

Marc,

Here's your patch with a couple of changes:
1. took out white space changes so that I could see the devicetree.cb changes
 - I understood most of the changes, but why remove the register
settings for the keyboard and mouse?
 - there's no reason we can' t use tabs when it gets committed, I just
couldn't see the differences.

2. changed the Kconfig a little for your drivers
 - Kconfig of drivers shouldn't show up in the menu.  If you build
this board, you want it to have all the drivers.

Signed-off-by: Myles Watson <mylesgw at gmail.com>

Thanks,
Myles
-------------- next part --------------
A non-text attachment was scrubbed...
Name: nokia.diff
Type: text/x-patch
Size: 11283 bytes
Desc: not available
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20100603/118ceb96/attachment.diff>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: drivers.diff
Type: text/x-patch
Size: 9158 bytes
Desc: not available
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20100603/118ceb96/attachment-0001.diff>

From mylesgw at gmail.com  Thu Jun  3 23:09:07 2010
From: mylesgw at gmail.com (Myles Watson)
Date: Thu, 3 Jun 2010 15:09:07 -0600
Subject: [coreboot] Update on NOKIA-IP530
In-Reply-To: <AANLkTikkwYfB9HHShBPnGkgjWqpe2m54t9hpqREbwlOH@mail.gmail.com>
References: <1275587298.3803.21.camel@andrala.reboot>
	<AANLkTikkwYfB9HHShBPnGkgjWqpe2m54t9hpqREbwlOH@mail.gmail.com>
Message-ID: <AANLkTiliPjg1CaO_ri7UjSHBTw7qLFZLWj9-1KtHuDZv@mail.gmail.com>

Marc,

A couple of picky details I forgot to mention:
- Since Nokia isn't an acronym, it should probably stay Nokia, not
NOKIA in the board string.
- The purpose of HAVE_ vs. GENERATE_ variables is:
  - HAVE_PIRQ_TABLES specifies that the board has a PIRQ table
  - GENERATE_PIRQ_TABLES lets the user decide if it should be built
Since GENERATE_ defaults to HAVE_, board Kconfigs should just set HAVE_

Thanks,
Myles



From mylesgw at gmail.com  Thu Jun  3 23:12:02 2010
From: mylesgw at gmail.com (Myles Watson)
Date: Thu, 3 Jun 2010 15:12:02 -0600
Subject: [coreboot] Update on NOKIA-IP530
In-Reply-To: <AANLkTikkwYfB9HHShBPnGkgjWqpe2m54t9hpqREbwlOH@mail.gmail.com>
References: <1275587298.3803.21.camel@andrala.reboot>
	<AANLkTikkwYfB9HHShBPnGkgjWqpe2m54t9hpqREbwlOH@mail.gmail.com>
Message-ID: <AANLkTil90azgdY4b1sGlJ047eX07KEYq7zjq4YpNBog0@mail.gmail.com>

On Thu, Jun 3, 2010 at 3:02 PM, Myles Watson <mylesgw at gmail.com> wrote:
> Marc,
>
> Here's your patch with a couple of changes:
> 1. took out white space changes so that I could see the devicetree.cb changes
> ?- I understood most of the changes, but why remove the register
> settings for the keyboard and mouse?
> ?- there's no reason we can' t use tabs when it gets committed, I just
> couldn't see the differences.
>
> 2. changed the Kconfig a little for your drivers
> ?- Kconfig of drivers shouldn't show up in the menu. ?If you build
> this board, you want it to have all the drivers.
>
> Signed-off-by: Myles Watson <mylesgw at gmail.com>

I forgot a final refresh of the patches.  Sorry.

Thanks,
Myles
-------------- next part --------------
A non-text attachment was scrubbed...
Name: drivers.diff
Type: text/x-patch
Size: 9060 bytes
Desc: not available
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20100603/fa0619e0/attachment.diff>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: nokia.diff
Type: text/x-patch
Size: 11284 bytes
Desc: not available
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20100603/fa0619e0/attachment-0001.diff>

From xdrudis at tinet.cat  Fri Jun  4 00:36:35 2010
From: xdrudis at tinet.cat (xdrudis)
Date: Fri, 4 Jun 2010 00:36:35 +0200
Subject: [coreboot] ASUS M4A77TD-PRO. First step: buy spare flash chips...
Message-ID: <20100603223635.GA4587@ideafix.casa.ct>

Hello. 

I finally bought the hardware I told you and installed gnewsense 3 with a
custom linux-libre 2.6.34 :
mainboard Asus M4A77TD-PRO 
http://www.asus.com/product.aspx?P_ID=0AvsBb7WBZe2i9zK
CPU AMD Phenom X4 910e stepping c3
AMD 770 
AMD SB710  
RAM 2 x 4Gb dual channel non-ECC G.Skill DDR3-1333 PC3 10666 F3-10666CL9D-8GBRL
superio ITE  IT8712F (clearly marked on the chip and detected)
lan: RTL8112L
audio VIA VT1708S 

I've put a graphics card by MSI, Nvidia GeForce 8400GS passively cooled (no fan) on the PCIExpress 2.0 slot.

I'll attachs the lspci and superiotool r3125 outputs (versions from gNewSense)
and flashrom 0.9.2 downloaded and compiled from release tarball.

Btw. The readme in flashrom 0.9.2 says to use make DESTDIR=/usr install 
if you don't want it in /usr/local, but this will install it in /usr/usr/local/sbin. To have it in /usr/sbin you need to run makePREFIX=/usr install. 
It's slightly confusing for me, I've had to look at the Makefile. 

Now, the first thing I want to do is to buy spare flash chips. 
But I'm not sure what chips or where to buy them. 

It's a socket with an eight pin chip (DIP-8?) 
(4 pins per side), roughly 5mm x 9mm
I'd say it's by Macronix (and flashrom agrees). But I doubt about 
the specific model. The motherboard manual says "8Mb Flash ROM".

The letters on the chip are very small and there's some marking over them 
that keeps me from reading them all .
I'll copy here what I can read (i mark the most dubious letters with ?). 
(top left is a logo MX) 

-   - -   -
-- --  - -
= v =  = =    b09?714
=   = =   =

25L5???5PC-15G
   3C153600
    TAIWAN

Looking at catalogues from macronix I think 25L is the 
family (SPI serial flash) 5?? should be the size (I'm not
sure how many digits are there, not even 100% sure it's a 5)
?5 would be normal, write protected, duplex,etc.
PC might be the process ( xx micrometers), -15 would be
frequency of 66 Mhz and G something about lead free or environmental
regulations. 

but flashrom says its a Macronix MX25L8005 .
http://www.macronix.com/QuickPlace/hq/PageLibrary4825740B00298A3B.nsf/h_Index/6F878CF760C559BD482576E00022E6CC/?OpenDocument&EPN=MX25L8005

Now, the question is should I buy some  MX25L8005 ? (apparently its 
end of life is 2010-11-30, so it should be available, but where in 
small quantities ? )

According to 
http://www.macronix.com/QuickPlace/hq/PageLibrary4825740B00298A3B.nsf/h_Index/430AA5580EA1C72E482576BE0004AF37/$File/PCN-10-035-B.pdf
maybe I could try 
Mx25L8006EPI-12G

Where do you get your spare EEPROMs ?

Thank you. 
-------------- next part --------------
flashrom v0.9.2-r1001 on Linux 2.6.34-libre (x86_64), built with libpci 3.0.0, GCC 4.3.2
flashrom is free software, get the source code at http://www.flashrom.org

Initializing internal programmer
No coreboot table found.
DMI string system-manufacturer: "System manufacturer"
DMI string system-product-name: "System Product Name"
DMI string system-version: "System Version"
DMI string baseboard-manufacturer: "ASUSTeK Computer INC."
DMI string baseboard-product-name: "M4A77TD PRO"
DMI string baseboard-version: "Rev X.0x"
DMI string chassis-type: "Desktop"
Found ITE Super I/O, id 8712
Found chipset "AMD SB700/SB710/SB750", enabling flash write... SPI base address is at 0xfec10000
AltSpiCSEnable=0, SpiRomEnable=1, AbortEnable=0
PrefetchEnSPIFromIMC=0, PrefetchEnSPIFromHost=1, SpiOpEnInLpcMode=1
SpiArbEnable=0, SpiAccessMacRomEn=1, SpiHostAccessRomEn=1, ArbWaitCount=0, SpiBridgeDisable=0, DropOneClkOnRd=0
GPIO11 used for SPI_DO
GPIO12 used for SPI_DI
GPIO31 used for SPI_HOLD
GPIO32 used for SPI_CS
GPIO47 used for SPI_CLK
ROM strap override is not active
OK.
This chipset supports the following protocols: LPC,FWH,SPI.
SuperI/O ID 8712 is not on the controller list.
Calibrating delay loop... 871M loops per second, 10 myus = 10 us, 100 myus = 100 us, 1000 myus = 1001 us, 10000 myus = 10010 us, OK.
Probing for AMD Am29F010A/B, 128 KB: skipped.
Probing for AMD Am29F002(N)BB, 256 KB: skipped.
Probing for AMD Am29F002(N)BT, 256 KB: skipped.
Probing for AMD Am29F016D, 2048 KB: skipped.
Probing for AMD Am29F040B, 512 KB: skipped.
Probing for AMD Am29F080B, 1024 KB: skipped.
Probing for AMD Am29LV040B, 512 KB: skipped.
Probing for AMD Am29LV081B, 1024 KB: skipped.
Probing for ASD AE49F2008, 256 KB: skipped.
Probing for Atmel AT25DF021, 256 KB: probe_spi_rdid_generic: id1 0xc2, id2 0x2014
Probing for Atmel AT25DF041A, 512 KB: probe_spi_rdid_generic: id1 0xc2, id2 0x2014
Probing for Atmel AT25DF081, 1024 KB: probe_spi_rdid_generic: id1 0xc2, id2 0x2014
Probing for Atmel AT25DF161, 2048 KB: probe_spi_rdid_generic: id1 0xc2, id2 0x2014
Probing for Atmel AT25DF321, 4096 KB: probe_spi_rdid_generic: id1 0xc2, id2 0x2014
Probing for Atmel AT25DF321A, 4096 KB: probe_spi_rdid_generic: id1 0xc2, id2 0x2014
Probing for Atmel AT25DF641, 8192 KB: probe_spi_rdid_generic: id1 0xc2, id2 0x2014
Probing for Atmel AT25F512B, 64 KB: probe_spi_rdid_generic: id1 0xc2, id2 0x2014
Probing for Atmel AT25FS010, 128 KB: probe_spi_rdid_generic: id1 0xc2, id2 0x2014
Probing for Atmel AT25FS040, 512 KB: probe_spi_rdid_generic: id1 0xc2, id2 0x2014
Probing for Atmel AT26DF041, 512 KB: probe_spi_rdid_generic: id1 0xc2, id2 0x2014
Probing for Atmel AT26DF081A, 1024 KB: probe_spi_rdid_generic: id1 0xc2, id2 0x2014
Probing for Atmel AT26DF161, 2048 KB: probe_spi_rdid_generic: id1 0xc2, id2 0x2014
Probing for Atmel AT26DF161A, 2048 KB: probe_spi_rdid_generic: id1 0xc2, id2 0x2014
Probing for Atmel AT26F004, 512 KB: probe_spi_rdid_generic: id1 0xc2, id2 0x2014
Probing for Atmel AT29C512, 64 KB: skipped.
Probing for Atmel AT29C010A, 128 KB: skipped.
Probing for Atmel AT29C020, 256 KB: skipped.
Probing for Atmel AT29C040A, 512 KB: skipped.
Probing for Atmel AT45CS1282, 16896 KB: probe_spi_rdid_generic: id1 0xc2, id2 0x2014
Probing for Atmel AT45DB011D, 128 KB: probe_spi_rdid_generic: id1 0xc2, id2 0x2014
Probing for Atmel AT45DB021D, 256 KB: probe_spi_rdid_generic: id1 0xc2, id2 0x2014
Probing for Atmel AT45DB041D, 512 KB: probe_spi_rdid_generic: id1 0xc2, id2 0x2014
Probing for Atmel AT45DB081D, 1024 KB: probe_spi_rdid_generic: id1 0xc2, id2 0x2014
Probing for Atmel AT45DB161D, 2048 KB: probe_spi_rdid_generic: id1 0xc2, id2 0x2014
Probing for Atmel AT45DB321C, 4224 KB: probe_spi_rdid_generic: id1 0xc2, id2 0x2014
Probing for Atmel AT45DB321D, 4096 KB: probe_spi_rdid_generic: id1 0xc2, id2 0x2014
Probing for Atmel AT45DB642D, 8192 KB: probe_spi_rdid_generic: id1 0xc2, id2 0x2014
Probing for Atmel AT49BV512, 64 KB: skipped.
Probing for Atmel AT49F002(N), 256 KB: skipped.
Probing for Atmel AT49F002(N)T, 256 KB: skipped.
Probing for AMIC A25L40PT, 512 KB: probe_spi_rdid_generic: id1 0xc2, id2 0x2014
Probing for AMIC A25L40PU, 512 KB: probe_spi_rdid_generic: id1 0xc2, id2 0x2014
Probing for AMIC A29002B, 256 KB: skipped.
Probing for AMIC A29002T, 256 KB: skipped.
Probing for AMIC A29040B, 512 KB: skipped.
Probing for AMIC A49LF040A, 512 KB: probe_jedec_common: id1 0xff, id2 0xff, id1 parity violation, id1 is normal flash content, id2 is normal flash content
Probing for EMST F49B002UA, 256 KB: skipped.
Probing for Eon EN25B05, 64 KB: probe_spi_rdid_generic: id1 0xc2, id2 0x2014
Probing for Eon EN25B05T, 64 KB: probe_spi_rdid_generic: id1 0xc2, id2 0x2014
Probing for Eon EN25B10, 128 KB: probe_spi_rdid_generic: id1 0xc2, id2 0x2014
Probing for Eon EN25B10T, 128 KB: probe_spi_rdid_generic: id1 0xc2, id2 0x2014
Probing for Eon EN25B20, 256 KB: probe_spi_rdid_generic: id1 0xc2, id2 0x2014
Probing for Eon EN25B20T, 256 KB: probe_spi_rdid_generic: id1 0xc2, id2 0x2014
Probing for Eon EN25B40, 512 KB: probe_spi_rdid_generic: id1 0xc2, id2 0x2014
Probing for Eon EN25B40T, 512 KB: probe_spi_rdid_generic: id1 0xc2, id2 0x2014
Probing for Eon EN25B80, 1024 KB: probe_spi_rdid_generic: id1 0xc2, id2 0x2014
Probing for Eon EN25B80T, 1024 KB: probe_spi_rdid_generic: id1 0xc2, id2 0x2014
Probing for Eon EN25B16, 2048 KB: probe_spi_rdid_generic: id1 0xc2, id2 0x2014
Probing for Eon EN25B16T, 2048 KB: probe_spi_rdid_generic: id1 0xc2, id2 0x2014
Probing for Eon EN25B32, 4096 KB: probe_spi_rdid_generic: id1 0xc2, id2 0x2014
Probing for Eon EN25B32T, 4096 KB: probe_spi_rdid_generic: id1 0xc2, id2 0x2014
Probing for Eon EN25B64, 8192 KB: probe_spi_rdid_generic: id1 0xc2, id2 0x2014
Probing for Eon EN25B64T, 8192 KB: probe_spi_rdid_generic: id1 0xc2, id2 0x2014
Probing for Eon EN25D16, 2048 KB: probe_spi_rdid_generic: id1 0xc2, id2 0x2014
Probing for Eon EN25F05, 64 KB: probe_spi_rdid_generic: id1 0xc2, id2 0x2014
Probing for Eon EN25F10, 128 KB: probe_spi_rdid_generic: id1 0xc2, id2 0x2014
Probing for Eon EN25F20, 256 KB: probe_spi_rdid_generic: id1 0xc2, id2 0x2014
Probing for Eon EN25F40, 512 KB: probe_spi_rdid_generic: id1 0xc2, id2 0x2014
Probing for Eon EN25F80, 1024 KB: probe_spi_rdid_generic: id1 0xc2, id2 0x2014
Probing for Eon EN25F16, 2048 KB: probe_spi_rdid_generic: id1 0xc2, id2 0x2014
Probing for Eon EN25F32, 4096 KB: probe_spi_rdid_generic: id1 0xc2, id2 0x2014
Probing for Eon EN29F010, 128 KB: skipped.
Probing for EON EN29F002(A)(N)B, 256 KB: skipped.
Probing for EON EN29F002(A)(N)T, 256 KB: skipped.
Probing for Fujitsu MBM29F004BC, 512 KB: skipped.
Probing for Fujitsu MBM29F004TC, 512 KB: skipped.
Probing for Fujitsu MBM29F400BC, 512 KB: skipped.
Probing for Fujitsu MBM29F400TC, 512 KB: skipped.
Probing for Intel 28F001BX-B, 128 KB: skipped.
Probing for Intel 28F001BX-T, 128 KB: skipped.
Probing for Intel 28F004S5, 512 KB: skipped.
Probing for Intel 28F004BV/BE-B, 512 KB: skipped.
Probing for Intel 28F004BV/BE-T, 512 KB: skipped.
Probing for Intel 28F400BV/CV/CE-B, 512 KB: skipped.
Probing for Intel 28F400BV/CV/CE-T, 512 KB: skipped.
Probing for Intel 82802AB, 512 KB: probe_82802ab: id1 0xff, id2 0xff, id1 parity violation, id1 is normal flash content, id2 is normal flash content
Probing for Intel 82802AC, 1024 KB: probe_82802ab: id1 0xff, id2 0xff, id1 parity violation, id1 is normal flash content, id2 is normal flash content
Probing for Macronix MX25L512, 64 KB: probe_spi_rdid_generic: id1 0xc2, id2 0x2014
Probing for Macronix MX25L1005, 128 KB: probe_spi_rdid_generic: id1 0xc2, id2 0x2014
Probing for Macronix MX25L2005, 256 KB: probe_spi_rdid_generic: id1 0xc2, id2 0x2014
Probing for Macronix MX25L4005, 512 KB: probe_spi_rdid_generic: id1 0xc2, id2 0x2014
Probing for Macronix MX25L8005, 1024 KB: probe_spi_rdid_generic: id1 0xc2, id2 0x2014
Chip status register is 00
Chip status register: Status Register Write Disable (SRWD) is not set
Chip status register: Bit 6 is not set
Chip status register: Bit 5 / Block Protect 3 (BP3) is not set
Chip status register: Bit 4 / Block Protect 2 (BP2) is not set
Chip status register: Bit 3 / Block Protect 1 (BP1) is not set
Chip status register: Bit 2 / Block Protect 0 (BP0) is not set
Chip status register: Write Enable Latch (WEL) is not set
Chip status register: Write In Progress (WIP/BUSY) is not set
Found chip "Macronix MX25L8005" (1024 KB, SPI) at physical address 0xfff00000.
Probing for Macronix MX25L1605, 2048 KB: probe_spi_rdid_generic: id1 0xc2, id2 0x2014
Probing for Macronix MX25L1635D, 2048 KB: probe_spi_rdid_generic: id1 0xc2, id2 0x2014
Probing for Macronix MX25L3205, 4096 KB: probe_spi_rdid_generic: id1 0xc2, id2 0x2014
Probing for Macronix MX25L3235D, 4096 KB: probe_spi_rdid_generic: id1 0xc2, id2 0x2014
Probing for Macronix MX25L6405, 8192 KB: probe_spi_rdid_generic: id1 0xc2, id2 0x2014
Probing for Macronix MX25L12805, 16384 KB: probe_spi_rdid_generic: id1 0xc2, id2 0x2014
Probing for Macronix MX29F001B, 128 KB: skipped.
Probing for Macronix MX29F001T, 128 KB: skipped.
Probing for Macronix MX29F002B, 256 KB: skipped.
Probing for Macronix MX29F002T, 256 KB: skipped.
Probing for Macronix MX29LV040, 512 KB: skipped.
Probing for Numonyx M25PE10, 128 KB: probe_spi_rdid_generic: id1 0xc2, id2 0x2014
Probing for Numonyx M25PE20, 256 KB: probe_spi_rdid_generic: id1 0xc2, id2 0x2014
Probing for Numonyx M25PE40, 512 KB: probe_spi_rdid_generic: id1 0xc2, id2 0x2014
Probing for Numonyx M25PE80, 1024 KB: probe_spi_rdid_generic: id1 0xc2, id2 0x2014
Probing for Numonyx M25PE16, 2048 KB: probe_spi_rdid_generic: id1 0xc2, id2 0x2014
Probing for PMC Pm25LV010, 128 KB: probe_spi_rdid_generic: id1 0xc2, id2 0x2014
Probing for PMC Pm25LV016B, 2048 KB: probe_spi_rdid_generic: id1 0xc2, id2 0x2014
Probing for PMC Pm25LV020, 256 KB: probe_spi_rdid_generic: id1 0xc2, id2 0x2014
Probing for PMC Pm25LV040, 512 KB: probe_spi_rdid_generic: id1 0xc2, id2 0x2014
Probing for PMC Pm25LV080B, 1024 KB: probe_spi_rdid_generic: id1 0xc2, id2 0x2014
Probing for PMC Pm25LV512, 64 KB: probe_spi_rdid_generic: id1 0xc2, id2 0x2014
Probing for PMC Pm29F002T, 256 KB: skipped.
Probing for PMC Pm29F002B, 256 KB: skipped.
Probing for PMC Pm39LV010, 128 KB: skipped.
Probing for PMC Pm39LV020, 256 KB: skipped.
Probing for PMC Pm39LV040, 512 KB: skipped.
Probing for PMC Pm49FL002, 256 KB: probe_jedec_common: id1 0x04, id2 0xd1, id1 is normal flash content, id2 is normal flash content
Probing for PMC Pm49FL004, 512 KB: probe_jedec_common: id1 0xff, id2 0xff, id1 parity violation, id1 is normal flash content, id2 is normal flash content
Probing for Sanyo LF25FW203A, 2048 KB: probe_spi_rdid_generic: id1 0xc2, id2 0x2014
Probing for Sharp LHF00L04, 1024 KB: probe_82802ab: id1 0xff, id2 0xff, id1 parity violation, id1 is normal flash content, id2 is normal flash content
Probing for Spansion S25FL008A, 1024 KB: probe_spi_rdid_generic: id1 0xc2, id2 0x2014
Probing for Spansion S25FL016A, 2048 KB: probe_spi_rdid_generic: id1 0xc2, id2 0x2014
Probing for SST SST25VF016B, 2048 KB: probe_spi_rdid_generic: id1 0xc2, id2 0x2014
Probing for SST SST25VF032B, 4096 KB: probe_spi_rdid_generic: id1 0xc2, id2 0x2014
Probing for SST SST25VF040.REMS, 512 KB: probe_spi_rems: id1 0xc2, id2 0x13
Probing for SST SST25VF040B, 512 KB: probe_spi_rdid_generic: id1 0xc2, id2 0x2014
Probing for SST SST25VF040B.REMS, 512 KB: probe_spi_rems: id1 0xc2, id2 0x13
Probing for SST SST25VF080B, 1024 KB: probe_spi_rdid_generic: id1 0xc2, id2 0x2014
Probing for SST SST28SF040A, 512 KB: skipped.
Probing for SST SST29EE010, 128 KB: skipped.
Probing for SST SST29LE010, 128 KB: skipped.
Probing for SST SST29EE020A, 256 KB: skipped.
Probing for SST SST29LE020, 256 KB: skipped.
Probing for SST SST39SF512, 64 KB: skipped.
Probing for SST SST39SF010A, 128 KB: skipped.
Probing for SST SST39SF020A, 256 KB: skipped.
Probing for SST SST39SF040, 512 KB: skipped.
Probing for SST SST39VF512, 64 KB: skipped.
Probing for SST SST39VF010, 128 KB: skipped.
Probing for SST SST39VF020, 256 KB: skipped.
Probing for SST SST39VF040, 512 KB: skipped.
Probing for SST SST39VF080, 1024 KB: skipped.
Probing for SST SST49LF002A/B, 256 KB: probe_jedec_common: id1 0x04, id2 0xd1, id1 is normal flash content, id2 is normal flash content
Probing for SST SST49LF003A/B, 384 KB: probe_jedec_common: id1 0x24, id2 0x41, id1 parity violation, id1 is normal flash content, id2 is normal flash content
Probing for SST SST49LF004A/B, 512 KB: probe_jedec_common: id1 0xff, id2 0xff, id1 parity violation, id1 is normal flash content, id2 is normal flash content
Probing for SST SST49LF004C, 512 KB: probe_82802ab: id1 0xff, id2 0xff, id1 parity violation, id1 is normal flash content, id2 is normal flash content
Probing for SST SST49LF008A, 1024 KB: probe_jedec_common: id1 0xff, id2 0xff, id1 parity violation, id1 is normal flash content, id2 is normal flash content
Probing for SST SST49LF008C, 1024 KB: probe_82802ab: id1 0xff, id2 0xff, id1 parity violation, id1 is normal flash content, id2 is normal flash content
Probing for SST SST49LF016C, 2048 KB: probe_82802ab: id1 0xff, id2 0xff, id1 parity violation, id1 is normal flash content, id2 is normal flash content
Probing for SST SST49LF020, 256 KB: probe_jedec_common: id1 0x04, id2 0xd1, id1 is normal flash content, id2 is normal flash content
Probing for SST SST49LF020A, 256 KB: probe_jedec_common: id1 0x04, id2 0xd1, id1 is normal flash content, id2 is normal flash content
Probing for SST SST49LF040, 512 KB: probe_jedec_common: id1 0xff, id2 0xff, id1 parity violation, id1 is normal flash content, id2 is normal flash content
Probing for SST SST49LF040B, 512 KB: probe_jedec_common: id1 0xff, id2 0xff, id1 parity violation, id1 is normal flash content, id2 is normal flash content
Probing for SST SST49LF080A, 1024 KB: Chip lacks correct probe timing information, using default 10mS/40uS. probe_jedec_common: id1 0xff, id2 0xff, id1 parity violation, id1 is normal flash content, id2 is normal flash content
Probing for SST SST49LF160C, 2048 KB: probe_82802ab: id1 0xff, id2 0xff, id1 parity violation, id1 is normal flash content, id2 is normal flash content
Probing for ST M25P05-A, 64 KB: probe_spi_rdid_generic: id1 0xc2, id2 0x2014
Probing for ST M25P05.RES, 64 KB: Ignoring RES in favour of RDID.
Probing for ST M25P10-A, 128 KB: probe_spi_rdid_generic: id1 0xc2, id2 0x2014
Probing for ST M25P10.RES, 128 KB: Ignoring RES in favour of RDID.
Probing for ST M25P20, 256 KB: probe_spi_rdid_generic: id1 0xc2, id2 0x2014
Probing for ST M25P40, 512 KB: probe_spi_rdid_generic: id1 0xc2, id2 0x2014
Probing for ST M25P40-old, 512 KB: Ignoring RES in favour of RDID.
Probing for ST M25P80, 1024 KB: probe_spi_rdid_generic: id1 0xc2, id2 0x2014
Probing for ST M25P16, 2048 KB: probe_spi_rdid_generic: id1 0xc2, id2 0x2014
Probing for ST M25P32, 4096 KB: probe_spi_rdid_generic: id1 0xc2, id2 0x2014
Probing for ST M25P64, 8192 KB: probe_spi_rdid_generic: id1 0xc2, id2 0x2014
Probing for ST M25P128, 16384 KB: probe_spi_rdid_generic: id1 0xc2, id2 0x2014
Probing for ST M29F002B, 256 KB: skipped.
Probing for ST M29F002T/NT, 256 KB: skipped.
Probing for ST M29F040B, 512 KB: skipped.
Probing for ST M29F400BT, 512 KB: skipped.
Probing for ST M29W010B, 128 KB: skipped.
Probing for ST M29W040B, 512 KB: skipped.
Probing for ST M29W512B, 64 KB: skipped.
Probing for ST M50FLW040A, 512 KB: probe_82802ab: id1 0xff, id2 0xff, id1 parity violation, id1 is normal flash content, id2 is normal flash content
Probing for ST M50FLW040B, 512 KB: probe_82802ab: id1 0xff, id2 0xff, id1 parity violation, id1 is normal flash content, id2 is normal flash content
Probing for ST M50FLW080A, 1024 KB: probe_82802ab: id1 0xff, id2 0xff, id1 parity violation, id1 is normal flash content, id2 is normal flash content
Probing for ST M50FLW080B, 1024 KB: probe_82802ab: id1 0xff, id2 0xff, id1 parity violation, id1 is normal flash content, id2 is normal flash content
Probing for ST M50FW002, 256 KB: probe_82802ab: id1 0x04, id2 0xd1, id1 is normal flash content, id2 is normal flash content
Probing for ST M50FW016, 2048 KB: probe_82802ab: id1 0xff, id2 0xff, id1 parity violation, id1 is normal flash content, id2 is normal flash content
Probing for ST M50FW040, 512 KB: probe_82802ab: id1 0xff, id2 0xff, id1 parity violation, id1 is normal flash content, id2 is normal flash content
Probing for ST M50FW080, 1024 KB: probe_82802ab: id1 0xff, id2 0xff, id1 parity violation, id1 is normal flash content, id2 is normal flash content
Probing for ST M50LPW116, 2048 KB: probe_82802ab: id1 0xff, id2 0xff, id1 parity violation, id1 is normal flash content, id2 is normal flash content
Probing for SyncMOS S29C31004T, 512 KB: skipped.
Probing for SyncMOS S29C51001T, 128 KB: skipped.
Probing for SyncMOS S29C51002T, 256 KB: skipped.
Probing for SyncMOS S29C51004T, 512 KB: skipped.
Probing for TI TMS29F002RB, 256 KB: skipped.
Probing for TI TMS29F002RT, 256 KB: skipped.
Probing for Winbond W25Q80, 1024 KB: probe_spi_rdid_generic: id1 0xc2, id2 0x2014
Probing for Winbond W25Q16, 2048 KB: probe_spi_rdid_generic: id1 0xc2, id2 0x2014
Probing for Winbond W25Q32, 4096 KB: probe_spi_rdid_generic: id1 0xc2, id2 0x2014
Probing for Winbond W25x10, 128 KB: probe_spi_rdid_generic: id1 0xc2, id2 0x2014
Probing for Winbond W25x20, 256 KB: probe_spi_rdid_generic: id1 0xc2, id2 0x2014
Probing for Winbond W25x40, 512 KB: probe_spi_rdid_generic: id1 0xc2, id2 0x2014
Probing for Winbond W25x80, 1024 KB: probe_spi_rdid_generic: id1 0xc2, id2 0x2014
Probing for Winbond W25x16, 2048 KB: probe_spi_rdid_generic: id1 0xc2, id2 0x2014
Probing for Winbond W25x32, 4096 KB: probe_spi_rdid_generic: id1 0xc2, id2 0x2014
Probing for Winbond W25x64, 8192 KB: probe_spi_rdid_generic: id1 0xc2, id2 0x2014
Probing for Winbond W29C011, 128 KB: skipped.
Probing for Winbond W29C020C, 256 KB: skipped.
Probing for Winbond W29C040P, 512 KB: skipped.
Probing for Winbond W29EE011, 128 KB: skipped.
Probing for Winbond W39V040A, 512 KB: probe_jedec_common: id1 0xff, id2 0xff, id1 parity violation, id1 is normal flash content, id2 is normal flash content
Probing for Winbond W39V040B, 512 KB: probe_jedec_common: id1 0xff, id2 0xff, id1 parity violation, id1 is normal flash content, id2 is normal flash content
Probing for Winbond W39V040C, 512 KB: Chip lacks correct probe timing information, using default 10mS/40uS. probe_jedec_common: id1 0xff, id2 0xff, id1 parity violation, id1 is normal flash content, id2 is normal flash content
Probing for Winbond W39V040FA, 512 KB: probe_jedec_common: id1 0xff, id2 0xff, id1 parity violation, id1 is normal flash content, id2 is normal flash content
Probing for Winbond W39V080A, 1024 KB: probe_jedec_common: id1 0xff, id2 0xff, id1 parity violation, id1 is normal flash content, id2 is normal flash content
Probing for Winbond W49F002U, 256 KB: skipped.
Probing for Winbond W49V002A, 256 KB: probe_jedec_common: id1 0x04, id2 0xd1, id1 is normal flash content, id2 is normal flash content
Probing for Winbond W49V002FA, 256 KB: probe_jedec_common: id1 0x04, id2 0xd1, id1 is normal flash content, id2 is normal flash content
Probing for Winbond W39V080FA, 1024 KB: Chip lacks correct probe timing information, using default 10mS/40uS. probe_jedec_common: id1 0xff, id2 0xff, id1 parity violation, id1 is normal flash content, id2 is normal flash content
Probing for Winbond W39V080FA (dual mode), 512 KB: Chip lacks correct probe timing information, using default 10mS/40uS. probe_jedec_common: id1 0xff, id2 0xff, id1 parity violation, id1 is normal flash content, id2 is normal flash content
Probing for Atmel unknown Atmel SPI chip, 0 KB: probe_spi_rdid_generic: id1 0xc2, id2 0x2014
Probing for EON unknown EON SPI chip, 0 KB: probe_spi_rdid_generic: id1 0xc2, id2 0x2014
Probing for Macronix unknown Macronix SPI chip, 0 KB: probe_spi_rdid_generic: id1 0xc2, id2 0x2014
Probing for PMC unknown PMC SPI chip, 0 KB: probe_spi_rdid_generic: id1 0xc2, id2 0x2014
Probing for SST unknown SST SPI chip, 0 KB: probe_spi_rdid_generic: id1 0xc2, id2 0x2014
Probing for ST unknown ST SPI chip, 0 KB: probe_spi_rdid_generic: id1 0xc2, id2 0x2014
Probing for Sanyo unknown Sanyo SPI chip, 0 KB: probe_spi_rdid_generic: id1 0xc2, id2 0x2014
Probing for Generic unknown SPI chip (RDID), 0 KB: probe_spi_rdid_generic: id1 0xc2, id2 0x2014
Probing for Generic unknown SPI chip (REMS), 0 KB: probe_spi_rems: id1 0xc2, id2 0x13
===
This flash part has status UNTESTED for operations: ERASE
The test status of this chip may have been updated in the latest development
version of flashrom. If you are running the latest development version,
please email a report to flashrom at flashrom.org if any of the above operations
work correctly for you with this flash part. Please include the flashrom
output with the additional -V option for all operations you tested (-V, -Vr,
-Vw, -VE), and mention which mainboard or programmer you tested.
Thanks for your help!
===
No operations were specified.
-------------- next part --------------
-[0000:00]-+-00.0  ATI Technologies Inc RX780/RX790 Chipset Host Bridge [1002:5957]
           +-02.0-[0000:01]----00.0  nVidia Corporation GeForce 8400 GS [10de:06e4]
           +-0a.0-[0000:02]----00.0  Realtek Semiconductor Co., Ltd. RTL8111/8168B PCI Express Gigabit Ethernet controller [10ec:8168]
           +-11.0  ATI Technologies Inc SB700/SB800 SATA Controller [AHCI mode] [1002:4391]
           +-12.0  ATI Technologies Inc SB700/SB800 USB OHCI0 Controller [1002:4397]
           +-12.1  ATI Technologies Inc SB700 USB OHCI1 Controller [1002:4398]
           +-12.2  ATI Technologies Inc SB700/SB800 USB EHCI Controller [1002:4396]
           +-13.0  ATI Technologies Inc SB700/SB800 USB OHCI0 Controller [1002:4397]
           +-13.1  ATI Technologies Inc SB700 USB OHCI1 Controller [1002:4398]
           +-13.2  ATI Technologies Inc SB700/SB800 USB EHCI Controller [1002:4396]
           +-14.0  ATI Technologies Inc SBx00 SMBus Controller [1002:4385]
           +-14.1  ATI Technologies Inc SB700/SB800 IDE Controller [1002:439c]
           +-14.2  ATI Technologies Inc SBx00 Azalia (Intel HDA) [1002:4383]
           +-14.3  ATI Technologies Inc SB700/SB800 LPC host controller [1002:439d]
           +-14.4-[0000:03]--
           +-14.5  ATI Technologies Inc SB700/SB800 USB OHCI2 Controller [1002:4399]
           +-18.0  Advanced Micro Devices [AMD] Family 10h [Opteron, Athlon64, Sempron] HyperTransport Configuration [1022:1200]
           +-18.1  Advanced Micro Devices [AMD] Family 10h [Opteron, Athlon64, Sempron] Address Map [1022:1201]
           +-18.2  Advanced Micro Devices [AMD] Family 10h [Opteron, Athlon64, Sempron] DRAM Controller [1022:1202]
           +-18.3  Advanced Micro Devices [AMD] Family 10h [Opteron, Athlon64, Sempron] Miscellaneous Control [1022:1203]
           \-18.4  Advanced Micro Devices [AMD] Family 10h [Opteron, Athlon64, Sempron] Link Control [1022:1204]
-------------- next part --------------
superiotool r3125
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=0xffff, id=0xffff
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...
Found ITE IT8712F (id=0x8712, rev=0x8) at 0x2e
Register dump:
idx 07 20 21 22 23 24 2b
val 0a 87 12 08 00 00 00
def NA 87 12 08 00 00 00
LDN 0x00 (Floppy)
idx 30 60 61 70 74 f0 f1
val 00 03 f0 06 02 00 00
def 00 03 f0 06 02 00 00
LDN 0x01 (COM1)
idx 30 60 61 70 f0 f1 f2 f3
val 01 03 f8 04 00 50 00 7f
def 00 03 f8 04 00 50 00 7f
LDN 0x02 (COM2)
idx 30 60 61 70 f0 f1 f2 f3
val 00 02 f8 03 00 50 00 7f
def 00 02 f8 03 00 50 00 7f
LDN 0x03 (Parallel port)
idx 30 60 61 62 63 70 74 f0
val 01 03 78 00 00 07 04 00
def 00 03 78 07 78 07 03 03
LDN 0x04 (Environment controller)
idx 30 60 61 62 63 70 f0 f1  f2 f3 f4 f5 f6
val 01 02 90 02 30 00 00 00  00 00 00 00 7f
def 00 02 90 02 30 09 00 00  00 00 00 NA NA
LDN 0x05 (Keyboard)
idx 30 60 61 62 63 70 71 f0
val 01 00 60 00 64 01 02 04
def 01 00 60 00 64 01 02 08
LDN 0x06 (Mouse)
idx 30 70 71 f0
val 01 0c 02 00
def 00 0c 02 00
LDN 0x07 (GPIO)
idx 25 26 27 28 29 2a 2c 60  61 62 63 64 65 70 71 72  73 74 b0 b1 b2 b3 b4 b5  b8 b9 ba bb bc bd c0 c1  c2 c3 c4 c8 c9 ca cb cc  e0 e1 e2 e3 e4 f0 f1 f2  f3 f4 f5 f6 f7 f8 f9 fa  fb fc fd
val 00 3c 20 00 00 00 1f 00  00 03 00 00 00 00 01 00  38 00 00 00 00 00 00 00  00 00 20 00 00 00 00 3c  20 00 00 00 20 00 00 00  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  00 00 00
def 01 00 00 40 00 00 00 00  00 00 00 00 00 00 00 00  c0 00 00 00 00 00 00 00  00 00 00 00 00 00 01 00  00 40 00 01 00 00 40 00  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  00 NA 00
LDN 0x08 (MIDI port)
idx 30 60 61 70 f0
val 00 03 00 0a 00
def 00 03 00 0a 00
LDN 0x09 (Game port)
idx 30 60 61
val 00 02 01
def 00 02 01
LDN 0x0a (Consumer IR)
idx 30 60 61 70 f0
val 00 03 10 0b 06
def 00 03 10 0b 00
Probing for ITE Super I/O (init=0x87,0x87) at 0x2e...
  Failed. Returned data: id=0xffff, rev=0xf
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...
  Failed. Returned data: port=0xff, port+1=0xff
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=0xff, rev=0xff
Probing for SMSC Super I/O (idregs=0x0d/0x0e) at 0x2e...
  Failed. Returned data: id=0xff, rev=0xff
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=0xff/0x0f, rev=0xff
Probing for Winbond Super I/O (init=0x89) at 0x2e...
  Failed. Returned data: id/oldid=0xff/0x0f, rev=0xff
Probing for Winbond Super I/O (init=0x86,0x86) at 0x2e...
  Failed. Returned data: id/oldid=0xff/0x0f, rev=0xff
Probing for Winbond Super I/O (init=0x87,0x87) at 0x2e...
  Failed. Returned data: id/oldid=0xff/0x0f, rev=0xff
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 stepan at coresystems.de  Fri Jun  4 00:46:25 2010
From: stepan at coresystems.de (Stefan Reinauer)
Date: Fri, 04 Jun 2010 00:46:25 +0200
Subject: [coreboot] [PATCH] libpayload: fix cmos checksum.
Message-ID: <4C0830C1.8060902@coresystems.de>

See patch.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20100604/c1bba947/attachment.html>
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: libpayload_cmos_checksum.diff
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20100604/c1bba947/attachment.ksh>

From Frank.Vibrans at amd.com  Fri Jun  4 01:41:33 2010
From: Frank.Vibrans at amd.com (Vibrans, Frank)
Date: Thu, 3 Jun 2010 18:41:33 -0500
Subject: [coreboot] A patch to replace the headers of three files - no
 functional changes.
Message-ID: <276EC11373289744A112A8FE6675506701183E8DC0@SAUSEXMBP01.amd.com>

This patch replaces the headers of the following files:

    src/cpu/amd/model_fxx/model_fxx_update_microcode.c
    src/northbridge/amd/amdk8/amdk8_acpi.c
    src/southbridge/amd/amd8132/amd8132_bridge.c

Signed-off by: Frank Vibrans frank.vibrans at amd.com<mailto:frank.vibrans at amd.com>

---
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20100603/2cf9056e/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: license.patch
Type: application/octet-stream
Size: 11141 bytes
Desc: license.patch
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20100603/2cf9056e/attachment.obj>

From rminnich at gmail.com  Fri Jun  4 06:18:57 2010
From: rminnich at gmail.com (ron minnich)
Date: Thu, 3 Jun 2010 21:18:57 -0700
Subject: [coreboot] A patch to replace the headers of three files - no
	functional changes.
In-Reply-To: <276EC11373289744A112A8FE6675506701183E8DC0@SAUSEXMBP01.amd.com>
References: <276EC11373289744A112A8FE6675506701183E8DC0@SAUSEXMBP01.amd.com>
Message-ID: <AANLkTim9jsz_F62Y5GilfrjSfBc3Icp-klpbQ6y52Lw6@mail.gmail.com>

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

Thanks, once again, to AMD.

ron



From mbertens at xs4all.nl  Fri Jun  4 06:25:26 2010
From: mbertens at xs4all.nl (mbertens)
Date: Fri, 04 Jun 2010 06:25:26 +0200
Subject: [coreboot] Update on NOKIA-IP530
In-Reply-To: <AANLkTin9LTl7QGCMz5vypyx0Y7_9vmDA0UXQPZq4-7ug@mail.gmail.com>
References: <1275587298.3803.21.camel@andrala.reboot>
	<AANLkTin9LTl7QGCMz5vypyx0Y7_9vmDA0UXQPZq4-7ug@mail.gmail.com>
Message-ID: <1275625526.3803.25.camel@andrala.reboot>

On Thu, 2010-06-03 at 13:29 -0600, Myles Watson wrote:
> > - Unfortunate we still need ti dirty hack in arch\i386\boot
> > \pirq_routing.c this should be fixed within the code of coreboot. But my
> > unfamiliarly with that code its not a good idea that i make that fix.
> > But i'm of cource willing to patch it on the Nokia code and test it. I
> > hope that you will consider applying the patch for the mean while, its
> > guarded by the #if CONFIG_BOARD_NOKIA_IP530 so nobody shall have any
> > problems with it.
> >From your earlier mail:
> a last update the dirty hack in the pirq_routing is not needed, therefor
> i made a new diff for it.
> 
> Was it just a mistake that you didn't need it?
No, the ip530 needs it. 
> 
> Thanks,
> Myles




From xdrudis at tinet.cat  Fri Jun  4 08:02:20 2010
From: xdrudis at tinet.cat (xdrudis)
Date: Fri, 4 Jun 2010 08:02:20 +0200
Subject: [coreboot] ASUS M4A77TD-PRO. First step: buy spare flash
	chips...
In-Reply-To: <20100603223635.GA4587@ideafix.casa.ct>
References: <20100603223635.GA4587@ideafix.casa.ct>
Message-ID: <20100604060220.GA4208@ideafix.casa.ct>

I forgot to add that the mainboard did not boot when I built the PC. 
It would only boot once when I cleared CMOS, and then never more until
I cleared it again.
I could fix it by downloading a BIOS image of a newer version 
from asus and flashing it (with a tool called EZ flash, I think, 
which was in the factory BIOS). 
Now it boots fine. 
I tried flashrom -r file.rom and it produced a file of the same size
as the downloaded BIOS image ( 1 megabyte) but diff says the binary 
files differ. I'm not sure whether this means flashrom is not reading
the BIOS 100% right or it's just normal because some parts of the file
don't get copied to EEPROM or something...



> Where do you get your spare EEPROMs ?
> 

I've tried a couple of local electronics parts shops in Barcelona, 
and they hardly knew Macronix. They couldn't find any MX25L parts 
listed. I'll try again, I guess...But maybe I should go somewhere else ?



From svn at coreboot.org  Fri Jun  4 09:49:53 2010
From: svn at coreboot.org (repository service)
Date: Fri, 04 Jun 2010 09:49:53 +0200
Subject: [coreboot] [commit] r5607 - in trunk/src: cpu/amd/model_fxx
	northbridge/amd/amdk8 southbridge/amd/amd8132
Message-ID: <E1OKRf7-0002FC-Gl@ra.coresystems.de>

Author: stepan
Date: Fri Jun  4 09:49:53 2010
New Revision: 5607
URL: https://tracker.coreboot.org/trac/coreboot/changeset/5607

Log:
This patch replaces the headers of the following files:

src/cpu/amd/model_fxx/model_fxx_update_microcode.c
src/northbridge/amd/amdk8/amdk8_acpi.c
src/southbridge/amd/amd8132/amd8132_bridge.c

Signed-off-by: Frank Vibrans <frank.vibrans at amd.com>
Acked-by: Ronald G. Minnich <rminnich at gmail.com>
Acked-by: Stefan Reinauer <stepan at coresystems.de>

http://www.coreboot.org/pipermail/coreboot/2010-June/058668.html

Modified:
   trunk/src/cpu/amd/model_fxx/model_fxx_update_microcode.c
   trunk/src/northbridge/amd/amdk8/amdk8_acpi.c
   trunk/src/southbridge/amd/amd8132/amd8132_bridge.c

Modified: trunk/src/cpu/amd/model_fxx/model_fxx_update_microcode.c
==============================================================================
--- trunk/src/cpu/amd/model_fxx/model_fxx_update_microcode.c	Thu Jun  3 09:51:09 2010	(r5606)
+++ trunk/src/cpu/amd/model_fxx/model_fxx_update_microcode.c	Fri Jun  4 09:49:53 2010	(r5607)
@@ -1,46 +1,27 @@
-/* Copyright 2005 AMD
- * 2005.08 yhlu add microcode support
+/*
+ * This file is part of the coreboot project.
+ *
+ * Copyright (C) 2005 Advanced Micro Devices, Inc.
+ * Copyright (C) 2010 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 as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * 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
  */
-/*============================================================================
-Copyright 2005 ADVANCED MICRO DEVICES, INC. All Rights Reserved.
-This software and any related documentation (the "Materials") are the
-confidential proprietary information of AMD. Unless otherwise provided in a
-software agreement specifically licensing the Materials, the Materials are
-provided in confidence and may not be distributed, modified, or reproduced in
-whole or in part by any means.
-LIMITATION OF LIABILITY: THE MATERIALS ARE PROVIDED "AS IS" WITHOUT ANY
-EXPRESS OR IMPLIED WARRANTY OF ANY KIND, INCLUDING BUT NOT LIMITED TO
-WARRANTIES OF MERCHANTABILITY, NONINFRINGEMENT, TITLE, FITNESS FOR ANY
-PARTICULAR PURPOSE, OR WARRANTIES ARISING FROM CONDUCT, COURSE OF DEALING, OR
-USAGE OF TRADE. IN NO EVENT SHALL AMD OR ITS LICENSORS BE LIABLE FOR ANY
-DAMAGES WHATSOEVER (INCLUDING, WITHOUT LIMITATION, DAMAGES FOR LOSS OF PROFITS,
-BUSINESS INTERRUPTION, OR LOSS OF INFORMATION) ARISING OUT OF THE USE OF OR
-INABILITY TO USE THE MATERIALS, EVEN IF AMD HAS BEEN ADVISED OF THE
-POSSIBILITY OF SUCH DAMAGES. BECAUSE SOME JURISDICTIONS PROHIBIT THE EXCLUSION
-OR LIMITATION OF LIABILITY FOR CONSEQUENTIAL OR INCIDENTAL DAMAGES, THE ABOVE
-LIMITATION MAY NOT APPLY TO YOU.
-AMD does not assume any responsibility for any errors which may appear in the
-Materials nor any responsibility to support or update the Materials. AMD
-retains the right to modify the Materials at any time, without notice, and is
-not obligated to provide such modified Materials to you.
-NO SUPPORT OBLIGATION: AMD is not obligated to furnish, support, or make any
-further information, software, technical information, know-how, or show-how
-available to you.
-U.S. GOVERNMENT RESTRICTED RIGHTS: The Materials are provided with "RESTRICTED
-RIGHTS." Use, duplication, or disclosure by the Government is subject to the
-restrictions as set forth in FAR 52.227-14 and DFAR 252.227-7013, et seq., or
-its successor. Use of the Materials by the Government constitutes
-acknowledgement of AMD's proprietary rights in them.
-============================================================================*/
-//@DOC
-// in model_fxx_update_microcode.c
+
 /*
-$1.0$
-*/
-// Description: microcode patch support for k8
-// by yhlu
-//
-//============================================================================
+ * Description: Microcode patch support for k8 by yhlu
+ */
 
 
 #include <console/console.h>

Modified: trunk/src/northbridge/amd/amdk8/amdk8_acpi.c
==============================================================================
--- trunk/src/northbridge/amd/amdk8/amdk8_acpi.c	Thu Jun  3 09:51:09 2010	(r5606)
+++ trunk/src/northbridge/amd/amdk8/amdk8_acpi.c	Fri Jun  4 09:49:53 2010	(r5607)
@@ -1,42 +1,28 @@
-/*============================================================================
-Copyright 2005 ADVANCED MICRO DEVICES, INC. All Rights Reserved.
-This software and any related documentation (the "Materials") are the
-confidential proprietary information of AMD. Unless otherwise provided in a
-software agreement specifically licensing the Materials, the Materials are
-provided in confidence and may not be distributed, modified, or reproduced in
-whole or in part by any means.
-LIMITATION OF LIABILITY: THE MATERIALS ARE PROVIDED "AS IS" WITHOUT ANY
-EXPRESS OR IMPLIED WARRANTY OF ANY KIND, INCLUDING BUT NOT LIMITED TO
-WARRANTIES OF MERCHANTABILITY, NONINFRINGEMENT, TITLE, FITNESS FOR ANY
-PARTICULAR PURPOSE, OR WARRANTIES ARISING FROM CONDUCT, COURSE OF DEALING, OR
-USAGE OF TRADE. IN NO EVENT SHALL AMD OR ITS LICENSORS BE LIABLE FOR ANY
-DAMAGES WHATSOEVER (INCLUDING, WITHOUT LIMITATION, DAMAGES FOR LOSS OF PROFITS,
-BUSINESS INTERRUPTION, OR LOSS OF INFORMATION) ARISING OUT OF THE USE OF OR
-INABILITY TO USE THE MATERIALS, EVEN IF AMD HAS BEEN ADVISED OF THE
-POSSIBILITY OF SUCH DAMAGES. BECAUSE SOME JURISDICTIONS PROHIBIT THE EXCLUSION
-OR LIMITATION OF LIABILITY FOR CONSEQUENTIAL OR INCIDENTAL DAMAGES, THE ABOVE
-LIMITATION MAY NOT APPLY TO YOU.
-AMD does not assume any responsibility for any errors which may appear in the
-Materials nor any responsibility to support or update the Materials. AMD
-retains the right to modify the Materials at any time, without notice, and is
-not obligated to provide such modified Materials to you.
-NO SUPPORT OBLIGATION: AMD is not obligated to furnish, support, or make any
-further information, software, technical information, know-how, or show-how
-available to you.
-U.S. GOVERNMENT RESTRICTED RIGHTS: The Materials are provided with "RESTRICTED
-RIGHTS." Use, duplication, or disclosure by the Government is subject to the
-restrictions as set forth in FAR 52.227-14 and DFAR 252.227-7013, et seq., or
-its successor. Use of the Materials by the Government constitutes
-acknowledgement of AMD's proprietary rights in them.
-============================================================================*/
-// 2005.9 serengeti support
-// by yhlu
-//
-
 /*
- * 2005.9 yhlu add madt lapic creat dynamically and SRAT related
+ * This file is part of the coreboot project.
+ *
+ * Copyright (C) 2005 Advanced Micro Devices, Inc.
+ * Copyright (C) 2010 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 as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * 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
  */
 
+/*
+ * Description: Add madt lapic creat dynamically and SRAT related by yhlu
+*/
+
 #include <console/console.h>
 #include <string.h>
 #include <arch/acpi.h>

Modified: trunk/src/southbridge/amd/amd8132/amd8132_bridge.c
==============================================================================
--- trunk/src/southbridge/amd/amd8132/amd8132_bridge.c	Thu Jun  3 09:51:09 2010	(r5606)
+++ trunk/src/southbridge/amd/amd8132/amd8132_bridge.c	Fri Jun  4 09:49:53 2010	(r5607)
@@ -1,43 +1,27 @@
-/*============================================================================
-Copyright 2005 ADVANCED MICRO DEVICES, INC. All Rights Reserved.
-This software and any related documentation (the "Materials") are the
-confidential proprietary information of AMD. Unless otherwise provided in a
-software agreement specifically licensing the Materials, the Materials are
-provided in confidence and may not be distributed, modified, or reproduced in
-whole or in part by any means.
-LIMITATION OF LIABILITY: THE MATERIALS ARE PROVIDED "AS IS" WITHOUT ANY
-EXPRESS OR IMPLIED WARRANTY OF ANY KIND, INCLUDING BUT NOT LIMITED TO
-WARRANTIES OF MERCHANTABILITY, NONINFRINGEMENT, TITLE, FITNESS FOR ANY
-PARTICULAR PURPOSE, OR WARRANTIES ARISING FROM CONDUCT, COURSE OF DEALING, OR
-USAGE OF TRADE. IN NO EVENT SHALL AMD OR ITS LICENSORS BE LIABLE FOR ANY
-DAMAGES WHATSOEVER (INCLUDING, WITHOUT LIMITATION, DAMAGES FOR LOSS OF PROFITS,
-BUSINESS INTERRUPTION, OR LOSS OF INFORMATION) ARISING OUT OF THE USE OF OR
-INABILITY TO USE THE MATERIALS, EVEN IF AMD HAS BEEN ADVISED OF THE
-POSSIBILITY OF SUCH DAMAGES. BECAUSE SOME JURISDICTIONS PROHIBIT THE EXCLUSION
-OR LIMITATION OF LIABILITY FOR CONSEQUENTIAL OR INCIDENTAL DAMAGES, THE ABOVE
-LIMITATION MAY NOT APPLY TO YOU.
-AMD does not assume any responsibility for any errors which may appear in the
-Materials nor any responsibility to support or update the Materials. AMD
-retains the right to modify the Materials at any time, without notice, and is
-not obligated to provide such modified Materials to you.
-NO SUPPORT OBLIGATION: AMD is not obligated to furnish, support, or make any
-further information, software, technical information, know-how, or show-how
-available to you.
-U.S. GOVERNMENT RESTRICTED RIGHTS: The Materials are provided with "RESTRICTED
-RIGHTS." Use, duplication, or disclosure by the Government is subject to the
-restrictions as set forth in FAR 52.227-14 and DFAR 252.227-7013, et seq., or
-its successor. Use of the Materials by the Government constitutes
-acknowledgement of AMD's proprietary rights in them.
-============================================================================*/
-//@DOC
-// in amd8132_bridge.c
 /*
-$1.0$
-*/
-// Description: amd 8132 support
-// by yhlu
-//
-//============================================================================
+ * This file is part of the coreboot project.
+ *
+ * Copyright (C) 2005 Advanced Micro Devices, Inc.
+ * Copyright (C) 2010 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 as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * 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
+ */
+
+/*
+ * Description: Amd 8132 support by yhlu
+ */
 
 #include <console/console.h>
 #include <device/device.h>



From stepan at coresystems.de  Fri Jun  4 09:53:07 2010
From: stepan at coresystems.de (Stefan Reinauer)
Date: Fri, 04 Jun 2010 09:53:07 +0200
Subject: [coreboot] A patch to replace the headers of three files - no
 functional changes.
In-Reply-To: <276EC11373289744A112A8FE6675506701183E8DC0@SAUSEXMBP01.amd.com>
References: <276EC11373289744A112A8FE6675506701183E8DC0@SAUSEXMBP01.amd.com>
Message-ID: <4C08B0E3.6090808@coresystems.de>

On 6/4/10 1:41 AM, Vibrans, Frank wrote:
>
> This patch replaces the headers of the following files:
>
>  
>
>     src/cpu/amd/model_fxx/model_fxx_update_microcode.c
>
>     src/northbridge/amd/amdk8/amdk8_acpi.c
>
>     src/southbridge/amd/amd8132/amd8132_bridge.c
>
>  
>
> Signed-off by: Frank Vibrans frank.vibrans at amd.com
> <mailto:frank.vibrans at amd.com>
>
>  
>
> ---
>
Dear Frank,

thank you very much for taking care of this issue so quickly.

It's great to see that you and AMD supporting this project! Thank you!

I committed the header changes as r5607 to our repository.

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 --------------
An HTML attachment was scrubbed...
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20100604/1a268a25/attachment.html>

From spooky85 at gmail.com  Fri Jun  4 10:42:04 2010
From: spooky85 at gmail.com (Christian Ruppert)
Date: Fri, 04 Jun 2010 10:42:04 +0200
Subject: [coreboot] ASUS M4A77TD-PRO. First step: buy spare flash
	chips...
In-Reply-To: <20100604060220.GA4208@ideafix.casa.ct>
References: <20100603223635.GA4587@ideafix.casa.ct>
	<20100604060220.GA4208@ideafix.casa.ct>
Message-ID: <4C08BC5C.5050607@gmail.com>

On 06/04/2010 08:02 AM, xdrudis wrote:
>> Where do you get your spare EEPROMs ?
>>
> 
> I've tried a couple of local electronics parts shops in Barcelona, 
> and they hardly knew Macronix. They couldn't find any MX25L parts 
> listed. I'll try again, I guess...But maybe I should go somewhere else ?
> 

http://bios-repair.co.uk/bios/eeprom.htm
MX25L8005PC-15G
1MB SPI 8 Pin PDIP

-- 
Regards,
Christian Ruppert

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 262 bytes
Desc: OpenPGP digital signature
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20100604/d2ed0277/attachment.sig>

From svn at coreboot.org  Fri Jun  4 13:01:50 2010
From: svn at coreboot.org (coreboot)
Date: Fri, 04 Jun 2010 11:01:50 -0000
Subject: [coreboot] #166: Compiling a Geode target without
 CONFIG_VGA_ROM_RUN fails to find VSA functions.
Message-ID: <063.cc58d54490759394ae17bb96706c5b67@coreboot.org>

#166: Compiling a Geode target without CONFIG_VGA_ROM_RUN fails to find VSA
functions.
--------------------------------------------+-------------------------------
    Reporter:  edwin_beasant@?              |         Owner:  stepan@?             
        Type:  defect                       |        Status:  new                  
    Priority:  major                        |     Milestone:  Going mainstream     
   Component:  coreboot                     |      Keywords:  Geode VSA option rom 
Dependencies:                               |   Patchstatus:  there is no patch    
--------------------------------------------+-------------------------------
 For some reason, the VSA running code has been moved to the option rom
 source files - this is not usable when I don't wish coreboot to run the
 option roms on the system (I want seabios to do it).

 Compilation fails trying to find do_vsmbios.
 reporting:

 build/coreboot_ram.o: In function `pci_domain_enable':
 northbridge.c:(.text+0xd44): undefined reference to `do_vsmbios'
 collect2: ld returned 1 exit status
 make: *** [build/coreboot_ram] Error 1

 This code needs to be independent of running option roms or not.

-- 
Ticket URL: <https://tracker.coreboot.org/trac/coreboot/ticket/166>
coreboot <http://www.coreboot.org/>


From svn at coreboot.org  Fri Jun  4 16:20:07 2010
From: svn at coreboot.org (coreboot)
Date: Fri, 04 Jun 2010 14:20:07 -0000
Subject: [coreboot] #166: Compiling a Geode target without
 CONFIG_VGA_ROM_RUN fails to find VSA functions.
In-Reply-To: <063.cc58d54490759394ae17bb96706c5b67@coreboot.org>
References: <063.cc58d54490759394ae17bb96706c5b67@coreboot.org>
Message-ID: <072.5ce05356d16fae629d17c893320359dc@coreboot.org>

#166: Compiling a Geode target without CONFIG_VGA_ROM_RUN fails to find VSA
functions.
--------------------------------------------+-------------------------------
    Reporter:  edwin_beasant@?              |         Owner:  stepan@?             
        Type:  defect                       |        Status:  new                  
    Priority:  major                        |     Milestone:  Going mainstream     
   Component:  coreboot                     |      Keywords:  Geode VSA option rom 
Dependencies:                               |   Patchstatus:  patch needs review   
--------------------------------------------+-------------------------------
Changes (by myles):

  * patchstatus:  there is no patch => patch needs review


Comment:

 you can't use "secure mode" with VSA, either

 Signed-off-by: Myles Watson <mylesgw at gmail.com>

-- 
Ticket URL: <https://tracker.coreboot.org/trac/coreboot/ticket/166#comment:1>
coreboot <http://www.coreboot.org/>


From mylesgw at gmail.com  Fri Jun  4 16:45:01 2010
From: mylesgw at gmail.com (Myles Watson)
Date: Fri, 4 Jun 2010 08:45:01 -0600
Subject: [coreboot] #166: Compiling a Geode target without
	CONFIG_VGA_ROM_RUN fails to find VSA functions.
In-Reply-To: <072.5ce05356d16fae629d17c893320359dc@coreboot.org>
References: <063.cc58d54490759394ae17bb96706c5b67@coreboot.org>
	<072.5ce05356d16fae629d17c893320359dc@coreboot.org>
Message-ID: <AANLkTinHso8KrZBH4NdAcr073OvtP-pEiD8Jh-6mF9bD@mail.gmail.com>

Here's the patch for those that don't use the tracker.

you can't use "secure mode" with VSA, either

Signed-off-by: Myles Watson <mylesgw at gmail.com>

Thanks,
Myles
-------------- next part --------------
A non-text attachment was scrubbed...
Name: vsa_oprom.diff
Type: text/x-patch
Size: 1135 bytes
Desc: not available
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20100604/3b1c6fd9/attachment.diff>

From mylesgw at gmail.com  Fri Jun  4 16:56:04 2010
From: mylesgw at gmail.com (Myles Watson)
Date: Fri, 4 Jun 2010 08:56:04 -0600
Subject: [coreboot] [PATCH] libpayload: fix cmos checksum.
In-Reply-To: <4C0830C1.8060902@coresystems.de>
References: <4C0830C1.8060902@coresystems.de>
Message-ID: <AANLkTinO0ADVUbjY59Pltb3uP--pXQVBakVU0sWX7qN1@mail.gmail.com>

On Thu, Jun 3, 2010 at 4:46 PM, Stefan Reinauer <stepan at coresystems.de> wrote:
> See patch.

+	checksum = (~checksum)&0xffff;

A tiny bit of overkill since checksum is u16.

Acked-by: Myles Watson <mylesgw at gmail.com>

Thanks,
Myles



From r.marek at assembler.cz  Fri Jun  4 17:32:43 2010
From: r.marek at assembler.cz (Rudolf Marek)
Date: Fri, 04 Jun 2010 17:32:43 +0200
Subject: [coreboot] ASUS M4A77TD-PRO. First step: buy spare
	flash	chips...
In-Reply-To: <20100604060220.GA4208@ideafix.casa.ct>
References: <20100603223635.GA4587@ideafix.casa.ct>
	<20100604060220.GA4208@ideafix.casa.ct>
Message-ID: <4C091C9B.60607@assembler.cz>

Try

http://search.digikey.com/scripts/DkSearch/dksus.dll?Detail&name=W25Q80BVDAIG-ND

Check if it matches - if you have DIP8 then yes but please recheck,
Gotta run,

Rudolf



From peter at stuge.se  Fri Jun  4 17:48:52 2010
From: peter at stuge.se (Peter Stuge)
Date: Fri, 4 Jun 2010 17:48:52 +0200
Subject: [coreboot] #166: Compiling a Geode target
	without	CONFIG_VGA_ROM_RUN fails to find VSA functions.
In-Reply-To: <AANLkTinHso8KrZBH4NdAcr073OvtP-pEiD8Jh-6mF9bD@mail.gmail.com>
References: <063.cc58d54490759394ae17bb96706c5b67@coreboot.org>
	<072.5ce05356d16fae629d17c893320359dc@coreboot.org>
	<AANLkTinHso8KrZBH4NdAcr073OvtP-pEiD8Jh-6mF9bD@mail.gmail.com>
Message-ID: <20100604154852.16813.qmail@stuge.se>

Myles Watson wrote:
> you can't use "secure mode" with VSA, either
> 
> Signed-off-by: Myles Watson <mylesgw at gmail.com>

Acked-by: Peter Stuge <peter at stuge.se>



From svn at coreboot.org  Fri Jun  4 17:55:13 2010
From: svn at coreboot.org (repository service)
Date: Fri, 04 Jun 2010 17:55:13 +0200
Subject: [coreboot] [commit] r5608 - trunk/src/devices
Message-ID: <E1OKZEn-0001QZ-84@ra.coresystems.de>

Author: myles
Date: Fri Jun  4 17:55:12 2010
New Revision: 5608
URL: https://tracker.coreboot.org/trac/coreboot/changeset/5608

Log:
Enable PCI_OPTION_ROM_REALMODE when GEODE_VSA is selected.

Using YABEL isn't supported for the VSA, so don't allow a choice.

Signed-off-by: Myles Watson <mylesgw at gmail.com>
Acked-by: Peter Stuge <peter at stuge.se>

Modified:
   trunk/src/devices/Kconfig
   trunk/src/devices/Makefile.inc

Modified: trunk/src/devices/Kconfig
==============================================================================
--- trunk/src/devices/Kconfig	Fri Jun  4 09:49:53 2010	(r5607)
+++ trunk/src/devices/Kconfig	Fri Jun  4 17:55:12 2010	(r5608)
@@ -46,7 +46,7 @@
 	prompt "Option ROM execution type"
 	default PCI_OPTION_ROM_RUN_YABEL if !ARCH_X86
 	default PCI_OPTION_ROM_RUN_REALMODE if ARCH_X86
-	depends on PCI_ROM_RUN || VGA_ROM_RUN
+	depends on PCI_ROM_RUN || VGA_ROM_RUN || GEODE_VSA
 
 config PCI_OPTION_ROM_RUN_REALMODE
 	prompt "Native mode"
@@ -61,6 +61,7 @@
 config PCI_OPTION_ROM_RUN_YABEL
 	prompt "Secure mode"
 	bool
+	depends on !GEODE_VSA
 	help
 	  If you select this option, the x86emu CPU emulator will be used to
 	  execute PCI option ROMs.

Modified: trunk/src/devices/Makefile.inc
==============================================================================
--- trunk/src/devices/Makefile.inc	Fri Jun  4 09:49:53 2010	(r5607)
+++ trunk/src/devices/Makefile.inc	Fri Jun  4 17:55:12 2010	(r5608)
@@ -11,11 +11,11 @@
 obj-y += pci_ops.o
 obj-y += smbus_ops.o
 
+subdirs-y += oprom
+
 ifeq ($(CONFIG_PCI_ROM_RUN),y)
 obj-y += pci_rom.o
-subdirs-y += oprom
 else
 obj-$(CONFIG_VGA_ROM_RUN) += pci_rom.o
-subdirs-$(CONFIG_VGA_ROM_RUN) += oprom
 endif
 



From mylesgw at gmail.com  Fri Jun  4 17:55:40 2010
From: mylesgw at gmail.com (Myles Watson)
Date: Fri, 4 Jun 2010 09:55:40 -0600
Subject: [coreboot] #166: Compiling a Geode target without
	CONFIG_VGA_ROM_RUN fails to find VSA functions.
In-Reply-To: <20100604154852.16813.qmail@stuge.se>
References: <063.cc58d54490759394ae17bb96706c5b67@coreboot.org>
	<072.5ce05356d16fae629d17c893320359dc@coreboot.org>
	<AANLkTinHso8KrZBH4NdAcr073OvtP-pEiD8Jh-6mF9bD@mail.gmail.com>
	<20100604154852.16813.qmail@stuge.se>
Message-ID: <AANLkTinWd9dJRvqOicrVhccsPE0N936LpdD8dgRz867P@mail.gmail.com>

On Fri, Jun 4, 2010 at 9:48 AM, Peter Stuge <peter at stuge.se> wrote:
> Myles Watson wrote:
>> you can't use "secure mode" with VSA, either
>>
>> Signed-off-by: Myles Watson <mylesgw at gmail.com>
>
> Acked-by: Peter Stuge <peter at stuge.se>

Rev 5608.

Thanks,
Myles



From svn at coreboot.org  Fri Jun  4 17:56:33 2010
From: svn at coreboot.org (coreboot)
Date: Fri, 04 Jun 2010 15:56:33 -0000
Subject: [coreboot] #166: Compiling a Geode target without
 CONFIG_VGA_ROM_RUN fails to find VSA functions.
In-Reply-To: <063.cc58d54490759394ae17bb96706c5b67@coreboot.org>
References: <063.cc58d54490759394ae17bb96706c5b67@coreboot.org>
Message-ID: <072.46c72d14432022ddf5d4992cdde568c6@coreboot.org>

#166: Compiling a Geode target without CONFIG_VGA_ROM_RUN fails to find VSA
functions.
-------------------------------------------+--------------------------------
   Reporter:  edwin_beasant@?              |          Owner:  stepan@?             
       Type:  defect                       |         Status:  closed               
   Priority:  major                        |      Milestone:  Going mainstream     
  Component:  coreboot                     |     Resolution:  fixed                
   Keywords:  Geode VSA option rom         |   Dependencies:                       
Patchstatus:  patch has been committed     |  
-------------------------------------------+--------------------------------
Changes (by myles):

  * status:  new => closed
  * patchstatus:  patch needs review => patch has been committed
  * resolution:  => fixed


-- 
Ticket URL: <https://tracker.coreboot.org/trac/coreboot/ticket/166#comment:2>
coreboot <http://www.coreboot.org/>


From edwin_beasant at virtensys.com  Fri Jun  4 17:25:58 2010
From: edwin_beasant at virtensys.com (Edwin Beasant)
Date: Fri, 4 Jun 2010 16:25:58 +0100
Subject: [coreboot] [PATCH] Fix geode lx VSA loading
Message-ID: <95EC52016CC5DE4896FD95FA7323A4DB152FFE43DA@mr-burns.exchange.virtensys.com>

This patch fixes the option rom code that was buggy when it switched segment registers before restoring register values. This was breaking the Geode VSA, and probably would have hurt other option roms as well.

Signed-off by: Edwin Beasant edwin_beasant at virtensys.com

---
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20100604/56e2507e/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: coreboot-v4-vsa-fix.patch
Type: application/octet-stream
Size: 2296 bytes
Desc: coreboot-v4-vsa-fix.patch
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20100604/56e2507e/attachment.obj>

From stepan at coresystems.de  Fri Jun  4 18:29:59 2010
From: stepan at coresystems.de (Stefan Reinauer)
Date: Fri, 04 Jun 2010 18:29:59 +0200
Subject: [coreboot] [PATCH] unavailable resources
Message-ID: <4C092A07.3070408@coresystems.de>

See patch
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20100604/bdf47194/attachment.html>
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: resource_not-available.diff
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20100604/bdf47194/attachment.ksh>

From mylesgw at gmail.com  Fri Jun  4 18:36:24 2010
From: mylesgw at gmail.com (Myles Watson)
Date: Fri, 4 Jun 2010 10:36:24 -0600
Subject: [coreboot] [PATCH] unavailable resources
In-Reply-To: <4C092A07.3070408@coresystems.de>
References: <4C092A07.3070408@coresystems.de>
Message-ID: <AANLkTik8RFgjiWNfVIYvQDmCArFiyBrvcDcg_66toMPw@mail.gmail.com>

		if (!(res->flags & IORESOURCE_FIXED))
			continue;
...

 		/* Is it already outside the limits? */
-		if (((res->base + res->size -1) < lim->base) || (res->base > lim->limit))
+		if (((res->base + res->size -1) < lim->base) || (res->base > lim->limit)) {
+			printk(BIOS_ERR, "%s: Resources not available.\n", dev_path(dev));
 			continue;
+		}

This code only is executed for fixed resources.  If they are outside
of the limits it's a good thing.  I don't think there should be an
error message.

Thanks,
Myles



From patrick at georgi-clan.de  Fri Jun  4 18:37:37 2010
From: patrick at georgi-clan.de (Patrick Georgi)
Date: Fri, 04 Jun 2010 18:37:37 +0200
Subject: [coreboot] [PATCH] Fix geode lx VSA loading
In-Reply-To: <95EC52016CC5DE4896FD95FA7323A4DB152FFE43DA@mr-burns.exchange.virtensys.com>
References: <95EC52016CC5DE4896FD95FA7323A4DB152FFE43DA@mr-burns.exchange.virtensys.com>
Message-ID: <1275669457.1521.7.camel@tetris>

Am Freitag, den 04.06.2010, 16:25 +0100 schrieb Edwin Beasant:
> This patch fixes the option rom code that was buggy when it switched
> segment registers before restoring register values. This was breaking
> the Geode VSA, and probably would have hurt other option roms as well.
> 
>  
> 
> Signed-off by: Edwin Beasant edwin_beasant at virtensys.com

Except for the first two parts (the magic values in ecx/edx and
whitespace), and assuming this is tested, the patch is

Acked-by: Patrick Georgi <patrick.georgi at coresystems.de>





From stepan at coresystems.de  Fri Jun  4 18:40:31 2010
From: stepan at coresystems.de (Stefan Reinauer)
Date: Fri, 04 Jun 2010 18:40:31 +0200
Subject: [coreboot] [PATCH] Fix geode lx VSA loading
In-Reply-To: <1275669457.1521.7.camel@tetris>
References: <95EC52016CC5DE4896FD95FA7323A4DB152FFE43DA@mr-burns.exchange.virtensys.com>
	<1275669457.1521.7.camel@tetris>
Message-ID: <4C092C7F.5030302@coresystems.de>

On 6/4/10 6:37 PM, Patrick Georgi wrote:
> Am Freitag, den 04.06.2010, 16:25 +0100 schrieb Edwin Beasant:
>   
>> This patch fixes the option rom code that was buggy when it switched
>> segment registers before restoring register values. This was breaking
>> the Geode VSA, and probably would have hurt other option roms as well.
>>
>>  
>>
>> Signed-off by: Edwin Beasant edwin_beasant at virtensys.com
>>     
> Except for the first two parts (the magic values in ecx/edx and
> whitespace), and assuming this is tested, the patch is
>
> Acked-by: Patrick Georgi <patrick.georgi at coresystems.de>
>
>
>   

I did a new version of the patch with those issues fixed (and pushing
one register instead of all), see attachment

Signed-off-by: Edwin Beasant <edwin_beasant at virtensys.com>
Signed-off-by: Stefan Reinauer <stepan at coresystems.de>
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: vsa.diff
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20100604/e8c75dfd/attachment.ksh>

From stepan at coresystems.de  Fri Jun  4 18:41:31 2010
From: stepan at coresystems.de (Stefan Reinauer)
Date: Fri, 04 Jun 2010 18:41:31 +0200
Subject: [coreboot] [PATCH] unavailable resources
In-Reply-To: <AANLkTik8RFgjiWNfVIYvQDmCArFiyBrvcDcg_66toMPw@mail.gmail.com>
References: <4C092A07.3070408@coresystems.de>
	<AANLkTik8RFgjiWNfVIYvQDmCArFiyBrvcDcg_66toMPw@mail.gmail.com>
Message-ID: <4C092CBB.1000007@coresystems.de>

On 6/4/10 6:36 PM, Myles Watson wrote:
> 		if (!(res->flags & IORESOURCE_FIXED))
> 			continue;
> ...
>
>  		/* Is it already outside the limits? */
> -		if (((res->base + res->size -1) < lim->base) || (res->base > lim->limit))
> +		if (((res->base + res->size -1) < lim->base) || (res->base > lim->limit)) {
> +			printk(BIOS_ERR, "%s: Resources not available.\n", dev_path(dev));
>  			continue;
> +		}
>
> This code only is executed for fixed resources.  If they are outside
> of the limits it's a good thing.  I don't think there should be an
> error message.
>   
Why is that good? (can we add that explanation to the code as a comment?)




From xdrudis at tinet.cat  Fri Jun  4 18:45:50 2010
From: xdrudis at tinet.cat (Xavi Drudis Ferran)
Date: Fri, 4 Jun 2010 18:45:50 +0200 (CEST)
Subject: [coreboot] ASUS M4A77TD-PRO. First step: buy spare
 flash	chips...
In-Reply-To: <4C091C9B.60607@assembler.cz>
References: <20100603223635.GA4587@ideafix.casa.ct>
	<20100604060220.GA4208@ideafix.casa.ct> <4C091C9B.60607@assembler.cz>
Message-ID: <33478.80.34.165.131.1275669950.squirrel@webmail.tinet.cat>

> Try
>
> http://search.digikey.com/scripts/DkSearch/dksus.dll?Detail&name=W25Q80BVDAIG-ND
>
> Check if it matches - if you have DIP8 then yes but please recheck,
> Gotta run,
>
> Rudolf
>

Thanks to you and Christian Ruppert

Yes, it's 300MIL 8-PDIP, according to the shape, the approximate size, the number of pins
and the marking on the chip (the part that says it's PDIP is the P and that is visible with a magnifying
glass). The only difference I see between the Winbond and the Macronix is that the Macronix
is max 70/33 MHz and the Winbond is max 80/50 MHz. I'll see if I can find it locally, or otherwise
I'll buy either this Winbond at digkey or the Macronix at the Bios repair in UK that Christian Ruppert said.

Thank you very much.








From mylesgw at gmail.com  Fri Jun  4 18:49:45 2010
From: mylesgw at gmail.com (Myles Watson)
Date: Fri, 4 Jun 2010 10:49:45 -0600
Subject: [coreboot] [PATCH] unavailable resources
In-Reply-To: <4C092CBB.1000007@coresystems.de>
References: <4C092A07.3070408@coresystems.de>
	<AANLkTik8RFgjiWNfVIYvQDmCArFiyBrvcDcg_66toMPw@mail.gmail.com>
	<4C092CBB.1000007@coresystems.de>
Message-ID: <AANLkTims3pgp8HC6Vb60TgEi5E5EQEW0eRssUO0lfDwv@mail.gmail.com>

On Fri, Jun 4, 2010 at 10:41 AM, Stefan Reinauer <stepan at coresystems.de> wrote:
> On 6/4/10 6:36 PM, Myles Watson wrote:
>> ? ? ? ? ? ? ? if (!(res->flags & IORESOURCE_FIXED))
>> ? ? ? ? ? ? ? ? ? ? ? continue;
>> ...
>>
>> ? ? ? ? ? ? ? /* Is it already outside the limits? */
>> - ? ? ? ? ? ? if (((res->base + res->size -1) < lim->base) || (res->base > lim->limit))
>> + ? ? ? ? ? ? if (((res->base + res->size -1) < lim->base) || (res->base > lim->limit)) {
>> + ? ? ? ? ? ? ? ? ? ? printk(BIOS_ERR, "%s: Resources not available.\n", dev_path(dev));
>> ? ? ? ? ? ? ? ? ? ? ? continue;
>> + ? ? ? ? ? ? }
>>
>> This code only is executed for fixed resources. ?If they are outside
>> of the limits it's a good thing. ?I don't think there should be an
>> error message.
>>
> Why is that good? (can we add that explanation to the code as a comment?)
Sure.  I guess since I wrote it I'm not a good judge of clarifying comments.

Here's the big picture:

You start with a full address space
You constrain what the allocator can use by subtracting fixed resources

And a completely contrived example:
 - take I/O 0x0000-0xffff
 - let's imagine that 0x400-420, 0x40-0x80, and 0xf000-0xf800 are
fixed resources (the allocator can't use that space)
First pass, the allocator chooses to use 0x420-0xffff (larger than 0x0-0x400)
Second pass, the allocator does nothing because 0x40-0x80 is already
outside the limits
Third pass, the allocator chooses to use 0x420-0xf800 (larger than
0xf800-0xffff.

I'd love it if you'd add some clarifying comments.

Thanks,
Myles



From mylesgw at gmail.com  Fri Jun  4 18:53:29 2010
From: mylesgw at gmail.com (Myles Watson)
Date: Fri, 4 Jun 2010 10:53:29 -0600
Subject: [coreboot] [PATCH] Fix geode lx VSA loading
In-Reply-To: <4C092C7F.5030302@coresystems.de>
References: <95EC52016CC5DE4896FD95FA7323A4DB152FFE43DA@mr-burns.exchange.virtensys.com><1275669457.1521.7.camel@tetris>
	<4C092C7F.5030302@coresystems.de>
Message-ID: <208622BC47ED4B7F88606AF82C8056B8@chimp>

I don't see where ax gets set to 0.  Does the comment need to be updated, or
do you want all the segments set to ax?

+	/* initialize registers for option rom lcall */
+	movl	__registers +  0, %eax
+	movl	__registers +  4, %ebx
+	movl	__registers +  8, %ecx
+	movl	__registers + 12, %edx
+	movl	__registers + 16, %esi
+	movl	__registers + 20, %edi	
+
 	/* Set all segments to 0x0000, ds to 0x0040 */
+	push	%ax
 	mov	%ax, %es
 	mov	%ax, %fs
 	mov	%ax, %gs
 	mov	$0x40, %ax
 	mov	%ax, %ds
+	pop	%ax

Maybe you want a

mov $0, %ax

right after the push %ax?

Thanks,
Myles




From stepan at coresystems.de  Fri Jun  4 18:57:09 2010
From: stepan at coresystems.de (Stefan Reinauer)
Date: Fri, 04 Jun 2010 18:57:09 +0200
Subject: [coreboot] [PATCH] Fix geode lx VSA loading
In-Reply-To: <4C092C7F.5030302@coresystems.de>
References: <95EC52016CC5DE4896FD95FA7323A4DB152FFE43DA@mr-burns.exchange.virtensys.com>	<1275669457.1521.7.camel@tetris>
	<4C092C7F.5030302@coresystems.de>
Message-ID: <4C093065.8040601@coresystems.de>

On 6/4/10 6:40 PM, Stefan Reinauer wrote:
> On 6/4/10 6:37 PM, Patrick Georgi wrote:
>   
>> Am Freitag, den 04.06.2010, 16:25 +0100 schrieb Edwin Beasant:
>>   
>>     
>>> This patch fixes the option rom code that was buggy when it switched
>>> segment registers before restoring register values. This was breaking
>>> the Geode VSA, and probably would have hurt other option roms as well.
>>>
>>>  
>>>
>>> Signed-off by: Edwin Beasant edwin_beasant at virtensys.com
>>>     
>>>       
>> Except for the first two parts (the magic values in ecx/edx and
>> whitespace), and assuming this is tested, the patch is
>>
>> Acked-by: Patrick Georgi <patrick.georgi at coresystems.de>
>>
>>
>>   
>>     
> I did a new version of the patch with those issues fixed (and pushing
> one register instead of all), see attachment
>
> Signed-off-by: Edwin Beasant <edwin_beasant at virtensys.com>
> Signed-off-by: Stefan Reinauer <stepan at coresystems.de>
>   
Updated patch.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20100604/6338b00e/attachment.html>
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: vsa2.diff
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20100604/6338b00e/attachment.ksh>

From mbertens at xs4all.nl  Fri Jun  4 20:14:14 2010
From: mbertens at xs4all.nl (mbertens)
Date: Fri, 04 Jun 2010 20:14:14 +0200
Subject: [coreboot] Update on NOKIA-IP530
In-Reply-To: <AANLkTil90azgdY4b1sGlJ047eX07KEYq7zjq4YpNBog0@mail.gmail.com>
References: <1275587298.3803.21.camel@andrala.reboot>
	<AANLkTikkwYfB9HHShBPnGkgjWqpe2m54t9hpqREbwlOH@mail.gmail.com>
	<AANLkTil90azgdY4b1sGlJ047eX07KEYq7zjq4YpNBog0@mail.gmail.com>
Message-ID: <1275675254.3803.33.camel@andrala.reboot>

Signed-off-by: Marc Bertens <mbertens at xs4all.nl>



On Thu, 2010-06-03 at 15:12 -0600, Myles Watson wrote:
> On Thu, Jun 3, 2010 at 3:02 PM, Myles Watson <mylesgw at gmail.com> wrote:
> > Marc,
> >
> > Here's your patch with a couple of changes:
> > 1. took out white space changes so that I could see the devicetree.cb changes
> >  - I understood most of the changes, but why remove the register
> > settings for the keyboard and mouse?
> >  - there's no reason we can' t use tabs when it gets committed, I just
> > couldn't see the differences.
> >
> > 2. changed the Kconfig a little for your drivers
> >  - Kconfig of drivers shouldn't show up in the menu.  If you build
> > this board, you want it to have all the drivers.
> >
> > Signed-off-by: Myles Watson <mylesgw at gmail.com>
> 
> I forgot a final refresh of the patches.  Sorry.
> 
> Thanks,
> Myles
> -- 
> coreboot mailing list: coreboot at coreboot.org
> http://www.coreboot.org/mailman/listinfo/coreboot
-- 





From mylesgw at gmail.com  Fri Jun  4 20:29:36 2010
From: mylesgw at gmail.com (Myles Watson)
Date: Fri, 4 Jun 2010 12:29:36 -0600
Subject: [coreboot] Update on NOKIA-IP530
In-Reply-To: <1275675254.3803.33.camel@andrala.reboot>
References: <1275587298.3803.21.camel@andrala.reboot>
	<AANLkTikkwYfB9HHShBPnGkgjWqpe2m54t9hpqREbwlOH@mail.gmail.com>
	<AANLkTil90azgdY4b1sGlJ047eX07KEYq7zjq4YpNBog0@mail.gmail.com>
	<1275675254.3803.33.camel@andrala.reboot>
Message-ID: <8812CE65242647D19DD672DCEC1C245E@chimp>

> Signed-off-by: Marc Bertens <mbertens at xs4all.nl>
Acked-by: is the tag you want if you agree with the patch and want it to be
committed.  I'm hoping that means you tested it.

> > >  - I understood most of the changes, but why remove the register
> > > settings for the keyboard and mouse?
Were they causing a problem?

> > >  - there's no reason we can' t use tabs when it gets committed, I just
> > > couldn't see the differences.
Did you have a preference here?

Thanks,
Myles





From mbertens at xs4all.nl  Fri Jun  4 20:38:03 2010
From: mbertens at xs4all.nl (mbertens)
Date: Fri, 04 Jun 2010 20:38:03 +0200
Subject: [coreboot] Update on NOKIA-IP530
In-Reply-To: <8812CE65242647D19DD672DCEC1C245E@chimp>
References: <1275587298.3803.21.camel@andrala.reboot>
	<AANLkTikkwYfB9HHShBPnGkgjWqpe2m54t9hpqREbwlOH@mail.gmail.com>
	<AANLkTil90azgdY4b1sGlJ047eX07KEYq7zjq4YpNBog0@mail.gmail.com>
	<1275675254.3803.33.camel@andrala.reboot>
	<8812CE65242647D19DD672DCEC1C245E@chimp>
Message-ID: <1275676683.3803.39.camel@andrala.reboot>

On Fri, 2010-06-04 at 12:29 -0600, Myles Watson wrote:
> > Signed-off-by: Marc Bertens <mbertens at xs4all.nl>
> Acked-by: is the tag you want if you agree with the patch and want it to be
> committed.  I'm hoping that means you tested it.
Ok, i mis understand you then, because i was not seeing any real
changes. But i will test the patches. 
> 
> > > >  - I understood most of the changes, but why remove the register
> > > > settings for the keyboard and mouse?
> Were they causing a problem?
The IP530 doesn't have a mouse or keyboard, they where not a problem,
but i dont like any thing these that is not nessary.
> 
> > > >  - there's no reason we can' t use tabs when it gets committed, I just
> > > > couldn't see the differences.
> Did you have a preference here?
Regarding the tabs, i was just folling the coding rules, nothing more or
less :-)
> 
> Thanks,
> Myles
> 
> 

I will send you an ack when i tested it.

Marc 




From mylesgw at gmail.com  Fri Jun  4 20:46:45 2010
From: mylesgw at gmail.com (Myles Watson)
Date: Fri, 4 Jun 2010 12:46:45 -0600
Subject: [coreboot] Update on NOKIA-IP530
In-Reply-To: <1275676683.3803.39.camel@andrala.reboot>
References: <1275587298.3803.21.camel@andrala.reboot>
	<AANLkTikkwYfB9HHShBPnGkgjWqpe2m54t9hpqREbwlOH@mail.gmail.com>
	<AANLkTil90azgdY4b1sGlJ047eX07KEYq7zjq4YpNBog0@mail.gmail.com>
	<1275675254.3803.33.camel@andrala.reboot>
	<8812CE65242647D19DD672DCEC1C245E@chimp>
	<1275676683.3803.39.camel@andrala.reboot>
Message-ID: <5FD03A5F92784807AEED3800D0762D57@chimp>

> On Fri, 2010-06-04 at 12:29 -0600, Myles Watson wrote:
> > > Signed-off-by: Marc Bertens <mbertens at xs4all.nl>
> > Acked-by: is the tag you want if you agree with the patch and want it to
> be
> > committed.  I'm hoping that means you tested it.
> Ok, i mis understand you then, because i was not seeing any real
> changes. But i will test the patches.
I didn't mean for there to be any, but I wanted to make sure I didn't break
it.

> > > > >  - I understood most of the changes, but why remove the register
> > > > > settings for the keyboard and mouse?
> > Were they causing a problem?
> The IP530 doesn't have a mouse or keyboard, they where not a problem,
> but i dont like any thing these that is not nessary.
Then should they be turned off?  I agree that simpler is better.

> >
> > > > >  - there's no reason we can' t use tabs when it gets committed, I
> just
> > > > > couldn't see the differences.
> > Did you have a preference here?
> Regarding the tabs, i was just folling the coding rules, nothing more or
> less :-)
Sorry about that.  It is an unofficial exception because the device trees
get so deeply nested.  I agree that we should make it official or use tabs.

> I will send you an ack when i tested it.
Great.  You could also test turning off the floppy and sign off an updated
patch.  I'll Ack and commit it.

Thanks,
Myles





From mbertens at xs4all.nl  Fri Jun  4 21:25:37 2010
From: mbertens at xs4all.nl (mbertens)
Date: Fri, 04 Jun 2010 21:25:37 +0200
Subject: [coreboot] Update on NOKIA-IP530
In-Reply-To: <5FD03A5F92784807AEED3800D0762D57@chimp>
References: <1275587298.3803.21.camel@andrala.reboot>
	<AANLkTikkwYfB9HHShBPnGkgjWqpe2m54t9hpqREbwlOH@mail.gmail.com>
	<AANLkTil90azgdY4b1sGlJ047eX07KEYq7zjq4YpNBog0@mail.gmail.com>
	<1275675254.3803.33.camel@andrala.reboot>
	<8812CE65242647D19DD672DCEC1C245E@chimp>
	<1275676683.3803.39.camel@andrala.reboot>
	<5FD03A5F92784807AEED3800D0762D57@chimp>
Message-ID: <1275679537.3803.42.camel@andrala.reboot>

Acked-by: Marc Bertens <mbertens at xs4all.nl>

I tested the patch at it worked fine, when i added the patch on the
\arch\i386\boot\pirq_routing.c too :-)

Marc 



On Fri, 2010-06-04 at 12:46 -0600, Myles Watson wrote:
> > On Fri, 2010-06-04 at 12:29 -0600, Myles Watson wrote:
> > > > Signed-off-by: Marc Bertens <mbertens at xs4all.nl>
> > > Acked-by: is the tag you want if you agree with the patch and want it to
> > be
> > > committed.  I'm hoping that means you tested it.
> > Ok, i mis understand you then, because i was not seeing any real
> > changes. But i will test the patches.
> I didn't mean for there to be any, but I wanted to make sure I didn't break
> it.
> 
> > > > > >  - I understood most of the changes, but why remove the register
> > > > > > settings for the keyboard and mouse?
> > > Were they causing a problem?
> > The IP530 doesn't have a mouse or keyboard, they where not a problem,
> > but i dont like any thing these that is not nessary.
> Then should they be turned off?  I agree that simpler is better.
> 
> > >
> > > > > >  - there's no reason we can' t use tabs when it gets committed, I
> > just
> > > > > > couldn't see the differences.
> > > Did you have a preference here?
> > Regarding the tabs, i was just folling the coding rules, nothing more or
> > less :-)
> Sorry about that.  It is an unofficial exception because the device trees
> get so deeply nested.  I agree that we should make it official or use tabs.
> 
> > I will send you an ack when i tested it.
> Great.  You could also test turning off the floppy and sign off an updated
> patch.  I'll Ack and commit it.
> 
> Thanks,
> Myles
> 
> 
> 
-- 





From svn at coreboot.org  Fri Jun  4 21:53:56 2010
From: svn at coreboot.org (repository service)
Date: Fri, 04 Jun 2010 21:53:56 +0200
Subject: [coreboot] [commit] r5609 - in trunk/src: drivers drivers/dec
	drivers/dec/21143 drivers/ti drivers/ti/pcmcia-cardbus
	include/device mainboard/nokia/ip530
Message-ID: <E1OKcxo-0006Dc-1Q@ra.coresystems.de>

Author: myles
Date: Fri Jun  4 21:53:55 2010
New Revision: 5609
URL: https://tracker.coreboot.org/trac/coreboot/changeset/5609

Log:
Fixes for Nokia IP530 and associated drivers.

Signed-off-by: Marc Bertens <mbertens at xs4all.nl>
Signed-off-by: Myles Watson <mylesgw at gmail.com>
Acked-by: Marc Bertens <mbertens at xs4all.nl>

Added:
   trunk/src/drivers/dec/
   trunk/src/drivers/dec/21143/
   trunk/src/drivers/dec/21143/21143pd.c
   trunk/src/drivers/dec/21143/Makefile.inc
   trunk/src/drivers/ti/
   trunk/src/drivers/ti/pcmcia-cardbus/
   trunk/src/drivers/ti/pcmcia-cardbus/Makefile.inc
   trunk/src/drivers/ti/pcmcia-cardbus/ti-pcmcia-cardbus.c
Modified:
   trunk/src/drivers/Kconfig
   trunk/src/drivers/Makefile.inc
   trunk/src/include/device/pci_ids.h
   trunk/src/mainboard/nokia/ip530/Kconfig
   trunk/src/mainboard/nokia/ip530/devicetree.cb
   trunk/src/mainboard/nokia/ip530/irq_tables.c
   trunk/src/mainboard/nokia/ip530/mainboard.c

Modified: trunk/src/drivers/Kconfig
==============================================================================
--- trunk/src/drivers/Kconfig	Fri Jun  4 17:55:12 2010	(r5608)
+++ trunk/src/drivers/Kconfig	Fri Jun  4 21:53:55 2010	(r5609)
@@ -23,3 +23,21 @@
 	help
 	It sets PCI class to IDE compatible native mode, allowing
 	SeaBIOS, FILO etc... to boot from it.
+
+config DRIVERS_TI
+	bool
+
+config DRIVERS_TI_PCI1225
+	select DRIVERS_TI
+	bool
+
+config DRIVERS_TI_PCI1420
+	select DRIVERS_TI
+	bool
+
+config DRIVERS_TI_PCI1520
+	select DRIVERS_TI
+	bool
+
+config DRIVERS_DEC_21143PD
+	bool

Modified: trunk/src/drivers/Makefile.inc
==============================================================================
--- trunk/src/drivers/Makefile.inc	Fri Jun  4 17:55:12 2010	(r5608)
+++ trunk/src/drivers/Makefile.inc	Fri Jun  4 21:53:55 2010	(r5609)
@@ -1,3 +1,5 @@
 subdirs-y += generic/debug
 subdirs-y += ati/ragexl
 subdirs-y += sil/3114
+subdirs-y += ti/pcmcia-cardbus
+subdirs-y += dec/21143

Added: trunk/src/drivers/dec/21143/21143pd.c
==============================================================================
--- /dev/null	00:00:00 1970	(empty, because file is newly added)
+++ trunk/src/drivers/dec/21143/21143pd.c	Fri Jun  4 21:53:55 2010	(r5609)
@@ -0,0 +1,70 @@
+/*
+ * This file is part of the coreboot project.
+ *
+ * Copyright (C) 2010 Marc Bertens <mbertens at xs4all.nl>
+ *
+ * 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; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * 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 <device/device.h>
+#include <device/pci_def.h>
+#include <device/pci.h>
+#include <device/pci_ids.h>
+#include <console/console.h>
+
+/**
+ * The following should be set in the mainboard-specific Kconfig file.
+ */
+#if (!defined(CONFIG_DEC21143_CACHE_LINE_SIZE) || \
+     !defined(CONFIG_DEC21143_EXPANSION_ROM_BASE_ADDRESS) || \
+     !defined(CONFIG_DEC21143_COMMAND_AND_STATUS_CONFIGURATION))
+#error "you must supply these values in your mainboard-specific Kconfig file"
+#endif
+
+/* CONFIG_DEC21143_CACHE_LINE_SIZE try 0x00000000 if unsure */
+/* CONFIG_DEC21143_EXPANSION_ROM_BASE_ADDRESS try 0x00000000 if unsure */
+/* CONFIG_DEC21143_COMMAND_AND_STATUS_CONFIGURATION try 0x02800107 or 0x02800007 if unsure */
+
+/**
+ * This driver take the values from Kconfig and load them in the registers
+ */
+static void dec_21143pd_enable( device_t dev )
+{
+	printk( BIOS_DEBUG, "Init of DECchip 21143PD/TD Kconfig style\n");
+	// Command and Status Configuration Register (Offset 0x04)
+	pci_write_config32( dev, 0x04, CONFIG_DEC21143_COMMAND_AND_STATUS_CONFIGURATION );
+	printk( BIOS_DEBUG, "0x04 = %08x (07 01 80 02)\n", pci_read_config32(dev, 0x04) );
+	// Cache Line Size Register (Offset 0x0C)
+	pci_write_config8( dev, 0x0C, CONFIG_DEC21143_CACHE_LINE_SIZE );
+	printk( BIOS_DEBUG, "0x0c = %08x (00 80 00 00)\n", pci_read_config32(dev, 0x0C) );
+	// Expansion ROM Base Address Register (Offset 0x30)
+	pci_write_config32( dev, 0x30, CONFIG_DEC21143_EXPANSION_ROM_BASE_ADDRESS );
+	printk( BIOS_DEBUG, "0x30 = %08x (0x00000000)\n", pci_read_config32(dev, 0x30) );
+	return;
+}
+
+static struct device_operations dec_21143pd_ops  = {
+        .read_resources   = pci_dev_read_resources,
+        .set_resources    = pci_dev_set_resources,
+        .enable_resources = pci_dev_enable_resources,
+        .init             = dec_21143pd_enable,
+        .scan_bus         = 0,
+};
+
+static const struct pci_driver dec_21143pd_driver __pci_driver = {
+        .ops    = &dec_21143pd_ops,
+        .vendor = PCI_VENDOR_ID_DEC,
+        .device = PCI_DEVICE_ID_DEC_21142,
+};

Added: trunk/src/drivers/dec/21143/Makefile.inc
==============================================================================
--- /dev/null	00:00:00 1970	(empty, because file is newly added)
+++ trunk/src/drivers/dec/21143/Makefile.inc	Fri Jun  4 21:53:55 2010	(r5609)
@@ -0,0 +1,2 @@
+driver-$(CONFIG_DRIVERS_DEC_21143PD) += 21143pd.o
+

Added: trunk/src/drivers/ti/pcmcia-cardbus/Makefile.inc
==============================================================================
--- /dev/null	00:00:00 1970	(empty, because file is newly added)
+++ trunk/src/drivers/ti/pcmcia-cardbus/Makefile.inc	Fri Jun  4 21:53:55 2010	(r5609)
@@ -0,0 +1,2 @@
+driver-$(CONFIG_DRIVERS_TI) += ti-pcmcia-cardbus.o
+

Added: trunk/src/drivers/ti/pcmcia-cardbus/ti-pcmcia-cardbus.c
==============================================================================
--- /dev/null	00:00:00 1970	(empty, because file is newly added)
+++ trunk/src/drivers/ti/pcmcia-cardbus/ti-pcmcia-cardbus.c	Fri Jun  4 21:53:55 2010	(r5609)
@@ -0,0 +1,91 @@
+/*
+ * This file is part of the coreboot project.
+ *
+ * Copyright (C) 2010 Marc Bertens <mbertens at xs4all.nl>
+ *
+ * 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; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * 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 <device/device.h>
+#include <device/pci.h>
+#include <device/pci_ids.h>
+#include <device/pci_ops.h>
+#include <console/console.h>
+
+#if (	!defined( CONFIG_TI_PCMCIA_CARDBUS_CMDR ) || \
+	!defined( CONFIG_TI_PCMCIA_CARDBUS_CLSR ) || \
+	!defined( CONFIG_TI_PCMCIA_CARDBUS_CLTR	) || \
+	!defined( CONFIG_TI_PCMCIA_CARDBUS_BCR ) || \
+	!defined( CONFIG_TI_PCMCIA_CARDBUS_SCR ) || \
+	!defined( CONFIG_TI_PCMCIA_CARDBUS_MRR ) )
+#error "you must supply these values in your mainboard-specific Kconfig file"
+#endif
+
+static void ti_pci1x2y_init(struct device *dev)
+{
+	printk(BIOS_INFO, "Init of Texas Instruments PCI1x2x PCMCIA/CardBus controller\n");
+	// Command register (offset 04)
+	pci_write_config16( dev, 0x04, CONFIG_TI_PCMCIA_CARDBUS_CMDR );
+	// Cache Line Size Register (offset 0x0C)
+	pci_write_config8( dev, 0x0C, CONFIG_TI_PCMCIA_CARDBUS_CLSR );
+	// CardBus latency timer register (offset 1B)
+	pci_write_config8( dev, 0x1B, CONFIG_TI_PCMCIA_CARDBUS_CLTR );
+	// Bridge control register (offset 3E)
+	pci_write_config16( dev, 0x3E, CONFIG_TI_PCMCIA_CARDBUS_BCR );
+	/** Enable change sub-vendor id
+	 * Clear the bit 5 to enable to write to the sub-vendor/device ids at 40 and 42 */
+	pci_write_config32( dev, 0x80, 0x10 );
+	pci_write_config32( dev, 0x40, PCI_VENDOR_ID_NOKIA );
+	// Now write the correct value for SCR
+	// System Control Register (offset 0x80)
+	pci_write_config32( dev, 0x80, CONFIG_TI_PCMCIA_CARDBUS_SCR );
+	// Multifunction routing register
+	pci_write_config32( dev, 0x8C, CONFIG_TI_PCMCIA_CARDBUS_MRR );
+	// Set Device Control Register (0x92) accordingly
+	pci_write_config8( dev, 0x92, pci_read_config8( dev, 0x92 ) | 0x02 );
+	return;
+}
+
+static struct device_operations ti_pci1x2y_ops  = {
+	.read_resources   = NULL, //pci_dev_read_resources,
+	.set_resources    = pci_dev_set_resources,
+	.enable_resources = pci_dev_enable_resources,
+	.init             = ti_pci1x2y_init,
+	.scan_bus         = 0,
+};
+
+#ifdef CONFIG_DRIVERS_TI_PCI1225
+static const struct pci_driver ti_pci1225_driver __pci_driver = {
+        .ops    = &ti_pci1x2y_ops,
+        .vendor = PCI_VENDOR_ID_TI,
+        .device = PCI_DEVICE_ID_TI_1225,
+};
+
+#endif
+#ifdef CONFIG_DRIVERS_TI_PCI1420
+static const struct pci_driver ti_pci1420_driver __pci_driver = {
+        .ops    = &ti_pci1x2y_ops,
+        .vendor = PCI_VENDOR_ID_TI,
+        .device = PCI_DEVICE_ID_TI_1420,
+};
+#endif
+#ifdef CONFIG_DRIVERS_TI_PCI1520
+static const struct pci_driver ti_pci1520_driver __pci_driver = {
+        .ops    = &ti_pci1x2y_ops,
+        .vendor = PCI_VENDOR_ID_TI,
+        .device = PCI_DEVICE_ID_TI_1420,
+};
+#endif
+
+

Modified: trunk/src/include/device/pci_ids.h
==============================================================================
--- trunk/src/include/device/pci_ids.h	Fri Jun  4 17:55:12 2010	(r5608)
+++ trunk/src/include/device/pci_ids.h	Fri Jun  4 21:53:55 2010	(r5609)
@@ -696,6 +696,7 @@
 #define PCI_DEVICE_ID_TI_4410		0xac41
 #define PCI_DEVICE_ID_TI_4451		0xac42
 #define PCI_DEVICE_ID_TI_1420		0xac51
+#define PCI_DEVICE_ID_TI_1520		0xAC55
 
 #define PCI_VENDOR_ID_SONY		0x104d
 #define PCI_DEVICE_ID_SONY_CXD3222	0x8039
@@ -1741,6 +1742,10 @@
 #define PCI_DEVICE_ID_CCD_B00C		0xb00c
 #define PCI_DEVICE_ID_CCD_B100		0xb100
 
+#define PCI_VENDOR_ID_NOKIA		0x13B8	// Nokia Telecommunications oy
+#define PCI_VENDOR_ID_NOKIA_WIRELESS	0x1603	// Nokia Wireless Communications
+#define PCI_VENDOR_ID_NOKIA_HOME	0x1622	// Nokia Home Communications
+
 #define PCI_VENDOR_ID_3WARE		0x13C1
 #define PCI_DEVICE_ID_3WARE_1000	0x1000
 

Modified: trunk/src/mainboard/nokia/ip530/Kconfig
==============================================================================
--- trunk/src/mainboard/nokia/ip530/Kconfig	Fri Jun  4 17:55:12 2010	(r5608)
+++ trunk/src/mainboard/nokia/ip530/Kconfig	Fri Jun  4 21:53:55 2010	(r5609)
@@ -24,10 +24,12 @@
 	select NORTHBRIDGE_INTEL_I440BX
 	select SOUTHBRIDGE_INTEL_I82371EB
 	select SUPERIO_SMSC_SMSCSUPERIO
+	select DRIVERS_TI_PCI1225
+	select DRIVERS_DEC_21143PD
 	select ROMCC
+	select PIRQ_ROUTE
 	select HAVE_PIRQ_TABLE
 	select UDELAY_TSC
-	select BOARD_ROMSIZE_KB_256
 
 config MAINBOARD_DIR
 	string
@@ -46,6 +48,52 @@
 
 config IRQ_SLOT_COUNT
 	int
-	default 6
+	default 22
 	depends on BOARD_NOKIA_IP530
 
+## Configuration items for the ethernet adaptors
+config DEC21143_CACHE_LINE_SIZE
+	int
+	default 0x00000000
+	depends on BOARD_NOKIA_IP530
+
+config DEC21143_EXPANSION_ROM_BASE_ADDRESS
+	hex
+	default 0x00000000
+	depends on BOARD_NOKIA_IP530
+
+config DEC21143_COMMAND_AND_STATUS_CONFIGURATION
+	hex
+	default 0x02800107
+	depends on BOARD_NOKIA_IP530
+
+## Configuration for the PCMCIA-Cardbus controller.
+config TI_PCMCIA_CARDBUS_CMDR
+	hex
+	default 0x0107
+	depends on BOARD_NOKIA_IP530
+
+config TI_PCMCIA_CARDBUS_CLSR
+	hex
+	default 0x00
+	depends on BOARD_NOKIA_IP530
+
+config TI_PCMCIA_CARDBUS_CLTR
+	hex
+	default 0x40
+	depends on BOARD_NOKIA_IP530
+
+config TI_PCMCIA_CARDBUS_BCR
+	hex
+	default 0x07C0
+	depends on BOARD_NOKIA_IP530
+
+config TI_PCMCIA_CARDBUS_SCR
+	hex
+	default 0x08449060
+	depends on BOARD_NOKIA_IP530
+
+config TI_PCMCIA_CARDBUS_MRR
+	hex
+	default 0x00007522
+	depends on BOARD_NOKIA_IP530

Modified: trunk/src/mainboard/nokia/ip530/devicetree.cb
==============================================================================
--- trunk/src/mainboard/nokia/ip530/devicetree.cb	Fri Jun  4 17:55:12 2010	(r5608)
+++ trunk/src/mainboard/nokia/ip530/devicetree.cb	Fri Jun  4 21:53:55 2010	(r5609)
@@ -30,16 +30,8 @@
     chip southbridge/intel/i82371eb	# Southbridge
       device pci 7.0 on			# ISA bridge
         chip superio/smsc/smscsuperio	# Super I/O (SMSC FDC37C878)
-          device pnp 3f0.0 on		# Floppy
-            io 0x60 = 0x3f0
-            irq 0x70 = 6
-            drq 0x74 = 2
-          end
-          device pnp 3f0.3 on		# Parallel port
-            io 0x60 = 0x378
-            irq 0x70 = 7
-            drq 0x74 = 4
-          end
+          device pnp 3f0.0 off end	# Floppy (No connector)
+          device pnp 3f0.3 off end	# Parallel port (No connector)
           device pnp 3f0.4 on		# COM1
             io 0x60 = 0x3f8
             irq 0x70 = 4
@@ -48,47 +40,23 @@
             io 0x60 = 0x2f8
             irq 0x70 = 3
           end
-          device pnp 3f0.7 on		# PS/2 keyboard / mouse
-            io 0x60 = 0x60
-            io 0x62 = 0x64
-            irq 0x70 = 1		# PS/2 keyboard interrupt
-            irq 0x72 = 12		# PS/2 mouse interrupt
-          end
-          device pnp 3f0.9 on		# Game port
-            io 0x60 = 0x201
-          end
-          device pnp 3f0.a on		# Power-management events (PME)
-            io 0x60 = 0x600
-          end
-          device pnp 3f0.b on		# MIDI port (MPU-401)
-            io 0x60 = 0x330
-            irq 0x70 = 5
-          end
+          device pnp 3f0.7 on end	# PS/2 keyboard / mouse
+          device pnp 3f0.6 on end	# RTC
+          device pnp 3f0.8 on end	# AUX I/O
+          device pnp 3f0.A off end	# ACPI (No support yet)
         end
       end
       device pci 7.1 on end		# IDE
-      device pci 7.2 on end		# USB
-      device pci 7.3 on end		# ACPI
+      device pci 7.2 off end		# USB (No connector)
+      device pci 7.3 off end		# ACPI (No support yet)
       register "ide0_enable" = "1"
       register "ide1_enable" = "1"
       register "ide_legacy_enable" = "1"
-      # Enable UDMA/33 for higher speed if your IDE device(s) support it.
-      register "ide0_drive0_udma33_enable" = "0"
-      register "ide0_drive1_udma33_enable" = "0"
-      register "ide1_drive0_udma33_enable" = "0"
-      register "ide1_drive1_udma33_enable" = "0"
+      # Disable UDMA/33 for lower speed if your IDE device(s) don't support it.
+      register "ide0_drive0_udma33_enable" = "1"
+      register "ide0_drive1_udma33_enable" = "1"
+      register "ide1_drive0_udma33_enable" = "1"
+      register "ide1_drive1_udma33_enable" = "1"
     end
-    device pci 0d.0 on end		# NIC (DEC DECchip 21142/43)
-    device pci 0e.0 on end		# NIC (DEC DECchip 21142/43)
-    device pci 0f.0 on end		# CardBus bridge (TI PCI1225)
-    device pci 0f.1 on end		# CardBus bridge (TI PCI1225)
-  end
-  device pci_domain 1 on		# PCI domain 1
-    device pci 00.0 on end		# PCI bridge (DEC DECchip 21150)
-  end
-  device pci_domain 2 on		# PCI domain 2
-    device pci 04.0 on end		# NIC (DECchip 21142/43)
-    device pci 04.0 on end		# NIC (DECchip 21142/43)
   end
 end
-

Modified: trunk/src/mainboard/nokia/ip530/irq_tables.c
==============================================================================
--- trunk/src/mainboard/nokia/ip530/irq_tables.c	Fri Jun  4 17:55:12 2010	(r5608)
+++ trunk/src/mainboard/nokia/ip530/irq_tables.c	Fri Jun  4 21:53:55 2010	(r5609)
@@ -31,15 +31,46 @@
 	0x122e,			/* Device */
 	0,			/* Miniport */
 	{ 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0 }, /* u8 rfu[11] */
-	0x36,			/* Checksum */
+	0x44,			/* Checksum */
 	{
-		/* bus,        dev | fn,   {link, bitmap}, {link, bitmap}, {link, bitmap}, {link, bitmap}, slot, rfu */
-		{0x00, (0x07 << 3) | 0x0, {{0x00, 0x0ea8}, {0x00, 0x0ea8}, {0x00, 0x0ea8}, {0x63, 0x0ea8}}, 0x0, 0x0},
-		{0x00, (0x0c << 3) | 0x0, {{0x61, 0x06a8}, {0x62, 0x06a8}, {0x00, 0x06a8}, {0x00, 0x06a8}}, 0x0, 0x0},
-		{0x00, (0x0d << 3) | 0x0, {{0x60, 0x0ea8}, {0x61, 0x0ea8}, {0x00, 0x0ea8}, {0x00, 0x0ea8}}, 0x1, 0x0},
-		{0x00, (0x09 << 3) | 0x0, {{0x62, 0x0ea8}, {0x63, 0x0ea8}, {0x60, 0x0ea8}, {0x61, 0x0ea8}}, 0x2, 0x0},
-		{0x00, (0x0a << 3) | 0x0, {{0x63, 0x0ea8}, {0x00, 0x0ea8}, {0x00, 0x0ea8}, {0x00, 0x0ea8}}, 0x0, 0x0},
-		{0x01, (0x00 << 3) | 0x0, {{0x60, 0x0ea8}, {0x00, 0x0ea8}, {0x00, 0x0ea8}, {0x00, 0x0ea8}}, 0x0, 0x0},
+		/**
+		 *	Rebuild of the PIRQ table, to fix the non-working on-board NIC and PCMCIA controller.
+		 */
+		// Southbridge 82371
+		{ 0x00, (0x07 << 3) | 0x0, {{0x00, 0x1E20}, {0x00, 0x1E20}, {0x00, 0x1E20}, {0x63, 0x1E20}}, 0x0, 0x0 },
+		// On-board PCI-to-PCI bridge
+		{ 0x01, (0x00 << 3) | 0x0, {{0x60, 0x1E20}, {0x61, 0x1E20}, {0x62, 0x1E20}, {0x63, 0x1E20}}, 0x0, 0x0 },
+		// ETH1 on front panel
+		{ 0x00, (0x0d << 3) | 0x0, {{0x62, 0x1E20}, {0x00, 0x1E20}, {0x00, 0x1E20}, {0x00, 0x1E20}}, 0x0, 0x0 },
+		// ETH2 on front panel
+		{ 0x00, (0x0e << 3) | 0x0, {{0x63, 0x1E20}, {0x00, 0x1E20}, {0x00, 0x1E20}, {0x00, 0x1E20}}, 0x0, 0x0 },
+		// ETH3 on front panel
+		{ 0x02, (0x04 << 3) | 0x0, {{0x60, 0x1E20}, {0x00, 0x1E20}, {0x00, 0x1E20}, {0x00, 0x1E20}}, 0x0, 0x0 },
+		// ETH4 on front panel
+		{ 0x02, (0x05 << 3) | 0x0, {{0x61, 0x1E20}, {0x00, 0x1E20}, {0x00, 0x1E20}, {0x00, 0x1E20}}, 0x0, 0x0 },
+		// PCMCIA/Cardbus controller
+		{ 0x00, (0x0f << 3) | 0x0, {{0x60, 0x1E20}, {0x61, 0x1E20}, {0x00, 0x1E20}, {0x00, 0x1E20}}, 0x0, 0x0 },
+		// Bridge for slot 1 (top)
+		{ 0x02, (0x07 << 3) | 0x0, {{0x61, 0x1E20}, {0x62, 0x1E20}, {0x63, 0x1E20}, {0x64, 0x1E20}}, 0x0, 0x0 },
+		// PCI compact slots 1 (top)
+		{ 0x03, (0x04 << 3) | 0x0, {{0x61, 0x1E20}, {0x62, 0x1E20}, {0x63, 0x1E20}, {0x60, 0x1E20}}, 0x1, 0x0 },
+		{ 0x03, (0x05 << 3) | 0x0, {{0x62, 0x1E20}, {0x63, 0x1E20}, {0x60, 0x1E20}, {0x61, 0x1E20}}, 0x2, 0x0 },
+		{ 0x03, (0x06 << 3) | 0x0, {{0x63, 0x1E20}, {0x60, 0x1E20}, {0x61, 0x1E20}, {0x62, 0x1E20}}, 0x3, 0x0 },
+		{ 0x03, (0x07 << 3) | 0x0, {{0x60, 0x1E20}, {0x61, 0x1E20}, {0x62, 0x1E20}, {0x63, 0x1E20}}, 0x4, 0x0 },
+		// Bridge for slot 2 (middle)
+		{ 0x02, (0x06 << 3) | 0x0, {{0x61, 0x1E20}, {0x62, 0x1E20}, {0x63, 0x1E20}, {0x60, 0x1E20}}, 0x0, 0x0 },
+		// PCI compact slots 2 (middle)
+		{ 0x04, (0x04 << 3) | 0x0, {{0x61, 0x1E20}, {0x62, 0x1E20}, {0x63, 0x1E20}, {0x60, 0x1E20}}, 0x5, 0x0 },
+		{ 0x04, (0x05 << 3) | 0x0, {{0x62, 0x1E20}, {0x63, 0x1E20}, {0x60, 0x1E20}, {0x61, 0x1E20}}, 0x6, 0x0 },
+		{ 0x04, (0x06 << 3) | 0x0, {{0x63, 0x1E20}, {0x60, 0x1E20}, {0x61, 0x1E20}, {0x62, 0x1E20}}, 0x7, 0x0 },
+		{ 0x04, (0x07 << 3) | 0x0, {{0x60, 0x1E20}, {0x61, 0x1E20}, {0x62, 0x1E20}, {0x63, 0x1E20}}, 0x8, 0x0 },
+		// Bridge for slot 3 (bottom)
+		{ 0x00, (0x10 << 3) | 0x0, {{0x61, 0x1E20}, {0x62, 0x1E20}, {0x63, 0x1E20}, {0x60, 0x1E20}}, 0x0, 0x0 },
+		// PCI compact slots 3 (bottom)
+		{ 0x05, (0x04 << 3) | 0x0, {{0x61, 0x1E20}, {0x62, 0x1E20}, {0x63, 0x1E20}, {0x60, 0x1E20}}, 0x9, 0x0 },
+		{ 0x05, (0x05 << 3) | 0x0, {{0x62, 0x1E20}, {0x63, 0x1E20}, {0x60, 0x1E20}, {0x61, 0x1E20}}, 0xA, 0x0 },
+		{ 0x05, (0x06 << 3) | 0x0, {{0x63, 0x1E20}, {0x60, 0x1E20}, {0x61, 0x1E20}, {0x62, 0x1E20}}, 0xB, 0x0 },
+		{ 0x05, (0x07 << 3) | 0x0, {{0x60, 0x1E20}, {0x61, 0x1E20}, {0x62, 0x1E20}, {0x63, 0x1E20}}, 0xC, 0x0 },
 	}
 };
 
@@ -47,3 +78,13 @@
 {
 	return copy_pirq_routing_table(addr);
 }
+
+/**
+ * TODO: This stub function is here until the point is solved in the
+ * main code of coreboot. see also arch/i386/boot/pirq_tables.c
+ */
+void pirq_assign_irqs(const unsigned char pIntAtoD[4])
+{
+	return;
+}
+

Modified: trunk/src/mainboard/nokia/ip530/mainboard.c
==============================================================================
--- trunk/src/mainboard/nokia/ip530/mainboard.c	Fri Jun  4 17:55:12 2010	(r5608)
+++ trunk/src/mainboard/nokia/ip530/mainboard.c	Fri Jun  4 21:53:55 2010	(r5609)
@@ -20,7 +20,44 @@
 
 #include <device/device.h>
 #include "chip.h"
+#include <device/pci_def.h>
+#include <device/pci.h>
+#include <arch/io.h>
+#include <device/pnp_def.h>
+#include <console/console.h>
+#define OUTB	outb
+#define INB		inb
+
+/*
+*	Taken from flashrom project
+*	Generic Super I/O helper functions
+*/
+static uint8_t sio_read(uint16_t port, uint8_t reg)
+{
+	OUTB( reg, port );
+	return ( INB( port + 1 ) );
+}
+
+static void sio_write(uint16_t port, uint8_t reg, uint8_t data)
+{
+	OUTB( reg, port );
+	OUTB( data, port + 1 );
+	return;
+}
+
+static void nokia_ip530_board_enable( device_t dev )
+{
+	print_debug( "Setting up IP530-Super I/O devices\n");
+	sio_write( 0x20, 0x03, 0x80 );
+	printk( BIOS_DEBUG, "--Register 0x03 = %X := 0x80\n", sio_read( 0x20, 0x03 ) );
+	sio_write( 0x20, 0x22, 0x30 );
+	printk( BIOS_DEBUG, "--Register 0x22 = %X := 0x30\n", sio_read( 0x20, 0x22 ) );
+	sio_write( 0x20, 0x24, 0x84 );
+	printk( BIOS_DEBUG, "--Register 0x24 = %X := 0x84\n", sio_read( 0x20, 0x24 ) );
+	return;
+}
 
 struct chip_operations mainboard_ops = {
 	CHIP_NAME("Nokia IP530 Mainboard")
+	.enable_dev = nokia_ip530_board_enable,
 };



From mylesgw at gmail.com  Fri Jun  4 21:57:18 2010
From: mylesgw at gmail.com (Myles Watson)
Date: Fri, 4 Jun 2010 13:57:18 -0600
Subject: [coreboot] Update on NOKIA-IP530
In-Reply-To: <1275679537.3803.42.camel@andrala.reboot>
References: <1275587298.3803.21.camel@andrala.reboot>
	<AANLkTikkwYfB9HHShBPnGkgjWqpe2m54t9hpqREbwlOH@mail.gmail.com>
	<AANLkTil90azgdY4b1sGlJ047eX07KEYq7zjq4YpNBog0@mail.gmail.com>
	<1275675254.3803.33.camel@andrala.reboot>
	<8812CE65242647D19DD672DCEC1C245E@chimp>
	<1275676683.3803.39.camel@andrala.reboot>
	<5FD03A5F92784807AEED3800D0762D57@chimp>
	<1275679537.3803.42.camel@andrala.reboot>
Message-ID: <49A74B61F4E049B3B90EE4E8CD84F105@chimp>


> Acked-by: Marc Bertens <mbertens at xs4all.nl>
> 
> I tested the patch at it worked fine, when i added the patch on the
> \arch\i386\boot\pirq_routing.c too :-)
Rev 5609.

Thanks for testing it.  Peter said he didn't think the ugly hack was ready
to go in, and I've never done anything with PIRQ tables.  Maybe he can help
you figure out a better long-term solution.  

Thanks,
Myles




From njacobs8 at hetnet.nl  Fri Jun  4 22:01:11 2010
From: njacobs8 at hetnet.nl (Nils)
Date: Fri, 4 Jun 2010 22:01:11 +0200
Subject: [coreboot] [PATCH] Fix geode lx VSA loading
Message-ID: <201006042201.11701.njacobs8@hetnet.nl>

Hi all,
I boot tested the last revision (by Stefan) of this patch on my Wyse S50 (GX2) 
and it seems to work nice!
So this patch is:

Acked-by: Nils Jacobs <njacobs8 at hetnet.nl>

Thanks,Nils.



From info at coresystems.de  Fri Jun  4 22:08:06 2010
From: info at coresystems.de (coreboot information)
Date: Fri, 04 Jun 2010 22:08:06 +0200
Subject: [coreboot] build service results for r5609
Message-ID: <E1OKdBW-0000iy-8y@ra.coresystems.de>

Dear coreboot readers!

This is the automatic build system of coreboot.

The developer "myles" checked in revision 5609 to
the coreboot repository. This caused the following 
changes:

Change Log:
Fixes for Nokia IP530 and associated drivers.

Signed-off-by: Marc Bertens <mbertens at xs4all.nl>
Signed-off-by: Myles Watson <mylesgw at gmail.com>
Acked-by: Marc Bertens <mbertens at xs4all.nl>


Build Log:
Compilation of nokia:ip530 has been broken
See the error log at http://qa.coreboot.org/log_buildbrd.php?revision=5609&device=ip530&vendor=nokia&num=2


If something broke during this checkin please be a pain 
in myles'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  Fri Jun  4 22:20:38 2010
From: svn at coreboot.org (repository service)
Date: Fri, 04 Jun 2010 22:20:38 +0200
Subject: [coreboot] [commit] r5610 - trunk/src/mainboard/nokia/ip530
Message-ID: <E1OKdNe-0002ll-5m@ra.coresystems.de>

Author: myles
Date: Fri Jun  4 22:20:37 2010
New Revision: 5610
URL: https://tracker.coreboot.org/trac/coreboot/changeset/5610

Log:
128KB is the default, and isn't large enough with the 30K payload for abuild.

Signed-off-by: Myles Watson <mylesgw at gmail.com>
Acked-by: Myles Watson <mylesgw at gmail.com>

Modified:
   trunk/src/mainboard/nokia/ip530/Kconfig

Modified: trunk/src/mainboard/nokia/ip530/Kconfig
==============================================================================
--- trunk/src/mainboard/nokia/ip530/Kconfig	Fri Jun  4 21:53:55 2010	(r5609)
+++ trunk/src/mainboard/nokia/ip530/Kconfig	Fri Jun  4 22:20:37 2010	(r5610)
@@ -26,6 +26,7 @@
 	select SUPERIO_SMSC_SMSCSUPERIO
 	select DRIVERS_TI_PCI1225
 	select DRIVERS_DEC_21143PD
+	select BOARD_ROMSIZE_KB_256
 	select ROMCC
 	select PIRQ_ROUTE
 	select HAVE_PIRQ_TABLE



From svn at coreboot.org  Fri Jun  4 22:24:13 2010
From: svn at coreboot.org (repository service)
Date: Fri, 04 Jun 2010 22:24:13 +0200
Subject: [coreboot] [commit] r5611 - trunk/src/mainboard/nokia/ip530
Message-ID: <E1OKdR7-0000UF-1b@ra.coresystems.de>

Author: myles
Date: Fri Jun  4 22:24:11 2010
New Revision: 5611
URL: https://tracker.coreboot.org/trac/coreboot/changeset/5611

Log:
Kconfig value is hex, not int.

Signed-off-by: Myles Watson <mylesgw at gmail.com>
Acked-by: Myles Watson <mylesgw at gmail.com>

Modified:
   trunk/src/mainboard/nokia/ip530/Kconfig

Modified: trunk/src/mainboard/nokia/ip530/Kconfig
==============================================================================
--- trunk/src/mainboard/nokia/ip530/Kconfig	Fri Jun  4 22:20:37 2010	(r5610)
+++ trunk/src/mainboard/nokia/ip530/Kconfig	Fri Jun  4 22:24:11 2010	(r5611)
@@ -54,7 +54,7 @@
 
 ## Configuration items for the ethernet adaptors
 config DEC21143_CACHE_LINE_SIZE
-	int
+	hex
 	default 0x00000000
 	depends on BOARD_NOKIA_IP530
 



From svn at coreboot.org  Fri Jun  4 22:32:12 2010
From: svn at coreboot.org (repository service)
Date: Fri, 04 Jun 2010 22:32:12 +0200
Subject: [coreboot] [commit] r5612 - trunk/src/devices/oprom
Message-ID: <E1OKdYq-0007ci-OM@ra.coresystems.de>

Author: stepan
Date: Fri Jun  4 22:32:12 2010
New Revision: 5612
URL: https://tracker.coreboot.org/trac/coreboot/changeset/5612

Log:
This patch fixes the option rom code that was buggy when it switched
segment registers before restoring register values. This was breaking
the Geode VSA, and probably would have hurt other option roms as well.

Signed-off-by: Edwin Beasant <edwin_beasant at virtensys.com>
Acked-by: Patrick Georgi <patrick.georgi at coresystems.de>
Signed-off-by: Stefan Reinauer <stepan at coresystems.de>
Acked-by: Nils Jacobs <njacobs8 at hetnet.nl>

Modified:
   trunk/src/devices/oprom/x86_asm.S

Modified: trunk/src/devices/oprom/x86_asm.S
==============================================================================
--- trunk/src/devices/oprom/x86_asm.S	Fri Jun  4 22:24:11 2010	(r5611)
+++ trunk/src/devices/oprom/x86_asm.S	Fri Jun  4 22:32:12 2010	(r5612)
@@ -141,20 +141,23 @@
 	mov	%ax, %ds
 	lidt	__realmode_idt
 
-	/* Set all segments to 0x0000, ds to 0x0040 */
-	mov	%ax, %es
-	mov	%ax, %fs
-	mov	%ax, %gs
-	mov	$0x40, %ax
-	mov	%ax, %ds
-
 	/* initialize registers for option rom lcall */
 	movl	__registers +  0, %eax
 	movl	__registers +  4, %ebx
 	movl	__registers +  8, %ecx
 	movl	__registers + 12, %edx
 	movl	__registers + 16, %esi
-	movl	__registers + 20, %edi
+	movl	__registers + 20, %edi	
+
+	/* Set all segments to 0x0000, ds to 0x0040 */
+	push	%ax
+	xor	%ax, %ax
+	mov	%ax, %es
+	mov	%ax, %fs
+	mov	%ax, %gs
+	mov	$0x40, %ax
+	mov	%ax, %ds
+	pop	%ax
 
 	/* ************************************ */
 __lcall_instr = RELOCATED(.)
@@ -262,12 +265,6 @@
 	mov	%ax, %ds
 	lidt	__realmode_idt
 
-	/* Set all segments to 0x0000 */
-	mov	%ax, %ds
-	mov	%ax, %es
-	mov	%ax, %fs
-	mov	%ax, %gs
-
 	/* initialize registers for intXX call */
 	movl	__registers +  0, %eax
 	movl	__registers +  4, %ebx
@@ -276,6 +273,15 @@
 	movl	__registers + 16, %esi
 	movl	__registers + 20, %edi
 
+	/* Set all segments to 0x0000 */
+	push	%ax
+	xor	%ax, %ax
+	mov	%ax, %ds
+	mov	%ax, %es
+	mov	%ax, %fs
+	mov	%ax, %gs
+	pop	%ax
+
 __intXX_instr = RELOCATED(.)
 	.byte 0xcd, 0x00 /* This becomes intXX */
 
@@ -376,7 +382,7 @@
 	mov	%ax, %ds
 	lidt	__realmode_idt
 
-	/* Set up segment registers to segment 0x0000 */
+	/* Set up segment registers to segment 0x0000 and ds to 0x040 */
 	mov	%ax, %es
 	mov	%ax, %fs
 	mov	%ax, %gs



From info at coresystems.de  Fri Jun  4 22:35:28 2010
From: info at coresystems.de (coreboot information)
Date: Fri, 04 Jun 2010 22:35:28 +0200
Subject: [coreboot] build service results for r5610
Message-ID: <E1OKdc0-00064g-GP@ra.coresystems.de>

Dear coreboot readers!

This is the automatic build system of coreboot.

The developer "myles" checked in revision 5610 to
the coreboot repository. This caused the following 
changes:

Change Log:
128KB is the default, and isn't large enough with the 30K payload for abuild.

Signed-off-by: Myles Watson <mylesgw at gmail.com>
Acked-by: Myles Watson <mylesgw at gmail.com>


Build Log:
Compilation of nokia:ip530 has been fixed


If something broke during this checkin please be a pain 
in myles'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 stepan at coresystems.de  Fri Jun  4 22:44:02 2010
From: stepan at coresystems.de (Stefan Reinauer)
Date: Fri, 04 Jun 2010 22:44:02 +0200
Subject: [coreboot] [PATCH] cosmetical oprom update
Message-ID: <4C096592.2020500@coresystems.de>

See patch
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20100604/9866ca6f/attachment.html>
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: oprom.diff
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20100604/9866ca6f/attachment.ksh>

From jwangzju at gmail.com  Fri Jun  4 22:55:33 2010
From: jwangzju at gmail.com (Jiang Wang)
Date: Fri, 4 Jun 2010 16:55:33 -0400
Subject: [coreboot] ASUS M4A77TD-PRO. First step: buy spare flash
	chips...
In-Reply-To: <20100603223635.GA4587@ideafix.casa.ct>
References: <20100603223635.GA4587@ideafix.casa.ct>
Message-ID: <AANLkTimrq2bvzd_t0S_tT5i6Y5Inb76n5Z874IwHAvf8@mail.gmail.com>

Hi:

I am interested in this motherboard for BIOS developing too. I think
this board has a flash chip that you can plug out manually (without
soldering) right?
Where did you buy it? Form on-line or a local store? I am in the USA.
Also, is this board supported by coreboot? I checked the coreboot wiki
but cannot find it. Thanks a lot.

Regards,

Jiang

On Thu, Jun 3, 2010 at 6:36 PM, xdrudis <xdrudis at tinet.cat> wrote:
> Hello.
>
> I finally bought the hardware I told you and installed gnewsense 3 with a
> custom linux-libre 2.6.34 :
> mainboard Asus M4A77TD-PRO
> http://www.asus.com/product.aspx?P_ID=0AvsBb7WBZe2i9zK
> CPU AMD Phenom X4 910e stepping c3
> AMD 770
> AMD SB710
> RAM 2 x 4Gb dual channel non-ECC G.Skill DDR3-1333 PC3 10666 F3-10666CL9D-8GBRL
> superio ITE ?IT8712F (clearly marked on the chip and detected)
> lan: RTL8112L
> audio VIA VT1708S
>
> I've put a graphics card by MSI, Nvidia GeForce 8400GS passively cooled (no fan) on the PCIExpress 2.0 slot.
>
> I'll attachs the lspci and superiotool r3125 outputs (versions from gNewSense)
> and flashrom 0.9.2 downloaded and compiled from release tarball.
>
> Btw. The readme in flashrom 0.9.2 says to use make DESTDIR=/usr install
> if you don't want it in /usr/local, but this will install it in /usr/usr/local/sbin. To have it in /usr/sbin you need to run makePREFIX=/usr install.
> It's slightly confusing for me, I've had to look at the Makefile.
>
> Now, the first thing I want to do is to buy spare flash chips.
> But I'm not sure what chips or where to buy them.
>
> It's a socket with an eight pin chip (DIP-8?)
> (4 pins per side), roughly 5mm x 9mm
> I'd say it's by Macronix (and flashrom agrees). But I doubt about
> the specific model. The motherboard manual says "8Mb Flash ROM".
>
> The letters on the chip are very small and there's some marking over them
> that keeps me from reading them all .
> I'll copy here what I can read (i mark the most dubious letters with ?).
> (top left is a logo MX)
>
> - ? - - ? -
> -- -- ?- -
> = v = ?= = ? ?b09?714
> = ? = = ? =
>
> 25L5???5PC-15G
> ? 3C153600
> ? ?TAIWAN
>
> Looking at catalogues from macronix I think 25L is the
> family (SPI serial flash) 5?? should be the size (I'm not
> sure how many digits are there, not even 100% sure it's a 5)
> ?5 would be normal, write protected, duplex,etc.
> PC might be the process ( xx micrometers), -15 would be
> frequency of 66 Mhz and G something about lead free or environmental
> regulations.
>
> but flashrom says its a Macronix MX25L8005 .
> http://www.macronix.com/QuickPlace/hq/PageLibrary4825740B00298A3B.nsf/h_Index/6F878CF760C559BD482576E00022E6CC/?OpenDocument&EPN=MX25L8005
>
> Now, the question is should I buy some ?MX25L8005 ? (apparently its
> end of life is 2010-11-30, so it should be available, but where in
> small quantities ? )
>
> According to
> http://www.macronix.com/QuickPlace/hq/PageLibrary4825740B00298A3B.nsf/h_Index/430AA5580EA1C72E482576BE0004AF37/$File/PCN-10-035-B.pdf
> maybe I could try
> Mx25L8006EPI-12G
>
> Where do you get your spare EEPROMs ?
>
> Thank you.
>
> --
> coreboot mailing list: coreboot at coreboot.org
> http://www.coreboot.org/mailman/listinfo/coreboot
>



From njacobs8 at hetnet.nl  Sat Jun  5 00:36:14 2010
From: njacobs8 at hetnet.nl (Nils)
Date: Sat, 5 Jun 2010 00:36:14 +0200
Subject: [coreboot] [PATCH] cosmetical oprom update
Message-ID: <201006050036.14339.njacobs8@hetnet.nl>

Hi Stefan,

You wrote:
>See patch
>-------------- next part --------------
>An HTML attachment was scrubbed...
>URL: 
><http://www.coreboot.org/pipermail/coreboot/attachments/20100604/9866ca6f/attachment.html>
>-------------- next part --------------
>An embedded and charset-unspecified text was scrubbed...
>Name: oprom.diff
>URL: 
><http://www.coreboot.org/pipermail/coreboot/attachments/20100604/9866ca6f/attachment.ksh>

I boot tested the patch on my Wyse S50 (GX2) 
and it seems to work nice!
So this patch is:

Acked-by: Nils Jacobs <njacobs8 at hetnet.nl>

Thanks,Nils.



From wangqingpei at gmail.com  Sat Jun  5 03:00:08 2010
From: wangqingpei at gmail.com (Qing Pei Wang)
Date: Sat, 5 Jun 2010 09:00:08 +0800
Subject: [coreboot] ASUS M4A77TD-PRO. First step: buy spare flash
	chips...
In-Reply-To: <AANLkTimrq2bvzd_t0S_tT5i6Y5Inb76n5Z874IwHAvf8@mail.gmail.com>
References: <20100603223635.GA4587@ideafix.casa.ct>
	<AANLkTimrq2bvzd_t0S_tT5i6Y5Inb76n5Z874IwHAvf8@mail.gmail.com>
Message-ID: <AANLkTimZWfUM9MARVlL388jZHCXs34dHgs0euqeP_zxH@mail.gmail.com>

hi jiang,
  it is impossible to make the developers to port all of the
mainboard.Actually,
we take things as different chipset/cpu. If you found that the
chipset/cpu/superio of
one mainboard has already been supported, you can take a try to use
coreboot.

On Sat, Jun 5, 2010 at 4:55 AM, Jiang Wang <jwangzju at gmail.com> wrote:

> Hi:
>
> I am interested in this motherboard for BIOS developing too. I think
> this board has a flash chip that you can plug out manually (without
> soldering) right?
> Where did you buy it? Form on-line or a local store? I am in the USA.
> Also, is this board supported by coreboot? I checked the coreboot wiki
> but cannot find it. Thanks a lot.
>
> Regards,
>
> Jiang
>
> On Thu, Jun 3, 2010 at 6:36 PM, xdrudis <xdrudis at tinet.cat> wrote:
> > Hello.
> >
> > I finally bought the hardware I told you and installed gnewsense 3 with a
> > custom linux-libre 2.6.34 :
> > mainboard Asus M4A77TD-PRO
> > http://www.asus.com/product.aspx?P_ID=0AvsBb7WBZe2i9zK
> > CPU AMD Phenom X4 910e stepping c3
> > AMD 770
> > AMD SB710
> > RAM 2 x 4Gb dual channel non-ECC G.Skill DDR3-1333 PC3 10666
> F3-10666CL9D-8GBRL
> > superio ITE  IT8712F (clearly marked on the chip and detected)
> > lan: RTL8112L
> > audio VIA VT1708S
> >
> > I've put a graphics card by MSI, Nvidia GeForce 8400GS passively cooled
> (no fan) on the PCIExpress 2.0 slot.
> >
> > I'll attachs the lspci and superiotool r3125 outputs (versions from
> gNewSense)
> > and flashrom 0.9.2 downloaded and compiled from release tarball.
> >
> > Btw. The readme in flashrom 0.9.2 says to use make DESTDIR=/usr install
> > if you don't want it in /usr/local, but this will install it in
> /usr/usr/local/sbin. To have it in /usr/sbin you need to run makePREFIX=/usr
> install.
> > It's slightly confusing for me, I've had to look at the Makefile.
> >
> > Now, the first thing I want to do is to buy spare flash chips.
> > But I'm not sure what chips or where to buy them.
> >
> > It's a socket with an eight pin chip (DIP-8?)
> > (4 pins per side), roughly 5mm x 9mm
> > I'd say it's by Macronix (and flashrom agrees). But I doubt about
> > the specific model. The motherboard manual says "8Mb Flash ROM".
> >
> > The letters on the chip are very small and there's some marking over them
> > that keeps me from reading them all .
> > I'll copy here what I can read (i mark the most dubious letters with ?).
> > (top left is a logo MX)
> >
> > -   - -   -
> > -- --  - -
> > = v =  = =    b09?714
> > =   = =   =
> >
> > 25L5???5PC-15G
> >   3C153600
> >    TAIWAN
> >
> > Looking at catalogues from macronix I think 25L is the
> > family (SPI serial flash) 5?? should be the size (I'm not
> > sure how many digits are there, not even 100% sure it's a 5)
> > ?5 would be normal, write protected, duplex,etc.
> > PC might be the process ( xx micrometers), -15 would be
> > frequency of 66 Mhz and G something about lead free or environmental
> > regulations.
> >
> > but flashrom says its a Macronix MX25L8005 .
> >
> http://www.macronix.com/QuickPlace/hq/PageLibrary4825740B00298A3B.nsf/h_Index/6F878CF760C559BD482576E00022E6CC/?OpenDocument&EPN=MX25L8005
> >
> > Now, the question is should I buy some  MX25L8005 ? (apparently its
> > end of life is 2010-11-30, so it should be available, but where in
> > small quantities ? )
> >
> > According to
> >
> http://www.macronix.com/QuickPlace/hq/PageLibrary4825740B00298A3B.nsf/h_Index/430AA5580EA1C72E482576BE0004AF37/$File/PCN-10-035-B.pdf
> > maybe I could try
> > Mx25L8006EPI-12G
> >
> > Where do you get your spare EEPROMs ?
> >
> > Thank you.
> >
> > --
> > coreboot mailing list: coreboot at coreboot.org
> > http://www.coreboot.org/mailman/listinfo/coreboot
> >
>
> --
> coreboot mailing list: coreboot at coreboot.org
> http://www.coreboot.org/mailman/listinfo/coreboot
>



-- 
Wang Qing Pei
MSN:wangqingpei at hotmail.com <MSN%3Awangqingpei at hotmail.com>
Gmail:wangqingpei at gmail.com <Gmail%3Awangqingpei at gmail.com>
Phone:86+13426369984
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20100605/6afff1c7/attachment.html>

From tiagomnm at gmail.com  Sat Jun  5 05:15:20 2010
From: tiagomnm at gmail.com (Tiago Marques)
Date: Sat, 5 Jun 2010 04:15:20 +0100
Subject: [coreboot] SIS630ET coreboot challenge
In-Reply-To: <4C030C99.8090107@coresystems.de>
References: <AANLkTikFxOKoGfkTAE0vdSpGLHAqZtso0bKKpccs5Dsi@mail.gmail.com> 
	<4BFADBE1.8020007@coresystems.de>
	<AANLkTikBCEbCJiU9-UWEow6oz1QICeqHNSXS7hfqRaQK@mail.gmail.com> 
	<4C030C99.8090107@coresystems.de>
Message-ID: <AANLkTinP8T-89w2dgngDyhgjYVXVowlKBiHz_rRnlhms@mail.gmail.com>

See the attachment, doesn't look like something from a company that's alive
and kicking. I know them since the SiS 730.
Last time I heard they had some design win for a Core 2 chipset that I
haven't seen in any product and started selling SiS branded SO-DIMMS :|

Best regards,
Tiago

On Mon, May 31, 2010 at 2:10 AM, Stefan Reinauer <
stefan.reinauer at coresystems.de> wrote:

>  On 5/31/10 2:38 AM, Tiago Marques wrote:
>
> SiS is mostly dead nowadays.  Might be hard, no?
>
> Looks very much alive ...?
>
> http://www.sis.com/contact/contact.htm
>
> Stefan
>
>
>  Tiago
>
> On Mon, May 24, 2010 at 9:04 PM, Stefan Reinauer <
> stefan.reinauer at coresystems.de> wrote:
>
>> On 5/24/10 8:38 PM, Keith Hui wrote:
>> > To be legally safe, I
>> > would like one person/team to reverse the factory BIOS of a number of
>> > 630ET boards, then produce a documentation.
>> >
>>  It might be easier to contact SiS for documentation. Did you try?
>>
>> 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
>>
>>
>> --
>>  coreboot mailing list: coreboot at coreboot.org
>> http://www.coreboot.org/mailman/listinfo/coreboot
>>
>
>
>
> --
> 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 --------------
An HTML attachment was scrubbed...
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20100605/aa9c02a0/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: sis.png
Type: image/png
Size: 65645 bytes
Desc: not available
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20100605/aa9c02a0/attachment.png>

From peter at stuge.se  Sat Jun  5 05:30:07 2010
From: peter at stuge.se (Peter Stuge)
Date: Sat, 5 Jun 2010 05:30:07 +0200
Subject: [coreboot] SIS630ET coreboot challenge
In-Reply-To: <AANLkTinP8T-89w2dgngDyhgjYVXVowlKBiHz_rRnlhms@mail.gmail.com>
References: <AANLkTikFxOKoGfkTAE0vdSpGLHAqZtso0bKKpccs5Dsi@mail.gmail.com>
	<4BFADBE1.8020007@coresystems.de>
	<AANLkTikBCEbCJiU9-UWEow6oz1QICeqHNSXS7hfqRaQK@mail.gmail.com>
	<4C030C99.8090107@coresystems.de>
	<AANLkTinP8T-89w2dgngDyhgjYVXVowlKBiHz_rRnlhms@mail.gmail.com>
Message-ID: <20100605033007.29360.qmail@stuge.se>

Tiago Marques wrote:
> doesn't look like something from a company that's alive and
> kicking.

They were doing fine last year, but no longer have focus on the
chipset market.


//Peter



From mbertens at xs4all.nl  Sat Jun  5 08:04:01 2010
From: mbertens at xs4all.nl (mbertens)
Date: Sat, 05 Jun 2010 08:04:01 +0200
Subject: [coreboot] Update on NOKIA-IP530
In-Reply-To: <49A74B61F4E049B3B90EE4E8CD84F105@chimp>
References: <1275587298.3803.21.camel@andrala.reboot>
	<AANLkTikkwYfB9HHShBPnGkgjWqpe2m54t9hpqREbwlOH@mail.gmail.com>
	<AANLkTil90azgdY4b1sGlJ047eX07KEYq7zjq4YpNBog0@mail.gmail.com>
	<1275675254.3803.33.camel@andrala.reboot>
	<8812CE65242647D19DD672DCEC1C245E@chimp>
	<1275676683.3803.39.camel@andrala.reboot>
	<5FD03A5F92784807AEED3800D0762D57@chimp>
	<1275679537.3803.42.camel@andrala.reboot>
	<49A74B61F4E049B3B90EE4E8CD84F105@chimp>
Message-ID: <1275717841.3803.47.camel@andrala.reboot>

On Fri, 2010-06-04 at 13:57 -0600, Myles Watson wrote:
> > Acked-by: Marc Bertens <mbertens at xs4all.nl>
> > 
> > I tested the patch at it worked fine, when i added the patch on the
> > \arch\i386\boot\pirq_routing.c too :-)
> Rev 5609.
Great
> 
> Thanks for testing it.  Peter said he didn't think the ugly hack was ready
> to go in, and I've never done anything with PIRQ tables.  Maybe he can help
> you figure out a better long-term solution.  
Yeah, its an ugly hack, my problem at this time is de unfamiliarty with
that part of the code and the impact on all other configurations. But i
will investigate how that code works and see if i can make a proposition
for it...
> 
> Thanks,
> Myles
> 


Marc




From mbertens at xs4all.nl  Sat Jun  5 08:20:55 2010
From: mbertens at xs4all.nl (mbertens)
Date: Sat, 05 Jun 2010 08:20:55 +0200
Subject: [coreboot] build service results for r5609
In-Reply-To: <E1OKdBW-0000iy-8y@ra.coresystems.de>
References: <E1OKdBW-0000iy-8y@ra.coresystems.de>
Message-ID: <1275718855.3803.51.camel@andrala.reboot>

On Fri, 2010-06-04 at 22:08 +0200, coreboot information wrote:
> Dear coreboot readers!
> 
> This is the automatic build system of coreboot.
> 
> The developer "myles" checked in revision 5609 to
> the coreboot repository. This caused the following 
> changes:
> 
> Change Log:
> Fixes for Nokia IP530 and associated drivers.
> 
> Signed-off-by: Marc Bertens <mbertens at xs4all.nl>
> Signed-off-by: Myles Watson <mylesgw at gmail.com>
> Acked-by: Marc Bertens <mbertens at xs4all.nl>
> 
> 
> Build Log:
> Compilation of nokia:ip530 has been broken
> See the error log at http://qa.coreboot.org/log_buildbrd.php?revision=5609&device=ip530&vendor=nokia&num=2
> 
The warning are due renaming those variables, when it got into SVN .

mbertens at andrala:~/src/coreboot$ make menuconfig
.config:197:warning: trying to assign nonexistent symbol PCI1225
.config:198:warning: trying to assign nonexistent symbol PCI1420
.config:199:warning: trying to assign nonexistent symbol PCI1520
.config:200:warning: trying to assign nonexistent symbol
DRIVERS_DEC21143PD
#
# configuration written to .config
#


*** End of coreboot configuration.
*** Execute 'make' to build or try 'make help'.

mbertens at andrala:~/src/coreboot$ make clean
mbertens at andrala:~/src/coreboot$ make
    GEN        build.h
    ROMCC      romstage.inc
    GEN        crt0.S
    CC         mainboard/nokia/ip530/crt0.s
    CC         mainboard/nokia/ip530/crt0.initobj.o
    CC         lib/uart8250.initobj.o
    CC         lib/memset.initobj.o
    CC         lib/memcpy.initobj.o
    CC         lib/memcmp.initobj.o
    CC         lib/cbfs.initobj.o
    CC         lib/lzma.initobj.o
    CC         console/vtxprintf.initobj.o
    CC         arch/i386/lib/printk_init.initobj.o
    CC         arch/i386/lib/cbfs_and_run.initobj.o
    LINK       coreboot
    OBJCOPY    coreboot.bootblock
    CC         arch/i386/lib/c_start.o
    CC         console/uart8250_console.driver.o
    CC         console/vga_console.driver.o
    CC         drivers/ti/pcmcia-cardbus/ti-pcmcia-cardbus.driver.o
    CC         drivers/dec/21143/21143pd.driver.o
    CC         southbridge/intel/i82371eb/i82371eb.driver.o
    CC         southbridge/intel/i82371eb/i82371eb_isa.driver.o
    CC         southbridge/intel/i82371eb/i82371eb_ide.driver.o
    CC         southbridge/intel/i82371eb/i82371eb_usb.driver.o
    CC         southbridge/intel/i82371eb/i82371eb_smbus.driver.o
    CC         southbridge/intel/i82371eb/i82371eb_reset.driver.o
    CC         northbridge/intel/i440bx/northbridge.driver.o
    CC         cpu/intel/model_6xx/model_6xx_init.driver.o
    SCONFIG    mainboard/nokia/ip530/devicetree.cb
    CC         mainboard/nokia/ip530/static.o
    CC         mainboard/nokia/ip530/mainboard.o
    CC         mainboard/nokia/ip530/irq_tables.o
    CC         lib/clog2.o
    CC         lib/uart8250.o
    CC         lib/memset.o
    CC         lib/memcpy.o
    CC         lib/memcmp.o
    CC         lib/memmove.o
    CC         lib/malloc.o
    CC         lib/delay.o
    CC         lib/fallback_boot.o
    CC         lib/compute_ip_checksum.o
    CC         lib/version.o
    CC         lib/cbfs.o
    CC         lib/lzma.o
    CC         lib/gcc.o
    CC         lib/cbmem.o
    CC         boot/hardwaremain.o
    CC         boot/selfboot.o
    CC         console/printk.o
    CC         console/console.o
    CC         console/vtxprintf.o
    CC         console/vsprintf.o
    CC         devices/device.o
    CC         devices/root_device.o
    CC         devices/device_util.o
    CC         devices/pci_device.o
    CC         devices/pcix_device.o
    CC         devices/pciexp_device.o
    CC         devices/agp_device.o
    CC         devices/cardbus_device.o
    CC         devices/pnp_device.o
    CC         devices/pci_ops.o
    CC         devices/smbus_ops.o
    CC         devices/pci_rom.o
    CC         pc80/mc146818rtc.o
    CC         pc80/isa-dma.o
    CC         pc80/i8259.o
    CC         pc80/keyboard.o
    CC         arch/i386/boot/boot.o
    CC         arch/i386/boot/coreboot_table.o
    CC         arch/i386/boot/multiboot.o
    CC         arch/i386/boot/gdt.o
    CC         arch/i386/boot/tables.o
    CC         arch/i386/boot/pirq_routing.o
    CC         arch/i386/lib/cpu.o
    CC         arch/i386/lib/pci_ops_conf1.o
    CC         arch/i386/lib/pci_ops_conf2.o
    CC         arch/i386/lib/pci_ops_mmconf.o
    CC         arch/i386/lib/pci_ops_auto.o
    CC         arch/i386/lib/exception.o
    CC         arch/i386/lib/ioapic.o
    CC         devices/oprom/x86.o
    CC         devices/oprom/x86_asm.o
    CC         devices/oprom/x86_interrupts.o
    CC         pc80/vga/vga_io.o
    CC         cpu/intel/socket_PGA370/socket_PGA370.o
    CC         superio/smsc/smscsuperio/superio.o
    CC         cpu/x86/tsc/delay_tsc.o
    CC         cpu/x86/mtrr/mtrr.o
    CC         cpu/x86/lapic/lapic.o
    CC         cpu/x86/lapic/lapic_cpu_init.o
    CC         cpu/x86/lapic/secondary.o
    CC         cpu/x86/cache/cache.o
    CC         cpu/intel/microcode/microcode.o
    AR         coreboot.a
    CC         coreboot_ram.o
    CC         coreboot_ram
    CBFS       coreboot.rom
    PAYLOAD    ../seabios/out/bios.bin.elf (compression: LZMA)
    CBFSPRINT  coreboot.rom

coreboot.rom: 512 kB, bootblocksize 65536, romsize 524288, offset 0x0
Alignment: 64 bytes

Name                           Offset     Type         Size
fallback/coreboot_ram          0x0        stage        40192
fallback/payload               0x9d40     payload      41248
(empty)                        0x13ec0    null         377080
mbertens at andrala:~/src/coreboot$ 

Nothing broke here it just compiles fine, and the code runs on the
Nokia.


> 
> If something broke during this checkin please be a pain 
> in myles'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 stefan.reinauer at coresystems.de  Sat Jun  5 10:32:14 2010
From: stefan.reinauer at coresystems.de (Stefan Reinauer)
Date: Sat, 05 Jun 2010 10:32:14 +0200
Subject: [coreboot] SIS630ET coreboot challenge
In-Reply-To: <AANLkTinP8T-89w2dgngDyhgjYVXVowlKBiHz_rRnlhms@mail.gmail.com>
References: <AANLkTikFxOKoGfkTAE0vdSpGLHAqZtso0bKKpccs5Dsi@mail.gmail.com>
	<4BFADBE1.8020007@coresystems.de>	<AANLkTikBCEbCJiU9-UWEow6oz1QICeqHNSXS7hfqRaQK@mail.gmail.com>
	<4C030C99.8090107@coresystems.de>
	<AANLkTinP8T-89w2dgngDyhgjYVXVowlKBiHz_rRnlhms@mail.gmail.com>
Message-ID: <4C0A0B8E.2040809@coresystems.de>

On 6/5/10 5:15 AM, Tiago Marques wrote:
> See the attachment, doesn't look like something from a company that's
> alive and kicking. I know them since the SiS 730.
> Last time I heard they had some design win for a Core 2 chipset that I
> haven't seen in any product and started selling SiS branded SO-DIMMS :|
>
So you did contact them for data sheets?



From svn at coreboot.org  Sat Jun  5 11:52:37 2010
From: svn at coreboot.org (repository service)
Date: Sat, 05 Jun 2010 11:52:37 +0200
Subject: [coreboot] [commit] r5613 - trunk/src/devices/oprom
Message-ID: <E1OKq3R-0001OZ-VK@ra.coresystems.de>

Author: stepan
Date: Sat Jun  5 11:52:37 2010
New Revision: 5613
URL: https://tracker.coreboot.org/trac/coreboot/changeset/5613

Log:
tly cosmetical. don't use movw because we use mov in most places.
Also, drop some dead code at the very end where some segment registers
get set up and are immediately overwritten by pops.

Signed-off-by: Stefan Reinauer <stepan at coresystems.de>
Acked-by: Nils Jacobs <njacobs8 at hetnet.nl>

Modified:
   trunk/src/devices/oprom/x86_asm.S

Modified: trunk/src/devices/oprom/x86_asm.S
==============================================================================
--- trunk/src/devices/oprom/x86_asm.S	Fri Jun  4 22:32:12 2010	(r5612)
+++ trunk/src/devices/oprom/x86_asm.S	Sat Jun  5 11:52:37 2010	(r5613)
@@ -82,10 +82,10 @@
 
 	/* entry point */
 	movl    36(%ebp), %eax
-	movw	%ax, __lcall_instr + 1
+	mov	%ax, __lcall_instr + 1
 	andl	$0xffff0000, %eax
 	shrl	$4, %eax
-	movw	%ax, __lcall_instr + 3
+	mov	%ax, __lcall_instr + 3
 
 	/* initial register values */
 	movl	40(%ebp), %eax
@@ -147,7 +147,7 @@
 	movl	__registers +  8, %ecx
 	movl	__registers + 12, %edx
 	movl	__registers + 16, %esi
-	movl	__registers + 20, %edi	
+	movl	__registers + 20, %edi
 
 	/* Set all segments to 0x0000, ds to 0x0040 */
 	push	%ax
@@ -165,8 +165,8 @@
 	.word 0x0000, 0x0000
 	/* ************************************ */
 
-	/* If we got here, just about done.
-	 * Need to get back to protected mode
+	/* If we got here, we are just about done.
+	 * Need to get back to protected mode.
 	 */
 	movl	%cr0, %eax
 	orl	$PE, %eax
@@ -178,7 +178,7 @@
 	data32	ljmp	$0x10, $RELOCATED(1f)
 1:
 	.code32
-	movw	$0x18, %ax
+	mov	$0x18, %ax
 	mov	%ax, %ds
 	mov	%ax, %es
 	mov	%ax, %fs
@@ -294,7 +294,7 @@
 	data32	ljmp	$0x10, $RELOCATED(1f)
 1:
 	.code32
-	movw	$0x18, %ax
+	mov	$0x18, %ax
 	mov	%ax, %ds
 	mov	%ax, %es
 	mov	%ax, %fs
@@ -337,7 +337,7 @@
 	data32 ljmp    $0x10, $RELOCATED(1f)
 1:
 	.code32
-	movw	$0x18, %ax
+	mov	$0x18, %ax
 	mov	%ax, %ds
 	mov	%ax, %es
 	mov	%ax, %fs
@@ -382,13 +382,6 @@
 	mov	%ax, %ds
 	lidt	__realmode_idt
 
-	/* Set up segment registers to segment 0x0000 and ds to 0x040 */
-	mov	%ax, %es
-	mov	%ax, %fs
-	mov	%ax, %gs
-	mov	$0x40, %ax
-	mov	%ax, %ds
-
 	/* Restore all registers, including those
 	 * manipulated by the C handler
 	 */



From svn at coreboot.org  Sat Jun  5 12:03:10 2010
From: svn at coreboot.org (repository service)
Date: Sat, 05 Jun 2010 12:03:10 +0200
Subject: [coreboot] [commit] r5614 - in trunk/src: . mainboard/getac/p470
	mainboard/ibase/mb899 mainboard/intel/d945gclf
	mainboard/kontron/986lcd-m mainboard/roda/rk886ex
	southbridge/intel/i82801gx
Message-ID: <E1OKqDe-0005wS-0b@ra.coresystems.de>

Author: stepan
Date: Sat Jun  5 12:03:08 2010
New Revision: 5614
URL: https://tracker.coreboot.org/trac/coreboot/changeset/5614

Log:
Fix two warnings:

108 src/arch/i386/include/arch/acpi.h:402:5: warning: "CONFIG_HAVE_ACPI_SLIC" is not defined
  1 src/mainboard/getac/p470/mainboard.c:83: warning: assignment discards qualifiers from pointer target type

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

Modified:
   trunk/src/Kconfig
   trunk/src/mainboard/getac/p470/Kconfig
   trunk/src/mainboard/getac/p470/hda_verb.h
   trunk/src/mainboard/ibase/mb899/Kconfig
   trunk/src/mainboard/intel/d945gclf/Kconfig
   trunk/src/mainboard/kontron/986lcd-m/Kconfig
   trunk/src/mainboard/roda/rk886ex/Kconfig
   trunk/src/southbridge/intel/i82801gx/i82801gx_azalia.c

Modified: trunk/src/Kconfig
==============================================================================
--- trunk/src/Kconfig	Sat Jun  5 11:52:37 2010	(r5613)
+++ trunk/src/Kconfig	Sat Jun  5 12:03:08 2010	(r5614)
@@ -164,6 +164,10 @@
 	bool
 	default n
 
+config HAVE_ACPI_SLIC
+	bool
+	default n
+
 config ACPI_SSDTX_NUM
 	int
 	default 0

Modified: trunk/src/mainboard/getac/p470/Kconfig
==============================================================================
--- trunk/src/mainboard/getac/p470/Kconfig	Sat Jun  5 11:52:37 2010	(r5613)
+++ trunk/src/mainboard/getac/p470/Kconfig	Sat Jun  5 12:03:08 2010	(r5614)
@@ -33,6 +33,7 @@
 	select GENERATE_MP_TABLE
 	select HAVE_HARD_RESET
 	select HAVE_ACPI_RESUME
+	select HAVE_ACPI_SLIC
 	select HAVE_MAINBOARD_RESOURCES
 	select MMCONF_SUPPORT
 	select USE_PRINTK_IN_CAR
@@ -89,8 +90,3 @@
 	default "getac-pci8086,27a2.rom"
 	depends on BOARD_GETAC_P470
 
-config HAVE_ACPI_SLIC
-	bool
-	default y
-	depends on BOARD_GETAC_P470
-

Modified: trunk/src/mainboard/getac/p470/hda_verb.h
==============================================================================
--- trunk/src/mainboard/getac/p470/hda_verb.h	Sat Jun  5 11:52:37 2010	(r5613)
+++ trunk/src/mainboard/getac/p470/hda_verb.h	Sat Jun  5 12:03:08 2010	(r5614)
@@ -95,6 +95,6 @@
 	0x01F71F41,
 };
 
-extern u32 * cim_verb_data;
+extern const u32 * cim_verb_data;
 extern u32 cim_verb_data_size;
 

Modified: trunk/src/mainboard/ibase/mb899/Kconfig
==============================================================================
--- trunk/src/mainboard/ibase/mb899/Kconfig	Sat Jun  5 11:52:37 2010	(r5613)
+++ trunk/src/mainboard/ibase/mb899/Kconfig	Sat Jun  5 12:03:08 2010	(r5614)
@@ -66,8 +66,3 @@
 	default "amipci_01.20"
 	depends on BOARD_IBASE_MB899
 
-config HAVE_ACPI_SLIC
-	bool
-	default n
-	depends on BOARD_IBASE_MB899
-

Modified: trunk/src/mainboard/intel/d945gclf/Kconfig
==============================================================================
--- trunk/src/mainboard/intel/d945gclf/Kconfig	Sat Jun  5 11:52:37 2010	(r5613)
+++ trunk/src/mainboard/intel/d945gclf/Kconfig	Sat Jun  5 12:03:08 2010	(r5614)
@@ -89,8 +89,3 @@
 	default 2
 	depends on BOARD_INTEL_D945GCLF
 
-config HAVE_ACPI_SLIC
-	bool
-	default n
-	depends on BOARD_INTEL_D945GCLF
-

Modified: trunk/src/mainboard/kontron/986lcd-m/Kconfig
==============================================================================
--- trunk/src/mainboard/kontron/986lcd-m/Kconfig	Sat Jun  5 11:52:37 2010	(r5613)
+++ trunk/src/mainboard/kontron/986lcd-m/Kconfig	Sat Jun  5 12:03:08 2010	(r5614)
@@ -66,8 +66,3 @@
 	default "amipci_01.20"
 	depends on BOARD_KONTRON_986LCD_M
 
-config HAVE_ACPI_SLIC
-	bool
-	default n
-	depends on BOARD_KONTRON_986LCD_M
-

Modified: trunk/src/mainboard/roda/rk886ex/Kconfig
==============================================================================
--- trunk/src/mainboard/roda/rk886ex/Kconfig	Sat Jun  5 11:52:37 2010	(r5613)
+++ trunk/src/mainboard/roda/rk886ex/Kconfig	Sat Jun  5 12:03:08 2010	(r5614)
@@ -63,8 +63,3 @@
 	default 0x6886
 	depends on BOARD_RODA_RK886EX
 
-config HAVE_ACPI_SLIC
-	bool
-	default n
-	depends on BOARD_RODA_RK886EX
-

Modified: trunk/src/southbridge/intel/i82801gx/i82801gx_azalia.c
==============================================================================
--- trunk/src/southbridge/intel/i82801gx/i82801gx_azalia.c	Sat Jun  5 11:52:37 2010	(r5613)
+++ trunk/src/southbridge/intel/i82801gx/i82801gx_azalia.c	Sat Jun  5 12:03:08 2010	(r5614)
@@ -90,10 +90,10 @@
 	return 0;
 }
 
-u32 * cim_verb_data = NULL;
+const u32 * cim_verb_data = NULL;
 u32 cim_verb_data_size = 0;
 
-static u32 find_verb(struct device *dev, u32 viddid, u32 ** verb)
+static u32 find_verb(struct device *dev, u32 viddid, const u32 ** verb)
 {
 	int idx=0;
 
@@ -166,7 +166,7 @@
 static void codec_init(struct device *dev, u32 base, int addr)
 {
 	u32 reg32;
-	u32 *verb;
+	const u32 *verb;
 	u32 verb_size;
 	int i;
 



From sdubois at gnu.org  Sat Jun  5 16:55:27 2010
From: sdubois at gnu.org (Steven DuBois)
Date: Sat, 05 Jun 2010 10:55:27 -0400
Subject: [coreboot] Building a desktop, looking for suggestions
Message-ID: <1275749727.2448.8.camel@master-vile>

Hello everyone,

This summer, I am planning on building a new desktop PC for college.
This seems like the perfect opportunity to play with coreboot.

The list of supported motherboards is getting rather large, which is a
good thing, but I am wondering if anyone here can suggest a good
motherboard. I want to have a dual core CPU, but beyond that I have no
special requirements.

Thanks
-- 
Steven DuBois
http://sdubois.org




From tiagomnm at gmail.com  Sat Jun  5 19:03:25 2010
From: tiagomnm at gmail.com (Tiago Marques)
Date: Sat, 5 Jun 2010 18:03:25 +0100
Subject: [coreboot] SIS630ET coreboot challenge
In-Reply-To: <4C0A0B8E.2040809@coresystems.de>
References: <AANLkTikFxOKoGfkTAE0vdSpGLHAqZtso0bKKpccs5Dsi@mail.gmail.com> 
	<4BFADBE1.8020007@coresystems.de>
	<AANLkTikBCEbCJiU9-UWEow6oz1QICeqHNSXS7hfqRaQK@mail.gmail.com> 
	<4C030C99.8090107@coresystems.de>
	<AANLkTinP8T-89w2dgngDyhgjYVXVowlKBiHz_rRnlhms@mail.gmail.com> 
	<4C0A0B8E.2040809@coresystems.de>
Message-ID: <AANLkTikedXbbd8W99a0jmCj_mPbJiYngAHYnM92qhNWY@mail.gmail.com>

Me? I wasn't after that.

Best regards

On Sat, Jun 5, 2010 at 9:32 AM, Stefan Reinauer <
stefan.reinauer at coresystems.de> wrote:

> On 6/5/10 5:15 AM, Tiago Marques wrote:
> > See the attachment, doesn't look like something from a company that's
> > alive and kicking. I know them since the SiS 730.
> > Last time I heard they had some design win for a Core 2 chipset that I
> > haven't seen in any product and started selling SiS branded SO-DIMMS :|
> >
> So you did contact them for data sheets?
>
> --
> 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/20100605/4d218bf9/attachment.html>

From peter at stuge.se  Sat Jun  5 22:48:36 2010
From: peter at stuge.se (Peter Stuge)
Date: Sat, 5 Jun 2010 22:48:36 +0200
Subject: [coreboot] [PATCH] Fix geode lx VSA loading
In-Reply-To: <95EC52016CC5DE4896FD95FA7323A4DB152FFE43DA@mr-burns.exchange.virtensys.com>
References: <95EC52016CC5DE4896FD95FA7323A4DB152FFE43DA@mr-burns.exchange.virtensys.com>
Message-ID: <20100605204836.26652.qmail@stuge.se>

Edwin Beasant wrote:
> This patch fixes the option rom code that was buggy

Content-Description: coreboot-v4-vsa-fix.patch
> @@ -141,21 +146,25 @@
>  	mov	%ax, %ds
>  	lidt	__realmode_idt
>  
> +	/* initialize registers for option rom lcall */
> +	movl	__registers +  0, %eax
..
>  	/* Set all segments to 0x0000, ds to 0x0040 */
> +
>  	mov	%ax, %es
>  	mov	%ax, %fs
>  	mov	%ax, %gs
>  	mov	$0x40, %ax
>  	mov	%ax, %ds
> +	popal
>  
> -	/* initialize registers for option rom lcall */
> -	movl	__registers +  0, %eax

Thanks for finding that one Edwin! Good find. I read through it a few
times but didn't catch the ds change/memory ref.


//Peter



From peter at stuge.se  Sat Jun  5 23:11:29 2010
From: peter at stuge.se (Peter Stuge)
Date: Sat, 5 Jun 2010 23:11:29 +0200
Subject: [coreboot] [commit] r5609 - in trunk/src: drivers
	drivers/dec	drivers/dec/21143 drivers/ti
	drivers/ti/pcmcia-cardbus	include/device mainboard/nokia/ip530
In-Reply-To: <E1OKcxo-0006Dc-1Q@ra.coresystems.de>
References: <E1OKcxo-0006Dc-1Q@ra.coresystems.de>
Message-ID: <20100605211129.29623.qmail@stuge.se>

I have several issues with this commit. I pointed out at least one of
them already very long ago!


repository service wrote:
> +++ trunk/src/drivers/Kconfig	Fri Jun  4 21:53:55 2010	(r5609)
> @@ -23,3 +23,21 @@
>  	help
>  	It sets PCI class to IDE compatible native mode, allowing
>  	SeaBIOS, FILO etc... to boot from it.
> +
> +config DRIVERS_TI
> +	bool
> +
> +config DRIVERS_TI_PCI1225
> +	select DRIVERS_TI
> +	bool
> +
> +config DRIVERS_TI_PCI1420
> +	select DRIVERS_TI
> +	bool
> +
> +config DRIVERS_TI_PCI1520
> +	select DRIVERS_TI
> +	bool

DRIVERS_TI is not a great name! And is the code for these three
devices really so different that it warrants three different config
variables? I doubt that.


> +++ trunk/src/drivers/Makefile.inc	Fri Jun  4 21:53:55 2010	(r5609)
> @@ -1,3 +1,5 @@
>  subdirs-y += generic/debug
>  subdirs-y += ati/ragexl
>  subdirs-y += sil/3114
> +subdirs-y += ti/pcmcia-cardbus

The way this is done there is now a big disconnect between those
CONFIG_TI_* and the filenames that they relate to. That really hurts
understandability of our code base and I don't like that at all.


> Added: trunk/src/drivers/dec/21143/21143pd.c

This path is really redundant. Is it correct? I am not sure. "Others
are like that" is not a good reason. And why is there both 21143 and
21143pd? Does the code apply to ALL 21143 or strictly to 21143PD? The
CONFIG_ name implies strictly 21143PD, but the directory name implies
the opposite. This ambiguity is not good!


> +++ trunk/src/drivers/dec/21143/21143pd.c	Fri Jun  4 21:53:55 2010	(r5609)
..
> +/**
> + * The following should be set in the mainboard-specific Kconfig file.
> + */
> +#if (!defined(CONFIG_DEC21143_CACHE_LINE_SIZE) || \
> +     !defined(CONFIG_DEC21143_EXPANSION_ROM_BASE_ADDRESS) || \
> +     !defined(CONFIG_DEC21143_COMMAND_AND_STATUS_CONFIGURATION))
> +#error "you must supply these values in your mainboard-specific Kconfig file"
> +#endif
> +
> +/* CONFIG_DEC21143_CACHE_LINE_SIZE try 0x00000000 if unsure */
> +/* CONFIG_DEC21143_EXPANSION_ROM_BASE_ADDRESS try 0x00000000 if unsure */
> +/* CONFIG_DEC21143_COMMAND_AND_STATUS_CONFIGURATION try 0x02800107 or 0x02800007 if unsure */

Please explain why they should be set by the mainboard if there are
default values?

I very strongly dislike adding any configuration whatsoever to
mainboards, I think it is important to try to always avoid it.
Can you explain why this is absolutely neccessary?


> +++ trunk/src/drivers/ti/pcmcia-cardbus/ti-pcmcia-cardbus.c	Fri Jun  4 21:53:55 2010	(r5609)
..
> +#if (	!defined( CONFIG_TI_PCMCIA_CARDBUS_CMDR ) || \
> +	!defined( CONFIG_TI_PCMCIA_CARDBUS_CLSR ) || \
> +	!defined( CONFIG_TI_PCMCIA_CARDBUS_CLTR	) || \
> +	!defined( CONFIG_TI_PCMCIA_CARDBUS_BCR ) || \
> +	!defined( CONFIG_TI_PCMCIA_CARDBUS_SCR ) || \
> +	!defined( CONFIG_TI_PCMCIA_CARDBUS_MRR ) )
> +#error "you must supply these values in your mainboard-specific Kconfig file"
> +#endif

Same thing here. Please explain more about how these values are
mainboard-specific?


> +static void ti_pci1x2y_init(struct device *dev)
> +{
> +	printk(BIOS_INFO, "Init of Texas Instruments PCI1x2x PCMCIA/CardBus controller\n");

Here is confirmation that the CONFIG_ names are not very good for
this piece of code. The function name and printk suggests that the
exact same code is used for all controllers.


> +#ifdef CONFIG_DRIVERS_TI_PCI1225
> +static const struct pci_driver ti_pci1225_driver __pci_driver = {
> +        .ops    = &ti_pci1x2y_ops,
> +        .vendor = PCI_VENDOR_ID_TI,
> +        .device = PCI_DEVICE_ID_TI_1225,
> +};
> +
> +#endif
> +#ifdef CONFIG_DRIVERS_TI_PCI1420
> +static const struct pci_driver ti_pci1420_driver __pci_driver = {
> +        .ops    = &ti_pci1x2y_ops,
> +        .vendor = PCI_VENDOR_ID_TI,
> +        .device = PCI_DEVICE_ID_TI_1420,
> +};
> +#endif
> +#ifdef CONFIG_DRIVERS_TI_PCI1520
> +static const struct pci_driver ti_pci1520_driver __pci_driver = {
> +        .ops    = &ti_pci1x2y_ops,
> +        .vendor = PCI_VENDOR_ID_TI,
> +        .device = PCI_DEVICE_ID_TI_1420,
> +};
> +#endif

And yes indeed - the exact same code is used for all devices. Then I
think there must also only be a single CONFIG_ variable.


> +++ trunk/src/include/device/pci_ids.h	Fri Jun  4 21:53:55 2010	(r5609)
> @@ -696,6 +696,7 @@
>  #define PCI_DEVICE_ID_TI_4410		0xac41
>  #define PCI_DEVICE_ID_TI_4451		0xac42
>  #define PCI_DEVICE_ID_TI_1420		0xac51
> +#define PCI_DEVICE_ID_TI_1520		0xAC55

Somewhat minor, but please use lower case for a-f to look like other
values in the file.


> @@ -1741,6 +1742,10 @@
>  #define PCI_DEVICE_ID_CCD_B00C		0xb00c
>  #define PCI_DEVICE_ID_CCD_B100		0xb100
>  
> +#define PCI_VENDOR_ID_NOKIA		0x13B8	// Nokia Telecommunications oy
> +#define PCI_VENDOR_ID_NOKIA_WIRELESS	0x1603	// Nokia Wireless Communications
> +#define PCI_VENDOR_ID_NOKIA_HOME	0x1622	// Nokia Home Communications

And please don't add such comments. The name of the define should be
good enough to provide sufficiently meaningful information about what
this number represents. If a comment is neccessary then the name is
bad. I think the names are great, so there should be no comments.
(Also, please avoid // comments, they're allowed in C99 but not in
older C standards.)


> +++ trunk/src/mainboard/nokia/ip530/Kconfig	Fri Jun  4 21:53:55 2010	(r5609)
> @@ -24,10 +24,12 @@
>  	select NORTHBRIDGE_INTEL_I440BX
>  	select SOUTHBRIDGE_INTEL_I82371EB
>  	select SUPERIO_SMSC_SMSCSUPERIO
> +	select DRIVERS_TI_PCI1225
> +	select DRIVERS_DEC_21143PD
>  	select ROMCC
> +	select PIRQ_ROUTE
>  	select HAVE_PIRQ_TABLE
>  	select UDELAY_TSC
> -	select BOARD_ROMSIZE_KB_256

I already asked many times why the romsize was removed, but Myles has
already fixed it.


> +## Configuration items for the ethernet adaptors
> +config DEC21143_CACHE_LINE_SIZE

If these are absolutely neccessary then I think they should go into
devicetree.cb rather than Kconfig.


> +## Configuration for the PCMCIA-Cardbus controller.
> +config TI_PCMCIA_CARDBUS_CMDR

Same for these.


//Peter



From kara_am at yahoo.com  Sun Jun  6 05:46:32 2010
From: kara_am at yahoo.com (am kara)
Date: Sat, 5 Jun 2010 20:46:32 -0700 (PDT)
Subject: [coreboot] a question about SeaBIOS
Message-ID: <70841.61035.qm@web114605.mail.gq1.yahoo.com>

Does SeaBIOS support SATA hard drives? What chipset and hardware it support? 


      



From rminnich at gmail.com  Sun Jun  6 06:50:12 2010
From: rminnich at gmail.com (ron minnich)
Date: Sat, 5 Jun 2010 21:50:12 -0700
Subject: [coreboot] [PATCH] Fix geode lx VSA loading
In-Reply-To: <208622BC47ED4B7F88606AF82C8056B8@chimp>
References: <95EC52016CC5DE4896FD95FA7323A4DB152FFE43DA@mr-burns.exchange.virtensys.com>
	<1275669457.1521.7.camel@tetris> <4C092C7F.5030302@coresystems.de>
	<208622BC47ED4B7F88606AF82C8056B8@chimp>
Message-ID: <AANLkTimtPS6fYcFmndu4TO_GLDZV8e7cr4vHOGu2TDeB@mail.gmail.com>

On Fri, Jun 4, 2010 at 9:53 AM, Myles Watson <mylesgw at gmail.com> wrote:

> mov $0, %ax

use the classic:
xorl %ax, %ax

ron



From peter at stuge.se  Sun Jun  6 07:06:47 2010
From: peter at stuge.se (Peter Stuge)
Date: Sun, 6 Jun 2010 07:06:47 +0200
Subject: [coreboot] a question about SeaBIOS
In-Reply-To: <70841.61035.qm@web114605.mail.gq1.yahoo.com>
References: <70841.61035.qm@web114605.mail.gq1.yahoo.com>
Message-ID: <20100606050647.17237.qmail@stuge.se>

am kara wrote:
> Does SeaBIOS support SATA hard drives?

Yes.


> What chipset and hardware it support? 

Do you mean mainboard chipset or hard drive controller chipset?

As for mainboard, SeaBIOS doesn't need to explicitly support
mainboards.

For storage ny IDE-compatible controller will work fine, and very
many SATA controllers are IDE-compatible.


//Peter



From peter at stuge.se  Sun Jun  6 07:45:17 2010
From: peter at stuge.se (Peter Stuge)
Date: Sun, 6 Jun 2010 07:45:17 +0200
Subject: [coreboot] A patch to replace the headers of three files -
	no	functional changes.
In-Reply-To: <276EC11373289744A112A8FE6675506701183E8DC0@SAUSEXMBP01.amd.com>
References: <276EC11373289744A112A8FE6675506701183E8DC0@SAUSEXMBP01.amd.com>
Message-ID: <20100606054517.24071.qmail@stuge.se>

Hello Frank,

Vibrans, Frank wrote:
> This patch replaces the headers of the following files:
> 
>     src/cpu/amd/model_fxx/model_fxx_update_microcode.c
>     src/northbridge/amd/amdk8/amdk8_acpi.c
>     src/southbridge/amd/amd8132/amd8132_bridge.c

Thank you very much for sorting this out!


//Peter



From r.marek at assembler.cz  Sun Jun  6 17:01:16 2010
From: r.marek at assembler.cz (Rudolf Marek)
Date: Sun, 06 Jun 2010 17:01:16 +0200
Subject: [coreboot] AMD CAR quiz question
Message-ID: <4C0BB83C.2060608@assembler.cz>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hello,

It makes me wonder why CAR on APs use same stack? How does this can work? I
thought CPUs somehow keep caches coherent between them. I see that Fam10h CAR
code allocates 1KB for each AP. But not pre Fam10h.

How this can work?

Rationale for question is to have some kind of mutex for serial console
printouts and for Network over console. Secret plan is to print outputs from
different CPUs on different UDP port ;)

Second reason is that we really need some inter CPU mutex for PCI access.

In principle is correct that all CPUs once after CAR stage share the cache contents?

Thanks,
Rudolf
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAkwLuDwACgkQ3J9wPJqZRNU/cwCcChsbMNe7bxKp03IofGnNvU/g
YiEAn1z1+Du/GgB/i5+4tBq2ItJ0ylyr
=ArrJ
-----END PGP SIGNATURE-----



From stefan.reinauer at coresystems.de  Sun Jun  6 17:28:46 2010
From: stefan.reinauer at coresystems.de (Stefan Reinauer)
Date: Sun, 06 Jun 2010 17:28:46 +0200
Subject: [coreboot] AMD CAR quiz question
In-Reply-To: <4C0BB83C.2060608@assembler.cz>
References: <4C0BB83C.2060608@assembler.cz>
Message-ID: <4C0BBEAE.6060509@coresystems.de>

On 6/6/10 5:01 PM, Rudolf Marek wrote:
> Hello,
>
> It makes me wonder why CAR on APs use same stack?
Maybe it is not coherent?
Or maybe it doesn't really work?
> I see that Fam10h CAR
> code allocates 1KB for each AP. But not pre Fam10h.
>
> How this can work?
>
> Rationale for question is to have some kind of mutex for serial console
> printouts and for Network over console. Secret plan is to print
> outputs from
> different CPUs on different UDP port ;)
>
> Second reason is that we really need some inter CPU mutex for PCI access.

Or we need to stop doing PCI accesses and console output in SMP before
we have RAM.

I somehow can't imagine that the speed improvements we get from doing
concurrent PCI config space accesses to some 100 registers really make
up for the trouble we get ourselves into by trying to wildly spread
configuration tasks among CPUs (and doing it differently on basically
every mainboard that uses K8 or K10)

Stefan



From r.marek at assembler.cz  Sun Jun  6 17:42:47 2010
From: r.marek at assembler.cz (Rudolf Marek)
Date: Sun, 06 Jun 2010 17:42:47 +0200
Subject: [coreboot] AMD CAR quiz question
In-Reply-To: <4C0BBEAE.6060509@coresystems.de>
References: <4C0BB83C.2060608@assembler.cz> <4C0BBEAE.6060509@coresystems.de>
Message-ID: <4C0BC1F7.4060703@assembler.cz>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

I think it is mostly because there is memory init done by APs. Is this true for
some board?

Thanks,
Rudolf
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAkwLwfcACgkQ3J9wPJqZRNVUuwCeOiO0GH+ARFtCSvPIz/zsX51k
vtgAoKHoxvbHTFTOpNQ86NEVZFPu5IY7
=KLfr
-----END PGP SIGNATURE-----



From stefan.reinauer at coresystems.de  Sun Jun  6 18:08:08 2010
From: stefan.reinauer at coresystems.de (Stefan Reinauer)
Date: Sun, 06 Jun 2010 18:08:08 +0200
Subject: [coreboot] AMD CAR quiz question
In-Reply-To: <4C0BC1F7.4060703@assembler.cz>
References: <4C0BB83C.2060608@assembler.cz> <4C0BBEAE.6060509@coresystems.de>
	<4C0BC1F7.4060703@assembler.cz>
Message-ID: <4C0BC7E8.8040107@coresystems.de>

On 6/6/10 5:42 PM, Rudolf Marek wrote:
> I think it is mostly because there is memory init done by APs. Is this
> true for
> some board?
Afaik it's "ECC clearing" which is implemented several times in the
tree, including stage2.
It needs no PCI access nor console output, though... and parallelizing
the burden of PCI config space writes is not where the speedup lives.


Stefan



From r.marek at assembler.cz  Sun Jun  6 18:29:01 2010
From: r.marek at assembler.cz (Rudolf Marek)
Date: Sun, 06 Jun 2010 18:29:01 +0200
Subject: [coreboot] AMD CAR quiz question
In-Reply-To: <4C0BC7E8.8040107@coresystems.de>
References: <4C0BB83C.2060608@assembler.cz>
	<4C0BBEAE.6060509@coresystems.de>	<4C0BC1F7.4060703@assembler.cz>
	<4C0BC7E8.8040107@coresystems.de>
Message-ID: <4C0BCCCD.9040007@assembler.cz>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

> Afaik it's "ECC clearing" which is implemented several times in the
> tree, including stage2.

Nope, the APs can init the memory controller too. Check
CONFIG_MEM_TRAIN_SEQ 0 for BSP only
1 = train_ram_on_node is called from init_cpus
2 = dunno - looks like it is also done in parallel but I could not find how it
works.

Lot of boards sets it up for 2 a think only one to 1

Thanks,
Rudolf
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAkwLzM0ACgkQ3J9wPJqZRNXnJACggCA6DuDnIA8XKPgjeBFS/YEm
PQwAoJOBWtko+KzopAQLiPvstoFqBiiO
=l48p
-----END PGP SIGNATURE-----



From borg.db at gmail.com  Sun Jun  6 19:17:22 2010
From: borg.db at gmail.com (David Borg)
Date: Sun, 6 Jun 2010 19:17:22 +0200
Subject: [coreboot] Mobo Support
Message-ID: <AANLkTimwasrhRi0rQBcsi_42RBw12O4lJsNzH5ZaLFY3@mail.gmail.com>

Hey all,  I was thinking of trying out coreboot on my old desktop pc and
would like to check whether the motherboard is supported, as it is not in
the list of supported motherboards.

System description:
Board vendor : Gigabyte
Board name : GA-6VX7-4X
CPU : Intel Celeron 633MHz
Northbridge : VT82C694X (URL:
http://www.datasheetarchive.com/pdf-datasheets/Datasheets-23/DSA-446497.pdf)
Southbridge : VT82C686A (URL: http://www.charmed.com/PDF/VT82C686A.pdf)

The output of lspci -tvnn is attached (lscpi.txt).
Note:
\-0b.0  Realtek Semiconductor Co., Ltd. RTL-8139/8139C/8139C+ [10ec:8139] <=
PCI network card
+-01.0-[0000:01]----00.0  S3 Inc. 86c368 [Trio 3D/2X] [5333:8a13] <= AGP
graphics card

No super io chip was identified by superiotool (output attached as
superiotool.txt).
Note:
Super-IO  should be integrated in the southbridge chip VT82C686A

BIOS device: PLCC32 chip (soldered directly to mainboard). Flashrom does not
detect the BIOS chip.
Output of flashrom attached as flashrom.txt

Motherboard info:
http://www.gigabyte.com/products/product-page.aspx?pid=1415&dl=#sp


Thanks,

David Borg
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20100606/13963913/attachment.html>
-------------- next part --------------
-[0000:00]-+-00.0  VIA Technologies, Inc. VT82C693A/694x [Apollo PRO133x] [1106:0691]
           +-01.0-[0000:01]----00.0  S3 Inc. 86c368 [Trio 3D/2X] [5333:8a13]
           +-07.0  VIA Technologies, Inc. VT82C686 [Apollo Super South] [1106:0686]
           +-07.1  VIA Technologies, Inc. VT82C586A/B/VT82C686/A/B/VT823x/A/C PIPC Bus Master IDE [1106:0571]
           +-07.2  VIA Technologies, Inc. VT82xxxxx UHCI USB 1.1 Controller [1106:3038]
           +-07.3  VIA Technologies, Inc. VT82xxxxx UHCI USB 1.1 Controller [1106:3038]
           +-07.4  VIA Technologies, Inc. VT82C686 [Apollo Super ACPI] [1106:3057]
           +-07.5  VIA Technologies, Inc. VT82C686 AC97 Audio Controller [1106:3058]
           \-0b.0  Realtek Semiconductor Co., Ltd. RTL-8139/8139C/8139C+ [10ec:8139]
-------------- next part --------------
superiotool r3844
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=0xffff, id=0xffff
Probing for Fintek Super I/O at 0x4e...
  Failed. Returned data: vid=0xffff, id=0xffff
Probing for ITE Super I/O (init=standard) at 0x2e...
  Failed. Returned data: id=0xffff, rev=0xf
Probing for ITE Super I/O (init=it8761e) at 0x2e...
  Failed. Returned data: id=0xffff, rev=0xf
Probing for ITE Super I/O (init=it8228e) at 0x2e...
  Failed. Returned data: id=0xffff, rev=0xf
Probing for ITE Super I/O (init=0x87,0x87) at 0x2e...
  Failed. Returned data: id=0xffff, rev=0xf
Probing for ITE Super I/O (init=standard) at 0x4e...
  Failed. Returned data: id=0xffff, rev=0xf
Probing for ITE Super I/O (init=it8761e) at 0x4e...
  Failed. Returned data: id=0xffff, rev=0xf
Probing for ITE Super I/O (init=it8228e) 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 ITE Super I/O (init=legacy/it8661f) at 0x370...
  Failed. Returned data: id=0xffff, rev=0xf
Probing for ITE Super I/O (init=legacy/it8671f) at 0x370...
  Failed. Returned data: id=0xffff, rev=0xf
Probing for NSC Super I/O at 0x2e...
  Failed. Returned data: port=0xff, port+1=0xff
Probing for NSC Super I/O at 0x4e...
  Failed. Returned data: port=0xff, port+1=0xff
Probing for NSC Super I/O at 0x15c...
  Failed. Returned data: port=0xff, port+1=0xff
Probing for SMSC Super I/O (idregs=0x20/0x21) at 0x2e...
  Failed. Returned data: id=0xff, rev=0xff
Probing for SMSC Super I/O (idregs=0x0d/0x0e) at 0x2e...
  Failed. Returned data: id=0xff, rev=0xff
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=0xff/0x0f, rev=0xff
Probing for Winbond Super I/O (init=0x89) at 0x2e...
  Failed. Returned data: id/oldid=0xff/0x0f, rev=0xff
Probing for Winbond Super I/O (init=0x86,0x86) at 0x2e...
  Failed. Returned data: id/oldid=0xff/0x0f, rev=0xff
Probing for Winbond Super I/O (init=0x87,0x87) at 0x2e...
  Failed. Returned data: id/oldid=0xff/0x0f, rev=0xff
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
No Super I/O found
-------------- next part --------------
flashrom v0.9.2-r1033 on Linux 2.6.31-22-generic (i686), built with libpci 3.0.0, GCC 4.4.1, little endian
flashrom is free software, get the source code at http://www.flashrom.org

Calibrating delay loop... OS timer resolution is 3 usecs, 211M loops per second, 10 myus = 11 us, 100 myus = 101 us, 1000 myus = 999 us, 10000 myus = 10063 us, 12 myus = 14 us, OK.
Initializing internal programmer
No coreboot table found.
DMI string system-manufacturer: "                                "
DMI string system-product-name: "                                "
DMI string system-version: "00000000"
DMI string baseboard-manufacturer: "Gigabyte Technology Co., Ltd."
DMI string baseboard-product-name: "6VX7-4X / 6VX7B-4X"
DMI string baseboard-version: "1.0"
DMI string chassis-type: "Desktop"
Found chipset "VIA VT82C686A/B", enabling flash write... chipset PCI ID is 1106:0686, OK.
This chipset supports the following protocols: Non-SPI.
Probing for AMD Am29F010A/B, 128 KB: probe_jedec_common: id1 0xad, id2 0xb0
Probing for AMD Am29F002(N)BB, 256 KB: probe_jedec_common: id1 0xad, id2 0xb0
Probing for AMD Am29F002(N)BT, 256 KB: probe_jedec_common: id1 0xad, id2 0xb0
Probing for AMD Am29F016D, 2048 KB: Chip size 2048 kB is bigger than supported size 512 kB of chipset/board/programmer for Parallel interface, probe/read/erase/write may fail. Chip lacks correct probe timing information, using default 10mS/40uS. probe_jedec_common: id1 0xff, id2 0xff, id1 parity violation, id1 is normal flash content, id2 is normal flash content
Probing for AMD Am29F040B, 512 KB: Chip lacks correct probe timing information, using default 10mS/40uS. probe_jedec_common: id1 0xad, id2 0xb0
Probing for AMD Am29F080B, 1024 KB: Chip size 1024 kB is bigger than supported size 512 kB of chipset/board/programmer for Parallel interface, probe/read/erase/write may fail. probe_jedec_common: id1 0xad, id2 0xb0
Probing for AMD Am29LV040B, 512 KB: Chip lacks correct probe timing information, using default 10mS/40uS. probe_jedec_common: id1 0xad, id2 0xb0
Probing for AMD Am29LV081B, 1024 KB: Chip size 1024 kB is bigger than supported size 512 kB of chipset/board/programmer for Parallel interface, probe/read/erase/write may fail. Chip lacks correct probe timing information, using default 10mS/40uS. probe_jedec_common: id1 0xad, id2 0xb0
Probing for ASD AE49F2008, 256 KB: Chip lacks correct probe timing information, using default 10mS/40uS. probe_jedec_common: id1 0xad, id2 0xb0
Probing for Atmel AT25DF021, 256 KB: skipped.
Probing for Atmel AT25DF041A, 512 KB: skipped.
Probing for Atmel AT25DF081, 1024 KB: skipped.
Probing for Atmel AT25DF161, 2048 KB: skipped.
Probing for Atmel AT25DF321, 4096 KB: skipped.
Probing for Atmel AT25DF321A, 4096 KB: skipped.
Probing for Atmel AT25DF641, 8192 KB: skipped.
Probing for Atmel AT25F512B, 64 KB: skipped.
Probing for Atmel AT25FS010, 128 KB: skipped.
Probing for Atmel AT25FS040, 512 KB: skipped.
Probing for Atmel AT26DF041, 512 KB: skipped.
Probing for Atmel AT26DF081A, 1024 KB: skipped.
Probing for Atmel AT26DF161, 2048 KB: skipped.
Probing for Atmel AT26DF161A, 2048 KB: skipped.
Probing for Atmel AT26F004, 512 KB: skipped.
Probing for Atmel AT29C512, 64 KB: probe_jedec_common: id1 0xad, id2 0xb0
Probing for Atmel AT29C010A, 128 KB: probe_jedec_common: id1 0xad, id2 0xb0
Probing for Atmel AT29C020, 256 KB: probe_jedec_common: id1 0xad, id2 0xb0
Probing for Atmel AT29C040A, 512 KB: probe_jedec_common: id1 0xad, id2 0xb0
Probing for Atmel AT45CS1282, 16896 KB: skipped.
Probing for Atmel AT45DB011D, 128 KB: skipped.
Probing for Atmel AT45DB021D, 256 KB: skipped.
Probing for Atmel AT45DB041D, 512 KB: skipped.
Probing for Atmel AT45DB081D, 1024 KB: skipped.
Probing for Atmel AT45DB161D, 2048 KB: skipped.
Probing for Atmel AT45DB321C, 4224 KB: skipped.
Probing for Atmel AT45DB321D, 4096 KB: skipped.
Probing for Atmel AT45DB642D, 8192 KB: skipped.
Probing for Atmel AT49BV512, 64 KB: probe_jedec_common: id1 0xad, id2 0xb0
Probing for Atmel AT49F002(N), 256 KB: probe_jedec_common: id1 0xad, id2 0xb0
Probing for Atmel AT49F002(N)T, 256 KB: probe_jedec_common: id1 0xad, id2 0xb0
Probing for AMIC A25L40PT, 512 KB: skipped.
Probing for AMIC A25L40PU, 512 KB: skipped.
Probing for AMIC A29002B, 256 KB: Chip lacks correct probe timing information, using default 10mS/40uS. probe_jedec_common: id1 0xad, id2 0xb0
Probing for AMIC A29002T, 256 KB: Chip lacks correct probe timing information, using default 10mS/40uS. probe_jedec_common: id1 0xad, id2 0xb0
Probing for AMIC A29040B, 512 KB: Chip lacks correct probe timing information, using default 10mS/40uS. probe_jedec_common: id1 0xad, id2 0xb0
Probing for AMIC A49LF040A, 512 KB: probe_jedec_common: id1 0xad, id2 0xb0
Probing for EMST F49B002UA, 256 KB: probe_jedec_common: id1 0xad, id2 0xb0
Probing for Eon EN25B05, 64 KB: skipped.
Probing for Eon EN25B05T, 64 KB: skipped.
Probing for Eon EN25B10, 128 KB: skipped.
Probing for Eon EN25B10T, 128 KB: skipped.
Probing for Eon EN25B20, 256 KB: skipped.
Probing for Eon EN25B20T, 256 KB: skipped.
Probing for Eon EN25B40, 512 KB: skipped.
Probing for Eon EN25B40T, 512 KB: skipped.
Probing for Eon EN25B80, 1024 KB: skipped.
Probing for Eon EN25B80T, 1024 KB: skipped.
Probing for Eon EN25B16, 2048 KB: skipped.
Probing for Eon EN25B16T, 2048 KB: skipped.
Probing for Eon EN25B32, 4096 KB: skipped.
Probing for Eon EN25B32T, 4096 KB: skipped.
Probing for Eon EN25B64, 8192 KB: skipped.
Probing for Eon EN25B64T, 8192 KB: skipped.
Probing for Eon EN25D16, 2048 KB: skipped.
Probing for Eon EN25F05, 64 KB: skipped.
Probing for Eon EN25F10, 128 KB: skipped.
Probing for Eon EN25F20, 256 KB: skipped.
Probing for Eon EN25F40, 512 KB: skipped.
Probing for Eon EN25F80, 1024 KB: skipped.
Probing for Eon EN25F16, 2048 KB: skipped.
Probing for Eon EN25F32, 4096 KB: skipped.
Probing for Eon EN29F010, 128 KB: probe_jedec_common: id1 0xad, id2 0xb0
Probing for EON EN29F002(A)(N)B, 256 KB: probe_jedec_common: id1 0xad, id2 0xb0
Probing for EON EN29F002(A)(N)T, 256 KB: probe_jedec_common: id1 0xad, id2 0xb0
Probing for Fujitsu MBM29F004BC, 512 KB: probe_jedec_common: id1 0xad, id2 0xb0
Probing for Fujitsu MBM29F004TC, 512 KB: probe_jedec_common: id1 0xad, id2 0xb0
Probing for Fujitsu MBM29F400BC, 512 KB: probe_m29f400bt: id1 0xff, id2 0xff
Probing for Fujitsu MBM29F400TC, 512 KB: probe_m29f400bt: id1 0xff, id2 0xff
Probing for Intel 28F001BX-B, 128 KB: probe_jedec_common: id1 0xad, id2 0xb0
Probing for Intel 28F001BX-T, 128 KB: probe_jedec_common: id1 0xad, id2 0xb0
Probing for Intel 28F004S5, 512 KB: probe_82802ab: id1 0xff, id2 0xff, id1 parity violation, id1 is normal flash content, id2 is normal flash content
Probing for Intel 28F004BV/BE-B, 512 KB: probe_82802ab: id1 0xff, id2 0xff, id1 parity violation, id1 is normal flash content, id2 is normal flash content
Probing for Intel 28F004BV/BE-T, 512 KB: probe_82802ab: id1 0xff, id2 0xff, id1 parity violation, id1 is normal flash content, id2 is normal flash content
Probing for Intel 28F400BV/CV/CE-B, 512 KB: probe_82802ab: id1 0xff, id2 0xff, id1 parity violation, id1 is normal flash content, id2 is normal flash content
Probing for Intel 28F400BV/CV/CE-T, 512 KB: probe_82802ab: id1 0xff, id2 0xff, id1 parity violation, id1 is normal flash content, id2 is normal flash content
Probing for Intel 82802AB, 512 KB: probe_82802ab: id1 0xff, id2 0xff, id1 parity violation, id1 is normal flash content, id2 is normal flash content
Probing for Intel 82802AC, 1024 KB: probe_82802ab: id1 0xff, id2 0xff, id1 parity violation, id1 is normal flash content, id2 is normal flash content
Probing for Macronix MX25L512, 64 KB: skipped.
Probing for Macronix MX25L1005, 128 KB: skipped.
Probing for Macronix MX25L2005, 256 KB: skipped.
Probing for Macronix MX25L4005, 512 KB: skipped.
Probing for Macronix MX25L8005, 1024 KB: skipped.
Probing for Macronix MX25L1605, 2048 KB: skipped.
Probing for Macronix MX25L1635D, 2048 KB: skipped.
Probing for Macronix MX25L3205, 4096 KB: skipped.
Probing for Macronix MX25L3235D, 4096 KB: skipped.
Probing for Macronix MX25L6405, 8192 KB: skipped.
Probing for Macronix MX25L12805, 16384 KB: skipped.
Probing for Macronix MX29F001B, 128 KB: Chip lacks correct probe timing information, using default 10mS/40uS. probe_jedec_common: id1 0xad, id2 0xb0
Probing for Macronix MX29F001T, 128 KB: Chip lacks correct probe timing information, using default 10mS/40uS. probe_jedec_common: id1 0xad, id2 0xb0
Probing for Macronix MX29F002B, 256 KB: Chip lacks correct probe timing information, using default 10mS/40uS. probe_jedec_common: id1 0xad, id2 0xb0
Probing for Macronix MX29F002T, 256 KB: Chip lacks correct probe timing information, using default 10mS/40uS. probe_jedec_common: id1 0xad, id2 0xb0
Probing for Macronix MX29LV040, 512 KB: Chip lacks correct probe timing information, using default 10mS/40uS. probe_jedec_common: id1 0xad, id2 0xb0
Probing for Numonyx M25PE10, 128 KB: skipped.
Probing for Numonyx M25PE20, 256 KB: skipped.
Probing for Numonyx M25PE40, 512 KB: skipped.
Probing for Numonyx M25PE80, 1024 KB: skipped.
Probing for Numonyx M25PE16, 2048 KB: skipped.
Probing for PMC Pm25LV010, 128 KB: skipped.
Probing for PMC Pm25LV016B, 2048 KB: skipped.
Probing for PMC Pm25LV020, 256 KB: skipped.
Probing for PMC Pm25LV040, 512 KB: skipped.
Probing for PMC Pm25LV080B, 1024 KB: skipped.
Probing for PMC Pm25LV512, 64 KB: skipped.
Probing for PMC Pm29F002T, 256 KB: Chip lacks correct probe timing information, using default 10mS/40uS. probe_jedec_common: id1 0xad, id2 0xb0
Probing for PMC Pm29F002B, 256 KB: Chip lacks correct probe timing information, using default 10mS/40uS. probe_jedec_common: id1 0xad, id2 0xb0
Probing for PMC Pm39LV010, 128 KB: probe_jedec_common: id1 0xad, id2 0xb0
Probing for PMC Pm39LV020, 256 KB: probe_jedec_common: id1 0xad, id2 0xb0
Probing for PMC Pm39LV040, 512 KB: probe_jedec_common: id1 0xad, id2 0xb0
Probing for PMC Pm49FL002, 256 KB: probe_jedec_common: id1 0xad, id2 0xb0
Probing for PMC Pm49FL004, 512 KB: probe_jedec_common: id1 0xad, id2 0xb0
Probing for Sanyo LF25FW203A, 2048 KB: skipped.
Probing for Sharp LHF00L04, 1024 KB: probe_82802ab: id1 0xff, id2 0xff, id1 parity violation, id1 is normal flash content, id2 is normal flash content
Probing for Spansion S25FL008A, 1024 KB: skipped.
Probing for Spansion S25FL016A, 2048 KB: skipped.
Probing for SST SST25VF016B, 2048 KB: skipped.
Probing for SST SST25VF032B, 4096 KB: skipped.
Probing for SST SST25VF040.REMS, 512 KB: skipped.
Probing for SST SST25VF040B, 512 KB: skipped.
Probing for SST SST25VF040B.REMS, 512 KB: skipped.
Probing for SST SST25VF080B, 1024 KB: skipped.
Probing for SST SST28SF040A, 512 KB: probe_82802ab: id1 0xff, id2 0xff, id1 parity violation, id1 is normal flash content, id2 is normal flash content
Probing for SST SST29EE010, 128 KB: probe_jedec_common: id1 0xad, id2 0xb0
Probing for SST SST29LE010, 128 KB: probe_jedec_common: id1 0xad, id2 0xb0
Probing for SST SST29EE020A, 256 KB: probe_jedec_common: id1 0xad, id2 0xb0
Probing for SST SST29LE020, 256 KB: probe_jedec_common: id1 0xad, id2 0xb0
Probing for SST SST39SF512, 64 KB: probe_jedec_common: id1 0xad, id2 0xb0
Probing for SST SST39SF010A, 128 KB: probe_jedec_common: id1 0xad, id2 0xb0
Probing for SST SST39SF020A, 256 KB: probe_jedec_common: id1 0xad, id2 0xb0
Probing for SST SST39SF040, 512 KB: probe_jedec_common: id1 0xad, id2 0xb0
Probing for SST SST39VF512, 64 KB: probe_jedec_common: id1 0xad, id2 0xb0
Probing for SST SST39VF010, 128 KB: probe_jedec_common: id1 0xad, id2 0xb0
Probing for SST SST39VF020, 256 KB: probe_jedec_common: id1 0xad, id2 0xb0
Probing for SST SST39VF040, 512 KB: probe_jedec_common: id1 0xad, id2 0xb0
Probing for SST SST39VF080, 1024 KB: Chip size 1024 kB is bigger than supported size 512 kB of chipset/board/programmer for Parallel interface, probe/read/erase/write may fail. probe_jedec_common: id1 0xad, id2 0xb0
Probing for SST SST49LF002A/B, 256 KB: probe_jedec_common: id1 0xad, id2 0xb0
Probing for SST SST49LF003A/B, 384 KB: probe_jedec_common: id1 0xad, id2 0xb0
Probing for SST SST49LF004A/B, 512 KB: probe_jedec_common: id1 0xad, id2 0xb0
Probing for SST SST49LF004C, 512 KB: probe_82802ab: id1 0xff, id2 0xff, id1 parity violation, id1 is normal flash content, id2 is normal flash content
Probing for SST SST49LF008A, 1024 KB: probe_jedec_common: id1 0xad, id2 0xb0
Probing for SST SST49LF008C, 1024 KB: probe_82802ab: id1 0xff, id2 0xff, id1 parity violation, id1 is normal flash content, id2 is normal flash content
Probing for SST SST49LF016C, 2048 KB: probe_82802ab: id1 0xff, id2 0xff, id1 parity violation, id1 is normal flash content, id2 is normal flash content
Probing for SST SST49LF020, 256 KB: probe_jedec_common: id1 0xad, id2 0xb0
Probing for SST SST49LF020A, 256 KB: probe_jedec_common: id1 0xad, id2 0xb0
Probing for SST SST49LF040, 512 KB: probe_jedec_common: id1 0xad, id2 0xb0
Probing for SST SST49LF040B, 512 KB: probe_jedec_common: id1 0xad, id2 0xb0
Probing for SST SST49LF080A, 1024 KB: Chip lacks correct probe timing information, using default 10mS/40uS. probe_jedec_common: id1 0xad, id2 0xb0
Probing for SST SST49LF160C, 2048 KB: probe_82802ab: id1 0xff, id2 0xff, id1 parity violation, id1 is normal flash content, id2 is normal flash content
Probing for ST M25P05-A, 64 KB: skipped.
Probing for ST M25P05.RES, 64 KB: skipped.
Probing for ST M25P10-A, 128 KB: skipped.
Probing for ST M25P10.RES, 128 KB: skipped.
Probing for ST M25P20, 256 KB: skipped.
Probing for ST M25P40, 512 KB: skipped.
Probing for ST M25P40-old, 512 KB: skipped.
Probing for ST M25P80, 1024 KB: skipped.
Probing for ST M25P16, 2048 KB: skipped.
Probing for ST M25P32, 4096 KB: skipped.
Probing for ST M25P64, 8192 KB: skipped.
Probing for ST M25P128, 16384 KB: skipped.
Probing for ST M29F002B, 256 KB: probe_jedec_common: id1 0xad, id2 0xb0
Probing for ST M29F002T/NT, 256 KB: probe_jedec_common: id1 0xad, id2 0xb0
Probing for ST M29F040B, 512 KB: Chip lacks correct probe timing information, using default 10mS/40uS. probe_jedec_common: id1 0xad, id2 0xb0
Probing for ST M29F400BT, 512 KB: probe_m29f400bt: id1 0xff, id2 0xff
Probing for ST M29W010B, 128 KB: probe_jedec_common: id1 0xad, id2 0xb0
Probing for ST M29W040B, 512 KB: probe_jedec_common: id1 0xad, id2 0xb0
Probing for ST M29W512B, 64 KB: probe_jedec_common: id1 0xad, id2 0xb0
Probing for ST M50FLW040A, 512 KB: probe_82802ab: id1 0xff, id2 0xff, id1 parity violation, id1 is normal flash content, id2 is normal flash content
Probing for ST M50FLW040B, 512 KB: probe_82802ab: id1 0xff, id2 0xff, id1 parity violation, id1 is normal flash content, id2 is normal flash content
Probing for ST M50FLW080A, 1024 KB: probe_82802ab: id1 0xff, id2 0xff, id1 parity violation, id1 is normal flash content, id2 is normal flash content
Probing for ST M50FLW080B, 1024 KB: probe_82802ab: id1 0xff, id2 0xff, id1 parity violation, id1 is normal flash content, id2 is normal flash content
Probing for ST M50FW002, 256 KB: probe_82802ab: id1 0xff, id2 0xff, id1 parity violation, id1 is normal flash content, id2 is normal flash content
Probing for ST M50FW016, 2048 KB: probe_82802ab: id1 0xff, id2 0xff, id1 parity violation, id1 is normal flash content, id2 is normal flash content
Probing for ST M50FW040, 512 KB: probe_82802ab: id1 0xff, id2 0xff, id1 parity violation, id1 is normal flash content, id2 is normal flash content
Probing for ST M50FW080, 1024 KB: probe_82802ab: id1 0xff, id2 0xff, id1 parity violation, id1 is normal flash content, id2 is normal flash content
Probing for ST M50LPW116, 2048 KB: probe_82802ab: id1 0xff, id2 0xff, id1 parity violation, id1 is normal flash content, id2 is normal flash content
Probing for SyncMOS S29C31004T, 512 KB: probe_jedec_common: id1 0xad, id2 0xb0
Probing for SyncMOS S29C51001T, 128 KB: probe_jedec_common: id1 0xad, id2 0xb0
Probing for SyncMOS S29C51002T, 256 KB: probe_jedec_common: id1 0xad, id2 0xb0
Probing for SyncMOS S29C51004T, 512 KB: probe_jedec_common: id1 0xad, id2 0xb0
Probing for TI TMS29F002RB, 256 KB: probe_jedec_common: id1 0xad, id2 0xb0
Probing for TI TMS29F002RT, 256 KB: probe_jedec_common: id1 0xad, id2 0xb0
Probing for Winbond W25Q80, 1024 KB: skipped.
Probing for Winbond W25Q16, 2048 KB: skipped.
Probing for Winbond W25Q32, 4096 KB: skipped.
Probing for Winbond W25x10, 128 KB: skipped.
Probing for Winbond W25x20, 256 KB: skipped.
Probing for Winbond W25x40, 512 KB: skipped.
Probing for Winbond W25x80, 1024 KB: skipped.
Probing for Winbond W25x16, 2048 KB: skipped.
Probing for Winbond W25x32, 4096 KB: skipped.
Probing for Winbond W25x64, 8192 KB: skipped.
Probing for Winbond W29C011, 128 KB: probe_jedec_common: id1 0xad, id2 0xb0
Probing for Winbond W29C020C, 256 KB: probe_jedec_common: id1 0xad, id2 0xb0
Probing for Winbond W29C040P, 512 KB: probe_jedec_common: id1 0xad, id2 0xb0
Probing for Winbond W29EE011, 128 KB: Probing disabled for Winbond W29EE011 because the probing sequence puts the AMIC A49LF040A in a funky state. Use 'flashrom -c W29EE011' if you have a board with this chip.
Probing for Winbond W39V040A, 512 KB: probe_jedec_common: id1 0xad, id2 0xb0
Probing for Winbond W39V040B, 512 KB: probe_jedec_common: id1 0xad, id2 0xb0
Probing for Winbond W39V040C, 512 KB: Chip lacks correct probe timing information, using default 10mS/40uS. probe_jedec_common: id1 0xad, id2 0xb0
Probing for Winbond W39V040FA, 512 KB: probe_jedec_common: id1 0xad, id2 0xb0
Probing for Winbond W39V080A, 1024 KB: probe_jedec_common: id1 0xad, id2 0xb0
Probing for Winbond W49F002U, 256 KB: probe_jedec_common: id1 0xad, id2 0xb0
Probing for Winbond W49V002A, 256 KB: probe_jedec_common: id1 0xad, id2 0xb0
Probing for Winbond W49V002FA, 256 KB: probe_jedec_common: id1 0xad, id2 0xb0
Probing for Winbond W39V080FA, 1024 KB: Chip lacks correct probe timing information, using default 10mS/40uS. probe_jedec_common: id1 0xad, id2 0xb0
Probing for Winbond W39V080FA (dual mode), 512 KB: Chip lacks correct probe timing information, using default 10mS/40uS. probe_jedec_common: id1 0xad, id2 0xb0
Probing for Atmel unknown Atmel SPI chip, 0 KB: skipped.
Probing for EON unknown EON SPI chip, 0 KB: skipped.
Probing for Macronix unknown Macronix SPI chip, 0 KB: skipped.
Probing for PMC unknown PMC SPI chip, 0 KB: skipped.
Probing for SST unknown SST SPI chip, 0 KB: skipped.
Probing for ST unknown ST SPI chip, 0 KB: skipped.
Probing for Sanyo unknown Sanyo SPI chip, 0 KB: skipped.
Probing for Generic unknown SPI chip (RDID), 0 KB: skipped.
Probing for Generic unknown SPI chip (REMS), 0 KB: skipped.
No EEPROM/flash device found.
Note: flashrom can never write if the flash chip isn't found automatically.

From stefan.reinauer at coresystems.de  Sun Jun  6 20:56:13 2010
From: stefan.reinauer at coresystems.de (Stefan Reinauer)
Date: Sun, 06 Jun 2010 20:56:13 +0200
Subject: [coreboot] AMD CAR quiz question
In-Reply-To: <4C0BCCCD.9040007@assembler.cz>
References: <4C0BB83C.2060608@assembler.cz>
	<4C0BBEAE.6060509@coresystems.de>	<4C0BC1F7.4060703@assembler.cz>
	<4C0BC7E8.8040107@coresystems.de> <4C0BCCCD.9040007@assembler.cz>
Message-ID: <4C0BEF4D.9080206@coresystems.de>

On 6/6/10 6:29 PM, Rudolf Marek wrote:
> > Afaik it's "ECC clearing" which is implemented several times in the
> > tree, including stage2.
>
> Nope, the APs can init the memory controller too. Check
> CONFIG_MEM_TRAIN_SEQ 0 for BSP only
> 1 = train_ram_on_node is called from init_cpus
> 2 = dunno - looks like it is also done in parallel but I could not
> find how it
> works.
>
> Lot of boards sets it up for 2 a think only one to 1
I think 2 is for calling it from CAR..

Still wondering how much time we save by parallelizing this... Did
anyone take a measurement?



From anders at jenbo.dk  Mon Jun  7 00:20:01 2010
From: anders at jenbo.dk (Anders Jenbo)
Date: Mon, 7 Jun 2010 00:20:01 +0200
Subject: [coreboot] Mobo Support
Message-ID: <53422.1275862801@jenbo.dk>

Hallo David

I am currently working on the chip-set that your board uses. So support is in progress. I have debug console running via serial and i am about a 1/3 in to getting the ram initialized. If you think you can help (time is the only real skill required) coding in the support you are more then welcome.

You should get in contact with the flashrom developers to get support for your flash chip. Remove the AMI BIOS lable from the rom chip and read the fist number on the actual chip, should be some thing similar to these http://www.flashrom.org/Supported_hardware. You can find the flashrom developers at freenode.net #flashrom, or flashrom at flashrom.org.

Good luck
-Anders


On Sun 06/06/10 19:17 , David Borg <borg.db at gmail.com> wrote:

> Hey all, ?I was thinking of trying out coreboot on my old desktop pc
> and would like to check whether the motherboard is supported, as it is
> not in the list of supported motherboards.
> System description:
> Board vendor : GigabyteBoard name : GA-6VX7-4XCPU : Intel Celeron
> 633MHz
> Northbridge :?VT82C694X
> (URL:?http://www.datasheetarchive.com/pdf-datasheets/Datasheets-23/DSA-446
> 497.pdf[1]) Southbridge :?VT82C686A
> (URL:?http://www.charmed.com/PDF/VT82C686A.pdf [2])
> 
> The output of lspci -tvnn is attached (lscpi.txt).  Note:-0b.0
> ?Realtek Semiconductor Co., Ltd. RTL-8139/8139C/8139C+ [10ec:8139] 
> 
> Links:
> ------
> [1]
> http://www.datasheetarchive.com/pdf-datasheets/Datasheets-23/DSA-446497.pdf
> [2] http://www.charmed.com/PDF/VT82C686A.pdf
> [3]
> http://www.gigabyte.com/products/product-page.aspx?pid=1415&amp;dl=#sp
> 
> 
---- Msg sent via @Mail - http://atmail.com/



From borg.db at gmail.com  Mon Jun  7 01:16:10 2010
From: borg.db at gmail.com (David Borg)
Date: Mon, 7 Jun 2010 01:16:10 +0200
Subject: [coreboot] Mobo Support
In-Reply-To: <53422.1275862801@jenbo.dk>
References: <53422.1275862801@jenbo.dk>
Message-ID: <AANLkTinzUzOgxO-oAJ6VaQzybzkifelz8L4FUwcO3LP5@mail.gmail.com>

Hey Anders, thanks for the reply.

Good to hear that progress is being made =] I should have some free
time available in the coming summer holidays, so I'll try to help out
then.

Regarding the rom chip, I got its number (HY29F002TC-90). I'll contact
the flashrom developers about support for it.

Cheers,
David

On 7 June 2010 00:20, Anders Jenbo <anders at jenbo.dk> wrote:
> Hallo David
>
> I am currently working on the chip-set that your board uses. So support is in progress. I have debug console running via serial and i am about a 1/3 in to getting the ram initialized. If you think you can help (time is the only real skill required) coding in the support you are more then welcome.
>
> You should get in contact with the flashrom developers to get support for your flash chip. Remove the AMI BIOS lable from the rom chip and read the fist number on the actual chip, should be some thing similar to these http://www.flashrom.org/Supported_hardware. You can find the flashrom developers at freenode.net #flashrom, or flashrom at flashrom.org.
>
> Good luck
> -Anders
>
>
> On Sun 06/06/10 19:17 , David Borg <borg.db at gmail.com> wrote:
>
>> Hey all, ?I was thinking of trying out coreboot on my old desktop pc
>> and would like to check whether the motherboard is supported, as it is
>> not in the list of supported motherboards.
>> System description:
>> Board vendor : GigabyteBoard name : GA-6VX7-4XCPU : Intel Celeron
>> 633MHz
>> Northbridge :?VT82C694X
>> (URL:?http://www.datasheetarchive.com/pdf-datasheets/Datasheets-23/DSA-446
>> 497.pdf[1]) Southbridge :?VT82C686A
>> (URL:?http://www.charmed.com/PDF/VT82C686A.pdf [2])
>>
>> The output of lspci -tvnn is attached (lscpi.txt). ?Note:-0b.0
>> ?Realtek Semiconductor Co., Ltd. RTL-8139/8139C/8139C+ [10ec:8139]
>>
>> Links:
>> ------
>> [1]
>> http://www.datasheetarchive.com/pdf-datasheets/Datasheets-23/DSA-446497.pdf
>> [2] http://www.charmed.com/PDF/VT82C686A.pdf
>> [3]
>> http://www.gigabyte.com/products/product-page.aspx?pid=1415&amp;dl=#sp
>>
>>
> ---- Msg sent via @Mail - http://atmail.com/
>



From rminnich at gmail.com  Mon Jun  7 02:45:49 2010
From: rminnich at gmail.com (ron minnich)
Date: Sun, 6 Jun 2010 17:45:49 -0700
Subject: [coreboot] AMD CAR quiz question
In-Reply-To: <4C0BEF4D.9080206@coresystems.de>
References: <4C0BB83C.2060608@assembler.cz> <4C0BBEAE.6060509@coresystems.de>
	<4C0BC1F7.4060703@assembler.cz> <4C0BC7E8.8040107@coresystems.de>
	<4C0BCCCD.9040007@assembler.cz> <4C0BEF4D.9080206@coresystems.de>
Message-ID: <AANLkTinywGqqUOcRJuyBX1k9ljw3MZ1N4XsEW5ug-OST@mail.gmail.com>

I've talked to Marc Jones about this several times over the years.. He
can confirm my memory. There is almost no win to parallelizing any of
the memory or PCI bus setup. Yes, it's supported in the code, kind of,
for some platforms, and maybe it works on some of them, but it's not
worth it and it really complicates things.

What is worth it, and we've measured this, is ECC scrubbing. We should
focus on that.

So the boot path:
BSP does all device tree, DRAM setup, sets up stacks and boot code for APs

APs are woken up and do what they are told, which is in many cases to
set themselves up and do ECC scrubbing.

In other words, Stefan is right (again :-)

ron



From anders at jenbo.dk  Mon Jun  7 02:51:51 2010
From: anders at jenbo.dk (Anders Jenbo)
Date: Mon, 7 Jun 2010 02:51:51 +0200
Subject: [coreboot] Mobo Support
Message-ID: <48372.1275871911@jenbo.dk>

Ok that is a Hynix chip, no other chips of that bran is currently supported, but the data-sheet is available here:
http://www.datasheetcatalog.org/datasheet/hynix/HY29F002TT-55.pdf

So it shouldn't be to much trouble to get it working.

It is a 256KB 5v PLCC32. I think it is parallel but you should check with the flashrom developers to confirm this.
You probably want to desolder it and solder on a PLCC32 socket and get a compatible spare to experiment with, so that you do not brick you board. If you are no skilled with a solder iron i highly recommend paying some one who is.

-Anders


On Mon 07/06/10 01:16 , David Borg <borg.db at gmail.com> wrote:

> Hey Anders, thanks for the reply.
> Good to hear that progress is being made =] I should have some free
> time available in the coming summer holidays, so I'll try to help
> out
> then.
> Regarding the rom chip, I got its number (HY29F002TC-90). I'll
> contact
> the flashrom developers about support for it.
> Cheers,
> David
> On 7 June 2010 00:20, Anders Jenbo  wrote:
> > Hallo David
> >
> > I am currently working on the chip-set that your board uses. So
> support is in progress. I have debug console running via serial and i
> am about a 1/3 in to getting the ram initialized. If you think you can
> help (time is the only real skill required) coding in the support you
> are more then welcome.
> >
> > You should get in contact with the flashrom developers to get
> support for your flash chip. Remove the AMI BIOS lable from the rom
> chip and read the fist number on the actual chip, should be some thing
> similar to these http://www.flashrom.org/Supported_hardware. You can
> find the flashrom developers at freenode.net #flashrom, or .
> >
> > Good luck
> > -Anders
> >
> >
> > On Sun 06/06/10 19:17 , David Borg  wrote:
> >
> >> Hey all,  I was thinking of trying out coreboot on my old desktop
> pc
> >> and would like to check whether the motherboard is supported, as
> it is
> >> not in the list of supported motherboards.
> >> System description:
> >> Board vendor : GigabyteBoard name : GA-6VX7-4XCPU : Intel Celeron
> >> 633MHz
> >> Northbridge : VT82C694X
> >> (URL:
> http://www.datasheetarchive.com/pdf-datasheets/Datasheets-23/DSA-446
> >> 497.pdf[1]) Southbridge : VT82C686A
> >> (URL: http://www.charmed.com/PDF/VT82C686A.pdf [2])
> >>
> >> The output of lspci -tvnn is attached (lscpi.txt).  Note:-0b.0
> >>  Realtek Semiconductor Co., Ltd. RTL-8139/8139C/8139C+
> [10ec:8139]
> >>
> >> Links:
> >> ------
> >> [1]
> >>
> http://www.datasheetarchive.com/pdf-datasheets/Datasheets-23/DSA-446497.pdf
> >> [2] http://www.charmed.com/PDF/VT82C686A.pdf
> >> [3]
> >>
> http://www.gigabyte.com/products/product-page.aspx?pid=1415&amp;dl=#sp
> >>
> >>
> > ---- Msg sent via @Mail - http://atmail.com/
> >
> 
> 
---- Msg sent via @Mail - http://atmail.com/



From peter at stuge.se  Mon Jun  7 06:20:01 2010
From: peter at stuge.se (Peter Stuge)
Date: Mon, 7 Jun 2010 06:20:01 +0200
Subject: [coreboot] Mobo Support
In-Reply-To: <48372.1275871911@jenbo.dk>
References: <48372.1275871911@jenbo.dk>
Message-ID: <20100607042002.12353.qmail@stuge.se>

Anders Jenbo wrote:
> Hynix chip
> http://www.datasheetcatalog.org/datasheet/hynix/HY29F002TT-55.pdf
> 
> It is a 256KB 5v PLCC32. I think it is parallel

Yep, that's right. LPC and FWH chips are always 3V3, and very rarely
smaller than 4Mbit or 512kbyte.


//Peter



From svn at coreboot.org  Mon Jun  7 10:29:37 2010
From: svn at coreboot.org (repository service)
Date: Mon, 07 Jun 2010 10:29:37 +0200
Subject: [coreboot] [commit] r5615 - in trunk/src: cpu/amd/car
	cpu/amd/model_lx cpu/via/car mainboard/digitallogic/msm586seg
Message-ID: <E1OLXiD-0001qP-F3@ra.coresystems.de>

Author: stepan
Date: Mon Jun  7 10:29:36 2010
New Revision: 5615
URL: https://tracker.coreboot.org/trac/coreboot/changeset/5615

Log:
replace outb -> port 0x80 with post_code() in some places.
Especially most _smbus functions misuse port 0x80 writes for delays.
Signed-off-by: Stefan Reinauer <stepan at coresystems.de>
Acked-by: Stefan Reinauer <stepan at coresystems.de>

Modified:
   trunk/src/cpu/amd/car/cache_as_ram.inc
   trunk/src/cpu/amd/model_lx/cache_as_ram.inc
   trunk/src/cpu/via/car/cache_as_ram.inc
   trunk/src/mainboard/digitallogic/msm586seg/romstage.c

Modified: trunk/src/cpu/amd/car/cache_as_ram.inc
==============================================================================
--- trunk/src/cpu/amd/car/cache_as_ram.inc	Sat Jun  5 12:03:08 2010	(r5614)
+++ trunk/src/cpu/amd/car/cache_as_ram.inc	Mon Jun  7 10:29:36 2010	(r5615)
@@ -49,9 +49,7 @@
 	/*for normal part %ebx already contain cpu_init_detected from fallback call */
 
 cache_as_ram_setup:
-
-	movb	$0xA0, %al
-	outb	%al, $0x80
+	post_code(0xa0)
 
 	/* enable SSE */
 	movl %cr4, %eax
@@ -284,8 +282,7 @@
 	orl	$(SYSCFG_MSR_MtrrVarDramEn | SYSCFG_MSR_MtrrFixDramEn), %eax
 	wrmsr
 
-	movb	$0xA1, %al
-	outb	%al, $0x80
+	post_code(0xa1)
 
 	/* enable cache */
 	movl	%cr0, %eax
@@ -301,8 +298,7 @@
 	jnc	CAR_FAM10_ap
 fam10_end_part1:
 
-	movb	$0xA2, %al
-	outb	%al, $0x80
+	post_code(0xa2)
 
 	/* Read the range with lodsl*/
 	cld
@@ -320,8 +316,7 @@
 	movl	$(CacheBase + CacheSize - GlobalVarSize), %eax
 	movl	%eax, %esp
 
-	movb	$0xA3, %al
-	outb	%al, $0x80
+	post_code(0xa3)
 
 	jmp	CAR_FAM10_ap_out
 CAR_FAM10_ap:
@@ -363,13 +358,11 @@
 	/* retrive init detected */
 	movl	%esi, %ebx
 
-	movb	$0xA4, %al
-	outb	%al, $0x80
+	post_code(0xa4)
 
 CAR_FAM10_ap_out:
 
-	movb	$0xA5, %al
-	outb	%al, $0x80
+	post_code(0xa5)
 
 	/* disable SSE */
 	movl %cr4, %eax
@@ -386,8 +379,7 @@
 	call	cache_as_ram_main
 	/* We will not go back */
 
-	movb	$0xAF, %al	/* Should never see this postcode */
-	outb	%al, $0x80
+	post_code(0xaf)		/* Should never see this postcode */
 
 fixed_mtrr_msr:
 	.long	0x250, 0x258, 0x259

Modified: trunk/src/cpu/amd/model_lx/cache_as_ram.inc
==============================================================================
--- trunk/src/cpu/amd/model_lx/cache_as_ram.inc	Sat Jun  5 12:03:08 2010	(r5614)
+++ trunk/src/cpu/amd/model_lx/cache_as_ram.inc	Mon Jun  7 10:29:36 2010	(r5615)
@@ -169,8 +169,8 @@
 	popl	%ecx
 	cmpl	%ecx, %edx
 	je	DCacheSetupGood
-	movb	$0xC5, %al
-	outb	%al, $0x80
+
+	post_code(0xc5)
 DCacheSetupBad:
 	hlt		/* issues */
 	jmp DCacheSetupBad

Modified: trunk/src/cpu/via/car/cache_as_ram.inc
==============================================================================
--- trunk/src/cpu/via/car/cache_as_ram.inc	Sat Jun  5 12:03:08 2010	(r5614)
+++ trunk/src/cpu/via/car/cache_as_ram.inc	Mon Jun  7 10:29:36 2010	(r5615)
@@ -152,8 +152,8 @@
 	movl	%eax, %esp
 
 #ifdef CARTEST
-testok:	movb $0x40,%al
-	outb %al, $0x80
+testok:	
+	post_code(0x40)
 	xorl	%edx, %edx
 	xorl	%eax, %eax
 	movl	$0x5c5c,%edx

Modified: trunk/src/mainboard/digitallogic/msm586seg/romstage.c
==============================================================================
--- trunk/src/mainboard/digitallogic/msm586seg/romstage.c	Sat Jun  5 12:03:08 2010	(r5614)
+++ trunk/src/mainboard/digitallogic/msm586seg/romstage.c	Mon Jun  7 10:29:36 2010	(r5615)
@@ -183,7 +183,7 @@
 
 	//			while(1)
 	print_err("STATIC MEM DONE\n");
-	outb(0xee, 0x80);
+	post_code(0xee);
 	print_err("loop forever ...\n");
 
 #if 0
@@ -231,13 +231,14 @@
 	    *dst = *src;
 	    //print_err(" dst is now "); print_err_hex32(*dst); print_err("\n");
 	    dst++, src++;
-	    outb((unsigned char)i, 0x80);
+	    post_code(i & 0xff);
 	  }
 	}
 	dumpmem();
-	outb(0, 0x80);
+	post_code(0x00);
+
 	print_err("loop forever\n");
-	outb(0xdd, 0x80);
+	post_code(0xdd);
         __asm__ volatile(
 			 "movl %0, %%edi\n\t"
 			 "jmp *%%edi\n\t"



From edwin_beasant at virtensys.com  Mon Jun  7 10:30:27 2010
From: edwin_beasant at virtensys.com (Edwin Beasant)
Date: Mon, 7 Jun 2010 09:30:27 +0100
Subject: [coreboot] [PATCH] Fix geode lx VSA loading
In-Reply-To: <AANLkTimtPS6fYcFmndu4TO_GLDZV8e7cr4vHOGu2TDeB@mail.gmail.com>
References: <208622BC47ED4B7F88606AF82C8056B8@chimp>
	<AANLkTimtPS6fYcFmndu4TO_GLDZV8e7cr4vHOGu2TDeB@mail.gmail.com>
Message-ID: <95EC52016CC5DE4896FD95FA7323A4DB152FFE43FD@mr-burns.exchange.virtensys.com>

Agreed - ax should be 0, it is only 0 in this case due to the argument passed in!
Before the segment setup, but after the _registers section, an xorl %ax, %al would be appropriate.
Thanks!
Edwin

-----Original Message-----
From: coreboot-bounces+edwin_beasant=virtensys.com at coreboot.org [mailto:coreboot-bounces+edwin_beasant=virtensys.com at coreboot.org] On Behalf Of ron minnich
Sent: 06 June 2010 05:50
To: Myles Watson
Cc: Stefan Reinauer; coreboot at coreboot.org
Subject: Re: [coreboot] [PATCH] Fix geode lx VSA loading

On Fri, Jun 4, 2010 at 9:53 AM, Myles Watson <mylesgw at gmail.com> wrote:

> mov $0, %ax

use the classic:
xorl %ax, %ax

ron

--
coreboot mailing list: coreboot at coreboot.org
http://www.coreboot.org/mailman/listinfo/coreboot



From stepan at coresystems.de  Mon Jun  7 10:38:02 2010
From: stepan at coresystems.de (Stefan Reinauer)
Date: Mon, 07 Jun 2010 10:38:02 +0200
Subject: [coreboot] [PATCH] Fix geode lx VSA loading
In-Reply-To: <95EC52016CC5DE4896FD95FA7323A4DB152FFE43FD@mr-burns.exchange.virtensys.com>
References: <208622BC47ED4B7F88606AF82C8056B8@chimp>	<AANLkTimtPS6fYcFmndu4TO_GLDZV8e7cr4vHOGu2TDeB@mail.gmail.com>
	<95EC52016CC5DE4896FD95FA7323A4DB152FFE43FD@mr-burns.exchange.virtensys.com>
Message-ID: <4C0CAFEA.9030300@coresystems.de>

On 6/7/10 10:30 AM, Edwin Beasant wrote:
> Agreed - ax should be 0, it is only 0 in this case due to the argument passed in!
> Before the segment setup, but after the _registers section, an xorl %ax, %al would be appropriate.
> Thanks!
> Edwin
>
>   

Did I miss one?

Stefan

> -----Original Message-----
> From: coreboot-bounces+edwin_beasant=virtensys.com at coreboot.org [mailto:coreboot-bounces+edwin_beasant=virtensys.com at coreboot.org] On Behalf Of ron minnich
> Sent: 06 June 2010 05:50
> To: Myles Watson
> Cc: Stefan Reinauer; coreboot at coreboot.org
> Subject: Re: [coreboot] [PATCH] Fix geode lx VSA loading
>
> On Fri, Jun 4, 2010 at 9:53 AM, Myles Watson <mylesgw at gmail.com> wrote:
>
>   
>> mov $0, %ax
>>     
> use the classic:
> xorl %ax, %ax
>
> ron
>
> --
> coreboot mailing list: coreboot at coreboot.org
> http://www.coreboot.org/mailman/listinfo/coreboot
>
>   




From edwin_beasant at virtensys.com  Mon Jun  7 10:57:28 2010
From: edwin_beasant at virtensys.com (Edwin Beasant)
Date: Mon, 7 Jun 2010 09:57:28 +0100
Subject: [coreboot] [PATCH] Fix geode lx VSA loading
In-Reply-To: <4C0CAFEA.9030300@coresystems.de>
References: <95EC52016CC5DE4896FD95FA7323A4DB152FFE43FD@mr-burns.exchange.virtensys.com>
	<4C0CAFEA.9030300@coresystems.de>
Message-ID: <95EC52016CC5DE4896FD95FA7323A4DB152FFE4402@mr-burns.exchange.virtensys.com>

Nope - I was just behind with my subversion revisions (merge problems on update, that will teach me...!)
Just seen the patch as finalised, thanks for that, looks good and should fix the issues seen.

I was going to refine it today, but you're way ahead of me :-)
Thanks,
Edwin

-----Original Message-----
From: coreboot-bounces at coreboot.org [mailto:coreboot-bounces at coreboot.org] On Behalf Of Stefan Reinauer
Sent: 07 June 2010 09:38
To: coreboot at coreboot.org
Subject: Re: [coreboot] [PATCH] Fix geode lx VSA loading

On 6/7/10 10:30 AM, Edwin Beasant wrote:
> Agreed - ax should be 0, it is only 0 in this case due to the argument passed in!
> Before the segment setup, but after the _registers section, an xorl %ax, %al would be appropriate.
> Thanks!
> Edwin
>
>

Did I miss one?

Stefan

> -----Original Message-----
> From: coreboot-bounces+edwin_beasant=virtensys.com at coreboot.org [mailto:coreboot-bounces+edwin_beasant=virtensys.com at coreboot.org] On Behalf Of ron minnich
> Sent: 06 June 2010 05:50
> To: Myles Watson
> Cc: Stefan Reinauer; coreboot at coreboot.org
> Subject: Re: [coreboot] [PATCH] Fix geode lx VSA loading
>
> On Fri, Jun 4, 2010 at 9:53 AM, Myles Watson <mylesgw at gmail.com> wrote:
>
>
>> mov $0, %ax
>>
> use the classic:
> xorl %ax, %ax
>
> ron
>
> --
> coreboot mailing list: coreboot at coreboot.org
> http://www.coreboot.org/mailman/listinfo/coreboot
>
>


--
coreboot mailing list: coreboot at coreboot.org
http://www.coreboot.org/mailman/listinfo/coreboot



From patrick at georgi-clan.de  Mon Jun  7 14:01:12 2010
From: patrick at georgi-clan.de (Patrick Georgi)
Date: Mon, 07 Jun 2010 14:01:12 +0200
Subject: [coreboot] [PATCH]Changes to libpayload's USB stack
Message-ID: <4C0CDF88.6030008@georgi-clan.de>

Hi,

attached patch
- avoids using the name "pid_t", which is used on unixoid systems
- moves controller specific data structures into private headers,
  to avoid conflicts between controller drivers
- factors out the USB PID ids, which are only exposed on UHCI. It's
  of not much use on the other controllers.

It requires a copy of uhci.h to uhci_private.h

Signed-off-by: Patrick Georgi <patrick.georgi at coresystems.de>
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: 20100607-1-usb-infrastructure.diff
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20100607/5a491dec/attachment.ksh>

From stefan.reinauer at coresystems.de  Mon Jun  7 14:09:38 2010
From: stefan.reinauer at coresystems.de (Stefan Reinauer)
Date: Mon, 07 Jun 2010 14:09:38 +0200
Subject: [coreboot] [PATCH]Changes to libpayload's USB stack
In-Reply-To: <4C0CDF88.6030008@georgi-clan.de>
References: <4C0CDF88.6030008@georgi-clan.de>
Message-ID: <4C0CE182.8080004@coresystems.de>

On 6/7/10 2:01 PM, Patrick Georgi wrote:
> Hi,
>
> attached patch
> - avoids using the name "pid_t", which is used on unixoid systems
> - moves controller specific data structures into private headers,
>   to avoid conflicts between controller drivers
> - factors out the USB PID ids, which are only exposed on UHCI. It's
>   of not much use on the other controllers.
>
> It requires a copy of uhci.h to uhci_private.h
>
> Signed-off-by: Patrick Georgi <patrick.georgi at coresystems.de>
>   
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




From darmawan.salihun at gmail.com  Mon Jun  7 15:01:28 2010
From: darmawan.salihun at gmail.com (Darmawan Salihun)
Date: Mon, 7 Jun 2010 20:01:28 +0700
Subject: [coreboot] Fwd:  SIS630ET coreboot challenge
In-Reply-To: <AANLkTikXWY4MNWGSnx8dAK4rgohnGjwC3BJ1uNnecSd4@mail.gmail.com>
References: <AANLkTikFxOKoGfkTAE0vdSpGLHAqZtso0bKKpccs5Dsi@mail.gmail.com>
	<4BFADBE1.8020007@coresystems.de>
	<AANLkTikBCEbCJiU9-UWEow6oz1QICeqHNSXS7hfqRaQK@mail.gmail.com>
	<4C030C99.8090107@coresystems.de>
	<AANLkTinP8T-89w2dgngDyhgjYVXVowlKBiHz_rRnlhms@mail.gmail.com>
	<4C0A0B8E.2040809@coresystems.de>
	<AANLkTikedXbbd8W99a0jmCj_mPbJiYngAHYnM92qhNWY@mail.gmail.com>
	<AANLkTikXWY4MNWGSnx8dAK4rgohnGjwC3BJ1uNnecSd4@mail.gmail.com>
Message-ID: <AANLkTila_Sb5Mgp_dK_mVLfvCdCYPDcfmw5B8WLkQRcL@mail.gmail.com>

---------- Forwarded message ----------
From: Darmawan Salihun <darmawan.salihun at gmail.com>
Date: Mon, 7 Jun 2010 20:00:08 +0700
Subject: Re: [coreboot] SIS630ET coreboot challenge
To: Tiago Marques <tiagomnm at gmail.com>

I've sent a datasheet in my posession to Keith. Haven't heard back
from him yet. Hopefully he can make use of it :-)

On 6/6/10, Tiago Marques <tiagomnm at gmail.com> wrote:
> Me? I wasn't after that.
>
> Best regards
>
> On Sat, Jun 5, 2010 at 9:32 AM, Stefan Reinauer <
> stefan.reinauer at coresystems.de> wrote:
>
>> On 6/5/10 5:15 AM, Tiago Marques wrote:
>> > See the attachment, doesn't look like something from a company that's
>> > alive and kicking. I know them since the SiS 730.
>> > Last time I heard they had some design win for a Core 2 chipset that I
>> > haven't seen in any product and started selling SiS branded SO-DIMMS :|
>> >
>> So you did contact them for data sheets?
>>
>> --
>> coreboot mailing list: coreboot at coreboot.org
>> http://www.coreboot.org/mailman/listinfo/coreboot
>>
>


-- 
--------------------------------------------------------------------
-= Human knowledge belongs to the world =-



-- 
--------------------------------------------------------------------
-= Human knowledge belongs to the world =-



From svn at coreboot.org  Mon Jun  7 15:58:18 2010
From: svn at coreboot.org (repository service)
Date: Mon, 07 Jun 2010 15:58:18 +0200
Subject: [coreboot] [commit] r5616 - in trunk/payloads/libpayload:
	drivers/usb include/usb
Message-ID: <E1OLcqI-0006GE-8h@ra.coresystems.de>

Author: oxygene
Date: Mon Jun  7 15:58:17 2010
New Revision: 5616
URL: https://tracker.coreboot.org/trac/coreboot/changeset/5616

Log:
Avoid using the name "pid_t", which is used on unixoid systems.
Move controller specific data structures into private headers,
to avoid conflicts between controller drivers.
Factor out the USB PID ids, which are only exposed on UHCI. It's
of not much use on the other controllers.

Signed-off-by: Patrick Georgi <patrick.georgi at coresystems.de>
Acked-by: Stefan Reinauer <stepan at coresystems.de>

Added:
   trunk/payloads/libpayload/drivers/usb/uhci_private.h
      - copied, changed from r5615, trunk/payloads/libpayload/drivers/usb/uhci.h
Modified:
   trunk/payloads/libpayload/drivers/usb/uhci.c
   trunk/payloads/libpayload/drivers/usb/uhci.h
   trunk/payloads/libpayload/drivers/usb/uhci_rh.c
   trunk/payloads/libpayload/include/usb/usb.h

Modified: trunk/payloads/libpayload/drivers/usb/uhci.c
==============================================================================
--- trunk/payloads/libpayload/drivers/usb/uhci.c	Mon Jun  7 10:29:36 2010	(r5615)
+++ trunk/payloads/libpayload/drivers/usb/uhci.c	Mon Jun  7 15:58:17 2010	(r5616)
@@ -29,16 +29,17 @@
 
 //#define USB_DEBUG
 
+#include <arch/virtual.h>
 #include <usb/usb.h>
 #include "uhci.h"
-#include <arch/virtual.h>
+#include "uhci_private.h"
 
 static void uhci_start (hci_t *controller);
 static void uhci_stop (hci_t *controller);
 static void uhci_reset (hci_t *controller);
 static void uhci_shutdown (hci_t *controller);
 static int uhci_bulk (endpoint_t *ep, int size, u8 *data, int finalize);
-static int uhci_control (usbdev_t *dev, pid_t dir, int drlen, void *devreq,
+static int uhci_control (usbdev_t *dev, direction_t dir, int drlen, void *devreq,
 			 int dalen, u8 *data);
 static void* uhci_create_intr_queue (endpoint_t *ep, int reqsize, int reqcount, int reqtiming);
 static void uhci_destroy_intr_queue (endpoint_t *ep, void *queue);
@@ -66,13 +67,13 @@
 	char td_value[3];
 	char *td_type;
 	switch (td->pid) {
-		case SETUP:
+		case UHCI_SETUP:
 			td_type="SETUP";
 			break;
-		case IN:
+		case UHCI_IN:
 			td_type="IN";
 			break;
-		case OUT:
+		case UHCI_OUT:
 			td_type="OUT";
 			break;
 		default:
@@ -296,7 +297,7 @@
 }
 
 static int
-uhci_control (usbdev_t *dev, pid_t dir, int drlen, void *devreq, int dalen,
+uhci_control (usbdev_t *dev, direction_t dir, int drlen, void *devreq, int dalen,
 	      unsigned char *data)
 {
 	int endp = 0;		/* this is control: always 0 */
@@ -316,7 +317,7 @@
 	tds[count].depth_first = 1;
 	tds[count].terminate = 1;
 
-	tds[0].pid = SETUP;
+	tds[0].pid = UHCI_SETUP;
 	tds[0].dev_addr = dev->address;
 	tds[0].endp = endp;
 	tds[0].maxlen = maxlen (drlen);
@@ -328,7 +329,11 @@
 
 	int toggle = 1;
 	for (i = 1; i < count; i++) {
-		tds[i].pid = dir;
+		switch (dir) {
+			case SETUP: tds[i].pid = UHCI_SETUP; break;
+			case IN:    tds[i].pid = UHCI_IN;    break;
+			case OUT:   tds[i].pid = UHCI_OUT;   break;
+		}
 		tds[i].dev_addr = dev->address;
 		tds[i].endp = endp;
 		tds[i].maxlen = maxlen (min (mlen, dalen));
@@ -342,7 +347,7 @@
 		data += mlen;
 	}
 
-	tds[count].pid = (dir == OUT) ? IN : OUT;
+	tds[count].pid = (dir == OUT) ? UHCI_IN : UHCI_OUT;
 	tds[count].dev_addr = dev->address;
 	tds[count].endp = endp;
 	tds[count].maxlen = maxlen (0);

Modified: trunk/payloads/libpayload/drivers/usb/uhci.h
==============================================================================
--- trunk/payloads/libpayload/drivers/usb/uhci.h	Mon Jun  7 10:29:36 2010	(r5615)
+++ trunk/payloads/libpayload/drivers/usb/uhci.h	Mon Jun  7 15:58:17 2010	(r5616)
@@ -33,90 +33,6 @@
 #include <pci.h>
 #include <usb/usb.h>
 
-typedef union {
-	struct {
-		unsigned long terminate:1;
-		unsigned long queue_head:1;
-		unsigned long:2;
-		unsigned long ptr_part:28;
-	};
-	u32 ptr;
-} __attribute__ ((packed)) flistp_t;
-
-typedef struct {
-	union {
-		struct {
-			unsigned long terminate:1;
-			unsigned long queue_head:1;
-			unsigned long depth_first:1;
-			unsigned long:29;
-		} __attribute__ ((packed));
-		u32 ptr;
-	} __attribute__ ((packed));
-
-	volatile unsigned long actlen:11;
-	volatile unsigned long:5;
-	union {
-		struct {
-			unsigned long:1;	// bit 0
-			unsigned long status_bitstuff_err:1;
-			unsigned long status_crc_err:1;
-			unsigned long status_nakrcvd:1;
-			unsigned long status_babble:1;
-			unsigned long status_databuf_err:1;
-			unsigned long status_stalled:1;
-			unsigned long status_active:1;	// bit 7
-		} __attribute__ ((packed));
-		unsigned char status;
-	} __attribute__ ((packed));
-	volatile unsigned long ioc:1;	/* interrupt on complete */
-	volatile unsigned long isochronous:1;
-	volatile unsigned long lowspeed:1;
-	volatile unsigned long counter:2;
-	volatile unsigned long shortpck:1;
-	volatile unsigned long:2;
-
-	unsigned long pid:8;
-	unsigned long dev_addr:7;
-	unsigned long endp:4;
-	unsigned long data_toggle:1;
-	unsigned long:1;
-	unsigned long maxlen:11;
-
-	u32 bufptr;
-
-} __attribute__ ((packed))
-     td_t;
-
-     typedef struct {
-	     flistp_t headlinkptr;
-	     volatile flistp_t elementlinkptr;
-     } __attribute__ ((packed))
-     qh_t;
-
-     typedef enum { USBCMD = 0, USBSTS = 2, USBINTR = 4, FRNUM =
-		     6, FLBASEADD = 8, SOFMOD = 0xc, PORTSC1 = 0x10, PORTSC2 =
-		     0x12
-     } usbreg;
-
-     void uhci_reg_write32 (hci_t *ctrl, usbreg reg, u32 value);
-     u32 uhci_reg_read32 (hci_t *ctrl, usbreg reg);
-     void uhci_reg_write16 (hci_t *ctrl, usbreg reg, u16 value);
-     u16 uhci_reg_read16 (hci_t *ctrl, usbreg reg);
-     void uhci_reg_write8 (hci_t *ctrl, usbreg reg, u8 value);
-     u8 uhci_reg_read8 (hci_t *ctrl, usbreg reg);
-     void uhci_reg_mask32 (hci_t *ctrl, usbreg reg, u32 andmask, u32 ormask);
-     void uhci_reg_mask16 (hci_t *ctrl, usbreg reg, u16 andmask, u16 ormask);
-     void uhci_reg_mask8 (hci_t *ctrl, usbreg reg, u8 andmask, u8 ormask);
-
-     typedef struct uhci {
-	     flistp_t *framelistptr;
-	     qh_t *qh_prei, *qh_intr, *qh_data, *qh_last;
-	     usbdev_t *roothub;
-     } uhci_t;
-
-#define UHCI_INST(controller) ((uhci_t*)((controller)->instance))
-
      hci_t *uhci_init (pcidev_t addr);
 
      void uhci_rh_init (usbdev_t *dev);

Copied and modified: trunk/payloads/libpayload/drivers/usb/uhci_private.h (from r5615, trunk/payloads/libpayload/drivers/usb/uhci.h)
==============================================================================
--- trunk/payloads/libpayload/drivers/usb/uhci.h	Mon Jun  7 10:29:36 2010	(r5615, copy source)
+++ trunk/payloads/libpayload/drivers/usb/uhci_private.h	Mon Jun  7 15:58:17 2010	(r5616)
@@ -27,11 +27,10 @@
  * SUCH DAMAGE.
  */
 
-#ifndef __UHCI_H
-#define __UHCI_H
+#ifndef __UHCI_PRIVATE_H
+#define __UHCI_PRIVATE_H
 
-#include <pci.h>
-#include <usb/usb.h>
+typedef enum { UHCI_SETUP = 0x2d, UHCI_IN = 0x69, UHCI_OUT = 0xe1 } uhci_pid_t;
 
 typedef union {
 	struct {
@@ -117,8 +116,4 @@
 
 #define UHCI_INST(controller) ((uhci_t*)((controller)->instance))
 
-     hci_t *uhci_init (pcidev_t addr);
-
-     void uhci_rh_init (usbdev_t *dev);
-
 #endif

Modified: trunk/payloads/libpayload/drivers/usb/uhci_rh.c
==============================================================================
--- trunk/payloads/libpayload/drivers/usb/uhci_rh.c	Mon Jun  7 10:29:36 2010	(r5615)
+++ trunk/payloads/libpayload/drivers/usb/uhci_rh.c	Mon Jun  7 15:58:17 2010	(r5616)
@@ -31,6 +31,7 @@
 
 #include <libpayload.h>
 #include "uhci.h"
+#include "uhci_private.h"
 
 typedef struct {
 	int port[2];

Modified: trunk/payloads/libpayload/include/usb/usb.h
==============================================================================
--- trunk/payloads/libpayload/include/usb/usb.h	Mon Jun  7 10:29:36 2010	(r5615)
+++ trunk/payloads/libpayload/include/usb/usb.h	Mon Jun  7 15:58:17 2010	(r5616)
@@ -80,14 +80,14 @@
 struct usbdev;
 typedef struct usbdev usbdev_t;
 
-typedef enum { SETUP = 0x2d, IN = 0x69, OUT = 0xe1 } pid_t;
+typedef enum { SETUP, IN, OUT } direction_t;
 typedef enum { CONTROL = 0, ISOCHRONOUS = 1, BULK = 2, INTERRUPT = 3
 } endpoint_type;
 
 typedef struct {
 	usbdev_t *dev;
 	int endpoint;
-	pid_t direction;
+	direction_t direction;
 	int toggle;
 	int maxpacketsize;
 	endpoint_type type;
@@ -121,7 +121,7 @@
 	void (*reset) (hci_t *controller);
 	void (*shutdown) (hci_t *controller);
 	int (*bulk) (endpoint_t *ep, int size, u8 *data, int finalize);
-	int (*control) (usbdev_t *dev, pid_t pid, int dr_length,
+	int (*control) (usbdev_t *dev, direction_t pid, int dr_length,
 			void *devreq, int data_length, u8 *data);
 	void* (*create_intr_queue) (endpoint_t *ep, int reqsize, int reqcount, int reqtiming);
 	void (*destroy_intr_queue) (endpoint_t *ep, void *queue);



From svn at coreboot.org  Mon Jun  7 16:00:02 2010
From: svn at coreboot.org (coreboot tracker)
Date: Mon, 07 Jun 2010 16:00:02 +0200
Subject: [coreboot] Trac reminder: list of new ticket(s)
Message-ID: <E1OLcry-0001MO-Uu@ra.coresystems.de>

An HTML attachment was scrubbed...
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20100607/904b8d9a/attachment.html>

From svn at coreboot.org  Mon Jun  7 16:09:46 2010
From: svn at coreboot.org (repository service)
Date: Mon, 07 Jun 2010 16:09:46 +0200
Subject: [coreboot] [commit] r5617 - trunk/src/arch/i386
Message-ID: <E1OLd1O-0004O0-OH@ra.coresystems.de>

Author: oxygene
Date: Mon Jun  7 16:09:41 2010
New Revision: 5617
URL: https://tracker.coreboot.org/trac/coreboot/changeset/5617

Log:
Make sure VSA is linked as ELF32 for i386 (instead of whatever the compiler considers native).

Signed-off-by: Patrick Georgi <patrick.georgi at coresystems.de>
Acked-by: Patrick Georgi <patrick.georgi at coresystems.de>

Modified:
   trunk/src/arch/i386/Makefile.inc

Modified: trunk/src/arch/i386/Makefile.inc
==============================================================================
--- trunk/src/arch/i386/Makefile.inc	Mon Jun  7 15:58:17 2010	(r5616)
+++ trunk/src/arch/i386/Makefile.inc	Mon Jun  7 16:09:41 2010	(r5617)
@@ -58,7 +58,7 @@
 ifeq ($(CONFIG_GEODE_VSA_FILE),y)
 	@printf "    VSA        $(CONFIG_VSA_FILENAME)\n"
 	$(OBJCOPY) --set-start 0x20 --adjust-vma 0x60000 -I binary -O elf32-i386 -B i386 $(CONFIG_VSA_FILENAME) $(obj)/vsa.o
-	$(LD) -e 0x60020 --section-start .data=0x60000 $(obj)/vsa.o -o $(obj)/vsa.elf
+	$(LD) -m elf_i386 -e 0x60020 --section-start .data=0x60000 $(obj)/vsa.o -o $(obj)/vsa.elf
 	$(CBFSTOOL) $@.tmp add-stage $(obj)/vsa.elf vsa
 endif
 	mv $@.tmp $@



From svn at coreboot.org  Mon Jun  7 16:10:55 2010
From: svn at coreboot.org (coreboot)
Date: Mon, 07 Jun 2010 14:10:55 -0000
Subject: [coreboot] #165: Geode VSA re-parsing to elf fails on 64 bit
 platforms
In-Reply-To: <063.c71f8433ce0f07bd94755266a552fc67@coreboot.org>
References: <063.c71f8433ce0f07bd94755266a552fc67@coreboot.org>
Message-ID: <072.8b7dd47dfc91447fc2dc382352055423@coreboot.org>

#165: Geode VSA re-parsing to elf fails on 64 bit platforms
-------------------------------------------+--------------------------------
   Reporter:  edwin_beasant@?              |          Owner:  stepan@?             
       Type:  defect                       |         Status:  closed               
   Priority:  major                        |      Milestone:  Going mainstream     
  Component:  coreboot                     |     Resolution:  fixed                
   Keywords:  VSA Geode ld cbfs            |   Dependencies:                       
Patchstatus:  patch needs review           |  
-------------------------------------------+--------------------------------
Changes (by oxygene):

  * status:  new => closed
  * resolution:  => fixed


Comment:

 it's the wrong patch, but I got feedback that my fix in #5617 is okay.

-- 
Ticket URL: <https://tracker.coreboot.org/trac/coreboot/ticket/165#comment:1>
coreboot <http://www.coreboot.org/>


From anders at jenbo.dk  Mon Jun  7 16:32:55 2010
From: anders at jenbo.dk (Anders Jenbo)
Date: Mon, 7 Jun 2010 16:32:55 +0200
Subject: [coreboot] Fwd:  SIS630ET coreboot challenge
Message-ID: <56838.1275921175@jenbo.dk>


To bad i just dumped a couple of SIS boards because i never expected them to get supported :)

-Anders



On Mon 07/06/10 15:01 , Darmawan Salihun <darmawan.salihun at gmail.com> wrote:

> ---------- Forwarded message ----------
> From: Darmawan Salihun 
> Date: Mon, 7 Jun 2010 20:00:08 +0700
> Subject: Re: [coreboot] SIS630ET coreboot challenge
> To: Tiago Marques 
> I've sent a datasheet in my posession to Keith. Haven't heard back
> from him yet. Hopefully he can make use of it :-)
> On 6/6/10, Tiago Marques  wrote:
> > Me? I wasn't after that.
> >
> > Best regards
> >
> > On Sat, Jun 5, 2010 at 9:32 AM, Stefan Reinauer  > wrote:
> >
> >> On 6/5/10 5:15 AM, Tiago Marques wrote:
> >> > See the attachment, doesn't look like something from a company
> that's
> >> > alive and kicking. I know them since the SiS 730.
> >> > Last time I heard they had some design win for a Core 2 chipset
> that I
> >> > haven't seen in any product and started selling SiS branded
> SO-DIMMS :|
> >> >
> >> So you did contact them for data sheets?
> >>
> >> --
> >> coreboot mailing list: 
> >> http://www.coreboot.org/mailman/listinfo/coreboot
> >>
> >
> -- 
> --------------------------------------------------------------------
> -= Human knowledge belongs to the world =-
> -- 
> --------------------------------------------------------------------
> -= Human knowledge belongs to the world =-
> -- 
> coreboot mailing list: 
> http://www.coreboot.org/mailman/listinfo/coreboot
> 
> 
---- Msg sent via @Mail - http://atmail.com/



From edwin_beasant at virtensys.com  Mon Jun  7 16:44:57 2010
From: edwin_beasant at virtensys.com (Edwin Beasant)
Date: Mon, 7 Jun 2010 15:44:57 +0100
Subject: [coreboot] [PATCH] Geode 5536 resources mis-allocated,
 causes lack of interrupts.
Message-ID: <95EC52016CC5DE4896FD95FA7323A4DB152FFE4446@mr-burns.exchange.virtensys.com>

This patch extends the reserved resources for the cs5536 to avoid the excluded range as detailed on p104 of the cs5536 Device Data Book.


Signed-off by: Edwin Beasant edwin_beasant at virtensys.com<mailto:edwin_beasant at virtensys.com>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20100607/dcc55149/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: geode-5536-resources-fixup.patch
Type: application/octet-stream
Size: 445 bytes
Desc: geode-5536-resources-fixup.patch
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20100607/dcc55149/attachment.obj>

From mylesgw at gmail.com  Mon Jun  7 17:05:46 2010
From: mylesgw at gmail.com (Myles Watson)
Date: Mon, 7 Jun 2010 09:05:46 -0600
Subject: [coreboot] [PATCH] Geode 5536 resources mis-allocated,
	causes 	lack of interrupts.
In-Reply-To: <95EC52016CC5DE4896FD95FA7323A4DB152FFE4446@mr-burns.exchange.virtensys.com>
References: <95EC52016CC5DE4896FD95FA7323A4DB152FFE4446@mr-burns.exchange.virtensys.com>
Message-ID: <AANLkTinYMY_vx1xpwfAPHGVcisPNJOMzXLlVqMPRKYwG@mail.gmail.com>

On Mon, Jun 7, 2010 at 8:44 AM, Edwin Beasant
<edwin_beasant at virtensys.com> wrote:
> This patch extends the reserved resources for the cs5536 to avoid the
> excluded range as detailed on p104 of the cs5536 Device Data Book.
Should we make it a round 0x1000?  What about the cs5535?

Thanks,
Myles



From svn at coreboot.org  Mon Jun  7 17:39:04 2010
From: svn at coreboot.org (repository service)
Date: Mon, 07 Jun 2010 17:39:04 +0200
Subject: [coreboot] [commit] r5618 - in trunk/src/southbridge/amd: cs5535
	cs5536
Message-ID: <E1OLePo-0001PZ-RE@ra.coresystems.de>

Author: myles
Date: Mon Jun  7 17:39:04 2010
New Revision: 5618
URL: https://tracker.coreboot.org/trac/coreboot/changeset/5618

Log:
This patch extends the reserved resources for the cs5536 to avoid the excluded
range as detailed on p104 of the cs5536 Device Data Book.

Extended to 0x1000.  Same change for cs5535.

Signed-off by: Edwin Beasant edwin_beasant at virtensys.com
Signed-off-by: Myles Watson <mylesgw at gmail.com>
Acked-by: Myles Watson <mylesgw at gmail.com>

Modified:
   trunk/src/southbridge/amd/cs5535/cs5535.c
   trunk/src/southbridge/amd/cs5536/cs5536.c

Modified: trunk/src/southbridge/amd/cs5535/cs5535.c
==============================================================================
--- trunk/src/southbridge/amd/cs5535/cs5535.c	Mon Jun  7 16:09:41 2010	(r5617)
+++ trunk/src/southbridge/amd/cs5535/cs5535.c	Mon Jun  7 17:39:04 2010	(r5618)
@@ -71,13 +71,13 @@
 
 static void cs5535_read_resources(device_t dev)
 {
-	struct resource* res;
+	struct resource *res;
 
 	pci_dev_read_resources(dev);
 
 	res = new_resource(dev, 1);
 	res->base = 0x0UL;
-	res->size = 0x400UL;
+	res->size = 0x1000UL;
 	res->limit = 0xffffUL;
 	res->flags = IORESOURCE_IO | IORESOURCE_ASSIGNED | IORESOURCE_FIXED;
 
@@ -89,7 +89,7 @@
 
 static void cs5535_pci_dev_enable_resources(device_t dev)
 {
-	printk(BIOS_SPEW, "cs5535.c: %s()\n", __func__);
+	printk(BIOS_DEBUG, "%s()\n", __func__);
 	pci_dev_enable_resources(dev);
 	enable_childrens_resources(dev);
 }

Modified: trunk/src/southbridge/amd/cs5536/cs5536.c
==============================================================================
--- trunk/src/southbridge/amd/cs5536/cs5536.c	Mon Jun  7 16:09:41 2010	(r5617)
+++ trunk/src/southbridge/amd/cs5536/cs5536.c	Mon Jun  7 17:39:04 2010	(r5618)
@@ -651,10 +651,9 @@
 
 	res = new_resource(dev, 1);
 	res->base = 0x0UL;
-	res->size = 0x400UL;
+	res->size = 0x1000UL;
 	res->limit = 0xffffUL;
-	res->flags = IORESOURCE_IO |
-		     IORESOURCE_ASSIGNED | IORESOURCE_FIXED;
+	res->flags = IORESOURCE_IO | IORESOURCE_ASSIGNED | IORESOURCE_FIXED;
 
 	res = new_resource(dev, 3); /* IOAPIC */
 	res->base = 0xfec00000;
@@ -670,7 +669,7 @@
 
 static void cs5536_pci_dev_enable_resources(device_t dev)
 {
-	printk(BIOS_ERR, "cs5536: %s()\n", __func__);
+	printk(BIOS_DEBUG, "%s()\n", __func__);
 	pci_dev_enable_resources(dev);
 	enable_childrens_resources(dev);
 }



From mylesgw at gmail.com  Mon Jun  7 17:40:35 2010
From: mylesgw at gmail.com (Myles Watson)
Date: Mon, 7 Jun 2010 09:40:35 -0600
Subject: [coreboot] [PATCH] Geode 5536 resources mis-allocated,
	causes 	lack of interrupts.
In-Reply-To: <95EC52016CC5DE4896FD95FA7323A4DB152FFE4446@mr-burns.exchange.virtensys.com>
References: <95EC52016CC5DE4896FD95FA7323A4DB152FFE4446@mr-burns.exchange.virtensys.com>
Message-ID: <AANLkTik70MMMKmG-szzlBH-9SbXOdv0DpIi7fu7jrOtQ@mail.gmail.com>

On Mon, Jun 7, 2010 at 8:44 AM, Edwin Beasant
<edwin_beasant at virtensys.com> wrote:
> This patch extends the reserved resources for the cs5536 to avoid the
> excluded range as detailed on p104 of the cs5536 Device Data Book.
>
> Signed-off by: Edwin Beasant edwin_beasant at virtensys.com
Rev 5618.

Thanks,
Myles



From mylesgw at gmail.com  Mon Jun  7 18:00:47 2010
From: mylesgw at gmail.com (Myles Watson)
Date: Mon, 7 Jun 2010 10:00:47 -0600
Subject: [coreboot] [PATCH] remove duplicate code
Message-ID: <AANLkTikPvJz8KX16RPACmS7Y88_xb74WZmzg-a70RtCI@mail.gmail.com>

cardbus_scan_bridge is identical to pci_scan_bridge (since
PCI_PRIMARY_BUS == PCI_CB_PRIMARY_BUS.)  Remove it.  Fix a typo while
there.

Signed-off-by: Myles Watson <mylesgw at gmail.com>

Thanks,
Myles
-------------- next part --------------
A non-text attachment was scrubbed...
Name: dedup.diff
Type: text/x-patch
Size: 3206 bytes
Desc: not available
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20100607/0cf668ad/attachment.diff>

From buurin at gmail.com  Mon Jun  7 18:17:17 2010
From: buurin at gmail.com (Keith Hui)
Date: Mon, 7 Jun 2010 12:17:17 -0400
Subject: [coreboot] coreboot Digest, Vol 64, Issue 23
In-Reply-To: <mailman.801.1275919214.3514.coreboot@coreboot.org>
References: <mailman.801.1275919214.3514.coreboot@coreboot.org>
Message-ID: <AANLkTilcK5EAtDsvSq9vCITHdcSLiNKL6yvZumVYgM64@mail.gmail.com>

Yes, I have it. Thanks to all who responded. Looks like there is only
two versions of the datasheet out, but I have a intact version now.

It may not be enough to help me write from scratch, but will help me
understand the factory BIOS's ways. Now, I have a 630ET that also have
Tualatin support, and my board's bootblock is already conditionally
setting some "reserved" bits when a Tualatin chip is installed.
There's also some flipping of GPIO4 and GPIO7 (thanks to the
datasheets now I know) for unknown purposes. There's also nothing
about RAM sizing algorithm. There is also the same SRAM chip as P3B-F
has which flashrom doesn't work with. Even better, there will be
board-specific enable needed when it comes time to do flashrom. Oh
yeah, the MAC address for the built in LAN is in the flash.

Good news is, IDE controller for many SIS chipsets (630 included) are
all identified as "5513" meaning I should be able to bring in
something from other SiS chipset(s) already in the tree.

Also, how should the code be organized? 630 series is a single chip.
The main other separate chips are IT8705 for super I/O, and CMI8738
for audio that I don't need to worry about for now. Question is - All
in src/northbridge?

But before I go any further, I have to reinstall my main
HTPC-cum-broadband-router that have been having problems for months.
:-D

As for my board, after I soldered on a PLCC socket, it has to return
to active service as the backup router while I reinstall the other
machine (above).

And there is also the lingering problem of the SCSI chip on my P2B-LS
board still not working properly, and there's also ACPI support/SMI
handler for same. So it will be a while.

Thanks
Keith

> From: Darmawan Salihun <darmawan.salihun at gmail.com>
> Date: Mon, 7 Jun 2010 20:00:08 +0700
> Subject: Re: [coreboot] SIS630ET coreboot challenge
> To: Tiago Marques <tiagomnm at gmail.com>
>
> I've sent a datasheet in my posession to Keith. Haven't heard back
> from him yet. Hopefully he can make use of it :-)
>
> On 6/6/10, Tiago Marques <tiagomnm at gmail.com> wrote:
>> Me? I wasn't after that.
>>
>> Best regards
>>
>> On Sat, Jun 5, 2010 at 9:32 AM, Stefan Reinauer <
>> stefan.reinauer at coresystems.de> wrote:
>>
>>> On 6/5/10 5:15 AM, Tiago Marques wrote:
>>> > See the attachment, doesn't look like something from a company that's
>>> > alive and kicking. I know them since the SiS 730.
>>> > Last time I heard they had some design win for a Core 2 chipset that I
>>> > haven't seen in any product and started selling SiS branded SO-DIMMS :|
>>> >
>>> So you did contact them for data sheets?
>>>
>>> --
>>> coreboot mailing list: coreboot at coreboot.org
>>> http://www.coreboot.org/mailman/listinfo/coreboot
>>>
>>



From joe at settoplinux.org  Mon Jun  7 18:39:31 2010
From: joe at settoplinux.org (Joseph Smith)
Date: Mon, 07 Jun 2010 12:39:31 -0400
Subject: [coreboot] Fwd:  SIS630ET coreboot challenge
In-Reply-To: <56838.1275921175@jenbo.dk>
References: <56838.1275921175@jenbo.dk>
Message-ID: <ce2eab4aa934df80b17476165781a90b@imap.1and1.com>




On Mon, 7 Jun 2010 16:32:55 +0200, Anders Jenbo <anders at jenbo.dk> wrote:
> 
> To bad i just dumped a couple of SIS boards because i never expected them
> to get supported :)
> 
I got a couple of SIS 630's kicking around, I would be glad to do some
testing :-)

-- 
Thanks,
Joseph Smith
Set-Top-Linux
www.settoplinux.org




From peter at stuge.se  Mon Jun  7 18:40:50 2010
From: peter at stuge.se (Peter Stuge)
Date: Mon, 7 Jun 2010 18:40:50 +0200
Subject: [coreboot] [PATCH] remove duplicate code
In-Reply-To: <AANLkTikPvJz8KX16RPACmS7Y88_xb74WZmzg-a70RtCI@mail.gmail.com>
References: <AANLkTikPvJz8KX16RPACmS7Y88_xb74WZmzg-a70RtCI@mail.gmail.com>
Message-ID: <20100607164050.19596.qmail@stuge.se>

Myles Watson wrote:
> cardbus_scan_bridge is identical to pci_scan_bridge (since
> PCI_PRIMARY_BUS == PCI_CB_PRIMARY_BUS.)  Remove it.  Fix a typo while
> there.
> 
> Signed-off-by: Myles Watson <mylesgw at gmail.com>

Acked-by: Peter Stuge <peter at stuge.se>



From svn at coreboot.org  Mon Jun  7 18:51:12 2010
From: svn at coreboot.org (repository service)
Date: Mon, 07 Jun 2010 18:51:12 +0200
Subject: [coreboot] [commit] r5619 - trunk/src/devices
Message-ID: <E1OLfXc-0008Pf-8O@ra.coresystems.de>

Author: myles
Date: Mon Jun  7 18:51:11 2010
New Revision: 5619
URL: https://tracker.coreboot.org/trac/coreboot/changeset/5619

Log:
cardbus_scan_bridge is identical to pci_scan_bridge
(since PCI_PRIMARY_BUS == PCI_CB_PRIMARY_BUS.)  Remove it.
Fix a typo while there.

Signed-off-by: Myles Watson <mylesgw at gmail.com>
Acked-by: Peter Stuge <peter at stuge.se>

Modified:
   trunk/src/devices/cardbus_device.c

Modified: trunk/src/devices/cardbus_device.c
==============================================================================
--- trunk/src/devices/cardbus_device.c	Mon Jun  7 17:39:04 2010	(r5618)
+++ trunk/src/devices/cardbus_device.c	Mon Jun  7 18:51:11 2010	(r5619)
@@ -41,9 +41,9 @@
 	device_t dev, resource_t moving, resource_t min_size,
 	unsigned index, unsigned long type)
 {
-	/* Initiliaze the constraints on the current bus */
+	/* Initialize the constraints on the current bus. */
 	struct resource *resource;
-	resource = 0;
+	resource = NULL;
 	if (moving) {
 		unsigned long gran;
 		resource_t step;
@@ -51,7 +51,7 @@
 		resource->size = 0;
 		gran = 0;
 		step = 1;
-		while((moving & step) == 0) {
+		while ((moving & step) == 0) {
 			gran += 1;
 			step <<= 1;
 		}
@@ -174,78 +174,12 @@
 	enable_childrens_resources(dev);
 }
 
-unsigned int cardbus_scan_bus(struct bus *bus,
-	unsigned min_devfn, unsigned max_devfn,
-	unsigned int max)
-{
-	return pci_scan_bus(bus, min_devfn, max_devfn, max);
-}
-
-
-unsigned int cardbus_scan_bridge(device_t dev, unsigned int max)
-{
-	struct bus *bus;
-	uint32_t buses;
-	uint16_t cr;
-
-	printk(BIOS_SPEW, "%s for %s\n", __func__, dev_path(dev));
-
-	bus = &dev->link[0];
-	bus->dev = dev;
-	dev->links = 1;
-
-	/* Set up the primary, secondary and subordinate bus numbers. We have
-	 * no idea how many buses are behind this bridge yet, so we set the
-	 * subordinate bus number to 0xff for the moment.
-	 */
-	bus->secondary = ++max;
-	bus->subordinate = 0xff;
-
-	/* Clear all status bits and turn off memory, I/O and master enables. */
-	cr = pci_read_config16(dev, PCI_COMMAND);
-	pci_write_config16(dev, PCI_COMMAND, 0x0000);
-	pci_write_config16(dev, PCI_STATUS, 0xffff);
-
-	/*
-	 * Read the existing primary/secondary/subordinate bus
-	 * number configuration.
-	 */
-	buses = pci_read_config32(dev, PCI_CB_PRIMARY_BUS);
-
-	/* Configure the bus numbers for this bridge: the configuration
-	 * transactions will not be propagated by the bridge if it is not
-	 * correctly configured.
-	 */
-	buses &= 0xff000000;
-	buses |= (((unsigned int) (dev->bus->secondary) << 0) |
-		((unsigned int) (bus->secondary) << 8) |
-		((unsigned int) (bus->subordinate) << 16));
-	pci_write_config32(dev, PCI_CB_PRIMARY_BUS, buses);
-
-	/* Now we can scan all subordinate buses
-	 * i.e. the bus behind the bridge.
-	 */
-	max = cardbus_scan_bus(bus, 0x00, 0xff, max);
-
-	/* We know the number of buses behind this bridge. Set the subordinate
-	 * bus number to its real value.
-	 */
-	bus->subordinate = max;
-	buses = (buses & 0xff00ffff) |
-		((unsigned int) (bus->subordinate) << 16);
-	pci_write_config32(dev, PCI_CB_PRIMARY_BUS, buses);
-	pci_write_config16(dev, PCI_COMMAND, cr);
-
-	printk(BIOS_SPEW, "%s returns max %d\n", __func__, max);
-	return max;
-}
-
 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,
+	.scan_bus	  = pci_scan_bridge,
 	.enable           = 0,
 	.reset_bus        = pci_bus_reset,
 };



From mylesgw at gmail.com  Mon Jun  7 18:51:41 2010
From: mylesgw at gmail.com (Myles Watson)
Date: Mon, 7 Jun 2010 10:51:41 -0600
Subject: [coreboot] [PATCH] remove duplicate code
In-Reply-To: <20100607164050.19596.qmail@stuge.se>
References: <AANLkTikPvJz8KX16RPACmS7Y88_xb74WZmzg-a70RtCI@mail.gmail.com>
	<20100607164050.19596.qmail@stuge.se>
Message-ID: <AANLkTilAGDFUAV2khtukylEXfvGBD5PEaveNtRMV8lPa@mail.gmail.com>

On Mon, Jun 7, 2010 at 10:40 AM, Peter Stuge <peter at stuge.se> wrote:
> Myles Watson wrote:
>> cardbus_scan_bridge is identical to pci_scan_bridge (since
>> PCI_PRIMARY_BUS == PCI_CB_PRIMARY_BUS.) ?Remove it. ?Fix a typo while
>> there.
>>
>> Signed-off-by: Myles Watson <mylesgw at gmail.com>
>
> Acked-by: Peter Stuge <peter at stuge.se>
Rev 5619.

Thanks,
Myles



From svn at coreboot.org  Mon Jun  7 19:05:07 2010
From: svn at coreboot.org (repository service)
Date: Mon, 07 Jun 2010 19:05:07 +0200
Subject: [coreboot] build service results for r5619
Message-ID: <E1OLfl5-0002Ol-VS@ra.coresystems.de>

Dear coreboot readers!

This is the automatic build system of coreboot.

The developer "myles" checked in revision 5619 to
the coreboot repository. This caused the following 
changes:

Change Log:
cardbus_scan_bridge is identical to pci_scan_bridge
(since PCI_PRIMARY_BUS == PCI_CB_PRIMARY_BUS.)  Remove it.
Fix a typo while there.

Signed-off-by: Myles Watson <mylesgw at gmail.com>
Acked-by: Peter Stuge <peter at stuge.se>


Build Log:
Compilation of getac:p470 has been broken
See the error log at http://qa.coreboot.org/log_buildbrd.php?revision=5619&device=p470&vendor=getac&num=2
Compilation of roda:rk886ex has been broken
See the error log at http://qa.coreboot.org/log_buildbrd.php?revision=5619&device=rk886ex&vendor=roda&num=2
Compilation of via:epia-m has been broken
See the error log at http://qa.coreboot.org/log_buildbrd.php?revision=5619&device=epia-m&vendor=via&num=2


If something broke during this checkin please be a pain 
in myles'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  Mon Jun  7 19:12:58 2010
From: svn at coreboot.org (repository service)
Date: Mon, 07 Jun 2010 19:12:58 +0200
Subject: [coreboot] [commit] r5620 - in trunk/src: include/device
	southbridge/ricoh/rl5c476 southbridge/ti/pci7420
	southbridge/ti/pcixx12
Message-ID: <E1OLfsg-0003O5-F3@ra.coresystems.de>

Author: myles
Date: Mon Jun  7 19:12:57 2010
New Revision: 5620
URL: https://tracker.coreboot.org/trac/coreboot/changeset/5620

Log:
Remove the rest of cardbus_scan_bus.

Signed-off-by: Myles Watson <mylesgw at gmail.com>
Acked-by: Myles Watson <mylesgw at gmail.com>

Modified:
   trunk/src/include/device/cardbus.h
   trunk/src/southbridge/ricoh/rl5c476/rl5c476.c
   trunk/src/southbridge/ti/pci7420/pci7420_cardbus.c
   trunk/src/southbridge/ti/pcixx12/pcixx12.c

Modified: trunk/src/include/device/cardbus.h
==============================================================================
--- trunk/src/include/device/cardbus.h	Mon Jun  7 18:51:11 2010	(r5619)
+++ trunk/src/include/device/cardbus.h	Mon Jun  7 19:12:57 2010	(r5620)
@@ -3,9 +3,6 @@
 /* (c) 2005 Linux Networx GPL see COPYING for details */
 
 void cardbus_read_resources(device_t dev);
-unsigned int cardbus_scan_bus(struct bus *bus,
-	unsigned min_devfn, unsigned max_devfn, unsigned int max);
-unsigned int cardbus_scan_bridge(device_t dev, unsigned int max);
 void cardbus_enable_resources(device_t dev);
 
 extern struct device_operations default_cardbus_ops_bus;

Modified: trunk/src/southbridge/ricoh/rl5c476/rl5c476.c
==============================================================================
--- trunk/src/southbridge/ricoh/rl5c476/rl5c476.c	Mon Jun  7 18:51:11 2010	(r5619)
+++ trunk/src/southbridge/ricoh/rl5c476/rl5c476.c	Mon Jun  7 19:12:57 2010	(r5620)
@@ -203,7 +203,7 @@
 	.set_resources    = rl5c476_set_resources,
 	.enable_resources = cardbus_enable_resources,
 	.init             = rl5c476_init,
-	.scan_bus         = cardbus_scan_bridge,
+	.scan_bus         = pci_scan_bridge,
 };
 
 static const struct pci_driver ricoh_rl5c476_driver __pci_driver = {

Modified: trunk/src/southbridge/ti/pci7420/pci7420_cardbus.c
==============================================================================
--- trunk/src/southbridge/ti/pci7420/pci7420_cardbus.c	Mon Jun  7 18:51:11 2010	(r5619)
+++ trunk/src/southbridge/ti/pci7420/pci7420_cardbus.c	Mon Jun  7 19:12:57 2010	(r5620)
@@ -102,7 +102,7 @@
 	.set_resources    = pci7420_cardbus_set_resources,
 	.enable_resources = cardbus_enable_resources,
 	.init             = pci7420_cardbus_init,
-	.scan_bus         = cardbus_scan_bridge,
+	.scan_bus         = pci_scan_bridge,
 };
 
 static const struct pci_driver ti_pci7420_driver __pci_driver = {

Modified: trunk/src/southbridge/ti/pcixx12/pcixx12.c
==============================================================================
--- trunk/src/southbridge/ti/pcixx12/pcixx12.c	Mon Jun  7 18:51:11 2010	(r5619)
+++ trunk/src/southbridge/ti/pcixx12/pcixx12.c	Mon Jun  7 19:12:57 2010	(r5620)
@@ -52,7 +52,7 @@
 	.set_resources    = pcixx12_set_resources,
 	.enable_resources = cardbus_enable_resources,
 	.init             = pcixx12_init,
-	.scan_bus         = cardbus_scan_bridge,
+	.scan_bus         = pci_scan_bridge,
 };
 
 static const struct pci_driver ti_pcixx12_driver __pci_driver = {



From svn at coreboot.org  Mon Jun  7 19:25:43 2010
From: svn at coreboot.org (repository service)
Date: Mon, 07 Jun 2010 19:25:43 +0200
Subject: [coreboot] build service results for r5620
Message-ID: <E1OLg51-0005o0-Hf@ra.coresystems.de>

Dear coreboot readers!

This is the automatic build system of coreboot.

The developer "myles" checked in revision 5620 to
the coreboot repository. This caused the following 
changes:

Change Log:
Remove the rest of cardbus_scan_bus.

Signed-off-by: Myles Watson <mylesgw at gmail.com>
Acked-by: Myles Watson <mylesgw at gmail.com>


Build Log:
Compilation of getac:p470 has been fixed
Compilation of roda:rk886ex has been fixed
Compilation of via:epia-m has been fixed


If something broke during this checkin please be a pain 
in myles'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 mylesgw at gmail.com  Mon Jun  7 20:20:33 2010
From: mylesgw at gmail.com (Myles Watson)
Date: Mon, 7 Jun 2010 12:20:33 -0600
Subject: [coreboot] [commit] r5609 - in trunk/src: drivers drivers/dec
	drivers/dec/21143 drivers/ti drivers/ti/pcmcia-cardbus
	include/device mainboard/nokia/ip530
In-Reply-To: <20100605211129.29623.qmail@stuge.se>
References: <E1OKcxo-0006Dc-1Q@ra.coresystems.de>
	<20100605211129.29623.qmail@stuge.se>
Message-ID: <AANLkTikHFSFUx7jKTaSVCdZaJnRVNoJt62Kk9Mjzw5Np@mail.gmail.com>

On Sat, Jun 5, 2010 at 3:11 PM, Peter Stuge <peter at stuge.se> wrote:
> I have several issues with this commit. I pointed out at least one of
> them already very long ago!

The attached patch addresses some of the issues.

It mostly moves drivers to southbridge/ti/ and southbridge/dec/

Signed-off-by: Myles Watson <mylesgw at gmail.com>

>> +++ trunk/src/include/device/pci_ids.h ? ? ? ?Fri Jun ?4 21:53:55 2010 ? ? ? ?(r5609)
>> @@ -696,6 +696,7 @@
>> ?#define PCI_DEVICE_ID_TI_4410 ? ? ? ? ? ? ? ?0xac41
>> ?#define PCI_DEVICE_ID_TI_4451 ? ? ? ? ? ? ? ?0xac42
>> ?#define PCI_DEVICE_ID_TI_1420 ? ? ? ? ? ? ? ?0xac51
>> +#define PCI_DEVICE_ID_TI_1520 ? ? ? ? ? ? ? ?0xAC55
>
> Somewhat minor, but please use lower case for a-f to look like other
> values in the file.
Unfortunately, this is not consistent in that file, but I changed it
so at least it's consistent within TI values.

>
>> @@ -1741,6 +1742,10 @@
>> ?#define PCI_DEVICE_ID_CCD_B00C ? ? ? ? ? ? ? 0xb00c
>> ?#define PCI_DEVICE_ID_CCD_B100 ? ? ? ? ? ? ? 0xb100
>>
>> +#define PCI_VENDOR_ID_NOKIA ? ? ? ? ?0x13B8 ?// Nokia Telecommunications oy
>> +#define PCI_VENDOR_ID_NOKIA_WIRELESS 0x1603 ?// Nokia Wireless Communications
>> +#define PCI_VENDOR_ID_NOKIA_HOME ? ? 0x1622 ?// Nokia Home Communications
Removed.

Thanks,
Myles
-------------- next part --------------
A non-text attachment was scrubbed...
Name: nokia.diff
Type: text/x-patch
Size: 19343 bytes
Desc: not available
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20100607/80edcfa0/attachment.diff>

From svn at coreboot.org  Mon Jun  7 22:15:55 2010
From: svn at coreboot.org (repository service)
Date: Mon, 07 Jun 2010 22:15:55 +0200
Subject: [coreboot] [commit] r5621 - in trunk/src: drivers drivers/dec
	drivers/ti include/device mainboard/nokia/ip530 southbridge
	southbridge/dec southbridge/dec/21143 southbridge/ti
	southbridge/ti/pci1x2x
Message-ID: <E1OLijj-0008DI-Eu@ra.coresystems.de>

Author: myles
Date: Mon Jun  7 22:15:54 2010
New Revision: 5621
URL: https://tracker.coreboot.org/trac/coreboot/changeset/5621

Log:
Fix some of Peter's suggestions for the Nokia IP530.

Signed-off-by: Myles Watson <mylesgw at gmail.com>
Acked-by: Myles Watson <mylesgw at gmail.com>

Added:
   trunk/src/southbridge/dec/
   trunk/src/southbridge/dec/21143/   (props changed)
      - copied from r5619, trunk/src/drivers/dec/21143/
   trunk/src/southbridge/dec/21143/21143.c   (contents, props changed)
      - copied, changed from r5619, trunk/src/drivers/dec/21143/21143pd.c
   trunk/src/southbridge/dec/21143/Kconfig
   trunk/src/southbridge/dec/Kconfig
   trunk/src/southbridge/dec/Makefile.inc
   trunk/src/southbridge/ti/pci1x2x/
   trunk/src/southbridge/ti/pci1x2x/Kconfig
   trunk/src/southbridge/ti/pci1x2x/Makefile.inc   (contents, props changed)
      - copied, changed from r5619, trunk/src/drivers/ti/pcmcia-cardbus/Makefile.inc
   trunk/src/southbridge/ti/pci1x2x/pci1x2x.c   (contents, props changed)
      - copied, changed from r5619, trunk/src/drivers/ti/pcmcia-cardbus/ti-pcmcia-cardbus.c
Deleted:
   trunk/src/drivers/dec/
   trunk/src/drivers/ti/
   trunk/src/southbridge/dec/21143/21143pd.c
Modified:
   trunk/src/drivers/Kconfig
   trunk/src/include/device/pci_ids.h
   trunk/src/mainboard/nokia/ip530/Kconfig
   trunk/src/southbridge/Kconfig
   trunk/src/southbridge/Makefile.inc
   trunk/src/southbridge/dec/21143/Makefile.inc
   trunk/src/southbridge/ti/Kconfig
   trunk/src/southbridge/ti/Makefile.inc

Modified: trunk/src/drivers/Kconfig
==============================================================================
--- trunk/src/drivers/Kconfig	Mon Jun  7 19:12:57 2010	(r5620)
+++ trunk/src/drivers/Kconfig	Mon Jun  7 22:15:54 2010	(r5621)
@@ -23,21 +23,3 @@
 	help
 	It sets PCI class to IDE compatible native mode, allowing
 	SeaBIOS, FILO etc... to boot from it.
-
-config DRIVERS_TI
-	bool
-
-config DRIVERS_TI_PCI1225
-	select DRIVERS_TI
-	bool
-
-config DRIVERS_TI_PCI1420
-	select DRIVERS_TI
-	bool
-
-config DRIVERS_TI_PCI1520
-	select DRIVERS_TI
-	bool
-
-config DRIVERS_DEC_21143PD
-	bool

Modified: trunk/src/include/device/pci_ids.h
==============================================================================
--- trunk/src/include/device/pci_ids.h	Mon Jun  7 19:12:57 2010	(r5620)
+++ trunk/src/include/device/pci_ids.h	Mon Jun  7 22:15:54 2010	(r5621)
@@ -696,7 +696,7 @@
 #define PCI_DEVICE_ID_TI_4410		0xac41
 #define PCI_DEVICE_ID_TI_4451		0xac42
 #define PCI_DEVICE_ID_TI_1420		0xac51
-#define PCI_DEVICE_ID_TI_1520		0xAC55
+#define PCI_DEVICE_ID_TI_1520		0xac55
 
 #define PCI_VENDOR_ID_SONY		0x104d
 #define PCI_DEVICE_ID_SONY_CXD3222	0x8039
@@ -1742,9 +1742,9 @@
 #define PCI_DEVICE_ID_CCD_B00C		0xb00c
 #define PCI_DEVICE_ID_CCD_B100		0xb100
 
-#define PCI_VENDOR_ID_NOKIA		0x13B8	// Nokia Telecommunications oy
-#define PCI_VENDOR_ID_NOKIA_WIRELESS	0x1603	// Nokia Wireless Communications
-#define PCI_VENDOR_ID_NOKIA_HOME	0x1622	// Nokia Home Communications
+#define PCI_VENDOR_ID_NOKIA		0x13B8
+#define PCI_VENDOR_ID_NOKIA_WIRELESS	0x1603
+#define PCI_VENDOR_ID_NOKIA_HOME	0x1622
 
 #define PCI_VENDOR_ID_3WARE		0x13C1
 #define PCI_DEVICE_ID_3WARE_1000	0x1000

Modified: trunk/src/mainboard/nokia/ip530/Kconfig
==============================================================================
--- trunk/src/mainboard/nokia/ip530/Kconfig	Mon Jun  7 19:12:57 2010	(r5620)
+++ trunk/src/mainboard/nokia/ip530/Kconfig	Mon Jun  7 22:15:54 2010	(r5621)
@@ -24,8 +24,8 @@
 	select NORTHBRIDGE_INTEL_I440BX
 	select SOUTHBRIDGE_INTEL_I82371EB
 	select SUPERIO_SMSC_SMSCSUPERIO
-	select DRIVERS_TI_PCI1225
-	select DRIVERS_DEC_21143PD
+	select SOUTHBRIDGE_TI_PCI1X2X
+	select SOUTHBRIDGE_DEC_21143
 	select BOARD_ROMSIZE_KB_256
 	select ROMCC
 	select PIRQ_ROUTE

Modified: trunk/src/southbridge/Kconfig
==============================================================================
--- trunk/src/southbridge/Kconfig	Mon Jun  7 19:12:57 2010	(r5620)
+++ trunk/src/southbridge/Kconfig	Mon Jun  7 22:15:54 2010	(r5621)
@@ -1,5 +1,6 @@
 source src/southbridge/amd/Kconfig
 source src/southbridge/broadcom/Kconfig
+source src/southbridge/dec/Kconfig
 source src/southbridge/intel/Kconfig
 source src/southbridge/nvidia/Kconfig
 source src/southbridge/ricoh/Kconfig

Modified: trunk/src/southbridge/Makefile.inc
==============================================================================
--- trunk/src/southbridge/Makefile.inc	Mon Jun  7 19:12:57 2010	(r5620)
+++ trunk/src/southbridge/Makefile.inc	Mon Jun  7 22:15:54 2010	(r5621)
@@ -1,5 +1,6 @@
 subdirs-y += amd
 subdirs-y += broadcom
+subdirs-y += dec
 subdirs-y += intel
 subdirs-y += nvidia
 subdirs-y += ricoh

Copied and modified: trunk/src/southbridge/dec/21143/21143.c (from r5619, trunk/src/drivers/dec/21143/21143pd.c)
==============================================================================
--- trunk/src/drivers/dec/21143/21143pd.c	Mon Jun  7 18:51:11 2010	(r5619, copy source)
+++ trunk/src/southbridge/dec/21143/21143.c	Mon Jun  7 22:15:54 2010	(r5621)
@@ -40,9 +40,9 @@
 /**
  * This driver take the values from Kconfig and load them in the registers
  */
-static void dec_21143pd_enable( device_t dev )
+static void dec_21143_enable( device_t dev )
 {
-	printk( BIOS_DEBUG, "Init of DECchip 21143PD/TD Kconfig style\n");
+	printk( BIOS_DEBUG, "Init of DECchip 21143 Kconfig style\n");
 	// Command and Status Configuration Register (Offset 0x04)
 	pci_write_config32( dev, 0x04, CONFIG_DEC21143_COMMAND_AND_STATUS_CONFIGURATION );
 	printk( BIOS_DEBUG, "0x04 = %08x (07 01 80 02)\n", pci_read_config32(dev, 0x04) );
@@ -55,16 +55,16 @@
 	return;
 }
 
-static struct device_operations dec_21143pd_ops  = {
+static struct device_operations dec_21143_ops  = {
         .read_resources   = pci_dev_read_resources,
         .set_resources    = pci_dev_set_resources,
         .enable_resources = pci_dev_enable_resources,
-        .init             = dec_21143pd_enable,
+        .init             = dec_21143_enable,
         .scan_bus         = 0,
 };
 
-static const struct pci_driver dec_21143pd_driver __pci_driver = {
-        .ops    = &dec_21143pd_ops,
+static const struct pci_driver dec_21143_driver __pci_driver = {
+        .ops    = &dec_21143_ops,
         .vendor = PCI_VENDOR_ID_DEC,
         .device = PCI_DEVICE_ID_DEC_21142,
 };

Added: trunk/src/southbridge/dec/21143/Kconfig
==============================================================================
--- /dev/null	00:00:00 1970	(empty, because file is newly added)
+++ trunk/src/southbridge/dec/21143/Kconfig	Mon Jun  7 22:15:54 2010	(r5621)
@@ -0,0 +1,2 @@
+config SOUTHBRIDGE_DEC_21143
+	bool

Modified: trunk/src/southbridge/dec/21143/Makefile.inc
==============================================================================
--- trunk/src/drivers/dec/21143/Makefile.inc	Mon Jun  7 18:51:11 2010	(r5619)
+++ trunk/src/southbridge/dec/21143/Makefile.inc	Mon Jun  7 22:15:54 2010	(r5621)
@@ -1,2 +1,2 @@
-driver-$(CONFIG_DRIVERS_DEC_21143PD) += 21143pd.o
+driver-y += 21143.o
 

Added: trunk/src/southbridge/dec/Kconfig
==============================================================================
--- /dev/null	00:00:00 1970	(empty, because file is newly added)
+++ trunk/src/southbridge/dec/Kconfig	Mon Jun  7 22:15:54 2010	(r5621)
@@ -0,0 +1 @@
+source src/southbridge/dec/21143/Kconfig

Added: trunk/src/southbridge/dec/Makefile.inc
==============================================================================
--- /dev/null	00:00:00 1970	(empty, because file is newly added)
+++ trunk/src/southbridge/dec/Makefile.inc	Mon Jun  7 22:15:54 2010	(r5621)
@@ -0,0 +1 @@
+subdirs-$(CONFIG_SOUTHBRIDGE_DEC_21143) += 21143

Modified: trunk/src/southbridge/ti/Kconfig
==============================================================================
--- trunk/src/southbridge/ti/Kconfig	Mon Jun  7 19:12:57 2010	(r5620)
+++ trunk/src/southbridge/ti/Kconfig	Mon Jun  7 22:15:54 2010	(r5621)
@@ -19,3 +19,4 @@
 
 source src/southbridge/ti/pci7420/Kconfig
 source src/southbridge/ti/pcixx12/Kconfig
+source src/southbridge/ti/pci1x2x/Kconfig

Modified: trunk/src/southbridge/ti/Makefile.inc
==============================================================================
--- trunk/src/southbridge/ti/Makefile.inc	Mon Jun  7 19:12:57 2010	(r5620)
+++ trunk/src/southbridge/ti/Makefile.inc	Mon Jun  7 22:15:54 2010	(r5621)
@@ -19,3 +19,4 @@
 
 subdirs-$(CONFIG_SOUTHBRIDGE_TI_PCI7420) += pci7420
 subdirs-$(CONFIG_SOUTHBRIDGE_TI_PCIXX12) += pcixx12
+subdirs-$(CONFIG_SOUTHBRIDGE_TI_PCI1X2X) += pci1x2x

Added: trunk/src/southbridge/ti/pci1x2x/Kconfig
==============================================================================
--- /dev/null	00:00:00 1970	(empty, because file is newly added)
+++ trunk/src/southbridge/ti/pci1x2x/Kconfig	Mon Jun  7 22:15:54 2010	(r5621)
@@ -0,0 +1,2 @@
+config SOUTHBRIDGE_TI_PCI1X2X
+	bool

Copied and modified: trunk/src/southbridge/ti/pci1x2x/Makefile.inc (from r5619, trunk/src/drivers/ti/pcmcia-cardbus/Makefile.inc)
==============================================================================
--- trunk/src/drivers/ti/pcmcia-cardbus/Makefile.inc	Mon Jun  7 18:51:11 2010	(r5619, copy source)
+++ trunk/src/southbridge/ti/pci1x2x/Makefile.inc	Mon Jun  7 22:15:54 2010	(r5621)
@@ -1,2 +1 @@
-driver-$(CONFIG_DRIVERS_TI) += ti-pcmcia-cardbus.o
-
+driver-$(CONFIG_SOUTHBRIDGE_TI_PCI1X2X) += pci1x2x.o

Copied and modified: trunk/src/southbridge/ti/pci1x2x/pci1x2x.c (from r5619, trunk/src/drivers/ti/pcmcia-cardbus/ti-pcmcia-cardbus.c)
==============================================================================
--- trunk/src/drivers/ti/pcmcia-cardbus/ti-pcmcia-cardbus.c	Mon Jun  7 18:51:11 2010	(r5619, copy source)
+++ trunk/src/southbridge/ti/pci1x2x/pci1x2x.c	Mon Jun  7 22:15:54 2010	(r5621)
@@ -65,27 +65,20 @@
 	.scan_bus         = 0,
 };
 
-#ifdef CONFIG_DRIVERS_TI_PCI1225
 static const struct pci_driver ti_pci1225_driver __pci_driver = {
         .ops    = &ti_pci1x2y_ops,
         .vendor = PCI_VENDOR_ID_TI,
         .device = PCI_DEVICE_ID_TI_1225,
 };
 
-#endif
-#ifdef CONFIG_DRIVERS_TI_PCI1420
 static const struct pci_driver ti_pci1420_driver __pci_driver = {
         .ops    = &ti_pci1x2y_ops,
         .vendor = PCI_VENDOR_ID_TI,
         .device = PCI_DEVICE_ID_TI_1420,
 };
-#endif
-#ifdef CONFIG_DRIVERS_TI_PCI1520
+
 static const struct pci_driver ti_pci1520_driver __pci_driver = {
         .ops    = &ti_pci1x2y_ops,
         .vendor = PCI_VENDOR_ID_TI,
         .device = PCI_DEVICE_ID_TI_1420,
 };
-#endif
-
-



From njacobs8 at hetnet.nl  Tue Jun  8 00:53:14 2010
From: njacobs8 at hetnet.nl (Nils)
Date: Tue, 8 Jun 2010 00:53:14 +0200
Subject: [coreboot]  [PATCH] Wyse S50 RAMBASE 0x100000 fix
Message-ID: <201006080053.14260.njacobs8@hetnet.nl>

This patch fixes RAMBASE 0x100000 for Wyse S50.
I think that the problem was that extended memory was not setup early enough.
This patch is boot tested on r5621.

Signed-off-by: Nils Jacobs <njacobs8 at hetnet.nl>

Thanks,Nils.





From njacobs8 at hetnet.nl  Tue Jun  8 00:55:58 2010
From: njacobs8 at hetnet.nl (Nils)
Date: Tue, 8 Jun 2010 00:55:58 +0200
Subject: [coreboot]  [PATCH] Wyse S50 RAMBASE 0x100000 fix
Message-ID: <201006080055.58504.njacobs8@hetnet.nl>

This patch fixes RAMBASE 0x100000 for Wyse S50.
I think that the problem was that extended memory was not setup early enough.
This patch is boot tested on r5621.

Signed-off-by: Nils Jacobs <njacobs8 at hetnet.nl>

And now with patch attached,sorry.

Thanks,Nils.


-------------- next part --------------
A non-text attachment was scrubbed...
Name: geode_rambase_fix.patch
Type: text/x-patch
Size: 1710 bytes
Desc: not available
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20100608/8e01cf9e/attachment.patch>

From joe at settoplinux.org  Tue Jun  8 04:22:38 2010
From: joe at settoplinux.org (Joseph Smith)
Date: Mon, 07 Jun 2010 22:22:38 -0400
Subject: [coreboot] Booting UHCI with FILO
Message-ID: <4C0DA96E.5040700@settoplinux.org>

Hello,
Trying to boot Fedora 12 Live USB. FILO loads the Kernel just fine and 
then Loads the initrd just fine. Then:

Jumping to entry point...

Out of memory while allocating output buffer

  -- System halted


Any Ideas?

-- 
Thanks,
Joseph Smith
Set-Top-Linux
www.settoplinux.org



From svn at coreboot.org  Tue Jun  8 07:57:06 2010
From: svn at coreboot.org (repository service)
Date: Tue, 08 Jun 2010 07:57:06 +0200
Subject: [coreboot] [commit] r5622 - trunk/src/northbridge/amd/gx2
Message-ID: <E1OLroA-0000sw-4D@ra.coresystems.de>

Author: oxygene
Date: Tue Jun  8 07:57:05 2010
New Revision: 5622
URL: https://tracker.coreboot.org/trac/coreboot/changeset/5622

Log:
Fix auto-mangled comments (trivial)

Signed-off-by: Patrick Georgi <patrick.georgi at coresystems.de>
Acked-by: Patrick Georgi <patrick.georgi at coresystems.de>

Modified:
   trunk/src/northbridge/amd/gx2/northbridgeinit.c

Modified: trunk/src/northbridge/amd/gx2/northbridgeinit.c
==============================================================================
--- trunk/src/northbridge/amd/gx2/northbridgeinit.c	Mon Jun  7 22:15:54 2010	(r5621)
+++ trunk/src/northbridge/amd/gx2/northbridgeinit.c	Tue Jun  8 07:57:05 2010	(r5622)
@@ -37,9 +37,9 @@
 	{.desc_name=MSR_GLIU1_BASE1,.desc_type=  BM,.hi=  MSR_GL0 + 0x0,.lo=  0x0FFF80},	/*  0-7FFFF to MC*/
 	{.desc_name=MSR_GLIU1_BASE2,.desc_type=  BM,.hi=  MSR_GL0 + 0x0,.lo= (0x80 << 20) +0x0FFFE0},	/*  80000-9ffff to Mc*/
 	{.desc_name=MSR_GLIU1_SHADOW,.desc_type=  SC_SHADOW,.hi=  MSR_GL0 + 0x0,.lo=  0x03}, /*  C0000-Fffff split to MC and PCI (sub decode)*/
-	{.desc_name=MSR_GLIU1_SYSMEM,.desc_type=  R_SYSMEM,.hi=  MSR_GL0,.lo=  0x0},		/*  Cat0xc and fix dynamicly.*/
-	{.desc_name=MSR_GLIU1_DMM,.desc_type=  BM_DMM,.hi=  MSR_GL0,.lo=  0x0},			/*  Cat0xc and fix dynamicly.*/
-	{.desc_name=MSR_GLIU1_SMM,.desc_type=  BM_SMM,.hi=  MSR_GL0,.lo=  0x0},			/*  Cat0xc and fix dynamicly.*/
+	{.desc_name=MSR_GLIU1_SYSMEM,.desc_type=  R_SYSMEM,.hi=  MSR_GL0,.lo=  0x0},		/*  Catch and fix dynamicly.*/
+	{.desc_name=MSR_GLIU1_DMM,.desc_type=  BM_DMM,.hi=  MSR_GL0,.lo=  0x0},			/*  Catch and fix dynamicly.*/
+	{.desc_name=MSR_GLIU1_SMM,.desc_type=  BM_SMM,.hi=  MSR_GL0,.lo=  0x0},			/*  Catch and fix dynamicly.*/
 	{.desc_name=GLIU1_GLD_MSR_COH,.desc_type= OTHER,.hi= 0x0,.lo= GL1_GLIU0},
 	{.desc_name=MSR_GLIU1_FPU_TRAP,.desc_type=  SCIO,.hi=  (GL1_GLCP << 29) + 0x0,.lo=  0x033000F0},	/*  FooGlue FPU 0xF0*/
 	{.desc_name=GL_END,.desc_type= GL_END,.hi= 0x0,.lo= 0x0},



From patrick at georgi-clan.de  Tue Jun  8 08:01:23 2010
From: patrick at georgi-clan.de (Patrick Georgi)
Date: Tue, 08 Jun 2010 08:01:23 +0200
Subject: [coreboot] [PATCH] Wyse S50 RAMBASE 0x100000 fix
In-Reply-To: <201006080055.58504.njacobs8@hetnet.nl>
References: <201006080055.58504.njacobs8@hetnet.nl>
Message-ID: <4C0DDCB3.1080703@georgi-clan.de>

Am 08.06.2010 00:55, schrieb Nils:
> This patch fixes RAMBASE 0x100000 for Wyse S50.
> I think that the problem was that extended memory was not setup early enough.
Looks plausible.
Is there a reason why this function is mainboard specific? It seems to
me that this, including your change, should be part of the chipset code.

> This patch is boot tested on r5621.
> 
> Signed-off-by: Nils Jacobs <njacobs8 at hetnet.nl>
Acked-by: Patrick Georgi <patrick.georgi at coresystems.de>



From patrick at georgi-clan.de  Tue Jun  8 08:06:19 2010
From: patrick at georgi-clan.de (Patrick Georgi)
Date: Tue, 08 Jun 2010 08:06:19 +0200
Subject: [coreboot] Booting UHCI with FILO
In-Reply-To: <4C0DA96E.5040700@settoplinux.org>
References: <4C0DA96E.5040700@settoplinux.org>
Message-ID: <4C0DDDDB.8050001@georgi-clan.de>

Am 08.06.2010 04:22, schrieb Joseph Smith:
> Hello,
> Trying to boot Fedora 12 Live USB. FILO loads the Kernel just fine and
> then Loads the initrd just fine. Then:
> 
> Jumping to entry point...
> 
> Out of memory while allocating output buffer
> 
>  -- System halted
> 
> 
> Any Ideas?
That error message is in the linux decompression code and appears when
it can't malloc the necessary memory (32kb), or if it's asked to
decompress to address 0.

I guess that this either means that linux doesn't find usable memory
tables, or that some parts of the linux bootblock data structure are not
filled in correctly.
The latter can happen when the kernel version is too new for the used
linux loader.


Patrick



From gregg.drwho8 at gmail.com  Tue Jun  8 08:12:28 2010
From: gregg.drwho8 at gmail.com (Gregg Levine)
Date: Tue, 8 Jun 2010 02:12:28 -0400
Subject: [coreboot] Set top box update
Message-ID: <AANLkTik-oz9g55oOoL380xqt8BunC_9VFNJdc-TldRJM@mail.gmail.com>

Hello!
Amazon tells me that there are now two people selling their Akimbo
boxes. Perhaps I'll definitely buy one.

And Joe here is the linked page which contains a reference to the STB
kit from Intel:
http://cerberus.teamhackaday.com/?p=3

It turns out that it comes up right below the description for the
device. It seems the only thing nonstandard about it is the crappy
BIOS that Akimbo insisted on.

-----
Gregg C Levine gregg.drwho8 at gmail.com
"This signature fought the Time Wars, time and again."



From stepan at coresystems.de  Tue Jun  8 10:54:00 2010
From: stepan at coresystems.de (Stefan Reinauer)
Date: Tue, 08 Jun 2010 10:54:00 +0200
Subject: [coreboot] [PATCH] Wyse S50 RAMBASE 0x100000 fix
In-Reply-To: <201006080055.58504.njacobs8@hetnet.nl>
References: <201006080055.58504.njacobs8@hetnet.nl>
Message-ID: <4C0E0528.4000001@coresystems.de>

On 6/8/10 12:55 AM, Nils wrote:
> +	__builtin_wrmsr(MSR_GLIU1_SYSMEM, 0x6bf00100, 0x2000001f); /*	0x100000-0x1F6BF000 */
>   
Why 1F6BF000 ?

Stefan



From anton.kochkov at gmail.com  Tue Jun  8 10:55:00 2010
From: anton.kochkov at gmail.com (=?UTF-8?B?0JDQvdGC0L7QvSDQmtC+0YfQutC+0LI=?=)
Date: Tue, 8 Jun 2010 12:55:00 +0400
Subject: [coreboot] superiotool: Add support to IT85xx series
Message-ID: <AANLkTinSlmXnUSbc1NEzXkJhJ_HqO-cIg6y2U6T5hLq7@mail.gmail.com>

Add support to IT85xx series
Signed-off-by: Anton Kochkov <anton.kochkov at gmail.com>
---
-------------- next part --------------
A non-text attachment was scrubbed...
Name: ite_it85xx.patch
Type: text/x-diff
Size: 5457 bytes
Desc: not available
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20100608/2a88cbe1/attachment.bin>

From anton.kochkov at gmail.com  Tue Jun  8 11:58:47 2010
From: anton.kochkov at gmail.com (=?UTF-8?B?0JDQvdGC0L7QvSDQmtC+0YfQutC+0LI=?=)
Date: Tue, 8 Jun 2010 13:58:47 +0400
Subject: [coreboot] ectool: Add support to extended commands
Message-ID: <AANLkTimNv5rYGOYunWloDkKfzs_PE0TAblwIlje2ymcY@mail.gmail.com>

Add support to extended EC series
Signed-off-by: Anton Kochkov <anton.kochkov at gmail.com>
---
-------------- next part --------------
A non-text attachment was scrubbed...
Name: ec_ext.patch
Type: text/x-diff
Size: 4327 bytes
Desc: not available
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20100608/44b54a78/attachment.bin>

From joe at settoplinux.org  Tue Jun  8 12:47:59 2010
From: joe at settoplinux.org (Joseph Smith)
Date: Tue, 08 Jun 2010 06:47:59 -0400
Subject: [coreboot] Booting UHCI with FILO
In-Reply-To: <4C0DDDDB.8050001@georgi-clan.de>
References: <4C0DA96E.5040700@settoplinux.org>
	<4C0DDDDB.8050001@georgi-clan.de>
Message-ID: <dec5e7c19e4dbc4e10aa5334ba3adfe4@imap.1and1.com>




On Tue, 08 Jun 2010 08:06:19 +0200, Patrick Georgi <patrick at georgi-clan.de>
wrote:
> Am 08.06.2010 04:22, schrieb Joseph Smith:
>> Hello,
>> Trying to boot Fedora 12 Live USB. FILO loads the Kernel just fine and
>> then Loads the initrd just fine. Then:
>>
>> Jumping to entry point...
>>
>> Out of memory while allocating output buffer
>>
>>  -- System halted
>>
>>
>> Any Ideas?
> That error message is in the linux decompression code and appears when
> it can't malloc the necessary memory (32kb), or if it's asked to
> decompress to address 0.
> 
> I guess that this either means that linux doesn't find usable memory
> tables, or that some parts of the linux bootblock data structure are not
> filled in correctly.
> The latter can happen when the kernel version is too new for the used
> linux loader.
> 
Thanks Patrick.
Hmm by linux loader you mean FILO? I was booting this directly from the
FILO prompt. FYI the same OS boots fine from regular hard drive, and the
Live USB image boots fine on another PC.

-- 
Thanks,
Joseph Smith
Set-Top-Linux
www.settoplinux.org




From joe at settoplinux.org  Tue Jun  8 12:54:13 2010
From: joe at settoplinux.org (Joseph Smith)
Date: Tue, 08 Jun 2010 06:54:13 -0400
Subject: [coreboot] Set top box update
In-Reply-To: <AANLkTik-oz9g55oOoL380xqt8BunC_9VFNJdc-TldRJM@mail.gmail.com>
References: <AANLkTik-oz9g55oOoL380xqt8BunC_9VFNJdc-TldRJM@mail.gmail.com>
Message-ID: <de7ec465c99029e8bd697cdae89aade0@imap.1and1.com>




On Tue, 8 Jun 2010 02:12:28 -0400, Gregg Levine <gregg.drwho8 at gmail.com>
wrote:
> Hello!
> Amazon tells me that there are now two people selling their Akimbo
> boxes. Perhaps I'll definitely buy one.
> 
> And Joe here is the linked page which contains a reference to the STB
> kit from Intel:
> http://cerberus.teamhackaday.com/?p=3
>
Yes I know him.
> 
> It turns out that it comes up right below the description for the
> device. It seems the only thing nonstandard about it is the crappy
> BIOS that Akimbo insisted on.
> 
Yes, corboot will be much better :-)

-- 
Thanks,
Joseph Smith
Set-Top-Linux
www.settoplinux.org




From patrick at georgi-clan.de  Tue Jun  8 13:11:08 2010
From: patrick at georgi-clan.de (Patrick Georgi)
Date: Tue, 08 Jun 2010 13:11:08 +0200
Subject: [coreboot] Booting UHCI with FILO
In-Reply-To: <dec5e7c19e4dbc4e10aa5334ba3adfe4@imap.1and1.com>
References: <4C0DA96E.5040700@settoplinux.org>
	<4C0DDDDB.8050001@georgi-clan.de>
	<dec5e7c19e4dbc4e10aa5334ba3adfe4@imap.1and1.com>
Message-ID: <4C0E254C.6090502@georgi-clan.de>

Am 08.06.2010 12:47, schrieb Joseph Smith:
> Thanks Patrick.
> Hmm by linux loader you mean FILO?
The linux loader in FILO, yes.

> FYI the same OS boots fine from regular hard drive, and the
> Live USB image boots fine on another PC.
These approaches have different code taking care of the tables that are
setup.


Patrick



From joe at settoplinux.org  Tue Jun  8 13:20:29 2010
From: joe at settoplinux.org (Joseph Smith)
Date: Tue, 08 Jun 2010 07:20:29 -0400
Subject: [coreboot] Booting UHCI with FILO
In-Reply-To: <4C0E254C.6090502@georgi-clan.de>
References: <4C0DA96E.5040700@settoplinux.org>
	<4C0DDDDB.8050001@georgi-clan.de>
	<dec5e7c19e4dbc4e10aa5334ba3adfe4@imap.1and1.com>
	<4C0E254C.6090502@georgi-clan.de>
Message-ID: <b656cc291e97992c68bc89f5885f91d4@imap.1and1.com>




On Tue, 08 Jun 2010 13:11:08 +0200, Patrick Georgi <patrick at georgi-clan.de>
wrote:
> Am 08.06.2010 12:47, schrieb Joseph Smith:
>> Thanks Patrick.
>> Hmm by linux loader you mean FILO?
> The linux loader in FILO, yes.
> 
So does this mean there is a bug in FILO?

>> FYI the same OS boots fine from regular hard drive, and the
>> Live USB image boots fine on another PC.
> These approaches have different code taking care of the tables that are
> setup.
> 
Yes booting from hard drive uses the FILO/Grub and booting from Live USB
uses syslinux.

-- 
Thanks,
Joseph Smith
Set-Top-Linux
www.settoplinux.org




From stefan.reinauer at coresystems.de  Tue Jun  8 13:23:31 2010
From: stefan.reinauer at coresystems.de (Stefan Reinauer)
Date: Tue, 08 Jun 2010 13:23:31 +0200
Subject: [coreboot] Booting UHCI with FILO
In-Reply-To: <dec5e7c19e4dbc4e10aa5334ba3adfe4@imap.1and1.com>
References: <4C0DA96E.5040700@settoplinux.org>	<4C0DDDDB.8050001@georgi-clan.de>
	<dec5e7c19e4dbc4e10aa5334ba3adfe4@imap.1and1.com>
Message-ID: <4C0E2833.2010808@coresystems.de>

On 6/8/10 12:47 PM, Joseph Smith wrote:
>> That error message is in the linux decompression code and appears when
>> it can't malloc the necessary memory (32kb), or if it's asked to
>> decompress to address 0.
>>
>> I guess that this either means that linux doesn't find usable memory
>> tables, or that some parts of the linux bootblock data structure are not
>> filled in correctly.
>> The latter can happen when the kernel version is too new for the used
>> linux loader.
>>
>>     
> Thanks Patrick.
> Hmm by linux loader you mean FILO? I was booting this directly from the
> FILO prompt. FYI the same OS boots fine from regular hard drive, and the
> Live USB image boots fine on another PC.
>
>   
Is this the latest svn libpayload and filo?


Stefan



From joe at settoplinux.org  Tue Jun  8 13:35:31 2010
From: joe at settoplinux.org (Joseph Smith)
Date: Tue, 08 Jun 2010 07:35:31 -0400
Subject: [coreboot] Booting UHCI with FILO
In-Reply-To: <4C0E2833.2010808@coresystems.de>
References: <4C0DA96E.5040700@settoplinux.org>	<4C0DDDDB.8050001@georgi-clan.de>
	<dec5e7c19e4dbc4e10aa5334ba3adfe4@imap.1and1.com>
	<4C0E2833.2010808@coresystems.de>
Message-ID: <ae0335ec9ee98dc6cb387c5a290b00db@imap.1and1.com>




On Tue, 08 Jun 2010 13:23:31 +0200, Stefan Reinauer
<stefan.reinauer at coresystems.de> wrote:
> On 6/8/10 12:47 PM, Joseph Smith wrote:
>>> That error message is in the linux decompression code and appears when
>>> it can't malloc the necessary memory (32kb), or if it's asked to
>>> decompress to address 0.
>>>
>>> I guess that this either means that linux doesn't find usable memory
>>> tables, or that some parts of the linux bootblock data structure are
not
>>> filled in correctly.
>>> The latter can happen when the kernel version is too new for the used
>>> linux loader.
>>>
>>>
>> Thanks Patrick.
>> Hmm by linux loader you mean FILO? I was booting this directly from the
>> FILO prompt. FYI the same OS boots fine from regular hard drive, and the
>> Live USB image boots fine on another PC.
>>
>>
> Is this the latest svn libpayload and filo?
> 
This was from about a week ago. I know Patrick just made some changes to
UHCI stack, so maybe I will try new version. I was kind of wondering if
that would fix it though? Or, if this is completly different problem.

-- 
Thanks,
Joseph Smith
Set-Top-Linux
www.settoplinux.org




From patrick.georgi at coresystems.de  Tue Jun  8 14:10:51 2010
From: patrick.georgi at coresystems.de (Patrick Georgi)
Date: Tue, 08 Jun 2010 14:10:51 +0200
Subject: [coreboot] Booting UHCI with FILO
In-Reply-To: <ae0335ec9ee98dc6cb387c5a290b00db@imap.1and1.com>
References: <4C0DA96E.5040700@settoplinux.org>	<4C0DDDDB.8050001@georgi-clan.de>	<dec5e7c19e4dbc4e10aa5334ba3adfe4@imap.1and1.com>	<4C0E2833.2010808@coresystems.de>
	<ae0335ec9ee98dc6cb387c5a290b00db@imap.1and1.com>
Message-ID: <4C0E334B.4050201@coresystems.de>

Am 08.06.2010 13:35, schrieb Joseph Smith:
> This was from about a week ago. I know Patrick just made some changes to
> UHCI stack, so maybe I will try new version. I was kind of wondering if
> that would fix it though? Or, if this is completly different problem.
Your problem has nothing to do with UHCI.

And my recent changes shouldn't change behaviour anyway.


Patrick



From joe at settoplinux.org  Tue Jun  8 14:32:35 2010
From: joe at settoplinux.org (Joseph Smith)
Date: Tue, 08 Jun 2010 08:32:35 -0400
Subject: [coreboot] Booting UHCI with FILO
In-Reply-To: <4C0E334B.4050201@coresystems.de>
References: <4C0DA96E.5040700@settoplinux.org>	<4C0DDDDB.8050001@georgi-clan.de>	<dec5e7c19e4dbc4e10aa5334ba3adfe4@imap.1and1.com>	<4C0E2833.2010808@coresystems.de>
	<ae0335ec9ee98dc6cb387c5a290b00db@imap.1and1.com>
	<4C0E334B.4050201@coresystems.de>
Message-ID: <cd2d177127161bd9d22823b19865560d@imap.1and1.com>




On Tue, 08 Jun 2010 14:10:51 +0200, Patrick Georgi
<patrick.georgi at coresystems.de> wrote:
> Am 08.06.2010 13:35, schrieb Joseph Smith:
>> This was from about a week ago. I know Patrick just made some changes to
>> UHCI stack, so maybe I will try new version. I was kind of wondering if
>> that would fix it though? Or, if this is completly different problem.
> Your problem has nothing to do with UHCI.
> 
> And my recent changes shouldn't change behaviour anyway.
> 
> 
Hmm, then I guess FILO has a bug.

-- 
Thanks,
Joseph Smith
Set-Top-Linux
www.settoplinux.org




From peter at stuge.se  Tue Jun  8 17:31:23 2010
From: peter at stuge.se (Peter Stuge)
Date: Tue, 8 Jun 2010 17:31:23 +0200
Subject: [coreboot] LinuxTag 2010 this week
Message-ID: <20100608153123.15594.qmail@stuge.se>

Hi!

If you're in or near Berlin then please feel free to stop by the
coreboot booth at LinuxTag 2010 on the Messe Berlin fairground.

The expo runs from tomorrow Wednesday until Saturday evening this
week. Please let me know if you need a ticket.

Our booth will be in the embedded area, that's hall 7.2b booth 112,
on the right hand side of the Open Source Arena stage.


I hope to see you there! :)

//Peter



From joe at settoplinux.org  Tue Jun  8 18:24:03 2010
From: joe at settoplinux.org (Joseph Smith)
Date: Tue, 08 Jun 2010 12:24:03 -0400
Subject: [coreboot] LinuxTag 2010 this week
In-Reply-To: <20100608153123.15594.qmail@stuge.se>
References: <20100608153123.15594.qmail@stuge.se>
Message-ID: <100a7158417a77272504a83de619345e@imap.1and1.com>




On Tue, 8 Jun 2010 17:31:23 +0200, Peter Stuge <peter at stuge.se> wrote:
> Hi!
> 
> If you're in or near Berlin then please feel free to stop by the
> coreboot booth at LinuxTag 2010 on the Messe Berlin fairground.
> 
> The expo runs from tomorrow Wednesday until Saturday evening this
> week. Please let me know if you need a ticket.
> 
> Our booth will be in the embedded area, that's hall 7.2b booth 112,
> on the right hand side of the Open Source Arena stage.
> 
> 
> I hope to see you there! :)
> 
Sweet!
If only I was in Berlin...

-- 
Thanks,
Joseph Smith
Set-Top-Linux
www.settoplinux.org




From Cristi.Magherusan at net.utcluj.ro  Tue Jun  8 20:35:59 2010
From: Cristi.Magherusan at net.utcluj.ro (Cristi Magherusan)
Date: Tue, 08 Jun 2010 21:35:59 +0300
Subject: [coreboot] i840 coreboot challenge
In-Reply-To: <b0860df4c6310aa5ce21be0bde85569d@imap.1and1.com>
References: <4BD60205.9030709@settoplinux.org>
	<b0860df4c6310aa5ce21be0bde85569d@imap.1and1.com>
Message-ID: <1276022159.12049.13.camel@ufo>

On Tue, 2010-04-27 at 08:43 -0400, Joseph Smith wrote:
> 
> On Mon, 26 Apr 2010 17:13:41 -0400, Joseph Smith <joe at settoplinux.org>
> wrote:
> > Hello,
> > I want to propose a "coreboot challenge" to first port coreboot to the
> > i840 chpset, second port coreboot to support a very rare i840 dual cpu
> > board, third instead of RAMBUS (which i840 is designed for) this board
> > uses SDRAM. I think this would be a very interesting port for coreboot.
> > 
> > The board is a AMI Megatrends MegaDual. The user manual can be found
> > here: http://www.ami.com/support/doc/MegaDual_mb_man.PDF
> > 
> > I have four of these rare boards and am willing to donate three of them
> > (one person each, less shipping costs of course) to anyone who is
> > willing to take on this challenge. Let me know if your interested.
> > 
> > P.S.: the first person to boot to a Linux command line gets the grand
> > prize, a big fat cookie :-)
> > 
> Attached is a pic of the board, in case your curious.
> 
> -- 
> Thanks,
> Joseph Smith
> Set-Top-Linux
> www.settoplinux.org
> -- coreboot mailing list: coreboot at coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Hi Joe,

It it still offer valid? I could give it a try since next month, but I
also need a CPU(or two?). I think I still have some SDRAM somewhere, and
I think I have the rest of the components...

It really looks like great fun.

Regards,
Cristi

-- 
Cristi M?gheru?an, alumnus System/Network Engineer
Technical University of Cluj-Napoca, Romania
http://cc.utcluj.ro  +40264 401247
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20100608/383e753c/attachment.sig>

From njacobs8 at hetnet.nl  Tue Jun  8 21:41:20 2010
From: njacobs8 at hetnet.nl (Nils)
Date: Tue, 8 Jun 2010 21:41:20 +0200
Subject: [coreboot] [PATCH] Wyse S50 RAMBASE 0x100000 fix
Message-ID: <201006082141.20187.njacobs8@hetnet.nl>

Patrick wrote:
>Is there a reason why this function is mainboard specific? It seems to
>me that this, including your change, should be part of the chipset code.
I also thought about that and i think you are right.
I think all geode GX2 and LX boards should have the same memory region 
setup.And i think it could well live in chipset code.
A while back i tried to use the new LX msr init function but it didn`t 
compile.
(I forgot the exact error.) 
Could that be ROMCC related?
I then adapted it to the patch in r5544 .
Maybe someone knows how to change it so that it compiles on GCC and ROMCC.

Stefan wrote:
>Why 1F6BF000 ?
I extracted that value from the original bios with MSRtool , and it worked.
If you have a better setting and / or patch i will be glad to test it.

Thanks,Nils.



From joe at settoplinux.org  Tue Jun  8 21:39:15 2010
From: joe at settoplinux.org (Joseph Smith)
Date: Tue, 08 Jun 2010 15:39:15 -0400
Subject: [coreboot] i840 coreboot challenge
In-Reply-To: <1276022159.12049.13.camel@ufo>
References: <4BD60205.9030709@settoplinux.org>	
	<b0860df4c6310aa5ce21be0bde85569d@imap.1and1.com>
	<1276022159.12049.13.camel@ufo>
Message-ID: <4C0E9C63.9060202@settoplinux.org>

On 06/08/2010 02:35 PM, Cristi Magherusan wrote:
> On Tue, 2010-04-27 at 08:43 -0400, Joseph Smith wrote:
>>
>> On Mon, 26 Apr 2010 17:13:41 -0400, Joseph Smith<joe at settoplinux.org>
>> wrote:
>>> Hello,
>>> I want to propose a "coreboot challenge" to first port coreboot to the
>>> i840 chpset, second port coreboot to support a very rare i840 dual cpu
>>> board, third instead of RAMBUS (which i840 is designed for) this board
>>> uses SDRAM. I think this would be a very interesting port for coreboot.
>>>
>>> The board is a AMI Megatrends MegaDual. The user manual can be found
>>> here: http://www.ami.com/support/doc/MegaDual_mb_man.PDF
>>>
>>> I have four of these rare boards and am willing to donate three of them
>>> (one person each, less shipping costs of course) to anyone who is
>>> willing to take on this challenge. Let me know if your interested.
>>>
>>> P.S.: the first person to boot to a Linux command line gets the grand
>>> prize, a big fat cookie :-)
>>>
>> Attached is a pic of the board, in case your curious.
>>
>> --
>> Thanks,
>> Joseph Smith
>> Set-Top-Linux
>> www.settoplinux.org
>> -- coreboot mailing list: coreboot at coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
> Hi Joe,
>
> It it still offer valid? I could give it a try since next month, but I
> also need a CPU(or two?). I think I still have some SDRAM somewhere, and
> I think I have the rest of the components...
>
> It really looks like great fun.
>
Hello Cristi,
Yes I still have a board available for you. I might even have some 
processors around to throw in. Send me an email offlist and we will 
figure out the shipping stuff. Looking forward to coreboot on this board :-)

-- 
Thanks,
Joseph Smith
Set-Top-Linux
www.settoplinux.org



From mbertens at xs4all.nl  Tue Jun  8 21:55:25 2010
From: mbertens at xs4all.nl (mbertens)
Date: Tue, 08 Jun 2010 21:55:25 +0200
Subject: [coreboot] unable to boot linux with coreboot
Message-ID: <1276026925.3803.54.camel@andrala.reboot>

Hi all,

i have a strong problem that im not able to boot any os wit coreboot, it
starts (linux) ut it hangs after 128 sec. 

http://pastebin.com/uBT8JdH4

Anyone any ideas

Marc




From anders at jenbo.dk  Wed Jun  9 01:57:26 2010
From: anders at jenbo.dk (Anders Jenbo)
Date: Wed, 09 Jun 2010 01:57:26 +0200
Subject: [coreboot]  PATCH: ECS P6IWP-Fe
Message-ID: <1276041446.1596.5.camel@anders-laptop>

This patch adds the ECS P6IWP-Fe board to coreboot.

Signed-off-by: Anders Jenbo <anders at jenbo.dk>
---

Anders Jenbo
-------------- next part --------------
A non-text attachment was scrubbed...
Name: ecs-p6iwp-fe.patch
Type: text/x-patch
Size: 14900 bytes
Desc: not available
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20100609/e0904705/attachment.patch>

From paulepanter at users.sourceforge.net  Wed Jun  9 02:13:14 2010
From: paulepanter at users.sourceforge.net (Paul Menzel)
Date: Wed, 09 Jun 2010 02:13:14 +0200
Subject: [coreboot] PATCH: ECS P6IWP-Fe
In-Reply-To: <1276041446.1596.5.camel@anders-laptop>
References: <1276041446.1596.5.camel@anders-laptop>
Message-ID: <1276042394.9922.8.camel@mattotaupa>

Dear Anders,


Am Mittwoch, den 09.06.2010, 01:57 +0200 schrieb Anders Jenbo:
> This patch adds the ECS P6IWP-Fe board to coreboot.

great! Thank you. Could you provide a link to the product page of this
board board? Is there already a Wiki page for this board on what is
supported and so on?

[?]

> Property changes on: src/mainboard/ecs/Kconfig
> ___________________________________________________________________
> Added: svn:executable
>    + * 

This is done to a lot of files. Is this necessary?

[?]


Thanks again,

Paul
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20100609/34ee7e60/attachment.sig>

From kara_am at yahoo.com  Wed Jun  9 03:01:44 2010
From: kara_am at yahoo.com (am kara)
Date: Tue, 8 Jun 2010 18:01:44 -0700 (PDT)
Subject: [coreboot] Kontron, 986LCD-M
In-Reply-To: <mailman.834.1276023127.3514.coreboot@coreboot.org>
Message-ID: <10706.65358.qm@web114613.mail.gq1.yahoo.com>

Please direct me to make sure I can change the BIOS of the following computer with Corebot before buying it:
Kontron, 986LCD-M/miniITX

1) Does the vendor BIOS have a boot block? If I over-write BIOS chip completely, the boot block will be gone? I know that this board has Megatrends, AMIBIOS with kontron extensions, which probably has some facilities(boot block) to save or write the BIOS chip, can i replace the vendor BIOS with Coreboot by this facility? and if I write on flash BIOS, i will lose the vendor BIOS and the boot block completely?
Please let me know if anybody has some experience using `flashrom` free utility which is used for writing on BIOS chips. 

2) Can i install Linux, Fedora 12 on this motherboard? Does Linux kernel(www.kernel.org), the latest version, recognize all the motherboard chipset, CPU and other components?    


      



From anders at jenbo.dk  Wed Jun  9 09:02:30 2010
From: anders at jenbo.dk (=?utf-8?B?YW5kZXJzQGplbmJvLmRr?=)
Date: Wed, 09 Jun 2010 09:02:30 +0200
Subject: [coreboot] =?utf-8?q?Indtast_Bcc__Kontron=2C_986LCD-M?=
Message-ID: <mailman.4189.1355071773.16123.coreboot@coreboot.org>

The answer to all your questions seams to be yes. Yes the board seams to be fully supported by Linus, yes the BIOS will be completely over written, non of the BIOS functions will be there after you install coreboot, you may or may not be able to use the build in flash utility to write coreboot, but it is a done time deal, you would have to use flashrom (or a vendor utility) for any further flashing. Yes the board is supported by coreboot maybe except for CPU frequency scaling.

Mvh Anders

----- Reply message -----
Fra: "am kara" <kara_am at yahoo.com>
Dato: ons., jun. 9, 2010 03:01
Emne: [coreboot] Kontron, 986LCD-M
Til: <coreboot at coreboot.org>

Please direct me to make sure I can change the BIOS of the following computer with Corebot before buying it:
Kontron, 986LCD-M/miniITX

1) Does the vendor BIOS have a boot block? If I over-write BIOS chip completely, the boot block will be gone? I know that this board has Megatrends, AMIBIOS with kontron extensions, which probably has some facilities(boot block) to save or write the BIOS chip, can i replace the vendor BIOS with Coreboot by this facility? and if I write on flash BIOS, i will lose the vendor BIOS and the boot block completely?
Please let me know if anybody has some experience using `flashrom` free utility which is used for writing on BIOS chips. 

2) Can i install Linux, Fedora 12 on this motherboard? Does Linux kernel(www.kernel.org), the latest version, recognize all the motherboard chipset, CPU and other components?    


      

-- 
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/20100609/a983c3ec/attachment.html>

From anders at jenbo.dk  Wed Jun  9 09:30:18 2010
From: anders at jenbo.dk (=?utf-8?B?YW5kZXJzQGplbmJvLmRr?=)
Date: Wed, 09 Jun 2010 09:30:18 +0200
Subject: [coreboot] =?utf-8?q?PATCH=3A_ECS_P6IWP-Fe?=
Message-ID: <mailman.4190.1355071773.16123.coreboot@coreboot.org>

The exe flags are probably because I edited some of the file over a samba share, feel free to remove them.

Mvh Anders

----- Reply message -----
Fra: "Paul Menzel" <paulepanter at users.sourceforge.net>
Dato: ons., jun. 9, 2010 02:13
Emne: [coreboot] PATCH: ECS P6IWP-Fe
Til: <coreboot at coreboot.org>

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

From stefan.reinauer at coresystems.de  Wed Jun  9 09:44:29 2010
From: stefan.reinauer at coresystems.de (Stefan Reinauer)
Date: Wed, 09 Jun 2010 09:44:29 +0200
Subject: [coreboot] [PATCH] SeaBIOS CD/DVD abbreviations
Message-ID: <4C0F465D.4040901@coresystems.de>

See Patch.

-- 
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 --------------
An embedded and charset-unspecified text was scrubbed...
Name: seabios-dvd.diff
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20100609/fe1becf0/attachment.ksh>

From stefan.reinauer at coresystems.de  Wed Jun  9 09:45:28 2010
From: stefan.reinauer at coresystems.de (Stefan Reinauer)
Date: Wed, 09 Jun 2010 09:45:28 +0200
Subject: [coreboot] [PATCH] SeaBIOS VGA hooks
Message-ID: <4C0F4698.6000405@coresystems.de>

SeaBIOS VGA hooks for Getac P470 and Roda RK886EX notebooks

-- 
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 --------------
An embedded and charset-unspecified text was scrubbed...
Name: seabios-vgahooks.diff
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20100609/43470cbc/attachment.ksh>

From stefan.reinauer at coresystems.de  Wed Jun  9 09:46:27 2010
From: stefan.reinauer at coresystems.de (Stefan Reinauer)
Date: Wed, 09 Jun 2010 09:46:27 +0200
Subject: [coreboot] [PATCH] Bootsplash for SeaBIOS (with coreboot)
Message-ID: <4C0F46D3.3070405@coresystems.de>

See patch

-- 
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 --------------
An embedded and charset-unspecified text was scrubbed...
Name: seabios-splash.diff
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20100609/7be8285d/attachment.ksh>

From edwin_beasant at virtensys.com  Wed Jun  9 09:49:09 2010
From: edwin_beasant at virtensys.com (Edwin Beasant)
Date: Wed, 9 Jun 2010 08:49:09 +0100
Subject: [coreboot] Geode LX cpuinit v3->v4 port announce.
Message-ID: <95EC52016CC5DE4896FD95FA7323A4DB152FFE44F5@mr-burns.exchange.virtensys.com>

Hi all.
Over the next few days I hope to be able to port the v3 style cpu init code for the Geode LX from v3 into v4.
There are a number of outstanding issues in the v4 code that have been inherited from v2, and which v3 deals with correctly.
The primary motivation for this is the handling of terminated DIMMs, which under v4 the GLCP values are calculated incorrectly.

I hope to have this up and tested for db800 and Norwich derived boards asap.

In the meantime, please bear with me!

The changes will be based on  r5622 initially.

Many thanks,
Edwin_beasant at virtensys.com

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

From svn at coreboot.org  Wed Jun  9 10:08:13 2010
From: svn at coreboot.org (repository service)
Date: Wed, 09 Jun 2010 10:08:13 +0200
Subject: [coreboot] [commit] r5623 - in trunk/src/mainboard: . ecs
	ecs/p6iwp-fe
Message-ID: <E1OMGKb-0003W7-Ap@ra.coresystems.de>

Author: stepan
Date: Wed Jun  9 10:08:12 2010
New Revision: 5623
URL: https://tracker.coreboot.org/trac/coreboot/changeset/5623

Log:
This patch adds the ECS P6IWP-Fe board to coreboot.

Signed-off-by: Anders Jenbo <anders at jenbo.dk>
Acked-by: Stefan Reinauer <stepan at coresystems.de>

Added:
   trunk/src/mainboard/ecs/
   trunk/src/mainboard/ecs/Kconfig
   trunk/src/mainboard/ecs/p6iwp-fe/
   trunk/src/mainboard/ecs/p6iwp-fe/Kconfig
   trunk/src/mainboard/ecs/p6iwp-fe/chip.h
   trunk/src/mainboard/ecs/p6iwp-fe/devicetree.cb
   trunk/src/mainboard/ecs/p6iwp-fe/irq_tables.c
   trunk/src/mainboard/ecs/p6iwp-fe/mainboard.c
   trunk/src/mainboard/ecs/p6iwp-fe/romstage.c
Modified:
   trunk/src/mainboard/Kconfig

Modified: trunk/src/mainboard/Kconfig
==============================================================================
--- trunk/src/mainboard/Kconfig	Tue Jun  8 07:57:05 2010	(r5622)
+++ trunk/src/mainboard/Kconfig	Wed Jun  9 10:08:12 2010	(r5623)
@@ -40,6 +40,8 @@
 	bool "DIGITAL-LOGIC"
 config VENDOR_EAGLELION
 	bool "EagleLion"
+config VENDOR_ECS
+	bool "ECS"
 config VENDOR_EMULATION
 	bool "Emulation"
 config VENDOR_GETAC
@@ -203,6 +205,11 @@
 
 config MAINBOARD_VENDOR
 	string
+	default "ECS"
+	depends on VENDOR_ECS
+
+config MAINBOARD_VENDOR
+	string
 	default "Emulation"
 	depends on VENDOR_EMULATION
 
@@ -424,6 +431,7 @@
 source "src/mainboard/dell/Kconfig"
 source "src/mainboard/digitallogic/Kconfig"
 source "src/mainboard/eaglelion/Kconfig"
+source "src/mainboard/ecs/Kconfig"
 source "src/mainboard/emulation/Kconfig"
 source "src/mainboard/getac/Kconfig"
 source "src/mainboard/gigabyte/Kconfig"

Added: trunk/src/mainboard/ecs/Kconfig
==============================================================================
--- /dev/null	00:00:00 1970	(empty, because file is newly added)
+++ trunk/src/mainboard/ecs/Kconfig	Wed Jun  9 10:08:12 2010	(r5623)
@@ -0,0 +1,28 @@
+##
+## This file is part of the coreboot project.
+##
+## Copyright (C) 2009 Uwe Hermann <uwe at hermann-uwe.de>
+##
+## 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; either version 2 of the License, or
+## (at your option) any later version.
+##
+## 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
+##
+
+choice
+	prompt "Mainboard model"
+	depends on VENDOR_ECS
+
+source "src/mainboard/ecs/p6iwp-fe/Kconfig"
+
+endchoice
+

Added: trunk/src/mainboard/ecs/p6iwp-fe/Kconfig
==============================================================================
--- /dev/null	00:00:00 1970	(empty, because file is newly added)
+++ trunk/src/mainboard/ecs/p6iwp-fe/Kconfig	Wed Jun  9 10:08:12 2010	(r5623)
@@ -0,0 +1,52 @@
+##
+## This file is part of the coreboot project.
+##
+## Copyright (C) 2010 Anders Jenbo <anders at jenbo.dk>
+##
+## 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; either version 2 of the License, or
+## (at your option) any later version.
+##
+## 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 BOARD_ECS_P6IWP_FE
+	bool "P6IWP-FE"
+	select ARCH_X86
+	select CPU_INTEL_SOCKET_PGA370
+	select NORTHBRIDGE_INTEL_I82810
+	select SOUTHBRIDGE_INTEL_I82801AX
+	select SUPERIO_ITE_IT8712F
+	select ROMCC
+	select HAVE_PIRQ_TABLE
+	select UDELAY_TSC
+	select BOARD_ROMSIZE_KB_512
+
+config MAINBOARD_DIR
+	string
+	default ecs/p6iwp-fe
+	depends on BOARD_ECS_P6IWP_FE
+
+config MAINBOARD_PART_NUMBER
+	string
+	default "P6IWP-FE"
+	depends on BOARD_ECS_P6IWP_FE
+
+config HAVE_OPTION_TABLE
+	bool
+	default n
+	depends on BOARD_ECS_P6IWP_FE
+
+config IRQ_SLOT_COUNT
+	int
+	default 10
+	depends on BOARD_ECS_P6IWP_FE
+

Added: trunk/src/mainboard/ecs/p6iwp-fe/chip.h
==============================================================================
--- /dev/null	00:00:00 1970	(empty, because file is newly added)
+++ trunk/src/mainboard/ecs/p6iwp-fe/chip.h	Wed Jun  9 10:08:12 2010	(r5623)
@@ -0,0 +1,22 @@
+/*
+ * This file is part of the coreboot project.
+ *
+ * Copyright (C) 2007 Uwe Hermann <uwe at hermann-uwe.de>
+ *
+ * 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; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * 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
+ */
+
+extern struct chip_operations mainboard_ops;
+struct mainboard_config {};

Added: trunk/src/mainboard/ecs/p6iwp-fe/devicetree.cb
==============================================================================
--- /dev/null	00:00:00 1970	(empty, because file is newly added)
+++ trunk/src/mainboard/ecs/p6iwp-fe/devicetree.cb	Wed Jun  9 10:08:12 2010	(r5623)
@@ -0,0 +1,66 @@
+chip northbridge/intel/i82810		# Northbridge
+  device lapic_cluster 0 on		# APIC cluster
+    chip cpu/intel/socket_PGA370	# CPU
+      device lapic 0 on end		# APIC
+    end
+  end
+  device pci_domain 0 on		# PCI domain
+    device pci 0.0 on end		# Graphics Memory Controller Hub (GMCH)
+    device pci 1.0 on end		# Chipset Graphics Controller (CGC)
+    chip southbridge/intel/i82801ax	# Southbridge
+      register "ide0_enable" = "1"
+      register "ide1_enable" = "1"
+
+      device pci 1e.0 on end		# PCI bridge
+      device pci 1f.0 on		# ISA bridge
+        chip superio/ite/it8712f	# Super I/O
+          device pnp 2e.0 off		# Floppy
+            io 0x60 = 0x3f0
+            irq 0x70 = 6
+            drq 0x74 = 2
+          end
+          device pnp 2e.1 on		# Com1
+            io 0x60 = 0x3f8
+            irq 0x70 = 4
+          end
+          device pnp 2e.2 on		# Com2
+            io 0x60 = 0x2f8
+            irq 0x70 = 3
+          end
+          device pnp 2e.3 on		# Parallel port
+            io 0x60 = 0x378
+            irq 0x70 = 7
+          end
+          device pnp 2e.4 on		# EC
+            io 0x60 = 0x290
+            io 0x62 = 0x230
+            irq 0x70 = 9
+          end
+          device pnp 2e.5 on		# PS/2 keyboard
+            io 0x60 = 0x60
+            io 0x62 = 0x64
+            irq 0x70 = 1
+          end
+          device pnp 2e.6 on		# PS/2 mouse
+            irq 0x70 = 12
+          end
+          device pnp 2e.7 on		# GPIO
+            io 0x62 = 0x1220
+            io 0x64 = 0x1200
+          end
+          device pnp 2e.8 off		# MIDI
+            io 0x60 = 0x300
+            irq 0x70 = 9
+          end
+          device pnp 2e.9 off		# Game port
+            io 0x60 = 0x220
+          end
+          device pnp 2e.a off end	# CIR
+        end
+      end
+      device pci 1f.1 on end		# IDE
+      device pci 1f.2 on end		# USB
+      device pci 1f.3 on end		# SMBus
+    end
+  end
+end

Added: trunk/src/mainboard/ecs/p6iwp-fe/irq_tables.c
==============================================================================
--- /dev/null	00:00:00 1970	(empty, because file is newly added)
+++ trunk/src/mainboard/ecs/p6iwp-fe/irq_tables.c	Wed Jun  9 10:08:12 2010	(r5623)
@@ -0,0 +1,56 @@
+/*
+ * This file is part of the coreboot project.
+ *
+ * Copyright (C) 2010 Anders Jenbo <anders at jenbo.dk>
+ *
+ * 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; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * 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 <arch/pirq_routing.h>
+
+const struct irq_routing_table intel_irq_routing_table = {
+	PIRQ_SIGNATURE,		/* u32 signature */
+	PIRQ_VERSION,		/* u16 version */
+	32 + 16 * CONFIG_IRQ_SLOT_COUNT, /* Max. number of devices on the bus */
+	0x00,			/* Interrupt router bus */
+	(0x1f << 3) | 0x0,	/* Interrupt router dev */
+	0x1c00,			/* IRQs devoted exclusively to PCI usage */
+	0x8086,			/* Vendor */
+	0x7000,			/* Device */
+	0,			/* Miniport */
+	{ 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0 }, /* u8 rfu[11] */
+	0x7,			/* Checksum (has to be set to some value that
+				 * would give 0 after the sum of all bytes
+				 * for this structure (including checksum).
+                                 */
+	{
+		/* bus,        dev | fn,   {link, bitmap}, {link, bitmap}, {link, bitmap}, {link, bitmap}, slot, rfu */
+		{0x00, (0x1e << 3) | 0x0, {{0x60, 0xdeb8}, {0x61, 0xdeb8}, {0x62, 0xdeb8}, {0x63, 0xdeb8}}, 0x1, 0x0},
+		{0x00, (0x10 << 3) | 0x0, {{0x61, 0xdeb8}, {0x62, 0xdeb8}, {0x63, 0xdeb8}, {0x60, 0xdeb8}}, 0x2, 0x0},
+		{0x01, (0x04 << 3) | 0x0, {{0x60, 0xdeb8}, {0x61, 0xdeb8}, {0x62, 0xdeb8}, {0x63, 0xdeb8}}, 0x3, 0x0},
+		{0x01, (0x05 << 3) | 0x0, {{0x61, 0xdeb8}, {0x62, 0xdeb8}, {0x63, 0xdeb8}, {0x60, 0xdeb8}}, 0x4, 0x0},
+		{0x01, (0x0a << 3) | 0x0, {{0x63, 0xdeb8}, {0x62, 0xdeb8}, {0x60, 0xdeb8}, {0x61, 0xdeb8}}, 0x5, 0x0},
+		{0x01, (0x07 << 3) | 0x0, {{0x61, 0xdeb8}, {0x62, 0xdeb8}, {0x63, 0xdeb8}, {0x60, 0xdeb8}}, 0x6, 0x0},
+		{0x01, (0x08 << 3) | 0x0, {{0x61, 0xdeb8}, {0x62, 0xdeb8}, {0x63, 0xdeb8}, {0x60, 0xdeb8}}, 0x7, 0x0},
+		{0x01, (0x09 << 3) | 0x0, {{0x62, 0xdeb8}, {0x63, 0xdeb8}, {0x60, 0xdeb8}, {0x61, 0xdeb8}}, 0x8, 0x0},
+		{0x00, (0x01 << 3) | 0x0, {{0x60, 0xdeb8}, {0x61, 0xdeb8}, {0x62, 0xdeb8}, {0x63, 0xdeb8}}, 0x0, 0x0},
+		{0x00, (0x1f << 3) | 0x1, {{0x60, 0xdeb8}, {0x61, 0xdeb8}, {0x62, 0xdeb8}, {0x63, 0xdeb8}}, 0x0, 0x0},
+	}
+};
+
+unsigned long write_pirq_routing_table(unsigned long addr)
+{
+	return copy_pirq_routing_table(addr);
+}

Added: trunk/src/mainboard/ecs/p6iwp-fe/mainboard.c
==============================================================================
--- /dev/null	00:00:00 1970	(empty, because file is newly added)
+++ trunk/src/mainboard/ecs/p6iwp-fe/mainboard.c	Wed Jun  9 10:08:12 2010	(r5623)
@@ -0,0 +1,26 @@
+/*
+ * This file is part of the coreboot project.
+ *
+ * Copyright (C) 2010 Anders Jenbo <anders at jenbo.dk>
+ *
+ * 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; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * 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 <device/device.h>
+#include "chip.h"
+
+struct chip_operations mainboard_ops = {
+	CHIP_NAME("ECS P6IWP-Fe Mainboard")
+};

Added: trunk/src/mainboard/ecs/p6iwp-fe/romstage.c
==============================================================================
--- /dev/null	00:00:00 1970	(empty, because file is newly added)
+++ trunk/src/mainboard/ecs/p6iwp-fe/romstage.c	Wed Jun  9 10:08:12 2010	(r5623)
@@ -0,0 +1,72 @@
+/*
+ * This file is part of the coreboot project.
+ *
+ * Copyright (C) 2007 Uwe Hermann <uwe at hermann-uwe.de>
+ * Copyright (C) 2010 Anders Jenbo <anders at jenbo.dk>
+ *
+ * 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; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * 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 <stdint.h>
+#include <stdlib.h>
+#include <device/pci_def.h>
+#include <arch/io.h>
+#include <device/pnp_def.h>
+#include <arch/romcc_io.h>
+#include <arch/hlt.h>
+#include <console/console.h>
+#include "lib/ramtest.c"
+#include "southbridge/intel/i82801ax/i82801ax_early_smbus.c"
+#include "northbridge/intel/i82810/raminit.h"
+#include "lib/debug.c"
+#include "pc80/udelay_io.c"
+#include "lib/delay.c"
+#include "cpu/x86/mtrr/earlymtrr.c"
+#include "cpu/x86/bist.h"
+#include "superio/ite/it8712f/it8712f_early_serial.c"
+
+static inline int spd_read_byte(unsigned int device, unsigned int address)
+{
+	return smbus_read_byte(device, address);
+}
+
+#include "northbridge/intel/i82810/raminit.c"
+#include "northbridge/intel/i82810/debug.c"
+
+/* Early mainboard specific GPIO setup. */
+static void mb_gpio_init(void)
+{
+}
+
+static void main(unsigned long bist)
+{
+	if (bist == 0)
+		early_mtrr_init();
+
+	it8712f_24mhz_clkin();
+	it8712f_enable_serial(0, CONFIG_TTYS0_BASE); // Does not use its 1st parameter
+	mb_gpio_init();
+	uart_init();
+	console_init();
+	report_bist_failure(bist);
+	enable_smbus();
+	dump_spd_registers();
+	sdram_set_registers();
+	sdram_set_spd_registers();
+	sdram_enable();
+	dump_spd_registers();
+	/* ram_check(0, 640 * 1024); */
+}
+



From stepan at coresystems.de  Wed Jun  9 10:09:21 2010
From: stepan at coresystems.de (Stefan Reinauer)
Date: Wed, 09 Jun 2010 10:09:21 +0200
Subject: [coreboot] PATCH: ECS P6IWP-Fe
In-Reply-To: <1276041446.1596.5.camel@anders-laptop>
References: <1276041446.1596.5.camel@anders-laptop>
Message-ID: <4C0F4C31.8040907@coresystems.de>

On 6/9/10 1:57 AM, Anders Jenbo wrote:
> This patch adds the ECS P6IWP-Fe board to coreboot.
>
> Signed-off-by: Anders Jenbo <anders at jenbo.dk>

Thanks a lot!

Acked-by: Stefan Reinauer <stepan at coresystems.de>
and checked in as r5623

But please add a license header to the device tree as well in an extra
patch..

Stefan



From stepan at coresystems.de  Wed Jun  9 10:49:36 2010
From: stepan at coresystems.de (Stefan Reinauer)
Date: Wed, 09 Jun 2010 10:49:36 +0200
Subject: [coreboot] [PATCH] avoid IO resource conflicts
Message-ID: <4C0F55A0.2010506@coresystems.de>

See patch

Stefan
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: resource-constraints.diff
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20100609/6dd55608/attachment.ksh>

From joe at settoplinux.org  Wed Jun  9 12:47:59 2010
From: joe at settoplinux.org (Joseph Smith)
Date: Wed, 09 Jun 2010 06:47:59 -0400
Subject: [coreboot] PATCH: ECS P6IWP-Fe
In-Reply-To: <4C0F4C31.8040907@coresystems.de>
References: <1276041446.1596.5.camel@anders-laptop>
	<4C0F4C31.8040907@coresystems.de>
Message-ID: <bd417ec0e08ccae701233c5eccaefafe@imap.1and1.com>




On Wed, 09 Jun 2010 10:09:21 +0200, Stefan Reinauer <stepan at coresystems.de>
wrote:
> On 6/9/10 1:57 AM, Anders Jenbo wrote:
>> This patch adds the ECS P6IWP-Fe board to coreboot.
>>
>> Signed-off-by: Anders Jenbo <anders at jenbo.dk>
> 
> Thanks a lot!
> 
> Acked-by: Stefan Reinauer <stepan at coresystems.de>
> and checked in as r5623
> 
> But please add a license header to the device tree as well in an extra
> patch..
> 
Yes thanks Anders :-)
One more suggestion. I think from this point forward there is really no
excuse for any Intel 440bx and up to be using romcc. I feel there should be
a new rule, any new boards 440bx and up need to be running CAR for a Ack.
Other wise that will be just one more board to back paddle to CAR. Anyone
else have a thought on this?

-- 
Thanks,
Joseph Smith
Set-Top-Linux
www.settoplinux.org




From stefan.reinauer at coresystems.de  Wed Jun  9 13:00:26 2010
From: stefan.reinauer at coresystems.de (Stefan Reinauer)
Date: Wed, 9 Jun 2010 13:00:26 +0200
Subject: [coreboot] PATCH: ECS P6IWP-Fe
In-Reply-To: <bd417ec0e08ccae701233c5eccaefafe@imap.1and1.com>
References: <1276041446.1596.5.camel@anders-laptop>
	<4C0F4C31.8040907@coresystems.de>
	<bd417ec0e08ccae701233c5eccaefafe@imap.1and1.com>
Message-ID: <E05A6BE4-C523-4783-B8E0-BE8B10BACAD3@coresystems.de>


On 09.06.2010, at 12:47, Joseph Smith <joe at settoplinux.org> wrote:

>
>
>
> On Wed, 09 Jun 2010 10:09:21 +0200, Stefan Reinauer <stepan at coresystems.de 
> >
> wrote:
>> On 6/9/10 1:57 AM, Anders Jenbo wrote:
>>> This patch adds the ECS P6IWP-Fe board to coreboot.
>>>
>>> Signed-off-by: Anders Jenbo <anders at jenbo.dk>
>>
>> Thanks a lot!
>>
>> Acked-by: Stefan Reinauer <stepan at coresystems.de>
>> and checked in as r5623
>>
>> But please add a license header to the device tree as well in an  
>> extra
>> patch..
>>
> Yes thanks Anders :-)
> One more suggestion. I think from this point forward there is really  
> no
> excuse for any Intel 440bx and up to be using romcc. I feel there  
> should be
> a new rule, any new boards 440bx and up need to be running CAR for a  
> Ack.
> Other wise that will be just one more board to back paddle to CAR.  
> Anyone
> else have a thought on this?
>

Since people always copy from existing boards and keep changing them  
until it works, a patch that moves all existing 440 boards to CAR  
would most likely solve the problem better than a rule. Want to give  
it a try?

Stefan




> -- 
> Thanks,
> Joseph Smith
> Set-Top-Linux
> www.settoplinux.org
>
>
> -- 
> coreboot mailing list: coreboot at coreboot.org
> http://www.coreboot.org/mailman/listinfo/coreboot
>



From patrick at georgi-clan.de  Wed Jun  9 13:08:32 2010
From: patrick at georgi-clan.de (Patrick Georgi)
Date: Wed, 09 Jun 2010 13:08:32 +0200
Subject: [coreboot] PATCH: ECS P6IWP-Fe
In-Reply-To: <E05A6BE4-C523-4783-B8E0-BE8B10BACAD3@coresystems.de>
References: <1276041446.1596.5.camel@anders-laptop>	<4C0F4C31.8040907@coresystems.de>	<bd417ec0e08ccae701233c5eccaefafe@imap.1and1.com>
	<E05A6BE4-C523-4783-B8E0-BE8B10BACAD3@coresystems.de>
Message-ID: <4C0F7630.9060904@georgi-clan.de>

Am 09.06.2010 13:00, schrieb Stefan Reinauer:
> Since people always copy from existing boards and keep changing them
> until it works, a patch that moves all existing 440 boards to CAR would
> most likely solve the problem better than a rule. Want to give it a try?
This doesn't catch the boards that were copied months ago (but of course
it helps)


Patrick



From joe at settoplinux.org  Wed Jun  9 13:16:48 2010
From: joe at settoplinux.org (Joseph Smith)
Date: Wed, 09 Jun 2010 07:16:48 -0400
Subject: [coreboot] PATCH: ECS P6IWP-Fe
In-Reply-To: <E05A6BE4-C523-4783-B8E0-BE8B10BACAD3@coresystems.de>
References: <1276041446.1596.5.camel@anders-laptop>
	<4C0F4C31.8040907@coresystems.de>
	<bd417ec0e08ccae701233c5eccaefafe@imap.1and1.com>
	<E05A6BE4-C523-4783-B8E0-BE8B10BACAD3@coresystems.de>
Message-ID: <00852b49f7d1b4ae1b02d978245a62d8@imap.1and1.com>




On Wed, 9 Jun 2010 13:00:26 +0200, Stefan Reinauer
<stefan.reinauer at coresystems.de> wrote:
> 
> On 09.06.2010, at 12:47, Joseph Smith <joe at settoplinux.org> wrote:
> 
>>
>>
>>
>> On Wed, 09 Jun 2010 10:09:21 +0200, Stefan Reinauer
> <stepan at coresystems.de
>> >
>> wrote:
>>> On 6/9/10 1:57 AM, Anders Jenbo wrote:
>>>> This patch adds the ECS P6IWP-Fe board to coreboot.
>>>>
>>>> Signed-off-by: Anders Jenbo <anders at jenbo.dk>
>>>
>>> Thanks a lot!
>>>
>>> Acked-by: Stefan Reinauer <stepan at coresystems.de>
>>> and checked in as r5623
>>>
>>> But please add a license header to the device tree as well in an
>>> extra
>>> patch..
>>>
>> Yes thanks Anders :-)
>> One more suggestion. I think from this point forward there is really
>> no
>> excuse for any Intel 440bx and up to be using romcc. I feel there
>> should be
>> a new rule, any new boards 440bx and up need to be running CAR for a
>> Ack.
>> Other wise that will be just one more board to back paddle to CAR.
>> Anyone
>> else have a thought on this?
>>
> 
> Since people always copy from existing boards and keep changing them
> until it works, a patch that moves all existing 440 boards to CAR
> would most likely solve the problem better than a rule. Want to give
> it a try?
> 
I could but not sure how much sense that would make considering I do not
have a 440bx to test....

On the other hand I do have some i810's, That chip I would be glad to
convert :-)

-- 
Thanks,
Joseph Smith
Set-Top-Linux
www.settoplinux.org




From joe at settoplinux.org  Wed Jun  9 14:44:42 2010
From: joe at settoplinux.org (Joseph Smith)
Date: Wed, 09 Jun 2010 08:44:42 -0400
Subject: [coreboot] PATCH: ECS P6IWP-Fe
In-Reply-To: <00852b49f7d1b4ae1b02d978245a62d8@imap.1and1.com>
References: <1276041446.1596.5.camel@anders-laptop>
	<4C0F4C31.8040907@coresystems.de>
	<bd417ec0e08ccae701233c5eccaefafe@imap.1and1.com>
	<E05A6BE4-C523-4783-B8E0-BE8B10BACAD3@coresystems.de>
	<00852b49f7d1b4ae1b02d978245a62d8@imap.1and1.com>
Message-ID: <ef879181119d8a20be984b2b7b086ed2@imap.1and1.com>




On Wed, 09 Jun 2010 07:16:48 -0400, Joseph Smith <joe at settoplinux.org>
wrote:
> 
> 
> 
> On Wed, 9 Jun 2010 13:00:26 +0200, Stefan Reinauer
> <stefan.reinauer at coresystems.de> wrote:
>>
>> On 09.06.2010, at 12:47, Joseph Smith <joe at settoplinux.org> wrote:
>>
>>>
>>>
>>>
>>> On Wed, 09 Jun 2010 10:09:21 +0200, Stefan Reinauer
>> <stepan at coresystems.de
>>> >
>>> wrote:
>>>> On 6/9/10 1:57 AM, Anders Jenbo wrote:
>>>>> This patch adds the ECS P6IWP-Fe board to coreboot.
>>>>>
>>>>> Signed-off-by: Anders Jenbo <anders at jenbo.dk>
>>>>
>>>> Thanks a lot!
>>>>
>>>> Acked-by: Stefan Reinauer <stepan at coresystems.de>
>>>> and checked in as r5623
>>>>
>>>> But please add a license header to the device tree as well in an
>>>> extra
>>>> patch..
>>>>
>>> Yes thanks Anders :-)
>>> One more suggestion. I think from this point forward there is really
>>> no
>>> excuse for any Intel 440bx and up to be using romcc. I feel there
>>> should be
>>> a new rule, any new boards 440bx and up need to be running CAR for a
>>> Ack.
>>> Other wise that will be just one more board to back paddle to CAR.
>>> Anyone
>>> else have a thought on this?
>>>
>>
>> Since people always copy from existing boards and keep changing them
>> until it works, a patch that moves all existing 440 boards to CAR
>> would most likely solve the problem better than a rule. Want to give
>> it a try?
>>
> I could but not sure how much sense that would make considering I do not
> have a 440bx to test....
> 
> On the other hand I do have some i810's, That chip I would be glad to
> convert :-)
> 
Yes, this is going to be a new side project. 
Hey maybe a i815 port will even come out of it :-)

-- 
Thanks,
Joseph Smith
Set-Top-Linux
www.settoplinux.org




From mylesgw at gmail.com  Wed Jun  9 15:06:28 2010
From: mylesgw at gmail.com (Myles Watson)
Date: Wed, 9 Jun 2010 07:06:28 -0600
Subject: [coreboot] [PATCH] avoid IO resource conflicts
In-Reply-To: <4C0F55A0.2010506@coresystems.de>
References: <4C0F55A0.2010506@coresystems.de>
Message-ID: <66A3708ACCC04083BB083EFA89ED596D@chimp>

Acked-by: Myles Watson <mylesgw at gmail.com>

Is 0x1000 standard now?  Should we just bump everything up that isn't there
yet?

Thanks,
Myles




From edwin_beasant at virtensys.com  Wed Jun  9 15:55:04 2010
From: edwin_beasant at virtensys.com (Edwin Beasant)
Date: Wed, 9 Jun 2010 14:55:04 +0100
Subject: [coreboot] PATCH: Porting v3-style Geode LX cpu init to v4
Message-ID: <95EC52016CC5DE4896FD95FA7323A4DB152FFE4535@mr-burns.exchange.virtensys.com>

This patch moves the GLCP Delay control register calculation and cpuInit functions over from v3 into v4.
This fixes a bug whereby boards that use terminated DRAM and manual PLL configuration fail to set a correct GLCP_DELAY_CONTROL.
This also imports a v3 style msrinit_t structure into the msr.h.


Signed-off-by: Edwin Beasant <edwin_beasant at virtensys.com>

---



Edwin Beasant

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20100609/a6ffb824/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: coreboot-v4-lx-cpuinit-port.patch
Type: application/octet-stream
Size: 17706 bytes
Desc: coreboot-v4-lx-cpuinit-port.patch
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20100609/a6ffb824/attachment.obj>

From anders at jenbo.dk  Wed Jun  9 16:02:46 2010
From: anders at jenbo.dk (=?utf-8?B?YW5kZXJzQGplbmJvLmRr?=)
Date: Wed, 09 Jun 2010 16:02:46 +0200
Subject: [coreboot] =?utf-8?q?Indtast_Bcc__PATCH=3A_ECS_P6IWP-Fe?=
Message-ID: <mailman.4191.1355071773.16123.coreboot@coreboot.org>

Oh ok, was not aware that that was possible.

Mvh Anders

----- Reply message -----
Fra: "Stefan Reinauer" <stepan at coresystems.de>
Dato: ons., jun. 9, 2010 10:09
Emne: [coreboot] PATCH: ECS P6IWP-Fe
Til: <coreboot at coreboot.org>

On 6/9/10 1:57 AM, Anders Jenbo wrote:
> This patch adds the ECS P6IWP-Fe board to coreboot.
>
> Signed-off-by: Anders Jenbo <anders at jenbo.dk>

Thanks a lot!

Acked-by: Stefan Reinauer <stepan at coresystems.de>
and checked in as r5623

But please add a license header to the device tree as well in an extra
patch..

Stefan

-- 
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/20100609/cff25ed4/attachment.html>

From anders at jenbo.dk  Wed Jun  9 16:26:31 2010
From: anders at jenbo.dk (=?utf-8?B?YW5kZXJzQGplbmJvLmRr?=)
Date: Wed, 09 Jun 2010 16:26:31 +0200
Subject: [coreboot] =?utf-8?q?Re__PATCH=3A_ECS_P6IWP-Fe?=
Message-ID: <mailman.4192.1355071773.16123.coreboot@coreboot.org>

Agreed, the only reason I haven't done car yet is that I haven't had a board where the best match to copy from used CAR. I defiantly hav plans for updating all the boards I have to car but I am waiting til I hit a board where car is the best match or I run out if board / easy targets.

By then I might help out with porting the 440bx boards (is 440lx below?).

Mvh Anders

----- Reply message -----
Fra: "Joseph Smith" <joe at settoplinux.org>
Dato: ons., jun. 9, 2010 14:44
Emne: [coreboot] PATCH: ECS P6IWP-Fe
Til: <coreboot at coreboot.org>
Cc: "Stefan Reinauer" <stefan.reinauer at coresystems.de>





On Wed, 09 Jun 2010 07:16:48 -0400, Joseph Smith <joe at settoplinux.org>
wrote:
> 
> 
> 
> On Wed, 9 Jun 2010 13:00:26 +0200, Stefan Reinauer
> <stefan.reinauer at coresystems.de> wrote:
>>
>> On 09.06.2010, at 12:47, Joseph Smith <joe at settoplinux.org> wrote:
>>
>>>
>>>
>>>
>>> On Wed, 09 Jun 2010 10:09:21 +0200, Stefan Reinauer
>> <stepan at coresystems.de
>>> >
>>> wrote:
>>>> On 6/9/10 1:57 AM, Anders Jenbo wrote:
>>>>> This patch adds the ECS P6IWP-Fe board to coreboot.
>>>>>
>>>>> Signed-off-by: Anders Jenbo <anders at jenbo.dk>
>>>>
>>>> Thanks a lot!
>>>>
>>>> Acked-by: Stefan Reinauer <stepan at coresystems.de>
>>>> and checked in as r5623
>>>>
>>>> But please add a license header to the device tree as well in an
>>>> extra
>>>> patch..
>>>>
>>> Yes thanks Anders :-)
>>> One more suggestion. I think from this point forward there is really
>>> no
>>> excuse for any Intel 440bx and up to be using romcc. I feel there
>>> should be
>>> a new rule, any new boards 440bx and up need to be running CAR for a
>>> Ack.
>>> Other wise that will be just one more board to back paddle to CAR.
>>> Anyone
>>> else have a thought on this?
>>>
>>
>> Since people always copy from existing boards and keep changing them
>> until it works, a patch that moves all existing 440 boards to CAR
>> would most likely solve the problem better than a rule. Want to give
>> it a try?
>>
> I could but not sure how much sense that would make considering I do not
> have a 440bx to test....
> 
> On the other hand I do have some i810's, That chip I would be glad to
> convert :-)
> 
Yes, this is going to be a new side project. 
Hey maybe a i815 port will even come out of it :-)

-- 
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/20100609/96e9c509/attachment.html>

From mylesgw at gmail.com  Wed Jun  9 16:25:25 2010
From: mylesgw at gmail.com (Myles Watson)
Date: Wed, 9 Jun 2010 08:25:25 -0600
Subject: [coreboot] unable to boot linux with coreboot
In-Reply-To: <1276026925.3803.54.camel@andrala.reboot>
References: <1276026925.3803.54.camel@andrala.reboot>
Message-ID: <AANLkTinByqVUaavWHsFHcrjNhe_zTqKZZKAlyJl4Z32w@mail.gmail.com>

On Tue, Jun 8, 2010 at 1:55 PM, mbertens <mbertens at xs4all.nl> wrote:
> Hi all,
>
> i have a strong problem that im not able to boot any os wit coreboot, it
> starts (linux) ut it hangs after 128 sec.
>
> http://pastebin.com/uBT8JdH4
>
> Anyone any ideas
I think you'd get a better response if you gave a little more information:

1. Have you ever been able to boot Linux with Coreboot?  If yes, what
revision?  Have you checked to see what revision broke it?

2.  What loader are you using?  I know I could tell by going to the
link, but more information in the mail helps generate interest enough
to follow the link.

3....  Anything else you think is relevant.

Thanks,
Myles



From mylesgw at gmail.com  Wed Jun  9 16:57:04 2010
From: mylesgw at gmail.com (Myles Watson)
Date: Wed, 9 Jun 2010 08:57:04 -0600
Subject: [coreboot] [PATCH] lists of links
Message-ID: <AANLkTilYFrq7PgDTJJVh05L79wdadM6m7QSvKII-kA1g@mail.gmail.com>

Same conversion as with resources from static arrays to lists, except
there is no free list.

Converting resource arrays to lists reduced the size of each device
struct from 1092 to 228 bytes.
Converting link arrays to lists reduced the size of each device struct
from 228 to 68 bytes.

fam10_pci.diff makes fam10 and k8 northbridge code a little more
similar before the conversion.

The next step for fam10 and k8 would be to reorganize the links so
that the southbridge link is always first.  This would make some of
the code a lot easier to follow.  Something to consider would be
adding link numbers to the device tree, since that would allow the
southbridge link to start in the correct place.

Signed-off-by: Myles Watson <mylesgw at gmail.com>

Abuild tested.  Boot tested on serengeti_cheetah,
serengeti_cheetah_fam10, and qemu.

Thanks,
Myles
-------------- next part --------------
A non-text attachment was scrubbed...
Name: fam10_pci.diff
Type: text/x-patch
Size: 29506 bytes
Desc: not available
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20100609/efd8e71c/attachment.diff>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: links.diff
Type: text/x-patch
Size: 102346 bytes
Desc: not available
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20100609/efd8e71c/attachment-0001.diff>

From ziltro at ziltro.com  Wed Jun  9 17:43:48 2010
From: ziltro at ziltro.com (Andrew Morgan)
Date: Wed, 09 Jun 2010 16:43:48 +0100
Subject: [coreboot] [PATCH] SeaBIOS CD/DVD abbreviations
In-Reply-To: <4C0F465D.4040901@coresystems.de>
References: <4C0F465D.4040901@coresystems.de>
Message-ID: <4C0FB6B4.2070906@ziltro.com>

Just a small point, the "ROM" bit isn't really needed. The fact that CDs 
are read-only is pretty much irrelevant. No other type of disk gets -ROM 
or -RAM stuck on the end of it. Also some CDs aren't read only...

-- 

Andrew.




From joe at settoplinux.org  Wed Jun  9 18:01:14 2010
From: joe at settoplinux.org (Joseph Smith)
Date: Wed, 09 Jun 2010 12:01:14 -0400
Subject: [coreboot] Re  PATCH: ECS P6IWP-Fe
In-Reply-To: <0M7I3a-1PFqm13SdC-00x3vi@mx.perfora.net>
References: <0M7I3a-1PFqm13SdC-00x3vi@mx.perfora.net>
Message-ID: <fb238673d64fb2b07e0ec7b85ed69eac@imap.1and1.com>




On Wed, 09 Jun 2010 16:26:31 +0200, "anders at jenbo.dk" <anders at jenbo.dk>
wrote:
> Agreed, the only reason I haven't done car yet is that I haven't had a
> board where the best match to copy from used CAR. I defiantly hav plans
for
> updating all the boards I have to car but I am waiting til I hit a board
> where car is the best match or I run out if board / easy targets.
> 
> By then I might help out with porting the 440bx boards (is 440lx below?).
> 
No worries CAR for i810/socket_370 will be coming on the next few days :-)
I am really excited to get rid of that model_6xx clump-o-crap.

Anders you should really get togethor with Keith on the 440bx CAR
conversion.

-- 
Thanks,
Joseph Smith
Set-Top-Linux
www.settoplinux.org




From joe at settoplinux.org  Wed Jun  9 19:54:12 2010
From: joe at settoplinux.org (Joseph Smith)
Date: Wed, 09 Jun 2010 13:54:12 -0400
Subject: [coreboot] [PATCH] SeaBIOS VGA hooks
In-Reply-To: <4C0F4698.6000405@coresystems.de>
References: <4C0F4698.6000405@coresystems.de>
Message-ID: <45495d41b1c114226683bc2958f9f54a@imap.1and1.com>


On Wed, 09 Jun 2010 09:45:28 +0200, Stefan Reinauer
<stefan.reinauer at coresystems.de> wrote:
> SeaBIOS VGA hooks for Getac P470 and Roda RK886EX notebooks
> 
This is awsome!
Acked-by: Joseph Smith <joe at settoplinux.org>

Any chance for a SMI Handler for SeaBIOS coming up?

-- 
Thanks,
Joseph Smith
Set-Top-Linux
www.settoplinux.org




From stefan.reinauer at coresystems.de  Wed Jun  9 19:55:36 2010
From: stefan.reinauer at coresystems.de (Stefan Reinauer)
Date: Wed, 09 Jun 2010 19:55:36 +0200
Subject: [coreboot] [PATCH] SeaBIOS VGA hooks
In-Reply-To: <45495d41b1c114226683bc2958f9f54a@imap.1and1.com>
References: <4C0F4698.6000405@coresystems.de>
	<45495d41b1c114226683bc2958f9f54a@imap.1and1.com>
Message-ID: <4C0FD598.8000205@coresystems.de>

On 6/9/10 7:54 PM, Joseph Smith wrote:
> On Wed, 09 Jun 2010 09:45:28 +0200, Stefan Reinauer
> <stefan.reinauer at coresystems.de> wrote:
>   
>> SeaBIOS VGA hooks for Getac P470 and Roda RK886EX notebooks
>>
>>     
> This is awsome!
> Acked-by: Joseph Smith <joe at settoplinux.org>
>
> Any chance for a SMI Handler for SeaBIOS coming up?
>
>   
No... What would that be good for?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20100609/120f69e8/attachment.html>

From mylesgw at gmail.com  Wed Jun  9 20:00:41 2010
From: mylesgw at gmail.com (Myles Watson)
Date: Wed, 9 Jun 2010 12:00:41 -0600
Subject: [coreboot] [PATCH] SeaBIOS VGA hooks
In-Reply-To: <4C0F4698.6000405@coresystems.de>
References: <4C0F4698.6000405@coresystems.de>
Message-ID: <AANLkTikDo087UjGhFfQUzZvBEFk4wBlYkZJHdPkoC2aC@mail.gmail.com>

On Wed, Jun 9, 2010 at 1:45 AM, Stefan Reinauer
<stefan.reinauer at coresystems.de> wrote:
> SeaBIOS VGA hooks for Getac P470 and Roda RK886EX notebooks

It seems surprising to want to make SeaBIOS have this much stuff
that's board-specific.  It seems like a more generic way to set hooks
from CBFS would be nice.

I'm thinking something like seabios/hooks which has a list of
interrupts handlers and where they should be installed.

Thanks,
Myles



From joe at settoplinux.org  Wed Jun  9 20:06:51 2010
From: joe at settoplinux.org (Joseph Smith)
Date: Wed, 09 Jun 2010 14:06:51 -0400
Subject: [coreboot] [PATCH] SeaBIOS VGA hooks
In-Reply-To: <AANLkTikDo087UjGhFfQUzZvBEFk4wBlYkZJHdPkoC2aC@mail.gmail.com>
References: <4C0F4698.6000405@coresystems.de>
	<AANLkTikDo087UjGhFfQUzZvBEFk4wBlYkZJHdPkoC2aC@mail.gmail.com>
Message-ID: <8e1fcf4bfa2f67aadd5867e5fdf37fdc@imap.1and1.com>




On Wed, 9 Jun 2010 12:00:41 -0600, Myles Watson <mylesgw at gmail.com> wrote:
> On Wed, Jun 9, 2010 at 1:45 AM, Stefan Reinauer
> <stefan.reinauer at coresystems.de> wrote:
>> SeaBIOS VGA hooks for Getac P470 and Roda RK886EX notebooks
> 
> It seems surprising to want to make SeaBIOS have this much stuff
> that's board-specific.  It seems like a more generic way to set hooks
> from CBFS would be nice.
> 
> I'm thinking something like seabios/hooks which has a list of
> interrupts handlers and where they should be installed.
> 
True, probibly could be more generic, just about any Intel vbios is going
to have the potential of INT15 5F hooks enabled.
But I think we should get this in for now, and genericize it in the future
as more things get added.

-- 
Thanks,
Joseph Smith
Set-Top-Linux
www.settoplinux.org




From joe at settoplinux.org  Wed Jun  9 20:11:04 2010
From: joe at settoplinux.org (Joseph Smith)
Date: Wed, 09 Jun 2010 14:11:04 -0400
Subject: [coreboot] [PATCH] SeaBIOS VGA hooks
In-Reply-To: <4C0FD598.8000205@coresystems.de>
References: <4C0F4698.6000405@coresystems.de>
	<45495d41b1c114226683bc2958f9f54a@imap.1and1.com>
	<4C0FD598.8000205@coresystems.de>
Message-ID: <35e995abc9a5fc8b5ce093d390cd450a@imap.1and1.com>




On Wed, 09 Jun 2010 19:55:36 +0200, Stefan Reinauer
<stefan.reinauer at coresystems.de> wrote:
> On 6/9/10 7:54 PM, Joseph Smith wrote:
>> On Wed, 09 Jun 2010 09:45:28 +0200, Stefan Reinauer
>> <stefan.reinauer at coresystems.de> wrote:
>>
>>> SeaBIOS VGA hooks for Getac P470 and Roda RK886EX notebooks
>>>
>>>
>> This is awsome!
>> Acked-by: Joseph Smith <joe at settoplinux.org>
>>
>> Any chance for a SMI Handler for SeaBIOS coming up?
>>
>>
> No... What would that be good for?

Uh, MBI?

-- 
Thanks,
Joseph Smith
Set-Top-Linux
www.settoplinux.org




From stefan.reinauer at coresystems.de  Wed Jun  9 20:34:45 2010
From: stefan.reinauer at coresystems.de (Stefan Reinauer)
Date: Wed, 09 Jun 2010 20:34:45 +0200
Subject: [coreboot] [PATCH] SeaBIOS VGA hooks
In-Reply-To: <AANLkTikDo087UjGhFfQUzZvBEFk4wBlYkZJHdPkoC2aC@mail.gmail.com>
References: <4C0F4698.6000405@coresystems.de>
	<AANLkTikDo087UjGhFfQUzZvBEFk4wBlYkZJHdPkoC2aC@mail.gmail.com>
Message-ID: <4C0FDEC5.70702@coresystems.de>

On 6/9/10 8:00 PM, Myles Watson wrote:
> On Wed, Jun 9, 2010 at 1:45 AM, Stefan Reinauer
> <stefan.reinauer at coresystems.de> wrote:
>   
>> SeaBIOS VGA hooks for Getac P470 and Roda RK886EX notebooks
>>     
> It seems surprising to want to make SeaBIOS have this much stuff
> that's board-specific. 
int15 hooks are designed to be board specific.

>  It seems like a more generic way to set hooks
> from CBFS would be nice.
>   
Loading an int handler dynamically from CBFS and linking it at runtime?
Sounds doable but complex.
As long as it's only 2 intel and a number of VIA based boards that
require a special int15 handler it might not be that bad.

Generally it's also possible to locally patch the SeaBIOS source code.
The runtime distinction is only required if you want to use the same
SeaBIOS binary on several mainboards that require to have different
int15 handlers.

> I'm thinking something like seabios/hooks which has a list of
> interrupts handlers and where they should be installed.
>   
It would need to be 0xe0000 - 0xfffff unless we want to start cutting
out more memory.
Alternatively we could add an SMI "function call" to coreboot that does
the deed. That would simplify the code in SeaBIOS significantly but add
more requirements for SMM.

Stefan




From stefan.reinauer at coresystems.de  Wed Jun  9 20:38:22 2010
From: stefan.reinauer at coresystems.de (Stefan Reinauer)
Date: Wed, 09 Jun 2010 20:38:22 +0200
Subject: [coreboot] [PATCH] SeaBIOS VGA hooks
In-Reply-To: <35e995abc9a5fc8b5ce093d390cd450a@imap.1and1.com>
References: <4C0F4698.6000405@coresystems.de>	<45495d41b1c114226683bc2958f9f54a@imap.1and1.com>	<4C0FD598.8000205@coresystems.de>
	<35e995abc9a5fc8b5ce093d390cd450a@imap.1and1.com>
Message-ID: <4C0FDF9E.6020102@coresystems.de>

On 6/9/10 8:11 PM, Joseph Smith wrote:
>
>
> On Wed, 09 Jun 2010 19:55:36 +0200, Stefan Reinauer
> <stefan.reinauer at coresystems.de> wrote:
>   
>> On 6/9/10 7:54 PM, Joseph Smith wrote:
>>     
>>> On Wed, 09 Jun 2010 09:45:28 +0200, Stefan Reinauer
>>> <stefan.reinauer at coresystems.de> wrote:
>>>
>>>       
>>>> SeaBIOS VGA hooks for Getac P470 and Roda RK886EX notebooks
>>>>
>>>>
>>>>         
>>> This is awsome!
>>> Acked-by: Joseph Smith <joe at settoplinux.org>
>>>
>>> Any chance for a SMI Handler for SeaBIOS coming up?
>>>
>>>
>>>       
>> No... What would that be good for?
>>     
> Uh, MBI?
>   
The coreboot SMI handler already implements that. Remember SMI handlers
stay active even when the OS is loaded.

For security reasons coreboot even locks SMM so that SeaBIOS (or a Linux
kernel module or root process) couldn't  just install a new handler.
When experimenting that lock can of course be disabled in the coreboot
source.




From svn at coreboot.org  Wed Jun  9 21:07:20 2010
From: svn at coreboot.org (repository service)
Date: Wed, 09 Jun 2010 21:07:20 +0200
Subject: [coreboot] [commit] r5624 - in trunk/src/southbridge: amd/cs5530
	via/vt8231 via/vt8235
Message-ID: <E1OMQcS-0006BW-8K@ra.coresystems.de>

Author: stepan
Date: Wed Jun  9 21:07:19 2010
New Revision: 5624
URL: https://tracker.coreboot.org/trac/coreboot/changeset/5624

Log:
The interrupt controller lives at I/O 0x4d0/0x4d1.
However on these platforms we were causing a resource conflict by
letting the resource allocator start allocations at 0x400.
Change the constraints to start at 0x1000 so we avoid allocating over
LPT ports (0x778-0x77f), PCI (0xcf8-0xcff) and some other fixed
resources that might live down there (smbus base, acpi base,...)

Signed-off-by: Stefan Reinauer <stepan at coresystems.de>
Acked-by: Myles Watson <mylesgw at gmail.com>

Modified:
   trunk/src/southbridge/amd/cs5530/cs5530_isa.c
   trunk/src/southbridge/via/vt8231/vt8231_lpc.c
   trunk/src/southbridge/via/vt8235/vt8235_lpc.c

Modified: trunk/src/southbridge/amd/cs5530/cs5530_isa.c
==============================================================================
--- trunk/src/southbridge/amd/cs5530/cs5530_isa.c	Wed Jun  9 10:08:12 2010	(r5623)
+++ trunk/src/southbridge/amd/cs5530/cs5530_isa.c	Wed Jun  9 21:07:19 2010	(r5624)
@@ -33,7 +33,7 @@
 
 	res = new_resource(dev, 1);
 	res->base = 0x0UL;
-	res->size = 0x400UL;
+	res->size = 0x1000UL;
 	res->limit = 0xffffUL;
 	res->flags = IORESOURCE_IO | IORESOURCE_ASSIGNED | IORESOURCE_FIXED;
 

Modified: trunk/src/southbridge/via/vt8231/vt8231_lpc.c
==============================================================================
--- trunk/src/southbridge/via/vt8231/vt8231_lpc.c	Wed Jun  9 10:08:12 2010	(r5623)
+++ trunk/src/southbridge/via/vt8231/vt8231_lpc.c	Wed Jun  9 21:07:19 2010	(r5624)
@@ -136,7 +136,7 @@
 
 	res = new_resource(dev, 1);
 	res->base = 0x0UL;
-	res->size = 0x400UL;
+	res->size = 0x1000UL;
 	res->limit = 0xffffUL;
 	res->flags = IORESOURCE_IO | IORESOURCE_ASSIGNED | IORESOURCE_FIXED;
 

Modified: trunk/src/southbridge/via/vt8235/vt8235_lpc.c
==============================================================================
--- trunk/src/southbridge/via/vt8235/vt8235_lpc.c	Wed Jun  9 10:08:12 2010	(r5623)
+++ trunk/src/southbridge/via/vt8235/vt8235_lpc.c	Wed Jun  9 21:07:19 2010	(r5624)
@@ -110,7 +110,7 @@
 	// Set gen config 0
 	pci_write_config8(dev, 0x80, 0x20);
 
-	// Set ACPI base address to IO 0x4000
+	// Set ACPI base address to IO 0x400
 	pci_write_config16(dev, 0x88, 0x0401);
 
 	// set ACPI irq to 5
@@ -223,7 +223,7 @@
 
 	res = new_resource(dev, 1);
 	res->base = 0x0UL;
-	res->size = 0x400UL;
+	res->size = 0x1000UL;
 	res->limit = 0xffffUL;
 	res->flags = IORESOURCE_IO | IORESOURCE_ASSIGNED | IORESOURCE_FIXED;
 



From stefan.reinauer at coresystems.de  Wed Jun  9 21:10:13 2010
From: stefan.reinauer at coresystems.de (Stefan Reinauer)
Date: Wed, 09 Jun 2010 21:10:13 +0200
Subject: [coreboot] [PATCH] SeaBIOS CD/DVD abbreviations
In-Reply-To: <4C0FB6B4.2070906@ziltro.com>
References: <4C0F465D.4040901@coresystems.de> <4C0FB6B4.2070906@ziltro.com>
Message-ID: <4C0FE715.4010302@coresystems.de>

On 6/9/10 5:43 PM, Andrew Morgan wrote:
> Just a small point, the "ROM" bit isn't really needed. The fact that
> CDs are read-only is pretty much irrelevant. No other type of disk
> gets -ROM or -RAM stuck on the end of it. Also some CDs aren't read
> only...

Good point.
Updated patch attached
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: seabios-dvd.diff
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20100609/790e06e5/attachment.ksh>

From mylesgw at gmail.com  Wed Jun  9 20:48:02 2010
From: mylesgw at gmail.com (Myles Watson)
Date: Wed, 9 Jun 2010 12:48:02 -0600
Subject: [coreboot] [PATCH] SeaBIOS VGA hooks
In-Reply-To: <4C0FDEC5.70702@coresystems.de>
References: <4C0F4698.6000405@coresystems.de>
	<AANLkTikDo087UjGhFfQUzZvBEFk4wBlYkZJHdPkoC2aC@mail.gmail.com>
	<4C0FDEC5.70702@coresystems.de>
Message-ID: <AANLkTikyO4eG4TT3Qr-b6NK4yMvGv1K39HIR69DZMsNS@mail.gmail.com>

On Wed, Jun 9, 2010 at 12:34 PM, Stefan Reinauer
<stefan.reinauer at coresystems.de> wrote:
> On 6/9/10 8:00 PM, Myles Watson wrote:
>> On Wed, Jun 9, 2010 at 1:45 AM, Stefan Reinauer
>> <stefan.reinauer at coresystems.de> wrote:
>>
>>> SeaBIOS VGA hooks for Getac P470 and Roda RK886EX notebooks
>>>
>> It seems surprising to want to make SeaBIOS have this much stuff
>> that's board-specific.
> int15 hooks are designed to be board specific.
>
>> ?It seems like a more generic way to set hooks
>> from CBFS would be nice.
>>
> Loading an int handler dynamically from CBFS and linking it at runtime?
> Sounds doable but complex.
It may not be worth the trouble.

> As long as it's only 2 intel and a number of VIA based boards that
> require a special int15 handler it might not be that bad.
>
> Generally it's also possible to locally patch the SeaBIOS source code.
Sure.  Harder for end users, but just as easy for developers.

> The runtime distinction is only required if you want to use the same
> SeaBIOS binary on several mainboards that require to have different
> int15 handlers.
>
>> I'm thinking something like seabios/hooks which has a list of
>> interrupts handlers and where they should be installed.
>>
> It would need to be 0xe0000 - 0xfffff unless we want to start cutting
> out more memory.
I meant where as in what interrupt to patch, not what address to run
at.  SeaBIOS should be able to use whatever address it wants to.

> Alternatively we could add an SMI "function call" to coreboot that does
> the deed. That would simplify the code in SeaBIOS significantly but add
> more requirements for SMM.

I'm not sure what's best.  Maybe few enough boards will need their own
handlers that it doesn't really matter.

Thanks,
Myles



From oliver at schinagl.nl  Wed Jun  9 21:24:20 2010
From: oliver at schinagl.nl (Oliver Schinagl)
Date: Wed, 09 Jun 2010 21:24:20 +0200
Subject: [coreboot] Minor update on IDE mode on Wyse S10 (CS5536)
Message-ID: <4C0FEA64.7060704@schinagl.nl>

I built a 2.6.24.7 kernel almost exactly to Nils his config, had to 
change some things like USB storage as my main boot medium, and it 
worked. I think the generic IDE driver loads up, still says 'IDE 
disabled' but then probes for hdb en hda. hda actually is a Transcend 
IDE disk (Compact Flash sort of IDE disk, but still).

hdparm -tT reports a whopping 1.87mb/s and I can't enable DMA, operation 
not permitted, suggesting the chipset driver is missing, which I belive 
is compiled in.

The more interesting part though is, that I was able to install 
partitions, grub and actually am booting and running with said 2.6.24.7 
kernel and openwrt distro! I attached a new lspci -vvvxxx output, which 
shows slightly different IDE timings.

In any case, I went trough the CS5536 documentation and also found MSR 
stuff about enabling the IDE port (or hooking it to flash chips 
directly) and that there where certain 'balls' that also setup the board 
a certain way. After checking the pinout of the CS5536 and using the 
very handy msrutil I found the IDE port is actually connected in IDE 
mode, and why the bios lists stupid notions about the port being 
disabled baffles me.

I am now ready I think to start giving coreboot a whirl on this thing. 
Though I still wonder, if the bios can boot the kernel from the IDE 
'drive', I assume coreboot will equally be able to boot it; but if 
recent kernels refuse to use the disk, I may end up being screwed anyway 
:S. Well I could always make a big initrd I suppose with everything in 
it ...

Sorry for ranting on this list :p

Oliver
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: lspci_2.6.24.7.txt
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20100609/7e49714c/attachment.txt>

From stefan.reinauer at coresystems.de  Wed Jun  9 21:26:20 2010
From: stefan.reinauer at coresystems.de (Stefan Reinauer)
Date: Wed, 09 Jun 2010 21:26:20 +0200
Subject: [coreboot] [PATCH] SeaBIOS VGA hooks
In-Reply-To: <AANLkTikyO4eG4TT3Qr-b6NK4yMvGv1K39HIR69DZMsNS@mail.gmail.com>
References: <4C0F4698.6000405@coresystems.de>	<AANLkTikDo087UjGhFfQUzZvBEFk4wBlYkZJHdPkoC2aC@mail.gmail.com>	<4C0FDEC5.70702@coresystems.de>
	<AANLkTikyO4eG4TT3Qr-b6NK4yMvGv1K39HIR69DZMsNS@mail.gmail.com>
Message-ID: <4C0FEADC.4090800@coresystems.de>

On 6/9/10 8:48 PM, Myles Watson wrote:
>> > It would need to be 0xe0000 - 0xfffff unless we want to start cutting
>> > out more memory.
>>     
> I meant where as in what interrupt to patch, not what address to run
> at.  SeaBIOS should be able to use whatever address it wants to.
>   
If it contains a dynamic linker, or the code is position independent, yes.

>> > Alternatively we could add an SMI "function call" to coreboot that does
>> > the deed. That would simplify the code in SeaBIOS significantly but add
>> > more requirements for SMM.
>>     
> I'm not sure what's best.  Maybe few enough boards will need their own
> handlers that it doesn't really matter.
>   
Kevin, any preference?



From joe at settoplinux.org  Wed Jun  9 22:15:59 2010
From: joe at settoplinux.org (Joseph Smith)
Date: Wed, 09 Jun 2010 16:15:59 -0400
Subject: [coreboot] [PATCH] SeaBIOS VGA hooks
In-Reply-To: <4C0FDF9E.6020102@coresystems.de>
References: <4C0F4698.6000405@coresystems.de>	<45495d41b1c114226683bc2958f9f54a@imap.1and1.com>	<4C0FD598.8000205@coresystems.de>	<35e995abc9a5fc8b5ce093d390cd450a@imap.1and1.com>
	<4C0FDF9E.6020102@coresystems.de>
Message-ID: <4C0FF67F.2070508@settoplinux.org>

On 06/09/2010 02:38 PM, Stefan Reinauer wrote:
> On 6/9/10 8:11 PM, Joseph Smith wrote:
>>
>>
>> On Wed, 09 Jun 2010 19:55:36 +0200, Stefan Reinauer
>> <stefan.reinauer at coresystems.de>  wrote:
>>
>>> On 6/9/10 7:54 PM, Joseph Smith wrote:
>>>
>>>> On Wed, 09 Jun 2010 09:45:28 +0200, Stefan Reinauer
>>>> <stefan.reinauer at coresystems.de>  wrote:
>>>>
>>>>
>>>>> SeaBIOS VGA hooks for Getac P470 and Roda RK886EX notebooks
>>>>>
>>>>>
>>>>>
>>>> This is awsome!
>>>> Acked-by: Joseph Smith<joe at settoplinux.org>
>>>>
>>>> Any chance for a SMI Handler for SeaBIOS coming up?
>>>>
>>>>
>>>>
>>> No... What would that be good for?
>>>
>> Uh, MBI?
>>
> The coreboot SMI handler already implements that. Remember SMI handlers
> stay active even when the OS is loaded.
>
> For security reasons coreboot even locks SMM so that SeaBIOS (or a Linux
> kernel module or root process) couldn't  just install a new handler.
> When experimenting that lock can of course be disabled in the coreboot
> source.
>
>
Hmm, if the SMI handler is only implemented when using YABEL than how is 
one supposed to use SeaBIOS to load vga?


-- 
Thanks,
Joseph Smith
Set-Top-Linux
www.settoplinux.org



From stefan.reinauer at coresystems.de  Wed Jun  9 22:57:53 2010
From: stefan.reinauer at coresystems.de (Stefan Reinauer)
Date: Wed, 09 Jun 2010 22:57:53 +0200
Subject: [coreboot] [PATCH] SeaBIOS VGA hooks
In-Reply-To: <4C0FF67F.2070508@settoplinux.org>
References: <4C0F4698.6000405@coresystems.de>	<45495d41b1c114226683bc2958f9f54a@imap.1and1.com>	<4C0FD598.8000205@coresystems.de>	<35e995abc9a5fc8b5ce093d390cd450a@imap.1and1.com>	<4C0FDF9E.6020102@coresystems.de>
	<4C0FF67F.2070508@settoplinux.org>
Message-ID: <4C100051.4010600@coresystems.de>

On 6/9/10 10:15 PM, Joseph Smith wrote:
>> The coreboot SMI handler already implements that. Remember SMI handlers
>> stay active even when the OS is loaded.
>>
>> For security reasons coreboot even locks SMM so that SeaBIOS (or a Linux
>> kernel module or root process) couldn't  just install a new handler.
>> When experimenting that lock can of course be disabled in the coreboot
>> source.
>>
>>
> Hmm, if the SMI handler is only implemented when using YABEL than how
> is one supposed to use SeaBIOS to load vga?

The i82830 SMI handler is implemented and enabled completely independent
of any option rom initialization in coreboot itself.

Stefan



From joe at settoplinux.org  Wed Jun  9 23:03:33 2010
From: joe at settoplinux.org (Joseph Smith)
Date: Wed, 09 Jun 2010 17:03:33 -0400
Subject: [coreboot] [PATCH] SeaBIOS VGA hooks
In-Reply-To: <4C100051.4010600@coresystems.de>
References: <4C0F4698.6000405@coresystems.de>	<45495d41b1c114226683bc2958f9f54a@imap.1and1.com>	<4C0FD598.8000205@coresystems.de>	<35e995abc9a5fc8b5ce093d390cd450a@imap.1and1.com>	<4C0FDF9E.6020102@coresystems.de>	<4C0FF67F.2070508@settoplinux.org>
	<4C100051.4010600@coresystems.de>
Message-ID: <4C1001A5.4090809@settoplinux.org>

On 06/09/2010 04:57 PM, Stefan Reinauer wrote:
> On 6/9/10 10:15 PM, Joseph Smith wrote:
>>> The coreboot SMI handler already implements that. Remember SMI handlers
>>> stay active even when the OS is loaded.
>>>
>>> For security reasons coreboot even locks SMM so that SeaBIOS (or a Linux
>>> kernel module or root process) couldn't  just install a new handler.
>>> When experimenting that lock can of course be disabled in the coreboot
>>> source.
>>>
>>>
>> Hmm, if the SMI handler is only implemented when using YABEL than how
>> is one supposed to use SeaBIOS to load vga?
>
> The i82830 SMI handler is implemented and enabled completely independent
> of any option rom initialization in coreboot itself.
>
Ok cool. Then I guess SeaBIOS just needs to be able to load vga bios and 
mbi rom. Correct?


-- 
Thanks,
Joseph Smith
Set-Top-Linux
www.settoplinux.org



From stefan.reinauer at coresystems.de  Wed Jun  9 23:10:07 2010
From: stefan.reinauer at coresystems.de (Stefan Reinauer)
Date: Wed, 09 Jun 2010 23:10:07 +0200
Subject: [coreboot] [PATCH] SeaBIOS VGA hooks
In-Reply-To: <4C1001A5.4090809@settoplinux.org>
References: <4C0F4698.6000405@coresystems.de>	<45495d41b1c114226683bc2958f9f54a@imap.1and1.com>	<4C0FD598.8000205@coresystems.de>	<35e995abc9a5fc8b5ce093d390cd450a@imap.1and1.com>	<4C0FDF9E.6020102@coresystems.de>	<4C0FF67F.2070508@settoplinux.org>
	<4C100051.4010600@coresystems.de>
	<4C1001A5.4090809@settoplinux.org>
Message-ID: <4C10032F.1000507@coresystems.de>

On 6/9/10 11:03 PM, Joseph Smith wrote:
>>
> Ok cool. Then I guess SeaBIOS just needs to be able to load vga bios
> and mbi rom. Correct?

Not even that complicated. mbi is loaded by coreboot, so SeaBIOS has
everything it needs. It might at some point need a mainboard specific
int15 handler, if that is how you implement TV-out enable.

Stefan
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20100609/069839ca/attachment.html>

From njacobs8 at hetnet.nl  Wed Jun  9 23:21:18 2010
From: njacobs8 at hetnet.nl (Nils)
Date: Wed, 9 Jun 2010 23:21:18 +0200
Subject: [coreboot] Minor update on IDE mode on Wyse S10 (CS5536)
Message-ID: <201006092321.18381.njacobs8@hetnet.nl>

Hi Oliver,
You wrote:
>I am now ready I think to start giving coreboot a whirl on this thing. 
>Though I still wonder, if the bios can boot the kernel from the IDE 
>'drive', I assume coreboot will equally be able to boot it; but if 
>recent kernels refuse to use the disk, I may end up being screwed anyway 
>:S.
As i was trying to explain before, there is nothing wrong with the hardware
or the way the IDE port is connected.
The only problem is the stock bios witch is initializing the IDE port of the
CS5536 as flash port.(that gives troubles if you are using a real IDE harddisk)
When you use coreboot you can enable or disable flash_enable.
Normaly it is disabled so you can use IDE.(But for your flash drive i think you
want flash enabled)
With coreboot you can use a normal recent kernel with the appropriate
drivers.

Succes,Nils



From joe at settoplinux.org  Wed Jun  9 23:39:45 2010
From: joe at settoplinux.org (Joseph Smith)
Date: Wed, 09 Jun 2010 17:39:45 -0400
Subject: [coreboot] Re  PATCH: ECS P6IWP-Fe
In-Reply-To: <fb238673d64fb2b07e0ec7b85ed69eac@imap.1and1.com>
References: <0M7I3a-1PFqm13SdC-00x3vi@mx.perfora.net>
	<fb238673d64fb2b07e0ec7b85ed69eac@imap.1and1.com>
Message-ID: <4C100A21.3000700@settoplinux.org>

On 06/09/2010 12:01 PM, Joseph Smith wrote:
>
>
>
> On Wed, 09 Jun 2010 16:26:31 +0200, "anders at jenbo.dk"<anders at jenbo.dk>
> wrote:
>> Agreed, the only reason I haven't done car yet is that I haven't had a
>> board where the best match to copy from used CAR. I defiantly hav plans
> for
>> updating all the boards I have to car but I am waiting til I hit a board
>> where car is the best match or I run out if board / easy targets.
>>
>> By then I might help out with porting the 440bx boards (is 440lx below?).
>>
> No worries CAR for i810/socket_370 will be coming on the next few days :-)
> I am really excited to get rid of that model_6xx clump-o-crap.
>
Anders in case your curious, I will be porting the Intel D810E2CB.


-- 
Thanks,
Joseph Smith
Set-Top-Linux
www.settoplinux.org



From mylesgw at gmail.com  Wed Jun  9 23:49:43 2010
From: mylesgw at gmail.com (Myles Watson)
Date: Wed, 9 Jun 2010 15:49:43 -0600
Subject: [coreboot] [PATCH] lists of links
In-Reply-To: <AANLkTilYFrq7PgDTJJVh05L79wdadM6m7QSvKII-kA1g@mail.gmail.com>
References: <AANLkTilYFrq7PgDTJJVh05L79wdadM6m7QSvKII-kA1g@mail.gmail.com>
Message-ID: <AANLkTimrzWgxkmhq-xw6fnxP9Jofw5vvwdf2UMBjlv7Q@mail.gmail.com>

On Wed, Jun 9, 2010 at 8:57 AM, Myles Watson <mylesgw at gmail.com> wrote:
> Same conversion as with resources from static arrays to lists, except
> there is no free list.
>
> Converting resource arrays to lists reduced the size of each device
> struct from 1092 to 228 bytes.
> Converting link arrays to lists reduced the size of each device struct
> from 228 to 68 bytes.
>
> fam10_pci.diff makes fam10 and k8 northbridge code a little more
> similar before the conversion.
>
> The next step for fam10 and k8 would be to reorganize the links so
> that the southbridge link is always first. ?This would make some of
> the code a lot easier to follow. ?Something to consider would be
> adding link numbers to the device tree, since that would allow the
> southbridge link to start in the correct place.
>

Signed-off-by: Myles Watson <mylesgw at gmail.com>

Removed some warnings and fixed static.c generation when the
southbridge link is not 0.

Thanks,
Myles
-------------- next part --------------
A non-text attachment was scrubbed...
Name: links.diff
Type: text/x-patch
Size: 102219 bytes
Desc: not available
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20100609/6957faff/attachment.diff>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: fam10_pci.diff
Type: text/x-patch
Size: 31708 bytes
Desc: not available
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20100609/6957faff/attachment-0001.diff>

From stepan at coresystems.de  Thu Jun 10 00:14:59 2010
From: stepan at coresystems.de (Stefan Reinauer)
Date: Thu, 10 Jun 2010 00:14:59 +0200
Subject: [coreboot] [PATCH] lists of links
In-Reply-To: <AANLkTimrzWgxkmhq-xw6fnxP9Jofw5vvwdf2UMBjlv7Q@mail.gmail.com>
References: <AANLkTilYFrq7PgDTJJVh05L79wdadM6m7QSvKII-kA1g@mail.gmail.com>
	<AANLkTimrzWgxkmhq-xw6fnxP9Jofw5vvwdf2UMBjlv7Q@mail.gmail.com>
Message-ID: <4C101263.7080506@coresystems.de>

On 6/9/10 11:49 PM, Myles Watson wrote:
> Signed-off-by: Myles Watson <mylesgw at gmail.com>
>
> Removed some warnings and fixed static.c generation when the
> southbridge link is not 0.
>   
I didn't test this, but assuming we're not planning on getting rid of
malloc anymore, this is

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




From oliver at schinagl.nl  Thu Jun 10 00:24:23 2010
From: oliver at schinagl.nl (Oliver Schinagl)
Date: Thu, 10 Jun 2010 00:24:23 +0200
Subject: [coreboot] Minor update on IDE mode on Wyse S10 (CS5536)
In-Reply-To: <201006092321.18381.njacobs8@hetnet.nl>
References: <201006092321.18381.njacobs8@hetnet.nl>
Message-ID: <4C101497.8080906@schinagl.nl>

On 06/09/2010 11:21 PM, Nils wrote:
> Hi Oliver,
> You wrote:
>    
>> I am now ready I think to start giving coreboot a whirl on this thing.
>> Though I still wonder, if the bios can boot the kernel from the IDE
>> 'drive', I assume coreboot will equally be able to boot it; but if
>> recent kernels refuse to use the disk, I may end up being screwed anyway
>> :S.
>>      
> As i was trying to explain before, there is nothing wrong with the hardware
> or the way the IDE port is connected.
>    
Hmm, well I can boot from the IDE device as it actually detects grub on 
the MBR, so it does switch to IDE at boot time?
> The only problem is the stock bios witch is initializing the IDE port of the
> CS5536 as flash port.(that gives troubles if you are using a real IDE harddisk)
> When you use coreboot you can enable or disable flash_enable.
> Normaly it is disabled so you can use IDE.(But for your flash drive i think you
> want flash enabled)
>    
The controller on my device is a SM322TF which is a compact flash like 
IDE controller. If one would put the IDE port in flash mode, the docs 
talk about communicating directly with the flash chips, which is 
impossble with the controller. Also, in IDE mode, hdparm tells me many 
things about the IDE device, so why would I want it in flash mode?
> With coreboot you can use a normal recent kernel with the appropriate
> drivers.
>    
Ah! well I still have your coreboot.rom which I will give a whirl soon. 
Could I bother you for your .config so I can possibly tweak it?
> Succes,Nils
>    
Bedankt!
Oliver



From mylesgw at gmail.com  Thu Jun 10 00:27:40 2010
From: mylesgw at gmail.com (Myles Watson)
Date: Wed, 9 Jun 2010 16:27:40 -0600
Subject: [coreboot] [PATCH] lists of links
In-Reply-To: <4C101263.7080506@coresystems.de>
References: <AANLkTilYFrq7PgDTJJVh05L79wdadM6m7QSvKII-kA1g@mail.gmail.com>
	<AANLkTimrzWgxkmhq-xw6fnxP9Jofw5vvwdf2UMBjlv7Q@mail.gmail.com>
	<4C101263.7080506@coresystems.de>
Message-ID: <AANLkTilmyboonSHcY1-pjcKuGiOR8TACie4OaGkY6z1n@mail.gmail.com>

On Wed, Jun 9, 2010 at 4:14 PM, Stefan Reinauer <stepan at coresystems.de> wrote:
> On 6/9/10 11:49 PM, Myles Watson wrote:
>> Signed-off-by: Myles Watson <mylesgw at gmail.com>
>>
>> Removed some warnings and fixed static.c generation when the
>> southbridge link is not 0.
>>
> I didn't test this, but assuming we're not planning on getting rid of
> malloc anymore, this is

I'm willing to listen more before committing.  I remember you brought
up getting rid of malloc, but I don't see how you can get away from
it.  Are you suggesting a static global pool of resources and lists
that devices can use?  Am I totally missing your point?

Thanks,
Myles



From stepan at coresystems.de  Thu Jun 10 00:32:29 2010
From: stepan at coresystems.de (Stefan Reinauer)
Date: Thu, 10 Jun 2010 00:32:29 +0200
Subject: [coreboot] [PATCH] lists of links
In-Reply-To: <AANLkTilmyboonSHcY1-pjcKuGiOR8TACie4OaGkY6z1n@mail.gmail.com>
References: <AANLkTilYFrq7PgDTJJVh05L79wdadM6m7QSvKII-kA1g@mail.gmail.com>	<AANLkTimrzWgxkmhq-xw6fnxP9Jofw5vvwdf2UMBjlv7Q@mail.gmail.com>	<4C101263.7080506@coresystems.de>
	<AANLkTilmyboonSHcY1-pjcKuGiOR8TACie4OaGkY6z1n@mail.gmail.com>
Message-ID: <4C10167D.8010001@coresystems.de>

On 6/10/10 12:27 AM, Myles Watson wrote:
> On Wed, Jun 9, 2010 at 4:14 PM, Stefan Reinauer <stepan at coresystems.de> wrote:
>   
>> On 6/9/10 11:49 PM, Myles Watson wrote:
>>     
>>> Signed-off-by: Myles Watson <mylesgw at gmail.com>
>>>
>>> Removed some warnings and fixed static.c generation when the
>>> southbridge link is not 0.
>>>
>>>       
>> I didn't test this, but assuming we're not planning on getting rid of
>> malloc anymore, this is
>>     
> I'm willing to listen more before committing.  I remember you brought
> up getting rid of malloc, but I don't see how you can get away from
> it.  Are you suggesting a static global pool of resources and lists
> that devices can use?  Am I totally missing your point?
>   
I believe it was easy when a device was just a fixed size huge array,
but the more dynamic this gets it becomes more complex.
We'd indeed need a fixed number of every "dynamic" data structure we
have. Which makes little sense when we're looking into making coreboot
use less memory and be more flexible. So I believe keeping malloc and
having 68byte sized devices is better than dropping malloc and having
1KB big devices.

Stefan



From stefan.reinauer at coresystems.de  Thu Jun 10 00:37:10 2010
From: stefan.reinauer at coresystems.de (Stefan Reinauer)
Date: Thu, 10 Jun 2010 00:37:10 +0200
Subject: [coreboot] superiotool: Add support to IT85xx series
In-Reply-To: <AANLkTinSlmXnUSbc1NEzXkJhJ_HqO-cIg6y2U6T5hLq7@mail.gmail.com>
References: <AANLkTinSlmXnUSbc1NEzXkJhJ_HqO-cIg6y2U6T5hLq7@mail.gmail.com>
Message-ID: <4C101796.5090802@coresystems.de>

On 6/8/10 10:55 AM, ????? ?????? wrote:
> +static void enter_conf_mode_ite_it8502e(uint16_t port)
> +{
> +	OUTB(0x85, port);
> +	OUTB(0x02, port);
> +	OUTB(0x55, port);
> +	OUTB((port == 0x2e) ? 0x55 : 0xaa, port);
> +}
> +
>   
This one looks kind of weird... Do you have a datasheet somewhere?

Why's the second value different for entering configuration mode
depending on the port?


Stefan



From stefan.reinauer at coresystems.de  Thu Jun 10 00:38:23 2010
From: stefan.reinauer at coresystems.de (Stefan Reinauer)
Date: Thu, 10 Jun 2010 00:38:23 +0200
Subject: [coreboot] ectool: Add support to extended commands
In-Reply-To: <AANLkTimNv5rYGOYunWloDkKfzs_PE0TAblwIlje2ymcY@mail.gmail.com>
References: <AANLkTimNv5rYGOYunWloDkKfzs_PE0TAblwIlje2ymcY@mail.gmail.com>
Message-ID: <4C1017DF.3080405@coresystems.de>

On 6/8/10 11:58 AM, ????? ?????? wrote:
> Add support to extended EC series
> Signed-off-by: Anton Kochkov <anton.kochkov at gmail.com>
>   
They new functions are never used... is that on purpose?


-- 
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 svn at coreboot.org  Thu Jun 10 00:39:01 2010
From: svn at coreboot.org (repository service)
Date: Thu, 10 Jun 2010 00:39:01 +0200
Subject: [coreboot] [commit] r5625 - in trunk/src/northbridge/amd: amdfam10
	amdk8
Message-ID: <E1OMTvJ-0006yR-84@ra.coresystems.de>

Author: myles
Date: Thu Jun 10 00:39:00 2010
New Revision: 5625
URL: https://tracker.coreboot.org/trac/coreboot/changeset/5625

Log:
Make k8 & fam10 northbridge.c code more similar.

Signed-off-by: Myles Watson <mylesgw at gmail.com>
Acked-by: Myles Watson <mylesgw at gmail.com>

Modified:
   trunk/src/northbridge/amd/amdfam10/northbridge.c
   trunk/src/northbridge/amd/amdk8/northbridge.c

Modified: trunk/src/northbridge/amd/amdfam10/northbridge.c
==============================================================================
--- trunk/src/northbridge/amd/amdfam10/northbridge.c	Wed Jun  9 21:07:19 2010	(r5624)
+++ trunk/src/northbridge/amd/amdfam10/northbridge.c	Thu Jun 10 00:39:00 2010	(r5625)
@@ -55,6 +55,7 @@
 static device_t __f1_dev[FX_DEVS];
 static device_t __f2_dev[FX_DEVS];
 static device_t __f4_dev[FX_DEVS];
+static unsigned fx_devs=0;
 
 device_t get_node_pci(u32 nodeid, u32 fn)
 {
@@ -68,37 +69,37 @@
 #else
 	return dev_find_slot(CONFIG_CBB, PCI_DEVFN(CONFIG_CDB + nodeid, fn));
 #endif
-
 }
+
 static void get_fx_devs(void)
 {
 	int i;
-	if (__f1_dev[0]) {
-		return;
-	}
 	for(i = 0; i < FX_DEVS; i++) {
 		__f0_dev[i] = get_node_pci(i, 0);
 		__f1_dev[i] = get_node_pci(i, 1);
 		__f2_dev[i] = get_node_pci(i, 2);
 		__f4_dev[i] = get_node_pci(i, 4);
+		if (__f0_dev[i] != NULL && __f1_dev[i] != NULL)
+			fx_devs = i+1;
 	}
-	if (!__f1_dev[0]) {
-		printk(BIOS_ERR, "Cannot find %02x:%02x.1", CONFIG_CBB, CONFIG_CDB);
-		die("Cannot go on\n");
+	if (__f1_dev[0] == NULL || __f0_dev[0] == NULL || fx_devs == 0) {
+		die("Cannot find 0:0x18.[0|1]\n");
 	}
 }
 
-static u32 f1_read_config32(u32 reg)
+static u32 f1_read_config32(unsigned reg)
 {
-	get_fx_devs();
+	if (fx_devs == 0)
+		get_fx_devs();
 	return pci_read_config32(__f1_dev[0], reg);
 }
 
-static void f1_write_config32(u32 reg, u32 value)
+static void f1_write_config32(unsigned reg, u32 value)
 {
 	int i;
-	get_fx_devs();
-	for(i = 0; i < FX_DEVS; i++) {
+	if (fx_devs == 0)
+		get_fx_devs();
+	for(i = 0; i < fx_devs; i++) {
 		device_t dev;
 		dev = __f1_dev[i];
 		if (dev && dev->enabled) {
@@ -107,7 +108,6 @@
 	}
 }
 
-
 static u32 amdfam10_nodeid(device_t dev)
 {
 #if NODE_NUMS == 64
@@ -197,11 +197,10 @@
 		 * We have no idea how many busses are behind this bridge yet,
 		 * so we set the subordinate bus number to 0xff for the moment.
 		 */
-
 #if CONFIG_SB_HT_CHAIN_ON_BUS0 > 0
 		// first chain will on bus 0
 		if((nodeid == 0) && (sblink==link)) { // actually max is 0 here
-			 min_bus = max;
+			min_bus = max;
 		}
 	#if CONFIG_SB_HT_CHAIN_ON_BUS0 > 1
 		// second chain will be on 0x40, third 0x80, forth 0xc0
@@ -211,12 +210,12 @@
 			min_bus = ((busn>>3) + 1) << 3; // one node can have 8 link and segn is the same
 		}
 		max = min_bus | (segn<<8);
-	 #else
+	#else
 		//other ...
 		else {
 			min_bus = ++max;
 		}
-	 #endif
+	#endif
 #else
 		min_bus = ++max;
 #endif
@@ -224,6 +223,7 @@
 
 		dev->link[link].secondary = min_bus;
 		dev->link[link].subordinate = max_bus;
+
 		/* Read the existing primary/secondary/subordinate bus
 		 * number configuration.
 		 */
@@ -257,7 +257,6 @@
 
 		max = hypertransport_scan_chain(&dev->link[link], 0, max_devfn, max, ht_unitid_base, offset_unitid);
 
-
 		/* We know the number of busses behind this bridge.  Set the
 		 * subordinate bus number to it's real value
 		 */
@@ -270,7 +269,7 @@
 		sysconf.ht_c_num++;
 
 		{
-		// config config_reg, and ht_unitid_base to update hcdn_reg;
+			// use ht_unitid_base to update hcdn_reg
 			u32 temp = 0;
 			for(i=0;i<4;i++) {
 				temp |= (ht_unitid_base[i] & 0xff) << (i*8);
@@ -279,23 +278,19 @@
 			sysconf.hcdn_reg[ht_c_index] = temp;
 
 		}
-
-		store_ht_c_conf_bus(nodeid, link, ht_c_index, dev->link[link].secondary, dev->link[link].subordinate, &sysconf);
-
-
+	store_ht_c_conf_bus(nodeid, link, ht_c_index, dev->link[link].secondary, dev->link[link].subordinate, &sysconf);
 	return max;
 }
 
 static u32 amdfam10_scan_chains(device_t dev, u32 max)
 {
-	u32 nodeid;
+	unsigned nodeid;
 	u32 link;
-	u32 sblink = sysconf.sblk;
-	u32 offset_unitid = 0;
+	unsigned sblink = sysconf.sblk;
+	unsigned offset_unitid = 0;
 
 	nodeid = amdfam10_nodeid(dev);
 
-
 // Put sb chain in bus 0
 #if CONFIG_SB_HT_CHAIN_ON_BUS0 > 0
 	if(nodeid==0) {
@@ -306,12 +301,10 @@
 	}
 #endif
 
-
 #if CONFIG_PCI_BUS_SEGN_BITS
 	max = check_segn(dev, max, sysconf.nodes, &sysconf);
 #endif
 
-
 	for(link = 0; link < dev->links; link++) {
 #if CONFIG_SB_HT_CHAIN_ON_BUS0 > 0
 		if( (nodeid == 0) && (sblink == link) ) continue; //already done
@@ -330,14 +323,14 @@
 }
 
 
-static int reg_useable(u32 reg,device_t goal_dev, u32 goal_nodeid,
-			u32 goal_link)
+static int reg_useable(unsigned reg, device_t goal_dev, unsigned goal_nodeid,
+			unsigned goal_link)
 {
 	struct resource *res;
-	u32 nodeid, link = 0;
+	unsigned nodeid, link = 0;
 	int result;
 	res = 0;
-	for(nodeid = 0; !res && (nodeid < NODE_NUMS); nodeid++) {
+	for(nodeid = 0; !res && (nodeid < fx_devs); nodeid++) {
 		device_t dev;
 		dev = __f0_dev[nodeid];
 		if (!dev)
@@ -358,7 +351,7 @@
 	return result;
 }
 
-static struct resource *amdfam10_find_iopair(device_t dev, u32 nodeid, u32 link)
+static struct resource *amdfam10_find_iopair(device_t dev, unsigned nodeid, unsigned link)
 {
 	struct resource *resource;
 	u32 free_reg, reg;
@@ -433,7 +426,7 @@
 	struct resource *resource;
 
 	/* Initialize the io space constraints on the current bus */
-	resource =  amdfam10_find_iopair(dev, nodeid, link);
+	resource = amdfam10_find_iopair(dev, nodeid, link);
 	if (resource) {
 		u32 align;
 #if CONFIG_EXT_CONF_SUPPORT == 1
@@ -454,12 +447,13 @@
 	/* Initialize the prefetchable memory constraints on the current bus */
 	resource = amdfam10_find_mempair(dev, nodeid, link);
 	if (resource) {
-		resource->base	= 0;
-		resource->size	= 0;
+		resource->base = 0;
+		resource->size = 0;
 		resource->align = log2(HT_MEM_HOST_ALIGN);
-		resource->gran	= log2(HT_MEM_HOST_ALIGN);
+		resource->gran = log2(HT_MEM_HOST_ALIGN);
 		resource->limit = 0xffffffffffULL;
-		resource->flags = IORESOURCE_MEM | IORESOURCE_PREFETCH | IORESOURCE_BRIDGE;
+		resource->flags = IORESOURCE_MEM | IORESOURCE_PREFETCH;
+		resource->flags |= IORESOURCE_BRIDGE;
 
 #if CONFIG_EXT_CONF_SUPPORT == 1
 		if((resource->index & 0x1fff) == 0x1110) { // ext
@@ -472,23 +466,20 @@
 	/* Initialize the memory constraints on the current bus */
 	resource = amdfam10_find_mempair(dev, nodeid, link);
 	if (resource) {
-		resource->base	= 0;
-		resource->size	= 0;
+		resource->base = 0;
+		resource->size = 0;
 		resource->align = log2(HT_MEM_HOST_ALIGN);
-		resource->gran	= log2(HT_MEM_HOST_ALIGN);
+		resource->gran = log2(HT_MEM_HOST_ALIGN);
 		resource->limit = 0xffffffffffULL;
 		resource->flags = IORESOURCE_MEM | IORESOURCE_BRIDGE;
-
 #if CONFIG_EXT_CONF_SUPPORT == 1
 		if((resource->index & 0x1fff) == 0x1110) { // ext
 			normalize_resource(resource);
 		}
 #endif
-
 	}
 }
 
-
 static void amdfam10_read_resources(device_t dev)
 {
 	u32 nodeid, link;
@@ -501,7 +492,6 @@
 	}
 }
 
-
 static void amdfam10_set_resource(device_t dev, struct resource *resource,
 				u32 nodeid)
 {
@@ -613,7 +603,6 @@
 	}
 }
 
-
 static void amdfam10_enable_resources(device_t dev)
 {
 	pci_dev_enable_resources(dev);
@@ -665,14 +654,14 @@
 			} else { // io
 				nodeid =  (limit & 0xf) + ((base>>4)&0x30);
 			}
-			reg_link   = (limit >> 4) & 7;
+			reg_link = (limit >> 4) & 7;
 			reg_dev = __f0_dev[nodeid];
 			if (reg_dev) {
 				/* Reserve the resource  */
-				struct resource *reg_resource;
-				reg_resource = new_resource(reg_dev, IOINDEX(0x1000 + reg, reg_link));
-				if (reg_resource) {
-					reg_resource->flags = 1;
+				struct resource *res;
+				res = new_resource(reg_dev, IOINDEX(0x1000 + reg, reg_link));
+				if (res) {
+					res->flags = 1;
 				}
 			}
 		}
@@ -714,8 +703,8 @@
 		return;
 	}
 	resource = new_resource(dev, index);
-	resource->base	= basek << 10;
-	resource->size	= sizek << 10;
+	resource->base = basek << 10;
+	resource->size = sizek << 10;
 	resource->flags =  IORESOURCE_MEM | IORESOURCE_CACHEABLE | \
 		IORESOURCE_FIXED | IORESOURCE_STORED | IORESOURCE_ASSIGNED;
 }
@@ -798,9 +787,9 @@
 // WHY this check? CONFIG_AMDMCT is enabled on all Fam10 boards.
 // Does it make sense not to?
 #if CONFIG_AMDMCT == 0
-static void disable_hoist_memory(unsigned long hole_startk, int i)
+static void disable_hoist_memory(unsigned long hole_startk, int node_id)
 {
-	int ii;
+	int i;
 	device_t dev;
 	struct dram_base_mask_t d;
 	u32 sel_m;
@@ -811,7 +800,7 @@
 	u32 one_DCT;
 	struct sys_info *sysinfox = (struct sys_info *)((CONFIG_RAMTOP) - CONFIG_DCACHE_RAM_GLOBAL_VAR_SIZE); // in RAM
 	struct mem_info *meminfo;
-	meminfo = &sysinfox->meminfo[i];
+	meminfo = &sysinfox->meminfo[node_id];
 
 	one_DCT = get_one_DCT(meminfo);
 
@@ -824,54 +813,52 @@
 
 	hole_sizek = (4*1024*1024) - hole_startk;
 
-	for(ii=NODE_NUMS-1;ii>i;ii--) {
+	for(i=NODE_NUMS-1;i>node_id;i--) {
 
-		d = get_dram_base_mask(ii);
+		d = get_dram_base_mask(i);
 
 		if(!(d.mask & 1)) continue;
 
 		d.base -= (hole_sizek>>9);
 		d.mask -= (hole_sizek>>9);
-		set_dram_base_mask(ii, d, sysconf.nodes);
+		set_dram_base_mask(i, d, sysconf.nodes);
 
-		if(get_DctSelHiEn(ii) & 1) {
-			sel_m = get_DctSelBaseAddr(ii);
+		if(get_DctSelHiEn(i) & 1) {
+			sel_m = get_DctSelBaseAddr(i);
 			sel_m -= hole_startk>>10;
-			set_DctSelBaseAddr(ii, sel_m);
+			set_DctSelBaseAddr(i, sel_m);
 		}
 	}
 
-	d = get_dram_base_mask(i);
-	dev = __f1_dev[i];
-	hoist = pci_read_config32(dev, 0xf0);
-	sel_hi_en = get_DctSelHiEn(i);
+	d = get_dram_base_mask(node_id);
+	dev = __f1_dev[node_id];
+	sel_hi_en = get_DctSelHiEn(node_id);
 
 	if(sel_hi_en & 1) {
-		sel_m = get_DctSelBaseAddr(i);
+		sel_m = get_DctSelBaseAddr(node_id);
 	}
-
+	hoist = pci_read_config32(dev, 0xf0);
 	if(hoist & 1) {
 		pci_write_config32(dev, 0xf0, 0);
 		d.mask -= (hole_sizek>>9);
-		set_dram_base_mask(i, d, sysconf.nodes);
+		set_dram_base_mask(node_id, d, sysconf.nodes);
 		if(one_DCT || (sel_m >= (hole_startk>>10))) {
 			if(sel_hi_en & 1) {
 				sel_m -= hole_startk>>10;
-				set_DctSelBaseAddr(i, sel_m);
+				set_DctSelBaseAddr(node_id, sel_m);
 			}
 		}
 		if(sel_hi_en & 1) {
-			set_DctSelBaseOffset(i, 0);
+			set_DctSelBaseOffset(node_id, 0);
 		}
-	}
-	else {
+	} else {
 		d.base -= (hole_sizek>>9);
 		d.mask -= (hole_sizek>>9);
-		set_dram_base_mask(i, d, sysconf.nodes);
+		set_dram_base_mask(node_id, d, sysconf.nodes);
 
 		if(sel_hi_en & 1) {
 			sel_m -= hole_startk>>10;
-			set_DctSelBaseAddr(i, sel_m);
+			set_DctSelBaseAddr(node_id, sel_m);
 		}
 	}
 
@@ -885,7 +872,7 @@
 extern uint64_t high_tables_base, high_tables_size;
 #endif
 
-static void pci_domain_set_resources(device_t dev)
+static void amdfam10_domain_set_resources(device_t dev)
 {
 #if CONFIG_PCI_64BIT_PREF_MEM == 1
 	struct resource *io, *mem1, *mem2;
@@ -902,7 +889,7 @@
 
 #if CONFIG_PCI_64BIT_PREF_MEM == 1
 
-	for(link=0; link<dev->links; link++) {
+	for(link = 0; link < dev->links; link++) {
 		/* Now reallocate the pci resources memory with the
 		 * highest addresses I can manage.
 		 */
@@ -946,16 +933,13 @@
 	for(res = &dev->resource_list; res; res = res->next)
 	{
 		res->flags |= IORESOURCE_ASSIGNED;
-		res->flags &= ~IORESOURCE_STORED;
-		link = (res>>2) & 3;
 		res->flags |= IORESOURCE_STORED;
 		report_resource_stored(dev, res, "");
-
 	}
 #endif
 
 	pci_tolm = 0xffffffffUL;
-	for(link=0;link<dev->links; link++) {
+	for(link = 0; link<dev->links; link++) {
 		pci_tolm = find_pci_tolm(&dev->link[link], pci_tolm);
 	}
 
@@ -967,7 +951,7 @@
 
 	// FIXME improve mtrr.c so we don't use up all of the mtrrs with a 64M
 	// MMIO hole. If you fix this here, please fix amdk8, too.
-	/* Round the mmio hold to 64M */
+	/* Round the mmio hole to 64M */
 	mmio_basek &= ~((64*1024) - 1);
 
 #if CONFIG_HW_MEM_HOLE_SIZEK != 0
@@ -1057,11 +1041,11 @@
 					idx += 0x10;
 					sizek -= pre_sizek;
 #if CONFIG_WRITE_HIGH_TABLES==1
-					if (i==0 && high_tables_base==0) {
+					if (high_tables_base==0) {
 					/* Leave some space for ACPI, PIRQ and MP tables */
 						high_tables_base = (mmio_basek - HIGH_TABLES_SIZE) * 1024;
 						high_tables_size = HIGH_TABLES_SIZE * 1024;
-						printk(BIOS_DEBUG, "(split)%xK table at =%08llx\n", HIGH_TABLES_SIZE,
+						printk(BIOS_DEBUG, " split: %dK table at =%08llx\n", HIGH_TABLES_SIZE,
 							     high_tables_base);
 					}
 #endif
@@ -1092,7 +1076,7 @@
 #if CONFIG_WRITE_HIGH_TABLES==1
 		printk(BIOS_DEBUG, "%d: mmio_basek=%08lx, basek=%08llx, limitk=%08llx\n",
 			     i, mmio_basek, basek, limitk);
-		if (i==0 && high_tables_base==0) {
+		if (high_tables_base==0) {
 		/* Leave some space for ACPI, PIRQ and MP tables */
 			high_tables_base = (limitk - HIGH_TABLES_SIZE) * 1024;
 			high_tables_size = HIGH_TABLES_SIZE * 1024;
@@ -1130,7 +1114,7 @@
 #endif
 
 
-	for(i=0;i<dev->links;i++) {
+	for(i = 0; i < dev->links; i++) {
 		max = pci_scan_bus(&dev->link[i], PCI_DEVFN(CONFIG_CDB, 0), 0xff, max);
 	}
 
@@ -1138,7 +1122,7 @@
 	 * Including enabling relaxed ordering if it is safe.
 	 */
 	get_fx_devs();
-	for(i = 0; i < FX_DEVS; i++) {
+	for(i = 0; i < fx_devs; i++) {
 		device_t f0_dev;
 		f0_dev = __f0_dev[i];
 		if (f0_dev && f0_dev->enabled) {
@@ -1160,7 +1144,7 @@
 
 static struct device_operations pci_domain_ops = {
 	.read_resources	  = amdfam10_domain_read_resources,
-	.set_resources	  = pci_domain_set_resources,
+	.set_resources	  = amdfam10_domain_set_resources,
 	.enable_resources = enable_childrens_resources,
 	.init		  = 0,
 	.scan_bus	  = amdfam10_domain_scan_bus,
@@ -1208,11 +1192,9 @@
 		} else {
 			sysconf.lift_bsp_apicid = 1;
 		}
-
 	}
 	#endif
 #endif
-
 }
 
 static u32 cpu_bus_scan(device_t dev, u32 max)
@@ -1243,11 +1225,7 @@
 	get_option(&disable_siblings, "multi_core");
 #endif
 
-	// for pre_e0, nb_cfg_54 can not be set, ( even set, when you read it
-	//    still be 0)
-	// How can I get the nb_cfg_54 of every node' nb_cfg_54 in bsp???
-	//    and differ d0 and e0 single core
-
+	// How can I get the nb_cfg_54 of every node's nb_cfg_54 in bsp???
 	nb_cfg_54 = read_nb_cfg_54();
 
 #if CONFIG_CBB
@@ -1264,7 +1242,6 @@
 			printk(BIOS_DEBUG, " but it is not under pci_domain directly ");
 		}
 		printk(BIOS_DEBUG, "\n");
-
 	}
 	dev_mc = dev_find_slot(CONFIG_CBB, PCI_DEVFN(CONFIG_CDB, 0));
 	if(!dev_mc) {
@@ -1342,9 +1319,9 @@
 				cdb_dev = pci_probe_dev(NULL, pbus,
 					PCI_DEVFN(devn, fn));
 			}
-			cdb_dev = dev_find_slot(busn, PCI_DEVFN(devn,0));
+			cdb_dev = dev_find_slot(busn, PCI_DEVFN(devn, 0));
 		}
-		if(cdb_dev) {
+		if (cdb_dev) {
 			/* Ok, We need to set the links for that device.
 			 * otherwise the device under it will not be scanned
 			 */
@@ -1355,7 +1332,7 @@
 #else
 			linknum = 4;
 #endif
-			if(cdb_dev->links < linknum) {
+			if (cdb_dev->links < linknum) {
 				for(link=cdb_dev->links; link<linknum; link++) {
 					 cdb_dev->link[link].link = link;
 					 cdb_dev->link[link].dev = cdb_dev;
@@ -1412,14 +1389,14 @@
 				cpu->path.apic.node_id = i;
 				cpu->path.apic.core_id = j;
 	#if (CONFIG_ENABLE_APIC_EXT_ID == 1) && (CONFIG_APIC_ID_OFFSET>0)
-				 if(sysconf.enabled_apic_ext_id) {
+				if(sysconf.enabled_apic_ext_id) {
 					if(sysconf.lift_bsp_apicid) {
 						cpu->path.apic.apic_id += sysconf.apicid_offset;
 					} else
 					{
 						if (cpu->path.apic.apic_id != 0)
 							cpu->path.apic.apic_id += sysconf.apicid_offset;
-					 }
+					}
 				}
 	#endif
 				printk(BIOS_DEBUG, "CPU: %s %s\n",
@@ -1431,18 +1408,15 @@
 	return max;
 }
 
-
 static void cpu_bus_init(device_t dev)
 {
 	initialize_cpus(&dev->link[0]);
 }
 
-
 static void cpu_bus_noop(device_t dev)
 {
 }
 
-
 static struct device_operations cpu_bus_ops = {
 	.read_resources	  = cpu_bus_noop,
 	.set_resources	  = cpu_bus_noop,
@@ -1451,7 +1425,6 @@
 	.scan_bus	  = cpu_bus_scan,
 };
 
-
 static void root_complex_enable_dev(struct device *dev)
 {
 	/* Set the operations if it is a special bus type */

Modified: trunk/src/northbridge/amd/amdk8/northbridge.c
==============================================================================
--- trunk/src/northbridge/amd/amdk8/northbridge.c	Wed Jun  9 21:07:19 2010	(r5624)
+++ trunk/src/northbridge/amd/amdk8/northbridge.c	Thu Jun 10 00:39:00 2010	(r5625)
@@ -55,17 +55,17 @@
 	}
 }
 
-static uint32_t f1_read_config32(unsigned reg)
+static u32 f1_read_config32(unsigned reg)
 {
-	if ( fx_devs == 0)
+	if (fx_devs == 0)
 		get_fx_devs();
 	return pci_read_config32(__f1_dev[0], reg);
 }
 
-static void f1_write_config32(unsigned reg, uint32_t value)
+static void f1_write_config32(unsigned reg, u32 value)
 {
 	int i;
-	if ( fx_devs == 0)
+	if (fx_devs == 0)
 		get_fx_devs();
 	for(i = 0; i < fx_devs; i++) {
 		device_t dev;
@@ -76,22 +76,23 @@
 	}
 }
 
-static unsigned int amdk8_nodeid(device_t dev)
+static u32 amdk8_nodeid(device_t dev)
 {
 	return (dev->path.pci.devfn >> 3) - 0x18;
 }
 
-static unsigned int amdk8_scan_chain(device_t dev, unsigned nodeid, unsigned link, unsigned sblink, unsigned int max, unsigned offset_unitid)
+static u32 amdk8_scan_chain(device_t dev, u32 nodeid, u32 link, u32 sblink,
+				u32 max, u32 offset_unitid)
 {
 
-		uint32_t link_type;
+		u32 link_type;
 		int i;
-		uint32_t busses, config_busses;
-		unsigned free_reg, config_reg;
-		unsigned ht_unitid_base[4]; // here assume only 4 HT device on chain
-		unsigned max_bus;
-		unsigned min_bus;
-		unsigned max_devfn;
+		u32 busses, config_busses;
+		u32 free_reg, config_reg;
+		u32 ht_unitid_base[4]; // here assume only 4 HT device on chain
+		u32 max_bus;
+		u32 min_bus;
+		u32 max_devfn;
 
 		dev->link[link].cap = 0x80 + (link *0x20);
 		do {
@@ -111,7 +112,7 @@
 		 */
 		free_reg = 0;
 		for(config_reg = 0xe0; config_reg <= 0xec; config_reg += 4) {
-			uint32_t config;
+			u32 config;
 			config = f1_read_config32(config_reg);
 			if (!free_reg && ((config & 3) == 0)) {
 				free_reg = config_reg;
@@ -150,7 +151,7 @@
 		max = min_bus;
 	#else
 		//other ...
-		else  {
+		else {
 			min_bus = ++max;
 		}
 	#endif
@@ -214,9 +215,9 @@
 		f1_write_config32(config_reg, config_busses);
 
 		{
-			// config config_reg, and ht_unitid_base to update hcdn_reg;
+			// use config_reg and ht_unitid_base to update hcdn_reg
 			int index;
-			unsigned temp = 0;
+			u32 temp = 0;
 			index = (config_reg-0xe0) >> 2;
 			for(i=0;i<4;i++) {
 				temp |= (ht_unitid_base[i] & 0xff) << (i*8);
@@ -225,16 +226,16 @@
 			sysconf.hcdn_reg[index] = temp;
 
 		}
-
 	return max;
 }
 
-static unsigned int amdk8_scan_chains(device_t dev, unsigned int max)
+static unsigned amdk8_scan_chains(device_t dev, unsigned max)
 {
 	unsigned nodeid;
 	unsigned link;
 	unsigned sblink = 0;
 	unsigned offset_unitid = 0;
+
 	nodeid = amdk8_nodeid(dev);
 
 	if(nodeid==0) {
@@ -247,7 +248,7 @@
 #endif
 	}
 
-	for(link = 0; link < dev->links; link++) {
+	for (link = 0; link < dev->links; link++) {
 #if CONFIG_SB_HT_CHAIN_ON_BUS0 > 0
 		if( (nodeid == 0) && (sblink == link) ) continue; //already done
 #endif
@@ -261,16 +262,15 @@
 
 		max = amdk8_scan_chain(dev, nodeid, link, sblink, max, offset_unitid);
 	}
-
 	return max;
 }
 
 
-static int reg_useable(unsigned reg,
-	device_t goal_dev, unsigned goal_nodeid, unsigned goal_link)
+static int reg_useable(unsigned reg, device_t goal_dev, unsigned goal_nodeid,
+			unsigned goal_link)
 {
 	struct resource *res;
-	unsigned nodeid, link=0;
+	unsigned nodeid, link = 0;
 	int result;
 	res = 0;
 	for(nodeid = 0; !res && (nodeid < fx_devs); nodeid++) {
@@ -291,7 +291,6 @@
 			result = 1;
 		}
 	}
-
 	return result;
 }
 
@@ -351,10 +350,10 @@
 	/* Initialize the prefetchable memory constraints on the current bus */
 	resource = new_resource(dev, IOINDEX(2, link));
 	if (resource) {
-		resource->base  = 0;
-		resource->size  = 0;
+		resource->base = 0;
+		resource->size = 0;
 		resource->align = log2(HT_MEM_HOST_ALIGN);
-		resource->gran  = log2(HT_MEM_HOST_ALIGN);
+		resource->gran = log2(HT_MEM_HOST_ALIGN);
 		resource->limit = 0xffffffffffULL;
 		resource->flags = IORESOURCE_MEM | IORESOURCE_PREFETCH;
 		resource->flags |= IORESOURCE_BRIDGE;
@@ -363,10 +362,10 @@
 	/* Initialize the memory constraints on the current bus */
 	resource = new_resource(dev, IOINDEX(1, link));
 	if (resource) {
-		resource->base  = 0;
-		resource->size  = 0;
+		resource->base = 0;
+		resource->size = 0;
 		resource->align = log2(HT_MEM_HOST_ALIGN);
-		resource->gran  = log2(HT_MEM_HOST_ALIGN);
+		resource->gran = log2(HT_MEM_HOST_ALIGN);
 		resource->limit = 0xffffffffULL;
 		resource->flags = IORESOURCE_MEM | IORESOURCE_BRIDGE;
 	}
@@ -430,7 +429,7 @@
 	link = IOINDEX_LINK(resource->index);
 
 	if (resource->flags & IORESOURCE_IO) {
-		uint32_t base, limit;
+		u32 base, limit;
 		base  = f1_read_config32(reg);
 		limit = f1_read_config32(reg + 0x4);
 		base  &= 0xfe000fcc;
@@ -454,7 +453,7 @@
 		f1_write_config32(reg, base);
 	}
 	else if (resource->flags & IORESOURCE_MEM) {
-		uint32_t base, limit;
+		u32 base, limit;
 		base  = f1_read_config32(reg);
 		limit = f1_read_config32(reg + 0x4);
 		base  &= 0x000000f0;
@@ -468,7 +467,7 @@
 		f1_write_config32(reg, base);
 	}
 	resource->flags |= IORESOURCE_STORED;
-	sprintf(buf, " <node %d link %d>",
+	sprintf(buf, " <node %x link %x>",
 		nodeid, link);
 	report_resource_stored(dev, resource, buf);
 }
@@ -580,18 +579,18 @@
 }
 
 static struct device_operations northbridge_operations = {
-	.read_resources   = amdk8_read_resources,
-	.set_resources    = amdk8_set_resources,
+	.read_resources	  = amdk8_read_resources,
+	.set_resources	  = amdk8_set_resources,
 	.enable_resources = amdk8_enable_resources,
-	.init             = mcf0_control_init,
-	.scan_bus         = amdk8_scan_chains,
-	.enable           = 0,
-	.ops_pci          = 0,
+	.init		  = mcf0_control_init,
+	.scan_bus	  = amdk8_scan_chains,
+	.enable		  = 0,
+	.ops_pci	  = 0,
 };
 
 
 static const struct pci_driver mcf0_driver __pci_driver = {
-	.ops    = &northbridge_operations,
+	.ops	= &northbridge_operations,
 	.vendor = PCI_VENDOR_ID_AMD,
 	.device = 0x1100,
 };
@@ -608,20 +607,20 @@
 	/* Find the already assigned resource pairs */
 	get_fx_devs();
 	for(reg = 0x80; reg <= 0xd8; reg+= 0x08) {
-		uint32_t base, limit;
+		u32 base, limit;
 		base  = f1_read_config32(reg);
 		limit = f1_read_config32(reg + 0x04);
 		/* Is this register allocated? */
 		if ((base & 3) != 0) {
-			unsigned nodeid, link;
+			unsigned nodeid, reg_link;
 			device_t reg_dev;
 			nodeid = limit & 7;
-			link   = (limit >> 4) & 3;
+			reg_link = (limit >> 4) & 3;
 			reg_dev = __f0_dev[nodeid];
 			if (reg_dev) {
 				/* Reserve the resource  */
 				struct resource *res;
-				res = new_resource(reg_dev, IOINDEX(0x100 + reg, link));
+				res = new_resource(reg_dev, IOINDEX(0x100 + reg, reg_link));
 				if (res) {
 					res->base = base;
 					res->limit = limit;
@@ -650,8 +649,8 @@
 		return;
 	}
 	resource = new_resource(dev, index);
-	resource->base  = ((resource_t)basek) << 10;
-	resource->size  = ((resource_t)sizek) << 10;
+	resource->base = ((resource_t)basek) << 10;
+	resource->size = ((resource_t)sizek) << 10;
 	resource->flags =  IORESOURCE_MEM | IORESOURCE_CACHEABLE | \
 		IORESOURCE_FIXED | IORESOURCE_STORED | IORESOURCE_ASSIGNED;
 }
@@ -668,10 +667,10 @@
 	*best_p = best;
 }
 
-static uint32_t find_pci_tolm(struct bus *bus)
+static u32 find_pci_tolm(struct bus *bus)
 {
 	struct resource *min;
-	uint32_t tolm;
+	u32 tolm;
 	min = 0;
 	search_bus_resources(bus, IORESOURCE_MEM, IORESOURCE_MEM, tolm_test, &min);
 	tolm = 0xffffffffUL;
@@ -697,8 +696,8 @@
 		mem_hole.node_id = -1;
 
 		for (i = 0; i < fx_devs; i++) {
-			uint32_t base;
-			uint32_t hole;
+			u32 base;
+			u32 hole;
 			base  = f1_read_config32(0x40 + (i << 3));
 			if ((base & ((1<<1)|(1<<0))) != ((1<<1)|(1<<0))) {
 				continue;
@@ -714,9 +713,9 @@
 
 		//We need to double check if there is speical set on base reg and limit reg are not continous instead of hole, it will find out it's hole_startk
 		if(mem_hole.node_id==-1) {
-			uint32_t limitk_pri = 0;
+			u32 limitk_pri = 0;
 			for(i=0; i<8; i++) {
-				uint32_t base, limit;
+				u32 base, limit;
 				unsigned base_k, limit_k;
 				base  = f1_read_config32(0x40 + (i << 3));
 				if ((base & ((1<<1)|(1<<0))) != ((1<<1)|(1<<0))) {
@@ -735,18 +734,16 @@
 				limitk_pri = limit_k;
 			}
 		}
-
 		return mem_hole;
-
 }
 
 static void disable_hoist_memory(unsigned long hole_startk, int node_id)
 {
 	int i;
 	device_t dev;
-	uint32_t base, limit;
-	uint32_t hoist;
-	uint32_t hole_sizek;
+	u32 base, limit;
+	u32 hoist;
+	u32 hole_sizek;
 
 
 	//1. find which node has hole
@@ -776,22 +773,22 @@
 		return;
 	}
 	hoist = pci_read_config32(dev, 0xf0);
-	if(hoist & 1)
+	if(hoist & 1) {
 		pci_write_config32(dev, 0xf0, 0);
-	else {
+	} else {
 		base = pci_read_config32(dev, 0x40 + (node_id << 3));
 		f1_write_config32(0x40 + (node_id << 3),base - (hole_sizek << 2));
 	}
 }
 
-static uint32_t hoist_memory(unsigned long hole_startk, int node_id)
+static u32 hoist_memory(unsigned long hole_startk, int node_id)
 {
 	int i;
-	uint32_t carry_over;
+	u32 carry_over;
 	device_t dev;
-	uint32_t base, limit;
-	uint32_t basek;
-	uint32_t hoist;
+	u32 base, limit;
+	u32 basek;
+	u32 hoist;
 
 	carry_over = (4*1024*1024) - hole_startk;
 
@@ -848,11 +845,11 @@
 	struct resource *res;
 #endif
 	unsigned long mmio_basek;
-	uint32_t pci_tolm;
+	u32 pci_tolm;
 	int i, idx;
 #if CONFIG_HW_MEM_HOLE_SIZEK != 0
 	struct hw_mem_hole_info mem_hole;
-	unsigned reset_memhole = 1;
+	u32 reset_memhole = 1;
 #endif
 
 #if 0
@@ -909,7 +906,6 @@
 		res->flags |= IORESOURCE_ASSIGNED;
 		res->flags |= IORESOURCE_STORED;
 		report_resource_stored(dev, res, "");
-
 	}
 #endif
 
@@ -953,10 +949,10 @@
 
 		#if CONFIG_HW_MEM_HOLE_SIZE_AUTO_INC == 1
 			//We need to double check if the mmio_basek is valid for hole setting, if it is equal to basek, we need to decrease it some
-			uint32_t basek_pri;
+			u32 basek_pri;
 			for (i = 0; i < fx_devs; i++) {
-				uint32_t base;
-				uint32_t basek;
+				u32 base;
+				u32 basek;
 				base  = f1_read_config32(0x40 + (i << 3));
 				if ((base & ((1<<1)|(1<<0))) != ((1<<1)|(1<<0))) {
 					continue;
@@ -980,8 +976,8 @@
 
 	idx = 0x10;
 	for(i = 0; i < fx_devs; i++) {
-		uint32_t base, limit;
-		unsigned basek, limitk, sizek;
+		u32 base, limit;
+		u32 basek, limitk, sizek;
 		base  = f1_read_config32(0x40 + (i << 3));
 		limit = f1_read_config32(0x44 + (i << 3));
 		if ((base & ((1<<1)|(1<<0))) != ((1<<1)|(1<<0))) {
@@ -1074,9 +1070,9 @@
 
 }
 
-static unsigned int amdk8_domain_scan_bus(device_t dev, unsigned int max)
+static u32 amdk8_domain_scan_bus(device_t dev, u32 max)
 {
-	unsigned reg;
+	u32 reg;
 	int i;
 	/* Unmap all of the HT chains */
 	for(reg = 0xe0; reg <= 0xec; reg += 4) {
@@ -1092,7 +1088,7 @@
 		device_t f0_dev;
 		f0_dev = __f0_dev[i];
 		if (f0_dev && f0_dev->enabled) {
-			uint32_t httc;
+			u32 httc;
 			httc = pci_read_config32(f0_dev, HT_TRANSACTION_CONTROL);
 			httc &= ~HTTC_RSP_PASS_PW;
 			if (!dev->link[0].disable_relaxed_ordering) {
@@ -1109,15 +1105,15 @@
 }
 
 static struct device_operations pci_domain_ops = {
-	.read_resources   = amdk8_domain_read_resources,
-	.set_resources    = amdk8_domain_set_resources,
+	.read_resources	  = amdk8_domain_read_resources,
+	.set_resources	  = amdk8_domain_set_resources,
 	.enable_resources = enable_childrens_resources,
-	.init             = 0,
-	.scan_bus         = amdk8_domain_scan_bus,
-	.ops_pci_bus      = &pci_cf8_conf1,
+	.init		  = 0,
+	.scan_bus	  = amdk8_domain_scan_bus,
+	.ops_pci_bus	  = &pci_cf8_conf1,
 };
 
-static unsigned int cpu_bus_scan(device_t dev, unsigned int max)
+static u32 cpu_bus_scan(device_t dev, u32 max)
 {
 	struct bus *cpu_bus;
 	device_t dev_mc;
@@ -1142,9 +1138,9 @@
 	get_option(&disable_siblings, "multi_core");
 #endif
 
-	// for pre_e0, nb_cfg_54 can not be set, ( even set, when you read it still be 0)
-	// How can I get the nb_cfg_54 of every node' nb_cfg_54 in bsp??? and differ d0 and e0 single core
-
+	// for pre_e0, nb_cfg_54 can not be set, (when you read it still is 0)
+	// How can I get the nb_cfg_54 of every node's nb_cfg_54 in bsp???
+	// and differ d0 and e0 single core
 	nb_cfg_54 = read_nb_cfg_54();
 
 	dev_mc = dev_find_slot(0, PCI_DEVFN(0x18, 0));
@@ -1197,7 +1193,6 @@
 					dev_f0->link[local_j].dev = dev_f0;
 				}
 			}
-
 		}
 
 		e0_later_single_core = 0;
@@ -1236,7 +1231,7 @@
   			}
 		}
 
-		unsigned jj;
+		u32 jj;
 		if(e0_later_single_core || disable_siblings) {
 			jj = 0;
 		} else
@@ -1280,8 +1275,8 @@
 						cpu->path.apic.apic_id += sysconf.apicid_offset;
 					} else
 					{
-					       if (cpu->path.apic.apic_id != 0)
-						       cpu->path.apic.apic_id += sysconf.apicid_offset;
+						if (cpu->path.apic.apic_id != 0)
+							cpu->path.apic.apic_id += sysconf.apicid_offset;
 					}
 				}
 				printk(BIOS_DEBUG, "CPU: %s %s\n",
@@ -1303,11 +1298,11 @@
 }
 
 static struct device_operations cpu_bus_ops = {
-	.read_resources   = cpu_bus_noop,
-	.set_resources    = cpu_bus_noop,
+	.read_resources	  = cpu_bus_noop,
+	.set_resources	  = cpu_bus_noop,
 	.enable_resources = cpu_bus_noop,
-	.init             = cpu_bus_init,
-	.scan_bus         = cpu_bus_scan,
+	.init		  = cpu_bus_init,
+	.scan_bus	  = cpu_bus_scan,
 };
 
 static void root_complex_enable_dev(struct device *dev)



From svn at coreboot.org  Thu Jun 10 00:41:38 2010
From: svn at coreboot.org (repository service)
Date: Thu, 10 Jun 2010 00:41:38 +0200
Subject: [coreboot] [commit] r5626 - in trunk: src/arch/i386/boot
	src/cpu/amd/sc520 src/devices src/devices/oprom/yabel
	src/drivers/generic/debug src/drivers/i2c/i2cmux
	src/drivers/i2c/i2cmux2 src/include/device src/m...
Message-ID: <E1OMTxq-00032x-4P@ra.coresystems.de>

Author: myles
Date: Thu Jun 10 00:41:35 2010
New Revision: 5626
URL: https://tracker.coreboot.org/trac/coreboot/changeset/5626

Log:
Same conversion as with resources from static arrays to lists, except
there is no free list.

Converting resource arrays to lists reduced the size of each device
struct from 1092 to 228 bytes.

Converting link arrays to lists reduced the size of each device struct
from 228 to 68 bytes.

Signed-off-by: Myles Watson <mylesgw at gmail.com>
Acked-by: Stefan Reinauer <stepan at coresystems.de>

Modified:
   trunk/src/arch/i386/boot/mpspec.c
   trunk/src/cpu/amd/sc520/sc520.c
   trunk/src/devices/cardbus_device.c
   trunk/src/devices/device.c
   trunk/src/devices/device_util.c
   trunk/src/devices/oprom/yabel/device.c
   trunk/src/devices/pci_device.c
   trunk/src/devices/pcix_device.c
   trunk/src/devices/root_device.c
   trunk/src/devices/smbus_ops.c
   trunk/src/drivers/generic/debug/debug_dev.c
   trunk/src/drivers/i2c/i2cmux/i2cmux.c
   trunk/src/drivers/i2c/i2cmux2/i2cmux2.c
   trunk/src/include/device/device.h
   trunk/src/mainboard/emulation/qemu-x86/northbridge.c
   trunk/src/mainboard/ibase/mb899/mptable.c
   trunk/src/mainboard/kontron/986lcd-m/mptable.c
   trunk/src/mainboard/tyan/s2881/mainboard.c
   trunk/src/northbridge/amd/amdfam10/northbridge.c
   trunk/src/northbridge/amd/amdk8/northbridge.c
   trunk/src/northbridge/amd/gx1/northbridge.c
   trunk/src/northbridge/amd/gx2/northbridge.c
   trunk/src/northbridge/amd/lx/northbridge.c
   trunk/src/northbridge/intel/e7501/northbridge.c
   trunk/src/northbridge/intel/e7520/northbridge.c
   trunk/src/northbridge/intel/e7525/northbridge.c
   trunk/src/northbridge/intel/i3100/northbridge.c
   trunk/src/northbridge/intel/i3100/pciexp_porta_ep80579.c
   trunk/src/northbridge/intel/i440bx/northbridge.c
   trunk/src/northbridge/intel/i440lx/northbridge.c
   trunk/src/northbridge/intel/i82810/northbridge.c
   trunk/src/northbridge/intel/i82830/northbridge.c
   trunk/src/northbridge/intel/i855/northbridge.c
   trunk/src/northbridge/intel/i945/northbridge.c
   trunk/src/northbridge/via/cn400/northbridge.c
   trunk/src/northbridge/via/cn700/northbridge.c
   trunk/src/northbridge/via/cx700/northbridge.c
   trunk/src/northbridge/via/vt8601/northbridge.c
   trunk/src/northbridge/via/vt8623/northbridge.c
   trunk/src/northbridge/via/vx800/northbridge.c
   trunk/src/southbridge/amd/amd8131/amd8131_bridge.c
   trunk/src/southbridge/amd/amd8132/amd8132_bridge.c
   trunk/src/southbridge/amd/sb600/sb600_lpc.c
   trunk/src/southbridge/amd/sb700/sb700_lpc.c
   trunk/src/southbridge/broadcom/bcm5785/bcm5785_lpc.c
   trunk/src/southbridge/intel/i82801gx/i82801gx_pci.c
   trunk/src/southbridge/intel/pxhd/pxhd_bridge.c
   trunk/src/southbridge/nvidia/ck804/ck804_lpc.c
   trunk/src/southbridge/nvidia/ck804/ck804_smbus.c
   trunk/src/southbridge/nvidia/mcp55/mcp55_lpc.c
   trunk/src/southbridge/nvidia/mcp55/mcp55_smbus.c
   trunk/src/southbridge/sis/sis966/sis966_lpc.c
   trunk/util/sconfig/main.c

Modified: trunk/src/arch/i386/boot/mpspec.c
==============================================================================
--- trunk/src/arch/i386/boot/mpspec.c	Thu Jun 10 00:39:00 2010	(r5625)
+++ trunk/src/arch/i386/boot/mpspec.c	Thu Jun 10 00:41:35 2010	(r5626)
@@ -190,7 +190,6 @@
 {
 	struct device *child;
 
-	int linkn;
 	int i;
 	int srcbus;
 	int slot;
@@ -198,9 +197,8 @@
 	struct bus *link;
 	unsigned char dstirq_x[4];
 
-	for (linkn = 0; linkn < dev->links; linkn++) {
+	for (link = dev->link_list; link; link = link->next) {
 
-		link = &dev->link[linkn];
 		child = link->children;
 		srcbus = link->secondary;
 

Modified: trunk/src/cpu/amd/sc520/sc520.c
==============================================================================
--- trunk/src/cpu/amd/sc520/sc520.c	Thu Jun 10 00:39:00 2010	(r5625)
+++ trunk/src/cpu/amd/sc520/sc520.c	Thu Jun 10 00:41:35 2010	(r5626)
@@ -130,8 +130,8 @@
 	device_t mc_dev;
         uint32_t pci_tolm;
   printk(BIOS_SPEW, "%s\n", __func__);
-        pci_tolm = find_pci_tolm(&dev->link[0]);
-	mc_dev = dev->link[0].children;
+        pci_tolm = find_pci_tolm(dev->link_list);
+	mc_dev = dev->link_list->children;
 	if (mc_dev) {
 		unsigned long tomk, tolmk;
 		//		unsigned char rambits;
@@ -168,7 +168,7 @@
 		idx = 10;
 		ram_resource(dev, idx++, 0, tolmk);
 	}
-	assign_resources(&dev->link[0]);
+	assign_resources(dev->link_list);
 }
 
 #if 0

Modified: trunk/src/devices/cardbus_device.c
==============================================================================
--- trunk/src/devices/cardbus_device.c	Thu Jun 10 00:39:00 2010	(r5625)
+++ trunk/src/devices/cardbus_device.c	Thu Jun 10 00:41:35 2010	(r5626)
@@ -158,7 +158,7 @@
 {
 	uint16_t ctrl;
 	ctrl = pci_read_config16(dev, PCI_CB_BRIDGE_CONTROL);
-	ctrl |= (dev->link[0].bridge_ctrl & (
+	ctrl |= (dev->link_list->bridge_ctrl & (
 			PCI_BRIDGE_CTL_PARITY |
 			PCI_BRIDGE_CTL_SERR |
 			PCI_BRIDGE_CTL_NO_ISA |
@@ -178,8 +178,8 @@
 	.read_resources   = cardbus_read_resources,
 	.set_resources    = pci_dev_set_resources,
 	.enable_resources = cardbus_enable_resources,
-	.init		  = 0,
-	.scan_bus	  = pci_scan_bridge,
+	.init			  = 0,
+	.scan_bus		  = pci_scan_bridge,
 	.enable           = 0,
 	.reset_bus        = pci_bus_reset,
 };

Modified: trunk/src/devices/device.c
==============================================================================
--- trunk/src/devices/device.c	Thu Jun 10 00:39:00 2010	(r5625)
+++ trunk/src/devices/device.c	Thu Jun 10 00:41:35 2010	(r5626)
@@ -66,7 +66,6 @@
 device_t alloc_dev(struct bus *parent, struct device_path *path)
 {
 	device_t dev, child;
-	int link;
 
 	spin_lock(&dev_lock);
 
@@ -82,12 +81,6 @@
 	memset(dev, 0, sizeof(*dev));
 	memcpy(&dev->path, path, sizeof(*path));
 
-	/* Initialize the back pointers in the link fields. */
-	for (link = 0; link < MAX_LINKS; link++) {
-		dev->link[link].dev = dev;
-		dev->link[link].link = link;
-	}
-
 	/* By default devices are enabled. */
 	dev->enabled = 1;
 
@@ -132,11 +125,11 @@
 	struct device *curdev;
 
 	printk(BIOS_SPEW, "%s %s bus %x link: %d\n", dev_path(bus->dev), __func__,
-		    bus->secondary, bus->link);
+		    bus->secondary, bus->link_num);
 
 	/* Walk through all devices and find which resources they need. */
 	for (curdev = bus->children; curdev; curdev = curdev->sibling) {
-		int i;
+		struct bus *link;
 		if (!curdev->enabled) {
 			continue;
 		}
@@ -148,11 +141,11 @@
 		curdev->ops->read_resources(curdev);
 
 		/* Read in the resources behind the current device's links. */
-		for (i = 0; i < curdev->links; i++)
-			read_resources(&curdev->link[i]);
+		for (link = curdev->link_list; link; link = link->next)
+			read_resources(link);
 	}
 	printk(BIOS_SPEW, "%s read_resources bus %d link: %d done\n",
-		    dev_path(bus->dev), bus->secondary, bus->link);
+		    dev_path(bus->dev), bus->secondary, bus->link_num);
 }
 
 struct pick_largest_state {
@@ -257,13 +250,13 @@
 	for (dev = bus->children; dev; dev = dev->sibling) {
 		struct resource *child_bridge;
 
-		if (!dev->links)
+		if (!dev->link_list)
 			continue;
 
 		/* Find the resources with matching type flags. */
 		for (child_bridge = dev->resource_list; child_bridge;
 		     child_bridge = child_bridge->next) {
-			unsigned link;
+			struct bus* link;
 
 			if (!(child_bridge->flags & IORESOURCE_BRIDGE) ||
 			    (child_bridge->flags & type_mask) != type)
@@ -275,8 +268,15 @@
 			 * need it separated.  Add the PREFETCH flag to the
 			 * type_mask and type.
 			 */
-			link = IOINDEX_LINK(child_bridge->index);
-			compute_resources(&dev->link[link], child_bridge,
+			link = dev->link_list;
+			while (link && link->link_num !=
+					IOINDEX_LINK(child_bridge->index))
+				link = link->next;
+			if (link == NULL)
+				printk(BIOS_ERR, "link %ld not found on %s\n",
+				       IOINDEX_LINK(child_bridge->index),
+				       dev_path(dev));
+			compute_resources(link, child_bridge,
 					  type_mask | IORESOURCE_PREFETCH,
 					  type | (child_bridge->flags &
 						  IORESOURCE_PREFETCH));
@@ -505,13 +505,13 @@
 	for (dev = bus->children; dev; dev = dev->sibling) {
 		struct resource *child_bridge;
 
-		if (!dev->links)
+		if (!dev->link_list)
 			continue;
 
 		/* Find the resources with matching type flags. */
 		for (child_bridge = dev->resource_list; child_bridge;
 		     child_bridge = child_bridge->next) {
-			unsigned link;
+			struct bus* link;
 
 			if (!(child_bridge->flags & IORESOURCE_BRIDGE) ||
 			    (child_bridge->flags & type_mask) != type)
@@ -523,8 +523,15 @@
 			 * need it separated.  Add the PREFETCH flag to the
 			 * type_mask and type.
 			 */
-			link = IOINDEX_LINK(child_bridge->index);
-			allocate_resources(&dev->link[link], child_bridge,
+			link = dev->link_list;
+			while (link && link->link_num !=
+			               IOINDEX_LINK(child_bridge->index))
+				link = link->next;
+			if (link == NULL)
+				printk(BIOS_ERR, "link %ld not found on %s\n",
+				       IOINDEX_LINK(child_bridge->index),
+				       dev_path(dev));
+			allocate_resources(link, child_bridge,
 					   type_mask | IORESOURCE_PREFETCH,
 					   type | (child_bridge->flags &
 						   IORESOURCE_PREFETCH));
@@ -551,7 +558,7 @@
 	struct device *child;
 	struct resource *res;
 	struct resource *lim;
-	int i;
+	struct bus *link;
 
 	printk(BIOS_SPEW, "%s: %s\n", __func__, dev_path(dev));
 
@@ -592,8 +599,8 @@
 	}
 
 	/* Descend into every enabled child and look for fixed resources. */
-	for (i = 0; i < dev->links; i++)
-		for (child = dev->link[i].children; child;
+	for (link = dev->link_list; link; link = link->next)
+		for (child = link->children; child;
 		     child = child->sibling)
 			if (child->enabled)
 				constrain_resources(child, limits);
@@ -757,7 +764,7 @@
 	struct device *curdev;
 
 	printk(BIOS_SPEW, "%s assign_resources, bus %d link: %d\n",
-		    dev_path(bus->dev), bus->secondary, bus->link);
+		    dev_path(bus->dev), bus->secondary, bus->link_num);
 
 	for (curdev = bus->children; curdev; curdev = curdev->sibling) {
 		if (!curdev->enabled || !curdev->resource_list) {
@@ -771,7 +778,7 @@
 		curdev->ops->set_resources(curdev);
 	}
 	printk(BIOS_SPEW, "%s assign_resources, bus %d link: %d\n",
-		    dev_path(bus->dev), bus->secondary, bus->link);
+		    dev_path(bus->dev), bus->secondary, bus->link_num);
 }
 
 /**
@@ -846,12 +853,12 @@
 
 	do_scan_bus = 1;
 	while (do_scan_bus) {
-		int link;
+		struct bus *link;
 		new_max = busdev->ops->scan_bus(busdev, max);
 		do_scan_bus = 0;
-		for (link = 0; link < busdev->links; link++) {
-			if (busdev->link[link].reset_needed) {
-				if (reset_bus(&busdev->link[link])) {
+		for (link = busdev->link_list; link; link = link->next) {
+			if (link->reset_needed) {
+				if (reset_bus(link)) {
 					do_scan_bus = 1;
 				} else {
 					busdev->bus->reset_needed = 1;
@@ -940,30 +947,30 @@
 	/* Read the resources for the entire tree. */
 
 	printk(BIOS_INFO, "Reading resources...\n");
-	read_resources(&root->link[0]);
+	read_resources(root->link_list);
 	printk(BIOS_INFO, "Done reading resources.\n");
 
 	print_resource_tree(root, BIOS_SPEW, "After reading.");
 
 	/* Compute resources for all domains. */
-	for (child = root->link[0].children; child; child = child->sibling) {
+	for (child = root->link_list->children; child; child = child->sibling) {
 		if (!(child->path.type == DEVICE_PATH_PCI_DOMAIN))
 			continue;
 		for (res = child->resource_list; res; res = res->next) {
 			if (res->flags & IORESOURCE_FIXED)
 				continue;
 			if (res->flags & IORESOURCE_PREFETCH) {
-				compute_resources(&child->link[0],
+				compute_resources(child->link_list,
 					       res, MEM_MASK, PREF_TYPE);
 				continue;
 			}
 			if (res->flags & IORESOURCE_MEM) {
-				compute_resources(&child->link[0],
+				compute_resources(child->link_list,
 					       res, MEM_MASK, MEM_TYPE);
 				continue;
 			}
 			if (res->flags & IORESOURCE_IO) {
-				compute_resources(&child->link[0],
+				compute_resources(child->link_list,
 					       res, IO_MASK, IO_TYPE);
 				continue;
 			}
@@ -971,14 +978,14 @@
 	}
 
 	/* For all domains. */
-	for (child = root->link[0].children; child; child=child->sibling)
+	for (child = root->link_list->children; child; child=child->sibling)
 		if (child->path.type == DEVICE_PATH_PCI_DOMAIN)
 			avoid_fixed_resources(child);
 
 	/* Now we need to adjust the resources. MEM resources need to start at
 	 * the highest address managable.
 	 */
-	for (child = root->link[0].children; child; child = child->sibling) {
+	for (child = root->link_list->children; child; child = child->sibling) {
 		if (child->path.type != DEVICE_PATH_PCI_DOMAIN)
 			continue;
 		for (res = child->resource_list; res; res = res->next) {
@@ -991,30 +998,30 @@
 
 	/* Store the computed resource allocations into device registers ... */
 	printk(BIOS_INFO, "Setting resources...\n");
-	for (child = root->link[0].children; child; child = child->sibling) {
+	for (child = root->link_list->children; child; child = child->sibling) {
 		if (!(child->path.type == DEVICE_PATH_PCI_DOMAIN))
 			continue;
 		for (res = child->resource_list; res; res = res->next) {
 			if (res->flags & IORESOURCE_FIXED)
 				continue;
 			if (res->flags & IORESOURCE_PREFETCH) {
-				allocate_resources(&child->link[0],
+				allocate_resources(child->link_list,
 					       res, MEM_MASK, PREF_TYPE);
 				continue;
 			}
 			if (res->flags & IORESOURCE_MEM) {
-				allocate_resources(&child->link[0],
+				allocate_resources(child->link_list,
 					       res, MEM_MASK, MEM_TYPE);
 				continue;
 			}
 			if (res->flags & IORESOURCE_IO) {
-				allocate_resources(&child->link[0],
+				allocate_resources(child->link_list,
 					       res, IO_MASK, IO_TYPE);
 				continue;
 			}
 		}
 	}
-	assign_resources(&root->link[0]);
+	assign_resources(root->link_list);
 	printk(BIOS_INFO, "Done setting resources.\n");
 	print_resource_tree(root, BIOS_SPEW, "After assigning values.");
 
@@ -1055,7 +1062,7 @@
 			if (dev->path.type == DEVICE_PATH_I2C) {
 				printk(BIOS_DEBUG, "smbus: %s[%d]->",
 					     dev_path(dev->bus->dev),
-					     dev->bus->link);
+					     dev->bus->link_num);
 			}
 			printk(BIOS_DEBUG, "%s init\n", dev_path(dev));
 			dev->initialized = 1;

Modified: trunk/src/devices/device_util.c
==============================================================================
--- trunk/src/devices/device_util.c	Thu Jun 10 00:39:00 2010	(r5625)
+++ trunk/src/devices/device_util.c	Thu Jun 10 00:41:35 2010	(r5626)
@@ -40,7 +40,7 @@
 device_t find_dev_path(struct bus *parent, struct device_path *path)
 {
 	device_t child;
-	for(child = parent->children; child; child = child->sibling) {
+	for (child = parent->children; child; child = child->sibling) {
 		if (path_eq(path, &child->path)) {
 			break;
 		}
@@ -213,7 +213,7 @@
 const char *bus_path(struct bus *bus)
 {
 	static char buffer[BUS_PATH_MAX];
-	sprintf(buffer, "%s,%d", dev_path(bus->dev), bus->link);
+	sprintf(buffer, "%s,%d", dev_path(bus->dev), bus->link_num);
 	return buffer;
 }
 
@@ -303,7 +303,7 @@
 {
 	struct resource *res, *next, *prev = NULL;
 	/* Move all of the free resources to the end */
-	for(res = dev->resource_list; res; res = next) {
+	for (res = dev->resource_list; res; res = next) {
 		next = res->next;
 		if (!res->flags)
 			free_resource(dev, res, prev);
@@ -323,7 +323,7 @@
 {
 	struct resource *res;
 	/* See if there is a resource with the appropriate index */
-	for(res = dev->resource_list; res; res = res->next) {
+	for (res = dev->resource_list; res; res = res->next) {
 		if (res->index == index)
 			break;
 	}
@@ -496,9 +496,9 @@
 		buf[0] = '\0';
 		if (resource->flags & IORESOURCE_PCI_BRIDGE) {
 #if CONFIG_PCI_BUS_SEGN_BITS
-			sprintf(buf, "bus %04x:%02x ", dev->bus->secondary>>8, dev->link[0].secondary & 0xff);
+			sprintf(buf, "bus %04x:%02x ", dev->bus->secondary>>8, dev->link_list->secondary & 0xff);
 #else
-			sprintf(buf, "bus %02x ", dev->link[0].secondary);
+			sprintf(buf, "bus %02x ", dev->link_list->secondary);
 #endif
 		}
 		printk(BIOS_DEBUG,
@@ -518,11 +518,11 @@
 	resource_search_t search, void *gp)
 {
 	struct device *curdev;
-	for(curdev = bus->children; curdev; curdev = curdev->sibling) {
+	for (curdev = bus->children; curdev; curdev = curdev->sibling) {
 		struct resource *res;
 		/* Ignore disabled devices */
 		if (!curdev->enabled) continue;
-		for(res = curdev->resource_list; res; res = res->next) {
+		for (res = curdev->resource_list; res; res = res->next) {
 			/* If it isn't the right kind of resource ignore it */
 			if ((res->flags & type_mask) != type) {
 				continue;
@@ -530,7 +530,9 @@
 			/* If it is a subtractive resource recurse */
 			if (res->flags & IORESOURCE_SUBTRACTIVE) {
 				struct bus * subbus;
-				subbus = &curdev->link[IOINDEX_SUBTRACTIVE_LINK(res->index)];
+				for (subbus = curdev->link_list; subbus; subbus = subbus->next)
+					if (subbus->link_num == IOINDEX_SUBTRACTIVE_LINK(res->index))
+						break;
 				search_bus_resources(subbus, type_mask, type, search, gp);
 				continue;
 			}
@@ -544,11 +546,11 @@
 	resource_search_t search, void *gp)
 {
 	struct device *curdev;
-	for(curdev = all_devices; curdev; curdev = curdev->next) {
+	for (curdev = all_devices; curdev; curdev = curdev->next) {
 		struct resource *res;
 		/* Ignore disabled devices */
 		if (!curdev->enabled) continue;
-		for(res = curdev->resource_list; res; res = res->next) {
+		for (res = curdev->resource_list; res; res = res->next) {
 			/* If it isn't the right kind of resource ignore it */
 			if ((res->flags & type_mask) != type) {
 				continue;
@@ -579,10 +581,10 @@
 void disable_children(struct bus *bus)
 {
 	device_t child;
-	for(child = bus->children; child; child = child->sibling) {
-		int link;
-		for(link = 0; link < child->links; link++) {
-			disable_children(&child->link[link]);
+	for (child = bus->children; child; child = child->sibling) {
+		struct bus *link;
+		for (link = child->link_list; link; link = link->next) {
+			disable_children(link);
 		}
 		dev_set_enabled(child, 0);
 	}
@@ -590,8 +592,9 @@
 
 static void resource_tree(struct device *root, int debug_level, int depth)
 {
-	int i = 0, link = 0;
+	int i = 0;
 	struct device *child;
+	struct bus *link;
 	struct resource *res;
 	char indent[30];	/* If your tree has more levels, it's wrong. */
 
@@ -599,10 +602,12 @@
 		indent[i] = ' ';
 	indent[i] = '\0';
 
-	do_printk(debug_level, "%s%s links %x child on link 0", indent,
-		  dev_path(root), root->links);
-	do_printk(debug_level, " %s\n", root->link[0].children ?
-		  dev_path(root->link[0].children) : "NULL");
+ 	do_printk(BIOS_DEBUG, "%s%s", indent, dev_path(root));
+ 	if (root->link_list && root->link_list->children)
+ 		do_printk(BIOS_DEBUG, " child on link 0 %s",
+ 			  dev_path(root->link_list->children));
+ 	do_printk(BIOS_DEBUG, "\n");
+
 	for (res = root->resource_list; res; res = res->next) {
 		do_printk(debug_level,
 			  "%s%s resource base %llx size %llx align %d gran %d limit %llx flags %lx index %lx\n",
@@ -612,9 +617,8 @@
 			  res->flags, res->index);
 	}
 
-	for (link = 0; link < root->links; link++) {
-		for (child = root->link[link].children; child;
-		     child = child->sibling)
+	for (link = root->link_list; link; link = link->next) {
+		for (child = link->children; child; child = child->sibling)
 			resource_tree(child, debug_level, depth + 1);
 	}
 }
@@ -640,13 +644,15 @@
 	char depth_str[20] = "";
 	int i;
 	struct device *sibling;
+	struct bus *link;
+
 	for (i = 0; i < depth; i++)
 		depth_str[i] = ' ';
 	depth_str[i] = '\0';
 	do_printk(debug_level, "%s%s: enabled %d\n",
 		  depth_str, dev_path(dev), dev->enabled);
-	for (i = 0; i < dev->links; i++) {
-		for (sibling = dev->link[i].children; sibling;
+	for (link = dev->link_list; link; link = link->next) {
+		for (sibling = link->children; sibling;
 		     sibling = sibling->sibling)
 			show_devs_tree(sibling, debug_level, depth + 1, i);
 	}

Modified: trunk/src/devices/oprom/yabel/device.c
==============================================================================
--- trunk/src/devices/oprom/yabel/device.c	Thu Jun 10 00:39:00 2010	(r5625)
+++ trunk/src/devices/oprom/yabel/device.c	Thu Jun 10 00:41:35 2010	(r5626)
@@ -45,7 +45,7 @@
 {
 	int taa_index = 0;
 	struct resource *r;
-	u8 bus = bios_device.dev->bus->link;
+	u8 bus = bios_device.dev->bus->link_num;
 	u16 devfn = bios_device.dev->path.pci.devfn;
 
 	bios_device.bus =  bus;

Modified: trunk/src/devices/pci_device.c
==============================================================================
--- trunk/src/devices/pci_device.c	Thu Jun 10 00:39:00 2010	(r5625)
+++ trunk/src/devices/pci_device.c	Thu Jun 10 00:41:35 2010	(r5626)
@@ -551,15 +551,13 @@
 void pci_dev_set_resources(struct device *dev)
 {
 	struct resource *res;
-	unsigned link;
+	struct bus *bus;
 	u8 line;
 
 	for (res = dev->resource_list; res; res = res->next) {
 		pci_set_resource(dev, res);
 	}
-	for (link = 0; link < dev->links; link++) {
-		struct bus *bus;
-		bus = &dev->link[link];
+	for (bus = dev->link_list; bus; bus = bus->next) {
 		if (bus->children) {
 			assign_resources(bus);
 		}
@@ -614,10 +612,10 @@
 	/* Enable I/O in command register if there is VGA card
 	 * connected with (even it does not claim I/O resource).
 	 */
-	if (dev->link[0].bridge_ctrl & PCI_BRIDGE_CTL_VGA)
+	if (dev->link_list->bridge_ctrl & PCI_BRIDGE_CTL_VGA)
 		dev->command |= PCI_COMMAND_IO;
 	ctrl = pci_read_config16(dev, PCI_BRIDGE_CONTROL);
-	ctrl |= dev->link[0].bridge_ctrl;
+	ctrl |= dev->link_list->bridge_ctrl;
 	ctrl |= (PCI_BRIDGE_CTL_PARITY + PCI_BRIDGE_CTL_SERR);	/* Error check. */
 	printk(BIOS_DEBUG, "%s bridge ctrl <- %04x\n", dev_path(dev), ctrl);
 	pci_write_config16(dev, PCI_BRIDGE_CONTROL, ctrl);
@@ -1102,9 +1100,17 @@
 
 	printk(BIOS_SPEW, "%s for %s\n", __func__, dev_path(dev));
 
-	bus = &dev->link[0];
-	bus->dev = dev;
-	dev->links = 1;
+	if (dev->link_list == NULL) {
+		struct bus *link;
+		link = malloc(sizeof(*link));
+		if (link == NULL)
+			die("Couldn't allocate a link!\n");
+		memset(link, 0, sizeof(*link));
+		link->dev = dev;
+		dev->link_list = link;
+	}
+
+	bus = dev->link_list;
 
 	/* Set up the primary, secondary and subordinate bus numbers. We have
 	 * no idea how many buses are behind this bridge yet, so we set the
@@ -1179,7 +1185,7 @@
  */
 unsigned int pci_domain_scan_bus(device_t dev, unsigned int max)
 {
-	max = pci_scan_bus(&dev->link[0], PCI_DEVFN(0, 0), 0xff, max);
+	max = pci_scan_bus(dev->link_list, PCI_DEVFN(0, 0), 0xff, max);
 	return max;
 }
 

Modified: trunk/src/devices/pcix_device.c
==============================================================================
--- trunk/src/devices/pcix_device.c	Thu Jun 10 00:39:00 2010	(r5625)
+++ trunk/src/devices/pcix_device.c	Thu Jun 10 00:41:35 2010	(r5626)
@@ -61,20 +61,11 @@
 	}
 }
 
-unsigned int pcix_scan_bus(struct bus *bus,
-	unsigned min_devfn, unsigned max_devfn, unsigned int max)
+static void pcix_tune_bus(struct bus *bus)
 {
 	device_t child;
-	max = pci_scan_bus(bus, min_devfn, max_devfn, max);
-	for(child = bus->children; child; child = child->sibling) {
-		if (	(child->path.pci.devfn < min_devfn) ||
-			(child->path.pci.devfn > max_devfn))
-		{
-			continue;
-		}
+	for(child = bus->children; child; child = child->sibling)
 		pcix_tune_dev(child);
-	}
-	return max;
 }
 
 const char *pcix_speed(unsigned sstatus)
@@ -124,18 +115,17 @@
 	unsigned pos;
 	unsigned sstatus;
 
+	max = do_pci_scan_bridge(dev, max, pci_scan_bus);
 	/* Find the PCI-X capability */
 	pos = pci_find_capability(dev, PCI_CAP_ID_PCIX);
 	sstatus = pci_read_config16(dev, pos + PCI_X_SEC_STATUS);
 
-	if (PCI_X_SSTATUS_MFREQ(sstatus) == PCI_X_SSTATUS_CONVENTIONAL_PCI) {
-		max = do_pci_scan_bridge(dev, max, pci_scan_bus);
-	} else {
-		max = do_pci_scan_bridge(dev, max, pcix_scan_bus);
+	if (PCI_X_SSTATUS_MFREQ(sstatus) != PCI_X_SSTATUS_CONVENTIONAL_PCI) {
+		pcix_tune_bus(dev->link_list);
 	}
 
 	/* Print the PCI-X bus speed */
-	printk(BIOS_DEBUG, "PCI: %02x: %s\n", dev->link[0].secondary, pcix_speed(sstatus));
+	printk(BIOS_DEBUG, "PCI: %02x: %s\n", dev->link_list->secondary, pcix_speed(sstatus));
 
 	return max;
 }

Modified: trunk/src/devices/root_device.c
==============================================================================
--- trunk/src/devices/root_device.c	Thu Jun 10 00:39:00 2010	(r5625)
+++ trunk/src/devices/root_device.c	Thu Jun 10 00:41:35 2010	(r5626)
@@ -75,17 +75,17 @@
 unsigned int scan_static_bus(device_t bus, unsigned int max)
 {
 	device_t child;
-	unsigned link;
+	struct bus* link;
 
 	printk(BIOS_SPEW, "%s for %s\n", __func__, dev_path(bus));
 
-	for(link = 0; link < bus->links; link++) {
+	for(link = bus->link_list; link; link = link->next) {
 		/* for smbus bus enumerate */
-		child = bus->link[link].children;
+		child = link->children;
 		if(child && child->path.type == DEVICE_PATH_I2C) {
-			bus->link[link].secondary = ++smbus_max;
+			link->secondary = ++smbus_max;
 		}
-		for(child = bus->link[link].children; child; child = child->sibling) {
+		for(child =link->children; child; child = child->sibling) {
 			if (child->chip_ops && child->chip_ops->enable_dev) {
 				child->chip_ops->enable_dev(child);
 			}
@@ -94,15 +94,15 @@
 			}
  			if (child->path.type == DEVICE_PATH_I2C) {
  				printk(BIOS_DEBUG, "smbus: %s[%d]->",
-					dev_path(child->bus->dev), child->bus->link );
+					dev_path(child->bus->dev), child->bus->link_num );
 			}
 			printk(BIOS_DEBUG, "%s %s\n",
 				dev_path(child),
 				child->enabled?"enabled": "disabled");
 		}
 	}
-	for(link = 0; link < bus->links; link++) {
-		for(child = bus->link[link].children; child; child = child->sibling) {
+	for(link = bus->link_list; link; link = link->next) {
+		for(child = link->children; child; child = child->sibling) {
 			if (!child->ops || !child->ops->scan_bus)
 				continue;
 			printk(BIOS_SPEW, "%s scanning...\n", dev_path(child));
@@ -130,10 +130,10 @@
  */
 void enable_childrens_resources(device_t dev)
 {
-	unsigned link;
-	for(link = 0; link < dev->links; link++) {
+	struct bus *link;
+	for(link = dev->link_list; link; link = link->next) {
 		device_t child;
-		for(child = dev->link[link].children; child; child = child->sibling) {
+		for(child = link->children; child; child = child->sibling) {
 			enable_resources(child);
 		}
 	}

Modified: trunk/src/devices/smbus_ops.c
==============================================================================
--- trunk/src/devices/smbus_ops.c	Thu Jun 10 00:39:00 2010	(r5625)
+++ trunk/src/devices/smbus_ops.c	Thu Jun 10 00:41:35 2010	(r5626)
@@ -58,7 +58,7 @@
 //		printk(BIOS_INFO, " %s[%d] -> ", dev_path(pbus_a[i]->dev), pbus_a[i]->link);
         	if (ops_smbus_bus(get_pbus_smbus(pbus_a[i]->dev))) {
                 	if (pbus_a[i]->dev->ops && pbus_a[i]->dev->ops->set_link)
-                        	pbus_a[i]->dev->ops->set_link(pbus_a[i]->dev, pbus_a[i]->link);
+                        	pbus_a[i]->dev->ops->set_link(pbus_a[i]->dev, pbus_a[i]->link_num);
 		}
 	}
 //	printk(BIOS_INFO, " %s\n", dev_path(dev));

Modified: trunk/src/drivers/generic/debug/debug_dev.c
==============================================================================
--- trunk/src/drivers/generic/debug/debug_dev.c	Thu Jun 10 00:39:00 2010	(r5625)
+++ trunk/src/drivers/generic/debug/debug_dev.c	Thu Jun 10 00:41:35 2010	(r5626)
@@ -85,7 +85,7 @@
 static void print_smbus_regs(struct device *dev)
 {
 	int j;
-	printk(BIOS_DEBUG, "smbus: %s[%d]->", dev_path(dev->bus->dev), dev->bus->link);
+	printk(BIOS_DEBUG, "smbus: %s[%d]->", dev_path(dev->bus->dev), dev->bus->link_num);
 	printk(BIOS_DEBUG, "%s", dev_path(dev));
 	for(j = 0; j < 256; j++) {
 		int status;
@@ -107,22 +107,22 @@
 static void print_smbus_regs_all(struct device *dev)
 {
 	struct device *child;
-	int i;
+	struct bus *link;
 	if (dev->enabled && dev->path.type == DEVICE_PATH_I2C)
 	{
 		// Here don't need to call smbus_set_link, because we scan it from top to down
 		if( dev->bus->dev->path.type == DEVICE_PATH_I2C) { // it's under i2c MUX so set mux at first
 			if(ops_smbus_bus(get_pbus_smbus(dev->bus->dev))) {
 				if(dev->bus->dev->ops && dev->bus->dev->ops->set_link)
-					dev->bus->dev->ops->set_link(dev->bus->dev, dev->bus->link);
+					dev->bus->dev->ops->set_link(dev->bus->dev, dev->bus->link_num);
 			}
 		}
 
 		if(ops_smbus_bus(get_pbus_smbus(dev))) print_smbus_regs(dev);
 	}
 
-	for(i=0; i< dev->links; i++) {
-		for (child = dev->link[i].children; child; child = child->sibling) {
+	for(link = dev->link_list; link; link = link->next) {
+		for (child = link->children; child; child = child->sibling) {
 			print_smbus_regs_all(child);
         	}
 	}

Modified: trunk/src/drivers/i2c/i2cmux/i2cmux.c
==============================================================================
--- trunk/src/drivers/i2c/i2cmux/i2cmux.c	Thu Jun 10 00:39:00 2010	(r5625)
+++ trunk/src/drivers/i2c/i2cmux/i2cmux.c	Thu Jun 10 00:41:35 2010	(r5626)
@@ -34,7 +34,7 @@
 
 static void enable_dev(struct device *dev)
 {
-	if(dev->links>0)
+	if(dev->link_list != NULL)
 		dev->ops = &i2cmux_operations;
 }
 

Modified: trunk/src/drivers/i2c/i2cmux2/i2cmux2.c
==============================================================================
--- trunk/src/drivers/i2c/i2cmux2/i2cmux2.c	Thu Jun 10 00:39:00 2010	(r5625)
+++ trunk/src/drivers/i2c/i2cmux2/i2cmux2.c	Thu Jun 10 00:41:35 2010	(r5626)
@@ -33,7 +33,7 @@
 
 static void enable_dev(struct device *dev)
 {
-	if(dev->links>0)
+	if(dev->link_list != NULL)
 		dev->ops = &i2cmux2_operations;
 }
 

Modified: trunk/src/include/device/device.h
==============================================================================
--- trunk/src/include/device/device.h	Thu Jun 10 00:39:00 2010	(r5625)
+++ trunk/src/include/device/device.h	Thu Jun 10 00:41:35 2010	(r5626)
@@ -40,8 +40,9 @@
 struct bus {
 	device_t 	dev;		/* This bridge device */
 	device_t 	children;	/* devices behind this bridge */
+	struct bus	*next;		/* The next bridge on this device */
 	unsigned	bridge_ctrl;	/* Bridge control register */
-	unsigned char	link;		/* The index of this link */
+	unsigned char	link_num;	/* The index of this link */
 	uint16_t	secondary; 	/* secondary bus number */
 	uint16_t	subordinate;	/* max subordinate bus number */
 	unsigned char   cap;		/* PCi capability offset */
@@ -49,8 +50,6 @@
 	unsigned	disable_relaxed_ordering : 1;
 };
 
-#define MAX_RESOURCES 24
-#define MAX_LINKS    8
 /*
  * There is one device structure for each slot-number/function-number
  * combination:
@@ -79,9 +78,7 @@
 	/* links are (downstream) buses attached to the device, usually a leaf
 	 * device with no children has 0 buses attached and a bridge has 1 bus
 	 */
-	struct bus link[MAX_LINKS];
-	/* number of buses attached to the device */
-	unsigned int links;
+	struct bus *link_list;
 
 	struct device_operations *ops;
 	const struct chip_operations *chip_ops;
@@ -96,6 +93,7 @@
 extern struct device	*all_devices;	/* list of all devices */
 
 extern struct resource	*free_resources;
+extern struct bus	*free_links;
 
 /* Generic device interface functions */
 device_t alloc_dev(struct bus *parent, struct device_path *path);

Modified: trunk/src/mainboard/emulation/qemu-x86/northbridge.c
==============================================================================
--- trunk/src/mainboard/emulation/qemu-x86/northbridge.c	Thu Jun 10 00:39:00 2010	(r5625)
+++ trunk/src/mainboard/emulation/qemu-x86/northbridge.c	Thu Jun 10 00:41:35 2010	(r5626)
@@ -60,7 +60,7 @@
 
 static void cpu_pci_domain_set_resources(device_t dev)
 {
-	u32 pci_tolm = find_pci_tolm(&dev->link[0]);
+	u32 pci_tolm = find_pci_tolm(dev->link_list);
 	unsigned long tomk = 0, tolmk;
 	int idx;
 
@@ -91,7 +91,7 @@
 	high_tables_size = HIGH_TABLES_SIZE * 1024;
 #endif
 
-	assign_resources(&dev->link[0]);
+	assign_resources(dev->link_list);
 }
 
 static void cpu_pci_domain_read_resources(struct device *dev)

Modified: trunk/src/mainboard/ibase/mb899/mptable.c
==============================================================================
--- trunk/src/mainboard/ibase/mb899/mptable.c	Thu Jun 10 00:39:00 2010	(r5625)
+++ trunk/src/mainboard/ibase/mb899/mptable.c	Thu Jun 10 00:41:35 2010	(r5626)
@@ -70,7 +70,7 @@
 	if (!riser)
 		riser = dev_find_device(0x3388, 0x0022, 0);
 	if (riser) {
-		riser_bus = riser->link[0].secondary;
+		riser_bus = riser->link_list->secondary;
 		printk(BIOS_SPEW, "Riser bus is %x\n", riser_bus);
 		max_pci_bus = riser_bus;
 	}

Modified: trunk/src/mainboard/kontron/986lcd-m/mptable.c
==============================================================================
--- trunk/src/mainboard/kontron/986lcd-m/mptable.c	Thu Jun 10 00:39:00 2010	(r5625)
+++ trunk/src/mainboard/kontron/986lcd-m/mptable.c	Thu Jun 10 00:41:35 2010	(r5626)
@@ -70,7 +70,7 @@
 	if (!riser)
 		riser = dev_find_device(0x3388, 0x0022, 0);
 	if (riser) {
-		riser_bus = riser->link[0].secondary;
+		riser_bus = riser->link_list->secondary;
 		printk(BIOS_SPEW, "Riser bus is %x\n", riser_bus);
 		max_pci_bus = riser_bus;
 	}

Modified: trunk/src/mainboard/tyan/s2881/mainboard.c
==============================================================================
--- trunk/src/mainboard/tyan/s2881/mainboard.c	Thu Jun 10 00:39:00 2010	(r5625)
+++ trunk/src/mainboard/tyan/s2881/mainboard.c	Thu Jun 10 00:41:35 2010	(r5626)
@@ -46,7 +46,7 @@
 	/* Find the ADT7463 device. */
 	path.type = DEVICE_PATH_I2C;
 	path.i2c.device = 0x2d;
-	adt7463 = find_dev_path(smbus_dev->link, &path);
+	adt7463 = find_dev_path(smbus_dev->link_list, &path);
 	if (!adt7463)
 		die("ADT7463 not found\n");
 	printk(BIOS_DEBUG, "ADT7463 found\n");
@@ -113,7 +113,6 @@
 {
 	struct device_path path;
 	device_t dummy;
-	unsigned link_i;
 
 	max = root_dev_scan_bus(root, max);
 
@@ -126,20 +125,10 @@
 	 * as the last device to be initialized.
 	 */
 
-	link_i = root->links;
-	if (link_i >= MAX_LINKS) {
-		printk(BIOS_DEBUG, "Reached MAX_LINKS, not configuring ADT7463");
-		return max;
-	}
-	root->link[link_i].link = link_i;
-	root->link[link_i].dev = root;
-	root->link[link_i].children = 0;
-	root->links++;
-
 	path.type = DEVICE_PATH_PNP;
 	path.pnp.port = 0;
 	path.pnp.device = 0;
-	dummy = alloc_dev(&root->link[link_i], &path);
+	dummy = alloc_dev(root->link_list, &path);
 	dummy->ops = &dummy_operations;
 
 	return max;

Modified: trunk/src/northbridge/amd/amdfam10/northbridge.c
==============================================================================
--- trunk/src/northbridge/amd/amdfam10/northbridge.c	Thu Jun 10 00:39:00 2010	(r5625)
+++ trunk/src/northbridge/amd/amdfam10/northbridge.c	Thu Jun 10 00:41:35 2010	(r5626)
@@ -137,7 +137,7 @@
 
 }
 
-static u32 amdfam10_scan_chain(device_t dev, u32 nodeid, u32 link, u32 sblink,
+static u32 amdfam10_scan_chain(device_t dev, u32 nodeid, struct bus *link, u32 link_num, u32 sblink,
 				u32 max, u32 offset_unitid)
 {
 //	I want to put sb chain in bus 0 can I?
@@ -149,7 +149,7 @@
 		u32 ht_unitid_base[4]; // here assume only 4 HT device on chain
 		u32 max_bus;
 		u32 min_bus;
-		u32 is_sublink1 = (link>3);
+		u32 is_sublink1 = (link_num>3);
 		device_t devx;
 		u32 busses;
 		u32 segn = max>>8;
@@ -162,7 +162,7 @@
 		if(is_sublink1) {
 			u32 regpos;
 			u32 reg;
-			regpos = 0x170 + 4 * (link&3); // it is only on sublink0
+			regpos = 0x170 + 4 * (link_num&3); // it is only on sublink0
 			reg = pci_read_config32(dev, regpos);
 			if(reg & 1) return max; // already ganged no sblink1
 			devx = get_node_pci(nodeid, 4);
@@ -171,15 +171,15 @@
 			devx = dev;
 
 
-		dev->link[link].cap = 0x80 + ((link&3) *0x20);
+		link->cap = 0x80 + ((link_num&3) *0x20);
 		do {
-			link_type = pci_read_config32(devx, dev->link[link].cap + 0x18);
+			link_type = pci_read_config32(devx, link->cap + 0x18);
 		} while(link_type & ConnectionPending);
 		if (!(link_type & LinkConnected)) {
 			return max;
 		}
 		do {
-			link_type = pci_read_config32(devx, dev->link[link].cap + 0x18);
+			link_type = pci_read_config32(devx, link->cap + 0x18);
 		} while(!(link_type & InitComplete));
 		if (!(link_type & NonCoherent)) {
 			return max;
@@ -187,7 +187,7 @@
 		/* See if there is an available configuration space mapping
 		 * register in function 1.
 		 */
-		ht_c_index = get_ht_c_index(nodeid, link, &sysconf);
+		ht_c_index = get_ht_c_index(nodeid, link_num, &sysconf);
 
 #if CONFIG_EXT_CONF_SUPPORT == 0
 		if(ht_c_index>=4) return max;
@@ -199,7 +199,7 @@
 		 */
 #if CONFIG_SB_HT_CHAIN_ON_BUS0 > 0
 		// first chain will on bus 0
-		if((nodeid == 0) && (sblink==link)) { // actually max is 0 here
+		if((nodeid == 0) && (sblink==link_num)) { // actually max is 0 here
 			min_bus = max;
 		}
 	#if CONFIG_SB_HT_CHAIN_ON_BUS0 > 1
@@ -221,26 +221,26 @@
 #endif
 		max_bus = 0xfc | (segn<<8);
 
-		dev->link[link].secondary = min_bus;
-		dev->link[link].subordinate = max_bus;
+		link->secondary = min_bus;
+		link->subordinate = max_bus;
 
 		/* Read the existing primary/secondary/subordinate bus
 		 * number configuration.
 		 */
-		busses = pci_read_config32(devx, dev->link[link].cap + 0x14);
+		busses = pci_read_config32(devx, link->cap + 0x14);
 
 		/* Configure the bus numbers for this bridge: the configuration
 		 * transactions will not be propagates by the bridge if it is
 		 * not correctly configured
 		 */
 		busses &= 0xffff00ff;
-		busses |= ((u32)(dev->link[link].secondary) << 8);
-		pci_write_config32(devx, dev->link[link].cap + 0x14, busses);
+		busses |= ((u32)(link->secondary) << 8);
+		pci_write_config32(devx, link->cap + 0x14, busses);
 
 
 		/* set the config map space */
 
-		set_config_map_reg(nodeid, link, ht_c_index, dev->link[link].secondary, dev->link[link].subordinate, sysconf.segbit, sysconf.nodes);
+		set_config_map_reg(nodeid, link_num, ht_c_index, link->secondary, link->subordinate, sysconf.segbit, sysconf.nodes);
 
 		/* Now we can scan all of the subordinate busses i.e. the
 		 * chain on the hypertranport link
@@ -255,17 +255,17 @@
 		else
 			max_devfn = (0x1f<<3) | 7;
 
-		max = hypertransport_scan_chain(&dev->link[link], 0, max_devfn, max, ht_unitid_base, offset_unitid);
+		max = hypertransport_scan_chain(link, 0, max_devfn, max, ht_unitid_base, offset_unitid);
 
 		/* We know the number of busses behind this bridge.  Set the
 		 * subordinate bus number to it's real value
 		 */
 		if(ht_c_index>3) { // clear the extend reg
-			clear_config_map_reg(nodeid, link, ht_c_index, (max+1)>>sysconf.segbit, (dev->link[link].subordinate)>>sysconf.segbit, sysconf.nodes);
+			clear_config_map_reg(nodeid, link_num, ht_c_index, (max+1)>>sysconf.segbit, (link->subordinate)>>sysconf.segbit, sysconf.nodes);
 		}
 
-		dev->link[link].subordinate = max;
-		set_config_map_reg(nodeid, link, ht_c_index, dev->link[link].secondary, dev->link[link].subordinate, sysconf.segbit, sysconf.nodes);
+		link->subordinate = max;
+		set_config_map_reg(nodeid, link_num, ht_c_index, link->secondary, link->subordinate, sysconf.segbit, sysconf.nodes);
 		sysconf.ht_c_num++;
 
 		{
@@ -278,14 +278,14 @@
 			sysconf.hcdn_reg[ht_c_index] = temp;
 
 		}
-	store_ht_c_conf_bus(nodeid, link, ht_c_index, dev->link[link].secondary, dev->link[link].subordinate, &sysconf);
+	store_ht_c_conf_bus(nodeid, link_num, ht_c_index, link->secondary, link->subordinate, &sysconf);
 	return max;
 }
 
-static u32 amdfam10_scan_chains(device_t dev, u32 max)
+static unsigned amdfam10_scan_chains(device_t dev, unsigned max)
 {
 	unsigned nodeid;
-	u32 link;
+	struct bus *link;
 	unsigned sblink = sysconf.sblk;
 	unsigned offset_unitid = 0;
 
@@ -297,7 +297,9 @@
 	#if ((CONFIG_HT_CHAIN_UNITID_BASE != 1) || (CONFIG_HT_CHAIN_END_UNITID_BASE != 0x20))
 		offset_unitid = 1;
 	#endif
-		max = amdfam10_scan_chain(dev, nodeid, sblink, sblink, max, offset_unitid ); // do sb ht chain at first, in case s2885 put sb chain (8131/8111) on link2, but put 8151 on link0
+		for (link = dev->link_list; link; link = link->next)
+			if (link->link_num == sblink)
+				max = amdfam10_scan_chain(dev, nodeid, link, sblink, sblink, max, offset_unitid ); // do sb ht chain at first, in case s2885 put sb chain (8131/8111) on link2, but put 8151 on link0
 	}
 #endif
 
@@ -305,19 +307,19 @@
 	max = check_segn(dev, max, sysconf.nodes, &sysconf);
 #endif
 
-	for(link = 0; link < dev->links; link++) {
+	for(link = dev->link_list; link; link = link->next) {
 #if CONFIG_SB_HT_CHAIN_ON_BUS0 > 0
-		if( (nodeid == 0) && (sblink == link) ) continue; //already done
+		if( (nodeid == 0) && (sblink == link->link_num) ) continue; //already done
 #endif
 		offset_unitid = 0;
 		#if ((CONFIG_HT_CHAIN_UNITID_BASE != 1) || (CONFIG_HT_CHAIN_END_UNITID_BASE != 0x20))
 			#if CONFIG_SB_HT_CHAIN_UNITID_OFFSET_ONLY == 1
-			if((nodeid == 0) && (sblink == link))
+			if((nodeid == 0) && (sblink == link->link_num))
 			#endif
 				offset_unitid = 1;
 		#endif
 
-		max = amdfam10_scan_chain(dev, nodeid, link, sblink, max, offset_unitid);
+		max = amdfam10_scan_chain(dev, nodeid, link, link->link_num, sblink, max, offset_unitid);
 	}
 	return max;
 }
@@ -482,12 +484,12 @@
 
 static void amdfam10_read_resources(device_t dev)
 {
-	u32 nodeid, link;
-
+	u32 nodeid;
+	struct bus *link;
 	nodeid = amdfam10_nodeid(dev);
-	for(link = 0; link < dev->links; link++) {
-		if (dev->link[link].children) {
-			amdfam10_link_read_bases(dev, nodeid, link);
+	for(link = dev->link_list; link; link = link->next) {
+		if (link->children) {
+			amdfam10_link_read_bases(dev, nodeid, link->link_num);
 		}
 	}
 }
@@ -496,7 +498,7 @@
 				u32 nodeid)
 {
 	resource_t rbase, rend;
-	unsigned reg, link;
+	unsigned reg, link_num;
 	char buf[50];
 
 	/* Make certain the resource has actually been set */
@@ -525,20 +527,20 @@
 
 	/* Get the register and link */
 	reg  = resource->index & 0xfff; // 4k
-	link = IOINDEX_LINK(resource->index);
+	link_num = IOINDEX_LINK(resource->index);
 
 	if (resource->flags & IORESOURCE_IO) {
 
-		set_io_addr_reg(dev, nodeid, link, reg, rbase>>8, rend>>8);
-		store_conf_io_addr(nodeid, link, reg, (resource->index >> 24), rbase>>8, rend>>8);
+		set_io_addr_reg(dev, nodeid, link_num, reg, rbase>>8, rend>>8);
+		store_conf_io_addr(nodeid, link_num, reg, (resource->index >> 24), rbase>>8, rend>>8);
 	}
 	else if (resource->flags & IORESOURCE_MEM) {
-		set_mmio_addr_reg(nodeid, link, reg, (resource->index >>24), rbase>>8, rend>>8, sysconf.nodes) ;// [39:8]
-		store_conf_mmio_addr(nodeid, link, reg, (resource->index >>24), rbase>>8, rend>>8);
+		set_mmio_addr_reg(nodeid, link_num, reg, (resource->index >>24), rbase>>8, rend>>8, sysconf.nodes) ;// [39:8]
+		store_conf_mmio_addr(nodeid, link_num, reg, (resource->index >>24), rbase>>8, rend>>8);
 	}
 	resource->flags |= IORESOURCE_STORED;
-	sprintf(buf, " <node %02x link %02x>",
-		nodeid, link);
+	sprintf(buf, " <node %x link %x>",
+		nodeid, link_num);
 	report_resource_stored(dev, resource, buf);
 }
 
@@ -553,18 +555,18 @@
 
 static void amdfam10_create_vga_resource(device_t dev, unsigned nodeid)
 {
-	unsigned link;
+	struct bus *link;
 
 	/* find out which link the VGA card is connected,
 	 * we only deal with the 'first' vga card */
-	for (link = 0; link < dev->links; link++) {
-		if (dev->link[link].bridge_ctrl & PCI_BRIDGE_CTL_VGA) {
+	for (link = dev->link_list; link; link = link->next) {
+		if (link->bridge_ctrl & PCI_BRIDGE_CTL_VGA) {
 #if CONFIG_CONSOLE_VGA_MULTI == 1
-			printk(BIOS_DEBUG, "VGA: vga_pri bus num = %d dev->link[link] bus range [%d,%d]\n", vga_pri->bus->secondary,
-				dev->link[link].secondary,dev->link[link].subordinate);
+			printk(BIOS_DEBUG, "VGA: vga_pri bus num = %d bus range [%d,%d]\n", vga_pri->bus->secondary,
+				link->secondary,link->subordinate);
 			/* We need to make sure the vga_pri is under the link */
-			if((vga_pri->bus->secondary >= dev->link[link].secondary ) &&
-				(vga_pri->bus->secondary <= dev->link[link].subordinate )
+			if((vga_pri->bus->secondary >= link->secondary ) &&
+				(vga_pri->bus->secondary <= link->subordinate )
 			)
 #endif
 			break;
@@ -572,16 +574,17 @@
 	}
 
 	/* no VGA card installed */
-	if (link == dev->links)
+	if (link == NULL)
 		return;
 
-	printk(BIOS_DEBUG, "VGA: %s (aka node %d) link %d has VGA device\n", dev_path(dev), nodeid, link);
-	set_vga_enable_reg(nodeid, link);
+	printk(BIOS_DEBUG, "VGA: %s (aka node %d) link %d has VGA device\n", dev_path(dev), nodeid, link->link_num);
+	set_vga_enable_reg(nodeid, link->link_num);
 }
 
 static void amdfam10_set_resources(device_t dev)
 {
-	u32 nodeid, link;
+	unsigned nodeid;
+	struct bus *bus;
 	struct resource *res;
 
 	/* Find the nodeid */
@@ -594,9 +597,7 @@
 		amdfam10_set_resource(dev, res, nodeid);
 	}
 
-	for(link = 0; link < dev->links; link++) {
-		struct bus *bus;
-		bus = &dev->link[link];
+	for(bus = dev->link_list; bus; bus = bus->next) {
 		if (bus->children) {
 			assign_resources(bus);
 		}
@@ -672,22 +673,22 @@
 #if CONFIG_PCI_64BIT_PREF_MEM == 0
 	pci_domain_read_resources(dev);
 #else
-	unsigned link;
+	struct bus *link;
 	struct resource *resource;
-	for(link=0; link<dev->links; link++) {
+	for(link=dev->link_list; link; link = link->next) {
 		/* Initialize the system wide io space constraints */
-		resource = new_resource(dev, 0|(link<<2));
+		resource = new_resource(dev, 0|(link->link_num<<2));
 		resource->base	= 0x400;
 		resource->limit = 0xffffUL;
 		resource->flags = IORESOURCE_IO;
 
 		/* Initialize the system wide prefetchable memory resources constraints */
-		resource = new_resource(dev, 1|(link<<2));
+		resource = new_resource(dev, 1|(link->link_num<<2));
 		resource->limit = 0xfcffffffffULL;
 		resource->flags = IORESOURCE_MEM | IORESOURCE_PREFETCH;
 
 		/* Initialize the system wide memory resources constraints */
-		resource = new_resource(dev, 2|(link<<2));
+		resource = new_resource(dev, 2|(link->link_num<<2));
 		resource->limit = 0xfcffffffffULL;
 		resource->flags = IORESOURCE_MEM;
 	}
@@ -881,7 +882,7 @@
 	unsigned long mmio_basek;
 	u32 pci_tolm;
 	int i, idx;
-	u32 link;
+	struct bus *link;
 #if CONFIG_HW_MEM_HOLE_SIZEK != 0
 	struct hw_mem_hole_info mem_hole;
 	u32 reset_memhole = 1;
@@ -889,12 +890,12 @@
 
 #if CONFIG_PCI_64BIT_PREF_MEM == 1
 
-	for(link = 0; link < dev->links; link++) {
+	for(link = dev->link_list; link; link = link->next) {
 		/* Now reallocate the pci resources memory with the
 		 * highest addresses I can manage.
 		 */
-		mem1 = find_resource(dev, 1|(link<<2));
-		mem2 = find_resource(dev, 2|(link<<2));
+		mem1 = find_resource(dev, 1|(link->link_num<<2));
+		mem2 = find_resource(dev, 2|(link->link_num<<2));
 
 		printk(BIOS_DEBUG, "base1: 0x%08Lx limit1: 0x%08Lx size: 0x%08Lx align: %d\n",
 			mem1->base, mem1->limit, mem1->size, mem1->align);
@@ -939,8 +940,8 @@
 #endif
 
 	pci_tolm = 0xffffffffUL;
-	for(link = 0; link<dev->links; link++) {
-		pci_tolm = find_pci_tolm(&dev->link[link], pci_tolm);
+	for(link = dev->link_list; link; link = link->next) {
+		pci_tolm = find_pci_tolm(link, pci_tolm);
 	}
 
 	// FIXME handle interleaved nodes. If you fix this here, please fix
@@ -1084,11 +1085,9 @@
 #endif
 	}
 
-	for(link = 0; link < dev->links; link++) {
-		struct bus *bus;
-		bus = &dev->link[link];
-		if (bus->children) {
-			assign_resources(bus);
+	for(link = dev->link_list; link; link = link->next) {
+		if (link->children) {
+			assign_resources(link);
 		}
 	}
 }
@@ -1097,6 +1096,7 @@
 {
 	u32 reg;
 	int i;
+	struct bus *link;
 	/* Unmap all of the HT chains */
 	for(reg = 0xe0; reg <= 0xec; reg += 4) {
 		f1_write_config32(reg, 0);
@@ -1114,8 +1114,8 @@
 #endif
 
 
-	for(i = 0; i < dev->links; i++) {
-		max = pci_scan_bus(&dev->link[i], PCI_DEVFN(CONFIG_CDB, 0), 0xff, max);
+	for(link = dev->link_list; link; link = link->next) {
+		max = pci_scan_bus(link, PCI_DEVFN(CONFIG_CDB, 0), 0xff, max);
 	}
 
 	/* Tune the hypertransport transaction for best performance.
@@ -1129,12 +1129,12 @@
 			u32 httc;
 			httc = pci_read_config32(f0_dev, HT_TRANSACTION_CONTROL);
 			httc &= ~HTTC_RSP_PASS_PW;
-			if (!dev->link[0].disable_relaxed_ordering) {
+			if (!dev->link_list->disable_relaxed_ordering) {
 				httc |= HTTC_RSP_PASS_PW;
 			}
 			printk(BIOS_SPEW, "%s passpw: %s\n",
 				dev_path(dev),
-				(!dev->link[0].disable_relaxed_ordering)?
+				(!dev->link_list->disable_relaxed_ordering)?
 				"enabled":"disabled");
 			pci_write_config32(f0_dev, HT_TRANSACTION_CONTROL, httc);
 		}
@@ -1197,6 +1197,42 @@
 #endif
 }
 
+static void add_more_links(device_t dev, unsigned total_links)
+{
+	struct bus *link, *last = NULL;
+	int link_num;
+
+	for (link = dev->link_list; link; link = link->next)
+		last = link;
+
+	if (last) {
+		int links = total_links - last->link_num;
+		link_num = last->link_num;
+		if (links > 0) {
+			link = malloc(links*sizeof(*link));
+			if (!link)
+				die("Couldn't allocate more links!\n");
+			memset(link, 0, links*sizeof(*link));
+			last->next = link;
+		}
+	}
+	else {
+		link_num = -1;
+		link = malloc(total_links*sizeof(*link));
+		memset(link, 0, total_links*sizeof(*link));
+		dev->link_list = link;
+	}
+
+	for (link_num = link_num + 1; link_num < total_links; link_num++) {
+		link->link_num = link_num;
+		link->dev = dev;
+		link->next = link + 1;
+		last = link;
+		link = link->next;
+	}
+	last->next = NULL;
+}
+
 static u32 cpu_bus_scan(device_t dev, u32 max)
 {
 	struct bus *cpu_bus;
@@ -1250,7 +1286,7 @@
 			printk(BIOS_DEBUG, "%s found\n", dev_path(dev_mc));
 			pci_domain = dev_mc->bus->dev;
 			if(pci_domain && (pci_domain->path.type == DEVICE_PATH_PCI_DOMAIN)) {
-				if((pci_domain->links==1) && (pci_domain->link[0].children == dev_mc)) {
+				if((pci_domain->link_list) && (pci_domain->link_list->children == dev_mc)) {
 					printk(BIOS_DEBUG, "%s move to ",dev_path(dev_mc));
 					dev_mc->bus->secondary = CONFIG_CBB; // move to 0xff
 					printk(BIOS_DEBUG, "%s\n",dev_path(dev_mc));
@@ -1279,18 +1315,19 @@
 
 #if CONFIG_CBB && (NODE_NUMS > 32)
 	if(nodes>32) { // need to put node 32 to node 63 to bus 0xfe
-		if(pci_domain->links==1) {
-			pci_domain->links++; // from 1 to 2
-			pci_domain->link[1].link = 1;
-			pci_domain->link[1].dev = pci_domain;
-			pci_domain->link[1].children = 0;
-			printk(BIOS_DEBUG, "%s links increase to %d\n", dev_path(pci_domain), pci_domain->links);
+		if(pci_domain->link_list && !pci_domain->link_list->next) {
+			struct bus *new_link = new_link(pci_domain);
+			pci_domain->link_list->next = new_link;
+			new_link->link_num = 1;
+			new_link->dev = pci_domain;
+			new_link->children = 0;
+			printk(BIOS_DEBUG, "%s links now 2\n", dev_path(pci_domain));
 		}
-		pci_domain->link[1].secondary = CONFIG_CBB - 1;
+		pci_domain->link_list->next->secondary = CONFIG_CBB - 1;
 	}
 #endif
 	/* Find which cpus are present */
-	cpu_bus = &dev->link[0];
+	cpu_bus = dev->link_list;
 	for(i = 0; i < nodes; i++) {
 		device_t cdb_dev, cpu;
 		struct device_path cpu_path;
@@ -1304,7 +1341,7 @@
 		if(i>=32) {
 			busn--;
 			devn-=32;
-			pbus = &(pci_domain->link[1]);
+			pbus = pci_domain->link_list->next);
 		}
 #endif
 
@@ -1325,21 +1362,13 @@
 			/* Ok, We need to set the links for that device.
 			 * otherwise the device under it will not be scanned
 			 */
-			int link;
 			int linknum;
 #if CONFIG_HT3_SUPPORT==1
 			linknum = 8;
 #else
 			linknum = 4;
 #endif
-			if (cdb_dev->links < linknum) {
-				for(link=cdb_dev->links; link<linknum; link++) {
-					 cdb_dev->link[link].link = link;
-					 cdb_dev->link[link].dev = cdb_dev;
-				}
-				cdb_dev->links = linknum;
-				printk(BIOS_DEBUG, "%s links increase to %d\n", dev_path(cdb_dev), cdb_dev->links);
-			}
+			add_more_links(cdb_dev, linknum);
 		}
 
 		cores_found = 0; // one core
@@ -1410,7 +1439,7 @@
 
 static void cpu_bus_init(device_t dev)
 {
-	initialize_cpus(&dev->link[0]);
+	initialize_cpus(dev->link_list);
 }
 
 static void cpu_bus_noop(device_t dev)

Modified: trunk/src/northbridge/amd/amdk8/northbridge.c
==============================================================================
--- trunk/src/northbridge/amd/amdk8/northbridge.c	Thu Jun 10 00:39:00 2010	(r5625)
+++ trunk/src/northbridge/amd/amdk8/northbridge.c	Thu Jun 10 00:41:35 2010	(r5626)
@@ -81,7 +81,7 @@
 	return (dev->path.pci.devfn >> 3) - 0x18;
 }
 
-static u32 amdk8_scan_chain(device_t dev, u32 nodeid, u32 link, u32 sblink,
+static u32 amdk8_scan_chain(device_t dev, u32 nodeid, struct bus *link, u32 link_num, u32 sblink,
 				u32 max, u32 offset_unitid)
 {
 
@@ -94,15 +94,15 @@
 		u32 min_bus;
 		u32 max_devfn;
 
-		dev->link[link].cap = 0x80 + (link *0x20);
+		link->cap = 0x80 + (link_num *0x20);
 		do {
-			link_type = pci_read_config32(dev, dev->link[link].cap + 0x18);
+			link_type = pci_read_config32(dev, link->cap + 0x18);
 		} while(link_type & ConnectionPending);
 		if (!(link_type & LinkConnected)) {
 			return max;
 		}
 		do {
-			link_type = pci_read_config32(dev, dev->link[link].cap + 0x18);
+			link_type = pci_read_config32(dev, link->cap + 0x18);
 		} while(!(link_type & InitComplete));
 		if (!(link_type & NonCoherent)) {
 			return max;
@@ -120,7 +120,7 @@
 			}
 			if (((config & 3) == 3) &&
 				(((config >> 4) & 7) == nodeid) &&
-				(((config >> 8) & 3) == link)) {
+				(((config >> 8) & 3) == link_num)) {
 				break;
 			}
 		}
@@ -140,7 +140,7 @@
 		 */
 #if CONFIG_SB_HT_CHAIN_ON_BUS0 > 0
 		// first chain will on bus 0
-		if((nodeid == 0) && (sblink==link)) { // actually max is 0 here
+		if((nodeid == 0) && (sblink==link_num)) { // actually max is 0 here
 			min_bus = max;
 		}
 	#if CONFIG_SB_HT_CHAIN_ON_BUS0 > 1
@@ -160,13 +160,13 @@
 #endif
 		max_bus = 0xff;
 
-		dev->link[link].secondary = min_bus;
-		dev->link[link].subordinate = max_bus;
+		link->secondary = min_bus;
+		link->subordinate = max_bus;
 
 		/* Read the existing primary/secondary/subordinate bus
 		 * number configuration.
 		 */
-		busses = pci_read_config32(dev, dev->link[link].cap + 0x14);
+		busses = pci_read_config32(dev, link->cap + 0x14);
 		config_busses = f1_read_config32(config_reg);
 
 		/* Configure the bus numbers for this bridge: the configuration
@@ -175,17 +175,17 @@
 		 */
 		busses &= 0xff000000;
 		busses |= (((unsigned int)(dev->bus->secondary) << 0) |
-			((unsigned int)(dev->link[link].secondary) << 8) |
-			((unsigned int)(dev->link[link].subordinate) << 16));
-		pci_write_config32(dev, dev->link[link].cap + 0x14, busses);
+			((unsigned int)(link->secondary) << 8) |
+			((unsigned int)(link->subordinate) << 16));
+		pci_write_config32(dev, link->cap + 0x14, busses);
 
 		config_busses &= 0x000fc88;
 		config_busses |=
 			(3 << 0) |  /* rw enable, no device compare */
 			(( nodeid & 7) << 4) |
-			(( link & 3 ) << 8) |
-			((dev->link[link].secondary) << 16) |
-			((dev->link[link].subordinate) << 24);
+			(( link_num & 3 ) << 8) |
+			((link->secondary) << 16) |
+			((link->subordinate) << 24);
 		f1_write_config32(config_reg, config_busses);
 
 		/* Now we can scan all of the subordinate busses i.e. the
@@ -200,18 +200,18 @@
 		else
 			max_devfn = (0x1f<<3) | 7;
 
-		max = hypertransport_scan_chain(&dev->link[link], 0, max_devfn, max, ht_unitid_base, offset_unitid);
+		max = hypertransport_scan_chain(link, 0, max_devfn, max, ht_unitid_base, offset_unitid);
 
 		/* We know the number of busses behind this bridge.  Set the
 		 * subordinate bus number to it's real value
 		 */
-		dev->link[link].subordinate = max;
+		link->subordinate = max;
 		busses = (busses & 0xff00ffff) |
-			((unsigned int) (dev->link[link].subordinate) << 16);
-		pci_write_config32(dev, dev->link[link].cap + 0x14, busses);
+			((unsigned int) (link->subordinate) << 16);
+		pci_write_config32(dev, link->cap + 0x14, busses);
 
 		config_busses = (config_busses & 0x00ffffff) |
-			(dev->link[link].subordinate << 24);
+			(link->subordinate << 24);
 		f1_write_config32(config_reg, config_busses);
 
 		{
@@ -232,7 +232,7 @@
 static unsigned amdk8_scan_chains(device_t dev, unsigned max)
 {
 	unsigned nodeid;
-	unsigned link;
+	struct bus *link;
 	unsigned sblink = 0;
 	unsigned offset_unitid = 0;
 
@@ -244,23 +244,25 @@
 	#if ((CONFIG_HT_CHAIN_UNITID_BASE != 1) || (CONFIG_HT_CHAIN_END_UNITID_BASE != 0x20))
 		offset_unitid = 1;
 	#endif
-		max = amdk8_scan_chain(dev, nodeid, sblink, sblink, max, offset_unitid ); // do sb ht chain at first, in case s2885 put sb chain (8131/8111) on link2, but put 8151 on link0
+		for (link = dev->link_list; link; link = link->next)
+			if (link->link_num == sblink)
+				max = amdk8_scan_chain(dev, nodeid, link, sblink, sblink, max, offset_unitid ); // do sb ht chain at first, in case s2885 put sb chain (8131/8111) on link2, but put 8151 on link0
 #endif
 	}
 
-	for (link = 0; link < dev->links; link++) {
+	for (link = dev->link_list; link; link = link->next) {
 #if CONFIG_SB_HT_CHAIN_ON_BUS0 > 0
-		if( (nodeid == 0) && (sblink == link) ) continue; //already done
+		if( (nodeid == 0) && (sblink == link->link_num) ) continue; //already done
 #endif
 		offset_unitid = 0;
 		#if ((CONFIG_HT_CHAIN_UNITID_BASE != 1) || (CONFIG_HT_CHAIN_END_UNITID_BASE != 0x20))
 			#if CONFIG_SB_HT_CHAIN_UNITID_OFFSET_ONLY == 1
-			if((nodeid == 0) && (sblink == link))
+			if((nodeid == 0) && (sblink == link->link_num))
 			#endif
 				offset_unitid = 1;
 		#endif
 
-		max = amdk8_scan_chain(dev, nodeid, link, sblink, max, offset_unitid);
+		max = amdk8_scan_chain(dev, nodeid, link, link->link_num, sblink, max, offset_unitid);
 	}
 	return max;
 }
@@ -375,21 +377,22 @@
 
 static void amdk8_read_resources(device_t dev)
 {
-	unsigned nodeid, link;
+	unsigned nodeid;
+	struct bus *link;
 	nodeid = amdk8_nodeid(dev);
-	for(link = 0; link < dev->links; link++) {
-		if (dev->link[link].children) {
-			amdk8_link_read_bases(dev, nodeid, link);
+	for(link = dev->link_list; link; link = link->next) {
+		if (link->children) {
+			amdk8_link_read_bases(dev, nodeid, link->link_num);
 		}
 	}
-
 	amdk8_create_vga_resource(dev, nodeid);
 }
 
 static void amdk8_set_resource(device_t dev, struct resource *resource, unsigned nodeid)
 {
+	struct bus *link;
 	resource_t rbase, rend;
-	unsigned reg, link;
+	unsigned reg, link_num;
 	char buf[50];
 
 	/* Make certain the resource has actually been set */
@@ -426,7 +429,17 @@
 
 	/* Get the register and link */
 	reg  = resource->index & 0xfc;
-	link = IOINDEX_LINK(resource->index);
+	link_num = IOINDEX_LINK(resource->index);
+
+	for (link = dev->link_list; link; link = link->next)
+		if (link->link_num == link_num)
+			break;
+
+	if (link == NULL) {
+		printk(BIOS_ERR, "%s: can't find link %x for %lx\n", __func__,
+			   link_num, resource->index);
+		return;
+	}
 
 	if (resource->flags & IORESOURCE_IO) {
 		u32 base, limit;
@@ -437,15 +450,15 @@
 		base  |= 3;
 		limit &= 0xfe000fc8;
 		limit |= rend & 0x01fff000;
-		limit |= (link & 3) << 4;
+		limit |= (link_num & 3) << 4;
 		limit |= (nodeid & 7);
 
-		if (dev->link[link].bridge_ctrl & PCI_BRIDGE_CTL_VGA) {
+		if (link->bridge_ctrl & PCI_BRIDGE_CTL_VGA) {
 			printk(BIOS_SPEW, "%s, enabling legacy VGA IO forwarding for %s link 0x%x\n",
-				    __func__, dev_path(dev), link);
+				    __func__, dev_path(dev), link_num);
 			base |= PCI_IO_BASE_VGA_EN;
 		}
-		if (dev->link[link].bridge_ctrl & PCI_BRIDGE_CTL_NO_ISA) {
+		if (link->bridge_ctrl & PCI_BRIDGE_CTL_NO_ISA) {
 			base |= PCI_IO_BASE_NO_ISA;
 		}
 
@@ -461,14 +474,14 @@
 		base  |= 3;
 		limit &= 0x00000048;
 		limit |= (rend >> 8) & 0xffffff00;
-		limit |= (link & 3) << 4;
+		limit |= (link_num & 3) << 4;
 		limit |= (nodeid & 7);
 		f1_write_config32(reg + 0x4, limit);
 		f1_write_config32(reg, base);
 	}
 	resource->flags |= IORESOURCE_STORED;
 	sprintf(buf, " <node %x link %x>",
-		nodeid, link);
+		nodeid, link_num);
 	report_resource_stored(dev, resource, buf);
 }
 
@@ -479,18 +492,18 @@
 static void amdk8_create_vga_resource(device_t dev, unsigned nodeid)
 {
 	struct resource *resource;
-	unsigned link;
+	struct bus *link;
 
 	/* find out which link the VGA card is connected,
 	 * we only deal with the 'first' vga card */
-	for (link = 0; link < dev->links; link++) {
-		if (dev->link[link].bridge_ctrl & PCI_BRIDGE_CTL_VGA) {
+	for (link = dev->link_list; link; link = link->next) {
+		if (link->bridge_ctrl & PCI_BRIDGE_CTL_VGA) {
 #if CONFIG_CONSOLE_VGA_MULTI == 1
-			printk(BIOS_DEBUG, "VGA: vga_pri bus num = %d dev->link[link] bus range [%d,%d]\n", vga_pri->bus->secondary,
-				dev->link[link].secondary,dev->link[link].subordinate);
+			printk(BIOS_DEBUG, "VGA: vga_pri bus num = %d link bus range [%d,%d]\n", vga_pri->bus->secondary,
+				link->secondary,link->subordinate);
 			/* We need to make sure the vga_pri is under the link */
-			if((vga_pri->bus->secondary >= dev->link[link].secondary ) &&
-				(vga_pri->bus->secondary <= dev->link[link].subordinate )
+			if((vga_pri->bus->secondary >= link->secondary ) &&
+				(vga_pri->bus->secondary <= link->subordinate )
 			)
 #endif
 			break;
@@ -498,13 +511,13 @@
 	}
 
 	/* no VGA card installed */
-	if (link == dev->links)
+	if (link == NULL)
 		return;
 
-	printk(BIOS_DEBUG, "VGA: %s (aka node %d) link %d has VGA device\n", dev_path(dev), nodeid, link);
+	printk(BIOS_DEBUG, "VGA: %s (aka node %d) link %d has VGA device\n", dev_path(dev), nodeid, link->link_num);
 
 	/* allocate a temp resource for the legacy VGA buffer */
-	resource = new_resource(dev, IOINDEX(4, link));
+	resource = new_resource(dev, IOINDEX(4, link->link_num));
 	if(!resource){
 		printk(BIOS_DEBUG, "VGA: %s out of resources.\n", dev_path(dev));
 		return;
@@ -518,7 +531,8 @@
 
 static void amdk8_set_resources(device_t dev)
 {
-	unsigned nodeid, link;
+	unsigned nodeid;
+	struct bus *bus;
 	struct resource *res;
 
 	/* Find the nodeid */
@@ -553,9 +567,7 @@
 
 	compact_resources(dev);
 
-	for(link = 0; link < dev->links; link++) {
-		struct bus *bus;
-		bus = &dev->link[link];
+	for(bus = dev->link_list; bus; bus = bus->next) {
 		if (bus->children) {
 			assign_resources(bus);
 		}
@@ -909,7 +921,7 @@
 	}
 #endif
 
-	pci_tolm = find_pci_tolm(&dev->link[0]);
+	pci_tolm = find_pci_tolm(dev->link_list);
 
 	// FIXME handle interleaved nodes. If you fix this here, please fix
 	// amdfam10, too.
@@ -1066,7 +1078,7 @@
 		}
 #endif
 	}
-	assign_resources(&dev->link[0]);
+	assign_resources(dev->link_list);
 
 }
 
@@ -1078,7 +1090,7 @@
 	for(reg = 0xe0; reg <= 0xec; reg += 4) {
 		f1_write_config32(reg, 0);
 	}
-	max = pci_scan_bus(&dev->link[0], PCI_DEVFN(0x18, 0), 0xff, max);
+	max = pci_scan_bus(dev->link_list, PCI_DEVFN(0x18, 0), 0xff, max);
 
 	/* Tune the hypertransport transaction for best performance.
 	 * Including enabling relaxed ordering if it is safe.
@@ -1091,12 +1103,12 @@
 			u32 httc;
 			httc = pci_read_config32(f0_dev, HT_TRANSACTION_CONTROL);
 			httc &= ~HTTC_RSP_PASS_PW;
-			if (!dev->link[0].disable_relaxed_ordering) {
+			if (!dev->link_list->disable_relaxed_ordering) {
 				httc |= HTTC_RSP_PASS_PW;
 			}
 			printk(BIOS_SPEW, "%s passpw: %s\n",
 				dev_path(dev),
-				(!dev->link[0].disable_relaxed_ordering)?
+				(!dev->link_list->disable_relaxed_ordering)?
 				"enabled":"disabled");
 			pci_write_config32(f0_dev, HT_TRANSACTION_CONTROL, httc);
 		}
@@ -1113,6 +1125,42 @@
 	.ops_pci_bus	  = &pci_cf8_conf1,
 };
 
+static void add_more_links(device_t dev, unsigned total_links)
+{
+	struct bus *link, *last = NULL;
+	int link_num;
+
+	for (link = dev->link_list; link; link = link->next)
+		last = link;
+
+	if (last) {
+		int links = total_links - last->link_num;
+		link_num = last->link_num;
+		if (links > 0) {
+			link = malloc(links*sizeof(*link));
+			if (!link)
+				die("Couldn't allocate more links!\n");
+			memset(link, 0, links*sizeof(*link));
+			last->next = link;
+		}
+	}
+	else {
+		link_num = -1;
+		link = malloc(total_links*sizeof(*link));
+		memset(link, 0, total_links*sizeof(*link));
+		dev->link_list = link;
+	}
+
+	for (link_num = link_num + 1; link_num < total_links; link_num++) {
+		link->link_num = link_num;
+		link->dev = dev;
+		link->next = link + 1;
+		last = link;
+		link = link->next;
+	}
+	last->next = NULL;
+}
+
 static u32 cpu_bus_scan(device_t dev, u32 max)
 {
 	struct bus *cpu_bus;
@@ -1165,7 +1213,7 @@
 	}
 
 	/* Find which cpus are present */
-	cpu_bus = &dev->link[0];
+	cpu_bus = dev->link_list;
 	for(i = 0; i < sysconf.nodes; i++) {
 		device_t cpu_dev, cpu;
 		struct device_path cpu_path;
@@ -1187,11 +1235,7 @@
 			 */
 			dev_f0 = dev_find_slot(0, PCI_DEVFN(0x18+i,0));
 			if(dev_f0) {
-				dev_f0->links = 3;
-				for(local_j=0;local_j<3;local_j++) {
-					dev_f0->link[local_j].link = local_j;
-					dev_f0->link[local_j].dev = dev_f0;
-				}
+				add_more_links(dev_f0, 3);
 			}
 		}
 
@@ -1290,7 +1334,7 @@
 
 static void cpu_bus_init(device_t dev)
 {
-	initialize_cpus(&dev->link[0]);
+	initialize_cpus(dev->link_list);
 }
 
 static void cpu_bus_noop(device_t dev)

Modified: trunk/src/northbridge/amd/gx1/northbridge.c
==============================================================================
--- trunk/src/northbridge/amd/gx1/northbridge.c	Thu Jun 10 00:39:00 2010	(r5625)
+++ trunk/src/northbridge/amd/gx1/northbridge.c	Thu Jun 10 00:41:35 2010	(r5626)
@@ -115,8 +115,8 @@
 	device_t mc_dev;
         uint32_t pci_tolm;
 
-        pci_tolm = find_pci_tolm(&dev->link[0]);
-	mc_dev = dev->link[0].children;
+        pci_tolm = find_pci_tolm(dev->link_list);
+	mc_dev = dev->link_list->children;
 	if (mc_dev) {
 		unsigned int tomk, tolmk;
 		unsigned int ramreg = 0;
@@ -163,7 +163,7 @@
 		idx = 10;
 		ram_resource(dev, idx++, 0, tolmk);
 	}
-	assign_resources(&dev->link[0]);
+	assign_resources(dev->link_list);
 }
 
 static struct device_operations pci_domain_ops = {
@@ -177,7 +177,7 @@
 static void cpu_bus_init(device_t dev)
 {
 	printk(BIOS_SPEW, "%s:%s()\n", NORTHBRIDGE_FILE, __func__);
-	initialize_cpus(&dev->link[0]);
+	initialize_cpus(dev->link_list);
 }
 
 static void cpu_bus_noop(device_t dev)

Modified: trunk/src/northbridge/amd/gx2/northbridge.c
==============================================================================
--- trunk/src/northbridge/amd/gx2/northbridge.c	Thu Jun 10 00:39:00 2010	(r5625)
+++ trunk/src/northbridge/amd/gx2/northbridge.c	Thu Jun 10 00:41:35 2010	(r5626)
@@ -303,11 +303,9 @@
                 pci_set_resource(dev, resource);
         }
 #endif
-        unsigned link;
+	struct bus *bus;
 
-        for(link = 0; link < dev->links; link++) {
-                struct bus *bus;
-                bus = &dev->link[link];
+	for(bus = dev->link_list; bus; bus = bus->next) {
                 if (bus->children) {
                         assign_resources(bus);
                 }
@@ -402,8 +400,8 @@
 	device_t mc_dev;
         u32 pci_tolm;
 
-        pci_tolm = find_pci_tolm(&dev->link[0]);
-	mc_dev = dev->link[0].children;
+        pci_tolm = find_pci_tolm(dev->link_list);
+	mc_dev = dev->link_list->children;
 	if (mc_dev) {
 		unsigned int tomk, tolmk;
 		unsigned int ramreg = 0;
@@ -444,7 +442,7 @@
 		ram_resource(dev, idx++, 0, tolmk);
 	}
 #endif
-	assign_resources(&dev->link[0]);
+	assign_resources(dev->link_list);
 }
 
 static struct device_operations pci_domain_ops = {
@@ -457,7 +455,7 @@
 
 static void cpu_bus_init(device_t dev)
 {
-        initialize_cpus(&dev->link[0]);
+        initialize_cpus(dev->link_list);
 }
 
 static void cpu_bus_noop(device_t dev)

Modified: trunk/src/northbridge/amd/lx/northbridge.c
==============================================================================
--- trunk/src/northbridge/amd/lx/northbridge.c	Thu Jun 10 00:39:00 2010	(r5625)
+++ trunk/src/northbridge/amd/lx/northbridge.c	Thu Jun 10 00:41:35 2010	(r5626)
@@ -318,7 +318,6 @@
 
 static void northbridge_set_resources(struct device *dev)
 {
-	unsigned link;
 	uint8_t line;
 
 #if 0
@@ -331,9 +330,8 @@
 	}
 #endif
 
-	for (link = 0; link < dev->links; link++) {
-		struct bus *bus;
-		bus = &dev->link[link];
+	struct bus *bus;
+	for (bus = dev->link_list; bus; bus = bus->next) {
 		if (bus->children) {
 			printk(BIOS_DEBUG, "my_dev_set_resources: assign_resources %d\n",
 			     bus->secondary);
@@ -402,7 +400,7 @@
 
 	printk(BIOS_SPEW, ">> Entering northbridge.c: %s\n", __func__);
 
-	mc_dev = dev->link[0].children;
+	mc_dev = dev->link_list->children;
 	if (mc_dev) {
 		tomk = get_systop() / 1024;
 		/* Report the memory regions
@@ -418,7 +416,7 @@
 #endif
 	}
 
-	assign_resources(&dev->link[0]);
+	assign_resources(dev->link_list);
 }
 
 static void pci_domain_enable(device_t dev)
@@ -452,7 +450,7 @@
 {
 	printk(BIOS_SPEW, ">> Entering northbridge.c: %s\n", __func__);
 
-	initialize_cpus(&dev->link[0]);
+	initialize_cpus(dev->link_list);
 }
 
 static void cpu_bus_noop(device_t dev)

Modified: trunk/src/northbridge/intel/e7501/northbridge.c
==============================================================================
--- trunk/src/northbridge/intel/e7501/northbridge.c	Thu Jun 10 00:39:00 2010	(r5625)
+++ trunk/src/northbridge/intel/e7501/northbridge.c	Thu Jun 10 00:41:35 2010	(r5626)
@@ -58,8 +58,8 @@
 	device_t mc_dev;
         uint32_t pci_tolm;
 
-        pci_tolm = find_pci_tolm(&dev->link[0]);
-	mc_dev = dev->link[0].children;
+        pci_tolm = find_pci_tolm(dev->link_list);
+	mc_dev = dev->link_list->children;
 	if (mc_dev) {
 		/* Figure out which areas are/should be occupied by RAM.
 		 * This is all computed in kilobytes and converted to/from
@@ -135,7 +135,7 @@
 		high_tables_size = HIGH_TABLES_SIZE * 1024;
 #endif
 	}
-	assign_resources(&dev->link[0]);
+	assign_resources(dev->link_list);
 }
 
 static struct device_operations pci_domain_ops = {
@@ -149,7 +149,7 @@
 
 static void cpu_bus_init(device_t dev)
 {
-        initialize_cpus(&dev->link[0]);
+        initialize_cpus(dev->link_list);
 }
 
 static void cpu_bus_noop(device_t dev)

Modified: trunk/src/northbridge/intel/e7520/northbridge.c
==============================================================================
--- trunk/src/northbridge/intel/e7520/northbridge.c	Thu Jun 10 00:39:00 2010	(r5625)
+++ trunk/src/northbridge/intel/e7520/northbridge.c	Thu Jun 10 00:41:35 2010	(r5626)
@@ -62,7 +62,7 @@
 	device_t mc_dev;
 	uint32_t pci_tolm;
 
-        pci_tolm = find_pci_tolm(&dev->link[0]);
+        pci_tolm = find_pci_tolm(dev->link_list);
 
 #if 1
 	printk(BIOS_DEBUG, "PCI mem marker = %x\n", pci_tolm);
@@ -72,7 +72,7 @@
 		pci_tolm = 0xe0000000;
 	/* Ensure pci_tolm is 128M aligned */
 	pci_tolm &= 0xf8000000;
-	mc_dev = dev->link[0].children;
+	mc_dev = dev->link_list->children;
 	if (mc_dev) {
 		/* Figure out which areas are/should be occupied by RAM.
 		 * This is all computed in kilobytes and converted to/from
@@ -151,7 +151,7 @@
 		high_tables_size = HIGH_TABLES_SIZE * 1024;
 #endif
 	}
-	assign_resources(&dev->link[0]);
+	assign_resources(dev->link_list);
 }
 
 static u32 e7520_domain_scan_bus(device_t dev, u32 max)
@@ -219,7 +219,7 @@
 
 static void cpu_bus_init(device_t dev)
 {
-        initialize_cpus(&dev->link[0]);
+        initialize_cpus(dev->link_list);
 }
 
 static void cpu_bus_noop(device_t dev)

Modified: trunk/src/northbridge/intel/e7525/northbridge.c
==============================================================================
--- trunk/src/northbridge/intel/e7525/northbridge.c	Thu Jun 10 00:39:00 2010	(r5625)
+++ trunk/src/northbridge/intel/e7525/northbridge.c	Thu Jun 10 00:41:35 2010	(r5626)
@@ -62,7 +62,7 @@
 	device_t mc_dev;
 	uint32_t pci_tolm;
 
-        pci_tolm = find_pci_tolm(&dev->link[0]);
+        pci_tolm = find_pci_tolm(dev->link_list);
 
 #if 1
 	printk(BIOS_DEBUG, "PCI mem marker = %x\n", pci_tolm);
@@ -72,7 +72,7 @@
 		pci_tolm = 0xe0000000;
 	/* Ensure pci_tolm is 128M aligned */
 	pci_tolm &= 0xf8000000;
-	mc_dev = dev->link[0].children;
+	mc_dev = dev->link_list->children;
 	if (mc_dev) {
 		/* Figure out which areas are/should be occupied by RAM.
 		 * This is all computed in kilobytes and converted to/from
@@ -151,7 +151,7 @@
 		high_tables_size = HIGH_TABLES_SIZE * 1024;
 #endif
 	}
-	assign_resources(&dev->link[0]);
+	assign_resources(dev->link_list);
 }
 
 static u32 e7525_domain_scan_bus(device_t dev, u32 max)
@@ -219,7 +219,7 @@
 
 static void cpu_bus_init(device_t dev)
 {
-        initialize_cpus(&dev->link[0]);
+        initialize_cpus(dev->link_list);
 }
 
 static void cpu_bus_noop(device_t dev)

Modified: trunk/src/northbridge/intel/i3100/northbridge.c
==============================================================================
--- trunk/src/northbridge/intel/i3100/northbridge.c	Thu Jun 10 00:39:00 2010	(r5625)
+++ trunk/src/northbridge/intel/i3100/northbridge.c	Thu Jun 10 00:41:35 2010	(r5626)
@@ -83,7 +83,7 @@
 	device_t mc_dev;
 	u32 pci_tolm;
 
-        pci_tolm = find_pci_tolm(&dev->link[0]);
+        pci_tolm = find_pci_tolm(dev->link_list);
 
 #if 1
 	printk(BIOS_DEBUG, "PCI mem marker = %x\n", pci_tolm);
@@ -93,7 +93,7 @@
 		pci_tolm = 0xe0000000;
 	/* Ensure pci_tolm is 128M aligned */
 	pci_tolm &= 0xf8000000;
-	mc_dev = dev->link[0].children;
+	mc_dev = dev->link_list->children;
 	if (mc_dev) {
 		/* Figure out which areas are/should be occupied by RAM.
 		 * This is all computed in kilobytes and converted to/from
@@ -172,7 +172,7 @@
 		high_tables_size = HIGH_TABLES_SIZE * 1024;
 #endif
 	}
-	assign_resources(&dev->link[0]);
+	assign_resources(dev->link_list);
 }
 
 static u32 i3100_domain_scan_bus(device_t dev, u32 max)
@@ -240,7 +240,7 @@
 
 static void cpu_bus_init(device_t dev)
 {
-        initialize_cpus(&dev->link[0]);
+        initialize_cpus(dev->link_list);
 }
 
 static void cpu_bus_noop(device_t dev)

Modified: trunk/src/northbridge/intel/i3100/pciexp_porta_ep80579.c
==============================================================================
--- trunk/src/northbridge/intel/i3100/pciexp_porta_ep80579.c	Thu Jun 10 00:39:00 2010	(r5625)
+++ trunk/src/northbridge/intel/i3100/pciexp_porta_ep80579.c	Thu Jun 10 00:41:35 2010	(r5626)
@@ -56,7 +56,7 @@
 
 static void pcie_bus_enable_resources(struct device *dev)
 {
-	if (dev->link[0].bridge_ctrl & PCI_BRIDGE_CTL_VGA) {
+	if (dev->link_list->bridge_ctrl & PCI_BRIDGE_CTL_VGA) {
 		printk(BIOS_SPEW, "Enable VGA IO/MEM forwarding on PCIe port\n");
 		pci_write_config8(dev, PCI_BRIDGE_CONTROL, 8);
 

Modified: trunk/src/northbridge/intel/i440bx/northbridge.c
==============================================================================
--- trunk/src/northbridge/intel/i440bx/northbridge.c	Thu Jun 10 00:39:00 2010	(r5625)
+++ trunk/src/northbridge/intel/i440bx/northbridge.c	Thu Jun 10 00:41:35 2010	(r5626)
@@ -82,8 +82,8 @@
 	device_t mc_dev;
 	uint32_t pci_tolm;
 
-	pci_tolm = find_pci_tolm(&dev->link[0]);
-	mc_dev = dev->link[0].children;
+	pci_tolm = find_pci_tolm(dev->link_list);
+	mc_dev = dev->link_list->children;
 	if (mc_dev) {
 		unsigned long tomk, tolmk;
 		int idx;
@@ -118,7 +118,7 @@
 		high_tables_size = HIGH_TABLES_SIZE * 1024;
 #endif
 	}
-	assign_resources(&dev->link[0]);
+	assign_resources(dev->link_list);
 }
 
 static struct device_operations pci_domain_ops = {
@@ -131,7 +131,7 @@
 
 static void cpu_bus_init(device_t dev)
 {
-	initialize_cpus(&dev->link[0]);
+	initialize_cpus(dev->link_list);
 }
 
 static void cpu_bus_noop(device_t dev)

Modified: trunk/src/northbridge/intel/i440lx/northbridge.c
==============================================================================
--- trunk/src/northbridge/intel/i440lx/northbridge.c	Thu Jun 10 00:39:00 2010	(r5625)
+++ trunk/src/northbridge/intel/i440lx/northbridge.c	Thu Jun 10 00:41:35 2010	(r5626)
@@ -110,8 +110,8 @@
 	device_t mc_dev;
 	uint32_t pci_tolm;
 
-	pci_tolm = find_pci_tolm(&dev->link[0]);
-	mc_dev = dev->link[0].children;
+	pci_tolm = find_pci_tolm(dev->link_list);
+	mc_dev = dev->link_list->children;
 	if (mc_dev) {
 		unsigned long tomk, tolmk;
 		int idx;
@@ -146,7 +146,7 @@
 		high_tables_size = HIGH_TABLES_SIZE * 1024;
 #endif
 	}
-	assign_resources(&dev->link[0]);
+	assign_resources(dev->link_list);
 }
 
 static struct device_operations pci_domain_ops = {
@@ -159,7 +159,7 @@
 
 static void cpu_bus_init(device_t dev)
 {
-	initialize_cpus(&dev->link[0]);
+	initialize_cpus(dev->link_list);
 }
 
 static void cpu_bus_noop(device_t dev)

Modified: trunk/src/northbridge/intel/i82810/northbridge.c
==============================================================================
--- trunk/src/northbridge/intel/i82810/northbridge.c	Thu Jun 10 00:39:00 2010	(r5625)
+++ trunk/src/northbridge/intel/i82810/northbridge.c	Thu Jun 10 00:41:35 2010	(r5626)
@@ -119,8 +119,8 @@
 	device_t mc_dev;
 	uint32_t pci_tolm;
 
-	pci_tolm = find_pci_tolm(&dev->link[0]);
-	mc_dev = dev->link[0].children;
+	pci_tolm = find_pci_tolm(dev->link_list);
+	mc_dev = dev->link_list->children;
 
 	if (mc_dev) {
 		/* Figure out which areas are/should be occupied by RAM.
@@ -178,7 +178,7 @@
 		high_tables_size = HIGH_TABLES_SIZE * 1024;
 #endif
 	}
-	assign_resources(&dev->link[0]);
+	assign_resources(dev->link_list);
 }
 
 static struct device_operations pci_domain_ops = {
@@ -191,7 +191,7 @@
 
 static void cpu_bus_init(device_t dev)
 {
-	initialize_cpus(&dev->link[0]);
+	initialize_cpus(dev->link_list);
 }
 
 static void cpu_bus_noop(device_t dev)

Modified: trunk/src/northbridge/intel/i82830/northbridge.c
==============================================================================
--- trunk/src/northbridge/intel/i82830/northbridge.c	Thu Jun 10 00:39:00 2010	(r5625)
+++ trunk/src/northbridge/intel/i82830/northbridge.c	Thu Jun 10 00:41:35 2010	(r5626)
@@ -111,8 +111,8 @@
 	uint32_t pci_tolm;
 	int igd_memory = 0;
 
-	pci_tolm = find_pci_tolm(&dev->link[0]);
-	mc_dev = dev->link[0].children;
+	pci_tolm = find_pci_tolm(dev->link_list);
+	mc_dev = dev->link_list->children;
 	if (!mc_dev)
 		return;
 
@@ -152,7 +152,7 @@
 	ram_resource(dev, idx++, 768, 256);
 	ram_resource(dev, idx++, 1024, tolmk - 1024);
 
-	assign_resources(&dev->link[0]);
+	assign_resources(dev->link_list);
 
 #if CONFIG_WRITE_HIGH_TABLES==1
 	/* Leave some space for ACPI, PIRQ and MP tables */
@@ -171,7 +171,7 @@
 
 static void cpu_bus_init(device_t dev)
 {
-	initialize_cpus(&dev->link[0]);
+	initialize_cpus(dev->link_list);
 }
 
 static void cpu_bus_noop(device_t dev)

Modified: trunk/src/northbridge/intel/i855/northbridge.c
==============================================================================
--- trunk/src/northbridge/intel/i855/northbridge.c	Thu Jun 10 00:39:00 2010	(r5625)
+++ trunk/src/northbridge/intel/i855/northbridge.c	Thu Jun 10 00:41:35 2010	(r5626)
@@ -83,8 +83,8 @@
         printk(BIOS_DEBUG, "Entered with dev vid = %x\n", dev->vendor);
 	printk(BIOS_DEBUG, "Entered with dev did = %x\n", dev->device);
 
-        pci_tolm = find_pci_tolm(&dev->link[0]);
-	mc_dev = dev->link[0].children->sibling;
+        pci_tolm = find_pci_tolm(dev->link_list);
+	mc_dev = dev->link_list->children->sibling;
 	printk(BIOS_DEBUG, "MC dev vendor = %x\n", mc_dev->vendor);
 	printk(BIOS_DEBUG, "MC dev device = %x\n", mc_dev->device);
 
@@ -134,7 +134,7 @@
 		high_tables_size = HIGH_TABLES_SIZE * 1024;
 #endif
 	}
-	assign_resources(&dev->link[0]);
+	assign_resources(dev->link_list);
 }
 
 static struct device_operations pci_domain_ops = {
@@ -147,7 +147,7 @@
 
 static void cpu_bus_init(device_t dev)
 {
-        initialize_cpus(&dev->link[0]);
+        initialize_cpus(dev->link_list);
 }
 
 static void cpu_bus_noop(device_t dev)

Modified: trunk/src/northbridge/intel/i945/northbridge.c
==============================================================================
--- trunk/src/northbridge/intel/i945/northbridge.c	Thu Jun 10 00:39:00 2010	(r5625)
+++ trunk/src/northbridge/intel/i945/northbridge.c	Thu Jun 10 00:41:35 2010	(r5626)
@@ -138,7 +138,7 @@
 	/* Can we find out how much memory we can use at most
 	 * this way?
 	 */
-	pci_tolm = find_pci_tolm(&dev->link[0]);
+	pci_tolm = find_pci_tolm(dev->link_list);
 	printk(BIOS_DEBUG, "pci_tolm: 0x%x\n", pci_tolm);
 
 	printk(BIOS_SPEW, "Base of stolen memory: 0x%08x\n",
@@ -208,7 +208,7 @@
 		ram_resource(dev, 5, 4096 * 1024, tomk - 4 * 1024 * 1024);
 	}
 
-	assign_resources(&dev->link[0]);
+	assign_resources(dev->link_list);
 
 #if CONFIG_WRITE_HIGH_TABLES==1
 	/* Leave some space for ACPI, PIRQ and MP tables */
@@ -326,7 +326,7 @@
 
 static void cpu_bus_init(device_t dev)
 {
-	initialize_cpus(&dev->link[0]);
+	initialize_cpus(dev->link_list);
 }
 
 static void cpu_bus_noop(device_t dev)

Modified: trunk/src/northbridge/via/cn400/northbridge.c
==============================================================================
--- trunk/src/northbridge/via/cn400/northbridge.c	Thu Jun 10 00:39:00 2010	(r5625)
+++ trunk/src/northbridge/via/cn400/northbridge.c	Thu Jun 10 00:41:35 2010	(r5626)
@@ -233,7 +233,7 @@
 
 	printk(BIOS_SPEW, "Entering %s.\n", __func__);
 
-	pci_tolm = find_pci_tolm(&dev->link[0]);
+	pci_tolm = find_pci_tolm(dev->link_list);
 	mc_dev = dev_find_device(PCI_VENDOR_ID_VIA,
 				 PCI_DEVICE_ID_VIA_CN400_MEMCTRL, 0);
 
@@ -267,7 +267,7 @@
 		ram_resource(dev, idx++, 768,
 			     (tolmk - 768 - CONFIG_VIDEO_MB * 1024));
 	}
-	assign_resources(&dev->link[0]);
+	assign_resources(dev->link_list);
 
 	printk(BIOS_SPEW, "Leaving %s.\n", __func__);
 }
@@ -276,7 +276,7 @@
 {
 	printk(BIOS_DEBUG, "Entering %s.\n", __func__);
 
-	max = pci_scan_bus(&dev->link[0], PCI_DEVFN(0, 0), 0xff, max);
+	max = pci_scan_bus(dev->link_list, PCI_DEVFN(0, 0), 0xff, max);
 	return max;
 }
 
@@ -290,7 +290,7 @@
 
 static void cpu_bus_init(device_t dev)
 {
-	initialize_cpus(&dev->link[0]);
+	initialize_cpus(dev->link_list);
 }
 
 static void cpu_bus_noop(device_t dev)

Modified: trunk/src/northbridge/via/cn700/northbridge.c
==============================================================================
--- trunk/src/northbridge/via/cn700/northbridge.c	Thu Jun 10 00:39:00 2010	(r5625)
+++ trunk/src/northbridge/via/cn700/northbridge.c	Thu Jun 10 00:41:35 2010	(r5626)
@@ -157,7 +157,7 @@
 
 	printk(BIOS_SPEW, "Entering cn700 pci_domain_set_resources.\n");
 
-	pci_tolm = find_pci_tolm(&dev->link[0]);
+	pci_tolm = find_pci_tolm(dev->link_list);
 	mc_dev = dev_find_device(PCI_VENDOR_ID_VIA,
 				 PCI_DEVICE_ID_VIA_CN700_MEMCTRL, 0);
 
@@ -199,7 +199,7 @@
 		ram_resource(dev, idx++, 768,
 			     (tolmk - 768 - CONFIG_VIDEO_MB * 1024));
 	}
-	assign_resources(&dev->link[0]);
+	assign_resources(dev->link_list);
 }
 
 static struct device_operations pci_domain_ops = {
@@ -212,7 +212,7 @@
 
 static void cpu_bus_init(device_t dev)
 {
-	initialize_cpus(&dev->link[0]);
+	initialize_cpus(dev->link_list);
 }
 
 static void cpu_bus_noop(device_t dev)

Modified: trunk/src/northbridge/via/cx700/northbridge.c
==============================================================================
--- trunk/src/northbridge/via/cx700/northbridge.c	Thu Jun 10 00:39:00 2010	(r5625)
+++ trunk/src/northbridge/via/cx700/northbridge.c	Thu Jun 10 00:41:35 2010	(r5626)
@@ -87,7 +87,7 @@
 	unsigned char rambits;
 	int idx;
 
-	pci_tolm = find_pci_tolm(&dev->link[0]);
+	pci_tolm = find_pci_tolm(dev->link_list);
 	mc_dev = dev_find_device(PCI_VENDOR_ID_VIA, 0x3324, 0);
 
 	rambits = pci_read_config8(mc_dev, 0x88);
@@ -128,7 +128,7 @@
 	/* TODO: Hole needed? Should this go elsewhere? */
 	ram_resource(dev, idx++, 0, 640);	/* first 640k */
 	ram_resource(dev, idx++, 768, (tolmk - 768));	/* leave a hole for vga */
-	assign_resources(&dev->link[0]);
+	assign_resources(dev->link_list);
 }
 
 static struct device_operations pci_domain_ops = {
@@ -141,7 +141,7 @@
 
 static void cpu_bus_init(device_t dev)
 {
-	initialize_cpus(&dev->link[0]);
+	initialize_cpus(dev->link_list);
 }
 
 static void cpu_bus_noop(device_t dev)

Modified: trunk/src/northbridge/via/vt8601/northbridge.c
==============================================================================
--- trunk/src/northbridge/via/vt8601/northbridge.c	Thu Jun 10 00:39:00 2010	(r5625)
+++ trunk/src/northbridge/via/vt8601/northbridge.c	Thu Jun 10 00:41:35 2010	(r5626)
@@ -98,8 +98,8 @@
 	device_t mc_dev;
         uint32_t pci_tolm;
 
-        pci_tolm = find_pci_tolm(&dev->link[0]);
-	mc_dev = dev->link[0].children;
+        pci_tolm = find_pci_tolm(dev->link_list);
+	mc_dev = dev->link_list->children;
 	if (mc_dev) {
 		unsigned long tomk, tolmk;
 		unsigned char rambits;
@@ -140,7 +140,7 @@
 		idx = 10;
 		ram_resource(dev, idx++, 0, tolmk);
 	}
-	assign_resources(&dev->link[0]);
+	assign_resources(dev->link_list);
 }
 
 static struct device_operations pci_domain_ops = {
@@ -153,7 +153,7 @@
 
 static void cpu_bus_init(device_t dev)
 {
-        initialize_cpus(&dev->link[0]);
+        initialize_cpus(dev->link_list);
 }
 
 static void cpu_bus_noop(device_t dev)

Modified: trunk/src/northbridge/via/vt8623/northbridge.c
==============================================================================
--- trunk/src/northbridge/via/vt8623/northbridge.c	Thu Jun 10 00:39:00 2010	(r5625)
+++ trunk/src/northbridge/via/vt8623/northbridge.c	Thu Jun 10 00:41:35 2010	(r5626)
@@ -158,8 +158,8 @@
 
 	printk(BIOS_SPEW, "Entering vt8623 pci_domain_set_resources.\n");
 
-        pci_tolm = find_pci_tolm(&dev->link[0]);
-	mc_dev = dev->link[0].children;
+        pci_tolm = find_pci_tolm(dev->link_list);
+	mc_dev = dev->link_list->children;
 	if (mc_dev) {
 		unsigned long tomk, tolmk;
 		unsigned char rambits;
@@ -201,7 +201,7 @@
 		ram_resource(dev, idx++, 0, 640);		/* first 640k */
 		ram_resource(dev, idx++, 768, tolmk - 768);	/* leave a hole for vga */
 	}
-	assign_resources(&dev->link[0]);
+	assign_resources(dev->link_list);
 }
 
 static struct device_operations pci_domain_ops = {
@@ -214,7 +214,7 @@
 
 static void cpu_bus_init(device_t dev)
 {
-        initialize_cpus(&dev->link[0]);
+        initialize_cpus(dev->link_list);
 }
 
 static void cpu_bus_noop(device_t dev)

Modified: trunk/src/northbridge/via/vx800/northbridge.c
==============================================================================
--- trunk/src/northbridge/via/vx800/northbridge.c	Thu Jun 10 00:39:00 2010	(r5625)
+++ trunk/src/northbridge/via/vx800/northbridge.c	Thu Jun 10 00:41:35 2010	(r5626)
@@ -128,7 +128,7 @@
 
 	printk(BIOS_SPEW, "Entering vx800 pci_domain_set_resources.\n");
 
-	pci_tolm = find_pci_tolm(&dev->link[0]);
+	pci_tolm = find_pci_tolm(dev->link_list);
 	mc_dev = dev_find_device(PCI_VENDOR_ID_VIA,
 				 PCI_DEVICE_ID_VIA_VX855_MEMCTRL, 0);
 
@@ -175,7 +175,7 @@
 		/* Leave a hole for vga, 0xa0000 - 0xc0000 */
 		ram_resource(dev, idx++, 768, (tolmk - 768));
 	}
-	assign_resources(&dev->link[0]);
+	assign_resources(dev->link_list);
 }
 
 static struct device_operations pci_domain_ops = {
@@ -188,7 +188,7 @@
 
 static void cpu_bus_init(device_t dev)
 {
-	initialize_cpus(&dev->link[0]);
+	initialize_cpus(dev->link_list);
 }
 
 static void cpu_bus_noop(device_t dev)

Modified: trunk/src/southbridge/amd/amd8131/amd8131_bridge.c
==============================================================================
--- trunk/src/southbridge/amd/amd8131/amd8131_bridge.c	Thu Jun 10 00:39:00 2010	(r5625)
+++ trunk/src/southbridge/amd/amd8131/amd8131_bridge.c	Thu Jun 10 00:41:35 2010	(r5626)
@@ -25,7 +25,7 @@
 			continue;
 		}
 		if (child->hdr_type == PCI_HEADER_TYPE_BRIDGE) {
-			amd8131_walk_children(&child->link[0], visit, ptr);
+			amd8131_walk_children(child->link_list, visit, ptr);
 		}
 		visit(child, ptr);
 	}

Modified: trunk/src/southbridge/amd/amd8132/amd8132_bridge.c
==============================================================================
--- trunk/src/southbridge/amd/amd8132/amd8132_bridge.c	Thu Jun 10 00:39:00 2010	(r5625)
+++ trunk/src/southbridge/amd/amd8132/amd8132_bridge.c	Thu Jun 10 00:41:35 2010	(r5626)
@@ -47,7 +47,7 @@
 			continue;
 		}
 		if (child->hdr_type == PCI_HEADER_TYPE_BRIDGE) {
-			amd8132_walk_children(&child->link[0], visit, ptr);
+			amd8132_walk_children(child->link_list, visit, ptr);
 		}
 		visit(child, ptr);
 	}

Modified: trunk/src/southbridge/amd/sb600/sb600_lpc.c
==============================================================================
--- trunk/src/southbridge/amd/sb600/sb600_lpc.c	Thu Jun 10 00:39:00 2010	(r5625)
+++ trunk/src/southbridge/amd/sb600/sb600_lpc.c	Thu Jun 10 00:41:35 2010	(r5626)
@@ -106,7 +106,7 @@
  */
 static void sb600_lpc_enable_childrens_resources(device_t dev)
 {
-	u32 link;
+	struct bus *link;
 	u32 reg, reg_x;
 	int var_num = 0;
 	u16 reg_var[3];
@@ -114,9 +114,9 @@
 	reg = pci_read_config32(dev, 0x44);
 	reg_x = pci_read_config32(dev, 0x48);
 
-	for (link = 0; link < dev->links; link++) {
+	for (link = dev->link_list; link; link = link->next) {
 		device_t child;
-		for (child = dev->link[link].children; child;
+		for (child = link->children; child;
 		     child = child->sibling) {
 			enable_resources(child);
 			if (child->enabled

Modified: trunk/src/southbridge/amd/sb700/sb700_lpc.c
==============================================================================
--- trunk/src/southbridge/amd/sb700/sb700_lpc.c	Thu Jun 10 00:39:00 2010	(r5625)
+++ trunk/src/southbridge/amd/sb700/sb700_lpc.c	Thu Jun 10 00:41:35 2010	(r5626)
@@ -118,7 +118,7 @@
  */
 static void sb700_lpc_enable_childrens_resources(device_t dev)
 {
-	u32 link;
+	struct bus *link;
 	u32 reg, reg_x;
 	int var_num = 0;
 	u16 reg_var[3];
@@ -126,9 +126,9 @@
 	reg = pci_read_config32(dev, 0x44);
 	reg_x = pci_read_config32(dev, 0x48);
 
-	for (link = 0; link < dev->links; link++) {
+	for (link = dev->link_list; link; link = link->next) {
 		device_t child;
-		for (child = dev->link[link].children; child;
+		for (child = link->children; child;
 		     child = child->sibling) {
 			enable_resources(child);
 			if (child->enabled

Modified: trunk/src/southbridge/broadcom/bcm5785/bcm5785_lpc.c
==============================================================================
--- trunk/src/southbridge/broadcom/bcm5785/bcm5785_lpc.c	Thu Jun 10 00:39:00 2010	(r5625)
+++ trunk/src/southbridge/broadcom/bcm5785/bcm5785_lpc.c	Thu Jun 10 00:41:35 2010	(r5626)
@@ -67,14 +67,14 @@
  */
 static void bcm5785_lpc_enable_childrens_resources(device_t dev)
 {
-        unsigned link;
+	struct bus *link;
 	uint32_t reg;
 
 	reg = pci_read_config8(dev, 0x44);
 
-        for (link = 0; link < dev->links; link++) {
+	for (link = dev->link_list; link; link = link->next) {
                 device_t child;
-                for (child = dev->link[link].children; child; child = child->sibling) {
+                for (child = link->children; child; child = child->sibling) {
                         enable_resources(child);
 			if(child->enabled && (child->path.type == DEVICE_PATH_PNP)) {
 				struct resource *res;

Modified: trunk/src/southbridge/intel/i82801gx/i82801gx_pci.c
==============================================================================
--- trunk/src/southbridge/intel/i82801gx/i82801gx_pci.c	Thu Jun 10 00:39:00 2010	(r5625)
+++ trunk/src/southbridge/intel/i82801gx/i82801gx_pci.c	Thu Jun 10 00:41:35 2010	(r5626)
@@ -100,10 +100,10 @@
 	/* enable IO in command register if there is VGA card
 	 * connected with (even it does not claim IO resource)
 	 */
-	if (dev->link[0].bridge_ctrl & PCI_BRIDGE_CTL_VGA)
+	if (dev->link_list->bridge_ctrl & PCI_BRIDGE_CTL_VGA)
 		dev->command |= PCI_COMMAND_IO;
 	ctrl = pci_read_config16(dev, PCI_BRIDGE_CONTROL);
-	ctrl |= dev->link[0].bridge_ctrl;
+	ctrl |= dev->link_list->bridge_ctrl;
 	ctrl |= (PCI_BRIDGE_CTL_PARITY + PCI_BRIDGE_CTL_SERR); /* error check */
 	printk(BIOS_DEBUG, "%s bridge ctrl <- %04x\n", dev_path(dev), ctrl);
 	pci_write_config16(dev, PCI_BRIDGE_CONTROL, ctrl);

Modified: trunk/src/southbridge/intel/pxhd/pxhd_bridge.c
==============================================================================
--- trunk/src/southbridge/intel/pxhd/pxhd_bridge.c	Thu Jun 10 00:39:00 2010	(r5625)
+++ trunk/src/southbridge/intel/pxhd/pxhd_bridge.c	Thu Jun 10 00:41:35 2010	(r5626)
@@ -41,8 +41,7 @@
 {
 	int bus_100Mhz = 0;
 
-	dev->link[0].dev = dev;
-	dev->links = 1;
+	dev->link_list->dev = dev;
 
 	get_option(&bus_100Mhz, "pxhd_bus_speed_100");
 	if(bus_100Mhz) {
@@ -58,7 +57,7 @@
 		pci_write_config16(dev, 0x40, word);
 
 		/* reset the bus to make the new frequencies effective */
-		pci_bus_reset(&dev->link[0]);
+		pci_bus_reset(dev->link_list);
 	}
 	return pcix_scan_bridge(dev, max);
 }

Modified: trunk/src/southbridge/nvidia/ck804/ck804_lpc.c
==============================================================================
--- trunk/src/southbridge/nvidia/ck804/ck804_lpc.c	Thu Jun 10 00:39:00 2010	(r5625)
+++ trunk/src/southbridge/nvidia/ck804/ck804_lpc.c	Thu Jun 10 00:41:35 2010	(r5626)
@@ -231,15 +231,15 @@
  */
 static void ck804_lpc_enable_childrens_resources(device_t dev)
 {
-	unsigned link;
+	struct bus *link;
 	uint32_t reg, reg_var[4];
 	int i, var_num = 0;
 
 	reg = pci_read_config32(dev, 0xa0);
 
-	for (link = 0; link < dev->links; link++) {
+	for (link = dev->link_list; link; link = link->next) {
 		device_t child;
-		for (child = dev->link[link].children; child; child = child->sibling) {
+		for (child = link->children; child; child = child->sibling) {
 			enable_resources(child);
 			if (child->enabled && (child->path.type == DEVICE_PATH_PNP)) {
 				struct resource *res;

Modified: trunk/src/southbridge/nvidia/ck804/ck804_smbus.c
==============================================================================
--- trunk/src/southbridge/nvidia/ck804/ck804_smbus.c	Thu Jun 10 00:39:00 2010	(r5625)
+++ trunk/src/southbridge/nvidia/ck804/ck804_smbus.c	Thu Jun 10 00:41:35 2010	(r5626)
@@ -23,7 +23,7 @@
 	device = dev->path.i2c.device;
 	pbus = get_pbus_smbus(dev);
 
-	res = find_resource(pbus->dev, 0x20 + (pbus->link * 4));
+	res = find_resource(pbus->dev, 0x20 + (pbus->link_num * 4));
 
 	return do_smbus_recv_byte(res->base, device);
 }
@@ -37,7 +37,7 @@
 	device = dev->path.i2c.device;
 	pbus = get_pbus_smbus(dev);
 
-	res = find_resource(pbus->dev, 0x20 + (pbus->link * 4));
+	res = find_resource(pbus->dev, 0x20 + (pbus->link_num * 4));
 
 	return do_smbus_send_byte(res->base, device, val);
 }
@@ -51,7 +51,7 @@
 	device = dev->path.i2c.device;
 	pbus = get_pbus_smbus(dev);
 
-	res = find_resource(pbus->dev, 0x20 + (pbus->link * 4));
+	res = find_resource(pbus->dev, 0x20 + (pbus->link_num * 4));
 
 	return do_smbus_read_byte(res->base, device, address);
 }
@@ -65,7 +65,7 @@
 	device = dev->path.i2c.device;
 	pbus = get_pbus_smbus(dev);
 
-	res = find_resource(pbus->dev, 0x20 + (pbus->link * 4));
+	res = find_resource(pbus->dev, 0x20 + (pbus->link_num * 4));
 
 	return do_smbus_write_byte(res->base, device, address, val);
 }

Modified: trunk/src/southbridge/nvidia/mcp55/mcp55_lpc.c
==============================================================================
--- trunk/src/southbridge/nvidia/mcp55/mcp55_lpc.c	Thu Jun 10 00:39:00 2010	(r5625)
+++ trunk/src/southbridge/nvidia/mcp55/mcp55_lpc.c	Thu Jun 10 00:41:35 2010	(r5626)
@@ -205,16 +205,16 @@
  */
 static void mcp55_lpc_enable_childrens_resources(device_t dev)
 {
-	unsigned link;
 	uint32_t reg, reg_var[4];
 	int i;
 	int var_num = 0;
+	struct bus *link;
 
 	reg = pci_read_config32(dev, 0xa0);
 
-	for (link = 0; link < dev->links; link++) {
+	for (link = dev->link_list; link; link = link->next) {
 		device_t child;
-		for (child = dev->link[link].children; child; child = child->sibling) {
+		for (child = link->children; child; child = child->sibling) {
 			enable_resources(child);
 			if(child->enabled && (child->path.type == DEVICE_PATH_PNP)) {
 				struct resource *res;

Modified: trunk/src/southbridge/nvidia/mcp55/mcp55_smbus.c
==============================================================================
--- trunk/src/southbridge/nvidia/mcp55/mcp55_smbus.c	Thu Jun 10 00:39:00 2010	(r5625)
+++ trunk/src/southbridge/nvidia/mcp55/mcp55_smbus.c	Thu Jun 10 00:41:35 2010	(r5626)
@@ -41,7 +41,7 @@
 	device = dev->path.i2c.device;
 	pbus = get_pbus_smbus(dev);
 
-	res = find_resource(pbus->dev, 0x20 + (pbus->link * 4));
+	res = find_resource(pbus->dev, 0x20 + (pbus->link_num * 4));
 
 	return do_smbus_recv_byte(res->base, device);
 }
@@ -55,7 +55,7 @@
 	device = dev->path.i2c.device;
 	pbus = get_pbus_smbus(dev);
 
-	res = find_resource(pbus->dev, 0x20 + (pbus->link * 4));
+	res = find_resource(pbus->dev, 0x20 + (pbus->link_num * 4));
 
 	return do_smbus_send_byte(res->base, device, val);
 }
@@ -69,7 +69,7 @@
 	device = dev->path.i2c.device;
 	pbus = get_pbus_smbus(dev);
 
-	res = find_resource(pbus->dev, 0x20 + (pbus->link * 4));
+	res = find_resource(pbus->dev, 0x20 + (pbus->link_num * 4));
 
 	return do_smbus_read_byte(res->base, device, address);
 }
@@ -83,7 +83,7 @@
 	device = dev->path.i2c.device;
 	pbus = get_pbus_smbus(dev);
 
-	res = find_resource(pbus->dev, 0x20 + (pbus->link * 4));
+	res = find_resource(pbus->dev, 0x20 + (pbus->link_num * 4));
 
 	return do_smbus_write_byte(res->base, device, address, val);
 }

Modified: trunk/src/southbridge/sis/sis966/sis966_lpc.c
==============================================================================
--- trunk/src/southbridge/sis/sis966/sis966_lpc.c	Thu Jun 10 00:39:00 2010	(r5625)
+++ trunk/src/southbridge/sis/sis966/sis966_lpc.c	Thu Jun 10 00:41:35 2010	(r5626)
@@ -198,16 +198,16 @@
  */
 static void sis966_lpc_enable_childrens_resources(device_t dev)
 {
-	unsigned link;
+	struct bus *link;
 	uint32_t reg, reg_var[4];
 	int i;
 	int var_num = 0;
 
 	reg = pci_read_config32(dev, 0xa0);
 
-	for (link = 0; link < dev->links; link++) {
+	for (link = dev->link_list; link; link = link->next) {
 		device_t child;
-		for (child = dev->link[link].children; child; child = child->sibling) {
+		for (child = link->children; child; child = child->sibling) {
 			enable_resources(child);
 			if(child->enabled && (child->path.type == DEVICE_PATH_PNP)) {
 				struct resource *res;

Modified: trunk/util/sconfig/main.c
==============================================================================
--- trunk/util/sconfig/main.c	Thu Jun 10 00:39:00 2010	(r5625)
+++ trunk/util/sconfig/main.c	Thu Jun 10 00:41:35 2010	(r5626)
@@ -278,10 +278,14 @@
 }
 
 static void pass0(FILE *fil, struct device *ptr) {
+	if (ptr->type == device && ptr->id == 0)
+		fprintf(fil, "struct bus %s_links[];\n", ptr->name);
 	if ((ptr->type == device) && (ptr->id != 0) && (!ptr->used)) {
 		fprintf(fil, "struct device %s;\n", ptr->name);
 		if (ptr->rescnt > 0)
 			fprintf(fil, "struct resource %s_res[];\n", ptr->name);
+		if (ptr->children || ptr->multidev)
+			fprintf(fil, "struct bus %s_links[];\n", ptr->name);
 	}
 	if ((ptr->type == device) && (ptr->id != 0) && ptr->used)
 		fprintf(fil, "struct device %s;\n", ptr->aliased_name);
@@ -291,7 +295,7 @@
 	if (!ptr->used && (ptr->type == device)) {
 		fprintf(fil, "struct device %s = {\n", ptr->name);
 		fprintf(fil, "\t.ops = %s,\n", (ptr->ops)?(ptr->ops):"0");
-		fprintf(fil, "\t.bus = &%s.link[%d],\n", ptr->bus->name, ptr->bus->link);
+		fprintf(fil, "\t.bus = &%s_links[%d],\n", ptr->bus->name, ptr->bus->link);
 		fprintf(fil, "\t.path = {");
 		fprintf(fil, ptr->path, ptr->path_a, ptr->path_b);
 		fprintf(fil, "},\n");
@@ -301,33 +305,10 @@
 			fprintf(fil, "\t.resource_list = &%s_res[0],\n", ptr->name);
 		}
 		int link = 0;
-		fprintf(fil, "\t.link = {\n");
-		if (ptr->multidev) {
-			struct device *d = ptr;
-			while (d) {
-				if (device_match(d, ptr)) {
-					fprintf(fil, "\t\t[%d] = {\n", d->link);
-					fprintf(fil, "\t\t\t.link = %d,\n", d->link);
-					fprintf(fil, "\t\t\t.dev = &%s,\n", d->name);
-					if (d->children)
-						fprintf(fil, "\t\t\t.children = &%s,\n", d->children->name);
-					fprintf(fil, "\t\t},\n");
-					link++;
-				}
-				d = d->next_sibling;
-			}
-		} else {
-			if (ptr->children) {
-				fprintf(fil, "\t\t[0] = {\n");
-				fprintf(fil, "\t\t\t.link = 0,\n");
-				fprintf(fil, "\t\t\t.dev = &%s,\n", ptr->name);
-				fprintf(fil, "\t\t\t.children = &%s,\n", ptr->children->name);
-				fprintf(fil, "\t\t},\n");
-				link++;
-			}
-		}
-		fprintf(fil, "\t},\n");
-		fprintf(fil, "\t.links = %d,\n", link);
+		if (ptr->children || ptr->multidev)
+			fprintf(fil, "\t.link_list = &%s_links[0],\n", ptr->name);
+		else
+			fprintf(fil, "\t.link_list = NULL,\n", ptr->name);
 		if (ptr->sibling)
 			fprintf(fil, "\t.sibling = &%s,\n", ptr->sibling->name);
 		if (ptr->chip->chiph_exists) {
@@ -356,6 +337,37 @@
 		}
 		fprintf(fil, "\t };\n");
 	}
+	if (!ptr->used && ptr->type == device && (ptr->children || ptr->multidev)) {
+		fprintf(fil, "struct bus %s_links[] = {\n", ptr->name);
+		if (ptr->multidev) {
+			struct device *d = ptr;
+			while (d) {
+				if (device_match(d, ptr)) {
+					fprintf(fil, "\t\t[%d] = {\n", d->link);
+					fprintf(fil, "\t\t\t.link_num = %d,\n", d->link);
+					fprintf(fil, "\t\t\t.dev = &%s,\n", d->name);
+					if (d->children)
+						fprintf(fil, "\t\t\t.children = &%s,\n", d->children->name);
+					if (device_match(d->next_sibling, ptr))
+						fprintf(fil, "\t\t\t.next=&%s_links[%d],\n", d->name, d->link+1);
+					else
+						fprintf(fil, "\t\t\t.next = NULL,\n");
+					fprintf(fil, "\t\t},\n");
+				}
+				d = d->next_sibling;
+			}
+		} else {
+			if (ptr->children) {
+				fprintf(fil, "\t\t[0] = {\n");
+				fprintf(fil, "\t\t\t.link_num = 0,\n");
+				fprintf(fil, "\t\t\t.dev = &%s,\n", ptr->name);
+				fprintf(fil, "\t\t\t.children = &%s,\n", ptr->children->name);
+				fprintf(fil, "\t\t\t.next = NULL,\n");
+				fprintf(fil, "\t\t},\n");
+			}
+		}
+		fprintf(fil, "\t};\n");
+	}
 	if ((ptr->type == chip) && (ptr->chiph_exists)) {
 		if (ptr->reg) {
 			fprintf(fil, "struct %s_config %s_info_%d\t= {\n", ptr->name_underscore, ptr->name_underscore, ptr->id);



From mylesgw at gmail.com  Thu Jun 10 00:42:39 2010
From: mylesgw at gmail.com (Myles Watson)
Date: Wed, 9 Jun 2010 16:42:39 -0600
Subject: [coreboot] [PATCH] lists of links
In-Reply-To: <4C101263.7080506@coresystems.de>
References: <AANLkTilYFrq7PgDTJJVh05L79wdadM6m7QSvKII-kA1g@mail.gmail.com>
	<AANLkTimrzWgxkmhq-xw6fnxP9Jofw5vvwdf2UMBjlv7Q@mail.gmail.com>
	<4C101263.7080506@coresystems.de>
Message-ID: <AANLkTilmaO07icQiQj8kgNRijygL_-Re42GIpCzeWQf5@mail.gmail.com>

On Wed, Jun 9, 2010 at 4:14 PM, Stefan Reinauer <stepan at coresystems.de> wrote:
> On 6/9/10 11:49 PM, Myles Watson wrote:
>> Signed-off-by: Myles Watson <mylesgw at gmail.com>
>>
>> Removed some warnings and fixed static.c generation when the
>> southbridge link is not 0.
>>
> I didn't test this, but assuming we're not planning on getting rid of
> malloc anymore, this is
>
> Acked-by: Stefan Reinauer <stepan at coresystems.de>
Rev 5626

Thanks,
Myles



From svn at coreboot.org  Thu Jun 10 01:17:50 2010
From: svn at coreboot.org (repository service)
Date: Thu, 10 Jun 2010 01:17:50 +0200
Subject: [coreboot] build service results for r5626
Message-ID: <E1OMUWs-00021h-Iy@ra.coresystems.de>

Dear coreboot readers!

This is the automatic build system of coreboot.

The developer "myles" checked in revision 5626 to
the coreboot repository. This caused the following 
changes:

Change Log:
Same conversion as with resources from static arrays to lists, except
there is no free list.

Converting resource arrays to lists reduced the size of each device
struct from 1092 to 228 bytes.

Converting link arrays to lists reduced the size of each device struct
from 228 to 68 bytes.

Signed-off-by: Myles Watson <mylesgw at gmail.com>
Acked-by: Stefan Reinauer <stepan at coresystems.de>


Build Log:
Compilation of amd:rumba has been broken
See the error log at http://qa.coreboot.org/log_buildbrd.php?revision=5626&device=rumba&vendor=amd&num=2


If something broke during this checkin please be a pain 
in myles'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  Thu Jun 10 02:19:30 2010
From: rminnich at gmail.com (ron minnich)
Date: Wed, 9 Jun 2010 17:19:30 -0700
Subject: [coreboot] [PATCH] lists of links
In-Reply-To: <4C10167D.8010001@coresystems.de>
References: <AANLkTilYFrq7PgDTJJVh05L79wdadM6m7QSvKII-kA1g@mail.gmail.com>
	<AANLkTimrzWgxkmhq-xw6fnxP9Jofw5vvwdf2UMBjlv7Q@mail.gmail.com>
	<4C101263.7080506@coresystems.de>
	<AANLkTilmyboonSHcY1-pjcKuGiOR8TACie4OaGkY6z1n@mail.gmail.com>
	<4C10167D.8010001@coresystems.de>
Message-ID: <AANLkTilbQkULNjsxbyyjzJiJKCv4jJWVkEDAeEf4ZtK3@mail.gmail.com>

getting rid of malloc was a beautiful theory that was killed by a
brutal gang of facts.

Don't you just hate it when that happens :-)

ron



From kevin at koconnor.net  Thu Jun 10 04:57:30 2010
From: kevin at koconnor.net (Kevin O'Connor)
Date: Wed, 9 Jun 2010 22:57:30 -0400
Subject: [coreboot] [PATCH] Bootsplash for SeaBIOS (with coreboot)
In-Reply-To: <4C0F46D3.3070405@coresystems.de>
References: <4C0F46D3.3070405@coresystems.de>
Message-ID: <20100610025730.GB326@morn.localdomain>

On Wed, Jun 09, 2010 at 09:46:27AM +0200, Stefan Reinauer wrote:
> See patch

Thanks Stefan!  It looks very useful.

I haven't had a chance to review the patch fully.  One thing I did
note is that the new file jpeg.c needs a copyright statement.

At a quick glance I also noticed a couple of minor things:

* It looks like you want malloc_tmplow/tmphigh instead of
  malloc_low/high - using the permanent allocations has an impact on
  reserved space even if they are eventually freed.

* I'd guess we'd want to malloc_tmp and cbfs_copyfile instead of
  cbfs_getfile - doing the jpeg uncompression with the rom as source
  could be slow.

* there seems to be some tab/space corruption in optionrom.c - seabios
  uses all spaces

* Do the vga changes justify a new file instead of an addition to
  optionrom.c?

-Kevin



From kevin at koconnor.net  Thu Jun 10 04:33:34 2010
From: kevin at koconnor.net (Kevin O'Connor)
Date: Wed, 9 Jun 2010 22:33:34 -0400
Subject: [coreboot] [SeaBIOS]  [PATCH] SeaBIOS VGA hooks
In-Reply-To: <4C0FEADC.4090800@coresystems.de>
References: <4C0F4698.6000405@coresystems.de>
	<AANLkTikDo087UjGhFfQUzZvBEFk4wBlYkZJHdPkoC2aC@mail.gmail.com>
	<4C0FDEC5.70702@coresystems.de>
	<AANLkTikyO4eG4TT3Qr-b6NK4yMvGv1K39HIR69DZMsNS@mail.gmail.com>
	<4C0FEADC.4090800@coresystems.de>
Message-ID: <20100610023334.GA326@morn.localdomain>

On Wed, Jun 09, 2010 at 09:26:20PM +0200, Stefan Reinauer wrote:
> On 6/9/10 8:48 PM, Myles Watson wrote:
> >> > It would need to be 0xe0000 - 0xfffff unless we want to start cutting
> >> > out more memory.
> >>     
> > I meant where as in what interrupt to patch, not what address to run
> > at.  SeaBIOS should be able to use whatever address it wants to.
> >   
> If it contains a dynamic linker, or the code is position independent, yes.
> 
> >> > Alternatively we could add an SMI "function call" to coreboot that does
> >> > the deed. That would simplify the code in SeaBIOS significantly but add
> >> > more requirements for SMM.
> >>     
> > I'm not sure what's best.  Maybe few enough boards will need their own
> > handlers that it doesn't really matter.
> >   
> Kevin, any preference?

I think vgahooks.c is simple enough that extending it for the handful
of boards that need it is okay.  If it becomes too unwieldy, then I'm
sure we can come up with a new system at that time.

If an alternate solution is needed, I'd guess it would be simplest to
deploy an option rom that hooked 155f.  Writing an option rom that
hooks 155f is straight forward.  However, there would be some
complexity in deployment because the option rom would need to run
before the vga bios and it would need to be loaded to an address other
than 0xc0000.  (Normally the vgabios is the first option rom to be
executed, and option roms are normally loaded in ascending order
starting at 0xc0000.)  So, I'd say it is definitely possible, but
probably not worth it right now.

-Kevin



From svn at coreboot.org  Thu Jun 10 05:14:01 2010
From: svn at coreboot.org (repository service)
Date: Thu, 10 Jun 2010 05:14:01 +0200
Subject: [coreboot] [commit] r5627 - trunk/src/mainboard/amd/rumba
Message-ID: <E1OMYDR-0003Hj-98@ra.coresystems.de>

Author: myles
Date: Thu Jun 10 05:14:00 2010
New Revision: 5627
URL: https://tracker.coreboot.org/trac/coreboot/changeset/5627

Log:
The devicetree was wrong, but I'm still surprised it broke.  This fixes the
board, but doesn't fix the device tree parsing.

Signed-off-by: Myles Watson <mylesgw at gmail.com>
Acked-by: Myles Watson <mylesgw at gmail.com>

Modified:
   trunk/src/mainboard/amd/rumba/devicetree.cb

Modified: trunk/src/mainboard/amd/rumba/devicetree.cb
==============================================================================
--- trunk/src/mainboard/amd/rumba/devicetree.cb	Thu Jun 10 00:41:35 2010	(r5626)
+++ trunk/src/mainboard/amd/rumba/devicetree.cb	Thu Jun 10 05:14:00 2010	(r5627)
@@ -15,7 +15,7 @@
         		device pci f.2 on end	# IDE Controller
         		device pci f.3 on end 	# Audio
         		device pci f.4 on end	# OHCI
-			device pci f.4 on end	# UHCI
+			device pci f.5 on end	# EHCI
       		end
     	end
 end



From svn at coreboot.org  Thu Jun 10 05:26:16 2010
From: svn at coreboot.org (repository service)
Date: Thu, 10 Jun 2010 05:26:16 +0200
Subject: [coreboot] build service results for r5627
Message-ID: <E1OMYPI-0005Cf-Jb@ra.coresystems.de>

Dear coreboot readers!

This is the automatic build system of coreboot.

The developer "myles" checked in revision 5627 to
the coreboot repository. This caused the following 
changes:

Change Log:
The devicetree was wrong, but I'm still surprised it broke.  This fixes the
board, but doesn't fix the device tree parsing.

Signed-off-by: Myles Watson <mylesgw at gmail.com>
Acked-by: Myles Watson <mylesgw at gmail.com>


Build Log:
Compilation of amd:rumba has been fixed


If something broke during this checkin please be a pain 
in myles'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  Thu Jun 10 06:06:52 2010
From: svn at coreboot.org (repository service)
Date: Thu, 10 Jun 2010 06:06:52 +0200
Subject: [coreboot] [commit] r5628 - trunk/util/sconfig
Message-ID: <E1OMZ2a-0007vS-Sb@ra.coresystems.de>

Author: myles
Date: Thu Jun 10 06:06:52 2010
New Revision: 5628
URL: https://tracker.coreboot.org/trac/coreboot/changeset/5628

Log:
Check for NULL before calling device_match()

It matters for multifunction devices who don't have siblings.

The error in the rumba device tree created that situation.

Signed-off-by: Myles Watson <mylesgw at gmail.com>
Acked-by: Myles Watson <mylesgw at gmail.com>

Modified:
   trunk/util/sconfig/main.c

Modified: trunk/util/sconfig/main.c
==============================================================================
--- trunk/util/sconfig/main.c	Thu Jun 10 05:14:00 2010	(r5627)
+++ trunk/util/sconfig/main.c	Thu Jun 10 06:06:52 2010	(r5628)
@@ -348,7 +348,7 @@
 					fprintf(fil, "\t\t\t.dev = &%s,\n", d->name);
 					if (d->children)
 						fprintf(fil, "\t\t\t.children = &%s,\n", d->children->name);
-					if (device_match(d->next_sibling, ptr))
+					if (d->next_sibling && device_match(d->next_sibling, ptr))
 						fprintf(fil, "\t\t\t.next=&%s_links[%d],\n", d->name, d->link+1);
 					else
 						fprintf(fil, "\t\t\t.next = NULL,\n");



From oliver at schinagl.nl  Thu Jun 10 12:22:03 2010
From: oliver at schinagl.nl (Oliver Schinagl)
Date: Thu, 10 Jun 2010 12:22:03 +0200
Subject: [coreboot] Minor update on IDE mode on Wyse S10 (CS5536)
In-Reply-To: <201006092321.18381.njacobs8@hetnet.nl>
References: <201006092321.18381.njacobs8@hetnet.nl>
Message-ID: <4C10BCCB.5090400@schinagl.nl>

On 06/09/2010 11:21 PM, Nils wrote:
> Hi Oliver,
> You wrote:
>    
>> I am now ready I think to start giving coreboot a whirl on this thing.
>> Though I still wonder, if the bios can boot the kernel from the IDE
>> 'drive', I assume coreboot will equally be able to boot it; but if
>> recent kernels refuse to use the disk, I may end up being screwed anyway
>> :S.
>>      
> As i was trying to explain before, there is nothing wrong with the hardware
> or the way the IDE port is connected.
> The only problem is the stock bios witch is initializing the IDE port of the
> CS5536 as flash port.(that gives troubles if you are using a real IDE harddisk)
> When you use coreboot you can enable or disable flash_enable.
> Normaly it is disabled so you can use IDE.(But for your flash drive i think you
> want flash enabled)
> With coreboot you can use a normal recent kernel with the appropriate
> drivers.
>    
Ok I had to sleep over this one and think about this one a little bit. 
Earlier you wrote, you only got the IDE port to work on a 2.6.24 kernel; 
At first I assumed using any bios, but now that I thought about it, 
after your comment here, did you mean, 2.6.24 is the only kernel with 
IDE mode using the wyse bios, and IDE mode works on any driver with 
coreboot? Then, it makes sense perfectly, and I'll flash your rom tonight :)
> Succes,Nils
>    
Oliver



From =?UTF-8?Q?palito at o2.pl?=  Thu Jun 10 14:24:07 2010
From: =?UTF-8?Q?palito at o2.pl?= (=?UTF-8?Q?palito at o2.pl?=)
Date: Thu, 10 Jun 2010 14:24:07 +0200
Subject: [coreboot] =?utf-8?q?coreboot_on_Dell_c600?=
Message-ID: <553651f8.5e039b2d.4c10d967.8ef4b@o2.pl>

Did any progress was made in the matter of coreboot on laptops and with Dell C600 Latitude? As I am googling the net and the mailing list I see that my chipset is supported but still I am bit afraid to flash it with coreboot. Any suggestion except mounting a socket for changeable chips?



From joe at settoplinux.org  Thu Jun 10 15:36:42 2010
From: joe at settoplinux.org (Joseph Smith)
Date: Thu, 10 Jun 2010 09:36:42 -0400
Subject: [coreboot] coreboot on Dell c600
In-Reply-To: <553651f8.5e039b2d.4c10d967.8ef4b@o2.pl>
References: <553651f8.5e039b2d.4c10d967.8ef4b@o2.pl>
Message-ID: <39eca38b821466ee3154ab2f7798dae2@imap.1and1.com>




On Thu, 10 Jun 2010 14:24:07 +0200, palito at o2.pl <palito at o2.pl> wrote:
> Did any progress was made in the matter of coreboot on laptops and with
> Dell C600 Latitude? As I am googling the net and the mailing list I see
> that my chipset is supported but still I am bit afraid to flash it with
> coreboot. Any suggestion except mounting a socket for changeable chips?
> 
Hello and welcome,
I will say it again. I would love to see coreboot running on C600.
Unfortunately it will not run with out some development. You see the Dell
C600 has a AGP video card. AGP has not been implemented on i830 because my
i830 boards only have on-board graphics. So unless you are willing to roll
up your sleeves and dig in it may be a while. Of course if someone wanted
to donate a C600 to the cause I would be glad to get coreboot running on
it.

-- 
Thanks,
Joseph Smith
Set-Top-Linux
www.settoplinux.org




From joe.korty at ccur.com  Thu Jun 10 15:38:05 2010
From: joe.korty at ccur.com (Joe Korty)
Date: Thu, 10 Jun 2010 09:38:05 -0400
Subject: [coreboot] [h8dme-fam10] acquiring coreboot skills from scratch
 somewhat daunting
Message-ID: <20100610133805.GA3452@tsunami.ccur.com>

Hi,
As a learning experience, I've been trying to port coreboot to the
supermicro h8dme-2 w/ AMD K10.  I've had not much luck either in the
learning or the porting.  In any case I've got coreboot up to where it
is out of car and has started to clear memory, at which point it hangs.
I presume this is because I failed to properly set up each socket's
memory controller.

  Copying data from cache to RAM -- switching to use RAM as stack... Done
  testx = 5a5a5a5a
  Disabling cache as ram now 
  Clearing initial memory region:

I started with the h8dmr_fam10 port since the h8dmr is identical, spec-wise,
to the h8dme except that it has half the number of dimm slots.  Also there
is both K8 and K10 versions of coreboot for the h8dmr which in principle
makes the study of the differences a good way to learn coreboot internals.

In any case I have not been able to find where the info in spd_addr.h comes
from, so I have not been able to make it correct for my board.  How does one
construct this table?  In general, how does one construct devicetree.cb and
the other tables from scratch?

Is there an apprenticeship program somewhere, perhaps at some conference?
How do people in general get their coreboot skill-set jump-started?

Regards,
Joe
-------------- next part --------------
coreboot-4.0-r5628M Thu Jun 10 08:46:40 EDT 2010 starting...

Coreboot configured for H8DME-2 with K10 AMD processors
BSP Family_Model: 00100f42 
*sysinfo range: [000cc000,000cdfa0]
bsp_apicid = 00 
cpu_init_detectedx = 00000000 
microcode: equivalent rev id  = 0x1041, current patch id = 0x00000000
microcode: rev id (1062) does not match this patch.
microcode: Not updated! Fix microcode_updates[] 
cpuSetAMDMSR  done
Enter amd_ht_init()
AMD_CB_EventNotify()
 event class: 05
 event: 1004
 data:  04  00  00  01 
AMD_CB_ManualBUIDSwapList()
AMD_CB_EventNotify()
 event class: 05
 event: 2006
 data:  04  00  02  ff 
Exit amd_ht_init()
cpuSetAMDPCI 00 done
cpuSetAMDPCI 01 done
Prep FID/VID Node:00 
  F3x80: e600a681 
  F3x84: a0e641e6 
  F3xD4: c3310f24 
  F3xD8: 03001615 
  F3xDC: 00005322 
Prep FID/VID Node:01 
  F3x80: e600a681 
  F3x84: a0e641e6 
  F3xD4: c3310f24 
  F3xD8: 03001615 
  F3xDC: 00005322 
setup_remote_node: 01 done
Start node 01 done.
core0 started:  core0:  --- { APICID = 04 NODEID = 01 COREID = 00} ---
c0mi1
ersoctoadrte_:o tehqeuriv_acolreents (r)
tc iinidt   =n od0ex:10 4010 ,  ccuorrerse:nt  0p3 a
- hS taird t=  ot0hxe00r0 c0o0r00e0 
6 nmiocderiocdo:d 0e:0  r cevo riesd: ( 1003
 2)i ndoiets  nnoodte :m 0a1t ch  ctohriess :p a0t3 ch
S
dtmairctr ooctohdeer:  cNoorte  u-p dnaotdeeid!d :F i0x1  m iccorroecso:d e0_u3p
xdxx   teacccs[rooortrr] eeee
    : :: a  cpp   -- -uS--a-e---p  it {{cA{M  i DAAdAMPP:PSII IRCCCIII DDD   ===   d o0n00e231
 N  NONinODOiDEDtEIE_IDIfD Di = d= =v 0 i000d0 0_ C aCOCpORO(RERsEIEtIDIaD Dg = d- =0 1 0)02}1 3a} }- p i---c---i
 : 

exrxccc *m oo0ommr4riAiriPccece
    x rr:oo:F:0o I 1c ccoDos o  --ddV-dt-ea--eeI-r-::D-:      t {{e{oeee dqqn  quu AAAiiPPPi
            IvIIv*PvCa :aCaC lIlIIlAPeDeDDe0 n4 n n t0=t==t
D D  ==Ersreete000vavv6r 5 7  ii ti deNNddNO  dOO D
        E=EI I  I*D D0D00xx A x =111=P=    00004400041111131 s , ,,C  CtC OcOccO n =ttt=rrEtErEIrIrrIeDdDeDeenn 
dd      =      000ppp21aa3a}t}tt} ccc  hhh----  -- ii--i-

     
     ===*   000 mmmiAiixxx000cPccrr000r o0oo000c005cc0oo0o00sd0td0d0e0e0ae0:0:0:   

ee
uuiiicccimmu
         iivvrrrv*a aaooolccAllceeoeooPnd ndndttt0eee 6::  :r rs  rerreretvaveev =v r vv  i itidediidi d d dd     
  ((=(= 1  *11000000 xAx666x121P1220))0)0 404  4 1d171ddoo,o,s, t ee ecscacss  un   ntmtrnrrorreooettteedn
p       tmm aa a 
thttptacaacc
    hh B c cchhtetht h  hghiiiiiiiddsdnss       =F=pp=p a I aa0tt0t0DxVxccxc0h0I0hh..0.0D00 0
 0M0

ooo mm0m0S00Rii0i00c00 cc0rrr000
c
 c
  ccooo0mmmi0ddiidccec1eer::r:r0o0o  o cNc7cNNoooooo1d dttdt 0  eeeuu::u:x p 3pp rdrdr0dabeaeaevtt0vtv e  ee0i0iiddddd!!ad!      3(F F((F1i1i0i10xx0x0x6 64 6 2meeno_o_oi)i) c c3 cdrdrdr50ooooooec4cecesosso0o  dd  dnen
iBsSs   _tututuF pp Ip dDmmddmaaaVaaatttttItcDceceehssh hs [ [[ otnt]t]]  h h hi
     s

MM_    P  cccpppp,ppaauuua tAttSSSeeecPcchhttthI.C..AAA

 D
ccoDimMdmMmMiSiS:iScRcRcR rr0r   ooo0c
o  ooddd   e:dddee:oo: onn Nn eeNoeNBotS

t P
   t  u iiipfnunnupidiipidtdtadtt _a_a_tfe=ftfeieii d!dd1ddd vv0!!v iFii6 Fd0Fdidx_i_0i_xa axa
p pmp i(m(m(Wsacsisicttirtcraraatocg ogogceoefceo1o1d1or)d)d)ee _  e _a_auAapPup ppdii pipdcdaccsaitiatiedtdadte:s:e:gs es [ ]0[0 [0]3 1]21:

 


F
 FaFcpIpIIccppD_DDuSVuuVaVepIISSIeDtiDDet  t AcMiAooAoMnDdMnnD  D M S=MAAMASPR S   0R:R1   
  o 00321 


nn nddooe
i       ee
 en
tgaeaiinntd_biittfa_c_ifdfki ivid=dv dv_ii1d0ad__1p(0aapps6t0((sa1st
a0067g1g        ec)e11o am))  pmioaapcnpi_iicdcfii:i ddd:(0:5  p
     cFk
Ie
A:P PDIVI)D DIDV=VI  IoDD1 0n oo6 A0nn  P0A
i0067:W:0 a5 
     t
f
 or AP stage 1: ap_apicid = 2
        readback = 2010601
        common_fid(packed) = 10600
Wait for AP stage 1: ap_apicid = 3
        readback = 3010601
        common_fid(packed) = 10600
Wait for AP stage 1: ap_apicid = 4
        readback = 4010601
        common_fid(packed) = 10600
Wait for AP stage 1: ap_apicid = 5
        readback = 5010601
        common_fid(packed) = 10600
Wait for AP stage 1: ap_apicid = 6
        readback = 6010601
        common_fid(packed) = 10600
Wait for AP stage 1: ap_apicid = 7
        readback = 7010601
        common_fid(packed) = 10600
common_fid = 10600
FID Change Node:00, F3xD4: c3310f26 
FID Change Node:01, F3xD4: c3310f26 
End FIDVIDMSR 0xc0010071 0x30b000a3 0x38035040 
mcp55_num:01
...WARM RESET...




coreboot-4.0-r5628M Thu Jun 10 08:46:40 EDT 2010 starting...

Coreboot configured for H8DME-2 with K10 AMD processors
BSP Family_Model: 00100f42 
*sysinfo range: [000cc000,000cdfa0]
bsp_apicid = 00 
cpu_init_detectedx = 00000000 
microcode: equivalent rev id  = 0x1041, current patch id = 0x00000000
microcode: rev id (1062) does not match this patch.
microcode: Not updated! Fix microcode_updates[] 
cpuSetAMDMSR  done
Enter amd_ht_init()
AMD_CB_EventNotify()
 event class: 05
 event: 1004
 data:  04  00  00  01 
AMD_CB_ManualBUIDSwapList()
AMD_CB_EventNotify()
 event class: 05
 event: 2006
 data:  04  00  02  ff 
Exit amd_ht_init()
cpuSetAMDPCI 00 done
cpuSetAMDPCI 01 done
Prep FID/VID Node:00 
  F3x80: e600a681 
  F3x84: a0e641e6 
  F3xD4: c3310f26 
  F3xD8: 03001615 
  F3xDC: 00005322 
Prep FID/VID Node:01 
  F3x80: e600a681 
  F3x84: a0e641e6 
  F3xD4: c3310f26 
  F3xD8: 03001615 
  F3xDC: 00005322 
setup_remote_node: 01 done
Start node 01 done.
core0 started:  01
start_other_cores()
init node:  00co r eco0r: es -: --03 {  
ASPItCaIrtD  =o the04r  NcoOrDEeI -D  n= o0de1i dCO:R 0E0I D  =co r00e}s : -0--3

vnmiitc rnoocdoed:e :0 1 eq uciovraelse:n t0 3r e
  Sitda r t= o 0txh1e0r4 1c,o rceu r-r ennotd epiadt:c h0 1i d  c=o r0exs0:0 000030
   t
    acccmiroooctrrrreeeeodxxxc :::oa   dp   e :a--- p------riec   {{{vi    diAAA:dPPP  III(CCC1III0DDD6   2===)    d000o213es    NNNnOOOoDDDtEEE IIImDDDa   t===1   h000 000t   hCCCiOOOsRRR EEEpIIIaDDDt   c===h   0.0023
c}}}m   -i---c--r---o


    *o cccmmmoiiAoiodccPrcrerer re:er0oox xox:ccN:c:1ooo o s tddtd   -a ee--e::-ut uu  eiAiiAA ed eee{qda{qq{
              PvvvPP*dII !IaaaCA ClllCFPIeeeIID nnnDDit0tt  x =2  = = rsr m r ted E==Evc0007 r r56 tiio  i cddNNdNe  OO OdoD D D
      e=E  I*_ IID0 u0DD0Axpx  x d11==1=P00  0  a040400t411113e11,, ss,  C t[ CCrEErEtrIIrIeruRru
np n=t       rDeDdeDec n 
      tu=t=  S    e0p00pp3ata1a2}t}}tAt cMc c -h--hDh- M - --i--iSi

   
csc000=*    00m0Am mixPixxid 0c00cocr000rnr0000oeo5oc00
 e    oto0o0dad0d0ie00n0ere00i0:t::t

d_
qfmmmuq
      uiiiiui*dccciiv rrrvvvoAooaaailPcclldco oee_oen0dnsdnd6tttteee a :: :sgr  d d d i    eeeverv2v vvt   v  eiai ididpdidi
 4 1d1s     c ((=*(i== 1 1d  1A00:0000 66xx6xP221121 00)0)004)4 47
etn    d1d,t,oo,o eee a cssscrcutu   unnnrrerrdrooorette
tm n n  tmmt
aa  a aapttppt
  cccathhttBhcce c  htthhgt  ih hhiiiiinidd sdss     F ==Ip=pp aa  Da00Vt0ttxccx0Ic00Dh0hh0..00 .00M

 00S
oo  00Rm0mm0ii00 i00c0cc00rr00xr
cc

  0co0oommmddiid1ice0ceec::rr:0ro 7o  oNNccN1coo oooottddt0d   exee:uu::3u  0p pprddrrbdee0aeaavttvv0t  0e eeiiiadddd3d!!d!       (0(FF(Fii1i1x1030xx0x6  686 20 dnmm)ii)3)i 5 c ccdrrd0dro4oooooecce0ecs sosoo dd 
   neneeo__oo_tutuutEppn  p mdmdddmaa aaaatttttFtceIcecehshshsD [V [ [t]t]t]Ih DMsh i
  Ss
    s
DD      Rccc ppppppuuaa0uaSxtSStteeccecc0thtthhAA..0A.M1

  D0
aot 0MmMMmmSSii7SiR1cRRccrrr    o0oocccxo3ood0dd   eedddeb:o0::oo  nn n0Ne0NNeeo
   3tt

          iiiun0uunnppiipixdt3ddttaa__a_8tf0ttffeeiiei02dddddd!vv!8v! 0i  iiFddFsx i _ii__xssx
   t  ttmaammamigicgigceececpr2r5r22o  o o5cac_caaoppoponddudiiiecceecm_i:_ii_udd00aa0:1p::p  dd 
s     a1t32tte

 s
  s[[[]]]   


cccpppuuuSSSeeetttAAAMMMDDDMMMSSSRRR      dddooonnneee


iiinnniiittt___fffiiidddvvviiiddd___ssstttaaagggeee222   aaapppiiiccciiiddd:::   000567


fill_mem_ctrl()
raminit_amdmct()
raminit_amdmct begin:
 Node: 01  base: 00  limit: 7fffff  BottomIO: e00000
 Copy dram map from Node 0 to Node 01 
raminit_amdmct end:
v_esp=000cbee8
testx = 5a5a5a5a
Copying data from cache to RAM -- switching to use RAM as stack... Done
testx = 5a5a5a5a
Disabling cache as ram now 
Clearing initial memory region: 

From mylesgw at gmail.com  Thu Jun 10 16:31:06 2010
From: mylesgw at gmail.com (Myles Watson)
Date: Thu, 10 Jun 2010 08:31:06 -0600
Subject: [coreboot] [h8dme-fam10] acquiring coreboot skills from scratch
	somewhat daunting
In-Reply-To: <20100610133805.GA3452@tsunami.ccur.com>
References: <20100610133805.GA3452@tsunami.ccur.com>
Message-ID: <AANLkTikGu31lG0fKp0Y2cGg7zDe1W27VVx-MP07PGnVC@mail.gmail.com>

On Thu, Jun 10, 2010 at 7:38 AM, Joe Korty <joe.korty at ccur.com> wrote:
> Hi,
> As a learning experience, I've been trying to port coreboot to the
> supermicro h8dme-2 w/ AMD K10.
Ward and others have tried this board in the past.  There seems to be
something wrong with multi-core setup for K10.

If you search the mailing list for "h8dme fam10", it might give you
some help.  I would disable all the other processors until you get the
board working.

CONFIG_LOGICAL_CPUS 0
CONFIG_SMP 0
CONFIG_MAX_PHYSICAL_CPUS 1

> I started with the h8dmr_fam10 port since the h8dmr is identical, spec-wise,
> to the h8dme except that it has half the number of dimm slots. ?Also there
> is both K8 and K10 versions of coreboot for the h8dmr which in principle
> makes the study of the differences a good way to learn coreboot internals.
I agree that's a good approach.  K8 and fam10 code are pretty similar,
though they could be made even more similar.

> In any case I have not been able to find where the info in spd_addr.h comes
> from, so I have not been able to make it correct for my board. ?How does one
> construct this table? ?In general, how does one construct devicetree.cb and
> the other tables from scratch?
I don't know that anyone does it from scratch.  The idea is to make
the devicetree as minimal as possible.  That usually means including
the processor and configuring the southbridge buses.  The rest can
usually be found.


> Is there an apprenticeship program somewhere, perhaps at some conference?
I don't know.  There have been some talks and short tutorials, but I
haven't heard of an official training program.

> How do people in general get their coreboot skill-set jump-started?
IRC and the mailing list is what I've heard most.  I've used the mailing list.

Qemu and SimNOW are both helpful, too.  SimNOW exhibits the same
problems for fam10 as hardware (super slow initialization and problems
with logical CPUs), so fixing it there would probably help.

Thanks,
Myles



From knuku at gap.upv.es  Thu Jun 10 16:52:30 2010
From: knuku at gap.upv.es (Knut Kujat)
Date: Thu, 10 Jun 2010 16:52:30 +0200
Subject: [coreboot] [h8dme-fam10] acquiring coreboot skills from scratch
 somewhat daunting
In-Reply-To: <AANLkTikGu31lG0fKp0Y2cGg7zDe1W27VVx-MP07PGnVC@mail.gmail.com>
References: <20100610133805.GA3452@tsunami.ccur.com>
	<AANLkTikGu31lG0fKp0Y2cGg7zDe1W27VVx-MP07PGnVC@mail.gmail.com>
Message-ID: <4C10FC2E.6040705@gap.upv.es>

Myles Watson escribi?:
> On Thu, Jun 10, 2010 at 7:38 AM, Joe Korty <joe.korty at ccur.com> wrote:
>   
>> Hi,
>> As a learning experience, I've been trying to port coreboot to the
>> supermicro h8dme-2 w/ AMD K10.
>>     
> Ward and others have tried this board in the past.  There seems to be
> something wrong with multi-core setup for K10.
>   
I think that why Ward had problems with this CPU family is for the same
reason why I had problems with it on different boards, the resource map!
I started using the one from the h8dme fam 10 board. So maybe you should
try another resource map from another fam 10 board.
bye!
> If you search the mailing list for "h8dme fam10", it might give you
> some help.  I would disable all the other processors until you get the
> board working.
>
> CONFIG_LOGICAL_CPUS 0
> CONFIG_SMP 0
> CONFIG_MAX_PHYSICAL_CPUS 1
>
>   
>> I started with the h8dmr_fam10 port since the h8dmr is identical, spec-wise,
>> to the h8dme except that it has half the number of dimm slots.  Also there
>> is both K8 and K10 versions of coreboot for the h8dmr which in principle
>> makes the study of the differences a good way to learn coreboot internals.
>>     
> I agree that's a good approach.  K8 and fam10 code are pretty similar,
> though they could be made even more similar.
>
>   
>> In any case I have not been able to find where the info in spd_addr.h comes
>> from, so I have not been able to make it correct for my board.  How does one
>> construct this table?  In general, how does one construct devicetree.cb and
>> the other tables from scratch?
>>     
> I don't know that anyone does it from scratch.  The idea is to make
> the devicetree as minimal as possible.  That usually means including
> the processor and configuring the southbridge buses.  The rest can
> usually be found.
>
>
>   
>> Is there an apprenticeship program somewhere, perhaps at some conference?
>>     
> I don't know.  There have been some talks and short tutorials, but I
> haven't heard of an official training program.
>
>   
>> How do people in general get their coreboot skill-set jump-started?
>>     
> IRC and the mailing list is what I've heard most.  I've used the mailing list.
>
> Qemu and SimNOW are both helpful, too.  SimNOW exhibits the same
> problems for fam10 as hardware (super slow initialization and problems
> with logical CPUs), so fixing it there would probably help.
>
> Thanks,
> Myles
>
>   




From rminnich at gmail.com  Thu Jun 10 16:55:27 2010
From: rminnich at gmail.com (ron minnich)
Date: Thu, 10 Jun 2010 14:55:27 +0000
Subject: [coreboot] PATCH: Porting v3-style Geode LX cpu init to v4
In-Reply-To: <95EC52016CC5DE4896FD95FA7323A4DB152FFE4535@mr-burns.exchange.virtensys.com>
References: <95EC52016CC5DE4896FD95FA7323A4DB152FFE4535@mr-burns.exchange.virtensys.com>
Message-ID: <AANLkTimn5MNpXxDcVJG9SfbVoQfccjoIREd4l7eHwUvR@mail.gmail.com>

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



From mylesgw at gmail.com  Thu Jun 10 17:07:19 2010
From: mylesgw at gmail.com (Myles Watson)
Date: Thu, 10 Jun 2010 09:07:19 -0600
Subject: [coreboot] [PATCH] resource maps
In-Reply-To: <AANLkTilxewyJug2rrJcUPjME3rvq4XvsoJyh_yUByRDj@mail.gmail.com>
References: <AANLkTilxewyJug2rrJcUPjME3rvq4XvsoJyh_yUByRDj@mail.gmail.com>
Message-ID: <AANLkTimpyJgWC7a-Mob2Vxh2F2eD64ZJuYaYnhQ4wAn_@mail.gmail.com>

On Mon, May 10, 2010 at 1:24 PM, Myles Watson <mylesgw at gmail.com> wrote:
> I think there's too much duplication in the resource map code.
> resourcemaps.diff tries to address it by:
>
> Creating clear_resource_map() for k8 and fam10. ?This sets all the
> routing registers to a known state.
> Calling clear_resource_map() and then only setting the specific
> registers that are non-zero in board-specific code.
> Adding util.c for fam10, so that it can be customized for fam10.
>
> I didn't update all of the resourcemap.c files, yet. ?I wanted to see
> what the reaction would be.
Ping.

> sublinks.diff marks that bit as not reserved for all fam10 boards, so
> that it can be cleared.
>
> Signed-off-by: Myles Watson <mylesgw at gmail.com>
>
> Thanks,
> Myles
>



From mylesgw at gmail.com  Thu Jun 10 17:09:13 2010
From: mylesgw at gmail.com (Myles Watson)
Date: Thu, 10 Jun 2010 09:09:13 -0600
Subject: [coreboot] [h8dme-fam10] acquiring coreboot skills from scratch
	somewhat daunting
In-Reply-To: <4C10FC2E.6040705@gap.upv.es>
References: <20100610133805.GA3452@tsunami.ccur.com>
	<AANLkTikGu31lG0fKp0Y2cGg7zDe1W27VVx-MP07PGnVC@mail.gmail.com>
	<4C10FC2E.6040705@gap.upv.es>
Message-ID: <AANLkTin4eQ19pQ4ztqDhP3-rV_6qVYuVib3LOB8S-lV7@mail.gmail.com>

>>> Hi,
>>> As a learning experience, I've been trying to port coreboot to the
>>> supermicro h8dme-2 w/ AMD K10.
>>>
>> Ward and others have tried this board in the past. ?There seems to be
>> something wrong with multi-core setup for K10.
>>
> I think that why Ward had problems with this CPU family is for the same
> reason why I had problems with it on different boards, the resource map!
> I started using the one from the h8dme fam 10 board. So maybe you should
> try another resource map from another fam 10 board.
> bye!
I'd forgotten about that problem.  I think it's separate from the
SimNOW problems, but it could be causing you grief, too.

Thanks,
Myles



From joe.korty at ccur.com  Thu Jun 10 17:10:28 2010
From: joe.korty at ccur.com (Joe Korty)
Date: Thu, 10 Jun 2010 11:10:28 -0400
Subject: [coreboot] [h8dme-fam10] acquiring coreboot skills from scratch
 somewhat daunting
In-Reply-To: <4C10FC2E.6040705@gap.upv.es>
References: <20100610133805.GA3452@tsunami.ccur.com>
	<AANLkTikGu31lG0fKp0Y2cGg7zDe1W27VVx-MP07PGnVC@mail.gmail.com>
	<4C10FC2E.6040705@gap.upv.es>
Message-ID: <20100610151028.GA7194@tsunami.ccur.com>

On Thu, Jun 10, 2010 at 10:52:30AM -0400, Knut Kujat wrote:
> Myles Watson escribi?:
>> On Thu, Jun 10, 2010 at 7:38 AM, Joe Korty <joe.korty at ccur.com> wrote:
>>> As a learning experience, I've been trying to port coreboot to the
>>> supermicro h8dme-2 w/ AMD K10.

>> Ward and others have tried this board in the past.  There seems to be
>> something wrong with multi-core setup for K10.

> I think that why Ward had problems with this CPU family is for the same
> reason why I had problems with it on different boards, the resource map!
> I started using the one from the h8dme fam 10 board. So maybe you should
> try another resource map from another fam 10 board.

>> If you search the mailing list for "h8dme fam10", it might give you
>> some help.  I would disable all the other processors until you get the
>> board working.

>> Qemu and SimNOW are both helpful, too.  SimNOW exhibits the same
>> problems for fam10 as hardware (super slow initialization and problems
>> with logical CPUs), so fixing it there would probably help.

Myles and Knut,
Thanks!  I'll probe these ideas and see what happens.

Another data point: It _does_ continue after the hang, but it takes about
an hour.  I image each memory write is timing out so a bunch of writes via
memset drags the total timeout to an hour.  At that point we try to load
the payload so it seems that I am really really close to the end here....

Regards,
Joe

... the extra trace data ...
Clearing initial memory region: Done
Loading stage image.
Check CBFS header at fffff8da
magic is 4f524243
Found CBFS header at fffff8da
Check fallback/romstage
CBFS: follow chain: fff00000 + 38 + 12438 + align -> fff12480
Check fallback/coreboot_ram
Stage: loading fallback/coreboot_ram @ 0x200000 (1146880 bytes), entry @ 0x200000
lzma: Decoding error = 1
CBFS: LZMA decompression failed!
Loading stage failed!



From svn at coreboot.org  Thu Jun 10 17:24:58 2010
From: svn at coreboot.org (repository service)
Date: Thu, 10 Jun 2010 17:24:58 +0200
Subject: [coreboot] [commit] r5629 - in trunk/src: cpu/amd/model_lx
	include/cpu/amd include/cpu/x86 mainboard/amd/db800
	mainboard/amd/norwich mainboard/artecgroup/dbe61
	mainboard/digitallogic/msm800sev mainboard/iei/p...
Message-ID: <E1OMjco-0001D9-8i@ra.coresystems.de>

Author: monofin
Date: Thu Jun 10 17:24:57 2010
New Revision: 5629
URL: https://tracker.coreboot.org/trac/coreboot/changeset/5629

Log:
This commit updates the Geode LX GLCP delay control setup from the v2 way to the v3 way.
This resolves problems with terminated DRAM modules.
Signed-off-by: Edwin Beasant <edwin_beasant at virtensys.com>
Acked-by: Roland G. Minnich <rminnich at gmail.com>

Modified:
   trunk/src/cpu/amd/model_lx/cpureginit.c
   trunk/src/cpu/amd/model_lx/msrinit.c
   trunk/src/include/cpu/amd/lxdef.h
   trunk/src/include/cpu/x86/msr.h
   trunk/src/mainboard/amd/db800/romstage.c
   trunk/src/mainboard/amd/norwich/romstage.c
   trunk/src/mainboard/artecgroup/dbe61/romstage.c
   trunk/src/mainboard/digitallogic/msm800sev/romstage.c
   trunk/src/mainboard/iei/pcisa-lx-800-r10/romstage.c
   trunk/src/mainboard/lippert/roadrunner-lx/romstage.c
   trunk/src/mainboard/lippert/spacerunner-lx/romstage.c
   trunk/src/mainboard/pcengines/alix1c/romstage.c
   trunk/src/mainboard/traverse/geos/romstage.c
   trunk/src/mainboard/winent/pl6064/romstage.c

Modified: trunk/src/cpu/amd/model_lx/cpureginit.c
==============================================================================
--- trunk/src/cpu/amd/model_lx/cpureginit.c	Thu Jun 10 06:06:52 2010	(r5628)
+++ trunk/src/cpu/amd/model_lx/cpureginit.c	Thu Jun 10 17:24:57 2010	(r5629)
@@ -1,6 +1,6 @@
 /*
  * This file is part of the coreboot project.
- *
+ * 
  * Copyright (C) 2006 Indrek Kruusa <indrek.kruusa at artecdesign.ee>
  * Copyright (C) 2006 Ronald G. Minnich <rminnich at gmail.com>
  * Copyright (C) 2007 Advanced Micro Devices, Inc.
@@ -25,200 +25,156 @@
 ;*	SetDelayControl
 ;*
 ;*************************************************************************/
-static void SetDelayControl(void)
+#include "cpu/x86/msr.h"
+
+
+
+
+/**
+ * Delay Control Settings table from AMD (MCP 0x4C00000F).
+ */
+static const msrinit_t delay_msr_table[] = {
+	{CPU_BC_MSS_ARRAY_CTL0, {.hi = 0x00000000, .lo = 0x2814D352}},
+	{CPU_BC_MSS_ARRAY_CTL1, {.hi = 0x00000000, .lo = 0x1068334D}},
+	{CPU_BC_MSS_ARRAY_CTL2, {.hi = 0x00000106, .lo = 0x83104104}},
+};
+
+
+
+static const struct delay_controls {
+	u8 dimms;
+	u8 devices;
+	u32 slow_hi;
+	u32 slow_low;
+	u32 fast_hi;
+	u32 fast_low;
+} delay_control_table[] = {
+	/* DIMMs Devs Slow (<=333MHz)            Fast (>334MHz) */
+	{   1,     4, 0x0837100FF, 0x056960004,  0x0827100FF, 0x056960004 },
+	{   1,     8, 0x0837100AA, 0x056960004,  0x0827100AA, 0x056960004 },
+	{   1,    16, 0x0837100AA, 0x056960004,  0x082710055, 0x056960004 },
+	{   2,     8, 0x0837100A5, 0x056960004,  0x082710000, 0x056960004 },
+	{   2,    16, 0x0937100A5, 0x056960004,  0x0C27100A5, 0x056960004 },
+	{   2,    20, 0x0B37100A5, 0x056960004,  0x0B27100A5, 0x056960004 },
+	{   2,    24, 0x0B37100A5, 0x056960004,  0x0B27100A5, 0x056960004 },
+	{   2,    32, 0x0B37100A5, 0x056960004,  0x0B2710000, 0x056960004 },
+};
+
+/*
+ * Bit 55 (disable SDCLK 1,3,5) should be set if there is a single DIMM
+ * in slot 0, but it should be clear for all 2 DIMM settings and if a
+ * single DIMM is in slot 1. Bits 54:52 should always be set to '111'.
+ *
+ * Settings for single DIMM and no VTT termination (like DB800 platform)
+ * 0xF2F100FF 0x56960004
+ * -------------------------------------
+ * ADDR/CTL have 22 ohm series R
+ * DQ/DQM/DQS have 33 ohm series R
+ */
+
+/**
+ * This is Black Magic DRAM timing juju[1].
+ *
+ * DRAM delay depends on CPU clock, memory bus clock, memory bus loading,
+ * memory bus termination, your middle initial (ha! caught you!), GeodeLink
+ * clock rate, and DRAM timing specifications.
+ *
+ * From this the code computes a number which is "known to work". No,
+ * hardware is not an exact science. And, finally, if an FS2 (JTAG debugger)
+ * is hooked up, then just don't do anything. This code was written by a master
+ * of the Dark Arts at AMD and should not be modified in any way.
+ * 
+ * [1] (http://www.thefreedictionary.com/juju)
+ *
+ * @param dimm0 The SMBus address of DIMM 0 (mainboard dependent).
+ * @param dimm1 The SMBus address of DIMM 1 (mainboard dependent).
+ * @param terminated The bus is terminated. (mainboard dependent).
+ */
+static void SetDelayControl(u8 dimm0, u8 dimm1, int terminated)
 {
-	unsigned int msrnum, glspeed;
-	unsigned char spdbyte0, spdbyte1;
+	u32 glspeed;
+	u8 spdbyte0, spdbyte1, dimms, i;
 	msr_t msr;
 
 	glspeed = GeodeLinkSpeed();
 
-	/* fix delay controls for DM and IM arrays */
-	msrnum = CPU_BC_MSS_ARRAY_CTL0;
-	msr.hi = 0;
-	msr.lo = 0x2814D352;
-	wrmsr(msrnum, msr);
-
-	msrnum = CPU_BC_MSS_ARRAY_CTL1;
-	msr.hi = 0;
-	msr.lo = 0x1068334D;
-	wrmsr(msrnum, msr);
-
-	msrnum = CPU_BC_MSS_ARRAY_CTL2;
-	msr.hi = 0x00000106;
-	msr.lo = 0x83104104;
-	wrmsr(msrnum, msr);
+	/* Fix delay controls for DM and IM arrays. */
+	for (i = 0; i < ARRAY_SIZE(delay_msr_table); i++)
+		wrmsr(delay_msr_table[i].index, delay_msr_table[i].msr);
 
-	msrnum = GLCP_FIFOCTL;
-	msr = rdmsr(msrnum);
+	msr = rdmsr(GLCP_FIFOCTL);
 	msr.hi = 0x00000005;
-	wrmsr(msrnum, msr);
+	wrmsr(GLCP_FIFOCTL, msr);
 
-	/* Enable setting */
-	msrnum = CPU_BC_MSS_ARRAY_CTL_ENA;
+	/* Enable setting. */
 	msr.hi = 0;
 	msr.lo = 0x00000001;
-	wrmsr(msrnum, msr);
+	wrmsr(CPU_BC_MSS_ARRAY_CTL_ENA, msr);
 
-	/* Debug Delay Control Setup Check
-	   Leave it alone if it has been setup. FS2 or something is here. */
-	msrnum = GLCP_DELAY_CONTROLS;
-	msr = rdmsr(msrnum);
-	if (msr.lo & ~(0x7C0)) {
+	/* Debug Delay Control setup check.
+	 * Leave it alone if it has been setup. FS2 or something is here.
+	 */
+	msr = rdmsr(GLCP_DELAY_CONTROLS);
+	if (msr.lo & ~(DELAY_LOWER_STATUS_MASK))
 		return;
-	}
 
-	/*
-	 * Delay Controls based on DIMM loading. UGH!
-	 * # of Devices = Module Width (SPD6) / Device Width(SPD13) * Physical Banks(SPD5)
-	 * Note - We only support module width of 64.
+	/* Delay Controls based on DIMM loading. UGH!
+	 * Number of devices = module width (SPD 6) / device width (SPD 13)
+	 *                     * physical banks (SPD 5)
+	 *
+	 * Note: We only support a module width of 64.
 	 */
-	spdbyte0 = spd_read_byte(DIMM0, SPD_PRIMARY_SDRAM_WIDTH);
+	dimms = 0;
+	spdbyte0 = spd_read_byte(dimm0, SPD_PRIMARY_SDRAM_WIDTH);
 	if (spdbyte0 != 0xFF) {
-		spdbyte0 = (unsigned char)64 / spdbyte0 *
-		    (unsigned char)(spd_read_byte(DIMM0, SPD_NUM_DIMM_BANKS));
+		dimms++;
+		spdbyte0 = (u8)64 / spdbyte0 *
+			   (u8)(spd_read_byte(dimm0, SPD_NUM_DIMM_BANKS));
 	} else {
 		spdbyte0 = 0;
 	}
 
-	spdbyte1 = spd_read_byte(DIMM1, SPD_PRIMARY_SDRAM_WIDTH);
+	spdbyte1 = spd_read_byte(dimm1, SPD_PRIMARY_SDRAM_WIDTH);
 	if (spdbyte1 != 0xFF) {
-		spdbyte1 = (unsigned char)64 / spdbyte1 *
-		    (unsigned char)(spd_read_byte(DIMM1, SPD_NUM_DIMM_BANKS));
+		dimms++;
+		spdbyte1 = (u8)64 / spdbyte1 *
+			   (u8)(spd_read_byte(dimm1, SPD_NUM_DIMM_BANKS));
 	} else {
 		spdbyte1 = 0;
 	}
 
-/* The current thinking. Subject to change...
-
-;								   "FUTURE ROBUSTNESS" PROPOSAL
-;								   ----------------------------
-;		DIMM	 Max MBUS					   MC 0x2000001A bits 26:24
-;DIMMs	devices	 Frequency	 MCP 0x4C00000F Setting		 vvv
-;-----	-------	 ---------	 ----------------------	 ----------
-;1		 4		 400MHz		 0x82*100FF 0x56960004		  4
-;1		 8		 400MHz		 0x82*100AA 0x56960004		  4
-;1		 16		 400MHz		 0x82*10055 0x56960004		  4
-;
-;2		 4,4	 400MHz		 0x82710000 0x56960004		  4
-;
-;1		 4		 <=333MHz	 0x83*100FF 0x56960004		  3
-;1		 8		 <=333MHz	 0x83*100AA 0x56960004		  3
-;1		 16		 <=333MHz	 0x83*100AA 0x56960004		  3
-;
-;2		 4,4	 <=333MHz	 0x837100A5 0x56960004		  3
-;2		 8,8	 <=333MHz	 0x937100A5 0x56960004		  3
-;
-;=========================================================================
-;* - Bit 55 (disable SDCLK 1,3,5) should be set if there is a single DIMM in slot 0,
-;	 but it should be clear for all 2 DIMM settings and if a single DIMM is in slot 1.
-;	 Bits 54:52 should always be set to '111'.
-
-;No VTT termination
-;-------------------------------------
-;ADDR/CTL have 22 ohm series R
-;DQ/DQM/DQS have 33 ohm series R
-;
-;		DIMM	 Max MBUS
-;DIMMs	devices	 Frequency	 MCP 0x4C00000F Setting
-;-----	-------	 ---------	 ----------------------
-;1		 4		 400MHz		 0xF2F100FF 0x56960004		  4			The No VTT changes improve timing.
-;1		 8		 400MHz		 0xF2F100FF 0x56960004		  4
-;1		 4		 <=333MHz	 0xF2F100FF 0x56960004		  3
-;1		 8		 <=333MHz	 0xF2F100FF 0x56960004		  3
-;1		 16		 <=333MHz	 0xF2F100FF 0x56960004		  3
-*/
+	/* Zero GLCP_DELAY_CONTROLS MSR */
 	msr.hi = msr.lo = 0;
 
-	if (spdbyte0 == 0 || spdbyte1 == 0) {
-		/* one dimm solution */
-		if (spdbyte1 == 0) {
-			msr.hi |= 0x000800000;
-		}
-		spdbyte0 += spdbyte1;
-		if (spdbyte0 > 8) {
-			/* large dimm */
-			if (glspeed < 334) {
-				msr.hi |= 0x0837100AA;
-				msr.lo |= 0x056960004;
-			} else {
-				msr.hi |= 0x082710055;
-				msr.lo |= 0x056960004;
-			}
-		} else if (spdbyte0 > 4) {
-			/* medium dimm */
-			if (glspeed < 334) {
-				msr.hi |= 0x0837100AA;
-				msr.lo |= 0x056960004;
-			} else {
-				msr.hi |= 0x0827100AA;
-				msr.lo |= 0x056960004;
-			}
-		} else {
-			/* small dimm */
-			if (glspeed < 334) {
-				msr.hi |= 0x0837100FF;
-				msr.lo |= 0x056960004;
-			} else {
-				msr.hi |= 0x0827100FF;
-				msr.lo |= 0x056960004;
-			}
-		}
-	} else {
-		/* two dimm solution */
-		spdbyte0 += spdbyte1;
-		if (spdbyte0 > 24) {
-			/* huge dimms */
-			if (glspeed < 334) {
-				msr.hi |= 0x0B37100A5;
-				msr.lo |= 0x056960004;
-			} else {
-				msr.hi |= 0x0B2710000;
-				msr.lo |= 0x056960004;
-			}
-		} else if (spdbyte0 > 16) {
-			/* large dimms */
-			if (glspeed < 334) {
-				msr.hi |= 0x0B37100A5;
-				msr.lo |= 0x056960004;
-			} else {
-				msr.hi |= 0x0B27100A5;
-				msr.lo |= 0x056960004;
-			}
-		} else if (spdbyte0 >= 8) {
-			/* medium dimms */
-			if (glspeed < 334) {
-				msr.hi |= 0x0937100A5;
-				msr.lo |= 0x056960004;
-			} else {
-				msr.hi |= 0x0C27100A5;
-				msr.lo |= 0x056960004;
-			}
-		} else {
-			/* small dimms */
+	/* Save some power, disable clock to second DIMM if it is empty. */
+	if (spdbyte1 == 0)
+		msr.hi |= DELAY_UPPER_DISABLE_CLK135;
+
+	spdbyte0 += spdbyte1;
+
+	if ((dimms == 1) && (terminated == DRAM_TERMINATED)) {
+		msr.hi = 0xF2F100FF;
+		msr.lo = 0x56960004;
+	} else for (i = 0; i < ARRAY_SIZE(delay_control_table); i++) {
+		if ((dimms == delay_control_table[i].dimms) &&
+		    (spdbyte0 <= delay_control_table[i].devices)) {
 			if (glspeed < 334) {
-				msr.hi |= 0x0837100A5;
-				msr.lo |= 0x056960004;
+				msr.hi |= delay_control_table[i].slow_hi;
+				msr.lo |= delay_control_table[i].slow_low;
 			} else {
-				msr.hi |= 0x082710000;
-				msr.lo |= 0x056960004;
+				msr.hi |= delay_control_table[i].fast_hi;
+				msr.lo |= delay_control_table[i].fast_low;
 			}
+			break;
 		}
 	}
-	print_debug("Try to write GLCP_DELAY_CONTROLS: hi ");
-	print_debug_hex32(msr.hi);
-	print_debug(" and lo ");
-	print_debug_hex32(msr.lo);
-	print_debug("\n");
 	wrmsr(GLCP_DELAY_CONTROLS, msr);
-	print_debug("SetDelayControl done\n");
-	return;
 }
 
 /* ***************************************************************************/
 /* *	cpuRegInit*/
 /* ***************************************************************************/
-void cpuRegInit(void)
+void cpuRegInit(int debug_clock_disable, u8 dimm0, u8 dimm1, int terminated)
 {
 	int msrnum;
 	msr_t msr;
@@ -259,7 +215,7 @@
 
 	/* Set the Delay Control in GLCP */
 	print_debug("Set the Delay Control in GLCP\n");
-	SetDelayControl();
+	SetDelayControl(dimm0, dimm1, terminated);
 
 	/*  Enable RSDC */
 	print_debug("Enable RSDC\n");
@@ -294,12 +250,12 @@
 
 	/* Disable the debug clock to save power. */
 	/* NOTE: leave it enabled for fs2 debug */
-#if 0
-	msrnum = GLCP_DBGCLKCTL;
-	msr.hi = 0;
-	msr.lo = 0;
-	wrmsr(msrnum, msr);
-#endif
+	if (debug_clock_disable && 0) {
+		msrnum = GLCP_DBGCLKCTL;
+		msr.hi = 0;
+		msr.lo = 0;
+		wrmsr(msrnum, msr);
+	}
 
 	/* Setup throttling delays to proper mode if it is ever enabled. */
 	print_debug("Setup throttling delays to proper mode\n");

Modified: trunk/src/cpu/amd/model_lx/msrinit.c
==============================================================================
--- trunk/src/cpu/amd/model_lx/msrinit.c	Thu Jun 10 06:06:52 2010	(r5628)
+++ trunk/src/cpu/amd/model_lx/msrinit.c	Thu Jun 10 17:24:57 2010	(r5629)
@@ -18,13 +18,9 @@
  */
 
 #include <stdlib.h>
+#include "cpu/x86/msr.h"
 
-struct msrinit {
-	u32 msrnum;
-	msr_t msr;
-};
-
-static const struct msrinit msr_table[] =
+static const msrinit_t msr_table[] =
 {
 	{CPU_RCONF_DEFAULT, {.hi = 0x24fffc02,.lo = 0x1000A000}}, /* Setup access to cache under 1MB.
 								   * Rom Properties: Write Serialize, WriteProtect.
@@ -49,7 +45,7 @@
 {
 	int i;
 	for (i = 0; i < ARRAY_SIZE(msr_table); i++)
-		wrmsr(msr_table[i].msrnum, msr_table[i].msr);
+		wrmsr(msr_table[i].index, msr_table[i].msr);
 }
 
 

Modified: trunk/src/include/cpu/amd/lxdef.h
==============================================================================
--- trunk/src/include/cpu/amd/lxdef.h	Thu Jun 10 06:06:52 2010	(r5628)
+++ trunk/src/include/cpu/amd/lxdef.h	Thu Jun 10 17:24:57 2010	(r5629)
@@ -623,9 +623,16 @@
 #define SMM_OFFSET	0x80400000	/* above 2GB */
 #define SMM_SIZE	128			/* changed SMM_SIZE from 256 KB to 128 KB */
 
+/* DRAM_TERMINATED affects how the DELAY register is set. */
+#define DRAM_TERMINATED 'T'
+#define DRAM_UNTERMINATED 't'
+/* Bitfield definitions for the DELAY register */
+#define DELAY_UPPER_DISABLE_CLK135	(1 << 23)
+#define DELAY_LOWER_STATUS_MASK		0x7C0
+
 #if !defined(__ROMCC__)  && !defined(ASSEMBLY)
 #if defined(__PRE_RAM__)
-void cpuRegInit(void);
+void cpuRegInit(int debug_clock_disable, u8 dimm0, u8 dimm1, int terminated);
 void SystemPreInit(void);
 #endif
 void cpubug(void);

Modified: trunk/src/include/cpu/x86/msr.h
==============================================================================
--- trunk/src/include/cpu/x86/msr.h	Thu Jun 10 06:06:52 2010	(r5628)
+++ trunk/src/include/cpu/x86/msr.h	Thu Jun 10 17:24:57 2010	(r5629)
@@ -23,6 +23,12 @@
 	unsigned hi;
 } msr_t;
 
+typedef struct msrinit_struct 
+{
+        unsigned index;
+        msr_t msr;
+} msrinit_t;
+
 static inline msr_t rdmsr(unsigned index)
 {
 	msr_t result;

Modified: trunk/src/mainboard/amd/db800/romstage.c
==============================================================================
--- trunk/src/mainboard/amd/db800/romstage.c	Thu Jun 10 06:06:52 2010	(r5628)
+++ trunk/src/mainboard/amd/db800/romstage.c	Thu Jun 10 17:24:57 2010	(r5629)
@@ -44,8 +44,8 @@
 }
 
 #define ManualConf 0		/* Do automatic strapped PLL config */
-#define PLLMSRhi 0x00001490	/* Manual settings for the PLL */
-#define PLLMSRlo 0x02000030
+#define PLLMSRhi 0x000005DD	/* Manual settings for the PLL */
+#define PLLMSRlo 0x00DE60EE
 #define DIMM0 0xA0
 #define DIMM1 0xA2
 
@@ -88,7 +88,7 @@
 
 	pll_reset(ManualConf);
 
-	cpuRegInit();
+	cpuRegInit(0, DIMM0, DIMM1, DRAM_TERMINATED);
 
 	sdram_initialize(1, memctrl);
 

Modified: trunk/src/mainboard/amd/norwich/romstage.c
==============================================================================
--- trunk/src/mainboard/amd/norwich/romstage.c	Thu Jun 10 06:06:52 2010	(r5628)
+++ trunk/src/mainboard/amd/norwich/romstage.c	Thu Jun 10 17:24:57 2010	(r5629)
@@ -19,6 +19,7 @@
  */
 
 #include <stdint.h>
+#include <stdlib.h>
 #include <device/pci_def.h>
 #include <arch/io.h>
 #include <device/pnp_def.h>
@@ -88,7 +89,7 @@
 
 	pll_reset(ManualConf);
 
-	cpuRegInit();
+	cpuRegInit(0, DIMM0, DIMM1, DRAM_TERMINATED);
 
 	sdram_initialize(1, memctrl);
 

Modified: trunk/src/mainboard/artecgroup/dbe61/romstage.c
==============================================================================
--- trunk/src/mainboard/artecgroup/dbe61/romstage.c	Thu Jun 10 06:06:52 2010	(r5628)
+++ trunk/src/mainboard/artecgroup/dbe61/romstage.c	Thu Jun 10 17:24:57 2010	(r5629)
@@ -109,7 +109,7 @@
 
 	pll_reset(ManualConf);
 
-	cpuRegInit();
+	cpuRegInit(0, DIMM0, DIMM1, DRAM_TERMINATED);
 
 	sdram_initialize(1, memctrl);
 

Modified: trunk/src/mainboard/digitallogic/msm800sev/romstage.c
==============================================================================
--- trunk/src/mainboard/digitallogic/msm800sev/romstage.c	Thu Jun 10 06:06:52 2010	(r5628)
+++ trunk/src/mainboard/digitallogic/msm800sev/romstage.c	Thu Jun 10 17:24:57 2010	(r5629)
@@ -1,4 +1,5 @@
 #include <stdint.h>
+#include <stdlib.h>
 #include <device/pci_def.h>
 #include <arch/io.h>
 #include <device/pnp_def.h>
@@ -69,7 +70,7 @@
 
 	pll_reset(ManualConf);
 
-	cpuRegInit();
+	cpuRegInit(0, DIMM0, DIMM1, DRAM_TERMINATED);
 
 	sdram_initialize(1, memctrl);
 

Modified: trunk/src/mainboard/iei/pcisa-lx-800-r10/romstage.c
==============================================================================
--- trunk/src/mainboard/iei/pcisa-lx-800-r10/romstage.c	Thu Jun 10 06:06:52 2010	(r5628)
+++ trunk/src/mainboard/iei/pcisa-lx-800-r10/romstage.c	Thu Jun 10 17:24:57 2010	(r5629)
@@ -19,6 +19,7 @@
  */
 
 #include <stdint.h>
+#include <stdlib.h>
 #include <device/pci_def.h>
 #include <arch/io.h>
 #include <device/pnp_def.h>
@@ -92,7 +93,7 @@
 
 	pll_reset(ManualConf);
 
-	cpuRegInit();
+	cpuRegInit(0, DIMM0, DIMM1, DRAM_TERMINATED);
 
 	sdram_initialize(1, memctrl);
 

Modified: trunk/src/mainboard/lippert/roadrunner-lx/romstage.c
==============================================================================
--- trunk/src/mainboard/lippert/roadrunner-lx/romstage.c	Thu Jun 10 06:06:52 2010	(r5628)
+++ trunk/src/mainboard/lippert/roadrunner-lx/romstage.c	Thu Jun 10 17:24:57 2010	(r5629)
@@ -122,7 +122,7 @@
 
 	pll_reset(ManualConf);
 
-	cpuRegInit();
+	cpuRegInit(0, DIMM0, DIMM1, DRAM_TERMINATED);
 
 	sdram_initialize(1, memctrl);
 

Modified: trunk/src/mainboard/lippert/spacerunner-lx/romstage.c
==============================================================================
--- trunk/src/mainboard/lippert/spacerunner-lx/romstage.c	Thu Jun 10 06:06:52 2010	(r5628)
+++ trunk/src/mainboard/lippert/spacerunner-lx/romstage.c	Thu Jun 10 17:24:57 2010	(r5629)
@@ -184,7 +184,7 @@
 
 	pll_reset(ManualConf);
 
-	cpuRegInit();
+	cpuRegInit(0, DIMM0, DIMM1, DRAM_TERMINATED);
 
 	/* bit1 = on-board IDE is slave, bit0 = Spread Spectrum */
 	if ((err = smc_send_config(SMC_CONFIG))) {

Modified: trunk/src/mainboard/pcengines/alix1c/romstage.c
==============================================================================
--- trunk/src/mainboard/pcengines/alix1c/romstage.c	Thu Jun 10 06:06:52 2010	(r5628)
+++ trunk/src/mainboard/pcengines/alix1c/romstage.c	Thu Jun 10 17:24:57 2010	(r5629)
@@ -18,6 +18,7 @@
  */
 
 #include <stdint.h>
+#include <stdlib.h>
 #include <spd.h>
 #include <device/pci_def.h>
 #include <arch/io.h>
@@ -148,7 +149,7 @@
 
 	pll_reset(ManualConf);
 
-	cpuRegInit();
+	cpuRegInit(0, DIMM0, DIMM1, DRAM_TERMINATED);
 
 	sdram_initialize(1, memctrl);
 

Modified: trunk/src/mainboard/traverse/geos/romstage.c
==============================================================================
--- trunk/src/mainboard/traverse/geos/romstage.c	Thu Jun 10 06:06:52 2010	(r5628)
+++ trunk/src/mainboard/traverse/geos/romstage.c	Thu Jun 10 17:24:57 2010	(r5629)
@@ -88,7 +88,7 @@
 
 	pll_reset(ManualConf);
 
-	cpuRegInit();
+	cpuRegInit(0, DIMM0, DIMM1, DRAM_TERMINATED);
 
 	sdram_initialize(1, memctrl);
 

Modified: trunk/src/mainboard/winent/pl6064/romstage.c
==============================================================================
--- trunk/src/mainboard/winent/pl6064/romstage.c	Thu Jun 10 06:06:52 2010	(r5628)
+++ trunk/src/mainboard/winent/pl6064/romstage.c	Thu Jun 10 17:24:57 2010	(r5629)
@@ -90,7 +90,7 @@
 
 	pll_reset(ManualConf);
 
-	cpuRegInit();
+	cpuRegInit(0, DIMM0, DIMM1, DRAM_TERMINATED);
 
 	sdram_initialize(1, memctrl);
 



From ward at gnu.org  Thu Jun 10 17:28:48 2010
From: ward at gnu.org (Ward Vandewege)
Date: Thu, 10 Jun 2010 11:28:48 -0400
Subject: [coreboot] [h8dme-fam10] acquiring coreboot skills from scratch
 somewhat daunting
In-Reply-To: <20100610151028.GA7194@tsunami.ccur.com>
References: <20100610133805.GA3452@tsunami.ccur.com>
	<AANLkTikGu31lG0fKp0Y2cGg7zDe1W27VVx-MP07PGnVC@mail.gmail.com>
	<4C10FC2E.6040705@gap.upv.es>
	<20100610151028.GA7194@tsunami.ccur.com>
Message-ID: <20100610152848.GA17772@countzero.vandewege.net>

On Thu, Jun 10, 2010 at 11:10:28AM -0400, Joe Korty wrote:
> >> Ward and others have tried this board in the past. 

Yeah - I still have a test setup and need to get back to this soon. I'm just
tied up with too much other stuff. Bleh.

> There seems to be
> >> something wrong with multi-core setup for K10.
> 
> > I think that why Ward had problems with this CPU family is for the same
> > reason why I had problems with it on different boards, the resource map!
> > I started using the one from the h8dme fam 10 board. So maybe you should
> > try another resource map from another fam 10 board.
> 
> >> If you search the mailing list for "h8dme fam10", it might give you
> >> some help.  I would disable all the other processors until you get the
> >> board working.
> 
> >> Qemu and SimNOW are both helpful, too.  SimNOW exhibits the same
> >> problems for fam10 as hardware (super slow initialization and problems
> >> with logical CPUs), so fixing it there would probably help.
> 
> Myles and Knut,
> Thanks!  I'll probe these ideas and see what happens.
> 
> Another data point: It _does_ continue after the hang, but it takes about
> an hour. 

Oh! That's interesting. I never tried to leave the board alone for that long.

> I image each memory write is timing out so a bunch of writes via
> memset drags the total timeout to an hour.  At that point we try to load
> the payload so it seems that I am really really close to the end here....

It does sound like it. 

Thanks,
Ward.

-- 
Ward Vandewege <ward at fsf.org>
Free Software Foundation - Senior Systems Administrator



From svn at coreboot.org  Thu Jun 10 17:40:18 2010
From: svn at coreboot.org (repository service)
Date: Thu, 10 Jun 2010 17:40:18 +0200
Subject: [coreboot] build service results for r5629
Message-ID: <E1OMjre-0004mj-59@ra.coresystems.de>

Dear coreboot readers!

This is the automatic build system of coreboot.

The developer "monofin" checked in revision 5629 to
the coreboot repository. This caused the following 
changes:

Change Log:
This commit updates the Geode LX GLCP delay control setup from the v2 way to the v3 way.
This resolves problems with terminated DRAM modules.
Signed-off-by: Edwin Beasant <edwin_beasant at virtensys.com>
Acked-by: Roland G. Minnich <rminnich at gmail.com>



Build Log:
Compilation of traverse:geos has been broken
See the error log at http://qa.coreboot.org/log_buildbrd.php?revision=5629&device=geos&vendor=traverse&num=2


If something broke during this checkin please be a pain 
in monofin'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 joe at settoplinux.org  Thu Jun 10 17:51:57 2010
From: joe at settoplinux.org (Joseph Smith)
Date: Thu, 10 Jun 2010 11:51:57 -0400
Subject: [coreboot] Re  PATCH: ECS P6IWP-Fe
In-Reply-To: <4C100A21.3000700@settoplinux.org>
References: <0M7I3a-1PFqm13SdC-00x3vi@mx.perfora.net>
	<fb238673d64fb2b07e0ec7b85ed69eac@imap.1and1.com>
	<4C100A21.3000700@settoplinux.org>
Message-ID: <711038347ea3f88128ae425246e0ee6a@imap.1and1.com>




On Wed, 09 Jun 2010 17:39:45 -0400, Joseph Smith <joe at settoplinux.org>
wrote:
> On 06/09/2010 12:01 PM, Joseph Smith wrote:
>>
>>
>>
>> On Wed, 09 Jun 2010 16:26:31 +0200, "anders at jenbo.dk"<anders at jenbo.dk>
>> wrote:
>>> Agreed, the only reason I haven't done car yet is that I haven't had a
>>> board where the best match to copy from used CAR. I defiantly hav plans
>> for
>>> updating all the boards I have to car but I am waiting til I hit a
board
>>> where car is the best match or I run out if board / easy targets.
>>>
>>> By then I might help out with porting the 440bx boards (is 440lx
> below?).
>>>
>> No worries CAR for i810/socket_370 will be coming on the next few days
> :-)
>> I am really excited to get rid of that model_6xx clump-o-crap.
>>
> Anders in case your curious, I will be porting the Intel D810E2CB.
> 
> 
Update: Almost done with this port :-) It will be done today.
I should write a blog about porting your board in 48 hours or less :-)

My 1GHz PIII FC-PGA Copermine is not supported yet, so what better way to
kick off CAR for Socket 370 :-)

Anyways, then I can dig out my box of 370's and start testing and sending
CAR patches for all of them.

Oh, Anders don't forget to update wiki with your new port.


-- 
Thanks,
Joseph Smith
Set-Top-Linux
www.settoplinux.org




From svn at coreboot.org  Thu Jun 10 18:19:03 2010
From: svn at coreboot.org (repository service)
Date: Thu, 10 Jun 2010 18:19:03 +0200
Subject: [coreboot] [commit] r5630 - trunk/src/mainboard/traverse/geos
Message-ID: <E1OMkT9-0000Rc-89@ra.coresystems.de>

Author: monofin
Date: Thu Jun 10 18:19:02 2010
New Revision: 5630
URL: https://tracker.coreboot.org/trac/coreboot/changeset/5630

Log:
Fix a missing include file that was breaking the Traverse Geos build.

Signed-off-by: Edwin Beasant <edwin_beasant at virtensys.com>
Acked-by: Edwin Beasant <edwin_beasant at virtensys.com>

Modified:
   trunk/src/mainboard/traverse/geos/romstage.c

Modified: trunk/src/mainboard/traverse/geos/romstage.c
==============================================================================
--- trunk/src/mainboard/traverse/geos/romstage.c	Thu Jun 10 17:24:57 2010	(r5629)
+++ trunk/src/mainboard/traverse/geos/romstage.c	Thu Jun 10 18:19:02 2010	(r5630)
@@ -19,6 +19,7 @@
  */
 
 #include <stdint.h>
+#include <stdlib.h>
 #include <device/pci_def.h>
 #include <arch/io.h>
 #include <device/pnp_def.h>



From svn at coreboot.org  Thu Jun 10 18:32:54 2010
From: svn at coreboot.org (repository service)
Date: Thu, 10 Jun 2010 18:32:54 +0200
Subject: [coreboot] build service results for r5630
Message-ID: <E1OMkgY-0002oU-HZ@ra.coresystems.de>

Dear coreboot readers!

This is the automatic build system of coreboot.

The developer "monofin" checked in revision 5630 to
the coreboot repository. This caused the following 
changes:

Change Log:
Fix a missing include file that was breaking the Traverse Geos build.

Signed-off-by: Edwin Beasant <edwin_beasant at virtensys.com>
Acked-by: Edwin Beasant <edwin_beasant at virtensys.com>


Build Log:
Compilation of traverse:geos has been fixed


If something broke during this checkin please be a pain 
in monofin'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 mbertens at xs4all.nl  Thu Jun 10 20:13:43 2010
From: mbertens at xs4all.nl (mbertens)
Date: Thu, 10 Jun 2010 20:13:43 +0200
Subject: [coreboot] unable to boot linux with coreboot
In-Reply-To: <AANLkTinByqVUaavWHsFHcrjNhe_zTqKZZKAlyJl4Z32w@mail.gmail.com>
References: <1276026925.3803.54.camel@andrala.reboot>
	<AANLkTinByqVUaavWHsFHcrjNhe_zTqKZZKAlyJl4Z32w@mail.gmail.com>
Message-ID: <1276193623.4023.2.camel@andrala.reboot>

On Wed, 2010-06-09 at 08:25 -0600, Myles Watson wrote:
> On Tue, Jun 8, 2010 at 1:55 PM, mbertens <mbertens at xs4all.nl> wrote:
> > Hi all,
> >
> > i have a strong problem that im not able to boot any os wit coreboot, it
> > starts (linux) ut it hangs after 128 sec.
> >
> > http://pastebin.com/uBT8JdH4
> >
> > Anyone any ideas
> I think you'd get a better response if you gave a little more information:
> 
> 1. Have you ever been able to boot Linux with Coreboot?  If yes, what
> revision?  Have you checked to see what revision broke it?
> 
> 2.  What loader are you using?  I know I could tell by going to the
> link, but more information in the mail helps generate interest enough
> to follow the link.
> 
> 3....  Anything else you think is relevant.
> 
> Thanks,
> Myles

I was able to boot coreboot, with multiple revisions but none of the
will boot anymore, bacially like the boot log i provided, but i'm lost
at the moment. I don't known any more where to look for the problem.

I'm currently booting the latest revision, that was ok, and also an
earlier revistion was booting fine, but now not any more.



Marc 




From mylesgw at gmail.com  Thu Jun 10 20:25:16 2010
From: mylesgw at gmail.com (Myles Watson)
Date: Thu, 10 Jun 2010 12:25:16 -0600
Subject: [coreboot] unable to boot linux with coreboot
In-Reply-To: <1276193623.4023.2.camel@andrala.reboot>
References: <1276026925.3803.54.camel@andrala.reboot>
	<AANLkTinByqVUaavWHsFHcrjNhe_zTqKZZKAlyJl4Z32w@mail.gmail.com>
	<1276193623.4023.2.camel@andrala.reboot>
Message-ID: <AANLkTimIJoTAHDUAb9DAeouL_EorypnlKbeBQdA1iCdt@mail.gmail.com>

On Thu, Jun 10, 2010 at 12:13 PM, mbertens <mbertens at xs4all.nl> wrote:
> On Wed, 2010-06-09 at 08:25 -0600, Myles Watson wrote:
>> On Tue, Jun 8, 2010 at 1:55 PM, mbertens <mbertens at xs4all.nl> wrote:
>> > Hi all,
>> >
>> > i have a strong problem that im not able to boot any os wit coreboot, it
>> > starts (linux) ut it hangs after 128 sec.
>> >
>> > http://pastebin.com/uBT8JdH4
>> >
>> > Anyone any ideas
>> I think you'd get a better response if you gave a little more information:
>>
>> 1. Have you ever been able to boot Linux with Coreboot? ?If yes, what
>> revision? ?Have you checked to see what revision broke it?
>>
>> 2. ?What loader are you using? ?I know I could tell by going to the
>> link, but more information in the mail helps generate interest enough
>> to follow the link.
>>
>> 3.... ?Anything else you think is relevant.
>>
>> Thanks,
>> Myles
>
> I was able to boot coreboot, with multiple revisions but none of the
> will boot anymore, bacially like the boot log i provided, but i'm lost
> at the moment. I don't known any more where to look for the problem.
>
> I'm currently booting the latest revision, that was ok, and also an
> earlier revistion was booting fine, but now not any more.

Do you have an earlier (working) log to compare with?

Have you always gotten these errors?
ERROR: PNP: 03f0.7 60 io size: 0x0000000001 not assigned
ERROR: PNP: 03f0.7 62 io size: 0x0000000001 not assigned
ERROR: PNP: 03f0.7 70 irq size: 0x0000000001 not assigned
ERROR: PNP: 03f0.7 72 irq size: 0x0000000001 not assigned

Thanks,
Myles



From mylesgw at gmail.com  Thu Jun 10 20:31:04 2010
From: mylesgw at gmail.com (Myles Watson)
Date: Thu, 10 Jun 2010 12:31:04 -0600
Subject: [coreboot] unable to boot linux with coreboot
In-Reply-To: <AANLkTimIJoTAHDUAb9DAeouL_EorypnlKbeBQdA1iCdt@mail.gmail.com>
References: <1276026925.3803.54.camel@andrala.reboot><AANLkTinByqVUaavWHsFHcrjNhe_zTqKZZKAlyJl4Z32w@mail.gmail.com><1276193623.4023.2.camel@andrala.reboot>
	<AANLkTimIJoTAHDUAb9DAeouL_EorypnlKbeBQdA1iCdt@mail.gmail.com>
Message-ID: <8D4BA30875194CE6B70388C538077DEC@chimp>

> >> > Anyone any ideas
Have you tried to boot the factory BIOS?  Are these all cold boots?  Did
cold boot always work?

Thanks,
Myles




From arne.gleditsch at numascale.com  Thu Jun 10 21:00:41 2010
From: arne.gleditsch at numascale.com (Arne Georg Gleditsch)
Date: Thu, 10 Jun 2010 21:00:41 +0200
Subject: [coreboot] [h8dme-fam10] acquiring coreboot skills from scratch
	somewhat daunting
In-Reply-To: <20100610151028.GA7194@tsunami.ccur.com> (Joe Korty's message of
	"Thu, 10 Jun 2010 11:10:28 -0400")
References: <20100610133805.GA3452@tsunami.ccur.com>
	<AANLkTikGu31lG0fKp0Y2cGg7zDe1W27VVx-MP07PGnVC@mail.gmail.com>
	<4C10FC2E.6040705@gap.upv.es> <20100610151028.GA7194@tsunami.ccur.com>
Message-ID: <87ljamemqu.fsf@taniquetil.gledits.ch>

Joe Korty <joe.korty at ccur.com> writes:
> Myles and Knut,
> Thanks!  I'll probe these ideas and see what happens.
>
> Another data point: It _does_ continue after the hang, but it takes about
> an hour.  I image each memory write is timing out so a bunch of writes via
> memset drags the total timeout to an hour.  At that point we try to load
> the payload so it seems that I am really really close to the end here....

This sounds kinda familiar.  Can you check if it is related to
http://article.gmane.org/gmane.linux.bios/57707 -- do the patches there
help any?

-- 
							Arne.



From joe.korty at ccur.com  Thu Jun 10 21:10:28 2010
From: joe.korty at ccur.com (Joe Korty)
Date: Thu, 10 Jun 2010 15:10:28 -0400
Subject: [coreboot] [h8dme-fam10] acquiring coreboot skills from scratch
 somewhat daunting
In-Reply-To: <87ljamemqu.fsf@taniquetil.gledits.ch>
References: <20100610133805.GA3452@tsunami.ccur.com>
	<AANLkTikGu31lG0fKp0Y2cGg7zDe1W27VVx-MP07PGnVC@mail.gmail.com>
	<4C10FC2E.6040705@gap.upv.es>
	<20100610151028.GA7194@tsunami.ccur.com>
	<87ljamemqu.fsf@taniquetil.gledits.ch>
Message-ID: <20100610191028.GA31944@tsunami.ccur.com>

On Thu, Jun 10, 2010 at 03:00:41PM -0400, Arne Georg Gleditsch wrote:
> Joe Korty <joe.korty at ccur.com> writes:
> > Myles and Knut,
> > Thanks!  I'll probe these ideas and see what happens.
> >
> > Another data point: It _does_ continue after the hang, but it takes about
> > an hour.  I image each memory write is timing out so a bunch of writes via
> > memset drags the total timeout to an hour.  At that point we try to load
> > the payload so it seems that I am really really close to the end here....
> 
> This sounds kinda familiar.  Can you check if it is related to
> http://article.gmane.org/gmane.linux.bios/57707 -- do the patches there
> help any?


Doesn't look like it.  We are getting hosed (consuming an hour's worth of time)
between the printk of 'Clearing memory...' and the printk of 'Done.'  The only
thing between those two printk's is a memset.

Joe



From joe.korty at ccur.com  Thu Jun 10 22:31:56 2010
From: joe.korty at ccur.com (Joe Korty)
Date: Thu, 10 Jun 2010 16:31:56 -0400
Subject: [coreboot] [h8dme-fam10] acquiring coreboot skills from scratch
 somewhat daunting
In-Reply-To: <87hblaeldq.fsf@taniquetil.gledits.ch>
References: <20100610133805.GA3452@tsunami.ccur.com>
	<AANLkTikGu31lG0fKp0Y2cGg7zDe1W27VVx-MP07PGnVC@mail.gmail.com>
	<4C10FC2E.6040705@gap.upv.es>
	<20100610151028.GA7194@tsunami.ccur.com>
	<87ljamemqu.fsf@taniquetil.gledits.ch>
	<20100610191028.GA31944@tsunami.ccur.com>
	<87hblaeldq.fsf@taniquetil.gledits.ch>
Message-ID: <20100610203156.GA3826@tsunami.ccur.com>

On Thu, Jun 10, 2010 at 03:30:09PM -0400, Arne Georg Gleditsch wrote:
> Joe Korty <joe.korty at ccur.com> writes:
> >> This sounds kinda familiar.  Can you check if it is related to
> >> http://article.gmane.org/gmane.linux.bios/57707 -- do the patches there
> >> help any?
> >
> > Doesn't look like it.  We are getting hosed (consuming an hour's worth of time)
> > between the printk of 'Clearing memory...' and the printk of 'Done.'  The only
> > thing between those two printk's is a memset.
> 
> I believe there's a patch to memset there too, unless I've pasted the
> wrong URL?  I saw what appeared to be dramatic performance issues,
> presumably related to instruction cache misses/refetches in the memset
> code.  (The impact is likely related to how the alignment turns out as
> well as the latency over the SB towards ROM.)
> 
> I'm not sure a northbridge timeout on write to coherent memory would be
> benign enough to let you continue going gracefully...  Either way, it'd
> be interesting to know if modifying the code itself helps any.

Hi Arne,
First first applied only the memset change then I applied the whole patch.

The memset-only change did indeed speed up the memset.  It is now
instantaeous.  The speedup seems too great to me, it implies that I've
no-oped memset somehow.

Then I applied the whole patch.  I had to change the "#if CONFIG_ARCH_X86"
to "#if 1" as CONFIG_ARCH_X86 doesn't seem to be set.  With that single
change to your patch I see a speed-up to 'no delays, anywhere'; but now
the execution patch is quite a bit different, we are in a warm reset
infinite loop.

Anyways your patch made a difference .......
Thanks,
Joe



From arne.gleditsch at numascale.com  Thu Jun 10 21:30:09 2010
From: arne.gleditsch at numascale.com (Arne Georg Gleditsch)
Date: Thu, 10 Jun 2010 21:30:09 +0200
Subject: [coreboot] [h8dme-fam10] acquiring coreboot skills from scratch
	somewhat daunting
In-Reply-To: <20100610191028.GA31944@tsunami.ccur.com> (Joe Korty's message of
	"Thu, 10 Jun 2010 15:10:28 -0400")
References: <20100610133805.GA3452@tsunami.ccur.com>
	<AANLkTikGu31lG0fKp0Y2cGg7zDe1W27VVx-MP07PGnVC@mail.gmail.com>
	<4C10FC2E.6040705@gap.upv.es> <20100610151028.GA7194@tsunami.ccur.com>
	<87ljamemqu.fsf@taniquetil.gledits.ch>
	<20100610191028.GA31944@tsunami.ccur.com>
Message-ID: <87hblaeldq.fsf@taniquetil.gledits.ch>

Joe Korty <joe.korty at ccur.com> writes:
>> This sounds kinda familiar.  Can you check if it is related to
>> http://article.gmane.org/gmane.linux.bios/57707 -- do the patches there
>> help any?
>
> Doesn't look like it.  We are getting hosed (consuming an hour's worth of time)
> between the printk of 'Clearing memory...' and the printk of 'Done.'  The only
> thing between those two printk's is a memset.

I believe there's a patch to memset there too, unless I've pasted the
wrong URL?  I saw what appeared to be dramatic performance issues,
presumably related to instruction cache misses/refetches in the memset
code.  (The impact is likely related to how the alignment turns out as
well as the latency over the SB towards ROM.)

I'm not sure a northbridge timeout on write to coherent memory would be
benign enough to let you continue going gracefully...  Either way, it'd
be interesting to know if modifying the code itself helps any.

-- 
							Arne.



From joe.korty at ccur.com  Thu Jun 10 23:10:43 2010
From: joe.korty at ccur.com (Joe Korty)
Date: Thu, 10 Jun 2010 17:10:43 -0400
Subject: [coreboot] [h8dme-fam10] acquiring coreboot skills from scratch
 somewhat daunting
In-Reply-To: <87d3vyehri.fsf@taniquetil.gledits.ch>
References: <20100610133805.GA3452@tsunami.ccur.com>
	<AANLkTikGu31lG0fKp0Y2cGg7zDe1W27VVx-MP07PGnVC@mail.gmail.com>
	<4C10FC2E.6040705@gap.upv.es>
	<20100610151028.GA7194@tsunami.ccur.com>
	<87ljamemqu.fsf@taniquetil.gledits.ch>
	<20100610191028.GA31944@tsunami.ccur.com>
	<87hblaeldq.fsf@taniquetil.gledits.ch>
	<20100610203156.GA3826@tsunami.ccur.com>
	<87d3vyehri.fsf@taniquetil.gledits.ch>
Message-ID: <20100610211043.GA15209@tsunami.ccur.com>

On Thu, Jun 10, 2010 at 04:48:17PM -0400, Arne Georg Gleditsch wrote:
> Joe Korty <joe.korty at ccur.com> writes:
> > Hi Arne,
> > First first applied only the memset change then I applied the whole patch.
> >
> > The memset-only change did indeed speed up the memset.  It is now
> > instantaeous.  The speedup seems too great to me, it implies that I've
> > no-oped memset somehow.
> 
> Well, RAMTOP is what, 16MB?  DDR2 (peak) transfer rates are 100-500
> times that per second.  There's reason that memset operation should be
> taking any noticeable amount of time.
> 
> > Then I applied the whole patch.  I had to change the "#if CONFIG_ARCH_X86"
> > to "#if 1" as CONFIG_ARCH_X86 doesn't seem to be set.  With that single
> > change to your patch I see a speed-up to 'no delays, anywhere'; but now
> > the execution patch is quite a bit different, we are in a warm reset
> > infinite loop.
> 
> That's interesting.  What's happening at the end there, before the warm
> reset?


Hi Arnie,
I've looked more closely; I first see a warm reset (which is normal) followed
by an infinite series of soft resets (which are new).  Here is the first part
of the log, containing the warm reset and two of thesoft resets.

Still digesting this new development, myself.....

Regards,
Joe


coreboot-4.0-r5628M Thu Jun 10 16:21:49 EDT 2010 starting...

Coreboot configured for H8DME-2 with K10 AMD processors
BSP Family_Model: 00100f42 
*sysinfo range: [000cc000,000cdfa0]
bsp_apicid = 00 
cpu_init_detectedx = 00000000 
microcode: equivalent rev id  = 0x1041, current patch id = 0x00000000
microcode: rev id (1062) does not match this patch.
microcode: Not updated! Fix microcode_updates[] 
cpuSetAMDMSR  done
Enter amd_ht_init()
AMD_CB_EventNotify()
 event class: 05
 event: 1004
 data:  04  00  00  01 
AMD_CB_ManualBUIDSwapList()
AMD_CB_EventNotify()
 event class: 05
 event: 2006
 data:  04  00  02  ff 
Exit amd_ht_init()
cpuSetAMDPCI 00 done
cpuSetAMDPCI 01 done
Prep FID/VID Node:00 
  F3x80: e600a681 
  F3x84: a0e641e6 
  F3xD4: c3310f24 
  F3xD8: 03001615 
  F3xDC: 00005322 
Prep FID/VID Node:01 
  F3x80: e600a681 
  F3x84: a0e641e6 
  F3xD4: c3310f24 
  F3xD8: 03001615 
  F3xDC: 00005322 
setup_remote_node: 01 done
Start node 01 done.
core0 started:  core0:  --- { APICID = 04 NODEID = 01 COREID = 00} ---
crm1i
v ostcaordet:_ oteqhueri_vcaloernest( r)e
c iniidt   =n od0ex1:0 4001 ,  ccuorrersen:t  03p at
 hSt aird t= o t0hx0e0r0 c0o00r0e0 -
2nmiodceriocdo: d0e:0  r ceovr ieds : (01036
.)i ndoiets  nnoodte :m 0a1t ch  ctohriess :p a0t3c h
S
ptamirctr ooctohdeer:  cNoorte  u-p dnaotdeeid!d :F i0x1  m iccorroecso:d e0_3u
    a attccceaooorsrrr[etee]xexx :d::
        -p--c-p- -a--u-S p  i{{e{tc   AiAAAMdPPPD:IIIM CCCSIIIDDDR    ===    000OOO32n   eNNN
   DDDEEEiIIInDDDit   _===f   i000d000v   iCCCdOOO_RRRaEEEpIII(DDDs   t===a   0gc0e3211}}})    ------ap---


 cs i*ccc ooodAmmm:iPiirrre c cceex0rrxx0r:o1oo::4 cc 
 AuuA uA  -dd-F-ad-re-ee-I-:::-D-t  V e   {d{{Ieeeqq Dq 
eeae0007vrvP*PiiIv IvvInCaaC CaAIAIlPIllDePDe De n0 n n: =t2=t=t s     0rtr4r
  DE E E   v65      tNiNNieidddOdOOD D
         I*=I=I=D   D D 0  0A0=Pxx==x 1  11 00000001341414 1 s1 1C,C,Ct, aO O ORe=crRcEuEuEuterIrIrIDrdrDrD e  e
ddnn==n t tt 00   01ppp32aaa}}} tt  t-cc--c-h-hh--   --
  d

      *===    mmmi0A0ii0cxcxPxcr0r0r0 o00o0o0c0c05c0o0o0o0st0d0d0de0ea0e0:0:0:r0eeeq 0 
    q

uummmiii
        iiivcvcc*var ararloloAloecececPno nonotdtd0td   6eeer:sr::re e te vrvrvrd d= = =ivivtivd d d edi i i  d 
         (* ( ( 011 010x0xx00A16P61160202 204)4)4)01 71 1 ,d,ds,d o o otaecececut rsusr r rt nernrnreoodeoentnntt
m papapa m
tct     atatta
   cctchchcBh eh h h t tg tihihihinididid s s s = = F = Ip p p0a0Da0axtxtxVtcI0c0000h0hD0h0.0.0. M
  S
   0
xr  00m00mRm0 ii00i0c00cc0
 c
  oo
    oc0ccmmmooiio0ic1ddccdrer0eero::o:o0c7c  c oNo1oNNoodod d0ttetee: ::  x 3uu u rpr0ppreddedebv0vaava t 0 tteeiei0idaddddd !3  !!(  (  (101FF1F0i0x0iixx6x6462o2  2 )m)0)mmii i 3 d5ccdcdoroo0rreoooee4s0scccs o   oonddndn
 oeeoet_tt__FuIuu   mmpDppmadaadVdIaatattccDttcthehh ee sss  ottnt[[[h]]h h]i i  iBsSs

  P 
_AA ppp,ccca apppatutAtuuSScScPchIeeheh.t..Ctt
 i
  MMM
ccooomDmdmDDMMiMi:ic cSScSrRr0rRRoo0o   c
P    dddeee   :::dd  d NoNoNoononontetteeB 

 u
  uupp piiidnndfdnaiaiiaitdttttt__e e_efffd=dd!! !iii dd 1 dFvFvvF0i6iiiiixddx0xmamaappim
        ipicc(((cWrrrasssotttooictcaaacogo oggeededfdeoe11e1_)_r_))  u u upAaapa13pddPppaiiiaa tstcccteieteiisddsdsa[g[::[:] ]e]  00 0   

:



 cccpaFFFppuuupIIISDDSS_DeaVeVVetItpItIADADAiD cM M MDoDoiDoMnMnMnd  S S SRA=ARA P PP   ::1:  
n000   d1dd32oo

 n
  neee


        riiinenniiaitdtt___bfaffiicidkddvvv i=iiddd _1__aaa0p1pp(((0s6sstt0ta1aaegg
aee111  )))c o  aaampmppiioicncciii_dfdd::i: d  000(5p76
 c

: FFFkIeIIDDDdV)VVIII D=DD    o1oonn0n 6  AAA0P0PP::
i   0W006a57
 t

   for AP stage 1: ap_apicid = 2
        readback = 2010601
        common_fid(packed) = 10600
Wait for AP stage 1: ap_apicid = 3
        readback = 3010601
        common_fid(packed) = 10600
Wait for AP stage 1: ap_apicid = 4
        readback = 4010601
        common_fid(packed) = 10600
Wait for AP stage 1: ap_apicid = 5
        readback = 5010601
        common_fid(packed) = 10600
Wait for AP stage 1: ap_apicid = 6
        readback = 6010601
        common_fid(packed) = 10600
Wait for AP stage 1: ap_apicid = 7
        readback = 7010601
        common_fid(packed) = 10600
common_fid = 10600
FID Change Node:00, F3xD4: c3310f26 
FID Change Node:01, F3xD4: c3310f26 
End FIDVIDMSR 0xc0010071 0x30b000a3 0x38035040 
mcp55_num:01
...WARM RESET...




coreboot-4.0-r5628M Thu Jun 10 16:21:49 EDT 2010 starting...

Coreboot configured for H8DME-2 with K10 AMD processors
BSP Family_Model: 00100f42 
*sysinfo range: [000cc000,000cdfa0]
bsp_apicid = 00 
cpu_init_detectedx = 00000000 
microcode: equivalent rev id  = 0x1041, current patch id = 0x00000000
microcode: rev id (1062) does not match this patch.
microcode: Not updated! Fix microcode_updates[] 
cpuSetAMDMSR  done
Enter amd_ht_init()
AMD_CB_EventNotify()
 event class: 05
 event: 1004
 data:  04  00  00  01 
AMD_CB_ManualBUIDSwapList()
AMD_CB_EventNotify()
 event class: 05
 event: 2006
 data:  04  00  02  ff 
Exit amd_ht_init()
cpuSetAMDPCI 00 done
cpuSetAMDPCI 01 done
Prep FID/VID Node:00 
  F3x80: e600a681 
  F3x84: a0e641e6 
  F3xD4: c3310f26 
  F3xD8: 03001615 
  F3xDC: 00005322 
Prep FID/VID Node:01 
  F3x80: e600a681 
  F3x84: a0e641e6 
  F3xD4: c3310f26 
  F3xD8: 03001615 
  F3xDC: 00005322 
setup_remote_node: 01 done
Start node 01 done.
core0 started:  01
start_other_cores()
init node:  c0o0r  ec0:o re s-:- -0 3{  A
3SICtIaDrt  =o th0e4r N OcoDrEeI D -= n o0d1 eCiOd:R E0ID0  =  c0o0re}s -:- -0

imnicirto cnooddee::  e0q1 ui cvaolreenst:  r0e3v  
 dS t a=r t0 xo1t0h4e1r,  ccourrer e-n tn opdaeticdh:  i0d1  =  c0oxr0e0s0:0 00000
sccc
    tooomiarrreecrexxrtxo::e:c  d o    da---ep :--- a---rp   ei{{{vc    iAAAidPPPd:III  CCC(III1DDD0   6===2   ) d000132o   eNNNsO OOnDDDoEEEItIIDDD m   a===t   c000h000    tCCChOOOiRRRsEEE IIIpDDDa   t===c   h000.312}}}
o  m---i---c---r


 c*   occcd mmmeAoiiioorccr:Prce rerre ooxNx0ox:1c:cc:o ot so otdd d   --aee-ue- ueu uAiiAd- -t e a eeetq{q{d{q 
          Aid!PvvP*PvI Ia IaaCllCAClFIPeiIeeIDnnDD nxt0  tt    == 2m=is rr  receDevvrva00056  7o rcit  ii NddNodeNd dOO  OD  De 
 =EE==E_  Iu* IID0D00Dp  xdA x x=1=1=1aPt0  0 0 0440e4003111111s,, [s,  C C  C]trR aOcOcRuuRu
  rtEErrEIrrIIrecDedDeeDpnn u n
dd   =S=  e    0ppt0p023aaA1a}t}ttM}  c ccD--h-hMh- - - SR-i--ii
      

0o0   ===*     00Am0mmdxxPixiic0co00 c000rr0rno0oe005oc0sc0c
  t0o0toa0dd0d0ier0e0ne0i0:0:t0:

 d
mmmuieqfqq
     iuiuiidicic*c rrvvvrviaoaAooacPcldlcleoeo oe_n0dsndndttt6teeeas:  ::   rgt  di  erreeeev2ervv t vv  vi a iei dddidipi d d
dd1      c=(i=(*=( 1 1 1d 00:0A000x66x6 xP021 12210))04)004 74  4
ettnn 1,ot,oo,ee  ea csrcsscu tu  urnernnrrodrooreet
tm a an  tmtm
a      atptptp
 cacactBhththc e c chhtgtht  hih hiiiiniidsds sd     F =p=p=pI a a aD0Vt0t0txIcx0000hDh0h00. .0.00
   S
    0
oc   0m0mRm000i0i i00c0c0c0r0r0rx
  0c
    c
     co0oommmid1iiddcee0ccer::0rr:o   7oocNNN1ccooooo odddttt0   eeexuuu:3:: ppp 0 rdddrbreeaaae0vvtttv0 0 eee iiaiddddd3d!!!       (F(0(FF1i1x1ii0xx030x6  686  dddnen)iii)3) ccc 5 ddrrrd0o4oooooe0ecccess sooo  
       neeo_oo__tuuuttEpppn   mddddmmaaaaa attttttFccceeeIhDhhsss V  [[[t]Itt]]hsiih  i

 Sss
MM    R cccppppp paauuua0txtSSStccceeechh0httt.A.0.AA
  DD
    0
     DmMMm0mMiSSSi7iccRRRc1r rr   o0oocccxo3ooddd0   dddeebe:ooo::0 nnn  0N0eeeNoott3


     t    iiiuuu0nnnpppxiiidtdd3tta_aa8__tfftt0feiiee0idddd2ddv8vv!!!0iii   F8ddsssx  __iixx
      ttt mmmaaamggiiigccpeeccer522rr2o 5  oocca_aacoopnppoddduiiiececcme_i_ii:_d d  a00a:p::1d
es       a0t21tt3e
  s

   s[[[]]]   


cccpppuuuSSSeeetttAAAMMMDDDMMMSSSRRR      dddooonnneee


iiinnniiittt___fffiiidddvvviiiddd___ssstttaaagggeee222   aaapppiiiccciiiddd:::   000567


fill_mem_ctrl()
raminit_amdmct()
raminit_amdmct begin:
 Node: 01  base: 00  limit: 7fffff  BottomIO: e00000
 Copy dram map from Node 0 to Node 01 
raminit_amdmct end:
v_esp=000cbee8
testx = 5a5a5a5a
Copying data from cache to RAM -- switching to use RAM as stack... Done
testx = 5a5a5a5a
Disabling cache as ram now 
Clearing initial memory region: Done
Loading stage image.
Check CBFS header at fffff8da
magic is 4f524243
Found CBFS header at fffff8da
Check fallback/romstage
CBFS: follow chain: fff00000 + 38 + 124d4 + align -> fff12540
Check fallback/coreboot_ram
Stage: loading fallback/coreboot_ram @ 0x200000 (1179648 bytes), entry @ 0x200000



INIT detected from  --- { APICID = 00 NODEID = 00 COREID = 00} ---

Issuing SOFT_RESET...


coreboot-4.0-r5628M Thu Jun 10 16:21:49 EDT 2010 starting...

Coreboot configured for H8DME-2 with K10 AMD processors
BSP Family_Model: 00100f42 
*sysinfo range: [000cc000,000cdfa0]
bsp_apicid = 00 
cpu_init_detectedx = 00000000 
microcode: equivalent rev id  = 0x1041, current patch id = 0x00000000
microcode: rev id (1062) does not match this patch.
microcode: Not updated! Fix microcode_updates[] 
cpuSetAMDMSR  done
Enter amd_ht_init()
AMD_CB_EventNotify()
 event class: 05
 event: 1004
 data:  04  00  00  01 
AMD_CB_ManualBUIDSwapList()
AMD_CB_EventNotify()
 event class: 05
 event: 2006
 data:  04  00  02  ff 
Exit amd_ht_init()
cpuSetAMDPCI 00 done
cpuSetAMDPCI 01 done
Prep FID/VID Node:00 
  F3x80: e600a681 
  F3x84: a0e641e6 
  F3xD4: c3310f26 
  F3xD8: 03001615 
  F3xDC: 00005322 
Prep FID/VID Node:01 
  F3x80: e600a681 
  F3x84: a0e641e6 
  F3xD4: c3310f26 
  F3xD8: 03001615 
  F3xDC: 00005322 
setup_remote_node: 01 done
Start node 01 done.
core0 started:  01
start_other_cores()
 nit node: 0 0 c orceor0e: s:  -0--3  {
-SAtPIaCrtI Do =t her 0c4 oNreO D-EI Dno d= e0i1d:  CO0R0 EI cDo =r es0:0}  0-3
i-
 nit mnicordoec:o 0d1e :  ceqoureisv:a l0e3n t
 rSetva ritd  o t=h e0rx 1c0o4r1e,  -c unrordeenitd :p a0t1c h  ciodr e=s :0 x0000
rre0  sc0tcoc00aoror
   etexexx:mid:: c    ra  op---c ---oa---dp   {i{{e: c   AiAArPdPPeI:IIvC CC IIIiDDDd    ===(   1060001232)    NNNdOOOoDDDeEEEsIII DDDn   o===t    000m000a   tC---OOOhRRR EEEtIIIhDDDi   s===    p000a321}}}tc   h----.--
m


    i*ccc coooAmmrrrrmiieieeoPxccxxc crr::o0r: o d1o ocescc   -o-o-o:t-d a-d-dNeuuPPupt: : : o{  { {te   d eeeAqqAAqu
      PiiIIid*ICCva CvvIatAIaaIDlePDllD  ee  ed=n=n!=0n tt  2t F  s trirr000xeeeD DDr v5v tm     ieiiNiNNdddOdOOc 
       E EEo I==IIc=*  DDo  D 0 d0A 0=xexP=x=_11  1  0000000u341411p4 11  d1s,,Cnn==CO Ot aO RcecrRcRsuutEuEErreIrII[drDrDD]r ee   e
 = t 
ii   t t0  0 0c3pp2p1p}u}a}aa tt S t-e-c-cc-hh-t-h-A- -  
 D
  d
   dd  M *=S== R  mmm iA000ii cPxcxxcr00rr 0 00do00ooo5c00cc0os00oo0n0t0dd0ed0aee0:r:0
eneeeq:00 t0 00 i
      q
       diq
uummmi_i  ut
        iiiifc*vvccv raarrailolooldAecccevPeoooni nnddtd0ttd _6  eees:srr::rete d  dd  rrvar ree ge vtvievii ed2 dd  d i  iia
       ==  =p * (( (i 10110c0x000xixA6661d1P1220:0 024) 404))0 171  1,ds,dd,4to  ceeec
tttnn  tttsuururtr   rrernnnrooeedeon
mmm  papp   
ccttct   aaatatta
      chBhhcc  hhh e tgtt  hhiiihidiniidd s  s s= F = = p  pIp0aDa0a0xtxxtVt0cIc0000h00hDh0. .0.00
 S
  0
rxr00m00mRm0i i0i00c00c0c
o

 ococ0ccmmmooiiio0cd1ddccrerre0eo:0:o:oc cc 7 oN1NoNododdo o0ttteee:: :  x uu3u  rprrpp0eddbedevavvaa0 tt0 t ieiiee0ddadddd 3!  !!(  (  (10F11FF0ii0xi063x66xx2 dne 2)0m))mm ii 0i d2cddccorro8roe0oeeoosccs8cs  o  oonddn
   ooeeot__t_t uu u Emmnppmpddadaadtt aatattctccFhhIeehe ss  DsttV[t[[h]]hhI]iiD  S s
    

MMM pppRcccpppaa at0tuuutSSSccxchcheeehttt..0.

   1
    m0mDDDmMMMii0ic7cSSScRRrr1rRo oo   cc0cooxodd3d  ee0e :bddd:: o  0ooN0nnNnNott 0ee
     
     3
       uuuiiipnpnn0piixddidatatt3a__8tt_tefeff0eii0iddd!!d!dd2vv8  v FFiFii0dd8i  s mmtmttss
          aaiiaimcccgcggreerpreo5o2o22c  c5c o_oaoaadppdndpeueeiiiccc_m__u:uiiiua00tt0pd1d:::d   aa
[s   t0e312ees
 [

  []]]   


cccpppuuuSSSeeetttAAAMMMDDDMMMSSSRRR      dddooonnneee


iiinnniiittt___fffiiidddvvviiiddd___ssstttaaagggeee222   aaapppiiiccciiiddd:::   000576


fill_mem_ctrl()
raminit_amdmct()
raminit_amdmct begin:
 Node: 01  base: 00  limit: 7fffff  BottomIO: e00000
 Copy dram map from Node 0 to Node 01 
raminit_amdmct end:
v_esp=000cbee8
testx = 5a5a5a5a
Copying data from cache to RAM -- switching to use RAM as stack... Done
testx = 5a5a5a5a
Disabling cache as ram now 
Clearing initial memory region: 


INIT detected from  --- { APICID = 00 NODEID = 00 COREID = 00} ---

Issuing SOFT_RESET...


coreboot-4.0-r5628M Thu Jun 10 16:21:49 EDT 2010 starting...

Coreboot configured for H8DME-2 with K10 AMD processors
BSP Family_Model: 00100f42 
*sysinfo range: [000cc000,000cdfa0]
bsp_apicid = 00 
cpu_init_detectedx = 00000000 
microcode: equivalent rev id  = 0x1041, current patch id = 0x00000000
microcode: rev id (1062) does not match this patch.
microcode: Not updated! Fix microcode_updates[] 
cpuSetAMDMSR  done
Enter amd_ht_init()
AMD_CB_EventNotify()
 event class: 05
 event: 1004
 data:  04  00  00  01 
AMD_CB_ManualBUIDSwapList()
AMD_CB_EventNotify()
 event class: 05
 event: 2006
 data:  04  00  02  ff 
Exit amd_ht_init()
cpuSetAMDPCI 00 done
cpuSetAMDPCI 01 done
Prep FID/VID Node:00 
  F3x80: e600a681 
  F3x84: a0e641e6 
  F3xD4: c3310f26 
  F3xD8: 03001615 
  F3xDC: 00005322 
Prep FID/VID Node:01 
  F3x80: e600a681 
  F3x84: a0e641e6 
  F3xD4: c3310f26 
  F3xD8: 03001615 
  F3xDC: 00005322 
setup_remote_node: 01 done
Start node 01 done.
core0 started:  01
start_other_cores()
 nit node: 0 0c  ocreo0re:s : - 0-3-  {
 SAtPaICrIt Do =t her 0c4 oNreO DE-I nDo d= e0id1: C O00R EI Dco r=e 0s0: }0 -3-
i
rnit mnicordoec:o 0d1e :  ceqourievsa:l e0n3t  
 eSvt airdt   o=t h0exr1 0c4o1r,e  c-u rnroedneti dp:a t0c1h   icdo r=e s0:x 00000
teee sc0tcc0aooo0rrrr
    exxx:d::mi    ca   rp-o-- ac---po---  di ec{{{:  i  AAdArPP:PeII IvCCC IIIiDDDd    ===(   1060002132)    NNNdOOOoDDDeEEEsIII DDDn   o===t    000m000a   tCCCcOOOhRRR EEEtIIIhDDDi   s===    p000a213t}}}   ch------.---



mi *   cccArcoommmoorriiiPreeccc cxxrrr0oe:ooo1dx:cccse:  oot: o  --ddda  -eeerNuuup A-:::-e     t{d{  eee qqqu{ 
      AiidAP*PiavPI IvvIaCACaatIlPIlleCD eeIDed!D n 0nn=t=2tt    s  F= irtrr xeaDDDr  E vrvv7 m t    iieiiNNNdddOOOcd 
       EEo   I*Ic===ID o   DDdA000   xPxx===e11   _1 0000u000141p4341 1d1s1  a,,e   nn a OOOtrccRRRecEuEEsutuIrI[rerIDr]rdrDD ee
tt    n===
iiiddd000   c21p3ppp}aaa}}u  S ttt-ccc--e--t-hhh   --A-

      D
0e00ere:00:t: ===RmmAm    iiPic000c crxxxr0r 00o5odo0c0scoc00t0ono00od0ed00da
iq           000 e  0in000edeeq


 uu
   tuii*_immmvv fviiiaAiacccadPlrrrlleoooeev cccnni0noottd6to d _s ddrstrreeetae       a  iii trrr g eeeeieiivdvd2ddv 
             p==ddd*=       i0Ac00(((iPxx111x1 10001d006660:027224 44)s)1011), 4d  dda cocoorc
ee            ueeetuurrssserrr   drennn
ttt nnoottt
a        pmmmpp
 aaaaattttBttceccccchhhhghh i     ttiiintd hhhddii   Fi=Isss==    D  0Vpp0p0xaxx00atDt0t000c00c cMhh0h000.0S..0
  0
    
c   0m000m0m0i0iix0cc
 r
  r0r
     o0oommmiccc1iic0ccooordddr0ro7ooeee:::c1cco oo   NNNd0ddoooexee:3:ttt:    0  rbuuurrppeee0pv0dddvv a  0aaiattitidedd3ee    ddd(!(!0(!x 1 1 10F03F0F6ii6i682no02xx)  ) )0 m 2 mmdiidid8oc0occoerreer8so soos cc  c
  noonddoodoeettetEn__  _ mumduump paapatdtdFdtaIccacahthttDhVe  e etstsIst[Dhh[  p]]]MiiS sss   
   pp

tt1AA0a0aacccxpttptpcuucucchShhSS0.ee0.e.
      A

       mMmmMM0DD7iDiicMccMM1SS rSrroRoRR0ocxcc   ooo3d0ddeebe:0::    ddd 0 No0NN  onnonao3etteet 
 0uu

dx_ uppxpiii3ndnnddiiaa8iat0ttttte_e_0e_f2ffddd!!i!i8i0dd  d FvF8vvFi iiiiixdxd
     _ _msmssmmtticiticpacaacggrr5gro5eoeeo22cc_2c no  ooaaddaudmpeppee__:_iiiuc::a:apip1piidddddd
]    att  t e00ee0ss3s21[[
 ]

  ]   


cccpppuuuSSSeeetttAAAMMMDDDMMMSSSRRR      dddooonnneee


iiinnniiittt___fffiiidddvvviiiddd___ssstttaaagggeee222   aaapppiiiccciiiddd:::   000765


fill_mem_ctrl()
raminit_amdmct()
raminit_amdmct begin:
 Node: 01  base: 00  limit: 7fffff  BottomIO: e00000
 Copy dram map from Node 0 to Node 01 
raminit_amdmct end:
v_esp=000cbee8
testx = 5a5a5a5a
Copying data from cache to RAM -- switching to use RAM as stack... Done
testx = 5a5a5a5a
Disabling cache as ram now 
Clearing initial memory region: 


INIT detected from  --- { APICID = 00 NODEID = 00 COREID = 00} ---

Issuing SOFT_RESET...


coreboot-4.0-r5628M Thu Jun 10 16:21:49 EDT 2010 starting...

Coreboot configured for H8DME-2 with K10 AMD processors



From arne.gleditsch at numascale.com  Thu Jun 10 22:48:17 2010
From: arne.gleditsch at numascale.com (Arne Georg Gleditsch)
Date: Thu, 10 Jun 2010 22:48:17 +0200
Subject: [coreboot] [h8dme-fam10] acquiring coreboot skills from scratch
	somewhat daunting
In-Reply-To: <20100610203156.GA3826@tsunami.ccur.com> (Joe Korty's message of
	"Thu, 10 Jun 2010 16:31:56 -0400")
References: <20100610133805.GA3452@tsunami.ccur.com>
	<AANLkTikGu31lG0fKp0Y2cGg7zDe1W27VVx-MP07PGnVC@mail.gmail.com>
	<4C10FC2E.6040705@gap.upv.es> <20100610151028.GA7194@tsunami.ccur.com>
	<87ljamemqu.fsf@taniquetil.gledits.ch>
	<20100610191028.GA31944@tsunami.ccur.com>
	<87hblaeldq.fsf@taniquetil.gledits.ch>
	<20100610203156.GA3826@tsunami.ccur.com>
Message-ID: <87d3vyehri.fsf@taniquetil.gledits.ch>

Joe Korty <joe.korty at ccur.com> writes:
> Hi Arne,
> First first applied only the memset change then I applied the whole patch.
>
> The memset-only change did indeed speed up the memset.  It is now
> instantaeous.  The speedup seems too great to me, it implies that I've
> no-oped memset somehow.

Well, RAMTOP is what, 16MB?  DDR2 (peak) transfer rates are 100-500
times that per second.  There's reason that memset operation should be
taking any noticeable amount of time.

> Then I applied the whole patch.  I had to change the "#if CONFIG_ARCH_X86"
> to "#if 1" as CONFIG_ARCH_X86 doesn't seem to be set.  With that single
> change to your patch I see a speed-up to 'no delays, anywhere'; but now
> the execution patch is quite a bit different, we are in a warm reset
> infinite loop.

That's interesting.  What's happening at the end there, before the warm
reset?

-- 
							Arne.



From arne.gleditsch at numascale.com  Thu Jun 10 23:21:44 2010
From: arne.gleditsch at numascale.com (Arne Georg Gleditsch)
Date: Thu, 10 Jun 2010 23:21:44 +0200
Subject: [coreboot] [h8dme-fam10] acquiring coreboot skills from scratch
	somewhat daunting
In-Reply-To: <20100610211043.GA15209@tsunami.ccur.com> (Joe Korty's message of
	"Thu, 10 Jun 2010 17:10:43 -0400")
References: <20100610133805.GA3452@tsunami.ccur.com>
	<AANLkTikGu31lG0fKp0Y2cGg7zDe1W27VVx-MP07PGnVC@mail.gmail.com>
	<4C10FC2E.6040705@gap.upv.es> <20100610151028.GA7194@tsunami.ccur.com>
	<87ljamemqu.fsf@taniquetil.gledits.ch>
	<20100610191028.GA31944@tsunami.ccur.com>
	<87hblaeldq.fsf@taniquetil.gledits.ch>
	<20100610203156.GA3826@tsunami.ccur.com>
	<87d3vyehri.fsf@taniquetil.gledits.ch>
	<20100610211043.GA15209@tsunami.ccur.com>
Message-ID: <878w6meg7r.fsf@taniquetil.gledits.ch>

Joe Korty <joe.korty at ccur.com> writes:
> I've looked more closely; I first see a warm reset (which is normal) followed
> by an infinite series of soft resets (which are new).  Here is the first part
> of the log, containing the warm reset and two of thesoft resets.
>
> Still digesting this new development, myself.....
>
[..]
> raminit_amdmct()
> raminit_amdmct begin:
>  Node: 01  base: 00  limit: 7fffff  BottomIO: e00000

Looks like coreboot only finds memory on node 01.  Not sure if that's
supposed to work or not, but I'd be surprised if it did.  I assume you
have memory installed on node 00 as well?  You mentioned spd earlier,
and this seems like a likely symptom of coreboot failing to detect the
spd roms on socket 0.  You might want to enable CONFIG_DEBUG_RAM_SETUP
to get some more data.

-- 
							Arne.



From joe.korty at ccur.com  Thu Jun 10 23:26:21 2010
From: joe.korty at ccur.com (Joe Korty)
Date: Thu, 10 Jun 2010 17:26:21 -0400
Subject: [coreboot] [h8dme-fam10] acquiring coreboot skills from scratch
 somewhat daunting
In-Reply-To: <878w6meg7r.fsf@taniquetil.gledits.ch>
References: <AANLkTikGu31lG0fKp0Y2cGg7zDe1W27VVx-MP07PGnVC@mail.gmail.com>
	<4C10FC2E.6040705@gap.upv.es>
	<20100610151028.GA7194@tsunami.ccur.com>
	<87ljamemqu.fsf@taniquetil.gledits.ch>
	<20100610191028.GA31944@tsunami.ccur.com>
	<87hblaeldq.fsf@taniquetil.gledits.ch>
	<20100610203156.GA3826@tsunami.ccur.com>
	<87d3vyehri.fsf@taniquetil.gledits.ch>
	<20100610211043.GA15209@tsunami.ccur.com>
	<878w6meg7r.fsf@taniquetil.gledits.ch>
Message-ID: <20100610212621.GA17456@tsunami.ccur.com>

On Thu, Jun 10, 2010 at 05:21:44PM -0400, Arne Georg Gleditsch wrote:
> Joe Korty <joe.korty at ccur.com> writes:
> > I've looked more closely; I first see a warm reset (which is normal) followed
> > by an infinite series of soft resets (which are new).  Here is the first part
> > of the log, containing the warm reset and two of thesoft resets.
> >
> > Still digesting this new development, myself.....
> >
> [..]
> > raminit_amdmct()
> > raminit_amdmct begin:
> >  Node: 01  base: 00  limit: 7fffff  BottomIO: e00000
> 
> Looks like coreboot only finds memory on node 01.  Not sure if that's
> supposed to work or not, but I'd be surprised if it did.  I assume you
> have memory installed on node 00 as well?

Yes I do.  When I stick K8's in and compile coreboot accordingly, it all
works.

> You mentioned spd earlier,
> and this seems like a likely symptom of coreboot failing to detect the
> spd roms on socket 0.  You might want to enable CONFIG_DEBUG_RAM_SETUP
> to get some more data.

I will!
Thanks,
Joe



From joe.korty at ccur.com  Thu Jun 10 23:31:18 2010
From: joe.korty at ccur.com (Joe Korty)
Date: Thu, 10 Jun 2010 17:31:18 -0400
Subject: [coreboot] [h8dme-fam10] acquiring coreboot skills from scratch
 somewhat daunting
In-Reply-To: <878w6meg7r.fsf@taniquetil.gledits.ch>
References: <AANLkTikGu31lG0fKp0Y2cGg7zDe1W27VVx-MP07PGnVC@mail.gmail.com>
	<4C10FC2E.6040705@gap.upv.es>
	<20100610151028.GA7194@tsunami.ccur.com>
	<87ljamemqu.fsf@taniquetil.gledits.ch>
	<20100610191028.GA31944@tsunami.ccur.com>
	<87hblaeldq.fsf@taniquetil.gledits.ch>
	<20100610203156.GA3826@tsunami.ccur.com>
	<87d3vyehri.fsf@taniquetil.gledits.ch>
	<20100610211043.GA15209@tsunami.ccur.com>
	<878w6meg7r.fsf@taniquetil.gledits.ch>
Message-ID: <20100610213118.GB17456@tsunami.ccur.com>

On Thu, Jun 10, 2010 at 05:21:44PM -0400, Arne Georg Gleditsch wrote:
> Joe Korty <joe.korty at ccur.com> writes:
> > I've looked more closely; I first see a warm reset (which is normal) followed
> > by an infinite series of soft resets (which are new).  Here is the first part
> > of the log, containing the warm reset and two of thesoft resets.
> >
> > Still digesting this new development, myself.....
> >
> [..]
> > raminit_amdmct()
> > raminit_amdmct begin:
> >  Node: 01  base: 00  limit: 7fffff  BottomIO: e00000
> 
> Looks like coreboot only finds memory on node 01.  Not sure if that's
> supposed to work or not, but I'd be surprised if it did.  I assume you
> have memory installed on node 00 as well?  You mentioned spd earlier,

FYI, the K8 version of the h8dme-2 (which works) has this comment in it.
This comment isn't in the h8dmr version (K8 or K10) nor in the h8qme
K10 version.  I wonder how the K8 version initializes the node 00 bank?
Whatever that is, I think I need it here also.

Regards,
Joe


... from src/mainboard/supermicro/h8dme/romstage.c:

/* We have no idea where the SMBUS switch is. This doesn't do anything ATM. */
#define RC0 (2<<8)
#define RC1 (1<<8)

void cache_as_ram_main(unsigned long bist, unsigned long cpu_init_detectedx)
{
/* The SPD is being read from the CPU1 (marked CPU2 on the board) and we
   don't know how to switch the SMBus to decode the CPU0 SPDs. So, The
   memory on each CPU must be an exact match.
 */
        static const uint16_t spd_addr[] = {




From arne.gleditsch at numascale.com  Thu Jun 10 23:46:24 2010
From: arne.gleditsch at numascale.com (Arne Georg Gleditsch)
Date: Thu, 10 Jun 2010 23:46:24 +0200
Subject: [coreboot] [h8dme-fam10] acquiring coreboot skills from scratch
	somewhat daunting
In-Reply-To: <20100610213118.GB17456@tsunami.ccur.com> (Joe Korty's message of
	"Thu, 10 Jun 2010 17:31:18 -0400")
References: <AANLkTikGu31lG0fKp0Y2cGg7zDe1W27VVx-MP07PGnVC@mail.gmail.com>
	<4C10FC2E.6040705@gap.upv.es> <20100610151028.GA7194@tsunami.ccur.com>
	<87ljamemqu.fsf@taniquetil.gledits.ch>
	<20100610191028.GA31944@tsunami.ccur.com>
	<87hblaeldq.fsf@taniquetil.gledits.ch>
	<20100610203156.GA3826@tsunami.ccur.com>
	<87d3vyehri.fsf@taniquetil.gledits.ch>
	<20100610211043.GA15209@tsunami.ccur.com>
	<878w6meg7r.fsf@taniquetil.gledits.ch>
	<20100610213118.GB17456@tsunami.ccur.com>
Message-ID: <874ohaef2n.fsf@taniquetil.gledits.ch>

Joe Korty <joe.korty at ccur.com> writes:
> FYI, the K8 version of the h8dme-2 (which works) has this comment in it.
> This comment isn't in the h8dmr version (K8 or K10) nor in the h8qme
> K10 version.  I wonder how the K8 version initializes the node 00 bank?
> Whatever that is, I think I need it here also.

Haha, I just had a look and noticed this too.  This appears to be a
massive hack which simply pretends that the SPD addresses of the node 0
banks are the same as the ones for node 1 -- so instead of probing the
banks on both node, the code is in effect probing the banks on node 1
twice.  This is harmless as long as both sockets are identically
populated, but fairly brittle...

To recreate for the fam10 infrastructure, you'll need a somewhat
non-standard spd_addr.h.  Since the addresses you have for the second
node seems to work, you could start with just copying them to the line
representing the first node as well.

But long-term we really should find out how to switch the SMBus between
the different SPD groups.  SerialICE is handy tool for this, for someone
who has the time.

-- 
							Arne.



From buurin at gmail.com  Thu Jun 10 23:21:48 2010
From: buurin at gmail.com (Keith Hui)
Date: Thu, 10 Jun 2010 17:21:48 -0400
Subject: [coreboot] Re PATCH: ECS P6IWP-Fe (Joseph Smith)
Message-ID: <AANLkTiln3luXISBk-gxgPcp9GyOftt1CF3M9PEZkuH6a@mail.gmail.com>

>>> On Wed, 09 Jun 2010 16:26:31 +0200, "anders at jenbo.dk"<anders at jenbo.dk>
>>> wrote:
>>>> Agreed, the only reason I haven't done car yet is that I haven't had a
>>>> board where the best match to copy from used CAR. I defiantly hav plans
>>> for
>>>> updating all the boards I have to car but I am waiting til I hit a
> board
>>>> where car is the best match or I run out if board / easy targets.
>>>>
>>>> By then I might help out with porting the 440bx boards (is 440lx
>> below?).
>>>>
>>> No worries CAR for i810/socket_370 will be coming on the next few days
>> :-)
>>> I am really excited to get rid of that model_6xx clump-o-crap.
>>>
>> Anders in case your curious, I will be porting the Intel D810E2CB.
>>
>>
> Update: Almost done with this port :-) It will be done today.
> I should write a blog about porting your board in 48 hours or less :-)
>
> My 1GHz PIII FC-PGA Copermine is not supported yet, so what better way to
> kick off CAR for Socket 370 :-)
>
> Anyways, then I can dig out my box of 370's and start testing and sending
> CAR patches for all of them.
>
> Oh, Anders don't forget to update wiki with your new port.
>

Just go ahead and enable CAR. It would use the intel CAR code already
in the tree. It works for 6bx. Would be interesting to see if it works
out of the box for Coppermine. The tiny little bit of L1 should be
enough to get things going. ;-) Then it's to see if L2 is enabled
without additional configuration like 6bx.

I did put out patches to support the entire Slot1+370 lineup...



From joe.korty at ccur.com  Thu Jun 10 23:52:47 2010
From: joe.korty at ccur.com (Joe Korty)
Date: Thu, 10 Jun 2010 17:52:47 -0400
Subject: [coreboot] [h8dme-fam10] acquiring coreboot skills from scratch
 somewhat daunting
In-Reply-To: <874ohaef2n.fsf@taniquetil.gledits.ch>
References: <20100610151028.GA7194@tsunami.ccur.com>
	<87ljamemqu.fsf@taniquetil.gledits.ch>
	<20100610191028.GA31944@tsunami.ccur.com>
	<87hblaeldq.fsf@taniquetil.gledits.ch>
	<20100610203156.GA3826@tsunami.ccur.com>
	<87d3vyehri.fsf@taniquetil.gledits.ch>
	<20100610211043.GA15209@tsunami.ccur.com>
	<878w6meg7r.fsf@taniquetil.gledits.ch>
	<20100610213118.GB17456@tsunami.ccur.com>
	<874ohaef2n.fsf@taniquetil.gledits.ch>
Message-ID: <20100610215246.GA19833@tsunami.ccur.com>

On Thu, Jun 10, 2010 at 05:46:24PM -0400, Arne Georg Gleditsch wrote:
> Joe Korty <joe.korty at ccur.com> writes:
> > FYI, the K8 version of the h8dme-2 (which works) has this comment in it.
> > This comment isn't in the h8dmr version (K8 or K10) nor in the h8qme
> > K10 version.  I wonder how the K8 version initializes the node 00 bank?
> > Whatever that is, I think I need it here also.
> 
> Haha, I just had a look and noticed this too.  This appears to be a
> massive hack which simply pretends that the SPD addresses of the node 0
> banks are the same as the ones for node 1 -- so instead of probing the
> banks on both node, the code is in effect probing the banks on node 1
> twice.  This is harmless as long as both sockets are identically
> populated, but fairly brittle...
> 
> To recreate for the fam10 infrastructure, you'll need a somewhat
> non-standard spd_addr.h.  Since the addresses you have for the second
> node seems to work, you could start with just copying them to the line
> representing the first node as well.

Thanks,
I'll play with this tomorrow and see what happens....
Joe



From joe at settoplinux.org  Fri Jun 11 03:29:59 2010
From: joe at settoplinux.org (Joseph Smith)
Date: Thu, 10 Jun 2010 21:29:59 -0400
Subject: [coreboot] Re PATCH: ECS P6IWP-Fe (Joseph Smith)
In-Reply-To: <AANLkTiln3luXISBk-gxgPcp9GyOftt1CF3M9PEZkuH6a@mail.gmail.com>
References: <AANLkTiln3luXISBk-gxgPcp9GyOftt1CF3M9PEZkuH6a@mail.gmail.com>
Message-ID: <4C119197.20305@settoplinux.org>

> I did put out patches to support the entire Slot1+370 lineup...
>
You did? Sorry I must have missed it, can you send it again?

-- 
Thanks,
Joseph Smith
Set-Top-Linux
www.settoplinux.org



From kevin at koconnor.net  Fri Jun 11 04:48:21 2010
From: kevin at koconnor.net (Kevin O'Connor)
Date: Thu, 10 Jun 2010 22:48:21 -0400
Subject: [coreboot] [PATCH] SeaBIOS CD/DVD abbreviations
In-Reply-To: <4C0FE715.4010302@coresystems.de>
References: <4C0F465D.4040901@coresystems.de> <4C0FB6B4.2070906@ziltro.com>
	<4C0FE715.4010302@coresystems.de>
Message-ID: <20100611024821.GB11427@morn.localdomain>

On Wed, Jun 09, 2010 at 09:10:13PM +0200, Stefan Reinauer wrote:
> On 6/9/10 5:43 PM, Andrew Morgan wrote:
> > Just a small point, the "ROM" bit isn't really needed. The fact that
> > CDs are read-only is pretty much irrelevant. No other type of disk
> > gets -ROM or -RAM stuck on the end of it. Also some CDs aren't read
> > only...
> 
> Good point.
> Updated patch attached

Thanks.  Commit 203f6f38.

-Kevin



From kevin at koconnor.net  Fri Jun 11 04:52:02 2010
From: kevin at koconnor.net (Kevin O'Connor)
Date: Thu, 10 Jun 2010 22:52:02 -0400
Subject: [coreboot] [PATCH] SeaBIOS VGA hooks
In-Reply-To: <4C0F4698.6000405@coresystems.de>
References: <4C0F4698.6000405@coresystems.de>
Message-ID: <20100611025202.GC11427@morn.localdomain>

On Wed, Jun 09, 2010 at 09:45:28AM +0200, Stefan Reinauer wrote:
> SeaBIOS VGA hooks for Getac P470 and Roda RK886EX notebooks

Thanks.  Commit 8cb8ba52.

-Kevin



From joe at settoplinux.org  Fri Jun 11 13:30:44 2010
From: joe at settoplinux.org (Joseph Smith)
Date: Fri, 11 Jun 2010 07:30:44 -0400
Subject: [coreboot] Re  PATCH: ECS P6IWP-Fe
In-Reply-To: <711038347ea3f88128ae425246e0ee6a@imap.1and1.com>
References: <0M7I3a-1PFqm13SdC-00x3vi@mx.perfora.net>
	<fb238673d64fb2b07e0ec7b85ed69eac@imap.1and1.com>
	<4C100A21.3000700@settoplinux.org>
	<711038347ea3f88128ae425246e0ee6a@imap.1and1.com>
Message-ID: <000bfa5777c5c9ac28f743c6932741d1@imap.1and1.com>




On Thu, 10 Jun 2010 11:51:57 -0400, Joseph Smith <joe at settoplinux.org>
wrote:
> 
> 
> 
> On Wed, 09 Jun 2010 17:39:45 -0400, Joseph Smith <joe at settoplinux.org>
> wrote:
>> On 06/09/2010 12:01 PM, Joseph Smith wrote:
>>>
>>>
>>>
>>> On Wed, 09 Jun 2010 16:26:31 +0200, "anders at jenbo.dk"<anders at jenbo.dk>
>>> wrote:
>>>> Agreed, the only reason I haven't done car yet is that I haven't had a
>>>> board where the best match to copy from used CAR. I defiantly hav
plans
>>> for
>>>> updating all the boards I have to car but I am waiting til I hit a
> board
>>>> where car is the best match or I run out if board / easy targets.
>>>>
>>>> By then I might help out with porting the 440bx boards (is 440lx
>> below?).
>>>>
>>> No worries CAR for i810/socket_370 will be coming on the next few days
>> :-)
>>> I am really excited to get rid of that model_6xx clump-o-crap.
>>>
>> Anders in case your curious, I will be porting the Intel D810E2CB.
>>
>>
> Update: Almost done with this port :-) It will be done today.
> I should write a blog about porting your board in 48 hours or less :-)
> 
> My 1GHz PIII FC-PGA Copermine is not supported yet, so what better way to
> kick off CAR for Socket 370 :-)
> 
> Anyways, then I can dig out my box of 370's and start testing and sending
> CAR patches for all of them.
> 
Update: I am booting into Linux :-)
Just a few minor things to fix....and then I will be sending a patch for
the Intel D810E2CB by the end of the day :-)

-- 
Thanks,
Joseph Smith
Set-Top-Linux
www.settoplinux.org




From svn at coreboot.org  Fri Jun 11 16:25:41 2010
From: svn at coreboot.org (repository service)
Date: Fri, 11 Jun 2010 16:25:41 +0200
Subject: [coreboot] [commit] r5631 - trunk/payloads/libpayload/drivers/usb
Message-ID: <E1ON5Az-0007FW-25@ra.coresystems.de>

Author: oxygene
Date: Fri Jun 11 16:25:40 2010
New Revision: 5631
URL: https://tracker.coreboot.org/trac/coreboot/changeset/5631

Log:
Follow up to the USB refactoring patch: Missed setting pid values correctly.

Signed-off-by: Patrick Georgi <patrick.georgi at coresystems.de>
Acked-by: Patrick Georgi <patrick.georgi at coresystems.de>

Modified:
   trunk/payloads/libpayload/drivers/usb/uhci.c

Modified: trunk/payloads/libpayload/drivers/usb/uhci.c
==============================================================================
--- trunk/payloads/libpayload/drivers/usb/uhci.c	Thu Jun 10 18:19:02 2010	(r5630)
+++ trunk/payloads/libpayload/drivers/usb/uhci.c	Fri Jun 11 16:25:40 2010	(r5631)
@@ -400,7 +400,11 @@
 fill_schedule (td_t *td, endpoint_t *ep, int length, unsigned char *data,
 	       int *toggle)
 {
-	td->pid = ep->direction;
+	switch (ep->direction) {
+		case IN: td->pid = UHCI_IN; break;
+		case OUT: td->pid = UHCI_OUT; break;
+		case SETUP: td->pid = UHCI_SETUP; break;
+	}
 	td->dev_addr = ep->dev->address;
 	td->endp = ep->endpoint & 0xf;
 	td->maxlen = maxlen (length);
@@ -507,7 +511,11 @@
 		tds[i].queue_head = 0;
 		tds[i].depth_first = 0;
 
-		tds[i].pid = ep->direction;
+		switch (ep->direction) {
+			case IN: tds[i].pid = UHCI_IN; break;
+			case OUT: tds[i].pid = UHCI_OUT; break;
+			case SETUP: tds[i].pid = UHCI_SETUP; break;
+		}
 		tds[i].dev_addr = ep->dev->address;
 		tds[i].endp = ep->endpoint & 0xf;
 		tds[i].maxlen = maxlen (reqsize);



From joe at settoplinux.org  Fri Jun 11 17:46:49 2010
From: joe at settoplinux.org (Joseph Smith)
Date: Fri, 11 Jun 2010 11:46:49 -0400
Subject: [coreboot] Fwd: SCO loses, Novell wins finally
Message-ID: <cb6540593a2270b262e4cfafb976940b@imap.1and1.com>



-------- Original Message --------
Subject: SCO loses, Novell wins finally
Date: Fri, 11 Jun 2010 11:41:23 -0400
From: Jerry Feldman <gaf at blu.org>
To: Greater NH Linux User Group <gnhlug-discuss at mail.gnhlug.org>

Judge Stewart finally ruled against SCO officially closing the case. I
don't believe that SCO can appeal this one, and I fully expect SCO to
subsequently convert to Chapter 7 in the bankruptcy case unless they
want to push the IBM case.

>From Groklaw:
http://www.groklaw.net/article.php?story=20100610161411160

Here you go, munchkins. Judge Ted Stewart has ruled for Novell and
against SCO. Novell's claim for declaratory judgment is granted; SCO's
claims for specific performance and breach of the implied covenant of
good fair and fair dealings are denied. Also SCO's motion for judgment
as a matter of law or for a new trial: denied. SCO is entitled to waive,
at its sole discretion, claims against IBM, Sequent and other SVRX
licensees.

CASE CLOSED! Maybe I should say case_s_ closed. The door has slammed
shut on the SCO litigation machine. "The Clerk of the Court is directed
to close this case forthwith," Stewart writes in the final judgment. I
believe that means /SCO v. IBM/ is essentially over now, unless IBM
wishes to pursue its counterclaims.

-----------------------------------------------

The big issue for Linux here is that Novell now officially owns the Unix
copyrights, and there is absolutely no legal cloud over them unless SCO
attorneys figure out another angle around the judgement. While there are
some other issues in the SCO vs. Novell case, the biggest one for Linux
users and vendors is who owns the Unix copyrights.


----------------------------------
Thought you might find this interesting :-)

-- 
Thanks,
Joseph Smith
Set-Top-Linux
www.settoplinux.org
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 252 bytes
Desc: not available
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20100611/20b55dfb/attachment.sig>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: rcmAttmntVUcyMf
Type: micalg/pgp-sha1
Size: 25 bytes
Desc: not available
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20100611/20b55dfb/attachment.bin>
-------------- next part --------------
_______________________________________________
gnhlug-discuss mailing list
gnhlug-discuss at mail.gnhlug.org
http://mail.gnhlug.org/mailman/listinfo/gnhlug-discuss/

From mbertens at xs4all.nl  Fri Jun 11 20:35:30 2010
From: mbertens at xs4all.nl (mbertens)
Date: Fri, 11 Jun 2010 20:35:30 +0200
Subject: [coreboot] unable to boot linux with coreboot
In-Reply-To: <AANLkTimIJoTAHDUAb9DAeouL_EorypnlKbeBQdA1iCdt@mail.gmail.com>
References: <1276026925.3803.54.camel@andrala.reboot>
	<AANLkTinByqVUaavWHsFHcrjNhe_zTqKZZKAlyJl4Z32w@mail.gmail.com>
	<1276193623.4023.2.camel@andrala.reboot>
	<AANLkTimIJoTAHDUAb9DAeouL_EorypnlKbeBQdA1iCdt@mail.gmail.com>
Message-ID: <1276281330.4023.5.camel@andrala.reboot>

On Thu, 2010-06-10 at 12:25 -0600, Myles Watson wrote:
> On Thu, Jun 10, 2010 at 12:13 PM, mbertens <mbertens at xs4all.nl> wrote:
> > On Wed, 2010-06-09 at 08:25 -0600, Myles Watson wrote:
> >> On Tue, Jun 8, 2010 at 1:55 PM, mbertens <mbertens at xs4all.nl> wrote:
> >> > Hi all,
> >> >
> >> > i have a strong problem that im not able to boot any os wit coreboot, it
> >> > starts (linux) ut it hangs after 128 sec.
> >> >
> >> > http://pastebin.com/uBT8JdH4
> >> >
> >> > Anyone any ideas
> >> I think you'd get a better response if you gave a little more information:
> >>
> >> 1. Have you ever been able to boot Linux with Coreboot?  If yes, what
> >> revision?  Have you checked to see what revision broke it?
> >>
> >> 2.  What loader are you using?  I know I could tell by going to the
> >> link, but more information in the mail helps generate interest enough
> >> to follow the link.
> >>
> >> 3....  Anything else you think is relevant.
> >>
> >> Thanks,
> >> Myles
> >
> > I was able to boot coreboot, with multiple revisions but none of the
> > will boot anymore, bacially like the boot log i provided, but i'm lost
> > at the moment. I don't known any more where to look for the problem.
> >
> > I'm currently booting the latest revision, that was ok, and also an
> > earlier revistion was booting fine, but now not any more.
> 
> Do you have an earlier (working) log to compare with?
> 
> Have you always gotten these errors?
> ERROR: PNP: 03f0.7 60 io size: 0x0000000001 not assigned
> ERROR: PNP: 03f0.7 62 io size: 0x0000000001 not assigned
> ERROR: PNP: 03f0.7 70 irq size: 0x0000000001 not assigned
> ERROR: PNP: 03f0.7 72 irq size: 0x0000000001 not assigned
> 
> Thanks,
> Myles
> 
Yes these errors where there always, it never botherd the system, but
there should be resolved at some point, but i tried to find the problem,
but didn't find it

Marc  







From mbertens at xs4all.nl  Fri Jun 11 20:43:16 2010
From: mbertens at xs4all.nl (mbertens)
Date: Fri, 11 Jun 2010 20:43:16 +0200
Subject: [coreboot] unable to boot linux with coreboot
In-Reply-To: <8D4BA30875194CE6B70388C538077DEC@chimp>
References: <1276026925.3803.54.camel@andrala.reboot>
	<AANLkTinByqVUaavWHsFHcrjNhe_zTqKZZKAlyJl4Z32w@mail.gmail.com>
	<1276193623.4023.2.camel@andrala.reboot>
	<AANLkTimIJoTAHDUAb9DAeouL_EorypnlKbeBQdA1iCdt@mail.gmail.com>
	<8D4BA30875194CE6B70388C538077DEC@chimp>
Message-ID: <1276281796.4023.15.camel@andrala.reboot>

On Thu, 2010-06-10 at 12:31 -0600, Myles Watson wrote:
> > >> > Anyone any ideas
> Have you tried to boot the factory BIOS?  Are these all cold boots?  Did
> cold boot always work?
> 
> Thanks,
> Myles
> 
I have two systems here on the table;
1.A.	original BIOS (insyde) boots just fine with FreeBSD
  B	with external ROM on the JDEBUG connector (see
http://www.coreboot.org/Tutorials:Nokia_IP530#J-DEBUG ) im not able to
boot coreboot (R5628 or 5600 with my patches which worked before). 
2.	The on-board flash contains R5512 that does not boot as well and this
one booted before too.

So as you can understand i'm a little lost

I tried adding bayou with payloads seabios and coreinfo, seabios is
starting as before, but coreinfo doesn't do anything.


Marc  	





From joe at settoplinux.org  Sat Jun 12 16:05:56 2010
From: joe at settoplinux.org (Joseph Smith)
Date: Sat, 12 Jun 2010 10:05:56 -0400
Subject: [coreboot] WARNING: BIOS bug: CPU MTRRs don't cover all of memory,
 losing 2MB of RAM
Message-ID: <4C139444.5010505@settoplinux.org>

Hello,
While working on my i810 port I am getting this message from the Linux 
kernel about my mtrr setup:

BIOS-provided physical RAM map:
  BIOS-e820: 0000000000000000 - 0000000000001000 type 16
  BIOS-e820: 0000000000001000 - 00000000000a0000 (usable)
  BIOS-e820: 00000000000c0000 - 000000000fef0000 (usable)
  BIOS-e820: 000000000fef0000 - 000000000ff00000 type 16
DMI not present or invalid.
last_pfn = 0xfef0 max_arch_pfn = 0x100000
WARNING: BIOS bug: CPU MTRRs don't cover all of memory, losing 2MB of RAM.
------------[ cut here ]------------
WARNING: at arch/x86/kernel/cpu/mtrr/main.c:1557 
mtrr_trim_uncached_memory+0x295/0x2b6() (Not tainted)
Modules linked in:
Pid: 0, comm: swapper Not tainted 2.6.27.24-170.2.68.fc10.i686 #1
  [<c042ddfb>] warn_on_slowpath+0x65/0x8b
  [<c06ab53c>] ? _spin_unlock_irqrestore+0x1b/0x38
  [<c06ab53c>] ? _spin_unlock_irqrestore+0x1b/0x38
  [<c06ab543>] ? _spin_unlock_irqrestore+0x22/0x38
  [<c042e2f1>] ? release_console_sem+0x1bf/0x1c7
  [<c042e76c>] ? vprintk+0x2ce/0x2f3
  [<c06a96db>] ? printk+0xf/0x14
  [<c0824127>] mtrr_trim_uncached_memory+0x295/0x2b6
  [<c081f73b>] setup_arch+0x48f/0x947
  [<c042e76c>] ? vprintk+0x2ce/0x2f3
  [<c08218dd>] ? __reserve_early+0xe4/0xf8
  [<c06a96db>] ? printk+0xf/0x14
  [<c0819605>] start_kernel+0x73/0x2f0
  [<c0819080>] __init_begin+0x80/0x88
  =======================
---[ end trace 4eaa2a86a8e2da22 ]---
update e820 for mtrr
modified physical RAM map:
  modified: 0000000000000000 - 0000000000001000 type 16
  modified: 0000000000001000 - 00000000000a0000 (usable)
  modified: 00000000000c0000 - 000000000fc00000 (usable)
  modified: 000000000fc00000 - 000000000fef0000 (reserved)
  modified: 000000000fef0000 - 000000000ff00000 type 16
last_pfn = 0xfc00 max_arch_pfn = 0x100000

----------------------------------------------

Any ideas? Full bootlog attached.

-- 
Thanks,
Joseph Smith
Set-Top-Linux
www.settoplinux.org
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: i810_boot_test8.txt
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20100612/a59082d6/attachment.txt>

From stepan at coresystems.de  Sat Jun 12 16:57:47 2010
From: stepan at coresystems.de (Stefan Reinauer)
Date: Sat, 12 Jun 2010 16:57:47 +0200
Subject: [coreboot] WARNING: BIOS bug: CPU MTRRs don't cover all of
 memory, losing 2MB of RAM
In-Reply-To: <4C139444.5010505@settoplinux.org>
References: <4C139444.5010505@settoplinux.org>
Message-ID: <4C13A06B.4090002@coresystems.de>

On 6/12/10 4:05 PM, Joseph Smith wrote:
> Setting fixed MTRRs(0-88) Type: UC
> Setting fixed MTRRs(0-16) Type: WB
> Setting fixed MTRRs(24-88) Type: WB
> DONE fixed MTRRs
> call enable_fixed_mtrr()
> Setting variable MTRR 0, base:    0MB, range:  128MB, type WB
> ADDRESS_MASK_HIGH=0xf
> Setting variable MTRR 1, base:  128MB, range:   64MB, type WB
> ADDRESS_MASK_HIGH=0xf
> Setting variable MTRR 2, base:  192MB, range:   32MB, type WB
> ADDRESS_MASK_HIGH=0xf
> Setting variable MTRR 3, base:  224MB, range:   16MB, type WB
> ADDRESS_MASK_HIGH=0xf
> Setting variable MTRR 4, base:  240MB, range:    8MB, type WB
> ADDRESS_MASK_HIGH=0xf
> Setting variable MTRR 5, base:  248MB, range:    4MB, type WB
> ADDRESS_MASK_HIGH=0xf
> Running out of variable MTRRs!
> Zero-sized MTRR range @0KB
> 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
>
>   
It looks like an UMA chipset with the UMA mechanism not used correctly
(i.e. uma_memory_base and uma_memory_size are not set and/or
CONFIG_GFXUMA not enabled)

Stefan
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20100612/33a69118/attachment.html>

From joe at settoplinux.org  Sat Jun 12 17:00:24 2010
From: joe at settoplinux.org (Joseph Smith)
Date: Sat, 12 Jun 2010 11:00:24 -0400
Subject: [coreboot] WARNING: BIOS bug: CPU MTRRs don't cover all of
 memory, losing 2MB of RAM
In-Reply-To: <4C13A06B.4090002@coresystems.de>
References: <4C139444.5010505@settoplinux.org>
	<4C13A06B.4090002@coresystems.de>
Message-ID: <4C13A108.1030500@settoplinux.org>

On 06/12/2010 10:57 AM, Stefan Reinauer wrote:
> On 6/12/10 4:05 PM, Joseph Smith wrote:
>> Setting fixed MTRRs(0-88) Type: UC
>> Setting fixed MTRRs(0-16) Type: WB
>> Setting fixed MTRRs(24-88) Type: WB
>> DONE fixed MTRRs
>> call enable_fixed_mtrr()
>> Setting variable MTRR 0, base:    0MB, range:  128MB, type WB
>> ADDRESS_MASK_HIGH=0xf
>> Setting variable MTRR 1, base:  128MB, range:   64MB, type WB
>> ADDRESS_MASK_HIGH=0xf
>> Setting variable MTRR 2, base:  192MB, range:   32MB, type WB
>> ADDRESS_MASK_HIGH=0xf
>> Setting variable MTRR 3, base:  224MB, range:   16MB, type WB
>> ADDRESS_MASK_HIGH=0xf
>> Setting variable MTRR 4, base:  240MB, range:    8MB, type WB
>> ADDRESS_MASK_HIGH=0xf
>> Setting variable MTRR 5, base:  248MB, range:    4MB, type WB
>> ADDRESS_MASK_HIGH=0xf
>> Running out of variable MTRRs!
>> Zero-sized MTRR range @0KB
>> 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
>>
>>
> It looks like an UMA chipset with the UMA mechanism not used correctly
> (i.e. uma_memory_base and uma_memory_size are not set and/or
> CONFIG_GFXUMA not enabled)
>
That is what I thought, I have not setup GFXUMA on i810 yet, but will do 
so, Thanks Stefan and Patrick.


-- 
Thanks,
Joseph Smith
Set-Top-Linux
www.settoplinux.org



From nowens2 at illinois.edu  Sun Jun 13 00:10:32 2010
From: nowens2 at illinois.edu (Nathan Owens)
Date: Sat, 12 Jun 2010 17:10:32 -0500
Subject: [coreboot] problems with M2V-MX SE + VGA
Message-ID: <4C1405D8.7090302@illinois.edu>

Hello Everyone,

I'm trying to compile Coreboot+SeaBIOS+VGA on an ASUS M2V-MX SE, using 
the VGA BIOS I extracted from the vendor BIOS. The result is that I can 
get to the bootloader menu (GRUB2, Debian Squeeze), but after 5-7 
seconds the video dies and or turns to random junk on the screen. Only 
on one occasion did it get past trying to start GDM (GNOME Display 
Manager). On that occasion I had deselected "set up bridges on path to 
VGA adapter" in kconfig. The video was very low resolution (about 
600X400) and it allowed me to log in to a desktop, but after the usual 
5-7 seconds the video turned to random junk.

I have been working on this since the beginning of May and have tried 
many, many combinations of settings in kconfig, including of course the 
recommended settings from the SeaBIOS page.

Here are a few of the things I've tried:

I'm reasonably sure I have a good VGA BIOS image, since the one I 
extracted matches bit for bit another one provided to me by Ruik.

I've compiled my own SeaBIOS and tried the pre-compiled one provided on 
the SeaBIOS page.

I've compiled and tried FILO as well, but more or less the same thing 
happens.

The motherboard and video work just fine with the vendor BIOS.

I also tried installing a video card (Radeon X300SE) in the PCI-e 16x 
slot, but Coreboot doesn't even work when I do that. I've tried many 
combinations of kconfig settings for this, but no luck. This card works 
with the vendor BIOS.

Here are couple of questions I have:

Is anyone having similar problems with this board?

I'd like to send some debugging info to the list (i.e, the boot log), 
but I'm not quite sure how to obtain this. Can someone point me to some 
documentation for obtaining the boot log from this board. I assume it's 
going to require some hardware.

Does anyone have any suggestions for kconfig settings that I should use?

Thanks,
Nate



From svn at coreboot.org  Sun Jun 13 00:42:15 2010
From: svn at coreboot.org (coreboot)
Date: Sat, 12 Jun 2010 22:42:15 -0000
Subject: [coreboot] #163: Board still requires RAMBASE <1MB
In-Reply-To: <043.f7c7426094d5eb0bf3d8dbfeb19852e7@coreboot.org>
References: <043.f7c7426094d5eb0bf3d8dbfeb19852e7@coreboot.org>
Message-ID: <052.899ed40608842bff53989d17ce85dceb@coreboot.org>

#163: Board still requires RAMBASE <1MB
-------------------------+--------------------------------------------------
    Reporter:  oxygene   |         Owner:  stepan@?             
        Type:  defect    |        Status:  new                  
    Priority:  minor     |     Milestone:                       
   Component:  coreboot  |      Keywords:                       
Dependencies:            |   Patchstatus:  there is no patch    
-------------------------+--------------------------------------------------

Comment(by jackliusooo):

 Several manufactured products attain the status of "luxury goods" due to
 their design, quality, durability or performance that are remarkably
 superior toYSL shoes sizing
 the comparable substitutes. Thus, virtually every category of goods
 available on the market today includes a subset of similar products whose
 "luxury" is marked by better-quality components and materials, solid
 construction, stylish appearance, increased durability, better
 performance, advanced features, and so on. As such, these luxury goods may
 retain or improve the basic functionality for which all items of a given
 category are originally designed <a href=http://www.luxuryinbox.com/issa-
 dresses-c-151.html>issa dresses on sale</a>.




 And do you like <a href=http://www.herve-leger-sale.com>herve leger dress
 knock off</a>.

 Which do you like best?
 Coach Bags 2009
 matthew williamson spring 2010

-- 
Ticket URL: <https://tracker.coreboot.org/trac/coreboot/ticket/163#comment:1>
coreboot <http://www.coreboot.org/>


From r.marek at assembler.cz  Sun Jun 13 01:33:22 2010
From: r.marek at assembler.cz (Rudolf Marek)
Date: Sun, 13 Jun 2010 01:33:22 +0200
Subject: [coreboot] problems with M2V-MX SE + VGA
In-Reply-To: <4C1405D8.7090302@illinois.edu>
References: <4C1405D8.7090302@illinois.edu>
Message-ID: <4C141942.8@assembler.cz>

Hi,

I can only say it always worked for me ;) Have you enabled the VGA BIOS hooks in 
SeaBIOS? Try with less RAM. I think I use 512MB, you can send me (in private 
please) your binary and I can flash it on Monday and see if I have same 
problems. I think it looks like something is wrong with video "bitrate" setup or 
something overlaps the gfx memory.

You can also try image from:

http://www.coreboot.org/ASUS_M2V-MX_SE

Thanks,
Rudolf




From svn at coreboot.org  Sun Jun 13 09:44:05 2010
From: svn at coreboot.org (coreboot)
Date: Sun, 13 Jun 2010 07:44:05 -0000
Subject: [coreboot] #163: Board still requires RAMBASE <1MB
In-Reply-To: <043.f7c7426094d5eb0bf3d8dbfeb19852e7@coreboot.org>
References: <043.f7c7426094d5eb0bf3d8dbfeb19852e7@coreboot.org>
Message-ID: <052.ffba6a8e5c4556e3db9c94d295e555d9@coreboot.org>

#163: Board still requires RAMBASE <1MB
-------------------------+--------------------------------------------------
    Reporter:  oxygene   |         Owner:  stepan@?             
        Type:  defect    |        Status:  new                  
    Priority:  minor     |     Milestone:                       
   Component:  coreboot  |      Keywords:                       
Dependencies:            |   Patchstatus:  there is no patch    
-------------------------+--------------------------------------------------

Comment(by LisaLilyworld):

 Brand like <a href=http://www.luxuryinbox.com/anna-sui-c-122.html>anna sui
 for target</a>.

 Many women love that, and they are all luxuries. for examples,
 Manolo Blahnik boots
 herve leger bandage dress
 christian louboutin discount
 And so on

-- 
Ticket URL: <https://tracker.coreboot.org/trac/coreboot/ticket/163#comment:2>
coreboot <http://www.coreboot.org/>


From mbertens at xs4all.nl  Sun Jun 13 11:30:19 2010
From: mbertens at xs4all.nl (mbertens)
Date: Sun, 13 Jun 2010 11:30:19 +0200
Subject: [coreboot] unable to boot linux with coreboot
In-Reply-To: <1276281796.4023.15.camel@andrala.reboot>
References: <1276026925.3803.54.camel@andrala.reboot>
	<AANLkTinByqVUaavWHsFHcrjNhe_zTqKZZKAlyJl4Z32w@mail.gmail.com>
	<1276193623.4023.2.camel@andrala.reboot>
	<AANLkTimIJoTAHDUAb9DAeouL_EorypnlKbeBQdA1iCdt@mail.gmail.com>
	<8D4BA30875194CE6B70388C538077DEC@chimp>
	<1276281796.4023.15.camel@andrala.reboot>
Message-ID: <1276421419.4023.40.camel@andrala.reboot>

Hi all,

an update:
I installed a secondary build system (ubuntu), i build everything from
scratch; seabios and coreboot r5575, r5600 and r5631, all these where
working fine. But booting them all failed. 

I tried  everything i could think of;
1. Swapped hardware; memory, system board, harddisks, ide-controller
(pri. versus sec.).
2. Swapped development systems (debian versus ubuntu)
3. 


I attached two bootlogs. for analise 
1.	with 80Gb harddisk.
	- up to 7 secs in the boot process all is fine
	- then 120 secs of silence, and last the message from udevd
2.	with 1Gb compact flash disk (which has a DMA problem, but its able to
boot futher in the Linux boot secuence.
	- up to 6 secs in the boot process all is fine
	- then 120 secs are lost to the DMA problem of the CF card, the system
booted before with de DMA failures just fine it takes only 120 secs
extra.
	- then 120 secs of silence, and the message from udevd
	- then some more output on starting the cardbus and others.
	- final message adding the swap on /dev/hda5 and then silence again.

I hope that anyone can help me with this silly problem, please don't
just throw a term through the mail, like "fix the DMA problem", but give
some pointers how to solve it in my configuration.

Marc



On Fri, 2010-06-11 at 20:43 +0200, mbertens wrote:
> On Thu, 2010-06-10 at 12:31 -0600, Myles Watson wrote:
> > > >> > Anyone any ideas
> > Have you tried to boot the factory BIOS?  Are these all cold boots?  Did
> > cold boot always work?
> > 
> > Thanks,
> > Myles
> > 
> I have two systems here on the table;
> 1.A.	original BIOS (insyde) boots just fine with FreeBSD
>   B	with external ROM on the JDEBUG connector (see
> http://www.coreboot.org/Tutorials:Nokia_IP530#J-DEBUG ) im not able to
> boot coreboot (R5628 or 5600 with my patches which worked before). 
> 2.	The on-board flash contains R5512 that does not boot as well and this
> one booted before too.
> 
> So as you can understand i'm a little lost
> 
> I tried adding bayou with payloads seabios and coreinfo, seabios is
> starting as before, but coreinfo doesn't do anything.
> 
> 
> Marc  	
> 
> 
> 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: putty-ip530-13-jun-2010-r5631.log
Type: text/x-log
Size: 54435 bytes
Desc: not available
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20100613/56760128/attachment.log>

From mbertens at xs4all.nl  Sun Jun 13 11:34:24 2010
From: mbertens at xs4all.nl (mbertens)
Date: Sun, 13 Jun 2010 11:34:24 +0200
Subject: [coreboot] unable to boot linux with coreboot,
	the second	bootlog
In-Reply-To: <1276421419.4023.40.camel@andrala.reboot>
References: <1276026925.3803.54.camel@andrala.reboot>
	<AANLkTinByqVUaavWHsFHcrjNhe_zTqKZZKAlyJl4Z32w@mail.gmail.com>
	<1276193623.4023.2.camel@andrala.reboot>
	<AANLkTimIJoTAHDUAb9DAeouL_EorypnlKbeBQdA1iCdt@mail.gmail.com>
	<8D4BA30875194CE6B70388C538077DEC@chimp>
	<1276281796.4023.15.camel@andrala.reboot>
	<1276421419.4023.40.camel@andrala.reboot>
Message-ID: <1276421664.4023.42.camel@andrala.reboot>

The second bootlog

On Sun, 2010-06-13 at 11:30 +0200, mbertens wrote:
> Hi all,
> 
> an update:
> I installed a secondary build system (ubuntu), i build everything from
> scratch; seabios and coreboot r5575, r5600 and r5631, all these where
> working fine. But booting them all failed. 
> 
> I tried  everything i could think of;
> 1. Swapped hardware; memory, system board, harddisks, ide-controller
> (pri. versus sec.).
> 2. Swapped development systems (debian versus ubuntu)
> 3. 
> 
> 
> I attached two bootlogs. for analise 
> 1.	with 80Gb harddisk.
> 	- up to 7 secs in the boot process all is fine
> 	- then 120 secs of silence, and last the message from udevd
> 2.	with 1Gb compact flash disk (which has a DMA problem, but its able to
> boot futher in the Linux boot secuence.
> 	- up to 6 secs in the boot process all is fine
> 	- then 120 secs are lost to the DMA problem of the CF card, the system
> booted before with de DMA failures just fine it takes only 120 secs
> extra.
> 	- then 120 secs of silence, and the message from udevd
> 	- then some more output on starting the cardbus and others.
> 	- final message adding the swap on /dev/hda5 and then silence again.
> 
> I hope that anyone can help me with this silly problem, please don't
> just throw a term through the mail, like "fix the DMA problem", but give
> some pointers how to solve it in my configuration.
> 
> Marc
> 
> 
> 
> On Fri, 2010-06-11 at 20:43 +0200, mbertens wrote:
> > On Thu, 2010-06-10 at 12:31 -0600, Myles Watson wrote:
> > > > >> > Anyone any ideas
> > > Have you tried to boot the factory BIOS?  Are these all cold boots?  Did
> > > cold boot always work?
> > > 
> > > Thanks,
> > > Myles
> > > 
> > I have two systems here on the table;
> > 1.A.	original BIOS (insyde) boots just fine with FreeBSD
> >   B	with external ROM on the JDEBUG connector (see
> > http://www.coreboot.org/Tutorials:Nokia_IP530#J-DEBUG ) im not able to
> > boot coreboot (R5628 or 5600 with my patches which worked before). 
> > 2.	The on-board flash contains R5512 that does not boot as well and this
> > one booted before too.
> > 
> > So as you can understand i'm a little lost
> > 
> > I tried adding bayou with payloads seabios and coreinfo, seabios is
> > starting as before, but coreinfo doesn't do anything.
> > 
> > 
> > Marc  	
> > 
> > 
> > 
> -- 
> coreboot mailing list: coreboot at coreboot.org
> http://www.coreboot.org/mailman/listinfo/coreboot
-------------- next part --------------
A non-text attachment was scrubbed...
Name: putty-ip530.log
Type: text/x-log
Size: 294445 bytes
Desc: not available
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20100613/7517746c/attachment.log>

From juhe at iki.fi  Sun Jun 13 20:25:04 2010
From: juhe at iki.fi (Juhana Helovuo)
Date: Sun, 13 Jun 2010 21:25:04 +0300
Subject: [coreboot] Porting to Asus M4A785-M
Message-ID: <1276453504.27968.52.camel@bart>

Hello,

I am trying to get coreboot working on Asus M4A785-M with Athlon II X2
240e CPU (Socket AM3). So far there is no success.


The mainboard is based on AMD785G + SB710 chipset, which has integrated
ATI VGA.

http://www.asus.com/product.aspx?P_ID=ef0qgvMIwOUagAVl&templete=2

The super IO chip is labeled ITE IT8712F-S. 

Please see the listings at the end of this post for details.

There is only pin header connector for COM1 serial port on the
mainboard. The back panel DB9 connector with cable to attach to the
mainboard must be bought separately. (The one I got has too short cable
to reach the PCI slot openings. And it was supposed to be an original
Asus part!)

The BIOS ROM is Macronix MX25L8005PC-15G, 1 MByte, DIP-8, mounted in a
socket. Flashrom 0.9.1 recognizes the chip and is able to read and write
it. 

I have built a small circuit board where I have two BIOS chips and can
select between them with a switch. The board is sitting in the BIOS
socket. This makes it easier to recover after flashing something
non-bootable.

I have tried with coreboot revision 5631 from SVN.

First, I connected the board via a null-modem cable to another Linux
machine, started getty at ttyS0, 115200 bps at the target machine and
minicom at the other machine. I get login prompt and can log in via
ttyS0, so the serial connection works.

Then I tried to build coreboot for ASRock 939A785GMH/128M, since it is
based on the same chip set. Flashing succeeds, but booting does not
work. Power light comes on, fans start, but otherwise there is no sign
of life, nothing on the serial port.

Then I noticed that the super IO type is different, make a new directory
under src/mainboard/asus for this board type, copy the contents from the
ASRock board, and change the references to the super I/O from a Winbond
chip to the ITE IT8712F.

There seemed to be a some code in the romstage.c that toggled the GPIO
pins in the super I/O chip, in function sio_init(). I made a guess that
this was something specific to the Winbond chip, so I commented those
out. The guess was based on #define -lines after the #include -section.

Also I generated a new irq_tables.c with the utility provided with
coreboot sources.

Now, when attempting to boot, I get the following from the serial port:

coreboot-4.0-r5631M Mon Jun 14 04:56:01 EEST 2010 starting...
bsp_apicid=0x0
Enabling routing table for node 00 done.
Enabling SMP settings


coreboot-4.0-r5631M Mon Jun 14 04:56:01 EEST 2010 starting...
bsp_apicid=0x0
Enabling routing table for node 00 done.
Enabling SMP settings


coreboot-4.0-r5631M Mon Jun 14 04:56:01 EEST 2010 starting...
bsp_apicid=0x0
Enabling routing table for node 00 done.
Enabling SMP settings

[...the same repeats...]


Now what to do next? 

The wiki documentation left me wondering what exactly are the necessary
steps to port coreboot, provided that all the basic components are
already supported. Which board-specific files are needed, and which ones
can be auto-generated vs. manually coded?


Best regards,
Juhana Helovuo




$ lspci -tvnn

> -[0000:00]-+-00.0  Advanced Micro Devices [AMD] RS780 Host Bridge Alternate [1022:9601]
>            +-01.0-[0000:01]--+-05.0  ATI Technologies Inc Device [1002:9710]
>            |                 \-05.1  ATI Technologies Inc Device [1002:970f]
>            +-0a.0-[0000:02]----00.0  Realtek Semiconductor Co., Ltd. RTL8111/8168B PCI Express Gigabit Ethernet controller [10ec:8168]
>            +-11.0  ATI Technologies Inc SB700/SB800 SATA Controller [IDE mode] [1002:4390]
>            +-12.0  ATI Technologies Inc SB700/SB800 USB OHCI0 Controller [1002:4397]
>            +-12.1  ATI Technologies Inc SB700 USB OHCI1 Controller [1002:4398]
>            +-12.2  ATI Technologies Inc SB700/SB800 USB EHCI Controller [1002:4396]
>            +-13.0  ATI Technologies Inc SB700/SB800 USB OHCI0 Controller [1002:4397]
>            +-13.1  ATI Technologies Inc SB700 USB OHCI1 Controller [1002:4398]
>            +-13.2  ATI Technologies Inc SB700/SB800 USB EHCI Controller [1002:4396]
>            +-14.0  ATI Technologies Inc SBx00 SMBus Controller [1002:4385]
>            +-14.1  ATI Technologies Inc SB700/SB800 IDE Controller [1002:439c]
>            +-14.2  ATI Technologies Inc SBx00 Azalia (Intel HDA) [1002:4383]
>            +-14.3  ATI Technologies Inc SB700/SB800 LPC host controller [1002:439d]
>            +-14.4-[0000:03]--
>            +-14.5  ATI Technologies Inc SB700/SB800 USB OHCI2 Controller [1002:4399]
>            +-18.0  Advanced Micro Devices [AMD] Family 10h [Opteron, Athlon64, Sempron] HyperTransport Configuration [1022:1200]
>            +-18.1  Advanced Micro Devices [AMD] Family 10h [Opteron, Athlon64, Sempron] Address Map [1022:1201]
>            +-18.2  Advanced Micro Devices [AMD] Family 10h [Opteron, Athlon64, Sempron] DRAM Controller [1022:1202]
>            +-18.3  Advanced Micro Devices [AMD] Family 10h [Opteron, Athlon64, Sempron] Miscellaneous Control [1022:1203]
>            \-18.4  Advanced Micro Devices [AMD] Family 10h [Opteron, Athlon64, Sempron] Link Control [1022:1204]


All the PCI(-E) slots are empty. Everything in the above listing is integrated to the mainboard.


> # ./superiotool -d       
> superiotool r5549
> Found ITE IT8712F (id=0x8712, rev=0x8) at 0x2e
> Register dump:
> idx 20 21 22 23 24 2b
> val 87 12 08 00 00 00
> def 87 12 08 00 00 00
> LDN 0x00 (Floppy)
> idx 30 60 61 70 74 f0 f1
> val 00 03 f0 06 02 00 00
> def 00 03 f0 06 02 00 00
> LDN 0x01 (COM1)
> idx 30 60 61 70 f0 f1 f2 f3
> val 01 03 f8 04 00 50 00 7f
> def 00 03 f8 04 00 50 00 7f
> LDN 0x02 (COM2)
> idx 30 60 61 70 f0 f1 f2 f3
> val 00 02 f8 03 00 50 00 7f
> def 00 02 f8 03 00 50 00 7f
> LDN 0x03 (Parallel port)
> idx 30 60 61 62 63 70 74 f0
> val 01 03 78 00 00 07 04 00
> def 00 03 78 07 78 07 03 03
> LDN 0x04 (Environment controller)
> idx 30 60 61 62 63 70 f0 f1  f2 f3 f4 f5 f6
> val 01 02 90 02 30 00 00 00  00 00 00 00 ff
> def 00 02 90 02 30 09 00 00  00 00 00 NA NA
> LDN 0x05 (Keyboard)
> idx 30 60 61 62 63 70 71 f0
> val 01 00 60 00 64 01 02 04
> def 01 00 60 00 64 01 02 08
> LDN 0x06 (Mouse)
> idx 30 70 71 f0
> val 01 0c 02 00
> def 00 0c 02 00
> LDN 0x07 (GPIO)
> idx 25 26 27 28 29 2a 2c 60  61 62 63 64 65 70 71 72  73 74 b0 b1 b2 b3 b4 b5  b8 b9 ba bb bc bd c0 c1  c2 c3 c4 c8 c9 ca cb cc  e0 e1 e2 e3 e4 f0 f1 f2  f3 f4 f5 f6 f7 f8 f9 fa  fb fc fd
> val c0 23 00 00 00 00 1f 00  00 03 00 00 00 00 01 00  38 00 00 00 00 00 00 00  00 00 00 00 00 00 c0 23  00 00 00 c0 23 00 00 00  00 00 00 00 00 00 00 00  00 00 00 1a 00 00 00 00  00 00 00
> def 01 00 00 40 00 00 00 00  00 00 00 00 00 00 00 00  c0 00 00 00 00 00 00 00  00 00 00 00 00 00 01 00  00 40 00 01 00 00 40 00  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  00 NA 00
> LDN 0x08 (MIDI port)
> idx 30 60 61 70 f0
> val 00 03 00 0a 00
> def 00 03 00 0a 00
> LDN 0x09 (Game port)
> idx 30 60 61
> val 00 02 01
> def 00 02 01
> LDN 0x0a (Consumer IR)
> idx 30 60 61 70 f0
> val 00 03 10 0b 06
> def 00 03 10 0b 00
> 




From mbertens at xs4all.nl  Sun Jun 13 21:59:53 2010
From: mbertens at xs4all.nl (mbertens)
Date: Sun, 13 Jun 2010 21:59:53 +0200
Subject: [coreboot] unable to boot linux with coreboot,
	the	second	bootlog
In-Reply-To: <1276421664.4023.42.camel@andrala.reboot>
References: <1276026925.3803.54.camel@andrala.reboot>
	<AANLkTinByqVUaavWHsFHcrjNhe_zTqKZZKAlyJl4Z32w@mail.gmail.com>
	<1276193623.4023.2.camel@andrala.reboot>
	<AANLkTimIJoTAHDUAb9DAeouL_EorypnlKbeBQdA1iCdt@mail.gmail.com>
	<8D4BA30875194CE6B70388C538077DEC@chimp>
	<1276281796.4023.15.camel@andrala.reboot>
	<1276421419.4023.40.camel@andrala.reboot>
	<1276421664.4023.42.camel@andrala.reboot>
Message-ID: <1276459194.4023.45.camel@andrala.reboot>

Hi all,

did some extra tests, with crossgcc, it did change anything.

Marc  


On Sun, 2010-06-13 at 11:34 +0200, mbertens wrote:
> The second bootlog
> 
> On Sun, 2010-06-13 at 11:30 +0200, mbertens wrote:
> > Hi all,
> > 
> > an update:
> > I installed a secondary build system (ubuntu), i build everything from
> > scratch; seabios and coreboot r5575, r5600 and r5631, all these where
> > working fine. But booting them all failed. 
> > 
> > I tried  everything i could think of;
> > 1. Swapped hardware; memory, system board, harddisks, ide-controller
> > (pri. versus sec.).
> > 2. Swapped development systems (debian versus ubuntu)
> > 3. 
> > 
> > 
> > I attached two bootlogs. for analise 
> > 1.	with 80Gb harddisk.
> > 	- up to 7 secs in the boot process all is fine
> > 	- then 120 secs of silence, and last the message from udevd
> > 2.	with 1Gb compact flash disk (which has a DMA problem, but its able to
> > boot futher in the Linux boot secuence.
> > 	- up to 6 secs in the boot process all is fine
> > 	- then 120 secs are lost to the DMA problem of the CF card, the system
> > booted before with de DMA failures just fine it takes only 120 secs
> > extra.
> > 	- then 120 secs of silence, and the message from udevd
> > 	- then some more output on starting the cardbus and others.
> > 	- final message adding the swap on /dev/hda5 and then silence again.
> > 
> > I hope that anyone can help me with this silly problem, please don't
> > just throw a term through the mail, like "fix the DMA problem", but give
> > some pointers how to solve it in my configuration.
> > 
> > Marc
> > 
> > 
> > 
> > On Fri, 2010-06-11 at 20:43 +0200, mbertens wrote:
> > > On Thu, 2010-06-10 at 12:31 -0600, Myles Watson wrote:
> > > > > >> > Anyone any ideas
> > > > Have you tried to boot the factory BIOS?  Are these all cold boots?  Did
> > > > cold boot always work?
> > > > 
> > > > Thanks,
> > > > Myles
> > > > 
> > > I have two systems here on the table;
> > > 1.A.	original BIOS (insyde) boots just fine with FreeBSD
> > >   B	with external ROM on the JDEBUG connector (see
> > > http://www.coreboot.org/Tutorials:Nokia_IP530#J-DEBUG ) im not able to
> > > boot coreboot (R5628 or 5600 with my patches which worked before). 
> > > 2.	The on-board flash contains R5512 that does not boot as well and this
> > > one booted before too.
> > > 
> > > So as you can understand i'm a little lost
> > > 
> > > I tried adding bayou with payloads seabios and coreinfo, seabios is
> > > starting as before, but coreinfo doesn't do anything.
> > > 
> > > 
> > > Marc  	
> > > 
> > > 
> > > 
> > -- 
> > coreboot mailing list: coreboot at coreboot.org
> > http://www.coreboot.org/mailman/listinfo/coreboot
> -- 
> coreboot mailing list: coreboot at coreboot.org
> http://www.coreboot.org/mailman/listinfo/coreboot




From svn at coreboot.org  Mon Jun 14 16:00:02 2010
From: svn at coreboot.org (coreboot tracker)
Date: Mon, 14 Jun 2010 16:00:02 +0200
Subject: [coreboot] Trac reminder: list of new ticket(s)
Message-ID: <E1OOACo-000249-CD@ra.coresystems.de>

An HTML attachment was scrubbed...
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20100614/7b0abd93/attachment.html>

From edwin_beasant at virtensys.com  Mon Jun 14 16:23:04 2010
From: edwin_beasant at virtensys.com (Edwin Beasant)
Date: Mon, 14 Jun 2010 15:23:04 +0100
Subject: [coreboot] PATCH: Add support for Virtensys 2uRack and Napoli
Message-ID: <95EC52016CC5DE4896FD95FA7323A4DB152FFE468C@mr-burns.exchange.virtensys.com>

Add Virtensys as a Manufacturer to the build sytem, and add their products.
Virtensys products use AMD Geode LX in configuration very similar to AMD Norwich designs.
Virtensys boards differ in the following ways from the reference implementation.
No PCI Physical Slots.
Intel 1Gig Ethernet onboard.
Pericom PCI->PCIe bridge onboard.
Napoli represents the Blade range of products
2uRack represents the 2u Rackable products.

Signed-off-by: Edwin Beasant edwin_beasant at virtensys.com<mailto:edwin_beasant at virtensys.com>
Edwin Beasant
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20100614/6ad0cb9d/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: coreboot-v4-virtensys-support.patch
Type: application/octet-stream
Size: 29987 bytes
Desc: coreboot-v4-virtensys-support.patch
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20100614/6ad0cb9d/attachment.obj>

From mylesgw at gmail.com  Mon Jun 14 17:06:21 2010
From: mylesgw at gmail.com (Myles Watson)
Date: Mon, 14 Jun 2010 09:06:21 -0600
Subject: [coreboot] unable to boot linux with coreboot, thesecond	bootlog
In-Reply-To: <1276459194.4023.45.camel@andrala.reboot>
References: <1276026925.3803.54.camel@andrala.reboot>
	<AANLkTinByqVUaavWHsFHcrjNhe_zTqKZZKAlyJl4Z32w@mail.gmail.com>
	<1276193623.4023.2.camel@andrala.reboot>
	<AANLkTimIJoTAHDUAb9DAeouL_EorypnlKbeBQdA1iCdt@mail.gmail.com>
	<8D4BA30875194CE6B70388C538077DEC@chimp>
	<1276281796.4023.15.camel@andrala.reboot>
	<1276421419.4023.40.camel@andrala.reboot>
	<1276421664.4023.42.camel@andrala.reboot>
	<1276459194.4023.45.camel@andrala.reboot>
Message-ID: <78BC921C322244109D960CEE77E086A4@chimp>

My only suggestion is to boot Linux with the factory BIOS, then shut it down
completely and cold boot with Coreboot.  I've had that work before when
nothing else would.  I'd love to track it down, but I haven't yet.

Thanks,
Myles




From joe.korty at ccur.com  Mon Jun 14 17:16:42 2010
From: joe.korty at ccur.com (Joe Korty)
Date: Mon, 14 Jun 2010 11:16:42 -0400
Subject: [coreboot] ottawa linux symposium
Message-ID: <20100614151642.GA29802@tsunami.ccur.com>

Hi Everyone,
My company is sending me to OLS this year.  I'd like
to meet up with any of you that might also be going.

Regards,
Joe



From ziltro at ziltro.com  Mon Jun 14 17:27:00 2010
From: ziltro at ziltro.com (Andrew Morgan)
Date: Mon, 14 Jun 2010 16:27:00 +0100
Subject: [coreboot] problems with M2V-MX SE + VGA
In-Reply-To: <4C1405D8.7090302@illinois.edu>
References: <4C1405D8.7090302@illinois.edu>
Message-ID: <4C164A44.6020600@ziltro.com>

Just a thought, have you tried with no VGA BIOS? You won't get any 
screen output until X loads, but after that point it should work fine, 
while in X.
On a plug-in card that's how it works but I don't know if the onboard 
chip will be enabled by default, enabled by Coreboot or disabled because 
the VGA BIOS isn't run.
I don't know exactly what this might prove but it is something to try 
anyway.

-- 

Andrew.





From anders at jenbo.dk  Mon Jun 14 18:38:11 2010
From: anders at jenbo.dk (=?utf-8?B?YW5kZXJzQGplbmJvLmRr?=)
Date: Mon, 14 Jun 2010 18:38:11 +0200
Subject: [coreboot] =?utf-8?q?Indtast_Bcc__problems_with_M2V-MX_SE_+_VGA?=
Message-ID: <mailman.4193.1355071776.16123.coreboot@coreboot.org>

Worked for me on a system with an onboard card based on i810th chipset.

Mvh Anders

----- Reply message -----
Fra: "Andrew Morgan" <ziltro at ziltro.com>
Dato: man., jun. 14, 2010 17:27
Emne: [coreboot] problems with M2V-MX SE + VGA
Til: <coreboot at coreboot.org>

Just a thought, have you tried with no VGA BIOS? You won't get any 
screen output until X loads, but after that point it should work fine, 
while in X.
On a plug-in card that's how it works but I don't know if the onboard 
chip will be enabled by default, enabled by Coreboot or disabled because 
the VGA BIOS isn't run.
I don't know exactly what this might prove but it is something to try 
anyway.

-- 

Andrew.



-- 
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/20100614/ccc5ef73/attachment.html>

From mbertens at xs4all.nl  Mon Jun 14 22:43:26 2010
From: mbertens at xs4all.nl (mbertens)
Date: Mon, 14 Jun 2010 22:43:26 +0200
Subject: [coreboot] unable to boot linux with coreboot, now with FreeBSD
In-Reply-To: <1276421664.4023.42.camel@andrala.reboot>
References: <1276026925.3803.54.camel@andrala.reboot>
	<AANLkTinByqVUaavWHsFHcrjNhe_zTqKZZKAlyJl4Z32w@mail.gmail.com>
	<1276193623.4023.2.camel@andrala.reboot>
	<AANLkTimIJoTAHDUAb9DAeouL_EorypnlKbeBQdA1iCdt@mail.gmail.com>
	<8D4BA30875194CE6B70388C538077DEC@chimp>
	<1276281796.4023.15.camel@andrala.reboot>
	<1276421419.4023.40.camel@andrala.reboot>
	<1276421664.4023.42.camel@andrala.reboot>
Message-ID: <1276548206.4023.50.camel@andrala.reboot>

Hi all,

A new boot log but now with freeBSD.

It seems to me that the memory gets trashed by something, but what?

FreeBSD is able too boot, but encouters a interrupt storm. Normally this
is due to faulty PIRQ table, and the only thing that i can think of is
that the memory table gets trashed too. 

Anyone having any ideas..... 


On Sun, 2010-06-13 at 11:34 +0200, mbertens wrote:
> The second bootlog
> 
> On Sun, 2010-06-13 at 11:30 +0200, mbertens wrote:
> > Hi all,
> > 
> > an update:
> > I installed a secondary build system (ubuntu), i build everything from
> > scratch; seabios and coreboot r5575, r5600 and r5631, all these where
> > working fine. But booting them all failed. 
> > 
> > I tried  everything i could think of;
> > 1. Swapped hardware; memory, system board, harddisks, ide-controller
> > (pri. versus sec.).
> > 2. Swapped development systems (debian versus ubuntu)
> > 3. 
> > 
> > 
> > I attached two bootlogs. for analise 
> > 1.	with 80Gb harddisk.
> > 	- up to 7 secs in the boot process all is fine
> > 	- then 120 secs of silence, and last the message from udevd
> > 2.	with 1Gb compact flash disk (which has a DMA problem, but its able to
> > boot futher in the Linux boot secuence.
> > 	- up to 6 secs in the boot process all is fine
> > 	- then 120 secs are lost to the DMA problem of the CF card, the system
> > booted before with de DMA failures just fine it takes only 120 secs
> > extra.
> > 	- then 120 secs of silence, and the message from udevd
> > 	- then some more output on starting the cardbus and others.
> > 	- final message adding the swap on /dev/hda5 and then silence again.
> > 
> > I hope that anyone can help me with this silly problem, please don't
> > just throw a term through the mail, like "fix the DMA problem", but give
> > some pointers how to solve it in my configuration.
> > 
> > Marc
> > 
> > 
> > 
> > On Fri, 2010-06-11 at 20:43 +0200, mbertens wrote:
> > > On Thu, 2010-06-10 at 12:31 -0600, Myles Watson wrote:
> > > > > >> > Anyone any ideas
> > > > Have you tried to boot the factory BIOS?  Are these all cold boots?  Did
> > > > cold boot always work?
> > > > 
> > > > Thanks,
> > > > Myles
> > > > 
> > > I have two systems here on the table;
> > > 1.A.	original BIOS (insyde) boots just fine with FreeBSD
> > >   B	with external ROM on the JDEBUG connector (see
> > > http://www.coreboot.org/Tutorials:Nokia_IP530#J-DEBUG ) im not able to
> > > boot coreboot (R5628 or 5600 with my patches which worked before). 
> > > 2.	The on-board flash contains R5512 that does not boot as well and this
> > > one booted before too.
> > > 
> > > So as you can understand i'm a little lost
> > > 
> > > I tried adding bayou with payloads seabios and coreinfo, seabios is
> > > starting as before, but coreinfo doesn't do anything.
> > > 
> > > 
> > > Marc  	
> > > 
> > > 
> > > 
> > -- 
> > coreboot mailing list: coreboot at coreboot.org
> > http://www.coreboot.org/mailman/listinfo/coreboot
> -- 
> coreboot mailing list: coreboot at coreboot.org
> http://www.coreboot.org/mailman/listinfo/coreboot
-------------- next part --------------
A non-text attachment was scrubbed...
Name: dump.log
Type: text/x-log
Size: 59900 bytes
Desc: not available
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20100614/492180d9/attachment.log>

From edwin_beasant at virtensys.com  Tue Jun 15 08:16:33 2010
From: edwin_beasant at virtensys.com (Edwin Beasant)
Date: Tue, 15 Jun 2010 07:16:33 +0100
Subject: [coreboot] unable to boot linux with coreboot, now with FreeBSD
In-Reply-To: <1276548206.4023.50.camel@andrala.reboot>
References: <1276421664.4023.42.camel@andrala.reboot>
	<1276548206.4023.50.camel@andrala.reboot>
Message-ID: <99994B2A-D90C-48C8-AE60-68579132FEE7@virtensys.com>

I think you may well have interrupt configuration problems:
There are messages in the boot log about interrupt storm, and
dissabling interrupts, which will then basically fubar any disk access/
Dma.
If you can boot Linux with options 'irqfixup irqpoll', it will start
to give you pointers.
A strong possibility is that the actual pins wired to the pci
interrupts are misconfigured early on, resulting in a permenantly 'on'
interrupt source.
I would look carefully at the interrupt routing table, and also the
PCI interrupt setup? Looking for things like interrupt overlap,
misconfigured GPIO etc...

Hope this helps!
Edwin

On 14 Jun 2010, at 21:40, "mbertens" <mbertens at xs4all.nl> wrote:

> Hi all,
>
> A new boot log but now with freeBSD.
>
> It seems to me that the memory gets trashed by something, but what?
>
> FreeBSD is able too boot, but encouters a interrupt storm. Normally
> this
> is due to faulty PIRQ table, and the only thing that i can think of is
> that the memory table gets trashed too.
>
> Anyone having any ideas.....
>
>
> On Sun, 2010-06-13 at 11:34 +0200, mbertens wrote:
>> The second bootlog
>>
>> On Sun, 2010-06-13 at 11:30 +0200, mbertens wrote:
>>> Hi all,
>>>
>>> an update:
>>> I installed a secondary build system (ubuntu), i build everything
>>> from
>>> scratch; seabios and coreboot r5575, r5600 and r5631, all these
>>> where
>>> working fine. But booting them all failed.
>>>
>>> I tried  everything i could think of;
>>> 1. Swapped hardware; memory, system board, harddisks, ide-controller
>>> (pri. versus sec.).
>>> 2. Swapped development systems (debian versus ubuntu)
>>> 3.
>>>
>>>
>>> I attached two bootlogs. for analise
>>> 1.  with 80Gb harddisk.
>>>    - up to 7 secs in the boot process all is fine
>>>    - then 120 secs of silence, and last the message from udevd
>>> 2.  with 1Gb compact flash disk (which has a DMA problem, but its
>>> able to
>>> boot futher in the Linux boot secuence.
>>>    - up to 6 secs in the boot process all is fine
>>>    - then 120 secs are lost to the DMA problem of the CF card, the
>>> system
>>> booted before with de DMA failures just fine it takes only 120 secs
>>> extra.
>>>    - then 120 secs of silence, and the message from udevd
>>>    - then some more output on starting the cardbus and others.
>>>    - final message adding the swap on /dev/hda5 and then silence
>>> again.
>>>
>>> I hope that anyone can help me with this silly problem, please don't
>>> just throw a term through the mail, like "fix the DMA problem",
>>> but give
>>> some pointers how to solve it in my configuration.
>>>
>>> Marc
>>>
>>>
>>>
>>> On Fri, 2010-06-11 at 20:43 +0200, mbertens wrote:
>>>> On Thu, 2010-06-10 at 12:31 -0600, Myles Watson wrote:
>>>>>>>>> Anyone any ideas
>>>>> Have you tried to boot the factory BIOS?  Are these all cold
>>>>> boots?  Did
>>>>> cold boot always work?
>>>>>
>>>>> Thanks,
>>>>> Myles
>>>>>
>>>> I have two systems here on the table;
>>>> 1.A.      original BIOS (insyde) boots just fine with FreeBSD
>>>>  B       with external ROM on the JDEBUG connector (see
>>>> http://www.coreboot.org/Tutorials:Nokia_IP530#J-DEBUG ) im not
>>>> able to
>>>> boot coreboot (R5628 or 5600 with my patches which worked before).
>>>> 2.        The on-board flash contains R5512 that does not boot as
>>>> well and this
>>>> one booted before too.
>>>>
>>>> So as you can understand i'm a little lost
>>>>
>>>> I tried adding bayou with payloads seabios and coreinfo, seabios is
>>>> starting as before, but coreinfo doesn't do anything.
>>>>
>>>>
>>>> Marc
>>>>
>>>>
>>>>
>>> --
>>> coreboot mailing list: coreboot at coreboot.org
>>> http://www.coreboot.org/mailman/listinfo/coreboot
>> --
>> coreboot mailing list: coreboot at coreboot.org
>> http://www.coreboot.org/mailman/listinfo/coreboot
> <dump.log>
> --
> coreboot mailing list: coreboot at coreboot.org
> http://www.coreboot.org/mailman/listinfo/coreboot



From joe at settoplinux.org  Tue Jun 15 13:38:25 2010
From: joe at settoplinux.org (Joseph Smith)
Date: Tue, 15 Jun 2010 07:38:25 -0400
Subject: [coreboot] Serial Console only starts after reset
Message-ID: <d3b3dbd0aff4456f420451fe44f5ddde@imap.1and1.com>


Hello,
I have a strange thing happening on the i810 port I am working on. When I
power the board on i do not get any serial console from coreboot. VGA turns
on and works fine, but no serial output. The strange part is if I push the
reset button, serial console comes up and works fine until the next power
off. The SuperIO is SMSC LPC47M102 and I am using superio/smsc/smscsuperio.
Just wondering if anyone else has encountered this before. Any help /
thoughts would be appreciated.

-- 
Thanks,
Joseph Smith
Set-Top-Linux
www.settoplinux.org




From stefan.reinauer at coresystems.de  Tue Jun 15 14:13:24 2010
From: stefan.reinauer at coresystems.de (Stefan Reinauer)
Date: Tue, 15 Jun 2010 14:13:24 +0200
Subject: [coreboot] Serial Console only starts after reset
In-Reply-To: <d3b3dbd0aff4456f420451fe44f5ddde@imap.1and1.com>
References: <d3b3dbd0aff4456f420451fe44f5ddde@imap.1and1.com>
Message-ID: <4C176E64.50501@coresystems.de>

On 6/15/10 1:38 PM, Joseph Smith wrote:
> Hello,
> I have a strange thing happening on the i810 port I am working on. When I
> power the board on i do not get any serial console from coreboot. VGA turns
> on and works fine, but no serial output. The strange part is if I push the
> reset button, serial console comes up and works fine until the next power
> off. The SuperIO is SMSC LPC47M102 and I am using superio/smsc/smscsuperio.
> Just wondering if anyone else has encountered this before. Any help /
> thoughts would be appreciated.
>   

Your Super IO chip is not initialized correctly. Compare the register
output after reset and from cold start.
Did you run the same coreboot image already when you pressed the reset
button, or did you initially boot with the BIOS?

Stefan




From joe at settoplinux.org  Tue Jun 15 14:25:48 2010
From: joe at settoplinux.org (Joseph Smith)
Date: Tue, 15 Jun 2010 08:25:48 -0400
Subject: [coreboot] Serial Console only starts after reset
In-Reply-To: <4C176E64.50501@coresystems.de>
References: <d3b3dbd0aff4456f420451fe44f5ddde@imap.1and1.com>
	<4C176E64.50501@coresystems.de>
Message-ID: <629e66cb159099658a0e4cef5b844934@imap.1and1.com>




On Tue, 15 Jun 2010 14:13:24 +0200, Stefan Reinauer
<stefan.reinauer at coresystems.de> wrote:
> On 6/15/10 1:38 PM, Joseph Smith wrote:
>> Hello,
>> I have a strange thing happening on the i810 port I am working on. When
I
>> power the board on i do not get any serial console from coreboot. VGA
> turns
>> on and works fine, but no serial output. The strange part is if I push
> the
>> reset button, serial console comes up and works fine until the next
power
>> off. The SuperIO is SMSC LPC47M102 and I am using
> superio/smsc/smscsuperio.
>> Just wondering if anyone else has encountered this before. Any help /
>> thoughts would be appreciated.
>>
> 
> Your Super IO chip is not initialized correctly. Compare the register
> output after reset and from cold start.

You mean with superiotool?

> Did you run the same coreboot image already when you pressed the reset
> button, or did you initially boot with the BIOS?
> 
Yes, same coreboot image.

-- 
Thanks,
Joseph Smith
Set-Top-Linux
www.settoplinux.org




From rminnich at gmail.com  Tue Jun 15 14:30:07 2010
From: rminnich at gmail.com (ron minnich)
Date: Tue, 15 Jun 2010 05:30:07 -0700
Subject: [coreboot] Serial Console only starts after reset
In-Reply-To: <629e66cb159099658a0e4cef5b844934@imap.1and1.com>
References: <d3b3dbd0aff4456f420451fe44f5ddde@imap.1and1.com>
	<4C176E64.50501@coresystems.de>
	<629e66cb159099658a0e4cef5b844934@imap.1and1.com>
Message-ID: <AANLkTim6HdR6LM0_aZiN3FKM2lg4oxUJmWz_UaDqTugP@mail.gmail.com>

It would seem that the RAM code is right but the "early setup" code is
wrong. It's working because the "early setup" is probably having no
effect whatsoever ...

ron



From joe at settoplinux.org  Tue Jun 15 14:41:46 2010
From: joe at settoplinux.org (Joseph Smith)
Date: Tue, 15 Jun 2010 08:41:46 -0400
Subject: [coreboot] Serial Console only starts after reset
In-Reply-To: <AANLkTim6HdR6LM0_aZiN3FKM2lg4oxUJmWz_UaDqTugP@mail.gmail.com>
References: <d3b3dbd0aff4456f420451fe44f5ddde@imap.1and1.com>
	<4C176E64.50501@coresystems.de>
	<629e66cb159099658a0e4cef5b844934@imap.1and1.com>
	<AANLkTim6HdR6LM0_aZiN3FKM2lg4oxUJmWz_UaDqTugP@mail.gmail.com>
Message-ID: <2b3d7d498ec928359c77f8d365cb6097@imap.1and1.com>




On Tue, 15 Jun 2010 05:30:07 -0700, ron minnich <rminnich at gmail.com> wrote:
> It would seem that the RAM code is right but the "early setup" code is
> wrong. It's working because the "early setup" is probably having no
> effect whatsoever ...
> 
Hmm,
There is a src/superio/smsc/lpc47m10x maybe I will try that and see if it
works.
Maybe the src/superio/smsc/smscsuperio does not do early_serial correctly
for this chip?
FYI, after I push the reset button and can see the bootlog, 
it appears that the superio is detected and setup correctly.

-- 
Thanks,
Joseph Smith
Set-Top-Linux
www.settoplinux.org




From stepan at coresystems.de  Tue Jun 15 15:39:25 2010
From: stepan at coresystems.de (Stefan Reinauer)
Date: Tue, 15 Jun 2010 15:39:25 +0200
Subject: [coreboot] Serial Console only starts after reset
In-Reply-To: <629e66cb159099658a0e4cef5b844934@imap.1and1.com>
References: <d3b3dbd0aff4456f420451fe44f5ddde@imap.1and1.com>	<4C176E64.50501@coresystems.de>
	<629e66cb159099658a0e4cef5b844934@imap.1and1.com>
Message-ID: <4C17828D.9050808@coresystems.de>

On 6/15/10 2:25 PM, Joseph Smith wrote:
>
>
> On Tue, 15 Jun 2010 14:13:24 +0200, Stefan Reinauer
> <stefan.reinauer at coresystems.de> wrote:
>   
>> On 6/15/10 1:38 PM, Joseph Smith wrote:
>>     
>>> Hello,
>>> I have a strange thing happening on the i810 port I am working on. When
>>>       
> I
>   
>>> power the board on i do not get any serial console from coreboot. VGA
>>>       
>> turns
>>     
>>> on and works fine, but no serial output. The strange part is if I push
>>>       
>> the
>>     
>>> reset button, serial console comes up and works fine until the next
>>>       
> power
>   
>>> off. The SuperIO is SMSC LPC47M102 and I am using
>>>       
>> superio/smsc/smscsuperio.
>>     
>>> Just wondering if anyone else has encountered this before. Any help /
>>> thoughts would be appreciated.
>>>
>>>       
>> Your Super IO chip is not initialized correctly. Compare the register
>> output after reset and from cold start.
>>     
> You mean with superiotool?
>
>   
That might already be too late

>> Did you run the same coreboot image already when you pressed the reset
>> button, or did you initially boot with the BIOS?
>>
>>     
> Yes, same coreboot image.
>   

So booting Linux fixes the issue? Does serial console in linux work on a
cold boot?




From stepan at coresystems.de  Tue Jun 15 15:50:51 2010
From: stepan at coresystems.de (Stefan Reinauer)
Date: Tue, 15 Jun 2010 15:50:51 +0200
Subject: [coreboot] Serial Console only starts after reset
In-Reply-To: <2b3d7d498ec928359c77f8d365cb6097@imap.1and1.com>
References: <d3b3dbd0aff4456f420451fe44f5ddde@imap.1and1.com>
	<4C176E64.50501@coresystems.de>
	<629e66cb159099658a0e4cef5b844934@imap.1and1.com>
	<AANLkTim6HdR6LM0_aZiN3FKM2lg4oxUJmWz_UaDqTugP@mail.gmail.com>
	<2b3d7d498ec928359c77f8d365cb6097@imap.1and1.com>
Message-ID: <4C17853B.2010805@coresystems.de>

On 6/15/10 2:41 PM, Joseph Smith wrote:
>
>
> On Tue, 15 Jun 2010 05:30:07 -0700, ron minnich <rminnich at gmail.com> wrote:
>   
>> It would seem that the RAM code is right but the "early setup" code is
>> wrong. It's working because the "early setup" is probably having no
>> effect whatsoever ...
>>
>>     
> Hmm,
> There is a src/superio/smsc/lpc47m10x maybe I will try that and see if it
> works.
>   
That driver seems non functional. It looks like it was added for the sun
ultra 40 board but then romstage.c of that machine includes init code of
another superio ....

> Maybe the src/superio/smsc/smscsuperio does not do early_serial correctly
> for this chip?
>   
Google tells me that this document knows the answer:
http://www.smsc.com/media/Downloads_Public/Data_Sheets/47m10x.pdf



> FYI, after I push the reset button and can see the bootlog, 
> it appears that the superio is detected and setup correctly.
>   
Does pushing the superio button help when you're still in FILO, too?

Stefan




From joe at settoplinux.org  Tue Jun 15 16:07:06 2010
From: joe at settoplinux.org (Joseph Smith)
Date: Tue, 15 Jun 2010 10:07:06 -0400
Subject: [coreboot] Serial Console only starts after reset
In-Reply-To: <4C17828D.9050808@coresystems.de>
References: <d3b3dbd0aff4456f420451fe44f5ddde@imap.1and1.com>	<4C176E64.50501@coresystems.de>
	<629e66cb159099658a0e4cef5b844934@imap.1and1.com>
	<4C17828D.9050808@coresystems.de>
Message-ID: <1e8eccf4f0337df4a6cf194e132212ca@imap.1and1.com>




On Tue, 15 Jun 2010 15:39:25 +0200, Stefan Reinauer <stepan at coresystems.de>
wrote:
> On 6/15/10 2:25 PM, Joseph Smith wrote:
>>
>>
>> On Tue, 15 Jun 2010 14:13:24 +0200, Stefan Reinauer
>> <stefan.reinauer at coresystems.de> wrote:
>>
>>> On 6/15/10 1:38 PM, Joseph Smith wrote:
>>>
>>>> Hello,
>>>> I have a strange thing happening on the i810 port I am working on.
When
>>>>
>> I
>>
>>>> power the board on i do not get any serial console from coreboot. VGA
>>>>
>>> turns
>>>
>>>> on and works fine, but no serial output. The strange part is if I push
>>>>
>>> the
>>>
>>>> reset button, serial console comes up and works fine until the next
>>>>
>> power
>>
>>>> off. The SuperIO is SMSC LPC47M102 and I am using
>>>>
>>> superio/smsc/smscsuperio.
>>>
>>>> Just wondering if anyone else has encountered this before. Any help /
>>>> thoughts would be appreciated.
>>>>
>>>>
>>> Your Super IO chip is not initialized correctly. Compare the register
>>> output after reset and from cold start.
>>>
>> You mean with superiotool?
>>
>>
> That might already be too late
> 
>>> Did you run the same coreboot image already when you pressed the reset
>>> button, or did you initially boot with the BIOS?
>>>
>>>
>> Yes, same coreboot image.
>>
> 
> So booting Linux fixes the issue? Does serial console in linux work on a
> cold boot?
> 
I don't think there is really a issue. The post card spins through all the
post codes just fine, vga starts up and it boots into Linux just fine. When
I cold boot it, if I hit the reset button before Linux starts, it restarts
with coreboot serial console just fine. I have not tried Linux serial
console mode yet. I think something wrong is happening at the early_serial
point. I wonder if it could be a SB gpio or SB PM event to wake the serial
port? The devices on the LPC47M102 do support PM wake-up events, So I
wonder if it is related?

-- 
Thanks,
Joseph Smith
Set-Top-Linux
www.settoplinux.org




From joe at settoplinux.org  Tue Jun 15 16:12:11 2010
From: joe at settoplinux.org (Joseph Smith)
Date: Tue, 15 Jun 2010 10:12:11 -0400
Subject: [coreboot] Serial Console only starts after reset
In-Reply-To: <4C17853B.2010805@coresystems.de>
References: <d3b3dbd0aff4456f420451fe44f5ddde@imap.1and1.com>
	<4C176E64.50501@coresystems.de>
	<629e66cb159099658a0e4cef5b844934@imap.1and1.com>
	<AANLkTim6HdR6LM0_aZiN3FKM2lg4oxUJmWz_UaDqTugP@mail.gmail.com>
	<2b3d7d498ec928359c77f8d365cb6097@imap.1and1.com>
	<4C17853B.2010805@coresystems.de>
Message-ID: <39c3c2fcd2539d4003fb22c5f26ac897@imap.1and1.com>




On Tue, 15 Jun 2010 15:50:51 +0200, Stefan Reinauer <stepan at coresystems.de>
wrote:
> On 6/15/10 2:41 PM, Joseph Smith wrote:
>>
>>
>> On Tue, 15 Jun 2010 05:30:07 -0700, ron minnich <rminnich at gmail.com>
> wrote:
>>
>>> It would seem that the RAM code is right but the "early setup" code is
>>> wrong. It's working because the "early setup" is probably having no
>>> effect whatsoever ...
>>>
>>>
>> Hmm,
>> There is a src/superio/smsc/lpc47m10x maybe I will try that and see if
it
>> works.
>>
> That driver seems non functional. It looks like it was added for the sun
> ultra 40 board but then romstage.c of that machine includes init code of
> another superio ....
> 
Yeh I noticed that it is a half port....

>> Maybe the src/superio/smsc/smscsuperio does not do early_serial
correctly
>> for this chip?
>>
> Google tells me that this document knows the answer:
> http://www.smsc.com/media/Downloads_Public/Data_Sheets/47m10x.pdf
> 
Yes, of course I have the datasheeet, silly :-)
> 
> 
>> FYI, after I push the reset button and can see the bootlog,
>> it appears that the superio is detected and setup correctly.
>>
> Does pushing the superio button help when you're still in FILO, too?
> 
Hmm, not sure I usually push the reset before I get to payload. I can
check.

-- 
Thanks,
Joseph Smith
Set-Top-Linux
www.settoplinux.org




From stepan at coresystems.de  Tue Jun 15 16:16:46 2010
From: stepan at coresystems.de (Stefan Reinauer)
Date: Tue, 15 Jun 2010 16:16:46 +0200
Subject: [coreboot] Serial Console only starts after reset
In-Reply-To: <1e8eccf4f0337df4a6cf194e132212ca@imap.1and1.com>
References: <d3b3dbd0aff4456f420451fe44f5ddde@imap.1and1.com>	<4C176E64.50501@coresystems.de>
	<629e66cb159099658a0e4cef5b844934@imap.1and1.com>
	<4C17828D.9050808@coresystems.de>
	<1e8eccf4f0337df4a6cf194e132212ca@imap.1and1.com>
Message-ID: <4C178B4E.6040705@coresystems.de>

On 6/15/10 4:07 PM, Joseph Smith wrote:
> When
> I cold boot it, if I hit the reset button before Linux starts, it restarts
> with coreboot serial console just fine. 
>   

Hm...

Maybe 0x2e/0x4e are mapped to LPC after the SuperIO is configured (and
that mapping survives a reset)... that would be a southbridge init issue.

Or, the hardware has to stabilize after power on before you can
configure the SuperIO.

Stefan



From joe at settoplinux.org  Tue Jun 15 16:28:51 2010
From: joe at settoplinux.org (Joseph Smith)
Date: Tue, 15 Jun 2010 10:28:51 -0400
Subject: [coreboot] Serial Console only starts after reset
In-Reply-To: <4C178B4E.6040705@coresystems.de>
References: <d3b3dbd0aff4456f420451fe44f5ddde@imap.1and1.com>	<4C176E64.50501@coresystems.de>
	<629e66cb159099658a0e4cef5b844934@imap.1and1.com>
	<4C17828D.9050808@coresystems.de>
	<1e8eccf4f0337df4a6cf194e132212ca@imap.1and1.com>
	<4C178B4E.6040705@coresystems.de>
Message-ID: <7c81186dd4a181b1e0b5e6422f1935e3@imap.1and1.com>




On Tue, 15 Jun 2010 16:16:46 +0200, Stefan Reinauer <stepan at coresystems.de>
wrote:
> On 6/15/10 4:07 PM, Joseph Smith wrote:
>> When
>> I cold boot it, if I hit the reset button before Linux starts, it
> restarts
>> with coreboot serial console just fine.
>>
> 
> Hm...
> 
> Maybe 0x2e/0x4e are mapped to LPC after the SuperIO is configured (and
> that mapping survives a reset)... that would be a southbridge init issue.
> 
Hmm, This is interesting. The first time I booted it, I had copied romstage
from another board that had:

#define SERIAL_DEV PNP_DEV(0x4e, SMSCSUPERIO_SP1)

And I got coreboot serial console (early_serial) just fine but when it came
to detecting and inializing the superio, I got all kinds of errors from
coreboot about device not found.

So I changed it to 0x2e as described in the datasheet and detected with
superiotool(vendor bios), and that is when this problem started. But now
coreboot is happy, detects the device and the resource allocator is happy,
I just do not get early_serial on cold boot.

This is weird!

> Or, the hardware has to stabilize after power on before you can
> configure the SuperIO.
> 
Maybe?

-- 
Thanks,
Joseph Smith
Set-Top-Linux
www.settoplinux.org




From stepan at coresystems.de  Tue Jun 15 16:32:21 2010
From: stepan at coresystems.de (Stefan Reinauer)
Date: Tue, 15 Jun 2010 16:32:21 +0200
Subject: [coreboot] Serial Console only starts after reset
In-Reply-To: <7c81186dd4a181b1e0b5e6422f1935e3@imap.1and1.com>
References: <d3b3dbd0aff4456f420451fe44f5ddde@imap.1and1.com>	<4C176E64.50501@coresystems.de>
	<629e66cb159099658a0e4cef5b844934@imap.1and1.com>
	<4C17828D.9050808@coresystems.de>
	<1e8eccf4f0337df4a6cf194e132212ca@imap.1and1.com>
	<4C178B4E.6040705@coresystems.de>
	<7c81186dd4a181b1e0b5e6422f1935e3@imap.1and1.com>
Message-ID: <4C178EF5.7000404@coresystems.de>

On 6/15/10 4:28 PM, Joseph Smith wrote:
> Hmm, This is interesting. The first time I booted it, I had copied romstage
> from another board that had:
>
> #define SERIAL_DEV PNP_DEV(0x4e, SMSCSUPERIO_SP1)
>
> And I got coreboot serial console (early_serial) just fine but when it came
> to detecting and inializing the superio, I got all kinds of errors from
> coreboot about device not found.
>
> So I changed it to 0x2e as described in the datasheet and detected with
> superiotool(vendor bios), and that is when this problem started. But now
> coreboot is happy, detects the device and the resource allocator is happy,
> I just do not get early_serial on cold boot.
>
> This is weird!
>   
The above define does not change any behavior in stage 2 / the resource
allocator. Try disabling romstage smsc initialization completely and see
if that helps.



From joe at settoplinux.org  Tue Jun 15 16:44:19 2010
From: joe at settoplinux.org (Joseph Smith)
Date: Tue, 15 Jun 2010 10:44:19 -0400
Subject: [coreboot] Serial Console only starts after reset
In-Reply-To: <4C178EF5.7000404@coresystems.de>
References: <d3b3dbd0aff4456f420451fe44f5ddde@imap.1and1.com>	<4C176E64.50501@coresystems.de>
	<629e66cb159099658a0e4cef5b844934@imap.1and1.com>
	<4C17828D.9050808@coresystems.de>
	<1e8eccf4f0337df4a6cf194e132212ca@imap.1and1.com>
	<4C178B4E.6040705@coresystems.de>
	<7c81186dd4a181b1e0b5e6422f1935e3@imap.1and1.com>
	<4C178EF5.7000404@coresystems.de>
Message-ID: <40c168673627b192f07dc785fdbb98c1@imap.1and1.com>



On Tue, 15 Jun 2010 16:32:21 +0200, Stefan Reinauer <stepan at coresystems.de>
wrote:
> On 6/15/10 4:28 PM, Joseph Smith wrote:
>> Hmm, This is interesting. The first time I booted it, I had copied
> romstage
>> from another board that had:
>>
>> #define SERIAL_DEV PNP_DEV(0x4e, SMSCSUPERIO_SP1)
>>
>> And I got coreboot serial console (early_serial) just fine but when it
> came
>> to detecting and inializing the superio, I got all kinds of errors from
>> coreboot about device not found.
>>
>> So I changed it to 0x2e as described in the datasheet and detected with
>> superiotool(vendor bios), and that is when this problem started. But now
>> coreboot is happy, detects the device and the resource allocator is
> happy,
>> I just do not get early_serial on cold boot.
>>
>> This is weird!
>>
> The above define does not change any behavior in stage 2 / the resource
> allocator. Try disabling romstage smsc initialization completely and see
> if that helps.

Are you sure about that?
Attached is a bootlog with it set to 0x4e. Note the:

Found SMSC Super I/O (ID=0xff, rev=0xff)

With it set to 0x2e:

Found SMSC Super I/O (ID=0x59, rev=0x01)

-- 
Thanks,
Joseph Smith
Set-Top-Linux
www.settoplinux.org
-------------- next part --------------


coreboot-4.0-r5627M Fri Jun 11 00:40:22 EDT 2010 starting...
SMBus controller enabled
Found DIMM in slot 00
DIMM is 0x80MB
After translation, dimm_size is 0x0d
Found DIMM in slot 01
DIMM is 0x80MB
After translation, dimm_size is 0x0d
DRP calculated to 0xdd
BUFF_SC calculated to 0x55c6
Loading stage image.
Check CBFS header at fffeffe0
magic is 4f524243
Found CBFS header at fffeffe0
Check fallback/coreboot_ram
Stage: loading fallback/coreboot_ram @ 0x100000 (147456 bytes), entry @ 0x100000
Stage: done loading.
Jumping to image.
coreboot-4.0-r5627M Fri Jun 11 00:40:22 EDT 2010 booting...
Calibrating delay loop...
end 88727718, start 2e2b573c
32-bit delta 1444
calibrate_tsc 32-bit result is 1444
clocks_per_usec: 1444
Enumerating buses...
Show all devs...Before Device Enumeration.
Root Device: enabled 1
APIC_CLUSTER: 0: enabled 1
APIC: 00: enabled 1
PCI_DOMAIN: 0000: enabled 1
PCI: 00:00.0: enabled 1
PCI: 00:01.0: enabled 1
PCI: 00:1e.0: enabled 1
PCI: 00:1f.0: enabled 1
PNP: 002e.0: enabled 1
PNP: 002e.3: enabled 1
PNP: 002e.4: enabled 1
PNP: 002e.5: enabled 0
PNP: 002e.7: enabled 1
PNP: 002e.9: enabled 0
PNP: 002e.a: enabled 1
PNP: 002e.b: enabled 0
PCI: 00:1f.1: enabled 1
PCI: 00:1f.2: enabled 1
PCI: 00:1f.3: enabled 1
PCI: 00:1f.4: enabled 1
PCI: 00:1f.5: enabled 1
PCI: 00:1f.6: enabled 0
Compare with tree...
Root Device: enabled 1
 APIC_CLUSTER: 0: enabled 1
  APIC: 00: enabled 1
 PCI_DOMAIN: 0000: enabled 1
  PCI: 00:00.0: enabled 1
  PCI: 00:01.0: enabled 1
  PCI: 00:1e.0: enabled 1
  PCI: 00:1f.0: enabled 1
   PNP: 002e.0: enabled 1
   PNP: 002e.3: enabled 1
   PNP: 002e.4: enabled 1
   PNP: 002e.5: enabled 0
   PNP: 002e.7: enabled 1
   PNP: 002e.9: enabled 0
   PNP: 002e.a: enabled 1
   PNP: 002e.b: enabled 0
  PCI: 00:1f.1: enabled 1
  PCI: 00:1f.2: enabled 1
  PCI: 00:1f.3: enabled 1
  PCI: 00:1f.4: enabled 1
  PCI: 00:1f.5: enabled 1
  PCI: 00:1f.6: enabled 0
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] ops
PCI: 00:00.0 [8086/7124] enabled
PCI: 00:01.0 [8086/7125] enabled
PCI: 00:1e.0 [8086/244e] bus ops
PCI: 00:1e.0 [8086/244e] enabled
PCI: 00:1f.0 [8086/2440] bus ops
PCI: 00:1f.0 [8086/2440] enabled
PCI: 00:1f.1 [8086/244b] ops
PCI: 00:1f.1 [8086/244b] enabled
PCI: 00:1f.2 [8086/2442] ops
PCI: 00:1f.2 [8086/2442] enabled
PCI: 00:1f.3 [8086/2443] enabled
PCI: 00:1f.4 [8086/2444] ops
PCI: 00:1f.4 [8086/2444] enabled
PCI: 00:1f.5 [8086/2445] ops
PCI: 00:1f.5 [8086/2445] enabled
do_pci_scan_bridge for PCI: 00:1e.0
malloc Enter, size 24, free_mem_ptr 00120000
malloc 00120000
PCI: pci_scan_bus for bus 01
malloc Enter, size 68, free_mem_ptr 00120018
malloc 00120018
PCI: 01:08.0 [8086/2449] ops
PCI: 01:08.0 [8086/2449] enabled
PCI: pci_scan_bus returning with max=001
do_pci_scan_bridge returns max 1
scan_static_bus for PCI: 00:1f.0
Found SMSC Super I/O (ID=0xff, rev=0xff)
PNP: 002e.0 enabled
PNP: 002e.3 enabled
PNP: 002e.4 enabled
PNP: 002e.5 disabled
PNP: 002e.7 enabled
PNP: 002e.9 disabled
PNP: 002e.a enabled
PNP: 002e.b disabled
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
Setting up VGA for PCI: 00:01.0
Setting PCI_BRIDGE_CTL_VGA for bridge PCI_DOMAIN: 0000
Setting PCI_BRIDGE_CTL_VGA for bridge Root Device
Allocating resources...
Reading resources...
Root Device read_resources bus 0 link: 0
APIC_CLUSTER: 0 read_resources bus 0 link: 0
APIC: 00 missing read_resources
APIC_CLUSTER: 0 read_resources bus 0 link: 0 done
malloc Enter, size 2560, free_mem_ptr 0012005c
malloc 0012005c
PCI_DOMAIN: 0000 read_resources bus 0 link: 0
PCI: 00:1e.0 read_resources bus 1 link: 0
PCI: 00:1e.0 read_resources bus 1 link: 0 done
PCI: 00:1f.0 read_resources bus 0 link: 0
PNP: 002e.0 missing read_resources
PNP: 002e.3 missing read_resources
PNP: 002e.4 missing read_resources
PNP: 002e.7 missing read_resources
PNP: 002e.a missing read_resources
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
Done reading resources.
Show resources in subtree (Root Device)...After reading.
 Root Device child on link 0 APIC_CLUSTER: 0
  APIC_CLUSTER: 0 child on link 0 APIC: 00
   APIC: 00
  PCI_DOMAIN: 0000 child on link 0 PCI: 00:00.0
  PCI_DOMAIN: 0000 resource base 0 size 0 align 0 gran 0 limit ffff flags 40040100 index 10000000
  PCI_DOMAIN: 0000 resource base 0 size 0 align 0 gran 0 limit ffffffff flags 40040200 index 10000100
   PCI: 00:00.0
   PCI: 00:01.0
   PCI: 00:01.0 resource base 0 size 4000000 align 26 gran 26 limit ffffffff flags 1200 index 10
   PCI: 00:01.0 resource base 0 size 80000 align 19 gran 19 limit ffffffff flags 200 index 14
   PCI: 00:1e.0 child on link 0 PCI: 01:08.0
   PCI: 00:1e.0 resource base 0 size 0 align 12 gran 12 limit ffff flags 80102 index 1c
   PCI: 00:1e.0 resource base 0 size 0 align 20 gran 20 limit ffffffff flags 81202 index 24
   PCI: 00:1e.0 resource base 0 size 0 align 20 gran 20 limit ffffffff flags 80202 index 20
    PCI: 01:08.0
    PCI: 01:08.0 resource base 0 size 1000 align 12 gran 12 limit ffffffff flags 200 index 10
    PCI: 01:08.0 resource base 0 size 40 align 6 gran 6 limit ffff flags 100 index 14
   PCI: 00:1f.0 child on link 0 PNP: 002e.0
   PCI: 00:1f.0 resource base 0 size 1000 align 0 gran 0 limit 0 flags c0040100 index 10000000
   PCI: 00:1f.0 resource base ff800000 size 800000 align 0 gran 0 limit 0 flags c0040200 index 10000100
   PCI: 00:1f.0 resource base fec00000 size 1000 align 0 gran 0 limit 0 flags c0000200 index 3
    PNP: 002e.0
    PNP: 002e.0 resource base 3f0 size 0 align 0 gran 0 limit 0 flags c0000100 index 60
    PNP: 002e.0 resource base 6 size 0 align 0 gran 0 limit 0 flags c0000400 index 70
    PNP: 002e.0 resource base 2 size 0 align 0 gran 0 limit 0 flags c0000800 index 74
    PNP: 002e.3
    PNP: 002e.3 resource base 378 size 0 align 0 gran 0 limit 0 flags c0000100 index 60
    PNP: 002e.3 resource base 7 size 0 align 0 gran 0 limit 0 flags c0000400 index 70
    PNP: 002e.3 resource base 4 size 0 align 0 gran 0 limit 0 flags c0000800 index 74
    PNP: 002e.4
    PNP: 002e.4 resource base 3f8 size 0 align 0 gran 0 limit 0 flags c0000100 index 60
    PNP: 002e.4 resource base 4 size 0 align 0 gran 0 limit 0 flags c0000400 index 70
    PNP: 002e.5
    PNP: 002e.7
    PNP: 002e.7 resource base 1 size 0 align 0 gran 0 limit 0 flags c0000400 index 70
    PNP: 002e.7 resource base c size 0 align 0 gran 0 limit 0 flags c0000400 index 72
    PNP: 002e.9
    PNP: 002e.a
    PNP: 002e.a resource base 800 size 0 align 0 gran 0 limit 0 flags c0000100 index 60
    PNP: 002e.b
   PCI: 00:1f.1
   PCI: 00:1f.1 resource base 0 size 10 align 4 gran 4 limit ffff flags 100 index 20
   PCI: 00:1f.2
   PCI: 00:1f.2 resource base 0 size 20 align 5 gran 5 limit ffff flags 100 index 20
   PCI: 00:1f.3
   PCI: 00:1f.3 resource base 0 size 10 align 4 gran 4 limit ffff flags 100 index 20
   PCI: 00:1f.4
   PCI: 00:1f.4 resource base 0 size 20 align 5 gran 5 limit ffff flags 100 index 20
   PCI: 00:1f.5
   PCI: 00:1f.5 resource base 0 size 100 align 8 gran 8 limit ffff flags 100 index 10
   PCI: 00:1f.5 resource base 0 size 40 align 6 gran 6 limit ffff flags 100 index 14
   PCI: 00:1f.6
PCI_DOMAIN: 0000 compute_resources_io: base: 0 size: 0 align: 0 gran: 0 limit: ffff
PCI: 00:1e.0 compute_resources_io: base: 0 size: 0 align: 12 gran: 12 limit: ffff
PCI: 01:08.0 14 *  [0x0 - 0x3f] io
PCI: 00:1e.0 compute_resources_io: base: 40 size: 1000 align: 12 gran: 12 limit: ffff done
PCI: 00:1e.0 1c *  [0x0 - 0xfff] io
PCI: 00:1f.5 10 *  [0x1000 - 0x10ff] io
PCI: 00:1f.5 14 *  [0x1400 - 0x143f] io
PCI: 00:1f.2 20 *  [0x1440 - 0x145f] io
PCI: 00:1f.4 20 *  [0x1460 - 0x147f] io
PCI: 00:1f.1 20 *  [0x1480 - 0x148f] io
PCI: 00:1f.3 20 *  [0x1490 - 0x149f] io
PCI_DOMAIN: 0000 compute_resources_io: base: 14a0 size: 14a0 align: 12 gran: 0 limit: ffff done
PCI_DOMAIN: 0000 compute_resources_mem: base: 0 size: 0 align: 0 gran: 0 limit: ffffffff
PCI: 00:1e.0 compute_resources_prefmem: base: 0 size: 0 align: 20 gran: 20 limit: ffffffff
PCI: 00:1e.0 compute_resources_prefmem: base: 0 size: 0 align: 20 gran: 20 limit: ffffffff done
PCI: 00:1e.0 compute_resources_mem: base: 0 size: 0 align: 20 gran: 20 limit: ffffffff
PCI: 01:08.0 10 *  [0x0 - 0xfff] mem
PCI: 00:1e.0 compute_resources_mem: base: 1000 size: 100000 align: 20 gran: 20 limit: ffffffff done
PCI: 00:01.0 10 *  [0x0 - 0x3ffffff] prefmem
PCI: 00:1e.0 20 *  [0x4000000 - 0x40fffff] mem
PCI: 00:01.0 14 *  [0x4100000 - 0x417ffff] mem
PCI_DOMAIN: 0000 compute_resources_mem: base: 4180000 size: 4180000 align: 26 gran: 0 limit: ffffffff done
avoid_fixed_resources: PCI_DOMAIN: 0000
avoid_fixed_resources:@PCI_DOMAIN: 0000 10000000 limit 0000ffff
avoid_fixed_resources:@PCI_DOMAIN: 0000 10000100 limit ffffffff
constrain_resources: PCI_DOMAIN: 0000
constrain_resources: PCI: 00:00.0
constrain_resources: PCI: 00:01.0
constrain_resources: PCI: 00:1e.0
constrain_resources: PCI: 01:08.0
constrain_resources: PCI: 00:1f.0
constrain_resources: PNP: 002e.0
skipping PNP: 002e.0 at 60 fixed resource, size=0!
skipping PNP: 002e.0 at 70 fixed resource, size=0!
skipping PNP: 002e.0 at 74 fixed resource, size=0!
constrain_resources: PNP: 002e.3
skipping PNP: 002e.3 at 60 fixed resource, size=0!
skipping PNP: 002e.3 at 70 fixed resource, size=0!
skipping PNP: 002e.3 at 74 fixed resource, size=0!
constrain_resources: PNP: 002e.4
skipping PNP: 002e.4 at 60 fixed resource, size=0!
skipping PNP: 002e.4 at 70 fixed resource, size=0!
constrain_resources: PNP: 002e.7
skipping PNP: 002e.7 at 70 fixed resource, size=0!
skipping PNP: 002e.7 at 72 fixed resource, size=0!
constrain_resources: PNP: 002e.a
skipping PNP: 002e.a at 60 fixed resource, size=0!
constrain_resources: PCI: 00:1f.1
constrain_resources: PCI: 00:1f.2
constrain_resources: PCI: 00:1f.3
constrain_resources: PCI: 00:1f.4
constrain_resources: PCI: 00:1f.5
avoid_fixed_resources2: PCI_DOMAIN: 0000 at 10000000 limit 0000ffff
	lim->base 00001000 lim->limit 0000ffff
avoid_fixed_resources2: PCI_DOMAIN: 0000 at 10000100 limit ffffffff
	lim->base 00000000 lim->limit febfffff
Setting resources...
PCI_DOMAIN: 0000 allocate_resources_io: base:1000 size:14a0 align:12 gran:0 limit:ffff
Assigned: PCI: 00:1e.0 1c *  [0x1000 - 0x1fff] io
Assigned: PCI: 00:1f.5 10 *  [0x2000 - 0x20ff] io
Assigned: PCI: 00:1f.5 14 *  [0x2400 - 0x243f] io
Assigned: PCI: 00:1f.2 20 *  [0x2440 - 0x245f] io
Assigned: PCI: 00:1f.4 20 *  [0x2460 - 0x247f] io
Assigned: PCI: 00:1f.1 20 *  [0x2480 - 0x248f] io
Assigned: PCI: 00:1f.3 20 *  [0x2490 - 0x249f] io
PCI_DOMAIN: 0000 allocate_resources_io: next_base: 24a0 size: 14a0 align: 12 gran: 0 done
PCI: 00:1e.0 allocate_resources_io: base:1000 size:1000 align:12 gran:12 limit:ffff
Assigned: PCI: 01:08.0 14 *  [0x1000 - 0x103f] io
PCI: 00:1e.0 allocate_resources_io: next_base: 1040 size: 1000 align: 12 gran: 12 done
PCI_DOMAIN: 0000 allocate_resources_mem: base:f8000000 size:4180000 align:26 gran:0 limit:febfffff
Assigned: PCI: 00:01.0 10 *  [0xf8000000 - 0xfbffffff] prefmem
Assigned: PCI: 00:1e.0 20 *  [0xfc000000 - 0xfc0fffff] mem
Assigned: PCI: 00:01.0 14 *  [0xfc100000 - 0xfc17ffff] mem
PCI_DOMAIN: 0000 allocate_resources_mem: next_base: fc180000 size: 4180000 align: 26 gran: 0 done
PCI: 00:1e.0 allocate_resources_prefmem: base:febfffff size:0 align:20 gran:20 limit:febfffff
PCI: 00:1e.0 allocate_resources_prefmem: next_base: febfffff size: 0 align: 20 gran: 20 done
PCI: 00:1e.0 allocate_resources_mem: base:fc000000 size:100000 align:20 gran:20 limit:febfffff
Assigned: PCI: 01:08.0 10 *  [0xfc000000 - 0xfc000fff] mem
PCI: 00:1e.0 allocate_resources_mem: next_base: fc001000 size: 100000 align: 20 gran: 20 done
Root Device assign_resources, bus 0 link: 0
Setting RAM size to 256 MB
Allocating 1MB RAM for VGA
PCI_DOMAIN: 0000 assign_resources, bus 0 link: 0
PCI: 00:01.0 10 <- [0x00f8000000 - 0x00fbffffff] size 0x04000000 gran 0x1a prefmem
PCI: 00:01.0 14 <- [0x00fc100000 - 0x00fc17ffff] size 0x00080000 gran 0x13 mem
PCI: 00:1e.0 1c <- [0x0000001000 - 0x0000001fff] size 0x00001000 gran 0x0c bus 01 io
PCI: 00:1e.0 24 <- [0x00febfffff - 0x00febffffe] size 0x00000000 gran 0x14 bus 01 prefmem
PCI: 00:1e.0 20 <- [0x00fc000000 - 0x00fc0fffff] size 0x00100000 gran 0x14 bus 01 mem
PCI: 00:1e.0 assign_resources, bus 1 link: 0
PCI: 01:08.0 10 <- [0x00fc000000 - 0x00fc000fff] size 0x00001000 gran 0x0c mem
PCI: 01:08.0 14 <- [0x0000001000 - 0x000000103f] size 0x00000040 gran 0x06 io
PCI: 00:1e.0 assign_resources, bus 1 link: 0
PCI: 00:1f.0 assign_resources, bus 0 link: 0
PNP: 002e.0 missing set_resources
PNP: 002e.3 missing set_resources
PNP: 002e.4 missing set_resources
PNP: 002e.7 missing set_resources
PNP: 002e.a missing set_resources
PCI: 00:1f.0 assign_resources, bus 0 link: 0
PCI: 00:1f.1 20 <- [0x0000002480 - 0x000000248f] size 0x00000010 gran 0x04 io
PCI: 00:1f.2 20 <- [0x0000002440 - 0x000000245f] size 0x00000020 gran 0x05 io
PCI: 00:1f.3 20 <- [0x0000002490 - 0x000000249f] size 0x00000010 gran 0x04 io
PCI: 00:1f.4 20 <- [0x0000002460 - 0x000000247f] size 0x00000020 gran 0x05 io
PCI: 00:1f.5 10 <- [0x0000002000 - 0x00000020ff] size 0x00000100 gran 0x08 io
PCI: 00:1f.5 14 <- [0x0000002400 - 0x000000243f] size 0x00000040 gran 0x06 io
PCI_DOMAIN: 0000 assign_resources, bus 0 link: 0
Root Device assign_resources, bus 0 link: 0
Done setting resources.
Show resources in subtree (Root Device)...After assigning values.
 Root Device child on link 0 APIC_CLUSTER: 0
  APIC_CLUSTER: 0 child on link 0 APIC: 00
   APIC: 00
  PCI_DOMAIN: 0000 child on link 0 PCI: 00:00.0
  PCI_DOMAIN: 0000 resource base 1000 size 14a0 align 12 gran 0 limit ffff flags 40040100 index 10000000
  PCI_DOMAIN: 0000 resource base f8000000 size 4180000 align 26 gran 0 limit febfffff flags 40040200 index 10000100
  PCI_DOMAIN: 0000 resource base 0 size a0000 align 0 gran 0 limit 0 flags e0004200 index a
  PCI_DOMAIN: 0000 resource base c0000 size fe40000 align 0 gran 0 limit 0 flags e0004200 index b
   PCI: 00:00.0
   PCI: 00:01.0
   PCI: 00:01.0 resource base f8000000 size 4000000 align 26 gran 26 limit febfffff flags 60001200 index 10
   PCI: 00:01.0 resource base fc100000 size 80000 align 19 gran 19 limit febfffff flags 60000200 index 14
   PCI: 00:1e.0 child on link 0 PCI: 01:08.0
   PCI: 00:1e.0 resource base 1000 size 1000 align 12 gran 12 limit ffff flags 60080102 index 1c
   PCI: 00:1e.0 resource base febfffff size 0 align 20 gran 20 limit febfffff flags 60081202 index 24
   PCI: 00:1e.0 resource base fc000000 size 100000 align 20 gran 20 limit febfffff flags 60080202 index 20
    PCI: 01:08.0
    PCI: 01:08.0 resource base fc000000 size 1000 align 12 gran 12 limit febfffff flags 60000200 index 10
    PCI: 01:08.0 resource base 1000 size 40 align 6 gran 6 limit ffff flags 60000100 index 14
   PCI: 00:1f.0 child on link 0 PNP: 002e.0
   PCI: 00:1f.0 resource base 0 size 1000 align 0 gran 0 limit 0 flags c0040100 index 10000000
   PCI: 00:1f.0 resource base ff800000 size 800000 align 0 gran 0 limit 0 flags c0040200 index 10000100
   PCI: 00:1f.0 resource base fec00000 size 1000 align 0 gran 0 limit 0 flags c0000200 index 3
    PNP: 002e.0
    PNP: 002e.0 resource base 3f0 size 0 align 0 gran 0 limit 0 flags c0000100 index 60
    PNP: 002e.0 resource base 6 size 0 align 0 gran 0 limit 0 flags c0000400 index 70
    PNP: 002e.0 resource base 2 size 0 align 0 gran 0 limit 0 flags c0000800 index 74
    PNP: 002e.3
    PNP: 002e.3 resource base 378 size 0 align 0 gran 0 limit 0 flags c0000100 index 60
    PNP: 002e.3 resource base 7 size 0 align 0 gran 0 limit 0 flags c0000400 index 70
    PNP: 002e.3 resource base 4 size 0 align 0 gran 0 limit 0 flags c0000800 index 74
    PNP: 002e.4
    PNP: 002e.4 resource base 3f8 size 0 align 0 gran 0 limit 0 flags c0000100 index 60
    PNP: 002e.4 resource base 4 size 0 align 0 gran 0 limit 0 flags c0000400 index 70
    PNP: 002e.5
    PNP: 002e.7
    PNP: 002e.7 resource base 1 size 0 align 0 gran 0 limit 0 flags c0000400 index 70
    PNP: 002e.7 resource base c size 0 align 0 gran 0 limit 0 flags c0000400 index 72
    PNP: 002e.9
    PNP: 002e.a
    PNP: 002e.a resource base 800 size 0 align 0 gran 0 limit 0 flags c0000100 index 60
    PNP: 002e.b
   PCI: 00:1f.1
   PCI: 00:1f.1 resource base 2480 size 10 align 4 gran 4 limit ffff flags 60000100 index 20
   PCI: 00:1f.2
   PCI: 00:1f.2 resource base 2440 size 20 align 5 gran 5 limit ffff flags 60000100 index 20
   PCI: 00:1f.3
   PCI: 00:1f.3 resource base 2490 size 10 align 4 gran 4 limit ffff flags 60000100 index 20
   PCI: 00:1f.4
   PCI: 00:1f.4 resource base 2460 size 20 align 5 gran 5 limit ffff flags 60000100 index 20
   PCI: 00:1f.5
   PCI: 00:1f.5 resource base 2000 size 100 align 8 gran 8 limit ffff flags 60000100 index 10
   PCI: 00:1f.5 resource base 2400 size 40 align 6 gran 6 limit ffff flags 60000100 index 14
   PCI: 00:1f.6
Done allocating resources.
Enabling resources...
PCI: 00:00.0 cmd <- 06
PCI: 00:01.0 subsystem <- 8086/00
PCI: 00:01.0 cmd <- 07
PCI: 00:1e.0 bridge ctrl <- 0003
PCI: 00:1e.0 cmd <- 07
PCI: 01:08.0 cmd <- 03
PCI: 00:1f.0 cmd <- 0f
PNP: 002e.0 missing enable_resources
PNP: 002e.3 missing enable_resources
PNP: 002e.4 missing enable_resources
PNP: 002e.7 missing enable_resources
PNP: 002e.a missing enable_resources
PCI: 00:1f.1 cmd <- 01
PCI: 00:1f.2 cmd <- 01
PCI: 00:1f.3 subsystem <- 8086/00
PCI: 00:1f.3 cmd <- 01
PCI: 00:1f.4 cmd <- 01
PCI: 00:1f.5 cmd <- 01
done.
Initializing devices...
Root Device init
APIC_CLUSTER: 0 init
malloc Enter, size 68, free_mem_ptr 00120a5c
malloc 00120a5c
Initializing CPU #0
CPU: vendor Intel device 68a
CPU: family 06, model 08, stepping 0a
Enabling cache

Setting fixed MTRRs(0-88) Type: UC
Setting fixed MTRRs(0-16) Type: WB
Setting fixed MTRRs(24-88) Type: WB
DONE fixed MTRRs
call enable_fixed_mtrr()
Setting variable MTRR 0, base:    0MB, range:  128MB, type WB
ADDRESS_MASK_HIGH=0xf
Setting variable MTRR 1, base:  128MB, range:   64MB, type WB
ADDRESS_MASK_HIGH=0xf
Setting variable MTRR 2, base:  192MB, range:   32MB, type WB
ADDRESS_MASK_HIGH=0xf
Setting variable MTRR 3, base:  224MB, range:   16MB, type WB
ADDRESS_MASK_HIGH=0xf
Setting variable MTRR 4, base:  240MB, range:    8MB, type WB
ADDRESS_MASK_HIGH=0xf
Setting variable MTRR 5, base:  248MB, range:    4MB, type WB
ADDRESS_MASK_HIGH=0xf
Running out of variable MTRRs!
Zero-sized MTRR range @0KB
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 = 0x0000068a pf=0x00000010 rev = 0x00000000
Disabling local apic...done.
CPU #0 initialized
PCI: 00:00.0 init
Northbridge init
PCI: 00:01.0 init
Check CBFS header at fffeffe0
magic is 4f524243
Found CBFS header at fffeffe0
Check fallback/coreboot_ram
CBFS: follow chain: fff80000 + 38 + 9aa7 + align -> fff89b00
Check fallback/payload
CBFS: follow chain: fff89b00 + 38 + cc9b + align -> fff96800
Check pci8086,7125.rom
In cbfs, rom address for PCI: 00:01.0 = fff96838
PCI Expansion ROM, signature 0xaa55, INIT size 0x8000, data ptr 0x004c
PCI ROM Image, Vendor 8086, Device 7125,
PCI ROM Image,  Class Code 030000, Code Type 00
copying VGA ROM Image from fff96838 to 0xc0000, 0x8000 bytes
Real mode stub @00000600: 606 bytes
Calling Option ROM...
oprom: INT# 0x15
oprom: eax: 0000d042 ebx: 0000ff10 ecx: 00000000 edx: 0000ffff
oprom: ebp: 00110fe4 esp: 00000fda edi: 00000000 esi: 00000000
oprom:  ip: 791b      cs: c000   flags: 00000003
Unknown INT15 function d042!
int15 call returned error.
... Option ROM returned.
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
PCI: 00:1f.1 init
IDE0: Primary IDE interface is enabled
IDE1: Secondary IDE interface is enabled
PCI: 00:1f.2 init
USB: Setting up controller.. done.
PCI: 00:1f.3 init
Check CBFS header at fffeffe0
magic is 4f524243
Found CBFS header at fffeffe0
Check fallback/coreboot_ram
CBFS: follow chain: fff80000 + 38 + 9aa7 + align -> fff89b00
Check fallback/payload
CBFS: follow chain: fff89b00 + 38 + cc9b + align -> fff96800
Check pci8086,7125.rom
CBFS: follow chain: fff96800 + 38 + 8000 + align -> fff9e840
Check 
CBFS: follow chain: fff9e840 + 28 + 51778 + align -> ffff0000
CBFS:  Could not find file pci8086,2443.rom
PCI: 00:1f.4 init
USB: Setting up controller.. done.
Devices initialized
Show all devs...After init.
Root Device: enabled 1
APIC_CLUSTER: 0: enabled 1
APIC: 00: enabled 1
PCI_DOMAIN: 0000: enabled 1
PCI: 00:00.0: enabled 1
PCI: 00:01.0: enabled 1
PCI: 00:1e.0: enabled 1
PCI: 00:1f.0: enabled 1
PNP: 002e.0: enabled 1
PNP: 002e.3: enabled 1
PNP: 002e.4: enabled 1
PNP: 002e.5: enabled 0
PNP: 002e.7: enabled 1
PNP: 002e.9: enabled 0
PNP: 002e.a: enabled 1
PNP: 002e.b: enabled 0
PCI: 00:1f.1: enabled 1
PCI: 00:1f.2: enabled 1
PCI: 00:1f.3: enabled 1
PCI: 00:1f.4: enabled 1
PCI: 00:1f.5: enabled 1
PCI: 00:1f.6: enabled 0
PCI: 01:08.0: enabled 1
CPU: 00: enabled 1
Initializing CBMEM area to 0xfef0000 (65536 bytes)
Adding CBMEM entry as no. 1
Moving GDT to 0fef0200...ok
High Tables Base is fef0000.
Copying Interrupt Routing Table to 0x000f0000... done.
Adding CBMEM entry as no. 2
Copying Interrupt Routing Table to 0x0fef0400... done.
PIRQ table: 144 bytes.
Multiboot Information structure has been written.
Adding CBMEM entry as no. 3
Writing high table forward entry at 0x00000500
Wrote coreboot table at: 00000500 - 00000518  checksum dbef
New low_table_end: 0x00000518
Now going to write high coreboot table at 0x0fef1400
rom_table_end = 0x0fef1400
Adjust low_table_end from 0x00000518 to 0x00001000 
Adjust rom_table_end from 0x0fef1400 to 0x0ff00000 
Adding high table area
coreboot memory table:
 0. 0000000000000000-0000000000000fff: CONFIGURATION TABLES
 1. 0000000000001000-000000000009ffff: RAM
 2. 00000000000c0000-000000000feeffff: RAM
 3. 000000000fef0000-000000000fefffff: CONFIGURATION TABLES
Wrote coreboot table at: 0fef1400 - 0fef1580  checksum d65c
coreboot table: 384 bytes.
 0. FREE SPACE 0fef3400 0000cc00
 1. GDT        0fef0200 00000200
 2. IRQ TABLE  0fef0400 00001000
 3. COREBOOT   0fef1400 00002000
Check CBFS header at fffeffe0
magic is 4f524243
Found CBFS header at fffeffe0
Check fallback/coreboot_ram
CBFS: follow chain: fff80000 + 38 + 9aa7 + align -> fff89b00
Check fallback/payload
Got a payload
Loading segment from rom address 0xfff89b38
  parameter section (skipped)
Loading segment from rom address 0xfff89b54
  data (compression=1)
malloc Enter, size 36, free_mem_ptr 00120aa0
malloc 00120aa0
  New segment dstaddr 0x100000 memsize 0x16c3d0 srcaddr 0xfff89bd8 filesize 0xcbcd
  (cleaned up) New segment addr 0x100000 size 0x16c3d0 offset 0xfff89bd8 filesize 0xcbcd
Loading segment from rom address 0xfff89b70
  data (compression=1)
malloc Enter, size 36, free_mem_ptr 00120ac4
malloc 00120ac4
  New segment dstaddr 0x26c3d0 memsize 0x48 srcaddr 0xfff967a5 filesize 0x2e
  (cleaned up) New segment addr 0x26c3d0 size 0x48 offset 0xfff967a5 filesize 0x2e
Loading segment from rom address 0xfff89b8c
  Entry Point 0x00100000
Loading Segment: addr: 0x0000000000100000 memsz: 0x000000000016c3d0 filesz: 0x000000000000cbcd
lb: [0x0000000000100000, 0x0000000000124000)
segment: [0x0000000000100000, 0x000000000010cbcd, 0x000000000026c3d0)
 bounce: [0x000000000fd5fc30, 0x000000000fd6c7fd, 0x000000000fecc000)
Post relocation: addr: 0x000000000fd5fc30 memsz: 0x000000000016c3d0 filesz: 0x000000000000cbcd
using LZMA
[ 0x0fd5fc30, 0fd7c790, 0x0fecc000) <- fff89bd8
Clearing Segment: addr: 0x000000000fd7c790 memsz: 0x000000000014f870
dest 0fd5fc30, end 0fecc000, bouncebuffer fd5fc30
move suffix around: from fd83c30, to 124000, amount: 1483d0
Loading Segment: addr: 0x000000000026c3d0 memsz: 0x0000000000000048 filesz: 0x000000000000002e
lb: [0x0000000000100000, 0x0000000000124000)
Post relocation: addr: 0x000000000026c3d0 memsz: 0x0000000000000048 filesz: 0x000000000000002e
using LZMA
[ 0x0026c3d0, 0026c418, 0x0026c418) <- fff967a5
dest 0026c3d0, end 0026c418, bouncebuffer fd5fc30
Loaded segments
Jumping to boot code at 100000
entry    = 0x00100000
lb_start = 0x00100000
lb_size  = 0x00024000
adjust   = 0x0fdcc000
buffer   = 0x0fd5fc30
     elf_boot_notes = 0x00112b98
adjusted_boot_notes = 0x0fedeb98
FILO version 0.6.0 (joe at smitty2m) Sat May 29 16:37:42 EDT 2010
00:1f.4 2444:8086.4 UHCI controller
00:1f.2 2442:8086.2 UHCI controller
fullspeed device
device 0x05e3:0x0604 is USB 1.1 (Hub)
lowspeed device
device 0x046d:0xc01b is USB 2.0 (HID)
NOTICE: USB mice are not supported.
lowspeed device
device 0x413c:0x2003 is USB 1.10 (HID)
  Keyboard has not supported layout (country code 00)
  Keyboard layout 'us'
lowspeed device
device 0x0d3d:0x0006 is USB 1.10 
NOTICE: This driver defaults to using the first interface.
This might be the wrong choice and lead to limited functionality
of the device. Please report such a case to coreboot at coreboot.org
as you might be the first.
(HID)
  Keyboard has not supported layout (country code 00)
  Keyboard layout 'us'
ERROR: No such CMOS option (boot_devices)
Press <Enter> for default menu.lst (hdc1:/grub/grub.conf), or <Esc> for prompt... 5 4 3 
menu: hdc1:/grub/grub.conf
                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                ERROR: No such CMOS option (boot_default)
hdc: LBA 40GB: WDC WD400BB-00JHC0                      File not found.ERROR: No such CMOS option (boot_default)
                                                                                                                  FILO 0.6.0                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                    lqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqkx                                                                         xx                                                                         xx                                                                         xx                                                                         xx                                                                         xx                                                                         xx                                                                         xx                                                                         xx                                                                         xx                                                                         xx                                                                         xx                                                                         xmqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqj      Use the ^ and v keys to select which entry is highlighted.      Press enter to boot the selected OS, 'e' to edit the      commands before booting, 'a' to modify the kernel arguments      before booting, or 'c' for a command-line. Fedora (2.6.27.24-170.2.68.fc10.i686)                                   x   Fedora (2.6.27.5-117.fc10.i686)                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                    The highlighted entry will be booted automatically in 10 seconds.    The highlighted entry will be booted automatically in 9 seconds.    The highlighted entry will be booted automatically in 8 seconds.    The highlighted entry will be booted automatically in 7 seconds.    The highlighted entry will be booted automatically in 6 seconds.    The highlighted entry will be booted automatically in 5 seconds.    The highlighted entry will be booted automatically in 4 seconds.    The highlighted entry will be booted automatically in 3 seconds.                                                                                                                                                                                          FILO 0.6.0                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                    lqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqkx                                                                         xx                                                                         xx                                                                         xx                                                                         xx                                                                         xx                                                                         xx                                                                         xx                                                                         xx                                                                         xx                                                                         xx                                                                         xx                                                                         xmqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqj      Use the ^ and v keys to select which entry is highlighted.      Press 'b' to boot, 'e' to edit the selected command in the      boot sequence, 'c' for a command-line, 'o' to open a new line      after ('O' for before) the selected line, 'd' to remove the      selected line, or escape to go back to the main me root (hd2,0)                                                            x   kernel /vmlinuz-2.6.27.24-170.2.68.fc10.i686 ro root=/dev/VolGroup00/>   initrd /initrd-2.6.27.24-170.2.68.fc10.i686.img                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                            root (hd2,0)                                                             kernel /vmlinuz-2.6.27.24-170.2.68.fc10.i686 ro root=/dev/VolGroup00/>    [ Minimal BASH-like line editing is supported.  For the first word, TAB           lists possible command completions.                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                            ESC at any time cancels.  ENTER    at any time accepts your changes.]</VolGroup00/LogVol00 rhgb quiet 3                                                         3 console=tty0 console=ttyS0,115200n8                                                                                                                  FILO 0.6.0                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                    lqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqkx                                                                         xx                                                                         xx                                                                         xx                                                                         xx                                                                         xx                                                                         xx                                                                         xx                                                                         xx                                                                         xx                                                                         xx                                                                         xx                                                                         xmqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqj      Use the ^ and v keys to select which entry is highlighted.      Press 'b' to boot, 'e' to edit the selected command in the      boot sequence, 'c' for a command-line, 'o' to open a new line      after ('O' for before) the selected line, 'd' to remove the      selected line, or escape to go back to the main me root (hd2,0)                                                            x   kernel /vmlinuz-2.6.27.24-170.2.68.fc10.i686 ro root=/dev/VolGroup00/>   initrd /initrd-2.6.27.24-170.2.68.fc10.i686.img                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                            kernel /vmlinuz-2.6.27.24-170.2.68.fc10.i686 ro root=/dev/VolGroup00/>   root (hd2,0)                                                              Booting command-list                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                          root (hd2,0)kernel /vmlinuz-2.6.27.24-170.2.68.fc10.i686 ro root=/dev/VolGroup00/LogVol00 3 console=tty0 console=ttyS0,115200n8initrd /initrd-2.6.27.24-170.2.68.fc10.i686.img  Booting command-list                                                                                                                                          root (hd2,0)                                                                    kernel /vmlinuz-2.6.27.24-170.2.68.fc10.i686 ro root=/dev/VolGroup00/LogVol00 3  console=tty0 console=ttyS0,115200n8                                            initrd /initrd-2.6.27.24-170.2.68.fc10.i686.img                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                 Booting 'hdc1:/vmlinuz-2.6.27.24-170.2.68.fc10.i686 ro root=/dev/VolGroup00/Log Vol00 3 console=tty0 console=ttyS0,115200n8 initrd=hdc1:/initrd-2.6.27.24-170.2 .68.fc10.i686.img'                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                              Found Linux version 2.6.27.24-170.2.68.fc10.i686 (mockbuild at x86-4.fedora.phx.redhat.com) #1 SMP Wed May 20 23:10:16 EDT 2009 bzImage.Loading kernel... okLoading initrd... okJumping to entry point...Initializing cgroup subsys cpuset
Initializing cgroup subsys cpu
Linux version 2.6.27.24-170.2.68.fc10.i686 (mockbuild at x86-4.fedora.phx.redhat.com) (gcc version 4.3.2 20081105 (Red Hat 4.3.2-7) (GCC) ) #1 SMP Wed May 20 23:10:16 EDT 2009
PAT WC disabled due to known CPU erratum.
BIOS-provided physical RAM map:
 BIOS-e820: 0000000000000000 - 0000000000001000 type 16
 BIOS-e820: 0000000000001000 - 00000000000a0000 (usable)
 BIOS-e820: 00000000000c0000 - 000000000fef0000 (usable)
 BIOS-e820: 000000000fef0000 - 000000000ff00000 type 16
DMI not present or invalid.
last_pfn = 0xfef0 max_arch_pfn = 0x100000
WARNING: BIOS bug: CPU MTRRs don't cover all of memory, losing 2MB of RAM.
------------[ cut here ]------------
WARNING: at arch/x86/kernel/cpu/mtrr/main.c:1557 mtrr_trim_uncached_memory+0x295/0x2b6() (Not tainted)
Modules linked in:
Pid: 0, comm: swapper Not tainted 2.6.27.24-170.2.68.fc10.i686 #1
 [<c042ddfb>] warn_on_slowpath+0x65/0x8b
 [<c06ab53c>] ? _spin_unlock_irqrestore+0x1b/0x38
 [<c06ab53c>] ? _spin_unlock_irqrestore+0x1b/0x38
 [<c06ab543>] ? _spin_unlock_irqrestore+0x22/0x38
 [<c042e2f1>] ? release_console_sem+0x1bf/0x1c7
 [<c042e76c>] ? vprintk+0x2ce/0x2f3
 [<c06a96db>] ? printk+0xf/0x14
 [<c0824127>] mtrr_trim_uncached_memory+0x295/0x2b6
 [<c081f73b>] setup_arch+0x48f/0x947
 [<c042e76c>] ? vprintk+0x2ce/0x2f3
 [<c08218dd>] ? __reserve_early+0xe4/0xf8
 [<c06a96db>] ? printk+0xf/0x14
 [<c0819605>] start_kernel+0x73/0x2f0
 [<c0819080>] __init_begin+0x80/0x88
 =======================
---[ end trace 4eaa2a86a8e2da22 ]---
update e820 for mtrr
modified physical RAM map:
 modified: 0000000000000000 - 0000000000001000 type 16
 modified: 0000000000001000 - 00000000000a0000 (usable)
 modified: 00000000000c0000 - 000000000fc00000 (usable)
 modified: 000000000fc00000 - 000000000fef0000 (reserved)
 modified: 000000000fef0000 - 000000000ff00000 type 16
last_pfn = 0xfc00 max_arch_pfn = 0x100000
Using x86 segment limits to approximate NX protection
RAMDISK: 0fa01000 - 0fd825e9
Allocated new RAMDISK: 0097c000 - 00cfd5e9
Move RAMDISK from 000000000fa01000 - 000000000fd825e8 to 0097c000 - 00cfd5e8
ACPI Error (tbxfroot-0218): A valid RSDP was not found [20080609]
0MB HIGHMEM available.
252MB LOWMEM available.
  mapped low ram: 0 - 0fc00000
  low ram: 00000000 - 0fc00000
  bootmap 00002000 - 00003f80
(9 early reservations) ==> bootmem [0000000000 - 000fc00000]
  #0 [0000000000 - 0000001000]   BIOS data page ==> [0000000000 - 0000001000]
  #1 [0000001000 - 0000002000]    EX TRAMPOLINE ==> [0000001000 - 0000002000]
  #2 [0000006000 - 0000007000]       TRAMPOLINE ==> [0000006000 - 0000007000]
  #3 [0000400000 - 000097712c]    TEXT DATA BSS ==> [0000400000 - 000097712c]
  #4 [0000978000 - 000097c000]    INIT_PG_TABLE ==> [0000978000 - 000097c000]
  #5 [00000f6000 - 0000100000]    BIOS reserved ==> [00000f6000 - 0000100000]
  #6 [0000007000 - 0000008000]          PGTABLE ==> [0000007000 - 0000008000]
  #7 [000097c000 - 0000cfd5e9]      NEW RAMDISK ==> [000097c000 - 0000cfd5e9]
  #8 [0000002000 - 0000004000]          BOOTMAP ==> [0000002000 - 0000004000]
Zone PFN ranges:
  DMA      0x00000001 -> 0x00001000
  Normal   0x00001000 -> 0x0000fc00
  HighMem  0x0000fc00 -> 0x0000fc00
Movable zone start PFN for each node
early_node_map[2] active PFN ranges
    0: 0x00000001 -> 0x000000a0
    0: 0x000000c0 -> 0x0000fc00
Using APIC driver default
SMP: Allowing 1 CPUs, 0 hotplug CPUs
Local APIC disabled by BIOS -- you can enable it with "lapic"
PM: Registered nosave memory: 00000000000a0000 - 00000000000c0000
Allocating PCI resources starting at 10000000 (gap: ff00000:f0100000)
PERCPU: Allocating 41372 bytes of per cpu data
Built 1 zonelists in Zone order, mobility grouping on.  Total pages: 63975
Kernel command line: ro root=/dev/VolGroup00/LogVol00 3 console=tty0 console=ttyS0,115200n8
Enabling fast FPU save and restore... done.
Enabling unmasked SIMD FPU exception support... done.
Initializing CPU#0
PID hash table entries: 1024 (order: 10, 4096 bytes)
TSC: Using PIT calibration value
Detected 996.767 MHz processor.
Console: colour VGA+ 80x25
console [tty0] enabled
console [ttyS0] enabled
Dentry cache hash table entries: 32768 (order: 5, 131072 bytes)
Inode-cache hash table entries: 16384 (order: 4, 65536 bytes)
Memory: 246076k/258048k available (2748k kernel code, 11576k reserved, 1425k data, 416k init, 0k highmem)
virtual kernel memory layout:
    fixmap  : 0xffc57000 - 0xfffff000   (3744 kB)
    pkmap   : 0xff400000 - 0xff800000   (4096 kB)
    vmalloc : 0xd0800000 - 0xff3fe000   ( 747 MB)
    lowmem  : 0xc0000000 - 0xcfc00000   ( 252 MB)
      .init : 0xc0819000 - 0xc0881000   ( 416 kB)
      .data : 0xc06af12e - 0xc0813618   (1425 kB)
      .text : 0xc0400000 - 0xc06af12e   (2748 kB)
Checking if this processor honours the WP bit even in supervisor mode...Ok.
SLUB: Genslabs=12, HWalign=32, Order=0-3, MinObjects=0, CPUs=1, Nodes=1
Calibrating delay loop (skipped), value calculated using timer frequency.. 1993.53 BogoMIPS (lpj=996767)
Security Framework initialized
SELinux:  Initializing.
Mount-cache hash table entries: 512
Initializing cgroup subsys ns
Initializing cgroup subsys cpuacct
Initializing cgroup subsys devices
CPU: L1 I cache: 16K, L1 D cache: 16K
CPU: L2 cache: 256K
CPU serial number disabled.
Intel machine check architecture supported.
Intel machine check reporting enabled on CPU#0.
Checking 'hlt' instruction... OK.
SMP alternatives: switching to UP code
Freeing SMP alternatives: 14k freed
weird, boot CPU (#0) not listedby the BIOS.
SMP motherboard not detected.
Local APIC not detected. Using dummy APIC emulation.
SMP disabled
Brought up 1 CPUs
Total of 1 processors activated (1993.53 BogoMIPS).
net_namespace: 840 bytes
Booting paravirtualized kernel on bare hardware
Time:  4:58:54  Date: 06/11/10
NET: Registered protocol family 16
PCI: Using configuration type 1 for base access
ACPI: Interpreter disabled.
Linux Plug and Play Support v0.97 (c) Adam Belay
pnp: PnP ACPI: disabled
SCSI subsystem initialized
usbcore: registered new interface driver usbfs
usbcore: registered new interface driver hub
usbcore: registered new device driver usb
PCI: Probing PCI hardware
pci 0000:00:1f.0: quirk: region 0400-047f claimed by ICH4 ACPI/GPIO/TCO
pci 0000:00:1f.0: quirk: region 0500-053f claimed by ICH4 GPIO
pci 0000:01:08.0: PME# supported from D0 D1 D2 D3hot D3cold
pci 0000:01:08.0: PME# disabled
pci 0000:00:1e.0: transparent bridge
pci 0000:00:1f.0: PIIX/ICH IRQ router [8086/2440]
pci 0000:00:01.0: found PCI INT A -> IRQ 5
pci 0000:00:1f.2: found PCI INT D -> IRQ 9
pci 0000:00:1f.3: found PCI INT B -> IRQ 6
pci 0000:00:1f.3: sharing IRQ 6 with 0000:00:1f.5
pci 0000:00:1f.4: found PCI INT C -> IRQ 11
pci 0000:01:08.0: found PCI INT A -> IRQ 10
NetLabel: Initializing
NetLabel:  domain hash size = 128
NetLabel:  protocols = UNLABELED CIPSOv4
NetLabel:  unlabeled traffic allowed by default
tracer: 772 pages allocated for 65536 entries of 48 bytes
   actual entries 65620
ACPI Exception (utmutex-0263): AE_BAD_PARAMETER, Thread CF428000 could not acquire Mutex [1] [20080609]
pci 0000:00:1e.0: PCI bridge, secondary bus 0000:01
pci 0000:00:1e.0:   IO window: 0x1000-0x1fff
pci 0000:00:1e.0:   MEM window: 0xfc000000-0xfc0fffff
pci 0000:00:1e.0:   PREFETCH window: disabled
bus: 00 index 0 io port: [0, ffff]
bus: 00 index 1 mmio: [0, ffffffffffffffff]
bus: 01 index 0 io port: [1000, 1fff]
bus: 01 index 1 mmio: [fc000000, fc0fffff]
bus: 01 index 2 mmio: [0, 0]
bus: 01 index 3 io port: [0, ffff]
bus: 01 index 4 mmio: [0, ffffffffffffffff]
NET: Registered protocol family 2
IP route cache hash table entries: 2048 (order: 1, 8192 bytes)
TCP established hash table entries: 8192 (order: 4, 65536 bytes)
TCP bind hash table entries: 8192 (order: 4, 65536 bytes)
TCP: Hash tables configured (established 8192 bind 8192)
TCP reno registered
NET: Registered protocol family 1
checking if image is initramfs... it is
Freeing initrd memory: 3589k freed
platform rtc_cmos: registered platform RTC device (no PNP device found)
apm: BIOS not found.
audit: initializing netlink socket (disabled)
type=2000 audit(1276232334.944:1): initialized
HugeTLB registered 4 MB page size, pre-allocated 0 pages
VFS: Disk quotas dquot_6.5.1
Dquot-cache hash table entries: 1024 (order 0, 4096 bytes)
msgmni has been set to 488
Block layer SCSI generic (bsg) driver version 0.4 loaded (major 252)
io scheduler noop registered
io scheduler anticipatory registered
io scheduler deadline registered
io scheduler cfq registered (default)
pci 0000:01:08.0: Firmware left e100 interrupts enabled; disabling
pci_hotplug: PCI Hot Plug PCI Core version: 0.5
acpiphp: ACPI Hot Plug PCI Controller Driver version: 0.5
isapnp: Scanning for PnP cards...
isapnp: No Plug & Play device found
Non-volatile memory driver v1.2
Linux agpgart interface v0.103
agpgart-intel 0000:00:00.0: Intel i810 Chipset
agpgart-intel 0000:00:00.0: AGP aperture is 64M @ 0xf8000000
Serial: 8250/16550 driver4 ports, IRQ sharing enabled
?serial8250: ttyS0 at I/O 0x3f8 (irq = 0) is a 16550A
brd: module loaded
loop: module loaded
input: Macintosh mouse button emulation as /devices/virtual/input/input0
Driver 'sd' needs updating - please use bus_type methods
Driver 'sr' needs updating - please use bus_type methods
scsi0 : ata_piix
scsi1 : ata_piix
ata1: PATA max UDMA/100 cmd 0x1f0 ctl 0x3f6 bmdma 0x2480 irq 14
ata2: PATA max UDMA/100 cmd 0x170 ctl 0x376 bmdma 0x2488 irq 15
ata2.00: ATA-6: WDC WD400BB-00JHC0, 05.01C05, max UDMA/100
ata2.00: 78165360 sectors, multi 0: LBA 
ata2.00: limited to UDMA/33 due to 40-wire cable
ata2.00: configured for UDMA/33
scsi 1:0:0:0: Direct-Access     ATA      WDC WD400BB-00JH 05.0 PQ: 0 ANSI: 5
sd 1:0:0:0: [sda] 78165360 512-byte hardware sectors (40021 MB)
sd 1:0:0:0: [sda] Write Protect is off
sd 1:0:0:0: [sda] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA
sd 1:0:0:0: [sda] 78165360 512-byte hardware sectors (40021 MB)
sd 1:0:0:0: [sda] Write Protect is off
sd 1:0:0:0: [sda] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA
 sda: sda1 sda2
sd 1:0:0:0: [sda] Attached SCSI disk
sd 1:0:0:0: Attached scsi generic sg0 type 0
USB Universal Host Controller Interface driver v3.0
uhci_hcd 0000:00:1f.2: found PCI INT D -> IRQ 9
uhci_hcd 0000:00:1f.2: UHCI Host Controller
uhci_hcd 0000:00:1f.2: new USB bus registered, assigned bus number 1
uhci_hcd 0000:00:1f.2: irq 9, io base 0x00002440
usb usb1: configuration #1 chosen from 1 choice
hub 1-0:1.0: USB hub found
hub 1-0:1.0: 2 ports detected
Clocksource tsc unstable (delta = 106982795 ns)
usb usb1: New USB device found, idVendor=1d6b, idProduct=0001
usb usb1: New USB device strings: Mfr=3, Product=2, SerialNumber=1
usb usb1: Product: UHCI Host Controller
usb usb1: Manufacturer: Linux 2.6.27.24-170.2.68.fc10.i686 uhci_hcd
usb usb1: SerialNumber: 0000:00:1f.2
uhci_hcd 0000:00:1f.4: found PCI INT C -> IRQ 11
uhci_hcd 0000:00:1f.4: UHCI Host Controller
uhci_hcd 0000:00:1f.4: new USB bus registered, assigned bus number 2
uhci_hcd 0000:00:1f.4: irq 11, io base 0x00002460
usb usb2: configuration #1 chosen from 1 choice
hub 2-0:1.0: USB hub found
hub 2-0:1.0: 2 ports detected
usb 1-1: new full speed USB device using uhci_hcd and address 2
usb usb2: New USB device found, idVendor=1d6b, idProduct=0001
usb usb2: New USB device strings: Mfr=3, Product=2, SerialNumber=1
usb usb2: Product: UHCI Host Controller
usb usb2: Manufacturer: Linux 2.6.27.24-170.2.68.fc10.i686 uhci_hcd
usb usb2: SerialNumber: 0000:00:1f.4
PNP: No PS/2 controller found. Probing ports directly.
mice: PS/2 mouse device common for all mice
rtc_cmos rtc_cmos: rtc core: registered rtc_cmos as rtc0
rtc0: alarms up to one day
device-mapper: uevent: version 1.0.3
device-mapper: ioctl: 4.14.0-ioctl (2008-04-23) initialised: dm-devel at redhat.com
cpuidle: using governor ladder
cpuidle: using governor menu
usb 1-1: configuration #1 chosen from 1 choice
hub 1-1:1.0: USB hub found
hub 1-1:1.0: 4 ports detected
usb 1-1: New USB device found, idVendor=05e3, idProduct=0604
usb 1-1: New USB device strings: Mfr=0, Product=1, SerialNumber=0
usb 1-1: Product: USB Hub
usb 1-1.1: new low speed USB device using uhci_hcd and address 3
usb 1-1.1: configuration #1 chosen from 1 choice
usb 1-1.1: New USB device found, idVendor=046d, idProduct=c01b
usb 1-1.1: New USB device strings: Mfr=1, Product=2, SerialNumber=0
usb 1-1.1: Product: USB-PS/2 Optical Mouse
usb 1-1.1: Manufacturer: Logitech
usb 1-1.2: new low speed USB device using uhci_hcd and address 4
usb 1-1.2: configuration #1 chosen from 1 choice
usb 1-1.2: New USB device found, idVendor=413c, idProduct=2003
usb 1-1.2: New USB device strings: Mfr=1, Product=2, SerialNumber=0
usb 1-1.2: Product: Dell USB Keyboard
usb 1-1.2: Manufacturer: Dell
usb 1-1.4: new low speed USB device using uhci_hcd and address 5
usb 1-1.4: configuration #1 chosen from 1 choice
usb 1-1.4: New USB device found, idVendor=0d3d, idProduct=0006
usb 1-1.4: New USB device strings: Mfr=1, Product=2, SerialNumber=0
usb 1-1.4: Product: Generic KVM102UC
usb 1-1.4: Manufacturer: Tangtop
usbcore: registered new interface driver hiddev
input: Logitech USB-PS/2 Optical Mouse as /devices/pci0000:00/0000:00:1f.2/usb1/1-1/1-1.1/1-1.1:1.0/input/input1
input,hidraw0: USB HID v1.10 Mouse [Logitech USB-PS/2 Optical Mouse] on usb-0000:00:1f.2-1.1
input: Dell Dell USB Keyboard as /devices/pci0000:00/0000:00:1f.2/usb1/1-1/1-1.2/1-1.2:1.0/input/input2
input,hidraw1: USB HID v1.10 Keyboard [Dell Dell USB Keyboard] on usb-0000:00:1f.2-1.2
input: Tangtop Generic KVM102UC as /devices/pci0000:00/0000:00:1f.2/usb1/1-1/1-1.4/1-1.4:1.0/input/input3
input,hidraw2: USB HID v1.00 Keyboard [Tangtop Generic KVM102UC] on usb-0000:00:1f.2-1.4
input: Tangtop Generic KVM102UC as /devices/pci0000:00/0000:00:1f.2/usb1/1-1/1-1.4/1-1.4:1.1/input/input4
input,hidraw3: USB HID v1.00 Mouse [Tangtop Generic KVM102UC] on usb-0000:00:1f.2-1.4
usbcore: registered new interface driver usbhid
usbhid: v2.6:USB HID core driver
nf_conntrack version 0.5.0 (4096 buckets, 16384 max)
CONFIG_NF_CT_ACCT is deprecated and will be removed soon. Plase use
nf_conntrack.acct=1 kernel paramater, acct=1 nf_conntrack module option or
sysctl net.netfilter.nf_conntrack_acct=1 to enable it.
ip_tables: (C) 2000-2006 Netfilter Core Team
TCP cubic registered
Initializing XFRM netlink socket
NET: Registered protocol family 17
Using IPI No-Shortcut mode
registered taskstats version 1
  Magic number: 14:688:969
hidraw hidraw0: hash matches
Freeing unused kernel memory: 416k freed
Write protecting the kernel text: 2752k
Write protecting the kernel read-only data: 1176k
Mounting proc filesystem
Mounting sysfs filesystem
Creating /dev
Creating initial device nodes
Loading /lib/kbd/keymaps/i386/qwerty/us.map
Setting up hotplug.
Creating block device nodes.
Creating character device nodes.
Loading pata_acpi module
Loading ata_generic module
Making device-mapper control node
Scanning logical volumes
  Reading all physical volumes.  This may take a while...
  Found volume group "VolGroup00" using metadata type lvm2
Activating logical volumes
  2 logical volume(s) in volume group "VolGroup00" now active
Creating root device.
Mounting root filesystem.
EXT3-fs: INFO: recovery required on readonly filesystem.
EXT3-fs: write access will be enabled during recovery.
kjournald starting.  Commit interval 5 seconds
EXT3-fs: recovery complete.
EXT3-fs: mounted filesystem with ordered data mode.
Setting up other filesystems.
type=1404 audit(1276232339.637:2): enforcing=1 old_enforcing=0 auid=4294967295 ses=4294967295
type=1403 audit(1276232340.872:3): policy loaded auid=4294967295 ses=4294967295
Switching to new root and running init.
		Welcome to Fedora 
		Press 'I' to enter interactive startup.
Starting udev: G[  OK  ]
Setting hostname localhost.localdomain:  [  OK  ]
Setting up Logical Volume Management:   2 logical volume(s) in volume group "VolGroup00" now active
[  OK  ]
Checking filesystems
Checking all file systems.
[/sbin/fsck.ext3 (1) -- /] fsck.ext3 -a /dev/VolGroup00/LogVol00 
/dev/VolGroup00/LogVol00: clean, 67326/2354688 files, 609171/9412608 blocks
[/sbin/fsck.ext3 (1) -- /boot] fsck.ext3 -a /dev/sda1 
/boot: recovering journal
/boot: clean, 40/50200 files, 27058/200780 blocks
[  OK  ]
Remounting root filesystem in read-write mode:  [  OK  ]
Mounting local filesystems:  [  OK  ]
Enabling local filesystem quotas:  [  OK  ]
Enabling /etc/fstab swaps:  [  OK  ]
Entering non-interactive startup
Applying Intel CPU microcode update: [  OK  ]
Starting auditd: [  OK  ]
Starting portreserve: [  OK  ]
Starting system logger: [  OK  ]
Starting irqbalance: [  OK  ]
Starting rpcbind: [  OK  ]
Starting NFS statd: [  OK  ]
Starting RPC idmapd: [  OK  ]
Starting system message bus: [  OK  ]
Starting HAL daemon: [  OK  ]
Starting PC/SC smart card daemon (pcscd): [  OK  ]
Setting network parameters... [  OK  ]
Starting NetworkManager daemon: [  OK  ]
Starting setroubleshootd: [  OK  ]
Starting Bluetooth services:[  OK  ]
Starting sshd: [  OK  ]
ntpdate: Synchronizing with time server: [FAILED]
Starting ntpd: [  OK  ]
Starting sendmail: [  OK  ]
Starting sm-client: [  OK  ]
Starting crond: [  OK  ][  OK  ]
Starting kerneloops:[  OK  ]
Starting atd: [  OK  ][  OK  ]
Starting Avahi daemon... [  OK  ]
Starting cups: [  OK  ]

Fedora release 10 (Cambridge)
Kernel 2.6.27.24-170.2.68.fc10.i686 on an i686 (/dev/ttyS0)

localhost.localdomain login: 

From joe at settoplinux.org  Tue Jun 15 17:54:02 2010
From: joe at settoplinux.org (Joseph Smith)
Date: Tue, 15 Jun 2010 11:54:02 -0400
Subject: [coreboot] Serial Console only starts after reset
In-Reply-To: <7c81186dd4a181b1e0b5e6422f1935e3@imap.1and1.com>
References: <d3b3dbd0aff4456f420451fe44f5ddde@imap.1and1.com>	<4C176E64.50501@coresystems.de>
	<629e66cb159099658a0e4cef5b844934@imap.1and1.com>
	<4C17828D.9050808@coresystems.de>
	<1e8eccf4f0337df4a6cf194e132212ca@imap.1and1.com>
	<4C178B4E.6040705@coresystems.de>
	<7c81186dd4a181b1e0b5e6422f1935e3@imap.1and1.com>
Message-ID: <476421bf8b52e5ec5471840078560df1@imap.1and1.com>




On Tue, 15 Jun 2010 10:28:51 -0400, Joseph Smith <joe at settoplinux.org>
wrote:
> 
> 
> 
> On Tue, 15 Jun 2010 16:16:46 +0200, Stefan Reinauer
<stepan at coresystems.de>
> wrote:
>> On 6/15/10 4:07 PM, Joseph Smith wrote:
>>> When
>>> I cold boot it, if I hit the reset button before Linux starts, it
>> restarts
>>> with coreboot serial console just fine.
>>>
>>
>> Hm...
>>
>> Maybe 0x2e/0x4e are mapped to LPC after the SuperIO is configured (and
>> that mapping survives a reset)... that would be a southbridge init
issue.
>>
> Hmm, This is interesting. The first time I booted it, I had copied
romstage
> from another board that had:
> 
> #define SERIAL_DEV PNP_DEV(0x4e, SMSCSUPERIO_SP1)
> 
> And I got coreboot serial console (early_serial) just fine but when it
came
> to detecting and inializing the superio, I got all kinds of errors from
> coreboot about device not found.
> 
> So I changed it to 0x2e as described in the datasheet and detected with
> superiotool(vendor bios), and that is when this problem started. But now
> coreboot is happy, detects the device and the resource allocator is
happy,
> I just do not get early_serial on cold boot.
> 
> This is weird!
> 
>> Or, the hardware has to stabilize after power on before you can
>> configure the SuperIO.
>>
> Maybe?
> 
Hmm from page 142 in the datasheet, I need to figure out of there is a
pull-down resistor connected to the SYSOPT pin to use 0x2e or if there is a
pull-up resistor connected to the SYSOPT pin to use 0x4e. And once powered
up the configuration port base address can be changed through CR26 and
CR27.

I bet you that there is a pull-up resistor connected to the SYSOPT pin and
0x4e is supposed to be used. And the vendor bios changes this to 0x2e at
some point. That is what is throwing me off!

So I will try:

#define SERIAL_DEV PNP_DEV(0x4e, SMSCSUPERIO_SP1)

and change all the devices in devicetree.cb to 4e.

My question is does it need to get changed to 0x2e at some point? Or can I
just leave it at 0x4e? Will it matter to OS?

Thanks for all the brainstorming help Stefan and Ron.

-- 
Thanks,
Joseph Smith
Set-Top-Linux
www.settoplinux.org




From rminnich at gmail.com  Tue Jun 15 19:22:18 2010
From: rminnich at gmail.com (ron minnich)
Date: Tue, 15 Jun 2010 10:22:18 -0700
Subject: [coreboot] Serial Console only starts after reset
In-Reply-To: <476421bf8b52e5ec5471840078560df1@imap.1and1.com>
References: <d3b3dbd0aff4456f420451fe44f5ddde@imap.1and1.com>
	<4C176E64.50501@coresystems.de>
	<629e66cb159099658a0e4cef5b844934@imap.1and1.com>
	<4C17828D.9050808@coresystems.de>
	<1e8eccf4f0337df4a6cf194e132212ca@imap.1and1.com>
	<4C178B4E.6040705@coresystems.de>
	<7c81186dd4a181b1e0b5e6422f1935e3@imap.1and1.com>
	<476421bf8b52e5ec5471840078560df1@imap.1and1.com>
Message-ID: <AANLkTikEsV3SC2DDCRakleFoHP9e8MTEym8YxOHZV4Cn@mail.gmail.com>

On Tue, Jun 15, 2010 at 8:54 AM, Joseph Smith <joe at settoplinux.org> wrote:

> My question is does it need to get changed to 0x2e at some point? Or can I
> just leave it at 0x4e? Will it matter to OS?
>
> Thanks for all the brainstorming help Stefan and Ron.

Should not matter to OS IMHO ... the OS can probe for it pretty easily.

That's totally wacky if the vendor BIOS is doing that, but it's not
the worst such thing we've seen (by far).

ron



From mylesgw at gmail.com  Tue Jun 15 20:34:01 2010
From: mylesgw at gmail.com (Myles Watson)
Date: Tue, 15 Jun 2010 12:34:01 -0600
Subject: [coreboot] PATCH: Add support for Virtensys 2uRack and Napoli
In-Reply-To: <95EC52016CC5DE4896FD95FA7323A4DB152FFE468C@mr-burns.exchange.virtensys.com>
References: <95EC52016CC5DE4896FD95FA7323A4DB152FFE468C@mr-burns.exchange.virtensys.com>
Message-ID: <AANLkTimkLa9khl2Ln9uwZsXf6fBt8HO6A9yL2_gPfjht@mail.gmail.com>

On Mon, Jun 14, 2010 at 8:23 AM, Edwin Beasant
<edwin_beasant at virtensys.com> wrote:
> Add Virtensys as a Manufacturer to the build sytem, and add their products.
>
> Virtensys products use AMD Geode LX in configuration very similar to AMD
> Norwich designs.
>
> Virtensys boards differ in the following ways from the reference
> implementation.
>
> No PCI Physical Slots.
> Intel 1Gig Ethernet onboard.
> Pericom PCI->PCIe bridge onboard.
> Napoli represents the Blade range of products
> 2uRack represents the 2u Rackable products.
>
> Signed-off-by: Edwin Beasant edwin_beasant at virtensys.com

A couple of questions:

1.  Does this support make them both work perfectly?  Is there
anything left to fix?
2.  Why do we need a cmos.layout file if HAVE_OPTION_TABLE is N?
3.  Can we get rid of the commented out lines in the cmos.layout file
if it needs to stay?

Sorry I don't have the hardware to test, so I have to have more
information about how it's working before wanting to Ack.

Thanks,
Myles



From patrick at georgi-clan.de  Tue Jun 15 21:25:17 2010
From: patrick at georgi-clan.de (Patrick Georgi)
Date: Tue, 15 Jun 2010 21:25:17 +0200
Subject: [coreboot] [PATCH]libpayload: libc-style headers,
	some more functions
Message-ID: <4C17D39D.30504@georgi-clan.de>

Hi,

attached patch moves functions out of the huge libpayload.h into headers
according to libc/posix traditions, to simplify porting applications to
payloads.

It also adds a couple of functions:
strcasecmp, strncasecmp, strcat, strtol, strspn, strcspn, strtok_r,
strtok, perror, exit, getpagesize

baiyin cai, I added you to the recipients, as marc indicated that this
might overlap with your summer of code effort.

Comments are appreciated.

Signed-off-by: Patrick Georgi <patrick.georgi at coresystems.de>
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: 20100615-1-more-libc.diff
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20100615/677a1221/attachment.ksh>

From darmawan.salihun at gmail.com  Tue Jun 15 21:56:25 2010
From: darmawan.salihun at gmail.com (Darmawan Salihun)
Date: Wed, 16 Jun 2010 02:56:25 +0700
Subject: [coreboot] Winflashrom plans
Message-ID: <AANLkTilaa3TIrAedHzQs6DRWZrIba6NKx8UhTAp5otYc@mail.gmail.com>

Hello guys,

Sorry, I haven't been able to update Winflashrom for more than 3 years now.
I'm planning to add Windows 7 support next month.

Therefore, I'm looking for suggestions.

A bit of Winflashrom background of the currently available Winflashrom
(at flashrom.org):

The programming model:
a. User mode application:
    - Mostly "pure" flashrom source code recompiled with MinGW.
    - libpci recompiled with MinGW (for PCI access logic). This is
required because
       the PCI access functions in the Windows API is not guaranteed
(marked as obsolete),
       in Windows XP SP2 and Windows 2003 server back then.

b. Device driver:
    - Provides POSIX mmap() implementation in the kernel, i.e.
      provides an entrypoint for mmap() function to user mode application.
    - Provides direct I/O port access for libpci.

Well, the reason for these programming model is to reduce the burden
when moving to newer flash chip support because this programming model
"preserves" the POSIX API in the user mode application (the device
driver is generic enough).
Therefore, "only" the user mode application need to be recompiled to
support new flash chip.

Any suggestions on what to change from the current programming model?

Thanks,

Darmawan
-- 
--------------------------------------------------------------------
-= Human knowledge belongs to the world =-



From joe at settoplinux.org  Tue Jun 15 22:18:32 2010
From: joe at settoplinux.org (Joseph Smith)
Date: Tue, 15 Jun 2010 16:18:32 -0400
Subject: [coreboot] Winflashrom plans
In-Reply-To: <AANLkTilaa3TIrAedHzQs6DRWZrIba6NKx8UhTAp5otYc@mail.gmail.com>
References: <AANLkTilaa3TIrAedHzQs6DRWZrIba6NKx8UhTAp5otYc@mail.gmail.com>
Message-ID: <4C17E018.20907@settoplinux.org>

On 06/15/2010 03:56 PM, Darmawan Salihun wrote:
> Hello guys,
>
> Sorry, I haven't been able to update Winflashrom for more than 3 years now.
> I'm planning to add Windows 7 support next month.
>
Awesome, great to see :-)

-- 
Thanks,
Joseph Smith
Set-Top-Linux
www.settoplinux.org



From r.marek at assembler.cz  Wed Jun 16 00:27:29 2010
From: r.marek at assembler.cz (Rudolf Marek)
Date: Wed, 16 Jun 2010 00:27:29 +0200
Subject: [coreboot] rommcc bugs
Message-ID: <4C17FE51.5070009@assembler.cz>

Hi all,

While working on netconsole for ROMCC I noticed following:

int main(void)
{
	/* volatile */
	union {
		unsigned char  byte[2];
		unsigned short word;
	} value;

	value.byte[1] = 1;
}

./build/util/romcc/romcc -mcpu=p2 a.c

a.c:9.18:
0x86bb968 tuple      Internal compiler error: tuple used
Aborted

Second problem is more complex:

romstage.c:74.0:
Internal compiler error: constant for unknown type


The romstage 74 is end... I will try to come with some testcase for the second 
problem later or with the a patch that exhibits the problem.

Please Eric can you help,

Thanks,
Rudolf



From mylesgw at gmail.com  Wed Jun 16 00:36:08 2010
From: mylesgw at gmail.com (Myles Watson)
Date: Tue, 15 Jun 2010 16:36:08 -0600
Subject: [coreboot] rommcc bugs
In-Reply-To: <4C17FE51.5070009@assembler.cz>
References: <4C17FE51.5070009@assembler.cz>
Message-ID: <AANLkTinpCv9MUfBYOnqme9fPhPSs_p2Ev0XXZL5d-sNh@mail.gmail.com>

On Tue, Jun 15, 2010 at 4:27 PM, Rudolf Marek <r.marek at assembler.cz> wrote:
> Hi all,
>
> While working on netconsole for ROMCC I noticed following:
>
> int main(void)
> {
> ? ? ? ?/* volatile */
> ? ? ? ?union {
> ? ? ? ? ? ? ? ?unsigned char ?byte[2];
> ? ? ? ? ? ? ? ?unsigned short word;
> ? ? ? ?} value;
>
> ? ? ? ?value.byte[1] = 1;
> }
>
> ./build/util/romcc/romcc -mcpu=p2 a.c
>
> a.c:9.18:
> 0x86bb968 tuple ? ? ?Internal compiler error: tuple used
This case looks familiar.

>From this message:
http://www.mail-archive.com/coreboot at coreboot.org/msg22555.html

> Looking at the rest fragment that has been passed around I think the
> actual bug is that romcc allows non-static non-const arrays to be
> declared.  I can not find any indication that I ever added support for
> this when I wrote romcc.

Thanks,
Myles



From joe at settoplinux.org  Wed Jun 16 00:37:45 2010
From: joe at settoplinux.org (Joseph Smith)
Date: Tue, 15 Jun 2010 18:37:45 -0400
Subject: [coreboot] Serial Console only starts after reset
In-Reply-To: <476421bf8b52e5ec5471840078560df1@imap.1and1.com>
References: <d3b3dbd0aff4456f420451fe44f5ddde@imap.1and1.com>	<4C176E64.50501@coresystems.de>	<629e66cb159099658a0e4cef5b844934@imap.1and1.com>	<4C17828D.9050808@coresystems.de>	<1e8eccf4f0337df4a6cf194e132212ca@imap.1and1.com>	<4C178B4E.6040705@coresystems.de>	<7c81186dd4a181b1e0b5e6422f1935e3@imap.1and1.com>
	<476421bf8b52e5ec5471840078560df1@imap.1and1.com>
Message-ID: <4C1800B9.5000200@settoplinux.org>

On 06/15/2010 11:54 AM, Joseph Smith wrote:
>
>
>
> On Tue, 15 Jun 2010 10:28:51 -0400, Joseph Smith<joe at settoplinux.org>
> wrote:
>>
>>
>>
>> On Tue, 15 Jun 2010 16:16:46 +0200, Stefan Reinauer
> <stepan at coresystems.de>
>> wrote:
>>> On 6/15/10 4:07 PM, Joseph Smith wrote:
>>>> When
>>>> I cold boot it, if I hit the reset button before Linux starts, it
>>> restarts
>>>> with coreboot serial console just fine.
>>>>
>>>
>>> Hm...
>>>
>>> Maybe 0x2e/0x4e are mapped to LPC after the SuperIO is configured (and
>>> that mapping survives a reset)... that would be a southbridge init
> issue.
>>>
>> Hmm, This is interesting. The first time I booted it, I had copied
> romstage
>> from another board that had:
>>
>> #define SERIAL_DEV PNP_DEV(0x4e, SMSCSUPERIO_SP1)
>>
>> And I got coreboot serial console (early_serial) just fine but when it
> came
>> to detecting and inializing the superio, I got all kinds of errors from
>> coreboot about device not found.
>>
>> So I changed it to 0x2e as described in the datasheet and detected with
>> superiotool(vendor bios), and that is when this problem started. But now
>> coreboot is happy, detects the device and the resource allocator is
> happy,
>> I just do not get early_serial on cold boot.
>>
>> This is weird!
>>
>>> Or, the hardware has to stabilize after power on before you can
>>> configure the SuperIO.
>>>
>> Maybe?
>>
> Hmm from page 142 in the datasheet, I need to figure out of there is a
> pull-down resistor connected to the SYSOPT pin to use 0x2e or if there is a
> pull-up resistor connected to the SYSOPT pin to use 0x4e. And once powered
> up the configuration port base address can be changed through CR26 and
> CR27.
>
> I bet you that there is a pull-up resistor connected to the SYSOPT pin and
> 0x4e is supposed to be used. And the vendor bios changes this to 0x2e at
> some point. That is what is throwing me off!
>
> So I will try:
>
> #define SERIAL_DEV PNP_DEV(0x4e, SMSCSUPERIO_SP1)
>
> and change all the devices in devicetree.cb to 4e.
>
> My question is does it need to get changed to 0x2e at some point? Or can I
> just leave it at 0x4e? Will it matter to OS?
>
> Thanks for all the brainstorming help Stefan and Ron.
>
Yup that did it :-)
Looks like SYSOPT had a pull-up resistor so 0x4e works great.

But there is one other small issue. Looks like the resource allocater is 
not allocating any space for device 43.a the Runtime Registers.

My devicetree.cb looks like:
           device pnp 4e.a on            # Runtime registers
             io 0x60 = 0x800
           end

But my bootlog (attached) shows:
PNP: 004e.a resource base 800 size 0 align 0 gran 0 limit 0 flags 
c0000100 index 60

skipping PNP: 004e.a at 60 fixed resource, size=0!

PNP: 004e.a 60 <- [0x0000000800 - 0x00000007ff] size 0x00000000 gran 0x00 io

     PNP: 004e.a resource base 800 size 0 align 0 gran 0 limit 0 flags 
e0000100 index 60


Is it supposed to look like that?

-- 
Thanks,
Joseph Smith
Set-Top-Linux
www.settoplinux.org
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: i810_boot_test11.txt
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20100615/c5662790/attachment.txt>

From stepan at coresystems.de  Wed Jun 16 00:42:57 2010
From: stepan at coresystems.de (Stefan Reinauer)
Date: Wed, 16 Jun 2010 00:42:57 +0200
Subject: [coreboot] Serial Console only starts after reset
In-Reply-To: <4C1800B9.5000200@settoplinux.org>
References: <d3b3dbd0aff4456f420451fe44f5ddde@imap.1and1.com>	<4C176E64.50501@coresystems.de>	<629e66cb159099658a0e4cef5b844934@imap.1and1.com>	<4C17828D.9050808@coresystems.de>	<1e8eccf4f0337df4a6cf194e132212ca@imap.1and1.com>	<4C178B4E.6040705@coresystems.de>	<7c81186dd4a181b1e0b5e6422f1935e3@imap.1and1.com>
	<476421bf8b52e5ec5471840078560df1@imap.1and1.com>
	<4C1800B9.5000200@settoplinux.org>
Message-ID: <4C1801F1.9050107@coresystems.de>

On 6/16/10 12:37 AM, Joseph Smith wrote:
> But there is one other small issue. Looks like the resource allocater
> is not allocating any space for device 43.a the Runtime Registers.
>
> My devicetree.cb looks like:
>           device pnp 4e.a on            # Runtime registers
>             io 0x60 = 0x800
>           end
>
> But my bootlog (attached) shows:
> PNP: 004e.a resource base 800 size 0 align 0 gran 0 limit 0 flags
> c0000100 index 60
It's probably missing a correct entry in the pnp_dev_info structure of
the superio.

Stefan



From joe at settoplinux.org  Wed Jun 16 00:49:36 2010
From: joe at settoplinux.org (Joseph Smith)
Date: Tue, 15 Jun 2010 18:49:36 -0400
Subject: [coreboot] Serial Console only starts after reset
In-Reply-To: <4C1801F1.9050107@coresystems.de>
References: <d3b3dbd0aff4456f420451fe44f5ddde@imap.1and1.com>	<4C176E64.50501@coresystems.de>	<629e66cb159099658a0e4cef5b844934@imap.1and1.com>	<4C17828D.9050808@coresystems.de>	<1e8eccf4f0337df4a6cf194e132212ca@imap.1and1.com>	<4C178B4E.6040705@coresystems.de>	<7c81186dd4a181b1e0b5e6422f1935e3@imap.1and1.com>
	<476421bf8b52e5ec5471840078560df1@imap.1and1.com>
	<4C1800B9.5000200@settoplinux.org>
	<4C1801F1.9050107@coresystems.de>
Message-ID: <4C180380.2010205@settoplinux.org>

On 06/15/2010 06:42 PM, Stefan Reinauer wrote:
> On 6/16/10 12:37 AM, Joseph Smith wrote:
>> But there is one other small issue. Looks like the resource allocater
>> is not allocating any space for device 43.a the Runtime Registers.
>>
>> My devicetree.cb looks like:
>>            device pnp 4e.a on            # Runtime registers
>>              io 0x60 = 0x800
>>            end
>>
>> But my bootlog (attached) shows:
>> PNP: 004e.a resource base 800 size 0 align 0 gran 0 limit 0 flags
>> c0000100 index 60
> It's probably missing a correct entry in the pnp_dev_info structure of
> the superio.
>
Ah yes, looks like my ip1000 that uses the same code does the same 
thing, I will have to fix that :-)

-- 
Thanks,
Joseph Smith
Set-Top-Linux
www.settoplinux.org



From ebiederm at xmission.com  Wed Jun 16 00:59:19 2010
From: ebiederm at xmission.com (Eric W. Biederman)
Date: Tue, 15 Jun 2010 15:59:19 -0700
Subject: [coreboot] rommcc bugs
In-Reply-To: <AANLkTinpCv9MUfBYOnqme9fPhPSs_p2Ev0XXZL5d-sNh@mail.gmail.com>
	(Myles Watson's message of "Tue\, 15 Jun 2010 16\:36\:08 -0600")
References: <4C17FE51.5070009@assembler.cz>
	<AANLkTinpCv9MUfBYOnqme9fPhPSs_p2Ev0XXZL5d-sNh@mail.gmail.com>
Message-ID: <m17hlzucl4.fsf@fess.ebiederm.org>

Myles Watson <mylesgw at gmail.com> writes:

> On Tue, Jun 15, 2010 at 4:27 PM, Rudolf Marek <r.marek at assembler.cz> wrote:
>> Hi all,
>>
>> While working on netconsole for ROMCC I noticed following:
>>
>> int main(void)
>> {
>> ? ? ? ?/* volatile */
>> ? ? ? ?union {
>> ? ? ? ? ? ? ? ?unsigned char ?byte[2];
>> ? ? ? ? ? ? ? ?unsigned short word;
>> ? ? ? ?} value;
>>
>> ? ? ? ?value.byte[1] = 1;
>> }
>>
>> ./build/util/romcc/romcc -mcpu=p2 a.c
>>
>> a.c:9.18:
>> 0x86bb968 tuple ? ? ?Internal compiler error: tuple used
> This case looks familiar.
>
>>From this message:
> http://www.mail-archive.com/coreboot at coreboot.org/msg22555.html
>
>> Looking at the rest fragment that has been passed around I think the
>> actual bug is that romcc allows non-static non-const arrays to be
>> declared.  I can not find any indication that I ever added support for
>> this when I wrote romcc.

That would be it.

Unions where you write a value in as one type, and read it out as
another type also will not work with romcc.

It does looks like I need a better error check at the declaration of
variables, I missed dealing with an array inside a union ick.

Eric



From c-d.hailfinger.devel.2006 at gmx.net  Wed Jun 16 01:47:30 2010
From: c-d.hailfinger.devel.2006 at gmx.net (Carl-Daniel Hailfinger)
Date: Wed, 16 Jun 2010 01:47:30 +0200
Subject: [coreboot] Winflashrom plans
In-Reply-To: <AANLkTilaa3TIrAedHzQs6DRWZrIba6NKx8UhTAp5otYc@mail.gmail.com>
References: <AANLkTilaa3TIrAedHzQs6DRWZrIba6NKx8UhTAp5otYc@mail.gmail.com>
Message-ID: <4C181112.6000500@gmx.net>

Hi Darmawan,

nice to see you're back.
flashrom has its own mailing list and I added it to CC.

On 15.06.2010 21:56, Darmawan Salihun wrote:
> Sorry, I haven't been able to update Winflashrom for more than 3 years now.
> I'm planning to add Windows 7 support next month.
>   

Nice!


> Therefore, I'm looking for suggestions.
>
> A bit of Winflashrom background of the currently available Winflashrom
> (at flashrom.org):
>
> The programming model:
> a. User mode application:
>     - Mostly "pure" flashrom source code recompiled with MinGW.
>   

Current flashrom can be compiled with MinGW and Cygwin, but it doesn't
support any PCI accesses (USB and serial work).


>     - libpci recompiled with MinGW (for PCI access logic). This is
> required because
>        the PCI access functions in the Windows API is not guaranteed
> (marked as obsolete),
>        in Windows XP SP2 and Windows 2003 server back then.
>   

If the PCI access functions are still available in Windows 7, can we
simply ignore the "deprecated" warnings? CF8/CFC accesses from userspace
are not atomic and might cause mixed up PCI accesses.


> b. Device driver:
>     - Provides POSIX mmap() implementation in the kernel, i.e.
>       provides an entrypoint for mmap() function to user mode application.
>   

Please note that we need two types of memory mapping:
sys_physmap_ro_cached() and sys_physmap_rw_uncached(). For example, the
low memory mapping for coreboot tables uses the readonly cached variant,
and any future DMI string access will also use the readonly cached
variant. Any MMIO areas (including flash access) use the uncached rw
variant. Some operating systems do not care at all about cached/uncached
mapping (they simply use the default caching settings of that memory
region), and for those you can use the uncached rw access for both
access types.


>     - Provides direct I/O port access for libpci.
>
> Well, the reason for these programming model is to reduce the burden
> when moving to newer flash chip support because this programming model
> "preserves" the POSIX API in the user mode application (the device
> driver is generic enough).
> Therefore, "only" the user mode application need to be recompiled to
> support new flash chip.
>
> Any suggestions on what to change from the current programming model?
>   

Current flashrom already supports PCI device flashing and onboard
flashing on DOS, Linux, FreeBSD, NetBSD, DragonFlyBSD, OpenSolaris, Mac
OS X and a few others.
Please take a look at hwaccess.c and hwaccess.h and physmap.c for things
you might want to change for Windows PCI support.

I expect Windows support in flashrom to need ~60 lines of code, maybe
less. The device driver (and libpci support) is a different question,
though.
If you have to modify any file except hwaccess.c, hwaccess.h, physmap.c
or Makefile please tell us.

If you have any questions, feel free to ask at flashrom at flashrom.org or
in #flashrom on irc.freenode.net.

Regards,
Carl-Daniel

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




From c-d.hailfinger.devel.2006 at gmx.net  Wed Jun 16 09:35:38 2010
From: c-d.hailfinger.devel.2006 at gmx.net (Carl-Daniel Hailfinger)
Date: Wed, 16 Jun 2010 09:35:38 +0200
Subject: [coreboot] [PATCH]libpayload: libc-style headers,
	some more functions
In-Reply-To: <4C17D39D.30504@georgi-clan.de>
References: <4C17D39D.30504@georgi-clan.de>
Message-ID: <4C187ECA.7030109@gmx.net>

On 15.06.2010 21:25, Patrick Georgi wrote:
> attached patch moves functions out of the huge libpayload.h into headers
> according to libc/posix traditions, to simplify porting applications to
> payloads.
>   

Very much appreciated. This makes working with libpayload a lot easier.


> It also adds a couple of functions:
> strcasecmp, strncasecmp, strcat, strtol, strspn, strcspn, strtok_r,
> strtok, perror, exit, getpagesize
>   

Could you make perror() a wrapper for strerror()? flashrom will move to
strerror() soon to behave more like a library.


> Signed-off-by: Patrick Georgi <patrick.georgi at coresystems.de>
>   

I didn't review the code in depth, so my comments may be incomplete.
Did you write those functions from scratch, or did you merge proven code
from a BSD licensed codebase?


> +int strtol(const char *ptr, char **endptr, int base)
>   

strtol is long int, not int.


> +char *strcat(char *d, const char *s)
>   

What about more descriptive argument names?
char *strcat(char *dest, const char *src);


> +size_t strspn(const char *s, const char *a)
>   

size_t strspn(const char *s, const char *accept);


> +size_t strcspn(const char *s, const char *a)
>   

size_t strcspn(const char *s, const char *reject);


> +char* strtok_r(char *str, const char *delim, char **ptr)

char *strtok_r(char *str, const char *delim, char **saveptr);


> Index: include/pci.h
> ===================================================================
> --- include/pci.h	(Revision 5631)
> +++ include/pci.h	(Arbeitskopie)
> @@ -36,8 +36,11 @@
>  
>  #define REG_VENDOR_ID   0x00
>  #define REG_COMMAND     0x04
> +#define REG_CLASS_DEV   0x0A
>  #define REG_HEADER_TYPE 0x0E
>  #define REG_PRIMARY_BUS 0x18
> +#define REG_SUBSYS_VENDOR_ID	0x2C
> +#define REG_SUBSYS_ID	0x2E
>  
>  #define REG_COMMAND_BM  (1 << 2)
>  
>   

Here is seems you're using both spaces and tabs between the identifier
and the value. Apart from that, I found that some places use spaces for
indentation instead of tabs.


> Index: libc/lib.c
> ===================================================================
> --- libc/lib.c	(Revision 5631)
> +++ libc/lib.c	(Arbeitskopie)
> @@ -113,3 +113,13 @@
>  	halt();
>  }
>  
> +void exit(int status)
> +{
> +	printf("exited with status %d\n", status);
> +	halt();
> +}
> +
> +int getpagesize(void)
> +{
> +	return 4096;
>   

Maybe wrap that in a check for x86. OTOH, if this function is used to
determine mmap granularity, it should return 1 instead of 4096.


Regards,
Carl-Daniel

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




From juhe at iki.fi  Wed Jun 16 10:02:29 2010
From: juhe at iki.fi (Juhana Helovuo)
Date: Wed, 16 Jun 2010 11:02:29 +0300
Subject: [coreboot] Porting to Asus M4A785-M
In-Reply-To: <1276453504.27968.52.camel@bart>
References: <1276453504.27968.52.camel@bart>
Message-ID: <4C188515.3000409@iki.fi>

Juhana Helovuo kirjoitti:
> Hello,
> 
> I am trying to get coreboot working on Asus M4A785-M with Athlon II X2
> 240e CPU (Socket AM3). So far there is no success.

Hello again,

There is now some progress in this port.

- Found out that the northbridge was wrong. We should use AMD Family 10 
instead of AMD K8.

- Started porting effort again, this time from AMD Tilapia board, since 
it seemed to be a closer match.

- Configured for AM3 CPU socket and DDR2 settings for memory controller 
(not DDR3).

Coreboot now boots past the romstage and starts setting up PCI devices. 
Unfortunately, it crashes at some point during PCI setup. I do not have 
access to the boot log right now, but could post it later.

I suspect that the devicetree.cb source file is somehow wrong and 
therefore coreboot does some wrong initialization or probe, which causes 
an immediate reboot.

Is there a reference manual for writing the devicetree.cb file? All the 
documents I found in the Coreboot wiki seemed to describe some past 
version of it.

Can the correctness of devicetree.cb be somehow verified against lspci 
output? If so, how?

Best regards,
Juhana Helovuo




From patrick at georgi-clan.de  Wed Jun 16 11:36:43 2010
From: patrick at georgi-clan.de (Patrick Georgi)
Date: Wed, 16 Jun 2010 11:36:43 +0200
Subject: [coreboot] [PATCH]libpayload: libc-style headers,
	some more functions
In-Reply-To: <4C187ECA.7030109@gmx.net>
References: <4C17D39D.30504@georgi-clan.de> <4C187ECA.7030109@gmx.net>
Message-ID: <4C189B2B.7000009@georgi-clan.de>

Am 16.06.2010 09:35, schrieb Carl-Daniel Hailfinger:
> Could you make perror() a wrapper for strerror()? flashrom will move to
> strerror() soon to behave more like a library.
We don't have sterror, so I simply let it print the error code (which
isn't set anywhere). This is stubbed until there's actually some real
user of errno.

>> Signed-off-by: Patrick Georgi <patrick.georgi at coresystems.de>
> I didn't review the code in depth, so my comments may be incomplete.
> Did you write those functions from scratch, or did you merge proven code
> from a BSD licensed codebase?
I adapted libpayload functions where possible (strtoul -> strtol, for
example). Everything else is written from scratch.

> strtol is long int, not int.
I'll change that for both strtol and strtoul, thanks.

>> +char *strcat(char *d, const char *s)
> What about more descriptive argument names?
I adopted naming style (ie. single character names) from the other
functions (strncat for strcat, specifically).

This should be done globally, in a separate patch, in my opinion.

>> Index: include/pci.h
> Here is seems you're using both spaces and tabs between the identifier
> and the value. Apart from that, I found that some places use spaces for
> indentation instead of tabs.
Fixed.

>> +int getpagesize(void)
>> +{
>> +	return 4096;
>>   
> 
> Maybe wrap that in a check for x86. OTOH, if this function is used to
> determine mmap granularity, it should return 1 instead of 4096.
I stuck with the meaning of the function (and x86 has 4k pages by default).
Instead of #ifdef-hell, I moved the function to arch/*/virtual.c - both
x86 and powerpc claim 4k pages now.


Patrick



From wangqingpei at gmail.com  Wed Jun 16 12:52:02 2010
From: wangqingpei at gmail.com (Qing Pei Wang)
Date: Wed, 16 Jun 2010 18:52:02 +0800
Subject: [coreboot] jetway PA78VM5 spi flashing
Message-ID: <AANLkTinMZwbLpDzs5UeRtl21SeNageevp7XksSy7uKr8@mail.gmail.com>

hi all,
    Recently i found that the mainboard which i used(Jetway PA78VM-H-LF) is
not stable, most of the spi flashing caused data error.
the data writing is ok, but the bios data does not as the same  as the
original. the SPI FLASH is Winbond W25X80A
In the other hand, the board can not boot correctly, i am wondering if it's
because of the CPU. Olsen, have you ever met this problem?

-- 
Wang Qing Pei
MSN:wangqingpei at hotmail.com <MSN%3Awangqingpei at hotmail.com>
Gmail:wangqingpei at gmail.com <Gmail%3Awangqingpei at gmail.com>
Phone:86+13426369984
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20100616/19efb051/attachment.html>

From joe at settoplinux.org  Wed Jun 16 13:27:16 2010
From: joe at settoplinux.org (Joseph Smith)
Date: Wed, 16 Jun 2010 07:27:16 -0400
Subject: [coreboot] SuperIO PNP resource allocation help
Message-ID: <b30a6ba927439f296d7f299b46a8d187@imap.1and1.com>


Hello,
Need some help understanding how the SuperIO PNP resource allocation works.
Particularly src/superio/smsc/smscsuperio pnp_dev_info. I need to reserve
128 bytes for device { &ops, LD_PME, } but I am not really sure how the
magic behind this works. Anyone that could shed a light I would be much
appreciated.

-- 
Thanks,
Joseph Smith
Set-Top-Linux
www.settoplinux.org




From mylesgw at gmail.com  Wed Jun 16 16:30:23 2010
From: mylesgw at gmail.com (Myles Watson)
Date: Wed, 16 Jun 2010 08:30:23 -0600
Subject: [coreboot] Porting to Asus M4A785-M
In-Reply-To: <4C188515.3000409@iki.fi>
References: <1276453504.27968.52.camel@bart> <4C188515.3000409@iki.fi>
Message-ID: <C99ACA6966B34C90B11874735E1F302F@chimp>

> Coreboot now boots past the romstage and starts setting up PCI devices.
> Unfortunately, it crashes at some point during PCI setup. I do not have
> access to the boot log right now, but could post it later.
That would be helpful.
 
> I suspect that the devicetree.cb source file is somehow wrong and
> therefore coreboot does some wrong initialization or probe, which causes
> an immediate reboot.
Usually an incorrect device tree wouldn't cause a reboot.  Do the devices
selected in your Kconfig file match the devices in your device tree?
 
> Is there a reference manual for writing the devicetree.cb file? All the
> documents I found in the Coreboot wiki seemed to describe some past
> version of it.
The best thing to do is copy a device tree from a similar board.  The hard
thing about AMD device trees is that the chips in a HyperTransport chain
need to be listed in reverse order.  You'll get a lot more malloc debugging
statements if your device tree is incorrect, since it will find the devices
(just not where it expects to), and the devices from the tree will be
disabled.

> Can the correctness of devicetree.cb be somehow verified against lspci
> output? If so, how?
The best way is looking through the log to see which devices are allocated
with malloc, and which get disabled.

Thanks,
Myles




From alexander.hug at physik.tu-darmstadt.de  Wed Jun 16 19:48:55 2010
From: alexander.hug at physik.tu-darmstadt.de (Alexander Hug)
Date: Wed, 16 Jun 2010 19:48:55 +0200
Subject: [coreboot] Will my board be supported?
Message-ID: <4C190E87.60504@physik.tu-darmstadt.de>

Hello!

I am interested in Coreboot and want to try it on my "old" desktop.
It is an "ASUS A7V880", but i cannot find it in the list of boards.

So here is my hardware, i hope everything is included:

ASUS A7V880 with AthlonXP 2600+, 2GB Ram, HD connected to the SATA 
controller.

The Manual says (highlights):
Chipset VIA KT880, VIA VT8237
FSB 400,333,266,200
1x AGPx8, 5xPCI
2x UDMA(IDE) 133
2x SATA
ASUS EZ Flash
ASUS CrashFree BIOS 2
ASUS Q-Fan

4Mb Flash EEPROM, Award BIOS, PnP, DMI2.0, WfM2.0, SM Bios 2.3, ACPI

$ lspci -tvnn

-[0000:00]-+-00.0  VIA Technologies, Inc. KT880 Host Bridge [1106:0269]
           +-00.1  VIA Technologies, Inc. KT880 Host Bridge [1106:1269]
           +-00.2  VIA Technologies, Inc. KT880 Host Bridge [1106:2269]
           +-00.3  VIA Technologies, Inc. KT880 Host Bridge [1106:3269]
           +-00.4  VIA Technologies, Inc. KT880 Host Bridge [1106:4269]
           +-00.7  VIA Technologies, Inc. KT880 Host Bridge [1106:7269]
           +-01.0-[0000:01]----00.0  nVidia Corporation NV34 [GeForce FX 
5200] [10de:0322]
           +-0a.0  Intel Corporation 82557/8/9/0/1 Ethernet Pro 100 
[8086:1229]
           +-0e.0  VIA Technologies Inc. VT1720/24 [Envy24PT/HT] PCI 
Multi-Channel Audio Controller [1412:1724]
           +-0f.0  VIA Technologies, Inc. VIA VT6420 SATA RAID 
Controller [1106:3149]
           +-0f.1  VIA Technologies, Inc. 
VT82C586A/B/VT82C686/A/B/VT823x/A/C PIPC Bus Master IDE [1106:0571]
           +-10.0  VIA Technologies, Inc. VT82xxxxx UHCI USB 1.1 
Controller [1106:3038]
           +-10.1  VIA Technologies, Inc. VT82xxxxx UHCI USB 1.1 
Controller [1106:3038]
           +-10.2  VIA Technologies, Inc. VT82xxxxx UHCI USB 1.1 
Controller [1106:3038]
           +-10.3  VIA Technologies, Inc. VT82xxxxx UHCI USB 1.1 
Controller [1106:3038]
           +-10.4  VIA Technologies, Inc. USB 2.0 [1106:3104]
           +-11.0  VIA Technologies, Inc. VT8237 ISA bridge 
[KT600/K8T800/K8T890 South] [1106:3227]
           +-11.5  VIA Technologies, Inc. VT8233/A/8235/8237 AC97 Audio 
Controller [1106:3059]
           \-11.6  VIA Technologies, Inc. AC'97 Modem Controller [1106:3068]

$superiotool -d (I skipped V because it reports only "failed")

superiotool r3125
Found ITE IT8712F (id=0x8712, rev=0x5) at 0x2e
Register dump:
idx 07 20 21 22 23 24 2b
val 0a 87 12 05 01 00 00
def NA 87 12 08 00 00 00
LDN 0x00 (Floppy)
idx 30 60 61 70 74 f0 f1
val 01 03 f0 06 02 00 00
def 00 03 f0 06 02 00 00
LDN 0x01 (COM1)
idx 30 60 61 70 f0 f1 f2 f3
val 00 00 00 00 00 50 00 7f
def 00 03 f8 04 00 50 00 7f
LDN 0x02 (COM2)
idx 30 60 61 70 f0 f1 f2 f3
val 00 02 f8 03 00 50 00 7f
def 00 02 f8 03 00 50 00 7f
LDN 0x03 (Parallel port)
idx 30 60 61 62 63 70 74 f0
val 00 00 00 00 00 00 04 00
def 00 03 78 07 78 07 03 03
LDN 0x04 (Environment controller)
idx 30 60 61 62 63 70 f0 f1  f2 f3 f4 f5 f6
val 01 0c 00 0b 00 00 00 00  06 00 80 00 ff
def 00 02 90 02 30 09 00 00  00 00 00 NA NA
LDN 0x05 (Keyboard)
idx 30 60 61 62 63 70 71 f0
val 01 00 60 00 64 01 02 00
def 01 00 60 00 64 01 02 08
LDN 0x06 (Mouse)
idx 30 70 71 f0
val 01 0c 02 00
def 00 0c 02 00
LDN 0x07 (GPIO)
idx 25 26 27 28 29 2a 2c 60  61 62 63 64 65 70 71 72  73 74 b0 b1 b2 b3 
b4 b5  b8 b9 ba bb bc bd c0 c1  c2 c3 c4 c8 c9 ca cb cc  e0 e1 e2 e3 e4 
f0 f1 f2  f3 f4 f5 f6 f7 f8 f9 fa  fb fc fd
val 00 00 36 80 00 00 00 00  00 04 80 00 00 00 00 00  00 04 00 00 00 80 
00 00  00 00 00 00 00 00 00 00  00 00 00 00 00 34 80 00  00 00 00 00 00 
00 00 00  00 00 00 00 00 00 00 00  00 16 00
def 01 00 00 40 00 00 00 00  00 00 00 00 00 00 00 00  c0 00 00 00 00 00 
00 00  00 00 00 00 00 00 01 00  00 40 00 01 00 00 40 00  00 00 00 00 00 
00 00 00  00 00 00 00 00 00 00 00  00 NA 00
LDN 0x08 (MIDI port)
idx 30 60 61 70 f0
val 00 00 00 00 00
def 00 03 00 0a 00
LDN 0x09 (Game port)
idx 30 60 61
val 00 00 00
def 00 02 01
LDN 0x0a (Consumer IR)
idx 30 60 61 70 f0
val 00 03 10 0b 06
def 00 03 10 0b 00

$ flashrom -v

Calibrating delay loop... OK.
No coreboot table found.
Found chipset "VIA VT8237", enabling flash write... OK.
Found chip "PMC Pm49FL004" (512 KB) at physical address 0xfff80000.

URL to ASUS
http://support.asus.com/download/download.aspx?SLanguage=de-de&model=A7V880&product=1




From mylesgw at gmail.com  Wed Jun 16 20:00:28 2010
From: mylesgw at gmail.com (Myles Watson)
Date: Wed, 16 Jun 2010 12:00:28 -0600
Subject: [coreboot] Strange ROMCC failure with Rev 5623
Message-ID: <AANLkTikgYCZFdyizSDn-4GB14HSO5RhAMsuFHZI_bvls@mail.gmail.com>

When compiling asus/p2b (and several others), Rev 5622 succeeds, but 5623 fails.

make: *** [build/mainboard/asus/p2b/romstage.inc] Segmentation fault
make: *** Deleting file `build/mainboard/asus/p2b/romstage.inc'

The only difference for these boards is this line in config.h:

#define CONFIG_VENDOR_ECS 0

Removing this line lets 5623 build correctly.

Is there some limit on the length of this file?  The number of
#defines?  I'm using the reference compiler to compile romcc.

Thanks,
Myles



From mylesgw at gmail.com  Wed Jun 16 20:06:53 2010
From: mylesgw at gmail.com (Myles Watson)
Date: Wed, 16 Jun 2010 12:06:53 -0600
Subject: [coreboot] Strange ROMCC failure with Rev 5623
In-Reply-To: <AANLkTikgYCZFdyizSDn-4GB14HSO5RhAMsuFHZI_bvls@mail.gmail.com>
References: <AANLkTikgYCZFdyizSDn-4GB14HSO5RhAMsuFHZI_bvls@mail.gmail.com>
Message-ID: <AANLkTinHo_Jak42t3kroe7ePuL77KfogqrhQpxIfAaBO@mail.gmail.com>

On Wed, Jun 16, 2010 at 12:00 PM, Myles Watson <mylesgw at gmail.com> wrote:
> When compiling asus/p2b (and several others), Rev 5622 succeeds, but 5623 fails.
>
> make: *** [build/mainboard/asus/p2b/romstage.inc] Segmentation fault
> make: *** Deleting file `build/mainboard/asus/p2b/romstage.inc'
>
> The only difference for these boards is this line in config.h:
>
> #define CONFIG_VENDOR_ECS 0
>
> Removing this line lets 5623 build correctly.
Removing any line from the file that doesn't affect the build works.
(CONFIG_VENDOR_*, CONFIG_DEFAULT_CONSOLE_LEVEL_*, etc.)

Thanks,
Myles



From juhe at iki.fi  Wed Jun 16 21:55:31 2010
From: juhe at iki.fi (Juhana Helovuo)
Date: Wed, 16 Jun 2010 22:55:31 +0300
Subject: [coreboot] Porting to Asus M4A785-M
In-Reply-To: <C99ACA6966B34C90B11874735E1F302F@chimp>
References: <1276453504.27968.52.camel@bart> <4C188515.3000409@iki.fi>
	<C99ACA6966B34C90B11874735E1F302F@chimp>
Message-ID: <1276718131.3866.4.camel@bart>

On Wed, 2010-06-16 at 08:30 -0600, Myles Watson wrote:
> > Coreboot now boots past the romstage and starts setting up PCI devices.
> > Unfortunately, it crashes at some point during PCI setup. I do not have
> > access to the boot log right now, but could post it later.
> That would be helpful.
>  

Ok, here I have a boot log attached, in case anyone is interested.

At the end of the log the machine resets and the same starts over from
the beginning.

I do not know what the PCI device setup should look like, but towards
the end of the log it seems to iterate over the same devices many times.

Best regards,
Juhana Helovuo
-------------- next part --------------
A non-text attachment was scrubbed...
Name: coreboot-asus-m4a785-m.log
Type: text/x-log
Size: 26426 bytes
Desc: not available
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20100616/e5c9267d/attachment.log>

From john.wyzer at gmx.de  Wed Jun 16 22:00:34 2010
From: john.wyzer at gmx.de (John Wyzer)
Date: Wed, 16 Jun 2010 22:00:34 +0200
Subject: [coreboot] request for comments: Gigabyte GA-945PL-S3 (rev. 1.0)
Message-ID: <4C192D62.7030706@gmx.de>

I'm really interested in using coreboot and tried to follow http://www.coreboot.org/FAQ to 
find out about the chances for my motherboard.

Note: I disabled line wrapping for better readability of command line tools output. 
No annoying intended.

*  Step 1: A very brief description of your system: board vendor, board name, CPU, northbridge, southbridge, and optionally other important details.

Board: Gigabyte GA-945PL-S3 (rev. 1.0)
CPU: Intel Core Duo
# Northbridge: Intel? 945PL Express Chipset
# Southbridge: Intel? ICH7
# Realtek 8111B Gigabit Ethernet controller 
further Bios details:
BIOS	

   1. 4 Mbit flash ROM
   2. Use of licensed AWARD BIOS
   3. Supports Virtual Dual BIOS
   4. PnP 1.0a, DMI 2.0, SM BIOS 2.3, ACPI 1.0b. 

Other Features	

   1. Supports @BIOS
   2. Supports Download Center
   3. Supports Q-Flash
   4. Supports EasyTune 5
   5. Supports Xpress Install
   6. Supports Xpress Recovery2
   7. Supports Virtual DualBIOS 
 

* Step 2: Linux "lspci -tvnn" output for your system, generated by booting Linux via the original BIOS and runnning lspci.
-[0000:00]-+-00.0  Intel Corporation 82945G/GZ/P/PL Memory Controller Hub [8086:2770]
           +-1b.0  Intel Corporation 82801G (ICH7 Family) High Definition Audio Controller [8086:27d8]
           +-1c.0-[01]--+-00.0  JMicron Technology Corp. JMB362/JMB363 Serial ATA Controller [197b:2363]
           |            \-00.1  JMicron Technology Corp. JMB362/JMB363 Serial ATA Controller [197b:2363]
           +-1c.3-[02]----00.0  Realtek Semiconductor Co., Ltd. RTL8111/8168B PCI Express Gigabit Ethernet controller [10ec:8168]
           +-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-[03]--+-00.0  VIA Technologies, Inc. VT82xxxxx UHCI USB 1.1 Controller [1106:3038]
           |            +-00.1  VIA Technologies, Inc. VT82xxxxx UHCI USB 1.1 Controller [1106:3038]
           |            +-00.2  VIA Technologies, Inc. USB 2.0 [1106:3104]
           |            +-00.3  VIA Technologies, Inc. VT6306/7/8 [Fire II(M)] IEEE 1394 OHCI Controller [1106:3044]
           |            \-02.0  ATI Technologies Inc 3D Rage Pro 215GP [1002:4750]
           +-1f.0  Intel Corporation 82801GB/GR (ICH7 Family) LPC Interface Bridge [8086:27b8]
           +-1f.1  Intel Corporation 82801G (ICH7 Family) IDE Controller [8086:27df]
           +-1f.2  Intel Corporation 82801GB/GR/GH (ICH7 Family) SATA IDE Controller [8086:27c0]
           \-1f.3  Intel Corporation 82801G (ICH7 Family) SMBus Controller [8086:27da]


* Step 3: Super I/O chip on the mainboard (report the model numbers on the actual chip, for example "Winbond W83627HF" and/or run "superiotool -dV").
superiotool said: Found ITE IT8718F (id=0x8718, rev=0x1) at 0x2e

* Step 4: Type of BIOS device (see the question "How do I identify the BIOS chip on my mainboard?" below). Please send us the output of "flashrom -V"

flashrom -V said in between:
[...]
Found ITE Super I/O, id 8718
Found chipset "Intel ICH7/ICH7R", enabling flash write...
[...]
Found chip "SST SST25VF040.REMS" (512 KB, SPI) at physical address 0xfff80000.
[...]


* Step 5: URL to the mainboard specifications page (optional).
All non-generated information comes from from http://www.gigabyte.us/Support/Motherboard/BIOS_Model.aspx?ProductID=2325 
 
* Step 6: Any other relevant information you can provide. 
I'm extremely comfortable with C and linux in general and willing to invest time into making this work if possible.
Please let me know if there's a chance to get coreboot running and/or if there is anything I can do to help.
Please CC me - I'm subscribed but disabled reception until it makes sense to get further involved.

Best regards!
John




From mylesgw at gmail.com  Wed Jun 16 22:04:24 2010
From: mylesgw at gmail.com (Myles Watson)
Date: Wed, 16 Jun 2010 14:04:24 -0600
Subject: [coreboot] Porting to Asus M4A785-M
In-Reply-To: <1276718131.3866.4.camel@bart>
References: <1276453504.27968.52.camel@bart> <4C188515.3000409@iki.fi>
	<C99ACA6966B34C90B11874735E1F302F@chimp>
	<1276718131.3866.4.camel@bart>
Message-ID: <AANLkTim-7sixU0sg94kvYGbLq0WRJzaxsEiN4mdgL-9G@mail.gmail.com>

On Wed, Jun 16, 2010 at 1:55 PM, Juhana Helovuo <juhe at iki.fi> wrote:
> On Wed, 2010-06-16 at 08:30 -0600, Myles Watson wrote:
>> > Coreboot now boots past the romstage and starts setting up PCI devices.
>> > Unfortunately, it crashes at some point during PCI setup. I do not have
>> > access to the boot log right now, but could post it later.
>> That would be helpful.
>>
>
> Ok, here I have a boot log attached, in case anyone is interested.
>
> At the end of the log the machine resets and the same starts over from
> the beginning.
>
> I do not know what the PCI device setup should look like, but towards
> the end of the log it seems to iterate over the same devices many times.

Yes.  I'm not sure why that's happening.  Could you send your devicetree.cb?

Thanks,
Myles



From r.marek at assembler.cz  Wed Jun 16 22:35:59 2010
From: r.marek at assembler.cz (Rudolf Marek)
Date: Wed, 16 Jun 2010 22:35:59 +0200
Subject: [coreboot] Porting to Asus M4A785-M
In-Reply-To: <AANLkTim-7sixU0sg94kvYGbLq0WRJzaxsEiN4mdgL-9G@mail.gmail.com>
References: <1276453504.27968.52.camel@bart>
	<4C188515.3000409@iki.fi>	<C99ACA6966B34C90B11874735E1F302F@chimp>	<1276718131.3866.4.camel@bart>
	<AANLkTim-7sixU0sg94kvYGbLq0WRJzaxsEiN4mdgL-9G@mail.gmail.com>
Message-ID: <4C1935AF.2060205@assembler.cz>

I think the IT8712 has a watchdog enabled. You need to disable it.

Call it8712f_kill_watchdog()

Thanks,
Rudolf



From r.marek at assembler.cz  Wed Jun 16 22:41:49 2010
From: r.marek at assembler.cz (Rudolf Marek)
Date: Wed, 16 Jun 2010 22:41:49 +0200
Subject: [coreboot] rommcc bugs
In-Reply-To: <m17hlzucl4.fsf@fess.ebiederm.org>
References: <4C17FE51.5070009@assembler.cz>	<AANLkTinpCv9MUfBYOnqme9fPhPSs_p2Ev0XXZL5d-sNh@mail.gmail.com>
	<m17hlzucl4.fsf@fess.ebiederm.org>
Message-ID: <4C19370D.9020000@assembler.cz>

Hi all,

Second problem is very strange:

marekr2 at kiur:~/dilna/coreboot$ make
     GEN        build.h
     ROMCC      romstage.inc
ne2k.c:83.0: warning:  "comment next line causes stuff to compile again"
ne2k.c:126.0: warning:  "Add timeout"
romstage.c:74.0:
Internal compiler error: constant for unknown type
make: *** [build/mainboard/soyo/sy-6ba-plus-iii/romstage.inc] Aborted

The board is Soyo, you need to apply the attached patch.

If you comment out in ne2k.c line 84 it will compile again :/

I tried to isolate the problem but i was able to compile the ne2k.c just fine. I 
suspect romcc runs out of some resources.

Please let me know if you are able to reproduce the problem,

Thanks,
Rudolf
-------------- next part --------------
A non-text attachment was scrubbed...
Name: a.patch
Type: text/x-diff
Size: 25281 bytes
Desc: not available
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20100616/a9baca02/attachment.bin>

From mylesgw at gmail.com  Wed Jun 16 22:50:42 2010
From: mylesgw at gmail.com (Myles Watson)
Date: Wed, 16 Jun 2010 14:50:42 -0600
Subject: [coreboot] [PATCH] Simplify device enabling and initialization
Message-ID: <AANLkTingtsR4xtaPMENTl3bk5tOWM1hMqR2t9w8Ep3vR@mail.gmail.com>

If we initialize and enable devices in the order that they are found
in the tree, instead of the order that they were added to the list, it
simplifies the code.  It also makes it so that removing a device from
the devicetree.cb file won't change when its resources are enabled.

I had the devices initialize depth first, but changed it to breadth
first.  I think it makes more sense to have all the children of a
device initialized together.  I could be talked out of that.

This patch breaks the s2881, which was doing some odd acrobatics in
order to get a device initialized after its parent.  It should be an
easy fix to do it correctly now, but I don't have an s2881 to test on.
 Ward?

Changes:
1. Remove global enable_resources(child) and calls to it from bridges
2. Make root_dev_* functions local to the root_device
3. Make ".init=init_func," consistent.  Some were using ".init=&init_func,"
4. Remove comments about indirect mutual recursion since it isn't anymore

Signed-off-by: Myles Watson <mylesgw at gmail.com>

Thanks,
Myles
-------------- next part --------------
A non-text attachment was scrubbed...
Name: trees.diff
Type: text/x-patch
Size: 47452 bytes
Desc: not available
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20100616/d9e66c0a/attachment.diff>

From mylesgw at gmail.com  Wed Jun 16 23:16:11 2010
From: mylesgw at gmail.com (Myles Watson)
Date: Wed, 16 Jun 2010 15:16:11 -0600
Subject: [coreboot] rommcc bugs
In-Reply-To: <4C19370D.9020000@assembler.cz>
References: <4C17FE51.5070009@assembler.cz>
	<AANLkTinpCv9MUfBYOnqme9fPhPSs_p2Ev0XXZL5d-sNh@mail.gmail.com>
	<m17hlzucl4.fsf@fess.ebiederm.org> <4C19370D.9020000@assembler.cz>
Message-ID: <AANLkTin7EiCHXpet2kYDgGLwRsMrzkXM7zKfA3zDnBOs@mail.gmail.com>

On Wed, Jun 16, 2010 at 2:41 PM, Rudolf Marek <r.marek at assembler.cz> wrote:
> Hi all,
>
> Second problem is very strange:
>
> marekr2 at kiur:~/dilna/coreboot$ make
> ? ?GEN ? ? ? ?build.h
> ? ?ROMCC ? ? ?romstage.inc
> ne2k.c:83.0: warning: ?"comment next line causes stuff to compile again"
> ne2k.c:126.0: warning: ?"Add timeout"
> romstage.c:74.0:
> Internal compiler error: constant for unknown type
> make: *** [build/mainboard/soyo/sy-6ba-plus-iii/romstage.inc] Aborted
>
> The board is Soyo, you need to apply the attached patch.
>
> If you comment out in ne2k.c line 84 it will compile again :/

This is what I get:
Internal compiler error: constant for unknown type

If I comment out lines 83 & 84 I get:

src/lib/ne2k.c:71: warning: no previous prototype for 'eth_pio_write_byte'
src/lib/ne2k.c:125:2: warning: #warning "Add timeout"
src/lib/ne2k.c:89: warning: 'eth_pio_read_byte' defined but not used
    CC         lib/compute_ip_checksum.initobj.o
    CC         console/vtxprintf.initobj.o
    CC         arch/i386/lib/printk_init.initobj.o
    CC         arch/i386/lib/cbfs_and_run.initobj.o
    LINK       coreboot
    OBJCOPY    coreboot.bootblock
    CC         arch/i386/lib/c_start.o
    CC         lib/ne2k.driver.o
src/lib/ne2k.c:71: warning: no previous prototype for 'eth_pio_write_byte'
src/lib/ne2k.c:125:2: warning: #warning "Add timeout"
src/lib/ne2k.c:89: warning: 'eth_pio_read_byte' defined but not used
    CC         console/uart8250_console.driver.o
make: *** No rule to make target
`build/console/ne2k_console.driver.o', needed by
`build/coreboot_ram.o'.  Stop.

Thanks,
Myles



From joe at settoplinux.org  Wed Jun 16 23:18:08 2010
From: joe at settoplinux.org (Joseph Smith)
Date: Wed, 16 Jun 2010 17:18:08 -0400
Subject: [coreboot] [PATCH] i810E and ICH2 inteltool support
Message-ID: <4C193F90.9080806@settoplinux.org>

This patch adds inteltool support for i810E and ICH2.

Signed-off-by: Joseph Smith <joe at settoplinux.org>

-- 
Thanks,
Joseph Smith
Set-Top-Linux
www.settoplinux.org
-------------- next part --------------
A non-text attachment was scrubbed...
Name: inteltool_i810e_ich2.patch
Type: text/x-patch
Size: 6688 bytes
Desc: not available
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20100616/c41947cb/attachment.patch>

From r.marek at assembler.cz  Wed Jun 16 23:28:03 2010
From: r.marek at assembler.cz (Rudolf Marek)
Date: Wed, 16 Jun 2010 23:28:03 +0200
Subject: [coreboot] rommcc bugs
In-Reply-To: <AANLkTin7EiCHXpet2kYDgGLwRsMrzkXM7zKfA3zDnBOs@mail.gmail.com>
References: <4C17FE51.5070009@assembler.cz>	<AANLkTinpCv9MUfBYOnqme9fPhPSs_p2Ev0XXZL5d-sNh@mail.gmail.com>	<m17hlzucl4.fsf@fess.ebiederm.org>
	<4C19370D.9020000@assembler.cz>
	<AANLkTin7EiCHXpet2kYDgGLwRsMrzkXM7zKfA3zDnBOs@mail.gmail.com>
Message-ID: <4C1941E3.8000605@assembler.cz>

Ah sorry I forgot one more file. Now it should be better.

But yes I got same error.

Thanks,
Rudolf
-------------- next part --------------
A non-text attachment was scrubbed...
Name: a.patch
Type: text/x-diff
Size: 26723 bytes
Desc: not available
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20100616/6d697d6d/attachment.bin>

From mylesgw at gmail.com  Wed Jun 16 23:55:40 2010
From: mylesgw at gmail.com (Myles Watson)
Date: Wed, 16 Jun 2010 15:55:40 -0600
Subject: [coreboot] rommcc bugs
In-Reply-To: <4C1941E3.8000605@assembler.cz>
References: <4C17FE51.5070009@assembler.cz>
	<AANLkTinpCv9MUfBYOnqme9fPhPSs_p2Ev0XXZL5d-sNh@mail.gmail.com>
	<m17hlzucl4.fsf@fess.ebiederm.org> <4C19370D.9020000@assembler.cz>
	<AANLkTin7EiCHXpet2kYDgGLwRsMrzkXM7zKfA3zDnBOs@mail.gmail.com>
	<4C1941E3.8000605@assembler.cz>
Message-ID: <AANLkTil7AYcHe7Rc6rIzScnOZ7ETxa5IvXMf7wUaBvo1@mail.gmail.com>

Sorry Rudolf, I forgot to copy the list.

It looks like romcc doesn't support unsigned char there.  I did this:

- outb(datxa, eth_nic_base + NE_ASIC_OFFSET + NE_DATA);
+ outb((char)datxa, eth_nic_base + NE_ASIC_OFFSET + NE_DATA);

And it compiles again.

Here's the code from romcc.c:

static struct triple *int_const(
	struct compile_state *state, struct type *type, ulong_t value)
{
	struct triple *result;
	switch(type->type & TYPE_MASK) {
	case TYPE_CHAR:
	case TYPE_INT:   case TYPE_UINT:
	case TYPE_LONG:  case TYPE_ULONG:
		break;
	default:
		internal_error(state, 0, "constant for unknown type");
	}
	result = triple(state, OP_INTCONST, type, 0, 0);
	result->u.cval = value;
	return result;
}

Thanks,
Myles



From r.marek at assembler.cz  Thu Jun 17 00:03:05 2010
From: r.marek at assembler.cz (Rudolf Marek)
Date: Thu, 17 Jun 2010 00:03:05 +0200
Subject: [coreboot] rommcc bugs
In-Reply-To: <AANLkTil7AYcHe7Rc6rIzScnOZ7ETxa5IvXMf7wUaBvo1@mail.gmail.com>
References: <4C17FE51.5070009@assembler.cz>	<AANLkTinpCv9MUfBYOnqme9fPhPSs_p2Ev0XXZL5d-sNh@mail.gmail.com>	<m17hlzucl4.fsf@fess.ebiederm.org>	<4C19370D.9020000@assembler.cz>	<AANLkTin7EiCHXpet2kYDgGLwRsMrzkXM7zKfA3zDnBOs@mail.gmail.com>	<4C1941E3.8000605@assembler.cz>
	<AANLkTil7AYcHe7Rc6rIzScnOZ7ETxa5IvXMf7wUaBvo1@mail.gmail.com>
Message-ID: <4C194A19.2000509@assembler.cz>

Hm,

It does not work here. If i change it I still got

marekr2 at kiur:~/dilna/coreboot$ make
     GEN        build.h
     ROMCC      romstage.inc
ne2k.c:83.0: warning:  "comment next line causes stuff to compile again"
ne2k.c:126.0: warning:  "Add timeout"
romstage.c:74.0:
Internal compiler error: constant for unknown type
make: *** [build/mainboard/soyo/sy-6ba-plus-iii/romstage.inc] Aborted

outb((char)datxa, eth_nic_base + NE_ASIC_OFFSET + NE_DATA);


this is how it looks now. Maybe you changed more?

Thanks,

Rudolf



From stepan at coresystems.de  Thu Jun 17 00:13:32 2010
From: stepan at coresystems.de (Stefan Reinauer)
Date: Thu, 17 Jun 2010 00:13:32 +0200
Subject: [coreboot] [PATCH] Simplify device enabling and initialization
In-Reply-To: <AANLkTingtsR4xtaPMENTl3bk5tOWM1hMqR2t9w8Ep3vR@mail.gmail.com>
References: <AANLkTingtsR4xtaPMENTl3bk5tOWM1hMqR2t9w8Ep3vR@mail.gmail.com>
Message-ID: <4C194C8C.50504@coresystems.de>

Hi Myles,

I like the patch, but it looks like you're wiping calls to adt7463
initialization on the s2881 completely with no replacement. is that on
purpose?

Stefan

On 6/16/10 10:50 PM, Myles Watson wrote:
> Index: svn/src/mainboard/tyan/s2881/mainboard.c
> ===================================================================
> --- svn.orig/src/mainboard/tyan/s2881/mainboard.c
> +++ svn/src/mainboard/tyan/s2881/mainboard.c
> @@ -98,56 +98,6 @@ static void adt7463_init(device_t dev)
>  	printk(BIOS_DEBUG, "ADT7463 properly initialized\n");
>  }
>  
> -static void dummy_noop(device_t dummy)
> -{
> -}
> -
> -static struct device_operations dummy_operations = {
> -	.read_resources		= dummy_noop,
> -	.set_resources		= dummy_noop,
> -	.enable_resources	= dummy_noop,
> -	.init			= adt7463_init,
> -};
> -
> -static unsigned int scan_root_bus(device_t root, unsigned int max)
> -{
> -	struct device_path path;
> -	device_t dummy;
> -
> -	max = root_dev_scan_bus(root, max);
> -
> -	printk(BIOS_DEBUG, "scan_root_bus ok\n");
> -
> -	/* The following is a little silly. We need a hook into the boot
> -	 * process *after* the ADT7463 device has been initialized. So we
> -	 * create this dummy device, and we put the ADT7463 S2881 specific
> -	 * settings in its init function, which gets called
> -	 * as the last device to be initialized.
> -	 */
> -
> -	path.type = DEVICE_PATH_PNP;
> -	path.pnp.port = 0;
> -	path.pnp.device = 0;
> -	dummy = alloc_dev(root->link_list, &path);
> -	dummy->ops = &dummy_operations;
> -
> -	return max;
> -}
> -
> -static struct device_operations mainboard_operations = {
> -	.read_resources		= root_dev_read_resources,
> -	.set_resources		= root_dev_set_resources,
> -	.enable_resources	= root_dev_enable_resources,
> -	.init			= root_dev_init,
> -	.scan_bus		= scan_root_bus,
> -};
> -
> -static void enable_dev(struct device *dev)
> -{
> -	dev->ops = &mainboard_operations;
> -}
> -
>  struct chip_operations mainboard_ops = {
>  	CHIP_NAME("Tyan S2881 Mainboard")
> -	.enable_dev = enable_dev,
>  };
>   
>   

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

From mylesgw at gmail.com  Thu Jun 17 00:14:11 2010
From: mylesgw at gmail.com (Myles Watson)
Date: Wed, 16 Jun 2010 16:14:11 -0600
Subject: [coreboot] rommcc bugs
In-Reply-To: <4C194A19.2000509@assembler.cz>
References: <4C17FE51.5070009@assembler.cz>
	<AANLkTinpCv9MUfBYOnqme9fPhPSs_p2Ev0XXZL5d-sNh@mail.gmail.com>
	<m17hlzucl4.fsf@fess.ebiederm.org> <4C19370D.9020000@assembler.cz>
	<AANLkTin7EiCHXpet2kYDgGLwRsMrzkXM7zKfA3zDnBOs@mail.gmail.com>
	<4C1941E3.8000605@assembler.cz>
	<AANLkTil7AYcHe7Rc6rIzScnOZ7ETxa5IvXMf7wUaBvo1@mail.gmail.com>
	<4C194A19.2000509@assembler.cz>
Message-ID: <AANLkTinLpq6iDbZQeqgMoXL0YmFHfS9ZT16ECQ-hrZEA@mail.gmail.com>

On Wed, Jun 16, 2010 at 4:03 PM, Rudolf Marek <r.marek at assembler.cz> wrote:
> Hm,
>
> It does not work here. If i change it I still got

You're right.  I added TYPE_UCHAR:

before:
       case TYPE_CHAR:
       case TYPE_INT:   case TYPE_UINT:

after:
       case TYPE_CHAR: case TYPE_UCHAR:
       case TYPE_INT:   case TYPE_UINT:

I don't know how safe that is, but it seems like it should work.  I
don't know the difference between constants that are unsigned or
signed characters.  In the past it's been better to work around romcc
than modify it unless Eric helps.

Sorry for the confusion.  I thought I changed it back before I tried it last.

Thanks,
Myles



From stepan at coresystems.de  Thu Jun 17 00:18:19 2010
From: stepan at coresystems.de (Stefan Reinauer)
Date: Thu, 17 Jun 2010 00:18:19 +0200
Subject: [coreboot] [PATCH] i810E and ICH2 inteltool support
In-Reply-To: <4C193F90.9080806@settoplinux.org>
References: <4C193F90.9080806@settoplinux.org>
Message-ID: <4C194DAB.6060308@coresystems.de>

Great, thank you.

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




From svn at coreboot.org  Thu Jun 17 00:21:20 2010
From: svn at coreboot.org (repository service)
Date: Thu, 17 Jun 2010 00:21:20 +0200
Subject: [coreboot] [commit] r5632 - trunk/util/inteltool
Message-ID: <E1OP0z2-0007Yz-0q@ra.coresystems.de>

Author: linux_junkie
Date: Thu Jun 17 00:21:19 2010
New Revision: 5632
URL: https://tracker.coreboot.org/trac/coreboot/changeset/5632

Log:
This patch adds inteltool support for i810E and ICH2.
Signed-off-by: Joseph Smith <joe at settoplinux.org>
Acked-by: Stefan Reinauer <stepan at coresystems.de>

Modified:
   trunk/util/inteltool/gpio.c
   trunk/util/inteltool/inteltool.c
   trunk/util/inteltool/inteltool.h
   trunk/util/inteltool/memory.c
   trunk/util/inteltool/pcie.c
   trunk/util/inteltool/powermgt.c
   trunk/util/inteltool/rootcmplx.c

Modified: trunk/util/inteltool/gpio.c
==============================================================================
--- trunk/util/inteltool/gpio.c	Fri Jun 11 16:25:40 2010	(r5631)
+++ trunk/util/inteltool/gpio.c	Thu Jun 17 00:21:19 2010	(r5632)
@@ -39,6 +39,25 @@
 	{ 0x3C, 4, "RESERVED" }
 };
 
+static const io_register_t ich2_gpio_registers[] = {
+	{ 0x00, 4, "GPIO_USE_SEL" },
+	{ 0x04, 4, "GP_IO_SEL" },
+	{ 0x08, 4, "RESERVED" },
+	{ 0x0c, 4, "GP_LVL" },
+	{ 0x10, 4, "RESERVED" },
+	{ 0x14, 4, "GPO_TTL" },
+	{ 0x18, 4, "GPO_BLINK" },
+	{ 0x1c, 4, "RESERVED" },
+	{ 0x20, 4, "RESERVED" },
+	{ 0x24, 4, "RESERVED" },
+	{ 0x28, 4, "RESERVED" },
+	{ 0x2c, 4, "GPI_INV" },
+	{ 0x30, 4, "RESERVED" },
+	{ 0x34, 4, "RESERVED" },
+	{ 0x38, 4, "RESERVED" },
+	{ 0x3C, 4, "RESERVED" }
+};
+
 static const io_register_t ich4_gpio_registers[] = {
 	{ 0x00, 4, "GPIO_USE_SEL" },
 	{ 0x04, 4, "GP_IO_SEL" },
@@ -176,6 +195,11 @@
 		gpio_registers = ich4_gpio_registers;
 		size = ARRAY_SIZE(ich4_gpio_registers);
 		break;
+	case PCI_DEVICE_ID_INTEL_ICH2:
+		gpiobase = pci_read_word(sb, 0x58) & 0xfffc;
+		gpio_registers = ich2_gpio_registers;
+		size = ARRAY_SIZE(ich2_gpio_registers);
+		break;
 	case PCI_DEVICE_ID_INTEL_ICH:
 	case PCI_DEVICE_ID_INTEL_ICH0:
 		gpiobase = pci_read_word(sb, 0x58) & 0xfffc;

Modified: trunk/util/inteltool/inteltool.c
==============================================================================
--- trunk/util/inteltool/inteltool.c	Fri Jun 11 16:25:40 2010	(r5631)
+++ trunk/util/inteltool/inteltool.c	Thu Jun 17 00:21:19 2010	(r5632)
@@ -34,6 +34,7 @@
 	{ PCI_VENDOR_ID_INTEL, PCI_DEVICE_ID_INTEL_82443BX_NO_AGP, "82443BX without AGP" },
 	{ PCI_VENDOR_ID_INTEL, PCI_DEVICE_ID_INTEL_82810, "i810" },
 	{ PCI_VENDOR_ID_INTEL, PCI_DEVICE_ID_INTEL_82810DC, "i810-DC100" },
+	{ PCI_VENDOR_ID_INTEL, PCI_DEVICE_ID_INTEL_82810E_MC, "i810E DC-133" },
 	{ PCI_VENDOR_ID_INTEL, PCI_DEVICE_ID_INTEL_82830M, "i830M" },
 	{ PCI_VENDOR_ID_INTEL, PCI_DEVICE_ID_INTEL_82845, "i845" },
 	{ PCI_VENDOR_ID_INTEL, PCI_DEVICE_ID_INTEL_82915, "82915G/P/GV/GL/PL/910GL" },

Modified: trunk/util/inteltool/inteltool.h
==============================================================================
--- trunk/util/inteltool/inteltool.h	Fri Jun 11 16:25:40 2010	(r5631)
+++ trunk/util/inteltool/inteltool.h	Thu Jun 17 00:21:19 2010	(r5632)
@@ -55,6 +55,7 @@
 
 #define PCI_DEVICE_ID_INTEL_82810		0x7120
 #define PCI_DEVICE_ID_INTEL_82810DC		0x7122
+#define PCI_DEVICE_ID_INTEL_82810E_MC		0x7124
 #define PCI_DEVICE_ID_INTEL_82830M		0x3575
 #define PCI_DEVICE_ID_INTEL_82845		0x1a30
 #define PCI_DEVICE_ID_INTEL_82915		0x2580

Modified: trunk/util/inteltool/memory.c
==============================================================================
--- trunk/util/inteltool/memory.c	Fri Jun 11 16:25:40 2010	(r5631)
+++ trunk/util/inteltool/memory.c	Thu Jun 17 00:21:19 2010	(r5632)
@@ -50,6 +50,7 @@
 	case PCI_DEVICE_ID_INTEL_82443LX:
 	case PCI_DEVICE_ID_INTEL_82443BX:
 	case PCI_DEVICE_ID_INTEL_82810:
+	case PCI_DEVICE_ID_INTEL_82810E_MC:
 	case PCI_DEVICE_ID_INTEL_82810DC:
 	case PCI_DEVICE_ID_INTEL_82830M:
 		printf("This northbrigde does not have MCHBAR.\n");

Modified: trunk/util/inteltool/pcie.c
==============================================================================
--- trunk/util/inteltool/pcie.c	Fri Jun 11 16:25:40 2010	(r5631)
+++ trunk/util/inteltool/pcie.c	Thu Jun 17 00:21:19 2010	(r5632)
@@ -49,6 +49,7 @@
  		break;
 	case PCI_DEVICE_ID_INTEL_82810:
 	case PCI_DEVICE_ID_INTEL_82810DC:
+	case PCI_DEVICE_ID_INTEL_82810E_MC:
 	case PCI_DEVICE_ID_INTEL_82830M:
 		printf("This northbrigde does not have EPBAR.\n");
 		return 1;
@@ -102,6 +103,7 @@
  		break;
 	case PCI_DEVICE_ID_INTEL_82810:
 	case PCI_DEVICE_ID_INTEL_82810DC:
+	case PCI_DEVICE_ID_INTEL_82810E_MC:
 		printf("This northbrigde does not have DMIBAR.\n");
 		return 1;
 	default:
@@ -156,6 +158,7 @@
  		break;
 	case PCI_DEVICE_ID_INTEL_82810:
 	case PCI_DEVICE_ID_INTEL_82810DC:
+	case PCI_DEVICE_ID_INTEL_82810E_MC:
 		printf("Error: This northbrigde does not have PCIEXBAR.\n");
 		return 1;
 	default:

Modified: trunk/util/inteltool/powermgt.c
==============================================================================
--- trunk/util/inteltool/powermgt.c	Fri Jun 11 16:25:40 2010	(r5631)
+++ trunk/util/inteltool/powermgt.c	Thu Jun 17 00:21:19 2010	(r5632)
@@ -299,6 +299,69 @@
 	{ 0x7c, 4, "RESERVED" },
 };
 
+static const io_register_t ich2_pm_registers[] = {
+	{ 0x00, 2, "PM1_STS" },
+	{ 0x02, 2, "PM1_EN" },
+	{ 0x04, 4, "PM1_CNT" },
+	{ 0x08, 4, "PM1_TMR" },
+	{ 0x0c, 4, "RESERVED" },
+	{ 0x10, 4, "PROC_CNT" },
+#if DANGEROUS_REGISTERS
+	/* This register returns 0 on read, but reading it may cause
+	 * the system to enter C2 state, which might hang the system.
+	 */
+	{ 0x14, 1, "LV2" },
+	{ 0x15, 1, "RESERVED" },
+	{ 0x16, 2, "RESERVED" },
+#endif
+	{ 0x18, 4, "RESERVED" },
+	{ 0x1c, 4, "RESERVED" },
+	{ 0x20, 4, "RESERVED" },
+	{ 0x24, 4, "RESERVED" },
+	{ 0x28, 2, "GPE0_STS" },
+	{ 0x2a, 2, "GPE0_EN" },
+	{ 0x2c, 2, "GPE1_STS" },
+	{ 0x2e, 2, "GPE1_EN" },
+	{ 0x30, 2, "SMI_EN" },
+	{ 0x32, 2, "RESERVED" },
+	{ 0x34, 2, "SMI_STS" },
+	{ 0x36, 2, "RESERVED" },
+	{ 0x38, 4, "RESERVED" },
+	{ 0x3c, 4, "RESERVED" },
+	{ 0x40, 2, "MON_SMI_STS" },
+	{ 0x42, 2, "RESERVED" },
+	{ 0x44, 2, "DEV_TRP_STS" },
+	{ 0x46, 2, "RESERVED" },
+	{ 0x48, 2, "TRP_EN" },
+	{ 0x4A, 2, "RESERVED" },
+	{ 0x4c, 2, "BUS_ADDR_TRACK" },
+	{ 0x4e, 1, "BUS_CYC_TRACK" },
+	{ 0x4f, 1, "RESERVED" },
+	{ 0x50, 4, "RESERVED" },
+	{ 0x54, 4, "RESERVED" },
+	{ 0x58, 4, "RESERVED" },
+	{ 0x5c, 4, "RESERVED" },
+	/* Here start the TCO registers */
+	{ 0x60, 1, "TCO_RLD" },
+	{ 0x61, 1, "TCO_TMR" },
+	{ 0x62, 1, "TCO_DAT_IN" },
+	{ 0x63, 1, "TCO_DAT_OUT" },
+	{ 0x64, 2, "TCO1_STS" },
+	{ 0x66, 2, "TCO2_STS" },
+	{ 0x68, 2, "TCO1_CNT" },
+	{ 0x6a, 2, "TCO2_CNT" },
+	{ 0x6c, 1, "TCO_MESSAGE1" },
+	{ 0x6d, 1, "TCO_MESSAGE2" },
+	{ 0x6e, 1, "TCO_WDSTATUS" },
+	{ 0x6f, 1, "RESERVED" },
+	{ 0x70, 1, "SW_IRQ_GEN" },
+	{ 0x71, 1, "RESERVED" },
+	{ 0x72, 2, "RESERVED" },
+	{ 0x74, 4, "RESERVED" },
+	{ 0x78, 4, "RESERVED" },
+	{ 0x7c, 4, "RESERVED" },
+};
+
 static const io_register_t ich0_pm_registers[] = {
 	{ 0x00, 2, "PM1_STS" },
 	{ 0x02, 2, "PM1_EN" },
@@ -443,6 +506,11 @@
 		pm_registers = ich4_pm_registers;
 		size = ARRAY_SIZE(ich4_pm_registers);
 		break;
+	case PCI_DEVICE_ID_INTEL_ICH2:
+		pmbase = pci_read_word(sb, 0x40) & 0xfffc;
+		pm_registers = ich2_pm_registers;
+		size = ARRAY_SIZE(ich2_pm_registers);
+		break;
 	case PCI_DEVICE_ID_INTEL_ICH0:
 		pmbase = pci_read_word(sb, 0x40) & 0xfffc;
 		pm_registers = ich0_pm_registers;

Modified: trunk/util/inteltool/rootcmplx.c
==============================================================================
--- trunk/util/inteltool/rootcmplx.c	Fri Jun 11 16:25:40 2010	(r5631)
+++ trunk/util/inteltool/rootcmplx.c	Thu Jun 17 00:21:19 2010	(r5632)
@@ -47,6 +47,7 @@
 		break;
 	case PCI_DEVICE_ID_INTEL_ICH:
 	case PCI_DEVICE_ID_INTEL_ICH0:
+	case PCI_DEVICE_ID_INTEL_ICH2:
 	case PCI_DEVICE_ID_INTEL_ICH4:
 	case PCI_DEVICE_ID_INTEL_ICH4M:
 		printf("This southbridge does not have RCBA.\n");



From joe at settoplinux.org  Thu Jun 17 00:22:00 2010
From: joe at settoplinux.org (Joseph Smith)
Date: Wed, 16 Jun 2010 18:22:00 -0400
Subject: [coreboot] [PATCH] i810E and ICH2 inteltool support
In-Reply-To: <4C194DAB.6060308@coresystems.de>
References: <4C193F90.9080806@settoplinux.org>
	<4C194DAB.6060308@coresystems.de>
Message-ID: <4C194E88.3040304@settoplinux.org>

On 06/16/2010 06:18 PM, Stefan Reinauer wrote:
> Great, thank you.
>
> Acked-by: Stefan Reinauer<stepan at coresystems.de>
>
>
Thanks r5632

-- 
Thanks,
Joseph Smith
Set-Top-Linux
www.settoplinux.org



From mylesgw at gmail.com  Thu Jun 17 00:26:58 2010
From: mylesgw at gmail.com (Myles Watson)
Date: Wed, 16 Jun 2010 16:26:58 -0600
Subject: [coreboot] [PATCH] Simplify device enabling and initialization
In-Reply-To: <4C194C8C.50504@coresystems.de>
References: <AANLkTingtsR4xtaPMENTl3bk5tOWM1hMqR2t9w8Ep3vR@mail.gmail.com>
	<4C194C8C.50504@coresystems.de>
Message-ID: <AANLkTinoQTc8fo8hk1487UJVCpgyL5HbPY7NRoKNMdXI@mail.gmail.com>

On Wed, Jun 16, 2010 at 4:13 PM, Stefan Reinauer <stepan at coresystems.de> wrote:
> Hi Myles,
>
> I like the patch, but it looks like you're wiping calls to adt7463
> initialization on the s2881 completely with no replacement. is that on
> purpose?

Yes.  I know it breaks the s2881, but I'm not sure where to put the
code and I have no way to test it.  I was hoping Ward would still have
one.

Thanks,
Myles



From mylesgw at gmail.com  Thu Jun 17 00:34:23 2010
From: mylesgw at gmail.com (Myles Watson)
Date: Wed, 16 Jun 2010 16:34:23 -0600
Subject: [coreboot] Strange ROMCC failure with Rev 5623
In-Reply-To: <AANLkTinHo_Jak42t3kroe7ePuL77KfogqrhQpxIfAaBO@mail.gmail.com>
References: <AANLkTikgYCZFdyizSDn-4GB14HSO5RhAMsuFHZI_bvls@mail.gmail.com>
	<AANLkTinHo_Jak42t3kroe7ePuL77KfogqrhQpxIfAaBO@mail.gmail.com>
Message-ID: <AANLkTikeZHCMwwWm6k2bTTujJ93tEPeChXhRpwvVjYtJ@mail.gmail.com>

On Wed, Jun 16, 2010 at 12:06 PM, Myles Watson <mylesgw at gmail.com> wrote:
> On Wed, Jun 16, 2010 at 12:00 PM, Myles Watson <mylesgw at gmail.com> wrote:
>> When compiling asus/p2b (and several others), Rev 5622 succeeds, but 5623 fails.
>>
>> make: *** [build/mainboard/asus/p2b/romstage.inc] Segmentation fault
>> make: *** Deleting file `build/mainboard/asus/p2b/romstage.inc'
>>
>> The only difference for these boards is this line in config.h:
>>
>> #define CONFIG_VENDOR_ECS 0
>>
>> Removing this line lets 5623 build correctly.
> Removing any line from the file that doesn't affect the build works.
> (CONFIG_VENDOR_*, CONFIG_DEFAULT_CONSOLE_LEVEL_*, etc.)

Program received signal SIGSEGV, Segmentation fault.
0x0000000000423bbe in free_basic_block (state=0x7fff5dbcbb20, block=0x1392ff0)
    at /home/myles/try/buildrom-devel/work/coreboot/svn/util/romcc/romcc.c:15165
15165			if (child && (child->vertex != -1)) {
(gdb) print child
$1 = (struct block *) 0x1c95950
(gdb) print child->vertex
Cannot access memory at address 0x1c959b8

Thanks,
Myles



From mylesgw at gmail.com  Thu Jun 17 00:40:43 2010
From: mylesgw at gmail.com (Myles Watson)
Date: Wed, 16 Jun 2010 16:40:43 -0600
Subject: [coreboot] Strange ROMCC failure with Rev 5623
In-Reply-To: <AANLkTikeZHCMwwWm6k2bTTujJ93tEPeChXhRpwvVjYtJ@mail.gmail.com>
References: <AANLkTikgYCZFdyizSDn-4GB14HSO5RhAMsuFHZI_bvls@mail.gmail.com>
	<AANLkTinHo_Jak42t3kroe7ePuL77KfogqrhQpxIfAaBO@mail.gmail.com>
	<AANLkTikeZHCMwwWm6k2bTTujJ93tEPeChXhRpwvVjYtJ@mail.gmail.com>
Message-ID: <AANLkTin1AzYcUWEm8imxBqjg9Vrhxwqz0lFCODmPFHyF@mail.gmail.com>

On Wed, Jun 16, 2010 at 4:34 PM, Myles Watson <mylesgw at gmail.com> wrote:
> On Wed, Jun 16, 2010 at 12:06 PM, Myles Watson <mylesgw at gmail.com> wrote:
>> On Wed, Jun 16, 2010 at 12:00 PM, Myles Watson <mylesgw at gmail.com> wrote:
>>> When compiling asus/p2b (and several others), Rev 5622 succeeds, but 5623 fails.
>>>
>>> make: *** [build/mainboard/asus/p2b/romstage.inc] Segmentation fault
>>> make: *** Deleting file `build/mainboard/asus/p2b/romstage.inc'
>>>
>>> The only difference for these boards is this line in config.h:
>>>
>>> #define CONFIG_VENDOR_ECS 0
>>>
>>> Removing this line lets 5623 build correctly.
>> Removing any line from the file that doesn't affect the build works.
>> (CONFIG_VENDOR_*, CONFIG_DEFAULT_CONSOLE_LEVEL_*, etc.)
>
> Program received signal SIGSEGV, Segmentation fault.
> 0x0000000000423bbe in free_basic_block (state=0x7fff5dbcbb20, block=0x1392ff0)
> ? ?at /home/myles/try/buildrom-devel/work/coreboot/svn/util/romcc/romcc.c:15165
> 15165 ? ? ? ? ? ? ? ? ? if (child && (child->vertex != -1)) {
> (gdb) print child
> $1 = (struct block *) 0x1c95950
> (gdb) print child->vertex
> Cannot access memory at address 0x1c959b8
>
It looks like Patrick found this before:
http://www.coreboot.org/pipermail/coreboot/2009-November/054387.html

If I take out the free it works fine.  It seems like there must be a better fix.

Thanks,
Myles



From john.wyzer at gmx.de  Thu Jun 17 01:41:32 2010
From: john.wyzer at gmx.de (John Wyzer)
Date: Thu, 17 Jun 2010 01:41:32 +0200
Subject: [coreboot] request for comments: Gigabyte GA-945PL-S3 (rev. 1.0)
In-Reply-To: <4C192D62.7030706@gmx.de>
References: <4C192D62.7030706@gmx.de>
Message-ID: <4C19612C.6090509@gmx.de>

On 16/06/10 22:00, John Wyzer wrote:
> Board: Gigabyte GA-945PL-S3 (rev. 1.0)

For the BIOS:
I looked around and saw that SST25VF040.REMS cannot be written yet.
I'd be willing to buy a few, desolder the current one and volunteer to
run flashrom via trial and error (in August).
Would that help or is someone already working on something equivalent?



From ward at gnu.org  Thu Jun 17 02:22:37 2010
From: ward at gnu.org (Ward Vandewege)
Date: Wed, 16 Jun 2010 20:22:37 -0400
Subject: [coreboot] [PATCH] Simplify device enabling and initialization
In-Reply-To: <AANLkTingtsR4xtaPMENTl3bk5tOWM1hMqR2t9w8Ep3vR@mail.gmail.com>
References: <AANLkTingtsR4xtaPMENTl3bk5tOWM1hMqR2t9w8Ep3vR@mail.gmail.com>
Message-ID: <20100617002237.GA2700@countzero.vandewege.net>

On Wed, Jun 16, 2010 at 02:50:42PM -0600, Myles Watson wrote:
> This patch breaks the s2881, which was doing some odd acrobatics in
> order to get a device initialized after its parent.  It should be an
> easy fix to do it correctly now, but I don't have an s2881 to test on.
>  Ward?

Yep, I've got (the guts) of an s2881 lying on my desk here, and can test any
patches you throw at me :)

Thanks,
Ward.

-- 
Ward Vandewege <ward at fsf.org>
Free Software Foundation - Senior Systems Administrator



From ebiederm at xmission.com  Thu Jun 17 02:40:18 2010
From: ebiederm at xmission.com (Eric W. Biederman)
Date: Wed, 16 Jun 2010 17:40:18 -0700
Subject: [coreboot] Strange ROMCC failure with Rev 5623
In-Reply-To: <AANLkTin1AzYcUWEm8imxBqjg9Vrhxwqz0lFCODmPFHyF@mail.gmail.com>
	(Myles Watson's message of "Wed\, 16 Jun 2010 16\:40\:43 -0600")
References: <AANLkTikgYCZFdyizSDn-4GB14HSO5RhAMsuFHZI_bvls@mail.gmail.com>
	<AANLkTinHo_Jak42t3kroe7ePuL77KfogqrhQpxIfAaBO@mail.gmail.com>
	<AANLkTikeZHCMwwWm6k2bTTujJ93tEPeChXhRpwvVjYtJ@mail.gmail.com>
	<AANLkTin1AzYcUWEm8imxBqjg9Vrhxwqz0lFCODmPFHyF@mail.gmail.com>
Message-ID: <m1iq5isd8t.fsf@fess.ebiederm.org>

Myles Watson <mylesgw at gmail.com> writes:

> On Wed, Jun 16, 2010 at 4:34 PM, Myles Watson <mylesgw at gmail.com> wrote:
>> On Wed, Jun 16, 2010 at 12:06 PM, Myles Watson <mylesgw at gmail.com> wrote:
>>> On Wed, Jun 16, 2010 at 12:00 PM, Myles Watson <mylesgw at gmail.com> wrote:
>>>> When compiling asus/p2b (and several others), Rev 5622 succeeds, but 5623 fails.
>>>>
>>>> make: *** [build/mainboard/asus/p2b/romstage.inc] Segmentation fault
>>>> make: *** Deleting file `build/mainboard/asus/p2b/romstage.inc'
>>>>
>>>> The only difference for these boards is this line in config.h:
>>>>
>>>> #define CONFIG_VENDOR_ECS 0
>>>>
>>>> Removing this line lets 5623 build correctly.
>>> Removing any line from the file that doesn't affect the build works.
>>> (CONFIG_VENDOR_*, CONFIG_DEFAULT_CONSOLE_LEVEL_*, etc.)
>>
>> Program received signal SIGSEGV, Segmentation fault.
>> 0x0000000000423bbe in free_basic_block (state=0x7fff5dbcbb20, block=0x1392ff0)
>> ? ?at /home/myles/try/buildrom-devel/work/coreboot/svn/util/romcc/romcc.c:15165
>> 15165 ? ? ? ? ? ? ? ? ? if (child && (child->vertex != -1)) {
>> (gdb) print child
>> $1 = (struct block *) 0x1c95950
>> (gdb) print child->vertex
>> Cannot access memory at address 0x1c959b8
>>
> It looks like Patrick found this before:
> http://www.coreboot.org/pipermail/coreboot/2009-November/054387.html
>
> If I take out the free it works fine.  It seems like there must be a better fix.

Agreed.

I took a look at this a little bit with Stefan and he helped me track where
the double free is.

The routine doing the freeing badly needs to be rewritten to use simpler logic
as the recursive logic it is using now just doesn't work, and it winds
up to be a bit of a crap shoot if your compile gets killed by this or not.

Eric




From garyhunt at mnsi.net  Thu Jun 17 03:15:31 2010
From: garyhunt at mnsi.net (GS Hunt)
Date: Wed, 16 Jun 2010 21:15:31 -0400
Subject: [coreboot] AMD740G - Not supported yet?
Message-ID: <4C197733.6060906@mnsi.net>

I noticed that there is still a request for AMD740G chipset info almost
a year later after I first posted some info regarding it. Is it in limbo
now?

Cheers,

Gary



From peter at stuge.se  Thu Jun 17 10:04:08 2010
From: peter at stuge.se (Peter Stuge)
Date: Thu, 17 Jun 2010 10:04:08 +0200
Subject: [coreboot] [PATCH] Simplify device enabling and initialization
In-Reply-To: <AANLkTingtsR4xtaPMENTl3bk5tOWM1hMqR2t9w8Ep3vR@mail.gmail.com>
References: <AANLkTingtsR4xtaPMENTl3bk5tOWM1hMqR2t9w8Ep3vR@mail.gmail.com>
Message-ID: <20100617080408.25711.qmail@stuge.se>

Myles Watson wrote:
> If we initialize and enable devices in the order that they are found
> in the tree, instead of the order that they were added to the list, it
> simplifies the code.  It also makes it so that removing a device from
> the devicetree.cb file won't change when its resources are enabled.
..
> Signed-off-by: Myles Watson <mylesgw at gmail.com>

Acked-by: Peter Stuge <peter at stuge.se>


> This patch breaks the s2881, which was doing some odd acrobatics in
> order to get a device initialized after its parent.

If neccessary then I would be in favor of mainboard-specific hooks
from coreboot, that are separate from the device tree. But maybe the
init for s2881 can be done using a coreboot "driver" ?


//Peter



From stepan at coresystems.de  Thu Jun 17 11:17:24 2010
From: stepan at coresystems.de (Stefan Reinauer)
Date: Thu, 17 Jun 2010 11:17:24 +0200
Subject: [coreboot] AMD740G - Not supported yet?
In-Reply-To: <4C197733.6060906@mnsi.net>
References: <4C197733.6060906@mnsi.net>
Message-ID: <4C19E824.1050206@coresystems.de>

On 6/17/10 3:15 AM, GS Hunt wrote:
> I noticed that there is still a request for AMD740G chipset info almost
> a year later after I first posted some info regarding it. Is it in limbo
> now?
>   
I doubt anybody was ever working on this. There is, however, support for
AMD's RS780 chipset which might be fairly similar, so if you have 740
hardware, feel encouraged to let us know how far you get with the RS780
code.

Stefan



From Greg.Chandler at wellsfargo.com  Thu Jun 17 11:17:59 2010
From: Greg.Chandler at wellsfargo.com (Greg.Chandler at wellsfargo.com)
Date: Thu, 17 Jun 2010 04:17:59 -0500
Subject: [coreboot] Can not add bug report via website.
Message-ID: <569016304DCCAB46A4C779C0EBE5E30E24B24D8311@MSGCMSV21016.ent.wfb.bank.corp>

I've tried to add this several times to via the bug report tool on the website, but get stuck in a loop on the captcha page.
Can I post this here to get it looked at?


Filo does not boot from the CF or PCMCIA controllers.  I did find a work around, some 70 prom flashes later..

I've limited the scope of my work to ide.c, for the legacy boot, not the grub-compatible.

This is one will need the help of a real developer to fix properly.

Here is what I've found:
Problem 1:
There are 2 types of detections for IDE interfaces:
if ((sata && class == 0x180) || (pata && class == 0x101)) {
  and
if (hdr == HEADER_TYPE_BRIDGE || hdr == HEADER_TYPE_CARDBUS) {

The 2nd does not work...  The first excludes the CF/PC-CARD because it doesn't include the correct class.  I have no idea how to fix the CARDBUS check.  It's got stuff that reaches into the libpayload code..
So I've made this modification:
if ((sata && class == 0x180) || (pata && class == 0x101) || (pata && class == 0x607)) {
This explicitly directs the driver to treat the CF as an IDE device.
That part works, and it does to a proper detection once it's in the "if" statement. The problem is, as far as I can tell detects this card before all others, and stops.  I can see no other IDE channels once I set this.

Problem 2:
We enter this in "native PCI mode", which is ok.
      if ((prog_if & mask) || (devclass != 0x0101)) {
                debug("native PCI mode\n");
                if ((ctrl_index & 1) == 0) {
                        /* Primary channel */
                        ctrl->cmd_base = pci_read_resource(dev, 0);
                        ctrl->ctrl_base = pci_read_resource(dev, 1);
                } else {
                        /* Secondary channel */
                        ctrl->cmd_base = pci_read_resource(dev, 2);
                        ctrl->ctrl_base = pci_read_resource(dev, 3);
                }
                ctrl->cmd_base &= ~3;
                ctrl->ctrl_base &= ~3;

What is not ok, is that we are now using pci_read_resource to set the ctrl->* stuff when we _explicitly_ listed those elsewhere..  Obviously that doesn't work...  I have no idea why we do the "&= ~3" either, so I'm not inclined to mess with it.
What does work, is adding these two lines after those:
                ctrl->cmd_base = 0x1e0;
                ctrl->ctrl_base = 0x1ec;
Obviously we just overwrite all the crap we just set with the pci_read call and the additional lines.

Once these are done, the machine can boot of the CF slot, but ONLY the CF slot.

A real fix would probably be cool.


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

From c-d.hailfinger.devel.2006 at gmx.net  Thu Jun 17 11:40:04 2010
From: c-d.hailfinger.devel.2006 at gmx.net (Carl-Daniel Hailfinger)
Date: Thu, 17 Jun 2010 11:40:04 +0200
Subject: [coreboot] AMD740G - Not supported yet?
In-Reply-To: <4C19E824.1050206@coresystems.de>
References: <4C197733.6060906@mnsi.net> <4C19E824.1050206@coresystems.de>
Message-ID: <4C19ED74.5040608@gmx.net>

On 17.06.2010 11:17, Stefan Reinauer wrote:
> On 6/17/10 3:15 AM, GS Hunt wrote:
>   
>> I noticed that there is still a request for AMD740G chipset info almost
>> a year later after I first posted some info regarding it. Is it in limbo
>> now?
>>   
>>     
> I doubt anybody was ever working on this. There is, however, support for
> AMD's RS780 chipset which might be fairly similar, so if you have 740
> hardware, feel encouraged to let us know how far you get with the RS780
> code.
>   

According to my sources, AMD 740G is basically AMD 690G, but you may
have to change one or two PCI IDs. That could result in a working
system. I don't have the hardware, so I'm unable to test.

Regards,
Carl-Daniel

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




From peter at stuge.se  Thu Jun 17 12:06:31 2010
From: peter at stuge.se (Peter Stuge)
Date: Thu, 17 Jun 2010 12:06:31 +0200
Subject: [coreboot] Will my board be supported?
In-Reply-To: <4C190E87.60504@physik.tu-darmstadt.de>
References: <4C190E87.60504@physik.tu-darmstadt.de>
Message-ID: <20100617100631.15335.qmail@stuge.se>

Hi Alexander,

Alexander Hug wrote:
> I am interested in Coreboot and want to try it on my "old" desktop.
> It is an "ASUS A7V880", but i cannot find it in the list of boards.

Basically the answer is no, your board will not be supported, unless
you help add the support for it! :)

The K8T890 chipset is already supported, and maybe 880 is similar
enough that you can reuse all existing code.


//Peter



From peter at stuge.se  Thu Jun 17 12:08:55 2010
From: peter at stuge.se (Peter Stuge)
Date: Thu, 17 Jun 2010 12:08:55 +0200
Subject: [coreboot] jetway PA78VM5 spi flashing
In-Reply-To: <AANLkTinMZwbLpDzs5UeRtl21SeNageevp7XksSy7uKr8@mail.gmail.com>
References: <AANLkTinMZwbLpDzs5UeRtl21SeNageevp7XksSy7uKr8@mail.gmail.com>
Message-ID: <20100617100855.15837.qmail@stuge.se>

Hello,

Qing Pei Wang wrote:
> Recently i found that the mainboard which i used(Jetway PA78VM-H-LF)
> is not stable, most of the spi flashing caused data error.
> the data writing is ok, but the bios data does not as the same as the
> original. the SPI FLASH is Winbond W25X80A

Is the flash chip flashed onboard using flashrom, or externally by
another system?

If onboard, what chip is SPI bus master on the board? Is it the SB700
or some LPC->SPI bridge?


//Peter



From wangqingpei at gmail.com  Thu Jun 17 12:47:10 2010
From: wangqingpei at gmail.com (Qing Pei Wang)
Date: Thu, 17 Jun 2010 18:47:10 +0800
Subject: [coreboot] jetway PA78VM5 spi flashing
In-Reply-To: <20100617100855.15837.qmail@stuge.se>
References: <AANLkTinMZwbLpDzs5UeRtl21SeNageevp7XksSy7uKr8@mail.gmail.com>
	<20100617100855.15837.qmail@stuge.se>
Message-ID: <AANLkTimClFWQzSPajqLNqPLYImSQenmYbhAus3HUlAmn@mail.gmail.com>

hi,
  it's external flash programmer SF100 and SB700

On Thu, Jun 17, 2010 at 6:08 PM, Peter Stuge <peter at stuge.se> wrote:

> Hello,
>
> Qing Pei Wang wrote:
> > Recently i found that the mainboard which i used(Jetway PA78VM-H-LF)
> > is not stable, most of the spi flashing caused data error.
> > the data writing is ok, but the bios data does not as the same as the
> > original. the SPI FLASH is Winbond W25X80A
>
> Is the flash chip flashed onboard using flashrom, or externally by
> another system?
>
> If onboard, what chip is SPI bus master on the board? Is it the SB700
> or some LPC->SPI bridge?
>
>
> //Peter
>
> --
> coreboot mailing list: coreboot at coreboot.org
> http://www.coreboot.org/mailman/listinfo/coreboot
>



-- 
Wang Qing Pei
MSN:wangqingpei at hotmail.com <MSN%3Awangqingpei at hotmail.com>
Gmail:wangqingpei at gmail.com <Gmail%3Awangqingpei at gmail.com>
Phone:86+13426369984
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20100617/b7d9a46e/attachment.html>

From peter at stuge.se  Thu Jun 17 13:41:15 2010
From: peter at stuge.se (Peter Stuge)
Date: Thu, 17 Jun 2010 13:41:15 +0200
Subject: [coreboot] jetway PA78VM5 spi flashing
In-Reply-To: <AANLkTimClFWQzSPajqLNqPLYImSQenmYbhAus3HUlAmn@mail.gmail.com>
References: <AANLkTinMZwbLpDzs5UeRtl21SeNageevp7XksSy7uKr8@mail.gmail.com>
	<20100617100855.15837.qmail@stuge.se>
	<AANLkTimClFWQzSPajqLNqPLYImSQenmYbhAus3HUlAmn@mail.gmail.com>
Message-ID: <20100617114115.32002.qmail@stuge.se>

Qing Pei Wang wrote:
> hi,
>   it's external flash programmer SF100 and SB700

Same problem both with SF100 and onboard flashing?

That could mean that the flash chip is bad.


//Peter



From alexander.hug at physik.tu-darmstadt.de  Thu Jun 17 13:26:21 2010
From: alexander.hug at physik.tu-darmstadt.de (Alexander Hug)
Date: Thu, 17 Jun 2010 13:26:21 +0200
Subject: [coreboot] Will my board be supported?
In-Reply-To: <20100617100631.15335.qmail@stuge.se>
References: <4C190E87.60504@physik.tu-darmstadt.de>
	<20100617100631.15335.qmail@stuge.se>
Message-ID: <4C1A065D.9080702@physik.tu-darmstadt.de>

Hello Peter, hello list!

Thanks for the fast answer!

I have a bad feeling because the  K_8_T890 is for AMD64 Platform, while 
KT880 (w/o "8") is for "old" socket A processors ... but maybe it is 
just  a further development of the old one.
Has somebody experience in getting technical documents from VIA?

Regards, Alex

Peter Stuge schrieb:
> Hi Alexander,
>
> Alexander Hug wrote:
>   
>> I am interested in Coreboot and want to try it on my "old" desktop.
>> It is an "ASUS A7V880", but i cannot find it in the list of boards.
>>     
>
> Basically the answer is no, your board will not be supported, unless
> you help add the support for it! :)
>
> The K8T890 chipset is already supported, and maybe 880 is similar
> enough that you can reuse all existing code.
>
>
> //Peter
>
>   




From wangqingpei at gmail.com  Thu Jun 17 14:18:28 2010
From: wangqingpei at gmail.com (Qing Pei Wang)
Date: Thu, 17 Jun 2010 20:18:28 +0800
Subject: [coreboot] jetway PA78VM5 spi flashing
In-Reply-To: <20100617114115.32002.qmail@stuge.se>
References: <AANLkTinMZwbLpDzs5UeRtl21SeNageevp7XksSy7uKr8@mail.gmail.com>
	<20100617100855.15837.qmail@stuge.se>
	<AANLkTimClFWQzSPajqLNqPLYImSQenmYbhAus3HUlAmn@mail.gmail.com>
	<20100617114115.32002.qmail@stuge.se>
Message-ID: <AANLkTimbg6PzQZN5DCFhZSLcSRLdPp91zu-g-tyt3vDy@mail.gmail.com>

I tried another board, it's ok...
it may because of the flashchip.

On Thu, Jun 17, 2010 at 7:41 PM, Peter Stuge <peter at stuge.se> wrote:

> Qing Pei Wang wrote:
> > hi,
> >   it's external flash programmer SF100 and SB700
>
> Same problem both with SF100 and onboard flashing?
>
> That could mean that the flash chip is bad.
>
>
> //Peter
>
> --
> coreboot mailing list: coreboot at coreboot.org
> http://www.coreboot.org/mailman/listinfo/coreboot
>



-- 
Wang Qing Pei
MSN:wangqingpei at hotmail.com <MSN%3Awangqingpei at hotmail.com>
Gmail:wangqingpei at gmail.com <Gmail%3Awangqingpei at gmail.com>
Phone:86+13426369984
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20100617/4be03e04/attachment.html>

From juhe at iki.fi  Thu Jun 17 15:07:01 2010
From: juhe at iki.fi (Juhana Helovuo)
Date: Thu, 17 Jun 2010 16:07:01 +0300
Subject: [coreboot] Porting to Asus M4A785-M
In-Reply-To: <AANLkTim-7sixU0sg94kvYGbLq0WRJzaxsEiN4mdgL-9G@mail.gmail.com>
References: <1276453504.27968.52.camel@bart> <4C188515.3000409@iki.fi>
	<C99ACA6966B34C90B11874735E1F302F@chimp> <1276718131.3866.4.camel@bart>
	<AANLkTim-7sixU0sg94kvYGbLq0WRJzaxsEiN4mdgL-9G@mail.gmail.com>
Message-ID: <1276780021.3607.8.camel@bart>

On Wed, 2010-06-16 at 14:04 -0600, Myles Watson wrote:
> On Wed, Jun 16, 2010 at 1:55 PM, Juhana Helovuo <juhe at iki.fi> wrote:
> > On Wed, 2010-06-16 at 08:30 -0600, Myles Watson wrote:
> >> > Coreboot now boots past the romstage and starts setting up PCI devices.
> >> > Unfortunately, it crashes at some point during PCI setup. I do not have
> >> > access to the boot log right now, but could post it later.
> >> That would be helpful.
> >>
> >
> > Ok, here I have a boot log attached, in case anyone is interested.
> >
> > At the end of the log the machine resets and the same starts over from
> > the beginning.
> >
> > I do not know what the PCI device setup should look like, but towards
> > the end of the log it seems to iterate over the same devices many times.
> 
> Yes.  I'm not sure why that's happening.  Could you send your devicetree.cb?


Yes, here it is attached. It is copied and modified from AMD Tilapia
mainboard, because that seemed to be a close relative.

Meanwhile, I added call to it8712f_kill_watchdog() , like Rudolf Marek
suggested. That changed the behavior so that the machine no longer
reboots in the middle of iterating through PCI busses and devices, but
instead it seems to go on iterating infinitely, or presumably until
malloc runs out of memory.

Perhaps I should start out with a very minimalist devicetree and then
add parts as needed?

Is there a way to derive the correct contents, or at least the outline,
of devicetree.cb from "lspci" dumps?


Best regards,
Juhana Helovuo



-------------- next part --------------
# sample config for amd/tilapia_fam10
chip northbridge/amd/amdfam10/root_complex
	device lapic_cluster 0 on
		chip cpu/amd/socket_AM3  #L1 and DDR3
			 device lapic 0 on end
		end
	end
	device pci_domain 0 on
		chip northbridge/amd/amdfam10
			device pci 18.0 on #  northbridge
				chip southbridge/amd/rs780
					device pci 0.0 on end # HT  	0x9600
					device pci 1.0 on end # Internal Graphics P2P bridge 0x9602
					#device pci 2.0 on end # PCIE P2P bridge (external graphics) 0x9603
					device pci 3.0 on end # PCIE P2P bridge	0x960b
					#device pci 4.0 on end # PCIE P2P bridge 0x9604
					device pci 5.0 off end # PCIE P2P bridge 0x9605
					device pci 6.0 off end # PCIE P2P bridge 0x9606
					device pci 7.0 off end # PCIE P2P bridge 0x9607
					device pci 8.0 off end # NB/SB Link P2P bridge
					#device pci 9.0 on end #
					device pci a.0 on end #
					register "gppsb_configuration" = "1"   # Configuration B
					register "gpp_configuration" = "3"   # Configuration D default
					register "port_enable" = "0x6fc"
					register "gfx_dev2_dev3" = "1"
					register "gfx_dual_slot" = "2"

					register "gfx_lane_reversal" = "0"
					register "gfx_tmds" = "0"
					register "gfx_compliance" = "0"
					register "gfx_reconfiguration" = "1"
					register "gfx_link_width" = "0"
				end
				chip southbridge/amd/sb700 # it is under NB/SB Link, but on the same pri bus
					device pci 11.0 on end # SATA
					device pci 12.0 on end # USB
					device pci 12.1 on end # USB
					device pci 12.2 on end # USB
					device pci 13.0 on end # USB
					device pci 13.1 on end # USB
					device pci 13.2 on end # USB
	 				device pci 14.0 on # SM
						chip drivers/generic/generic #dimm 0-0-0
							device i2c 50 on end
						end
						chip drivers/generic/generic #dimm 0-0-1
							device i2c 51 on end
						end
						chip drivers/generic/generic #dimm 0-1-0
							device i2c 52 on end
						end
						chip drivers/generic/generic #dimm 0-1-1
							device i2c 53 on end
						end
					end # SM
					device pci 14.1 on end # IDE    0x439c
					device pci 14.2 on end # HDA    0x4383
					device pci 14.3 on # LPC	0x439d
						chip superio/ite/it8712f
							device pnp 2e.0 off #  Floppy
								io 0x60 = 0x3f0
								irq 0x70 = 6
								drq 0x74 = 2
							end
							device pnp 2e.1 on #  Com1
								io 0x60 = 0x3f8
								irq 0x70 = 4
							end
							device pnp 2e.2 off #  Com2
								io 0x60 = 0x2f8
								irq 0x70 = 3
							end
							device pnp 2e.3 off #  Parallel Port
								io 0x60 = 0x378
								irq 0x70 = 7
							end
							device pnp 2e.4 off end #  EC
							device pnp 2e.5 on #  Keyboard
								io 0x60 = 0x60
								io 0x62 = 0x64
								irq 0x70 = 1
							end
							device pnp 2e.6 on #  Mouse
								irq 0x70 = 12
							end
							device pnp 2e.7 off #  GPIO, must be closed for unresolved reason.
							end
							device pnp 2e.8 off #  MIDI
								io 0x60 = 0x300
								irq 0x70 = 9
							end
							device pnp 2e.9 off #  GAME
								io 0x60 = 0x220
							end
							device pnp 2e.a off end #  CIR
						end	#superio/ite/it8718f
					end		#LPC
					device pci 14.4 on end # PCI 0x4384
					device pci 14.5 on end # USB 2
					register "ide0_enable" = "1"
					register "sata0_enable" = "1"
					register "boot_switch_sata_ide" = "0"	# 0: boot from SATA. 1: IDE
					register "hda_viddid" = "0x10ec0882"
				end	#southbridge/amd/sb700
			end #  device pci 18.0

			#device pci 18.0 on end
			#device pci 18.0 on end
			device pci 18.1 on end
			device pci 18.2 on end
			device pci 18.3 on end
			device pci 18.4 on end
		end
	end #pci_domain
end

From mylesgw at gmail.com  Thu Jun 17 15:31:25 2010
From: mylesgw at gmail.com (Myles Watson)
Date: Thu, 17 Jun 2010 07:31:25 -0600
Subject: [coreboot] Porting to Asus M4A785-M
In-Reply-To: <1276780021.3607.8.camel@bart>
References: <1276453504.27968.52.camel@bart> <4C188515.3000409@iki.fi>
	<C99ACA6966B34C90B11874735E1F302F@chimp>
	<1276718131.3866.4.camel@bart>
	<AANLkTim-7sixU0sg94kvYGbLq0WRJzaxsEiN4mdgL-9G@mail.gmail.com>
	<1276780021.3607.8.camel@bart>
Message-ID: <3C92B942FD2F45A78D16F334E642629B@chimp>


> Yes, here it is attached. It is copied and modified from AMD Tilapia
> mainboard, because that seemed to be a close relative.
Thanks.

> Meanwhile, I added call to it8712f_kill_watchdog() , like Rudolf Marek
> suggested. That changed the behavior so that the machine no longer
> reboots in the middle of iterating through PCI busses and devices, but
> instead it seems to go on iterating infinitely, or presumably until
> malloc runs out of memory.
OK

> Perhaps I should start out with a very minimalist devicetree and then
> add parts as needed?
Yes.  Instead of commenting out devices from the Tilapia board, I think you
should turn them off.  The exception to that is: 
			#device pci 18.0 on end
			#device pci 18.0 on end

Those are the HyperTransport links.  There is no explicit way to set a link
number in the device tree, so multiple copies of the device are added.  If
you move those around, your devices will be on different links.  In other
words, if you move both of those lines (not commented out) above the other
device pci 18.0 on, then your devices will be on link 2 instead of link 0.

> Is there a way to derive the correct contents, or at least the outline,
> of devicetree.cb from "lspci" dumps?

You can look at lspci -xxx from the factory BIOS and look at the register
settings to determine which link is being used, or you can just try moving
those lines around.

Thanks,
Myles




From mylesgw at gmail.com  Thu Jun 17 17:12:39 2010
From: mylesgw at gmail.com (Myles Watson)
Date: Thu, 17 Jun 2010 09:12:39 -0600
Subject: [coreboot] Strange ROMCC failure with Rev 5623
In-Reply-To: <m1iq5isd8t.fsf@fess.ebiederm.org>
References: <AANLkTikgYCZFdyizSDn-4GB14HSO5RhAMsuFHZI_bvls@mail.gmail.com>
	<AANLkTinHo_Jak42t3kroe7ePuL77KfogqrhQpxIfAaBO@mail.gmail.com>
	<AANLkTikeZHCMwwWm6k2bTTujJ93tEPeChXhRpwvVjYtJ@mail.gmail.com>
	<AANLkTin1AzYcUWEm8imxBqjg9Vrhxwqz0lFCODmPFHyF@mail.gmail.com>
	<m1iq5isd8t.fsf@fess.ebiederm.org>
Message-ID: <AANLkTimwcqevmGFO5IWY9sYO_dGirYrNKgGr_Oexah40@mail.gmail.com>

>> It looks like Patrick found this before:
>> http://www.coreboot.org/pipermail/coreboot/2009-November/054387.html
>>
>> If I take out the free it works fine. ?It seems like there must be a better fix.
>
> Agreed.
>
> I took a look at this a little bit with Stefan and he helped me track where
> the double free is.
>
> The routine doing the freeing badly needs to be rewritten to use simpler logic
> as the recursive logic it is using now just doesn't work, and it winds
> up to be a bit of a crap shoot if your compile gets killed by this or not.

What if we just agree that host machines have a lot of RAM, romcc is
not a long-running program, and life will be easier if nothing gets
freed.  How much RAM are we talking about?  It might be easier to
debug if nothing gets zeroed.

Thanks,
Myles



From rminnich at gmail.com  Thu Jun 17 17:16:23 2010
From: rminnich at gmail.com (ron minnich)
Date: Thu, 17 Jun 2010 08:16:23 -0700
Subject: [coreboot] Strange ROMCC failure with Rev 5623
In-Reply-To: <AANLkTimwcqevmGFO5IWY9sYO_dGirYrNKgGr_Oexah40@mail.gmail.com>
References: <AANLkTikgYCZFdyizSDn-4GB14HSO5RhAMsuFHZI_bvls@mail.gmail.com>
	<AANLkTinHo_Jak42t3kroe7ePuL77KfogqrhQpxIfAaBO@mail.gmail.com>
	<AANLkTikeZHCMwwWm6k2bTTujJ93tEPeChXhRpwvVjYtJ@mail.gmail.com>
	<AANLkTin1AzYcUWEm8imxBqjg9Vrhxwqz0lFCODmPFHyF@mail.gmail.com>
	<m1iq5isd8t.fsf@fess.ebiederm.org>
	<AANLkTimwcqevmGFO5IWY9sYO_dGirYrNKgGr_Oexah40@mail.gmail.com>
Message-ID: <AANLkTinmRCiu7RHimubMZvuPQh8PJ16i2uyXnbDk-A3l@mail.gmail.com>

On Thu, Jun 17, 2010 at 8:12 AM, Myles Watson <mylesgw at gmail.com> wrote:

> What if we just agree that host machines have a lot of RAM, romcc is
> not a long-running program, and life will be easier if nothing gets
> freed. ?How much RAM are we talking about? ?It might be easier to
> debug if nothing gets zeroed.

Reasonable. You could at least try it. Use LD_PRELOAD and make free()
a no-op :-)

It's ugly but sometimes ...

there are times when it's simpler to consume resources and keep in
mind that on exit, they're freed (you'd be surprised how often I have
to point out to people that doing lots of work to free memory before
calling exit() has no effect on the system free memory -- "You mean
the system can somehow free the process memory when the process
exits?" -- I'm not kidding!)

ron



From stepan at coresystems.de  Thu Jun 17 18:15:26 2010
From: stepan at coresystems.de (Stefan Reinauer)
Date: Thu, 17 Jun 2010 18:15:26 +0200
Subject: [coreboot] Strange ROMCC failure with Rev 5623
In-Reply-To: <AANLkTimwcqevmGFO5IWY9sYO_dGirYrNKgGr_Oexah40@mail.gmail.com>
References: <AANLkTikgYCZFdyizSDn-4GB14HSO5RhAMsuFHZI_bvls@mail.gmail.com>	<AANLkTinHo_Jak42t3kroe7ePuL77KfogqrhQpxIfAaBO@mail.gmail.com>	<AANLkTikeZHCMwwWm6k2bTTujJ93tEPeChXhRpwvVjYtJ@mail.gmail.com>	<AANLkTin1AzYcUWEm8imxBqjg9Vrhxwqz0lFCODmPFHyF@mail.gmail.com>	<m1iq5isd8t.fsf@fess.ebiederm.org>
	<AANLkTimwcqevmGFO5IWY9sYO_dGirYrNKgGr_Oexah40@mail.gmail.com>
Message-ID: <4C1A4A1E.7050203@coresystems.de>

On 6/17/10 5:12 PM, Myles Watson wrote:
>>> It looks like Patrick found this before:
>>> http://www.coreboot.org/pipermail/coreboot/2009-November/054387.html
>>>
>>> If I take out the free it works fine.  It seems like there must be a better fix.
>>>       
>> Agreed.
>>
>> I took a look at this a little bit with Stefan and he helped me track where
>> the double free is.
>>
>> The routine doing the freeing badly needs to be rewritten to use simpler logic
>> as the recursive logic it is using now just doesn't work, and it winds
>> up to be a bit of a crap shoot if your compile gets killed by this or not.
>>     
> What if we just agree that host machines have a lot of RAM, romcc is
> not a long-running program, and life will be easier if nothing gets
> freed.
>   
Then we should also switch to Visual C++ in order to stay compliant. ;-)

Stefan



From svn at coreboot.org  Thu Jun 17 18:16:57 2010
From: svn at coreboot.org (repository service)
Date: Thu, 17 Jun 2010 18:16:57 +0200
Subject: [coreboot] [commit] r5633 - in trunk/src: devices
	drivers/i2c/adt7463 include/device
	mainboard/emulation/qemu-x86 mainboard/tyan/s2881
	northbridge/amd/amdfam10 northbridge/amd/amdk8
	northbridge/amd/gx1 northb...
Message-ID: <E1OPHlx-0008UD-8g@ra.coresystems.de>

Author: myles
Date: Thu Jun 17 18:16:56 2010
New Revision: 5633
URL: https://tracker.coreboot.org/trac/coreboot/changeset/5633

Log:
Always enable parent resources before child resources.

Always initialize parents before children.

Move s2881 code into a driver.

Signed-off-by: Myles Watson <mylesgw at gmail.com>
Acked-by: Peter Stuge <peter at stuge.se>

Added:
   trunk/src/drivers/i2c/adt7463/
   trunk/src/drivers/i2c/adt7463/adt7463.c   (contents, props changed)
      - copied, changed from r5632, trunk/src/mainboard/tyan/s2881/mainboard.c
   trunk/src/drivers/i2c/adt7463/chip.h   (contents, props changed)
      - copied, changed from r5632, trunk/src/drivers/i2c/adm1027/chip.h
Modified:
   trunk/src/devices/cardbus_device.c
   trunk/src/devices/device.c
   trunk/src/devices/pci_device.c
   trunk/src/devices/root_device.c
   trunk/src/include/device/device.h
   trunk/src/mainboard/emulation/qemu-x86/northbridge.c
   trunk/src/mainboard/tyan/s2881/mainboard.c
   trunk/src/northbridge/amd/amdfam10/northbridge.c
   trunk/src/northbridge/amd/amdk8/northbridge.c
   trunk/src/northbridge/amd/gx1/northbridge.c
   trunk/src/northbridge/amd/gx2/northbridge.c
   trunk/src/northbridge/amd/lx/northbridge.c
   trunk/src/northbridge/intel/e7501/northbridge.c
   trunk/src/northbridge/intel/e7520/northbridge.c
   trunk/src/northbridge/intel/e7525/northbridge.c
   trunk/src/northbridge/intel/i3100/northbridge.c
   trunk/src/northbridge/intel/i3100/pciexp_porta_ep80579.c
   trunk/src/northbridge/intel/i440bx/northbridge.c
   trunk/src/northbridge/intel/i440lx/northbridge.c
   trunk/src/northbridge/intel/i82810/northbridge.c
   trunk/src/northbridge/intel/i82830/northbridge.c
   trunk/src/northbridge/intel/i855/northbridge.c
   trunk/src/northbridge/intel/i945/northbridge.c
   trunk/src/northbridge/via/cn400/northbridge.c
   trunk/src/northbridge/via/cn700/northbridge.c
   trunk/src/northbridge/via/cx700/cx700_lpc.c
   trunk/src/northbridge/via/cx700/northbridge.c
   trunk/src/northbridge/via/vt8601/northbridge.c
   trunk/src/northbridge/via/vt8623/northbridge.c
   trunk/src/northbridge/via/vx800/northbridge.c
   trunk/src/northbridge/via/vx800/vx800_lpc.c
   trunk/src/southbridge/amd/amd8111/amd8111_lpc.c
   trunk/src/southbridge/amd/cs5530/cs5530_isa.c
   trunk/src/southbridge/amd/cs5535/cs5535.c
   trunk/src/southbridge/amd/cs5536/cs5536.c
   trunk/src/southbridge/amd/sb600/sb600_lpc.c
   trunk/src/southbridge/amd/sb700/sb700_lpc.c
   trunk/src/southbridge/broadcom/bcm5785/bcm5785_lpc.c
   trunk/src/southbridge/intel/esb6300/esb6300_lpc.c
   trunk/src/southbridge/intel/i3100/i3100_lpc.c
   trunk/src/southbridge/intel/i82801ax/i82801ax_lpc.c
   trunk/src/southbridge/intel/i82801bx/i82801bx_lpc.c
   trunk/src/southbridge/intel/i82801cx/i82801cx_lpc.c
   trunk/src/southbridge/intel/i82801dx/i82801dx_lpc.c
   trunk/src/southbridge/intel/i82801ex/i82801ex_lpc.c
   trunk/src/southbridge/intel/i82801gx/i82801gx_lpc.c
   trunk/src/southbridge/intel/i82801gx/i82801gx_pci.c
   trunk/src/southbridge/nvidia/ck804/ck804_lpc.c
   trunk/src/southbridge/nvidia/mcp55/mcp55_lpc.c
   trunk/src/southbridge/sis/sis966/sis966_lpc.c
   trunk/src/southbridge/via/vt8235/vt8235_lpc.c
   trunk/src/southbridge/via/vt8237r/vt8237r_lpc.c

Modified: trunk/src/devices/cardbus_device.c
==============================================================================
--- trunk/src/devices/cardbus_device.c	Thu Jun 17 00:21:19 2010	(r5632)
+++ trunk/src/devices/cardbus_device.c	Thu Jun 17 18:16:56 2010	(r5633)
@@ -170,8 +170,6 @@
 	pci_write_config16(dev, PCI_BRIDGE_CONTROL, ctrl);
 
 	pci_dev_enable_resources(dev);
-
-	enable_childrens_resources(dev);
 }
 
 struct device_operations default_cardbus_ops_bus = {

Modified: trunk/src/devices/device.c
==============================================================================
--- trunk/src/devices/device.c	Thu Jun 17 00:21:19 2010	(r5632)
+++ trunk/src/devices/device.c	Thu Jun 17 18:16:56 2010	(r5633)
@@ -782,33 +782,34 @@
 }
 
 /**
- * @brief Enable the resources for a specific device
+ * @brief Enable the resources for devices on a link
  *
- * @param dev the device whose resources are to be enabled
+ * @param link the link whose devices' resources are to be enabled
  *
  * Enable resources of the device by calling the device specific
  * enable_resources() method.
  *
  * The parent's resources should be enabled first to avoid having enabling
  * order problem. This is done by calling the parent's enable_resources()
- * method and let that method to call it's children's enable_resoruces()
- * method via the (global) enable_childrens_resources().
+ * method before its childrens' enable_resources() methods.
  *
- * Indirect mutual recursion:
- *	enable_resources() -> device_operations::enable_resource()
- *	device_operations::enable_resource() -> enable_children_resources()
- *	enable_children_resources() -> enable_resources()
  */
-void enable_resources(struct device *dev)
+static void enable_resources(struct bus *link)
 {
-	if (!dev->enabled) {
-		return;
+	struct device *dev;
+	struct bus *c_link;
+
+	for (dev = link->children; dev; dev = dev->sibling) {
+		if (dev->enabled && dev->ops && dev->ops->enable_resources) {
+			dev->ops->enable_resources(dev);
+		}
 	}
-	if (!dev->ops || !dev->ops->enable_resources) {
-		printk(BIOS_ERR, "%s missing enable_resources\n", dev_path(dev));
-		return;
+
+	for (dev = link->children; dev; dev = dev->sibling) {
+		for (c_link = dev->link_list; c_link; c_link = c_link->next) {
+			enable_resources(c_link);
+		}
 	}
-	dev->ops->enable_resources(dev);
 }
 
 /**
@@ -1036,39 +1037,77 @@
  */
 void dev_enable(void)
 {
+	struct bus *link;
+
 	printk(BIOS_INFO, "Enabling resources...\n");
 
 	/* now enable everything. */
-	enable_resources(&dev_root);
+	for (link = dev_root.link_list; link; link = link->next)
+		enable_resources(link);
 
 	printk(BIOS_INFO, "done.\n");
 }
 
 /**
- * @brief Initialize all devices in the global device list.
+ * @brief Initialize a specific device
+ *
+ * @param dev the device to be initialized
+ *
+ * The parent should be initialized first to avoid having an ordering
+ * problem. This is done by calling the parent's init()
+ * method before its childrens' init() methods.
  *
- * Starting at the first device on the global device link list,
- * walk the list and call the device's init() method to do deivce
- * specific setup.
  */
-void dev_initialize(void)
+static void init_dev(struct device *dev)
+{
+	if (!dev->enabled) {
+		return;
+	}
+
+	if (!dev->initialized && dev->ops && dev->ops->init) {
+		if (dev->path.type == DEVICE_PATH_I2C) {
+			printk(BIOS_DEBUG, "smbus: %s[%d]->",
+			       dev_path(dev->bus->dev), dev->bus->link_num);
+		}
+
+		printk(BIOS_DEBUG, "%s init\n", dev_path(dev));
+		dev->initialized = 1;
+		dev->ops->init(dev);
+	}
+}
+
+static void init_link(struct bus *link)
 {
 	struct device *dev;
+	struct bus *c_link;
 
-	printk(BIOS_INFO, "Initializing devices...\n");
-	for (dev = all_devices; dev; dev = dev->next) {
-		if (dev->enabled && !dev->initialized &&
-		    dev->ops && dev->ops->init) {
-			if (dev->path.type == DEVICE_PATH_I2C) {
-				printk(BIOS_DEBUG, "smbus: %s[%d]->",
-					     dev_path(dev->bus->dev),
-					     dev->bus->link_num);
-			}
-			printk(BIOS_DEBUG, "%s init\n", dev_path(dev));
-			dev->initialized = 1;
-			dev->ops->init(dev);
+	for (dev = link->children; dev; dev = dev->sibling) {
+		init_dev(dev);
+	}
+
+	for (dev = link->children; dev; dev = dev->sibling) {
+		for (c_link = dev->link_list; c_link; c_link = c_link->next) {
+			init_link(c_link);
 		}
 	}
+}
+
+/**
+ * @brief Initialize all devices in the global device tree.
+ *
+ * Starting at the root device, call the device's init() method to do device-
+ * specific setup, then call each child's init() method.
+ */
+void dev_initialize(void)
+{
+	struct bus *link;
+
+	printk(BIOS_INFO, "Initializing devices...\n");
+
+	/* now initialize everything. */
+	for (link = dev_root.link_list; link; link = link->next)
+		init_link(link);
+
 	printk(BIOS_INFO, "Devices initialized\n");
 	show_all_devs(BIOS_SPEW, "After init.");
 }

Modified: trunk/src/devices/pci_device.c
==============================================================================
--- trunk/src/devices/pci_device.c	Thu Jun 17 00:21:19 2010	(r5632)
+++ trunk/src/devices/pci_device.c	Thu Jun 17 18:16:56 2010	(r5633)
@@ -621,7 +621,6 @@
 	pci_write_config16(dev, PCI_BRIDGE_CONTROL, ctrl);
 
 	pci_dev_enable_resources(dev);
-	enable_childrens_resources(dev);
 }
 
 void pci_bus_reset(struct bus *bus)

Modified: trunk/src/devices/root_device.c
==============================================================================
--- trunk/src/devices/root_device.c	Thu Jun 17 00:21:19 2010	(r5632)
+++ trunk/src/devices/root_device.c	Thu Jun 17 18:16:56 2010	(r5633)
@@ -32,7 +32,7 @@
  * that encompass the resources for the entire system.
  * @param root Pointer to the device structure for the system root device
  */
-void root_dev_read_resources(device_t root)
+static void root_dev_read_resources(device_t root)
 {
 	printk(BIOS_ERR, "%s should never be called.\n", __func__);
 }
@@ -44,7 +44,7 @@
  * and every device under it which are all of the devices.
  * @param root Pointer to the device structure for the system root device
  */
-void root_dev_set_resources(device_t root)
+static void root_dev_set_resources(device_t root)
 {
 	printk(BIOS_ERR, "%s should never be called.\n", __func__);
 }
@@ -115,33 +115,8 @@
 	return max;
 }
 
-/**
- * @brief Enable resources for children devices
- *
- * @param dev the device whos children's resources are to be enabled
- *
- * This function is called by the global enable_resource() indirectly via the
- * device_operation::enable_resources() method of devices.
- *
- * Indirect mutual recursion:
- *	enable_childrens_resources() -> enable_resources()
- *	enable_resources() -> device_operation::enable_resources()
- *	device_operation::enable_resources() -> enable_children_resources()
- */
-void enable_childrens_resources(device_t dev)
-{
-	struct bus *link;
-	for(link = dev->link_list; link; link = link->next) {
-		device_t child;
-		for(child = link->children; child; child = child->sibling) {
-			enable_resources(child);
-		}
-	}
-}
-
-void root_dev_enable_resources(device_t dev)
+static void root_dev_enable_resources(device_t dev)
 {
-	enable_childrens_resources(dev);
 }
 
 /**
@@ -152,16 +127,16 @@
  *
  * This function is the default scan_bus() method of the root device.
  */
-unsigned int root_dev_scan_bus(device_t root, unsigned int max)
+static unsigned int root_dev_scan_bus(device_t root, unsigned int max)
 {
 	return scan_static_bus(root, max);
 }
 
-void root_dev_init(device_t root)
+static void root_dev_init(device_t root)
 {
 }
 
-void root_dev_reset(struct bus *bus)
+static void root_dev_reset(struct bus *bus)
 {
 	printk(BIOS_INFO, "Reseting board...\n");
 	hard_reset();

Copied and modified: trunk/src/drivers/i2c/adt7463/adt7463.c (from r5632, trunk/src/mainboard/tyan/s2881/mainboard.c)
==============================================================================
--- trunk/src/mainboard/tyan/s2881/mainboard.c	Thu Jun 17 00:21:19 2010	(r5632, copy source)
+++ trunk/src/drivers/i2c/adt7463/adt7463.c	Thu Jun 17 18:16:56 2010	(r5633)
@@ -28,6 +28,8 @@
 /**
  * Do some S2881-specific HWM initialization for the ADT7463 chip.
  *
+ * Should be factored out so that it can be more general.
+ *
  * See Analog Devices ADT7463 datasheet, Rev C (2004):
  * http://www.analog.com/en/prod/0,,766_825_ADT7463,00.html
  */
@@ -98,56 +100,23 @@
 	printk(BIOS_DEBUG, "ADT7463 properly initialized\n");
 }
 
-static void dummy_noop(device_t dummy)
+static void adt7463_noop(device_t dummy)
 {
 }
 
-static struct device_operations dummy_operations = {
-	.read_resources		= dummy_noop,
-	.set_resources		= dummy_noop,
-	.enable_resources	= dummy_noop,
+static struct device_operations adt7463_operations = {
+	.read_resources		= adt7463_noop,
+	.set_resources		= adt7463_noop,
+	.enable_resources	= adt7463_noop,
 	.init			= adt7463_init,
 };
 
-static unsigned int scan_root_bus(device_t root, unsigned int max)
-{
-	struct device_path path;
-	device_t dummy;
-
-	max = root_dev_scan_bus(root, max);
-
-	printk(BIOS_DEBUG, "scan_root_bus ok\n");
-
-	/* The following is a little silly. We need a hook into the boot
-	 * process *after* the ADT7463 device has been initialized. So we
-	 * create this dummy device, and we put the ADT7463 S2881 specific
-	 * settings in its init function, which gets called
-	 * as the last device to be initialized.
-	 */
-
-	path.type = DEVICE_PATH_PNP;
-	path.pnp.port = 0;
-	path.pnp.device = 0;
-	dummy = alloc_dev(root->link_list, &path);
-	dummy->ops = &dummy_operations;
-
-	return max;
-}
-
-static struct device_operations mainboard_operations = {
-	.read_resources		= root_dev_read_resources,
-	.set_resources		= root_dev_set_resources,
-	.enable_resources	= root_dev_enable_resources,
-	.init			= root_dev_init,
-	.scan_bus		= scan_root_bus,
-};
-
 static void enable_dev(struct device *dev)
 {
-	dev->ops = &mainboard_operations;
+	dev->ops = &adt7463_operations;
 }
 
 struct chip_operations mainboard_ops = {
-	CHIP_NAME("Tyan S2881 Mainboard")
+	CHIP_NAME("adt7463")
 	.enable_dev = enable_dev,
 };

Copied and modified: trunk/src/drivers/i2c/adt7463/chip.h (from r5632, trunk/src/drivers/i2c/adm1027/chip.h)
==============================================================================
--- trunk/src/drivers/i2c/adm1027/chip.h	Thu Jun 17 00:21:19 2010	(r5632, copy source)
+++ trunk/src/drivers/i2c/adt7463/chip.h	Thu Jun 17 18:16:56 2010	(r5633)
@@ -1,4 +1,4 @@
-extern struct chip_operations drivers_i2c_adm1027_ops;
+extern struct chip_operations drivers_i2c_adt7463_ops;
 
-struct drivers_i2c_adm1027_config {
+struct drivers_i2c_adt7463_config {
 };

Modified: trunk/src/include/device/device.h
==============================================================================
--- trunk/src/include/device/device.h	Thu Jun 17 00:21:19 2010	(r5632)
+++ trunk/src/include/device/device.h	Thu Jun 17 18:16:56 2010	(r5633)
@@ -107,7 +107,6 @@
 int reset_bus(struct bus *bus);
 unsigned int scan_bus(struct device *bus, unsigned int max);
 void assign_resources(struct bus *bus);
-void enable_resources(struct device *dev);
 void enumerate_static_device(void);
 void enumerate_static_devices(void);
 const char *dev_path(device_t dev);
@@ -146,12 +145,5 @@
 extern struct device_operations default_dev_ops_root;
 void pci_domain_read_resources(struct device *dev);
 unsigned int pci_domain_scan_bus(struct device *dev, unsigned int max);
-void root_dev_read_resources(device_t dev);
-void root_dev_set_resources(device_t dev);
 unsigned int scan_static_bus(device_t bus, unsigned int max);
-void enable_childrens_resources(device_t dev);
-void root_dev_enable_resources(device_t dev);
-unsigned int root_dev_scan_bus(device_t root, unsigned int max);
-void root_dev_init(device_t dev);
-void root_dev_reset(struct bus *bus);
 #endif /* DEVICE_H */

Modified: trunk/src/mainboard/emulation/qemu-x86/northbridge.c
==============================================================================
--- trunk/src/mainboard/emulation/qemu-x86/northbridge.c	Thu Jun 17 00:21:19 2010	(r5632)
+++ trunk/src/mainboard/emulation/qemu-x86/northbridge.c	Thu Jun 17 18:16:56 2010	(r5633)
@@ -122,8 +122,8 @@
 static struct device_operations pci_domain_ops = {
 	.read_resources		= cpu_pci_domain_read_resources,
 	.set_resources		= cpu_pci_domain_set_resources,
-	.enable_resources	= enable_childrens_resources,
-	.init			= 0,
+	.enable_resources	= NULL,
+	.init			= NULL,
 	.scan_bus		= pci_domain_scan_bus,
 };
 

Modified: trunk/src/mainboard/tyan/s2881/mainboard.c
==============================================================================
--- trunk/src/mainboard/tyan/s2881/mainboard.c	Thu Jun 17 00:21:19 2010	(r5632)
+++ trunk/src/mainboard/tyan/s2881/mainboard.c	Thu Jun 17 18:16:56 2010	(r5633)
@@ -21,133 +21,8 @@
  */
 
 #include <device/device.h>
-#include <console/console.h>
-#include <device/smbus.h>
 #include "chip.h"
 
-/**
- * Do some S2881-specific HWM initialization for the ADT7463 chip.
- *
- * See Analog Devices ADT7463 datasheet, Rev C (2004):
- * http://www.analog.com/en/prod/0,,766_825_ADT7463,00.html
- */
-static void adt7463_init(device_t dev)
-{
-	device_t smbus_dev, adt7463;
-	struct device_path path;
-	int result;
-
-	/* Find the SMBus controller (AMD-8111). */
-	smbus_dev = dev_find_device(0x1022, 0x746b, 0);
-	if (!smbus_dev)
-		die("SMBus controller not found\n");
-	printk(BIOS_DEBUG, "SMBus controller found\n");
-
-	/* Find the ADT7463 device. */
-	path.type = DEVICE_PATH_I2C;
-	path.i2c.device = 0x2d;
-	adt7463 = find_dev_path(smbus_dev->link_list, &path);
-	if (!adt7463)
-		die("ADT7463 not found\n");
-	printk(BIOS_DEBUG, "ADT7463 found\n");
-
-	/* Set all fans to 'Fastest Speed Calculated by All 3 Temperature
-	 * Channels Controls PWMx'.
-	 */
-	result = smbus_write_byte(adt7463, 0x5c, 0xc2);
-	result = smbus_write_byte(adt7463, 0x5d, 0xc2);
-	result = smbus_write_byte(adt7463, 0x5e, 0xc2);
-
-	/* Make sure that our fans never stop when temp. falls below Tmin,
-	 * but rather keep going at minimum duty cycle (applies to automatic
-	 * fan control mode only).
-	 */
-	result = smbus_write_byte(adt7463, 0x62, 0xc0);
-
-	/* Set minimum PWM duty cycle to 25%, rather than the default 50%. */
-	result = smbus_write_byte(adt7463, 0x64, 0x40);
-	result = smbus_write_byte(adt7463, 0x65, 0x40);
-	result = smbus_write_byte(adt7463, 0x66, 0x40);
-
-	/* Set Tmin to 55C, rather than the default 90C. Above this temperature
-	 * the fans will start blowing harder as temperature increases
-	 * (automatic mode only).
-	 */
-	result = smbus_write_byte(adt7463, 0x67, 0x37);
-	result = smbus_write_byte(adt7463, 0x68, 0x37);
-	result = smbus_write_byte(adt7463, 0x69, 0x37);
-
-	/* Set THERM limit to 70C, rather than the default 100C.
-	 * The fans will kick in at 100% if the sensors reach this temperature,
-	 * (only in automatic mode, but supposedly even when hardware is
-	 * locked up). This is a failsafe measure.
-	 */
-	result = smbus_write_byte(adt7463, 0x6a, 0x46);
-	result = smbus_write_byte(adt7463, 0x6b, 0x46);
-	result = smbus_write_byte(adt7463, 0x6c, 0x46);
-
-	/* Remote temperature 1 offset (LSB == 0.25C). */
-	result = smbus_write_byte(adt7463, 0x70, 0x02);
-
-	/* Remote temperature 2 offset (LSB == 0.25C). */
-	result = smbus_write_byte(adt7463, 0x72, 0x01);
-
-	/* Set TACH measurements to normal (1/second). */
-	result = smbus_write_byte(adt7463, 0x78, 0xf0);
-
-	printk(BIOS_DEBUG, "ADT7463 properly initialized\n");
-}
-
-static void dummy_noop(device_t dummy)
-{
-}
-
-static struct device_operations dummy_operations = {
-	.read_resources		= dummy_noop,
-	.set_resources		= dummy_noop,
-	.enable_resources	= dummy_noop,
-	.init			= adt7463_init,
-};
-
-static unsigned int scan_root_bus(device_t root, unsigned int max)
-{
-	struct device_path path;
-	device_t dummy;
-
-	max = root_dev_scan_bus(root, max);
-
-	printk(BIOS_DEBUG, "scan_root_bus ok\n");
-
-	/* The following is a little silly. We need a hook into the boot
-	 * process *after* the ADT7463 device has been initialized. So we
-	 * create this dummy device, and we put the ADT7463 S2881 specific
-	 * settings in its init function, which gets called
-	 * as the last device to be initialized.
-	 */
-
-	path.type = DEVICE_PATH_PNP;
-	path.pnp.port = 0;
-	path.pnp.device = 0;
-	dummy = alloc_dev(root->link_list, &path);
-	dummy->ops = &dummy_operations;
-
-	return max;
-}
-
-static struct device_operations mainboard_operations = {
-	.read_resources		= root_dev_read_resources,
-	.set_resources		= root_dev_set_resources,
-	.enable_resources	= root_dev_enable_resources,
-	.init			= root_dev_init,
-	.scan_bus		= scan_root_bus,
-};
-
-static void enable_dev(struct device *dev)
-{
-	dev->ops = &mainboard_operations;
-}
-
 struct chip_operations mainboard_ops = {
 	CHIP_NAME("Tyan S2881 Mainboard")
-	.enable_dev = enable_dev,
 };

Modified: trunk/src/northbridge/amd/amdfam10/northbridge.c
==============================================================================
--- trunk/src/northbridge/amd/amdfam10/northbridge.c	Thu Jun 17 00:21:19 2010	(r5632)
+++ trunk/src/northbridge/amd/amdfam10/northbridge.c	Thu Jun 17 18:16:56 2010	(r5633)
@@ -604,12 +604,6 @@
 	}
 }
 
-static void amdfam10_enable_resources(device_t dev)
-{
-	pci_dev_enable_resources(dev);
-	enable_childrens_resources(dev);
-}
-
 static void mcf0_control_init(struct device *dev)
 {
 }
@@ -617,7 +611,7 @@
 static struct device_operations northbridge_operations = {
 	.read_resources	  = amdfam10_read_resources,
 	.set_resources	  = amdfam10_set_resources,
-	.enable_resources = amdfam10_enable_resources,
+	.enable_resources = pci_dev_enable_resources,
 	.init		  = mcf0_control_init,
 	.scan_bus	  = amdfam10_scan_chains,
 	.enable		  = 0,
@@ -1145,8 +1139,8 @@
 static struct device_operations pci_domain_ops = {
 	.read_resources	  = amdfam10_domain_read_resources,
 	.set_resources	  = amdfam10_domain_set_resources,
-	.enable_resources = enable_childrens_resources,
-	.init		  = 0,
+	.enable_resources = NULL,
+	.init		  = NULL,
 	.scan_bus	  = amdfam10_domain_scan_bus,
 #if CONFIG_MMCONF_SUPPORT_DEFAULT
 	.ops_pci_bus	  = &pci_ops_mmconf,

Modified: trunk/src/northbridge/amd/amdk8/northbridge.c
==============================================================================
--- trunk/src/northbridge/amd/amdk8/northbridge.c	Thu Jun 17 00:21:19 2010	(r5632)
+++ trunk/src/northbridge/amd/amdk8/northbridge.c	Thu Jun 17 18:16:56 2010	(r5633)
@@ -574,12 +574,6 @@
 	}
 }
 
-static void amdk8_enable_resources(device_t dev)
-{
-	pci_dev_enable_resources(dev);
-	enable_childrens_resources(dev);
-}
-
 static void mcf0_control_init(struct device *dev)
 {
 #if 0
@@ -593,7 +587,7 @@
 static struct device_operations northbridge_operations = {
 	.read_resources	  = amdk8_read_resources,
 	.set_resources	  = amdk8_set_resources,
-	.enable_resources = amdk8_enable_resources,
+	.enable_resources = pci_dev_enable_resources,
 	.init		  = mcf0_control_init,
 	.scan_bus	  = amdk8_scan_chains,
 	.enable		  = 0,
@@ -1119,8 +1113,8 @@
 static struct device_operations pci_domain_ops = {
 	.read_resources	  = amdk8_domain_read_resources,
 	.set_resources	  = amdk8_domain_set_resources,
-	.enable_resources = enable_childrens_resources,
-	.init		  = 0,
+	.enable_resources = NULL,
+	.init		  = NULL,
 	.scan_bus	  = amdk8_domain_scan_bus,
 	.ops_pci_bus	  = &pci_cf8_conf1,
 };

Modified: trunk/src/northbridge/amd/gx1/northbridge.c
==============================================================================
--- trunk/src/northbridge/amd/gx1/northbridge.c	Thu Jun 17 00:21:19 2010	(r5632)
+++ trunk/src/northbridge/amd/gx1/northbridge.c	Thu Jun 17 18:16:56 2010	(r5633)
@@ -169,8 +169,8 @@
 static struct device_operations pci_domain_ops = {
         .read_resources   = pci_domain_read_resources,
         .set_resources    = pci_domain_set_resources,
-        .enable_resources = enable_childrens_resources,
-        .init             = 0,
+        .enable_resources = NULL,
+        .init             = NULL,
         .scan_bus         = pci_domain_scan_bus,
 };
 

Modified: trunk/src/northbridge/amd/gx2/northbridge.c
==============================================================================
--- trunk/src/northbridge/amd/gx2/northbridge.c	Thu Jun 17 00:21:19 2010	(r5632)
+++ trunk/src/northbridge/amd/gx2/northbridge.c	Thu Jun 17 18:16:56 2010	(r5633)
@@ -448,8 +448,8 @@
 static struct device_operations pci_domain_ops = {
         .read_resources   = pci_domain_read_resources,
         .set_resources    = pci_domain_set_resources,
-        .enable_resources = enable_childrens_resources,
-        .init             = 0,
+        .enable_resources = NULL,
+        .init             = NULL,
         .scan_bus         = pci_domain_scan_bus,
 };
 

Modified: trunk/src/northbridge/amd/lx/northbridge.c
==============================================================================
--- trunk/src/northbridge/amd/lx/northbridge.c	Thu Jun 17 00:21:19 2010	(r5632)
+++ trunk/src/northbridge/amd/lx/northbridge.c	Thu Jun 17 18:16:56 2010	(r5633)
@@ -441,7 +441,7 @@
 static struct device_operations pci_domain_ops = {
 	.read_resources = pci_domain_read_resources,
 	.set_resources = pci_domain_set_resources,
-	.enable_resources = enable_childrens_resources,
+	.enable_resources = NULL,
 	.scan_bus = pci_domain_scan_bus,
 	.enable = pci_domain_enable,
 };

Modified: trunk/src/northbridge/intel/e7501/northbridge.c
==============================================================================
--- trunk/src/northbridge/intel/e7501/northbridge.c	Thu Jun 17 00:21:19 2010	(r5632)
+++ trunk/src/northbridge/intel/e7501/northbridge.c	Thu Jun 17 18:16:56 2010	(r5633)
@@ -141,8 +141,8 @@
 static struct device_operations pci_domain_ops = {
         .read_resources   = pci_domain_read_resources,
         .set_resources    = pci_domain_set_resources,
-        .enable_resources = enable_childrens_resources,
-        .init             = 0,
+        .enable_resources = NULL,
+        .init             = NULL,
         .scan_bus         = pci_domain_scan_bus,
 	.ops_pci_bus      = &pci_cf8_conf1,
 };

Modified: trunk/src/northbridge/intel/e7520/northbridge.c
==============================================================================
--- trunk/src/northbridge/intel/e7520/northbridge.c	Thu Jun 17 00:21:19 2010	(r5632)
+++ trunk/src/northbridge/intel/e7520/northbridge.c	Thu Jun 17 18:16:56 2010	(r5633)
@@ -163,8 +163,8 @@
 static struct device_operations pci_domain_ops = {
 	.read_resources   = pci_domain_read_resources,
 	.set_resources    = pci_domain_set_resources,
-	.enable_resources = enable_childrens_resources,
-	.init             = 0,
+	.enable_resources = NULL,
+	.init             = NULL,
 	.scan_bus         = e7520_domain_scan_bus,
 	.ops_pci_bus      = &pci_cf8_conf1, /* Do we want to use the memory mapped space here? */
 };

Modified: trunk/src/northbridge/intel/e7525/northbridge.c
==============================================================================
--- trunk/src/northbridge/intel/e7525/northbridge.c	Thu Jun 17 00:21:19 2010	(r5632)
+++ trunk/src/northbridge/intel/e7525/northbridge.c	Thu Jun 17 18:16:56 2010	(r5633)
@@ -163,8 +163,8 @@
 static struct device_operations pci_domain_ops = {
 	.read_resources   = pci_domain_read_resources,
 	.set_resources    = pci_domain_set_resources,
-	.enable_resources = enable_childrens_resources,
-	.init             = 0,
+	.enable_resources = NULL,
+	.init             = NULL,
 	.scan_bus         = e7525_domain_scan_bus,
 	.ops_pci_bus      = &pci_cf8_conf1, /* Do we want to use the memory mapped space here? */
 };

Modified: trunk/src/northbridge/intel/i3100/northbridge.c
==============================================================================
--- trunk/src/northbridge/intel/i3100/northbridge.c	Thu Jun 17 00:21:19 2010	(r5632)
+++ trunk/src/northbridge/intel/i3100/northbridge.c	Thu Jun 17 18:16:56 2010	(r5633)
@@ -184,8 +184,8 @@
 static struct device_operations pci_domain_ops = {
 	.read_resources   = pci_domain_read_resources,
 	.set_resources    = pci_domain_set_resources,
-	.enable_resources = enable_childrens_resources,
-	.init             = 0,
+	.enable_resources = NULL,
+	.init             = NULL,
 	.scan_bus         = i3100_domain_scan_bus,
 	.ops_pci_bus      = &pci_cf8_conf1, /* Do we want to use the memory mapped space here? */
 };

Modified: trunk/src/northbridge/intel/i3100/pciexp_porta_ep80579.c
==============================================================================
--- trunk/src/northbridge/intel/i3100/pciexp_porta_ep80579.c	Thu Jun 17 00:21:19 2010	(r5632)
+++ trunk/src/northbridge/intel/i3100/pciexp_porta_ep80579.c	Thu Jun 17 18:16:56 2010	(r5633)
@@ -64,7 +64,6 @@
 		dev->command |= PCI_COMMAND_MEMORY;
 	}
 	pci_dev_enable_resources(dev);
-	enable_childrens_resources(dev);
 }
 
 

Modified: trunk/src/northbridge/intel/i440bx/northbridge.c
==============================================================================
--- trunk/src/northbridge/intel/i440bx/northbridge.c	Thu Jun 17 00:21:19 2010	(r5632)
+++ trunk/src/northbridge/intel/i440bx/northbridge.c	Thu Jun 17 18:16:56 2010	(r5633)
@@ -124,8 +124,8 @@
 static struct device_operations pci_domain_ops = {
 	.read_resources		= pci_domain_read_resources,
 	.set_resources		= i440bx_domain_set_resources,
-	.enable_resources	= enable_childrens_resources,
-	.init			= 0,
+	.enable_resources	= NULL,
+	.init			= NULL,
 	.scan_bus		= pci_domain_scan_bus,
 };
 

Modified: trunk/src/northbridge/intel/i440lx/northbridge.c
==============================================================================
--- trunk/src/northbridge/intel/i440lx/northbridge.c	Thu Jun 17 00:21:19 2010	(r5632)
+++ trunk/src/northbridge/intel/i440lx/northbridge.c	Thu Jun 17 18:16:56 2010	(r5633)
@@ -152,8 +152,8 @@
 static struct device_operations pci_domain_ops = {
 	.read_resources		= pci_domain_read_resources,
 	.set_resources		= i440lx_domain_set_resources,
-	.enable_resources	= enable_childrens_resources,
-	.init			= 0,
+	.enable_resources	= NULL,
+	.init			= NULL,
 	.scan_bus		= pci_domain_scan_bus,
 };
 

Modified: trunk/src/northbridge/intel/i82810/northbridge.c
==============================================================================
--- trunk/src/northbridge/intel/i82810/northbridge.c	Thu Jun 17 00:21:19 2010	(r5632)
+++ trunk/src/northbridge/intel/i82810/northbridge.c	Thu Jun 17 18:16:56 2010	(r5633)
@@ -184,8 +184,8 @@
 static struct device_operations pci_domain_ops = {
 	.read_resources		= pci_domain_read_resources,
 	.set_resources		= pci_domain_set_resources,
-	.enable_resources	= enable_childrens_resources,
-	.init			= 0,
+	.enable_resources	= NULL,
+	.init			= NULL,
 	.scan_bus		= pci_domain_scan_bus,
 };
 

Modified: trunk/src/northbridge/intel/i82830/northbridge.c
==============================================================================
--- trunk/src/northbridge/intel/i82830/northbridge.c	Thu Jun 17 00:21:19 2010	(r5632)
+++ trunk/src/northbridge/intel/i82830/northbridge.c	Thu Jun 17 18:16:56 2010	(r5633)
@@ -164,8 +164,8 @@
 static struct device_operations pci_domain_ops = {
 	.read_resources		= pci_domain_read_resources,
 	.set_resources		= pci_domain_set_resources,
-	.enable_resources	= enable_childrens_resources,
-	.init			= 0,
+	.enable_resources	= NULL,
+	.init			= NULL,
 	.scan_bus		= pci_domain_scan_bus,
 };
 

Modified: trunk/src/northbridge/intel/i855/northbridge.c
==============================================================================
--- trunk/src/northbridge/intel/i855/northbridge.c	Thu Jun 17 00:21:19 2010	(r5632)
+++ trunk/src/northbridge/intel/i855/northbridge.c	Thu Jun 17 18:16:56 2010	(r5633)
@@ -140,8 +140,8 @@
 static struct device_operations pci_domain_ops = {
         .read_resources   = pci_domain_read_resources,
         .set_resources    = pci_domain_set_resources,
-        .enable_resources = enable_childrens_resources,
-        .init             = 0,
+        .enable_resources = NULL,
+        .init             = NULL,
         .scan_bus         = pci_domain_scan_bus,
 };
 

Modified: trunk/src/northbridge/intel/i945/northbridge.c
==============================================================================
--- trunk/src/northbridge/intel/i945/northbridge.c	Thu Jun 17 00:21:19 2010	(r5632)
+++ trunk/src/northbridge/intel/i945/northbridge.c	Thu Jun 17 18:16:56 2010	(r5633)
@@ -224,8 +224,8 @@
 static struct device_operations pci_domain_ops = {
 	.read_resources   = pci_domain_read_resources,
 	.set_resources    = pci_domain_set_resources,
-	.enable_resources = enable_childrens_resources,
-	.init             = 0,
+	.enable_resources = NULL,
+	.init             = NULL,
 	.scan_bus         = pci_domain_scan_bus,
 #if CONFIG_MMCONF_SUPPORT_DEFAULT
 	.ops_pci_bus	  = &pci_ops_mmconf,

Modified: trunk/src/northbridge/via/cn400/northbridge.c
==============================================================================
--- trunk/src/northbridge/via/cn400/northbridge.c	Thu Jun 17 00:21:19 2010	(r5632)
+++ trunk/src/northbridge/via/cn400/northbridge.c	Thu Jun 17 18:16:56 2010	(r5633)
@@ -283,8 +283,8 @@
 static struct device_operations pci_domain_ops = {
 	.read_resources   = cn400_domain_read_resources,
 	.set_resources    = cn400_domain_set_resources,
-	.enable_resources = enable_childrens_resources,
-	.init             = 0,
+	.enable_resources = NULL,
+	.init             = NULL,
 	.scan_bus         = cn400_domain_scan_bus,
 };
 

Modified: trunk/src/northbridge/via/cn700/northbridge.c
==============================================================================
--- trunk/src/northbridge/via/cn700/northbridge.c	Thu Jun 17 00:21:19 2010	(r5632)
+++ trunk/src/northbridge/via/cn700/northbridge.c	Thu Jun 17 18:16:56 2010	(r5633)
@@ -205,8 +205,8 @@
 static struct device_operations pci_domain_ops = {
 	.read_resources   = pci_domain_read_resources,
 	.set_resources    = pci_domain_set_resources,
-	.enable_resources = enable_childrens_resources,
-	.init             = 0,
+	.enable_resources = NULL,
+	.init             = NULL,
 	.scan_bus         = pci_domain_scan_bus,
 };
 

Modified: trunk/src/northbridge/via/cx700/cx700_lpc.c
==============================================================================
--- trunk/src/northbridge/via/cx700/cx700_lpc.c	Thu Jun 17 00:21:19 2010	(r5632)
+++ trunk/src/northbridge/via/cx700/cx700_lpc.c	Thu Jun 17 18:16:56 2010	(r5633)
@@ -270,7 +270,6 @@
 {
 	/* Enable SuperIO decoding */
 	pci_dev_enable_resources(dev);
-	enable_childrens_resources(dev);
 }
 
 static void cx700_lpc_init(struct device *dev)

Modified: trunk/src/northbridge/via/cx700/northbridge.c
==============================================================================
--- trunk/src/northbridge/via/cx700/northbridge.c	Thu Jun 17 00:21:19 2010	(r5632)
+++ trunk/src/northbridge/via/cx700/northbridge.c	Thu Jun 17 18:16:56 2010	(r5633)
@@ -134,8 +134,8 @@
 static struct device_operations pci_domain_ops = {
 	.read_resources	  = pci_domain_read_resources,
 	.set_resources	  = pci_domain_set_resources,
-	.enable_resources = enable_childrens_resources,
-	.init		  = 0,
+	.enable_resources = NULL,
+	.init		  = NULL,
 	.scan_bus	  = pci_domain_scan_bus,
 };
 

Modified: trunk/src/northbridge/via/vt8601/northbridge.c
==============================================================================
--- trunk/src/northbridge/via/vt8601/northbridge.c	Thu Jun 17 00:21:19 2010	(r5632)
+++ trunk/src/northbridge/via/vt8601/northbridge.c	Thu Jun 17 18:16:56 2010	(r5633)
@@ -146,8 +146,8 @@
 static struct device_operations pci_domain_ops = {
         .read_resources   = pci_domain_read_resources,
         .set_resources    = pci_domain_set_resources,
-        .enable_resources = enable_childrens_resources,
-        .init             = 0,
+        .enable_resources = NULL,
+        .init             = NULL,
         .scan_bus         = pci_domain_scan_bus,
 };
 

Modified: trunk/src/northbridge/via/vt8623/northbridge.c
==============================================================================
--- trunk/src/northbridge/via/vt8623/northbridge.c	Thu Jun 17 00:21:19 2010	(r5632)
+++ trunk/src/northbridge/via/vt8623/northbridge.c	Thu Jun 17 18:16:56 2010	(r5633)
@@ -207,8 +207,8 @@
 static struct device_operations pci_domain_ops = {
         .read_resources   = pci_domain_read_resources,
         .set_resources    = pci_domain_set_resources,
-        .enable_resources = enable_childrens_resources,
-        .init             = 0,
+        .enable_resources = NULL,
+        .init             = NULL,
         .scan_bus         = pci_domain_scan_bus,
 };
 

Modified: trunk/src/northbridge/via/vx800/northbridge.c
==============================================================================
--- trunk/src/northbridge/via/vx800/northbridge.c	Thu Jun 17 00:21:19 2010	(r5632)
+++ trunk/src/northbridge/via/vx800/northbridge.c	Thu Jun 17 18:16:56 2010	(r5633)
@@ -181,8 +181,8 @@
 static struct device_operations pci_domain_ops = {
 	.read_resources = pci_domain_read_resources,
 	.set_resources = pci_domain_set_resources,
-	.enable_resources = enable_childrens_resources,
-	.init = 0,
+	.enable_resources = NULL,
+	.init = NULL,
 	.scan_bus = pci_domain_scan_bus,
 };
 

Modified: trunk/src/northbridge/via/vx800/vx800_lpc.c
==============================================================================
--- trunk/src/northbridge/via/vx800/vx800_lpc.c	Thu Jun 17 00:21:19 2010	(r5632)
+++ trunk/src/northbridge/via/vx800/vx800_lpc.c	Thu Jun 17 18:16:56 2010	(r5633)
@@ -322,16 +322,6 @@
 	pci_dev_set_resources(dev);
 }
 
-static void vx800_enable_resources(device_t dev)
-{
-	/* vx800 is not a pci bridge and has no resources of its own (other than
-	   standard PC i/o addresses). however it does control the isa bus and so
-	   we need to manually call enable childrens resources on that bus */
-	/* TODO: do we even care about ISA? If so, for what? SuperIO on LPC bus */
-	pci_dev_enable_resources(dev);
-	enable_childrens_resources(dev);
-}
-
 static void southbridge_init(struct device *dev)
 {
 	printk(BIOS_DEBUG, "vx800 sb init\n");
@@ -375,8 +365,8 @@
 static struct device_operations vx800_lpc_ops = {
 	.read_resources = vx800_read_resources,
 	.set_resources = vx800_set_resources,
-	.enable_resources = vx800_enable_resources,
-	.init = &southbridge_init,
+	.enable_resources = pci_dev_enable_resources,
+	.init = southbridge_init,
 	.scan_bus = scan_static_bus,
 };
 

Modified: trunk/src/southbridge/amd/amd8111/amd8111_lpc.c
==============================================================================
--- trunk/src/southbridge/amd/amd8111/amd8111_lpc.c	Thu Jun 17 00:21:19 2010	(r5632)
+++ trunk/src/southbridge/amd/amd8111/amd8111_lpc.c	Thu Jun 17 18:16:56 2010	(r5633)
@@ -106,12 +106,6 @@
 	res->flags = IORESOURCE_MEM | IORESOURCE_ASSIGNED | IORESOURCE_FIXED;
 }
 
-static void amd8111_lpc_enable_resources(device_t dev)
-{
-	pci_dev_enable_resources(dev);
-	enable_childrens_resources(dev);
-}
-
 static void lpci_set_subsystem(device_t dev, unsigned vendor, unsigned device)
 {
 	pci_write_config32(dev, 0x70,
@@ -125,7 +119,7 @@
 static struct device_operations lpc_ops  = {
 	.read_resources   = amd8111_lpc_read_resources,
 	.set_resources    = pci_dev_set_resources,
-	.enable_resources = amd8111_lpc_enable_resources,
+	.enable_resources = pci_dev_enable_resources,
 	.init             = lpc_init,
 	.scan_bus         = scan_static_bus,
 	.enable           = amd8111_enable,

Modified: trunk/src/southbridge/amd/cs5530/cs5530_isa.c
==============================================================================
--- trunk/src/southbridge/amd/cs5530/cs5530_isa.c	Thu Jun 17 00:21:19 2010	(r5632)
+++ trunk/src/southbridge/amd/cs5530/cs5530_isa.c	Thu Jun 17 18:16:56 2010	(r5633)
@@ -47,17 +47,10 @@
 {
 }
 
-static void cs5530_pci_dev_enable_resources(device_t dev)
-{
-	// TODO: Needed?
-	pci_dev_enable_resources(dev);
-	enable_childrens_resources(dev);
-}
-
 static struct device_operations isa_ops = {
 	.read_resources		= cs5530_read_resources,
 	.set_resources		= pci_dev_set_resources,
-	.enable_resources	= cs5530_pci_dev_enable_resources,
+	.enable_resources	= pci_dev_enable_resources,
 	.init			= isa_init,
 	.enable			= 0,
 	.scan_bus		= scan_static_bus,

Modified: trunk/src/southbridge/amd/cs5535/cs5535.c
==============================================================================
--- trunk/src/southbridge/amd/cs5535/cs5535.c	Thu Jun 17 00:21:19 2010	(r5632)
+++ trunk/src/southbridge/amd/cs5535/cs5535.c	Thu Jun 17 18:16:56 2010	(r5633)
@@ -87,17 +87,10 @@
 	res->flags = IORESOURCE_MEM | IORESOURCE_ASSIGNED | IORESOURCE_FIXED;
 }
 
-static void cs5535_pci_dev_enable_resources(device_t dev)
-{
-	printk(BIOS_DEBUG, "%s()\n", __func__);
-	pci_dev_enable_resources(dev);
-	enable_childrens_resources(dev);
-}
-
 static struct device_operations southbridge_ops = {
 	.read_resources   = cs5535_read_resources,
 	.set_resources    = pci_dev_set_resources,
-	.enable_resources = cs5535_pci_dev_enable_resources,
+	.enable_resources = pci_dev_enable_resources,
 	.init             = southbridge_init,
 	.enable           = southbridge_enable,
 	.scan_bus         = scan_static_bus,

Modified: trunk/src/southbridge/amd/cs5536/cs5536.c
==============================================================================
--- trunk/src/southbridge/amd/cs5536/cs5536.c	Thu Jun 17 00:21:19 2010	(r5632)
+++ trunk/src/southbridge/amd/cs5536/cs5536.c	Thu Jun 17 18:16:56 2010	(r5633)
@@ -667,17 +667,10 @@
 
 }
 
-static void cs5536_pci_dev_enable_resources(device_t dev)
-{
-	printk(BIOS_DEBUG, "%s()\n", __func__);
-	pci_dev_enable_resources(dev);
-	enable_childrens_resources(dev);
-}
-
 static struct device_operations southbridge_ops = {
 	.read_resources = cs5536_read_resources,
 	.set_resources = pci_dev_set_resources,
-	.enable_resources = cs5536_pci_dev_enable_resources,
+	.enable_resources = pci_dev_enable_resources,
 	.init = southbridge_init,
 //      .enable                   = southbridge_enable,
 	.scan_bus = scan_static_bus,

Modified: trunk/src/southbridge/amd/sb600/sb600_lpc.c
==============================================================================
--- trunk/src/southbridge/amd/sb600/sb600_lpc.c	Thu Jun 17 00:21:19 2010	(r5632)
+++ trunk/src/southbridge/amd/sb600/sb600_lpc.c	Thu Jun 17 18:16:56 2010	(r5633)
@@ -96,13 +96,6 @@
  *
  * @param dev the device whos children's resources are to be enabled
  *
- * This function is call by the global enable_resources() indirectly via the
- * device_operation::enable_resources() method of devices.
- *
- * Indirect mutual recursion:
- *      enable_childrens_resources() -> enable_resources()
- *      enable_resources() -> device_operation::enable_resources()
- *      device_operation::enable_resources() -> enable_children_resources()
  */
 static void sb600_lpc_enable_childrens_resources(device_t dev)
 {
@@ -118,7 +111,6 @@
 		device_t child;
 		for (child = link->children; child;
 		     child = child->sibling) {
-			enable_resources(child);
 			if (child->enabled
 			    && (child->path.type == DEVICE_PATH_PNP)) {
 				struct resource *res;

Modified: trunk/src/southbridge/amd/sb700/sb700_lpc.c
==============================================================================
--- trunk/src/southbridge/amd/sb700/sb700_lpc.c	Thu Jun 17 00:21:19 2010	(r5632)
+++ trunk/src/southbridge/amd/sb700/sb700_lpc.c	Thu Jun 17 18:16:56 2010	(r5633)
@@ -108,13 +108,6 @@
  *
  * @param dev the device whos children's resources are to be enabled
  *
- * This function is call by the global enable_resources() indirectly via the
- * device_operation::enable_resources() method of devices.
- *
- * Indirect mutual recursion:
- *      enable_childrens_resources() -> enable_resources()
- *      enable_resources() -> device_operation::enable_resources()
- *      device_operation::enable_resources() -> enable_children_resources()
  */
 static void sb700_lpc_enable_childrens_resources(device_t dev)
 {
@@ -130,7 +123,6 @@
 		device_t child;
 		for (child = link->children; child;
 		     child = child->sibling) {
-			enable_resources(child);
 			if (child->enabled
 			    && (child->path.type == DEVICE_PATH_PNP)) {
 				struct resource *res;

Modified: trunk/src/southbridge/broadcom/bcm5785/bcm5785_lpc.c
==============================================================================
--- trunk/src/southbridge/broadcom/bcm5785/bcm5785_lpc.c	Thu Jun 17 00:21:19 2010	(r5632)
+++ trunk/src/southbridge/broadcom/bcm5785/bcm5785_lpc.c	Thu Jun 17 18:16:56 2010	(r5633)
@@ -57,13 +57,6 @@
  *
  * @param dev the device whos children's resources are to be enabled
  *
- * This function is call by the global enable_resources() indirectly via the
- * device_operation::enable_resources() method of devices.
- *
- * Indirect mutual recursion:
- *      enable_childrens_resources() -> enable_resources()
- *      enable_resources() -> device_operation::enable_resources()
- *      device_operation::enable_resources() -> enable_children_resources()
  */
 static void bcm5785_lpc_enable_childrens_resources(device_t dev)
 {
@@ -75,7 +68,6 @@
 	for (link = dev->link_list; link; link = link->next) {
                 device_t child;
                 for (child = link->children; child; child = child->sibling) {
-                        enable_resources(child);
 			if(child->enabled && (child->path.type == DEVICE_PATH_PNP)) {
 				struct resource *res;
 				for(res = child->resource_list; res; res = res->next) {

Modified: trunk/src/southbridge/intel/esb6300/esb6300_lpc.c
==============================================================================
--- trunk/src/southbridge/intel/esb6300/esb6300_lpc.c	Thu Jun 17 00:21:19 2010	(r5632)
+++ trunk/src/southbridge/intel/esb6300/esb6300_lpc.c	Thu Jun 17 18:16:56 2010	(r5633)
@@ -351,8 +351,6 @@
 	gpio_cntl = pci_read_config8(dev, 0x5c);
 	gpio_cntl |= (1 << 4);
 	pci_write_config8(dev, 0x5c, gpio_cntl);
-
-	enable_childrens_resources(dev);
 }
 
 static struct pci_operations lops_pci = {

Modified: trunk/src/southbridge/intel/i3100/i3100_lpc.c
==============================================================================
--- trunk/src/southbridge/intel/i3100/i3100_lpc.c	Thu Jun 17 00:21:19 2010	(r5632)
+++ trunk/src/southbridge/intel/i3100/i3100_lpc.c	Thu Jun 17 18:16:56 2010	(r5633)
@@ -404,8 +404,6 @@
 
 	/* Enable the RCBA */
 	pci_write_config32(dev, RCBA, pci_read_config32(dev, RCBA) | (1 << 0));
-
-	enable_childrens_resources(dev);
 }
 
 static struct pci_operations lops_pci = {

Modified: trunk/src/southbridge/intel/i82801ax/i82801ax_lpc.c
==============================================================================
--- trunk/src/southbridge/intel/i82801ax/i82801ax_lpc.c	Thu Jun 17 00:21:19 2010	(r5632)
+++ trunk/src/southbridge/intel/i82801ax/i82801ax_lpc.c	Thu Jun 17 18:16:56 2010	(r5633)
@@ -332,16 +332,10 @@
 	res->flags = IORESOURCE_MEM | IORESOURCE_ASSIGNED | IORESOURCE_FIXED;
 }
 
-static void i82801ax_lpc_enable_resources(device_t dev)
-{
-	pci_dev_enable_resources(dev);
-	enable_childrens_resources(dev);
-}
-
 static struct device_operations lpc_ops = {
 	.read_resources		= i82801ax_lpc_read_resources,
 	.set_resources		= pci_dev_set_resources,
-	.enable_resources	= i82801ax_lpc_enable_resources,
+	.enable_resources	= pci_dev_enable_resources,
 	.init			= lpc_init,
 	.scan_bus		= scan_static_bus,
 	.enable			= i82801ax_enable,

Modified: trunk/src/southbridge/intel/i82801bx/i82801bx_lpc.c
==============================================================================
--- trunk/src/southbridge/intel/i82801bx/i82801bx_lpc.c	Thu Jun 17 00:21:19 2010	(r5632)
+++ trunk/src/southbridge/intel/i82801bx/i82801bx_lpc.c	Thu Jun 17 18:16:56 2010	(r5633)
@@ -332,16 +332,10 @@
 	res->flags = IORESOURCE_MEM | IORESOURCE_ASSIGNED | IORESOURCE_FIXED;
 }
 
-static void i82801bx_lpc_enable_resources(device_t dev)
-{
-	pci_dev_enable_resources(dev);
-	enable_childrens_resources(dev);
-}
-
 static struct device_operations lpc_ops = {
 	.read_resources		= i82801bx_lpc_read_resources,
 	.set_resources		= pci_dev_set_resources,
-	.enable_resources	= i82801bx_lpc_enable_resources,
+	.enable_resources	= pci_dev_enable_resources,
 	.init			= lpc_init,
 	.scan_bus		= scan_static_bus,
 	.enable			= i82801bx_enable,

Modified: trunk/src/southbridge/intel/i82801cx/i82801cx_lpc.c
==============================================================================
--- trunk/src/southbridge/intel/i82801cx/i82801cx_lpc.c	Thu Jun 17 00:21:19 2010	(r5632)
+++ trunk/src/southbridge/intel/i82801cx/i82801cx_lpc.c	Thu Jun 17 18:16:56 2010	(r5633)
@@ -229,16 +229,10 @@
 	res->flags = IORESOURCE_MEM | IORESOURCE_ASSIGNED | IORESOURCE_FIXED;
 }
 
-static void i82801cx_lpc_enable_resources(device_t dev)
-{
-	pci_dev_enable_resources(dev);
-	enable_childrens_resources(dev);
-}
-
 static struct device_operations lpc_ops  = {
 	.read_resources   = i82801cx_lpc_read_resources,
 	.set_resources    = pci_dev_set_resources,
-	.enable_resources = i82801cx_lpc_enable_resources,
+	.enable_resources = pci_dev_enable_resources,
 	.init             = lpc_init,
 	.scan_bus         = scan_static_bus,
 	.enable           = 0,

Modified: trunk/src/southbridge/intel/i82801dx/i82801dx_lpc.c
==============================================================================
--- trunk/src/southbridge/intel/i82801dx/i82801dx_lpc.c	Thu Jun 17 00:21:19 2010	(r5632)
+++ trunk/src/southbridge/intel/i82801dx/i82801dx_lpc.c	Thu Jun 17 18:16:56 2010	(r5633)
@@ -322,16 +322,10 @@
 	res->flags = IORESOURCE_MEM | IORESOURCE_ASSIGNED | IORESOURCE_FIXED;
 }
 
-static void i82801dx_lpc_enable_resources(device_t dev)
-{
-	pci_dev_enable_resources(dev);
-	enable_childrens_resources(dev);
-}
-
 static struct device_operations lpc_ops = {
 	.read_resources		= i82801dx_lpc_read_resources,
 	.set_resources		= pci_dev_set_resources,
-	.enable_resources	= i82801dx_lpc_enable_resources,
+	.enable_resources	= pci_dev_enable_resources,
 	.init			= lpc_init,
 	.scan_bus		= scan_static_bus,
 	.enable			= i82801dx_enable,

Modified: trunk/src/southbridge/intel/i82801ex/i82801ex_lpc.c
==============================================================================
--- trunk/src/southbridge/intel/i82801ex/i82801ex_lpc.c	Thu Jun 17 00:21:19 2010	(r5632)
+++ trunk/src/southbridge/intel/i82801ex/i82801ex_lpc.c	Thu Jun 17 18:16:56 2010	(r5633)
@@ -335,8 +335,6 @@
 	gpio_cntl = pci_read_config8(dev, 0x5c);
 	gpio_cntl |= (1 << 4);
 	pci_write_config8(dev, 0x5c, gpio_cntl);
-
-	enable_childrens_resources(dev);
 }
 
 static struct pci_operations lops_pci = {

Modified: trunk/src/southbridge/intel/i82801gx/i82801gx_lpc.c
==============================================================================
--- trunk/src/southbridge/intel/i82801gx/i82801gx_lpc.c	Thu Jun 17 00:21:19 2010	(r5632)
+++ trunk/src/southbridge/intel/i82801gx/i82801gx_lpc.c	Thu Jun 17 18:16:56 2010	(r5633)
@@ -481,12 +481,6 @@
 	res->flags = IORESOURCE_MEM | IORESOURCE_ASSIGNED | IORESOURCE_FIXED;
 }
 
-static void i82801gx_lpc_enable_resources(device_t dev)
-{
-	pci_dev_enable_resources(dev);
-	enable_childrens_resources(dev);
-}
-
 static void set_subsystem(device_t dev, unsigned vendor, unsigned device)
 {
 	if (!vendor || !device) {
@@ -505,7 +499,7 @@
 static struct device_operations device_ops = {
 	.read_resources		= i82801gx_lpc_read_resources,
 	.set_resources		= pci_dev_set_resources,
-	.enable_resources	= i82801gx_lpc_enable_resources,
+	.enable_resources	= pci_dev_enable_resources,
 	.init			= lpc_init,
 	.scan_bus		= scan_static_bus,
 	.enable			= i82801gx_enable,

Modified: trunk/src/southbridge/intel/i82801gx/i82801gx_pci.c
==============================================================================
--- trunk/src/southbridge/intel/i82801gx/i82801gx_pci.c	Thu Jun 17 00:21:19 2010	(r5632)
+++ trunk/src/southbridge/intel/i82801gx/i82801gx_pci.c	Thu Jun 17 18:16:56 2010	(r5633)
@@ -110,8 +110,6 @@
 
 	/* This is the reason we need our own pci_bus_enable_resources */
 	ich_pci_dev_enable_resources(dev);
-
-	enable_childrens_resources(dev);
 }
 
 static void set_subsystem(device_t dev, unsigned vendor, unsigned device)

Modified: trunk/src/southbridge/nvidia/ck804/ck804_lpc.c
==============================================================================
--- trunk/src/southbridge/nvidia/ck804/ck804_lpc.c	Thu Jun 17 00:21:19 2010	(r5632)
+++ trunk/src/southbridge/nvidia/ck804/ck804_lpc.c	Thu Jun 17 18:16:56 2010	(r5633)
@@ -222,12 +222,6 @@
  * This function is called by the global enable_resources() indirectly via the
  * device_operation::enable_resources() method of devices.
  *
- * Indirect mutual recursion:
- *      enable_childrens_resources() -> enable_resources()
- *      enable_resources() -> device_operation::enable_resources()
- *      device_operation::enable_resources() -> enable_children_resources()
- *
- * @param dev The device whose children's resources are to be enabled.
  */
 static void ck804_lpc_enable_childrens_resources(device_t dev)
 {
@@ -240,7 +234,6 @@
 	for (link = dev->link_list; link; link = link->next) {
 		device_t child;
 		for (child = link->children; child; child = child->sibling) {
-			enable_resources(child);
 			if (child->enabled && (child->path.type == DEVICE_PATH_PNP)) {
 				struct resource *res;
 				for (res = child->resource_list; res; res = res->next) {

Modified: trunk/src/southbridge/nvidia/mcp55/mcp55_lpc.c
==============================================================================
--- trunk/src/southbridge/nvidia/mcp55/mcp55_lpc.c	Thu Jun 17 00:21:19 2010	(r5632)
+++ trunk/src/southbridge/nvidia/mcp55/mcp55_lpc.c	Thu Jun 17 18:16:56 2010	(r5633)
@@ -195,13 +195,6 @@
  *
  * @param dev the device whos children's resources are to be enabled
  *
- * This function is called by the global enable_resources() indirectly via the
- * device_operation::enable_resources() method of devices.
- *
- * Indirect mutual recursion:
- *      enable_childrens_resources() -> enable_resources()
- *      enable_resources() -> device_operation::enable_resources()
- *      device_operation::enable_resources() -> enable_children_resources()
  */
 static void mcp55_lpc_enable_childrens_resources(device_t dev)
 {
@@ -215,7 +208,6 @@
 	for (link = dev->link_list; link; link = link->next) {
 		device_t child;
 		for (child = link->children; child; child = child->sibling) {
-			enable_resources(child);
 			if(child->enabled && (child->path.type == DEVICE_PATH_PNP)) {
 				struct resource *res;
 				for(res = child->resource_list; res; res = res->next) {

Modified: trunk/src/southbridge/sis/sis966/sis966_lpc.c
==============================================================================
--- trunk/src/southbridge/sis/sis966/sis966_lpc.c	Thu Jun 17 00:21:19 2010	(r5632)
+++ trunk/src/southbridge/sis/sis966/sis966_lpc.c	Thu Jun 17 18:16:56 2010	(r5633)
@@ -188,13 +188,6 @@
  *
  * @param dev the device whos children's resources are to be enabled
  *
- * This function is call by the global enable_resources() indirectly via the
- * device_operation::enable_resources() method of devices.
- *
- * Indirect mutual recursion:
- *      enable_childrens_resources() -> enable_resources()
- *      enable_resources() -> device_operation::enable_resources()
- *      device_operation::enable_resources() -> enable_children_resources()
  */
 static void sis966_lpc_enable_childrens_resources(device_t dev)
 {
@@ -208,7 +201,6 @@
 	for (link = dev->link_list; link; link = link->next) {
 		device_t child;
 		for (child = link->children; child; child = child->sibling) {
-			enable_resources(child);
 			if(child->enabled && (child->path.type == DEVICE_PATH_PNP)) {
 				struct resource *res;
 				for(res = child->resource_list; res; res = res->next) {

Modified: trunk/src/southbridge/via/vt8235/vt8235_lpc.c
==============================================================================
--- trunk/src/southbridge/via/vt8235/vt8235_lpc.c	Thu Jun 17 00:21:19 2010	(r5632)
+++ trunk/src/southbridge/via/vt8235/vt8235_lpc.c	Thu Jun 17 18:16:56 2010	(r5633)
@@ -241,14 +241,6 @@
 	pci_dev_set_resources(dev);
 }
 
-static void vt8235_enable_resources(device_t dev)
-{
-	/* vt8235 is not a pci bridge and has no resources of its own (other than standard PC i/o addresses)
-           however it does control the isa bus and so we need to manually call enable childrens resources on that bus */
-	pci_dev_enable_resources(dev);
-	enable_childrens_resources(dev);
-}
-
 static void southbridge_init(struct device *dev)
 {
 	vt8235_init(dev);
@@ -258,8 +250,8 @@
 static struct device_operations vt8235_lpc_ops = {
 	.read_resources   = vt8235_read_resources,
 	.set_resources    = vt8235_set_resources,
-	.enable_resources = vt8235_enable_resources,
-	.init             = &southbridge_init,
+	.enable_resources = pci_dev_enable_resources,
+	.init             = southbridge_init,
 	.scan_bus         = scan_static_bus,
 };
 

Modified: trunk/src/southbridge/via/vt8237r/vt8237r_lpc.c
==============================================================================
--- trunk/src/southbridge/via/vt8237r/vt8237r_lpc.c	Thu Jun 17 00:21:19 2010	(r5632)
+++ trunk/src/southbridge/via/vt8237r/vt8237r_lpc.c	Thu Jun 17 18:16:56 2010	(r5633)
@@ -505,17 +505,6 @@
 	res->flags = IORESOURCE_IO | IORESOURCE_ASSIGNED | IORESOURCE_FIXED;
 }
 
-/**
- * The VT8237R is not a PCI bridge and has no resources of its own (other
- * than standard PC I/O addresses), however it does control the ISA bus
- * and so we need to manually call enable childrens resources on that bus.
- */
-static void vt8237r_enable_resources(device_t dev)
-{
-	pci_dev_enable_resources(dev);
-	enable_childrens_resources(dev);
-}
-
 static void init_keyboard(struct device *dev)
 {
 	u8 regval = pci_read_config8(dev, 0x51);
@@ -535,16 +524,16 @@
 static const struct device_operations vt8237r_lpc_ops_s = {
 	.read_resources		= vt8237r_read_resources,
 	.set_resources		= pci_dev_set_resources,
-	.enable_resources	= vt8237r_enable_resources,
-	.init			= &vt8237s_init,
+	.enable_resources	= pci_dev_enable_resources,
+	.init			= vt8237s_init,
 	.scan_bus		= scan_static_bus,
 };
 
 static const struct device_operations vt8237r_lpc_ops_r = {
 	.read_resources		= vt8237r_read_resources,
 	.set_resources		= pci_dev_set_resources,
-	.enable_resources	= vt8237r_enable_resources,
-	.init			= &vt8237r_init,
+	.enable_resources	= pci_dev_enable_resources,
+	.init			= vt8237r_init,
 	.scan_bus		= scan_static_bus,
 };
 



From mylesgw at gmail.com  Thu Jun 17 18:19:03 2010
From: mylesgw at gmail.com (Myles Watson)
Date: Thu, 17 Jun 2010 10:19:03 -0600
Subject: [coreboot] [PATCH] Simplify device enabling and initialization
In-Reply-To: <20100617080408.25711.qmail@stuge.se>
References: <AANLkTingtsR4xtaPMENTl3bk5tOWM1hMqR2t9w8Ep3vR@mail.gmail.com>
	<20100617080408.25711.qmail@stuge.se>
Message-ID: <AANLkTikLwqenXGmG51HkOEOT9LmfUEl9jKawTg36ha2h@mail.gmail.com>

On Thu, Jun 17, 2010 at 2:04 AM, Peter Stuge <peter at stuge.se> wrote:
> Myles Watson wrote:
>> If we initialize and enable devices in the order that they are found
>> in the tree, instead of the order that they were added to the list, it
>> simplifies the code. ?It also makes it so that removing a device from
>> the devicetree.cb file won't change when its resources are enabled.
> ..
>> Signed-off-by: Myles Watson <mylesgw at gmail.com>
>
> Acked-by: Peter Stuge <peter at stuge.se>
Rev 5633.

I copied the s2881 code into a driver stub, since Ward said he's
willing to test.

>> This patch breaks the s2881, which was doing some odd acrobatics in
>> order to get a device initialized after its parent.
>
> If neccessary then I would be in favor of mainboard-specific hooks
> from coreboot, that are separate from the device tree. But maybe the
> init for s2881 can be done using a coreboot "driver" ?
That could work.  I think it might get abused, though.

Thanks,
Myles



From mylesgw at gmail.com  Thu Jun 17 18:50:08 2010
From: mylesgw at gmail.com (Myles Watson)
Date: Thu, 17 Jun 2010 10:50:08 -0600
Subject: [coreboot] Strange ROMCC failure with Rev 5623
In-Reply-To: <4C1A4A1E.7050203@coresystems.de>
References: <AANLkTikgYCZFdyizSDn-4GB14HSO5RhAMsuFHZI_bvls@mail.gmail.com>
	<AANLkTinHo_Jak42t3kroe7ePuL77KfogqrhQpxIfAaBO@mail.gmail.com>
	<AANLkTikeZHCMwwWm6k2bTTujJ93tEPeChXhRpwvVjYtJ@mail.gmail.com>
	<AANLkTin1AzYcUWEm8imxBqjg9Vrhxwqz0lFCODmPFHyF@mail.gmail.com>
	<m1iq5isd8t.fsf@fess.ebiederm.org>
	<AANLkTimwcqevmGFO5IWY9sYO_dGirYrNKgGr_Oexah40@mail.gmail.com>
	<4C1A4A1E.7050203@coresystems.de>
Message-ID: <AANLkTilsWjH7IRNhIybd3l_yHaixEJRxUeX5hnV78g1p@mail.gmail.com>

On Thu, Jun 17, 2010 at 10:15 AM, Stefan Reinauer <stepan at coresystems.de> wrote:
> On 6/17/10 5:12 PM, Myles Watson wrote:
>>>> It looks like Patrick found this before:
>>>> http://www.coreboot.org/pipermail/coreboot/2009-November/054387.html
>>>>
>>>> If I take out the free it works fine. ?It seems like there must be a better fix.
>>>>
>>> Agreed.
>>>
>>> I took a look at this a little bit with Stefan and he helped me track where
>>> the double free is.
>>>
>>> The routine doing the freeing badly needs to be rewritten to use simpler logic
>>> as the recursive logic it is using now just doesn't work, and it winds
>>> up to be a bit of a crap shoot if your compile gets killed by this or not.
>>>
>> What if we just agree that host machines have a lot of RAM, romcc is
>> not a long-running program, and life will be easier if nothing gets
>> freed.
>>
> Then we should also switch to Visual C++ in order to stay compliant. ;-)
Point taken :)

Myles



From mylesgw at gmail.com  Thu Jun 17 18:40:12 2010
From: mylesgw at gmail.com (Myles Watson)
Date: Thu, 17 Jun 2010 10:40:12 -0600
Subject: [coreboot] [PATCH] Simplify device enabling and initialization
In-Reply-To: <20100617002237.GA2700@countzero.vandewege.net>
References: <AANLkTingtsR4xtaPMENTl3bk5tOWM1hMqR2t9w8Ep3vR@mail.gmail.com>
	<20100617002237.GA2700@countzero.vandewege.net>
Message-ID: <AANLkTimDkFfjpRr1ZZCG0yDjGuVtwZweyYzrhzoxiOy0@mail.gmail.com>

On Wed, Jun 16, 2010 at 6:22 PM, Ward Vandewege <ward at gnu.org> wrote:
> On Wed, Jun 16, 2010 at 02:50:42PM -0600, Myles Watson wrote:
>> This patch breaks the s2881, which was doing some odd acrobatics in
>> order to get a device initialized after its parent. ?It should be an
>> easy fix to do it correctly now, but I don't have an s2881 to test on.
>> ?Ward?
>
> Yep, I've got (the guts) of an s2881 lying on my desk here, and can test any
> patches you throw at me :)

Great.  Here are two patches.

The first one enables the driver exactly like it was before, only as a driver.

The second one tries to make it less board specific.  Putting the fan
settings in the device tree would complete that effort, I think.

Suggestions welcome.  Thanks for testing!

Signed-off-by: Myles Watson <mylesgw at gmail.com>

Thanks,
Myles
-------------- next part --------------
A non-text attachment was scrubbed...
Name: s2881.diff
Type: text/x-diff
Size: 2122 bytes
Desc: not available
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20100617/983c7908/attachment.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: s2881_2.diff
Type: text/x-diff
Size: 3529 bytes
Desc: not available
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20100617/983c7908/attachment-0001.bin>

From jwangzju at gmail.com  Thu Jun 17 18:58:10 2010
From: jwangzju at gmail.com (Jiang Wang)
Date: Thu, 17 Jun 2010 12:58:10 -0400
Subject: [coreboot] Has anyone tested Windows Server 2008 with Hyper-V on
	coreboot(SeaBIOS)
Message-ID: <AANLkTilTq8qstwHCMBzANV0XAtTIw11JqSt84hanH3Bi@mail.gmail.com>

Hi:

I want to install Win 2008 server with Hyper-V (64bit OS and requires
VT or AMD-V) on a coreboot based mainboard. I found following link :
http://www.coreboot.org/SeaBIOS#Windows
It only mentioned client version of WINDOWS (xp, vista, 7). Has anyone
tested the server versions and Hyper-V? Thanks.

Regards,

Jiang



From anders at jenbo.dk  Thu Jun 17 22:07:04 2010
From: anders at jenbo.dk (Anders Jenbo)
Date: Thu, 17 Jun 2010 22:07:04 +0200
Subject: [coreboot] request for comments: Gigabyte GA-945PL-S3 (rev. 1.0)
In-Reply-To: <4C192D62.7030706@gmx.de>
References: <4C192D62.7030706@gmx.de>
Message-ID: <1276805224.1275.28.camel@anders-laptop>

Hi John

All your chips seams to be supported so getting your board working
shouldn't be to hard.

As fare as i can see on flashrom.org, the status for writing to "SST
SST25VF040.REMS" is just unknown, if it really doesn't work, then
another option might be to find a compatible chip that is supported for
write. In any case you will probably need to desolder it so that you can
switch back to the original in case your port doesn't work in the first
attempt (likely).

I sugest that you copy the code for Kontron 986LCD-M/mITX, as it seams
the closes working match. You might also take a peak at Tyan Tiger K8W
(S2875) as it uses the same SuperIO as your board.

-Anders




From peter at stuge.se  Thu Jun 17 22:14:19 2010
From: peter at stuge.se (Peter Stuge)
Date: Thu, 17 Jun 2010 22:14:19 +0200
Subject: [coreboot] Strange ROMCC failure with Rev 5623
In-Reply-To: <4C1A4A1E.7050203@coresystems.de>
	<AANLkTinmRCiu7RHimubMZvuPQh8PJ16i2uyXnbDk-A3l@mail.gmail.com>
References: <m1iq5isd8t.fsf@fess.ebiederm.org>
	<AANLkTimwcqevmGFO5IWY9sYO_dGirYrNKgGr_Oexah40@mail.gmail.com>
	<4C1A4A1E.7050203@coresystems.de>
	<AANLkTikgYCZFdyizSDn-4GB14HSO5RhAMsuFHZI_bvls@mail.gmail.com>
	<AANLkTinHo_Jak42t3kroe7ePuL77KfogqrhQpxIfAaBO@mail.gmail.com>
	<AANLkTikeZHCMwwWm6k2bTTujJ93tEPeChXhRpwvVjYtJ@mail.gmail.com>
	<AANLkTin1AzYcUWEm8imxBqjg9Vrhxwqz0lFCODmPFHyF@mail.gmail.com>
	<m1iq5isd8t.fsf@fess.ebiederm.org>
	<AANLkTimwcqevmGFO5IWY9sYO_dGirYrNKgGr_Oexah40@mail.gmail.com>
	<AANLkTinmRCiu7RHimubMZvuPQh8PJ16i2uyXnbDk-A3l@mail.gmail.com>
Message-ID: <20100617201419.28984.qmail@stuge.se>

ron minnich wrote:
> > What if we just agree that host machines have a lot of RAM, romcc is
> > not a long-running program, and life will be easier if nothing gets
> > freed.
> > How much RAM are we talking about?
> 
> Reasonable. You could at least try it. Use LD_PRELOAD and make free()
> a no-op :-)

Yes, I would be interested in how much RAM is being used.


> (you'd be surprised how often I have to point out to people that
> doing lots of work to free memory before calling exit() has no
> effect on the system free memory -- "You mean the system can
> somehow free the process memory when the process exits?" -- I'm
> not kidding!)

It's lovely. I worked on a project where the application implemented
it's own memory allocator. When starting, the program would allocate
*all* available memory in the system, and then split that up into
small parts as the program progressed. The boss was convinced that
the operating system could not be trusted to do memory management.
They're still in business, I expect still running the same code.


Stefan Reinauer wrote:
> > What if we just agree that host machines have a lot of RAM, romcc is
> > not a long-running program, and life will be easier if nothing gets
> > freed.
> 
> Then we should also switch to Visual C++ in order to stay compliant. ;-)

He-he.. But depending on the resource use I would be okey with making
an exception for romcc.


//Peter



From anders at jenbo.dk  Thu Jun 17 23:00:46 2010
From: anders at jenbo.dk (Anders Jenbo)
Date: Thu, 17 Jun 2010 23:00:46 +0200
Subject: [coreboot] Strange ROMCC failure with Rev 5623
In-Reply-To: <20100617201419.28984.qmail@stuge.se>
References: <m1iq5isd8t.fsf@fess.ebiederm.org>
	<AANLkTimwcqevmGFO5IWY9sYO_dGirYrNKgGr_Oexah40@mail.gmail.com>
	<4C1A4A1E.7050203@coresystems.de>
	<AANLkTikgYCZFdyizSDn-4GB14HSO5RhAMsuFHZI_bvls@mail.gmail.com>
	<AANLkTinHo_Jak42t3kroe7ePuL77KfogqrhQpxIfAaBO@mail.gmail.com>
	<AANLkTikeZHCMwwWm6k2bTTujJ93tEPeChXhRpwvVjYtJ@mail.gmail.com>
	<AANLkTin1AzYcUWEm8imxBqjg9Vrhxwqz0lFCODmPFHyF@mail.gmail.com>
	<m1iq5isd8t.fsf@fess.ebiederm.org>
	<AANLkTimwcqevmGFO5IWY9sYO_dGirYrNKgGr_Oexah40@mail.gmail.com>
	<AANLkTinmRCiu7RHimubMZvuPQh8PJ16i2uyXnbDk-A3l@mail.gmail.com>
	<20100617201419.28984.qmail@stuge.se>
Message-ID: <1276808446.1275.30.camel@anders-laptop>

tor, 17 06 2010 kl. 22:14 +0200, skrev Peter Stuge:
> ron minnich wrote:
> > > What if we just agree that host machines have a lot of RAM, romcc is
> > > not a long-running program, and life will be easier if nothing gets
> > > freed.
> > > How much RAM are we talking about?
> > 
> > Reasonable. You could at least try it. Use LD_PRELOAD and make free()
> > a no-op :-)
> 
> Yes, I would be interested in how much RAM is being used.
> 
> 
> > (you'd be surprised how often I have to point out to people that
> > doing lots of work to free memory before calling exit() has no
> > effect on the system free memory -- "You mean the system can
> > somehow free the process memory when the process exits?" -- I'm
> > not kidding!)
> 
> It's lovely. I worked on a project where the application implemented
> it's own memory allocator. When starting, the program would allocate
> *all* available memory in the system, and then split that up into
> small parts as the program progressed. The boss was convinced that
> the operating system could not be trusted to do memory management.
> They're still in business, I expect still running the same code.

They should make there software in to payloads for coreboot ;D

> 
> 
> Stefan Reinauer wrote:
> > > What if we just agree that host machines have a lot of RAM, romcc is
> > > not a long-running program, and life will be easier if nothing gets
> > > freed.
> > 
> > Then we should also switch to Visual C++ in order to stay compliant. ;-)
> 
> He-he.. But depending on the resource use I would be okey with making
> an exception for romcc.
> 
> 
> //Peter
> 





From bari at onelabs.com  Thu Jun 17 22:51:25 2010
From: bari at onelabs.com (bari)
Date: Thu, 17 Jun 2010 15:51:25 -0500
Subject: [coreboot] AMD740G - Not supported yet?
In-Reply-To: <4C19ED74.5040608@gmx.net>
References: <4C197733.6060906@mnsi.net> <4C19E824.1050206@coresystems.de>
	<4C19ED74.5040608@gmx.net>
Message-ID: <4C1A8ACD.8060706@onelabs.com>

There is actually a good comparison of features here of 740 vs 690:

http://en.wikipedia.org/wiki/AMD_700_chipset_series#740G

Try it out and let us know what problems you find. Full specs are 
available for the chipset.

-Bari

Carl-Daniel Hailfinger wrote:
> On 17.06.2010 11:17, Stefan Reinauer wrote:
>> On 6/17/10 3:15 AM, GS Hunt wrote:
>>   
>>> I noticed that there is still a request for AMD740G chipset info almost
>>> a year later after I first posted some info regarding it. Is it in limbo
>>> now?
>>>   
>>>     
>> I doubt anybody was ever working on this. There is, however, support for
>> AMD's RS780 chipset which might be fairly similar, so if you have 740
>> hardware, feel encouraged to let us know how far you get with the RS780
>> code.
>>   
> 
> According to my sources, AMD 740G is basically AMD 690G, but you may
> have to change one or two PCI IDs. That could result in a working
> system. I don't have the hardware, so I'm unable to test.
> 
> Regards,
> Carl-Daniel
> 



From john.wyzer at gmx.de  Fri Jun 18 02:05:39 2010
From: john.wyzer at gmx.de (John Wyzer)
Date: Fri, 18 Jun 2010 02:05:39 +0200
Subject: [coreboot] request for comments: Gigabyte GA-945PL-S3 (rev. 1.0)
In-Reply-To: <1276805224.1275.28.camel@anders-laptop>
References: <4C192D62.7030706@gmx.de> <1276805224.1275.28.camel@anders-laptop>
Message-ID: <4C1AB853.4010107@gmx.de>

On 17/06/10 22:07, Anders Jenbo wrote:
> All your chips seams to be supported so getting your board working
> shouldn't be to hard.
> 
> As fare as i can see on flashrom.org, the status for writing to "SST
> SST25VF040.REMS" is just unknown, if it really doesn't work, then
> another option might be to find a compatible chip that is supported for
> write. In any case you will probably need to desolder it so that you can
> switch back to the original in case your port doesn't work in the first
> attempt (likely).
> 
> I sugest that you copy the code for Kontron 986LCD-M/mITX, as it seams
> the closes working match. You might also take a peak at Tyan Tiger K8W
> (S2875) as it uses the same SuperIO as your board.


Thanks for the reply!
Will do so as soon as other projects are out of the way :-)
Best regards!



From superligen at gmail.com  Fri Jun 18 05:26:20 2010
From: superligen at gmail.com (Li Gen)
Date: Fri, 18 Jun 2010 11:26:20 +0800
Subject: [coreboot] CS5536 write MSR and trigger I/O error
Message-ID: <AANLkTilk6fPi6ZHfcvyCR1jGiaKlnMcey_Sh6ziDQ2MH@mail.gmail.com>

Hi,
  I have a main board with cs5536, and need to write the bios. During
the pci devices scaning, I can found cs5536, and the device number is
9. So I use following codes to read and write MSR to configure CS5536.
However, I found  that I can successfully read the MSR content, but
when I write the same content to the same MSR, the I/O error was
happened after writing the low data to 0xf8.
  Then I try to write the high data first and then write the low
data, I found that writing the high data will not trigger I/O error,
only writing low data will trigger I/O error. Is there something else
I forgot to initialize before writing MSR? and what do I do something
wrong?
Thank you!


#define CS5536_SB_MSR_BASE (0x00000000)

pci_write(CS5536_PCI_CONF_BASE+0xf4, CS5536_SB_MSR_BASE | 0x10) ;  // OK
pci_read(CS5536_PCI_CONF_BASE+0xf8, &low ) ;  // OK low =00000003h
pci_read(CS5536_PCI_CONF_BASE+0xfc, &hi ) ;  // OK hi =  44000030h

pci_write(CS5536_PCI_CONF_BASE+0xf4, CS5536_SB_MSR_BASE | 0x10) ;  // OK
pci_write(CS5536_PCI_CONF_BASE+0xf8, low  ) ; // I/O Error, Why?
pci_write(CS5536_PCI_CONF_BASE+0xfc, hi    ) ;  // I/O Error, Why?


Q: Is there something else I forgot to initialize before writing MSR?
and what do I do something wrong?



From peter at stuge.se  Fri Jun 18 08:08:29 2010
From: peter at stuge.se (Peter Stuge)
Date: Fri, 18 Jun 2010 08:08:29 +0200
Subject: [coreboot] CS5536 write MSR and trigger I/O error
In-Reply-To: <AANLkTilk6fPi6ZHfcvyCR1jGiaKlnMcey_Sh6ziDQ2MH@mail.gmail.com>
References: <AANLkTilk6fPi6ZHfcvyCR1jGiaKlnMcey_Sh6ziDQ2MH@mail.gmail.com>
Message-ID: <20100618060829.15745.qmail@stuge.se>

Hello,

Li Gen wrote:
> I have a main board with cs5536,

Which CPU does it have?


> and need to write the bios.

I would suggest that you use coreboot as firmware. If you require a
legacy BIOS environment then you can use coreboot together with
SeaBIOS. It works very well.


> I use following codes to read and write MSR to configure CS5536.

Reading and writing MSRs must be done with the instructions rdmsr and
wrmsr.


> pci_write(CS5536_PCI_CONF_BASE+0xf4, CS5536_SB_MSR_BASE | 0x10) ;  // OK
> pci_read(CS5536_PCI_CONF_BASE+0xf8, &low ) ;  // OK low =00000003h
> pci_read(CS5536_PCI_CONF_BASE+0xfc, &hi ) ;  // OK hi =  44000030h

Whenever you are accessing PCI config space registers, keep in mind
that each access is always two operations. First write the 32-bit PCI
config space register address to 0xcf8, then read or write 32-bit
data to 0xcfc.


Also note that if you are not using coreboot then you may not get a
lot of help here, since this mailing list is focused on coreboot. :)


//Peter



From svn at coreboot.org  Sat Jun 19 08:55:18 2010
From: svn at coreboot.org (repository service)
Date: Sat, 19 Jun 2010 08:55:18 +0200
Subject: [coreboot] [commit] r5634 - trunk/src/southbridge/amd/sb700
Message-ID: <E1OPrxW-0005Vg-EL@ra.coresystems.de>

Author: zbao
Date: Sat Jun 19 08:55:17 2010
New Revision: 5634
URL: https://tracker.coreboot.org/trac/coreboot/changeset/5634

Log:
Trivial. Cleaning up about the blank line.

Signed-off-by: Zheng Bao <zheng.bao at amd.com>
Acked-by: Zheng Bao <zheng.bao at amd.com>

Modified:
   trunk/src/southbridge/amd/sb700/sb700.c
   trunk/src/southbridge/amd/sb700/sb700_lpc.c
   trunk/src/southbridge/amd/sb700/sb700_sm.c
   trunk/src/southbridge/amd/sb700/sb700_usb.c

Modified: trunk/src/southbridge/amd/sb700/sb700.c
==============================================================================
--- trunk/src/southbridge/amd/sb700/sb700.c	Thu Jun 17 18:16:56 2010	(r5633)
+++ trunk/src/southbridge/amd/sb700/sb700.c	Sat Jun 19 08:55:17 2010	(r5634)
@@ -120,21 +120,21 @@
 
 	printk(BIOS_DEBUG, "sb700_enable()\n");
 
-/*
-*	0:11.0  SATA	bit 8 of sm_dev 0xac : 1 - enable, default         + 32 * 3
-*	0:12.0  OHCI0-USB1	bit 0 of sm_dev 0x68
-*	0:12.1  OHCI1-USB1	bit 1 of sm_dev 0x68
-*	0:12.2  EHCI-USB1	bit 2 of sm_dev 0x68
-*	0:13.0  OHCI0-USB2	bit 4 of sm_dev 0x68
-*	0:13.1  OHCI1-USB2	bit 5 of sm_dev 0x68
-*	0:13.2  EHCI-USB2	bit 6 of sm_dev 0x68
-*	0:14.5  OHCI0-USB3	bit 7 of sm_dev 0x68
-*	0:14.0  SMBUS							0
-*	0:14.1  IDE							1
-*	0:14.2  HDA	bit 3 of pm_io 0x59 : 1 - enable, default	    + 32 * 4
-*	0:14.3  LPC	bit 20 of sm_dev 0x64 : 0 - disable, default  + 32 * 1
-*	0:14.4  PCI							4
-*/
+	/*
+	 * 0:11.0  SATA	bit 8 of sm_dev 0xac : 1 - enable, default         + 32 * 3
+	 * 0:12.0  OHCI0-USB1	bit 0 of sm_dev 0x68
+	 * 0:12.1  OHCI1-USB1	bit 1 of sm_dev 0x68
+	 * 0:12.2  EHCI-USB1	bit 2 of sm_dev 0x68
+	 * 0:13.0  OHCI0-USB2	bit 4 of sm_dev 0x68
+	 * 0:13.1  OHCI1-USB2	bit 5 of sm_dev 0x68
+	 * 0:13.2  EHCI-USB2	bit 6 of sm_dev 0x68
+	 * 0:14.5  OHCI0-USB3	bit 7 of sm_dev 0x68
+	 * 0:14.0  SMBUS							0
+	 * 0:14.1  IDE							1
+	 * 0:14.2  HDA	bit 3 of pm_io 0x59 : 1 - enable, default	    + 32 * 4
+	 * 0:14.3  LPC	bit 20 of sm_dev 0x64 : 0 - disable, default  + 32 * 1
+	 * 0:14.4  PCI							4
+	 */
 	if (dev->device == 0x0000) {
 		vendorid = pci_read_config32(dev, PCI_VENDOR_ID);
 		deviceid = (vendorid >> 16) & 0xffff;
@@ -143,6 +143,7 @@
 		vendorid = dev->vendor;
 		deviceid = dev->device;
 	}
+
 	bus_dev = dev->bus->dev;
 	if ((bus_dev->vendor == PCI_VENDOR_ID_ATI) &&
 	    (bus_dev->device == PCI_DEVICE_ID_ATI_SB700_PCI)) {
@@ -156,7 +157,6 @@
 		case 5 << 3:
 			;
 		}
-
 		return;
 	}
 

Modified: trunk/src/southbridge/amd/sb700/sb700_lpc.c
==============================================================================
--- trunk/src/southbridge/amd/sb700/sb700_lpc.c	Thu Jun 17 18:16:56 2010	(r5633)
+++ trunk/src/southbridge/amd/sb700/sb700_lpc.c	Sat Jun 19 08:55:17 2010	(r5634)
@@ -58,7 +58,6 @@
 	byte = pci_read_config8(dev, 0x78);
 	byte &= ~(1 << 1);
 	pci_write_config8(dev, 0x78, byte);
-
 }
 
 static void sb700_lpc_read_resources(device_t dev)
@@ -100,7 +99,6 @@
 	/* Specical case. SPI Base Address. The SpiRomEnable should be set. */
 	res = find_resource(dev, 0xA0);
 	pci_write_config32(dev, 0xA0, res->base | 1 << 1);
-
 }
 
 /**

Modified: trunk/src/southbridge/amd/sb700/sb700_sm.c
==============================================================================
--- trunk/src/southbridge/amd/sb700/sb700_sm.c	Thu Jun 17 18:16:56 2010	(r5633)
+++ trunk/src/southbridge/amd/sb700/sb700_sm.c	Sat Jun 19 08:55:17 2010	(r5634)
@@ -72,7 +72,6 @@
 	dword |= 1 << 13;
 	pci_write_config16(dev, 0x64, dword);
 
-
 	/* rrg:K8 INTR Enable (BIOS should set this bit after PIC initialization) */
 	/* rpr 2.1 Enabling Legacy Interrupt */
 	dword = pci_read_config8(dev, 0x62);
@@ -282,6 +281,7 @@
 
 	return do_smbus_write_byte(res->base, device, address, val);
 }
+
 static struct smbus_bus_operations lops_smbus_bus = {
 	.recv_byte = lsmbus_recv_byte,
 	.send_byte = lsmbus_send_byte,
@@ -335,10 +335,9 @@
 	res->gran = 8;
 	res->flags = IORESOURCE_IO | IORESOURCE_FIXED;
 
-
 	compact_resources(dev);
-
 }
+
 static void sb700_sm_set_resources(struct device *dev)
 {
 	struct resource *res;
@@ -346,7 +345,6 @@
 
 	pci_dev_set_resources(dev);
 
-
 	/* rpr2.14: Make HPET MMIO decoding controlled by the memory enable bit in command register of LPC ISA bridage */
 	byte = pm_ioread(0x52);
 	byte |= 1 << 6;
@@ -365,6 +363,7 @@
 static struct pci_operations lops_pci = {
 	.set_subsystem = pci_dev_set_subsystem,
 };
+
 static struct device_operations smbus_ops = {
 	.read_resources = sb700_sm_read_resources,
 	.set_resources = sb700_sm_set_resources,
@@ -374,6 +373,7 @@
 	.ops_pci = &lops_pci,
 	.ops_smbus_bus = &lops_smbus_bus,
 };
+
 static const struct pci_driver smbus_driver __pci_driver = {
 	.ops = &smbus_ops,
 	.vendor = PCI_VENDOR_ID_ATI,

Modified: trunk/src/southbridge/amd/sb700/sb700_usb.c
==============================================================================
--- trunk/src/southbridge/amd/sb700/sb700_usb.c	Thu Jun 17 18:16:56 2010	(r5633)
+++ trunk/src/southbridge/amd/sb700/sb700_usb.c	Sat Jun 19 08:55:17 2010	(r5634)
@@ -42,7 +42,6 @@
 	byte |= 0xFF;
 	pci_write_config8(sm_dev, 0x68, byte);
 
-
 	/* RPR 6.2 Enables the USB PME Event,Enable USB resume support */
 	byte = pm_ioread(0x61);
 	byte |= 1 << 6;
@@ -188,7 +187,6 @@
 	set_ehci_base(base);
 	report_resource_stored(dev, res, "");
 #endif
-
 }
 
 static struct device_operations usb_ops = {
@@ -205,6 +203,7 @@
 	.vendor = PCI_VENDOR_ID_ATI,
 	.device = PCI_DEVICE_ID_ATI_SB700_USB_18_0,
 };
+
 static const struct pci_driver usb_1_driver __pci_driver = {
 	.ops = &usb_ops,
 	.vendor = PCI_VENDOR_ID_ATI,



From mbertens at xs4all.nl  Sat Jun 19 09:03:31 2010
From: mbertens at xs4all.nl (mbertens)
Date: Sat, 19 Jun 2010 09:03:31 +0200
Subject: [coreboot] Booting problem
Message-ID: <1276931011.4023.60.camel@andrala.reboot>

Hi all, 

i made two logs with one disk one log is where disk boots in the donor
PC and there i see the difference that there are messages send to the
console (without a timestamp) those do not show up in the log with
coreboot. 

Both logs are made in the serial console, with the same kernel parameter
"console=ttyS0,115200" so there should not be a difference!

Has anyone an idea where this problem comes from ? 

Marc 

 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: putty-ip530-DISK-DIFF-coreboot.log
Type: text/x-log
Size: 61229 bytes
Desc: not available
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20100619/e747e29d/attachment.log>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: putty-ip530-DISK-DIFF-donor.log
Type: text/x-log
Size: 25710 bytes
Desc: not available
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20100619/e747e29d/attachment-0001.log>

From bari at onelabs.com  Sat Jun 19 16:05:07 2010
From: bari at onelabs.com (bari)
Date: Sat, 19 Jun 2010 09:05:07 -0500
Subject: [coreboot] GSOC AMD 7xx Mainboard mass-porting
Message-ID: <4C1CCE93.1020402@onelabs.com>

Wang,

If you need any AMD 7xx boards donated to your GSOC project that are 
only available in Europe or USA, please let us know.

-Bari



From spooky85 at gmail.com  Sat Jun 19 18:47:10 2010
From: spooky85 at gmail.com (Christian Ruppert)
Date: Sat, 19 Jun 2010 18:47:10 +0200
Subject: [coreboot] GSOC AMD 7xx Mainboard mass-porting
In-Reply-To: <4C1CCE93.1020402@onelabs.com>
References: <4C1CCE93.1020402@onelabs.com>
Message-ID: <4C1CF48E.9080100@gmail.com>

On 06/19/2010 04:05 PM, bari wrote:
> Wang,
> 
> If you need any AMD 7xx boards donated to your GSOC project that are
> only available in Europe or USA, please let us know.
> 
> -Bari
> 

That sounds great!
Please take a look at the "Asus M4A79XTD EVO" :)

-- 
Regards,
Christian Ruppert

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 262 bytes
Desc: OpenPGP digital signature
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20100619/00e77b06/attachment.sig>

From bari at onelabs.com  Sat Jun 19 20:22:20 2010
From: bari at onelabs.com (bari)
Date: Sat, 19 Jun 2010 13:22:20 -0500
Subject: [coreboot] GSOC AMD 7xx Mainboard mass-porting
In-Reply-To: <4C1CF48E.9080100@gmail.com>
References: <4C1CCE93.1020402@onelabs.com> <4C1CF48E.9080100@gmail.com>
Message-ID: <4C1D0ADC.70408@onelabs.com>

Christian Ruppert wrote:

> That sounds great!
> Please take a look at the "Asus M4A79XTD EVO" :)

Stick one in a box and ship it to him.

I guess all we need now is a "ship to" address.

-Bari



From stepan at coresystems.de  Sat Jun 19 20:31:23 2010
From: stepan at coresystems.de (Stefan Reinauer)
Date: Sat, 19 Jun 2010 20:31:23 +0200
Subject: [coreboot] GSOC AMD 7xx Mainboard mass-porting
In-Reply-To: <4C1CF48E.9080100@gmail.com>
References: <4C1CCE93.1020402@onelabs.com> <4C1CF48E.9080100@gmail.com>
Message-ID: <4C1D0CFB.7050806@coresystems.de>

On 6/19/10 6:47 PM, Christian Ruppert wrote:
> On 06/19/2010 04:05 PM, bari wrote:
>   
>> Wang,
>>
>> If you need any AMD 7xx boards donated to your GSOC project that are
>> only available in Europe or USA, please let us know.
>>
>> -Bari
>>
>>     
> That sounds great!
> Please take a look at the "Asus M4A79XTD EVO" :)
>   

The boards that will be worked on during this year's GSoC are:

- AMD "Shiner" mainboard: AM2+RS780+SB700
- AMD "Tilapia": AM3+RS780+SB700
- Gigabyte GA-MA78GM-S2H
- ASUS M4A78-VM
- Colorful C.A780G X5

(Qing Pei or Zheng, please correct the list if I'm wrong, but that was
what the GSoC application said)

Everything else is up to you guys :-)

Stefan





From juhe at iki.fi  Sat Jun 19 20:31:59 2010
From: juhe at iki.fi (Juhana Helovuo)
Date: Sat, 19 Jun 2010 21:31:59 +0300
Subject: [coreboot] Porting to Asus M4A785-M
In-Reply-To: <3C92B942FD2F45A78D16F334E642629B@chimp>
References: <1276453504.27968.52.camel@bart> <4C188515.3000409@iki.fi>
	<C99ACA6966B34C90B11874735E1F302F@chimp> <1276718131.3866.4.camel@bart>
	<AANLkTim-7sixU0sg94kvYGbLq0WRJzaxsEiN4mdgL-9G@mail.gmail.com>
	<1276780021.3607.8.camel@bart> <3C92B942FD2F45A78D16F334E642629B@chimp>
Message-ID: <1276972320.3607.42.camel@bart>

On Thu, 2010-06-17 at 07:31 -0600, Myles Watson wrote:
> > Yes, here it is attached. It is copied and modified from AMD Tilapia
> > mainboard, because that seemed to be a close relative.
> Thanks.
> 
> > Meanwhile, I added call to it8712f_kill_watchdog() , like Rudolf Marek
> > suggested. That changed the behavior so that the machine no longer
> > reboots in the middle of iterating through PCI busses and devices, but
> > instead it seems to go on iterating infinitely, or presumably until
> > malloc runs out of memory.
> OK
> 
> > Perhaps I should start out with a very minimalist devicetree and then
> > add parts as needed?
> Yes.  Instead of commenting out devices from the Tilapia board, I think you
> should turn them off.  The exception to that is: 
> 			#device pci 18.0 on end
> 			#device pci 18.0 on end


> You can look at lspci -xxx from the factory BIOS and look at the
> register
> settings to determine which link is being used, or you can just try
> moving
> those lines around.

Now this command gives only hex dumps. I have some idea what the PCI
part (first 64 bytes) means, but I have no clue how to interpret the
dump to find out the Hypertransport topology. Is there some web
reference for this? The lspci listing is attached.

Placing those duplicate "device pci 18.0 on end" entries either before
or after the main entry seems to have no effect.




After some experiments with different devicetrees, I did not get very
much further. PCI scan is still stuck in infinite loop.

If I switch device 0.0 off, the device enumeration dies, because RS780
device is not found, which is quite logical.

If I switch off the super IO device, I no longer get debug output after
that device is switched off, again quite easy to understand.

Otherwise, switching devices on or off does not seem to change the end
result: The PCI scan gets into an infinte loop (or recursion). Please
see the attached boot log. It was generated using the attached
devicetree.cb file.

I added some extra debug print statements to src/devices/pci_device.c,
function pci_scan_bus:

        /* For all children that implement scan_bus() (i.e. bridges)
         * scan the bus behind that child.
         */
        printk(BIOS_DEBUG, "PCI: pci_scan_bus entering children of devfn
%x.%x - devfn %x.%x\n",
               PCI_SLOT(min_devfn), PCI_FUNC(min_devfn),
PCI_SLOT(max_devfn), PCI_FUNC(max_devfn) );
        for (child = bus->children; child; child = child->sibling) {
          printk(BIOS_DEBUG, "  %s\n", dev_path(child) );
        }
        printk(BIOS_DEBUG, "PCI: pci_scan_bus child list end.\n");

        for (child = bus->children; child; child = child->sibling) {
                max = scan_bus(child, max);
        }

The first for-loop and printk statemements around it were added to see
if there is a recursion path through pci_scan_bus. 

The resulting log shows that this piece of code is only executed once,
so the answer was no.


If I have understood correctly, this part of the boot process scans
through the PCI busses and devices by querying the hardware. Can it get
into a loop like this, if the hardware gives funny answers?

By my logic, this could be caused by at least three things:
- bad devicetree.cb
- hardware gives funny answers to PCI scan
- bug in the PCI scan logic

Presumably, the first step would be to distinguish among these.

Where would be an appropriate place to insert printk's to find out what
is going on?

Best regards,
Juhana Helovuo

-------------- next part --------------
A non-text attachment was scrubbed...
Name: coreboot-asus-m4a785-m-debug.log
Type: text/x-log
Size: 52428 bytes
Desc: not available
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20100619/89a505f1/attachment.log>
-------------- next part --------------
# sample config for amd/tilapia_fam10
# modified towards Asus M4A785-M

chip northbridge/amd/amdfam10/root_complex
	device lapic_cluster 0 on
		chip cpu/amd/socket_AM3  #L1 and DDR2
			 device lapic 0 on end
		end
	end
	device pci_domain 0 on
		chip northbridge/amd/amdfam10
			device pci 18.0 on #  northbridge
				chip southbridge/amd/rs780
					device pci 0.0 on end # HT  	0x9600
					device pci 1.0 on end # Internal Graphics P2P bridge 0x9602
					device pci 2.0 off end # PCIE P2P bridge (external graphics) 0x9603
					device pci 3.0 off end # PCIE P2P bridge	0x960b
					device pci 4.0 off end # PCIE P2P bridge 0x9604
					device pci 5.0 off end # PCIE P2P bridge 0x9605
					device pci 6.0 off end # PCIE P2P bridge 0x9606
					device pci 7.0 off end # PCIE P2P bridge 0x9607
					device pci 8.0 on end # NB/SB Link P2P bridge
					device pci 9.0 off end #
					device pci a.0 off end #
					register "gppsb_configuration" = "1"   # Configuration B
					register "gpp_configuration" = "3"   # Configuration D default
					register "port_enable" = "0x6fc"
					register "gfx_dev2_dev3" = "1"
					register "gfx_dual_slot" = "2"

					register "gfx_lane_reversal" = "0"
					register "gfx_tmds" = "0"
					register "gfx_compliance" = "0"
					register "gfx_reconfiguration" = "1"
					register "gfx_link_width" = "0"
				end
				chip southbridge/amd/sb700 # it is under NB/SB Link, but on the same pri bus
					device pci 11.0 off end # SATA
					device pci 12.0 off end # USB
					device pci 12.1 off end # USB
					device pci 12.2 off end # USB
					device pci 13.0 off end # USB
					device pci 13.1 off end # USB
					device pci 13.2 off end # USB
	 				device pci 14.0 on # SM
						chip drivers/generic/generic #dimm 0-0-0
							device i2c 50 on end
						end
						chip drivers/generic/generic #dimm 0-0-1
							device i2c 51 on end
						end
						chip drivers/generic/generic #dimm 0-1-0
							device i2c 52 on end
						end
						chip drivers/generic/generic #dimm 0-1-1
							device i2c 53 on end
						end
					end # SM
					device pci 14.1 off end # IDE    0x439c
					device pci 14.2 off end # HDA    0x4383
					device pci 14.3 on # LPC	0x439d
						chip superio/ite/it8712f
							device pnp 2e.0 off #  Floppy
								#io 0x60 = 0x3f0
								#irq 0x70 = 6
								#drq 0x74 = 2
							end
							device pnp 2e.1 on #  Com1
								io 0x60 = 0x3f8
								irq 0x70 = 4
							end
							device pnp 2e.2 off #  Com2
								#io 0x60 = 0x2f8
								#irq 0x70 = 3
							end
							device pnp 2e.3 off #  Parallel Port
								#io 0x60 = 0x378
								#irq 0x70 = 7
							end
							device pnp 2e.4 off #  Environment Controller
							        io 0x60 = 0x290
								io 0x62 = 0x230
							        irq 0x70 = 0x00
							end 
							device pnp 2e.5 on #  Keyboard
								io 0x60 = 0x60
								io 0x62 = 0x64
								irq 0x70 = 1
							end
							device pnp 2e.6 off #  Mouse
								#irq 0x70 = 12
							end
							device pnp 2e.7 off #  GPIO, must be closed for unresolved reason.
							end
							device pnp 2e.8 off #  MIDI
							end
							device pnp 2e.9 off #  GAME
							end
							device pnp 2e.a off end #  CIR
						end	#superio
					end		#LPC
					device pci 14.4 on end # PCI to PCI Bridge [1002:4384]
					device pci 14.5 off end # USB 2
					register "ide0_enable" = "1"
					register "sata0_enable" = "1"
					register "boot_switch_sata_ide" = "0"	# 0: boot from SATA. 1: IDE
					#register "hda_viddid" = "0x10ec0882"
				end	#southbridge/amd/sb700
			end #  device pci 18.0

			device pci 18.1 on end
			device pci 18.2 on end
			device pci 18.3 on end
			device pci 18.4 on end
		end # chip northbridge
	end #pci_domain
end # northbridge/amd/amdfam10/root_complex
-------------- next part --------------
00:00.0 Host bridge: Advanced Micro Devices [AMD] RS780 Host Bridge Alternate
	Subsystem: ASUSTeK Computer Inc. Device 83a2
	Flags: bus master, 66MHz, medium devsel, latency 0
	Capabilities: [c4] HyperTransport: Slave or Primary Interface
	Capabilities: [54] HyperTransport: UnitID Clumping
	Capabilities: [40] HyperTransport: Retry Mode
	Capabilities: [9c] HyperTransport: #1a
	Capabilities: [f8] HyperTransport: #1c
00: 22 10 01 96 06 00 30 22 00 00 00 06 00 00 00 00
10: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
20: 00 00 00 00 00 00 00 00 00 00 00 00 43 10 a2 83
30: 00 00 00 00 c4 00 00 00 00 00 00 00 00 00 00 00
40: 08 9c 00 c0 c1 00 00 00 3c 00 00 00 42 20 05 00
50: 43 10 a2 83 08 40 00 90 08 10 05 00 08 00 05 00
60: 3c 00 00 00 00 00 00 00 00 02 20 00 0b c0 86 81
70: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 20
80: 00 00 00 00 10 00 00 03 20 c0 00 00 33 26 00 00
90: 00 00 00 80 7f 00 00 00 00 00 00 00 08 f8 7c d0
a0: 26 00 74 00 00 00 00 80 00 00 00 00 79 01 c0 07
b0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
c0: 00 00 00 80 08 54 80 01 20 00 11 11 d0 00 00 00
d0: 60 0b 75 1e 02 00 00 00 00 00 00 00 00 00 00 00
e0: 00 00 00 00 ff ff ff ff f0 00 00 00 00 01 00 00
f0: 00 00 00 00 00 80 80 00 08 00 00 e0 00 00 00 00

00:01.0 PCI bridge: ASUSTeK Computer Inc. Device 9602 (prog-if 00 [Normal decode])
	Flags: bus master, 66MHz, medium devsel, latency 64
	Bus: primary=00, secondary=01, subordinate=01, sec-latency=64
	I/O behind bridge: 0000d000-0000dfff
	Memory behind bridge: fe900000-feafffff
	Prefetchable memory behind bridge: 00000000d0000000-00000000dfffffff
	Capabilities: [44] HyperTransport: MSI Mapping Enable+ Fixed+
	Capabilities: [b0] Subsystem: ASUSTeK Computer Inc. Device 83a2
	Kernel modules: shpchp
00: 43 10 02 96 07 01 30 02 00 00 04 06 00 40 01 00
10: 00 00 00 00 00 00 00 00 00 01 01 40 d1 d1 20 02
20: 90 fe a0 fe 01 d0 f1 df 00 00 00 00 00 00 00 00
30: 00 00 00 00 44 00 00 00 00 00 00 00 00 00 1a 00
40: 00 00 00 00 08 b0 03 a8 00 00 00 00 43 10 a2 83
50: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
60: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
70: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
90: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
a0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
b0: 0d 00 00 00 43 10 a2 83 00 00 00 00 00 00 00 00
c0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
d0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
e0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
f0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00

00:0a.0 PCI bridge: Advanced Micro Devices [AMD] RS780 PCI to PCI bridge (PCIE port 5) (prog-if 00 [Normal decode])
	Flags: bus master, fast devsel, latency 0
	Bus: primary=00, secondary=02, subordinate=02, sec-latency=0
	I/O behind bridge: 0000e000-0000efff
	Memory behind bridge: feb00000-febfffff
	Prefetchable memory behind bridge: 00000000fdf00000-00000000fdffffff
	Capabilities: [50] Power Management version 3
	Capabilities: [58] Express Root Port (Slot+), MSI 00
	Capabilities: [a0] Message Signalled Interrupts: Mask- 64bit- Queue=0/0 Enable+
	Capabilities: [b0] Subsystem: ASUSTeK Computer Inc. Device 83a2
	Capabilities: [b8] HyperTransport: MSI Mapping Enable+ Fixed+
	Capabilities: [100] Vendor Specific Information <?>
	Capabilities: [110] Virtual Channel <?>
	Kernel driver in use: pcieport-driver
	Kernel modules: shpchp
00: 22 10 09 96 07 05 10 00 00 00 04 06 10 00 01 00
10: 00 00 00 00 00 00 00 00 00 02 02 00 e1 e1 00 00
20: b0 fe b0 fe f1 fd f1 fd 00 00 00 00 00 00 00 00
30: 00 00 00 00 50 00 00 00 00 00 00 00 0a 01 07 00
40: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
50: 01 58 03 c8 00 00 00 00 10 a0 42 01 20 80 00 00
60: 1f 08 00 00 12 0c 30 01 40 00 11 70 80 0c 54 00
70: 00 00 48 01 00 00 01 00 00 00 00 00 00 00 00 00
80: 00 00 00 00 00 00 00 00 01 00 00 00 00 00 00 00
90: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
a0: 05 b0 01 00 0c 30 e0 fe 51 41 00 00 00 00 00 00
b0: 0d b8 00 00 43 10 a2 83 08 00 03 a8 00 00 00 00
c0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
d0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
e0: 00 00 00 00 ff ff ff ff 00 00 00 00 00 00 00 00
f0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00

00:11.0 SATA controller: ATI Technologies Inc SB700/SB800 SATA Controller [IDE mode] (prog-if 01 [AHCI 1.0])
	Subsystem: ASUSTeK Computer Inc. Device 8389
	Flags: bus master, 66MHz, medium devsel, latency 64, IRQ 22
	I/O ports at c000 [size=8]
	I/O ports at b000 [size=4]
	I/O ports at a000 [size=8]
	I/O ports at 9000 [size=4]
	I/O ports at 8000 [size=16]
	Memory at fe8ffc00 (32-bit, non-prefetchable) [size=1K]
	Capabilities: [60] Power Management version 2
	Capabilities: [70] SATA HBA <?>
	Kernel driver in use: ahci
	Kernel modules: ahci
00: 02 10 90 43 07 01 30 02 00 01 06 01 10 40 00 00
10: 01 c0 00 00 01 b0 00 00 01 a0 00 00 01 90 00 00
20: 01 80 00 00 00 fc 8f fe 00 00 00 00 43 10 89 83
30: 00 00 00 00 60 00 00 00 00 00 00 00 0b 01 00 00
40: 10 00 00 00 01 00 10 00 c0 bf 00 00 00 00 00 00
50: 05 70 84 00 00 00 00 00 00 00 00 00 00 00 00 00
60: 01 70 22 00 00 00 00 00 00 00 00 00 00 00 00 00
70: 12 00 10 00 0f 00 00 00 00 00 00 00 00 00 00 00
80: 00 00 00 00 06 00 00 2c f6 a0 b4 01 f6 a0 b4 01
90: f6 a0 b4 01 f6 a0 b4 01 f6 a0 b4 01 f7 a0 b4 01
a0: d8 a0 f8 a0 f8 a0 f8 a0 b8 a0 fa a0 00 00 00 00
b0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
c0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
d0: 00 00 00 00 00 00 00 00 00 00 00 00 00 20 00 00
e0: 80 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
f0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00

00:12.0 USB Controller: ATI Technologies Inc SB700/SB800 USB OHCI0 Controller (prog-if 10 [OHCI])
	Subsystem: ASUSTeK Computer Inc. Device 8389
	Flags: bus master, 66MHz, medium devsel, latency 64, IRQ 16
	Memory at fe8fe000 (32-bit, non-prefetchable) [size=4K]
	Kernel driver in use: ohci_hcd
	Kernel modules: ohci-hcd
00: 02 10 97 43 06 01 a0 02 00 10 03 0c 10 40 80 00
10: 00 e0 8f fe 00 00 00 00 00 00 00 00 00 00 00 00
20: 00 00 00 00 00 00 00 00 00 00 00 00 43 10 89 83
30: 00 00 00 00 00 00 00 00 00 00 00 00 0a 01 00 00
40: 80 03 00 00 11 00 00 00 00 00 00 00 00 00 00 00
50: 40 13 03 f6 00 00 00 00 ff ff ff ff 00 00 00 00
60: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
70: 00 00 00 00 ff 00 00 80 00 00 00 00 00 00 00 00
80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
90: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
a0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
b0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
c0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
d0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
e0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
f0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00

00:12.1 USB Controller: ATI Technologies Inc SB700 USB OHCI1 Controller (prog-if 10 [OHCI])
	Subsystem: ASUSTeK Computer Inc. Device 8389
	Flags: bus master, 66MHz, medium devsel, latency 64, IRQ 16
	Memory at fe8fd000 (32-bit, non-prefetchable) [size=4K]
	Kernel driver in use: ohci_hcd
	Kernel modules: ohci-hcd
00: 02 10 98 43 17 01 a0 02 00 10 03 0c 10 40 00 00
10: 00 d0 8f fe 00 00 00 00 00 00 00 00 00 00 00 00
20: 00 00 00 00 00 00 00 00 00 00 00 00 43 10 89 83
30: 00 00 00 00 00 00 00 00 00 00 00 00 0a 01 00 00
40: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
50: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
60: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
70: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
90: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
a0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
b0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
c0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
d0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
e0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
f0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00

00:12.2 USB Controller: ATI Technologies Inc SB700/SB800 USB EHCI Controller (prog-if 20 [EHCI])
	Subsystem: ASUSTeK Computer Inc. Device 8389
	Flags: bus master, 66MHz, medium devsel, latency 64, IRQ 17
	Memory at fe8ff800 (32-bit, non-prefetchable) [size=256]
	Capabilities: [c0] Power Management version 2
	Capabilities: [e4] Debug port: BAR=1 offset=00e0
	Kernel driver in use: ehci_hcd
	Kernel modules: ehci-hcd
00: 02 10 96 43 16 01 b0 02 00 20 03 0c 10 40 00 00
10: 00 f8 8f fe 00 00 00 00 00 00 00 00 00 00 00 00
20: 00 00 00 00 00 00 00 00 00 00 00 00 43 10 89 83
30: 00 00 00 00 c0 00 00 00 00 00 00 00 0b 02 00 00
40: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
50: d8 01 9e 80 00 00 00 00 00 00 00 00 00 00 00 00
60: 20 20 00 00 00 00 00 00 00 00 00 00 00 00 00 00
70: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
90: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
a0: 01 00 00 00 00 00 08 c0 00 00 00 00 00 00 00 00
b0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
c0: 01 e4 02 7e 00 00 40 00 00 00 00 00 00 00 00 00
d0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
e0: 00 00 00 00 0a 00 e0 20 00 00 00 00 00 00 00 00
f0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00

00:13.0 USB Controller: ATI Technologies Inc SB700/SB800 USB OHCI0 Controller (prog-if 10 [OHCI])
	Subsystem: ASUSTeK Computer Inc. Device 8389
	Flags: bus master, 66MHz, medium devsel, latency 64, IRQ 18
	Memory at fe8fc000 (32-bit, non-prefetchable) [size=4K]
	Kernel driver in use: ohci_hcd
	Kernel modules: ohci-hcd
00: 02 10 97 43 06 01 a0 02 00 10 03 0c 10 40 80 00
10: 00 c0 8f fe 00 00 00 00 00 00 00 00 00 00 00 00
20: 00 00 00 00 00 00 00 00 00 00 00 00 43 10 89 83
30: 00 00 00 00 00 00 00 00 00 00 00 00 0a 01 00 00
40: 80 03 00 00 11 00 00 00 00 00 00 00 00 00 00 00
50: 40 13 03 f6 00 00 00 00 ff ff ff ff 00 00 00 00
60: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
70: 00 00 00 00 ff 00 00 80 00 00 00 00 00 00 00 00
80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
90: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
a0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
b0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
c0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
d0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
e0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
f0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00

00:13.1 USB Controller: ATI Technologies Inc SB700 USB OHCI1 Controller (prog-if 10 [OHCI])
	Subsystem: ASUSTeK Computer Inc. Device 8389
	Flags: bus master, 66MHz, medium devsel, latency 64, IRQ 18
	Memory at fe8fb000 (32-bit, non-prefetchable) [size=4K]
	Kernel driver in use: ohci_hcd
	Kernel modules: ohci-hcd
00: 02 10 98 43 17 01 a0 02 00 10 03 0c 10 40 00 00
10: 00 b0 8f fe 00 00 00 00 00 00 00 00 00 00 00 00
20: 00 00 00 00 00 00 00 00 00 00 00 00 43 10 89 83
30: 00 00 00 00 00 00 00 00 00 00 00 00 0a 01 00 00
40: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
50: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
60: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
70: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
90: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
a0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
b0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
c0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
d0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
e0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
f0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00

00:13.2 USB Controller: ATI Technologies Inc SB700/SB800 USB EHCI Controller (prog-if 20 [EHCI])
	Subsystem: ASUSTeK Computer Inc. Device 8389
	Flags: bus master, 66MHz, medium devsel, latency 64, IRQ 19
	Memory at fe8ff400 (32-bit, non-prefetchable) [size=256]
	Capabilities: [c0] Power Management version 2
	Capabilities: [e4] Debug port: BAR=1 offset=00e0
	Kernel driver in use: ehci_hcd
	Kernel modules: ehci-hcd
00: 02 10 96 43 16 01 b0 02 00 20 03 0c 10 40 00 00
10: 00 f4 8f fe 00 00 00 00 00 00 00 00 00 00 00 00
20: 00 00 00 00 00 00 00 00 00 00 00 00 43 10 89 83
30: 00 00 00 00 c0 00 00 00 00 00 00 00 0a 02 00 00
40: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
50: d8 01 9e 80 00 00 00 00 00 00 00 00 00 00 00 00
60: 20 20 00 00 00 00 00 00 00 00 00 00 00 00 00 00
70: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
90: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
a0: 01 00 00 00 00 00 08 c0 00 00 00 00 00 00 00 00
b0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
c0: 01 e4 02 7e 00 00 40 00 00 00 00 00 00 00 00 00
d0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
e0: 00 00 00 00 0a 00 e0 20 00 00 00 00 00 00 00 00
f0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00

00:14.0 SMBus: ATI Technologies Inc SBx00 SMBus Controller (rev 3c)
	Subsystem: ASUSTeK Computer Inc. Device 8389
	Flags: 66MHz, medium devsel
	Capabilities: [b0] HyperTransport: MSI Mapping Enable- Fixed+
	Kernel driver in use: piix4_smbus
	Kernel modules: i2c-piix4
00: 02 10 85 43 03 04 30 d2 3c 00 05 0c 00 00 80 00
10: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
20: 00 00 00 00 00 00 00 00 00 00 00 00 43 10 89 83
30: 00 00 00 00 b0 00 00 00 00 00 00 00 00 00 00 00
40: 44 eb 00 fd 00 00 00 00 0f ff 00 00 00 00 00 c0
50: f0 01 f0 0e 70 05 f0 0f 21 0b f0 0f 80 00 10 00
60: 01 00 24 20 bf fc 9e 03 ff 90 00 00 20 00 00 00
70: 00 00 00 00 08 00 c0 fe ff 6e 00 00 00 00 f0 06
80: f0 0a f0 0f 00 00 00 00 00 00 00 00 00 00 00 00
90: 01 0b 00 00 f9 ce ff 00 00 00 00 00 00 00 00 00
a0: 00 00 ff ff 7f ff f0 09 00 ff 08 02 06 59 20 18
b0: 08 00 02 a8 00 00 d0 fe 00 00 00 00 f0 0f 08 1a
c0: ff ff ff ff 00 00 00 00 00 00 00 00 00 00 00 00
d0: 00 00 01 00 00 00 00 00 00 00 00 00 00 00 00 00
e0: 20 99 00 00 00 00 00 00 00 00 00 00 00 00 00 00
f0: d8 0c 00 00 00 00 44 00 00 00 00 00 02 00 34 00

00:14.1 IDE interface: ATI Technologies Inc SB700/SB800 IDE Controller (prog-if 8a [Master SecP PriP])
	Subsystem: ASUSTeK Computer Inc. Device 8389
	Flags: bus master, 66MHz, medium devsel, latency 0, IRQ 16
	I/O ports at 01f0 [size=8]
	I/O ports at 03f4 [size=1]
	I/O ports at 0170 [size=8]
	I/O ports at 0374 [size=1]
	I/O ports at ff00 [size=16]
	Capabilities: [70] Message Signalled Interrupts: Mask- 64bit- Queue=0/1 Enable-
	Kernel driver in use: ATIIXP_IDE
	Kernel modules: ide-pci-generic, atiixp, ata_generic
00: 02 10 9c 43 05 00 30 02 00 8a 01 01 00 00 00 00
10: 01 00 00 00 01 00 00 00 01 00 00 00 01 00 00 00
20: 01 ff 00 00 00 00 00 00 00 00 00 00 43 10 89 83
30: 00 00 00 00 70 00 00 00 00 00 00 00 00 01 00 00
40: 20 20 99 99 20 20 ff ff 00 00 44 00 00 00 00 00
50: 00 00 00 00 03 00 22 00 00 00 00 00 00 00 00 00
60: 00 00 40 26 10 2c 01 07 01 00 00 00 ff ff 0f 00
70: 05 00 02 00 00 00 00 00 00 00 00 00 00 00 00 00
80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
90: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
a0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
b0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
c0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
d0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
e0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
f0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00

00:14.2 Audio device: ATI Technologies Inc SBx00 Azalia (Intel HDA)
	Subsystem: ASUSTeK Computer Inc. Device 836c
	Flags: bus master, slow devsel, latency 64, IRQ 16
	Memory at fe8f4000 (64-bit, non-prefetchable) [size=16K]
	Capabilities: [50] Power Management version 2
	Kernel driver in use: HDA Intel
	Kernel modules: snd-hda-intel
00: 02 10 83 43 06 00 10 04 00 00 03 04 10 40 00 00
10: 04 40 8f fe 00 00 00 00 00 00 00 00 00 00 00 00
20: 00 00 00 00 00 00 00 00 00 00 00 00 43 10 6c 83
30: 00 00 00 00 50 00 00 00 00 00 00 00 0a 00 00 00
40: 00 00 02 00 00 00 00 00 00 00 00 00 01 00 00 00
50: 01 00 42 c8 00 00 00 00 00 00 00 00 00 00 00 00
60: 05 00 80 00 00 00 00 00 00 00 00 00 00 00 00 00
70: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
90: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
a0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
b0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
c0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
d0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
e0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
f0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00

00:14.3 ISA bridge: ATI Technologies Inc SB700/SB800 LPC host controller
	Subsystem: ASUSTeK Computer Inc. Device 8389
	Flags: bus master, 66MHz, medium devsel, latency 0
00: 02 10 9d 43 0f 00 20 02 00 00 01 06 00 00 80 00
10: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
20: 00 00 00 00 00 00 00 00 00 00 00 00 43 10 89 83
30: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
40: 04 00 00 00 43 c0 03 ff 17 ff 40 00 00 00 00 00
50: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
60: 00 00 00 00 30 02 00 00 0e 00 0f 00 b0 ff ff ff
70: 67 45 23 00 00 00 00 00 1c 00 00 00 05 0a 00 00
80: 08 00 03 a8 00 00 00 00 00 00 00 00 00 00 00 00
90: 00 00 00 00 00 00 00 00 00 00 00 08 01 00 00 00
a0: 02 00 c1 fe 2f 00 00 00 00 00 00 00 00 00 00 00
b0: 00 00 00 00 00 00 00 00 00 00 00 e9 f2 ff 00 00
c0: 00 00 00 00 00 00 08 00 f7 ff ff fd 00 00 00 78
d0: 00 ff ff 00 00 00 00 ff ff ff ff 00 00 00 00 0c
e0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
f0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00

00:14.4 PCI bridge: ATI Technologies Inc SBx00 PCI to PCI Bridge (prog-if 01 [Subtractive decode])
	Flags: bus master, 66MHz, medium devsel, latency 64
	Bus: primary=00, secondary=03, subordinate=03, sec-latency=64
00: 02 10 84 43 05 01 a0 02 00 01 04 06 00 40 81 00
10: 00 00 00 00 00 00 00 00 00 03 03 40 f0 00 80 22
20: f0 ff 00 00 f0 ff 00 00 00 00 00 00 00 00 00 00
30: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 07 00
40: 26 00 3c ff 00 00 00 00 0c 0f 3d d1 00 01 00 00
50: 01 00 00 00 08 00 03 a8 00 00 00 00 85 00 ff ff
60: ca 0e 17 00 ba d8 10 00 00 00 00 00 00 00 00 00
70: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
90: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
a0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
b0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
c0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
d0: 00 00 00 00 00 00 00 00 00 00 00 00 01 00 02 06
e0: 00 00 80 00 00 00 00 00 00 00 00 00 00 00 00 00
f0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00

00:14.5 USB Controller: ATI Technologies Inc SB700/SB800 USB OHCI2 Controller (prog-if 10 [OHCI])
	Subsystem: ASUSTeK Computer Inc. Device 8389
	Flags: bus master, 66MHz, medium devsel, latency 64, IRQ 18
	Memory at fe8fa000 (32-bit, non-prefetchable) [size=4K]
	Kernel driver in use: ohci_hcd
	Kernel modules: ohci-hcd
00: 02 10 99 43 06 01 a0 02 00 10 03 0c 10 40 00 00
10: 00 a0 8f fe 00 00 00 00 00 00 00 00 00 00 00 00
20: 00 00 00 00 00 00 00 00 00 00 00 00 43 10 89 83
30: 00 00 00 00 00 00 00 00 00 00 00 00 0a 03 00 00
40: 80 01 00 00 11 00 00 00 00 00 00 00 00 00 00 00
50: 40 13 1f f6 00 00 00 00 ff ff ff ff 00 00 00 00
60: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
70: 00 00 00 00 ff 00 00 80 00 00 00 00 00 00 00 00
80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
90: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
a0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
b0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
c0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
d0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
e0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
f0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00

00:18.0 Host bridge: Advanced Micro Devices [AMD] Family 10h [Opteron, Athlon64, Sempron] HyperTransport Configuration
	Flags: fast devsel
	Capabilities: [80] HyperTransport: Host or Secondary Interface
00: 22 10 00 12 00 00 10 00 00 00 00 06 00 00 80 00
10: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
20: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
30: 00 00 00 00 80 00 00 00 00 00 00 00 00 00 00 00
40: 01 02 04 00 01 02 04 00 01 02 04 00 01 02 04 00
50: 01 02 04 00 01 02 04 00 01 02 04 00 01 02 04 00
60: 00 00 01 00 e0 00 00 00 20 a8 2f 01 30 f8 00 00
70: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
80: 08 00 01 21 20 20 11 11 60 0b f5 8f 13 00 00 00
90: d0 02 85 80 00 00 00 00 07 00 00 00 00 00 00 00
a0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
b0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
c0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
d0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
e0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
f0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00

00:18.1 Host bridge: Advanced Micro Devices [AMD] Family 10h [Opteron, Athlon64, Sempron] Address Map
	Flags: fast devsel
00: 22 10 01 12 00 00 00 00 00 00 00 06 00 00 80 00
10: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
20: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
30: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
40: 03 00 00 00 00 00 7f 00 00 00 00 00 00 00 00 00
50: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
60: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
70: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
90: 03 0a 00 00 00 0b 00 00 03 00 80 00 00 ff cf 00
a0: 03 00 d0 00 80 ff ef 00 03 00 f0 00 00 8f fe 00
b0: 03 90 fe 00 80 af fe 00 03 b0 fe 00 00 ef ff 00
c0: 13 10 00 00 00 f0 ff 00 00 00 00 00 00 00 00 00
d0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
e0: 03 00 00 07 00 00 00 00 00 00 00 00 00 00 00 00
f0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00

00:18.2 Host bridge: Advanced Micro Devices [AMD] Family 10h [Opteron, Athlon64, Sempron] DRAM Controller
	Flags: fast devsel
00: 22 10 02 12 00 00 00 00 00 00 00 06 00 00 80 00
10: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
20: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
30: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
40: 01 00 00 00 01 01 00 00 00 00 00 00 00 00 00 00
50: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
60: e0 3e 78 00 00 00 00 00 00 00 00 00 00 00 00 00
70: 00 00 00 00 00 00 00 00 06 00 c8 0f 00 00 00 00
80: 05 00 00 00 00 00 00 00 35 fb 7d 5d 34 03 22 00
90: 10 04 01 00 0b 00 58 7f 07 03 00 80 00 00 00 00
a0: 00 02 00 00 00 00 00 00 00 00 00 00 00 00 00 00
b0: 6b 8c 84 19 9c 00 00 00 ff 00 1c 07 e9 ef 00 c0
c0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
d0: 0f 38 f8 9e ef 00 f0 f0 81 ff 10 fe 31 e6 fa 7d
e0: ff 3b fc fe ff 1f 70 0c 0f 00 1c 80 dc e5 ef ff
f0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00

00:18.3 Host bridge: Advanced Micro Devices [AMD] Family 10h [Opteron, Athlon64, Sempron] Miscellaneous Control
	Flags: fast devsel
	Capabilities: [f0] Secure device <?>
00: 22 10 03 12 00 00 10 00 00 00 00 06 00 00 80 00
10: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
20: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
30: 00 00 00 00 f0 00 00 00 00 00 00 00 00 00 00 00
40: ff ff ff 3f 5c 00 b0 4a 00 00 00 00 00 00 00 00
50: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
60: 00 00 00 00 05 62 5f 34 00 00 00 30 51 80 01 60
70: 51 11 32 60 01 01 98 00 14 0c 20 00 11 08 07 00
80: 81 e6 00 e6 e6 41 e6 01 08 00 00 00 00 20 58 42
90: 00 00 00 00 83 4f 00 00 60 e0 9f ff 00 00 00 00
a0: 00 08 06 b0 80 18 88 11 00 00 00 00 00 00 00 00
b0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
c0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
d0: 00 00 00 00 26 0f 81 c8 16 14 2c 03 2c 53 27 00
e0: 00 00 00 00 30 12 00 1d 79 5f 07 00 00 00 00 00
f0: 0f 00 10 00 00 00 00 00 00 00 00 00 62 0f 10 00

00:18.4 Host bridge: Advanced Micro Devices [AMD] Family 10h [Opteron, Athlon64, Sempron] Link Control
	Flags: fast devsel
00: 22 10 04 12 00 00 00 00 00 00 00 06 00 00 80 00
10: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
20: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
30: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
40: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
50: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
60: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
70: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
90: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
a0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
b0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
c0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
d0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
e0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
f0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00

01:05.0 VGA compatible controller: ATI Technologies Inc Device 9710 (prog-if 00 [VGA controller])
	Subsystem: ASUSTeK Computer Inc. Device 83a2
	Flags: bus master, fast devsel, latency 0, IRQ 10
	Memory at d0000000 (32-bit, prefetchable) [size=256M]
	I/O ports at d000 [size=256]
	Memory at feaf0000 (32-bit, non-prefetchable) [size=64K]
	Memory at fe900000 (32-bit, non-prefetchable) [size=1M]
	Capabilities: [50] Power Management version 3
	Capabilities: [a0] Message Signalled Interrupts: Mask- 64bit+ Queue=0/0 Enable-
00: 02 10 10 97 07 01 10 40 00 00 00 03 10 00 80 00
10: 08 00 00 d0 01 d0 00 00 00 00 af fe 00 00 00 00
20: 00 00 00 00 00 00 90 fe 00 00 00 00 43 10 a2 83
30: 00 00 00 00 50 00 00 00 00 00 00 00 0a 01 00 00
40: 00 00 00 00 00 00 00 00 00 00 00 00 43 10 a2 83
50: 01 a0 03 06 00 00 00 00 10 a0 12 00 a0 8f 00 00
60: 10 08 0a 00 01 0d 00 00 00 00 01 11 00 00 00 00
70: 00 00 00 00 00 00 00 00 00 00 00 00 1f 00 00 00
80: 00 00 00 00 00 00 00 00 01 00 01 00 00 00 00 00
90: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
a0: 05 00 80 00 00 00 00 00 00 00 00 00 00 00 00 00
b0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
c0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
d0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
e0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
f0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00

01:05.1 Audio device: ATI Technologies Inc Device 970f
	Subsystem: ASUSTeK Computer Inc. Device 83a2
	Flags: bus master, fast devsel, latency 0, IRQ 10
	Memory at feae8000 (32-bit, non-prefetchable) [size=16K]
	Capabilities: [50] Power Management version 3
	Capabilities: [a0] Message Signalled Interrupts: Mask- 64bit+ Queue=0/0 Enable-
00: 02 10 0f 97 07 01 10 40 00 00 03 04 10 00 80 00
10: 00 80 ae fe 00 00 00 00 00 00 00 00 00 00 00 00
20: 00 00 00 00 00 00 00 00 00 00 00 00 43 10 a2 83
30: 00 00 00 00 50 00 00 00 00 00 00 00 0a 02 00 00
40: 00 00 00 00 00 00 00 00 00 00 00 00 43 10 a2 83
50: 01 a0 03 06 00 00 00 00 10 a0 12 00 a0 8f 00 00
60: 10 08 0a 00 01 0d 00 00 00 00 01 11 00 00 00 00
70: 00 00 00 00 00 00 00 00 00 00 00 00 1f 00 00 00
80: 00 00 00 00 00 00 00 00 00 00 01 00 00 00 00 00
90: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
a0: 05 00 80 00 00 00 00 00 00 00 00 00 00 00 00 00
b0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
c0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
d0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
e0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
f0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00

02:00.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL8111/8168B PCI Express Gigabit Ethernet controller (rev 03)
	Subsystem: ASUSTeK Computer Inc. Device 83a3
	Flags: bus master, fast devsel, latency 0, IRQ 1278
	I/O ports at e800 [size=256]
	Memory at fdfff000 (64-bit, prefetchable) [size=4K]
	Memory at fdff8000 (64-bit, prefetchable) [size=16K]
	Expansion ROM at febf0000 [disabled] [size=64K]
	Capabilities: [40] Power Management version 3
	Capabilities: [50] Message Signalled Interrupts: Mask- 64bit+ Queue=0/0 Enable+
	Capabilities: [70] Express Endpoint, MSI 01
	Capabilities: [ac] MSI-X: Enable- Mask- TabSize=4
	Capabilities: [cc] Vital Product Data <?>
	Capabilities: [100] Advanced Error Reporting <?>
	Capabilities: [140] Virtual Channel <?>
	Capabilities: [160] Device Serial Number 00-00-00-00-00-00-00-00
	Kernel driver in use: r8169
	Kernel modules: r8169
00: ec 10 68 81 07 05 10 00 03 00 00 02 10 00 00 00
10: 01 e8 00 00 00 00 00 00 0c f0 ff fd 00 00 00 00
20: 0c 80 ff fd 00 00 00 00 00 00 00 00 43 10 a3 83
30: 00 00 bf fe 40 00 00 00 00 00 00 00 0a 01 00 00
40: 01 50 c3 ff 08 00 00 00 00 00 00 00 00 00 00 00
50: 05 70 81 00 0c 30 e0 fe 00 00 00 00 59 41 00 00
60: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
70: 10 ac 02 02 c1 8c 64 00 00 20 19 00 11 3c 07 00
80: 40 00 11 10 00 00 00 00 00 00 00 00 00 00 00 00
90: 00 00 00 00 10 00 00 00 00 00 00 00 00 00 00 00
a0: 00 00 00 00 00 00 00 00 00 00 00 00 11 cc 03 00
b0: 04 00 00 00 04 08 00 00 00 00 00 00 00 00 00 00
c0: 00 00 00 00 00 00 00 00 00 00 00 00 03 00 00 00
d0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
e0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
f0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00


From bari at onelabs.com  Sat Jun 19 20:33:37 2010
From: bari at onelabs.com (bari)
Date: Sat, 19 Jun 2010 13:33:37 -0500
Subject: [coreboot] GSOC AMD 7xx Mainboard mass-porting
In-Reply-To: <4C1D0CFB.7050806@coresystems.de>
References: <4C1CCE93.1020402@onelabs.com> <4C1CF48E.9080100@gmail.com>
	<4C1D0CFB.7050806@coresystems.de>
Message-ID: <4C1D0D81.7010001@onelabs.com>

Stefan Reinauer wrote:

> 
> The boards that will be worked on during this year's GSoC are:
> 
> - AMD "Shiner" mainboard: AM2+RS780+SB700
> - AMD "Tilapia": AM3+RS780+SB700
> - Gigabyte GA-MA78GM-S2H
> - ASUS M4A78-VM
> - Colorful C.A780G X5

Stefan,

Thanks for the list. Can this go up on the wiki?

-Bari



From Cristi.Magherusan at net.utcluj.ro  Sat Jun 19 23:48:08 2010
From: Cristi.Magherusan at net.utcluj.ro (Cristi Magherusan)
Date: Sun, 20 Jun 2010 00:48:08 +0300
Subject: [coreboot] [patch] Added dependency checking for the USB EHCI debug
 Kconfig option
Message-ID: <1276984088.6251.9.camel@ufo>

See attached patch.

I had to add that ifdef because config.h didn't have defined the
CONFIG_USBDEBUG_DIRECT option and compilation failed.
If anyone has an idea how I can get it defined there, I'm all ears.

Signed-off-by: Cristi Magherusan <cristi.magherusan at net.utcluj.ro>

-- 
Cristi M?gheru?an, alumnus System/Network Engineer
Technical University of Cluj-Napoca, Romania
http://cc.utcluj.ro  +40264 401247
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0001-Added-dependency-checking-for-the-USB-EHCI-debug-Kco.patch
Type: text/x-patch
Size: 1645 bytes
Desc: not available
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20100620/24af323a/attachment.patch>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20100620/24af323a/attachment.sig>

From stepan at coresystems.de  Sun Jun 20 02:00:25 2010
From: stepan at coresystems.de (Stefan Reinauer)
Date: Sun, 20 Jun 2010 02:00:25 +0200
Subject: [coreboot] [patch] Added dependency checking for the USB EHCI
 debug Kconfig option
In-Reply-To: <1276984088.6251.9.camel@ufo>
References: <1276984088.6251.9.camel@ufo>
Message-ID: <4C1D5A19.3000609@coresystems.de>

On 6/19/10 11:48 PM, Cristi Magherusan wrote:
> See attached patch.
>
> I had to add that ifdef because config.h didn't have defined the
> CONFIG_USBDEBUG_DIRECT option and compilation failed.
> If anyone has an idea how I can get it defined there, I'm all ears.
>   
Why not just leave it as it is? Someone might plug an USB2 card into a
system that doesn't have the chip onboard.

Stefan



From wangqingpei at gmail.com  Sun Jun 20 05:37:48 2010
From: wangqingpei at gmail.com (Qing Pei Wang)
Date: Sun, 20 Jun 2010 11:37:48 +0800
Subject: [coreboot] GSOC AMD 7xx Mainboard mass-porting
In-Reply-To: <4C1D0CFB.7050806@coresystems.de>
References: <4C1CCE93.1020402@onelabs.com> <4C1CF48E.9080100@gmail.com>
	<4C1D0CFB.7050806@coresystems.de>
Message-ID: <AANLkTin6644f3zFQ2Ln5cMZxyId6HxYBKiIMx3ObGMBq@mail.gmail.com>

hi Stefan,
it is right, i should confirm that AMD "Shiner" code could be submitted
after AMD permitted.
- Gigabyte GA-MA78GM-S2H(i have already got it)
- ASUS M4A78-VM (still ordering, there is no spot goods)
- Colorful C.A780G X5(i can not find in China, but i have an jetway PA78VM5)

hi bari,
  that would be very fine if i can get one of the 780 mainboards,

On Sun, Jun 20, 2010 at 2:31 AM, Stefan Reinauer <stepan at coresystems.de>wrote:

> On 6/19/10 6:47 PM, Christian Ruppert wrote:
> > On 06/19/2010 04:05 PM, bari wrote:
> >
> >> Wang,
> >>
> >> If you need any AMD 7xx boards donated to your GSOC project that are
> >> only available in Europe or USA, please let us know.
> >>
> >> -Bari
> >>
> >>
> > That sounds great!
> > Please take a look at the "Asus M4A79XTD EVO" :)
> >
>
> The boards that will be worked on during this year's GSoC are:
>
> - AMD "Shiner" mainboard: AM2+RS780+SB700
> - AMD "Tilapia": AM3+RS780+SB700
> - Gigabyte GA-MA78GM-S2H
> - ASUS M4A78-VM
> - Colorful C.A780G X5
>
> (Qing Pei or Zheng, please correct the list if I'm wrong, but that was
> what the GSoC application said)
>
> Everything else is up to you guys :-)
>
> Stefan
>
>
>


-- 
Wang Qing Pei
MSN:wangqingpei at hotmail.com <MSN%3Awangqingpei at hotmail.com>
Gmail:wangqingpei at gmail.com <Gmail%3Awangqingpei at gmail.com>
Phone:86+13426369984
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20100620/e7cf54f9/attachment.html>

From joe at settoplinux.org  Sun Jun 20 07:59:31 2010
From: joe at settoplinux.org (Joseph Smith)
Date: Sun, 20 Jun 2010 01:59:31 -0400
Subject: [coreboot] [PATCH] i810 GFXUMA and Northbridge fixes
Message-ID: <4C1DAE43.5080801@settoplinux.org>

Hello,
This patch implements gfxuma on all supported i810 boards. Also some 
fix-ups to the i810 northbridge.c code.

Abuild tested all i810 boards.
Build and boot tested on soon to come i810e board.

Signed-off by: Joseph Smith <joe at settoplinux.org>

-- 
Thanks,
Joseph Smith
Set-Top-Linux
www.settoplinux.org
-------------- next part --------------
A non-text attachment was scrubbed...
Name: gfxuma_i810.patch
Type: text/x-patch
Size: 11056 bytes
Desc: not available
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20100620/a677757a/attachment.patch>

From Cristi.Magherusan at net.utcluj.ro  Sun Jun 20 08:04:30 2010
From: Cristi.Magherusan at net.utcluj.ro (Cristi Magherusan)
Date: Sun, 20 Jun 2010 09:04:30 +0300
Subject: [coreboot] [patch] Added dependency checking for the USB EHCI
 debug Kconfig option
In-Reply-To: <4C1D5A19.3000609@coresystems.de>
References: <1276984088.6251.9.camel@ufo>  <4C1D5A19.3000609@coresystems.de>
Message-ID: <1277013870.17510.3.camel@ufo>

On Sun, 2010-06-20 at 02:00 +0200, Stefan Reinauer wrote:
> On 6/19/10 11:48 PM, Cristi Magherusan wrote:
> > See attached patch.
> >
> > I had to add that ifdef because config.h didn't have defined the
> > CONFIG_USBDEBUG_DIRECT option and compilation failed.
> > If anyone has an idea how I can get it defined there, I'm all ears.
> >   
> Why not just leave it as it is? Someone might plug an USB2 card into a
> system that doesn't have the chip onboard.
> 
> Stefan
> 
Compilation fails if you select the option and the support is not
implemented. If anyone wants to use the devi