From peter at stuge.se  Mon Mar  1 04:55:14 2010
From: peter at stuge.se (Peter Stuge)
Date: Mon, 1 Mar 2010 04:55:14 +0100
Subject: [coreboot] [PATCH]generic ssdt rules
In-Reply-To: <4B8AEA4D.1090800@georgi-clan.de>
References: <4B8AEA4D.1090800@georgi-clan.de>
Message-ID: <20100301035514.12174.qmail@stuge.se>

Patrick Georgi wrote:
> attached patch unifies the ACPI_SSDTX_NUM handling.
..
> Signed-off-by: Patrick Georgi <patrick.georgi at coresystems.de>

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



From joe at settoplinux.org  Mon Mar  1 06:15:47 2010
From: joe at settoplinux.org (Joseph Smith)
Date: Mon, 01 Mar 2010 00:15:47 -0500
Subject: [coreboot] [PATCH] Support for Intel Modular BIOS Interface
 support on i830
In-Reply-To: <4B8AC17C.3010808@coresystems.de>
References: <4B8AC17C.3010808@coresystems.de>
Message-ID: <4B8B4D83.4040702@settoplinux.org>

On 02/28/2010 02:18 PM, Stefan Reinauer wrote:
> See patch.
>
looks like you have CONFIG_CONFIG_PCI_OPTION_ROM_RUN_YABEL in a few 
spots. Shouldn't there inly be one CONFIG 
(CONFIG_PCI_OPTION_ROM_RUN_YABEL) ?

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



From Zheng.Bao at amd.com  Mon Mar  1 06:35:26 2010
From: Zheng.Bao at amd.com (Bao, Zheng)
Date: Mon, 1 Mar 2010 13:35:26 +0800
Subject: [coreboot] [patch] RE: Fam10 breakage
In-Reply-To: <48E56E69-70E4-4885-A19E-FEB3A99F02D7@coresystems.de>
References: <2831fecf1002241327v19493c8dq1891384716765a13@mail.gmail.com>,
	<2831fecf1002241448o298638d1v2baeb69e9e2c7cd9@mail.gmail.com>,
	<DD1CC71B621B004FA76856E5129D6B17037D25AB@sbjgexmb1.amd.com>,
	<2831fecf1002250711l1ec9d640p7ee35aeca02ffcf3@mail.gmail.com>,
	<DD1CC71B621B004FA76856E5129D6B17037D2948@sbjgexmb1.amd.com>,
	<4B87C4E8.8000600@georgi-clan.de>,
	<2831fecf1002260614g38565a2amcfde229241798755@mail.gmail.com>,
	<4B87DCBE.6080703@georgi-clan.de>,
	<2831fecf1002260735r57ca0895nb144a94e7385941@mail.gmail.com>,
	<4B882E0A.10304@georgi-clan.de>,
	<2831fecf1002261232p22880cd3g41c38f0119163187@mail.gmail.com><COL112-W22300097A8B5852F670940CD3D0@phx.gbl>
	<48E56E69-70E4-4885-A19E-FEB3A99F02D7@coresystems.de>
Message-ID: <DD1CC71B621B004FA76856E5129D6B17037D2DB8@sbjgexmb1.amd.com>

I have tried. But it makes no difference.
00000030 A CONFIG_MAX_CPUS
...............
00008000 A CONFIG_STACK_SIZE
...............
00228500 A _ebss
00228500 A _end
00230000 A _stack
00238000 A _estack
00238000 A _heap
002f8000 A _eheap
002f8000 A _eram_seg

Zheng


________________________________________
From: coreboot-bounces at coreboot.org [mailto:coreboot-bounces at coreboot.org] On Behalf Of Stefan Reinauer
Sent: Sunday, February 28, 2010 5:27 PM
To: Zheng Bao
Cc: coreboot at coreboot.org; <mylesgw at gmail.com>
Subject: Re: [coreboot] [patch] RE: Fam10 breakage

Have you tried compiling with the reference cross compiler from util/crossgcc??

Stefan

On 28.02.2010, at 04:52, Zheng Bao <fishbaoz at hotmail.com> wrote:
Unfortunately, it doesn't fix my problem here. It is the coreboot_ram.map
of serengeti_cheetah_fam10 built on my machine. The _estack is not
what we expect. Myles, what is the result at you machine?
?
00000030 A CONFIG_MAX_CPUS
...............
00002000 A CONFIG_STACK_SIZE
...............
00228550 A _ebss
00228550 A _end
0022a000 A _stack
0022c000 A _estack
0022c000 A _heap
002ec000 A _eheap
002ec000 A _eram_seg
01000000 A CONFIG_RAMTOP
04000000 A CONFIG_AGP_APERTURE_SIZE
fff80000 A CONFIG_XIP_ROM_BASE
ffff0000 A CONFIG_ROMBASE

?
Zheng
?
________________________________________
Date: Fri, 26 Feb 2010 13:32:49 -0700
From: mylesgw at gmail.com
To: patrick at georgi-clan.de
CC: coreboot at coreboot.org
Subject: Re: [coreboot] [patch] RE: Fam10 breakage


On Fri, Feb 26, 2010 at 1:24 PM, Patrick Georgi <patrick at georgi-clan.de> wrote:
Am 26.02.2010 16:35, schrieb Myles Watson:
> For me, the only change that needs to be made is:
>
> - ? ? ? ? ? . = ((CONFIG_CONSOLE_VGA ||
> CONFIG_PCI_ROM_RUN)&&(CONFIG_RAMBASE<0x100000)&&(CONFIG_RAMTOP>0x100000)
> ) ? CONFIG_STACK_SIZE : (CONFIG_MAX_CPUS*CONFIG_STACK_SIZE);
>
> + ? ? ? ? ? . += ((CONFIG_CONSOLE_VGA ||
> CONFIG_PCI_ROM_RUN)&&(CONFIG_RAMBASE<0x100000)&&(CONFIG_RAMTOP>0x100000)
> ) ? CONFIG_STACK_SIZE : (CONFIG_MAX_CPUS*CONFIG_STACK_SIZE);
>
> Removing the .stack construct makes no difference.
>
> I like the idea of minimizing the change.
Sounds good, and should be stable (unless that's part of the bug Zheng
Bao is experiencing).

I'd say, commit this (as it fixes things for you). If it's not enough,
we can do the full change.
Great.
?
Acked-by: Patrick Georgi <patrick.georgi at coresystems.de>
Rev 5166.

Thanks,
Myles
________________________________________
Hotmail: Trusted email with powerful SPAM protection. Sign up now. 
-- 
coreboot mailing list: coreboot at coreboot.org
http://www.coreboot.org/mailman/listinfo/coreboot




From Zheng.Bao at amd.com  Mon Mar  1 06:42:53 2010
From: Zheng.Bao at amd.com (Bao, Zheng)
Date: Mon, 1 Mar 2010 13:42:53 +0800
Subject: [coreboot] [patch] RE: Fam10 breakage
In-Reply-To: <2831fecf1002272040x4d45ded2k7f1b723cb0178e52@mail.gmail.com>
References: <2831fecf1002241327v19493c8dq1891384716765a13@mail.gmail.com><2831fecf1002250711l1ec9d640p7ee35aeca02ffcf3@mail.gmail.com><DD1CC71B621B004FA76856E5129D6B17037D2948@sbjgexmb1.amd.com><4B87C4E8.8000600@georgi-clan.de><2831fecf1002260614g38565a2amcfde229241798755@mail.gmail.com><4B87DCBE.6080703@georgi-clan.de><2831fecf1002260735r57ca0895nb144a94e7385941@mail.gmail.com><4B882E0A.10304@georgi-clan.de><2831fecf1002261232p22880cd3g41c38f0119163187@mail.gmail.com><COL112-W22300097A8B5852F670940CD3D0@phx.gbl>
	<2831fecf1002272040x4d45ded2k7f1b723cb0178e52@mail.gmail.com>
Message-ID: <DD1CC71B621B004FA76856E5129D6B17037D2DC4@sbjgexmb1.amd.com>

It doesn't matter whether it is a huge stack. The _estack - _stack should be 
MAX_CPUS * STACK_SIZE. The MAX_CPU could be set as 4, and STACK_SIZE could be 0x2000. So the stack is only 0x8000. Is it huge? But checking my coreboot_ram.map, _estack - _stack is only ONE STACK_SIZE. But the loader has no idea about that. The stack will overlap other section of data. I believe many other build machine will produce the same result with me.

I have tried compiling with the reference cross compiler from util/crossgcc, and it make no difference.

Zheng

________________________________________
From: coreboot-bounces at coreboot.org [mailto:coreboot-bounces at coreboot.org] On Behalf Of Myles Watson
Sent: Sunday, February 28, 2010 12:41 PM
To: Zheng Bao
Cc: coreboot at coreboot.org
Subject: Re: [coreboot] [patch] RE: Fam10 breakage


2010/2/27 Zheng Bao <fishbaoz at hotmail.com>
Unfortunately, it doesn't fix my problem here. It is the coreboot_ram.map
of serengeti_cheetah_fam10 built on my machine. The _estack is not
what we expect. Myles, what is the result at you machine?
?002284a0 A _ebss
?002284a0 A _end
?00230000 A _stack
?00530000 A _estack
?00530000 A _heap
?005f0000 A _eheap
?005f0000 A _eram_seg

So it worked for me.

I think we should just get rid of the complexity.? I don't think there are any boards with lots of APs and huge stack needs that start below 1M, so the check that is breaking for you doesn't help anyone.

Thanks,
Myles




From Zheng.Bao at amd.com  Mon Mar  1 06:53:10 2010
From: Zheng.Bao at amd.com (Bao, Zheng)
Date: Mon, 1 Mar 2010 13:53:10 +0800
Subject: [coreboot] [PATCH]: Disable ExtINT in ioapic.c
In-Reply-To: <4B68D414.9030500@coresystems.de>
References: <DD1CC71B621B004FA76856E5129D6B17036DA956@sbjgexmb1.amd.com>
	<4B68D414.9030500@coresystems.de>
Message-ID: <DD1CC71B621B004FA76856E5129D6B17037D2DD5@sbjgexmb1.amd.com>

I tried other board. The K8+rs690+sb600 and k8+rs780+sb700 don't work on
current version, while fam10+rs780+sb700 works. I doubt that it has
something to do the spurious interrupt or timer interrupt. I don't know.
Do you have any idea?

Zheng

-----Original Message-----
From: coreboot-bounces at coreboot.org
[mailto:coreboot-bounces at coreboot.org] On Behalf Of Stefan Reinauer
Sent: Wednesday, February 03, 2010 9:41 AM
To: coreboot at coreboot.org
Subject: Re: [coreboot] [PATCH]: Disable ExtINT in ioapic.c

On 2/2/10 4:25 AM, Bao, Zheng wrote:
> Index: src/arch/i386/smp/ioapic.c
> ===================================================================
> --- src/arch/i386/smp/ioapic.c	(revision 5073)
> +++ src/arch/i386/smp/ioapic.c	(working copy)
> @@ -110,7 +110,7 @@
>  #endif
>  
>  	/* Enable Virtual Wire Mode */
> -	low = ENABLED | TRIGGER_EDGE | POLARITY_HIGH | PHYSICAL_DEST |
> ExtINT;
> +	low = DISABLED;
>  	high = bsp_lapicid << (56 - 32);
>  
>  	io_apic_write(ioapic_base, 0x10, low);
>   

Hm.. This will break quite some other boards...

Is there any particular reason why the dbm690t will not work in virtual
wire mode?

I think either the sb600 code should call clear_ioapic() instead of
setup_ioapic() or (maybe better) the setup_ioapic() function should get
an additional parameter virtual_wire

Anyways, maybe we should try to unify clear_ioapic and setup_ioapic

(also, the function should create a device node and append it to the
bridge it is called from)

Stefan


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





From mailbox at sergio.spb.ru  Mon Mar  1 00:54:32 2010
From: mailbox at sergio.spb.ru (sergio)
Date: Mon, 01 Mar 2010 02:54:32 +0300
Subject: [coreboot] biostar TA690G AM2 and TA770 A2+
Message-ID: <4B8B0238.5050300@sergio.spb.ru>

Hello.

I have two biostar mainboards on which I'd like to try coreboot.
They are not in supported mainboards list, but northbridges, 
southbridges and super I/Os looks like be supported.

The first mainboard is:
vendor: biostar
model: TA690G AM2
northbridge: AMD 690G (I'm not absolutely sure)
southbridge: AMD SB600 (I'm not absolutely sure)
cpu: AMD Athlon(tm) X2 Dual Core Processor BE-2300
Super I/O: "ITE IT8716F-S" this is written on the chip (superiotool says 
ITE IT8716F)
BIOS device: PMC Pm49FL004T-33JCE (flashrom -V looks like can't detect 
bios, but flashrom -r says PMC Pm49FL004)
url: http://www.biostar.com.tw/app/en/mb/content.php?S_ID=17

The second mainboard is:
vendor: biostar
model: TA770 A2+
northbridge: AMD 770 (I'm not absolutely sure)
southbridge: AMD SB600 (I'm not absolutely sure)
cpu: AMD Athlon(tm) 64 X2 Dual Core Processor 5200+
Super I/O: ITE IT8718F (from superiotool r5050)
BIOS device: Winbond W25x80
url: http://www.biostar.com.tw/app/en/mb/content.php?S_ID=310

Both motherboards were successfully flashed several times with flashrom 
for original bios.

Have I chance to run coreboot on this mainboards?

-- 
sergio.
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: TA690G.flashrom-V
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20100301/7fcb83ec/attachment.ksh>
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: TA690G.lspci-tvnn
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20100301/7fcb83ec/attachment-0001.ksh>
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: TA690G.superiotool-dV
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20100301/7fcb83ec/attachment-0002.ksh>
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: TA770.flashrom-V
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20100301/7fcb83ec/attachment-0003.ksh>
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: TA770.lspci-tvnn
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20100301/7fcb83ec/attachment-0004.ksh>
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: TA770.superiotool-dV
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20100301/7fcb83ec/attachment-0005.ksh>

From jordan at cosmicpenguin.net  Mon Mar  1 05:55:40 2010
From: jordan at cosmicpenguin.net (Jordan Crouse)
Date: Sun, 28 Feb 2010 21:55:40 -0700
Subject: [coreboot] [PATCH] cbfs, smaller api, more types
In-Reply-To: <4B8935BE.3080404@coresystems.de>
References: <4B890743.4000608@coresystems.de>	<20100227135740.3611.qmail@stuge.se>	<4B892F1D.8010106@coresystems.de>
	<20100227145117.12549.qmail@stuge.se>
	<4B8935BE.3080404@coresystems.de>
Message-ID: <4B8B48CC.9060500@cosmicpenguin.net>

Stefan Reinauer wrote:
> Jordan, what do you think? Would it make sense to drop either name or
> type from CBFS? I am hesitating, but maybe you have some reasons to
> definitely keep it?

I feel silly speaking like I'm a guru that somebody climbed a mountain 
to consult with, but here we go.

I think it is okay to just use name matching.  My intent with the type 
was to have an integer that could be quickly parsed in a ROM for Bayou - 
"Give me all the payloads" or some such.  I realize  that isn't as 
flexible as the names, so if everybody can agree on standard extensions 
and the extra processing time to parse the string, then carry on.

Please leave a banana in the bowl on your way out.

Jordan

> On 2/27/10 3:51 PM, Peter Stuge wrote:
>> Stefan Reinauer wrote:
>>   
>>> Since we only do name based matching in coreboot anyways, do you
>>> suggest we drop the type field?
>>>     
>> Well, yes, I think I am..
>>
>> I know there are cases when it's handy to inspect the type, but
>> unless the type is the _only_ thing that matters it isn't so
>> intuitive to have one at all.
>>
>> What do you think?
>>   
> * Payloads may want to optimize their walking using the type.
> * in case of some file types it may be interesting to load all of a type
> from cbfs (ie. public crypto keys)
> * I think Kevin might not like that idea. He's using the type in SeaBIOS.
> * Maybe SeaBIOS can be changed? Who will do that?
> * Maybe we should keep the type on the cbfstool command line so we can
> keep the additional error checking it allows us, but keep it out of the
> coreboot file format.
> 
> So I think we should keep it for now and keep the possibility to drop it
> in mind.
> 
> 




From patrick at georgi-clan.de  Mon Mar  1 08:39:17 2010
From: patrick at georgi-clan.de (Patrick Georgi)
Date: Mon, 01 Mar 2010 08:39:17 +0100
Subject: [coreboot] [patch] RE: Fam10 breakage
In-Reply-To: <DD1CC71B621B004FA76856E5129D6B17037D2DC4@sbjgexmb1.amd.com>
References: <2831fecf1002241327v19493c8dq1891384716765a13@mail.gmail.com><2831fecf1002250711l1ec9d640p7ee35aeca02ffcf3@mail.gmail.com><DD1CC71B621B004FA76856E5129D6B17037D2948@sbjgexmb1.amd.com><4B87C4E8.8000600@georgi-clan.de><2831fecf1002260614g38565a2amcfde229241798755@mail.gmail.com><4B87DCBE.6080703@georgi-clan.de><2831fecf1002260735r57ca0895nb144a94e7385941@mail.gmail.com><4B882E0A.10304@georgi-clan.de><2831fecf1002261232p22880cd3g41c38f0119163187@mail.gmail.com><COL112-W22300097A8B5852F670940CD3D0@phx.gbl>	<2831fecf1002272040x4d45ded2k7f1b723cb0178e52@mail.gmail.com>
	<DD1CC71B621B004FA76856E5129D6B17037D2DC4@sbjgexmb1.amd.com>
Message-ID: <4B8B6F25.6070106@georgi-clan.de>

Am 01.03.2010 06:42, schrieb Bao, Zheng:
> It doesn't matter whether it is a huge stack. The _estack - _stack
> should be MAX_CPUS * STACK_SIZE. The MAX_CPU could be set as 4, and
> STACK_SIZE could be 0x2000. So the stack is only 0x8000. Is it huge?
> But checking my coreboot_ram.map, _estack - _stack is only ONE
> STACK_SIZE. But the loader has no idea about that. The stack will
> overlap other section of data. I believe many other build machine
> will produce the same result with me.
The main issue I see is that weird rule to decide whether to use one
stack or many - it doesn't really make sense.

The only place where multiple stacks seem to be setup is
src/cpu/x86/lapic/lapic_cpu_init.c (look for estack in that file). That
place really indicates that the ldscript rule does the wrong thing:
No matter if that weird conditional holds true, multiple stacks are set
up, just in different ways, with special behaviour if the stacks are
split between <1MB and >1MB memory.

So I can only support Myles' proposal to make the linker script line
 . += CONFIG_MAX_CPUS * CONFIG_STACK_SIZE
without any cleverness. I believe that the line as it is in the linker
script is wrong. From looking at the behaviour in the mentioned C file,
it should decide between MAX_CPUS * STACK_SIZE and some more complex
rule that creates a stack at >1MB. Something like:

(I'm not proposing to add this to the linker script!)
. += ((CONFIG_RAMTOP>0x100000) && (CONFIG_RAMBASE < 0x100000) &&
((CONFIG_CONSOLE_VGA==1) || (CONFIG_PCI_ROM_RUN == 1)))?(0x100000+(20480
+ CONFIG_STACK_SIZE)*CONFIG_MAX_CPUS - (CONFIG_STACK_SIZE*index) -
.):(CONFIG_STACK_SIZE*CONFIG_MAX_CPUS);

There are a couple of boards with RAMBASE<1MB and RAMTOP >1MB.
(amd_db800, amd_norwich, artecgroup_dbe61, bcom_winnetp680,
digitallogic_msm800sev, iei_pcisa-lx-800-r10, jetway_j7f24,
lippert_roadrunner-lx, lippert_spacerunner-lx, pcengines_alix1c,
technexion_tim5690, via_epia-cn, via_epia, via_epia-m700, via_epia-m,
via_epia-n, via_pc2500e, via_vt8454c, winent_pl6064)

Only one of them actually has MAX_CPUS > 1, technexion/tim5690, so once
that one is changed to have RAMBASE >= 1MB, we could drop this special
rule without side effect (except for avoiding a linker bug and being
able to simplify the code)


Patrick



From svn at coreboot.org  Mon Mar  1 08:42:02 2010
From: svn at coreboot.org (repository service)
Date: Mon, 01 Mar 2010 08:42:02 +0100
Subject: [coreboot] [commit] r5176 - in trunk/src: arch/i386
	mainboard/amd/serengeti_cheetah
	mainboard/amd/serengeti_cheetah_fam10 mainboard/iwill/dk8_htx
	mainboard/tyan/s2912 mainboard/tyan/s2912_fam10
Message-ID: <E1Nm0GQ-0003lz-OX@ra.coresystems.de>

Author: oxygene
Date: Mon Mar  1 08:42:02 2010
New Revision: 5176
URL: http://tracker.coreboot.org/trac/coreboot/changeset/5176

Log:
- Add rules that build either 4 or 5 ssdts (only those variants exist in the board now)
- Change ACPI_SSDTX_NUM to either 4 or 5 for boards that have ssdtX.asl
  files, according to the number of ssdtX.asl there.
- Remove custom ssdt rules

Signed-off-by: Patrick Georgi <patrick.georgi at coresystems.de>
Acked-by: Peter Stuge <peter at stuge.se>

Deleted:
   trunk/src/mainboard/iwill/dk8_htx/Makefile.inc
Modified:
   trunk/src/arch/i386/Makefile.inc
   trunk/src/mainboard/amd/serengeti_cheetah/Kconfig
   trunk/src/mainboard/amd/serengeti_cheetah/Makefile.inc
   trunk/src/mainboard/amd/serengeti_cheetah_fam10/Kconfig
   trunk/src/mainboard/amd/serengeti_cheetah_fam10/Makefile.inc
   trunk/src/mainboard/iwill/dk8_htx/Kconfig
   trunk/src/mainboard/tyan/s2912/Kconfig
   trunk/src/mainboard/tyan/s2912_fam10/Kconfig

Modified: trunk/src/arch/i386/Makefile.inc
==============================================================================
--- trunk/src/arch/i386/Makefile.inc	Sun Feb 28 21:56:42 2010	(r5175)
+++ trunk/src/arch/i386/Makefile.inc	Mon Mar  1 08:42:02 2010	(r5176)
@@ -202,6 +202,15 @@
 ifeq ($(CONFIG_GENERATE_ACPI_TABLES),y)
 objs += $(obj)/mainboard/$(MAINBOARDDIR)/acpi_tables.o
 objs += $(obj)/mainboard/$(MAINBOARDDIR)/dsdt.o
+# make doesn't have arithmetic operators or greater-than comparisons
+ifeq ($(subst 5,4,$(CONFIG_ACPI_SSDTX_NUM)),4)
+objs += $(obj)/mainboard/$(MAINBOARDDIR)/ssdt2.o
+objs += $(obj)/mainboard/$(MAINBOARDDIR)/ssdt3.o
+objs += $(obj)/mainboard/$(MAINBOARDDIR)/ssdt4.o
+endif
+ifeq ($(CONFIG_ACPI_SSDTX_NUM),5)
+objs += $(obj)/mainboard/$(MAINBOARDDIR)/ssdt5.o
+endif
 ifeq ($(CONFIG_BOARD_HAS_FADT),y)
 objs += $(obj)/mainboard/$(MAINBOARDDIR)/fadt.o
 endif

Modified: trunk/src/mainboard/amd/serengeti_cheetah/Kconfig
==============================================================================
--- trunk/src/mainboard/amd/serengeti_cheetah/Kconfig	Sun Feb 28 21:56:42 2010	(r5175)
+++ trunk/src/mainboard/amd/serengeti_cheetah/Kconfig	Mon Mar  1 08:42:02 2010	(r5176)
@@ -128,5 +128,5 @@
 
 config ACPI_SSDTX_NUM
 	int
-	default 1
+	default 4
 	depends on BOARD_AMD_SERENGETI_CHEETAH

Modified: trunk/src/mainboard/amd/serengeti_cheetah/Makefile.inc
==============================================================================
--- trunk/src/mainboard/amd/serengeti_cheetah/Makefile.inc	Sun Feb 28 21:56:42 2010	(r5175)
+++ trunk/src/mainboard/amd/serengeti_cheetah/Makefile.inc	Mon Mar  1 08:42:02 2010	(r5176)
@@ -17,9 +17,4 @@
 ## Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA
 ##
 
-# Needed by irq_tables and mptable and acpi_tables.
-obj-$(CONFIG_GENERATE_ACPI_TABLES) += ssdt2.o
-obj-$(CONFIG_GENERATE_ACPI_TABLES) += ssdt3.o
-obj-$(CONFIG_GENERATE_ACPI_TABLES) += ssdt4.o
-
 obj-y += ../../../drivers/i2c/i2cmux/i2cmux.o

Modified: trunk/src/mainboard/amd/serengeti_cheetah_fam10/Kconfig
==============================================================================
--- trunk/src/mainboard/amd/serengeti_cheetah_fam10/Kconfig	Sun Feb 28 21:56:42 2010	(r5175)
+++ trunk/src/mainboard/amd/serengeti_cheetah_fam10/Kconfig	Mon Mar  1 08:42:02 2010	(r5176)
@@ -116,7 +116,7 @@
 
 config ACPI_SSDTX_NUM
 	int
-	default 31
+	default 5
 	depends on BOARD_AMD_SERENGETI_CHEETAH_FAM10
 
 config MAINBOARD_PCI_SUBSYSTEM_DEVICE_ID

Modified: trunk/src/mainboard/amd/serengeti_cheetah_fam10/Makefile.inc
==============================================================================
--- trunk/src/mainboard/amd/serengeti_cheetah_fam10/Makefile.inc	Sun Feb 28 21:56:42 2010	(r5175)
+++ trunk/src/mainboard/amd/serengeti_cheetah_fam10/Makefile.inc	Mon Mar  1 08:42:02 2010	(r5176)
@@ -17,12 +17,4 @@
 ## Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA
 ##
 
-# Needed by irq_tables and mptable and acpi_tables.
-
-# ./ssdt.o is in northbridge/amd/amdfam10/Makefile.inc
-obj-$(CONFIG_GENERATE_ACPI_TABLES) += ssdt2.o
-obj-$(CONFIG_GENERATE_ACPI_TABLES) += ssdt3.o
-obj-$(CONFIG_GENERATE_ACPI_TABLES) += ssdt4.o
-obj-$(CONFIG_GENERATE_ACPI_TABLES) += ssdt5.o
-
 obj-y += ../../../drivers/i2c/i2cmux2/i2cmux2.o

Modified: trunk/src/mainboard/iwill/dk8_htx/Kconfig
==============================================================================
--- trunk/src/mainboard/iwill/dk8_htx/Kconfig	Sun Feb 28 21:56:42 2010	(r5175)
+++ trunk/src/mainboard/iwill/dk8_htx/Kconfig	Mon Mar  1 08:42:02 2010	(r5176)
@@ -122,5 +122,5 @@
 
 config ACPI_SSDTX_NUM
 	int
-	default 3
+	default 5
 	depends on BOARD_IWILL_DK8_HTX

Modified: trunk/src/mainboard/tyan/s2912/Kconfig
==============================================================================
--- trunk/src/mainboard/tyan/s2912/Kconfig	Sun Feb 28 21:56:42 2010	(r5175)
+++ trunk/src/mainboard/tyan/s2912/Kconfig	Mon Mar  1 08:42:02 2010	(r5176)
@@ -140,8 +140,3 @@
 	int
 	default 11
 	depends on BOARD_TYAN_S2912
-
-config ACPI_SSDTX_NUM
-	int
-	default 3
-	depends on BOARD_TYAN_S2912

Modified: trunk/src/mainboard/tyan/s2912_fam10/Kconfig
==============================================================================
--- trunk/src/mainboard/tyan/s2912_fam10/Kconfig	Sun Feb 28 21:56:42 2010	(r5175)
+++ trunk/src/mainboard/tyan/s2912_fam10/Kconfig	Mon Mar  1 08:42:02 2010	(r5176)
@@ -153,11 +153,6 @@
 	default n
 	depends on BOARD_TYAN_S2912_FAM10
 
-config ACPI_SSDTX_NUM
-	int
-	default 31
-	depends on BOARD_TYAN_S2912_FAM10
-
 config RAMBASE
 	hex
 	default 0x200000



From patrick at georgi-clan.de  Mon Mar  1 09:11:23 2010
From: patrick at georgi-clan.de (Patrick Georgi)
Date: Mon, 01 Mar 2010 09:11:23 +0100
Subject: [coreboot] [patch] RE: Fam10 breakage
In-Reply-To: <DD1CC71B621B004FA76856E5129D6B17037D2E91@sbjgexmb1.amd.com>
References: <2831fecf1002241327v19493c8dq1891384716765a13@mail.gmail.com><2831fecf1002250711l1ec9d640p7ee35aeca02ffcf3@mail.gmail.com><DD1CC71B621B004FA76856E5129D6B17037D2948@sbjgexmb1.amd.com><4B87C4E8.8000600@georgi-clan.de><2831fecf1002260614g38565a2amcfde229241798755@mail.gmail.com><4B87DCBE.6080703@georgi-clan.de><2831fecf1002260735r57ca0895nb144a94e7385941@mail.gmail.com><4B882E0A.10304@georgi-clan.de><2831fecf1002261232p22880cd3g41c38f0119163187@mail.gmail.com><COL112-W22300097A8B5852F670940CD3D0@phx.gbl>	<2831fecf1002272040x4d45ded2k7f1b723cb0178e52@mail.gmail.com><DD1CC71B621B004FA76856E5129D6B17037D2DC4@sbjgexmb1.amd.com>
	<4B8B6F25.6070106@georgi-clan.de>
	<DD1CC71B621B004FA76856E5129D6B17037D2E91@sbjgexmb1.amd.com>
Message-ID: <4B8B76AB.6080402@georgi-clan.de>

Am 01.03.2010 09:00, schrieb Bao, Zheng:
> What I keep trying to make everyone understand is not what the rules we
> should use to decide the stack size.
By now, I'm quite certain that the rule is wrong.
Binutils bug or not.

> What I worry is the bug in the
> crosstool will make the rule do the wrong thing, even if the rule is
> perfect. 
Is that only in crossgcc or also in other binutils (eg. by distributions)?

> So far, no one seems to support me that there is a bug in the
> toolchain. I admit it seems ridiculous But the it is quite clear.
If it's a bug (and yes, it definitely looks like that), we can report it
to upstream. That does not (in itself) fix broken boards.


Patrick



From Zheng.Bao at amd.com  Mon Mar  1 09:00:09 2010
From: Zheng.Bao at amd.com (Bao, Zheng)
Date: Mon, 1 Mar 2010 16:00:09 +0800
Subject: [coreboot] [patch] RE: Fam10 breakage
In-Reply-To: <4B8B6F25.6070106@georgi-clan.de>
References: <2831fecf1002241327v19493c8dq1891384716765a13@mail.gmail.com><2831fecf1002250711l1ec9d640p7ee35aeca02ffcf3@mail.gmail.com><DD1CC71B621B004FA76856E5129D6B17037D2948@sbjgexmb1.amd.com><4B87C4E8.8000600@georgi-clan.de><2831fecf1002260614g38565a2amcfde229241798755@mail.gmail.com><4B87DCBE.6080703@georgi-clan.de><2831fecf1002260735r57ca0895nb144a94e7385941@mail.gmail.com><4B882E0A.10304@georgi-clan.de><2831fecf1002261232p22880cd3g41c38f0119163187@mail.gmail.com><COL112-W22300097A8B5852F670940CD3D0@phx.gbl>	<2831fecf1002272040x4d45ded2k7f1b723cb0178e52@mail.gmail.com><DD1CC71B621B004FA76856E5129D6B17037D2DC4@sbjgexmb1.amd.com>
	<4B8B6F25.6070106@georgi-clan.de>
Message-ID: <DD1CC71B621B004FA76856E5129D6B17037D2E91@sbjgexmb1.amd.com>

What I keep trying to make everyone understand is not what the rules we
should use to decide the stack size. What I worry is the bug in the
crosstool will make the rule do the wrong thing, even if the rule is
perfect. So far, no one seems to support me that there is a bug in the
toolchain. I admit it seems ridiculous But the it is quite clear.

Zheng


-----Original Message-----
From: coreboot-bounces at coreboot.org
[mailto:coreboot-bounces at coreboot.org] On Behalf Of Patrick Georgi
Sent: Monday, March 01, 2010 3:39 PM
To: coreboot at coreboot.org
Subject: Re: [coreboot] [patch] RE: Fam10 breakage

Am 01.03.2010 06:42, schrieb Bao, Zheng:
> It doesn't matter whether it is a huge stack. The _estack - _stack
> should be MAX_CPUS * STACK_SIZE. The MAX_CPU could be set as 4, and
> STACK_SIZE could be 0x2000. So the stack is only 0x8000. Is it huge?
> But checking my coreboot_ram.map, _estack - _stack is only ONE
> STACK_SIZE. But the loader has no idea about that. The stack will
> overlap other section of data. I believe many other build machine
> will produce the same result with me.
The main issue I see is that weird rule to decide whether to use one
stack or many - it doesn't really make sense.

The only place where multiple stacks seem to be setup is
src/cpu/x86/lapic/lapic_cpu_init.c (look for estack in that file). That
place really indicates that the ldscript rule does the wrong thing:
No matter if that weird conditional holds true, multiple stacks are set
up, just in different ways, with special behaviour if the stacks are
split between <1MB and >1MB memory.

So I can only support Myles' proposal to make the linker script line
 . += CONFIG_MAX_CPUS * CONFIG_STACK_SIZE
without any cleverness. I believe that the line as it is in the linker
script is wrong. From looking at the behaviour in the mentioned C file,
it should decide between MAX_CPUS * STACK_SIZE and some more complex
rule that creates a stack at >1MB. Something like:

(I'm not proposing to add this to the linker script!)
. += ((CONFIG_RAMTOP>0x100000) && (CONFIG_RAMBASE < 0x100000) &&
((CONFIG_CONSOLE_VGA==1) || (CONFIG_PCI_ROM_RUN == 1)))?(0x100000+(20480
+ CONFIG_STACK_SIZE)*CONFIG_MAX_CPUS - (CONFIG_STACK_SIZE*index) -
.):(CONFIG_STACK_SIZE*CONFIG_MAX_CPUS);

There are a couple of boards with RAMBASE<1MB and RAMTOP >1MB.
(amd_db800, amd_norwich, artecgroup_dbe61, bcom_winnetp680,
digitallogic_msm800sev, iei_pcisa-lx-800-r10, jetway_j7f24,
lippert_roadrunner-lx, lippert_spacerunner-lx, pcengines_alix1c,
technexion_tim5690, via_epia-cn, via_epia, via_epia-m700, via_epia-m,
via_epia-n, via_pc2500e, via_vt8454c, winent_pl6064)

Only one of them actually has MAX_CPUS > 1, technexion/tim5690, so once
that one is changed to have RAMBASE >= 1MB, we could drop this special
rule without side effect (except for avoiding a linker bug and being
able to simplify the code)


Patrick

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





From svn at coreboot.org  Mon Mar  1 09:34:19 2010
From: svn at coreboot.org (repository service)
Date: Mon, 01 Mar 2010 09:34:19 +0100
Subject: [coreboot] [commit] r5177 - in trunk: src src/arch/i386 src/devices
	src/include src/lib src/mainboard/rca/rm4100
	src/mainboard/thomson/ip1000 src/northbridge/intel/i82830
	src/southbridge/intel/i82801dx util/c...
Message-ID: <E1Nm151-0001To-Jb@ra.coresystems.de>

Author: stepan
Date: Mon Mar  1 09:34:19 2010
New Revision: 5177
URL: http://tracker.coreboot.org/trac/coreboot/changeset/5177

Log:
This patch implements MBI (modular bios interface) support to the i830 chipset.
This is needed on the IP1000T to get VGA output. The VGA option rom will ask
through an SMI for hardware specifics (in form of a VBT, video bios table)
which the SMI handler copies into the VGA option rom. 

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

Added:
   trunk/src/mainboard/rca/rm4100/mainboard_smi.c
   trunk/src/mainboard/thomson/ip1000/mainboard_smi.c
   trunk/src/northbridge/intel/i82830/i82830_smihandler.c
   trunk/src/southbridge/intel/i82801dx/i82801dx_nvs.h
   trunk/src/southbridge/intel/i82801dx/i82801dx_smi.c
   trunk/src/southbridge/intel/i82801dx/i82801dx_smihandler.c
   trunk/src/southbridge/intel/i82801dx/i82801dx_tco_timer.c
Modified:
   trunk/src/Kconfig
   trunk/src/arch/i386/Makefile.inc
   trunk/src/devices/Kconfig
   trunk/src/include/cbfs.h
   trunk/src/lib/Makefile.inc
   trunk/src/lib/cbfs.c
   trunk/src/mainboard/rca/rm4100/Kconfig
   trunk/src/mainboard/rca/rm4100/Makefile.inc
   trunk/src/mainboard/rca/rm4100/devicetree.cb
   trunk/src/mainboard/rca/rm4100/mainboard.c
   trunk/src/mainboard/rca/rm4100/romstage.c
   trunk/src/mainboard/thomson/ip1000/Kconfig
   trunk/src/mainboard/thomson/ip1000/Makefile.inc
   trunk/src/mainboard/thomson/ip1000/devicetree.cb
   trunk/src/mainboard/thomson/ip1000/mainboard.c
   trunk/src/mainboard/thomson/ip1000/romstage.c
   trunk/src/northbridge/intel/i82830/Makefile.inc
   trunk/src/northbridge/intel/i82830/northbridge.c
   trunk/src/northbridge/intel/i82830/raminit.c
   trunk/src/northbridge/intel/i82830/vga.c
   trunk/src/southbridge/intel/i82801dx/Kconfig
   trunk/src/southbridge/intel/i82801dx/Makefile.inc
   trunk/src/southbridge/intel/i82801dx/i82801dx_ac97.c
   trunk/util/cbfstool/cbfs.h
   trunk/util/cbfstool/common.c
   trunk/util/x86emu/yabel/vbe.c

Modified: trunk/src/Kconfig
==============================================================================
--- trunk/src/Kconfig	Mon Mar  1 08:42:02 2010	(r5176)
+++ trunk/src/Kconfig	Mon Mar  1 09:34:19 2010	(r5177)
@@ -447,6 +447,66 @@
 	  the "0x" prefix) and 3230 specifies the PCI device ID of the
 	  video card (also in hex, without "0x" prefix).
 
+config INTEL_MBI
+	bool "Add an MBI image"
+	depends on NORTHBRIDGE_INTEL_I82830
+	help
+	  Select this option if you have an Intel MBI image that you would
+	  like to add to your ROM.
+
+	  You will be able to specify the location and file name of the
+	  image later.
+
+config FALLBACK_MBI_FILE
+	string "Intel MBI path and filename"
+	depends on INTEL_MBI
+	default "mbi.bin"
+	help
+	  The path and filename of the file to use as VGA BIOS.
+
+endmenu
+
+menu "Bootsplash"
+	depends on PCI_OPTION_ROM_RUN_YABEL
+
+config BOOTSPLASH
+	prompt "Show graphical bootsplash"
+	bool
+	depends on PCI_OPTION_ROM_RUN_YABEL
+	help
+	  This option shows a graphical bootsplash screen. The grapics are
+	  loaded from the CBFS file bootsplash.jpg.
+
+config FALLBACK_BOOTSPLASH_FILE
+	string "Bootsplash path and filename"
+	depends on BOOTSPLASH
+	default "bootsplash.jpg"
+	help
+	  The path and filename of the file to use as graphical bootsplash 
+	  screen. The file format has to be jpg. 
+
+# TODO: Turn this into a "choice".
+config FRAMEBUFFER_VESA_MODE
+	prompt "VESA framebuffer video mode"
+	hex
+	default 0x117
+	depends on BOOTSPLASH
+	help
+	  This option sets the resolution used for the coreboot framebuffer and
+	  bootsplash screen. Set to 0x117 for 1024x768x16. A diligent soul will
+	  some day make this a "choice".
+
+config COREBOOT_KEEP_FRAMEBUFFER
+	prompt "Keep VESA framebuffer"
+	bool
+	depends on BOOTSPLASH
+	help
+	  This option keeps the framebuffer mode set after coreboot finishes
+	  execution. If this option is enabled, coreboot will pass a
+	  framebuffer entry in its coreboot table and the payload will need a
+	  framebuffer driver. If this option is disabled, coreboot will switch
+	  back to text mode before handing control to a payload.
+
 endmenu
 
 menu "Debugging"

Modified: trunk/src/arch/i386/Makefile.inc
==============================================================================
--- trunk/src/arch/i386/Makefile.inc	Mon Mar  1 08:42:02 2010	(r5176)
+++ trunk/src/arch/i386/Makefile.inc	Mon Mar  1 09:34:19 2010	(r5177)
@@ -28,6 +28,14 @@
 	@printf "    VGABIOS    $(CONFIG_FALLBACK_VGA_BIOS_FILE) $(CONFIG_FALLBACK_VGA_BIOS_ID)\n"
 	$(CBFSTOOL) $(obj)/coreboot.rom add $(CONFIG_FALLBACK_VGA_BIOS_FILE) "pci$(CONFIG_FALLBACK_VGA_BIOS_ID).rom" optionrom
 endif
+ifeq ($(CONFIG_INTEL_MBI),y)
+	@printf "    MBI        $(CONFIG_FALLBACK_MBI_FILE)\n"
+	$(CBFSTOOL) $(obj)/coreboot.rom add $(CONFIG_FALLBACK_MBI_FILE) mbi.bin mbi
+endif
+ifeq ($(CONFIG_BOOTSPLASH),y)
+	@printf "    BOOTSPLASH $(CONFIG_FALLBACK_BOOTSPLASH_FILE)\n"
+	$(CBFSTOOL) $(obj)/coreboot.rom add $(CONFIG_FALLBACK_BOOTSPLASH_FILE) bootsplash.jpg bootsplash
+endif
 	@printf "    CBFSPRINT  $(subst $(obj)/,,$(@))\n\n"
 	$(CBFSTOOL) $(obj)/coreboot.rom print
 

Modified: trunk/src/devices/Kconfig
==============================================================================
--- trunk/src/devices/Kconfig	Mon Mar  1 08:42:02 2010	(r5176)
+++ trunk/src/devices/Kconfig	Mon Mar  1 09:34:19 2010	(r5177)
@@ -167,36 +167,6 @@
 	  they can still access all devices in the system.
 	  Enable this option for a good compromise between security and speed.
 
-config BOOTSPLASH
-	prompt "Show graphical bootsplash"
-	bool
-	depends on PCI_OPTION_ROM_RUN_YABEL
-	help
-	  This option shows a graphical bootsplash screen. The grapics are
-	  loaded from the CBFS file bootsplash.jpg.
-
-# TODO: Turn this into a "choice".
-config FRAMEBUFFER_VESA_MODE
-	prompt "VESA framebuffer video mode"
-	hex
-	default 0x117
-	depends on BOOTSPLASH
-	help
-	  This option sets the resolution used for the coreboot framebuffer and
-	  bootsplash screen. Set to 0x117 for 1024x768x16. A diligent soul will
-	  some day make this a "choice".
-
-config COREBOOT_KEEP_FRAMEBUFFER
-	prompt "Keep VESA framebuffer"
-	bool
-	depends on BOOTSPLASH
-	help
-	  This option keeps the framebuffer mode set after coreboot finishes
-	  execution. If this option is enabled, coreboot will pass a
-	  framebuffer entry in its coreboot table and the payload will need a
-	  framebuffer driver. If this option is disabled, coreboot will switch
-	  back to text mode before handing control to a payload.
-
 config CONSOLE_VGA_MULTI
 	bool
 	default n

Modified: trunk/src/include/cbfs.h
==============================================================================
--- trunk/src/include/cbfs.h	Mon Mar  1 08:42:02 2010	(r5176)
+++ trunk/src/include/cbfs.h	Mon Mar  1 09:34:19 2010	(r5177)
@@ -63,9 +63,14 @@
     Users are welcome to use any other value for their
     components */
 
-#define CBFS_TYPE_STAGE     0x10
-#define CBFS_TYPE_PAYLOAD   0x20
-#define CBFS_TYPE_OPTIONROM 0x30
+#define CBFS_TYPE_STAGE      0x10
+#define CBFS_TYPE_PAYLOAD    0x20
+#define CBFS_TYPE_OPTIONROM  0x30
+#define CBFS_TYPE_BOOTSPLASH 0x40
+#define CBFS_TYPE_RAW        0x50
+#define CBFS_TYPE_VSA        0x51
+#define CBFS_TYPE_MBI        0x52
+#define CBFS_TYPE_MICROCODE  0x53
 
 /** this is the master cbfs header - it need to be
     located somewhere in the bootblock.  Where it
@@ -164,11 +169,8 @@
 void * cbfs_get_file(const char *name);
 void *cbfs_load_optionrom(u16 vendor, u16 device, void * dest);
 int run_address(void *f);
-int cbfs_decompress(int algo, void *src, void *dst, int len);
-struct cbfs_stage *cbfs_find_file(const char *name, int type);
-int cbfs_check_magic(struct cbfs_file *file);
-struct cbfs_header *cbfs_master_header(void);
 struct cbfs_file *cbfs_find(const char *name);
+void *cbfs_find_file(const char *name, int type);
 void cbfs_and_run_core(const char *filename, unsigned int ebp);
 
 #endif

Modified: trunk/src/lib/Makefile.inc
==============================================================================
--- trunk/src/lib/Makefile.inc	Mon Mar  1 08:42:02 2010	(r5176)
+++ trunk/src/lib/Makefile.inc	Mon Mar  1 09:34:19 2010	(r5177)
@@ -31,3 +31,5 @@
 ifdef POST_EVALUATION
 $(obj)/lib/version.o :: $(obj)/build.h
 endif
+
+smmobj-y += memcpy.o

Modified: trunk/src/lib/cbfs.c
==============================================================================
--- trunk/src/lib/cbfs.c	Mon Mar  1 08:42:02 2010	(r5176)
+++ trunk/src/lib/cbfs.c	Mon Mar  1 09:34:19 2010	(r5177)
@@ -24,7 +24,16 @@
 #include <lib.h>
 #include <arch/byteorder.h>
 
-int cbfs_decompress(int algo, void *src, void *dst, int len)
+
+/**
+ * Decompression wrapper for CBFS
+ * @param algo
+ * @param src
+ * @param dst
+ * @param len
+ * @return 0 on success, -1 on failure
+ */
+static int cbfs_decompress(int algo, void *src, void *dst, int len)
 {
 	switch(algo) {
 	case CBFS_COMPRESS_NONE:
@@ -44,12 +53,12 @@
 	}
 }
 
-int cbfs_check_magic(struct cbfs_file *file)
+static int cbfs_check_magic(struct cbfs_file *file)
 {
 	return !strcmp(file->magic, CBFS_FILE_MAGIC) ? 1 : 0;
 }
 
-struct cbfs_header *cbfs_master_header(void)
+static struct cbfs_header *cbfs_master_header(void)
 {
 	struct cbfs_header *header;
 
@@ -103,7 +112,7 @@
 	}
 }
 
-struct cbfs_stage *cbfs_find_file(const char *name, int type)
+void *cbfs_find_file(const char *name, int type)
 {
 	struct cbfs_file *file = cbfs_find(name);
 
@@ -123,7 +132,7 @@
 	return (void *) CBFS_SUBHEADER(file);
 }
 
-static int tohex4(unsigned int c)
+static inline int tohex4(unsigned int c)
 {
 	return (c<=9)?(c+'0'):(c-10+'a');
 }
@@ -205,11 +214,6 @@
 	return (void *) entry;
 }
 
-void * cbfs_get_file(const char *name)
-{
-	return (void *) cbfs_find(name);
-}
-
 int cbfs_execute_stage(const char *name)
 {
 	struct cbfs_stage *stage = (struct cbfs_stage *)
@@ -233,7 +237,7 @@
  * run_address is passed the address of a function taking no parameters and
  * jumps to it, returning the result. 
  * @param f the address to call as a function. 
- * returns value returned by the function. 
+ * @return value returned by the function. 
  */
 
 int run_address(void *f)

Modified: trunk/src/mainboard/rca/rm4100/Kconfig
==============================================================================
--- trunk/src/mainboard/rca/rm4100/Kconfig	Mon Mar  1 08:42:02 2010	(r5176)
+++ trunk/src/mainboard/rca/rm4100/Kconfig	Mon Mar  1 09:34:19 2010	(r5177)
@@ -9,6 +9,7 @@
 	select HAVE_PIRQ_TABLE
 	select UDELAY_TSC
 	select BOARD_ROMSIZE_KB_512
+	select HAVE_SMI_HANDLER
 
 config MAINBOARD_DIR
 	string

Modified: trunk/src/mainboard/rca/rm4100/Makefile.inc
==============================================================================
--- trunk/src/mainboard/rca/rm4100/Makefile.inc	Mon Mar  1 08:42:02 2010	(r5176)
+++ trunk/src/mainboard/rca/rm4100/Makefile.inc	Mon Mar  1 09:34:19 2010	(r5177)
@@ -1 +1,4 @@
 ROMCCFLAGS=-mcpu=p3 -O
+
+smmobj-$(CONFIG_HAVE_SMI_HANDLER) += mainboard_smi.o
+

Modified: trunk/src/mainboard/rca/rm4100/devicetree.cb
==============================================================================
--- trunk/src/mainboard/rca/rm4100/devicetree.cb	Mon Mar  1 08:42:02 2010	(r5176)
+++ trunk/src/mainboard/rca/rm4100/devicetree.cb	Mon Mar  1 09:34:19 2010	(r5177)
@@ -1,4 +1,9 @@
 chip northbridge/intel/i82830		# Northbridge
+  device apic_cluster 0 on		# APIC cluster
+    chip cpu/intel/socket_PGA370	# Mobile Celeron Micro-FCBGA Socket 479
+      device apic 0 on end		# APIC
+    end
+  end
   device pci_domain 0 on		# PCI domain
     device pci 0.0 on end		# Host bridge
     device pci 2.0 on end		# VGA (Intel 82830 CGC)
@@ -19,9 +24,7 @@
       device pci 1d.1 on end		# USB UHCI Controller #2
       device pci 1d.2 on end		# USB UHCI Controller #3
       device pci 1d.7 on end		# USB2 EHCI Controller
-      device pci 1e.0 on		# PCI bridge
-        device pci 08.0 on end		# Intel 82801DB PRO/100 VE Ethernet
-      end
+      device pci 1e.0 on end		# PCI bridge
       device pci 1f.0 on		# ISA/LPC bridge
         chip superio/smsc/smscsuperio	# Super I/O
           device pnp 2e.0 off		# Floppy
@@ -61,10 +64,5 @@
       device pci 1f.6 on end		# AC'97 modem
     end
   end
-  device apic_cluster 0 on		# APIC cluster
-    chip cpu/intel/socket_PGA370	# Mobile Celeron Micro-FCBGA Socket 479
-      device apic 0 on end		# APIC
-    end
-  end
 end
 

Modified: trunk/src/mainboard/rca/rm4100/mainboard.c
==============================================================================
--- trunk/src/mainboard/rca/rm4100/mainboard.c	Mon Mar  1 08:42:02 2010	(r5176)
+++ trunk/src/mainboard/rca/rm4100/mainboard.c	Mon Mar  1 09:34:19 2010	(r5177)
@@ -21,6 +21,18 @@
 #include <device/device.h>
 #include "chip.h"
 
+static void mainboard_init(device_t dev)
+{
+	// TODO Switch parport LEDs again
+}
+
+static void mainboard_enable(device_t dev)
+{
+	// TODO Switch parport LEDs
+	dev->ops->init = mainboard_init;
+}
+ 
 struct chip_operations mainboard_ops = {
+	.enable_dev = mainboard_enable,
 	CHIP_NAME("RCA RM4100 Mainboard")
 };

Added: trunk/src/mainboard/rca/rm4100/mainboard_smi.c
==============================================================================
--- /dev/null	00:00:00 1970	(empty, because file is newly added)
+++ trunk/src/mainboard/rca/rm4100/mainboard_smi.c	Mon Mar  1 09:34:19 2010	(r5177)
@@ -0,0 +1,30 @@
+/*
+ * This file is part of the coreboot project.
+ *
+ * Copyright (C) 2008-2009 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; version 2 of
+ * the License.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 51 Franklin St, Fifth Floor, Boston,
+ * MA 02110-1301 USA
+ */
+
+#include <arch/io.h>
+#include <arch/romcc_io.h>
+#include <console/console.h>
+
+int mainboard_io_trap_handler(int smif)
+{
+	printk_debug("MAINBOARD IO TRAP HANDLER!\n");
+	return 1;
+}

Modified: trunk/src/mainboard/rca/rm4100/romstage.c
==============================================================================
--- trunk/src/mainboard/rca/rm4100/romstage.c	Mon Mar  1 08:42:02 2010	(r5176)
+++ trunk/src/mainboard/rca/rm4100/romstage.c	Mon Mar  1 09:34:19 2010	(r5177)
@@ -45,6 +45,7 @@
 #define SERIAL_DEV PNP_DEV(0x2e, SMSCSUPERIO_SP1)
 
 #include "southbridge/intel/i82801dx/i82801dx_early_smbus.c"
+#include "southbridge/intel/i82801dx/i82801dx_tco_timer.c"
 
 /**
  * The onboard 64MB PC133 memory does not have a SPD EEPROM so the
@@ -102,11 +103,12 @@
 
 static void main(unsigned long bist)
 {
-	if (bist == 0)
+	if (bist == 0) {
 		early_mtrr_init();
 		if (memory_initialized()) {
 			hard_reset();
 		}
+	}
 
 	/* Set southbridge and superio gpios */
 	mb_gpio_init();
@@ -118,6 +120,9 @@
 	/* Halt if there was a built in self test failure. */
 	report_bist_failure(bist);
 
+	/* disable TCO timers */
+	i82801dx_halt_tco_timer();
+
 	/* Setup mainboard specific registers */
 	mb_early_setup();
 

Modified: trunk/src/mainboard/thomson/ip1000/Kconfig
==============================================================================
--- trunk/src/mainboard/thomson/ip1000/Kconfig	Mon Mar  1 08:42:02 2010	(r5176)
+++ trunk/src/mainboard/thomson/ip1000/Kconfig	Mon Mar  1 09:34:19 2010	(r5177)
@@ -9,6 +9,7 @@
 	select HAVE_PIRQ_TABLE
 	select UDELAY_TSC
 	select BOARD_ROMSIZE_KB_512
+	select HAVE_SMI_HANDLER
 
 config MAINBOARD_DIR
 	string

Modified: trunk/src/mainboard/thomson/ip1000/Makefile.inc
==============================================================================
--- trunk/src/mainboard/thomson/ip1000/Makefile.inc	Mon Mar  1 08:42:02 2010	(r5176)
+++ trunk/src/mainboard/thomson/ip1000/Makefile.inc	Mon Mar  1 09:34:19 2010	(r5177)
@@ -1 +1,4 @@
 ROMCCFLAGS=-mcpu=p3 -O
+
+smmobj-$(CONFIG_HAVE_SMI_HANDLER) += mainboard_smi.o
+

Modified: trunk/src/mainboard/thomson/ip1000/devicetree.cb
==============================================================================
--- trunk/src/mainboard/thomson/ip1000/devicetree.cb	Mon Mar  1 08:42:02 2010	(r5176)
+++ trunk/src/mainboard/thomson/ip1000/devicetree.cb	Mon Mar  1 09:34:19 2010	(r5177)
@@ -1,4 +1,10 @@
 chip northbridge/intel/i82830		# Northbridge
+  device apic_cluster 0 on		# APIC cluster
+    chip cpu/intel/socket_PGA370	# Low Voltage PIII Micro-FCBGA Socket 479
+      device apic 0 on end		# APIC
+    end
+  end
+
   device pci_domain 0 on		# PCI domain
     device pci 0.0 on end		# Host bridge
     device pci 2.0 on end		# VGA (Intel 82830 CGC)
@@ -19,9 +25,7 @@
       device pci 1d.1 on end		# USB UHCI Controller #2
       device pci 1d.2 on end		# USB UHCI Controller #3
       device pci 1d.7 on end		# USB2 EHCI Controller
-      device pci 1e.0 on		# PCI bridge
-        device pci 08.0 on end		# Intel 82801DB PRO/100 VE Ethernet
-      end
+      device pci 1e.0 on end		# PCI bridge
       device pci 1f.0 on		# ISA/LPC bridge
         chip superio/smsc/smscsuperio	# Super I/O
           device pnp 2e.0 off		# Floppy
@@ -61,10 +65,5 @@
       device pci 1f.6 off end		# AC'97 modem
     end
   end
-  device apic_cluster 0 on		# APIC cluster
-    chip cpu/intel/socket_PGA370	# Low Voltage PIII Micro-FCBGA Socket 479
-      device apic 0 on end		# APIC
-    end
-  end
 end
 

Modified: trunk/src/mainboard/thomson/ip1000/mainboard.c
==============================================================================
--- trunk/src/mainboard/thomson/ip1000/mainboard.c	Mon Mar  1 08:42:02 2010	(r5176)
+++ trunk/src/mainboard/thomson/ip1000/mainboard.c	Mon Mar  1 09:34:19 2010	(r5177)
@@ -21,6 +21,18 @@
 #include <device/device.h>
 #include "chip.h"
 
+static void mainboard_init(device_t dev)
+{
+	// TODO Switch parport LEDs again
+}
+
+static void mainboard_enable(device_t dev)
+{
+	// TODO Switch parport LEDs
+	dev->ops->init = mainboard_init;
+}
+
 struct chip_operations mainboard_ops = {
+	.enable_dev = mainboard_enable,
 	CHIP_NAME("THOMSON IP1000 Mainboard")
 };

Added: trunk/src/mainboard/thomson/ip1000/mainboard_smi.c
==============================================================================
--- /dev/null	00:00:00 1970	(empty, because file is newly added)
+++ trunk/src/mainboard/thomson/ip1000/mainboard_smi.c	Mon Mar  1 09:34:19 2010	(r5177)
@@ -0,0 +1,30 @@
+/*
+ * This file is part of the coreboot project.
+ *
+ * Copyright (C) 2008-2009 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; version 2 of
+ * the License.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 51 Franklin St, Fifth Floor, Boston,
+ * MA 02110-1301 USA
+ */
+
+#include <arch/io.h>
+#include <arch/romcc_io.h>
+#include <console/console.h>
+
+int mainboard_io_trap_handler(int smif)
+{
+	printk_debug("MAINBOARD IO TRAP HANDLER!\n");
+	return 1;
+}

Modified: trunk/src/mainboard/thomson/ip1000/romstage.c
==============================================================================
--- trunk/src/mainboard/thomson/ip1000/romstage.c	Mon Mar  1 08:42:02 2010	(r5176)
+++ trunk/src/mainboard/thomson/ip1000/romstage.c	Mon Mar  1 09:34:19 2010	(r5177)
@@ -45,6 +45,7 @@
 #define SERIAL_DEV PNP_DEV(0x2e, SMSCSUPERIO_SP1)
 
 #include "southbridge/intel/i82801dx/i82801dx_early_smbus.c"
+#include "southbridge/intel/i82801dx/i82801dx_tco_timer.c"
 
 /**
  * The onboard 64MB PC133 memory does not have a SPD EEPROM so the
@@ -102,11 +103,12 @@
 
 static void main(unsigned long bist)
 {
-	if (bist == 0)
+	if (bist == 0) {
 		early_mtrr_init();
 		if (memory_initialized()) {
 			hard_reset();
 		}
+	}
 
 	/* Set southbridge and superio gpios */
 	mb_gpio_init();
@@ -118,6 +120,9 @@
 	/* Halt if there was a built in self test failure. */
 	report_bist_failure(bist);
 
+	/* disable TCO timers */
+	i82801dx_halt_tco_timer();
+
 	/* Setup mainboard specific registers */
 	mb_early_setup();
 

Modified: trunk/src/northbridge/intel/i82830/Makefile.inc
==============================================================================
--- trunk/src/northbridge/intel/i82830/Makefile.inc	Mon Mar  1 08:42:02 2010	(r5176)
+++ trunk/src/northbridge/intel/i82830/Makefile.inc	Mon Mar  1 09:34:19 2010	(r5177)
@@ -1,2 +1,4 @@
 driver-y += northbridge.o
 driver-y += vga.o
+
+smmobj-$(CONFIG_HAVE_SMI_HANDLER) += i82830_smihandler.o

Added: trunk/src/northbridge/intel/i82830/i82830_smihandler.c
==============================================================================
--- /dev/null	00:00:00 1970	(empty, because file is newly added)
+++ trunk/src/northbridge/intel/i82830/i82830_smihandler.c	Mon Mar  1 09:34:19 2010	(r5177)
@@ -0,0 +1,374 @@
+/*
+ * This file is part of the coreboot project.
+ *
+ * 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; version 2 of
+ * the License.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 51 Franklin St, Fifth Floor, Boston,
+ * MA 02110-1301 USA
+ */
+
+#include <types.h>
+#include <string.h>
+#include <arch/io.h>
+#include <arch/romcc_io.h>
+#include <console/console.h>
+#include <cpu/x86/cache.h>
+#include <cpu/x86/smm.h>
+#include <device/pci_def.h>
+#include "i82830.h"
+
+extern unsigned char *mbi;
+extern u32 mbi_len;
+
+#define DEBUG_SMI
+
+/* If YABEL is enabled and it's not running at 0x00000000, we have to add some
+ * offset to all our mbi object memory accesses
+ */
+#if defined(CONFIG_PCI_OPTION_ROM_RUN_YABEL) && !defined(CONFIG_YABEL_DIRECTHW)
+#define OBJ_OFFSET CONFIG_YABEL_VIRTMEM_LOCATION
+#else
+#define OBJ_OFFSET 0x00000
+#endif
+
+/* I830M */
+#define SMRAM		0x90
+#define   D_OPEN	(1 << 6)
+#define   D_CLS		(1 << 5)
+#define   D_LCK		(1 << 4)
+#define   G_SMRANE	(1 << 3)
+#define   C_BASE_SEG	((0 << 2) | (1 << 1) | (0 << 0))
+
+
+typedef struct {
+	u32 mhid;
+	u32 function;
+	u32 retsts;
+	u32 rfu;
+} __attribute__((packed)) banner_id_t;
+
+#define MSH_OK			0x0000
+#define MSH_OK_RESTART		0x0001
+#define MSH_FWH_ERR		0x00ff
+#define MSH_IF_BAD_ID		0x0100
+#define MSH_IF_BAD_FUNC		0x0101
+#define MSH_IF_MBI_CORRUPT	0x0102
+#define MSH_IF_BAD_HANDLE	0x0103
+#define MSH_ALRDY_ATCHED	0x0104
+#define MSH_NOT_ATCHED		0x0105
+#define MSH_IF			0x0106
+#define MSH_IF_INVADDR		0x0107
+#define MSH_IF_UKN_TYPE		0x0108
+#define MSH_IF_NOT_FOUND	0x0109
+#define MSH_IF_NO_KEY		0x010a
+#define MSH_IF_BUF_SIZE		0x010b
+#define MSH_IF_NOT_PENDING	0x010c
+
+static void
+dump(u8 * addr, u32 len)
+{
+	printk_debug("\n%s(%p, %x):\n", __func__, addr, len);
+	while (len) {
+		unsigned int tmpCnt = len;
+		unsigned char x;
+		if (tmpCnt > 8)
+			tmpCnt = 8;
+		printk_debug("\n%p: ", addr);
+		// print hex
+		while (tmpCnt--) {
+			x = *addr++;
+			printk_debug("%02x ", x);
+		}
+		tmpCnt = len;
+		if (tmpCnt > 8)
+			tmpCnt = 8;
+		len -= tmpCnt;
+		//reset addr ptr to print ascii
+		addr = addr - tmpCnt;
+		// print ascii
+		while (tmpCnt--) {
+			x = *addr++;
+			if ((x < 32) || (x >= 127)) {
+				//non-printable char
+				x = '.';
+			}
+			printk_debug("%c", x);
+		}
+	}
+	printk_debug("\n");
+}
+
+typedef struct {
+	banner_id_t banner;
+	u16 versionmajor;
+	u16 versionminor;
+	u32 smicombuffersize;
+} __attribute__((packed)) version_t;
+
+typedef struct {
+	u16 header_id;
+	u16 attributes;
+	u16 size;
+	u8  name_len;
+	u8 reserved;
+	u32 type;
+	u32 header_ext;
+	u8 name[0];
+} __attribute__((packed)) mbi_header_t;
+
+typedef struct {
+	banner_id_t banner;
+	u64 handle;
+	u32 objnum;
+	mbi_header_t header;
+} __attribute__((packed)) obj_header_t;
+
+typedef struct {
+	banner_id_t banner;
+	u64 handle;
+	u32 objnum;
+	u32 start;
+	u32 numbytes;
+	u32 buflen;
+	u32 buffer;
+} __attribute__((packed)) get_object_t;
+
+static void mbi_call(u8 subf, banner_id_t *banner_id)
+{
+	// printk_debug("MBI\n");
+	// printk_debug("|- sub function %x\n", subf);
+	// printk_debug("|- banner id @ %x\n", (u32)banner_id);
+	// printk_debug("|  |- mhid %x\n", banner_id->mhid);
+	// printk_debug("|  |- function %x\n", banner_id->function);
+	// printk_debug("|  |- return status %x\n", banner_id->retsts);
+	// printk_debug("|  |- rfu %x\n", banner_id->rfu);
+
+	switch(banner_id->function) {
+	case 0x0001: {
+		version_t *version;
+		printk_debug("|- MBI_QueryInterface\n");
+		version = (version_t *)banner_id;
+		version->banner.retsts = MSH_OK;
+		version->versionmajor=1;
+		version->versionminor=3;
+		version->smicombuffersize=0x1000;
+		break;
+	}
+	case 0x0002:
+		printk_debug("|- MBI_Attach\n");
+		printk_debug("|? |- Not Implemented!\n");
+		break;
+	case 0x0003:
+		printk_debug("|- MBI_Detach\n");
+		printk_debug("|? |- Not Implemented!\n");
+		break;
+	case 0x0201: {
+		obj_header_t *obj_header = (obj_header_t *)banner_id;
+		mbi_header_t *mbi_header = NULL;
+		printk_debug("|- MBI_GetObjectHeader\n");
+		printk_debug("|  |- objnum = %d\n", obj_header->objnum);
+
+		int i, count=0;
+		obj_header->banner.retsts = MSH_IF_NOT_FOUND;
+
+		for (i=0; i< mbi_len;) {
+			int len;
+
+			if (!(mbi[i] == 0xf0 && mbi [i+1] == 0xf6)) {
+				i+=16;
+				continue;
+			}
+			
+			mbi_header = (mbi_header_t *)&mbi[i];
+			len = ALIGN((mbi_header->size * 16) + sizeof(mbi_header) + mbi_header->name_len, 16);
+			
+			if (obj_header->objnum == count) {
+				int headerlen = ALIGN(sizeof(mbi_header) + mbi_header->name_len + 15, 16);
+				// printk_debug("|  |- headerlen = %d\n", headerlen);
+				memcpy(&obj_header->header, mbi_header, headerlen);
+				obj_header->banner.retsts = MSH_OK;
+				printk_debug("|     |- MBI module '");
+				int j;
+				for (j=0; j < mbi_header->name_len && mbi_header->name[j]; j++)
+					printk_debug("%c",  mbi_header->name[j]);
+				printk_debug("' found.\n", obj_header->objnum);
+				// dump(banner_id, sizeof(obj_header_t) + 16);
+				break;
+			}
+			i += len;
+			count++;
+		}
+		if (obj_header->banner.retsts == MSH_IF_NOT_FOUND) 
+			printk_debug("|     |- MBI object #%d not found.\n", obj_header->objnum);
+		break;
+	}
+	case 0x0203: {
+		get_object_t *getobj = (get_object_t *)banner_id;
+		mbi_header_t *mbi_header = NULL;
+		printk_debug("|- MBI_GetObject\n");
+		// printk_debug("|  |- handle = %016lx\n", getobj->handle);
+		printk_debug("|  |- objnum = %d\n", getobj->objnum);
+		printk_debug("|  |- start = %x\n", getobj->start);
+		printk_debug("|  |- numbytes = %x\n", getobj->numbytes);
+		printk_debug("|  |- buflen = %x\n", getobj->buflen);
+		printk_debug("|  |- buffer = %x\n", getobj->buffer);
+
+		int i, count=0;
+		getobj->banner.retsts = MSH_IF_NOT_FOUND;
+
+		for (i=0; i< mbi_len;) {
+			int len;
+
+			if (!(mbi[i] == 0xf0 && mbi [i+1] == 0xf6)) {
+				i+=16;
+				continue;
+			}
+			
+			mbi_header = (mbi_header_t *)&mbi[i];
+			len = ALIGN((mbi_header->size * 16) + sizeof(mbi_header) + mbi_header->name_len, 16);
+			
+			if (getobj->objnum == count) {
+				printk_debug("|  |- len = %x\n", len);
+				memcpy((void *)(getobj->buffer + OBJ_OFFSET),
+						((char *)mbi_header) + 0x20 , (len > getobj->buflen ? getobj->buflen : len));
+
+				getobj->banner.retsts = MSH_OK;
+				//dump(banner_id, sizeof(getobj) + len);
+				break;
+			}
+			i += len;
+			count++;
+		}
+		if (getobj->banner.retsts == MSH_IF_NOT_FOUND) 
+			printk_debug("MBI module %d not found.\n", getobj->objnum);
+		break;
+	}
+	default:
+		printk_debug("|- function %x\n", banner_id->function);
+		printk_debug("|  |- Unknown Function!\n");
+		break;
+	}
+	printk_debug("\n");
+	//dump(banner_id, 0x20);
+}
+
+#define SMI_IFC_SUCCESS		    1
+#define SMI_IFC_FAILURE_GENERIC     0
+#define SMI_IFC_FAILURE_INVALID     2
+#define SMI_IFC_FAILURE_CRITICAL    4
+#define SMI_IFC_FAILURE_NONCRITICAL 6
+
+#define PC10 	0x10
+#define PC11	0x11
+#define PC12	0x12
+#define PC13	0x13
+
+void smi_interface_call(void)
+{
+	u32 mmio;
+	mmio = pci_read_config32(PCI_DEV(0, 0x02, 0), 0x14);
+	// mmio &= 0xfff80000;
+	// printk_debug("mmio=%x\n", mmio);
+
+	u16 swsmi;
+	swsmi=pci_read_config16(PCI_DEV(0, 0x02, 0), 0xe0);
+
+	if (!(swsmi & 1))
+		return;
+
+	swsmi &= ~(1 << 0); // clear SMI toggle
+
+	switch ((swsmi>>1) & 0xf) {
+	case 0:
+		printk_debug("Interface Function Presence Test.\n");
+		swsmi = 0;
+		swsmi &= ~(7 << 5); // Exit: Result
+		swsmi |= (SMI_IFC_SUCCESS << 5);
+		swsmi &= 0xff;
+		swsmi |= (PC13 << 8);
+		pci_write_config16(PCI_DEV(0, 0x02, 0), 0xe0, swsmi);
+		// pathetic
+		write32(mmio + 0x71428, 0x494e5443);
+		return;
+	case 4:
+		printk_debug("Get BIOS Data.\n");
+		printk_debug("swsmi=%04x\n", swsmi);
+		break;
+	case 5:
+		printk_debug("Call MBI Functions.\n");
+		mbi_call(swsmi >> 8, (banner_id_t *)((readl(mmio + 0x71428) & 0x000fffff) + OBJ_OFFSET) );
+		// swsmi = 0x0000;
+		swsmi &= ~(7 << 5); // Exit: Result
+		swsmi |= (SMI_IFC_SUCCESS << 5);
+		pci_write_config16(PCI_DEV(0, 0x02, 0), 0xe0, swsmi);
+		return;
+	case 6:
+		printk_debug("System BIOS Callbacks.\n");
+		printk_debug("swsmi=%04x\n", swsmi);
+		break;
+	default:
+		printk_debug("Unknown SMI interface call %04x\n", swsmi);
+		break;
+	}
+
+	swsmi &= ~(7 << 5); // Exit: Result
+	swsmi |= (SMI_IFC_FAILURE_CRITICAL << 7);
+	pci_write_config16(PCI_DEV(0, 0x02, 0), 0xe0, swsmi);
+}
+
+/**
+ * @brief read and clear ERRSTS
+ * @return ERRSTS register
+ */
+static u16 reset_err_status(void)
+{
+	u16 reg16;
+
+	reg16 = pci_read_config16(PCI_DEV(0, 0x00, 0), ERRSTS);
+	/* set status bits are cleared by writing 1 to them */
+	pci_write_config16(PCI_DEV(0, 0x00, 0), ERRSTS, reg16);
+
+	return reg16;
+}
+
+static void dump_err_status(u32 errsts)
+{
+	printk_debug("ERRSTS: ");
+	if (errsts & (1 << 12)) printk_debug("MBI ");
+	if (errsts & (1 <<  9)) printk_debug("LCKF ");
+	if (errsts & (1 <<  8)) printk_debug("DTF ");
+	if (errsts & (1 <<  5)) printk_debug("UNSC ");
+	if (errsts & (1 <<  4)) printk_debug("OOGF ");
+	if (errsts & (1 <<  3)) printk_debug("IAAF ");
+	if (errsts & (1 <<  2)) printk_debug("ITTEF ");
+	printk_debug("\n");
+}
+
+void northbridge_smi_handler(unsigned int node, smm_state_save_area_t *state_save)
+{
+	u16 errsts;
+
+	/* We need to clear the SMI status registers, or we won't see what's
+	 * happening in the following calls.
+	 */
+	errsts = reset_err_status();
+	if (errsts & (1 << 12)) {
+		smi_interface_call();
+	} else {
+		if (errsts)
+			dump_err_status(errsts);
+	}
+
+}

Modified: trunk/src/northbridge/intel/i82830/northbridge.c
==============================================================================
--- trunk/src/northbridge/intel/i82830/northbridge.c	Mon Mar  1 08:42:02 2010	(r5176)
+++ trunk/src/northbridge/intel/i82830/northbridge.c	Mon Mar  1 09:34:19 2010	(r5177)
@@ -116,7 +116,7 @@
 		 */
 		tomk = ((unsigned long)pci_read_config8(mc_dev, DRB + 3)) << 15;
 		tomk -= igd_memory;
-		printk_debug("Setting RAM size to %ld\n", tomk);
+		printk_debug("Memory detected: %ldKB RAM\n", tomk);
 
 		/* Compute the top of low memory. */
 		tolmk = pci_tolm >> 10;

Modified: trunk/src/northbridge/intel/i82830/raminit.c
==============================================================================
--- trunk/src/northbridge/intel/i82830/raminit.c	Mon Mar  1 08:42:02 2010	(r5176)
+++ trunk/src/northbridge/intel/i82830/raminit.c	Mon Mar  1 09:34:19 2010	(r5177)
@@ -536,6 +536,7 @@
 
 	value = pci_read_config16(NORTHBRIDGE, GCC1);
 	value |= igd_memory << 4;
+	value |= 1; // 64MB aperture
 	pci_write_config16(NORTHBRIDGE, GCC1, value);
 
 	PRINT_DEBUG("Initial northbridge registers have been set.\r\n");

Modified: trunk/src/northbridge/intel/i82830/vga.c
==============================================================================
--- trunk/src/northbridge/intel/i82830/vga.c	Mon Mar  1 08:42:02 2010	(r5176)
+++ trunk/src/northbridge/intel/i82830/vga.c	Mon Mar  1 09:34:19 2010	(r5177)
@@ -24,13 +24,67 @@
 #include <device/device.h>
 #include <device/pci.h>
 #include <device/pci_ids.h>
+#include <cbfs.h>
+#include <x86emu/x86emu.h>
 
-static void vga_init(device_t dev) {
-
+static void vga_init(device_t dev)
+{
 	printk_info("Starting Graphics Initialization\n");
+	struct cbfs_file *file = cbfs_find("mbi.bin");
+	void *mbi = NULL;
+	unsigned int mbi_len = 0;
+
+	if (file) {
+		if (ntohl(file->type) != CBFS_TYPE_MBI) {
+			printk_info( "CBFS:  MBI binary is of type %x instead of"
+			       "type %x\n", file->type, CBFS_TYPE_MBI);
+		} else {
+			mbi = (void *) CBFS_SUBHEADER(file);
+			mbi_len = file->len;
+		}
+	} else {
+		printk_info( "Could not find MBI.\n");
+	}
+
+	if (mbi && mbi_len) {
+		/* The GDT or coreboot table is going to live here. But
+		 * a long time after we relocated the GNVS, so this is
+		 * not troublesome.
+		 */
+		*(u32 *)0x500 = (u32)mbi;
+		*(u32 *)0x504 = (u32)mbi_len;
+		outb(0xeb, 0xb2);
+	}
+
 	pci_dev_init(dev);
 	printk_info("Graphics Initialization Complete\n");
-	/* Future TV-OUT code will be called from here. */
+
+	/* Enable TV-Out */
+#if defined(CONFIG_PCI_OPTION_ROM_RUN_YABEL) && CONFIG_PCI_OPTION_ROM_RUN_YABEL
+#define PIPE_A_CRT	(1 << 0)
+#define PIPE_A_LFP	(1 << 1)
+#define PIPE_A_TV	(1 << 3)
+#define PIPE_B_CRT	(1 << 8)
+#define PIPE_B_TV	(1 << 10)
+	printk_debug("Enabling TV-Out\n"); 
+	void runInt10(void);
+	M.x86.R_AX = 0x5f64;
+	M.x86.R_BX = 0x0001; // Set Display Device, force execution
+	M.x86.R_CX = PIPE_A_CRT | PIPE_A_TV;
+	// M.x86.R_CX = PIPE_B_TV;
+	runInt10();
+	switch (M.x86.R_AX) {
+	case 0x005f:
+		printk_debug("... failed.\n");
+		break;
+	case 0x015f:
+		printk_debug("... ok.\n");
+		break;
+	default:
+		printk_debug("... not supported.\n");
+		break;
+	}
+#endif
 }
 
 static const struct device_operations vga_operations = {

Modified: trunk/src/southbridge/intel/i82801dx/Kconfig
==============================================================================
--- trunk/src/southbridge/intel/i82801dx/Kconfig	Mon Mar  1 08:42:02 2010	(r5176)
+++ trunk/src/southbridge/intel/i82801dx/Kconfig	Mon Mar  1 09:34:19 2010	(r5177)
@@ -1,2 +1,3 @@
 config SOUTHBRIDGE_INTEL_I82801DX
 	bool
+	select IOAPIC

Modified: trunk/src/southbridge/intel/i82801dx/Makefile.inc
==============================================================================
--- trunk/src/southbridge/intel/i82801dx/Makefile.inc	Mon Mar  1 08:42:02 2010	(r5176)
+++ trunk/src/southbridge/intel/i82801dx/Makefile.inc	Mon Mar  1 09:34:19 2010	(r5177)
@@ -7,3 +7,6 @@
 #driver-y += i82801dx_nic.o
 #driver-y += i82801dx_pci.o
 obj-y += i82801dx_reset.o
+
+obj-$(CONFIG_HAVE_SMI_HANDLER) += i82801dx_smi.o
+smmobj-$(CONFIG_HAVE_SMI_HANDLER) += i82801dx_smihandler.o

Modified: trunk/src/southbridge/intel/i82801dx/i82801dx_ac97.c
==============================================================================
--- trunk/src/southbridge/intel/i82801dx/i82801dx_ac97.c	Mon Mar  1 08:42:02 2010	(r5176)
+++ trunk/src/southbridge/intel/i82801dx/i82801dx_ac97.c	Mon Mar  1 09:34:19 2010	(r5177)
@@ -1,41 +1,285 @@
 /*
- * (C) 2003 Linux Networx
+ * This file is part of the coreboot project.
+ *
+ * Copyright (C) 2008-2009 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; version 2 of
+ * the License.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA  02110-1301 USA
  */
+
 #include <console/console.h>
 #include <device/device.h>
 #include <device/pci.h>
 #include <device/pci_ids.h>
-#include <device/pci_ops.h>
+#include <arch/io.h>
+#include <delay.h>
 #include "i82801dx.h"
 
+#define NAMBAR		0x10
+#define   MASTER_VOL	0x02
+#define   PAGING	0x24
+#define   EXT_AUDIO	0x28
+#define   FUNC_SEL	0x66
+#define   INFO_IO	0x68
+#define   CONNECTOR	0x6a
+#define   VENDOR_ID1	0x7c
+#define   VENDOR_ID2	0x7e
+#define   SEC_VENDOR_ID1 0xfc
+#define   SEC_VENDOR_ID2 0xfe
+
+#define NABMBAR		0x14
+#define   GLOB_CNT	0x2c
+#define   GLOB_STA	0x30
+#define   CAS		0x34
+
+#define MMBAR		0x10
+#define   EXT_MODEM_ID1	0x3c
+#define   EXT_MODEM_ID2	0xbc
+
+#define MBAR		0x14
+#define   SEC_CODEC	0x40
+
+
+/* FIXME. This table is probably mainboard specific */
+static u16 ac97_function[16*2][4] = {
+	{ (1 << 5), (2 << 11), (1 << 10), (3 << 13) },
+	{ (1 << 5), (2 << 11), (1 << 10), (3 << 13) },
+	{ (1 << 5), (2 << 11), (1 << 10), (3 << 13) },
+	{ (1 << 5), (2 << 11), (1 << 10), (3 << 13) },
+	{ (1 << 5), (2 << 11), (1 << 10), (3 << 13) },
+	{ (1 << 5), (2 << 11), (1 << 10), (3 << 13) },
+	{ (1 << 5), (2 << 11), (1 << 10), (3 << 13) },
+	{ (1 << 5), (2 << 11), (1 << 10), (3 << 13) },
+	{ (1 << 5), (2 << 11), (1 << 10), (3 << 13) },
+	{ (1 << 5), (2 << 11), (1 << 10), (3 << 13) },
+	{ (1 << 5), (2 << 11), (1 << 10), (3 << 13) },
+	{ (1 << 5), (2 << 11), (1 << 10), (3 << 13) },
+	{ (1 << 5), (2 << 11), (1 << 10), (3 << 13) },
+	{ (1 << 5), (2 << 11), (1 << 10), (3 << 13) },
+	{ (1 << 5), (2 << 11), (1 << 10), (3 << 13) },
+	{ (1 << 5), (2 << 11), (1 << 10), (3 << 13) },
+	{ (1 << 5), (2 << 11), (1 << 10), (3 << 13) },
+	{ (1 << 5), (2 << 11), (1 << 10), (3 << 13) },
+	{ (1 << 5), (2 << 11), (1 << 10), (3 << 13) },
+	{ (1 << 5), (2 << 11), (1 << 10), (3 << 13) },
+	{ (1 << 5), (2 << 11), (1 << 10), (3 << 13) },
+	{ (1 << 5), (2 << 11), (1 << 10), (3 << 13) },
+	{ (1 << 5), (2 << 11), (1 << 10), (3 << 13) },
+	{ (1 << 5), (2 << 11), (1 << 10), (3 << 13) },
+	{ (1 << 5), (2 << 11), (1 << 10), (3 << 13) },
+	{ (1 << 5), (2 << 11), (1 << 10), (3 << 13) },
+	{ (1 << 5), (2 << 11), (1 << 10), (3 << 13) },
+	{ (1 << 5), (2 << 11), (1 << 10), (3 << 13) },
+	{ (1 << 5), (2 << 11), (1 << 10), (3 << 13) },
+	{ (1 << 5), (2 << 11), (1 << 10), (3 << 13) },
+	{ (1 << 5), (2 << 11), (1 << 10), (3 << 13) },
+	{ (1 << 5), (2 << 11), (1 << 10), (3 << 13) }
+};
+
+static u16 nabmbar;
+static u16 nambar;
+
+static int ac97_semaphore(void)
+{
+	int timeout;
+	u8 reg8;
+
+	timeout = 0xffff;
+	do {
+		reg8 = inb(nabmbar + CAS);
+		timeout--;
+	} while ((reg8 & 1) && timeout);
+	if (! timeout) {
+		printk_debug("Timeout!\n");
+	}
+
+	return (!timeout);
+}
+
+static void init_cnr(void)
+{
+	// TODO
+}
+
+static void program_sigid(struct device *dev, u32 id)
+{
+	pci_write_config32(dev, 0x2c, id);
+}
+
+static void ac97_audio_init(struct device *dev)
+{
+	u16 reg16;
+	u32 reg32;
+	int i;
+
+	printk_debug("Initializing AC'97 Audio.\n");
+
+	/* top 16 bits are zero, so don't read them */
+	nabmbar = pci_read_config16(dev, NABMBAR) & 0xfffe;
+	nambar = pci_read_config16(dev, NAMBAR) & 0xfffe;
+
+	reg16 = inw(nabmbar + GLOB_CNT);
+	reg16 |= (1 << 1); /* Remove AC_RESET# */
+	outw(reg16, nabmbar + GLOB_CNT);
+
+	/* Wait 600ms. Ouch. */
+	udelay(600 * 1000);
+
+	init_cnr();
+
+	/* Detect Primary AC'97 Codec */
+	reg32 = inl(nabmbar + GLOB_STA);
+	if ((reg32 & ((1 << 28) | (1 << 9) | (1 << 8))) == 0) {
+		/* Primary Codec not found */
+		printk_debug("No primary codec. Disabling AC'97 Audio.\n");
+		return;
+	}
+
+	ac97_semaphore();
+
+	/* Detect if codec is programmable */
+	outw(0x8000, nambar + MASTER_VOL);
+	ac97_semaphore();
+	if (inw(nambar + MASTER_VOL) != 0x8000) {
+		printk_debug("Codec not programmable. Disabling AC'97 Audio.\n");
+		return;
+	}
+
+	/* Program Vendor IDs */
+	reg32 = inw(nambar + VENDOR_ID1);
+	reg32 <<= 16;
+	reg32 |= (u16)inw(nambar + VENDOR_ID2);
+
+	program_sigid(dev, reg32);
 
-static struct device_operations ac97audio_ops  = {
+	/* Is Codec AC'97 2.3 compliant? */
+	reg16 = inw(nambar + EXT_AUDIO);
+	/* [11:10] = 10b -> AC'97 2.3 */
+	if ((reg16 & 0x0c00) != 0x0800) {
+		/* No 2.3 Codec. We're done */
+		return;
+	}
+
+	/* Select Page 1 */
+	reg16 = inw(nambar + PAGING);
+	reg16 &= 0xfff0;
+	reg16 |= 0x0001;
+	outw(reg16, nambar + PAGING);
+
+	for (i = 0x0a * 2; i > 0; i--) {
+		outw(i, nambar + FUNC_SEL);
+
+		/* Function could not be selected. Next one */
+		if (inw(nambar + FUNC_SEL) != i)
+			continue;
+
+		reg16 = inw(nambar + INFO_IO);
+
+		/* Function Information present? */
+		if (!(reg16 & (1 << 0)))
+			continue;
+
+		/* Function Information valid? */
+		if (!(reg16 & (1 << 4)))
+			continue;
+
+		/* Program Buffer Delay [9:5] */
+		reg16 &= 0x03e0;
+		reg16 |= ac97_function[i][0];
+
+		/* Program Gain [15:11] */
+		reg16 |= ac97_function[i][1];
+
+		/* Program Inversion [10] */
+		reg16 |= ac97_function[i][2];
+
+		outw(reg16, nambar + INFO_IO);
+
+		/* Program Connector / Jack Location */
+		reg16 = inw(nambar + CONNECTOR);
+		reg16 &= 0x1fff;
+		reg16 |= ac97_function[i][3];
+		outw(reg16, nambar + CONNECTOR);
+	}
+}
+
+static void ac97_modem_init(struct device *dev)
+{
+	u16 reg16;
+	u32 reg32;
+	u16 mmbar, mbar;
+
+	mmbar = pci_read_config16(dev, MMBAR) & 0xfffe;
+	mbar = pci_read_config16(dev, MBAR) & 0xfffe;
+
+	reg16 = inw(mmbar + EXT_MODEM_ID1);
+	if ((reg16 & 0xc000) != 0xc000 ) {
+		if (reg16 & (1 << 0)) {
+			reg32 = inw(mmbar + VENDOR_ID2);
+			reg32 <<= 16;
+			reg32 |= (u16)inw(mmbar + VENDOR_ID1);
+			program_sigid(dev, reg32);
+			return;
+		}
+	}
+
+	/* Secondary codec? */
+	reg16 = inw(mbar + SEC_CODEC);
+	if ((reg16 & (1 << 9)) == 0)
+		return;
+
+	reg16 = inw(mmbar + EXT_MODEM_ID2);
+	if ((reg16 & 0xc000) == 0x4000) {
+		if (reg16 & (1 << 0)) {
+			reg32 = inw(mmbar + SEC_VENDOR_ID2);
+			reg32 <<= 16;
+			reg32 |= (u16)inw(mmbar + SEC_VENDOR_ID1);
+			program_sigid(dev, reg32);
+			return;
+		}
+	}
+}
+
+static struct device_operations ac97_audio_ops  = {
 	.read_resources   = pci_dev_read_resources,
 	.set_resources    = pci_dev_set_resources,
 	.enable_resources = pci_dev_enable_resources,
 	.enable           = i82801dx_enable,
-	.init             = 0,
+	.init             = ac97_audio_init,
 	.scan_bus         = 0,
 };
 
-static const struct pci_driver ac97audio_driver __pci_driver = {
-	.ops    = &ac97audio_ops,
-	.vendor = PCI_VENDOR_ID_INTEL,
-	.device = PCI_DEVICE_ID_INTEL_82801DBM_AC97_AUDIO,
-};
-
-
-static struct device_operations ac97modem_ops  = {
+static struct device_operations ac97_modem_ops  = {
 	.read_resources   = pci_dev_read_resources,
 	.set_resources    = pci_dev_set_resources,
 	.enable_resources = pci_dev_enable_resources,
 	.enable           = i82801dx_enable,
-	.init             = 0,
+	.init             = ac97_modem_init,
 	.scan_bus         = 0,
 };
 
-static const struct pci_driver ac97modem_driver __pci_driver = {
-	.ops    = &ac97modem_ops,
-	.vendor = PCI_VENDOR_ID_INTEL,
-	.device = PCI_DEVICE_ID_INTEL_82801DBM_AC97_MODEM,
+/* 82801DB/DBL/DBM (ICH4/ICH4-L/ICH4-M) */
+static const struct pci_driver i82801db_ac97_audio __pci_driver = {
+	.ops	= &ac97_audio_ops,
+	.vendor	= PCI_VENDOR_ID_INTEL,
+	.device	= PCI_DEVICE_ID_INTEL_82801DB_AC97_AUDIO,
+};
+
+static const struct pci_driver i82801db_ac97_modem __pci_driver = {
+	.ops	= &ac97_modem_ops,
+	.vendor	= PCI_VENDOR_ID_INTEL,
+	.device	= PCI_DEVICE_ID_INTEL_82801DB_AC97_MODEM,
 };
+
+

Added: trunk/src/southbridge/intel/i82801dx/i82801dx_nvs.h
==============================================================================
--- /dev/null	00:00:00 1970	(empty, because file is newly added)
+++ trunk/src/southbridge/intel/i82801dx/i82801dx_nvs.h	Mon Mar  1 09:34:19 2010	(r5177)
@@ -0,0 +1,138 @@
+/*
+ * This file is part of the coreboot project.
+ *
+ * Copyright (C) 2008-2009 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; version 2 of the License.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA
+ */
+
+typedef struct {
+	/* Miscellaneous */
+	u16	osys; /* 0x00 - Operating System */
+	u8	smif; /* 0x02 - SMI function call ("TRAP") */
+	u8	prm0; /* 0x03 - SMI function call parameter */
+	u8	prm1; /* 0x04 - SMI function call parameter */
+	u8	scif; /* 0x05 - SCI function call (via _L00) */
+	u8	prm2; /* 0x06 - SCI function call parameter */
+	u8	prm3; /* 0x07 - SCI function call parameter */
+	u8	lckf; /* 0x08 - Global Lock function for EC */
+	u8	prm4; /* 0x09 - Lock function parameter */
+	u8	prm5; /* 0x0a - Lock function parameter */
+	u32	p80d; /* 0x0b - Debug port (IO 0x80) value */
+	u8	lids; /* 0x0f - LID state (open = 1) */
+	u8	pwrs; /* 0x10 - Power state (AC = 1) */
+	u8	dbgs; /* 0x11 - Debug state */
+	u8	linx; /* 0x12 - Linux OS */
+	u8	dckn; /* 0x13 - PCIe docking state */
+	/* Thermal policy */
+	u8	actt; /* 0x14 - active trip point */
+	u8	psvt; /* 0x15 - passive trip point */
+	u8	tc1v; /* 0x16 - passive trip point TC1 */
+	u8	tc2v; /* 0x17 - passive trip point TC2 */
+	u8	tspv; /* 0x18 - passive trip point TSP */
+	u8	crtt; /* 0x19 - critical trip point */
+	u8	dtse; /* 0x1a - Digital Thermal Sensor enable */
+	u8	dts1; /* 0x1b - DT sensor 1 */
+	u8	dts2; /* 0x1c - DT sensor 2 */
+	u8	rsvd2;
+	/* Battery Support */
+	u8	bnum; /* 0x1e - number of batteries */
+	u8	b0sc, b1sc, b2sc; /* 0x1f-0x21 - stored capacity */
+	u8	b0ss, b1ss, b2ss; /* 0x22-0x24 - stored status */
+	u8	rsvd3[3];
+	/* Processor Identification */
+	u8	apic; /* 0x28 - APIC enabled */
+	u8	mpen; /* 0x29 - MP capable/enabled */
+	u8	pcp0; /* 0x2a - PDC CPU/CORE 0 */
+	u8	pcp1; /* 0x2b - PDC CPU/CORE 1 */
+	u8	ppcm; /* 0x2c - Max. PPC state */
+	u8	rsvd4[5];
+	/* Super I/O & CMOS config */
+	u8	natp; /* 0x32 - SIO type */
+	u8	cmap; /* 0x33 - */
+	u8	cmbp; /* 0x34 - */
+	u8	lptp; /* 0x35 - LPT port */
+	u8	fdcp; /* 0x36 - Floppy Disk Controller */
+	u8	rfdv; /* 0x37 - */
+	u8	hotk; /* 0x38 - Hot Key */
+	u8	rtcf;
+	u8	util;
+	u8	acin;
+	/* Integrated Graphics Device */
+	u8	igds; /* 0x3c - IGD state */
+	u8	tlst; /* 0x3d - Display Toggle List Pointer */
+	u8	cadl; /* 0x3e - currently attached devices */
+	u8	padl; /* 0x3f - previously attached devices */
+	u16	cste; /* 0x40 - current display state */
+	u16	nste; /* 0x42 - next display state */
+	u16	sste; /* 0x44 - set display state */
+	u8	ndid; /* 0x46 - number of device ids */
+	u32	did[5]; /* 0x47 - 5b device id 1..5 */
+	u8	rsvd5[0x9];
+	/* Backlight Control */
+	u8	blcs; /* 0x64 - Backlight Control possible */
+	u8	brtl;
+	u8	odds;
+	u8	rsvd6[0x7];
+	/* Ambient Light Sensors*/
+	u8	alse; /* 0x6e - ALS enable */
+	u8	alaf;
+	u8	llow;
+	u8	lhih;
+	u8	rsvd7[0x6];
+	/* EMA */
+	u8	emae; /* 0x78 - EMA enable */
+	u16	emap;
+	u16	emal;
+	u8	rsvd8[0x5];
+	/* MEF */
+	u8	mefe; /* 0x82 - MEF enable */
+	u8	rsvd9[0x9];
+	/* TPM support */
+	u8	tpmp; /* 0x8c - TPM */
+	u8	tpme;
+	u8	rsvd10[8];
+	/* SATA */
+	u8	gtf0[7]; /* 0x96 - GTF task file buffer for port 0 */
+	u8	gtf1[7];
+	u8	gtf2[7];
+	u8	idem;
+	u8	idet;
+	u8	rsvd11[7];
+	/* IGD OpRegion (not implemented yet) */
+	u32	aslb; /* 0xb4 - IGD OpRegion Base Address */
+	u8	ibtt;
+	u8	ipat;
+	u8	itvf;
+	u8	itvm;
+	u8	ipsc;
+	u8	iblc;
+	u8	ibia;
+	u8	issc;
+	u8	i409;
+	u8	i509;
+	u8	i609;
+	u8	i709;
+	u8	idmm;
+	u8	idms;
+	u8	if1e;
+	u8	hvco;
+	u32	nxd[8];
+	u8	rsvd12[8];
+	/* Mainboard specific */
+	u8	dock; /* 0xf0 - Docking Status */
+	u8	bten;
+	u8	rsvd13[14];
+} __attribute__((packed)) global_nvs_t;
+

Added: trunk/src/southbridge/intel/i82801dx/i82801dx_smi.c
==============================================================================
--- /dev/null	00:00:00 1970	(empty, because file is newly added)
+++ trunk/src/southbridge/intel/i82801dx/i82801dx_smi.c	Mon Mar  1 09:34:19 2010	(r5177)
@@ -0,0 +1,365 @@
+/*
+ * This file is part of the coreboot project.
+ *
+ * Copyright (C) 2008-2009 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; version 2 of
+ * the License.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 51 Franklin St, Fifth Floor, Boston,
+ * MA 02110-1301 USA
+ */
+
+
+#include <device/device.h>
+#include <device/pci.h>
+#include <console/console.h>
+#include <arch/io.h>
+#include <cpu/x86/cache.h>
+#include <cpu/x86/smm.h>
+#include <string.h>
+#include "i82801dx.h"
+
+extern unsigned char smm[];
+extern unsigned int smm_len;
+
+/* I945 */
+#define SMRAM		0x90
+#define   D_OPEN	(1 << 6)
+#define   D_CLS		(1 << 5)
+#define   D_LCK		(1 << 4)
+#define   G_SMRAME	(1 << 3)
+#define   C_BASE_SEG	((0 << 2) | (1 << 1) | (0 << 0))
+
+/* While we read PMBASE dynamically in case it changed, let's
+ * initialize it with a sane value
+ */
+static u16 pmbase = PMBASE_ADDR;
+
+/**
+ * @brief read and clear PM1_STS
+ * @return PM1_STS register
+ */
+static u16 reset_pm1_status(void)
+{
+	u16 reg16;
+
+	reg16 = inw(pmbase + PM1_STS);
+	/* set status bits are cleared by writing 1 to them */
+	outw(reg16, pmbase + PM1_STS);
+
+	return reg16;
+}
+
+static void dump_pm1_status(u16 pm1_sts)
+{
+	printk_debug("PM1_STS: ");
+	if (pm1_sts & (1 << 15)) printk_debug("WAK ");
+	if (pm1_sts & (1 << 14)) printk_debug("PCIEXPWAK ");
+	if (pm1_sts & (1 << 11)) printk_debug("PRBTNOR ");
+	if (pm1_sts & (1 << 10)) printk_debug("RTC ");
+	if (pm1_sts & (1 <<  8)) printk_debug("PWRBTN ");
+	if (pm1_sts & (1 <<  5)) printk_debug("GBL ");
+	if (pm1_sts & (1 <<  4)) printk_debug("BM ");
+	if (pm1_sts & (1 <<  0)) printk_debug("TMROF ");
+	printk_debug("\n");
+}
+
+/**
+ * @brief read and clear SMI_STS
+ * @return SMI_STS register
+ */
+static u32 reset_smi_status(void)
+{
+	u32 reg32;
+
+	reg32 = inl(pmbase + SMI_STS);
+	/* set status bits are cleared by writing 1 to them */
+	outl(reg32, pmbase + SMI_STS);
+
+	return reg32;
+}
+
+static void dump_smi_status(u32 smi_sts)
+{
+	printk_debug("SMI_STS: ");
+	if (smi_sts & (1 << 26)) printk_debug("SPI ");
+	if (smi_sts & (1 << 25)) printk_debug("EL_SMI ");
+	if (smi_sts & (1 << 21)) printk_debug("MONITOR ");
+	if (smi_sts & (1 << 20)) printk_debug("PCI_EXP_SMI ");
+	if (smi_sts & (1 << 18)) printk_debug("INTEL_USB2 ");
+	if (smi_sts & (1 << 17)) printk_debug("LEGACY_USB2 ");
+	if (smi_sts & (1 << 16)) printk_debug("SMBUS_SMI ");
+	if (smi_sts & (1 << 15)) printk_debug("SERIRQ_SMI ");
+	if (smi_sts & (1 << 14)) printk_debug("PERIODIC ");
+	if (smi_sts & (1 << 13)) printk_debug("TCO ");
+	if (smi_sts & (1 << 12)) printk_debug("DEVMON ");
+	if (smi_sts & (1 << 11)) printk_debug("MCSMI ");
+	if (smi_sts & (1 << 10)) printk_debug("GPI ");
+	if (smi_sts & (1 <<  9)) printk_debug("GPE0 ");
+	if (smi_sts & (1 <<  8)) printk_debug("PM1 ");
+	if (smi_sts & (1 <<  6)) printk_debug("SWSMI_TMR ");
+	if (smi_sts & (1 <<  5)) printk_debug("APM ");
+	if (smi_sts & (1 <<  4)) printk_debug("SLP_SMI ");
+	if (smi_sts & (1 <<  3)) printk_debug("LEGACY_USB ");
+	if (smi_sts & (1 <<  2)) printk_debug("BIOS ");
+	printk_debug("\n");
+}
+
+
+/**
+ * @brief read and clear GPE0_STS
+ * @return GPE0_STS register
+ */
+static u32 reset_gpe0_status(void)
+{
+	u32 reg32;
+
+	reg32 = inl(pmbase + GPE0_STS);
+	/* set status bits are cleared by writing 1 to them */
+	outl(reg32, pmbase + GPE0_STS);
+
+	return reg32;
+}
+
+static void dump_gpe0_status(u32 gpe0_sts)
+{
+	int i;
+	printk_debug("GPE0_STS: ");
+	for (i=31; i<= 16; i--) {
+		if (gpe0_sts & (1 << i)) printk_debug("GPIO%d ", (i-16));
+	}
+	if (gpe0_sts & (1 << 14)) printk_debug("USB4 ");
+	if (gpe0_sts & (1 << 13)) printk_debug("PME_B0 ");
+	if (gpe0_sts & (1 << 12)) printk_debug("USB3 ");
+	if (gpe0_sts & (1 << 11)) printk_debug("PME ");
+	if (gpe0_sts & (1 << 10)) printk_debug("EL_SCI/BATLOW ");
+	if (gpe0_sts & (1 <<  9)) printk_debug("PCI_EXP ");
+	if (gpe0_sts & (1 <<  8)) printk_debug("RI ");
+	if (gpe0_sts & (1 <<  7)) printk_debug("SMB_WAK ");
+	if (gpe0_sts & (1 <<  6)) printk_debug("TCO_SCI ");
+	if (gpe0_sts & (1 <<  5)) printk_debug("AC97 ");
+	if (gpe0_sts & (1 <<  4)) printk_debug("USB2 ");
+	if (gpe0_sts & (1 <<  3)) printk_debug("USB1 ");
+	if (gpe0_sts & (1 <<  2)) printk_debug("HOT_PLUG ");
+	if (gpe0_sts & (1 <<  0)) printk_debug("THRM ");
+	printk_debug("\n");
+}
+
+
+/**
+ * @brief read and clear ALT_GP_SMI_STS
+ * @return ALT_GP_SMI_STS register
+ */
+static u16 reset_alt_gp_smi_status(void)
+{
+	u16 reg16;
+
+	reg16 = inl(pmbase + ALT_GP_SMI_STS);
+	/* set status bits are cleared by writing 1 to them */
+	outl(reg16, pmbase + ALT_GP_SMI_STS);
+
+	return reg16;
+}
+
+static void dump_alt_gp_smi_status(u16 alt_gp_smi_sts)
+{
+	int i;
+	printk_debug("ALT_GP_SMI_STS: ");
+	for (i=15; i<= 0; i--) {
+		if (alt_gp_smi_sts & (1 << i)) printk_debug("GPI%d ", (i-16));
+	}
+	printk_debug("\n");
+}
+
+
+
+/**
+ * @brief read and clear TCOx_STS
+ * @return TCOx_STS registers
+ */
+static u32 reset_tco_status(void)
+{
+	u32 tcobase = pmbase + 0x60;
+	u32 reg32;
+
+	reg32 = inl(tcobase + 0x04);
+	/* set status bits are cleared by writing 1 to them */
+	outl(reg32 & ~(1<<18), tcobase + 0x04); //  Don't clear BOOT_STS before SECOND_TO_STS
+	if (reg32 & (1 << 18))
+		outl(reg32 & (1<<18), tcobase + 0x04); // clear BOOT_STS
+
+	return reg32;
+}
+
+
+static void dump_tco_status(u32 tco_sts)
+{
+	printk_debug("TCO_STS: ");
+	if (tco_sts & (1 << 20)) printk_debug("SMLINK_SLV ");
+	if (tco_sts & (1 << 18)) printk_debug("BOOT ");
+	if (tco_sts & (1 << 17)) printk_debug("SECOND_TO ");
+	if (tco_sts & (1 << 16)) printk_debug("INTRD_DET ");
+	if (tco_sts & (1 << 12)) printk_debug("DMISERR ");
+	if (tco_sts & (1 << 10)) printk_debug("DMISMI ");
+	if (tco_sts & (1 <<  9)) printk_debug("DMISCI ");
+	if (tco_sts & (1 <<  8)) printk_debug("BIOSWR ");
+	if (tco_sts & (1 <<  7)) printk_debug("NEWCENTURY ");
+	if (tco_sts & (1 <<  3)) printk_debug("TIMEOUT ");
+	if (tco_sts & (1 <<  2)) printk_debug("TCO_INT ");
+	if (tco_sts & (1 <<  1)) printk_debug("SW_TCO ");
+	if (tco_sts & (1 <<  0)) printk_debug("NMI2SMI ");
+	printk_debug("\n");
+}
+
+
+
+/**
+ * @brief Set the EOS bit
+ */
+static void smi_set_eos(void)
+{
+	u8 reg8;
+
+	reg8 = inb(pmbase + SMI_EN);
+	reg8 |= EOS;
+	outb(reg8, pmbase + SMI_EN);
+}
+
+extern uint8_t smm_relocation_start, smm_relocation_end;
+
+void smm_relocate(void)
+{
+	u32 smi_en;
+	u16 pm1_en;
+
+	printk_debug("Initializing SMM handler...");
+
+	pmbase = pci_read_config16(dev_find_slot(0, PCI_DEVFN(0x1f, 0)), 0x40) & 0xfffc;
+	printk_spew(" ... pmbase = 0x%04x\n", pmbase);
+
+	smi_en = inl(pmbase + SMI_EN);
+	if (smi_en & APMC_EN) {
+		printk_info("SMI# handler already enabled?\n");
+		return;
+	}
+
+	/* copy the SMM relocation code */
+	memcpy((void *)0x38000, &smm_relocation_start,
+			&smm_relocation_end - &smm_relocation_start);
+
+	printk_debug("\n");
+	dump_smi_status(reset_smi_status());
+	dump_pm1_status(reset_pm1_status());
+	dump_gpe0_status(reset_gpe0_status());
+	dump_alt_gp_smi_status(reset_alt_gp_smi_status());
+	dump_tco_status(reset_tco_status());
+
+	/* Enable SMI generation:
+	 *  - on TCO events
+	 *  - on APMC writes (io 0xb2)
+	 *  - on writes to SLP_EN (sleep states)
+	 *  - on writes to GBL_RLS (bios commands)
+	 * No SMIs:
+	 *  - on microcontroller writes (io 0x62/0x66)
+	 */
+
+	smi_en = 0; /* reset SMI enables */
+
+#if 0
+	smi_en |= LEGACY_USB2_EN | LEGACY_USB_EN;
+#endif
+	smi_en |= TCO_EN;
+	smi_en |= APMC_EN;
+#if DEBUG_PERIODIC_SMIS
+	/* Set DEBUG_PERIODIC_SMIS in i82801gx.h to debug using
+	 * periodic SMIs.
+	 */
+	smi_en |= PERIODIC_EN;
+#endif
+	smi_en |= SLP_SMI_EN;
+	smi_en |= BIOS_EN;
+
+	/* The following need to be on for SMIs to happen */
+	smi_en |= EOS | GBL_SMI_EN;
+
+	outl(smi_en, pmbase + SMI_EN);
+
+	pm1_en = 0;
+	pm1_en |= PWRBTN_EN;
+	pm1_en |= GBL_EN;
+	outw(pm1_en, pmbase + PM1_EN);
+
+	/**
+	 * There are several methods of raising a controlled SMI# via
+	 * software, among them:
+	 *  - Writes to io 0xb2 (APMC)
+	 *  - Writes to the Local Apic ICR with Delivery mode SMI.
+	 *
+	 * Using the local apic is a bit more tricky. According to
+	 * AMD Family 11 Processor BKDG no destination shorthand must be
+	 * used.
+	 * The whole SMM initialization is quite a bit hardware specific, so
+	 * I'm not too worried about the better of the methods at the moment
+	 */
+
+	/* raise an SMI interrupt */
+	printk_spew("  ... raise SMI#\n");
+	outb(0x00, 0xb2);
+}
+
+void smm_install(void)
+{
+	/* enable the SMM memory window */
+	pci_write_config8(dev_find_slot(0, PCI_DEVFN(0, 0)), SMRAM,
+				D_OPEN | G_SMRAME | C_BASE_SEG);
+
+	/* copy the real SMM handler */
+	memcpy((void *)0xa0000, smm, smm_len);
+	wbinvd();
+
+	/* close the SMM memory window and enable normal SMM */
+	pci_write_config8(dev_find_slot(0, PCI_DEVFN(0, 0)), SMRAM,
+			G_SMRAME | C_BASE_SEG);
+}
+
+void smm_init(void)
+{
+	// FIXME is this a race condition?
+	smm_relocate();
+	smm_install();
+
+	// We're done. Make sure SMIs can happen!
+	smi_set_eos();
+}
+
+void smm_lock(void)
+{
+	/* LOCK the SMM memory window and enable normal SMM.
+	 * After running this function, only a full reset can
+	 * make the SMM registers writable again.
+	 */
+	printk_debug("Locking SMM.\n");
+	pci_write_config8(dev_find_slot(0, PCI_DEVFN(0, 0)), SMRAM,
+			D_LCK | G_SMRAME | C_BASE_SEG);
+}
+
+void smm_setup_structures(void *gnvs, void *tcg, void *smi1)
+{
+	/* The GDT or coreboot table is going to live here. But a long time
+	 * after we relocated the GNVS, so this is not troublesome.
+	 */
+	*(u32 *)0x500 = (u32)gnvs;
+	*(u32 *)0x504 = (u32)tcg;
+	*(u32 *)0x508 = (u32)smi1;
+	outb(0xea, 0xb2);
+}

Added: trunk/src/southbridge/intel/i82801dx/i82801dx_smihandler.c
==============================================================================
--- /dev/null	00:00:00 1970	(empty, because file is newly added)
+++ trunk/src/southbridge/intel/i82801dx/i82801dx_smihandler.c	Mon Mar  1 09:34:19 2010	(r5177)
@@ -0,0 +1,669 @@
+/*
+ * This file is part of the coreboot project.
+ *
+ * Copyright (C) 2008-2009 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; version 2 of
+ * the License.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 51 Franklin St, Fifth Floor, Boston,
+ * MA 02110-1301 USA
+ */
+
+#include <types.h>
+#include <arch/io.h>
+#include <arch/romcc_io.h>
+#include <console/console.h>
+#include <cpu/x86/cache.h>
+#include <cpu/x86/smm.h>
+#include <device/pci_def.h>
+#include "i82801dx.h"
+
+#define DEBUG_SMI
+
+#define APM_CNT		0xb2
+#define   CST_CONTROL	0x85
+#define   PST_CONTROL	0x80
+#define   ACPI_DISABLE	0x1e
+#define   ACPI_ENABLE	0xe1
+#define   GNVS_UPDATE   0xea
+#define   MBI_UPDATE    0xeb
+#define APM_STS		0xb3
+
+/* I830M */
+#define SMRAM		0x90
+#define   D_OPEN	(1 << 6)
+#define   D_CLS		(1 << 5)
+#define   D_LCK		(1 << 4)
+#define   G_SMRANE	(1 << 3)
+#define   C_BASE_SEG	((0 << 2) | (1 << 1) | (0 << 0))
+
+#include "i82801dx_nvs.h"
+
+/* While we read PMBASE dynamically in case it changed, let's
+ * initialize it with a sane value
+ */
+u16 pmbase = PMBASE_ADDR;
+u8 smm_initialized = 0;
+
+unsigned char *mbi = NULL;
+u32 mbi_len;
+u8 mbi_initialized = 0;
+
+/* GNVS needs to be updated by an 0xEA PM Trap (B2) after it has been located
+ * by coreboot.
+ */
+global_nvs_t *gnvs = (global_nvs_t *)0x0;
+void *tcg = (void *)0x0;
+void *smi1 = (void *)0x0;
+
+/**
+ * @brief read and clear PM1_STS
+ * @return PM1_STS register
+ */
+static u16 reset_pm1_status(void)
+{
+	u16 reg16;
+
+	reg16 = inw(pmbase + PM1_STS);
+	/* set status bits are cleared by writing 1 to them */
+	outw(reg16, pmbase + PM1_STS);
+
+	return reg16;
+}
+
+static void dump_pm1_status(u16 pm1_sts)
+{
+	printk_spew("PM1_STS: ");
+	if (pm1_sts & (1 << 15)) printk_spew("WAK ");
+	if (pm1_sts & (1 << 14)) printk_spew("PCIEXPWAK ");
+	if (pm1_sts & (1 << 11)) printk_spew("PRBTNOR ");
+	if (pm1_sts & (1 << 10)) printk_spew("RTC ");
+	if (pm1_sts & (1 <<  8)) printk_spew("PWRBTN ");
+	if (pm1_sts & (1 <<  5)) printk_spew("GBL ");
+	if (pm1_sts & (1 <<  4)) printk_spew("BM ");
+	if (pm1_sts & (1 <<  0)) printk_spew("TMROF ");
+	printk_spew("\n");
+	int reg16 = inw(pmbase + PM1_EN);
+	printk_spew("PM1_EN: %x\n", reg16);
+}
+
+/**
+ * @brief read and clear SMI_STS
+ * @return SMI_STS register
+ */
+static u32 reset_smi_status(void)
+{
+	u32 reg32;
+
+	reg32 = inl(pmbase + SMI_STS);
+	/* set status bits are cleared by writing 1 to them */
+	outl(reg32, pmbase + SMI_STS);
+
+	return reg32;
+}
+
+static void dump_smi_status(u32 smi_sts)
+{
+	printk_debug("SMI_STS: ");
+	if (smi_sts & (1 << 26)) printk_debug("SPI ");
+	if (smi_sts & (1 << 25)) printk_debug("EL_SMI ");
+	if (smi_sts & (1 << 21)) printk_debug("MONITOR ");
+	if (smi_sts & (1 << 20)) printk_debug("PCI_EXP_SMI ");
+	if (smi_sts & (1 << 18)) printk_debug("INTEL_USB2 ");
+	if (smi_sts & (1 << 17)) printk_debug("LEGACY_USB2 ");
+	if (smi_sts & (1 << 16)) printk_debug("SMBUS_SMI ");
+	if (smi_sts & (1 << 15)) printk_debug("SERIRQ_SMI ");
+	if (smi_sts & (1 << 14)) printk_debug("PERIODIC ");
+	if (smi_sts & (1 << 13)) printk_debug("TCO ");
+	if (smi_sts & (1 << 12)) printk_debug("DEVMON ");
+	if (smi_sts & (1 << 11)) printk_debug("MCSMI ");
+	if (smi_sts & (1 << 10)) printk_debug("GPI ");
+	if (smi_sts & (1 <<  9)) printk_debug("GPE0 ");
+	if (smi_sts & (1 <<  8)) printk_debug("PM1 ");
+	if (smi_sts & (1 <<  6)) printk_debug("SWSMI_TMR ");
+	if (smi_sts & (1 <<  5)) printk_debug("APM ");
+	if (smi_sts & (1 <<  4)) printk_debug("SLP_SMI ");
+	if (smi_sts & (1 <<  3)) printk_debug("LEGACY_USB ");
+	if (smi_sts & (1 <<  2)) printk_debug("BIOS ");
+	printk_debug("\n");
+}
+
+
+/**
+ * @brief read and clear GPE0_STS
+ * @return GPE0_STS register
+ */
+static u32 reset_gpe0_status(void)
+{
+	u32 reg32;
+
+	reg32 = inl(pmbase + GPE0_STS);
+	/* set status bits are cleared by writing 1 to them */
+	outl(reg32, pmbase + GPE0_STS);
+
+	return reg32;
+}
+
+static void dump_gpe0_status(u32 gpe0_sts)
+{
+	int i;
+	printk_debug("GPE0_STS: ");
+	for (i=31; i<= 16; i--) {
+		if (gpe0_sts & (1 << i)) printk_debug("GPIO%d ", (i-16));
+	}
+	if (gpe0_sts & (1 << 14)) printk_debug("USB4 ");
+	if (gpe0_sts & (1 << 13)) printk_debug("PME_B0 ");
+	if (gpe0_sts & (1 << 12)) printk_debug("USB3 ");
+	if (gpe0_sts & (1 << 11)) printk_debug("PME ");
+	if (gpe0_sts & (1 << 10)) printk_debug("EL_SCI/BATLOW ");
+	if (gpe0_sts & (1 <<  9)) printk_debug("PCI_EXP ");
+	if (gpe0_sts & (1 <<  8)) printk_debug("RI ");
+	if (gpe0_sts & (1 <<  7)) printk_debug("SMB_WAK ");
+	if (gpe0_sts & (1 <<  6)) printk_debug("TCO_SCI ");
+	if (gpe0_sts & (1 <<  5)) printk_debug("AC97 ");
+	if (gpe0_sts & (1 <<  4)) printk_debug("USB2 ");
+	if (gpe0_sts & (1 <<  3)) printk_debug("USB1 ");
+	if (gpe0_sts & (1 <<  2)) printk_debug("HOT_PLUG ");
+	if (gpe0_sts & (1 <<  0)) printk_debug("THRM ");
+	printk_debug("\n");
+}
+
+
+/**
+ * @brief read and clear TCOx_STS
+ * @return TCOx_STS registers
+ */
+static u32 reset_tco_status(void)
+{
+	u32 tcobase = pmbase + 0x60;
+	u32 reg32;
+
+	reg32 = inl(tcobase + 0x04);
+	/* set status bits are cleared by writing 1 to them */
+	outl(reg32 & ~(1<<18), tcobase + 0x04); //  Don't clear BOOT_STS before SECOND_TO_STS
+	if (reg32 & (1 << 18))
+		outl(reg32 & (1<<18), tcobase + 0x04); // clear BOOT_STS
+
+	return reg32;
+}
+
+
+static void dump_tco_status(u32 tco_sts)
+{
+	printk_debug("TCO_STS: ");
+	if (tco_sts & (1 << 20)) printk_debug("SMLINK_SLV ");
+	if (tco_sts & (1 << 18)) printk_debug("BOOT ");
+	if (tco_sts & (1 << 17)) printk_debug("SECOND_TO ");
+	if (tco_sts & (1 << 16)) printk_debug("INTRD_DET ");
+	if (tco_sts & (1 << 12)) printk_debug("DMISERR ");
+	if (tco_sts & (1 << 10)) printk_debug("DMISMI ");
+	if (tco_sts & (1 <<  9)) printk_debug("DMISCI ");
+	if (tco_sts & (1 <<  8)) printk_debug("BIOSWR ");
+	if (tco_sts & (1 <<  7)) printk_debug("NEWCENTURY ");
+	if (tco_sts & (1 <<  3)) printk_debug("TIMEOUT ");
+	if (tco_sts & (1 <<  2)) printk_debug("TCO_INT ");
+	if (tco_sts & (1 <<  1)) printk_debug("SW_TCO ");
+	if (tco_sts & (1 <<  0)) printk_debug("NMI2SMI ");
+	printk_debug("\n");
+}
+
+/* We are using PCIe accesses for now
+ *  1. the chipset can do it
+ *  2. we don't need to worry about how we leave 0xcf8/0xcfc behind
+ */
+// #include "../../../northbridge/intel/i945/pcie_config.c"
+
+int southbridge_io_trap_handler(int smif)
+{
+	switch (smif) {
+	case 0x32:
+		printk_debug("OS Init\n");
+		/* gnvs->smif:
+		 *  On success, the IO Trap Handler returns 0
+		 *  On failure, the IO Trap Handler returns a value != 0
+		 */
+		gnvs->smif = 0;
+		return 1; /* IO trap handled */
+	}
+
+	/* Not handled */
+	return 0;
+}
+
+/**
+ * @brief Set the EOS bit
+ */
+void southbridge_smi_set_eos(void)
+{
+	u8 reg8;
+
+	reg8 = inb(pmbase + SMI_EN);
+	reg8 |= EOS;
+	outb(reg8, pmbase + SMI_EN);
+}
+
+static void busmaster_disable_on_bus(int bus)
+{
+        int slot, func;
+        unsigned int val;
+        unsigned char hdr;
+
+        for (slot = 0; slot < 0x20; slot++) {
+                for (func = 0; func < 8; func++) {
+                        u32 reg32;
+                        device_t dev = PCI_DEV(bus, slot, func);
+
+                        val = pci_read_config32(dev, PCI_VENDOR_ID);
+
+                        if (val == 0xffffffff || val == 0x00000000 ||
+                            val == 0x0000ffff || val == 0xffff0000)
+                                continue;
+
+                        /* Disable Bus Mastering for this one device */
+                        reg32 = pci_read_config32(dev, PCI_COMMAND);
+                        reg32 &= ~PCI_COMMAND_MASTER;
+                        pci_write_config32(dev, PCI_COMMAND, reg32);
+
+                        /* If this is a bridge, then follow it. */
+                        hdr = pci_read_config8(dev, PCI_HEADER_TYPE);
+                        hdr &= 0x7f;
+                        if (hdr == PCI_HEADER_TYPE_BRIDGE ||
+                            hdr == PCI_HEADER_TYPE_CARDBUS) {
+                                unsigned int buses;
+                                buses = pci_read_config32(dev, PCI_PRIMARY_BUS);
+                                busmaster_disable_on_bus((buses >> 8) & 0xff);
+                        }
+                }
+        }
+}
+
+
+static void southbridge_smi_sleep(unsigned int node, smm_state_save_area_t *state_save)
+{
+	u8 reg8;
+	u32 reg32;
+	u8 slp_typ;
+	/* FIXME: the power state on boot should be read from
+	 * CMOS or even better from GNVS. Right now it's hard
+	 * coded at compile time.
+	 */
+	u8 s5pwr = CONFIG_MAINBOARD_POWER_ON_AFTER_POWER_FAIL;
+
+	/* First, disable further SMIs */
+	reg8 = inb(pmbase + SMI_EN);
+	reg8 &= ~SLP_SMI_EN;
+	outb(reg8, pmbase + SMI_EN);
+
+	/* Figure out SLP_TYP */
+	reg32 = inl(pmbase + PM1_CNT);
+	printk_spew("SMI#: SLP = 0x%08x\n", reg32);
+	slp_typ = (reg32 >> 10) & 7;
+
+	/* Next, do the deed.
+	 */
+
+	switch (slp_typ) {
+	case 0: printk_debug("SMI#: Entering S0 (On)\n"); break;
+	case 1: printk_debug("SMI#: Entering S1 (Assert STPCLK#)\n"); break;
+	case 5:
+		printk_debug("SMI#: Entering S3 (Suspend-To-RAM)\n");
+		/* Invalidate the cache before going to S3 */
+		wbinvd();
+		break;
+	case 6: printk_debug("SMI#: Entering S4 (Suspend-To-Disk)\n"); break;
+	case 7:
+		printk_debug("SMI#: Entering S5 (Soft Power off)\n");
+
+		outl(0, pmbase + GPE0_EN);
+
+		/* Should we keep the power state after a power loss?
+		 * In case the setting is "ON" or "OFF" we don't have
+		 * to do anything. But if it's "KEEP" we have to switch
+		 * to "OFF" before entering S5.
+		 */
+		if (s5pwr == MAINBOARD_POWER_KEEP) {
+			reg8 = pci_read_config8(PCI_DEV(0, 0x1f, 0), GEN_PMCON_3);
+			reg8 |= 1;
+			pci_write_config8(PCI_DEV(0, 0x1f, 0), GEN_PMCON_3, reg8);
+		}
+
+		/* also iterates over all bridges on bus 0 */
+		busmaster_disable_on_bus(0);
+		break;
+	default: printk_debug("SMI#: ERROR: SLP_TYP reserved\n"); break;
+	}
+
+	/* Write back to the SLP register to cause the originally intended
+	 * event again. We need to set BIT13 (SLP_EN) though to make the
+	 * sleep happen.
+	 */
+	outl(reg32 | SLP_EN, pmbase + PM1_CNT);
+
+	/* In most sleep states, the code flow of this function ends at
+	 * the line above. However, if we entered sleep state S1 and wake
+	 * up again, we will continue to execute code in this function.
+	 */
+	reg32 = inl(pmbase + PM1_CNT);
+	if (reg32 & SCI_EN) {
+		/* The OS is not an ACPI OS, so we set the state to S0 */
+		reg32 &= ~(SLP_EN | SLP_TYP);
+		outl(reg32, pmbase + PM1_CNT);
+	}
+}
+
+static void southbridge_smi_apmc(unsigned int node, smm_state_save_area_t *state_save)
+{
+	u32 pmctrl;
+	u8 reg8;
+
+	/* Emulate B2 register as the FADT / Linux expects it */
+
+	reg8 = inb(APM_CNT);
+	switch (reg8) {
+	case CST_CONTROL:
+		/* Calling this function seems to cause
+		 * some kind of race condition in Linux
+		 * and causes a kernel oops
+		 */
+		printk_debug("C-state control\n");
+		break;
+	case PST_CONTROL:
+		/* Calling this function seems to cause
+		 * some kind of race condition in Linux
+		 * and causes a kernel oops
+		 */
+		printk_debug("P-state control\n");
+		break;
+	case ACPI_DISABLE:
+		pmctrl = inl(pmbase + PM1_CNT);
+		pmctrl &= ~SCI_EN;
+		outl(pmctrl, pmbase + PM1_CNT);
+		printk_debug("SMI#: ACPI disabled.\n");
+		break;
+	case ACPI_ENABLE:
+		pmctrl = inl(pmbase + PM1_CNT);
+		pmctrl |= SCI_EN;
+		outl(pmctrl, pmbase + PM1_CNT);
+		printk_debug("SMI#: ACPI enabled.\n");
+		break;
+	case GNVS_UPDATE:
+		if (smm_initialized) {
+			printk_debug("SMI#: SMM structures already initialized!\n");
+			return;
+		}
+		gnvs = *(global_nvs_t **)0x500;
+		tcg  = *(void **)0x504;
+		smi1 = *(void **)0x508;
+		smm_initialized = 1;
+		printk_debug("SMI#: Setting up structures to %p, %p, %p\n", gnvs, tcg, smi1);
+		break;
+	case MBI_UPDATE: // FIXME
+		if (mbi_initialized) {
+			printk_debug("SMI#: mbi already registered!\n");
+			return;
+		}
+		mbi = *(void **)0x500;
+		mbi_len = *(u32 *)0x504;
+		mbi_initialized = 1;
+		printk_debug("SMI#: Registered MBI at %p (%d bytes)\n", mbi, mbi_len);
+		break;
+
+	default:
+		printk_debug("SMI#: Unknown function APM_CNT=%02x\n", reg8);
+	}
+}
+
+static void southbridge_smi_pm1(unsigned int node, smm_state_save_area_t *state_save)
+{
+	u16 pm1_sts;
+
+	pm1_sts = reset_pm1_status();
+	dump_pm1_status(pm1_sts);
+
+	/* While OSPM is not active, poweroff immediately
+	 * on a power button event.
+	 */
+	if (pm1_sts & PWRBTN_STS) {
+		// power button pressed
+		u32 reg32;
+		reg32 = (7 << 10) | (1 << 13);
+		outl(reg32, pmbase + PM1_CNT);
+	}
+}
+
+static void southbridge_smi_gpe0(unsigned int node, smm_state_save_area_t *state_save)
+{
+	u32 gpe0_sts;
+
+	gpe0_sts = reset_gpe0_status();
+	dump_gpe0_status(gpe0_sts);
+}
+
+void __attribute__((weak)) mainboard_smi_gpi(u16 gpi_sts);
+
+static void southbridge_smi_gpi(unsigned int node, smm_state_save_area_t *state_save)
+{
+	u16 reg16;
+	reg16 = inw(pmbase + ALT_GP_SMI_STS);
+	outl(reg16, pmbase + ALT_GP_SMI_STS);
+
+	reg16 &= inw(pmbase + ALT_GP_SMI_EN);
+
+	if (mainboard_smi_gpi) {
+		mainboard_smi_gpi(reg16);
+	} else {
+		if (reg16)
+			printk_debug("GPI (mask %04x)\n",reg16);
+	}
+}
+
+static void southbridge_smi_mc(unsigned int node, smm_state_save_area_t *state_save)
+{
+	u32 reg32;
+
+	reg32 = inl(pmbase + SMI_EN);
+
+	/* Are periodic SMIs enabled? */
+	if ((reg32 & MCSMI_EN) == 0)
+		return;
+
+	printk_debug("Microcontroller SMI.\n");
+}
+
+
+
+static void southbridge_smi_tco(unsigned int node, smm_state_save_area_t *state_save)
+{
+	u32 tco_sts;
+
+	tco_sts = reset_tco_status();
+
+	/* Any TCO event? */
+	if (!tco_sts)
+		return;
+
+	if (tco_sts & (1 << 8)) { // BIOSWR
+		u8 bios_cntl;
+
+		bios_cntl = pci_read_config16(PCI_DEV(0, 0x1f, 0), 0xdc);
+
+		if (bios_cntl & 1) {
+			/* BWE is RW, so the SMI was caused by a
+			 * write to BWE, not by a write to the BIOS
+			 */
+
+			/* This is the place where we notice someone
+			 * is trying to tinker with the BIOS. We are
+			 * trying to be nice and just ignore it. A more
+			 * resolute answer would be to power down the
+			 * box.
+			 */
+			printk_debug("Switching back to RO\n");
+			pci_write_config32(PCI_DEV(0, 0x1f, 0), 0xdc, (bios_cntl & ~1));
+		} /* No else for now? */
+	} else if (tco_sts & (1 << 3)) { /* TIMEOUT */
+		/* Handle TCO timeout */
+		printk_debug("TCO Timeout.\n");
+	} else if (!tco_sts) {
+		dump_tco_status(tco_sts);
+	}
+}
+
+static void southbridge_smi_periodic(unsigned int node, smm_state_save_area_t *state_save)
+{
+	u32 reg32;
+
+	reg32 = inl(pmbase + SMI_EN);
+
+	/* Are periodic SMIs enabled? */
+	if ((reg32 & PERIODIC_EN) == 0)
+		return;
+
+	printk_debug("Periodic SMI.\n");
+}
+
+static void southbridge_smi_monitor(unsigned int node, smm_state_save_area_t *state_save)
+{
+#define IOTRAP(x) (trap_sts & (1 << x))
+#if 0
+	u32 trap_sts, trap_cycle;
+	u32 data, mask = 0;
+	int i;
+
+	trap_sts = RCBA32(0x1e00); // TRSR - Trap Status Register
+	RCBA32(0x1e00) = trap_sts; // Clear trap(s) in TRSR
+
+	trap_cycle = RCBA32(0x1e10);
+	for (i=16; i<20; i++) {
+		if (trap_cycle & (1 << i))
+			mask |= (0xff << ((i - 16) << 2));
+	}
+
+
+	/* IOTRAP(3) SMI function call */
+	if (IOTRAP(3)) {
+		if (gnvs && gnvs->smif)
+			io_trap_handler(gnvs->smif); // call function smif
+		return;
+	}
+
+	/* IOTRAP(2) currently unused
+	 * IOTRAP(1) currently unused */
+
+	/* IOTRAP(0) SMIC */
+	if (IOTRAP(0)) {
+		if (!(trap_cycle & (1 << 24))) { // It's a write
+			printk_debug("SMI1 command\n");
+			data = RCBA32(0x1e18);
+			data &= mask;
+			// if (smi1)
+			// 	southbridge_smi_command(data);
+			// return;
+		}
+		// Fall through to debug
+	}
+
+	printk_debug("  trapped io address = 0x%x\n", trap_cycle & 0xfffc);
+	for (i=0; i < 4; i++) if(IOTRAP(i)) printk_debug("  TRAP?= %d\n", i);
+	printk_debug("  AHBE = %x\n", (trap_cycle >> 16) & 0xf);
+	printk_debug("  MASK = 0x%08x\n", mask);
+	printk_debug("  read/write: %s\n", (trap_cycle & (1 << 24)) ? "read" : "write");
+
+	if (!(trap_cycle & (1 << 24))) {
+		/* Write Cycle */
+		data = RCBA32(0x1e18);
+		printk_debug("  iotrap written data = 0x%08x\n", data);
+	}
+#endif
+#undef IOTRAP
+}
+
+typedef void (*smi_handler)(unsigned int node,
+		smm_state_save_area_t *state_save);
+
+smi_handler southbridge_smi[32] = {
+	NULL,			  //  [0] reserved
+	NULL,			  //  [1] reserved
+	NULL,			  //  [2] BIOS_STS
+	NULL,			  //  [3] LEGACY_USB_STS
+	southbridge_smi_sleep,	  //  [4] SLP_SMI_STS
+	southbridge_smi_apmc,	  //  [5] APM_STS
+	NULL,			  //  [6] SWSMI_TMR_STS
+	NULL,			  //  [7] reserved
+	southbridge_smi_pm1,	  //  [8] PM1_STS
+	southbridge_smi_gpe0,	  //  [9] GPE0_STS
+	southbridge_smi_gpi,	  // [10] GPI_STS
+	southbridge_smi_mc,	  // [11] MCSMI_STS
+	NULL,			  // [12] DEVMON_STS
+	southbridge_smi_tco,	  // [13] TCO_STS
+	southbridge_smi_periodic, // [14] PERIODIC_STS
+	NULL,			  // [15] SERIRQ_SMI_STS
+	NULL,			  // [16] SMBUS_SMI_STS
+	NULL,			  // [17] LEGACY_USB2_STS
+	NULL,			  // [18] INTEL_USB2_STS
+	NULL,			  // [19] reserved
+	NULL,			  // [20] PCI_EXP_SMI_STS
+	southbridge_smi_monitor,  // [21] MONITOR_STS
+	NULL,			  // [22] reserved
+	NULL,			  // [23] reserved
+	NULL,			  // [24] reserved
+	NULL,			  // [25] EL_SMI_STS
+	NULL,			  // [26] SPI_STS
+	NULL,			  // [27] reserved
+	NULL,			  // [28] reserved
+	NULL,			  // [29] reserved
+	NULL,			  // [30] reserved
+	NULL			  // [31] reserved
+};
+
+/**
+ * @brief Interrupt handler for SMI#
+ *
+ * @param smm_revision revision of the smm state save map
+ */
+
+void southbridge_smi_handler(unsigned int node, smm_state_save_area_t *state_save)
+{
+	int i, dump = 0;
+	u32 smi_sts;
+
+	/* Update global variable pmbase */
+	pmbase = pci_read_config16(PCI_DEV(0, 0x1f, 0), 0x40) & 0xfffc;
+
+	/* We need to clear the SMI status registers, or we won't see what's
+	 * happening in the following calls.
+	 */
+	smi_sts = reset_smi_status();
+
+	/* Filter all non-enabled SMI events */
+	// FIXME Double check, this clears MONITOR
+	// smi_sts &= inl(pmbase + SMI_EN);
+
+	/* Call SMI sub handler for each of the status bits */
+	for (i = 0; i < 31; i++) {
+		if (smi_sts & (1 << i)) {
+			if (southbridge_smi[i])
+				southbridge_smi[i](node, state_save);
+			else {
+				printk_debug("SMI_STS[%d] occured, but no "
+						"handler available.\n", i);
+				dump = 1;
+			}
+		}
+	}
+
+	if(dump) {
+		dump_smi_status(smi_sts);
+	}
+
+}

Added: trunk/src/southbridge/intel/i82801dx/i82801dx_tco_timer.c
==============================================================================
--- /dev/null	00:00:00 1970	(empty, because file is newly added)
+++ trunk/src/southbridge/intel/i82801dx/i82801dx_tco_timer.c	Mon Mar  1 09:34:19 2010	(r5177)
@@ -0,0 +1,37 @@
+/*
+ * This file is part of the coreboot project.
+ *
+ * Copyright (C) 2008 Joseph Smith <joe at settoplinux.org>
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA  02110-1301 USA
+ *
+ */
+
+static void i82801dx_halt_tco_timer(void)
+{
+	device_t dev;
+	uint16_t halt_tco_timer;
+
+	/* Set the LPC device statically. */
+	dev = PCI_DEV(0x0, 0x1f, 0x0);
+
+	/* Temporarily set ACPI base address (I/O space). */
+	pci_write_config32(dev, PMBASE, (PMBASE_ADDR | 1));
+
+	/* Enable ACPI I/O. */
+	pci_write_config8(dev, ACPI_CNTL, 0x10);
+
+	/* Halt the TCO timer, preventing SMI and automatic reboot */
+	outw(inw(PMBASE_ADDR + TCOBASE + TCO1_CNT) | (1 << 11), PMBASE_ADDR + TCOBASE + TCO1_CNT);
+}

Modified: trunk/util/cbfstool/cbfs.h
==============================================================================
--- trunk/util/cbfstool/cbfs.h	Mon Mar  1 08:42:02 2010	(r5176)
+++ trunk/util/cbfstool/cbfs.h	Mon Mar  1 09:34:19 2010	(r5177)
@@ -68,9 +68,14 @@
     Users are welcome to use any other value for their
     components */
 
-#define CBFS_COMPONENT_STAGE     0x10
-#define CBFS_COMPONENT_PAYLOAD   0x20
-#define CBFS_COMPONENT_OPTIONROM 0x30
+#define CBFS_COMPONENT_STAGE      0x10
+#define CBFS_COMPONENT_PAYLOAD    0x20
+#define CBFS_COMPONENT_OPTIONROM  0x30
+#define CBFS_COMPONENT_BOOTSPLASH 0x40
+#define CBFS_COMPONENT_RAW        0x50
+#define CBFS_COMPONENT_VSA        0x51
+#define CBFS_COMPONENT_MBI        0x52
+#define CBFS_COMPONENT_MICROCODE  0x53
 
 /* The deleted type is chosen to be a value
  * that can be written in a FLASH from all other

Modified: trunk/util/cbfstool/common.c
==============================================================================
--- trunk/util/cbfstool/common.c	Mon Mar  1 08:42:02 2010	(r5176)
+++ trunk/util/cbfstool/common.c	Mon Mar  1 09:34:19 2010	(r5177)
@@ -128,6 +128,11 @@
 	{CBFS_COMPONENT_STAGE, "stage"},
 	{CBFS_COMPONENT_PAYLOAD, "payload"},
 	{CBFS_COMPONENT_OPTIONROM, "optionrom"},
+	{CBFS_COMPONENT_BOOTSPLASH, "bootsplash"},
+	{CBFS_COMPONENT_RAW, "raw"},
+	{CBFS_COMPONENT_VSA, "vsa"},
+	{CBFS_COMPONENT_MBI, "mbi"},
+	{CBFS_COMPONENT_MICROCODE, "microcode"},
 	{CBFS_COMPONENT_DELETED, "deleted"},
 	{CBFS_COMPONENT_NULL, "null"}
 };

Modified: trunk/util/x86emu/yabel/vbe.c
==============================================================================
--- trunk/util/x86emu/yabel/vbe.c	Mon Mar  1 08:42:02 2010	(r5176)
+++ trunk/util/x86emu/yabel/vbe.c	Mon Mar  1 09:34:19 2010	(r5177)
@@ -795,12 +795,11 @@
 	 * cares. */
 	int imagesize = 1024*768*2;
 	
-	struct cbfs_file *file = cbfs_find("bootsplash.jpg");
-	if (!file) { 
+	unsigned char *jpeg = cbfs_find_file("bootsplash.jpg", CBFS_TYPE_BOOTSPLASH);
+	if (!jpeg) { 
 		DEBUG_PRINTF_VBE("Could not find bootsplash.jpg\n");
 		return;
 	}
-	unsigned char *jpeg = ((unsigned char *)file) + ntohl(file->offset);
 	DEBUG_PRINTF_VBE("Splash at %08x ...\n", jpeg);
 	dump(jpeg, 64);
 



From info at coresystems.de  Mon Mar  1 09:53:03 2010
From: info at coresystems.de (coreboot information)
Date: Mon, 01 Mar 2010 09:53:03 +0100
Subject: [coreboot] build service results for r5177
Message-ID: <E1Nm1N9-0003O6-U2@ra.coresystems.de>

Dear coreboot readers!

This is the automatic build system of coreboot.

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

Change Log:

This patch implements MBI (modular bios interface) support to the i830 chipset.
This is needed on the IP1000T to get VGA output. The VGA option rom will ask
through an SMI for hardware specifics (in form of a VBT, video bios table)
which the SMI handler copies into the VGA option rom.

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



Build Log:
Compilation of rca:rm4100 has been broken
See the error log at http://qa.coreboot.org/log_buildbrd.php?revision=5177&device=rm4100&vendor=rca&num=2
Compilation of thomson:ip1000 has been broken
See the error log at http://qa.coreboot.org/log_buildbrd.php?revision=5177&device=ip1000&vendor=thomson&num=2


If something broke during this checkin please be a pain 
in stepan'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 Mar  1 10:09:33 2010
From: svn at coreboot.org (repository service)
Date: Mon, 01 Mar 2010 10:09:33 +0100
Subject: [coreboot] [commit] r5178 - trunk/src/northbridge/intel/i82830
Message-ID: <E1Nm1d7-0005Sm-Sr@ra.coresystems.de>

Author: stepan
Date: Mon Mar  1 10:09:33 2010
New Revision: 5178
URL: http://tracker.coreboot.org/trac/coreboot/changeset/5178

Log:
Fix YABEL guards; make debugging optional; fix some warnings
Signed-off-by: Stefan Reinauer <stepan at coresystems.de>
Acked-by: Stefan Reinauer <stepan at coresystems.de>

Modified:
   trunk/src/northbridge/intel/i82830/i82830_smihandler.c

Modified: trunk/src/northbridge/intel/i82830/i82830_smihandler.c
==============================================================================
--- trunk/src/northbridge/intel/i82830/i82830_smihandler.c	Mon Mar  1 09:34:19 2010	(r5177)
+++ trunk/src/northbridge/intel/i82830/i82830_smihandler.c	Mon Mar  1 10:09:33 2010	(r5178)
@@ -32,12 +32,12 @@
 extern unsigned char *mbi;
 extern u32 mbi_len;
 
-#define DEBUG_SMI
+// #define DEBUG_SMI_I82830
 
 /* If YABEL is enabled and it's not running at 0x00000000, we have to add some
  * offset to all our mbi object memory accesses
  */
-#if defined(CONFIG_PCI_OPTION_ROM_RUN_YABEL) && !defined(CONFIG_YABEL_DIRECTHW)
+#if defined(CONFIG_PCI_OPTION_ROM_RUN_YABEL) && CONFIG_PCI_OPTION_ROM_RUN_YABEL && !CONFIG_YABEL_DIRECTHW
 #define OBJ_OFFSET CONFIG_YABEL_VIRTMEM_LOCATION
 #else
 #define OBJ_OFFSET 0x00000
@@ -76,6 +76,7 @@
 #define MSH_IF_BUF_SIZE		0x010b
 #define MSH_IF_NOT_PENDING	0x010c
 
+#ifdef DEBUG_SMI_I82830
 static void
 dump(u8 * addr, u32 len)
 {
@@ -109,6 +110,7 @@
 	}
 	printk_debug("\n");
 }
+#endif
 
 typedef struct {
 	banner_id_t banner;
@@ -147,13 +149,15 @@
 
 static void mbi_call(u8 subf, banner_id_t *banner_id)
 {
-	// printk_debug("MBI\n");
-	// printk_debug("|- sub function %x\n", subf);
-	// printk_debug("|- banner id @ %x\n", (u32)banner_id);
-	// printk_debug("|  |- mhid %x\n", banner_id->mhid);
-	// printk_debug("|  |- function %x\n", banner_id->function);
-	// printk_debug("|  |- return status %x\n", banner_id->retsts);
-	// printk_debug("|  |- rfu %x\n", banner_id->rfu);
+#ifdef DEBUG_SMI_I82830
+	printk_debug("MBI\n");
+	printk_debug("|- sub function %x\n", subf);
+	printk_debug("|- banner id @ %x\n", (u32)banner_id);
+	printk_debug("|  |- mhid %x\n", banner_id->mhid);
+	printk_debug("|  |- function %x\n", banner_id->function);
+	printk_debug("|  |- return status %x\n", banner_id->retsts);
+	printk_debug("|  |- rfu %x\n", banner_id->rfu);
+#endif
 
 	switch(banner_id->function) {
 	case 0x0001: {
@@ -196,15 +200,19 @@
 			
 			if (obj_header->objnum == count) {
 				int headerlen = ALIGN(sizeof(mbi_header) + mbi_header->name_len + 15, 16);
-				// printk_debug("|  |- headerlen = %d\n", headerlen);
+#ifdef DEBUG_SMI_I82830
+				printk_debug("|  |- headerlen = %d\n", headerlen);
+#endif
 				memcpy(&obj_header->header, mbi_header, headerlen);
 				obj_header->banner.retsts = MSH_OK;
 				printk_debug("|     |- MBI module '");
 				int j;
 				for (j=0; j < mbi_header->name_len && mbi_header->name[j]; j++)
 					printk_debug("%c",  mbi_header->name[j]);
-				printk_debug("' found.\n", obj_header->objnum);
-				// dump(banner_id, sizeof(obj_header_t) + 16);
+				printk_debug("' found.\n");
+#ifdef DEBUG_SMI_I82830
+				dump(banner_id, sizeof(obj_header_t) + 16);
+#endif
 				break;
 			}
 			i += len;
@@ -218,7 +226,9 @@
 		get_object_t *getobj = (get_object_t *)banner_id;
 		mbi_header_t *mbi_header = NULL;
 		printk_debug("|- MBI_GetObject\n");
-		// printk_debug("|  |- handle = %016lx\n", getobj->handle);
+#ifdef DEBUG_SMI_I82830
+		printk_debug("|  |- handle = %016lx\n", getobj->handle);
+#endif
 		printk_debug("|  |- objnum = %d\n", getobj->objnum);
 		printk_debug("|  |- start = %x\n", getobj->start);
 		printk_debug("|  |- numbytes = %x\n", getobj->numbytes);
@@ -245,7 +255,9 @@
 						((char *)mbi_header) + 0x20 , (len > getobj->buflen ? getobj->buflen : len));
 
 				getobj->banner.retsts = MSH_OK;
-				//dump(banner_id, sizeof(getobj) + len);
+#ifdef DEBUG_SMI_I82830
+				dump(banner_id, sizeof(getobj) + len);
+#endif
 				break;
 			}
 			i += len;
@@ -275,15 +287,12 @@
 #define PC12	0x12
 #define PC13	0x13
 
-void smi_interface_call(void)
+static void smi_interface_call(void)
 {
-	u32 mmio;
-	mmio = pci_read_config32(PCI_DEV(0, 0x02, 0), 0x14);
+	u32 mmio = pci_read_config32(PCI_DEV(0, 0x02, 0), 0x14);
 	// mmio &= 0xfff80000;
 	// printk_debug("mmio=%x\n", mmio);
-
-	u16 swsmi;
-	swsmi=pci_read_config16(PCI_DEV(0, 0x02, 0), 0xe0);
+	u16 swsmi = pci_read_config16(PCI_DEV(0, 0x02, 0), 0xe0);
 
 	if (!(swsmi & 1))
 		return;
@@ -299,7 +308,7 @@
 		swsmi &= 0xff;
 		swsmi |= (PC13 << 8);
 		pci_write_config16(PCI_DEV(0, 0x02, 0), 0xe0, swsmi);
-		// pathetic
+		// write magic
 		write32(mmio + 0x71428, 0x494e5443);
 		return;
 	case 4:
@@ -308,7 +317,7 @@
 		break;
 	case 5:
 		printk_debug("Call MBI Functions.\n");
-		mbi_call(swsmi >> 8, (banner_id_t *)((readl(mmio + 0x71428) & 0x000fffff) + OBJ_OFFSET) );
+		mbi_call(swsmi >> 8, (banner_id_t *)((read32(mmio + 0x71428) & 0x000fffff) + OBJ_OFFSET) );
 		// swsmi = 0x0000;
 		swsmi &= ~(7 << 5); // Exit: Result
 		swsmi |= (SMI_IFC_SUCCESS << 5);



From info at coresystems.de  Mon Mar  1 10:24:44 2010
From: info at coresystems.de (coreboot information)
Date: Mon, 01 Mar 2010 10:24:44 +0100
Subject: [coreboot] build service results for r5178
Message-ID: <E1Nm1ro-0007UF-2J@ra.coresystems.de>

Dear coreboot readers!

This is the automatic build system of coreboot.

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

Change Log:
Fix YABEL guards; make debugging optional; fix some warnings
Signed-off-by: Stefan Reinauer <stepan at coresystems.de>
Acked-by: Stefan Reinauer <stepan at coresystems.de>



Build Log:
Compilation of rca:rm4100 has been fixed
Compilation of thomson:ip1000 has been fixed


If something broke during this checkin please be a pain 
in stepan'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 Mar  1 11:30:09 2010
From: svn at coreboot.org (repository service)
Date: Mon, 01 Mar 2010 11:30:09 +0100
Subject: [coreboot] [commit] r5179 - in trunk/src: . northbridge/amd/amdht
Message-ID: <E1Nm2t7-000816-6B@ra.coresystems.de>

Author: oxygene
Date: Mon Mar  1 11:30:08 2010
New Revision: 5179
URL: http://tracker.coreboot.org/trac/coreboot/changeset/5179

Log:
Allow per-board setting of HT clock and width so
less than optimal PCB designs can still work reliably
with reduced clock.

Signed-off-by: Timothy Pearson <tpearson at raptorengineeringinc.com>
Acked-by: Patrick Georgi <patrick.georgi at coresystems.de>

Modified:
   trunk/src/Kconfig
   trunk/src/northbridge/amd/amdht/h3finit.c

Modified: trunk/src/Kconfig
==============================================================================
--- trunk/src/Kconfig	Mon Mar  1 10:09:33 2010	(r5178)
+++ trunk/src/Kconfig	Mon Mar  1 11:30:08 2010	(r5179)
@@ -56,6 +56,78 @@
 comment "CPU"
 source src/cpu/Kconfig
 comment "Northbridge"
+
+menu "HyperTransport Setup"
+	depends on (NORTHBRIDGE_AMD_AMDK8 || NORTHBRIDGE_AMD_AMDFAM10) && EXPERT
+
+choice
+	prompt "HyperTransport Frequency"
+	default LIMIT_HT_SPEED_AUTO
+	help
+	  This option sets the maximum permissible HyperTransport link frequency.
+	  Use of this option will only limit the autodetected HT frequency; it will not (and cannot) increase the frequency beyond the autodetected limits.
+	  This is primarily used to work around poorly designed or laid out HT traces on certain motherboards.
+
+config LIMIT_HT_SPEED_200
+	bool "Limit HT frequency to 200MHz"
+config LIMIT_HT_SPEED_400
+	bool "Limit HT frequency to 400MHz"
+config LIMIT_HT_SPEED_600
+	bool "Limit HT frequency to 600MHz"
+config LIMIT_HT_SPEED_800
+	bool "Limit HT frequency to 800MHz"
+config LIMIT_HT_SPEED_1000
+	bool "Limit HT frequency to 1.0GHz"
+config LIMIT_HT_SPEED_1200
+	bool "Limit HT frequency to 1.2GHz"
+config LIMIT_HT_SPEED_1400
+	bool "Limit HT frequency to 1.4GHz"
+config LIMIT_HT_SPEED_1600
+	bool "Limit HT frequency to 1.6GHz"
+config LIMIT_HT_SPEED_1800
+        bool "Limit HT frequency to 1.6GHz"
+config LIMIT_HT_SPEED_2000
+        bool "Limit HT frequency to 2.0GHz"
+config LIMIT_HT_SPEED_2200
+        bool "Limit HT frequency to 2.2GHz"
+config LIMIT_HT_SPEED_2400
+        bool "Limit HT frequency to 2.4GHz"
+config LIMIT_HT_SPEED_2600
+        bool "Limit HT frequency to 2.6GHz"
+config LIMIT_HT_SPEED_AUTO
+	bool "Autodetect HT frequency"
+endchoice
+
+choice
+	prompt "HyperTransport Downlink Width"
+	default LIMIT_HT_DOWN_WIDTH_16
+	help
+	  This option sets the maximum permissible HyperTransport link width.
+	  Use of this option will only limit the autodetected HT width; it will not (and cannot) increase the width beyond the autodetected limits.
+	  This is primarily used to work around poorly designed or laid out HT traces on certain motherboards.
+
+config LIMIT_HT_DOWN_WIDTH_8
+	bool "8 bits"
+config LIMIT_HT_DOWN_WIDTH_16
+	bool "16 bits"
+endchoice
+
+choice
+	prompt "HyperTransport Uplink Width"
+	default LIMIT_HT_UP_WIDTH_16
+	help
+	  This option sets the maximum permissible HyperTransport link width.
+	  Use of this option will only limit the autodetected HT width; it will not (and cannot) increase the width beyond the autodetected limits.
+	  This is primarily used to work around poorly designed or laid out HT traces on certain motherboards.
+
+config LIMIT_HT_UP_WIDTH_8
+	bool "8 bits"
+config LIMIT_HT_UP_WIDTH_16
+	bool "16 bits"
+endchoice
+
+endmenu
+
 source src/northbridge/Kconfig
 comment "Southbridge"
 source src/southbridge/Kconfig

Modified: trunk/src/northbridge/amd/amdht/h3finit.c
==============================================================================
--- trunk/src/northbridge/amd/amdht/h3finit.c	Mon Mar  1 10:09:33 2010	(r5178)
+++ trunk/src/northbridge/amd/amdht/h3finit.c	Mon Mar  1 11:30:08 2010	(r5179)
@@ -1327,9 +1327,51 @@
 
 	for (i = 0; i < pDat->TotalLinks*2; i += 2)
 	{
-		cbPCBFreqLimit = 0xFFFF;
+#if CONFIG_LIMIT_HT_SPEED_200
+		cbPCBFreqLimit = 0x0001;
+#elif CONFIG_LIMIT_HT_SPEED_300
+		cbPCBFreqLimit = 0x0003;
+#elif CONFIG_LIMIT_HT_SPEED_400
+		cbPCBFreqLimit = 0x0007;
+#elif CONFIG_LIMIT_HT_SPEED_500
+		cbPCBFreqLimit = 0x000F;
+#elif CONFIG_LIMIT_HT_SPEED_600
+		cbPCBFreqLimit = 0x001F;
+#elif CONFIG_LIMIT_HT_SPEED_800
+		cbPCBFreqLimit = 0x003F;
+#elif CONFIG_LIMIT_HT_SPEED_1000
+		cbPCBFreqLimit = 0x007F;
+#elif CONFIG_LIMIT_HT_SPEED_1200
+		cbPCBFreqLimit = 0x00FF;
+#elif CONFIG_LIMIT_HT_SPEED_1400
+		cbPCBFreqLimit = 0x01FF;
+#elif CONFIG_LIMIT_HT_SPEED_1600
+		cbPCBFreqLimit = 0x03FF;
+#elif CONFIG_LIMIT_HT_SPEED_1800
+		cbPCBFreqLimit = 0x07FF;
+#elif CONFIG_LIMIT_HT_SPEED_2000
+		cbPCBFreqLimit = 0x0FFF;
+#elif CONFIG_LIMIT_HT_SPEED_2200
+		cbPCBFreqLimit = 0x1FFF;
+#elif CONFIG_LIMIT_HT_SPEED_2400
+		cbPCBFreqLimit = 0x3FFF;
+#elif CONFIG_LIMIT_HT_SPEED_2600
+		cbPCBFreqLimit = 0x7FFF;
+#else
+		cbPCBFreqLimit = 0xFFFF;		// Maximum allowed by autoconfiguration
+#endif
+
+#if CONFIG_LIMIT_HT_DOWN_WIDTH_8
+		cbPCBABDownstreamWidth = 8;
+#else
 		cbPCBABDownstreamWidth = 16;
+#endif
+
+#if CONFIG_LIMIT_HT_UP_WIDTH_8
+		cbPCBBAUpstreamWidth = 8;
+#else
 		cbPCBBAUpstreamWidth = 16;
+#endif
 
 		if ( (pDat->PortList[i].Type == PORTLIST_TYPE_CPU) && (pDat->PortList[i+1].Type == PORTLIST_TYPE_CPU))
 		{



From patrick at georgi-clan.de  Mon Mar  1 11:35:18 2010
From: patrick at georgi-clan.de (Patrick Georgi)
Date: Mon, 01 Mar 2010 11:35:18 +0100
Subject: [coreboot] AMD HT link frequency limit configuration patch
In-Reply-To: <50697.131.156.220.35.1267039833.squirrel@www.pearsoncomputing.net>
References: In-Reply-To: <50697.131.156.220.35.1267039833.squirrel@www.pearsoncomputing.net>
Message-ID: <4B8B9866.6010408@georgi-clan.de>

Am 24.02.2010 20:30, schrieb Timothy Pearson:
> This patch is critical for the MSI MS-9652 mainboard and Barcelona CPUs;
> without limiting the HT link the system was completely unstable due to bad
> PCB layout.
I can't test it due to lack of hardware, but it looks good.

> Signed-off-by: Timothy Pearson <tpearson at raptorengineeringinc.com>
Acked-by: Patrick Georgi <patrick.georgi at coresystems.de>

and committed as r5179


Patrick



From svn at coreboot.org  Mon Mar  1 11:56:52 2010
From: svn at coreboot.org (repository service)
Date: Mon, 01 Mar 2010 11:56:52 +0100
Subject: [coreboot] [commit] r5180 - in trunk/src/mainboard/msi: .
	ms9652_fam10
Message-ID: <E1Nm3Iy-0006u2-Ab@ra.coresystems.de>

Author: oxygene
Date: Mon Mar  1 11:56:51 2010
New Revision: 5180
URL: http://tracker.coreboot.org/trac/coreboot/changeset/5180

Log:
Add msi/ms9652_fam10 board.

Updated Timothy's patch to match recent changes in the tree. It's build tested.

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

Added:
   trunk/src/mainboard/msi/ms9652_fam10/
   trunk/src/mainboard/msi/ms9652_fam10/Kconfig
   trunk/src/mainboard/msi/ms9652_fam10/acpi_tables.c
   trunk/src/mainboard/msi/ms9652_fam10/chip.h
   trunk/src/mainboard/msi/ms9652_fam10/cmos.layout
   trunk/src/mainboard/msi/ms9652_fam10/devicetree.cb
   trunk/src/mainboard/msi/ms9652_fam10/dsdt.asl
   trunk/src/mainboard/msi/ms9652_fam10/get_bus_conf.c
   trunk/src/mainboard/msi/ms9652_fam10/irq_tables.c
   trunk/src/mainboard/msi/ms9652_fam10/mainboard.c
   trunk/src/mainboard/msi/ms9652_fam10/mb_sysconf.h
   trunk/src/mainboard/msi/ms9652_fam10/mptable.c
   trunk/src/mainboard/msi/ms9652_fam10/resourcemap.c
   trunk/src/mainboard/msi/ms9652_fam10/romstage.c
   trunk/src/mainboard/msi/ms9652_fam10/spd_addr.h
Modified:
   trunk/src/mainboard/msi/Kconfig

Modified: trunk/src/mainboard/msi/Kconfig
==============================================================================
--- trunk/src/mainboard/msi/Kconfig	Mon Mar  1 11:30:08 2010	(r5179)
+++ trunk/src/mainboard/msi/Kconfig	Mon Mar  1 11:56:51 2010	(r5180)
@@ -30,6 +30,7 @@
 source "src/mainboard/msi/ms7260/Kconfig"
 source "src/mainboard/msi/ms9185/Kconfig"
 source "src/mainboard/msi/ms9282/Kconfig"
+source "src/mainboard/msi/ms9652_fam10/Kconfig"
 
 endchoice
 

Added: trunk/src/mainboard/msi/ms9652_fam10/Kconfig
==============================================================================
--- /dev/null	00:00:00 1970	(empty, because file is newly added)
+++ trunk/src/mainboard/msi/ms9652_fam10/Kconfig	Mon Mar  1 11:56:51 2010	(r5180)
@@ -0,0 +1,288 @@
+config BOARD_MSI_MS9652_FAM10
+	bool "MS9652 Fam10 (Speedster K9ND)"
+	select ARCH_X86
+	select CPU_AMD_SOCKET_F_1207
+	select NORTHBRIDGE_AMD_AMDFAM10
+	select NORTHBRIDGE_AMD_AMDFAM10_ROOT_COMPLEX
+	select SOUTHBRIDGE_NVIDIA_MCP55
+	select SUPERIO_WINBOND_W83627EHG
+	select HAVE_BUS_CONFIG
+	select HAVE_PIRQ_TABLE
+	select HAVE_MP_TABLE
+	select USE_PRINTK_IN_CAR
+	select USE_DCACHE_RAM
+	select HAVE_HARD_RESET
+	select BOARD_ROMSIZE_KB_512
+	select ENABLE_APIC_EXT_ID
+	select AMDMCT
+	select TINY_BOOTBLOCK
+
+config MAINBOARD_DIR
+	string
+	default msi/ms9652_fam10
+	depends on BOARD_MSI_MS9652_FAM10
+
+config DCACHE_RAM_BASE
+	hex
+	default 0xc4000
+	depends on BOARD_MSI_MS9652_FAM10
+
+config DCACHE_RAM_SIZE
+	hex
+	default 0x0c000
+	depends on BOARD_MSI_MS9652_FAM10
+
+config DCACHE_RAM_GLOBAL_VAR_SIZE
+	hex
+	default 0x04000
+	depends on BOARD_MSI_MS9652_FAM10
+
+config CONFIG_ACPI_SSDTX_NUM
+	hex
+	default 0x1F
+	depends on BOARD_MSI_MS9652_FAM10
+
+config USE_FALLBACK_IMAGE
+	bool
+	default y
+	depends on BOARD_MSI_MS9652_FAM10
+
+config HAVE_FALLBACK_BOOT
+	bool
+	default y
+	depends on BOARD_MSI_MS9652_FAM10
+
+config CONFIG_USE_FAILOVER_IMAGE
+	bool
+	default y
+	depends on BOARD_MSI_MS9652_FAM10
+
+config CONFIG_HAVE_FAILOVER_BOOT
+	bool
+	default y
+	depends on BOARD_MSI_MS9652_FAM10
+
+config GENERATE_PIRQ_TABLE
+	bool
+	default y
+	depends on BOARD_MSI_MS9652_FAM10
+
+config CONFIG_IRQ_SLOT_COUNT
+	hex
+	default 0x0b
+	depends on BOARD_MSI_MS9652_FAM10
+
+config HAVE_OPTION_TABLE
+	bool
+	default y
+	depends on BOARD_MSI_MS9652_FAM10
+
+config MAX_CPUS
+	int
+	default 8
+	depends on BOARD_MSI_MS9652_FAM10
+
+config MAX_PHYSICAL_CPUS
+	int
+	default 2
+	depends on BOARD_MSI_MS9652_FAM10
+
+config LOGICAL_CPUS
+	bool
+	default y
+	depends on BOARD_MSI_MS9652_FAM10
+
+config IOAPIC
+	bool
+	default y
+	depends on BOARD_MSI_MS9652_FAM10
+
+config SMP
+	bool
+	default y
+	depends on BOARD_MSI_MS9652_FAM10
+
+config STACK_SIZE
+	hex
+	default 0x20000
+	depends on BOARD_MSI_MS9652_FAM10
+
+config HEAP_SIZE
+	hex
+	default 0x20000
+	depends on BOARD_MSI_MS9652_FAM10
+
+config USE_OPTION_TABLE
+	bool
+	default n
+	depends on BOARD_MSI_MS9652_FAM10
+
+config LB_CKS_RANGE_START
+	int
+	default 49
+	depends on BOARD_MSI_MS9652_FAM10
+
+config LB_CKS_RANGE_END
+	int
+	default 122
+	depends on BOARD_MSI_MS9652_FAM10
+
+config LB_CKS_LOC
+	int
+	default 123
+	depends on BOARD_MSI_MS9652_FAM10
+
+config MAINBOARD_PART_NUMBER
+	string
+	default "MS-9256"
+	depends on BOARD_MSI_MS9652_FAM10
+
+config MAINBOARD_PCI_SUBSYSTEM_VENDOR_ID
+	hex
+	default 0x1462
+	depends on BOARD_MSI_MS9652_FAM10
+
+config MAINBOARD_PCI_SUBSYSTEM_DEVICE_ID
+	hex
+	default 0x9652
+	depends on BOARD_MSI_MS9652_FAM10
+
+config RAMBASE
+	hex
+	default 0x00200000
+	depends on BOARD_MSI_MS9652_FAM10
+
+config TTYS0_BAUD
+	int
+	default 115200
+	depends on BOARD_MSI_MS9652_FAM10
+
+config TTYS0_BASE
+	hex
+	default 0x3f8
+	depends on BOARD_MSI_MS9652_FAM10
+
+config TTYS0_LCS
+	int
+	default 3
+	depends on BOARD_MSI_MS9652_FAM10
+
+config DEFAULT_CONSOLE_LOGLEVEL
+	int
+	default 9
+	depends on BOARD_MSI_MS9652_FAM10
+
+config MAXIMUM_CONSOLE_LOGLEVEL
+	int
+	default 9
+	depends on BOARD_MSI_MS9652_FAM10
+
+config MAINBOARD_POWER_ON_AFTER_POWER_FAIL
+	bool
+	default y
+	depends on BOARD_MSI_MS9652_FAM10
+
+config CONSOLE_SERIAL8250
+	bool
+	default y
+	depends on BOARD_MSI_MS9652_FAM10
+
+config CONSOLE_VGA
+	bool
+	default y
+	depends on BOARD_MSI_MS9652_FAM10
+
+config PCI_ROM_RUN
+	bool
+	default y
+	depends on BOARD_MSI_MS9652_FAM10
+
+config USBDEBUG_DIRECT
+	bool
+	default n
+	depends on BOARD_MSI_MS9652_FAM10
+
+config HW_MEM_HOLE_SIZEK
+	hex
+	default 0x100000
+	depends on BOARD_MSI_MS9652_FAM10
+
+config HW_MEM_HOLE_SIZE_AUTO_INC
+	bool
+	default n
+	depends on BOARD_MSI_MS9652_FAM10
+
+config HT_CHAIN_UNITID_BASE
+	hex
+	default 0x20
+	depends on BOARD_MSI_MS9652_FAM10
+
+config HT_CHAIN_END_UNITID_BASE
+	hex
+	default 0x00
+	depends on BOARD_MSI_MS9652_FAM10
+
+config SB_HT_CHAIN_ON_BUS0
+	int
+	default 1
+	depends on BOARD_MSI_MS9652_FAM10
+
+config SB_HT_CHAIN_UNITID_OFFSET_ONLY
+	bool
+	default y
+	depends on BOARD_MSI_MS9652_FAM10
+
+config VAR_MTRR_HOLE
+	bool
+	default n
+	depends on BOARD_MSI_MS9652_FAM10
+
+config USE_INIT
+	bool
+	default n
+	depends on BOARD_MSI_MS9652_FAM10
+
+config SERIAL_CPU_INIT
+	bool
+	default y
+	depends on BOARD_MSI_MS9652_FAM10
+
+config APIC_ID_OFFSET
+	hex
+	default 0x00
+	depends on BOARD_MSI_MS9652_FAM10
+
+config LIFT_BSP_APIC_ID
+	bool
+	default 1
+	depends on BOARD_MSI_MS9652_FAM10
+
+config RAMTOP
+	hex
+	default 0x1000000
+	depends on BOARD_MSI_MS9652_FAM10
+
+config MEM_TRAIN_SEQ
+	int
+	default 2
+	depends on BOARD_MSI_MS9652_FAM10
+
+config WAIT_BEFORE_CPUS_INIT
+	bool
+	default n
+	depends on BOARD_MSI_MS9652_FAM10
+
+config AMD_UCODE_PATCH_FILE
+	string
+	default "mc_patch_01000096.h"
+	depends on BOARD_MSI_MS9652_FAM10
+
+config ID_SECTION_OFFSET
+	hex
+	default 0x80
+	depends on BOARD_MSI_MS9652_FAM10
+
+config HT3_SUPPORT
+	bool
+	default y
+	depends on BOARD_MSI_MS9652_FAM10

Added: trunk/src/mainboard/msi/ms9652_fam10/acpi_tables.c
==============================================================================
--- /dev/null	00:00:00 1970	(empty, because file is newly added)
+++ trunk/src/mainboard/msi/ms9652_fam10/acpi_tables.c	Mon Mar  1 11:56:51 2010	(r5180)
@@ -0,0 +1,207 @@
+/*
+ * This file is part of the coreboot project.
+ *
+ * Written by Stefan Reinauer <stepan at openbios.org>.
+ * ACPI FADT, FACS, and DSDT table support added by 
+ *
+ * Copyright (C) 2004 Stefan Reinauer <stepan at openbios.org>
+ * Copyright (C) 2005 Nick Barker <nick.barker9 at btinternet.com>
+ * Copyright (C) 2007, 2008 Rudolf Marek <r.marek at assembler.cz>
+ * Copyright (C) 2009 Harald Gutmann <harald.gutmann at gmx.net>
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License v2 as published by
+ * the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA  02110-1301 USA
+ */
+
+#include <console/console.h>
+#include <string.h>
+#include <arch/acpi.h>
+#include <arch/smp/mpspec.h>
+#include <device/device.h>
+#include <device/pci_ids.h>
+//#include <../../../northbridge/amd/amdfam10/amdfam10_acpi.h>
+#include <cpu/amd/model_fxx_powernow.h>
+#include <device/pci.h>
+#include <cpu/amd/amdfam10_sysconf.h>
+#include "mb_sysconf.h"
+
+extern unsigned char AmlCode[];
+
+unsigned long acpi_fill_mcfg(unsigned long current)
+{
+	/* Not implemented */
+	return current;
+}
+
+unsigned long acpi_fill_madt(unsigned long current)
+{
+	unsigned int gsi_base = 0x18;
+	struct mb_sysconf_t *m;
+	//extern unsigned char bus_mcp55[8];
+	//extern unsigned apicid_mcp55;
+	extern void get_bus_conf(void);
+	unsigned sbdn;
+	struct resource *res;
+	device_t dev;
+
+	get_bus_conf();
+	sbdn = sysconf.sbdn;
+	m = sysconf.mb;
+	
+	/* Create all subtables for processors. */
+	current = acpi_create_madt_lapics(current);
+
+	/* Write SB IOAPIC. */
+	dev = dev_find_slot(m->bus_mcp55[0], PCI_DEVFN(sbdn+ 0x1,0));
+	if (dev) {
+		res = find_resource(dev, PCI_BASE_ADDRESS_1);
+		if (res) {
+			current += acpi_create_madt_ioapic((acpi_madt_ioapic_t *) current,
+				m->apicid_mcp55, res->base,  0);
+		}
+	}
+
+	/* Write NB IOAPIC. */
+	dev = dev_find_slot(m->bus_mcp55[0], PCI_DEVFN(sbdn+ 0x12,1));
+	if (dev) {
+		res = find_resource(dev, PCI_BASE_ADDRESS_1);
+		if (res) {
+			current += acpi_create_madt_ioapic((acpi_madt_ioapic_t *) current,
+				m->apicid_mcp55++, res->base,  gsi_base);
+		}
+	}
+
+	/* IRQ9 ACPI active low. */
+	current += acpi_create_madt_irqoverride((acpi_madt_irqoverride_t *)
+		current, 0, 9, 9, MP_IRQ_TRIGGER_LEVEL | MP_IRQ_POLARITY_LOW);
+
+	/* IRQ0 -> APIC IRQ2. */
+	current += acpi_create_madt_irqoverride((acpi_madt_irqoverride_t *)
+		current, 0, 0, 2, 0x0);	
+
+	/* Create all subtables for processors. */
+	current = acpi_create_madt_lapic_nmis(current,
+		MP_IRQ_TRIGGER_EDGE | MP_IRQ_POLARITY_HIGH, 1);
+
+	return current;
+}
+
+unsigned long acpi_fill_ssdt_generator(unsigned long current, const char *oem_table_id)
+{
+	//k8acpi_write_vars();
+	//amd_model_fxx_generate_powernow(0, 0, 0);
+	//return (unsigned long) (acpigen_get_current());
+	return 0;
+}
+
+unsigned long write_acpi_tables(unsigned long start)
+{
+	unsigned long current;
+	acpi_rsdp_t *rsdp;
+	acpi_srat_t *srat;
+	acpi_rsdt_t *rsdt;
+	acpi_mcfg_t *mcfg;
+	acpi_hpet_t *hpet;
+	acpi_madt_t *madt;
+	acpi_fadt_t *fadt;
+	acpi_facs_t *facs;
+	acpi_slit_t *slit;
+	acpi_header_t *ssdt;
+	acpi_header_t *dsdt;
+
+	/* Align ACPI tables to 16 byte. */
+	start = (start + 0x0f) & -0x10;
+	current = start;
+
+	printk_info("ACPI: Writing ACPI tables at %lx...\n", start);
+
+	/* We need at least an RSDP and an RSDT table. */
+	rsdp = (acpi_rsdp_t *) current;
+	current += sizeof(acpi_rsdp_t);
+	rsdt = (acpi_rsdt_t *) current;
+	current += sizeof(acpi_rsdt_t);
+
+	/* Clear all table memory. */
+	memset((void *) start, 0, current - start);
+
+	acpi_write_rsdp(rsdp, rsdt, NULL);
+	acpi_write_rsdt(rsdt);
+
+	/* We explicitly add these tables later on: */
+	printk_debug("ACPI:     * FACS\n");
+
+	/* we should align FACS to 64B as per ACPI specs */
+	current = ALIGN(current, 64);
+	facs = (acpi_facs_t *) current;
+	current += sizeof(acpi_facs_t);
+	acpi_create_facs(facs);
+
+	dsdt = (acpi_header_t *) current;
+	current += ((acpi_header_t *) AmlCode)->length;
+	memcpy((void *) dsdt, (void *) AmlCode,
+	       ((acpi_header_t *) AmlCode)->length);
+	dsdt->checksum = 0;	/* Don't trust iasl to get this right. */
+	dsdt->checksum = acpi_checksum(dsdt, dsdt->length);
+	printk_debug("ACPI:     * DSDT @ %08x Length %x\n", dsdt,
+		     dsdt->length);
+	printk_debug("ACPI:     * FADT\n");
+
+	fadt = (acpi_fadt_t *) current;
+	current += sizeof(acpi_fadt_t);
+
+	acpi_create_fadt(fadt, facs, dsdt);
+	acpi_add_table(rsdp, fadt);
+
+	printk_debug("ACPI:    * HPET\n");
+	hpet = (acpi_hpet_t *) current;
+	current += sizeof(acpi_hpet_t);
+	acpi_create_hpet(hpet);
+	acpi_add_table(rsdp, hpet);
+
+	/* If we want to use HPET timers Linux wants an MADT. */
+	printk_debug("ACPI:    * MADT\n");
+	madt = (acpi_madt_t *) current;
+	acpi_create_madt(madt);
+	current += madt->header.length;
+	acpi_add_table(rsdp, madt);
+
+	printk_debug("ACPI:    * MCFG\n");
+	mcfg = (acpi_mcfg_t *) current;
+	acpi_create_mcfg(mcfg);
+	current += mcfg->header.length;
+	acpi_add_table(rsdp, mcfg);
+
+	printk_debug("ACPI:    * SRAT\n");
+	srat = (acpi_srat_t *) current;
+	acpi_create_srat(srat);
+	current += srat->header.length;
+	acpi_add_table(rsdp, srat);
+
+	/* SLIT */
+	printk_debug("ACPI:    * SLIT\n");
+	slit = (acpi_slit_t *) current;
+	acpi_create_slit(slit);
+	current+=slit->header.length;
+	acpi_add_table(rsdp, slit);
+
+	/* SSDT */
+	printk_debug("ACPI:    * SSDT\n");
+	ssdt = (acpi_header_t *)current;
+
+	acpi_create_ssdt_generator(ssdt, "DYNADATA");
+	current += ssdt->length;
+	acpi_add_table(rsdp, ssdt);
+
+	printk_info("ACPI: done.\n");
+	return current;
+}

Added: trunk/src/mainboard/msi/ms9652_fam10/chip.h
==============================================================================
--- /dev/null	00:00:00 1970	(empty, because file is newly added)
+++ trunk/src/mainboard/msi/ms9652_fam10/chip.h	Mon Mar  1 11:56:51 2010	(r5180)
@@ -0,0 +1,27 @@
+/*
+ * This file is part of the coreboot project.
+ *
+ * Copyright (C) 2007 AMD
+ * Written by Yinghai Lu <yinghailu at amd.com> for AMD.
+ *
+ * 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 {
+//	int fixup_scsi;
+//	int fixup_vga;
+};

Added: trunk/src/mainboard/msi/ms9652_fam10/cmos.layout
==============================================================================
--- /dev/null	00:00:00 1970	(empty, because file is newly added)
+++ trunk/src/mainboard/msi/ms9652_fam10/cmos.layout	Mon Mar  1 11:56:51 2010	(r5180)
@@ -0,0 +1,119 @@
+##
+## This file is part of the coreboot project.
+##
+## Copyright (C) 2007 AMD
+## Written by Yinghai Lu <yinghailu at amd.com> for AMD.
+##
+## 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
+##
+
+entries
+
+#start-bit length  config config-ID    name
+#0            8       r       0        seconds
+#8            8       r       0        alarm_seconds
+#16           8       r       0        minutes
+#24           8       r       0        alarm_minutes
+#32           8       r       0        hours
+#40           8       r       0        alarm_hours
+#48           8       r       0        day_of_week
+#56           8       r       0        day_of_month
+#64           8       r       0        month
+#72           8       r       0        year
+#80           4       r       0        rate_select
+#84           3       r       0        REF_Clock
+#87           1       r       0        UIP
+#88           1       r       0        auto_switch_DST
+#89           1       r       0        24_hour_mode
+#90           1       r       0        binary_values_enable
+#91           1       r       0        square-wave_out_enable
+#92           1       r       0        update_finished_enable
+#93           1       r       0        alarm_interrupt_enable
+#94           1       r       0        periodic_interrupt_enable
+#95           1       r       0        disable_clock_updates
+#96         288       r       0        temporary_filler
+0          384       r       0        reserved_memory
+384          1       e       4        boot_option
+385          1       e       4        last_boot
+386          1       e       1        ECC_memory
+388          4       r       0        reboot_bits
+392          3       e       5        baud_rate
+395          1       e       1        hw_scrubber
+396          1       e       1        interleave_chip_selects
+397          2       e       8        max_mem_clock
+399          1       e       2        quad_core
+400          1       e       1        power_on_after_fail
+412          4       e       6        debug_level
+416          4       e       7        boot_first
+420          4       e       7        boot_second
+424          4       e       7        boot_third
+428          4       h       0        boot_index
+432          8       h       0        boot_countdown
+440          4       e       9        slow_cpu
+444          1       e       1        nmi
+445          1       e       1        iommu
+728        256       h       0        user_data
+984         16       h       0        check_sum
+# Reserve the extended AMD configuration registers
+1000        24       r       0        reserved_memory
+
+
+
+enumerations
+
+#ID value   text
+1     0     Disable
+1     1     Enable
+2     0     Enable
+2     1     Disable
+4     0     Fallback
+4     1     Normal
+5     0     115200
+5     1     57600
+5     2     38400
+5     3     19200
+5     4     9600
+5     5     4800
+5     6     2400
+5     7     1200
+6     6     Notice
+6     7     Info
+6     8     Debug
+6     9     Spew
+7     0     Network
+7     1     HDD
+7     2     Floppy
+7     8     Fallback_Network
+7     9     Fallback_HDD
+7     10    Fallback_Floppy
+#7     3     ROM
+8     0     200Mhz
+8     1     166Mhz
+8     2     133Mhz
+8     3     100Mhz
+9     0     off
+9     1     87.5%
+9     2     75.0%
+9     3     62.5%
+9     4     50.0%
+9     5     37.5%
+9     6     25.0%
+9     7     12.5%
+
+checksums
+
+checksum 392 983 984
+
+

Added: trunk/src/mainboard/msi/ms9652_fam10/devicetree.cb
==============================================================================
--- /dev/null	00:00:00 1970	(empty, because file is newly added)
+++ trunk/src/mainboard/msi/ms9652_fam10/devicetree.cb	Mon Mar  1 11:56:51 2010	(r5180)
@@ -0,0 +1,155 @@
+## Copyright (C) 2010 Raptor Engineering
+## Written by Timothy Pearson <tpearson at raptorengineeringinc.com> for Raptor Engineering.
+##
+## Copyright (C) 2007 AMD
+## Written by Yinghai Lu <yinghailu at amd.com> for AMD.
+
+chip northbridge/amd/amdfam10/root_complex
+	device apic_cluster 0 on
+		chip cpu/amd/socket_F_1207
+			device apic 0 on end
+		end
+	end
+	device pci_domain 0 on
+		chip northbridge/amd/amdfam10 #mc0
+			device pci 18.0 on	# SB on HT link 0.0
+				chip southbridge/nvidia/mcp55
+					device pci 0.0 on end   # HT
+					device pci 1.0 on # LPC
+						chip superio/winbond/w83627ehg
+							device pnp 2e.0 on #  Floppy
+								io 0x60 = 0x3f0
+								irq 0x70 = 6
+								drq 0x74 = 2
+							end
+							device pnp 2e.1 off #  Parallel Port
+								io 0x60 = 0x378
+								irq 0x70 = 7
+							end
+							device pnp 2e.2 on #  Com1
+								io 0x60 = 0x3f8
+								irq 0x70 = 4
+							end
+							device pnp 2e.3 on #  Com2
+								io 0x60 = 0x2f8
+								irq 0x70 = 3
+							end
+							device pnp 2e.5 on #  Keyboard
+								io 0x60 = 0x60
+								io 0x62 = 0x64
+								irq 0x70 = 1
+								irq 0x72 = 12
+							end
+							device pnp 2e.6 off #  SERIAL_FLASH
+								io 0x60 = 0x100
+							end
+							device pnp 2e.7 off #  GAME_MIDI_GIPO1
+								io 0x60 = 0x220
+								io 0x62 = 0x300
+								irq 0x70 = 9
+							end
+							device pnp 2e.8 off end #  WDTO_PLED
+							device pnp 2e.9 off end #  GPIO2_GPIO3_GPIO4_GPIO5
+							device pnp 2e.a off end #  ACPI
+							device pnp 2e.b on #  HW Monitor
+								io 0x60 = 0x290
+								irq 0x70 = 5
+							end
+							device pnp 2e.106 off		# Serial flash
+								io 0x60 = 0x100
+							end
+							device pnp 2e.207 on		# MIDI
+								io 0x62 = 0x330
+								irq 0x70 = 0xa
+							end
+						end
+					end
+					device pci 1.1 on # SM 0
+						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
+						chip drivers/generic/generic #dimm 1-0-0
+							device i2c 54 on end
+						end
+						chip drivers/generic/generic #dimm 1-0-1
+							device i2c 55 on end
+						end
+						chip drivers/generic/generic #dimm 1-1-0
+							device i2c 56 on end
+						end
+						chip drivers/generic/generic #dimm 1-1-1
+							device i2c 57 on end
+						end
+					end # SM
+					device pci 1.1 on # SM 1
+#PCI device smbus address will depend on addon pci device, do we need to scan_smbus_bus?
+#						chip drivers/generic/generic #PCIXA Slot1
+#							device i2c 50 on end
+#						end
+#						chip drivers/generic/generic #PCIXB Slot1
+#							device i2c 51 on end
+#						end
+#						chip drivers/generic/generic #PCIXB Slot2
+#							device i2c 52 on end
+#						end
+#						chip drivers/generic/generic #PCI Slot1
+#							device i2c 53 on end
+#						end
+#						chip drivers/generic/generic #Master MCP55 PCI-E
+#							device i2c 54 on end
+#						end
+#						chip drivers/generic/generic #Slave MCP55 PCI-E
+#							device i2c 55 on end
+#						end
+#						chip drivers/generic/generic #MAC EEPROM
+#							device i2c 51 on end
+#						end
+					end # SM
+					device pci 2.0 on end # USB 1.1
+					device pci 2.1 on end # USB 2
+					device pci 4.0 on end # IDE
+					device pci 5.0 on end # SATA 0
+					device pci 5.1 on end # SATA 1
+					device pci 5.2 on end # SATA 2
+					device pci 6.1 on end # AZA
+					device pci 8.0 on end # NIC
+					device pci 9.0 on end # NIC
+					register "ide0_enable" = "1"
+					register "sata0_enable" = "1"
+					register "sata1_enable" = "1"
+					register "mac_eeprom_smbus" = "3" # 1: smbus under 2e.8, 2: SM0 3: SM1
+					register "mac_eeprom_addr" = "0x51"
+				end
+			end #  device pci 18.0
+			device pci 18.0 on end	# HT 1.0
+			device pci 18.0 on end	# HT 2.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 # mc0
+
+	end # PCI domain
+
+#	chip drivers/generic/debug
+#		device pnp 0.0 off end # chip name
+#		device pnp 0.1 on end # pci_regs_all
+#		device pnp 0.2 on end # mem
+#		device pnp 0.3 off end # cpuid
+#		device pnp 0.4 on end # smbus_regs_all
+#		device pnp 0.5 off end # dual core msr
+#		device pnp 0.6 off end # cache size
+#		device pnp 0.7 off end # tsc
+#		device pnp 0.8 off  end # io
+#		device pnp 0.9 off end # io
+#	end
+end #root_complex

Added: trunk/src/mainboard/msi/ms9652_fam10/dsdt.asl
==============================================================================
--- /dev/null	00:00:00 1970	(empty, because file is newly added)
+++ trunk/src/mainboard/msi/ms9652_fam10/dsdt.asl	Mon Mar  1 11:56:51 2010	(r5180)
@@ -0,0 +1,302 @@
+/*
+ * This file is part of the coreboot project.
+ *
+ * (C) Copyright 2004 Nick Barker <Nick.Barker9 at btinternet.com>
+ * (C) Copyright 2007, 2008 Rudolf Marek <r.marek at assembler.cz>
+ * (C) Copyright 2009 Harald Gutmann <harald.gutmann at gmx.net>
+ *
+ * ISA portions taken from QEMU acpi-dsdt.dsl.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License v2 as published by
+ * the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA  02110-1301 USA
+ */
+
+DefinitionBlock ("DSDT.aml", "DSDT", 1, "LXBIOS", "LXB-DSDT", 1)
+{
+	Include ("../../../../src/northbridge/amd/amdk8/amdk8_util.asl")
+
+	/* For now only define 2 power states:
+	 *  - S0 which is fully on
+	 *  - S5 which is soft off
+	 */
+	Name (\_S0, Package () { 0x00, 0x00, 0x00, 0x00 })
+	Name (\_S5, Package () { 0x07, 0x00, 0x00, 0x00 })
+
+	/* Root of the bus hierarchy */
+	Scope (\_SB)
+	{
+		/* Top PCI device */
+		Device (PCI0)
+		{
+			Name (_HID, EisaId ("PNP0A03"))
+			Name (_ADR, 0x00)
+			Name (_UID, 0x00)
+			Name (_BBN, 0x00)
+
+			External (BUSN)
+			External (MMIO)
+			External (PCIO)
+			External (SBLK)
+			External (TOM1)
+			External (HCLK)
+			External (SBDN)
+			External (HCDN)
+                    
+			Method (_CRS, 0, NotSerialized)
+                        {
+				Name (BUF0, ResourceTemplate ()
+				{
+					IO (Decode16,
+					0x0CF8,             // Address Range Minimum
+					0x0CF8,             // Address Range Maximum
+					0x01,               // Address Alignment
+					0x08,               // Address Length
+					)
+					WordIO (ResourceProducer, MinFixed, MaxFixed, PosDecode, EntireRange,
+					0x0000,             // Address Space Granularity
+					0x0000,             // Address Range Minimum
+					0x0CF7,             // Address Range Maximum
+					0x0000,             // Address Translation Offset
+					0x0CF8,             // Address Length
+					,, , TypeStatic)
+				})
+				/* Methods bellow use SSDT to get actual MMIO regs
+				   The IO ports are from 0xd00, optionally an VGA,
+				   otherwise the info from MMIO is used.
+				 */
+				Concatenate (\_SB.GMEM (0x00, \_SB.PCI0.SBLK), BUF0, Local1)
+				Concatenate (\_SB.GIOR (0x00, \_SB.PCI0.SBLK), Local1, Local2)
+				Concatenate (\_SB.GWBN (0x00, \_SB.PCI0.SBLK), Local2, Local3)
+				Return (Local3)
+			}
+
+			/* PCI Routing Table */
+			Name (_PRT, Package () {
+				Package (0x04) { 0x0001FFFF, 0x01, 0x00, 0x0A }, /* 0x1 - 00:01.1 - IRQ 10 - SMBus */
+				Package (0x04) { 0x0002FFFF, 0x00, 0x00, 0x16 }, /* 0x2 - 00:02.0 - IRQ 22 - USB */
+				Package (0x04) { 0x0002FFFF, 0x01, 0x00, 0x17 }, /* 0x2 - 00:01.1 - IRQ 23 - USB */
+				Package (0x04) { 0x0004FFFF, 0x00, 0x00, 0x15 }, /* 0x4 - 00:04.0 - IRQ 21 - IDE */
+				Package (0x04) { 0x0005FFFF, 0x00, 0x00, 0x14 }, /* 0x5 - 00:05.0 - IRQ 20 - SATA */
+				Package (0x04) { 0x0005FFFF, 0x01, 0x00, 0x15 }, /* 0x5 - 00:05.1 - IRQ 21 - SATA */
+				Package (0x04) { 0x0005FFFF, 0x02, 0x00, 0x16 }, /* 0x5 - 00:05.2 - IRQ 22 - SATA */
+				Package (0x04) { 0x0006FFFF, 0x01, 0x00, 0x17 }, /* 0x6 - 00:06.1 - IRQ 23 - HD Audio */
+				Package (0x04) { 0x0008FFFF, 0x00, 0x00, 0x14 }, /* 0x8 - 00:08.0 - IRQ 20 - GBit Ethernet */
+			})
+
+			Device (PEBF) /* PCI-E Bridge F */
+			{
+				Name (_ADR, 0x000F0000)
+				Name (_UID, 0x00)
+				Name (_BBN, 0x07)
+				Name (_PRT, Package () {
+					Package (0x04) { 0x0000FFFF, 0x00, 0x00, 0x11 },
+					Package (0x04) { 0x0000FFFF, 0x01, 0x00, 0x12 },
+					Package (0x04) { 0x0000FFFF, 0x02, 0x00, 0x13 },
+					Package (0x04) { 0x0000FFFF, 0x03, 0x00, 0x10 },
+				})
+			}
+
+			Device (PEBE) /* PCI-E Bridge E */
+			{
+				Name (_ADR, 0x000E0000)
+				Name (_UID, 0x00)
+				Name (_BBN, 0x06)
+				Name (_PRT, Package () {
+					Package (0x04) { 0x0000FFFF, 0x00, 0x00, 0x12 },
+					Package (0x04) { 0x0000FFFF, 0x01, 0x00, 0x13 },
+					Package (0x04) { 0x0000FFFF, 0x02, 0x00, 0x10 },
+					Package (0x04) { 0x0000FFFF, 0x03, 0x00, 0x11 },
+				})
+			}
+
+			Device (PEBD) /* PCI-E Bridge D */
+			{
+				Name (_ADR, 0x000D0000)
+				Name (_UID, 0x00)
+				Name (_BBN, 0x05)
+				Name (_PRT, Package () {
+					Package (0x04) { 0x0000FFFF, 0x00, 0x00, 0x13 },
+					Package (0x04) { 0x0000FFFF, 0x01, 0x00, 0x10 },
+					Package (0x04) { 0x0000FFFF, 0x02, 0x00, 0x11 },
+					Package (0x04) { 0x0000FFFF, 0x03, 0x00, 0x12 },
+				})
+			}
+
+			Device (PEBC) /* PCI-E Bridge C */
+			{
+				Name (_ADR, 0x000C0000)
+				Name (_UID, 0x00)
+				Name (_BBN, 0x04)
+				Name (_PRT, Package () {
+					Package (0x04) { 0x0000FFFF, 0x00, 0x00, 0x10 },
+					Package (0x04) { 0x0000FFFF, 0x01, 0x00, 0x11 },
+					Package (0x04) { 0x0000FFFF, 0x02, 0x00, 0x12 },
+					Package (0x04) { 0x0000FFFF, 0x03, 0x00, 0x13 },
+				})
+			}
+
+			Device (PEBB) /* PCI-E Bridge B */
+			{
+				Name (_ADR, 0x000B0000)
+				Name (_UID, 0x00)
+				Name (_BBN, 0x03)
+				Name (_PRT, Package () {
+					Package (0x04) { 0x0000FFFF, 0x00, 0x00, 0x11 },
+					Package (0x04) { 0x0000FFFF, 0x01, 0x00, 0x12 },
+					Package (0x04) { 0x0000FFFF, 0x02, 0x00, 0x13 },
+					Package (0x04) { 0x0000FFFF, 0x03, 0x00, 0x10 },
+				})
+			}
+
+			Device (PEBA) /* PCI-E Bridge A */
+			{
+				Name (_ADR, 0x000A0000)
+				Name (_UID, 0x00)
+				Name (_BBN, 0x02)
+				Name (_PRT, Package () {
+					Package (0x04) { 0x0000FFFF, 0x00, 0x00, 0x12 },
+					Package (0x04) { 0x0000FFFF, 0x01, 0x00, 0x13 },
+					Package (0x04) { 0x0000FFFF, 0x02, 0x00, 0x10 },
+					Package (0x04) { 0x0000FFFF, 0x03, 0x00, 0x11 },
+				})
+			}
+
+			Device (PCID)	/* PCI Device */
+			{
+				Name (_ADR, 0x00060000)
+				Name (_UID, 0x00)
+				Name (_BBN, 0x01)
+				Name (_PRT, Package () {
+					Package (0x04) { 0x0006FFFF, 0x00, 0x00, 0x12 },
+					Package (0x04) { 0x0006FFFF, 0x01, 0x00, 0x13 },
+					Package (0x04) { 0x0006FFFF, 0x02, 0x00, 0x10 },
+					Package (0x04) { 0x0006FFFF, 0x03, 0x00, 0x11 },
+					Package (0x04) { 0x0007FFFF, 0x00, 0x00, 0x13 }, /* PCI slot 1 */
+					Package (0x04) { 0x0007FFFF, 0x01, 0x00, 0x10 },
+					Package (0x04) { 0x0007FFFF, 0x02, 0x00, 0x11 },
+					Package (0x04) { 0x0007FFFF, 0x03, 0x00, 0x12 },
+					Package (0x04) { 0x0008FFFF, 0x00, 0x00, 0x10 }, /* PCI slot 2 */
+					Package (0x04) { 0x0008FFFF, 0x01, 0x00, 0x11 },
+					Package (0x04) { 0x0008FFFF, 0x02, 0x00, 0x12 },
+					Package (0x04) { 0x0008FFFF, 0x03, 0x00, 0x13 },
+					Package (0x04) { 0x0009FFFF, 0x00, 0x00, 0x11 },
+					Package (0x04) { 0x0009FFFF, 0x01, 0x00, 0x12 },
+					Package (0x04) { 0x0009FFFF, 0x02, 0x00, 0x13 },
+					Package (0x04) { 0x0009FFFF, 0x03, 0x00, 0x10 },
+					Package (0x04) { 0x000AFFFF, 0x00, 0x00, 0x12 }, /* FireWire */
+					Package (0x04) { 0x000AFFFF, 0x01, 0x00, 0x13 },
+					Package (0x04) { 0x000AFFFF, 0x02, 0x00, 0x10 },
+					Package (0x04) { 0x000AFFFF, 0x03, 0x00, 0x11 },
+				})
+			}
+		}
+
+		Device (ISA) {
+			Name (_ADR, 0x000010000)
+
+			/* PS/2 keyboard (seems to be important for WinXP install) */
+			Device (KBD)
+			{
+				Name (_HID, EisaId ("PNP0303"))
+				Method (_STA, 0, NotSerialized)
+				{
+					Return (0x0f)
+				}
+				Method (_CRS, 0, NotSerialized)
+				{
+					Name (TMP0, ResourceTemplate () {
+						IO (Decode16, 0x0060, 0x0060, 0x01, 0x01)
+						IO (Decode16, 0x0064, 0x0064, 0x01, 0x01)
+						IRQNoFlags () {1}
+					})
+					Return (TMP0)
+				}
+			}
+
+			/* PS/2 mouse */
+			Device (MOU)
+			{
+				Name (_HID, EisaId ("PNP0F13"))
+				Method (_STA, 0, NotSerialized)
+				{
+					Return (0x0f)
+				}
+				Method (_CRS, 0, NotSerialized)
+				{
+					Name (TMP1, ResourceTemplate () {
+						IO (Decode16, 0x0060, 0x0060, 0x01, 0x01)
+						IO (Decode16, 0x0064, 0x0064, 0x01, 0x01)
+						IRQNoFlags () {12}
+					})
+					Return (TMP1)
+				}
+			}
+
+			/* PS/2 floppy controller */
+			Device (FDC0)
+			{
+				Name (_HID, EisaId ("PNP0700"))
+				Method (_STA, 0, NotSerialized)
+				{
+					Return (0x0f)
+				}
+				Method (_CRS, 0, NotSerialized)
+				{
+					Name (BUF0, ResourceTemplate () {
+						IO (Decode16, 0x03F0, 0x03F0, 0x01, 0x06)
+						IO (Decode16, 0x03F7, 0x03F7, 0x01, 0x01)
+						IRQNoFlags () {6}
+						DMA (Compatibility, NotBusMaster, Transfer8) {2}
+					})
+					Return (BUF0)
+				}
+			}
+			/* Parallel Port */
+			Device (LPT1)
+			{
+				Name (_HID, EisaId ("PNP0400"))
+				Method (_STA, 0, NotSerialized)
+				{
+					Return (0x0f)
+				}
+				Method (_CRS, 0, NotSerialized)
+				{
+					Name (BUF1, ResourceTemplate () {
+						IO (Decode16, 0x0378, 0x0378, 0x01, 0x08) 
+						IRQNoFlags () {7}
+					})
+					Return (BUF1)
+				}
+			}
+			/* Parallel Port ECP */
+			Device (ECP1)
+			{
+				Name (_HID, EisaId ("PNP0401"))
+				Method (_STA, 0, NotSerialized)
+				{
+					Return (0x0f)
+				}
+				Method (_CRS, 0, NotSerialized)
+				{
+					Name (BUF1, ResourceTemplate () {
+						IO (Decode16, 0x0378, 0x0378, 0x01, 0x04) 
+						IO (Decode16, 0x0778, 0x0778, 0x01, 0x04)
+						IRQNoFlags() {7}
+						DMA (Compatibility, NotBusMaster, Transfer8) {0,1,3}
+					})
+					Return (BUF1)
+				}
+			}
+		}
+	}
+}

Added: trunk/src/mainboard/msi/ms9652_fam10/get_bus_conf.c
==============================================================================
--- /dev/null	00:00:00 1970	(empty, because file is newly added)
+++ trunk/src/mainboard/msi/ms9652_fam10/get_bus_conf.c	Mon Mar  1 11:56:51 2010	(r5180)
@@ -0,0 +1,140 @@
+/*
+ * This file is part of the coreboot project.
+ *
+ * Copyright (C) 2007 AMD
+ * Written by Yinghai Lu <yinghailu at amd.com> for AMD.
+ *
+ * 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 <console/console.h>
+#include <device/pci.h>
+#include <device/pci_ids.h>
+#include <string.h>
+#include <stdint.h>
+#if CONFIG_LOGICAL_CPUS==1
+#include <cpu/amd/quadcore.h>
+#endif
+
+#include <cpu/amd/amdfam10_sysconf.h>
+
+#include <stdlib.h>
+#include "mb_sysconf.h"
+
+// Global variables for MB layouts and these will be shared by irqtable mptable and acpi_tables
+struct mb_sysconf_t mb_sysconf;
+
+/* Here you only need to set value in pci1234 for HT-IO that could be
+installed or not You may need to preset pci1234 for HTIO board, please
+refer to src/northbridge/amd/amdfam10/get_pci1234.c for detail */
+static u32 pci1234x[] = {
+	0x0000ffc, 0x0000ffc, 0x0000ffc, 0x0000ffc, 0x0000ffc, 0x0000ffc,
+	0x0000ffc, 0x0000ffc, 0x0000ffc, 0x0000ffc, 0x0000ffc, 0x0000ffc,
+	0x0000ffc, 0x0000ffc, 0x0000ffc, 0x0000ffc, 0x0000ffc, 0x0000ffc,
+	0x0000ffc, 0x0000ffc, 0x0000ffc, 0x0000ffc, 0x0000ffc, 0x0000ffc,
+	0x0000ffc, 0x0000ffc, 0x0000ffc, 0x0000ffc, 0x0000ffc, 0x0000ffc,
+	0x0000ffc, 0x0000ffc,
+	};
+
+
+/* HT Chain device num, actually it is unit id base of every ht device
+in chain, assume every chain only have 4 ht device at most */
+
+static unsigned hcdnx[] = {
+	0x20202020, 0x20202020, 0x20202020, 0x20202020, 0x20202020,
+	0x20202020, 0x20202020, 0x20202020, 0x20202020, 0x20202020,
+	0x20202020, 0x20202020, 0x20202020, 0x20202020, 0x20202020,
+	0x20202020, 0x20202020, 0x20202020, 0x20202020, 0x20202020,
+	0x20202020, 0x20202020, 0x20202020, 0x20202020, 0x20202020,
+	0x20202020, 0x20202020, 0x20202020, 0x20202020, 0x20202020,
+	0x20202020, 0x20202020,
+};
+
+extern void get_pci1234(void);
+
+static unsigned get_bus_conf_done = 0;
+
+void get_bus_conf(void)
+{
+	unsigned apicid_base;
+	struct mb_sysconf_t *m;
+
+	device_t dev;
+	int i, j;
+
+	printk_spew("get_bus_conf()\n");
+
+	if(get_bus_conf_done==1) return; //do it only once
+
+	get_bus_conf_done = 1;
+
+	sysconf.mb = &mb_sysconf;
+
+	m = sysconf.mb;
+	memset(m, 0, sizeof(struct mb_sysconf_t));
+
+	sysconf.hc_possible_num = ARRAY_SIZE(pci1234x);
+	for(i=0;i<sysconf.hc_possible_num; i++) {
+		sysconf.pci1234[i] = pci1234x[i];
+		sysconf.hcdn[i] = hcdnx[i];
+	}
+
+	get_pci1234();
+
+	m->bus_type[0] = 1; //pci
+	sysconf.sbdn = (sysconf.hcdn[0] & 0xff); // first byte of first chain
+	m->bus_mcp55[0] = (sysconf.pci1234[0] >> 12) & 0xff;
+
+		/* MCP55 */
+		dev = dev_find_slot(m->bus_mcp55[0], PCI_DEVFN(sysconf.sbdn + 0x06,0));
+		if (dev) {
+			m->bus_mcp55[1] = pci_read_config8(dev, PCI_SECONDARY_BUS);
+		}
+		else {
+			printk_debug("ERROR - could not find PCI 1:%02x.0, using defaults\n", sysconf.sbdn + 0x06);
+		}
+
+		for(i=2; i<8;i++) {
+			dev = dev_find_slot(m->bus_mcp55[0], PCI_DEVFN(sysconf.sbdn + 0x0a + i - 2 , 0));
+			if (dev) {
+				m->bus_mcp55[i] = pci_read_config8(dev, PCI_SECONDARY_BUS);
+			}
+			else {
+				printk_debug("ERROR - could not find PCI %02x:%02x.0, using defaults\n", m->bus_mcp55[0], sysconf.sbdn + 0x0a + i - 2 );
+			}
+		}
+
+	for(i=0; i< sysconf.hc_possible_num; i++) {
+		if(!(sysconf.pci1234[i] & 0x1) ) continue;
+
+		unsigned busn = (sysconf.pci1234[i] >> 12) & 0xff;
+		unsigned busn_max = (sysconf.pci1234[i] >> 20) & 0xff;
+		for (j = busn; j <= busn_max; j++)
+			m->bus_type[j] = 1;
+		if(m->bus_isa <= busn_max)
+			m->bus_isa = busn_max + 1;
+		printk_debug("i=%d bus range: [%x, %x] bus_isa=%x\n",i, busn, busn_max, m->bus_isa);
+	}
+
+/*I/O APICs:	APIC ID	Version	State		Address*/
+#if CONFIG_LOGICAL_CPUS==1
+	apicid_base = get_apicid_base(1);
+	printk_spew("CONFIG_LOGICAL_CPUS==1: apicid_base: %08x\n");
+#else
+	apicid_base = CONFIG_MAX_PHYSICAL_CPUS;
+	printk_spew("CONFIG_LOGICAL_CPUS==0: apicid_base: %08x\n");
+#endif
+	m->apicid_mcp55 = apicid_base+0;
+}

Added: trunk/src/mainboard/msi/ms9652_fam10/irq_tables.c
==============================================================================
--- /dev/null	00:00:00 1970	(empty, because file is newly added)
+++ trunk/src/mainboard/msi/ms9652_fam10/irq_tables.c	Mon Mar  1 11:56:51 2010	(r5180)
@@ -0,0 +1,138 @@
+/*
+ * This file is part of the coreboot project.
+ *
+ * Copyright (C) 2007 AMD
+ * Written by Yinghai Lu <yinghailu at amd.com> for AMD.
+ *
+ * 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
+ */
+
+/* This file was generated by getpir.c, do not modify! 
+ * (but if you do, please run checkpir on it to verify)
+ * Contains the IRQ Routing Table dumped directly from your memory , wich BIOS sets up
+
+ * Documentation at : http://www.microsoft.com/hwdev/busbios/PCIIRQ.HTM
+*/
+#include <console/console.h>
+#include <device/pci.h>
+#include <string.h>
+#include <stdint.h>
+#include <arch/pirq_routing.h>
+
+#include <cpu/amd/amdfam10_sysconf.h>
+#include "mb_sysconf.h"
+
+static void write_pirq_info(struct irq_info *pirq_info, uint8_t bus, uint8_t devfn, uint8_t link0, uint16_t bitmap0, 
+		uint8_t link1, uint16_t bitmap1, uint8_t link2, uint16_t bitmap2,uint8_t link3, uint16_t bitmap3,
+		uint8_t slot, uint8_t rfu)
+{
+	pirq_info->bus = bus; 
+	pirq_info->devfn = devfn;
+		pirq_info->irq[0].link = link0;
+		pirq_info->irq[0].bitmap = bitmap0;
+		pirq_info->irq[1].link = link1;
+		pirq_info->irq[1].bitmap = bitmap1;
+		pirq_info->irq[2].link = link2;
+		pirq_info->irq[2].bitmap = bitmap2;
+		pirq_info->irq[3].link = link3;
+		pirq_info->irq[3].bitmap = bitmap3;
+	pirq_info->slot = slot;
+	pirq_info->rfu = rfu;
+}
+
+extern void get_bus_conf(void);
+
+unsigned long write_pirq_routing_table(unsigned long addr)
+{
+
+	struct irq_routing_table *pirq;
+	struct irq_info *pirq_info;
+	unsigned slot_num;
+	uint8_t *v;
+	struct mb_sysconf_t *m;
+	unsigned sbdn;
+
+	uint8_t sum=0;
+	int i;
+
+	get_bus_conf(); // it will find out all bus num and apic that share with mptable.c and mptable.c and acpi_tables.c
+	sbdn = sysconf.sbdn;
+	m = sysconf.mb;
+
+	/* Align the table to be 16 byte aligned. */
+	addr += 15;
+	addr &= ~15;
+
+	/* This table must be betweeen 0xf0000 & 0x100000 */
+	printk_info("Writing IRQ routing tables to 0x%x...", addr);
+
+	pirq = (void *)(addr);
+	v = (uint8_t *)(addr);
+	
+	pirq->signature = PIRQ_SIGNATURE;
+	pirq->version  = PIRQ_VERSION;
+	
+	pirq->rtr_bus = m->bus_mcp55[0];
+	pirq->rtr_devfn = ((sbdn+6)<<3)|0;
+
+	pirq->exclusive_irqs = 0;
+	
+	pirq->rtr_vendor = 0x10de;
+	pirq->rtr_device = 0x0370;
+
+	pirq->miniport_data = 0;
+
+	memset(pirq->rfu, 0, sizeof(pirq->rfu));
+
+	pirq_info = (void *) ( &pirq->checksum + 1);
+	slot_num = 0;
+//pci bridge
+	write_pirq_info(pirq_info, m->bus_mcp55[0], ((sbdn+6)<<3)|0, 0x1, 0xdef8, 0x2, 0xdef8, 0x3, 0xdef8, 0x4, 0xdef8, 0, 0);
+	pirq_info++; slot_num++;
+	
+	for(i=1; i< sysconf.hc_possible_num; i++) {
+		if(!(sysconf.pci1234[i] & 0x1) ) continue;
+		unsigned busn = (sysconf.pci1234[i] >> 12) & 0xff;
+		unsigned devn = sysconf.hcdn[i] & 0xff;
+
+		write_pirq_info(pirq_info, busn, (devn<<3)|0, 0x1, 0xdef8, 0x2, 0xdef8, 0x3, 0xdef8, 0x4, 0xdef8, 0, 0);
+		pirq_info++; slot_num++;
+	}
+
+#if CONFIG_CBB
+	write_pirq_info(pirq_info, CONFIG_CBB, (0<<3)|0, 0x1, 0xdef8, 0x2, 0xdef8, 0x3, 0xdef8, 0x4, 0xdef8, 0, 0);
+	pirq_info++; slot_num++;
+	if(sysconf.nodes>32) {
+		write_pirq_info(pirq_info, CONFIG_CBB-1, (0<<3)|0, 0x1, 0xdef8, 0x2, 0xdef8, 0x3, 0xdef8, 0x4, 0xdef8, 0, 0);
+		pirq_info++; slot_num++;
+	}
+#endif
+
+	pirq->size = 32 + 16 * slot_num; 
+
+	for (i = 0; i < pirq->size; i++)
+		sum += v[i];	
+
+	sum = pirq->checksum - sum;
+
+	if (sum != pirq->checksum) {
+		pirq->checksum = sum;
+	}
+
+	printk_info("done.\n");
+
+	return	(unsigned long) pirq_info;
+
+}

Added: trunk/src/mainboard/msi/ms9652_fam10/mainboard.c
==============================================================================
--- /dev/null	00:00:00 1970	(empty, because file is newly added)
+++ trunk/src/mainboard/msi/ms9652_fam10/mainboard.c	Mon Mar  1 11:56:51 2010	(r5180)
@@ -0,0 +1,31 @@
+/*
+ * This file is part of the coreboot project.
+ *
+ * Copyright (C) 2007 AMD
+ * Written by Yinghai Lu <yinghailu at amd.com> for AMD.
+ *
+ * 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 <console/console.h>
+#include <device/device.h>
+#include <device/pci.h>
+#include <device/pci_ids.h>
+#include <device/pci_ops.h>
+#include "chip.h"
+
+struct chip_operations mainboard_ops = {
+	CHIP_NAME("MSI MS-9652 Mainboard (Family 10)")
+};

Added: trunk/src/mainboard/msi/ms9652_fam10/mb_sysconf.h
==============================================================================
--- /dev/null	00:00:00 1970	(empty, because file is newly added)
+++ trunk/src/mainboard/msi/ms9652_fam10/mb_sysconf.h	Mon Mar  1 11:56:51 2010	(r5180)
@@ -0,0 +1,34 @@
+/*
+ * This file is part of the coreboot project.
+ *
+ * Copyright (C) 2007 AMD
+ * Written by Yinghai Lu <yinghailu at amd.com> for AMD.
+ *
+ * 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
+ */
+
+#ifndef MB_SYSCONF_H
+#define MB_SYSCONF_H
+
+struct mb_sysconf_t {
+	unsigned char bus_isa;
+	unsigned char bus_mcp55[8]; //1
+	unsigned apicid_mcp55;
+	unsigned bus_type[256]; 
+
+};
+
+#endif
+

Added: trunk/src/mainboard/msi/ms9652_fam10/mptable.c
==============================================================================
--- /dev/null	00:00:00 1970	(empty, because file is newly added)
+++ trunk/src/mainboard/msi/ms9652_fam10/mptable.c	Mon Mar  1 11:56:51 2010	(r5180)
@@ -0,0 +1,162 @@
+/*
+ * This file is part of the coreboot project.
+ *
+ * Copyright (C) 2007 AMD
+ * Written by Yinghai Lu <yinghailu at amd.com> for AMD.
+ *
+ * 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 <console/console.h>
+#include <arch/smp/mpspec.h>
+#include <device/pci.h>
+#include <string.h>
+#include <stdint.h>
+
+#include <cpu/amd/amdfam10_sysconf.h>
+
+#include "mb_sysconf.h"
+
+extern void get_bus_conf(void);
+
+void *smp_write_config_table(void *v)
+{
+	static const char sig[4] = "PCMP";
+	static const char oem[8] = "MSI     ";
+	static const char productid[12] = "K9ND MS-9652";
+	struct mp_config_table *mc;
+	struct mb_sysconf_t *m;
+	unsigned sbdn;
+
+	int i,j;
+
+	mc = (void *)(((char *)v) + SMP_FLOATING_TABLE_LEN);
+	memset(mc, 0, sizeof(*mc));
+
+	memcpy(mc->mpc_signature, sig, sizeof(sig));
+	mc->mpc_length = sizeof(*mc); /* initially just the header */
+	mc->mpc_spec = 0x04;
+	mc->mpc_checksum = 0; /* not yet computed */
+	memcpy(mc->mpc_oem, oem, sizeof(oem));
+	memcpy(mc->mpc_productid, productid, sizeof(productid));
+	mc->mpc_oemptr = 0;
+	mc->mpc_oemsize = 0;
+	mc->mpc_entry_count = 0; /* No entries yet... */
+	mc->mpc_lapic = LAPIC_ADDR;
+	mc->mpe_length = 0;
+	mc->mpe_checksum = 0;
+	mc->reserved = 0;
+
+	smp_write_processors(mc);
+
+	get_bus_conf();
+	sbdn = sysconf.sbdn;
+	m = sysconf.mb;
+
+/*Bus:		Bus ID	Type*/
+	/* define bus and isa numbers */
+	for(j= 0; j < 256 ; j++) {
+		if(m->bus_type[j])
+			 smp_write_bus(mc, j, "PCI   ");
+	}
+	smp_write_bus(mc, m->bus_isa, "ISA   ");
+
+/*I/O APICs:	APIC ID	Version	State		Address*/
+	{
+		device_t dev;
+		struct resource *res;
+		uint32_t dword;
+
+		dev = dev_find_slot(m->bus_mcp55[0], PCI_DEVFN(sbdn+ 0x1,0));
+		if (dev) {
+			res = find_resource(dev, PCI_BASE_ADDRESS_1);
+			if (res) {
+				smp_write_ioapic(mc, m->apicid_mcp55, 0x11, res->base);
+			}
+
+			dword = 0x43c6c643;
+			pci_write_config32(dev, 0x7c, dword);
+
+			dword = 0x81001a00;
+			pci_write_config32(dev, 0x80, dword);
+
+			dword = 0xd00012d2;
+			pci_write_config32(dev, 0x84, dword);
+
+		}
+
+
+	}
+
+			/*I/O Ints:	Type	Polarity    Trigger			Bus ID	 IRQ	APIC ID	PIN# */
+	smp_write_intsrc(mc, mp_ExtINT, MP_IRQ_TRIGGER_EDGE|MP_IRQ_POLARITY_HIGH, m->bus_isa, 0x0, m->apicid_mcp55, 0x0);
+	smp_write_intsrc(mc, mp_INT, MP_IRQ_TRIGGER_EDGE|MP_IRQ_POLARITY_HIGH,  m->bus_isa, 0x1, m->apicid_mcp55, 0x1);
+	smp_write_intsrc(mc, mp_INT, MP_IRQ_TRIGGER_EDGE|MP_IRQ_POLARITY_HIGH,  m->bus_isa, 0x0, m->apicid_mcp55, 0x2);
+	smp_write_intsrc(mc, mp_INT, MP_IRQ_TRIGGER_EDGE|MP_IRQ_POLARITY_HIGH,  m->bus_isa, 0x3, m->apicid_mcp55, 0x3);
+	smp_write_intsrc(mc, mp_INT, MP_IRQ_TRIGGER_EDGE|MP_IRQ_POLARITY_HIGH,  m->bus_isa, 0x4, m->apicid_mcp55, 0x4);
+	smp_write_intsrc(mc, mp_INT, MP_IRQ_TRIGGER_EDGE|MP_IRQ_POLARITY_HIGH,  m->bus_isa, 0x6, m->apicid_mcp55, 0x6);
+	smp_write_intsrc(mc, mp_INT, MP_IRQ_TRIGGER_EDGE|MP_IRQ_POLARITY_HIGH,  m->bus_isa, 0x7, m->apicid_mcp55, 0x7);
+	smp_write_intsrc(mc, mp_INT, MP_IRQ_TRIGGER_EDGE|MP_IRQ_POLARITY_HIGH,  m->bus_isa, 0x8, m->apicid_mcp55, 0x8);
+	smp_write_intsrc(mc, mp_INT, MP_IRQ_TRIGGER_EDGE|MP_IRQ_POLARITY_HIGH,  m->bus_isa, 0xc, m->apicid_mcp55, 0xc);
+	smp_write_intsrc(mc, mp_INT, MP_IRQ_TRIGGER_EDGE|MP_IRQ_POLARITY_HIGH,  m->bus_isa, 0xd, m->apicid_mcp55, 0xd);
+	smp_write_intsrc(mc, mp_INT, MP_IRQ_TRIGGER_EDGE|MP_IRQ_POLARITY_HIGH,  m->bus_isa, 0xe, m->apicid_mcp55, 0xe);
+	smp_write_intsrc(mc, mp_INT, MP_IRQ_TRIGGER_EDGE|MP_IRQ_POLARITY_HIGH,  m->bus_isa, 0xf, m->apicid_mcp55, 0xf);
+
+	smp_write_intsrc(mc, mp_INT, MP_IRQ_TRIGGER_LEVEL|MP_IRQ_POLARITY_LOW, m->bus_mcp55[0], ((sbdn+1)<<2)|1, m->apicid_mcp55, 0xa);
+
+	smp_write_intsrc(mc, mp_INT, MP_IRQ_TRIGGER_LEVEL|MP_IRQ_POLARITY_LOW, m->bus_mcp55[0], ((sbdn+2)<<2)|0, m->apicid_mcp55, 0x16); // 22
+
+	smp_write_intsrc(mc, mp_INT, MP_IRQ_TRIGGER_LEVEL|MP_IRQ_POLARITY_LOW, m->bus_mcp55[0], ((sbdn+2)<<2)|1, m->apicid_mcp55, 0x17); // 23
+
+	smp_write_intsrc(mc, mp_INT, MP_IRQ_TRIGGER_LEVEL|MP_IRQ_POLARITY_LOW, m->bus_mcp55[0], ((sbdn+6)<<2)|1, m->apicid_mcp55, 0x17); // 23
+
+	smp_write_intsrc(mc, mp_INT, MP_IRQ_TRIGGER_LEVEL|MP_IRQ_POLARITY_LOW, m->bus_mcp55[0], ((sbdn+5)<<2)|0, m->apicid_mcp55, 0x14); // 20
+	smp_write_intsrc(mc, mp_INT, MP_IRQ_TRIGGER_LEVEL|MP_IRQ_POLARITY_LOW, m->bus_mcp55[0], ((sbdn+5)<<2)|1, m->apicid_mcp55, 0x17); // 23
+	smp_write_intsrc(mc, mp_INT, MP_IRQ_TRIGGER_LEVEL|MP_IRQ_POLARITY_LOW, m->bus_mcp55[0], ((sbdn+5)<<2)|2, m->apicid_mcp55, 0x15); // 21
+
+	smp_write_intsrc(mc, mp_INT, MP_IRQ_TRIGGER_LEVEL|MP_IRQ_POLARITY_LOW, m->bus_mcp55[0], ((sbdn+8)<<2)|0, m->apicid_mcp55, 0x16); // 22
+	smp_write_intsrc(mc, mp_INT, MP_IRQ_TRIGGER_LEVEL|MP_IRQ_POLARITY_LOW, m->bus_mcp55[0], ((sbdn+9)<<2)|0, m->apicid_mcp55, 0x15); // 21
+
+	for(j=7; j>=2; j--) {
+		if(!m->bus_mcp55[j]) continue;
+		for(i=0;i<4;i++) {
+			smp_write_intsrc(mc, mp_INT, MP_IRQ_TRIGGER_LEVEL|MP_IRQ_POLARITY_LOW, m->bus_mcp55[j], (0x00<<2)|i, m->apicid_mcp55, 0x10 + (2+j+i+4-sbdn%4)%4);
+		}
+	}
+
+	for(j=0; j<1; j++)
+		for(i=0;i<4;i++) {
+			smp_write_intsrc(mc, mp_INT, MP_IRQ_TRIGGER_LEVEL|MP_IRQ_POLARITY_LOW, m->bus_mcp55[1], ((0x04+j)<<2)|i, m->apicid_mcp55, 0x10 + (2+i+j)%4);
+		}
+
+/*Local Ints:	Type	Polarity    Trigger	Bus ID	 IRQ	APIC ID	PIN#*/
+	smp_write_intsrc(mc, mp_ExtINT, MP_IRQ_TRIGGER_EDGE|MP_IRQ_POLARITY_HIGH, m->bus_isa, 0x0, MP_APIC_ALL, 0x0);
+	smp_write_intsrc(mc, mp_NMI, MP_IRQ_TRIGGER_EDGE|MP_IRQ_POLARITY_HIGH, m->bus_isa, 0x0, MP_APIC_ALL, 0x1);
+	/* There is no extension information... */
+
+	/* Compute the checksums */
+	mc->mpe_checksum = smp_compute_checksum(smp_next_mpc_entry(mc), mc->mpe_length);
+	mc->mpc_checksum = smp_compute_checksum(mc, mc->mpc_length);
+	printk_debug("Wrote the mp table end at: %p - %p\n",
+		mc, smp_next_mpe_entry(mc));
+	return smp_next_mpe_entry(mc);
+}
+
+unsigned long write_smp_table(unsigned long addr)
+{
+	void *v;
+	v = smp_write_floating_table(addr);
+	return (unsigned long)smp_write_config_table(v);
+}

Added: trunk/src/mainboard/msi/ms9652_fam10/resourcemap.c
==============================================================================
--- /dev/null	00:00:00 1970	(empty, because file is newly added)
+++ trunk/src/mainboard/msi/ms9652_fam10/resourcemap.c	Mon Mar  1 11:56:51 2010	(r5180)
@@ -0,0 +1,287 @@
+/*
+ * This file is part of the coreboot project.
+ *
+ * Copyright (C) 2007 AMD
+ * Written by Yinghai Lu <yinghailu at amd.com> for AMD.
+ *
+ * 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
+ */
+
+static void setup_mb_resource_map(void)
+{
+	static const unsigned int register_values[] = {
+		/* Careful set limit registers before base registers which contain the enables */
+		/* DRAM Limit i Registers
+		 * F1:0x44 i = 0
+		 * F1:0x4C i = 1
+		 * F1:0x54 i = 2
+		 * F1:0x5C i = 3
+		 * F1:0x64 i = 4
+		 * F1:0x6C i = 5
+		 * F1:0x74 i = 6
+		 * F1:0x7C i = 7
+		 * [ 2: 0] Destination Node ID
+		 *	   000 = Node 0
+		 *	   001 = Node 1
+		 *	   010 = Node 2
+		 *	   011 = Node 3
+		 *	   100 = Node 4
+		 *	   101 = Node 5
+		 *	   110 = Node 6
+		 *	   111 = Node 7
+		 * [ 7: 3] Reserved
+		 * [10: 8] Interleave select
+		 *	   specifies the values of A[14:12] to use with interleave enable.
+		 * [15:11] Reserved
+		 * [31:16] DRAM Limit Address i Bits 39-24
+		 *	   This field defines the upper address bits of a 40 bit  address
+		 *	   that define the end of the DRAM region.
+		 */
+		// PCI_ADDR(CONFIG_CBB, CONFIG_CDB, 1, 0x44), 0x0000f8f8, 0x00000000, // Don't touch it, we need it for CAR with FAM10
+		PCI_ADDR(CONFIG_CBB, CONFIG_CDB, 1, 0x4C), 0x0000f8f8, 0x00000001,
+		PCI_ADDR(CONFIG_CBB, CONFIG_CDB, 1, 0x54), 0x0000f8f8, 0x00000002,
+		PCI_ADDR(CONFIG_CBB, CONFIG_CDB, 1, 0x5C), 0x0000f8f8, 0x00000003,
+		PCI_ADDR(CONFIG_CBB, CONFIG_CDB, 1, 0x64), 0x0000f8f8, 0x00000004,
+		PCI_ADDR(CONFIG_CBB, CONFIG_CDB, 1, 0x6C), 0x0000f8f8, 0x00000005,
+		PCI_ADDR(CONFIG_CBB, CONFIG_CDB, 1, 0x74), 0x0000f8f8, 0x00000006,
+		PCI_ADDR(CONFIG_CBB, CONFIG_CDB, 1, 0x7C), 0x0000f8f8, 0x00000007,
+
+		/* DRAM Base i Registers
+		 * F1:0x40 i = 0
+		 * F1:0x48 i = 1
+		 * F1:0x50 i = 2
+		 * F1:0x58 i = 3
+		 * F1:0x60 i = 4
+		 * F1:0x68 i = 5
+		 * F1:0x70 i = 6
+		 * F1:0x78 i = 7
+		 * [ 0: 0] Read Enable
+		 *	   0 = Reads Disabled
+		 *	   1 = Reads Enabled
+		 * [ 1: 1] Write Enable
+		 *	   0 = Writes Disabled
+		 *	   1 = Writes Enabled
+		 * [ 7: 2] Reserved
+		 * [10: 8] Interleave Enable
+		 *	   000 = No interleave
+		 *	   001 = Interleave on A[12] (2 nodes)
+		 *	   010 = reserved
+		 *	   011 = Interleave on A[12] and A[14] (4 nodes)
+		 *	   100 = reserved
+		 *	   101 = reserved
+		 *	   110 = reserved
+		 *	   111 = Interleve on A[12] and A[13] and A[14] (8 nodes)
+		 * [15:11] Reserved
+		 * [13:16] DRAM Base Address i Bits 39-24
+		 *	   This field defines the upper address bits of a 40-bit address
+		 *	   that define the start of the DRAM region.
+		 */
+		// PCI_ADDR(CONFIG_CBB, CONFIG_CDB, 1, 0x40), 0x0000f8fc, 0x00000000, // don't touch it, we need it for CAR with FAM10
+		PCI_ADDR(CONFIG_CBB, CONFIG_CDB, 1, 0x48), 0x0000f8fc, 0x00000000,
+		PCI_ADDR(CONFIG_CBB, CONFIG_CDB, 1, 0x50), 0x0000f8fc, 0x00000000,
+		PCI_ADDR(CONFIG_CBB, CONFIG_CDB, 1, 0x58), 0x0000f8fc, 0x00000000,
+		PCI_ADDR(CONFIG_CBB, CONFIG_CDB, 1, 0x60), 0x0000f8fc, 0x00000000,
+		PCI_ADDR(CONFIG_CBB, CONFIG_CDB, 1, 0x68), 0x0000f8fc, 0x00000000,
+		PCI_ADDR(CONFIG_CBB, CONFIG_CDB, 1, 0x70), 0x0000f8fc, 0x00000000,
+		PCI_ADDR(CONFIG_CBB, CONFIG_CDB, 1, 0x78), 0x0000f8fc, 0x00000000,
+
+		/* Memory-Mapped I/O Limit i Registers
+		 * F1:0x84 i = 0
+		 * F1:0x8C i = 1
+		 * F1:0x94 i = 2
+		 * F1:0x9C i = 3
+		 * F1:0xA4 i = 4
+		 * F1:0xAC i = 5
+		 * F1:0xB4 i = 6
+		 * F1:0xBC i = 7
+		 * [ 2: 0] Destination Node ID
+		 *	   000 = Node 0
+		 *	   001 = Node 1
+		 *	   010 = Node 2
+		 *	   011 = Node 3
+		 *	   100 = Node 4
+		 *	   101 = Node 5
+		 *	   110 = Node 6
+		 *	   111 = Node 7
+		 * [ 3: 3] Reserved
+		 * [ 5: 4] Destination Link ID
+		 *	   00 = Link 0
+		 *	   01 = Link 1
+		 *	   10 = Link 2
+		 *	   11 = Reserved
+		 * [ 6: 6] Reserved
+		 * [ 7: 7] Non-Posted
+		 *	   0 = CPU writes may be posted
+		 *	   1 = CPU writes must be non-posted
+		 * [31: 8] Memory-Mapped I/O Limit Address i (39-16)
+		 *	   This field defines the upp adddress bits of a 40-bit address that
+		 *	   defines the end of a memory-mapped I/O region n
+		 */
+		PCI_ADDR(CONFIG_CBB, CONFIG_CDB, 1, 0x84), 0x00000048, 0x00000000,
+		PCI_ADDR(CONFIG_CBB, CONFIG_CDB, 1, 0x8C), 0x00000048, 0x00000000,
+		PCI_ADDR(CONFIG_CBB, CONFIG_CDB, 1, 0x94), 0x00000048, 0x00000000,
+		PCI_ADDR(CONFIG_CBB, CONFIG_CDB, 1, 0x9C), 0x00000048, 0x00000000,
+		PCI_ADDR(CONFIG_CBB, CONFIG_CDB, 1, 0xA4), 0x00000048, 0x00000000,
+		PCI_ADDR(CONFIG_CBB, CONFIG_CDB, 1, 0xAC), 0x00000048, 0x00000000,
+		PCI_ADDR(CONFIG_CBB, CONFIG_CDB, 1, 0xB4), 0x00000048, 0x00000000,
+//		PCI_ADDR(CONFIG_CBB, CONFIG_CDB, 1, 0xBC), 0x00000048, 0x00ffff00,
+
+		/* Memory-Mapped I/O Base i Registers
+		 * F1:0x80 i = 0
+		 * F1:0x88 i = 1
+		 * F1:0x90 i = 2
+		 * F1:0x98 i = 3
+		 * F1:0xA0 i = 4
+		 * F1:0xA8 i = 5
+		 * F1:0xB0 i = 6
+		 * F1:0xB8 i = 7
+		 * [ 0: 0] Read Enable
+		 *	   0 = Reads disabled
+		 *	   1 = Reads Enabled
+		 * [ 1: 1] Write Enable
+		 *	   0 = Writes disabled
+		 *	   1 = Writes Enabled
+		 * [ 2: 2] Cpu Disable
+		 *	   0 = Cpu can use this I/O range
+		 *	   1 = Cpu requests do not use this I/O range
+		 * [ 3: 3] Lock
+		 *	   0 = base/limit registers i are read/write
+		 *	   1 = base/limit registers i are read-only
+		 * [ 7: 4] Reserved
+		 * [31: 8] Memory-Mapped I/O Base Address i (39-16)
+		 *	   This field defines the upper address bits of a 40bit address 
+		 *	   that defines the start of memory-mapped I/O region i
+		 */
+		PCI_ADDR(CONFIG_CBB, CONFIG_CDB, 1, 0x80), 0x000000f0, 0x00000000,
+		PCI_ADDR(CONFIG_CBB, CONFIG_CDB, 1, 0x88), 0x000000f0, 0x00000000,
+		PCI_ADDR(CONFIG_CBB, CONFIG_CDB, 1, 0x90), 0x000000f0, 0x00000000,
+		PCI_ADDR(CONFIG_CBB, CONFIG_CDB, 1, 0x98), 0x000000f0, 0x00000000,
+		PCI_ADDR(CONFIG_CBB, CONFIG_CDB, 1, 0xA0), 0x000000f0, 0x00000000,
+		PCI_ADDR(CONFIG_CBB, CONFIG_CDB, 1, 0xA8), 0x000000f0, 0x00000000,
+		PCI_ADDR(CONFIG_CBB, CONFIG_CDB, 1, 0xB0), 0x000000f0, 0x00000000,
+//		PCI_ADDR(CONFIG_CBB, CONFIG_CDB, 1, 0xB8), 0x000000f0, 0x00fc0003,
+
+		/* PCI I/O Limit i Registers
+		 * F1:0xC4 i = 0
+		 * F1:0xCC i = 1
+		 * F1:0xD4 i = 2
+		 * F1:0xDC i = 3
+		 * [ 2: 0] Destination Node ID
+		 *	   000 = Node 0
+		 *	   001 = Node 1
+		 *	   010 = Node 2
+		 *	   011 = Node 3
+		 *	   100 = Node 4
+		 *	   101 = Node 5
+		 *	   110 = Node 6
+		 *	   111 = Node 7
+		 * [ 3: 3] Reserved
+		 * [ 5: 4] Destination Link ID
+		 *	   00 = Link 0
+		 *	   01 = Link 1
+		 *	   10 = Link 2
+		 *	   11 = reserved
+		 * [11: 6] Reserved
+		 * [24:12] PCI I/O Limit Address i
+		 *	   This field defines the end of PCI I/O region n
+		 * [31:25] Reserved
+		 */
+//		PCI_ADDR(CONFIG_CBB, CONFIG_CDB, 1, 0xC4), 0xFE000FC8, 0x00004000,
+		PCI_ADDR(CONFIG_CBB, CONFIG_CDB, 1, 0xC4), 0xFE000FC8, 0x01fff000,
+		PCI_ADDR(CONFIG_CBB, CONFIG_CDB, 1, 0xCC), 0xFE000FC8, 0x00000000,
+		PCI_ADDR(CONFIG_CBB, CONFIG_CDB, 1, 0xD4), 0xFE000FC8, 0x00000000,
+		PCI_ADDR(CONFIG_CBB, CONFIG_CDB, 1, 0xDC), 0xFE000FC8, 0x00000000,
+
+		/* PCI I/O Base i Registers
+		 * F1:0xC0 i = 0
+		 * F1:0xC8 i = 1
+		 * F1:0xD0 i = 2
+		 * F1:0xD8 i = 3
+		 * [ 0: 0] Read Enable
+		 *	   0 = Reads Disabled
+		 *	   1 = Reads Enabled
+		 * [ 1: 1] Write Enable
+		 *	   0 = Writes Disabled
+		 *	   1 = Writes Enabled
+		 * [ 3: 2] Reserved
+		 * [ 4: 4] VGA Enable
+		 *	   0 = VGA matches Disabled
+		 *	   1 = matches all address < 64K and where A[9:0] is in the 
+		 *	       range 3B0-3BB or 3C0-3DF independen of the base & limit registers
+		 * [ 5: 5] ISA Enable
+		 *	   0 = ISA matches Disabled
+		 *	   1 = Blocks address < 64K and in the last 768 bytes of eack 1K block
+		 *	       from matching agains this base/limit pair
+		 * [11: 6] Reserved
+		 * [24:12] PCI I/O Base i
+		 *	   This field defines the start of PCI I/O region n 
+		 * [31:25] Reserved
+		 */
+		/* Verified against board configuration registers after normal proprietary BIOS boot */
+		//PCI_ADDR(CONFIG_CBB, CONFIG_CDB, 1, 0xC0), 0xFE000FCC, 0x00001033,
+		PCI_ADDR(CONFIG_CBB, CONFIG_CDB, 1, 0xC0), 0xFE000FCC, 0x00000033,
+		PCI_ADDR(CONFIG_CBB, CONFIG_CDB, 1, 0xC8), 0xFE000FCC, 0x00000000,
+		PCI_ADDR(CONFIG_CBB, CONFIG_CDB, 1, 0xD0), 0xFE000FCC, 0x00000000,
+		PCI_ADDR(CONFIG_CBB, CONFIG_CDB, 1, 0xD8), 0xFE000FCC, 0x00000000,
+
+		/* Config Base and Limit i Registers
+		 * F1:0xE0 i = 0
+		 * F1:0xE4 i = 1
+		 * F1:0xE8 i = 2
+		 * F1:0xEC i = 3
+		 * [ 0: 0] Read Enable
+		 *	   0 = Reads Disabled
+		 *	   1 = Reads Enabled
+		 * [ 1: 1] Write Enable
+		 *	   0 = Writes Disabled
+		 *	   1 = Writes Enabled
+		 * [ 2: 2] Device Number Compare Enable
+		 *	   0 = The ranges are based on bus number
+		 *	   1 = The ranges are ranges of devices on bus 0
+		 * [ 3: 3] Reserved
+		 * [ 6: 4] Destination Node
+		 *	   000 = Node 0
+		 *	   001 = Node 1
+		 *	   010 = Node 2
+		 *	   011 = Node 3
+		 *	   100 = Node 4
+		 *	   101 = Node 5
+		 *	   110 = Node 6
+		 *	   111 = Node 7
+		 * [ 7: 7] Reserved
+		 * [ 9: 8] Destination Link
+		 *	   00 = Link 0
+		 *	   01 = Link 1
+		 *	   10 = Link 2
+		 *	   11 - Reserved
+		 * [15:10] Reserved
+		 * [23:16] Bus Number Base i
+		 *	   This field defines the lowest bus number in configuration region i
+		 * [31:24] Bus Number Limit i
+		 *	   This field defines the highest bus number in configuration region i
+		 */
+		/* Verified against board configuration registers after normal proprietary BIOS boot */
+		PCI_ADDR(CONFIG_CBB, CONFIG_CDB, 1, 0xE0), 0x0000FC88, 0xff000003, /* link 0 of cpu 0 --> Nvidia MCP55 Pro */
+		PCI_ADDR(CONFIG_CBB, CONFIG_CDB, 1, 0xE4), 0x0000FC88, 0x00000000,
+		PCI_ADDR(CONFIG_CBB, CONFIG_CDB, 1, 0xE8), 0x0000FC88, 0x00000000,
+		PCI_ADDR(CONFIG_CBB, CONFIG_CDB, 1, 0xEC), 0x0000FC88, 0x00000000,
+
+	};
+
+	int max;
+	max = ARRAY_SIZE(register_values);
+	setup_resource_map(register_values, max);
+}
+

Added: trunk/src/mainboard/msi/ms9652_fam10/romstage.c
==============================================================================
--- /dev/null	00:00:00 1970	(empty, because file is newly added)
+++ trunk/src/mainboard/msi/ms9652_fam10/romstage.c	Mon Mar  1 11:56:51 2010	(r5180)
@@ -0,0 +1,389 @@
+/*
+ * This file is part of the coreboot project.
+ *
+ * Copyright (C) 2007 AMD
+ * Written by Yinghai Lu <yinghailu at amd.com> for AMD.
+ *
+ * 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
+ */
+
+#define ASSEMBLY 1
+#define __PRE_RAM__
+
+#define RAMINIT_SYSINFO 1
+
+#define FAM10_SCAN_PCI_BUS 0
+#define FAM10_ALLOCATE_IO_RANGE 1
+
+#define QRANK_DIMM_SUPPORT 1
+
+#if CONFIG_LOGICAL_CPUS==1
+#define SET_NB_CFG_54 1
+#endif
+
+#define FAM10_SET_FIDVID 1
+#define FAM10_SET_FIDVID_CORE_RANGE 0
+
+#define DBGP_DEFAULT 7
+
+#include <stdint.h>
+#include <string.h>
+#include <device/pci_def.h>
+#include <device/pci_ids.h>
+#include <arch/io.h>
+#include <device/pnp_def.h>
+#include <arch/romcc_io.h>
+#include <cpu/x86/lapic.h>
+#include "option_table.h"
+#include "pc80/mc146818rtc_early.c"
+#include "pc80/serial.c"
+
+ static void post_code(u8 value) {
+ 	outb(value, 0x80);
+ }
+
+#if CONFIG_USE_FAILOVER_IMAGE==0
+#include "arch/i386/lib/console.c"
+#if CONFIG_USBDEBUG_DIRECT
+#include "southbridge/nvidia/mcp55/mcp55_enable_usbdebug_direct.c"
+#include "pc80/usbdebug_direct_serial.c"
+#endif
+#include "lib/ramtest.c"
+
+#include <cpu/amd/model_10xxx_rev.h>
+
+#include "southbridge/nvidia/mcp55/mcp55_early_smbus.c"
+#include "northbridge/amd/amdfam10/raminit.h"
+#include "northbridge/amd/amdfam10/amdfam10.h"
+
+#endif
+
+#include "cpu/x86/lapic/boot_cpu.c"
+#include "northbridge/amd/amdfam10/reset_test.c"
+#include "superio/winbond/w83627ehg/w83627ehg_early_serial.c"
+
+#if CONFIG_USE_FAILOVER_IMAGE==0
+
+#include "cpu/x86/bist.h"
+
+#include "northbridge/amd/amdfam10/debug.c"
+
+#include "cpu/amd/mtrr/amd_earlymtrr.c"
+
+#include "northbridge/amd/amdfam10/setup_resource_map.c"
+
+#define SERIAL_DEV PNP_DEV(0x2e, W83627EHG_SP1)
+#define RTC_DEV PNP_DEV(0x2e, W83627EHG_RTC)
+
+#include "southbridge/nvidia/mcp55/mcp55_early_ctrl.c"
+
+static void memreset_setup(void)
+{
+}
+
+static void memreset(int controllers, const struct mem_controller *ctrl)
+{
+}
+
+static inline void activate_spd_rom(const struct mem_controller *ctrl)
+{
+	/* nothing to do */
+}
+
+static inline int spd_read_byte(unsigned device, unsigned address)
+{
+	return smbus_read_byte(device, address);
+}
+
+#include "northbridge/amd/amdfam10/amdfam10.h"
+#include "northbridge/amd/amdht/ht_wrapper.c"
+
+#include "include/cpu/x86/mem.h"
+#include "northbridge/amd/amdfam10/raminit_sysinfo_in_ram.c"
+#include "northbridge/amd/amdfam10/raminit_amdmct.c"
+#include "northbridge/amd/amdfam10/amdfam10_pci.c"
+
+#include "resourcemap.c"
+
+#include "cpu/amd/quadcore/quadcore.c"
+
+#define MCP55_NUM 1
+#define MCP55_USE_NIC 1
+#define MCP55_USE_AZA 1
+
+#define MCP55_PCI_E_X_0 1
+
+#define MCP55_MB_SETUP \
+	RES_PORT_IO_8, SYSCTRL_IO_BASE + 0xc0+37, 0x00, 0x44,/* GPIO38 PCI_REQ3 */ \
+	RES_PORT_IO_8, SYSCTRL_IO_BASE + 0xc0+38, 0x00, 0x44,/* GPIO39 PCI_GNT3 */ \
+	RES_PORT_IO_8, SYSCTRL_IO_BASE + 0xc0+39, 0x00, 0x44,/* GPIO40 PCI_GNT2 */ \
+	RES_PORT_IO_8, SYSCTRL_IO_BASE + 0xc0+40, 0x00, 0x44,/* GPIO41 PCI_REQ2 */ \
+	RES_PORT_IO_8, SYSCTRL_IO_BASE + 0xc0+59, 0x00, 0x60,/* GPIP60 FANCTL0 */ \
+	RES_PORT_IO_8, SYSCTRL_IO_BASE + 0xc0+60, 0x00, 0x60,/* GPIO61 FANCTL1 */
+
+#include "southbridge/nvidia/mcp55/mcp55_early_setup_ss.h"
+#include "southbridge/nvidia/mcp55/mcp55_early_setup_car.c"
+
+#include "cpu/amd/car/copy_and_run.c"
+
+#include "cpu/amd/car/post_cache_as_ram.c"
+
+#include "cpu/amd/model_10xxx/init_cpus.c"
+
+#include "cpu/amd/model_10xxx/fidvid.c"
+
+#endif
+
+#if ((CONFIG_HAVE_FAILOVER_BOOT==1) && (CONFIG_USE_FAILOVER_IMAGE == 1)) || ((CONFIG_HAVE_FAILOVER_BOOT==0) && (CONFIG_USE_FALLBACK_IMAGE == 1))
+
+#include "southbridge/nvidia/mcp55/mcp55_enable_rom.c"
+#include "northbridge/amd/amdfam10/early_ht.c"
+
+static void sio_setup(void)
+{
+
+        unsigned value;
+        uint32_t dword;
+        uint8_t byte;
+
+        byte = pci_read_config32(PCI_DEV(0, MCP55_DEVN_BASE+1 , 0), 0x7b);
+        byte |= 0x20;
+        pci_write_config8(PCI_DEV(0, MCP55_DEVN_BASE+1 , 0), 0x7b, byte);
+
+        dword = pci_read_config32(PCI_DEV(0, MCP55_DEVN_BASE+1 , 0), 0xa0);
+        dword |= (1<<0);
+        pci_write_config32(PCI_DEV(0, MCP55_DEVN_BASE+1 , 0), 0xa0, dword);
+
+
+}
+
+void failover_process(unsigned long bist, unsigned long cpu_init_detectedx)
+{
+	unsigned last_boot_normal_x = last_boot_normal();
+
+	/* Is this a cpu only reset? or Is this a secondary cpu? */
+	if ((cpu_init_detectedx) || (!boot_cpu())) {
+		if (last_boot_normal_x) {
+			goto normal_image;
+		} else {
+			goto fallback_image;
+		}
+	}
+
+	/* Nothing special needs to be done to find bus 0 */
+	/* Allow the HT devices to be found */
+
+	set_bsp_node_CHtExtNodeCfgEn();
+	enumerate_ht_chain();
+
+	sio_setup();
+
+	/* Setup the mcp55 */
+	mcp55_enable_rom();
+
+	/* Is this a deliberate reset by the bios */
+	if (bios_reset_detected() && last_boot_normal_x) {
+		goto normal_image;
+	}
+	/* This is the primary cpu how should I boot? */
+	else if (do_normal_boot()) {
+		goto normal_image;
+	}
+	else {
+		goto fallback_image;
+	}
+ normal_image:
+	__asm__ volatile ("jmp __normal_image"
+		: /* outputs */
+		: "a" (bist), "b" (cpu_init_detectedx) /* inputs */
+		);
+
+ fallback_image:
+#if CONFIG_HAVE_FAILOVER_BOOT==1
+	__asm__ volatile ("jmp __fallback_image"
+		: /* outputs */
+		: "a" (bist), "b" (cpu_init_detectedx) /* inputs */
+		)
+#endif
+	;
+}
+#endif
+void real_main(unsigned long bist, unsigned long cpu_init_detectedx);
+
+void cache_as_ram_main(unsigned long bist, unsigned long cpu_init_detectedx)
+{
+#if CONFIG_HAVE_FAILOVER_BOOT==1
+    #if CONFIG_USE_FAILOVER_IMAGE==1
+	failover_process(bist, cpu_init_detectedx);
+    #else
+	real_main(bist, cpu_init_detectedx);
+    #endif
+#else
+    #if CONFIG_USE_FALLBACK_IMAGE == 1
+	failover_process(bist, cpu_init_detectedx);
+    #endif
+	real_main(bist, cpu_init_detectedx);
+#endif
+}
+
+#if CONFIG_USE_FAILOVER_IMAGE==0
+#include "spd_addr.h"
+#include "cpu/amd/microcode/microcode.c"
+#include "cpu/amd/model_10xxx/update_microcode.c"
+
+void real_main(unsigned long bist, unsigned long cpu_init_detectedx)
+{
+	struct sys_info *sysinfo = (struct sys_info *)(CONFIG_DCACHE_RAM_BASE + CONFIG_DCACHE_RAM_SIZE - CONFIG_DCACHE_RAM_GLOBAL_VAR_SIZE);
+
+	u32 bsp_apicid = 0;
+	u32 val;
+	u8 reg;
+	u32 wants_reset;
+	msr_t msr;
+
+	post_code(0x30);
+
+	if (bist == 0) {
+		bsp_apicid = init_cpus(cpu_init_detectedx, sysinfo);
+	}
+
+	post_code(0x32);
+
+	pnp_enter_ext_func_mode(SERIAL_DEV);
+	/* We have 24MHz input. */
+	reg = pnp_read_config(SERIAL_DEV, 0x24);
+	pnp_write_config(SERIAL_DEV, 0x24, (reg & 0xbf));
+	pnp_exit_ext_func_mode(SERIAL_DEV);
+
+	w83627ehg_enable_serial(SERIAL_DEV, CONFIG_TTYS0_BASE);
+	uart_init();
+	console_init();
+	printk_debug("\n");
+
+	/* Halt if there was a built in self test failure */
+	report_bist_failure(bist);
+
+#if CONFIG_USBDEBUG_DIRECT
+	mcp55_enable_usbdebug_direct(DBGP_DEFAULT);
+	early_usbdebug_direct_init();
+#endif
+
+	val = cpuid_eax(1);
+	printk_debug("BSP Family_Model: %08x \n", val);
+	printk_debug("*sysinfo range: ["); print_debug_hex32((u32)sysinfo); print_debug(","); print_debug_hex32((u32)sysinfo+sizeof(struct sys_info)); print_debug("]\n");
+	printk_debug("bsp_apicid = %02x \n", bsp_apicid);
+	printk_debug("cpu_init_detectedx = %08x \n", cpu_init_detectedx);
+
+	/* Setup sysinfo defaults */
+	set_sysinfo_in_ram(0);
+
+	update_microcode(val);
+	post_code(0x33);
+
+	cpuSetAMDMSR();
+	post_code(0x34);
+
+	amd_ht_init(sysinfo);
+	post_code(0x35);
+
+	/* Setup nodes PCI space and start core 0 AP init. */
+	finalize_node_setup(sysinfo);
+	printk_debug("finalize_node_setup done \n");
+
+	/* Setup any mainboard PCI settings etc. */
+	printk_debug("setup_mb_resource_map begin \n");
+	setup_mb_resource_map();
+	printk_debug("setup_mb_resource_map end \n");
+	post_code(0x36);
+
+	/* wait for all the APs core0 started by finalize_node_setup. */
+	/* FIXME: A bunch of cores are going to start output to serial at once.
+	 * It would be nice to fixup prink spinlocks for ROM XIP mode.
+	 * I think it could be done by putting the spinlock flag in the cache
+	 * of the BSP located right after sysinfo.
+	 */
+	wait_all_core0_started();
+
+#if CONFIG_LOGICAL_CPUS==1
+	/* Core0 on each node is configured. Now setup any additional cores. */
+	printk_debug("start_other_cores()\n");
+	start_other_cores();
+	post_code(0x37);
+	printk_debug("wait_all_other_cores_started()\n");
+	wait_all_other_cores_started(bsp_apicid);
+#endif
+
+	post_code(0x38);
+
+#if FAM10_SET_FIDVID == 1
+	msr = rdmsr(0xc0010071);
+	printk_debug("\nBegin FIDVID MSR 0xc0010071 0x%08x 0x%08x \n", msr.hi, msr.lo);
+
+	/* FIXME: The sb fid change may survive the warm reset and only
+	 * need to be done once.*/
+	enable_fid_change_on_sb(sysinfo->sbbusn, sysinfo->sbdn);
+
+	post_code(0x39);
+
+	if (!warm_reset_detect(0)) {			// BSP is node 0
+		init_fidvid_bsp(bsp_apicid, sysinfo->nodes);
+	} else {
+		init_fidvid_stage2(bsp_apicid, 0);	// BSP is node 0
+	}
+
+	post_code(0x3A);
+
+	/* show final fid and vid */
+	msr=rdmsr(0xc0010071);
+	printk_debug("End FIDVIDMSR 0xc0010071 0x%08x 0x%08x \n", msr.hi, msr.lo);
+#endif
+
+	wants_reset = mcp55_early_setup_x();
+
+	/* Reset for HT, FIDVID, PLL and errata changes to take affect. */
+	if (!warm_reset_detect(0)) {
+		print_info("...WARM RESET...\n\n\n");
+		soft_reset();
+		die("After soft_reset_x - shouldn't see this message!!!\n");
+	}
+
+	if (wants_reset)
+		printk_debug("mcp55_early_setup_x wanted additional reset!\n");
+
+	post_code(0x3B);
+
+	/* It's the time to set ctrl in sysinfo now; */
+	printk_debug("fill_mem_ctrl()\n");
+	fill_mem_ctrl(sysinfo->nodes, sysinfo->ctrl, spd_addr);
+	post_code(0x3D);
+
+	printk_debug("enable_smbus()\n");
+	enable_smbus();
+	post_code(0x3E);
+
+	memreset_setup();
+	post_code(0x40);
+
+	printk_debug("raminit_amdmct()\n");
+	raminit_amdmct(sysinfo);
+	post_code(0x41);
+
+	printk_debug("\n*** Yes, the copy/decompress is taking a while, FIXME!\n");
+	post_cache_as_ram();	// BSP switch stack to ram, copy then execute LB.
+	post_code(0x43);	// Should never see this post code.
+}
+
+
+#endif

Added: trunk/src/mainboard/msi/ms9652_fam10/spd_addr.h
==============================================================================
--- /dev/null	00:00:00 1970	(empty, because file is newly added)
+++ trunk/src/mainboard/msi/ms9652_fam10/spd_addr.h	Mon Mar  1 11:56:51 2010	(r5180)
@@ -0,0 +1,110 @@
+/*
+ * This file is part of the coreboot project.
+ *
+ * Copyright (C) 2007 Advanced Micro Devices, Inc.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; version 2 of the License.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA  02110-1301 USA
+ */
+
+/**
+ * This file defines the SPD addresses for the mainboard. Must be included in
+ * cache_as_ram_auto.c
+ */
+
+#define RC00 0
+#define RC01 1
+#define RC02 2
+#define RC03 3
+#define RC04 4
+#define RC05 5
+#define RC06 6
+#define RC07 7
+#define RC08 8
+#define RC09 9
+#define RC10 10
+#define RC11 11
+#define RC12 12
+#define RC13 13
+#define RC14 14
+#define RC15 15
+#define RC16 16
+#define RC17 17
+#define RC18 18
+#define RC19 19
+#define RC20 20
+#define RC21 21
+#define RC22 22
+#define RC23 23
+#define RC24 24
+#define RC25 25
+#define RC26 26
+#define RC27 27
+#define RC28 28
+#define RC29 29
+#define RC30 30
+#define RC31 31
+
+#define RC32 32
+#define RC33 33
+#define RC34 34
+#define RC35 35
+#define RC36 36
+#define RC37 37
+#define RC38 38
+#define RC39 39
+#define RC40 40
+#define RC41 41
+#define RC42 42
+#define RC43 43
+#define RC44 44
+#define RC45 45
+#define RC46 46
+#define RC47 47
+#define RC48 48
+#define RC49 49
+#define RC50 50
+#define RC51 51
+#define RC52 52
+#define RC53 53
+#define RC54 54
+#define RC55 55
+#define RC56 56
+#define RC57 57
+#define RC58 58
+#define RC59 59
+#define RC60 60
+#define RC61 61
+#define RC62 62
+#define RC63 63
+
+
+#define DIMM0 0x50
+#define DIMM1 0x51
+#define DIMM2 0x52
+#define DIMM3 0x53
+#define DIMM4 0x54
+#define DIMM5 0x55
+#define DIMM6 0x56
+#define DIMM7 0x57
+
+
+static const u8 spd_addr[] = {
+	//first node
+	RC00, DIMM0, DIMM2, 0, 0, DIMM1, DIMM3, 0, 0,
+#if CONFIG_MAX_PHYSICAL_CPUS > 1
+	//second node
+	RC00, DIMM4, DIMM6, 0, 0, DIMM5, DIMM7, 0, 0,
+#endif
+};
+



From patrick at georgi-clan.de  Mon Mar  1 12:01:03 2010
From: patrick at georgi-clan.de (Patrick Georgi)
Date: Mon, 01 Mar 2010 12:01:03 +0100
Subject: [coreboot] Patch to add MSI MS-9652 support to CoreBoot
In-Reply-To: <40891.192.168.1.101.1265935369.squirrel@vali.starlink.edu>
References: <47827.192.168.1.70.1265915511.squirrel@vali.starlink.edu>	<47941.192.168.1.70.1265915579.squirrel@vali.starlink.edu>
	<40891.192.168.1.101.1265935369.squirrel@vali.starlink.edu>
Message-ID: <4B8B9E6F.6000705@georgi-clan.de>

Am 12.02.2010 01:42, schrieb tpearson at raptorengineeringinc.com:
> Signed-off-by: Timothy Pearson <tpearson at raptorengineeringinc.com>
Committed in r5180, with changes to make it fit with recent changes in
the repository.

I'd be grateful if you could test the board with these changes and
report back (here, or IRC), so we know that this didn't break anything.

Thank you for sharing your work, it's much appreciated! (and for
listening to our complaints, newconfig/kconfig and all :-) )

Patrick



From patrick at georgi-clan.de  Mon Mar  1 12:47:57 2010
From: patrick at georgi-clan.de (Patrick Georgi)
Date: Mon, 01 Mar 2010 12:47:57 +0100
Subject: [coreboot] [patch] RE: Fam10 breakage
In-Reply-To: <DD1CC71B621B004FA76856E5129D6B17037D2E91@sbjgexmb1.amd.com>
References: <2831fecf1002241327v19493c8dq1891384716765a13@mail.gmail.com><2831fecf1002250711l1ec9d640p7ee35aeca02ffcf3@mail.gmail.com><DD1CC71B621B004FA76856E5129D6B17037D2948@sbjgexmb1.amd.com><4B87C4E8.8000600@georgi-clan.de><2831fecf1002260614g38565a2amcfde229241798755@mail.gmail.com><4B87DCBE.6080703@georgi-clan.de><2831fecf1002260735r57ca0895nb144a94e7385941@mail.gmail.com><4B882E0A.10304@georgi-clan.de><2831fecf1002261232p22880cd3g41c38f0119163187@mail.gmail.com><COL112-W22300097A8B5852F670940CD3D0@phx.gbl>	<2831fecf1002272040x4d45ded2k7f1b723cb0178e52@mail.gmail.com><DD1CC71B621B004FA76856E5129D6B17037D2DC4@sbjgexmb1.amd.com>
	<4B8B6F25.6070106@georgi-clan.de>
	<DD1CC71B621B004FA76856E5129D6B17037D2E91@sbjgexmb1.amd.com>
Message-ID: <4B8BA96D.3060505@georgi-clan.de>

Am 01.03.2010 09:00, schrieb Bao, Zheng:
> What I keep trying to make everyone understand is not what the rules we
> should use to decide the stack size. What I worry is the bug in the
> crosstool will make the rule do the wrong thing, even if the rule is
> perfect. So far, no one seems to support me that there is a bug in the
> toolchain. I admit it seems ridiculous But the it is quite clear.
I looked a bit into it. According to the binutils documentation,
expressions (which always lead to addresses) are either relative or
absolute. They're relative when inside some section, absolute otherwise.

But most importantly, ld does not know about boolean values!

What I could think of (and validate with some tests) is that ld really
messes up boolean operations within sections. I didn't find anything
conclusive yet, but it could be that boolean operations, even
intermediate values are "relative", and then evaluated to absolute
addresses - in which case both "true" and "false" are (very likely)
non-null values.
I'm also not sure if that's the intended behaviour by the binutils
developers, but it's probably fragile as the logical operations are also
used for address manipulations.
I guess for clarification this should be asked on the binutils mailing list.

Solution to that: Move operations on non-addresses and non-sizes out of
sections (which you did in your patch)

However, this does not fix the bug in our stack size calculation.
I'm not quite sure if the patch does the right thing, but it should be
close.

Signed-off-by: Patrick Georgi <patrick.georgi at coresystems.de>
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: 20100301-1-remove-special-stack-size
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20100301/db74b6a9/attachment.ksh>

From knuku at gap.upv.es  Mon Mar  1 14:30:53 2010
From: knuku at gap.upv.es (Knut Kujat)
Date: Mon, 01 Mar 2010 14:30:53 +0100
Subject: [coreboot] Supermicro H8QME-2+ mct_d fatal exit.
In-Reply-To: <20100226154934.5727.qmail@stuge.se>
References: <4B87CF9D.9060204@gap.upv.es>	<201002261506.46602.christian.leber@ziti.uni-heidelberg.de>	<4B87DEFE.3010604@gap.upv.es>
	<20100226154934.5727.qmail@stuge.se>
Message-ID: <4B8BC18D.1050400@gap.upv.es>

Peter Stuge escribi?:
> Knut Kujat wrote:
>   
>> I haven't tried swapping CPUs or RAM. But this errors appears on
>> memory initialization, right? So its most likely a ram issue?
>>     
>
> The memory controller is built-in to the CPU.
>
> Try swapping components around and see if the problem follows some
> particular parts.
>
>
> //Peter
>
>   
Hello,

switching memory from a working board to the failing board worked
"partially" because now it boots and even starts seabios but seabios
can't find the hard drive!! It's like there isn't one installed I
already switched HD with the working board and no result, of course
everything works fine with vendor bios.

That's odd!

thx,
Knut Kujat.



From peter at stuge.se  Mon Mar  1 14:39:23 2010
From: peter at stuge.se (Peter Stuge)
Date: Mon, 1 Mar 2010 14:39:23 +0100
Subject: [coreboot] biostar TA690G AM2 and TA770 A2+
In-Reply-To: <4B8B0238.5050300@sergio.spb.ru>
References: <4B8B0238.5050300@sergio.spb.ru>
Message-ID: <20100301133923.11989.qmail@stuge.se>

sergio wrote:
> model: TA690G AM2
..
> Have I chance to run coreboot on this mainboards?

The 690 board maybe. Make sure you can restore the board when the
first coreboot attempt does not work, and then go ahead and start
with a coreboot image for a board which has the same components.

Then fix what doesn't work.


//Peter



From knuku at gap.upv.es  Mon Mar  1 15:14:08 2010
From: knuku at gap.upv.es (Knut Kujat)
Date: Mon, 01 Mar 2010 15:14:08 +0100
Subject: [coreboot] Supermicro H8QME-2+ mct_d fatal exit.
In-Reply-To: <4B8BC18D.1050400@gap.upv.es>
References: <4B87CF9D.9060204@gap.upv.es>	<201002261506.46602.christian.leber@ziti.uni-heidelberg.de>	<4B87DEFE.3010604@gap.upv.es>	<20100226154934.5727.qmail@stuge.se>
	<4B8BC18D.1050400@gap.upv.es>
Message-ID: <4B8BCBB0.9000004@gap.upv.es>

Knut Kujat escribi?:
> Peter Stuge escribi?:
>   
>> Knut Kujat wrote:
>>   
>>     
>>> I haven't tried swapping CPUs or RAM. But this errors appears on
>>> memory initialization, right? So its most likely a ram issue?
>>>     
>>>       
>> The memory controller is built-in to the CPU.
>>
>> Try swapping components around and see if the problem follows some
>> particular parts.
>>
>>
>> //Peter
>>
>>   
>>     
> Hello,
>
> switching memory from a working board to the failing board worked
> "partially" because now it boots and even starts seabios but seabios
> can't find the hard drive!! It's like there isn't one installed I
> already switched HD with the working board and no result, of course
> everything works fine with vendor bios.
>
> That's odd!
>
> thx,
> Knut Kujat.
>
>   

I "solved" it. There are 3 sata cables connected to the board only 1
actually has a hard drive connected to it. Seems like this cable has to
be connected to sata 1 and before all others. Is this right? Can someone
confirm that pleas?

Bye and THX,
Knut Kujat.



From peter at stuge.se  Mon Mar  1 15:31:39 2010
From: peter at stuge.se (Peter Stuge)
Date: Mon, 1 Mar 2010 15:31:39 +0100
Subject: [coreboot] [commit] r5180 - in trunk/src/mainboard/msi:
	.	ms9652_fam10
In-Reply-To: <E1Nm3Iy-0006u2-Ab@ra.coresystems.de>
References: <E1Nm3Iy-0006u2-Ab@ra.coresystems.de>
Message-ID: <20100301143139.20702.qmail@stuge.se>

repository service wrote:
> Added:
>    trunk/src/mainboard/msi/ms9652_fam10/
>    trunk/src/mainboard/msi/ms9652_fam10/Kconfig
>    trunk/src/mainboard/msi/ms9652_fam10/acpi_tables.c
>    trunk/src/mainboard/msi/ms9652_fam10/chip.h
>    trunk/src/mainboard/msi/ms9652_fam10/cmos.layout
>    trunk/src/mainboard/msi/ms9652_fam10/devicetree.cb
>    trunk/src/mainboard/msi/ms9652_fam10/dsdt.asl
>    trunk/src/mainboard/msi/ms9652_fam10/get_bus_conf.c
>    trunk/src/mainboard/msi/ms9652_fam10/irq_tables.c
>    trunk/src/mainboard/msi/ms9652_fam10/mainboard.c
>    trunk/src/mainboard/msi/ms9652_fam10/mb_sysconf.h
>    trunk/src/mainboard/msi/ms9652_fam10/mptable.c
>    trunk/src/mainboard/msi/ms9652_fam10/resourcemap.c
>    trunk/src/mainboard/msi/ms9652_fam10/romstage.c
>    trunk/src/mainboard/msi/ms9652_fam10/spd_addr.h

Timothy, are any of these files plain copypaste from another
mainboard?


//Peter



From patrick at georgi-clan.de  Mon Mar  1 15:35:40 2010
From: patrick at georgi-clan.de (Patrick Georgi)
Date: Mon, 01 Mar 2010 15:35:40 +0100
Subject: [coreboot] [commit] r5180 - in
	trunk/src/mainboard/msi:	.	ms9652_fam10
In-Reply-To: <20100301143139.20702.qmail@stuge.se>
References: <E1Nm3Iy-0006u2-Ab@ra.coresystems.de>
	<20100301143139.20702.qmail@stuge.se>
Message-ID: <4B8BD0BC.5060203@georgi-clan.de>

Am 01.03.2010 15:31, schrieb Peter Stuge:
> Timothy, are any of these files plain copypaste from another
> mainboard?
>From comparing hashes (and the use of apc_auto.c on a Fam10 board), it
seems that it was derived from tyan/s2912_fam10.


Patrick



From peter at stuge.se  Mon Mar  1 15:51:44 2010
From: peter at stuge.se (Peter Stuge)
Date: Mon, 1 Mar 2010 15:51:44 +0100
Subject: [coreboot] [commit] r5180 - in trunk/src/mainboard/msi:
	.	ms9652_fam10
In-Reply-To: <4B8BD0BC.5060203@georgi-clan.de>
References: <E1Nm3Iy-0006u2-Ab@ra.coresystems.de>
	<20100301143139.20702.qmail@stuge.se>
	<4B8BD0BC.5060203@georgi-clan.de>
Message-ID: <20100301145144.24394.qmail@stuge.se>

Patrick Georgi wrote:
> > Timothy, are any of these files plain copypaste from another
> > mainboard?
> 
> From comparing hashes (and the use of apc_auto.c on a Fam10 board),
> it seems that it was derived from tyan/s2912_fam10.

I think Fam10 support will become more popular. It would be great if
somehow not so much code ended up being duplicated next time.


//Peter



From patrick at georgi-clan.de  Mon Mar  1 15:57:00 2010
From: patrick at georgi-clan.de (Patrick Georgi)
Date: Mon, 01 Mar 2010 15:57:00 +0100
Subject: [coreboot] [commit] r5180 - in
	trunk/src/mainboard/msi:	.	ms9652_fam10
In-Reply-To: <20100301145144.24394.qmail@stuge.se>
References: <E1Nm3Iy-0006u2-Ab@ra.coresystems.de>	<20100301143139.20702.qmail@stuge.se>	<4B8BD0BC.5060203@georgi-clan.de>
	<20100301145144.24394.qmail@stuge.se>
Message-ID: <4B8BD5BC.1010704@georgi-clan.de>

Am 01.03.2010 15:51, schrieb Peter Stuge:
>> From comparing hashes (and the use of apc_auto.c on a Fam10 board),
>> it seems that it was derived from tyan/s2912_fam10.
> 
> I think Fam10 support will become more popular. It would be great if
> somehow not so much code ended up being duplicated next time.
Ron had even more suggestions for improvement, but the patch was already
harder to apply because of my changes to the build system.

I'm all for unifying code, even across chipsets and vendors - and there
are many opportunities, but this was not the time.

It might be a good thing to compare tyan/s2912_fam10 (if that's indeed
the ancestor) and this board, to identify common parts that could be
factored out - we have a live example, with small divergence inbetween.

Everything we get done now will simplify the job for the next board, as
every feature not to maintain is an issue less for the developer to care
about.

Any takers?


Patrick



From stepan at coresystems.de  Mon Mar  1 17:00:52 2010
From: stepan at coresystems.de (Stefan Reinauer)
Date: Mon, 01 Mar 2010 17:00:52 +0100
Subject: [coreboot] [commit] r5180 -
	in	trunk/src/mainboard/msi:	.	ms9652_fam10
In-Reply-To: <4B8BD5BC.1010704@georgi-clan.de>
References: <E1Nm3Iy-0006u2-Ab@ra.coresystems.de>	<20100301143139.20702.qmail@stuge.se>	<4B8BD0BC.5060203@georgi-clan.de>	<20100301145144.24394.qmail@stuge.se>
	<4B8BD5BC.1010704@georgi-clan.de>
Message-ID: <4B8BE4B4.9080607@coresystems.de>

On 3/1/10 3:57 PM, Patrick Georgi wrote:
> It might be a good thing to compare tyan/s2912_fam10 (if that's indeed
> the ancestor) and this board, to identify common parts that could be
> factored out - we have a live example, with small divergence inbetween.
>
> Everything we get done now will simplify the job for the next board, as
> every feature not to maintain is an issue less for the developer to care
> about.
>   
> Any takers?
>   
A great unification would also be to stop having a different target for
FAM10 and non-FAM10 boards. This is more complicated for users than a
bit of duplicated code. (And it will bite us again for Fam10 + x, and
for Nehalem and co, basically for every chipset with a memory controller
in the CPU instead of on the board)

So how do we fix our device model, which still assumes a board has
exactly one choice of memory controller?

Stefan




From patrick at georgi-clan.de  Mon Mar  1 17:09:21 2010
From: patrick at georgi-clan.de (Patrick Georgi)
Date: Mon, 01 Mar 2010 17:09:21 +0100
Subject: [coreboot] [commit] r5180
	-	in	trunk/src/mainboard/msi:	.	ms9652_fam10
In-Reply-To: <4B8BE4B4.9080607@coresystems.de>
References: <E1Nm3Iy-0006u2-Ab@ra.coresystems.de>	<20100301143139.20702.qmail@stuge.se>	<4B8BD0BC.5060203@georgi-clan.de>	<20100301145144.24394.qmail@stuge.se>	<4B8BD5BC.1010704@georgi-clan.de>
	<4B8BE4B4.9080607@coresystems.de>
Message-ID: <4B8BE6B1.7030601@georgi-clan.de>

Am 01.03.2010 17:00, schrieb Stefan Reinauer:
> A great unification would also be to stop having a different target for
> FAM10 and non-FAM10 boards. This is more complicated for users than a
> bit of duplicated code. (And it will bite us again for Fam10 + x, and
> for Nehalem and co, basically for every chipset with a memory controller
> in the CPU instead of on the board)
> 
> So how do we fix our device model, which still assumes a board has
> exactly one choice of memory controller?
How about:
- Make memory controllers drivers
- Add detection function
- Allow several of them to be compiled in

The only thing required then is unified CAR, so we're able to get to the
point where multiple drivers could be considered - which exists for
K8/Fam10.

If we're going to do runtime linking anyway, we could load the drivers
from CBFS, instead of doing our current flavor of linker magic to get a
list of drivers in the ramstage (I better get into hiding for this, I guess)


Patrick



From mylesgw at gmail.com  Mon Mar  1 17:23:18 2010
From: mylesgw at gmail.com (Myles Watson)
Date: Mon, 1 Mar 2010 09:23:18 -0700
Subject: [coreboot] [patch] RE: Fam10 breakage
In-Reply-To: <4B8BA96D.3060505@georgi-clan.de>
References: <2831fecf1002241327v19493c8dq1891384716765a13@mail.gmail.com><2831fecf1002250711l1ec9d640p7ee35aeca02ffcf3@mail.gmail.com><DD1CC71B621B004FA76856E5129D6B17037D2948@sbjgexmb1.amd.com><4B87C4E8.8000600@georgi-clan.de><2831fecf1002260614g38565a2amcfde229241798755@mail.gmail.com><4B87DCBE.6080703@georgi-clan.de><2831fecf1002260735r57ca0895nb144a94e7385941@mail.gmail.com><4B882E0A.10304@georgi-clan.de><2831fecf1002261232p22880cd3g41c38f0119163187@mail.gmail.com><COL112-W22300097A8B5852F670940CD3D0@phx.gbl>	<2831fecf1002272040x4d45ded2k7f1b723cb0178e52@mail.gmail.com><DD1CC71B621B004FA76856E5129D6B17037D2DC4@sbjgexmb1.amd.com><4B8B6F25.6070106@georgi-clan.de><DD1CC71B621B004FA76856E5129D6B17037D2E91@sbjgexmb1.amd.com>
	<4B8BA96D.3060505@georgi-clan.de>
Message-ID: <83ADD2156D734BF8A5C3C874248759E4@chimp>

> Am 01.03.2010 09:00, schrieb Bao, Zheng:
> > What I keep trying to make everyone understand is not what the rules we
> > should use to decide the stack size. What I worry is the bug in the
> > crosstool will make the rule do the wrong thing, even if the rule is
> > perfect. So far, no one seems to support me that there is a bug in the
> > toolchain.
I don't think you should feel like it's a lack of support.  We just want to
fix it to make it simpler at the same time.
 
> Solution to that: Move operations on non-addresses and non-sizes out of
> sections (which you did in your patch)
> 
> However, this does not fix the bug in our stack size calculation.
> I'm not quite sure if the patch does the right thing, but it should be
> close.
I don't think we need to make the SMP check.  Can't we just put in an assert
that checks for RAMBASE < 0xa0000 and eheap > 0xa0000?  One large stack
could just as easily break this.

Thanks,
Myles




From uwe at hermann-uwe.de  Mon Mar  1 17:38:12 2010
From: uwe at hermann-uwe.de (Uwe Hermann)
Date: Mon, 1 Mar 2010 17:38:12 +0100
Subject: [coreboot] [commit] r5180 - in	trunk/src/mainboard/msi:
	.	ms9652_fam10
In-Reply-To: <4B8BE4B4.9080607@coresystems.de>
References: <E1Nm3Iy-0006u2-Ab@ra.coresystems.de>
	<20100301143139.20702.qmail@stuge.se>
	<4B8BD0BC.5060203@georgi-clan.de>
	<20100301145144.24394.qmail@stuge.se>
	<4B8BD5BC.1010704@georgi-clan.de> <4B8BE4B4.9080607@coresystems.de>
Message-ID: <20100301163812.GA13408@greenwood>

On Mon, Mar 01, 2010 at 05:00:52PM +0100, Stefan Reinauer wrote:
> On 3/1/10 3:57 PM, Patrick Georgi wrote:
> > It might be a good thing to compare tyan/s2912_fam10 (if that's indeed
> > the ancestor) and this board, to identify common parts that could be
> > factored out - we have a live example, with small divergence inbetween.
> >
> > Everything we get done now will simplify the job for the next board, as
> > every feature not to maintain is an issue less for the developer to care
> > about.
> >   
> > Any takers?
> >   
> A great unification would also be to stop having a different target for
> FAM10 and non-FAM10 boards.

+1

This is definately a good thing!


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



From forevertheuni at gmail.com  Mon Mar  1 16:09:49 2010
From: forevertheuni at gmail.com (Joao Mamede)
Date: Mon, 01 Mar 2010 16:09:49 +0100
Subject: [coreboot] Re  unsuported Motherboard
Message-ID: <4B8BD8BD.2020001@gmail.com>

On 1/4/10 12:17 PM, Joao Mamede wrote:
>/ Hello I want to use coreboot in an old laptop (in order to
/>/ replace/upgrade a fried graphics card).
/>/ Both the southern and northernbridges are suported
/>/ The laptop is the A8js from asus.
/>/
/>/ Here's an lspci
/>/ 00:00.0 Host bridge: Intel Corporation Mobile 945GM/PM/GMS/940GML and
/>/ 945GT Express Memory Controller Hub (rev 03)
/>/ 00:1f.0 ISA bridge: Intel Corporation 82801GBM (ICH7-M) LPC Interface
/>/ Bridge (rev 02) 
/
>/
/>/ I can't find a socketed bios in the motherboard...so I guess I have
/>/ one try.
/>/ Can anyone help me out in making a target build(I wouldn't bother you
/>/ and try to do it myself if I had more than one chance).
/>/ It's either make it work and make me happy, or put the laptop in the
/>/ garbage..independently of frying the bios or not.
/>/ Thank you
/
Chances are good to get coreboot running on this laptop, its components
seem to be mostly supported by coreboot. However, the chance of getting
everything working on the first try are zero. The chances to get the
system at least to boot on the first try and always keep the system in a
working, updatable state are almost zero, too. So if you attempt to port
coreboot to this machine, you will need to create some kind of recovery
mechanism. You could solder a socket to the mainboard, or a plug to
reflash the machine externally.

However, to get started, I suggest that you find out what flash chip you
have on the board, so you can determine what recovery mechanism is
suitable. (The flashrom utility from www.flashrom.org will help you with
that)

Also, a dump of superiotool -ed will help you a lot. Does the machine
have a serial port?

Stefan


The machine has no serial port. I think it's a socketed bios(from the pics of the disassembly tech manual). However I have to disassemble everything in order to acess the BIOS
Is there a way to plug a chip that has a wire coming to the outside to a machine that contains or  the BIOS chip or and emulation of one?
I'll do all the dumps, etc and post here again.






From patrick at georgi-clan.de  Mon Mar  1 17:48:04 2010
From: patrick at georgi-clan.de (Patrick Georgi)
Date: Mon, 01 Mar 2010 17:48:04 +0100
Subject: [coreboot] [patch] RE: Fam10 breakage
In-Reply-To: <83ADD2156D734BF8A5C3C874248759E4@chimp>
References: <2831fecf1002241327v19493c8dq1891384716765a13@mail.gmail.com><2831fecf1002250711l1ec9d640p7ee35aeca02ffcf3@mail.gmail.com><DD1CC71B621B004FA76856E5129D6B17037D2948@sbjgexmb1.amd.com><4B87C4E8.8000600@georgi-clan.de><2831fecf1002260614g38565a2amcfde229241798755@mail.gmail.com><4B87DCBE.6080703@georgi-clan.de><2831fecf1002260735r57ca0895nb144a94e7385941@mail.gmail.com><4B882E0A.10304@georgi-clan.de><2831fecf1002261232p22880cd3g41c38f0119163187@mail.gmail.com><COL112-W22300097A8B5852F670940CD3D0@phx.gbl>	<2831fecf1002272040x4d45ded2k7f1b723cb0178e52@mail.gmail.com><DD1CC71B621B004FA76856E5129D6B17037D2DC4@sbjgexmb1.amd.com><4B8B6F25.6070106@georgi-clan.de><DD1CC71B621B004FA76856E5129D6B17037D2E91@sbjgexmb1.amd.com>
	<4B8BA96D.3060505@georgi-clan.de>
	<83ADD2156D734BF8A5C3C874248759E4@chimp>
Message-ID: <4B8BEFC4.1060802@georgi-clan.de>

Am 01.03.2010 17:23, schrieb Myles Watson:
>> However, this does not fix the bug in our stack size calculation.
>> I'm not quite sure if the patch does the right thing, but it should be
>> close.
> I don't think we need to make the SMP check.  Can't we just put in an assert
> that checks for RAMBASE < 0xa0000 and eheap > 0xa0000?  One large stack
> could just as easily break this.
True. Attached patch might do this (only moderately tested)

I think the only reason why we can't get rid of RAMBASE <1M completely
is a couple of boards (Via based iirc) that have their own vgabios.c
that breaks with RAMBASE >1M

The other RAMBASE we sometimes use (mostly on AMD boards) is RAMBASE==2M
- what was the rationale for that again?

With those two gone, we could hide RAMBASE somewhere in Kconfig or
eliminate it completely.


Patrick
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: 20100301-2-remove-special-stack-size-retry
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20100301/01c8ae97/attachment.ksh>

From svn at coreboot.org  Mon Mar  1 18:16:06 2010
From: svn at coreboot.org (repository service)
Date: Mon, 01 Mar 2010 18:16:06 +0100
Subject: [coreboot] [commit] r5181 - in trunk/src: arch/i386 cpu/x86/lapic
	mainboard/technexion/tim5690
Message-ID: <E1Nm9Dy-0007DB-TG@ra.coresystems.de>

Author: oxygene
Date: Mon Mar  1 18:16:06 2010
New Revision: 5181
URL: http://tracker.coreboot.org/trac/coreboot/changeset/5181

Log:
- Simplify stack size determination: MAX_CPUS * STACK_SIZE
- Check that this doesn't run into vga/oprom/bios area at link time
- Avoid overly complicated and not well understood hack which avoids that
  area by leaving a hole in the stack area.
- Adapt technexion/tim5690 to put ramstage at 1MB

Signed-off-by: Patrick Georgi <patrick.georgi at coresystems.de>
Acked-by: Myles Watson <mylesgw at gmail.com>

Modified:
   trunk/src/arch/i386/coreboot_ram.ld
   trunk/src/cpu/x86/lapic/lapic_cpu_init.c
   trunk/src/mainboard/technexion/tim5690/Kconfig

Modified: trunk/src/arch/i386/coreboot_ram.ld
==============================================================================
--- trunk/src/arch/i386/coreboot_ram.ld	Mon Mar  1 11:56:51 2010	(r5180)
+++ trunk/src/arch/i386/coreboot_ram.ld	Mon Mar  1 18:16:06 2010	(r5181)
@@ -100,11 +100,11 @@
 	_ebss = .;
 	_end = .;
 	. = ALIGN(CONFIG_STACK_SIZE);
+
 	_stack = .;
 	.stack . : {
 		/* Reserve a stack for each possible cpu */
-		/* the stack for ap will be put after pgtbl in 1M to CONFIG_RAMTOP range when VGA and ROM_RUN and CONFIG_RAMTOP>1M*/
-		. += ((CONFIG_CONSOLE_VGA || CONFIG_PCI_ROM_RUN)&&(CONFIG_RAMBASE<0x100000)&&(CONFIG_RAMTOP>0x100000) ) ? CONFIG_STACK_SIZE : (CONFIG_MAX_CPUS*CONFIG_STACK_SIZE);
+		. += CONFIG_MAX_CPUS*CONFIG_STACK_SIZE;
 	}
 	_estack = .;
         _heap = .;
@@ -114,6 +114,10 @@
                 . = ALIGN(4);
         }
         _eheap = .;
+
+	/* Avoid running into 0xa0000-0xfffff */
+	_bogus = ASSERT(CONFIG_RAMBASE >= 0x100000 || _eheap < 0xa0000, "Please move RAMBASE to 1MB");
+
 	/* The ram segment
  	 * This is all address of the memory resident copy of coreboot.
 	 */

Modified: trunk/src/cpu/x86/lapic/lapic_cpu_init.c
==============================================================================
--- trunk/src/cpu/x86/lapic/lapic_cpu_init.c	Mon Mar  1 11:56:51 2010	(r5180)
+++ trunk/src/cpu/x86/lapic/lapic_cpu_init.c	Mon Mar  1 18:16:06 2010	(r5181)
@@ -246,25 +246,7 @@
 	index = ++last_cpu_index;
 
 	/* Find end of the new processors stack */
-#if (CONFIG_RAMTOP>0x100000) && (CONFIG_RAMBASE < 0x100000) && ((CONFIG_CONSOLE_VGA==1) || (CONFIG_PCI_ROM_RUN == 1))
-	if(index<1) { // only keep bsp on low
-		stack_end = ((unsigned long)_estack) - (CONFIG_STACK_SIZE*index) - sizeof(struct cpu_info);
-	} else {
-		// for all APs, let use stack after pgtbl, 20480 is the pgtbl size for every cpu
-		stack_end = 0x100000+(20480 + CONFIG_STACK_SIZE)*CONFIG_MAX_CPUS - (CONFIG_STACK_SIZE*index);
-#if (0x100000+(20480 + CONFIG_STACK_SIZE)*CONFIG_MAX_CPUS) > (CONFIG_RAMTOP)
-		#warning "We may need to increase CONFIG_RAMTOP, it need to be more than (0x100000+(20480 + CONFIG_STACK_SIZE)*CONFIG_MAX_CPUS)\n"
-#endif
-		if(stack_end > (CONFIG_RAMTOP)) {
-			printk_debug("start_cpu: Please increase the CONFIG_RAMTOP more than %luK\n", stack_end);
-			die("Can not go on\n");
-		}
-		stack_end -= sizeof(struct cpu_info);
-	}
-#else
 	stack_end = ((unsigned long)_estack) - (CONFIG_STACK_SIZE*index) - sizeof(struct cpu_info);
-#endif
-
 
 	/* Record the index and which cpu structure we are using */
 	info = (struct cpu_info *)stack_end;

Modified: trunk/src/mainboard/technexion/tim5690/Kconfig
==============================================================================
--- trunk/src/mainboard/technexion/tim5690/Kconfig	Mon Mar  1 11:56:51 2010	(r5180)
+++ trunk/src/mainboard/technexion/tim5690/Kconfig	Mon Mar  1 18:16:06 2010	(r5181)
@@ -127,5 +127,5 @@
 
 config RAMBASE
 	hex
-	default 0x4000
+	default 0x100000
 	depends on BOARD_TECHNEXION_TIM5690



From patrick at georgi-clan.de  Mon Mar  1 18:17:37 2010
From: patrick at georgi-clan.de (Patrick Georgi)
Date: Mon, 01 Mar 2010 18:17:37 +0100
Subject: [coreboot] [patch] RE: Fam10 breakage
In-Reply-To: <DFB6A79EF37548D0BA5D6297EFAB4A30@chimp>
References: <2831fecf1002241327v19493c8dq1891384716765a13@mail.gmail.com><2831fecf1002250711l1ec9d640p7ee35aeca02ffcf3@mail.gmail.com><DD1CC71B621B004FA76856E5129D6B17037D2948@sbjgexmb1.amd.com><4B87C4E8.8000600@georgi-clan.de><2831fecf1002260614g38565a2amcfde229241798755@mail.gmail.com><4B87DCBE.6080703@georgi-clan.de><2831fecf1002260735r57ca0895nb144a94e7385941@mail.gmail.com><4B882E0A.10304@georgi-clan.de><2831fecf1002261232p22880cd3g41c38f0119163187@mail.gmail.com><COL112-W22300097A8B5852F670940CD3D0@phx.gbl>	<2831fecf1002272040x4d45ded2k7f1b723cb0178e52@mail.gmail.com><DD1CC71B621B004FA76856E5129D6B17037D2DC4@sbjgexmb1.amd.com><4B8B6F25.6070106@georgi-clan.de><DD1CC71B621B004FA76856E5129D6B17037D2E91@sbjgexmb1.amd.com>
	<4B8BA96D.3060505@georgi-clan.de>
	<83ADD2156D734BF8A5C3C874248759E4@chimp>
	<4B8BEFC4.1060802@georgi-clan.de>
	<DFB6A79EF37548D0BA5D6297EFAB4A30@chimp>
Message-ID: <4B8BF6B1.10901@georgi-clan.de>

Am 01.03.2010 17:54, schrieb Myles Watson:
>>> that checks for RAMBASE < 0xa0000 and eheap > 0xa0000?  One large stack
>>> could just as easily break this.
>> True. Attached patch might do this (only moderately tested)
> Acked-by: Myles Watson <mylesgw at gmail.com>
Thanks, r5181

>> With those two gone, we could hide RAMBASE somewhere in Kconfig or
>> eliminate it completely.
> Wasn't there a board with RAMBASE at 32 M too?
Might be Rudolf's, to help with suspend/resume.


Patrick



From svn at coreboot.org  Mon Mar  1 18:19:56 2010
From: svn at coreboot.org (repository service)
Date: Mon, 01 Mar 2010 18:19:56 +0100
Subject: [coreboot] [commit] r5182 - in trunk/src: . include
	mainboard/kontron/986lcd-m mainboard/kontron/986lcd-m/acpi
	mainboard/msi/ms9652_fam10
Message-ID: <E1Nm9Hg-0005tL-Hr@ra.coresystems.de>

Author: uwe
Date: Mon Mar  1 18:19:55 2010
New Revision: 5182
URL: http://tracker.coreboot.org/trac/coreboot/changeset/5182

Log:
Various cometic and coding-style fixes (trivial).

 - Fix whitespace, alignment, and indentation in a few places.

 - Some more consistency fixes in license headers.

 - Fix incomplete license header: src/mainboard/msi/ms9652_fam10/devicetree.cb.

 - Fix typo for LIMIT_HT_SPEED_1800: s/1.6GHz/1.8GHz/.

 - Fix typo in src/mainboard/msi/ms9652_fam10/Kconfig: s/MS-9256/MS-9252/.

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

Modified:
   trunk/src/Kconfig
   trunk/src/include/assert.h
   trunk/src/mainboard/kontron/986lcd-m/acpi/ec.asl
   trunk/src/mainboard/kontron/986lcd-m/acpi/i945_pci_irqs.asl
   trunk/src/mainboard/kontron/986lcd-m/acpi/ich7_pci_irqs.asl
   trunk/src/mainboard/kontron/986lcd-m/acpi/platform.asl
   trunk/src/mainboard/kontron/986lcd-m/acpi/superio.asl
   trunk/src/mainboard/kontron/986lcd-m/acpi/thermal.asl
   trunk/src/mainboard/kontron/986lcd-m/acpi/video.asl
   trunk/src/mainboard/kontron/986lcd-m/acpi_tables.c
   trunk/src/mainboard/kontron/986lcd-m/cmos.layout
   trunk/src/mainboard/kontron/986lcd-m/dsdt.asl
   trunk/src/mainboard/kontron/986lcd-m/fadt.c
   trunk/src/mainboard/kontron/986lcd-m/irq_tables.c
   trunk/src/mainboard/kontron/986lcd-m/mainboard.c
   trunk/src/mainboard/kontron/986lcd-m/mainboard_smi.c
   trunk/src/mainboard/kontron/986lcd-m/mptable.c
   trunk/src/mainboard/kontron/986lcd-m/romstage.c
   trunk/src/mainboard/msi/ms9652_fam10/Kconfig
   trunk/src/mainboard/msi/ms9652_fam10/acpi_tables.c
   trunk/src/mainboard/msi/ms9652_fam10/devicetree.cb
   trunk/src/mainboard/msi/ms9652_fam10/dsdt.asl

Modified: trunk/src/Kconfig
==============================================================================
--- trunk/src/Kconfig	Mon Mar  1 18:16:06 2010	(r5181)
+++ trunk/src/Kconfig	Mon Mar  1 18:19:55 2010	(r5182)
@@ -57,16 +57,22 @@
 source src/cpu/Kconfig
 comment "Northbridge"
 
-menu "HyperTransport Setup"
+menu "HyperTransport setup"
 	depends on (NORTHBRIDGE_AMD_AMDK8 || NORTHBRIDGE_AMD_AMDFAM10) && EXPERT
 
 choice
-	prompt "HyperTransport Frequency"
+	prompt "HyperTransport frequency"
 	default LIMIT_HT_SPEED_AUTO
 	help
-	  This option sets the maximum permissible HyperTransport link frequency.
-	  Use of this option will only limit the autodetected HT frequency; it will not (and cannot) increase the frequency beyond the autodetected limits.
-	  This is primarily used to work around poorly designed or laid out HT traces on certain motherboards.
+	  This option sets the maximum permissible HyperTransport link
+	  frequency.
+
+	  Use of this option will only limit the autodetected HT frequency.
+	  It will not (and cannot) increase the frequency beyond the
+	  autodetected limits.
+
+	  This is primarily used to work around poorly designed or laid out
+	  HT traces on certain motherboards.
 
 config LIMIT_HT_SPEED_200
 	bool "Limit HT frequency to 200MHz"
@@ -85,26 +91,32 @@
 config LIMIT_HT_SPEED_1600
 	bool "Limit HT frequency to 1.6GHz"
 config LIMIT_HT_SPEED_1800
-        bool "Limit HT frequency to 1.6GHz"
+	bool "Limit HT frequency to 1.8GHz"
 config LIMIT_HT_SPEED_2000
-        bool "Limit HT frequency to 2.0GHz"
+	bool "Limit HT frequency to 2.0GHz"
 config LIMIT_HT_SPEED_2200
-        bool "Limit HT frequency to 2.2GHz"
+	bool "Limit HT frequency to 2.2GHz"
 config LIMIT_HT_SPEED_2400
-        bool "Limit HT frequency to 2.4GHz"
+	bool "Limit HT frequency to 2.4GHz"
 config LIMIT_HT_SPEED_2600
-        bool "Limit HT frequency to 2.6GHz"
+	bool "Limit HT frequency to 2.6GHz"
 config LIMIT_HT_SPEED_AUTO
 	bool "Autodetect HT frequency"
 endchoice
 
 choice
-	prompt "HyperTransport Downlink Width"
+	prompt "HyperTransport downlink width"
 	default LIMIT_HT_DOWN_WIDTH_16
 	help
-	  This option sets the maximum permissible HyperTransport link width.
-	  Use of this option will only limit the autodetected HT width; it will not (and cannot) increase the width beyond the autodetected limits.
-	  This is primarily used to work around poorly designed or laid out HT traces on certain motherboards.
+	  This option sets the maximum permissible HyperTransport
+	  downlink width.
+
+	  Use of this option will only limit the autodetected HT width.
+	  It will not (and cannot) increase the width beyond the autodetected
+	  limits.
+
+	  This is primarily used to work around poorly designed or laid out HT
+	  traces on certain motherboards.
 
 config LIMIT_HT_DOWN_WIDTH_8
 	bool "8 bits"
@@ -113,12 +125,18 @@
 endchoice
 
 choice
-	prompt "HyperTransport Uplink Width"
+	prompt "HyperTransport uplink width"
 	default LIMIT_HT_UP_WIDTH_16
 	help
-	  This option sets the maximum permissible HyperTransport link width.
-	  Use of this option will only limit the autodetected HT width; it will not (and cannot) increase the width beyond the autodetected limits.
-	  This is primarily used to work around poorly designed or laid out HT traces on certain motherboards.
+	  This option sets the maximum permissible HyperTransport
+	  uplink width.
+
+	  Use of this option will only limit the autodetected HT width.
+	  It will not (and cannot) increase the width beyond the autodetected
+	  limits.
+
+	  This is primarily used to work around poorly designed or laid out HT
+	  traces on certain motherboards.
 
 config LIMIT_HT_UP_WIDTH_8
 	bool "8 bits"

Modified: trunk/src/include/assert.h
==============================================================================
--- trunk/src/include/assert.h	Mon Mar  1 18:16:06 2010	(r5181)
+++ trunk/src/include/assert.h	Mon Mar  1 18:19:55 2010	(r5182)
@@ -1,12 +1,11 @@
 /*
  * This file is part of the coreboot project.
- * 
+ *
  * 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; version 2 of
- * the License.
+ * published by the Free Software Foundation; version 2 of the License.
  *
  * This program is distributed in the hope that it will be useful,
  * but WITHOUT ANY WARRANTY; without even the implied warranty of
@@ -15,8 +14,7 @@
  *
  * 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
+ * Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA
  */
 
 #ifndef __ASSERT_H__
@@ -62,5 +60,5 @@
 }
 
 #endif
-					
-#endif 	// __ASSERT_H__
+
+#endif // __ASSERT_H__

Modified: trunk/src/mainboard/kontron/986lcd-m/acpi/ec.asl
==============================================================================
--- trunk/src/mainboard/kontron/986lcd-m/acpi/ec.asl	Mon Mar  1 18:16:06 2010	(r5181)
+++ trunk/src/mainboard/kontron/986lcd-m/acpi/ec.asl	Mon Mar  1 18:19:55 2010	(r5182)
@@ -3,10 +3,9 @@
  *
  * Copyright (C) 2007-2009 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; version 2 of
- * the License.
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; version 2 of the License.
  *
  * This program is distributed in the hope that it will be useful,
  * but WITHOUT ANY WARRANTY; without even the implied warranty of
@@ -15,8 +14,7 @@
  *
  * 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
+ * Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA
  */
 
 Device(EC0)

Modified: trunk/src/mainboard/kontron/986lcd-m/acpi/i945_pci_irqs.asl
==============================================================================
--- trunk/src/mainboard/kontron/986lcd-m/acpi/i945_pci_irqs.asl	Mon Mar  1 18:16:06 2010	(r5181)
+++ trunk/src/mainboard/kontron/986lcd-m/acpi/i945_pci_irqs.asl	Mon Mar  1 18:19:55 2010	(r5182)
@@ -3,10 +3,9 @@
  *
  * Copyright (C) 2007-2009 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; version 2 of
- * the License.
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; version 2 of the License.
  *
  * This program is distributed in the hope that it will be useful,
  * but WITHOUT ANY WARRANTY; without even the implied warranty of
@@ -15,8 +14,7 @@
  *
  * 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
+ * Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA
  */
 
 /* This is board specific information: IRQ routing for the 

Modified: trunk/src/mainboard/kontron/986lcd-m/acpi/ich7_pci_irqs.asl
==============================================================================
--- trunk/src/mainboard/kontron/986lcd-m/acpi/ich7_pci_irqs.asl	Mon Mar  1 18:16:06 2010	(r5181)
+++ trunk/src/mainboard/kontron/986lcd-m/acpi/ich7_pci_irqs.asl	Mon Mar  1 18:19:55 2010	(r5182)
@@ -3,10 +3,9 @@
  *
  * Copyright (C) 2007-2009 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; version 2 of
- * the License.
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; version 2 of the License.
  *
  * This program is distributed in the hope that it will be useful,
  * but WITHOUT ANY WARRANTY; without even the implied warranty of
@@ -15,8 +14,7 @@
  *
  * 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
+ * Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA
  */
 
 /* This is board specific information: IRQ routing for the 

Modified: trunk/src/mainboard/kontron/986lcd-m/acpi/platform.asl
==============================================================================
--- trunk/src/mainboard/kontron/986lcd-m/acpi/platform.asl	Mon Mar  1 18:16:06 2010	(r5181)
+++ trunk/src/mainboard/kontron/986lcd-m/acpi/platform.asl	Mon Mar  1 18:19:55 2010	(r5182)
@@ -3,10 +3,9 @@
  *
  * Copyright (C) 2007-2009 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; version 2 of
- * the License.
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; version 2 of the License.
  *
  * This program is distributed in the hope that it will be useful,
  * but WITHOUT ANY WARRANTY; without even the implied warranty of
@@ -15,8 +14,7 @@
  *
  * 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
+ * Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA
  */
 
 /* The APM port can be used for generating software SMIs */

Modified: trunk/src/mainboard/kontron/986lcd-m/acpi/superio.asl
==============================================================================
--- trunk/src/mainboard/kontron/986lcd-m/acpi/superio.asl	Mon Mar  1 18:16:06 2010	(r5181)
+++ trunk/src/mainboard/kontron/986lcd-m/acpi/superio.asl	Mon Mar  1 18:19:55 2010	(r5182)
@@ -3,10 +3,9 @@
  *
  * Copyright (C) 2007-2009 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; version 2 of
- * the License.
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; version 2 of the License.
  *
  * This program is distributed in the hope that it will be useful,
  * but WITHOUT ANY WARRANTY; without even the implied warranty of
@@ -15,8 +14,7 @@
  *
  * 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
+ * Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA
  */
 
 

Modified: trunk/src/mainboard/kontron/986lcd-m/acpi/thermal.asl
==============================================================================
--- trunk/src/mainboard/kontron/986lcd-m/acpi/thermal.asl	Mon Mar  1 18:16:06 2010	(r5181)
+++ trunk/src/mainboard/kontron/986lcd-m/acpi/thermal.asl	Mon Mar  1 18:19:55 2010	(r5182)
@@ -3,10 +3,9 @@
  *
  * Copyright (C) 2007-2009 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; version 2 of
- * the License.
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; version 2 of the License.
  *
  * This program is distributed in the hope that it will be useful,
  * but WITHOUT ANY WARRANTY; without even the implied warranty of
@@ -15,8 +14,7 @@
  *
  * 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
+ * Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA
  */
 
 // Thermal Zone

Modified: trunk/src/mainboard/kontron/986lcd-m/acpi/video.asl
==============================================================================
--- trunk/src/mainboard/kontron/986lcd-m/acpi/video.asl	Mon Mar  1 18:16:06 2010	(r5181)
+++ trunk/src/mainboard/kontron/986lcd-m/acpi/video.asl	Mon Mar  1 18:19:55 2010	(r5182)
@@ -3,10 +3,9 @@
  *
  * Copyright (C) 2007-2009 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; version 2 of
- * the License.
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; version 2 of the License.
  *
  * This program is distributed in the hope that it will be useful,
  * but WITHOUT ANY WARRANTY; without even the implied warranty of
@@ -15,8 +14,7 @@
  *
  * 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
+ * Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA
  */
 
 // Brightness write

Modified: trunk/src/mainboard/kontron/986lcd-m/acpi_tables.c
==============================================================================
--- trunk/src/mainboard/kontron/986lcd-m/acpi_tables.c	Mon Mar  1 18:16:06 2010	(r5181)
+++ trunk/src/mainboard/kontron/986lcd-m/acpi_tables.c	Mon Mar  1 18:19:55 2010	(r5182)
@@ -3,10 +3,9 @@
  * 
  * Copyright (C) 2007-2009 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; version 2 of
- * the License.
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; version 2 of the License.
  *
  * This program is distributed in the hope that it will be useful,
  * but WITHOUT ANY WARRANTY; without even the implied warranty of
@@ -15,8 +14,7 @@
  *
  * 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
+ * Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA
  */
 
 #include <types.h>

Modified: trunk/src/mainboard/kontron/986lcd-m/cmos.layout
==============================================================================
--- trunk/src/mainboard/kontron/986lcd-m/cmos.layout	Mon Mar  1 18:16:06 2010	(r5181)
+++ trunk/src/mainboard/kontron/986lcd-m/cmos.layout	Mon Mar  1 18:19:55 2010	(r5182)
@@ -1,23 +1,21 @@
-#
-# This file is part of the coreboot project.
-# 
-# Copyright (C) 2007-2008 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; version 2 of
-# the License.
-#
-# This program is distributed in the hope that it will be useful,
-# but WITHOUT ANY WARRANTY; without even the implied warranty of
-# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
-# GNU General Public License for more details.
-#
-# You should have received a copy of the GNU General Public License
-# along with this program; if not, write to the Free Software
-# Foundation, Inc., 51 Franklin St, Fifth Floor, Boston,
-# MA 02110-1301 USA
-#
+##
+## This file is part of the coreboot project.
+##
+## Copyright (C) 2007-2008 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; version 2 of the License.
+##
+## This program is distributed in the hope that it will be useful,
+## but WITHOUT ANY WARRANTY; without even the implied warranty of
+## MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+## GNU General Public License for more details.
+##
+## You should have received a copy of the GNU General Public License
+## along with this program; if not, write to the Free Software
+## Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA
+##
 
 # -----------------------------------------------------------------
 entries

Modified: trunk/src/mainboard/kontron/986lcd-m/dsdt.asl
==============================================================================
--- trunk/src/mainboard/kontron/986lcd-m/dsdt.asl	Mon Mar  1 18:16:06 2010	(r5181)
+++ trunk/src/mainboard/kontron/986lcd-m/dsdt.asl	Mon Mar  1 18:19:55 2010	(r5182)
@@ -3,10 +3,9 @@
  *
  * Copyright (C) 2007-2009 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; version 2 of
- * the License.
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; version 2 of the License.
  *
  * This program is distributed in the hope that it will be useful,
  * but WITHOUT ANY WARRANTY; without even the implied warranty of
@@ -15,8 +14,7 @@
  *
  * 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
+ * Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA
  */
 
 DefinitionBlock(

Modified: trunk/src/mainboard/kontron/986lcd-m/fadt.c
==============================================================================
--- trunk/src/mainboard/kontron/986lcd-m/fadt.c	Mon Mar  1 18:16:06 2010	(r5181)
+++ trunk/src/mainboard/kontron/986lcd-m/fadt.c	Mon Mar  1 18:19:55 2010	(r5182)
@@ -3,10 +3,9 @@
  *
  * Copyright (C) 2007-2009 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; version 2 of
- * the License.
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; version 2 of the License.
  *
  * This program is distributed in the hope that it will be useful,
  * but WITHOUT ANY WARRANTY; without even the implied warranty of
@@ -15,8 +14,7 @@
  *
  * 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
+ * Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA
  */
 
 #include <string.h>

Modified: trunk/src/mainboard/kontron/986lcd-m/irq_tables.c
==============================================================================
--- trunk/src/mainboard/kontron/986lcd-m/irq_tables.c	Mon Mar  1 18:16:06 2010	(r5181)
+++ trunk/src/mainboard/kontron/986lcd-m/irq_tables.c	Mon Mar  1 18:19:55 2010	(r5182)
@@ -3,10 +3,9 @@
  *
  * Copyright (C) 2007-2008 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; version 2 of
- * the License.
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; version 2 of the License.
  *
  * This program is distributed in the hope that it will be useful,
  * but WITHOUT ANY WARRANTY; without even the implied warranty of
@@ -15,8 +14,7 @@
  *
  * 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
+ * Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA
  */
 
 #include <arch/pirq_routing.h>

Modified: trunk/src/mainboard/kontron/986lcd-m/mainboard.c
==============================================================================
--- trunk/src/mainboard/kontron/986lcd-m/mainboard.c	Mon Mar  1 18:16:06 2010	(r5181)
+++ trunk/src/mainboard/kontron/986lcd-m/mainboard.c	Mon Mar  1 18:19:55 2010	(r5182)
@@ -3,10 +3,9 @@
  *
  * Copyright (C) 2007-2009 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; version 2 of
- * the License.
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; version 2 of the License.
  *
  * This program is distributed in the hope that it will be useful,
  * but WITHOUT ANY WARRANTY; without even the implied warranty of
@@ -15,8 +14,7 @@
  *
  * 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
+ * Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA
  */
 
 #include <types.h>

Modified: trunk/src/mainboard/kontron/986lcd-m/mainboard_smi.c
==============================================================================
--- trunk/src/mainboard/kontron/986lcd-m/mainboard_smi.c	Mon Mar  1 18:16:06 2010	(r5181)
+++ trunk/src/mainboard/kontron/986lcd-m/mainboard_smi.c	Mon Mar  1 18:19:55 2010	(r5182)
@@ -3,10 +3,9 @@
  *
  * Copyright (C) 2008-2009 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; version 2 of
- * the License.
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; version 2 of the License.
  *
  * This program is distributed in the hope that it will be useful,
  * but WITHOUT ANY WARRANTY; without even the implied warranty of
@@ -15,8 +14,7 @@
  *
  * 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
+ * Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA
  */
 
 #include <arch/io.h>

Modified: trunk/src/mainboard/kontron/986lcd-m/mptable.c
==============================================================================
--- trunk/src/mainboard/kontron/986lcd-m/mptable.c	Mon Mar  1 18:16:06 2010	(r5181)
+++ trunk/src/mainboard/kontron/986lcd-m/mptable.c	Mon Mar  1 18:19:55 2010	(r5182)
@@ -3,10 +3,9 @@
  *
  * Copyright (C) 2007-2008 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; version 2 of
- * the License.
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; version 2 of the License.
  *
  * This program is distributed in the hope that it will be useful,
  * but WITHOUT ANY WARRANTY; without even the implied warranty of
@@ -15,8 +14,7 @@
  *
  * 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
+ * Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA
  */
 
 

Modified: trunk/src/mainboard/kontron/986lcd-m/romstage.c
==============================================================================
--- trunk/src/mainboard/kontron/986lcd-m/romstage.c	Mon Mar  1 18:16:06 2010	(r5181)
+++ trunk/src/mainboard/kontron/986lcd-m/romstage.c	Mon Mar  1 18:19:55 2010	(r5182)
@@ -3,10 +3,9 @@
  * 
  * Copyright (C) 2007-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; version 2 of
- * the License.
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; version 2 of the License.
  *
  * This program is distributed in the hope that it will be useful,
  * but WITHOUT ANY WARRANTY; without even the implied warranty of
@@ -15,8 +14,7 @@
  *
  * 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
+ * Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA
  */
 
 // __PRE_RAM__ means: use "unsigned" for device, not a struct.

Modified: trunk/src/mainboard/msi/ms9652_fam10/Kconfig
==============================================================================
--- trunk/src/mainboard/msi/ms9652_fam10/Kconfig	Mon Mar  1 18:16:06 2010	(r5181)
+++ trunk/src/mainboard/msi/ms9652_fam10/Kconfig	Mon Mar  1 18:19:55 2010	(r5182)
@@ -1,5 +1,5 @@
 config BOARD_MSI_MS9652_FAM10
-	bool "MS9652 Fam10 (Speedster K9ND)"
+	bool "MS-9652 Fam10 (Speedster K9ND)"
 	select ARCH_X86
 	select CPU_AMD_SOCKET_F_1207
 	select NORTHBRIDGE_AMD_AMDFAM10
@@ -134,7 +134,7 @@
 
 config MAINBOARD_PART_NUMBER
 	string
-	default "MS-9256"
+	default "MS-9252"
 	depends on BOARD_MSI_MS9652_FAM10
 
 config MAINBOARD_PCI_SUBSYSTEM_VENDOR_ID

Modified: trunk/src/mainboard/msi/ms9652_fam10/acpi_tables.c
==============================================================================
--- trunk/src/mainboard/msi/ms9652_fam10/acpi_tables.c	Mon Mar  1 18:16:06 2010	(r5181)
+++ trunk/src/mainboard/msi/ms9652_fam10/acpi_tables.c	Mon Mar  1 18:19:55 2010	(r5182)
@@ -10,8 +10,8 @@
  * Copyright (C) 2009 Harald Gutmann <harald.gutmann at gmx.net>
  *
  * This program is free software; you can redistribute it and/or modify
- * it under the terms of the GNU General Public License v2 as published by
- * the Free Software Foundation.
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; version 2 of the License.
  *
  * This program is distributed in the hope that it will be useful,
  * but WITHOUT ANY WARRANTY; without even the implied warranty of

Modified: trunk/src/mainboard/msi/ms9652_fam10/devicetree.cb
==============================================================================
--- trunk/src/mainboard/msi/ms9652_fam10/devicetree.cb	Mon Mar  1 18:16:06 2010	(r5181)
+++ trunk/src/mainboard/msi/ms9652_fam10/devicetree.cb	Mon Mar  1 18:19:55 2010	(r5182)
@@ -1,8 +1,25 @@
-## Copyright (C) 2010 Raptor Engineering
-## Written by Timothy Pearson <tpearson at raptorengineeringinc.com> for Raptor Engineering.
+##
+## This file is part of the coreboot project.
 ##
 ## Copyright (C) 2007 AMD
 ## Written by Yinghai Lu <yinghailu at amd.com> for AMD.
+## Copyright (C) 2010 Raptor Engineering
+## Written by Timothy Pearson <tpearson at raptorengineeringinc.com> for Raptor Engineering.
+##
+## 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
+##
 
 chip northbridge/amd/amdfam10/root_complex
 	device apic_cluster 0 on

Modified: trunk/src/mainboard/msi/ms9652_fam10/dsdt.asl
==============================================================================
--- trunk/src/mainboard/msi/ms9652_fam10/dsdt.asl	Mon Mar  1 18:16:06 2010	(r5181)
+++ trunk/src/mainboard/msi/ms9652_fam10/dsdt.asl	Mon Mar  1 18:19:55 2010	(r5182)
@@ -1,15 +1,15 @@
 /*
  * This file is part of the coreboot project.
  *
- * (C) Copyright 2004 Nick Barker <Nick.Barker9 at btinternet.com>
- * (C) Copyright 2007, 2008 Rudolf Marek <r.marek at assembler.cz>
- * (C) Copyright 2009 Harald Gutmann <harald.gutmann at gmx.net>
+ * Copyright (C) 2004 Nick Barker <Nick.Barker9 at btinternet.com>
+ * Copyright (C) 2007, 2008 Rudolf Marek <r.marek at assembler.cz>
+ * Copyright (C) 2009 Harald Gutmann <harald.gutmann at gmx.net>
  *
  * ISA portions taken from QEMU acpi-dsdt.dsl.
  *
  * This program is free software; you can redistribute it and/or modify
- * it under the terms of the GNU General Public License v2 as published by
- * the Free Software Foundation.
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; version 2 of the License.
  *
  * This program is distributed in the hope that it will be useful,
  * but WITHOUT ANY WARRANTY; without even the implied warranty of



From svn at coreboot.org  Mon Mar  1 18:21:16 2010
From: svn at coreboot.org (repository service)
Date: Mon, 01 Mar 2010 18:21:16 +0100
Subject: [coreboot] [commit] r5183 - in trunk/src/mainboard:
	amd/dbm690t/acpi amd/pistachio/acpi kontron/kt690/acpi
	technexion/tim5690/acpi technexion/tim8690/acpi
Message-ID: <E1Nm9Iy-0008KK-5J@ra.coresystems.de>

Author: uwe
Date: Mon Mar  1 18:21:15 2010
New Revision: 5183
URL: http://tracker.coreboot.org/trac/coreboot/changeset/5183

Log:
Drop unused doit.sh files (trivial).

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

Deleted:
   trunk/src/mainboard/amd/dbm690t/acpi/doit.sh
   trunk/src/mainboard/amd/pistachio/acpi/doit.sh
   trunk/src/mainboard/kontron/kt690/acpi/doit.sh
   trunk/src/mainboard/technexion/tim5690/acpi/doit.sh
   trunk/src/mainboard/technexion/tim8690/acpi/doit.sh



From mylesgw at gmail.com  Mon Mar  1 17:54:58 2010
From: mylesgw at gmail.com (Myles Watson)
Date: Mon, 1 Mar 2010 09:54:58 -0700
Subject: [coreboot] [patch] RE: Fam10 breakage
In-Reply-To: <4B8BEFC4.1060802@georgi-clan.de>
References: <2831fecf1002241327v19493c8dq1891384716765a13@mail.gmail.com><2831fecf1002250711l1ec9d640p7ee35aeca02ffcf3@mail.gmail.com><DD1CC71B621B004FA76856E5129D6B17037D2948@sbjgexmb1.amd.com><4B87C4E8.8000600@georgi-clan.de><2831fecf1002260614g38565a2amcfde229241798755@mail.gmail.com><4B87DCBE.6080703@georgi-clan.de><2831fecf1002260735r57ca0895nb144a94e7385941@mail.gmail.com><4B882E0A.10304@georgi-clan.de><2831fecf1002261232p22880cd3g41c38f0119163187@mail.gmail.com><COL112-W22300097A8B5852F670940CD3D0@phx.gbl>	<2831fecf1002272040x4d45ded2k7f1b723cb0178e52@mail.gmail.com><DD1CC71B621B004FA76856E5129D6B17037D2DC4@sbjgexmb1.amd.com><4B8B6F25.6070106@georgi-clan.de><DD1CC71B621B004FA76856E5129D6B17037D2E91@sbjgexmb1.amd.com>
	<4B8BA96D.3060505@georgi-clan.de>
	<83ADD2156D734BF8A5C3C874248759E4@chimp>
	<4B8BEFC4.1060802@georgi-clan.de>
Message-ID: <DFB6A79EF37548D0BA5D6297EFAB4A30@chimp>


> Am 01.03.2010 17:23, schrieb Myles Watson:
> >> However, this does not fix the bug in our stack size calculation.
> >> I'm not quite sure if the patch does the right thing, but it should be
> >> close.
> > I don't think we need to make the SMP check.  Can't we just put in an
> assert
> > that checks for RAMBASE < 0xa0000 and eheap > 0xa0000?  One large stack
> > could just as easily break this.
> True. Attached patch might do this (only moderately tested)
Acked-by: Myles Watson <mylesgw at gmail.com>

> I think the only reason why we can't get rid of RAMBASE <1M completely
> is a couple of boards (Via based iirc) that have their own vgabios.c
> that breaks with RAMBASE >1M
> 
> The other RAMBASE we sometimes use (mostly on AMD boards) is RAMBASE==2M
> - what was the rationale for that again?
I don't know.  I can't see a reason for it.

> With those two gone, we could hide RAMBASE somewhere in Kconfig or
> eliminate it completely.
Wasn't there a board with RAMBASE at 32 M too?

Thanks,
Myles






From patrick at georgi-clan.de  Mon Mar  1 18:24:26 2010
From: patrick at georgi-clan.de (Patrick Georgi)
Date: Mon, 01 Mar 2010 18:24:26 +0100
Subject: [coreboot] [PATCH] cbfs, smaller api, more types
In-Reply-To: <4B89BDFD.8000605@coresystems.de>
References: <4B890743.4000608@coresystems.de>	<20100227135740.3611.qmail@stuge.se>	<4B892F1D.8010106@coresystems.de>	<4B8930D9.8040804@georgi-clan.de>	<4B893630.20308@coresystems.de>
	<4B89BDFD.8000605@coresystems.de>
Message-ID: <4B8BF84A.5050301@georgi-clan.de>

Am 28.02.2010 01:51, schrieb Stefan Reinauer:
> 
> new version
> 
I'm not sure what to do with the CBFS type numbers, but I guess we still
have them, so we can as well put them to use. This doesn't add any
headers or anything similarily controversial, so it won't be in the way
should type numbers be removed at some point.

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



From marcj303 at gmail.com  Mon Mar  1 19:59:34 2010
From: marcj303 at gmail.com (Marc Jones)
Date: Mon, 1 Mar 2010 11:59:34 -0700
Subject: [coreboot] [patch] RE: Fam10 breakage
In-Reply-To: <4B8BEFC4.1060802@georgi-clan.de>
References: <2831fecf1002241327v19493c8dq1891384716765a13@mail.gmail.com>
	<2831fecf1002261232p22880cd3g41c38f0119163187@mail.gmail.com>
	<COL112-W22300097A8B5852F670940CD3D0@phx.gbl>
	<2831fecf1002272040x4d45ded2k7f1b723cb0178e52@mail.gmail.com>
	<DD1CC71B621B004FA76856E5129D6B17037D2DC4@sbjgexmb1.amd.com>
	<4B8B6F25.6070106@georgi-clan.de>
	<DD1CC71B621B004FA76856E5129D6B17037D2E91@sbjgexmb1.amd.com>
	<4B8BA96D.3060505@georgi-clan.de>
	<83ADD2156D734BF8A5C3C874248759E4@chimp>
	<4B8BEFC4.1060802@georgi-clan.de>
Message-ID: <534e5dc21003011059k1d59c92er5a4bfed11df1358b@mail.gmail.com>

On Mon, Mar 1, 2010 at 9:48 AM, Patrick Georgi <patrick at georgi-clan.de> wrote:
> Am 01.03.2010 17:23, schrieb Myles Watson:
>>> However, this does not fix the bug in our stack size calculation.
>>> I'm not quite sure if the patch does the right thing, but it should be
>>> close.
>> I don't think we need to make the SMP check. ?Can't we just put in an assert
>> that checks for RAMBASE < 0xa0000 and eheap > 0xa0000? ?One large stack
>> could just as easily break this.
> True. Attached patch might do this (only moderately tested)
>
> I think the only reason why we can't get rid of RAMBASE <1M completely
> is a couple of boards (Via based iirc) that have their own vgabios.c
> that breaks with RAMBASE >1M
>
> The other RAMBASE we sometimes use (mostly on AMD boards) is RAMBASE==2M
> - what was the rationale for that again?
>
> With those two gone, we could hide RAMBASE somewhere in Kconfig or
> eliminate it completely.

I'm coming to this discussion a bit late, but here is what I recall.
Maybe someone else can confirm this?

Each core needs a stack large enough for the sysinfo structure and its
own call stack. Stacks space was assigned starting at 0xC8000  and
size of 0x2000 was enough pre-cbfs. When we switched to cbfs and lzma,
the stack requirement went to 0x8000. I'm not positive since things
have moved around, but I think that RAMBASE set to 2M is to leave room
for the nodes CAR stacks. With the smaller 0x2000 stack 28 cores could
be supported. Although I don't know any machines with that many cores,
 that isn't the max possible 32 ( 8cpus x 4cores )( I'm not sure where
the 48 came from unless someone is already trying to support 6 core
cpus?). So, RAMBASE was moved to 2M. This is more important with
stacks of 0x8000 for each core as only 7 cores could be supported
below 1M.

Now, does RAMBASE really need to be affected by the CAR stacks? I
don't think so since the BSP does the decompress and the move after
memory init and all the APs are halted. Also, how many stacks do we
really need? I think that core0 for each node is the only one that
must run to do HT and memory init on the node before coreboot_ram is
run. The other cores can be setup later.

I think Patrick and Myles mentioned that we need to understand the
bootblock while each cpu core initializing and walking the cbfs while
not stepping on each others stacks. Has that been resolved?

I hope this made some sense and helps understand the problem.

Marc

-- 
http://se-eng.com



From mylesgw at gmail.com  Mon Mar  1 20:32:05 2010
From: mylesgw at gmail.com (Myles Watson)
Date: Mon, 1 Mar 2010 12:32:05 -0700
Subject: [coreboot] [patch] RE: Fam10 breakage
In-Reply-To: <534e5dc21003011059k1d59c92er5a4bfed11df1358b@mail.gmail.com>
References: <2831fecf1002241327v19493c8dq1891384716765a13@mail.gmail.com>
	<2831fecf1002261232p22880cd3g41c38f0119163187@mail.gmail.com>
	<COL112-W22300097A8B5852F670940CD3D0@phx.gbl>
	<2831fecf1002272040x4d45ded2k7f1b723cb0178e52@mail.gmail.com>
	<DD1CC71B621B004FA76856E5129D6B17037D2DC4@sbjgexmb1.amd.com>
	<4B8B6F25.6070106@georgi-clan.de>
	<DD1CC71B621B004FA76856E5129D6B17037D2E91@sbjgexmb1.amd.com>
	<4B8BA96D.3060505@georgi-clan.de>
	<83ADD2156D734BF8A5C3C874248759E4@chimp>
	<4B8BEFC4.1060802@georgi-clan.de>
	<534e5dc21003011059k1d59c92er5a4bfed11df1358b@mail.gmail.com>
Message-ID: <94A3107A5FB549A7AFDD49CFBEF2DFC0@chimp>



> -----Original Message-----
> From: Marc Jones [mailto:marcj303 at gmail.com]
> Sent: Monday, March 01, 2010 12:00 PM
> To: Patrick Georgi
> Cc: Myles Watson; coreboot at coreboot.org
> Subject: Re: [coreboot] [patch] RE: Fam10 breakage
> 
> On Mon, Mar 1, 2010 at 9:48 AM, Patrick Georgi <patrick at georgi-clan.de>
> wrote:
> > Am 01.03.2010 17:23, schrieb Myles Watson:
> >>> However, this does not fix the bug in our stack size calculation.
> >>> I'm not quite sure if the patch does the right thing, but it should be
> >>> close.
> >> I don't think we need to make the SMP check. ?Can't we just put in an
> assert
> >> that checks for RAMBASE < 0xa0000 and eheap > 0xa0000? ?One large stack
> >> could just as easily break this.
> > True. Attached patch might do this (only moderately tested)
> >
> > I think the only reason why we can't get rid of RAMBASE <1M completely
> > is a couple of boards (Via based iirc) that have their own vgabios.c
> > that breaks with RAMBASE >1M
> >
> > The other RAMBASE we sometimes use (mostly on AMD boards) is RAMBASE==2M
> > - what was the rationale for that again?
> >
> > With those two gone, we could hide RAMBASE somewhere in Kconfig or
> > eliminate it completely.
> 
> I'm coming to this discussion a bit late, but here is what I recall.
> Maybe someone else can confirm this?
> 
> Each core needs a stack large enough for the sysinfo structure and its
> own call stack. Stacks space was assigned starting at 0xC8000
This looks like a CAR address.  Most of the boards have RAMBASE 1M now,
right?

> size of 0x2000 was enough pre-cbfs. When we switched to cbfs and lzma,
> the stack requirement went to 0x8000. I'm not positive since things
> have moved around, but I think that RAMBASE set to 2M is to leave room
> for the nodes CAR stacks.
Shouldn't CAR stacks be below 1M?

> With the smaller 0x2000 stack 28 cores could
> be supported. Although I don't know any machines with that many cores,
>  that isn't the max possible 32 ( 8cpus x 4cores )( I'm not sure where
> the 48 came from unless someone is already trying to support 6 core
> cpus?).
Yep.

> So, RAMBASE was moved to 2M. This is more important with
> stacks of 0x8000 for each core as only 7 cores could be supported
> below 1M.
> 
> Now, does RAMBASE really need to be affected by the CAR stacks? I
> don't think so since the BSP does the decompress and the move after
> memory init and all the APs are halted. Also, how many stacks do we
> really need? I think that core0 for each node is the only one that
> must run to do HT and memory init on the node before coreboot_ram is
> run.
Do all the core0 processors have to do init?  I thought HT and memory init
was all done by BSP core0.

Maybe we should add specific memory areas for lzma and page tables so we can
go back to having smaller stacks.  Otherwise, maybe we should have two sizes
of stacks.

Thanks,
Myles




From svn at coreboot.org  Mon Mar  1 21:16:39 2010
From: svn at coreboot.org (repository service)
Date: Mon, 01 Mar 2010 21:16:39 +0100
Subject: [coreboot] [commit] r5184 - in trunk/src/mainboard:
	msi/ms9652_fam10 tyan/s2912_fam10
Message-ID: <E1NmC2h-00029o-4E@ra.coresystems.de>

Author: uwe
Date: Mon Mar  1 21:16:38 2010
New Revision: 5184
URL: http://tracker.coreboot.org/trac/coreboot/changeset/5184

Log:
Whitespace changes to make s2912_fam10/ms9652_fam10 more similar.

Also, fix another typo in the ms9652 board name.

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

Modified:
   trunk/src/mainboard/msi/ms9652_fam10/Kconfig
   trunk/src/mainboard/msi/ms9652_fam10/resourcemap.c
   trunk/src/mainboard/msi/ms9652_fam10/romstage.c
   trunk/src/mainboard/msi/ms9652_fam10/spd_addr.h
   trunk/src/mainboard/tyan/s2912_fam10/Kconfig
   trunk/src/mainboard/tyan/s2912_fam10/get_bus_conf.c
   trunk/src/mainboard/tyan/s2912_fam10/mptable.c
   trunk/src/mainboard/tyan/s2912_fam10/romstage.c

Modified: trunk/src/mainboard/msi/ms9652_fam10/Kconfig
==============================================================================
--- trunk/src/mainboard/msi/ms9652_fam10/Kconfig	Mon Mar  1 18:21:15 2010	(r5183)
+++ trunk/src/mainboard/msi/ms9652_fam10/Kconfig	Mon Mar  1 21:16:38 2010	(r5184)
@@ -134,7 +134,7 @@
 
 config MAINBOARD_PART_NUMBER
 	string
-	default "MS-9252"
+	default "MS-9652"
 	depends on BOARD_MSI_MS9652_FAM10
 
 config MAINBOARD_PCI_SUBSYSTEM_VENDOR_ID

Modified: trunk/src/mainboard/msi/ms9652_fam10/resourcemap.c
==============================================================================
--- trunk/src/mainboard/msi/ms9652_fam10/resourcemap.c	Mon Mar  1 18:21:15 2010	(r5183)
+++ trunk/src/mainboard/msi/ms9652_fam10/resourcemap.c	Mon Mar  1 21:16:38 2010	(r5184)
@@ -161,7 +161,7 @@
 		 *	   1 = base/limit registers i are read-only
 		 * [ 7: 4] Reserved
 		 * [31: 8] Memory-Mapped I/O Base Address i (39-16)
-		 *	   This field defines the upper address bits of a 40bit address 
+		 *	   This field defines the upper address bits of a 40bit address
 		 *	   that defines the start of memory-mapped I/O region i
 		 */
 		PCI_ADDR(CONFIG_CBB, CONFIG_CDB, 1, 0x80), 0x000000f0, 0x00000000,
@@ -218,7 +218,7 @@
 		 * [ 3: 2] Reserved
 		 * [ 4: 4] VGA Enable
 		 *	   0 = VGA matches Disabled
-		 *	   1 = matches all address < 64K and where A[9:0] is in the 
+		 *	   1 = matches all address < 64K and where A[9:0] is in the
 		 *	       range 3B0-3BB or 3C0-3DF independen of the base & limit registers
 		 * [ 5: 5] ISA Enable
 		 *	   0 = ISA matches Disabled
@@ -226,7 +226,7 @@
 		 *	       from matching agains this base/limit pair
 		 * [11: 6] Reserved
 		 * [24:12] PCI I/O Base i
-		 *	   This field defines the start of PCI I/O region n 
+		 *	   This field defines the start of PCI I/O region n
 		 * [31:25] Reserved
 		 */
 		/* Verified against board configuration registers after normal proprietary BIOS boot */

Modified: trunk/src/mainboard/msi/ms9652_fam10/romstage.c
==============================================================================
--- trunk/src/mainboard/msi/ms9652_fam10/romstage.c	Mon Mar  1 18:21:15 2010	(r5183)
+++ trunk/src/mainboard/msi/ms9652_fam10/romstage.c	Mon Mar  1 21:16:38 2010	(r5184)
@@ -50,9 +50,9 @@
 #include "pc80/mc146818rtc_early.c"
 #include "pc80/serial.c"
 
- static void post_code(u8 value) {
- 	outb(value, 0x80);
- }
+static void post_code(u8 value) {
+	outb(value, 0x80);
+}
 
 #if CONFIG_USE_FAILOVER_IMAGE==0
 #include "arch/i386/lib/console.c"
@@ -153,20 +153,17 @@
 
 static void sio_setup(void)
 {
-
-        unsigned value;
-        uint32_t dword;
-        uint8_t byte;
-
-        byte = pci_read_config32(PCI_DEV(0, MCP55_DEVN_BASE+1 , 0), 0x7b);
-        byte |= 0x20;
-        pci_write_config8(PCI_DEV(0, MCP55_DEVN_BASE+1 , 0), 0x7b, byte);
-
-        dword = pci_read_config32(PCI_DEV(0, MCP55_DEVN_BASE+1 , 0), 0xa0);
-        dword |= (1<<0);
-        pci_write_config32(PCI_DEV(0, MCP55_DEVN_BASE+1 , 0), 0xa0, dword);
-
-
+	unsigned value;
+	uint32_t dword;
+	uint8_t byte;
+
+	byte = pci_read_config32(PCI_DEV(0, MCP55_DEVN_BASE+1 , 0), 0x7b);
+	byte |= 0x20;
+	pci_write_config8(PCI_DEV(0, MCP55_DEVN_BASE+1 , 0), 0x7b, byte);
+
+	dword = pci_read_config32(PCI_DEV(0, MCP55_DEVN_BASE+1 , 0), 0xa0);
+	dword |= (1<<0);
+	pci_write_config32(PCI_DEV(0, MCP55_DEVN_BASE+1 , 0), 0xa0, dword);
 }
 
 void failover_process(unsigned long bist, unsigned long cpu_init_detectedx)
@@ -281,10 +278,10 @@
 #endif
 
 	val = cpuid_eax(1);
-	printk_debug("BSP Family_Model: %08x \n", val);
+	printk_debug("BSP Family_Model: %08x\n", val);
 	printk_debug("*sysinfo range: ["); print_debug_hex32((u32)sysinfo); print_debug(","); print_debug_hex32((u32)sysinfo+sizeof(struct sys_info)); print_debug("]\n");
-	printk_debug("bsp_apicid = %02x \n", bsp_apicid);
-	printk_debug("cpu_init_detectedx = %08x \n", cpu_init_detectedx);
+	printk_debug("bsp_apicid = %02x\n", bsp_apicid);
+	printk_debug("cpu_init_detectedx = %08x\n", cpu_init_detectedx);
 
 	/* Setup sysinfo defaults */
 	set_sysinfo_in_ram(0);
@@ -300,12 +297,12 @@
 
 	/* Setup nodes PCI space and start core 0 AP init. */
 	finalize_node_setup(sysinfo);
-	printk_debug("finalize_node_setup done \n");
+	printk_debug("finalize_node_setup done\n");
 
 	/* Setup any mainboard PCI settings etc. */
-	printk_debug("setup_mb_resource_map begin \n");
+	printk_debug("setup_mb_resource_map begin\n");
 	setup_mb_resource_map();
-	printk_debug("setup_mb_resource_map end \n");
+	printk_debug("setup_mb_resource_map end\n");
 	post_code(0x36);
 
 	/* wait for all the APs core0 started by finalize_node_setup. */
@@ -329,7 +326,7 @@
 
 #if FAM10_SET_FIDVID == 1
 	msr = rdmsr(0xc0010071);
-	printk_debug("\nBegin FIDVID MSR 0xc0010071 0x%08x 0x%08x \n", msr.hi, msr.lo);
+	printk_debug("\nBegin FIDVID MSR 0xc0010071 0x%08x 0x%08x\n", msr.hi, msr.lo);
 
 	/* FIXME: The sb fid change may survive the warm reset and only
 	 * need to be done once.*/
@@ -347,7 +344,7 @@
 
 	/* show final fid and vid */
 	msr=rdmsr(0xc0010071);
-	printk_debug("End FIDVIDMSR 0xc0010071 0x%08x 0x%08x \n", msr.hi, msr.lo);
+	printk_debug("End FIDVIDMSR 0xc0010071 0x%08x 0x%08x\n", msr.hi, msr.lo);
 #endif
 
 	wants_reset = mcp55_early_setup_x();

Modified: trunk/src/mainboard/msi/ms9652_fam10/spd_addr.h
==============================================================================
--- trunk/src/mainboard/msi/ms9652_fam10/spd_addr.h	Mon Mar  1 18:21:15 2010	(r5183)
+++ trunk/src/mainboard/msi/ms9652_fam10/spd_addr.h	Mon Mar  1 21:16:38 2010	(r5184)
@@ -19,7 +19,7 @@
 
 /**
  * This file defines the SPD addresses for the mainboard. Must be included in
- * cache_as_ram_auto.c
+ * romstage.c
  */
 
 #define RC00 0

Modified: trunk/src/mainboard/tyan/s2912_fam10/Kconfig
==============================================================================
--- trunk/src/mainboard/tyan/s2912_fam10/Kconfig	Mon Mar  1 18:21:15 2010	(r5183)
+++ trunk/src/mainboard/tyan/s2912_fam10/Kconfig	Mon Mar  1 21:16:38 2010	(r5184)
@@ -27,7 +27,7 @@
 	hex
 	default 0xc4000
 	depends on BOARD_TYAN_S2912_FAM10
-	
+
 config DCACHE_RAM_SIZE
 	hex
 	default 0x0c000
@@ -39,7 +39,7 @@
 	depends on BOARD_TYAN_S2912_FAM10
 
 config APIC_ID_OFFSET
-	hex	
+	hex
 	default 0
 	depends on BOARD_TYAN_S2912_FAM10
 
@@ -65,7 +65,7 @@
 
 config LB_CKS_LOC
 	int
-        default 123
+	default 123
 	depends on BOARD_TYAN_S2912_FAM10
 
 config MAINBOARD_PART_NUMBER
@@ -75,7 +75,7 @@
 
 config PCI_64BIT_PREF_MEM
 	bool
-        default n
+	default n
 	depends on BOARD_TYAN_S2912_FAM10
 
 config HAVE_FALLBACK_BOOT
@@ -104,7 +104,7 @@
 	depends on BOARD_TYAN_S2912_FAM10
 
 config HW_MEM_HOLE_SIZE_AUTO_INC
-	bool	
+	bool
 	default n
 	depends on BOARD_TYAN_S2912_FAM10
 
@@ -114,7 +114,7 @@
 	depends on BOARD_TYAN_S2912_FAM10
 
 config HT_CHAIN_END_UNITID_BASE
-	hex	
+	hex
 	default 0x20
 	depends on BOARD_TYAN_S2912_FAM10
 
@@ -124,12 +124,12 @@
 	depends on BOARD_TYAN_S2912_FAM10
 
 config SERIAL_CPU_INIT
-	bool	
+	bool
 	default n
 	depends on BOARD_TYAN_S2912_FAM10
 
 config WAIT_BEFORE_CPUS_INIT
-	bool	
+	bool
 	default n
 	depends on BOARD_TYAN_S2912_FAM10
 

Modified: trunk/src/mainboard/tyan/s2912_fam10/get_bus_conf.c
==============================================================================
--- trunk/src/mainboard/tyan/s2912_fam10/get_bus_conf.c	Mon Mar  1 18:21:15 2010	(r5183)
+++ trunk/src/mainboard/tyan/s2912_fam10/get_bus_conf.c	Mon Mar  1 21:16:38 2010	(r5184)
@@ -68,7 +68,6 @@
 
 void get_bus_conf(void)
 {
-
 	unsigned apicid_base;
 	struct mb_sysconf_t *m;
 
@@ -134,5 +133,4 @@
 	apicid_base = CONFIG_MAX_PHYSICAL_CPUS;
 #endif
 	m->apicid_mcp55 = apicid_base+0;
-
 }

Modified: trunk/src/mainboard/tyan/s2912_fam10/mptable.c
==============================================================================
--- trunk/src/mainboard/tyan/s2912_fam10/mptable.c	Mon Mar  1 18:21:15 2010	(r5183)
+++ trunk/src/mainboard/tyan/s2912_fam10/mptable.c	Mon Mar  1 21:16:38 2010	(r5184)
@@ -100,7 +100,7 @@
 
 	}
 
-		   /*I/O Ints:	Type	Polarity    Trigger			Bus ID	 IRQ	APIC ID	PIN# */
+			/*I/O Ints:	Type	Polarity    Trigger			Bus ID	 IRQ	APIC ID	PIN# */
 	smp_write_intsrc(mc, mp_ExtINT, MP_IRQ_TRIGGER_EDGE|MP_IRQ_POLARITY_HIGH, m->bus_isa, 0x0, m->apicid_mcp55, 0x0);
 	smp_write_intsrc(mc, mp_INT, MP_IRQ_TRIGGER_EDGE|MP_IRQ_POLARITY_HIGH,  m->bus_isa, 0x1, m->apicid_mcp55, 0x1);
 	smp_write_intsrc(mc, mp_INT, MP_IRQ_TRIGGER_EDGE|MP_IRQ_POLARITY_HIGH,  m->bus_isa, 0x0, m->apicid_mcp55, 0x2);

Modified: trunk/src/mainboard/tyan/s2912_fam10/romstage.c
==============================================================================
--- trunk/src/mainboard/tyan/s2912_fam10/romstage.c	Mon Mar  1 18:21:15 2010	(r5183)
+++ trunk/src/mainboard/tyan/s2912_fam10/romstage.c	Mon Mar  1 21:16:38 2010	(r5184)
@@ -150,10 +150,8 @@
 #include "southbridge/nvidia/mcp55/mcp55_enable_rom.c"
 #include "northbridge/amd/amdfam10/early_ht.c"
 
-
 static void sio_setup(void)
 {
-
 	unsigned value;
 	uint32_t dword;
 	uint8_t byte;
@@ -278,10 +276,10 @@
 #endif
 
 	val = cpuid_eax(1);
-	printk_debug("BSP Family_Model: %08x \n", val);
+	printk_debug("BSP Family_Model: %08x\n", val);
 	printk_debug("*sysinfo range: ["); print_debug_hex32((u32)sysinfo); print_debug(","); print_debug_hex32((u32)sysinfo+sizeof(struct sys_info)); print_debug("]\n");
-	printk_debug("bsp_apicid = %02x \n", bsp_apicid);
-	printk_debug("cpu_init_detectedx = %08x \n", cpu_init_detectedx);
+	printk_debug("bsp_apicid = %02x\n", bsp_apicid);
+	printk_debug("cpu_init_detectedx = %08x\n", cpu_init_detectedx);
 
 	/* Setup sysinfo defaults */
 	set_sysinfo_in_ram(0);
@@ -322,7 +320,7 @@
 
 #if FAM10_SET_FIDVID == 1
 	msr = rdmsr(0xc0010071);
-	printk_debug("\nBegin FIDVID MSR 0xc0010071 0x%08x 0x%08x \n", msr.hi, msr.lo);
+	printk_debug("\nBegin FIDVID MSR 0xc0010071 0x%08x 0x%08x\n", msr.hi, msr.lo);
 
 	/* FIXME: The sb fid change may survive the warm reset and only
 	 * need to be done once.*/
@@ -340,7 +338,7 @@
 
 	/* show final fid and vid */
 	msr=rdmsr(0xc0010071);
-	printk_debug("End FIDVIDMSR 0xc0010071 0x%08x 0x%08x \n", msr.hi, msr.lo);
+	printk_debug("End FIDVIDMSR 0xc0010071 0x%08x 0x%08x\n", msr.hi, msr.lo);
 #endif
 
 	wants_reset = mcp55_early_setup_x();



From marcj303 at gmail.com  Mon Mar  1 21:51:37 2010
From: marcj303 at gmail.com (Marc Jones)
Date: Mon, 1 Mar 2010 13:51:37 -0700
Subject: [coreboot] [patch] RE: Fam10 breakage
In-Reply-To: <94A3107A5FB549A7AFDD49CFBEF2DFC0@chimp>
References: <2831fecf1002241327v19493c8dq1891384716765a13@mail.gmail.com>
	<2831fecf1002272040x4d45ded2k7f1b723cb0178e52@mail.gmail.com>
	<DD1CC71B621B004FA76856E5129D6B17037D2DC4@sbjgexmb1.amd.com>
	<4B8B6F25.6070106@georgi-clan.de>
	<DD1CC71B621B004FA76856E5129D6B17037D2E91@sbjgexmb1.amd.com>
	<4B8BA96D.3060505@georgi-clan.de>
	<83ADD2156D734BF8A5C3C874248759E4@chimp>
	<4B8BEFC4.1060802@georgi-clan.de>
	<534e5dc21003011059k1d59c92er5a4bfed11df1358b@mail.gmail.com>
	<94A3107A5FB549A7AFDD49CFBEF2DFC0@chimp>
Message-ID: <534e5dc21003011251v6ca3004csf2ce92248ebfdfb8@mail.gmail.com>

On Mon, Mar 1, 2010 at 12:32 PM, Myles Watson <mylesgw at gmail.com> wrote:
>
>
>> -----Original Message-----
>> From: Marc Jones [mailto:marcj303 at gmail.com]
>> Sent: Monday, March 01, 2010 12:00 PM
>> To: Patrick Georgi
>> Cc: Myles Watson; coreboot at coreboot.org
>> Subject: Re: [coreboot] [patch] RE: Fam10 breakage
>>
>> On Mon, Mar 1, 2010 at 9:48 AM, Patrick Georgi <patrick at georgi-clan.de>
>> wrote:
>> > Am 01.03.2010 17:23, schrieb Myles Watson:
>> >>> However, this does not fix the bug in our stack size calculation.
>> >>> I'm not quite sure if the patch does the right thing, but it should be
>> >>> close.
>> >> I don't think we need to make the SMP check. ?Can't we just put in an
>> assert
>> >> that checks for RAMBASE < 0xa0000 and eheap > 0xa0000? ?One large stack
>> >> could just as easily break this.
>> > True. Attached patch might do this (only moderately tested)
>> >
>> > I think the only reason why we can't get rid of RAMBASE <1M completely
>> > is a couple of boards (Via based iirc) that have their own vgabios.c
>> > that breaks with RAMBASE >1M
>> >
>> > The other RAMBASE we sometimes use (mostly on AMD boards) is RAMBASE==2M
>> > - what was the rationale for that again?
>> >
>> > With those two gone, we could hide RAMBASE somewhere in Kconfig or
>> > eliminate it completely.
>>
>> I'm coming to this discussion a bit late, but here is what I recall.
>> Maybe someone else can confirm this?
>>
>> Each core needs a stack large enough for the sysinfo structure and its
>> own call stack. Stacks space was assigned starting at 0xC8000
> This looks like a CAR address. ?Most of the boards have RAMBASE 1M now,
> right?
>
>> size of 0x2000 was enough pre-cbfs. When we switched to cbfs and lzma,
>> the stack requirement went to 0x8000. I'm not positive since things
>> have moved around, but I think that RAMBASE set to 2M is to leave room
>> for the nodes CAR stacks.
> Shouldn't CAR stacks be below 1M?
>
>> With the smaller 0x2000 stack 28 cores could
>> be supported. Although I don't know any machines with that many cores,
>> ?that isn't the max possible 32 ( 8cpus x 4cores )( I'm not sure where
>> the 48 came from unless someone is already trying to support 6 core
>> cpus?).
> Yep.
>
>> So, RAMBASE was moved to 2M. This is more important with
>> stacks of 0x8000 for each core as only 7 cores could be supported
>> below 1M.
>>
>> Now, does RAMBASE really need to be affected by the CAR stacks? I
>> don't think so since the BSP does the decompress and the move after
>> memory init and all the APs are halted. Also, how many stacks do we
>> really need? I think that core0 for each node is the only one that
>> must run to do HT and memory init on the node before coreboot_ram is
>> run.
> Do all the core0 processors have to do init? ?I thought HT and memory init
> was all done by BSP core0.
>
> Maybe we should add specific memory areas for lzma and page tables so we can
> go back to having smaller stacks. ?Otherwise, maybe we should have two sizes
> of stacks.

I had to go look at the code to remeber the details.  Each core does
fid/vid setup before HT reset. You are correct, the BSP handles the
memory init. I was thinking on msrs setup but that happens later in
coreboot_ram (each core has to write some of its own msrs,TOM, TOM2 at
least).

You can see when core0 and coreN are started in romstage.c. Every core
runs init_cpus() which does different things depending on BSP, core0,
and coreN.  It looks like each core sets lapic and fid/vid. All cores
on a cpu will have the same fid/vid capability, so only core0 should
have to be setup, but currently every core is getting fid/vid setup
(#define FAM10_SET_FIDVID_CORE0_ONLY 0). I think the complexity comes
from what could be done and what is working today.

Marc

-- 
http://se-eng.com



From marcj303 at gmail.com  Mon Mar  1 22:40:47 2010
From: marcj303 at gmail.com (Marc Jones)
Date: Mon, 1 Mar 2010 14:40:47 -0700
Subject: [coreboot] [PATCH]: Disable ExtINT in ioapic.c
In-Reply-To: <DD1CC71B621B004FA76856E5129D6B17037D2DD5@sbjgexmb1.amd.com>
References: <DD1CC71B621B004FA76856E5129D6B17036DA956@sbjgexmb1.amd.com>
	<4B68D414.9030500@coresystems.de>
	<DD1CC71B621B004FA76856E5129D6B17037D2DD5@sbjgexmb1.amd.com>
Message-ID: <534e5dc21003011340t5ac3d427rd0752c5b553731c9@mail.gmail.com>

On Sun, Feb 28, 2010 at 10:53 PM, Bao, Zheng <Zheng.Bao at amd.com> wrote:
> I tried other board. The K8+rs690+sb600 and k8+rs780+sb700 don't work on
> current version, while fam10+rs780+sb700 works. I doubt that it has
> something to do the spurious interrupt or timer interrupt. I don't know.
> Do you have any idea?
>

That comment makes me think that the k8 lapic isn't setup correctly.
There is a lot more lapic setup in the fam10 code for fid/vid support.
We will have to look K8 more closely.  I am seeing something similar
on Pistachio when seabios enables the timer interrupt. I haven't
tracked it down any farther yet.


Marc

-- 
http://se-eng.com



From forevertheuni at gmail.com  Mon Mar  1 23:09:46 2010
From: forevertheuni at gmail.com (Joao Mamede)
Date: Mon, 01 Mar 2010 23:09:46 +0100
Subject: [coreboot] Re  unsuported Motherboard
In-Reply-To: <4B8BD8BD.2020001@gmail.com>
References: <4B8BD8BD.2020001@gmail.com>
Message-ID: <4B8C3B2A.9030506@gmail.com>

Hello Again,
So the BIOs chip is not socketed. It's soldered into the motherboard.
There is a sticker in the motherboard that has: 686 AMIBIOS NB 1999 BJ00 
9702
So I guess next step will be to unsolder the Bios and solder a socket to 
plug in a BIOS and buy a BIOS external  writer. Can I have 
recommendations on where to buy?(Europe zone would be preferable for me).

Thanks again
Jo?o

Joao Mamede wrote:
> On 1/4/10 12:17 PM, Joao Mamede wrote:
>> / Hello I want to use coreboot in an old laptop (in order to
> />/ replace/upgrade a fried graphics card).
> />/ Both the southern and northernbridges are suported
> />/ The laptop is the A8js from asus.
> />/
> />/ Here's an lspci
> />/ 00:00.0 Host bridge: Intel Corporation Mobile 945GM/PM/GMS/940GML and
> />/ 945GT Express Memory Controller Hub (rev 03)
> />/ 00:1f.0 ISA bridge: Intel Corporation 82801GBM (ICH7-M) LPC Interface
> />/ Bridge (rev 02) /
>> /
> />/ I can't find a socketed bios in the motherboard...so I guess I have
> />/ one try.
> />/ Can anyone help me out in making a target build(I wouldn't bother you
> />/ and try to do it myself if I had more than one chance).
> />/ It's either make it work and make me happy, or put the laptop in the
> />/ garbage..independently of frying the bios or not.
> />/ Thank you
> /
> Chances are good to get coreboot running on this laptop, its components
> seem to be mostly supported by coreboot. However, the chance of getting
> everything working on the first try are zero. The chances to get the
> system at least to boot on the first try and always keep the system in a
> working, updatable state are almost zero, too. So if you attempt to port
> coreboot to this machine, you will need to create some kind of recovery
> mechanism. You could solder a socket to the mainboard, or a plug to
> reflash the machine externally.
>
> However, to get started, I suggest that you find out what flash chip you
> have on the board, so you can determine what recovery mechanism is
> suitable. (The flashrom utility from www.flashrom.org will help you with
> that)
>
> Also, a dump of superiotool -ed will help you a lot. Does the machine
> have a serial port?
>
> Stefan
>
>
> The machine has no serial port. I think it's a socketed bios(from the 
> pics of the disassembly tech manual). However I have to disassemble 
> everything in order to acess the BIOS
> Is there a way to plug a chip that has a wire coming to the outside to 
> a machine that contains or  the BIOS chip or and emulation of one?
> I'll do all the dumps, etc and post here again.
>
>
>




From peter at stuge.se  Tue Mar  2 00:10:37 2010
From: peter at stuge.se (Peter Stuge)
Date: Tue, 2 Mar 2010 00:10:37 +0100
Subject: [coreboot] Re  unsuported Motherboard
In-Reply-To: <4B8C3B2A.9030506@gmail.com>
References: <4B8BD8BD.2020001@gmail.com> <4B8C3B2A.9030506@gmail.com>
Message-ID: <20100301231037.15719.qmail@stuge.se>

Joao Mamede wrote:
> a socket to plug in a BIOS and buy a BIOS external  writer. Can I
> have recommendations on where to buy?

What's your budget?

farnell.com should have PLCC sockets and maybe even flash chips.
bios-repair.co.uk has flash chips, and maybe PLCC sockets.

For programmer it would probably be simplest to use another
mainboard which is compatible with flashrom.

Check which flash chip is in the system, if it's an SPI chip then
your best bet is to order the sockets from bios-repair.co.uk instead,
I haven't seen SO-8 sockets easily available anywhere else.


//Peter



From r.marek at assembler.cz  Tue Mar  2 00:27:28 2010
From: r.marek at assembler.cz (Rudolf Marek)
Date: Tue, 02 Mar 2010 00:27:28 +0100
Subject: [coreboot] [PATCH]: Disable ExtINT in ioapic.c
In-Reply-To: <534e5dc21003011340t5ac3d427rd0752c5b553731c9@mail.gmail.com>
References: <DD1CC71B621B004FA76856E5129D6B17036DA956@sbjgexmb1.amd.com>	<4B68D414.9030500@coresystems.de>	<DD1CC71B621B004FA76856E5129D6B17037D2DD5@sbjgexmb1.amd.com>
	<534e5dc21003011340t5ac3d427rd0752c5b553731c9@mail.gmail.com>
Message-ID: <4B8C4D60.4060406@assembler.cz>

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

Hi,

On K8 + K8M890 it works well, please let me know what to test.

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

iEYEARECAAYFAkuMTWAACgkQ3J9wPJqZRNWxcQCfbXyqy7pivnyqp2tvj8MoZWOP
HyIAnjXUJX3+xk2Y/0e80BX0gJT5CldJ
=O44k
-----END PGP SIGNATURE-----



From buurin at gmail.com  Tue Mar  2 06:39:12 2010
From: buurin at gmail.com (Keith Hui)
Date: Tue, 2 Mar 2010 00:39:12 -0500
Subject: [coreboot] HELP: Porting i830 RAM init to 440BX,
	now it won't compile
Message-ID: <b72cdb061003012139s7db33e45sc2e043c35248e2fd@mail.gmail.com>

Hi, I need help getting this "patch" to compile.

This is my attempt at porting Joseph Smith's i830 RAM init code to 440BX.
Apply this patch and you have my 440BX part of the code. Which is where all
the trouble is. I changed motherboard target to P2B-F, P3B-F (both of which
which I haven't touched), and my under-development P2B-LS targets and they
all fail.

I need to figure out why romcc won't compile this. I wrote some stubs that I
use to test this code under userspace with dummy SPD dumps from a dozen of
my DIMM modules. I define TESTJIG when I'm compiling raminit.c to use these
stubs for my own userspace testing. gcc is used to compile both my stubs and
raminit.c for those tests and they all compile and seems to run fine. Now I
need to boot test it.

This code needs some expansion for i440bx because it supports a number of
features not present in i830.

Below are output of make when I tried to compile:

ramtest.c:6.0: warning: Replacing undefined macro: CONFIG_SSE2 with 0
ramtest.c:56.0: warning: Replacing undefined macro: CONFIG_SSE2 with 0
raminit.c:605.46: raminit.c:789.32: romstage.c:96.32:
0xd28680 or         Internal compiler error: non dominated rhs use point
0xd288d0?
make: *** [/usr/src/coreboot/build/mainboard/asus/p2b-ls/romstage.inc]
Aborted

The part of raminit.c that croaks is:

...
            if (value == SPD_MEMORY_TYPE_EDO) {
                edosd |= 0x02;
                PRINT_DEBUG("EDO");
            } else if (value == SPD_MEMORY_TYPE_SDRAM) {
                edosd |= 0x04;  // <<< ABORT!
                PRINT_DEBUG("SDRAM");   // <<< ABORT!
            }
...

Let me add another few questions here. I want to add code to have coreboot
talk to the clock chip to find out its FSB in order to select the fastest
memory timing from SPD data. 440BX only has official support for 100MHz, but
they often are taken to 133MHz and beyond - my two boards are tested stable
to 140MHz. I know the clock chip sits on SMBus, and have a fixed address at
0x69. That's with the clock chip my board uses. Where should this code be
placed?

The vendor BIOS placed the PIIX4E power management device base port at
0xE400, and its SMBus base port at 0xE800. Coreboot has its SMBus base port
at 0x0F00. If I want to change the base port to match vendor BIOS, where
should it be made?

Any help appreciated.

Thanks
Keith
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20100302/f3dff894/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: bxram.patch
Type: application/octet-stream
Size: 22304 bytes
Desc: not available
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20100302/f3dff894/attachment.obj>

From Zheng.Bao at amd.com  Tue Mar  2 09:06:20 2010
From: Zheng.Bao at amd.com (Bao, Zheng)
Date: Tue, 2 Mar 2010 16:06:20 +0800
Subject: [coreboot] [PATCH]: Disable ExtINT in ioapic.c
In-Reply-To: <4B8C4D60.4060406@assembler.cz>
References: <DD1CC71B621B004FA76856E5129D6B17036DA956@sbjgexmb1.amd.com>	<4B68D414.9030500@coresystems.de>	<DD1CC71B621B004FA76856E5129D6B17037D2DD5@sbjgexmb1.amd.com><534e5dc21003011340t5ac3d427rd0752c5b553731c9@mail.gmail.com>
	<4B8C4D60.4060406@assembler.cz>
Message-ID: <DD1CC71B621B004FA76856E5129D6B17037D3189@sbjgexmb1.amd.com>

Call the setup_ioapic in southbridge and see if linux hangs.

Zheng

-----Original Message-----
From: coreboot-bounces at coreboot.org
[mailto:coreboot-bounces at coreboot.org] On Behalf Of Rudolf Marek
Sent: Tuesday, March 02, 2010 7:27 AM
To: Marc Jones
Cc: Stefan Reinauer; Bao, Zheng; coreboot at coreboot.org
Subject: Re: [coreboot] [PATCH]: Disable ExtINT in ioapic.c

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

Hi,

On K8 + K8M890 it works well, please let me know what to test.

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

iEYEARECAAYFAkuMTWAACgkQ3J9wPJqZRNWxcQCfbXyqy7pivnyqp2tvj8MoZWOP
HyIAnjXUJX3+xk2Y/0e80BX0gJT5CldJ
=O44k
-----END PGP SIGNATURE-----

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





From r.marek at assembler.cz  Tue Mar  2 11:02:11 2010
From: r.marek at assembler.cz (Rudolf Marek)
Date: Tue, 02 Mar 2010 11:02:11 +0100
Subject: [coreboot] [PATCH]: Disable ExtINT in ioapic.c
In-Reply-To: <DD1CC71B621B004FA76856E5129D6B17037D3189@sbjgexmb1.amd.com>
References: <DD1CC71B621B004FA76856E5129D6B17036DA956@sbjgexmb1.amd.com>	<4B68D414.9030500@coresystems.de>	<DD1CC71B621B004FA76856E5129D6B17037D2DD5@sbjgexmb1.amd.com><534e5dc21003011340t5ac3d427rd0752c5b553731c9@mail.gmail.com>	<4B8C4D60.4060406@assembler.cz>
	<DD1CC71B621B004FA76856E5129D6B17037D3189@sbjgexmb1.amd.com>
Message-ID: <4B8CE223.2020209@assembler.cz>

> Call the setup_ioapic in southbridge and see if linux hangs.
> 
> Zheng


Yes this is done, works fine. Check vt8237r_lpc.c

Rudolf




From joe at settoplinux.org  Tue Mar  2 13:37:48 2010
From: joe at settoplinux.org (Joseph Smith)
Date: Tue, 02 Mar 2010 07:37:48 -0500
Subject: [coreboot] HELP: Porting i830 RAM init to 440BX,
	now it won't compile
In-Reply-To: <b72cdb061003012139s7db33e45sc2e043c35248e2fd@mail.gmail.com>
References: <b72cdb061003012139s7db33e45sc2e043c35248e2fd@mail.gmail.com>
Message-ID: <1bd580d56d672d268a305d574fdcd6c6@imap.1and1.com>




On Tue, 2 Mar 2010 00:39:12 -0500, Keith Hui <buurin at gmail.com> wrote:
> ramtest.c:6.0: warning: Replacing undefined macro: CONFIG_SSE2 with 0
> ramtest.c:56.0: warning: Replacing undefined macro: CONFIG_SSE2 with 0
> raminit.c:605.46: raminit.c:789.32: romstage.c:96.32:
> 0xd28680 or         Internal compiler error: non dominated rhs use point
> 0xd288d0?
> make: *** [/usr/src/coreboot/build/mainboard/asus/p2b-ls/romstage.inc]
> Aborted
> 
That is a very strange message, sorry I have never seen that before.
> 
> The part of raminit.c that croaks is:
> 
> ...
>             if (value == SPD_MEMORY_TYPE_EDO) {
>                 edosd |= 0x02;
>                 PRINT_DEBUG("EDO");
>             } else if (value == SPD_MEMORY_TYPE_SDRAM) {
>                 edosd |= 0x04;  // <<< ABORT!
>                 PRINT_DEBUG("SDRAM");   // <<< ABORT!
>             }
> ...
> 
Hmm, this looks fine.

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




From rminnich at gmail.com  Tue Mar  2 17:22:39 2010
From: rminnich at gmail.com (ron minnich)
Date: Tue, 2 Mar 2010 16:22:39 +0000
Subject: [coreboot] HELP: Porting i830 RAM init to 440BX,
	now it won't 	compile
In-Reply-To: <b72cdb061003012139s7db33e45sc2e043c35248e2fd@mail.gmail.com>
References: <b72cdb061003012139s7db33e45sc2e043c35248e2fd@mail.gmail.com>
Message-ID: <13426df11003020822k6f63abb8o26e4e7ab6690e6c4@mail.gmail.com>

On Tue, Mar 2, 2010 at 5:39 AM, Keith Hui <buurin at gmail.com> wrote:

> ramtest.c:6.0: warning: Replacing undefined macro: CONFIG_SSE2 with 0
> ramtest.c:56.0: warning: Replacing undefined macro: CONFIG_SSE2 with 0

fix this first. You really want your code to be warning-free.


> ??? ??? ??? ??? edosd |= 0x04;? // <<< ABORT!

did you try just edosd = edosd | 4;

just wondering if it's that simple.

>That's with the clock chip my board uses. Where should this code be
> placed?

depends on the chip I assume. Very, very early is my bet.

>
> The vendor BIOS placed the PIIX4E power management device base port at
> 0xE400, and its SMBus base port at 0xE800. Coreboot has its SMBus base port
> at 0x0F00. If I want to change the base port to match vendor BIOS, where
> should it be made?

Why? We've never seen a need to match these addresses up.

ron



From buurin at gmail.com  Tue Mar  2 17:43:42 2010
From: buurin at gmail.com (Keith Hui)
Date: Tue, 2 Mar 2010 11:43:42 -0500
Subject: [coreboot] HELP: Porting i830 RAM init to 440BX,
	now it won't 	compile
In-Reply-To: <13426df11003020822k6f63abb8o26e4e7ab6690e6c4@mail.gmail.com>
References: <b72cdb061003012139s7db33e45sc2e043c35248e2fd@mail.gmail.com>
	<13426df11003020822k6f63abb8o26e4e7ab6690e6c4@mail.gmail.com>
Message-ID: <b72cdb061003020843t7bbd56a1qe7cfca27d30a042@mail.gmail.com>

On Tue, Mar 2, 2010 at 11:22 AM, ron minnich <rminnich at gmail.com> wrote:

> On Tue, Mar 2, 2010 at 5:39 AM, Keith Hui <buurin at gmail.com> wrote:
>
> > ramtest.c:6.0: warning: Replacing undefined macro: CONFIG_SSE2 with 0
> > ramtest.c:56.0: warning: Replacing undefined macro: CONFIG_SSE2 with 0
>
> fix this first. You really want your code to be warning-free.
>
> I did a search, and the only reference (ie. this ramtest.c) is elsewhere in
the code - src/lib/. That may be used by something else.

>
> >                 edosd |= 0x04;  // <<< ABORT!
>
> did you try just edosd = edosd | 4;
>
> just wondering if it's that simple.
>
> I could try tonight. But I used both notations fearing that romcc doesn't
support more obscure constructs, and both work in other places.


> >That's with the clock chip my board uses. Where should this code be
> > placed?
>
> depends on the chip I assume. Very, very early is my bet.
>
> I'm mean where in the source tree should I put it. Southbridge,
mainboard-specific romstage, or northbridge?


> >
> > The vendor BIOS placed the PIIX4E power management device base port at
> > 0xE400, and its SMBus base port at 0xE800. Coreboot has its SMBus base
> port
> > at 0x0F00. If I want to change the base port to match vendor BIOS, where
> > should it be made?
>
> Why? We've never seen a need to match these addresses up.
>
> So that when I disassemble my coreboot image, I can look at it side by side
with vendor BIOS and check that it's doing the right thing.

I also don't know if there's anything else in the 0x0F00 port range.

This may also become an issue when the ACPI tables in vendor BIOS gets
carried over here and actually gets wired up.

Thanks
Keith
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20100302/f84e8bbf/attachment.html>

From joe at settoplinux.org  Tue Mar  2 18:53:53 2010
From: joe at settoplinux.org (Joseph Smith)
Date: Tue, 02 Mar 2010 12:53:53 -0500
Subject: [coreboot]
 =?utf-8?q?HELP=3A_Porting_i830_RAM_init_to_440BX=2C_no?=
 =?utf-8?q?w_it_won=27t_=09compile?=
In-Reply-To: <b72cdb061003020843t7bbd56a1qe7cfca27d30a042@mail.gmail.com>
References: <b72cdb061003012139s7db33e45sc2e043c35248e2fd@mail.gmail.com>
	<13426df11003020822k6f63abb8o26e4e7ab6690e6c4@mail.gmail.com>
	<b72cdb061003020843t7bbd56a1qe7cfca27d30a042@mail.gmail.com>
Message-ID: <e2b7db155363276aa0adc5fb777c67fd@imap.1and1.com>




On Tue, 2 Mar 2010 11:43:42 -0500, Keith Hui <buurin at gmail.com> wrote:
> On Tue, Mar 2, 2010 at 11:22 AM, ron minnich <rminnich at gmail.com> wrote:
> 
>> On Tue, Mar 2, 2010 at 5:39 AM, Keith Hui <buurin at gmail.com> wrote:
>>
>> > ramtest.c:6.0: warning: Replacing undefined macro: CONFIG_SSE2 with 0
>> > ramtest.c:56.0: warning: Replacing undefined macro: CONFIG_SSE2 with 0
>>
This should be fixed in Kconfig. Probibly in the cpu Kconfig?

>> fix this first. You really want your code to be warning-free.
>>
>> I did a search, and the only reference (ie. this ramtest.c) is elsewhere
> in
> the code - src/lib/. That may be used by something else.
> 
>>
>> >                 edosd |= 0x04;  // <<< ABORT!
>>
>> did you try just edosd = edosd | 4;
>>
>> just wondering if it's that simple.
>>
>> I could try tonight. But I used both notations fearing that romcc
doesn't
> support more obscure constructs, and both work in other places.
> 
hmm
> 
>> >That's with the clock chip my board uses. Where should this code be
>> > placed?
>>
>> depends on the chip I assume. Very, very early is my bet.
>>
>> I'm mean where in the source tree should I put it. Southbridge,
> mainboard-specific romstage, or northbridge?
> 
I would say romstage.c just after early_smbus runs.
> 
>> >
>> > The vendor BIOS placed the PIIX4E power management device base port at
>> > 0xE400, and its SMBus base port at 0xE800. Coreboot has its SMBus base
>> port
>> > at 0x0F00. If I want to change the base port to match vendor BIOS,
> where
>> > should it be made?
>>
>> Why? We've never seen a need to match these addresses up.
>>
>> So that when I disassemble my coreboot image, I can look at it side by
> side
> with vendor BIOS and check that it's doing the right thing.
> 
> I also don't know if there's anything else in the 0x0F00 port range.
> 
> This may also become an issue when the ACPI tables in vendor BIOS gets
> carried over here and actually gets wired up.
> 
I wouldn't worry to much about ACPI now. You have a ways to go before you
get to that point.

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




From rminnich at gmail.com  Tue Mar  2 19:09:30 2010
From: rminnich at gmail.com (ron minnich)
Date: Tue, 2 Mar 2010 10:09:30 -0800
Subject: [coreboot] HELP: Porting i830 RAM init to 440BX,
	now it won't 	compile
In-Reply-To: <b72cdb061003020843t7bbd56a1qe7cfca27d30a042@mail.gmail.com>
References: <b72cdb061003012139s7db33e45sc2e043c35248e2fd@mail.gmail.com>
	<13426df11003020822k6f63abb8o26e4e7ab6690e6c4@mail.gmail.com>
	<b72cdb061003020843t7bbd56a1qe7cfca27d30a042@mail.gmail.com>
Message-ID: <13426df11003021009v6d332948h42a718d964509e99@mail.gmail.com>

On Tue, Mar 2, 2010 at 8:43 AM, Keith Hui <buurin at gmail.com> wrote:

> I'm mean where in the source tree should I put it. Southbridge,
> mainboard-specific romstage, or northbridge?

mainboard. Whether overclocking works, and how well it works, is very
specific to a given mainboard.

ron



From joe at settoplinux.org  Tue Mar  2 23:23:00 2010
From: joe at settoplinux.org (Joseph Smith)
Date: Tue, 02 Mar 2010 17:23:00 -0500
Subject: [coreboot] YABEL debug broken again
Message-ID: <4B8D8FC4.80402@settoplinux.org>

Well it looks like YABEL debug is broken again.....

util/x86emu/yabel/vbe.c:600: error: 'vbe_mode_info_t' has no member 
named 'attributes'
util/x86emu/yabel/vbe.c:604: error: 'vbe_mode_info_t' has no member 
named 'attributes'
util/x86emu/yabel/vbe.c:607: error: 'vbe_mode_info_t' has no member 
named 'attributes'
util/x86emu/yabel/vbe.c:607: error: 'vbe_mode_info_t' has no member 
named 'attributes'
util/x86emu/yabel/vbe.c:612: error: 'vbe_mode_info_t' has no member 
named 'attributes'
util/x86emu/yabel/vbe.c:615: error: 'vbe_mode_info_t' has no member 
named 'attributes'
util/x86emu/yabel/vbe.c:618: error: 'vbe_mode_info_t' has no member 
named 'attributes'
util/x86emu/yabel/vbe.c:621: error: 'vbe_mode_info_t' has no member 
named 'x_resolution'
util/x86emu/yabel/vbe.c:621: error: 'vbe_mode_info_t' has no member 
named 'y_resolution'
util/x86emu/yabel/vbe.c:624: error: 'vbe_mode_info_t' has no member 
named 'x_charsize'
util/x86emu/yabel/vbe.c:624: error: 'vbe_mode_info_t' has no member 
named 'y_charsize'
util/x86emu/yabel/vbe.c:626: error: 'vbe_mode_info_t' has no member 
named 'bits_per_pixel'
util/x86emu/yabel/vbe.c:628: error: 'vbe_mode_info_t' has no member 
named 'memory_model'
util/x86emu/yabel/vbe.c:630: error: 'vbe_mode_info_t' has no member 
named 'framebuffer_address'
util/x86emu/yabel/vbe.c:647: error: 'vbe_mode_info_t' has no member 
named 'x_resolution'
util/x86emu/yabel/vbe.c:647: error: 'vbe_mode_info_t' has no member 
named 'y_resolution'
util/x86emu/yabel/vbe.c:647: error: 'vbe_mode_info_t' has no member 
named 'bits_per_pixel'
util/x86emu/yabel/vbe.c:647: error: 'vbe_mode_info_t' has no member 
named 'framebuffer_address'
make: *** [util/x86emu/yabel/vbe.o] Error 1


last part of buildlog attached. Any ideas?
-- 
Thanks,
Joseph Smith
Set-Top-Linux
www.settoplinux.org
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: buildlog.txt
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20100302/c9f18c5c/attachment.txt>

From joe at settoplinux.org  Tue Mar  2 23:54:37 2010
From: joe at settoplinux.org (Joseph Smith)
Date: Tue, 02 Mar 2010 17:54:37 -0500
Subject: [coreboot] YABEL debug broken again
In-Reply-To: <4B8D8FC4.80402@settoplinux.org>
References: <4B8D8FC4.80402@settoplinux.org>
Message-ID: <832e9bde3adf490cf365995e479733a9@imap.1and1.com>




On Tue, 02 Mar 2010 17:23:00 -0500, Joseph Smith <joe at settoplinux.org>
wrote:
> Well it looks like YABEL debug is broken again.....
> 
> util/x86emu/yabel/vbe.c:600: error: 'vbe_mode_info_t' has no member
> named 'attributes'
> util/x86emu/yabel/vbe.c:604: error: 'vbe_mode_info_t' has no member
> named 'attributes'
> util/x86emu/yabel/vbe.c:607: error: 'vbe_mode_info_t' has no member
> named 'attributes'
> util/x86emu/yabel/vbe.c:607: error: 'vbe_mode_info_t' has no member
> named 'attributes'
> util/x86emu/yabel/vbe.c:612: error: 'vbe_mode_info_t' has no member
> named 'attributes'
> util/x86emu/yabel/vbe.c:615: error: 'vbe_mode_info_t' has no member
> named 'attributes'
> util/x86emu/yabel/vbe.c:618: error: 'vbe_mode_info_t' has no member
> named 'attributes'
> util/x86emu/yabel/vbe.c:621: error: 'vbe_mode_info_t' has no member
> named 'x_resolution'
> util/x86emu/yabel/vbe.c:621: error: 'vbe_mode_info_t' has no member
> named 'y_resolution'
> util/x86emu/yabel/vbe.c:624: error: 'vbe_mode_info_t' has no member
> named 'x_charsize'
> util/x86emu/yabel/vbe.c:624: error: 'vbe_mode_info_t' has no member
> named 'y_charsize'
> util/x86emu/yabel/vbe.c:626: error: 'vbe_mode_info_t' has no member
> named 'bits_per_pixel'
> util/x86emu/yabel/vbe.c:628: error: 'vbe_mode_info_t' has no member
> named 'memory_model'
> util/x86emu/yabel/vbe.c:630: error: 'vbe_mode_info_t' has no member
> named 'framebuffer_address'
> util/x86emu/yabel/vbe.c:647: error: 'vbe_mode_info_t' has no member
> named 'x_resolution'
> util/x86emu/yabel/vbe.c:647: error: 'vbe_mode_info_t' has no member
> named 'y_resolution'
> util/x86emu/yabel/vbe.c:647: error: 'vbe_mode_info_t' has no member
> named 'bits_per_pixel'
> util/x86emu/yabel/vbe.c:647: error: 'vbe_mode_info_t' has no member
> named 'framebuffer_address'
> make: *** [util/x86emu/yabel/vbe.o] Error 1
> 
> 
Appears to be something wrong with the union in structure vbe_mode_info_t
in vbe.c. It points to another structure vesa_mode_info_t, but I am not
sure why it is not working?????


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




From mylesgw at gmail.com  Wed Mar  3 00:14:17 2010
From: mylesgw at gmail.com (Myles Watson)
Date: Tue, 2 Mar 2010 16:14:17 -0700
Subject: [coreboot] YABEL debug broken again
In-Reply-To: <832e9bde3adf490cf365995e479733a9@imap.1and1.com>
References: <4B8D8FC4.80402@settoplinux.org>
	<832e9bde3adf490cf365995e479733a9@imap.1and1.com>
Message-ID: <2831fecf1003021514r7af3a50fjb91429419cb05b77@mail.gmail.com>

> > util/x86emu/yabel/vbe.c:647: error: 'vbe_mode_info_t' has no member
> > named 'framebuffer_address'
> > make: *** [util/x86emu/yabel/vbe.o] Error 1
> >
> >
> Appears to be something wrong with the union in structure vbe_mode_info_t
> in vbe.c. It points to another structure vesa_mode_info_t, but I am not
> sure why it is not working?????
>
It compiles for me with 5132, but not 5135.  You could look at the changes:
http://tracker.coreboot.org/trac/coreboot/changeset/5135

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

From svn at coreboot.org  Wed Mar  3 02:52:53 2010
From: svn at coreboot.org (coreboot)
Date: Wed, 03 Mar 2010 01:52:53 -0000
Subject: [coreboot]  #158: buildrom svn error
Message-ID: <063.eb6713b39494c50916b0c668dc13bc6e@coreboot.org>

#158: buildrom svn error
--------------------------------------------+-------------------------------
    Reporter:  vibert <vib_chr@?>           |         Owner:  stepan@?             
        Type:  defect                       |        Status:  new                  
    Priority:  major                        |     Milestone:                       
   Component:  coreboot                     |      Keywords:                       
Dependencies:                               |   Patchstatus:  there is no patch    
--------------------------------------------+-------------------------------
 Hello,
 I have an error when I build buildrom:svn missing.

 How to correct the problem, thank you.

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


From buurin at gmail.com  Wed Mar  3 04:25:26 2010
From: buurin at gmail.com (Keith Hui)
Date: Tue, 2 Mar 2010 22:25:26 -0500
Subject: [coreboot] HELP: Porting i830 RAM init to 440BX,
	now it won't 	compile
In-Reply-To: <e2b7db155363276aa0adc5fb777c67fd@imap.1and1.com>
References: <b72cdb061003012139s7db33e45sc2e043c35248e2fd@mail.gmail.com>
	<13426df11003020822k6f63abb8o26e4e7ab6690e6c4@mail.gmail.com>
	<b72cdb061003020843t7bbd56a1qe7cfca27d30a042@mail.gmail.com>
	<e2b7db155363276aa0adc5fb777c67fd@imap.1and1.com>
Message-ID: <b72cdb061003021925s62d92832kea794d885534ed0f@mail.gmail.com>

On Tue, Mar 2, 2010 at 12:53 PM, Joseph Smith <joe at settoplinux.org> wrote:

>
>
>
> On Tue, 2 Mar 2010 11:43:42 -0500, Keith Hui <buurin at gmail.com> wrote:
> > On Tue, Mar 2, 2010 at 11:22 AM, ron minnich <rminnich at gmail.com> wrote:
> >
> >> On Tue, Mar 2, 2010 at 5:39 AM, Keith Hui <buurin at gmail.com> wrote:
> >>
> >> > ramtest.c:6.0: warning: Replacing undefined macro: CONFIG_SSE2 with 0
> >> > ramtest.c:56.0: warning: Replacing undefined macro: CONFIG_SSE2 with 0
> >>
> This should be fixed in Kconfig. Probibly in the cpu Kconfig?
>
> >> fix this first. You really want your code to be warning-free.
> >>
> >> I did a search, and the only reference (ie. this ramtest.c) is elsewhere
> > in
> > the code - src/lib/. That may be used by something else.
> >
> >>
> >> >                 edosd |= 0x04;  // <<< ABORT!
> >>
> >> did you try just edosd = edosd | 4;
> >>
> >> just wondering if it's that simple.
> >>
> >> I could try tonight. But I used both notations fearing that romcc
> doesn't
> > support more obscure constructs, and both work in other places.
> >
> hmm
>
I did it - I made the above change (though I doubt it made any difference)
and have to remove the PRINT_DEBUG mentioned in my original email for it to
compile.

Time to boot test.

* Clacks away *

This is the biggest excitement after Canada winning Hockey Gold at the
winter Olympics! (see attached log)

I have 256MB and Linux boots to the login prompt!

I'll formulate a patch later adding this and P2B-LS support.

Cheers
Keith
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20100302/9395b250/attachment.html>
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: coreboot run log 5 p2bls.txt
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20100302/9395b250/attachment.txt>

From joe at settoplinux.org  Wed Mar  3 05:08:30 2010
From: joe at settoplinux.org (Joseph Smith)
Date: Tue, 02 Mar 2010 23:08:30 -0500
Subject: [coreboot] HELP: Porting i830 RAM init to 440BX,
	now it won't compile
In-Reply-To: <b72cdb061003021925s62d92832kea794d885534ed0f@mail.gmail.com>
References: <b72cdb061003012139s7db33e45sc2e043c35248e2fd@mail.gmail.com>
	<13426df11003020822k6f63abb8o26e4e7ab6690e6c4@mail.gmail.com>
	<b72cdb061003020843t7bbd56a1qe7cfca27d30a042@mail.gmail.com>
	<e2b7db155363276aa0adc5fb777c67fd@imap.1and1.com>
	<b72cdb061003021925s62d92832kea794d885534ed0f@mail.gmail.com>
Message-ID: <5ff58a35425db051ddff02864914bbfc@imap.1and1.com>



> I did it - I made the above change (though I doubt it made any
difference)
> and have to remove the PRINT_DEBUG mentioned in my original email for it
to
> compile.
> 
> Time to boot test.
> 
> * Clacks away *
> 
> This is the biggest excitement after Canada winning Hockey Gold at the
> winter Olympics! (see attached log)
> 
> I have 256MB and Linux boots to the login prompt!
> 
> I'll formulate a patch later adding this and P2B-LS support.
> 
That's great! Congrats :-)

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




From joe at settoplinux.org  Wed Mar  3 05:16:05 2010
From: joe at settoplinux.org (Joseph Smith)
Date: Tue, 02 Mar 2010 23:16:05 -0500
Subject: [coreboot] YABEL debug broken again
In-Reply-To: <2831fecf1003021514r7af3a50fjb91429419cb05b77@mail.gmail.com>
References: <4B8D8FC4.80402@settoplinux.org>
	<832e9bde3adf490cf365995e479733a9@imap.1and1.com>
	<2831fecf1003021514r7af3a50fjb91429419cb05b77@mail.gmail.com>
Message-ID: <d0766dd7592b54b6bf7f21f6cf7600d0@imap.1and1.com>




On Tue, 2 Mar 2010 16:14:17 -0700, Myles Watson <mylesgw at gmail.com> wrote:
>> > util/x86emu/yabel/vbe.c:647: error: 'vbe_mode_info_t' has no member
>> > named 'framebuffer_address'
>> > make: *** [util/x86emu/yabel/vbe.o] Error 1
>> >
>> >
>> Appears to be something wrong with the union in structure
vbe_mode_info_t
>> in vbe.c. It points to another structure vesa_mode_info_t, but I am not
>> sure why it is not working?????
>>
> It compiles for me with 5132, but not 5135.  You could look at the
changes:
> http://tracker.coreboot.org/trac/coreboot/changeset/5135
> 
Yes it appears that union inside of the vbe_mode_info_t structure is new.
Is it even ok to put a union inside of a structure?

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




From buurin at gmail.com  Wed Mar  3 05:19:24 2010
From: buurin at gmail.com (Keith Hui)
Date: Tue, 2 Mar 2010 23:19:24 -0500
Subject: [coreboot] [PATCH] ASUS P2B-LS support, RAM detection for 440BX,
	add Slot 1 CPU, Microcode for Intel Tualatin CPUs
Message-ID: <b72cdb061003022019x18ab2b0fo7de47d2d1b0f9609@mail.gmail.com>

Hi all,

This thing is now ready for more exposure. Scratch my previous "patch" -
this is my first real deal.

- Adds Asus P2B-LS mainboard
- Adds RAM detection for i440bx (based on i82830 code). We're no longer hard
coded for 64MB on one row!
- Adds a proper Slot 1 cpu under src/cpu/intel/slot_1. It's a stub copied
from slot_2 but addresses a few FIXMEs. My P2B-LS code refers to this.
- Adds microcode for Intel Tualatin CPUs, cpuid 6B1 and 6B4.* Actually
loading them is pending.

Signed-off-by: Keith Hui <buurin at gmail.com>

Enjoy.

Keith

* Microcodes for all Intel CPUs can be downloaded from Intel -
downloadcenter.intel.com. So TODO for me is to add all microcode updates
from Klamath to Tualatin as the Asus P2B family, with the right mods and/or
adapter, can run anything in between that can fit either Slot 1 or Socket
370.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20100302/4d1896c1/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: p2bls.patch
Type: application/octet-stream
Size: 47277 bytes
Desc: not available
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20100302/4d1896c1/attachment.obj>

From anandbhagwantrao at gmail.com  Wed Mar  3 13:02:20 2010
From: anandbhagwantrao at gmail.com (anand bhagwantrao)
Date: Wed, 3 Mar 2010 17:32:20 +0530
Subject: [coreboot] Details for choice of motherboard
Message-ID: <afd6944b1003030402p70ba2fe0j1954b4ecd4277c0@mail.gmail.com>

Hello frnds..

I want to have coreboot in my motherboard.
pls let me know the same specification motherboard as
Intel BOXDG43NB LGA 775 Intel G43 ATX Intel Motherboard but apart from
Intel.


Thank you all..
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20100303/160ef1a0/attachment.html>

From mylesgw at gmail.com  Wed Mar  3 14:51:34 2010
From: mylesgw at gmail.com (Myles Watson)
Date: Wed, 3 Mar 2010 06:51:34 -0700
Subject: [coreboot] YABEL debug broken again
In-Reply-To: <d0766dd7592b54b6bf7f21f6cf7600d0@imap.1and1.com>
References: <4B8D8FC4.80402@settoplinux.org>
	<832e9bde3adf490cf365995e479733a9@imap.1and1.com>
	<2831fecf1003021514r7af3a50fjb91429419cb05b77@mail.gmail.com>
	<d0766dd7592b54b6bf7f21f6cf7600d0@imap.1and1.com>
Message-ID: <476785AD44234B3F8B89D32B9D6711CA@chimp>

On Tue, 2 Mar 2010 16:14:17 -0700, Myles Watson <mylesgw at gmail.com> wrote:
> >> > util/x86emu/yabel/vbe.c:647: error: 'vbe_mode_info_t' has no member
> >> > named 'framebuffer_address'
> >> > make: *** [util/x86emu/yabel/vbe.o] Error 1
> >> >
> >> >
> >> Appears to be something wrong with the union in structure
> vbe_mode_info_t
> >> in vbe.c. It points to another structure vesa_mode_info_t, but I am not
> >> sure why it is not working?????
> >>
> > It compiles for me with 5132, but not 5135.  You could look at the
> changes:
> > http://tracker.coreboot.org/trac/coreboot/changeset/5135
> >
> Yes it appears that union inside of the vbe_mode_info_t structure is new.
> Is it even ok to put a union inside of a structure?
Yes.  It compiles without debug, right?

If I were you I'd comment out the debugging statements that are breaking for
you, unless you are trying to debug the vbe code.  It looks like
framebuffer_address and friends were commented out in 5135.

Thanks,
Myles





From forevertheuni at gmail.com  Wed Mar  3 15:00:56 2010
From: forevertheuni at gmail.com (Joao Mamede)
Date: Wed, 03 Mar 2010 15:00:56 +0100
Subject: [coreboot] Re  unsuported Motherboard
In-Reply-To: <mailman.728.1267514315.10142.coreboot@coreboot.org>
References: <mailman.728.1267514315.10142.coreboot@coreboot.org>
Message-ID: <4B8E6B98.3090105@gmail.com>



        Joao Mamede wrote:
>         > a socket to plug in a BIOS and buy a BIOS external  writer. Can I
>         > have recommendations on where to buy?
>               

    Peter Stuge wrote:


    What's your budget?

    farnell.com should have PLCC sockets and maybe even flash chips.
    bios-repair.co.uk has flash chips, and maybe PLCC sockets.

    For programmer it would probably be simplest to use another
    mainboard which is compatible with flashrom.

Can we remove BIOS with the machine turned on? Meaning: We boot with the 
good one, we remove it, we insert the second machine chip and flash it. 
Does it work?
About the compatibility, I have a motherboard with a socket that has a 
award BIOS, is the chip/socket the same for AMI? Are they compatible?
I'm sorry for the "noob" questions, but I don't really know much about BIOS.


    Check which flash chip is in the system, if it's an SPI chip then
    your best bet is to order the sockets from bios-repair.co.uk instead,
    I haven't seen SO-8 sockets easily available anywhere else.


    //Peter





From paulepanter at users.sourceforge.net  Wed Mar  3 15:22:22 2010
From: paulepanter at users.sourceforge.net (Paul Menzel)
Date: Wed, 03 Mar 2010 15:22:22 +0100
Subject: [coreboot] Re  unsuported Motherboard
In-Reply-To: <4B8E6B98.3090105@gmail.com>
References: <mailman.728.1267514315.10142.coreboot@coreboot.org>
	<4B8E6B98.3090105@gmail.com>
Message-ID: <1267626142.3691.83.camel@mattotaupa>

Am Mittwoch, den 03.03.2010, 15:00 +0100 schrieb Joao Mamede:

[?]

> Can we remove BIOS with the machine turned on? Meaning: We boot with the 
> good one, we remove it, we insert the second machine chip and flash it. 
> Does it work?

As far as I know, yes! You can for example use push pins for easier
handling[2].

> About the compatibility, I have a motherboard with a socket that has a 
> award BIOS, is the chip/socket the same for AMI? Are they compatible?

As far as I know the BIOS manufacturer has nothing to do with it. It
really just depends on the socket and if the flash chip is supported on
that other system/motherboard.


Thanks,

Paul


[1] http://www.coreboot.org/Developer_Manual/Tools
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: Dies ist ein digital signierter Nachrichtenteil
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20100303/4cf55b31/attachment.sig>

From mylesgw at gmail.com  Wed Mar  3 15:19:03 2010
From: mylesgw at gmail.com (Myles Watson)
Date: Wed, 3 Mar 2010 07:19:03 -0700
Subject: [coreboot] Re  unsuported Motherboard
In-Reply-To: <4B8E6B98.3090105@gmail.com>
References: <mailman.728.1267514315.10142.coreboot@coreboot.org>
	<4B8E6B98.3090105@gmail.com>
Message-ID: <EF6E439CEC0246628E0789DFB2B60922@chimp>

>     For programmer it would probably be simplest to use another
>     mainboard which is compatible with flashrom.
> 
> Can we remove BIOS with the machine turned on? Meaning: We boot with the
> good one, we remove it, we insert the second machine chip and flash it.
> Does it work?
Yes.  This link has pictures of the pushpin method.  It works very well for
PLCC, which are pictured.

http://www.coreboot.org/Developer_Manual/Tools#Chip_removal_tools

The downside is that it will take a long time to try a new design, since you
will have to boot the machine to Linux, flash the new design, and reboot.
Having another machine that is already up will save a lot of time.

> About the compatibility, I have a motherboard with a socket that has a
> award BIOS, is the chip/socket the same for AMI? Are they compatible?
Any BIOS vendor could use any type of chip.  Unfortunately, that won't help
you figure it out.

Thanks,
Myles




From knuku at gap.upv.es  Wed Mar  3 15:32:10 2010
From: knuku at gap.upv.es (Knut Kujat)
Date: Wed, 03 Mar 2010 15:32:10 +0100
Subject: [coreboot] Re  unsuported Motherboard
In-Reply-To: <EF6E439CEC0246628E0789DFB2B60922@chimp>
References: <mailman.728.1267514315.10142.coreboot@coreboot.org>	<4B8E6B98.3090105@gmail.com>
	<EF6E439CEC0246628E0789DFB2B60922@chimp>
Message-ID: <4B8E72EA.1050803@gap.upv.es>

Myles Watson escribi?:
>>     For programmer it would probably be simplest to use another
>>     mainboard which is compatible with flashrom.
>>
>> Can we remove BIOS with the machine turned on? Meaning: We boot with the
>> good one, we remove it, we insert the second machine chip and flash it.
>> Does it work?
>>     
> Yes.  This link has pictures of the pushpin method.  It works very well for
> PLCC, which are pictured.
>
> http://www.coreboot.org/Developer_Manual/Tools#Chip_removal_tools
>
> The downside is that it will take a long time to try a new design, since you
> will have to boot the machine to Linux, flash the new design, and reboot.
> Having another machine that is already up will save a lot of time.
>   

I'm using pushpins and a separate machine for reprogramming the chips
(PLCC) works awesome no problem so far and I'm sure I did reprogram
chips on this board for like 100 times.
>   
>> About the compatibility, I have a motherboard with a socket that has a
>> award BIOS, is the chip/socket the same for AMI? Are they compatible?
>>     
> Any BIOS vendor could use any type of chip.  Unfortunately, that won't help
> you figure it out.
>
> Thanks,
> Myles
>
>
>   
Have you tried flashrom to see which chip is installed?

Bye,
Knut Kujat.




From joe at settoplinux.org  Wed Mar  3 16:00:00 2010
From: joe at settoplinux.org (Joseph Smith)
Date: Wed, 03 Mar 2010 10:00:00 -0500
Subject: [coreboot] YABEL debug broken again
In-Reply-To: <476785AD44234B3F8B89D32B9D6711CA@chimp>
References: <4B8D8FC4.80402@settoplinux.org>
	<832e9bde3adf490cf365995e479733a9@imap.1and1.com>
	<2831fecf1003021514r7af3a50fjb91429419cb05b77@mail.gmail.com>
	<d0766dd7592b54b6bf7f21f6cf7600d0@imap.1and1.com>
	<476785AD44234B3F8B89D32B9D6711CA@chimp>
Message-ID: <963f95957548dc7619cc57c6d7c24699@imap.1and1.com>




On Wed, 3 Mar 2010 06:51:34 -0700, "Myles Watson" <mylesgw at gmail.com>
wrote:
> On Tue, 2 Mar 2010 16:14:17 -0700, Myles Watson <mylesgw at gmail.com>
wrote:
>> >> > util/x86emu/yabel/vbe.c:647: error: 'vbe_mode_info_t' has no member
>> >> > named 'framebuffer_address'
>> >> > make: *** [util/x86emu/yabel/vbe.o] Error 1
>> >> >
>> >> >
>> >> Appears to be something wrong with the union in structure
>> vbe_mode_info_t
>> >> in vbe.c. It points to another structure vesa_mode_info_t, but I am
> not
>> >> sure why it is not working?????
>> >>
>> > It compiles for me with 5132, but not 5135.  You could look at the
>> changes:
>> > http://tracker.coreboot.org/trac/coreboot/changeset/5135
>> >
>> Yes it appears that union inside of the vbe_mode_info_t structure is
new.
>> Is it even ok to put a union inside of a structure?
> Yes.  It compiles without debug, right?
> 
Yes.

> If I were you I'd comment out the debugging statements that are breaking
> for
> you, unless you are trying to debug the vbe code.  It looks like
> framebuffer_address and friends were commented out in 5135.
> 
Well I was kind of looking forward to the vbe debug. Hmm.

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




From mylesgw at gmail.com  Wed Mar  3 16:05:36 2010
From: mylesgw at gmail.com (Myles Watson)
Date: Wed, 3 Mar 2010 08:05:36 -0700
Subject: [coreboot] YABEL debug broken again
In-Reply-To: <963f95957548dc7619cc57c6d7c24699@imap.1and1.com>
References: <4B8D8FC4.80402@settoplinux.org>
	<832e9bde3adf490cf365995e479733a9@imap.1and1.com>
	<2831fecf1003021514r7af3a50fjb91429419cb05b77@mail.gmail.com>
	<d0766dd7592b54b6bf7f21f6cf7600d0@imap.1and1.com>
	<476785AD44234B3F8B89D32B9D6711CA@chimp>
	<963f95957548dc7619cc57c6d7c24699@imap.1and1.com>
Message-ID: <2831fecf1003030705j1caa78e2gbc8363da35bd691a@mail.gmail.com>

> >> > It compiles for me with 5132, but not 5135.  You could look at the
> >> changes:
> >> > http://tracker.coreboot.org/trac/coreboot/changeset/5135
> >> >
> > Yes.  It compiles without debug, right?
> >
> Yes.
>
> > If I were you I'd comment out the debugging statements that are breaking
> > for
> > you, unless you are trying to debug the vbe code.  It looks like
> > framebuffer_address and friends were commented out in 5135.
> >
> Well I was kind of looking forward to the vbe debug. Hmm.
>
You'd still get some information from the debugging statements that work,
but the statements referencing undefined variables are not likely to give
you any good information.

Patrick and Stefan:
Any hints for Joe?

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

From rminnich at gmail.com  Wed Mar  3 17:39:42 2010
From: rminnich at gmail.com (ron minnich)
Date: Wed, 3 Mar 2010 08:39:42 -0800
Subject: [coreboot] HELP: Porting i830 RAM init to 440BX,
	now it won't 	compile
In-Reply-To: <b72cdb061003021925s62d92832kea794d885534ed0f@mail.gmail.com>
References: <b72cdb061003012139s7db33e45sc2e043c35248e2fd@mail.gmail.com>
	<13426df11003020822k6f63abb8o26e4e7ab6690e6c4@mail.gmail.com>
	<b72cdb061003020843t7bbd56a1qe7cfca27d30a042@mail.gmail.com>
	<e2b7db155363276aa0adc5fb777c67fd@imap.1and1.com>
	<b72cdb061003021925s62d92832kea794d885534ed0f@mail.gmail.com>
Message-ID: <13426df11003030839x34f27479k36341c09404589b1@mail.gmail.com>

Keith, Nice job!

I will have to disagree with you about the hockey results though :-)

ron



From gregg.drwho8 at gmail.com  Wed Mar  3 17:13:37 2010
From: gregg.drwho8 at gmail.com (Gregg Levine)
Date: Wed, 3 Mar 2010 11:13:37 -0500
Subject: [coreboot] Details for choice of motherboard
In-Reply-To: <afd6944b1003030402p70ba2fe0j1954b4ecd4277c0@mail.gmail.com>
References: <afd6944b1003030402p70ba2fe0j1954b4ecd4277c0@mail.gmail.com>
Message-ID: <18d205ed1003030813r2bbea90cnff871c39af793a84@mail.gmail.com>

On Wed, Mar 3, 2010 at 7:02 AM, anand bhagwantrao
<anandbhagwantrao at gmail.com> wrote:
> Hello frnds..
>
> I want to have coreboot in my motherboard.
> pls let me know the same specification motherboard as
>
> Intel BOXDG43NB LGA 775 Intel G43 ATX Intel Motherboard
>
> but apart from Intel.
>
>
> Thank you all..
>
>
> --
> coreboot mailing list: coreboot at coreboot.org
> http://www.coreboot.org/mailman/listinfo/coreboot
>

Hello!
More of us will be able to give much more correct answers, but I
believe that particular board is not yet supported. There is a place
on the Coreboot site which describes what is, and what is not.

How new for example is that particular board, do you have the complete
documentation on it, and such like. If you already have Linux running
on it, we'd need to see the output from a command called lspci, and it
would need to be run as lspci -v, followed by running the utilities
that further explain what else is needed.

Right now I'm just writing as the first responder here, more of the
members are more conversant then I with the particulars behind what to
do, and what else gets done.
-----
Gregg C Levine gregg.drwho8 at gmail.com
"This signature fought the Time Wars, time and again."



From uwe at hermann-uwe.de  Wed Mar  3 20:06:44 2010
From: uwe at hermann-uwe.de (Uwe Hermann)
Date: Wed, 3 Mar 2010 20:06:44 +0100
Subject: [coreboot] [PATCH] ASUS P2B-LS support, RAM detection for 440BX,
 add Slot 1 CPU, Microcode for Intel Tualatin CPUs
In-Reply-To: <b72cdb061003022019x18ab2b0fo7de47d2d1b0f9609@mail.gmail.com>
References: <b72cdb061003022019x18ab2b0fo7de47d2d1b0f9609@mail.gmail.com>
Message-ID: <20100303190644.GB13408@greenwood>

Hi Keith,

On Tue, Mar 02, 2010 at 11:19:24PM -0500, Keith Hui wrote:
> This thing is now ready for more exposure. Scratch my previous "patch" -
> this is my first real deal.
> 
> - Adds Asus P2B-LS mainboard
> - Adds RAM detection for i440bx (based on i82830 code). We're no longer hard
> coded for 64MB on one row!
> - Adds a proper Slot 1 cpu under src/cpu/intel/slot_1. It's a stub copied
> from slot_2 but addresses a few FIXMEs. My P2B-LS code refers to this.
> - Adds microcode for Intel Tualatin CPUs, cpuid 6B1 and 6B4.* Actually
> loading them is pending.
> 
> Signed-off-by: Keith Hui <buurin at gmail.com>

Great stuff, thanks a lot!

I'll review and/or test the individual pieces one by one and commit
them as I progress. (small note for the next patch: please split up
the stuff in multiple smaller, independent patches, that makes it
easier to review and test; no need to re-send this patch though).


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



From cmwang at ms1.hinet.net  Thu Mar  4 08:40:19 2010
From: cmwang at ms1.hinet.net (Chi Min Wang)
Date: Thu, 04 Mar 2010 15:40:19 +0800
Subject: [coreboot] MSI K9VGM-V(MS-7253)....
Message-ID: <4B8F63E3.2050201@ms1.hinet.net>

An HTML attachment was scrubbed...
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20100304/f397a66e/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: ms-7253.txt.gz
Type: application/x-gzip
Size: 3903 bytes
Desc: not available
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20100304/f397a66e/attachment.gz>

From paulepanter at users.sourceforge.net  Thu Mar  4 10:49:42 2010
From: paulepanter at users.sourceforge.net (Paul Menzel)
Date: Thu, 04 Mar 2010 10:49:42 +0100
Subject: [coreboot] Details for choice of motherboard
In-Reply-To: <afd6944b1003030402p70ba2fe0j1954b4ecd4277c0@mail.gmail.com>
References: <afd6944b1003030402p70ba2fe0j1954b4ecd4277c0@mail.gmail.com>
Message-ID: <1267696182.9133.35.camel@mattotaupa>

Dear Anand,


Am Mittwoch, den 03.03.2010, 17:32 +0530 schrieb anand bhagwantrao:
> I want to have coreboot in my motherboard.
> pls let me know the same specification motherboard as
> Intel BOXDG43NB LGA 775 Intel G43 ATX Intel Motherboard 
> but apart from Intel.

it would be great if you could list the exact specifications you need
without us looking/searching on the WWW.

Unfortunately as far as I know the code for newer AMD devices is still
under review by the AMD lawyers and has not been published yet.

Rudolf Marek wrote to the list, that he bought an Asrock 939A785GMH/128M
[1]. If it fits your needs, I would suggest to you to buy this or a
similar board since chances are pretty high that as soon as AMD releases
the code Rudolf will implement the support for this board.


Thanks,

Paul


[1] http://www.coreboot.org/pipermail/coreboot/2009-December/054723.html
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: Dies ist ein digital signierter Nachrichtenteil
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20100304/3aec07cb/attachment.sig>

From mark.marshall60 at ntlworld.com  Thu Mar  4 11:05:57 2010
From: mark.marshall60 at ntlworld.com (Mark Marshall)
Date: Thu, 04 Mar 2010 10:05:57 +0000
Subject: [coreboot] [PATCH] ASUS P2B-LS support, RAM detection for 440BX,
 add Slot 1 CPU, Microcode for Intel Tualatin CPUs
In-Reply-To: <b72cdb061003022019x18ab2b0fo7de47d2d1b0f9609@mail.gmail.com>
References: <b72cdb061003022019x18ab2b0fo7de47d2d1b0f9609@mail.gmail.com>
Message-ID: <4B8F8605.7010700@ntlworld.com>

On 03/03/10 04:19, Keith Hui wrote:
> Hi all,
>
> This thing is now ready for more exposure. Scratch my previous "patch" -
> this is my first real deal.
>
> - Adds RAM detection for i440bx (based on i82830 code). We're no longer
> hard coded for 64MB on one row!
Hi.

I've tried this with my ASUS P2B, and it's not quite there yet.

The first problem is that this motherboard only has three DIMM slots. 
This means you have to set SDRAMC to something different; 0x0103 works 
for me.

I'm guessing that we will need a motherboard config option for this - 
there doesn't seem to be one suitable?  Something like:

src/mainboard/asus/p2b/Kconfig:

config DIMM_SOCKETS
	int
	default 3
	depends on BOARD_ASUS_P2B


The second problem is that it doesn't work with more that 256 MB of 
memory.  I've had one stick of 128 MB work, two sticks of 128 MB and one 
stick of 256 MB all work, but two sticks of 256 MB doesn't boot linux.


Has anyone got any idea as to what might be wrong?  If I get the time 
I'll try to boot with the real BIOS and see what that sets the register 
up to in different configs.

This is great work though!

Many thanks,

MM




From mark.marshall60 at ntlworld.com  Thu Mar  4 11:05:57 2010
From: mark.marshall60 at ntlworld.com (Mark Marshall)
Date: Thu, 04 Mar 2010 10:05:57 +0000
Subject: [coreboot] [PATCH] ASUS P2B-LS support, RAM detection for 440BX,
 add Slot 1 CPU, Microcode for Intel Tualatin CPUs
In-Reply-To: <b72cdb061003022019x18ab2b0fo7de47d2d1b0f9609@mail.gmail.com>
References: <b72cdb061003022019x18ab2b0fo7de47d2d1b0f9609@mail.gmail.com>
Message-ID: <4B8F8605.7010700@ntlworld.com>

On 03/03/10 04:19, Keith Hui wrote:
> Hi all,
>
> This thing is now ready for more exposure. Scratch my previous "patch" -
> this is my first real deal.
>
> - Adds RAM detection for i440bx (based on i82830 code). We're no longer
> hard coded for 64MB on one row!
Hi.

I've tried this with my ASUS P2B, and it's not quite there yet.

The first problem is that this motherboard only has three DIMM slots. 
This means you have to set SDRAMC to something different; 0x0103 works 
for me.

I'm guessing that we will need a motherboard config option for this - 
there doesn't seem to be one suitable?  Something like:

src/mainboard/asus/p2b/Kconfig:

config DIMM_SOCKETS
	int
	default 3
	depends on BOARD_ASUS_P2B


The second problem is that it doesn't work with more that 256 MB of 
memory.  I've had one stick of 128 MB work, two sticks of 128 MB and one 
stick of 256 MB all work, but two sticks of 256 MB doesn't boot linux.


Has anyone got any idea as to what might be wrong?  If I get the time 
I'll try to boot with the real BIOS and see what that sets the register 
up to in different configs.

This is great work though!

Many thanks,

MM



From r.marek at assembler.cz  Thu Mar  4 12:56:34 2010
From: r.marek at assembler.cz (Rudolf Marek)
Date: Thu, 04 Mar 2010 12:56:34 +0100
Subject: [coreboot] MSI K9VGM-V(MS-7253)....
In-Reply-To: <4B8F63E3.2050201@ms1.hinet.net>
References: <4B8F63E3.2050201@ms1.hinet.net>
Message-ID: <4B8F9FF2.6040904@assembler.cz>

Hi,
>  Hello everyone: I had a MSI K9VGM-V
> 
<http://www.msi.com/index.php?func=prodmbspec&maincat_no=1&cat2_no=&cat3_no=&prod_no=260>
>  based on VIA K8M890CE/8237A which shoud similar to ASUS M2V-VM except
>  super I/O(W83627EHG vs ITE8712).

>How could I port Coreboot to it??

Well you need to do some basic adjustments described bit 
http://assembler.cz/FOSDEM/porting.pdf

>  And is it possible to make K10(i.e. Athlon II X2/Athlon II X4 which
>  consume less than 95W) to work with it??  Thanks!!

If it fit to the socket then in theory yes, but not sure what changes 
must be made to CPU init.

However there is still one quite big obstacle, the SB VT8237A is not 
VT8237S or VT8237R compatible,
i have the datasheet under NDA, but it would mean to check all register 
settings to see if this chipset implements this same way.

It looks like you will need to treat the VT8237A as "S" variant - all 
PCI ids should be fixed, it could work I can check it in the evening.

I can check all settings but it takes time and you must promise me that 
you will do the port ;)

Rudolf









From uwe at hermann-uwe.de  Thu Mar  4 13:30:06 2010
From: uwe at hermann-uwe.de (Uwe Hermann)
Date: Thu, 4 Mar 2010 13:30:06 +0100
Subject: [coreboot] [PATCH] ASUS P2B-LS support, RAM detection for 440BX,
 add Slot 1 CPU, Microcode for Intel Tualatin CPUs
In-Reply-To: <4B8F8605.7010700@ntlworld.com>
References: <b72cdb061003022019x18ab2b0fo7de47d2d1b0f9609@mail.gmail.com>
	<4B8F8605.7010700@ntlworld.com>
Message-ID: <20100304123006.GC13408@greenwood>

On Thu, Mar 04, 2010 at 10:05:57AM +0000, Mark Marshall wrote:
> On 03/03/10 04:19, Keith Hui wrote:
> >Hi all,
> >
> >This thing is now ready for more exposure. Scratch my previous "patch" -
> >this is my first real deal.
> >
> >- Adds RAM detection for i440bx (based on i82830 code). We're no longer
> >hard coded for 64MB on one row!
> Hi.
> 
> I've tried this with my ASUS P2B, and it's not quite there yet.
> 
> The first problem is that this motherboard only has three DIMM
> slots. This means you have to set SDRAMC to something different;
> 0x0103 works for me.
> 
> I'm guessing that we will need a motherboard config option for this
> - there doesn't seem to be one suitable?  Something like:
> 
> src/mainboard/asus/p2b/Kconfig:
> 
> config DIMM_SOCKETS
> 	int
> 	default 3
> 	depends on BOARD_ASUS_P2B

Yes, sounds good. We will either need this, or maybe the settings can be
auto-detected / probed (need to check datasheet, but I guess it's unlikely).

Hm, seems to be determined by SDRAMPWR + MMCONFIG, and MMCONFIG seems to
be a hardware-strap (so we can check it), but not sure about SDRAMPWR.


> The second problem is that it doesn't work with more that 256 MB of
> memory.  I've had one stick of 128 MB work, two sticks of 128 MB and
> one stick of 256 MB all work, but two sticks of 256 MB doesn't boot
> linux.

Hm, will investigate. Are you sure both 256MB DIMMs work under vendor
BIOS (so we can exclude hardware issues)?

Thanks for testing!


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



From joe at settoplinux.org  Thu Mar  4 13:38:45 2010
From: joe at settoplinux.org (Joseph Smith)
Date: Thu, 04 Mar 2010 07:38:45 -0500
Subject: [coreboot] [PATCH] ASUS P2B-LS support, RAM detection for 440BX,
 add Slot 1 CPU, Microcode for Intel Tualatin CPUs
In-Reply-To: <20100304123006.GC13408@greenwood>
References: <b72cdb061003022019x18ab2b0fo7de47d2d1b0f9609@mail.gmail.com>	<4B8F8605.7010700@ntlworld.com>
	<20100304123006.GC13408@greenwood>
Message-ID: <4B8FA9D5.5050901@settoplinux.org>

On 03/04/2010 07:30 AM, Uwe Hermann wrote:
> On Thu, Mar 04, 2010 at 10:05:57AM +0000, Mark Marshall wrote:
>> On 03/03/10 04:19, Keith Hui wrote:
>>> Hi all,
>>>
>>> This thing is now ready for more exposure. Scratch my previous "patch" -
>>> this is my first real deal.
>>>
>>> - Adds RAM detection for i440bx (based on i82830 code). We're no longer
>>> hard coded for 64MB on one row!
>> Hi.
>>
>> I've tried this with my ASUS P2B, and it's not quite there yet.
>>
>> The first problem is that this motherboard only has three DIMM
>> slots. This means you have to set SDRAMC to something different;
>> 0x0103 works for me.
>>
>> I'm guessing that we will need a motherboard config option for this
>> - there doesn't seem to be one suitable?  Something like:
>>
>> src/mainboard/asus/p2b/Kconfig:
>>
>> config DIMM_SOCKETS
>> 	int
>> 	default 3
>> 	depends on BOARD_ASUS_P2B
>
> Yes, sounds good. We will either need this, or maybe the settings can be
> auto-detected / probed (need to check datasheet, but I guess it's unlikely).
>
> Hm, seems to be determined by SDRAMPWR + MMCONFIG, and MMCONFIG seems to
> be a hardware-strap (so we can check it), but not sure about SDRAMPWR.
>
>
>> The second problem is that it doesn't work with more that 256 MB of
>> memory.  I've had one stick of 128 MB work, two sticks of 128 MB and
>> one stick of 256 MB all work, but two sticks of 256 MB doesn't boot
>> linux.
>
> Hm, will investigate. Are you sure both 256MB DIMMs work under vendor
> BIOS (so we can exclude hardware issues)?
>
> Thanks for testing!
>
One thing I noticed about Keith's code is he didn't impliment the 
initializing one row/side of memory at a time. I think it should really 
be visited, for multiple memory sticks.


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



From joe at settoplinux.org  Thu Mar  4 14:10:01 2010
From: joe at settoplinux.org (Joseph Smith)
Date: Thu, 04 Mar 2010 08:10:01 -0500
Subject: [coreboot] [PATCH] ASUS P2B-LS support, RAM detection for 440BX,
 add Slot 1 CPU, Microcode for Intel Tualatin CPUs
In-Reply-To: <4B8FA9D5.5050901@settoplinux.org>
References: <b72cdb061003022019x18ab2b0fo7de47d2d1b0f9609@mail.gmail.com>	<4B8F8605.7010700@ntlworld.com>	<20100304123006.GC13408@greenwood>
	<4B8FA9D5.5050901@settoplinux.org>
Message-ID: <4B8FB129.3020102@settoplinux.org>

On 03/04/2010 07:38 AM, Joseph Smith wrote:
> On 03/04/2010 07:30 AM, Uwe Hermann wrote:
>> On Thu, Mar 04, 2010 at 10:05:57AM +0000, Mark Marshall wrote:
>>> On 03/03/10 04:19, Keith Hui wrote:
>>>> Hi all,
>>>>
>>>> This thing is now ready for more exposure. Scratch my previous
>>>> "patch" -
>>>> this is my first real deal.
>>>>
>>>> - Adds RAM detection for i440bx (based on i82830 code). We're no longer
>>>> hard coded for 64MB on one row!
>>> Hi.
>>>
>>> I've tried this with my ASUS P2B, and it's not quite there yet.
>>>
>>> The first problem is that this motherboard only has three DIMM
>>> slots. This means you have to set SDRAMC to something different;
>>> 0x0103 works for me.
>>>
>> Hm, seems to be determined by SDRAMPWR + MMCONFIG, and MMCONFIG seems to
>> be a hardware-strap (so we can check it), but not sure about SDRAMPWR.
>>
 >>>
I think a simple SPD probe would work, if the correct value is returned 
you know you have memory in that slot, otherwise if 0xff is returned 
then no memory is present. Do this probe for as many slots as the 440 
supports. Then set your registers based on that.
>>
>>> The second problem is that it doesn't work with more that 256 MB of
>>> memory. I've had one stick of 128 MB work, two sticks of 128 MB and
>>> one stick of 256 MB all work, but two sticks of 256 MB doesn't boot
>>> linux.
>>
>> Hm, will investigate. Are you sure both 256MB DIMMs work under vendor
>> BIOS (so we can exclude hardware issues)?
>>
>> Thanks for testing!
>>
> One thing I noticed about Keith's code is he didn't impliment the
> initializing one row/side of memory at a time. I think it should really
> be visited, for multiple memory sticks.
>
>


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



From joe at settoplinux.org  Thu Mar  4 14:26:57 2010
From: joe at settoplinux.org (Joseph Smith)
Date: Thu, 04 Mar 2010 08:26:57 -0500
Subject: [coreboot] [PATCH] ASUS P2B-LS support, RAM detection for 440BX,
 add Slot 1 CPU, Microcode for Intel Tualatin CPUs
In-Reply-To: <b72cdb061003022019x18ab2b0fo7de47d2d1b0f9609@mail.gmail.com>
References: <b72cdb061003022019x18ab2b0fo7de47d2d1b0f9609@mail.gmail.com>
Message-ID: <4B8FB521.7040503@settoplinux.org>

On 03/02/2010 11:19 PM, Keith Hui wrote:
> Hi all,
>
> This thing is now ready for more exposure. Scratch my previous "patch" -
> this is my first real deal.
>
> - Adds Asus P2B-LS mainboard
> - Adds RAM detection for i440bx (based on i82830 code). We're no longer
> hard coded for 64MB on one row!
> - Adds a proper Slot 1 cpu under src/cpu/intel/slot_1. It's a stub
> copied from slot_2 but addresses a few FIXMEs. My P2B-LS code refers to
> this.
> - Adds microcode for Intel Tualatin CPUs, cpuid 6B1 and 6B4.* Actually
> loading them is pending.
>
> Signed-off-by: Keith Hui <buurin at gmail.com <mailto:buurin at gmail.com>>
>
> Enjoy.
>
> Keith
>
> * Microcodes for all Intel CPUs can be downloaded from Intel -
> downloadcenter.intel.com <http://downloadcenter.intel.com>. So TODO for
> me is to add all microcode updates from Klamath to Tualatin as the Asus
> P2B family, with the right mods and/or adapter, can run anything in
> between that can fit either Slot 1 or Socket 370.
>
>
I would not worry about the microcode updates right now. CAR for Intel 
6bx is coming real soon and the microcode updates will be included :-)

See other comments below.


Index: src/northbridge/intel/i440bx/raminit.c
===================================================================
--- src/northbridge/intel/i440bx/raminit.c	(revision 5184)
+++ src/northbridge/intel/i440bx/raminit.c	(working copy)
@@ -2,6 +2,7 @@
   * This file is part of the coreboot project.
   *
   * Copyright (C) 2007-2008 Uwe Hermann <uwe at hermann-uwe.de>
+ * Copyright (C) 2010 Keith Hui <buurin at gmail.com>
   *
   * 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
@@ -23,6 +24,7 @@
  #include <delay.h>
  #include <stdlib.h>
  #include "i440bx.h"
+#include "raminit.h"

 
/*-----------------------------------------------------------------------------
  Macros and definitions.
@@ -65,12 +67,24 @@
   * [4] == Extended(4x)    62.5 us ->  62.4 us
   * [5] == Extended(8x)     125 us -> 124.8 us
   */
-static const uint32_t refresh_rate_map[] = {
-	1, 5, 5, 2, 3, 4
+static const unsigned int refresh_rate_map[] = {
+	1, 1, 1, 2, 3, 4
  };

  /* Table format: register, bitmask, value. */
  static const long register_values[] = {
+	/* MLT - Master Latency Timer Register
+	 * 0x0d
+	 *
+	 * [07:03] Master Latency Timer Count Value for PCI Bus Access.
+	 *         MLT is an 8-bit register that controls the amount of
+	 *		   time the 82443BX, as a PCI bus master, can burst data
+	 *		   on the PCI Bus. The default value of MLT is 00h and
+	 *		   disables this function. For example, if the MLT is
+	 *		   programmed to 18h, then the value is 24 PCI clocks.
+	 * [02:00] Reserved
+	 */
+	MLT, 0x00, 0x40,
  	/* NBXCFG - NBX Configuration Register
  	 * 0x50 - 0x53
  	 *
@@ -188,14 +202,21 @@
  	 * 10 = Write Only (Writes to DRAM, reads to memory mapped I/O space)
  	 * 11 = Read/Write (all access goes to DRAM)
  	 */
-	// TODO
-	PAM0, 0x00, 0x00,
-	PAM1, 0x00, 0x00,
-	PAM2, 0x00, 0x00,
-	PAM3, 0x00, 0x00,
-	PAM4, 0x00, 0x00,
-	PAM5, 0x00, 0x00,
-	PAM6, 0x00, 0x00,
+	/* Map all legacy regions to RAM (read/write). This is required if
+	 * you want to use the RAM area from 768 KB - 1 MB. If the PAM
+	 * registers are not set here appropriately, the RAM in that region
+	 * will not be accessible, thus a RAM check of it will also fail.
+	
+	 * TODO: This was set in sdram_set_spd_registers()
+	 * Test if it still works when set here
+	 */
+	PAM0, 0x00, 0x30,
+	PAM1, 0x00, 0x33,
+	PAM2, 0x00, 0x33,
+	PAM3, 0x00, 0x33,
+	PAM4, 0x00, 0x33,
+	PAM5, 0x00, 0x33,
+	PAM6, 0x00, 0x33,

  	/* DRB[0:7] - DRAM Row Boundary Registers
  	 * 0x60 - 0x67
@@ -343,6 +364,8 @@
  	// PMCR, 0x00, 0x14,
  	// PMCR, 0x00, 0x10,
  	PMCR, 0x00, 0x00,
+	/* Enable SCRR.SRRAEN and let BX choose the SRR */
+	SCRR+1, 0x00, 0x10,
  };

 
/*-----------------------------------------------------------------------------
@@ -396,7 +419,7 @@

  		dimm_end = pci_read_config8(NB, DRB + i);

-		addr = (dimm_start * 8 * 1024 * 1024) + addr_offset;
+		addr = (dimm_start * 8 * 1048576) + addr_offset;
  		if (dimm_end > dimm_start) {
  #if 0
  			PRINT_DEBUG("    Sending RAM command 0x");
@@ -414,6 +437,22 @@
  	}
  }

+static void set_dram_buffer_strength(void)
+{
+	/* TODO: This needs to be set according to the DRAM tech
+	 * (x8, x16, or x32). Argh, Intel provides no docs on this!
+	 * Currently, it needs to be pulled from the output of
+	 * lspci -xxx Rx92
+	   Relevant registers:
+	 * MBSC
+	 * MBFS, BUFFC
+	 */
+
+	pci_write_config8(NB, MBSC, 0x03);
+
+}
+
+
 
/*-----------------------------------------------------------------------------
  DIMM-independant configuration functions.
 
-----------------------------------------------------------------------------*/
@@ -461,71 +500,305 @@
  		reg &= register_values[i + 1];
  		reg |= register_values[i + 2] & ~(register_values[i + 1]);
  		pci_write_config8(NB, register_values[i], reg);
-
+#if 0
  		PRINT_DEBUG("    Set register 0x");
  		PRINT_DEBUG_HEX8(register_values[i]);
  		PRINT_DEBUG(" to 0x");
  		PRINT_DEBUG_HEX8(reg);
  		PRINT_DEBUG("\r\n");
+#endif
  	}
  }

-static void sdram_set_spd_registers(void)
+/* Copied from i82830 northbridge code */
+struct dimm_size {
+	unsigned long side1;
+	unsigned long side2;
+};
+
+static struct dimm_size spd_get_dimm_size(unsigned device)
  {
-	/* TODO: Don't hardcode the values here, get info via SPD. */
+	struct dimm_size sz;
+	int i, module_density, dimm_banks;
+	sz.side1 = 0;
+	module_density = spd_read_byte(device, SPD_DENSITY_OF_EACH_ROW_ON_MODULE);
+	dimm_banks = spd_read_byte(device, SPD_NUM_DIMM_BANKS);

-	/* Map all legacy regions to RAM (read/write). This is required if
-	 * you want to use the RAM area from 768 KB - 1 MB. If the PAM
-	 * registers are not set here appropriately, the RAM in that region
-	 * will not be accessible, thus a RAM check of it will also fail.
+	/* Find the size of side1. */
+	/* Find the larger value. The larger value is always side1. */
+	for (i = 512; i >= 0; i >>= 1) {
+		if ((module_density & i) == i) {
+			sz.side1 = i;
+			break;
+		}
+	}
+
+	/* Set to 0 in case it's single sided. */
+	sz.side2 = 0;
+
+	/* Test if it's a dual-sided DIMM. */
+	if (dimm_banks > 1) {
+		/* Test to see if there's a second value, if so it's asymmetrical. */
+		if (module_density != i) {
+			/* Find the second value, picking up where we left off. */
+			/* i >>= 1 done initially to make sure we don't get the same value 
again. */
+			for (i >>= 1; i >= 0; i >>= 1) {
+				if (module_density == (sz.side1 | i)) {
+					sz.side2 = i;
+					break;
+				}
+			}
+			/* If not, it's symmetrical */
+		} else {
+			sz.side2 = sz.side1;
+		}
+	}
+
+	/* SPD byte 31 is the memory size divided by 4 so we
+	 * need to muliply by 4 to get the total size.
  	 */
-	pci_write_config8(NB, PAM0, 0x30);
-	pci_write_config8(NB, PAM1, 0x33);
-	pci_write_config8(NB, PAM2, 0x33);
-	pci_write_config8(NB, PAM3, 0x33);
-	pci_write_config8(NB, PAM4, 0x33);
-	pci_write_config8(NB, PAM5, 0x33);
-	pci_write_config8(NB, PAM6, 0x33);
+	sz.side1 *= 4;
+	sz.side2 *= 4;
+	return sz;
+}
+/*
+   Sets DRAM attributes one DIMM at a time, based on SPD data
+   Northbridge settings that got set here:
+
+   NBXCFG[31:24]
+   DRB0-DRB7
+   RPS
+   DRAMC
+ */
+static void set_dram_row_attributes(void)


**********You are setting alot more than just dra here, I would rename 
this function something like sdram_setup_registers().



+{
+	int i, dra, drb, col, width, value, rps, edosd, ecc, nbxecc;
+	u8 bpr; // Top 8 bits of PGPOL
+	
+	edosd = 0;
+	rps = 0;
+	drb = 0;
+	bpr = 0;
+	nbxecc=0xff;
+	
+	for (i = 0; i < DIMM_SOCKETS; i++) {
+		unsigned device;
+		device = DIMM_SPD_BASE + i;
+	   	bpr >>= 2;

-	/* TODO: Set DRB0-DRB7. */
-	/* Currently this is hardcoded to one 64 MB DIMM in slot 0. */
-	pci_write_config8(NB, DRB0, 0x08);
-	pci_write_config8(NB, DRB1, 0x08);
-	pci_write_config8(NB, DRB2, 0x08);
-	pci_write_config8(NB, DRB3, 0x08);
-	pci_write_config8(NB, DRB4, 0x08);
-	pci_write_config8(NB, DRB5, 0x08);
-	pci_write_config8(NB, DRB6, 0x08);
-	pci_write_config8(NB, DRB7, 0x08);
+		/* First check if a DIMM is actually present. */
+		value = spd_read_byte(device, SPD_MEMORY_TYPE);
+		/* This is BX! We do EDO too! */
+		if (value == SPD_MEMORY_TYPE_EDO || value == SPD_MEMORY_TYPE_SDRAM) {

-	/* TODO: Set DRAMC. Don't enable refresh for now. */
-	pci_write_config8(NB, DRAMC, 0x08);
+			PRINT_DEBUG("Found ");
+			if (value == SPD_MEMORY_TYPE_EDO) {
+				edosd |= 0x02;
+			} else if (value == SPD_MEMORY_TYPE_SDRAM) {
+				edosd = edosd | 0x04;
+			}
+			PRINT_DEBUG("DIMM in slot ");
+			PRINT_DEBUG_HEX8(i);
+			PRINT_DEBUG("\r\n");

-	/* TODO: Set RPS. Needs to be fixed for multiple DIMM support. */
-	pci_write_config16(NB, RPS, 0x0001);
+			if (edosd == 0x06) {
+				print_err("Mixing EDO/SDRAM not supported\r\n");
+				die("HALT\r\n");
+			}
+			
+			/* "DRA" is our RPS for the two rows on this DIMM */
+			dra = 0;

+			/* columns */
+			col = spd_read_byte(device, SPD_NUM_COLUMNS);
+
+			/* Is this an ECC DIMM? (Actually this will be a 2 if so) */
+			/* TODO: Other register than NBXCFG also needs this ECC information */
+			ecc = spd_read_byte(device, SPD_DIMM_CONFIG_TYPE);
+			
+			/* data width */
+			width = spd_read_byte(device, SPD_MODULE_DATA_WIDTH_LSB);
+			
+			/* Exclude error checking data width from page size calculations */
+			if (ecc) {
+			   value = spd_read_byte(device, SPD_ERROR_CHECKING_SDRAM_WIDTH);
+			   width -= value;
+			   /* ### ECC */
+			   /* Top 2 bits are clear to help set up NBXCFG */
+			   ecc &= 0x3f;
+			} else {
+			   /* Without ECC, these top 2 bits should be 11 */
+			   ecc |= 0xc0;
+			}
+			
+			/* calculate page size in bits */
+			value = ((1 << col) * width);
+
+			/* convert to Kilobytes */
+			dra = (value >> 13);
+
+			/* # of banks of DIMM (single or double sided) */
+			value = spd_read_byte(device, SPD_NUM_DIMM_BANKS);
+			
+			/* Once we have dra, col is done and can be reused,
+			 * So it's reused for number of banks
+			 */
+			col = spd_read_byte(device, SPD_NUM_BANKS_PER_SDRAM);
+
+			if (value == 1) {
+			   	/* Second bank of 1-bank DIMMs "doesn't have ECC" - or anything */
+				ecc |=0x80;
+				if (dra == 2) {
+				    dra = 0x0; /* 2KB */
+				} else if (dra == 4) {
+					dra = 0x1; /* 4KB */
+				} else if (dra == 8) {
+					dra = 0x2; /* 8KB */
+				} else {
+					dra = -1;
+				}
+				/* Sets a flag in PGPOL[BPR] if this DIMM has 4 banks per row */
+				if (col == 4) {
+					bpr |= 0x40;
+				}
+			} else if (value == 2) {
+				if (dra == 2) {
+				    dra = 0x0; /* 2KB */
+				} else if (dra == 4) {
+					dra = 0x05; /* 4KB */
+				} else if (dra == 8) {
+					dra = 0x0a; /* 8KB */
+				} else {
+					dra = -1;
+				}
+				/* Ditto */
+				if (col == 4) {
+					bpr |= 0xc0;
+				}
+			} else {
+				print_err("# of banks of DIMM not supported\r\n");
+				die("HALT\r\n");
+			}
+			if (dra == -1) {
+				print_err("Page size not supported\r\n");
+				die("HALT\r\n");
+			}
+
+			/* The 440BX supports asymmetrical dual-sided dimms (I can't test 
though)
+			 * but can't handle DIMMs smaller than 8MB per
+			 * side or larger than 128MB per side.
+			 */
+			struct dimm_size sz = spd_get_dimm_size(device);
+			if ((sz.side1 < 8)) {
+				print_err("DIMMs smaller than 8MB per side\r\nare not supported on 
this northbridge\r\n");
+				die("HALT\r\n");
+			}
+			if ((sz.side1 > 128)) {
+				print_err ("DIMMs larger than 128MB per side\r\nare not supported 
on this northbridge\r\n");
+				die("HALT\r\n");
+			}
+			/* - End Memory compatibility checks - */
+
+			/* We need to divide size by 8 to set up the
+			 * DRB registers.
+			 */
+			drb += (sz.side1 / 8);
+			/* Builds the DRB for the next row in MSB so it gets placed in DRB[n+1]
+			 * where it belongs when written as a 16-bit word.
+			 */
+			drb &= 0xff;
+			drb |= (drb + (sz.side2 / 8)) << 8;
+
+		} else {
+#if 0
+			PRINT_DEBUG("No DIMM found in slot ");
+			PRINT_DEBUG_HEX8(i);
+			PRINT_DEBUG("\r\n");
+#endif			
+
+			/* If there's no DIMM in the slot, set dra value to 0x00. */
+			dra = 0x00;
+			ecc = 0xc0;
+			/* Still have to propagate DRB over */
+			drb &= 0xff;
+			drb |= (drb << 8);
+		}
+
+		pci_write_config16(NB, DRB+(2*i), drb);
+#if 0
+		PRINT_DEBUG("DRB has been set to 0x");
+		PRINT_DEBUG_HEX16(drb);
+		PRINT_DEBUG("\r\n");
+#endif		
+			
+		/* Brings the upper DRB back down to be base for
+		 * DRB calculations for the next two rows.
+		 */
+		drb >>= 8;
+			
+		rps |= (dra & 0x0f) << (i*4);
+		nbxecc = (nbxecc >> 2) | (ecc & 0xc0);
+	}
+	/* Set Paging Policy Register */
+	pci_write_config8(NB, PGPOL+1, bpr);
+	PRINT_DEBUG("PGPOL[BPR] has been set to 0x");
+	PRINT_DEBUG_HEX8(bpr);
+	PRINT_DEBUG("\r\n");
+	/* Set DRAM Row Page Size Register */
+	pci_write_config16(NB, RPS, rps);
+	PRINT_DEBUG("RPS has been set to 0x");
+	PRINT_DEBUG_HEX16(rps);
+	PRINT_DEBUG("\r\n");
+	/* ### ECC */
+	pci_write_config8(NB, NBXCFG+3, nbxecc);
+	PRINT_DEBUG("NBXECC[31:24] has been set to 0x");
+	PRINT_DEBUG_HEX8(nbxecc);
+	PRINT_DEBUG("\r\n");
+
+	/* Set DRAMC[4:3] to proper memory type (EDO/SDRAM)
+	 * TODO: Account for registered SDRAM
+	 */
+	edosd &= 0x07;
+	if (edosd & 0x02) {
+	   edosd |= 0x00;
+	} else if (edosd & 0x04) {
+	   edosd |= 0x08;
+	}
+	edosd &= 0x18;
+	/* edosd by now has been transformed to the value needed for DRAMC[4:3] */
+	value = pci_read_config8(NB, DRAMC) & 0xe7;
+	value |= edosd;
+	pci_write_config8(NB, DRAMC, value);
+	PRINT_DEBUG("DRAMC has been set to 0x");
+	PRINT_DEBUG_HEX8(value);
+	PRINT_DEBUG("\r\n");
+	
+}
+
+static void sdram_set_spd_registers(void)
+{
+	/* Setup DRAM Row Boundary Registers and other attributes */
+	set_dram_row_attributes();
+
  	/* TODO: Set SDRAMC. */
  	pci_write_config16(NB, SDRAMC, 0x0010);	/* SDRAMPWR=1: 4 DIMM config */

-	/* TODO: Set PGPOL. */
-	// pci_write_config16(NB, PGPOL, 0x0107);
-	pci_write_config16(NB, PGPOL, 0x0123);
-
-	/* TODO: Set NBXCFG. */
-	// pci_write_config32(NB, NBXCFG, 0x0100220c); // FIXME?
-	pci_write_config32(NB, NBXCFG, 0xff00800c);
-
+	/* TODO */
+	set_dram_buffer_strength();
+	
  	/* TODO: Set PMCR? */
  	// pci_write_config8(NB, PMCR, 0x14);
  	pci_write_config8(NB, PMCR, 0x10);

  	/* TODO? */
-	pci_write_config8(NB, PCI_LATENCY_TIMER, 0x40);
  	pci_write_config8(NB, DRAMT, 0x03);
-	pci_write_config8(NB, MBSC, 0x03);
-	pci_write_config8(NB, SCRR, 0x38);
  }

+static void sdram_set_timing(unsigned int mhz) {
+	   /* TODO */
+
+}
+
  static void sdram_enable(void)
  {
  	int i;

************I also noticed you did not use the memory initialize each 
row/side code from the i830. That code is extremely important for 
multiple memory sticks. Besides that everything else looks really good, 
great work!



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



From knuku at gap.upv.es  Thu Mar  4 15:49:27 2010
From: knuku at gap.upv.es (Knut Kujat)
Date: Thu, 04 Mar 2010 15:49:27 +0100
Subject: [coreboot] Supermicro H8QME-2+ mct_d fatal exit.
In-Reply-To: <4B8BC18D.1050400@gap.upv.es>
References: <4B87CF9D.9060204@gap.upv.es>	<201002261506.46602.christian.leber@ziti.uni-heidelberg.de>	<4B87DEFE.3010604@gap.upv.es>	<20100226154934.5727.qmail@stuge.se>
	<4B8BC18D.1050400@gap.upv.es>
Message-ID: <4B8FC877.4030209@gap.upv.es>

Hello,

I still having trouble with "fatal exit" but now I can reproduce the error:

Let's say I have a board running with vendor BIOS and flashing
coreboot.rom into it with flashrom, so far everything good.
Now I shut the whole system down and turn it on again, and voila
coreboot booting without having problems. And I can shut the system down
like 100 times and boot again with no trouble. Now I unplugging the
board for more than a minute plug it back on and coreboot is unable to
find my installed memory and dies with "No Nodes?!" "mct_d: fatal exit".
In order to make it boot again with coreboot I have to first flash the
vendor BIOS on it and boot it than I can flash and boot coreboot again.
That won't be much trouble with 1 or 2 boards but with more than 10...

I'm thinking that there may be some kind of electrical issue because I
have a board that used to "fatal exit" down in the cluster but up here
in the lab it works  fine without any "unplugging and than not working"
issues. Is there any way to solve this problem? Maybe ram needs more
time to stabilize itself before initializing ?!

Any suggestions ?

Thanks,
Knut Kujat.



From c-d.hailfinger.devel.2006 at gmx.net  Thu Mar  4 16:55:35 2010
From: c-d.hailfinger.devel.2006 at gmx.net (Carl-Daniel Hailfinger)
Date: Thu, 04 Mar 2010 16:55:35 +0100
Subject: [coreboot] GSoC 2010
Message-ID: <4B8FD7F7.7090307@gmx.net>

Hi,

Google Summer of Code 2010 is approaching quickly. I hope
coreboot/flashrom are going to participate again, and to do that, we
have to apply between 2010-03-08 and 2010-03-12 (March 8 - March 12).

Do we want to participate?
Who is willing to mentor?
Any developers who want to apply as students?
Who will serve as organization administrator?
Are there any good ideas for GSoC (coreboot or flashrom)?


Regards,
Carl-Daniel



From marcj303 at gmail.com  Thu Mar  4 18:17:24 2010
From: marcj303 at gmail.com (Marc Jones)
Date: Thu, 4 Mar 2010 10:17:24 -0700
Subject: [coreboot] GSoC 2010
In-Reply-To: <4B8FD7F7.7090307@gmx.net>
References: <4B8FD7F7.7090307@gmx.net>
Message-ID: <534e5dc21003040917u37e5ea7ek5d29f4b73b8dc445@mail.gmail.com>

On Thu, Mar 4, 2010 at 8:55 AM, Carl-Daniel Hailfinger
<c-d.hailfinger.devel.2006 at gmx.net> wrote:
> Hi,
>
> Google Summer of Code 2010 is approaching quickly. I hope
> coreboot/flashrom are going to participate again, and to do that, we
> have to apply between 2010-03-08 and 2010-03-12 (March 8 - March 12).
>
> Do we want to participate?
> Who is willing to mentor?
> Any developers who want to apply as students?
> Who will serve as organization administrator?
> Are there any good ideas for GSoC (coreboot or flashrom)?

I would like for coreboot to do GSoC again. I think it is great
exposure for the project and I would be happy to be a mentor again.
I'll put some thought into what prospective students might work  on.

Marc



-- 
http://se-eng.com



From r.marek at assembler.cz  Thu Mar  4 23:17:35 2010
From: r.marek at assembler.cz (Rudolf Marek)
Date: Thu, 04 Mar 2010 23:17:35 +0100
Subject: [coreboot] MSI K9VGM-V(MS-7253)....
In-Reply-To: <4B8F63E3.2050201@ms1.hinet.net>
References: <4B8F63E3.2050201@ms1.hinet.net>
Message-ID: <4B90317F.6090800@assembler.cz>

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

Hi,

I somehow automated the checks for differences between VT8237S and VT8237A. They
look very very similar. I even hacked a coreboot for you. If we are VERY lucky
it can boot linux ;)

I'm attaching the patch. I put for you whole tree on
assembler.cz/coreboot-K9VGM-V.tgz

You now have to use the board M2V-MX SE, it contains already changed serial.

I generated the image for a flash in build/coreboot.rom

It contains an image with SeaBIOS and needs a serial line on 115200 bauds
connected to see something.

Please try. Be sure you can recover if your image does not work!!!! (like from
bad flash of BIOS) Handy would be second flash and hot swap and burn to new one
(so you can use orig bios as backup solution ;)

Please can you post

lspci -xxx -vvv

Because I'm just unsure about one settings of LPC bridge. Maybe you will need to
change the 0x58 register to some other value then 0x43 see the comment in the patch.

SATA may or may not work don't know. Otherwise it looks promissing, but from now
treat the stuff like nothing works and a lot of things may work ;)

Rudolf






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

iEYEARECAAYFAkuQMX8ACgkQ3J9wPJqZRNVjcgCdGMa0a8+1QWvFIoR+D3gVwu7t
aVMAn05kJXc70t4uWTdzs8gtBzoi1PfM
=wrIm
-----END PGP SIGNATURE-----
-------------- next part --------------
A non-text attachment was scrubbed...
Name: hack_vt8237a.patch
Type: text/x-diff
Size: 7892 bytes
Desc: not available
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20100304/15c2cf72/attachment.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: hack_vt8237a.patch.sig
Type: application/octet-stream
Size: 72 bytes
Desc: not available
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20100304/15c2cf72/attachment.obj>

From ziltro at ziltro.com  Thu Mar  4 23:43:16 2010
From: ziltro at ziltro.com (Andrew Morgan)
Date: Thu, 04 Mar 2010 22:43:16 +0000
Subject: [coreboot] [PATCH] ASUS P2B-LS support, RAM detection for 440BX,
 add Slot 1 CPU, Microcode for Intel Tualatin CPUs
In-Reply-To: <b72cdb061003022019x18ab2b0fo7de47d2d1b0f9609@mail.gmail.com>
References: <b72cdb061003022019x18ab2b0fo7de47d2d1b0f9609@mail.gmail.com>
Message-ID: <4B903784.8050505@ziltro.com>

Hi,

I have been testing this patch on my Soyo SY-6BA+ III, i440BX based.

Good news:
128MB module on its own in any of the 4 slots works.
256MB module works (tested in one slot).
128MB + 128MB works.

Not so good:
128MB + 128MB + 256MB + 128MB boots but only with 512MB RAM. Should add 
up to 640MB. If this is a limitation of the chipset that's fine, but 
maybe it could print a warning message if that is the case?
A single 16MB module did not boot. Log:

------

coreboot-4.0-r5184M-Andrew Thu Mar  4 21:19:28 GMT 2010 starting...
SMBus controller enabled
Northbridge prior to SDRAM init:
PCI: 00:00.00
00: 86 80 90 71 06 00 10 22 03 00 00 06 00 00 00 00
10: 08 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 a0 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: 04 20 00 00 00 00 00 00 03 00 00 00 00 00 00 00
60: 01 01 01 01 01 01 01 01 00 00 00 00 00 00 00 00
70: 00 1f 02 38 00 00 00 00 00 00 00 38 00 00 00 00
80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
90: 80 00 00 00 04 61 00 00 00 05 00 00 00 00 00 00
a0: 02 00 10 00 03 02 00 1f 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 18 0c 00 00 00 00 00 00
d0: 00 00 00 00 00 00 00 00 0c 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 f8 00 00 20 0f 00 00 00 00 00 00
Found DIMM in slot 00
DIMMs larger than 128MB per side
are not supported on this northbridge
HALT

------

But in all that's a very good result, thanks for the work and the patch! 
Now I'm not sure what else I need the vendor BIOS for... :)

-- 

Andrew.




From c-d.hailfinger.devel.2006 at gmx.net  Fri Mar  5 04:03:30 2010
From: c-d.hailfinger.devel.2006 at gmx.net (Carl-Daniel Hailfinger)
Date: Fri, 05 Mar 2010 04:03:30 +0100
Subject: [coreboot] [flashrom] flashrom on non-x86 hosts
Message-ID: <4B907482.1000904@gmx.net>

Hi,

[I wish to apologize for the crossposting, but AFAICS quite a few
coreboot developers are not subscribed to the flashrom list yet.
Followup is set to flashrom at flashrom.org and I'll make sure your replies
will be whitelisted and end up on the flashrom list.]

flashrom has reached a state where pretty much all hardware access is
now done in an OS-independent and hardware-independent way.

Does flashrom still work on non-x86 architectures?

I remember people using it on non-x86, but only PPC is mentioned near
flashrom/flash_and_burn. Endianness might be an issue with the current
code, but since I lack the hardware, I have no way to test.
Please send any test/compile results as reply to this mail, and I'll try
to address any bugs/problems as they turn up.

Thank you!

Regards,
Carl-Daniel



From buurin at gmail.com  Fri Mar  5 06:53:13 2010
From: buurin at gmail.com (Keith Hui)
Date: Fri, 5 Mar 2010 00:53:13 -0500
Subject: [coreboot] [PATCH] ASUS P2B-LS support, RAM detection for 440BX,
	add Slot 1 CPU, Microcode for Intel Tualatin CPUs
In-Reply-To: <4B8FB521.7040503@settoplinux.org>
References: <b72cdb061003022019x18ab2b0fo7de47d2d1b0f9609@mail.gmail.com>
	<4B8FB521.7040503@settoplinux.org>
Message-ID: <b72cdb061003042153j7ca4cf18p8985778a102807f1@mail.gmail.com>

On Thu, Mar 4, 2010 at 8:26 AM, Joseph Smith <joe at settoplinux.org> wrote:

> I would not worry about the microcode updates right now. CAR for Intel 6bx
> is coming real soon and the microcode updates will be included :-)
>
> CAN'T WAIT! :D Then I can say goodbye to the messiness that is romcc, lol.


>
> **********You are setting alot more than just dra here, I would rename this
> function something like sdram_setup_registers().
>
> Good point. Eventually I wanted to name it sdram_initalize() just like
i830, but there are a couple other references to the current names
elsewhere. One step at a time I guess.

>
>
> ************I also noticed you did not use the memory initialize each
> row/side code from the i830. That code is extremely important for multiple
> memory sticks. Besides that everything else looks really good, great work!
>
> There were some code that send RAM commands to the modules in the BX code.
I just kept them around, thinking that this code in i830 may be specific to
i830.

Mark, the problem you saw might be MBFS and MBSC not being set properly. I
have reversed how the factory BIOS programmed them and have the code in my
working copy. I'll see if that makes a difference. We are still hardcoded to
CAS3 latency. One step at a time again I guess.

On another front, with the board running factory BIOS, I dumped the BX's
config space (lspci -s 0:0:0.0 -xxx) with various DIMM configurations,
especially with two sticks in DIMM0&1, DIMM2&3, and 3 sticks. These three
scenarios are where most of the logics are. I can post them if anyone wants
to look at them. All my RAMs are double sided, one 128MB and the others are
256MB.

To figure out how this gets coded for the 3-slot P2B, Someone would need to
reverse the vendor bios for that board or do same as above.

Also, P3B-F has 4 DIMM slots as well.

Thanks
Keith
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20100305/c6ac436d/attachment.html>

From anandbhagwantrao at gmail.com  Fri Mar  5 07:53:16 2010
From: anandbhagwantrao at gmail.com (anand bhagwantrao)
Date: Fri, 5 Mar 2010 12:23:16 +0530
Subject: [coreboot] Hi...all
Message-ID: <afd6944b1003042253q139e636bm2809fced98f4eda8@mail.gmail.com>

Hi all,

Im want to know which IPMI BMC card is supported by Coreboot.
Im building a server where i want both ipmi bmc manageability and coreboot.
If anyone find.....?pls let me know...

Thanks
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20100305/b73af242/attachment.html>

From mark.marshall60 at ntlworld.com  Fri Mar  5 09:03:21 2010
From: mark.marshall60 at ntlworld.com (Mark Marshall)
Date: Fri, 05 Mar 2010 08:03:21 +0000
Subject: [coreboot] [PATCH] ASUS P2B-LS support, RAM detection for 440BX,
 add Slot 1 CPU, Microcode for Intel Tualatin CPUs
In-Reply-To: <4B8FB129.3020102@settoplinux.org>
References: <b72cdb061003022019x18ab2b0fo7de47d2d1b0f9609@mail.gmail.com>	<4B8F8605.7010700@ntlworld.com>	<20100304123006.GC13408@greenwood>
	<4B8FA9D5.5050901@settoplinux.org>
	<4B8FB129.3020102@settoplinux.org>
Message-ID: <4B90BAC9.2090901@ntlworld.com>

On 04/03/10 13:10, Joseph Smith wrote:
> On 03/04/2010 07:38 AM, Joseph Smith wrote:
>> On 03/04/2010 07:30 AM, Uwe Hermann wrote:
>>> On Thu, Mar 04, 2010 at 10:05:57AM +0000, Mark Marshall wrote:
>>>> On 03/03/10 04:19, Keith Hui wrote:
>>>> The first problem is that this motherboard only has three DIMM
>>>> slots. This means you have to set SDRAMC to something different;
>>>> 0x0103 works for me.
>>>>
>>> Hm, seems to be determined by SDRAMPWR + MMCONFIG, and MMCONFIG seems to
>>> be a hardware-strap (so we can check it), but not sure about SDRAMPWR.
>>>
>  >>>
> I think a simple SPD probe would work, if the correct value is returned
> you know you have memory in that slot, otherwise if 0xff is returned
> then no memory is present. Do this probe for as many slots as the 440
> supports. Then set your registers based on that.

The issue here is the number of DIMM slots on the motherboard, not the 
number of sticks in the slots.  Some 440BX boards have four slots, while 
others only have three.

MM



From phueper at hueper.net  Fri Mar  5 10:42:14 2010
From: phueper at hueper.net (Pattrick Hueper)
Date: Fri, 5 Mar 2010 10:42:14 +0100
Subject: [coreboot] YABEL debug broken again
In-Reply-To: <2831fecf1003030705j1caa78e2gbc8363da35bd691a@mail.gmail.com>
References: <4B8D8FC4.80402@settoplinux.org>
	<832e9bde3adf490cf365995e479733a9@imap.1and1.com>
	<2831fecf1003021514r7af3a50fjb91429419cb05b77@mail.gmail.com>
	<d0766dd7592b54b6bf7f21f6cf7600d0@imap.1and1.com>
	<476785AD44234B3F8B89D32B9D6711CA@chimp>
	<963f95957548dc7619cc57c6d7c24699@imap.1and1.com>
	<2831fecf1003030705j1caa78e2gbc8363da35bd691a@mail.gmail.com>
Message-ID: <b5765cdf1003050142o60a1245dt6bf0e52664db39d4@mail.gmail.com>

Hi,

i am trying to get a setup to fix this... but i cant even compile...
in menuconfig for qemu i cant seem to set CONFIG_DEBUG and thus
enabling YABEL_DEBUG breaks the build.
If i manually set CONFIG_DEBUG=y in .config and then run make
oldconfig, CONFIG_DEBUG is unset again.

Help?

Regards, Pattrick



On Wed, Mar 3, 2010 at 4:05 PM, Myles Watson <mylesgw at gmail.com> wrote:
>
>> >> > It compiles for me with 5132, but not 5135. ?You could look at the
>> >> changes:
>> >> > http://tracker.coreboot.org/trac/coreboot/changeset/5135
>> >> >
>> > Yes. ?It compiles without debug, right?
>> >
>> Yes.
>>
>> > If I were you I'd comment out the debugging statements that are breaking
>> > for
>> > you, unless you are trying to debug the vbe code. ?It looks like
>> > framebuffer_address and friends were commented out in 5135.
>> >
>> Well I was kind of looking forward to the vbe debug. Hmm.
>
> You'd still get some information from the debugging statements that work,
> but the statements referencing undefined variables are not likely to give
> you any good information.
>
> Patrick and Stefan:
> Any hints for Joe?
>
> Thanks,
> Myles
>
> --
> coreboot mailing list: coreboot at coreboot.org
> http://www.coreboot.org/mailman/listinfo/coreboot
>



From Zheng.Bao at amd.com  Fri Mar  5 10:29:49 2010
From: Zheng.Bao at amd.com (Bao, Zheng)
Date: Fri, 5 Mar 2010 17:29:49 +0800
Subject: [coreboot] [PATCH] sb600: don't load verb for codec
Message-ID: <DD1CC71B621B004FA76856E5129D6B17038260ED@sbjgexmb1.amd.com>

Don't load verb in BIOS stage. It is not BIOS's responsibility.
And we can not have verb for every single codec.

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

Index: src/southbridge/amd/sb600/sb600_hda.c
===================================================================
--- src/southbridge/amd/sb600/sb600_hda.c	(revision 5184)
+++ src/southbridge/amd/sb600/sb600_hda.c	(working copy)
@@ -90,88 +90,10 @@
 	return 0;
 }
 
-static u32 cim_verb_data[] = {
-	0x01471c10,
-	0x01471d40,
-	0x01471e01,
-	0x01471f01,
-/* 1 */
-	0x01571c12,
-	0x01571d10,
-	0x01571e01,
-	0x01571f01,
-/* 2 */
-	0x01671c11,
-	0x01671d60,
-	0x01671e01,
-	0x01671f01,
-/* 3 */
-	0x01771c14,
-	0x01771d20,
-	0x01771e01,
-	0x01771f01,
-/* 4 */
-	0x01871c30,
-	0x01871d90,
-	0x01871ea1,
-	0x01871f01,
-/* 5 */
-	0x01971cf0,
-	0x01971d11,
-	0x01971e11,
-	0x01971f41,
-/* 6 */
-	0x01a71c80,
-	0x01a71d30,
-	0x01a71e81,
-	0x01a71f01,
-/* 7 */
-	0x01b71cf0,
-	0x01b71d11,
-	0x01b71e11,
-	0x01b71f41,
-/* 8 */
-	0x01c71cf0,
-	0x01c71d11,
-	0x01c71e11,
-	0x01c71f41,
-/* 9 */
-	0x01d71cf0,
-	0x01d71d11,
-	0x01d71e11,
-	0x01d71f41,
-/* 10 */
-	0x01e71c50,
-	0x01e71d11,
-	0x01e71e44,
-	0x01e71f01,
-/* 11 */
-	0x01f71c60,
-	0x01f71d61,
-	0x01f71ec4,
-	0x01f71f01,
-};
-static u32 find_verb(u32 viddid, u32 ** verb)
-{
-	device_t azalia_dev = dev_find_slot(0, PCI_DEVFN(0x14, 2));
-	struct southbridge_amd_sb600_config *cfg =
-	    (struct southbridge_amd_sb600_config
*)azalia_dev->chip_info;
-	printk_debug("Dev=%s\n", dev_path(azalia_dev));
-	printk_debug("Default viddid=%x\n", cfg->hda_viddid);
-	printk_debug("Reading viddid=%x\n", viddid);
-	if (!cfg)
-		return 0;
-	if (viddid != cfg->hda_viddid)
-		return 0;
-	*verb = (u32 *) cim_verb_data;
-	return sizeof(cim_verb_data) / sizeof(u32);
-}
-
 /**
  *  Wait 50usec for for the codec to indicate it is ready
  *  no response would imply that the codec is non-operative
  */
-
 static int wait_for_ready(u8 *base)
 {
 	/* Use a 50 usec timeout - the Linux kernel uses the
@@ -194,7 +116,6 @@
  *  the previous command.  No response would imply that the code
  *  is non-operative
  */
-
 static int wait_for_valid(u8 *base)
 {
 	/* Use a 50 usec timeout - the Linux kernel uses the
@@ -215,9 +136,6 @@
 static void codec_init(u8 * base, int addr)
 {
 	u32 dword;
-	u32 *verb;
-	u32 verb_size;
-	int i;
 
 	/* 1 */
 	if (wait_for_ready(base) == -1)
@@ -232,26 +150,7 @@
 	dword = read32(base + 0x64);
 
 	/* 2 */
-	printk_debug("codec viddid: %08x\n", dword);
-	verb_size = find_verb(dword, &verb);
-
-	if (!verb_size) {
-		printk_debug("No verb!\n");
-		return;
-	}
-
-	printk_debug("verb_size: %d\n", verb_size);
-	/* 3 */
-	for (i = 0; i < verb_size; i++) {
-		if (wait_for_ready(base) == -1)
-			return;
-
-		write32(base + 0x60, verb[i]);
-
-		if (wait_for_valid(base) == -1)
-			return;
-	}
-	printk_debug("verb loaded!\n");
+	printk_debug("%x(th) codec viddid: %08x\n", addr, dword);
 }
 
 static void codecs_init(u8 * base, u32 codec_mask)
-------------- next part --------------
A non-text attachment was scrubbed...
Name: sb600_dont_load_verb.patch
Type: application/octet-stream
Size: 2969 bytes
Desc: sb600_dont_load_verb.patch
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20100305/cb227dc8/attachment.obj>

From svn at coreboot.org  Fri Mar  5 11:03:51 2010
From: svn at coreboot.org (repository service)
Date: Fri, 05 Mar 2010 11:03:51 +0100
Subject: [coreboot] [commit] r5185 - in trunk: src src/console
	src/cpu/x86/smm src/devices src/mainboard/amd/dbm690t
	src/mainboard/amd/pistachio
	src/mainboard/amd/serengeti_cheetah_fam10
	src/mainboard/asus/a8n_e src/m...
Message-ID: <E1NnUNr-0000kG-Dr@ra.coresystems.de>

Author: stepan
Date: Fri Mar  5 11:03:50 2010
New Revision: 5185
URL: http://tracker.coreboot.org/trac/coreboot/changeset/5185

Log:
This patch is from 2009-10-20

Convert all DEBUG_SMBUS, DEBUG_SMI, and DEBUG_RAM_SETUP custom and
local #defines into globally configurable kconfig options (and Options.lb
options for as long as newconfig still exists) which can be enabled
by the user in the "Debugging" menu.

The respective menu items only appear if a board is selected where the
chipset code actually provides such additional DEBUG output.

All three variables default to 0 / off for now.

Also, drop a small chunk of dead/useless code in the
src/northbridge/via/cn700/raminit.c file, which would otherwise break
compilation.

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

Reworked to still apply to trunk, added X86EMU_DEBUG (and make the x86emu/yabel
code only work printf instead of a redefined version of printk and 
Acked-by: Stefan Reinauer <stepan at coresystems.de>

Modified:
   trunk/src/Kconfig
   trunk/src/console/printk.c
   trunk/src/cpu/x86/smm/smihandler.c
   trunk/src/cpu/x86/smm/smiutil.c
   trunk/src/devices/Kconfig
   trunk/src/mainboard/amd/dbm690t/romstage.c
   trunk/src/mainboard/amd/pistachio/romstage.c
   trunk/src/mainboard/amd/serengeti_cheetah_fam10/romstage.c
   trunk/src/mainboard/asus/a8n_e/romstage.c
   trunk/src/mainboard/asus/a8v-e_se/romstage.c
   trunk/src/mainboard/asus/m2v-mx_se/romstage.c
   trunk/src/mainboard/kontron/986lcd-m/romstage.c
   trunk/src/mainboard/msi/ms7135/romstage.c
   trunk/src/mainboard/msi/ms7260/romstage.c
   trunk/src/mainboard/msi/ms9185/romstage.c
   trunk/src/mainboard/msi/ms9282/romstage.c
   trunk/src/northbridge/amd/amdfam10/debug.c
   trunk/src/northbridge/amd/amdfam10/raminit_amdmct.c
   trunk/src/northbridge/amd/amdk8/debug.c
   trunk/src/northbridge/amd/amdk8/raminit_f.c
   trunk/src/northbridge/intel/e7501/raminit.c
   trunk/src/northbridge/intel/i440bx/raminit.c
   trunk/src/northbridge/intel/i82810/raminit.c
   trunk/src/northbridge/intel/i82830/raminit.c
   trunk/src/northbridge/intel/i945/raminit.c
   trunk/src/northbridge/via/cn700/raminit.c
   trunk/src/northbridge/via/cx700/cx700_early_smbus.c
   trunk/src/northbridge/via/cx700/raminit.c
   trunk/src/northbridge/via/vx800/raminit.c
   trunk/src/northbridge/via/vx800/vx800_early_smbus.c
   trunk/src/southbridge/intel/i82801gx/i82801gx_smihandler.c
   trunk/src/southbridge/via/vt8237r/vt8237r.h
   trunk/util/x86emu/include/x86emu/fpu_regs.h
   trunk/util/x86emu/include/x86emu/regs.h
   trunk/util/x86emu/include/x86emu/x86emu.h
   trunk/util/x86emu/x86.c
   trunk/util/x86emu/x86_interrupts.c
   trunk/util/x86emu/x86emu/debug.c
   trunk/util/x86emu/x86emu/debug.h
   trunk/util/x86emu/x86emu/decode.c
   trunk/util/x86emu/x86emu/fpu.c
   trunk/util/x86emu/x86emu/ops.c
   trunk/util/x86emu/x86emu/ops2.c
   trunk/util/x86emu/x86emu/sys.c
   trunk/util/x86emu/x86emu/x86emui.h
   trunk/util/x86emu/yabel/biosemu.c
   trunk/util/x86emu/yabel/biosemu.h
   trunk/util/x86emu/yabel/compat/functions.c
   trunk/util/x86emu/yabel/debug.h
   trunk/util/x86emu/yabel/device.c
   trunk/util/x86emu/yabel/interrupt.c
   trunk/util/x86emu/yabel/io.c
   trunk/util/x86emu/yabel/mem.c
   trunk/util/x86emu/yabel/vbe.c

Modified: trunk/src/Kconfig
==============================================================================
--- trunk/src/Kconfig	Mon Mar  1 21:16:38 2010	(r5184)
+++ trunk/src/Kconfig	Fri Mar  5 11:03:50 2010	(r5185)
@@ -609,6 +609,190 @@
 	  If enabled, you will be able to set breakpoints for gdb debugging.
 	  See src/arch/i386/lib/c_start.S for details.
 
+config DEBUG_RAM_SETUP
+	bool "Output verbose RAM init debug messages"
+	default n
+	depends on (NORTHBRIDGE_AMD_AMDFAM10 \
+		 || NORTHBRIDGE_AMD_AMDK8 \
+		 || NORTHBRIDGE_VIA_CN700 \
+		 || NORTHBRIDGE_VIA_CX700 \
+		 || NORTHBRIDGE_VIA_VX800 \
+		 || NORTHBRIDGE_INTEL_E7501 \
+		 || NORTHBRIDGE_INTEL_I440BX \
+		 || NORTHBRIDGE_INTEL_I82810 \
+		 || NORTHBRIDGE_INTEL_I82830 \
+		 || NORTHBRIDGE_INTEL_I945)
+	help
+	  This option enables additional RAM init related debug messages.
+	  It is recommended to enable this when debugging issues on your
+	  board which might be RAM init related.
+
+	  Note: This option will increase the size of the coreboot image.
+
+	  If unsure, say N.
+
+config DEBUG_SMBUS
+	bool "Output verbose SMBus debug messages"
+	default n
+	depends on (SOUTHBRIDGE_VIA_VT8237R \
+		 || NORTHBRIDGE_VIA_VX800 \
+		 || NORTHBRIDGE_VIA_CX700 \
+		 || NORTHBRIDGE_AMD_AMDK8)
+	help
+	  This option enables additional SMBus (and SPD) debug messages.
+
+	  Note: This option will increase the size of the coreboot image.
+
+	  If unsure, say N.
+
+config DEBUG_SMI
+	bool "Output verbose SMI debug messages"
+	default n
+	depends on HAVE_SMI_HANDLER
+	help
+	  This option enables additional SMI related debug messages.
+
+	  Note: This option will increase the size of the coreboot image.
+
+	  If unsure, say N.
+
+config X86EMU_DEBUG
+	bool "Output verbose x86emu debug messages"
+	default n
+	depends on PCI_OPTION_ROM_RUN_YABEL
+	help
+	  This option enables additional x86emu related debug messages.
+
+	  Note: This option will increase the size of the coreboot image.
+
+	  If unsure, say N.
+
+config X86EMU_DEBUG_JMP
+	bool "Trace JMP/RETF"
+	default n
+	depends on X86EMU_DEBUG
+	help
+	  Print information about JMP and RETF opcodes from x86emu.
+
+	  Note: This option will increase the size of the coreboot image.
+
+	  If unsure, say N.
+
+config X86EMU_DEBUG_TRACE
+	bool "Trace all opcodes"
+	default n
+	depends on X86EMU_DEBUG
+	help
+	  Print _all_ opcodes that are executed by x86emu.
+	  
+	  WARNING: This will produce a LOT of output and take a long time.
+
+	  Note: This option will increase the size of the coreboot image.
+
+	  If unsure, say N.
+
+config X86EMU_DEBUG_PNP
+	bool "Log Plug&Play accesses"
+	default n
+	depends on X86EMU_DEBUG
+	help
+	  Print Plug And Play accesses made by option ROMs.
+
+	  Note: This option will increase the size of the coreboot image.
+
+	  If unsure, say N.
+
+config X86EMU_DEBUG_DISK
+	bool "Log Disk I/O"
+	default n
+	depends on X86EMU_DEBUG
+	help
+	  Print Disk I/O related messages.
+
+	  Note: This option will increase the size of the coreboot image.
+
+	  If unsure, say N.
+
+config X86EMU_DEBUG_PMM
+	bool "Log PMM"
+	default n
+	depends on X86EMU_DEBUG
+	help
+	  Print messages related to POST Memory Manager (PMM).
+
+	  Note: This option will increase the size of the coreboot image.
+
+	  If unsure, say N.
+
+
+config X86EMU_DEBUG_VBE
+	bool "Debug VESA BIOS Extensions"
+	default n
+	depends on X86EMU_DEBUG
+	help
+	  Print messages related to VESA BIOS Extension (VBE) functions.
+
+	  Note: This option will increase the size of the coreboot image.
+
+	  If unsure, say N.
+
+config X86EMU_DEBUG_INT10
+	bool "Redirect INT10 output to console"
+	default n
+	depends on X86EMU_DEBUG
+	help
+	  Let INT10 (i.e. character output) calls print messages to debug output.
+
+	  Note: This option will increase the size of the coreboot image.
+
+	  If unsure, say N.
+
+config X86EMU_DEBUG_INTERRUPTS
+	bool "Log intXX calls"
+	default n
+	depends on X86EMU_DEBUG
+	help
+	  Print messages related to interrupt handling.
+
+	  Note: This option will increase the size of the coreboot image.
+
+	  If unsure, say N.
+
+config X86EMU_DEBUG_CHECK_VMEM_ACCESS
+	bool "Log special memory accesses"
+	default n
+	depends on X86EMU_DEBUG
+	help
+	  Print messages related to accesses to certain areas of the virtual
+	  memory (e.g. BDA (BIOS Data Area) or interrupt vectors)
+
+	  Note: This option will increase the size of the coreboot image.
+
+	  If unsure, say N.
+
+config X86EMU_DEBUG_MEM
+	bool "Log all memory accesses"
+	default n
+	depends on X86EMU_DEBUG
+	help
+	  Print memory accesses made by option ROM.
+	  Note: This also includes accesses to fetch instructions.
+
+	  Note: This option will increase the size of the coreboot image.
+
+	  If unsure, say N.
+
+config X86EMU_DEBUG_IO
+	bool "Log IO accesses"
+	default n
+	depends on X86EMU_DEBUG
+	help
+	  Print I/O accesses made by option ROM.
+
+	  Note: This option will increase the size of the coreboot image.
+
+	  If unsure, say N.
+
 endmenu
 
 config LIFT_BSP_APIC_ID

Modified: trunk/src/console/printk.c
==============================================================================
--- trunk/src/console/printk.c	Mon Mar  1 21:16:38 2010	(r5184)
+++ trunk/src/console/printk.c	Fri Mar  5 11:03:50 2010	(r5185)
@@ -19,8 +19,6 @@
 /* Keep together for sysctl support */
 
 int console_loglevel = CONFIG_DEFAULT_CONSOLE_LOGLEVEL;
-int default_message_loglevel = DEFAULT_MESSAGE_LOGLEVEL;
-int minimum_console_loglevel = MINIMUM_CONSOLE_LOGLEVEL;
 int default_console_loglevel = CONFIG_DEFAULT_CONSOLE_LOGLEVEL;
 
 DECLARE_SPIN_LOCK(console_lock)

Modified: trunk/src/cpu/x86/smm/smihandler.c
==============================================================================
--- trunk/src/cpu/x86/smm/smihandler.c	Mon Mar  1 21:16:38 2010	(r5184)
+++ trunk/src/cpu/x86/smm/smihandler.c	Fri Mar  5 11:03:50 2010	(r5185)
@@ -27,8 +27,6 @@
 
 void southbridge_smi_set_eos(void);
 
-/* To enable SMI define DEBUG_SMI in smiutil.c */
-
 typedef enum { SMI_LOCKED, SMI_UNLOCKED } smi_semaphore;
 
 /* SMI multiprocessing semaphore */

Modified: trunk/src/cpu/x86/smm/smiutil.c
==============================================================================
--- trunk/src/cpu/x86/smm/smiutil.c	Mon Mar  1 21:16:38 2010	(r5184)
+++ trunk/src/cpu/x86/smm/smiutil.c	Fri Mar  5 11:03:50 2010	(r5185)
@@ -25,8 +25,6 @@
 #include <cpu/x86/cache.h>
 #include <cpu/x86/smm.h>
 
-// #define DEBUG_SMI
-
 /* ********************* smi_util ************************* */
 
 /* Data */
@@ -119,7 +117,7 @@
 
 void console_init(void)
 {
-#ifdef DEBUG_SMI
+#if CONFIG_DEBUG_SMI
 	console_loglevel = CONFIG_DEFAULT_CONSOLE_LOGLEVEL;
 	uart_init();
 #else

Modified: trunk/src/devices/Kconfig
==============================================================================
--- trunk/src/devices/Kconfig	Mon Mar  1 21:16:38 2010	(r5184)
+++ trunk/src/devices/Kconfig	Fri Mar  5 11:03:50 2010	(r5185)
@@ -74,63 +74,6 @@
 
 endchoice
 
-# TODO: Describe better, and/or make a "choice" selection for this.
-config YABEL_DEBUG_FLAGS
-	prompt "Hex value for YABEL debug flags"
-	hex
-	default 0x0
-	depends on PCI_OPTION_ROM_RUN_YABEL
-	help
-	  CONFIG_YABEL_DEBUG_FLAGS is a binary switch that allows you
-	  to select the following items to debug. 1=on 0=off. After you
-	  decide what you want to debug create the binary value, convert to
-	  hex and set the option.
-
-	  Example for "debug all":
-	    CONFIG_YABEL_DEBUG_FLAGS = 0x31FF
-
-	  |-DEBUG_JMP - Print info about JMP and RETF opcodes from x86emu
-	  ||-DEBUG_TRACE_X86EMU - Print _all_ opcodes that are executed by
-	  ||                      x86emu (WARNING: this will produce a LOT
-	  ||                      of output)
-	  |||-Currently unused
-	  ||||-Currently unused
-	  |||||-Currently unused
-	  ||||||-DEBUG_PNP - Print Plug And Play accesses made by option ROM
-	  |||||||-DEBUG_DISK - Print Disk I/O related messages, currently unused
-	  ||||||||-DEBUG_PMM - Print messages related to POST Memory
-	  ||||||||             Manager (PMM)
-	  |||||||||-DEBUG_VBE - Print messages related to VESA BIOS Extension
-	  |||||||||             (VBE) functions
-	  ||||||||||-DEBUG_PRINT_INT10 - Let INT10 (i.e. character output)
-	  ||||||||||                     calls print messages to debug output
-	  |||||||||||-DEBUG_INTR - Print messages related to interrupt handling
-	  ||||||||||||-DEBUG_CHECK_VMEM_ACCESS - Print messages related to
-	  ||||||||||||                           accesses to certain areas of
-	  ||||||||||||                           the virtual memory (e.g. BDA
-	  ||||||||||||                           (BIOS Data Area) or interrupt
-	  ||||||||||||                           vectors)
-	  |||||||||||||-DEBUG_MEM - Print memory accesses made by option ROM
-	  |||||||||||||             (NOTE: this also includes accesses to
-	  |||||||||||||             fetch instructions)
-	  ||||||||||||||-DEBUG_IO - Print I/O accesses made by option ROM
-	  11000111111111 - Maximum binary value, i.e. "debug all"
-	                   (WARNING: This could run for hours)
-
-	  DEBUG_IO			0x0001
-	  DEBUG_MEM			0x0002
-	  DEBUG_CHECK_VMEM_ACCESS	0x0004
-	  DEBUG_INTR			0x0008
-	  DEBUG_PRINT_INT10		0x0010
-	  DEBUG_VBE			0x0020
-	  DEBUG_PMM			0x0040
-	  DEBUG_DISK			0x0080
-	  DEBUG_PNP			0x0100
-	  DEBUG_TRACE_X86EMU		0x1000
-	  DEBUG_JMP			0x2000
-
-	  See debug.h for values. 0 is no debug output, 0x31ff is _verbose_.
-
 config YABEL_PCI_ACCESS_OTHER_DEVICES
 	prompt "Allow option ROMs to access other devices"
 	bool
@@ -150,6 +93,11 @@
 	  YABEL requires 1MB memory for its CPU emulation. This memory is
 	  normally located at 16MB.
 
+config YABEL_VIRTMEM_LOCATION
+	hex
+	depends on PCI_OPTION_ROM_RUN_YABEL && !EXPERT
+	default 0x1000000
+
 config YABEL_DIRECTHW
 	prompt "Direct hardware access"
 	bool

Modified: trunk/src/mainboard/amd/dbm690t/romstage.c
==============================================================================
--- trunk/src/mainboard/amd/dbm690t/romstage.c	Mon Mar  1 21:16:38 2010	(r5184)
+++ trunk/src/mainboard/amd/dbm690t/romstage.c	Fri Mar  5 11:03:50 2010	(r5185)
@@ -57,7 +57,6 @@
 
 #include "cpu/x86/lapic/boot_cpu.c"
 #include "northbridge/amd/amdk8/reset_test.c"
-#include "northbridge/amd/amdk8/debug.c"
 #include "superio/ite/it8712f/it8712f_early_serial.c"
 
 #include "cpu/amd/mtrr/amd_earlymtrr.c"
@@ -67,6 +66,7 @@
 
 #include "southbridge/amd/rs690/rs690_early_setup.c"
 #include "southbridge/amd/sb600/sb600_early_setup.c"
+#include "northbridge/amd/amdk8/debug.c" /* After sb600_early_setup.c! */
 
 /* CAN'T BE REMOVED! crt0.S will use it. I don't know WHY!*/
 static void memreset(int controllers, const struct mem_controller *ctrl)

Modified: trunk/src/mainboard/amd/pistachio/romstage.c
==============================================================================
--- trunk/src/mainboard/amd/pistachio/romstage.c	Mon Mar  1 21:16:38 2010	(r5184)
+++ trunk/src/mainboard/amd/pistachio/romstage.c	Fri Mar  5 11:03:50 2010	(r5185)
@@ -51,7 +51,6 @@
 
 #include "cpu/x86/lapic/boot_cpu.c"
 #include "northbridge/amd/amdk8/reset_test.c"
-#include "northbridge/amd/amdk8/debug.c"
 #include "superio/ite/it8712f/it8712f_early_serial.c"
 
 #include "cpu/amd/mtrr/amd_earlymtrr.c"
@@ -61,6 +60,7 @@
 
 #include "southbridge/amd/rs690/rs690_early_setup.c"
 #include "southbridge/amd/sb600/sb600_early_setup.c"
+#include "northbridge/amd/amdk8/debug.c" /* After sb600_early_setup.c! */
 
 /* CAN'T BE REMOVED! crt0.S will use it. I don't know WHY!*/
 static void memreset(int controllers, const struct mem_controller *ctrl)

Modified: trunk/src/mainboard/amd/serengeti_cheetah_fam10/romstage.c
==============================================================================
--- trunk/src/mainboard/amd/serengeti_cheetah_fam10/romstage.c	Mon Mar  1 21:16:38 2010	(r5184)
+++ trunk/src/mainboard/amd/serengeti_cheetah_fam10/romstage.c	Fri Mar  5 11:03:50 2010	(r5185)
@@ -29,8 +29,6 @@
 #define RAMINIT_SYSINFO 1
 #define CACHE_AS_RAM_ADDRESS_DEBUG 1
 
-#define DEBUG_SMBUS 1
-
 #define SET_NB_CFG_54 1
 
 //used by raminit

Modified: trunk/src/mainboard/asus/a8n_e/romstage.c
==============================================================================
--- trunk/src/mainboard/asus/a8n_e/romstage.c	Mon Mar  1 21:16:38 2010	(r5184)
+++ trunk/src/mainboard/asus/a8n_e/romstage.c	Fri Mar  5 11:03:50 2010	(r5185)
@@ -30,9 +30,6 @@
 /* Used by raminit. */
 #define QRANK_DIMM_SUPPORT 1
 
-/* Turn this on for SMBus debugging output. */
-#define DEBUG_SMBUS 0
-
 #if CONFIG_LOGICAL_CPUS == 1
 #define SET_NB_CFG_54 1
 #endif

Modified: trunk/src/mainboard/asus/a8v-e_se/romstage.c
==============================================================================
--- trunk/src/mainboard/asus/a8v-e_se/romstage.c	Mon Mar  1 21:16:38 2010	(r5184)
+++ trunk/src/mainboard/asus/a8v-e_se/romstage.c	Fri Mar  5 11:03:50 2010	(r5185)
@@ -40,8 +40,6 @@
 /* If we want to wait for core1 done before DQS training, set it to 0. */
 #define K8_SET_FIDVID_CORE0_ONLY 1
 
-/* #define DEBUG_SMBUS 1 */
-
 #include <stdint.h>
 #include <string.h>
 #include <device/pci_def.h>
@@ -59,10 +57,10 @@
 #include "lib/delay.c"
 #include "cpu/x86/lapic/boot_cpu.c"
 #include "northbridge/amd/amdk8/reset_test.c"
-#include "northbridge/amd/amdk8/debug.c"
 #include "northbridge/amd/amdk8/early_ht.c"
 #include "superio/winbond/w83627ehg/w83627ehg_early_serial.c"
 #include "southbridge/via/vt8237r/vt8237r_early_smbus.c"
+#include "northbridge/amd/amdk8/debug.c" /* After vt8237r_early_smbus.c! */
 #include "cpu/amd/mtrr/amd_earlymtrr.c"
 #include "cpu/x86/bist.h"
 #include "northbridge/amd/amdk8/setup_resource_map.c"

Modified: trunk/src/mainboard/asus/m2v-mx_se/romstage.c
==============================================================================
--- trunk/src/mainboard/asus/m2v-mx_se/romstage.c	Mon Mar  1 21:16:38 2010	(r5184)
+++ trunk/src/mainboard/asus/m2v-mx_se/romstage.c	Fri Mar  5 11:03:50 2010	(r5185)
@@ -44,8 +44,6 @@
 #define K8_REV_F_SUPPORT_F0_F1_WORKAROUND 0
 #endif
 
-/* #define DEBUG_SMBUS 1 */
-
 #include <stdint.h>
 #include <string.h>
 #include <device/pci_def.h>

Modified: trunk/src/mainboard/kontron/986lcd-m/romstage.c
==============================================================================
--- trunk/src/mainboard/kontron/986lcd-m/romstage.c	Mon Mar  1 21:16:38 2010	(r5184)
+++ trunk/src/mainboard/kontron/986lcd-m/romstage.c	Fri Mar  5 11:03:50 2010	(r5185)
@@ -445,7 +445,7 @@
 
 #if !CONFIG_HAVE_ACPI_RESUME
 #if CONFIG_DEFAULT_CONSOLE_LOGLEVEL > 8
-#if defined(DEBUG_RAM_SETUP)
+#if CONFIG_DEBUG_RAM_SETUP
 	sdram_dump_mchbar_registers();
 #endif
 

Modified: trunk/src/mainboard/msi/ms7135/romstage.c
==============================================================================
--- trunk/src/mainboard/msi/ms7135/romstage.c	Mon Mar  1 21:16:38 2010	(r5184)
+++ trunk/src/mainboard/msi/ms7135/romstage.c	Fri Mar  5 11:03:50 2010	(r5185)
@@ -30,9 +30,6 @@
 /* Used by raminit. */
 #define QRANK_DIMM_SUPPORT 1
 
-/* Turn this on for SMBus debugging output. */
-#define DEBUG_SMBUS 0
-
 #if CONFIG_LOGICAL_CPUS == 1
 #define SET_NB_CFG_54 1
 #endif

Modified: trunk/src/mainboard/msi/ms7260/romstage.c
==============================================================================
--- trunk/src/mainboard/msi/ms7260/romstage.c	Mon Mar  1 21:16:38 2010	(r5184)
+++ trunk/src/mainboard/msi/ms7260/romstage.c	Fri Mar  5 11:03:50 2010	(r5185)
@@ -24,7 +24,6 @@
 #define __PRE_RAM__
 
 // #define CACHE_AS_RAM_ADDRESS_DEBUG 1
-// #define DEBUG_SMBUS 1
 // #define RAM_TIMING_DEBUG 1
 // #define DQS_TRAIN_DEBUG 1
 // #define RES_DEBUG 1

Modified: trunk/src/mainboard/msi/ms9185/romstage.c
==============================================================================
--- trunk/src/mainboard/msi/ms9185/romstage.c	Mon Mar  1 21:16:38 2010	(r5184)
+++ trunk/src/mainboard/msi/ms9185/romstage.c	Fri Mar  5 11:03:50 2010	(r5185)
@@ -42,8 +42,6 @@
 //if we want to wait for core1 done before DQS training, set it to 0
 #define K8_SET_FIDVID_CORE0_ONLY 1
 
-#define DEBUG_SMBUS 1
-
 #include <stdint.h>
 #include <string.h>
 #include <device/pci_def.h>

Modified: trunk/src/mainboard/msi/ms9282/romstage.c
==============================================================================
--- trunk/src/mainboard/msi/ms9282/romstage.c	Mon Mar  1 21:16:38 2010	(r5184)
+++ trunk/src/mainboard/msi/ms9282/romstage.c	Fri Mar  5 11:03:50 2010	(r5185)
@@ -38,8 +38,6 @@
 //if we want to wait for core1 done before DQS training, set it to 0
 #define K8_SET_FIDVID_CORE0_ONLY 1
 
-#define DEBUG_SMBUS 1
-
 #include <stdint.h>
 #include <string.h>
 #include <device/pci_def.h>

Modified: trunk/src/northbridge/amd/amdfam10/debug.c
==============================================================================
--- trunk/src/northbridge/amd/amdfam10/debug.c	Mon Mar  1 21:16:38 2010	(r5184)
+++ trunk/src/northbridge/amd/amdfam10/debug.c	Fri Mar  5 11:03:50 2010	(r5185)
@@ -220,11 +220,7 @@
 	}
 }
 
-#ifndef DEBUG_SMBUS
-#define DEBUG_SMBUS 0
-#endif
-
-#if DEBUG_SMBUS == 1
+#if CONFIG_DEBUG_SMBUS
 
 static void dump_spd_registers(const struct mem_controller *ctrl)
 {

Modified: trunk/src/northbridge/amd/amdfam10/raminit_amdmct.c
==============================================================================
--- trunk/src/northbridge/amd/amdfam10/raminit_amdmct.c	Mon Mar  1 21:16:38 2010	(r5184)
+++ trunk/src/northbridge/amd/amdfam10/raminit_amdmct.c	Fri Mar  5 11:03:50 2010	(r5185)
@@ -23,21 +23,16 @@
 	printk_debug("%s%08x\n", strval, val);
 }
 
-
-#define RAMINIT_DEBUG 1
-
-
 static  void print_tx(const char *strval, u32 val)
 {
-#if RAMINIT_DEBUG == 1
+#if CONFIG_DEBUG_RAM_SETUP
 	print_raminit(strval, val);
 #endif
 }
 
-
 static  void print_t(const char *strval)
 {
-#if RAMINIT_DEBUG == 1
+#if CONFIG_DEBUG_RAM_SETUP
 	print_debug(strval);
 #endif
 }

Modified: trunk/src/northbridge/amd/amdk8/debug.c
==============================================================================
--- trunk/src/northbridge/amd/amdk8/debug.c	Mon Mar  1 21:16:38 2010	(r5184)
+++ trunk/src/northbridge/amd/amdk8/debug.c	Fri Mar  5 11:03:50 2010	(r5185)
@@ -134,11 +134,8 @@
 	}
 }
 
-#ifndef DEBUG_SMBUS
-#define DEBUG_SMBUS 0
-#endif
+#if CONFIG_DEBUG_SMBUS
 
-#if DEBUG_SMBUS == 1
 static void dump_spd_registers(const struct mem_controller *ctrl)
 {
 	int i;

Modified: trunk/src/northbridge/amd/amdk8/raminit_f.c
==============================================================================
--- trunk/src/northbridge/amd/amdk8/raminit_f.c	Mon Mar  1 21:16:38 2010	(r5184)
+++ trunk/src/northbridge/amd/amdk8/raminit_f.c	Fri Mar  5 11:03:50 2010	(r5185)
@@ -34,9 +34,7 @@
 #define QRANK_DIMM_SUPPORT 0
 #endif
 
-#define RAM_TIMING_DEBUG 0
-
-#if RAM_TIMING_DEBUG == 1
+#if DEBUG_RAM_SETUP
 #define printk_raminit printk_debug
 #else
 #define printk_raminit(fmt, arg...)

Modified: trunk/src/northbridge/intel/e7501/raminit.c
==============================================================================
--- trunk/src/northbridge/intel/e7501/raminit.c	Mon Mar  1 21:16:38 2010	(r5184)
+++ trunk/src/northbridge/intel/e7501/raminit.c	Fri Mar  5 11:03:50 2010	(r5185)
@@ -22,10 +22,7 @@
 // Unfortunately the code seems to chew up several K of space.
 //#define VALIDATE_DIMM_COMPATIBILITY
 
-// Uncomment this to enable local debugging messages
-//#define DEBUG_RAM_CONFIG
-
-#if defined(DEBUG_RAM_CONFIG)
+#if CONFIG_DEBUG_RAM_SETUP
 #define RAM_DEBUG_MESSAGE(x)	print_debug(x)
 #define RAM_DEBUG_HEX32(x)		print_debug_hex32(x)
 #define RAM_DEBUG_HEX8(x)		print_debug_hex8(x)

Modified: trunk/src/northbridge/intel/i440bx/raminit.c
==============================================================================
--- trunk/src/northbridge/intel/i440bx/raminit.c	Mon Mar  1 21:16:38 2010	(r5184)
+++ trunk/src/northbridge/intel/i440bx/raminit.c	Fri Mar  5 11:03:50 2010	(r5185)
@@ -28,11 +28,8 @@
 Macros and definitions.
 -----------------------------------------------------------------------------*/
 
-/* Uncomment this to enable debugging output. */
-#define DEBUG_RAM_SETUP 1
-
 /* Debugging macros. */
-#if defined(DEBUG_RAM_SETUP)
+#if CONFIG_DEBUG_RAM_SETUP
 #define PRINT_DEBUG(x)		print_debug(x)
 #define PRINT_DEBUG_HEX8(x)	print_debug_hex8(x)
 #define PRINT_DEBUG_HEX16(x)	print_debug_hex16(x)

Modified: trunk/src/northbridge/intel/i82810/raminit.c
==============================================================================
--- trunk/src/northbridge/intel/i82810/raminit.c	Mon Mar  1 21:16:38 2010	(r5184)
+++ trunk/src/northbridge/intel/i82810/raminit.c	Fri Mar  5 11:03:50 2010	(r5185)
@@ -29,11 +29,8 @@
 Macros and definitions.
 -----------------------------------------------------------------------------*/
 
-/* Uncomment this to enable debugging output. */
-// #define DEBUG_RAM_SETUP 1
-
 /* Debugging macros. */
-#if defined(DEBUG_RAM_SETUP)
+#if CONFIG_DEBUG_RAM_SETUP
 #define PRINT_DEBUG(x)		print_debug(x)
 #define PRINT_DEBUG_HEX8(x)	print_debug_hex8(x)
 #define PRINT_DEBUG_HEX16(x)	print_debug_hex16(x)

Modified: trunk/src/northbridge/intel/i82830/raminit.c
==============================================================================
--- trunk/src/northbridge/intel/i82830/raminit.c	Mon Mar  1 21:16:38 2010	(r5184)
+++ trunk/src/northbridge/intel/i82830/raminit.c	Fri Mar  5 11:03:50 2010	(r5185)
@@ -29,11 +29,8 @@
 Macros and definitions.
 -----------------------------------------------------------------------------*/
 
-/* Uncomment this to enable debugging output. */
-/* #define DEBUG_RAM_SETUP 1 */
-
 /* Debugging macros. */
-#if defined(DEBUG_RAM_SETUP)
+#if CONFIG_DEBUG_RAM_SETUP
 #define PRINT_DEBUG(x)		print_debug(x)
 #define PRINT_DEBUG_HEX8(x)	print_debug_hex8(x)
 #define PRINT_DEBUG_HEX16(x)	print_debug_hex16(x)

Modified: trunk/src/northbridge/intel/i945/raminit.c
==============================================================================
--- trunk/src/northbridge/intel/i945/raminit.c	Mon Mar  1 21:16:38 2010	(r5184)
+++ trunk/src/northbridge/intel/i945/raminit.c	Fri Mar  5 11:03:50 2010	(r5185)
@@ -24,10 +24,8 @@
 #include "raminit.h"
 #include "i945.h"
 
-#define DEBUG_RAM_SETUP
-
 /* Debugging macros. */
-#if defined(DEBUG_RAM_SETUP)
+#if CONFIG_DEBUG_RAM_SETUP
 #define PRINTK_DEBUG(x...)	printk_debug(x)
 #else
 #define PRINTK_DEBUG(x...)
@@ -73,7 +71,7 @@
 	read32(offset);
 }
 
-#ifdef DEBUG_RAM_SETUP
+#if CONFIG_DEBUG_RAM_SETUP
 static void sdram_dump_mchbar_registers(void)
 {
 	int i;

Modified: trunk/src/northbridge/via/cn700/raminit.c
==============================================================================
--- trunk/src/northbridge/via/cn700/raminit.c	Mon Mar  1 21:16:38 2010	(r5184)
+++ trunk/src/northbridge/via/cn700/raminit.c	Fri Mar  5 11:03:50 2010	(r5185)
@@ -25,9 +25,7 @@
 #include <delay.h>
 #include "cn700.h"
 
-// #define DEBUG_RAM_SETUP 1
-
-#ifdef DEBUG_RAM_SETUP
+#ifdef CONFIG_DEBUG_RAM_SETUP
 #define PRINT_DEBUG_MEM(x)		print_debug(x)
 #define PRINT_DEBUG_MEM_HEX8(x)		print_debug_hex8(x)
 #define PRINT_DEBUG_MEM_HEX16(x)	print_debug_hex16(x)
@@ -51,12 +49,6 @@
 	reg &= 0xf8;		/* Clear bits 2-0. */
 	reg |= command;
 	pci_write_config8(dev, DRAM_MISC_CTL, reg);
-
-	PRINT_DEBUG_MEM("    Sending RAM command 0x");
-	PRINT_DEBUG_MEM_HEX8(reg);
-	PRINT_DEBUG_MEM(" to 0x");
-	PRINT_DEBUG_MEM_HEX32(0 + addr_offset);
-	PRINT_DEBUG_MEM("\r\n");
 }
 
 /**

Modified: trunk/src/northbridge/via/cx700/cx700_early_smbus.c
==============================================================================
--- trunk/src/northbridge/via/cx700/cx700_early_smbus.c	Mon Mar  1 21:16:38 2010	(r5184)
+++ trunk/src/northbridge/via/cx700/cx700_early_smbus.c	Fri Mar  5 11:03:50 2010	(r5185)
@@ -48,10 +48,7 @@
 #define SMBUS_DELAY()		outb(0x80, 0x80)
 
 /* Debugging macros. */
-
-// #define DEBUG_SMBUS 1
-
-#ifdef DEBUG_SMBUS
+#if CONFIG_DEBUG_SMBUS
 #define PRINT_DEBUG(x)		print_debug(x)
 #define PRINT_DEBUG_HEX16(x)	print_debug_hex16(x)
 #else
@@ -102,7 +99,7 @@
 		SMBUS_DELAY();
 		++loops;
 	}
-#ifdef DEBUG_SMBUS
+#if CONFIG_DEBUG_SMBUS
 	/* Some systems seem to have a flakey SMBus. No need to spew a lot of
 	 * errors on those, once we know that SMBus access is principally
 	 * working.
@@ -234,7 +231,7 @@
 }
 
 /* Debugging Function */
-#ifdef DEBUG_SMBUS
+#ifdef CONFIG_DEBUG_SMBUS
 static void dump_spd_data(const struct mem_controller *ctrl)
 {
 	int dimm, offset, regs;

Modified: trunk/src/northbridge/via/cx700/raminit.c
==============================================================================
--- trunk/src/northbridge/via/cx700/raminit.c	Mon Mar  1 21:16:38 2010	(r5184)
+++ trunk/src/northbridge/via/cx700/raminit.c	Fri Mar  5 11:03:50 2010	(r5185)
@@ -24,10 +24,8 @@
 #include <delay.h>
 #include "cx700_registers.h"
 
-// #define DEBUG_RAM_SETUP 1
-
 /* Debugging macros. */
-#if defined(DEBUG_RAM_SETUP)
+#if CONFIG_DEBUG_RAM_SETUP
 #define PRINTK_DEBUG(x...)      printk_debug(x)
 #else
 #define PRINTK_DEBUG(x...)

Modified: trunk/src/northbridge/via/vx800/raminit.c
==============================================================================
--- trunk/src/northbridge/via/vx800/raminit.c	Mon Mar  1 21:16:38 2010	(r5184)
+++ trunk/src/northbridge/via/vx800/raminit.c	Fri Mar  5 11:03:50 2010	(r5185)
@@ -21,9 +21,7 @@
 #include <sdram_mode.h>
 #include <delay.h>
 
-#define DEBUG_RAM_SETUP 1
-
-#ifdef DEBUG_RAM_SETUP
+#if CONFIG_DEBUG_RAM_SETUP
 #define PRINT_DEBUG_MEM(x)		print_debug(x)
 #define PRINT_DEBUG_MEM_HEX8(x)		print_debug_hex8(x)
 #define PRINT_DEBUG_MEM_HEX16(x)	print_debug_hex16(x)

Modified: trunk/src/northbridge/via/vx800/vx800_early_smbus.c
==============================================================================
--- trunk/src/northbridge/via/vx800/vx800_early_smbus.c	Mon Mar  1 21:16:38 2010	(r5184)
+++ trunk/src/northbridge/via/vx800/vx800_early_smbus.c	Fri Mar  5 11:03:50 2010	(r5185)
@@ -49,11 +49,7 @@
 
 #define SMBUS_DELAY()		outb(0x80, 0x80)
 
-/* Debugging macros. Only necessary if something isn't working right */
-
-#define DEBUG_SMBUS 1
-
-#ifdef DEBUG_SMBUS
+#ifdef CONFIG_DEBUG_SMBUS
 #define PRINT_DEBUG(x)		print_debug(x)
 #define PRINT_DEBUG_HEX16(x)	print_debug_hex16(x)
 #else
@@ -289,7 +285,7 @@
 }
 
 /* Debugging Function */
-#ifdef DEBUG_SMBUS
+#if CONFIG_DEBUG_SMBUS
 static void dump_spd_data(void)
 {
 	int dimm, offset, regs;

Modified: trunk/src/southbridge/intel/i82801gx/i82801gx_smihandler.c
==============================================================================
--- trunk/src/southbridge/intel/i82801gx/i82801gx_smihandler.c	Mon Mar  1 21:16:38 2010	(r5184)
+++ trunk/src/southbridge/intel/i82801gx/i82801gx_smihandler.c	Fri Mar  5 11:03:50 2010	(r5185)
@@ -28,8 +28,6 @@
 #include <device/pci_def.h>
 #include "i82801gx.h"
 
-#define DEBUG_SMI
-
 #define APM_CNT		0xb2
 #define   CST_CONTROL	0x85
 #define   PST_CONTROL	0x80

Modified: trunk/src/southbridge/via/vt8237r/vt8237r.h
==============================================================================
--- trunk/src/southbridge/via/vt8237r/vt8237r.h	Mon Mar  1 21:16:38 2010	(r5184)
+++ trunk/src/southbridge/via/vt8237r/vt8237r.h	Fri Mar  5 11:03:50 2010	(r5185)
@@ -65,7 +65,7 @@
 #define I2C_TRANS_CMD			0x40
 #define CLOCK_SLAVE_ADDRESS		0x69
 
-#if DEBUG_SMBUS == 1
+#if CONFIG_DEBUG_SMBUS
 #define PRINT_DEBUG(x)		print_debug(x)
 #define PRINT_DEBUG_HEX16(x)	print_debug_hex16(x)
 #else

Modified: trunk/util/x86emu/include/x86emu/fpu_regs.h
==============================================================================
--- trunk/util/x86emu/include/x86emu/fpu_regs.h	Mon Mar  1 21:16:38 2010	(r5184)
+++ trunk/util/x86emu/include/x86emu/fpu_regs.h	Fri Mar  5 11:03:50 2010	(r5185)
@@ -102,7 +102,7 @@
 
 #endif /* X86_FPU_SUPPORT */
 
-#ifdef DEBUG
+#if CONFIG_X86EMU_DEBUG
 # define DECODE_PRINTINSTR32(t,mod,rh,rl)     	\
 	DECODE_PRINTF(t[(mod<<3)+(rh)]);
 # define DECODE_PRINTINSTR256(t,mod,rh,rl)    	\

Modified: trunk/util/x86emu/include/x86emu/regs.h
==============================================================================
--- trunk/util/x86emu/include/x86emu/regs.h	Mon Mar  1 21:16:38 2010	(r5184)
+++ trunk/util/x86emu/include/x86emu/regs.h	Fri Mar  5 11:03:50 2010	(r5185)
@@ -279,7 +279,7 @@
     u32                         mode;
     volatile int                intr;   /* mask of pending interrupts */
     volatile int                         debug;
-#ifdef DEBUG
+#if CONFIG_X86EMU_DEBUG
     int                         check;
     u16                         saved_ip;
     u16                         saved_cs;
@@ -365,13 +365,6 @@
 #define X86_CH M.x86.R_CH
 #define X86_DH M.x86.R_DH
 
-		
-/*-------------------------- Function Prototypes --------------------------*/
-
-/* Function to log information at runtime */
-
-//void	printk(const char *fmt, ...);
-
 #ifdef  __cplusplus
 }                       			/* End of "C" linkage for C++   	*/
 #endif

Modified: trunk/util/x86emu/include/x86emu/x86emu.h
==============================================================================
--- trunk/util/x86emu/include/x86emu/x86emu.h	Mon Mar  1 21:16:38 2010	(r5184)
+++ trunk/util/x86emu/include/x86emu/x86emu.h	Fri Mar  5 11:03:50 2010	(r5185)
@@ -42,27 +42,15 @@
 #ifndef __X86EMU_X86EMU_H
 #define __X86EMU_X86EMU_H
 
-/* FIXME: redefine printk for the moment */
 #include <stddef.h>
 #include <console/console.h>
-#undef printk
-#define printk(x...) do_printk(BIOS_DEBUG, x)
-#if defined(CONFIG_YABEL_DEBUG_FLAGS) && (CONFIG_YABEL_DEBUG_FLAGS != 0)
+#if CONFIG_X86EMU_DEBUG
 #define DEBUG
-#else
-#undef DEBUG
 #endif
 
-#ifdef SCITECH
-#include "scitech.h"
-#define	X86API	_ASMAPI
-#define	X86APIP	_ASMAPIP
-typedef int X86EMU_pioAddr;
-#else
 #include "types.h"
 #define	X86API
 #define	X86APIP	*
-#endif
 #include "regs.h"
 
 /*---------------------- Macros and type definitions ----------------------*/
@@ -166,9 +154,9 @@
 void 	X86EMU_exec(void);
 void 	X86EMU_halt_sys(void);
 
-#ifdef	DEBUG
+#if CONFIG_X86EMU_DEBUG
 #define	HALT_SYS()	\
-    	printk("halt_sys: in %s\n", __func__);	\
+    	printf("halt_sys: in %s\n", __func__);	\
 	X86EMU_halt_sys();
 #else
 #define	HALT_SYS()	X86EMU_halt_sys()

Modified: trunk/util/x86emu/x86.c
==============================================================================
--- trunk/util/x86emu/x86.c	Mon Mar  1 21:16:38 2010	(r5184)
+++ trunk/util/x86emu/x86.c	Fri Mar  5 11:03:50 2010	(r5185)
@@ -23,8 +23,6 @@
 #include <arch/io.h>
 #include <arch/registers.h>
 #include <console/console.h>
-#define printk(x...) do_printk(x)
-
 #include <arch/interrupt.h>
 
 #define REALMODE_BASE ((void *)0x600)

Modified: trunk/util/x86emu/x86_interrupts.c
==============================================================================
--- trunk/util/x86emu/x86_interrupts.c	Mon Mar  1 21:16:38 2010	(r5184)
+++ trunk/util/x86emu/x86_interrupts.c	Fri Mar  5 11:03:50 2010	(r5185)
@@ -26,7 +26,6 @@
 #include <console/console.h>
 #include <arch/io.h>
 #include <arch/registers.h>
-#define printk(x...) do_printk(x)
 
 enum {
 	PCIBIOS_CHECK = 0xb101,

Modified: trunk/util/x86emu/x86emu/debug.c
==============================================================================
--- trunk/util/x86emu/x86emu/debug.c	Mon Mar  1 21:16:38 2010	(r5184)
+++ trunk/util/x86emu/x86emu/debug.c	Fri Mar  5 11:03:50 2010	(r5185)
@@ -38,7 +38,6 @@
 ****************************************************************************/
 
 #include "x86emui.h"
-// #include <stdarg.h>
 
 /*----------------------------- Implementation ----------------------------*/
 
@@ -59,7 +58,7 @@
 	}
     }
     if (DEBUG_DECODE() && ! DEBUG_DECODE_NOPRINT()) {
-        printk("%04x:%04x ",M.x86.saved_cs, M.x86.saved_ip);
+        printf("%04x:%04x ",M.x86.saved_cs, M.x86.saved_ip);
         print_encoded_bytes( M.x86.saved_cs, M.x86.saved_ip);
         print_decoded_instruction();
     }
@@ -78,7 +77,7 @@
      * This routine called if the flag DEBUG_DISASSEMBLE is set kind
      * of a hack!
      */
-    printk("%04x:%04x ",M.x86.saved_cs, M.x86.saved_ip);
+    printf("%04x:%04x ",M.x86.saved_cs, M.x86.saved_ip);
     print_encoded_bytes( M.x86.saved_cs, M.x86.saved_ip);
     print_decoded_instruction();
 }
@@ -162,13 +161,13 @@
     M.x86.enc_pos += x;
 }
 
-void x86emu_decode_printf (char *x)
+void x86emu_decode_printf (const char *x)
 {
     sprintf(M.x86.decoded_buf+M.x86.enc_str_pos,"%s",x);
     M.x86.enc_str_pos += strlen(x);
 }
 
-void x86emu_decode_printf2 (char *x, int y)
+void x86emu_decode_printf2 (const char *x, int y)
 {
     char temp[100];
     sprintf(temp,x,y);
@@ -189,12 +188,12 @@
     for (i=0; i< M.x86.enc_pos; i++) {
         sprintf(buf1+2*i,"%02x", fetch_data_byte_abs(s,o+i));
     }
-    printk("%-20s ",buf1);
+    printf("%-20s ",buf1);
 }
 
 static void print_decoded_instruction (void)
 {
-    printk("%s", M.x86.decoded_buf);
+    printf("%s", M.x86.decoded_buf);
 }
 
 void x86emu_print_int_vect (u16 iv)
@@ -204,7 +203,7 @@
     if (iv > 256) return;
     seg   = fetch_data_word_abs(0,iv*4);
     off   = fetch_data_word_abs(0,iv*4+2);
-    printk("%04x:%04x ", seg, off);
+    printf("%04x:%04x ", seg, off);
 }
 
 void X86EMU_dump_memory (u16 seg, u16 off, u32 amt)
@@ -216,12 +215,12 @@
 
     current = start;
     while (end <= off + amt) {
-        printk("%04x:%04x ", seg, start);
+        printf("%04x:%04x ", seg, start);
         for (i=start; i< off; i++)
-          printk("   ");
+          printf("   ");
         for (       ; i< end; i++)
-          printk("%02x ", fetch_data_byte_abs(seg,i));
-        printk("\n");
+          printf("%02x ", fetch_data_byte_abs(seg,i));
+        printf("\n");
         start = end;
         end = start + 16;
     }
@@ -256,7 +255,7 @@
     done=0;
     offset = M.x86.saved_ip;
     while (!done) {
-        printk("-");
+        printf("-");
         p = fgets(s, 1023, stdin);
         cmd = parse_line(s, ps, &ntok);
         switch(cmd) {
@@ -310,7 +309,7 @@
           return;
       case 'P':
           noDecode = (noDecode)?0:1;
-          printk("Toggled decoding to %s\n",(noDecode)?"FALSE":"TRUE");
+          printf("Toggled decoding to %s\n",(noDecode)?"FALSE":"TRUE");
           break;
           case 't':
       case 0:
@@ -368,68 +367,68 @@
 
 void x86emu_dump_regs (void)
 {
-    printk("\tAX=%04x  ", M.x86.R_AX );
-    printk("BX=%04x  ", M.x86.R_BX );
-    printk("CX=%04x  ", M.x86.R_CX );
-    printk("DX=%04x  ", M.x86.R_DX );
-    printk("SP=%04x  ", M.x86.R_SP );
-    printk("BP=%04x  ", M.x86.R_BP );
-    printk("SI=%04x  ", M.x86.R_SI );
-    printk("DI=%04x\n", M.x86.R_DI );
-    printk("\tDS=%04x  ", M.x86.R_DS );
-    printk("ES=%04x  ", M.x86.R_ES );
-    printk("SS=%04x  ", M.x86.R_SS );
-    printk("CS=%04x  ", M.x86.R_CS );
-    printk("IP=%04x   ", M.x86.R_IP );
-    if (ACCESS_FLAG(F_OF))    printk("OV ");     /* CHECKED... */
-    else                        printk("NV ");
-    if (ACCESS_FLAG(F_DF))    printk("DN ");
-    else                        printk("UP ");
-    if (ACCESS_FLAG(F_IF))    printk("EI ");
-    else                        printk("DI ");
-    if (ACCESS_FLAG(F_SF))    printk("NG ");
-    else                        printk("PL ");
-    if (ACCESS_FLAG(F_ZF))    printk("ZR ");
-    else                        printk("NZ ");
-    if (ACCESS_FLAG(F_AF))    printk("AC ");
-    else                        printk("NA ");
-    if (ACCESS_FLAG(F_PF))    printk("PE ");
-    else                        printk("PO ");
-    if (ACCESS_FLAG(F_CF))    printk("CY ");
-    else                        printk("NC ");
-    printk("\n");
+    printf("\tAX=%04x  ", M.x86.R_AX );
+    printf("BX=%04x  ", M.x86.R_BX );
+    printf("CX=%04x  ", M.x86.R_CX );
+    printf("DX=%04x  ", M.x86.R_DX );
+    printf("SP=%04x  ", M.x86.R_SP );
+    printf("BP=%04x  ", M.x86.R_BP );
+    printf("SI=%04x  ", M.x86.R_SI );
+    printf("DI=%04x\n", M.x86.R_DI );
+    printf("\tDS=%04x  ", M.x86.R_DS );
+    printf("ES=%04x  ", M.x86.R_ES );
+    printf("SS=%04x  ", M.x86.R_SS );
+    printf("CS=%04x  ", M.x86.R_CS );
+    printf("IP=%04x   ", M.x86.R_IP );
+    if (ACCESS_FLAG(F_OF))    printf("OV ");     /* CHECKED... */
+    else                        printf("NV ");
+    if (ACCESS_FLAG(F_DF))    printf("DN ");
+    else                        printf("UP ");
+    if (ACCESS_FLAG(F_IF))    printf("EI ");
+    else                        printf("DI ");
+    if (ACCESS_FLAG(F_SF))    printf("NG ");
+    else                        printf("PL ");
+    if (ACCESS_FLAG(F_ZF))    printf("ZR ");
+    else                        printf("NZ ");
+    if (ACCESS_FLAG(F_AF))    printf("AC ");
+    else                        printf("NA ");
+    if (ACCESS_FLAG(F_PF))    printf("PE ");
+    else                        printf("PO ");
+    if (ACCESS_FLAG(F_CF))    printf("CY ");
+    else                        printf("NC ");
+    printf("\n");
 }
 
 void x86emu_dump_xregs (void)
 {
-    printk("\tEAX=%08x  ", M.x86.R_EAX );
-    printk("EBX=%08x  ", M.x86.R_EBX );
-    printk("ECX=%08x  ", M.x86.R_ECX );
-    printk("EDX=%08x  \n", M.x86.R_EDX );
-    printk("\tESP=%08x  ", M.x86.R_ESP );
-    printk("EBP=%08x  ", M.x86.R_EBP );
-    printk("ESI=%08x  ", M.x86.R_ESI );
-    printk("EDI=%08x\n", M.x86.R_EDI );
-    printk("\tDS=%04x  ", M.x86.R_DS );
-    printk("ES=%04x  ", M.x86.R_ES );
-    printk("SS=%04x  ", M.x86.R_SS );
-    printk("CS=%04x  ", M.x86.R_CS );
-    printk("EIP=%08x\n\t", M.x86.R_EIP );
-    if (ACCESS_FLAG(F_OF))    printk("OV ");     /* CHECKED... */
-    else                        printk("NV ");
-    if (ACCESS_FLAG(F_DF))    printk("DN ");
-    else                        printk("UP ");
-    if (ACCESS_FLAG(F_IF))    printk("EI ");
-    else                        printk("DI ");
-    if (ACCESS_FLAG(F_SF))    printk("NG ");
-    else                        printk("PL ");
-    if (ACCESS_FLAG(F_ZF))    printk("ZR ");
-    else                        printk("NZ ");
-    if (ACCESS_FLAG(F_AF))    printk("AC ");
-    else                        printk("NA ");
-    if (ACCESS_FLAG(F_PF))    printk("PE ");
-    else                        printk("PO ");
-    if (ACCESS_FLAG(F_CF))    printk("CY ");
-    else                        printk("NC ");
-    printk("\n");
+    printf("\tEAX=%08x  ", M.x86.R_EAX );
+    printf("EBX=%08x  ", M.x86.R_EBX );
+    printf("ECX=%08x  ", M.x86.R_ECX );
+    printf("EDX=%08x  \n", M.x86.R_EDX );
+    printf("\tESP=%08x  ", M.x86.R_ESP );
+    printf("EBP=%08x  ", M.x86.R_EBP );
+    printf("ESI=%08x  ", M.x86.R_ESI );
+    printf("EDI=%08x\n", M.x86.R_EDI );
+    printf("\tDS=%04x  ", M.x86.R_DS );
+    printf("ES=%04x  ", M.x86.R_ES );
+    printf("SS=%04x  ", M.x86.R_SS );
+    printf("CS=%04x  ", M.x86.R_CS );
+    printf("EIP=%08x\n\t", M.x86.R_EIP );
+    if (ACCESS_FLAG(F_OF))    printf("OV ");     /* CHECKED... */
+    else                        printf("NV ");
+    if (ACCESS_FLAG(F_DF))    printf("DN ");
+    else                        printf("UP ");
+    if (ACCESS_FLAG(F_IF))    printf("EI ");
+    else                        printf("DI ");
+    if (ACCESS_FLAG(F_SF))    printf("NG ");
+    else                        printf("PL ");
+    if (ACCESS_FLAG(F_ZF))    printf("ZR ");
+    else                        printf("NZ ");
+    if (ACCESS_FLAG(F_AF))    printf("AC ");
+    else                        printf("NA ");
+    if (ACCESS_FLAG(F_PF))    printf("PE ");
+    else                        printf("PO ");
+    if (ACCESS_FLAG(F_CF))    printf("CY ");
+    else                        printf("NC ");
+    printf("\n");
 }

Modified: trunk/util/x86emu/x86emu/debug.h
==============================================================================
--- trunk/util/x86emu/x86emu/debug.h	Mon Mar  1 21:16:38 2010	(r5184)
+++ trunk/util/x86emu/x86emu/debug.h	Fri Mar  5 11:03:50 2010	(r5185)
@@ -40,10 +40,11 @@
 #ifndef __X86EMU_DEBUG_H
 #define __X86EMU_DEBUG_H
 
-//#define DEBUG 0
-//#undef DEBUG
 /*---------------------- Macros and type definitions ----------------------*/
 
+/* printf is not available in coreboot... use printk */
+#define printf(x...) printk(BIOS_DEBUG, x)
+
 /* checks to be enabled for "runtime" */
 
 #define CHECK_IP_FETCH_F                0x1
@@ -172,17 +173,17 @@
 	if (DEBUG_TRACECALLREGS())									\
 		x86emu_dump_regs();                                     \
 	if (DEBUG_TRACECALL())                                     	\
-		printk("%04x:%04x: CALL %s%04x:%04x\n", u , v, s, w, x);
+		printf("%04x:%04x: CALL %s%04x:%04x\n", u , v, s, w, x);
 # define RETURN_TRACE(u,v,w,x,s)                                    \
 	if (DEBUG_TRACECALLREGS())									\
 		x86emu_dump_regs();                                     \
 	if (DEBUG_TRACECALL())                                     	\
-		printk("%04x:%04x: RET %s %04x:%04x\n",u,v,s,w,x);
+		printf("%04x:%04x: RET %s %04x:%04x\n",u,v,s,w,x);
 # define  JMP_TRACE(u,v,w,x,s)                                 \
    if (DEBUG_TRACEJMPREGS()) \
       x86emu_dump_regs(); \
    if (DEBUG_TRACEJMP()) \
-      printk("%04x:%04x: JMP %s%04x:%04x\n", u , v, s, w, x);
+      printf("%04x:%04x: JMP %s%04x:%04x\n", u , v, s, w, x);
 #else
 # define CALL_TRACE(u,v,w,x,s)
 # define RETURN_TRACE(u,v,w,x,s)
@@ -201,20 +202,22 @@
 extern "C" {            			/* Use "C" linkage when in C++ mode */
 #endif
 
-extern void x86emu_inc_decoded_inst_len (int x);
-extern void x86emu_decode_printf (char *x);
-extern void x86emu_decode_printf2 (char *x, int y);
-extern void x86emu_just_disassemble (void);
-extern void x86emu_single_step (void);
-extern void x86emu_end_instr (void);
-extern void x86emu_dump_regs (void);
-extern void x86emu_dump_xregs (void);
-extern void x86emu_print_int_vect (u16 iv);
-extern void x86emu_instrument_instruction (void);
-extern void x86emu_check_ip_access (void);
-extern void x86emu_check_sp_access (void);
-extern void x86emu_check_mem_access (u32 p);
-extern void x86emu_check_data_access (uint s, uint o);
+void x86emu_inc_decoded_inst_len (int x);
+void x86emu_decode_printf (const char *x);
+void x86emu_decode_printf2 (const char *x, int y);
+void x86emu_just_disassemble (void);
+void x86emu_single_step (void);
+void x86emu_end_instr (void);
+void x86emu_dump_regs (void);
+void x86emu_dump_xregs (void);
+void x86emu_print_int_vect (u16 iv);
+void x86emu_instrument_instruction (void);
+void x86emu_check_ip_access (void);
+void x86emu_check_sp_access (void);
+void x86emu_check_mem_access (u32 p);
+void x86emu_check_data_access (uint s, uint o);
+
+void disassemble_forward (u16 seg, u16 off, int n);
 
 #ifdef  __cplusplus
 }                       			/* End of "C" linkage for C++   	*/

Modified: trunk/util/x86emu/x86emu/decode.c
==============================================================================
--- trunk/util/x86emu/x86emu/decode.c	Mon Mar  1 21:16:38 2010	(r5184)
+++ trunk/util/x86emu/x86emu/decode.c	Fri Mar  5 11:03:50 2010	(r5185)
@@ -77,7 +77,7 @@
 void x86emu_intr_raise(
     u8 intrnum)
 {
-    printk("%s, rasing execption %x\n", __func__, intrnum);
+    printf("%s, raising exeception %x\n", __func__, intrnum);
     x86emu_dump_regs();
     M.x86.intno = intrnum;
     M.x86.intr |= INTR_SYNCH;
@@ -105,12 +105,12 @@
         if (M.x86.intr) {
             if (M.x86.intr & INTR_HALTED) {
 DB(             if (M.x86.R_SP != 0) {
-                    printk("halted\n");
+                    printf("halted\n");
                     X86EMU_trace_regs();
                     }
                 else {
                     if (M.x86.debug)
-                        printk("Service completed successfully\n");
+                        printf("Service completed successfully\n");
                     })
                 return;
             }
@@ -286,7 +286,7 @@
         return  M.x86.R_SS;
       default:
 #ifdef  DEBUG
-        printk("error: should not happen:  multiple overrides.\n");
+        printf("error: should not happen:  multiple overrides.\n");
 #endif
         HALT_SYS();
         return 0;

Modified: trunk/util/x86emu/x86emu/fpu.c
==============================================================================
--- trunk/util/x86emu/x86emu/fpu.c	Mon Mar  1 21:16:38 2010	(r5184)
+++ trunk/util/x86emu/x86emu/fpu.c	Fri Mar  5 11:03:50 2010	(r5185)
@@ -52,7 +52,7 @@
 
 #ifdef DEBUG
 
-static char *x86emu_fpu_op_d9_tab[] = {
+static const char *x86emu_fpu_op_d9_tab[] = {
     "FLD\tDWORD PTR ", "ESC_D9\t", "FST\tDWORD PTR ", "FSTP\tDWORD PTR ",
     "FLDENV\t", "FLDCW\t", "FSTENV\t", "FSTCW\t",
 
@@ -63,7 +63,7 @@
     "FLDENV\t", "FLDCW\t", "FSTENV\t", "FSTCW\t",
 };
 
-static char *x86emu_fpu_op_d9_tab1[] = {
+static const char *x86emu_fpu_op_d9_tab1[] = {
     "FLD\t", "FLD\t", "FLD\t", "FLD\t",
     "FLD\t", "FLD\t", "FLD\t", "FLD\t",
 
@@ -296,7 +296,7 @@
 
 #ifdef DEBUG
 
-char *x86emu_fpu_op_da_tab[] = {
+static const char *x86emu_fpu_op_da_tab[] = {
     "FIADD\tDWORD PTR ", "FIMUL\tDWORD PTR ", "FICOM\tDWORD PTR ",
     "FICOMP\tDWORD PTR ",
     "FISUB\tDWORD PTR ", "FISUBR\tDWORD PTR ", "FIDIV\tDWORD PTR ",
@@ -386,7 +386,7 @@
 
 #ifdef DEBUG
 
-char *x86emu_fpu_op_db_tab[] = {
+static const char *x86emu_fpu_op_db_tab[] = {
     "FILD\tDWORD PTR ", "ESC_DB\t19", "FIST\tDWORD PTR ", "FISTP\tDWORD PTR ",
     "ESC_DB\t1C", "FLD\tTBYTE PTR ", "ESC_DB\t1E", "FSTP\tTBYTE PTR ",
 
@@ -505,7 +505,7 @@
 }
 
 #ifdef DEBUG
-char *x86emu_fpu_op_dc_tab[] = {
+static const char *x86emu_fpu_op_dc_tab[] = {
     "FADD\tQWORD PTR ", "FMUL\tQWORD PTR ", "FCOM\tQWORD PTR ",
     "FCOMP\tQWORD PTR ",
     "FSUB\tQWORD PTR ", "FSUBR\tQWORD PTR ", "FDIV\tQWORD PTR ",
@@ -620,7 +620,7 @@
 
 #ifdef DEBUG
 
-static char *x86emu_fpu_op_dd_tab[] = {
+static const char *x86emu_fpu_op_dd_tab[] = {
     "FLD\tQWORD PTR ", "ESC_DD\t29,", "FST\tQWORD PTR ", "FSTP\tQWORD PTR ",
     "FRSTOR\t", "ESC_DD\t2D,", "FSAVE\t", "FSTSW\t",
 
@@ -720,7 +720,7 @@
 
 #ifdef DEBUG
 
-static char *x86emu_fpu_op_de_tab[] =
+static const char *x86emu_fpu_op_de_tab[] =
 {
     "FIADD\tWORD PTR ", "FIMUL\tWORD PTR ", "FICOM\tWORD PTR ",
     "FICOMP\tWORD PTR ",
@@ -839,7 +839,7 @@
 
 #ifdef DEBUG
 
-static char *x86emu_fpu_op_df_tab[] = {
+static const char *x86emu_fpu_op_df_tab[] = {
     /* mod == 00 */
     "FILD\tWORD PTR ", "ESC_DF\t39\n", "FIST\tWORD PTR ", "FISTP\tWORD PTR ",
     "FBLD\tTBYTE PTR ", "FILD\tQWORD PTR ", "FBSTP\tTBYTE PTR ",

Modified: trunk/util/x86emu/x86emu/ops.c
==============================================================================
--- trunk/util/x86emu/x86emu/ops.c	Mon Mar  1 21:16:38 2010	(r5184)
+++ trunk/util/x86emu/x86emu/ops.c	Fri Mar  5 11:03:50 2010	(r5185)
@@ -77,7 +77,7 @@
 /* constant arrays to do several instructions in just one function */
 
 #ifdef DEBUG
-static char *x86emu_GenOpName[8] = {
+static const char *x86emu_GenOpName[8] = {
     "ADD", "OR", "ADC", "SBB", "AND", "SUB", "XOR", "CMP"};
 #endif
 
@@ -159,7 +159,7 @@
 
 #ifdef DEBUG
 
-static char *opF6_names[8] =
+static const char *opF6_names[8] =
   { "TEST\t", "", "NOT\t", "NEG\t", "MUL\t", "IMUL\t", "DIV\t", "IDIV\t" };
 
 #endif
@@ -178,7 +178,7 @@
     if (M.x86.R_SP != 0) {
         DECODE_PRINTF("ILLEGAL X86 OPCODE\n");
         TRACE_REGS();
-        DB( printk("%04x:%04x: %02X ILLEGAL X86 OPCODE!\n",
+        DB( printf("%04x:%04x: %02X ILLEGAL X86 OPCODE!\n",
             M.x86.R_CS, M.x86.R_IP-1,op1));
         HALT_SYS();
         }

Modified: trunk/util/x86emu/x86emu/ops2.c
==============================================================================
--- trunk/util/x86emu/x86emu/ops2.c	Mon Mar  1 21:16:38 2010	(r5184)
+++ trunk/util/x86emu/x86emu/ops2.c	Fri Mar  5 11:03:50 2010	(r5185)
@@ -54,7 +54,7 @@
     START_OF_INSTR();
     DECODE_PRINTF("ILLEGAL EXTENDED X86 OPCODE\n");
     TRACE_REGS();
-    printk("%04x:%04x: %02X ILLEGAL EXTENDED X86 OPCODE!\n",
+    printf("%04x:%04x: %02X ILLEGAL EXTENDED X86 OPCODE!\n",
         M.x86.R_CS, M.x86.R_IP-2, op2);
     HALT_SYS();
     END_OF_INSTR();
@@ -105,7 +105,7 @@
   default:
     DECODE_PRINTF("ILLEGAL EXTENDED X86 OPCODE IN 0F 01\n");
     TRACE_REGS();
-    printk("%04x:%04x: %02X ILLEGAL EXTENDED X86 OPCODE!\n",
+    printf("%04x:%04x: %02X ILLEGAL EXTENDED X86 OPCODE!\n",
         M.x86.R_CS, M.x86.R_IP-2, op2);
     HALT_SYS();
     break;
@@ -1272,7 +1272,7 @@
     default:
         DECODE_PRINTF("ILLEGAL EXTENDED X86 OPCODE\n");
         TRACE_REGS();
-        printk("%04x:%04x: %02X%02X ILLEGAL EXTENDED X86 OPCODE EXTENSION!\n",
+        printf("%04x:%04x: %02X%02X ILLEGAL EXTENDED X86 OPCODE EXTENSION!\n",
                 M.x86.R_CS, M.x86.R_IP-3,op2, (mod<<6)|(rh<<3)|rl);
         HALT_SYS();
     }

Modified: trunk/util/x86emu/x86emu/sys.c
==============================================================================
--- trunk/util/x86emu/x86emu/sys.c	Mon Mar  1 21:16:38 2010	(r5184)
+++ trunk/util/x86emu/x86emu/sys.c	Fri Mar  5 11:03:50 2010	(r5185)
@@ -41,15 +41,11 @@
 ****************************************************************************/
 /* $XFree86: xc/extras/x86emu/src/x86emu/sys.c,v 1.5 2000/08/23 22:10:01 tsi Exp $ */
 
+#include <arch/io.h>
 #include <x86emu/x86emu.h>
 #include <x86emu/regs.h>
 #include "debug.h"
 #include "prim_ops.h"
-#if 1 /* Coreboot needs to map prinkf to printk. */
-#include "arch/io.h"
-#else
-#include <sys/io.h>
-#endif
 
 #ifdef IN_MODULE
 #include "xf86_ansic.h"
@@ -69,11 +65,11 @@
 	u8 *retaddr = 0;
 
 	if (addr > M.mem_size - size) {
-		DB(printk("mem_ptr: address %#x out of range!\n", addr);)
+		DB(printf("mem_ptr: address %#x out of range!\n", addr);)
 		    HALT_SYS();
 	}
 	if (addr < 0x200) {
-		//printk("%x:%x updating int vector 0x%x\n",
+		//printf("%x:%x updating int vector 0x%x\n",
 		//       M.x86.R_CS, M.x86.R_IP, addr >> 2);
 	}
 	retaddr = (u8 *) (M.mem_base + addr);
@@ -100,7 +96,7 @@
 
 	val = *ptr;
 	DB(if (DEBUG_MEM_TRACE())
-	   printk("%#08x 1 -> %#x\n", addr, val);)
+	   printf("%#08x 1 -> %#x\n", addr, val);)
 		return val;
 }
 
@@ -123,7 +119,7 @@
 	val = *(u16 *) (ptr);
 
 	DB(if (DEBUG_MEM_TRACE())
-	   printk("%#08x 2 -> %#x\n", addr, val);)
+	   printf("%#08x 2 -> %#x\n", addr, val);)
 	return val;
 }
 
@@ -145,7 +141,7 @@
        	val = *(u32 *) (ptr);
 
 	DB(if (DEBUG_MEM_TRACE())
-	   printk("%#08x 4 -> %#x\n", addr, val);)
+	   printf("%#08x 4 -> %#x\n", addr, val);)
 	return val;
 }
 
@@ -165,7 +161,7 @@
 	*(u8 *) (ptr) = val;
 
 	DB(if (DEBUG_MEM_TRACE())
-	   printk("%#08x 1 <- %#x\n", addr, val);)
+	   printf("%#08x 1 <- %#x\n", addr, val);)
 }
 
 /****************************************************************************
@@ -184,7 +180,7 @@
 	*(u16 *) (ptr) = val;
 
 	DB(if (DEBUG_MEM_TRACE())
-	   printk("%#08x 2 <- %#x\n", addr, val);)
+	   printf("%#08x 2 <- %#x\n", addr, val);)
 }
 
 /****************************************************************************
@@ -203,7 +199,7 @@
 	*(u32 *) (ptr) = val;
 
 	DB(if (DEBUG_MEM_TRACE())
-	   printk("%#08x 4 <- %#x\n", addr, val);)
+	   printf("%#08x 4 <- %#x\n", addr, val);)
 
 
 }
@@ -219,7 +215,7 @@
 static u8 X86API p_inb(X86EMU_pioAddr addr)
 {
 	DB(if (DEBUG_IO_TRACE())
-		printk("inb %#04x \n", addr);)
+		printf("inb %#04x \n", addr);)
 	return inb(addr);
 }
 
@@ -234,7 +230,7 @@
 static u16 X86API p_inw(X86EMU_pioAddr addr)
 {
 	DB(if (DEBUG_IO_TRACE())
-		printk("inw %#04x \n", addr);)
+		printf("inw %#04x \n", addr);)
 	return inw(addr);
 }
 
@@ -249,7 +245,7 @@
 static u32 X86API p_inl(X86EMU_pioAddr addr)
 {
 	DB(if (DEBUG_IO_TRACE())
-		printk("inl %#04x \n", addr);)
+		printf("inl %#04x \n", addr);)
 	return inl(addr);
 }
 
@@ -263,7 +259,7 @@
 static void X86API p_outb(X86EMU_pioAddr addr, u8 val)
 {
 	DB(if (DEBUG_IO_TRACE())
-		printk("outb %#02x -> %#04x \n", val, addr);)
+		printf("outb %#02x -> %#04x \n", val, addr);)
 	outb(val, addr);
 	return;
 }
@@ -278,7 +274,7 @@
 static void X86API p_outw(X86EMU_pioAddr addr, u16 val)
 {
 	DB(if (DEBUG_IO_TRACE())
-		printk("outw %#04x -> %#04x \n", val, addr);)
+		printf("outw %#04x -> %#04x \n", val, addr);)
 	outw(val, addr);
 	return;
 }
@@ -293,7 +289,7 @@
 static void X86API p_outl(X86EMU_pioAddr addr, u32 val)
 {
 	DB(if (DEBUG_IO_TRACE())
-	       printk("outl %#08x -> %#04x \n", val, addr);)
+	       printf("outl %#08x -> %#04x \n", val, addr);)
 
 	outl(val, addr);
 	return;

Modified: trunk/util/x86emu/x86emu/x86emui.h
==============================================================================
--- trunk/util/x86emu/x86emu/x86emui.h	Mon Mar  1 21:16:38 2010	(r5184)
+++ trunk/util/x86emu/x86emu/x86emui.h	Fri Mar  5 11:03:50 2010	(r5185)
@@ -74,8 +74,6 @@
 #ifdef IN_MODULE
 #include <xf86_ansic.h>
 #else
-//#include <stdio.h>
-//#include <stdlib.h>
 #include <string.h>
 #endif                                                                                           
 /*--------------------------- Inline Functions ----------------------------*/

Modified: trunk/util/x86emu/yabel/biosemu.c
==============================================================================
--- trunk/util/x86emu/yabel/biosemu.c	Mon Mar  1 21:16:38 2010	(r5184)
+++ trunk/util/x86emu/yabel/biosemu.c	Fri Mar  5 11:03:50 2010	(r5185)
@@ -1,6 +1,7 @@
 /******************************************************************************
  * Copyright (c) 2004, 2008 IBM Corporation
  * Copyright (c) 2008, 2009 Pattrick Hueper <phueper at hueper.net>
+ * Copyright (c) 2010 coresystems GmbH
  * All rights reserved.
  * This program and the accompanying materials
  * are made available under the terms of the BSD License
@@ -12,7 +13,6 @@
  *****************************************************************************/
 
 #include <string.h>
-
 #include <types.h>
 
 #include "debug.h"
@@ -28,9 +28,8 @@
 #include "device.h"
 #include "pmm.h"
 
-#include "compat/rtas.h"
-
 #include <device/device.h>
+#include "compat/rtas.h"
 
 static X86EMU_memFuncs my_mem_funcs = {
 	my_rdb, my_rdw, my_rdl,
@@ -57,13 +56,42 @@
 {
 	u8 *rom_image;
 	int i = 0;
-#ifdef DEBUG
-	debug_flags = 0;//DEBUG_PRINT_INT10 | DEBUG_PNP | DEBUG_INTR | DEBUG_CHECK_VMEM_ACCESS | DEBUG_MEM | DEBUG_IO;
-		// | DEBUG_CHECK_VMEM_ACCESS | DEBUG_MEM | DEBUG_IO;
-		// | DEBUG_TRACE_X86EMU | DEBUG_JMP;
+#if CONFIG_X86EMU_DEBUG
+	debug_flags = 0;
+#if defined(CONFIG_X86EMU_DEBUG_JMP) && CONFIG_X86EMU_DEBUG_JMP
+	debug_flags |= DEBUG_JMP;
+#endif
+#if defined(CONFIG_X86EMU_DEBUG_TRACE) && CONFIG_X86EMU_DEBUG_TRACE
+	debug_flags |= DEBUG_TRACE_X86EMU;
+#endif
+#if defined(CONFIG_X86EMU_DEBUG_PNP) && CONFIG_X86EMU_DEBUG_PNP
+	debug_flags |= DEBUG_PNP;
+#endif
+#if defined(CONFIG_X86EMU_DEBUG_DISK) && CONFIG_X86EMU_DEBUG_DISK
+	debug_flags |= DEBUG_DISK;
+#endif
+#if defined(CONFIG_X86EMU_DEBUG_PMM) && CONFIG_X86EMU_DEBUG_PMM
+	debug_flags |= DEBUG_PMM;
+#endif
+#if defined(CONFIG_X86EMU_DEBUG_VBE) && CONFIG_X86EMU_DEBUG_VBE
+	debug_flags |= DEBUG_VBE;
+#endif
+#if defined(CONFIG_X86EMU_DEBUG_INT10) && CONFIG_X86EMU_DEBUG_INT10
+	debug_flags |= DEBUG_PRINT_INT10;
+#endif
+#if defined(CONFIG_X86EMU_DEBUG_INTERRUPTS) && CONFIG_X86EMU_DEBUG_INTERRUPTS
+	debug_flags |= DEBUG_INTR;
+#endif
+#if defined(CONFIG_X86EMU_DEBUG_CHECK_VMEM_ACCESS) && CONFIG_X86EMU_DEBUG_CHECK_VMEM_ACCESS
+	debug_flags |= DEBUG_CHECK_VMEM_ACCESS;
+#endif
+#if defined(CONFIG_X86EMU_DEBUG_MEM) && CONFIG_X86EMU_DEBUG_MEM
+	debug_flags |= DEBUG_MEM;
+#endif
+#if defined(CONFIG_X86EMU_DEBUG_IO) && CONFIG_X86EMU_DEBUG_IO
+	debug_flags |= DEBUG_IO;
+#endif
 
-	/* use CONFIG_YABEL_DEBUG_FLAGS, too... */
-	debug_flags |= CONFIG_YABEL_DEBUG_FLAGS;
 #endif
 	if (biosmem_size < MIN_REQUIRED_VMEM_SIZE) {
 		printf("Error: Not enough virtual memory: %x, required: %x!\n",
@@ -200,11 +228,11 @@
 	//TODO: check for further needed EBDA data...
 
 	// setup  original ROM BIOS Area (F000:xxxx)
-	char *date = "06/11/99";
+	const char *date = "06/11/99";
 	for (i = 0; date[i]; i++)
 		my_wrb(0xffff5 + i, date[i]);
 	// set up eisa ident string
-	char *ident = "PCI_ISA";
+	const char *ident = "PCI_ISA";
 	for (i = 0; ident[i]; i++)
 		my_wrb(0xfffd9 + i, ident[i]);
 
@@ -250,14 +278,14 @@
 	// push a HLT instruction and a pointer to it onto the stack
 	// any return will pop the pointer and jump to the HLT, thus
 	// exiting (more or less) cleanly
-	push_word(0xf4f4);	//F4=HLT
+	push_word(0xf4f4);	// F4=HLT
 	push_word(M.x86.R_SS);
 	push_word(M.x86.R_SP + 2);
 
 	CHECK_DBG(DEBUG_TRACE_X86EMU) {
 		X86EMU_trace_on();
+#if 0
 	} else {
-#ifdef DEBUG
 		M.x86.debug |= DEBUG_SAVE_IP_CS_F;
 		M.x86.debug |= DEBUG_DECODE_F;
 		M.x86.debug |= DEBUG_DECODE_NOPRINT_F;
@@ -268,7 +296,7 @@
 		M.x86.debug |= DEBUG_TRACEJMP_REGS_F;
 		M.x86.debug |= DEBUG_TRACECALL_F;
 		M.x86.debug |= DEBUG_TRACECALL_REGS_F;
-		}
+	}
 
 	DEBUG_PRINTF("Executing Initialization Vector...\n");
 	X86EMU_exec();
@@ -278,7 +306,7 @@
 	 * some boot device status in AX (see PNP BIOS Spec Section 3.3
 	 */
 	DEBUG_PRINTF_CS_IP("Option ROM Exit Status: %04x\n", M.x86.R_AX);
-#ifdef DEBUG
+#if defined(CONFIG_X86EMU_DEBUG) && CONFIG_X86EMU_DEBUG
 	DEBUG_PRINTF("Exit Status Decode:\n");
 	if (M.x86.R_AX & 0x100) {	// bit 8
 		DEBUG_PRINTF
@@ -344,14 +372,12 @@
 	    && (M.x86.R_SP == STACK_START_OFFSET)) {
 		DEBUG_PRINTF("Stack is clean, initialization successfull!\n");
 	} else {
-		DEBUG_PRINTF
-		    ("Stack unclean, initialization probably NOT COMPLETE!!\n");
+		printf("Stack unclean, initialization probably NOT COMPLETE!\n");
 		DEBUG_PRINTF("SS:SP = %04x:%04x, expected: %04x:%04x\n",
 			     M.x86.R_SS, M.x86.R_SP, STACK_SEGMENT,
 			     STACK_START_OFFSET);
 	}
 
-
 	// TODO: according to the BIOS Boot Spec initializations may be ended using INT18h and setting
 	// the status.
 	// We need to implement INT18 accordingly, pseudo code is in specsbbs101.pdf page 30

Modified: trunk/util/x86emu/yabel/biosemu.h
==============================================================================
--- trunk/util/x86emu/yabel/biosemu.h	Mon Mar  1 21:16:38 2010	(r5184)
+++ trunk/util/x86emu/yabel/biosemu.h	Fri Mar  5 11:03:50 2010	(r5185)
@@ -46,4 +46,7 @@
 typedef int (* yabel_handleIntFunc)(void);
 extern yabel_handleIntFunc yabel_intFuncArray[256];
 
+struct device;
+
+u32 biosemu(u8 *biosmem, u32 biosmem_size, struct device *dev, unsigned long rom_addr);
 #endif

Modified: trunk/util/x86emu/yabel/compat/functions.c
==============================================================================
--- trunk/util/x86emu/yabel/compat/functions.c	Mon Mar  1 21:16:38 2010	(r5184)
+++ trunk/util/x86emu/yabel/compat/functions.c	Fri Mar  5 11:03:50 2010	(r5185)
@@ -17,6 +17,7 @@
 #include <string.h>
 #include <device/device.h>
 #include "../debug.h"
+#include "../biosemu.h"
 
 #define VMEM_SIZE (1024 * 1024) /* 1 MB */
 
@@ -30,8 +31,6 @@
 u8* vmem = NULL;
 #endif
 
-u32 biosemu(u8 *biosmem, u32 biosmem_size, struct device *dev,
-	    unsigned long rom_addr);
 #if CONFIG_BOOTSPLASH
 void vbe_set_graphics(void);
 #endif
@@ -46,10 +45,10 @@
 #endif
 
 	if (vmem != NULL) {
-		printf("Copying legacy memory from 0x%08x to the lower 1MB\n", vmem);
-		memcpy(0x00000, vmem + 0x00000, 0x400);         // IVT
-		memcpy(0x00400, vmem + 0x00400, 0x100);         // BDA
-		memcpy(0xc0000, vmem + 0xc0000, 0x10000);       // VGA OPROM
+		printf("Copying legacy memory from %p to the lower 1MB\n", vmem);
+		memcpy((void *)0x00000, vmem + 0x00000, 0x400);         // IVT
+		memcpy((void *)0x00400, vmem + 0x00400, 0x100);         // BDA
+		memcpy((void *)0xc0000, vmem + 0xc0000, 0x10000);       // VGA OPROM
 	}
 }
 

Modified: trunk/util/x86emu/yabel/debug.h
==============================================================================
--- trunk/util/x86emu/yabel/debug.h	Mon Mar  1 21:16:38 2010	(r5184)
+++ trunk/util/x86emu/yabel/debug.h	Fri Mar  5 11:03:50 2010	(r5185)
@@ -21,21 +21,18 @@
 
 /* printf is not available in coreboot... use printk */
 #include <console/console.h>
-/* uurgs... yuck... x86emu/x86emu.h is redefining printk... we include it here
- * and use its redefinition of printk
- * TODO: FIX!!!! */
 #include "x86emu/x86emu.h"
-#define printf printk
+#define printf(x...) printk(BIOS_DEBUG, x)
 
 /* PH: empty versions of set/clr_ci
  * TODO: remove! */
 static inline void clr_ci(void) {};
 static inline void set_ci(void) {};
 
-/* Set CONFIG_YABEL_DEBUG_FLAGS is a binary switch that allows you
- * to select the following items to debug. 1=on 0=off. After you
- * decide what you want to debug create the binary value, convert to hex
- * and set the Option (Ex. CONFIG_YABEL_DEBUG_FLAGS = 0x31FF //Debug All).
+/* debug_flags is a binary switch that allows you to select the following items
+ * to debug. 1=on 0=off. After you decide what you want to debug create the
+ * binary value, convert to hex and set the option. These options can be
+ * selected in Kconfig.
  *
  * |-DEBUG_JMP - print info about JMP and RETF opcodes from x86emu
  * ||-DEBUG_TRACE_X86EMU - print _all_ opcodes that are executed by x86emu (WARNING: this will produce a LOT of output)
@@ -69,9 +66,7 @@
 // set to enable tracing of JMPs in x86emu
 #define DEBUG_JMP 0x2000
 
-//#define DEBUG
-//#undef DEBUG
-#ifdef DEBUG
+#if defined(CONFIG_X86EMU_DEBUG) && CONFIG_X86EMU_DEBUG
 
 #define CHECK_DBG(_flag) if (debug_flags & _flag)
 

Modified: trunk/util/x86emu/yabel/device.c
==============================================================================
--- trunk/util/x86emu/yabel/device.c	Mon Mar  1 21:16:38 2010	(r5184)
+++ trunk/util/x86emu/yabel/device.c	Fri Mar  5 11:03:50 2010	(r5185)
@@ -40,7 +40,7 @@
 #ifdef CONFIG_PCI_OPTION_ROM_RUN_YABEL
 /* coreboot version */
 
-void
+static void
 biosemu_dev_get_addr_info(void)
 {
 	int taa_index = 0;
@@ -112,7 +112,7 @@
 	}
 	// store last entry index of translate_address_array
 	taa_last_entry = taa_index - 1;
-#ifdef DEBUG
+#if defined(CONFIG_X86EMU_DEBUG) && CONFIG_X86EMU_DEBUG
 	//dump translate_address_array
 	printf("translate_address_array: \n");
 	translate_address_t ta;
@@ -195,7 +195,7 @@
 	}
 	// store last entry index of translate_address_array
 	taa_last_entry = taa_index - 1;
-#ifdef DEBUG
+#if defined(CONFIG_X86EMU_DEBUG) && CONFIG_X86EMU_DEBUG
 	//dump translate_address_array
 	printf("translate_address_array: \n");
 	translate_address_t ta;
@@ -210,11 +210,12 @@
 }
 #endif
 
+#ifndef CONFIG_PCI_OPTION_ROM_RUN_YABEL
 // to simulate accesses to legacy VGA Memory (0xA0000-0xBFFFF)
 // we look for the first prefetchable memory BAR, if no prefetchable BAR found,
 // we use the first memory BAR
 // dev_translate_addr will translate accesses to the legacy VGA Memory into the found vmem BAR
-void
+static void
 biosemu_dev_find_vmem_addr(void)
 {
 	int i = 0;
@@ -257,7 +258,6 @@
 	//bios_device.vmem_size = 0;
 }
 
-#ifndef CONFIG_PCI_OPTION_ROM_RUN_YABEL
 void
 biosemu_dev_get_puid(void)
 {
@@ -267,7 +267,7 @@
 }
 #endif
 
-void
+static void
 biosemu_dev_get_device_vendor_id(void)
 {
 
@@ -334,7 +334,7 @@
 		memcpy(&pci_ds, (void *) (rom_base_addr + pci_ds_offset),
 		       sizeof(pci_ds));
 		clr_ci();
-#ifdef DEBUG
+#if defined(CONFIG_X86EMU_DEBUG) && CONFIG_X86EMU_DEBUG
 		DEBUG_PRINTF("PCI Data Structure @%lx:\n",
 			     rom_base_addr + pci_ds_offset);
 		dump((void *) &pci_ds, sizeof(pci_ds));

Modified: trunk/util/x86emu/yabel/interrupt.c
==============================================================================
--- trunk/util/x86emu/yabel/interrupt.c	Mon Mar  1 21:16:38 2010	(r5184)
+++ trunk/util/x86emu/yabel/interrupt.c	Fri Mar  5 11:03:50 2010	(r5185)
@@ -11,6 +11,7 @@
  *     IBM Corporation - initial implementation
  *****************************************************************************/
 
+#include <types.h>
 #include "compat/rtas.h"
 
 #include "biosemu.h"
@@ -18,6 +19,7 @@
 #include "device.h"
 #include "debug.h"
 #include "pmm.h"
+#include "interrupt.h"
 
 #include <x86emu/x86emu.h>
 #include "../x86emu/prim_ops.h"

Modified: trunk/util/x86emu/yabel/io.c
==============================================================================
--- trunk/util/x86emu/yabel/io.c	Mon Mar  1 21:16:38 2010	(r5184)
+++ trunk/util/x86emu/yabel/io.c	Fri Mar  5 11:03:50 2010	(r5185)
@@ -17,6 +17,7 @@
 #include "device.h"
 #include "debug.h"
 #include <x86emu/x86emu.h>
+#include "io.h"
 
 #ifdef CONFIG_PCI_OPTION_ROM_RUN_YABEL
 #include <device/pci.h>
@@ -87,10 +88,7 @@
 	u8 val;
 
 	val = inb(addr);
-#ifdef CONFIG_DEBUG
-	if ((debug_flags & DEBUG_IO) && (addr != 0x40))
-	    printk("inb(0x%04x) = 0x%02x\n", addr, val);
-#endif
+	DEBUG_PRINTF_IO("inb(0x%04x) = 0x%02x\n", addr, val);
 
 	return val;
 }
@@ -100,11 +98,8 @@
 	u16 val;
 
 	val = inw(addr);
+	DEBUG_PRINTF_IO("inw(0x%04x) = 0x%04x\n", addr, val);
 
-#ifdef CONFIG_DEBUG
-	if (debug_flags & DEBUG_IO)
-		printk("inw(0x%04x) = 0x%04x\n", addr, val);
-#endif
 	return val;
 }
 
@@ -113,38 +108,26 @@
 	u32 val;
 
 	val = inl(addr);
+	DEBUG_PRINTF_IO("inl(0x%04x) = 0x%08x\n", addr, val);
 
-#ifdef CONFIG_DEBUG
-	if (debug_flags & DEBUG_IO)
-		printk("inl(0x%04x) = 0x%08x\n", addr, val);
-#endif
 	return val;
 }
 
 void my_outb(X86EMU_pioAddr addr, u8 val)
 {
-#ifdef CONFIG_DEBUG
-	if ((debug_flags & DEBUG_IO) && (addr != 0x43))
-		printk("outb(0x%02x, 0x%04x)\n", val, addr);
-#endif
+	DEBUG_PRINTF_IO("outb(0x%02x, 0x%04x)\n", val, addr);
 	outb(val, addr);
 }
 
 void my_outw(X86EMU_pioAddr addr, u16 val)
 {
-#ifdef CONFIG_DEBUG
-	if (debug_flags & DEBUG_IO)
-		printk("outw(0x%04x, 0x%04x)\n", val, addr);
-#endif
+	DEBUG_PRINTF_IO("outw(0x%04x, 0x%04x)\n", val, addr);
 	outw(val, addr);
 }
 
 void my_outl(X86EMU_pioAddr addr, u32 val)
 {
-#ifdef CONFIG_DEBUG
-	if (debug_flags & DEBUG_IO)
-		printk("outl(0x%08x, 0x%04x)\n", val, addr);
-#endif
+	DEBUG_PRINTF_IO("outl(0x%08x, 0x%04x)\n", val, addr);
 	outl(val, addr);
 }
 

Modified: trunk/util/x86emu/yabel/mem.c
==============================================================================
--- trunk/util/x86emu/yabel/mem.c	Mon Mar  1 21:16:38 2010	(r5184)
+++ trunk/util/x86emu/yabel/mem.c	Fri Mar  5 11:03:50 2010	(r5185)
@@ -16,10 +16,11 @@
 #include "device.h"
 #include "x86emu/x86emu.h"
 #include "biosemu.h"
+#include "mem.h"
 #include "compat/time.h"
 
 // define a check for access to certain (virtual) memory regions (interrupt handlers, BIOS Data Area, ...)
-#ifdef DEBUG
+#if CONFIG_X86EMU_DEBUG
 static u8 in_check = 0;	// to avoid recursion...
 u16 ebda_segment;
 u32 ebda_size;
@@ -27,11 +28,6 @@
 //TODO: these macros have grown so large, that they should be changed to an inline function,
 //just for the sake of readability...
 
-//declare prototypes of the functions to follow, for use in DEBUG_CHECK_VMEM_ACCESS
-u8 my_rdb(u32);
-u16 my_rdw(u32);
-u32 my_rdl(u32);
-
 #define DEBUG_CHECK_VMEM_READ(_addr, _rval) \
    if ((debug_flags & DEBUG_CHECK_VMEM_ACCESS) && (in_check == 0)) { \
          in_check = 1; \

Modified: trunk/util/x86emu/yabel/vbe.c
==============================================================================
--- trunk/util/x86emu/yabel/vbe.c	Mon Mar  1 21:16:38 2010	(r5184)
+++ trunk/util/x86emu/yabel/vbe.c	Fri Mar  5 11:03:50 2010	(r5185)
@@ -154,7 +154,7 @@
 }
 
 // VBE Function 00h
-u8
+static u8
 vbe_info(vbe_info_t * info)
 {
 	vbe_prepare();
@@ -223,7 +223,7 @@
 }
 
 // VBE Function 01h
-u8
+static u8
 vbe_get_mode_info(vbe_mode_info_t * mode_info)
 {
 	vbe_prepare();
@@ -264,7 +264,7 @@
 }
 
 // VBE Function 02h
-u8
+static u8
 vbe_set_mode(vbe_mode_info_t * mode_info)
 {
 	vbe_prepare();
@@ -301,7 +301,7 @@
 }
 
 //VBE Function 08h
-u8
+static u8
 vbe_set_palette_format(u8 format)
 {
 	vbe_prepare();
@@ -337,7 +337,7 @@
 }
 
 // VBE Function 09h
-u8
+static u8
 vbe_set_color(u16 color_number, u32 color_value)
 {
 	vbe_prepare();
@@ -379,7 +379,7 @@
 	return 0;
 }
 
-u8
+static u8
 vbe_get_color(u16 color_number, u32 * color_value)
 {
 	vbe_prepare();
@@ -422,7 +422,7 @@
 }
 
 // VBE Function 15h
-u8
+static u8
 vbe_get_ddc_info(vbe_ddc_info_t * ddc_info)
 {
 	vbe_prepare();
@@ -496,7 +496,7 @@
 	return 0;
 }
 
-u32
+static u32
 vbe_get_info(void)
 {
 	u8 rval;
@@ -571,7 +571,7 @@
 	}
 #endif
 	if (*((u64 *) ddc_info.edid_block_zero) !=
-	    (u64) 0x00FFFFFFFFFFFF00) {
+	    (u64) 0x00FFFFFFFFFFFF00ULL) {
 		// invalid EDID signature... probably no monitor
 
 		output->display_type = 0x0;
@@ -599,36 +599,36 @@
 
 		DEBUG_PRINTF_VBE("Video Mode 0x%04x available, %s\n",
 				 mode_info.video_mode,
-				 (mode_info.attributes & 0x1) ==
+				 (le16_to_cpu(mode_info.vesa.mode_attributes) & 0x1) ==
 				 0 ? "not supported" : "supported");
 		DEBUG_PRINTF_VBE("\tTTY: %s\n",
-				 (mode_info.attributes & 0x4) ==
+				 (le16_to_cpu(mode_info.vesa.mode_attributes) & 0x4) ==
 				 0 ? "no" : "yes");
 		DEBUG_PRINTF_VBE("\tMode: %s %s\n",
-				 (mode_info.attributes & 0x8) ==
+				 (le16_to_cpu(mode_info.vesa.mode_attributes) & 0x8) ==
 				 0 ? "monochrome" : "color",
-				 (mode_info.attributes & 0x10) ==
+				 (le16_to_cpu(mode_info.vesa.mode_attributes) & 0x10) ==
 				 0 ? "text" : "graphics");
 		DEBUG_PRINTF_VBE("\tVGA: %s\n",
-				 (mode_info.attributes & 0x20) ==
+				 (le16_to_cpu(mode_info.vesa.mode_attributes) & 0x20) ==
 				 0 ? "compatible" : "not compatible");
 		DEBUG_PRINTF_VBE("\tWindowed Mode: %s\n",
-				 (mode_info.attributes & 0x40) ==
+				 (le16_to_cpu(mode_info.vesa.mode_attributes) & 0x40) ==
 				 0 ? "yes" : "no");
 		DEBUG_PRINTF_VBE("\tFramebuffer: %s\n",
-				 (mode_info.attributes & 0x80) ==
+				 (le16_to_cpu(mode_info.vesa.mode_attributes) & 0x80) ==
 				 0 ? "no" : "yes");
 		DEBUG_PRINTF_VBE("\tResolution: %dx%d\n",
-				 mode_info.x_resolution,
-				 mode_info.y_resolution);
+				 le16_to_cpu(mode_info.vesa.x_resolution),
+				 le16_to_cpu(mode_info.vesa.y_resolution));
 		DEBUG_PRINTF_VBE("\tChar Size: %dx%d\n",
-				 mode_info.x_charsize, mode_info.y_charsize);
+				 mode_info.vesa.x_charsize, mode_info.vesa.y_charsize);
 		DEBUG_PRINTF_VBE("\tColor Depth: %dbpp\n",
-				 mode_info.bits_per_pixel);
+				 mode_info.vesa.bits_per_pixel);
 		DEBUG_PRINTF_VBE("\tMemory Model: 0x%x\n",
-				 mode_info.memory_model);
+				 mode_info.vesa.memory_model);
 		DEBUG_PRINTF_VBE("\tFramebuffer Offset: %08x\n",
-				 mode_info.framebuffer_address);
+				 le32_to_cpu(mode_info.vesa.phys_base_ptr));
 
 		if ((mode_info.vesa.bits_per_pixel == input.color_depth)
 		    && (le16_to_cpu(mode_info.vesa.x_resolution) <= input.max_screen_width)
@@ -647,10 +647,10 @@
 		DEBUG_PRINTF_VBE
 		    ("Best Video Mode found: 0x%x, %dx%d, %dbpp, framebuffer_address: 0x%x\n",
 		     best_mode_info.video_mode,
-		     best_mode_info.x_resolution,
-		     best_mode_info.y_resolution,
-		     best_mode_info.bits_per_pixel,
-		     best_mode_info.framebuffer_address);
+		     best_mode_info.vesa.x_resolution,
+		     best_mode_info.vesa.y_resolution,
+		     best_mode_info.vesa.bits_per_pixel,
+		     le32_to_cpu(best_mode_info.vesa.phys_base_ptr));
 
 		//printf("Mode Info Dump:");
 		//dump(best_mode_info.mode_info_block, 64);



From stepan at coresystems.de  Fri Mar  5 11:05:51 2010
From: stepan at coresystems.de (Stefan Reinauer)
Date: Fri, 05 Mar 2010 11:05:51 +0100
Subject: [coreboot] YABEL debug broken again
In-Reply-To: <b5765cdf1003050142o60a1245dt6bf0e52664db39d4@mail.gmail.com>
References: <4B8D8FC4.80402@settoplinux.org>	<832e9bde3adf490cf365995e479733a9@imap.1and1.com>	<2831fecf1003021514r7af3a50fjb91429419cb05b77@mail.gmail.com>	<d0766dd7592b54b6bf7f21f6cf7600d0@imap.1and1.com>	<476785AD44234B3F8B89D32B9D6711CA@chimp>	<963f95957548dc7619cc57c6d7c24699@imap.1and1.com>	<2831fecf1003030705j1caa78e2gbc8363da35bd691a@mail.gmail.com>
	<b5765cdf1003050142o60a1245dt6bf0e52664db39d4@mail.gmail.com>
Message-ID: <4B90D77F.2030501@coresystems.de>

On 3/5/10 10:42 AM, Pattrick Hueper wrote:
> Hi,
>
> i am trying to get a setup to fix this... but i cant even compile...
> in menuconfig for qemu i cant seem to set CONFIG_DEBUG and thus
> enabling YABEL_DEBUG breaks the build.
> If i manually set CONFIG_DEBUG=y in .config and then run make
> oldconfig, CONFIG_DEBUG is unset again.
>
> Help?
>
> Regards, Pattrick
Do svn up, r5185 should fix X86EMU/YABEL debugging and makes it
separately user selectable in "make menuconfig" under the "Debugging" menu.

Stefan




From stepan at coresystems.de  Fri Mar  5 11:13:34 2010
From: stepan at coresystems.de (Stefan Reinauer)
Date: Fri, 05 Mar 2010 11:13:34 +0100
Subject: [coreboot] [PATCH] sb600: don't load verb for codec
In-Reply-To: <DD1CC71B621B004FA76856E5129D6B17038260ED@sbjgexmb1.amd.com>
References: <DD1CC71B621B004FA76856E5129D6B17038260ED@sbjgexmb1.amd.com>
Message-ID: <4B90D94E.5000007@coresystems.de>

On 3/5/10 10:29 AM, Bao, Zheng wrote:
> Don't load verb in BIOS stage. It is not BIOS's responsibility.
>   
Who is responsible for that, then?
 
On i945 I definitely don't get sound on most systems if I don't load the
verb in coreboot. I also don't think the Linux drivers do it.
> And we can not have verb for every single codec.
>   
Have a look at the i82801gx southbridge; I think it was based on the
sb600 code, but I changed it so I can have a per mainboard verb table.
In mainboard_enable() in mainboard.c, call verb_setup() which does:

#include "hda_verb.h"

static void verb_setup(void)
{
        cim_verb_data = mainboard_cim_verb_data;
        cim_verb_data_size = sizeof(mainboard_cim_verb_data);
}

and hda_verb.c looks like this:

static u32 mainboard_cim_verb_data[] = {
        /* coreboot specific header */
        0x10ec0262,     // Codec Vendor ID / Device ID
        0x10714700,     // Subsystem ID
        0x0000000d,     // Number of jacks

        /* HDA Codec Subsystem ID Verb Table: 0x10ec0000 */
        0x00172000,
        0x00172100,
        0x001722EC,
        0x00172310,

        /* Pin Widget Verb Table */

        /* Pin Complex (NID 0x12) */
        0x01271CF0,
        0x01271D11,
        0x01271E11,
...
};

extern u32 * cim_verb_data;
extern u32 cim_verb_data_size;





From phueper at hueper.net  Fri Mar  5 11:20:02 2010
From: phueper at hueper.net (Pattrick Hueper)
Date: Fri, 5 Mar 2010 11:20:02 +0100
Subject: [coreboot] YABEL debug broken again
In-Reply-To: <4B90D77F.2030501@coresystems.de>
References: <4B8D8FC4.80402@settoplinux.org>
	<832e9bde3adf490cf365995e479733a9@imap.1and1.com>
	<2831fecf1003021514r7af3a50fjb91429419cb05b77@mail.gmail.com>
	<d0766dd7592b54b6bf7f21f6cf7600d0@imap.1and1.com>
	<476785AD44234B3F8B89D32B9D6711CA@chimp>
	<963f95957548dc7619cc57c6d7c24699@imap.1and1.com>
	<2831fecf1003030705j1caa78e2gbc8363da35bd691a@mail.gmail.com>
	<b5765cdf1003050142o60a1245dt6bf0e52664db39d4@mail.gmail.com>
	<4B90D77F.2030501@coresystems.de>
Message-ID: <b5765cdf1003050220nadf2be7g8161c0f1288de099@mail.gmail.com>

Ah... very cool...

so Josephs issue with VBE debugging is resolved as well?

Patty

On Fri, Mar 5, 2010 at 11:05 AM, Stefan Reinauer <stepan at coresystems.de> wrote:
> On 3/5/10 10:42 AM, Pattrick Hueper wrote:
>> Hi,
>>
>> i am trying to get a setup to fix this... but i cant even compile...
>> in menuconfig for qemu i cant seem to set CONFIG_DEBUG and thus
>> enabling YABEL_DEBUG breaks the build.
>> If i manually set CONFIG_DEBUG=y in .config and then run make
>> oldconfig, CONFIG_DEBUG is unset again.
>>
>> Help?
>>
>> Regards, Pattrick
> Do svn up, r5185 should fix X86EMU/YABEL debugging and makes it
> separately user selectable in "make menuconfig" under the "Debugging" menu.
>
> Stefan
>
>
> --
> coreboot mailing list: coreboot at coreboot.org
> http://www.coreboot.org/mailman/listinfo/coreboot
>



From svn at coreboot.org  Fri Mar  5 11:20:28 2010
From: svn at coreboot.org (repository service)
Date: Fri, 05 Mar 2010 11:20:28 +0100
Subject: [coreboot] [commit] r5186 - trunk
Message-ID: <E1NnUdw-0003hu-QA@ra.coresystems.de>

Author: stepan
Date: Fri Mar  5 11:20:28 2010
New Revision: 5186
URL: http://tracker.coreboot.org/trac/coreboot/changeset/5186

Log:
This patch fixes two things:

- -m32 is already defined by xcompile if the compiler is a 64bit compiler so
  drop it from the Makefile.
- allow "obj-.. += foo.o" for util/, too. Otherwise the source files in
  util/x86emu/ put their objects in util/ instead of $(obj)/util

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

Modified:
   trunk/Makefile

Modified: trunk/Makefile
==============================================================================
--- trunk/Makefile	Fri Mar  5 11:03:50 2010	(r5185)
+++ trunk/Makefile	Fri Mar  5 11:20:28 2010	(r5186)
@@ -119,7 +119,7 @@
 crt0s:=
 ldscripts:=
 types:=obj initobj driver smmobj
-includemakefiles=$(foreach type,$(2), $(eval $(type)-y:=)) $(eval subdirs-y:=) $(eval -include $(1)) $(if $(strip $(3)),$(foreach type,$(2),$(eval $(type)s+=$$(patsubst src/%,$(obj)/%,$$(addprefix $(dir $(1)),$$($(type)-y)))))) $(eval subdirs+=$$(subst $(PWD)/,,$$(abspath $$(addprefix $(dir $(1)),$$(subdirs-y)))))
+includemakefiles=$(foreach type,$(2), $(eval $(type)-y:=)) $(eval subdirs-y:=) $(eval -include $(1)) $(if $(strip $(3)),$(foreach type,$(2),$(eval $(type)s+=$$(patsubst util/%,$(obj)/util/%,$$(patsubst src/%,$(obj)/%,$$(addprefix $(dir $(1)),$$($(type)-y))))))) $(eval subdirs+=$$(subst $(PWD)/,,$$(abspath $$(addprefix $(dir $(1)),$$(subdirs-y)))))
 evaluate_subdirs=$(eval cursubdirs:=$(subdirs)) $(eval subdirs:=) $(foreach dir,$(cursubdirs),$(eval $(call includemakefiles,$(dir)/Makefile.inc,$(types),$(1)))) $(if $(subdirs),$(eval $(call evaluate_subdirs, $(1))))
 
 # collect all object files eligible for building
@@ -148,55 +148,63 @@
 	$(CPP) -D__ACPI__ -P $(CPPFLAGS) -include $(obj)/config.h -I$(src) -I$(src)/mainboard/$(MAINBOARDDIR) $$< -o $$(basename $$@).asl
 	iasl -p $$(basename $$@) -tc $$(basename $$@).asl
 	mv $$(basename $$@).hex $$(basename $$@).c
-	$(CC) -m32 $$(CFLAGS) $$(if $$(subst dsdt,,$$(basename $$(notdir $$@))), -DAmlCode=AmlCode_$$(basename $$(notdir $$@))) -c -o $$@ $$(basename $$@).c
+	$(CC) $$(CFLAGS) $$(if $$(subst dsdt,,$$(basename $$(notdir $$@))), -DAmlCode=AmlCode_$$(basename $$(notdir $$@))) -c -o $$@ $$(basename $$@).c
 endef
 
 define objs_c_template
+$(obj)/$(1)%.o: $(1)%.c $(obj)/config.h
+	@printf "    CC         $$(subst $$(obj)/,,$$(@))\n"
+	$(CC) $$(CFLAGS) -c -o $$@ $$<
+
 $(obj)/$(1)%.o: src/$(1)%.c $(obj)/config.h
 	@printf "    CC         $$(subst $$(obj)/,,$$(@))\n"
-	$(CC) -m32 $$(CFLAGS) -c -o $$@ $$<
+	$(CC) $$(CFLAGS) -c -o $$@ $$<
 endef
 
 define objs_S_template
+$(obj)/$(1)%.o: $(1)%.S $(obj)/config.h
+	@printf "    CC         $$(subst $$(obj)/,,$$(@))\n"
+	$(CC) -DASSEMBLY $$(CFLAGS) -c -o $$@ $$<
+
 $(obj)/$(1)%.o: src/$(1)%.S $(obj)/config.h
 	@printf "    CC         $$(subst $$(obj)/,,$$(@))\n"
-	$(CC) -m32 -DASSEMBLY $$(CFLAGS) -c -o $$@ $$<
+	$(CC) -DASSEMBLY $$(CFLAGS) -c -o $$@ $$<
 endef
 
 define initobjs_c_template
 $(obj)/$(1)%.initobj.o: src/$(1)%.c $(obj)/config.h
 	@printf "    CC         $$(subst $$(obj)/,,$$(@))\n"
-	$(CC) -m32 $$(CFLAGS) -c -o $$@ $$<
+	$(CC) $$(CFLAGS) -c -o $$@ $$<
 endef
 
 define initobjs_S_template
 $(obj)/$(1)%.initobj.o: src/$(1)%.S $(obj)/config.h
 	@printf "    CC         $$(subst $$(obj)/,,$$(@))\n"
-	$(CC) -m32 -DASSEMBLY $$(CFLAGS) -c -o $$@ $$<
+	$(CC) -DASSEMBLY $$(CFLAGS) -c -o $$@ $$<
 endef
 
 define drivers_c_template
 $(obj)/$(1)%.driver.o: src/$(1)%.c $(obj)/config.h
 	@printf "    CC         $$(subst $$(obj)/,,$$(@))\n"
-	$(CC) -m32 $$(CFLAGS) -c -o $$@ $$<
+	$(CC) $$(CFLAGS) -c -o $$@ $$<
 endef
 
 define drivers_S_template
 $(obj)/$(1)%.driver.o: src/$(1)%.S
 	@printf "    CC         $$(subst $$(obj)/,,$$(@))\n"
-	$(CC) -m32 -DASSEMBLY $$(CFLAGS) -c -o $$@ $$<
+	$(CC) -DASSEMBLY $$(CFLAGS) -c -o $$@ $$<
 endef
 
 define smmobjs_c_template
 $(obj)/$(1)%.smmobj.o: src/$(1)%.c
 	@printf "    CC         $$(subst $$(obj)/,,$$(@))\n"
-	$(CC) -m32 $$(CFLAGS) -c -o $$@ $$<
+	$(CC) $$(CFLAGS) -c -o $$@ $$<
 endef
 
 define smmobjs_S_template
 $(obj)/$(1)%.smmobj.o: src/$(1)%.S
 	@printf "    CC         $$(subst $$(obj)/,,$$(@))\n"
-	$(CC) -m32 $$(CFLAGS) -c -o $$@ $$<
+	$(CC) $$(CFLAGS) -c -o $$@ $$<
 endef
 
 usetemplate=$(foreach d,$(sort $(dir $($(1)))),$(eval $(call $(1)_$(2)_template,$(subst $(obj)/,,$(d)))))



From stepan at coresystems.de  Fri Mar  5 11:21:51 2010
From: stepan at coresystems.de (Stefan Reinauer)
Date: Fri, 05 Mar 2010 11:21:51 +0100
Subject: [coreboot] YABEL debug broken again
In-Reply-To: <b5765cdf1003050220nadf2be7g8161c0f1288de099@mail.gmail.com>
References: <4B8D8FC4.80402@settoplinux.org>	
	<832e9bde3adf490cf365995e479733a9@imap.1and1.com>	
	<2831fecf1003021514r7af3a50fjb91429419cb05b77@mail.gmail.com>	
	<d0766dd7592b54b6bf7f21f6cf7600d0@imap.1and1.com>	
	<476785AD44234B3F8B89D32B9D6711CA@chimp>	
	<963f95957548dc7619cc57c6d7c24699@imap.1and1.com>	
	<2831fecf1003030705j1caa78e2gbc8363da35bd691a@mail.gmail.com>	
	<b5765cdf1003050142o60a1245dt6bf0e52664db39d4@mail.gmail.com>	
	<4B90D77F.2030501@coresystems.de>
	<b5765cdf1003050220nadf2be7g8161c0f1288de099@mail.gmail.com>
Message-ID: <4B90DB3F.5020105@coresystems.de>

On 3/5/10 11:20 AM, Pattrick Hueper wrote:
> Ah... very cool...
>
> so Josephs issue with VBE debugging is resolved as well?
>
> Patty
>   
Worked for me... The X86EMU_DEBUG code may want some more tweaking to
make it more silent / verbose with some of the flags, though



From joe at settoplinux.org  Fri Mar  5 13:02:53 2010
From: joe at settoplinux.org (Joseph Smith)
Date: Fri, 05 Mar 2010 07:02:53 -0500
Subject: [coreboot] [PATCH] ASUS P2B-LS support, RAM detection for 440BX,
 add Slot 1 CPU, Microcode for Intel Tualatin CPUs
In-Reply-To: <b72cdb061003042153j7ca4cf18p8985778a102807f1@mail.gmail.com>
References: <b72cdb061003022019x18ab2b0fo7de47d2d1b0f9609@mail.gmail.com>	
	<4B8FB521.7040503@settoplinux.org>
	<b72cdb061003042153j7ca4cf18p8985778a102807f1@mail.gmail.com>
Message-ID: <4B90F2ED.2070706@settoplinux.org>

On 03/05/2010 12:53 AM, Keith Hui wrote:
>
>
> On Thu, Mar 4, 2010 at 8:26 AM, Joseph Smith <joe at settoplinux.org
> <mailto:joe at settoplinux.org>> wrote:
>
>     I would not worry about the microcode updates right now. CAR for
>     Intel 6bx is coming real soon and the microcode updates will be
>     included :-)
>
> CAN'T WAIT! :D Then I can say goodbye to the messiness that is romcc, lol.
>
>
>     **********You are setting alot more than just dra here, I would
>     rename this function something like sdram_setup_registers().
>
> Good point. Eventually I wanted to name it sdram_initalize() just like
> i830, but there are a couple other references to the current names
> elsewhere. One step at a time I guess.
>
>
>
>     ************I also noticed you did not use the memory initialize
>     each row/side code from the i830. That code is extremely important
>     for multiple memory sticks. Besides that everything else looks
>     really good, great work!
>
> There were some code that send RAM commands to the modules in the BX
> code. I just kept them around, thinking that this code in i830 may be
> specific to i830.
>
The only code that may be specific to the i830 is the DRC regs. Also you 
may have to tweek:

dimm_end = pci_read_config8(NORTHBRIDGE, DRB + row);

for the 440bx. This basicly reading the sdram size to set as the start 
of the next row.

The rest of the routine (and I have researched it extensively) is pretty 
much the standard for sdram initialization.

> Mark, the problem you saw might be MBFS and MBSC not being set properly.
> I have reversed how the factory BIOS programmed them and have the code
> in my working copy. I'll see if that makes a difference. We are still
> hardcoded to CAS3 latency. One step at a time again I guess.
>
> On another front, with the board running factory BIOS, I dumped the BX's
> config space (lspci -s 0:0:0.0 -xxx) with various DIMM configurations,
> especially with two sticks in DIMM0&1, DIMM2&3, and 3 sticks. These
> three scenarios are where most of the logics are. I can post them if
> anyone wants to look at them. All my RAMs are double sided, one 128MB
> and the others are 256MB.
>
> To figure out how this gets coded for the 3-slot P2B, Someone would need
> to reverse the vendor bios for that board or do same as above.
>
FYI, serialice is awesome at dumping raminit routines :-)


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



From joe at settoplinux.org  Fri Mar  5 13:05:57 2010
From: joe at settoplinux.org (Joseph Smith)
Date: Fri, 05 Mar 2010 07:05:57 -0500
Subject: [coreboot] [PATCH] ASUS P2B-LS support, RAM detection for 440BX,
 add Slot 1 CPU, Microcode for Intel Tualatin CPUs
In-Reply-To: <4B90BAC9.2090901@ntlworld.com>
References: <b72cdb061003022019x18ab2b0fo7de47d2d1b0f9609@mail.gmail.com>	<4B8F8605.7010700@ntlworld.com>	<20100304123006.GC13408@greenwood>	<4B8FA9D5.5050901@settoplinux.org>	<4B8FB129.3020102@settoplinux.org>
	<4B90BAC9.2090901@ntlworld.com>
Message-ID: <4B90F3A5.2080301@settoplinux.org>

On 03/05/2010 03:03 AM, Mark Marshall wrote:
> On 04/03/10 13:10, Joseph Smith wrote:
>> On 03/04/2010 07:38 AM, Joseph Smith wrote:
>>> On 03/04/2010 07:30 AM, Uwe Hermann wrote:
>>>> On Thu, Mar 04, 2010 at 10:05:57AM +0000, Mark Marshall wrote:
>>>>> On 03/03/10 04:19, Keith Hui wrote:
>>>>> The first problem is that this motherboard only has three DIMM
>>>>> slots. This means you have to set SDRAMC to something different;
>>>>> 0x0103 works for me.
>>>>>
>>>> Hm, seems to be determined by SDRAMPWR + MMCONFIG, and MMCONFIG
>>>> seems to
>>>> be a hardware-strap (so we can check it), but not sure about SDRAMPWR.
>>>>
>> >>>
>> I think a simple SPD probe would work, if the correct value is returned
>> you know you have memory in that slot, otherwise if 0xff is returned
>> then no memory is present. Do this probe for as many slots as the 440
>> supports. Then set your registers based on that.
>
> The issue here is the number of DIMM slots on the motherboard, not the
> number of sticks in the slots. Some 440BX boards have four slots, while
> others only have three.
>
> MM
>
That is fine. Then if 440bx datasheet says it supports 4 slots, then 
that should be the standard.

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



From joe at settoplinux.org  Fri Mar  5 13:11:23 2010
From: joe at settoplinux.org (Joseph Smith)
Date: Fri, 05 Mar 2010 07:11:23 -0500
Subject: [coreboot] YABEL debug broken again
In-Reply-To: <b5765cdf1003050142o60a1245dt6bf0e52664db39d4@mail.gmail.com>
References: <4B8D8FC4.80402@settoplinux.org>	<832e9bde3adf490cf365995e479733a9@imap.1and1.com>	<2831fecf1003021514r7af3a50fjb91429419cb05b77@mail.gmail.com>	<d0766dd7592b54b6bf7f21f6cf7600d0@imap.1and1.com>	<476785AD44234B3F8B89D32B9D6711CA@chimp>	<963f95957548dc7619cc57c6d7c24699@imap.1and1.com>	<2831fecf1003030705j1caa78e2gbc8363da35bd691a@mail.gmail.com>
	<b5765cdf1003050142o60a1245dt6bf0e52664db39d4@mail.gmail.com>
Message-ID: <4B90F4EB.8050500@settoplinux.org>

On 03/05/2010 04:42 AM, Pattrick Hueper wrote:
> Hi,
>
> i am trying to get a setup to fix this... but i cant even compile...
> in menuconfig for qemu i cant seem to set CONFIG_DEBUG and thus
> enabling YABEL_DEBUG breaks the build.
> If i manually set CONFIG_DEBUG=y in .config and then run make
> oldconfig, CONFIG_DEBUG is unset again.
>
> Help?
>
> Regards, Pattrick
>
>
>
> On Wed, Mar 3, 2010 at 4:05 PM, Myles Watson<mylesgw at gmail.com>  wrote:
>>
>>>>>> It compiles for me with 5132, but not 5135.  You could look at the
>>>>> changes:
>>>>>> http://tracker.coreboot.org/trac/coreboot/changeset/5135
>>>>>>
>>>> Yes.  It compiles without debug, right?
>>>>
>>> Yes.
>>>
>>>> If I were you I'd comment out the debugging statements that are breaking
>>>> for
>>>> you, unless you are trying to debug the vbe code.  It looks like
>>>> framebuffer_address and friends were commented out in 5135.
>>>>
>>> Well I was kind of looking forward to the vbe debug. Hmm.
>>
>> You'd still get some information from the debugging statements that work,
>> but the statements referencing undefined variables are not likely to give
>> you any good information.
>>
Hello Pattrick.
We made the CONFIG_DEBUG automatic.

-------------------------
Author: myles
Date: Fri Feb 19 20:08:11 2010
New Revision: 5131
URL: http://tracker.coreboot.org/trac/coreboot/changeset/5131

Log:
1. Change CONFIG_DEBUG to DEBUG in util/x86emu/*
2. Make DEBUG depend on CONFIG_YABEL_DEBUG_FLAGS being nonzero
--------------------------------


Attached is a copy of my config.h for reference.


-- 
Thanks,
Joseph Smith
Set-Top-Linux
www.settoplinux.org
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: config.h
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20100305/0bc234f2/attachment.h>

From joe at settoplinux.org  Fri Mar  5 13:15:40 2010
From: joe at settoplinux.org (Joseph Smith)
Date: Fri, 05 Mar 2010 07:15:40 -0500
Subject: [coreboot] YABEL debug broken again
In-Reply-To: <4B90DB3F.5020105@coresystems.de>
References: <4B8D8FC4.80402@settoplinux.org>		<832e9bde3adf490cf365995e479733a9@imap.1and1.com>		<2831fecf1003021514r7af3a50fjb91429419cb05b77@mail.gmail.com>		<d0766dd7592b54b6bf7f21f6cf7600d0@imap.1and1.com>		<476785AD44234B3F8B89D32B9D6711CA@chimp>		<963f95957548dc7619cc57c6d7c24699@imap.1and1.com>		<2831fecf1003030705j1caa78e2gbc8363da35bd691a@mail.gmail.com>		<b5765cdf1003050142o60a1245dt6bf0e52664db39d4@mail.gmail.com>		<4B90D77F.2030501@coresystems.de>	<b5765cdf1003050220nadf2be7g8161c0f1288de099@mail.gmail.com>
	<4B90DB3F.5020105@coresystems.de>
Message-ID: <4B90F5EC.8040504@settoplinux.org>

On 03/05/2010 05:21 AM, Stefan Reinauer wrote:
> On 3/5/10 11:20 AM, Pattrick Hueper wrote:
>> Ah... very cool...
>>
>> so Josephs issue with VBE debugging is resolved as well?
>>
>> Patty
>>
> Worked for me... The X86EMU_DEBUG code may want some more tweaking to
> make it more silent / verbose with some of the flags, though
>
Ah, cool. I will try it out and let you know. I think a debugging menu 
is a great idea.

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



From stepan at coresystems.de  Fri Mar  5 13:30:40 2010
From: stepan at coresystems.de (Stefan Reinauer)
Date: Fri, 05 Mar 2010 13:30:40 +0100
Subject: [coreboot] YABEL debug broken again
In-Reply-To: <4B90F4EB.8050500@settoplinux.org>
References: <4B8D8FC4.80402@settoplinux.org>	<832e9bde3adf490cf365995e479733a9@imap.1and1.com>	<2831fecf1003021514r7af3a50fjb91429419cb05b77@mail.gmail.com>	<d0766dd7592b54b6bf7f21f6cf7600d0@imap.1and1.com>	<476785AD44234B3F8B89D32B9D6711CA@chimp>	<963f95957548dc7619cc57c6d7c24699@imap.1and1.com>	<2831fecf1003030705j1caa78e2gbc8363da35bd691a@mail.gmail.com>
	<b5765cdf1003050142o60a1245dt6bf0e52664db39d4@mail.gmail.com>
	<4B90F4EB.8050500@settoplinux.org>
Message-ID: <4B90F970.9090403@coresystems.de>

On 3/5/10 1:11 PM, Joseph Smith wrote:
>>> You'd still get some information from the debugging statements that
>>> work,
>>> but the statements referencing undefined variables are not likely to
>>> give
>>> you any good information.
>>>
>
> Hello Pattrick.
> We made the CONFIG_DEBUG automatic.
The code that was causing the errors in vbe.c was not being called, so
no gain, just pain ;-) But it compiles anyways, now.



From mark.marshall at csr.com  Fri Mar  5 14:04:27 2010
From: mark.marshall at csr.com (Mark Marshall)
Date: Fri, 05 Mar 2010 13:04:27 +0000
Subject: [coreboot] [PATCH] ASUS P2B-LS support, RAM detection for 440BX,
 add Slot 1 CPU, Microcode for Intel Tualatin CPUs
In-Reply-To: <4B90F3A5.2080301@settoplinux.org>
References: <b72cdb061003022019x18ab2b0fo7de47d2d1b0f9609@mail.gmail.com>	<4B8F8605.7010700@ntlworld.com>	<20100304123006.GC13408@greenwood>	<4B8FA9D5.5050901@settoplinux.org>	<4B8FB129.3020102@settoplinux.org>	<4B90BAC9.2090901@ntlworld.com>
	<4B90F3A5.2080301@settoplinux.org>
Message-ID: <4B91015B.7020602@csr.com>

Joseph Smith wrote:
> On 03/05/2010 03:03 AM, Mark Marshall wrote:
>> On 04/03/10 13:10, Joseph Smith wrote:
>>> On 03/04/2010 07:38 AM, Joseph Smith wrote:
>>>> On 03/04/2010 07:30 AM, Uwe Hermann wrote:
>>>>> On Thu, Mar 04, 2010 at 10:05:57AM +0000, Mark Marshall wrote:
>>>>>> On 03/03/10 04:19, Keith Hui wrote:
>>>>>> The first problem is that this motherboard only has three DIMM
>>>>>> slots. This means you have to set SDRAMC to something different;
>>>>>> 0x0103 works for me.
>>>>>>
>>>>> Hm, seems to be determined by SDRAMPWR + MMCONFIG, and MMCONFIG
>>>>> seems to
>>>>> be a hardware-strap (so we can check it), but not sure about SDRAMPWR.
>>>>>
>>> >>>
>>> I think a simple SPD probe would work, if the correct value is returned
>>> you know you have memory in that slot, otherwise if 0xff is returned
>>> then no memory is present. Do this probe for as many slots as the 440
>>> supports. Then set your registers based on that.
>>
>> The issue here is the number of DIMM slots on the motherboard, not the
>> number of sticks in the slots. Some 440BX boards have four slots, while
>> others only have three.
>>
>> MM
>>
> That is fine. Then if 440bx datasheet says it supports 4 slots, then 
> that should be the standard.
> 

Please check this section of the 440BX data sheet.

   3.3.24 SDRAMC?SDRAM Control Register (Device 0)

We are interested in bit 4.

  SDRAMPWR. The SDRAMPWR bit controls how the CKE signals are driven
  for different DRAM configurations. For a 3 DIMM configuration,
  SDRAMPWR should be set to ?0?. For a 4 DIMM configuration,
  SDRAMPWR should be set to ?1?. In this case the 82443BX drives a
  single CKE signal (GCKE). The combination of SDRAMPWR and MMCONFIG
  (DRAMC register) determine the functioning of the CKE signals.
  Refer to the DRAMC register (Section 3.3.15, ?DRAMC?DRAM
  Control Register (Device 0)? on page 3-19) for more details.

  Note: When PCIRST# assertion occurs during POS/STR, these bits
  are not reset to 0.

As far as I can tell we cannot auto-detect this.  Some (many)
440BX boards only have three DIMM slots, and in these cases the
clocks are routed differently to the boards with four DIMM slots.

MM




From andrew.goodbody at tadpole.com  Fri Mar  5 12:15:38 2010
From: andrew.goodbody at tadpole.com (Andrew Goodbody)
Date: Fri, 05 Mar 2010 03:15:38 -0800
Subject: [coreboot] [PATCH] sb600: don't load verb for codec
In-Reply-To: <4B90D94E.5000007@coresystems.de>
References: <DD1CC71B621B004FA76856E5129D6B17038260ED@sbjgexmb1.amd.com>
	<4B90D94E.5000007@coresystems.de>
Message-ID: <4B90E7DA.8090303@tadpole.com>

Stefan Reinauer wrote:
> On 3/5/10 10:29 AM, Bao, Zheng wrote:
>> Don't load verb in BIOS stage. It is not BIOS's responsibility.
>>   
> Who is responsible for that, then?

Those verbs are motherboard specific as they describe the actual 
external connections so they should not be in southbridge code. They 
cannot be inferred by the driver so they absolutely should be done by 
coreboot. So they should be moved to motherboard specific code not 
dropped entirely.

Andrew



From c-d.hailfinger.devel.2006 at gmx.net  Fri Mar  5 15:03:19 2010
From: c-d.hailfinger.devel.2006 at gmx.net (Carl-Daniel Hailfinger)
Date: Fri, 05 Mar 2010 15:03:19 +0100
Subject: [coreboot] [PATCH] sb600: don't load verb for codec
In-Reply-To: <4B90D94E.5000007@coresystems.de>
References: <DD1CC71B621B004FA76856E5129D6B17038260ED@sbjgexmb1.amd.com>
	<4B90D94E.5000007@coresystems.de>
Message-ID: <4B910F27.7030903@gmx.net>

On 05.03.2010 11:13, Stefan Reinauer wrote:
> On 3/5/10 10:29 AM, Bao, Zheng wrote:
>   
>> Don't load verb in BIOS stage. It is not BIOS's responsibility.
>>   
>>     
> Who is responsible for that, then?
>  
> On i945 I definitely don't get sound on most systems if I don't load the
> verb in coreboot. I also don't think the Linux drivers do it.
>   
>> And we can not have verb for every single codec.
>>   
>>     
> Have a look at the i82801gx southbridge; I think it was based on the
> sb600 code, but I changed it so I can have a per mainboard verb table.
>   

I think we should try to mirror the behaviour of the vendor BIOS. The
Linux kernel source has some interesting info about HD Audio:
http://www.mjmwired.net/kernel/Documentation/sound/alsa/HD-Audio.txt

Regards,
Carl-Daniel

-- 
"I do consider assignment statements and pointer variables to be among
computer science's most valuable treasures."
-- Donald E. Knuth




From joe at settoplinux.org  Fri Mar  5 15:15:05 2010
From: joe at settoplinux.org (Joseph Smith)
Date: Fri, 05 Mar 2010 09:15:05 -0500
Subject: [coreboot] [PATCH] ASUS P2B-LS support, RAM detection for 440BX,
 add Slot 1 CPU, Microcode for Intel Tualatin CPUs
In-Reply-To: <4B91015B.7020602@csr.com>
References: <b72cdb061003022019x18ab2b0fo7de47d2d1b0f9609@mail.gmail.com>	<4B8F8605.7010700@ntlworld.com>	<20100304123006.GC13408@greenwood>	<4B8FA9D5.5050901@settoplinux.org>	<4B8FB129.3020102@settoplinux.org>	<4B90BAC9.2090901@ntlworld.com>
	<4B90F3A5.2080301@settoplinux.org> <4B91015B.7020602@csr.com>
Message-ID: <01dad3b81ca0551beea67320b55d248b@imap.1and1.com>




On Fri, 05 Mar 2010 13:04:27 +0000, Mark Marshall <mark.marshall at csr.com>
wrote:
> Joseph Smith wrote:
>> On 03/05/2010 03:03 AM, Mark Marshall wrote:
>>> On 04/03/10 13:10, Joseph Smith wrote:
>>>> On 03/04/2010 07:38 AM, Joseph Smith wrote:
>>>>> On 03/04/2010 07:30 AM, Uwe Hermann wrote:
>>>>>> On Thu, Mar 04, 2010 at 10:05:57AM +0000, Mark Marshall wrote:
>>>>>>> On 03/03/10 04:19, Keith Hui wrote:
>>>>>>> The first problem is that this motherboard only has three DIMM
>>>>>>> slots. This means you have to set SDRAMC to something different;
>>>>>>> 0x0103 works for me.
>>>>>>>
>>>>>> Hm, seems to be determined by SDRAMPWR + MMCONFIG, and MMCONFIG
>>>>>> seems to
>>>>>> be a hardware-strap (so we can check it), but not sure about
> SDRAMPWR.
>>>>>>
>>>> >>>
>>>> I think a simple SPD probe would work, if the correct value is
returned
>>>> you know you have memory in that slot, otherwise if 0xff is returned
>>>> then no memory is present. Do this probe for as many slots as the 440
>>>> supports. Then set your registers based on that.
>>>
>>> The issue here is the number of DIMM slots on the motherboard, not the
>>> number of sticks in the slots. Some 440BX boards have four slots, while
>>> others only have three.
>>>
>>> MM
>>>
>> That is fine. Then if 440bx datasheet says it supports 4 slots, then 
>> that should be the standard.
>> 
> 
> Please check this section of the 440BX data sheet.
> 
>    3.3.24 SDRAMC?SDRAM Control Register (Device 0)
> 
> We are interested in bit 4.
> 
>   SDRAMPWR. The SDRAMPWR bit controls how the CKE signals are driven
>   for different DRAM configurations. For a 3 DIMM configuration,
>   SDRAMPWR should be set to ?0?. For a 4 DIMM configuration,
>   SDRAMPWR should be set to ?1?. In this case the 82443BX drives a
>   single CKE signal (GCKE). The combination of SDRAMPWR and MMCONFIG
>   (DRAMC register) determine the functioning of the CKE signals.
>   Refer to the DRAMC register (Section 3.3.15, ?DRAMC?DRAM
>   Control Register (Device 0)? on page 3-19) for more details.
> 
>   Note: When PCIRST# assertion occurs during POS/STR, these bits
>   are not reset to 0.
> 
> As far as I can tell we cannot auto-detect this.  Some (many)
> 440BX boards only have three DIMM slots, and in these cases the
> clocks are routed differently to the boards with four DIMM slots.
> 
That's easy... so you do something like this:

slot4_detect = (spd_read_byte((DIMM_SPD_BASE + 3), SPD_MEMORY_TYPE);

if (slot4_detect != 0xff) {

     /* We have 4 slots */
     ----Set bit 4 in SDRAMPWR----
     #define DIMM_SOCKETS 4
} else {

     /* We have 3 slots */
     ----Set bit 4 in SDRAMPWR----
     #define DIMM_SOCKETS 3
}

Hope that helps.

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




From arne.gleditsch at numascale.com  Fri Mar  5 15:37:07 2010
From: arne.gleditsch at numascale.com (Arne Georg Gleditsch)
Date: Fri, 05 Mar 2010 15:37:07 +0100
Subject: [coreboot] [PATCH] ulzma delay
Message-ID: <4B911713.3090805@numascale.com>

Hi,

In the same way as unrv2b used to, ulzma exhibits very bad instruction
fetch behavior on my Opteron CPUs/Tyan S2912 board.  I'm not entirely
sure what causes this, and despite having spent significant time digging
through it I'm not able to mend this by adjusting MTRRs or other cache
settings.  So I've taken the easy route, and patched ulzma to copy
LzmaDecode to the stack before executing.  This brings running time for
fallback stage uncompress from nearly two minutes to 50ms here.

I'm also seeing weird performance behavior from memset -- this is not
consistent, and just started appearing at some point in my development
here.  I assume this has something to do with alignment, but I was
frankly not in the mood to start debugging this as well.  I've included
a patch that reduces memset to "rep stosb" under x86, which eliminates
the worst-case behavior (in the order of minutes spent in
cbfs_load_stage) I was seeing here.

Signed-off-by: Arne Georg Gleditsch <arne.gleditsch at numascale.com>

-- 
								Arne.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: r5184-ulzma.patch
Type: text/x-patch
Size: 2558 bytes
Desc: not available
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20100305/91aa4c80/attachment.patch>

From arne.gleditsch at numascale.com  Fri Mar  5 15:40:45 2010
From: arne.gleditsch at numascale.com (Arne Georg Gleditsch)
Date: Fri, 05 Mar 2010 15:40:45 +0100
Subject: [coreboot] [PATCH] Istanbul support
Message-ID: <4B9117ED.5020807@numascale.com>

Hi,

The following patch implements Opteron Fam 10 rev D (aka Istanbul)
support for coreboot.  I have not updated MAX_CPUS for all fam10
mainboards, but it might make sense to multiply those by 1.5.

Signed-off-by: Arne Georg Gleditsch <arne.gleditsch at numascale.com>

-- 
								Arne.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: r5184-istanbul.patch
Type: text/x-patch
Size: 8519 bytes
Desc: not available
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20100305/a7246793/attachment.patch>

From andrew.goodbody at tadpole.com  Fri Mar  5 14:33:24 2010
From: andrew.goodbody at tadpole.com (Andrew Goodbody)
Date: Fri, 05 Mar 2010 05:33:24 -0800
Subject: [coreboot] Supermicro H8QME-2+ mct_d fatal exit.
In-Reply-To: <4B90C8EB.6050006@gap.upv.es>
References: <4B87CF9D.9060204@gap.upv.es>	<201002261506.46602.christian.leber@ziti.uni-heidelberg.de>	<4B87DEFE.3010604@gap.upv.es>	<20100226154934.5727.qmail@stuge.se>	<4B8BC18D.1050400@gap.upv.es>
	<4B8FC877.4030209@gap.upv.es> <4B8FE8C2.1090104@tadpole.com>
	<4B90C8EB.6050006@gap.upv.es>
Message-ID: <4B910824.5040901@tadpole.com>

Sorry, neglected to send original reply to list.

Knut Kujat wrote:
> Andrew Goodbody escribi?:
>> Knut Kujat wrote:
>>> Any suggestions ?
>> The vendor BIOS is doing some initialisation that coreboot is not.
>> This init survives a short shutdown but is lost after a longer period
>> without power.
> Yes, vendor BIOS must be doing something different when initializing
> ram. But why is coreboot working just fine up here in the lab even if I
> let it unplugged the whole night next morning I plug it back on and it
> works!

Don't focus on that too much. It's probably to do with the environment, 
or even just coincidence.

>> Is there a multiplexer on the SMBUS?
> I honestly don't know, I have:

A multiplexer on the SMBUS was just something that occurred to me. To 
find it you would need to actually use the SMBUS controller to scan the 
SMBUS for devices. This is not a trivial task but I think there may be 
tools out there to help you.

A better approach would be to start by actually debugging what is going 
wrong in RAM init. That will tell you the area to investigate for 
differences.

Andrew



From andrew.goodbody at tadpole.com  Fri Mar  5 15:29:51 2010
From: andrew.goodbody at tadpole.com (Andrew Goodbody)
Date: Fri, 05 Mar 2010 06:29:51 -0800
Subject: [coreboot] [PATCH] ASUS P2B-LS support, RAM detection for 440BX,
 add Slot 1 CPU, Microcode for Intel Tualatin CPUs
In-Reply-To: <01dad3b81ca0551beea67320b55d248b@imap.1and1.com>
References: <b72cdb061003022019x18ab2b0fo7de47d2d1b0f9609@mail.gmail.com>	<4B8F8605.7010700@ntlworld.com>	<20100304123006.GC13408@greenwood>	<4B8FA9D5.5050901@settoplinux.org>	<4B8FB129.3020102@settoplinux.org>	<4B90BAC9.2090901@ntlworld.com>	<4B90F3A5.2080301@settoplinux.org>
	<4B91015B.7020602@csr.com>
	<01dad3b81ca0551beea67320b55d248b@imap.1and1.com>
Message-ID: <4B91155F.8040208@tadpole.com>

Joseph Smith wrote:
> That's easy... so you do something like this:

As I understand it that only works if there is a DIMM in the 4th slot. 
Otherwise you'll set a four slot system with the 3 slot configuration 
leading to incorrect routing of clocks.

Andrew



From mylesgw at gmail.com  Fri Mar  5 16:13:39 2010
From: mylesgw at gmail.com (Myles Watson)
Date: Fri, 5 Mar 2010 08:13:39 -0700
Subject: [coreboot] [PATCH] YABEL compilation warnings
In-Reply-To: <2831fecf1003050704g39c76edcy32f5efbf5abaee65@mail.gmail.com>
References: <2831fecf1003050704g39c76edcy32f5efbf5abaee65@mail.gmail.com>
Message-ID: <2831fecf1003050713h77bd7abbx245a8bd6fa96a595@mail.gmail.com>

On Fri, Mar 5, 2010 at 8:04 AM, Myles Watson <mylesgw at gmail.com> wrote:

> This patch removes most of the rest of the compilation warnings for me.
>
> 1. Move run_bios prototype to device.h
> 2. Use time.h for get_time()
>
2b. Move tb_freq into functions.c instead of the time.h

> 3. Move read_io and write_io to io.c and make them static
> 4. Make a couple of functions static in interrupt.c
> 5. Refactor a cast from char[] to u64 to get rid of potential alignment
> problems and a warning
>
> The only ones left are "unused function" warnings.
>
> I think we should get rid of that warning, since we conditionally call
> functions based on debugging and various config variables.  Is there a case
> where it helps enough to justify all the warnings?
>
> This next part isn't part of the patch, but applying it makes qemu compile
> with yabel (with and without debugging).
>
> Index: Makefile
> ===================================================================
> --- Makefile    (revision 5186)
> +++ Makefile    (working copy)
> @@ -239,7 +239,7 @@
>  CFLAGS = $(INCLUDES) -Os -nostdinc
>  CFLAGS += -nostdlib -Wall -Wundef -Wstrict-prototypes -Wmissing-prototypes
>  CFLAGS += -Wwrite-strings -Wredundant-decls -Wno-trigraphs
> -CFLAGS += -Wstrict-aliasing -Wshadow
>

I meant no-unused-function:

> +CFLAGS += -Wstrict-aliasing -Wshadow -Wno-unused-function
>


>  ifeq ($(CONFIG_WARNINGS_ARE_ERRORS),y)
>  CFLAGS += -Werror
>  endif
>

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

Thanks,
Myles
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20100305/9e80a2f6/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: warnings.diff
Type: text/x-patch
Size: 7363 bytes
Desc: not available
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20100305/9e80a2f6/attachment.diff>

From mylesgw at gmail.com  Fri Mar  5 16:04:38 2010
From: mylesgw at gmail.com (Myles Watson)
Date: Fri, 5 Mar 2010 08:04:38 -0700
Subject: [coreboot] [PATCH] YABEL compilation warnings
Message-ID: <2831fecf1003050704g39c76edcy32f5efbf5abaee65@mail.gmail.com>

This patch removes most of the rest of the compilation warnings for me.

1. Move run_bios prototype to device.h
2. Use time.h for get_time()
3. Move read_io and write_io to io.c and make them static
4. Make a couple of functions static in interrupt.c
5. Refactor a cast from char[] to u64 to get rid of potential alignment
problems and a warning

The only ones left are "unused" warnings.

I think we should get rid of that warning, since we conditionally call
functions based on debugging and various config variables.  Is there a case
where it helps enough to justify all the warnings?

This next part isn't part of the patch, but applying it makes qemu compile
with yabel (with and without debugging).

Index: Makefile
===================================================================
--- Makefile    (revision 5186)
+++ Makefile    (working copy)
@@ -239,7 +239,7 @@
 CFLAGS = $(INCLUDES) -Os -nostdinc
 CFLAGS += -nostdlib -Wall -Wundef -Wstrict-prototypes -Wmissing-prototypes
 CFLAGS += -Wwrite-strings -Wredundant-decls -Wno-trigraphs
-CFLAGS += -Wstrict-aliasing -Wshadow
+CFLAGS += -Wstrict-aliasing -Wshadow -Wno-unused
 ifeq ($(CONFIG_WARNINGS_ARE_ERRORS),y)
 CFLAGS += -Werror
 endif

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

Thanks,
Myles
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20100305/6c05beaa/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: warnings.diff
Type: text/x-patch
Size: 7165 bytes
Desc: not available
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20100305/6c05beaa/attachment.diff>

From r.marek at assembler.cz  Fri Mar  5 16:55:07 2010
From: r.marek at assembler.cz (Rudolf Marek)
Date: Fri, 05 Mar 2010 16:55:07 +0100
Subject: [coreboot] Supermicro H8QME-2+ mct_d fatal exit.
In-Reply-To: <4B8FC877.4030209@gap.upv.es>
References: <4B87CF9D.9060204@gap.upv.es>	<201002261506.46602.christian.leber@ziti.uni-heidelberg.de>	<4B87DEFE.3010604@gap.upv.es>	<20100226154934.5727.qmail@stuge.se>	<4B8BC18D.1050400@gap.upv.es>
	<4B8FC877.4030209@gap.upv.es>
Message-ID: <4B91295B.9060102@assembler.cz>

Hi,

This is pointing to something which is powered from 5VSB voltage. It could be 
some GPIO settings which sets voltage for ram through some other chip. It could 
be some powersequencing pin connected as GPIO too, it could be a i2c bus 
multiplexer operated by some GPIO pin too ;)

I would suggest to dump the superio chip with "isadump" (all logical devices) 
and all registers powered from the 5VSB well if known. Check for changes on GPIO 
pins or SuperIO global config.

Check if the fail is caused by missing SPD EPROMS (error SMBus reads) or just by 
ram itself.

It could be also something from the SB itself, but try with superio first.

Then compare the dumps with that you obtained from coreboot (you will need to 
program that) You can check from linux with legacy bios, then boot with coreboot 
and then boot with power unplugged.

Good luck,

Rudolf



From svn at coreboot.org  Fri Mar  5 17:18:39 2010
From: svn at coreboot.org (repository service)
Date: Fri, 05 Mar 2010 17:18:39 +0100
Subject: [coreboot] [commit] r5187 - in trunk/src/cpu/intel: . slot_1
Message-ID: <E1NnaEZ-0007B0-0p@ra.coresystems.de>

Author: uwe
Date: Fri Mar  5 17:18:38 2010
New Revision: 5187
URL: http://tracker.coreboot.org/trac/coreboot/changeset/5187

Log:
Add proper Slot 1 CPU support code/infrastructure.

Signed-off-by: Keith Hui <buurin at gmail.com>
Acked-by: Uwe Hermann <uwe at hermann-uwe.de>

Added:
   trunk/src/cpu/intel/slot_1/
   trunk/src/cpu/intel/slot_1/Kconfig
   trunk/src/cpu/intel/slot_1/Makefile.inc
   trunk/src/cpu/intel/slot_1/chip.h
   trunk/src/cpu/intel/slot_1/slot_1.c
Modified:
   trunk/src/cpu/intel/Kconfig
   trunk/src/cpu/intel/Makefile.inc

Modified: trunk/src/cpu/intel/Kconfig
==============================================================================
--- trunk/src/cpu/intel/Kconfig	Fri Mar  5 11:20:28 2010	(r5186)
+++ trunk/src/cpu/intel/Kconfig	Fri Mar  5 17:18:38 2010	(r5187)
@@ -8,6 +8,7 @@
 source src/cpu/intel/bga956/Kconfig
 source src/cpu/intel/ep80579/Kconfig
 source src/cpu/intel/slot_2/Kconfig
+source src/cpu/intel/slot_1/Kconfig
 source src/cpu/intel/socket_mFCPGA478/Kconfig
 source src/cpu/intel/socket_mPGA478/Kconfig
 source src/cpu/intel/socket_mPGA479M/Kconfig

Modified: trunk/src/cpu/intel/Makefile.inc
==============================================================================
--- trunk/src/cpu/intel/Makefile.inc	Fri Mar  5 11:20:28 2010	(r5186)
+++ trunk/src/cpu/intel/Makefile.inc	Fri Mar  5 17:18:38 2010	(r5187)
@@ -13,6 +13,7 @@
 subdirs-$(CONFIG_CPU_INTEL_SOCKET_MPGA604) += socket_mPGA604
 subdirs-$(CONFIG_CPU_INTEL_SOCKET_PGA370) += socket_PGA370
 subdirs-$(CONFIG_CPU_INTEL_SLOT_2) += slot_2
+subdirs-$(CONFIG_CPU_INTEL_SLOT_1) += slot_1
 
 #socket_mPGA604_533Mhz
 #socket_mPGA604_800Mhz

Added: trunk/src/cpu/intel/slot_1/Kconfig
==============================================================================
--- /dev/null	00:00:00 1970	(empty, because file is newly added)
+++ trunk/src/cpu/intel/slot_1/Kconfig	Fri Mar  5 17:18:38 2010	(r5187)
@@ -0,0 +1,33 @@
+##
+## This file is part of the coreboot project.
+##
+## Copyright (C) 2010 Keith Hui <buurin at gmail.com>
+##
+## 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 CPU_INTEL_SLOT_1
+	bool
+
+config DCACHE_RAM_BASE
+	hex
+	default 0xc0000
+	depends on CPU_INTEL_SLOT_1
+
+config DCACHE_RAM_SIZE
+	hex
+	default 0x01000
+	depends on CPU_INTEL_SLOT_1
+

Added: trunk/src/cpu/intel/slot_1/Makefile.inc
==============================================================================
--- /dev/null	00:00:00 1970	(empty, because file is newly added)
+++ trunk/src/cpu/intel/slot_1/Makefile.inc	Fri Mar  5 17:18:38 2010	(r5187)
@@ -0,0 +1,29 @@
+##
+## 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
+##
+
+obj-y += slot_1.o
+subdirs-y += ../model_6xx
+subdirs-y += ../../x86/tsc
+subdirs-y += ../../x86/mtrr
+subdirs-y += ../../x86/lapic
+subdirs-y += ../../x86/cache
+subdirs-y += ../../x86/smm
+subdirs-y += ../microcode
+

Added: trunk/src/cpu/intel/slot_1/chip.h
==============================================================================
--- /dev/null	00:00:00 1970	(empty, because file is newly added)
+++ trunk/src/cpu/intel/slot_1/chip.h	Fri Mar  5 17:18:38 2010	(r5187)
@@ -0,0 +1,24 @@
+/*
+ * This file is part of the coreboot project.
+ *
+ * Copyright (C) 2010 Keith Hui <buurin at gmail.com>
+ *
+ * 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 cpu_intel_slot_1_ops;
+
+struct cpu_intel_slot_1_config {
+};

Added: trunk/src/cpu/intel/slot_1/slot_1.c
==============================================================================
--- /dev/null	00:00:00 1970	(empty, because file is newly added)
+++ trunk/src/cpu/intel/slot_1/slot_1.c	Fri Mar  5 17:18:38 2010	(r5187)
@@ -0,0 +1,26 @@
+/*
+ * This file is part of the coreboot project.
+ *
+ * Copyright (C) 2010 Keith Hui <buurin at gmail.com>
+ *
+ * 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 cpu_intel_slot_1_ops = {
+	CHIP_NAME("Slot 1 CPU")
+};



From knuku at gap.upv.es  Fri Mar  5 17:23:00 2010
From: knuku at gap.upv.es (Knut Kujat)
Date: Fri, 05 Mar 2010 17:23:00 +0100
Subject: [coreboot] Supermicro H8QME-2+ mct_d fatal exit.
In-Reply-To: <4B91295B.9060102@assembler.cz>
References: <4B87CF9D.9060204@gap.upv.es>	<201002261506.46602.christian.leber@ziti.uni-heidelberg.de>	<4B87DEFE.3010604@gap.upv.es>	<20100226154934.5727.qmail@stuge.se>	<4B8BC18D.1050400@gap.upv.es>	<4B8FC877.4030209@gap.upv.es>
	<4B91295B.9060102@assembler.cz>
Message-ID: <4B912FE4.7080204@gap.upv.es>

Rudolf Marek escribi?:
> Hi,
>
> This is pointing to something which is powered from 5VSB voltage. It
> could be some GPIO settings which sets voltage for ram through some
> other chip. It could be some powersequencing pin connected as GPIO
> too, it could be a i2c bus multiplexer operated by some GPIO pin too ;)
>
> I would suggest to dump the superio chip with "isadump" (all logical
> devices) and all registers powered from the 5VSB well if known. Check
> for changes on GPIO pins or SuperIO global config.
>
> Check if the fail is caused by missing SPD EPROMS (error SMBus reads)
> or just by ram itself.
>
> It could be also something from the SB itself, but try with superio
> first.
>
> Then compare the dumps with that you obtained from coreboot (you will
> need to program that) You can check from linux with legacy bios, then
> boot with coreboot and then boot with power unplugged.
>
> Good luck,
>
> Rudolf
>
Hi,

I did a output on status form status = mctRead_SPD(smbaddr, Index); in
mct_d.c and it only spits -1 out while on the working coreboot machine
it gives me several numbers until index = 64 on those dimms where ram is
installed. Is this a possible SPD EPROMS missing error you pointed out?
What would be my next steps if so?

Thanks for your effort,
Knut Kujat.



From svn at coreboot.org  Fri Mar  5 17:31:41 2010
From: svn at coreboot.org (repository service)
Date: Fri, 05 Mar 2010 17:31:41 +0100
Subject: [coreboot] [commit] r5188 - in trunk/src/mainboard/asus: . p2b-ls
Message-ID: <E1NnaRB-0007QO-TB@ra.coresystems.de>

Author: uwe
Date: Fri Mar  5 17:31:41 2010
New Revision: 5188
URL: http://tracker.coreboot.org/trac/coreboot/changeset/5188

Log:
Add support for the ASUS P2B-LS mainboard.

Signed-off-by: Keith Hui <buurin at gmail.com>
Acked-by: Uwe Hermann <uwe at hermann-uwe.de>

Added:
   trunk/src/mainboard/asus/p2b-ls/
   trunk/src/mainboard/asus/p2b-ls/Kconfig
   trunk/src/mainboard/asus/p2b-ls/chip.h
   trunk/src/mainboard/asus/p2b-ls/devicetree.cb
   trunk/src/mainboard/asus/p2b-ls/irq_tables.c
   trunk/src/mainboard/asus/p2b-ls/mainboard.c
   trunk/src/mainboard/asus/p2b-ls/romstage.c
Modified:
   trunk/src/mainboard/asus/Kconfig

Modified: trunk/src/mainboard/asus/Kconfig
==============================================================================
--- trunk/src/mainboard/asus/Kconfig	Fri Mar  5 17:18:38 2010	(r5187)
+++ trunk/src/mainboard/asus/Kconfig	Fri Mar  5 17:31:41 2010	(r5188)
@@ -27,6 +27,7 @@
 source "src/mainboard/asus/p2b/Kconfig"
 source "src/mainboard/asus/p2b-d/Kconfig"
 source "src/mainboard/asus/p2b-ds/Kconfig"
+source "src/mainboard/asus/p2b-ls/Kconfig"
 source "src/mainboard/asus/p2b-f/Kconfig"
 source "src/mainboard/asus/p3b-f/Kconfig"
 source "src/mainboard/asus/m2v-mx_se/Kconfig"

Added: trunk/src/mainboard/asus/p2b-ls/Kconfig
==============================================================================
--- /dev/null	00:00:00 1970	(empty, because file is newly added)
+++ trunk/src/mainboard/asus/p2b-ls/Kconfig	Fri Mar  5 17:31:41 2010	(r5188)
@@ -0,0 +1,52 @@
+##
+## This file is part of the coreboot project.
+##
+## Copyright (C) 2010 Keith Hui <buurin at gmail.com>
+##
+## 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_ASUS_P2B_LS
+	bool "P2B-LS"
+	select ARCH_X86
+	select CPU_INTEL_SLOT_1
+	select NORTHBRIDGE_INTEL_I440BX
+	select SOUTHBRIDGE_INTEL_I82371EB
+	select SUPERIO_WINBOND_W83977TF
+	select ROMCC
+	select HAVE_PIRQ_TABLE
+	select UDELAY_TSC
+	select BOARD_ROMSIZE_KB_256
+
+config MAINBOARD_DIR
+	string
+	default asus/p2b-ls
+	depends on BOARD_ASUS_P2B_LS
+
+config MAINBOARD_PART_NUMBER
+	string
+	default "P2B-LS"
+	depends on BOARD_ASUS_P2B_LS
+
+config HAVE_OPTION_TABLE
+	bool
+	default n
+	depends on BOARD_ASUS_P2B_LS
+
+config IRQ_SLOT_COUNT
+	int
+	default 8
+	depends on BOARD_ASUS_P2B_LS
+

Added: trunk/src/mainboard/asus/p2b-ls/chip.h
==============================================================================
--- /dev/null	00:00:00 1970	(empty, because file is newly added)
+++ trunk/src/mainboard/asus/p2b-ls/chip.h	Fri Mar  5 17:31:41 2010	(r5188)
@@ -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/asus/p2b-ls/devicetree.cb
==============================================================================
--- /dev/null	00:00:00 1970	(empty, because file is newly added)
+++ trunk/src/mainboard/asus/p2b-ls/devicetree.cb	Fri Mar  5 17:31:41 2010	(r5188)
@@ -0,0 +1,59 @@
+chip northbridge/intel/i440bx		# Northbridge
+  device apic_cluster 0 on		# APIC cluster
+    chip cpu/intel/slot_1		# CPU
+      device apic 0 on end		# APIC
+    end
+  end
+  device pci_domain 0 on		# PCI domain
+    device pci 0.0 on end		# Host bridge
+    device pci 1.0 on end		# PCI/AGP bridge
+    chip southbridge/intel/i82371eb	# Southbridge
+      device pci 4.0 on			# ISA bridge
+        chip superio/winbond/w83977tf	# Super I/O (FIXME: It's W83977EF!)
+          device pnp 3f0.0 on		# Floppy
+            io 0x60 = 0x3f0
+            irq 0x70 = 6
+            drq 0x74 = 2
+          end
+          device pnp 3f0.1 on		# Parallel port
+            io 0x60 = 0x378
+            irq 0x70 = 7
+          end
+          device pnp 3f0.2 on		# COM1
+            io 0x60 = 0x3f8
+            irq 0x70 = 4
+          end
+          device pnp 3f0.3 on		# COM2 / IR
+            io 0x60 = 0x2f8
+            irq 0x70 = 3
+          end
+          device pnp 3f0.5 on		# PS/2 keyboard
+            io 0x60 = 0x60
+            io 0x62 = 0x64
+            irq 0x70 = 1		# PS/2 keyboard interrupt
+            irq 0x72 = 12		# PS/2 mouse interrupt
+          end
+          device pnp 3f0.7 on		# GPIO 1
+          end
+          device pnp 3f0.8 on		# GPIO 2
+          end
+          device pnp 3f0.a on		# ACPI
+          end
+        end
+      end
+      device pci 4.1 on	end		# IDE
+      device pci 4.2 on	end		# USB
+      device pci 4.3 on end		# ACPI
+      device pci 6.0 on end             # Onboard SCSI
+      device pci 7.0 on end             # Onboard LAN
+      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"
+    end
+  end
+end

Added: trunk/src/mainboard/asus/p2b-ls/irq_tables.c
==============================================================================
--- /dev/null	00:00:00 1970	(empty, because file is newly added)
+++ trunk/src/mainboard/asus/p2b-ls/irq_tables.c	Fri Mar  5 17:31:41 2010	(r5188)
@@ -0,0 +1,54 @@
+/*
+ * This file is part of the coreboot project.
+ *
+ * Copyright (C) 2010 Keith Hui <buurin at gmail.com>
+ *
+ * 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,
+	PIRQ_VERSION,
+	32 + 16 * CONFIG_IRQ_SLOT_COUNT,/* Max. number of devices on the bus */
+	0x00,			/* Interrupt router bus */
+	(0x04 << 3) | 0x0,	/* Interrupt router device */
+	0,			/* IRQs devoted exclusively to PCI usage */
+	0x8086,			/* Vendor */
+	0x122e,			/* Device */
+	0,			/* Miniport */
+	{ 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0 }, /* u8 rfu[11] */
+	0x10,			/* 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, (0x0c << 3) | 0x0, {{0x60, 0x1eb8}, {0x61, 0x1eb8}, {0x62, 0x1eb8}, {0x63, 0x1eb8}}, 0x1, 0x0},
+		{0x00, (0x0b << 3) | 0x0, {{0x61, 0x1eb8}, {0x62, 0x1eb8}, {0x63, 0x1eb8}, {0x60, 0x1eb8}}, 0x2, 0x0},
+		{0x00, (0x0a << 3) | 0x0, {{0x62, 0x1eb8}, {0x63, 0x1eb8}, {0x60, 0x1eb8}, {0x61, 0x1eb8}}, 0x3, 0x0},
+		{0x00, (0x09 << 3) | 0x0, {{0x63, 0x1eb8}, {0x60, 0x1eb8}, {0x61, 0x1eb8}, {0x62, 0x1eb8}}, 0x4, 0x0},
+		{0x00, (0x04 << 3) | 0x0, {{0x60, 0x1eb8}, {0x61, 0x1eb8}, {0x62, 0x1eb8}, {0x63, 0x1eb8}}, 0x0, 0x0},
+		{0x00, (0x01 << 3) | 0x0, {{0x60, 0x1eb8}, {0x61, 0x1eb8}, {0x62, 0x1eb8}, {0x63, 0x1eb8}}, 0x0, 0x0},
+		{0x00, (0x06 << 3) | 0x0, {{0x63, 0x1eb8}, {0x60, 0x1eb8}, {0x61, 0x1eb8}, {0x62, 0x1eb8}}, 0x0, 0x0},
+		{0x00, (0x07 << 3) | 0x0, {{0x62, 0x1eb8}, {0x63, 0x1eb8}, {0x60, 0x1eb8}, {0x61, 0x1eb8}}, 0x0, 0x0},
+	}
+};
+
+unsigned long write_pirq_routing_table(unsigned long addr)
+{
+	return copy_pirq_routing_table(addr);
+}

Added: trunk/src/mainboard/asus/p2b-ls/mainboard.c
==============================================================================
--- /dev/null	00:00:00 1970	(empty, because file is newly added)
+++ trunk/src/mainboard/asus/p2b-ls/mainboard.c	Fri Mar  5 17:31:41 2010	(r5188)
@@ -0,0 +1,26 @@
+/*
+ * 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
+ */
+
+#include <device/device.h>
+#include "chip.h"
+
+struct chip_operations mainboard_ops = {
+	CHIP_NAME("ASUS P2B-LS Mainboard")
+};

Added: trunk/src/mainboard/asus/p2b-ls/romstage.c
==============================================================================
--- /dev/null	00:00:00 1970	(empty, because file is newly added)
+++ trunk/src/mainboard/asus/p2b-ls/romstage.c	Fri Mar  5 17:31:41 2010	(r5188)
@@ -0,0 +1,75 @@
+/*
+ * 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
+ */
+
+#define ASSEMBLY 1
+#define __PRE_RAM__
+
+#include <stdint.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 <stdlib.h>
+#include "pc80/serial.c"
+#include "arch/i386/lib/console.c"
+#include "lib/ramtest.c"
+#include "southbridge/intel/i82371eb/i82371eb_enable_rom.c"
+#include "southbridge/intel/i82371eb/i82371eb_early_smbus.c"
+#include "northbridge/intel/i440bx/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"
+/* FIXME: The ASUS P2B-LS has a Winbond W83977EF, actually. */
+#include "superio/winbond/w83977tf/w83977tf_early_serial.c"
+
+#define SERIAL_DEV PNP_DEV(0x3f0, W83977TF_SP1)
+
+static inline int spd_read_byte(unsigned int device, unsigned int address)
+{
+	return smbus_read_byte(device, address);
+}
+
+#include "northbridge/intel/i440bx/raminit.c"
+#include "northbridge/intel/i440bx/debug.c"
+
+static void main(unsigned long bist)
+{
+	if (bist == 0)
+		early_mtrr_init();
+
+	/* FIXME: The ASUS P2B-LS has a Winbond W83977EF, actually. */
+	w83977tf_enable_serial(SERIAL_DEV, CONFIG_TTYS0_BASE);
+	uart_init();
+	console_init();
+	report_bist_failure(bist);
+
+	/* Enable access to the full ROM chip, needed very early by CBFS. */
+	i82371eb_enable_rom(PCI_DEV(0, 4, 0)); /* ISA bridge at 00:04.0. */
+
+	enable_smbus();
+	/* dump_spd_registers(); */
+	sdram_set_registers();
+	sdram_set_spd_registers();
+	sdram_enable();
+	/* ram_check(0, 640 * 1024); */
+}



From arne.gleditsch at numascale.com  Fri Mar  5 17:53:07 2010
From: arne.gleditsch at numascale.com (Arne Georg Gleditsch)
Date: Fri, 05 Mar 2010 17:53:07 +0100
Subject: [coreboot] [PATCH] Tyan S2912 Fam10
Message-ID: <4B9136F3.6090003@numascale.com>

(Hm, this message seems to not have made it through.  Resending...)

Hi all,

I've just recently brought my development environment up to speed with
the latest coreboot version -- which is very nice! -- and caught a
couple of minor issues.  I'm not sure I fully understand the underlying
logic behind the different CAR setup routines in
src/cpu/amd/car/cache_as_ram.inc, but the attached patch is required to
make the S2912 board choose the correct code path.  I've also upped the
MAX_CPUS setting to 12 to accommodate 6-core Istanbul CPUs.  This might
make sense for other fam10 boards as well.

Signed-off-by: Arne Georg Gleditsch <arne.gleditsch at numascale.com>

-- 
								Arne.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: r5184-tyan-s2912-fam10.patch
Type: text/x-patch
Size: 872 bytes
Desc: not available
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20100305/872c8c09/attachment.patch>

From arne.gleditsch at numascale.com  Fri Mar  5 15:22:23 2010
From: arne.gleditsch at numascale.com (Arne Georg Gleditsch)
Date: Fri, 05 Mar 2010 15:22:23 +0100
Subject: [coreboot] [PATCH] Tyan S2912 Fam10
Message-ID: <4B91139F.4040509@numascale.com>

Hi all,

I've just recently brought my development environment up to speed with
the latest coreboot version -- which is very nice! -- and caught a
couple of minor issues.  I'm not sure I fully understand the underlying
logic behind the different CAR setup routines in
src/cpu/amd/car/cache_as_ram.inc, but the attached patch is required to
make the S2912 board choose the correct code path.  I've also upped the
MAX_CPUS setting to 12 to accommodate 6-core Istanbul CPUs.  This might
make sense for other fam10 boards as well.

Signed-off-by: Arne Georg Gleditsch <arne.gleditsch at numascale.com>

-- 
								Arne.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: r5184-tyan-s2912-fam10.patch
Type: text/x-patch
Size: 871 bytes
Desc: not available
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20100305/1aefdc6d/attachment.patch>

From stepan at coresystems.de  Fri Mar  5 18:05:20 2010
From: stepan at coresystems.de (Stefan Reinauer)
Date: Fri, 05 Mar 2010 18:05:20 +0100
Subject: [coreboot] Supermicro H8QME-2+ mct_d fatal exit.
In-Reply-To: <4B910824.5040901@tadpole.com>
References: <4B87CF9D.9060204@gap.upv.es>	<201002261506.46602.christian.leber@ziti.uni-heidelberg.de>	<4B87DEFE.3010604@gap.upv.es>	<20100226154934.5727.qmail@stuge.se>	<4B8BC18D.1050400@gap.upv.es>	<4B8FC877.4030209@gap.upv.es>
	<4B8FE8C2.1090104@tadpole.com>	<4B90C8EB.6050006@gap.upv.es>
	<4B910824.5040901@tadpole.com>
Message-ID: <4B9139D0.6000305@coresystems.de>

On 3/5/10 2:33 PM, Andrew Goodbody wrote:
> Sorry, neglected to send original reply to list.
>
> Knut Kujat wrote:
>> Andrew Goodbody escribi?:
>>> Knut Kujat wrote:
>>>> Any suggestions ?
>>> The vendor BIOS is doing some initialisation that coreboot is not.
>>> This init survives a short shutdown but is lost after a longer period
>>> without power.
>> Yes, vendor BIOS must be doing something different when initializing
>> ram. But why is coreboot working just fine up here in the lab even if I
>> let it unplugged the whole night next morning I plug it back on and it
>> works!
>
> Don't focus on that too much. It's probably to do with the
> environment, or even just coincidence.
I think so too.

Two more suggestions:
- compare coreboot and vendor bios with SerialICE
- try disabling all cores / cpus except the BSP to make sure the problem
is not caused by the PCI access race conditions in the Fam8 and K10 ports...

Stefan



From r.marek at assembler.cz  Fri Mar  5 18:06:09 2010
From: r.marek at assembler.cz (Rudolf Marek)
Date: Fri, 05 Mar 2010 18:06:09 +0100
Subject: [coreboot] Supermicro H8QME-2+ mct_d fatal exit.
In-Reply-To: <4B912FE4.7080204@gap.upv.es>
References: <4B87CF9D.9060204@gap.upv.es>	<201002261506.46602.christian.leber@ziti.uni-heidelberg.de>	<4B87DEFE.3010604@gap.upv.es>	<20100226154934.5727.qmail@stuge.se>	<4B8BC18D.1050400@gap.upv.es>	<4B8FC877.4030209@gap.upv.es>	<4B91295B.9060102@assembler.cz>
	<4B912FE4.7080204@gap.upv.es>
Message-ID: <4B913A01.4090103@assembler.cz>

> Hi,
> 
> I did a output on status form status = mctRead_SPD(smbaddr, Index); in
> mct_d.c and it only spits -1 out while on the working coreboot machine
> it gives me several numbers until index = 64 on those dimms where ram is
> installed. Is this a possible SPD EPROMS missing error you pointed out?


Yes this points to some I2C multiplexer device. You need to find out how to 
control the multiplexer. It might be some GPIO setup or even some i2c device. 
Try to superiotool in verbose mode to see how the GPIO is setup. You will need 
either to load the GPIO settings (of superio tool) in coreboot before ram init 
or just dump it and check for the differences in first place.

in linux, i2cdetect 0
output would also help maybe...

try running sensors-detect it might detect the bus multiplexers.

Rudolf


> What would be my next steps if so?
> 
> Thanks for your effort,
> Knut Kujat.
> 



From r.marek at assembler.cz  Fri Mar  5 18:07:49 2010
From: r.marek at assembler.cz (Rudolf Marek)
Date: Fri, 05 Mar 2010 18:07:49 +0100
Subject: [coreboot] Supermicro H8QME-2+ mct_d fatal exit.
In-Reply-To: <4B9139D0.6000305@coresystems.de>
References: <4B87CF9D.9060204@gap.upv.es>	<201002261506.46602.christian.leber@ziti.uni-heidelberg.de>	<4B87DEFE.3010604@gap.upv.es>	<20100226154934.5727.qmail@stuge.se>	<4B8BC18D.1050400@gap.upv.es>	<4B8FC877.4030209@gap.upv.es>	<4B8FE8C2.1090104@tadpole.com>	<4B90C8EB.6050006@gap.upv.es>	<4B910824.5040901@tadpole.com>
	<4B9139D0.6000305@coresystems.de>
Message-ID: <4B913A65.1030601@assembler.cz>

> Two more suggestions:
> - compare coreboot and vendor bios with SerialICE
> - try disabling all cores / cpus except the BSP to make sure the problem
> is not caused by the PCI access race conditions in the Fam8 and K10 ports...

Yes good one also.

Rudolf

> 
> Stefan
> 



From rminnich at gmail.com  Fri Mar  5 17:58:20 2010
From: rminnich at gmail.com (ron minnich)
Date: Fri, 5 Mar 2010 08:58:20 -0800
Subject: [coreboot] "How come it's so slow?"
Message-ID: <13426df11003050858r1c4bbe5m34514694d6e7c561@mail.gmail.com>

Just got a new nehalem box in for test yesterday. Experiences so far:

1. POST from power-on takes 45 seconds. *45 SECONDS*. Now, I had it
said to me at SCALE7x last year from someone from Intel that all new
BIOSes on Intel chips are really EFI underneath -- is this indicative
of what we are to expect? If so, it's awful. It's 15 times slower than
what we had ten years ago, and 50 times slower than what we can do
today on coreboot.
2. POST from reset took infinity, sometimes, and 60 seconds others.
3. With no keyboard attached, we got the 'Hit any key to continue'
message. I can't this problem still occurs.
4. No PS/2 connectors, which might be ok, except:
5. USB keyboard doesn't work well enough to get to the config screen.
Oh, it works, just not right away. We can't get to the BIOS setup.
6. It's too dumb to realize that if there really are no storage
devices attached, it really ought to try the network. And we can't
force the 'boot from net' setting yet. See (5).

Experiences on a MAC with EFI
1. "How come it's so long to be responsive?"
2. The only way to make it bearable is to load REFIt.
3. there's a file on the "EFI FLASH partition". It defines the
partition tables. Yep, you might think that it could just read the
drive, and no, that's not good enough: it can't boot an installed
linux unless you rebuild this file too.

So, the score so far: we've had a superior open source solution for 10
years, and there are lots of sectors starting to listen (I hear from
more each week), but we're still stuck with Old Fashioned BIOS on our
desktops and servers. :-)

I expect this problem to change this decade, just not sure when :-)

ron



From stepan at coresystems.de  Fri Mar  5 18:28:15 2010
From: stepan at coresystems.de (Stefan Reinauer)
Date: Fri, 05 Mar 2010 18:28:15 +0100
Subject: [coreboot] [PATCH] YABEL compilation warnings
In-Reply-To: <2831fecf1003050713h77bd7abbx245a8bd6fa96a595@mail.gmail.com>
References: <2831fecf1003050704g39c76edcy32f5efbf5abaee65@mail.gmail.com>
	<2831fecf1003050713h77bd7abbx245a8bd6fa96a595@mail.gmail.com>
Message-ID: <4B913F2F.3070006@coresystems.de>

On 3/5/10 4:13 PM, Myles Watson wrote:
>
>     I think we should get rid of that warning, since we conditionally
>     call functions based on debugging and various config variables.  
>
I think we should instead just drop CONFIG_WARNINGS_ARE_ERRORS for Qemu
rather than dropping warnings. Or maybe only add -Wno-unused-function if
CONFIG_WARNINGS_ARE_ERRORS is active, at least.  Or maybe add an Option
"Warnings good for Developers"?

>     Is there a case where it helps enough to justify all the warnings?
>

Yes, they indicate that there is dead code. This is, not only but
especially useful to recognize if / how code should / could be restructured.

>  Signed-off-by: Myles Watson <mylesgw at gmail.com
> <mailto:mylesgw at gmail.com>>
With the -Wno-unused-functions taken care of:

Acked-by: Stefan Reinauer <stepan at coresystems.de>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20100305/75059db8/attachment.html>

From joe at settoplinux.org  Fri Mar  5 18:50:02 2010
From: joe at settoplinux.org (Joseph Smith)
Date: Fri, 05 Mar 2010 12:50:02 -0500
Subject: [coreboot] [PATCH] ASUS P2B-LS support, RAM detection for 440BX,
 add Slot 1 CPU, Microcode for Intel Tualatin CPUs
In-Reply-To: <4B911419.1020808@coresystems.de>
References: <b72cdb061003022019x18ab2b0fo7de47d2d1b0f9609@mail.gmail.com>	<4B8F8605.7010700@ntlworld.com>	<20100304123006.GC13408@greenwood>	<4B8FA9D5.5050901@settoplinux.org>	<4B8FB129.3020102@settoplinux.org>	<4B90BAC9.2090901@ntlworld.com>	<4B90F3A5.2080301@settoplinux.org>
	<4B91015B.7020602@csr.com>
	<01dad3b81ca0551beea67320b55d248b@imap.1and1.com>
	<4B911419.1020808@coresystems.de>
Message-ID: <ac2bf110e56426cd24b2b39199b64fe0@imap.1and1.com>




On Fri, 05 Mar 2010 15:24:25 +0100, Stefan Reinauer <stepan at coresystems.de>
wrote:
> On 3/5/10 3:15 PM, Joseph Smith wrote:
>>
>>
>> On Fri, 05 Mar 2010 13:04:27 +0000, Mark Marshall
<mark.marshall at csr.com>
>> wrote:
>>
>>> Joseph Smith wrote:
>>>
>>>> On 03/05/2010 03:03 AM, Mark Marshall wrote:
>>>>
>>>>> On 04/03/10 13:10, Joseph Smith wrote:
>>>>>
>>>>>> On 03/04/2010 07:38 AM, Joseph Smith wrote:
>>>>>>
>>>>>>> On 03/04/2010 07:30 AM, Uwe Hermann wrote:
>>>>>>>
>>>>>>>> On Thu, Mar 04, 2010 at 10:05:57AM +0000, Mark Marshall wrote:
>>>>>>>>
>>>>>>>>> On 03/03/10 04:19, Keith Hui wrote:
>>>>>>>>> The first problem is that this motherboard only has three DIMM
>>>>>>>>> slots. This means you have to set SDRAMC to something different;
>>>>>>>>> 0x0103 works for me.
>>>>>>>>>
>>>>>>>>>
>>>>>>>> Hm, seems to be determined by SDRAMPWR + MMCONFIG, and MMCONFIG
>>>>>>>> seems to
>>>>>>>> be a hardware-strap (so we can check it), but not sure about
>>>>>>>>
>>> SDRAMPWR.
>>>
>>>>>>>>
>>>>>>>>>
>>>>>> I think a simple SPD probe would work, if the correct value is
>>>>>>
>> returned
>>
>>>>>> you know you have memory in that slot, otherwise if 0xff is returned
>>>>>> then no memory is present. Do this probe for as many slots as the
440
>>>>>> supports. Then set your registers based on that.
>>>>>>
>>>>> The issue here is the number of DIMM slots on the motherboard, not
the
>>>>> number of sticks in the slots. Some 440BX boards have four slots,
> while
>>>>> others only have three.
>>>>>
>>>>> MM
>>>>>
>>>>>
>>>> That is fine. Then if 440bx datasheet says it supports 4 slots, then
>>>> that should be the standard.
>>>>
>>>>
>>> Please check this section of the 440BX data sheet.
>>>
>>>    3.3.24 SDRAMC?SDRAM Control Register (Device 0)
>>>
>>> We are interested in bit 4.
>>>
>>>   SDRAMPWR. The SDRAMPWR bit controls how the CKE signals are driven
>>>   for different DRAM configurations. For a 3 DIMM configuration,
>>>   SDRAMPWR should be set to ?0?. For a 4 DIMM configuration,
>>>   SDRAMPWR should be set to ?1?. In this case the 82443BX drives a
>>>   single CKE signal (GCKE). The combination of SDRAMPWR and MMCONFIG
>>>   (DRAMC register) determine the functioning of the CKE signals.
>>>   Refer to the DRAMC register (Section 3.3.15, ?DRAMC?DRAM
>>>   Control Register (Device 0)? on page 3-19) for more details.
>>>
>>>   Note: When PCIRST# assertion occurs during POS/STR, these bits
>>>   are not reset to 0.
>>>
>>> As far as I can tell we cannot auto-detect this.  Some (many)
>>> 440BX boards only have three DIMM slots, and in these cases the
>>> clocks are routed differently to the boards with four DIMM slots.
>>>
>>>
>> That's easy... so you do something like this:
>>
>> slot4_detect = (spd_read_byte((DIMM_SPD_BASE + 3), SPD_MEMORY_TYPE);
>>
>> if (slot4_detect != 0xff) {
>>
>>      /* We have 4 slots */
>>      ----Set bit 4 in SDRAMPWR----
>>      #define DIMM_SOCKETS 4
>> } else {
>>
>>      /* We have 3 slots */
>>      ----Set bit 4 in SDRAMPWR----
>>      #define DIMM_SOCKETS 3
>> }
>>
>> Hope that helps.
>>
> 
> Will a mainboard with three modules but 4 slots work like this? Can
> someone try? If we can autodetect it, we should. If we can't I think
> encoding the number of slots in Kconfig is fine.
> 
I think so, from what I understand the clocks are routed in a daisy chain
so to speak. So if there is 4 physical slots and the system is only
configured for three it should work ok. Also this routine will be
determined at every start up so if you put a sdram module in the fourth
slot it will be re-configured for 4 slots.

Anyways the only way to know if this will work is to test it so can someone
please test?

Also, one could always use serialice on a 4 slot system with factory bios
to see how they deterime it....

One could try a dump with three DIMMS and then a dump with four DIMMS and
compare the results.


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




From svn at coreboot.org  Fri Mar  5 19:03:49 2010
From: svn at coreboot.org (repository service)
Date: Fri, 05 Mar 2010 19:03:49 +0100
Subject: [coreboot] [commit] r5189 - trunk/src/arch/i386/init
Message-ID: <E1NnbsL-0003Bh-Hz@ra.coresystems.de>

Author: stepan
Date: Fri Mar  5 19:03:49 2010
New Revision: 5189
URL: http://tracker.coreboot.org/trac/coreboot/changeset/5189

Log:
Fix creation of coreboot.bootblock when -O2 is specified instead of -Os (4GB image issue).

According to some GCC folks -Os should be considered a buggy and unreliable
code path, so at least keep -O2 working. coreboot_ram is only 4KB bigger.

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

Modified:
   trunk/src/arch/i386/init/ldscript_fallback_cbfs.lb

Modified: trunk/src/arch/i386/init/ldscript_fallback_cbfs.lb
==============================================================================
--- trunk/src/arch/i386/init/ldscript_fallback_cbfs.lb	Fri Mar  5 17:31:41 2010	(r5188)
+++ trunk/src/arch/i386/init/ldscript_fallback_cbfs.lb	Fri Mar  5 19:03:49 2010	(r5189)
@@ -47,6 +47,7 @@
 		*(.rom.data);
 		*(.init.rodata.*);
 		*(.init.text);
+		*(.rodata);
 		*(.rodata.*);
 		*(.rom.data.*);
 		. = ALIGN(16);



From rminnich at gmail.com  Fri Mar  5 19:07:49 2010
From: rminnich at gmail.com (ron minnich)
Date: Fri, 5 Mar 2010 10:07:49 -0800
Subject: [coreboot] Supermicro H8QME-2+ mct_d fatal exit.
In-Reply-To: <4B913A01.4090103@assembler.cz>
References: <4B87CF9D.9060204@gap.upv.es>
	<201002261506.46602.christian.leber@ziti.uni-heidelberg.de>
	<4B87DEFE.3010604@gap.upv.es> <20100226154934.5727.qmail@stuge.se>
	<4B8BC18D.1050400@gap.upv.es> <4B8FC877.4030209@gap.upv.es>
	<4B91295B.9060102@assembler.cz> <4B912FE4.7080204@gap.upv.es>
	<4B913A01.4090103@assembler.cz>
Message-ID: <13426df11003051007r29fee819p2fdea852891a4b58@mail.gmail.com>

Just FYI:

on our first system with Arima boards in 2002, everything worked well
until we started booting 64-bit kernels. I'm not kidding. We did not
find the SMBUS MUX on the boards until we had unreliable coreboot
boots of 64-bit kernels. For quite some time the boards worked fine.
Ollie found the SMBUS MUX by examining schematics.

So the SMBUS mux can appear in strange ways, at strange times. This
sounds like one of those times. SMBUS muxes are more common than you
might think and the default power-on state is not always very well
determined.

ron



From thomas at gstaedtner.net  Fri Mar  5 18:58:23 2010
From: thomas at gstaedtner.net (=?UTF-8?Q?Thomas_Gst=C3=A4dtner?=)
Date: Fri, 5 Mar 2010 18:58:23 +0100
Subject: [coreboot] "How come it's so slow?"
In-Reply-To: <13426df11003050858r1c4bbe5m34514694d6e7c561@mail.gmail.com>
References: <13426df11003050858r1c4bbe5m34514694d6e7c561@mail.gmail.com>
Message-ID: <c16a574a1003050958r672fe76bx6d6421c672440332@mail.gmail.com>

Imho it's just a sad sign for our industry.
There is a great, fast, cheap and very easy to implement solution for
x86 bootfirmwares. coreboot, but somehow the industry doesn't seem
interested.
Instead every company invents the wheel over and over again and they
never do it good or even right.
One would think that coreboot could give a company a real advantage in
the market, but still - nobody even tries (some exceptions in special
market segments excluded).

I hope that changes soon, not only "this decade", and I hope that AMD
stays on course and tries harder.

Anyway, you're doing a great job, keep up the good work!

On 2010-03-05, ron minnich <rminnich at gmail.com> wrote:
> Just got a new nehalem box in for test yesterday. Experiences so far:
>
> 1. POST from power-on takes 45 seconds. *45 SECONDS*. Now, I had it
> said to me at SCALE7x last year from someone from Intel that all new
> BIOSes on Intel chips are really EFI underneath -- is this indicative
> of what we are to expect? If so, it's awful. It's 15 times slower than
> what we had ten years ago, and 50 times slower than what we can do
> today on coreboot.
> 2. POST from reset took infinity, sometimes, and 60 seconds others.
> 3. With no keyboard attached, we got the 'Hit any key to continue'
> message. I can't this problem still occurs.
> 4. No PS/2 connectors, which might be ok, except:
> 5. USB keyboard doesn't work well enough to get to the config screen.
> Oh, it works, just not right away. We can't get to the BIOS setup.
> 6. It's too dumb to realize that if there really are no storage
> devices attached, it really ought to try the network. And we can't
> force the 'boot from net' setting yet. See (5).
>
> Experiences on a MAC with EFI
> 1. "How come it's so long to be responsive?"
> 2. The only way to make it bearable is to load REFIt.
> 3. there's a file on the "EFI FLASH partition". It defines the
> partition tables. Yep, you might think that it could just read the
> drive, and no, that's not good enough: it can't boot an installed
> linux unless you rebuild this file too.
>
> So, the score so far: we've had a superior open source solution for 10
> years, and there are lots of sectors starting to listen (I hear from
> more each week), but we're still stuck with Old Fashioned BIOS on our
> desktops and servers. :-)
>
> I expect this problem to change this decade, just not sure when :-)
>
> ron
>
> --
> coreboot mailing list: coreboot at coreboot.org
> http://www.coreboot.org/mailman/listinfo/coreboot
>



From svn at coreboot.org  Fri Mar  5 19:25:20 2010
From: svn at coreboot.org (repository service)
Date: Fri, 05 Mar 2010 19:25:20 +0100
Subject: [coreboot] [commit] r5190 - trunk/src/northbridge/intel/i945
Message-ID: <E1NncDA-0007Fb-9E@ra.coresystems.de>

Author: stepan
Date: Fri Mar  5 19:25:19 2010
New Revision: 5190
URL: http://tracker.coreboot.org/trac/coreboot/changeset/5190

Log:
i945 mini patch:
- don't skip the reset on S4 violations. Specs ask us to do this so we do it
- hlt on waiting for reset instead of hot looping.

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

Modified:
   trunk/src/northbridge/intel/i945/raminit.c

Modified: trunk/src/northbridge/intel/i945/raminit.c
==============================================================================
--- trunk/src/northbridge/intel/i945/raminit.c	Fri Mar  5 19:03:49 2010	(r5189)
+++ trunk/src/northbridge/intel/i945/raminit.c	Fri Mar  5 19:25:19 2010	(r5190)
@@ -236,8 +236,9 @@
 	if (reg8 & ((1<<7)|(1<<2))) {
 		if (reg8 & (1<<2)) {
 			printk_debug("SLP S4# Assertion Width Violation.\n");
-
+			/* Write back clears bit 2 */
 			pci_write_config8(PCI_DEV(0, 0x1f, 0), 0xa2, reg8);
+			do_reset = 1;
 
 		}
 
@@ -257,7 +258,7 @@
 			printk_debug("Reset required.\n");
 			outb(0x00, 0xcf9);
 			outb(0x0e, 0xcf9);
-			for (;;) ; /* Wait for reset! */
+			for (;;) asm("hlt"); /* Wait for reset! */
 		}
 	}
 



From rminnich at gmail.com  Fri Mar  5 19:26:58 2010
From: rminnich at gmail.com (ron minnich)
Date: Fri, 5 Mar 2010 10:26:58 -0800
Subject: [coreboot] Hi...all
In-Reply-To: <afd6944b1003042253q139e636bm2809fced98f4eda8@mail.gmail.com>
References: <afd6944b1003042253q139e636bm2809fced98f4eda8@mail.gmail.com>
Message-ID: <13426df11003051026y16c5053q3d3f77144308548f@mail.gmail.com>

What would coreboot need to do to "support" IPMI BMC?

ron



From svn at coreboot.org  Fri Mar  5 19:27:20 2010
From: svn at coreboot.org (repository service)
Date: Fri, 05 Mar 2010 19:27:20 +0100
Subject: [coreboot] [commit] r5191 - in trunk: src/devices
	src/include/device util/x86emu/yabel util/x86emu/yabel/compat
Message-ID: <E1NncF6-0002fO-7p@ra.coresystems.de>

Author: myles
Date: Fri Mar  5 19:27:19 2010
New Revision: 5191
URL: http://tracker.coreboot.org/trac/coreboot/changeset/5191

Log:
1. Move run_bios prototype to device.h
2. Use time.h for get_time() and move tb_freq into functions.c
3. Move read_io and write_io to io.c and make them static
4. Make a couple of functions static in interrupt.c
5. Refactor a cast from char[] to u64 to get rid of potential alignment problems and a warning

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

Modified:
   trunk/src/devices/pci_device.c
   trunk/src/include/device/device.h
   trunk/util/x86emu/yabel/compat/functions.c
   trunk/util/x86emu/yabel/compat/time.h
   trunk/util/x86emu/yabel/interrupt.c
   trunk/util/x86emu/yabel/io.c
   trunk/util/x86emu/yabel/mem.c
   trunk/util/x86emu/yabel/vbe.c

Modified: trunk/src/devices/pci_device.c
==============================================================================
--- trunk/src/devices/pci_device.c	Fri Mar  5 19:25:19 2010	(r5190)
+++ trunk/src/devices/pci_device.c	Fri Mar  5 19:27:19 2010	(r5191)
@@ -652,7 +652,6 @@
 void pci_dev_init(struct device *dev)
 {
 #if CONFIG_PCI_ROM_RUN == 1 || CONFIG_VGA_ROM_RUN == 1
-	void run_bios(struct device *dev, unsigned long addr);
 	struct rom_header *rom, *ram;
 
 	if (CONFIG_PCI_ROM_RUN != 1 && /* Only execute VGA ROMs. */

Modified: trunk/src/include/device/device.h
==============================================================================
--- trunk/src/include/device/device.h	Fri Mar  5 19:25:19 2010	(r5190)
+++ trunk/src/include/device/device.h	Fri Mar  5 19:27:19 2010	(r5191)
@@ -117,6 +117,9 @@
 void dev_set_enabled(device_t dev, int enable);
 void disable_children(struct bus *bus);
 
+/* Option ROM helper functions */
+void run_bios(struct device *dev, unsigned long addr);
+
 /* Helper functions */
 device_t find_dev_path(struct bus *parent, struct device_path *path);
 device_t alloc_find_dev(struct bus *parent, struct device_path *path);

Modified: trunk/util/x86emu/yabel/compat/functions.c
==============================================================================
--- trunk/util/x86emu/yabel/compat/functions.c	Fri Mar  5 19:25:19 2010	(r5190)
+++ trunk/util/x86emu/yabel/compat/functions.c	Fri Mar  5 19:27:19 2010	(r5191)
@@ -18,6 +18,7 @@
 #include <device/device.h>
 #include "../debug.h"
 #include "../biosemu.h"
+#include "../compat/time.h"
 
 #define VMEM_SIZE (1024 * 1024) /* 1 MB */
 
@@ -52,6 +53,8 @@
 	}
 }
 
+unsigned long tb_freq = 0;
+
 u64 get_time(void)
 {
     u64 act;
@@ -64,50 +67,3 @@
     act = ((u64) edx << 32) | eax; 
     return act;
 }
-
-unsigned int
-read_io(void *addr, size_t sz)
-{
-        unsigned int ret;
-	/* since we are using inb instructions, we need the port number as 16bit value */
-	u16 port = (u16)(u32) addr;
-
-        switch (sz) {
-        case 1:
-		asm volatile ("inb %1, %b0" : "=a"(ret) : "d" (port));
-                break;
-        case 2:
-		asm volatile ("inw %1, %w0" : "=a"(ret) : "d" (port));
-                break;
-        case 4:
-		asm volatile ("inl %1, %0" : "=a"(ret) : "d" (port));
-                break;
-        default:
-                ret = 0;
-        }
-
-        return ret;
-}
-
-int
-write_io(void *addr, unsigned int value, size_t sz)
-{
-	u16 port = (u16)(u32) addr;
-        switch (sz) {
-	/* since we are using inb instructions, we need the port number as 16bit value */
-        case 1:
-		asm volatile ("outb %b0, %1" : : "a"(value), "d" (port));
-                break;
-        case 2:
-		asm volatile ("outw %w0, %1" : : "a"(value), "d" (port));
-                break;
-        case 4:
-		asm volatile ("outl %0, %1" : : "a"(value), "d" (port));
-                break;
-        default:
-                return -1;
-        }
-
-        return 0;
-}
-

Modified: trunk/util/x86emu/yabel/compat/time.h
==============================================================================
--- trunk/util/x86emu/yabel/compat/time.h	Fri Mar  5 19:25:19 2010	(r5190)
+++ trunk/util/x86emu/yabel/compat/time.h	Fri Mar  5 19:27:19 2010	(r5191)
@@ -13,5 +13,6 @@
 #define _BIOSEMU_COMPAT_TIME_H
 
 /* TODO: check how this works in x86 */
-static unsigned long tb_freq = 0;
+extern unsigned long tb_freq;
+u64 get_time(void);
 #endif 

Modified: trunk/util/x86emu/yabel/interrupt.c
==============================================================================
--- trunk/util/x86emu/yabel/interrupt.c	Fri Mar  5 19:25:19 2010	(r5190)
+++ trunk/util/x86emu/yabel/interrupt.c	Fri Mar  5 19:27:19 2010	(r5191)
@@ -31,7 +31,7 @@
 
 
 //setup to run the code at the address, that the Interrupt Vector points to...
-void
+static void
 setupInt(int intNum)
 {
 	DEBUG_PRINTF_INTR("%s(%x): executing interrupt handler @%08x\n",
@@ -50,7 +50,7 @@
 }
 
 // handle int10 (VGA BIOS Interrupt)
-void
+static void
 handleInt10(void)
 {
 	// the data for INT10 is stored in BDA (0000:0400h) offset 49h-66h
@@ -207,7 +207,7 @@
 
 ;
 
-void
+static void
 translate_keycode(u64 * keycode)
 {
 	u8 scan_code = 0;
@@ -233,7 +233,7 @@
 }
 
 // handle int16 (Keyboard BIOS Interrupt)
-void
+static void
 handleInt16(void)
 {
 	// keyboard buffer is in BIOS Memory Area:
@@ -319,7 +319,7 @@
 }
 
 // handle int1a (PCI BIOS Interrupt)
-void
+static void
 handleInt1a(void)
 {
 	// function number in AX

Modified: trunk/util/x86emu/yabel/io.c
==============================================================================
--- trunk/util/x86emu/yabel/io.c	Fri Mar  5 19:25:19 2010	(r5190)
+++ trunk/util/x86emu/yabel/io.c	Fri Mar  5 19:27:19 2010	(r5191)
@@ -24,12 +24,51 @@
 #include <device/pci_ops.h>
 #endif
 
-// those are defined in net-snk/oflib/pci.c
-extern unsigned int read_io(void *, size_t);
-extern int write_io(void *, unsigned int, size_t);
+static unsigned int
+read_io(void *addr, size_t sz)
+{
+        unsigned int ret;
+	/* since we are using inb instructions, we need the port number as 16bit value */
+	u16 port = (u16)(u32) addr;
 
-//defined in net-snk/kernel/timer.c
-extern u64 get_time(void);
+        switch (sz) {
+        case 1:
+		asm volatile ("inb %1, %b0" : "=a"(ret) : "d" (port));
+                break;
+        case 2:
+		asm volatile ("inw %1, %w0" : "=a"(ret) : "d" (port));
+                break;
+        case 4:
+		asm volatile ("inl %1, %0" : "=a"(ret) : "d" (port));
+                break;
+        default:
+                ret = 0;
+        }
+
+        return ret;
+}
+
+static int
+write_io(void *addr, unsigned int value, size_t sz)
+{
+	u16 port = (u16)(u32) addr;
+        switch (sz) {
+	/* since we are using inb instructions, we need the port number as 16bit value */
+        case 1:
+		asm volatile ("outb %b0, %1" : : "a"(value), "d" (port));
+                break;
+        case 2:
+		asm volatile ("outw %w0, %1" : : "a"(value), "d" (port));
+                break;
+        case 4:
+		asm volatile ("outl %0, %1" : : "a"(value), "d" (port));
+                break;
+        default:
+                return -1;
+        }
+
+        return 0;
+}
 
 #ifdef CONFIG_ARCH_X86
 #include <arch/io.h>

Modified: trunk/util/x86emu/yabel/mem.c
==============================================================================
--- trunk/util/x86emu/yabel/mem.c	Fri Mar  5 19:25:19 2010	(r5190)
+++ trunk/util/x86emu/yabel/mem.c	Fri Mar  5 19:27:19 2010	(r5191)
@@ -159,9 +159,6 @@
 #define DEBUG_CHECK_VMEM_WRITE(_addr, _val)
 #endif
 
-//defined in net-snk/kernel/timer.c
-extern u64 get_time(void);
-
 void update_time(u32);
 
 #if !defined(CONFIG_YABEL_DIRECTHW) || (!CONFIG_YABEL_DIRECTHW)

Modified: trunk/util/x86emu/yabel/vbe.c
==============================================================================
--- trunk/util/x86emu/yabel/vbe.c	Fri Mar  5 19:25:19 2010	(r5190)
+++ trunk/util/x86emu/yabel/vbe.c	Fri Mar  5 19:27:19 2010	(r5191)
@@ -570,8 +570,17 @@
 		     sizeof(ddc_info.edid_block_zero));
 	}
 #endif
-	if (*((u64 *) ddc_info.edid_block_zero) !=
-	    (u64) 0x00FFFFFFFFFFFF00ULL) {
+/* This could fail because of alignment issues, so use a longer form.
+	*((u64 *) ddc_info.edid_block_zero) != (u64) 0x00FFFFFFFFFFFF00ULL
+*/
+	if (ddc_info.edid_block_zero[0] != 0x00 ||
+	    ddc_info.edid_block_zero[1] != 0xFF ||
+	    ddc_info.edid_block_zero[2] != 0xFF ||
+	    ddc_info.edid_block_zero[3] != 0xFF ||
+	    ddc_info.edid_block_zero[4] != 0xFF ||
+	    ddc_info.edid_block_zero[5] != 0xFF ||
+	    ddc_info.edid_block_zero[6] != 0xFF ||
+	    ddc_info.edid_block_zero[7] != 0x00 ) {
 		// invalid EDID signature... probably no monitor
 
 		output->display_type = 0x0;



From mylesgw at gmail.com  Fri Mar  5 19:28:15 2010
From: mylesgw at gmail.com (Myles Watson)
Date: Fri, 5 Mar 2010 11:28:15 -0700
Subject: [coreboot] [PATCH] YABEL compilation warnings
In-Reply-To: <4B913F2F.3070006@coresystems.de>
References: <2831fecf1003050704g39c76edcy32f5efbf5abaee65@mail.gmail.com>
	<2831fecf1003050713h77bd7abbx245a8bd6fa96a595@mail.gmail.com>
	<4B913F2F.3070006@coresystems.de>
Message-ID: <2831fecf1003051028v7876df89r9aca8ab3e9e7df11@mail.gmail.com>

On Fri, Mar 5, 2010 at 10:28 AM, Stefan Reinauer <stepan at coresystems.de>wrote:

>  On 3/5/10 4:13 PM, Myles Watson wrote:
>
>  I think we should get rid of that warning, since we conditionally call
>> functions based on debugging and various config variables.
>
>  I think we should instead just drop CONFIG_WARNINGS_ARE_ERRORS for Qemu
> rather than dropping warnings.
>
I think that setting for Qemu has reduced the number of warnings in our code
by a lot.  It's easier for the original developer to deal with warnings when
the code is written.


> Or maybe only add -Wno-unused-function if
>
CONFIG_WARNINGS_ARE_ERRORS is active, at least.  Or maybe add an Option
> "Warnings good for Developers"?
>
I can see your point.  I'd rather not have to special case warnings either.
What would you suggest for the two emulator functions in yabel that are
unused right now?  Should we comment them out until they are used?


>  Is there a case where it helps enough to justify all the warnings?
>>
>   Yes, they indicate that there is dead code. This is, not only but
> especially useful to recognize if / how code should / could be restructured.
>
>
I worry that having too many warnings makes it so that "important" ones
(ones that cause bugs) get missed.

>   Signed-off-by: Myles Watson <mylesgw at gmail.com>
>
> With the -Wno-unused-functions taken care of:
>

I wasn't sure how you wanted it taken care of.  I left it for another patch.


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

Rev 5191.

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

From info at coresystems.de  Fri Mar  5 20:03:33 2010
From: info at coresystems.de (coreboot information)
Date: Fri, 05 Mar 2010 20:03:33 +0100
Subject: [coreboot] build service results for r5191
Message-ID: <E1Nnco9-0006jb-4D@ra.coresystems.de>

Dear coreboot readers!

This is the automatic build system of coreboot.

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

Change Log:
1. Move run_bios prototype to device.h
2. Use time.h for get_time() and move tb_freq into functions.c
3. Move read_io and write_io to io.c and make them static
4. Make a couple of functions static in interrupt.c
5. Refactor a cast from char[] to u64 to get rid of potential alignment problems and a warning

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


Build Log:
Compilation of emulation:qemu-x86 has been broken
See the error log at http://qa.coreboot.org/log_buildbrd.php?revision=5191&device=qemu-x86&vendor=emulation&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 andrew.goodbody at tadpole.com  Fri Mar  5 18:55:34 2010
From: andrew.goodbody at tadpole.com (Andrew Goodbody)
Date: Fri, 05 Mar 2010 09:55:34 -0800
Subject: [coreboot] [PATCH] ASUS P2B-LS support, RAM detection for 440BX,
 add Slot 1 CPU, Microcode for Intel Tualatin CPUs
In-Reply-To: <ac2bf110e56426cd24b2b39199b64fe0@imap.1and1.com>
References: <b72cdb061003022019x18ab2b0fo7de47d2d1b0f9609@mail.gmail.com>	<4B8F8605.7010700@ntlworld.com>	<20100304123006.GC13408@greenwood>	<4B8FA9D5.5050901@settoplinux.org>	<4B8FB129.3020102@settoplinux.org>	<4B90BAC9.2090901@ntlworld.com>	<4B90F3A5.2080301@settoplinux.org>	<4B91015B.7020602@csr.com>	<01dad3b81ca0551beea67320b55d248b@imap.1and1.com>	<4B911419.1020808@coresystems.de>
	<ac2bf110e56426cd24b2b39199b64fe0@imap.1and1.com>
Message-ID: <4B914596.9000505@tadpole.com>

Joseph Smith wrote:
> Also, one could always use serialice on a 4 slot system with factory bios
> to see how they deterime it....

The factory BIOS does not have to determine it. It knows the 
configuration of the board it is running on. It can use a build time 
setting.

Andrew



From svn at coreboot.org  Fri Mar  5 20:12:34 2010
From: svn at coreboot.org (repository service)
Date: Fri, 05 Mar 2010 20:12:34 +0100
Subject: [coreboot] [commit] r5192 - trunk/util/x86emu
Message-ID: <E1Nncws-00085U-Sv@ra.coresystems.de>

Author: myles
Date: Fri Mar  5 20:12:34 2010
New Revision: 5192
URL: http://tracker.coreboot.org/trac/coreboot/changeset/5192

Log:
Remove redundant run_bios prototype.  Trivial.

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

Modified:
   trunk/util/x86emu/x86.c

Modified: trunk/util/x86emu/x86.c
==============================================================================
--- trunk/util/x86emu/x86.c	Fri Mar  5 19:27:19 2010	(r5191)
+++ trunk/util/x86emu/x86.c	Fri Mar  5 20:12:34 2010	(r5192)
@@ -32,7 +32,6 @@
 };
 
 void x86_exception(struct eregs *info);
-void run_bios(struct device *dev, unsigned long addr);
 
 extern unsigned char __idt_handler, __idt_handler_size;
 extern unsigned char __realmode_code, __realmode_code_size;



From peter at stuge.se  Fri Mar  5 20:16:51 2010
From: peter at stuge.se (Peter Stuge)
Date: Fri, 5 Mar 2010 20:16:51 +0100
Subject: [coreboot] [commit] r5185 - in trunk: src
	src/console	src/cpu/x86/smm src/devices
	src/mainboard/amd/dbm690t	src/mainboard/amd/pistachio	src/mainboard/amd/serengeti_cheetah_fam10
	src/mainboard/asus/a8n_e	src/m...
In-Reply-To: <E1NnUNr-0000kG-Dr@ra.coresystems.de>
References: <E1NnUNr-0000kG-Dr@ra.coresystems.de>
Message-ID: <20100305191651.28252.qmail@stuge.se>

repository service wrote:
> +config X86EMU_DEBUG
> +	bool "Output verbose x86emu debug messages"
> +	default n
> +	depends on PCI_OPTION_ROM_RUN_YABEL
> +	help
> +	  This option enables additional x86emu related debug messages.

So is it x86emu or YABEL? It would be great to have just one name.


//Peter



From stepan at coresystems.de  Fri Mar  5 20:23:26 2010
From: stepan at coresystems.de (Stefan Reinauer)
Date: Fri, 05 Mar 2010 20:23:26 +0100
Subject: [coreboot] [commit] r5185 - in trunk:
 src	src/console	src/cpu/x86/smm
 src/devices	src/mainboard/amd/dbm690t	src/mainboard/amd/pistachio	src/mainboard/amd/serengeti_cheetah_fam10
 src/mainboard/asus/a8n_e	src/m...
In-Reply-To: <20100305191651.28252.qmail@stuge.se>
References: <E1NnUNr-0000kG-Dr@ra.coresystems.de>
	<20100305191651.28252.qmail@stuge.se>
Message-ID: <4B915A2E.9010204@coresystems.de>

On 3/5/10 8:16 PM, Peter Stuge wrote:
> repository service wrote:
>   
>> +config X86EMU_DEBUG
>> +	bool "Output verbose x86emu debug messages"
>> +	default n
>> +	depends on PCI_OPTION_ROM_RUN_YABEL
>> +	help
>> +	  This option enables additional x86emu related debug messages.
>>     
> So is it x86emu or YABEL? It would be great to have just one name.
>   
It's both. YABEL is the BIOS emulation, x86emu is the CPU emulation.

Stefan




From info at coresystems.de  Fri Mar  5 20:28:40 2010
From: info at coresystems.de (coreboot information)
Date: Fri, 05 Mar 2010 20:28:40 +0100
Subject: [coreboot] build service results for r5192
Message-ID: <E1NndCS-00036L-EZ@ra.coresystems.de>

Dear coreboot readers!

This is the automatic build system of coreboot.

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

Change Log:
Remove redundant run_bios prototype.  Trivial.

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


Build Log:
Compilation of emulation:qemu-x86 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 marcj303 at gmail.com  Fri Mar  5 23:02:18 2010
From: marcj303 at gmail.com (Marc Jones)
Date: Fri, 5 Mar 2010 15:02:18 -0700
Subject: [coreboot] [PATCH]: Disable ExtINT in ioapic.c
In-Reply-To: <4B68D414.9030500@coresystems.de>
References: <DD1CC71B621B004FA76856E5129D6B17036DA956@sbjgexmb1.amd.com>
	<4B68D414.9030500@coresystems.de>
Message-ID: <534e5dc21003051402h7aec7dbdl80bd7d5a5ede4966@mail.gmail.com>

On Tue, Feb 2, 2010 at 6:40 PM, Stefan Reinauer <stepan at coresystems.de> wrote:
> On 2/2/10 4:25 AM, Bao, Zheng wrote:
>> Index: src/arch/i386/smp/ioapic.c
>> ===================================================================
>> --- src/arch/i386/smp/ioapic.c ? ? ? ?(revision 5073)
>> +++ src/arch/i386/smp/ioapic.c ? ? ? ?(working copy)
>> @@ -110,7 +110,7 @@
>> ?#endif
>>
>> ? ? ? /* Enable Virtual Wire Mode */
>> - ? ? low = ENABLED | TRIGGER_EDGE | POLARITY_HIGH | PHYSICAL_DEST |
>> ExtINT;
>> + ? ? low = DISABLED;
>> ? ? ? high = bsp_lapicid << (56 - 32);
>>
>> ? ? ? io_apic_write(ioapic_base, 0x10, low);
>>
>
> Hm.. This will break quite some other boards...
>
> Is there any particular reason why the dbm690t will not work in virtual
> wire mode?
>
> I think either the sb600 code should call clear_ioapic() instead of
> setup_ioapic() or (maybe better) the setup_ioapic() function should get
> an additional parameter virtual_wire
>
> Anyways, maybe we should try to unify clear_ioapic and setup_ioapic
>
> (also, the function should create a device node and append it to the
> bridge it is called from)

Sefan,

You are right. The sb600 was really doing a clear_ioapic() previously.
I don't yet understand why the virtual wire mode causes problems. It
is either an additional sb600 setup issue or a mainboard problem with
how EXTINT is connected. The setup_ioapic() should probably have more
options as EXTINT doesn't have to be connected to the APIC.

Signed-off-by: Marc Jones <marcj303 at gmail.com>

Marc


-- 
http://se-eng.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: sb600_apic.patch
Type: application/octet-stream
Size: 834 bytes
Desc: not available
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20100305/e50118b8/attachment.obj>

From c-d.hailfinger.devel.2006 at gmx.net  Sat Mar  6 01:12:51 2010
From: c-d.hailfinger.devel.2006 at gmx.net (Carl-Daniel Hailfinger)
Date: Sat, 06 Mar 2010 01:12:51 +0100
Subject: [coreboot] Hi...all
In-Reply-To: <13426df11003051026y16c5053q3d3f77144308548f@mail.gmail.com>
References: <afd6944b1003042253q139e636bm2809fced98f4eda8@mail.gmail.com>
	<13426df11003051026y16c5053q3d3f77144308548f@mail.gmail.com>
Message-ID: <4B919E03.9090907@gmx.net>

On 05.03.2010 19:26, ron minnich wrote:
> What would coreboot need to do to "support" IPMI BMC?
>   

Depends on the IPMI BMC. If you're lucky, it works out of the box, and
if you're unlucky, you have to implement undocumented BIOS interfaces.
The easiest solution is to buy a card and try it, and if it doesn't
work, reverse engineer it or try another card.

Besides that, IPMI is a security nightmare (see the discussions on the
linux-kernel mailing list about IPMI bypassing host network security).

Regards,
Carl-Daniel

-- 
"I do consider assignment statements and pointer variables to be among
computer science's most valuable treasures."
-- Donald E. Knuth




From stawel at gmail.com  Sat Mar  6 01:14:40 2010
From: stawel at gmail.com (=?ISO-8859-2?Q?Pawe=B3_Stawicki?=)
Date: Sat, 6 Mar 2010 01:14:40 +0100
Subject: [coreboot] coreboot on "acer aspire 1520"
Message-ID: <12ac91af1003051614s2a040e9mb4bafbdf51de229a@mail.gmail.com>

Hi,
I want to try run coreboot on my "acer aspire 1520" laptop.
It has:
Northbridge: via k8n800
southbrige: vt8235
super i/o:   pc87392

Can I get some advise, where to start ?
which northbridge and super i/o are the nearest ?


Best Regards,
Pawe? Stawicki
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20100306/79f15769/attachment.html>

From rminnich at gmail.com  Sat Mar  6 01:54:25 2010
From: rminnich at gmail.com (ron minnich)
Date: Fri, 5 Mar 2010 16:54:25 -0800
Subject: [coreboot] "How come it's so slow?"
In-Reply-To: <13426df11003050858r1c4bbe5m34514694d6e7c561@mail.gmail.com>
References: <13426df11003050858r1c4bbe5m34514694d6e7c561@mail.gmail.com>
Message-ID: <13426df11003051654x142baa51wc1b365c0a0d77756@mail.gmail.com>

OK, we found a keyboard that works. The BIOS is convinced there are
two keyboards and two mice attached. There is one keyboard and no mice
Just great.

ron



From patrick at georgi-clan.de  Sat Mar  6 09:08:16 2010
From: patrick at georgi-clan.de (Patrick Georgi)
Date: Sat, 06 Mar 2010 09:08:16 +0100
Subject: [coreboot] [PATCH]Make macros in Makefile more readable
Message-ID: <4B920D70.5030503@georgi-clan.de>

Hi,

attached patch should help devs to more easily understand the "main
loop" that includes Makefile.incs.

Signed-off-by: Patrick Georgi <patrick.georgi at coresystems.de>
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: 20100306-1-readable-macro
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20100306/44f548f0/attachment.ksh>

From darmawan.salihun at gmail.com  Sat Mar  6 09:29:19 2010
From: darmawan.salihun at gmail.com (Darmawan Salihun)
Date: Sat, 6 Mar 2010 15:29:19 +0700
Subject: [coreboot] GSoC 2010
In-Reply-To: <534e5dc21003040917u37e5ea7ek5d29f4b73b8dc445@mail.gmail.com>
References: <4B8FD7F7.7090307@gmx.net>
	<534e5dc21003040917u37e5ea7ek5d29f4b73b8dc445@mail.gmail.com>
Message-ID: <46893e741003060029v13d8af42xde7da120e0ebee1@mail.gmail.com>

Flashrom used to have Windows port that I worked on back in 2007
(Winflashrom). I'm willing to help if any student want to port to
Windows 7. I'm not a student anymore ;-)

Regards,

Darmawan

On 3/5/10, Marc Jones <marcj303 at gmail.com> wrote:
> On Thu, Mar 4, 2010 at 8:55 AM, Carl-Daniel Hailfinger
> <c-d.hailfinger.devel.2006 at gmx.net> wrote:
>> Hi,
>>
>> Google Summer of Code 2010 is approaching quickly. I hope
>> coreboot/flashrom are going to participate again, and to do that, we
>> have to apply between 2010-03-08 and 2010-03-12 (March 8 - March 12).
>>
>> Do we want to participate?
>> Who is willing to mentor?
>> Any developers who want to apply as students?
>> Who will serve as organization administrator?
>> Are there any good ideas for GSoC (coreboot or flashrom)?
>
> I would like for coreboot to do GSoC again. I think it is great
> exposure for the project and I would be happy to be a mentor again.
> I'll put some thought into what prospective students might work  on.
>
> Marc
>
>
>
> --
> http://se-eng.com
>
> --
> coreboot mailing list: coreboot at coreboot.org
> http://www.coreboot.org/mailman/listinfo/coreboot
>


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



From stepan at coresystems.de  Sat Mar  6 10:35:30 2010
From: stepan at coresystems.de (Stefan Reinauer)
Date: Sat, 06 Mar 2010 10:35:30 +0100
Subject: [coreboot] [PATCH]: Disable ExtINT in ioapic.c
In-Reply-To: <534e5dc21003051402h7aec7dbdl80bd7d5a5ede4966@mail.gmail.com>
References: <DD1CC71B621B004FA76856E5129D6B17036DA956@sbjgexmb1.amd.com>	
	<4B68D414.9030500@coresystems.de>
	<534e5dc21003051402h7aec7dbdl80bd7d5a5ede4966@mail.gmail.com>
Message-ID: <4B9221E2.1070708@coresystems.de>

On 3/5/10 11:02 PM, Marc Jones wrote:
> You are right. The sb600 was really doing a clear_ioapic() previously.
> I don't yet understand why the virtual wire mode causes problems. It
> is either an additional sb600 setup issue or a mainboard problem with
> how EXTINT is connected. The setup_ioapic() should probably have more
> options as EXTINT doesn't have to be connected to the APIC.
>
> Signed-off-by: Marc Jones <marcj303 at gmail.com>
>
> Marc
>   
Acked-by: Stefan Reinauer <stepan at coresystems.de>



From stepan at coresystems.de  Sat Mar  6 11:02:00 2010
From: stepan at coresystems.de (Stefan Reinauer)
Date: Sat, 06 Mar 2010 11:02:00 +0100
Subject: [coreboot] [PATCH]Make macros in Makefile more readable
In-Reply-To: <4B920D70.5030503@georgi-clan.de>
References: <4B920D70.5030503@georgi-clan.de>
Message-ID: <4B922818.8070100@coresystems.de>

On 3/6/10 9:08 AM, Patrick Georgi wrote:
> Hi,
>
> attached patch should help devs to more easily understand the "main
> loop" that includes Makefile.incs.
>
> Signed-off-by: Patrick Georgi <patrick.georgi at coresystems.de>
>   
Acked-by: Stefan Reinauer <stepan at coresystems.de>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20100306/e9d2ed66/attachment.html>

From wangqingpei at gmail.com  Sat Mar  6 10:03:24 2010
From: wangqingpei at gmail.com (Jason Wang)
Date: Sat, 6 Mar 2010 17:03:24 +0800
Subject: [coreboot] GSoC 2010
In-Reply-To: <46893e741003060029v13d8af42xde7da120e0ebee1@mail.gmail.com>
References: <4B8FD7F7.7090307@gmx.net>
	<534e5dc21003040917u37e5ea7ek5d29f4b73b8dc445@mail.gmail.com>
	<46893e741003060029v13d8af42xde7da120e0ebee1@mail.gmail.com>
Message-ID: <df1430311003060103w22137aa9w7e43e1dd64977654@mail.gmail.com>

does coreboot and flashrom will join gsoc 2010 as an union or else?
i am thinking who about making flashrom can be used under windows?

On Sat, Mar 6, 2010 at 4:29 PM, Darmawan Salihun <darmawan.salihun at gmail.com
> wrote:

> Flashrom used to have Windows port that I worked on back in 2007
> (Winflashrom). I'm willing to help if any student want to port to
> Windows 7. I'm not a student anymore ;-)
>
> Regards,
>
> Darmawan
>
> On 3/5/10, Marc Jones <marcj303 at gmail.com> wrote:
> > On Thu, Mar 4, 2010 at 8:55 AM, Carl-Daniel Hailfinger
> > <c-d.hailfinger.devel.2006 at gmx.net> wrote:
> >> Hi,
> >>
> >> Google Summer of Code 2010 is approaching quickly. I hope
> >> coreboot/flashrom are going to participate again, and to do that, we
> >> have to apply between 2010-03-08 and 2010-03-12 (March 8 - March 12).
> >>
> >> Do we want to participate?
> >> Who is willing to mentor?
> >> Any developers who want to apply as students?
> >> Who will serve as organization administrator?
> >> Are there any good ideas for GSoC (coreboot or flashrom)?
> >
> > I would like for coreboot to do GSoC again. I think it is great
> > exposure for the project and I would be happy to be a mentor again.
> > I'll put some thought into what prospective students might work  on.
> >
> > Marc
> >
> >
> >
> > --
> > http://se-eng.com
> >
> > --
> > coreboot mailing list: coreboot at coreboot.org
> > http://www.coreboot.org/mailman/listinfo/coreboot
> >
>
>
> --
> --------------------------------------------------------------------
> -= Human knowledge belongs to the world =-
>
> --
> 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/20100306/2b647377/attachment.html>

From c-d.hailfinger.devel.2006 at gmx.net  Sat Mar  6 14:45:01 2010
From: c-d.hailfinger.devel.2006 at gmx.net (Carl-Daniel Hailfinger)
Date: Sat, 06 Mar 2010 14:45:01 +0100
Subject: [coreboot] GSoC 2010
In-Reply-To: <df1430311003060103w22137aa9w7e43e1dd64977654@mail.gmail.com>
References: <4B8FD7F7.7090307@gmx.net>	<534e5dc21003040917u37e5ea7ek5d29f4b73b8dc445@mail.gmail.com>	<46893e741003060029v13d8af42xde7da120e0ebee1@mail.gmail.com>
	<df1430311003060103w22137aa9w7e43e1dd64977654@mail.gmail.com>
Message-ID: <4B925C5D.1040609@gmx.net>

On 06.03.2010 10:03, Jason Wang wrote:
> On Sat, Mar 6, 2010 at 4:29 PM, Darmawan Salihun wrote:  
>> Flashrom used to have Windows port that I worked on back in 2007
>> (Winflashrom). I'm willing to help if any student want to port to
>> Windows 7. I'm not a student anymore ;-)
>>     
> i am thinking who about making flashrom can be used under windows?
>   

I think Stefan Reinauer already ported flashrom to Windows 7, AFAIK
somewhat based on the original Windows port. Look here:
http://www.coreboot.org/pipermail/flashrom/2009-August/000239.html .
Darmawan, it would be cool if you could look at this as well. flashrom
now has a lot better abstraction than back when you did the original
Windows port, and merging Stefan's patch should be possible. It's been a
while, but I think DirectIO for Windows hasn't been released yet.


> does coreboot and flashrom will join gsoc 2010 as an union or else?
>   

Yes, coreboot and flashrom will have one joint project for GSoC 2010.

Regards,
Carl-Daniel

-- 
"I do consider assignment statements and pointer variables to be among
computer science's most valuable treasures."
-- Donald E. Knuth




From r.marek at assembler.cz  Sat Mar  6 14:42:15 2010
From: r.marek at assembler.cz (Rudolf Marek)
Date: Sat, 06 Mar 2010 14:42:15 +0100
Subject: [coreboot] [PATCH] consolidate K8M890 VGA code - take2
Message-ID: <4B925BB7.2090301@assembler.cz>

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

Hi,

Following patch changes the K8M890 VGA handling. It reverts the framebuffer size
to option based (similar what Uwe did) and also it uses GFXUMA to handle the
high_tables_start offset from memory top.

To satisfy the CMOS option users (Hi, libv! ;) I added also a possibility to do
that through CMOS.

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

Works here, maybe delete that old version from patchwork (from 28.10.2009 22:53)?

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

iEYEARECAAYFAkuSW7cACgkQ3J9wPJqZRNWa3wCgj5Fv/0CkqJXdtSWlvK9X2DW+
i7wAniOA+1D8GBoNjv3VYrbh2xyn+THB
=bTQ6
-----END PGP SIGNATURE-----
-------------- next part --------------
A non-text attachment was scrubbed...
Name: consolidate_vga2.patch
Type: text/x-diff
Size: 6185 bytes
Desc: not available
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20100306/c2987abd/attachment.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: consolidate_vga2.patch.sig
Type: application/octet-stream
Size: 72 bytes
Desc: not available
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20100306/c2987abd/attachment.obj>

From ward at gnu.org  Sat Mar  6 15:32:41 2010
From: ward at gnu.org (Ward Vandewege)
Date: Sat, 6 Mar 2010 09:32:41 -0500
Subject: [coreboot] Hi...all
In-Reply-To: <4B919E03.9090907@gmx.net>
References: <afd6944b1003042253q139e636bm2809fced98f4eda8@mail.gmail.com>
	<13426df11003051026y16c5053q3d3f77144308548f@mail.gmail.com>
	<4B919E03.9090907@gmx.net>
Message-ID: <20100306143241.GA12021@countzero.vandewege.net>

On Sat, Mar 06, 2010 at 01:12:51AM +0100, Carl-Daniel Hailfinger wrote:
> On 05.03.2010 19:26, ron minnich wrote:
> > What would coreboot need to do to "support" IPMI BMC?
> >   
> 
> Depends on the IPMI BMC. If you're lucky, it works out of the box, and
> if you're unlucky, you have to implement undocumented BIOS interfaces.
> The easiest solution is to buy a card and try it, and if it doesn't
> work, reverse engineer it or try another card.
> 
> Besides that, IPMI is a security nightmare (see the discussions on the
> linux-kernel mailing list about IPMI bypassing host network security).

Even worse - I have yet to encounter a reliable IPMI card. The sorts of
problems I've encountered are: 

* specific packets can 'kill' the IPMI controller. Once the thing is hung,
  the only fix is a *cold* boot of the entire machine. 
* I've seen machines crash, taking the IPMI controller with them. Makes
  the whole thing kind of pointless...
* general reliability issues. IPMI controllers also seem to like to hang
  themselves occasionally

I really tried to make IPMI work reliably; I have an 80 machine cluster full
of these things. I wasted a ton of time on them (3 different generations from
2 vendors - Tyan and Supermicro).

I think that those issues were largely caused by extremely crappy proprietary
firmware. But there is a more fundamental issue; the IPMI BMC is pretty
tightly connected into the mainboard, by design. That's bad - how can you
guarantee that IPMI BMC will always be available, fully out of band, when it
is not 100% independent of the mainboard?

In the end I gave up; I now use serial console servers (opengear is highly
recommended) and switched PDUs (I've tried various brands, so far I like
Raritan's Dominion series the best). That works, 100% of the time.

Thanks,
Ward.
 
-- 
Ward Vandewege <ward at gnu.org>



From c-d.hailfinger.devel.2006 at gmx.net  Sat Mar  6 15:50:25 2010
From: c-d.hailfinger.devel.2006 at gmx.net (Carl-Daniel Hailfinger)
Date: Sat, 06 Mar 2010 15:50:25 +0100
Subject: [coreboot] GSoC 2010
In-Reply-To: <4B925C5D.1040609@gmx.net>
References: <4B8FD7F7.7090307@gmx.net>	<534e5dc21003040917u37e5ea7ek5d29f4b73b8dc445@mail.gmail.com>	<46893e741003060029v13d8af42xde7da120e0ebee1@mail.gmail.com>	<df1430311003060103w22137aa9w7e43e1dd64977654@mail.gmail.com>
	<4B925C5D.1040609@gmx.net>
Message-ID: <4B926BB1.4080601@gmx.net>

On 06.03.2010 14:45, Carl-Daniel Hailfinger wrote:
> On 06.03.2010 10:03, Jason Wang wrote:
>   
>> On Sat, Mar 6, 2010 at 4:29 PM, Darmawan Salihun wrote:  
>>     
>>> Flashrom used to have Windows port that I worked on back in 2007
>>> (Winflashrom). I'm willing to help if any student want to port to
>>> Windows 7. I'm not a student anymore ;-)
>>>     
>>>       
>> i am thinking who about making flashrom can be used under windows?
>>   
>>     
>
> I think Stefan Reinauer already ported flashrom to Windows 7, AFAIK
> somewhat based on the original Windows port. Look here:
> http://www.coreboot.org/pipermail/flashrom/2009-August/000239.html .
> Darmawan, it would be cool if you could look at this as well. flashrom
> now has a lot better abstraction than back when you did the original
> Windows port, and merging Stefan's patch should be possible. It's been a
> while, but I think DirectIO for Windows hasn't been released yet.
>   

To summarize:
I don't think porting flashrom to Windows would be a good GSoC task.

Porting flashrom to DOS would be interesting, but I have no idea if our
coding style allows usage of old compilers for DOS.


Regards,
Carl-Daniel

-- 
"I do consider assignment statements and pointer variables to be among
computer science's most valuable treasures."
-- Donald E. Knuth




From peter at stuge.se  Sat Mar  6 16:05:09 2010
From: peter at stuge.se (Peter Stuge)
Date: Sat, 6 Mar 2010 16:05:09 +0100
Subject: [coreboot] GSoC 2010
In-Reply-To: <4B926BB1.4080601@gmx.net>
References: <4B8FD7F7.7090307@gmx.net>
	<534e5dc21003040917u37e5ea7ek5d29f4b73b8dc445@mail.gmail.com>
	<46893e741003060029v13d8af42xde7da120e0ebee1@mail.gmail.com>
	<df1430311003060103w22137aa9w7e43e1dd64977654@mail.gmail.com>
	<4B925C5D.1040609@gmx.net> <4B926BB1.4080601@gmx.net>
Message-ID: <20100306150509.2476.qmail@stuge.se>

Carl-Daniel Hailfinger wrote:
> I have no idea if our coding style allows usage of old compilers
> for DOS.

Use a DOS extender and it should be fine.


//Peter



From stefan.reinauer at coresystems.de  Sat Mar  6 16:06:50 2010
From: stefan.reinauer at coresystems.de (Stefan Reinauer)
Date: Sat, 6 Mar 2010 16:06:50 +0100
Subject: [coreboot] GSoC 2010
In-Reply-To: <4B926BB1.4080601@gmx.net>
References: <4B8FD7F7.7090307@gmx.net>	<534e5dc21003040917u37e5ea7ek5d29f4b73b8dc445@mail.gmail.com>	<46893e741003060029v13d8af42xde7da120e0ebee1@mail.gmail.com>	<df1430311003060103w22137aa9w7e43e1dd64977654@mail.gmail.com>
	<4B925C5D.1040609@gmx.net> <4B926BB1.4080601@gmx.net>
Message-ID: <D2B8891A-FEBE-4A46-80BD-A292E109662D@coresystems.de>

On 06.03.2010, at 15:50, Carl-Daniel Hailfinger <c-d.hailfinger.devel.2006 at gmx.net 
 > wrote:
> To summarize:
> I don't think porting flashrom to Windows would be a good GSoC task.
>
> Porting flashrom to DOS would be interesting, but I have no idea if  
> our
> coding style allows usage of old compilers for DOS.

Porting it to FILO/libpayload would be a nice project, too!
With that feature and an easy way to do partly coreboot flashing, we'd  
have an incredible fallback payload that can even work as a restore  
point if it's not even possible to boot an OS.




>
>
>



From joe at settoplinux.org  Sat Mar  6 16:19:08 2010
From: joe at settoplinux.org (Joseph Smith)
Date: Sat, 06 Mar 2010 10:19:08 -0500
Subject: [coreboot] GSoC 2010
In-Reply-To: <D2B8891A-FEBE-4A46-80BD-A292E109662D@coresystems.de>
References: <4B8FD7F7.7090307@gmx.net>	<534e5dc21003040917u37e5ea7ek5d29f4b73b8dc445@mail.gmail.com>	<46893e741003060029v13d8af42xde7da120e0ebee1@mail.gmail.com>	<df1430311003060103w22137aa9w7e43e1dd64977654@mail.gmail.com>
	<4B925C5D.1040609@gmx.net> <4B926BB1.4080601@gmx.net>
	<D2B8891A-FEBE-4A46-80BD-A292E109662D@coresystems.de>
Message-ID: <49f8af42eac1e221bca5af3b9e97b052@imap.1and1.com>




On Sat, 6 Mar 2010 16:06:50 +0100, Stefan Reinauer
<stefan.reinauer at coresystems.de> wrote:
> On 06.03.2010, at 15:50, Carl-Daniel Hailfinger
> <c-d.hailfinger.devel.2006 at gmx.net
>  > wrote:
>> To summarize:
>> I don't think porting flashrom to Windows would be a good GSoC task.
>>
>> Porting flashrom to DOS would be interesting, but I have no idea if
>> our
>> coding style allows usage of old compilers for DOS.
> 
> Porting it to FILO/libpayload would be a nice project, too!
> With that feature and an easy way to do partly coreboot flashing, we'd
> have an incredible fallback payload that can even work as a restore
> point if it's not even possible to boot an OS.

YES! Flashrom as a coreboot payload would be truly awesome!

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




From rminnich at gmail.com  Sat Mar  6 17:03:40 2010
From: rminnich at gmail.com (ron minnich)
Date: Sat, 6 Mar 2010 08:03:40 -0800
Subject: [coreboot] Hi...all
In-Reply-To: <20100306143241.GA12021@countzero.vandewege.net>
References: <afd6944b1003042253q139e636bm2809fced98f4eda8@mail.gmail.com>
	<13426df11003051026y16c5053q3d3f77144308548f@mail.gmail.com>
	<4B919E03.9090907@gmx.net>
	<20100306143241.GA12021@countzero.vandewege.net>
Message-ID: <13426df11003060803g7d8c4623i4ad4b36a06aee570@mail.gmail.com>

So, if you're looking to buy 150 or so nodes, what's a reasonable
coreboot-capable node *without* any sort of BMC/IPMI? I really need
these IPMI-free boards and the vendors keep trying to shove this IPMI
nonsense down our throats -- in spite of the fact that IPMI is such a
failure. It's easy to see why, they get to charge a pretty nice
premium for the  presence of those BMCs.

Coreboot would be a huge plus. A 45-second POST, in this day and age,
is just simply ridiculous. Even were we to accept that 45-second post,
 the BIOS on this Nehalem new board is so defective that it's just
unusuable for what we need -- it doesn't always come out of a reset.

Ward, what's the latest thing you know of?

thanks

ron



From c-d.hailfinger.devel.2006 at gmx.net  Sat Mar  6 17:13:41 2010
From: c-d.hailfinger.devel.2006 at gmx.net (Carl-Daniel Hailfinger)
Date: Sat, 06 Mar 2010 17:13:41 +0100
Subject: [coreboot] GSoC 2010
In-Reply-To: <49f8af42eac1e221bca5af3b9e97b052@imap.1and1.com>
References: <4B8FD7F7.7090307@gmx.net>	<534e5dc21003040917u37e5ea7ek5d29f4b73b8dc445@mail.gmail.com>	<46893e741003060029v13d8af42xde7da120e0ebee1@mail.gmail.com>	<df1430311003060103w22137aa9w7e43e1dd64977654@mail.gmail.com>
	<4B925C5D.1040609@gmx.net> <4B926BB1.4080601@gmx.net>
	<D2B8891A-FEBE-4A46-80BD-A292E109662D@coresystems.de>
	<49f8af42eac1e221bca5af3b9e97b052@imap.1and1.com>
Message-ID: <4B927F35.3060500@gmx.net>

On 06.03.2010 16:19, Joseph Smith wrote:
>
> On Sat, 6 Mar 2010 16:06:50 +0100, Stefan Reinauer
> <stefan.reinauer at coresystems.de> wrote:
>   
>> On 06.03.2010, at 15:50, Carl-Daniel Hailfinger
>> <c-d.hailfinger.devel.2006 at gmx.net
>>  > wrote:
>>     
>>> To summarize:
>>> I don't think porting flashrom to Windows would be a good GSoC task.
>>>
>>> Porting flashrom to DOS would be interesting, but I have no idea if
>>> our
>>> coding style allows usage of old compilers for DOS.
>>>       
>> Porting it to FILO/libpayload would be a nice project, too!
>> With that feature and an easy way to do partly coreboot flashing, we'd
>> have an incredible fallback payload that can even work as a restore
>> point if it's not even possible to boot an OS.
>>     
>
> YES! Flashrom as a coreboot payload would be truly awesome!
>   

Doable, but AFAICS a good student would only need 1 week (maybe 2) to
achieve the simplest variant, so I have to recommend against it as a
GSoC task. It would be a truly good test for GSoC applicants, though.
(Implement a part of that, and we believe you can implement the other
tasks.)

Since there is so much interest in flashrom as a payload, I'd like to
know which variant you prefer:
1. Full flashrom with GUI as payload (may easily exceed 200 kB
uncompressed and 60 kB lzma compressed).
2. Tiny flashrom stub for remote flashing over serial/network/whatever
(~10 kB uncompressed and 3 kB lzma compressed, maybe even smaller).
3. Load flashrom from an external medium (serial/USB/floppy/whatever) to
RAM and execute it (no space requirements).

Variant 1 does waste a lot of flash space and is unable to cope with new
flash chips, and you have no way to recover if flashing goes wrong
because you can't upgrade flashrom in the first place. It is the only
standalone solution, though, and it is fast.
Variant 2 is essentially a stripped down SerialICE with one or two extra
commands. Rather slow, but you can upgrade the controlling flashrom app
on the master computer (and test patches) without having to mess with
the contents of the flash in the slave (to be reflashed) computer.
Besides that, it allows even such stuff as PCI card reflashing (for gPXE
and stuff).
Variant 3 has a high initial load time, but flashing will be fast. No
guarantees on how to recover if flashrom crashes or exits prematurely,
though.

Now if you think these tasks (or a combination thereof) are sufficiently
difficult for GSoC, I'd like to apply for solving them ;-)

Regards,
Carl-Daniel

-- 
"I do consider assignment statements and pointer variables to be among
computer science's most valuable treasures."
-- Donald E. Knuth




From c-d.hailfinger.devel.2006 at gmx.net  Sat Mar  6 17:17:49 2010
From: c-d.hailfinger.devel.2006 at gmx.net (Carl-Daniel Hailfinger)
Date: Sat, 06 Mar 2010 17:17:49 +0100
Subject: [coreboot] GSoC 2010
In-Reply-To: <20100306150509.2476.qmail@stuge.se>
References: <4B8FD7F7.7090307@gmx.net>	<534e5dc21003040917u37e5ea7ek5d29f4b73b8dc445@mail.gmail.com>	<46893e741003060029v13d8af42xde7da120e0ebee1@mail.gmail.com>	<df1430311003060103w22137aa9w7e43e1dd64977654@mail.gmail.com>	<4B925C5D.1040609@gmx.net>
	<4B926BB1.4080601@gmx.net> <20100306150509.2476.qmail@stuge.se>
Message-ID: <4B92802D.7040806@gmx.net>

On 06.03.2010 16:05, Peter Stuge wrote:
> Carl-Daniel Hailfinger wrote:
>   
>> I have no idea if our coding style allows usage of old compilers
>> for DOS.
>>     
>
> Use a DOS extender and it should be fine.
>   

Not what I meant.
AFAIK DJGPP is based on gcc 2.72, and that may not support the C99
features flashrom is using.

Regards,
Carl-Daniel

-- 
"I do consider assignment statements and pointer variables to be among
computer science's most valuable treasures."
-- Donald E. Knuth




From svn at coreboot.org  Sat Mar  6 17:19:11 2010
From: svn at coreboot.org (repository service)
Date: Sat, 06 Mar 2010 17:19:11 +0100
Subject: [coreboot] [commit] r5193 - trunk/src/cpu/intel/model_6xx
Message-ID: <E1Nnwid-0001qt-IX@ra.coresystems.de>

Author: uwe
Date: Sat Mar  6 17:19:11 2010
New Revision: 5193
URL: http://tracker.coreboot.org/trac/coreboot/changeset/5193

Log:
Add support for the 0x06B1 CPU ID for Celeron (Tualatin).

Signed-off-by: Keith Hui <buurin at gmail.com>
Acked-by: Uwe Hermann <uwe at hermann-uwe.de>

Modified:
   trunk/src/cpu/intel/model_6xx/model_6xx_init.c

Modified: trunk/src/cpu/intel/model_6xx/model_6xx_init.c
==============================================================================
--- trunk/src/cpu/intel/model_6xx/model_6xx_init.c	Fri Mar  5 20:12:34 2010	(r5192)
+++ trunk/src/cpu/intel/model_6xx/model_6xx_init.c	Sat Mar  6 17:19:11 2010	(r5193)
@@ -58,6 +58,7 @@
 	{ X86_VENDOR_INTEL, 0x06A1 },
 	{ X86_VENDOR_INTEL, 0x06A4 },
 	{ X86_VENDOR_INTEL, 0x06B0 }, /* Mobile Celeron FCBGA */
+	{ X86_VENDOR_INTEL, 0x06B1 }, /* Celeron (Tualatin) */
 	{ X86_VENDOR_INTEL, 0x06B4 },
 	{ 0, 0 },
 };



From joe at settoplinux.org  Sat Mar  6 17:22:06 2010
From: joe at settoplinux.org (Joseph Smith)
Date: Sat, 06 Mar 2010 11:22:06 -0500
Subject: [coreboot] GSoC 2010
In-Reply-To: <4B927F35.3060500@gmx.net>
References: <4B8FD7F7.7090307@gmx.net>	<534e5dc21003040917u37e5ea7ek5d29f4b73b8dc445@mail.gmail.com>	<46893e741003060029v13d8af42xde7da120e0ebee1@mail.gmail.com>	<df1430311003060103w22137aa9w7e43e1dd64977654@mail.gmail.com>
	<4B925C5D.1040609@gmx.net> <4B926BB1.4080601@gmx.net>
	<D2B8891A-FEBE-4A46-80BD-A292E109662D@coresystems.de>
	<49f8af42eac1e221bca5af3b9e97b052@imap.1and1.com>
	<4B927F35.3060500@gmx.net>
Message-ID: <db06ef2110edd4d219d6dedeaf32ceb8@imap.1and1.com>




On Sat, 06 Mar 2010 17:13:41 +0100, Carl-Daniel Hailfinger
<c-d.hailfinger.devel.2006 at gmx.net> wrote:
> On 06.03.2010 16:19, Joseph Smith wrote:
>>
>> On Sat, 6 Mar 2010 16:06:50 +0100, Stefan Reinauer
>> <stefan.reinauer at coresystems.de> wrote:
>>
>>> On 06.03.2010, at 15:50, Carl-Daniel Hailfinger
>>> <c-d.hailfinger.devel.2006 at gmx.net
>>>  > wrote:
>>>
>>>> To summarize:
>>>> I don't think porting flashrom to Windows would be a good GSoC task.
>>>>
>>>> Porting flashrom to DOS would be interesting, but I have no idea if
>>>> our
>>>> coding style allows usage of old compilers for DOS.
>>>>
>>> Porting it to FILO/libpayload would be a nice project, too!
>>> With that feature and an easy way to do partly coreboot flashing, we'd
>>> have an incredible fallback payload that can even work as a restore
>>> point if it's not even possible to boot an OS.
>>>
>>
>> YES! Flashrom as a coreboot payload would be truly awesome!
>>
> 
> Doable, but AFAICS a good student would only need 1 week (maybe 2) to
> achieve the simplest variant, so I have to recommend against it as a
> GSoC task. It would be a truly good test for GSoC applicants, though.
> (Implement a part of that, and we believe you can implement the other
> tasks.)
> 
> Since there is so much interest in flashrom as a payload, I'd like to
> know which variant you prefer:
> 1. Full flashrom with GUI as payload (may easily exceed 200 kB
> uncompressed and 60 kB lzma compressed).
> 2. Tiny flashrom stub for remote flashing over serial/network/whatever
> (~10 kB uncompressed and 3 kB lzma compressed, maybe even smaller).
> 3. Load flashrom from an external medium (serial/USB/floppy/whatever) to
> RAM and execute it (no space requirements).
> 
> Variant 1 does waste a lot of flash space and is unable to cope with new
> flash chips, and you have no way to recover if flashing goes wrong
> because you can't upgrade flashrom in the first place. It is the only
> standalone solution, though, and it is fast.
> Variant 2 is essentially a stripped down SerialICE with one or two extra
> commands. Rather slow, but you can upgrade the controlling flashrom app
> on the master computer (and test patches) without having to mess with
> the contents of the flash in the slave (to be reflashed) computer.
> Besides that, it allows even such stuff as PCI card reflashing (for gPXE
> and stuff).
> Variant 3 has a high initial load time, but flashing will be fast. No
> guarantees on how to recover if flashrom crashes or exits prematurely,
> though.
> 
> Now if you think these tasks (or a combination thereof) are sufficiently
> difficult for GSoC, I'd like to apply for solving them ;-)
> 
What about Variant 1 but with Kconfig options to choose only certain flash
chips supported by your board, thus reducing the overall size. This
combined with bayou and a normal OS booting payload would be incredible :-)

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




From joe at settoplinux.org  Sat Mar  6 17:35:12 2010
From: joe at settoplinux.org (Joseph Smith)
Date: Sat, 06 Mar 2010 11:35:12 -0500
Subject: [coreboot] GSoC 2010
In-Reply-To: <db06ef2110edd4d219d6dedeaf32ceb8@imap.1and1.com>
References: <4B8FD7F7.7090307@gmx.net>	<534e5dc21003040917u37e5ea7ek5d29f4b73b8dc445@mail.gmail.com>	<46893e741003060029v13d8af42xde7da120e0ebee1@mail.gmail.com>	<df1430311003060103w22137aa9w7e43e1dd64977654@mail.gmail.com>
	<4B925C5D.1040609@gmx.net> <4B926BB1.4080601@gmx.net>
	<D2B8891A-FEBE-4A46-80BD-A292E109662D@coresystems.de>
	<49f8af42eac1e221bca5af3b9e97b052@imap.1and1.com>
	<4B927F35.3060500@gmx.net>
	<db06ef2110edd4d219d6dedeaf32ceb8@imap.1and1.com>
Message-ID: <46977b4d8eda4b5257e89ee04b3ed0cc@imap.1and1.com>




On Sat, 06 Mar 2010 11:22:06 -0500, Joseph Smith <joe at settoplinux.org>
wrote:
> 
> 
> 
> On Sat, 06 Mar 2010 17:13:41 +0100, Carl-Daniel Hailfinger
> <c-d.hailfinger.devel.2006 at gmx.net> wrote:
>> On 06.03.2010 16:19, Joseph Smith wrote:
>>>
>>> On Sat, 6 Mar 2010 16:06:50 +0100, Stefan Reinauer
>>> <stefan.reinauer at coresystems.de> wrote:
>>>
>>>> On 06.03.2010, at 15:50, Carl-Daniel Hailfinger
>>>> <c-d.hailfinger.devel.2006 at gmx.net
>>>>  > wrote:
>>>>
>>>>> To summarize:
>>>>> I don't think porting flashrom to Windows would be a good GSoC task.
>>>>>
>>>>> Porting flashrom to DOS would be interesting, but I have no idea if
>>>>> our
>>>>> coding style allows usage of old compilers for DOS.
>>>>>
>>>> Porting it to FILO/libpayload would be a nice project, too!
>>>> With that feature and an easy way to do partly coreboot flashing, we'd
>>>> have an incredible fallback payload that can even work as a restore
>>>> point if it's not even possible to boot an OS.
>>>>
>>>
>>> YES! Flashrom as a coreboot payload would be truly awesome!
>>>
>>
>> Doable, but AFAICS a good student would only need 1 week (maybe 2) to
>> achieve the simplest variant, so I have to recommend against it as a
>> GSoC task. It would be a truly good test for GSoC applicants, though.
>> (Implement a part of that, and we believe you can implement the other
>> tasks.)
>>
>> Since there is so much interest in flashrom as a payload, I'd like to
>> know which variant you prefer:
>> 1. Full flashrom with GUI as payload (may easily exceed 200 kB
>> uncompressed and 60 kB lzma compressed).
>> 2. Tiny flashrom stub for remote flashing over serial/network/whatever
>> (~10 kB uncompressed and 3 kB lzma compressed, maybe even smaller).
>> 3. Load flashrom from an external medium (serial/USB/floppy/whatever) to
>> RAM and execute it (no space requirements).
>>
>> Variant 1 does waste a lot of flash space and is unable to cope with new
>> flash chips, and you have no way to recover if flashing goes wrong
>> because you can't upgrade flashrom in the first place. It is the only
>> standalone solution, though, and it is fast.
>> Variant 2 is essentially a stripped down SerialICE with one or two extra
>> commands. Rather slow, but you can upgrade the controlling flashrom app
>> on the master computer (and test patches) without having to mess with
>> the contents of the flash in the slave (to be reflashed) computer.
>> Besides that, it allows even such stuff as PCI card reflashing (for gPXE
>> and stuff).
>> Variant 3 has a high initial load time, but flashing will be fast. No
>> guarantees on how to recover if flashrom crashes or exits prematurely,
>> though.
>>
>> Now if you think these tasks (or a combination thereof) are sufficiently
>> difficult for GSoC, I'd like to apply for solving them ;-)
>>
> What about Variant 1 but with Kconfig options to choose only certain
flash
> chips supported by your board, thus reducing the overall size. This
> combined with bayou and a normal OS booting payload would be incredible
:-)
> 
Or like Stefan said, just make it part of FILO, that way it already has
disk access to find the bios image to flash.

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




From rminnich at gmail.com  Sat Mar  6 18:12:33 2010
From: rminnich at gmail.com (ron minnich)
Date: Sat, 6 Mar 2010 09:12:33 -0800
Subject: [coreboot] GSoC 2010
In-Reply-To: <49f8af42eac1e221bca5af3b9e97b052@imap.1and1.com>
References: <4B8FD7F7.7090307@gmx.net>
	<534e5dc21003040917u37e5ea7ek5d29f4b73b8dc445@mail.gmail.com>
	<46893e741003060029v13d8af42xde7da120e0ebee1@mail.gmail.com>
	<df1430311003060103w22137aa9w7e43e1dd64977654@mail.gmail.com>
	<4B925C5D.1040609@gmx.net> <4B926BB1.4080601@gmx.net>
	<D2B8891A-FEBE-4A46-80BD-A292E109662D@coresystems.de>
	<49f8af42eac1e221bca5af3b9e97b052@imap.1and1.com>
Message-ID: <13426df11003060912w1fbb3c03t12ad7ba6f0f0d16a@mail.gmail.com>

As a project, I'd still like to see someone try the "serialice as
bootblock" and see how it goes.

Let me explain. At the meeting in 2006, we decided it would be nice to
have an "all is lost" mode wherein we'd flash a new image from the
serial port. I still like this idea. I think serialice would be the
foundation of this capability.

If a given mainboard could be extended to include the basic commands
for flashing, then we could experiment with this model. Coreboot would
need to be modified, mainly to allow it to be loaded into
lower-than-top-64k, but we do this already: it's called the "normal"
build.

I think all the bits are there, they just need assembly. This model
would be *ideal* for me on the Dell cluster, even better than the old
normal/fallback model.

Not well defined, I realize, but I'd be happy to mentor someone who
wanted to give this a try.

ron



From stepan at coresystems.de  Sat Mar  6 18:50:05 2010
From: stepan at coresystems.de (Stefan Reinauer)
Date: Sat, 06 Mar 2010 18:50:05 +0100
Subject: [coreboot] GSoC 2010
In-Reply-To: <4B927F35.3060500@gmx.net>
References: <4B8FD7F7.7090307@gmx.net>	<534e5dc21003040917u37e5ea7ek5d29f4b73b8dc445@mail.gmail.com>	<46893e741003060029v13d8af42xde7da120e0ebee1@mail.gmail.com>	<df1430311003060103w22137aa9w7e43e1dd64977654@mail.gmail.com>
	<4B925C5D.1040609@gmx.net> <4B926BB1.4080601@gmx.net>
	<D2B8891A-FEBE-4A46-80BD-A292E109662D@coresystems.de>
	<49f8af42eac1e221bca5af3b9e97b052@imap.1and1.com>
	<4B927F35.3060500@gmx.net>
Message-ID: <4B9295CD.80002@coresystems.de>

On 3/6/10 5:13 PM, Carl-Daniel Hailfinger wrote:
> Since there is so much interest in flashrom as a payload, I'd like to
> know which variant you prefer:
> 1. Full flashrom with GUI as payload (may easily exceed 200 kB
> uncompressed and 60 kB lzma compressed).
> 2. Tiny flashrom stub for remote flashing over serial/network/whatever
> (~10 kB uncompressed and 3 kB lzma compressed, maybe even smaller).
> 3. Load flashrom from an external medium (serial/USB/floppy/whatever) to
> RAM and execute it (no space requirements).
>   
Just having it as a FILO add-on would be the best solution. Then it can
use all the FILO infrastructure (reading lots of filesystems, using a
recovery with a nice menu on a USB stick, integrate with the flash
protection that FILO offers (lock flash writes before FILO executes
external code for example)


> Variant 1 does waste a lot of flash space and is unable to cope with new
> flash chips, and you have no way to recover if flashing goes wrong
> because you can't upgrade flashrom in the first place. It is the only
> standalone solution, though, and it is fast.
> Variant 2 is essentially a stripped down SerialICE with one or two extra
> commands. Rather slow, but you can upgrade the controlling flashrom app
> on the master computer (and test patches) without having to mess with
> the contents of the flash in the slave (to be reflashed) computer.
> Besides that, it allows even such stuff as PCI card reflashing (for gPXE
> and stuff).
> Variant 3 has a high initial load time, but flashing will be fast. No
> guarantees on how to recover if flashrom crashes or exits prematurely,
> though.
>   
I agree all those variants have some drawbacks...

Stefan



From c-d.hailfinger.devel.2006 at gmx.net  Sat Mar  6 18:55:56 2010
From: c-d.hailfinger.devel.2006 at gmx.net (Carl-Daniel Hailfinger)
Date: Sat, 06 Mar 2010 18:55:56 +0100
Subject: [coreboot] GSoC 2010
In-Reply-To: <13426df11003060912w1fbb3c03t12ad7ba6f0f0d16a@mail.gmail.com>
References: <4B8FD7F7.7090307@gmx.net>	
	<534e5dc21003040917u37e5ea7ek5d29f4b73b8dc445@mail.gmail.com>	
	<46893e741003060029v13d8af42xde7da120e0ebee1@mail.gmail.com>	
	<df1430311003060103w22137aa9w7e43e1dd64977654@mail.gmail.com>	
	<4B925C5D.1040609@gmx.net> <4B926BB1.4080601@gmx.net>	
	<D2B8891A-FEBE-4A46-80BD-A292E109662D@coresystems.de>	
	<49f8af42eac1e221bca5af3b9e97b052@imap.1and1.com>
	<13426df11003060912w1fbb3c03t12ad7ba6f0f0d16a@mail.gmail.com>
Message-ID: <4B92972C.5070806@gmx.net>

On 06.03.2010 18:12, ron minnich wrote:
> As a project, I'd still like to see someone try the "serialice as
> bootblock" and see how it goes.
>
> Let me explain. At the meeting in 2006, we decided it would be nice to
> have an "all is lost" mode wherein we'd flash a new image from the
> serial port. I still like this idea. I think serialice would be the
> foundation of this capability.
>
> If a given mainboard could be extended to include the basic commands
> for flashing, then we could experiment with this model. Coreboot would
> need to be modified, mainly to allow it to be loaded into
> lower-than-top-64k, but we do this already: it's called the "normal"
> build.
>
> I think all the bits are there, they just need assembly. This model
> would be *ideal* for me on the Dell cluster, even better than the old
> normal/fallback model.
>
> Not well defined, I realize, but I'd be happy to mentor someone who
> wanted to give this a try.
>   

Oh, I would definitely be interested (well, it is variant 2 of my
proposal), but due to the hard requirements of flashing, the code either
has to run from CAR or from RAM. Not only the stack, but also the code
has to be outside flash. Why? Simple. During write or erase of any
Parallel/LPC/FWH chip, all reads are guaranteed to return garbage (bit 6
and 7 are reserved for JEDEC completion detection on some chips, other
chips simply return the status register instead of valid data). That
means instruction fetch from ROM has to be avoided at all costs. SPI
isn't much better, many datasheets mention that the results of reads
during erase/write are undefined. Please note that this is not the fault
of flashrom (no other flashing software would be able to cope either).

There are three points in time where the "all is lost" code can be run
in theory:
1. Without CAR or RAM. No reflashing possible (see above).
2. With CAR and without RAM. Works as long as the CPU can execute code
from CAR and at the same time have either a stack in CAR (neat) or store
a few bytes elsewhere (but it needs ROMCC for that).
3. With RAM. No limitations here.

Regards,
Carl-Daniel

-- 
"I do consider assignment statements and pointer variables to be among
computer science's most valuable treasures."
-- Donald E. Knuth




From c-d.hailfinger.devel.2006 at gmx.net  Sat Mar  6 19:00:57 2010
From: c-d.hailfinger.devel.2006 at gmx.net (Carl-Daniel Hailfinger)
Date: Sat, 06 Mar 2010 19:00:57 +0100
Subject: [coreboot] GSoC 2010
In-Reply-To: <db06ef2110edd4d219d6dedeaf32ceb8@imap.1and1.com>
References: <4B8FD7F7.7090307@gmx.net>	<534e5dc21003040917u37e5ea7ek5d29f4b73b8dc445@mail.gmail.com>	<46893e741003060029v13d8af42xde7da120e0ebee1@mail.gmail.com>	<df1430311003060103w22137aa9w7e43e1dd64977654@mail.gmail.com>	<4B925C5D.1040609@gmx.net>
	<4B926BB1.4080601@gmx.net>	<D2B8891A-FEBE-4A46-80BD-A292E109662D@coresystems.de>	<49f8af42eac1e221bca5af3b9e97b052@imap.1and1.com>	<4B927F35.3060500@gmx.net>
	<db06ef2110edd4d219d6dedeaf32ceb8@imap.1and1.com>
Message-ID: <4B929859.4040609@gmx.net>

On 06.03.2010 17:22, Joseph Smith wrote:
> On Sat, 06 Mar 2010 17:13:41 +0100, Carl-Daniel Hailfinger
> <c-d.hailfinger.devel.2006 at gmx.net> wrote:
>   
>> On 06.03.2010 16:19, Joseph Smith wrote:
>>     
>>> YES! Flashrom as a coreboot payload would be truly awesome!
>>>
>>>       
>> 1. Full flashrom with GUI as payload (may easily exceed 200 kB
>> uncompressed and 60 kB lzma compressed).
>>
>> Variant 1 does waste a lot of flash space and is unable to cope with new
>> flash chips, and you have no way to recover if flashing goes wrong
>> because you can't upgrade flashrom in the first place. It is the only
>> standalone solution, though, and it is fast.
>>     
> What about Variant 1 but with Kconfig options to choose only certain flash
> chips supported by your board, thus reducing the overall size. This
> combined with bayou and a normal OS booting payload would be incredible :-)
>   

While it would be cool, this needs a completely working coreboot
including VGA init (how would you interact with the system otherwise),
and if that works, you can usually run Linux anyway or at least load
some code from disk or from the network (the place where the new image
would live).

So yes, would be a neat gimmick, but IMHO of limited value.

Regards,
Carl-Daniel

-- 
"I do consider assignment statements and pointer variables to be among
computer science's most valuable treasures."
-- Donald E. Knuth




From svn at coreboot.org  Sat Mar  6 19:16:25 2010
From: svn at coreboot.org (repository service)
Date: Sat, 06 Mar 2010 19:16:25 +0100
Subject: [coreboot] [commit] r5194 - trunk/src/northbridge/intel/i440bx
Message-ID: <E1NnyY5-0005Np-HC@ra.coresystems.de>

Author: uwe
Date: Sat Mar  6 19:16:25 2010
New Revision: 5194
URL: http://tracker.coreboot.org/trac/coreboot/changeset/5194

Log:
440BX: Do not hardcode DIMM number + size anymore.

The code currently assumes a 4-DIMM-slots board, this will be fixed soon.

Signed-off-by: Keith Hui <buurin at gmail.com>
Acked-by: Uwe Hermann <uwe at hermann-uwe.de>

Modified:
   trunk/src/northbridge/intel/i440bx/i440bx.h
   trunk/src/northbridge/intel/i440bx/raminit.c

Modified: trunk/src/northbridge/intel/i440bx/i440bx.h
==============================================================================
--- trunk/src/northbridge/intel/i440bx/i440bx.h	Sat Mar  6 17:19:11 2010	(r5193)
+++ trunk/src/northbridge/intel/i440bx/i440bx.h	Sat Mar  6 19:16:25 2010	(r5194)
@@ -32,11 +32,27 @@
  * Any addresses between 0x00 and 0xff not listed below are either
  * Reserved or Intel Reserved and should not be touched.
  */
+
 #define NBXCFG  0x50 /* 440BX Configuration (0x0000:00S0_0000_000S_0S00b). */
 #define DRAMC   0x57 /* DRAM Control (00S0_0000b). */
 #define DRAMT   0x58 /* DRAM Timing (0x03). */
 #define PAM     0x59 /* Programmable Attribute Map, 7 registers (0x00). */
+#define PAM0    0x59
+#define PAM1    0x5a
+#define PAM2    0x5b
+#define PAM3    0x5c
+#define PAM4    0x5d
+#define PAM5    0x5e
+#define PAM6    0x5f
 #define DRB     0x60 /* DRAM Row Boundary, 8 registers (0x01). */
+#define DRB0    0x60
+#define DRB1    0x61
+#define DRB2    0x62
+#define DRB3    0x63
+#define DRB4    0x64
+#define DRB5    0x65
+#define DRB6    0x66
+#define DRB7    0x67
 #define FDHC    0x68 /* Fixed SDRAM Hole Control (0x00). */
 #define MBSC    0x69 /* Memory Buffer Strength Control (0x0000-0000-0000). */
 #define SMRAM   0x72 /* System Management RAM Control (0x02). */
@@ -50,27 +66,24 @@
 #define ERRCMD  0x90 /* Error Command Register (0x80). */
 #define ERRSTS  0x91 /* Error Status (0x0000). */
 // TODO: AGP stuff.
+#define ACAPID  0xa0 /* AGP Capability Identifier (0x00100002 or 0x00000000) */
+#define AGPSTAT 0xa4 /* AGP Status Register (0x1f000203, read only) */
+#define AGPCMD  0xa8 /* AGP Command Register (0x00000000) */
+#define AGPCTRL 0xb0 /* AGP Control Register (0x00000000) */
+#define APSIZE  0xb4 /* Aperture Size Control Register (0x00) */
+#define ATTBASE 0xb8 /* Aperture Translation Table (0x00000000) */
+ 
 #define MBFS    0xca /* Memory Buffer Frequency Select (0x000000). */
 #define BSPAD   0xd0 /* BIOS Scratch Pad (0x000..000). */
+#define BSPAD0  0xd0 /* These are free for our use. */ 
+#define BSPAD1  0xd1
+#define BSPAD2  0xd2
+#define BSPAD3  0xd3
+#define BSPAD4  0xd4
+#define BSPAD5  0xd5
+#define BSPAD6  0xd6
+#define BSPAD7  0xd7
 #define DWTC    0xe0 /* DRAM Write Thermal Throttling Control (0x000..000). */
 #define DRTC    0xe8 /* DRAM Read Thermal Throttling Control (0x000..000). */
 #define BUFFC   0xf0 /* Buffer Control Register (0x0000). */
 
-/* For convenience: */
-#define DRB0    0x60
-#define DRB1    0x61
-#define DRB2    0x62
-#define DRB3    0x63
-#define DRB4    0x64
-#define DRB5    0x65
-#define DRB6    0x66
-#define DRB7    0x67
-
-#define PAM0    0x59
-#define PAM1    0x5a
-#define PAM2    0x5b
-#define PAM3    0x5c
-#define PAM4    0x5d
-#define PAM5    0x5e
-#define PAM6    0x5f
-

Modified: trunk/src/northbridge/intel/i440bx/raminit.c
==============================================================================
--- trunk/src/northbridge/intel/i440bx/raminit.c	Sat Mar  6 17:19:11 2010	(r5193)
+++ trunk/src/northbridge/intel/i440bx/raminit.c	Sat Mar  6 19:16:25 2010	(r5194)
@@ -2,6 +2,7 @@
  * This file is part of the coreboot project.
  *
  * Copyright (C) 2007-2008 Uwe Hermann <uwe at hermann-uwe.de>
+ * Copyright (C) 2010 Keith Hui <buurin at gmail.com>
  *
  * 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
@@ -23,6 +24,7 @@
 #include <delay.h>
 #include <stdlib.h>
 #include "i440bx.h"
+#include "raminit.h"
 
 /*-----------------------------------------------------------------------------
 Macros and definitions.
@@ -185,14 +187,23 @@
 	 * 10 = Write Only (Writes to DRAM, reads to memory mapped I/O space)
 	 * 11 = Read/Write (all access goes to DRAM)
 	 */
-	// TODO
-	PAM0, 0x00, 0x00,
-	PAM1, 0x00, 0x00,
-	PAM2, 0x00, 0x00,
-	PAM3, 0x00, 0x00,
-	PAM4, 0x00, 0x00,
-	PAM5, 0x00, 0x00,
-	PAM6, 0x00, 0x00,
+
+	/*
+	 * Map all legacy regions to RAM (read/write). This is required if
+	 * you want to use the RAM area from 768 KB - 1 MB. If the PAM
+	 * registers are not set here appropriately, the RAM in that region
+	 * will not be accessible, thus a RAM check of it will also fail.
+	 *
+	 * TODO: This was set in sdram_set_spd_registers().
+	 * Test if it still works when set here.
+	 */
+	PAM0, 0x00, 0x30,
+	PAM1, 0x00, 0x33,
+	PAM2, 0x00, 0x33,
+	PAM3, 0x00, 0x33,
+	PAM4, 0x00, 0x33,
+	PAM5, 0x00, 0x33,
+	PAM6, 0x00, 0x33,
 
 	/* DRB[0:7] - DRAM Row Boundary Registers
 	 * 0x60 - 0x67
@@ -340,6 +351,9 @@
 	// PMCR, 0x00, 0x14,
 	// PMCR, 0x00, 0x10,
 	PMCR, 0x00, 0x00,
+
+	/* Enable SCRR.SRRAEN and let BX choose the SRR. */
+	SCRR + 1, 0x00, 0x10,
 };
 
 /*-----------------------------------------------------------------------------
@@ -374,8 +388,8 @@
 	/* Send the RAM command to each row of memory. */
 	dimm_start = 0;
 	for (i = 0; i < (DIMM_SOCKETS * 2); i++) {
-                addr_offset = 0;
-                caslatency = 3; /* TODO: Dynamically get CAS latency later. */
+		addr_offset = 0;
+		caslatency = 3; /* TODO: Dynamically get CAS latency later. */
 		if (command == RAM_COMMAND_MRS) {
 			/*
 			 * MAA[12:11,9:0] must be inverted when sent to DIMM
@@ -411,6 +425,19 @@
 	}
 }
 
+static void set_dram_buffer_strength(void)
+{
+	/* TODO: This needs to be set according to the DRAM tech
+	 * (x8, x16, or x32). Argh, Intel provides no docs on this!
+	 * Currently, it needs to be pulled from the output of
+	 * lspci -xxx Rx92
+	 *
+	 * Relevant registers: MBSC, MBFS, BUFFC.
+	 */
+
+	pci_write_config8(NB, MBSC, 0x03);
+}
+
 /*-----------------------------------------------------------------------------
 DIMM-independant configuration functions.
 -----------------------------------------------------------------------------*/
@@ -458,69 +485,311 @@
 		reg &= register_values[i + 1];
 		reg |= register_values[i + 2] & ~(register_values[i + 1]);
 		pci_write_config8(NB, register_values[i], reg);
-
+#if 0
 		PRINT_DEBUG("    Set register 0x");
 		PRINT_DEBUG_HEX8(register_values[i]);
 		PRINT_DEBUG(" to 0x");
 		PRINT_DEBUG_HEX8(reg);
 		PRINT_DEBUG("\r\n");
+#endif
 	}
 }
 
-static void sdram_set_spd_registers(void)
+struct dimm_size {
+	unsigned long side1;
+	unsigned long side2;
+};
+
+static struct dimm_size spd_get_dimm_size(unsigned int device)
 {
-	/* TODO: Don't hardcode the values here, get info via SPD. */
+	struct dimm_size sz;
+	int i, module_density, dimm_banks;
+	sz.side1 = 0;
+	module_density = spd_read_byte(device, SPD_DENSITY_OF_EACH_ROW_ON_MODULE);
+	dimm_banks = spd_read_byte(device, SPD_NUM_DIMM_BANKS);
+
+	/* Find the size of side1. */
+	/* Find the larger value. The larger value is always side1. */
+	for (i = 512; i >= 0; i >>= 1) {
+		if ((module_density & i) == i) {
+			sz.side1 = i;
+			break;
+		}
+	}
 
-	/* Map all legacy regions to RAM (read/write). This is required if
-	 * you want to use the RAM area from 768 KB - 1 MB. If the PAM
-	 * registers are not set here appropriately, the RAM in that region
-	 * will not be accessible, thus a RAM check of it will also fail.
+	/* Set to 0 in case it's single sided. */
+	sz.side2 = 0;
+
+	/* Test if it's a dual-sided DIMM. */
+	if (dimm_banks > 1) {
+		/* Test if there's a second value. If so it's asymmetrical. */
+		if (module_density != i) {
+			/*
+			 * Find second value, picking up where we left off.
+			 * i >>= 1 done initially to make sure we don't get
+			 * the same value again.
+			 */
+			for (i >>= 1; i >= 0; i >>= 1) {
+				if (module_density == (sz.side1 | i)) {
+					sz.side2 = i;
+					break;
+				}
+			}
+			/* If not, it's symmetrical. */
+		} else {
+			sz.side2 = sz.side1;
+		}
+	}
+
+	/*
+	 * SPD byte 31 is the memory size divided by 4 so we
+	 * need to muliply by 4 to get the total size.
 	 */
-	pci_write_config8(NB, PAM0, 0x30);
-	pci_write_config8(NB, PAM1, 0x33);
-	pci_write_config8(NB, PAM2, 0x33);
-	pci_write_config8(NB, PAM3, 0x33);
-	pci_write_config8(NB, PAM4, 0x33);
-	pci_write_config8(NB, PAM5, 0x33);
-	pci_write_config8(NB, PAM6, 0x33);
-
-	/* TODO: Set DRB0-DRB7. */
-	/* Currently this is hardcoded to one 64 MB DIMM in slot 0. */
-	pci_write_config8(NB, DRB0, 0x08);
-	pci_write_config8(NB, DRB1, 0x08);
-	pci_write_config8(NB, DRB2, 0x08);
-	pci_write_config8(NB, DRB3, 0x08);
-	pci_write_config8(NB, DRB4, 0x08);
-	pci_write_config8(NB, DRB5, 0x08);
-	pci_write_config8(NB, DRB6, 0x08);
-	pci_write_config8(NB, DRB7, 0x08);
+	sz.side1 *= 4;
+	sz.side2 *= 4;
+
+	return sz;
+}
+/*
+ * Sets DRAM attributes one DIMM at a time, based on SPD data.
+ * Northbridge settings that are set: NBXCFG[31:24], DRB0-DRB7, RPS, DRAMC.
+ */
+static void set_dram_row_attributes(void)
+{
+	int i, dra, drb, col, width, value, rps, edosd, ecc, nbxecc;
+	u8 bpr; /* Top 8 bits of PGPOL */
 
-	/* TODO: Set DRAMC. Don't enable refresh for now. */
-	pci_write_config8(NB, DRAMC, 0x08);
+	edosd = 0;
+	rps = 0;
+	drb = 0;
+	bpr = 0;
+	nbxecc = 0xff;
 
-	/* TODO: Set RPS. Needs to be fixed for multiple DIMM support. */
-	pci_write_config16(NB, RPS, 0x0001);
+	for (i = 0; i < DIMM_SOCKETS; i++) {
+		unsigned int device;
+		device = DIMM_SPD_BASE + i;
+		bpr >>= 2;
+
+		/* First check if a DIMM is actually present. */
+		value = spd_read_byte(device, SPD_MEMORY_TYPE);
+		/* This is 440BX! We do EDO too! */
+		if (value == SPD_MEMORY_TYPE_EDO
+			|| value == SPD_MEMORY_TYPE_SDRAM) {
+
+			PRINT_DEBUG("Found ");
+			if (value == SPD_MEMORY_TYPE_EDO) {
+				edosd |= 0x02; 
+			} else if (value == SPD_MEMORY_TYPE_SDRAM) { 
+				edosd |= 0x04; 
+			}
+			PRINT_DEBUG("DIMM in slot ");
+			PRINT_DEBUG_HEX8(i);
+			PRINT_DEBUG("\r\n");
+
+			if (edosd == 0x06) { 
+				print_err("Mixing EDO/SDRAM unsupported!\r\n");
+				die("HALT\r\n");
+			}
+
+			/* "DRA" is our RPS for the two rows on this DIMM. */
+			dra = 0;
+
+			/* Columns */
+			col = spd_read_byte(device, SPD_NUM_COLUMNS);
+
+			/*
+			 * Is this an ECC DIMM? Actually will be a 2 if so.
+			 * TODO: Other register than NBXCFG also needs this
+			 * ECC information.
+			 */
+			ecc = spd_read_byte(device, SPD_DIMM_CONFIG_TYPE);
+
+			/* Data width */
+			width = spd_read_byte(device, SPD_MODULE_DATA_WIDTH_LSB);
+			
+			/* Exclude error checking data width from page size calculations */
+			if (ecc) {
+				value = spd_read_byte(device,
+					SPD_ERROR_CHECKING_SDRAM_WIDTH);
+				width -= value;
+				/* ### ECC */
+				/* Clear top 2 bits to help set up NBXCFG. */
+				ecc &= 0x3f;
+			} else {
+				/* Without ECC, top 2 bits should be 11. */
+				ecc |= 0xc0;
+			}
+
+			/* Calculate page size in bits. */
+			value = ((1 << col) * width);
+
+			/* Convert to KB. */
+			dra = (value >> 13);
+
+			/* Number of banks of DIMM (single or double sided). */
+			value = spd_read_byte(device, SPD_NUM_DIMM_BANKS);
+
+			/* Once we have dra, col is done and can be reused.
+			 * So it's reused for number of banks.
+			 */
+			col = spd_read_byte(device, SPD_NUM_BANKS_PER_SDRAM);
+
+			if (value == 1) {
+				/*
+				 * Second bank of 1-bank DIMMs "doesn't have
+				 * ECC" - or anything.
+				 */
+				ecc |= 0x80;
+				if (dra == 2) {
+					dra = 0x0; /* 2KB */
+				} else if (dra == 4) {
+					dra = 0x1; /* 4KB */
+				} else if (dra == 8) {
+					dra = 0x2; /* 8KB */
+				} else {
+					dra = -1;
+				}
+				/*
+				 * Sets a flag in PGPOL[BPR] if this DIMM has
+				 * 4 banks per row.
+				 */
+				if (col == 4)
+					bpr |= 0x40;
+			} else if (value == 2) {
+				if (dra == 2) {
+					dra = 0x0; /* 2KB */
+				} else if (dra == 4) {
+					dra = 0x05; /* 4KB */
+				} else if (dra == 8) {
+					dra = 0x0a; /* 8KB */
+				} else {
+					dra = -1;
+				}
+				/* Ditto */
+				if (col == 4)
+					bpr |= 0xc0;
+			} else {
+				print_err("# of banks of DIMM unsupported!\r\n");
+				die("HALT\r\n");
+			}
+			if (dra == -1) {
+				print_err("Page size not supported\r\n");
+				die("HALT\r\n");
+			}
+
+			/*
+			 * 440BX supports asymmetrical dual-sided DIMMs,
+			 * but can't handle DIMMs smaller than 8MB per
+			 * side or larger than 128MB per side.
+			 */
+			struct dimm_size sz = spd_get_dimm_size(device);
+			if ((sz.side1 < 8)) {
+				print_err("DIMMs smaller than 8MB per side\r\n"
+					  "are not supported on this NB.\r\n");
+				die("HALT\r\n");
+			}
+			if ((sz.side1 > 128)) {
+				print_err ("DIMMs > 128MB per side\r\n"
+					   "are not supported on this NB\r\n");
+				die("HALT\r\n");
+			}
+
+			/* Divide size by 8 to set up the DRB registers. */
+			drb += (sz.side1 / 8);
+
+			/*
+			 * Build the DRB for the next row in MSB so it gets
+			 * placed in DRB[n+1] where it belongs when written
+			 * as a 16-bit word.
+			 */
+			drb &= 0xff;
+			drb |= (drb + (sz.side2 / 8)) << 8;
+		} else {
+#if 0
+			PRINT_DEBUG("No DIMM found in slot ");
+			PRINT_DEBUG_HEX8(i);
+			PRINT_DEBUG("\r\n");
+#endif
+
+			/* If there's no DIMM in the slot, set dra to 0x00. */
+			dra = 0x00;
+			ecc = 0xc0;
+			/* Still have to propagate DRB over. */
+			drb &= 0xff;
+			drb |= (drb << 8);
+		}
+
+		pci_write_config16(NB, DRB + (2 * i), drb);
+#if 0
+		PRINT_DEBUG("DRB has been set to 0x");
+		PRINT_DEBUG_HEX16(drb);
+		PRINT_DEBUG("\r\n");
+#endif
+
+		/* Brings the upper DRB back down to be base for
+		 * DRB calculations for the next two rows.
+		 */
+		drb >>= 8;
+
+		rps |= (dra & 0x0f) << (i * 4);
+		nbxecc = (nbxecc >> 2) | (ecc & 0xc0);
+	}
+
+	/* Set paging policy register. */
+	pci_write_config8(NB, PGPOL + 1, bpr);
+	PRINT_DEBUG("PGPOL[BPR] has been set to 0x");
+	PRINT_DEBUG_HEX8(bpr);
+	PRINT_DEBUG("\r\n");
+
+	/* Set DRAM row page size register. */
+	pci_write_config16(NB, RPS, rps);
+	PRINT_DEBUG("RPS has been set to 0x");
+	PRINT_DEBUG_HEX16(rps);
+	PRINT_DEBUG("\r\n");
+
+	/* ### ECC */
+	pci_write_config8(NB, NBXCFG + 3, nbxecc);
+	PRINT_DEBUG("NBXECC[31:24] has been set to 0x");
+	PRINT_DEBUG_HEX8(nbxecc);
+	PRINT_DEBUG("\r\n");
+
+	/* Set DRAMC[4:3] to proper memory type (EDO/SDRAM).
+	 * TODO: Registered SDRAM support.
+	 */
+	edosd &= 0x07;
+	if (edosd & 0x02) {
+		edosd |= 0x00;
+	} else if (edosd & 0x04) {
+		edosd |= 0x08;
+	}
+	edosd &= 0x18;
+
+	/* edosd is now in the form needed for DRAMC[4:3]. */
+	value = pci_read_config8(NB, DRAMC) & 0xe7;
+	value |= edosd;
+	pci_write_config8(NB, DRAMC, value);
+	PRINT_DEBUG("DRAMC has been set to 0x");
+	PRINT_DEBUG_HEX8(value);
+	PRINT_DEBUG("\r\n");
+}
+
+static void sdram_set_spd_registers(void)
+{
+	/* Setup DRAM row boundary registers and other attributes. */
+	set_dram_row_attributes();
 
 	/* TODO: Set SDRAMC. */
 	pci_write_config16(NB, SDRAMC, 0x0010);	/* SDRAMPWR=1: 4 DIMM config */
 
-	/* TODO: Set PGPOL. */
-	// pci_write_config16(NB, PGPOL, 0x0107);
-	pci_write_config16(NB, PGPOL, 0x0123);
-
-	/* TODO: Set NBXCFG. */
-	// pci_write_config32(NB, NBXCFG, 0x0100220c); // FIXME?
-	pci_write_config32(NB, NBXCFG, 0xff00800c);
+	/* TODO */
+	set_dram_buffer_strength();
 
 	/* TODO: Set PMCR? */
 	// pci_write_config8(NB, PMCR, 0x14);
 	pci_write_config8(NB, PMCR, 0x10);
 
 	/* TODO? */
-	pci_write_config8(NB, PCI_LATENCY_TIMER, 0x40);
 	pci_write_config8(NB, DRAMT, 0x03);
-	pci_write_config8(NB, MBSC, 0x03);
-	pci_write_config8(NB, SCRR, 0x38);
 }
 
 static void sdram_enable(void)



From c-d.hailfinger.devel.2006 at gmx.net  Sat Mar  6 19:26:16 2010
From: c-d.hailfinger.devel.2006 at gmx.net (Carl-Daniel Hailfinger)
Date: Sat, 06 Mar 2010 19:26:16 +0100
Subject: [coreboot] GSoC 2010
In-Reply-To: <4B9295CD.80002@coresystems.de>
References: <4B8FD7F7.7090307@gmx.net>	<534e5dc21003040917u37e5ea7ek5d29f4b73b8dc445@mail.gmail.com>	<46893e741003060029v13d8af42xde7da120e0ebee1@mail.gmail.com>	<df1430311003060103w22137aa9w7e43e1dd64977654@mail.gmail.com>
	<4B925C5D.1040609@gmx.net> <4B926BB1.4080601@gmx.net>
	<D2B8891A-FEBE-4A46-80BD-A292E109662D@coresystems.de>
	<49f8af42eac1e221bca5af3b9e97b052@imap.1and1.com>
	<4B927F35.3060500@gmx.net> <4B9295CD.80002@coresystems.de>
Message-ID: <4B929E48.1090908@gmx.net>

On 06.03.2010 18:50, Stefan Reinauer wrote:
> On 3/6/10 5:13 PM, Carl-Daniel Hailfinger wrote:
>   
>> 1. Full flashrom with GUI as payload (may easily exceed 200 kB
>> uncompressed and 60 kB lzma compressed).
>> 2. Tiny flashrom stub for remote flashing over serial/network/whatever
>> (~10 kB uncompressed and 3 kB lzma compressed, maybe even smaller).
>> 3. Load flashrom from an external medium (serial/USB/floppy/whatever) to
>> RAM and execute it (no space requirements).
>>   
>>     
> Just having it as a FILO add-on would be the best solution. Then it can
> use all the FILO infrastructure (reading lots of filesystems, using a
> recovery with a nice menu on a USB stick, 

OTOH, it could simply be an ELF loaded by FILO. That allows upgrades of
flashrom as needed, and if FILO can load flash images from any media, it
should be able to do the same with executable code.

> integrate with the flash
> protection that FILO offers (lock flash writes before FILO executes
> external code for example)
>   

Now that is indeed a compelling reason to have FILO support flashing.
Then again, if flashrom-in-FILO doesn't check a cryptographic signature
of the new flash image, the flash protection effect is rather limited.

Anyway, I can do it if you let me do it.

Regards,
Carl-Daniel

-- 
"I do consider assignment statements and pointer variables to be among
computer science's most valuable treasures."
-- Donald E. Knuth




From uwe at hermann-uwe.de  Sat Mar  6 19:28:25 2010
From: uwe at hermann-uwe.de (Uwe Hermann)
Date: Sat, 6 Mar 2010 19:28:25 +0100
Subject: [coreboot] [PATCH] ASUS P2B-LS support, RAM detection for 440BX,
 add Slot 1 CPU, Microcode for Intel Tualatin CPUs
In-Reply-To: <b72cdb061003022019x18ab2b0fo7de47d2d1b0f9609@mail.gmail.com>
References: <b72cdb061003022019x18ab2b0fo7de47d2d1b0f9609@mail.gmail.com>
Message-ID: <20100306182824.GD13408@greenwood>

Hi,

I think I reviewed and committed most of the stuff now, except for the
microcode updates, IIRC there will be some bigger patch handling those
in the near future anyway.

See some more notes below.


On Tue, Mar 02, 2010 at 11:19:24PM -0500, Keith Hui wrote:
> - Adds Asus P2B-LS mainboard

Merged with some small cosmetic changes, thanks.


> - Adds RAM detection for i440bx (based on i82830 code). We're no longer hard
> coded for 64MB on one row!

Very nice! I did various smaller changes here, should be functionally
equivalent mostly though, except for these:

 - In i440bx.h: I dropped the generic PCI register definitions, those
   are not 440BX specific and already defined in pci_def.h.

 - Dropped MLT / PCI_LATENCY_TIMER for now, should not be needed, and
   raminit.c is probably the wrong place for this stuff anyway, I guess.

 - Not sure about this change, omitted it for now (need to re-check
   datasheets):

  static const uint32_t refresh_rate_map[] = {
  -       1, 5, 5, 2, 3, 4
  +       1, 1, 1, 2, 3, 4
  };

Probably also some more stuff I forgot about. One thing I'd like to do
next is to factor out some stuff from set_dram_row_attributes(), that's
way too long and too nested for my taste.


> - Adds a proper Slot 1 cpu under src/cpu/intel/slot_1. It's a stub copied
> from slot_2 but addresses a few FIXMEs. My P2B-LS code refers to this.

Yep, thanks! I'll fixup the other slot 1 boards in a few minutes or so.


> - Adds microcode for Intel Tualatin CPUs, cpuid 6B1 and 6B4.* Actually
> loading them is pending.

Postponed for now, see above.


Will test the code on a few 440BX boards soonish, and fix the 3 vs. 4
DIMM slots issue.


Thanks, Uwe.
-- 
http://www.hermann-uwe.de  | http://www.randomprojects.org
http://www.crazy-hacks.org | http://www.unmaintained-free-software.org



From rminnich at gmail.com  Sat Mar  6 19:52:27 2010
From: rminnich at gmail.com (ron minnich)
Date: Sat, 6 Mar 2010 10:52:27 -0800
Subject: [coreboot] GSoC 2010
In-Reply-To: <4B9295CD.80002@coresystems.de>
References: <4B8FD7F7.7090307@gmx.net>
	<534e5dc21003040917u37e5ea7ek5d29f4b73b8dc445@mail.gmail.com>
	<46893e741003060029v13d8af42xde7da120e0ebee1@mail.gmail.com>
	<df1430311003060103w22137aa9w7e43e1dd64977654@mail.gmail.com>
	<4B925C5D.1040609@gmx.net> <4B926BB1.4080601@gmx.net>
	<D2B8891A-FEBE-4A46-80BD-A292E109662D@coresystems.de>
	<49f8af42eac1e221bca5af3b9e97b052@imap.1and1.com>
	<4B927F35.3060500@gmx.net> <4B9295CD.80002@coresystems.de>
Message-ID: <13426df11003061052w187d2b16m7166c9a377559ce3@mail.gmail.com>

It would be nice, if a flashrom is in there, to also have some sort of
security too I think.

Something that is not as easily compromised as the stuff that's out
there now, which relies on security through obscurity.

Is it even possible?

The only thing I really trust is a jumper, but nobody seems to put
those in any more. A pity.

thanks

ron



From rminnich at gmail.com  Sat Mar  6 20:01:11 2010
From: rminnich at gmail.com (ron minnich)
Date: Sat, 6 Mar 2010 11:01:11 -0800
Subject: [coreboot] [PATCH] ASUS P2B-LS support, RAM detection for 440BX,
	add Slot 1 CPU, Microcode for Intel Tualatin CPUs
In-Reply-To: <20100306182824.GD13408@greenwood>
References: <b72cdb061003022019x18ab2b0fo7de47d2d1b0f9609@mail.gmail.com>
	<20100306182824.GD13408@greenwood>
Message-ID: <13426df11003061101ja0cd5bex9d7adad03b86f94d@mail.gmail.com>

This activity is really impressive. It got me to wondering: how old is
the 440bx chipset? I know it's been around a while. It sure seems to
live one ...

ron



From c-d.hailfinger.devel.2006 at gmx.net  Sat Mar  6 20:28:06 2010
From: c-d.hailfinger.devel.2006 at gmx.net (Carl-Daniel Hailfinger)
Date: Sat, 06 Mar 2010 20:28:06 +0100
Subject: [coreboot] GSoC 2010
In-Reply-To: <13426df11003061052w187d2b16m7166c9a377559ce3@mail.gmail.com>
References: <4B8FD7F7.7090307@gmx.net>	<534e5dc21003040917u37e5ea7ek5d29f4b73b8dc445@mail.gmail.com>	<46893e741003060029v13d8af42xde7da120e0ebee1@mail.gmail.com>	<df1430311003060103w22137aa9w7e43e1dd64977654@mail.gmail.com>	<4B925C5D.1040609@gmx.net>
	<4B926BB1.4080601@gmx.net>	<D2B8891A-FEBE-4A46-80BD-A292E109662D@coresystems.de>	<49f8af42eac1e221bca5af3b9e97b052@imap.1and1.com>	<4B927F35.3060500@gmx.net>
	<4B9295CD.80002@coresystems.de>
	<13426df11003061052w187d2b16m7166c9a377559ce3@mail.gmail.com>
Message-ID: <4B92ACC6.8050305@gmx.net>

On 06.03.2010 19:52, ron minnich wrote:
> It would be nice, if a flashrom is in there, to also have some sort of
> security too I think.
>
> Something that is not as easily compromised as the stuff that's out
> there now, which relies on security through obscurity.
>
> Is it even possible?
>   

Well, I implemented signature checking for coreboot (so that only signed
payloads would be executed).

The big question is: Do you want to protect against
1. someone with full hardware access (developer),
2. someone sitting in front of the machine but without hardware access
(computer pool),
3. against evil malware (including rootkits)?
I'd say the first category is pointless with current x86 hardware.
Second category should be easily achieved by requiring a signed boot
image for a non-lockdown boot. A default boot would be with locked down
flash, and only a special kernel/payload/bootable-file-on-disk would be
able to reflash. Needs chipset cooperation and/or one-shot GPIOs.
Third category would allow the user to select an unlocked boot. Locked
boot would be default, and the setting would not be stored anywhere to
avoid circumvention.


> The only thing I really trust is a jumper, but nobody seems to put
> those in any more. A pity.
>   

At least one modern flash chip ignores the write protect pin for some
erase commands. A jumper won't help here. Chipset lockdown can be
circumvented as well. If you really want a rootkit-resistant protection,
you need two flash chips and some additional circuitry.

(I once worked as an infosec penetration tester, and it shows. I don't
believe in magic, nor do I believe in correct operation of any chip
under non-standard conditions.)

Regards,
Carl-Daniel

-- 
"I do consider assignment statements and pointer variables to be among
computer science's most valuable treasures."
-- Donald E. Knuth




From ward at gnu.org  Sat Mar  6 20:33:52 2010
From: ward at gnu.org (Ward Vandewege)
Date: Sat, 6 Mar 2010 14:33:52 -0500
Subject: [coreboot] server hardware without IPMI / with coreboot
In-Reply-To: <13426df11003060803g7d8c4623i4ad4b36a06aee570@mail.gmail.com>
References: <afd6944b1003042253q139e636bm2809fced98f4eda8@mail.gmail.com>
	<13426df11003051026y16c5053q3d3f77144308548f@mail.gmail.com>
	<4B919E03.9090907@gmx.net>
	<20100306143241.GA12021@countzero.vandewege.net>
	<13426df11003060803g7d8c4623i4ad4b36a06aee570@mail.gmail.com>
Message-ID: <20100306193352.GA26578@countzero.vandewege.net>

On Sat, Mar 06, 2010 at 08:03:40AM -0800, ron minnich wrote:
> So, if you're looking to buy 150 or so nodes, what's a reasonable
> coreboot-capable node *without* any sort of BMC/IPMI? I really need
> these IPMI-free boards and the vendors keep trying to shove this IPMI
> nonsense down our throats -- in spite of the fact that IPMI is such a
> failure. It's easy to see why, they get to charge a pretty nice
> premium for the  presence of those BMCs.

While the IPMI BMC is tightly integrated with the mainboard, it tends to be
an optional module on Supermicro (and Tyan, I guess, I have not looked
recently though) boards. So you can definitely order without the module.

> Coreboot would be a huge plus. A 45-second POST, in this day and age,
> is just simply ridiculous. Even were we to accept that 45-second post,
>  the BIOS on this Nehalem new board is so defective that it's just
> unusuable for what we need -- it doesn't always come out of a reset.
> 
> Ward, what's the latest thing you know of?

I still like Opteron a lot. Here's the current list of Supermicro boards
based on the latest SR56x0/SP5100 chipset:

  http://www.supermicro.com/Aplus/motherboard/Opteron2000/

I wonder if these boards will take the 8 and 12 core CPUs AMD is due to
release at the end of this month.

Silicon Mechanics has a few systems built on those boards, but so far only a
2U (nServ A346) and 3U (A362). They should be able to to tell you when they
will have 1U systems (assuming that's what you are looking for here).

There are also very nifty 'twin' systems (1U) and 2x2 twin systems (4 boards,
hot swappable, in a 2U chassis with redundant power and 12 disk bays). Sadly,
I've only seen the 2x2 with Intel boards, so far...

My experience is that if you talk to a vendor like Silicon Mechanics or Aspen
Systems and tell them you want to buy 150 systems, they will at least *try*
to help with coreboot by talking to their suppliers.

I guess the most important thing right now would be to get AMD to release
docs (and code?) for the SR56x0/SP5100 chipset. With that, supporting any of
the boards listed above might be possible. This chipset is likely to be
around for a while (5 years?).

Thanks,
Ward.

-- 
Ward Vandewege <ward at gnu.org>



From rminnich at gmail.com  Sat Mar  6 21:17:57 2010
From: rminnich at gmail.com (ron minnich)
Date: Sat, 6 Mar 2010 12:17:57 -0800
Subject: [coreboot] GSoC 2010
In-Reply-To: <4B92ACC6.8050305@gmx.net>
References: <4B8FD7F7.7090307@gmx.net>
	<df1430311003060103w22137aa9w7e43e1dd64977654@mail.gmail.com>
	<4B925C5D.1040609@gmx.net> <4B926BB1.4080601@gmx.net>
	<D2B8891A-FEBE-4A46-80BD-A292E109662D@coresystems.de>
	<49f8af42eac1e221bca5af3b9e97b052@imap.1and1.com>
	<4B927F35.3060500@gmx.net> <4B9295CD.80002@coresystems.de>
	<13426df11003061052w187d2b16m7166c9a377559ce3@mail.gmail.com>
	<4B92ACC6.8050305@gmx.net>
Message-ID: <13426df11003061217o217cbc6cs316fec7c99efef19@mail.gmail.com>

On Sat, Mar 6, 2010 at 11:28 AM, Carl-Daniel Hailfinger
<c-d.hailfinger.devel.2006 at gmx.net> wrote:
> On 06.03.2010 19:52, ron minnich wrote:
>> It would be nice, if a flashrom is in there, to also have some sort of
>> security too I think.
>>
>> Something that is not as easily compromised as the stuff that's out
>> there now, which relies on security through obscurity.
>>
>> Is it even possible?
>>
>
> Well, I implemented signature checking for coreboot (so that only signed
> payloads would be executed).
>
> The big question is: Do you want to protect against
> 1. someone with full hardware access (developer),
> 2. someone sitting in front of the machine but without hardware access
> (computer pool),
> 3. against evil malware (including rootkits)?
> I'd say the first category is pointless with current x86 hardware.

I agree completely.
> Second category should be easily achieved by requiring a signed boot
> image for a non-lockdown boot. A default boot would be with locked down
> flash, and only a special kernel/payload/bootable-file-on-disk would be
> able to reflash. Needs chipset cooperation and/or one-shot GPIOs.
> Third category would allow the user to select an unlocked boot. Locked
> boot would be default, and the setting would not be stored anywhere to
> avoid circumvention.

3 is the biggest concern. For me, anyway. (2) is close however.


> At least one modern flash chip ignores the write protect pin for some
> erase commands. A jumper won't help here.

WHO designs this stuff? it would be nice to have a blacklist for such
poor designs.

>Chipset lockdown can be
> circumvented as well. If you really want a rootkit-resistant protection,
> you need two flash chips and some additional circuitry.
>
> (I once worked as an infosec penetration tester, and it shows. I don't
> believe in magic, nor do I believe in correct operation of any chip
> under non-standard conditions.)

I'm glad you're on OUR side :-)

ron



From christian.leber at ziti.uni-heidelberg.de  Sat Mar  6 21:05:06 2010
From: christian.leber at ziti.uni-heidelberg.de (Christian Leber)
Date: Sat, 6 Mar 2010 21:05:06 +0100
Subject: [coreboot] [PATCH] ASUS P2B-LS support, RAM detection for 440BX,
	add Slot 1 CPU, Microcode for Intel Tualatin CPUs
In-Reply-To: <13426df11003061101ja0cd5bex9d7adad03b86f94d@mail.gmail.com>
References: <b72cdb061003022019x18ab2b0fo7de47d2d1b0f9609@mail.gmail.com>
	<20100306182824.GD13408@greenwood>
	<13426df11003061101ja0cd5bex9d7adad03b86f94d@mail.gmail.com>
Message-ID: <201003062105.06745.christian.leber@ziti.uni-heidelberg.de>

On Saturday 06 March 2010 20:01:11 ron minnich wrote:
> This activity is really impressive. It got me to wondering: how old is
> the 440bx chipset?

it was released in april 1998

Christian



From yinghailu at gmail.com  Sat Mar  6 21:24:16 2010
From: yinghailu at gmail.com (yhlu)
Date: Sat, 6 Mar 2010 12:24:16 -0800
Subject: [coreboot] Hi...all
In-Reply-To: <13426df11003051026y16c5053q3d3f77144308548f@mail.gmail.com>
References: <afd6944b1003042253q139e636bm2809fced98f4eda8@mail.gmail.com>
	<13426df11003051026y16c5053q3d3f77144308548f@mail.gmail.com>
Message-ID: <2ea3fae11003061224u1c47dbf1h170fe32450acb62a@mail.gmail.com>

On Fri, Mar 5, 2010 at 10:26 AM, ron minnich <rminnich at gmail.com> wrote:

> What would coreboot need to do to "support" IPMI BMC?
>

need to use BT or KCS interface to tell FRU list esp for the devices there
is side band access from BMC

also may need to abitritry etc to make sure BMC and host don't access some
devices at same time
like GPIO, and i2c...

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

From darmawan.salihun at gmail.com  Sat Mar  6 22:07:50 2010
From: darmawan.salihun at gmail.com (Darmawan Salihun)
Date: Sun, 7 Mar 2010 04:07:50 +0700
Subject: [coreboot] GSoC 2010
In-Reply-To: <4B925C5D.1040609@gmx.net>
References: <4B8FD7F7.7090307@gmx.net>
	<534e5dc21003040917u37e5ea7ek5d29f4b73b8dc445@mail.gmail.com>
	<46893e741003060029v13d8af42xde7da120e0ebee1@mail.gmail.com>
	<df1430311003060103w22137aa9w7e43e1dd64977654@mail.gmail.com>
	<4B925C5D.1040609@gmx.net>
Message-ID: <46893e741003061307v5263d914sb0e29cb2502633b3@mail.gmail.com>

On 3/6/10, Carl-Daniel Hailfinger <c-d.hailfinger.devel.2006 at gmx.net> wrote:
> On 06.03.2010 10:03, Jason Wang wrote:
>> On Sat, Mar 6, 2010 at 4:29 PM, Darmawan Salihun wrote:
>>> Flashrom used to have Windows port that I worked on back in 2007
>>> (Winflashrom). I'm willing to help if any student want to port to
>>> Windows 7. I'm not a student anymore ;-)
>>>
>> i am thinking who about making flashrom can be used under windows?
>>
>
> I think Stefan Reinauer already ported flashrom to Windows 7, AFAIK
> somewhat based on the original Windows port. Look here:
> http://www.coreboot.org/pipermail/flashrom/2009-August/000239.html .
> Darmawan, it would be cool if you could look at this as well. flashrom
> now has a lot better abstraction than back when you did the original
> Windows port, and merging Stefan's patch should be possible. It's been a
> while, but I think DirectIO for Windows hasn't been released yet.

OK. Looking into it now ;-).
I'm not well versed with Windows 7 driver model yet.
I'm gonna need to working on it nonetheless, for my book.
I'll let you guys know.

>
>
>> does coreboot and flashrom will join gsoc 2010 as an union or else?
>>
>
> Yes, coreboot and flashrom will have one joint project for GSoC 2010.
>
> Regards,
> Carl-Daniel
>
> --
> "I do consider assignment statements and pointer variables to be among
> computer science's most valuable treasures."
> -- Donald E. Knuth
>
>

Regards,

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



From rminnich at gmail.com  Sat Mar  6 22:14:21 2010
From: rminnich at gmail.com (ron minnich)
Date: Sat, 6 Mar 2010 13:14:21 -0800
Subject: [coreboot] Hi...all
In-Reply-To: <2ea3fae11003061224u1c47dbf1h170fe32450acb62a@mail.gmail.com>
References: <afd6944b1003042253q139e636bm2809fced98f4eda8@mail.gmail.com>
	<13426df11003051026y16c5053q3d3f77144308548f@mail.gmail.com>
	<2ea3fae11003061224u1c47dbf1h170fe32450acb62a@mail.gmail.com>
Message-ID: <13426df11003061314w2d0089d1we6e65013253a8350@mail.gmail.com>

On Sat, Mar 6, 2010 at 12:24 PM, yhlu <yinghailu at gmail.com> wrote:
>
>
> On Fri, Mar 5, 2010 at 10:26 AM, ron minnich <rminnich at gmail.com> wrote:
>>
>> What would coreboot need to do to "support" IPMI BMC?
>
> need to use BT or KCS interface to tell FRU list esp for the devices there
> is side band access from BMC
>
> also may need to abitritry etc to make sure BMC and host don't access some
> devices at same time
> like GPIO, and i2c...

ah. You just gave me another reason to never want a BMC on board :-)

OK, good to know.

ron



From svn at coreboot.org  Sat Mar  6 22:18:44 2010
From: svn at coreboot.org (repository service)
Date: Sat, 06 Mar 2010 22:18:44 +0100
Subject: [coreboot] [commit] r5195 - trunk
Message-ID: <E1No1OW-0006t8-8U@ra.coresystems.de>

Author: oxygene
Date: Sat Mar  6 22:18:43 2010
New Revision: 5195
URL: http://tracker.coreboot.org/trac/coreboot/changeset/5195

Log:
More readable recursive descent macro in Makefile

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

Modified:
   trunk/Makefile

Modified: trunk/Makefile
==============================================================================
--- trunk/Makefile	Sat Mar  6 19:16:25 2010	(r5194)
+++ trunk/Makefile	Sat Mar  6 22:18:43 2010	(r5195)
@@ -119,8 +119,32 @@
 crt0s:=
 ldscripts:=
 types:=obj initobj driver smmobj
-includemakefiles=$(foreach type,$(2), $(eval $(type)-y:=)) $(eval subdirs-y:=) $(eval -include $(1)) $(if $(strip $(3)),$(foreach type,$(2),$(eval $(type)s+=$$(patsubst util/%,$(obj)/util/%,$$(patsubst src/%,$(obj)/%,$$(addprefix $(dir $(1)),$$($(type)-y))))))) $(eval subdirs+=$$(subst $(PWD)/,,$$(abspath $$(addprefix $(dir $(1)),$$(subdirs-y)))))
-evaluate_subdirs=$(eval cursubdirs:=$(subdirs)) $(eval subdirs:=) $(foreach dir,$(cursubdirs),$(eval $(call includemakefiles,$(dir)/Makefile.inc,$(types),$(1)))) $(if $(subdirs),$(eval $(call evaluate_subdirs, $(1))))
+
+# Clean -y variables, include Makefile.inc
+# If $(3) is non-empty, add paths to files in X-y, and add them to Xs
+# Add subdirs-y to subdirs
+includemakefiles= \
+	$(foreach type,$(2), $(eval $(type)-y:=)) \
+	$(eval subdirs-y:=) \
+	$(eval -include $(1)) \
+	$(if $(strip $(3)), \
+		$(foreach type,$(2), \
+			$(eval $(type)s+= \
+				$$(patsubst util/%, \
+					$(obj)/util/%, \
+					$$(patsubst src/%, \
+						$(obj)/%, \
+						$$(addprefix $(dir $(1)),$$($(type)-y))))))) \
+	$(eval subdirs+=$$(subst $(PWD)/,,$$(abspath $$(addprefix $(dir $(1)),$$(subdirs-y)))))
+
+# For each path in $(subdirs) call includemakefiles, passing $(1) as $(3)
+# Repeat until subdirs is empty
+evaluate_subdirs= \
+	$(eval cursubdirs:=$(subdirs)) \
+	$(eval subdirs:=) \
+	$(foreach dir,$(cursubdirs), \
+		$(eval $(call includemakefiles,$(dir)/Makefile.inc,$(types),$(1)))) \
+	$(if $(subdirs),$(eval $(call evaluate_subdirs, $(1))))
 
 # collect all object files eligible for building
 subdirs:=$(PLATFORM-y) $(BUILD-y)



From r.marek at assembler.cz  Sat Mar  6 23:47:22 2010
From: r.marek at assembler.cz (Rudolf Marek)
Date: Sat, 06 Mar 2010 23:47:22 +0100
Subject: [coreboot] GSoC 2010
In-Reply-To: <4B92802D.7040806@gmx.net>
References: <4B8FD7F7.7090307@gmx.net>	<534e5dc21003040917u37e5ea7ek5d29f4b73b8dc445@mail.gmail.com>	<46893e741003060029v13d8af42xde7da120e0ebee1@mail.gmail.com>	<df1430311003060103w22137aa9w7e43e1dd64977654@mail.gmail.com>	<4B925C5D.1040609@gmx.net>	<4B926BB1.4080601@gmx.net>
	<20100306150509.2476.qmail@stuge.se> <4B92802D.7040806@gmx.net>
Message-ID: <4B92DB7A.9070400@assembler.cz>

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

> Not what I meant.
> AFAIK DJGPP is based on gcc 2.72, and that may not support the C99
> features flashrom is using.

Well then compile with libpayload and write simple DOS wrapper to load it ;)

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

iEYEARECAAYFAkuS23oACgkQ3J9wPJqZRNUhQwCg3XOzh4VT5dRdgEuPWvRELhzU
qYoAoKW7o86UtVV/b7UQJEu3GKh5l3Zp
=UCy5
-----END PGP SIGNATURE-----



From stepan at coresystems.de  Sat Mar  6 23:57:32 2010
From: stepan at coresystems.de (Stefan Reinauer)
Date: Sat, 06 Mar 2010 23:57:32 +0100
Subject: [coreboot] GSoC 2010
In-Reply-To: <4B92ACC6.8050305@gmx.net>
References: <4B8FD7F7.7090307@gmx.net>	<534e5dc21003040917u37e5ea7ek5d29f4b73b8dc445@mail.gmail.com>	<46893e741003060029v13d8af42xde7da120e0ebee1@mail.gmail.com>	<df1430311003060103w22137aa9w7e43e1dd64977654@mail.gmail.com>	<4B925C5D.1040609@gmx.net>	<4B926BB1.4080601@gmx.net>	<D2B8891A-FEBE-4A46-80BD-A292E109662D@coresystems.de>	<49f8af42eac1e221bca5af3b9e97b052@imap.1and1.com>	<4B927F35.3060500@gmx.net>	<4B9295CD.80002@coresystems.de>	<13426df11003061052w187d2b16m7166c9a377559ce3@mail.gmail.com>
	<4B92ACC6.8050305@gmx.net>
Message-ID: <4B92DDDC.7030804@coresystems.de>

On 3/6/10 8:28 PM, Carl-Daniel Hailfinger wrote:
> On 06.03.2010 19:52, ron minnich wrote:
>   
>> It would be nice, if a flashrom is in there, to also have some sort of
>> security too I think.
>>
>> Something that is not as easily compromised as the stuff that's out
>> there now, which relies on security through obscurity.
>>
>> Is it even possible?
>>   
>>     
> Well, I implemented signature checking for coreboot (so that only signed
> payloads would be executed).
>   
When coresystems developed our first version of hard crypto signature
checking for firmware in 2007/2008 we explicitly decided to not check
the payload but only let the payload check further stages. The reason
was that if you're able to compromise the flash chip, you're able to
reprogram coreboot just as well as the payload. Also, we didn't want
feel comfortable to duplicate the amount of crypto code in the flash,
and there is no serious mechanism around that protects only the
bootblock, at least not on commonly used systems.

So I'm interested to hear your reasons to do this in coreboot itself...
Is your code publically available somewhere?

Regards,
Stefan





From stepan at coresystems.de  Sun Mar  7 00:02:45 2010
From: stepan at coresystems.de (Stefan Reinauer)
Date: Sun, 07 Mar 2010 00:02:45 +0100
Subject: [coreboot] GSoC 2010
In-Reply-To: <13426df11003061217o217cbc6cs316fec7c99efef19@mail.gmail.com>
References: <4B8FD7F7.7090307@gmx.net>	<df1430311003060103w22137aa9w7e43e1dd64977654@mail.gmail.com>	<4B925C5D.1040609@gmx.net>
	<4B926BB1.4080601@gmx.net>	<D2B8891A-FEBE-4A46-80BD-A292E109662D@coresystems.de>	<49f8af42eac1e221bca5af3b9e97b052@imap.1and1.com>	<4B927F35.3060500@gmx.net>
	<4B9295CD.80002@coresystems.de>	<13426df11003061052w187d2b16m7166c9a377559ce3@mail.gmail.com>	<4B92ACC6.8050305@gmx.net>
	<13426df11003061217o217cbc6cs316fec7c99efef19@mail.gmail.com>
Message-ID: <4B92DF15.10200@coresystems.de>

On 3/6/10 9:17 PM, ron minnich wrote:
> On Sat, Mar 6, 2010 at 11:28 AM, Carl-Daniel Hailfinger
> <c-d.hailfinger.devel.2006 at gmx.net> wrote:
>   
>> On 06.03.2010 19:52, ron minnich wrote:
>>     
>>> It would be nice, if a flashrom is in there, to also have some sort of
>>> security too I think.
>>>
>>> Something that is not as easily compromised as the stuff that's out
>>> there now, which relies on security through obscurity.
>>>
>>> Is it even possible?
>>>
>>>       
>> Well, I implemented signature checking for coreboot (so that only signed
>> payloads would be executed).
>>
>> The big question is: Do you want to protect against
>> 1. someone with full hardware access (developer),
>> 2. someone sitting in front of the machine but without hardware access
>> (computer pool),
>> 3. against evil malware (including rootkits)?
>> I'd say the first category is pointless with current x86 hardware.
>>     
> I agree completely.
>   
Also, the question is what kind of privilege escalation can be caused by
a security breach. While you can always solder a new flash chip on an
x86 system these days you can still encrypt your data in order to
protect (read) access.
> 3 is the biggest concern. For me, anyway. (2) is close however.
>   
Someone sitting in front of the machine usually does have hardware
access, so the differentiation is kind of artificial unless you count
the people forgetting to bring soldering irons and screw drivers.

Stefan



From c-d.hailfinger.devel.2006 at gmx.net  Sun Mar  7 01:11:32 2010
From: c-d.hailfinger.devel.2006 at gmx.net (Carl-Daniel Hailfinger)
Date: Sun, 07 Mar 2010 01:11:32 +0100
Subject: [coreboot] GSoC 2010
In-Reply-To: <4B92DDDC.7030804@coresystems.de>
References: <4B8FD7F7.7090307@gmx.net>	<534e5dc21003040917u37e5ea7ek5d29f4b73b8dc445@mail.gmail.com>	<46893e741003060029v13d8af42xde7da120e0ebee1@mail.gmail.com>	<df1430311003060103w22137aa9w7e43e1dd64977654@mail.gmail.com>	<4B925C5D.1040609@gmx.net>	<4B926BB1.4080601@gmx.net>	<D2B8891A-FEBE-4A46-80BD-A292E109662D@coresystems.de>	<49f8af42eac1e221bca5af3b9e97b052@imap.1and1.com>	<4B927F35.3060500@gmx.net>	<4B9295CD.80002@coresystems.de>	<13426df11003061052w187d2b16m7166c9a377559ce3@mail.gmail.com>	<4B92ACC6.8050305@gmx.net>
	<4B92DDDC.7030804@coresystems.de>
Message-ID: <4B92EF34.1010400@gmx.net>

On 06.03.2010 23:57, Stefan Reinauer wrote:
> On 3/6/10 8:28 PM, Carl-Daniel Hailfinger wrote:
>   
>> On 06.03.2010 19:52, ron minnich wrote:
>>   
>>     
>>> It would be nice, if a flashrom is in there, to also have some sort of
>>> security too I think.
>>>
>>> Something that is not as easily compromised as the stuff that's out
>>> there now, which relies on security through obscurity.
>>>
>>> Is it even possible?
>>>   
>>>     
>>>       
>> Well, I implemented signature checking for coreboot (so that only signed
>> payloads would be executed).
>>   
>>     
> When coresystems developed our first version of hard crypto signature
> checking for firmware in 2007/2008 we explicitly decided to not check
> the payload but only let the payload check further stages. The reason
> was that if you're able to compromise the flash chip, you're able to
> reprogram coreboot just as well as the payload. Also, we didn't want
> feel comfortable to duplicate the amount of crypto code in the flash,
> and there is no serious mechanism around that protects only the
> bootblock, at least not on commonly used systems.
>   

Indeed.

> So I'm interested to hear your reasons to do this in coreboot itself...
> Is your code publically available somewhere?
>   

Code:
http://www.mail-archive.com/coreboot at coreboot.org/msg17372.html
Thesis by Rene Reuter:
http://sit.sit.fraunhofer.de/smv/publications/downloads/KonzeptTrustedBoot_Reuter.pdf
Reasons:
Basically, I did it for fun, and because Rene was stuck trying to
include OpenSSL in coreboot. I simply coded up a working alternative.
And yes, I agree that checking the payload is pointless if flash
protection is either full-on (not needed) or full-off (attacker can
modify coreboot itself). The only halfway reasonable use case would be
if coreboot is in a write protected part of the flash chip and the
payload is in an unprotected part of the flash chip.

Regards,
Carl-Daniel

-- 
"I do consider assignment statements and pointer variables to be among
computer science's most valuable treasures."
-- Donald E. Knuth




From c-d.hailfinger.devel.2006 at gmx.net  Sun Mar  7 01:26:21 2010
From: c-d.hailfinger.devel.2006 at gmx.net (Carl-Daniel Hailfinger)
Date: Sun, 07 Mar 2010 01:26:21 +0100
Subject: [coreboot] GSoC 2010
In-Reply-To: <4B92DF15.10200@coresystems.de>
References: <4B8FD7F7.7090307@gmx.net>	<df1430311003060103w22137aa9w7e43e1dd64977654@mail.gmail.com>	<4B925C5D.1040609@gmx.net>	<4B926BB1.4080601@gmx.net>	<D2B8891A-FEBE-4A46-80BD-A292E109662D@coresystems.de>	<49f8af42eac1e221bca5af3b9e97b052@imap.1and1.com>	<4B927F35.3060500@gmx.net>	<4B9295CD.80002@coresystems.de>	<13426df11003061052w187d2b16m7166c9a377559ce3@mail.gmail.com>	<4B92ACC6.8050305@gmx.net>	<13426df11003061217o217cbc6cs316fec7c99efef19@mail.gmail.com>
	<4B92DF15.10200@coresystems.de>
Message-ID: <4B92F2AD.7020002@gmx.net>

On 07.03.2010 00:02, Stefan Reinauer wrote:
> On 3/6/10 9:17 PM, ron minnich wrote:
>   
>> On Sat, Mar 6, 2010 at 11:28 AM, Carl-Daniel Hailfinger wrote:
>>     
>>> Well, I implemented signature checking for coreboot (so that only signed
>>> payloads would be executed).
>>>
>>> The big question is: Do you want to protect against
>>> 1. someone with full hardware access (developer),
>>> 2. someone sitting in front of the machine but without hardware access
>>> (computer pool),
>>> 3. against evil malware (including rootkits)?
>>> I'd say the first category is pointless with current x86 hardware.
>>>
>>>       
>> I agree completely.
>>   
>>     
> Also, the question is what kind of privilege escalation can be caused by
> a security breach. While you can always solder a new flash chip on an
> x86 system these days you can still encrypt your data in order to
> protect (read) access.
>   

It depends on the security model. If you store the encryption key in the
ROM, people can read it out if they have hardware access. If there are
protections in place against such readout, there is still the chance to
rig something with the help of SerialICE.


>> 3 is the biggest concern. For me, anyway. (2) is close however.
>>   
>>     
> Someone sitting in front of the machine usually does have hardware
> access, so the differentiation is kind of artificial unless you count
> the people forgetting to bring soldering irons and screw drivers.
>   

I hope someone questions/stops you if you decide to bring screwdrivers
and a soldering iron to a shared student computer room and start taking
apart one of the machines. Then again, doing this is basic social
engineering, and if you are bold enough and ask loudly in that computer
room for someone to assist you, most people will think the operation is
entirely legit.

In the end, what we need is a detailed security model which includes a
good understanding of the threat we want to protect against. Doing many
"security things" is not a fix for anything, but a hand-tailored
solution has the chance of addressing one given problem.

Regards,
Carl-Daniel

-- 
"I do consider assignment statements and pointer variables to be among
computer science's most valuable treasures."
-- Donald E. Knuth




From c-d.hailfinger.devel.2006 at gmx.net  Sun Mar  7 01:27:29 2010
From: c-d.hailfinger.devel.2006 at gmx.net (Carl-Daniel Hailfinger)
Date: Sun, 07 Mar 2010 01:27:29 +0100
Subject: [coreboot] GSoC 2010
In-Reply-To: <4B92DB7A.9070400@assembler.cz>
References: <4B8FD7F7.7090307@gmx.net>	<534e5dc21003040917u37e5ea7ek5d29f4b73b8dc445@mail.gmail.com>	<46893e741003060029v13d8af42xde7da120e0ebee1@mail.gmail.com>	<df1430311003060103w22137aa9w7e43e1dd64977654@mail.gmail.com>	<4B925C5D.1040609@gmx.net>	<4B926BB1.4080601@gmx.net>	<20100306150509.2476.qmail@stuge.se>
	<4B92802D.7040806@gmx.net> <4B92DB7A.9070400@assembler.cz>
Message-ID: <4B92F2F1.80204@gmx.net>

On 06.03.2010 23:47, Rudolf Marek wrote:
> > Not what I meant.
> > AFAIK DJGPP is based on gcc 2.72, and that may not support the C99
> > features flashrom is using.
>
> Well then compile with libpayload and write simple DOS wrapper to load
> it ;)

Brilliant idea. Not exactly what I had in mind, but certainly an option.

Regards,
Carl-Daniel
-- 
"I do consider assignment statements and pointer variables to be among
computer science's most valuable treasures."
-- Donald E. Knuth




From c-d.hailfinger.devel.2006 at gmx.net  Sun Mar  7 01:29:58 2010
From: c-d.hailfinger.devel.2006 at gmx.net (Carl-Daniel Hailfinger)
Date: Sun, 07 Mar 2010 01:29:58 +0100
Subject: [coreboot] GSoC 2010
In-Reply-To: <46893e741003061307v5263d914sb0e29cb2502633b3@mail.gmail.com>
References: <4B8FD7F7.7090307@gmx.net>	
	<534e5dc21003040917u37e5ea7ek5d29f4b73b8dc445@mail.gmail.com>	
	<46893e741003060029v13d8af42xde7da120e0ebee1@mail.gmail.com>	
	<df1430311003060103w22137aa9w7e43e1dd64977654@mail.gmail.com>	
	<4B925C5D.1040609@gmx.net>
	<46893e741003061307v5263d914sb0e29cb2502633b3@mail.gmail.com>
Message-ID: <4B92F386.7030505@gmx.net>

[followup to flashrom at flashrom.org please]

On 06.03.2010 22:07, Darmawan Salihun wrote:
> On 3/6/10, Carl-Daniel Hailfinger <c-d.hailfinger.devel.2006 at gmx.net> wrote:
>   
>> On 06.03.2010 10:03, Jason Wang wrote:
>>     
>>> On Sat, Mar 6, 2010 at 4:29 PM, Darmawan Salihun wrote:
>>>       
>>>> Flashrom used to have Windows port that I worked on back in 2007
>>>> (Winflashrom). I'm willing to help if any student want to port to
>>>> Windows 7. I'm not a student anymore ;-)
>>>>         
>>> i am thinking who about making flashrom can be used under windows?
>>>
>>>       
>> I think Stefan Reinauer already ported flashrom to Windows 7, AFAIK
>> somewhat based on the original Windows port. Look here:
>> http://www.coreboot.org/pipermail/flashrom/2009-August/000239.html .
>> Darmawan, it would be cool if you could look at this as well. flashrom
>> now has a lot better abstraction than back when you did the original
>> Windows port, and merging Stefan's patch should be possible. It's been a
>> while, but I think DirectIO for Windows hasn't been released yet.
>>     
>
> OK. Looking into it now ;-).
> I'm not well versed with Windows 7 driver model yet.
> I'm gonna need to working on it nonetheless, for my book.
> I'll let you guys know.
>   

Cool, thanks.

Regards,
Carl-Daniel

-- 
"I do consider assignment statements and pointer variables to be among
computer science's most valuable treasures."
-- Donald E. Knuth




From c-d.hailfinger.devel.2006 at gmx.net  Sun Mar  7 01:53:38 2010
From: c-d.hailfinger.devel.2006 at gmx.net (Carl-Daniel Hailfinger)
Date: Sun, 07 Mar 2010 01:53:38 +0100
Subject: [coreboot] GSoC 2010
In-Reply-To: <4B92972C.5070806@gmx.net>
References: <4B8FD7F7.7090307@gmx.net>		<534e5dc21003040917u37e5ea7ek5d29f4b73b8dc445@mail.gmail.com>		<46893e741003060029v13d8af42xde7da120e0ebee1@mail.gmail.com>		<df1430311003060103w22137aa9w7e43e1dd64977654@mail.gmail.com>		<4B925C5D.1040609@gmx.net>
	<4B926BB1.4080601@gmx.net>		<D2B8891A-FEBE-4A46-80BD-A292E109662D@coresystems.de>		<49f8af42eac1e221bca5af3b9e97b052@imap.1and1.com>	<13426df11003060912w1fbb3c03t12ad7ba6f0f0d16a@mail.gmail.com>
	<4B92972C.5070806@gmx.net>
Message-ID: <4B92F912.9020007@gmx.net>

Hi,

I updated http://www.coreboot.org/GSoC with my project ideas and some
basic information. Please update the wiki with your own ideas and fix
the stuff I forgot.

Thank you.

Regards,
Carl-Daniel



From r.marek at assembler.cz  Sun Mar  7 11:29:15 2010
From: r.marek at assembler.cz (Rudolf Marek)
Date: Sun, 07 Mar 2010 11:29:15 +0100
Subject: [coreboot] GSoC 2010
In-Reply-To: <4B92F2F1.80204@gmx.net>
References: <4B8FD7F7.7090307@gmx.net>	<534e5dc21003040917u37e5ea7ek5d29f4b73b8dc445@mail.gmail.com>	<46893e741003060029v13d8af42xde7da120e0ebee1@mail.gmail.com>	<df1430311003060103w22137aa9w7e43e1dd64977654@mail.gmail.com>	<4B925C5D.1040609@gmx.net>	<4B926BB1.4080601@gmx.net>	<20100306150509.2476.qmail@stuge.se>
	<4B92802D.7040806@gmx.net> <4B92DB7A.9070400@assembler.cz>
	<4B92F2F1.80204@gmx.net>
Message-ID: <4B937FFB.8070501@assembler.cz>

Carl-Daniel Hailfinger napsal(a):
> On 06.03.2010 23:47, Rudolf Marek wrote:
>>> Not what I meant.
>>> AFAIK DJGPP is based on gcc 2.72, and that may not support the C99
>>> features flashrom is using.
>> Well then compile with libpayload and write simple DOS wrapper to load
>> it ;)
> 
> Brilliant idea. Not exactly what I had in mind, but certainly an option.

Well not so on the other look ;) One would need to do bit of I/O to/from file 
right? Maybe one could place the file to HIGMEM and after flashrom is finished 
write it back using normal dos ;)

Second possibility is to compile against the libpayload and use DPMI services to 
handle the I/O and even setup the protected mode. If one forces the compiler to 
output in COFF format one can even embedd the application in CSWDPMI ;)

Rudolf





From stepan at coresystems.de  Sun Mar  7 15:40:09 2010
From: stepan at coresystems.de (Stefan Reinauer)
Date: Sun, 07 Mar 2010 15:40:09 +0100
Subject: [coreboot] [PATCH] revive llshell
Message-ID: <4B93BAC9.2070900@coresystems.de>

Ron and Peter should like this.... "Panic Room" there you go.

It's of course completely useless if the machine hangs. It could be made
part of "die()" though.

Stefan
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20100307/5c383927/attachment.html>
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: revive_llshell.diff
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20100307/5c383927/attachment.ksh>

From buurin at gmail.com  Sun Mar  7 15:18:28 2010
From: buurin at gmail.com (Keith Hui)
Date: Sun, 7 Mar 2010 09:18:28 -0500
Subject: [coreboot] GSoC 2010
Message-ID: <b72cdb061003070618y12947477m5a6b6fbf940e0c89@mail.gmail.com>

Looking at this on the GSoC page:

> flashrom support for Willem hardware

Haha, I'd so love to see this.

For a base to work off of, look at firebrand:

http://www.astro.gla.ac.uk/~paulm/Code/eprom.html

You may even be able to google for an older version of the original control
program with source.

Also look at the sivava "PCB45" variant as well. This site has info (and
schematics with differences highlighted) on how to convert a PCB3B (for
which schematics is/was available) to a PCB45:
http://www.msxpro.com/py2bbs/willem_pcb45en.php

There are four versions that we can easily get schematics for - original
willem, PCB3B, a simplified, flash-only "EzoFlash", and the PCB45 conversion
above. There are newer variants but they are proprietary. I'd love to see
support for these four implemented.

>From what I read it may be a product of the shady parts of Internet. At
least it is sort of open and easily accessible. I first built EzoFlash on a
breadboard to flash a firmware for my infamous Apex 600A DVD player, and
then built a PCB3B on a crudely made PCB, that I am using right now to flash
440BX RAM initialization code for boot testing.

Have fun.

Keith
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20100307/fe9ce3ab/attachment.html>

From joe at settoplinux.org  Sun Mar  7 16:12:37 2010
From: joe at settoplinux.org (Joseph Smith)
Date: Sun, 07 Mar 2010 10:12:37 -0500
Subject: [coreboot] GSoC 2010
In-Reply-To: <b72cdb061003070618y12947477m5a6b6fbf940e0c89@mail.gmail.com>
References: <b72cdb061003070618y12947477m5a6b6fbf940e0c89@mail.gmail.com>
Message-ID: <f1c64086d882cc8898760d6b75546ae0@imap.1and1.com>




On Sun, 7 Mar 2010 09:18:28 -0500, Keith Hui <buurin at gmail.com> wrote:
> Looking at this on the GSoC page:
> 
>> flashrom support for Willem hardware
> 
> Haha, I'd so love to see this.
> 
> For a base to work off of, look at firebrand:
> 
> http://www.astro.gla.ac.uk/~paulm/Code/eprom.html
> 
Cool, this may even help with the Paraflasher project :-)


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




From c-d.hailfinger.devel.2006 at gmx.net  Sun Mar  7 21:47:21 2010
From: c-d.hailfinger.devel.2006 at gmx.net (Carl-Daniel Hailfinger)
Date: Sun, 07 Mar 2010 21:47:21 +0100
Subject: [coreboot] GSoC 2010
In-Reply-To: <b72cdb061003070618y12947477m5a6b6fbf940e0c89@mail.gmail.com>
References: <b72cdb061003070618y12947477m5a6b6fbf940e0c89@mail.gmail.com>
Message-ID: <4B9410D9.3060907@gmx.net>

Hi Paul,

I'm one of the developers of flashrom <http://www.flashrom.org/> which
aims to be a generic utility for programming all kinds of flash EEPROMs
on your mainboard, on storage/network/graphics cards, and in external
programmers.
There is some interest in integrating parts of your firebrand code to
support a Willem backend/driver for flashrom. Would that be OK with you?
flashrom is GPLv2.

On 07.03.2010 15:18, Keith Hui wrote:
> Looking at this on the GSoC page:
>   
>> flashrom support for Willem hardware
>>     
>
> Haha, I'd so love to see this.
>
> For a base to work off of, look at firebrand:
>
> http://www.astro.gla.ac.uk/~paulm/Code/eprom.html
>   

Cool. I have added Paul to CC of this mail.


> You may even be able to google for an older version of the original control
> program with source.
>
> Also look at the sivava "PCB45" variant as well. This site has info (and
> schematics with differences highlighted) on how to convert a PCB3B (for
> which schematics is/was available) to a PCB45:
> http://www.msxpro.com/py2bbs/willem_pcb45en.php
>
> There are four versions that we can easily get schematics for - original
> willem, PCB3B, a simplified, flash-only "EzoFlash", and the PCB45 conversion
> above. There are newer variants but they are proprietary. I'd love to see
> support for these four implemented.
>
> From what I read it may be a product of the shady parts of Internet. At
> least it is sort of open and easily accessible. I first built EzoFlash on a
> breadboard to flash a firmware for my infamous Apex 600A DVD player, and
> then built a PCB3B on a crudely made PCB, that I am using right now to flash
> 440BX RAM initialization code for boot testing.
>   

Nice.

Basically, flashrom already has chip drivers for 29* series Parallel
flash, 49* series LPC/FWH flash, and 25* series SPI flash (actual model
numbers may differ, but pretty much every flash chip present on
mainboards out there is supported). Support for other chip types
(I2C...) is possible (infrastructure is there) but not on our immediate
TODO list.
flashrom has half a dozen backend programmer drivers, and these backend
drivers can be "dumb", i.e. the only thing they have to do is pass
address/data pairs (Parallel/LPC/FWH) or command streams (SPI) to the
programmer hardware. Adding support for a new programmer can be as easy
as writing 20 lines of code.

Regards,
Carl-Daniel



From buurin at gmail.com  Mon Mar  8 03:20:20 2010
From: buurin at gmail.com (Keith Hui)
Date: Sun, 7 Mar 2010 21:20:20 -0500
Subject: [coreboot] [PATCH] RAM detection for 440BX
Message-ID: <b72cdb061003071820q7e2352c0y49e1158791407017@mail.gmail.com>

On Sat, Mar 6, 2010 at 2:01 PM, ron minnich <rminnich at gmail.com> wrote:

> This activity is really impressive. It got me to wondering: how old is
> the 440bx chipset? I know it's been around a while. It sure seems to
> live one ...
>
> ron
>

Yup, 440BX is alive and well. :-)

I got scored by romcc again in the battle to complete its support.

Attached is my working copy of src/northbridge/intel/i440bx/raminit.c with
more or less complete SDRAM support at 100MHz. There is one problem: romcc
segfaults on it. Because of this, it is not patch ready. It compiles fine on
gcc for my test jig. Anything I added to make it compile for my jig did not
cause this, as I removed them all and it still segfaults.

Any help is again appreciated.

There is also preliminary work done to combine

    sdram_set_registers();
    sdram_set_spd_registers();
    sdram_enable();

into sdram_initialize(), like i82830. I also added a parameter to it for the
motherboard's FSB, so the motherboard romstage can get the FSB off the clock
chip and pass it to raminit.c where SDRAM timings are programmed.

I ended up just dumping the configuration space with three 256MB PC133 DIMMs
installed in all kind of combinations and analyze that. I tested this code
by comparing its output through my test jig with my collected dumps.
SerialICE still not involved. :-)

Joseph, the code to initialize the DIMMs are already there before I came
onboard. Instead of sending the sequence to one row at a time, the 440BX
code sends one command to all populated DIMM rows together. I figure we
could save some execution time as this method is not unlike boiling 8 eggs
all at once.

By the way where in the source tree would one put code to initialize
non-DRAM related aspects of northbridge?

Thanks
Keith
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20100307/fb7fd292/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: raminit.c
Type: application/octet-stream
Size: 32415 bytes
Desc: not available
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20100307/fb7fd292/attachment.obj>

From Zheng.Bao at amd.com  Mon Mar  8 09:20:27 2010
From: Zheng.Bao at amd.com (Bao, Zheng)
Date: Mon, 8 Mar 2010 16:20:27 +0800
Subject: [coreboot] [PATCH] sb600: new way to load initial verb
In-Reply-To: <4B910F27.7030903@gmx.net>
References: <DD1CC71B621B004FA76856E5129D6B17038260ED@sbjgexmb1.amd.com><4B90D94E.5000007@coresystems.de>
	<4B910F27.7030903@gmx.net>
Message-ID: <DD1CC71B621B004FA76856E5129D6B170382637F@sbjgexmb1.amd.com>


The original way to load initial verb is quite inflexible.
The format of the command is:
CAd 31:28 - codec address
NID 27:20 - Nid
Verb 19:0 - Verb data
Each Nid has 4 byte data to write. It has to write one at a time.
	0x01471c10,      //1st byte 10
	0x01471d40,      //2nd byte 40
	0x01471e01,      //3rd byte 01
	0x01471f01,      //4th byte 01

The new code in sb600_hda.c and the code structure are quite
preliminary.  When it is almost done and can satisfy everybody, We can
define the pin configuration code at mainboard.
 #define CODEC_PIN_CONFIG_FILE "codec/alc_882.h"
or
 config CODEC_PIN_CONFIG_FILE
	string
	default "codec/alc_882.h"
	depends on BOARD_AMD_DBM690T

Now I am wondering if it is legal provide the intial pin configuration
code in coreboot. If it is legal, how can we get it? The 882 code is
got from CIM.

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

Index: src/codec/alc_882.h
===================================================================
--- src/codec/alc_882.h	(revision 0)
+++ src/codec/alc_882.h	(revision 0)
@@ -0,0 +1,12 @@
+	{0x14, 0x01014010},
+	{0x15, 0x01011012},
+	{0x16, 0x01016011},
+	{0x17, 0x01012014},
+	{0x18, 0x01A19030},
+	{0x19, 0x411111F0},
+	{0x1a, 0x01813080},
+	{0x1b, 0x411111F0},
+	{0x1C, 0x411111F0},
+	{0x1d, 0x411111F0},
+	{0x1e, 0x01441150},
+	{0x1f, 0x01C46160},
Index: src/southbridge/amd/sb600/sb600_hda.c
===================================================================
--- src/southbridge/amd/sb600/sb600_hda.c	(revision 5195)
+++ src/southbridge/amd/sb600/sb600_hda.c	(working copy)
@@ -90,68 +90,19 @@
 	return 0;
 }
 
-static u32 cim_verb_data[] = {
-	0x01471c10,
-	0x01471d40,
-	0x01471e01,
-	0x01471f01,
-/* 1 */
-	0x01571c12,
-	0x01571d10,
-	0x01571e01,
-	0x01571f01,
-/* 2 */
-	0x01671c11,
-	0x01671d60,
-	0x01671e01,
-	0x01671f01,
-/* 3 */
-	0x01771c14,
-	0x01771d20,
-	0x01771e01,
-	0x01771f01,
-/* 4 */
-	0x01871c30,
-	0x01871d90,
-	0x01871ea1,
-	0x01871f01,
-/* 5 */
-	0x01971cf0,
-	0x01971d11,
-	0x01971e11,
-	0x01971f41,
-/* 6 */
-	0x01a71c80,
-	0x01a71d30,
-	0x01a71e81,
-	0x01a71f01,
-/* 7 */
-	0x01b71cf0,
-	0x01b71d11,
-	0x01b71e11,
-	0x01b71f41,
-/* 8 */
-	0x01c71cf0,
-	0x01c71d11,
-	0x01c71e11,
-	0x01c71f41,
-/* 9 */
-	0x01d71cf0,
-	0x01d71d11,
-	0x01d71e11,
-	0x01d71f41,
-/* 10 */
-	0x01e71c50,
-	0x01e71d11,
-	0x01e71e44,
-	0x01e71f01,
-/* 11 */
-	0x01f71c60,
-	0x01f71d61,
-	0x01f71ec4,
-	0x01f71f01,
+typedef struct _pin_config_codec_entry {
+	u8	nid;
+	u32	pin_config;
+} pin_config_codec_entry;
+
+static pin_config_codec_entry pin_config_file[] = {
+#ifdef	CODEC_PIN_CONFIG_FILE
+	#include CODEC_PIN_CONFIG_FILE
+#endif
+	{-1, -1}
 };
-static u32 find_verb(u32 viddid, u32 ** verb)
+
+static void find_verb(u32 viddid, pin_config_codec_entry ** verb)
 {
 	device_t azalia_dev = dev_find_slot(0, PCI_DEVFN(0x14, 2));
 	struct southbridge_amd_sb600_config *cfg =
@@ -159,12 +110,13 @@
 	printk_debug("Dev=%s\n", dev_path(azalia_dev));
 	printk_debug("Default viddid=%x\n", cfg->hda_viddid);
 	printk_debug("Reading viddid=%x\n", viddid);
+
+	*verb = NULL;
 	if (!cfg)
-		return 0;
+		return;
 	if (viddid != cfg->hda_viddid)
-		return 0;
-	*verb = (u32 *) cim_verb_data;
-	return sizeof(cim_verb_data) / sizeof(u32);
+		return;
+	*verb = pin_config_file;
 }
 
 /**
@@ -214,9 +166,8 @@
 
 static void codec_init(u8 * base, int addr)
 {
-	u32 dword;
-	u32 *verb;
-	u32 verb_size;
+	u32 dword, dword1, pin_config;
+	pin_config_codec_entry *verb=NULL;
 	int i;
 
 	/* 1 */
@@ -233,23 +184,32 @@
 
 	/* 2 */
 	printk_debug("codec viddid: %08x\n", dword);
-	verb_size = find_verb(dword, &verb);
+	find_verb(dword, &verb);
 
-	if (!verb_size) {
+	if (verb == NULL) {
 		printk_debug("No verb!\n");
 		return;
 	}
 
-	printk_debug("verb_size: %d\n", verb_size);
 	/* 3 */
-	for (i = 0; i < verb_size; i++) {
-		if (wait_for_ready(base) == -1)
-			return;
+	for (verb; verb->nid != 0xFF; verb++) {
+		dword = addr << 28 | verb->nid << 20 | 7 << 16;
+		pin_config = verb->pin_config;
 
-		write32(base + 0x60, verb[i]);
+		for (i = 4; i > 0; i--, pin_config >>= 8) {
+			if (wait_for_ready(base) == -1)
+				return;
 
-		if (wait_for_valid(base) == -1)
-			return;
+			if (verb->nid != 1)
+				dword1 = dword | ((0x20 - i) & 0xFF) <<
8;
+			else
+				dword1 = dword | ((0x24 - i) & 0xFF) <<
8;
+			dword1 |= (pin_config & 0xFF);
+			write32(base + 0x60, dword1);
+
+			if (wait_for_valid(base) == -1)
+				return;
+		}
 	}
 	printk_debug("verb loaded!\n");
 }



-----Original Message-----
From: coreboot-bounces at coreboot.org
[mailto:coreboot-bounces at coreboot.org] On Behalf Of Carl-Daniel
Hailfinger
Sent: Friday, March 05, 2010 10:03 PM
To: Stefan Reinauer
Cc: coreboot at coreboot.org
Subject: Re: [coreboot] [PATCH] sb600: don't load verb for codec

On 05.03.2010 11:13, Stefan Reinauer wrote:
> On 3/5/10 10:29 AM, Bao, Zheng wrote:
>   
>> Don't load verb in BIOS stage. It is not BIOS's responsibility.
>>   
>>     
> Who is responsible for that, then?
>  
> On i945 I definitely don't get sound on most systems if I don't load
the
> verb in coreboot. I also don't think the Linux drivers do it.
>   
>> And we can not have verb for every single codec.
>>   
>>     
> Have a look at the i82801gx southbridge; I think it was based on the
> sb600 code, but I changed it so I can have a per mainboard verb table.
>   

I think we should try to mirror the behaviour of the vendor BIOS. The
Linux kernel source has some interesting info about HD Audio:
http://www.mjmwired.net/kernel/Documentation/sound/alsa/HD-Audio.txt

Regards,
Carl-Daniel

-- 
"I do consider assignment statements and pointer variables to be among
computer science's most valuable treasures."
-- Donald E. Knuth


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

-------------- next part --------------
A non-text attachment was scrubbed...
Name: sb600_load_verb_new.patch
Type: application/octet-stream
Size: 4448 bytes
Desc: sb600_load_verb_new.patch
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20100308/36c77d15/attachment.obj>

From knuku at gap.upv.es  Mon Mar  8 12:46:12 2010
From: knuku at gap.upv.es (Knut Kujat)
Date: Mon, 08 Mar 2010 12:46:12 +0100
Subject: [coreboot] Supermicro H8QME-2+ mct_d fatal exit.
In-Reply-To: <13426df11003051007r29fee819p2fdea852891a4b58@mail.gmail.com>
References: <4B87CF9D.9060204@gap.upv.es>	<201002261506.46602.christian.leber@ziti.uni-heidelberg.de>	<4B87DEFE.3010604@gap.upv.es>
	<20100226154934.5727.qmail@stuge.se>	<4B8BC18D.1050400@gap.upv.es>
	<4B8FC877.4030209@gap.upv.es>	<4B91295B.9060102@assembler.cz>
	<4B912FE4.7080204@gap.upv.es>	<4B913A01.4090103@assembler.cz>
	<13426df11003051007r29fee819p2fdea852891a4b58@mail.gmail.com>
Message-ID: <4B94E384.4060002@gap.upv.es>

Hello,

thx all of you for your comments. Here a little update :)

I now know why the boards worked just fine up here in my lab. To know if
the board would work after being unplugged I always "only" unplugged the
electrical cable but never the monitor attached to the board I figured
out that the monitor is providing enough juice to maintain whatever
alive in the board so after plugging the electrical cable on again
coreboot started fine. Another thing I figured out is that it seems that
the front leds of the board a managed by GPIO as well, is this right? If
so it seems that something is wrong with GPIO because the power on led
never works with coreboot.

thx,
Knut Kujat.



ron minnich escribi?:
> Just FYI:
>
> on our first system with Arima boards in 2002, everything worked well
> until we started booting 64-bit kernels. I'm not kidding. We did not
> find the SMBUS MUX on the boards until we had unreliable coreboot
> boots of 64-bit kernels. For quite some time the boards worked fine.
> Ollie found the SMBUS MUX by examining schematics.
>
> So the SMBUS mux can appear in strange ways, at strange times. This
> sounds like one of those times. SMBUS muxes are more common than you
> might think and the default power-on state is not always very well
> determined.
>
> ron
>
>   




From Mathias.Krause at secunet.com  Mon Mar  8 13:31:21 2010
From: Mathias.Krause at secunet.com (Mathias Krause)
Date: Mon, 08 Mar 2010 13:31:21 +0100
Subject: [coreboot] [PATCH] libpayload: Use correct define for VGA console
	support
Message-ID: <4B94EE19.9090002@secunet.com>

This code was using the wrong preprocessor define, too.

Greets,
Mathias
-------------- next part --------------
A non-text attachment was scrubbed...
Name: vga_console.diff
Type: application/pgp-keys
Size: 410 bytes
Desc: not available
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20100308/a2c7948b/attachment.skr>

From Mathias.Krause at secunet.com  Mon Mar  8 13:25:18 2010
From: Mathias.Krause at secunet.com (Mathias Krause)
Date: Mon, 08 Mar 2010 13:25:18 +0100
Subject: [coreboot] [PATCH] FILO: Fix VGA cursor position with VGA console
Message-ID: <4B94ECAE.3090904@secunet.com>

The attached patch fixes the VGA cursor position when booting a Linux
kernel. The code was using the wrong preprocessor define.

Greets,
Mathias
-------------- next part --------------
A non-text attachment was scrubbed...
Name: vga_cursor_pos.diff
Type: application/pgp-keys
Size: 1164 bytes
Desc: not available
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20100308/cdfedcf0/attachment.skr>

From svn at coreboot.org  Mon Mar  8 14:08:24 2010
From: svn at coreboot.org (repository service)
Date: Mon, 08 Mar 2010 14:08:24 +0100
Subject: [coreboot] [commit] r5196 - trunk/payloads/libpayload/curses
Message-ID: <E1Noch6-00051g-JW@ra.coresystems.de>

Author: stepan
Date: Mon Mar  8 14:08:24 2010
New Revision: 5196
URL: http://tracker.coreboot.org/trac/coreboot/changeset/5196

Log:
Trivial fix, use correct define.

Signed-off-by: Mathias Krause <Mathias.Krause at secunet.com>
Acked-by: Stefan Reinauer <stepan at coresystems.de>

Modified:
   trunk/payloads/libpayload/curses/keyboard.c

Modified: trunk/payloads/libpayload/curses/keyboard.c
==============================================================================
--- trunk/payloads/libpayload/curses/keyboard.c	Sat Mar  6 22:18:43 2010	(r5195)
+++ trunk/payloads/libpayload/curses/keyboard.c	Mon Mar  8 14:08:24 2010	(r5196)
@@ -225,7 +225,7 @@
 	return 0;
 }
 
-#ifdef CONFIG_VGA_CONSOLE
+#ifdef CONFIG_VGA_VIDEO_CONSOLE
 void curses_enable_vga(int state)
 {
 	if (state)



From svn at coreboot.org  Mon Mar  8 14:09:45 2010
From: svn at coreboot.org (repository service)
Date: Mon, 08 Mar 2010 14:09:45 +0100
Subject: [coreboot] [FILO] r108 - trunk/filo/i386
Message-ID: <E1NociP-0007b4-OH@ra.coresystems.de>

Author: stepan
Date: Mon Mar  8 14:09:45 2010
New Revision: 108
URL: http://tracker.coreboot.org/trac/filo/changeset/108

Log:
Set current cursor position in kernel header when VGA support was compiled
into libpayload so the kernel starts outputting it's messages at the right
position. The old code was actually working, but using the wrong
preprocessor define.

Signed-off-by: Mathias Krause <Mathias.Krause at secunet.com>
Acked-by: Stefan Reinauer <stepan at coresystems.de>

Modified:
   trunk/filo/i386/linux_load.c

Modified: trunk/filo/i386/linux_load.c
==============================================================================
--- trunk/filo/i386/linux_load.c	Tue Oct  6 05:10:00 2009	(r107)
+++ trunk/filo/i386/linux_load.c	Mon Mar  8 14:09:45 2010	(r108)
@@ -26,6 +26,7 @@
  */
 
 #include <libpayload.h>
+#include <libpayload-config.h>
 #include <config.h>
 #include <fs.h>
 #include "context.h"
@@ -585,7 +586,7 @@
 {
     struct segment_desc *linux_gdt;
     struct context *ctx;
-#ifdef CONFIG_VGA_CONSOLE
+#ifdef CONFIG_VGA_VIDEO_CONSOLE
     unsigned int cursor_x, cursor_y, cursor_en;
 #endif
 #ifdef CONFIG_PCMCIA_CF
@@ -625,7 +626,7 @@
     debug("eip=%#x\n", kern_addr);
     printf("Jumping to entry point...\n");
 
-#ifdef CONFIG_VGA_CONSOLE
+#ifdef CONFIG_VGA_VIDEO_CONSOLE
     /* Update VGA cursor position.
      * This must be here because the printf changes the value! */
     video_console_get_cursor(&cursor_x, &cursor_y, &cursor_en);



From stepan at coresystems.de  Mon Mar  8 14:10:24 2010
From: stepan at coresystems.de (Stefan Reinauer)
Date: Mon, 08 Mar 2010 14:10:24 +0100
Subject: [coreboot] [PATCH] FILO: Fix VGA cursor position with VGA
	console
In-Reply-To: <4B94ECAE.3090904@secunet.com>
References: <4B94ECAE.3090904@secunet.com>
Message-ID: <4B94F740.1050905@coresystems.de>

On 3/8/10 1:25 PM, Mathias Krause wrote:
> The attached patch fixes the VGA cursor position when booting a Linux
> kernel. The code was using the wrong preprocessor define.
>   
Thanks a lot!

r5196

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




From stepan at coresystems.de  Mon Mar  8 14:14:03 2010
From: stepan at coresystems.de (Stefan Reinauer)
Date: Mon, 08 Mar 2010 14:14:03 +0100
Subject: [coreboot] [PATCH] FILO: Fix VGA cursor position with
	VGA	console
In-Reply-To: <4B94F740.1050905@coresystems.de>
References: <4B94ECAE.3090904@secunet.com> <4B94F740.1050905@coresystems.de>
Message-ID: <4B94F81B.2030809@coresystems.de>

On 3/8/10 2:10 PM, Stefan Reinauer wrote:
> On 3/8/10 1:25 PM, Mathias Krause wrote:
>   
>> The attached patch fixes the VGA cursor position when booting a Linux
>> kernel. The code was using the wrong preprocessor define.
>>   
>>     
> Thanks a lot!
>
> r5196
>   
in libpayload and r108 in FILO.


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




From c-d.hailfinger.devel.2006 at gmx.net  Mon Mar  8 15:14:57 2010
From: c-d.hailfinger.devel.2006 at gmx.net (Carl-Daniel Hailfinger)
Date: Mon, 08 Mar 2010 15:14:57 +0100
Subject: [coreboot] [PATCH] sb600: new way to load initial verb
In-Reply-To: <DD1CC71B621B004FA76856E5129D6B170382637F@sbjgexmb1.amd.com>
References: <DD1CC71B621B004FA76856E5129D6B17038260ED@sbjgexmb1.amd.com><4B90D94E.5000007@coresystems.de>	<4B910F27.7030903@gmx.net>
	<DD1CC71B621B004FA76856E5129D6B170382637F@sbjgexmb1.amd.com>
Message-ID: <4B950661.5060905@gmx.net>

On 08.03.2010 09:20, Bao, Zheng wrote:
> The original way to load initial verb is quite inflexible.
> The format of the command is:
> CAd 31:28 - codec address
> NID 27:20 - Nid
> Verb 19:0 - Verb data
> Each Nid has 4 byte data to write. It has to write one at a time.
> 	0x01471c10,      //1st byte 10
> 	0x01471d40,      //2nd byte 40
> 	0x01471e01,      //3rd byte 01
> 	0x01471f01,      //4th byte 01
>
> The new code in sb600_hda.c and the code structure are quite
> preliminary.  When it is almost done and can satisfy everybody, We can
> define the pin configuration code at mainboard.
>   

It would be cool if all chipsets could use the new verb implementation.


>  #define CODEC_PIN_CONFIG_FILE "codec/alc_882.h"
> or
>  config CODEC_PIN_CONFIG_FILE
> 	string
> 	default "codec/alc_882.h"
> 	depends on BOARD_AMD_DBM690T
>   

Or we define that file as separate uncompressed CBFS file.


> Now I am wondering if it is legal provide the intial pin configuration
> code in coreboot. If it is legal, how can we get it? The 882 code is
> got from CIM.
>   

Sorry, what is CIM?
In theory, the pin configuration is mainboard specific. If that is true,
the pin configuration is similar to IRQ routing: There is usually only
one correct and working solution. So it is possible that the mainboard
vendor and the codec vendor own parts of it. Not sure. We could tell
users to dump verbs from their mainboards (is that possible?) and add
the resulting file to CBFS.


> Signed-off-by: Zheng Bao <zheng.bao at amd.com>
>
> Index: src/codec/alc_882.h
> ===================================================================
> --- src/codec/alc_882.h	(revision 0)
> +++ src/codec/alc_882.h	(revision 0)
> @@ -0,0 +1,12 @@
>   

struct _pin_config_codec_entry pin_config_file[] = {

> +	{0x14, 0x01014010},
> +	{0x15, 0x01011012},
> +	{0x16, 0x01016011},
> +	{0x17, 0x01012014},
> +	{0x18, 0x01A19030},
> +	{0x19, 0x411111F0},
> +	{0x1a, 0x01813080},
> +	{0x1b, 0x411111F0},
> +	{0x1C, 0x411111F0},
> +	{0x1d, 0x411111F0},
> +	{0x1e, 0x01441150},
> +	{0x1f, 0x01C46160},
>   

{-1, -1}
};


> Index: src/southbridge/amd/sb600/sb600_hda.c
> ===================================================================
> --- src/southbridge/amd/sb600/sb600_hda.c	(revision 5195)
> +++ src/southbridge/amd/sb600/sb600_hda.c	(working copy)
> @@ -90,68 +90,19 @@
>  	return 0;
>  }
>  
> -static u32 cim_verb_data[] = {
> -	0x01471c10,
> -	0x01471d40,
> -	0x01471e01,
> -	0x01471f01,
> -/* 1 */
> -	0x01571c12,
> -	0x01571d10,
> -	0x01571e01,
> -	0x01571f01,
> -/* 2 */
> -	0x01671c11,
> -	0x01671d60,
> -	0x01671e01,
> -	0x01671f01,
> -/* 3 */
> -	0x01771c14,
> -	0x01771d20,
> -	0x01771e01,
> -	0x01771f01,
> -/* 4 */
> -	0x01871c30,
> -	0x01871d90,
> -	0x01871ea1,
> -	0x01871f01,
> -/* 5 */
> -	0x01971cf0,
> -	0x01971d11,
> -	0x01971e11,
> -	0x01971f41,
> -/* 6 */
> -	0x01a71c80,
> -	0x01a71d30,
> -	0x01a71e81,
> -	0x01a71f01,
> -/* 7 */
> -	0x01b71cf0,
> -	0x01b71d11,
> -	0x01b71e11,
> -	0x01b71f41,
> -/* 8 */
> -	0x01c71cf0,
> -	0x01c71d11,
> -	0x01c71e11,
> -	0x01c71f41,
> -/* 9 */
> -	0x01d71cf0,
> -	0x01d71d11,
> -	0x01d71e11,
> -	0x01d71f41,
> -/* 10 */
> -	0x01e71c50,
> -	0x01e71d11,
> -	0x01e71e44,
> -	0x01e71f01,
> -/* 11 */
> -	0x01f71c60,
> -	0x01f71d61,
> -	0x01f71ec4,
> -	0x01f71f01,
> +typedef struct _pin_config_codec_entry {
>   

Can you please kill the typedef and use "struct _pin_config_codec_entry"
instead?


> +	u8	nid;
> +	u32	pin_config;
> +} pin_config_codec_entry;
> +
> +static pin_config_codec_entry pin_config_file[] = {
> +#ifdef	CODEC_PIN_CONFIG_FILE
> +	#include CODEC_PIN_CONFIG_FILE
>   

Including C source makes code difficult to read. Can you move the
complete struct to alc_882.h?

Hm. Could we simply store the whole verb stuff uncompressed inside CBFS?


> +#endif
> +	{-1, -1}
>  };
> -static u32 find_verb(u32 viddid, u32 ** verb)
> +
> +static void find_verb(u32 viddid, pin_config_codec_entry ** verb)
>  {
>  	device_t azalia_dev = dev_find_slot(0, PCI_DEVFN(0x14, 2));
>  	struct southbridge_amd_sb600_config *cfg =
> @@ -159,12 +110,13 @@
>  	printk_debug("Dev=%s\n", dev_path(azalia_dev));
>  	printk_debug("Default viddid=%x\n", cfg->hda_viddid);
>  	printk_debug("Reading viddid=%x\n", viddid);
> +
> +	*verb = NULL;
>  	if (!cfg)
> -		return 0;
> +		return;
>  	if (viddid != cfg->hda_viddid)
> -		return 0;
> -	*verb = (u32 *) cim_verb_data;
> -	return sizeof(cim_verb_data) / sizeof(u32);
> +		return;
> +	*verb = pin_config_file;
>  }
>  
>  /**
> @@ -214,9 +166,8 @@
>  
>  static void codec_init(u8 * base, int addr)
>  {
> -	u32 dword;
> -	u32 *verb;
> -	u32 verb_size;
> +	u32 dword, dword1, pin_config;
> +	pin_config_codec_entry *verb=NULL;
>  	int i;
>  
>  	/* 1 */
> @@ -233,23 +184,32 @@
>  
>  	/* 2 */
>  	printk_debug("codec viddid: %08x\n", dword);
> -	verb_size = find_verb(dword, &verb);
> +	find_verb(dword, &verb);
>  
> -	if (!verb_size) {
> +	if (verb == NULL) {
>  		printk_debug("No verb!\n");
>  		return;
>  	}
>  
> -	printk_debug("verb_size: %d\n", verb_size);
>  	/* 3 */
> -	for (i = 0; i < verb_size; i++) {
> -		if (wait_for_ready(base) == -1)
> -			return;
> +	for (verb; verb->nid != 0xFF; verb++) {
> +		dword = addr << 28 | verb->nid << 20 | 7 << 16;
> +		pin_config = verb->pin_config;
>  
> -		write32(base + 0x60, verb[i]);
> +		for (i = 4; i > 0; i--, pin_config >>= 8) {
> +			if (wait_for_ready(base) == -1)
> +				return;
>  
> -		if (wait_for_valid(base) == -1)
> -			return;
> +			if (verb->nid != 1)
> +				dword1 = dword | ((0x20 - i) & 0xFF) << 8;
> +			else
> +				dword1 = dword | ((0x24 - i) & 0xFF) << 8;
> +			dword1 |= (pin_config & 0xFF);
> +			write32(base + 0x60, dword1);
> +
> +			if (wait_for_valid(base) == -1)
> +				return;
> +		}
>  	}
>  	printk_debug("verb loaded!\n");
>  }
>   

Looks good.

Regards,
Carl-Daniel

-- 
"I do consider assignment statements and pointer variables to be among
computer science's most valuable treasures."
-- Donald E. Knuth




From c-d.hailfinger.devel.2006 at gmx.net  Mon Mar  8 16:59:14 2010
From: c-d.hailfinger.devel.2006 at gmx.net (Carl-Daniel Hailfinger)
Date: Mon, 08 Mar 2010 16:59:14 +0100
Subject: [coreboot] GSoC 2010
In-Reply-To: <4B92D9A4.8080909@coresystems.de>
References: <4B8FD7F7.7090307@gmx.net>	<534e5dc21003040917u37e5ea7ek5d29f4b73b8dc445@mail.gmail.com>	<46893e741003060029v13d8af42xde7da120e0ebee1@mail.gmail.com>	<df1430311003060103w22137aa9w7e43e1dd64977654@mail.gmail.com>	<4B925C5D.1040609@gmx.net>
	<4B926BB1.4080601@gmx.net>	<D2B8891A-FEBE-4A46-80BD-A292E109662D@coresystems.de>	<49f8af42eac1e221bca5af3b9e97b052@imap.1and1.com>	<4B927F35.3060500@gmx.net>
	<4B9295CD.80002@coresystems.de> <4B929E48.1090908@gmx.net>
	<4B92D9A4.8080909@coresystems.de>
Message-ID: <4B951ED2.7010909@gmx.net>

[Fullquote because it seems Stefan's mail mail did not end up on the
list by accident.]

On 06.03.2010 23:39, Stefan Reinauer wrote:
> On 3/6/10 7:26 PM, Carl-Daniel Hailfinger wrote:
>   
>>> Just having it as a FILO add-on would be the best solution. Then it can
>>> use all the FILO infrastructure (reading lots of filesystems, using a
>>> recovery with a nice menu on a USB stick, 
>>>     
>>>       
>> OTOH, it could simply be an ELF loaded by FILO. That allows upgrades of
>> flashrom as needed, and if FILO can load flash images from any media, it
>> should be able to do the same with executable code.
>>   
>>     
> Unless FILO gets a full blown linker, that ELF file would need a full
> blown VFS, IDE driver, FS drivers, USB stack, ....
>
> But yes, maybe doing run time linking at firmware time is what we want
> to do, after all...
>   

Assuming the addresses of symbols in FILO/libpayload are known at
compile/link (well, prelink) time of flashrom, it should be possible to
offer prelinked ELF files to FILO without needing any linker in FILO.
This would be similar to the linking of initram and stage2 in coreboot v3.
Or we make sure FILO is able to write out a symbol table over serial or
to disk. That symbol table can then be used by a linker on another
machine to link flashrom, and then a linked flashrom can be supplied to
FILO.
I could try to dig up my symbol-table-in-LAR patches for v3.

That's surely an interesting project regardless of how we implement it.

Regards,
Carl-Daniel

-- 
"I do consider assignment statements and pointer variables to be among
computer science's most valuable treasures."
-- Donald E. Knuth




From rminnich at gmail.com  Mon Mar  8 17:35:12 2010
From: rminnich at gmail.com (ron minnich)
Date: Mon, 8 Mar 2010 08:35:12 -0800
Subject: [coreboot] GSoC 2010
In-Reply-To: <4B951ED2.7010909@gmx.net>
References: <4B8FD7F7.7090307@gmx.net> <4B925C5D.1040609@gmx.net>
	<4B926BB1.4080601@gmx.net>
	<D2B8891A-FEBE-4A46-80BD-A292E109662D@coresystems.de>
	<49f8af42eac1e221bca5af3b9e97b052@imap.1and1.com>
	<4B927F35.3060500@gmx.net> <4B9295CD.80002@coresystems.de>
	<4B929E48.1090908@gmx.net> <4B92D9A4.8080909@coresystems.de>
	<4B951ED2.7010909@gmx.net>
Message-ID: <13426df11003080835n673e5088k4124a4ba154e8f@mail.gmail.com>

The EFI lesson: if you're going to put an OS in FLASH, at least make
it a good one.

Otherwise, you get EFI.

Be careful where you're going here. You're starting to verge on
creating an OS. If you get that far, at least look at what's out there
before you go too much further.

ron



From ziltro at ziltro.com  Mon Mar  8 17:54:19 2010
From: ziltro at ziltro.com (Andrew Morgan)
Date: Mon, 08 Mar 2010 16:54:19 +0000
Subject: [coreboot] [PATCH] ASUS P2B-LS support, RAM detection for 440BX,
 add Slot 1 CPU, Microcode for Intel Tualatin CPUs
In-Reply-To: <201003062105.06745.christian.leber@ziti.uni-heidelberg.de>
References: <b72cdb061003022019x18ab2b0fo7de47d2d1b0f9609@mail.gmail.com>	<20100306182824.GD13408@greenwood>	<13426df11003061101ja0cd5bex9d7adad03b86f94d@mail.gmail.com>
	<201003062105.06745.christian.leber@ziti.uni-heidelberg.de>
Message-ID: <4B952BBB.4070301@ziltro.com>

On 06/03/2010 20:05, Christian Leber wrote:
> On Saturday 06 March 2010 20:01:11 ron minnich wrote:
>    
>> This activity is really impressive. It got me to wondering: how old is
>> the 440bx chipset?
>>      
> it was released in april 1998
>    

Old enough that most people would want to get rid of computers that old, 
but still new enough to be useful. (Flash not EPROM, PCI, DIMMs...) I 
have an i440BX based Soyo board which I got for free and I know that 
even if I broke it it wouldn't be a great loss, so re-programming the 
flash etc. is of no great risk. Even if I had to de-solder the flash 
chip I could use it for practice, although this board has a socket. And 
now (after surprisingly little effort on my part!) Coreboot runs on it. :)

So it is probably a good era of board for anyone wanting to get started 
with Coreboot without the risk of destroying something they care about 
or remembering how to do ISA.

-- 

Andrew.




From c-d.hailfinger.devel.2006 at gmx.net  Mon Mar  8 17:59:00 2010
From: c-d.hailfinger.devel.2006 at gmx.net (Carl-Daniel Hailfinger)
Date: Mon, 08 Mar 2010 17:59:00 +0100
Subject: [coreboot] GSoC 2010
In-Reply-To: <13426df11003080835n673e5088k4124a4ba154e8f@mail.gmail.com>
References: <4B8FD7F7.7090307@gmx.net>
	<4B925C5D.1040609@gmx.net>	<4B926BB1.4080601@gmx.net>	<D2B8891A-FEBE-4A46-80BD-A292E109662D@coresystems.de>	<49f8af42eac1e221bca5af3b9e97b052@imap.1and1.com>	<4B927F35.3060500@gmx.net>
	<4B9295CD.80002@coresystems.de>	<4B929E48.1090908@gmx.net>
	<4B92D9A4.8080909@coresystems.de>	<4B951ED2.7010909@gmx.net>
	<13426df11003080835n673e5088k4124a4ba154e8f@mail.gmail.com>
Message-ID: <4B952CD4.4030106@gmx.net>

On 08.03.2010 17:35, ron minnich wrote:
> The EFI lesson: if you're going to put an OS in FLASH, at least make
> it a good one.
>
> Otherwise, you get EFI.
>   

Great quote. May I use that as new signature?


> Be careful where you're going here. You're starting to verge on
> creating an OS. If you get that far, at least look at what's out there
> before you go too much further.
>   

In my very humble opinion, a complete flashrom in flash is not a
desirable idea with today's flash sizes and the other restrictions
associated with flashing.
Either you can load flash images from disk/whatever, and then it should
be possible to boot an OS which can run flashrom.
Or you can't load flash images from disk/whatever, and then flashrom in
flash has nothing to flash.

I do care about good design, but if an employer tells me to use a design
I disagree with, I won't refuse to use that design. If this becomes a
GSoC project, the success of the student (me?) essentially depends on
what the mentor thinks is good, so the situation is similar to a workplace.

Some people want an all-singing, all-dancing BIOS/bootloader with BIOS
settings screen, flashrom, a splash screen video, maybe a builtin game
and a disk formatter. If you can thow in a web browser (based on any
personal favourite self-written incomplete closed source
not-an-operating-system (you know which one I mean)), even better. Throw
in some fan control scripts which can make the fans sing and let useful
LEDs on the board blink in patterns synchronized to the music.
A sizable part of the overclocking/modding crowd will _love_ such a
thing regardless of technical merits because it is "cool" and perfect
for bragging.

Regards,
Carl-Daniel

-- 
"I do consider assignment statements and pointer variables to be among
computer science's most valuable treasures."
-- Donald E. Knuth




From mylesgw at gmail.com  Mon Mar  8 18:21:16 2010
From: mylesgw at gmail.com (Myles Watson)
Date: Mon, 8 Mar 2010 10:21:16 -0700
Subject: [coreboot] GSoC 2010
In-Reply-To: <13426df11003080835n673e5088k4124a4ba154e8f@mail.gmail.com>
References: <4B8FD7F7.7090307@gmx.net> <4B926BB1.4080601@gmx.net>
	<D2B8891A-FEBE-4A46-80BD-A292E109662D@coresystems.de>
	<49f8af42eac1e221bca5af3b9e97b052@imap.1and1.com>
	<4B927F35.3060500@gmx.net> <4B9295CD.80002@coresystems.de>
	<4B929E48.1090908@gmx.net> <4B92D9A4.8080909@coresystems.de>
	<4B951ED2.7010909@gmx.net>
	<13426df11003080835n673e5088k4124a4ba154e8f@mail.gmail.com>
Message-ID: <2831fecf1003080921g4411928du2ef2c2d8453203eb@mail.gmail.com>

On Mon, Mar 8, 2010 at 9:35 AM, ron minnich <rminnich at gmail.com> wrote:

> The EFI lesson: if you're going to put an OS in FLASH, at least make
> it a good one.
>
> Otherwise, you get EFI.
>
> Be careful where you're going here. You're starting to verge on
> creating an OS. If you get that far, at least look at what's out there
> before you go too much further.
>
I may have missed too much of this thread, but I thought it started out as a
"recovery" method.  If it doesn't work well enough to load Linux, why could
it load other things?

I thought the point was that you want to be able to recover when only serial
works.  Lots of things can fail between then and loading a payload.

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

From kh.nirschl at googlemail.com  Mon Mar  8 18:36:48 2010
From: kh.nirschl at googlemail.com (Karl-Heinz Nirschl)
Date: Mon, 8 Mar 2010 18:36:48 +0100
Subject: [coreboot] Getting started with Coreboot on Intel Core
In-Reply-To: <f7bea4a91003080931q241d05edtd2b8d03bf5a3831c@mail.gmail.com>
References: <f7bea4a91003080931q241d05edtd2b8d03bf5a3831c@mail.gmail.com>
Message-ID: <f7bea4a91003080936w69638e59m90035367161885d1@mail.gmail.com>

Hi,

i should append:

this is using a spi flash with 2 Megs and todays svn version.
i also tried with a 1 meg fhw with a somewhat earlier version of
coreboot. same problem.


regards,

karl



2010/3/8 Karl-Heinz Nirschl <kh.nirschl at googlemail.com>:
> Hi there,
>
> i'm new to coreboot and trying to port coreboot to a intel core based
> board. it's a u2500 with a ich7m and 945gm.
> i started with kontron 986lcd-m which should be quite similar but
> didn't have much success so far.
>
> the board hangs with post code 0x23 (pci post card) which is bevor
> "call ? stage1_main" in model_6ex/cache_as_ram.inc.
>
> as this is very early and the cpu never seem to come to stage1_main
> (in cache_as_ram_disable.c) i assume i have a problem with my
> toolchain.
>
> I build on ubuntu 8.04 (Hardy Heron) with nothing special.
>
> Any hints for a coreboot newbie? Which additional information could i
> provide to find the problem?
>
>
> Best Regards,
>
> karl
>



From kh.nirschl at googlemail.com  Mon Mar  8 18:31:25 2010
From: kh.nirschl at googlemail.com (Karl-Heinz Nirschl)
Date: Mon, 8 Mar 2010 18:31:25 +0100
Subject: [coreboot] Getting started with Coreboot on Intel Core
Message-ID: <f7bea4a91003080931q241d05edtd2b8d03bf5a3831c@mail.gmail.com>

Hi there,

i'm new to coreboot and trying to port coreboot to a intel core based
board. it's a u2500 with a ich7m and 945gm.
i started with kontron 986lcd-m which should be quite similar but
didn't have much success so far.

the board hangs with post code 0x23 (pci post card) which is bevor
"call	stage1_main" in model_6ex/cache_as_ram.inc.

as this is very early and the cpu never seem to come to stage1_main
(in cache_as_ram_disable.c) i assume i have a problem with my
toolchain.

I build on ubuntu 8.04 (Hardy Heron) with nothing special.

Any hints for a coreboot newbie? Which additional information could i
provide to find the problem?


Best Regards,

karl



From stepan at coresystems.de  Mon Mar  8 19:38:51 2010
From: stepan at coresystems.de (Stefan Reinauer)
Date: Mon, 08 Mar 2010 19:38:51 +0100
Subject: [coreboot] Getting started with Coreboot on Intel Core
In-Reply-To: <f7bea4a91003080936w69638e59m90035367161885d1@mail.gmail.com>
References: <f7bea4a91003080931q241d05edtd2b8d03bf5a3831c@mail.gmail.com>
	<f7bea4a91003080936w69638e59m90035367161885d1@mail.gmail.com>
Message-ID: <4B95443B.3050501@coresystems.de>

On 3/8/10 6:36 PM, Karl-Heinz Nirschl wrote:
> Hi,
>
> i should append:
>
> this is using a spi flash with 2 Megs and todays svn version.
> i also tried with a 1 meg fhw with a somewhat earlier version of
> coreboot. same problem.
>
>
> regards,
>
> karl
>
>
>
> 2010/3/8 Karl-Heinz Nirschl <kh.nirschl at googlemail.com>:
>   
>> Hi there,
>>
>> i'm new to coreboot and trying to port coreboot to a intel core based
>> board. it's a u2500 with a ich7m and 945gm.
>> i started with kontron 986lcd-m which should be quite similar but
>> didn't have much success so far.
>>     
Did you adapt the code for your SuperIO chip? Do you get any messages on
the serial port?

>> the board hangs with post code 0x23 (pci post card) which is bevor
>> "call   stage1_main" in model_6ex/cache_as_ram.inc.
>>
>> as this is very early and the cpu never seem to come to stage1_main
>> (in cache_as_ram_disable.c) i assume i have a problem with my
>> toolchain.
>>     

Try this one:

Index: src/northbridge/intel/i945/early_init.c
===================================================================
--- src/northbridge/intel/i945/early_init.c (revision 5196)
+++ src/northbridge/intel/i945/early_init.c (working copy)
@@ -867,7 +867,7 @@
i945_setup_bars();

/* Change port80 to LPC */
- RCBA32(GCS) &= (~0x04);
+ //RCBA32(GCS) &= (~0x04);

/* Just do it that way */
RCBA32(0x2010) |= (1 << 10);

Then post codes keep going to PCI instead of LPC and you should see
where it's going.





>> I build on ubuntu 8.04 (Hardy Heron) with nothing special.
>>
>> Any hints for a coreboot newbie? Which additional information could i
>> provide to find the problem?
>>     

You should use the reference toolchain in util/crossgcc


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




From stepan at coresystems.de  Mon Mar  8 19:43:16 2010
From: stepan at coresystems.de (Stefan Reinauer)
Date: Mon, 08 Mar 2010 19:43:16 +0100
Subject: [coreboot] GSoC 2010
In-Reply-To: <2831fecf1003080921g4411928du2ef2c2d8453203eb@mail.gmail.com>
References: <4B8FD7F7.7090307@gmx.net>
	<4B926BB1.4080601@gmx.net>	<D2B8891A-FEBE-4A46-80BD-A292E109662D@coresystems.de>	<49f8af42eac1e221bca5af3b9e97b052@imap.1and1.com>	<4B927F35.3060500@gmx.net>
	<4B9295CD.80002@coresystems.de>	<4B929E48.1090908@gmx.net>
	<4B92D9A4.8080909@coresystems.de>	<4B951ED2.7010909@gmx.net>	<13426df11003080835n673e5088k4124a4ba154e8f@mail.gmail.com>
	<2831fecf1003080921g4411928du2ef2c2d8453203eb@mail.gmail.com>
Message-ID: <4B954544.30401@coresystems.de>

On 3/8/10 6:21 PM, Myles Watson wrote:
>
>
> On Mon, Mar 8, 2010 at 9:35 AM, ron minnich <rminnich at gmail.com
> <mailto:rminnich at gmail.com>> wrote:
>
>     The EFI lesson: if you're going to put an OS in FLASH, at least make
>     it a good one.
>
>     Otherwise, you get EFI.
>
>     Be careful where you're going here. You're starting to verge on
>     creating an OS. If you get that far, at least look at what's out there
>     before you go too much further.
>

> I may have missed too much of this thread, but I thought it started
> out as a "recovery" method.  If it doesn't work well enough to load
> Linux, why could it load other things?
>
Because Linux needs a lot more stuff than anything else. APIC setup,
interrupts going, ...

> I thought the point was that you want to be able to recover when only
> serial works.  Lots of things can fail between then and loading a payload.
No, the point is really to get normal going without an OS after normal
is misflashed, with only fallback left.

If you're beyond that point you're a coreboot hacker and want a
replacement flash chip or some more convenient methods to recover anyways.

Stefan

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20100308/3093f8b3/attachment.html>

From mark.marshall at csr.com  Mon Mar  8 19:43:38 2010
From: mark.marshall at csr.com (Mark Marshall)
Date: Mon, 08 Mar 2010 18:43:38 +0000
Subject: [coreboot] [PATCH] ASUS P2B-LS support, RAM detection for 440BX,
 add Slot 1 CPU, Microcode for Intel Tualatin CPUs
In-Reply-To: <4B952BBB.4070301@ziltro.com>
References: <b72cdb061003022019x18ab2b0fo7de47d2d1b0f9609@mail.gmail.com>	<20100306182824.GD13408@greenwood>	<13426df11003061101ja0cd5bex9d7adad03b86f94d@mail.gmail.com>	<201003062105.06745.christian.leber@ziti.uni-heidelberg.de>
	<4B952BBB.4070301@ziltro.com>
Message-ID: <4B95455A.3000108@csr.com>

Andrew Morgan wrote:
> On 06/03/2010 20:05, Christian Leber wrote:
>> On Saturday 06 March 2010 20:01:11 ron minnich wrote:
>>   
>>> This activity is really impressive. It got me to wondering: how old is
>>> the 440bx chipset?
>>>      
>> it was released in april 1998
>>    
> 
> Old enough that most people would want to get rid of computers that old, 
> but still new enough to be useful. (Flash not EPROM, PCI, DIMMs...) I 
> have an i440BX based Soyo board which I got for free and I know that 
> even if I broke it it wouldn't be a great loss, so re-programming the 
> flash etc. is of no great risk. Even if I had to de-solder the flash 
> chip I could use it for practice, although this board has a socket. And 
> now (after surprisingly little effort on my part!) Coreboot runs on it. :)
> 
> So it is probably a good era of board for anyone wanting to get started 
> with Coreboot without the risk of destroying something they care about 
> or remembering how to do ISA.
> 

That's why I bought a ASUS P2B off of e-bay for ?5.  ;-)

A lot of fun for the money.

MM




From mylesgw at gmail.com  Mon Mar  8 19:53:26 2010
From: mylesgw at gmail.com (Myles Watson)
Date: Mon, 8 Mar 2010 11:53:26 -0700
Subject: [coreboot] GSoC 2010
In-Reply-To: <4B954544.30401@coresystems.de>
References: <4B8FD7F7.7090307@gmx.net>
	<49f8af42eac1e221bca5af3b9e97b052@imap.1and1.com>
	<4B927F35.3060500@gmx.net> <4B9295CD.80002@coresystems.de>
	<4B929E48.1090908@gmx.net> <4B92D9A4.8080909@coresystems.de>
	<4B951ED2.7010909@gmx.net>
	<13426df11003080835n673e5088k4124a4ba154e8f@mail.gmail.com>
	<2831fecf1003080921g4411928du2ef2c2d8453203eb@mail.gmail.com>
	<4B954544.30401@coresystems.de>
Message-ID: <2831fecf1003081053h63f291cbk3a22983660757217@mail.gmail.com>

On Mon, Mar 8, 2010 at 11:43 AM, Stefan Reinauer <stepan at coresystems.de>wrote:

>  On 3/8/10 6:21 PM, Myles Watson wrote:
>
>  I thought the point was that you want to be able to recover when only
> serial works.  Lots of things can fail between then and loading a payload.
>
> No, the point is really to get normal going without an OS after normal is
> misflashed, with only fallback left.
>
That's what I was missing.  Thanks.

If you're beyond that point you're a coreboot hacker and want a replacement
> flash chip or some more convenient methods to recover anyways.
>
I was thinking of Ron's clusters, too.

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

From kh.nirschl at googlemail.com  Mon Mar  8 21:47:16 2010
From: kh.nirschl at googlemail.com (Karl-Heinz Nirschl)
Date: Mon, 8 Mar 2010 21:47:16 +0100
Subject: [coreboot] Fwd:  Getting started with Coreboot on Intel Core
In-Reply-To: <f7bea4a91003081245ge0d0519w62842fffb35bb0b1@mail.gmail.com>
References: <f7bea4a91003080931q241d05edtd2b8d03bf5a3831c@mail.gmail.com>
	<f7bea4a91003080936w69638e59m90035367161885d1@mail.gmail.com>
	<4B95443B.3050501@coresystems.de>
	<f7bea4a91003081245ge0d0519w62842fffb35bb0b1@mail.gmail.com>
Message-ID: <f7bea4a91003081247t301e43b4g4147f8ecd3fdd1db@mail.gmail.com>

argl,

forward this to coreboot list too.


---------- Forwarded message ----------
From: Karl-Heinz Nirschl <kh.nirschl at googlemail.com>
Date: 2010/3/8
Subject: Re: [coreboot] Getting started with Coreboot on Intel Core
To: Stefan Reinauer <stepan at coresystems.de>


Hi,

thanks for your reply. i thought
src/northbridge/intel/i945/early_init.c is executed after stage1_main
somewhere in real main. i've put a lot of postcodes bevor that
- one in front of stage1_main and and one in real_main. shouldn't i see these?

in my understanding execution takes the following way:
1 some generic x86 startup assembler
2 cache_as_ram.inc
3 cache_as_ram_disable.inc (stage1_main)
4 romstage.c (real_main) in mainboard dir
5 cpu_init
6 nb_init
-...

isn't that right? it looks like i hang between 2 und 3.


i'll go and check the toolschain in utils.


best regards,

khn




2010/3/8 Stefan Reinauer <stepan at coresystems.de>:
> On 3/8/10 6:36 PM, Karl-Heinz Nirschl wrote:
>> Hi,
>>
>> i should append:
>>
>> this is using a spi flash with 2 Megs and todays svn version.
>> i also tried with a 1 meg fhw with a somewhat earlier version of
>> coreboot. same problem.
>>
>>
>> regards,
>>
>> karl
>>
>>
>>
>> 2010/3/8 Karl-Heinz Nirschl <kh.nirschl at googlemail.com>:
>>
>>> Hi there,
>>>
>>> i'm new to coreboot and trying to port coreboot to a intel core based
>>> board. it's a u2500 with a ich7m and 945gm.
>>> i started with kontron 986lcd-m which should be quite similar but
>>> didn't have much success so far.
>>>
> Did you adapt the code for your SuperIO chip? Do you get any messages on
> the serial port?
>
>>> the board hangs with post code 0x23 (pci post card) which is bevor
>>> "call ? stage1_main" in model_6ex/cache_as_ram.inc.
>>>
>>> as this is very early and the cpu never seem to come to stage1_main
>>> (in cache_as_ram_disable.c) i assume i have a problem with my
>>> toolchain.
>>>
>
> Try this one:
>
> Index: src/northbridge/intel/i945/early_init.c
> ===================================================================
> --- src/northbridge/intel/i945/early_init.c (revision 5196)
> +++ src/northbridge/intel/i945/early_init.c (working copy)
> @@ -867,7 +867,7 @@
> i945_setup_bars();
>
> /* Change port80 to LPC */
> - RCBA32(GCS) &= (~0x04);
> + //RCBA32(GCS) &= (~0x04);
>
> /* Just do it that way */
> RCBA32(0x2010) |= (1 << 10);
>
> Then post codes keep going to PCI instead of LPC and you should see
> where it's going.
>
>
>
>
>
>>> I build on ubuntu 8.04 (Hardy Heron) with nothing special.
>>>
>>> Any hints for a coreboot newbie? Which additional information could i
>>> provide to find the problem?
>>>
>
> You should use the reference toolchain in util/crossgcc
>
>
> --
> 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
>



From Cristi.Magherusan at net.utcluj.ro  Mon Mar  8 21:33:34 2010
From: Cristi.Magherusan at net.utcluj.ro (Cristi Magherusan)
Date: Mon, 08 Mar 2010 22:33:34 +0200
Subject: [coreboot] "How come it's so slow?"
In-Reply-To: <c16a574a1003050958r672fe76bx6d6421c672440332@mail.gmail.com>
References: <13426df11003050858r1c4bbe5m34514694d6e7c561@mail.gmail.com>
	<c16a574a1003050958r672fe76bx6d6421c672440332@mail.gmail.com>
Message-ID: <1268080414.2985.7.camel@ubuntu>

Hi,

I noticed that the HP DL380 servers that I've been working with lately
wait a random amount of time before running the BIOS (up to 120sec) so
that if you boot up many machines at the same time they won't have the
power spikes at the same time when starting the fans and the disks.

Still, the BIOS itself is quite slow too, taking quite a lot of time,
especially when it initializes the RAID controllers. I didn't measure it
but it may be even more than a minute, including all the delays that can
be skipped if you press Escape.

Regards, 
Cristi

-- 
Cristi M?gheru?an, 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: 197 bytes
Desc: This is a digitally signed message part
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20100308/00060f3a/attachment.sig>

From stepan at coresystems.de  Mon Mar  8 22:43:13 2010
From: stepan at coresystems.de (Stefan Reinauer)
Date: Mon, 08 Mar 2010 22:43:13 +0100
Subject: [coreboot] Getting started with Coreboot on Intel Core
In-Reply-To: <f7bea4a91003081245ge0d0519w62842fffb35bb0b1@mail.gmail.com>
References: <f7bea4a91003080931q241d05edtd2b8d03bf5a3831c@mail.gmail.com>	
	<f7bea4a91003080936w69638e59m90035367161885d1@mail.gmail.com>	
	<4B95443B.3050501@coresystems.de>
	<f7bea4a91003081245ge0d0519w62842fffb35bb0b1@mail.gmail.com>
Message-ID: <4B956F71.2010001@coresystems.de>

On 3/8/10 9:45 PM, Karl-Heinz Nirschl wrote:
> Hi,
>
> thanks for your reply. i thought
> src/northbridge/intel/i945/early_init.c is executed after stage1_main
> somewhere in real main. i've put a lot of postcodes bevor that
> - one in front of stage1_main and and one in real_main. shouldn't i see these?
>   
>From your description I can't tell. But 0x23 is the last post code
before the call into stage1_main(). stage1_main() calls real_main()
which calls into early_init.c.,

Stefan




From kh.nirschl at googlemail.com  Mon Mar  8 22:46:12 2010
From: kh.nirschl at googlemail.com (Karl-Heinz Nirschl)
Date: Mon, 8 Mar 2010 22:46:12 +0100
Subject: [coreboot] crossgcc patch
Message-ID: <f7bea4a91003081346i29c50fcck90d89b2ae33ffb19@mail.gmail.com>

hi,

appended is a simple patch to make crossgcc script work. version
number of MPFR was bumped.


regards,


khn
-------------- next part --------------
A non-text attachment was scrubbed...
Name: patch
Type: application/octet-stream
Size: 300 bytes
Desc: not available
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20100308/76c97c78/attachment.obj>

From kh.nirschl at googlemail.com  Mon Mar  8 23:02:39 2010
From: kh.nirschl at googlemail.com (Karl-Heinz Nirschl)
Date: Mon, 8 Mar 2010 23:02:39 +0100
Subject: [coreboot] xcompile
Message-ID: <f7bea4a91003081402j552ff9d5r86e546f16972f516@mail.gmail.com>

Hi,

looks to me like xcompile uses the wrong start directory when called
from makefile. the appended trivial patch fixes this.



regards,
-------------- next part --------------
A non-text attachment was scrubbed...
Name: patch
Type: application/octet-stream
Size: 526 bytes
Desc: not available
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20100308/0d9cffb4/attachment.obj>

From stepan at coresystems.de  Mon Mar  8 23:04:11 2010
From: stepan at coresystems.de (Stefan Reinauer)
Date: Mon, 08 Mar 2010 23:04:11 +0100
Subject: [coreboot] Getting started with Coreboot on Intel Core
In-Reply-To: <f7bea4a91003081348w4e2c90b5ka0c618b621c319ee@mail.gmail.com>
References: <f7bea4a91003080931q241d05edtd2b8d03bf5a3831c@mail.gmail.com>	
	<f7bea4a91003080936w69638e59m90035367161885d1@mail.gmail.com>	
	<4B95443B.3050501@coresystems.de>	
	<f7bea4a91003081245ge0d0519w62842fffb35bb0b1@mail.gmail.com>	
	<4B956F71.2010001@coresystems.de>
	<f7bea4a91003081348w4e2c90b5ka0c618b621c319ee@mail.gmail.com>
Message-ID: <4B95745B.9000101@coresystems.de>

On 3/8/10 10:48 PM, Karl-Heinz Nirschl wrote:
> Hi,
>
> i've just compiled the crossgcc. but how do i make the build system
> use it. is there a coreboot way of doing it?
>
>   
coreboot should just pick it up... the script util/xcompile/xcompile
should create an according .xcompile file in the coreboot root directory

Stefan




From svn at coreboot.org  Tue Mar  9 00:38:43 2010
From: svn at coreboot.org (repository service)
Date: Tue, 09 Mar 2010 00:38:43 +0100
Subject: [coreboot] [commit] r5197 - trunk/src/mainboard/tyan/s2912_fam10
Message-ID: <E1NomX5-0007Sd-KB@ra.coresystems.de>

Author: oxygene
Date: Tue Mar  9 00:38:43 2010
New Revision: 5197
URL: http://tracker.coreboot.org/trac/coreboot/changeset/5197

Log:
Set options to make AMD CAR code compile correctly,
and increase MAX_CPUS to aid support 6-core CPUs.

Signed-off-by: Arne Georg Gleditsch <arne.gleditsch at numascale.com>
Acked-by: Patrick Georgi <patrick.georgi at coresystems.de>

Modified:
   trunk/src/mainboard/tyan/s2912_fam10/Kconfig

Modified: trunk/src/mainboard/tyan/s2912_fam10/Kconfig
==============================================================================
--- trunk/src/mainboard/tyan/s2912_fam10/Kconfig	Mon Mar  8 14:08:24 2010	(r5196)
+++ trunk/src/mainboard/tyan/s2912_fam10/Kconfig	Tue Mar  9 00:38:43 2010	(r5197)
@@ -38,6 +38,26 @@
 	default 0x04000
 	depends on BOARD_TYAN_S2912_FAM10
 
+config USE_FALLBACK_IMAGE
+	bool
+	default y
+	depends on BOARD_TYAN_S2912_FAM10
+
+config HAVE_FALLBACK_BOOT
+	bool
+	default y
+	depends on BOARD_TYAN_S2912_FAM10
+
+config CONFIG_USE_FAILOVER_IMAGE
+	bool
+	default y
+	depends on BOARD_TYAN_S2912_FAM10
+
+config CONFIG_HAVE_FAILOVER_BOOT
+	bool
+	default y
+	depends on BOARD_TYAN_S2912_FAM10
+
 config APIC_ID_OFFSET
 	hex
 	default 0
@@ -95,7 +115,7 @@
 
 config MAX_CPUS
 	int
-	default 8
+	default 12
 	depends on BOARD_TYAN_S2912_FAM10
 
 config MAX_PHYSICAL_CPUS



From patrick at georgi-clan.de  Tue Mar  9 00:39:57 2010
From: patrick at georgi-clan.de (Patrick Georgi)
Date: Tue, 09 Mar 2010 00:39:57 +0100
Subject: [coreboot] [PATCH] Tyan S2912 Fam10
In-Reply-To: <4B9136F3.6090003@numascale.com>
References: <4B9136F3.6090003@numascale.com>
Message-ID: <4B958ACD.6050502@georgi-clan.de>

Am 05.03.2010 17:53, schrieb Arne Georg Gleditsch:
> Signed-off-by: Arne Georg Gleditsch <arne.gleditsch at numascale.com>
Acked-by: Patrick Georgi <patrick.georgi at coresystems.de>

and committed as r5197


The "real" fix would be to eliminate the uses of these config options
(they're useless since we dropped newconfig), but this is a good
indicator on how to handle the AMD code when cleaning it up.


Thanks,
Patrick



From mylesgw at gmail.com  Tue Mar  9 00:18:08 2010
From: mylesgw at gmail.com (Myles Watson)
Date: Mon, 8 Mar 2010 16:18:08 -0700
Subject: [coreboot] Strange corruption with printk
Message-ID: <2831fecf1003081518o5b05576bx614dc0a3ca9075a8@mail.gmail.com>

I divided the CAR copy into pieces to debug memory corruption that I'm
seeing.  It seems to fit a pattern, but I'm not sure what would be causing
it.  Any ideas would be appreciated.

I'm copying the stack from 0c8000-0cfffff to 1f8000-1fffff
Here's the output when copying in 8 pieces

Copying testx from 000ced80 (001fed80)

0 dest 001f8000 src 000c8000 size 1000
1 dest 001f9000 src 000c9000 size 1000
2 dest 001fa000 src 000ca000 size 1000
3 dest 001fb000 src 000cb000 size 1000
4 dest 001fc000 src 000cc000 size 1000
5 dest 001fd000 src 000cd000 size 1000
6 dest 001fe000 src 000ce000 size 1000
? dest 001ff000 src 000cf000 size 1000
Copying done
Done

testx = 5a5a5a5a

Disabling cache as ram now


Notice the ? character when the top of the stack (location of testx) gets
copied.

16 pieces (excerpt):

d dest 001fe800 src 000ce800 size 800
? dest 001ff000 src 000cf000 size 800
f dest 001ff800 src 000cf800 size 800

Same character at the top of the stack

32 pieces:

1a dest 001fe800 src 000ce800 size 400
1b dest 001fec00 src 000cec00 size 400
?? dest 001ff000 src 000cf000 size 400
1d dest 001ff400 src 000cf400 size 400
1e dest 001ff800 src 000cf800 size 400

64 pieces:

36 dest 001fec00 src 000cec00 size 200
?? dest 001fee00 src 000cee00 size 200
38 dest 001ff000 src 000cf000 size 200

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

From svn at coreboot.org  Tue Mar  9 00:44:31 2010
From: svn at coreboot.org (repository service)
Date: Tue, 09 Mar 2010 00:44:31 +0100
Subject: [coreboot] [commit] r5198 - in trunk/src/mainboard:
	gigabyte/ga_2761gxdk gigabyte/m57sli msi/ms7135 msi/ms7260
	msi/ms9282 nvidia/l1_2pvv tyan/s2880 tyan/s2881 tyan/s2882
	tyan/s2885 tyan/s2891 tyan/s2892 tyan/...
Message-ID: <E1Nomch-0001zt-Fn@ra.coresystems.de>

Author: oxygene
Date: Tue Mar  9 00:44:30 2010
New Revision: 5198
URL: http://tracker.coreboot.org/trac/coreboot/changeset/5198

Log:
Remove Kconfig entries that disable
WAIT_BEFORE_CPUS_INIT. It's disabled by default
(see src/cpu/x86/Kconfig)

Signed-off-by: Patrick Georgi <patrick.georgi at coresystems.de>
Acked-by: Myles Watson <mylesgw at gmail.com>

Modified:
   trunk/src/mainboard/gigabyte/ga_2761gxdk/Kconfig
   trunk/src/mainboard/gigabyte/m57sli/Kconfig
   trunk/src/mainboard/msi/ms7135/Kconfig
   trunk/src/mainboard/msi/ms7260/Kconfig
   trunk/src/mainboard/msi/ms9282/Kconfig
   trunk/src/mainboard/nvidia/l1_2pvv/Kconfig
   trunk/src/mainboard/tyan/s2880/Kconfig
   trunk/src/mainboard/tyan/s2881/Kconfig
   trunk/src/mainboard/tyan/s2882/Kconfig
   trunk/src/mainboard/tyan/s2885/Kconfig
   trunk/src/mainboard/tyan/s2891/Kconfig
   trunk/src/mainboard/tyan/s2892/Kconfig
   trunk/src/mainboard/tyan/s2895/Kconfig
   trunk/src/mainboard/tyan/s2912/Kconfig
   trunk/src/mainboard/tyan/s2912_fam10/Kconfig

Modified: trunk/src/mainboard/gigabyte/ga_2761gxdk/Kconfig
==============================================================================
--- trunk/src/mainboard/gigabyte/ga_2761gxdk/Kconfig	Tue Mar  9 00:38:43 2010	(r5197)
+++ trunk/src/mainboard/gigabyte/ga_2761gxdk/Kconfig	Tue Mar  9 00:44:30 2010	(r5198)
@@ -125,11 +125,6 @@
 	default n
 	depends on BOARD_GIGABYTE_GA_2761GXDK
 
-config WAIT_BEFORE_CPUS_INIT
-	bool	
-	default n
-	depends on BOARD_GIGABYTE_GA_2761GXDK
-
 config MAINBOARD_PCI_SUBSYSTEM_VENDOR_ID
 	hex
 	default 0x1039

Modified: trunk/src/mainboard/gigabyte/m57sli/Kconfig
==============================================================================
--- trunk/src/mainboard/gigabyte/m57sli/Kconfig	Tue Mar  9 00:38:43 2010	(r5197)
+++ trunk/src/mainboard/gigabyte/m57sli/Kconfig	Tue Mar  9 00:44:30 2010	(r5198)
@@ -128,11 +128,6 @@
 	default n
 	depends on BOARD_GIGABYTE_M57SLI
 
-config WAIT_BEFORE_CPUS_INIT
-	bool	
-	default n
-	depends on BOARD_GIGABYTE_M57SLI
-
 config MAINBOARD_PCI_SUBSYSTEM_VENDOR_ID
 	hex
 	default 0x1022

Modified: trunk/src/mainboard/msi/ms7135/Kconfig
==============================================================================
--- trunk/src/mainboard/msi/ms7135/Kconfig	Tue Mar  9 00:38:43 2010	(r5197)
+++ trunk/src/mainboard/msi/ms7135/Kconfig	Tue Mar  9 00:44:30 2010	(r5198)
@@ -89,11 +89,6 @@
 	default n
 	depends on BOARD_MSI_MS7135
 
-config WAIT_BEFORE_CPUS_INIT
-	bool
-	default n
-	depends on BOARD_MSI_MS7135
-
 config SB_HT_CHAIN_ON_BUS0
 	int
 	default 2

Modified: trunk/src/mainboard/msi/ms7260/Kconfig
==============================================================================
--- trunk/src/mainboard/msi/ms7260/Kconfig	Tue Mar  9 00:38:43 2010	(r5197)
+++ trunk/src/mainboard/msi/ms7260/Kconfig	Tue Mar  9 00:44:30 2010	(r5198)
@@ -126,11 +126,6 @@
 	default n
 	depends on BOARD_MSI_MS7260
 
-config WAIT_BEFORE_CPUS_INIT
-	bool	
-	default n
-	depends on BOARD_MSI_MS7260
-
 config MAINBOARD_PCI_SUBSYSTEM_VENDOR_ID
 	hex
 	default 0x1462

Modified: trunk/src/mainboard/msi/ms9282/Kconfig
==============================================================================
--- trunk/src/mainboard/msi/ms9282/Kconfig	Tue Mar  9 00:38:43 2010	(r5197)
+++ trunk/src/mainboard/msi/ms9282/Kconfig	Tue Mar  9 00:44:30 2010	(r5198)
@@ -120,11 +120,6 @@
 	default n
 	depends on BOARD_MSI_MS9282
 
-config WAIT_BEFORE_CPUS_INIT
-	bool	
-	default n
-	depends on BOARD_MSI_MS9282
-
 config MAINBOARD_PCI_SUBSYSTEM_VENDOR_ID
 	hex
 	default 0x1462

Modified: trunk/src/mainboard/nvidia/l1_2pvv/Kconfig
==============================================================================
--- trunk/src/mainboard/nvidia/l1_2pvv/Kconfig	Tue Mar  9 00:38:43 2010	(r5197)
+++ trunk/src/mainboard/nvidia/l1_2pvv/Kconfig	Tue Mar  9 00:44:30 2010	(r5198)
@@ -126,11 +126,6 @@
 	default n
 	depends on BOARD_NVIDIA_L1_2PVV
 
-config WAIT_BEFORE_CPUS_INIT
-	bool	
-	default n
-	depends on BOARD_NVIDIA_L1_2PVV
-
 config MAINBOARD_PCI_SUBSYSTEM_VENDOR_ID
 	hex
 	default 0x1022

Modified: trunk/src/mainboard/tyan/s2880/Kconfig
==============================================================================
--- trunk/src/mainboard/tyan/s2880/Kconfig	Tue Mar  9 00:38:43 2010	(r5197)
+++ trunk/src/mainboard/tyan/s2880/Kconfig	Tue Mar  9 00:44:30 2010	(r5198)
@@ -83,11 +83,6 @@
 	default n
 	depends on BOARD_TYAN_S2880
 
-config WAIT_BEFORE_CPUS_INIT
-	bool
-	default n
-	depends on BOARD_TYAN_S2880
-
 config IRQ_SLOT_COUNT
 	int
 	default 13

Modified: trunk/src/mainboard/tyan/s2881/Kconfig
==============================================================================
--- trunk/src/mainboard/tyan/s2881/Kconfig	Tue Mar  9 00:38:43 2010	(r5197)
+++ trunk/src/mainboard/tyan/s2881/Kconfig	Tue Mar  9 00:44:30 2010	(r5198)
@@ -84,11 +84,6 @@
 	default n
 	depends on BOARD_TYAN_S2881
 
-config WAIT_BEFORE_CPUS_INIT
-	bool
-	default n
-	depends on BOARD_TYAN_S2881
-
 config IRQ_SLOT_COUNT
 	int
 	default 9

Modified: trunk/src/mainboard/tyan/s2882/Kconfig
==============================================================================
--- trunk/src/mainboard/tyan/s2882/Kconfig	Tue Mar  9 00:38:43 2010	(r5197)
+++ trunk/src/mainboard/tyan/s2882/Kconfig	Tue Mar  9 00:44:30 2010	(r5198)
@@ -83,11 +83,6 @@
 	default n
 	depends on BOARD_TYAN_S2882
 
-config WAIT_BEFORE_CPUS_INIT
-	bool
-	default n
-	depends on BOARD_TYAN_S2882
-
 config IRQ_SLOT_COUNT
 	int
 	default 15

Modified: trunk/src/mainboard/tyan/s2885/Kconfig
==============================================================================
--- trunk/src/mainboard/tyan/s2885/Kconfig	Tue Mar  9 00:38:43 2010	(r5197)
+++ trunk/src/mainboard/tyan/s2885/Kconfig	Tue Mar  9 00:44:30 2010	(r5198)
@@ -84,11 +84,6 @@
 	default n
 	depends on BOARD_TYAN_S2885
 
-config WAIT_BEFORE_CPUS_INIT
-	bool
-	default n
-	depends on BOARD_TYAN_S2885
-
 config IRQ_SLOT_COUNT
 	int
 	default 11

Modified: trunk/src/mainboard/tyan/s2891/Kconfig
==============================================================================
--- trunk/src/mainboard/tyan/s2891/Kconfig	Tue Mar  9 00:38:43 2010	(r5197)
+++ trunk/src/mainboard/tyan/s2891/Kconfig	Tue Mar  9 00:44:30 2010	(r5198)
@@ -86,11 +86,6 @@
 	default n
 	depends on BOARD_TYAN_S2891
 
-config WAIT_BEFORE_CPUS_INIT
-	bool
-	default n
-	depends on BOARD_TYAN_S2891
-
 config IRQ_SLOT_COUNT
 	int
 	default 11

Modified: trunk/src/mainboard/tyan/s2892/Kconfig
==============================================================================
--- trunk/src/mainboard/tyan/s2892/Kconfig	Tue Mar  9 00:38:43 2010	(r5197)
+++ trunk/src/mainboard/tyan/s2892/Kconfig	Tue Mar  9 00:44:30 2010	(r5198)
@@ -85,11 +85,6 @@
 	default n
 	depends on BOARD_TYAN_S2892
 
-config WAIT_BEFORE_CPUS_INIT
-	bool
-	default n
-	depends on BOARD_TYAN_S2892
-
 config SB_HT_CHAIN_ON_BUS0
 	int
 	default 2

Modified: trunk/src/mainboard/tyan/s2895/Kconfig
==============================================================================
--- trunk/src/mainboard/tyan/s2895/Kconfig	Tue Mar  9 00:38:43 2010	(r5197)
+++ trunk/src/mainboard/tyan/s2895/Kconfig	Tue Mar  9 00:44:30 2010	(r5198)
@@ -85,11 +85,6 @@
 	default n
 	depends on BOARD_TYAN_S2895
 
-config WAIT_BEFORE_CPUS_INIT
-	bool
-	default n
-	depends on BOARD_TYAN_S2895
-
 config SB_HT_CHAIN_ON_BUS0
 	int
 	default 2

Modified: trunk/src/mainboard/tyan/s2912/Kconfig
==============================================================================
--- trunk/src/mainboard/tyan/s2912/Kconfig	Tue Mar  9 00:38:43 2010	(r5197)
+++ trunk/src/mainboard/tyan/s2912/Kconfig	Tue Mar  9 00:44:30 2010	(r5198)
@@ -126,11 +126,6 @@
 	default n
 	depends on BOARD_TYAN_S2912
 
-config WAIT_BEFORE_CPUS_INIT
-	bool	
-	default n
-	depends on BOARD_TYAN_S2912
-
 config MAINBOARD_PCI_SUBSYSTEM_DEVICE_ID
 	hex
 	default 0x2912

Modified: trunk/src/mainboard/tyan/s2912_fam10/Kconfig
==============================================================================
--- trunk/src/mainboard/tyan/s2912_fam10/Kconfig	Tue Mar  9 00:38:43 2010	(r5197)
+++ trunk/src/mainboard/tyan/s2912_fam10/Kconfig	Tue Mar  9 00:44:30 2010	(r5198)
@@ -148,11 +148,6 @@
 	default n
 	depends on BOARD_TYAN_S2912_FAM10
 
-config WAIT_BEFORE_CPUS_INIT
-	bool
-	default n
-	depends on BOARD_TYAN_S2912_FAM10
-
 config MAINBOARD_PCI_SUBSYSTEM_DEVICE_ID
 	hex
 	default 0x2912



From joe at settoplinux.org  Tue Mar  9 01:02:38 2010
From: joe at settoplinux.org (Joseph Smith)
Date: Mon, 08 Mar 2010 19:02:38 -0500
Subject: [coreboot] Getting started with Coreboot on Intel Core
In-Reply-To: <4B95745B.9000101@coresystems.de>
References: <f7bea4a91003080931q241d05edtd2b8d03bf5a3831c@mail.gmail.com>
	<f7bea4a91003080936w69638e59m90035367161885d1@mail.gmail.com>
	<4B95443B.3050501@coresystems.de>
	<f7bea4a91003081245ge0d0519w62842fffb35bb0b1@mail.gmail.com>
	<4B956F71.2010001@coresystems.de>
	<f7bea4a91003081348w4e2c90b5ka0c618b621c319ee@mail.gmail.com>
	<4B95745B.9000101@coresystems.de>
Message-ID: <48644ca517aa3fd4ca1e6ed31a9f2c39@imap.1and1.com>




On Mon, 08 Mar 2010 23:04:11 +0100, Stefan Reinauer <stepan at coresystems.de>
wrote:
> On 3/8/10 10:48 PM, Karl-Heinz Nirschl wrote:
>> Hi,
>>
>> i've just compiled the crossgcc. but how do i make the build system
>> use it. is there a coreboot way of doing it?
>>
>>
> coreboot should just pick it up... the script util/xcompile/xcompile
> should create an according .xcompile file in the coreboot root directory
> 
huh?
So it just dosen't look for it in your $PATH???

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




From c-d.hailfinger.devel.2006 at gmx.net  Tue Mar  9 01:07:21 2010
From: c-d.hailfinger.devel.2006 at gmx.net (Carl-Daniel Hailfinger)
Date: Tue, 09 Mar 2010 01:07:21 +0100
Subject: [coreboot] Strange corruption with printk
In-Reply-To: <2831fecf1003081518o5b05576bx614dc0a3ca9075a8@mail.gmail.com>
References: <2831fecf1003081518o5b05576bx614dc0a3ca9075a8@mail.gmail.com>
Message-ID: <4B959139.5070607@gmx.net>

On 09.03.2010 00:18, Myles Watson wrote:
> I divided the CAR copy into pieces to debug memory corruption that I'm
> seeing.  It seems to fit a pattern, but I'm not sure what would be causing
> it.  Any ideas would be appreciated.
>   

To be honest, if post_cache_as_ram() works at all on K8, it is mostly
luck. The memory copy is not inline asm (will lead to subtle
corruption), the memory copy and the stack switching are not in one
inline asm block (gcc is free to insert arbitrary code in between), and
the stack is switched in the middle of a function (gcc may use some
non-clobbered regs to access the old stack, or simply die).

Throwing out the complete v2 K8 CAR disabling code and replacing it with
the v3 code is one of the possible fixes. I will do that probably this
May. By the way, the global variable infrastructure in v3 is one of the
reasons why stack switching in v3 is much less painful.

Regards,
Carl-Daniel

-- 
"I do consider assignment statements and pointer variables to be among
computer science's most valuable treasures."
-- Donald E. Knuth




From stepan at coresystems.de  Tue Mar  9 01:09:59 2010
From: stepan at coresystems.de (Stefan Reinauer)
Date: Tue, 09 Mar 2010 01:09:59 +0100
Subject: [coreboot] xcompile
In-Reply-To: <f7bea4a91003081402j552ff9d5r86e546f16972f516@mail.gmail.com>
References: <f7bea4a91003081402j552ff9d5r86e546f16972f516@mail.gmail.com>
Message-ID: <4B9591D7.6060800@coresystems.de>

On 3/8/10 11:02 PM, Karl-Heinz Nirschl wrote:
> Hi,
>
> looks to me like xcompile uses the wrong start directory when called
> from makefile. the appended trivial patch fixes this.
>   
It looks like you're still using the old repository path...

Please change to svn://coreboot.org/coreboot/trunk



-- 
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 joe at settoplinux.org  Tue Mar  9 01:16:39 2010
From: joe at settoplinux.org (Joseph Smith)
Date: Mon, 08 Mar 2010 19:16:39 -0500
Subject: [coreboot] GSoC 2010
In-Reply-To: <9ae48b021003081604v1d99513el65845eec556e495@mail.gmail.com>
References: <4B8FD7F7.7090307@gmx.net>
	<534e5dc21003040917u37e5ea7ek5d29f4b73b8dc445@mail.gmail.com>
	<46893e741003060029v13d8af42xde7da120e0ebee1@mail.gmail.com>
	<df1430311003060103w22137aa9w7e43e1dd64977654@mail.gmail.com>
	<4B925C5D.1040609@gmx.net> <4B926BB1.4080601@gmx.net>
	<D2B8891A-FEBE-4A46-80BD-A292E109662D@coresystems.de>
	<49f8af42eac1e221bca5af3b9e97b052@imap.1and1.com>
	<4B927F35.3060500@gmx.net>
	<9ae48b021003081604v1d99513el65845eec556e495@mail.gmail.com>
Message-ID: <3c6928fe92a44cc52197c437efbcbf2c@imap.1and1.com>




On Mon, 8 Mar 2010 16:04:31 -0800, Ed Swierk <eswierk at aristanetworks.com>
wrote:
> On Sat, Mar 6, 2010 at 8:13 AM, Carl-Daniel Hailfinger
> <c-d.hailfinger.devel.2006 at gmx.net> wrote:
>> 2. Tiny flashrom stub for remote flashing over serial/network/whatever
>> (~10 kB uncompressed and 3 kB lzma compressed, maybe even smaller).
>> 3. Load flashrom from an external medium (serial/USB/floppy/whatever) to
>> RAM and execute it (no space requirements).
>> ...
>> Variant 2 is essentially a stripped down SerialICE with one or two extra
>> commands. Rather slow, but you can upgrade the controlling flashrom app
>> on the master computer (and test patches) without having to mess with
>> the contents of the flash in the slave (to be reflashed) computer.
>> Besides that, it allows even such stuff as PCI card reflashing (for gPXE
>> and stuff).
>> Variant 3 has a high initial load time, but flashing will be fast. No
>> guarantees on how to recover if flashrom crashes or exits prematurely,
>> though.
> 
> I implemented a little hack a while ago that let you download a
> payload via xmodem over serial:
> 
> http://www.coreboot.org/pipermail/coreboot/2006-October/016120.html
> 
> It looks like most of the code has since vanished, but the
> xmodemReceive() function is still there, and might be useful for some
> kind of last-ditch failover mechanism.
> 
We also have a small program on Set-Top-Linux to send flash commands to the
original bios over Serial Console:


http://www.settoplinux.org/index.php?title=RCA_RM4100:Howto_coreboot_and_Linux#Flash_the_bios

You just copy bios image to drive, boot, and flash over serial console.
It may be nothing, but it could be a start to something that could be used
for recovery???


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




From stepan at coresystems.de  Tue Mar  9 01:23:34 2010
From: stepan at coresystems.de (Stefan Reinauer)
Date: Tue, 09 Mar 2010 01:23:34 +0100
Subject: [coreboot] Getting started with Coreboot on Intel Core
In-Reply-To: <48644ca517aa3fd4ca1e6ed31a9f2c39@imap.1and1.com>
References: <f7bea4a91003080931q241d05edtd2b8d03bf5a3831c@mail.gmail.com>
	<f7bea4a91003080936w69638e59m90035367161885d1@mail.gmail.com>
	<4B95443B.3050501@coresystems.de>
	<f7bea4a91003081245ge0d0519w62842fffb35bb0b1@mail.gmail.com>
	<4B956F71.2010001@coresystems.de>
	<f7bea4a91003081348w4e2c90b5ka0c618b621c319ee@mail.gmail.com>
	<4B95745B.9000101@coresystems.de>
	<48644ca517aa3fd4ca1e6ed31a9f2c39@imap.1and1.com>
Message-ID: <4B959506.8000307@coresystems.de>

On 3/9/10 1:02 AM, Joseph Smith wrote:
>
>
> On Mon, 08 Mar 2010 23:04:11 +0100, Stefan Reinauer <stepan at coresystems.de>
> wrote:
>   
>> On 3/8/10 10:48 PM, Karl-Heinz Nirschl wrote:
>>     
>>> Hi,
>>>
>>> i've just compiled the crossgcc. but how do i make the build system
>>> use it. is there a coreboot way of doing it?
>>>
>>>
>>>       
>> coreboot should just pick it up... the script util/xcompile/xcompile
>> should create an according .xcompile file in the coreboot root directory
>>
>>     
> huh?
> So it just dosen't look for it in your $PATH???
>
>   
It does, right after it checked util/crossgcc/xgcc/bin

-- 
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 joe at settoplinux.org  Tue Mar  9 01:24:25 2010
From: joe at settoplinux.org (Joseph Smith)
Date: Mon, 08 Mar 2010 19:24:25 -0500
Subject: [coreboot] Getting started with Coreboot on Intel Core
In-Reply-To: <4B959506.8000307@coresystems.de>
References: <f7bea4a91003080931q241d05edtd2b8d03bf5a3831c@mail.gmail.com>
	<f7bea4a91003080936w69638e59m90035367161885d1@mail.gmail.com>
	<4B95443B.3050501@coresystems.de>
	<f7bea4a91003081245ge0d0519w62842fffb35bb0b1@mail.gmail.com>
	<4B956F71.2010001@coresystems.de>
	<f7bea4a91003081348w4e2c90b5ka0c618b621c319ee@mail.gmail.com>
	<4B95745B.9000101@coresystems.de>
	<48644ca517aa3fd4ca1e6ed31a9f2c39@imap.1and1.com>
	<4B959506.8000307@coresystems.de>
Message-ID: <be753611a167296c1e94ee6d04bee78a@imap.1and1.com>




On Tue, 09 Mar 2010 01:23:34 +0100, Stefan Reinauer <stepan at coresystems.de>
wrote:
> On 3/9/10 1:02 AM, Joseph Smith wrote:
>>
>>
>> On Mon, 08 Mar 2010 23:04:11 +0100, Stefan Reinauer
> <stepan at coresystems.de>
>> wrote:
>>
>>> On 3/8/10 10:48 PM, Karl-Heinz Nirschl wrote:
>>>
>>>> Hi,
>>>>
>>>> i've just compiled the crossgcc. but how do i make the build system
>>>> use it. is there a coreboot way of doing it?
>>>>
>>>>
>>>>
>>> coreboot should just pick it up... the script util/xcompile/xcompile
>>> should create an according .xcompile file in the coreboot root
directory
>>>
>>>
>> huh?
>> So it just dosen't look for it in your $PATH???
>>
>>
> It does, right after it checked util/crossgcc/xgcc/bin
> 
oh ok.

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




From eswierk at aristanetworks.com  Tue Mar  9 01:04:31 2010
From: eswierk at aristanetworks.com (Ed Swierk)
Date: Mon, 8 Mar 2010 16:04:31 -0800
Subject: [coreboot] GSoC 2010
In-Reply-To: <4B927F35.3060500@gmx.net>
References: <4B8FD7F7.7090307@gmx.net>
	<534e5dc21003040917u37e5ea7ek5d29f4b73b8dc445@mail.gmail.com>
	<46893e741003060029v13d8af42xde7da120e0ebee1@mail.gmail.com>
	<df1430311003060103w22137aa9w7e43e1dd64977654@mail.gmail.com>
	<4B925C5D.1040609@gmx.net> <4B926BB1.4080601@gmx.net>
	<D2B8891A-FEBE-4A46-80BD-A292E109662D@coresystems.de>
	<49f8af42eac1e221bca5af3b9e97b052@imap.1and1.com>
	<4B927F35.3060500@gmx.net>
Message-ID: <9ae48b021003081604v1d99513el65845eec556e495@mail.gmail.com>

On Sat, Mar 6, 2010 at 8:13 AM, Carl-Daniel Hailfinger
<c-d.hailfinger.devel.2006 at gmx.net> wrote:
> 2. Tiny flashrom stub for remote flashing over serial/network/whatever
> (~10 kB uncompressed and 3 kB lzma compressed, maybe even smaller).
> 3. Load flashrom from an external medium (serial/USB/floppy/whatever) to
> RAM and execute it (no space requirements).
> ...
> Variant 2 is essentially a stripped down SerialICE with one or two extra
> commands. Rather slow, but you can upgrade the controlling flashrom app
> on the master computer (and test patches) without having to mess with
> the contents of the flash in the slave (to be reflashed) computer.
> Besides that, it allows even such stuff as PCI card reflashing (for gPXE
> and stuff).
> Variant 3 has a high initial load time, but flashing will be fast. No
> guarantees on how to recover if flashrom crashes or exits prematurely,
> though.

I implemented a little hack a while ago that let you download a
payload via xmodem over serial:

http://www.coreboot.org/pipermail/coreboot/2006-October/016120.html

It looks like most of the code has since vanished, but the
xmodemReceive() function is still there, and might be useful for some
kind of last-ditch failover mechanism.

--Ed



From c-d.hailfinger.devel.2006 at gmx.net  Tue Mar  9 03:50:57 2010
From: c-d.hailfinger.devel.2006 at gmx.net (Carl-Daniel Hailfinger)
Date: Tue, 09 Mar 2010 03:50:57 +0100
Subject: [coreboot] GSoC 2010
In-Reply-To: <3c6928fe92a44cc52197c437efbcbf2c@imap.1and1.com>
References: <4B8FD7F7.7090307@gmx.net>	<534e5dc21003040917u37e5ea7ek5d29f4b73b8dc445@mail.gmail.com>	<46893e741003060029v13d8af42xde7da120e0ebee1@mail.gmail.com>	<df1430311003060103w22137aa9w7e43e1dd64977654@mail.gmail.com>	<4B925C5D.1040609@gmx.net>
	<4B926BB1.4080601@gmx.net>	<D2B8891A-FEBE-4A46-80BD-A292E109662D@coresystems.de>	<49f8af42eac1e221bca5af3b9e97b052@imap.1and1.com>	<4B927F35.3060500@gmx.net>	<9ae48b021003081604v1d99513el65845eec556e495@mail.gmail.com>
	<3c6928fe92a44cc52197c437efbcbf2c@imap.1and1.com>
Message-ID: <4B95B791.5060208@gmx.net>

On 09.03.2010 01:16, Joseph Smith wrote:
> On Mon, 8 Mar 2010 16:04:31 -0800, Ed Swierk <eswierk at aristanetworks.com>
> wrote:
>   
>> On Sat, Mar 6, 2010 at 8:13 AM, Carl-Daniel Hailfinger
>> <c-d.hailfinger.devel.2006 at gmx.net> wrote:
>>     
>>> 2. Tiny flashrom stub for remote flashing over serial/network/whatever
>>> (~10 kB uncompressed and 3 kB lzma compressed, maybe even smaller).
>>> 3. Load flashrom from an external medium (serial/USB/floppy/whatever) to
>>> RAM and execute it (no space requirements).
>>> ...
>>> Variant 2 is essentially a stripped down SerialICE with one or two extra
>>> commands. Rather slow, but you can upgrade the controlling flashrom app
>>> on the master computer (and test patches) without having to mess with
>>> the contents of the flash in the slave (to be reflashed) computer.
>>> Besides that, it allows even such stuff as PCI card reflashing (for gPXE
>>> and stuff).
>>> Variant 3 has a high initial load time, but flashing will be fast. No
>>> guarantees on how to recover if flashrom crashes or exits prematurely,
>>> though.
>>>       
>> I implemented a little hack a while ago that let you download a
>> payload via xmodem over serial:
>>
>> http://www.coreboot.org/pipermail/coreboot/2006-October/016120.html
>>     

Right, I had remembered such a think existed, but didn't know where to look.


>> It looks like most of the code has since vanished, but the
>> xmodemReceive() function is still there, and might be useful for some
>> kind of last-ditch failover mechanism.
>>     

Absolutely. It is definitely good for payload/whateveryoucallit download
once CAR or RAM is working.


> We also have a small program on Set-Top-Linux to send flash commands to the
> original bios over Serial Console:
>
>
> http://www.settoplinux.org/index.php?title=RCA_RM4100:Howto_coreboot_and_Linux#Flash_the_bios
>
> You just copy bios image to drive, boot, and flash over serial console.
> It may be nothing, but it could be a start to something that could be used
> for recovery???
>   

AFAICS the trick you mentioned works by uploading a small flasher
program to the RM4100 memory in a place where it overwrites existing
code, causing execution to continue at the inserted code. Very neat. It
needs a way to upload a program over serial to RAM to work at all, though.

Anyway, we'll see what the optimal solution is, and how it works out.
IMHO one key to success is to have multiple options, and enable some
sort of recovery for all of them.

Regards,
Carl-Daniel

-- 
"I do consider assignment statements and pointer variables to be among
computer science's most valuable treasures."
-- Donald E. Knuth




From c-d.hailfinger.devel.2006 at gmx.net  Tue Mar  9 03:55:55 2010
From: c-d.hailfinger.devel.2006 at gmx.net (Carl-Daniel Hailfinger)
Date: Tue, 09 Mar 2010 03:55:55 +0100
Subject: [coreboot] Strange corruption with printk
In-Reply-To: <ACC5402B33C9468D8C5A6FCF2BBA567D@chimp>
References: <2831fecf1003081518o5b05576bx614dc0a3ca9075a8@mail.gmail.com>
	<4B959139.5070607@gmx.net> <ACC5402B33C9468D8C5A6FCF2BBA567D@chimp>
Message-ID: <4B95B8BB.3060802@gmx.net>

On 09.03.2010 03:16, Myles Watson wrote:
>   
>> On 09.03.2010 00:18, Myles Watson wrote:
>>     
>>> I divided the CAR copy into pieces to debug memory corruption that I'm
>>> seeing.  It seems to fit a pattern, but I'm not sure what would be
>>>       
>> causing
>>     
>>> it.  Any ideas would be appreciated.
>>>
>>>       
>> To be honest, if post_cache_as_ram() works at all on K8, it is mostly
>> luck.
>>     
> :)
>
>   
>> The memory copy is not inline asm (will lead to subtle
>> corruption), the memory copy and the stack switching are not in one
>> inline asm block (gcc is free to insert arbitrary code in between), and
>> the stack is switched in the middle of a function (gcc may use some
>> non-clobbered regs to access the old stack, or simply die).
>>
>> Throwing out the complete v2 K8 CAR disabling code and replacing it with
>> the v3 code is one of the possible fixes.
>>     
> Unfortunately, v3 never worked for K8.
>   

IIRC CAR disable worked for K8 in v3, but later K8 init failed.
Maybe it makes more sense to modify my suggestion above to "replace some
of the code with v3". The three-stage-CAR-disable-jump design in v3 is
something I believe to be superior to the stack switching in v2.
Anyway, I think that having the stack copy inside the same asm statement
as the stack switch could probably help.

Regards,
Carl-Daniel

-- 
"I do consider assignment statements and pointer variables to be among
computer science's most valuable treasures."
-- Donald E. Knuth




From Zheng.Bao at amd.com  Tue Mar  9 04:02:06 2010
From: Zheng.Bao at amd.com (Bao, Zheng)
Date: Tue, 9 Mar 2010 11:02:06 +0800
Subject: [coreboot] [PATCH] sb600: new way to load initial verb
In-Reply-To: <4B950661.5060905@gmx.net>
References: <DD1CC71B621B004FA76856E5129D6B17038260ED@sbjgexmb1.amd.com><4B90D94E.5000007@coresystems.de>	<4B910F27.7030903@gmx.net>
	<DD1CC71B621B004FA76856E5129D6B170382637F@sbjgexmb1.amd.com>
	<4B950661.5060905@gmx.net>
Message-ID: <DD1CC71B621B004FA76856E5129D6B1703826497@sbjgexmb1.amd.com>



> -----Original Message-----
> From: Carl-Daniel Hailfinger
[mailto:c-d.hailfinger.devel.2006 at gmx.net]
> Sent: Monday, March 08, 2010 10:15 PM
> To: Bao, Zheng
> Cc: Stefan Reinauer; coreboot at coreboot.org
> Subject: Re: [coreboot] [PATCH] sb600: new way to load initial verb
> 
> On 08.03.2010 09:20, Bao, Zheng wrote:
> > The original way to load initial verb is quite inflexible.
> > The format of the command is:
> > CAd 31:28 - codec address
> > NID 27:20 - Nid
> > Verb 19:0 - Verb data
> > Each Nid has 4 byte data to write. It has to write one at a time.
> > 	0x01471c10,      //1st byte 10
> > 	0x01471d40,      //2nd byte 40
> > 	0x01471e01,      //3rd byte 01
> > 	0x01471f01,      //4th byte 01
> >
> > The new code in sb600_hda.c and the code structure are quite
> > preliminary.  When it is almost done and can satisfy everybody, We
can
> > define the pin configuration code at mainboard.
> >
> 
> It would be cool if all chipsets could use the new verb
implementation.
> 
> 
> >  #define CODEC_PIN_CONFIG_FILE "codec/alc_882.h"
> > or
> >  config CODEC_PIN_CONFIG_FILE
> > 	string
> > 	default "codec/alc_882.h"
> > 	depends on BOARD_AMD_DBM690T
> >
> 
> Or we define that file as separate uncompressed CBFS file.
> 
> 
> > Now I am wondering if it is legal provide the intial pin
configuration
> > code in coreboot. If it is legal, how can we get it? The 882 code is
> > got from CIM.
> >
> 
> Sorry, what is CIM?
> In theory, the pin configuration is mainboard specific. If that is
true,
> the pin configuration is similar to IRQ routing: There is usually only
> one correct and working solution. So it is possible that the mainboard
> vendor and the codec vendor own parts of it. Not sure. We could tell
> users to dump verbs from their mainboards (is that possible?) and add
> the resulting file to CBFS.
> 
It is mainboard specific. Each codec also has its own code. The
mainboard code is based on the codec code, I think. Dumping verbs is
possible. It needs a lot of work from the ground up. There are some
similar tools like http://helllabs.org/codecgraph/. Integrating them to
coreboot/util needs permission, doesn't it?

> 
> > Signed-off-by: Zheng Bao <zheng.bao at amd.com>
> >
> > Index: src/codec/alc_882.h
> > ===================================================================
> > --- src/codec/alc_882.h	(revision 0)
> > +++ src/codec/alc_882.h	(revision 0)
> > @@ -0,0 +1,12 @@
> >
> 
> struct _pin_config_codec_entry pin_config_file[] = {
> 
> > +	{0x14, 0x01014010},
> > +	{0x15, 0x01011012},
> > +	{0x16, 0x01016011},
> > +	{0x17, 0x01012014},
> > +	{0x18, 0x01A19030},
> > +	{0x19, 0x411111F0},
> > +	{0x1a, 0x01813080},
> > +	{0x1b, 0x411111F0},
> > +	{0x1C, 0x411111F0},
> > +	{0x1d, 0x411111F0},
> > +	{0x1e, 0x01441150},
> > +	{0x1f, 0x01C46160},
> >
> 
> {-1, -1}
> };
> 
> 
> > Index: src/southbridge/amd/sb600/sb600_hda.c
> > ===================================================================
> > --- src/southbridge/amd/sb600/sb600_hda.c	(revision 5195)
> > +++ src/southbridge/amd/sb600/sb600_hda.c	(working copy)
> > @@ -90,68 +90,19 @@
> >  	return 0;
> >  }
> >
> > -static u32 cim_verb_data[] = {
> > -	0x01471c10,
> > -	0x01471d40,
> > -	0x01471e01,
> > -	0x01471f01,
> > -/* 1 */
> > -	0x01571c12,
> > -	0x01571d10,
> > -	0x01571e01,
> > -	0x01571f01,
> > -/* 2 */
> > -	0x01671c11,
> > -	0x01671d60,
> > -	0x01671e01,
> > -	0x01671f01,
> > -/* 3 */
> > -	0x01771c14,
> > -	0x01771d20,
> > -	0x01771e01,
> > -	0x01771f01,
> > -/* 4 */
> > -	0x01871c30,
> > -	0x01871d90,
> > -	0x01871ea1,
> > -	0x01871f01,
> > -/* 5 */
> > -	0x01971cf0,
> > -	0x01971d11,
> > -	0x01971e11,
> > -	0x01971f41,
> > -/* 6 */
> > -	0x01a71c80,
> > -	0x01a71d30,
> > -	0x01a71e81,
> > -	0x01a71f01,
> > -/* 7 */
> > -	0x01b71cf0,
> > -	0x01b71d11,
> > -	0x01b71e11,
> > -	0x01b71f41,
> > -/* 8 */
> > -	0x01c71cf0,
> > -	0x01c71d11,
> > -	0x01c71e11,
> > -	0x01c71f41,
> > -/* 9 */
> > -	0x01d71cf0,
> > -	0x01d71d11,
> > -	0x01d71e11,
> > -	0x01d71f41,
> > -/* 10 */
> > -	0x01e71c50,
> > -	0x01e71d11,
> > -	0x01e71e44,
> > -	0x01e71f01,
> > -/* 11 */
> > -	0x01f71c60,
> > -	0x01f71d61,
> > -	0x01f71ec4,
> > -	0x01f71f01,
> > +typedef struct _pin_config_codec_entry {
> >
> 
> Can you please kill the typedef and use "struct
_pin_config_codec_entry"
> instead?
> 
> 
> > +	u8	nid;
> > +	u32	pin_config;
> > +} pin_config_codec_entry;
> > +
> > +static pin_config_codec_entry pin_config_file[] = {
> > +#ifdef	CODEC_PIN_CONFIG_FILE
> > +	#include CODEC_PIN_CONFIG_FILE
> >
> 
> Including C source makes code difficult to read. Can you move the
> complete struct to alc_882.h?
> 
> Hm. Could we simply store the whole verb stuff uncompressed inside
CBFS?
> 

I think the purpose of the CBFS is to integrate some binary files which
are built at other place. The verb data we got is in text mode. We need
to build it into binary and store it into CBFS. Is it wasting? Why don't
we do it as fam10 patch code?

> 
> > +#endif
> > +	{-1, -1}
> >  };
> > -static u32 find_verb(u32 viddid, u32 ** verb)
> > +
> > +static void find_verb(u32 viddid, pin_config_codec_entry ** verb)
> >  {
> >  	device_t azalia_dev = dev_find_slot(0, PCI_DEVFN(0x14, 2));
> >  	struct southbridge_amd_sb600_config *cfg =
> > @@ -159,12 +110,13 @@
> >  	printk_debug("Dev=%s\n", dev_path(azalia_dev));
> >  	printk_debug("Default viddid=%x\n", cfg->hda_viddid);
> >  	printk_debug("Reading viddid=%x\n", viddid);
> > +
> > +	*verb = NULL;
> >  	if (!cfg)
> > -		return 0;
> > +		return;
> >  	if (viddid != cfg->hda_viddid)
> > -		return 0;
> > -	*verb = (u32 *) cim_verb_data;
> > -	return sizeof(cim_verb_data) / sizeof(u32);
> > +		return;
> > +	*verb = pin_config_file;
> >  }
> >
> >  /**
> > @@ -214,9 +166,8 @@
> >
> >  static void codec_init(u8 * base, int addr)
> >  {
> > -	u32 dword;
> > -	u32 *verb;
> > -	u32 verb_size;
> > +	u32 dword, dword1, pin_config;
> > +	pin_config_codec_entry *verb=NULL;
> >  	int i;
> >
> >  	/* 1 */
> > @@ -233,23 +184,32 @@
> >
> >  	/* 2 */
> >  	printk_debug("codec viddid: %08x\n", dword);
> > -	verb_size = find_verb(dword, &verb);
> > +	find_verb(dword, &verb);
> >
> > -	if (!verb_size) {
> > +	if (verb == NULL) {
> >  		printk_debug("No verb!\n");
> >  		return;
> >  	}
> >
> > -	printk_debug("verb_size: %d\n", verb_size);
> >  	/* 3 */
> > -	for (i = 0; i < verb_size; i++) {
> > -		if (wait_for_ready(base) == -1)
> > -			return;
> > +	for (verb; verb->nid != 0xFF; verb++) {
> > +		dword = addr << 28 | verb->nid << 20 | 7 << 16;
> > +		pin_config = verb->pin_config;
> >
> > -		write32(base + 0x60, verb[i]);
> > +		for (i = 4; i > 0; i--, pin_config >>= 8) {
> > +			if (wait_for_ready(base) == -1)
> > +				return;
> >
> > -		if (wait_for_valid(base) == -1)
> > -			return;
> > +			if (verb->nid != 1)
> > +				dword1 = dword | ((0x20 - i) & 0xFF) <<
8;
> > +			else
> > +				dword1 = dword | ((0x24 - i) & 0xFF) <<
8;
> > +			dword1 |= (pin_config & 0xFF);
> > +			write32(base + 0x60, dword1);
> > +
> > +			if (wait_for_valid(base) == -1)
> > +				return;
> > +		}
> >  	}
> >  	printk_debug("verb loaded!\n");
> >  }
> >
> 
> Looks good.
> 
> Regards,
> Carl-Daniel
> 
> --
> "I do consider assignment statements and pointer variables to be among
> computer science's most valuable treasures."
> -- Donald E. Knuth
> 





From mylesgw at gmail.com  Tue Mar  9 03:16:01 2010
From: mylesgw at gmail.com (Myles Watson)
Date: Mon, 8 Mar 2010 19:16:01 -0700
Subject: [coreboot] Strange corruption with printk
In-Reply-To: <4B959139.5070607@gmx.net>
References: <2831fecf1003081518o5b05576bx614dc0a3ca9075a8@mail.gmail.com>
	<4B959139.5070607@gmx.net>
Message-ID: <ACC5402B33C9468D8C5A6FCF2BBA567D@chimp>



> On 09.03.2010 00:18, Myles Watson wrote:
> > I divided the CAR copy into pieces to debug memory corruption that I'm
> > seeing.  It seems to fit a pattern, but I'm not sure what would be
> causing
> > it.  Any ideas would be appreciated.
> >
> 
> To be honest, if post_cache_as_ram() works at all on K8, it is mostly
> luck.
:)

> The memory copy is not inline asm (will lead to subtle
> corruption), the memory copy and the stack switching are not in one
> inline asm block (gcc is free to insert arbitrary code in between), and
> the stack is switched in the middle of a function (gcc may use some
> non-clobbered regs to access the old stack, or simply die).
> 
> Throwing out the complete v2 K8 CAR disabling code and replacing it with
> the v3 code is one of the possible fixes.
Unfortunately, v3 never worked for K8.

Thanks,
Myles




From kh.nirschl at googlemail.com  Tue Mar  9 10:41:54 2010
From: kh.nirschl at googlemail.com (Karl-Heinz Nirschl)
Date: Tue, 9 Mar 2010 10:41:54 +0100
Subject: [coreboot] crossgcc patch
In-Reply-To: <f7bea4a91003081346i29c50fcck90d89b2ae33ffb19@mail.gmail.com>
References: <f7bea4a91003081346i29c50fcck90d89b2ae33ffb19@mail.gmail.com>
Message-ID: <f7bea4a91003090141wfcbd98di69d1b47f15a7dfe8@mail.gmail.com>

hi,

looks like i was in the old tree. works fine with lastest svn. sorry for that.

regards,

khn

2010/3/8 Karl-Heinz Nirschl <kh.nirschl at googlemail.com>:
> hi,
>
> appended is a simple patch to make crossgcc script work. version
> number of MPFR was bumped.
>
>
> regards,
>
>
> khn
>



From kh.nirschl at googlemail.com  Tue Mar  9 10:40:25 2010
From: kh.nirschl at googlemail.com (Karl-Heinz Nirschl)
Date: Tue, 9 Mar 2010 10:40:25 +0100
Subject: [coreboot] xcompile
In-Reply-To: <4B9591D7.6060800@coresystems.de>
References: <f7bea4a91003081402j552ff9d5r86e546f16972f516@mail.gmail.com>
	<4B9591D7.6060800@coresystems.de>
Message-ID: <f7bea4a91003090140u596abc2aw7633582074072b9d@mail.gmail.com>

Hi,
right. that was the failure. sorry for that.


regards,

khn

2010/3/9 Stefan Reinauer <stepan at coresystems.de>:
> On 3/8/10 11:02 PM, Karl-Heinz Nirschl wrote:
>> Hi,
>>
>> looks to me like xcompile uses the wrong start directory when called
>> from makefile. the appended trivial patch fixes this.
>>
> It looks like you're still using the old repository path...
>
> Please change to svn://coreboot.org/coreboot/trunk
>
>
>
> --
> 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
>



From paul at astro.gla.ac.uk  Tue Mar  9 12:22:01 2010
From: paul at astro.gla.ac.uk (Paul Millar)
Date: Tue, 9 Mar 2010 12:22:01 +0100
Subject: [coreboot] Fwd: Re:  GSoC 2010
Message-ID: <201003091222.01496.paul@astro.gla.ac.uk>

[resent from different email address]

Hi Carl-Daniel,

BTW, I'm <paul at astro.gla.ac.uk> and also <paul.millar at desy.de>.  Both 
addresses will work, but I try to keep the DESY account for work stuff.  I'm 
also subscribed to the coreboot mailing list, but I'm not always up-to-date 
with the latest developments :)

On Sunday 07 March 2010 21:47:21 Carl-Daniel Hailfinger wrote:
> I'm one of the developers of flashrom <http://www.flashrom.org/> which
> aims to be a generic utility for programming all kinds of flash EEPROMs
> on your mainboard, on storage/network/graphics cards, and in external
> programmers.
> There is some interest in integrating parts of your firebrand code to
> support a Willem backend/driver for flashrom. Would that be OK with you?
> flashrom is GPLv2.

I think that's an excellent idea.  The code-base is available under LGPL v2.1 
and was written with as a library to facilitate people using it in their own 
software.  That said, I believe the supplied CLI tool is the only code that 
links against the library, so if the API proves problematic, we can try to 
adjust it to match.

Incidentally, the project is now also available from the SVN repository here:

    http://savannah.nongnu.org/projects/firebrand/

Cheers,

Paul.

-------------------------------------------------------



From r.marek at assembler.cz  Tue Mar  9 13:26:26 2010
From: r.marek at assembler.cz (Rudolf Marek)
Date: Tue, 09 Mar 2010 13:26:26 +0100
Subject: [coreboot] Strange corruption with printk
In-Reply-To: <4B95B8BB.3060802@gmx.net>
References: <2831fecf1003081518o5b05576bx614dc0a3ca9075a8@mail.gmail.com>	<4B959139.5070607@gmx.net>
	<ACC5402B33C9468D8C5A6FCF2BBA567D@chimp> <4B95B8BB.3060802@gmx.net>
Message-ID: <4B963E72.1030301@assembler.cz>

>>> The memory copy is not inline asm (will lead to subtle
>>> corruption), the memory copy and the stack switching are not in one
>>> inline asm block (gcc is free to insert arbitrary code in between), and
>>> the stack is switched in the middle of a function (gcc may use some
>>> non-clobbered regs to access the old stack, or simply die).
>>>

I fixed that with recent patch. Is it what you checked?

Myles, please check

1) If it does work without my patch ;)
2) Add the


static void set_init_ram_access_uc(void)
{
	set_var_mtrr(0, 0x00000000, CONFIG_RAMTOP, MTRR_TYPE_UNCACHED);
}


And call the set_init_ram_access_uc instead of set_init_ram_access and call 
again set_init_ram_access after the copy.

The CAR code as it is now is doing at least evictions to L2 maybe this will help.

Rudolf



From kh.nirschl at googlemail.com  Tue Mar  9 13:41:58 2010
From: kh.nirschl at googlemail.com (Karl-Heinz Nirschl)
Date: Tue, 9 Mar 2010 13:41:58 +0100
Subject: [coreboot] Getting started with Coreboot on Intel Core
In-Reply-To: <f7bea4a91003090421g44717202o58915a9f51062a50@mail.gmail.com>
References: <f7bea4a91003080931q241d05edtd2b8d03bf5a3831c@mail.gmail.com>
	<f7bea4a91003080936w69638e59m90035367161885d1@mail.gmail.com>
	<4B95443B.3050501@coresystems.de>
	<f7bea4a91003081245ge0d0519w62842fffb35bb0b1@mail.gmail.com>
	<4B956F71.2010001@coresystems.de>
	<f7bea4a91003081348w4e2c90b5ka0c618b621c319ee@mail.gmail.com>
	<4B95745B.9000101@coresystems.de>
	<f7bea4a91003081405v468eb152y80bb335afe6c7d7c@mail.gmail.com>
	<4B9575FC.8050907@coresystems.de>
	<f7bea4a91003090421g44717202o58915a9f51062a50@mail.gmail.com>
Message-ID: <f7bea4a91003090441h5bbe3dcbkd9b77b37e34dac53@mail.gmail.com>

Hi,

no i use crossgcc which looks fine, but still can't hang with postcode 0x23.

if have the following in crt0.disasm:
 153 0148 B023E680 		post_code(0x23)
 154              	
 155 014c E8FCFFFF 		call	stage1_main
 155      FF

and the following in romstage.inc (both from build dir):

stage1_main:
	subl	$24, %esp
/APP
/ 29 "/home/xxx/coreboot/src/cpu/intel/model_6ex/cache_as_ram_disable.c" 1
	movb	0xa4, %al
	outb	%al, $0x80

so i suppose i should at least see postcode 0xa4 if the call
instruction succeeds.

any further hints what i could have done wrong?


regards,

khn



From mylesgw at gmail.com  Tue Mar  9 15:51:31 2010
From: mylesgw at gmail.com (Myles Watson)
Date: Tue, 9 Mar 2010 07:51:31 -0700
Subject: [coreboot] Strange corruption with printk
In-Reply-To: <4B95B8BB.3060802@gmx.net>
References: <2831fecf1003081518o5b05576bx614dc0a3ca9075a8@mail.gmail.com>
	<4B959139.5070607@gmx.net> <ACC5402B33C9468D8C5A6FCF2BBA567D@chimp>
	<4B95B8BB.3060802@gmx.net>
Message-ID: <7FD3BC8A838945188BF1A285FDAA069D@chimp>



> -----Original Message-----
> From: Carl-Daniel Hailfinger [mailto:c-d.hailfinger.devel.2006 at gmx.net]
> Sent: Monday, March 08, 2010 7:56 PM
> To: Myles Watson
> Cc: 'coreboot'
> Subject: Re: [coreboot] Strange corruption with printk
> 
> On 09.03.2010 03:16, Myles Watson wrote:
> >
> >> On 09.03.2010 00:18, Myles Watson wrote:
> >>
> >>> I divided the CAR copy into pieces to debug memory corruption that I'm
> >>> seeing.  It seems to fit a pattern, but I'm not sure what would be
> >>>
> >> causing
> >>
> >>> it.  Any ideas would be appreciated.
> >>>
> >>>
> >> To be honest, if post_cache_as_ram() works at all on K8, it is mostly
> >> luck.
> >>
> > :)
> >
> >
> >> The memory copy is not inline asm (will lead to subtle
> >> corruption), the memory copy and the stack switching are not in one
> >> inline asm block (gcc is free to insert arbitrary code in between), and
> >> the stack is switched in the middle of a function (gcc may use some
> >> non-clobbered regs to access the old stack, or simply die).
Interestingly enough, the corruption is before the stack switch.  I guess
you're saying that gcc is reordering instructions so that it corrupts part
of the loop?

I'll try adding some post codes before and after the copy.  gcc shouldn't
reorder around serializing instructions, right?

> >> Throwing out the complete v2 K8 CAR disabling code and replacing it
> with
> >> the v3 code is one of the possible fixes.
> >>
> > Unfortunately, v3 never worked for K8.
> >
> 
> IIRC CAR disable worked for K8 in v3, but later K8 init failed.
> Maybe it makes more sense to modify my suggestion above to "replace some
> of the code with v3". The three-stage-CAR-disable-jump design in v3 is
> something I believe to be superior to the stack switching in v2.
> Anyway, I think that having the stack copy inside the same asm statement
> as the stack switch could probably help.
I'll look into it.

Thanks,
Myles




From komars_1605 at yahoo.com  Tue Mar  9 16:34:58 2010
From: komars_1605 at yahoo.com (Sergei Komarov)
Date: Tue, 9 Mar 2010 07:34:58 -0800 (PST)
Subject: [coreboot] DBE61 with etherboot
Message-ID: <812286.33156.qm@web110407.mail.gq1.yahoo.com>

Hello,

I am trying to setup Smartlink/Revnetek DBE61 to boot from LAN.
I am following this tutorial: http://wiki.thincan.org/Building_Coreboot_v3

Which Coreboot v3 revision should I use?
I plan on building Etherboot payload with Rom-o-matic.
Which Etherboot version must I use as a payload?

Thanks,
Sergei Komarov



      



From mylesgw at gmail.com  Tue Mar  9 17:42:42 2010
From: mylesgw at gmail.com (Myles Watson)
Date: Tue, 9 Mar 2010 09:42:42 -0700
Subject: [coreboot] Strange corruption with printk
In-Reply-To: <4B963E72.1030301@assembler.cz>
References: <2831fecf1003081518o5b05576bx614dc0a3ca9075a8@mail.gmail.com>	<4B959139.5070607@gmx.net>
	<ACC5402B33C9468D8C5A6FCF2BBA567D@chimp>
	<4B95B8BB.3060802@gmx.net> <4B963E72.1030301@assembler.cz>
Message-ID: <BB2BA90F9913411B9C5E2625D1D76608@chimp>

> >>> The memory copy is not inline asm (will lead to subtle
> >>> corruption), the memory copy and the stack switching are not in one
> >>> inline asm block (gcc is free to insert arbitrary code in between),
> and
> >>> the stack is switched in the middle of a function (gcc may use some
> >>> non-clobbered regs to access the old stack, or simply die).
> >>>
> 
> I fixed that with recent patch. Is it what you checked?
I thought I had updated since then, but it turns out that I hadn't.  One of
these days I'll look into why the build strings never update.
 
> Myles, please check
> 
> 1) If it does work without my patch ;)
No strange characters :)  It makes it fail more reliably later, which is
good.  I'll go back to debugging that.

> 2) Add the
> 
> 
> static void set_init_ram_access_uc(void)
> {
> 	set_var_mtrr(0, 0x00000000, CONFIG_RAMTOP, MTRR_TYPE_UNCACHED);
> }
> 
> 
> And call the set_init_ram_access_uc instead of set_init_ram_access and
> call
> again set_init_ram_access after the copy.
I'll look at that too.

Thanks,
Myles




From eswierk at aristanetworks.com  Tue Mar  9 17:32:15 2010
From: eswierk at aristanetworks.com (Ed Swierk)
Date: Tue, 9 Mar 2010 08:32:15 -0800
Subject: [coreboot] "How come it's so slow?"
In-Reply-To: <13426df11003050858r1c4bbe5m34514694d6e7c561@mail.gmail.com>
References: <13426df11003050858r1c4bbe5m34514694d6e7c561@mail.gmail.com>
Message-ID: <9ae48b021003090832n2baaff5bw1b4783c581b57026@mail.gmail.com>

On Fri, Mar 5, 2010 at 8:58 AM, ron minnich <rminnich at gmail.com> wrote:
> Just got a new nehalem box in for test yesterday. Experiences so far:
>
> 1. POST from power-on takes 45 seconds. *45 SECONDS*. Now, I had it
> said to me at SCALE7x last year from someone from Intel that all new
> BIOSes on Intel chips are really EFI underneath -- is this indicative
> of what we are to expect? If so, it's awful. It's 15 times slower than
> what we had ten years ago, and 50 times slower than what we can do
> today on coreboot.

As far as I can tell the sole purpose of EFI is to make it easier for
hardware vendors to shovel more junk into the BIOS by removing the
hurdle of hand-coding 16-bit assembly.

But while EFI might accelerate the trend, it's not the only villain.
Someone noticed a 9x growth in boot time on qemu recently
(http://lists.gnu.org/archive/html/qemu-devel/2010-03/msg00546.html ).
Even on a virtual platform with no actual hardware to initialize, boot
time will grow unless someone is actively pushing the other way.

Ultimately the system board vendors are responsible for the BIOS in
the boards we buy. They are the ones cutting deals with Intel and AMI
and Phoenix, and can exert the necessary leverage. But they won't,
until they see 1-second cold boot as a feature that will sell more
boards.

--Ed



From alpha2003ca at videotron.ca  Tue Mar  9 20:40:10 2010
From: alpha2003ca at videotron.ca (Miguel Ross)
Date: Tue, 09 Mar 2010 14:40:10 -0500
Subject: [coreboot]  dell gx270
References: <2831fecf1003081518o5b05576bx614dc0a3ca9075a8@mail.gmail.com>
	<4B959139.5070607@gmx.net> <ACC5402B33C9468D8C5A6FCF2BBA567D@chimp>
	<4B95B8BB.3060802@gmx.net> <7FD3BC8A838945188BF1A285FDAA069D@chimp>
Message-ID: <4A3EF6E1DAFA433ABC8824A31C3058B6@declick17prog>

is this possible coreboot works on dell gx270



From svn at coreboot.org  Tue Mar  9 22:51:31 2010
From: svn at coreboot.org (repository service)
Date: Tue, 09 Mar 2010 22:51:31 +0100
Subject: [coreboot] [commit] r5199 - trunk/src/southbridge/amd/sb600
Message-ID: <E1Np7Kt-0005dH-PV@ra.coresystems.de>

Author: mjones
Date: Tue Mar  9 22:51:31 2010
New Revision: 5199
URL: http://tracker.coreboot.org/trac/coreboot/changeset/5199

Log:
sb600 has problems with the virtual wire mode setup in setup_ioapic(). It causes problems when interrupts are enabled (specifically timer).
Previously the sb600 setup was equivalent to clear_ioapic(), so that is what we will do for now.

Signed-off-by: Marc Jones <marcj303 at gmail.com>
Acked-by: Stefan Reinauer <stepan at coresystems.de>

Modified:
   trunk/src/southbridge/amd/sb600/sb600_sm.c

Modified: trunk/src/southbridge/amd/sb600/sb600_sm.c
==============================================================================
--- trunk/src/southbridge/amd/sb600/sb600_sm.c	Tue Mar  9 00:44:30 2010	(r5198)
+++ trunk/src/southbridge/amd/sb600/sb600_sm.c	Tue Mar  9 22:51:31 2010	(r5199)
@@ -58,7 +58,7 @@
 
 	ioapic_base = pci_read_config32(dev, 0x74) & (0xffffffe0);	/* some like mem resource, but does not have  enable bit */
 	/* Don't rename APIC ID */
-	setup_ioapic(ioapic_base, 0);
+	clear_ioapic(ioapic_base);
 
 	dword = pci_read_config8(dev, 0x62);
 	dword |= 1 << 2;



From marcj303 at gmail.com  Tue Mar  9 22:52:03 2010
From: marcj303 at gmail.com (Marc Jones)
Date: Tue, 9 Mar 2010 14:52:03 -0700
Subject: [coreboot] [PATCH]: Disable ExtINT in ioapic.c
In-Reply-To: <4B9221E2.1070708@coresystems.de>
References: <DD1CC71B621B004FA76856E5129D6B17036DA956@sbjgexmb1.amd.com>
	<4B68D414.9030500@coresystems.de>
	<534e5dc21003051402h7aec7dbdl80bd7d5a5ede4966@mail.gmail.com>
	<4B9221E2.1070708@coresystems.de>
Message-ID: <534e5dc21003091352v6f94d336ra3719ddc7840f4fc@mail.gmail.com>

On Sat, Mar 6, 2010 at 2:35 AM, Stefan Reinauer <stepan at coresystems.de> wrote:
> On 3/5/10 11:02 PM, Marc Jones wrote:
>> You are right. The sb600 was really doing a clear_ioapic() previously.
>> I don't yet understand why the virtual wire mode causes problems. It
>> is either an additional sb600 setup issue or a mainboard problem with
>> how EXTINT is connected. The setup_ioapic() should probably have more
>> options as EXTINT doesn't have to be connected to the APIC.
>>
>> Signed-off-by: Marc Jones <marcj303 at gmail.com>
>>
>> Marc
>>
> Acked-by: Stefan Reinauer <stepan at coresystems.de>
>

r5199

Thanks,
Marc



-- 
http://se-eng.com



From Zheng.Bao at amd.com  Wed Mar 10 04:30:25 2010
From: Zheng.Bao at amd.com (Bao, Zheng)
Date: Wed, 10 Mar 2010 11:30:25 +0800
Subject: [coreboot] [PATCH] Istanbul support
In-Reply-To: <4B9117ED.5020807@numascale.com>
References: <4B9117ED.5020807@numascale.com>
Message-ID: <DD1CC71B621B004FA76856E5129D6B170382671B@sbjgexmb1.amd.com>

index ac62981..067560d 100644
--- a/src/cpu/amd/quadcore/quadcore.c
+++ b/src/cpu/amd/quadcore/quadcore.c
@@ -69,11 +72,10 @@ static void real_start_other_core(u32 nodeid, u32
cores)
 
 	if(cores > 1) {
 		dword = pci_read_config32(NODE_PCI(nodeid, 0), 0x168);
-		dword |= (1 << 0);	// core2
-		if(cores > 2) {		// core3
-			dword |= (1 << 1);
+		for (i = 0; i < cores - 1; i++) {
+			dword |= 1 << i;
+			pci_write_config32(NODE_PCI(nodeid, 0), 0x168,
dword);
 		}
-		pci_write_config32(NODE_PCI(nodeid, 0), 0x168, dword);
 	}
 }

I assume the line
pci_write_config32(NODE_PCI(nodeid, 0), 0x168, dword);
should be put outside the loop.

Everything seems to be fine. I don't have Istanbul to test. I have read
every changes and they all look good.

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



> -----Original Message-----
> From: coreboot-bounces at coreboot.org
[mailto:coreboot-bounces at coreboot.org]
> On Behalf Of Arne Georg Gleditsch
> Sent: Friday, March 05, 2010 10:41 PM
> To: coreboot at coreboot.org
> Subject: [coreboot] [PATCH] Istanbul support
> 
> Hi,
> 
> The following patch implements Opteron Fam 10 rev D (aka Istanbul)
> support for coreboot.  I have not updated MAX_CPUS for all fam10
> mainboards, but it might make sense to multiply those by 1.5.
> 
> Signed-off-by: Arne Georg Gleditsch <arne.gleditsch at numascale.com>
> 
> --
> 								Arne.




From Zheng.Bao at amd.com  Wed Mar 10 04:39:26 2010
From: Zheng.Bao at amd.com (Bao, Zheng)
Date: Wed, 10 Mar 2010 11:39:26 +0800
Subject: [coreboot] [PATCH] Istanbul support
In-Reply-To: <4B9117ED.5020807@numascale.com>
References: <4B9117ED.5020807@numascale.com>
Message-ID: <DD1CC71B621B004FA76856E5129D6B1703826726@sbjgexmb1.amd.com>

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


> -----Original Message-----
> From: coreboot-bounces at coreboot.org
[mailto:coreboot-bounces at coreboot.org]
> On Behalf Of Arne Georg Gleditsch
> Sent: Friday, March 05, 2010 10:41 PM
> To: coreboot at coreboot.org
> Subject: [coreboot] [PATCH] Istanbul support
> 
> Hi,
> 
> The following patch implements Opteron Fam 10 rev D (aka Istanbul)
> support for coreboot.  I have not updated MAX_CPUS for all fam10
> mainboards, but it might make sense to multiply those by 1.5.
> 
> Signed-off-by: Arne Georg Gleditsch <arne.gleditsch at numascale.com>
> 
> --
> 								Arne.




From svn at coreboot.org  Wed Mar 10 04:43:06 2010
From: svn at coreboot.org (repository service)
Date: Wed, 10 Mar 2010 04:43:06 +0100
Subject: [coreboot] [commit] r5200 - in trunk/src: cpu/amd/model_10xxx
	cpu/amd/quadcore northbridge/amd/amdfam10 northbridge/amd/amdmct
Message-ID: <E1NpCp8-0000dM-9M@ra.coresystems.de>

Author: zbao
Date: Wed Mar 10 04:43:05 2010
New Revision: 5200
URL: http://tracker.coreboot.org/trac/coreboot/changeset/5200

Log:
The following patch implements Opteron Fam 10 rev D (aka Istanbul)
support for coreboot.  I have not updated MAX_CPUS for all fam10
mainboards, but it might make sense to multiply those by 1.5.

Signed-off-by: Arne Georg Gleditsch <arne.gleditsch at numascale.com>


I assume the line
pci_write_config32(NODE_PCI(nodeid, 0), 0x168, dword);
should be put outside the loop.

Everything seems to be fine. I don't have Istanbul to test. I have
read every changes and they all look good.

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

Modified:
   trunk/src/cpu/amd/model_10xxx/defaults.h
   trunk/src/cpu/amd/model_10xxx/model_10xxx_init.c
   trunk/src/cpu/amd/quadcore/quadcore.c
   trunk/src/northbridge/amd/amdfam10/northbridge.c
   trunk/src/northbridge/amd/amdfam10/raminit_amdmct.c
   trunk/src/northbridge/amd/amdmct/amddefs.h

Modified: trunk/src/cpu/amd/model_10xxx/defaults.h
==============================================================================
--- trunk/src/cpu/amd/model_10xxx/defaults.h	Tue Mar  9 22:51:31 2010	(r5199)
+++ trunk/src/cpu/amd/model_10xxx/defaults.h	Wed Mar 10 04:43:05 2010	(r5200)
@@ -315,44 +315,44 @@
 	u32 mask;
 } fam10_htphy_default[] = {
 
-	/* Errata 344 - Fam10 C2
+	/* Errata 344 - Fam10 C2/D0
 	 * System software should set bit 6 of F4x1[9C, 94, 8C, 84]_x[78:70, 68:60]. */
-	{ 0x60, AMD_RB_C2 | AMD_DA_C2, AMD_PTYPE_ALL, HTPHY_LINKTYPE_ALL,
+	{ 0x60, AMD_RB_C2 | AMD_DA_C2 | AMD_HY_D0, AMD_PTYPE_ALL, HTPHY_LINKTYPE_ALL,
 	  0x00000040, 0x00000040 },
-	{ 0x61, AMD_RB_C2 | AMD_DA_C2, AMD_PTYPE_ALL, HTPHY_LINKTYPE_ALL,
+	{ 0x61, AMD_RB_C2 | AMD_DA_C2 | AMD_HY_D0, AMD_PTYPE_ALL, HTPHY_LINKTYPE_ALL,
 	  0x00000040, 0x00000040 },
-	{ 0x62, AMD_RB_C2 | AMD_DA_C2, AMD_PTYPE_ALL, HTPHY_LINKTYPE_ALL,
+	{ 0x62, AMD_RB_C2 | AMD_DA_C2 | AMD_HY_D0, AMD_PTYPE_ALL, HTPHY_LINKTYPE_ALL,
 	  0x00000040, 0x00000040 },
-	{ 0x63, AMD_RB_C2 | AMD_DA_C2, AMD_PTYPE_ALL, HTPHY_LINKTYPE_ALL,
+	{ 0x63, AMD_RB_C2 | AMD_DA_C2 | AMD_HY_D0, AMD_PTYPE_ALL, HTPHY_LINKTYPE_ALL,
 	  0x00000040, 0x00000040 },
-	{ 0x64, AMD_RB_C2 | AMD_DA_C2, AMD_PTYPE_ALL, HTPHY_LINKTYPE_ALL,
+	{ 0x64, AMD_RB_C2 | AMD_DA_C2 | AMD_HY_D0, AMD_PTYPE_ALL, HTPHY_LINKTYPE_ALL,
 	  0x00000040, 0x00000040 },
-	{ 0x65, AMD_RB_C2 | AMD_DA_C2, AMD_PTYPE_ALL, HTPHY_LINKTYPE_ALL,
+	{ 0x65, AMD_RB_C2 | AMD_DA_C2 | AMD_HY_D0, AMD_PTYPE_ALL, HTPHY_LINKTYPE_ALL,
 	  0x00000040, 0x00000040 },
-	{ 0x66, AMD_RB_C2 | AMD_DA_C2, AMD_PTYPE_ALL, HTPHY_LINKTYPE_ALL,
+	{ 0x66, AMD_RB_C2 | AMD_DA_C2 | AMD_HY_D0, AMD_PTYPE_ALL, HTPHY_LINKTYPE_ALL,
 	  0x00000040, 0x00000040 },
-	{ 0x67, AMD_RB_C2 | AMD_DA_C2, AMD_PTYPE_ALL, HTPHY_LINKTYPE_ALL,
+	{ 0x67, AMD_RB_C2 | AMD_DA_C2 | AMD_HY_D0, AMD_PTYPE_ALL, HTPHY_LINKTYPE_ALL,
 	  0x00000040, 0x00000040 },
-	{ 0x68, AMD_RB_C2 | AMD_DA_C2, AMD_PTYPE_ALL, HTPHY_LINKTYPE_ALL,
+	{ 0x68, AMD_RB_C2 | AMD_DA_C2 | AMD_HY_D0, AMD_PTYPE_ALL, HTPHY_LINKTYPE_ALL,
 	  0x00000040, 0x00000040 },
 
-	{ 0x70, AMD_RB_C2 | AMD_DA_C2, AMD_PTYPE_ALL, HTPHY_LINKTYPE_ALL,
+	{ 0x70, AMD_RB_C2 | AMD_DA_C2 | AMD_HY_D0, AMD_PTYPE_ALL, HTPHY_LINKTYPE_ALL,
 	  0x00000040, 0x00000040 },
-	{ 0x71, AMD_RB_C2 | AMD_DA_C2, AMD_PTYPE_ALL, HTPHY_LINKTYPE_ALL,
+	{ 0x71, AMD_RB_C2 | AMD_DA_C2 | AMD_HY_D0, AMD_PTYPE_ALL, HTPHY_LINKTYPE_ALL,
 	  0x00000040, 0x00000040 },
-	{ 0x72, AMD_RB_C2 | AMD_DA_C2, AMD_PTYPE_ALL, HTPHY_LINKTYPE_ALL,
+	{ 0x72, AMD_RB_C2 | AMD_DA_C2 | AMD_HY_D0, AMD_PTYPE_ALL, HTPHY_LINKTYPE_ALL,
 	  0x00000040, 0x00000040 },
-	{ 0x73, AMD_RB_C2 | AMD_DA_C2, AMD_PTYPE_ALL, HTPHY_LINKTYPE_ALL,
+	{ 0x73, AMD_RB_C2 | AMD_DA_C2 | AMD_HY_D0, AMD_PTYPE_ALL, HTPHY_LINKTYPE_ALL,
 	  0x00000040, 0x00000040 },
-	{ 0x74, AMD_RB_C2 | AMD_DA_C2, AMD_PTYPE_ALL, HTPHY_LINKTYPE_ALL,
+	{ 0x74, AMD_RB_C2 | AMD_DA_C2 | AMD_HY_D0, AMD_PTYPE_ALL, HTPHY_LINKTYPE_ALL,
 	  0x00000040, 0x00000040 },
-	{ 0x75, AMD_RB_C2 | AMD_DA_C2, AMD_PTYPE_ALL, HTPHY_LINKTYPE_ALL,
+	{ 0x75, AMD_RB_C2 | AMD_DA_C2 | AMD_HY_D0, AMD_PTYPE_ALL, HTPHY_LINKTYPE_ALL,
 	  0x00000040, 0x00000040 },
-	{ 0x76, AMD_RB_C2 | AMD_DA_C2, AMD_PTYPE_ALL, HTPHY_LINKTYPE_ALL,
+	{ 0x76, AMD_RB_C2 | AMD_DA_C2 | AMD_HY_D0, AMD_PTYPE_ALL, HTPHY_LINKTYPE_ALL,
 	  0x00000040, 0x00000040 },
-	{ 0x77, AMD_RB_C2 | AMD_DA_C2, AMD_PTYPE_ALL, HTPHY_LINKTYPE_ALL,
+	{ 0x77, AMD_RB_C2 | AMD_DA_C2 | AMD_HY_D0, AMD_PTYPE_ALL, HTPHY_LINKTYPE_ALL,
 	  0x00000040, 0x00000040 },
-	{ 0x78, AMD_RB_C2 | AMD_DA_C2, AMD_PTYPE_ALL, HTPHY_LINKTYPE_ALL,
+	{ 0x78, AMD_RB_C2 | AMD_DA_C2 | AMD_HY_D0, AMD_PTYPE_ALL, HTPHY_LINKTYPE_ALL,
 	  0x00000040, 0x00000040 },
 
 	/* Errata 354 - Fam10 C2
@@ -395,20 +395,20 @@
 	{ 0x58, AMD_RB_C2 | AMD_DA_C2, AMD_PTYPE_ALL, HTPHY_LINKTYPE_ALL,
 	  0x00000040, 0x00000040 },
 
-	/* Errata 327 - Fam10 C2
+	/* Errata 327 - Fam10 C2/D0
 	 * BIOS should set the Link Phy Impedance Register[RttCtl]
 	 * (F4x1[9C, 94, 8C, 84]_x[D0, C0][31:29]) to 010b and
 	 * Link Phy Impedance Register[RttIndex]
 	 * (F4x1[9C, 94, 8C, 84]_x[D0, C0][20:16]) to 00100b */
-	{ 0xC0, AMD_RB_C2 | AMD_DA_C2, AMD_PTYPE_ALL, HTPHY_LINKTYPE_ALL,
+	{ 0xC0, AMD_RB_C2 | AMD_DA_C2 | AMD_HY_D0, AMD_PTYPE_ALL, HTPHY_LINKTYPE_ALL,
 	  0x40040000, 0xe01F0000 },
-	{ 0xD0, AMD_RB_C2 | AMD_DA_C2, AMD_PTYPE_ALL, HTPHY_LINKTYPE_ALL,
+	{ 0xD0, AMD_RB_C2 | AMD_DA_C2 | AMD_HY_D0, AMD_PTYPE_ALL, HTPHY_LINKTYPE_ALL,
 	  0x40040000, 0xe01F0000 },
 
-	{ 0x520A, AMD_RB_C2 | AMD_DA_C2, AMD_PTYPE_ALL, HTPHY_LINKTYPE_ALL,
+	{ 0x520A, AMD_RB_C2 | AMD_DA_C2 | AMD_HY_D0, AMD_PTYPE_ALL, HTPHY_LINKTYPE_ALL,
 	  0x00004000, 0x00006000 },	/* HT_PHY_DLL_REG */
 
-	{ 0x530A, AMD_RB_C2 | AMD_DA_C2, AMD_PTYPE_ALL, HTPHY_LINKTYPE_ALL,
+	{ 0x530A, AMD_RB_C2 | AMD_DA_C2 | AMD_HY_D0, AMD_PTYPE_ALL, HTPHY_LINKTYPE_ALL,
 	  0x00004000, 0x00006000 },	/* HT_PHY_DLL_REG */
 
 	{ 0x520A, AMD_DR_ALL, AMD_PTYPE_ALL, HTPHY_LINKTYPE_ALL,

Modified: trunk/src/cpu/amd/model_10xxx/model_10xxx_init.c
==============================================================================
--- trunk/src/cpu/amd/model_10xxx/model_10xxx_init.c	Tue Mar  9 22:51:31 2010	(r5199)
+++ trunk/src/cpu/amd/model_10xxx/model_10xxx_init.c	Wed Mar 10 04:43:05 2010	(r5200)
@@ -146,6 +146,7 @@
 	{ X86_VENDOR_AMD, 0x100F42 },           /* RB-C2 */ 
 	{ X86_VENDOR_AMD, 0x100F52 },           /* BL-C2 */ 
 	{ X86_VENDOR_AMD, 0x100F62 },           /* DA-C2 */ 
+	{ X86_VENDOR_AMD, 0x100F80 },           /* HY-D0 */ 
 	{ 0, 0 },
 };
 static struct cpu_driver model_10xxx __cpu_driver = {

Modified: trunk/src/cpu/amd/quadcore/quadcore.c
==============================================================================
--- trunk/src/cpu/amd/quadcore/quadcore.c	Tue Mar  9 22:51:31 2010	(r5199)
+++ trunk/src/cpu/amd/quadcore/quadcore.c	Wed Mar 10 04:43:05 2010	(r5200)
@@ -29,7 +29,11 @@
 	u32 dword;
 	dword = pci_read_config32(NODE_PCI(nodeid, 3), 0xe8);
 	dword >>= 12;
-	dword &= 3;
+	/* Bit 15 is CmpCap[2] since Revision D. */
+	if ((cpuid_ecx(0x80000008) & 0xff) > 3)
+	    dword = ((dword & 8) >> 1) | (dword & 3);
+	else
+	    dword &= 3;
 	return dword;
 }
 
@@ -53,7 +57,7 @@
 
 static void real_start_other_core(u32 nodeid, u32 cores)
 {
-	u32 dword;
+	u32 dword, i;
 
 	printk_debug("Start other core - nodeid: %02x  cores: %02x\n", nodeid, cores);
 
@@ -69,9 +73,8 @@
 
 	if(cores > 1) {
 		dword = pci_read_config32(NODE_PCI(nodeid, 0), 0x168);
-		dword |= (1 << 0);	// core2
-		if(cores > 2) {		// core3
-			dword |= (1 << 1);
+		for (i = 0; i < cores - 1; i++) {
+			dword |= 1 << i;
 		}
 		pci_write_config32(NODE_PCI(nodeid, 0), 0x168, dword);
 	}

Modified: trunk/src/northbridge/amd/amdfam10/northbridge.c
==============================================================================
--- trunk/src/northbridge/amd/amdfam10/northbridge.c	Tue Mar  9 22:51:31 2010	(r5199)
+++ trunk/src/northbridge/amd/amdfam10/northbridge.c	Wed Mar 10 04:43:05 2010	(r5200)
@@ -1364,6 +1364,8 @@
 		if (dev && dev->enabled) {
 			j = pci_read_config32(dev, 0xe8);
 			cores_found = (j >> 12) & 3; // dev is func 3
+			if (siblings > 3)
+				cores_found |= (j >> 13) & 4;
 			printk_debug("  %s siblings=%d\n", dev_path(dev), cores_found);
 		}
 

Modified: trunk/src/northbridge/amd/amdfam10/raminit_amdmct.c
==============================================================================
--- trunk/src/northbridge/amd/amdfam10/raminit_amdmct.c	Tue Mar  9 22:51:31 2010	(r5199)
+++ trunk/src/northbridge/amd/amdfam10/raminit_amdmct.c	Wed Mar 10 04:43:05 2010	(r5200)
@@ -150,6 +150,9 @@
 	case 0x10062:
 		ret = AMD_DA_C2;
 		break;
+	case 0x10080:
+		ret = AMD_HY_D0;
+		break;
 	default:
 		/* FIXME: mabe we should die() here. */
 		print_err("FIXME! CPU Version unknown or not supported! \n");

Modified: trunk/src/northbridge/amd/amdmct/amddefs.h
==============================================================================
--- trunk/src/northbridge/amd/amdmct/amddefs.h	Tue Mar  9 22:51:31 2010	(r5199)
+++ trunk/src/northbridge/amd/amdmct/amddefs.h	Wed Mar 10 04:43:05 2010	(r5200)
@@ -42,6 +42,7 @@
 #define	AMD_DR_B3	0x00800000	/* Barcelona B3 */
 #define	AMD_RB_C2	0x01000000	/* Shanghai C2 */
 #define	AMD_DA_C2	0x02000000	/* XXXX C2 */
+#define	AMD_HY_D0	0x04000000	/* Istanbul D0 */
 
 /*
  * Groups - Create as many as you wish, from the above public values
@@ -59,7 +60,7 @@
 #define	AMD_DR_LT_B3	(AMD_DR_B0 | AMD_DR_B1 | AMD_DR_B2 | AMD_DR_BA)
 #define	AMD_DR_GT_B0	(AMD_DR_ALL & ~(AMD_DR_B0))
 #define	AMD_DR_ALL	(AMD_DR_Bx)
-#define	AMD_FAM10_ALL	(AMD_DR_ALL | AMD_RB_C2)
+#define	AMD_FAM10_ALL	(AMD_DR_ALL | AMD_RB_C2 | AMD_HY_D0)
 #define	AMD_FAM10_GT_B0	(AMD_FAM10_ALL & ~(AMD_DR_B0))
 
 /*



From Zheng.Bao at amd.com  Wed Mar 10 06:03:55 2010
From: Zheng.Bao at amd.com (Bao, Zheng)
Date: Wed, 10 Mar 2010 13:03:55 +0800
Subject: [coreboot] [PATCH] Istanbul support
In-Reply-To: <DD1CC71B621B004FA76856E5129D6B1703826726@sbjgexmb1.amd.com>
References: <4B9117ED.5020807@numascale.com>
	<DD1CC71B621B004FA76856E5129D6B1703826726@sbjgexmb1.amd.com>
Message-ID: <DD1CC71B621B004FA76856E5129D6B1703826761@sbjgexmb1.amd.com>

r5200.


> -----Original Message-----
> From: coreboot-bounces at coreboot.org
[mailto:coreboot-bounces at coreboot.org]
> On Behalf Of Bao, Zheng
> Sent: Wednesday, March 10, 2010 11:39 AM
> To: Arne Georg Gleditsch
> Cc: coreboot at coreboot.org
> Subject: Re: [coreboot] [PATCH] Istanbul support
> 
> Acked-by: Zheng Bao <zheng.bao at amd.com>
> 
> 
> > -----Original Message-----
> > From: coreboot-bounces at coreboot.org
> [mailto:coreboot-bounces at coreboot.org]
> > On Behalf Of Arne Georg Gleditsch
> > Sent: Friday, March 05, 2010 10:41 PM
> > To: coreboot at coreboot.org
> > Subject: [coreboot] [PATCH] Istanbul support
> >
> > Hi,
> >
> > The following patch implements Opteron Fam 10 rev D (aka Istanbul)
> > support for coreboot.  I have not updated MAX_CPUS for all fam10
> > mainboards, but it might make sense to multiply those by 1.5.
> >
> > Signed-off-by: Arne Georg Gleditsch <arne.gleditsch at numascale.com>
> >
> > --
> > 								Arne.
> 
> 
> --
> coreboot mailing list: coreboot at coreboot.org
> http://www.coreboot.org/mailman/listinfo/coreboot





From arne.gleditsch at numascale.com  Wed Mar 10 08:27:15 2010
From: arne.gleditsch at numascale.com (Arne Georg Gleditsch)
Date: Wed, 10 Mar 2010 08:27:15 +0100
Subject: [coreboot] [PATCH] Istanbul support
In-Reply-To: <DD1CC71B621B004FA76856E5129D6B170382671B@sbjgexmb1.amd.com>
References: <4B9117ED.5020807@numascale.com>
	<DD1CC71B621B004FA76856E5129D6B170382671B@sbjgexmb1.amd.com>
Message-ID: <4B9749D3.4040508@numascale.com>

On 10. mars 2010 04:30, Bao, Zheng wrote:
> index ac62981..067560d 100644
> --- a/src/cpu/amd/quadcore/quadcore.c
> +++ b/src/cpu/amd/quadcore/quadcore.c
> @@ -69,11 +72,10 @@ static void real_start_other_core(u32 nodeid, u32
> cores)
>  
>  	if(cores > 1) {
>  		dword = pci_read_config32(NODE_PCI(nodeid, 0), 0x168);
> -		dword |= (1 << 0);	// core2
> -		if(cores > 2) {		// core3
> -			dword |= (1 << 1);
> +		for (i = 0; i < cores - 1; i++) {
> +			dword |= 1 << i;
> +			pci_write_config32(NODE_PCI(nodeid, 0), 0x168,
> dword);
>  		}
> -		pci_write_config32(NODE_PCI(nodeid, 0), 0x168, dword);
>  	}
>  }
> 
> I assume the line
> pci_write_config32(NODE_PCI(nodeid, 0), 0x168, dword);
> should be put outside the loop.

Yes, well, I originally had that as "dword |= (0xf >> (5-cores);
pci_write_config32(..)" or something.  However, after reducing the
loglevel below "debug" and encountering hangs that seemed to be conflict
issues with the core startup, I added the loop to be able to add delays
between startup of the individual cores during debugging.  As it stands,
the write could just as well be outside the loop.

Regarding hangs, I suspect this might be a PCI config race condition
between the cores.  I tried to adjust my configuration to use MMCONFIG
to address this.  It didn't seem to be supported out of the box, and I
didn't have the time to look into it further at the moment.  I still
intend to do so, but it would be nice to know if anyone is using
MMCONFIG with fam10 configurations.  Is it supposed to work?

-- 
								Arne.



From patrick at georgi-clan.de  Wed Mar 10 09:57:37 2010
From: patrick at georgi-clan.de (Patrick Georgi)
Date: Wed, 10 Mar 2010 09:57:37 +0100
Subject: [coreboot] [PATCH] revive llshell
In-Reply-To: <4B93BAC9.2070900@coresystems.de>
References: <4B93BAC9.2070900@coresystems.de>
Message-ID: <4B975F01.8050509@georgi-clan.de>

Am 07.03.2010 15:40, schrieb Stefan Reinauer:
> Ron and Peter should like this.... "Panic Room" there you go.
> 
> It's of course completely useless if the machine hangs. It could be made
> part of "die()" though.
Maybe guard the Kconfig option with "depends on CONFIG_EXPERT"?

With or without, it's
Acked-by: Patrick Georgi <patrick.georgi at coresystems.de>



From knuku at gap.upv.es  Wed Mar 10 17:26:47 2010
From: knuku at gap.upv.es (Knut Kujat)
Date: Wed, 10 Mar 2010 17:26:47 +0100
Subject: [coreboot] Supermicro H8QME-2+ mct_d fatal exit.
In-Reply-To: <4B94E384.4060002@gap.upv.es>
References: <4B87CF9D.9060204@gap.upv.es>	<201002261506.46602.christian.leber@ziti.uni-heidelberg.de>	<4B87DEFE.3010604@gap.upv.es>	<20100226154934.5727.qmail@stuge.se>	<4B8BC18D.1050400@gap.upv.es>	<4B8FC877.4030209@gap.upv.es>	<4B91295B.9060102@assembler.cz>	<4B912FE4.7080204@gap.upv.es>	<4B913A01.4090103@assembler.cz>	<13426df11003051007r29fee819p2fdea852891a4b58@mail.gmail.com>
	<4B94E384.4060002@gap.upv.es>
Message-ID: <4B97C847.5070506@gap.upv.es>

Hi,

I finally know that my issue must be related with the smbus registers
because on a vendor bios running machine and using i2cdetect and i2cdump
I get several values for different i2c devices detected, I get the same
values when I successfully start with coreboot. But when I start with
coreboot and fail with mcr_d fatal exit those registers are blank, I
know that because I found a nice piece of code dumping smbus registers
on the h8dme board :D thx to the autor!!

I also know that reading these registers out may cause them to get lost!
I'm not sure why?!

Now my question is how do I initialize these registers with the values
known from the vendor BIOS? smb_write_byte doesn't seems to work or
maybe I'm using it wrong.

THX,
Knut Kujat.



Knut Kujat escribi?:
> Hello,
>
> thx all of you for your comments. Here a little update :)
>
> I now know why the boards worked just fine up here in my lab. To know if
> the board would work after being unplugged I always "only" unplugged the
> electrical cable but never the monitor attached to the board I figured
> out that the monitor is providing enough juice to maintain whatever
> alive in the board so after plugging the electrical cable on again
> coreboot started fine. Another thing I figured out is that it seems that
> the front leds of the board a managed by GPIO as well, is this right? If
> so it seems that something is wrong with GPIO because the power on led
> never works with coreboot.
>
> thx,
> Knut Kujat.
>
>
>
> ron minnich escribi?:
>   
>> Just FYI:
>>
>> on our first system with Arima boards in 2002, everything worked well
>> until we started booting 64-bit kernels. I'm not kidding. We did not
>> find the SMBUS MUX on the boards until we had unreliable coreboot
>> boots of 64-bit kernels. For quite some time the boards worked fine.
>> Ollie found the SMBUS MUX by examining schematics.
>>
>> So the SMBUS mux can appear in strange ways, at strange times. This
>> sounds like one of those times. SMBUS muxes are more common than you
>> might think and the default power-on state is not always very well
>> determined.
>>
>> ron
>>
>>   
>>     
>
>
>   




From paulepanter at users.sourceforge.net  Wed Mar 10 18:26:35 2010
From: paulepanter at users.sourceforge.net (Paul Menzel)
Date: Wed, 10 Mar 2010 18:26:35 +0100
Subject: [coreboot] Supermicro H8QME-2+: Dumping smbus registers (was:
 Supermicro H8QME-2+ mct_d fatal exit.)
In-Reply-To: <4B97C847.5070506@gap.upv.es>
References: <4B87CF9D.9060204@gap.upv.es>
	<201002261506.46602.christian.leber@ziti.uni-heidelberg.de>
	<4B87DEFE.3010604@gap.upv.es>	<20100226154934.5727.qmail@stuge.se>
	<4B8BC18D.1050400@gap.upv.es>	<4B8FC877.4030209@gap.upv.es>
	<4B91295B.9060102@assembler.cz>	<4B912FE4.7080204@gap.upv.es>
	<4B913A01.4090103@assembler.cz>
	<13426df11003051007r29fee819p2fdea852891a4b58@mail.gmail.com>
	<4B94E384.4060002@gap.upv.es>  <4B97C847.5070506@gap.upv.es>
Message-ID: <1268241995.3876.1.camel@mattotaupa>

Dear Knut,


Am Mittwoch, den 10.03.2010, 17:26 +0100 schrieb Knut Kujat:

[?]

> I know that because I found a nice piece of code dumping smbus registers
> on the h8dme board :D thx to the autor!!

is it possible to share that piece of code?

[?]

Anyway, nice to hear you ar making some progress and good luck with the
next steps!


Thanks,

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

From darmawan.salihun at gmail.com  Wed Mar 10 18:20:29 2010
From: darmawan.salihun at gmail.com (Darmawan Salihun)
Date: Thu, 11 Mar 2010 00:20:29 +0700
Subject: [coreboot] "How come it's so slow?"
In-Reply-To: <9ae48b021003090832n2baaff5bw1b4783c581b57026@mail.gmail.com>
References: <13426df11003050858r1c4bbe5m34514694d6e7c561@mail.gmail.com>
	<9ae48b021003090832n2baaff5bw1b4783c581b57026@mail.gmail.com>
Message-ID: <46893e741003100920x4d2790f7y27afe192eabcd6bf@mail.gmail.com>

I think every UEFI/EFI implementation will boot to "old school" boot
mode when it can't find any EFI/UEFI-compliant
boot-device/boot-partition. It would take too long though but at least
the fallback is there.

-Darmawan

On 3/9/10, Ed Swierk <eswierk at aristanetworks.com> wrote:
> On Fri, Mar 5, 2010 at 8:58 AM, ron minnich <rminnich at gmail.com> wrote:
>> Just got a new nehalem box in for test yesterday. Experiences so far:
>>
>> 1. POST from power-on takes 45 seconds. *45 SECONDS*. Now, I had it
>> said to me at SCALE7x last year from someone from Intel that all new
>> BIOSes on Intel chips are really EFI underneath -- is this indicative
>> of what we are to expect? If so, it's awful. It's 15 times slower than
>> what we had ten years ago, and 50 times slower than what we can do
>> today on coreboot.
>
> As far as I can tell the sole purpose of EFI is to make it easier for
> hardware vendors to shovel more junk into the BIOS by removing the
> hurdle of hand-coding 16-bit assembly.
>
> But while EFI might accelerate the trend, it's not the only villain.
> Someone noticed a 9x growth in boot time on qemu recently
> (http://lists.gnu.org/archive/html/qemu-devel/2010-03/msg00546.html ).
> Even on a virtual platform with no actual hardware to initialize, boot
> time will grow unless someone is actively pushing the other way.
>
> Ultimately the system board vendors are responsible for the BIOS in
> the boards we buy. They are the ones cutting deals with Intel and AMI
> and Phoenix, and can exert the necessary leverage. But they won't,
> until they see 1-second cold boot as a feature that will sell more
> boards.
>
> --Ed
>
> --
> coreboot mailing list: coreboot at coreboot.org
> http://www.coreboot.org/mailman/listinfo/coreboot
>


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



From darmawan.salihun at gmail.com  Wed Mar 10 18:23:42 2010
From: darmawan.salihun at gmail.com (Darmawan Salihun)
Date: Thu, 11 Mar 2010 00:23:42 +0700
Subject: [coreboot] "How come it's so slow?"
In-Reply-To: <46893e741003100920x4d2790f7y27afe192eabcd6bf@mail.gmail.com>
References: <13426df11003050858r1c4bbe5m34514694d6e7c561@mail.gmail.com>
	<9ae48b021003090832n2baaff5bw1b4783c581b57026@mail.gmail.com>
	<46893e741003100920x4d2790f7y27afe192eabcd6bf@mail.gmail.com>
Message-ID: <46893e741003100923p477b7d85yddf761c951ae87d5@mail.gmail.com>

> On 3/9/10, Ed Swierk <eswierk at aristanetworks.com> wrote:
>> On Fri, Mar 5, 2010 at 8:58 AM, ron minnich <rminnich at gmail.com> wrote:
>>> Just got a new nehalem box in for test yesterday. Experiences so far:
>>>
>>> 1. POST from power-on takes 45 seconds. *45 SECONDS*. Now, I had it
>>> said to me at SCALE7x last year from someone from Intel that all new
>>> BIOSes on Intel chips are really EFI underneath -- is this indicative
>>> of what we are to expect? If so, it's awful. It's 15 times slower than
>>> what we had ten years ago, and 50 times slower than what we can do
>>> today on coreboot.
>>
>> As far as I can tell the sole purpose of EFI is to make it easier for
>> hardware vendors to shovel more junk into the BIOS by removing the
>> hurdle of hand-coding 16-bit assembly.
>>
>> But while EFI might accelerate the trend, it's not the only villain.
>> Someone noticed a 9x growth in boot time on qemu recently
>> (http://lists.gnu.org/archive/html/qemu-devel/2010-03/msg00546.html ).
>> Even on a virtual platform with no actual hardware to initialize, boot
>> time will grow unless someone is actively pushing the other way.
>>
>> Ultimately the system board vendors are responsible for the BIOS in
>> the boards we buy. They are the ones cutting deals with Intel and AMI
>> and Phoenix, and can exert the necessary leverage. But they won't,
>> until they see 1-second cold boot as a feature that will sell more
>> boards.
>>
>> --Ed
>>

Sorry about the double post. Something went wrong with my mail client.

Anyway, perhaps these articles by vid is a nice addition:
http://x86asm.net/articles/introduction-to-uefi/index.html
http://x86asm.net/articles/uefi-programming-first-steps/index.html


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



From buurin at gmail.com  Thu Mar 11 04:25:43 2010
From: buurin at gmail.com (Keith Hui)
Date: Wed, 10 Mar 2010 22:25:43 -0500
Subject: [coreboot] romcc segfaults; serious help needed
Message-ID: <b72cdb061003101925k7acf86a6h4037b6ed90366313@mail.gmail.com>

Hi guys,

I posted a new 440BX RAM init code a few days ago that was segfaulting
romcc, and I didn't get any response.

In the meantime I have narrowed the cause to this code fragment, with enough
wrapper added so it can be fed to romcc on its own:

void romcc_fail(void) {
int dimm03 = 0;
int dimm47 = 0;
char mbsc[5];
char mbfs[3];
/* begin actual fragment */
        if (dimm03 > 2) {
                mbsc[4] |= 0x80;
                mbsc[1] |= 0x28;
                mbfs[2] |= 0x40;
                mbfs[0] |= 0x60;
        } else {
                mbsc[4] |= 0xc0;
                mbsc[1] |= 0x3c;
        }
        if ((dimm03 + dimm47) > 4) {
                mbsc[4]  = 0xba;
                mbsc[0]  = 0x30;
                mbfs[0] |= 0x02;
        } else {
                mbsc[0]  = 0x2c;
        }
        if (dimm47 > 2) {
                mbsc[4] |= 0x20;
                mbsc[1] |= 0x02;
                mbsc[0] |= 0x80;
                mbfs[2] |= 0x20;
                mbfs[0] |= 0x18;
        } else {
                mbsc[4] |= 0x30;
                mbsc[1] |= 0x03;
                mbsc[0] |= 0xc0;
        }
/* end actual fragment */
}

There are three similar constructs, any one of them is enough to cause a
segfault.

mbfs and mbsc are meant to be an array of bytes that make up the MBFS and
MBSC registers in the 440BX, to be written out to it once they're all set.

Thanks for all help
Keith
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20100310/b0020ead/attachment.html>

From knuku at gap.upv.es  Thu Mar 11 09:26:02 2010
From: knuku at gap.upv.es (Knut Kujat)
Date: Thu, 11 Mar 2010 09:26:02 +0100
Subject: [coreboot] Supermicro H8QME-2+: Dumping smbus registers
In-Reply-To: <1268241995.3876.1.camel@mattotaupa>
References: <4B87CF9D.9060204@gap.upv.es>	<201002261506.46602.christian.leber@ziti.uni-heidelberg.de>	<4B87DEFE.3010604@gap.upv.es>	<20100226154934.5727.qmail@stuge.se>	<4B8BC18D.1050400@gap.upv.es>	<4B8FC877.4030209@gap.upv.es>	<4B91295B.9060102@assembler.cz>	<4B912FE4.7080204@gap.upv.es>	<4B913A01.4090103@assembler.cz>	<13426df11003051007r29fee819p2fdea852891a4b58@mail.gmail.com>	<4B94E384.4060002@gap.upv.es>
	<4B97C847.5070506@gap.upv.es> <1268241995.3876.1.camel@mattotaupa>
Message-ID: <4B98A91A.1020602@gap.upv.es>

Paul Menzel escribi?:
> Dear Knut,
>
>
> Am Mittwoch, den 10.03.2010, 17:26 +0100 schrieb Knut Kujat:
>
> [?]
>
>   
>> I know that because I found a nice piece of code dumping smbus registers
>> on the h8dme board :D thx to the autor!!
>>     
>
> is it possible to share that piece of code?
>
> [?]
>
> Anyway, nice to hear you ar making some progress and good luck with the
> next steps!
>
>
> Thanks,
>
> Paul
>   
Hi,

you can find the function at src/mainboard/supermicro/h8dme/romstage.c
line 101: static void dump_smbus_registers(void).

bye!
Knut Kujat



From tho.wie at gmx.de  Thu Mar 11 00:47:12 2010
From: tho.wie at gmx.de (tho.wie at gmx.de)
Date: Thu, 11 Mar 2010 00:47:12 +0100
Subject: [coreboot] Un-brick a GAM57SLIS4
Message-ID: <20100310234712.55280@gmx.net>

Hello,

[if this is off-topic here, please feel free to ignore/delete this message]

I accidently flashed my Gigabyte GA-M57-SLI-S4 Rev. 1 with a corrupted BIOS file. The board does not boot anymore, just a black screen, no beeps, simply dead.

I would be glad if I could save the money for a new board so I've got the following question:

If I do the hardware-mod as shown in <http://private.vlsi.informatik.tu-darmstadt.de/st/> and can obtain a programmed flash rom with a valid BIOS inside, would it be possible to "reanimate" the board again? Would it be neccessary to remove the original Flash-BIOS or can leave it (permanently switched off) on the board?


Thanks

Thorsten


-- 
GRATIS f?r alle GMX-Mitglieder: Die maxdome Movie-FLAT!
Jetzt freischalten unter http://portal.gmx.net/de/go/maxdome01



From peter at stuge.se  Thu Mar 11 11:44:04 2010
From: peter at stuge.se (Peter Stuge)
Date: Thu, 11 Mar 2010 11:44:04 +0100
Subject: [coreboot] romcc segfaults; serious help needed
In-Reply-To: <b72cdb061003101925k7acf86a6h4037b6ed90366313@mail.gmail.com>
References: <b72cdb061003101925k7acf86a6h4037b6ed90366313@mail.gmail.com>
Message-ID: <20100311104404.27344.qmail@stuge.se>

Keith Hui wrote:
> I posted a new 440BX RAM init code a few days ago that was
> segfaulting romcc, and I didn't get any response.

There aren't very many romcc ninjas.


> void romcc_fail(void) {
> int dimm03 = 0;
> int dimm47 = 0;
> char mbsc[5];
> char mbfs[3];

This is already putting some pressure on register allocation. Can you
help romcc by making dimm03 and dimm47 into char also? Consistently
using unsigned may also help.


> mbfs and mbsc are meant to be an array of bytes that make up the
> MBFS and MBSC registers in the 440BX, to be written out to it once
> they're all set.

Would it be possible to not store, and instead write out to registers
as soon as possible? This will also help romcc.


//Peter



From patrick at georgi-clan.de  Thu Mar 11 11:33:35 2010
From: patrick at georgi-clan.de (Patrick Georgi)
Date: Thu, 11 Mar 2010 11:33:35 +0100
Subject: [coreboot] romcc segfaults; serious help needed
In-Reply-To: <b72cdb061003101925k7acf86a6h4037b6ed90366313@mail.gmail.com>
References: <b72cdb061003101925k7acf86a6h4037b6ed90366313@mail.gmail.com>
Message-ID: <4B98C6FF.6080707@georgi-clan.de>

Am 11.03.2010 04:25, schrieb Keith Hui:
> Hi guys,
> 
> I posted a new 440BX RAM init code a few days ago that was segfaulting
> romcc, and I didn't get any response.
> 
> In the meantime I have narrowed the cause to this code fragment, with
> enough wrapper added so it can be fed to romcc on its own:
Thank you for the test case, I could reproduce the crash.

Attached patch fixes the romcc segfaults when using the |=, +=, ^=
operators on array fields and produces reasonably looking code.

I did some tests to verify that the behaviour didn't change, but your
test case compiles to no code (except some useless jmp instructions) as
it has no side effects, so I can only verify it builds.
Please test it on your real world code.

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

From buurin at gmail.com  Thu Mar 11 12:31:22 2010
From: buurin at gmail.com (Keith Hui)
Date: Thu, 11 Mar 2010 06:31:22 -0500
Subject: [coreboot] romcc segfaults; serious help needed
Message-ID: <b72cdb061003110331h396ee4bctf44ad991c3ace313@mail.gmail.com>

> > void romcc_fail(void) {
> > int dimm03 = 0;
> > int dimm47 = 0;
> > char mbsc[5];
> > char mbfs[3];
>
> This is already putting some pressure on register allocation. Can you
> help romcc by making dimm03 and dimm47 into char also? Consistently
> using unsigned may also help.
>
> > mbfs and mbsc are meant to be an array of bytes that make up the
> > MBFS and MBSC registers in the 440BX, to be written out to it once
> > they're all set.
>
> Would it be possible to not store, and instead write out to registers
> as soon as possible? This will also help romcc.
>
> //Peter

I feel good being able to push romcc to the limit, and probably off the
cliff given what happened. :-P

Two of the MBSC bytes are common, at least for now. I'll try eliminating the
variables for them.

On further tries the problem seems to be with the use of |= operator on an
array item. Elsewhere in the original raminit code uses |= with a simple
variable and it doesn't seem to segfault.

But other than that, there are three conditions to check for, and the
registers cannot be finalized and written out until all three are done.

Thanks
Keith
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20100311/4c398a29/attachment.html>

From mylesgw at gmail.com  Thu Mar 11 17:53:44 2010
From: mylesgw at gmail.com (Myles Watson)
Date: Thu, 11 Mar 2010 09:53:44 -0700
Subject: [coreboot] Strange corruption with printk
In-Reply-To: <BB2BA90F9913411B9C5E2625D1D76608@chimp>
References: <2831fecf1003081518o5b05576bx614dc0a3ca9075a8@mail.gmail.com>
	<4B959139.5070607@gmx.net> <ACC5402B33C9468D8C5A6FCF2BBA567D@chimp>
	<4B95B8BB.3060802@gmx.net> <4B963E72.1030301@assembler.cz>
	<BB2BA90F9913411B9C5E2625D1D76608@chimp>
Message-ID: <2831fecf1003110853h7ead7374n6a4411103bd7a52c@mail.gmail.com>

> > 2) Add the
> >
> >
> > static void set_init_ram_access_uc(void)
> > {
> >       set_var_mtrr(0, 0x00000000, CONFIG_RAMTOP, MTRR_TYPE_UNCACHED);
> > }
> >
> >
> > And call the set_init_ram_access_uc instead of set_init_ram_access and
> > call
> > again set_init_ram_access after the copy.
> I'll look at that too

That didn't make any difference for my symptoms, but I'm interested in why
you'd want to set it uncacheable.

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

From ward at gnu.org  Thu Mar 11 17:58:40 2010
From: ward at gnu.org (Ward Vandewege)
Date: Thu, 11 Mar 2010 11:58:40 -0500
Subject: [coreboot] Supermicro H8QME-2+ mct_d fatal exit.
In-Reply-To: <4B97C847.5070506@gap.upv.es>
References: <4B87DEFE.3010604@gap.upv.es> <20100226154934.5727.qmail@stuge.se>
	<4B8BC18D.1050400@gap.upv.es> <4B8FC877.4030209@gap.upv.es>
	<4B91295B.9060102@assembler.cz> <4B912FE4.7080204@gap.upv.es>
	<4B913A01.4090103@assembler.cz>
	<13426df11003051007r29fee819p2fdea852891a4b58@mail.gmail.com>
	<4B94E384.4060002@gap.upv.es> <4B97C847.5070506@gap.upv.es>
Message-ID: <20100311165840.GA1933@countzero.vandewege.net>

On Wed, Mar 10, 2010 at 05:26:47PM +0100, Knut Kujat wrote:
> I finally know that my issue must be related with the smbus registers
> because on a vendor bios running machine and using i2cdetect and i2cdump
> I get several values for different i2c devices detected, I get the same
> values when I successfully start with coreboot. But when I start with
> coreboot and fail with mcr_d fatal exit those registers are blank, I
> know that because I found a nice piece of code dumping smbus registers
> on the h8dme board :D thx to the autor!!

That would have been Marc Jones :)

Thanks,
Ward.

-- 
Ward Vandewege <ward at fsf.org>
Free Software Foundation - Senior Systems Administrator

Join us in Cambridge for LibrePlanet, March 19th-21st!
http://groups.fsf.org/wiki/LibrePlanet2010



From mylesgw at gmail.com  Thu Mar 11 22:14:21 2010
From: mylesgw at gmail.com (Myles Watson)
Date: Thu, 11 Mar 2010 14:14:21 -0700
Subject: [coreboot] [PATCH] use memset
Message-ID: <2831fecf1003111314y380d6602n1426653b1af8e540@mail.gmail.com>

I was having trouble with stack corruption.  Using memset (C) instead of
clear_memory(asm) speeds it up by almost a factor of 2 for a 1M region.

TSC difference with clear_memory 0xFA884D
TSC difference with memset 0x826742

Anyway, this patch removes a couple of files that don't need to exist
anymore, given that only K8 was using clear_memory.

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

Thanks,
Myles
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20100311/0ce80119/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: memset.diff
Type: text/x-patch
Size: 11681 bytes
Desc: not available
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20100311/0ce80119/attachment.diff>

From patrick at georgi-clan.de  Thu Mar 11 22:20:14 2010
From: patrick at georgi-clan.de (Patrick Georgi)
Date: Thu, 11 Mar 2010 22:20:14 +0100
Subject: [coreboot] [PATCH] use memset
In-Reply-To: <2831fecf1003111314y380d6602n1426653b1af8e540@mail.gmail.com>
References: <2831fecf1003111314y380d6602n1426653b1af8e540@mail.gmail.com>
Message-ID: <4B995E8E.4080306@georgi-clan.de>

Am 11.03.2010 22:14, schrieb Myles Watson:
> I was having trouble with stack corruption.  Using memset (C) instead of
> clear_memory(asm) speeds it up by almost a factor of 2 for a 1M region.
> 
> TSC difference with clear_memory 0xFA884D
> TSC difference with memset 0x826742
Interesting that the C version is faster in this case.

> Anyway, this patch removes a couple of files that don't need to exist
> anymore, given that only K8 was using clear_memory.
Yay :-)

> SIgned-off-by: Myles Watson <mylesgw at gmail.com <mailto:mylesgw at gmail.com>>
Acked-by: Patrick Georgi <patrick.georgi at coresystems.de>



From svn at coreboot.org  Thu Mar 11 22:34:28 2010
From: svn at coreboot.org (repository service)
Date: Thu, 11 Mar 2010 22:34:28 +0100
Subject: [coreboot] [commit] r5201 - in trunk/src: cpu/amd/car
	cpu/amd/model_10xxx cpu/amd/model_fxx include/cpu/x86
	mainboard/amd/serengeti_cheetah_fam10
	mainboard/msi/ms9652_fam10 mainboard/supermicro/h8dmr_fam10 ma...
Message-ID: <E1Npq1U-00062N-BQ@ra.coresystems.de>

Author: myles
Date: Thu Mar 11 22:34:27 2010
New Revision: 5201
URL: http://tracker.coreboot.org/trac/coreboot/changeset/5201

Log:
Replace clear_memory with memset.
Replace set_init_ram_access with the call to set_var_mtrr.
Remove unused #include statments.

Signed-off-by: Myles Watson <mylesgw at gmail.com>
Acked-by: Patrick Georgi <patrick.georgi at coresystems.de>

Deleted:
   trunk/src/cpu/amd/car/clear_init_ram.c
   trunk/src/include/cpu/x86/mem.h
Modified:
   trunk/src/cpu/amd/car/post_cache_as_ram.c
   trunk/src/cpu/amd/model_10xxx/init_cpus.c
   trunk/src/cpu/amd/model_10xxx/model_10xxx_init.c
   trunk/src/cpu/amd/model_fxx/init_cpus.c
   trunk/src/cpu/amd/model_fxx/model_fxx_init.c
   trunk/src/mainboard/amd/serengeti_cheetah_fam10/romstage.c
   trunk/src/mainboard/msi/ms9652_fam10/romstage.c
   trunk/src/mainboard/supermicro/h8dmr_fam10/romstage.c
   trunk/src/mainboard/supermicro/h8qme_fam10/romstage.c
   trunk/src/mainboard/tyan/s2912_fam10/romstage.c
   trunk/src/northbridge/amd/amdk8/raminit.c
   trunk/src/northbridge/amd/amdk8/raminit_f.c
   trunk/src/northbridge/intel/e7520/raminit.c
   trunk/src/northbridge/intel/e7525/raminit.c
   trunk/src/northbridge/intel/i3100/raminit.c
   trunk/src/northbridge/intel/i3100/raminit_ep80579.c
   trunk/src/northbridge/intel/i945/raminit.c

Modified: trunk/src/cpu/amd/car/post_cache_as_ram.c
==============================================================================
--- trunk/src/cpu/amd/car/post_cache_as_ram.c	Wed Mar 10 04:43:05 2010	(r5200)
+++ trunk/src/cpu/amd/car/post_cache_as_ram.c	Thu Mar 11 22:34:27 2010	(r5201)
@@ -3,8 +3,6 @@
  */
 #include "cpu/amd/car/disable_cache_as_ram.c"
 
-#include "cpu/amd/car/clear_init_ram.c"
-
 static inline void print_debug_pcar(const char *strval, uint32_t val)
 {
         printk_debug("%s%08x\r\n", strval, val);
@@ -64,7 +62,8 @@
         #error "You need to set CONFIG_RAMTOP greater than 1M"
 #endif
 	
-	set_init_ram_access(); /* So we can access RAM from [1M, CONFIG_RAMTOP) */
+	/* So we can access RAM from [1M, CONFIG_RAMTOP) */
+	set_var_mtrr(0, 0x00000000, CONFIG_RAMTOP, MTRR_TYPE_WRBACK);
 
 //	dump_mem(CONFIG_DCACHE_RAM_BASE+CONFIG_DCACHE_RAM_SIZE-0x8000, CONFIG_DCACHE_RAM_BASE+CONFIG_DCACHE_RAM_SIZE-0x7c00);
 	print_debug("Copying data from cache to RAM -- switching to use RAM as stack... ");
@@ -94,7 +93,12 @@
 	disable_cache_as_ram_bsp();  
 
         print_debug("Clearing initial memory region: ");
-        clear_init_ram(); //except the range from [(CONFIG_RAMTOP) - CONFIG_DCACHE_RAM_SIZE, (CONFIG_RAMTOP))
+#if CONFIG_HAVE_ACPI_RESUME == 1
+	/* clear only coreboot used region of memory. Note: this may break ECC enabled boards */
+	memset((void*) CONFIG_RAMBASE, (CONFIG_RAMTOP) - CONFIG_RAMBASE - CONFIG_DCACHE_RAM_SIZE, 0);
+#else
+        memset((void*)0, ((CONFIG_RAMTOP) - CONFIG_DCACHE_RAM_SIZE), 0);
+#endif
         print_debug("Done\r\n");
 
 //	dump_mem((CONFIG_RAMTOP) - 0x8000, (CONFIG_RAMTOP) - 0x7c00);

Modified: trunk/src/cpu/amd/model_10xxx/init_cpus.c
==============================================================================
--- trunk/src/cpu/amd/model_10xxx/init_cpus.c	Wed Mar 10 04:43:05 2010	(r5200)
+++ trunk/src/cpu/amd/model_10xxx/init_cpus.c	Thu Mar 11 22:34:27 2010	(r5201)
@@ -421,7 +421,7 @@
 		 */
 		//wait_till_sysinfo_in_ram();
 
-		set_init_ram_access();
+		set_var_mtrr(0, 0x00000000, CONFIG_RAMTOP, MTRR_TYPE_WRBACK);
 
 		STOP_CAR_AND_CPU();
 		printk_debug("\nAP %02x should be halted but you are reading this....\n", apicid);

Modified: trunk/src/cpu/amd/model_10xxx/model_10xxx_init.c
==============================================================================
--- trunk/src/cpu/amd/model_10xxx/model_10xxx_init.c	Wed Mar 10 04:43:05 2010	(r5200)
+++ trunk/src/cpu/amd/model_10xxx/model_10xxx_init.c	Thu Mar 11 22:34:27 2010	(r5201)
@@ -34,7 +34,6 @@
 #include <cpu/cpu.h>
 #include <cpu/x86/cache.h>
 #include <cpu/x86/mtrr.h>
-#include <cpu/x86/mem.h>
 #include <cpu/amd/quadcore.h>
 #include <cpu/amd/model_10xxx_msr.h>
 

Modified: trunk/src/cpu/amd/model_fxx/init_cpus.c
==============================================================================
--- trunk/src/cpu/amd/model_fxx/init_cpus.c	Wed Mar 10 04:43:05 2010	(r5200)
+++ trunk/src/cpu/amd/model_fxx/init_cpus.c	Thu Mar 11 22:34:27 2010	(r5201)
@@ -317,7 +317,7 @@
 			        print_initcpu8("while waiting for BSP signal to STOP, timeout in ap ", apicid);
 			}
                         lapic_write(LAPIC_MSG_REG, (apicid<<24) | 0x44); // bsp can not check it before stop_this_cpu
-                        set_init_ram_access();
+			set_var_mtrr(0, 0x00000000, CONFIG_RAMTOP, MTRR_TYPE_WRBACK);
 	#if CONFIG_MEM_TRAIN_SEQ == 1
 			train_ram_on_node(id.nodeid, id.coreid, sysinfo,
 					  (unsigned) STOP_CAR_AND_CPU);

Modified: trunk/src/cpu/amd/model_fxx/model_fxx_init.c
==============================================================================
--- trunk/src/cpu/amd/model_fxx/model_fxx_init.c	Wed Mar 10 04:43:05 2010	(r5200)
+++ trunk/src/cpu/amd/model_fxx/model_fxx_init.c	Thu Mar 11 22:34:27 2010	(r5201)
@@ -24,7 +24,6 @@
 #include <cpu/cpu.h>
 #include <cpu/x86/cache.h>
 #include <cpu/x86/mtrr.h>
-#include <cpu/x86/mem.h>
 
 #include <cpu/amd/dualcore.h>
 
@@ -238,7 +237,7 @@
 
                 /* clear memory 2M (limitk - basek) */
                 addr = (void *)(((uint32_t)addr) | ((basek & 0x7ff) << 10));
-                clear_memory(addr, size);
+                memset(addr, size, 0);
 }
 
 static void init_ecc_memory(unsigned node_id)

Modified: trunk/src/mainboard/amd/serengeti_cheetah_fam10/romstage.c
==============================================================================
--- trunk/src/mainboard/amd/serengeti_cheetah_fam10/romstage.c	Wed Mar 10 04:43:05 2010	(r5200)
+++ trunk/src/mainboard/amd/serengeti_cheetah_fam10/romstage.c	Thu Mar 11 22:34:27 2010	(r5201)
@@ -130,7 +130,6 @@
 #include "northbridge/amd/amdfam10/amdfam10.h"
 #include "northbridge/amd/amdht/ht_wrapper.c"
 
-#include "include/cpu/x86/mem.h"
 #include "northbridge/amd/amdfam10/raminit_sysinfo_in_ram.c"
 #include "northbridge/amd/amdfam10/raminit_amdmct.c"
 #include "northbridge/amd/amdfam10/amdfam10_pci.c"

Modified: trunk/src/mainboard/msi/ms9652_fam10/romstage.c
==============================================================================
--- trunk/src/mainboard/msi/ms9652_fam10/romstage.c	Wed Mar 10 04:43:05 2010	(r5200)
+++ trunk/src/mainboard/msi/ms9652_fam10/romstage.c	Thu Mar 11 22:34:27 2010	(r5201)
@@ -110,7 +110,6 @@
 #include "northbridge/amd/amdfam10/amdfam10.h"
 #include "northbridge/amd/amdht/ht_wrapper.c"
 
-#include "include/cpu/x86/mem.h"
 #include "northbridge/amd/amdfam10/raminit_sysinfo_in_ram.c"
 #include "northbridge/amd/amdfam10/raminit_amdmct.c"
 #include "northbridge/amd/amdfam10/amdfam10_pci.c"

Modified: trunk/src/mainboard/supermicro/h8dmr_fam10/romstage.c
==============================================================================
--- trunk/src/mainboard/supermicro/h8dmr_fam10/romstage.c	Wed Mar 10 04:43:05 2010	(r5200)
+++ trunk/src/mainboard/supermicro/h8dmr_fam10/romstage.c	Thu Mar 11 22:34:27 2010	(r5201)
@@ -108,7 +108,6 @@
 #include "northbridge/amd/amdfam10/amdfam10.h"
 #include "northbridge/amd/amdht/ht_wrapper.c"
 
-#include "include/cpu/x86/mem.h"
 #include "northbridge/amd/amdfam10/raminit_sysinfo_in_ram.c"
 #include "northbridge/amd/amdfam10/raminit_amdmct.c"
 #include "northbridge/amd/amdfam10/amdfam10_pci.c"

Modified: trunk/src/mainboard/supermicro/h8qme_fam10/romstage.c
==============================================================================
--- trunk/src/mainboard/supermicro/h8qme_fam10/romstage.c	Wed Mar 10 04:43:05 2010	(r5200)
+++ trunk/src/mainboard/supermicro/h8qme_fam10/romstage.c	Thu Mar 11 22:34:27 2010	(r5201)
@@ -108,7 +108,6 @@
 #include "northbridge/amd/amdfam10/amdfam10.h"
 #include "northbridge/amd/amdht/ht_wrapper.c"
 
-#include "include/cpu/x86/mem.h"
 #include "northbridge/amd/amdfam10/raminit_sysinfo_in_ram.c"
 #include "northbridge/amd/amdfam10/raminit_amdmct.c"
 #include "northbridge/amd/amdfam10/amdfam10_pci.c"

Modified: trunk/src/mainboard/tyan/s2912_fam10/romstage.c
==============================================================================
--- trunk/src/mainboard/tyan/s2912_fam10/romstage.c	Wed Mar 10 04:43:05 2010	(r5200)
+++ trunk/src/mainboard/tyan/s2912_fam10/romstage.c	Thu Mar 11 22:34:27 2010	(r5201)
@@ -110,7 +110,6 @@
 #include "northbridge/amd/amdfam10/amdfam10.h"
 #include "northbridge/amd/amdht/ht_wrapper.c"
 
-#include "include/cpu/x86/mem.h"
 #include "northbridge/amd/amdfam10/raminit_sysinfo_in_ram.c"
 #include "northbridge/amd/amdfam10/raminit_amdmct.c"
 #include "northbridge/amd/amdfam10/amdfam10_pci.c"

Modified: trunk/src/northbridge/amd/amdk8/raminit.c
==============================================================================
--- trunk/src/northbridge/amd/amdk8/raminit.c	Wed Mar 10 04:43:05 2010	(r5200)
+++ trunk/src/northbridge/amd/amdk8/raminit.c	Thu Mar 11 22:34:27 2010	(r5201)
@@ -4,7 +4,6 @@
 	2005.02 yhlu add E0 memory hole support
 */
 
-#include <cpu/x86/mem.h>
 #include <cpu/x86/cache.h>
 #include <cpu/x86/mtrr.h>
 #include <stdlib.h>

Modified: trunk/src/northbridge/amd/amdk8/raminit_f.c
==============================================================================
--- trunk/src/northbridge/amd/amdk8/raminit_f.c	Wed Mar 10 04:43:05 2010	(r5200)
+++ trunk/src/northbridge/amd/amdk8/raminit_f.c	Thu Mar 11 22:34:27 2010	(r5201)
@@ -20,7 +20,6 @@
  * Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA  02110-1301 USA
 */
 
-#include <cpu/x86/mem.h>
 #include <cpu/x86/cache.h>
 #include <cpu/x86/mtrr.h>
 #include <cpu/x86/tsc.h>

Modified: trunk/src/northbridge/intel/e7520/raminit.c
==============================================================================
--- trunk/src/northbridge/intel/e7520/raminit.c	Wed Mar 10 04:43:05 2010	(r5200)
+++ trunk/src/northbridge/intel/e7520/raminit.c	Thu Mar 11 22:34:27 2010	(r5201)
@@ -18,7 +18,6 @@
  *
  */
 
-#include <cpu/x86/mem.h>
 #include <cpu/x86/mtrr.h>
 #include <cpu/x86/cache.h>
 #include <stdlib.h>

Modified: trunk/src/northbridge/intel/e7525/raminit.c
==============================================================================
--- trunk/src/northbridge/intel/e7525/raminit.c	Wed Mar 10 04:43:05 2010	(r5200)
+++ trunk/src/northbridge/intel/e7525/raminit.c	Thu Mar 11 22:34:27 2010	(r5201)
@@ -18,7 +18,6 @@
  *
  */
 
-#include <cpu/x86/mem.h>
 #include <cpu/x86/mtrr.h>
 #include <cpu/x86/cache.h>
 #include <stdlib.h>

Modified: trunk/src/northbridge/intel/i3100/raminit.c
==============================================================================
--- trunk/src/northbridge/intel/i3100/raminit.c	Wed Mar 10 04:43:05 2010	(r5200)
+++ trunk/src/northbridge/intel/i3100/raminit.c	Thu Mar 11 22:34:27 2010	(r5201)
@@ -19,7 +19,6 @@
  *
  */
 
-#include <cpu/x86/mem.h>
 #include <cpu/x86/mtrr.h>
 #include <cpu/x86/cache.h>
 #include <stdlib.h>

Modified: trunk/src/northbridge/intel/i3100/raminit_ep80579.c
==============================================================================
--- trunk/src/northbridge/intel/i3100/raminit_ep80579.c	Wed Mar 10 04:43:05 2010	(r5200)
+++ trunk/src/northbridge/intel/i3100/raminit_ep80579.c	Thu Mar 11 22:34:27 2010	(r5201)
@@ -19,7 +19,6 @@
  *
  */
 
-#include <cpu/x86/mem.h>
 #include <cpu/x86/mtrr.h>
 #include <cpu/x86/cache.h>
 #include "raminit_ep80579.h"

Modified: trunk/src/northbridge/intel/i945/raminit.c
==============================================================================
--- trunk/src/northbridge/intel/i945/raminit.c	Wed Mar 10 04:43:05 2010	(r5200)
+++ trunk/src/northbridge/intel/i945/raminit.c	Thu Mar 11 22:34:27 2010	(r5201)
@@ -17,7 +17,6 @@
  * Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA  02110-1301 USA
  */
 
-#include <cpu/x86/mem.h>
 #include <cpu/x86/mtrr.h>
 #include <cpu/x86/cache.h>
 #include <spd.h>



From mylesgw at gmail.com  Thu Mar 11 22:39:48 2010
From: mylesgw at gmail.com (Myles Watson)
Date: Thu, 11 Mar 2010 14:39:48 -0700
Subject: [coreboot] [PATCH] use memset
In-Reply-To: <4B995E8E.4080306@georgi-clan.de>
References: <2831fecf1003111314y380d6602n1426653b1af8e540@mail.gmail.com>
	<4B995E8E.4080306@georgi-clan.de>
Message-ID: <C6CB289FCCC4460FB02A7B50F19E04A1@chimp>

> Am 11.03.2010 22:14, schrieb Myles Watson:
> > I was having trouble with stack corruption.  Using memset (C) instead of
> > clear_memory(asm) speeds it up by almost a factor of 2 for a 1M region.
I should have said it got rid of the memory corruption I was seeing, too :)

> > TSC difference with clear_memory 0xFA884D
> > TSC difference with memset 0x826742
> Interesting that the C version is faster in this case.
Yeah.  Maybe you could do a lot better with a different asm implementation.
You'd hope that the compiler would have a pretty good routine for clearing
memory, though.  I didn't dig into it to see what the real difference was.

> > SIgned-off-by: Myles Watson <mylesgw at gmail.com
> <mailto:mylesgw at gmail.com>>
> Acked-by: Patrick Georgi <patrick.georgi at coresystems.de>
Rev 5201.

Thanks,
Myles




From svn at coreboot.org  Thu Mar 11 23:12:11 2010
From: svn at coreboot.org (repository service)
Date: Thu, 11 Mar 2010 23:12:11 +0100
Subject: [coreboot] [commit] r5202 - trunk/src/cpu/amd/car
Message-ID: <E1Npqbz-0002Op-6v@ra.coresystems.de>

Author: myles
Date: Thu Mar 11 23:12:10 2010
New Revision: 5202
URL: http://tracker.coreboot.org/trac/coreboot/changeset/5202

Log:
Replace spaces with tabs.  Trivial.

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

Modified:
   trunk/src/cpu/amd/car/cache_as_ram.inc
   trunk/src/cpu/amd/car/disable_cache_as_ram.c
   trunk/src/cpu/amd/car/post_cache_as_ram.c

Modified: trunk/src/cpu/amd/car/cache_as_ram.inc
==============================================================================
--- trunk/src/cpu/amd/car/cache_as_ram.inc	Thu Mar 11 22:34:27 2010	(r5201)
+++ trunk/src/cpu/amd/car/cache_as_ram.inc	Thu Mar 11 23:12:10 2010	(r5202)
@@ -270,8 +270,8 @@
 #else
 #define REAL_XIP_ROM_BASE CONFIG_XIP_ROM_BASE
 #endif
-       movl    $REAL_XIP_ROM_BASE, %eax
-       orl     $MTRR_TYPE_WRBACK, %eax
+	movl    $REAL_XIP_ROM_BASE, %eax
+	orl     $MTRR_TYPE_WRBACK, %eax
 	wrmsr
 
 	movl	$0x203, %ecx

Modified: trunk/src/cpu/amd/car/disable_cache_as_ram.c
==============================================================================
--- trunk/src/cpu/amd/car/disable_cache_as_ram.c	Thu Mar 11 22:34:27 2010	(r5201)
+++ trunk/src/cpu/amd/car/disable_cache_as_ram.c	Thu Mar 11 23:12:10 2010	(r5202)
@@ -2,45 +2,45 @@
 /* be warned, this file will be used other cores and core 0 / node 0 */
 static inline __attribute__((always_inline)) void disable_cache_as_ram(void)
 {
-        __asm__ __volatile__ (
-        /* We don't need cache as ram for now on */
-        /* disable cache */
-        "movl    %%cr0, %%eax\n\t"
-        "orl    $(0x1<<30),%%eax\n\t"
-        "movl    %%eax, %%cr0\n\t"
+	__asm__ __volatile__ (
+	/* We don't need cache as ram for now on */
+	/* disable cache */
+	"movl    %%cr0, %%eax\n\t"
+	"orl    $(0x1<<30),%%eax\n\t"
+	"movl    %%eax, %%cr0\n\t"
 
-        /* clear sth */
-        "movl    $0x269, %%ecx\n\t"  /* fix4k_c8000*/
-        "xorl    %%edx, %%edx\n\t"
-        "xorl    %%eax, %%eax\n\t"
+	/* clear sth */
+	"movl    $0x269, %%ecx\n\t"  /* fix4k_c8000*/
+	"xorl    %%edx, %%edx\n\t"
+	"xorl    %%eax, %%eax\n\t"
 	"wrmsr\n\t"
 #if CONFIG_DCACHE_RAM_SIZE > 0x8000
 	"movl    $0x268, %%ecx\n\t"  /* fix4k_c0000*/
-        "wrmsr\n\t"
+	"wrmsr\n\t"
 #endif
 
-        /* disable fixed mtrr from now on, it will be enabled by coreboot_ram again*/
-        "movl    $0xC0010010, %%ecx\n\t"
-//        "movl    $SYSCFG_MSR, %ecx\n\t"
-        "rdmsr\n\t"
-        "andl    $(~(3<<18)), %%eax\n\t"
-//        "andl    $(~(SYSCFG_MSR_MtrrFixDramModEn | SYSCFG_MSR_MtrrFixDramEn)), %eax\n\t"
-        "wrmsr\n\t"
+	/* disable fixed mtrr from now on, it will be enabled by coreboot_ram again*/
+	"movl    $0xC0010010, %%ecx\n\t"
+//	"movl    $SYSCFG_MSR, %ecx\n\t"
+	"rdmsr\n\t"
+	"andl    $(~(3<<18)), %%eax\n\t"
+//	"andl    $(~(SYSCFG_MSR_MtrrFixDramModEn | SYSCFG_MSR_MtrrFixDramEn)), %eax\n\t"
+	"wrmsr\n\t"
 
-        /* Set the default memory type and disable fixed and enable variable MTRRs */
-        "movl    $0x2ff, %%ecx\n\t"
-//        "movl    $MTRRdefType_MSR, %ecx\n\t"
-        "xorl    %%edx, %%edx\n\t"
-        /* Enable Variable and Disable Fixed MTRRs */
-        "movl    $0x00000800, %%eax\n\t"
-        "wrmsr\n\t"
+	/* Set the default memory type and disable fixed and enable variable MTRRs */
+	"movl    $0x2ff, %%ecx\n\t"
+//	"movl    $MTRRdefType_MSR, %ecx\n\t"
+	"xorl    %%edx, %%edx\n\t"
+	/* Enable Variable and Disable Fixed MTRRs */
+	"movl    $0x00000800, %%eax\n\t"
+	"wrmsr\n\t"
 
-        /* enable cache */
-        "movl    %%cr0, %%eax\n\t"
-        "andl    $0x9fffffff,%%eax\n\t"
-        "movl    %%eax, %%cr0\n\t"
-        ::: "memory", "eax", "ecx", "edx"
-        );
+	/* enable cache */
+	"movl    %%cr0, %%eax\n\t"
+	"andl    $0x9fffffff,%%eax\n\t"
+	"movl    %%eax, %%cr0\n\t"
+	::: "memory", "eax", "ecx", "edx"
+	);
 }
 
 static void disable_cache_as_ram_bsp(void)

Modified: trunk/src/cpu/amd/car/post_cache_as_ram.c
==============================================================================
--- trunk/src/cpu/amd/car/post_cache_as_ram.c	Thu Mar 11 22:34:27 2010	(r5201)
+++ trunk/src/cpu/amd/car/post_cache_as_ram.c	Thu Mar 11 23:12:10 2010	(r5202)
@@ -5,7 +5,7 @@
 
 static inline void print_debug_pcar(const char *strval, uint32_t val)
 {
-        printk_debug("%s%08x\r\n", strval, val);
+	printk_debug("%s%08x\r\n", strval, val);
 }
 
 /* from linux kernel 2.6.32 asm/string_32.h */
@@ -41,15 +41,15 @@
 {
 
 #if 1
-        {
-        /* Check value of esp to verify if we have enough rom for stack in Cache as RAM */
-        unsigned v_esp;
-        __asm__ volatile (
-                "movl   %%esp, %0\n\t"
-                : "=a" (v_esp)
-        );
-        print_debug_pcar("v_esp=", v_esp);
-        }
+	{
+	/* Check value of esp to verify if we have enough rom for stack in Cache as RAM */
+	unsigned v_esp;
+	__asm__ volatile (
+		"movl   %%esp, %0\n\t"
+		: "=a" (v_esp)
+	);
+	print_debug_pcar("v_esp=", v_esp);
+	}
 #endif
 
 	unsigned testx = 0x5a5a5a5a;
@@ -59,7 +59,7 @@
 		ram need to set CONFIG_RAMTOP to 2M and use var mtrr instead.
 	 */
 #if CONFIG_RAMTOP <= 0x100000
-        #error "You need to set CONFIG_RAMTOP greater than 1M"
+	#error "You need to set CONFIG_RAMTOP greater than 1M"
 #endif
 	
 	/* So we can access RAM from [1M, CONFIG_RAMTOP) */
@@ -71,51 +71,49 @@
 	/* from here don't store more data in CAR */
 	vErrata343();
 
-        memcopy((void *)((CONFIG_RAMTOP)-CONFIG_DCACHE_RAM_SIZE), (void *)CONFIG_DCACHE_RAM_BASE, CONFIG_DCACHE_RAM_SIZE); //inline
-//        dump_mem((CONFIG_RAMTOP) - 0x8000, (CONFIG_RAMTOP) - 0x7c00);
+	memcopy((void *)((CONFIG_RAMTOP)-CONFIG_DCACHE_RAM_SIZE), (void *)CONFIG_DCACHE_RAM_BASE, CONFIG_DCACHE_RAM_SIZE); //inline
+//	dump_mem((CONFIG_RAMTOP) - 0x8000, (CONFIG_RAMTOP) - 0x7c00);
 
-        __asm__ volatile (
-                /* set new esp */ /* before CONFIG_RAMBASE */
-                "subl   %0, %%esp\n\t"
-                ::"a"( (CONFIG_DCACHE_RAM_BASE + CONFIG_DCACHE_RAM_SIZE)- (CONFIG_RAMTOP) )
+	__asm__ volatile (
+		/* set new esp */ /* before CONFIG_RAMBASE */
+		"subl   %0, %%esp\n\t"
+		::"a"( (CONFIG_DCACHE_RAM_BASE + CONFIG_DCACHE_RAM_SIZE)- (CONFIG_RAMTOP) )
 		/* discard all registers (eax is used for %0), so gcc redo everything
 		   after the stack is moved */
 		: "cc", "memory", "%ebx", "%ecx", "%edx", "%esi", "%edi", "%ebp"
-        );
+	);
 
 	/* We can put data to stack again */
 
-        /* only global variable sysinfo in cache need to be offset */
-        print_debug("Done\r\n");
-        print_debug_pcar("testx = ", testx);
+	/* only global variable sysinfo in cache need to be offset */
+	print_debug("Done\r\n");
+	print_debug_pcar("testx = ", testx);
 
 	print_debug("Disabling cache as ram now \r\n");
 	disable_cache_as_ram_bsp();  
 
-        print_debug("Clearing initial memory region: ");
+	print_debug("Clearing initial memory region: ");
 #if CONFIG_HAVE_ACPI_RESUME == 1
 	/* clear only coreboot used region of memory. Note: this may break ECC enabled boards */
 	memset((void*) CONFIG_RAMBASE, (CONFIG_RAMTOP) - CONFIG_RAMBASE - CONFIG_DCACHE_RAM_SIZE, 0);
 #else
-        memset((void*)0, ((CONFIG_RAMTOP) - CONFIG_DCACHE_RAM_SIZE), 0);
+	memset((void*)0, ((CONFIG_RAMTOP) - CONFIG_DCACHE_RAM_SIZE), 0);
 #endif
-        print_debug("Done\r\n");
+	print_debug("Done\r\n");
 
 //	dump_mem((CONFIG_RAMTOP) - 0x8000, (CONFIG_RAMTOP) - 0x7c00);
 
-        set_sysinfo_in_ram(1); // So other core0 could start to train mem
+	set_sysinfo_in_ram(1); // So other core0 could start to train mem
 
 #if CONFIG_MEM_TRAIN_SEQ == 1
 //	struct sys_info *sysinfox = ((CONFIG_RAMTOP) - CONFIG_DCACHE_RAM_GLOBAL_VAR_SIZE);
 
-        // wait for ap memory to trained
-//        wait_all_core0_mem_trained(sysinfox); // moved to lapic_init_cpus.c
+	// wait for ap memory to trained
+//	wait_all_core0_mem_trained(sysinfox); // moved to lapic_init_cpus.c
 #endif
-        /*copy and execute coreboot_ram */
-        copy_and_run();
-        /* We will not return */
-
-        print_debug("should not be here -\r\n");
+	/*copy and execute coreboot_ram */
+	copy_and_run();
+	/* We will not return */
 
+	print_debug("should not be here -\r\n");
 }
-



From Zheng.Bao at amd.com  Fri Mar 12 03:23:17 2010
From: Zheng.Bao at amd.com (Bao, Zheng)
Date: Fri, 12 Mar 2010 10:23:17 +0800
Subject: [coreboot] [PATCH] sb600: new way to load initial verb
In-Reply-To: <DD1CC71B621B004FA76856E5129D6B1703826497@sbjgexmb1.amd.com>
References: <DD1CC71B621B004FA76856E5129D6B17038260ED@sbjgexmb1.amd.com><4B90D94E.5000007@coresystems.de>	<4B910F27.7030903@gmx.net><DD1CC71B621B004FA76856E5129D6B170382637F@sbjgexmb1.amd.com><4B950661.5060905@gmx.net>
	<DD1CC71B621B004FA76856E5129D6B1703826497@sbjgexmb1.amd.com>
Message-ID: <DD1CC71B621B004FA76856E5129D6B170388A6E8@sbjgexmb1.amd.com>

Could it be a GSOC project?
1. Make an application to dump the codec structure and initial pin
configuration.
2. In Coreboot repository, add a public code to load initial pin
configuration as a CBFS modules.

Is it too small? I kinda don't have much time to do this.


Zheng

> -----Original Message-----
> From: coreboot-bounces at coreboot.org
[mailto:coreboot-bounces at coreboot.org]
> On Behalf Of Bao, Zheng
> Sent: Tuesday, March 09, 2010 11:02 AM
> To: coreboot at coreboot.org
> Subject: Re: [coreboot] [PATCH] sb600: new way to load initial verb
> 
> 
> 
> > -----Original Message-----
> > From: Carl-Daniel Hailfinger
> [mailto:c-d.hailfinger.devel.2006 at gmx.net]
> > Sent: Monday, March 08, 2010 10:15 PM
> > To: Bao, Zheng
> > Cc: Stefan Reinauer; coreboot at coreboot.org
> > Subject: Re: [coreboot] [PATCH] sb600: new way to load initial verb
> >
> > On 08.03.2010 09:20, Bao, Zheng wrote:
> > > The original way to load initial verb is quite inflexible.
> > > The format of the command is:
> > > CAd 31:28 - codec address
> > > NID 27:20 - Nid
> > > Verb 19:0 - Verb data
> > > Each Nid has 4 byte data to write. It has to write one at a time.
> > > 	0x01471c10,      //1st byte 10
> > > 	0x01471d40,      //2nd byte 40
> > > 	0x01471e01,      //3rd byte 01
> > > 	0x01471f01,      //4th byte 01
> > >
> > > The new code in sb600_hda.c and the code structure are quite
> > > preliminary.  When it is almost done and can satisfy everybody, We
> can
> > > define the pin configuration code at mainboard.
> > >
> >
> > It would be cool if all chipsets could use the new verb
> implementation.
> >
> >
> > >  #define CODEC_PIN_CONFIG_FILE "codec/alc_882.h"
> > > or
> > >  config CODEC_PIN_CONFIG_FILE
> > > 	string
> > > 	default "codec/alc_882.h"
> > > 	depends on BOARD_AMD_DBM690T
> > >
> >
> > Or we define that file as separate uncompressed CBFS file.
> >
> >
> > > Now I am wondering if it is legal provide the intial pin
> configuration
> > > code in coreboot. If it is legal, how can we get it? The 882 code
is
> > > got from CIM.
> > >
> >
> > Sorry, what is CIM?
> > In theory, the pin configuration is mainboard specific. If that is
> true,
> > the pin configuration is similar to IRQ routing: There is usually
only
> > one correct and working solution. So it is possible that the
mainboard
> > vendor and the codec vendor own parts of it. Not sure. We could tell
> > users to dump verbs from their mainboards (is that possible?) and
add
> > the resulting file to CBFS.
> >
> It is mainboard specific. Each codec also has its own code. The
> mainboard code is based on the codec code, I think. Dumping verbs is
> possible. It needs a lot of work from the ground up. There are some
> similar tools like http://helllabs.org/codecgraph/. Integrating them
to
> coreboot/util needs permission, doesn't it?
> 
> >
> > > Signed-off-by: Zheng Bao <zheng.bao at amd.com>
> > >
> > > Index: src/codec/alc_882.h
> > >
===================================================================
> > > --- src/codec/alc_882.h	(revision 0)
> > > +++ src/codec/alc_882.h	(revision 0)
> > > @@ -0,0 +1,12 @@
> > >
> >
> > struct _pin_config_codec_entry pin_config_file[] = {
> >
> > > +	{0x14, 0x01014010},
> > > +	{0x15, 0x01011012},
> > > +	{0x16, 0x01016011},
> > > +	{0x17, 0x01012014},
> > > +	{0x18, 0x01A19030},
> > > +	{0x19, 0x411111F0},
> > > +	{0x1a, 0x01813080},
> > > +	{0x1b, 0x411111F0},
> > > +	{0x1C, 0x411111F0},
> > > +	{0x1d, 0x411111F0},
> > > +	{0x1e, 0x01441150},
> > > +	{0x1f, 0x01C46160},
> > >
> >
> > {-1, -1}
> > };
> >
> >
> > > Index: src/southbridge/amd/sb600/sb600_hda.c
> > >
===================================================================
> > > --- src/southbridge/amd/sb600/sb600_hda.c	(revision 5195)
> > > +++ src/southbridge/amd/sb600/sb600_hda.c	(working copy)
> > > @@ -90,68 +90,19 @@
> > >  	return 0;
> > >  }
> > >
> > > -static u32 cim_verb_data[] = {
> > > -	0x01471c10,
> > > -	0x01471d40,
> > > -	0x01471e01,
> > > -	0x01471f01,
> > > -/* 1 */
> > > -	0x01571c12,
> > > -	0x01571d10,
> > > -	0x01571e01,
> > > -	0x01571f01,
> > > -/* 2 */
> > > -	0x01671c11,
> > > -	0x01671d60,
> > > -	0x01671e01,
> > > -	0x01671f01,
> > > -/* 3 */
> > > -	0x01771c14,
> > > -	0x01771d20,
> > > -	0x01771e01,
> > > -	0x01771f01,
> > > -/* 4 */
> > > -	0x01871c30,
> > > -	0x01871d90,
> > > -	0x01871ea1,
> > > -	0x01871f01,
> > > -/* 5 */
> > > -	0x01971cf0,
> > > -	0x01971d11,
> > > -	0x01971e11,
> > > -	0x01971f41,
> > > -/* 6 */
> > > -	0x01a71c80,
> > > -	0x01a71d30,
> > > -	0x01a71e81,
> > > -	0x01a71f01,
> > > -/* 7 */
> > > -	0x01b71cf0,
> > > -	0x01b71d11,
> > > -	0x01b71e11,
> > > -	0x01b71f41,
> > > -/* 8 */
> > > -	0x01c71cf0,
> > > -	0x01c71d11,
> > > -	0x01c71e11,
> > > -	0x01c71f41,
> > > -/* 9 */
> > > -	0x01d71cf0,
> > > -	0x01d71d11,
> > > -	0x01d71e11,
> > > -	0x01d71f41,
> > > -/* 10 */
> > > -	0x01e71c50,
> > > -	0x01e71d11,
> > > -	0x01e71e44,
> > > -	0x01e71f01,
> > > -/* 11 */
> > > -	0x01f71c60,
> > > -	0x01f71d61,
> > > -	0x01f71ec4,
> > > -	0x01f71f01,
> > > +typedef struct _pin_config_codec_entry {
> > >
> >
> > Can you please kill the typedef and use "struct
> _pin_config_codec_entry"
> > instead?
> >
> >
> > > +	u8	nid;
> > > +	u32	pin_config;
> > > +} pin_config_codec_entry;
> > > +
> > > +static pin_config_codec_entry pin_config_file[] = {
> > > +#ifdef	CODEC_PIN_CONFIG_FILE
> > > +	#include CODEC_PIN_CONFIG_FILE
> > >
> >
> > Including C source makes code difficult to read. Can you move the
> > complete struct to alc_882.h?
> >
> > Hm. Could we simply store the whole verb stuff uncompressed inside
> CBFS?
> >
> 
> I think the purpose of the CBFS is to integrate some binary files
which
> are built at other place. The verb data we got is in text mode. We
need
> to build it into binary and store it into CBFS. Is it wasting? Why
don't
> we do it as fam10 patch code?
> 
> >
> > > +#endif
> > > +	{-1, -1}
> > >  };
> > > -static u32 find_verb(u32 viddid, u32 ** verb)
> > > +
> > > +static void find_verb(u32 viddid, pin_config_codec_entry ** verb)
> > >  {
> > >  	device_t azalia_dev = dev_find_slot(0, PCI_DEVFN(0x14, 2));
> > >  	struct southbridge_amd_sb600_config *cfg =
> > > @@ -159,12 +110,13 @@
> > >  	printk_debug("Dev=%s\n", dev_path(azalia_dev));
> > >  	printk_debug("Default viddid=%x\n", cfg->hda_viddid);
> > >  	printk_debug("Reading viddid=%x\n", viddid);
> > > +
> > > +	*verb = NULL;
> > >  	if (!cfg)
> > > -		return 0;
> > > +		return;
> > >  	if (viddid != cfg->hda_viddid)
> > > -		return 0;
> > > -	*verb = (u32 *) cim_verb_data;
> > > -	return sizeof(cim_verb_data) / sizeof(u32);
> > > +		return;
> > > +	*verb = pin_config_file;
> > >  }
> > >
> > >  /**
> > > @@ -214,9 +166,8 @@
> > >
> > >  static void codec_init(u8 * base, int addr)
> > >  {
> > > -	u32 dword;
> > > -	u32 *verb;
> > > -	u32 verb_size;
> > > +	u32 dword, dword1, pin_config;
> > > +	pin_config_codec_entry *verb=NULL;
> > >  	int i;
> > >
> > >  	/* 1 */
> > > @@ -233,23 +184,32 @@
> > >
> > >  	/* 2 */
> > >  	printk_debug("codec viddid: %08x\n", dword);
> > > -	verb_size = find_verb(dword, &verb);
> > > +	find_verb(dword, &verb);
> > >
> > > -	if (!verb_size) {
> > > +	if (verb == NULL) {
> > >  		printk_debug("No verb!\n");
> > >  		return;
> > >  	}
> > >
> > > -	printk_debug("verb_size: %d\n", verb_size);
> > >  	/* 3 */
> > > -	for (i = 0; i < verb_size; i++) {
> > > -		if (wait_for_ready(base) == -1)
> > > -			return;
> > > +	for (verb; verb->nid != 0xFF; verb++) {
> > > +		dword = addr << 28 | verb->nid << 20 | 7 << 16;
> > > +		pin_config = verb->pin_config;
> > >
> > > -		write32(base + 0x60, verb[i]);
> > > +		for (i = 4; i > 0; i--, pin_config >>= 8) {
> > > +			if (wait_for_ready(base) == -1)
> > > +				return;
> > >
> > > -		if (wait_for_valid(base) == -1)
> > > -			return;
> > > +			if (verb->nid != 1)
> > > +				dword1 = dword | ((0x20 - i) & 0xFF) <<
> 8;
> > > +			else
> > > +				dword1 = dword | ((0x24 - i) & 0xFF) <<
> 8;
> > > +			dword1 |= (pin_config & 0xFF);
> > > +			write32(base + 0x60, dword1);
> > > +
> > > +			if (wait_for_valid(base) == -1)
> > > +				return;
> > > +		}
> > >  	}
> > >  	printk_debug("verb loaded!\n");
> > >  }
> > >
> >
> > Looks good.
> >
> > Regards,
> > Carl-Daniel
> >
> > --
> > "I do consider assignment statements and pointer variables to be
among
> > computer science's most valuable treasures."
> > -- Donald E. Knuth
> >
> 
> 
> 
> --
> coreboot mailing list: coreboot at coreboot.org
> http://www.coreboot.org/mailman/listinfo/coreboot





From buurin at gmail.com  Fri Mar 12 05:02:05 2010
From: buurin at gmail.com (Keith Hui)
Date: Thu, 11 Mar 2010 23:02:05 -0500
Subject: [coreboot] [PATCH] New config option for 440BX northbridge
Message-ID: <b72cdb061003112002w777153b4t9a99ac557853a02c@mail.gmail.com>

Hi all,

This patch adds a Kconfig option for 440BX that enable compiling in the
proper value for the SDRAMPWR bit in SDRAMC register for 3 or 4 DIMM slots.
No more hard coding for 4 DIMM slots. Also sets it to be permanently enabled
for a few ASUS boards (P2B-LS/D/DS, P3B-F) that I know for sure have 4
slots.

This option only appears when Expert mode is selected in Kconfig.

The actual code in raminit.c is still being boot tested and would have to
wait until it boots all the way on my board. This just adds the config
option so it is there when the code is ready.

Cheers.

Signed-off-by: Keith Hui <buurin at gmail.com>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20100311/a588fe52/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: sdrampwrcfg.patch
Type: application/octet-stream
Size: 2349 bytes
Desc: not available
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20100311/a588fe52/attachment.obj>

From ward at gnu.org  Fri Mar 12 05:16:39 2010
From: ward at gnu.org (Ward Vandewege)
Date: Thu, 11 Mar 2010 23:16:39 -0500
Subject: [coreboot] Un-brick a GAM57SLIS4
In-Reply-To: <20100310234712.55280@gmx.net>
References: <20100310234712.55280@gmx.net>
Message-ID: <20100312041639.GA29500@countzero.vandewege.net>

Hi Thorsten,

On Thu, Mar 11, 2010 at 12:47:12AM +0100, tho.wie at gmx.de wrote:
> [if this is off-topic here, please feel free to ignore/delete this message]
> 
> I accidently flashed my Gigabyte GA-M57-SLI-S4 Rev. 1 with a corrupted BIOS file. The board does not boot anymore, just a black screen, no beeps, simply dead.
> 
> I would be glad if I could save the money for a new board so I've got the following question:
> 
> If I do the hardware-mod as shown in
> <http://private.vlsi.informatik.tu-darmstadt.de/st/> and can obtain a
> programmed flash rom with a valid BIOS inside, would it be possible to
> "reanimate" the board again? Would it be neccessary to remove the original
> Flash-BIOS or can leave it (permanently switched off) on the board?

If you do that modification, you'll have a switch or jumper to toggle between
your 2 chips. If the second one has a good image, this should work.

Thanks,
Ward.

-- 
Ward Vandewege <ward at fsf.org>
Free Software Foundation - Senior Systems Administrator

Join us in Cambridge for LibrePlanet, March 19th-21st!
http://groups.fsf.org/wiki/LibrePlanet2010



From kevin at koconnor.net  Fri Mar 12 03:30:56 2010
From: kevin at koconnor.net (Kevin O'Connor)
Date: Thu, 11 Mar 2010 21:30:56 -0500
Subject: [coreboot] SeaBIOS support for high-speed (EHCI) USB
Message-ID: <20100312023056.GA30239@morn.localdomain>

Hi,

The latest SeaBIOS git now has support for EHCI USB controllers.  This
is in addition to the UHCI and OHCI support already in SeaBIOS.  To
obtain SeaBIOS, see:

http://seabios.org/Download

I've tested the EHCI support on my epia-cn.  Booting from USB drives
is now noticeably faster.

Currently SeaBIOS supports USB keyboards, USB hubs, and USB drives.

Help with testing on a wider range of hardware would be appreciated.

-Kevin



From joe at settoplinux.org  Fri Mar 12 08:19:47 2010
From: joe at settoplinux.org (Joseph Smith)
Date: Fri, 12 Mar 2010 02:19:47 -0500
Subject: [coreboot] SeaBIOS support for high-speed (EHCI) USB
In-Reply-To: <20100312023056.GA30239@morn.localdomain>
References: <20100312023056.GA30239@morn.localdomain>
Message-ID: <4B99EB13.6020608@settoplinux.org>

On 03/11/2010 09:30 PM, Kevin O'Connor wrote:
> Hi,
>
> The latest SeaBIOS git now has support for EHCI USB controllers.  This
> is in addition to the UHCI and OHCI support already in SeaBIOS.  To
> obtain SeaBIOS, see:
>
> http://seabios.org/Download
>
> I've tested the EHCI support on my epia-cn.  Booting from USB drives
> is now noticeably faster.
>
> Currently SeaBIOS supports USB keyboards, USB hubs, and USB drives.
>
> Help with testing on a wider range of hardware would be appreciated.
>
YAHOO! Great work Kevin!


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



From kh.nirschl at googlemail.com  Fri Mar 12 10:22:27 2010
From: kh.nirschl at googlemail.com (Karl-Heinz Nirschl)
Date: Fri, 12 Mar 2010 10:22:27 +0100
Subject: [coreboot] Getting started with Coreboot on Intel Core
In-Reply-To: <f7bea4a91003090441h5bbe3dcbkd9b77b37e34dac53@mail.gmail.com>
References: <f7bea4a91003080931q241d05edtd2b8d03bf5a3831c@mail.gmail.com>
	<4B95443B.3050501@coresystems.de>
	<f7bea4a91003081245ge0d0519w62842fffb35bb0b1@mail.gmail.com>
	<4B956F71.2010001@coresystems.de>
	<f7bea4a91003081348w4e2c90b5ka0c618b621c319ee@mail.gmail.com>
	<4B95745B.9000101@coresystems.de>
	<f7bea4a91003081405v468eb152y80bb335afe6c7d7c@mail.gmail.com>
	<4B9575FC.8050907@coresystems.de>
	<f7bea4a91003090421g44717202o58915a9f51062a50@mail.gmail.com>
	<f7bea4a91003090441h5bbe3dcbkd9b77b37e34dac53@mail.gmail.com>
Message-ID: <f7bea4a91003120122m75ee6be0l4433d2fd012fec2f@mail.gmail.com>

Hi,

i still haven't found whats wrong. toolchain seems to be ok, as
everything works fine with qemu.


could someone confirm that kontron 986lcd-m is working in the current
svn version?


regards,

karl



2010/3/9 Karl-Heinz Nirschl <kh.nirschl at googlemail.com>:
> Hi,
>
> no i use crossgcc which looks fine, but still can't hang with postcode 0x23.
>
> if have the following in crt0.disasm:
> ?153 0148 B023E680 ? ? ? ? ? ? ?post_code(0x23)
> ?154
> ?155 014c E8FCFFFF ? ? ? ? ? ? ?call ? ?stage1_main
> ?155 ? ? ?FF
>
> and the following in romstage.inc (both from build dir):
>
> stage1_main:
> ? ? ? ?subl ? ?$24, %esp
> /APP
> / 29 "/home/xxx/coreboot/src/cpu/intel/model_6ex/cache_as_ram_disable.c" 1
> ? ? ? ?movb ? ?0xa4, %al
> ? ? ? ?outb ? ?%al, $0x80
>
> so i suppose i should at least see postcode 0xa4 if the call
> instruction succeeds.
>
> any further hints what i could have done wrong?
>
>
> regards,
>
> khn
>



From knuku at gap.upv.es  Fri Mar 12 12:00:40 2010
From: knuku at gap.upv.es (Knut Kujat)
Date: Fri, 12 Mar 2010 12:00:40 +0100
Subject: [coreboot] [PATCH] spd_rom FIX H8QME-2+
Message-ID: <4B9A1ED8.1070106@gap.upv.es>

Hello,

this patch fixes the issue where the board wasn't able to start after
getting unplugged. I also added some GPIOs so now the power on led is
working.

Signed-off-by: Knut Kujat <knuku at gap.upv.es>

---


-------------- next part --------------
A non-text attachment was scrubbed...
Name: spd_rom-FIX.patch
Type: text/x-patch
Size: 2764 bytes
Desc: not available
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20100312/b6a38d32/attachment.patch>

From r.marek at assembler.cz  Fri Mar 12 12:20:56 2010
From: r.marek at assembler.cz (Rudolf Marek)
Date: Fri, 12 Mar 2010 12:20:56 +0100
Subject: [coreboot] Supermicro H8QME-2+ mct_d fatal exit.
In-Reply-To: <4B97C847.5070506@gap.upv.es>
References: <4B87CF9D.9060204@gap.upv.es>	<201002261506.46602.christian.leber@ziti.uni-heidelberg.de>	<4B87DEFE.3010604@gap.upv.es>	<20100226154934.5727.qmail@stuge.se>	<4B8BC18D.1050400@gap.upv.es>	<4B8FC877.4030209@gap.upv.es>	<4B91295B.9060102@assembler.cz>	<4B912FE4.7080204@gap.upv.es>	<4B913A01.4090103@assembler.cz>	<13426df11003051007r29fee819p2fdea852891a4b58@mail.gmail.com>
	<4B94E384.4060002@gap.upv.es> <4B97C847.5070506@gap.upv.es>
Message-ID: <4B9A2398.2030803@assembler.cz>


> I finally know that my issue must be related with the smbus registers
> because on a vendor bios running machine and using i2cdetect and i2cdump
> I get several values for different i2c devices detected, I get the same
> values when I successfully start with coreboot. But when I start with
> coreboot and fail with mcr_d fatal exit those registers are blank, I
> know that because I found a nice piece of code dumping smbus registers
> on the h8dme board :D thx to the autor!!
>
> I also know that reading these registers out may cause them to get lost!
> I'm not sure why?!
>
>   

There is a multiplexer on SMBus, this confirms my theory. Please check
the GPIO.

Imagine the multiplexer acts as some kind of rail switch. The
transactions on smbus never reach thhe memory chips (the SPD eeprom).
You need to find a pin to control the multiplexer.

Rudolf



> Now my question is how do I initialize these registers with the values
> known from the vendor BIOS? smb_write_byte doesn't seems to work or
> maybe I'm using it wrong.
>
> THX,
> Knut Kujat.
>
>
>
> Knut Kujat escribi?:
>   
>> Hello,
>>
>> thx all of you for your comments. Here a little update :)
>>
>> I now know why the boards worked just fine up here in my lab. To know if
>> the board would work after being unplugged I always "only" unplugged the
>> electrical cable but never the monitor attached to the board I figured
>> out that the monitor is providing enough juice to maintain whatever
>> alive in the board so after plugging the electrical cable on again
>> coreboot started fine. Another thing I figured out is that it seems that
>> the front leds of the board a managed by GPIO as well, is this right? If
>> so it seems that something is wrong with GPIO because the power on led
>> never works with coreboot.
>>
>> thx,
>> Knut Kujat.
>>
>>
>>
>> ron minnich escribi?:
>>   
>>     
>>> Just FYI:
>>>
>>> on our first system with Arima boards in 2002, everything worked well
>>> until we started booting 64-bit kernels. I'm not kidding. We did not
>>> find the SMBUS MUX on the boards until we had unreliable coreboot
>>> boots of 64-bit kernels. For quite some time the boards worked fine.
>>> Ollie found the SMBUS MUX by examining schematics.
>>>
>>> So the SMBUS mux can appear in strange ways, at strange times. This
>>> sounds like one of those times. SMBUS muxes are more common than you
>>> might think and the default power-on state is not always very well
>>> determined.
>>>
>>> ron
>>>
>>>   
>>>     
>>>       
>>   
>>     
>
>   





From knuku at gap.upv.es  Fri Mar 12 12:27:15 2010
From: knuku at gap.upv.es (Knut Kujat)
Date: Fri, 12 Mar 2010 12:27:15 +0100
Subject: [coreboot] Supermicro H8QME-2+ mct_d fatal exit.
In-Reply-To: <4B9A2398.2030803@assembler.cz>
References: <4B87CF9D.9060204@gap.upv.es>	<201002261506.46602.christian.leber@ziti.uni-heidelberg.de>	<4B87DEFE.3010604@gap.upv.es>	<20100226154934.5727.qmail@stuge.se>	<4B8BC18D.1050400@gap.upv.es>	<4B8FC877.4030209@gap.upv.es>	<4B91295B.9060102@assembler.cz>	<4B912FE4.7080204@gap.upv.es>	<4B913A01.4090103@assembler.cz>	<13426df11003051007r29fee819p2fdea852891a4b58@mail.gmail.com>	<4B94E384.4060002@gap.upv.es>
	<4B97C847.5070506@gap.upv.es> <4B9A2398.2030803@assembler.cz>
Message-ID: <4B9A2513.7040807@gap.upv.es>

Rudolf Marek escribi?:
>
>> I finally know that my issue must be related with the smbus registers
>> because on a vendor bios running machine and using i2cdetect and i2cdump
>> I get several values for different i2c devices detected, I get the same
>> values when I successfully start with coreboot. But when I start with
>> coreboot and fail with mcr_d fatal exit those registers are blank, I
>> know that because I found a nice piece of code dumping smbus registers
>> on the h8dme board :D thx to the autor!!
>>
>> I also know that reading these registers out may cause them to get lost!
>> I'm not sure why?!
>>
>>   
>
> There is a multiplexer on SMBus, this confirms my theory. Please check
> the GPIO.
>
> Imagine the multiplexer acts as some kind of rail switch. The
> transactions on smbus never reach thhe memory chips (the SPD eeprom).
> You need to find a pin to control the multiplexer.
>
> Rudolf
Thanks, because of your hints I was able to figure out that I needed to
set up the spd_rom in romstage.c I also added the GPIOs settings as read
from vendor BIOS and now the power on led works :).

thx,
Knut Kujat.

>
>
>
>> Now my question is how do I initialize these registers with the values
>> known from the vendor BIOS? smb_write_byte doesn't seems to work or
>> maybe I'm using it wrong.
>>
>> THX,
>> Knut Kujat.
>>
>>
>>
>> Knut Kujat escribi?:
>>  
>>> Hello,
>>>
>>> thx all of you for your comments. Here a little update :)
>>>
>>> I now know why the boards worked just fine up here in my lab. To
>>> know if
>>> the board would work after being unplugged I always "only" unplugged
>>> the
>>> electrical cable but never the monitor attached to the board I figured
>>> out that the monitor is providing enough juice to maintain whatever
>>> alive in the board so after plugging the electrical cable on again
>>> coreboot started fine. Another thing I figured out is that it seems
>>> that
>>> the front leds of the board a managed by GPIO as well, is this
>>> right? If
>>> so it seems that something is wrong with GPIO because the power on led
>>> never works with coreboot.
>>>
>>> thx,
>>> Knut Kujat.
>>>
>>>
>>>
>>> ron minnich escribi?:
>>>      
>>>> Just FYI:
>>>>
>>>> on our first system with Arima boards in 2002, everything worked well
>>>> until we started booting 64-bit kernels. I'm not kidding. We did not
>>>> find the SMBUS MUX on the boards until we had unreliable coreboot
>>>> boots of 64-bit kernels. For quite some time the boards worked fine.
>>>> Ollie found the SMBUS MUX by examining schematics.
>>>>
>>>> So the SMBUS mux can appear in strange ways, at strange times. This
>>>> sounds like one of those times. SMBUS muxes are more common than you
>>>> might think and the default power-on state is not always very well
>>>> determined.
>>>>
>>>> ron
>>>>
>>>>             
>>>       
>>
>>   
>
>
>




From mylesgw at gmail.com  Fri Mar 12 16:50:23 2010
From: mylesgw at gmail.com (Myles Watson)
Date: Fri, 12 Mar 2010 08:50:23 -0700
Subject: [coreboot] [PATCH] New config option for 440BX northbridge
In-Reply-To: <b72cdb061003112002w777153b4t9a99ac557853a02c@mail.gmail.com>
References: <b72cdb061003112002w777153b4t9a99ac557853a02c@mail.gmail.com>
Message-ID: <2831fecf1003120750h3eda658uf44db5bc431e6b2e@mail.gmail.com>

On Thu, Mar 11, 2010 at 9:02 PM, Keith Hui <buurin at gmail.com> wrote:

> Hi all,
>
> This patch adds a Kconfig option for 440BX that enable compiling in the
> proper value for the SDRAMPWR bit in SDRAMC register for 3 or 4 DIMM slots.
> No more hard coding for 4 DIMM slots. Also sets it to be permanently enabled
> for a few ASUS boards (P2B-LS/D/DS, P3B-F) that I know for sure have 4
> slots.
>
> This option only appears when Expert mode is selected in Kconfig.
>
I don't think the option should appear in the menu.  It should be set by
board developers in the Kconfig file for the board.

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

From mylesgw at gmail.com  Fri Mar 12 17:09:58 2010
From: mylesgw at gmail.com (Myles Watson)
Date: Fri, 12 Mar 2010 09:09:58 -0700
Subject: [coreboot] [PATCH] spd_rom FIX H8QME-2+
In-Reply-To: <4B9A1ED8.1070106@gap.upv.es>
References: <4B9A1ED8.1070106@gap.upv.es>
Message-ID: <2831fecf1003120809l157b7e9fqedc6fa401179c644@mail.gmail.com>

On Fri, Mar 12, 2010 at 4:00 AM, Knut Kujat <knuku at gap.upv.es> wrote:

> Hello,
>
> this patch fixes the issue where the board wasn't able to start after
> getting unplugged. I also added some GPIOs so now the power on led is
> working.
>

The spacing doesn't look like it follows these guidelines:
http://www.coreboot.org/Development_Guidelines#Coding_Style

 static inline void activate_spd_rom(const struct mem_controller *ctrl)
 {
-    /* nothing to do */
+#define SMBUS_SWITCH1 0x70
+#define SMBUS_SWITCH2 0x72
+//     unsigned device=(ctrl->spd_addr[0])>>8;
It's unclear what this comment is for.  Maybe just drop it?

Signed-off-by: Knut Kujat <knuku at gap.upv.es>

With the formatting and comment addressed:
Acked-by: Myles Watson <mylesgw at gmail.com>

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

From knuku at gap.upv.es  Fri Mar 12 18:26:38 2010
From: knuku at gap.upv.es (Knut Kujat)
Date: Fri, 12 Mar 2010 18:26:38 +0100
Subject: [coreboot] [PATCH] spd_rom FIX H8QME-2+
In-Reply-To: <2831fecf1003120809l157b7e9fqedc6fa401179c644@mail.gmail.com>
References: <4B9A1ED8.1070106@gap.upv.es>
	<2831fecf1003120809l157b7e9fqedc6fa401179c644@mail.gmail.com>
Message-ID: <4B9A794E.4020008@gap.upv.es>

Myles Watson escribi?:
>
>
> On Fri, Mar 12, 2010 at 4:00 AM, Knut Kujat <knuku at gap.upv.es
> <mailto:knuku at gap.upv.es>> wrote:
>
>     Hello,
>
>     this patch fixes the issue where the board wasn't able to start after
>     getting unplugged. I also added some GPIOs so now the power on led is
>     working.
>
>
> The spacing doesn't look like it follows these guidelines:
> http://www.coreboot.org/Development_Guidelines#Coding_Style
Sorry, Patrick tells me so, too! I'll take a look at that article this
weekend.
>
>  static inline void activate_spd_rom(const struct mem_controller *ctrl)
>  {
> -    /* nothing to do */
> +#define SMBUS_SWITCH1 0x70
> +#define SMBUS_SWITCH2 0x72
> +//     unsigned device=(ctrl->spd_addr[0])>>8;
> It's unclear what this comment is for.  Maybe just drop it?
Yes, that one can go, since I was testing multiple options because I
wasn't really sure what to do.
>
>     Signed-off-by: Knut Kujat <knuku at gap.upv.es <mailto:knuku at gap.upv.es>>
>
> With the formatting and comment addressed:
> Acked-by: Myles Watson <mylesgw at gmail.com <mailto:mylesgw at gmail.com>>
>
> Thanks,
> Myles

thx and have a nice weekend,
Knut Kujat.




From buurin at gmail.com  Fri Mar 12 23:55:49 2010
From: buurin at gmail.com (Keith Hui)
Date: Fri, 12 Mar 2010 17:55:49 -0500
Subject: [coreboot] [PATCH] New config option for 440BX northbridge
In-Reply-To: <13426df11003121440t65cd6c48yc9bb15e54c66ad2c@mail.gmail.com>
References: <b72cdb061003112002w777153b4t9a99ac557853a02c@mail.gmail.com>
	<2831fecf1003120750h3eda658uf44db5bc431e6b2e@mail.gmail.com>
	<13426df11003121440t65cd6c48yc9bb15e54c66ad2c@mail.gmail.com>
Message-ID: <b72cdb061003121455o62bf4431i8926405bcbdf0d30@mail.gmail.com>

On Fri, Mar 12, 2010 at 5:40 PM, ron minnich <rminnich at gmail.com> wrote:

> On Fri, Mar 12, 2010 at 7:50 AM, Myles Watson <mylesgw at gmail.com> wrote:
>
> > I don't think the option should appear in the menu.  It should be set by
> > board developers in the Kconfig file for the board.
>
> Absolutely correct :-)
>
> ron
>

If we go through all the Kconfigs for all 440BX boards and identify all that
have 4 slots, and enter this setting for all of them, done before my 440BX
ram init code is ready. ;-) There is a reason for expert mode, no?

The P2B-F picture shown on our wiki also shows 4 slots. ;-)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20100312/cf5fd226/attachment.html>

From rminnich at gmail.com  Sat Mar 13 00:07:19 2010
From: rminnich at gmail.com (ron minnich)
Date: Fri, 12 Mar 2010 15:07:19 -0800
Subject: [coreboot] [PATCH] New config option for 440BX northbridge
In-Reply-To: <b72cdb061003121455o62bf4431i8926405bcbdf0d30@mail.gmail.com>
References: <b72cdb061003112002w777153b4t9a99ac557853a02c@mail.gmail.com>
	<2831fecf1003120750h3eda658uf44db5bc431e6b2e@mail.gmail.com>
	<13426df11003121440t65cd6c48yc9bb15e54c66ad2c@mail.gmail.com>
	<b72cdb061003121455o62bf4431i8926405bcbdf0d30@mail.gmail.com>
Message-ID: <13426df11003121507y6ffbafc2kf77c3d74396edb82@mail.gmail.com>

On Fri, Mar 12, 2010 at 2:55 PM, Keith Hui <buurin at gmail.com> wrote:

> If we go through all the Kconfigs for all 440BX boards and identify all that
> have 4 slots, and enter this setting for all of them, done before my 440BX
> ram init code is ready. ;-) There is a reason for expert mode, no?

I think this goes beyond expert mode. It seems to me it is a setting
that can render the machine unbootable if configured incorrectly. Even
for experts, I don't think it should be visible in Kconfig.

thanks

ron



From rminnich at gmail.com  Fri Mar 12 23:40:06 2010
From: rminnich at gmail.com (ron minnich)
Date: Fri, 12 Mar 2010 14:40:06 -0800
Subject: [coreboot] [PATCH] New config option for 440BX northbridge
In-Reply-To: <2831fecf1003120750h3eda658uf44db5bc431e6b2e@mail.gmail.com>
References: <b72cdb061003112002w777153b4t9a99ac557853a02c@mail.gmail.com>
	<2831fecf1003120750h3eda658uf44db5bc431e6b2e@mail.gmail.com>
Message-ID: <13426df11003121440t65cd6c48yc9bb15e54c66ad2c@mail.gmail.com>

On Fri, Mar 12, 2010 at 7:50 AM, Myles Watson <mylesgw at gmail.com> wrote:

> I don't think the option should appear in the menu.? It should be set by
> board developers in the Kconfig file for the board.

Absolutely correct :-)

ron



From joe at settoplinux.org  Sat Mar 13 01:08:51 2010
From: joe at settoplinux.org (Joseph Smith)
Date: Fri, 12 Mar 2010 19:08:51 -0500
Subject: [coreboot] [PATCH] New config option for 440BX northbridge
In-Reply-To: <13426df11003121507y6ffbafc2kf77c3d74396edb82@mail.gmail.com>
References: <b72cdb061003112002w777153b4t9a99ac557853a02c@mail.gmail.com>	<2831fecf1003120750h3eda658uf44db5bc431e6b2e@mail.gmail.com>	<13426df11003121440t65cd6c48yc9bb15e54c66ad2c@mail.gmail.com>	<b72cdb061003121455o62bf4431i8926405bcbdf0d30@mail.gmail.com>
	<13426df11003121507y6ffbafc2kf77c3d74396edb82@mail.gmail.com>
Message-ID: <4B9AD793.2000008@settoplinux.org>

On 03/12/2010 06:07 PM, ron minnich wrote:
> On Fri, Mar 12, 2010 at 2:55 PM, Keith Hui<buurin at gmail.com>  wrote:
>
>> If we go through all the Kconfigs for all 440BX boards and identify all that
>> have 4 slots, and enter this setting for all of them, done before my 440BX
>> ram init code is ready. ;-) There is a reason for expert mode, no?
>
> I think this goes beyond expert mode. It seems to me it is a setting
> that can render the machine unbootable if configured incorrectly. Even
> for experts, I don't think it should be visible in Kconfig.
>
has anyone even tested this yet???

 >> slot4_detect = (spd_read_byte((DIMM_SPD_BASE + 3), SPD_MEMORY_TYPE);
 >>
 >> if (slot4_detect != 0xff) {
 >>
 >>      /* We have 4 slots */
 >>      ----Set bit 4 in SDRAMPWR----
 >>      #define DIMM_SOCKETS 4
 >> } else {
 >>
 >>      /* We have 3 slots */
 >>      ----Set bit 4 in SDRAMPWR----
 >>      #define DIMM_SOCKETS 3
 >> }
 >>


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



From mylesgw at gmail.com  Sat Mar 13 00:14:31 2010
From: mylesgw at gmail.com (Myles Watson)
Date: Fri, 12 Mar 2010 16:14:31 -0700
Subject: [coreboot] [PATCH] New config option for 440BX northbridge
In-Reply-To: <13426df11003121507y6ffbafc2kf77c3d74396edb82@mail.gmail.com>
References: <b72cdb061003112002w777153b4t9a99ac557853a02c@mail.gmail.com>
	<2831fecf1003120750h3eda658uf44db5bc431e6b2e@mail.gmail.com>
	<13426df11003121440t65cd6c48yc9bb15e54c66ad2c@mail.gmail.com>
	<b72cdb061003121455o62bf4431i8926405bcbdf0d30@mail.gmail.com>
	<13426df11003121507y6ffbafc2kf77c3d74396edb82@mail.gmail.com>
Message-ID: <CD031F2B11F64D008FA387C3C402BC5A@chimp>

> > If we go through all the Kconfigs for all 440BX boards and identify all
> that
> > have 4 slots, and enter this setting for all of them, done before my
> 440BX
> > ram init code is ready. ;-) There is a reason for expert mode, no?
> 
> I think this goes beyond expert mode. It seems to me it is a setting
> that can render the machine unbootable if configured incorrectly. Even
> for experts, I don't think it should be visible in Kconfig.

I agree.  Since the boards used to be hard coded, lets set all the boards to
match what they were hard coded to.  Then no one gets a broken board from
the change.  To make it easier, the default Kconfig option could match the
hard coded value.

Thanks,
Myles




From buurin at gmail.com  Sat Mar 13 04:44:56 2010
From: buurin at gmail.com (Keith Hui)
Date: Fri, 12 Mar 2010 22:44:56 -0500
Subject: [coreboot] [PATCH] New config option for 440BX northbridge
In-Reply-To: <4B9AD793.2000008@settoplinux.org>
References: <b72cdb061003112002w777153b4t9a99ac557853a02c@mail.gmail.com>
	<2831fecf1003120750h3eda658uf44db5bc431e6b2e@mail.gmail.com>
	<13426df11003121440t65cd6c48yc9bb15e54c66ad2c@mail.gmail.com>
	<b72cdb061003121455o62bf4431i8926405bcbdf0d30@mail.gmail.com>
	<13426df11003121507y6ffbafc2kf77c3d74396edb82@mail.gmail.com>
	<4B9AD793.2000008@settoplinux.org>
Message-ID: <b72cdb061003121944g1b5cc6eka8aa30fa548540cf@mail.gmail.com>

On Fri, Mar 12, 2010 at 7:08 PM, Joseph Smith <joe at settoplinux.org> wrote:

> On 03/12/2010 06:07 PM, ron minnich wrote:
>
>> On Fri, Mar 12, 2010 at 2:55 PM, Keith Hui<buurin at gmail.com>  wrote:
>>
>>  If we go through all the Kconfigs for all 440BX boards and identify all
>>> that
>>> have 4 slots, and enter this setting for all of them, done before my
>>> 440BX
>>> ram init code is ready. ;-) There is a reason for expert mode, no?
>>>
>>
>> I think this goes beyond expert mode. It seems to me it is a setting
>> that can render the machine unbootable if configured incorrectly. Even
>> for experts, I don't think it should be visible in Kconfig.
>>
>>  has anyone even tested this yet???
>
> >> slot4_detect = (spd_read_byte((DIMM_SPD_BASE + 3), SPD_MEMORY_TYPE);
> >>
> >> if (slot4_detect != 0xff) {
> >>
> >>      /* We have 4 slots */
> >>      ----Set bit 4 in SDRAMPWR----
> >>      #define DIMM_SOCKETS 4
> >> } else {
> >>
> >>      /* We have 3 slots */
> >>      ----Set bit 4 in SDRAMPWR----
> >>      #define DIMM_SOCKETS 3
> >> }
> >>
>
> You put a #define inside a actual code branch? I highly doubt if that would
work AT ALL. :-)

And this code will fail on any 4-DIMM boards without a stick installed in
slot 3.

There is a possibility that a board would have 3 DIMM slots, yet only wired
for GCKE. I doubt any manufacturer would actually do that, but still a
possibility. Dumping the BX configuration space with factory BIOS installed
still provides the most authoritative answer.

We currently have support for about 15 440BX mainboards. If someone can go
through them and get the correct SDRAMPWR setting for all of them that we
don't already know - especially those with 3 DIMM slots, I'll code this
setting for all of them and get it out of sight.

Thanks
Keith
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20100312/5826d342/attachment.html>

From buurin at gmail.com  Sat Mar 13 06:53:50 2010
From: buurin at gmail.com (Keith Hui)
Date: Sat, 13 Mar 2010 00:53:50 -0500
Subject: [coreboot] RAM support for 440BX
Message-ID: <b72cdb061003122153v68ffb73vbdfd53b4a21d4d18@mail.gmail.com>

Below are debug outputs of my new RAM init code. As you can see it isn't
quite working. Can this output help in finding out why?

I had to remove a bunch of debugging messages as romcc is finally running
out of registers.

The code is again attached for reference.

Stick used is a 128MB PC133 DIMM in slot 0.

Thanks
Keith

coreboot-4.0-r5202M Fri Mar 12 23:12:55 EST 2010 starting...
SMBus controller enabled
Found DIMM in slot 00
dra = 04
Northbridge following SDRAM init:
PCI: 00:00.00
00: 86 80 90 71 06 00 10 22 03 00 00 06 00 00 00 00
10: 08 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 a0 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: 0c 8a 04 03 00 00 00 08 03 30 33 33 33 33 33 33
60: 08 10 10 10 10 10 10 10 00 ec 3f 00 a0 fa 00 00
70: 00 1f 02 38 05 00 17 01 03 03 00 38 10 00 00 00
80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
90: 80 00 00 00 04 61 00 00 00 05 00 00 00 00 00 00
a0: 02 00 10 00 03 02 00 1f 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 18 0c 84 ff 1f 00 00 00
d0: 00 00 00 00 00 00 00 00 0c 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 f8 00 00 20 0f 00 00 00 00 00 00
RAM Enable 1: Apply NOP
CAS latency: 02
    Sending RAM command 0x0001 to 0x00000000
    Sending RAM command 0x0001 to 0x04000000
RAM Enable 2: Precharge all
CAS latency: 02
    Sending RAM command 0x0002 to 0x00000000
    Sending RAM command 0x0002 to 0x04000000
RAM Enable 3: CBR
CAS latency: 02
    Sending RAM command 0x0004 to 0x00000000
    Sending RAM command 0x0004 to 0x04000000
CAS latency: 02
    Sending RAM command 0x0004 to 0x00000000
    Sending RAM command 0x0004 to 0x04000000
CAS latency: 02
    Sending RAM command 0x0004 to 0x00000000
    Sending RAM command 0x0004 to 0x04000000
CAS latency: 02
    Sending RAM command 0x0004 to 0x00000000
    Sending RAM command 0x0004 to 0x04000000
CAS latency: 02
    Sending RAM command 0x0004 to 0x00000000
    Sending RAM command 0x0004 to 0x04000000
CAS latency: 02
    Sending RAM command 0x0004 to 0x00000000
    Sending RAM command 0x0004 to 0x04000000
CAS latency: 02
    Sending RAM command 0x0004 to 0x00000000
    Sending RAM command 0x0004 to 0x04000000
CAS latency: 02
    Sending RAM command 0x0004 to 0x00000000
    Sending RAM command 0x0004 to 0x04000000
RAM Enable 4: Mode register set
CAS latency: 02
    Sending RAM command 0x0003 to 0x00000150
    Sending RAM command 0x0003 to 0x04000150
RAM Enable 5: Normal operation
RAM Enable 6: Enable refresh
    Enabling refresh (DRAMC = 0x09) for DIMM 00
Testing DRAM : 00000000-000a0000
DRAM fill: 00000000-000a0000
000a0000
DRAM filled
DRAM verify: 00000000-000a0000
Fail: @0x00000000 Read value=0x0009ff80
Fail: @0x00000004 Read value=0x0009fffc
Fail: @0x00000008 Read value=0x0009ff80
Fail: @0x0000000c Read value=0x0009fffc
Fail: @0x00000010 Read value=0x0009ff80
Fail: @0x00000014 Read value=0x0009fffc
Fail: @0x00000018 Read value=0x0009ff80
Fail: @0x0000001c Read value=0x0009fffc
Fail: @0x00000020 Read value=0x0009ff80
Fail: @0x00000024 Read value=0x0009fffc
Fail: @0x00000028 Read value=0x0009ff80
Fail: @0x0000002c Read value=0x0009fffc
Fail: @0x00000030 Read value=0x0009ff80
Fail: @0x00000034 Read value=0x0009fffc
Fail: @0x00000038 Read value=0x0009ff80
Fail: @0x0000003c Read value=0x0009fffc
Fail: @0x00000040 Read value=0x0009ff80
Fail: @0x00000044 Read value=0x0009fffc
Fail: @0x00000048 Read value=0x0009ff80
Fail: @0x0000004c Read value=0x0009fffc
Fail: @0x00000050 Read value=0x0009ff80
Fail: @0x00000054 Read value=0x0009fffc
Fail: @0x00000058 Read value=0x0009ff80
Fail: @0x0000005c Read value=0x0009fffc
Fail: @0x00000060 Read value=0x0009ff80
Fail: @0x00000064 Read value=0x0009fffc
Fail: @0x00000068 Read value=0x0009ff80
Fail: @0x0000006c Read value=0x0009fffc
Fail: @0x00000070 Read value=0x0009ff80
Fail: @0x00000074 Read value=0x0009fffc
Fail: @0x00000078 Read value=0x0009ff80
Fail: @0x0000007c Read value=0x0009fffc
Fail: @0x00000080 Read value=0x0009ff80
Fail: @0x00000084 Read value=0x0009fffc
Fail: @0x00000088 Read value=0x0009ff80
Fail: @0x0000008c Read value=0x0009fffc
Fail: @0x00000090 Read value=0x0009ff80
Fail: @0x00000094 Read value=0x0009fffc
Fail: @0x00000098 Read value=0x0009ff80
Fail: @0x0000009c Read value=0x0009fffc
Fail: @0x000000a0 Read value=0x0009ff80
Fail: @0x000000a4 Read value=0x0009fffc
Fail: @0x000000a8 Read value=0x0009ff80
Fail: @0x000000ac Read value=0x0009fffc
Fail: @0x000000b0 Read value=0x0009ff80
Fail: @0x000000b4 Read value=0x0009fffc
Fail: @0x000000b8 Read value=0x0009ff80
Fail: @0x000000bc Read value=0x0009fffc
Fail: @0x000000c0 Read value=0x0009ff80
Fail: @0x000000c4 Read value=0x0009fffc
Fail: @0x000000c8 Read value=0x0009ff80
Fail: @0x000000cc Read value=0x0009fffc
Fail: @0x000000d0 Read value=0x0009ff80
Fail: @0x000000d4 Read value=0x0009fffc
Fail: @0x000000d8 Read value=0x0009ff80
Fail: @0x000000dc Read value=0x0009fffc
Fail: @0x000000e0 Read value=0x0009ff80
Fail: @0x000000e4 Read value=0x0009fffc
Fail: @0x000000e8 Read value=0x0009ff80
Fail: @0x000000ec Read value=0x0009fffc
Fail: @0x000000f0 Read value=0x0009ff80
Fail: @0x000000f4 Read value=0x0009fffc
Fail: @0x000000f8 Read value=0x0009ff80
Fail: @0x000000fc Read value=0x0009fffc
Fail: @0x00000100 Read value=0x0009ff80
Fail: @0x00000104 Read value=0x0009fffc
Fail: @0x00000108 Read value=0x0009ff80
Fail: @0x0000010c Read value=0x0009fffc
Fail: @0x00000110 Read value=0x0009ff80
Fail: @0x00000114 Read value=0x0009fffc
Fail: @0x00000118 Read value=0x0009ff80
Fail: @0x0000011c Read value=0x0009fffc
Fail: @0x00000120 Read value=0x0009ff80
Fail: @0x00000124 Read value=0x0009fffc
Fail: @0x00000128 Read value=0x0009ff80
Fail: @0x0000012c Read value=0x0009fffc
Fail: @0x00000130 Read value=0x0009ff80
Fail: @0x00000134 Read value=0x0009fffc
Fail: @0x00000138 Read value=0x0009ff80
Fail: @0x0000013c Read value=0x0009fffc
Fail: @0x00000140 Read value=0x0009ff80
Fail: @0x00000144 Read value=0x0009fffc
Fail: @0x00000148 Read value=0x0009ff80
Fail: @0x0000014c Read value=0x0009fffc
Fail: @0x00000150 Read value=0x0009ff80
Fail: @0x00000154 Read value=0x0009fffc
Fail: @0x00000158 Read value=0x0009ff80
Fail: @0x0000015c Read value=0x0009fffc
Fail: @0x00000160 Read value=0x0009ff80
Fail: @0x00000164 Read value=0x0009fffc
Fail: @0x00000168 Read value=0x0009ff80
Fail: @0x0000016c Read value=0x0009fffc
Fail: @0x00000170 Read value=0x0009ff80
Fail: @0x00000174 Read value=0x0009fffc
Fail: @0x00000178 Read value=0x0009ff80
Fail: @0x0000017c Read value=0x0009fffc
Fail: @0x00000180 Read value=0x0009ff80
Fail: @0x00000184 Read value=0x0009fffc
Fail: @0x00000188 Read value=0x0009ff80
Fail: @0x0000018c Read value=0x0009fffc
Fail: @0x00000190 Read value=0x0009ff80
Fail: @0x00000194 Read value=0x0009fffc
Fail: @0x00000198 Read value=0x0009ff80
Fail: @0x0000019c Read value=0x0009fffc
Fail: @0x000001a0 Read value=0x0009ff80
Fail: @0x000001a4 Read value=0x0009fffc
Fail: @0x000001a8 Read value=0x0009ff80
Fail: @0x000001ac Read value=0x0009fffc
Fail: @0x000001b0 Read value=0x0009ff80
Fail: @0x000001b4 Read value=0x0009fffc
Fail: @0x000001b8 Read value=0x0009ff80
Fail: @0x000001bc Read value=0x0009fffc
Fail: @0x000001c0 Read value=0x0009ff80
Fail: @0x000001c4 Read value=0x0009fffc
Fail: @0x000001c8 Read value=0x0009ff80
Fail: @0x000001cc Read value=0x0009fffc
Fail: @0x000001d0 Read value=0x0009ff80
Fail: @0x000001d4 Read value=0x0009fffc
Fail: @0x000001d8 Read value=0x0009ff80
Fail: @0x000001dc Read value=0x0009fffc
Fail: @0x000001e0 Read value=0x0009ff80
Fail: @0x000001e4 Read value=0x0009fffc
Fail: @0x000001e8 Read value=0x0009ff80
Fail: @0x000001ec Read value=0x0009fffc
Fail: @0x000001f0 Read value=0x0009ff80
Fail: @0x000001f4 Read value=0x0009fffc
Fail: @0x000001f8 Read value=0x0009ff80
Fail: @0x000001fc Read value=0x0009fffc
Fail: @0x00000200 Read value=0x0009ff80
Fail: @0x00000204 Read value=0x0009fffc
Fail: @0x00000208 Read value=0x0009ff80
Fail: @0x0000020c Read value=0x0009fffc
Fail: @0x00000210 Read value=0x0009ff80
Fail: @0x00000214 Read value=0x0009fffc
Fail: @0x00000218 Read value=0x0009ff80
Fail: @0x0000021c Read value=0x0009fffc
Fail: @0x00000220 Read value=0x0009ff80
Fail: @0x00000224 Read value=0x0009fffc
Fail: @0x00000228 Read value=0x0009ff80
Fail: @0x0000022c Read value=0x0009fffc
Fail: @0x00000230 Read value=0x0009ff80
Fail: @0x00000234 Read value=0x0009fffc
Fail: @0x00000238 Read value=0x0009ff80
Fail: @0x0000023c Read value=0x0009fffc
Fail: @0x00000240 Read value=0x0009ff80
Fail: @0x00000244 Read value=0x0009fffc
Fail: @0x00000248 Read value=0x0009ff80
Fail: @0x0000024c Read value=0x0009fffc
Fail: @0x00000250 Read value=0x0009ff80
Fail: @0x00000254 Read value=0x0009fffc
Fail: @0x00000258 Read value=0x0009ff80
Fail: @0x0000025c Read value=0x0009fffc
Fail: @0x00000260 Read value=0x0009ff80
Fail: @0x00000264 Read value=0x0009fffc
Fail: @0x00000268 Read value=0x0009ff80
Fail: @0x0000026c Read value=0x0009fffc
Fail: @0x00000270 Read value=0x0009ff80
Fail: @0x00000274 Read value=0x0009fffc
Fail: @0x00000278 Read value=0x0009ff80
Fail: @0x0000027c Read value=0x0009fffc
Fail: @0x00000280 Read value=0x0009ff80
Fail: @0x00000284 Read value=0x0009fffc
Fail: @0x00000288 Read value=0x0009ff80
Fail: @0x0000028c Read value=0x0009fffc
Fail: @0x00000290 Read value=0x0009ff80
Fail: @0x00000294 Read value=0x0009fffc
Fail: @0x00000298 Read value=0x0009ff80
Fail: @0x0000029c Read value=0x0009fffc
Fail: @0x000002a0 Read value=0x0009ff80
Fail: @0x000002a4 Read value=0x0009fffc
Fail: @0x000002a8 Read value=0x0009ff80
Fail: @0x000002ac Read value=0x0009fffc
Fail: @0x000002b0 Read value=0x0009ff80
Fail: @0x000002b4 Read value=0x0009fffc
Fail: @0x000002b8 Read value=0x0009ff80
Fail: @0x000002bc Read value=0x0009fffc
Fail: @0x000002c0 Read value=0x0009ff80
Fail: @0x000002c4 Read value=0x0009fffc
Fail: @0x000002c8 Read value=0x0009ff80
Fail: @0x000002cc Read value=0x0009fffc
Fail: @0x000002d0 Read value=0x0009ff80
Fail: @0x000002d4 Read value=0x0009fffc
Fail: @0x000002d8 Read value=0x0009ff80
Fail: @0x000002dc Read value=0x0009fffc
Fail: @0x000002e0 Read value=0x0009ff80
Fail: @0x000002e4 Read value=0x0009fffc
Fail: @0x000002e8 Read value=0x0009ff80
Fail: @0x000002ec Read value=0x0009fffc
Fail: @0x000002f0 Read value=0x0009ff80
Fail: @0x000002f4 Read value=0x0009fffc
Fail: @0x000002f8 Read value=0x0009ff80
Fail: @0x000002fc Read value=0x0009fffc
Fail: @0x00000300 Read value=0x0009ff80
Fail: @0x00000304 Read value=0x0009fffc
Fail: @0x00000308 Read value=0x0009ff80
Fail: @0x0000030c Read value=0x0009fffc
Fail: @0x00000310 Read value=0x0009ff80
Fail: @0x00000314 Read value=0x0009fffc
Fail: @0x00000318 Read value=0x0009ff80
Fail: @0x0000031c Read value=0x0009fffc
Fail: @0x00000320 Read value=0x0009ff80
Fail: @0x00000324 Read value=0x0009fffc
Fail: @0x00000328 Read value=0x0009ff80
Fail: @0x0000032c Read value=0x0009fffc
Fail: @0x00000330 Read value=0x0009ff80
Fail: @0x00000334 Read value=0x0009fffc
Fail: @0x00000338 Read value=0x0009ff80
Fail: @0x0000033c Read value=0x0009fffc
Fail: @0x00000340 Read value=0x0009ff80
Fail: @0x00000344 Read value=0x0009fffc
Fail: @0x00000348 Read value=0x0009ff80
Fail: @0x0000034c Read value=0x0009fffc
Fail: @0x00000350 Read value=0x0009ff80
Fail: @0x00000354 Read value=0x0009fffc
Fail: @0x00000358 Read value=0x0009ff80
Fail: @0x0000035c Read value=0x0009fffc
Fail: @0x00000360 Read value=0x0009ff80
Fail: @0x00000364 Read value=0x0009fffc
Fail: @0x00000368 Read value=0x0009ff80
Fail: @0x0000036c Read value=0x0009fffc
Fail: @0x00000370 Read value=0x0009ff80
Fail: @0x00000374 Read value=0x0009fffc
Fail: @0x00000378 Read value=0x0009ff80
Fail: @0x0000037c Read value=0x0009fffc
Fail: @0x00000380 Read value=0x0009ff80
Fail: @0x00000384 Read value=0x0009fffc
Fail: @0x00000388 Read value=0x0009ff80
Fail: @0x0000038c Read value=0x0009fffc
Fail: @0x00000390 Read value=0x0009ff80
Fail: @0x00000394 Read value=0x0009fffc
Fail: @0x00000398 Read value=0x0009ff80
Fail: @0x0000039c Read value=0x0009fffc
Fail: @0x000003a0 Read value=0x0009ff80
Fail: @0x000003a4 Read value=0x0009fffc
Fail: @0x000003a8 Read value=0x0009ff80
Fail: @0x000003ac Read value=0x0009fffc
Fail: @0x000003b0 Read value=0x0009ff80
Fail: @0x000003b4 Read value=0x0009fffc
Fail: @0x000003b8 Read value=0x0009ff80
Fail: @0x000003bc Read value=0x0009fffc
Fail: @0x000003c0 Read value=0x0009ff80
Fail: @0x000003c4 Read value=0x0009fffc
Fail: @0x000003c8 Read value=0x0009ff80
Fail: @0x000003cc Read value=0x0009fffc
Fail: @0x000003d0 Read value=0x0009ff80
Fail: @0x000003d4 Read value=0x0009fffc
Fail: @0x000003d8 Read value=0x0009ff80
Fail: @0x000003dc Read value=0x0009fffc
Fail: @0x000003e0 Read value=0x0009ff80
Fail: @0x000003e4 Read value=0x0009fffc
Fail: @0x000003e8 Read value=0x0009ff80
Fail: @0x000003ec Read value=0x0009fffc
Fail: @0x000003f0 Read value=0x0009ff80
Fail: @0x000003f4 Read value=0x0009fffc
Fail: @0x000003f8 Read value=0x0009ff80
Fail: @0x000003fc Read value=0x0009fffc
Fail: @0x00000400 Read value=0x0009ff80
Aborting.
00000400
DRAM did _NOT_ verify!
DRAM ERROR
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20100313/01c64080/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: raminit.c
Type: application/octet-stream
Size: 32960 bytes
Desc: not available
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20100313/01c64080/attachment.obj>

From svn at coreboot.org  Sat Mar 13 13:54:58 2010
From: svn at coreboot.org (repository service)
Date: Sat, 13 Mar 2010 13:54:58 +0100
Subject: [coreboot] [commit] r5203 -
	trunk/src/mainboard/supermicro/h8qme_fam10
Message-ID: <E1NqQrq-0003BQ-BI@ra.coresystems.de>

Author: oxygene
Date: Sat Mar 13 13:54:58 2010
New Revision: 5203
URL: http://tracker.coreboot.org/trac/coreboot/changeset/5203

Log:
Fix supermicro/h8qme_fam10 by enabling SPD ROM properly.
Also configure GPIOs so the power LED is working.
Some whitespace cleanups (but by no means comprehensive)

Signed-off-by: Knut Kujat <knuku at gap.upv.es>
Acked-by: Myles Watson <mylesgw at gmail.com>

Modified:
   trunk/src/mainboard/supermicro/h8qme_fam10/romstage.c

Modified: trunk/src/mainboard/supermicro/h8qme_fam10/romstage.c
==============================================================================
--- trunk/src/mainboard/supermicro/h8qme_fam10/romstage.c	Thu Mar 11 23:12:10 2010	(r5202)
+++ trunk/src/mainboard/supermicro/h8qme_fam10/romstage.c	Sat Mar 13 13:54:58 2010	(r5203)
@@ -97,7 +97,10 @@
 
 static inline void activate_spd_rom(const struct mem_controller *ctrl)
 {
-	/* nothing to do */
+#define SMBUS_SWITCH1 0x70
+#define SMBUS_SWITCH2 0x72
+	smbus_send_byte(SMBUS_SWITCH1, 5 & 0x0f);
+	smbus_send_byte(SMBUS_SWITCH2, (5 >> 4) & 0x0f);
 }
 
 static inline int spd_read_byte(unsigned device, unsigned address)
@@ -239,6 +242,46 @@
 #include "cpu/amd/microcode/microcode.c"
 #include "cpu/amd/model_10xxx/update_microcode.c"
 
+#define GPIO1_DEV PNP_DEV(0x2e, W83627HF_GAME_MIDI_GPIO1)
+#define GPIO2_DEV PNP_DEV(0x2e, W83627HF_GPIO2)
+#define GPIO3_DEV PNP_DEV(0x2e, W83627HF_GPIO3)
+void write_GPIO(void)
+{
+	pnp_enter_ext_func_mode(GPIO1_DEV);
+	pnp_set_logical_device(GPIO1_DEV);
+	pnp_write_config(GPIO1_DEV, 0x30, 0x01);
+	pnp_write_config(GPIO1_DEV, 0x60, 0x00);
+	pnp_write_config(GPIO1_DEV, 0x61, 0x00);
+	pnp_write_config(GPIO1_DEV, 0x62, 0x00);
+	pnp_write_config(GPIO1_DEV, 0x63, 0x00);
+	pnp_write_config(GPIO1_DEV, 0x70, 0x00);
+	pnp_write_config(GPIO1_DEV, 0xf0, 0xff);
+	pnp_write_config(GPIO1_DEV, 0xf1, 0xff);
+	pnp_write_config(GPIO1_DEV, 0xf2, 0x00);
+	pnp_exit_ext_func_mode(GPIO1_DEV);
+
+	pnp_enter_ext_func_mode(GPIO2_DEV);
+	pnp_set_logical_device(GPIO2_DEV);
+	pnp_write_config(GPIO2_DEV, 0x30, 0x01);
+	pnp_write_config(GPIO2_DEV, 0xf0, 0xef);
+	pnp_write_config(GPIO2_DEV, 0xf1, 0xff);
+	pnp_write_config(GPIO2_DEV, 0xf2, 0x00);
+	pnp_write_config(GPIO2_DEV, 0xf3, 0x00);
+	pnp_write_config(GPIO2_DEV, 0xf5, 0x48);
+	pnp_write_config(GPIO2_DEV, 0xf6, 0x00);
+	pnp_write_config(GPIO2_DEV, 0xf7, 0xc0);
+	pnp_exit_ext_func_mode(GPIO2_DEV);
+
+	pnp_enter_ext_func_mode(GPIO3_DEV);
+	pnp_set_logical_device(GPIO3_DEV);
+	pnp_write_config(GPIO3_DEV, 0x30, 0x00);
+	pnp_write_config(GPIO3_DEV, 0xf0, 0xff);
+	pnp_write_config(GPIO3_DEV, 0xf1, 0xff);
+	pnp_write_config(GPIO3_DEV, 0xf2, 0xff);
+	pnp_write_config(GPIO3_DEV, 0xf3, 0x40);
+	pnp_exit_ext_func_mode(GPIO3_DEV);
+}
+
 void real_main(unsigned long bist, unsigned long cpu_init_detectedx)
 {
   struct sys_info *sysinfo = (struct sys_info *)(CONFIG_DCACHE_RAM_BASE + CONFIG_DCACHE_RAM_SIZE - CONFIG_DCACHE_RAM_GLOBAL_VAR_SIZE);
@@ -261,10 +304,10 @@
  	w83627hf_enable_dev(SERIAL_DEV, CONFIG_TTYS0_BASE);
 	pnp_exit_ext_func_mode(SERIAL_DEV);
 
-        uart_init();
-        console_init();
-  printk_debug("\n");
-
+	uart_init();
+	console_init();
+	write_GPIO();
+	printk_debug("\n");
 
 	/* Halt if there was a built in self test failure */
 	report_bist_failure(bist);



From stepan at coresystems.de  Sat Mar 13 14:10:32 2010
From: stepan at coresystems.de (Stefan Reinauer)
Date: Sat, 13 Mar 2010 14:10:32 +0100
Subject: [coreboot] RAM support for 440BX
In-Reply-To: <b72cdb061003122153v68ffb73vbdfd53b4a21d4d18@mail.gmail.com>
References: <b72cdb061003122153v68ffb73vbdfd53b4a21d4d18@mail.gmail.com>
Message-ID: <4B9B8EC8.8080206@coresystems.de>

On 3/13/10 6:53 AM, Keith Hui wrote:
> Below are debug outputs of my new RAM init code. As you can see it
> isn't quite working. Can this output help in finding out why?
No. You'll have to run a diff between the old (working?) and the new
code and do a binary search over the changes to find out what's causing
the trouble.

Stefan



From svn at coreboot.org  Sat Mar 13 21:16:48 2010
From: svn at coreboot.org (repository service)
Date: Sat, 13 Mar 2010 21:16:48 +0100
Subject: [coreboot] [commit] r5204 - in trunk/src: mainboard/asus/p2b-d
	mainboard/asus/p2b-ds mainboard/asus/p2b-ls
	mainboard/asus/p3b-f northbridge/intel/i440bx
Message-ID: <E1NqXlQ-0001ZZ-Mo@ra.coresystems.de>

Author: uwe
Date: Sat Mar 13 21:16:48 2010
New Revision: 5204
URL: http://tracker.coreboot.org/trac/coreboot/changeset/5204

Log:
Add SDRAMPWR_4DIMM Kconfig option (not user-visible in menuconfig).

Each Intel 440BX board should select this option if it has 4 DIMM
slots on the PCB, and _not_ select it (it defaults to 'n') if it
has 3 DIMMs on the PCB.

Signed-off-by: Keith Hui <buurin at gmail.com>
Acked-by: Uwe Hermann <uwe at hermann-uwe.de>

Modified:
   trunk/src/mainboard/asus/p2b-d/Kconfig
   trunk/src/mainboard/asus/p2b-ds/Kconfig
   trunk/src/mainboard/asus/p2b-ls/Kconfig
   trunk/src/mainboard/asus/p3b-f/Kconfig
   trunk/src/northbridge/intel/i440bx/Kconfig
   trunk/src/northbridge/intel/i440bx/raminit.c

Modified: trunk/src/mainboard/asus/p2b-d/Kconfig
==============================================================================
--- trunk/src/mainboard/asus/p2b-d/Kconfig	Sat Mar 13 13:54:58 2010	(r5203)
+++ trunk/src/mainboard/asus/p2b-d/Kconfig	Sat Mar 13 21:16:48 2010	(r5204)
@@ -31,6 +31,7 @@
 	select SMP
 	select UDELAY_TSC
 	select BOARD_ROMSIZE_KB_256
+	select SDRAMPWR_4DIMM
 
 config MAINBOARD_DIR
 	string

Modified: trunk/src/mainboard/asus/p2b-ds/Kconfig
==============================================================================
--- trunk/src/mainboard/asus/p2b-ds/Kconfig	Sat Mar 13 13:54:58 2010	(r5203)
+++ trunk/src/mainboard/asus/p2b-ds/Kconfig	Sat Mar 13 21:16:48 2010	(r5204)
@@ -31,6 +31,7 @@
 	select SMP
 	select UDELAY_TSC
 	select BOARD_ROMSIZE_KB_256
+	select SDRAMPWR_4DIMM
 
 config MAINBOARD_DIR
 	string

Modified: trunk/src/mainboard/asus/p2b-ls/Kconfig
==============================================================================
--- trunk/src/mainboard/asus/p2b-ls/Kconfig	Sat Mar 13 13:54:58 2010	(r5203)
+++ trunk/src/mainboard/asus/p2b-ls/Kconfig	Sat Mar 13 21:16:48 2010	(r5204)
@@ -29,6 +29,7 @@
 	select HAVE_PIRQ_TABLE
 	select UDELAY_TSC
 	select BOARD_ROMSIZE_KB_256
+	select SDRAMPWR_4DIMM
 
 config MAINBOARD_DIR
 	string

Modified: trunk/src/mainboard/asus/p3b-f/Kconfig
==============================================================================
--- trunk/src/mainboard/asus/p3b-f/Kconfig	Sat Mar 13 13:54:58 2010	(r5203)
+++ trunk/src/mainboard/asus/p3b-f/Kconfig	Sat Mar 13 21:16:48 2010	(r5204)
@@ -29,6 +29,7 @@
 	select HAVE_PIRQ_TABLE
 	select UDELAY_TSC
 	select BOARD_ROMSIZE_KB_256
+	select SDRAMPWR_4DIMM
 
 config MAINBOARD_DIR
 	string

Modified: trunk/src/northbridge/intel/i440bx/Kconfig
==============================================================================
--- trunk/src/northbridge/intel/i440bx/Kconfig	Sat Mar 13 13:54:58 2010	(r5203)
+++ trunk/src/northbridge/intel/i440bx/Kconfig	Sat Mar 13 21:16:48 2010	(r5204)
@@ -22,3 +22,16 @@
 	bool
 	select HAVE_HIGH_TABLES
 
+config SDRAMPWR_4DIMM
+	bool
+	depends on NORTHBRIDGE_INTEL_I440BX
+	default n
+	help
+	  This option affects how the SDRAMC register is programmed.
+	  Memory clock signals will not be routed properly if this option
+	  is set wrong.
+	
+	  If your board has 4 DIMM slots, you must use select this option, in
+	  your Kconfig file of the board. On boards with 3 DIMM slots,
+	  do _not_ select this option.
+

Modified: trunk/src/northbridge/intel/i440bx/raminit.c
==============================================================================
--- trunk/src/northbridge/intel/i440bx/raminit.c	Sat Mar 13 13:54:58 2010	(r5203)
+++ trunk/src/northbridge/intel/i440bx/raminit.c	Sat Mar 13 21:16:48 2010	(r5204)
@@ -292,7 +292,11 @@
 	 *         0 = 3 clocks of RAS# precharge
 	 *         1 = 2 clocks of RAS# precharge
 	 */
-	SDRAMC + 0, 0x00, 0x00,
+#if CONFIG_SDRAMPWR_4DIMM
+	SDRAMC + 0, 0x00, 0x10, /* The board has 4 DIMM slots. */
+#else
+	SDRAMC + 0, 0x00, 0x00, /* The board has 3 DIMM slots.*/
+#endif
 	SDRAMC + 1, 0x00, 0x00,
 
 	/* PGPOL - Paging Policy Register



From uwe at hermann-uwe.de  Sat Mar 13 21:18:39 2010
From: uwe at hermann-uwe.de (Uwe Hermann)
Date: Sat, 13 Mar 2010 21:18:39 +0100
Subject: [coreboot] [PATCH] New config option for 440BX northbridge
In-Reply-To: <b72cdb061003112002w777153b4t9a99ac557853a02c@mail.gmail.com>
References: <b72cdb061003112002w777153b4t9a99ac557853a02c@mail.gmail.com>
Message-ID: <20100313201839.GA15375@greenwood>

On Thu, Mar 11, 2010 at 11:02:05PM -0500, Keith Hui wrote:
> This patch adds a Kconfig option for 440BX that enable compiling in the
> proper value for the SDRAMPWR bit in SDRAMC register for 3 or 4 DIMM slots.
> No more hard coding for 4 DIMM slots. Also sets it to be permanently enabled
> for a few ASUS boards (P2B-LS/D/DS, P3B-F) that I know for sure have 4
> slots.

Thanks, committed a slighly modified patch in r5204.

As noted by others, this is a hardware-specific option which should be
set per-board but it doesn't make sense to make it visible in
"make menuconfig" (not even with EXPERT).

I also hooked up the variable in raminit.c (untested yet, though).


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



From svn at coreboot.org  Sat Mar 13 21:36:12 2010
From: svn at coreboot.org (repository service)
Date: Sat, 13 Mar 2010 21:36:12 +0100
Subject: [coreboot] [commit] r5205 - in trunk/src/mainboard:
	a-trend/atc-6220 a-trend/atc-6240 abit/be6-ii_v2_0 asus/p2b
	asus/p2b-d asus/p2b-ds asus/p2b-f asus/p3b-f azza/pt-6ibd
	biostar/m6tba compaq/deskpro_en_sff_p6...
Message-ID: <E1NqY4C-0005Bl-5G@ra.coresystems.de>

Author: uwe
Date: Sat Mar 13 21:36:11 2010
New Revision: 5205
URL: http://tracker.coreboot.org/trac/coreboot/changeset/5205

Log:
Use CPU_INTEL_SLOT_1 for Slot 1 boards (trivial).

This fixes a longstanding TODO item.

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

Modified:
   trunk/src/mainboard/a-trend/atc-6220/Kconfig
   trunk/src/mainboard/a-trend/atc-6220/devicetree.cb
   trunk/src/mainboard/a-trend/atc-6240/Kconfig
   trunk/src/mainboard/a-trend/atc-6240/devicetree.cb
   trunk/src/mainboard/abit/be6-ii_v2_0/Kconfig
   trunk/src/mainboard/abit/be6-ii_v2_0/devicetree.cb
   trunk/src/mainboard/asus/p2b-d/Kconfig
   trunk/src/mainboard/asus/p2b-d/devicetree.cb
   trunk/src/mainboard/asus/p2b-ds/Kconfig
   trunk/src/mainboard/asus/p2b-ds/devicetree.cb
   trunk/src/mainboard/asus/p2b-f/Kconfig
   trunk/src/mainboard/asus/p2b-f/devicetree.cb
   trunk/src/mainboard/asus/p2b/Kconfig
   trunk/src/mainboard/asus/p2b/devicetree.cb
   trunk/src/mainboard/asus/p3b-f/Kconfig
   trunk/src/mainboard/asus/p3b-f/devicetree.cb
   trunk/src/mainboard/azza/pt-6ibd/Kconfig
   trunk/src/mainboard/azza/pt-6ibd/devicetree.cb
   trunk/src/mainboard/biostar/m6tba/Kconfig
   trunk/src/mainboard/biostar/m6tba/devicetree.cb
   trunk/src/mainboard/compaq/deskpro_en_sff_p600/Kconfig
   trunk/src/mainboard/compaq/deskpro_en_sff_p600/devicetree.cb
   trunk/src/mainboard/gigabyte/ga-6bxc/Kconfig
   trunk/src/mainboard/gigabyte/ga-6bxc/devicetree.cb
   trunk/src/mainboard/msi/ms6119/Kconfig
   trunk/src/mainboard/msi/ms6119/devicetree.cb
   trunk/src/mainboard/msi/ms6147/Kconfig
   trunk/src/mainboard/msi/ms6147/devicetree.cb
   trunk/src/mainboard/msi/ms6156/Kconfig
   trunk/src/mainboard/msi/ms6156/devicetree.cb
   trunk/src/mainboard/soyo/sy-6ba-plus-iii/Kconfig
   trunk/src/mainboard/soyo/sy-6ba-plus-iii/devicetree.cb
   trunk/src/mainboard/tyan/s1846/Kconfig
   trunk/src/mainboard/tyan/s1846/devicetree.cb

Modified: trunk/src/mainboard/a-trend/atc-6220/Kconfig
==============================================================================
--- trunk/src/mainboard/a-trend/atc-6220/Kconfig	Sat Mar 13 21:16:48 2010	(r5204)
+++ trunk/src/mainboard/a-trend/atc-6220/Kconfig	Sat Mar 13 21:36:11 2010	(r5205)
@@ -21,7 +21,7 @@
 config BOARD_A_TREND_ATC_6220
 	bool "ATC-6220"
 	select ARCH_X86
-	select CPU_INTEL_SLOT_2
+	select CPU_INTEL_SLOT_1
 	select NORTHBRIDGE_INTEL_I440BX
 	select SOUTHBRIDGE_INTEL_I82371EB
 	select SUPERIO_WINBOND_W83977TF

Modified: trunk/src/mainboard/a-trend/atc-6220/devicetree.cb
==============================================================================
--- trunk/src/mainboard/a-trend/atc-6220/devicetree.cb	Sat Mar 13 21:16:48 2010	(r5204)
+++ trunk/src/mainboard/a-trend/atc-6220/devicetree.cb	Sat Mar 13 21:36:11 2010	(r5205)
@@ -1,6 +1,6 @@
 chip northbridge/intel/i440bx		# Northbridge
   device apic_cluster 0 on		# APIC cluster
-    chip cpu/intel/slot_2		# CPU (FIXME: It's slot 1, actually)
+    chip cpu/intel/slot_1		# CPU
       device apic 0 on end		# APIC
     end
   end

Modified: trunk/src/mainboard/a-trend/atc-6240/Kconfig
==============================================================================
--- trunk/src/mainboard/a-trend/atc-6240/Kconfig	Sat Mar 13 21:16:48 2010	(r5204)
+++ trunk/src/mainboard/a-trend/atc-6240/Kconfig	Sat Mar 13 21:36:11 2010	(r5205)
@@ -21,7 +21,7 @@
 config BOARD_A_TREND_ATC_6240
 	bool "ATC-6240"
 	select ARCH_X86
-	select CPU_INTEL_SLOT_2
+	select CPU_INTEL_SLOT_1
 	select NORTHBRIDGE_INTEL_I440BX
 	select SOUTHBRIDGE_INTEL_I82371EB
 	select SUPERIO_WINBOND_W83627HF

Modified: trunk/src/mainboard/a-trend/atc-6240/devicetree.cb
==============================================================================
--- trunk/src/mainboard/a-trend/atc-6240/devicetree.cb	Sat Mar 13 21:16:48 2010	(r5204)
+++ trunk/src/mainboard/a-trend/atc-6240/devicetree.cb	Sat Mar 13 21:36:11 2010	(r5205)
@@ -1,6 +1,6 @@
 chip northbridge/intel/i440bx		# Northbridge
   device apic_cluster 0 on		# APIC cluster
-    chip cpu/intel/slot_2		# CPU (FIXME: It's slot 1, actually)
+    chip cpu/intel/slot_1		# CPU
       device apic 0 on end		# APIC
     end
   end

Modified: trunk/src/mainboard/abit/be6-ii_v2_0/Kconfig
==============================================================================
--- trunk/src/mainboard/abit/be6-ii_v2_0/Kconfig	Sat Mar 13 21:16:48 2010	(r5204)
+++ trunk/src/mainboard/abit/be6-ii_v2_0/Kconfig	Sat Mar 13 21:36:11 2010	(r5205)
@@ -21,7 +21,7 @@
 config BOARD_ABIT_BE6_II_V2_0
 	bool "BE6-II V2.0"
 	select ARCH_X86
-	select CPU_INTEL_SLOT_2
+	select CPU_INTEL_SLOT_1
 	select NORTHBRIDGE_INTEL_I440BX
 	select SOUTHBRIDGE_INTEL_I82371EB
 	select SUPERIO_WINBOND_W83977TF

Modified: trunk/src/mainboard/abit/be6-ii_v2_0/devicetree.cb
==============================================================================
--- trunk/src/mainboard/abit/be6-ii_v2_0/devicetree.cb	Sat Mar 13 21:16:48 2010	(r5204)
+++ trunk/src/mainboard/abit/be6-ii_v2_0/devicetree.cb	Sat Mar 13 21:36:11 2010	(r5205)
@@ -1,6 +1,6 @@
 chip northbridge/intel/i440bx		# Northbridge
   device apic_cluster 0 on		# APIC cluster
-    chip cpu/intel/slot_2		# CPU (FIXME: It's slot 1, actually)
+    chip cpu/intel/slot_1		# CPU
       device apic 0 on end		# APIC
     end
   end

Modified: trunk/src/mainboard/asus/p2b-d/Kconfig
==============================================================================
--- trunk/src/mainboard/asus/p2b-d/Kconfig	Sat Mar 13 21:16:48 2010	(r5204)
+++ trunk/src/mainboard/asus/p2b-d/Kconfig	Sat Mar 13 21:36:11 2010	(r5205)
@@ -21,7 +21,7 @@
 config BOARD_ASUS_P2B_D
 	bool "P2B-D"
 	select ARCH_X86
-	select CPU_INTEL_SLOT_2
+	select CPU_INTEL_SLOT_1
 	select NORTHBRIDGE_INTEL_I440BX
 	select SOUTHBRIDGE_INTEL_I82371EB
 	select SUPERIO_WINBOND_W83977TF

Modified: trunk/src/mainboard/asus/p2b-d/devicetree.cb
==============================================================================
--- trunk/src/mainboard/asus/p2b-d/devicetree.cb	Sat Mar 13 21:16:48 2010	(r5204)
+++ trunk/src/mainboard/asus/p2b-d/devicetree.cb	Sat Mar 13 21:36:11 2010	(r5205)
@@ -1,9 +1,9 @@
 chip northbridge/intel/i440bx		# Northbridge
   device apic_cluster 0 on		# APIC cluster
-    chip cpu/intel/slot_2		# CPU (FIXME: It's slot 1, actually)
+    chip cpu/intel/slot_1		# CPU
       device apic 0 on end		# APIC
     end
-    chip cpu/intel/slot_2		# CPU (FIXME: It's slot 1, actually)
+    chip cpu/intel/slot_1		# CPU
       device apic 1 on end		# APIC
     end
   end

Modified: trunk/src/mainboard/asus/p2b-ds/Kconfig
==============================================================================
--- trunk/src/mainboard/asus/p2b-ds/Kconfig	Sat Mar 13 21:16:48 2010	(r5204)
+++ trunk/src/mainboard/asus/p2b-ds/Kconfig	Sat Mar 13 21:36:11 2010	(r5205)
@@ -21,7 +21,7 @@
 config BOARD_ASUS_P2B_DS
 	bool "P2B-DS"
 	select ARCH_X86
-	select CPU_INTEL_SLOT_2
+	select CPU_INTEL_SLOT_1
 	select NORTHBRIDGE_INTEL_I440BX
 	select SOUTHBRIDGE_INTEL_I82371EB
 	select SUPERIO_WINBOND_W83977TF

Modified: trunk/src/mainboard/asus/p2b-ds/devicetree.cb
==============================================================================
--- trunk/src/mainboard/asus/p2b-ds/devicetree.cb	Sat Mar 13 21:16:48 2010	(r5204)
+++ trunk/src/mainboard/asus/p2b-ds/devicetree.cb	Sat Mar 13 21:36:11 2010	(r5205)
@@ -1,9 +1,9 @@
 chip northbridge/intel/i440bx		# Northbridge
   device apic_cluster 0 on		# APIC cluster
-    chip cpu/intel/slot_2		# CPU (FIXME: It's slot 1, actually)
+    chip cpu/intel/slot_1		# CPU
       device apic 0 on end		# APIC
     end
-    chip cpu/intel/slot_2		# CPU (FIXME: It's slot 1, actually)
+    chip cpu/intel/slot_1		# CPU
       device apic 1 on end		# APIC
     end
   end

Modified: trunk/src/mainboard/asus/p2b-f/Kconfig
==============================================================================
--- trunk/src/mainboard/asus/p2b-f/Kconfig	Sat Mar 13 21:16:48 2010	(r5204)
+++ trunk/src/mainboard/asus/p2b-f/Kconfig	Sat Mar 13 21:36:11 2010	(r5205)
@@ -21,7 +21,7 @@
 config BOARD_ASUS_P2B_F
 	bool "P2B-F"
 	select ARCH_X86
-	select CPU_INTEL_SLOT_2
+	select CPU_INTEL_SLOT_1
 	select NORTHBRIDGE_INTEL_I440BX
 	select SOUTHBRIDGE_INTEL_I82371EB
 	select SUPERIO_WINBOND_W83977TF

Modified: trunk/src/mainboard/asus/p2b-f/devicetree.cb
==============================================================================
--- trunk/src/mainboard/asus/p2b-f/devicetree.cb	Sat Mar 13 21:16:48 2010	(r5204)
+++ trunk/src/mainboard/asus/p2b-f/devicetree.cb	Sat Mar 13 21:36:11 2010	(r5205)
@@ -1,6 +1,6 @@
 chip northbridge/intel/i440bx		# Northbridge
   device apic_cluster 0 on		# APIC cluster
-    chip cpu/intel/slot_2		# CPU (FIXME: It's slot 1, actually)
+    chip cpu/intel/slot_1		# CPU
       device apic 0 on end		# APIC
     end
   end

Modified: trunk/src/mainboard/asus/p2b/Kconfig
==============================================================================
--- trunk/src/mainboard/asus/p2b/Kconfig	Sat Mar 13 21:16:48 2010	(r5204)
+++ trunk/src/mainboard/asus/p2b/Kconfig	Sat Mar 13 21:36:11 2010	(r5205)
@@ -21,7 +21,7 @@
 config BOARD_ASUS_P2B
 	bool "P2B"
 	select ARCH_X86
-	select CPU_INTEL_SLOT_2
+	select CPU_INTEL_SLOT_1
 	select NORTHBRIDGE_INTEL_I440BX
 	select SOUTHBRIDGE_INTEL_I82371EB
 	select SUPERIO_WINBOND_W83977TF

Modified: trunk/src/mainboard/asus/p2b/devicetree.cb
==============================================================================
--- trunk/src/mainboard/asus/p2b/devicetree.cb	Sat Mar 13 21:16:48 2010	(r5204)
+++ trunk/src/mainboard/asus/p2b/devicetree.cb	Sat Mar 13 21:36:11 2010	(r5205)
@@ -1,6 +1,6 @@
 chip northbridge/intel/i440bx		# Northbridge
   device apic_cluster 0 on		# APIC cluster
-    chip cpu/intel/slot_2		# CPU (FIXME: It's slot 1, actually)
+    chip cpu/intel/slot_1		# CPU
       device apic 0 on end		# APIC
     end
   end

Modified: trunk/src/mainboard/asus/p3b-f/Kconfig
==============================================================================
--- trunk/src/mainboard/asus/p3b-f/Kconfig	Sat Mar 13 21:16:48 2010	(r5204)
+++ trunk/src/mainboard/asus/p3b-f/Kconfig	Sat Mar 13 21:36:11 2010	(r5205)
@@ -21,7 +21,7 @@
 config BOARD_ASUS_P3B_F
 	bool "P3B-F"
 	select ARCH_X86
-	select CPU_INTEL_SLOT_2
+	select CPU_INTEL_SLOT_1
 	select NORTHBRIDGE_INTEL_I440BX
 	select SOUTHBRIDGE_INTEL_I82371EB
 	select SUPERIO_WINBOND_W83977TF

Modified: trunk/src/mainboard/asus/p3b-f/devicetree.cb
==============================================================================
--- trunk/src/mainboard/asus/p3b-f/devicetree.cb	Sat Mar 13 21:16:48 2010	(r5204)
+++ trunk/src/mainboard/asus/p3b-f/devicetree.cb	Sat Mar 13 21:36:11 2010	(r5205)
@@ -1,6 +1,6 @@
 chip northbridge/intel/i440bx		# Northbridge
   device apic_cluster 0 on		# APIC cluster
-    chip cpu/intel/slot_2		# CPU (FIXME: It's slot 1, actually)
+    chip cpu/intel/slot_1		# CPU
       device apic 0 on end		# APIC
     end
   end

Modified: trunk/src/mainboard/azza/pt-6ibd/Kconfig
==============================================================================
--- trunk/src/mainboard/azza/pt-6ibd/Kconfig	Sat Mar 13 21:16:48 2010	(r5204)
+++ trunk/src/mainboard/azza/pt-6ibd/Kconfig	Sat Mar 13 21:36:11 2010	(r5205)
@@ -21,7 +21,7 @@
 config BOARD_AZZA_PT_6IBD
 	bool "PT-6IBD"
 	select ARCH_X86
-	select CPU_INTEL_SLOT_2
+	select CPU_INTEL_SLOT_1
 	select NORTHBRIDGE_INTEL_I440BX
 	select SOUTHBRIDGE_INTEL_I82371EB
 	select SUPERIO_WINBOND_W83977TF

Modified: trunk/src/mainboard/azza/pt-6ibd/devicetree.cb
==============================================================================
--- trunk/src/mainboard/azza/pt-6ibd/devicetree.cb	Sat Mar 13 21:16:48 2010	(r5204)
+++ trunk/src/mainboard/azza/pt-6ibd/devicetree.cb	Sat Mar 13 21:36:11 2010	(r5205)
@@ -1,6 +1,6 @@
 chip northbridge/intel/i440bx		# Northbridge
   device apic_cluster 0 on		# APIC cluster
-    chip cpu/intel/slot_2		# CPU (FIXME: It's slot 1, actually)
+    chip cpu/intel/slot_1		# CPU
       device apic 0 on end		# APIC
     end
   end

Modified: trunk/src/mainboard/biostar/m6tba/Kconfig
==============================================================================
--- trunk/src/mainboard/biostar/m6tba/Kconfig	Sat Mar 13 21:16:48 2010	(r5204)
+++ trunk/src/mainboard/biostar/m6tba/Kconfig	Sat Mar 13 21:36:11 2010	(r5205)
@@ -21,7 +21,7 @@
 config BOARD_BIOSTAR_M6TBA
 	bool "M6TBA"
 	select ARCH_X86
-	select CPU_INTEL_SLOT_2
+	select CPU_INTEL_SLOT_1
 	select NORTHBRIDGE_INTEL_I440BX
 	select SOUTHBRIDGE_INTEL_I82371EB
 	select SUPERIO_SMSC_SMSCSUPERIO

Modified: trunk/src/mainboard/biostar/m6tba/devicetree.cb
==============================================================================
--- trunk/src/mainboard/biostar/m6tba/devicetree.cb	Sat Mar 13 21:16:48 2010	(r5204)
+++ trunk/src/mainboard/biostar/m6tba/devicetree.cb	Sat Mar 13 21:36:11 2010	(r5205)
@@ -1,6 +1,6 @@
 chip northbridge/intel/i440bx		# Northbridge
   device apic_cluster 0 on		# APIC cluster
-    chip cpu/intel/slot_2		# CPU (FIXME: It's slot 1, actually)
+    chip cpu/intel/slot_1		# CPU
       device apic 0 on end		# APIC
     end
   end

Modified: trunk/src/mainboard/compaq/deskpro_en_sff_p600/Kconfig
==============================================================================
--- trunk/src/mainboard/compaq/deskpro_en_sff_p600/Kconfig	Sat Mar 13 21:16:48 2010	(r5204)
+++ trunk/src/mainboard/compaq/deskpro_en_sff_p600/Kconfig	Sat Mar 13 21:36:11 2010	(r5205)
@@ -21,7 +21,7 @@
 config BOARD_COMPAQ_DESKPRO_EN_SFF_P600
 	bool "Deskpro EN SFF P600"
 	select ARCH_X86
-	select CPU_INTEL_SLOT_2
+	select CPU_INTEL_SLOT_1
 	select NORTHBRIDGE_INTEL_I440BX
 	select SOUTHBRIDGE_INTEL_I82371EB
 	# should be SUPERIO_NSC_PC97307!

Modified: trunk/src/mainboard/compaq/deskpro_en_sff_p600/devicetree.cb
==============================================================================
--- trunk/src/mainboard/compaq/deskpro_en_sff_p600/devicetree.cb	Sat Mar 13 21:16:48 2010	(r5204)
+++ trunk/src/mainboard/compaq/deskpro_en_sff_p600/devicetree.cb	Sat Mar 13 21:36:11 2010	(r5205)
@@ -1,6 +1,6 @@
 chip northbridge/intel/i440bx		# Northbridge
   device apic_cluster 0 on		# APIC cluster
-    chip cpu/intel/slot_2		# CPU (FIXME: It's slot 1, actually)
+    chip cpu/intel/slot_1		# CPU
       device apic 0 on end		# APIC
     end
   end

Modified: trunk/src/mainboard/gigabyte/ga-6bxc/Kconfig
==============================================================================
--- trunk/src/mainboard/gigabyte/ga-6bxc/Kconfig	Sat Mar 13 21:16:48 2010	(r5204)
+++ trunk/src/mainboard/gigabyte/ga-6bxc/Kconfig	Sat Mar 13 21:36:11 2010	(r5205)
@@ -21,7 +21,7 @@
 config BOARD_GIGABYTE_GA_6BXC
 	bool "GA-6BXC"
 	select ARCH_X86
-	select CPU_INTEL_SLOT_2
+	select CPU_INTEL_SLOT_1
 	select NORTHBRIDGE_INTEL_I440BX
 	select SOUTHBRIDGE_INTEL_I82371EB
 	select SUPERIO_ITE_IT8671F

Modified: trunk/src/mainboard/gigabyte/ga-6bxc/devicetree.cb
==============================================================================
--- trunk/src/mainboard/gigabyte/ga-6bxc/devicetree.cb	Sat Mar 13 21:16:48 2010	(r5204)
+++ trunk/src/mainboard/gigabyte/ga-6bxc/devicetree.cb	Sat Mar 13 21:36:11 2010	(r5205)
@@ -1,6 +1,6 @@
 chip northbridge/intel/i440bx		# Northbridge
   device apic_cluster 0 on		# APIC cluster
-    chip cpu/intel/slot_2		# CPU (FIXME: It's slot 1, actually)
+    chip cpu/intel/slot_1		# CPU
       device apic 0 on end		# APIC
     end
   end

Modified: trunk/src/mainboard/msi/ms6119/Kconfig
==============================================================================
--- trunk/src/mainboard/msi/ms6119/Kconfig	Sat Mar 13 21:16:48 2010	(r5204)
+++ trunk/src/mainboard/msi/ms6119/Kconfig	Sat Mar 13 21:36:11 2010	(r5205)
@@ -21,7 +21,7 @@
 config BOARD_MSI_MS_6119
 	bool "MS-6119"
 	select ARCH_X86
-	select CPU_INTEL_SLOT_2
+	select CPU_INTEL_SLOT_1
 	select NORTHBRIDGE_INTEL_I440BX
 	select SOUTHBRIDGE_INTEL_I82371EB
 	select SUPERIO_WINBOND_W83977TF

Modified: trunk/src/mainboard/msi/ms6119/devicetree.cb
==============================================================================
--- trunk/src/mainboard/msi/ms6119/devicetree.cb	Sat Mar 13 21:16:48 2010	(r5204)
+++ trunk/src/mainboard/msi/ms6119/devicetree.cb	Sat Mar 13 21:36:11 2010	(r5205)
@@ -1,6 +1,6 @@
 chip northbridge/intel/i440bx		# Northbridge
   device apic_cluster 0 on		# APIC cluster
-    chip cpu/intel/slot_2		# CPU (FIXME: It's slot 1, actually)
+    chip cpu/intel/slot_1		# CPU
       device apic 0 on end		# APIC
     end
   end

Modified: trunk/src/mainboard/msi/ms6147/Kconfig
==============================================================================
--- trunk/src/mainboard/msi/ms6147/Kconfig	Sat Mar 13 21:16:48 2010	(r5204)
+++ trunk/src/mainboard/msi/ms6147/Kconfig	Sat Mar 13 21:36:11 2010	(r5205)
@@ -21,7 +21,7 @@
 config BOARD_MSI_MS_6147
 	bool "MS-6147"
 	select ARCH_X86
-	select CPU_INTEL_SLOT_2
+	select CPU_INTEL_SLOT_1
 	select NORTHBRIDGE_INTEL_I440BX
 	select SOUTHBRIDGE_INTEL_I82371EB
 	select SUPERIO_WINBOND_W83977TF

Modified: trunk/src/mainboard/msi/ms6147/devicetree.cb
==============================================================================
--- trunk/src/mainboard/msi/ms6147/devicetree.cb	Sat Mar 13 21:16:48 2010	(r5204)
+++ trunk/src/mainboard/msi/ms6147/devicetree.cb	Sat Mar 13 21:36:11 2010	(r5205)
@@ -1,6 +1,6 @@
 chip northbridge/intel/i440bx		# Northbridge
   device apic_cluster 0 on		# APIC cluster
-    chip cpu/intel/slot_2		# CPU (FIXME: It's slot 1, actually)
+    chip cpu/intel/slot_1		# CPU
       device apic 0 on end		# APIC
     end
   end

Modified: trunk/src/mainboard/msi/ms6156/Kconfig
==============================================================================
--- trunk/src/mainboard/msi/ms6156/Kconfig	Sat Mar 13 21:16:48 2010	(r5204)
+++ trunk/src/mainboard/msi/ms6156/Kconfig	Sat Mar 13 21:36:11 2010	(r5205)
@@ -21,7 +21,7 @@
 config BOARD_MSI_MS_6156
 	bool "MS-6156"
 	select ARCH_X86
-	select CPU_INTEL_SLOT_2
+	select CPU_INTEL_SLOT_1
 	select NORTHBRIDGE_INTEL_I440BX
 	select SOUTHBRIDGE_INTEL_I82371EB
 	select SUPERIO_WINBOND_W83977TF

Modified: trunk/src/mainboard/msi/ms6156/devicetree.cb
==============================================================================
--- trunk/src/mainboard/msi/ms6156/devicetree.cb	Sat Mar 13 21:16:48 2010	(r5204)
+++ trunk/src/mainboard/msi/ms6156/devicetree.cb	Sat Mar 13 21:36:11 2010	(r5205)
@@ -20,7 +20,7 @@
 
 chip northbridge/intel/i440bx		# Northbridge
   device apic_cluster 0 on		# APIC cluster
-    chip cpu/intel/slot_2		# CPU (FIXME: It's slot 1, actually)
+    chip cpu/intel/slot_1		# CPU
       device apic 0 on end		# APIC
     end
   end

Modified: trunk/src/mainboard/soyo/sy-6ba-plus-iii/Kconfig
==============================================================================
--- trunk/src/mainboard/soyo/sy-6ba-plus-iii/Kconfig	Sat Mar 13 21:16:48 2010	(r5204)
+++ trunk/src/mainboard/soyo/sy-6ba-plus-iii/Kconfig	Sat Mar 13 21:36:11 2010	(r5205)
@@ -21,7 +21,7 @@
 config BOARD_SOYO_SY_6BA_PLUS_III
 	bool "SY-6BA+ III"
 	select ARCH_X86
-	select CPU_INTEL_SLOT_2
+	select CPU_INTEL_SLOT_1
 	select NORTHBRIDGE_INTEL_I440BX
 	select SOUTHBRIDGE_INTEL_I82371EB
 	select SUPERIO_ITE_IT8671F

Modified: trunk/src/mainboard/soyo/sy-6ba-plus-iii/devicetree.cb
==============================================================================
--- trunk/src/mainboard/soyo/sy-6ba-plus-iii/devicetree.cb	Sat Mar 13 21:16:48 2010	(r5204)
+++ trunk/src/mainboard/soyo/sy-6ba-plus-iii/devicetree.cb	Sat Mar 13 21:36:11 2010	(r5205)
@@ -20,7 +20,7 @@
 
 chip northbridge/intel/i440bx		# Northbridge
   device apic_cluster 0 on		# APIC cluster
-    chip cpu/intel/slot_2		# CPU (FIXME: It's slot 1, actually)
+    chip cpu/intel/slot_1		# CPU
       device apic 0 on end		# APIC
     end
   end

Modified: trunk/src/mainboard/tyan/s1846/Kconfig
==============================================================================
--- trunk/src/mainboard/tyan/s1846/Kconfig	Sat Mar 13 21:16:48 2010	(r5204)
+++ trunk/src/mainboard/tyan/s1846/Kconfig	Sat Mar 13 21:36:11 2010	(r5205)
@@ -21,7 +21,7 @@
 config BOARD_TYAN_S1846
 	bool "S1846 (Tsunami ATX)"
 	select ARCH_X86
-	select CPU_INTEL_SLOT_2
+	select CPU_INTEL_SLOT_1
 	select NORTHBRIDGE_INTEL_I440BX
 	select SOUTHBRIDGE_INTEL_I82371EB
 	select SUPERIO_NSC_PC87309

Modified: trunk/src/mainboard/tyan/s1846/devicetree.cb
==============================================================================
--- trunk/src/mainboard/tyan/s1846/devicetree.cb	Sat Mar 13 21:16:48 2010	(r5204)
+++ trunk/src/mainboard/tyan/s1846/devicetree.cb	Sat Mar 13 21:36:11 2010	(r5205)
@@ -1,6 +1,6 @@
 chip northbridge/intel/i440bx		# Northbridge
   device apic_cluster 0 on		# APIC cluster
-    chip cpu/intel/slot_2		# CPU (FIXME: It's slot 1, actually)
+    chip cpu/intel/slot_1		# CPU
       device apic 0 on end		# APIC
     end
   end



From joe at settoplinux.org  Sat Mar 13 22:18:02 2010
From: joe at settoplinux.org (Joseph Smith)
Date: Sat, 13 Mar 2010 16:18:02 -0500
Subject: [coreboot] gfxuma memory support for I82830
Message-ID: <4B9C010A.3060409@settoplinux.org>

This patch adds support for gfxuma memory region for i82830 onboard 
graphics.

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_i82830_ip1000_rm4100.patch
Type: text/x-patch
Size: 2652 bytes
Desc: not available
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20100313/517cb533/attachment.patch>

From rminnich at gmail.com  Sat Mar 13 22:25:58 2010
From: rminnich at gmail.com (ron minnich)
Date: Sat, 13 Mar 2010 13:25:58 -0800
Subject: [coreboot] gfxuma memory support for I82830
In-Reply-To: <4B9C010A.3060409@settoplinux.org>
References: <4B9C010A.3060409@settoplinux.org>
Message-ID: <13426df11003131325u45c4a4d0nbe6a8cb41dab7c99@mail.gmail.com>

Maybe I'm missing something. You select GFXUMA but nothing seems to
depend on it?

is there something else out there that uses this variable?

ron



From svn at coreboot.org  Sat Mar 13 23:07:15 2010
From: svn at coreboot.org (repository service)
Date: Sat, 13 Mar 2010 23:07:15 +0100
Subject: [coreboot] [commit] r5206 - in trunk/src: . arch/i386
	arch/i386/include/arch arch/i386/llshell mainboard/thomson/ip1000
Message-ID: <E1NqZUJ-00011j-SK@ra.coresystems.de>

Author: oxygene
Date: Sat Mar 13 23:07:15 2010
New Revision: 5206
URL: http://tracker.coreboot.org/trac/coreboot/changeset/5206

Log:
Fix llshell

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

Added:
   trunk/src/arch/i386/include/arch/llshell.h
   trunk/src/arch/i386/llshell/console.inc
   trunk/src/arch/i386/llshell/pci.inc
   trunk/src/arch/i386/llshell/ramtest.inc
Modified:
   trunk/src/Kconfig
   trunk/src/arch/i386/Makefile.inc
   trunk/src/arch/i386/llshell/llshell.inc
   trunk/src/mainboard/thomson/ip1000/romstage.c

Modified: trunk/src/Kconfig
==============================================================================
--- trunk/src/Kconfig	Sat Mar 13 21:36:11 2010	(r5205)
+++ trunk/src/Kconfig	Sat Mar 13 23:07:15 2010	(r5206)
@@ -793,6 +793,14 @@
 
 	  If unsure, say N.
 
+config LLSHELL
+	bool "Built-in low-level shell"
+	default n
+	help
+	  If enabled, you will have a low level shell to examine your machine.
+	  Put llshell() in your (romstage) code to start the shell.
+	  See src/arch/i386/llshell/llshell.inc for details.
+
 endmenu
 
 config LIFT_BSP_APIC_ID

Modified: trunk/src/arch/i386/Makefile.inc
==============================================================================
--- trunk/src/arch/i386/Makefile.inc	Sat Mar 13 21:36:11 2010	(r5205)
+++ trunk/src/arch/i386/Makefile.inc	Sat Mar 13 23:07:15 2010	(r5206)
@@ -148,6 +148,11 @@
 crt0s += $(obj)/mainboard/$(MAINBOARDDIR)/failover.inc
 endif
 endif
+
+ifeq ($(CONFIG_LLSHELL),y)
+crt0s += $(src)/arch/i386/llshell/llshell.inc
+endif
+
 crt0s += $(obj)/mainboard/$(MAINBOARDDIR)/romstage.inc
 
 ifeq ($(CONFIG_SSE),y)

Added: trunk/src/arch/i386/include/arch/llshell.h
==============================================================================
--- /dev/null	00:00:00 1970	(empty, because file is newly added)
+++ trunk/src/arch/i386/include/arch/llshell.h	Sat Mar 13 23:07:15 2010	(r5206)
@@ -0,0 +1,11 @@
+#ifndef __ARCH_LLSHELL__
+#define __ARCH_LLSHELL__
+
+
+#if CONFIG_LLSHELL
+#define llshell() asm("jmp low_level_shell");
+#else
+#define llshell() print_debug("LLSHELL not active.\n");
+#endif
+
+#endif

Added: trunk/src/arch/i386/llshell/console.inc
==============================================================================
--- /dev/null	00:00:00 1970	(empty, because file is newly added)
+++ trunk/src/arch/i386/llshell/console.inc	Sat Mar 13 23:07:15 2010	(r5206)
@@ -0,0 +1,515 @@
+// #include <loglevel.h>
+
+jmp	console0
+
+#define __STR(X) #X
+#define STR(X) __STR(X)
+
+
+#undef STR
+	/* uses:	ax, dx */
+#if defined(SERIAL_CONSOLE)
+#define __CONSOLE_INLINE_TX_AL TTYS0_TX_AL
+#else
+#define __CONSOLE_INLINE_TX_AL
+#endif
+
+	/* uses:	esp, ax, dx */
+#define __CONSOLE_TX_CHAR(byte)	\
+	mov	byte, %al	; \
+	CALLSP(console_tx_al)
+
+	/* uses:	 ax, dx */
+#define __CONSOLE_INLINE_TX_CHAR(byte)	\
+	mov	byte, %al	; \
+	__CONSOLE_INLINE_TX_AL
+
+	/* uses:	esp, ax, edx */
+#define __CONSOLE_TX_HEX8(byte)	\
+	mov	byte, %al	; \
+	CALLSP(console_tx_hex8)
+
+	/* uses:	 byte, ax, dx */
+#define __CONSOLE_INLINE_TX_HEX8(byte)	\
+	movb	byte, %dl	; \
+	shll	$16, %edx	; \
+	shr	$4, %al		; \
+	add	$'0', %al	; \
+	cmp	$'9', %al	; \
+	jle	9f		; \
+	add	$39, %al	; \
+9:				; \
+	__CONSOLE_INLINE_TX_AL	; \
+	shrl	$16, %edx	; \
+	movb	%dl, %al	; \
+	and	$0x0f, %al	; \
+	add	$'0', %al	; \
+	cmp	$'9', %al	; \
+	jle	9f		; \
+	add	$39, %al	; \
+9:				; \
+	__CONSOLE_INLINE_TX_AL
+
+	/* uses:	esp, eax, ebx, dx */
+#define __CONSOLE_TX_HEX32(lword)	\
+	mov	lword, %eax	; \
+	CALLSP(console_tx_hex32)
+
+	/* uses:	eax, lword, dx */
+#define __CONSOLE_INLINE_TX_HEX32(lword)	\
+	mov	lword, %eax	; \
+	shr	$28, %eax	; \
+	add	$'0', %al	; \
+	cmp	$'9', %al	; \
+	jle	9f		; \
+	add	$39, %al	; \
+9:				; \
+	__CONSOLE_INLINE_TX_AL		; \
+				; \
+	mov	lword, %eax	; \
+	shr	$24, %eax	; \
+	and	$0x0f, %al	; \
+	add	$'0', %al	; \
+	cmp	$'9', %al	; \
+	jle	9f		; \
+	add	$39, %al	; \
+9:				; \
+	__CONSOLE_INLINE_TX_AL		; \
+				; \
+	mov	lword, %eax	; \
+	shr	$20, %eax	; \
+	and	$0x0f, %al	; \
+	add	$'0', %al	; \
+	cmp	$'9', %al	; \
+	jle	9f		; \
+	add	$39, %al	; \
+9:				; \
+	__CONSOLE_INLINE_TX_AL		; \
+				; \
+	mov	lword, %eax	; \
+	shr	$16, %eax	; \
+	and	$0x0f, %al	; \
+	add	$'0', %al	; \
+	cmp	$'9', %al	; \
+	jle	9f		; \
+	add	$39, %al	; \
+9:				; \
+	__CONSOLE_INLINE_TX_AL		; \
+				; \
+	mov	lword, %eax	; \
+	shr	$12, %eax	; \
+	and	$0x0f, %al	; \
+	add	$'0', %al	; \
+	cmp	$'9', %al	; \
+	jle	9f		; \
+	add	$39, %al	; \
+9:				; \
+	__CONSOLE_INLINE_TX_AL		; \
+				; \
+	mov	lword, %eax	; \
+	shr	$8, %eax	; \
+	and	$0x0f, %al	; \
+	add	$'0', %al	; \
+	cmp	$'9', %al	; \
+	jle	9f		; \
+	add	$39, %al	; \
+9:				; \
+	__CONSOLE_INLINE_TX_AL		; \
+				; \
+	mov	lword, %eax	; \
+	shr	$4, %eax	; \
+	and	$0x0f, %al	; \
+	add	$'0', %al	; \
+	cmp	$'9', %al	; \
+	jle	9f		; \
+	add	$39, %al	; \
+9:				; \
+	__CONSOLE_INLINE_TX_AL		; \
+				; \
+	mov	lword, %eax	; \
+	and	$0x0f, %al	; \
+	add	$'0', %al	; \
+	cmp	$'9', %al	; \
+	jle	9f		; \
+	add	$39, %al	; \
+9:				; \
+	__CONSOLE_INLINE_TX_AL
+
+
+	/* uses:	 esp, ebx, ax, dx */
+#define __CONSOLE_TX_STRING(string)	\
+	mov	string, %ebx	; \
+	CALLSP(console_tx_string)
+
+	/* uses:	 ebx, ax, dx */
+#define __CONSOLE_INLINE_TX_STRING(string)	\
+	movl	string, %ebx	; \
+10:	movb	(%ebx), %al	; \
+	incl	%ebx		; \
+	testb	%al, %al	; \
+	jz	11f		; \
+	__CONSOLE_INLINE_TX_AL	; \
+	jmp	10b		; \
+11:	
+
+
+#define CONSOLE_EMERG_TX_CHAR(byte)            __CONSOLE_TX_CHAR(byte)
+#define CONSOLE_EMERG_INLINE_TX_CHAR(byte)     __CONSOLE_INLINE_TX_CHAR(byte)
+#define CONSOLE_EMERG_TX_HEX8(byte)            __CONSOLE_TX_HEX8(byte)
+#define CONSOLE_EMERG_INLINE_TX_HEX8(byte)     __CONSOLE_INLINE_TX_HEX8(byte)
+#define CONSOLE_EMERG_TX_HEX32(lword)          __CONSOLE_TX_HEX32(lword)
+#define CONSOLE_EMERG_INLINE_TX_HEX32(lword)   __CONSOLE_INLINE_TX_HEX32(lword)
+#define CONSOLE_EMERG_TX_STRING(string)        __CONSOLE_TX_STRING(string)
+#define CONSOLE_EMERG_INLINE_TX_STRING(string) __CONSOLE_INLINE_TX_STRING(string)
+
+#define CONSOLE_ALERT_TX_CHAR(byte)            __CONSOLE_TX_CHAR(byte)
+#define CONSOLE_ALERT_INLINE_TX_CHAR(byte)     __CONSOLE_INLINE_TX_CHAR(byte)
+#define CONSOLE_ALERT_TX_HEX8(byte)            __CONSOLE_TX_HEX8(byte)
+#define CONSOLE_ALERT_INLINE_TX_HEX8(byte)     __CONSOLE_INLINE_TX_HEX8(byte)
+#define CONSOLE_ALERT_TX_HEX32(lword)          __CONSOLE_TX_HEX32(lword)
+#define CONSOLE_ALERT_INLINE_TX_HEX32(lword)   __CONSOLE_INLINE_TX_HEX32(lword)
+#define CONSOLE_ALERT_TX_STRING(string)        __CONSOLE_TX_STRING(string)
+#define CONSOLE_ALERT_INLINE_TX_STRING(string) __CONSOLE_INLINE_TX_STRING(string)
+
+#define CONSOLE_CRIT_TX_CHAR(byte)            __CONSOLE_TX_CHAR(byte)
+#define CONSOLE_CRIT_INLINE_TX_CHAR(byte)     __CONSOLE_INLINE_TX_CHAR(byte)
+#define CONSOLE_CRIT_TX_HEX8(byte)            __CONSOLE_TX_HEX8(byte)
+#define CONSOLE_CRIT_INLINE_TX_HEX8(byte)     __CONSOLE_INLINE_TX_HEX8(byte)
+#define CONSOLE_CRIT_TX_HEX32(lword)          __CONSOLE_TX_HEX32(lword)
+#define CONSOLE_CRIT_INLINE_TX_HEX32(lword)   __CONSOLE_INLINE_TX_HEX32(lword)
+#define CONSOLE_CRIT_TX_STRING(string)        __CONSOLE_TX_STRING(string)
+#define CONSOLE_CRIT_INLINE_TX_STRING(string) __CONSOLE_INLINE_TX_STRING(string)
+
+#define CONSOLE_ERR_TX_CHAR(byte)            __CONSOLE_TX_CHAR(byte)
+#define CONSOLE_ERR_INLINE_TX_CHAR(byte)     __CONSOLE_INLINE_TX_CHAR(byte)
+#define CONSOLE_ERR_TX_HEX8(byte)            __CONSOLE_TX_HEX8(byte)
+#define CONSOLE_ERR_INLINE_TX_HEX8(byte)     __CONSOLE_INLINE_TX_HEX8(byte)
+#define CONSOLE_ERR_TX_HEX32(lword)          __CONSOLE_TX_HEX32(lword)
+#define CONSOLE_ERR_INLINE_TX_HEX32(lword)   __CONSOLE_INLINE_TX_HEX32(lword)
+#define CONSOLE_ERR_TX_STRING(string)        __CONSOLE_TX_STRING(string)
+#define CONSOLE_ERR_INLINE_TX_STRING(string) __CONSOLE_INLINE_TX_STRING(string)
+
+#define CONSOLE_WARNING_TX_CHAR(byte)            __CONSOLE_TX_CHAR(byte)
+#define CONSOLE_WARNING_INLINE_TX_CHAR(byte)     __CONSOLE_INLINE_TX_CHAR(byte)
+#define CONSOLE_WARNING_TX_HEX8(byte)            __CONSOLE_TX_HEX8(byte)
+#define CONSOLE_WARNING_INLINE_TX_HEX8(byte)     __CONSOLE_INLINE_TX_HEX8(byte)
+#define CONSOLE_WARNING_TX_HEX32(lword)          __CONSOLE_TX_HEX32(lword)
+#define CONSOLE_WARNING_INLINE_TX_HEX32(lword)   __CONSOLE_INLINE_TX_HEX32(lword)
+#define CONSOLE_WARNING_TX_STRING(string)        __CONSOLE_TX_STRING(string)
+#define CONSOLE_WARNING_INLINE_TX_STRING(string) __CONSOLE_INLINE_TX_STRING(string)
+
+#define CONSOLE_NOTICE_TX_CHAR(byte)            __CONSOLE_TX_CHAR(byte)
+#define CONSOLE_NOTICE_INLINE_TX_CHAR(byte)     __CONSOLE_INLINE_TX_CHAR(byte)
+#define CONSOLE_NOTICE_TX_HEX8(byte)            __CONSOLE_TX_HEX8(byte)
+#define CONSOLE_NOTICE_INLINE_TX_HEX8(byte)     __CONSOLE_INLINE_TX_HEX8(byte)
+#define CONSOLE_NOTICE_TX_HEX32(lword)          __CONSOLE_TX_HEX32(lword)
+#define CONSOLE_NOTICE_INLINE_TX_HEX32(lword)   __CONSOLE_INLINE_TX_HEX32(lword)
+#define CONSOLE_NOTICE_TX_STRING(string)        __CONSOLE_TX_STRING(string)
+#define CONSOLE_NOTICE_INLINE_TX_STRING(string) __CONSOLE_INLINE_TX_STRING(string)
+
+#define CONSOLE_INFO_TX_CHAR(byte)            __CONSOLE_TX_CHAR(byte)
+#define CONSOLE_INFO_INLINE_TX_CHAR(byte)     __CONSOLE_INLINE_TX_CHAR(byte)
+#define CONSOLE_INFO_TX_HEX8(byte)            __CONSOLE_TX_HEX8(byte)
+#define CONSOLE_INFO_INLINE_TX_HEX8(byte)     __CONSOLE_INLINE_TX_HEX8(byte)
+#define CONSOLE_INFO_TX_HEX32(lword)          __CONSOLE_TX_HEX32(lword)
+#define CONSOLE_INFO_INLINE_TX_HEX32(lword)   __CONSOLE_INLINE_TX_HEX32(lword)
+#define CONSOLE_INFO_TX_STRING(string)        __CONSOLE_TX_STRING(string)
+#define CONSOLE_INFO_INLINE_TX_STRING(string) __CONSOLE_INLINE_TX_STRING(string)
+
+#define CONSOLE_DEBUG_TX_CHAR(byte)            __CONSOLE_TX_CHAR(byte)
+#define CONSOLE_DEBUG_INLINE_TX_CHAR(byte)     __CONSOLE_INLINE_TX_CHAR(byte)
+#define CONSOLE_DEBUG_TX_HEX8(byte)            __CONSOLE_TX_HEX8(byte)
+#define CONSOLE_DEBUG_INLINE_TX_HEX8(byte)     __CONSOLE_INLINE_TX_HEX8(byte)
+#define CONSOLE_DEBUG_TX_HEX32(lword)          __CONSOLE_TX_HEX32(lword)
+#define CONSOLE_DEBUG_INLINE_TX_HEX32(lword)   __CONSOLE_INLINE_TX_HEX32(lword)
+#define CONSOLE_DEBUG_TX_STRING(string)        __CONSOLE_TX_STRING(string)
+#define CONSOLE_DEBUG_INLINE_TX_STRING(string) __CONSOLE_INLINE_TX_STRING(string)
+
+#define CONSOLE_SPEW_TX_CHAR(byte)            __CONSOLE_TX_CHAR(byte)
+#define CONSOLE_SPEW_INLINE_TX_CHAR(byte)     __CONSOLE_INLINE_TX_CHAR(byte)
+#define CONSOLE_SPEW_TX_HEX8(byte)            __CONSOLE_TX_HEX8(byte)
+#define CONSOLE_SPEW_INLINE_TX_HEX8(byte)     __CONSOLE_INLINE_TX_HEX8(byte)
+#define CONSOLE_SPEW_TX_HEX32(lword)          __CONSOLE_TX_HEX32(lword)
+#define CONSOLE_SPEW_INLINE_TX_HEX32(lword)   __CONSOLE_INLINE_TX_HEX32(lword)
+#define CONSOLE_SPEW_TX_STRING(string)        __CONSOLE_TX_STRING(string)
+#define CONSOLE_SPEW_INLINE_TX_STRING(string) __CONSOLE_INLINE_TX_STRING(string)
+
+#if 0
+#if ASM_CONSOLE_LOGLEVEL <= BIOS_EMERG
+#undef  CONSOLE_EMERG_TX_CHAR
+#undef  CONSOLE_EMERG_INLINE_TX_CHAR
+#undef  CONSOLE_EMERG_TX_HEX8
+#undef  CONSOLE_EMERG_INLINE_TX_HEX8
+#undef  CONSOLE_EMERG_TX_HEX32
+#undef  CONSOLE_EMERG_INLINE_TX_HEX32
+#undef  CONSOLE_EMERG_TX_STRING
+#undef  CONSOLE_EMERG_INLINE_TX_STRING
+#define CONSOLE_EMERG_TX_CHAR(byte)            
+#define CONSOLE_EMERG_INLINE_TX_CHAR(byte)     
+#define CONSOLE_EMERG_TX_HEX8(byte)            
+#define CONSOLE_EMERG_INLINE_TX_HEX8(byte)     
+#define CONSOLE_EMERG_TX_HEX32(lword)          
+#define CONSOLE_EMERG_INLINE_TX_HEX32(lword)   
+#define CONSOLE_EMERG_TX_STRING(string)        
+#define CONSOLE_EMERG_INLINE_TX_STRING(string) 
+#endif
+
+
+#if ASM_CONSOLE_LOGLEVEL <= BIOS_ALERT
+#undef  CONSOLE_ALERT_TX_CHAR
+#undef  CONSOLE_ALERT_INLINE_TX_CHAR
+#undef  CONSOLE_ALERT_TX_HEX8
+#undef  CONSOLE_ALERT_INLINE_TX_HEX8
+#undef  CONSOLE_ALERT_TX_HEX32
+#undef  CONSOLE_ALERT_INLINE_TX_HEX32
+#undef  CONSOLE_ALERT_TX_STRING
+#undef  CONSOLE_ALERT_INLINE_TX_STRING
+#define CONSOLE_ALERT_TX_CHAR(byte)            
+#define CONSOLE_ALERT_INLINE_TX_CHAR(byte)     
+#define CONSOLE_ALERT_TX_HEX8(byte)            
+#define CONSOLE_ALERT_INLINE_TX_HEX8(byte)     
+#define CONSOLE_ALERT_TX_HEX32(lword)          
+#define CONSOLE_ALERT_INLINE_TX_HEX32(lword)   
+#define CONSOLE_ALERT_TX_STRING(string)        
+#define CONSOLE_ALERT_INLINE_TX_STRING(string) 
+#endif
+
+#if ASM_CONSOLE_LOGLEVEL <= BIOS_CRIT
+#undef  CONSOLE_CRIT_TX_CHAR
+#undef  CONSOLE_CRIT_INLINE_TX_CHAR
+#undef  CONSOLE_CRIT_TX_HEX8
+#undef  CONSOLE_CRIT_INLINE_TX_HEX8
+#undef  CONSOLE_CRIT_TX_HEX32
+#undef  CONSOLE_CRIT_INLINE_TX_HEX32
+#undef  CONSOLE_CRIT_TX_STRING
+#undef  CONSOLE_CRIT_INLINE_TX_STRING
+#define CONSOLE_CRIT_TX_CHAR(byte)            
+#define CONSOLE_CRIT_INLINE_TX_CHAR(byte)     
+#define CONSOLE_CRIT_TX_HEX8(byte)            
+#define CONSOLE_CRIT_INLINE_TX_HEX8(byte)     
+#define CONSOLE_CRIT_TX_HEX32(lword)          
+#define CONSOLE_CRIT_INLINE_TX_HEX32(lword)   
+#define CONSOLE_CRIT_TX_STRING(string)        
+#define CONSOLE_CRIT_INLINE_TX_STRING(string) 
+#endif
+
+#if ASM_CONSOLE_LOGLEVEL <= BIOS_ERR
+#undef  CONSOLE_ERR_TX_CHAR
+#undef  CONSOLE_ERR_INLINE_TX_CHAR
+#undef  CONSOLE_ERR_TX_HEX8
+#undef  CONSOLE_ERR_INLINE_TX_HEX8
+#undef  CONSOLE_ERR_TX_HEX32
+#undef  CONSOLE_ERR_INLINE_TX_HEX32
+#undef  CONSOLE_ERR_TX_STRING
+#undef  CONSOLE_ERR_INLINE_TX_STRING
+#define CONSOLE_ERR_TX_CHAR(byte)            
+#define CONSOLE_ERR_INLINE_TX_CHAR(byte)     
+#define CONSOLE_ERR_TX_HEX8(byte)            
+#define CONSOLE_ERR_INLINE_TX_HEX8(byte)     
+#define CONSOLE_ERR_TX_HEX32(lword)          
+#define CONSOLE_ERR_INLINE_TX_HEX32(lword)   
+#define CONSOLE_ERR_TX_STRING(string)        
+#define CONSOLE_ERR_INLINE_TX_STRING(string) 
+#endif
+
+#if ASM_CONSOLE_LOGLEVEL <= BIOS_WARNING
+#undef  CONSOLE_WARNING_TX_CHAR
+#undef  CONSOLE_WARNING_INLINE_TX_CHAR
+#undef  CONSOLE_WARNING_TX_HEX8
+#undef  CONSOLE_WARNING_INLINE_TX_HEX8
+#undef  CONSOLE_WARNING_TX_HEX32
+#undef  CONSOLE_WARNING_INLINE_TX_HEX32
+#undef  CONSOLE_WARNING_TX_STRING
+#undef  CONSOLE_WARNING_INLINE_TX_STRING
+#define CONSOLE_WARNING_TX_CHAR(byte)            
+#define CONSOLE_WARNING_INLINE_TX_CHAR(byte)     
+#define CONSOLE_WARNING_TX_HEX8(byte)            
+#define CONSOLE_WARNING_INLINE_TX_HEX8(byte)     
+#define CONSOLE_WARNING_TX_HEX32(lword)          
+#define CONSOLE_WARNING_INLINE_TX_HEX32(lword)   
+#define CONSOLE_WARNING_TX_STRING(string)        
+#define CONSOLE_WARNING_INLINE_TX_STRING(string) 
+#endif
+
+#if ASM_CONSOLE_LOGLEVEL <= BIOS_NOTICE
+#undef  CONSOLE_NOTICE_TX_CHAR
+#undef  CONSOLE_NOTICE_INLINE_TX_CHAR
+#undef  CONSOLE_NOTICE_TX_HEX8
+#undef  CONSOLE_NOTICE_INLINE_TX_HEX8
+#undef  CONSOLE_NOTICE_TX_HEX32
+#undef  CONSOLE_NOTICE_INLINE_TX_HEX32
+#undef  CONSOLE_NOTICE_TX_STRING
+#undef  CONSOLE_NOTICE_INLINE_TX_STRING
+#define CONSOLE_NOTICE_TX_CHAR(byte)            
+#define CONSOLE_NOTICE_INLINE_TX_CHAR(byte)     
+#define CONSOLE_NOTICE_TX_HEX8(byte)            
+#define CONSOLE_NOTICE_INLINE_TX_HEX8(byte)     
+#define CONSOLE_NOTICE_TX_HEX32(lword)          
+#define CONSOLE_NOTICE_INLINE_TX_HEX32(lword)   
+#define CONSOLE_NOTICE_TX_STRING(string)        
+#define CONSOLE_NOTICE_INLINE_TX_STRING(string) 
+#endif
+
+#if ASM_CONSOLE_LOGLEVEL <= BIOS_INFO
+#undef  CONSOLE_INFO_TX_CHAR
+#undef  CONSOLE_INFO_INLINE_TX_CHAR
+#undef  CONSOLE_INFO_TX_HEX8
+#undef  CONSOLE_INFO_INLINE_TX_HEX8
+#undef  CONSOLE_INFO_TX_HEX32
+#undef  CONSOLE_INFO_INLINE_TX_HEX32
+#undef  CONSOLE_INFO_TX_STRING
+#undef  CONSOLE_INFO_INLINE_TX_STRING
+#define CONSOLE_INFO_TX_CHAR(byte)            
+#define CONSOLE_INFO_INLINE_TX_CHAR(byte)     
+#define CONSOLE_INFO_TX_HEX8(byte)            
+#define CONSOLE_INFO_INLINE_TX_HEX8(byte)     
+#define CONSOLE_INFO_TX_HEX32(lword)          
+#define CONSOLE_INFO_INLINE_TX_HEX32(lword)   
+#define CONSOLE_INFO_TX_STRING(string)        
+#define CONSOLE_INFO_INLINE_TX_STRING(string) 
+#endif
+
+#if ASM_CONSOLE_LOGLEVEL <= BIOS_DEBUG
+#undef  CONSOLE_DEBUG_TX_CHAR
+#undef  CONSOLE_DEBUG_INLINE_TX_CHAR
+#undef  CONSOLE_DEBUG_TX_HEX8
+#undef  CONSOLE_DEBUG_INLINE_TX_HEX8
+#undef  CONSOLE_DEBUG_TX_HEX32
+#undef  CONSOLE_DEBUG_INLINE_TX_HEX32
+#undef  CONSOLE_DEBUG_TX_STRING
+#undef  CONSOLE_DEBUG_INLINE_TX_STRING
+#define CONSOLE_DEBUG_TX_CHAR(byte)            
+#define CONSOLE_DEBUG_INLINE_TX_CHAR(byte)     
+#define CONSOLE_DEBUG_TX_HEX8(byte)            
+#define CONSOLE_DEBUG_INLINE_TX_HEX8(byte)     
+#define CONSOLE_DEBUG_TX_HEX32(lword)          
+#define CONSOLE_DEBUG_INLINE_TX_HEX32(lword)   
+#define CONSOLE_DEBUG_TX_STRING(string)        
+#define CONSOLE_DEBUG_INLINE_TX_STRING(string) 
+#endif
+
+#if ASM_CONSOLE_LOGLEVEL <= BIOS_SPEW
+#undef  CONSOLE_SPEW_TX_CHAR
+#undef  CONSOLE_SPEW_INLINE_TX_CHAR
+#undef  CONSOLE_SPEW_TX_HEX8
+#undef  CONSOLE_SPEW_INLINE_TX_HEX8
+#undef  CONSOLE_SPEW_TX_HEX32
+#undef  CONSOLE_SPEW_INLINE_TX_HEX32
+#undef  CONSOLE_SPEW_TX_STRING
+#undef  CONSOLE_SPEW_INLINE_TX_STRING
+#define CONSOLE_SPEW_TX_CHAR(byte)            
+#define CONSOLE_SPEW_INLINE_TX_CHAR(byte)     
+#define CONSOLE_SPEW_TX_HEX8(byte)            
+#define CONSOLE_SPEW_INLINE_TX_HEX8(byte)     
+#define CONSOLE_SPEW_TX_HEX32(lword)          
+#define CONSOLE_SPEW_INLINE_TX_HEX32(lword)   
+#define CONSOLE_SPEW_TX_STRING(string)        
+#define CONSOLE_SPEW_INLINE_TX_STRING(string) 
+#endif
+#endif
+
+	/* uses:	esp, ax, dx */
+console_tx_al:	
+	__CONSOLE_INLINE_TX_AL
+	RETSP
+
+	/* uses:	 esp, ax, edx */
+console_tx_hex8:
+	__CONSOLE_INLINE_TX_HEX8(%al)
+	RETSP
+
+
+	/* uses:	 esp, ebx, eax, dx */
+console_tx_hex32:
+	mov	%eax, %ebx
+	shr	$28, %eax
+	add	$'0', %al
+	cmp	$'9', %al
+	jle	9f
+	add	$39, %al
+9:
+	__CONSOLE_INLINE_TX_AL
+
+	mov	%ebx, %eax
+	shr	$24, %eax
+	and	$0x0f, %al
+	add	$'0', %al
+	cmp	$'9', %al
+	jle	9f
+	add	$39, %al
+9:
+	__CONSOLE_INLINE_TX_AL
+
+	mov	%ebx, %eax
+	shr	$20, %eax
+	and	$0x0f, %al
+	add	$'0', %al
+	cmp	$'9', %al
+	jle	9f
+	add	$39, %al
+9:
+	__CONSOLE_INLINE_TX_AL
+
+	mov	%ebx, %eax
+	shr	$16, %eax
+	and	$0x0f, %al
+	add	$'0', %al
+	cmp	$'9', %al
+	jle	9f
+	add	$39, %al
+9:
+	__CONSOLE_INLINE_TX_AL
+
+	mov	%ebx, %eax
+	shr	$12, %eax
+	and	$0x0f, %al
+	add	$'0', %al
+	cmp	$'9', %al
+	jle	9f
+	add	$39, %al
+9:
+	__CONSOLE_INLINE_TX_AL
+
+	mov	%ebx, %eax
+	shr	$8, %eax
+	and	$0x0f, %al
+	add	$'0', %al
+	cmp	$'9', %al
+	jle	9f
+	add	$39, %al
+9:
+	__CONSOLE_INLINE_TX_AL
+
+	mov	%ebx, %eax
+	shr	$4, %eax
+	and	$0x0f, %al
+	add	$'0', %al
+	cmp	$'9', %al
+	jle	9f
+	add	$39, %al
+9:
+	__CONSOLE_INLINE_TX_AL
+
+	mov	%ebx, %eax
+	and	$0x0f, %al
+	add	$'0', %al
+	cmp	$'9', %al
+	jle	9f
+	add	$39, %al
+9:
+	__CONSOLE_INLINE_TX_AL
+	RETSP
+
+	/* Uses esp, ebx, ax, dx  */
+
+console_tx_string:
+	mov	(%ebx), %al
+	inc	%ebx
+	cmp	$0, %al
+	jne	9f
+	RETSP
+9:	
+	__CONSOLE_INLINE_TX_AL
+	jmp	console_tx_string
+
+console0:

Modified: trunk/src/arch/i386/llshell/llshell.inc
==============================================================================
--- trunk/src/arch/i386/llshell/llshell.inc	Sat Mar 13 21:36:11 2010	(r5205)
+++ trunk/src/arch/i386/llshell/llshell.inc	Sat Mar 13 23:07:15 2010	(r5206)
@@ -1,3 +1,7 @@
+#include "console.inc"
+#include "pci.inc"
+#include "ramtest.inc"
+
 jmp llshell_out
 
 // (c) 2004 Bryan Chafy,  This program is released under the GPL

Added: trunk/src/arch/i386/llshell/pci.inc
==============================================================================
--- /dev/null	00:00:00 1970	(empty, because file is newly added)
+++ trunk/src/arch/i386/llshell/pci.inc	Sat Mar 13 23:07:15 2010	(r5206)
@@ -0,0 +1,229 @@
+
+	/*
+	 * Macro:	PCI_WRITE_CONFIG_BYTE
+	 * Arguments:	%eax address to write to (includes bus, device, function, &offset)
+	 *              %dl byte to write
+	 *
+	 * Results:	none
+	 *
+	 * Trashed:	%eax, %edx
+	 * Effects:	writes a single byte to pci config space
+	 *
+	 * Notes:	This routine is optimized for minimal register usage.
+	 *              And the tricks it does cannot scale beyond writing a single byte.
+	 *               
+	 *              What it does is almost simple.
+	 *              It preserves %eax (baring special bits) until it is written
+	 *              out to the appropriate port.  And hides the data byte
+	 *              in the high half of edx.
+	 *
+	 *              In %edx[3] it stores the byte to write.
+	 *              In %edx[2] it stores the lower three bits of the address.
+	 */
+
+
+#define PCI_WRITE_CONFIG_BYTE \
+	shll $8,   %edx		; \
+	movb %al,  %dl		; \
+	andb $0x3, %dl		; \
+	shll $16,  %edx		; \
+	\
+	orl  $0x80000000, %eax	; \
+	andl $0xfffffffc, %eax	; \
+	movw $0xcf8, %dx	; \
+	outl %eax,  %dx		; \
+	\
+	shrl $16,  %edx		; \
+	movb %dh,  %al		; \
+	movb $0,   %dh		; \
+	addl $0xcfc, %edx	; \
+	outb %al,  %dx
+
+
+	/*
+	 * Macro:	PCI_WRITE_CONFIG_WORD
+	 * Arguments:	%eax address to write to (includes bus, device, function, &offset)
+	 *              %ecx word to write
+	 *
+	 * Results:	none
+	 *
+	 * Trashed:	%eax, %edx
+	 * Preserved:   %ecx
+	 * Effects:	writes a single byte to pci config space
+	 *
+	 * Notes:	This routine is optimized for minimal register usage.
+	 *               
+	 *              What it does is almost simple.
+	 *              It preserves %eax (baring special bits) until it is written
+	 *              out to the appropriate port.  And hides the least significant
+	 *              bits of the address in the high half of edx.
+	 *
+	 *              In %edx[2] it stores the lower three bits of the address.
+	 */
+
+
+#define PCI_WRITE_CONFIG_WORD \
+	movb %al,  %dl		; \
+	andl $0x3, %edx		; \
+	shll $16,  %edx		; \
+	\
+	orl  $0x80000000, %eax	; \
+	andl $0xfffffffc, %eax	; \
+	movw $0xcf8, %dx	; \
+	outl %eax,  %dx		; \
+	\
+	shrl $16,  %edx		; \
+	movl %ecx, %eax		; \
+	addl $0xcfc, %edx	; \
+	outw %ax,  %dx
+
+
+
+	/*
+	 * Macro:	PCI_WRITE_CONFIG_DWORD
+	 * Arguments:	%eax address to write to (includes bus, device, function, &offset)
+	 *              %ecx dword to write
+	 *
+	 * Results:	none
+	 *
+	 * Trashed:	%eax, %edx
+	 * Preserved:   %ecx
+	 * Effects:	writes a single byte to pci config space
+	 *
+	 * Notes:	This routine is optimized for minimal register usage.
+	 *               
+	 *              What it does is almost simple.
+	 *              It preserves %eax (baring special bits) until it is written
+	 *              out to the appropriate port.  And hides the least significant
+	 *              bits of the address in the high half of edx.
+	 *
+	 *              In %edx[2] it stores the lower three bits of the address.
+	 */
+
+
+#define PCI_WRITE_CONFIG_DWORD \
+	movb %al,  %dl		; \
+	andl $0x3, %edx		; \
+	shll $16,  %edx		; \
+	\
+	orl  $0x80000000, %eax	; \
+	andl $0xfffffffc, %eax	; \
+	movw $0xcf8, %dx	; \
+	outl %eax,  %dx		; \
+	\
+	shrl $16,  %edx		; \
+	movl %ecx, %eax		; \
+	addl $0xcfc, %edx	; \
+	outl %eax,  %dx
+
+
+
+	
+	/*
+	 * Macro:	PCI_READ_CONFIG_BYTE
+	 * Arguments:	%eax address to read from (includes bus, device, function, &offset)
+	 *
+	 * Results:	%al Byte read
+	 *
+	 * Trashed:	%eax, %edx
+	 * Effects:	reads a single byte from pci config space
+	 *
+	 * Notes:	This routine is optimized for minimal register usage.
+	 *               
+	 *              What it does is almost simple.
+	 *              It preserves %eax (baring special bits) until it is written
+	 *              out to the appropriate port.  And hides the least significant
+	 *              bits of the address in the high half of edx.
+	 *
+	 *              In %edx[2] it stores the lower three bits of the address.
+	 */
+
+
+#define PCI_READ_CONFIG_BYTE \
+	movb %al,  %dl		; \
+	andl $0x3, %edx		; \
+	shll $16,  %edx		; \
+	\
+	orl  $0x80000000, %eax	; \
+	andl $0xfffffffc, %eax	; \
+	movw $0xcf8, %dx	; \
+	outl %eax,  %dx		; \
+	\
+	shrl $16,  %edx		; \
+	addl $0xcfc, %edx	; \
+	inb  %dx,  %al
+
+
+
+	/*
+	 * Macro:	PCI_READ_CONFIG_WORD
+	 * Arguments:	%eax address to read from (includes bus, device, function, &offset)
+	 *
+	 * Results:	%ax word read
+	 *
+	 * Trashed:	%eax, %edx
+	 * Effects:	reads a 2 bytes from pci config space
+	 *
+	 * Notes:	This routine is optimized for minimal register usage.
+	 *               
+	 *              What it does is almost simple.
+	 *              It preserves %eax (baring special bits) until it is written
+	 *              out to the appropriate port.  And hides the least significant
+	 *              bits of the address in the high half of edx.
+	 *
+	 *              In %edx[2] it stores the lower three bits of the address.
+	 */
+
+
+#define PCI_READ_CONFIG_WORD \
+	movb %al,  %dl		; \
+	andl $0x3, %edx		; \
+	shll $16,  %edx		; \
+	\
+	orl  $0x80000000, %eax	; \
+	andl $0xfffffffc, %eax	; \
+	movw $0xcf8, %dx	; \
+	outl %eax,  %dx		; \
+	\
+	shrl $16,  %edx		; \
+	addl $0xcfc, %edx	; \
+	inw  %dx,  %ax
+
+
+
+	/*
+	 * Macro:	PCI_READ_CONFIG_DWORD
+	 * Arguments:	%eax address to read from (includes bus, device, function, &offset)
+	 *
+	 * Results:	%eax
+	 *
+	 * Trashed:	%edx
+	 * Effects:	reads 4 bytes from pci config space
+	 *
+	 * Notes:	This routine is optimized for minimal register usage.
+	 *               
+	 *              What it does is almost simple.
+	 *              It preserves %eax (baring special bits) until it is written
+	 *              out to the appropriate port.  And hides the least significant
+	 *              bits of the address in the high half of edx.
+	 *
+	 *              In %edx[2] it stores the lower three bits of the address.
+	 */
+
+
+#define PCI_READ_CONFIG_DWORD \
+	movb %al,  %dl		; \
+	andl $0x3, %edx		; \
+	shll $16,  %edx		; \
+	\
+	orl  $0x80000000, %eax	; \
+	andl $0xfffffffc, %eax	; \
+	movw $0xcf8, %dx	; \
+	outl %eax,  %dx		; \
+	\
+	shrl $16,  %edx		; \
+	addl $0xcfc, %edx	; \
+	inl  %dx,  %eax
+
+
+

Added: trunk/src/arch/i386/llshell/ramtest.inc
==============================================================================
--- /dev/null	00:00:00 1970	(empty, because file is newly added)
+++ trunk/src/arch/i386/llshell/ramtest.inc	Sat Mar 13 23:07:15 2010	(r5206)
@@ -0,0 +1,125 @@
+	/*
+	 * This is much more of a "Is my SDRAM properly configured?"
+	 * test than a "Is my SDRAM faulty?" test.  Not all bits
+	 * are tested.   -Tyson
+	 */
+
+	jmp	rt_skip
+#define RAMTEST 1
+#if RAMTEST	
+	.section ".rom.data"
+
+rt_test:	.string "Testing SDRAM : "
+rt_fill:	.string "SDRAM fill:\r\n"
+rt_verify:	.string "SDRAM verify:\r\n"
+rt_toomany:	.string "Too many errors.\r\n"
+rt_done:	.string "Done.\r\n"
+	.previous
+#endif
+	
+ramtest:
+#if RAMTEST
+	mov %eax, %esi
+	mov %ebx, %edi
+	mov %esp, %ebp
+
+	CONSOLE_INFO_TX_STRING($rt_test)
+	CONSOLE_INFO_TX_HEX32(%esi)
+	CONSOLE_INFO_TX_CHAR($'-')
+	CONSOLE_INFO_TX_HEX32(%edi)
+	CONSOLE_INFO_TX_CHAR($'\r')
+	CONSOLE_INFO_TX_CHAR($'\n')
+
+	/* ============== Fill ram block ==== */
+
+	CONSOLE_INFO_TX_STRING($rt_fill)
+
+	mov %esi, %ebx
+1:
+	cmp $0, %bx
+	jne 2f
+
+	/* Display address being filled */
+	/* CONSOLE_INFO_TX_HEX32(arg) will overwrite %ebx with arg */
+	
+	CONSOLE_INFO_TX_HEX32(%ebx)
+	CONSOLE_INFO_TX_CHAR($'\r')
+2:
+#if	i786
+	/* Use a non temporal store to go faster and
+	 * to bypass the cache.
+	 */
+	movnti	%ebx, (%ebx)
+#else
+	mov %ebx, (%ebx)
+#endif
+	add $4, %ebx
+	cmp %edi, %ebx
+	jl 1b
+
+	/* Display final address */
+
+	CONSOLE_INFO_TX_HEX32(%edi)
+	CONSOLE_INFO_TX_CHAR($'\r')
+	CONSOLE_INFO_TX_CHAR($'\n')
+
+	/* ========= Verify ram block ========== */
+
+	CONSOLE_INFO_TX_STRING($rt_verify)
+	mov %esi, %ebx
+
+1:
+	cmp $0, %bx
+	jne 2f
+
+	/* Display address being tested */
+
+	CONSOLE_INFO_TX_HEX32(%ebx)
+	CONSOLE_INFO_TX_CHAR($'\r')
+2:
+	cmp %ebx, (%ebx)
+	jne 4f
+3:
+	add $4, %ebx
+	cmp %edi, %ebx
+	jl 1b
+
+	/* Display final address */
+	CONSOLE_INFO_TX_HEX32(%edi)
+	CONSOLE_INFO_TX_CHAR($'\r')
+	CONSOLE_INFO_TX_CHAR($'\n')
+	jmp 6f
+
+4:
+	/* Display address with error */
+
+	CONSOLE_INFO_TX_HEX32(%ebx)
+	CONSOLE_INFO_TX_CHAR($':')
+
+	/* Display data in address with error */
+
+	/* CONSOLE_INFO_TX_HEX32(arg) will overwrite %ebx with arg */
+
+	mov %ebx, %esi
+	mov 0(%ebx), %eax
+	CONSOLE_INFO_TX_HEX32(%eax)
+	mov %esi, %ebx
+
+	CONSOLE_INFO_TX_CHAR($'\r')
+	CONSOLE_INFO_TX_CHAR($'\n')
+	sub $1, %ecx
+	jz 5f
+	jmp 3b
+5:	
+	CONSOLE_INFO_TX_STRING($rt_toomany)
+	intel_chip_post_macro(0xf1)
+	jmp	.Lhlt
+
+6:
+	CONSOLE_INFO_TX_STRING($rt_done)
+	mov %ebp, %esp
+
+#endif
+	RETSP
+
+rt_skip:

Modified: trunk/src/mainboard/thomson/ip1000/romstage.c
==============================================================================
--- trunk/src/mainboard/thomson/ip1000/romstage.c	Sat Mar 13 21:36:11 2010	(r5205)
+++ trunk/src/mainboard/thomson/ip1000/romstage.c	Sat Mar 13 23:07:15 2010	(r5206)
@@ -28,6 +28,7 @@
 #include <device/pnp_def.h>
 #include <arch/romcc_io.h>
 #include <arch/hlt.h>
+#include <arch/llshell.h>
 #include "pc80/serial.c"
 #include "pc80/udelay_io.c"
 #include "arch/i386/lib/console.c"
@@ -129,6 +130,9 @@
 	/* Initialize memory */
 	sdram_initialize();
 
+#if CONFIG_LLSHELL
+	llshell();
+#endif
 	/* Check RAM. */
 	/* ram_check(0, 640 * 1024); */
 	/* ram_check(64512 * 1024, 65536 * 1024); */



From joe at settoplinux.org  Sat Mar 13 23:55:15 2010
From: joe at settoplinux.org (Joseph Smith)
Date: Sat, 13 Mar 2010 17:55:15 -0500
Subject: [coreboot] [commit] r5206 - in trunk/src: . arch/i386
 arch/i386/include/arch arch/i386/llshell mainboard/thomson/ip1000
In-Reply-To: <E1NqZUJ-00011j-SK@ra.coresystems.de>
References: <E1NqZUJ-00011j-SK@ra.coresystems.de>
Message-ID: <914bca171c25d2a882ce40fcdba1cee2@imap.1and1.com>



> Modified: trunk/src/mainboard/thomson/ip1000/romstage.c
>
==============================================================================
> --- trunk/src/mainboard/thomson/ip1000/romstage.c	Sat Mar 13 21:36:11
> 2010	(r5205)
> +++ trunk/src/mainboard/thomson/ip1000/romstage.c	Sat Mar 13 23:07:15
> 2010	(r5206)
> @@ -28,6 +28,7 @@
>  #include <device/pnp_def.h>
>  #include <arch/romcc_io.h>
>  #include <arch/hlt.h>
> +#include <arch/llshell.h>
>  #include "pc80/serial.c"
>  #include "pc80/udelay_io.c"
>  #include "arch/i386/lib/console.c"
> @@ -129,6 +130,9 @@
>  	/* Initialize memory */
>  	sdram_initialize();
> 
> +#if CONFIG_LLSHELL
> +	llshell();
> +#endif
>  	/* Check RAM. */
>  	/* ram_check(0, 640 * 1024); */
>  	/* ram_check(64512 * 1024, 65536 * 1024); */
> 
Cool!
What kinds of things can you do with the llshell?

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




From joe at settoplinux.org  Sat Mar 13 23:58:32 2010
From: joe at settoplinux.org (Joseph Smith)
Date: Sat, 13 Mar 2010 17:58:32 -0500
Subject: [coreboot] gfxuma memory support for I82830
In-Reply-To: <13426df11003131325u45c4a4d0nbe6a8cb41dab7c99@mail.gmail.com>
References: <4B9C010A.3060409@settoplinux.org>
	<13426df11003131325u45c4a4d0nbe6a8cb41dab7c99@mail.gmail.com>
Message-ID: <6ec4d8dcf2ab409e51f32fe55d258f41@imap.1and1.com>




On Sat, 13 Mar 2010 13:25:58 -0800, ron minnich <rminnich at gmail.com> wrote:
> Maybe I'm missing something. You select GFXUMA but nothing seems to
> depend on it?
> 
> is there something else out there that uses this variable?
> 
Ah, hmm, I will have to look closer......
I just realized the add_northbridge_resources is not working eithor....
 
No one ACK this yet.

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




From buurin at gmail.com  Sun Mar 14 06:02:53 2010
From: buurin at gmail.com (Keith Hui)
Date: Sun, 14 Mar 2010 00:02:53 -0500
Subject: [coreboot] [PATCH] Implement DRAM buffer strength programming for
	440BX
Message-ID: <b72cdb061003132102o5a960b24o9619c2c94d20b37b@mail.gmail.com>

> > Below are debug outputs of my new RAM init code. As you can see it
> > isn't quite working. Can this output help in finding out why?
> No. You'll have to run a diff between the old (working?) and the new
> code and do a binary search over the changes to find out what's causing
> the trouble.
>
> Stefan

Thank you!

With your hint, I realized that I have made too many changes at once and
will have to make and test them one by one instead.

The result is this patch. It implements a full SDRAM buffer strength
programming algorithm in set_dram_buffer_strength(), checked against my
P2B-LS factory BIOS. With this in place, I now have 133MHz (!) stability
with three 256MB PC133 modules, and can boot Fedora 11 all the way to the
init daemon (actually upstart, but that's another story). Not to login
prompt yet. We'll find out why later.

This again assumes a 4-DIMM board because that's all I have. I need someone
with a 3-DIMM board to test it.

As a bonus, there's a big comment block within that illustrates the
algorithm. :-)

Signed-off-by: Keith Hui <buurin at gmail.com>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20100314/edfb3bea/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 440bxdrambuf.patch
Type: application/octet-stream
Size: 6545 bytes
Desc: not available
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20100314/edfb3bea/attachment.obj>

From svn at coreboot.org  Sun Mar 14 18:01:09 2010
From: svn at coreboot.org (repository service)
Date: Sun, 14 Mar 2010 18:01:09 +0100
Subject: [coreboot] [commit] r5207 - trunk/src/southbridge/intel/i82801dx
Message-ID: <E1NqrBd-0005HK-4z@ra.coresystems.de>

Author: stepan
Date: Sun Mar 14 18:01:08 2010
New Revision: 5207
URL: http://tracker.coreboot.org/trac/coreboot/changeset/5207

Log:
ICH4 update, fix ATA init, drop SATA (chipset doesn't have SATA)
fix some PCI IDs, enable USB bus mastering, add some license headers, ...

LPC code needs another look, but I think we're getting there.

Signed-off-by: Stefan Reinauer <stepan at coresystems.de>
Acked-by: Joseph Smith <joe at settoplinux.org>

Deleted:
   trunk/src/southbridge/intel/i82801dx/i82801dx_nic.c
   trunk/src/southbridge/intel/i82801dx/i82801dx_sata.c
Modified:
   trunk/src/southbridge/intel/i82801dx/Kconfig
   trunk/src/southbridge/intel/i82801dx/Makefile.inc
   trunk/src/southbridge/intel/i82801dx/chip.h
   trunk/src/southbridge/intel/i82801dx/cmos_failover.c
   trunk/src/southbridge/intel/i82801dx/i82801dx.c
   trunk/src/southbridge/intel/i82801dx/i82801dx.h
   trunk/src/southbridge/intel/i82801dx/i82801dx_early_smbus.c
   trunk/src/southbridge/intel/i82801dx/i82801dx_ide.c
   trunk/src/southbridge/intel/i82801dx/i82801dx_lpc.c
   trunk/src/southbridge/intel/i82801dx/i82801dx_pci.c
   trunk/src/southbridge/intel/i82801dx/i82801dx_reset.c
   trunk/src/southbridge/intel/i82801dx/i82801dx_smbus.c
   trunk/src/southbridge/intel/i82801dx/i82801dx_tco_timer.c
   trunk/src/southbridge/intel/i82801dx/i82801dx_usb.c
   trunk/src/southbridge/intel/i82801dx/i82801dx_usb2.c

Modified: trunk/src/southbridge/intel/i82801dx/Kconfig
==============================================================================
--- trunk/src/southbridge/intel/i82801dx/Kconfig	Sat Mar 13 23:07:15 2010	(r5206)
+++ trunk/src/southbridge/intel/i82801dx/Kconfig	Sun Mar 14 18:01:08 2010	(r5207)
@@ -1,3 +1,24 @@
+##
+## This file is part of the coreboot project.
+##
+## Copyright (C) 2008-2009 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; version 2 of
+## the License.
+##
+## This program is distributed in the hope that it will be useful,
+## but WITHOUT ANY WARRANTY; without even the implied warranty of
+## MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+## GNU General Public License for more details.
+##
+## You should have received a copy of the GNU General Public License
+## along with this program; if not, write to the Free Software
+## Foundation, Inc., 51 Franklin St, Fifth Floor, Boston,
+## MA 02110-1301 USA
+##
+
 config SOUTHBRIDGE_INTEL_I82801DX
 	bool
 	select IOAPIC

Modified: trunk/src/southbridge/intel/i82801dx/Makefile.inc
==============================================================================
--- trunk/src/southbridge/intel/i82801dx/Makefile.inc	Sat Mar 13 23:07:15 2010	(r5206)
+++ trunk/src/southbridge/intel/i82801dx/Makefile.inc	Sun Mar 14 18:01:08 2010	(r5207)
@@ -1,12 +1,33 @@
+##
+## This file is part of the coreboot project.
+##
+## Copyright (C) 2008-2009 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; version 2 of
+## the License.
+##
+## This program is distributed in the hope that it will be useful,
+## but WITHOUT ANY WARRANTY; without even the implied warranty of
+## MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+## GNU General Public License for more details.
+##
+## You should have received a copy of the GNU General Public License
+## along with this program; if not, write to the Free Software
+## Foundation, Inc., 51 Franklin St, Fifth Floor, Boston,
+## MA 02110-1301 USA
+##
+
 driver-y += i82801dx.o
-driver-y += i82801dx_usb.o
-driver-y += i82801dx_lpc.o
-driver-y += i82801dx_ide.o
-driver-y += i82801dx_usb2.o
 driver-y += i82801dx_ac97.o
-#driver-y += i82801dx_nic.o
+driver-y += i82801dx_ide.o
+driver-y += i82801dx_lpc.o
 #driver-y += i82801dx_pci.o
-obj-y += i82801dx_reset.o
+driver-y += i82801dx_usb.o
+driver-y += i82801dx_usb2.o
 
+obj-y += i82801dx_reset.o
 obj-$(CONFIG_HAVE_SMI_HANDLER) += i82801dx_smi.o
+
 smmobj-$(CONFIG_HAVE_SMI_HANDLER) += i82801dx_smihandler.o

Modified: trunk/src/southbridge/intel/i82801dx/chip.h
==============================================================================
--- trunk/src/southbridge/intel/i82801dx/chip.h	Sat Mar 13 23:07:15 2010	(r5206)
+++ trunk/src/southbridge/intel/i82801dx/chip.h	Sun Mar 14 18:01:08 2010	(r5207)
@@ -1,8 +1,27 @@
+/*
+ * This file is part of the coreboot project.
+ *
+ * Copyright (C) 2004 Eric Biederman
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License as
+ * published by the Free Software Foundation; version 2 of
+ * the License.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA  02110-1301 USA
+ */
+
 #ifndef I82801DX_CHIP_H
 #define I82801DX_CHIP_H
 
-struct southbridge_intel_i82801dx_config 
-{
+struct southbridge_intel_i82801dx_config {
 	int enable_usb;
 	int enable_native_ide;
 	/**
@@ -24,4 +43,4 @@
 
 extern struct chip_operations southbridge_intel_i82801dx_ops;
 
-#endif /* I82801DBM_CHIP_H */
+#endif				/* I82801DBM_CHIP_H */

Modified: trunk/src/southbridge/intel/i82801dx/cmos_failover.c
==============================================================================
--- trunk/src/southbridge/intel/i82801dx/cmos_failover.c	Sat Mar 13 23:07:15 2010	(r5206)
+++ trunk/src/southbridge/intel/i82801dx/cmos_failover.c	Sun Mar 14 18:01:08 2010	(r5207)
@@ -1,16 +1,35 @@
-//kind of cmos_err for ich5
+/*
+ * This file is part of the coreboot project.
+ *
+ * Copyright (C) 2004 Ron G. Minnich
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License as
+ * published by the Free Software Foundation; version 2 of
+ * the License.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA  02110-1301 USA
+ */
+
+// kind of cmos_err for ICH4
 #define RTC_FAILED    (1 <<2)
 #define GEN_PMCON_3     0xa4
-static void check_cmos_failed(void) 
+static void check_cmos_failed(void)
 {
-
-                uint8_t byte;
-                byte = pci_read_config8(PCI_DEV(0,0x1f,0),GEN_PMCON_3);
-                if( byte & RTC_FAILED){
-//clear bit 1 and bit 2
-                        byte = cmos_read(RTC_BOOT_BYTE);
-                        byte &= 0x0c;
-                        byte |= CONFIG_MAX_REBOOT_CNT << 4;
-                        cmos_write(byte, RTC_BOOT_BYTE);
-                }
+	u8 byte;
+	byte = pci_read_config8(PCI_DEV(0, 0x1f, 0), GEN_PMCON_3);
+	if (byte & RTC_FAILED) {
+		//clear bit 1 and bit 2
+		byte = cmos_read(RTC_BOOT_BYTE);
+		byte &= 0x0c;
+		byte |= CONFIG_MAX_REBOOT_CNT << 4;
+		cmos_write(byte, RTC_BOOT_BYTE);
+	}
 }

Modified: trunk/src/southbridge/intel/i82801dx/i82801dx.c
==============================================================================
--- trunk/src/southbridge/intel/i82801dx/i82801dx.c	Sat Mar 13 23:07:15 2010	(r5206)
+++ trunk/src/southbridge/intel/i82801dx/i82801dx.c	Sun Mar 14 18:01:08 2010	(r5207)
@@ -1,3 +1,23 @@
+/*
+ * This file is part of the coreboot project.
+ *
+ * Copyright (C) 2004 Ron G. Minnich
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License as
+ * published by the Free Software Foundation; version 2 of
+ * the License.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA  02110-1301 USA
+ */
+
 #include <console/console.h>
 #include <device/device.h>
 #include <device/pci.h>
@@ -10,48 +30,49 @@
 	uint8_t bHasDisableBit = 0;
 	uint16_t cur_disable_mask, new_disable_mask;
 
-//	all 82801dbm devices are in bus 0
-	unsigned int devfn = PCI_DEVFN(0x1f, 0); // lpc
-	device_t lpc_dev = dev_find_slot(0, devfn); // 0
+//      all 82801dbm devices are in bus 0
+	unsigned int devfn = PCI_DEVFN(0x1f, 0);	// lpc
+	device_t lpc_dev = dev_find_slot(0, devfn);	// 0
 	if (!lpc_dev)
 		return;
 
 	// Calculate disable bit position for specified device:function
 	// NOTE: For ICH-4, only the following devices can be disabled:
-	//		 D31: F0, F1, F3, F5, F6, 
-	//		 D29: F0, F1, F2, F7
+	//               D31: F0, F1, F3, F5, F6, 
+	//               D29: F0, F1, F2, F7
 
-    if (PCI_SLOT(dev->path.pci.devfn) == 31) {
-    	index = PCI_FUNC(dev->path.pci.devfn);
+	if (PCI_SLOT(dev->path.pci.devfn) == 31) {
+		index = PCI_FUNC(dev->path.pci.devfn);
 
 		switch (index) {
-			case 0:
-			case 1:
-			case 3:
-			case 5:
-			case 6:
-				bHasDisableBit = 1;
-				break;
-			
-			default:
-				break;
+		case 0:
+		case 1:
+		case 3:
+		case 5:
+		case 6:
+			bHasDisableBit = 1;
+			break;
+
+		default:
+			break;
 		};
-		
+
 		if (index == 0)
-			index = 14;		// D31:F0 bit is an exception
+			index = 14;	// D31:F0 bit is an exception
 
-    } else if (PCI_SLOT(dev->path.pci.devfn) == 29) {
-    	index = 8 + PCI_FUNC(dev->path.pci.devfn);
+	} else if (PCI_SLOT(dev->path.pci.devfn) == 29) {
+		index = 8 + PCI_FUNC(dev->path.pci.devfn);
 
-		if ((PCI_FUNC(dev->path.pci.devfn) < 3) || (PCI_FUNC(dev->path.pci.devfn) == 7))
+		if ((PCI_FUNC(dev->path.pci.devfn) < 3)
+		    || (PCI_FUNC(dev->path.pci.devfn) == 7))
 			bHasDisableBit = 1;
-    }
+	}
 
 	if (bHasDisableBit) {
 		cur_disable_mask = pci_read_config16(lpc_dev, FUNC_DIS);
-		new_disable_mask = cur_disable_mask & ~(1<<index); 		// enable it
+		new_disable_mask = cur_disable_mask & ~(1 << index);	// enable it
 		if (!dev->enabled) {
-			new_disable_mask |= (1<<index);  // disable it
+			new_disable_mask |= (1 << index);	// disable it
 		}
 		if (new_disable_mask != cur_disable_mask) {
 			pci_write_config16(lpc_dev, FUNC_DIS, new_disable_mask);
@@ -61,5 +82,5 @@
 
 struct chip_operations southbridge_intel_i82801dx_ops = {
 	CHIP_NAME("Intel ICH4/ICH4-M (82801Dx) Series Southbridge")
-	.enable_dev = i82801dx_enable,
+	    .enable_dev = i82801dx_enable,
 };

Modified: trunk/src/southbridge/intel/i82801dx/i82801dx.h
==============================================================================
--- trunk/src/southbridge/intel/i82801dx/i82801dx.h	Sat Mar 13 23:07:15 2010	(r5206)
+++ trunk/src/southbridge/intel/i82801dx/i82801dx.h	Sun Mar 14 18:01:08 2010	(r5207)
@@ -1,3 +1,25 @@
+/*
+ * This file is part of the coreboot project.
+ *
+ * Copyright (C) 2004 Ron G. Minnich
+ * Copyright (C) 2004 Eric Biederman
+ * Copyright (C) 2008-2009 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; version 2 of
+ * the License.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA  02110-1301 USA
+ */
+
 /* the problem: we have 82801dbm support in fb1, and 82801er in fb2. 
  * fb1 code is what we want, fb2 structure is needed however. 
  * so we need to get fb1 code for 82801dbm into fb2 structure. 
@@ -23,15 +45,23 @@
 #endif
 
 /*
-000 = Non-combined. P0 is primary master. P1 is secondary master.
-001 = Non-combined. P0 is secondary master. P1 is primary master.
-100 = Combined. P0 is primary master. P1 is primary slave. IDE is secondary; Primary IDE channel
-disabled.
-101 = Combined. P0 is primary slave. P1 is primary master. IDE is secondary.
-110 = Combined. IDE is primary. P0 is secondary master. P1 is secondary slave; Secondary IDE
-channel disabled.
-111 = Combined. IDE is primary. P0 is secondary slave. P1 is secondary master.
-*/
+ * 000 = Non-combined. P0 is primary master. P1 is secondary master.
+ * 001 = Non-combined. P0 is secondary master. P1 is primary master.
+ * 100 = Combined. P0 is primary master. P1 is primary slave. IDE is secondary;
+ *       Primary IDE channel disabled.
+ * 101 = Combined. P0 is primary slave. P1 is primary master. IDE is secondary.
+ * 110 = Combined. IDE is primary. P0 is secondary master. P1 is secondary
+ *       slave; Secondary IDE channel disabled.
+ * 111 = Combined. IDE is primary. P0 is secondary slave. P1 is secondary master.
+ */
+/* PCI Configuration Space (D31:F1) */
+#define IDE_TIM_PRI		0x40	/* IDE timings, primary */
+#define IDE_TIM_SEC		0x42	/* IDE timings, secondary */
+
+/* IDE_TIM bits */
+#define IDE_DECODE_ENABLE	(1 << 15)
+
+
 
 #define PCI_DMA_CFG     0x90
 #define SERIRQ_CNTL     0x64

Modified: trunk/src/southbridge/intel/i82801dx/i82801dx_early_smbus.c
==============================================================================
--- trunk/src/southbridge/intel/i82801dx/i82801dx_early_smbus.c	Sat Mar 13 23:07:15 2010	(r5206)
+++ trunk/src/southbridge/intel/i82801dx/i82801dx_early_smbus.c	Sun Mar 14 18:01:08 2010	(r5207)
@@ -1,3 +1,22 @@
+/*
+ * This file is part of the coreboot project.
+ *
+ * Copyright (C) 2004 Ronald G. Minnich
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License as
+ * published by the Free Software Foundation; version 2 of
+ * the License.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA  02110-1301 USA
+ */
 
 //#define SMBUS_IO_BASE 0x1000
 //#define SMBUS_IO_BASE 0x0f00
@@ -12,7 +31,7 @@
 #define SMBTRNSADD 0x9
 #define SMBSLVDATA 0xa
 #define SMLINK_PIN_CTL 0xe
-#define SMBUS_PIN_CTL  0xf 
+#define SMBUS_PIN_CTL  0xf
 
 /* Between 1-10 seconds, We should never timeout normally 
  * Longer than this is just painful when a timeout condition occurs.
@@ -28,15 +47,14 @@
 	pci_write_config32(dev, 0x20, SMBUS_IO_BASE | 1);
 	/* Set smbus enable */
 	pci_write_config8(dev, 0x40, 0x01);
-	/* Set smbus iospace enable */ 
+	/* Set smbus iospace enable */
 	pci_write_config16(dev, 0x4, 0x01);
-	/* Disable interrupt generation */ 
+	/* Disable interrupt generation */
 	outb(0, SMBUS_IO_BASE + SMBHSTCTL);
 	/* clear any lingering errors, so the transaction will run */
 	outb(inb(SMBUS_IO_BASE + SMBHSTSTAT), SMBUS_IO_BASE + SMBHSTSTAT);
 }
 
-
 static inline void smbus_delay(void)
 {
 	outb(0x80, 0x80);
@@ -53,8 +71,8 @@
 		if ((val & 1)) {
 			break;
 		}
-	} while(--loops);
-	return loops?0:-4;
+	} while (--loops);
+	return loops ? 0 : -4;
 }
 
 static int smbus_wait_until_ready(void)
@@ -68,12 +86,12 @@
 		if ((val & 1) == 0) {
 			break;
 		}
-		if(loops == (SMBUS_TIMEOUT / 2)) {
-			outb(inb(SMBUS_IO_BASE + SMBHSTSTAT), 
-				SMBUS_IO_BASE + SMBHSTSTAT);
+		if (loops == (SMBUS_TIMEOUT / 2)) {
+			outb(inb(SMBUS_IO_BASE + SMBHSTSTAT),
+			     SMBUS_IO_BASE + SMBHSTSTAT);
 		}
-	} while(--loops);
-	return loops?0:-2;
+	} while (--loops);
+	return loops ? 0 : -2;
 }
 
 static int smbus_wait_until_done(void)
@@ -83,16 +101,16 @@
 	do {
 		unsigned char val;
 		smbus_delay();
-		
+
 		val = inb(SMBUS_IO_BASE + SMBHSTSTAT);
-		if ( (val & 1) == 0) {
+		if ((val & 1) == 0) {
 			break;
 		}
-		if ((val & ~((1<<6)|(1<<0)) ) != 0 ) {
+		if ((val & ~((1 << 6) | (1 << 0))) != 0) {
 			break;
 		}
-	} while(--loops);
-	return loops?0:-3;
+	} while (--loops);
+	return loops ? 0 : -3;
 }
 
 static int smbus_read_byte(unsigned device, unsigned address)
@@ -101,12 +119,12 @@
 	unsigned char global_status_register;
 	unsigned char byte;
 
-	/*print_err("smbus_read_byte\r\n");*/
+	/*print_err("smbus_read_byte\r\n"); */
 	if (smbus_wait_until_ready() < 0) {
 		print_err_hex8(-2);
 		return -2;
 	}
-	
+
 	/* setup transaction */
 	/* disable interrupts */
 	outb(inb(SMBUS_IO_BASE + SMBHSTCTL) & 0xfe, SMBUS_IO_BASE + SMBHSTCTL);
@@ -115,16 +133,18 @@
 	/* set the command/address... */
 	outb(address & 0xFF, SMBUS_IO_BASE + SMBHSTCMD);
 	/* set up for a byte data read */
-	outb((inb(SMBUS_IO_BASE + SMBHSTCTL) & 0xe3) | (0x2<<2), SMBUS_IO_BASE + SMBHSTCTL);
+	outb((inb(SMBUS_IO_BASE + SMBHSTCTL) & 0xe3) | (0x2 << 2),
+	     SMBUS_IO_BASE + SMBHSTCTL);
 
 	/* clear any lingering errors, so the transaction will run */
 	outb(inb(SMBUS_IO_BASE + SMBHSTSTAT), SMBUS_IO_BASE + SMBHSTSTAT);
 
-	/* clear the data byte...*/
+	/* clear the data byte... */
 	outb(0, SMBUS_IO_BASE + SMBHSTDAT0);
 
 	/* start a byte read, with interrupts disabled */
-	outb((inb(SMBUS_IO_BASE + SMBHSTCTL) | 0x40), SMBUS_IO_BASE + SMBHSTCTL);
+	outb((inb(SMBUS_IO_BASE + SMBHSTCTL) | 0x40),
+	     SMBUS_IO_BASE + SMBHSTCTL);
 	/* poll for it to start */
 	if (smbus_wait_until_active() < 0) {
 		print_err_hex8(-4);
@@ -137,7 +157,7 @@
 		return -3;
 	}
 
-	global_status_register = inb(SMBUS_IO_BASE + SMBHSTSTAT) & ~(1<<6); /* Ignore the In Use Status... */
+	global_status_register = inb(SMBUS_IO_BASE + SMBHSTSTAT) & ~(1 << 6);	/* Ignore the In Use Status... */
 
 	/* read results of transaction */
 	byte = inb(SMBUS_IO_BASE + SMBHSTDAT0);
@@ -153,15 +173,17 @@
  */
 	return byte;
 }
+
 #if 0
-static void smbus_write_byte(unsigned device, unsigned address, unsigned char val)
+static void smbus_write_byte(unsigned device, unsigned address,
+			     unsigned char val)
 {
 	if (smbus_wait_until_ready() < 0) {
 		return;
 	}
 
 	/* by LYH */
-	outb(0x37,SMBUS_IO_BASE + SMBHSTSTAT);
+	outb(0x37, SMBUS_IO_BASE + SMBHSTSTAT);
 	/* set the device I'm talking too */
 	outw(((device & 0x7f) << 1) | 0, SMBUS_IO_BASE + SMBHSTADDR);
 

Modified: trunk/src/southbridge/intel/i82801dx/i82801dx_ide.c
==============================================================================
--- trunk/src/southbridge/intel/i82801dx/i82801dx_ide.c	Sat Mar 13 23:07:15 2010	(r5206)
+++ trunk/src/southbridge/intel/i82801dx/i82801dx_ide.c	Sun Mar 14 18:01:08 2010	(r5207)
@@ -1,3 +1,23 @@
+/*
+ * This file is part of the coreboot project.
+ *
+ * Copyright (C) 2004 Ronald G. Minnich
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License as
+ * published by the Free Software Foundation; version 2 of
+ * the License.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA  02110-1301 USA
+ */
+
 #include <console/console.h>
 #include <device/device.h>
 #include <device/pci.h>
@@ -5,49 +25,58 @@
 #include <device/pci_ops.h>
 #include "i82801dx.h"
 
+typedef struct southbridge_intel_i82801dx_config config_t;
 
 static void ide_init(struct device *dev)
 {
-#if ICH5_SATA_ADDRESS_MAP<=1
-	/* Enable ide devices so the linux ide driver will work */
-	uint16_t word;
-	uint8_t byte;
-	int enable_a=1, enable_b=1;
+	/* Get the chip configuration */
+	config_t *config = dev->chip_info;
 
+	/* Enable IDE devices so the Linux IDE driver will work. */
+	uint16_t ideTimingConfig;
 
-	word = pci_read_config16(dev, 0x40);
-	word &= ~((1 << 15));
-	if (enable_a) {
-		/* Enable first ide interface */
-		word |= (1<<15);
-		printk_debug("IDE0 ");
+	ideTimingConfig = pci_read_config16(dev, IDE_TIM_PRI);
+	ideTimingConfig &= ~IDE_DECODE_ENABLE;
+	if (!config || config->ide0_enable) {
+		/* Enable primary IDE interface. */
+		ideTimingConfig |= IDE_DECODE_ENABLE;
+		printk_debug("IDE0: Primary IDE interface is enabled\n");
+	} else {
+		printk_info("IDE0: Primary IDE interface is disabled\n");
 	}
-	pci_write_config16(dev, 0x40, word);
-
-        word = pci_read_config16(dev, 0x42);
-        word &= ~((1 << 15));
-        if (enable_b) {
-                /* Enable secondary ide interface */
-                word |= (1<<15);
-                printk_debug("IDE1 ");
-        }
-        pci_write_config16(dev, 0x42, word);
-#endif
+	pci_write_config16(dev, IDE_TIM_PRI, ideTimingConfig);
 
+	ideTimingConfig = pci_read_config16(dev, IDE_TIM_SEC);
+	ideTimingConfig &= ~IDE_DECODE_ENABLE;
+	if (!config || config->ide1_enable) {
+		/* Enable secondary IDE interface. */
+		ideTimingConfig |= IDE_DECODE_ENABLE;
+		printk_debug("IDE1: Secondary IDE interface is enabled\n");
+	} else {
+		printk_info("IDE1: Secondary IDE interface is disabled\n");
+	}
+	pci_write_config16(dev, IDE_TIM_SEC, ideTimingConfig);
 }
 
-static struct device_operations ide_ops  = {
-	.read_resources   = pci_dev_read_resources,
-	.set_resources    = pci_dev_set_resources,
+static struct device_operations ide_ops = {
+	.read_resources = pci_dev_read_resources,
+	.set_resources = pci_dev_set_resources,
 	.enable_resources = pci_dev_enable_resources,
-	.init             = ide_init,
-	.scan_bus         = 0,
-	.enable           = i82801dx_enable,
+	.init = ide_init,
+	.scan_bus = 0,
+	.enable = i82801dx_enable,
 };
 
-static const struct pci_driver ide_driver __pci_driver = {
-	.ops    = &ide_ops,
+/* 82801DB */
+static const struct pci_driver i82801db_ide __pci_driver = {
+	.ops = &ide_ops,
 	.vendor = PCI_VENDOR_ID_INTEL,
-	.device = PCI_DEVICE_ID_INTEL_82801DBM_IDE,
+	.device = 0x24cb,
 };
 
+/* 82801DBM */
+static const struct pci_driver i82801dbm_ide __pci_driver = {
+	.ops = &ide_ops,
+	.vendor = PCI_VENDOR_ID_INTEL,
+	.device = 0x24ca,
+};

Modified: trunk/src/southbridge/intel/i82801dx/i82801dx_lpc.c
==============================================================================
--- trunk/src/southbridge/intel/i82801dx/i82801dx_lpc.c	Sat Mar 13 23:07:15 2010	(r5206)
+++ trunk/src/southbridge/intel/i82801dx/i82801dx_lpc.c	Sun Mar 14 18:01:08 2010	(r5207)
@@ -1,7 +1,25 @@
 /*
- * (C) 2003 Linux Networx, SuSE Linux AG
- * (C) 2004 Tyan Computer
+ * This file is part of the coreboot project.
+ *
+ * Copyright (C) 2003 Linux Networx
+ * Copyright (C) 2004 SuSE Linux AG
+ * Copyright (C) 2004 Tyan Computer
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License as
+ * published by the Free Software Foundation; version 2 of
+ * the License.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA  02110-1301 USA
  */
+
 #include <console/console.h>
 #include <device/device.h>
 #include <device/pci.h>
@@ -12,113 +30,113 @@
 #include <arch/io.h>
 #include "i82801dx.h"
 
-
-
 #define NMI_OFF 0
 
-void i82801dx_enable_ioapic( struct device *dev) 
+void i82801dx_enable_ioapic(struct device *dev)
 {
-        uint32_t dword;
-        volatile uint32_t *ioapic_sba = (volatile uint32_t *)0xfec00000;
-        volatile uint32_t *ioapic_sbd = (volatile uint32_t *)0xfec00010;
-
-        dword = pci_read_config32(dev, GEN_CNTL);
-        dword |= (3 << 7); /* enable ioapic */
-        dword |= (1 <<13); /* coprocessor error enable */
-        dword |= (1 << 1); /* delay transaction enable */
-        dword |= (1 << 2); /* DMA collection buf enable */
-        pci_write_config32(dev, GEN_CNTL, dword);
-        printk_debug("ioapic southbridge enabled %x\n",dword);
-        *ioapic_sba=0;
-        *ioapic_sbd=(2<<24);
-        //lyh *ioapic_sba=3;
-        //lyh *ioapic_sbd=1;    
-        *ioapic_sba=0;
-        dword=*ioapic_sbd;
-        printk_debug("Southbridge apic id = %x\n",dword);
-        if(dword!=(2<<24))
-                die("");
-        //lyh *ioapic_sba=3;
-        //lyh dword=*ioapic_sbd;
-        //lyh printk_debug("Southbridge apic DT = %x\n",dword);
-        //lyh if(dword!=1)
-        //lyh   die("");
-
+	u32 dword;
+	volatile u32 *ioapic_sba = (volatile u32 *)0xfec00000;
+	volatile u32 *ioapic_sbd = (volatile u32 *)0xfec00010;
+
+	dword = pci_read_config32(dev, GEN_CNTL);
+	dword |= (3 << 7);	/* enable ioapic */
+	dword |= (1 << 13);	/* coprocessor error enable */
+	dword |= (1 << 1);	/* delay transaction enable */
+	dword |= (1 << 2);	/* DMA collection buf enable */
+	pci_write_config32(dev, GEN_CNTL, dword);
+	printk_debug("ioapic southbridge enabled %x\n", dword);
+	*ioapic_sba = 0;
+	*ioapic_sbd = (2 << 24);
+	//lyh *ioapic_sba=3;
+	//lyh *ioapic_sbd=1;    
+	*ioapic_sba = 0;
+	dword = *ioapic_sbd;
+	printk_debug("Southbridge apic id = %x\n", dword);
+	if (dword != (2 << 24))
+		die("");
+	//lyh *ioapic_sba=3;
+	//lyh dword=*ioapic_sbd;
+	//lyh printk_debug("Southbridge apic DT = %x\n",dword);
+	//lyh if(dword!=1)
+	//lyh   die("");
 
 }
-void i82801dx_enable_serial_irqs( struct device *dev)
-{
-        pci_write_config8(dev, SERIRQ_CNTL, (1 << 7)|(1 << 6)|((21 - 17) << 2)|(0<< 0));
-}
-void i82801dx_lpc_route_dma( struct device *dev, uint8_t mask) 
-{
-        uint16_t word;
-        int i;
-        word = pci_read_config16(dev, PCI_DMA_CFG);
-        word &= ((1 << 10) - (1 << 8));
-        for(i = 0; i < 8; i++) {
-                if (i == 4)
-                        continue;
-                word |= ((mask & (1 << i))? 3:1) << (i*2);
-        }
-        pci_write_config16(dev, PCI_DMA_CFG, word);
+
+void i82801dx_enable_serial_irqs(struct device *dev)
+{
+	pci_write_config8(dev, SERIRQ_CNTL,
+			  (1 << 7) | (1 << 6) | ((21 - 17) << 2) | (0 << 0));
+}
+
+void i82801dx_lpc_route_dma(struct device *dev, u8 mask)
+{
+	u16 word;
+	int i;
+	word = pci_read_config16(dev, PCI_DMA_CFG);
+	word &= ((1 << 10) - (1 << 8));
+	for (i = 0; i < 8; i++) {
+		if (i == 4)
+			continue;
+		word |= ((mask & (1 << i)) ? 3 : 1) << (i * 2);
+	}
+	pci_write_config16(dev, PCI_DMA_CFG, word);
 }
+
 void i82801dx_rtc_init(struct device *dev)
 {
-        uint8_t byte;
-        uint32_t dword;
-        int rtc_failed;
-        byte = pci_read_config8(dev, GEN_PMCON_3);
-        rtc_failed = byte & RTC_FAILED;
-        if (rtc_failed) {
-                byte &= ~(1 << 1); /* preserve the power fail state */
-                pci_write_config8(dev, GEN_PMCON_3, byte);
-        }
-        dword = pci_read_config32(dev, GEN_STS);
-        rtc_failed |= dword & (1 << 2);
-        rtc_init(rtc_failed);
+	u8 byte;
+	u32 dword;
+	int rtc_failed;
+	byte = pci_read_config8(dev, GEN_PMCON_3);
+	rtc_failed = byte & RTC_FAILED;
+	if (rtc_failed) {
+		byte &= ~(1 << 1);	/* preserve the power fail state */
+		pci_write_config8(dev, GEN_PMCON_3, byte);
+	}
+	dword = pci_read_config32(dev, GEN_STS);
+	rtc_failed |= dword & (1 << 2);
+	rtc_init(rtc_failed);
 }
 
-
 void i82801dx_1f0_misc(struct device *dev)
 {
-        pci_write_config16(dev, PCICMD, 0x014f);
-        pci_write_config32(dev, PMBASE, 0x00001001);
-        pci_write_config8(dev, ACPI_CNTL, 0x10);
-        pci_write_config32(dev, GPIO_BASE, 0x00001181);
-        pci_write_config8(dev, GPIO_CNTL, 0x10);
-        pci_write_config32(dev, PIRQA_ROUT, 0x0A05030B);
-        pci_write_config8(dev, PIRQE_ROUT, 0x07);
-        pci_write_config8(dev, RTC_CONF, 0x04);
-        pci_write_config8(dev, COM_DEC, 0x10);  //lyh E0->
-        pci_write_config16(dev, LPC_EN, 0x000F);  //LYH 000D->
+	pci_write_config16(dev, PCICMD, 0x014f);
+	pci_write_config32(dev, PMBASE, 0x00001001);
+	pci_write_config8(dev, ACPI_CNTL, 0x10);
+	pci_write_config32(dev, GPIO_BASE, 0x00001181);
+	pci_write_config8(dev, GPIO_CNTL, 0x10);
+	pci_write_config32(dev, PIRQA_ROUT, 0x0A05030B);
+	pci_write_config8(dev, PIRQE_ROUT, 0x07);
+	pci_write_config8(dev, RTC_CONF, 0x04);
+	pci_write_config8(dev, COM_DEC, 0x10);	//lyh E0->
+	pci_write_config16(dev, LPC_EN, 0x000F);	//LYH 000D->
 }
 
 static void enable_hpet(struct device *dev)
 {
 	const unsigned long hpet_address = 0xfed0000;
 
-        uint32_t dword;
-	uint32_t code = (0 & 0x3);
-        
-        dword = pci_read_config32(dev, GEN_CNTL);
-        dword |= (1 << 17); /* enable hpet */
+	u32 dword;
+	u32 code = (0 & 0x3);
+
+	dword = pci_read_config32(dev, GEN_CNTL);
+	dword |= (1 << 17);	/* enable hpet */
 	/*Bits [16:15]Memory Address Range
-	00 FED0_0000h - FED0_03FFh
-	01 FED0_1000h - FED0_13FFh
-	10 FED0_2000h - FED0_23FFh
-	11 FED0_3000h - FED0_33FFh*/
+	   00 FED0_0000h - FED0_03FFh
+	   01 FED0_1000h - FED0_13FFh
+	   10 FED0_2000h - FED0_23FFh
+	   11 FED0_3000h - FED0_33FFh */
 
-        dword &= ~(3 << 15); /* clear it */
-	dword |= (code<<15);
+	dword &= ~(3 << 15);	/* clear it */
+	dword |= (code << 15);
 
-	printk_debug("enabling HPET @0x%x\n", hpet_address | (code <<12) );
+	printk_debug("enabling HPET @0x%x\n", hpet_address | (code << 12));
 }
 
 static void lpc_init(struct device *dev)
 {
-	uint8_t byte;
-	int pwr_on=-1;
+	u8 byte;
+	int pwr_on = -1;
 	int nmi_option;
 
 	/* IO APIC initialization */
@@ -126,24 +144,24 @@
 
 	i82801dx_enable_serial_irqs(dev);
 
-#ifdef SUSPICIOUS_LOOKING_CODE	
+#ifdef SUSPICIOUS_LOOKING_CODE
 	// The ICH-4 datasheet does not mention this configuration register. 
 	// This code may have been inherited (incorrectly) from code for the AMD 766 southbridge,
 	// which *does* support this functionality.
 
 	/* posted memory write enable */
 	byte = pci_read_config8(dev, 0x46);
-	pci_write_config8(dev, 0x46, byte | (1<<0)); 
+	pci_write_config8(dev, 0x46, byte | (1 << 0));
 #endif
 
 	/* power after power fail */
-	        /* FIXME this doesn't work! */
-        /* Which state do we want to goto after g3 (power restored)?
-         * 0 == S0 Full On
-         * 1 == S5 Soft Off
-         */
-        pci_write_config8(dev, GEN_PMCON_3, pwr_on?0:1);
-        printk_info("set power %s after power fail\n", pwr_on?"on":"off");
+	/* FIXME this doesn't work! */
+	/* Which state do we want to goto after g3 (power restored)?
+	 * 0 == S0 Full On
+	 * 1 == S5 Soft Off
+	 */
+	pci_write_config8(dev, GEN_PMCON_3, pwr_on ? 0 : 1);
+	printk_info("set power %s after power fail\n", pwr_on ? "on" : "off");
 #if 0
 	/* Enable Error reporting */
 	/* Set up sync flood detected */
@@ -153,18 +171,18 @@
 #endif
 
 	/* Set up NMI on errors */
-    byte = inb(0x61);
-    byte &= ~(1 << 3); /* IOCHK# NMI Enable */
-    byte &= ~(1 << 2); /* PCI SERR# Enable */
-    outb(byte, 0x61);
-    byte = inb(0x70);
+	byte = inb(0x61);
+	byte &= ~(1 << 3);	/* IOCHK# NMI Enable */
+	byte &= ~(1 << 2);	/* PCI SERR# Enable */
+	outb(byte, 0x61);
+	byte = inb(0x70);
 	nmi_option = NMI_OFF;
 	get_option(&nmi_option, "nmi");
-	if (nmi_option) {			
-        byte &= ~(1 << 7); /* set NMI */
-        outb(byte, 0x70);
+	if (nmi_option) {
+		byte &= ~(1 << 7);	/* set NMI */
+		outb(byte, 0x70);
 	}
-	
+
 	/* Initialize the real time clock */
 	i82801dx_rtc_init(dev);
 
@@ -190,15 +208,15 @@
 	res->base = 0;
 	res->size = 0x1000;
 	res->flags = IORESOURCE_IO | IORESOURCE_SUBTRACTIVE |
-		     IORESOURCE_ASSIGNED | IORESOURCE_FIXED;
+	    IORESOURCE_ASSIGNED | IORESOURCE_FIXED;
 
 	res = new_resource(dev, IOINDEX_SUBTRACTIVE(1, 0));
 	res->base = 0xff800000;
-	res->size = 0x00800000; /* 8 MB for flash */
+	res->size = 0x00800000;	/* 8 MB for flash */
 	res->flags = IORESOURCE_MEM | IORESOURCE_SUBTRACTIVE |
-		     IORESOURCE_ASSIGNED | IORESOURCE_FIXED;
+	    IORESOURCE_ASSIGNED | IORESOURCE_FIXED;
 
-	res = new_resource(dev, 3); /* IOAPIC */
+	res = new_resource(dev, 3);	/* IOAPIC */
 	res->base = 0xfec00000;
 	res->size = 0x00001000;
 	res->flags = IORESOURCE_MEM | IORESOURCE_ASSIGNED | IORESOURCE_FIXED;
@@ -210,17 +228,25 @@
 	enable_childrens_resources(dev);
 }
 
-static struct device_operations lpc_ops  = {
-	.read_resources   = i82801dx_lpc_read_resources,
-	.set_resources    = pci_dev_set_resources,
+static struct device_operations lpc_ops = {
+	.read_resources = i82801dx_lpc_read_resources,
+	.set_resources = pci_dev_set_resources,
 	.enable_resources = i82801dx_lpc_enable_resources,
-	.init             = lpc_init,
-	.scan_bus         = scan_static_bus,
-	.enable           = i82801dx_enable,
+	.init = lpc_init,
+	.scan_bus = scan_static_bus,
+	.enable = i82801dx_enable,
+};
+
+/* 82801DB/DBL */
+static const struct pci_driver lpc_driver_db __pci_driver = {
+	.ops = &lpc_ops,
+	.vendor = PCI_VENDOR_ID_INTEL,
+	.device = PCI_DEVICE_ID_INTEL_82801DB_LPC,
 };
 
-static const struct pci_driver lpc_driver __pci_driver = {
-	.ops    = &lpc_ops,
+/* 82801DBM */
+static const struct pci_driver lpc_driver_dbm __pci_driver = {
+	.ops = &lpc_ops,
 	.vendor = PCI_VENDOR_ID_INTEL,
 	.device = PCI_DEVICE_ID_INTEL_82801DBM_LPC,
 };

Modified: trunk/src/southbridge/intel/i82801dx/i82801dx_pci.c
==============================================================================
--- trunk/src/southbridge/intel/i82801dx/i82801dx_pci.c	Sat Mar 13 23:07:15 2010	(r5206)
+++ trunk/src/southbridge/intel/i82801dx/i82801dx_pci.c	Sun Mar 14 18:01:08 2010	(r5207)
@@ -1,3 +1,22 @@
+/*
+ * This file is part of the coreboot project.
+ *
+ * Copyright (C) 2004 Ronald G. Minnich
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; version 2 of the License.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA
+ */
+
 #include <console/console.h>
 #include <device/device.h>
 #include <device/pci.h>
@@ -11,23 +30,29 @@
 	uint32_t dword;
 	/* System error enable */
 	dword = pci_read_config32(dev, 0x04);
-	dword |= (1<<8); /* SERR# Enable */
-	dword |= (1<<6); /* Parity Error Response */
+	dword |= (1 << 8);	/* SERR# Enable */
+	dword |= (1 << 6);	/* Parity Error Response */
 	pci_write_config32(dev, 0x04, dword);
-
 }
 
-static struct device_operations pci_ops  = {
-	.read_resources   = pci_bus_read_resources,
-	.set_resources    = pci_dev_set_resources,
+static struct device_operations pci_ops = {
+	.read_resources = pci_bus_read_resources,
+	.set_resources = pci_dev_set_resources,
 	.enable_resources = pci_bus_enable_resources,
-	.init             = pci_init,
-	.scan_bus         = pci_scan_bridge,
+	.init = pci_init,
+	.scan_bus = pci_scan_bridge,
 };
 
-static const struct pci_driver pci_driver __pci_driver = {
-	.ops    = &pci_ops,
+/* 82801DB */
+static const struct pci_driver pci_driver_db __pci_driver = {
+	.ops = &pci_ops,
 	.vendor = PCI_VENDOR_ID_INTEL,
-	.device = PCI_DEVICE_ID_INTEL_82801DBM_PCI,
+	.device = PCI_DEVICE_ID_INTEL_82801DB_PCI,
 };
 
+/* 82801DBM/DBL */
+static const struct pci_driver pci_driver_dbm __pci_driver = {
+	.ops = &pci_ops,
+	.vendor = PCI_VENDOR_ID_INTEL,
+	.device = PCI_DEVICE_ID_INTEL_82801DBM_PCI,
+};

Modified: trunk/src/southbridge/intel/i82801dx/i82801dx_reset.c
==============================================================================
--- trunk/src/southbridge/intel/i82801dx/i82801dx_reset.c	Sat Mar 13 23:07:15 2010	(r5206)
+++ trunk/src/southbridge/intel/i82801dx/i82801dx_reset.c	Sun Mar 14 18:01:08 2010	(r5207)
@@ -1,7 +1,26 @@
+/*
+ * This file is part of the coreboot project.
+ *
+ * Copyright (C) 2004 Ronald G. Minnich
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; version 2 of the License.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA
+ */
+
 #include <arch/io.h>
 
 void hard_reset(void)
 {
-        /* Try rebooting through port 0xcf9 */
-        outb((0 <<3)|(1<<2)|(1<<1), 0xcf9);
+	/* Try rebooting through port 0xcf9 */
+	outb((0 << 3) | (1 << 2) | (1 << 1), 0xcf9);
 }

Modified: trunk/src/southbridge/intel/i82801dx/i82801dx_smbus.c
==============================================================================
--- trunk/src/southbridge/intel/i82801dx/i82801dx_smbus.c	Sat Mar 13 23:07:15 2010	(r5206)
+++ trunk/src/southbridge/intel/i82801dx/i82801dx_smbus.c	Sun Mar 14 18:01:08 2010	(r5207)
@@ -1,3 +1,22 @@
+/*
+ * This file is part of the coreboot project.
+ *
+ * Copyright (C) 2004 Ronald G. Minnich
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; version 2 of the License.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA
+ */
+
 #include "i82801dx.h"
 #include <smbus.h>
 #include <pci.h>
@@ -6,29 +25,18 @@
 #define PM_BUS 0
 #define PM_DEVFN PCI_DEVFN(0x1f,3)
 
-#if 0
-#define SMBUS_IO_BASE 0x1000
-#define SMBHSTSTAT 0
-#define SMBHSTCTL  2
-#define SMBHSTCMD  3
-#define SMBHSTADD  4
-#define SMBHSTDAT0 5
-#define SMBHSTDAT1 6
-#define SMBBLKDAT  7
-#endif
-
 void smbus_enable(void)
 {
 	unsigned char byte;
 	/* iobase addr */
 	pcibios_write_config_dword(PM_BUS, PM_DEVFN, 0x20, SMBUS_IO_BASE | 1);
 	/* smbus enable */
-	pcibios_write_config_byte(PM_BUS, PM_DEVFN, 0x40,  1);
+	pcibios_write_config_byte(PM_BUS, PM_DEVFN, 0x40, 1);
 	/* iospace enable */
 	pcibios_write_config_word(PM_BUS, PM_DEVFN, 0x4, 1);
 
-        /* Disable interrupt generation */
-        outb(0, SMBUS_IO_BASE + SMBHSTCTL);
+	/* Disable interrupt generation */
+	outb(0, SMBUS_IO_BASE + SMBHSTCTL);
 
 }
 
@@ -39,7 +47,7 @@
 
 static void smbus_wait_until_ready(void)
 {
-	while((inb(SMBUS_IO_BASE + SMBHSTSTAT) & 1) == 1) {
+	while ((inb(SMBUS_IO_BASE + SMBHSTSTAT) & 1) == 1) {
 		/* nop */
 	}
 }
@@ -50,8 +58,8 @@
 	do {
 		byte = inb(SMBUS_IO_BASE + SMBHSTSTAT);
 	}
-	while((byte &1) == 1);
-	while( (byte & ~1) == 0) {
+	while ((byte & 1) == 1);
+	while ((byte & ~1) == 0) {
 		byte = inb(SMBUS_IO_BASE + SMBHSTSTAT);
 	}
 }
@@ -71,16 +79,18 @@
 	/* set the command/address... */
 	outb(address & 0xFF, SMBUS_IO_BASE + SMBHSTCMD);
 	/* set up for a byte data read */
-	outb((inb(SMBUS_IO_BASE + SMBHSTCTL) & 0xE3) | (0x2 << 2), SMBUS_IO_BASE + SMBHSTCTL);
+	outb((inb(SMBUS_IO_BASE + SMBHSTCTL) & 0xE3) | (0x2 << 2),
+	     SMBUS_IO_BASE + SMBHSTCTL);
 
 	/* clear any lingering errors, so the transaction will run */
 	outb(inb(SMBUS_IO_BASE + SMBHSTSTAT), SMBUS_IO_BASE + SMBHSTSTAT);
 
-	/* clear the data byte...*/
+	/* clear the data byte... */
 	outb(0, SMBUS_IO_BASE + SMBHSTDAT0);
 
 	/* start the command */
-	outb((inb(SMBUS_IO_BASE + SMBHSTCTL) | 0x40), SMBUS_IO_BASE + SMBHSTCTL);
+	outb((inb(SMBUS_IO_BASE + SMBHSTCTL) | 0x40),
+	     SMBUS_IO_BASE + SMBHSTCTL);
 
 	/* poll for transaction completion */
 	smbus_wait_until_done();

Modified: trunk/src/southbridge/intel/i82801dx/i82801dx_tco_timer.c
==============================================================================
--- trunk/src/southbridge/intel/i82801dx/i82801dx_tco_timer.c	Sat Mar 13 23:07:15 2010	(r5206)
+++ trunk/src/southbridge/intel/i82801dx/i82801dx_tco_timer.c	Sun Mar 14 18:01:08 2010	(r5207)
@@ -3,9 +3,10 @@
  *
  * Copyright (C) 2008 Joseph Smith <joe at settoplinux.org>
  *
- * This program is free software; you can redistribute it and/or modify
- * it under the terms of the GNU General Public License version 2 as
- * published by the Free Software Foundation.
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License as
+ * published by the Free Software Foundation; version 2 of
+ * the License.
  *
  * This program is distributed in the hope that it will be useful,
  * but WITHOUT ANY WARRANTY; without even the implied warranty of
@@ -14,8 +15,8 @@
  *
  * 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
- *
+ * Foundation, Inc., 51 Franklin St, Fifth Floor, Boston,
+ * MA 02110-1301 USA
  */
 
 static void i82801dx_halt_tco_timer(void)
@@ -33,5 +34,6 @@
 	pci_write_config8(dev, ACPI_CNTL, 0x10);
 
 	/* Halt the TCO timer, preventing SMI and automatic reboot */
-	outw(inw(PMBASE_ADDR + TCOBASE + TCO1_CNT) | (1 << 11), PMBASE_ADDR + TCOBASE + TCO1_CNT);
+	outw(inw(PMBASE_ADDR + TCOBASE + TCO1_CNT) | (1 << 11),
+	     PMBASE_ADDR + TCOBASE + TCO1_CNT);
 }

Modified: trunk/src/southbridge/intel/i82801dx/i82801dx_usb.c
==============================================================================
--- trunk/src/southbridge/intel/i82801dx/i82801dx_usb.c	Sat Mar 13 23:07:15 2010	(r5206)
+++ trunk/src/southbridge/intel/i82801dx/i82801dx_usb.c	Sun Mar 14 18:01:08 2010	(r5207)
@@ -1,3 +1,24 @@
+/*
+ * This file is part of the coreboot project.
+ *
+ * Copyright (C) 2004 Ronald G. Minnich
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License as
+ * published by the Free Software Foundation; version 2 of
+ * the License.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 51 Franklin St, Fifth Floor, Boston,
+ * MA 02110-1301 USA
+ */
+
 #include <console/console.h>
 #include <device/device.h>
 #include <device/pci.h>
@@ -7,43 +28,41 @@
 
 static void usb_init(struct device *dev)
 {
-
-
-#if 0
-	uint32_t cmd;
+	u32 cmd;
 	printk_debug("USB: Setting up controller.. ");
 	cmd = pci_read_config32(dev, PCI_COMMAND);
-	pci_write_config32(dev, PCI_COMMAND, 
-		cmd | PCI_COMMAND_IO | PCI_COMMAND_MEMORY | 
-		PCI_COMMAND_MASTER | PCI_COMMAND_INVALIDATE);
-
-
+	pci_write_config32(dev, PCI_COMMAND,
+			   cmd | PCI_COMMAND_IO | PCI_COMMAND_MEMORY |
+			   PCI_COMMAND_MASTER | PCI_COMMAND_INVALIDATE);
 	printk_debug("done.\n");
-#endif
-
 }
 
-static struct device_operations usb_ops  = {
-	.read_resources   = pci_dev_read_resources,
-	.set_resources    = pci_dev_set_resources,
+static struct device_operations usb_ops = {
+	.read_resources = pci_dev_read_resources,
+	.set_resources = pci_dev_set_resources,
 	.enable_resources = pci_dev_enable_resources,
-	.init             = usb_init,
-	.scan_bus         = 0,
-	.enable           = i82801dx_enable,
+	.init = usb_init,
+	.scan_bus = 0,
+	.enable = i82801dx_enable,
 };
 
+/* 82801DB/DBL/DBM USB1 */
 static const struct pci_driver usb_driver_1 __pci_driver = {
-	.ops    = &usb_ops,
+	.ops = &usb_ops,
 	.vendor = PCI_VENDOR_ID_INTEL,
-	.device = PCI_DEVICE_ID_INTEL_82801DBM_USB1,
+	.device = PCI_DEVICE_ID_INTEL_82801DB_USB1,
 };
+
+/* 82801DB/DBL/DBM USB2 */
 static const struct pci_driver usb_driver_2 __pci_driver = {
-        .ops    = &usb_ops,
-        .vendor = PCI_VENDOR_ID_INTEL,
-	.device = PCI_DEVICE_ID_INTEL_82801DBM_USB2,
+	.ops = &usb_ops,
+	.vendor = PCI_VENDOR_ID_INTEL,
+	.device = PCI_DEVICE_ID_INTEL_82801DB_USB2,
 };
+
+/* 82801DB/DBL/DBM USB3 */
 static const struct pci_driver usb_driver_3 __pci_driver = {
-        .ops    = &usb_ops,
-        .vendor = PCI_VENDOR_ID_INTEL,
-	.device = PCI_DEVICE_ID_INTEL_82801DBM_USB3,
+	.ops = &usb_ops,
+	.vendor = PCI_VENDOR_ID_INTEL,
+	.device = PCI_DEVICE_ID_INTEL_82801DB_USB3,
 };

Modified: trunk/src/southbridge/intel/i82801dx/i82801dx_usb2.c
==============================================================================
--- trunk/src/southbridge/intel/i82801dx/i82801dx_usb2.c	Sat Mar 13 23:07:15 2010	(r5206)
+++ trunk/src/southbridge/intel/i82801dx/i82801dx_usb2.c	Sun Mar 14 18:01:08 2010	(r5207)
@@ -1,4 +1,23 @@
-//2003 Copywright Tyan
+/*
+ * This file is part of the coreboot project.
+ *
+ * Copyright (C) 2003 Tyan
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License as
+ * published by the Free Software Foundation; version 2 of
+ * the License.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 51 Franklin St, Fifth Floor, Boston,
+ * MA 02110-1301 USA
+ */
 
 #include <console/console.h>
 #include <device/device.h>
@@ -9,32 +28,27 @@
 
 static void usb2_init(struct device *dev)
 {
-
-
-#if 0  
-  uint32_t cmd;
+	u32 cmd;
 	printk_debug("USB: Setting up controller.. ");
 	cmd = pci_read_config32(dev, PCI_COMMAND);
-	pci_write_config32(dev, PCI_COMMAND, 
-		cmd | PCI_COMMAND_IO | PCI_COMMAND_MEMORY | 
-		PCI_COMMAND_MASTER | PCI_COMMAND_INVALIDATE);
-
-
+	pci_write_config32(dev, PCI_COMMAND,
+			   cmd | PCI_COMMAND_IO | PCI_COMMAND_MEMORY |
+			   PCI_COMMAND_MASTER | PCI_COMMAND_INVALIDATE);
 	printk_debug("done.\n");
-#endif
 }
 
-static struct device_operations usb2_ops  = {
-	.read_resources   = pci_dev_read_resources,
-	.set_resources    = pci_dev_set_resources,
+static struct device_operations usb2_ops = {
+	.read_resources = pci_dev_read_resources,
+	.set_resources = pci_dev_set_resources,
 	.enable_resources = pci_dev_enable_resources,
-	.init             = usb2_init,
-	.scan_bus         = 0,
-	.enable           = i82801dx_enable,
+	.init = usb2_init,
+	.scan_bus = 0,
+	.enable = i82801dx_enable,
 };
 
+/* 82801DB/DBM USB 2.0 */
 static const struct pci_driver usb2_driver __pci_driver = {
-	.ops    = &usb2_ops,
+	.ops = &usb2_ops,
 	.vendor = PCI_VENDOR_ID_INTEL,
-	.device = PCI_DEVICE_ID_INTEL_82801DBM_EHCI,
+	.device = PCI_DEVICE_ID_INTEL_82801DB_EHCI,
 };



From patrick at georgi-clan.de  Sun Mar 14 21:47:26 2010
From: patrick at georgi-clan.de (Patrick Georgi)
Date: Sun, 14 Mar 2010 21:47:26 +0100
Subject: [coreboot] [PATCH]Add scan-build support to coreboot-v4
Message-ID: <4B9D4B5E.9030209@georgi-clan.de>

Hi,

attached patch adds scan-build support to coreboot-v4.
It's configurable using Kconfig and defaults to off.

If set, it expects scan-build to be around and runs it.
The target directory for the scan-build report is configurable. If not
set, the default (/tmp/scan-build-$date-$number) is used.

Also, abuild is adapted to make use of the feature when running with the
-sb flag.

While adding it, I discovered an issue in the build system that I worked
around in this patch, and will fix in a future patch:
$(obj)/$path/$file.c -> $(obj)/$path/$file.o rules rely on implicit
default rules in make. For some reasons, these are missing when make is
invoked by make.

There should also be some path normalization for object file paths
(using $(abspath)), so the option_table.c rule hack can go.

Maybe it's a good idea to avoid reading in all Makefile.incs in the
outer make in a scan-build based build, but it's probably not worth the
trouble (it's harder to keep make clean and the likes working with such
an optimization)


Signed-off-by: Patrick Georgi <patrick.georgi at coresystems.de>
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: 20100314-1-scanbuild-for-v4
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20100314/31fabbb8/attachment.ksh>

From stepan at coresystems.de  Sun Mar 14 22:05:32 2010
From: stepan at coresystems.de (Stefan Reinauer)
Date: Sun, 14 Mar 2010 22:05:32 +0100
Subject: [coreboot] [PATCH]Add scan-build support to coreboot-v4
In-Reply-To: <4B9D4B5E.9030209@georgi-clan.de>
References: <4B9D4B5E.9030209@georgi-clan.de>
Message-ID: <4B9D4F9C.3060203@coresystems.de>

On 3/14/10 9:47 PM, Patrick Georgi wrote:
> Hi,
>
> attached patch adds scan-build support to coreboot-v4.
> It's configurable using Kconfig and defaults to off.
>
> If set, it expects scan-build to be around and runs it.
> The target directory for the scan-build report is configurable. If not
> set, the default (/tmp/scan-build-$date-$number) is used.
>
> Also, abuild is adapted to make use of the feature when running with the
> -sb flag.
>
> While adding it, I discovered an issue in the build system that I worked
> around in this patch, and will fix in a future patch:
> $(obj)/$path/$file.c -> $(obj)/$path/$file.o rules rely on implicit
> default rules in make. For some reasons, these are missing when make is
> invoked by make.
>
> There should also be some path normalization for object file paths
> (using $(abspath)), so the option_table.c rule hack can go.
>
> Maybe it's a good idea to avoid reading in all Makefile.incs in the
> outer make in a scan-build based build, but it's probably not worth the
> trouble (it's harder to keep make clean and the likes working with such
> an optimization)
>
>
> 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 svn at coreboot.org  Sun Mar 14 22:25:03 2010
From: svn at coreboot.org (repository service)
Date: Sun, 14 Mar 2010 22:25:03 +0100
Subject: [coreboot] [commit] r5208 - in trunk: . src src/arch/i386
	src/cpu/x86/smm util/abuild
Message-ID: <E1NqvJ1-0002UB-S5@ra.coresystems.de>

Author: oxygene
Date: Sun Mar 14 22:25:03 2010
New Revision: 5208
URL: http://tracker.coreboot.org/trac/coreboot/changeset/5208

Log:
Add scan-build support to the build system.
When configured in Kconfig, just running "make"
calls scan-build as appropriate (however, it does not
check for the presence of scan-build)

The target directory for the scan-build report is configurable
and defaults to the scan-build default of /tmp/scan-build-$date-$num

abuild is adapted to properly run scanbuild when ran
with the -sb option.

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

Modified:
   trunk/   (props changed)
   trunk/Makefile
   trunk/src/Kconfig
   trunk/src/arch/i386/Makefile.inc
   trunk/src/cpu/x86/smm/Makefile.inc
   trunk/util/abuild/abuild

Modified: trunk/Makefile
==============================================================================
--- trunk/Makefile	Sun Mar 14 18:01:08 2010	(r5207)
+++ trunk/Makefile	Sun Mar 14 22:25:03 2010	(r5208)
@@ -19,8 +19,16 @@
 ## Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA  02110-1301 USA
 ##
 
+ifeq ($(INNER_SCANBUILD),y)
+CC_real:=$(CC)
+endif
 $(if $(wildcard .xcompile),,$(eval $(shell bash util/xcompile/xcompile > .xcompile)))
 include .xcompile
+ifeq ($(INNER_SCANBUILD),y)
+CC:=$(CC_real)
+HOSTCC:=$(CC_real) --hostcc
+HOSTCXX:=$(CC_real) --hostcxx
+endif
 
 export top := $(PWD)
 export src := $(top)/src
@@ -90,7 +98,25 @@
 # The primary target needs to be here before we include the
 # other files
 
+ifeq ($(INNER_SCANBUILD),y)
+CONFIG_SCANBUILD_ENABLE:=
+endif
+
+ifeq ($(CONFIG_SCANBUILD_ENABLE),y)
+ifneq ($(CONFIG_SCANBUILD_REPORT_LOCATION),)
+CONFIG_SCANBUILD_REPORT_LOCATION:=-o $(CONFIG_SCANBUILD_REPORT_LOCATION)
+endif
+all:
+	echo '#!/bin/sh' > .ccwrap
+	echo 'CC="$(CC)"' >> .ccwrap
+	echo 'if [ "$$1" = "--hostcc" ]; then shift; CC="$(HOSTCC)"; fi' >> .ccwrap
+	echo 'if [ "$$1" = "--hostcxx" ]; then shift; CC="$(HOSTCXX)"; fi' >> .ccwrap
+	echo 'eval $$CC $$*' >> .ccwrap
+	chmod +x .ccwrap
+	scan-build $(CONFIG_SCANBUILD_REPORT_LOCATION) -analyze-headers --use-cc=$(top)/.ccwrap --use-c++=$(top)/.ccwrap $(MAKE) INNER_SCANBUILD=y
+else
 all: coreboot
+endif
 
 
 #######################################################################
@@ -110,7 +136,12 @@
 	(cd $(obj)/mainboard/$(MAINBOARDDIR) ; PYTHONPATH=$(top)/util/sconfig export PYTHONPATH; python config.py  $(MAINBOARDDIR) $(top) $(obj)/mainboard/$(MAINBOARDDIR))
 
 $(obj)/mainboard/$(MAINBOARDDIR)/static.o: $(obj)/mainboard/$(MAINBOARDDIR)/static.c
-#
+	@printf "    CC         $(subst $(obj)/,,$(@))\n"
+	$(CC) $(CFLAGS) -c -o $@ $<
+
+$(obj)/arch/i386/../../option_table.o: $(obj)/arch/i386/../../option_table.c
+	@printf "    CC         $(subst $(obj)/,,$(@))\n"
+	$(CC) $(CFLAGS) -c -o $@ $<
 
 objs:=$(obj)/mainboard/$(MAINBOARDDIR)/static.o
 initobjs:=
@@ -325,7 +356,7 @@
 	$(MAKE) -C util/sconfig clean
 
 clean: clean-for-update
-	rm -f $(obj)/coreboot*
+	rm -f $(obj)/coreboot* .ccwrap
 
 distclean: clean
 	rm -rf $(obj)

Modified: trunk/src/Kconfig
==============================================================================
--- trunk/src/Kconfig	Sun Mar 14 18:01:08 2010	(r5207)
+++ trunk/src/Kconfig	Sun Mar 14 22:25:03 2010	(r5208)
@@ -46,6 +46,20 @@
 	  Select the prefix to all files put into the image. It's "fallback"
 	  by default, "normal" is a common alternative.
 
+config SCANBUILD_ENABLE
+	bool "build with scan-build for static analysis"
+	default n
+	help
+	  Changes the build process to scan-build is used.
+	  Requires scan-build in path.
+
+config SCANBUILD_REPORT_LOCATION
+	string "directory to put scan-build report in"
+	default ""
+	depends on SCANBUILD_ENABLE
+	help
+	  Where the scan-build report should be stored
+
 endmenu
 
 source src/mainboard/Kconfig

Modified: trunk/src/arch/i386/Makefile.inc
==============================================================================
--- trunk/src/arch/i386/Makefile.inc	Sun Mar 14 18:01:08 2010	(r5207)
+++ trunk/src/arch/i386/Makefile.inc	Sun Mar 14 22:25:03 2010	(r5208)
@@ -60,7 +60,7 @@
 
 $(obj)/coreboot_ram.o: $(obj)/arch/i386/lib/c_start.o $(drivers) $(obj)/coreboot.a $(LIBGCC_FILE_NAME)
 	@printf "    CC         $(subst $(obj)/,,$(@))\n"
-	$(CC) -nostdlib -r -o $@ $(obj)/arch/i386/lib/c_start.o $(drivers) -Wl,-\( $(obj)/coreboot.a $(LIBGCC_FILE_NAME) -Wl,-\)
+	$(CC) -nostdlib -r -o $@ $(obj)/arch/i386/lib/c_start.o $(drivers) -Wl,--start-group $(obj)/coreboot.a $(LIBGCC_FILE_NAME) -Wl,--end-group
 
 $(obj)/coreboot.a: $(objs)
 	@printf "    AR         $(subst $(obj)/,,$(@))\n"

Modified: trunk/src/cpu/x86/smm/Makefile.inc
==============================================================================
--- trunk/src/cpu/x86/smm/Makefile.inc	Sun Mar 14 18:01:08 2010	(r5207)
+++ trunk/src/cpu/x86/smm/Makefile.inc	Sun Mar 14 22:25:03 2010	(r5208)
@@ -38,5 +38,9 @@
 $(obj)/cpu/x86/smm/smm_bin.c: $(obj)/cpu/x86/smm/smm
 	(echo 'unsigned char smm[] = {'; od -vtx1 $(obj)/cpu/x86/smm/smm | sed -e 's,^[0-9]* *,,' -e 's:[0-9a-f][0-9a-f] :0x&,:g' -e 's:[0-9a-f][0-9a-f]$$:0x&,:'; echo '}; unsigned int smm_len = '; wc -c $(obj)/cpu/x86/smm/smm |awk '{print $$1;}' ; echo ';')  > $@
 
+$(obj)/cpu/x86/smm/smm_bin.o: $(obj)/cpu/x86/smm/smm_bin.c
+	@printf "    CC         $(subst $(obj)/,,$(@))\n"
+	$(CC) $(CFLAGS) -c -o $@ $<
+
 endif
 

Modified: trunk/util/abuild/abuild
==============================================================================
--- trunk/util/abuild/abuild	Sun Mar 14 18:01:08 2010	(r5207)
+++ trunk/util/abuild/abuild	Sun Mar 14 22:25:03 2010	(r5208)
@@ -173,6 +173,12 @@
 			echo "CONFIG_DEFAULT_CONSOLE_LOGLEVEL_$loglevel=y" >> .config
 			echo "CONFIG_DEFAULT_CONSOLE_LOGLEVEL=$loglevel" >> .config
 		fi
+
+		if [ "$scanbuild" = "true" ]; then
+			printf "(scan-build enabled) "
+			echo "CONFIG_SCANBUILD_ENABLE=y" >> .config
+			echo "CONFIG_SCANBUILD_REPORT_LOCATION=\"$TARGET/scan-build-results-tmp\"" >> .config
+		fi
 	fi
 
 	yes "" | $MAKE oldconfig obj=${build_dir} > ${build_dir}/config.log
@@ -364,21 +370,6 @@
 		CC="$CC -fno-stack-protector"
 	fi
 
-	if  [ "$scanbuild" = "true" ]; then
-		ccwrap=`mktemp`
-		mkdir -p $TARGET/${VENDOR}_${MAINBOARD}
-		mkdir -p $TARGET/scan-build-results-tmp
-		mv $ccwrap $TARGET/${VENDOR}_${MAINBOARD}
-		ccwrap=$TARGET/${VENDOR}_${MAINBOARD}/`basename $ccwrap`
-		echo '#!/bin/sh' > $ccwrap
-		echo $CC' "$@"' >> $ccwrap
-		chmod +x $ccwrap
-		origMAKE=$MAKE
-		MAKE="scan-build --use-cc=$ccwrap -o $TARGET/scan-build-results-tmp -analyze-headers $MAKE GCC=$ccwrap"
-		CC="\$(CC)"
-		HOSTCC="CCC_CC=$HOSTCC \$(CC)"
-	fi
-
 	built_successfully $VENDOR $MAINBOARD && \
 	{
 		printf " ( mainboard/$VENDOR/$MAINBOARD previously ok )\n\n"



From stepan at coresystems.de  Sun Mar 14 22:26:19 2010
From: stepan at coresystems.de (Stefan Reinauer)
Date: Sun, 14 Mar 2010 22:26:19 +0100
Subject: [coreboot] [PATCH] (not really) move util/x86emu out of util
Message-ID: <4B9D547B.9060804@coresystems.de>

Hi,

it was reason for workaround rules already, and it's somewhat ugly:
util/x86emu is the only part of coreboot that is linked into coreboot
itself that lives in util/.
It's not a utility and it does not really belong where it lives.

Thus, I suggest moving it to src/

---> svn mv util/x86emu src/devices/oprom

(plus necessary Makefile/Kconfig/#include changes to get it building again).

Signed-off-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 rminnich at gmail.com  Sun Mar 14 22:27:54 2010
From: rminnich at gmail.com (ron minnich)
Date: Sun, 14 Mar 2010 13:27:54 -0800
Subject: [coreboot] [PATCH] (not really) move util/x86emu out of util
In-Reply-To: <4B9D547B.9060804@coresystems.de>
References: <4B9D547B.9060804@coresystems.de>
Message-ID: <13426df11003141427g3485654fr60b1e6c8d4afef1c@mail.gmail.com>

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



From svn at coreboot.org  Sun Mar 14 22:31:07 2010
From: svn at coreboot.org (repository service)
Date: Sun, 14 Mar 2010 22:31:07 +0100
Subject: [coreboot] [commit] r5209 - trunk/src
Message-ID: <E1NqvOt-0006yb-DS@ra.coresystems.de>

Author: oxygene
Date: Sun Mar 14 22:31:05 2010
New Revision: 5209
URL: http://tracker.coreboot.org/trac/coreboot/changeset/5209

Log:
Move deprecated Kconfig options to their own file,
so it's clear that they should be gone.
More can (and should) be added, but this is a start.

Of course, eliminating the uses of the flags (and then
the flags themselves) that are in Kconfig.deprecated_options
is a noble task for the future :-)

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

Added:
   trunk/src/Kconfig.deprecated_options
Modified:
   trunk/src/Kconfig

Modified: trunk/src/Kconfig
==============================================================================
--- trunk/src/Kconfig	Sun Mar 14 22:25:03 2010	(r5208)
+++ trunk/src/Kconfig	Sun Mar 14 22:31:05 2010	(r5209)
@@ -283,28 +283,6 @@
 	  This variable specifies whether a given board has a hard_reset
 	  function, no matter if it's provided by board code or chipset code.
 
-config BOARD_HAS_HARD_RESET
-	bool
-	default n
-	help
-	  This variable specifies whether a given board has a reset.c
-	  file containing a hard_reset() function.
-
-config BOARD_HAS_FADT
-	bool
-	default n
-	help
-	  This variable specifies whether a given board has a board-local
-	  FADT in fadt.c. Long-term, those should be moved to appropriate
-	  chipset components (eg. southbridge)
-
-config HAVE_BUS_CONFIG
-	bool
-	default n
-	help
-	  This variable specifies whether a given board has a get_bus_conf.c
-	  file containing bus configuration data.
-
 config HAVE_INIT_TIMER
 	bool
 	default n if UDELAY_IO
@@ -841,3 +819,5 @@
 config ID_SECTION_OFFSET
 	hex
 	default 0x10
+
+source src/Kconfig.deprecated_options

Added: trunk/src/Kconfig.deprecated_options
==============================================================================
--- /dev/null	00:00:00 1970	(empty, because file is newly added)
+++ trunk/src/Kconfig.deprecated_options	Sun Mar 14 22:31:05 2010	(r5209)
@@ -0,0 +1,33 @@
+# Options in this file are meant to be deprecated. Avoid their use
+# if possible, and if you find the time, or touch the general area
+# for other purposes, please consider removing their uses.
+
+# It might be possible to consolidate hard_reset() to southbridges,
+# given that it (usually) uses its registers.
+# The long term goal would be to eliminate hard_reset from boards.
+config BOARD_HAS_HARD_RESET
+        bool
+        default n
+        help
+          This variable specifies whether a given board has a reset.c
+          file containing a hard_reset() function.
+
+# It might be possible to consolidate FADTs to southbridges. This would
+# improve code reuse in the tree.
+config BOARD_HAS_FADT
+        bool
+        default n
+        help
+          This variable specifies whether a given board has a board-local
+          FADT in fadt.c. Long-term, those should be moved to appropriate
+          chipset components (eg. southbridge)
+
+# There ought to be a better place to put data than code. Also, make this
+# (or a similar) framework more universally usable, so all boards benefit
+# from sharing data between the various tables.
+config HAVE_BUS_CONFIG
+        bool
+        default n
+	help
+	  This variable specifies whether a given board has a get_bus_conf.c
+	  file containing information about bus routing.



From peter at stuge.se  Sun Mar 14 22:32:54 2010
From: peter at stuge.se (Peter Stuge)
Date: Sun, 14 Mar 2010 22:32:54 +0100
Subject: [coreboot] [PATCH] (not really) move util/x86emu out of util
In-Reply-To: <4B9D547B.9060804@coresystems.de>
References: <4B9D547B.9060804@coresystems.de>
Message-ID: <20100314213254.11826.qmail@stuge.se>

Stefan Reinauer wrote:
> ---> svn mv util/x86emu src/devices/oprom
> 
> (plus necessary Makefile/Kconfig/#include changes to get it building again).
> 
> Signed-off-by: Stefan Reinauer <stepan at coresystems.de>

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



From svn at coreboot.org  Sun Mar 14 23:20:57 2010
From: svn at coreboot.org (repository service)
Date: Sun, 14 Mar 2010 23:20:57 +0100
Subject: [coreboot] [commit] r5210 - trunk/util/romcc
Message-ID: <E1NqwB7-0006gI-Qw@ra.coresystems.de>

Author: oxygene
Date: Sun Mar 14 23:20:57 2010
New Revision: 5210
URL: http://tracker.coreboot.org/trac/coreboot/changeset/5210

Log:
Fix segfault of romcc when complex assignment operators
were applied to non-trivial LHSs, eg.  c[4] |= 1;

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

Modified:
   trunk/util/romcc/romcc.c

Modified: trunk/util/romcc/romcc.c
==============================================================================
--- trunk/util/romcc/romcc.c	Sun Mar 14 22:31:05 2010	(r5209)
+++ trunk/util/romcc/romcc.c	Sun Mar 14 23:20:57 2010	(r5210)
@@ -1896,12 +1896,16 @@
 		return;
 	if (!user)
 		return;
-	ptr = &used->use;
-	while(*ptr) {
-		if ((*ptr)->member == user) {
-			return;
+	if (used->use == (void*)-1)
+		used->use = 0;
+	if (used->use) {
+		ptr = &used->use;
+		while(*ptr) {
+			if ((*ptr)->member == user) {
+				return;
+			}
+			ptr = &(*ptr)->next;
 		}
-		ptr = &(*ptr)->next;
 	}
 	/* Append new to the head of the list, 
 	 * copy_func and rename_block_variables
@@ -11599,19 +11603,19 @@
 		}
 		def = write_expr(state, left,
 			triple(state, op, left->type, 
-				read_expr(state, left), right));
+				read_expr(state, copy_triple(state, left)), right));
 		break;
 	case TOK_PLUSEQ:
 		lvalue(state, left);
 		eat(state, TOK_PLUSEQ);
 		def = write_expr(state, left,
-			mk_add_expr(state, left, assignment_expr(state)));
+			mk_add_expr(state, copy_triple(state, left), assignment_expr(state)));
 		break;
 	case TOK_MINUSEQ:
 		lvalue(state, left);
 		eat(state, TOK_MINUSEQ);
 		def = write_expr(state, left,
-			mk_sub_expr(state, left, assignment_expr(state)));
+			mk_sub_expr(state, copy_triple(state, left), assignment_expr(state)));
 		break;
 	case TOK_SLEQ:
 	case TOK_SREQ:
@@ -11635,7 +11639,7 @@
 		}
 		def = write_expr(state, left,
 			triple(state, op, left->type, 
-				read_expr(state, left), right));
+				read_expr(state, copy_triple(state,left)), right));
 		break;
 	}
 	return def;



From info at coresystems.de  Sun Mar 14 23:33:20 2010
From: info at coresystems.de (coreboot information)
Date: Sun, 14 Mar 2010 23:33:20 +0100
Subject: [coreboot] build service results for r5210
Message-ID: <E1NqwN6-00012O-Gg@ra.coresystems.de>

Dear coreboot readers!

This is the automatic build system of coreboot.

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

Change Log:
Fix segfault of romcc when complex assignment operators
were applied to non-trivial LHSs, eg.  c[4] |= 1;

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


Build Log:
Compilation of a-trend:atc-6220 has been broken
See the error log at http://qa.coreboot.org/log_buildbrd.php?revision=5210&device=atc-6220&vendor=a-trend&num=2
Compilation of a-trend:atc-6240 has been broken
See the error log at http://qa.coreboot.org/log_buildbrd.php?revision=5210&device=atc-6240&vendor=a-trend&num=2
Compilation of abit:be6-ii_v2_0 has been broken
See the error log at http://qa.coreboot.org/log_buildbrd.php?revision=5210&device=be6-ii_v2_0&vendor=abit&num=2
Compilation of advantech:pcm-5820 has been broken
See the error log at http://qa.coreboot.org/log_buildbrd.php?revision=5210&device=pcm-5820&vendor=advantech&num=2
Compilation of amd:rumba has been broken
See the error log at http://qa.coreboot.org/log_buildbrd.php?revision=5210&device=rumba&vendor=amd&num=2
Compilation of amd:serengeti_cheetah_fam10 has been broken
See the error log at http://qa.coreboot.org/log_buildbrd.php?revision=5210&device=serengeti_cheetah_fam10&vendor=amd&num=2
Compilation of asi:mb_5blgp has been broken
See the error log at http://qa.coreboot.org/log_buildbrd.php?revision=5210&device=mb_5blgp&vendor=asi&num=2
Compilation of asi:mb_5blmp has been broken
See the error log at http://qa.coreboot.org/log_buildbrd.php?revision=5210&device=mb_5blmp&vendor=asi&num=2
Compilation of asus:mew-am has been broken
See the error log at http://qa.coreboot.org/log_buildbrd.php?revision=5210&device=mew-am&vendor=asus&num=2
Compilation of asus:mew-vm has been broken
See the error log at http://qa.coreboot.org/log_buildbrd.php?revision=5210&device=mew-vm&vendor=asus&num=2
Compilation of asus:p2b has been broken
See the error log at http://qa.coreboot.org/log_buildbrd.php?revision=5210&device=p2b&vendor=asus&num=2
Compilation of asus:p2b-d has been broken
See the error log at http://qa.coreboot.org/log_buildbrd.php?revision=5210&device=p2b-d&vendor=asus&num=2
Compilation of asus:p2b-ds has been broken
See the error log at http://qa.coreboot.org/log_buildbrd.php?revision=5210&device=p2b-ds&vendor=asus&num=2
Compilation of asus:p2b-f has been broken
See the error log at http://qa.coreboot.org/log_buildbrd.php?revision=5210&device=p2b-f&vendor=asus&num=2
Compilation of asus:p2b-ls has been broken
See the error log at http://qa.coreboot.org/log_buildbrd.php?revision=5210&device=p2b-ls&vendor=asus&num=2
Compilation of asus:p3b-f has been broken
See the error log at http://qa.coreboot.org/log_buildbrd.php?revision=5210&device=p3b-f&vendor=asus&num=2
Compilation of axus:tc320 has been broken
See the error log at http://qa.coreboot.org/log_buildbrd.php?revision=5210&device=tc320&vendor=axus&num=2
Compilation of azza:pt-6ibd has been broken
See the error log at http://qa.coreboot.org/log_buildbrd.php?revision=5210&device=pt-6ibd&vendor=azza&num=2
Compilation of bcom:winnet100 has been broken
See the error log at http://qa.coreboot.org/log_buildbrd.php?revision=5210&device=winnet100&vendor=bcom&num=2
Compilation of biostar:m6tba has been broken
See the error log at http://qa.coreboot.org/log_buildbrd.php?revision=5210&device=m6tba&vendor=biostar&num=2
Compilation of compaq:deskpro_en_sff_p600 has been broken
See the error log at http://qa.coreboot.org/log_buildbrd.php?revision=5210&device=deskpro_en_sff_p600&vendor=compaq&num=2
Compilation of dell:s1850 has been broken
See the error log at http://qa.coreboot.org/log_buildbrd.php?revision=5210&device=s1850&vendor=dell&num=2
Compilation of digitallogic:adl855pc has been broken
See the error log at http://qa.coreboot.org/log_buildbrd.php?revision=5210&device=adl855pc&vendor=digitallogic&num=2
Compilation of digitallogic:msm586seg has been broken
See the error log at http://qa.coreboot.org/log_buildbrd.php?revision=5210&device=msm586seg&vendor=digitallogic&num=2
Compilation of eaglelion:5bcm has been broken
See the error log at http://qa.coreboot.org/log_buildbrd.php?revision=5210&device=5bcm&vendor=eaglelion&num=2
Compilation of gigabyte:ga-6bxc has been broken
See the error log at http://qa.coreboot.org/log_buildbrd.php?revision=5210&device=ga-6bxc&vendor=gigabyte&num=2
Compilation of hp:e_vectra_p2706t has been broken
See the error log at http://qa.coreboot.org/log_buildbrd.php?revision=5210&device=e_vectra_p2706t&vendor=hp&num=2
Compilation of iei:juki-511p has been broken
See the error log at http://qa.coreboot.org/log_buildbrd.php?revision=5210&device=juki-511p&vendor=iei&num=2
Compilation of iei:nova4899r has been broken
See the error log at http://qa.coreboot.org/log_buildbrd.php?revision=5210&device=nova4899r&vendor=iei&num=2
Compilation of intel:jarrell has been broken
See the error log at http://qa.coreboot.org/log_buildbrd.php?revision=5210&device=jarrell&vendor=intel&num=2
Compilation of intel:mtarvon has been broken
See the error log at http://qa.coreboot.org/log_buildbrd.php?revision=5210&device=mtarvon&vendor=intel&num=2
Compilation of intel:truxton has been broken
See the error log at http://qa.coreboot.org/log_buildbrd.php?revision=5210&device=truxton&vendor=intel&num=2
Compilation of intel:xe7501devkit has been broken
See the error log at http://qa.coreboot.org/log_buildbrd.php?revision=5210&device=xe7501devkit&vendor=intel&num=2
Compilation of lippert:frontrunner has been broken
See the error log at http://qa.coreboot.org/log_buildbrd.php?revision=5210&device=frontrunner&vendor=lippert&num=2
Compilation of mitac:6513wu has been broken
See the error log at http://qa.coreboot.org/log_buildbrd.php?revision=5210&device=6513wu&vendor=mitac&num=2
Compilation of msi:ms6119 has been broken
See the error log at http://qa.coreboot.org/log_buildbrd.php?revision=5210&device=ms6119&vendor=msi&num=2
Compilation of msi:ms6147 has been broken
See the error log at http://qa.coreboot.org/log_buildbrd.php?revision=5210&device=ms6147&vendor=msi&num=2
Compilation of msi:ms6156 has been broken
See the error log at http://qa.coreboot.org/log_buildbrd.php?revision=5210&device=ms6156&vendor=msi&num=2
Compilation of msi:ms6178 has been broken
See the error log at http://qa.coreboot.org/log_buildbrd.php?revision=5210&device=ms6178&vendor=msi&num=2
Compilation of msi:ms9652_fam10 has been broken
See the error log at http://qa.coreboot.org/log_buildbrd.php?revision=5210&device=ms9652_fam10&vendor=msi&num=2
Compilation of nec:powermate2000 has been broken
See the error log at http://qa.coreboot.org/log_buildbrd.php?revision=5210&device=powermate2000&vendor=nec&num=2
Compilation of olpc:btest has been broken
See the error log at http://qa.coreboot.org/log_buildbrd.php?revision=5210&device=btest&vendor=olpc&num=2
Compilation of olpc:rev_a has been broken
See the error log at http://qa.coreboot.org/log_buildbrd.php?revision=5210&device=rev_a&vendor=olpc&num=2
Compilation of rca:rm4100 has been broken
See the error log at http://qa.coreboot.org/log_buildbrd.php?revision=5210&device=rm4100&vendor=rca&num=2
Compilation of soyo:sy-6ba-plus-iii has been broken
See the error log at http://qa.coreboot.org/log_buildbrd.php?revision=5210&device=sy-6ba-plus-iii&vendor=soyo&num=2
Compilation of supermicro:h8dmr_fam10 has been broken
See the error log at http://qa.coreboot.org/log_buildbrd.php?revision=5210&device=h8dmr_fam10&vendor=supermicro&num=2
Compilation of supermicro:h8qme_fam10 has been broken
See the error log at http://qa.coreboot.org/log_buildbrd.php?revision=5210&device=h8qme_fam10&vendor=supermicro&num=2
Compilation of supermicro:x6dai_g has been broken
See the error log at http://qa.coreboot.org/log_buildbrd.php?revision=5210&device=x6dai_g&vendor=supermicro&num=2
Compilation of supermicro:x6dhe_g has been broken
See the error log at http://qa.coreboot.org/log_buildbrd.php?revision=5210&device=x6dhe_g&vendor=supermicro&num=2
Compilation of supermicro:x6dhe_g2 has been broken
See the error log at http://qa.coreboot.org/log_buildbrd.php?revision=5210&device=x6dhe_g2&vendor=supermicro&num=2
Compilation of supermicro:x6dhr_ig has been broken
See the error log at http://qa.coreboot.org/log_buildbrd.php?revision=5210&device=x6dhr_ig&vendor=supermicro&num=2
Compilation of supermicro:x6dhr_ig2 has been broken
See the error log at http://qa.coreboot.org/log_buildbrd.php?revision=5210&device=x6dhr_ig2&vendor=supermicro&num=2
Compilation of technologic:ts5300 has been broken
See the error log at http://qa.coreboot.org/log_buildbrd.php?revision=5210&device=ts5300&vendor=technologic&num=2
Compilation of televideo:tc7020 has been broken
See the error log at http://qa.coreboot.org/log_buildbrd.php?revision=5210&device=tc7020&vendor=televideo&num=2
Compilation of thomson:ip1000 has been broken
See the error log at http://qa.coreboot.org/log_buildbrd.php?revision=5210&device=ip1000&vendor=thomson&num=2
Compilation of tyan:s1846 has been broken
See the error log at http://qa.coreboot.org/log_buildbrd.php?revision=5210&device=s1846&vendor=tyan&num=2
Compilation of tyan:s2912_fam10 has been broken
See the error log at http://qa.coreboot.org/log_buildbrd.php?revision=5210&device=s2912_fam10&vendor=tyan&num=2
Compilation of via:epia-cn has been broken
See the error log at http://qa.coreboot.org/log_buildbrd.php?revision=5210&device=epia-cn&vendor=via&num=2
Compilation of via:pc2500e has been broken
See the error log at http://qa.coreboot.org/log_buildbrd.php?revision=5210&device=pc2500e&vendor=via&num=2


If something broke during this checkin please be a pain 
in oxygene'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  Mon Mar 15 00:35:56 2010
From: stepan at coresystems.de (Stefan Reinauer)
Date: Mon, 15 Mar 2010 00:35:56 +0100
Subject: [coreboot] [PATCH] build.h generation
Message-ID: <4B9D72DC.8070701@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: build_h_fix.diff
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20100315/6838a1bd/attachment.ksh>

From stepan at coresystems.de  Mon Mar 15 01:11:03 2010
From: stepan at coresystems.de (Stefan Reinauer)
Date: Mon, 15 Mar 2010 01:11:03 +0100
Subject: [coreboot] [PATCH] coreboot and LLVM
Message-ID: <4B9D7B17.6040600@coresystems.de>

See patch... This patch allows me to compile coreboot with LLVM/clang.

To actually use LLVM/clang, I just hard coded it in xcompile for now:

Index: util/xcompile/xcompile
===================================================================
--- util/xcompile/xcompile (revision 5209)
+++ util/xcompile/xcompile (working copy)
@@ -87,7 +87,8 @@
cat << EOF
# elf${TWIDTH}-${TARCH} toolchain
AS:=${GCCPREFIX}as ${ASFLAGS}
-CC:=${GCCPREFIX}gcc ${CFLAGS}
+#CC:=${GCCPREFIX}gcc ${CFLAGS}
+CC:=clang -m32
CPP:=${GCCPREFIX}cpp
AR:=${GCCPREFIX}ar
LD:=${GCCPREFIX}ld ${LDFLAGS}


-- 
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: stdarg_on_gcc.diff
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20100315/1b6273f4/attachment.ksh>

From buurin at gmail.com  Mon Mar 15 03:32:09 2010
From: buurin at gmail.com (Keith Hui)
Date: Sun, 14 Mar 2010 22:32:09 -0400
Subject: [coreboot] Ouch: romcc "x[0] |= something" patch causes another
	crash
Message-ID: <b72cdb061003141932m6fca044eo72d5ba31b84ea72e@mail.gmail.com>

Hi all,

I regret to report that the romcc patch circulated earlier to fix the
segfault I reported, is now causing another segfault. This also seems to be
triggered by something in the 440BX code, as it didn't segfault when I
compile for any mainboards that isn't 440BX. As of now I don't know what
this new segfault is. I'll report back with more findings.

Thanks
Keith
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20100314/ff4855d3/attachment.html>

From stawel at gmail.com  Mon Mar 15 03:51:02 2010
From: stawel at gmail.com (=?ISO-8859-2?Q?Pawe=B3_Stawicki?=)
Date: Mon, 15 Mar 2010 03:51:02 +0100
Subject: [coreboot] coreboot on "acer aspire 1520"
In-Reply-To: <12ac91af1003051614s2a040e9mb4bafbdf51de229a@mail.gmail.com>
References: <12ac91af1003051614s2a040e9mb4bafbdf51de229a@mail.gmail.com>
Message-ID: <12ac91af1003141951s4c1675eap5562429a04bed002@mail.gmail.com>

Hi, again

I'm still trying run coreboot on my laptop.

Because it has no COM port  I'm
trying run the debug logs on the IRDA output.

I was able to run the logs (through IRDA) but
only when I don't turn off the laptop.
(I can only reset the laptop - and  so run coreboot)

Now I have no idea what to do.

I guess that something is not initialized,
what my original bios or linux has initialized

But I have turned off all Irda and serial port
support in bios an linux and it still works
(booting coreboot through reset)

can someone help ??


Regards
Pawe?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20100315/ab4c9401/attachment.html>

From rminnich at gmail.com  Mon Mar 15 03:29:50 2010
From: rminnich at gmail.com (ron minnich)
Date: Sun, 14 Mar 2010 18:29:50 -0800
Subject: [coreboot] [PATCH] coreboot and LLVM
In-Reply-To: <4B9D7B17.6040600@coresystems.de>
References: <4B9D7B17.6040600@coresystems.de>
Message-ID: <13426df11003141929y7a75b004u5256f0703d3ddec1@mail.gmail.com>

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



From rminnich at gmail.com  Mon Mar 15 03:28:17 2010
From: rminnich at gmail.com (ron minnich)
Date: Sun, 14 Mar 2010 18:28:17 -0800
Subject: [coreboot] [PATCH] build.h generation
In-Reply-To: <4B9D72DC.8070701@coresystems.de>
References: <4B9D72DC.8070701@coresystems.de>
Message-ID: <13426df11003141928y4df67707w4a0f71cc5595b812@mail.gmail.com>

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



From Zheng.Bao at amd.com  Mon Mar 15 06:30:23 2010
From: Zheng.Bao at amd.com (Bao, Zheng)
Date: Mon, 15 Mar 2010 13:30:23 +0800
Subject: [coreboot] [PATCH]: AMD RS780/SB700 support
Message-ID: <DD1CC71B621B004FA76856E5129D6B170388AA35@sbjgexmb1.amd.com>

Please see the comment and Signed-off-by line in each patch file.


Zheng
-------------- next part --------------
A non-text attachment was scrubbed...
Name: pci_ids_h_amd_rs780_sb700.patch
Type: application/octet-stream
Size: 2679 bytes
Desc: pci_ids_h_amd_rs780_sb700.patch
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20100315/edba6310/attachment.obj>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: amd_mahogany.patch
Type: application/octet-stream
Size: 149756 bytes
Desc: amd_mahogany.patch
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20100315/edba6310/attachment-0001.obj>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: amd_mahogany_fam10.patch
Type: application/octet-stream
Size: 163424 bytes
Desc: amd_mahogany_fam10.patch
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20100315/edba6310/attachment-0002.obj>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: amd_rs780.patch
Type: application/octet-stream
Size: 120651 bytes
Desc: amd_rs780.patch
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20100315/edba6310/attachment-0003.obj>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: amd_rs780_sb700_mahogany_mahogany_fam10_makefile_inc.patch
Type: application/octet-stream
Size: 1717 bytes
Desc: amd_rs780_sb700_mahogany_mahogany_fam10_makefile_inc.patch
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20100315/edba6310/attachment-0004.obj>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: amd_sb700.patch
Type: application/octet-stream
Size: 90752 bytes
Desc: amd_sb700.patch
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20100315/edba6310/attachment-0005.obj>

From Zheng.Bao at amd.com  Mon Mar 15 06:37:37 2010
From: Zheng.Bao at amd.com (Bao, Zheng)
Date: Mon, 15 Mar 2010 13:37:37 +0800
Subject: [coreboot] (no subject)
Message-ID: <DD1CC71B621B004FA76856E5129D6B170388AA3B@sbjgexmb1.amd.com>

Add an AM2R2 entry in to the src/arch/i386/Makefile.inc.
The board seems to be working even without this patch.

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

Index: src/arch/i386/Makefile.inc
===================================================================
--- src/arch/i386/Makefile.inc	(revision 5210)
+++ src/arch/i386/Makefile.inc	(working copy)
@@ -108,6 +108,9 @@
 ifeq ($(CONFIG_CPU_AMD_SOCKET_F_1207),y)
 crt0s += $(src)/cpu/amd/car/cache_as_ram.inc
 endif
+ifeq ($(CONFIG_CPU_AMD_SOCKET_AM2R2),y)
+crt0s += $(src)/cpu/amd/car/cache_as_ram.inc
+endif
 ifeq ($(CONFIG_CPU_AMD_SOCKET_AM2),y)
 crt0s += $(src)/cpu/amd/car/cache_as_ram.inc
 endif
-------------- next part --------------
A non-text attachment was scrubbed...
Name: makefile_inc_am2r2.patch
Type: application/octet-stream
Size: 600 bytes
Desc: makefile_inc_am2r2.patch
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20100315/d89bca58/attachment.obj>

From Zheng.Bao at amd.com  Mon Mar 15 06:39:02 2010
From: Zheng.Bao at amd.com (Bao, Zheng)
Date: Mon, 15 Mar 2010 13:39:02 +0800
Subject: [coreboot] [patch]: add an entry for AM2R2 in
	src/arc/i386/Makefile.inc
Message-ID: <DD1CC71B621B004FA76856E5129D6B170388AA3E@sbjgexmb1.amd.com>



Add an AM2R2 entry in to the src/arch/i386/Makefile.inc.
The board seems to be working even without this patch.

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

Index: src/arch/i386/Makefile.inc
===================================================================
--- src/arch/i386/Makefile.inc	(revision 5210)
+++ src/arch/i386/Makefile.inc	(working copy)
@@ -108,6 +108,9 @@
 ifeq ($(CONFIG_CPU_AMD_SOCKET_F_1207),y)
 crt0s += $(src)/cpu/amd/car/cache_as_ram.inc
 endif
+ifeq ($(CONFIG_CPU_AMD_SOCKET_AM2R2),y)
+crt0s += $(src)/cpu/amd/car/cache_as_ram.inc
+endif
 ifeq ($(CONFIG_CPU_AMD_SOCKET_AM2),y)
 crt0s += $(src)/cpu/amd/car/cache_as_ram.inc
 endif
-------------- next part --------------
A non-text attachment was scrubbed...
Name: makefile_inc_am2r2.patch
Type: application/octet-stream
Size: 600 bytes
Desc: makefile_inc_am2r2.patch
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20100315/30342e2b/attachment.obj>

From Zheng.Bao at amd.com  Mon Mar 15 06:41:24 2010
From: Zheng.Bao at amd.com (Bao, Zheng)
Date: Mon, 15 Mar 2010 13:41:24 +0800
Subject: [coreboot] workaround for mahogany_fam10. Not a signed-off-by
Message-ID: <DD1CC71B621B004FA76856E5129D6B170388AA40@sbjgexmb1.amd.com>

This is for the mahogany_fam10 I just sent. It is not a signed-off-by
patch. We need to work it out about this problem.


Index: src/northbridge/amd/amdht/h3finit.c
===================================================================
--- src/northbridge/amd/amdht/h3finit.c	(revision 4521)
+++ src/northbridge/amd/amdht/h3finit.c	(working copy)
@@ -1104,6 +1104,7 @@
 				AmdPCIRead(currentPtr, &temp);
 			} while (!IS_HT_SLAVE_CAPABILITY(temp));
 
+#if (CONFIG_HT_CHAIN_UNITID_BASE != 0)
 			AmdPCIReadBits(currentPtr, 25, 21, &unitIDcnt);
 			if ((unitIDcnt + currentBUID > 31) || ((secBus
== 0) && (unitIDcnt + currentBUID > 24)))
 			{
@@ -1145,7 +1146,7 @@
 				STOP_HERE;
 				break;
 			}
-
+#endif
 			AmdPCIReadBits(currentPtr, 26, 26, &temp);
 			pDat->PortList[pDat->TotalLinks*2+1].Link =
(u8)temp;
 			pDat->PortList[pDat->TotalLinks*2+1].Pointer =
currentPtr;
@@ -1156,6 +1157,11 @@
 			depth++;
 			pDat->TotalLinks++;
 			currentBUID += unitIDcnt;
+#if CONFIG_HT_CHAIN_UNITID_BASE == 0
+			STOP_HERE;
+			break;
+#endif
+
 		}
 		if (pDat->HtBlock->AMD_CB_EventNotify)
 		{
-------------- next part --------------
A non-text attachment was scrubbed...
Name: ht_chain_unitid_base.patch
Type: application/octet-stream
Size: 968 bytes
Desc: ht_chain_unitid_base.patch
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20100315/4c7490d7/attachment.obj>

From eswierk at aristanetworks.com  Mon Mar 15 07:40:36 2010
From: eswierk at aristanetworks.com (Ed Swierk)
Date: Sun, 14 Mar 2010 23:40:36 -0700
Subject: [coreboot] [PATCH]: AMD RS780/SB700 support
In-Reply-To: <DD1CC71B621B004FA76856E5129D6B170388AA35@sbjgexmb1.amd.com>
References: <DD1CC71B621B004FA76856E5129D6B170388AA35@sbjgexmb1.amd.com>
Message-ID: <9ae48b021003142340gf1140d7lbb47feada52eb0f1@mail.gmail.com>

On Sun, Mar 14, 2010 at 10:30 PM, Bao, Zheng <Zheng.Bao at amd.com> wrote:
> Please see the comment and Signed-off-by line in each patch file.

Thank you, AMD!

Getting code like this through all the technical, legal and business
hurdles and out the door requires herculean effort. Here's hoping it
helps AMD sell lots and lots of chips.

--Ed



From paulepanter at users.sourceforge.net  Mon Mar 15 09:37:39 2010
From: paulepanter at users.sourceforge.net (Paul Menzel)
Date: Mon, 15 Mar 2010 09:37:39 +0100
Subject: [coreboot] [PATCH]: AMD RS780/SB700 support
In-Reply-To: <9ae48b021003142340gf1140d7lbb47feada52eb0f1@mail.gmail.com>
References: <DD1CC71B621B004FA76856E5129D6B170388AA35@sbjgexmb1.amd.com>
	<9ae48b021003142340gf1140d7lbb47feada52eb0f1@mail.gmail.com>
Message-ID: <1268642259.3759.1.camel@mattotaupa>

Am Sonntag, den 14.03.2010, 23:40 -0700 schrieb Ed Swierk:
> On Sun, Mar 14, 2010 at 10:30 PM, Bao, Zheng <Zheng.Bao at amd.com> wrote:
> > Please see the comment and Signed-off-by line in each patch file.
> 
> Thank you, AMD!
> 
> Getting code like this through all the technical, legal and business
> hurdles and out the door requires herculean effort. Here's hoping it
> helps AMD sell lots and lots of chips.

I second this!


THANK YOU!

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

From patrick at georgi-clan.de  Mon Mar 15 10:41:39 2010
From: patrick at georgi-clan.de (Patrick Georgi)
Date: Mon, 15 Mar 2010 10:41:39 +0100
Subject: [coreboot] [PATCH] coreboot and LLVM
In-Reply-To: <4B9D7B17.6040600@coresystems.de>
References: <4B9D7B17.6040600@coresystems.de>
Message-ID: <4B9E00D3.6000407@georgi-clan.de>

Am 15.03.2010 01:11, schrieb Stefan Reinauer:
> See patch... This patch allows me to compile coreboot with LLVM/clang.
> 
> To actually use LLVM/clang, I just hard coded it in xcompile for now:
This makes it configurable. Please test.

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

From patrick at georgi-clan.de  Mon Mar 15 10:59:27 2010
From: patrick at georgi-clan.de (Patrick Georgi)
Date: Mon, 15 Mar 2010 10:59:27 +0100
Subject: [coreboot] Ouch: romcc "x[0] |= something" patch causes another
 crash
In-Reply-To: <b72cdb061003141932m6fca044eo72d5ba31b84ea72e@mail.gmail.com>
References: <b72cdb061003141932m6fca044eo72d5ba31b84ea72e@mail.gmail.com>
Message-ID: <4B9E04FF.9050308@georgi-clan.de>

Am 15.03.2010 03:32, schrieb Keith Hui:
> Hi all,
> 
> I regret to report that the romcc patch circulated earlier to fix the
> segfault I reported, is now causing another segfault. This also seems to
> be triggered by something in the 440BX code, as it didn't segfault when
> I compile for any mainboards that isn't 440BX. As of now I don't know
> what this new segfault is. I'll report back with more findings.
It seems the problem was that copy_triple() isn't supposed to be used on
flattened (and simple) nodes.
I built a simple test case that failed:
void main(void) {
        int c = 0;
        c |= 4;
}

With the attached patch, this testcase, your testcase, and a full abuild
run work.

Signed-off-by: Patrick Georgi <patrick.georgi at coresystems.de>
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: 20100315-2-romcc
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20100315/10d182db/attachment.ksh>

From svn at coreboot.org  Mon Mar 15 11:04:06 2010
From: svn at coreboot.org (repository service)
Date: Mon, 15 Mar 2010 11:04:06 +0100
Subject: [coreboot] [commit] r5211 - trunk/src/arch/i386
Message-ID: <E1Nr79a-0006B7-HW@ra.coresystems.de>

Author: oxygene
Date: Mon Mar 15 11:04:06 2010
New Revision: 5211
URL: https://tracker.coreboot.org/trac/coreboot/changeset/5211

Log:
Add an AM2R2 entry in to the src/arch/i386/Makefile.inc.

Signed-off-by: Zheng Bao <zheng.bao at amd.com>
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	Sun Mar 14 23:20:57 2010	(r5210)
+++ trunk/src/arch/i386/Makefile.inc	Mon Mar 15 11:04:06 2010	(r5211)
@@ -108,6 +108,9 @@
 ifeq ($(CONFIG_CPU_AMD_SOCKET_F_1207),y)
 crt0s += $(src)/cpu/amd/car/cache_as_ram.inc
 endif
+ifeq ($(CONFIG_CPU_AMD_SOCKET_AM2R2),y)
+crt0s += $(src)/cpu/amd/car/cache_as_ram.inc
+endif
 ifeq ($(CONFIG_CPU_AMD_SOCKET_AM2),y)
 crt0s += $(src)/cpu/amd/car/cache_as_ram.inc
 endif



From info at coresystems.de  Mon Mar 15 11:16:28 2010
From: info at coresystems.de (coreboot information)
Date: Mon, 15 Mar 2010 11:16:28 +0100
Subject: [coreboot] build service results for r5211
Message-ID: <E1Nr7LY-0008LX-Iw@ra.coresystems.de>

Dear coreboot readers!

This is the automatic build system of coreboot.

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

Change Log:
Add an AM2R2 entry in to the src/arch/i386/Makefile.inc.

Signed-off-by: Zheng Bao <zheng.bao at amd.com>
Acked-by: Patrick Georgi <patrick.georgi at coresystems.de>


Build Log:
Compilation of a-trend:atc-6220 is still broken
See the error log at http://qa.coreboot.org/log_buildbrd.php?revision=5211&device=atc-6220&vendor=a-trend&num=2
Compilation of a-trend:atc-6240 is still broken
See the error log at http://qa.coreboot.org/log_buildbrd.php?revision=5211&device=atc-6240&vendor=a-trend&num=2
Compilation of abit:be6-ii_v2_0 is still broken
See the error log at http://qa.coreboot.org/log_buildbrd.php?revision=5211&device=be6-ii_v2_0&vendor=abit&num=2
Compilation of advantech:pcm-5820 is still broken
See the error log at http://qa.coreboot.org/log_buildbrd.php?revision=5211&device=pcm-5820&vendor=advantech&num=2
Compilation of amd:rumba is still broken
See the error log at http://qa.coreboot.org/log_buildbrd.php?revision=5211&device=rumba&vendor=amd&num=2
Compilation of amd:serengeti_cheetah_fam10 is still broken
See the error log at http://qa.coreboot.org/log_buildbrd.php?revision=5211&device=serengeti_cheetah_fam10&vendor=amd&num=2
Compilation of asi:mb_5blgp is still broken
See the error log at http://qa.coreboot.org/log_buildbrd.php?revision=5211&device=mb_5blgp&vendor=asi&num=2
Compilation of asi:mb_5blmp is still broken
See the error log at http://qa.coreboot.org/log_buildbrd.php?revision=5211&device=mb_5blmp&vendor=asi&num=2
Compilation of asus:mew-am is still broken
See the error log at http://qa.coreboot.org/log_buildbrd.php?revision=5211&device=mew-am&vendor=asus&num=2
Compilation of asus:mew-vm is still broken
See the error log at http://qa.coreboot.org/log_buildbrd.php?revision=5211&device=mew-vm&vendor=asus&num=2
Compilation of asus:p2b is still broken
See the error log at http://qa.coreboot.org/log_buildbrd.php?revision=5211&device=p2b&vendor=asus&num=2
Compilation of asus:p2b-d is still broken
See the error log at http://qa.coreboot.org/log_buildbrd.php?revision=5211&device=p2b-d&vendor=asus&num=2
Compilation of asus:p2b-ds is still broken
See the error log at http://qa.coreboot.org/log_buildbrd.php?revision=5211&device=p2b-ds&vendor=asus&num=2
Compilation of asus:p2b-f is still broken
See the erro