From rminnich at gmail.com  Thu Jan  1 01:58:01 2009
From: rminnich at gmail.com (ron minnich)
Date: Wed, 31 Dec 2008 16:58:01 -0800
Subject: [coreboot] K8 patch for new v3 allocator
In-Reply-To: <2831fecf0812311351j243c9f98qa3524e67aa6ed3c@mail.gmail.com>
References: <2831fecf0812311351j243c9f98qa3524e67aa6ed3c@mail.gmail.com>
Message-ID: <13426df10812311658u49f1eb2du622e7d0280e03d79@mail.gmail.com>

On Wed, Dec 31, 2008 at 1:51 PM, Myles Watson <mylesgw at gmail.com> wrote:
> This patch makes serengeti work as well as it did before.  I'm interested in
> feedback.
>
> Signed-off-by: Myles Watson <mylesgw at gmail.com>
>

I've given it two passes and liked it each time.

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



From fengyuning1984 at gmail.com  Thu Jan  1 11:21:23 2009
From: fengyuning1984 at gmail.com (FENG Yu Ning)
Date: Thu, 1 Jan 2009 18:21:23 +0800
Subject: [coreboot] [RFC]flashrom: improve basic design
Message-ID: <a505dc9d0901010221m7b564228tbb5bf1f80818ed6a@mail.gmail.com>

There is a defect in basic design of flashrom. It leads to problems
some developers are facing or going to face. A partial solution is
proposed.

1. The Defect

struct flashchip {

        /* ... */

	int (*probe) (struct flashchip *flash);
	int (*erase) (struct flashchip *flash);
	int (*write) (struct flashchip *flash, uint8_t *buf);
	int (*read) (struct flashchip *flash, uint8_t *buf);

        /* ... */

};

The struct specifies drivers for operations. It is a good design if
the drivers deal with flash chips directly and provide interfaces for
upper layer program to use. However, those drivers deal with every
component in the communication chain. They do not fit into a structure
storing information closely related to flash chips.


2. Problems

Supporting non-standard flash chips needs to write a new driver. It
requires the developer to be familiar with the internals of flashrom.

Probe functions and IDs are seperated. They are associated by the
flashchip structure. In nature, probe functions and IDs are questions
and answers, and should be associated more closely. Seperated ID
fields in struct flashchip are not very meaningful.

flashrom will probably have plugins in the future. Though chips are
operated in the same way from the view of their host devices, there is
not much useful information for plugins in struct flashchip.


3. Solution

We need an abstract specification of operations in struct flashchip,
not actual code. If there have to be some information not related to
flash chips, the less there is, the better.

Abstract operation specification for SPI flash chips:

/* BEGINNING OF SPECIFICATION */

struct cycles {
        u8 type;	/* CYCLETYPE_PREOPCODE, CYCLETYPE_OPCODE, */
	   		/* CYCLETYPE_ADDRESS, CYCLETYPE_DUMMY,	  */
			/* CYCLETYPE_DATA_IN, CYCLETYPE_DATA_OUT  */
        u8 length;	/* in bytes */
	u8 value_type;	/* VALUETYPE_VARIABLE, VALUETYPE_FIXED	  */
	u32 value;
};

struct cycles byte_read[] =
        {{CYCLETYPE_OPCODE, 1, VALUETYPE_FIXED, 0x3},
       	 {CYCLETYPE_ADDRESS, 3, VALUETYPE_VARIABLE},
	 {CYCLETYPE_DATA_IN, 1, VALUETYPE_VARIABLE}
	};

struct cycles byte_program[] =
        {{CYCLETYPE_PREOPCODE, 1, VALUETYPE_FIXED, 0x6},
	 {CYCLETYPE_OPCODE, 1, VALUETYPE_FIXED, 0x2},
       	 {CYCLETYPE_ADDRESS, 3, VALUETYPE_VARIABLE},
	 {CYCLETYPE_DATA_OUT, 1, VALUETYPE_VARIABLE}
	};

struct cycles SST25VF040B_probe_rdid[] =
        {{CYCLETYPE_OPCODE, 1, VALUETYPE_FIXED, 0x90},
	 {CYCLETYPE_ADDRESS, 3, VALUETYPE_FIXED, 0},
	 {CYCLETYPE_DATA_IN, 2, VALUETYPE_FIXED, 0xbf8d}
	};

struct cycles SST25VF040B_probe_jedec[] =
        {{CYCLETYPE_OPCODE, 1, VALUETYPE_FIXED, 0x9f},
	 {CYCLETYPE_DATA_IN, 3, VALUETYPE_FIXED, 0xbf258d}
	};

/* END OF SPECIFICATION */

Specifications for LPC and FWH flash chips will be different, but the
point is abstraction.

Comments are appreciated.

New year's greetings,
yu ning



From svn at coreboot.org  Thu Jan  1 11:33:53 2009
From: svn at coreboot.org (coreboot)
Date: Thu, 01 Jan 2009 10:33:53 -0000
Subject: [coreboot] #2: Complete tables of supported motherboards
In-Reply-To: <039.70863ac0efa16f2cb1755294334996e4@coreboot.org>
References: <039.70863ac0efa16f2cb1755294334996e4@coreboot.org>
Message-ID: <048.e229ab6cc2d9fdf1d9780fe6a6019abd@coreboot.org>

#2: Complete tables of supported motherboards
----------------------------------+-----------------------------------------
 Reporter:  uwe                   |          Owner:  somebody
     Type:  task                  |         Status:  new     
 Priority:  major                 |      Milestone:          
Component:  wiki/website/tracker  |        Version:          
 Keywords:                        |   Dependencies:          
----------------------------------+-----------------------------------------

Comment(by Radaguask):

 Today launched the new super program .

 It purpose be one of the wealthiest programs of 2009-2010 !

 Program use permit prepare and Anti-DDoS patronage!!!

 From their plot:

 We, the TheWinterProfit.com , are cock-a-hoop to invite You to participate
 in our Investment Programs. prefer uncontrolled to in the course our
 webpage, to connection us for any humanitarian of questions, and of
 assuredly to fasten to our Programs. We are a leading gang of sequestered
 individuals, most of our teammates are knowledgeskilful bankers and
 customrs, who drink made flush to cautious investments in the invest in
 custom on a worldwide heart for through 8 years. Our assemble is made up
 of American and European people, hence we are talented to awake to and
 custom on the contrary markets all but 14 - 18 hours a day. We drink been
 participating in sundry online and offline ventures, resulting in
 significant margins of profit for the owners and for the investors.


 Plans:

 108 % after 1 day
 118% after 2 days
 128% after 3 days

 10% referral commission!

 http://thewinterprofit.com/?ref=beo

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


From peter at stuge.se  Fri Jan  2 01:58:27 2009
From: peter at stuge.se (Peter Stuge)
Date: Fri, 2 Jan 2009 01:58:27 +0100
Subject: [coreboot] wiki page for Asus M2A-VM
In-Reply-To: <1230636643.4269.19.camel@mattotaupa.wohnung.familie-menzel.net>
References: <49487459.7060209@gmx.net> <49506040.5070805@gmx.net>
	<4950ED85.60205@gmx.net> <49583FD5.2010806@gmx.net>
	<1230632371.4269.16.camel@mattotaupa.wohnung.familie-menzel.net>
	<495A011C.9050208@gmx.net>
	<1230636643.4269.19.camel@mattotaupa.wohnung.familie-menzel.net>
Message-ID: <20090102005827.11367.qmail@stuge.se>

Paul Menzel wrote:
> Done [1]. If you have time could you please send me or update the
> ROM chip package (PLCC, DIP32, DIP8, SOIC8)?

The board has a soldered PLCC LPC flash chip.


//Peter
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20090102/47c8eed5/attachment.sig>

From c-d.hailfinger.devel.2006 at gmx.net  Fri Jan  2 03:49:58 2009
From: c-d.hailfinger.devel.2006 at gmx.net (Carl-Daniel Hailfinger)
Date: Fri, 02 Jan 2009 03:49:58 +0100
Subject: [coreboot] 3 days left for CFP Chemnitzer Linux Tage
Message-ID: <495D80D6.5080905@gmx.net>

Hi,

the Chemnitzer Linux Tage 2009 Call for Lectures and Call for
Presentations deadline is this Sunday, January 5th.

Name: Chemnitzer Linux-Tage
Date: March 14, 2009
Location: Chemnitz, Germany
Colocated with: Workshop on Innovative Operating System Concepts (WIOSC)
http://osg.informatik.tu-chemnitz.de/wiosc09/cfp.php

Call for presentations:
http://chemnitzer.linux-tage.de/2009/live/call_form.html (de)
http://chemnitzer.linux-tage.de/2009/live/call_form_en.html (en)

Call for Lectures:
http://chemnitzer.linux-tage.de/2009/vortraege/call.html (de)
http://chemnitzer.linux-tage.de/2009/vortraege/call_en.html (en)

Coreboot has been explicitly asked to present there and I'd like to make
sure this happens.

Unfortunately my internet access is and will be spotty in the next few
days, so it is rather unlikely I can submit a
presentation/lecture/workshop before the deadline.

Besides the usual coreboot talk, installing coreboot on a Asus M2A-VM
could be a nice workshop with readily available and cheap hardware. (The
top hat flash trick should work on that board.)

It would be great if somebody does submit a proposal.

Thanks!

Regards,
Carl-Daniel

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




From jordan at cosmicpenguin.net  Fri Jan  2 04:29:37 2009
From: jordan at cosmicpenguin.net (Jordan Crouse)
Date: Thu, 01 Jan 2009 20:29:37 -0700
Subject: [coreboot] Help with boot block problem
In-Reply-To: <2831fecf0812311127k7743df65t71ba3cd6582c4f18@mail.gmail.com>
References: <2831fecf0812311127k7743df65t71ba3cd6582c4f18@mail.gmail.com>
Message-ID: <495D8A21.50107@cosmicpenguin.net>

Myles Watson wrote:
> I'm porting a board from v2->v3, and I'm running out of space in the
> bootblock, even though it doesn't seem like I should.
> 
> Snippet of broken coreboot.initram.map:
> 
> ffffe3f3 A stage0_rawpnp_exit_ext_func_mode
> ffffe3fc A stage0_rawpnp_set_logical_device
> ffffe41f A stage0_rawpnp_set_iobase
> ffffe448 A stage0_rawpnp_set_enable
> ffffe470 A stage0_protected_stage0
> ffffe47f A stage0___protected_stage0
> ffffe5e8 A stage0__stage0
> ffffe630 A stage0_gdtptr
> fffff960 A stage0_option_table
> fffffff0 A stage0__resetjump
> fffffff0 A stage0__ROMTOP
> 
> Notice that stage0_gdtptr takes fffff960 - ffffe630 = 0x1966
> 
> And working coreboot.initram.map:
> 
> ffffe687 A stage0_rawpnp_read_config
> ffffe69f A stage0_rawpnp_exit_ext_func_mode
> ffffe6a8 A stage0_rawpnp_set_logical_device
> ffffe6cb A stage0_rawpnp_set_iobase
> ffffe6f4 A stage0_rawpnp_set_enable
> ffffe71c A stage0_protected_stage0
> ffffe72b A stage0___protected_stage0
> ffffe894 A stage0__stage0
> ffffe8dc A stage0_gdtptr
> fffff720 A stage0_option_table
> fffffe10 A stage0__estage0_1
> fffffff0 A stage0__resetjump
> fffffff0 A stage0__ROMTOP
> 
> Notice that stage0_gdtptr takes fffff720 - ffffe8dc = 0xe44
> 
> The broken one's gdtptr takes about twice as much?
>
> This might not be the problem, but I don't know where else to look.

Total shot in the dark without looking at code - but a doubling in size 
may indicate a 32 bit vs 64 bit issue.  Did you compile on different 
architectures?

Jordan




From joe at settoplinux.org  Fri Jan  2 05:20:56 2009
From: joe at settoplinux.org (Joseph Smith)
Date: Thu, 01 Jan 2009 23:20:56 -0500
Subject: [coreboot] [RFC]flashrom: improve basic design
In-Reply-To: <a505dc9d0901010221m7b564228tbb5bf1f80818ed6a@mail.gmail.com>
References: <a505dc9d0901010221m7b564228tbb5bf1f80818ed6a@mail.gmail.com>
Message-ID: <5aa83cac3ed645e64d104807af365806@imap.1and1.com>




On Thu, 1 Jan 2009 18:21:23 +0800, "FENG Yu Ning"
<fengyuning1984 at gmail.com> wrote:
> There is a defect in basic design of flashrom. It leads to problems
> some developers are facing or going to face. A partial solution is
> proposed.
> 
> 1. The Defect
> 
> struct flashchip {
> 
>         /* ... */
> 
> 	int (*probe) (struct flashchip *flash);
> 	int (*erase) (struct flashchip *flash);
> 	int (*write) (struct flashchip *flash, uint8_t *buf);
> 	int (*read) (struct flashchip *flash, uint8_t *buf);
> 
>         /* ... */
> 
> };
> 
> The struct specifies drivers for operations. It is a good design if
> the drivers deal with flash chips directly and provide interfaces for
> upper layer program to use. However, those drivers deal with every
> component in the communication chain. They do not fit into a structure
> storing information closely related to flash chips.
> 
> 
> 2. Problems
> 
> Supporting non-standard flash chips needs to write a new driver. It
> requires the developer to be familiar with the internals of flashrom.
> 
> Probe functions and IDs are seperated. They are associated by the
> flashchip structure. In nature, probe functions and IDs are questions
> and answers, and should be associated more closely. Seperated ID
> fields in struct flashchip are not very meaningful.
> 
> flashrom will probably have plugins in the future. Though chips are
> operated in the same way from the view of their host devices, there is
> not much useful information for plugins in struct flashchip.
> 
> 
> 3. Solution
> 
> We need an abstract specification of operations in struct flashchip,
> not actual code. If there have to be some information not related to
> flash chips, the less there is, the better.
> 
> Abstract operation specification for SPI flash chips:
> 
> /* BEGINNING OF SPECIFICATION */
> 
> struct cycles {
>         u8 type;	/* CYCLETYPE_PREOPCODE, CYCLETYPE_OPCODE, */
> 	   		/* CYCLETYPE_ADDRESS, CYCLETYPE_DUMMY,	  */
> 			/* CYCLETYPE_DATA_IN, CYCLETYPE_DATA_OUT  */
>         u8 length;	/* in bytes */
> 	u8 value_type;	/* VALUETYPE_VARIABLE, VALUETYPE_FIXED	  */
> 	u32 value;
> };
> 
> struct cycles byte_read[] =
>         {{CYCLETYPE_OPCODE, 1, VALUETYPE_FIXED, 0x3},
>        	 {CYCLETYPE_ADDRESS, 3, VALUETYPE_VARIABLE},
> 	 {CYCLETYPE_DATA_IN, 1, VALUETYPE_VARIABLE}
> 	};
> 
> struct cycles byte_program[] =
>         {{CYCLETYPE_PREOPCODE, 1, VALUETYPE_FIXED, 0x6},
> 	 {CYCLETYPE_OPCODE, 1, VALUETYPE_FIXED, 0x2},
>        	 {CYCLETYPE_ADDRESS, 3, VALUETYPE_VARIABLE},
> 	 {CYCLETYPE_DATA_OUT, 1, VALUETYPE_VARIABLE}
> 	};
> 
> struct cycles SST25VF040B_probe_rdid[] =
>         {{CYCLETYPE_OPCODE, 1, VALUETYPE_FIXED, 0x90},
> 	 {CYCLETYPE_ADDRESS, 3, VALUETYPE_FIXED, 0},
> 	 {CYCLETYPE_DATA_IN, 2, VALUETYPE_FIXED, 0xbf8d}
> 	};
> 
> struct cycles SST25VF040B_probe_jedec[] =
>         {{CYCLETYPE_OPCODE, 1, VALUETYPE_FIXED, 0x9f},
> 	 {CYCLETYPE_DATA_IN, 3, VALUETYPE_FIXED, 0xbf258d}
> 	};
> 
> /* END OF SPECIFICATION */
> 
> Specifications for LPC and FWH flash chips will be different, but the
> point is abstraction.
> 
> Comments are appreciated.
> 
I agree here, especially if we are going to support external programmers
(plug-ins). This would be a big flashrom change though, and a considerable
amount of work. Have you put together a patch for review yet?

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




From mylesgw at gmail.com  Fri Jan  2 05:44:21 2009
From: mylesgw at gmail.com (Myles Watson)
Date: Thu, 1 Jan 2009 21:44:21 -0700
Subject: [coreboot] Help with boot block problem
In-Reply-To: <495D8A21.50107@cosmicpenguin.net>
References: <2831fecf0812311127k7743df65t71ba3cd6582c4f18@mail.gmail.com>
	<495D8A21.50107@cosmicpenguin.net>
Message-ID: <F61F046F64A64C02ABE3BB6275429403@chimp>



> -----Original Message-----
> From: Jordan Crouse [mailto:jordan at cosmicpenguin.net]
> Sent: Thursday, January 01, 2009 8:30 PM
> To: Myles Watson
> Cc: Coreboot
> Subject: Re: [coreboot] Help with boot block problem
> 
> Myles Watson wrote:
> > I'm porting a board from v2->v3, and I'm running out of space in the
> > bootblock, even though it doesn't seem like I should.
> >
> > Snippet of broken coreboot.initram.map:
> >
> > ffffe3f3 A stage0_rawpnp_exit_ext_func_mode
> > ffffe3fc A stage0_rawpnp_set_logical_device
> > ffffe41f A stage0_rawpnp_set_iobase
> > ffffe448 A stage0_rawpnp_set_enable
> > ffffe470 A stage0_protected_stage0
> > ffffe47f A stage0___protected_stage0
> > ffffe5e8 A stage0__stage0
> > ffffe630 A stage0_gdtptr
> > fffff960 A stage0_option_table
> > fffffff0 A stage0__resetjump
> > fffffff0 A stage0__ROMTOP
> >
> > Notice that stage0_gdtptr takes fffff960 - ffffe630 = 0x1966
> >
> > And working coreboot.initram.map:
> >
> > ffffe687 A stage0_rawpnp_read_config
> > ffffe69f A stage0_rawpnp_exit_ext_func_mode
> > ffffe6a8 A stage0_rawpnp_set_logical_device
> > ffffe6cb A stage0_rawpnp_set_iobase
> > ffffe6f4 A stage0_rawpnp_set_enable
> > ffffe71c A stage0_protected_stage0
> > ffffe72b A stage0___protected_stage0
> > ffffe894 A stage0__stage0
> > ffffe8dc A stage0_gdtptr
> > fffff720 A stage0_option_table
> > fffffe10 A stage0__estage0_1
> > fffffff0 A stage0__resetjump
> > fffffff0 A stage0__ROMTOP
> >
> > Notice that stage0_gdtptr takes fffff720 - ffffe8dc = 0xe44
> >
> > The broken one's gdtptr takes about twice as much?
> >
> > This might not be the problem, but I don't know where else to look.
> 
> Total shot in the dark without looking at code - but a doubling in size
> may indicate a 32 bit vs 64 bit issue.  Did you compile on different
> architectures?

Good thought.  Unfortunately no.  It's the same machine, back to back
compiles with a make clean and make menuconfig in between.

Thanks,
Myles




From ledebass at gmail.com  Fri Jan  2 11:15:32 2009
From: ledebass at gmail.com (Daniele Primon)
Date: Fri, 2 Jan 2009 10:15:32 +0000
Subject: [coreboot] coreboot Digest, Vol 46, Issue 148
In-Reply-To: <mailman.73.1229874902.13869.coreboot@coreboot.org>
References: <mailman.73.1229874902.13869.coreboot@coreboot.org>
Message-ID: <38687c4a0901020215g386111dbg3401eb2d684058a9@mail.gmail.com>

Hi, obrain a similar output when trying to flash a proprietary BIOS.
What I guess is that the initial address could be wrong. Here is the
output:

root at debian:~# flashrom -w -v A6T-ASUS-0706.ROMCalibrating delay
loop... OK.No coreboot table found.Found chipset "NVIDIA MCP51",
enabling flash write... OK.Found chip "PMC Pm49FL004" (512 KB) at
physical address 0xfff80000.Flash image seems to be a legacy BIOS.
Disabling checks.Programming page: 0007 at address:
0x00070000Verifying flash... FAILED!  Expected=0xf8, Read=0x68

2008/12/21, coreboot-request at coreboot.org <coreboot-request at coreboot.org>:
> Send coreboot mailing list submissions to
> 	coreboot at coreboot.org
>
> To subscribe or unsubscribe via the World Wide Web, visit
> 	http://www.coreboot.org/mailman/listinfo/coreboot
> or, via email, send a message with subject or body 'help' to
> 	coreboot-request at coreboot.org
>
> You can reach the person managing the list at
> 	coreboot-owner at coreboot.org
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of coreboot digest..."
>
>
> Today's Topics:
>
>    1. Re: need help with #define macro (Joseph Smith)
>    2. Re: flashrom Asus A6T MCP51 PMC Pm49FL004 (razor1394)
>
>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Sun, 21 Dec 2008 10:48:47 -0500
> From: Joseph Smith <joe at settoplinux.org>
> Subject: Re: [coreboot] need help with #define macro
> To: Peter Stuge <peter at stuge.se>
> Cc: coreboot <coreboot at coreboot.org>
> Message-ID: <c09c20cbc5e98c7ec539757700db975b at imap.1and1.com>
> Content-Type: text/plain; charset="UTF-8"
>
>
>>> Sorry, I am still learning more and more every day....
>>
>> And that's a great thing. Please don't let me discourage it.
>> But coreboot isn't really the place to learn C.
>>
> I hate to say it Peter sometimes you can be a little discouraging, I think
> it is just embedded in your personality, so I try not to take offence to
> it. For me personally the best way to learn is from my peers, but if it
> irritates people that I ask C related questions on the mailing list I will
> stop, and find help else where.
>
> --
> Thanks,
> Joseph Smith
> Set-Top-Linux
> www.settoplinux.org
>
>
>
>
> ------------------------------
>
> Message: 2
> Date: Sun, 21 Dec 2008 16:54:46 +0100
> From: razor1394 <razor1394 at gmail.com>
> Subject: Re: [coreboot] flashrom Asus A6T MCP51 PMC Pm49FL004
> To: coreboot at coreboot.org
> Message-ID:
> 	<c1d5393c0812210754h44b27464g65cb25ab78919e63 at mail.gmail.com>
> Content-Type: text/plain; charset="utf-8"
>
> Sorry I forgot...
>
> razor1394 at picon:~$ sudo flashrom -V -v backup.bin
> [sudo] password for razor1394:
> Calibrating delay loop... 240M loops per second. OK.
> No coreboot table found.
> Found chipset "NVIDIA MCP51", enabling flash write... OK.
> Probing for AMD Am29F016D, 2048 KB: probe_29f040b: id1 0xff, id2 0xff
> Probing for AMD Am29F040B, 512 KB: probe_29f040b: id1 0xff, id2 0xff
> Probing for AMD Am29LV040B, 512 KB: probe_29f040b: id1 0xff, id2 0xff
> Probing for ASD AE49F2008, 256 KB: probe_jedec: id1 0x9d, id2 0x6e
> Probing for Atmel AT29C020, 256 KB: probe_jedec: id1 0x9d, id2 0x6e
> Probing for Atmel AT29C040A, 512 KB: probe_jedec: id1 0x9d, id2 0x6e
> Probing for Atmel AT49F002(N), 256 KB: probe_jedec: id1 0x9d, id2 0x6e
> Probing for Atmel AT49F002(N)T, 256 KB: probe_jedec: id1 0x9d, id2 0x6e
> Probing for Atmel AT25DF321, 4096 KB: spi_command called, but no SPI
> chipset
> detected
> Probing for AMIC Technology A25L40P, 512 KB: spi_command called, but no SPI
> chipset detected
> Probing for AMIC Technology A49LF040A, 512 KB: probe_jedec: id1 0x9d, id2
> 0x6e
> Probing for AMIC Technology A29040B, 512 KB: probe_29f040b: id1 0xff, id2
> 0xff
> Probing for EMST F49B002UA, 256 KB: probe_jedec: id1 0x9d, id2 0x6e
> Probing for EON EN29F002(A)(N)B, 256 KB: probe_jedec: id1 0x9d, id2 0x6e
> Probing for EON EN29F002(A)(N)T, 256 KB: probe_jedec: id1 0x9d, id2 0x6e
> Probing for Fujitsu MBM29F400TC, 512 KB: probe_m29f400bt: id1 0xff, id2
> 0xff
> Probing for Intel 82802AB, 512 KB: probe_82802ab: id1 0xff, id2 0xff
> Probing for Intel 82802AC, 1024 KB: probe_82802ab: id1 0xff, id2 0xff
> Probing for Macronix MX25L4005, 512 KB: spi_command called, but no SPI
> chipset detected
> Probing for Macronix MX25L8005, 1024 KB: spi_command called, but no SPI
> chipset detected
> Probing for Macronix MX25L1605, 2048 KB: spi_command called, but no SPI
> chipset detected
> Probing for Macronix MX25L3205, 4096 KB: spi_command called, but no SPI
> chipset detected
> Probing for Macronix MX29F002, 256 KB: probe_29f002: id1 0x9d, id2 0x6e
> Probing for PMC Pm25LV010, 128 KB: spi_command called, but no SPI chipset
> detected
> Probing for PMC Pm25LV016B, 2048 KB: spi_command called, but no SPI chipset
> detected
> Probing for PMC Pm25LV020, 256 KB: spi_command called, but no SPI chipset
> detected
> Probing for PMC Pm25LV040, 512 KB: spi_command called, but no SPI chipset
> detected
> Probing for PMC Pm25LV080B, 1024 KB: spi_command called, but no SPI chipset
> detected
> Probing for PMC Pm25LV512, 64 KB: spi_command called, but no SPI chipset
> detected
> Probing for PMC Pm49FL002, 256 KB: probe_jedec: id1 0x9d, id2 0x6e
> Probing for PMC Pm49FL004, 512 KB: probe_jedec: id1 0x9d, id2 0x6e
> Found chip "PMC Pm49FL004" (512 KB) at physical address 0xfff80000.
> Probing for Sharp LHF00L04, 1024 KB: probe_lhf00l04: id1 0xff, id2 0xff
> Probing for Spansion S25FL016A, 2048 KB: spi_command called, but no SPI
> chipset detected
> Probing for SST SST25VF016B, 2048 KB: spi_command called, but no SPI
> chipset
> detected
> Probing for SST SST25VF040B, 512 KB: spi_command called, but no SPI chipset
> detected
> Probing for SST SST28SF040A, 512 KB: probe_28sf040: id1 0xff, id2 0xff
> Probing for SST SST29EE010, 128 KB: probe_jedec: id1 0x9d, id2 0x6e
> Probing for SST SST29LE010, 128 KB: probe_jedec: id1 0x9d, id2 0x6e
> Probing for SST SST29EE020A, 256 KB: probe_jedec: id1 0x9d, id2 0x6e
> Probing for SST SST29LE020, 256 KB: probe_jedec: id1 0x9d, id2 0x6e
> Probing for SST SST39SF010A, 128 KB: probe_jedec: id1 0x9d, id2 0x6e
> Probing for SST SST39SF020A, 256 KB: probe_jedec: id1 0x9d, id2 0x6e
> Probing for SST SST39SF040, 512 KB: probe_jedec: id1 0x9d, id2 0x6e
> Probing for SST SST39VF512, 64 KB: probe_jedec: id1 0x9d, id2 0x6e
> Probing for SST SST39VF010, 128 KB: probe_jedec: id1 0x9d, id2 0x6e
> Probing for SST SST39VF020, 256 KB: probe_jedec: id1 0x9d, id2 0x6e
> Probing for SST SST39VF040, 512 KB: probe_jedec: id1 0x9d, id2 0x6e
> Probing for SST SST49LF002A/B, 256 KB: probe_jedec: id1 0x9d, id2 0x6e
> Probing for SST SST49LF003A/B, 384 KB: probe_jedec: id1 0x9d, id2 0x6e
> Probing for SST SST49LF004A/B, 512 KB: probe_jedec: id1 0x9d, id2 0x6e
> Probing for SST SST49LF004C, 512 KB: probe_49lfxxxc: id1 0xff, id2 0xff
> Probing for SST SST49LF008A, 1024 KB: probe_jedec: id1 0xff, id2 0xff, id1
> parity violation
> Probing for SST SST49LF008C, 1024 KB: probe_49lfxxxc: id1 0xff, id2 0xff
> Probing for SST SST49LF016C, 2048 KB: probe_49lfxxxc: id1 0xff, id2 0xff
> Probing for SST SST49LF020A, 256 KB: probe_jedec: id1 0x9d, id2 0x6e
> Probing for SST SST49LF040, 512 KB: probe_jedec: id1 0x9d, id2 0x6e
> Probing for SST SST49LF040B, 512 KB: probe_jedec: id1 0x9d, id2 0x6e
> Probing for SST SST49LF080A, 1024 KB: probe_jedec: id1 0xff, id2 0xff, id1
> parity violation
> Probing for SST SST49LF160C, 2048 KB: probe_49lfxxxc: id1 0xff, id2 0xff
> Probing for ST M25P05-A, 64 KB: spi_command called, but no SPI chipset
> detected
> Probing for ST M25P10-A, 128 KB: spi_command called, but no SPI chipset
> detected
> Probing for ST M25P20, 256 KB: spi_command called, but no SPI chipset
> detected
> Probing for ST M25P40, 512 KB: spi_command called, but no SPI chipset
> detected
> Probing for ST M25P40-old, 512 KB: spi_command called, but no SPI chipset
> detected
> Probing for ST M25P80, 1024 KB: spi_command called, but no SPI chipset
> detected
> Probing for ST M25P16, 2048 KB: spi_command called, but no SPI chipset
> detected
> Probing for ST M25P32, 4096 KB: spi_command called, but no SPI chipset
> detected
> Probing for ST M25P64, 8192 KB: spi_command called, but no SPI chipset
> detected
> Probing for ST M25P128, 16384 KB: spi_command called, but no SPI chipset
> detected
> Probing for ST M29F002B, 256 KB: probe_jedec: id1 0x9d, id2 0x6e
> Probing for ST M29F002T/NT, 256 KB: probe_jedec: id1 0x9d, id2 0x6e
> Probing for ST M29F040B, 512 KB: probe_29f040b: id1 0xff, id2 0xff
> Probing for ST M29F400BT, 512 KB: probe_m29f400bt: id1 0xff, id2 0xff
> Probing for ST M29W010B, 128 KB: probe_jedec: id1 0x9d, id2 0x6e
> Probing for ST M29W040B, 512 KB: probe_jedec: id1 0x9d, id2 0x6e
> Probing for ST M50FLW040A, 512 KB: probe_stm50flw0x0x: id1 0x9d, id2 0x6e
> Probing for ST M50FLW040B, 512 KB: probe_stm50flw0x0x: id1 0x9d, id2 0x6e
> Probing for ST M50FLW080A, 1024 KB: probe_stm50flw0x0x: id1 0xff, id2 0xff
> Probing for ST M50FLW080B, 1024 KB: probe_stm50flw0x0x: id1 0xff, id2 0xff
> Probing for ST M50FW016, 2048 KB: probe_82802ab: id1 0xff, id2 0xff
> Probing for ST M50FW040, 512 KB: probe_82802ab: id1 0xff, id2 0xff
> Probing for ST M50FW080, 1024 KB: probe_82802ab: id1 0xff, id2 0xff
> Probing for ST M50LPW116, 2048 KB: probe_jedec: id1 0xff, id2 0xff, id1
> parity violation
> Probing for SyncMOS S29C31004T, 512 KB: probe_jedec: id1 0x9d, id2 0x6e
> Probing for SyncMOS S29C51001T, 128 KB: probe_jedec: id1 0x9d, id2 0x6e
> Probing for SyncMOS S29C51002T, 256 KB: probe_jedec: id1 0x9d, id2 0x6e
> Probing for SyncMOS S29C51004T, 512 KB: probe_jedec: id1 0x9d, id2 0x6e
> Probing for Winbond W25x10, 128 KB: spi_command called, but no SPI chipset
> detected
> Probing for Winbond W25x20, 256 KB: spi_command called, but no SPI chipset
> detected
> Probing for Winbond W25x40, 512 KB: spi_command called, but no SPI chipset
> detected
> Probing for Winbond W25x80, 1024 KB: spi_command called, but no SPI chipset
> detected
> Probing for Winbond W29C011, 128 KB: probe_jedec: id1 0x9d, id2 0x6e
> Probing for Winbond W29C020C, 256 KB: probe_jedec: id1 0x9d, id2 0x6e
> Probing for Winbond W29C040P, 512 KB: probe_jedec: id1 0x9d, id2 0x6e
> Probing for Winbond W29EE011, 128 KB:
> ===
>   Probing disabled for Winbond W29EE011 because the probing sequence puts
> the
>   AMIC A49LF040A in a funky state.
>   Use 'flashrom -c W29EE011' if you have a board with this chip.
> ===
> Probing for Winbond W39V040A, 512 KB: probe_jedec: id1 0x9d, id2 0x6e
> Probing for Winbond W39V040B, 512 KB: probe_jedec: id1 0x9d, id2 0x6e
> Probing for Winbond W39V040FA, 512 KB: probe_jedec: id1 0x9d, id2 0x6e
> Probing for Winbond W39V080A, 1024 KB: probe_jedec: id1 0xff, id2 0xff, id1
> parity violation
> Probing for Winbond W49F002U, 256 KB: probe_jedec: id1 0x9d, id2 0x6e
> Probing for Winbond W49V002A, 256 KB: probe_jedec: id1 0x9d, id2 0x6e
> Probing for Winbond W49V002FA, 256 KB: probe_jedec: id1 0x9d, id2 0x6e
> Probing for Winbond W39V080FA, 1024 KB: probe_winbond_fwhub: vid 0xff, did
> 0xff
> Probing for Winbond W39V080FA (dual mode), 512 KB: probe_winbond_fwhub: vid
> 0x9d, did 0x6e
> Probing for EON unknown EON SPI chip, 0 KB: spi_command called, but no SPI
> chipset detected
> Probing for Macronix unknown Macronix SPI chip, 0 KB: spi_command called,
> but no SPI chipset detected
> Probing for PMC unknown PMC SPI chip, 0 KB: spi_command called, but no SPI
> chipset detected
> Probing for SST unknown SST SPI chip, 0 KB: spi_command called, but no SPI
> chipset detected
> Probing for ST unknown ST SPI chip, 0 KB: spi_command called, but no SPI
> chipset detected
> Flash image seems to be a legacy BIOS. Disabling checks.
> Verifying flash... address: 0x0006e079 FAILED!  Expected=0x09, Read=0x94
>
> 2008/12/21 razor1394 <razor1394 at gmail.com>
>
>> I copied the aflash2 folder after installing it with Wine and copied the
>> contents to a USB drive. Then I booted from a Vista live disc with the
>> stick
>> connected but when I tried to launch the aflash2 utility it complained
>> about
>> ASUS ATK0100 UTILITY (ACPI) not being found. So I'm going to try flashing
>> from a USB stick with DOS installed. I know this works in other computers
>> because I have done it several times.
>>
>> 2008/12/21 razor1394 <razor1394 at gmail.com>
>>
>> razor1394 at picon:~$ sudo flashrom -V -v
>>> Calibrating delay loop... 235M loops per second. OK.
>>> No coreboot table found.
>>> Found chipset "NVIDIA MCP51", enabling flash write... OK.
>>> Probing for AMD Am29F016D, 2048 KB: probe_29f040b: id1 0xff, id2 0xff
>>> Probing for AMD Am29F040B, 512 KB: probe_29f040b: id1 0xff, id2 0xff
>>> Probing for AMD Am29LV040B, 512 KB: probe_29f040b: id1 0xff, id2 0xff
>>> Probing for ASD AE49F2008, 256 KB: probe_jedec: id1 0x9d, id2 0x6e
>>> Probing for Atmel AT29C020, 256 KB: probe_jedec: id1 0x9d, id2 0x6e
>>> Probing for Atmel AT29C040A, 512 KB: probe_jedec: id1 0x9d, id2 0x6e
>>> Probing for Atmel AT49F002(N), 256 KB: probe_jedec: id1 0x9d, id2 0x6e
>>> Probing for Atmel AT49F002(N)T, 256 KB: probe_jedec: id1 0x9d, id2 0x6e
>>> Probing for Atmel AT25DF321, 4096 KB: spi_command called, but no SPI
>>> chipset detected
>>> Probing for AMIC Technology A25L40P, 512 KB: spi_command called, but no
>>> SPI chipset detected
>>> Probing for AMIC Technology A49LF040A, 512 KB: probe_jedec: id1 0x9d,
>>> id2
>>> 0x6e
>>> Probing for AMIC Technology A29040B, 512 KB: probe_29f040b: id1 0xff,
>>> id2
>>> 0xff
>>> Probing for EMST F49B002UA, 256 KB: probe_jedec: id1 0x9d, id2 0x6e
>>> Probing for EON EN29F002(A)(N)B, 256 KB: probe_jedec: id1 0x9d, id2 0x6e
>>> Probing for EON EN29F002(A)(N)T, 256 KB: probe_jedec: id1 0x9d, id2 0x6e
>>> Probing for Fujitsu MBM29F400TC, 512 KB: probe_m29f400bt: id1 0xff, id2
>>> 0xff
>>> Probing for Intel 82802AB, 512 KB: probe_82802ab: id1 0xff, id2 0xff
>>> Probing for Intel 82802AC, 1024 KB: probe_82802ab: id1 0xff, id2 0xff
>>> Probing for Macronix MX25L4005, 512 KB: spi_command called, but no SPI
>>> chipset detected
>>> Probing for Macronix MX25L8005, 1024 KB: spi_command called, but no SPI
>>> chipset detected
>>> Probing for Macronix MX25L1605, 2048 KB: spi_command called, but no SPI
>>> chipset detected
>>> Probing for Macronix MX25L3205, 4096 KB: spi_command called, but no SPI
>>> chipset detected
>>> Probing for Macronix MX29F002, 256 KB: probe_29f002: id1 0x9d, id2 0x6e
>>> Probing for PMC Pm25LV010, 128 KB: spi_command called, but no SPI
>>> chipset
>>> detected
>>> Probing for PMC Pm25LV016B, 2048 KB: spi_command called, but no SPI
>>> chipset detected
>>> Probing for PMC Pm25LV020, 256 KB: spi_command called, but no SPI
>>> chipset
>>> detected
>>> Probing for PMC Pm25LV040, 512 KB: spi_command called, but no SPI
>>> chipset
>>> detected
>>> Probing for PMC Pm25LV080B, 1024 KB: spi_command called, but no SPI
>>> chipset detected
>>> Probing for PMC Pm25LV512, 64 KB: spi_command called, but no SPI chipset
>>> detected
>>> Probing for PMC Pm49FL002, 256 KB: probe_jedec: id1 0x9d, id2 0x6e
>>> Probing for PMC Pm49FL004, 512 KB: probe_jedec: id1 0x9d, id2 0x6e
>>> Found chip "PMC Pm49FL004" (512 KB) at physical address 0xfff80000.
>>>  Probing for Sharp LHF00L04, 1024 KB: probe_lhf00l04: id1 0xff, id2 0xff
>>> Probing for Spansion S25FL016A, 2048 KB: spi_command called, but no SPI
>>> chipset detected
>>> Probing for SST SST25VF016B, 2048 KB: spi_command called, but no SPI
>>> chipset detected
>>> Probing for SST SST25VF040B, 512 KB: spi_command called, but no SPI
>>> chipset detected
>>> Probing for SST SST28SF040A, 512 KB: probe_28sf040: id1 0xff, id2 0xff
>>> Probing for SST SST29EE010, 128 KB: probe_jedec: id1 0x9d, id2 0x6e
>>> Probing for SST SST29LE010, 128 KB: probe_jedec: id1 0x9d, id2 0x6e
>>> Probing for SST SST29EE020A, 256 KB: probe_jedec: id1 0x9d, id2 0x6e
>>> Probing for SST SST29LE020, 256 KB: probe_jedec: id1 0x9d, id2 0x6e
>>> Probing for SST SST39SF010A, 128 KB: probe_jedec: id1 0x9d, id2 0x6e
>>> Probing for SST SST39SF020A, 256 KB: probe_jedec: id1 0x9d, id2 0x6e
>>> Probing for SST SST39SF040, 512 KB: probe_jedec: id1 0x9d, id2 0x6e
>>> Probing for SST SST39VF512, 64 KB: probe_jedec: id1 0x9d, id2 0x6e
>>> Probing for SST SST39VF010, 128 KB: probe_jedec: id1 0x9d, id2 0x6e
>>> Probing for SST SST39VF020, 256 KB: probe_jedec: id1 0x9d, id2 0x6e
>>> Probing for SST SST39VF040, 512 KB: probe_jedec: id1 0x9d, id2 0x6e
>>> Probing for SST SST49LF002A/B, 256 KB: probe_jedec: id1 0x9d, id2 0x6e
>>> Probing for SST SST49LF003A/B, 384 KB: probe_jedec: id1 0x9d, id2 0x6e
>>> Probing for SST SST49LF004A/B, 512 KB: probe_jedec: id1 0x9d, id2 0x6e
>>> Probing for SST SST49LF004C, 512 KB: probe_49lfxxxc: id1 0xff, id2 0xff
>>> Probing for SST SST49LF008A, 1024 KB: probe_jedec: id1 0xff, id2 0xff,
>>> id1
>>> parity violation
>>> Probing for SST SST49LF008C, 1024 KB: probe_49lfxxxc: id1 0xff, id2 0xff
>>> Probing for SST SST49LF016C, 2048 KB: probe_49lfxxxc: id1 0xff, id2 0xff
>>> Probing for SST SST49LF020A, 256 KB: probe_jedec: id1 0x9d, id2 0x6e
>>> Probing for SST SST49LF040, 512 KB: probe_jedec: id1 0x9d, id2 0x6e
>>> Probing for SST SST49LF040B, 512 KB: probe_jedec: id1 0x9d, id2 0x6e
>>> Probing for SST SST49LF080A, 1024 KB: probe_jedec: id1 0xff, id2 0xff,
>>> id1
>>> parity violation
>>> Probing for SST SST49LF160C, 2048 KB: probe_49lfxxxc: id1 0xff, id2 0xff
>>> Probing for ST M25P05-A, 64 KB: spi_command called, but no SPI chipset
>>> detected
>>> Probing for ST M25P10-A, 128 KB: spi_command called, but no SPI chipset
>>> detected
>>> Probing for ST M25P20, 256 KB: spi_command called, but no SPI chipset
>>> detected
>>> Probing for ST M25P40, 512 KB: spi_command called, but no SPI chipset
>>> detected
>>> Probing for ST M25P40-old, 512 KB: spi_command called, but no SPI
>>> chipset
>>> detected
>>> Probing for ST M25P80, 1024 KB: spi_command called, but no SPI chipset
>>> detected
>>> Probing for ST M25P16, 2048 KB: spi_command called, but no SPI chipset
>>> detected
>>> Probing for ST M25P32, 4096 KB: spi_command called, but no SPI chipset
>>> detected
>>> Probing for ST M25P64, 8192 KB: spi_command called, but no SPI chipset
>>> detected
>>> Probing for ST M25P128, 16384 KB: spi_command called, but no SPI chipset
>>> detected
>>> Probing for ST M29F002B, 256 KB: probe_jedec: id1 0x9d, id2 0x6e
>>> Probing for ST M29F002T/NT, 256 KB: probe_jedec: id1 0x9d, id2 0x6e
>>> Probing for ST M29F040B, 512 KB: probe_29f040b: id1 0xff, id2 0xff
>>> Probing for ST M29F400BT, 512 KB: probe_m29f400bt: id1 0xff, id2 0xff
>>> Probing for ST M29W010B, 128 KB: probe_jedec: id1 0x9d, id2 0x6e
>>> Probing for ST M29W040B, 512 KB: probe_jedec: id1 0x9d, id2 0x6e
>>> Probing for ST M50FLW040A, 512 KB: probe_stm50flw0x0x: id1 0x9d, id2
>>> 0x6e
>>> Probing for ST M50FLW040B, 512 KB: probe_stm50flw0x0x: id1 0x9d, id2
>>> 0x6e
>>> Probing for ST M50FLW080A, 1024 KB: probe_stm50flw0x0x: id1 0xff, id2
>>> 0xff
>>> Probing for ST M50FLW080B, 1024 KB: probe_stm50flw0x0x: id1 0xff, id2
>>> 0xff
>>> Probing for ST M50FW016, 2048 KB: probe_82802ab: id1 0xff, id2 0xff
>>> Probing for ST M50FW040, 512 KB: probe_82802ab: id1 0xff, id2 0xff
>>> Probing for ST M50FW080, 1024 KB: probe_82802ab: id1 0xff, id2 0xff
>>> Probing for ST M50LPW116, 2048 KB: probe_jedec: id1 0xff, id2 0xff, id1
>>> parity violation
>>> Probing for SyncMOS S29C31004T, 512 KB: probe_jedec: id1 0x9d, id2 0x6e
>>> Probing for SyncMOS S29C51001T, 128 KB: probe_jedec: id1 0x9d, id2 0x6e
>>> Probing for SyncMOS S29C51002T, 256 KB: probe_jedec: id1 0x9d, id2 0x6e
>>> Probing for SyncMOS S29C51004T, 512 KB: probe_jedec: id1 0x9d, id2 0x6e
>>> Probing for Winbond W25x10, 128 KB: spi_command called, but no SPI
>>> chipset
>>> detected
>>> Probing for Winbond W25x20, 256 KB: spi_command called, but no SPI
>>> chipset
>>> detected
>>> Probing for Winbond W25x40, 512 KB: spi_command called, but no SPI
>>> chipset
>>> detected
>>> Probing for Winbond W25x80, 1024 KB: spi_command called, but no SPI
>>> chipset detected
>>> Probing for Winbond W29C011, 128 KB: probe_jedec: id1 0x9d, id2 0x6e
>>> Probing for Winbond W29C020C, 256 KB: probe_jedec: id1 0x9d, id2 0x6e
>>> Probing for Winbond W29C040P, 512 KB: probe_jedec: id1 0x9d, id2 0x6e
>>> Probing for Winbond W29EE011, 128 KB:
>>> ===
>>>   Probing disabled for Winbond W29EE011 because the probing sequence
>>> puts
>>> the
>>>   AMIC A49LF040A in a funky state.
>>>   Use 'flashrom -c W29EE011' if you have a board with this chip.
>>> ===
>>> Probing for Winbond W39V040A, 512 KB: probe_jedec: id1 0x9d, id2 0x6e
>>> Probing for Winbond W39V040B, 512 KB: probe_jedec: id1 0x9d, id2 0x6e
>>> Probing for Winbond W39V040FA, 512 KB: probe_jedec: id1 0x9d, id2 0x6e
>>> Probing for Winbond W39V080A, 1024 KB: probe_jedec: id1 0xff, id2 0xff,
>>> id1 parity violation
>>> Probing for Winbond W49F002U, 256 KB: probe_jedec: id1 0x9d, id2 0x6e
>>> Probing for Winbond W49V002A, 256 KB: probe_jedec: id1 0x9d, id2 0x6e
>>> Probing for Winbond W49V002FA, 256 KB: probe_jedec: id1 0x9d, id2 0x6e
>>> Probing for Winbond W39V080FA, 1024 KB: probe_winbond_fwhub: vid 0xff,
>>> did
>>> 0xff
>>> Probing for Winbond W39V080FA (dual mode), 512 KB: probe_winbond_fwhub:
>>> vid 0x9d, did 0x6e
>>> Probing for EON unknown EON SPI chip, 0 KB: spi_command called, but no
>>> SPI
>>> chipset detected
>>> Probing for Macronix unknown Macronix SPI chip, 0 KB: spi_command
>>> called,
>>> but no SPI chipset detected
>>> Probing for PMC unknown PMC SPI chip, 0 KB: spi_command called, but no
>>> SPI
>>> chipset detected
>>> Probing for SST unknown SST SPI chip, 0 KB: spi_command called, but no
>>> SPI
>>> chipset detected
>>> Probing for ST unknown ST SPI chip, 0 KB: spi_command called, but no SPI
>>> chipset detected
>>> Error: No filename specified.
>>>
>>> 2008/12/21 Peter Stuge <peter at stuge.se>
>>>
>>>  razor1394 wrote:
>>>> > Reading the old bios worked but writing failed as verification did
>>>> > not pass.
>>>>
>>>> It would be interesting to see the output from verification.
>>>>
>>>>
>>>> > Writing was going very slowly. I flashed the backup bios
>>>> > immediately which verified fine and everything worked after reboot.
>>>> > I'm guessing something is suspicious about the new bios.
>>>>
>>>> The problem is quite likely that a GPIO pin of some chip is connected
>>>> to the two write protect pins on the flash chip.
>>>>
>>>> You can run flashrom -V to show their status of them. Please send
>>>> that output also. (Or combine and run flashrom -V -v so we can get
>>>> the verify output in one go.)
>>>>
>>>>
>>>> > As the MCP51 flashrom status is marked with a question mark I
>>>> > thought this could be interesting.
>>>>
>>>> Any flashrom failure is interesting! Thanks for the report.
>>>>
>>>>
>>>> //Peter
>>>>
>>>> --
>>>> coreboot mailing list: coreboot at coreboot.org
>>>> http://www.coreboot.org/mailman/listinfo/coreboot
>>>>
>>>
>>>
>>>
>>> --
>>> RaZoR1394
>>>
>>
>>
>>
>> --
>> RaZoR1394
>>
>
>
>
> --
> RaZoR1394
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL:
> <http://www.coreboot.org/pipermail/coreboot/attachments/20081221/c650f150/attachment.htm>
>
> ------------------------------
>
> _______________________________________________
> coreboot mailing list
> coreboot at coreboot.org
> http://www.coreboot.org/mailman/listinfo/coreboot
>
> End of coreboot Digest, Vol 46, Issue 148
> *****************************************
>
>



From spooky85 at gmail.com  Fri Jan  2 14:25:56 2009
From: spooky85 at gmail.com (Christian Ruppert)
Date: Fri, 2 Jan 2009 14:25:56 +0100
Subject: [coreboot] ASUS M2N-SLI Deluxe
In-Reply-To: <1230650997.15846.15.camel@mattotaupa.wohnung.familie-menzel.net>
References: <bb492f590812300627y5e3ab793n133d50d3379e07da@mail.gmail.com>
	<1230648997.15846.6.camel@mattotaupa.wohnung.familie-menzel.net>
	<1230650997.15846.15.camel@mattotaupa.wohnung.familie-menzel.net>
Message-ID: <bb492f590901020525t6e3c3daeg5cf024e6b8011d7@mail.gmail.com>

2008/12/30 Paul Menzel <paulepanter at users.sourceforge.net>:
> Dear Christian,
> [I added the list again.]
>
>
> Am Dienstag, den 30.12.2008, 16:09 +0100 schrieb Christian Ruppert:
>> 2008/12/30 Paul Menzel <paulepanter at users.sourceforge.net>:
>
>> > Am Dienstag, den 30.12.2008, 15:27 +0100 schrieb Christian Ruppert:
>> >
>> >> here is 'lspci -tvnn'.
>> >> additional cards are marked with PCIE CARD at the begin of line, rest
>> >> should be onboard.
>> >> i hope it help :)
>> >>
>> >> -[0000:00]-+-00.0  nVidia Corporation MCP55 Memory Controller [10de:0369]
>> >>            +-01.0  nVidia Corporation MCP55 LPC Bridge [10de:0360]
>> >>            +-01.1  nVidia Corporation MCP55 SMBus [10de:0368]
>> >>            +-02.0  nVidia Corporation MCP55 USB Controller [10de:036c]
>> >>            +-02.1  nVidia Corporation MCP55 USB Controller [10de:036d]
>> >>            +-04.0  nVidia Corporation MCP55 IDE [10de:036e]
>> >>            +-05.0  nVidia Corporation MCP55 SATA Controller [10de:037f]
>> >>            +-05.1  nVidia Corporation MCP55 SATA Controller [10de:037f]
>> >>            +-05.2  nVidia Corporation MCP55 SATA Controller [10de:037f]
>> >>            +-06.0-[0000:01]----0b.0  Texas Instruments TSB43AB22/A
>> >> IEEE-1394a-2000 Controller (PHY/Link) [104c:8023]
>> >>            +-06.1  nVidia Corporation MCP55 High Definition Audio [10de:0371]
>> >>            +-08.0  nVidia Corporation MCP55 Ethernet [10de:0373]
>> >>            +-09.0  nVidia Corporation MCP55 Ethernet [10de:0373]
>> >> PCIE CARD           +-0a.0-[0000:02]----00.0  nVidia Corporation G70
>> >> [GeForce 7600 GT] [10de:0391]
>> >>            +-0e.0-[0000:03]--
>> >> PCIE CARD           +-0f.0-[0000:04]----00.0  nVidia Corporation G70
>> >> [GeForce 7600 GT] [10de:0391]
>> >>            +-18.0  Advanced Micro Devices [AMD] K8 [Athlon64/Opteron]
>> >> HyperTransport Technology Configuration [1022:1100]
>> >>            +-18.1  Advanced Micro Devices [AMD] K8 [Athlon64/Opteron]
>> >> Address Map [1022:1101]
>> >>            +-18.2  Advanced Micro Devices [AMD] K8 [Athlon64/Opteron]
>> >> DRAM Controller [1022:1102]
>> >>            \-18.3  Advanced Micro Devices [AMD] K8 [Athlon64/Opteron]
>> >> Miscellaneous Control [1022:1103]
>> >
>> > Thank you. I guess you are referring to [1].
>> >
>> > Is it possible that you can test patches to complete the port?
>
>> of course!
>> i'd love to help but i have to buy some things before (empty chip,
>> nullmodem cable etc.).
>> i don't want break my desktop :D
>
> That is a good idea. We will be glad to hear from you, when you got your
> stuff and you are all setup. Santa must have been distracted that he did
> not get these things for you for Christmas. ;-)
>
>> yep refer to [1].
>
>> > [1] http://www.coreboot.org/pipermail/coreboot/2007-October/026410.html
>
>
> Thanks,
>
> Paul
>
>
> PS: Christian, are you knew to the project? If yes and you have time,
> could you tell us if you could find everything on the project's Web site
> or could something be improved by for example rearranging or putting
> into the FAQ?
>
> --
> coreboot mailing list: coreboot at coreboot.org
> http://www.coreboot.org/mailman/listinfo/coreboot
>

ok.. i've my backup ICs, PLCC extractor and a nullmodem cable :)
first test failed :/
i've used the lastest svn rev. with the m2n-sli-deluxe patch, as payload i've
defined /dev/zero (because i just want test the bios before i test
everything else).

after poweron followed directly and automatic a poweroff so i think it
isn't right.
i tried it again and no poweroff but a black screen (i use a PCIE graphics card
here with DVI dunno if that makes any differences).

it would be fine if we could get together in #coreboot :)



From fengyuning1984 at gmail.com  Fri Jan  2 14:45:02 2009
From: fengyuning1984 at gmail.com (FENG Yu Ning)
Date: Fri, 2 Jan 2009 21:45:02 +0800
Subject: [coreboot] [RFC]flashrom: improve basic design
In-Reply-To: <5aa83cac3ed645e64d104807af365806@imap.1and1.com>
References: <a505dc9d0901010221m7b564228tbb5bf1f80818ed6a@mail.gmail.com>
	<5aa83cac3ed645e64d104807af365806@imap.1and1.com>
Message-ID: <a505dc9d0901020545y4ee178a8rf72091682632875a@mail.gmail.com>

On Fri, Jan 2, 2009 at 12:20 PM, Joseph Smith <joe at settoplinux.org> wrote:
> This would be a big flashrom change though, and a considerable
> amount of work.

I realize that. I think of it as a branch.

> Have you put together a patch for review yet?

Not coding yet. I am not sure how good/bad the idea is. I'd like to
gather some feedback before doing more work.

yu ning



From paulepanter at users.sourceforge.net  Fri Jan  2 16:24:56 2009
From: paulepanter at users.sourceforge.net (Paul Menzel)
Date: Fri, 02 Jan 2009 16:24:56 +0100
Subject: [coreboot] wiki page for Asus M2A-VM
In-Reply-To: <20090102005827.11367.qmail@stuge.se>
References: <49487459.7060209@gmx.net> <49506040.5070805@gmx.net>
	<4950ED85.60205@gmx.net> <49583FD5.2010806@gmx.net>
	<1230632371.4269.16.camel@mattotaupa.wohnung.familie-menzel.net>
	<495A011C.9050208@gmx.net>
	<1230636643.4269.19.camel@mattotaupa.wohnung.familie-menzel.net>
	<20090102005827.11367.qmail@stuge.se>
Message-ID: <1230909896.4092.3.camel@mattotaupa.wohnung.familie-menzel.net>

Am Freitag, den 02.01.2009, 01:58 +0100 schrieb Peter Stuge:
> Paul Menzel wrote:
> > Done [1]. If you have time could you please send me or update the
> > ROM chip package (PLCC, DIP32, DIP8, SOIC8)?
> 
> The board has a soldered PLCC LPC flash chip.

Thanks, Peter. Done [1].

Unfortunately the Wiki seems to be an older version, since the links in
the (change) comments are not formated correctly. At least it works in
Wikipedia I think. Also references would be supported directly.

No it is up to Carl-Daniel to announce the port on the main page.


Thanks,

Paul


[1] http://www.coreboot.org/index.php?title=Supported_Motherboards&oldid=7809
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 197 bytes
Desc: Dies ist ein digital signierter Nachrichtenteil
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20090102/76a0159d/attachment.sig>

From paulepanter at users.sourceforge.net  Fri Jan  2 16:31:26 2009
From: paulepanter at users.sourceforge.net (Paul Menzel)
Date: Fri, 02 Jan 2009 16:31:26 +0100
Subject: [coreboot] Linux-Magazin Online: article about coreboot
In-Reply-To: <loom.20081230T194817-31@post.gmane.org>
References: <1230652398.15846.19.camel@mattotaupa.wohnung.familie-menzel.net>
	<loom.20081230T194817-31@post.gmane.org>
Message-ID: <1230910286.4092.6.camel@mattotaupa.wohnung.familie-menzel.net>

Am Dienstag, den 30.12.2008, 19:49 +0000 schrieb Christian Ruppert:
> Paul Menzel <paulepanter <at> users.sourceforge.net> writes:

> > there is an article [1] in German posted by Linux-Magazin Online.

> > [1]
> http://www.linux-magazin.de/news/25c3_coreboot_version_3_gibt_sich_die_ehre (German)

> also a nice video presentation can be found here (but en only, from
> 25C3 meeting):
> ftp://ftp.ccc.de/congress/25c3/pre-release/video_h264_720x576/
> 
> 25c3-2970-en-coreboot_beyond_the_final_frontier.mp4
> 25c3-2970-en-coreboot_beyond_the_final_frontier.mp4.md5
> 25c3-2970-en-coreboot_beyond_the_final_frontier.mp4.torrent

I added both links to the news entry [1].


Thanks,

Paul


[1] http://www.coreboot.org/index.php?title=News&oldid=7810
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 197 bytes
Desc: Dies ist ein digital signierter Nachrichtenteil
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20090102/689d8a8b/attachment.sig>

From c-d.hailfinger.devel.2006 at gmx.net  Fri Jan  2 16:37:13 2009
From: c-d.hailfinger.devel.2006 at gmx.net (Carl-Daniel Hailfinger)
Date: Fri, 02 Jan 2009 16:37:13 +0100
Subject: [coreboot] wiki page for Asus M2A-VM
In-Reply-To: <1230909896.4092.3.camel@mattotaupa.wohnung.familie-menzel.net>
References: <49487459.7060209@gmx.net>
	<49506040.5070805@gmx.net>	<4950ED85.60205@gmx.net>
	<49583FD5.2010806@gmx.net>	<1230632371.4269.16.camel@mattotaupa.wohnung.familie-menzel.net>	<495A011C.9050208@gmx.net>	<1230636643.4269.19.camel@mattotaupa.wohnung.familie-menzel.net>	<20090102005827.11367.qmail@stuge.se>
	<1230909896.4092.3.camel@mattotaupa.wohnung.familie-menzel.net>
Message-ID: <495E34A9.1090201@gmx.net>

On 02.01.2009 16:24, Paul Menzel wrote:
> Am Freitag, den 02.01.2009, 01:58 +0100 schrieb Peter Stuge:
>   
>> Paul Menzel wrote:
>>     
>>> Done [1]. If you have time could you please send me or update the
>>> ROM chip package (PLCC, DIP32, DIP8, SOIC8)?
>>>       
>> The board has a soldered PLCC LPC flash chip.
>>     
>
> Thanks, Peter. Done [1].
>
> Unfortunately the Wiki seems to be an older version, since the links in
> the (change) comments are not formated correctly. At least it works in
> Wikipedia I think. Also references would be supported directly.
>
> Now it is up to Carl-Daniel to announce the port on the main page.
>   

Thanks, I'll test with 4 GB RAM and some USB flash drives and report back.

Regards,
Carl-Daniel

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




From paulepanter at users.sourceforge.net  Fri Jan  2 16:47:09 2009
From: paulepanter at users.sourceforge.net (Paul Menzel)
Date: Fri, 02 Jan 2009 16:47:09 +0100
Subject: [coreboot] Flashrom fails with Kernel 2.6.28
In-Reply-To: <20081226140847.31178.qmail@stuge.se>
References: <200812261409.18056.niels_ole@salscheider-online.de>
	<20081226140847.31178.qmail@stuge.se>
Message-ID: <1230911229.4092.10.camel@mattotaupa.wohnung.familie-menzel.net>

Am Freitag, den 26.12.2008, 15:08 +0100 schrieb Peter Stuge:

> Niels Ole Salscheider wrote:
> > Do you know if there is a change from 2.6.27 to 2.6.28 which could
> > cause this error?
> 
> Please check that your kernel doesn't have CONFIG_STRICT_DEVMEM set,
> as it will stop flashrom from working.
> 
> Another poster reported that CONFIG_X86_PAT will also stop flashrom
> from working. Please try booting with the nopat kernel parameter to
> temporarily disable it.

I added your answer to a new entry in the FAQ [1].


Thanks,

Paul


[1] http://www.coreboot.org/FAQ#Can.27t_mmap_memory_using_.2Fdev.2Fmem:_Invalid_argument
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 197 bytes
Desc: Dies ist ein digital signierter Nachrichtenteil
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20090102/ad5838de/attachment.sig>

From dev at duffd.net  Fri Jan  2 17:53:31 2009
From: dev at duffd.net (Thomas Prochaska)
Date: Fri, 02 Jan 2009 17:53:31 +0100
Subject: [coreboot] Flashrom live CD
Message-ID: <495E468B.3040804@duffd.net>

hi!

i'm currently preparing a first release of the flashrom live cd. i'll 
announce it on this mailing list as soon as it's ready for a first test.

regards
thomas prochaska



From corey.osgood at gmail.com  Fri Jan  2 19:46:29 2009
From: corey.osgood at gmail.com (Corey Osgood)
Date: Fri, 2 Jan 2009 13:46:29 -0500
Subject: [coreboot] Flashrom live CD
In-Reply-To: <495E468B.3040804@duffd.net>
References: <495E468B.3040804@duffd.net>
Message-ID: <dd3c80060901021046y10fdc2faid5fbabafb63d3437@mail.gmail.com>

On Fri, Jan 2, 2009 at 11:53 AM, Thomas Prochaska <dev at duffd.net> wrote:

> hi!
>
> i'm currently preparing a first release of the flashrom live cd. i'll
> announce it on this mailing list as soon as it's ready for a first test.


I look forward to it ;) Any chance a release aimed at USB flash drives or
hard drives might follow?

Thanks,
Corey
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20090102/ddb95220/attachment.html>

From spooky85 at gmail.com  Fri Jan  2 19:51:04 2009
From: spooky85 at gmail.com (Christian Ruppert)
Date: Fri, 2 Jan 2009 19:51:04 +0100
Subject: [coreboot] ASUS M2N-SLI Deluxe
In-Reply-To: <bb492f590901020525t6e3c3daeg5cf024e6b8011d7@mail.gmail.com>
References: <bb492f590812300627y5e3ab793n133d50d3379e07da@mail.gmail.com>
	<1230648997.15846.6.camel@mattotaupa.wohnung.familie-menzel.net>
	<1230650997.15846.15.camel@mattotaupa.wohnung.familie-menzel.net>
	<bb492f590901020525t6e3c3daeg5cf024e6b8011d7@mail.gmail.com>
Message-ID: <bb492f590901021051w60597d57uadd5e79de5b14b99@mail.gmail.com>

ok guys,

a little summary from my side:

i've tried the patch from uwe [1] but there are some issues with the
baud rate and also the same problem as fred [2] had but with a
different output.

the baud problem could be solved with a small workaround: just change
to 57600 in minicom but leave 115200 in the bios source.
uwe wrote then a second patch (see attachment, works with the lastest
svn rev. (remove the old patch before apply the new one)) which fixed
the baud problem and other stuff but not the "poweroff" problem.

my first boot log was:

coreboot-2.0.0.0Fallback Fr 2. Jan 17:10:59 CET 2009 starting...
*sysinfo range: [000cf000,000cf730)
bsp_apicid=00
Enabling routing table for node 00 done.
Enabling UP settings
coherent_ht_finalize
done
core0 started:
started ap apicid:  01
SBLink=00
NC node|link=00
begin msr fid, vid 3107121207110202
Current fid_cur: 0x2, fid_max: 0x11
Requested fid_new: 0x11
FidVid table step fidvid: 0xe
200MHZ step fidvid: 0x10
100MHZ step fidvid: 0x11
end   msr fid, vid 3107120707110211
entering optimize_link_incoherent_ht
sysinfo->link_pair_num=0x1
entering ht_optimize_link
pos=0x8a, unfiltered freq_cap=0x8075
pos=0x8a, filtered freq_cap=0x75
pos=0x52, unfiltered freq_cap=0x807f
pos=0x52, filtered freq_cap=0x7f
freq_cap1=0x75, freq_cap2=0x7f
dev1 old_freq=0x0, freq=0x6, needs_reset=0x1
dev2 old_freq=0x0, freq=0x6, needs_reset=0x1
width_cap1=0x11, width_cap2=0x11
dev1 input ln_width1=0x4, ln_width2=0x4
dev1 input width=0x1
dev1 output ln_width1=0x4, ln_width2=0x4
dev1 input|output width=0x11
old dev1 input|output width=0x11
dev2 input|output width=0x11
old dev2 input|output width=0x11
after ht_optimize_link for link pair 0, reset_needed=0x1
after optimize_link_read_pointers_chain, reset_needed=0x1
mcp55_num:01

uwe told me to remove all useless hardware during these tests but no difference.

i hope that somebody find a solution to get a working bios for this board.

thats all for now.. i'll keep you up2date if something happens.

[1] http://www.coreboot.org/pipermail/coreboot/2007-October/026410.html
[2] http://thread.gmane.org/gmane.linux.bios/45265/focus=45311
-------------- next part --------------
A non-text attachment was scrubbed...
Name: v2_asus_m2n_sli_deluxe_secondtry.patch
Type: text/x-patch
Size: 9520 bytes
Desc: not available
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20090102/e29981a3/attachment.patch>

From joe at settoplinux.org  Fri Jan  2 20:20:36 2009
From: joe at settoplinux.org (Joseph Smith)
Date: Fri, 02 Jan 2009 14:20:36 -0500
Subject: [coreboot] Flashrom live CD
In-Reply-To: <495E468B.3040804@duffd.net>
References: <495E468B.3040804@duffd.net>
Message-ID: <2f51d2bd3fc3ba9d06ef3c4dd419546d@imap.1and1.com>




On Fri, 02 Jan 2009 17:53:31 +0100, Thomas Prochaska <dev at duffd.net> wrote:
> hi!
> 
> i'm currently preparing a first release of the flashrom live cd. i'll
> announce it on this mailing list as soon as it's ready for a first test.
> 
Excellent I am also looking forward to it. Will the sources be available in
case we want to include other coreboot utilities?

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




From dev at duffd.net  Fri Jan  2 20:27:41 2009
From: dev at duffd.net (Thomas Prochaska)
Date: Fri, 02 Jan 2009 20:27:41 +0100
Subject: [coreboot] Flashrom live CD
In-Reply-To: <4EE2C57A6B67478890809A44BBE7D21F@gmgrhkqytb527u>
References: <495E468B.3040804@duffd.net>
	<4EE2C57A6B67478890809A44BBE7D21F@gmgrhkqytb527u>
Message-ID: <495E6AAD.5000602@duffd.net>

hi!

of course. we can refine the iso step by step.
also i thought it would be a good idea to supply different sized versions.
not everyone needs all the packages in the biggest iso and not everyone 
needs a credit-card sized cd.

i already have netcat-openbsd in the package list. is this ok or should 
i change it to the netcat package. the package base is debian lenny main 
(through debian-live).

regards
thomas prochaska

George M. Garner Jr. wrote:
> Thomas,
>
> If you will permit a request, would you kindly include a version of netcat
> on the CD.  This assumes, of course, that there also will be network drivers
> on the CD.
>
> Regards,
>
> George.
>
> -----Original Message-----
> From: coreboot-bounces at coreboot.org [mailto:coreboot-bounces at coreboot.org]
> On Behalf Of Thomas Prochaska
> Sent: Friday, January 02, 2009 11:54 AM
> To: coreboot
> Subject: Re: [coreboot] Flashrom live CD
>
> hi!
>
> i'm currently preparing a first release of the flashrom live cd. i'll
> announce it on this mailing list as soon as it's ready for a first test.
>
> regards
> thomas prochaska
>
>
>
>    




From dev at duffd.net  Fri Jan  2 20:31:48 2009
From: dev at duffd.net (Thomas Prochaska)
Date: Fri, 02 Jan 2009 20:31:48 +0100
Subject: [coreboot] Flashrom live CD
In-Reply-To: <dd3c80060901021046y10fdc2faid5fbabafb63d3437@mail.gmail.com>
References: <495E468B.3040804@duffd.net>
	<dd3c80060901021046y10fdc2faid5fbabafb63d3437@mail.gmail.com>
Message-ID: <495E6BA4.8010305@duffd.net>

hi!

the first release is in the < 185 mb limit. when the core features, 
scripts and so on are mature i want to prepare different sized isos.

regards
thomas prochaska

Corey Osgood wrote:
> On Fri, Jan 2, 2009 at 11:53 AM, Thomas Prochaska <dev at duffd.net 
> <mailto:dev at duffd.net>> wrote:
>
>     hi!
>
>     i'm currently preparing a first release of the flashrom live cd.
>     i'll announce it on this mailing list as soon as it's ready for a
>     first test.
>
>
> I look forward to it ;) Any chance a release aimed at USB flash drives 
> or hard drives might follow?
>
> Thanks,
> Corey
>




From dev at duffd.net  Fri Jan  2 20:38:57 2009
From: dev at duffd.net (Thomas Prochaska)
Date: Fri, 02 Jan 2009 20:38:57 +0100
Subject: [coreboot] Flashrom live CD
In-Reply-To: <2f51d2bd3fc3ba9d06ef3c4dd419546d@imap.1and1.com>
References: <495E468B.3040804@duffd.net>
	<2f51d2bd3fc3ba9d06ef3c4dd419546d@imap.1and1.com>
Message-ID: <495E6D51.6020206@duffd.net>

hi!

it's all free. i haven't done anything like that before. if i make an 
iso with debian-live with just plain debian main repository and code a 
few scripts myself, what do i have to do to avoid legal trouble or to 
just make it right. i want to give this to the community for free but 
don't know if it's better to licence under gpl, lgpl, bsd or release to 
public domain.
where exactly do i have to include licence text or something?

also i use the coreboot logo (slightly altered for the syslinux screen 
[added white space on the top and bottom, scaled]).

regards
thomas prochaska

Joseph Smith wrote:
>
> On Fri, 02 Jan 2009 17:53:31 +0100, Thomas Prochaska<dev at duffd.net>  wrote:
>    
>> hi!
>>
>> i'm currently preparing a first release of the flashrom live cd. i'll
>> announce it on this mailing list as soon as it's ready for a first test.
>>
>>      
> Excellent I am also looking forward to it. Will the sources be available in
> case we want to include other coreboot utilities?
>
>    




From mylesgw at gmail.com  Fri Jan  2 22:36:34 2009
From: mylesgw at gmail.com (Myles Watson)
Date: Fri, 2 Jan 2009 14:36:34 -0700
Subject: [coreboot] ASUS M2N-SLI Deluxe
In-Reply-To: <bb492f590901021051w60597d57uadd5e79de5b14b99@mail.gmail.com>
References: <bb492f590812300627y5e3ab793n133d50d3379e07da@mail.gmail.com><1230648997.15846.6.camel@mattotaupa.wohnung.familie-menzel.net><1230650997.15846.15.camel@mattotaupa.wohnung.familie-menzel.net><bb492f590901020525t6e3c3daeg5cf024e6b8011d7@mail.gmail.com>
	<bb492f590901021051w60597d57uadd5e79de5b14b99@mail.gmail.com>
Message-ID: <DC610B8CCFF44258A4C134F0BE030621@chimp>



> -----Original Message-----
> From: coreboot-bounces+mylesgw=gmail.com at coreboot.org [mailto:coreboot-
> bounces+mylesgw=gmail.com at coreboot.org] On Behalf Of Christian Ruppert
> Sent: Friday, January 02, 2009 11:51 AM
> To: coreboot at coreboot.org
> Subject: Re: [coreboot] ASUS M2N-SLI Deluxe
> 
> ok guys,
> 
> a little summary from my side:
> 
> i've tried the patch from uwe [1] but there are some issues with the
> baud rate and also the same problem as fred [2] had but with a
> different output.
> 
> the baud problem could be solved with a small workaround: just change
> to 57600 in minicom but leave 115200 in the bios source.
> uwe wrote then a second patch (see attachment, works with the lastest
> svn rev. (remove the old patch before apply the new one)) which fixed
> the baud problem and other stuff but not the "poweroff" problem.
> 
> my first boot log was:
> 
> coreboot-2.0.0.0Fallback Fr 2. Jan 17:10:59 CET 2009 starting...
> *sysinfo range: [000cf000,000cf730)
> bsp_apicid=00
> Enabling routing table for node 00 done.
> Enabling UP settings
> coherent_ht_finalize
> done
> core0 started:
> started ap apicid:  01
> SBLink=00
> NC node|link=00
> begin msr fid, vid 3107121207110202
> Current fid_cur: 0x2, fid_max: 0x11
> Requested fid_new: 0x11
> FidVid table step fidvid: 0xe
> 200MHZ step fidvid: 0x10
> 100MHZ step fidvid: 0x11
> end   msr fid, vid 3107120707110211
> entering optimize_link_incoherent_ht
> sysinfo->link_pair_num=0x1
> entering ht_optimize_link
> pos=0x8a, unfiltered freq_cap=0x8075
> pos=0x8a, filtered freq_cap=0x75
> pos=0x52, unfiltered freq_cap=0x807f
> pos=0x52, filtered freq_cap=0x7f
> freq_cap1=0x75, freq_cap2=0x7f
> dev1 old_freq=0x0, freq=0x6, needs_reset=0x1
> dev2 old_freq=0x0, freq=0x6, needs_reset=0x1
> width_cap1=0x11, width_cap2=0x11
> dev1 input ln_width1=0x4, ln_width2=0x4
> dev1 input width=0x1
> dev1 output ln_width1=0x4, ln_width2=0x4
> dev1 input|output width=0x11
> old dev1 input|output width=0x11
> dev2 input|output width=0x11
> old dev2 input|output width=0x11
> after ht_optimize_link for link pair 0, reset_needed=0x1
> after optimize_link_read_pointers_chain, reset_needed=0x1
> mcp55_num:01
> 

It looks like you're getting to the first reset, then that isn't working.
Have you tried commenting out the reset at that point to see how much
farther you get?

The reset is to make the HT optimizations take effect, so it will be slower
but should continue.

Thanks,
Myles




From spooky85 at gmail.com  Sat Jan  3 00:53:58 2009
From: spooky85 at gmail.com (Christian Ruppert)
Date: Sat, 3 Jan 2009 00:53:58 +0100
Subject: [coreboot] ASUS M2N-SLI Deluxe
In-Reply-To: <DC610B8CCFF44258A4C134F0BE030621@chimp>
References: <bb492f590812300627y5e3ab793n133d50d3379e07da@mail.gmail.com>
	<1230648997.15846.6.camel@mattotaupa.wohnung.familie-menzel.net>
	<1230650997.15846.15.camel@mattotaupa.wohnung.familie-menzel.net>
	<bb492f590901020525t6e3c3daeg5cf024e6b8011d7@mail.gmail.com>
	<bb492f590901021051w60597d57uadd5e79de5b14b99@mail.gmail.com>
	<DC610B8CCFF44258A4C134F0BE030621@chimp>
Message-ID: <bb492f590901021553i8eb8f69j3ea18e0ba437a150@mail.gmail.com>

2009/1/2 Myles Watson <mylesgw at gmail.com>:
>
>
>> -----Original Message-----
>> From: coreboot-bounces+mylesgw=gmail.com at coreboot.org [mailto:coreboot-
>> bounces+mylesgw=gmail.com at coreboot.org] On Behalf Of Christian Ruppert
>> Sent: Friday, January 02, 2009 11:51 AM
>> To: coreboot at coreboot.org
>> Subject: Re: [coreboot] ASUS M2N-SLI Deluxe
>>
>> ok guys,
>>
>> a little summary from my side:
>>
>> i've tried the patch from uwe [1] but there are some issues with the
>> baud rate and also the same problem as fred [2] had but with a
>> different output.
>>
>> the baud problem could be solved with a small workaround: just change
>> to 57600 in minicom but leave 115200 in the bios source.
>> uwe wrote then a second patch (see attachment, works with the lastest
>> svn rev. (remove the old patch before apply the new one)) which fixed
>> the baud problem and other stuff but not the "poweroff" problem.
>>
>> my first boot log was:
>>
>> coreboot-2.0.0.0Fallback Fr 2. Jan 17:10:59 CET 2009 starting...
>> *sysinfo range: [000cf000,000cf730)
>> bsp_apicid=00
>> Enabling routing table for node 00 done.
>> Enabling UP settings
>> coherent_ht_finalize
>> done
>> core0 started:
>> started ap apicid:  01
>> SBLink=00
>> NC node|link=00
>> begin msr fid, vid 3107121207110202
>> Current fid_cur: 0x2, fid_max: 0x11
>> Requested fid_new: 0x11
>> FidVid table step fidvid: 0xe
>> 200MHZ step fidvid: 0x10
>> 100MHZ step fidvid: 0x11
>> end   msr fid, vid 3107120707110211
>> entering optimize_link_incoherent_ht
>> sysinfo->link_pair_num=0x1
>> entering ht_optimize_link
>> pos=0x8a, unfiltered freq_cap=0x8075
>> pos=0x8a, filtered freq_cap=0x75
>> pos=0x52, unfiltered freq_cap=0x807f
>> pos=0x52, filtered freq_cap=0x7f
>> freq_cap1=0x75, freq_cap2=0x7f
>> dev1 old_freq=0x0, freq=0x6, needs_reset=0x1
>> dev2 old_freq=0x0, freq=0x6, needs_reset=0x1
>> width_cap1=0x11, width_cap2=0x11
>> dev1 input ln_width1=0x4, ln_width2=0x4
>> dev1 input width=0x1
>> dev1 output ln_width1=0x4, ln_width2=0x4
>> dev1 input|output width=0x11
>> old dev1 input|output width=0x11
>> dev2 input|output width=0x11
>> old dev2 input|output width=0x11
>> after ht_optimize_link for link pair 0, reset_needed=0x1
>> after optimize_link_read_pointers_chain, reset_needed=0x1
>> mcp55_num:01
>>
>
> It looks like you're getting to the first reset, then that isn't working.
> Have you tried commenting out the reset at that point to see how much
> farther you get?
>
> The reset is to make the HT optimizations take effect, so it will be slower
> but should continue.
>
> Thanks,
> Myles
>
>

i commented soft_reset(); in cache_as_ram_auto.c but still the same.



From spooky85 at gmail.com  Sat Jan  3 03:30:49 2009
From: spooky85 at gmail.com (Christian Ruppert)
Date: Sat, 3 Jan 2009 03:30:49 +0100
Subject: [coreboot] ASUS M2N-SLI Deluxe
In-Reply-To: <DC610B8CCFF44258A4C134F0BE030621@chimp>
References: <bb492f590812300627y5e3ab793n133d50d3379e07da@mail.gmail.com>
	<1230648997.15846.6.camel@mattotaupa.wohnung.familie-menzel.net>
	<1230650997.15846.15.camel@mattotaupa.wohnung.familie-menzel.net>
	<bb492f590901020525t6e3c3daeg5cf024e6b8011d7@mail.gmail.com>
	<bb492f590901021051w60597d57uadd5e79de5b14b99@mail.gmail.com>
	<DC610B8CCFF44258A4C134F0BE030621@chimp>
Message-ID: <bb492f590901021830i75449b91ne6a09169c4494703@mail.gmail.com>

now i know where it stops.
i wrote a few debug prints in sothbridge/nvidia/mcp55/mcp55_early_setup_car.c
but don't slap me because i haven't checked all of these variable types %)
anyway.. i hope it help.

the numbers at the beginning of the line are line numbers.

the same log as i posted...
mcp55_num:01

in file src/southbridge/nvidia/mcp55/mcp55_early_setup_car.c:
327: for(j=0; j<mcp55_num; j++)
327: j=0
328: mcp55_early_pcie_setup(0, 0, 10240, 0);
330: setup_resource_map_x_offset(4294923544, 160, 00000000, 0);

332: for(i=0; i<3; i++) { // three SATA
332: i=0
333: setup_resource_map_x_offset(4294923400, 36, 00000000, 0, 0)
332: i=1
333: setup_resource_map_x_offset(4294923400, 36, 00001000, 0, 1)
332: i=2
333: setup_resource_map_x_offset(4294923400, 36, 00002000, 0, 2)

336: busn[j] = 0
337: setup_resource_map_x_offset(ffff5278, 132, 00000000, 0)

347: setup_resource_map_x_offset(ffff5208, 28, 00000000, 0)

_END_

so coreboot doesn't leave 'static void mcp55_early_setup(unsigned
mcp55_num, unsigned *busn, unsigned *devn, unsigned *io_base, unsigned
*pci_e_x)' in mcp55_early_setup_car.c



From svn at coreboot.org  Sat Jan  3 21:48:05 2009
From: svn at coreboot.org (coreboot)
Date: Sat, 03 Jan 2009 20:48:05 -0000
Subject: [coreboot]  #118: Flashrom Makefile improvements
Message-ID: <054.59dd658c9579a750126c8e9a60770984@coreboot.org>

#118: Flashrom Makefile improvements
----------------------------------+-----------------------------------------
   Reporter:  spooky85@?          |          Owner:  somebody
       Type:  task                |         Status:  new     
   Priority:  major               |      Milestone:          
  Component:  flashrom            |        Version:  v2      
   Keywords:                      |   Dependencies:          
Patchstatus:  patch needs review  |  
----------------------------------+-----------------------------------------
 hi guys,

 i wrote a small Makefile patch for flashrom.
 a few improvements and i corrected LD/C-FLAGS usage and link order e.g.
 for --as-needed.

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


From r.marek at assembler.cz  Sat Jan  3 23:04:21 2009
From: r.marek at assembler.cz (Rudolf Marek)
Date: Sat, 03 Jan 2009 23:04:21 +0100
Subject: [coreboot] AMD DBM690T PowerNow table problems
In-Reply-To: <49583EA2.8080903@gmx.net>
References: <49583EA2.8080903@gmx.net>
Message-ID: <495FE0E5.7020503@assembler.cz>

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

Hi,

Here we go.

Its seems that the generated table has wrong conversion for frequency and its
FID representation. In other words the table is OK but the first field is not
consistent with FID and real freq.

invalid freq entries 1000000 kHz vs. 800000

This means that:


                Package (0x06)
                {
                    0x00000320,. <--- here should be 0x3e8
                    0x0000F230,.
                    0x00000064,.
                    0x00000007,.
                    0xE8202F0A,.
                    0x0000030A
                },.

                Package (0x06)
                {
                    0x00000320,.
                    0x0000BB8C,.
                    0x00000064,.
                    0x00000007,.
                    0xE8202C82,.
                    0x00000482
                }


FID is 0A and 02 which means it should be: set to 0x3e8 and 0x320.

I guess it is because your CPU is revF and not revG.

fid_multiplier = ((cpuid1.edx & 0x40) >> 6) * 100;

This line will cause that your CPU has fid_multiplier 0 instead of 100x.
I believe that the multiplier should be always 100. Because revF CPU hav LSB in
FID always 0.

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

iEYEARECAAYFAklf4OMACgkQ3J9wPJqZRNUYlgCcDpdFgUSR/9niTmZscuIxSV96
fBwAn1eweTn8g0YuHfRfJU6xex2tPIE+
=gOpD
-----END PGP SIGNATURE-----



From r.marek at assembler.cz  Sat Jan  3 23:05:12 2009
From: r.marek at assembler.cz (Rudolf Marek)
Date: Sat, 03 Jan 2009 23:05:12 +0100
Subject: [coreboot] P state generator for powernow
In-Reply-To: <495821B2.5000205@gmx.net>
References: <4953F668.2040606@assembler.cz>
	<4956DD96.8090205@gmx.net>	<495738FB.8090504@assembler.cz>
	<495821B2.5000205@gmx.net>
Message-ID: <495FE118.8010805@assembler.cz>

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

> The results definitely look correct. My factory BIOS seems to have
> incorrect values there.

OK

> 
> I was unable to test this, though, because the AMD DBM690T target
> already has code to autogenerate the SSDT which conflicts with manual
> insertion of the results of genpowernow.c.

Aha OK. I will have a look into this.

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

iEYEARECAAYFAklf4RgACgkQ3J9wPJqZRNWHDgCgqQpVkAOqTfXkKmLJrcbBb6TQ
vnIAoK2eZ9i16x5JB9xeeLFfXWcbwg4r
=v7xh
-----END PGP SIGNATURE-----



From r.marek at assembler.cz  Sat Jan  3 23:10:52 2009
From: r.marek at assembler.cz (Rudolf Marek)
Date: Sat, 03 Jan 2009 23:10:52 +0100
Subject: [coreboot] AMD DBM690T PowerNow table problems
In-Reply-To: <495FE0E5.7020503@assembler.cz>
References: <49583EA2.8080903@gmx.net> <495FE0E5.7020503@assembler.cz>
Message-ID: <495FE26C.4030303@assembler.cz>

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

Whoops sorry the 1000 Mhz should be for second entry. First should have 0x708
for 1800Mhz.

It just states 800Mhz (0x320) because the formula is:

frq = FID * 0 + 800

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

iEYEARECAAYFAklf4mwACgkQ3J9wPJqZRNWqggCfR7Y9l0gP83qARvVNnx8SIBRY
g2UAoKNT6XJVV/w3khB4hyV0PbM405l4
=jG9b
-----END PGP SIGNATURE-----



From fengyuning1984 at gmail.com  Sun Jan  4 10:20:44 2009
From: fengyuning1984 at gmail.com (FENG Yu Ning)
Date: Sun, 4 Jan 2009 17:20:44 +0800
Subject: [coreboot] Flash chips and "page" (Was: How to find out "page size"
	of a flash chip?)
Message-ID: <a505dc9d0901040120w164c14a3yc500c12b58f9ffc2@mail.gmail.com>

On 11/19/08, Peter Stuge <peter at stuge.se> wrote:
> The page_size member is considered an eraseblock size by the code.

On Wed, Nov 19, 2008 at 8:36 PM, Carl-Daniel Hailfinger
<c-d.hailfinger.devel.2006 at gmx.net> wrote:
> Yes. We should have one eraseblock_size member and one write_size member.

In the flashchips array, the value of page_size is page size if the
chip has page-write as the only write command. At other times, it is
just a parameter of the memory geometry - maybe erase block size,
maybe not.

I have made some investigation to figure out the above result. I am
attaching it below for convenience of further discussion.

Vendor    Model            Type      Visibleness
-----------------------------------------------------------------------
                           S P  L F   Wr Wp
                             Px       Ar Ap
                             Po          1p
                                         Zp
                                      ?r ?p

S  = SPI

P  = Parallel
     (did not seperate parallel into sub-types when investigating
      those flash chips)

Px = Parallel, using JEDEC Single-Supply EEPROM like Command Set
     (command preceded by addresses and data containing alternated 1
      and 0 bits, i.e., 55, 555, 5555, AA, AAA, 2AA, 2AAA, etc.)

Po = Parallel, without preceded cycles

L  = LPC

F  = FWH

N  = There is no page concept or page is not visible to host.

Wr = Page read can start at any address within a page and will wrap
     back at page boundary in one page read instruction

Wp = Page program can start at any address within a page and will wrap
     back at page boundary in one page program instruction

Ar = Automatically page boundary alignment for page read

Ap = Automatically page boundary alignment for page program

1p = Every byte in a page has to be specified in one page program
     instruction

Zp = Page address is determined by the address of the last data to be
     programmed.

?r = Host should guarantee page address consistency when reading. How
     the flash chip behaves when inconsistency happens is unknown.

?p = Host should guarantee page address consistency when page
     programming. How the flash chip behaves when inconsistency
     happens is unknown.

Vendor    Model            Type      Visibleness
-----------------------------------------------------------------------
AMD       Am29F002         - Px - -   -  -
          Am29F016D        - Px - -   -  -

ATMEL     AT25DF021        S - - -   -  Wp
          AT25F512B        S - - -   -  Wp
          AT25FS010        S - - -   -  Wp
          AT26DF041        S - - -   -  Wp
          AT26F004         S - - -   -  -
          AT29C020         - - - -   -  1p
          AT45CS1282       S - - -   Wr Wp
          AT45DB011D       S - - -   Wr Wp
          AT49F002(N)(T)   - P - -   -  -

AMIC      A25L40P          S - - -   -  Wp
          A29002(1)        - P - -   -  -
          A29040B          - P - -   -  -
          A49LF040A        - - L -   -  -

EMST      F49B002UA        - P - -   -  -

EON       EN29F002(N)      - P - -   -  -

Fujitsu   MBM29F004BC/TC   - P - -   -  -
          MBM29F400BC/TC   - P - -   -  -

Intel     82802AB/AC       - - - F   -  -

Macronix  MX25L512         S - - -   -  Wp
          MX25L1005        S - - -   -  Wp
          MX29F002(N)T/B   - P - -   -  -
          MX29LV040C       - P - -   -  -

Numonyx   M25PE10/20       S - - -   -  Wp

PMC       Pm25LV512A       S - - -   -  Wp
          Pm25LV010A       S - - -   -  Wp
          Pm25LV020        S - - -   -  Wp
          Pm25LV040        S - - -   -  Wp
          Pm25LV080B/016B  S - - -   -  Wp
          Pm49FL002/004    - - L F   -  -

Sharp     LHF00L04         - - - F   ?r -

Spansion  S25FL016A        S - - -   -  ?p

SST       SST25VF040B      S - - -   -  -
          SST25VF080B      S - - -   -  -
          SST25VF016B      S - - -   -  -
          SST25VF032B      S - - -   -  -
          SST28SF040A      - - - -   -  -
          SST29EE010       - P - -   -  Zp
          SST29LE010       - P - -   -  Zp
          SST29VE010       - P - -   -  Zp
          SST29EE020A      - P - -   -  Zp
          SST29LE020A      - P - -   -  Zp
          SST29VE020A      - P - -   -  Zp
          SST39SF010A      - P - -   -  -
          SST39SF020A      - P - -   -  -
          SST39SF040       - P - -   -  -
          SST39VF512       - P - -   -  -
          SST39VF010       - P - -   -  -
          SST39VF020       - P - -   -  -
          SST39VF040       - P - -   -  -
          SST49LF002A      - P - F   -  -
          SST49LF003A      - P - F   -  -
          SST49LF004A      - P - F   -  -
          SST49LF008A      - P - F   -  -
          SST49LF002B      - P L F   -  -
          SST49LF003B      - P L F   -  -
          SST49LF004B      - P L F   -  -
          SST49LF004C      - - - F   -  Ap
          SST49LF008C      - - - F   -  Ap
          SST49LF016C      - - - F   -  Ap
          SST49LF020A      - P L -   -  -
          SST49LF040       - P L -   -  -
          SST49LF040B      - P L -   -  -
          SST49LF080A      - P L -   -  -
          SST49LF160C      - - L -   -  Ap

ST        M25P05-A         S -  - -   -  Wp
          M25P10-A         S -  - -   -  Wp
          M25P20           S -  - -   -  Wp
          M25P40           S -  - -   -  Wp
          M25P80           S -  - -   -  Wp
          M25P16           S -  - -   -  Wp
          M25P32           S -  - -   -  Wp
          M25P64           S -  - -   -  Wp
          M25P128          S -  - -   -  Wp
          M29F002T/NT/B    - Px - -   -  -
          M29F040B         - Px - -   -  -
          M29F400BT        - Px - -   -  -
          M29W010B         - Px - -   -  -
          M29W040B         - Px - -   -  -
          M50FLW040A/B     - -  L F   Ar -
          M50FLW080A/B     - -  L F   Ar -
          M50FW002         - Po - F   -  -
          M50FW040         - Po - F   -  -
          M50FW080         - Po - F   -  -
          M50LPW116        - Po L -   -  -

SyncMOS   S29C31004T       - Px - -   -  -
          S29C51001T       - Px - -   -  -
          S29C51002T       - Px - -   -  -
          S29C51004T       - Px - -   -  -

Winbond   W25x10           S -  - -   -  Wp
          W25x20           S -  - -   -  Wp
          W25x40           S -  - -   -  Wp
          W25x80           S -  - -   -  Wp
          W29C011A         - Px - -   -  ?p
          W29C020C         - Px - -   -  ?p
          W29C040          - Px - -   -  ?p
          W29EE011         - Px - -   -  ?p
          W39V040A         - Px L -   -  -
          W39V040B         - Px L -   -  -
          W39V040C         - Px L -   -  -
          W39V040FA        - Px - F   -  -
          W39V080A         - Px L -   -  -
          W49F002U         - Px - -   -  -
          W49V002A         - Px L -   -  -
          W49V002FA        - Px - F   -  -
          W39V080FA        - Px - F   -  -
-------------- next part --------------
A non-text attachment was scrubbed...
Name: page
Type: application/octet-stream
Size: 6345 bytes
Desc: not available
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20090104/d158f3c7/attachment.obj>

From r.marek at assembler.cz  Sun Jan  4 12:36:45 2009
From: r.marek at assembler.cz (Rudolf Marek)
Date: Sun, 04 Jan 2009 12:36:45 +0100
Subject: [coreboot] [RFC] Netbook Support
In-Reply-To: <49491B85.9080808@gmail.com>
References: <49430370.4020508@onelabs.com>	<dd3c80060812121657p7e902672x92fc00e557829a6@mail.gmail.com>	<49431788.3000107@onelabs.com>	<13426df10812122157s30c4ad72ycde1716792c066a8@mail.gmail.com>	<4943DF6B.7080901@cosmicpenguin.net>	<494411BE.1000104@gmx.net>	<494471A7.6000801@gmail.com>
	<4944BA6F.6030005@onelabs.com> <49491B85.9080808@gmail.com>
Message-ID: <49609F4D.6080602@assembler.cz>

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

Hi all,

> do end up needed to did deeper and you can't get any info from the
> manufacturer then EnE is your best bet for reverse engineering.


I have taken a BIOS from Mini A110 (q1d25i.rom). The Quanta IL1 reference design
seems to use ENE3310 controller. The q1d25i.rom was examined. The EC code is on
0xFFF00000 length is 64KB. The file is called HOLE0.ROM inside BIOS.

The ENE KB3310 seems to be similar to ENE KB3920, which datasheet I found via
google.

I have taken IDA and did the LST file. It has 8051 inside. Yesterday I spoke
with Bari and got the s51 emulator from (SVN:
https://sdcc.svn.sourceforge.net/svnroot/sdcc/trunk).

I fixed the serial port issue, and now the firmware runs inside emulator:

Serial output:
00,
ec[ECFV]==80ac
wake at z,ACOut
Zttttttttttttttttttttttttttt

It prints 't' every second or so.

It seems that a flash can be flashed even unsoldered via serial interface of EC.
(some other pins must be pulled low)

http://laptop.org/teamwiki/images/e/e5/SPI_Recovery.pdf

Here is a EC schematics from reference design.
http://laptop.org/teamwiki/images/f/fe/CL1_A1A.pdf


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

iEYEARECAAYFAklgn0kACgkQ3J9wPJqZRNVm/ACfYiWUWPguSNInUiwNpMA8BsSD
EQUAnjfRJe0rxt3WNKkqkyXRhiqQfsTZ
=rLzw
-----END PGP SIGNATURE-----



From spooky85 at gmail.com  Sun Jan  4 14:38:24 2009
From: spooky85 at gmail.com (Christian Ruppert)
Date: Sun, 4 Jan 2009 14:38:24 +0100
Subject: [coreboot] releases and snapshots?
Message-ID: <bb492f590901040538x2704bf59he6bf1be8dab296bc@mail.gmail.com>

Peter Stuge <peter <at> stuge.se> writes:
>
> On Fri, May 16, 2008 at 09:54:38PM +0300, Andriy Gapon wrote:
> > Does coreboot project produce any release or snapshots of its code?
>
> So far there has not been a single release of anything.
>
> Snapshots are published on http://qa.coreboot.org/ for each commit.
>
> > Especially I am interested in flashrom.
>
> Please hold on. flashrom-1.0 will be released Real Soon Now.
> It's already a few weeks past my release deadline, but on the other
> hand a number of very nice patches have been included in this time.
>
> > I mean, is using svn checkout the only way to get the sources?
>
> Not at all.
>
> But I am looking forward to the flashrom release very much, and I
> would like some coreboot releases too.
>
> For some reason, it feels more difficult to make a coreboot release..
>
> //Peter

how about the the release/status?
i'd like to see a tag in svn or even an archive :)
that would be useful e.g. for distribution packages :P



From spooky85 at gmail.com  Sun Jan  4 17:32:47 2009
From: spooky85 at gmail.com (Christian Ruppert)
Date: Sun, 4 Jan 2009 17:32:47 +0100
Subject: [coreboot] ASUS M2N-SLI Deluxe
In-Reply-To: <bb492f590901021830i75449b91ne6a09169c4494703@mail.gmail.com>
References: <bb492f590812300627y5e3ab793n133d50d3379e07da@mail.gmail.com>
	<1230648997.15846.6.camel@mattotaupa.wohnung.familie-menzel.net>
	<1230650997.15846.15.camel@mattotaupa.wohnung.familie-menzel.net>
	<bb492f590901020525t6e3c3daeg5cf024e6b8011d7@mail.gmail.com>
	<bb492f590901021051w60597d57uadd5e79de5b14b99@mail.gmail.com>
	<DC610B8CCFF44258A4C134F0BE030621@chimp>
	<bb492f590901021830i75449b91ne6a09169c4494703@mail.gmail.com>
Message-ID: <bb492f590901040832j18042c9fie575010cdd6973d8@mail.gmail.com>

i tested it again with RES_DEBUG and CONFIG_USE_PRINTK_IN_CAR.

coreboot-2.0.0.0Fallback Sun Jan  4 15:15:44 CET 2009 starting...
*sysinfo range: [000cf000,000cf730)
bsp_apicid=00
Enabling routing table for node 00 done.
Enabling UP settings
coherent_ht_finalize
done
core0 started:
started ap apicid:  01
SBLink=00
NC node|link=00
begin msr fid, vid 3107121207110202
Current fid_cur: 0x2, fid_max: 0x11
Requested fid_new: 0x11
FidVid table step fidvid: 0xe
200MHZ step fidvid: 0x10
100MHZ step fidvid: 0x11
end   msr fid, vid 3107120707110211
entering optimize_link_incoherent_ht
sysinfo->link_pair_num=0x1
entering ht_optimize_link
pos=0x8a, unfiltered freq_cap=0x8075
pos=0x8a, filtered freq_cap=0x75
pos=0x52, unfiltered freq_cap=0x807f
pos=0x52, filtered freq_cap=0x7f
freq_cap1=0x75, freq_cap2=0x7f
dev1 old_freq=0x0, freq=0x6, needs_reset=0x1
dev2 old_freq=0x0, freq=0x6, needs_reset=0x1
width_cap1=0x11, width_cap2=0x11
dev1 input ln_width1=0x4, ln_width2=0x4
dev1 input width=0x1
dev1 output ln_width1=0x4, ln_width2=0x4
dev1 input|output width=0x11
old dev1 input|output width=0x11
dev2 input|output width=0x11
old dev2 input|output width=0x11
after ht_optimize_link for link pair 0, reset_needed=0x1
after optimize_link_read_pointers_chain, reset_needed=0x1
mcp55_num:01

181: from mcp55_early_setup_car.c:static void mcp55_early_setup()
327: for(j=0; j<mcp55_num; j++)
327: j=0
328: mcp55_early_pcie_setup();
330: setup_resource_map_x_offset();

setting up resource map ex offset....
0000: 20 00002010 <- & 0007ffff | 0ff78000
0001: 20 000020a4 <- & ffedffff | 00012000
0002: 20 000020ac <- & fffffdff | 00000200
0003: 20 000020b4 <- & fffffffd | 00000002
0004: 20 00002824 <- & c0f0f08f | 26020230
0005: 20 00002834 <- & 00000000 | 22222222
0006: 20 00002808 <- & 7fffffff | 00000000
0007: 20 0000282c <- & 7fffffff | 80000000
0008: 20 000028cc <- & fffff9ff | 00000000
0009: 20 00002830 <- & 8fffffff | 40000000
000a: 20 000028cc <- & fffff9ff | 00000200
000b: 20 00002830 <- & 8fffffff | 40000000
000c: 20 000028cc <- & fffff9ff | 00000400
000d: 20 00002830 <- & 8fffffff | 40000000
000e: 20 00002874 <- & ffff0ff5 | 0000f000
000f: 20 00002878 <- & ff00ff00 | 00100010
0010: 20 0000287c <- & ff0ff0ff | 00500500
0011: 20 00002880 <- & ffffffe7 | 00000000
0012: 20 00002860 <- & ffcfffff | 00300000
0013: 20 00002890 <- & ffff00ff | 0000ff00
0014: 20 0000289c <- & ff00ffff | 00070000
0015: 10 00000040 <- & 00000000 | cb8410de
0016: 10 00000048 <- & ffffdced | 00002002
0017: 10 00000078 <- & ffffff8e | 00000011
0018: 10 00000080 <- & ffff0000 | 00009923
0019: 10 00000088 <- & fffffffe | 00000000
001a: 10 0000008c <- & ffff0000 | 0000007f
001b: 10 000000dc <- & fffeffff | 00010000
001c: 10 00008040 <- & 00000000 | cb8410de
001d: 10 00008074 <- & ffffff7b | 00000084
001e: 10 000080f8 <- & ffffffcf | 00000010
001f: 10 000090c4 <- & fffffffe | 00000001
0020: 10 000090f0 <- & 7ffffffd | 00000002
0021: 10 000090f8 <- & ffffffcf | 00000010
0022: 10 00040040 <- & 00000000 | cb8410de
0023: 10 00040068 <- & ffffff00 | 000000ff
0024: 10 000400f8 <- & ffffffbf | 00000040
0025: 10 00048040 <- & 00000000 | cb8410de
0026: 10 00048068 <- & ffffff00 | 000000ff
0027: 10 000480f8 <- & ffffffbf | 00000040
done.

332: for(i=0; i<3; i++) { // three SATA
332: i=0
333: setup_resource_map_x_offset()

setting up resource map ex offset....
0000: 10 00028040 <- & 00000000 | cb8410de
0001: 10 00028050 <- & fffffffc | 00000003
0002: 10 00028064 <- & fffffffe | 00000001
0003: 10 00028070 <- & fff0ffff | 00040000
0004: 10 000280ac <- & fffff0ff | 00000100
0005: 10 0002807c <- & ffffffef | 00000000
0006: 10 000280c8 <- & ff00ff00 | 000a000a
0007: 10 000280d0 <- & f0ffffff | 03000000
0008: 10 000280e0 <- & f0ffffff | 03000000
done.

332: i=1
333: setup_resource_map_x_offset()

setting up resource map ex offset....
0000: 10 00029040 <- & 00000000 | cb8410de
0001: 10 00029050 <- & fffffffc | 00000003
0002: 10 00029064 <- & fffffffe | 00000001
0003: 10 00029070 <- & fff0ffff | 00040000
0004: 10 000290ac <- & fffff0ff | 00000100
0005: 10 0002907c <- & ffffffef | 00000000
0006: 10 000290c8 <- & ff00ff00 | 000a000a
0007: 10 000290d0 <- & f0ffffff | 03000000
0008: 10 000290e0 <- & f0ffffff | 03000000
done.

332: i=2
333: setup_resource_map_x_offset()

setting up resource map ex offset....
0000: 10 0002a040 <- & 00000000 | cb8410de
0001: 10 0002a050 <- & fffffffc | 00000003
0002: 10 0002a064 <- & fffffffe | 00000001
0003: 10 0002a070 <- & fff0ffff | 00040000
0004: 10 0002a0ac <- & fffff0ff | 00000100
0005: 10 0002a07c <- & ffffffef | 00000000
0006: 10 0002a0c8 <- & ff00ff00 | 000a000a
0007: 10 0002a0d0 <- & f0ffffff | 03000000
0008: 10 0002a0e0 <- & f0ffffff | 03000000
done.

336: busn[j] = 0
337: setup_resource_map_x_offset()

setting up resource map ex offset....
0000: 10 00009040 <- & 00000000 | cb8410de
0001: 10 000090e0 <- & fffffeff | 00000000
0002: 10 000090e4 <- & fffffffb | 00000000
0003: 10 000090e8 <- & ffa9c8ff | 00003000
0004: 10 00020040 <- & 00000000 | cb8410de
0005: 10 000200f8 <- & ffffffcf | 00000010
0006: 10 00010040 <- & 00000000 | cb8410de
0007: 10 00011040 <- & 00000000 | cb8410de
0008: 10 00011064 <- & f87fffff | 05000000
0009: 10 00011078 <- & ffc07fff | 00360000
000a: 10 00011068 <- & fe00d03f | 013f2c00
000b: 10 00011070 <- & fff7ffff | 00080000
000c: 10 0001107c <- & fffff00f | 00000570
000d: 10 000110f8 <- & ffffffcf | 00000010
000e: 10 00030004 <- & fffffefb | 00000104
000f: 10 0003003c <- & f5ffffff | 0a000000
0010: 10 00030040 <- & 00c8ffff | 07330000
0011: 10 00030048 <- & fffffff8 | 00000005
0012: 10 0003004c <- & fe02ffff | 004c0000
0013: 10 00030074 <- & ffffffc0 | 00000000
0014: 10 000300c0 <- & 00000000 | cb8410de
0015: 10 000300c4 <- & fffffff8 | 00000007
0016: 10 00008078 <- & c0ffffff | 19000000
0017: 10 00031040 <- & 00000000 | cb8410de
0018: 22 000024e5 <- & 00000000 | 00000044
0019: 22 000024e6 <- & 00000000 | 00000044
001a: 22 000024e7 <- & 00000000 | 00000044
001b: 22 000024e8 <- & 00000000 | 00000044
001c: 22 000024fb <- & 00000000 | 00000060
001d: 22 000024fc <- & 00000000 | 00000060
001e: 22 000024d5 <- & fffffff3 | 00000008
001f: 22 000024d6 <- & fffffff3 | 00000008
0020: 22 000024ee <- & fffffff3 | 00000008
done.

346: setup_resource_map_x_offset()

setting up resource map ex offset....
0000: 10 00000074 <- & fffff00f | 000009d0
0001: 10 00008074 <- & ffff7fff | 00008000
0002: 20 00002448 <- & fffeffff | 00010000
0003: 20 00002860 <- & ffffff00 | 00000012
0004: 10 000090e4 <- & ffafffff | 00500000
0005: 22 000024c4 <- & ffffff00 | 00000004
0006: 22 000024c4 <- & ffffff00 | 00000005



From svens at stackframe.org  Sun Jan  4 20:11:57 2009
From: svens at stackframe.org (Sven Schnelle)
Date: Sun, 04 Jan 2009 20:11:57 +0100
Subject: [coreboot] [PATCH] flashrom: add SST49LF020 support
Message-ID: <877i5ahon6.fsf@apollo.stackframe.org>

Hi List,

i've added support for the SST 49LF020 Flash chip to flashrom. Basically
only the device Id differs, the programming algorithm seems to be the
same as for SST 49LF020A.

I've only tested read so far, i'm a bit reluctant to test
erase/programming without a backup BIOS chip :)

Index: flash.h
===================================================================
--- flash.h	(revision 3845)
+++ flash.h	(working copy)
@@ -356,6 +356,7 @@
 #define SST_39VF040		0xD7
 #define SST_49LF040B		0x50
 #define SST_49LF040		0x51
+#define SST_49LF020            0x61
 #define SST_49LF020A		0x52
 #define SST_49LF080A		0x5B
 #define SST_49LF002A		0x57
Index: flashchips.c
===================================================================
--- flashchips.c	(revision 3845)
+++ flashchips.c	(working copy)
@@ -626,6 +626,12 @@
 	 probe_49lfxxxc, erase_49lfxxxc, write_49lfxxxc
 	},
 
+	{"SST", "SST49LF020", SST_ID, SST_49LF020,
+	 256, 16 * 1024,
+	 TEST_UNTESTED,
+	 probe_jedec, erase_49lf040, write_49lf040
+	},
+
 	{"SST", "SST49LF020A", SST_ID, SST_49LF020A,
 	 256, 16 * 1024,
 	 TEST_UNTESTED,




From svens at stackframe.org  Sun Jan  4 20:16:06 2009
From: svens at stackframe.org (Sven Schnelle)
Date: Sun, 04 Jan 2009 20:16:06 +0100
Subject: [coreboot] [PATCH] flashrom: add AMD-768 chipset support
Message-ID: <871vvihog9.fsf@apollo.stackframe.org>

Hi List,

the patch attached adds support for the AMD-768 chipset.

Signed-off-by: Sven Schnelle <svens at stackframe.org>

Index: chipset_enable.c
===================================================================
--- chipset_enable.c	(revision 3845)
+++ chipset_enable.c	(working copy)
@@ -114,6 +114,19 @@
 	return 0;
 }
 
+static int enable_flash_amd768(struct pci_dev *dev, const char *name)
+{
+	/* enable address decoding for LPC */
+	pci_write_byte(dev, 0x40, pci_read_byte(dev, 0x40) | 0x01);
+	pci_write_byte(dev, 0x43, 0xbf);
+
+	return 0;
+}
+
 /* Datasheet:
  *   - Name: 82371AB PCI-TO-ISA / IDE XCELERATOR (PIIX4)
  *   - URL: http://www.intel.com/design/intarch/datashts/290562.htm
@@ -937,6 +950,7 @@
 	{0x1002, 0x4377, "ATI SB400",		enable_flash_sb400},
 	{0x1166, 0x0205, "Broadcom HT-1000",	enable_flash_ht1000},
 	{0x1022, 0x3000, "AMD Elan SC520",	get_flashbase_sc520},
+	{0x1022, 0x7440, "AMD AMD-768",         enable_flash_amd768},
 };
 
 void print_supported_chipsets(void)



From svens at stackframe.org  Sun Jan  4 22:10:00 2009
From: svens at stackframe.org (Sven Schnelle)
Date: Sun, 04 Jan 2009 22:10:00 +0100
Subject: [coreboot] [PATCH] flashrom: add i631x LPC support
Message-ID: <87ljtq7p7b.fsf@apollo.stackframe.org>

Hi List,

this patch adds support for the Intel i631x Chipset.

Signed-off-by: Sven Schnelle <svens at stackframe.org>

Index: chipset_enable.c
===================================================================
--- chipset_enable.c	(revision 3845)
+++ chipset_enable.c	(working copy)
@@ -804,6 +804,12 @@
 	return 0;
 }

+static int enable_flash_i631x(struct pci_dev *dev, const char *name)
+{
+	pci_write_byte(dev, 0xdc, pci_read_byte(dev, 0xdc) | 0x01);
+	return 0;
+}
+
 /**
  * Usually on the x86 architectures (and on other PC-like platforms like some
  * Alphas or Itanium) the system flash is mapped right below 4G. On the AMD
@@ -937,4 +943,5 @@
 	{0x1002, 0x4377, "ATI SB400",		enable_flash_sb400},
 	{0x1166, 0x0205, "Broadcom HT-1000",	enable_flash_ht1000},
 	{0x1022, 0x3000, "AMD Elan SC520",	get_flashbase_sc520},
+	{0x8086, 0x2670, "Intel 631xESB/632xESB/3100",         enable_flash_i631x},
 };

 void print_supported_chipsets(void)




From c-d.hailfinger.devel.2006 at gmx.net  Mon Jan  5 01:21:22 2009
From: c-d.hailfinger.devel.2006 at gmx.net (Carl-Daniel Hailfinger)
Date: Mon, 05 Jan 2009 01:21:22 +0100
Subject: [coreboot] Flash chips and "page" (Was: How to find out "page
 size"	of a flash chip?)
In-Reply-To: <a505dc9d0901040120w164c14a3yc500c12b58f9ffc2@mail.gmail.com>
References: <a505dc9d0901040120w164c14a3yc500c12b58f9ffc2@mail.gmail.com>
Message-ID: <49615282.5080408@gmx.net>

On 04.01.2009 10:20, FENG Yu Ning wrote:
> On 11/19/08, Peter Stuge <peter at stuge.se> wrote:
>   
>> The page_size member is considered an eraseblock size by the code.
>>     
>
> On Wed, Nov 19, 2008 at 8:36 PM, Carl-Daniel Hailfinger
> <c-d.hailfinger.devel.2006 at gmx.net> wrote:
>   
>> Yes. We should have one eraseblock_size member and one write_size member.
>>     
>
> In the flashchips array, the value of page_size is page size if the
> chip has page-write as the only write command. At other times, it is
> just a parameter of the memory geometry - maybe erase block size,
> maybe not.
>
> I have made some investigation to figure out the above result. I am
> attaching it below for convenience of further discussion.
>
> Vendor    Model            Type      Visibleness
> -----------------------------------------------------------------------
>                            S P  L F   Wr Wp
>                              Px       Ar Ap
>                              Po          1p
>                                          Zp
>                                       ?r ?p
>
> S  = SPI
>
> P  = Parallel
>      (did not seperate parallel into sub-types when investigating
>       those flash chips)
>
> L  = LPC
>
> F  = FWH
>
> Wr = Page read can start at any address within a page and will wrap
>      back at page boundary in one page read instruction
>   


Almost all SPI chips wrap at chip boundary for reads, not page boundary.
Some LPF/FWH chips do the same.


> Wp = Page program can start at any address within a page and will wrap
>      back at page boundary in one page program instruction
>   

Program wraparound (chip/page) not only depends on the chip, but also on
the programming mode. Once we introduce drivers for external flashers,
this becomes important.

We need multiple tuples of
erase function <-> erase block size <-> access mode
write function <-> write block size <-> access mode
read function <-> read block size <-> access mode

For a chip supporting multiple erase functions, this means we need
multiple erase function <-> erase block size pairs.

And each function also needs to be annotated with the access method
(LPC/FWH/SPI/special AAI/...) so that flashrom can decide on whether a
given flash function is usable with the available hardware. For example,
an external flasher may be able to use AAI mode, whereas this is
generally not possible (exceptions may apply) for in-circuit flashing
(which is used by flashrom right now).


Regards,
Carl-Daniel

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




From c-d.hailfinger.devel.2006 at gmx.net  Mon Jan  5 02:27:22 2009
From: c-d.hailfinger.devel.2006 at gmx.net (Carl-Daniel Hailfinger)
Date: Mon, 05 Jan 2009 02:27:22 +0100
Subject: [coreboot] [RFC]flashrom: improve basic design
In-Reply-To: <a505dc9d0901010221m7b564228tbb5bf1f80818ed6a@mail.gmail.com>
References: <a505dc9d0901010221m7b564228tbb5bf1f80818ed6a@mail.gmail.com>
Message-ID: <496161FA.8090308@gmx.net>

Hi Yu Ning,

thanks for yor design proposal.

I really like some stuff in there, especially the suggestion to couple
probe functions and associated IDs. I have a patch for this somewhere, I
need to dig it up and resend.

Unfortunately, other parts of the proposed abstraction level will make
it harder to understand chip drivers, especially for people who just
want to contribute support for one of their own chips.

There are a few ways out, but none of them makes me completely happy.
1. Put all flash chip data in a text/xml/whatever file and feed flash
chip drivers with that data. This has the advantage of separating
flashrom code from actual chip definitions and makes it possible to add
support for new chips without recompiling just by exchanging a text
file. While XML may sound cool, it is definitely a big chunk of code and
we'll lose if we ever try to put flashrom in the ROM. This is equivalent
to a complete rewrite of flashrom from scratch.
2. Convert chip drivers to use accessor functions for reads and writes.
The SPI code already does that and needs no changes to support external
programmers.
3. Some new way to solve all this.


On 01.01.2009 11:21, FENG Yu Ning wrote:
> There is a defect in basic design of flashrom. It leads to problems
> some developers are facing or going to face. A partial solution is
> proposed.
>
> 1. The Defect
>
> struct flashchip {
>
>         /* ... */
>
> 	int (*probe) (struct flashchip *flash);
> 	int (*erase) (struct flashchip *flash);
> 	int (*write) (struct flashchip *flash, uint8_t *buf);
> 	int (*read) (struct flashchip *flash, uint8_t *buf);
>
>         /* ... */
>
> };
>
> The struct specifies drivers for operations. It is a good design if
> the drivers deal with flash chips directly and provide interfaces for
> upper layer program to use. However, those drivers deal with every
> component in the communication chain. They do not fit into a structure
> storing information closely related to flash chips.
>
>
> 2. Problems
>
> Supporting non-standard flash chips needs to write a new driver. It
> requires the developer to be familiar with the internals of flashrom.
>
> Probe functions and IDs are seperated. They are associated by the
> flashchip structure. In nature, probe functions and IDs are questions
> and answers, and should be associated more closely. Seperated ID
> fields in struct flashchip are not very meaningful.
>
> flashrom will probably have plugins in the future. Though chips are
> operated in the same way from the view of their host devices, there is
> not much useful information for plugins in struct flashchip.
>
>
> 3. Solution
>
> We need an abstract specification of operations in struct flashchip,
> not actual code. If there have to be some information not related to
> flash chips, the less there is, the better.
>
> Abstract operation specification for SPI flash chips:
>
> /* BEGINNING OF SPECIFICATION */
>
> struct cycles {
>         u8 type;	/* CYCLETYPE_PREOPCODE, CYCLETYPE_OPCODE, */
> 	   		/* CYCLETYPE_ADDRESS, CYCLETYPE_DUMMY,	  */
> 			/* CYCLETYPE_DATA_IN, CYCLETYPE_DATA_OUT  */
>         u8 length;	/* in bytes */
> 	u8 value_type;	/* VALUETYPE_VARIABLE, VALUETYPE_FIXED	  */
> 	u32 value;
> };
>
> struct cycles byte_read[] =
>         {{CYCLETYPE_OPCODE, 1, VALUETYPE_FIXED, 0x3},
>        	 {CYCLETYPE_ADDRESS, 3, VALUETYPE_VARIABLE},
> 	 {CYCLETYPE_DATA_IN, 1, VALUETYPE_VARIABLE}
> 	};
>
> struct cycles byte_program[] =
>         {{CYCLETYPE_PREOPCODE, 1, VALUETYPE_FIXED, 0x6},
> 	 {CYCLETYPE_OPCODE, 1, VALUETYPE_FIXED, 0x2},
>        	 {CYCLETYPE_ADDRESS, 3, VALUETYPE_VARIABLE},
> 	 {CYCLETYPE_DATA_OUT, 1, VALUETYPE_VARIABLE}
> 	};
>
> struct cycles SST25VF040B_probe_rdid[] =
>         {{CYCLETYPE_OPCODE, 1, VALUETYPE_FIXED, 0x90},
> 	 {CYCLETYPE_ADDRESS, 3, VALUETYPE_FIXED, 0},
> 	 {CYCLETYPE_DATA_IN, 2, VALUETYPE_FIXED, 0xbf8d}
> 	};
>
> struct cycles SST25VF040B_probe_jedec[] =
>         {{CYCLETYPE_OPCODE, 1, VALUETYPE_FIXED, 0x9f},
> 	 {CYCLETYPE_DATA_IN, 3, VALUETYPE_FIXED, 0xbf258d}
> 	};
>
> /* END OF SPECIFICATION */
>   

I believe that it is fundamentally wrong to differentiate between
preopcodes and opcodes. That's just a way to confuse people, invented by
chip and controller vendors in a misdirected attempt to make flash
access easier or safer. In reality, it hurts us a lot (no usability
benefits) and the security benefits are debatable as well, depending on
which host you look at.
On the wire, there is no difference between preopcodes and opcodes. They
are just bytes in a command stream. Sure, the command stream has chunks,
but the chip does not care whether you treat an opcode as preopcode or
normal opcode. It just expects certain bytes after each other in the
command stream. A write operation should send a command stream chunk to
the controller driver without having to care about preopcode/opcode
separation.

I'll probably have to send a patch to kill all this preopcode/opcode stuff.

Regards,
Carl-Daniel

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




From c-d.hailfinger.devel.2006 at gmx.net  Mon Jan  5 02:47:15 2009
From: c-d.hailfinger.devel.2006 at gmx.net (Carl-Daniel Hailfinger)
Date: Mon, 05 Jan 2009 02:47:15 +0100
Subject: [coreboot] [PATCH] flashrom: Update man page
Message-ID: <496166A3.2040705@gmx.net>

The flashrom man page has incomplete author/copyright sections and an
incorrect license section.
- Remove the copyright listings and refer the reader to the source files.
- Update the author list to those which have copyright messages in the
source files.
- Correct the license from GPL v2+ to GPL v2.

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

Index: flashrom-manpage/flashrom.8
===================================================================
--- flashrom-manpage/flashrom.8	(Revision 3811)
+++ flashrom-manpage/flashrom.8	(Arbeitskopie)
@@ -1,4 +1,4 @@
-.TH FLASHROM 8 "June 22, 2008"
+.TH FLASHROM 8 "January 5, 2009"
 .SH NAME
 flashrom \- a universal BIOS/ROM/flash programming utility
 .SH SYNOPSIS
@@ -84,22 +84,51 @@
 .RB "(" http://coreboot.org/Mailinglist ")."
 .SH LICENCE
 .B flashrom
-is covered by the GNU General Public License (GPL), version 2 or later.
+is covered by the GNU General Public License (GPL), version 2.
 .SH COPYRIGHT
-2000 Silicon Integrated System Corporation
 .br
-2003 Niki W. Waibel
-.br
-2004 Tyan Corp
-.br
-2005-2007 coresystems GmbH
+Please see the individual files.
 .SH AUTHORS
 Yinghai Lu <yinghai.lu at amd.com>
 .br
 Stefan Reinauer <stepan at coresystems.de>
 .br
-Niki W. Waibel <niki.waibel at gmx.net>
+Ronald G. Minnich <rminnich at gmail.com>
 .br
+Steven James <pyro at linuxlabs.com>
+.br
+Giampiero Giancipoli <gianci at email.it>
+.br
+Uwe Hermann <uwe at hermann-uwe.de>
+.br
+2008 Carl-Daniel Hailfinger
+.br
+Luc Verhaegen <libv at skynet.be>
+.br
+Carl-Daniel Hailfinger
+.br
+Markus Boas <ryven at ryven.de>
+.br
+Nikolay Petukhov <nikolay.petukhov at gmail.com>
+.br
+Reinder E.N. de Haan <lb_reha at mveas.com>
+.br
+Claus Gindhart <claus.gindhart at kontron.com>
+.br
+Dominik Geyer <dominik.geyer at kontron.com>
+.br
+Joe Bao <Zheng.Bao at amd.com>
+.br
+Peter Stuge <peter at stuge.se>
+.br
+Ronald Hoogenboom <ronald at zonnet.nl>
+.br
+Stefan Wildemann <stefan.wildemann at kontron.com>
+.br
+Eric Biederman <ebiederman at lnxi.com>
+.br
+Wang Qingpei <Qingpei.Wang at amd.com>
+.br
 some others 
 .PP
 This manual page was written by Uwe Hermann <uwe at hermann-uwe.de>.


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




From engineerguy3737 at yahoo.com  Mon Jan  5 10:11:05 2009
From: engineerguy3737 at yahoo.com (Dan Lykowski)
Date: Mon, 5 Jan 2009 01:11:05 -0800 (PST)
Subject: [coreboot] [PATCH] Add support for winbond w83627uhg SuperIO
Message-ID: <317372.66111.qm@web57002.mail.re3.yahoo.com>

Patch to add support for Winbond w83627uhg SuperIO.

(This is my first submission. Let me know if I did it wrong.)
Signed-off-by: Dan Lykowski <lykowdk at gmail.com>
---



      
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20090105/139f794a/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: add_winbond_w83627uhg_support.patch
Type: text/x-patch
Size: 10648 bytes
Desc: not available
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20090105/139f794a/attachment.patch>

From lambros.galanis at gmail.com  Mon Jan  5 12:29:52 2009
From: lambros.galanis at gmail.com (lambros galanis)
Date: Mon, 05 Jan 2009 13:29:52 +0200
Subject: [coreboot] DFI LANPARTY NF4 SLI
Message-ID: <1231154992.14529.6.camel@localhost.localdomain>

I have the specified motherboard and I would like to test coreboot bios.
Are there any configuration files or any advances regarding this
motherboard?

regards 

Lambros





From phueper at hueper.net  Mon Jan  5 13:24:43 2009
From: phueper at hueper.net (Pattrick Hueper)
Date: Mon, 5 Jan 2009 13:24:43 +0100
Subject: [coreboot] [PATCH] YABEL: add license to pmm files
Message-ID: <b5765cdf0901050424s36a049c5q5c4d17d33079fee9@mail.gmail.com>

Hi,

i just saw, that i forgot to add a BSD license header to the PMM
files, this patch fixes that.

Patty

 Signed-off-by: Pattrick Hueper <phueper at hueper.net>

---
 util/x86emu/yabel/pmm.c |    5 +++++
 util/x86emu/yabel/pmm.h |    5 +++++
 2 files changed, 10 insertions(+), 0 deletions(-)

diff --git a/util/x86emu/yabel/pmm.c b/util/x86emu/yabel/pmm.c
index b6ec49f..d909931 100644
--- a/util/x86emu/yabel/pmm.c
+++ b/util/x86emu/yabel/pmm.c
@@ -1,6 +1,11 @@
 /****************************************************************************
  * YABEL BIOS Emulator
  *
+ * This program and the accompanying materials
+ * are made available under the terms of the BSD License
+ * which accompanies this distribution, and is available at
+ * http://www.opensource.org/licenses/bsd-license.php
+ *
  * Copyright 2008 Pattrick Hueper <phueper at hueper.net>
  ****************************************************************************/

diff --git a/util/x86emu/yabel/pmm.h b/util/x86emu/yabel/pmm.h
index 56298ad..e1d0566 100644
--- a/util/x86emu/yabel/pmm.h
+++ b/util/x86emu/yabel/pmm.h
@@ -1,6 +1,11 @@
 /****************************************************************************
  * YABEL BIOS Emulator
  *
+ * This program and the accompanying materials
+ * are made available under the terms of the BSD License
+ * which accompanies this distribution, and is available at
+ * http://www.opensource.org/licenses/bsd-license.php
+ *
  * Copyright 2008 Pattrick Hueper <phueper at hueper.net>
  ****************************************************************************/

-- 
1.6.0.4
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0001-add-license-to-pmm-files.patch
Type: text/x-diff
Size: 1674 bytes
Desc: not available
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20090105/95b16793/attachment.bin>

From c-d.hailfinger.devel.2006 at gmx.net  Mon Jan  5 14:03:04 2009
From: c-d.hailfinger.devel.2006 at gmx.net (Carl-Daniel Hailfinger)
Date: Mon, 05 Jan 2009 14:03:04 +0100
Subject: [coreboot] [PATCH] Check the printk format string against the
	arguments
Message-ID: <49620508.6080906@gmx.net>

Check the printk format string against the matching arguments. We have
this type of checking in the v3 code since ages, but v2 will happily
compile any code with bogus printk format strings and/or parameters.
This can cause real bugs and at least needs to emit a warning, if not an
error. Go with a warning for now since most of the flagged format
strings are wrong but harmless in a 32-bit x86 environment.

The following warnings are triggered in my dbm690t build:

src/southbridge/amd/sb600/sb600_hda.c:284: warning: format ?%08x? expects type ?unsigned int?, but argument 3 has type ?u8 *?
src/mainboard/amd/dbm690t/mainboard.c:200: warning: format ?%x? expects type ?unsigned int?, but argument 3 has type ?device_t?
src/mainboard/amd/dbm690t/mainboard.c:236: warning: format ?%08x? expects type ?unsigned int?, but argument 3 has type ?long unsigned int?
src/mainboard/amd/dbm690t/mainboard.c:236: warning: format ?%08x? expects type ?unsigned int?, but argument 4 has type ?long unsigned int?
src/mainboard/amd/dbm690t/mainboard.c:256: warning: format ?%x? expects type ?unsigned int?, but argument 3 has type ?long unsigned int?
src/mainboard/amd/dbm690t/mainboard.c:256: warning: format ?%x? expects type ?unsigned int?, but argument 4 has type ?long unsigned int?
src/southbridge/amd/rs690/rs690_gfx.c:124: warning: format ?%x? expects type ?unsigned int?, but argument 3 has type ?device_t?
src/southbridge/amd/rs690/rs690_gfx.c:124: warning: format ?%x? expects type ?unsigned int?, but argument 4 has type ?device_t?
src/southbridge/amd/rs690/rs690_gfx.c:420: warning: format ?%x? expects type ?unsigned int?, but argument 3 has type ?device_t?
src/southbridge/amd/rs690/rs690_gfx.c:420: warning: format ?%x? expects type ?unsigned int?, but argument 4 has type ?device_t?
src/southbridge/amd/rs690/rs690.c:132: warning: format ?%x? expects type ?unsigned int?, but argument 3 has type ?device_t?
src/southbridge/amd/sb600/sb600_usb.c:97: warning: format ?%x? expects type ?unsigned int?, but argument 3 has type ?u8 *?
src/cpu/amd/model_fxx/model_fxx_init.c:234: warning: format ?%x? expects type ?unsigned int?, but argument 3 has type ?long unsigned int?
src/cpu/amd/model_fxx/model_fxx_init.c:315: warning: format ?%u? expects type ?unsigned int?, but argument 3 has type ?long unsigned int?
src/cpu/amd/model_fxx/model_fxx_init.c:315: warning: format ?%u? expects type ?unsigned int?, but argument 4 has type ?long unsigned int?
src/southbridge/amd/rs690/rs690_pcie.c:206: warning: format ?%x? expects type ?unsigned int?, but argument 3 has type ?device_t?
src/southbridge/amd/rs690/rs690_pcie.c:206: warning: format ?%x? expects type ?unsigned int?, but argument 4 has type ?device_t?
src/cpu/x86/lapic/lapic.c:58: warning: format ?%02x? expects type ?unsigned int?, but argument 3 has type ?long unsigned int?
src/cpu/x86/lapic/lapic_cpu_init.c:88: warning: format ?%d? expects type ?int?, but argument 3 has type ?long unsigned int?
src/cpu/x86/lapic/lapic_cpu_init.c:91: warning: format ?%x? expects type ?unsigned int?, but argument 3 has type ?long unsigned int?
src/cpu/x86/lapic/lapic_cpu_init.c:95: warning: format ?%x? expects type ?unsigned int?, but argument 3 has type ?long unsigned int?
src/cpu/x86/lapic/lapic_cpu_init.c:117: warning: format ?%d? expects type ?int?, but argument 3 has type ?long unsigned int?
src/cpu/x86/lapic/lapic_cpu_init.c:242: warning: format ?%d? expects type ?int?, but argument 3 has type ?long unsigned int?
src/arch/i386/boot/tables.c:95: warning: format ?%0x? expects type ?unsigned int?, but argument 3 has type ?long unsigned int?
src/mainboard/amd/dbm690t/acpi_tables.c:721: warning: format ?%08x? expects type ?unsigned int?, but argument 3 has type ?struct acpi_header_t *?
src/devices/pnp_device.c:106: warning: format ?%02x? expects type ?unsigned int?, but argument 4 has type ?long unsigned int?
src/devices/pnp_device.c:124: warning: format ?%02x? expects type ?unsigned int?, but argument 4 has type ?long unsigned int?
src/mainboard/amd/dbm690t/irq_tables.c:76: warning: format ?%x? expects type ?unsigned int?, but argument 3 has type ?long unsigned int?
src/devices/pci_device.c:209: warning: format ?%02x? expects type ?unsigned int?, but argument 4 has type ?long unsigned int?
src/devices/pci_device.c:209: warning: format ?%08x? expects type ?unsigned int?, but argument 5 has type ?long unsigned int?
src/devices/pci_device.c:314: warning: format ?%02x? expects type ?unsigned int?, but argument 4 has type ?long unsigned int?
src/devices/pci_device.c:314: warning: format ?%08x? expects type ?unsigned int?, but argument 5 has type ?long unsigned int?
src/devices/pci_device.c:462: warning: format ?%02x? expects type ?unsigned int?, but argument 4 has type ?long unsigned int?
src/devices/pci_device.c:549: warning: format ?%x? expects type ?unsigned int?, but argument 3 has type ?long unsigned int?
src/boot/elfboot.c:79: warning: format ?%04x? expects type ?unsigned int?, but argument 4 has type ?long unsigned int?
src/boot/elfboot.c:502: warning: format ?%016lx? expects type ?long unsigned int?, but argument 4 has type ?int?
src/boot/elfboot.c:593: warning: format ?%x? expects type ?unsigned int?, but argument 3 has type ?void *?
src/northbridge/amd/amdk8/amdk8_acpi.c:140: warning: format ?%04x? expects type ?unsigned int?, but argument 4 has type ?long unsigned int?
src/northbridge/amd/amdk8/amdk8_acpi.c:140: warning: format ?%08x? expects type ?unsigned int?, but argument 5 has type ?long unsigned int?
src/northbridge/amd/amdk8/amdk8_acpi.c:140: warning: format ?%08x? expects type ?unsigned int?, but argument 6 has type ?long unsigned int?
src/devices/device_util.c:469: warning: format ?%02x? expects type ?unsigned int?, but argument 4 has type ?long unsigned int?
src/arch/i386/lib/exception.c:483: warning: format ?%08lx? expects type ?long unsigned int?, but argument 5 has type ?uint32_t?
src/arch/i386/lib/exception.c:483: warning: format ?%08lx? expects type ?long unsigned int?, but argument 7 has type ?uint32_t?
src/arch/i386/lib/exception.c:483: warning: format ?%08lx? expects type ?long unsigned int?, but argument 8 has type ?uint32_t?
src/arch/i386/lib/exception.c:483: warning: format ?%08lx? expects type ?long unsigned int?, but argument 9 has type ?uint32_t?
src/arch/i386/lib/exception.c:483: warning: format ?%08lx? expects type ?long unsigned int?, but argument 10 has type ?uint32_t?
src/arch/i386/lib/exception.c:483: warning: format ?%08lx? expects type ?long unsigned int?, but argument 11 has type ?uint32_t?
src/arch/i386/lib/exception.c:483: warning: format ?%08lx? expects type ?long unsigned int?, but argument 12 has type ?uint32_t?
src/arch/i386/lib/exception.c:483: warning: format ?%08lx? expects type ?long unsigned int?, but argument 13 has type ?uint32_t?
src/arch/i386/lib/exception.c:483: warning: format ?%08lx? expects type ?long unsigned int?, but argument 14 has type ?uint32_t?
src/arch/i386/lib/exception.c:483: warning: format ?%08lx? expects type ?long unsigned int?, but argument 15 has type ?uint32_t?
src/cpu/x86/mtrr/mtrr.c:244: warning: format ?%4d? expects type ?int?, but argument 4 has type ?long unsigned int?
src/cpu/x86/mtrr/mtrr.c:244: warning: format ?%4d? expects type ?int?, but argument 5 has type ?long unsigned int?
src/arch/i386/boot/pirq_routing.c:69: warning: format ?%x? expects type ?unsigned int?, but argument 3 has type ?long unsigned int?
src/arch/i386/boot/pirq_routing.c:94: warning: format ?%x? expects type ?unsigned int?, but argument 3 has type ?long unsigned int?
src/devices/pci_rom.c:48: warning: format ?%x? expects type ?unsigned int?, but argument 4 has type ?long unsigned int?
src/devices/pci_rom.c:113: warning: format ?%x? expects type ?unsigned int?, but argument 3 has type ?struct rom_header *?
src/devices/pci_rom.c:118: warning: format ?%x? expects type ?unsigned int?, but argument 3 has type ?struct rom_header *?
src/devices/pci_rom.c:118: warning: format ?%x? expects type ?unsigned int?, but argument 4 has type ?void *?
src/arch/i386/boot/coreboot_table.c:254: warning: format ?%lx? expects type ?long unsigned int?, but argument 5 has type ?uint32_t?
src/arch/i386/boot/coreboot_table.c:418: warning: format ?%08x? expects type ?unsigned int?, but argument 3 has type ?long unsigned int?
src/arch/i386/boot/coreboot_table.c:421: warning: format ?%08x? expects type ?unsigned int?, but argument 3 has type ?long unsigned int?
src/arch/i386/boot/coreboot_table.c:424: warning: format ?%08x? expects type ?unsigned int?, but argument 3 has type ?long unsigned int?
src/arch/i386/boot/coreboot_table.c:427: warning: format ?%08x? expects type ?unsigned int?, but argument 3 has type ?long unsigned int?
src/arch/i386/lib/cpu.c:228: warning: format ?%d? expects type ?int?, but argument 3 has type ?long unsigned int?
src/arch/i386/lib/cpu.c:264: warning: format ?%d? expects type ?int?, but argument 3 has type ?long unsigned int?



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

Index: LinuxBIOSv2-printk_format/src/include/console/console.h
===================================================================
--- LinuxBIOSv2-printk_format/src/include/console/console.h	(Revision 3845)
+++ LinuxBIOSv2-printk_format/src/include/console/console.h	(Arbeitskopie)
@@ -27,7 +27,7 @@
 extern struct console_driver econsole_drivers[];
 
 extern int console_loglevel;
-int do_printk(int msg_level, const char *fmt, ...);
+int do_printk(int msg_level, const char *fmt, ...) __attribute__((format(printf, 2, 3)));
 
 #define printk_emerg(fmt, arg...)   do_printk(BIOS_EMERG   ,fmt, ##arg)
 #define printk_alert(fmt, arg...)   do_printk(BIOS_ALERT   ,fmt, ##arg)


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

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

From mart.raudsepp at artecdesign.ee  Mon Jan  5 15:49:57 2009
From: mart.raudsepp at artecdesign.ee (Mart Raudsepp)
Date: Mon, 05 Jan 2009 16:49:57 +0200
Subject: [coreboot] [PATCH] There's a pciconf.h with PCI conf constants -
 lets actually use it
Message-ID: <1231166997.20385.3.camel@martr-gentoo.artec>

In case it's a good idea to use these constants from that header, here's the proposed commit log and patch:



There's a pciconf.h with PCI conf constants - lets actually use it

PCI_CONF_REG_{INDEX,DATA} constants instead of 0xCF8 and 0xCFF everywhere.
Not touching YABEL as I'm not sure it would want to include that header.

Signed-off-by: Mart Raudsepp <mart.raudsepp at artecdesign.ee>
---
 arch/x86/pci_ops_conf1.c        |   24 ++++++++++++------------
 southbridge/amd/cs5536/cs5536.c |    5 +++--
 2 files changed, 15 insertions(+), 14 deletions(-)

diff --git a/arch/x86/pci_ops_conf1.c b/arch/x86/pci_ops_conf1.c
index a9a7fea..757b6c2 100644
--- a/arch/x86/pci_ops_conf1.c
+++ b/arch/x86/pci_ops_conf1.c
@@ -58,38 +58,38 @@
 
 u8 pci_conf1_read_config8(u32 bdf, int where)
 {
-		outl(CONFIG_CMD(bdf, where), 0xCF8);
-		return inb(0xCFC + (where & 3));
+		outl(CONFIG_CMD(bdf, where), PCI_CONF_REG_INDEX);
+		return inb(PCI_CONF_REG_DATA + (where & 3));
 }
 
 u16 pci_conf1_read_config16(u32 bdf, int where)
 {
-		outl(CONFIG_CMD(bdf, where), 0xCF8);
-		return inw(0xCFC + (where & 2));
+		outl(CONFIG_CMD(bdf, where), PCI_CONF_REG_INDEX);
+		return inw(PCI_CONF_REG_DATA + (where & 2));
 }
 
 u32 pci_conf1_read_config32(u32 bdf, int where)
 {
-		outl(CONFIG_CMD(bdf, where), 0xCF8);
-		return inl(0xCFC);
+		outl(CONFIG_CMD(bdf, where), PCI_CONF_REG_INDEX);
+		return inl(PCI_CONF_REG_DATA);
 }
 
 void  pci_conf1_write_config8(u32 bdf, int where, u8 value)
 {
-		outl(CONFIG_CMD(bdf, where), 0xCF8);
-		outb(value, 0xCFC + (where & 3));
+		outl(CONFIG_CMD(bdf, where), PCI_CONF_REG_INDEX);
+		outb(value, PCI_CONF_REG_DATA + (where & 3));
 }
 
 void pci_conf1_write_config16(u32 bdf, int where, u16 value)
 {
-		outl(CONFIG_CMD(bdf, where), 0xCF8);
-		outw(value, 0xCFC + (where & 2));
+		outl(CONFIG_CMD(bdf, where), PCI_CONF_REG_INDEX);
+		outw(value, PCI_CONF_REG_DATA + (where & 2));
 }
 
 void pci_conf1_write_config32(u32 bdf, int where, u32 value)
 {
-		outl(CONFIG_CMD(bdf, where), 0xCF8);
-		outl(value, 0xCFC);
+		outl(CONFIG_CMD(bdf, where), PCI_CONF_REG_INDEX);
+		outl(value, PCI_CONF_REG_DATA);
 }
 
 /**
diff --git a/southbridge/amd/cs5536/cs5536.c b/southbridge/amd/cs5536/cs5536.c
index 89d64d6..dacf5c3 100644
--- a/southbridge/amd/cs5536/cs5536.c
+++ b/southbridge/amd/cs5536/cs5536.c
@@ -20,6 +20,7 @@
 #include <types.h>
 #include <lib.h>
 #include <console.h>
+#include <pciconf.h>
 #include <device/pci.h>
 #include <msr.h>
 #include <amd_geodelx.h>
@@ -93,8 +94,8 @@ static void hide_vpci(u32 vpci_devid)
 	printk(BIOS_DEBUG, "Hiding VPCI device: 0x%08X (%02x:%02x.%01x)\n",
 		vpci_devid, (vpci_devid >> 16) & 0xff,
 		(vpci_devid >> 11) & 0x1f, (vpci_devid >> 8) & 0x7);
-	outl(vpci_devid + 0x7C, 0xCF8);
-	outl(0xDEADBEEF, 0xCFC);
+	outl(vpci_devid + 0x7C, PCI_CONF_REG_INDEX);
+	outl(0xDEADBEEF, PCI_CONF_REG_DATA);
 }
 
 /**
-- 
1.6.0.4




From chris at stockwith.co.uk  Mon Jan  5 15:54:53 2009
From: chris at stockwith.co.uk (Chris Lingard)
Date: Mon, 05 Jan 2009 14:54:53 +0000
Subject: [coreboot] DFI LANPARTY NF4 SLI
In-Reply-To: <1231154992.14529.6.camel@localhost.localdomain>
References: <1231154992.14529.6.camel@localhost.localdomain>
Message-ID: <49621F3D.7060103@stockwith.co.uk>

lambros galanis wrote:
> I have the specified motherboard and I would like to test coreboot bios.
> Are there any configuration files or any advances regarding this
> motherboard?
> 
> regards 
> 
> Lambros
> 
> 
> 
> --
> coreboot mailing list: coreboot at coreboot.org
> http://www.coreboot.org/mailman/listinfo/coreboot
> 

You may find this helpful

http://www.coreboot.org/DFI_NF570_Build_Tutorial

My board is a DFI Infinity NF570-M2/G

If the chipset corresponds, you will find that it works fine.

Chris Lingard



From svn at coreboot.org  Mon Jan  5 17:00:32 2009
From: svn at coreboot.org (svn at coreboot.org)
Date: Mon,  5 Jan 2009 17:00:32 +0100
Subject: [coreboot] r1094 - in coreboot-v3: device include/device
	mainboard/amd/serengeti northbridge/amd/k8
Message-ID: <mailman.2629.1355071466.16123.coreboot@coreboot.org>

Author: myles
Date: 2009-01-05 17:00:32 +0100 (Mon, 05 Jan 2009)
New Revision: 1094

Modified:
   coreboot-v3/device/hypertransport.c
   coreboot-v3/include/device/hypertransport.h
   coreboot-v3/mainboard/amd/serengeti/stage1.c
   coreboot-v3/northbridge/amd/k8/domain.c
   coreboot-v3/northbridge/amd/k8/pci
   coreboot-v3/northbridge/amd/k8/pci.c
Log:
	This patch fixes up k8 for the new resource allocator.  It splits
northbridge functions and makes devices children of the northbridge.
	
northbridge/amd/k8/domain.c: 
	Add the functions from k8/pci.c that belong to the domain.  Add
support for physical link numbers in resource indices.  Combine find_iopair
and find_mempair to find_regpair.

northbridge/amd/k8/pci.c:
	Remove functions that went to the domain.

device/hypertransport.c:
	Add support for HT connections from devices that aren't the bus
controller.

device/hypertransport.h:
	Change the prototype of hypertransport_scan_chain.

northbridge/amd/k8/pci:
	Take out bridge flag.

mainboard/amd/serengeti/stage1.c
	Change first register usage.

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



Modified: coreboot-v3/device/hypertransport.c
===================================================================
--- coreboot-v3/device/hypertransport.c	2008-12-31 20:02:03 UTC (rev 1093)
+++ coreboot-v3/device/hypertransport.c	2009-01-05 16:00:32 UTC (rev 1094)
@@ -287,15 +287,15 @@
 	return pos;
 }
 
-static void ht_collapse_early_enumeration(struct bus *bus,
+static void ht_collapse_early_enumeration(struct bus *bus, struct device* htdev,
 					  unsigned int offset_unitid)
 {
 	unsigned int devfn, ctrl;
 	struct ht_link prev;
 
 	/* Initialize the hypertransport enumeration state. */
-	prev.dev = bus->dev;
-	prev.pos = bus->cap;
+	prev.dev = htdev;
+	prev.pos = htdev->link[0].cap;
 	prev.ctrl_off = PCI_HT_CAP_HOST_CTRL;
 	prev.config_off = PCI_HT_CAP_HOST_WIDTH;
 	prev.freq_off = PCI_HT_CAP_HOST_FREQ;
@@ -384,7 +384,8 @@
 	}
 }
 
-unsigned int hypertransport_scan_chain(struct bus *bus, unsigned int min_devfn,
+unsigned int hypertransport_scan_chain(struct device* htdev, struct bus *bus,
+				       unsigned int min_devfn,
 				       unsigned int max_devfn,
 				       unsigned int max,
 				       unsigned int *ht_unitid_base,
@@ -411,15 +412,15 @@
 #endif
 
 	/* Restore the hypertransport chain to its unitialized state. */
-	ht_collapse_early_enumeration(bus, offset_unitid);
+	ht_collapse_early_enumeration(bus, htdev, offset_unitid);
 
 	/* See which static device nodes I have. */
 	old_devices = bus->children;
-	bus->children = 0;
+	bus->children = NULL;
 
 	/* Initialize the hypertransport enumeration state. */
-	prev.dev = bus->dev;
-	prev.pos = bus->cap;
+	prev.dev = htdev;
+	prev.pos = htdev->link[0].cap;
 	prev.ctrl_off = PCI_HT_CAP_HOST_CTRL;
 	prev.config_off = PCI_HT_CAP_HOST_WIDTH;
 	prev.freq_off = PCI_HT_CAP_HOST_FREQ;
@@ -525,7 +526,7 @@
 		next_unitid += count;
 
 		/* Setup the hypertransport link. */
-		bus->reset_needed |= ht_setup_link(&prev, dev, pos);
+		htdev->link[0].reset_needed |= ht_setup_link(&prev, dev, pos);
 
 		printk(BIOS_DEBUG, "%s [%04x/%04x] %s next_unitid: %04x\n",
 			     dev_path(dev),
@@ -537,7 +538,7 @@
 		 && (next_unitid <= (max_devfn >> 3)));
       end_of_chain:
 #if OPT_HT_LINK == 1
-	if (bus->reset_needed) {
+	if (htdev->link[0].reset_needed) {
 		printk(BIOS_INFO, "HyperT reset needed\n");
 	} else {
 		printk(BIOS_DEBUG, "HyperT reset not needed\n");
@@ -621,8 +622,9 @@
 {
 	unsigned int ht_unitid_base[4];
 	unsigned int offset_unitid = 1;
-	return hypertransport_scan_chain(bus, min_devfn, max_devfn, max,
-					 ht_unitid_base, offset_unitid);
+	return hypertransport_scan_chain(bus->dev, bus, min_devfn,
+					 max_devfn, max, ht_unitid_base,
+					 offset_unitid);
 }
 
 unsigned int ht_scan_bridge(struct device *dev, unsigned int max)

Modified: coreboot-v3/include/device/hypertransport.h
===================================================================
--- coreboot-v3/include/device/hypertransport.h	2008-12-31 20:02:03 UTC (rev 1093)
+++ coreboot-v3/include/device/hypertransport.h	2009-01-05 16:00:32 UTC (rev 1094)
@@ -21,8 +21,10 @@
 #include <device/device.h>
 #include <device/hypertransport_def.h>
 
-unsigned int hypertransport_scan_chain(struct bus *bus, 
-	unsigned min_devfn, unsigned max_devfn, unsigned int max, unsigned *ht_unit_base, unsigned offset_unitid);
+unsigned int hypertransport_scan_chain(struct device* parent, struct bus *bus,
+				       unsigned min_devfn, unsigned max_devfn,
+				       unsigned int max, unsigned *ht_unit_base,
+				       unsigned offset_unitid);
 unsigned int ht_scan_bridge(struct device *dev, unsigned int max);
 extern const struct device_operations default_ht_ops_bus;
 

Modified: coreboot-v3/mainboard/amd/serengeti/stage1.c
===================================================================
--- coreboot-v3/mainboard/amd/serengeti/stage1.c	2008-12-31 20:02:03 UTC (rev 1093)
+++ coreboot-v3/mainboard/amd/serengeti/stage1.c	2009-01-05 16:00:32 UTC (rev 1094)
@@ -210,10 +210,10 @@
 	 *	   This field defines the end of PCI I/O region n
 	 * [31:25] Reserved
 	 */
-	PCM(0, 0x18, 1, 0xC4,  0xFE000FC8, 0x01fff000),
+	PCM(0, 0x18, 1, 0xC4,  0xFE000FC8, 0x00000000),
 	PCM(0, 0x18, 1, 0xCC,  0xFE000FC8, 0x00000000),
 	PCM(0, 0x18, 1, 0xD4,  0xFE000FC8, 0x00000000),
-	PCM(0, 0x18, 1, 0xDC,  0xFE000FC8, 0x00000000),
+	PCM(0, 0x18, 1, 0xDC,  0xFE000FC8, 0x01fff000),
 
 	/* PCI I/O Base i Registers
 	 * F1:0xC0 i = 0
@@ -240,10 +240,10 @@
 	 *	   This field defines the start of PCI I/O region n 
 	 * [31:25] Reserved
 	 */
-	PCM(0, 0x18, 1, 0xC0,  0xFE000FCC, 0x00000003),
+	PCM(0, 0x18, 1, 0xC0,  0xFE000FCC, 0x00000000),
 	PCM(0, 0x18, 1, 0xC8,  0xFE000FCC, 0x00000000),
 	PCM(0, 0x18, 1, 0xD0,  0xFE000FCC, 0x00000000),
-	PCM(0, 0x18, 1, 0xD8,  0xFE000FCC, 0x00000000),
+	PCM(0, 0x18, 1, 0xD8,  0xFE000FCC, 0x00000003),
 
 	/* Config Base and Limit i Registers
 	 * F1:0xE0 i = 0

Modified: coreboot-v3/northbridge/amd/k8/domain.c
===================================================================
--- coreboot-v3/northbridge/amd/k8/domain.c	2008-12-31 20:02:03 UTC (rev 1093)
+++ coreboot-v3/northbridge/amd/k8/domain.c	2009-01-05 16:00:32 UTC (rev 1094)
@@ -7,6 +7,7 @@
  * Copyright (C) 2005 Ollie Lo
  * Copyright (C) 2005-2007 Stefan Reinauer <stepan at openbios.org>
  * Copyright (C) 2008 Ronald G. Minnich <rminnich at gmail.com>
+ * Copyright (C) 2008-2009 Myles Watson <mylesgw 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
@@ -46,27 +47,18 @@
 #include <lib.h>
 #include <lapic.h>
 
+#define K8_RESOURCE_INDEX(node, func, link, reg) (((node) << 16) | ((func<<8) | (reg) | (link)))
+#define K8_RESOURCE_NODE(index) (((index) & 0x70000)>>16)
+#define K8_RESOURCE_REG(index)  ((index) & 0xfc)
+#define K8_RESOURCE_LINK(index)  ((index) & 0x3)
+#define K8_RESOURCE_FUNC(index)  (((index) & 0x700)>>8)
+
 #define FX_DEVS 8
 extern struct device * __f0_dev[FX_DEVS];
 u32 f1_read_config32(unsigned int reg);
 void f1_write_config32(unsigned int reg, u32 value);
 unsigned int amdk8_nodeid(struct device * dev);
 
-static void k8_ram_resource(struct device * dev, unsigned long index,
-	unsigned long basek, unsigned long sizek)
-{
-	struct resource *resource;
-
-	if (!sizek) {
-		return;
-	}
-	resource = new_resource(dev, index);
-	resource->base  = ((resource_t)basek) << 10;
-	resource->size  = ((resource_t)sizek) << 10;
-	resource->flags =  IORESOURCE_MEM | IORESOURCE_CACHEABLE | \
-		IORESOURCE_FIXED | IORESOURCE_STORED | IORESOURCE_ASSIGNED;
-}
-
 static void tolm_test(void *gp, struct device *dev, struct resource *new)
 {
 	struct resource **best_p = gp;
@@ -91,68 +83,306 @@
 	return tolm;
 }
 
-static void k8_pci_domain_read_resources(struct device * dev)
+/**
+ * reg_useable
+ * @param reg register to check
+ * @param goal_dev device to own the resource
+ * @param goal_nodeid node number
+ * @param goal_link link number
+ * @return 0 if not useable, 1 if useable, or 2 if the pair is free
+ */
+static int reg_useable(unsigned reg, struct device *dev, unsigned goal_nodeid,
+		       unsigned goal_link)
 {
+	struct resource *res = NULL;
+	unsigned nodeid = 0, link = 0;
+	int result;
+
+	/* Look for the resource that matches this register. */
+	for(nodeid = 0; !res && (nodeid < FX_DEVS); nodeid++) {
+		for (link = 0; !res && (link < 3); link++) {
+			res = probe_resource(dev,K8_RESOURCE_INDEX(nodeid,1,link,reg));
+		}
+	}
+
+	if (res) {
+		/* If the resource is allocated to the link and node already. */
+		if (0 && (goal_link == K8_RESOURCE_LINK(res->index)) &&
+		    (goal_nodeid == K8_RESOURCE_NODE(res->index)) &&
+		    (res->flags <= 1)) {
+			printk(BIOS_DEBUG, "Re-allocated resource %lx!\n",
+			       res->index);
+			result = 1;
+		}
+		/* Allocated, but not to this node. */
+		else
+			result = 0;
+	} else
+		/* If no allocated resource was found, it is free - return 2. */
+		result = 2;
+
+	return result;
+}
+
+static struct resource *amdk8_find_regpair(struct device *dev, unsigned nodeid,
+					   unsigned minreg, unsigned maxreg,
+					  unsigned link)
+{
 	struct resource *resource;
-	unsigned reg;
+	unsigned free_reg, reg;
+	resource = NULL;
+	free_reg = 0;
+	for (reg = minreg; reg <= maxreg; reg += 0x8) {
+		int result;
+		result = reg_useable(reg, dev, nodeid, link);
+		if (result == 1) {
+			/* I have been allocated this one */
+			break;
+		} else if (result > 1) {
+			/* I have a free register pair */
+			free_reg = reg;
+		}
+	}
+	if (reg > maxreg) {
+		reg = free_reg;
+	}
+	if (reg > 0) {
+		resource = new_resource(dev, 0x100 + (reg | link));
+	}
+	return resource;
+}
 
-	/* Find the already assigned resource pairs */
-	printk(BIOS_DEBUG, "k8_pci_domain_read_resources\n");
-	for(reg = 0x80; reg <= 0xd8; reg+= 0x08) {
+static struct resource *amdk8_find_iopair(struct device *dev, unsigned nodeid,
+					  unsigned link)
+{
+	return amdk8_find_regpair(dev,nodeid,0xc0, 0xd8,link);
+}
+
+static struct resource *amdk8_find_mempair(struct device *dev, unsigned nodeid,
+					   unsigned link)
+{
+	return amdk8_find_regpair(dev,nodeid,0x80, 0xb8,link);
+}
+
+static void amdk8_link_read_bases(struct device *dev, unsigned nodeid,
+				  unsigned link)
+{
+	struct resource *resource;
+
+	/* Initialize the io space constraints on the current bus */
+	resource = amdk8_find_iopair(dev, nodeid, link);
+	if (resource) {
+		resource->base = 0;
+		resource->size = 0;
+		resource->align = log2c(HT_IO_HOST_ALIGN);
+		resource->gran = log2c(HT_IO_HOST_ALIGN);
+		resource->limit = 0xffffUL;
+		resource->flags = IORESOURCE_IO | IORESOURCE_BRIDGE;
+	}
+
+	/* Initialize the prefetchable memory constraints on the current bus */
+	resource = amdk8_find_mempair(dev, nodeid, link);
+	if (resource) {
+		resource->base = 0;
+		resource->size = 0;
+		resource->align = log2c(HT_MEM_HOST_ALIGN);
+		resource->gran = log2c(HT_MEM_HOST_ALIGN);
+		resource->limit = 0xffffffffffULL;
+		resource->flags = IORESOURCE_MEM | IORESOURCE_PREFETCH;
+#ifdef CONFIG_PCI_64BIT_PREF_MEM
+		resource->flags |= IORESOURCE_BRIDGE;
+#endif
+	}
+
+	/* Initialize the memory constraints on the current bus */
+	resource = amdk8_find_mempair(dev, nodeid, link);
+	if (resource) {
+		resource->base = 0;
+		resource->size = 0;
+		resource->align = log2c(HT_MEM_HOST_ALIGN);
+		resource->gran = log2c(HT_MEM_HOST_ALIGN);
+		resource->limit = 0xffffffffULL;
+		resource->flags = IORESOURCE_MEM | IORESOURCE_BRIDGE;
+	}
+}
+
+static void k8_pci_domain_read_resources(struct device *dev)
+{
+	printk(BIOS_DEBUG, "%s\n", __func__);
+	unsigned link;
+
+	for (link = 0; link < dev->links; link++) {
+		if (dev->link[link].children) {
+			amdk8_link_read_bases(dev, 0, link);
+		}
+	}
+	printk(BIOS_DEBUG, "%s done\n", __func__);
+}
+
+static void amdk8_set_resource(struct device *dev, struct resource *resource)
+{
+	resource_t rbase, rend;
+	unsigned reg, link, nodeid, func;
+	char buf[50];
+
+	printk(BIOS_DEBUG, "%s: %s@%lx flags %lx\n", __func__, dev->dtsname,
+	       resource->index, resource->flags);
+
+	/* Make certain the resource has actually been set. */
+	if (!(resource->flags & IORESOURCE_ASSIGNED)) {
+		return;
+	}
+
+	/* If I have already stored this resource don't worry about it. */
+	if (resource->flags & IORESOURCE_STORED) {
+		return;
+	}
+
+	/* Only handle PCI memory and IO resources. */
+	if (!(resource->flags & (IORESOURCE_MEM | IORESOURCE_IO)))
+		return;
+
+	/* Get the base address. */
+	rbase = resource->base;
+
+	/* Get the limit (rounded up). */
+	rend = resource_end(resource);
+
+	/* Get the register, nodeid, and link */
+	nodeid = K8_RESOURCE_NODE(resource->index);
+	reg = K8_RESOURCE_REG(resource->index);
+	link = K8_RESOURCE_LINK(resource->index);
+	func = K8_RESOURCE_FUNC(resource->index);
+
+	if (func != 1) {
+		printk(BIOS_INFO, "%s: K8 function %d register!\n", __func__,
+		       func);
+		return;
+	}
+
+	if (resource->flags & IORESOURCE_IO) {
 		u32 base, limit;
-		base  = f1_read_config32(reg);
-		limit = f1_read_config32(reg + 0x04);
-		/* Is this register allocated? */
-		if ((base & 3) != 0) {
-			unsigned nodeid, link;
-			struct device * dev;
-			nodeid = limit & 7;
-			link   = (limit >> 4) & 3;
-			dev = __f0_dev[nodeid]; /* Initialized by f1_read_config32. */
-			if (dev) {
-				/* Reserve the resource  */
-				struct resource *resource;
-				resource = new_resource(dev, 0x100 + (reg | link));
-				if (resource) {
-					resource->flags = 1;
-				}
-			}
+		base = f1_read_config32(reg);
+		limit = f1_read_config32(reg + 0x4);
+		base &= 0xfe000fcc;
+		base |= rbase & 0x01fff000;
+		base |= 3;
+		limit &= 0xfe000fc8;
+		limit |= rend & 0x01fff000;
+		limit |= (link & 3) << 4;
+		limit |= (nodeid & 7);
+
+		if (dev->link[link].bridge_ctrl & PCI_BRIDGE_CTL_VGA) {
+			printk(BIOS_SPEW,
+			       "%s, enabling legacy VGA IO forwarding for %s link %x\n",
+			       __func__, dev_path(dev), link);
+			base |= PCI_IO_BASE_VGA_EN;
 		}
+		if (dev->link[link].bridge_ctrl & PCI_BRIDGE_CTL_NO_ISA) {
+			base |= PCI_IO_BASE_NO_ISA;
+		}
+
+		f1_write_config32(reg + 0x4, limit);
+		f1_write_config32(reg, base);
+	} else if (resource->flags & IORESOURCE_MEM) {
+		u32 base, limit;
+		base = f1_read_config32(reg);
+		limit = f1_read_config32(reg + 0x4);
+		base &= 0x000000f0;
+		base |= (rbase >> 8) & 0xffffff00;
+		base |= 3;
+		limit &= 0x00000048;
+		limit |= (rend >> 8) & 0xffffff00;
+		limit |= (link & 3) << 4;
+		limit |= (nodeid & 7);
+		f1_write_config32(reg + 0x4, limit);
+		f1_write_config32(reg, base);
 	}
-#ifndef CONFIG_PCI_64BIT_PREF_MEM
-	/* Initialize the system-wide io space constraints */
-	resource = new_resource(dev, IOINDEX_SUBTRACTIVE(0, 0));
-	resource->base  = 0x400;
-	resource->limit = 0xffffUL;
-	resource->flags = IORESOURCE_IO | IORESOURCE_SUBTRACTIVE | IORESOURCE_ASSIGNED;
+	resource->flags |= IORESOURCE_STORED;
+	sprintf(buf, " <node %d link %d>", nodeid, link);
+	report_resource_stored(dev, resource, buf);
+}
 
-	/* Initialize the system-wide memory resource constraints */
-	resource = new_resource(dev, IOINDEX_SUBTRACTIVE(1, 0));
-	resource->limit = 0xfcffffffffULL;
-	resource->flags = IORESOURCE_MEM | IORESOURCE_SUBTRACTIVE | IORESOURCE_ASSIGNED;
-#else
-	/* Initialize the system-wide io space constraints */
-	resource = new_resource(dev, 0);
-	resource->base  = 0x400;
-	resource->limit = 0xffffUL;
-	resource->flags = IORESOURCE_IO;
+#ifdef CONFIG_MULTIPLE_VGA_INIT
+extern struct device *vga_pri;	// the primary vga device, defined in device.c
+#endif
 
-	/* Initialize the system-wide prefetchable memory resource constraints */
-	resource = new_resource(dev, 1);
-	resource->limit = 0xfcffffffffULL;
-	resource->flags = IORESOURCE_MEM | IORESOURCE_PREFETCH;
+static void amdk8_create_vga_resource(struct device *dev)
+{
+	struct resource *resource;
+	unsigned link;
 
-	/* Initialize the system-wide memory resource constraints */
-	resource = new_resource(dev, 2);
-	resource->limit = 0xfcffffffffULL;
-	resource->flags = IORESOURCE_MEM;
+	/* find out which link the VGA card is connected,
+	 * we only deal with the 'first' vga card */
+	for (link = 0; link < dev->links; link++) {
+		if (dev->link[link].bridge_ctrl & PCI_BRIDGE_CTL_VGA) {
+#ifdef CONFIG_MULTIPLE_VGA_INIT
+			printk(BIOS_DEBUG,
+			       "VGA: vga_pri bus num = %d dev->link[link] bus range [%d,%d]\n",
+			       vga_pri->bus->secondary,
+			       dev->link[link].secondary,
+			       dev->link[link].subordinate);
+			/* We need to make sure the vga_pri is under the link */
+			if ((vga_pri->bus->secondary >=
+			     dev->link[link].secondary)
+			    && (vga_pri->bus->secondary <=
+				dev->link[link].subordinate)
+			    )
 #endif
-	printk(BIOS_DEBUG, "k8_pci_domain_read_resources done\n");
+				break;
+		}
+	}
+
+	/* no VGA card installed */
+	if (link == dev->links)
+		return;
+
+	printk(BIOS_DEBUG, "VGA: %s (aka node %d) link %d has VGA device\n",
+	       dev_path(dev), 0, link);
+
+	/* Allocate a resrouce for the legacy VGA buffer. */
+	resource = amdk8_find_mempair(dev, 0, link);
+	if (!resource) {
+		printk(BIOS_DEBUG,
+		       "VGA: Can not find free mmio reg for legacy VGA buffer\n");
+		return;
+	}
+	resource->base = 0xa0000;
+	resource->size = 0x20000;
+
+	resource->flags = IORESOURCE_MEM | IORESOURCE_ASSIGNED;
 }
 
+static void amdk8_set_resources(struct device *dev)
+{
+	unsigned link;
+	int i;
+
+	printk(BIOS_DEBUG, "%s\n", __func__);
+
+	printk(BIOS_DEBUG, "%s ops %p ops_pci_bus %p\n",
+		dev->dtsname, dev->ops, dev->ops->ops_pci_bus);
+	pci_check_pci_ops(dev->ops->ops_pci_bus);
+
+	amdk8_create_vga_resource(dev);
+
+	/* Set each resource we have found */
+	for (i = 0; i < dev->resources; i++) {
+		amdk8_set_resource(dev, &dev->resource[i]);
+	}
+
+	for (link = 0; link < dev->links; link++) {
+		struct bus *bus;
+		bus = &dev->link[link];
+		if (bus->children) {
+			phase4_set_resources(bus);
+		}
+	}
+}
+
 static void k8_pci_domain_set_resources(struct device * dev)
 {
-	printk(BIOS_DEBUG, "k8_pci_domain_set_resources\n");
+	printk(BIOS_DEBUG, "%s\n", __func__);
 #if CONFIG_HW_MEM_HOLE_SIZEK != 0
 	struct hw_mem_hole_info get_hw_mem_hole_info(void);
 	void disable_hoist_memory(unsigned long hole_startk, int i);
@@ -170,69 +400,6 @@
 	unsigned reset_memhole = 1;
 #endif
 
-#if 0
-	/* Place the IO devices somewhere safe */
-	io = find_resource(dev, 0);
-	io->base = DEVICE_IO_START;
-#endif
-#ifdef CONFIG_PCI_64BIT_PREF_MEM
-	/* Now reallocate the pci resources memory with the
-	 * highest addresses I can manage.
-	 */
-	mem1 = find_resource(dev, 1);
-	mem2 = find_resource(dev, 2);
-
-#if 1
-	printk(BIOS_DEBUG, "base1: 0x%08Lx limit1: 0x%08Lx size: 0x%08Lx align: %d\n",
-		mem1->base, mem1->limit, mem1->size, mem1->align);
-	printk(BIOS_DEBUG, "base2: 0x%08Lx limit2: 0x%08Lx size: 0x%08Lx align: %d\n",
-		mem2->base, mem2->limit, mem2->size, mem2->align);
-#endif
-
-	/* See if both resources have roughly the same limits */
-	if (((mem1->limit <= 0xffffffff) && (mem2->limit <= 0xffffffff)) ||
-		((mem1->limit > 0xffffffff) && (mem2->limit > 0xffffffff)))
-	{
-		/* If so place the one with the most stringent alignment first
-		 */
-		if (mem2->align > mem1->align) {
-			struct resource *tmp;
-			tmp = mem1;
-			mem1 = mem2;
-			mem2 = tmp;
-		}
-		/* Now place the memory as high up as it will go */
-		mem2->base = resource_max(mem2);
-		mem1->limit = mem2->base - 1;
-		mem1->base = resource_max(mem1);
-	}
-	else {
-		/* Place the resources as high up as they will go */
-		mem2->base = resource_max(mem2);
-		mem1->base = resource_max(mem1);
-	}
-
-#if 1
-	printk(BIOS_DEBUG, "base1: 0x%08Lx limit1: 0x%08Lx size: 0x%08Lx align: %d\n",
-		mem1->base, mem1->limit, mem1->size, mem1->align);
-	printk(BIOS_DEBUG, "base2: 0x%08Lx limit2: 0x%08Lx size: 0x%08Lx align: %d\n",
-		mem2->base, mem2->limit, mem2->size, mem2->align);
-#endif
-
-	last = &dev->resource[dev->resources];
-	for(resource = &dev->resource[0]; resource < last; resource++)
-	{
-#if 1
-		resource->flags |= IORESOURCE_ASSIGNED;
-		resource->flags &= ~IORESOURCE_STORED;
-#endif
-		resource->flags |= IORESOURCE_STORED;
-		report_resource_stored(dev, resource, "");
-
-	}
-#endif
-
-
 	pci_tolm = find_pci_tolm(&dev->link[0]);
 
 #warning "FIXME handle interleaved nodes"
@@ -240,11 +407,9 @@
 	/* Round mmio_basek to something the processor can support */
 	mmio_basek &= ~((1 << 6) -1);
 
-#if 1
 #warning "FIXME improve mtrr.c so we don't use up all of the mtrrs with a 64M MMIO hole"
 	/* Round the mmio hole to 64M */
 	mmio_basek &= ~((64*1024) - 1);
-#endif
 
 #if CONFIG_HW_MEM_HOLE_SIZEK != 0
 	/* If the hw mem hole is already set in raminit stage, here we will
@@ -307,7 +472,7 @@
 
 		/* see if we need a hole from 0xa0000 to 0xbffff */
 		if ((basek < ((8*64)+(8*16))) && (sizek > ((8*64)+(16*16)))) {
-			k8_ram_resource(dev, (idx | i), basek, ((8*64)+(8*16)) - basek);
+			ram_resource(dev, (idx | i), basek, ((8*64)+(8*16)) - basek);
 			idx += 0x10;
 			basek = (8*64)+(16*16);
 			sizek = limitk - ((8*64)+(16*16));
@@ -323,7 +488,7 @@
 				unsigned pre_sizek;
 				pre_sizek = mmio_basek - basek;
 				if(pre_sizek>0) {
-					k8_ram_resource(dev, (idx | i), basek, pre_sizek);
+					ram_resource(dev, (idx | i), basek, pre_sizek);
 					idx += 0x10;
 					sizek -= pre_sizek;
 				}
@@ -342,22 +507,223 @@
 				sizek -= (4*1024*1024 - mmio_basek);
 			}
 		}
-		k8_ram_resource(dev, (idx | i), basek, sizek);
+		ram_resource(dev, (idx | i), basek, sizek);
 		idx += 0x10;
 	}
+
+	amdk8_set_resources(dev);
+
 	phase4_set_resources(&dev->link[0]);
 }
 
+static unsigned int amdk8_scan_chain(struct device *domain,
+				     struct device* k8dev,
+				     unsigned link, unsigned sblink,
+				     unsigned int max, unsigned offset_unitid)
+{
+
+	u32 link_type;
+	int i;
+	u32 busses, config_busses;
+	unsigned free_reg, config_reg;
+	unsigned ht_unitid_base[4];	// here assume only 4 HT device on chain
+	unsigned max_bus;
+	unsigned min_bus;
+	unsigned max_devfn;
+	unsigned nodeid = amdk8_nodeid(k8dev);
+	printk(BIOS_SPEW, "%s node %x link %x\n", __func__, nodeid, link);
+	k8dev->link[link].cap = 0x80 + (link * 0x20);
+	do {
+		link_type = pci_read_config32(k8dev, k8dev->link[link].cap + 0x18);
+	} while (link_type & ConnectionPending);
+	if (!(link_type & LinkConnected)) {
+		return max;
+	}
+	printk(BIOS_DEBUG, "amdk8_scan_chain: link %d is connected\n", link);
+	do {
+		link_type = pci_read_config32(k8dev, k8dev->link[link].cap + 0x18);
+	} while (!(link_type & InitComplete));
+	if (!(link_type & NonCoherent)) {
+		return max;
+	}
+	/* See if there is an available configuration space mapping
+	 * register in function 1.
+	 */
+	free_reg = 0;
+	for (config_reg = 0xe0; config_reg <= 0xec; config_reg += 4) {
+		u32 config;
+		config = f1_read_config32(config_reg);
+		if (!free_reg && ((config & 3) == 0)) {
+			free_reg = config_reg;
+			continue;
+		}
+		if (((config & 3) == 3) &&
+		    (((config >> 4) & 7) == nodeid) &&
+		    (((config >> 8) & 3) == link)) {
+			break;
+		}
+	}
+	if (free_reg && (config_reg > 0xec)) {
+		config_reg = free_reg;
+	}
+	/* If we can't find an available configuration space mapping
+	 * register skip this bus
+	 */
+	if (config_reg > 0xec) {
+		return max;
+	}
+
+	/* Set up the primary, secondary and subordinate bus numbers.
+	 * We have no idea how many busses are behind this bridge yet,
+	 * so we set the subordinate bus number to 0xff for the moment.
+	 */
+#if SB_HT_CHAIN_ON_BUS0 > 0
+	// first chain will on bus 0
+	if ((nodeid == 0) && (sblink == link)) {	// actually max is 0 here
+		min_bus = max;
+	}
+	#if SB_HT_CHAIN_ON_BUS0 > 1
+	// second chain will be on 0x40, third 0x80, forth 0xc0
+	else {
+		min_bus = ((max >> 6) + 1) * 0x40;
+	}
+	max = min_bus;
+	#else
+	//other ...
+	else {
+		min_bus = ++max;
+	}
+	#endif
+#else
+	min_bus = ++max;
+#endif
+	max_bus = 0xff;
+
+	k8dev->link[link].secondary = min_bus;
+	k8dev->link[link].subordinate = max_bus;
+
+	/* Read the existing primary/secondary/subordinate bus
+	 * number configuration.
+	 */
+	busses = pci_read_config32(k8dev, k8dev->link[link].cap + 0x14);
+	config_busses = f1_read_config32(config_reg);
+
+	/* Configure the bus numbers for this bridge: the configuration
+	 * transactions will not be propagates by the bridge if it is
+	 * not correctly configured
+	 */
+	busses &= 0xff000000;
+	busses |= (((unsigned int)(k8dev->bus->secondary) << 0) |
+		   ((unsigned int)(k8dev->link[link].secondary) << 8) |
+		   ((unsigned int)(k8dev->link[link].subordinate) << 16));
+	pci_write_config32(k8dev, k8dev->link[link].cap + 0x14, busses);
+
+	config_busses &= 0x000fc88;
+	config_busses |= (3 << 0) |	/* rw enable, no device compare */
+	    ((nodeid & 7) << 4) |
+	    ((link & 3) << 8) |
+	    ((k8dev->link[link].secondary) << 16) |
+	    ((k8dev->link[link].subordinate) << 24);
+	f1_write_config32(config_reg, config_busses);
+
+	/* Now we can scan all of the subordinate busses i.e. the
+	 * chain on the hypertranport link
+	 */
+	for (i = 0; i < 4; i++) {
+		ht_unitid_base[i] = 0x20;
+	}
+
+	max_devfn = PCI_DEVFN(0x1f, 7);
+
+	max = hypertransport_scan_chain(k8dev, &domain->link[link], 0,
+				        max_devfn, max, ht_unitid_base,
+				        offset_unitid);
+
+	/* We know the number of busses behind this bridge.  Set the
+	 * subordinate bus number to it's real value
+	 */
+	k8dev->link[link].subordinate = max;
+	busses = (busses & 0xff00ffff) |
+	    ((unsigned int)(k8dev->link[link].subordinate) << 16);
+	pci_write_config32(k8dev, k8dev->link[link].cap + 0x14, busses);
+
+	config_busses = (config_busses & 0x00ffffff) |
+	    (k8dev->link[link].subordinate << 24);
+	f1_write_config32(config_reg, config_busses);
+
+	{
+		// config config_reg, and ht_unitid_base to update hcdn_reg;
+		int index;
+		unsigned temp = 0;
+		index = (config_reg - 0xe0) >> 2;
+		for (i = 0; i < 4; i++) {
+			temp |= (ht_unitid_base[i] & 0xff) << (i * 8);
+		}
+
+		sysconf.hcdn_reg[index] = temp;
+
+	}
+
+	printk(BIOS_SPEW, "amdk8_scan_chain done\n");
+	return max;
+}
+
+static unsigned int amdk8_scan_chains(struct device *domain, struct device *k8dev,
+				      unsigned int max)
+{
+	unsigned nodeid;
+	unsigned link;
+	unsigned sblink = 0;
+	unsigned offset_unitid = 0;
+	nodeid = amdk8_nodeid(k8dev);
+
+	printk(BIOS_DEBUG, "amdk8_scan_chains\n");
+
+	if (nodeid == 0) {
+		sblink = (pci_read_config32(k8dev, 0x64) >> 8) & 3;
+#if SB_HT_CHAIN_ON_BUS0 > 0
+#if ((HT_CHAIN_UNITID_BASE != 1) || (HT_CHAIN_END_UNITID_BASE != 0x20))
+		offset_unitid = 1;
+#endif
+		// do southbridge ht chain first, in case s2885 put southbridge chain (8131/8111) on link2,
+		// but put 8151 on link0
+		max =
+		    amdk8_scan_chain(domain, k8dev, sblink, sblink, max,
+				     offset_unitid);
+#endif
+	}
+
+	for (link = 0; link < k8dev->links; link++) {
+#if SB_HT_CHAIN_ON_BUS0 > 0
+		if ((nodeid == 0) && (sblink == link))
+			continue;	//already done
+#endif
+		offset_unitid = 0;
+#if ((HT_CHAIN_UNITID_BASE != 1) || (HT_CHAIN_END_UNITID_BASE != 0x20))
+#if SB_HT_CHAIN_UNITID_OFFSET_ONLY == 1
+		if ((nodeid == 0) && (sblink == link))
+#endif
+			offset_unitid = 1;
+#endif
+
+		max = amdk8_scan_chain(domain, k8dev, link, sblink, max,
+				       offset_unitid);
+	}
+
+	return max;
+}
+
 static unsigned int k8_domain_scan_bus(struct device * dev, unsigned int max)
 {
 	unsigned reg;
 	int i;
-	printk(BIOS_DEBUG, "k8_domain_scan_bus\n");
+
+	printk(BIOS_DEBUG, "%s: %s \n", __func__, dev->dtsname);
+
 	/* Unmap all of the HT chains */
 	for(reg = 0xe0; reg <= 0xec; reg += 4) {
 		f1_write_config32(reg, 0);
 	}
-	max = pci_scan_bus(&dev->link[0], PCI_DEVFN(0x18, 0), 0xff, max);
 
 	/* Tune the hypertransport transaction for best performance.
 	 * Including enabling relaxed ordering if it is safe.
@@ -379,9 +745,18 @@
 			pci_write_config32(f0_dev, HT_TRANSACTION_CONTROL, httc);
 		}
 	}
+
+	max = amdk8_scan_chains(dev, __f0_dev[0], max);
+
 	return max;
 }
 
+static void k8_pci_domain_enable_resources(struct device *dev)
+{
+	printk(BIOS_DEBUG, "%s\n", __func__);
+	enable_childrens_resources(dev);
+}
+
 struct device_operations k8domain_ops = {
 	.id = {.type = DEVICE_ID_APIC_CLUSTER,
 		{.pci_domain = {.vendor = PCI_VENDOR_ID_AMD,
@@ -390,7 +765,6 @@
 	.phase3_scan		 = k8_domain_scan_bus,
 	.phase4_read_resources	 = k8_pci_domain_read_resources,
 	.phase4_set_resources	 = k8_pci_domain_set_resources,
-	.phase5_enable_resources = enable_childrens_resources,
-	.ops_pci		 = &pci_dev_ops_pci,
+	.phase5_enable_resources = k8_pci_domain_enable_resources,
 	.ops_pci_bus		 = &pci_cf8_conf1,
 };

Modified: coreboot-v3/northbridge/amd/k8/pci
===================================================================
--- coreboot-v3/northbridge/amd/k8/pci	2008-12-31 20:02:03 UTC (rev 1093)
+++ coreboot-v3/northbridge/amd/k8/pci	2009-01-05 16:00:32 UTC (rev 1094)
@@ -20,5 +20,4 @@
 
 {
 	device_operations = "k8_ops";
-	bridge;
 };

Modified: coreboot-v3/northbridge/amd/k8/pci.c
===================================================================
--- coreboot-v3/northbridge/amd/k8/pci.c	2008-12-31 20:02:03 UTC (rev 1093)
+++ coreboot-v3/northbridge/amd/k8/pci.c	2009-01-05 16:00:32 UTC (rev 1094)
@@ -46,538 +46,6 @@
 #include <lib.h>
 #include <lapic.h>
 
-u32 f1_read_config32(unsigned int reg);
-void f1_write_config32(unsigned int reg, u32 value);
-unsigned int amdk8_nodeid(struct device *dev);
-
-static unsigned int amdk8_scan_chain(struct device *dev, unsigned nodeid,
-				     unsigned link, unsigned sblink,
-				     unsigned int max, unsigned offset_unitid)
-{
-
-	u32 link_type;
-	int i;
-	u32 busses, config_busses;
-	unsigned free_reg, config_reg;
-	unsigned ht_unitid_base[4];	// here assume only 4 HT device on chain
-	unsigned max_bus;
-	unsigned min_bus;
-	unsigned max_devfn;
-	printk(BIOS_SPEW, "amdk8_scan_chain link %x\n", link);
-	dev->link[link].cap = 0x80 + (link * 0x20);
-	do {
-		link_type = pci_read_config32(dev, dev->link[link].cap + 0x18);
-	} while (link_type & ConnectionPending);
-	if (!(link_type & LinkConnected)) {
-		return max;
-	}
-	printk(BIOS_DEBUG, "amdk8_scan_chain: link %d is connected\n", link);
-	do {
-		link_type = pci_read_config32(dev, dev->link[link].cap + 0x18);
-	} while (!(link_type & InitComplete));
-	if (!(link_type & NonCoherent)) {
-		return max;
-	}
-	/* See if there is an available configuration space mapping
-	 * register in function 1.
-	 */
-	free_reg = 0;
-	for (config_reg = 0xe0; config_reg <= 0xec; config_reg += 4) {
-		u32 config;
-		config = f1_read_config32(config_reg);
-		if (!free_reg && ((config & 3) == 0)) {
-			free_reg = config_reg;
-			continue;
-		}
-		if (((config & 3) == 3) &&
-		    (((config >> 4) & 7) == nodeid) &&
-		    (((config >> 8) & 3) == link)) {
-			break;
-		}
-	}
-	if (free_reg && (config_reg > 0xec)) {
-		config_reg = free_reg;
-	}
-	/* If we can't find an available configuration space mapping
-	 * register skip this bus
-	 */
-	if (config_reg > 0xec) {
-		return max;
-	}
-
-	/* Set up the primary, secondary and subordinate bus numbers.
-	 * We have no idea how many busses are behind this bridge yet,
-	 * so we set the subordinate bus number to 0xff for the moment.
-	 */
-#if SB_HT_CHAIN_ON_BUS0 > 0
-	// first chain will on bus 0
-	if ((nodeid == 0) && (sblink == link)) {	// actually max is 0 here
-		min_bus = max;
-	}
-	#if SB_HT_CHAIN_ON_BUS0 > 1
-	// second chain will be on 0x40, third 0x80, forth 0xc0
-	else {
-		min_bus = ((max >> 6) + 1) * 0x40;
-	}
-	max = min_bus;
-	#else
-	//other ...
-	else {
-		min_bus = ++max;
-	}
-	#endif
-#else
-	min_bus = ++max;
-#endif
-	max_bus = 0xff;
-
-	dev->link[link].secondary = min_bus;
-	dev->link[link].subordinate = max_bus;
-
-	/* Read the existing primary/secondary/subordinate bus
-	 * number configuration.
-	 */
-	busses = pci_read_config32(dev, dev->link[link].cap + 0x14);
-	config_busses = f1_read_config32(config_reg);
-
-	/* Configure the bus numbers for this bridge: the configuration
-	 * transactions will not be propagates by the bridge if it is
-	 * not correctly configured
-	 */
-	busses &= 0xff000000;
-	busses |= (((unsigned int)(dev->bus->secondary) << 0) |
-		   ((unsigned int)(dev->link[link].secondary) << 8) |
-		   ((unsigned int)(dev->link[link].subordinate) << 16));
-	pci_write_config32(dev, dev->link[link].cap + 0x14, busses);
-
-	config_busses &= 0x000fc88;
-	config_busses |= (3 << 0) |	/* rw enable, no device compare */
-	    ((nodeid & 7) << 4) |
-	    ((link & 3) << 8) |
-	    ((dev->link[link].secondary) << 16) |
-	    ((dev->link[link].subordinate) << 24);
-	f1_write_config32(config_reg, config_busses);
-
-	/* Now we can scan all of the subordinate busses i.e. the
-	 * chain on the hypertranport link
-	 */
-	for (i = 0; i < 4; i++) {
-		ht_unitid_base[i] = 0x20;
-	}
-
-	if (min_bus == 0)
-		max_devfn = (0x17 << 3) | 7;
-	else
-		max_devfn = (0x1f << 3) | 7;
-
-	max =
-	    hypertransport_scan_chain(&dev->link[link], 0, max_devfn, max,
-				      ht_unitid_base, offset_unitid);
-
-	/* We know the number of busses behind this bridge.  Set the
-	 * subordinate bus number to it's real value
-	 */
-	dev->link[link].subordinate = max;
-	busses = (busses & 0xff00ffff) |
-	    ((unsigned int)(dev->link[link].subordinate) << 16);
-	pci_write_config32(dev, dev->link[link].cap + 0x14, busses);
-
-	config_busses = (config_busses & 0x00ffffff) |
-	    (dev->link[link].subordinate << 24);
-	f1_write_config32(config_reg, config_busses);
-
-	{
-		// config config_reg, and ht_unitid_base to update hcdn_reg;
-		int index;
-		unsigned temp = 0;
-		index = (config_reg - 0xe0) >> 2;
-		for (i = 0; i < 4; i++) {
-			temp |= (ht_unitid_base[i] & 0xff) << (i * 8);
-		}
-
-		sysconf.hcdn_reg[index] = temp;
-
-	}
-
-	printk(BIOS_SPEW, "amdk8_scan_chain done\n");
-	return max;
-}
-
-static unsigned int amdk8_scan_chains(struct device *dev, unsigned int max)
-{
-	unsigned nodeid;
-	unsigned link;
-	unsigned sblink = 0;
-	unsigned offset_unitid = 0;
-	nodeid = amdk8_nodeid(dev);
-
-	printk(BIOS_DEBUG, "amdk8_scan_chains\n");
-
-	if (nodeid == 0) {
-		sblink = (pci_read_config32(dev, 0x64) >> 8) & 3;
-#if SB_HT_CHAIN_ON_BUS0 > 0
-#if ((HT_CHAIN_UNITID_BASE != 1) || (HT_CHAIN_END_UNITID_BASE != 0x20))
-		offset_unitid = 1;
-#endif
-		// do southbridge ht chain first, in case s2885 put southbridge chain (8131/8111) on link2,
-		// but put 8151 on link0
-		max =
-		    amdk8_scan_chain(dev, nodeid, sblink, sblink, max,
-				     offset_unitid);
-#endif
-	}
-
-	for (link = 0; link < dev->links; link++) {
-#if SB_HT_CHAIN_ON_BUS0 > 0
-		if ((nodeid == 0) && (sblink == link))
-			continue;	//already done
-#endif
-		offset_unitid = 0;
-#if ((HT_CHAIN_UNITID_BASE != 1) || (HT_CHAIN_END_UNITID_BASE != 0x20))
-#if SB_HT_CHAIN_UNITID_OFFSET_ONLY == 1
-		if ((nodeid == 0) && (sblink == link))
-#endif
-			offset_unitid = 1;
-#endif
-
-		max = amdk8_scan_chain(dev, nodeid, link, sblink, max,
-				       offset_unitid);
-	}
-
-	return max;
-}
-
-/** 
- * reg_useable
- * @param reg register to check
- * @param goal_dev device to own the resource
- * @param goal_nodeid node number
- * @param goal_link link number
- * @return 0 if not useable, 1 if useable, or 2 if the pair is free
- */
-static int reg_useable(unsigned reg,
-		       struct device *goal_dev, unsigned goal_nodeid,
-		       unsigned goal_link)
-{
-	struct resource *res = NULL;
-	struct device *dev = NULL;
-	unsigned nodeid = 0, link = 0;
-	int result;
-
-	/* Look for the resource that matches this register. */
-	while (!res
-	       && (dev = dev_find_pci_device(PCI_VENDOR_ID_AMD, 0x1100, dev))) {
-		for (link = 0; !res && (link < 3); link++) {
-			res = probe_resource(dev, 0x100 + (reg | link));
-		}
-		nodeid++;
-	}
-
-	/* If no allocated resource was found, it is free - return 2 */
-	result = 2;
-	if (res) {
-		result = 0;
-		/* If the resource is allocated to the link and node already */
-		if ((goal_link == (link - 1)) &&
-		    (goal_nodeid == (nodeid - 1)) && (res->flags <= 1)) {
-			result = 1;
-		}
-	}
-
-	return result;
-}
-
-static struct resource *amdk8_find_iopair(struct device *dev, unsigned nodeid,
-					  unsigned link)
-{
-	struct resource *resource;
-	unsigned free_reg, reg;
-	resource = NULL;
-	free_reg = 0;
-	for (reg = 0xc0; reg <= 0xd8; reg += 0x8) {
-		int result;
-		result = reg_useable(reg, dev, nodeid, link);
-		if (result == 1) {
-			/* I have been allocated this one */
-			break;
-		} else if (result > 1) {
-			/* I have a free register pair */
-			free_reg = reg;
-		}
-	}
-	if (reg > 0xd8) {
-		reg = free_reg;
-	}
-	if (reg > 0) {
-		resource = new_resource(dev, 0x100 + (reg | link));
-	}
-	return resource;
-}
-
-static struct resource *amdk8_find_mempair(struct device *dev, unsigned nodeid,
-					   unsigned link)
-{
-	struct resource *resource;
-	unsigned free_reg, reg;
-	resource = NULL;
-	free_reg = 0;
-	for (reg = 0x80; reg <= 0xb8; reg += 0x8) {
-		int result;
-		result = reg_useable(reg, dev, nodeid, link);
-		if (result == 1) {
-			/* I have been allocated this one */
-			break;
-		} else if (result > 1) {
-			/* I have a free register pair */
-			free_reg = reg;
-		}
-	}
-	if (reg > 0xb8) {
-		reg = free_reg;
-	}
-	if (reg > 0) {
-		resource = new_resource(dev, 0x100 + (reg | link));
-	}
-	return resource;
-}
-
-static void amdk8_link_read_bases(struct device *dev, unsigned nodeid,
-				  unsigned link)
-{
-	struct resource *resource;
-
-	/* Initialize the io space constraints on the current bus */
-	resource = amdk8_find_iopair(dev, nodeid, link);
-	if (resource) {
-		resource->base = 0;
-		resource->size = 0;
-		resource->align = log2c(HT_IO_HOST_ALIGN);
-		resource->gran = log2c(HT_IO_HOST_ALIGN);
-		resource->limit = 0xffffUL;
-		resource->flags = IORESOURCE_IO;
-	}
-
-	/* Initialize the prefetchable memory constraints on the current bus */
-	resource = amdk8_find_mempair(dev, nodeid, link);
-	if (resource) {
-		resource->base = 0;
-		resource->size = 0;
-		resource->align = log2c(HT_MEM_HOST_ALIGN);
-		resource->gran = log2c(HT_MEM_HOST_ALIGN);
-		resource->limit = 0xffffffffffULL;
-		resource->flags = IORESOURCE_MEM | IORESOURCE_PREFETCH;
-	}
-
-	/* Initialize the memory constraints on the current bus */
-	resource = amdk8_find_mempair(dev, nodeid, link);
-	if (resource) {
-		resource->base = 0;
-		resource->size = 0;
-		resource->align = log2c(HT_MEM_HOST_ALIGN);
-		resource->gran = log2c(HT_MEM_HOST_ALIGN);
-		resource->limit = 0xffffffffffULL;
-		resource->flags = IORESOURCE_MEM;
-	}
-}
-
-static void amdk8_read_resources(struct device *dev)
-{
-	printk(BIOS_DEBUG, "amdk8_read_resources\n");
-	unsigned nodeid, link;
-	nodeid = amdk8_nodeid(dev);
-
-	for (link = 0; link < dev->links; link++) {
-		if (dev->link[link].children) {
-			printk(BIOS_DEBUG, "amdk8_read_resources link %d\n",
-			       link);
-			amdk8_link_read_bases(dev, nodeid, link);
-		}
-	}
-	printk(BIOS_DEBUG, "amdk8_read_resources done\n");
-}
-
-static void amdk8_set_resource(struct device *dev, struct resource *resource,
-			       unsigned nodeid)
-{
-	resource_t rbase, rend;
-	unsigned reg, link;
-	char buf[50];
-	printk(BIOS_DEBUG, "amdk8_set_resource\n");
-	/* Make certain the resource has actually been set */
-	if (!(resource->flags & IORESOURCE_ASSIGNED)) {
-		return;
-	}
-
-	/* If I have already stored this resource don't worry about it */
-	if (resource->flags & IORESOURCE_STORED) {
-		return;
-	}
-
-	/* Only handle PCI memory and IO resources */
-	if (!(resource->flags & (IORESOURCE_MEM | IORESOURCE_IO)))
-		return;
-
-	/* Ensure I am actually looking at a resource of function 1 */
-	if (resource->index < 0x100) {
-		return;
-	}
-	/* Get the base address */
-	rbase = resource->base;
-
-	/* Get the limit (rounded up) */
-	rend = resource_end(resource);
-
-	/* Get the register and link */
-	reg = resource->index & 0xfc;
-	link = resource->index & 3;
-
-	if (resource->flags & IORESOURCE_IO) {
-		u32 base, limit;
-		base = f1_read_config32(reg);
-		limit = f1_read_config32(reg + 0x4);
-		base &= 0xfe000fcc;
-		base |= rbase & 0x01fff000;
-		base |= 3;
-		limit &= 0xfe000fc8;
-		limit |= rend & 0x01fff000;
-		limit |= (link & 3) << 4;
-		limit |= (nodeid & 7);
-
-		if (dev->link[link].bridge_ctrl & PCI_BRIDGE_CTL_VGA) {
-			printk(BIOS_SPEW,
-			       "%s, enabling legacy VGA IO forwarding for %s link %x\n",
-			       __func__, dev_path(dev), link);
-			base |= PCI_IO_BASE_VGA_EN;
-		}
-		if (dev->link[link].bridge_ctrl & PCI_BRIDGE_CTL_NO_ISA) {
-			base |= PCI_IO_BASE_NO_ISA;
-		}
-
-		f1_write_config32(reg + 0x4, limit);
-		f1_write_config32(reg, base);
-	} else if (resource->flags & IORESOURCE_MEM) {
-		u32 base, limit;
-		base = f1_read_config32(reg);
-		limit = f1_read_config32(reg + 0x4);
-		base &= 0x000000f0;
-		base |= (rbase >> 8) & 0xffffff00;
-		base |= 3;
-		limit &= 0x00000048;
-		limit |= (rend >> 8) & 0xffffff00;
-		limit |= (link & 3) << 4;
-		limit |= (nodeid & 7);
-		f1_write_config32(reg + 0x4, limit);
-		f1_write_config32(reg, base);
-	}
-	resource->flags |= IORESOURCE_STORED;
-	sprintf(buf, " <node %d link %d>", nodeid, link);
-	report_resource_stored(dev, resource, buf);
-}
-
-/**
- *
- * I tried to reuse the resource allocation code in amdk8_set_resource()
- * but it is too diffcult to deal with the resource allocation magic.
- */
-#ifdef CONFIG_MULTIPLE_VGA_INIT
-extern struct device *vga_pri;	// the primary vga device, defined in device.c
-#endif
-
-static void amdk8_create_vga_resource(struct device *dev, unsigned nodeid)
-{
-	struct resource *resource;
-	unsigned link;
-	u32 base, limit;
-	unsigned reg;
-
-	/* find out which link the VGA card is connected,
-	 * we only deal with the 'first' vga card */
-	for (link = 0; link < dev->links; link++) {
-		if (dev->link[link].bridge_ctrl & PCI_BRIDGE_CTL_VGA) {
-#ifdef CONFIG_MULTIPLE_VGA_INIT
-			printk(BIOS_DEBUG,
-			       "VGA: vga_pri bus num = %d dev->link[link] bus range [%d,%d]\n",
-			       vga_pri->bus->secondary,
-			       dev->link[link].secondary,
-			       dev->link[link].subordinate);
-			/* We need to make sure the vga_pri is under the link */
-			if ((vga_pri->bus->secondary >=
-			     dev->link[link].secondary)
-			    && (vga_pri->bus->secondary <=
-				dev->link[link].subordinate)
-			    )
-#endif
-				break;
-		}
-	}
-
-	/* no VGA card installed */
-	if (link == dev->links)
-		return;
-
-	printk(BIOS_DEBUG, "VGA: %s (aka node %d) link %d has VGA device\n",
-	       dev_path(dev), nodeid, link);
-
-	/* allocate a temp resrouce for legacy VGA buffer */
-	resource = amdk8_find_mempair(dev, nodeid, link);
-	if (!resource) {
-		printk(BIOS_DEBUG,
-		       "VGA: Can not find free mmio reg for legacy VGA buffer\n");
-		return;
-	}
-	resource->base = 0xa0000;
-	resource->size = 0x20000;
-
-	/* write the resource to the hardware */
-	reg = resource->index & 0xfc;
-	base = f1_read_config32(reg);
-	limit = f1_read_config32(reg + 0x4);
-	base &= 0x000000f0;
-	base |= (resource->base >> 8) & 0xffffff00;
-	base |= 3;
-	limit &= 0x00000048;
-	limit |= (resource_end(resource) >> 8) & 0xffffff00;
-	limit |= (resource->index & 3) << 4;
-	limit |= (nodeid & 7);
-	f1_write_config32(reg + 0x4, limit);
-	f1_write_config32(reg, base);
-
-	/* release the temp resource */
-	resource->flags = 0;
-}
-
-static void amdk8_set_resources(struct device *dev)
-{
-	unsigned nodeid, link;
-	int i;
-
-	/* Find the nodeid */
-	nodeid = amdk8_nodeid(dev);
-
-	printk(BIOS_DEBUG, "amdk8_set_resources: nodeid %d\n", nodeid);
-	amdk8_create_vga_resource(dev, nodeid);
-
-	/* Set each resource we have found */
-	for (i = 0; i < dev->resources; i++) {
-		amdk8_set_resource(dev, &dev->resource[i], nodeid);
-	}
-
-	for (link = 0; link < dev->links; link++) {
-		struct bus *bus;
-		bus = &dev->link[link];
-		if (bus->children) {
-			phase4_set_resources(bus);
-		}
-	}
-}
-
-static void amdk8_enable_resources(struct device *dev)
-{
-	printk(BIOS_DEBUG, "amdk8_enable_resources\n");
-	pci_dev_enable_resources(dev);
-	enable_childrens_resources(dev);
-}
-
 static void mcf0_control_init(struct device *dev)
 {
 	printk(BIOS_DEBUG, "NB: Function 0 Misc Control.. Nothing to do ...");
@@ -585,21 +53,15 @@
 	printk(BIOS_DEBUG, "done.\n");
 }
 
-#ifdef CONFIG_PCI_64BIT_PREF_MEM
-#define BRIDGE_IO_MASK (IORESOURCE_IO | IORESOURCE_MEM | IORESOURCE_PREFETCH)
-#endif
-
 struct device_operations k8_ops = {
 	.id = {.type = DEVICE_ID_PCI,
 	       {.pci = {.vendor = PCI_VENDOR_ID_AMD,
 			.device = 0x1100}}},
 	.constructor		 = default_device_constructor,
-	.reset_bus		 = pci_bus_reset,
-	.phase3_scan		 = amdk8_scan_chains,
-	.phase4_read_resources	 = amdk8_read_resources,
-	.phase4_set_resources	 = amdk8_set_resources,
-	.phase5_enable_resources = amdk8_enable_resources,
+	.phase3_scan		 = NULL,
+	.phase4_read_resources	 = pci_dev_read_resources,
+	.phase4_set_resources	 = pci_set_resources,
+	.phase5_enable_resources = pci_dev_enable_resources,
 	.phase6_init		 = mcf0_control_init,
-	.ops_pci		 = &pci_dev_ops_pci,
 	.ops_pci_bus		 = &pci_cf8_conf1,
 };




From mylesgw at gmail.com  Mon Jan  5 17:01:04 2009
From: mylesgw at gmail.com (Myles Watson)
Date: Mon, 5 Jan 2009 09:01:04 -0700
Subject: [coreboot] K8 patch for new v3 allocator
In-Reply-To: <13426df10812311658u49f1eb2du622e7d0280e03d79@mail.gmail.com>
References: <2831fecf0812311351j243c9f98qa3524e67aa6ed3c@mail.gmail.com>
	<13426df10812311658u49f1eb2du622e7d0280e03d79@mail.gmail.com>
Message-ID: <2831fecf0901050801t1c531a9bt50b74903bc27b7ca@mail.gmail.com>

On Wed, Dec 31, 2008 at 5:58 PM, ron minnich <rminnich at gmail.com> wrote:
> On Wed, Dec 31, 2008 at 1:51 PM, Myles Watson <mylesgw at gmail.com> wrote:
>> This patch makes serengeti work as well as it did before.  I'm interested in
>> feedback.
>>
>> Signed-off-by: Myles Watson <mylesgw at gmail.com>
>>
>
> I've given it two passes and liked it each time.
>
> Acked-by: Ronald G. Minnich <rminnich at gmail.com>

Rev 1094.

Thanks,
Myles



From svn at coreboot.org  Mon Jan  5 18:41:55 2009
From: svn at coreboot.org (svn at coreboot.org)
Date: Mon,  5 Jan 2009 18:41:55 +0100
Subject: [coreboot] r1095 - in coreboot-v3: device include/device
Message-ID: <mailman.2630.1355071466.16123.coreboot@coreboot.org>

Author: myles
Date: 2009-01-05 18:41:55 +0100 (Mon, 05 Jan 2009)
New Revision: 1095

Modified:
   coreboot-v3/device/agp_device.c
   coreboot-v3/include/device/agp.h
Log:
This trivial patch makes AGP support compile again.  

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


Modified: coreboot-v3/device/agp_device.c
===================================================================
--- coreboot-v3/device/agp_device.c	2009-01-05 16:00:32 UTC (rev 1094)
+++ coreboot-v3/device/agp_device.c	2009-01-05 17:41:55 UTC (rev 1095)
@@ -55,17 +55,13 @@
 }
 
 /** Default device operations for AGP bridges. */
-static const struct pci_operations agp_bus_ops_pci = {
-	.set_subsystem = 0,
-};
 
 const struct device_operations default_agp_ops_bus = {
-	.read_resources   = pci_bus_read_resources,
-	.set_resources    = pci_set_resources,
-	.enable_resources = pci_bus_enable_resources,
-	.init             = 0,
-	.scan_bus         = agp_scan_bridge,
-	.enable           = 0,
-	.reset_bus        = pci_bus_reset,
-	.ops_pci          = &agp_bus_ops_pci,
+	.phase3_scan		 = agp_scan_bridge,
+	.phase4_read_resources	 = pci_bus_read_resources,
+	.phase4_set_resources	 = pci_set_resources,
+	.phase5_enable_resources = pci_bus_enable_resources,
+	.phase6_init		 = 0,
+	.phase3_enable		 = 0,
+	.reset_bus		 = pci_bus_reset,
 };

Modified: coreboot-v3/include/device/agp.h
===================================================================
--- coreboot-v3/include/device/agp.h	2009-01-05 16:00:32 UTC (rev 1094)
+++ coreboot-v3/include/device/agp.h	2009-01-05 17:41:55 UTC (rev 1095)
@@ -25,6 +25,6 @@
 	unsigned min_devfn, unsigned max_devfn, unsigned int max);
 unsigned int agp_scan_bridge(struct device *dev, unsigned int max);
 
-extern struct device_operations default_agp_ops_bus;
+extern const struct device_operations default_agp_ops_bus;
 
 #endif /* DEVICE_AGP_H */




From mylesgw at gmail.com  Mon Jan  5 20:09:45 2009
From: mylesgw at gmail.com (Myles Watson)
Date: Mon, 5 Jan 2009 12:09:45 -0700
Subject: [coreboot] v3 bus support patch
Message-ID: <2831fecf0901051109n28595c91xf22b86218537c3b8@mail.gmail.com>

This patch introduces {PCIX,PCIE,AGP...}_SUPPORT config variables.

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

Thanks,
Myles

Kconfig:
	Add *_SUPPORT variables.
	Add select statements for the hardware that needs them.

device/Makefile:
	Test *_SUPPORT variables instead of chip names.

device/Kconfig:
	Add *_PLUGIN_SUPPORT variables.

device/pci_device.c:
	Conditionally include headers if *_PLUGIN_SUPPORT.
	Update default drivers to depend on CONFIG_*_PLUGIN_SUPPORT.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: bus_support.diff
Type: text/x-patch
Size: 5322 bytes
Desc: not available
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20090105/73fb66a7/attachment.diff>

From mylesgw at gmail.com  Mon Jan  5 20:11:25 2009
From: mylesgw at gmail.com (Myles Watson)
Date: Mon, 5 Jan 2009 12:11:25 -0700
Subject: [coreboot] v3 add 8131 support
Message-ID: <2831fecf0901051111g484d5855g8079332095e58b25@mail.gmail.com>

This patch does some minor fixups for 8111 and 8132 and adds support for 8131.

southbridge/amd/amd8132/Makefile:
	Trivial whitespace fix.

southbridge/amd/amd8132/amd8132_bridge.c:
	Remove unnecessary includes and fix enable_resources pointer.

southbridge/amd/amd8111/stage1_smbus.c:
	Remove unnecessary includes.

southbridge/amd/amd8131/apic.dts:
southbridge/amd/amd8131/Makefile:
	Copy file from 8132 with trivial changes.

southbridge/amd/amd8131/amd8131_bridge.c:
	Copy v2 driver file and update like 8132.

Kconfig:
	Add SOUTHBRIDGE_AMD_AMD8131.

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

Thanks,
Myles
-------------- next part --------------
A non-text attachment was scrubbed...
Name: amd81xx.diff
Type: text/x-patch
Size: 17091 bytes
Desc: not available
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20090105/e3a669d3/attachment.diff>

From mylesgw at gmail.com  Mon Jan  5 20:12:41 2009
From: mylesgw at gmail.com (Myles Watson)
Date: Mon, 5 Jan 2009 12:12:41 -0700
Subject: [coreboot] V3 resource map fix
Message-ID: <2831fecf0901051112r3bd3d0dcm43451cb61a22e253@mail.gmail.com>

This patch removes the offset_pciio since there is never an offset_pciio an
offset_pciio and an offset_io.  This makes it easier to port things from v2.

It also updates mcp55 and some whitespace there.

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

Thanks,
Myles
-------------- next part --------------
A non-text attachment was scrubbed...
Name: resource_map.diff
Type: text/x-patch
Size: 8770 bytes
Desc: not available
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20090105/9115b827/attachment.diff>

From mylesgw at gmail.com  Mon Jan  5 20:13:42 2009
From: mylesgw at gmail.com (Myles Watson)
Date: Mon, 5 Jan 2009 12:13:42 -0700
Subject: [coreboot] v3 mcp55 warnings
Message-ID: <2831fecf0901051113s245f5804l93fc6ad93d99a127@mail.gmail.com>

This patch removes a couple of warnings from the compilation of mcp55 boards.

* #if CONFIG_HPET -> #ifdef CONFIG_HPET
* unused variables

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

Thanks,
Myles
-------------- next part --------------
A non-text attachment was scrubbed...
Name: mcp55.diff
Type: text/x-patch
Size: 1265 bytes
Desc: not available
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20090105/ae4b063f/attachment.diff>

From mylesgw at gmail.com  Mon Jan  5 20:14:39 2009
From: mylesgw at gmail.com (Myles Watson)
Date: Mon, 5 Jan 2009 12:14:39 -0700
Subject: [coreboot] v3 ck804 support
Message-ID: <2831fecf0901051114l4836e020hfe91f76b788ff87b@mail.gmail.com>

This patch adds southbridge/nvidia/ck804 from v2 minimally updated for v3.

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

Thanks,
Myles
-------------- next part --------------
A non-text attachment was scrubbed...
Name: ck804.diff
Type: text/x-patch
Size: 90799 bytes
Desc: not available
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20090105/c5121fb1/attachment.diff>

From mylesgw at gmail.com  Mon Jan  5 20:15:59 2009
From: mylesgw at gmail.com (Myles Watson)
Date: Mon, 5 Jan 2009 12:15:59 -0700
Subject: [coreboot] v3 Tyan s2892
Message-ID: <2831fecf0901051115l154c9ebdo258c718ad095b067@mail.gmail.com>

This patch adds initial support for mainboard/tyan/s2892.  It compiles, but is
untested in hardware.

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

Thanks,
Myles
-------------- next part --------------
A non-text attachment was scrubbed...
Name: tyan.diff
Type: text/x-patch
Size: 32229 bytes
Desc: not available
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20090105/bab4c78d/attachment.diff>

From peter at stuge.se  Mon Jan  5 23:03:18 2009
From: peter at stuge.se (Peter Stuge)
Date: Mon, 5 Jan 2009 23:03:18 +0100
Subject: [coreboot] v3 mcp55 warnings
In-Reply-To: <2831fecf0901051113s245f5804l93fc6ad93d99a127@mail.gmail.com>
References: <2831fecf0901051113s245f5804l93fc6ad93d99a127@mail.gmail.com>
Message-ID: <20090105220318.3714.qmail@stuge.se>

Myles Watson wrote:
> This patch removes a couple of warnings from the compilation of mcp55 boards.
> 
> * #if CONFIG_HPET -> #ifdef CONFIG_HPET
> * unused variables
> 
> Signed-off-by: Myles Watson <mylesgw at gmail.com>

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



From svn at coreboot.org  Mon Jan  5 23:13:49 2009
From: svn at coreboot.org (svn at coreboot.org)
Date: Mon,  5 Jan 2009 23:13:49 +0100
Subject: [coreboot] r1096 - coreboot-v3/southbridge/nvidia/mcp55
Message-ID: <mailman.2631.1355071466.16123.coreboot@coreboot.org>

Author: myles
Date: 2009-01-05 23:13:49 +0100 (Mon, 05 Jan 2009)
New Revision: 1096

Modified:
   coreboot-v3/southbridge/nvidia/mcp55/lpc.c
   coreboot-v3/southbridge/nvidia/mcp55/smbus.c
   coreboot-v3/southbridge/nvidia/mcp55/stage1.c
Log:
This patch removes a couple of warnings from the compilation of mcp55 boards.

* #if CONFIG_HPET -> #ifdef CONFIG_HPET
* unused variables

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


Modified: coreboot-v3/southbridge/nvidia/mcp55/lpc.c
===================================================================
--- coreboot-v3/southbridge/nvidia/mcp55/lpc.c	2009-01-05 17:41:55 UTC (rev 1095)
+++ coreboot-v3/southbridge/nvidia/mcp55/lpc.c	2009-01-05 22:13:49 UTC (rev 1096)
@@ -157,7 +157,7 @@
 	lpc_common_init(dev, 0);
 }
 
-#if CONFIG_HPET
+#ifdef CONFIG_HPET
 static void enable_hpet(struct device *dev)
 {
 	unsigned long hpet_address;

Modified: coreboot-v3/southbridge/nvidia/mcp55/smbus.c
===================================================================
--- coreboot-v3/southbridge/nvidia/mcp55/smbus.c	2009-01-05 17:41:55 UTC (rev 1095)
+++ coreboot-v3/southbridge/nvidia/mcp55/smbus.c	2009-01-05 22:13:49 UTC (rev 1096)
@@ -104,7 +104,6 @@
 
 static void mcp55_sm_read_resources(struct device *dev)
 {
-	struct resource *res;
 	unsigned long index;
 
 	/* Get the normal pci resources of this device */

Modified: coreboot-v3/southbridge/nvidia/mcp55/stage1.c
===================================================================
--- coreboot-v3/southbridge/nvidia/mcp55/stage1.c	2009-01-05 17:41:55 UTC (rev 1095)
+++ coreboot-v3/southbridge/nvidia/mcp55/stage1.c	2009-01-05 22:13:49 UTC (rev 1096)
@@ -472,7 +472,6 @@
 void sio_setup(u32 devn)
 {
 
-        unsigned value;
         u32 dword;
         u8 byte;
 
@@ -489,4 +488,3 @@
         pci_conf1_write_config32(PCI_BDF(0, devn+1 , 0), 0xa4, dword);
 }
 
-




From mylesgw at gmail.com  Mon Jan  5 23:14:09 2009
From: mylesgw at gmail.com (Myles Watson)
Date: Mon, 5 Jan 2009 15:14:09 -0700
Subject: [coreboot] v3 mcp55 warnings
In-Reply-To: <20090105220318.3714.qmail@stuge.se>
References: <2831fecf0901051113s245f5804l93fc6ad93d99a127@mail.gmail.com>
	<20090105220318.3714.qmail@stuge.se>
Message-ID: <2831fecf0901051414g5b86a2dcu43b1317e9bcfbf67@mail.gmail.com>

On Mon, Jan 5, 2009 at 3:03 PM, Peter Stuge <peter at stuge.se> wrote:
> Myles Watson wrote:
>> This patch removes a couple of warnings from the compilation of mcp55 boards.
>>
>> * #if CONFIG_HPET -> #ifdef CONFIG_HPET
>> * unused variables
>>
>> Signed-off-by: Myles Watson <mylesgw at gmail.com>
>
> Acked-by: Peter Stuge <peter at stuge.se>

Rev 1096.

Thanks,
Myles



From peter at stuge.se  Mon Jan  5 23:36:51 2009
From: peter at stuge.se (Peter Stuge)
Date: Mon, 5 Jan 2009 23:36:51 +0100
Subject: [coreboot] v3 ck804 support
In-Reply-To: <2831fecf0901051114l4836e020hfe91f76b788ff87b@mail.gmail.com>
References: <2831fecf0901051114l4836e020hfe91f76b788ff87b@mail.gmail.com>
Message-ID: <20090105223651.10427.qmail@stuge.se>

Myles Watson wrote:
> This patch adds southbridge/nvidia/ck804 from v2 minimally updated
> for v3.

Mostly fine, but..


> +	/* If that is invalid we will read that from romstrap. */
> +	if (!eeprom_valid) {
> +		unsigned long mac_pos;
> +		mac_pos = 0xffffffd0; /* See romstrap.inc and romstrap.lds. */
> +		mac_l = readl(mac_pos) + nic_index;
> +		mac_h = readl(mac_pos + 4);
> +	}

..this won't work so well in v3 I think. I'd like a LAR file for the
MAC.


> +#if CONFIG_PCI_ROM_RUN == 1
> +	pci_dev_init(dev);	/* It will init Option ROM. */
> +#endif

Should this be in the NIC code?


> +// 0x7a or e3
> +#define PREVIOUS_POWER_STATE 0x7A
> +
> +#define MAINBOARD_POWER_OFF 0
> +#define MAINBOARD_POWER_ON 1
> +#define SLOW_CPU_OFF 0
> +#define SLOW_CPU__ON 1
> +
> +#ifndef MAINBOARD_POWER_ON_AFTER_POWER_FAIL
> +#define MAINBOARD_POWER_ON_AFTER_POWER_FAIL MAINBOARD_POWER_ON
> +#endif

We should make this a CONFIG_ variable.


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



From peter at stuge.se  Mon Jan  5 23:41:04 2009
From: peter at stuge.se (Peter Stuge)
Date: Mon, 5 Jan 2009 23:41:04 +0100
Subject: [coreboot] v3 bus support patch
In-Reply-To: <2831fecf0901051109n28595c91xf22b86218537c3b8@mail.gmail.com>
References: <2831fecf0901051109n28595c91xf22b86218537c3b8@mail.gmail.com>
Message-ID: <20090105224104.11337.qmail@stuge.se>

Myles Watson wrote:
> This patch introduces {PCIX,PCIE,AGP...}_SUPPORT config variables.
> 
> Signed-off-by: Myles Watson <mylesgw at gmail.com>

Nice! Thanks!

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



From peter at stuge.se  Mon Jan  5 23:43:00 2009
From: peter at stuge.se (Peter Stuge)
Date: Mon, 5 Jan 2009 23:43:00 +0100
Subject: [coreboot] v3 add 8131 support
In-Reply-To: <2831fecf0901051111g484d5855g8079332095e58b25@mail.gmail.com>
References: <2831fecf0901051111g484d5855g8079332095e58b25@mail.gmail.com>
Message-ID: <20090105224300.11666.qmail@stuge.se>

Myles Watson wrote:
> This patch does some minor fixups for 8111 and 8132 and adds support
> for 8131.

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

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



From peter at stuge.se  Mon Jan  5 23:48:20 2009
From: peter at stuge.se (Peter Stuge)
Date: Mon, 5 Jan 2009 23:48:20 +0100
Subject: [coreboot] V3 resource map fix
In-Reply-To: <2831fecf0901051112r3bd3d0dcm43451cb61a22e253@mail.gmail.com>
References: <2831fecf0901051112r3bd3d0dcm43451cb61a22e253@mail.gmail.com>
Message-ID: <20090105224820.12709.qmail@stuge.se>

Myles Watson wrote:
> This patch removes the offset_pciio since there is never an
> offset_pciio an offset_pciio and an offset_io.  This makes it
> easier to port things from v2.
> 
> It also updates mcp55 and some whitespace there.
> 
> Signed-off-by: Myles Watson <mylesgw at gmail.com>

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



From svn at coreboot.org  Mon Jan  5 23:57:46 2009
From: svn at coreboot.org (svn at coreboot.org)
Date: Mon,  5 Jan 2009 23:57:46 +0100
Subject: [coreboot] r1097 - in coreboot-v3: . device
Message-ID: <mailman.2632.1355071466.16123.coreboot@coreboot.org>

Author: myles
Date: 2009-01-05 23:57:45 +0100 (Mon, 05 Jan 2009)
New Revision: 1097

Modified:
   coreboot-v3/Kconfig
   coreboot-v3/device/Kconfig
   coreboot-v3/device/Makefile
   coreboot-v3/device/pci_device.c
Log:
This patch introduces {PCIX,PCIE,AGP...}_SUPPORT config variables.

Kconfig:
       Add *_SUPPORT variables.
       Add select statements for the hardware that needs them.

device/Makefile:
       Test *_SUPPORT variables instead of chip names.

device/Kconfig:
       Add *_PLUGIN_SUPPORT variables.

device/pci_device.c:
       Conditionally include headers if *_PLUGIN_SUPPORT.
       Update default drivers to depend on CONFIG_*_PLUGIN_SUPPORT.

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


Modified: coreboot-v3/Kconfig
===================================================================
--- coreboot-v3/Kconfig	2009-01-05 22:13:49 UTC (rev 1096)
+++ coreboot-v3/Kconfig	2009-01-05 22:57:45 UTC (rev 1097)
@@ -93,10 +93,23 @@
 
 # These are used for internal purposes only:
 
+# Buses:
+config PCIX_SUPPORT
+	boolean
+config PCIE_SUPPORT
+	boolean
+config HYPERTRANSPORT_SUPPORT
+	boolean
+config AGP_SUPPORT
+	boolean
+config CARDBUS_SUPPORT
+	boolean
+
 # Northbridges:
 config NORTHBRIDGE_AMD_GEODELX
 	boolean
 config NORTHBRIDGE_AMD_K8
+	select HYPERTRANSPORT_SUPPORT
 	boolean
 config NORTHBRIDGE_INTEL_I440BXEMULATION
 	boolean
@@ -111,10 +124,13 @@
 config SOUTHBRIDGE_INTEL_I82371EB
 	boolean
 config SOUTHBRIDGE_NVIDIA_MCP55
+	select PCIE_SUPPORT
 	boolean
 config SOUTHBRIDGE_AMD_AMD8151
+	select AGP_SUPPORT
 	boolean
 config SOUTHBRIDGE_AMD_AMD8132
+	select PCIX_SUPPORT
 	boolean
 config SOUTHBRIDGE_AMD_AMD8111
 	boolean

Modified: coreboot-v3/device/Kconfig
===================================================================
--- coreboot-v3/device/Kconfig	2009-01-05 22:13:49 UTC (rev 1096)
+++ coreboot-v3/device/Kconfig	2009-01-05 22:57:45 UTC (rev 1097)
@@ -125,6 +125,45 @@
 
 endmenu
 
+menu "Plugin Support"
+
+config PCIX_PLUGIN_SUPPORT
+	bool "Support for devices that provide PCI-X and aren't in the dts."
+	select PCIX_SUPPORT
+	default false
+	help
+	  Compile in the drivers for cards that provide PCI-X.
+
+config PCIE_PLUGIN_SUPPORT
+	bool "Support for devices that provide PCI-e and aren't in the dts."
+	select PCIE_SUPPORT
+	default false
+	help
+	  Compile in the drivers for cards that provide PCI-e.
+
+config HYPERTRANSPORT_PLUGIN_SUPPORT
+	bool "Support for devices that provide HT and aren't in the dts."
+	select HYPERTRANSPORT_SUPPORT
+	default false
+	help
+	  Compile in the drivers for cards that provide HT.
+
+config AGP_PLUGIN_SUPPORT
+	bool "Support for devices that provide AGP and aren't in the dts."
+	select AGP_SUPPORT
+	default false
+	help
+	  Compile in the drivers for cards that provide AGP.
+
+config CARDBUS_PLUGIN_SUPPORT
+	bool "Support for devices that provide Cardbus and aren't in the dts."
+	select CARDBUS_SUPPORT
+	default false
+	help
+	  Compile in the drivers for cards that provide Cardbus.
+
+endmenu
+
 menu "Power management"
 
 config SUSPEND_TO_RAM

Modified: coreboot-v3/device/Makefile
===================================================================
--- coreboot-v3/device/Makefile	2009-01-05 22:13:49 UTC (rev 1096)
+++ coreboot-v3/device/Makefile	2009-01-05 22:57:45 UTC (rev 1097)
@@ -28,27 +28,23 @@
 		    pci_device.c pci_ops.c pci_rom.c pnp_device.c pnp_raw.c \
 			smbus_ops.c
 
-# this is only needed on the K8
-# This could also check for CONFIG_HYPERTRANSPORT_PLUGIN_SUPPORT
-ifeq ($(CONFIG_NORTHBRIDGE_AMD_K8),y)
+ifeq ($(CONFIG_HYPERTRANSPORT_SUPPORT),y)
 STAGE2_DEVICE_SRC += hypertransport.c
 endif
 
-# this is only needed for pcix devices
-# This should also check for CONFIG_PCIX_PLUGIN_SUPPORT
-ifeq ($(CONFIG_SOUTHBRIDGE_AMD_AMD8132),y)
+ifeq ($(CONFIG_PCIX_SUPPORT),y)
 STAGE2_DEVICE_SRC += pcix_device.c
 endif
 
-ifeq ($(CONFIG_PCIE_PLUGIN_SUPPORT),y)
+ifeq ($(CONFIG_PCIE_SUPPORT),y)
 STAGE2_DEVICE_SRC += pcie_device.c
 endif
 
-ifeq ($(CONFIG_CARDBUS_PLUGIN_SUPPORT),y)
+ifeq ($(CONFIG_CARDBUS_SUPPORT),y)
 STAGE2_DEVICE_SRC += cardbus_device.c
 endif
 
-ifeq ($(CONFIG_AGP_PLUGIN_SUPPORT),y)
+ifeq ($(CONFIG_AGP_SUPPORT),y)
 STAGE2_DEVICE_SRC += agp_device.c
 endif
 

Modified: coreboot-v3/device/pci_device.c
===================================================================
--- coreboot-v3/device/pci_device.c	2009-01-05 22:13:49 UTC (rev 1096)
+++ coreboot-v3/device/pci_device.c	2009-01-05 22:57:45 UTC (rev 1097)
@@ -32,6 +32,22 @@
 #include <device/pci.h>
 #include <device/pci_ids.h>
 
+#ifdef CONFIG_PCIX_PLUGIN_SUPPORT
+#include <device/pcix.h>
+#endif
+#ifdef CONFIG_AGP_PLUGIN_SUPPORT
+#include <device/agp.h>
+#endif
+#ifdef CONFIG_HYPERTRANSPORT_PLUGIN_SUPPORT
+#include <device/hypertransport.h>
+#endif
+#ifdef CONFIG_PCIE_PLUGIN_SUPPORT
+#include <device/pcie.h>
+#endif
+#ifdef CONFIG_CARDBUS_PLUGIN_SUPPORT
+#include <device/cardbus.h>
+#endif
+
 #include <statictree.h>
 
 u8 pci_moving_config8(struct device *dev, unsigned int reg)
@@ -776,7 +792,7 @@
  */
 static const struct device_operations *get_pci_bridge_ops(struct device *dev)
 {
-#ifdef DEVICE_PCIX_H
+#ifdef CONFIG_PCIX_PLUGIN_SUPPORT
 	unsigned int pcix_pos;
 	pcix_pos = pci_find_capability(dev, PCI_CAP_ID_PCIX);
 	if (pcix_pos) {
@@ -785,12 +801,12 @@
 		return &default_pcix_ops_bus;
 	}
 #endif
-#ifdef DEVICE_AGP_H
+#ifdef CONFIG_AGP_PLUGIN_SUPPORT
 	/* How do I detect an PCI to AGP bridge? */
 #warning AGP detection not implemented, so AGP bridge plugin not supported.
 
 #endif
-#ifdef DEVICE_HYPERTRANSPORT_H
+#ifdef CONFIG_HYPERTRANSPORT_PLUGIN_SUPPORT
 	unsigned int ht_pos;
 	ht_pos = 0;
 	while ((ht_pos = pci_find_next_capability(dev, PCI_CAP_ID_HT, ht_pos))) {
@@ -805,7 +821,7 @@
 		}
 	}
 #endif
-#ifdef DEVICE_PCIE_H
+#ifdef CONFIG_PCIE_PLUGIN_SUPPORT
 	unsigned int pcie_pos;
 	pcie_pos = pci_find_capability(dev, PCI_CAP_ID_PCIE);
 	if (pcie_pos) {
@@ -881,7 +897,7 @@
 		else
 			dev->ops = get_pci_bridge_ops(dev);
 		break;
-#ifdef DEVICE_CARDBUS_H
+#ifdef CONFIG_CARDBUS_PLUGIN_SUPPORT
 	case PCI_HEADER_TYPE_CARDBUS:
 		dev->ops = &default_cardbus_ops_bus;
 		break;




From mylesgw at gmail.com  Mon Jan  5 23:58:25 2009
From: mylesgw at gmail.com (Myles Watson)
Date: Mon, 5 Jan 2009 15:58:25 -0700
Subject: [coreboot] v3 bus support patch
In-Reply-To: <20090105224104.11337.qmail@stuge.se>
References: <2831fecf0901051109n28595c91xf22b86218537c3b8@mail.gmail.com>
	<20090105224104.11337.qmail@stuge.se>
Message-ID: <2831fecf0901051458v4a3a35b9p4d6fc1c67e4de227@mail.gmail.com>

On Mon, Jan 5, 2009 at 3:41 PM, Peter Stuge <peter at stuge.se> wrote:
> Myles Watson wrote:
>> This patch introduces {PCIX,PCIE,AGP...}_SUPPORT config variables.
>>
>> Signed-off-by: Myles Watson <mylesgw at gmail.com>
>
> Nice! Thanks!

:)

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

Rev 1097.

Thanks,
Myles



From svn at coreboot.org  Tue Jan  6 00:02:16 2009
From: svn at coreboot.org (svn at coreboot.org)
Date: Tue,  6 Jan 2009 00:02:16 +0100
Subject: [coreboot] r1098 - in coreboot-v3: . southbridge/amd
	southbridge/amd/amd8111 southbridge/amd/amd8131
	southbridge/amd/amd8132
Message-ID: <mailman.2633.1355071466.16123.coreboot@coreboot.org>

Author: myles
Date: 2009-01-06 00:02:16 +0100 (Tue, 06 Jan 2009)
New Revision: 1098

Added:
   coreboot-v3/southbridge/amd/amd8131/
   coreboot-v3/southbridge/amd/amd8131/Makefile
   coreboot-v3/southbridge/amd/amd8131/amd8131_bridge.c
   coreboot-v3/southbridge/amd/amd8131/apic.dts
   coreboot-v3/southbridge/amd/amd8131/pcix.dts
Modified:
   coreboot-v3/Kconfig
   coreboot-v3/southbridge/amd/amd8111/stage1_smbus.c
   coreboot-v3/southbridge/amd/amd8132/Makefile
   coreboot-v3/southbridge/amd/amd8132/amd8132_bridge.c
Log:
This patch does some minor fixups for 8111 and 8132 and adds support for 8131.

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


Modified: coreboot-v3/Kconfig
===================================================================
--- coreboot-v3/Kconfig	2009-01-05 22:57:45 UTC (rev 1097)
+++ coreboot-v3/Kconfig	2009-01-05 23:02:16 UTC (rev 1098)
@@ -132,6 +132,9 @@
 config SOUTHBRIDGE_AMD_AMD8132
 	select PCIX_SUPPORT
 	boolean
+config SOUTHBRIDGE_AMD_AMD8131
+	select PCIX_SUPPORT
+	boolean
 config SOUTHBRIDGE_AMD_AMD8111
 	boolean
 config SOUTHBRIDGE_AMD_SB600

Modified: coreboot-v3/southbridge/amd/amd8111/stage1_smbus.c
===================================================================
--- coreboot-v3/southbridge/amd/amd8111/stage1_smbus.c	2009-01-05 22:57:45 UTC (rev 1097)
+++ coreboot-v3/southbridge/amd/amd8111/stage1_smbus.c	2009-01-05 23:02:16 UTC (rev 1098)
@@ -22,15 +22,9 @@
  * Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA, 02110-1301 USA
  */
 #include <types.h>
-#include <lib.h>
 #include <console.h>
 #include <device/pci.h>
-#include <msr.h>
-#include <legacy.h>
 #include <device/pci_ids.h>
-#include <statictree.h>
-#include <config.h>
-#include "amd8111.h"
 #include "amd8111_smbus.h"
 
 #define SMBUS_IO_BASE 0x0f00

Added: coreboot-v3/southbridge/amd/amd8131/Makefile
===================================================================
--- coreboot-v3/southbridge/amd/amd8131/Makefile	                        (rev 0)
+++ coreboot-v3/southbridge/amd/amd8131/Makefile	2009-01-05 23:02:16 UTC (rev 1098)
@@ -0,0 +1,26 @@
+##
+## This file is part of the coreboot project.
+##
+## Copyright (C) 2007 coresystems GmbH
+## (Written by Stefan Reinauer <stepan at coresystems.de> for coresystems GmbH)
+##
+## This program is free software; you can redistribute it and/or modify
+## it under the terms of the GNU General Public License as published by
+## the Free Software Foundation; either version 2 of the License, or
+## (at your option) any later version.
+##
+## 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
+##
+
+ifeq ($(CONFIG_SOUTHBRIDGE_AMD_AMD8131),y)
+
+STAGE2_CHIPSET_SRC += $(src)/southbridge/amd/amd8131/amd8131_bridge.c
+
+endif

Added: coreboot-v3/southbridge/amd/amd8131/amd8131_bridge.c
===================================================================
--- coreboot-v3/southbridge/amd/amd8131/amd8131_bridge.c	                        (rev 0)
+++ coreboot-v3/southbridge/amd/amd8131/amd8131_bridge.c	2009-01-05 23:02:16 UTC (rev 1098)
@@ -0,0 +1,399 @@
+/*
+ * This file is part of the coreboot project.
+ *
+ * Copyright (C) 2003-2004 Linux Networx
+ *
+ * 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 <lib.h>
+#include <console.h>
+#include <device/pci.h>
+#include <mc146818rtc.h>
+#include <device/pcix.h>
+#include <device/pci_ids.h>
+
+#define NMI_OFF 0
+
+static void amd8131_walk_children(struct bus *bus,
+	void (*visit)(struct device * dev, void *ptr), void *ptr)
+{
+	struct device * child;
+	for(child = bus->children; child; child = child->sibling)
+	{
+		if (child->path.type != DEVICE_PATH_PCI) {
+			continue;
+		}
+		if (child->hdr_type == PCI_HEADER_TYPE_BRIDGE) {
+			amd8131_walk_children(&child->link[0], visit, ptr);
+		}
+		visit(child, ptr);
+	}
+}
+
+struct amd8131_bus_info {
+	unsigned sstatus;
+	unsigned rev;
+	int errata_56;
+	int master_devices;
+	int max_func;
+};
+
+static void amd8131_count_dev(struct device * dev, void *ptr)
+{
+	struct amd8131_bus_info *info = ptr;
+	/* Don't count pci bridges */
+	if (dev->hdr_type != PCI_HEADER_TYPE_BRIDGE) {
+		info->master_devices++;
+	}
+	if (PCI_FUNC(dev->path.pci.devfn) > info->max_func) {
+		info->max_func = PCI_FUNC(dev->path.pci.devfn);
+	}
+}
+
+
+static void amd8131_pcix_tune_dev(struct device * dev, void *ptr)
+{
+	struct amd8131_bus_info *info = ptr;
+	unsigned cap;
+	unsigned status, cmd, orig_cmd;
+	unsigned max_read, max_tran;
+	int sib_funcs, sibs;
+	struct device * sib;
+
+	if (dev->hdr_type != PCI_HEADER_TYPE_NORMAL) {
+		return;
+	}
+	cap = pci_find_capability(dev, PCI_CAP_ID_PCIX);
+	if (!cap) {
+		return;
+	}
+	/* How many siblings does this device have? */
+	sibs = info->master_devices - 1;
+	/* Count how many sibling functions this device has */
+	sib_funcs = 0;
+	for(sib = dev->bus->children; sib; sib = sib->sibling) {
+		if (sib == dev) {
+			continue;
+		}
+		if (PCI_SLOT(sib->path.pci.devfn) != PCI_SLOT(dev->path.pci.devfn)) {
+			continue;
+		}
+		sib_funcs++;
+	}
+
+	printk(BIOS_DEBUG,"%s AMD8131 PCI-X tuning\n", dev_path(dev));
+	status = pci_read_config32(dev, cap + PCI_X_STATUS);
+	orig_cmd = cmd = pci_read_config16(dev,cap + PCI_X_CMD);
+
+	max_read = (status & PCI_X_STATUS_MAX_READ) >> 21;
+	max_tran = (status & PCI_X_STATUS_MAX_SPLIT) >> 23;
+
+	/* Errata #49 don't allow 4K transactions */
+	if (max_read >= 2) {
+		max_read = 2;
+	}
+
+	/* Errata #37 Limit the number of split transactions to avoid starvation */
+	if (sibs >= 2) {
+		/* At most 2 outstanding split transactions when we have
+		 * 3 or more bus master devices on the bus.
+		 */
+		if (max_tran > 1) {
+			max_tran = 1;
+		}
+	}
+	else if (sibs == 1) {
+		/* At most 4 outstanding split transactions when we have
+		 * 2 bus master devices on the bus.
+		 */
+		if (max_tran > 3) {
+			max_tran = 3;
+		}
+	}
+	else {
+		/* At most 8 outstanding split transactions when we have
+		 * only one bus master device on the bus.
+		 */
+		if (max_tran > 4) {
+			max_tran = 4;
+		}
+	}
+	/* Errata #56 additional limits when the bus runs at 133Mhz */
+	if (info->errata_56 &&
+		(PCI_X_SSTATUS_MFREQ(info->sstatus) == PCI_X_SSTATUS_MODE1_133MHZ))
+	{
+		unsigned limit_read;
+		/* Look at the number of siblings and compute the
+		 * largest legal read size.
+		 */
+		if (sib_funcs == 0) {
+			/* 2k reads */
+			limit_read = 2;
+		}
+		else if (sib_funcs <= 1) {
+			/* 1k reads */
+			limit_read = 1;
+		}
+		else {
+			/* 512 byte reads */
+			limit_read = 0;
+		}
+		if (max_read > limit_read) {
+			max_read = limit_read;
+		}
+		/* Look at the read size and the nubmer of siblings
+		 * and compute how many outstanding transactions I can have.
+		 */
+		if (max_read == 2) {
+			/* 2K reads */
+			if (max_tran > 0) {
+				/* Only 1 outstanding transaction allowed */
+				max_tran = 0;
+			}
+		}
+		else if (max_read == 1) {
+			/* 1K reads */
+			if (max_tran > (1 - sib_funcs)) {
+				/* At most 2 outstanding transactions */
+				max_tran = 1 - sib_funcs;
+			}
+		}
+		else {
+			/* 512 byte reads */
+			max_read = 0;
+			if (max_tran > (2 - sib_funcs)) {
+				/* At most 3 outstanding transactions */
+				max_tran = 2 - sib_funcs;
+			}
+		}
+	}
+#if 0
+	printk(BIOS_DEBUG, "%s max_read: %d max_tran: %d sibs: %d sib_funcs: %d\n",
+		dev_path(dev), max_read, max_tran, sibs, sib_funcs, sib_funcs);
+#endif
+	if (max_read != ((cmd & PCI_X_CMD_MAX_READ) >> 2)) {
+		cmd &= ~PCI_X_CMD_MAX_READ;
+		cmd |= max_read << 2;
+		}
+	if (max_tran != ((cmd & PCI_X_CMD_MAX_SPLIT) >> 4)) {
+		cmd &= ~PCI_X_CMD_MAX_SPLIT;
+		cmd |= max_tran << 4;
+	}
+
+	/* Don't attempt to handle PCI-X errors */
+	cmd &= ~PCI_X_CMD_DPERR_E;
+	/* The 8131 does not work properly with relax ordering enabled.
+	 * Errata #58
+	 */
+	cmd &= ~PCI_X_CMD_ERO;
+	if (orig_cmd != cmd) {
+		pci_write_config16(dev, cap + PCI_X_CMD, cmd);
+	}
+}
+static unsigned int amd8131_scan_bus(struct bus *bus,
+	unsigned min_devfn, unsigned max_devfn, unsigned int max)
+{
+	struct amd8131_bus_info info;
+	struct bus *pbus;
+	unsigned pos;
+
+
+	/* Find the children on the bus */
+	max = pci_scan_bus(bus, min_devfn, max_devfn, max);
+
+	/* Find the revision of the 8131 */
+	info.rev = pci_read_config8(bus->dev, PCI_CLASS_REVISION);
+
+	/* See which errata apply */
+	info.errata_56 = info.rev <= 0x12;
+
+	/* Find the pcix capability and get the secondary bus status */
+	pos = pci_find_capability(bus->dev, PCI_CAP_ID_PCIX);
+	info.sstatus = pci_read_config16(bus->dev, pos + PCI_X_SEC_STATUS);
+
+	/* Print the PCI-X bus speed */
+	printk(BIOS_DEBUG, "PCI: %02x: %s\n", bus->secondary, pcix_speed(info.sstatus));
+
+
+	/* Examine the bus and find out how loaded it is */
+	info.max_func = 0;
+	info.master_devices  = 0;
+	amd8131_walk_children(bus, amd8131_count_dev, &info);
+
+	/* Disable the bus if there are no devices on it or
+	 * we are running at 133Mhz and have a 4 function device.
+	 * see errata #56
+	 */
+	if (!bus->children ||
+		(info.errata_56 &&
+			(info.max_func >= 3) &&
+			(PCI_X_SSTATUS_MFREQ(info.sstatus) == PCI_X_SSTATUS_MODE1_133MHZ)))
+	{
+		unsigned pcix_misc;
+		/* Disable all of my children */
+		disable_children(bus);
+
+		/* Remember the device is disabled */
+		bus->dev->enabled = 0;
+
+		/* Disable the PCI-X clocks */
+		pcix_misc = pci_read_config32(bus->dev, 0x40);
+		pcix_misc &= ~(0x1f << 16);
+		pci_write_config32(bus->dev, 0x40, pcix_misc);
+
+		return max;
+	}
+
+	/* If we are in conventional PCI mode nothing more is necessary.
+	 */
+	if (PCI_X_SSTATUS_MFREQ(info.sstatus) == PCI_X_SSTATUS_CONVENTIONAL_PCI) {
+		return max;
+	}
+
+
+	/* Tune the devices on the bus */
+	amd8131_walk_children(bus, amd8131_pcix_tune_dev, &info);
+
+	/* Don't allow the 8131 or any of it's parent busses to
+	 * implement relaxed ordering.  Errata #58
+	 */
+	for(pbus = bus; !pbus->disable_relaxed_ordering; pbus = pbus->dev->bus) {
+		printk(BIOS_SPEW, "%s disabling relaxed ordering\n",
+			bus_path(pbus));
+		pbus->disable_relaxed_ordering = 1;
+	}
+	return max;
+}
+
+static unsigned int amd8131_scan_bridge(struct device * dev, unsigned int max)
+{
+	return do_pci_scan_bridge(dev, max, amd8131_scan_bus);
+}
+
+
+static void amd8131_pcix_init(struct device * dev)
+{
+	u32 dword;
+	u16 word;
+	u8 byte;
+	int nmi_option;
+
+	/* Enable memory write and invalidate ??? */
+	byte = pci_read_config8(dev, 0x04);
+        byte |= 0x10;
+        pci_write_config8(dev, 0x04, byte);
+
+	/* Set drive strength */
+	word = pci_read_config16(dev, 0xe0);
+        word = 0x0404;
+        pci_write_config16(dev, 0xe0, word);
+	word = pci_read_config16(dev, 0xe4);
+        word = 0x0404;
+        pci_write_config16(dev, 0xe4, word);
+
+	/* Set impedance */
+	word = pci_read_config16(dev, 0xe8);
+        word = 0x0404;
+        pci_write_config16(dev, 0xe8, word);
+
+	/* Set discard unrequested prefetch data */
+	/* Errata #51 */
+	word = pci_read_config16(dev, 0x4c);
+        word |= 1;
+        pci_write_config16(dev, 0x4c, word);
+
+	/* Set split transaction limits */
+	word = pci_read_config16(dev, 0xa8);
+        pci_write_config16(dev, 0xaa, word);
+	word = pci_read_config16(dev, 0xac);
+        pci_write_config16(dev, 0xae, word);
+
+	/* Set up error reporting, enable all */
+	/* system error enable */
+	dword = pci_read_config32(dev, 0x04);
+        dword |= (1<<8);
+        pci_write_config32(dev, 0x04, dword);
+
+	/* system and error parity enable */
+	dword = pci_read_config32(dev, 0x3c);
+        dword |= (3<<16);
+        pci_write_config32(dev, 0x3c, dword);
+
+	/* NMI enable */
+	nmi_option = NMI_OFF;
+	get_option(&nmi_option, "nmi");
+	if(nmi_option) {
+		dword = pci_read_config32(dev, 0x44);
+        	dword |= (1<<0);
+        	pci_write_config32(dev, 0x44, dword);
+	}
+
+	/* Set up CRC flood enable */
+	dword = pci_read_config32(dev, 0xc0);
+	if(dword) {  /* do device A only */
+		dword = pci_read_config32(dev, 0xc4);
+		dword |= (1<<1);
+		pci_write_config32(dev, 0xc4, dword);
+		dword = pci_read_config32(dev, 0xc8);
+		dword |= (1<<1);
+		pci_write_config32(dev, 0xc8, dword);
+	}
+	return;
+}
+
+struct device_operations amd8131_pcix = {
+	.id = {.type = DEVICE_ID_PCI,
+		{.pci = {.vendor = PCI_VENDOR_ID_AMD,
+			 .device = PCI_DEVICE_ID_AMD_8131_PCIX}}},
+	.constructor		 = default_device_constructor,
+	.reset_bus		 = pci_bus_reset,
+	.phase3_scan		 = amd8131_scan_bridge,
+	.phase4_read_resources	 = pci_bus_read_resources,
+	.phase4_set_resources	 = pci_set_resources,
+	.phase5_enable_resources = pci_bus_enable_resources,
+	.phase6_init		 = amd8131_pcix_init,
+	.ops_pci		 = &pci_bus_ops_pci,
+};
+
+static void ioapic_enable(struct device * dev)
+{
+	u32 value;
+
+	value = pci_read_config32(dev, 0x44);
+	if (dev->enabled) {
+		value |= ((1 << 1) | (1 << 0));
+	} else {
+		value &= ~((1 << 1) | (1 << 0));
+	}
+	pci_write_config32(dev, 0x44, value);
+}
+
+static struct pci_operations pci_ops_pci_dev = {
+	.set_subsystem    = pci_dev_set_subsystem,
+};
+
+struct device_operations amd8131_apic = {
+	.id = {.type = DEVICE_ID_PCI,
+		{.pci = {.vendor = PCI_VENDOR_ID_AMD,
+			 .device = PCI_DEVICE_ID_AMD_8131_IOAPIC}}},
+	.constructor		 = default_device_constructor,
+	.phase3_scan		 = 0,
+	.phase3_chip_setup_dev	 = ioapic_enable,
+	.phase4_read_resources	 = pci_dev_read_resources,
+	.phase4_set_resources	 = pci_set_resources,
+	.phase5_enable_resources = pci_dev_enable_resources,
+	.ops_pci		 = &pci_ops_pci_dev,
+};

Added: coreboot-v3/southbridge/amd/amd8131/apic.dts
===================================================================
--- coreboot-v3/southbridge/amd/amd8131/apic.dts	                        (rev 0)
+++ coreboot-v3/southbridge/amd/amd8131/apic.dts	2009-01-05 23:02:16 UTC (rev 1098)
@@ -0,0 +1,23 @@
+/*
+ * This file is part of the coreboot project.
+ *
+ * Copyright (C) 2008 Ronald G. Minnich <rminnich 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
+ */
+
+{
+	device_operations = "amd8131_apic";
+};

Added: coreboot-v3/southbridge/amd/amd8131/pcix.dts
===================================================================
--- coreboot-v3/southbridge/amd/amd8131/pcix.dts	                        (rev 0)
+++ coreboot-v3/southbridge/amd/amd8131/pcix.dts	2009-01-05 23:02:16 UTC (rev 1098)
@@ -0,0 +1,23 @@
+/*
+ * This file is part of the coreboot project.
+ *
+ * Copyright (C) 2008 Ronald G. Minnich <rminnich 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
+ */
+
+{
+	device_operations = "amd8131_pcix";
+};

Modified: coreboot-v3/southbridge/amd/amd8132/Makefile
===================================================================
--- coreboot-v3/southbridge/amd/amd8132/Makefile	2009-01-05 22:57:45 UTC (rev 1097)
+++ coreboot-v3/southbridge/amd/amd8132/Makefile	2009-01-05 23:02:16 UTC (rev 1098)
@@ -23,5 +23,4 @@
 
 STAGE2_CHIPSET_SRC += $(src)/southbridge/amd/amd8132/amd8132_bridge.c
 
-
 endif

Modified: coreboot-v3/southbridge/amd/amd8132/amd8132_bridge.c
===================================================================
--- coreboot-v3/southbridge/amd/amd8132/amd8132_bridge.c	2009-01-05 22:57:45 UTC (rev 1097)
+++ coreboot-v3/southbridge/amd/amd8132/amd8132_bridge.c	2009-01-05 23:02:16 UTC (rev 1098)
@@ -23,14 +23,8 @@
 #include <console.h>
 #include <device/pci.h>
 #include <device/pcix.h>
-#include <msr.h>
-#include <legacy.h>
 #include <device/pci_ids.h>
-#include <statictree.h>
-#include <config.h>
 
-#define NMI_OFF 0
-
 /* We don't implement this because:
  * 1. There's only one pair of registers for both devices.
  *      - This breaks our model for resource allocation.
@@ -324,12 +318,11 @@
 	.phase3_scan		 = amd8132_scan_bridge,
 	.phase4_read_resources	 = pci_bus_read_resources,
 	.phase4_set_resources	 = pci_set_resources,
-	.phase5_enable_resources = pci_dev_enable_resources,
+	.phase5_enable_resources = pci_bus_enable_resources,
 	.phase6_init		 = amd8132_pcix_init,
 	.ops_pci		 = &pci_bus_ops_pci,
 };
 
-
 static void ioapic_enable(struct device * dev)
 {
 	u32 value;
@@ -342,6 +335,7 @@
 	}
 	pci_write_config32(dev, 0x44, value);
 }
+
 static void amd8132_ioapic_init(struct device * dev)
 {
         u32 dword;




From mylesgw at gmail.com  Tue Jan  6 00:02:49 2009
From: mylesgw at gmail.com (Myles Watson)
Date: Mon, 5 Jan 2009 16:02:49 -0700
Subject: [coreboot] v3 add 8131 support
In-Reply-To: <20090105224300.11666.qmail@stuge.se>
References: <2831fecf0901051111g484d5855g8079332095e58b25@mail.gmail.com>
	<20090105224300.11666.qmail@stuge.se>
Message-ID: <2831fecf0901051502i461adcccna8a8523ceee9d100@mail.gmail.com>

On Mon, Jan 5, 2009 at 3:43 PM, Peter Stuge <peter at stuge.se> wrote:
> Myles Watson wrote:
>> This patch does some minor fixups for 8111 and 8132 and adds support
>> for 8131.
>
>> Signed-off-by: Myles Watson <mylesgw at gmail.com>
>
> Acked-by: Peter Stuge <peter at stuge.se>

Rev 1098.

Thanks,
Myles



From svn at coreboot.org  Tue Jan  6 00:04:13 2009
From: svn at coreboot.org (svn at coreboot.org)
Date: Tue,  6 Jan 2009 00:04:13 +0100
Subject: [coreboot] r1099 - in coreboot-v3: arch/x86 include/arch/x86
	southbridge/nvidia/mcp55
Message-ID: <mailman.2634.1355071466.16123.coreboot@coreboot.org>

Author: myles
Date: 2009-01-06 00:04:13 +0100 (Tue, 06 Jan 2009)
New Revision: 1099

Modified:
   coreboot-v3/arch/x86/resourcemap.c
   coreboot-v3/include/arch/x86/cpu.h
   coreboot-v3/southbridge/nvidia/mcp55/stage1.c
Log:
This patch removes the offset_pciio since there is never an offset_pciio an
offset_pciio and an offset_io.  This makes it easier to port things from v2.

It also updates mcp55 and some whitespace there.

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


Modified: coreboot-v3/arch/x86/resourcemap.c
===================================================================
--- coreboot-v3/arch/x86/resourcemap.c	2009-01-05 23:02:16 UTC (rev 1098)
+++ coreboot-v3/arch/x86/resourcemap.c	2009-01-05 23:04:13 UTC (rev 1099)
@@ -40,8 +40,8 @@
  * @param max The map size
  * @param offset_bdf pci device offset. Note this is a u32 in 
  * 			busdevfn format. See PCI_BDF macro if you are not sure what that is. 
- * @param offset_pciio added to the OR value for setting up PCI IO
- * @param offset_io offset from the io base in the resource map
+ * @param offset_io added to the OR value for setting up PCI IO
+ * 			  or the io base in the resource map
  */
 
 /* NOTE: By doing the config write in this manner we guarantee that this
@@ -49,8 +49,7 @@
  */
 
 void setup_resource_map_x_offset(const struct rmap *rm, u32 max,
-                                 u32 offset_bdf, u32 offset_pciio, 
-                                 u32 offset_io)
+                                 u32 offset_bdf, u32 offset_io)
 {
 	u32 i;
 
@@ -69,7 +68,7 @@
 			  printk(BIOS_DEBUG, "(%x+%x,%x+%x,%x+%x,%x) & %08x | %08x+%08x\n", rm->pcm.bus,
 				offset_bus, rm->pcm.dev, (offset_devfn>>3),
                                  rm->pcm.fn, offset_devfn&3, rm->pcm.reg,
-				 rm->pcm.and,rm->pcm.or, offset_pciio);
+				 rm->pcm.and,rm->pcm.or, offset_io);
                           dev = rm->pcm.dev;
                         where = rm->pcm.reg;
                           dev <<= 3;
@@ -77,7 +76,7 @@
                             dev += offset_devfn;
                           reg = pci_conf1_read_config32(PCI_BDEVFN(rm->pcm.bus + offset_bus, dev),  where);
                           reg &= rm->pcm.and;
-                          reg |= rm->pcm.or + offset_pciio; 
+                          reg |= rm->pcm.or + offset_io;
                           pci_conf1_write_config32(PCI_BDEVFN(rm->pcm.bus + offset_bus, dev), where, reg);
 			}
 			break;
@@ -122,7 +121,6 @@
 
 void setup_resource_map(const struct rmap *rm, u32 max)
 {
-
-  setup_resource_map_x_offset(rm, max, 0, 0, 0);
+	setup_resource_map_x_offset(rm, max, 0, 0);
 }
 

Modified: coreboot-v3/include/arch/x86/cpu.h
===================================================================
--- coreboot-v3/include/arch/x86/cpu.h	2009-01-05 23:02:16 UTC (rev 1098)
+++ coreboot-v3/include/arch/x86/cpu.h	2009-01-05 23:04:13 UTC (rev 1099)
@@ -330,9 +330,8 @@
 	};
 };
 
-void setup_resource_map_x_offset(const struct rmap *rm, u32 max,
-                                 u32 offset_dev, u32 offset_pciio, 
-                                 u32 offset_io);
+void setup_resource_map_x_offset(const struct rmap *rm, u32 max, u32 offset_dev,
+				 u32 offset_io);
 EXPORT_SYMBOL(setup_resource_map_x_offset);
 void setup_resource_map(const struct rmap *rm, u32 max);
 EXPORT_SYMBOL(setup_resource_map);

Modified: coreboot-v3/southbridge/nvidia/mcp55/stage1.c
===================================================================
--- coreboot-v3/southbridge/nvidia/mcp55/stage1.c	2009-01-05 23:02:16 UTC (rev 1098)
+++ coreboot-v3/southbridge/nvidia/mcp55/stage1.c	2009-01-05 23:04:13 UTC (rev 1099)
@@ -37,21 +37,22 @@
 	int set_ht_link_buffer_counts_chain(u8 ht_c_num, unsigned vendorid,  unsigned val);
 	unsigned vendorid = 0x10de;
 	unsigned val = 0x01610109;
-	/* Nvidia mcp55 hardcode, hw can not set it automatically */
+	/* Nvidia mcp55 hardcode, hw can not set it automatically. */
 	return set_ht_link_buffer_counts_chain(ht_c_num, vendorid, val);
 }
 
-void setup_ss_table(unsigned index, unsigned where, unsigned control, const unsigned int *register_values, int max)
+void setup_ss_table(unsigned index, unsigned where, unsigned control,
+		    const unsigned int *register_values, int max)
 {
 	int i;
-
 	unsigned val;
 
 	val = inl(control);
 	val &= 0xfffffffe;
 	outl(val, control);
 
-	outl(0, index); //index
+	outl(0, index);
+
 	for(i = 0; i < max; i++) {
 		unsigned long reg;
 		reg = register_values[i];
@@ -61,7 +62,6 @@
 	val = inl(control);
 	val |= 1;
 	outl(val, control);
-
 }
 
 /* SIZE 0x100 */
@@ -120,12 +120,13 @@
 	for(j = 0; j < mcp55_num; j++ ) {
 		setup_resource_map_x_offset(ctrl_devport_conf,
 			ARRAY_SIZE(ctrl_devport_conf),
-			PCI_BDF(busn[j], devn[j], 0) , io_base[j], 0);
+			PCI_BDF(busn[j], devn[j], 0), io_base[j]);
 	}
 }
-static void mcp55_early_clear_port(unsigned mcp55_num, unsigned *busn, unsigned *devn, unsigned *io_base)
+
+static void mcp55_early_clear_port(unsigned mcp55_num, unsigned *busn,
+				   unsigned *devn, unsigned *io_base)
 {
-
 	static const struct rmap ctrl_devport_conf_clear[] = {
 	PCM(0, 1, 1, ANACTRL_REG_POS, ~0x0000ff00, 0),
 	PCM(0, 1, 1, SYSCTRL_REG_POS, ~0x0000ff00, 0),
@@ -136,10 +137,8 @@
 	for(j = 0; j < mcp55_num; j++ ) {
 		setup_resource_map_x_offset(ctrl_devport_conf_clear,
 			ARRAY_SIZE(ctrl_devport_conf_clear),
-			PCI_BDF(busn[j], devn[j], 0) , io_base[j], 0);
+			PCI_BDF(busn[j], devn[j], 0) , io_base[j]);
 	}
-
-
 }
 
 static void mcp55_early_pcie_setup(unsigned busnx, unsigned devnx, unsigned anactrl_io_base, unsigned pci_e_x)
@@ -181,10 +180,18 @@
 	udelay(100000);
 }
 
-static void mcp55_early_setup(unsigned mcp55_num, unsigned *busn, unsigned *devn, unsigned *io_base, unsigned *pci_e_x)
+/**
+ * Do early setup
+ * @param mcp55_num the number of mcp55s on the board
+ * @param busn the number of the bus the mcp55 is on
+ * @param io_base
+ * @param pci_e_x
+ */
+
+static void mcp55_early_setup(unsigned mcp55_num, unsigned *busn, unsigned *devn,
+			      unsigned *io_base, unsigned *pci_e_x)
 {
-
-    static const struct rmap ctrl_conf_1[] = {
+	static const struct rmap ctrl_conf_1[] = {
 	IO32(ACPICTRL_IO_BASE + 0x10, 0x0007ffff, 0xff78000),
 	IO32(ACPICTRL_IO_BASE + 0xa4, 0xffedffff, 0x0012000),
 	IO32(ACPICTRL_IO_BASE + 0xac, 0xfffffdff, 0x0000200),
@@ -319,50 +326,53 @@
 	IO8(SYSCTRL_IO_BASE + 0xc0+ 4, ~(0xff),  ((0<<4)|(1<<2)|(0<<0))),
 	IO8(SYSCTRL_IO_BASE + 0xc0+ 4, ~(0xff),  ((0<<4)|(1<<2)|(1<<0))),
 #endif
+	};
 
-    };
-
-
 	int j, i;
 
 	for(j=0; j<mcp55_num; j++) {
 		mcp55_early_pcie_setup(busn[j], devn[j], io_base[j] + ANACTRL_IO_BASE, pci_e_x[j]);
 
 		setup_resource_map_x_offset(ctrl_conf_1, ARRAY_SIZE(ctrl_conf_1),
-				PCI_BDF(busn[j], devn[j], 0), io_base[j], 0);
+				PCI_BDF(busn[j], devn[j], 0), io_base[j]);
 		for(i=0; i<3; i++) { // three SATA
 			setup_resource_map_x_offset(ctrl_conf_1_1, ARRAY_SIZE(ctrl_conf_1_1),
-				PCI_BDF(busn[j], devn[j], i), io_base[j], 0);
+				PCI_BDF(busn[j], devn[j], i), io_base[j]);
 		}
 		if(busn[j] == 0) {
 			setup_resource_map_x_offset(ctrl_conf_mcp55_only, ARRAY_SIZE(ctrl_conf_mcp55_only),
-				PCI_BDF(busn[j], devn[j], 0), io_base[j], 0);
+				PCI_BDF(busn[j], devn[j], 0), io_base[j]);
 		}
 
 		if( (busn[j] == 0) && (mcp55_num>1) ) {
 			setup_resource_map_x_offset(ctrl_conf_master_only, ARRAY_SIZE(ctrl_conf_master_only),
-				PCI_BDF(busn[j], devn[j], 0), io_base[j], 0);
+				PCI_BDF(busn[j], devn[j], 0), io_base[j]);
 		}
 
 		setup_resource_map_x_offset(ctrl_conf_2, ARRAY_SIZE(ctrl_conf_2),
-				PCI_BDF(busn[j], devn[j], 0), io_base[j], 0);
+				PCI_BDF(busn[j], devn[j], 0), io_base[j]);
 
 	}
 
 #if 0
 	for(j=0; j< mcp55_num; j++) {
-		// PCI-E (XSPLL) SS table 0x40, x044, 0x48
-		// SATA  (SPPLL) SS table 0xb0, 0xb4, 0xb8
-		// CPU   (PPLL)  SS table 0xc0, 0xc4, 0xc8
-		setup_ss_table(io_base[j] + ANACTRL_IO_BASE+0x40, io_base[j] + ANACTRL_IO_BASE+0x44,
-			io_base[j] + ANACTRL_IO_BASE+0x48, pcie_ss_tbl, 64);
-		setup_ss_table(io_base[j] + ANACTRL_IO_BASE+0xb0, io_base[j] + ANACTRL_IO_BASE+0xb4,
-			io_base[j] + ANACTRL_IO_BASE+0xb8, sata_ss_tbl, 64);
-		setup_ss_table(io_base[j] + ANACTRL_IO_BASE+0xc0, io_base[j] + ANACTRL_IO_BASE+0xc4,
-			io_base[j] + ANACTRL_IO_BASE+0xc8, cpu_ss_tbl, 64);
+		/* PCI-E (XSPLL) SS table 0x40, x044, 0x48 */
+		/* SATA  (SPPLL) SS table 0xb0, 0xb4, 0xb8 */
+		/* CPU   (PPLL)  SS table 0xc0, 0xc4, 0xc8 */
+		setup_ss_table(io_base[j] + ANACTRL_IO_BASE+0x40,
+			       io_base[j] + ANACTRL_IO_BASE+0x44,
+			       io_base[j] + ANACTRL_IO_BASE+0x48,
+			       pcie_ss_tbl, 64);
+		setup_ss_table(io_base[j] + ANACTRL_IO_BASE+0xb0,
+			       io_base[j] + ANACTRL_IO_BASE+0xb4,
+			       io_base[j] + ANACTRL_IO_BASE+0xb8,
+			       sata_ss_tbl, 64);
+		setup_ss_table(io_base[j] + ANACTRL_IO_BASE+0xc0,
+			       io_base[j] + ANACTRL_IO_BASE+0xc4,
+			       io_base[j] + ANACTRL_IO_BASE+0xc8,
+			       cpu_ss_tbl, 64);
 	}
 #endif
-
 }
 
 #ifndef HT_CHAIN_NUM_MAX
@@ -440,7 +450,6 @@
 	}
 
 	return (bdf>>15) & 0x1f;
-
 }
 
 void set_bios_reset(void);




From uwe at hermann-uwe.de  Tue Jan  6 00:04:13 2009
From: uwe at hermann-uwe.de (Uwe Hermann)
Date: Tue, 6 Jan 2009 00:04:13 +0100
Subject: [coreboot] [PATCH] flashrom: Update man page
In-Reply-To: <496166A3.2040705@gmx.net>
References: <496166A3.2040705@gmx.net>
Message-ID: <20090105230413.GB12484@greenwood>

On Mon, Jan 05, 2009 at 02:47:15AM +0100, Carl-Daniel Hailfinger wrote:
> The flashrom man page has incomplete author/copyright sections and an
> incorrect license section.
> - Remove the copyright listings and refer the reader to the source files.

ACK, this is a pita to keep up-to-date in many places (README, manpage,
wiki, source, whatever). The only authoritative place for (C) lines is
(and should be) the source code.


> - Update the author list to those which have copyright messages in the
> source files.
> - Correct the license from GPL v2+ to GPL v2.

That's not quite correct / complete. I'd use a text such as this:

Flashrom is licensed under the terms of the GNU General Public License (GPL).
Some files are licensed under the "GPL (version 2, or any later version)",
and some files are licensed under the "GPL, version 2".


> Signed-off-by: Carl-Daniel Hailfinger <c-d.hailfinger.devel.2006 at gmx.net>
> 
> Index: flashrom-manpage/flashrom.8
> ===================================================================
> --- flashrom-manpage/flashrom.8	(Revision 3811)
> +++ flashrom-manpage/flashrom.8	(Arbeitskopie)
> @@ -1,4 +1,4 @@
> -.TH FLASHROM 8 "June 22, 2008"
> +.TH FLASHROM 8 "January 5, 2009"
>  .SH NAME
>  flashrom \- a universal BIOS/ROM/flash programming utility
>  .SH SYNOPSIS
> @@ -84,22 +84,51 @@
>  .RB "(" http://coreboot.org/Mailinglist ")."
>  .SH LICENCE
>  .B flashrom
> -is covered by the GNU General Public License (GPL), version 2 or later.
> +is covered by the GNU General Public License (GPL), version 2.
>  .SH COPYRIGHT
> -2000 Silicon Integrated System Corporation
>  .br
> -2003 Niki W. Waibel
> -.br
> -2004 Tyan Corp
> -.br
> -2005-2007 coresystems GmbH
> +Please see the individual files.
>  .SH AUTHORS
>  Yinghai Lu <yinghai.lu at amd.com>
>  .br
>  Stefan Reinauer <stepan at coresystems.de>
>  .br
> -Niki W. Waibel <niki.waibel at gmx.net>
> +Ronald G. Minnich <rminnich at gmail.com>
>  .br
> +Steven James <pyro at linuxlabs.com>
> +.br
> +Giampiero Giancipoli <gianci at email.it>
> +.br
> +Uwe Hermann <uwe at hermann-uwe.de>
> +.br

> +2008 Carl-Daniel Hailfinger

Drop this...


> +.br
> +Luc Verhaegen <libv at skynet.be>
> +.br
> +Carl-Daniel Hailfinger

... as this line is also there.


Also, are the entries in some order? Maybe sort alphabetically? This is
what we do in superiotool, I think.


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



From mylesgw at gmail.com  Tue Jan  6 00:04:37 2009
From: mylesgw at gmail.com (Myles Watson)
Date: Mon, 5 Jan 2009 16:04:37 -0700
Subject: [coreboot] V3 resource map fix
In-Reply-To: <20090105224820.12709.qmail@stuge.se>
References: <2831fecf0901051112r3bd3d0dcm43451cb61a22e253@mail.gmail.com>
	<20090105224820.12709.qmail@stuge.se>
Message-ID: <2831fecf0901051504m41c5b1bdl551aa2da46e88de@mail.gmail.com>

On Mon, Jan 5, 2009 at 3:48 PM, Peter Stuge <peter at stuge.se> wrote:
> Myles Watson wrote:
>> This patch removes the offset_pciio since there is never an
>> offset_pciio an offset_pciio and an offset_io.  This makes it
>> easier to port things from v2.
>>
>> It also updates mcp55 and some whitespace there.
>>
>> Signed-off-by: Myles Watson <mylesgw at gmail.com>
>
> Acked-by: Peter Stuge <peter at stuge.se>

Rev 1099.

Thanks,
Myles



From peter at stuge.se  Tue Jan  6 00:07:10 2009
From: peter at stuge.se (Peter Stuge)
Date: Tue, 6 Jan 2009 00:07:10 +0100
Subject: [coreboot] v3 Tyan s2892
In-Reply-To: <2831fecf0901051115l154c9ebdo258c718ad095b067@mail.gmail.com>
References: <2831fecf0901051115l154c9ebdo258c718ad095b067@mail.gmail.com>
Message-ID: <20090105230710.17810.qmail@stuge.se>

Myles Watson wrote:
> This patch adds initial support for mainboard/tyan/s2892.  It
> compiles, but is untested in hardware.

I think this needs a little polishing.


> +++ svn/mainboard/tyan/s2892/dts
..
> +/{
> +	device_operations="s2892";
> +	mainboard_vendor = "AMD";

Tyan, not AMD, right? :)


> +++ svn/mainboard/tyan/Kconfig
..

> +choice
> +	prompt "Mainboard model"
> +	depends on VENDOR_TYAN
> +
> +config BOARD_TYAN_S2892
> +	bool "s2892"
> +	select ARCH_X86
> +	select CPU_AMD_K8
> +	select NORTHBRIDGE_AMD_K8
> +	select SOUTHBRIDGE_NVIDIA_CK804
> +	select SOUTHBRIDGE_AMD_AMD8131
> +	select SUPERIO_WINBOND_W83627HF
> +	select IOAPIC
> +	help
> +	  Tyan Thunder K8SE (s2892)
> +
> +endchoice

Does Kconfig allow choices to span multiple files? If so it would be
nice to not have to repeat the Mainboard model choice for each
vendor.

I would like this option to read "Thunder K8SE (S2892)" as Tyan uses
on the web: http://www.tyan.com/product_board_detail.aspx?pid=145

(And not just the help, but the actual user visible option name.)


> +++ svn/mainboard/tyan/s2892/mainboard.c
..
> +struct device_operations s2892 = {
> +	.id = {.type = DEVICE_ID_PCI,
> +		{.pci = {.vendor = PCI_VENDOR_ID_TYAN,
> +			 .device = 0x2892}}},
> +	.constructor = default_device_constructor,
> +};

Why is this needed? The board itself isn't a PCI device. It can
certainly have a subsystem it belonging to it, but that was already
specified in the dts so must not be needed to duplicate here.


> +++ svn/mainboard/tyan/s2892/stage1.c
..
> +void ck804_enable_rom(void);

This prototype shouldn't be needed here right? What ROM is it anyway?
The NIC? See discussion in ck804 thread.


> +#define SERIAL_DEV W83627HF_SP1
> +#define SERIAL_IOBASE 0x3f8

Isn't at least the iobase in a CONFIG_ already?


> +void mainboard_pre_payload(void)
> +{
> +	banner(BIOS_DEBUG, "mainboard_pre_payload: done");
> +}

Can we remove this function from mainboard sources when it doesn't do
anything like here?


> +++ svn/mainboard/tyan/s2892/initram.c
..
> +/* this code is very mainboard dependent, sadly. */
..
> +/**
> + * read a byte from spd.
> + * @param device device to read from
> + * @param address address in the spd ROM
> + * @return the value of the byte at that address.
> + */
> +u8 spd_read_byte(u16 device, u8 address)
> +{
> +	int smbus_read_byte(u16 device, u16 address);
> +	return smbus_read_byte(device, address);
> +}

I hope you see the irony above.


> +
> +/**
> +  * main for initram for the AMD Serengeti

No, this is for s2892. If this code is copypaste, it can not go in.
I would like us to reuse more.


//Peter



From svn at coreboot.org  Tue Jan  6 00:08:37 2009
From: svn at coreboot.org (svn at coreboot.org)
Date: Tue,  6 Jan 2009 00:08:37 +0100
Subject: [coreboot] r1100 - in coreboot-v3: . include/device
	southbridge/nvidia southbridge/nvidia/ck804
Message-ID: <mailman.2635.1355071466.16123.coreboot@coreboot.org>

Author: myles
Date: 2009-01-06 00:08:37 +0100 (Tue, 06 Jan 2009)
New Revision: 1100

Added:
   coreboot-v3/southbridge/nvidia/ck804/
   coreboot-v3/southbridge/nvidia/ck804/Makefile
   coreboot-v3/southbridge/nvidia/ck804/ck804.c
   coreboot-v3/southbridge/nvidia/ck804/ck804.h
   coreboot-v3/southbridge/nvidia/ck804/ck804_ac97.c
   coreboot-v3/southbridge/nvidia/ck804/ck804_ht.c
   coreboot-v3/southbridge/nvidia/ck804/ck804_nic.c
   coreboot-v3/southbridge/nvidia/ck804/ck804_reset.c
   coreboot-v3/southbridge/nvidia/ck804/ck804_smbus.h
   coreboot-v3/southbridge/nvidia/ck804/ide.c
   coreboot-v3/southbridge/nvidia/ck804/ide.dts
   coreboot-v3/southbridge/nvidia/ck804/lpc.c
   coreboot-v3/southbridge/nvidia/ck804/lpc.dts
   coreboot-v3/southbridge/nvidia/ck804/pci.c
   coreboot-v3/southbridge/nvidia/ck804/pci.dts
   coreboot-v3/southbridge/nvidia/ck804/pcie.c
   coreboot-v3/southbridge/nvidia/ck804/pcie.dts
   coreboot-v3/southbridge/nvidia/ck804/sata.c
   coreboot-v3/southbridge/nvidia/ck804/sata.dts
   coreboot-v3/southbridge/nvidia/ck804/sata1.dts
   coreboot-v3/southbridge/nvidia/ck804/shared_smbus.c
   coreboot-v3/southbridge/nvidia/ck804/smbus.c
   coreboot-v3/southbridge/nvidia/ck804/smbus.dts
   coreboot-v3/southbridge/nvidia/ck804/stage1.c
   coreboot-v3/southbridge/nvidia/ck804/stage1.h
   coreboot-v3/southbridge/nvidia/ck804/stage1_enable_rom.c
   coreboot-v3/southbridge/nvidia/ck804/stage1_smbus.c
   coreboot-v3/southbridge/nvidia/ck804/usb.c
   coreboot-v3/southbridge/nvidia/ck804/usb.dts
   coreboot-v3/southbridge/nvidia/ck804/usb2.c
   coreboot-v3/southbridge/nvidia/ck804/usb2.dts
Modified:
   coreboot-v3/Kconfig
   coreboot-v3/include/device/pci_ids.h
Log:
This patch adds southbridge/nvidia/ck804 from v2 minimally updated for v3.

Peter has some valid points that need to be addressed in the future.  See his
Ack message.

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


Modified: coreboot-v3/Kconfig
===================================================================
--- coreboot-v3/Kconfig	2009-01-05 23:04:13 UTC (rev 1099)
+++ coreboot-v3/Kconfig	2009-01-05 23:08:37 UTC (rev 1100)
@@ -123,6 +123,9 @@
 	boolean
 config SOUTHBRIDGE_INTEL_I82371EB
 	boolean
+config SOUTHBRIDGE_NVIDIA_CK804
+	select PCIE_SUPPORT
+	boolean
 config SOUTHBRIDGE_NVIDIA_MCP55
 	select PCIE_SUPPORT
 	boolean

Modified: coreboot-v3/include/device/pci_ids.h
===================================================================
--- coreboot-v3/include/device/pci_ids.h	2009-01-05 23:04:13 UTC (rev 1099)
+++ coreboot-v3/include/device/pci_ids.h	2009-01-05 23:08:37 UTC (rev 1100)
@@ -265,6 +265,34 @@
 #define PCI_DEVICE_ID_NVIDIA_MCP55_TRIM         0x036A
 #define PCI_DEVICE_ID_NVIDIA_MCP55_PMU          0x036B
 
+#define PCI_DEVICE_ID_NVIDIA_CK804_LPC          0x0050
+#define PCI_DEVICE_ID_NVIDIA_CK804_PRO          0x0051
+#define PCI_DEVICE_ID_NVIDIA_CK804_ISA          0x0051
+#define PCI_DEVICE_ID_NVIDIA_CK804_SMB          0x0052
+#define PCI_DEVICE_ID_NVIDIA_CK804_SM           0x0052
+#define PCI_DEVICE_ID_NVIDIA_CK804_ACPI         0x0052
+#define PCI_DEVICE_ID_NVIDIA_CK804_IDE          0x0053
+#define PCI_DEVICE_ID_NVIDIA_CK804_SATA0        0x0054
+#define PCI_DEVICE_ID_NVIDIA_CK804_SATA1        0x0055
+#define PCI_DEVICE_ID_NVIDIA_CK804_SATA1        0x0055
+#define PCI_DEVICE_ID_NVIDIA_CK804_ENET         0x0056
+#define PCI_DEVICE_ID_NVIDIA_CK804_NIC          0x0056
+#define PCI_DEVICE_ID_NVIDIA_CK804_ENET2        0x0057
+#define PCI_DEVICE_ID_NVIDIA_CK804_NIC_BRIDGE   0x0057
+#define PCI_DEVICE_ID_NVIDIA_CK804_MODEM        0x0058
+#define PCI_DEVICE_ID_NVIDIA_CK804_MCI          0x0058
+#define PCI_DEVICE_ID_NVIDIA_CK804_AUDIO        0x0059
+#define PCI_DEVICE_ID_NVIDIA_CK804_ACI          0x0059
+#define PCI_DEVICE_ID_NVIDIA_CK804_USB          0x005A
+#define PCI_DEVICE_ID_NVIDIA_CK804_USB2         0x005B
+#define PCI_DEVICE_ID_NVIDIA_CK804_PCI          0x005C
+#define PCI_DEVICE_ID_NVIDIA_CK804_PCIE         0x005D
+#define PCI_DEVICE_ID_NVIDIA_CK804_PCI_E        0x005D
+#define PCI_DEVICE_ID_NVIDIA_CK804_MEM          0x005E
+#define PCI_DEVICE_ID_NVIDIA_CK804_HT           0x005E
+#define PCI_DEVICE_ID_NVIDIA_CK804_TRIM         0x005f
+#define PCI_DEVICE_ID_NVIDIA_CK804_SLAVE        0x00d3
+
 #define PCI_VENDOR_ID_VIA			0x1106
 #define PCI_DEVICE_ID_VIA_CN700_AGP		0x0314
 #define PCI_DEVICE_ID_VIA_CN700_ERR		0x1314

Added: coreboot-v3/southbridge/nvidia/ck804/Makefile
===================================================================
--- coreboot-v3/southbridge/nvidia/ck804/Makefile	                        (rev 0)
+++ coreboot-v3/southbridge/nvidia/ck804/Makefile	2009-01-05 23:08:37 UTC (rev 1100)
@@ -0,0 +1,39 @@
+##
+## This file is part of the coreboot project.
+##
+## Copyright (C) 2007 coresystems GmbH
+## (Written by Stefan Reinauer <stepan at coresystems.de> for coresystems GmbH)
+##
+## This program is free software; you can redistribute it and/or modify
+## it under the terms of the GNU General Public License as published by
+## the Free Software Foundation; either version 2 of the License, or
+## (at your option) any later version.
+##
+## 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
+##
+
+ifeq ($(CONFIG_SOUTHBRIDGE_NVIDIA_CK804),y)
+
+STAGE2_CHIPSET_SRC += $(src)/southbridge/nvidia/ck804/ck804.c
+
+ifeq ($(CONFIG_PIRQ_TABLE),y)
+STAGE2_CHIPSET_SRC += $(src)/southbridge/nvidia/ck804/irq_tables.c
+endif
+
+STAGE2_CHIPSET_SRC += $(src)/southbridge/nvidia/ck804/ide.c \
+ 					$(src)/southbridge/nvidia/ck804/pci.c \
+ 					$(src)/southbridge/nvidia/ck804/lpc.c \
+ 					$(src)/southbridge/nvidia/ck804/pcie.c \
+ 					$(src)/southbridge/nvidia/ck804/sata.c \
+					$(src)/southbridge/nvidia/ck804/smbus.c \
+					$(src)/southbridge/nvidia/ck804/usb.c \
+					$(src)/southbridge/nvidia/ck804/usb2.c
+
+endif

Added: coreboot-v3/southbridge/nvidia/ck804/ck804.c
===================================================================
--- coreboot-v3/southbridge/nvidia/ck804/ck804.c	                        (rev 0)
+++ coreboot-v3/southbridge/nvidia/ck804/ck804.c	2009-01-05 23:08:37 UTC (rev 1100)
@@ -0,0 +1,182 @@
+/*
+ * Copyright 2004 Tyan Computer
+ *  by yhlu at tyan.com
+ */
+
+#include <console.h>
+#include <io.h>
+#include <device/device.h>
+#include <device/pci.h>
+#include <device/pci_ids.h>
+#include <device/pci_ops.h>
+#include "ck804.h"
+
+static u32 final_reg;
+
+void ck804_set_subsystem(struct device *dev, u16 vendor, u16 device)
+{
+	pci_write_config32(dev, 0x40, (device << 16) | vendor);
+}
+
+static struct device * find_lpc_dev(struct device * dev, unsigned devfn)
+{
+	struct device * lpc_dev;
+
+	lpc_dev = dev_find_slot(dev->bus->secondary, devfn);
+	if (!lpc_dev)
+		return lpc_dev;
+
+	if ((lpc_dev->id.pci.vendor != PCI_VENDOR_ID_NVIDIA)
+		|| ((lpc_dev->id.pci.device != PCI_DEVICE_ID_NVIDIA_CK804_LPC)
+		&& (lpc_dev->id.pci.device != PCI_DEVICE_ID_NVIDIA_CK804_PRO)
+		&& (lpc_dev->id.pci.device != PCI_DEVICE_ID_NVIDIA_CK804_SLAVE)))
+	{
+		u32 id;
+		id = pci_read_config32(lpc_dev, PCI_VENDOR_ID);
+		if ((id != (PCI_VENDOR_ID_NVIDIA |
+		      (PCI_DEVICE_ID_NVIDIA_CK804_LPC << 16)))
+		    && (id != (PCI_VENDOR_ID_NVIDIA |
+			 (PCI_DEVICE_ID_NVIDIA_CK804_PRO << 16)))
+		    && (id != (PCI_VENDOR_ID_NVIDIA |
+			 (PCI_DEVICE_ID_NVIDIA_CK804_SLAVE << 16))))
+		{
+			lpc_dev = 0;
+		}
+	}
+
+	return lpc_dev;
+}
+
+void ck804_enable(struct device * dev)
+{
+	struct device * lpc_dev;
+	unsigned index = 0, index2 = 0;
+	u32 vendorid;
+	u16 deviceid, devfn;
+	u32 reg_old, reg;
+	u8 byte;
+
+	if (dev->id.pci.device == 0x0000) {
+		vendorid = pci_read_config32(dev, PCI_VENDOR_ID);
+		deviceid = (vendorid >> 16) & 0xffff;
+		/* vendorid &= 0xffff; */
+	} else {
+		/* vendorid = dev->id.pci.vendor; */
+		deviceid = dev->id.pci.device;
+	}
+
+	devfn = (dev->path.pci.devfn) & ~7;
+	switch (deviceid) {
+	case PCI_DEVICE_ID_NVIDIA_CK804_SM:
+		index = 16;
+		break;
+	case PCI_DEVICE_ID_NVIDIA_CK804_USB:
+		devfn -= (1 << 3);
+		index = 8;
+		break;
+	case PCI_DEVICE_ID_NVIDIA_CK804_USB2:
+		devfn -= (1 << 3);
+		index = 20;
+		break;
+	case PCI_DEVICE_ID_NVIDIA_CK804_NIC:
+		devfn -= (9 << 3);
+		index = 10;
+		break;
+	case PCI_DEVICE_ID_NVIDIA_CK804_NIC_BRIDGE:
+		devfn -= (9 << 3);
+		index = 10;
+		break;
+	case PCI_DEVICE_ID_NVIDIA_CK804_ACI:
+		devfn -= (3 << 3);
+		index = 12;
+		break;
+	case PCI_DEVICE_ID_NVIDIA_CK804_MCI:
+		devfn -= (3 << 3);
+		index = 13;
+		break;
+	case PCI_DEVICE_ID_NVIDIA_CK804_IDE:
+		devfn -= (5 << 3);
+		index = 14;
+		break;
+	case PCI_DEVICE_ID_NVIDIA_CK804_SATA0:
+		devfn -= (6 << 3);
+		index = 22;
+		break;
+	case PCI_DEVICE_ID_NVIDIA_CK804_SATA1:
+		devfn -= (7 << 3);
+		index = 18;
+		break;
+	case PCI_DEVICE_ID_NVIDIA_CK804_PCI:
+		devfn -= (8 << 3);
+		index = 15;
+		break;
+	case PCI_DEVICE_ID_NVIDIA_CK804_PCI_E:
+		devfn -= (0xa << 3);
+		index2 = 19;
+		break;
+	default:
+		index = 0;
+	}
+
+	if (index2 != 0) {
+		int i;
+		for (i = 0; i < 4; i++) {
+			lpc_dev = find_lpc_dev(dev, devfn - (i << 3));
+			if (!lpc_dev)
+				continue;
+			index2 -= i;
+			break;
+		}
+
+		if (lpc_dev) {
+			reg_old = reg = pci_read_config32(lpc_dev, 0xe4);
+			if (!dev->enabled)
+				reg |= (1 << index2);
+			if (reg != reg_old)
+				pci_write_config32(lpc_dev, 0xe4, reg);
+		}
+
+		index2 = 0;
+		return;
+	}
+
+	lpc_dev = find_lpc_dev(dev, devfn);
+	if (!lpc_dev)
+		return;
+
+	if (index == 0) {
+		final_reg = pci_read_config32(lpc_dev, 0xe8);
+		final_reg &= ~((1 << 16) | (1 << 8) | (1 << 20) | (1 << 10)
+			| (1 << 12) | (1 << 13) | (1 << 14) | (1 << 22)
+			| (1 << 18) | (1 << 15));
+		pci_write_config32(lpc_dev, 0xe8, final_reg);
+
+		reg_old = reg = pci_read_config32(lpc_dev, 0xe4);
+		reg |= (1 << 20);
+		if (reg != reg_old)
+			pci_write_config32(lpc_dev, 0xe4, reg);
+
+		byte = pci_read_config8(lpc_dev, 0x74);
+		byte |= ((1 << 1));
+		pci_write_config8(dev, 0x74, byte);
+
+		byte = pci_read_config8(lpc_dev, 0xdd);
+		byte |= ((1 << 0) | (1 << 3));
+		pci_write_config8(dev, 0xdd, byte);
+
+		return;
+	}
+
+	if (!dev->enabled)
+		final_reg |= (1 << index);
+
+	if (index == 10) {
+		reg_old = pci_read_config32(lpc_dev, 0xe8);
+		if (final_reg != reg_old)
+			pci_write_config32(lpc_dev, 0xe8, final_reg);
+	}
+}
+
+struct pci_operations ck804_ops_pci = {
+	.set_subsystem = ck804_set_subsystem,
+};

Added: coreboot-v3/southbridge/nvidia/ck804/ck804.h
===================================================================
--- coreboot-v3/southbridge/nvidia/ck804/ck804.h	                        (rev 0)
+++ coreboot-v3/southbridge/nvidia/ck804/ck804.h	2009-01-05 23:08:37 UTC (rev 1100)
@@ -0,0 +1,11 @@
+#ifndef CK804_H
+#define CK804_H
+
+#include <device/device.h>
+#include <device/pci.h>
+
+void ck804_enable(struct device *dev);
+
+extern struct pci_operations ck804_ops_pci;
+
+#endif

Added: coreboot-v3/southbridge/nvidia/ck804/ck804_ac97.c
===================================================================
--- coreboot-v3/southbridge/nvidia/ck804/ck804_ac97.c	                        (rev 0)
+++ coreboot-v3/southbridge/nvidia/ck804/ck804_ac97.c	2009-01-05 23:08:37 UTC (rev 1100)
@@ -0,0 +1,57 @@
+/*
+ * This file is part of the coreboot project.
+ *
+ * Copyright 2004 Tyan Computer
+ *  by yhlu at tyan.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 <types.h>
+#include <console.h>
+#include <device/device.h>
+#include <device/pci.h>
+#include <device/pci_ids.h>
+#include <device/pci_ops.h>
+#include "ck804.h"
+
+struct device_operations ac97audio = {
+	.id = {.type = DEVICE_ID_PCI,
+		{.pci = {.vendor = PCI_VENDOR_ID_NVIDIA,
+			 .device = PCI_DEVICE_ID_NVIDIA_CK804_ACI}}},
+	.constructor		 = default_device_constructor,
+	.phase3_chip_setup_dev	 = ck804_enable,
+	.phase3_scan		 = NULL,
+	.phase4_read_resources	 = pci_dev_read_resources,
+	.phase4_set_resources	 = pci_set_resources,
+	.phase5_enable_resources = pci_dev_enable_resources,
+	.phase6_init		 = NULL,
+	.ops_pci		 = &ck804_ops_pci,
+};
+
+struct device_operations ac97modem = {
+	.id = {.type = DEVICE_ID_PCI,
+		{.pci = {.vendor = PCI_VENDOR_ID_NVIDIA,
+			 .device = PCI_DEVICE_ID_NVIDIA_CK804_MCI}}},
+	.constructor		 = default_device_constructor,
+	.phase3_chip_setup_dev	 = ck804_enable,
+	.phase3_scan		 = NULL,
+	.phase4_read_resources	 = pci_dev_read_resources,
+	.phase4_set_resources	 = pci_set_resources,
+	.phase5_enable_resources = pci_dev_enable_resources,
+	.phase6_init		 = NULL,
+	.ops_pci		 = &ck804_ops_pci,
+};
+

Added: coreboot-v3/southbridge/nvidia/ck804/ck804_ht.c
===================================================================
--- coreboot-v3/southbridge/nvidia/ck804/ck804_ht.c	                        (rev 0)
+++ coreboot-v3/southbridge/nvidia/ck804/ck804_ht.c	2009-01-05 23:08:37 UTC (rev 1100)
@@ -0,0 +1,42 @@
+/*
+ * This file is part of the coreboot project.
+ *
+ * Copyright 2004 Tyan Computer
+ *  by yhlu at tyan.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 <types.h>
+#include <console.h>
+#include <device/device.h>
+#include <device/pci.h>
+#include <device/pci_ids.h>
+#include <device/pci_ops.h>
+#include "ck804.h"
+
+struct device_operations ck804_ht_ops = {
+	.id = {.type = DEVICE_ID_PCI,
+		{.pci = {.vendor = PCI_VENDOR_ID_NVIDIA,
+			 .device = PCI_DEVICE_ID_NVIDIA_CK804_HT}}},
+	.phase3_chip_setup_dev	 = ck804_enable,
+	.phase3_scan		 = NULL,
+	.phase4_read_resources	 = pci_dev_read_resources,
+	.phase4_set_resources	 = pci_set_resources,
+	.phase5_enable_resources = pci_dev_enable_resources,
+	.phase6_init		 = NULL,
+	.ops_pci		 = &ck804_ops_pci,
+};
+

Added: coreboot-v3/southbridge/nvidia/ck804/ck804_nic.c
===================================================================
--- coreboot-v3/southbridge/nvidia/ck804/ck804_nic.c	                        (rev 0)
+++ coreboot-v3/southbridge/nvidia/ck804/ck804_nic.c	2009-01-05 23:08:37 UTC (rev 1100)
@@ -0,0 +1,143 @@
+/*
+ * This file is part of the coreboot project.
+ *
+ * Copyright 2004 Tyan Computer
+ *  by yhlu at tyan.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 <types.h>
+#include <console.h>
+#include <device/device.h>
+#include <device/smbus.h>
+#include <device/pci.h>
+#include <device/pci_ids.h>
+#include <device/pci_ops.h>
+#include <io.h>
+#include "ck804.h"
+
+static void nic_init(struct device *dev)
+{
+	u32 dword, old, mac_h, mac_l;
+	int eeprom_valid = 0;
+	struct southbridge_nvidia_ck804_config *conf;
+	static u32 nic_index = 0;
+	u8 *base;
+	struct resource *res;
+
+	res = find_resource(dev, 0x10);
+	base = res->base;
+
+#define NvRegPhyInterface  0xC0
+#define PHY_RGMII          0x10000000
+
+	writel(PHY_RGMII, base + NvRegPhyInterface);
+
+	old = dword = pci_read_config32(dev, 0x30);
+	dword &= ~(0xf);
+	dword |= 0xf;
+	if (old != dword)
+		pci_write_config32(dev, 0x30, dword);
+
+	conf = dev->chip_info;
+
+	if (conf->mac_eeprom_smbus != 0) {
+		/* Read MAC address from EEPROM at first. */
+		struct device *dev_eeprom;
+		dev_eeprom = dev_find_slot_on_smbus(conf->mac_eeprom_smbus,
+					   conf->mac_eeprom_addr);
+
+		if (dev_eeprom) {
+			/* If that is valid we will use that. */
+			unsigned char dat[6];
+			int i, status;
+			for (i = 0; i < 6; i++) {
+				status = smbus_read_byte(dev_eeprom, i);
+				if (status < 0)
+					break;
+				dat[i] = status & 0xff;
+			}
+			if (status >= 0) {
+				mac_l = 0;
+				for (i = 3; i >= 0; i--) {
+					mac_l <<= 8;
+					mac_l += dat[i];
+				}
+				if (mac_l != 0xffffffff) {
+					mac_l += nic_index;
+					mac_h = 0;
+					for (i = 5; i >= 4; i--) {
+						mac_h <<= 8;
+						mac_h += dat[i];
+					}
+					eeprom_valid = 1;
+				}
+			}
+		}
+	}
+
+	/* If that is invalid we will read that from romstrap. */
+	if (!eeprom_valid) {
+		unsigned long mac_pos;
+		mac_pos = 0xffffffd0; /* See romstrap.inc and romstrap.lds. */
+		mac_l = readl(mac_pos) + nic_index;
+		mac_h = readl(mac_pos + 4);
+	}
+#if 1
+	/* Set that into NIC MMIO. */
+#define NvRegMacAddrA  0xA8
+#define NvRegMacAddrB  0xAC
+	writel(mac_l, base + NvRegMacAddrA);
+	writel(mac_h, base + NvRegMacAddrB);
+#else
+	/* Set that into NIC. */
+	pci_write_config32(dev, 0xa8, mac_l);
+	pci_write_config32(dev, 0xac, mac_h);
+#endif
+
+	nic_index++;
+
+#if CONFIG_PCI_ROM_RUN == 1
+	pci_dev_init(dev);	/* It will init Option ROM. */
+#endif
+}
+
+struct device_operations ck804_nic_ops = {
+	.id = {.type = DEVICE_ID_PCI,
+		{.pci = {.vendor = PCI_VENDOR_ID_NVIDIA,
+			 .device = PCI_DEVICE_ID_NVIDIA_CK804_NIC}}},
+	.phase3_chip_setup_dev	 = ck804_enable,
+	.phase3_scan		 = NULL,
+	.phase4_read_resources	 = pci_dev_read_resources,
+	.phase4_set_resources	 = pci_set_resources,
+	.phase5_enable_resources = pci_dev_enable_resources,
+	.phase6_init		 = nic_init,
+	.ops_pci		 = &ck804_ops_pci,
+};
+
+struct device_operations ck804_nic_bridge_ops = {
+	.id = {.type = DEVICE_ID_PCI,
+		{.pci = {.vendor = PCI_VENDOR_ID_NVIDIA,
+			 .device = PCI_DEVICE_ID_NVIDIA_CK804_NIC_BRIDGE}}},
+	.phase3_chip_setup_dev	 = ck804_enable,
+	.phase3_scan		 = NULL,
+	.phase4_read_resources	 = pci_dev_read_resources,
+	.phase4_set_resources	 = pci_set_resources,
+	.phase5_enable_resources = pci_dev_enable_resources,
+	.phase6_init		 = nic_init,
+	.ops_pci		 = &ck804_ops_pci,
+};
+

Added: coreboot-v3/southbridge/nvidia/ck804/ck804_reset.c
===================================================================
--- coreboot-v3/southbridge/nvidia/ck804/ck804_reset.c	                        (rev 0)
+++ coreboot-v3/southbridge/nvidia/ck804/ck804_reset.c	2009-01-05 23:08:37 UTC (rev 1100)
@@ -0,0 +1,39 @@
+/*
+ * Copyright 2004 Tyan Computer
+ *  by yhlu at tyan.com
+ */
+
+#include <io.h>
+
+#define PCI_DEV(BUS, DEV, FN) ( \
+	(((BUS) & 0xFFF) << 20) | \
+	(((DEV) & 0x1F) << 15) | \
+	(((FN)  & 0x7) << 12))
+
+typedef unsigned device_t;
+
+static void pci_write_config32(device_t dev, unsigned where, unsigned value)
+{
+	unsigned addr;
+	addr = (dev >> 4) | where;
+	outl(0x80000000 | (addr & ~3), 0xCF8);
+	outl(value, 0xCFC);
+}
+
+static unsigned pci_read_config32(device_t dev, unsigned where)
+{
+	unsigned addr;
+	addr = (dev >> 4) | where;
+	outl(0x80000000 | (addr & ~3), 0xCF8);
+	return inl(0xCFC);
+}
+
+#include "../../../northbridge/amd/amdk8/reset_test.c"
+
+void hard_reset(void)
+{
+	set_bios_reset();
+	/* Try rebooting through port 0xcf9. */
+	outb((0 << 3) | (0 << 2) | (1 << 1), 0xcf9);
+	outb((0 << 3) | (1 << 2) | (1 << 1), 0xcf9);
+}

Added: coreboot-v3/southbridge/nvidia/ck804/ck804_smbus.h
===================================================================
--- coreboot-v3/southbridge/nvidia/ck804/ck804_smbus.h	                        (rev 0)
+++ coreboot-v3/southbridge/nvidia/ck804/ck804_smbus.h	2009-01-05 23:08:37 UTC (rev 1100)
@@ -0,0 +1,32 @@
+/*
+ * Copyright 2004 Tyan Computer
+ *  by yhlu at tyan.com
+ */
+
+#ifndef CK804_SMBUS_H
+#define CK804_SMBUS_H
+
+#include <device/smbus_def.h>
+#include <io.h>
+
+#define SMBHSTSTAT  0x1
+#define SMBHSTPRTCL 0x0
+#define SMBHSTCMD   0x3
+#define SMBXMITADD  0x2
+#define SMBHSTDAT0  0x4
+#define SMBHSTDAT1  0x5
+
+/*
+ * Between 1-10 seconds, We should never timeout normally.
+ * Longer than this is just painful when a timeout condition occurs.
+ */
+#define SMBUS_TIMEOUT (100 * 1000 * 10)
+
+int do_smbus_write_byte(unsigned smbus_io_base, unsigned device,
+			unsigned address, unsigned char val);
+
+int do_smbus_read_byte(unsigned smbus_io_base, unsigned device,
+			      unsigned address);
+
+#endif
+

Added: coreboot-v3/southbridge/nvidia/ck804/ide.c
===================================================================
--- coreboot-v3/southbridge/nvidia/ck804/ide.c	                        (rev 0)
+++ coreboot-v3/southbridge/nvidia/ck804/ide.c	2009-01-05 23:08:37 UTC (rev 1100)
@@ -0,0 +1,85 @@
+/*
+ * This file is part of the coreboot project.
+ *
+ * Copyright 2004 Tyan Computer
+ *  by yhlu at tyan.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 <types.h>
+#include <console.h>
+#include <config.h>
+#include <device/device.h>
+#include <device/pci.h>
+#include <device/pci_ids.h>
+#include <device/pci_ops.h>
+#include <statictree.h>
+#include "ck804.h"
+
+static void ide_init(struct device *dev)
+{
+	struct southbridge_nvidia_ck804_ide_config *conf;
+	u32 dword;
+	u16 word;
+	u8 byte;
+
+	conf = dev->device_configuration;
+
+	word = pci_read_config16(dev, 0x50);
+	/* Ensure prefetch is disabled. */
+	word &= ~((1 << 15) | (1 << 13));
+	if (conf->ide1_enable) {
+		/* Enable secondary IDE interface. */
+		word |= (1 << 0);
+		printk(BIOS_DEBUG, "IDE1 \t");
+	}
+	if (conf->ide0_enable) {
+		/* Enable primary IDE interface. */
+		word |= (1 << 1);
+		printk(BIOS_DEBUG, "IDE0\n");
+	}
+
+	word |= (1 << 12);
+	word |= (1 << 14);
+
+	pci_write_config16(dev, 0x50, word);
+
+	byte = 0x20;		/* Latency: 64 --> 32 */
+	pci_write_config8(dev, 0xd, byte);
+
+	dword = pci_read_config32(dev, 0xf8);
+	dword |= 12;
+	pci_write_config32(dev, 0xf8, dword);
+
+#ifdef CONFIG_PCI_OPTION_ROM_RUN
+	pci_dev_init(dev);
+#endif
+}
+
+struct device_operations ck804_ide_ops = {
+	.id = {.type = DEVICE_ID_PCI,
+		{.pci = {.vendor = PCI_VENDOR_ID_NVIDIA,
+			 .device = PCI_DEVICE_ID_NVIDIA_CK804_IDE}}},
+	.constructor		 = default_device_constructor,
+	.phase3_chip_setup_dev	 = ck804_enable,
+	.phase3_scan		 = NULL,
+	.phase4_read_resources	 = pci_dev_read_resources,
+	.phase4_set_resources	 = pci_set_resources,
+	.phase5_enable_resources = pci_dev_enable_resources,
+	.phase6_init		 = ide_init,
+	//.ops_pci		 = &ck804_ops_pci,
+};
+

Added: coreboot-v3/southbridge/nvidia/ck804/ide.dts
===================================================================
--- coreboot-v3/southbridge/nvidia/ck804/ide.dts	                        (rev 0)
+++ coreboot-v3/southbridge/nvidia/ck804/ide.dts	2009-01-05 23:08:37 UTC (rev 1100)
@@ -0,0 +1,25 @@
+/*
+ * This file is part of the coreboot project.
+ *
+ * Copyright (C) 2008 Ronald G. Minnich <rminnich 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
+ */
+
+{
+	device_operations = "ck804_ide_ops";
+	ide0_enable = "1";
+	ide1_enable = "1";
+};

Added: coreboot-v3/southbridge/nvidia/ck804/lpc.c
===================================================================
--- coreboot-v3/southbridge/nvidia/ck804/lpc.c	                        (rev 0)
+++ coreboot-v3/southbridge/nvidia/ck804/lpc.c	2009-01-05 23:08:37 UTC (rev 1100)
@@ -0,0 +1,430 @@
+/*
+ * This file is part of the coreboot project.
+ *
+ * (C) 2003 Linux Networx, SuSE Linux AG
+ * Copyright 2004 Tyan Computer
+ *  by yhlu at tyan.com
+ *  2006.1 yhlu add dest apicid for IRQ0
+ *
+ * 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 <types.h>
+#include <console.h>
+#include <device/device.h>
+#include <device/pci.h>
+#include <device/pnp.h>
+#include <device/pci_ids.h>
+#include <device/pci_ops.h>
+#include <mc146818rtc.h>
+#include <isa-dma.h>
+#include <lib.h>
+#include <io.h>
+#include <lapic.h>
+#include "ck804.h"
+
+#define CK804_CHIP_REV 2
+
+#define NMI_OFF 0
+
+struct ioapicreg {
+	unsigned int reg;
+	unsigned int value_low, value_high;
+};
+
+static struct ioapicreg ioapicregvalues[] = {
+#define ALL		(0xff << 24)
+#define NONE		(0)
+#define DISABLED	(1 << 16)
+#define ENABLED		(0 << 16)
+#define TRIGGER_EDGE	(0 << 15)
+#define TRIGGER_LEVEL	(1 << 15)
+#define POLARITY_HIGH	(0 << 13)
+#define POLARITY_LOW	(1 << 13)
+#define PHYSICAL_DEST	(0 << 11)
+#define LOGICAL_DEST	(1 << 11)
+#define ExtINT		(7 << 8)
+#define NMI		(4 << 8)
+#define SMI		(2 << 8)
+#define INT		(1 << 8)
+	/* IO-APIC virtual wire mode configuration */
+	/* mask, trigger, polarity, destination, delivery, vector */
+	{0,  ENABLED | TRIGGER_EDGE | POLARITY_HIGH | PHYSICAL_DEST | ExtINT, NONE},
+	{1,  DISABLED, NONE},
+	{2,  DISABLED, NONE},
+	{3,  DISABLED, NONE},
+	{4,  DISABLED, NONE},
+	{5,  DISABLED, NONE},
+	{6,  DISABLED, NONE},
+	{7,  DISABLED, NONE},
+	{8,  DISABLED, NONE},
+	{9,  DISABLED, NONE},
+	{10, DISABLED, NONE},
+	{11, DISABLED, NONE},
+	{12, DISABLED, NONE},
+	{13, DISABLED, NONE},
+	{14, DISABLED, NONE},
+	{15, DISABLED, NONE},
+	{16, DISABLED, NONE},
+	{17, DISABLED, NONE},
+	{18, DISABLED, NONE},
+	{19, DISABLED, NONE},
+	{20, DISABLED, NONE},
+	{21, DISABLED, NONE},
+	{22, DISABLED, NONE},
+	{23, DISABLED, NONE},
+	/* Be careful and don't write past the end... */
+};
+
+static void setup_ioapic(unsigned long ioapic_base)
+{
+	int i;
+	unsigned long value_low, value_high;
+	/* unsigned long ioapic_base = 0xfec00000; */
+	volatile unsigned long *l;
+	struct ioapicreg *a = ioapicregvalues;
+
+	ioapicregvalues[0].value_high = lapicid() << (56 - 32);
+
+	l = (unsigned long *)ioapic_base;
+
+	for (i = 0; i < ARRAY_SIZE(ioapicregvalues); i++, a++) {
+		l[0] = (a->reg * 2) + 0x10;
+		l[4] = a->value_low;
+		value_low = l[4];
+		l[0] = (a->reg * 2) + 0x11;
+		l[4] = a->value_high;
+		value_high = l[4];
+		if ((i == 0) && (value_low == 0xffffffff)) {
+			printk(BIOS_INFO, "IO APIC not responding.\n");
+			return;
+		}
+		printk(BIOS_SPEW, "for IRQ, reg 0x%08x value 0x%08x 0x%08x\n",
+			    a->reg, a->value_low, a->value_high);
+	}
+}
+
+// 0x7a or e3
+#define PREVIOUS_POWER_STATE 0x7A
+
+#define MAINBOARD_POWER_OFF 0
+#define MAINBOARD_POWER_ON 1
+#define SLOW_CPU_OFF 0
+#define SLOW_CPU__ON 1
+
+#ifndef MAINBOARD_POWER_ON_AFTER_POWER_FAIL
+#define MAINBOARD_POWER_ON_AFTER_POWER_FAIL MAINBOARD_POWER_ON
+#endif
+
+static void lpc_common_init(struct device * dev)
+{
+	u8 byte;
+	u32 dword;
+
+	/* I/O APIC initialization */
+	byte = pci_read_config8(dev, 0x74);
+	byte |= (1 << 0);	/* Enable APIC. */
+	pci_write_config8(dev, 0x74, byte);
+	dword = pci_read_config32(dev, PCI_BASE_ADDRESS_1);	/* 0x14 */
+
+	setup_ioapic(dword);
+
+#if 1
+	dword = pci_read_config32(dev, 0xe4);
+	dword |= (1 << 23);
+	pci_write_config32(dev, 0xe4, dword);
+#endif
+}
+
+static void lpc_slave_init(struct device * dev)
+{
+	lpc_common_init(dev);
+}
+
+static void rom_dummy_write(struct device * dev)
+{
+	u8 old, new;
+	u8 *p;
+
+	old = pci_read_config8(dev, 0x88);
+	new = old | 0xc0;
+	if (new != old)
+		pci_write_config8(dev, 0x88, new);
+	/* Enable write. */
+	old = pci_read_config8(dev, 0x6d);
+	new = old | 0x01;
+	if (new != old)
+		pci_write_config8(dev, 0x6d, new);
+
+	/* Dummy write. */
+	p = (u8 *) 0xffffffe0;
+	old = 0;
+	*p = old;
+	old = *p;
+
+	/* Disable write. */
+	old = pci_read_config8(dev, 0x6d);
+	new = old & 0xfe;
+	if (new != old)
+		pci_write_config8(dev, 0x6d, new);
+}
+
+#if 0
+static void enable_hpet(struct device *dev)
+{
+	unsigned long hpet_address;
+
+	pci_write_config32(dev, 0x44, 0xfed00001);
+	hpet_address = pci_read_config32(dev, 0x44) & 0xfffffffe;
+	printk(BIOS_DEBUG, "Enabling HPET @0x%x\n", hpet_address);
+}
+#endif
+
+static void lpc_init(struct device * dev)
+{
+	u8 byte, byte_old;
+	int on, nmi_option;
+
+	lpc_common_init(dev);
+
+#if CK804_CHIP_REV==1
+	if (dev->bus->secondary != 1)
+		return;
+#endif
+
+#if 0
+	/* Posted memory write enable */
+	byte = pci_read_config8(dev, 0x46);
+	pci_write_config8(dev, 0x46, byte | (1 << 0));
+#endif
+
+	/* power after power fail */
+	on = MAINBOARD_POWER_ON_AFTER_POWER_FAIL;
+	get_option(&on, "power_on_after_fail");
+	byte = pci_read_config8(dev, PREVIOUS_POWER_STATE);
+	byte &= ~0x40;
+	if (!on)
+		byte |= 0x40;
+	pci_write_config8(dev, PREVIOUS_POWER_STATE, byte);
+	printk(BIOS_INFO, "set power %s after power fail\n", on ? "on" : "off");
+
+	/* Throttle the CPU speed down for testing. */
+	on = SLOW_CPU_OFF;
+	get_option(&on, "slow_cpu");
+	if (on) {
+		u16 pm10_bar;
+		u32 dword;
+		pm10_bar = (pci_read_config16(dev, 0x60) & 0xff00);
+		outl(((on << 1) + 0x10), (pm10_bar + 0x10));
+		dword = inl(pm10_bar + 0x10);
+		on = 8 - on;
+		printk(BIOS_DEBUG, "Throttling CPU %2d.%1.1d percent.\n",
+			     (on * 12) + (on >> 1), (on & 1) * 5);
+	}
+#if 0
+// default is enabled
+	/* Enable Port 92 fast reset. */
+	byte = pci_read_config8(dev, 0xe8);
+	byte |= ~(1 << 3);
+	pci_write_config8(dev, 0xe8, byte);
+#endif
+
+	/* Enable Error reporting. */
+	/* Set up sync flood detected. */
+	byte = pci_read_config8(dev, 0x47);
+	byte |= (1 << 1);
+	pci_write_config8(dev, 0x47, byte);
+
+	/* Set up NMI on errors. */
+	byte = inb(0x70);		/* RTC70 */
+	byte_old = byte;
+	nmi_option = NMI_OFF;
+	get_option(&nmi_option, "nmi");
+	if (nmi_option) {
+		byte &= ~(1 << 7); /* Set NMI. */
+	} else {
+		byte |= (1 << 7); /* Can't mask NMI from PCI-E and NMI_NOW. */
+	}
+	if (byte != byte_old)
+		outb(0x70, byte);
+
+	/* Initialize the real time clock (RTC). */
+	rtc_init(0);
+
+	/* Initialize ISA DMA. */
+	isa_dma_init();
+
+	/* Initialize the High Precision Event Timers (HPET). */
+	/* enable_hpet(dev); */
+
+	rom_dummy_write(dev);
+}
+
+static void ck804_lpc_read_resources(struct device * dev)
+{
+	struct resource *res;
+	unsigned long index;
+
+	/* Get the normal PCI resources of this device. */
+	/* We got one for APIC, or one more for TRAP. */
+	pci_dev_read_resources(dev);
+
+	/* Get resource for ACPI, SYSTEM_CONTROL, ANALOG_CONTROL. */
+	for (index = 0x60; index <= 0x68; index += 4)	/* We got another 3. */
+		pci_get_resource(dev, index);
+	compact_resources(dev);
+
+	/* Add an extra subtractive resource for both memory and I/O. */
+	res = new_resource(dev, IOINDEX_SUBTRACTIVE(0, 0));
+	res->flags =
+	    IORESOURCE_IO | IORESOURCE_SUBTRACTIVE | IORESOURCE_ASSIGNED;
+
+	res = new_resource(dev, IOINDEX_SUBTRACTIVE(1, 0));
+	res->flags =
+	    IORESOURCE_MEM | IORESOURCE_SUBTRACTIVE | IORESOURCE_ASSIGNED;
+}
+
+/**
+ * Enable resources for children devices.
+ *
+ * This function is called by the global enable_resources() indirectly via the
+ * device_operation::enable_resources() method of devices.
+ *
+ * Indirect mutual recursion:
+ *      enable_childrens_resources() -> enable_resources()
+ *      enable_resources() -> device_operation::enable_resources()
+ *      device_operation::enable_resources() -> enable_children_resources()
+ *
+ * @param dev The device whose children's resources are to be enabled.
+ */
+static void ck804_lpc_enable_childrens_resources(struct device * dev)
+{
+	unsigned link;
+	u32 reg, reg_var[4];
+	int i, var_num = 0;
+
+	reg = pci_read_config32(dev, 0xa0);
+
+	for (link = 0; link < dev->links; link++) {
+		struct device * child;
+		for (child = dev->link[link].children; child; child = child->sibling) {
+			if (child->path.type == DEVICE_PATH_PNP) {
+				for (i = 0; i < child->resources; i++) {
+					struct resource *res;
+					resource_t base, end;
+					res = &child->resource[i];
+					if (!(res->flags & IORESOURCE_IO))
+						continue;
+					base = res->base;
+					end = resource_end(res);
+					printk(BIOS_DEBUG, "ck804 lpc decode:%s, base=0x%08llx, end=0x%08llx\n", dev_path(child), base, end);
+					switch (base) {
+					case 0x3f8:	// COM1
+						reg |= (1 << 0);
+						break;
+					case 0x2f8:	// COM2
+						reg |= (1 << 1);
+						break;
+					case 0x378:	// Parallel 1
+						reg |= (1 << 24);
+						break;
+					case 0x3f0:	// FD0
+						reg |= (1 << 20);
+						break;
+					case 0x220:	// Audio 0
+						reg |= (1 << 8);
+						break;
+					case 0x300:	// Midi 0
+						reg |= (1 << 12);
+						break;
+					}
+					if (base == 0x290 || base >= 0x400) {
+						if (var_num >= 4)
+							continue;	// only 4 var ; compact them ?
+						reg |= (1 << (28 + var_num));
+						reg_var[var_num++] = (base & 0xffff) | ((end & 0xffff) << 16);
+					}
+				}
+			}
+		}
+	}
+	pci_write_config32(dev, 0xa0, reg);
+	for (i = 0; i < var_num; i++)
+		pci_write_config32(dev, 0xa8 + i * 4, reg_var[i]);
+}
+
+static void ck804_lpc_enable_resources(struct device * dev)
+{
+	pci_dev_enable_resources(dev);
+	ck804_lpc_enable_childrens_resources(dev);
+	enable_childrens_resources(dev);
+}
+
+void lpci_set_subsystem(struct device *dev, u16 vendor, u16 device)
+{
+	pci_write_config32(dev, 0x40,
+			   ((device & 0xffff) << 16) | (vendor & 0xffff));
+}
+
+static struct pci_operations lops_pci = {
+	.set_subsystem = lpci_set_subsystem,
+};
+
+struct device_operations ck804_lpc_pro_ops = {
+	.id = {.type = DEVICE_ID_PCI,
+		{.pci = {.vendor = PCI_VENDOR_ID_NVIDIA,
+			 .device = PCI_DEVICE_ID_NVIDIA_CK804_PRO}}},
+	.constructor		 = default_device_constructor,
+	.phase3_scan		 = scan_static_bus,
+	.phase4_read_resources	 = ck804_lpc_read_resources,
+	.phase4_set_resources	 = pci_set_resources,
+	.phase5_enable_resources = ck804_lpc_enable_resources,
+	.phase6_init		 = lpc_init,
+	// .enable		 = ck804_enable,
+	.ops_pci		 = &lops_pci,
+};
+
+struct device_operations ck804_lpc_ops = {
+	.id = {.type = DEVICE_ID_PCI,
+		{.pci = {.vendor = PCI_VENDOR_ID_NVIDIA,
+			 .device = PCI_DEVICE_ID_NVIDIA_CK804_LPC}}},
+	.constructor		 = default_device_constructor,
+	.phase3_scan		 = scan_static_bus,
+	.phase4_read_resources	 = ck804_lpc_read_resources,
+	.phase4_set_resources	 = pci_set_resources,
+	.phase5_enable_resources = ck804_lpc_enable_resources,
+	.phase6_init		 = lpc_init,
+	// .enable		 = ck804_enable,
+	.ops_pci		 = &lops_pci,
+};
+
+struct device_operations ck804_lpc_slave_ops = {
+	.id = {.type = DEVICE_ID_PCI,
+		{.pci = {.vendor = PCI_VENDOR_ID_NVIDIA,
+			 .device = PCI_DEVICE_ID_NVIDIA_CK804_SLAVE}}},
+	.constructor		 = default_device_constructor,
+	.phase3_scan		 = scan_static_bus,
+	.phase4_read_resources	 = ck804_lpc_read_resources,
+	.phase4_set_resources	 = pci_set_resources,
+#if CK804_CHIP_REV == 1
+	.phase5_enable_resources = ck804_lpc_enable_resources,
+	.phase6_init		 = lpc_init,
+#else
+	.phase5_enable_resources = pci_dev_enable_resources,
+	.phase6_init		 = lpc_slave_init,
+#endif
+	// .enable		 = ck804_enable,
+	.ops_pci		 = &lops_pci,
+};

Added: coreboot-v3/southbridge/nvidia/ck804/lpc.dts
===================================================================
--- coreboot-v3/southbridge/nvidia/ck804/lpc.dts	                        (rev 0)
+++ coreboot-v3/southbridge/nvidia/ck804/lpc.dts	2009-01-05 23:08:37 UTC (rev 1100)
@@ -0,0 +1,24 @@
+/*
+ * This file is part of the coreboot project.
+ *
+ * Copyright (C) 2008 Ronald G. Minnich <rminnich 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
+ */
+
+{
+	device_operations = "ck804_lpc_ops";
+	bridge;
+};

Added: coreboot-v3/southbridge/nvidia/ck804/pci.c
===================================================================
--- coreboot-v3/southbridge/nvidia/ck804/pci.c	                        (rev 0)
+++ coreboot-v3/southbridge/nvidia/ck804/pci.c	2009-01-05 23:08:37 UTC (rev 1100)
@@ -0,0 +1,93 @@
+/*
+ * This file is part of the coreboot project.
+ *
+ * Copyright 2004 Tyan Computer
+ *  by yhlu at tyan.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 <types.h>
+#include <console.h>
+#include <device/device.h>
+#include <device/pci.h>
+#include <device/pci_ids.h>
+#include <device/pci_ops.h>
+#include "ck804.h"
+
+static void pci_init(struct device *dev)
+{
+	u32 dword;
+
+	dword = pci_read_config32(dev, 0x04);
+	dword |= (1 << 8);	/* System error enable */
+	dword |= (1 << 30);	/* Clear possible errors */
+	pci_write_config32(dev, 0x04, dword);
+
+#if 0
+	word = pci_read_config16(dev, 0x48);
+	word |= (1 << 0);	/* MRL2MRM */
+	word |= (1 << 2);	/* MR2MRM */
+	pci_write_config16(dev, 0x48, word);
+#endif
+
+#if 1
+	dword = pci_read_config32(dev, 0x4c);
+	dword |= 0x00440000;	/* TABORT_SER_ENABLE Park Last Enable. */
+	pci_write_config32(dev, 0x4c, dword);
+#endif
+
+#warning 64-bit disabled here
+#if 0
+	struct device * pci_domain_dev;
+	struct resource *mem1, *mem2;
+	pci_domain_dev = dev->bus->dev;
+
+	if (!pci_domain_dev)
+		return;		/* Impossible */
+
+	mem1 = find_resource(pci_domain_dev, 1);	// prefmem, it could be 64bit
+	mem2 = find_resource(pci_domain_dev, 2);	// mem
+	if (mem1->base > mem2->base) {
+		dword = mem2->base & (0xffff0000UL);
+		printk(BIOS_DEBUG, "PCI DOMAIN mem2 base = 0x%010Lx\n", mem2->base);
+	} else {
+		dword = mem1->base & (0xffff0000UL);
+		printk(BIOS_DEBUG, "PCI DOMAIN mem1 (prefmem) base = 0x%010Lx\n",
+			     mem1->base);
+	}
+#else
+	dword = dev_root.resource[1].base & (0xffff0000UL);
+	printk(BIOS_DEBUG, "dev_root mem base = 0x%010Lx\n",
+		     dev_root.resource[1].base);
+#endif
+
+	printk(BIOS_DEBUG, "[0x50] <-- 0x%08x\n", dword);
+	pci_write_config32(dev, 0x50, dword);	/* TOM */
+}
+
+struct device_operations ck804_pci_ops = {
+	.id = {.type = DEVICE_ID_PCI,
+		{.pci = {.vendor = PCI_VENDOR_ID_NVIDIA,
+			 .device = PCI_DEVICE_ID_NVIDIA_CK804_PCI}}},
+	.phase3_chip_setup_dev	 = ck804_enable,
+	.phase3_scan		 = pci_scan_bridge,
+	.phase4_read_resources	 = pci_dev_read_resources,
+	.phase4_set_resources	 = pci_set_resources,
+	.phase5_enable_resources = pci_dev_enable_resources,
+	.phase6_init		 = pci_init,
+	.ops_pci		 = NULL,
+};
+

Added: coreboot-v3/southbridge/nvidia/ck804/pci.dts
===================================================================
--- coreboot-v3/southbridge/nvidia/ck804/pci.dts	                        (rev 0)
+++ coreboot-v3/southbridge/nvidia/ck804/pci.dts	2009-01-05 23:08:37 UTC (rev 1100)
@@ -0,0 +1,24 @@
+/*
+ * This file is part of the coreboot project.
+ *
+ * Copyright (C) 2008 Ronald G. Minnich <rminnich 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
+ */
+
+{
+	device_operations = "ck804_pci_ops";
+	bridge;
+};

Added: coreboot-v3/southbridge/nvidia/ck804/pcie.c
===================================================================
--- coreboot-v3/southbridge/nvidia/ck804/pcie.c	                        (rev 0)
+++ coreboot-v3/southbridge/nvidia/ck804/pcie.c	2009-01-05 23:08:37 UTC (rev 1100)
@@ -0,0 +1,54 @@
+/*
+ * This file is part of the coreboot project.
+ *
+ * Copyright 2004 Tyan Computer
+ *  by yhlu at tyan.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 <types.h>
+#include <console.h>
+#include <device/device.h>
+#include <device/pci.h>
+#include <device/pci_ids.h>
+#include <device/pci_ops.h>
+#include "ck804.h"
+
+static void pcie_init(struct device *dev)
+{
+	u32 dword;
+
+	/* Enable PCI error detecting. */
+	dword = pci_read_config32(dev, 0x04);
+	dword |= (1 << 8);	/* System error enable */
+	dword |= (1 << 30);	/* Clear possible errors */
+	pci_write_config32(dev, 0x04, dword);
+}
+
+
+struct device_operations ck804_pcie_ops = {
+	.id = {.type = DEVICE_ID_PCI,
+		{.pci = {.vendor = PCI_VENDOR_ID_NVIDIA,
+			 .device = PCI_DEVICE_ID_NVIDIA_CK804_PCI_E}}},
+	.phase3_chip_setup_dev	 = ck804_enable,
+	.phase3_scan		 = pci_scan_bridge,
+	.phase4_read_resources	 = pci_bus_read_resources,
+	.phase4_set_resources	 = pci_set_resources,
+	.phase5_enable_resources = pci_bus_enable_resources,
+	.phase6_init		 = pcie_init,
+	.ops_pci		 = NULL,
+};
+

Added: coreboot-v3/southbridge/nvidia/ck804/pcie.dts
===================================================================
--- coreboot-v3/southbridge/nvidia/ck804/pcie.dts	                        (rev 0)
+++ coreboot-v3/southbridge/nvidia/ck804/pcie.dts	2009-01-05 23:08:37 UTC (rev 1100)
@@ -0,0 +1,24 @@
+/*
+ * This file is part of the coreboot project.
+ *
+ * Copyright (C) 2008 Ronald G. Minnich <rminnich 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
+ */
+
+{
+	device_operations = "ck804_pcie_ops";
+	bridge;
+};

Added: coreboot-v3/southbridge/nvidia/ck804/sata.c
===================================================================
--- coreboot-v3/southbridge/nvidia/ck804/sata.c	                        (rev 0)
+++ coreboot-v3/southbridge/nvidia/ck804/sata.c	2009-01-05 23:08:37 UTC (rev 1100)
@@ -0,0 +1,189 @@
+/*
+ * This file is part of the coreboot project.
+ *
+ * Copyright 2004 Tyan Computer
+ *  by yhlu at tyan.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 <types.h>
+#include <console.h>
+#include <device/device.h>
+#include <lib.h>
+#include <device/pci.h>
+#include <device/pci_ids.h>
+#include <device/pci_ops.h>
+#include <statictree.h>
+#include "ck804.h"
+
+static void sata_com_reset(struct device *dev, unsigned reset)
+// reset = 1 : reset
+// reset = 0 : clear
+{
+	u32 *base;
+	u32 dword;
+	int loop;
+
+	base = (u32 *) pci_read_config32(dev, 0x24);
+
+	printk(BIOS_DEBUG, "base = %p\n", base);
+
+	if (reset) {
+		*(base + 4) = 0xffffffff;
+		*(base + 0x44) = 0xffffffff;
+	}
+
+	dword = *(base + 8);
+	dword &= ~(0xf);
+	dword |= reset;
+
+	*(base + 8) = dword;
+	*(base + 0x48) = dword;
+
+#if 0
+	udelay(1000);
+	dword &= ~(0xf);
+	*(base + 8) = dword;
+	*(base + 0x48) = dword;
+#endif
+
+	if (reset)
+		return;
+
+	dword = *(base + 0);
+	printk(BIOS_DEBUG, "*(base+0)=%08x\n", dword);
+	if (dword == 0x113) {
+		loop = 200000;	// 2
+		do {
+			dword = *(base + 4);
+			if ((dword & 0x10000) != 0)
+				break;
+			udelay(10);
+		} while (--loop > 0);
+		printk(BIOS_DEBUG, "loop=%d, *(base+4)=%08x\n", loop, dword);
+	}
+
+	dword = *(base + 0x40);
+	printk(BIOS_DEBUG, "*(base+0x40)=%08x\n", dword);
+	if (dword == 0x113) {
+		loop = 200000;	//2
+		do {
+			dword = *(base + 0x44);
+			if ((dword & 0x10000) != 0)
+				break;
+			udelay(10);
+		} while (--loop > 0);
+		printk(BIOS_DEBUG, "loop=%d, *(base+0x44)=%08x\n", loop, dword);
+	}
+}
+
+static void sata_init(struct device *dev)
+{
+	u32 dword;
+	struct southbridge_nvidia_ck804_sata_config *conf;
+
+	conf = dev->device_configuration;
+
+	dword = pci_read_config32(dev, 0x50);
+	/* Ensure prefetch is disabled. */
+	dword &= ~((1 << 15) | (1 << 13));
+	if (conf->sata1_enable) {
+		/* Enable secondary SATA interface. */
+		dword |= (1 << 0);
+		printk(BIOS_DEBUG, "SATA S \t");
+	}
+	if (conf->sata0_enable) {
+		/* Enable primary SATA interface. */
+		dword |= (1 << 1);
+		printk(BIOS_DEBUG, "SATA P \n");
+	}
+#if 0
+	/* Write back */
+	dword |= (1 << 12);
+	dword |= (1 << 14);
+#endif
+
+#if 0
+	/* ADMA */
+	dword |= (1 << 16);
+	dword |= (1 << 17);
+#endif
+
+#if 1
+	/* DO NOT relay OK and PAGE_FRNDLY_DTXFR_CNT. */
+	dword &= ~(0x1f << 24);
+	dword |= (0x15 << 24);
+#endif
+	pci_write_config32(dev, 0x50, dword);
+
+#if 0
+	/* SLUMBER_DURING_D3 */
+	dword = pci_read_config32(dev, 0x7c);
+	dword &= ~(1 << 4);
+	pci_write_config32(dev, 0x7c, dword);
+
+	dword = pci_read_config32(dev, 0xd0);
+	dword &= ~(0xff << 24);
+	dword |= (0x68 << 24);
+	pci_write_config32(dev, 0xd0, dword);
+
+	dword = pci_read_config32(dev, 0xe0);
+	dword &= ~(0xff << 24);
+	dword |= (0x68 << 24);
+	pci_write_config32(dev, 0xe0, dword);
+#endif
+
+	dword = pci_read_config32(dev, 0xf8);
+	dword |= 2;
+	pci_write_config32(dev, 0xf8, dword);
+
+#if 0
+	dword = pci_read_config32(dev, 0xac);
+	dword &= ~((1 << 13) | (1 << 14));
+	dword |= (1 << 13) | (0 << 14);
+	pci_write_config32(dev, 0xac, dword);
+
+	sata_com_reset(dev, 1);	/* For discover some s-atapi device. */
+#endif
+
+}
+
+struct device_operations ck804_sata0_ops = {
+	.id = {.type = DEVICE_ID_PCI,
+		{.pci = {.vendor = PCI_VENDOR_ID_NVIDIA,
+			 .device = PCI_DEVICE_ID_NVIDIA_CK804_SATA0}}},
+	.phase3_chip_setup_dev	 = ck804_enable,
+	.phase3_scan		 = NULL,
+	.phase4_read_resources	 = pci_dev_read_resources,
+	.phase4_set_resources	 = pci_set_resources,
+	.phase5_enable_resources = pci_dev_enable_resources,
+	.phase6_init		 = sata_init,
+	.ops_pci		 = &ck804_ops_pci,
+};
+
+struct device_operations ck804_sata1_ops = {
+	.id = {.type = DEVICE_ID_PCI,
+		{.pci = {.vendor = PCI_VENDOR_ID_NVIDIA,
+			 .device = PCI_DEVICE_ID_NVIDIA_CK804_SATA1}}},
+	.phase3_chip_setup_dev	 = ck804_enable,
+	.phase3_scan		 = NULL,
+	.phase4_read_resources	 = pci_dev_read_resources,
+	.phase4_set_resources	 = pci_set_resources,
+	.phase5_enable_resources = pci_dev_enable_resources,
+	.phase6_init		 = sata_init,
+	.ops_pci		 = &ck804_ops_pci,
+};
+

Added: coreboot-v3/southbridge/nvidia/ck804/sata.dts
===================================================================
--- coreboot-v3/southbridge/nvidia/ck804/sata.dts	                        (rev 0)
+++ coreboot-v3/southbridge/nvidia/ck804/sata.dts	2009-01-05 23:08:37 UTC (rev 1100)
@@ -0,0 +1,25 @@
+/*
+ * This file is part of the coreboot project.
+ *
+ * Copyright (C) 2008 Ronald G. Minnich <rminnich 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
+ */
+
+{
+	device_operations = "ck804_sata0_ops";
+	sata0_enable = "1";
+	sata1_enable = "1";
+};

Added: coreboot-v3/southbridge/nvidia/ck804/sata1.dts
===================================================================
--- coreboot-v3/southbridge/nvidia/ck804/sata1.dts	                        (rev 0)
+++ coreboot-v3/southbridge/nvidia/ck804/sata1.dts	2009-01-05 23:08:37 UTC (rev 1100)
@@ -0,0 +1,25 @@
+/*
+ * This file is part of the coreboot project.
+ *
+ * Copyright (C) 2008 Ronald G. Minnich <rminnich 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
+ */
+
+{
+	device_operations = "ck804_sata1_ops";
+	sata0_enable = "1";
+	sata1_enable = "1";
+};

Added: coreboot-v3/southbridge/nvidia/ck804/shared_smbus.c
===================================================================
--- coreboot-v3/southbridge/nvidia/ck804/shared_smbus.c	                        (rev 0)
+++ coreboot-v3/southbridge/nvidia/ck804/shared_smbus.c	2009-01-05 23:08:37 UTC (rev 1100)
@@ -0,0 +1,197 @@
+/*
+ * This file is part of the coreboot project.
+ *
+ * Copyright 2004 Tyan Computer
+ *  by yhlu at tyan.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 <types.h>
+#include <device/smbus.h>
+#include <device/smbus_def.h>
+#include <device/pci_ids.h>
+#include <device/pci_ops.h>
+#include <device/pci.h>
+#include <device/device.h>
+#include <console.h>
+#include <io.h>
+#include "ck804_smbus.h"
+
+static inline void smbus_delay(void)
+{
+	outb(0x80, 0x80);
+}
+
+int smbus_wait_until_ready(unsigned smbus_io_base)
+{
+	unsigned long loops;
+	loops = SMBUS_TIMEOUT;
+	do {
+		unsigned char val;
+		smbus_delay();
+		val = inb(smbus_io_base + SMBHSTSTAT);
+		val &= 0x1f;
+		if (val == 0)
+			return 0;
+		outb(val, smbus_io_base + SMBHSTSTAT);
+	} while (--loops);
+	return -2;
+}
+
+int smbus_wait_until_done(unsigned smbus_io_base)
+{
+	unsigned long loops;
+	loops = SMBUS_TIMEOUT;
+	do {
+		unsigned char val;
+		smbus_delay();
+		val = inb(smbus_io_base + SMBHSTSTAT);
+		if ((val & 0xff) != 0)
+			return 0;
+	} while (--loops);
+	return -3;
+}
+
+int do_smbus_recv_byte(unsigned smbus_io_base, unsigned device)
+{
+	unsigned char global_status_register, byte;
+
+	/* Set the device I'm talking to. */
+	outb(((device & 0x7f) << 1) | 1, smbus_io_base + SMBXMITADD);
+	smbus_delay();
+
+	/* Set the command/address. */
+	outb(0, smbus_io_base + SMBHSTCMD);
+	smbus_delay();
+
+	/* Byte data recv */
+	outb(0x05, smbus_io_base + SMBHSTPRTCL);
+	smbus_delay();
+
+	/* Poll for transaction completion. */
+	if (smbus_wait_until_done(smbus_io_base) < 0)
+		return -3;
+
+	/* Lose check */
+	global_status_register = inb(smbus_io_base + SMBHSTSTAT) & 0x80;
+
+	/* Read results of transaction. */
+	byte = inb(smbus_io_base + SMBHSTDAT0);
+
+	/* Lose check, otherwise it should be 0. */
+	if (global_status_register != 0x80)
+		return -1;
+
+	return byte;
+}
+
+int do_smbus_send_byte(unsigned smbus_io_base, unsigned device,
+			      unsigned char val)
+{
+	unsigned global_status_register;
+
+	outb(val, smbus_io_base + SMBHSTDAT0);
+	smbus_delay();
+
+	/* Set the device I'm talking to. */
+	outb(((device & 0x7f) << 1) | 0, smbus_io_base + SMBXMITADD);
+	smbus_delay();
+
+	outb(0, smbus_io_base + SMBHSTCMD);
+	smbus_delay();
+
+	/* Set up for a byte data write. */
+	outb(0x04, smbus_io_base + SMBHSTPRTCL);
+	smbus_delay();
+
+	/* Poll for transaction completion. */
+	if (smbus_wait_until_done(smbus_io_base) < 0)
+		return -3;
+
+	/* Lose check */
+	global_status_register = inb(smbus_io_base + SMBHSTSTAT) & 0x80;
+
+	if (global_status_register != 0x80)
+		return -1;
+
+	return 0;
+}
+
+int do_smbus_read_byte(unsigned smbus_io_base, unsigned device,
+			      unsigned address)
+{
+	unsigned char global_status_register, byte;
+
+	/* Set the device I'm talking to. */
+	outb(((device & 0x7f) << 1) | 1, smbus_io_base + SMBXMITADD);
+	smbus_delay();
+
+	/* Set the command/address. */
+	outb(address & 0xff, smbus_io_base + SMBHSTCMD);
+	smbus_delay();
+
+	/* Byte data read */
+	outb(0x07, smbus_io_base + SMBHSTPRTCL);
+	smbus_delay();
+
+	/* Poll for transaction completion. */
+	if (smbus_wait_until_done(smbus_io_base) < 0)
+		return -3;
+
+	/* Lose check */
+	global_status_register = inb(smbus_io_base + SMBHSTSTAT) & 0x80;
+
+	/* Read results of transaction. */
+	byte = inb(smbus_io_base + SMBHSTDAT0);
+
+	/* Lose check, otherwise it should be 0. */
+	if (global_status_register != 0x80)
+		return -1;
+
+	return byte;
+}
+
+int do_smbus_write_byte(unsigned smbus_io_base, unsigned device,
+			       unsigned address, unsigned char val)
+{
+	unsigned global_status_register;
+
+	outb(val, smbus_io_base + SMBHSTDAT0);
+	smbus_delay();
+
+	/* Set the device I'm talking to. */
+	outb(((device & 0x7f) << 1) | 0, smbus_io_base + SMBXMITADD);
+	smbus_delay();
+
+	outb(address & 0xff, smbus_io_base + SMBHSTCMD);
+	smbus_delay();
+
+	/* Set up for a byte data write. */
+	outb(0x06, smbus_io_base + SMBHSTPRTCL);
+	smbus_delay();
+
+	/* Poll for transaction completion. */
+	if (smbus_wait_until_done(smbus_io_base) < 0)
+		return -3;
+
+	/* Lose check */
+	global_status_register = inb(smbus_io_base + SMBHSTSTAT) & 0x80;
+
+	if (global_status_register != 0x80)
+		return -1;
+
+	return 0;
+}

Added: coreboot-v3/southbridge/nvidia/ck804/smbus.c
===================================================================
--- coreboot-v3/southbridge/nvidia/ck804/smbus.c	                        (rev 0)
+++ coreboot-v3/southbridge/nvidia/ck804/smbus.c	2009-01-05 23:08:37 UTC (rev 1100)
@@ -0,0 +1,299 @@
+/*
+ * This file is part of the coreboot project.
+ *
+ * Copyright 2004 Tyan Computer
+ *  by yhlu at tyan.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 <types.h>
+#include <device/smbus.h>
+#include <device/smbus_def.h>
+#include <device/pci_ids.h>
+#include <device/pci_ops.h>
+#include <device/pci.h>
+#include <device/device.h>
+#include <console.h>
+#include <io.h>
+#include "ck804.h"
+#include "ck804_smbus.h"
+
+static inline void smbus_delay(void)
+{
+	outb(0x80, 0x80);
+}
+
+int smbus_wait_until_ready(unsigned smbus_io_base)
+{
+	unsigned long loops;
+	loops = SMBUS_TIMEOUT;
+	do {
+		unsigned char val;
+		smbus_delay();
+		val = inb(smbus_io_base + SMBHSTSTAT);
+		val &= 0x1f;
+		if (val == 0)
+			return 0;
+		outb(val, smbus_io_base + SMBHSTSTAT);
+	} while (--loops);
+	return -2;
+}
+
+int smbus_wait_until_done(unsigned smbus_io_base)
+{
+	unsigned long loops;
+	loops = SMBUS_TIMEOUT;
+	do {
+		unsigned char val;
+		smbus_delay();
+		val = inb(smbus_io_base + SMBHSTSTAT);
+		if ((val & 0xff) != 0)
+			return 0;
+	} while (--loops);
+	return -3;
+}
+
+int do_smbus_recv_byte(unsigned smbus_io_base, unsigned device)
+{
+	unsigned char global_status_register, byte;
+
+#if 0
+	/* Not needed, upon write to PRTCL, the status will be auto-cleared. */
+	if (smbus_wait_until_ready(smbus_io_base) < 0)
+		return -2;
+#endif
+
+	/* Set the device I'm talking to. */
+	outb(((device & 0x7f) << 1) | 1, smbus_io_base + SMBXMITADD);
+	smbus_delay();
+
+	/* Set the command/address. */
+	outb(0, smbus_io_base + SMBHSTCMD);
+	smbus_delay();
+
+	/* Byte data recv */
+	outb(0x05, smbus_io_base + SMBHSTPRTCL);
+	smbus_delay();
+
+	/* Poll for transaction completion. */
+	if (smbus_wait_until_done(smbus_io_base) < 0)
+		return -3;
+
+	/* Lose check */
+	global_status_register = inb(smbus_io_base + SMBHSTSTAT) & 0x80;
+
+	/* Read results of transaction. */
+	byte = inb(smbus_io_base + SMBHSTDAT0);
+
+	/* Lose check, otherwise it should be 0. */
+	if (global_status_register != 0x80)
+		return -1;
+
+	return byte;
+}
+
+int do_smbus_send_byte(unsigned smbus_io_base, unsigned device,
+			      unsigned char val)
+{
+	unsigned global_status_register;
+
+#if 0
+	/* Not needed, upon write to PRTCL, the status will be auto-cleared. */
+	if (smbus_wait_until_ready(smbus_io_base) < 0)
+		return -2;
+#endif
+
+	outb(val, smbus_io_base + SMBHSTDAT0);
+	smbus_delay();
+
+	/* Set the device I'm talking to. */
+	outb(((device & 0x7f) << 1) | 0, smbus_io_base + SMBXMITADD);
+	smbus_delay();
+
+	outb(0, smbus_io_base + SMBHSTCMD);
+	smbus_delay();
+
+	/* Set up for a byte data write. */
+	outb(0x04, smbus_io_base + SMBHSTPRTCL);
+	smbus_delay();
+
+	/* Poll for transaction completion. */
+	if (smbus_wait_until_done(smbus_io_base) < 0)
+		return -3;
+
+	/* Lose check */
+	global_status_register = inb(smbus_io_base + SMBHSTSTAT) & 0x80;
+
+	if (global_status_register != 0x80)
+		return -1;
+
+	return 0;
+}
+
+int do_smbus_read_byte(unsigned smbus_io_base, unsigned device,
+			      unsigned address)
+{
+	unsigned char global_status_register, byte;
+
+#if 0
+	/* Not needed, upon write to PRTCL, the status will be auto-cleared. */
+	if (smbus_wait_until_ready(smbus_io_base) < 0)
+		return -2;
+#endif
+
+	/* Set the device I'm talking to. */
+	outb(((device & 0x7f) << 1) | 1, smbus_io_base + SMBXMITADD);
+	smbus_delay();
+
+	/* Set the command/address. */
+	outb(address & 0xff, smbus_io_base + SMBHSTCMD);
+	smbus_delay();
+
+	/* Byte data read */
+	outb(0x07, smbus_io_base + SMBHSTPRTCL);
+	smbus_delay();
+
+	/* Poll for transaction completion. */
+	if (smbus_wait_until_done(smbus_io_base) < 0)
+		return -3;
+
+	/* Lose check */
+	global_status_register = inb(smbus_io_base + SMBHSTSTAT) & 0x80;
+
+	/* Read results of transaction. */
+	byte = inb(smbus_io_base + SMBHSTDAT0);
+
+	/* Lose check, otherwise it should be 0. */
+	if (global_status_register != 0x80)
+		return -1;
+
+	return byte;
+}
+
+int do_smbus_write_byte(unsigned smbus_io_base, unsigned device,
+			       unsigned address, unsigned char val)
+{
+	unsigned global_status_register;
+
+#if 0
+	/* Not needed, upon write to PRTCL, the status will be auto-cleared. */
+	if (smbus_wait_until_ready(smbus_io_base) < 0)
+		return -2;
+#endif
+
+	outb(val, smbus_io_base + SMBHSTDAT0);
+	smbus_delay();
+
+	/* Set the device I'm talking to. */
+	outb(((device & 0x7f) << 1) | 0, smbus_io_base + SMBXMITADD);
+	smbus_delay();
+
+	outb(address & 0xff, smbus_io_base + SMBHSTCMD);
+	smbus_delay();
+
+	/* Set up for a byte data write. */
+	outb(0x06, smbus_io_base + SMBHSTPRTCL);
+	smbus_delay();
+
+	/* Poll for transaction completion. */
+	if (smbus_wait_until_done(smbus_io_base) < 0)
+		return -3;
+
+	/* Lose check */
+	global_status_register = inb(smbus_io_base + SMBHSTSTAT) & 0x80;
+
+	if (global_status_register != 0x80)
+		return -1;
+
+	return 0;
+}
+
+int lsmbus_recv_byte(struct device * dev)
+{
+	unsigned device;
+	struct resource *res;
+	struct bus *pbus;
+
+	device = dev->path.i2c.device;
+	pbus = get_pbus_smbus(dev);
+
+	res = find_resource(pbus->dev, 0x20 + (pbus->link * 4));
+
+	return do_smbus_recv_byte(res->base, device);
+}
+
+int lsmbus_send_byte(struct device * dev, u8 val)
+{
+	unsigned device;
+	struct resource *res;
+	struct bus *pbus;
+
+	device = dev->path.i2c.device;
+	pbus = get_pbus_smbus(dev);
+
+	res = find_resource(pbus->dev, 0x20 + (pbus->link * 4));
+
+	return do_smbus_send_byte(res->base, device, val);
+}
+
+int lsmbus_read_byte(struct device * dev, u8 address)
+{
+	unsigned device;
+	struct resource *res;
+	struct bus *pbus;
+
+	device = dev->path.i2c.device;
+	pbus = get_pbus_smbus(dev);
+
+	res = find_resource(pbus->dev, 0x20 + (pbus->link * 4));
+
+	return do_smbus_read_byte(res->base, device, address);
+}
+
+int lsmbus_write_byte(struct device * dev, u8 address, u8 val)
+{
+	unsigned device;
+	struct resource *res;
+	struct bus *pbus;
+
+	device = dev->path.i2c.device;
+	pbus = get_pbus_smbus(dev);
+
+	res = find_resource(pbus->dev, 0x20 + (pbus->link * 4));
+
+	return do_smbus_write_byte(res->base, device, address, val);
+}
+
+struct smbus_bus_operations lops_smbus_bus = {
+	.recv_byte  = lsmbus_recv_byte,
+	.send_byte  = lsmbus_send_byte,
+	.read_byte  = lsmbus_read_byte,
+	.write_byte = lsmbus_write_byte,
+};
+
+struct device_operations ck804_smbus_ops = {
+	.id = {.type = DEVICE_ID_PCI,
+		{.pci = {.vendor = PCI_VENDOR_ID_NVIDIA,
+			 .device = PCI_DEVICE_ID_NVIDIA_CK804_SM}}},
+	.phase3_chip_setup_dev	 = ck804_enable,
+	.phase3_scan		 = scan_static_bus,
+	.phase4_read_resources	 = pci_dev_read_resources,
+	.phase4_set_resources	 = pci_set_resources,
+	.phase5_enable_resources = pci_dev_enable_resources,
+	.ops_pci		 = &ck804_ops_pci,
+	.ops_smbus_bus		 = &lops_smbus_bus,
+};
+

Added: coreboot-v3/southbridge/nvidia/ck804/smbus.dts
===================================================================
--- coreboot-v3/southbridge/nvidia/ck804/smbus.dts	                        (rev 0)
+++ coreboot-v3/southbridge/nvidia/ck804/smbus.dts	2009-01-05 23:08:37 UTC (rev 1100)
@@ -0,0 +1,23 @@
+/*
+ * This file is part of the coreboot project.
+ *
+ * Copyright (C) 2008 Ronald G. Minnich <rminnich 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
+ */
+
+{
+	device_operations = "ck804_smbus_ops";
+};

Added: coreboot-v3/southbridge/nvidia/ck804/stage1.c
===================================================================
--- coreboot-v3/southbridge/nvidia/ck804/stage1.c	                        (rev 0)
+++ coreboot-v3/southbridge/nvidia/ck804/stage1.c	2009-01-05 23:08:37 UTC (rev 1100)
@@ -0,0 +1,434 @@
+/*
+ * This file is part of the coreboot project.
+ *
+ * Copyright (C) 2006 AMD
+ * Written by Yinghai Lu <yinghai.lu 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 <mainboard.h>
+#include <console.h>
+#include <lib.h>
+#include <io.h>
+#include <device/device.h>
+#include <device/pci.h>
+#include <cpu.h>
+#include <amd/k8/k8.h>
+#include "stage1.h"
+
+#ifndef CK804_NUM
+#error CK804_NUM should be defined in mainboard.h (in the mainboard directory)
+#endif
+
+#define CK804_BUSN 0
+#define CK804B_BUSN 1
+
+#if 0
+int set_ht_link_ck804(u8 ht_c_num)
+{
+	int set_ht_link_buffer_counts_chain(u8 ht_c_num, unsigned vendorid,  unsigned val);
+	unsigned vendorid = 0x10de;
+	unsigned val = 0x01610169;
+	/* Nvidia ck804 hardcode, hw can not set it automatically. */
+	return set_ht_link_buffer_counts_chain(ht_c_num, vendorid, val);
+}
+#endif
+
+void setup_ss_table(unsigned index, unsigned where, unsigned control,
+		    const u32 *register_values, int max)
+{
+	int i;
+	unsigned val;
+
+	val = inl(control);
+	val &= 0xfffffffe;
+	outl(val, control);
+
+	outl(0, index);
+
+	for(i = 0; i < max; i++) {
+		unsigned long reg;
+		reg = register_values[i];
+		outl(reg, where);
+	}
+
+	val = inl(control);
+	val |= 1;
+	outl(val, control);
+}
+
+#define ANACTRL_IO_BASE	0x3000
+#define ANACTRL_REG_POS	0x68
+
+#define SYSCTRL_IO_BASE	0x2000
+#define SYSCTRL_REG_POS	0x64
+
+/*
+ *	16 1 1 2 :0
+ *	 8 8 2 2 :1
+ *	 8 8 4   :2
+ *	 8 4 4 4 :3
+ *	16 4     :4
+*/
+
+#ifndef CK804_PCI_E_X
+#define CK804_PCI_E_X 4
+#endif
+
+#ifndef CK804_USE_NIC
+#define CK804_USE_NIC 0
+#endif
+
+#ifndef CK804_USE_ACI
+#define CK804_USE_ACI 0
+#endif
+#ifndef CK804_PCI_E_X
+#define CK804_PCI_E_X 4
+#endif
+
+/*
+ * We will use the offset in setup_resource_map_x_offset and
+ * setup_resource_map_offset.
+ */
+#define CK804B_ANACTRL_IO_BASE 0x3000
+#define CK804B_SYSCTRL_IO_BASE 0x2000
+
+#ifdef CK804B_BUSN
+#undef CK804B_BUSN
+#endif
+#define CK804B_BUSN 0x0
+
+#ifndef CK804B_PCI_E_X
+#define CK804B_PCI_E_X 4
+#endif
+
+#ifndef CK804_USE_NIC
+#define CK804_USE_NIC 0
+#endif
+
+#ifndef CK804_USE_ACI
+#define CK804_USE_ACI 0
+#endif
+
+#define CK804_CHIP_REV 3
+
+#if HT_CHAIN_END_UNITID_BASE < HT_CHAIN_UNITID_BASE
+#define CK804_DEVN_BASE HT_CHAIN_END_UNITID_BASE
+#else
+#define CK804_DEVN_BASE HT_CHAIN_UNITID_BASE
+#endif
+
+#if SB_HT_CHAIN_UNITID_OFFSET_ONLY == 1
+#define CK804B_DEVN_BASE 1
+#else
+#define CK804B_DEVN_BASE CK804_DEVN_BASE
+#endif
+
+void ck804_early_set_port(unsigned ck804_num, unsigned *busn,
+				 unsigned *io_base)
+{
+	static const struct rmap ctrl_devport_conf[] = {
+	PCM(0, (CK804_DEVN_BASE + 0x1), 0, ANACTRL_REG_POS, ~0x0000ff00, ANACTRL_IO_BASE),
+	PCM(0, (CK804_DEVN_BASE + 0x1), 0, SYSCTRL_REG_POS, ~0x0000ff00, SYSCTRL_IO_BASE),
+	};
+
+	int j;
+	for(j = 0; j < ck804_num; j++ ) {
+		setup_resource_map_x_offset(ctrl_devport_conf,
+			ARRAY_SIZE(ctrl_devport_conf),
+			PCI_BDF(busn[j], 0, 0), io_base[j]);
+	}
+}
+
+void ck804_early_clear_port(unsigned ck804_num, unsigned *busn,
+				   unsigned *io_base)
+{
+	static const struct rmap ctrl_devport_conf_clear[] = {
+	PCM(0, (CK804_DEVN_BASE + 0x1), 0, ANACTRL_REG_POS, ~0x0000ff00, 0),
+	PCM(0, (CK804_DEVN_BASE + 0x1), 0, SYSCTRL_REG_POS, ~0x0000ff00, 0),
+	};
+
+	int j;
+	for(j = 0; j < ck804_num; j++ ) {
+		setup_resource_map_x_offset(ctrl_devport_conf_clear,
+			ARRAY_SIZE(ctrl_devport_conf_clear),
+			PCI_BDF(busn[j], 0, 0) , io_base[j]);
+	}
+}
+
+/**
+ * Do early setup
+ * @param ck804_num the number of ck804s on the board
+ * @param busn the number of the bus the ck804 is on
+ * @param io_base
+ */
+
+static void ck804_early_setup(unsigned ck804_num, unsigned *busn,
+			      unsigned *io_base)
+{
+	static const struct rmap ctrl_conf_master[] = {
+	PCM(0, CK804_DEVN_BASE + 1, 2, 0x8c, 0xffff0000, 0x00009880),
+	PCM(0, CK804_DEVN_BASE + 1, 2, 0x90, 0xffff000f, 0x000074a0),
+	PCM(0, CK804_DEVN_BASE + 1, 2, 0xa0, 0xfffff0ff, 0x00000a00),
+	PCM(0, CK804_DEVN_BASE + 1, 2, 0xac, 0xffffff00, 0x00000000),
+
+	PCM(0, CK804_DEVN_BASE, 0, 0x48, 0xfffffffd, 0x00000002),
+	PCM(0, CK804_DEVN_BASE, 0, 0x74, 0xfffff00f, 0x000009d0),
+	PCM(0, CK804_DEVN_BASE, 0, 0x8c, 0xffff0000, 0x0000007f),
+	PCM(0, CK804_DEVN_BASE, 0, 0xcc, 0xfffffff8, 0x00000003),
+	PCM(0, CK804_DEVN_BASE, 0, 0xd0, 0xff000000, 0x00000000),
+	PCM(0, CK804_DEVN_BASE, 0, 0xd4, 0xff000000, 0x00000000),
+	PCM(0, CK804_DEVN_BASE, 0, 0xd8, 0xff000000, 0x00000000),
+	PCM(0, CK804_DEVN_BASE, 0, 0xdc, 0x7f000000, 0x00000000),
+
+	PCM(0, CK804_DEVN_BASE + 1, 0, 0xf0, 0xfffffffd, 0x00000002),
+	PCM(0, CK804_DEVN_BASE + 1, 0, 0xf8, 0xffffffcf, 0x00000010),
+
+	PCM(0, CK804_DEVN_BASE + 9, 0, 0x40, 0xfff8ffff, 0x00030000),
+	PCM(0, CK804_DEVN_BASE + 9, 0, 0x4c, 0xfe00ffff, 0x00440000),
+	PCM(0, CK804_DEVN_BASE + 9, 0, 0x74, 0xffffffc0, 0x00000000),
+
+#ifdef CK804_MB_SETUP
+		CK804_MB_SETUP
+#endif
+#if CK804_NUM > 1
+	PCM(0, CK804_DEVN_BASE + 1, 0, 0x78, 0xc0ffffff, 0x19000000),
+	PCM(0, CK804_DEVN_BASE + 1, 0, 0xe0, 0xfffffeff, 0x00000100),
+#endif
+
+#if CK804_NUM == 1
+	PCM(0, CK804_DEVN_BASE + 1, 0, 0x78, 0xc0ffffff, 0x19000000),
+	PCM(0, CK804_DEVN_BASE + 1, 0, 0xe0, 0xfffffeff, 0x00000100),
+#endif
+
+	IO32(ANACTRL_IO_BASE + 0x20, 0xe00fffff, 0x11000000),
+	IO32(ANACTRL_IO_BASE + 0x24, 0xc3f0ffff, 0x24040000),
+	IO32(ANACTRL_IO_BASE + 0x80, 0x8c3f04df, 0x51407120),
+	IO32(ANACTRL_IO_BASE + 0x84, 0xffffff8f, 0x00000010),
+	IO32(ANACTRL_IO_BASE + 0x94, 0xff00ffff, 0x00c00000),
+	IO32(ANACTRL_IO_BASE + 0xcc, 0xf7ffffff, 0x00000000),
+
+	IO32(ANACTRL_IO_BASE + 0x74, ~(0xffff), 0x0f008),
+	IO32(ANACTRL_IO_BASE + 0x78, ~((0xff) | (0xff << 16)), (0x41 << 16) | (0x32)),
+	IO32(ANACTRL_IO_BASE + 0x7c, ~(0xff << 16), (0xa0 << 16)),
+
+	IO32(ANACTRL_IO_BASE + 0x24, 0xfcffff0f, 0x020000b0),
+
+	PCM(0, CK804_DEVN_BASE + 8, 0, 0x50, ~0x1f000013, 0x15000013),
+	PCM(0, CK804_DEVN_BASE + 8, 0, 0x64, ~0x00000001, 0x00000001),
+	PCM(0, CK804_DEVN_BASE + 8, 0, 0x68, ~0x02000000, 0x02000000),
+	PCM(0, CK804_DEVN_BASE + 8, 0, 0x70, ~0x000f0000, 0x00040000),
+	PCM(0, CK804_DEVN_BASE + 8, 0, 0xa0, ~0x000001ff, 0x00000150),
+	PCM(0, CK804_DEVN_BASE + 8, 0, 0xac, ~0xffff8f00, 0x02aa8b00),
+	PCM(0, CK804_DEVN_BASE + 8, 0, 0x7c, ~0x00000010, 0x00000000),
+	PCM(0, CK804_DEVN_BASE + 8, 0, 0xc8, ~0x0fff0fff, 0x000a000a),
+	PCM(0, CK804_DEVN_BASE + 8, 0, 0xd0, ~0xf0000000, 0x00000000),
+	PCM(0, CK804_DEVN_BASE + 8, 0, 0xe0, ~0xf0000000, 0x00000000),
+
+	IO32(ANACTRL_IO_BASE + 0x04, ~((0x3ff << 0) | (0x3ff << 10)), (0x21 << 0) | (0x22 << 10)),
+
+// PANTA	IO32(ANACTRL_IO_BASE + 0x08, ~(0xfffff), (0x1c << 10) | 0x1b),
+
+	IO32(ANACTRL_IO_BASE + 0x80, ~(1 << 3), 0x00000000),
+
+	IO32(ANACTRL_IO_BASE + 0xcc, ~((7 << 4) | (1 << 8)), (CK804_PCI_E_X << 4) | (1 << 8)),
+
+//SYSCTRL
+	IO8(SYSCTRL_IO_BASE + 0xc0 + 8, (u8)~(0xff), (u8)((0 << 4) | (0 << 2) | (0 << 0))),
+	IO8(SYSCTRL_IO_BASE + 0xc0 + 9, (u8)~(0xff), (u8)((0 << 4) | (1 << 2) | (1 << 0))),
+
+#if CK804_USE_NIC == 1
+	PCM(0, CK804_DEVN_BASE + 0xa, 0, 0xf8, 0xffffffbf, 0x00000040),
+
+	IO8(SYSCTRL_IO_BASE + 0xc0 + 19, (u8)~(0xff), (u8)((0 << 4) | (1 << 2) | (0 << 0)),
+	IO8(SYSCTRL_IO_BASE + 0xc0 + 3, (u8)~(0xff), (u8)((0 << 4) | (1 << 2) | (0 << 0)),
+	IO8(SYSCTRL_IO_BASE + 0xc0 + 3, (u8)~(0xff), (u8)((0 << 4) | (1 << 2) | (1 << 0)),
+	PCM(0, CK804_DEVN_BASE + 1, 0, 0xe4, ~(1 << 23), (1 << 23),
+#endif
+
+#if CK804_USE_ACI == 1
+	IO8(SYSCTRL_IO_BASE + 0xc0 + 0x0d, (u8)~(0xff), (u8)((0 << 4) | (2 << 2) | (0 << 0)),
+	IO8(SYSCTRL_IO_BASE + 0xc0 + 0x1a, (u8)~(0xff), (u8)((0 << 4) | (2 << 2) | (0 << 0)),
+#endif
+
+#if CK804_NUM > 1
+	IO8(SYSCTRL_IO_BASE + 0xc0 + 0, (u8)~(3 << 2), (u8)(0 << 2)),
+#endif
+	};
+
+	static const struct rmap ctrl_conf_slave[] = {
+	PCM(CK804B_BUSN, CK804B_DEVN_BASE + 1, 2, 0x8c, 0xffff0000, 0x00009880),
+	PCM(CK804B_BUSN, CK804B_DEVN_BASE + 1, 2, 0x90, 0xffff000f, 0x000074a0),
+	PCM(CK804B_BUSN, CK804B_DEVN_BASE + 1, 2, 0xa0, 0xfffff0ff, 0x00000a00),
+
+	PCM(CK804B_BUSN, CK804B_DEVN_BASE, 0, 0x48, 0xfffffffd, 0x00000002),
+	PCM(CK804B_BUSN, CK804B_DEVN_BASE, 0, 0x74, 0xfffff00f, 0x000009d0),
+	PCM(CK804B_BUSN, CK804B_DEVN_BASE, 0, 0x8c, 0xffff0000, 0x0000007f),
+	PCM(CK804B_BUSN, CK804B_DEVN_BASE, 0, 0xcc, 0xfffffff8, 0x00000003),
+	PCM(CK804B_BUSN, CK804B_DEVN_BASE, 0, 0xd0, 0xff000000, 0x00000000),
+	PCM(CK804B_BUSN, CK804B_DEVN_BASE, 0, 0xd4, 0xff000000, 0x00000000),
+	PCM(CK804B_BUSN, CK804B_DEVN_BASE, 0, 0xd8, 0xff000000, 0x00000000),
+	PCM(CK804B_BUSN, CK804B_DEVN_BASE, 0, 0xdc, 0x7f000000, 0x00000000),
+
+	PCM(CK804B_BUSN, CK804B_DEVN_BASE + 1, 0, 0xf0, 0xfffffffd, 0x00000002),
+	PCM(CK804B_BUSN, CK804B_DEVN_BASE + 1, 0, 0xf8, 0xffffffcf, 0x00000010),
+
+	PCM(CK804B_BUSN, CK804B_DEVN_BASE + 9, 0, 0x40, 0xfff8ffff, 0x00030000),
+	PCM(CK804B_BUSN, CK804B_DEVN_BASE + 9, 0, 0x4c, 0xfe00ffff, 0x00440000),
+	PCM(CK804B_BUSN, CK804B_DEVN_BASE + 9, 0, 0x74, 0xffffffc0, 0x00000000),
+
+	PCM(CK804B_BUSN, CK804B_DEVN_BASE + 1, 0, 0x78, 0xc0ffffff, 0x20000000),
+	PCM(CK804B_BUSN, CK804B_DEVN_BASE + 1, 0, 0xe0, 0xfffffeff, 0x00000000),
+	PCM(CK804B_BUSN, CK804B_DEVN_BASE + 1, 0, 0xe8, 0xffffff00, 0x000000ff),
+
+	IO32(CK804B_ANACTRL_IO_BASE + 0x20, 0xe00fffff, 0x11000000),
+	IO32(CK804B_ANACTRL_IO_BASE + 0x24, 0xc3f0ffff, 0x24040000),
+	IO32(CK804B_ANACTRL_IO_BASE + 0x80, 0x8c3f04df, 0x51407120),
+	IO32(CK804B_ANACTRL_IO_BASE + 0x84, 0xffffff8f, 0x00000010),
+	IO32(CK804B_ANACTRL_IO_BASE + 0x94, 0xff00ffff, 0x00c00000),
+	IO32(CK804B_ANACTRL_IO_BASE + 0xcc, 0xf7ffffff, 0x00000000),
+
+	IO32(CK804B_ANACTRL_IO_BASE + 0x24, 0xfcffff0f, 0x020000b0),
+
+	PCM(CK804B_BUSN, CK804B_DEVN_BASE + 8, 0, 0x50, ~0x1f000013, 0x15000013),
+	PCM(CK804B_BUSN, CK804B_DEVN_BASE + 8, 0, 0x64, ~0x00000001, 0x00000001),
+	PCM(CK804B_BUSN, CK804B_DEVN_BASE + 8, 0, 0x68, ~0x02000000, 0x02000000),
+	PCM(CK804B_BUSN, CK804B_DEVN_BASE + 8, 0, 0x70, ~0x000f0000, 0x00040000),
+	PCM(CK804B_BUSN, CK804B_DEVN_BASE + 8, 0, 0xa0, ~0x000001ff, 0x00000150),
+	PCM(CK804B_BUSN, CK804B_DEVN_BASE + 8, 0, 0xac, ~0xffff8f00, 0x02aa8b00),
+	PCM(CK804B_BUSN, CK804B_DEVN_BASE + 8, 0, 0x7c, ~0x00000010, 0x00000000),
+	PCM(CK804B_BUSN, CK804B_DEVN_BASE + 8, 0, 0xc8, ~0x0fff0fff, 0x000a000a),
+	PCM(CK804B_BUSN, CK804B_DEVN_BASE + 8, 0, 0xd0, ~0xf0000000, 0x00000000),
+	PCM(CK804B_BUSN, CK804B_DEVN_BASE + 8, 0, 0xe0, ~0xf0000000, 0x00000000),
+
+	IO32(CK804B_ANACTRL_IO_BASE + 0x04, ~((0x3ff << 0) | (0x3ff << 10)), (0x21 << 0) | (0x22 << 10)),
+
+//PANTA	IO32(CK804B_ANACTRL_IO_BASE + 0x08, ~(0xfffff), (0x1c << 10) | 0x1b),
+
+	IO32(CK804B_ANACTRL_IO_BASE + 0x80, ~(1 << 3), 0x00000000),
+
+	IO32(CK804B_ANACTRL_IO_BASE + 0xcc, ~((7 << 4) | (1 << 8)), (CK804B_PCI_E_X << 4) | (1 << 8)),
+
+#if CK804_USE_NIC == 1
+	PCM(0, CK804B_DEVN_BASE + 0xa, 0, 0xf8), 0xffffffbf, 0x00000040),
+	IO8(SYSCTRL_IO_BASE + 0xc0 + 19, ~(0xff), ((0 << 4) | (1 << 2) | (0 << 0))),
+	IO8(SYSCTRL_IO_BASE + 0xc0 + 3, ~(0xff), ((0 << 4) | (1 << 2) | (0 << 0))),
+	IO8(SYSCTRL_IO_BASE + 0xc0 + 3, ~(0xff), ((0 << 4) | (1 << 2) | (1 << 0))),
+	PCM(CK804B_BUSN, CK804B_DEVN_BASE + 1, 0, 0xe4), ~(1 << 23), (1 << 23)),
+#endif
+	};
+
+	int j;
+	for (j = 0; j < ck804_num; j++) {
+		if (busn[j] == 0) {
+			setup_resource_map_x_offset(ctrl_conf_master,
+				ARRAY_SIZE(ctrl_conf_master),
+				PCI_BDF(busn[0], 0, 0), io_base[0]);
+			continue;
+		}
+
+		setup_resource_map_x_offset(ctrl_conf_slave, ARRAY_SIZE(ctrl_conf_slave),
+				PCI_BDF(busn[j], 0, 0), io_base[j]);
+	}
+
+#if 0
+	for(j=0; j< ck804_num; j++) {
+		/* PCI-E (XSPLL) SS table 0x40, x044, 0x48 */
+		/* SATA  (SPPLL) SS table 0xb0, 0xb4, 0xb8 */
+		/* CPU   (PPLL)  SS table 0xc0, 0xc4, 0xc8 */
+		setup_ss_table(io_base[j] + ANACTRL_IO_BASE+0x40,
+			       io_base[j] + ANACTRL_IO_BASE+0x44,
+			       io_base[j] + ANACTRL_IO_BASE+0x48,
+			       pcie_ss_tbl, 64);
+		setup_ss_table(io_base[j] + ANACTRL_IO_BASE+0xb0,
+			       io_base[j] + ANACTRL_IO_BASE+0xb4,
+			       io_base[j] + ANACTRL_IO_BASE+0xb8,
+			       sata_ss_tbl, 64);
+//PANTA		setup_ss_table(io_base[j] + ANACTRL_IO_BASE+0xc0,
+//			       io_base[j] + ANACTRL_IO_BASE+0xc4,
+//			       io_base[j] + ANACTRL_IO_BASE+0xc8,
+//			       cpu_ss_tbl, 64);
+	}
+#endif
+}
+
+#ifndef HT_CHAIN_NUM_MAX
+
+#define HT_CHAIN_NUM_MAX	4
+#define HT_CHAIN_BUSN_D	0x40
+#define HT_CHAIN_IOBASE_D	0x4000
+
+#endif
+
+int ck804_early_setup_x(void)
+{
+	unsigned busn[4], io_base[4];
+	int i, ck804_num = 0;
+
+	for (i = 0; i < 4; i++) {
+		u32 id;
+		u32 dev;
+		if (i == 0) // SB chain
+			dev = PCI_BDF(i * 0x40, CK804_DEVN_BASE, 0);
+		else
+			dev = PCI_BDF(i * 0x40, CK804B_DEVN_BASE, 0);
+		id = pci_conf1_read_config32(dev, PCI_VENDOR_ID);
+		if (id == 0x005e10de) {
+			busn[ck804_num] = i * 0x40;
+			io_base[ck804_num] = i * 0x4000;
+			ck804_num++;
+		}
+	}
+
+	ck804_early_set_port(ck804_num, busn, io_base);
+	ck804_early_setup(ck804_num, busn, io_base);
+	ck804_early_clear_port(ck804_num, busn, io_base);
+
+	//return set_ht_link_ck804(4);
+	return 0;
+}
+
+unsigned int get_sbdn(unsigned int bus)
+{
+	return CK804_DEVN_BASE;
+}
+
+void set_bios_reset(void);
+void hard_reset(void)
+{
+	set_bios_reset();
+
+	/* full reset */
+	outb(0x0a, 0x0cf9);
+	outb(0x0e, 0x0cf9);
+}
+
+void enable_fid_change_on_sb(unsigned sbbusn, unsigned sbdn)
+{
+	/* default value for ck804 is good */
+}
+
+void soft_reset(void)
+{
+	set_bios_reset();
+	/* link reset */
+	outb(0x02, 0x0cf9);
+	outb(0x06, 0x0cf9);
+}
+
+void soft_reset_x(unsigned sbbusn, unsigned sbdn)
+{
+	soft_reset();
+}

Added: coreboot-v3/southbridge/nvidia/ck804/stage1.h
===================================================================
--- coreboot-v3/southbridge/nvidia/ck804/stage1.h	                        (rev 0)
+++ coreboot-v3/southbridge/nvidia/ck804/stage1.h	2009-01-05 23:08:37 UTC (rev 1100)
@@ -0,0 +1,205 @@
+/*
+ * Copyright 2004 Tyan Computer
+ *  by yhlu at tyan.com
+ */
+
+static const u32 pcie_ss_tbl[] = {
+	0x0C504103f,
+	0x0C504103f,
+	0x0C504103f,
+	0x0C5042040,
+	0x0C5042040,
+	0x0C5042040,
+	0x0C5043041,
+	0x0C5043041,
+	0x0C5043041,
+	0x0C5043041,
+	0x0C5044042,
+	0x0C5044042,
+	0x0C5044042,
+	0x0C5045043,
+	0x0C5045043,
+	0x0C5045043,
+	0x0C5045043,
+	0x0C5045043,
+	0x0C5046044,
+	0x0C5046044,
+	0x0C5046044,
+	0x0C5046044,
+	0x0C5047045,
+	0x0C5047045,
+	0x0C5047045,
+	0x0C5047045,
+	0x0C5047045,
+	0x0C5048046,
+	0x0C5048046,
+	0x0C5048046,
+	0x0C5048046,
+	0x0C5049047,
+	0x0C5049047,
+	0x0C5049047,
+	0x0C504a048,
+	0x0C504a048,
+	0x0C504b049,
+	0x0C504b049,
+	0x0C504a048,
+	0x0C504a048,
+	0x0C5049047,
+	0x0C5049047,
+	0x0C5048046,
+	0x0C5048046,
+	0x0C5048046,
+	0x0C5047045,
+	0x0C5047045,
+	0x0C5047045,
+	0x0C5047045,
+	0x0C5047045,
+	0x0C5046044,
+	0x0C5046044,
+	0x0C5046044,
+	0x0C5046044,
+	0x0C5045043,
+	0x0C5045043,
+	0x0C5045043,
+	0x0C5044042,
+	0x0C5044042,
+	0x0C5044042,
+	0x0C5043041,
+	0x0C5043041,
+	0x0C5042040,
+	0x0C5042040,
+};
+
+static const u32 sata_ss_tbl[] = {
+	0x0c9044042,
+	0x0c9044042,
+	0x0c9044042,
+	0x0c9045043,
+	0x0c9045043,
+	0x0c9045043,
+	0x0c9045043,
+	0x0c9045043,
+	0x0c9046044,
+	0x0c9046044,
+	0x0c9046044,
+	0x0c9046044,
+	0x0c9047045,
+	0x0c9047045,
+	0x0c9047045,
+	0x0c9047045,
+	0x0c9047045,
+	0x0c9048046,
+	0x0c9048046,
+	0x0c9048046,
+	0x0c9048046,
+	0x0c9049047,
+	0x0c9049047,
+	0x0c9049047,
+	0x0c9049047,
+	0x0c904a048,
+	0x0c904a048,
+	0x0c904a048,
+	0x0c904a048,
+	0x0c904b049,
+	0x0c904b049,
+	0x0c904b049,
+	0x0c904b049,
+	0x0c904b049,
+	0x0c904b049,
+	0x0c904a048,
+	0x0c904a048,
+	0x0c904a048,
+	0x0c904a048,
+	0x0c9049047,
+	0x0c9049047,
+	0x0c9049047,
+	0x0c9049047,
+	0x0c9048046,
+	0x0c9048046,
+	0x0c9048046,
+	0x0c9048046,
+	0x0c9047045,
+	0x0c9047045,
+	0x0c9047045,
+	0x0c9047045,
+	0x0c9047045,
+	0x0c9046044,
+	0x0c9046044,
+	0x0c9046044,
+	0x0c9046044,
+	0x0c9045043,
+	0x0c9045043,
+	0x0c9045043,
+	0x0c9045043,
+	0x0c9045043,
+	0x0c9044042,
+	0x0c9044042,
+	0x0c9044042,
+};
+
+static const u32 cpu_ss_tbl[] = {
+	0x0C5038036,
+	0x0C5038036,
+	0x0C5038036,
+	0x0C5037035,
+	0x0C5037035,
+	0x0C5037035,
+	0x0C5037035,
+	0x0C5036034,
+	0x0C5036034,
+	0x0C5036034,
+	0x0C5036034,
+	0x0C5036034,
+	0x0C5035033,
+	0x0C5035033,
+	0x0C5035033,
+	0x0C5035033,
+	0x0C5035033,
+	0x0C5035033,
+	0x0C5034032,
+	0x0C5034032,
+	0x0C5034032,
+	0x0C5034032,
+	0x0C5034032,
+	0x0C5034032,
+	0x0C5035033,
+	0x0C5035033,
+	0x0C5035033,
+	0x0C5035033,
+	0x0C5035033,
+	0x0C5036034,
+	0x0C5036034,
+	0x0C5036034,
+	0x0C5036034,
+	0x0C5036034,
+	0x0C5037035,
+	0x0C5037035,
+	0x0C5037035,
+	0x0C5037035,
+	0x0C5038036,
+	0x0C5038036,
+	0x0C5038036,
+	0x0C5038036,
+	0x0C5039037,
+	0x0C5039037,
+	0x0C5039037,
+	0x0C5039037,
+	0x0C503a038,
+	0x0C503a038,
+	0x0C503a038,
+	0x0C503a038,
+	0x0C503b039,
+	0x0C503b039,
+	0x0C503b039,
+	0x0C503b039,
+	0x0C503b039,
+	0x0C503a038,
+	0x0C503a038,
+	0x0C503a038,
+	0x0C503a038,
+	0x0C503a038,
+	0x0C5039037,
+	0x0C5039037,
+	0x0C5039037,
+	0x0C5039037,
+};

Added: coreboot-v3/southbridge/nvidia/ck804/stage1_enable_rom.c
===================================================================
--- coreboot-v3/southbridge/nvidia/ck804/stage1_enable_rom.c	                        (rev 0)
+++ coreboot-v3/southbridge/nvidia/ck804/stage1_enable_rom.c	2009-01-05 23:08:37 UTC (rev 1100)
@@ -0,0 +1,29 @@
+/*
+ * Copyright 2004 Tyan Computer
+ *  by yhlu at tyan.com
+ */
+
+#include <mainboard.h>
+#include <types.h>
+#include <device/pci.h>
+
+#if HT_CHAIN_END_UNITID_BASE < HT_CHAIN_UNITID_BASE
+#define CK804_DEVN_BASE HT_CHAIN_END_UNITID_BASE
+#else
+#define CK804_DEVN_BASE HT_CHAIN_UNITID_BASE
+#endif
+
+void ck804_enable_rom(void)
+{
+	unsigned char byte;
+	u32 addr;
+
+	/* Enable 4MB ROM access at 0xFFC00000 - 0xFFFFFFFF. */
+	/* Locate the ck804 LPC. */
+	addr = PCI_BDEVFN(0, PCI_DEVFN((CK804_DEVN_BASE + 1), 0));
+
+	/* Set the 4MB enable bit. */
+	byte = pci_conf1_read_config8(addr, 0x88);
+	byte |= 0x80;
+	pci_conf1_write_config8(addr, 0x88, byte);
+}

Added: coreboot-v3/southbridge/nvidia/ck804/stage1_smbus.c
===================================================================
--- coreboot-v3/southbridge/nvidia/ck804/stage1_smbus.c	                        (rev 0)
+++ coreboot-v3/southbridge/nvidia/ck804/stage1_smbus.c	2009-01-05 23:08:37 UTC (rev 1100)
@@ -0,0 +1,55 @@
+/*
+ * AMD 8111 "southbridge"
+ * This file is part of the coreboot project.
+ * Copyright 2004 Tyan Computer
+ *  (Written by Yinghai Lu <yhlu at tyan.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; 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 <console.h>
+#include <device/pci.h>
+#include <device/pci_ids.h>
+#include "ck804_smbus.h"
+
+#define SMBUS_IO_BASE 0x1000
+
+void enable_smbus(void)
+{
+	u32 dev;
+
+	if (!pci_conf1_find_on_bus(0, PCI_VENDOR_ID_NVIDIA, 0x0052, &dev))
+		die("SMBus controller not found\n");
+
+	printk(BIOS_DEBUG,"SMBus controller enabled\n");
+
+	/* Set SMBus I/O base. */
+	pci_conf1_write_config32(dev, 0x20, SMBUS_IO_BASE | 1);
+
+	/* Set SMBus I/O space enable. */
+	pci_conf1_write_config16(dev, 0x4, 0x01);
+
+	/* Clear any lingering errors, so the transaction will run. */
+	outb(inb(SMBUS_IO_BASE + SMBHSTSTAT), SMBUS_IO_BASE + SMBHSTSTAT);
+}
+
+int smbus_read_byte(u16 dev, u16 address)
+{
+	return do_smbus_read_byte(SMBUS_IO_BASE, dev, address);
+}
+
+int smbus_write_byte(u16 dev, u16 address, u8 val)
+{
+	return do_smbus_write_byte(SMBUS_IO_BASE, dev, address, val);
+}

Added: coreboot-v3/southbridge/nvidia/ck804/usb.c
===================================================================
--- coreboot-v3/southbridge/nvidia/ck804/usb.c	                        (rev 0)
+++ coreboot-v3/southbridge/nvidia/ck804/usb.c	2009-01-05 23:08:37 UTC (rev 1100)
@@ -0,0 +1,62 @@
+/*
+ * This file is part of the coreboot project.
+ *
+ * Copyright 2004 Tyan Computer
+ *  by yhlu at tyan.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 <types.h>
+#include <console.h>
+#include <device/device.h>
+#include <device/pci.h>
+#include <device/pci_ids.h>
+#include <device/pci_ops.h>
+#include <statictree.h>
+#include "ck804.h"
+
+static void usb1_init(struct device *dev)
+{
+	struct southbridge_nvidia_ck804_usb_config const *conf = dev->device_configuration;
+	if (conf->usb1_hc_reset) {
+		/*
+		 * Somehow the warm reset does not really reset the USB
+		 * controller. Later, during boot, when the Bus Master bit is
+		 * set, the USB controller trashes the memory, causing weird
+		 * misbehavior. Was detected on Sun Ultra40, where mptable
+		 * was damaged.
+		 */
+		u32 bar0 = pci_read_config32(dev, 0x10);
+		u32 *regs = (u32 *) (bar0 & ~0xfff);
+
+		/* OHCI USB HCCommandStatus Register, HostControllerReset bit */
+		regs[2] |= 1;
+	}
+}
+
+struct device_operations ck804_usb_ops = {
+	.id = {.type = DEVICE_ID_PCI,
+		{.pci = {.vendor = PCI_VENDOR_ID_NVIDIA,
+			 .device = PCI_DEVICE_ID_NVIDIA_CK804_USB}}},
+	.phase3_chip_setup_dev	 = ck804_enable,
+	.phase3_scan		 = NULL,
+	.phase4_read_resources	 = pci_dev_read_resources,
+	.phase4_set_resources	 = pci_set_resources,
+	.phase5_enable_resources = pci_dev_enable_resources,
+	.phase6_init		 = usb1_init,
+	.ops_pci		 = &ck804_ops_pci,
+};
+

Added: coreboot-v3/southbridge/nvidia/ck804/usb.dts
===================================================================
--- coreboot-v3/southbridge/nvidia/ck804/usb.dts	                        (rev 0)
+++ coreboot-v3/southbridge/nvidia/ck804/usb.dts	2009-01-05 23:08:37 UTC (rev 1100)
@@ -0,0 +1,24 @@
+/*
+ * This file is part of the coreboot project.
+ *
+ * Copyright (C) 2008 Ronald G. Minnich <rminnich 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
+ */
+
+{
+	device_operations = "ck804_usb2_ops";
+	usb1_hc_reset = "1";
+};

Added: coreboot-v3/southbridge/nvidia/ck804/usb2.c
===================================================================
--- coreboot-v3/southbridge/nvidia/ck804/usb2.c	                        (rev 0)
+++ coreboot-v3/southbridge/nvidia/ck804/usb2.c	2009-01-05 23:08:37 UTC (rev 1100)
@@ -0,0 +1,50 @@
+/*
+ * This file is part of the coreboot project.
+ *
+ * Copyright 2004 Tyan Computer
+ *  by yhlu at tyan.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 <types.h>
+#include <console.h>
+#include <device/device.h>
+#include <device/pci.h>
+#include <device/pci_ids.h>
+#include <device/pci_ops.h>
+#include "ck804.h"
+
+static void usb2_init(struct device *dev)
+{
+	u32 dword;
+	dword = pci_read_config32(dev, 0xf8);
+	dword |= 40;
+	pci_write_config32(dev, 0xf8, dword);
+}
+
+struct device_operations ck804_usb2_ops = {
+	.id = {.type = DEVICE_ID_PCI,
+		{.pci = {.vendor = PCI_VENDOR_ID_NVIDIA,
+			 .device = PCI_DEVICE_ID_NVIDIA_CK804_USB2}}},
+	.phase3_chip_setup_dev	 = ck804_enable,
+	.phase3_scan		 = NULL,
+	.phase4_read_resources	 = pci_dev_read_resources,
+	.phase4_set_resources	 = pci_set_resources,
+	.phase5_enable_resources = pci_dev_enable_resources,
+	.phase6_init		 = usb2_init,
+	.ops_pci		 = &ck804_ops_pci,
+};
+

Added: coreboot-v3/southbridge/nvidia/ck804/usb2.dts
===================================================================
--- coreboot-v3/southbridge/nvidia/ck804/usb2.dts	                        (rev 0)
+++ coreboot-v3/southbridge/nvidia/ck804/usb2.dts	2009-01-05 23:08:37 UTC (rev 1100)
@@ -0,0 +1,23 @@
+/*
+ * This file is part of the coreboot project.
+ *
+ * Copyright (C) 2008 Ronald G. Minnich <rminnich 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
+ */
+
+{
+	device_operations = "ck804_usb_ops";
+};




From mylesgw at gmail.com  Tue Jan  6 00:09:37 2009
From: mylesgw at gmail.com (Myles Watson)
Date: Mon, 5 Jan 2009 16:09:37 -0700
Subject: [coreboot] v3 ck804 support
In-Reply-To: <20090105223651.10427.qmail@stuge.se>
References: <2831fecf0901051114l4836e020hfe91f76b788ff87b@mail.gmail.com>
	<20090105223651.10427.qmail@stuge.se>
Message-ID: <2831fecf0901051509x31e9f362ld6a3870748de1e5b@mail.gmail.com>

On Mon, Jan 5, 2009 at 3:36 PM, Peter Stuge <peter at stuge.se> wrote:
> Myles Watson wrote:
>> This patch adds southbridge/nvidia/ck804 from v2 minimally updated
>> for v3.
>
> Mostly fine, but..
>
>
>> +     /* If that is invalid we will read that from romstrap. */
>> +     if (!eeprom_valid) {
>> +             unsigned long mac_pos;
>> +             mac_pos = 0xffffffd0; /* See romstrap.inc and romstrap.lds. */
>> +             mac_l = readl(mac_pos) + nic_index;
>> +             mac_h = readl(mac_pos + 4);
>> +     }
>
> ..this won't work so well in v3 I think. I'd like a LAR file for the
> MAC.
>
>
>> +#if CONFIG_PCI_ROM_RUN == 1
>> +     pci_dev_init(dev);      /* It will init Option ROM. */
>> +#endif
>
> Should this be in the NIC code?
>
>
>> +// 0x7a or e3
>> +#define PREVIOUS_POWER_STATE 0x7A
>> +
>> +#define MAINBOARD_POWER_OFF 0
>> +#define MAINBOARD_POWER_ON 1
>> +#define SLOW_CPU_OFF 0
>> +#define SLOW_CPU__ON 1
>> +
>> +#ifndef MAINBOARD_POWER_ON_AFTER_POWER_FAIL
>> +#define MAINBOARD_POWER_ON_AFTER_POWER_FAIL MAINBOARD_POWER_ON
>> +#endif
>
> We should make this a CONFIG_ variable.
>
>
> Anyway:
> Acked-by: Peter Stuge <peter at stuge.se>

Rev 1100.

I added your concerns to the commit message so they won't be forgotten.

Thanks,
Myles



From peter at stuge.se  Tue Jan  6 00:12:30 2009
From: peter at stuge.se (Peter Stuge)
Date: Tue, 6 Jan 2009 00:12:30 +0100
Subject: [coreboot] v3 ck804 support
In-Reply-To: <2831fecf0901051509x31e9f362ld6a3870748de1e5b@mail.gmail.com>
References: <2831fecf0901051114l4836e020hfe91f76b788ff87b@mail.gmail.com>
	<20090105223651.10427.qmail@stuge.se>
	<2831fecf0901051509x31e9f362ld6a3870748de1e5b@mail.gmail.com>
Message-ID: <20090105231230.19040.qmail@stuge.se>

Myles Watson wrote:
> I added your concerns to the commit message so they won't be
> forgotten.

Didn't see them, but anyway maybe TODOs in the source would be
better.


//Peter



From mylesgw at gmail.com  Tue Jan  6 00:19:00 2009
From: mylesgw at gmail.com (Myles Watson)
Date: Mon, 5 Jan 2009 16:19:00 -0700
Subject: [coreboot] v3 ck804 support
In-Reply-To: <20090105231230.19040.qmail@stuge.se>
References: <2831fecf0901051114l4836e020hfe91f76b788ff87b@mail.gmail.com>
	<20090105223651.10427.qmail@stuge.se>
	<2831fecf0901051509x31e9f362ld6a3870748de1e5b@mail.gmail.com>
	<20090105231230.19040.qmail@stuge.se>
Message-ID: <2831fecf0901051519s5225cc4dk15382200dd2d692e@mail.gmail.com>

On Mon, Jan 5, 2009 at 4:12 PM, Peter Stuge <peter at stuge.se> wrote:
> Myles Watson wrote:
>> I added your concerns to the commit message so they won't be
>> forgotten.
>
> Didn't see them, but anyway maybe TODOs in the source would be
> better.

Sure.  I'll put them in.

Thanks,
Myles



From uwe at hermann-uwe.de  Tue Jan  6 00:24:13 2009
From: uwe at hermann-uwe.de (Uwe Hermann)
Date: Tue, 6 Jan 2009 00:24:13 +0100
Subject: [coreboot] [PATCH] There's a pciconf.h with PCI conf
	constants	- lets actually use it
In-Reply-To: <1231166997.20385.3.camel@martr-gentoo.artec>
References: <1231166997.20385.3.camel@martr-gentoo.artec>
Message-ID: <20090105232412.GC12484@greenwood>

On Mon, Jan 05, 2009 at 04:49:57PM +0200, Mart Raudsepp wrote:
> In case it's a good idea to use these constants from that header, here's the proposed commit log and patch:
> 
> 
> 
> There's a pciconf.h with PCI conf constants - lets actually use it
> 
> PCI_CONF_REG_{INDEX,DATA} constants instead of 0xCF8 and 0xCFF everywhere.
> Not touching YABEL as I'm not sure it would want to include that header.
> 
> Signed-off-by: Mart Raudsepp <mart.raudsepp at artecdesign.ee>

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


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



From mylesgw at gmail.com  Tue Jan  6 00:25:05 2009
From: mylesgw at gmail.com (Myles Watson)
Date: Mon, 5 Jan 2009 16:25:05 -0700
Subject: [coreboot] v3 Tyan s2892
In-Reply-To: <20090105230710.17810.qmail@stuge.se>
References: <2831fecf0901051115l154c9ebdo258c718ad095b067@mail.gmail.com>
	<20090105230710.17810.qmail@stuge.se>
Message-ID: <2831fecf0901051525oa1d6170l1560e03cc0fe7893@mail.gmail.com>

On Mon, Jan 5, 2009 at 4:07 PM, Peter Stuge <peter at stuge.se> wrote:
> Myles Watson wrote:
>> This patch adds initial support for mainboard/tyan/s2892.  It
>> compiles, but is untested in hardware.
>
> I think this needs a little polishing.

Thanks for the help.  I'll resubmit tomorrow.  I've got a few questions inlined.

>> +++ svn/mainboard/tyan/s2892/mainboard.c
> ..
>> +struct device_operations s2892 = {
>> +     .id = {.type = DEVICE_ID_PCI,
>> +             {.pci = {.vendor = PCI_VENDOR_ID_TYAN,
>> +                      .device = 0x2892}}},
>> +     .constructor = default_device_constructor,
>> +};
>
> Why is this needed? The board itself isn't a PCI device. It can
> certainly have a subsystem it belonging to it, but that was already
> specified in the dts so must not be needed to duplicate here.

The board gets enumerated as a device in the tree, and I find it
helpful to have it show up with a type, vendor, and device ID instead
of Unknown Device.  Do you think we should create a new type for
mainboards?

I appreciate the reviews.

Thanks,
Myles



From uwe at hermann-uwe.de  Tue Jan  6 00:27:01 2009
From: uwe at hermann-uwe.de (Uwe Hermann)
Date: Tue, 6 Jan 2009 00:27:01 +0100
Subject: [coreboot] [PATCH] flashrom: add SST49LF020 support
In-Reply-To: <877i5ahon6.fsf@apollo.stackframe.org>
References: <877i5ahon6.fsf@apollo.stackframe.org>
Message-ID: <20090105232701.GD12484@greenwood>

On Sun, Jan 04, 2009 at 08:11:57PM +0100, Sven Schnelle wrote:
> Hi List,
> 
> i've added support for the SST 49LF020 Flash chip to flashrom. Basically
> only the device Id differs, the programming algorithm seems to be the
> same as for SST 49LF020A.
> 
> I've only tested read so far, i'm a bit reluctant to test
> erase/programming without a backup BIOS chip :)

You forgot the Signed-off-by for this patch, please repost with that.


> Index: flash.h
> ===================================================================
> --- flash.h	(revision 3845)
> +++ flash.h	(working copy)
> @@ -356,6 +356,7 @@
>  #define SST_39VF040		0xD7
>  #define SST_49LF040B		0x50
>  #define SST_49LF040		0x51
> +#define SST_49LF020            0x61
>  #define SST_49LF020A		0x52
>  #define SST_49LF080A		0x5B
>  #define SST_49LF002A		0x57
> Index: flashchips.c
> ===================================================================
> --- flashchips.c	(revision 3845)
> +++ flashchips.c	(working copy)
> @@ -626,6 +626,12 @@
>  	 probe_49lfxxxc, erase_49lfxxxc, write_49lfxxxc
>  	},
>  
> +	{"SST", "SST49LF020", SST_ID, SST_49LF020,
> +	 256, 16 * 1024,
> +	 TEST_UNTESTED,

As reading works, this is not UNSTESTED. At least PROBE and READ
should be marked as working.


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



From peter at stuge.se  Tue Jan  6 00:38:00 2009
From: peter at stuge.se (Peter Stuge)
Date: Tue, 6 Jan 2009 00:38:00 +0100
Subject: [coreboot] [PATCH] There's a pciconf.h with PCI conf
	constants	- lets actually use it
In-Reply-To: <20090105232412.GC12484@greenwood>
References: <1231166997.20385.3.camel@martr-gentoo.artec>
	<20090105232412.GC12484@greenwood>
Message-ID: <20090105233800.24547.qmail@stuge.se>

Uwe Hermann wrote:
> > There's a pciconf.h with PCI conf constants - lets actually use it
> > 
> > PCI_CONF_REG_{INDEX,DATA} constants instead of 0xCF8 and 0xCFF everywhere.
> > Not touching YABEL as I'm not sure it would want to include that header.
> > 
> > Signed-off-by: Mart Raudsepp <mart.raudsepp at artecdesign.ee>
> 
> Acked-by: Uwe Hermann <uwe at hermann-uwe.de>

Please don't commit this. I would rather see the 0xcf8 and cfc
defines removed. This is PCI code, these ports will never change
for PCI buses, and they are the first thing most learn about PCI
programming.

Defines add indirection = complexity = error sources. I'm with
Stefan, we should use them carefully.


//Peter



From uwe at hermann-uwe.de  Tue Jan  6 01:03:41 2009
From: uwe at hermann-uwe.de (Uwe Hermann)
Date: Tue, 6 Jan 2009 01:03:41 +0100
Subject: [coreboot] [PATCH] Check the printk format string against
	the	arguments
In-Reply-To: <49620508.6080906@gmx.net>
References: <49620508.6080906@gmx.net>
Message-ID: <20090106000341.GE12484@greenwood>

On Mon, Jan 05, 2009 at 02:03:04PM +0100, Carl-Daniel Hailfinger wrote:
> Check the printk format string against the matching arguments. We have
> this type of checking in the v3 code since ages, but v2 will happily
> compile any code with bogus printk format strings and/or parameters.
> This can cause real bugs and at least needs to emit a warning, if not an
> error. Go with a warning for now since most of the flagged format
> strings are wrong but harmless in a 32-bit x86 environment.
[...] 
> Signed-off-by: Carl-Daniel Hailfinger <c-d.hailfinger.devel.2006 at gmx.net>

If this is abuild-tested, it's:

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

(Please make sure we don't get some romcc compile trouble because of
the __attribute__)

 
> Index: LinuxBIOSv2-printk_format/src/include/console/console.h
> ===================================================================
> --- LinuxBIOSv2-printk_format/src/include/console/console.h	(Revision 3845)
> +++ LinuxBIOSv2-printk_format/src/include/console/console.h	(Arbeitskopie)
> @@ -27,7 +27,7 @@
>  extern struct console_driver econsole_drivers[];
>  
>  extern int console_loglevel;
> -int do_printk(int msg_level, const char *fmt, ...);
> +int do_printk(int msg_level, const char *fmt, ...) __attribute__((format(printf, 2, 3)));
>  
>  #define printk_emerg(fmt, arg...)   do_printk(BIOS_EMERG   ,fmt, ##arg)
>  #define printk_alert(fmt, arg...)   do_printk(BIOS_ALERT   ,fmt, ##arg)
 

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



From svn at coreboot.org  Tue Jan  6 01:05:45 2009
From: svn at coreboot.org (svn at coreboot.org)
Date: Tue,  6 Jan 2009 01:05:45 +0100
Subject: [coreboot] r1101 - coreboot-v3/util/x86emu/yabel
Message-ID: <mailman.2636.1355071466.16123.coreboot@coreboot.org>

Author: uwe
Date: 2009-01-06 01:05:45 +0100 (Tue, 06 Jan 2009)
New Revision: 1101

Modified:
   coreboot-v3/util/x86emu/yabel/pmm.c
   coreboot-v3/util/x86emu/yabel/pmm.h
Log:
Add missing BSD license header to the PMM files.

Signed-off-by: Pattrick Hueper <phueper at hueper.net>
Acked-by: Uwe Hermann <uwe at hermann-uwe.de>



Modified: coreboot-v3/util/x86emu/yabel/pmm.c
===================================================================
--- coreboot-v3/util/x86emu/yabel/pmm.c	2009-01-05 23:08:37 UTC (rev 1100)
+++ coreboot-v3/util/x86emu/yabel/pmm.c	2009-01-06 00:05:45 UTC (rev 1101)
@@ -1,6 +1,11 @@
 /****************************************************************************
  * YABEL BIOS Emulator
  *
+ * This program and the accompanying materials
+ * are made available under the terms of the BSD License
+ * which accompanies this distribution, and is available at
+ * http://www.opensource.org/licenses/bsd-license.php
+ *
  * Copyright 2008 Pattrick Hueper <phueper at hueper.net>
  ****************************************************************************/
 

Modified: coreboot-v3/util/x86emu/yabel/pmm.h
===================================================================
--- coreboot-v3/util/x86emu/yabel/pmm.h	2009-01-05 23:08:37 UTC (rev 1100)
+++ coreboot-v3/util/x86emu/yabel/pmm.h	2009-01-06 00:05:45 UTC (rev 1101)
@@ -1,6 +1,11 @@
 /****************************************************************************
  * YABEL BIOS Emulator
  *
+ * This program and the accompanying materials
+ * are made available under the terms of the BSD License
+ * which accompanies this distribution, and is available at
+ * http://www.opensource.org/licenses/bsd-license.php
+ *
  * Copyright 2008 Pattrick Hueper <phueper at hueper.net>
  ****************************************************************************/
 




From uwe at hermann-uwe.de  Tue Jan  6 01:07:42 2009
From: uwe at hermann-uwe.de (Uwe Hermann)
Date: Tue, 6 Jan 2009 01:07:42 +0100
Subject: [coreboot] [PATCH] YABEL: add license to pmm files
In-Reply-To: <b5765cdf0901050424s36a049c5q5c4d17d33079fee9@mail.gmail.com>
References: <b5765cdf0901050424s36a049c5q5c4d17d33079fee9@mail.gmail.com>
Message-ID: <20090106000742.GF12484@greenwood>

On Mon, Jan 05, 2009 at 01:24:43PM +0100, Pattrick Hueper wrote:
> Hi,
> 
> i just saw, that i forgot to add a BSD license header to the PMM
> files, this patch fixes that.
> 
> Patty
> 
>  Signed-off-by: Pattrick Hueper <phueper at hueper.net>

Thanks, r1101.

Please also add the proper license headers to

  util/x86emu/yabel/compat/functions.c
  util/x86emu/yabel/compat/time.h


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



From peter at stuge.se  Tue Jan  6 01:11:41 2009
From: peter at stuge.se (Peter Stuge)
Date: Tue, 6 Jan 2009 01:11:41 +0100
Subject: [coreboot] [PATCH] flashrom: add AMD-768 chipset support
In-Reply-To: <871vvihog9.fsf@apollo.stackframe.org>
References: <871vvihog9.fsf@apollo.stackframe.org>
Message-ID: <20090106001141.542.qmail@stuge.se>

Hi Sven,

Sven Schnelle wrote:
> the patch attached adds support for the AMD-768 chipset.
..

> +static int enable_flash_amd768(struct pci_dev *dev, const char *name)
> +{
> +	/* enable address decoding for LPC */
> +	pci_write_byte(dev, 0x40, pci_read_byte(dev, 0x40) | 0x01);
> +	pci_write_byte(dev, 0x43, 0xbf);
> +
> +	return 0;
> +}

Does this chipset supporty anything else than LPC?


//Peter



From svn at coreboot.org  Tue Jan  6 01:33:31 2009
From: svn at coreboot.org (svn at coreboot.org)
Date: Tue,  6 Jan 2009 01:33:31 +0100
Subject: [coreboot] r3846 - in trunk/coreboot-v2/src/superio/winbond: .
	w83627uhg
Message-ID: <mailman.2637.1355071467.16123.coreboot@coreboot.org>

Author: uwe
Date: 2009-01-06 01:33:30 +0100 (Tue, 06 Jan 2009)
New Revision: 3846

Added:
   trunk/coreboot-v2/src/superio/winbond/w83627uhg/
   trunk/coreboot-v2/src/superio/winbond/w83627uhg/Config.lb
   trunk/coreboot-v2/src/superio/winbond/w83627uhg/chip.h
   trunk/coreboot-v2/src/superio/winbond/w83627uhg/superio.c
   trunk/coreboot-v2/src/superio/winbond/w83627uhg/w83627uhg.h
   trunk/coreboot-v2/src/superio/winbond/w83627uhg/w83627uhg_early_serial.c
Log:
Add support for the Winbond W83627UHG Super I/O.

Signed-off-by: Dan Lykowski <lykowdk at gmail.com>
Acked-by: Uwe Hermann <uwe at hermann-uwe.de>



Added: trunk/coreboot-v2/src/superio/winbond/w83627uhg/Config.lb
===================================================================
--- trunk/coreboot-v2/src/superio/winbond/w83627uhg/Config.lb	                        (rev 0)
+++ trunk/coreboot-v2/src/superio/winbond/w83627uhg/Config.lb	2009-01-06 00:33:30 UTC (rev 3846)
@@ -0,0 +1,22 @@
+##
+## This file is part of the coreboot project.
+##
+## Copyright (C) 2009 Dynon Avionics
+##
+## 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 $
+##
+
+config chip.h
+object superio.o

Added: trunk/coreboot-v2/src/superio/winbond/w83627uhg/chip.h
===================================================================
--- trunk/coreboot-v2/src/superio/winbond/w83627uhg/chip.h	                        (rev 0)
+++ trunk/coreboot-v2/src/superio/winbond/w83627uhg/chip.h	2009-01-06 00:33:30 UTC (rev 3846)
@@ -0,0 +1,29 @@
+/*
+ * This file is part of the coreboot project.
+ *
+ * Copyright (C) 2009 Dynon Avionics
+ *
+ * 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 $
+ */
+
+#include <pc80/keyboard.h>
+#include <uart8250.h>
+
+extern struct chip_operations superio_winbond_w83627uhg_ops;
+
+struct superio_winbond_w83627uhg_config {
+	struct uart8250 com1, com2, com3, com4, com5, com6;
+	struct pc_keyboard keyboard;
+};

Added: trunk/coreboot-v2/src/superio/winbond/w83627uhg/superio.c
===================================================================
--- trunk/coreboot-v2/src/superio/winbond/w83627uhg/superio.c	                        (rev 0)
+++ trunk/coreboot-v2/src/superio/winbond/w83627uhg/superio.c	2009-01-06 00:33:30 UTC (rev 3846)
@@ -0,0 +1,176 @@
+/*
+ * This file is part of the coreboot project.
+ *
+ * Copyright (C) 2009 Dynon Avionics
+ *
+ * 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 $
+ */
+
+#include <arch/io.h>
+#include <device/device.h>
+#include <device/pnp.h>
+#include <console/console.h>
+#include <string.h>
+#include <stdint.h>
+#include <stdlib.h>
+#include <bitops.h>
+#include <uart8250.h>
+#include <pc80/keyboard.h>
+#include "chip.h"
+#include "w83627uhg.h"
+
+static void w83627uhg_enter_ext_func_mode(device_t dev)
+{
+	outb(0x87, dev->path.u.pnp.port);
+	outb(0x87, dev->path.u.pnp.port);
+}
+
+static void w83627uhg_exit_ext_func_mode(device_t dev)
+{
+	outb(0xaa, dev->path.u.pnp.port);
+}
+
+/*
+ * Set the UART clock source.
+ *
+ * Possible UART clock source speeds are:
+ *
+ *   0 = 1.8462 MHz (default)
+ *   1 = 2 MHz
+ *   2 = 24 MHz
+ *   3 = 14.769 MHz
+ *
+ * The faster clocks allow for BAUD rates up to 2mbits.
+ *
+ * Warning: The kernel will need to be adjusted since it assumes
+ * a 1.8462 MHz clock.
+ */
+static void set_uart_clock_source(device_t dev, u8 uart_clock)
+{
+	u8 value;
+
+	w83627uhg_enter_ext_func_mode(dev);
+	pnp_set_logical_device(dev);
+	value = pnp_read_config(dev, 0xf0);
+	value &= ~0x03;
+	value |= (uart_clock & 0x03);
+	pnp_write_config(dev, 0xf0, value);
+	w83627uhg_exit_ext_func_mode(dev);
+}
+
+static void w83627uhg_init(device_t dev)
+{
+	struct superio_winbond_w83627uhg_config *conf;
+	struct resource *res0, *res1;
+
+	if (!dev->enabled)
+		return;
+
+	conf = dev->chip_info;
+	switch(dev->path.u.pnp.device) {
+	case W83627UHG_SP1: 
+		res0 = find_resource(dev, PNP_IDX_IO0);
+		/* set_uart_clock_source(dev, 0); */
+		init_uart8250(res0->base, &conf->com1);
+		break;
+	case W83627UHG_SP2:
+		res0 = find_resource(dev, PNP_IDX_IO0);
+		/* set_uart_clock_source(dev, 0); */
+		init_uart8250(res0->base, &conf->com2);
+		break;
+	case W83627UHG_SP3:
+		res0 = find_resource(dev, PNP_IDX_IO0);
+		/* set_uart_clock_source(dev, 0); */
+		init_uart8250(res0->base, &conf->com3);
+		break;
+	case W83627UHG_SP4:
+		res0 = find_resource(dev, PNP_IDX_IO0);
+		/* set_uart_clock_source(dev, 0); */
+		init_uart8250(res0->base, &conf->com4);
+		break;
+	case W83627UHG_SP5:
+		res0 = find_resource(dev, PNP_IDX_IO0);
+		/* set_uart_clock_source(dev, 0); */
+		init_uart8250(res0->base, &conf->com5);
+		break;
+	case W83627UHG_SP6:
+		res0 = find_resource(dev, PNP_IDX_IO0);
+		/* set_uart_clock_source(dev, 0); */
+		init_uart8250(res0->base, &conf->com6);
+		break;
+	case W83627UHG_KBC:
+		res0 = find_resource(dev, PNP_IDX_IO0);
+		res1 = find_resource(dev, PNP_IDX_IO1);
+		init_pc_keyboard(res0->base, res1->base, &conf->keyboard);
+		break;
+	}
+}
+
+static void w83627uhg_set_resources(device_t dev)
+{
+	w83627uhg_enter_ext_func_mode(dev);
+	pnp_set_resources(dev);
+	w83627uhg_exit_ext_func_mode(dev);
+}
+
+static void w83627uhg_enable_resources(device_t dev)
+{
+	w83627uhg_enter_ext_func_mode(dev);
+	pnp_enable_resources(dev);
+	w83627uhg_exit_ext_func_mode(dev);
+}
+
+static void w83627uhg_enable(device_t dev)
+{
+	w83627uhg_enter_ext_func_mode(dev);
+	pnp_enable(dev);
+	w83627uhg_exit_ext_func_mode(dev);
+}
+
+static struct device_operations ops = {
+	.read_resources   = pnp_read_resources,
+	.set_resources    = w83627uhg_set_resources,
+	.enable_resources = w83627uhg_enable_resources,
+	.enable           = w83627uhg_enable,
+	.init             = w83627uhg_init,
+};
+
+static struct pnp_info pnp_dev_info[] = {
+	{ &ops, W83627UHG_FDC,  PNP_IO0 | PNP_IRQ0 | PNP_DRQ0, { 0x07f8, 0}, },
+	{ &ops, W83627UHG_PP,   PNP_IO0 | PNP_IRQ0 | PNP_DRQ0, { 0x07f8, 0}, },
+	{ &ops, W83627UHG_SP1,  PNP_IO0 | PNP_IRQ0, { 0x7f8, 0 }, },
+	{ &ops, W83627UHG_SP2,  PNP_IO0 | PNP_IRQ0, { 0x7f8, 0 }, },
+	{ &ops, W83627UHG_KBC,  PNP_IO0 | PNP_IO1 | PNP_IRQ0 | PNP_IRQ1, { 0x7ff, 0 }, { 0x7ff, 0x4}, },
+	{ &ops, W83627UHG_SP3,  PNP_IO0 | PNP_IRQ0, { 0x7f8, 0 }, },
+	{ &ops, W83627UHG_GPIO3_4, },
+	{ &ops, W83627UHG_WDTO_PLED_GPIO5_6, },
+	{ &ops, W83627UHG_GPIO1_2,},
+	{ &ops, W83627UHG_ACPI, PNP_IRQ0,  },
+	{ &ops, W83627UHG_HWM,  PNP_IO0 | PNP_IRQ0, { 0xff8, 0 } },
+	{ &ops, W83627UHG_PECI_SST,},
+	{ &ops, W83627UHG_SP4,  PNP_IO0 | PNP_IRQ0, { 0x7f8, 0 }, },
+	{ &ops, W83627UHG_SP5,  PNP_IO0 | PNP_IRQ0, { 0x7f8, 0 }, },
+	{ &ops, W83627UHG_SP6,  PNP_IO0 | PNP_IRQ0, { 0x7f8, 0 }, },
+};
+
+static void enable_dev(device_t dev)
+{
+	pnp_enable_devices(dev, &ops, ARRAY_SIZE(pnp_dev_info), pnp_dev_info);
+}
+
+struct chip_operations superio_winbond_w83627uhg_ops = {
+	CHIP_NAME("Winbond W83627UHG Super I/O")
+	.enable_dev = enable_dev,
+};

Added: trunk/coreboot-v2/src/superio/winbond/w83627uhg/w83627uhg.h
===================================================================
--- trunk/coreboot-v2/src/superio/winbond/w83627uhg/w83627uhg.h	                        (rev 0)
+++ trunk/coreboot-v2/src/superio/winbond/w83627uhg/w83627uhg.h	2009-01-06 00:33:30 UTC (rev 3846)
@@ -0,0 +1,35 @@
+/*
+ * This file is part of the coreboot project.
+ *
+ * Copyright (C) 2009 Dynon Avionics
+ *
+ * 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 $
+ */
+
+#define W83627UHG_FDC			0   /* Floppy */
+#define W83627UHG_PP			1   /* Parallel port */
+#define W83627UHG_SP1			2   /* Com1 */
+#define W83627UHG_SP2			3   /* Com2 */
+#define W83627UHG_KBC			5   /* PS/2 keyboard & mouse */
+#define W83627UHG_SP3			6   /* Com3 */
+#define W83627UHG_GPIO3_4		7   /* GPIO 3/4 */
+#define W83627UHG_WDTO_PLED_GPIO5_6	8   /* WDTO#, PLED, GPIO5/6 */
+#define W83627UHG_GPIO1_2		9   /* GPIO 1/2, SUSLED */
+#define W83627UHG_ACPI			10  /* ACPI */
+#define W83627UHG_HWM			11  /* Hardware monitor */
+#define W83627UHG_PECI_SST		12  /* PECI, SST */
+#define W83627UHG_SP4			13  /* Com4 */
+#define W83627UHG_SP5			14  /* Com5 */
+#define W83627UHG_SP6			15  /* Com6 */

Added: trunk/coreboot-v2/src/superio/winbond/w83627uhg/w83627uhg_early_serial.c
===================================================================
--- trunk/coreboot-v2/src/superio/winbond/w83627uhg/w83627uhg_early_serial.c	                        (rev 0)
+++ trunk/coreboot-v2/src/superio/winbond/w83627uhg/w83627uhg_early_serial.c	2009-01-06 00:33:30 UTC (rev 3846)
@@ -0,0 +1,58 @@
+/*
+ * This file is part of the coreboot project.
+ *
+ * Copyright (C) 2009 Dynon Avionics
+ *
+ * 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/romcc_io.h>
+#include <stdint.h>
+#include "w83627uhg.h"
+
+static void pnp_enter_ext_func_mode(device_t dev)
+{
+	u16 port = dev >> 8;
+	outb(0x87, port);
+	outb(0x87, port);
+}
+
+static void pnp_exit_ext_func_mode(device_t dev)
+{
+	u16 port = dev >> 8;
+	outb(0xaa, port);
+}
+
+/** Set the input clock to 24 or 48 MHz. */
+static void w83627uhg_set_input_clk_sel(device_t dev, u8 speed_24mhz)
+{
+	u8 value;
+
+	value = pnp_read_config(dev, 0x24);
+	value &= ~(1 << 6);
+	if (!speed_24mhz)
+		value |= (1 << 6);
+	pnp_write_config(dev, 0x24, value);
+}
+
+static void w83627uhg_enable_serial(device_t dev, u32 iobase)
+{
+	pnp_enter_ext_func_mode(dev);
+	pnp_set_logical_device(dev);
+	pnp_set_enable(dev, 0);
+	pnp_set_iobase(dev, PNP_IDX_IO0, iobase);
+	pnp_set_enable(dev, 1);
+	pnp_exit_ext_func_mode(dev);
+}




From uwe at hermann-uwe.de  Tue Jan  6 01:56:59 2009
From: uwe at hermann-uwe.de (Uwe Hermann)
Date: Tue, 6 Jan 2009 01:56:59 +0100
Subject: [coreboot] [PATCH] Add support for winbond w83627uhg SuperIO
In-Reply-To: <317372.66111.qm@web57002.mail.re3.yahoo.com>
References: <317372.66111.qm@web57002.mail.re3.yahoo.com>
Message-ID: <20090106005659.GG12484@greenwood>

Hi,

On Mon, Jan 05, 2009 at 01:11:05AM -0800, Dan Lykowski wrote:
> Patch to add support for Winbond w83627uhg SuperIO.
> 
> (This is my first submission. Let me know if I did it wrong.)

You got the most important thing right -- adding the Signed-off-by :)


> Signed-off-by: Dan Lykowski <lykowdk at gmail.com>

Thanks, committed in r3846 with some smaller changes:

 - Make all files (C) 2009 Dynon Avionics only, pretty much all of the
   contents are trivial enough so we don't have to carry around other
   (C) lines. Or there's almost no remaining code from other people
   (e.g. in superio.c), hence we don't need the other (C) lines either.

 - Changed uint8_t to the short form u8, which we're slowly migrating to
   in coreboot v2 and v3.


> +static void w83627uhg_set_input_clk_sel(device_t dev, uint8_t speed_24mhz)
> +{
> +        /* Set the input clock to 24 or 48 mhz. */
> +        uint8_t value;
> +        value = pnp_read_config( dev, 0x24 );
> +        value &= ~(1<<6);
> +        if(!speed_24mhz) {
> +        	value |= (1<<6);
> +   	}

Changed the coding style and indentation a bit in the code, please check

  http://www.coreboot.org/Development_Guidelines#Coding_Style
  http://lxr.linux.no/linux/Documentation/CodingStyle


> Index: src/superio/winbond/w83627uhg/Config.lb
> ===================================================================
> --- src/superio/winbond/w83627uhg/Config.lb	(revision 0)
> +++ src/superio/winbond/w83627uhg/Config.lb	(revision 0)

Added missing license header here (and in another file which didn't
have a header).


> +static void enable_dev(device_t dev)
> +{
> +	pnp_enable_devices(dev, &ops,
> +		sizeof(pnp_dev_info)/sizeof(pnp_dev_info[0]), pnp_dev_info);

I used ARRAY_SIZE here.


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



From uwe at hermann-uwe.de  Tue Jan  6 02:12:30 2009
From: uwe at hermann-uwe.de (Uwe Hermann)
Date: Tue, 6 Jan 2009 02:12:30 +0100
Subject: [coreboot] [PATCH] flashrom: add i631x LPC support
In-Reply-To: <87ljtq7p7b.fsf@apollo.stackframe.org>
References: <87ljtq7p7b.fsf@apollo.stackframe.org>
Message-ID: <20090106011230.GH12484@greenwood>

Hi,

On Sun, Jan 04, 2009 at 10:10:00PM +0100, Sven Schnelle wrote:
> this patch adds support for the Intel i631x Chipset.
> 
> Signed-off-by: Sven Schnelle <svens at stackframe.org>
> 
> Index: chipset_enable.c
> ===================================================================
> --- chipset_enable.c	(revision 3845)
> +++ chipset_enable.c	(working copy)
> @@ -804,6 +804,12 @@
>  	return 0;
>  }
> 
> +static int enable_flash_i631x(struct pci_dev *dev, const char *name)
> +{
> +	pci_write_byte(dev, 0xdc, pci_read_byte(dev, 0xdc) | 0x01);
> +	return 0;
> +}
> +
>  /**
>   * Usually on the x86 architectures (and on other PC-like platforms like some
>   * Alphas or Itanium) the system flash is mapped right below 4G. On the AMD
> @@ -937,4 +943,5 @@
>  	{0x1002, 0x4377, "ATI SB400",		enable_flash_sb400},
>  	{0x1166, 0x0205, "Broadcom HT-1000",	enable_flash_ht1000},
>  	{0x1022, 0x3000, "AMD Elan SC520",	get_flashbase_sc520},
> +	{0x8086, 0x2670, "Intel 631xESB/632xESB/3100",         enable_flash_i631x},

We already have 

        {0x8086, 0x25a1, "Intel 6300ESB",       enable_flash_ich_4e},

Wouldn't enable_flash_ich_dc/enable_flash_ich also work for the
"Intel 631xESB/632xESB/3100" chipset(s)?


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



From marcj303 at gmail.com  Tue Jan  6 02:25:39 2009
From: marcj303 at gmail.com (Marc Jones)
Date: Mon, 5 Jan 2009 18:25:39 -0700
Subject: [coreboot] AMD DBM690T PowerNow table problems
In-Reply-To: <495FE0E5.7020503@assembler.cz>
References: <49583EA2.8080903@gmx.net> <495FE0E5.7020503@assembler.cz>
Message-ID: <534e5dc20901051725l69907601k7d2ccf6817510257@mail.gmail.com>

On Sat, Jan 3, 2009 at 3:04 PM, Rudolf Marek <r.marek at assembler.cz> wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Hi,
>
> Here we go.
>
> Its seems that the generated table has wrong conversion for frequency and its
> FID representation. In other words the table is OK but the first field is not
> consistent with FID and real freq.
>
> invalid freq entries 1000000 kHz vs. 800000
>
> This means that:
>
>
>                Package (0x06)
>                {
>                    0x00000320,. <--- here should be 0x3e8
>                    0x0000F230,.
>                    0x00000064,.
>                    0x00000007,.
>                    0xE8202F0A,.
>                    0x0000030A
>                },.
>
>                Package (0x06)
>                {
>                    0x00000320,.
>                    0x0000BB8C,.
>                    0x00000064,.
>                    0x00000007,.
>                    0xE8202C82,.
>                    0x00000482
>                }
>
>
> FID is 0A and 02 which means it should be: set to 0x3e8 and 0x320.
>
> I guess it is because your CPU is revF and not revG.
>
> fid_multiplier = ((cpuid1.edx & 0x40) >> 6) * 100;
>
> This line will cause that your CPU has fid_multiplier 0 instead of 100x.
> I believe that the multiplier should be always 100. Because revF CPU hav LSB in
> FID always 0.
>
> Rudolf

I agree with this analysis. Patch attached.

Marc
-------------- next part --------------
A non-text attachment was scrubbed...
Name: k8_pss_freq.patch
Type: application/octet-stream
Size: 944 bytes
Desc: not available
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20090105/0a6fb9d0/attachment.obj>

From Zheng.Bao at amd.com  Tue Jan  6 02:36:40 2009
From: Zheng.Bao at amd.com (Bao, Zheng)
Date: Tue, 6 Jan 2009 09:36:40 +0800
Subject: [coreboot] AMD DBM690T PowerNow table problems
In-Reply-To: <534e5dc20901051725l69907601k7d2ccf6817510257@mail.gmail.com>
References: <49583EA2.8080903@gmx.net> <495FE0E5.7020503@assembler.cz>
	<534e5dc20901051725l69907601k7d2ccf6817510257@mail.gmail.com>
Message-ID: <DD1CC71B621B004FA76856E5129D6B17024A0045@sbjgexmb1.amd.com>

If fid_multiplier is 0, it doesn't seem to have any sense. So I agree.

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 Marc Jones
Sent: Tuesday, January 06, 2009 9:26 AM
To: Rudolf Marek; Bao, Zheng
Cc: Carl-Daniel Hailfinger; Coreboot
Subject: Re: [coreboot] AMD DBM690T PowerNow table problems

On Sat, Jan 3, 2009 at 3:04 PM, Rudolf Marek <r.marek at assembler.cz>
wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Hi,
>
> Here we go.
>
> Its seems that the generated table has wrong conversion for frequency
and its
> FID representation. In other words the table is OK but the first field
is not
> consistent with FID and real freq.
>
> invalid freq entries 1000000 kHz vs. 800000
>
> This means that:
>
>
>                Package (0x06)
>                {
>                    0x00000320,. <--- here should be 0x3e8
>                    0x0000F230,.
>                    0x00000064,.
>                    0x00000007,.
>                    0xE8202F0A,.
>                    0x0000030A
>                },.
>
>                Package (0x06)
>                {
>                    0x00000320,.
>                    0x0000BB8C,.
>                    0x00000064,.
>                    0x00000007,.
>                    0xE8202C82,.
>                    0x00000482
>                }
>
>
> FID is 0A and 02 which means it should be: set to 0x3e8 and 0x320.
>
> I guess it is because your CPU is revF and not revG.
>
> fid_multiplier = ((cpuid1.edx & 0x40) >> 6) * 100;
>
> This line will cause that your CPU has fid_multiplier 0 instead of
100x.
> I believe that the multiplier should be always 100. Because revF CPU
hav LSB in
> FID always 0.
>
> Rudolf

I agree with this analysis. Patch attached.

Marc




From svens at stackframe.org  Tue Jan  6 09:31:21 2009
From: svens at stackframe.org (Sven Schnelle)
Date: Tue, 06 Jan 2009 09:31:21 +0100
Subject: [coreboot] [PATCH] flashrom: add SST49LF020 support
In-Reply-To: <20090105232701.GD12484@greenwood> (Uwe Hermann's message of
	"Tue\, 6 Jan 2009 00\:27\:01 +0100")
References: <877i5ahon6.fsf@apollo.stackframe.org>
	<20090105232701.GD12484@greenwood>
Message-ID: <87ljtoj0o6.fsf@apollo.stackframe.org>

Uwe Hermann <uwe at hermann-uwe.de> writes:

>> i've added support for the SST 49LF020 Flash chip to flashrom. Basically
>> only the device Id differs, the programming algorithm seems to be the
>> same as for SST 49LF020A.
>> 
>> I've only tested read so far, i'm a bit reluctant to test
>> erase/programming without a backup BIOS chip :)
>
> You forgot the Signed-off-by for this patch, please repost with that.
> [..]
> As reading works, this is not UNSTESTED. At least PROBE and READ
> should be marked as working.

Thanks for commenting, here is the updated patch:

Signed-off-by: Sven Schnelle <svens at stackframe.org>

Index: coreboot-v2/util/flashrom/flash.h
===================================================================
--- coreboot-v2/util/flashrom/flash.h	(revision 3846)
+++ coreboot-v2/util/flashrom/flash.h	(working copy)
@@ -356,6 +356,7 @@
 #define SST_39VF040		0xD7
 #define SST_49LF040B		0x50
 #define SST_49LF040		0x51
+#define SST_49LF020		0x61
 #define SST_49LF020A		0x52
 #define SST_49LF080A		0x5B
 #define SST_49LF002A		0x57
Index: coreboot-v2/util/flashrom/flashchips.c
===================================================================
--- coreboot-v2/util/flashrom/flashchips.c	(revision 3846)
+++ coreboot-v2/util/flashrom/flashchips.c	(working copy)
@@ -626,6 +626,12 @@
 	 probe_49lfxxxc, erase_49lfxxxc, write_49lfxxxc
 	},
 
+	{"SST", "SST49LF020", SST_ID, SST_49LF020,
+	 256, 16 * 1024,
+	 TEST_OK_PR,
+	 probe_jedec, erase_49lf040, write_49lf040
+	},
+
 	{"SST", "SST49LF020A", SST_ID, SST_49LF020A,
 	 256, 16 * 1024,
 	 TEST_UNTESTED,



From svens at stackframe.org  Tue Jan  6 09:37:42 2009
From: svens at stackframe.org (Sven Schnelle)
Date: Tue, 06 Jan 2009 09:37:42 +0100
Subject: [coreboot] [PATCH] flashrom: add i631x LPC support
In-Reply-To: <20090106011230.GH12484@greenwood> (Uwe Hermann's message of
	"Tue\, 6 Jan 2009 02\:12\:30 +0100")
References: <87ljtq7p7b.fsf@apollo.stackframe.org>
	<20090106011230.GH12484@greenwood>
Message-ID: <87eizgj0dl.fsf@apollo.stackframe.org>


>> Index: chipset_enable.c
>> ===================================================================
>> --- chipset_enable.c	(revision 3845)
>> +++ chipset_enable.c	(working copy)
>> @@ -804,6 +804,12 @@
>>  	return 0;
>>  }
>> 
>> +static int enable_flash_i631x(struct pci_dev *dev, const char *name)
>> +{
>> +	pci_write_byte(dev, 0xdc, pci_read_byte(dev, 0xdc) | 0x01);
>> +	return 0;
>> +}
>> +
>>  /**
>>   * Usually on the x86 architectures (and on other PC-like platforms like some
>>   * Alphas or Itanium) the system flash is mapped right below 4G. On the AMD
>> @@ -937,4 +943,5 @@
>>  	{0x1002, 0x4377, "ATI SB400",		enable_flash_sb400},
>>  	{0x1166, 0x0205, "Broadcom HT-1000",	enable_flash_ht1000},
>>  	{0x1022, 0x3000, "AMD Elan SC520",	get_flashbase_sc520},
>> +	{0x8086, 0x2670, "Intel 631xESB/632xESB/3100",         enable_flash_i631x},
>
> We already have 
>
>         {0x8086, 0x25a1, "Intel 6300ESB",       enable_flash_ich_4e},
>
> Wouldn't enable_flash_ich_dc/enable_flash_ich also work for the
> "Intel 631xESB/632xESB/3100" chipset(s)?

Indeed. I should read the source before patching it. :)

Signed-off-by: Sven Schnelle <svens at stackframe.org>

Index: coreboot-v2/util/flashrom/chipset_enable.c
===================================================================
--- coreboot-v2/util/flashrom/chipset_enable.c	(revision 3845)
+++ coreboot-v2/util/flashrom/chipset_enable.c	(working copy)
@@ -880,6 +880,7 @@
 	{0x8086, 0x24cc, "Intel ICH4-M",	enable_flash_ich_4e},
 	{0x8086, 0x24d0, "Intel ICH5/ICH5R",	enable_flash_ich_4e},
 	{0x8086, 0x25a1, "Intel 6300ESB",	enable_flash_ich_4e},
+	{0x8086, 0x2670, "Intel 631xESB/632xESB/3100",    enable_flash_ich_dc},
 	{0x8086, 0x2640, "Intel ICH6/ICH6R",	enable_flash_ich_dc},
 	{0x8086, 0x2641, "Intel ICH6-M",	enable_flash_ich_dc},
 	{0x8086, 0x5031, "Intel EP80579",	enable_flash_ich7},



From svens at stackframe.org  Tue Jan  6 09:43:27 2009
From: svens at stackframe.org (Sven Schnelle)
Date: Tue, 06 Jan 2009 09:43:27 +0100
Subject: [coreboot] [PATCH] flashrom: add AMD-768 chipset support
In-Reply-To: <20090106001141.542.qmail@stuge.se> (Peter Stuge's message of
	"Tue\, 6 Jan 2009 01\:11\:41 +0100")
References: <871vvihog9.fsf@apollo.stackframe.org>
	<20090106001141.542.qmail@stuge.se>
Message-ID: <878wpoj040.fsf@apollo.stackframe.org>

Peter Stuge <peter at stuge.se> writes:

> Sven Schnelle wrote:
>> the patch attached adds support for the AMD-768 chipset.
> ..
>
>> +static int enable_flash_amd768(struct pci_dev *dev, const char *name)
>> +{
>> +	/* enable address decoding for LPC */
>> +	pci_write_byte(dev, 0x40, pci_read_byte(dev, 0x40) | 0x01);
>> +	pci_write_byte(dev, 0x43, 0xbf);
>> +
>> +	return 0;
>> +}
>
> Does this chipset supporty anything else than LPC?

Don't think so, at least the documentation only mentions LPC as BIOS
interface. Nevertheless i've recognized that the algorithm is the same
as for the AMD8111, so let's just add the PCI Ids.

Signed-off-by: Sven Schnelle <svens at stackframe.org>

Index: coreboot-v2/util/flashrom/chipset_enable.c
===================================================================
--- coreboot-v2/util/flashrom/chipset_enable.c	(revision 3846)
+++ coreboot-v2/util/flashrom/chipset_enable.c	(working copy)
@@ -937,6 +937,7 @@
 	{0x1002, 0x4377, "ATI SB400",		enable_flash_sb400},
 	{0x1166, 0x0205, "Broadcom HT-1000",	enable_flash_ht1000},
 	{0x1022, 0x3000, "AMD Elan SC520",	get_flashbase_sc520},
+	{0x1022, 0x7440, "AMD AMD-768",         enable_flash_amd8111},
 };
 
 void print_supported_chipsets(void)



From mart.raudsepp at artecdesign.ee  Tue Jan  6 10:35:47 2009
From: mart.raudsepp at artecdesign.ee (Mart Raudsepp)
Date: Tue, 06 Jan 2009 11:35:47 +0200
Subject: [coreboot] [PATCH] There's a pciconf.h with PCI conf constants
 - lets actually use it
In-Reply-To: <20090105233800.24547.qmail@stuge.se>
References: <1231166997.20385.3.camel@martr-gentoo.artec>
	<20090105232412.GC12484@greenwood>
	<20090105233800.24547.qmail@stuge.se>
Message-ID: <1231234547.4627.5.camel@martr-gentoo.artec>

?hel kenal p?eval, T, 2009-01-06 kell 00:38, kirjutas Peter Stuge:
> Uwe Hermann wrote:
> > > There's a pciconf.h with PCI conf constants - lets actually use it
> > > 
> > > PCI_CONF_REG_{INDEX,DATA} constants instead of 0xCF8 and 0xCFF everywhere.
> > > Not touching YABEL as I'm not sure it would want to include that header.
> > > 
> > > Signed-off-by: Mart Raudsepp <mart.raudsepp at artecdesign.ee>
> > 
> > Acked-by: Uwe Hermann <uwe at hermann-uwe.de>
> 
> Please don't commit this. I would rather see the 0xcf8 and cfc
> defines removed. This is PCI code, these ports will never change
> for PCI buses, and they are the first thing most learn about PCI
> programming.
> 
> Defines add indirection = complexity = error sources. I'm with
> Stefan, we should use them carefully.

Hence the sentence "In case it's a good idea to use these constants from
that header" in my mail :)

I simply noticed the fact that there are constant defined, and that the
same thing is used per value. Lets perhaps fix the inconsistency another
way then. Proposed patch attached.


Mart Raudsepp

From mart.raudsepp at artecdesign.ee  Tue Jan  6 10:32:38 2009
From: mart.raudsepp at artecdesign.ee (Mart Raudsepp)
Date: Tue, 6 Jan 2009 11:32:38 +0200
Subject: [PATCH] Remove unused pciconf.h header with constants that everyone uses by value instead per convention
Message-ID: <mailman.2638.1355071467.16123.coreboot@coreboot.org>

Signed-off-by: Mart Raudsepp <mart.raudsepp at artecdesign.ee>
---
 arch/x86/pci_ops_auto.c    |    1 -
 arch/x86/pci_ops_conf1.c   |    1 -
 arch/x86/pci_ops_mmconf.c  |    1 -
 device/pci_ops.c           |    1 -
 include/arch/x86/pciconf.h |   13 -------------
 5 files changed, 0 insertions(+), 17 deletions(-)
 delete mode 100644 include/arch/x86/pciconf.h

diff --git a/arch/x86/pci_ops_auto.c b/arch/x86/pci_ops_auto.c
index 33634bc..d5fbe43 100644
--- a/arch/x86/pci_ops_auto.c
+++ b/arch/x86/pci_ops_auto.c
@@ -1,6 +1,5 @@
 #include <console.h>
 #include <device/device.h>
-#include <pciconf.h>
 #include <device/pci.h>
 #include <device/pci_ids.h>
 #include <device/pci_ops.h>
diff --git a/arch/x86/pci_ops_conf1.c b/arch/x86/pci_ops_conf1.c
index a9a7fea..83b06ea 100644
--- a/arch/x86/pci_ops_conf1.c
+++ b/arch/x86/pci_ops_conf1.c
@@ -1,6 +1,5 @@
 #include <console.h>
 #include <device/device.h>
-#include <pciconf.h>
 #include <device/pci.h>
 #include <device/pci_ids.h>
 #include <device/pci_ops.h>
diff --git a/arch/x86/pci_ops_mmconf.c b/arch/x86/pci_ops_mmconf.c
index e09692c..358e2d2 100644
--- a/arch/x86/pci_ops_mmconf.c
+++ b/arch/x86/pci_ops_mmconf.c
@@ -1,6 +1,5 @@
 #include <console.h>
 #include <device/device.h>
-#include <pciconf.h>
 #include <device/pci.h>
 #include <device/pci_ids.h>
 #include <device/pci_ops.h>
diff --git a/device/pci_ops.c b/device/pci_ops.c
index 411f927..2109701 100644
--- a/device/pci_ops.c
+++ b/device/pci_ops.c
@@ -20,7 +20,6 @@
 
 #include <console.h>
 #include <device/device.h>
-#include <pciconf.h>
 #include <device/pci.h>
 #include <device/pci_ids.h>
 #include <device/pci_ops.h>
diff --git a/include/arch/x86/pciconf.h b/include/arch/x86/pciconf.h
deleted file mode 100644
index 265dac7..0000000
--- a/include/arch/x86/pciconf.h
+++ /dev/null
@@ -1,13 +0,0 @@
-#ifndef ARCH_X86_PCICONF_H
-#define ARCH_X86_PCICONF_H
-
-#ifndef PCI_CONF_REG_INDEX
-
-// These are defined in the PCI spec, and hence are theoretically
-// inclusive of ANYTHING that uses a PCI bus. 
-#define	PCI_CONF_REG_INDEX	0xcf8
-#define	PCI_CONF_REG_DATA	0xcfc
-
-#endif
-
-#endif /* ARCH_X86_PCICONF_H */
-- 
1.6.0.4


--=-mWTd8bPtC2f8DzkRinE5--




From corey.osgood at gmail.com  Tue Jan  6 11:59:55 2009
From: corey.osgood at gmail.com (Corey Osgood)
Date: Tue, 6 Jan 2009 05:59:55 -0500
Subject: [coreboot] v3 stage2 running from flash
In-Reply-To: <dd3c80060812240325j65b0461av68169dbb3819c405@mail.gmail.com>
References: <dd3c80060812232040g1023a815sc0e678e8fe62e1cd@mail.gmail.com>
	<dd3c80060812232113j70c98431j1bd07d583a3b73c0@mail.gmail.com>
	<dd3c80060812232202g1497d040pa17e326027b023a9@mail.gmail.com>
	<13426df10812232346i6c839b8en92c8c16d0a0e7223@mail.gmail.com>
	<4951EB24.8090502@gmx.net>
	<13426df10812240002w1223d9b6o7c05d8aef1638e77@mail.gmail.com>
	<dd3c80060812240014q723ac1d1w5df2a4be5b15d9db@mail.gmail.com>
	<13426df10812240209g7615fbbl9870365664488f1@mail.gmail.com>
	<dd3c80060812240220j13f26289q7b01320797fa5fb8@mail.gmail.com>
	<dd3c80060812240325j65b0461av68169dbb3819c405@mail.gmail.com>
Message-ID: <dd3c80060901060259r1af9949eo7b5a0aa7fb303b38@mail.gmail.com>

On Wed, Dec 24, 2008 at 6:25 AM, Corey Osgood <corey.osgood at gmail.com>wrote:

> On Wed, Dec 24, 2008 at 5:20 AM, Corey Osgood <corey.osgood at gmail.com>wrote:
>
>> On Wed, Dec 24, 2008 at 5:09 AM, ron minnich <rminnich at gmail.com> wrote:
>>
>>> On Wed, Dec 24, 2008 at 12:14 AM, Corey Osgood <corey.osgood at gmail.com>
>>> wrote:
>>>
>>> > *phew* I was worried that was how v3 was always going to run. As for
>>> those
>>> > times Ron, stage0 takes <1 second, initram is ~5 seconds,
>>>
>>> the initram seems way too long. But that stage 2 tells me you have
>>> some real problems with your dram setup.
>>
>>
>> It could have been less, timing output from a serial port with a stopwatch
>> isn't very exact. I don't think there's anything wrong with the dram setup,
>> I ran memtest86 overnight without any errors.
>>
>> I know nothing about this part. I wonder if you could dump your mtrr
>>> settings and let us see them.
>>
>>
>> Sure, what point do you want them from? End of stage1?
>>
>
> Here's a boot log that dumps them right after serial comes up, again just
> before disable_car(), and once more before loading stage2. After that mtrrs
> aren't touched until stage 2 phase 6 AFAIK. I wish I knew more about this
> stuff, I should probably make some time to read those Intel x86 programming
> guides.
>

Alright, it was ridiculously simple. I added #defines for XIP_ROM_SIZE/BASE
in stage0.S like core2 has, and now it boots MUCH MUCH faster, until it gets
into phase6_init and does the MTRR init that I brought in from v2, after
that it slows back down. I'll send a patch to set that properly and to fix
it in core2 (currently hardcoded to a 1MB rom) soonish. Is the proper
solution to the MTRR problem to teach that mtrr_init() not to mess up the
caching MTRR, to set the caching back up after init, or just to not bother
with the late init?

Thanks,
Corey
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20090106/0e796926/attachment.html>

From corey.osgood at gmail.com  Tue Jan  6 12:49:36 2009
From: corey.osgood at gmail.com (Corey Osgood)
Date: Tue, 6 Jan 2009 06:49:36 -0500
Subject: [coreboot] [PATCH] [v3] Fix hardcoded rom cache size on core2
Message-ID: <dd3c80060901060349p75322fd1w238a7b3aea29c871@mail.gmail.com>

Patch attached, only build tested.

-Corey
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20090106/b7f4dd17/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: core2_rom_cache_size.diff
Type: text/x-diff
Size: 1413 bytes
Desc: not available
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20090106/b7f4dd17/attachment.bin>

From corey.osgood at gmail.com  Tue Jan  6 12:52:00 2009
From: corey.osgood at gmail.com (Corey Osgood)
Date: Tue, 6 Jan 2009 06:52:00 -0500
Subject: [coreboot] [PATCH] [v3] Fix ROM caching on Via C7
Message-ID: <dd3c80060901060352p219b2216j119fae5001ff08cc@mail.gmail.com>

Tested and working on hardware :D

-Corey
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20090106/86f79eba/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: c7_enable_caching.diff
Type: text/x-diff
Size: 2623 bytes
Desc: not available
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20090106/86f79eba/attachment.bin>

From mylesgw at gmail.com  Tue Jan  6 15:39:29 2009
From: mylesgw at gmail.com (Myles Watson)
Date: Tue, 6 Jan 2009 07:39:29 -0700
Subject: [coreboot] [PATCH] [v3] Fix ROM caching on Via C7
In-Reply-To: <dd3c80060901060352p219b2216j119fae5001ff08cc@mail.gmail.com>
References: <dd3c80060901060352p219b2216j119fae5001ff08cc@mail.gmail.com>
Message-ID: <2831fecf0901060639s5d60ddedn2bfc626fde4f356@mail.gmail.com>

On Tue, Jan 6, 2009 at 4:52 AM, Corey Osgood <corey.osgood at gmail.com> wrote:
> Tested and working on hardware :D

Great job!

As I read your patch I wondered if there's a good reason to disable
caching.  Can we just take out the #ifdefs?  Or maybe make it an
#ifndef DONT_CACHE_AND_RUN_REAL_SLOW_ON_C7? :)

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

Thanks,
Myles



From mart.raudsepp at artecdesign.ee  Tue Jan  6 16:09:32 2009
From: mart.raudsepp at artecdesign.ee (Mart Raudsepp)
Date: Tue, 06 Jan 2009 17:09:32 +0200
Subject: [coreboot] [PATCH] Update PCI dev_root struct definition generation
 explanation comment to v3 reality
Message-ID: <1231254572.4627.12.camel@martr-gentoo.artec>

Update PCI dev_root struct definition generation explanation comment to v3 reality

v3 uses dtc to create $(obj)/mainboard/$(MAINBOARDDIR)/statictree.c not the config.py tool as in v2.

Signed-off-by: Mart Raudsepp <mart.raudsepp at artecdesign.ee>
---
 device/root_device.c |    3 ++-
 1 files changed, 2 insertions(+), 1 deletions(-)

diff --git a/device/root_device.c b/device/root_device.c
index 8d809bc..34b74d3 100644
--- a/device/root_device.c
+++ b/device/root_device.c
@@ -200,6 +200,7 @@ struct device_operations default_dev_ops_root = {
  * The root of device tree.
  *
  * This is the root of the device tree. The device tree is defined in the
- * static.c file and is generated by config tool during compile time.
+ * build/mainboard/<board>/statictree.c file and is generated by the dtc util
+ * during build time.
  */
 extern struct device dev_root;
-- 
1.6.0.4




From mylesgw at gmail.com  Tue Jan  6 16:38:50 2009
From: mylesgw at gmail.com (Myles Watson)
Date: Tue, 6 Jan 2009 08:38:50 -0700
Subject: [coreboot] v3 Tyan s2892
In-Reply-To: <20090105230710.17810.qmail@stuge.se>
References: <2831fecf0901051115l154c9ebdo258c718ad095b067@mail.gmail.com>
	<20090105230710.17810.qmail@stuge.se>
Message-ID: <2831fecf0901060738sa9f2b8u9132f5a4782d4423@mail.gmail.com>

On Mon, Jan 5, 2009 at 4:07 PM, Peter Stuge <peter at stuge.se> wrote:
> Myles Watson wrote:
>> This patch adds initial support for mainboard/tyan/s2892.  It
>> compiles, but is untested in hardware.
>
> I think this needs a little polishing.

> Does Kconfig allow choices to span multiple files? If so it would be
> nice to not have to repeat the Mainboard model choice for each
> vendor.

I don't know how to do that.  It would affect all vendors currently in
v3, not just the one I'm adding, though.

>> +++ svn/mainboard/tyan/s2892/stage1.c
> ..
>> +void ck804_enable_rom(void);
>
> This prototype shouldn't be needed here right?

It won't compile without it.  It's possible that the sources could be
rearranged so that it doesn't need to be there.

> What ROM is it anyway?

The flashROM where coreboot is stored.  Sorry I'm not sure of the
correct terminology there.

>
>> +#define SERIAL_DEV W83627HF_SP1
>> +#define SERIAL_IOBASE 0x3f8
>
> Isn't at least the iobase in a CONFIG_ already?
No.  It's in the dts only, which isn't available yet.

>> +void mainboard_pre_payload(void)
>> +{
>> +     banner(BIOS_DEBUG, "mainboard_pre_payload: done");
>> +}
>
> Can we remove this function from mainboard sources when it doesn't do
> anything like here?

This function is only used for geode right now, but in geode it's used
to disable caching of the ROM.  I think that's up in the air right
now.

>
>> +++ svn/mainboard/tyan/s2892/initram.c
> ..
>> +/* this code is very mainboard dependent, sadly. */
> ..
>> +/**
>> + * read a byte from spd.
>> + * @param device device to read from
>> + * @param address address in the spd ROM
>> + * @return the value of the byte at that address.
>> + */
>> +u8 spd_read_byte(u16 device, u8 address)
>> +{
>> +     int smbus_read_byte(u16 device, u16 address);
>> +     return smbus_read_byte(device, address);
>> +}
>
> I hope you see the irony above.
Yes.  I was hoping to unify the code when we had two (maybe three)
working k8 boards in v3.  I still haven't figured out v2's execution
path.  cache_as_ram_auto.c vs. auto.c vs. ...

I'd love help here.

>> +
>> +/**
>> +  * main for initram for the AMD Serengeti
>
> No, this is for s2892. If this code is copypaste, it can not go in.
> I would like us to reuse more.

Me too.  See above.

Thanks again,
Myles



From mylesgw at gmail.com  Tue Jan  6 16:41:34 2009
From: mylesgw at gmail.com (Myles Watson)
Date: Tue, 6 Jan 2009 08:41:34 -0700
Subject: [coreboot] [PATCH] Update PCI dev_root struct definition
	generation explanation comment to v3 reality
In-Reply-To: <1231254572.4627.12.camel@martr-gentoo.artec>
References: <1231254572.4627.12.camel@martr-gentoo.artec>
Message-ID: <2831fecf0901060741n41275f34r76571a81358ef46d@mail.gmail.com>

On Tue, Jan 6, 2009 at 8:09 AM, Mart Raudsepp
<mart.raudsepp at artecdesign.ee> wrote:
> Update PCI dev_root struct definition generation explanation comment to v3 reality
>
> v3 uses dtc to create $(obj)/mainboard/$(MAINBOARDDIR)/statictree.c not the config.py tool as in v2.
>
> Signed-off-by: Mart Raudsepp <mart.raudsepp at artecdesign.ee>
> ---
>  device/root_device.c |    3 ++-
>  1 files changed, 2 insertions(+), 1 deletions(-)
>
> diff --git a/device/root_device.c b/device/root_device.c
> index 8d809bc..34b74d3 100644
> --- a/device/root_device.c
> +++ b/device/root_device.c
> @@ -200,6 +200,7 @@ struct device_operations default_dev_ops_root = {
>  * The root of device tree.
>  *
>  * This is the root of the device tree. The device tree is defined in the
> - * static.c file and is generated by config tool during compile time.
> + * build/mainboard/<board>/statictree.c file and is generated by the dtc util
> + * during build time.
Maybe we should mention mainboard/<vendor>/<board>/dts here.

Thanks,
Myles



From paulepanter at users.sourceforge.net  Tue Jan  6 17:11:44 2009
From: paulepanter at users.sourceforge.net (Paul Menzel)
Date: Tue, 06 Jan 2009 17:11:44 +0100
Subject: [coreboot] [PATCH] Update PCI dev_root struct
	definition	generation explanation comment to v3 reality
In-Reply-To: <1231254572.4627.12.camel@martr-gentoo.artec>
References: <1231254572.4627.12.camel@martr-gentoo.artec>
Message-ID: <1231258304.4069.3.camel@mattotaupa.wohnung.familie-menzel.net>

Dear Mart,


Am Dienstag, den 06.01.2009, 17:09 +0200 schrieb Mart Raudsepp:
> Update PCI dev_root struct definition generation explanation comment to v3 reality
> 
> v3 uses dtc to create $(obj)/mainboard/$(MAINBOARDDIR)/statictree.c not the config.py tool as in v2.
> 
> Signed-off-by: Mart Raudsepp <mart.raudsepp at artecdesign.ee>
> ---
>  device/root_device.c |    3 ++-
>  1 files changed, 2 insertions(+), 1 deletions(-)
> 
> diff --git a/device/root_device.c b/device/root_device.c
> index 8d809bc..34b74d3 100644
> --- a/device/root_device.c
> +++ b/device/root_device.c
> @@ -200,6 +200,7 @@ struct device_operations default_dev_ops_root = {
>   * The root of device tree.
>   *
>   * This is the root of the device tree. The device tree is defined in the
> - * static.c file and is generated by config tool during compile time.
> + * build/mainboard/<board>/statictree.c file and is generated by the dtc util

s/util/utility/ (I would prefer that.)

> + * during build time.
>   */
>  extern struct device dev_root;


Thanks,

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

From marcj303 at gmail.com  Tue Jan  6 17:31:18 2009
From: marcj303 at gmail.com (Marc Jones)
Date: Tue, 6 Jan 2009 09:31:18 -0700
Subject: [coreboot] [PATCH] [v3] Fix ROM caching on Via C7
In-Reply-To: <2831fecf0901060639s5d60ddedn2bfc626fde4f356@mail.gmail.com>
References: <dd3c80060901060352p219b2216j119fae5001ff08cc@mail.gmail.com>
	<2831fecf0901060639s5d60ddedn2bfc626fde4f356@mail.gmail.com>
Message-ID: <534e5dc20901060831y8cfd12we6bc9c804aaf3aea@mail.gmail.com>

On Tue, Jan 6, 2009 at 7:39 AM, Myles Watson <mylesgw at gmail.com> wrote:
> On Tue, Jan 6, 2009 at 4:52 AM, Corey Osgood <corey.osgood at gmail.com> wrote:
>> Tested and working on hardware :D
>
> Great job!
>
> As I read your patch I wondered if there's a good reason to disable
> caching.  Can we just take out the #ifdefs?  Or maybe make it an
> #ifndef DONT_CACHE_AND_RUN_REAL_SLOW_ON_C7? :)
>
> Acked-by: Myles Watson <mylesgw at gmail.com>
>
> Thanks,
> Myles

I think that we need to examine this for all the CPUs. In a legacy
BIOS all the runtime code will be in memory, so caching the ROM is
only need prior to memory setup. That is not the case for coreboot
because we have the XIP printk and LAR code. We should use one MTRR
for caching the ROM. So MTRR for ROM caching is setup by the CPU
specific CAR code and then later in normal MTRR setup we add an MTRR
that will support XIP for the rest of POST and payload loading. There
are two minor drawbacks to doing this.

1. You use an MTRR that could be used by the OS. No big deal, there
are more than enough MTRRs for every confguration I can think of.

2. You might use cache space for ROM code that will fetch slowly and
might only run once. This is no longer a problem with large L2 and L3
caches. Even on Geode it should be ok. Also, the ROM shouldn't be
accessed once the OS loads.

The last thing is if the ROM should be cached read-only or
write-through. If set RO, flashrom will need to be MTRR aware and set
it to WT when writing ROMs.

Marc



From svn at coreboot.org  Tue Jan  6 17:45:42 2009
From: svn at coreboot.org (svn at coreboot.org)
Date: Tue,  6 Jan 2009 17:45:42 +0100
Subject: [coreboot] r3847 - in trunk/coreboot-v2/src/mainboard/amd: dbm690t
	pistachio
Message-ID: <mailman.2639.1355071467.16123.coreboot@coreboot.org>

Author: mjones
Date: 2009-01-06 17:45:42 +0100 (Tue, 06 Jan 2009)
New Revision: 3847

Modified:
   trunk/coreboot-v2/src/mainboard/amd/dbm690t/acpi_tables.c
   trunk/coreboot-v2/src/mainboard/amd/pistachio/acpi_tables.c
Log:
The ACPI PSS CPU Pstate table was calculating the frequency incorrectly for
revF CPUs. The 100MHz/200MHz stepping is already handled in the FID setting
and doesn't need to be checked to set the fid_multiplier. The multiplier is
always 100.

Signed-off-by: Marc Jones <marcj303 at gmail.com>
Acked-by: zheng bao <zheng.bao at amd.com>

Modified: trunk/coreboot-v2/src/mainboard/amd/dbm690t/acpi_tables.c
===================================================================
--- trunk/coreboot-v2/src/mainboard/amd/dbm690t/acpi_tables.c	2009-01-06 00:33:30 UTC (rev 3846)
+++ trunk/coreboot-v2/src/mainboard/amd/dbm690t/acpi_tables.c	2009-01-06 16:45:42 UTC (rev 3847)
@@ -258,12 +258,11 @@
 		return 0;
 	}
 
-	/*get the multipier of the fid frequency */
+	/* Get the multipier of the fid frequency */
 	/*
-	 * In RevG, 100MHz step is added
+	 * Fid multiplier is always 100 revF and revG.
 	 */
-	cpuid1 = cpuid(0x80000007);
-	fid_multiplier = ((cpuid1.edx & 0x40) >> 6) * 100;
+	fid_multiplier = 100;
 
 	/*
 	 * Formula1:    CPUFreq = FID * fid_multiplier + 800

Modified: trunk/coreboot-v2/src/mainboard/amd/pistachio/acpi_tables.c
===================================================================
--- trunk/coreboot-v2/src/mainboard/amd/pistachio/acpi_tables.c	2009-01-06 00:33:30 UTC (rev 3846)
+++ trunk/coreboot-v2/src/mainboard/amd/pistachio/acpi_tables.c	2009-01-06 16:45:42 UTC (rev 3847)
@@ -258,12 +258,11 @@
 		return 0;
 	}
 
-	/*get the multipier of the fid frequency */
+	/* Get the multipier of the fid frequency */
 	/*
-	 * In RevG, 100MHz step is added
+	 * Fid multiplier is always 100 revF and revG.
 	 */
-	cpuid1 = cpuid(0x80000007);
-	fid_multiplier = ((cpuid1.edx & 0x40) >> 6) * 100;
+	fid_multiplier = 100;
 
 	/*
 	 * Formula1:    CPUFreq = FID * fid_multiplier + 800




From marcj303 at gmail.com  Tue Jan  6 17:47:00 2009
From: marcj303 at gmail.com (Marc Jones)
Date: Tue, 6 Jan 2009 09:47:00 -0700
Subject: [coreboot] AMD DBM690T PowerNow table problems
In-Reply-To: <DD1CC71B621B004FA76856E5129D6B17024A0045@sbjgexmb1.amd.com>
References: <49583EA2.8080903@gmx.net> <495FE0E5.7020503@assembler.cz>
	<534e5dc20901051725l69907601k7d2ccf6817510257@mail.gmail.com>
	<DD1CC71B621B004FA76856E5129D6B17024A0045@sbjgexmb1.amd.com>
Message-ID: <534e5dc20901060847j6c19053av20fe3845ca3df3b5@mail.gmail.com>

On Mon, Jan 5, 2009 at 6:36 PM, Bao, Zheng <Zheng.Bao at amd.com> wrote:
> If fid_multiplier is 0, it doesn't seem to have any sense. So I agree.
>
> Acked-by: zheng bao <zheng.bao at amd.com>
>

I also fixed this in acpi_tables.c Pistachio.

r 3847

Marc



From rminnich at gmail.com  Tue Jan  6 17:55:51 2009
From: rminnich at gmail.com (ron minnich)
Date: Tue, 6 Jan 2009 08:55:51 -0800
Subject: [coreboot] v3 stage2 running from flash
In-Reply-To: <dd3c80060901060259r1af9949eo7b5a0aa7fb303b38@mail.gmail.com>
References: <dd3c80060812232040g1023a815sc0e678e8fe62e1cd@mail.gmail.com>
	<dd3c80060812232202g1497d040pa17e326027b023a9@mail.gmail.com>
	<13426df10812232346i6c839b8en92c8c16d0a0e7223@mail.gmail.com>
	<4951EB24.8090502@gmx.net>
	<13426df10812240002w1223d9b6o7c05d8aef1638e77@mail.gmail.com>
	<dd3c80060812240014q723ac1d1w5df2a4be5b15d9db@mail.gmail.com>
	<13426df10812240209g7615fbbl9870365664488f1@mail.gmail.com>
	<dd3c80060812240220j13f26289q7b01320797fa5fb8@mail.gmail.com>
	<dd3c80060812240325j65b0461av68169dbb3819c405@mail.gmail.com>
	<dd3c80060901060259r1af9949eo7b5a0aa7fb303b38@mail.gmail.com>
Message-ID: <13426df10901060855l2192139t369b0f548d450d8f@mail.gmail.com>

On Tue, Jan 6, 2009 at 2:59 AM, Corey Osgood <corey.osgood at gmail.com> wrote:
> it was ridiculously simple. I added #defines for XIP_ROM_SIZE/BASE
> in stage0.S like core2 has, and now it boots MUCH MUCH faster, until it gets
> into phase6_init and does the MTRR init that I brought in from v2, after
> that it slows back down. I'll send a patch to set that properly and to fix
> it in core2 (currently hardcoded to a 1MB rom) soonish. Is the proper
> solution to the MTRR problem to teach that mtrr_init() not to mess up the
> caching MTRR, to set the caching back up after init, or just to not bother
> with the late init?

I think we need to get this right, but you could try skipping the late
init to see what happens.

I expect it will slow down once linux starts.

ron



From c-d.hailfinger.devel.2006 at gmx.net  Tue Jan  6 20:47:37 2009
From: c-d.hailfinger.devel.2006 at gmx.net (Carl-Daniel Hailfinger)
Date: Tue, 06 Jan 2009 20:47:37 +0100
Subject: [coreboot] v3 stage2 running from flash
In-Reply-To: <13426df10901060855l2192139t369b0f548d450d8f@mail.gmail.com>
References: <dd3c80060812232040g1023a815sc0e678e8fe62e1cd@mail.gmail.com>	
	<dd3c80060812232202g1497d040pa17e326027b023a9@mail.gmail.com>	
	<13426df10812232346i6c839b8en92c8c16d0a0e7223@mail.gmail.com>	
	<4951EB24.8090502@gmx.net>	
	<13426df10812240002w1223d9b6o7c05d8aef1638e77@mail.gmail.com>	
	<dd3c80060812240014q723ac1d1w5df2a4be5b15d9db@mail.gmail.com>	
	<13426df10812240209g7615fbbl9870365664488f1@mail.gmail.com>	
	<dd3c80060812240220j13f26289q7b01320797fa5fb8@mail.gmail.com>	
	<dd3c80060812240325j65b0461av68169dbb3819c405@mail.gmail.com>	
	<dd3c80060901060259r1af9949eo7b5a0aa7fb303b38@mail.gmail.com>
	<13426df10901060855l2192139t369b0f548d450d8f@mail.gmail.com>
Message-ID: <4963B559.1000504@gmx.net>

On 06.01.2009 17:55, ron minnich wrote:
> On Tue, Jan 6, 2009 at 2:59 AM, Corey Osgood <corey.osgood at gmail.com> wrote:
>   
>> it was ridiculously simple. I added #defines for XIP_ROM_SIZE/BASE
>> in stage0.S like core2 has, and now it boots MUCH MUCH faster, until it gets
>> into phase6_init and does the MTRR init that I brought in from v2, after
>> that it slows back down. I'll send a patch to set that properly and to fix
>> it in core2 (currently hardcoded to a 1MB rom) soonish. Is the proper
>> solution to the MTRR problem to teach that mtrr_init() not to mess up the
>> caching MTRR, to set the caching back up after init, or just to not bother
>> with the late init?
>>     
>
> I think we need to get this right, but you could try skipping the late
> init to see what happens.
>
> I expect it will slow down once linux starts.
>   

The situation is a bit complicated.
As long as CAR is active, we don't want the cacheable area (CAR+ROM) to
be bigger than the cache to prevent cache evictions of CAR contents.
That means we can cache the boot block and maybe initram. In that
situation, having initram directly before the boot block is a huge speed
benefit.
Once CAR is no longer active, we immediately want to mark the whole ROM
and RAM as cacheable to speed up decompression.

Regards,
Carl-Daniel

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




From marcj303 at gmail.com  Tue Jan  6 22:46:50 2009
From: marcj303 at gmail.com (Marc Jones)
Date: Tue, 6 Jan 2009 14:46:50 -0700
Subject: [coreboot] domain vs device statictree order
Message-ID: <534e5dc20901061346g5eb604c5kf63a80f5634a1128@mail.gmail.com>

Myles,

Should the domain functions run before the device functions? It looks
like the device functions run before the domain but I would expect it
to be the other way. This is a problem for Geode LX. It has the VSA
and graphics memory init in the domain phase2_fixup but it is running
after the 5536 devices run phase2_fixup and is a problem.


statictree: http://pastebin.ca/1301081
.next = &dev_domain_0 -  is the link from the last pci device in the
domain to the domain device.

serial output: http://pastebin.ca/1301072

Marc



From mylesgw at gmail.com  Tue Jan  6 22:56:46 2009
From: mylesgw at gmail.com (Myles Watson)
Date: Tue, 6 Jan 2009 14:56:46 -0700
Subject: [coreboot] domain vs device statictree order
In-Reply-To: <534e5dc20901061346g5eb604c5kf63a80f5634a1128@mail.gmail.com>
References: <534e5dc20901061346g5eb604c5kf63a80f5634a1128@mail.gmail.com>
Message-ID: <F893D0B3C6794D4BA36DE9DDC72625D3@chimp>

> Myles,
> 
> Should the domain functions run before the device functions?
Yes.

> It looks
> like the device functions run before the domain but I would expect it
> to be the other way.

Me too.

> This is a problem for Geode LX. It has the VSA
> and graphics memory init in the domain phase2_fixup but it is running
> after the 5536 devices run phase2_fixup and is a problem.

Sorry it broke.  Since I don't have the hardware I can't test very well.  I
had a patch that moved those functions, but I broke something else and
re-simplified.  I'll send you a patch, and maybe together we can do it
right.

> 
> statictree: http://pastebin.ca/1301081
> .next = &dev_domain_0 -  is the link from the last pci device in the
> domain to the domain device.

Yeah.  That seems like the "root" of the problem.  Because of the way the
statictree is made, anything done in device order ends up being depth-first.
You have to specify to make things breadth first, which seems like the
correct way.

> serial output: http://pastebin.ca/1301072

Thanks,
Myles




From mylesgw at gmail.com  Tue Jan  6 23:37:27 2009
From: mylesgw at gmail.com (Myles Watson)
Date: Tue, 6 Jan 2009 15:37:27 -0700
Subject: [coreboot] domain vs device statictree order
In-Reply-To: <F893D0B3C6794D4BA36DE9DDC72625D3@chimp>
References: <534e5dc20901061346g5eb604c5kf63a80f5634a1128@mail.gmail.com>
	<F893D0B3C6794D4BA36DE9DDC72625D3@chimp>
Message-ID: <2831fecf0901061437k3367b4fbgbf237c66a5af87ff@mail.gmail.com>

Marc,

Hopefully this makes everything right again.  I still think some of
the geode functions should be moved, but that's really a separate
issue.

> You have to specify to make things breadth first, which seems like the
> correct way.

I guess it's not really breadth first.  It's just parents before siblings.

I think this should be done for all the phases unless there's some
compelling reason not to.

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

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

From marcj303 at gmail.com  Wed Jan  7 00:13:06 2009
From: marcj303 at gmail.com (Marc Jones)
Date: Tue, 6 Jan 2009 16:13:06 -0700
Subject: [coreboot] domain vs device statictree order
In-Reply-To: <2831fecf0901061437k3367b4fbgbf237c66a5af87ff@mail.gmail.com>
References: <534e5dc20901061346g5eb604c5kf63a80f5634a1128@mail.gmail.com>
	<F893D0B3C6794D4BA36DE9DDC72625D3@chimp>
	<2831fecf0901061437k3367b4fbgbf237c66a5af87ff@mail.gmail.com>
Message-ID: <534e5dc20901061513l3b63756mf0a102cddc33ecc0@mail.gmail.com>

On Tue, Jan 6, 2009 at 3:37 PM, Myles Watson <mylesgw at gmail.com> wrote:
> Marc,
>
> Hopefully this makes everything right again.  I still think some of
> the geode functions should be moved, but that's really a separate
> issue.
>
>> You have to specify to make things breadth first, which seems like the
>> correct way.
>
> I guess it's not really breadth first.  It's just parents before siblings.
>
> I think this should be done for all the phases unless there's some
> compelling reason not to.
>
> Signed-off-by: Myles Watson <mylesgw at gmail.com>

I agree it is parents before siblings but I thought it looked more
like a problem with the statictree. I must not understand .next.

from http://pastebin.ca/1301081

dev_apic_0 has a .sibling = &dev_domain_0 and .next = &dev_domain_0_pci_1_0

Then later in the last device domain dev_domain_0_pci_f_2 has a .next
= &dev_domain_0.

I would expect .sibling and .next to point to the &dev_domain_0 and
then dev_domain_0 to have .next = &dev_domain_0_pci_1_0

dev_cpus looks like I would expect .sibling = &dev_apic_0 and .next =
&dev_apic_0.
dev_domain_0_pci_f_0 also has the same .sibling and .next.

Can you explain the last pci dev .next pointing back to the domain?

I am not setup to test this either. I was talking with Mart on NAND
device problems. Maybe he can test it tomorrow.

Marc



From mylesgw at gmail.com  Wed Jan  7 00:19:06 2009
From: mylesgw at gmail.com (Myles Watson)
Date: Tue, 6 Jan 2009 16:19:06 -0700
Subject: [coreboot] domain vs device statictree order
In-Reply-To: <534e5dc20901061513l3b63756mf0a102cddc33ecc0@mail.gmail.com>
References: <534e5dc20901061346g5eb604c5kf63a80f5634a1128@mail.gmail.com>
	<F893D0B3C6794D4BA36DE9DDC72625D3@chimp>
	<2831fecf0901061437k3367b4fbgbf237c66a5af87ff@mail.gmail.com>
	<534e5dc20901061513l3b63756mf0a102cddc33ecc0@mail.gmail.com>
Message-ID: <2831fecf0901061519i873cdf5ua5110832479f1679@mail.gmail.com>

On Tue, Jan 6, 2009 at 4:13 PM, Marc Jones <marcj303 at gmail.com> wrote:

> I agree it is parents before siblings but I thought it looked more
> like a problem with the statictree. I must not understand .next.
>
> from http://pastebin.ca/1301081
>
> dev_apic_0 has a .sibling = &dev_domain_0 and .next = &dev_domain_0_pci_1_0
>
> Then later in the last device domain dev_domain_0_pci_f_2 has a .next
> = &dev_domain_0.
>
> I would expect .sibling and .next to point to the &dev_domain_0 and
> then dev_domain_0 to have .next = &dev_domain_0_pci_1_0

Yes.  I would too.  It's that way because parents get defined after
children.  When the tree is being read, the full parent is not read
(we don't get to the closing brace) until after we read all the
children.  It seems confusing to me, but it is the way dts works.

> dev_cpus looks like I would expect .sibling = &dev_apic_0 and .next =
> &dev_apic_0.
> dev_domain_0_pci_f_0 also has the same .sibling and .next.

Yes.  Children are complete before their sibling is read in, so all
devices with childless siblings have the same .sibling and .next.

I hope that doesn't sound like blather :)

Thanks,
Myles



From mylesgw at gmail.com  Wed Jan  7 00:29:07 2009
From: mylesgw at gmail.com (Myles Watson)
Date: Tue, 6 Jan 2009 16:29:07 -0700
Subject: [coreboot] domain vs device statictree order
In-Reply-To: <2831fecf0901061519i873cdf5ua5110832479f1679@mail.gmail.com>
References: <534e5dc20901061346g5eb604c5kf63a80f5634a1128@mail.gmail.com>
	<F893D0B3C6794D4BA36DE9DDC72625D3@chimp>
	<2831fecf0901061437k3367b4fbgbf237c66a5af87ff@mail.gmail.com>
	<534e5dc20901061513l3b63756mf0a102cddc33ecc0@mail.gmail.com>
	<2831fecf0901061519i873cdf5ua5110832479f1679@mail.gmail.com>
Message-ID: <2831fecf0901061529p539d4e80s2bcb8c15abdf06a6@mail.gmail.com>

Here's the rest of the geodelx fixup patch too.  I think this is more
intuitive, but again I don't have the hardware.

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

Thanks,
Myles
-------------- next part --------------
A non-text attachment was scrubbed...
Name: geodelx.diff
Type: text/x-patch
Size: 7917 bytes
Desc: not available
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20090106/13eaf623/attachment.diff>

From peter at stuge.se  Wed Jan  7 00:51:57 2009
From: peter at stuge.se (Peter Stuge)
Date: Wed, 7 Jan 2009 00:51:57 +0100
Subject: [coreboot] Fwd: [RFC] Here we go... the SLOF biosemu
	forcoreboot-v3
In-Reply-To: <b5765cdf0812160514h474d03d6o4fa5f41b0b8595d5@mail.gmail.com>
References: <b5765cdf0812131105w7fa1aea8vc6057b64720d8c41@mail.gmail.com>
	<49440FF6.4010102@coresystems.de>
	<b5765cdf0812131243g19e87f7fl4944f905945da164@mail.gmail.com>
	<2831fecf0812131318v6342777cs4f78f54115c91640@mail.gmail.com>
	<b5765cdf0812131339l32b6f180gd138fe4b26a03d6f@mail.gmail.com>
	<20081215014832.15094.qmail@stuge.se>
	<8EA485427B6E4C578D25D1D9DF8780E9@chimp>
	<b5765cdf0812150930pd897bf4p1b5a771785ab293f@mail.gmail.com>
	<20081215182855.16628.qmail@stuge.se>
	<b5765cdf0812160514h474d03d6o4fa5f41b0b8595d5@mail.gmail.com>
Message-ID: <20090106235157.10599.qmail@stuge.se>

Hi, I found what seems to be a bug in the current yabel/biosemu.c.
You seem to have addressed it in a patch already, though..


Pattrick Hueper wrote:
..
> +u32
> +biosemu(u8 *biosmem, u32 biosmem_size, struct device * dev)
> +{
..
> +	// setup default Interrupt Vectors
> +	// some expansion ROMs seem to check for these addresses..
> +	// each handler is only an IRET (0xCF) instruction
> +	// ROM BIOS Int 10 Handler F000:F065
> +	my_wrl(0x10 * 4, 0xf000f065);
> +	my_wrb(0x000ff065, 0xcf);

Has this gotten some feedback? The fix is correct!


//Peter



From mart.raudsepp at artecdesign.ee  Wed Jan  7 00:58:46 2009
From: mart.raudsepp at artecdesign.ee (Mart Raudsepp)
Date: Wed, 07 Jan 2009 01:58:46 +0200
Subject: [coreboot] domain vs device statictree order
In-Reply-To: <2831fecf0901061519i873cdf5ua5110832479f1679@mail.gmail.com>
References: <534e5dc20901061346g5eb604c5kf63a80f5634a1128@mail.gmail.com>
	<F893D0B3C6794D4BA36DE9DDC72625D3@chimp>
	<2831fecf0901061437k3367b4fbgbf237c66a5af87ff@mail.gmail.com>
	<534e5dc20901061513l3b63756mf0a102cddc33ecc0@mail.gmail.com>
	<2831fecf0901061519i873cdf5ua5110832479f1679@mail.gmail.com>
Message-ID: <1231286326.2405.4.camel@phoenix.lan>

On T, 2009-01-06 at 16:19 -0700, Myles Watson wrote:
> On Tue, Jan 6, 2009 at 4:13 PM, Marc Jones <marcj303 at gmail.com> wrote:
> 
> > I agree it is parents before siblings but I thought it looked more
> > like a problem with the statictree. I must not understand .next.
> >
> > from http://pastebin.ca/1301081
> >
> > dev_apic_0 has a .sibling = &dev_domain_0 and .next = &dev_domain_0_pci_1_0
> >
> > Then later in the last device domain dev_domain_0_pci_f_2 has a .next
> > = &dev_domain_0.
> >
> > I would expect .sibling and .next to point to the &dev_domain_0 and
> > then dev_domain_0 to have .next = &dev_domain_0_pci_1_0
> 
> Yes.  I would too.  It's that way because parents get defined after
> children.  When the tree is being read, the full parent is not read
> (we don't get to the closing brace) until after we read all the
> children.

It seems the order code-wise is the expected one. Domain structure
definitions appear before its devices, and so on, just the next pointers
jump to the end for one of them in the pastebin example. Couldn't
the .next pointers simply be pointing to the entry that is going to be
printed out next as far as domain/device go?

"The rest of the geodelx fixup patch" looks quite invasive to me. Not
regarding quality, but to my own local changes I had done :)
Will take some digesting from the start to get things understood, merged
with other changes and working order for me. But tomorrow is clean-up
and submission time anyways. I will be adding a Flash device and juggle
around some code to be done in appropriate phases for the interaction
with VSA to be working as far as NAND Flash goes.


Mart Raudsepp




From c-d.hailfinger.devel.2006 at gmx.net  Wed Jan  7 02:11:43 2009
From: c-d.hailfinger.devel.2006 at gmx.net (Carl-Daniel Hailfinger)
Date: Wed, 07 Jan 2009 02:11:43 +0100
Subject: [coreboot] [PATCH] flashrom: Update man page
In-Reply-To: <20090105230413.GB12484@greenwood>
References: <496166A3.2040705@gmx.net> <20090105230413.GB12484@greenwood>
Message-ID: <4964014F.5090205@gmx.net>

On 06.01.2009 00:04, Uwe Hermann wrote:
> On Mon, Jan 05, 2009 at 02:47:15AM +0100, Carl-Daniel Hailfinger wrote:
>   
>> The flashrom man page has incomplete author/copyright sections and an
>> incorrect license section.
>> - Remove the copyright listings and refer the reader to the source files.
>>     
>
> ACK, this is a pita to keep up-to-date in many places (README, manpage,
> wiki, source, whatever). The only authoritative place for (C) lines is
> (and should be) the source code.
>
>
>   
>> - Update the author list to those which have copyright messages in the
>> source files.
>> - Correct the license from GPL v2+ to GPL v2.
>>     
>
> That's not quite correct / complete. I'd use a text such as this:
>
> Flashrom is licensed under the terms of the GNU General Public License (GPL).
> Some files are licensed under the "GPL (version 2, or any later version)",
> and some files are licensed under the "GPL, version 2".
>
>
>   
>> Signed-off-by: Carl-Daniel Hailfinger <c-d.hailfinger.devel.2006 at gmx.net>
>>
>> Index: flashrom-manpage/flashrom.8
>> ===================================================================
>> --- flashrom-manpage/flashrom.8	(Revision 3811)
>> +++ flashrom-manpage/flashrom.8	(Arbeitskopie)
>> @@ -1,4 +1,4 @@
>> -.TH FLASHROM 8 "June 22, 2008"
>> +.TH FLASHROM 8 "January 5, 2009"
>>  .SH NAME
>>  flashrom \- a universal BIOS/ROM/flash programming utility
>>  .SH SYNOPSIS
>> @@ -84,22 +84,51 @@
>>  .RB "(" http://coreboot.org/Mailinglist ")."
>>  .SH LICENCE
>>  .B flashrom
>> -is covered by the GNU General Public License (GPL), version 2 or later.
>> +is covered by the GNU General Public License (GPL), version 2.
>>  .SH COPYRIGHT
>> -2000 Silicon Integrated System Corporation
>>  .br
>> -2003 Niki W. Waibel
>> -.br
>> -2004 Tyan Corp
>> -.br
>> -2005-2007 coresystems GmbH
>> +Please see the individual files.
>>  .SH AUTHORS
>>  Yinghai Lu <yinghai.lu at amd.com>
>>  .br
>>  Stefan Reinauer <stepan at coresystems.de>
>>  .br
>> -Niki W. Waibel <niki.waibel at gmx.net>
>> +Ronald G. Minnich <rminnich at gmail.com>
>>  .br
>> +Steven James <pyro at linuxlabs.com>
>> +.br
>> +Giampiero Giancipoli <gianci at email.it>
>> +.br
>> +Uwe Hermann <uwe at hermann-uwe.de>
>> +.br
>>     
>
>   
>> +2008 Carl-Daniel Hailfinger
>>     
>
> Drop this...
>   

Done.

>> +.br
>> +Luc Verhaegen <libv at skynet.be>
>> +.br
>> +Carl-Daniel Hailfinger
>>     
>
> ... as this line is also there.
>
>
> Also, are the entries in some order? Maybe sort alphabetically? This is
> what we do in superiotool, I think.
>   

Done.

Thanks for the review!

Regards,
Carl-Daniel

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

Index: flashrom-manpage/flashrom.8
===================================================================
--- flashrom-manpage/flashrom.8	(Revision 3847)
+++ flashrom-manpage/flashrom.8	(Arbeitskopie)
@@ -1,4 +1,4 @@
-.TH FLASHROM 8 "June 22, 2008"
+.TH FLASHROM 8 "January 5, 2009"
 .SH NAME
 flashrom \- a universal BIOS/ROM/flash programming utility
 .SH SYNOPSIS
@@ -84,22 +84,50 @@
 .RB "(" http://coreboot.org/Mailinglist ")."
 .SH LICENCE
 .B flashrom
-is covered by the GNU General Public License (GPL), version 2 or later.
+is covered by the GNU General Public License (GPL), version 2. Some files are
+additionally available under the GPL (version 2, or any later version).
 .SH COPYRIGHT
-2000 Silicon Integrated System Corporation
 .br
-2003 Niki W. Waibel
+Please see the individual files.
+.SH AUTHORS
+Carl-Daniel Hailfinger
 .br
-2004 Tyan Corp
+Claus Gindhart <claus.gindhart at kontron.com>
 .br
-2005-2007 coresystems GmbH
-.SH AUTHORS
-Yinghai Lu <yinghai.lu at amd.com>
+Dominik Geyer <dominik.geyer at kontron.com>
 .br
+Eric Biederman <ebiederman at lnxi.com>
+.br
+Giampiero Giancipoli <gianci at email.it>
+.br
+Joe Bao <Zheng.Bao at amd.com>
+.br
+Luc Verhaegen <libv at skynet.be>
+.br
+Markus Boas <ryven at ryven.de>
+.br
+Nikolay Petukhov <nikolay.petukhov at gmail.com>
+.br
+Peter Stuge <peter at stuge.se>
+.br
+Reinder E.N. de Haan <lb_reha at mveas.com>
+.br
+Ronald G. Minnich <rminnich at gmail.com>
+.br
+Ronald Hoogenboom <ronald at zonnet.nl>
+.br
 Stefan Reinauer <stepan at coresystems.de>
 .br
-Niki W. Waibel <niki.waibel at gmx.net>
+Stefan Wildemann <stefan.wildemann at kontron.com>
 .br
+Steven James <pyro at linuxlabs.com>
+.br
+Uwe Hermann <uwe at hermann-uwe.de>
+.br
+Wang Qingpei <Qingpei.Wang at amd.com>
+.br
+Yinghai Lu <yinghai.lu at amd.com>
+.br
 some others 
 .PP
 This manual page was written by Uwe Hermann <uwe at hermann-uwe.de>.


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




From rminnich at gmail.com  Wed Jan  7 06:45:49 2009
From: rminnich at gmail.com (ron minnich)
Date: Tue, 6 Jan 2009 21:45:49 -0800
Subject: [coreboot] v3 stage2 running from flash
In-Reply-To: <4963B559.1000504@gmx.net>
References: <dd3c80060812232040g1023a815sc0e678e8fe62e1cd@mail.gmail.com>
	<4951EB24.8090502@gmx.net>
	<13426df10812240002w1223d9b6o7c05d8aef1638e77@mail.gmail.com>
	<dd3c80060812240014q723ac1d1w5df2a4be5b15d9db@mail.gmail.com>
	<13426df10812240209g7615fbbl9870365664488f1@mail.gmail.com>
	<dd3c80060812240220j13f26289q7b01320797fa5fb8@mail.gmail.com>
	<dd3c80060812240325j65b0461av68169dbb3819c405@mail.gmail.com>
	<dd3c80060901060259r1af9949eo7b5a0aa7fb303b38@mail.gmail.com>
	<13426df10901060855l2192139t369b0f548d450d8f@mail.gmail.com>
	<4963B559.1000504@gmx.net>
Message-ID: <13426df10901062145p44400dd0rcc0a2a0bf738da72@mail.gmail.com>

On Tue, Jan 6, 2009 at 11:47 AM, Carl-Daniel Hailfinger
<c-d.hailfinger.devel.2006 at gmx.net> wrote:

> As long as CAR is active, we don't want the cacheable area (CAR+ROM) to
> be bigger than the cache to prevent cache evictions of CAR contents.
> That means we can cache the boot block and maybe initram. In that
> situation, having initram directly before the boot block is a huge speed
> benefit.
> Once CAR is no longer active, we immediately want to mark the whole ROM
> and RAM as cacheable to speed up decompression.

Yes. And you want to have those MTRRs in a state that they'll be
correct even if the OS you boot doesn't touch them.

One logical place is at the end of initram. I'd like to get the
discussion to some agreement on where this code should be, and then we
can worry about writing the code. Maybe I am missing part of the
discussion but we seem to be going in circles at times :-)

As for the CAR+ROM area caching, no argument; what I think we're
saying is we may need the ability to control where a LAR file ends up
in ROM so we can limit the cacheable area. Does that make sense?

ron



From corey.osgood at gmail.com  Wed Jan  7 07:35:18 2009
From: corey.osgood at gmail.com (Corey Osgood)
Date: Wed, 7 Jan 2009 01:35:18 -0500
Subject: [coreboot] v3 stage2 running from flash
In-Reply-To: <13426df10901062145p44400dd0rcc0a2a0bf738da72@mail.gmail.com>
References: <dd3c80060812232040g1023a815sc0e678e8fe62e1cd@mail.gmail.com>
	<13426df10812240002w1223d9b6o7c05d8aef1638e77@mail.gmail.com>
	<dd3c80060812240014q723ac1d1w5df2a4be5b15d9db@mail.gmail.com>
	<13426df10812240209g7615fbbl9870365664488f1@mail.gmail.com>
	<dd3c80060812240220j13f26289q7b01320797fa5fb8@mail.gmail.com>
	<dd3c80060812240325j65b0461av68169dbb3819c405@mail.gmail.com>
	<dd3c80060901060259r1af9949eo7b5a0aa7fb303b38@mail.gmail.com>
	<13426df10901060855l2192139t369b0f548d450d8f@mail.gmail.com>
	<4963B559.1000504@gmx.net>
	<13426df10901062145p44400dd0rcc0a2a0bf738da72@mail.gmail.com>
Message-ID: <dd3c80060901062235j3f42b009j81104589d074bb1@mail.gmail.com>

On Wed, Jan 7, 2009 at 12:45 AM, ron minnich <rminnich at gmail.com> wrote:

> On Tue, Jan 6, 2009 at 11:47 AM, Carl-Daniel Hailfinger
> <c-d.hailfinger.devel.2006 at gmx.net> wrote:
>
> > As long as CAR is active, we don't want the cacheable area (CAR+ROM) to
> > be bigger than the cache to prevent cache evictions of CAR contents.
>

Ah, that explains the reboots I'm seeing if the lar isn't zero-filled.


>
> > That means we can cache the boot block and maybe initram. In that
> > situation, having initram directly before the boot block is a huge speed
> > benefit.
> > Once CAR is no longer active, we immediately want to mark the whole ROM
> > and RAM as cacheable to speed up decompression.
>
> Yes. And you want to have those MTRRs in a state that they'll be
> correct even if the OS you boot doesn't touch them.
>
> One logical place is at the end of initram. I'd like to get the
> discussion to some agreement on where this code should be, and then we
> can worry about writing the code. Maybe I am missing part of the
> discussion but we seem to be going in circles at times :-)


Probably my fault, I've just been skimming through the list the last couple
months while I was in class, and I head back next week, so I'd like to get
this running before then ;) Although the end of initram makes sense (I was
going to tuck it into disable_car()), if we only mark the first couple MB of
ram and all of ROM as cachable there (some safe value that every system
should have and coreboot will always fit inside) and then mark all of it
later when we add the ram resources, we eliminate the need for
chipset-specific code to tell coreboot the ram size twice. Does that make
sense, or will it just complicate things more?

As for the CAR+ROM area caching, no argument; what I think we're
> saying is we may need the ability to control where a LAR file ends up
> in ROM so we can limit the cacheable area. Does that make sense?


Perfect sense.

Thanks,
Corey
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20090107/e3c551f7/attachment.html>

From phueper at hueper.net  Wed Jan  7 09:49:57 2009
From: phueper at hueper.net (Pattrick Hueper)
Date: Wed, 7 Jan 2009 09:49:57 +0100
Subject: [coreboot] Fwd: [RFC] Here we go... the SLOF biosemu
	forcoreboot-v3
In-Reply-To: <20090106235157.10599.qmail@stuge.se>
References: <b5765cdf0812131105w7fa1aea8vc6057b64720d8c41@mail.gmail.com>
	<b5765cdf0812131243g19e87f7fl4944f905945da164@mail.gmail.com>
	<2831fecf0812131318v6342777cs4f78f54115c91640@mail.gmail.com>
	<b5765cdf0812131339l32b6f180gd138fe4b26a03d6f@mail.gmail.com>
	<20081215014832.15094.qmail@stuge.se>
	<8EA485427B6E4C578D25D1D9DF8780E9@chimp>
	<b5765cdf0812150930pd897bf4p1b5a771785ab293f@mail.gmail.com>
	<20081215182855.16628.qmail@stuge.se>
	<b5765cdf0812160514h474d03d6o4fa5f41b0b8595d5@mail.gmail.com>
	<20090106235157.10599.qmail@stuge.se>
Message-ID: <b5765cdf0901070049s2329579cqc0c0bafcd54bfe74@mail.gmail.com>

Hi,

On Wed, Jan 7, 2009 at 12:51 AM, Peter Stuge <peter at stuge.se> wrote:
> Hi, I found what seems to be a bug in the current yabel/biosemu.c.
> You seem to have addressed it in a patch already, though..
>
>
> Pattrick Hueper wrote:
> ..
>> +u32
>> +biosemu(u8 *biosmem, u32 biosmem_size, struct device * dev)
>> +{
> ..
>> +     // setup default Interrupt Vectors
>> +     // some expansion ROMs seem to check for these addresses..
>> +     // each handler is only an IRET (0xCF) instruction
>> +     // ROM BIOS Int 10 Handler F000:F065
>> +     my_wrl(0x10 * 4, 0xf000f065);
>> +     my_wrb(0x000ff065, 0xcf);
>
> Has this gotten some feedback? The fix is correct!
>

This code is currently in svn, isnt it? It should be correct, all it
does is let the INT10 int handler point to F000:F065 (the default
location) and the code at that location is 0xCF (IRET).

Patty



From phueper at hueper.net  Wed Jan  7 10:07:32 2009
From: phueper at hueper.net (Pattrick Hueper)
Date: Wed, 7 Jan 2009 10:07:32 +0100
Subject: [coreboot] [PATCH] YABEL: add license to pmm files
In-Reply-To: <20090106000742.GF12484@greenwood>
References: <b5765cdf0901050424s36a049c5q5c4d17d33079fee9@mail.gmail.com>
	<20090106000742.GF12484@greenwood>
Message-ID: <b5765cdf0901070107i6f49554ax841233c93c77ebe8@mail.gmail.com>

Hi,

here is the patch adding the BSD license header to the two files Uwe
mentioned. (yabel/compat/time.h and yabel/compat/functions.c)
I did get svn commit rights, so i will check this patch in myself,
since this is trivial, i will self-ack, i hope that is ok.

Patty

Signed-off-by: Pattrick Hueper <phueper at hueper.net>
Acked-by: Pattrick Hueper <phueper at hueper.net>
---
 util/x86emu/yabel/compat/functions.c |   10 ++++++++++
 util/x86emu/yabel/compat/time.h      |   10 ++++++++++
 2 files changed, 20 insertions(+), 0 deletions(-)

diff --git a/util/x86emu/yabel/compat/functions.c
b/util/x86emu/yabel/compat/functions.c
index c788594..64e9d40 100644
--- a/util/x86emu/yabel/compat/functions.c
+++ b/util/x86emu/yabel/compat/functions.c
@@ -1,3 +1,13 @@
+/****************************************************************************
+ * YABEL BIOS Emulator
+ *
+ * This program and the accompanying materials
+ * are made available under the terms of the BSD License
+ * which accompanies this distribution, and is available at
+ * http://www.opensource.org/licenses/bsd-license.php
+ *
+ * Copyright 2008 Pattrick Hueper <phueper at hueper.net>
+ ****************************************************************************/

 /* this file contains functions provided by SLOF, that the current
biosemu implementation needs
  * they should go away  inthe future...
diff --git a/util/x86emu/yabel/compat/time.h b/util/x86emu/yabel/compat/time.h
index 1e2342e..b0c63c7 100644
--- a/util/x86emu/yabel/compat/time.h
+++ b/util/x86emu/yabel/compat/time.h
@@ -1,3 +1,13 @@
+/****************************************************************************
+ * YABEL BIOS Emulator
+ *
+ * This program and the accompanying materials
+ * are made available under the terms of the BSD License
+ * which accompanies this distribution, and is available at
+ * http://www.opensource.org/licenses/bsd-license.php
+ *
+ * Copyright 2008 Pattrick Hueper <phueper at hueper.net>
+ ****************************************************************************/

 #ifndef _BIOSEMU_COMPAT_TIME_H
 #define _BIOSEMU_COMPAT_TIME_H
-- 
1.6.0.4



On Tue, Jan 6, 2009 at 1:07 AM, Uwe Hermann <uwe at hermann-uwe.de> wrote:
> On Mon, Jan 05, 2009 at 01:24:43PM +0100, Pattrick Hueper wrote:
>> Hi,
>>
>> i just saw, that i forgot to add a BSD license header to the PMM
>> files, this patch fixes that.
>>
>> Patty
>>
>>  Signed-off-by: Pattrick Hueper <phueper at hueper.net>
>
> Thanks, r1101.
>
> Please also add the proper license headers to
>
>  util/x86emu/yabel/compat/functions.c
>  util/x86emu/yabel/compat/time.h
>
>
> Thanks, Uwe.
> --
> http://www.hermann-uwe.de  | http://www.holsham-traders.de
> http://www.crazy-hacks.org | http://www.unmaintained-free-software.org
>



From svn at coreboot.org  Wed Jan  7 10:14:03 2009
From: svn at coreboot.org (svn at coreboot.org)
Date: Wed,  7 Jan 2009 10:14:03 +0100
Subject: [coreboot] r1102 - coreboot-v3/util/x86emu/yabel/compat
Message-ID: <mailman.2640.1355071467.16123.coreboot@coreboot.org>

Author: phueper
Date: 2009-01-07 10:14:03 +0100 (Wed, 07 Jan 2009)
New Revision: 1102

Modified:
   coreboot-v3/util/x86emu/yabel/compat/functions.c
   coreboot-v3/util/x86emu/yabel/compat/time.h
Log:
YABEL: (trivial) add BSD license header to files missing a license header

Signed-off-by: Pattrick Hueper <phueper at hueper.net>
Acked-by: Pattrick Hueper <phueper at hueper.net>


Modified: coreboot-v3/util/x86emu/yabel/compat/functions.c
===================================================================
--- coreboot-v3/util/x86emu/yabel/compat/functions.c	2009-01-06 00:05:45 UTC (rev 1101)
+++ coreboot-v3/util/x86emu/yabel/compat/functions.c	2009-01-07 09:14:03 UTC (rev 1102)
@@ -1,3 +1,13 @@
+/****************************************************************************
+ * YABEL BIOS Emulator
+ *
+ * This program and the accompanying materials
+ * are made available under the terms of the BSD License
+ * which accompanies this distribution, and is available at
+ * http://www.opensource.org/licenses/bsd-license.php
+ *
+ * Copyright 2008 Pattrick Hueper <phueper at hueper.net>
+ ****************************************************************************/
 
 /* this file contains functions provided by SLOF, that the current biosemu implementation needs
  * they should go away  inthe future...

Modified: coreboot-v3/util/x86emu/yabel/compat/time.h
===================================================================
--- coreboot-v3/util/x86emu/yabel/compat/time.h	2009-01-06 00:05:45 UTC (rev 1101)
+++ coreboot-v3/util/x86emu/yabel/compat/time.h	2009-01-07 09:14:03 UTC (rev 1102)
@@ -1,3 +1,13 @@
+/****************************************************************************
+ * YABEL BIOS Emulator
+ *
+ * This program and the accompanying materials
+ * are made available under the terms of the BSD License
+ * which accompanies this distribution, and is available at
+ * http://www.opensource.org/licenses/bsd-license.php
+ *
+ * Copyright 2008 Pattrick Hueper <phueper at hueper.net>
+ ****************************************************************************/
 
 #ifndef _BIOSEMU_COMPAT_TIME_H
 #define _BIOSEMU_COMPAT_TIME_H




From mart.raudsepp at artecdesign.ee  Wed Jan  7 10:25:36 2009
From: mart.raudsepp at artecdesign.ee (Mart Raudsepp)
Date: Wed, 07 Jan 2009 11:25:36 +0200
Subject: [coreboot] domain vs device statictree order
In-Reply-To: <2831fecf0901061437k3367b4fbgbf237c66a5af87ff@mail.gmail.com>
References: <534e5dc20901061346g5eb604c5kf63a80f5634a1128@mail.gmail.com>
	<F893D0B3C6794D4BA36DE9DDC72625D3@chimp>
	<2831fecf0901061437k3367b4fbgbf237c66a5af87ff@mail.gmail.com>
Message-ID: <1231320337.4567.4.camel@martr-gentoo.artec>

?hel kenal p?eval, T, 2009-01-06 kell 15:37, kirjutas Myles Watson:
> Marc,
> 
> Hopefully this makes everything right again.  I still think some of
> the geode functions should be moved, but that's really a separate
> issue.
> 
> > You have to specify to make things breadth first, which seems like the
> > correct way.
> 
> I guess it's not really breadth first.  It's just parents before siblings.
> 
> I think this should be done for all the phases unless there's some
> compelling reason not to.

I don't think having different phases run in different order is a good
idea, as it can lead to unexpected code execution orders all over again.

Hopefully we can finalize this soon, so I can finalize my month long
on-and-off NAND flash battles :)

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

Code-wise this looks good if all phases act the same way.
I'm not qualified right now to coment about the correctness of the
change for the order and how this affects existing mainboard code and
their code execution order expectations.


Mart Raudsepp




From fengyuning1984 at gmail.com  Wed Jan  7 10:52:19 2009
From: fengyuning1984 at gmail.com (FENG Yu Ning)
Date: Wed, 7 Jan 2009 17:52:19 +0800
Subject: [coreboot] [RFC]flashrom: improve basic design
In-Reply-To: <496161FA.8090308@gmx.net>
References: <a505dc9d0901010221m7b564228tbb5bf1f80818ed6a@mail.gmail.com>
	<496161FA.8090308@gmx.net>
Message-ID: <a505dc9d0901070152q69b2c58ex8eb76851e04474db@mail.gmail.com>

On Jan 5, 2009, Carl-Daniel Hailfinger wrote:
> thanks for yor design proposal.
Thanks for reading and commenting.

Having thought more, I realized the merit of the original design, and
I also realized what drives me eager to change it.

In the original design, every flash chip model could be specified its
own operation drivers. It is a good design providing mechanism.

However, too much code reuse keeps us from obtaining benefit from the
design. Most SPI flash chips have the same wrapper functions
probe_spi_rdid, spi_chip_write and spi_chip_read as their operation
drivers. Those drivers have to satisfy many flash chip. It is (too)
difficult.

We should limit how much we reuse operation drivers. My opinion is,
for read, erase and write, only the flash chip models in the same
series share drivers, and every model has its own probe driver. Thus,
we will never need IDs or page_size in struct flashchip, and will not
be bothered by related problems, such as grouping probe functions and
IDs, paged write, etc..

There would be code redundancy. We have to choose one to suffer from.

> Unfortunately, other parts of the proposed abstraction level will make
> it harder to understand chip drivers, especially for people who just
> want to contribute support for one of their own chips.

Yes.

Deeper thoughts make me realize that I am defining a
language/code (the specification), and trying to implement a built-in
compiler/virtual_machine (the chipset driver has to be intelligent).
It would be too complex.

> I believe that it is fundamentally wrong to differentiate between
> preopcodes and opcodes.

Agreed.

> I'll probably have to send a patch to kill all this preopcode/opcode stuff.

hmm.. for ICH7 like chipsets, we just cannot send a WREN like other
commands if SPI opmenu is locked.

BTW, do you have some comment on this issue?
http://www.coreboot.org/pipermail/coreboot/2008-December/043704.html

As you have said, it hurts.


yu ning



From uwe at hermann-uwe.de  Wed Jan  7 13:07:09 2009
From: uwe at hermann-uwe.de (Uwe Hermann)
Date: Wed, 7 Jan 2009 13:07:09 +0100
Subject: [coreboot] [PATCH] YABEL: add license to pmm files
In-Reply-To: <b5765cdf0901070107i6f49554ax841233c93c77ebe8@mail.gmail.com>
References: <b5765cdf0901050424s36a049c5q5c4d17d33079fee9@mail.gmail.com>
	<20090106000742.GF12484@greenwood>
	<b5765cdf0901070107i6f49554ax841233c93c77ebe8@mail.gmail.com>
Message-ID: <20090107120709.GA7490@greenwood>

On Wed, Jan 07, 2009 at 10:07:32AM +0100, Pattrick Hueper wrote:
> Hi,
> 
> here is the patch adding the BSD license header to the two files Uwe
> mentioned. (yabel/compat/time.h and yabel/compat/functions.c)
> I did get svn commit rights, so i will check this patch in myself,
> since this is trivial, i will self-ack, i hope that is ok.

Yep, looks ok. Go ahead.


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



From svn at coreboot.org  Wed Jan  7 13:11:13 2009
From: svn at coreboot.org (svn at coreboot.org)
Date: Wed,  7 Jan 2009 13:11:13 +0100
Subject: [coreboot] r3848 - trunk/util/flashrom
Message-ID: <mailman.2641.1355071467.16123.coreboot@coreboot.org>

Author: uwe
Date: 2009-01-07 13:11:13 +0100 (Wed, 07 Jan 2009)
New Revision: 3848

Modified:
   trunk/util/flashrom/chipset_enable.c
Log:
Add i631x LPC support.

Signed-off-by: Sven Schnelle <svens at stackframe.org>
Acked-by: Uwe Hermann <uwe at hermann-uwe.de>



Modified: trunk/util/flashrom/chipset_enable.c
===================================================================
--- trunk/util/flashrom/chipset_enable.c	2009-01-06 16:45:42 UTC (rev 3847)
+++ trunk/util/flashrom/chipset_enable.c	2009-01-07 12:11:13 UTC (rev 3848)
@@ -880,6 +880,7 @@
 	{0x8086, 0x24cc, "Intel ICH4-M",	enable_flash_ich_4e},
 	{0x8086, 0x24d0, "Intel ICH5/ICH5R",	enable_flash_ich_4e},
 	{0x8086, 0x25a1, "Intel 6300ESB",	enable_flash_ich_4e},
+	{0x8086, 0x2670, "Intel 631xESB/632xESB/3100",    enable_flash_ich_dc},
 	{0x8086, 0x2640, "Intel ICH6/ICH6R",	enable_flash_ich_dc},
 	{0x8086, 0x2641, "Intel ICH6-M",	enable_flash_ich_dc},
 	{0x8086, 0x5031, "Intel EP80579",	enable_flash_ich7},




From uwe at hermann-uwe.de  Wed Jan  7 13:11:43 2009
From: uwe at hermann-uwe.de (Uwe Hermann)
Date: Wed, 7 Jan 2009 13:11:43 +0100
Subject: [coreboot] [PATCH] flashrom: add i631x LPC support
In-Reply-To: <87eizgj0dl.fsf@apollo.stackframe.org>
References: <87ljtq7p7b.fsf@apollo.stackframe.org>
	<20090106011230.GH12484@greenwood>
	<87eizgj0dl.fsf@apollo.stackframe.org>
Message-ID: <20090107121142.GB7490@greenwood>

On Tue, Jan 06, 2009 at 09:37:42AM +0100, Sven Schnelle wrote:
> Signed-off-by: Sven Schnelle <svens at stackframe.org>

Thanks, r3848.


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



From uwe at hermann-uwe.de  Wed Jan  7 13:13:47 2009
From: uwe at hermann-uwe.de (Uwe Hermann)
Date: Wed, 7 Jan 2009 13:13:47 +0100
Subject: [coreboot] [PATCH] flashrom: Update man page
In-Reply-To: <4964014F.5090205@gmx.net>
References: <496166A3.2040705@gmx.net> <20090105230413.GB12484@greenwood>
	<4964014F.5090205@gmx.net>
Message-ID: <20090107121347.GC7490@greenwood>

On Wed, Jan 07, 2009 at 02:11:43AM +0100, Carl-Daniel Hailfinger wrote:
> Signed-off-by: Carl-Daniel Hailfinger <c-d.hailfinger.devel.2006 at gmx.net>

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


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



From svn at coreboot.org  Wed Jan  7 13:15:46 2009
From: svn at coreboot.org (svn at coreboot.org)
Date: Wed,  7 Jan 2009 13:15:46 +0100
Subject: [coreboot] r3849 - trunk/util/flashrom
Message-ID: <mailman.2642.1355071467.16123.coreboot@coreboot.org>

Author: uwe
Date: 2009-01-07 13:15:46 +0100 (Wed, 07 Jan 2009)
New Revision: 3849

Modified:
   trunk/util/flashrom/chipset_enable.c
Log:
Add AMD-768 chipset support.

Signed-off-by: Sven Schnelle <svens at stackframe.org>
Acked-by: Uwe Hermann <uwe at hermann-uwe.de>



Modified: trunk/util/flashrom/chipset_enable.c
===================================================================
--- trunk/util/flashrom/chipset_enable.c	2009-01-07 12:11:13 UTC (rev 3848)
+++ trunk/util/flashrom/chipset_enable.c	2009-01-07 12:15:46 UTC (rev 3849)
@@ -938,6 +938,7 @@
 	{0x1002, 0x4377, "ATI SB400",		enable_flash_sb400},
 	{0x1166, 0x0205, "Broadcom HT-1000",	enable_flash_ht1000},
 	{0x1022, 0x3000, "AMD Elan SC520",	get_flashbase_sc520},
+	{0x1022, 0x7440, "AMD AMD-768",         enable_flash_amd8111},
 };
 
 void print_supported_chipsets(void)




From uwe at hermann-uwe.de  Wed Jan  7 13:16:17 2009
From: uwe at hermann-uwe.de (Uwe Hermann)
Date: Wed, 7 Jan 2009 13:16:17 +0100
Subject: [coreboot] [PATCH] flashrom: add AMD-768 chipset support
In-Reply-To: <878wpoj040.fsf@apollo.stackframe.org>
References: <871vvihog9.fsf@apollo.stackframe.org>
	<20090106001141.542.qmail@stuge.se>
	<878wpoj040.fsf@apollo.stackframe.org>
Message-ID: <20090107121617.GD7490@greenwood>

On Tue, Jan 06, 2009 at 09:43:27AM +0100, Sven Schnelle wrote:
> > Does this chipset supporty anything else than LPC?
> 
> Don't think so, at least the documentation only mentions LPC as BIOS
> interface. Nevertheless i've recognized that the algorithm is the same
> as for the AMD8111, so let's just add the PCI Ids.
> 
> Signed-off-by: Sven Schnelle <svens at stackframe.org>

Thanks, r3849.


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



From svn at coreboot.org  Wed Jan  7 13:35:09 2009
From: svn at coreboot.org (svn at coreboot.org)
Date: Wed,  7 Jan 2009 13:35:09 +0100
Subject: [coreboot] r3850 - trunk/util/flashrom
Message-ID: <mailman.2643.1355071467.16123.coreboot@coreboot.org>

Author: uwe
Date: 2009-01-07 13:35:09 +0100 (Wed, 07 Jan 2009)
New Revision: 3850

Modified:
   trunk/util/flashrom/flash.h
   trunk/util/flashrom/flashchips.c
Log:
Add SST49LF020 support.

Signed-off-by: Sven Schnelle <svens at stackframe.org>
Acked-by: Uwe Hermann <uwe at hermann-uwe.de>



Modified: trunk/util/flashrom/flash.h
===================================================================
--- trunk/util/flashrom/flash.h	2009-01-07 12:15:46 UTC (rev 3849)
+++ trunk/util/flashrom/flash.h	2009-01-07 12:35:09 UTC (rev 3850)
@@ -356,6 +356,7 @@
 #define SST_39VF040		0xD7
 #define SST_49LF040B		0x50
 #define SST_49LF040		0x51
+#define SST_49LF020		0x61
 #define SST_49LF020A		0x52
 #define SST_49LF080A		0x5B
 #define SST_49LF002A		0x57

Modified: trunk/util/flashrom/flashchips.c
===================================================================
--- trunk/util/flashrom/flashchips.c	2009-01-07 12:15:46 UTC (rev 3849)
+++ trunk/util/flashrom/flashchips.c	2009-01-07 12:35:09 UTC (rev 3850)
@@ -626,6 +626,12 @@
 	 probe_49lfxxxc, erase_49lfxxxc, write_49lfxxxc
 	},
 
+	{"SST", "SST49LF020", SST_ID, SST_49LF020,
+	 256, 16 * 1024,
+	 TEST_OK_PR,
+	 probe_jedec, erase_49lf040, write_49lf040
+	},
+
 	{"SST", "SST49LF020A", SST_ID, SST_49LF020A,
 	 256, 16 * 1024,
 	 TEST_UNTESTED,




From uwe at hermann-uwe.de  Wed Jan  7 13:36:15 2009
From: uwe at hermann-uwe.de (Uwe Hermann)
Date: Wed, 7 Jan 2009 13:36:15 +0100
Subject: [coreboot] [PATCH] flashrom: add SST49LF020 support
In-Reply-To: <87ljtoj0o6.fsf@apollo.stackframe.org>
References: <877i5ahon6.fsf@apollo.stackframe.org>
	<20090105232701.GD12484@greenwood>
	<87ljtoj0o6.fsf@apollo.stackframe.org>
Message-ID: <20090107123615.GE7490@greenwood>

On Tue, Jan 06, 2009 at 09:31:21AM +0100, Sven Schnelle wrote:
> Signed-off-by: Sven Schnelle <svens at stackframe.org>

Thanks, r3850.

Btw, can we mark all the new stuff from your patches as supported in
the wiki, i.e. is all of it tested on hardware?


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



From svn at coreboot.org  Wed Jan  7 13:45:38 2009
From: svn at coreboot.org (coreboot)
Date: Wed, 07 Jan 2009 12:45:38 -0000
Subject: [coreboot] #118: Flashrom Makefile improvements
In-Reply-To: <054.59dd658c9579a750126c8e9a60770984@coreboot.org>
References: <054.59dd658c9579a750126c8e9a60770984@coreboot.org>
Message-ID: <063.6b7f101759ffed8877113f1f7cf950b8@coreboot.org>

#118: Flashrom Makefile improvements
----------------------------------+-----------------------------------------
   Reporter:  spooky85@?          |          Owner:  somebody
       Type:  task                |         Status:  new     
   Priority:  major               |      Milestone:          
  Component:  flashrom            |        Version:  v2      
   Keywords:                      |   Dependencies:          
Patchstatus:  patch needs review  |  
----------------------------------+-----------------------------------------

Comment(by uwe):

 Hi, please repost the patch with a Signed-off-by line so that we can
 commit it, see
 http://www.coreboot.org/Development_Guidelines#Sign-off_Procedure

 If possible, please also post the patch to the (coreboot) mailing list for
 easier reviewing.

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


From uwe at hermann-uwe.de  Wed Jan  7 13:49:56 2009
From: uwe at hermann-uwe.de (Uwe Hermann)
Date: Wed, 7 Jan 2009 13:49:56 +0100
Subject: [coreboot] coreboot Digest, Vol 46, Issue 148
In-Reply-To: <38687c4a0901020215g386111dbg3401eb2d684058a9@mail.gmail.com>
References: <mailman.73.1229874902.13869.coreboot@coreboot.org>
	<38687c4a0901020215g386111dbg3401eb2d684058a9@mail.gmail.com>
Message-ID: <20090107124955.GF7490@greenwood>

On Fri, Jan 02, 2009 at 10:15:32AM +0000, Daniele Primon wrote:
> Hi, obrain a similar output when trying to flash a proprietary BIOS.
> What I guess is that the initial address could be wrong. Here is the
> output:
> 
> root at debian:~# flashrom -w -v A6T-ASUS-0706.ROMCalibrating delay
> loop... OK.No coreboot table found.Found chipset "NVIDIA MCP51",
> enabling flash write... OK.Found chip "PMC Pm49FL004" (512 KB) at
> physical address 0xfff80000.Flash image seems to be a legacy BIOS.
> Disabling checks.Programming page: 0007 at address:
> 0x00070000Verifying flash... FAILED!  Expected=0xf8, Read=0x68

Are you sure your board is supported by flashrom, or works without
special support? See http://www.coreboot.org/Flashrom#Supported_mainboards

Also, have you tried the command multiple times (e.g. 5 times) in a row?
Sometimes there are glitches and writing will not work, but on the next
run it will...


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



From svens at stackframe.org  Wed Jan  7 13:55:26 2009
From: svens at stackframe.org (Sven Schnelle)
Date: Wed, 07 Jan 2009 13:55:26 +0100
Subject: [coreboot] [PATCH] flashrom: add SST49LF020 support
In-Reply-To: <20090107123615.GE7490@greenwood> (Uwe Hermann's message of "Wed, 
	7 Jan 2009 13:36:15 +0100")
References: <877i5ahon6.fsf@apollo.stackframe.org>
	<20090105232701.GD12484@greenwood>
	<87ljtoj0o6.fsf@apollo.stackframe.org>
	<20090107123615.GE7490@greenwood>
Message-ID: <87zli346o1.fsf@begreifnix.intranet.astaro.de>

Hi Uwe,

Uwe Hermann <uwe at hermann-uwe.de> writes:

> Btw, can we mark all the new stuff from your patches as supported in
> the wiki, i.e. is all of it tested on hardware?

Yes, they are tested on hardware - i have three Boards here,

2 with the Intel 5000 Chipset,
1 with AMD 760 Chipset.

The reason for adding the Flash/Chipset support is that i want to port/use
coreboot on these platforms.

Sven.



From c-d.hailfinger.devel.2006 at gmx.net  Wed Jan  7 13:54:35 2009
From: c-d.hailfinger.devel.2006 at gmx.net (Carl-Daniel Hailfinger)
Date: Wed, 07 Jan 2009 13:54:35 +0100
Subject: [coreboot] coreboot Digest, Vol 46, Issue 148
In-Reply-To: <20090107124955.GF7490@greenwood>
References: <mailman.73.1229874902.13869.coreboot@coreboot.org>	<38687c4a0901020215g386111dbg3401eb2d684058a9@mail.gmail.com>
	<20090107124955.GF7490@greenwood>
Message-ID: <4964A60B.6060903@gmx.net>

On 07.01.2009 13:49, Uwe Hermann wrote:
> On Fri, Jan 02, 2009 at 10:15:32AM +0000, Daniele Primon wrote:
>   
>> Hi, obrain a similar output when trying to flash a proprietary BIOS.
>> What I guess is that the initial address could be wrong. Here is the
>> output:
>>
>> root at debian:~# flashrom -w -v A6T-ASUS-0706.ROMCalibrating delay
>> loop... OK.No coreboot table found.Found chipset "NVIDIA MCP51",
>> enabling flash write... OK.Found chip "PMC Pm49FL004" (512 KB) at
>> physical address 0xfff80000.Flash image seems to be a legacy BIOS.
>> Disabling checks.Programming page: 0007 at address:
>> 0x00070000Verifying flash... FAILED!  Expected=0xf8, Read=0x68
>>     
>
> Are you sure your board is supported by flashrom, or works without
> special support? See http://www.coreboot.org/Flashrom#Supported_mainboards
>
> Also, have you tried the command multiple times (e.g. 5 times) in a row?
> Sometimes there are glitches and writing will not work, but on the next
> run it will...
>   

Although I claimed back then that MCP51 support worked, that may have
been an error. So far I am aware of no reproducible flashing of any chip
on MCP51.

Regards,
Carl-Daniel

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




From peter at stuge.se  Wed Jan  7 15:45:17 2009
From: peter at stuge.se (Peter Stuge)
Date: Wed, 7 Jan 2009 15:45:17 +0100
Subject: [coreboot] flashrom write/verify fails on ASUS A6T
In-Reply-To: <38687c4a0901020215g386111dbg3401eb2d684058a9@mail.gmail.com>
References: <mailman.73.1229874902.13869.coreboot@coreboot.org>
	<38687c4a0901020215g386111dbg3401eb2d684058a9@mail.gmail.com>
Message-ID: <20090107144517.10015.qmail@stuge.se>

Hi Daniele,

Daniele Primon wrote:
> Hi, obrain a similar output when trying to flash a proprietary BIOS.
> What I guess is that the initial address could be wrong. Here is the
> output:
> 
> root at debian:~# flashrom -w -v A6T-ASUS-0706.ROM
> Calibrating delay loop... OK.
> No coreboot table found.
> Found chipset "NVIDIA MCP51", enabling flash write... OK.
> Found chip "PMC Pm49FL004" (512 KB) at physical address 0xfff80000.
> Flash image seems to be a legacy BIOS.
> Disabling checks.
> Programming page: 0007 at address: 0x00070000
> Verifying flash... FAILED!  Expected=0xf8, Read=0x68

Please run flashrom again with -V on the command line for verbose
output, and send that to the list. (It will be many lines so please
send plain text without changing the formatting.)

Your mainboard requires some code to be added to flashrom. The flash
chip on the board has two input pins (7 and 8) for write protection,
and at least one of them is enabled at the moment. flashrom needs
code that disables them. Many times I find the easiest way to figure
that code out is to trace the pins and connections on the physical
board using a continuity tester, or ohm meter. Do you have access to
a multimeter?


//Peter



From corey.osgood at gmail.com  Wed Jan  7 16:07:39 2009
From: corey.osgood at gmail.com (Corey Osgood)
Date: Wed, 7 Jan 2009 10:07:39 -0500
Subject: [coreboot] v3 stage2 running from flash
In-Reply-To: <dd3c80060901062235j3f42b009j81104589d074bb1@mail.gmail.com>
References: <dd3c80060812232040g1023a815sc0e678e8fe62e1cd@mail.gmail.com>
	<dd3c80060812240014q723ac1d1w5df2a4be5b15d9db@mail.gmail.com>
	<13426df10812240209g7615fbbl9870365664488f1@mail.gmail.com>
	<dd3c80060812240220j13f26289q7b01320797fa5fb8@mail.gmail.com>
	<dd3c80060812240325j65b0461av68169dbb3819c405@mail.gmail.com>
	<dd3c80060901060259r1af9949eo7b5a0aa7fb303b38@mail.gmail.com>
	<13426df10901060855l2192139t369b0f548d450d8f@mail.gmail.com>
	<4963B559.1000504@gmx.net>
	<13426df10901062145p44400dd0rcc0a2a0bf738da72@mail.gmail.com>
	<dd3c80060901062235j3f42b009j81104589d074bb1@mail.gmail.com>
Message-ID: <dd3c80060901070707k4ef9548eod395cc021e101c6d@mail.gmail.com>

On Wed, Jan 7, 2009 at 1:35 AM, Corey Osgood <corey.osgood at gmail.com> wrote:

> On Wed, Jan 7, 2009 at 12:45 AM, ron minnich <rminnich at gmail.com> wrote:
>
>> On Tue, Jan 6, 2009 at 11:47 AM, Carl-Daniel Hailfinger
>> <c-d.hailfinger.devel.2006 at gmx.net> wrote:
>>
>> > As long as CAR is active, we don't want the cacheable area (CAR+ROM) to
>> > be bigger than the cache to prevent cache evictions of CAR contents.
>>
>
> Ah, that explains the reboots I'm seeing if the lar isn't zero-filled.
>
>
>>
>> > That means we can cache the boot block and maybe initram. In that
>> > situation, having initram directly before the boot block is a huge speed
>> > benefit.
>> > Once CAR is no longer active, we immediately want to mark the whole ROM
>> > and RAM as cacheable to speed up decompression.
>>
>> Yes. And you want to have those MTRRs in a state that they'll be
>> correct even if the OS you boot doesn't touch them.
>>
>> One logical place is at the end of initram. I'd like to get the
>> discussion to some agreement on where this code should be, and then we
>> can worry about writing the code. Maybe I am missing part of the
>> discussion but we seem to be going in circles at times :-)
>
>
> Probably my fault, I've just been skimming through the list the last couple
> months while I was in class, and I head back next week, so I'd like to get
> this running before then ;) Although the end of initram makes sense (I was
> going to tuck it into disable_car()), if we only mark the first couple MB of
> ram and all of ROM as cachable there (some safe value that every system
> should have and coreboot will always fit inside) and then mark all of it
> later when we add the ram resources, we eliminate the need for
> chipset-specific code to tell coreboot the ram size twice. Does that make
> sense, or will it just complicate things more?
>

And actually, we already have a config variable and function to do that in
stage1, the following should make it work (this is inside stage1_phase3).
All that would be left would be to teach ram_resource to re-set the mtrrs,
or use the mtrr setup functions I pulled in from v2. The next question
concerns that though, everything I can find suggests that coreboot uses the
range from 0MB-CBMEMK. What happens if/when it hits a reserved range? IE the
range from 768k-1MB which is always reserved on vt8237r, IIRC.

Thanks,
Corey

Index: arch/x86/stage1.c
===================================================================
--- arch/x86/stage1.c    (revision 1101)
+++ arch/x86/stage1.c    (working copy)
@@ -332,6 +332,10 @@
     /* Provide an easy way to check whether RAM is available. */
     global_vars()->ram_available = 1;

+#ifdef CONFIG_MTRR
+    cache_cbmem(MTRR_TYPE_WRBACK);
+#endif
+
     // location and size of image.
     init_archive(&archive);


>
>
> As for the CAR+ROM area caching, no argument; what I think we're
>> saying is we may need the ability to control where a LAR file ends up
>> in ROM so we can limit the cacheable area. Does that make sense?
>
>
> Perfect sense.
>
> Thanks,
> Corey
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20090107/2788d2dc/attachment.html>

From rminnich at gmail.com  Wed Jan  7 16:29:52 2009
From: rminnich at gmail.com (ron minnich)
Date: Wed, 7 Jan 2009 07:29:52 -0800
Subject: [coreboot] v3 stage2 running from flash
In-Reply-To: <dd3c80060901070707k4ef9548eod395cc021e101c6d@mail.gmail.com>
References: <dd3c80060812232040g1023a815sc0e678e8fe62e1cd@mail.gmail.com>
	<13426df10812240209g7615fbbl9870365664488f1@mail.gmail.com>
	<dd3c80060812240220j13f26289q7b01320797fa5fb8@mail.gmail.com>
	<dd3c80060812240325j65b0461av68169dbb3819c405@mail.gmail.com>
	<dd3c80060901060259r1af9949eo7b5a0aa7fb303b38@mail.gmail.com>
	<13426df10901060855l2192139t369b0f548d450d8f@mail.gmail.com>
	<4963B559.1000504@gmx.net>
	<13426df10901062145p44400dd0rcc0a2a0bf738da72@mail.gmail.com>
	<dd3c80060901062235j3f42b009j81104589d074bb1@mail.gmail.com>
	<dd3c80060901070707k4ef9548eod395cc021e101c6d@mail.gmail.com>
Message-ID: <13426df10901070729g7e9f4bffp663d99e814a3146e@mail.gmail.com>

On Wed, Jan 7, 2009 at 7:07 AM, Corey Osgood <corey.osgood at gmail.com> wrote:

> And actually, we already have a config variable and function to do that in
> stage1, the following should make it work (this is inside stage1_phase3).
> All that would be left would be to teach ram_resource to re-set the mtrrs,
> or use the mtrr setup functions I pulled in from v2. The next question
> concerns that though, everything I can find suggests that coreboot uses the
> range from 0MB-CBMEMK. What happens if/when it hits a reserved range? IE the
> range from 768k-1MB which is always reserved on vt8237r, IIRC.

I'm not sure under what circumstances coreboot would use the reserved range.
ron



From rminnich at gmail.com  Wed Jan  7 17:02:47 2009
From: rminnich at gmail.com (ron minnich)
Date: Wed, 7 Jan 2009 08:02:47 -0800
Subject: [coreboot] [PATCH] There's a pciconf.h with PCI conf constants
	- lets actually use it
In-Reply-To: <1231234547.4627.5.camel@martr-gentoo.artec>
References: <1231166997.20385.3.camel@martr-gentoo.artec>
	<20090105232412.GC12484@greenwood>
	<20090105233800.24547.qmail@stuge.se>
	<1231234547.4627.5.camel@martr-gentoo.artec>
Message-ID: <13426df10901070802i4f417776ha52ecb856fedb908@mail.gmail.com>

On Tue, Jan 6, 2009 at 1:35 AM, Mart Raudsepp
<mart.raudsepp at artecdesign.ee> wrote:

> I simply noticed the fact that there are constant defined, and that the
> same thing is used per value. Lets perhaps fix the inconsistency another
> way then. Proposed patch attached.

That patch I like ...

ron



From mylesgw at gmail.com  Wed Jan  7 17:35:57 2009
From: mylesgw at gmail.com (Myles Watson)
Date: Wed, 7 Jan 2009 09:35:57 -0700
Subject: [coreboot] domain vs device statictree order
In-Reply-To: <1231320337.4567.4.camel@martr-gentoo.artec>
References: <534e5dc20901061346g5eb604c5kf63a80f5634a1128@mail.gmail.com>
	<F893D0B3C6794D4BA36DE9DDC72625D3@chimp>
	<2831fecf0901061437k3367b4fbgbf237c66a5af87ff@mail.gmail.com>
	<1231320337.4567.4.camel@martr-gentoo.artec>
Message-ID: <2831fecf0901070835h1f260f9cweaea5d8ad38ae0fd@mail.gmail.com>

>> I guess it's not really breadth first.  It's just parents before siblings.
>>
>> I think this should be done for all the phases unless there's some
>> compelling reason not to.
>
> I don't think having different phases run in different order is a good
> idea, as it can lead to unexpected code execution orders all over again.

I agree.

> Code-wise this looks good if all phases act the same way.

Without this patch Phase1, Phase2, and Phase6 are done in statictree
order, and Phase3, Phase4, and Phase5 are done Parents before
children.

I don't see Phase1 being used anywhere.  Phase2 is handled with the
patch.  I think Phase6 should be updated, and I can send a patch.

Ron?

Thanks,
Myles



From marcj303 at gmail.com  Wed Jan  7 18:05:48 2009
From: marcj303 at gmail.com (Marc Jones)
Date: Wed, 7 Jan 2009 10:05:48 -0700
Subject: [coreboot] domain vs device statictree order
In-Reply-To: <2831fecf0901061529p539d4e80s2bcb8c15abdf06a6@mail.gmail.com>
References: <534e5dc20901061346g5eb604c5kf63a80f5634a1128@mail.gmail.com>
	<F893D0B3C6794D4BA36DE9DDC72625D3@chimp>
	<2831fecf0901061437k3367b4fbgbf237c66a5af87ff@mail.gmail.com>
	<534e5dc20901061513l3b63756mf0a102cddc33ecc0@mail.gmail.com>
	<2831fecf0901061519i873cdf5ua5110832479f1679@mail.gmail.com>
	<2831fecf0901061529p539d4e80s2bcb8c15abdf06a6@mail.gmail.com>
Message-ID: <534e5dc20901070905p401b0a5aj2598ccef1a3edec7@mail.gmail.com>

On Tue, Jan 6, 2009 at 4:29 PM, Myles Watson <mylesgw at gmail.com> wrote:
> Here's the rest of the geodelx fixup patch too.  I think this is more
> intuitive, but again I don't have the hardware.
>
> Signed-off-by: Myles Watson <mylesgw at gmail.com>
>

This matches the resource allocation work you did much better.

Can you make the dts changes to the other Geode mainboards when you check it in?
amd/norwich
amd/db800
artec/dbe61
artec/dbe62
pcengines/alix1c
pcengines/alix2c3

I think that is all of them.

Acked-by: Marc Jones <marcj303 at gmail.com>


Thanks,
Marc



From marcj303 at gmail.com  Wed Jan  7 18:12:13 2009
From: marcj303 at gmail.com (Marc Jones)
Date: Wed, 7 Jan 2009 10:12:13 -0700
Subject: [coreboot] domain vs device statictree order
In-Reply-To: <2831fecf0901070835h1f260f9cweaea5d8ad38ae0fd@mail.gmail.com>
References: <534e5dc20901061346g5eb604c5kf63a80f5634a1128@mail.gmail.com>
	<F893D0B3C6794D4BA36DE9DDC72625D3@chimp>
	<2831fecf0901061437k3367b4fbgbf237c66a5af87ff@mail.gmail.com>
	<1231320337.4567.4.camel@martr-gentoo.artec>
	<2831fecf0901070835h1f260f9cweaea5d8ad38ae0fd@mail.gmail.com>
Message-ID: <534e5dc20901070912s47237dc1pbf930085d2110ad3@mail.gmail.com>

On Wed, Jan 7, 2009 at 9:35 AM, Myles Watson <mylesgw at gmail.com> wrote:
>>> I guess it's not really breadth first.  It's just parents before siblings.
>>>
>>> I think this should be done for all the phases unless there's some
>>> compelling reason not to.
>>
>> I don't think having different phases run in different order is a good
>> idea, as it can lead to unexpected code execution orders all over again.
>
> I agree.
>
>> Code-wise this looks good if all phases act the same way.
>
> Without this patch Phase1, Phase2, and Phase6 are done in statictree
> order, and Phase3, Phase4, and Phase5 are done Parents before
> children.
>
> I don't see Phase1 being used anywhere.  Phase2 is handled with the
> patch.  I think Phase6 should be updated, and I can send a patch.
>
> Ron?
>

I think all the phases should be in parents before children order, ie
the same order that the devices would get scan. That seems to be the
most intuitive and should be consistent.

Marc



From rminnich at gmail.com  Wed Jan  7 18:16:11 2009
From: rminnich at gmail.com (ron minnich)
Date: Wed, 7 Jan 2009 09:16:11 -0800
Subject: [coreboot] SCALE reminder
Message-ID: <13426df10901070916t2c21c115q5fd7a701cdfaf788@mail.gmail.com>

I'm back at work in 10 days :-)

I need to set up the table for SCALE. So:
- folks on this list: demo suggestions?
- anybody willing to help at SCALE?
- Vendors: I'm happy to show hardware you want displayed

thanks

ron



From mylesgw at gmail.com  Wed Jan  7 18:23:16 2009
From: mylesgw at gmail.com (Myles Watson)
Date: Wed, 7 Jan 2009 10:23:16 -0700
Subject: [coreboot] domain vs device statictree order
In-Reply-To: <534e5dc20901070905p401b0a5aj2598ccef1a3edec7@mail.gmail.com>
References: <534e5dc20901061346g5eb604c5kf63a80f5634a1128@mail.gmail.com>
	<F893D0B3C6794D4BA36DE9DDC72625D3@chimp>
	<2831fecf0901061437k3367b4fbgbf237c66a5af87ff@mail.gmail.com>
	<534e5dc20901061513l3b63756mf0a102cddc33ecc0@mail.gmail.com>
	<2831fecf0901061519i873cdf5ua5110832479f1679@mail.gmail.com>
	<2831fecf0901061529p539d4e80s2bcb8c15abdf06a6@mail.gmail.com>
	<534e5dc20901070905p401b0a5aj2598ccef1a3edec7@mail.gmail.com>
Message-ID: <2831fecf0901070923h347b8276nfa51e88d7f23f01f@mail.gmail.com>

> This matches the resource allocation work you did much better.

Thanks.

> Can you make the dts changes to the other Geode mainboards when you check it in?

Sure.

> pcengines/alix2c3
This one doesn't have any graphics memory reserved.  Is that on purpose?

Thanks,
Myles



From marcj303 at gmail.com  Wed Jan  7 18:28:13 2009
From: marcj303 at gmail.com (Marc Jones)
Date: Wed, 7 Jan 2009 10:28:13 -0700
Subject: [coreboot] domain vs device statictree order
In-Reply-To: <2831fecf0901070923h347b8276nfa51e88d7f23f01f@mail.gmail.com>
References: <534e5dc20901061346g5eb604c5kf63a80f5634a1128@mail.gmail.com>
	<F893D0B3C6794D4BA36DE9DDC72625D3@chimp>
	<2831fecf0901061437k3367b4fbgbf237c66a5af87ff@mail.gmail.com>
	<534e5dc20901061513l3b63756mf0a102cddc33ecc0@mail.gmail.com>
	<2831fecf0901061519i873cdf5ua5110832479f1679@mail.gmail.com>
	<2831fecf0901061529p539d4e80s2bcb8c15abdf06a6@mail.gmail.com>
	<534e5dc20901070905p401b0a5aj2598ccef1a3edec7@mail.gmail.com>
	<2831fecf0901070923h347b8276nfa51e88d7f23f01f@mail.gmail.com>
Message-ID: <534e5dc20901070928g2829db3dg7befd75c34b994a9@mail.gmail.com>

On Wed, Jan 7, 2009 at 10:23 AM, Myles Watson <mylesgw at gmail.com> wrote:
>> This matches the resource allocation work you did much better.
>
> Thanks.
>
>> Can you make the dts changes to the other Geode mainboards when you check it in?
>
> Sure.
>
>> pcengines/alix2c3
> This one doesn't have any graphics memory reserved.  Is that on purpose?

Yes, It is headless.

Marc



From rminnich at gmail.com  Wed Jan  7 18:29:14 2009
From: rminnich at gmail.com (ron minnich)
Date: Wed, 7 Jan 2009 09:29:14 -0800
Subject: [coreboot] v3 ck804 support
In-Reply-To: <20090105223651.10427.qmail@stuge.se>
References: <2831fecf0901051114l4836e020hfe91f76b788ff87b@mail.gmail.com>
	<20090105223651.10427.qmail@stuge.se>
Message-ID: <13426df10901070929jf43473aj66a27a39604f7d14@mail.gmail.com>

On Mon, Jan 5, 2009 at 2:36 PM, Peter Stuge <peter at stuge.se> wrote:
> Myles Watson wrote:
>> This patch adds southbridge/nvidia/ck804 from v2 minimally updated
>> for v3.
>
> Mostly fine, but..
>
>
>> +     /* If that is invalid we will read that from romstrap. */
>> +     if (!eeprom_valid) {
>> +             unsigned long mac_pos;
>> +             mac_pos = 0xffffffd0; /* See romstrap.inc and romstrap.lds. */
>> +             mac_l = readl(mac_pos) + nic_index;
>> +             mac_h = readl(mac_pos + 4);
>> +     }
>
> ..this won't work so well in v3 I think. I'd like a LAR file for the
> MAC.

Yep. Put a #warning here so we can fix it.

>
>
>> +#if CONFIG_PCI_ROM_RUN == 1
>> +     pci_dev_init(dev);      /* It will init Option ROM. */
>> +#endif
>
> Should this be in the NIC code?

Seems that way to me.


>
>
>> +// 0x7a or e3
>> +#define PREVIOUS_POWER_STATE 0x7A
>> +
>> +#define MAINBOARD_POWER_OFF 0
>> +#define MAINBOARD_POWER_ON 1
>> +#define SLOW_CPU_OFF 0
>> +#define SLOW_CPU__ON 1
>> +
>> +#ifndef MAINBOARD_POWER_ON_AFTER_POWER_FAIL
>> +#define MAINBOARD_POWER_ON_AFTER_POWER_FAIL MAINBOARD_POWER_ON
>> +#endif
>
> We should make this a CONFIG_ variable.


Actually it should be a cmos option, as in any real mainboard. Code
for this should not be #ifdef'ed.

A #warning here would be useful too.

thanks

ron



From peter at stuge.se  Wed Jan  7 18:29:29 2009
From: peter at stuge.se (Peter Stuge)
Date: Wed, 7 Jan 2009 18:29:29 +0100
Subject: [coreboot] domain vs device statictree order
In-Reply-To: <2831fecf0901070835h1f260f9cweaea5d8ad38ae0fd@mail.gmail.com>
References: <534e5dc20901061346g5eb604c5kf63a80f5634a1128@mail.gmail.com>
	<F893D0B3C6794D4BA36DE9DDC72625D3@chimp>
	<2831fecf0901061437k3367b4fbgbf237c66a5af87ff@mail.gmail.com>
	<1231320337.4567.4.camel@martr-gentoo.artec>
	<2831fecf0901070835h1f260f9cweaea5d8ad38ae0fd@mail.gmail.com>
Message-ID: <20090107172929.30531.qmail@stuge.se>

Myles Watson wrote:
> >> I guess it's not really breadth first.  It's just parents before
> >> siblings.

Will our scheme with 6 phases all processing devices in one and the
same way fit all hardware?

Maybe the bus scan order needs to be settable, maybe by Kconfig,
maybe even at runtime?

I'll try to clarify:

Geode and Mart needs parents before siblings for phase2 to have VSA
init before the NAND enable, VSA is in domain.p2 and NAND in ide.p2.

I can imagine that one algorithm for deciding the order of processing
all devices in the system will not be enough however.

We'll see more dynamic hardware, which will require us to be better
at running code in the right order.

HT speed reconfiguration may be another example, or does it run
already before any of the phases? Does that also require parents
before siblings, or is something else (breadth first?) more
appropriate there?


If we can actually get by with just one simple algorithm that's
great of course. Can we?


> > I don't think having different phases run in different order is a
> > good idea, as it can lead to unexpected code execution orders all
> > over again.
> 
> I agree.

Yes, me too, in the sense that whoever is filling out phases will
need code for different devices to run in some particular order, and
instead of trying to guess and document what we think is sufficient,
it would be nice to have infrastructure that allows each phase filler
to specify the order they need in a very easy way.


> Without this patch Phase1, Phase2, and Phase6 are done in
> statictree order, and Phase3, Phase4, and Phase5 are done
> Parents before children.

The merit of statictree order is that it's the only thing available
before the dynamic bus scans in phase3, or?


> I don't see Phase1 being used anywhere.  Phase2 is handled with the
> patch.  I think Phase6 should be updated, and I can send a patch.

--8<-- doc/design/newboot.lyx
Phase 1 -- very early setup
This phase existed to make printk work and has been obsoleted.
The simple traversal (forall devices) is used for this phase.

Phase 2 -- fixup.
Fix broken devices if needed. Typically used by mainboard device.

These are functions that are required before any PCI operations of
any kind are run.
The simple traversal (forall devices) is used for this phase.
-->8--

I suggest moving VSA init to domain.phase1. It's certainly very early
setup because it _creates_ the PCI devices that are to be fixed up in
phase2.

Another option might be to put the NAND init in phase3.


//Peter



From peter at stuge.se  Wed Jan  7 18:34:23 2009
From: peter at stuge.se (Peter Stuge)
Date: Wed, 7 Jan 2009 18:34:23 +0100
Subject: [coreboot] [PATCH] Fix flashrom init for VT8237S
In-Reply-To: <4954C723.5060608@assembler.cz>
References: <4954C723.5060608@assembler.cz>
Message-ID: <20090107173423.31732.qmail@stuge.se>

Rudolf Marek wrote:
> Following patch fixes VIA SPI (VT8237S). It needs to have opcodes
> initialized same way as ICH7.
> 
> Signed-off-by: Rudolf Marek <r.marek at assembler.cz>

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



From mylesgw at gmail.com  Wed Jan  7 18:42:27 2009
From: mylesgw at gmail.com (Myles Watson)
Date: Wed, 7 Jan 2009 10:42:27 -0700
Subject: [coreboot] domain vs device statictree order
In-Reply-To: <20090107172929.30531.qmail@stuge.se>
References: <534e5dc20901061346g5eb604c5kf63a80f5634a1128@mail.gmail.com>
	<F893D0B3C6794D4BA36DE9DDC72625D3@chimp>
	<2831fecf0901061437k3367b4fbgbf237c66a5af87ff@mail.gmail.com>
	<1231320337.4567.4.camel@martr-gentoo.artec>
	<2831fecf0901070835h1f260f9cweaea5d8ad38ae0fd@mail.gmail.com>
	<20090107172929.30531.qmail@stuge.se>
Message-ID: <2831fecf0901070942r43f0d5b2qb108e22be383f08f@mail.gmail.com>

On Wed, Jan 7, 2009 at 10:29 AM, Peter Stuge <peter at stuge.se> wrote:
> Myles Watson wrote:
>> >> I guess it's not really breadth first.  It's just parents before
>> >> siblings.
>
> Will our scheme with 6 phases all processing devices in one and the
> same way fit all hardware?

I can't think of a time when a child expects to be initialized
(whatever phase) before its parent.

> Maybe the bus scan order needs to be settable, maybe by Kconfig,
> maybe even at runtime?
>
> I'll try to clarify:
>
> Geode and Mart needs parents before siblings for phase2 to have VSA
> init before the NAND enable, VSA is in domain.p2 and NAND in ide.p2.
>
> I can imagine that one algorithm for deciding the order of processing
> all devices in the system will not be enough however.
>
> We'll see more dynamic hardware, which will require us to be better
> at running code in the right order.

Those porting the code can choose what phase things need to go in if
it is clear what order things are called.  If that's not clear it
seems very hard to write the code.

> HT speed reconfiguration may be another example, or does it run
> already before any of the phases?

It runs in stage 1.

> Does that also require parents
> before siblings, or is something else (breadth first?) more
> appropriate there?
>
> If we can actually get by with just one simple algorithm that's
> great of course. Can we?

I think so.  It seems like the only downside is that for_all_devices
was simpler than the tree traversal.  I guess it also reaches devices
which weren't found in phase3, but it seems like if phase3 can't find
them you shouldn't do phase4-6.

>> > I don't think having different phases run in different order is a
>> > good idea, as it can lead to unexpected code execution orders all
>> > over again.
>>
>> I agree.
>
> Yes, me too, in the sense that whoever is filling out phases will
> need code for different devices to run in some particular order, and
> instead of trying to guess and document what we think is sufficient,
> it would be nice to have infrastructure that allows each phase filler
> to specify the order they need in a very easy way.
>
>
>> Without this patch Phase1, Phase2, and Phase6 are done in
>> statictree order, and Phase3, Phase4, and Phase5 are done
>> Parents before children.
>
> The merit of statictree order is that it's the only thing available
> before the dynamic bus scans in phase3, or?

There are always two orders available.  When stage2 starts we have the
device tree, which contains children, sibling, and next pointers.  I'm
not sure we ever care to use the next pointers.  Dynamic devices are
not available until after phase3, no matter which way you traverse the
devices.

>> I don't see Phase1 being used anywhere.  Phase2 is handled with the
>> patch.  I think Phase6 should be updated, and I can send a patch.
>
> --8<-- doc/design/newboot.lyx
> Phase 1 -- very early setup
> This phase existed to make printk work and has been obsoleted.
> The simple traversal (forall devices) is used for this phase.
>
> Phase 2 -- fixup.
> Fix broken devices if needed. Typically used by mainboard device.
>
> These are functions that are required before any PCI operations of
> any kind are run.
> The simple traversal (forall devices) is used for this phase.
> -->8--
>
> I suggest moving VSA init to domain.phase1. It's certainly very early
> setup because it _creates_ the PCI devices that are to be fixed up in
> phase2.
If phase1 is really obsolete, then phase2 is as early as you get.  Do
we need to reinstate phase1?

Thanks,
Myles



From svn at coreboot.org  Wed Jan  7 19:26:18 2009
From: svn at coreboot.org (svn at coreboot.org)
Date: Wed,  7 Jan 2009 19:26:18 +0100
Subject: [coreboot] r1103 - in coreboot-v3: mainboard/amd/db800
	mainboard/amd/norwich mainboard/amp/tinygx
	mainboard/artecgroup/dbe61 mainboard/artecgroup/dbe62
	mainboard/pcengines/alix1c northbridge/amd/geodelx
Message-ID: <mailman.2644.1355071467.16123.coreboot@coreboot.org>

Author: myles
Date: 2009-01-07 19:26:18 +0100 (Wed, 07 Jan 2009)
New Revision: 1103

Modified:
   coreboot-v3/mainboard/amd/db800/dts
   coreboot-v3/mainboard/amd/norwich/dts
   coreboot-v3/mainboard/amp/tinygx/dts
   coreboot-v3/mainboard/artecgroup/dbe61/dts
   coreboot-v3/mainboard/artecgroup/dbe62/dts
   coreboot-v3/mainboard/pcengines/alix1c/dts
   coreboot-v3/northbridge/amd/geodelx/apic
   coreboot-v3/northbridge/amd/geodelx/domain
   coreboot-v3/northbridge/amd/geodelx/geodelx.c
   coreboot-v3/northbridge/amd/geodelx/pci
Log:
This patch updates geodelx to fit the new resource allocator better.  It
splits the domain and the memory controller functions into their respective
devices.

It also updates the dts for all the boards that use geodelx_video_mb.

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



Modified: coreboot-v3/mainboard/amd/db800/dts
===================================================================
--- coreboot-v3/mainboard/amd/db800/dts	2009-01-07 09:14:03 UTC (rev 1102)
+++ coreboot-v3/mainboard/amd/db800/dts	2009-01-07 18:26:18 UTC (rev 1103)
@@ -29,11 +29,15 @@
 	};
 	domain at 0 {
 		/config/("northbridge/amd/geodelx/domain");
-		/* Video RAM has to be in 2MB chunks. */
-		geode_video_mb = "8";
 		pci at 1,0 {
 			/config/("northbridge/amd/geodelx/pci");
+			/* Video RAM has to be in 2MB chunks. */
+			geode_video_mb = "8";
 		};
+		pci at 1,1 { /* Graphics */
+		};
+		pci at 1,2 { /* AES */
+		};
 		pci at f,0 {
 			/config/("southbridge/amd/cs5536/dts");
 			/* Interrupt enables for LPC bus.

Modified: coreboot-v3/mainboard/amd/norwich/dts
===================================================================
--- coreboot-v3/mainboard/amd/norwich/dts	2009-01-07 09:14:03 UTC (rev 1102)
+++ coreboot-v3/mainboard/amd/norwich/dts	2009-01-07 18:26:18 UTC (rev 1103)
@@ -29,11 +29,15 @@
 	};
 	domain at 0 {
 		/config/("northbridge/amd/geodelx/domain");
-		/* Video RAM has to be in 2MB chunks. */
-		geode_video_mb = "8";
 		pci at 1,0 {
 			/config/("northbridge/amd/geodelx/pci");
+			/* Video RAM has to be in 2MB chunks. */
+			geode_video_mb = "8";
 		};
+		pci at 1,1 { /* Graphics */
+		};
+		pci at 1,2 { /* AES */
+		};
 		pci at f,0 {
 			/config/("southbridge/amd/cs5536/dts");
 			/* Interrupt enables for LPC bus.

Modified: coreboot-v3/mainboard/amp/tinygx/dts
===================================================================
--- coreboot-v3/mainboard/amp/tinygx/dts	2009-01-07 09:14:03 UTC (rev 1102)
+++ coreboot-v3/mainboard/amp/tinygx/dts	2009-01-07 18:26:18 UTC (rev 1103)
@@ -29,11 +29,15 @@
 	};
 	domain at 0 {
 		/config/("northbridge/amd/geodelx/domain");
-		/* Video RAM has to be in 2MB chunks. */
-		geode_video_mb = "8";
 		pci at 1,0 {
 			/config/("northbridge/amd/geodelx/pci");
+			/* Video RAM has to be in 2MB chunks. */
+			geode_video_mb = "8";
 		};
+		pci at 1,1 { /* Graphics */
+		};
+		pci at 1,2 { /* AES */
+		};
 		pci at f,0 {
 			/config/("southbridge/amd/cs5536/dts");
 			/* Interrupt enables for LPC bus.

Modified: coreboot-v3/mainboard/artecgroup/dbe61/dts
===================================================================
--- coreboot-v3/mainboard/artecgroup/dbe61/dts	2009-01-07 09:14:03 UTC (rev 1102)
+++ coreboot-v3/mainboard/artecgroup/dbe61/dts	2009-01-07 18:26:18 UTC (rev 1103)
@@ -74,12 +74,16 @@
 	};
 	domain at 0 {
 		/config/("northbridge/amd/geodelx/domain");
-		/* Video RAM has to be in 2MB chunks. */
-		/* 16MB for now, as 8MB would not be enough for WinCE */
-		geode_video_mb = "16";
 		pci at 1,0 {
 			/config/("northbridge/amd/geodelx/pci");
+			/* Video RAM has to be in 2MB chunks. */
+			/* 16MB for now, as 8MB would not be enough for WinCE */
+			geode_video_mb = "16";
 		};
+		pci at 1,1 { /* Graphics */
+		};
+		pci at 1,2 { /* AES */
+		};
 		pci at f,0 {
 			/config/("southbridge/amd/cs5536/dts");
 			/* Interrupt enables for LPC bus.

Modified: coreboot-v3/mainboard/artecgroup/dbe62/dts
===================================================================
--- coreboot-v3/mainboard/artecgroup/dbe62/dts	2009-01-07 09:14:03 UTC (rev 1102)
+++ coreboot-v3/mainboard/artecgroup/dbe62/dts	2009-01-07 18:26:18 UTC (rev 1103)
@@ -27,11 +27,19 @@
 	};
 	domain at 0 {
 		/config/("northbridge/amd/geodelx/domain");
-		/* Video RAM has to be in 2MB chunks. */
-		geode_video_mb = "16";
 		pci at 1,0 {
 			/config/("northbridge/amd/geodelx/pci");
+			/* Video RAM has to be in 2MB chunks. */
+			geode_video_mb = "16";
 		};
+		pci at 1,1 {
+			/* This is the graphics device, but since the memory
+			 * controller needs to know geode_video_mb, the
+			 * phase2_init is done there.  The rest are default ops.
+			 */
+		};
+		pci at 1,2 { /* AES */
+		};
 		pci at f,0 {
 			/config/("southbridge/amd/cs5536/dts");
 			/* Interrupt enables for LPC bus.

Modified: coreboot-v3/mainboard/pcengines/alix1c/dts
===================================================================
--- coreboot-v3/mainboard/pcengines/alix1c/dts	2009-01-07 09:14:03 UTC (rev 1102)
+++ coreboot-v3/mainboard/pcengines/alix1c/dts	2009-01-07 18:26:18 UTC (rev 1103)
@@ -27,11 +27,15 @@
 	};
 	domain at 0 {
 		/config/("northbridge/amd/geodelx/domain");
-		/* Video RAM has to be in 2MB chunks. */
-		geode_video_mb = "8";
 		pci at 1,0 {
 			/config/("northbridge/amd/geodelx/pci");
+			/* Video RAM has to be in 2MB chunks. */
+			geode_video_mb = "8";
 		};
+		pci at 1,1 { /* Graphics */
+		};
+		pci at 1,2 { /* AES */
+		};
 		pci at f,0 {
 			/config/("southbridge/amd/cs5536/dts");
 			/* Interrupt enables for LPC bus.

Modified: coreboot-v3/northbridge/amd/geodelx/apic
===================================================================
--- coreboot-v3/northbridge/amd/geodelx/apic	2009-01-07 09:14:03 UTC (rev 1102)
+++ coreboot-v3/northbridge/amd/geodelx/apic	2009-01-07 18:26:18 UTC (rev 1103)
@@ -19,6 +19,6 @@
  */
 
 {
-	device_operations = "geodelx_north_apic";
+	device_operations = "geodelx_apic";
 };
 

Modified: coreboot-v3/northbridge/amd/geodelx/domain
===================================================================
--- coreboot-v3/northbridge/amd/geodelx/domain	2009-01-07 09:14:03 UTC (rev 1102)
+++ coreboot-v3/northbridge/amd/geodelx/domain	2009-01-07 18:26:18 UTC (rev 1103)
@@ -20,9 +20,7 @@
  */
 
 {
-	device_operations = "geodelx_north_domain";
-
-	/* Video RAM has to be in 2MB chunks. */
-	geode_video_mb = "0";
+	device_operations = "geodelx_domain";
+	bridge;
 };
 

Modified: coreboot-v3/northbridge/amd/geodelx/geodelx.c
===================================================================
--- coreboot-v3/northbridge/amd/geodelx/geodelx.c	2009-01-07 09:14:03 UTC (rev 1102)
+++ coreboot-v3/northbridge/amd/geodelx/geodelx.c	2009-01-07 18:26:18 UTC (rev 1103)
@@ -48,7 +48,7 @@
  *
  * @return TODO.
  */
-u64 get_systop(struct northbridge_amd_geodelx_domain_config *nb_dm)
+u64 get_systop(struct northbridge_amd_geodelx_pci_config *nb_dm)
 {
 	const struct gliutable *gl = NULL;
 	u64 systop;
@@ -94,7 +94,10 @@
 static void geodelx_northbridge_set_resources(struct device *dev)
 {
 	struct resource *resource, *last;
+	struct northbridge_amd_geodelx_pci_config *nb_dm =
+	 (struct northbridge_amd_geodelx_pci_config *)dev->device_configuration;
 	unsigned int link;
+	int idx;
 	struct bus *bus;
 	u8 line;
 
@@ -116,6 +119,13 @@
 		}
 	}
 
+	/* Report the memory regions. */
+	idx = 10;
+	/* 0 .. 640 KB */
+	ram_resource(dev, idx++, 0, 640);
+	/* 1 MB .. (Systop - 1 MB) (in KB) */
+	ram_resource(dev, idx++, 1024, (get_systop(nb_dm) / 1024) - 1024);
+
 	/* Set a default latency timer. */
 	pci_write_config8(dev, PCI_LATENCY_TIMER, 0x40);
 
@@ -133,34 +143,26 @@
 }
 
 /**
+ * Read resources in the PCI domain.
+ *
+ * @param dev The device.
+ */
+static void geodelx_pci_domain_read_resources(struct device *dev)
+{
+	/* If the domain has any specific resources, read them here. */
+	pci_domain_read_resources(dev);
+}
+
+/**
  * Set resources in the PCI domain.
  *
- * Also, as a side effect, create a RAM resource in the child which,
- * interestingly enough, is the northbridge PCI device, for later
- * allocation of address space.
- *
  * @param dev The device.
  */
 static void geodelx_pci_domain_set_resources(struct device *dev)
 {
-	int idx;
-	struct device *mc_dev;
-	struct northbridge_amd_geodelx_domain_config *nb_dm =
-	 (struct northbridge_amd_geodelx_domain_config *)dev->device_configuration;
+	printk(BIOS_SPEW, ">> Entering northbridge.c: %s\n", __func__);
+	/* This is where we'd set the domain-specific resources. */
 
-	printk(BIOS_SPEW, ">> Entering northbridge.c: %s\n", __FUNCTION__);
-
-	mc_dev = dev->link[0].children;
-	if (mc_dev) {
-		/* Report the memory regions. */
-		idx = 10;
-		/* 0 .. 640 KB */
-		ram_resource(dev, idx++, 0, 640);
-		/* 1 MB .. (Systop - 1 MB) (in KB) */
-		ram_resource(dev, idx++, 1024,
-			     (get_systop(nb_dm) / 1024) - 1024);
-	}
-
 	phase4_set_resources(&dev->link[0]);
 }
 
@@ -178,9 +180,6 @@
  */
 static void geodelx_pci_domain_phase2(struct device *dev)
 {
-	struct northbridge_amd_geodelx_domain_config *nb_dm =
-	 (struct northbridge_amd_geodelx_domain_config *)dev->device_configuration;
-
 	void do_vsmbios(void);
 
 	printk(BIOS_SPEW, ">> Entering northbridge.c: %s\n", __FUNCTION__);
@@ -194,12 +193,23 @@
 	do_vsmbios(); 
 	printk(BIOS_SPEW, "After VSA:\n");
 	/* print_conf(); */
-	printk(BIOS_DEBUG, "VRC_VG value: 0x%04x\n", nb_dm->geode_video_mb);
-	graphics_init((u8)nb_dm->geode_video_mb);
-	pci_check_pci_ops(dev->ops->ops_pci_bus);
 }
 
 /**
+ * Do the NB video setup.
+ *
+ * @param dev The device.
+ */
+static void geodelx_mc_phase2(struct device *dev)
+{
+	struct northbridge_amd_geodelx_pci_config *nb_mc =
+	 (struct northbridge_amd_geodelx_pci_config *)dev->device_configuration;
+
+	printk(BIOS_DEBUG, "VRC_VG value: 0x%04x\n", nb_mc->geode_video_mb);
+	graphics_init((u8)nb_mc->geode_video_mb);
+}
+
+/**
  * Support for APIC cluster init.
  *
  * TODO: Should we do this in phase 2? It is now done in phase 6.
@@ -222,14 +232,14 @@
  */
 
 /** Operations for when the northbridge is running a PCI domain. */
-struct device_operations geodelx_north_domain = {
+struct device_operations geodelx_domain = {
 	.id = {.type = DEVICE_ID_PCI_DOMAIN,
-		{.pci_domain = {.vendor = PCI_VENDOR_ID_AMD,
-				     .device = PCI_DEVICE_ID_AMD_LXBRIDGE}}},
+	       {.pci_domain = {.vendor = PCI_VENDOR_ID_AMD,
+			       .device = PCI_DEVICE_ID_AMD_LXBRIDGE}}},
 	.constructor			= default_device_constructor,
-	.phase2_fixup		= geodelx_pci_domain_phase2,
+	.phase2_fixup			= geodelx_pci_domain_phase2,
 	.phase3_scan			= pci_domain_scan_bus,
-	.phase4_read_resources		= pci_domain_read_resources,
+	.phase4_read_resources		= geodelx_pci_domain_read_resources,
 	.phase4_set_resources		= geodelx_pci_domain_set_resources,
 	.phase5_enable_resources	= enable_childrens_resources,
 	.phase6_init			= 0,
@@ -237,17 +247,16 @@
 };
 
 /** Operations for when the northbridge is running an APIC cluster. */
-struct device_operations geodelx_north_apic = {
+struct device_operations geodelx_apic = {
 	.id = {.type = DEVICE_ID_APIC_CLUSTER,
-		{.apic_cluster = {.vendor = PCI_VENDOR_ID_AMD,
-				       .device = PCI_DEVICE_ID_AMD_LXBRIDGE}}},
+	       {.apic_cluster = {.vendor = PCI_VENDOR_ID_AMD,
+				 .device = PCI_DEVICE_ID_AMD_LXBRIDGE}}},
 	.constructor			= default_device_constructor,
 	.phase3_scan			= 0,
 	.phase4_read_resources		= cpu_bus_noop,
 	.phase4_set_resources		= cpu_bus_noop,
 	.phase5_enable_resources	= cpu_bus_noop,
 	.phase6_init			= cpu_bus_init,
-	.ops_pci_bus			= &pci_cf8_conf1,
 };
 
 /**
@@ -255,15 +264,15 @@
  *
  * Note that phase3 scan is done in the domain, and MUST NOT be done here too.
  */
-struct device_operations geodelx_north_pci = {
+struct device_operations geodelx_mc = {
 	.id = {.type = DEVICE_ID_PCI,
 		{.pci = {.vendor = PCI_VENDOR_ID_AMD,
 			      .device = PCI_DEVICE_ID_AMD_LXBRIDGE}}},
 	.constructor			= default_device_constructor,
+	.phase2_fixup			= geodelx_mc_phase2,
 	.phase3_scan			= 0,
-	.phase4_read_resources		= pci_domain_read_resources,
+	.phase4_read_resources		= pci_dev_read_resources,
 	.phase4_set_resources		= geodelx_northbridge_set_resources,
 	.phase5_enable_resources	= enable_childrens_resources,
 	.phase6_init			= geodelx_northbridge_init,
-	.ops_pci_bus			= &pci_cf8_conf1,
 };

Modified: coreboot-v3/northbridge/amd/geodelx/pci
===================================================================
--- coreboot-v3/northbridge/amd/geodelx/pci	2009-01-07 09:14:03 UTC (rev 1102)
+++ coreboot-v3/northbridge/amd/geodelx/pci	2009-01-07 18:26:18 UTC (rev 1103)
@@ -19,7 +19,9 @@
  */
 
 {
-	device_operations = "geodelx_north_pci";
-	bridge;
+	device_operations = "geodelx_mc";
+
+	/* Video RAM has to be in 2MB chunks. */
+	geode_video_mb = "0";
 };
 




From mylesgw at gmail.com  Wed Jan  7 19:27:01 2009
From: mylesgw at gmail.com (Myles Watson)
Date: Wed, 7 Jan 2009 11:27:01 -0700
Subject: [coreboot] domain vs device statictree order
In-Reply-To: <534e5dc20901070905p401b0a5aj2598ccef1a3edec7@mail.gmail.com>
References: <534e5dc20901061346g5eb604c5kf63a80f5634a1128@mail.gmail.com>
	<F893D0B3C6794D4BA36DE9DDC72625D3@chimp>
	<2831fecf0901061437k3367b4fbgbf237c66a5af87ff@mail.gmail.com>
	<534e5dc20901061513l3b63756mf0a102cddc33ecc0@mail.gmail.com>
	<2831fecf0901061519i873cdf5ua5110832479f1679@mail.gmail.com>
	<2831fecf0901061529p539d4e80s2bcb8c15abdf06a6@mail.gmail.com>
	<534e5dc20901070905p401b0a5aj2598ccef1a3edec7@mail.gmail.com>
Message-ID: <2831fecf0901071027t461c3c54rf8fd0b54112b5238@mail.gmail.com>

On Wed, Jan 7, 2009 at 10:05 AM, Marc Jones <marcj303 at gmail.com> wrote:
> On Tue, Jan 6, 2009 at 4:29 PM, Myles Watson <mylesgw at gmail.com> wrote:
>> Here's the rest of the geodelx fixup patch too.  I think this is more
>> intuitive, but again I don't have the hardware.
>>
>> Signed-off-by: Myles Watson <mylesgw at gmail.com>
>>
>
> This matches the resource allocation work you did much better.
>
> Can you make the dts changes to the other Geode mainboards when you check it in?
> amd/norwich
> amd/db800
> artec/dbe61
> artec/dbe62
> pcengines/alix1c
> pcengines/alix2c3

Done.

> I think that is all of them.
>
> Acked-by: Marc Jones <marcj303 at gmail.com>
Rev 1103.

Thanks,
Myles



From marcj303 at gmail.com  Wed Jan  7 19:27:59 2009
From: marcj303 at gmail.com (Marc Jones)
Date: Wed, 7 Jan 2009 11:27:59 -0700
Subject: [coreboot] domain vs device statictree order
In-Reply-To: <2831fecf0901070942r43f0d5b2qb108e22be383f08f@mail.gmail.com>
References: <534e5dc20901061346g5eb604c5kf63a80f5634a1128@mail.gmail.com>
	<F893D0B3C6794D4BA36DE9DDC72625D3@chimp>
	<2831fecf0901061437k3367b4fbgbf237c66a5af87ff@mail.gmail.com>
	<1231320337.4567.4.camel@martr-gentoo.artec>
	<2831fecf0901070835h1f260f9cweaea5d8ad38ae0fd@mail.gmail.com>
	<20090107172929.30531.qmail@stuge.se>
	<2831fecf0901070942r43f0d5b2qb108e22be383f08f@mail.gmail.com>
Message-ID: <534e5dc20901071027v5ffe361j83067d814e84fbb9@mail.gmail.com>

On Wed, Jan 7, 2009 at 10:42 AM, Myles Watson <mylesgw at gmail.com> wrote:
> On Wed, Jan 7, 2009 at 10:29 AM, Peter Stuge <peter at stuge.se> wrote:

>> I suggest moving VSA init to domain.phase1. It's certainly very early
>> setup because it _creates_ the PCI devices that are to be fixed up in
>> phase2.
> If phase1 is really obsolete, then phase2 is as early as you get.  Do
> we need to reinstate phase1?

Being the top level of the Geode PCI domain, Phase2_fixup for the
domain in parent to child order is correct place to do VSA init.
Phase2_fixup for the cs5536 southbridge should make the NAND/IDE
switch before resource allocation in phase 3-5.

I think that you want phase6 to walk the tree in case there is
something that needs fixup after allocation especially if it was
hidden from allocation.

Marc



From svn at coreboot.org  Wed Jan  7 19:37:21 2009
From: svn at coreboot.org (svn at coreboot.org)
Date: Wed,  7 Jan 2009 19:37:21 +0100
Subject: [coreboot] r1104 - coreboot-v3/southbridge/nvidia/ck804
Message-ID: <mailman.2645.1355071467.16123.coreboot@coreboot.org>

Author: myles
Date: 2009-01-07 19:37:21 +0100 (Wed, 07 Jan 2009)
New Revision: 1104

Modified:
   coreboot-v3/southbridge/nvidia/ck804/ck804_nic.c
   coreboot-v3/southbridge/nvidia/ck804/lpc.c
Log:
This trivial patch adds the warnings Peter and Ron requested to the ck804 code.

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



Modified: coreboot-v3/southbridge/nvidia/ck804/ck804_nic.c
===================================================================
--- coreboot-v3/southbridge/nvidia/ck804/ck804_nic.c	2009-01-07 18:26:18 UTC (rev 1103)
+++ coreboot-v3/southbridge/nvidia/ck804/ck804_nic.c	2009-01-07 18:37:21 UTC (rev 1104)
@@ -89,6 +89,8 @@
 		}
 	}
 
+#warning This should be fixed.  Can we use a LAR file for the MAC?
+
 	/* If that is invalid we will read that from romstrap. */
 	if (!eeprom_valid) {
 		unsigned long mac_pos;

Modified: coreboot-v3/southbridge/nvidia/ck804/lpc.c
===================================================================
--- coreboot-v3/southbridge/nvidia/ck804/lpc.c	2009-01-07 18:26:18 UTC (rev 1103)
+++ coreboot-v3/southbridge/nvidia/ck804/lpc.c	2009-01-07 18:37:21 UTC (rev 1104)
@@ -124,6 +124,8 @@
 #define SLOW_CPU_OFF 0
 #define SLOW_CPU__ON 1
 
+#warning Power on after fail should be a CMOS option.
+
 #ifndef MAINBOARD_POWER_ON_AFTER_POWER_FAIL
 #define MAINBOARD_POWER_ON_AFTER_POWER_FAIL MAINBOARD_POWER_ON
 #endif




From mylesgw at gmail.com  Wed Jan  7 19:39:26 2009
From: mylesgw at gmail.com (Myles Watson)
Date: Wed, 7 Jan 2009 11:39:26 -0700
Subject: [coreboot] v3 ck804 support
In-Reply-To: <13426df10901070929jf43473aj66a27a39604f7d14@mail.gmail.com>
References: <2831fecf0901051114l4836e020hfe91f76b788ff87b@mail.gmail.com>
	<20090105223651.10427.qmail@stuge.se>
	<13426df10901070929jf43473aj66a27a39604f7d14@mail.gmail.com>
Message-ID: <2831fecf0901071039off897bfj1be307f04c35344f@mail.gmail.com>

On Wed, Jan 7, 2009 at 10:29 AM, ron minnich <rminnich at gmail.com> wrote:
> On Mon, Jan 5, 2009 at 2:36 PM, Peter Stuge <peter at stuge.se> wrote:
>> Myles Watson wrote:
>>> This patch adds southbridge/nvidia/ck804 from v2 minimally updated
>>> for v3.
>>
>> Mostly fine, but..
>>
>>
>>> +     /* If that is invalid we will read that from romstrap. */
>>> +     if (!eeprom_valid) {
>>> +             unsigned long mac_pos;
>>> +             mac_pos = 0xffffffd0; /* See romstrap.inc and romstrap.lds. */
>>> +             mac_l = readl(mac_pos) + nic_index;
>>> +             mac_h = readl(mac_pos + 4);
>>> +     }
>>
>> ..this won't work so well in v3 I think. I'd like a LAR file for the
>> MAC.
>
> Yep. Put a #warning here so we can fix it.

Added.

>
>>
>>
>>> +#if CONFIG_PCI_ROM_RUN == 1
>>> +     pci_dev_init(dev);      /* It will init Option ROM. */
>>> +#endif
>>
>> Should this be in the NIC code?

There could be an option ROM for the NIC.

>>> +// 0x7a or e3
>>> +#define PREVIOUS_POWER_STATE 0x7A
>>> +
>>> +#define MAINBOARD_POWER_OFF 0
>>> +#define MAINBOARD_POWER_ON 1
>>> +#define SLOW_CPU_OFF 0
>>> +#define SLOW_CPU__ON 1
>>> +
>>> +#ifndef MAINBOARD_POWER_ON_AFTER_POWER_FAIL
>>> +#define MAINBOARD_POWER_ON_AFTER_POWER_FAIL MAINBOARD_POWER_ON
>>> +#endif
>>
>> We should make this a CONFIG_ variable.
>
>
> Actually it should be a cmos option, as in any real mainboard. Code
> for this should not be #ifdef'ed.
>
> A #warning here would be useful too.

Added.

Rev 1104.  Thanks for the reminder.

Thanks,
Myles



From peter at stuge.se  Wed Jan  7 21:12:36 2009
From: peter at stuge.se (Peter Stuge)
Date: Wed, 7 Jan 2009 21:12:36 +0100
Subject: [coreboot] v3 ck804 support
In-Reply-To: <2831fecf0901071039off897bfj1be307f04c35344f@mail.gmail.com>
References: <2831fecf0901051114l4836e020hfe91f76b788ff87b@mail.gmail.com>
	<20090105223651.10427.qmail@stuge.se>
	<13426df10901070929jf43473aj66a27a39604f7d14@mail.gmail.com>
	<2831fecf0901071039off897bfj1be307f04c35344f@mail.gmail.com>
Message-ID: <20090107201236.23594.qmail@stuge.se>

Myles Watson wrote:
> >>> +#if CONFIG_PCI_ROM_RUN == 1
> >>> +     pci_dev_init(dev);      /* It will init Option ROM. */
> >>> +#endif
> >>
> >> Should this be in the NIC code?
> 
> There could be an option ROM for the NIC.

The point was that this wasn't in the NIC code.

Thanks for adding the warnings.


//Peter



From mylesgw at gmail.com  Wed Jan  7 21:24:10 2009
From: mylesgw at gmail.com (Myles Watson)
Date: Wed, 7 Jan 2009 13:24:10 -0700
Subject: [coreboot] v3 ck804 support
In-Reply-To: <20090107201236.23594.qmail@stuge.se>
References: <2831fecf0901051114l4836e020hfe91f76b788ff87b@mail.gmail.com>
	<20090105223651.10427.qmail@stuge.se>
	<13426df10901070929jf43473aj66a27a39604f7d14@mail.gmail.com>
	<2831fecf0901071039off897bfj1be307f04c35344f@mail.gmail.com>
	<20090107201236.23594.qmail@stuge.se>
Message-ID: <2831fecf0901071224p4a686603xa8ab07d6801373d8@mail.gmail.com>

On Wed, Jan 7, 2009 at 1:12 PM, Peter Stuge <peter at stuge.se> wrote:
> Myles Watson wrote:
>> >>> +#if CONFIG_PCI_ROM_RUN == 1
>> >>> +     pci_dev_init(dev);      /* It will init Option ROM. */
>> >>> +#endif
>> >>
>> >> Should this be in the NIC code?
>>
>> There could be an option ROM for the NIC.
>
> The point was that this wasn't in the NIC code.

Sorry I misunderstood.  It's in both places, ide and nic.  I just took
it from v2.

> Thanks for adding the warnings.

Sure.

Thanks,
Myles



From mylesgw at gmail.com  Wed Jan  7 22:04:43 2009
From: mylesgw at gmail.com (Myles Watson)
Date: Wed, 7 Jan 2009 14:04:43 -0700
Subject: [coreboot] domain vs device statictree order
In-Reply-To: <2831fecf0901061437k3367b4fbgbf237c66a5af87ff@mail.gmail.com>
References: <534e5dc20901061346g5eb604c5kf63a80f5634a1128@mail.gmail.com>
	<F893D0B3C6794D4BA36DE9DDC72625D3@chimp>
	<2831fecf0901061437k3367b4fbgbf237c66a5af87ff@mail.gmail.com>
Message-ID: <2831fecf0901071304u26e06834t14a0d5b1f30b815d@mail.gmail.com>

On Tue, Jan 6, 2009 at 3:37 PM, Myles Watson <mylesgw at gmail.com> wrote:
> Marc,
>
> Hopefully this makes everything right again.  I still think some of
> the geode functions should be moved, but that's really a separate
> issue.
>
>> You have to specify to make things breadth first, which seems like the
>> correct way.
>
> I guess it's not really breadth first.  It's just parents before siblings.

I guess the more correct terminology is preorder.  Take care of the
root before siblings or children.

> I think this should be done for all the phases unless there's some
> compelling reason not to.

This patch implements preorder traversal for Phase 2 and Phase 6, and prints a
warning that Phase 1 is obsolete if anyone implements one.

The only difference between the Phase 2 and Phase 6 implementations is
that phase2_fixup is always called if it's defined, but phase6_init is
only called if the device is enabled.

Note that any devices not found in the tree will not have their init
functions called with this patch.  I think that's a good thing, but it
will require some dts fixes.

Boot tested on Serengeti and qemu.

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

Thanks,
Myles
-------------- next part --------------
A non-text attachment was scrubbed...
Name: parents_first.diff
Type: text/x-patch
Size: 3747 bytes
Desc: not available
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20090107/70827b01/attachment.diff>

From mylesgw at gmail.com  Thu Jan  8 00:24:23 2009
From: mylesgw at gmail.com (Myles Watson)
Date: Wed, 7 Jan 2009 16:24:23 -0700
Subject: [coreboot] K8 HT and dts fixups
Message-ID: <2831fecf0901071524m357a8b43n9c4210545c4fe4d5@mail.gmail.com>

This is a small HT fixup until HT links get figured out better.

It removes processors from the list of devices on the domain's bus so
that pci_scan_bus won't disable them, then scans for them, then puts
them back.  There are lots of other ways to do this, but this one
seemed minimally invasive and ends up with a correct tree.

The dts fixups I should have put in with the other K8 patch for the
new resource allocator.  I went to the v2 Config.lb files and tried to
get them as complete as possible.

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

Thanks,
Myles



From mylesgw at gmail.com  Thu Jan  8 00:24:58 2009
From: mylesgw at gmail.com (Myles Watson)
Date: Wed, 7 Jan 2009 16:24:58 -0700
Subject: [coreboot] K8 HT and dts fixups
In-Reply-To: <2831fecf0901071524m357a8b43n9c4210545c4fe4d5@mail.gmail.com>
References: <2831fecf0901071524m357a8b43n9c4210545c4fe4d5@mail.gmail.com>
Message-ID: <2831fecf0901071524r4bd7ee48n3ea6ff16ebb9ff75@mail.gmail.com>

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

Thanks,
Myles
-------------- next part --------------
A non-text attachment was scrubbed...
Name: k8_ht.diff
Type: text/x-patch
Size: 9259 bytes
Desc: not available
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20090107/3068e0fe/attachment.diff>

From peter at stuge.se  Thu Jan  8 02:11:44 2009
From: peter at stuge.se (Peter Stuge)
Date: Thu, 8 Jan 2009 02:11:44 +0100
Subject: [coreboot] domain vs device statictree order
In-Reply-To: <2831fecf0901071304u26e06834t14a0d5b1f30b815d@mail.gmail.com>
References: <534e5dc20901061346g5eb604c5kf63a80f5634a1128@mail.gmail.com>
	<F893D0B3C6794D4BA36DE9DDC72625D3@chimp>
	<2831fecf0901061437k3367b4fbgbf237c66a5af87ff@mail.gmail.com>
	<2831fecf0901071304u26e06834t14a0d5b1f30b815d@mail.gmail.com>
Message-ID: <20090108011144.1228.qmail@stuge.se>

Myles Watson wrote:
> This patch implements preorder traversal for Phase 2 and Phase 6, and prints a
> warning that Phase 1 is obsolete if anyone implements one.
> 
> The only difference between the Phase 2 and Phase 6 implementations is
> that phase2_fixup is always called if it's defined, but phase6_init is
> only called if the device is enabled.
> 
> Note that any devices not found in the tree will not have their init
> functions called with this patch.  I think that's a good thing, but it
> will require some dts fixes.
> 
> Boot tested on Serengeti and qemu.
> 
> Signed-off-by: Myles Watson <mylesgw at gmail.com>

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



From peter at stuge.se  Thu Jan  8 02:20:33 2009
From: peter at stuge.se (Peter Stuge)
Date: Thu, 8 Jan 2009 02:20:33 +0100
Subject: [coreboot] K8 HT and dts fixups
In-Reply-To: <2831fecf0901071524r4bd7ee48n3ea6ff16ebb9ff75@mail.gmail.com>
References: <2831fecf0901071524m357a8b43n9c4210545c4fe4d5@mail.gmail.com>
	<2831fecf0901071524r4bd7ee48n3ea6ff16ebb9ff75@mail.gmail.com>
Message-ID: <20090108012033.2758.qmail@stuge.se>

Myles Watson wrote:
> And the patch.
> Signed-off-by: Myles Watson <mylesgw at gmail.com>

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



From ward at gnu.org  Thu Jan  8 03:01:37 2009
From: ward at gnu.org (Ward Vandewege)
Date: Wed, 7 Jan 2009 21:01:37 -0500
Subject: [coreboot] domain vs device statictree order
In-Reply-To: <2831fecf0901071027t461c3c54rf8fd0b54112b5238@mail.gmail.com>
References: <534e5dc20901061346g5eb604c5kf63a80f5634a1128@mail.gmail.com>
	<F893D0B3C6794D4BA36DE9DDC72625D3@chimp>
	<2831fecf0901061437k3367b4fbgbf237c66a5af87ff@mail.gmail.com>
	<534e5dc20901061513l3b63756mf0a102cddc33ecc0@mail.gmail.com>
	<2831fecf0901061519i873cdf5ua5110832479f1679@mail.gmail.com>
	<2831fecf0901061529p539d4e80s2bcb8c15abdf06a6@mail.gmail.com>
	<534e5dc20901070905p401b0a5aj2598ccef1a3edec7@mail.gmail.com>
	<2831fecf0901071027t461c3c54rf8fd0b54112b5238@mail.gmail.com>
Message-ID: <20090108020137.GA20844@localdomain>

On Wed, Jan 07, 2009 at 11:27:01AM -0700, Myles Watson wrote:
> On Wed, Jan 7, 2009 at 10:05 AM, Marc Jones <marcj303 at gmail.com> wrote:
> > On Tue, Jan 6, 2009 at 4:29 PM, Myles Watson <mylesgw at gmail.com> wrote:
> >> Here's the rest of the geodelx fixup patch too.  I think this is more
> >> intuitive, but again I don't have the hardware.
> >>
> >> Signed-off-by: Myles Watson <mylesgw at gmail.com>
> >>
> >
> > This matches the resource allocation work you did much better.
> >
> > Can you make the dts changes to the other Geode mainboards when you check it in?
> > amd/norwich
> > amd/db800
> > artec/dbe61
> > artec/dbe62
> > pcengines/alix1c
> > pcengines/alix2c3
> 
> Done.
> 
> > I think that is all of them.
> >
> > Acked-by: Marc Jones <marcj303 at gmail.com>
> Rev 1103.

Marc asked me to test on geode - I tried on an alix2c3 just now with v1104.
Looks like something broke (but perhaps not because of this particular
checkin - the last known ok v3 version for alix2c3 is 682). Basically, the
alix resets itself right after (during?)

  cs5536: southbridge_init

Bootlog attached.

Help?

Thanks,
Ward.

-- 
Ward Vandewege <ward at fsf.org>
Free Software Foundation - Senior Systems Administrator
-------------- next part --------------
A non-text attachment was scrubbed...
Name: alix2c3-v1104-output.cap.gz
Type: application/octet-stream
Size: 10721 bytes
Desc: not available
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20090107/66da7dff/attachment.obj>

From ward at gnu.org  Thu Jan  8 03:31:35 2009
From: ward at gnu.org (Ward Vandewege)
Date: Wed, 7 Jan 2009 21:31:35 -0500
Subject: [coreboot] domain vs device statictree order
In-Reply-To: <20090108020137.GA20844@localdomain>
References: <534e5dc20901061346g5eb604c5kf63a80f5634a1128@mail.gmail.com>
	<F893D0B3C6794D4BA36DE9DDC72625D3@chimp>
	<2831fecf0901061437k3367b4fbgbf237c66a5af87ff@mail.gmail.com>
	<534e5dc20901061513l3b63756mf0a102cddc33ecc0@mail.gmail.com>
	<2831fecf0901061519i873cdf5ua5110832479f1679@mail.gmail.com>
	<2831fecf0901061529p539d4e80s2bcb8c15abdf06a6@mail.gmail.com>
	<534e5dc20901070905p401b0a5aj2598ccef1a3edec7@mail.gmail.com>
	<2831fecf0901071027t461c3c54rf8fd0b54112b5238@mail.gmail.com>
	<20090108020137.GA20844@localdomain>
Message-ID: <20090108023135.GA21159@localdomain>

On Wed, Jan 07, 2009 at 09:01:37PM -0500, Ward Vandewege wrote:
> > > Acked-by: Marc Jones <marcj303 at gmail.com>
> > Rev 1103.
> 
> Marc asked me to test on geode - I tried on an alix2c3 just now with v1104.
> Looks like something broke (but perhaps not because of this particular
> checkin - the last known ok v3 version for alix2c3 is 682). Basically, the
> alix resets itself right after (during?)
> 
>   cs5536: southbridge_init
> 
> Bootlog attached.
> 
> Help?

The rev that broke the boot was 1089 or 1090. 1089 does not build, so I can't
tell for sure. 1088 boots fine. 1090 is broken.

Btw: buildrom + artec dongle + alix2c3 -> 40 second turnaround time between
boots (and that includes 10 seconds for me). This is *nice*.

Thanks,
Ward.

-- 
Ward Vandewege <ward at fsf.org>
Free Software Foundation - Senior Systems Administrator



From c-d.hailfinger.devel.2006 at gmx.net  Thu Jan  8 03:34:18 2009
From: c-d.hailfinger.devel.2006 at gmx.net (Carl-Daniel Hailfinger)
Date: Thu, 08 Jan 2009 03:34:18 +0100
Subject: [coreboot] AMD DBM690T PowerNow table problems
In-Reply-To: <534e5dc20901060847j6c19053av20fe3845ca3df3b5@mail.gmail.com>
References: <49583EA2.8080903@gmx.net> <495FE0E5.7020503@assembler.cz>	
	<534e5dc20901051725l69907601k7d2ccf6817510257@mail.gmail.com>	
	<DD1CC71B621B004FA76856E5129D6B17024A0045@sbjgexmb1.amd.com>
	<534e5dc20901060847j6c19053av20fe3845ca3df3b5@mail.gmail.com>
Message-ID: <4965662A.5060109@gmx.net>

On 06.01.2009 17:47, Marc Jones wrote:
> On Mon, Jan 5, 2009 at 6:36 PM, Bao, Zheng <Zheng.Bao at amd.com> wrote:
>   
>> If fid_multiplier is 0, it doesn't seem to have any sense. So I agree.
>>
>> Acked-by: zheng bao <zheng.bao at amd.com>
>>
>>     
>
> I also fixed this in acpi_tables.c Pistachio.
>
> r 3847
>   

Thanks!
The Linux kernel powernow-k8 driver doesn't complain anymore, but now
the machine will lock up or reboot once I put some load on it.
Blacklisting the powernow-k8 driver avoids the issue, but that makes
frequency scaling impossible.

AFAICS the standard cpu frequency governor is ondemand and it scales the
frequency down from 1800 MHz to 1000 Mhz. That seems to work fine, but
scaling up again will cause the lockups/reboots. By the way, coreboot
reports a BIST failure after such reboots. Not nice.

Rudolf's PowerNow tables had entries for 1000/1600/1800 MHz. The
proprietary BIOS and coreboot only have entries for 1000/1800 MHz.
According to the docs, scaling from 1000 MHz to 1800 MHz can't be done
in a single step. Is that maybe the reason for the problems I'm seeing?

Regards,
Carl-Daniel

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




From svn at coreboot.org  Thu Jan  8 04:40:17 2009
From: svn at coreboot.org (svn at coreboot.org)
Date: Thu,  8 Jan 2009 04:40:17 +0100
Subject: [coreboot] r3851 - trunk/util/flashrom
Message-ID: <mailman.2646.1355071467.16123.coreboot@coreboot.org>

Author: hailfinger
Date: 2009-01-08 04:40:17 +0100 (Thu, 08 Jan 2009)
New Revision: 3851

Modified:
   trunk/util/flashrom/flashchips.c
Log:
This patch improves machine parseability and human readability of
flashchips.c over what's currently in flashrom HEAD.
The explicit initialization makes sure any future struct flashchip
reordering is not needed. (Except for the case where we need arrays
of some of the struct members.)

Signed-off-by: Stephan Guilloux <mailto:stephan.guilloux at free.fr>
Acked-by: Carl-Daniel Hailfinger <c-d.hailfinger.devel.2006 at gmx.net>


Modified: trunk/util/flashrom/flashchips.c
===================================================================
--- trunk/util/flashrom/flashchips.c	2009-01-07 12:35:09 UTC (rev 3850)
+++ trunk/util/flashrom/flashchips.c	2009-01-08 03:40:17 UTC (rev 3851)
@@ -36,949 +36,2111 @@
 	 * Probe function, Erase function, Write function, Read function
 	 */
 
-	{"AMD", "Am29F002(N)BB", AMD_ID, AM_29F002BB,
-	 256, 256,
-	 TEST_UNTESTED,
-	 probe_jedec, erase_chip_jedec, write_en29f002a
+	{
+		.vendor		= "AMD",
+		.name		= "Am29F002(N)BB",
+		.manufacture_id	= AMD_ID,
+		.model_id	= AM_29F002BB,
+		.total_size	= 256,
+		.page_size	= 256,
+		.tested		= TEST_UNTESTED,
+		.probe		= probe_jedec,
+		.erase		= erase_chip_jedec,
+		.write		= write_en29f002a,
 	},
 
-	{"AMD", "Am29F002(N)BT", AMD_ID, AM_29F002BT,
-	 256, 256,
-	 TEST_OK_PREW,
-	 probe_jedec, erase_chip_jedec, write_en29f002a
+	{
+		.vendor		= "AMD",
+		.name		= "Am29F002(N)BT",
+		.manufacture_id	= AMD_ID,
+		.model_id	= AM_29F002BT,
+		.total_size	= 256,
+		.page_size	= 256,
+		.tested		= TEST_OK_PREW,
+		.probe		= probe_jedec,
+		.erase		= erase_chip_jedec,
+		.write		= write_en29f002a,
 	},
 
-	{"AMD", "Am29F016D", AMD_ID, AM_29F016D,
-	 2048, 64 * 1024,
-	 TEST_UNTESTED,
-	 probe_29f040b, erase_29f040b, write_29f040b
+	{
+		.vendor		= "AMD",
+		.name		= "Am29F016D",
+		.manufacture_id	= AMD_ID,
+		.model_id	= AM_29F016D,
+		.total_size	= 2048,
+		.page_size	= 64 * 1024,
+		.tested		= TEST_UNTESTED,
+		.probe		= probe_29f040b,
+		.erase		= erase_29f040b,
+		.write		= write_29f040b,
 	},
 
-	{"AMD", "Am29F040B", AMD_ID, AM_29F040B,
-	 512, 64 * 1024,
-	 TEST_OK_PREW,
-	 probe_29f040b, erase_29f040b, write_29f040b
+	{
+		.vendor		= "AMD",
+		.name		= "Am29F040B",
+		.manufacture_id	= AMD_ID,
+		.model_id	= AM_29F040B,
+		.total_size	= 512,
+		.page_size	= 64 * 1024,
+		.tested		= TEST_OK_PREW,
+		.probe		= probe_29f040b,
+		.erase		= erase_29f040b,
+		.write		= write_29f040b,
 	},
 
-	{"AMD", "Am29LV040B", AMD_ID, AM_29LV040B,
-	 512, 64 * 1024,
-	 TEST_UNTESTED,
-	 probe_29f040b, erase_29f040b, write_29f040b
+	{
+		.vendor		= "AMD",
+		.name		= "Am29LV040B",
+		.manufacture_id	= AMD_ID,
+		.model_id	= AM_29LV040B,
+		.total_size	= 512,
+		.page_size	= 64 * 1024,
+		.tested		= TEST_UNTESTED,
+		.probe		= probe_29f040b,
+		.erase		= erase_29f040b,
+		.write		= write_29f040b,
 	},
 
-	{"ASD", "AE49F2008", ASD_ID, ASD_AE49F2008,
-	 256, 128,
-	 TEST_UNTESTED,
-	 probe_jedec, erase_chip_jedec, write_jedec
+	{
+		.vendor		= "ASD",
+		.name		= "AE49F2008",
+		.manufacture_id	= ASD_ID,
+		.model_id	= ASD_AE49F2008,
+		.total_size	= 256,
+		.page_size	= 128,
+		.tested		= TEST_UNTESTED,
+		.probe		= probe_jedec,
+		.erase		= erase_chip_jedec,
+		.write		= write_jedec,
 	},
 
-	{"Atmel", "AT25DF021", ATMEL_ID, AT_25DF021,
-	 256, 256,
-	 TEST_UNTESTED,
-	 probe_spi_rdid, NULL, NULL, spi_chip_read
+	{
+		.vendor		= "Atmel",
+		.name		= "AT25DF021",
+		.manufacture_id	= ATMEL_ID,
+		.model_id	= AT_25DF021,
+		.total_size	= 256,
+		.page_size	= 256,
+		.tested		= TEST_UNTESTED,
+		.probe		= probe_spi_rdid,
+		.erase		= NULL,
+		.write		= NULL,
+		.read		= spi_chip_read,
 	},
 
-	{"Atmel", "AT25DF041A", ATMEL_ID, AT_25DF041A,
-	 512, 256,
-	 TEST_UNTESTED,
-	 probe_spi_rdid, NULL, NULL, spi_chip_read
+	{
+		.vendor		= "Atmel",
+		.name		= "AT25DF041A",
+		.manufacture_id	= ATMEL_ID,
+		.model_id	= AT_25DF041A,
+		.total_size	= 512,
+		.page_size	= 256,
+		.tested		= TEST_UNTESTED,
+		.probe		= probe_spi_rdid,
+		.erase		= NULL,
+		.write		= NULL,
+		.read		= spi_chip_read,
 	},
 
-	{"Atmel", "AT25DF081", ATMEL_ID, AT_25DF081,
-	 1024, 256,
-	 TEST_UNTESTED,
-	 probe_spi_rdid, NULL, NULL, spi_chip_read
+	{
+		.vendor		= "Atmel",
+		.name		= "AT25DF081",
+		.manufacture_id	= ATMEL_ID,
+		.model_id	= AT_25DF081,
+		.total_size	= 1024,
+		.page_size	= 256,
+		.tested		= TEST_UNTESTED,
+		.probe		= probe_spi_rdid,
+		.erase		= NULL,
+		.write		= NULL,
+		.read		= spi_chip_read,
 	},
 
-	{"Atmel", "AT25DF161", ATMEL_ID, AT_25DF161,
-	 2048, 256,
-	 TEST_UNTESTED,
-	 probe_spi_rdid, NULL, NULL, spi_chip_read
+	{
+		.vendor		= "Atmel",
+		.name		= "AT25DF161",
+		.manufacture_id	= ATMEL_ID,
+		.model_id	= AT_25DF161,
+		.total_size	= 2048,
+		.page_size	= 256,
+		.tested		= TEST_UNTESTED,
+		.probe		= probe_spi_rdid,
+		.erase		= NULL,
+		.write		= NULL,
+		.read		= spi_chip_read,
 	},
 
-	{"Atmel", "AT25DF321", ATMEL_ID, AT_25DF321,
-	 4096, 256,
-	 TEST_OK_PREW,
-	 probe_spi_rdid, spi_chip_erase_c7, spi_chip_write, spi_chip_read
+	{
+		.vendor		= "Atmel",
+		.name		= "AT25DF321",
+		.manufacture_id	= ATMEL_ID,
+		.model_id	= AT_25DF321,
+		.total_size	= 4096,
+		.page_size	= 256,
+		.tested		= TEST_OK_PREW,
+		.probe		= probe_spi_rdid,
+		.erase		= spi_chip_erase_c7,
+		.write		= spi_chip_write,
+		.read		= spi_chip_read,
 	},
 
-	{"Atmel", "AT25DF321A", ATMEL_ID, AT_25DF321A,
-	 4096, 256,
-	 TEST_UNTESTED,
-	 probe_spi_rdid, NULL, NULL, spi_chip_read
+	{
+		.vendor		= "Atmel",
+		.name		= "AT25DF321A",
+		.manufacture_id	= ATMEL_ID,
+		.model_id	= AT_25DF321A,
+		.total_size	= 4096,
+		.page_size	= 256,
+		.tested		= TEST_UNTESTED,
+		.probe		= probe_spi_rdid,
+		.erase		= NULL,
+		.write		= NULL,
+		.read		= spi_chip_read,
 	},
 
-	{"Atmel", "AT25DF641", ATMEL_ID, AT_25DF641,
-	 8192, 256,
-	 TEST_UNTESTED,
-	 probe_spi_rdid, NULL, NULL, spi_chip_read
+	{
+		.vendor		= "Atmel",
+		.name		= "AT25DF641",
+		.manufacture_id	= ATMEL_ID,
+		.model_id	= AT_25DF641,
+		.total_size	= 8192,
+		.page_size	= 256,
+		.tested		= TEST_UNTESTED,
+		.probe		= probe_spi_rdid,
+		.erase		= NULL,
+		.write		= NULL,
+		.read		= spi_chip_read,
 	},
 
-	{"Atmel", "AT25F512B", ATMEL_ID, AT_25F512B,
-	 64, 256,
-	 TEST_UNTESTED,
-	 probe_spi_rdid, NULL, NULL, spi_chip_read
+	{
+		.vendor		= "Atmel",
+		.name		= "AT25F512B",
+		.manufacture_id	= ATMEL_ID,
+		.model_id	= AT_25F512B,
+		.total_size	= 64,
+		.page_size	= 256,
+		.tested		= TEST_UNTESTED,
+		.probe		= probe_spi_rdid,
+		.erase		= NULL,
+		.write		= NULL,
+		.read		= spi_chip_read,
 	},
 
-	{"Atmel", "AT25FS010", ATMEL_ID, AT_25FS010,
-	 128, 256,
-	 TEST_UNTESTED,
-	 probe_spi_rdid, NULL, NULL, spi_chip_read
+	{
+		.vendor		= "Atmel",
+		.name		= "AT25FS010",
+		.manufacture_id	= ATMEL_ID,
+		.model_id	= AT_25FS010,
+		.total_size	= 128,
+		.page_size	= 256,
+		.tested		= TEST_UNTESTED,
+		.probe		= probe_spi_rdid,
+		.erase		= NULL,
+		.write		= NULL,
+		.read		= spi_chip_read,
 	},
 
-	{"Atmel", "AT25FS040", ATMEL_ID, AT_25FS040,
-	 512, 256,
-	 TEST_UNTESTED,
-	 probe_spi_rdid, NULL, NULL, spi_chip_read
+	{
+		.vendor		= "Atmel",
+		.name		= "AT25FS040",
+		.manufacture_id	= ATMEL_ID,
+		.model_id	= AT_25FS040,
+		.total_size	= 512,
+		.page_size	= 256,
+		.tested		= TEST_UNTESTED,
+		.probe		= probe_spi_rdid,
+		.erase		= NULL,
+		.write		= NULL,
+		.read		= spi_chip_read,
 	},
 
-	{"Atmel", "AT26DF041", ATMEL_ID, AT_26DF041,
-	 512, 256,
-	 TEST_UNTESTED,
-	 probe_spi_rdid, NULL, NULL /* Incompatible Page write */,spi_chip_read
+	{
+		.vendor		= "Atmel",
+		.name		= "AT26DF041",
+		.manufacture_id	= ATMEL_ID,
+		.model_id	= AT_26DF041,
+		.total_size	= 512,
+		.page_size	= 256,
+		.tested		= TEST_UNTESTED,
+		.probe		= probe_spi_rdid,
+		.erase		= NULL,
+		.write		= NULL /* Incompatible Page write */,
+		.read		= spi_chip_read,
 	},
 
-	{"Atmel", "AT26DF081A", ATMEL_ID, AT_26DF081A,
-	 1024, 256,
-	 TEST_UNTESTED,
-	 probe_spi_rdid, NULL, NULL, spi_chip_read
+	{
+		.vendor		= "Atmel",
+		.name		= "AT26DF081A",
+		.manufacture_id	= ATMEL_ID,
+		.model_id	= AT_26DF081A,
+		.total_size	= 1024,
+		.page_size	= 256,
+		.tested		= TEST_UNTESTED,
+		.probe		= probe_spi_rdid,
+		.erase		= NULL,
+		.write		= NULL,
+		.read		= spi_chip_read,
 	},
 
-	{"Atmel", "AT26DF161", ATMEL_ID, AT_26DF161,
-	 2048, 256,
-	 TEST_UNTESTED,
-	 probe_spi_rdid, NULL, NULL, spi_chip_read
+	{
+		.vendor		= "Atmel",
+		.name		= "AT26DF161",
+		.manufacture_id	= ATMEL_ID,
+		.model_id	= AT_26DF161,
+		.total_size	= 2048,
+		.page_size	= 256,
+		.tested		= TEST_UNTESTED,
+		.probe		= probe_spi_rdid,
+		.erase		= NULL,
+		.write		= NULL,
+		.read		= spi_chip_read,
 	},
 
-	{"Atmel", "AT26DF161A", ATMEL_ID, AT_26DF161A,
-	 2048, 256,
-	 TEST_UNTESTED,
-	 probe_spi_rdid, NULL, NULL, spi_chip_read
+	{
+		.vendor		= "Atmel",
+		.name		= "AT26DF161A",
+		.manufacture_id	= ATMEL_ID,
+		.model_id	= AT_26DF161A,
+		.total_size	= 2048,
+		.page_size	= 256,
+		.tested		= TEST_UNTESTED,
+		.probe		= probe_spi_rdid,
+		.erase		= NULL,
+		.write		= NULL,
+		.read		= spi_chip_read,
 	},
 
 	/*The AT26DF321 has the same ID as the AT25DF321. */
-	/*{"Atmel", "AT26DF321", ATMEL_ID, AT_26DF321,
-	  4096, 256,
-	  TEST_UNTESTED,
-	  probe_spi_rdid, NULL, NULL, spi_chip_read
-	  },
-	*/
+	/*{
+		.vendor		= "Atmel",
+		.name		= "AT26DF321",
+		.manufacture_id	= ATMEL_ID,
+		.model_id	= AT_26DF321,
+		.total_size	= 4096,
+		.page_size	= 256,
+		.tested		= TEST_UNTESTED,
+		.probe		= probe_spi_rdid,
+		.erase		= spi_chip_erase_c7,
+		.write		= spi_chip_write,
+		.read		= spi_chip_read,
+	  },*/
 
-	{"Atmel", "AT26F004", ATMEL_ID, AT_26F004,
-	 512, 256,
-	 TEST_UNTESTED,
-	 probe_spi_rdid, NULL, NULL /* Incompatible Page write */,spi_chip_read
+	{
+		.vendor		= "Atmel",
+		.name		= "AT26F004",
+		.manufacture_id	= ATMEL_ID,
+		.model_id	= AT_26F004,
+		.total_size	= 512,
+		.page_size	= 256,
+		.tested		= TEST_UNTESTED,
+		.probe		= probe_spi_rdid,
+		.erase		= NULL,
+		.write		= NULL /* Incompatible Page write */,
+		.read		= spi_chip_read,
 	},
 
-	{"Atmel", "AT29C020", ATMEL_ID, AT_29C020,
-	 256, 256,
-	 TEST_OK_PREW,
-	 probe_jedec, erase_chip_jedec, write_jedec
+	{
+		.vendor		= "Atmel",
+		.name		= "AT29C020",
+		.manufacture_id	= ATMEL_ID,
+		.model_id	= AT_29C020,
+		.total_size	= 256,
+		.page_size	= 256,
+		.tested		= TEST_OK_PREW,
+		.probe		= probe_jedec,
+		.erase		= erase_chip_jedec,
+		.write		= write_jedec,
 	},
 
-	{"Atmel", "AT29C040A", ATMEL_ID, AT_29C040A,
-	 512, 256,
-	 TEST_UNTESTED,
-	 probe_jedec, erase_chip_jedec, write_jedec
+	{
+		.vendor		= "Atmel",
+		.name		= "AT29C040A",
+		.manufacture_id	= ATMEL_ID,
+		.model_id	= AT_29C040A,
+		.total_size	= 512,
+		.page_size	= 256,
+		.tested		= TEST_UNTESTED,
+		.probe		= probe_jedec,
+		.erase		= erase_chip_jedec,
+		.write		= write_jedec,
 	},
 
-	{"Atmel", "AT45CS1282", ATMEL_ID, AT_45CS1282,
-	 16896/*!*/, 1056/*!*/,
-	 TEST_BAD_READ,
-	 probe_spi_rdid, NULL, NULL /* Incompatible Page write */, NULL /* Incompatible read */
+	{
+		.vendor		= "Atmel",
+		.name		= "AT45CS1282",
+		.manufacture_id	= ATMEL_ID,
+		.model_id	= AT_45CS1282,
+		.total_size	= 16896/*!*/,
+		.page_size	= 1056/*!*/,
+		.tested		= TEST_BAD_READ,
+		.probe		= probe_spi_rdid,
+		.erase		= NULL,
+		.write		= NULL /* Incompatible Page write */,
+		.read		= NULL /* Incompatible read */,
 	}, /* No power of two sizes */
 
-	{"Atmel", "AT45DB011D", ATMEL_ID, AT_45DB011D,
-	 128/*!*/, 256/*!*/,
-	 TEST_BAD_READ,
-	 probe_spi_rdid, NULL, NULL, NULL
+	{
+		.vendor		= "Atmel",
+		.name		= "AT45DB011D",
+		.manufacture_id	= ATMEL_ID,
+		.model_id	= AT_45DB011D,
+		.total_size	= 128/*!*/,
+		.page_size	= 256/*!*/,
+		.tested		= TEST_BAD_READ,
+		.probe		= probe_spi_rdid,
+		.erase		= NULL,
+		.write		= NULL,
+		.read		= NULL,
 	}, /* Size can only be determined from status register */
 
-	{"Atmel", "AT45DB021D", ATMEL_ID, AT_45DB021D,
-	 256/*!*/, 256/*!*/,
-	 TEST_BAD_READ,
-	 probe_spi_rdid, NULL, NULL, NULL
+	{
+		.vendor		= "Atmel",
+		.name		= "AT45DB021D",
+		.manufacture_id	= ATMEL_ID,
+		.model_id	= AT_45DB021D,
+		.total_size	= 256/*!*/,
+		.page_size	= 256/*!*/,
+		.tested		= TEST_BAD_READ,
+		.probe		= probe_spi_rdid,
+		.erase		= NULL,
+		.write		= NULL,
+		.read		= NULL,
 	}, /* Size can only be determined from status register */
 
-	{"Atmel", "AT45DB041D", ATMEL_ID, AT_45DB041D,
-	 512/*!*/, 256/*!*/,
-	 TEST_BAD_READ,
-	 probe_spi_rdid, NULL, NULL, NULL
+	{
+		.vendor		= "Atmel",
+		.name		= "AT45DB041D",
+		.manufacture_id	= ATMEL_ID,
+		.model_id	= AT_45DB041D,
+		.total_size	= 512/*!*/,
+		.page_size	= 256/*!*/,
+		.tested		= TEST_BAD_READ,
+		.probe		= probe_spi_rdid,
+		.erase		= NULL,
+		.write		= NULL,
+		.read		= NULL,
 	}, /* Size can only be determined from status register */
 
-	{"Atmel", "AT45DB081D", ATMEL_ID, AT_45DB081D,
-	 1024/*!*/, 256/*!*/,
-	 TEST_BAD_READ,
-	 probe_spi_rdid, NULL, NULL, NULL
+	{
+		.vendor		= "Atmel",
+		.name		= "AT45DB081D",
+		.manufacture_id	= ATMEL_ID,
+		.model_id	= AT_45DB081D,
+		.total_size	= 1024/*!*/,
+		.page_size	= 256/*!*/,
+		.tested		= TEST_BAD_READ,
+		.probe		= probe_spi_rdid,
+		.erase		= NULL,
+		.write		= NULL,
+		.read		= NULL,
 	}, /* Size can only be determined from status register */
 
-	{"Atmel", "AT45DB161D", ATMEL_ID, AT_45DB161D,
-	 2048/*!*/, 512/*!*/,
-	 TEST_BAD_READ,
-	 probe_spi_rdid, NULL, NULL, NULL
+	{
+		.vendor		= "Atmel",
+		.name		= "AT45DB161D",
+		.manufacture_id	= ATMEL_ID,
+		.model_id	= AT_45DB161D,
+		.total_size	= 2048/*!*/,
+		.page_size	= 512/*!*/,
+		.tested		= TEST_BAD_READ,
+		.probe		= probe_spi_rdid,
+		.erase		= NULL,
+		.write		= NULL,
+		.read		= NULL,
 	}, /* Size can only be determined from status register */
 
-	{"Atmel", "AT45DB321C", ATMEL_ID, AT_45DB321C,
-	 4224/*!*/, 528/*!*/,
-	 TEST_BAD_READ,
-	 probe_spi_rdid, NULL, NULL, NULL /* Incompatible read */
+	{
+		.vendor		= "Atmel",
+		.name		= "AT45DB321C",
+		.manufacture_id	= ATMEL_ID,
+		.model_id	= AT_45DB321C,
+		.total_size	= 4224/*!*/,
+		.page_size	= 528/*!*/,
+		.tested		= TEST_BAD_READ,
+		.probe		= probe_spi_rdid,
+		.erase		= NULL,
+		.write		= NULL,
+		.read		= NULL /* Incompatible read */,
 	}, /* No power of two sizes */
 
-	{"Atmel", "AT45DB321D", ATMEL_ID, AT_45DB321D,
-	 4096/*!*/, 512/*!*/,
-	 TEST_BAD_READ,
-	 probe_spi_rdid, NULL, NULL, NULL
+	{
+		.vendor		= "Atmel",
+		.name		= "AT45DB321D",
+		.manufacture_id	= ATMEL_ID,
+		.model_id	= AT_45DB321D,
+		.total_size	= 4096/*!*/,
+		.page_size	= 512/*!*/,
+		.tested		= TEST_BAD_READ,
+		.probe		= probe_spi_rdid,
+		.erase		= NULL,
+		.write		= NULL,
+		.read		= NULL,
 	}, /* Size can only be determined from status register */
 
-	{"Atmel", "AT45DB642D", ATMEL_ID, AT_45DB642D,
-	 8192/*!*/, 1024/*!*/,
-	 TEST_BAD_READ,
-	 probe_spi_rdid, NULL, NULL, NULL
+	{
+		.vendor		= "Atmel",
+		.name		= "AT45DB642D",
+		.manufacture_id	= ATMEL_ID,
+		.model_id	= AT_45DB642D,
+		.total_size	= 8192/*!*/,
+		.page_size	= 1024/*!*/,
+		.tested		= TEST_BAD_READ,
+		.probe		= probe_spi_rdid,
+		.erase		= NULL,
+		.write		= NULL,
+		.read		= NULL,
 	}, /* Size can only be determined from status register */
 
-	{"Atmel", "AT49F002(N)", ATMEL_ID, AT_49F002N,
-	 256, 256,
-	 TEST_UNTESTED,
-	 probe_jedec, erase_chip_jedec, write_49f002
+	{
+		.vendor		= "Atmel",
+		.name		= "AT49F002(N)",
+		.manufacture_id	= ATMEL_ID,
+		.model_id	= AT_49F002N,
+		.total_size	= 256,
+		.page_size	= 256,
+		.tested		= TEST_UNTESTED,
+		.probe		= probe_jedec,
+		.erase		= erase_chip_jedec,
+		.write		= write_49f002,
 	},
 
-	{"Atmel", "AT49F002(N)T", ATMEL_ID, AT_49F002NT,
-	 256, 256,
-	 TEST_OK_PREW,
-	 probe_jedec, erase_chip_jedec, write_49f002
+	{
+		.vendor		= "Atmel",
+		.name		= "AT49F002(N)T",
+		.manufacture_id	= ATMEL_ID,
+		.model_id	= AT_49F002NT,
+		.total_size	= 256,
+		.page_size	= 256,
+		.tested		= TEST_OK_PREW,
+		.probe		= probe_jedec,
+		.erase		= erase_chip_jedec,
+		.write		= write_49f002,
 	},
 
-	{"AMIC", "A25L40P", AMIC_ID, AMIC_A25L40P,
-	 512, 256,
-	 TEST_OK_PREW,
-	 probe_spi_rdid4, spi_chip_erase_c7, spi_chip_write, spi_chip_read
+	{
+		.vendor		= "AMIC",
+		.name		= "A25L40P",
+		.manufacture_id	= AMIC_ID,
+		.model_id	= AMIC_A25L40P,
+		.total_size	= 512,
+		.page_size	= 256,
+		.tested		= TEST_OK_PREW,
+		.probe		= probe_spi_rdid4,
+		.erase		= spi_chip_erase_c7,
+		.write		= spi_chip_write,
+		.read		= spi_chip_read,
 	},
 
-	{"AMIC", "A29002B", AMIC_ID_NOPREFIX, AMIC_A29002B,
-	 256, 64 * 1024,
-	 TEST_UNTESTED,
-	 probe_29f002, erase_29f002, write_29f002
+	{
+		.vendor		= "AMIC",
+		.name		= "A29002B",
+		.manufacture_id	= AMIC_ID_NOPREFIX,
+		.model_id	= AMIC_A29002B,
+		.total_size	= 256,
+		.page_size	= 64 * 1024,
+		.tested		= TEST_UNTESTED,
+		.probe		= probe_29f002,
+		.erase		= erase_29f002,
+		.write		= write_29f002,
 	},
 
-	{"AMIC", "A29002T", AMIC_ID_NOPREFIX, AMIC_A29002T,
-	 256, 64 * 1024,
-	 TEST_OK_PREW,
-	 probe_29f002, erase_29f002, write_29f002
+	{
+		.vendor		= "AMIC",
+		.name		= "A29002T",
+		.manufacture_id	= AMIC_ID_NOPREFIX,
+		.model_id	= AMIC_A29002T,
+		.total_size	= 256,
+		.page_size	= 64 * 1024,
+		.tested		= TEST_OK_PREW,
+		.probe		= probe_29f002,
+		.erase		= erase_29f002,
+		.write		= write_29f002,
 	},
 
-	{"AMIC", "A29040B", AMIC_ID_NOPREFIX, AMIC_A29040B,
-	 512, 64 * 1024,
-	 TEST_OK_PR,
-	 probe_29f040b, erase_29f040b, write_29f040b
+	{
+		.vendor		= "AMIC",
+		.name		= "A29040B",
+		.manufacture_id	= AMIC_ID_NOPREFIX,
+		.model_id	= AMIC_A29040B,
+		.total_size	= 512,
+		.page_size	= 64 * 1024,
+		.tested		= TEST_OK_PR,
+		.probe		= probe_29f040b,
+		.erase		= erase_29f040b,
+		.write		= write_29f040b,
 	},
 
-	{"AMIC", "A49LF040A", AMIC_ID_NOPREFIX, AMIC_A49LF040A,
-	 512, 64 * 1024,
-	 TEST_OK_PREW,
-	 probe_49fl00x, erase_49fl00x, write_49fl00x
+	{
+		.vendor		= "AMIC",
+		.name		= "A49LF040A",
+		.manufacture_id	= AMIC_ID_NOPREFIX,
+		.model_id	= AMIC_A49LF040A,
+		.total_size	= 512,
+		.page_size	= 64 * 1024,
+		.tested		= TEST_OK_PREW,
+		.probe		= probe_49fl00x,
+		.erase		= erase_49fl00x,
+		.write		= write_49fl00x,
 	},
 
-	{"EMST", "F49B002UA", EMST_ID, EMST_F49B002UA,
-	 256, 4096,
-	 TEST_UNTESTED,
-	 probe_jedec, erase_chip_jedec, write_49f002
+	{
+		.vendor		= "EMST",
+		.name		= "F49B002UA",
+		.manufacture_id	= EMST_ID,
+		.model_id	= EMST_F49B002UA,
+		.total_size	= 256,
+		.page_size	= 4096,
+		.tested		= TEST_UNTESTED,
+		.probe		= probe_jedec,
+		.erase		= erase_chip_jedec,
+		.write		= write_49f002,
 	},
 
-	{"EON", "EN29F002(A)(N)B", EON_ID, EN_29F002B,
-	 256, 256,
-	 TEST_UNTESTED,
-	 probe_jedec, erase_chip_jedec, write_en29f002a
+	{
+		.vendor		= "EON",
+		.name		= "EN29F002(A)(N)B",
+		.manufacture_id	= EON_ID,
+		.model_id	= EN_29F002B,
+		.total_size	= 256,
+		.page_size	= 256,
+		.tested		= TEST_UNTESTED,
+		.probe		= probe_jedec,
+		.erase		= erase_chip_jedec,
+		.write		= write_en29f002a,
 	},
 
-	{"EON", "EN29F002(A)(N)T", EON_ID, EN_29F002T,
-	 256, 256,
-	 TEST_OK_PREW,
-	 probe_jedec, erase_chip_jedec, write_en29f002a
+	{
+		.vendor		= "EON",
+		.name		= "EN29F002(A)(N)T",
+		.manufacture_id	= EON_ID,
+		.model_id	= EN_29F002T,
+		.total_size	= 256,
+		.page_size	= 256,
+		.tested		= TEST_OK_PREW,
+		.probe		= probe_jedec,
+		.erase		= erase_chip_jedec,
+		.write		= write_en29f002a,
 	},
 
-	{"Fujitsu", "MBM29F004BC", FUJITSU_ID, MBM29F004BC,
-	 512, 64 * 1024,
-	 TEST_UNTESTED,
-	 probe_jedec, NULL, NULL
+	{
+		.vendor		= "Fujitsu",
+		.name		= "MBM29F004BC",
+		.manufacture_id	= FUJITSU_ID,
+		.model_id	= MBM29F004BC,
+		.total_size	= 512,
+		.page_size	= 64 * 1024,
+		.tested		= TEST_UNTESTED,
+		.probe		= probe_jedec,
+		.erase		= NULL,
+		.write		= NULL,
 	},
 
-	{"Fujitsu", "MBM29F004TC", FUJITSU_ID, MBM29F004TC,
-	 512, 64 * 1024,
-	 TEST_UNTESTED,
-	 probe_jedec, NULL, NULL
+	{
+		.vendor		= "Fujitsu",
+		.name		= "MBM29F004TC",
+		.manufacture_id	= FUJITSU_ID,
+		.model_id	= MBM29F004TC,
+		.total_size	= 512,
+		.page_size	= 64 * 1024,
+		.tested		= TEST_UNTESTED,
+		.probe		= probe_jedec,
+		.erase		= NULL,
+		.write		= NULL,
 	},
 
-	{"Fujitsu", "MBM29F400BC", FUJITSU_ID, MBM29F400BC,
-	 512, 64 * 1024,
-	 TEST_UNTESTED,
-	 probe_m29f400bt, erase_m29f400bt, write_coreboot_m29f400bt
+	{
+		.vendor		= "Fujitsu",
+		.name		= "MBM29F400BC",
+		.manufacture_id	= FUJITSU_ID,
+		.model_id	= MBM29F400BC,
+		.total_size	= 512,
+		.page_size	= 64 * 1024,
+		.tested		= TEST_UNTESTED,
+		.probe		= probe_m29f400bt,
+		.erase		= erase_m29f400bt,
+		.write		= write_coreboot_m29f400bt,
 	},
 
-	{"Fujitsu", "MBM29F400TC", FUJITSU_ID, MBM29F400TC,
-	 512, 64 * 1024,
-	 TEST_UNTESTED,
-	 probe_m29f400bt, erase_m29f400bt, write_coreboot_m29f400bt
+	{
+		.vendor		= "Fujitsu",
+		.name		= "MBM29F400TC",
+		.manufacture_id	= FUJITSU_ID,
+		.model_id	= MBM29F400TC,
+		.total_size	= 512,
+		.page_size	= 64 * 1024,
+		.tested		= TEST_UNTESTED,
+		.probe		= probe_m29f400bt,
+		.erase		= erase_m29f400bt,
+		.write		= write_coreboot_m29f400bt,
 	},
 
-	{"Intel", "82802AB", INTEL_ID, 173,
-	 512, 64 * 1024,
-	 TEST_OK_PREW,
-	 probe_82802ab, erase_82802ab, write_82802ab
+	{
+		.vendor		= "Intel",
+		.name		= "82802AB",
+		.manufacture_id	= INTEL_ID,
+		.model_id	= 173,
+		.total_size	= 512,
+		.page_size	= 64 * 1024,
+		.tested		= TEST_OK_PREW,
+		.probe		= probe_82802ab,
+		.erase		= erase_82802ab,
+		.write		= write_82802ab,
 	},
 
-	{"Intel", "82802AC", INTEL_ID, 172,
-	 1024, 64 * 1024,
-	 TEST_OK_PREW,
-	 probe_82802ab, erase_82802ab, write_82802ab
+	{
+		.vendor		= "Intel",
+		.name		= "82802AC",
+		.manufacture_id	= INTEL_ID,
+		.model_id	= 172,
+		.total_size	= 1024,
+		.page_size	= 64 * 1024,
+		.tested		= TEST_OK_PREW,
+		.probe		= probe_82802ab,
+		.erase		= erase_82802ab,
+		.write		= write_82802ab,
 	},
 
-	{"Macronix", "MX25L512", MX_ID, MX_25L512,
-	 64, 256,
-	 TEST_UNTESTED,
-	 probe_spi_rdid, spi_chip_erase_c7, spi_chip_write, spi_chip_read
+	{
+		.vendor		= "Macronix",
+		.name		= "MX25L512",
+		.manufacture_id	= MX_ID,
+		.model_id	= MX_25L512,
+		.total_size	= 64,
+		.page_size	= 256,
+		.tested		= TEST_UNTESTED,
+		.probe		= probe_spi_rdid,
+		.erase		= spi_chip_erase_c7,
+		.write		= spi_chip_write,
+		.read		= spi_chip_read,
 	},
 
-	{"Macronix", "MX25L1005", MX_ID, MX_25L1005,
-	 128, 256,
-	 TEST_UNTESTED,
-	 probe_spi_rdid, spi_chip_erase_c7, spi_chip_write, spi_chip_read
+	{
+		.vendor		= "Macronix",
+		.name		= "MX25L1005",
+		.manufacture_id	= MX_ID,
+		.model_id	= MX_25L1005,
+		.total_size	= 128,
+		.page_size	= 256,
+		.tested		= TEST_UNTESTED,
+		.probe		= probe_spi_rdid,
+		.erase		= spi_chip_erase_c7,
+		.write		= spi_chip_write,
+		.read		= spi_chip_read,
 	},
 
-	{"Macronix", "MX25L2005", MX_ID, MX_25L2005,
-	 256, 256,
-	 TEST_UNTESTED,
-	 probe_spi_rdid, spi_chip_erase_c7, spi_chip_write, spi_chip_read
+	{
+		.vendor		= "Macronix",
+		.name		= "MX25L2005",
+		.manufacture_id	= MX_ID,
+		.model_id	= MX_25L2005,
+		.total_size	= 256,
+		.page_size	= 256,
+		.tested		= TEST_UNTESTED,
+		.probe		= probe_spi_rdid,
+		.erase		= spi_chip_erase_c7,
+		.write		= spi_chip_write,
+		.read		= spi_chip_read,
 	},
 
-	{"Macronix", "MX25L4005", MX_ID, MX_25L4005,
-	 512, 256,
-	 TEST_OK_PREW,
-	 probe_spi_rdid, spi_chip_erase_c7, spi_chip_write, spi_chip_read
+	{
+		.vendor		= "Macronix",
+		.name		= "MX25L4005",
+		.manufacture_id	= MX_ID,
+		.model_id	= MX_25L4005,
+		.total_size	= 512,
+		.page_size	= 256,
+		.tested		= TEST_OK_PREW,
+		.probe		= probe_spi_rdid,
+		.erase		= spi_chip_erase_c7,
+		.write		= spi_chip_write,
+		.read		= spi_chip_read,
 	},
 
-	{"Macronix", "MX25L8005", MX_ID, MX_25L8005,
-	 1024, 256,
-	 TEST_OK_PREW,
-	 probe_spi_rdid, spi_chip_erase_c7, spi_chip_write, spi_chip_read
+	{
+		.vendor		= "Macronix",
+		.name		= "MX25L8005",
+		.manufacture_id	= MX_ID,
+		.model_id	= MX_25L8005,
+		.total_size	= 1024,
+		.page_size	= 256,
+		.tested		= TEST_OK_PREW,
+		.probe		= probe_spi_rdid,
+		.erase		= spi_chip_erase_c7,
+		.write		= spi_chip_write,
+		.read		= spi_chip_read,
 	},
 
-	{"Macronix", "MX25L1605", MX_ID, MX_25L1605,
-	 2048, 256,
-	 TEST_UNTESTED,
-	 probe_spi_rdid, spi_chip_erase_c7, spi_chip_write, spi_chip_read
+	{
+		.vendor		= "Macronix",
+		.name		= "MX25L1605",
+		.manufacture_id	= MX_ID,
+		.model_id	= MX_25L1605,
+		.total_size	= 2048,
+		.page_size	= 256,
+		.tested		= TEST_UNTESTED,
+		.probe		= probe_spi_rdid,
+		.erase		= spi_chip_erase_c7,
+		.write		= spi_chip_write,
+		.read		= spi_chip_read,
 	},
 
-	{"Macronix", "MX25L3205", MX_ID, MX_25L3205,
-	 4096, 256,
-	 TEST_OK_PREW,
-	 probe_spi_rdid, spi_chip_erase_c7, spi_chip_write, spi_chip_read
+	{
+		.vendor		= "Macronix",
+		.name		= "MX25L3205",
+		.manufacture_id	= MX_ID,
+		.model_id	= MX_25L3205,
+		.total_size	= 4096,
+		.page_size	= 256,
+		.tested		= TEST_OK_PREW,
+		.probe		= probe_spi_rdid,
+		.erase		= spi_chip_erase_c7,
+		.write		= spi_chip_write,
+		.read		= spi_chip_read,
 	},
 
-	{"Macronix", "MX25L6405", MX_ID, MX_25L6405,
-	 8192, 256,
-	 TEST_UNTESTED,
-	 probe_spi_rdid, spi_chip_erase_c7, spi_chip_write, spi_chip_read
+	{
+		.vendor		= "Macronix",
+		.name		= "MX25L6405",
+		.manufacture_id	= MX_ID,
+		.model_id	= MX_25L6405,
+		.total_size	= 8192,
+		.page_size	= 256,
+		.tested		= TEST_UNTESTED,
+		.probe		= probe_spi_rdid,
+		.erase		= spi_chip_erase_c7,
+		.write		= spi_chip_write,
+		.read		= spi_chip_read,
 	},
 
-	{"Macronix", "MX29F002B", MX_ID, MX_29F002B,
-	 256, 64 * 1024,
-	 TEST_UNTESTED,
-	 probe_29f002, erase_29f002, write_29f002
+	{
+		.vendor		= "Macronix",
+		.name		= "MX29F002B",
+		.manufacture_id	= MX_ID,
+		.model_id	= MX_29F002B,
+		.total_size	= 256,
+		.page_size	= 64 * 1024,
+		.tested		= TEST_UNTESTED,
+		.probe		= probe_29f002,
+		.erase		= erase_29f002,
+		.write		= write_29f002,
 	},
 
-	{"Macronix", "MX29F002T", MX_ID, MX_29F002T,
-	 256, 64 * 1024,
-	 TEST_UNTESTED,
-	 probe_29f002, erase_29f002, write_29f002
+	{
+		.vendor		= "Macronix",
+		.name		= "MX29F002T",
+		.manufacture_id	= MX_ID,
+		.model_id	= MX_29F002T,
+		.total_size	= 256,
+		.page_size	= 64 * 1024,
+		.tested		= TEST_UNTESTED,
+		.probe		= probe_29f002,
+		.erase		= erase_29f002,
+		.write		= write_29f002,
 	},
 
-	{"Macronix", "MX29LV040C", MX_ID, MX_29LV040C,
-	 512, 64 * 1024,
-	 TEST_OK_PR,
-	 probe_29f002, erase_29f002, write_29f002
+	{
+		.vendor		= "Macronix",
+		.name		= "MX29LV040C",
+		.manufacture_id	= MX_ID,
+		.model_id	= MX_29LV040C,
+		.total_size	= 512,
+		.page_size	= 64 * 1024,
+		.tested		= TEST_OK_PR,
+		.probe		= probe_29f002,
+		.erase		= erase_29f002,
+		.write		= write_29f002,
 	},
 
-	{"Numonyx", "M25PE10", ST_ID, 0x8011,
-	 128, 256,
-	 TEST_UNTESTED,
-	 probe_spi_rdid, spi_chip_erase_d8, spi_chip_write, spi_chip_read
+	{
+		.vendor		= "Numonyx",
+		.name		= "M25PE10",
+		.manufacture_id	= ST_ID,
+		.model_id	= 0x8011,
+		.total_size	= 128,
+		.page_size	= 256,
+		.tested		= TEST_UNTESTED,
+		.probe		= probe_spi_rdid,
+		.erase		= spi_chip_erase_d8,
+		.write		= spi_chip_write,
+		.read		= spi_chip_read,
 	},
 
-	{"Numonyx", "M25PE20", ST_ID, 0x8012,
-	 256, 256,
-	 TEST_UNTESTED,
-	 probe_spi_rdid, spi_chip_erase_d8, spi_chip_write, spi_chip_read
+	{
+		.vendor		= "Numonyx",
+		.name		= "M25PE20",
+		.manufacture_id	= ST_ID,
+		.model_id	= 0x8012,
+		.total_size	= 256,
+		.page_size	= 256,
+		.tested		= TEST_UNTESTED,
+		.probe		= probe_spi_rdid,
+		.erase		= spi_chip_erase_d8,
+		.write		= spi_chip_write,
+		.read		= spi_chip_read,
 	},
 
-	{"Numonyx", "M25PE40", ST_ID, 0x8013,
-	 256, 256,
-	 TEST_UNTESTED,
-	 probe_spi_rdid, spi_chip_erase_d8, spi_chip_write, spi_chip_read
+	{
+		.vendor		= "Numonyx",
+		.name		= "M25PE40",
+		.manufacture_id	= ST_ID,
+		.model_id	= 0x8013,
+		.total_size	= 256,
+		.page_size	= 256,
+		.tested		= TEST_UNTESTED,
+		.probe		= probe_spi_rdid,
+		.erase		= spi_chip_erase_d8,
+		.write		= spi_chip_write,
+		.read		= spi_chip_read,
 	},
 
-	{"Numonyx", "M25PE80", ST_ID, 0x8014,
-	 1024, 256,
-	 TEST_OK_PREW,
-	 probe_spi_rdid, spi_chip_erase_d8, spi_chip_write, spi_chip_read
+	{
+		.vendor		= "Numonyx",
+		.name		= "M25PE80",
+		.manufacture_id	= ST_ID,
+		.model_id	= 0x8014,
+		.total_size	= 1024,
+		.page_size	= 256,
+		.tested		= TEST_OK_PREW,
+		.probe		= probe_spi_rdid,
+		.erase		= spi_chip_erase_d8,
+		.write		= spi_chip_write,
+		.read		= spi_chip_read,
 	},
 
-	{"Numonyx", "M25PE16", ST_ID, 0x8015,
-	 2048, 256,
-	 TEST_UNTESTED,
-	 probe_spi_rdid, spi_chip_erase_d8, spi_chip_write, spi_chip_read
+	{
+		.vendor		= "Numonyx",
+		.name		= "M25PE16",
+		.manufacture_id	= ST_ID,
+		.model_id	= 0x8015,
+		.total_size	= 2048,
+		.page_size	= 256,
+		.tested		= TEST_UNTESTED,
+		.probe		= probe_spi_rdid,
+		.erase		= spi_chip_erase_d8,
+		.write		= spi_chip_write,
+		.read		= spi_chip_read,
 	},
 
-	{"PMC", "Pm25LV010", PMC_ID, PMC_25LV010,
-	 128, 256,
-	 TEST_UNTESTED,
-	 probe_spi_rdid, spi_chip_erase_c7, spi_chip_write, spi_chip_read
+	{
+		.vendor		= "PMC",
+		.name		= "Pm25LV010",
+		.manufacture_id	= PMC_ID,
+		.model_id	= PMC_25LV010,
+		.total_size	= 128,
+		.page_size	= 256,
+		.tested		= TEST_UNTESTED,
+		.probe		= probe_spi_rdid,
+		.erase		= spi_chip_erase_c7,
+		.write		= spi_chip_write,
+		.read		= spi_chip_read,
 	},
 
-	{"PMC", "Pm25LV016B", PMC_ID, PMC_25LV016B,
-	 2048, 256,
-	 TEST_UNTESTED,
-	 probe_spi_rdid, spi_chip_erase_c7, spi_chip_write, spi_chip_read
+	{
+		.vendor		= "PMC",
+		.name		= "Pm25LV016B",
+		.manufacture_id	= PMC_ID,
+		.model_id	= PMC_25LV016B,
+		.total_size	= 2048,
+		.page_size	= 256,
+		.tested		= TEST_UNTESTED,
+		.probe		= probe_spi_rdid,
+		.erase		= spi_chip_erase_c7,
+		.write		= spi_chip_write,
+		.read		= spi_chip_read,
 	},
 
-	{"PMC", "Pm25LV020", PMC_ID, PMC_25LV020,
-	 256, 256,
-	 TEST_UNTESTED,
-	 probe_spi_rdid, spi_chip_erase_c7, spi_chip_write, spi_chip_read
+	{
+		.vendor		= "PMC",
+		.name		= "Pm25LV020",
+		.manufacture_id	= PMC_ID,
+		.model_id	= PMC_25LV020,
+		.total_size	= 256,
+		.page_size	= 256,
+		.tested		= TEST_UNTESTED,
+		.probe		= probe_spi_rdid,
+		.erase		= spi_chip_erase_c7,
+		.write		= spi_chip_write,
+		.read		= spi_chip_read,
 	},
 
-	{"PMC", "Pm25LV040", PMC_ID, PMC_25LV040,
-	 512, 256,
-	 TEST_UNTESTED,
-	 probe_spi_rdid, spi_chip_erase_c7, spi_chip_write, spi_chip_read
+	{
+		.vendor		= "PMC",
+		.name		= "Pm25LV040",
+		.manufacture_id	= PMC_ID,
+		.model_id	= PMC_25LV040,
+		.total_size	= 512,
+		.page_size	= 256,
+		.tested		= TEST_UNTESTED,
+		.probe		= probe_spi_rdid,
+		.erase		= spi_chip_erase_c7,
+		.write		= spi_chip_write,
+		.read		= spi_chip_read,
 	},
 
-	{"PMC", "Pm25LV080B", PMC_ID, PMC_25LV080B,
-	 1024, 256,
-	 TEST_UNTESTED,
-	 probe_spi_rdid, spi_chip_erase_c7, spi_chip_write, spi_chip_read
+	{
+		.vendor		= "PMC",
+		.name		= "Pm25LV080B",
+		.manufacture_id	= PMC_ID,
+		.model_id	= PMC_25LV080B,
+		.total_size	= 1024,
+		.page_size	= 256,
+		.tested		= TEST_UNTESTED,
+		.probe		= probe_spi_rdid,
+		.erase		= spi_chip_erase_c7,
+		.write		= spi_chip_write,
+		.read		= spi_chip_read,
 	},
 
-	{"PMC", "Pm25LV512", PMC_ID, PMC_25LV512,
-	 64, 256,
-	 TEST_UNTESTED,
-	 probe_spi_rdid, spi_chip_erase_c7, spi_chip_write, spi_chip_read
+	{
+		.vendor		= "PMC",
+		.name		= "Pm25LV512",
+		.manufacture_id	= PMC_ID,
+		.model_id	= PMC_25LV512,
+		.total_size	= 64,
+		.page_size	= 256,
+		.tested		= TEST_UNTESTED,
+		.probe		= probe_spi_rdid,
+		.erase		= spi_chip_erase_c7,
+		.write		= spi_chip_write,
+		.read		= spi_chip_read,
 	},
 
-	{"PMC", "Pm49FL002", PMC_ID_NOPREFIX, PMC_49FL002,
-	 256, 16 * 1024,
-	 TEST_OK_PREW,
-	 probe_49fl00x, erase_49fl00x, write_49fl00x
+	{
+		.vendor		= "PMC",
+		.name		= "Pm49FL002",
+		.manufacture_id	= PMC_ID_NOPREFIX,
+		.model_id	= PMC_49FL002,
+		.total_size	= 256,
+		.page_size	= 16 * 1024,
+		.tested		= TEST_OK_PREW,
+		.probe		= probe_49fl00x,
+		.erase		= erase_49fl00x,
+		.write		= write_49fl00x,
 	},
 
-	{"PMC", "Pm49FL004", PMC_ID_NOPREFIX,PMC_49FL004,
-	 512, 64 * 1024,
-	 TEST_OK_PREW,
-	 probe_49fl00x, erase_49fl00x, write_49fl00x
+	{
+		.vendor		= "PMC",
+		.name		= "Pm49FL004",
+		.manufacture_id	= PMC_ID_NOPREFIX,
+		.model_id	= PMC_49FL004,
+		.total_size	= 512,
+		.page_size	= 64 * 1024,
+		.tested		= TEST_OK_PREW,
+		.probe		= probe_49fl00x,
+		.erase		= erase_49fl00x,
+		.write		= write_49fl00x,
 	},
 
-	{"Sharp", "LHF00L04", SHARP_ID, SHARP_LHF00L04,
-	 1024, 64 * 1024,
-	 TEST_UNTESTED,
-	 probe_lhf00l04, erase_lhf00l04, write_lhf00l04
+	{
+		.vendor		= "Sharp",
+		.name		= "LHF00L04",
+		.manufacture_id	= SHARP_ID,
+		.model_id	= SHARP_LHF00L04,
+		.total_size	= 1024,
+		.page_size	= 64 * 1024,
+		.tested		= TEST_UNTESTED,
+		.probe		= probe_lhf00l04,
+		.erase		= erase_lhf00l04,
+		.write		= write_lhf00l04,
 	},
 
-	{"Spansion", "S25FL016A", SPANSION_ID, SPANSION_S25FL016A,
-	 2048, 256,
-	 TEST_OK_PREW,
-	 probe_spi_rdid, spi_chip_erase_c7, spi_chip_write, spi_chip_read
+	{
+		.vendor		= "Spansion",
+		.name		= "S25FL016A",
+		.manufacture_id	= SPANSION_ID,
+		.model_id	= SPANSION_S25FL016A,
+		.total_size	= 2048,
+		.page_size	= 256,
+		.tested		= TEST_OK_PREW,
+		.probe		= probe_spi_rdid,
+		.erase		= spi_chip_erase_c7,
+		.write		= spi_chip_write,
+		.read		= spi_chip_read,
 	},
 
-	{"SST", "SST25VF016B", SST_ID, SST_25VF016B,
-	 2048, 256,
-	 TEST_OK_PREW,
-	 probe_spi_rdid, spi_chip_erase_c7, spi_chip_write, spi_chip_read
+	{
+		.vendor		= "SST",
+		.name		= "SST25VF016B",
+		.manufacture_id	= SST_ID,
+		.model_id	= SST_25VF016B,
+		.total_size	= 2048,
+		.page_size	= 256,
+		.tested		= TEST_OK_PREW,
+		.probe		= probe_spi_rdid,
+		.erase		= spi_chip_erase_c7,
+		.write		= spi_chip_write,
+		.read		= spi_chip_read,
 	},
 
-	{"SST", "SST25VF032B", SST_ID, SST_25VF032B,
-	 4096, 256,
-	 TEST_OK_PREW,
-	 probe_spi_rdid, spi_chip_erase_c7, spi_chip_write, spi_chip_read
+	{
+		.vendor		= "SST",
+		.name		= "SST25VF032B",
+		.manufacture_id	= SST_ID,
+		.model_id	= SST_25VF032B,
+		.total_size	= 4096,
+		.page_size	= 256,
+		.tested		= TEST_OK_PREW,
+		.probe		= probe_spi_rdid,
+		.erase		= spi_chip_erase_c7,
+		.write		= spi_chip_write,
+		.read		= spi_chip_read,
 	},
 
-	{"SST", "SST25VF040B", SST_ID, SST_25VF040B,
-	 512, 256,
-	 TEST_UNTESTED,
-	 probe_spi_rdid, spi_chip_erase_c7, spi_chip_write, spi_chip_read
+	{
+		.vendor		= "SST",
+		.name		= "SST25VF040B",
+		.manufacture_id	= SST_ID,
+		.model_id	= SST_25VF040B,
+		.total_size	= 512,
+		.page_size	= 256,
+		.tested		= TEST_UNTESTED,
+		.probe		= probe_spi_rdid,
+		.erase		= spi_chip_erase_c7,
+		.write		= spi_chip_write,
+		.read		= spi_chip_read,
 	},
 
-	{"SST", "SST25VF080B", SST_ID, SST_25VF080B,
-	 1024, 256,
-	 TEST_UNTESTED,
-	 probe_spi_rdid, spi_chip_erase_60_c7, spi_chip_write, spi_chip_read
+	{
+		.vendor		= "SST",
+		.name		= "SST25VF080B",
+		.manufacture_id	= SST_ID,
+		.model_id	= SST_25VF080B,
+		.total_size	= 1024,
+		.page_size	= 256,
+		.tested		= TEST_UNTESTED,
+		.probe		= probe_spi_rdid,
+		.erase		= spi_chip_erase_60_c7,
+		.write		= spi_chip_write,
+		.read		= spi_chip_read,
 	},
 
-	{"SST", "SST28SF040A", SST_ID, SST_28SF040,
-	 512, 256,
-	 TEST_UNTESTED,
-	 probe_28sf040, erase_28sf040, write_28sf040
+	{
+		.vendor		= "SST",
+		.name		= "SST28SF040A",
+		.manufacture_id	= SST_ID,
+		.model_id	= SST_28SF040,
+		.total_size	= 512,
+		.page_size	= 256,
+		.tested		= TEST_UNTESTED,
+		.probe		= probe_28sf040,
+		.erase		= erase_28sf040,
+		.write		= write_28sf040,
 	},
 
-	{"SST", "SST29EE010", SST_ID, SST_29EE010,
-	 128, 128,
-	 TEST_OK_PREW,
-	 probe_jedec, erase_chip_jedec, write_jedec
+	{
+		.vendor		= "SST",
+		.name		= "SST29EE010",
+		.manufacture_id	= SST_ID,
+		.model_id	= SST_29EE010,
+		.total_size	= 128,
+		.page_size	= 128,
+		.tested		= TEST_OK_PREW,
+		.probe		= probe_jedec,
+		.erase		= erase_chip_jedec,
+		.write		= write_jedec,
 	},
 
-	{"SST", "SST29LE010", SST_ID, SST_29LE010,
-	 128, 128,
-	 TEST_UNTESTED,
-	 probe_jedec, erase_chip_jedec, write_jedec
+	{
+		.vendor		= "SST",
+		.name		= "SST29LE010",
+		.manufacture_id	= SST_ID,
+		.model_id	= SST_29LE010,
+		.total_size	= 128,
+		.page_size	= 128,
+		.tested		= TEST_UNTESTED,
+		.probe		= probe_jedec,
+		.erase		= erase_chip_jedec,
+		.write		= write_jedec,
 	},
 
-	{"SST", "SST29EE020A", SST_ID, SST_29EE020A,
-	 256, 128,
-	 TEST_UNTESTED,
-	 probe_jedec, erase_chip_jedec, write_jedec
+	{
+		.vendor		= "SST",
+		.name		= "SST29EE020A",
+		.manufacture_id	= SST_ID,
+		.model_id	= SST_29EE020A,
+		.total_size	= 256,
+		.page_size	= 128,
+		.tested		= TEST_UNTESTED,
+		.probe		= probe_jedec,
+		.erase		= erase_chip_jedec,
+		.write		= write_jedec,
 	},
 
-	{"SST", "SST29LE020", SST_ID, SST_29LE020,
-	 256, 128,
-	 TEST_UNTESTED,
-	 probe_jedec, erase_chip_jedec, write_jedec
+	{
+		.vendor		= "SST",
+		.name		= "SST29LE020",
+		.manufacture_id	= SST_ID,
+		.model_id	= SST_29LE020,
+		.total_size	= 256,
+		.page_size	= 128,
+		.tested		= TEST_UNTESTED,
+		.probe		= probe_jedec,
+		.erase		= erase_chip_jedec,
+		.write		= write_jedec,
 	},
 
-	{"SST", "SST39SF010A", SST_ID, SST_39SF010,
-	 128, 4096,
-	 TEST_OK_PREW,
-	 probe_jedec, erase_chip_jedec, write_39sf020
+	{
+		.vendor		= "SST",
+		.name		= "SST39SF010A",
+		.manufacture_id	= SST_ID,
+		.model_id	= SST_39SF010,
+		.total_size	= 128,
+		.page_size	= 4096,
+		.tested		= TEST_OK_PREW,
+		.probe		= probe_jedec,
+		.erase		= erase_chip_jedec,
+		.write		= write_39sf020,
 	},
 
-	{"SST", "SST39SF020A", SST_ID, SST_39SF020,
-	 256, 4096,
-	 TEST_OK_PREW,
-	 probe_jedec, erase_chip_jedec, write_39sf020
+	{
+		.vendor		= "SST",
+		.name		= "SST39SF020A",
+		.manufacture_id	= SST_ID,
+		.model_id	= SST_39SF020,
+		.total_size	= 256,
+		.page_size	= 4096,
+		.tested		= TEST_OK_PREW,
+		.probe		= probe_jedec,
+		.erase		= erase_chip_jedec,
+		.write		= write_39sf020,
 	},
 
-	{"SST", "SST39SF040", SST_ID, SST_39SF040,
-	 512, 4096,
-	 TEST_OK_PREW,
-	 probe_jedec, erase_chip_jedec, write_39sf020
+	{
+		.vendor		= "SST",
+		.name		= "SST39SF040",
+		.manufacture_id	= SST_ID,
+		.model_id	= SST_39SF040,
+		.total_size	= 512,
+		.page_size	= 4096,
+		.tested		= TEST_OK_PREW,
+		.probe		= probe_jedec,
+		.erase		= erase_chip_jedec,
+		.write		= write_39sf020,
 	},
 
-	{"SST", "SST39VF512", SST_ID, SST_39VF512,
-	 64, 4096,
-	 TEST_UNTESTED,
-	 probe_jedec, erase_chip_jedec, write_39sf020
+	{
+		.vendor		= "SST",
+		.name		= "SST39VF512",
+		.manufacture_id	= SST_ID,
+		.model_id	= SST_39VF512,
+		.total_size	= 64,
+		.page_size	= 4096,
+		.tested		= TEST_UNTESTED,
+		.probe		= probe_jedec,
+		.erase		= erase_chip_jedec,
+		.write		= write_39sf020,
 	},
 
-	{"SST", "SST39VF010", SST_ID, SST_39VF010,
-	 128, 4096,
-	 TEST_UNTESTED,
-	 probe_jedec, erase_chip_jedec, write_39sf020
+	{
+		.vendor		= "SST",
+		.name		= "SST39VF010",
+		.manufacture_id	= SST_ID,
+		.model_id	= SST_39VF010,
+		.total_size	= 128,
+		.page_size	= 4096,
+		.tested		= TEST_UNTESTED,
+		.probe		= probe_jedec,
+		.erase		= erase_chip_jedec,
+		.write		= write_39sf020,
 	},
 
-	{"SST", "SST39VF020", SST_ID, SST_39VF020,
-	 256, 4096,
-	 TEST_OK_PREW,
-	 probe_jedec, erase_chip_jedec, write_39sf020
+	{
+		.vendor		= "SST",
+		.name		= "SST39VF020",
+		.manufacture_id	= SST_ID,
+		.model_id	= SST_39VF020,
+		.total_size	= 256,
+		.page_size	= 4096,
+		.tested		= TEST_OK_PREW,
+		.probe		= probe_jedec,
+		.erase		= erase_chip_jedec,
+		.write		= write_39sf020,
 	},
 
-	{"SST", "SST39VF040", SST_ID, SST_39VF040,
-	 512, 4096,
-	 TEST_OK_PROBE,
-	 probe_jedec, erase_chip_jedec, write_39sf020
+	{
+		.vendor		= "SST",
+		.name		= "SST39VF040",
+		.manufacture_id	= SST_ID,
+		.model_id	= SST_39VF040,
+		.total_size	= 512,
+		.page_size	= 4096,
+		.tested		= TEST_OK_PROBE,
+		.probe		= probe_jedec,
+		.erase		= erase_chip_jedec,
+		.write		= write_39sf020,
 	},
 
-	{"SST", "SST49LF002A/B", SST_ID, SST_49LF002A,
-	 256, 16 * 1024,
-	 TEST_OK_PREW,
-	 probe_sst_fwhub, erase_sst_fwhub, write_sst_fwhub
+	{
+		.vendor		= "SST",
+		.name		= "SST49LF002A/B",
+		.manufacture_id	= SST_ID,
+		.model_id	= SST_49LF002A,
+		.total_size	= 256,
+		.page_size	= 16 * 1024,
+		.tested		= TEST_OK_PREW,
+		.probe		= probe_sst_fwhub,
+		.erase		= erase_sst_fwhub,
+		.write		= write_sst_fwhub,
 	},
 
-	{"SST", "SST49LF003A/B", SST_ID, SST_49LF003A,
-	 384, 64 * 1024,
-	 TEST_UNTESTED,
-	 probe_sst_fwhub, erase_sst_fwhub, write_sst_fwhub
+	{
+		.vendor		= "SST",
+		.name		= "SST49LF003A/B",
+		.manufacture_id	= SST_ID,
+		.model_id	= SST_49LF003A,
+		.total_size	= 384,
+		.page_size	= 64 * 1024,
+		.tested		= TEST_UNTESTED,
+		.probe		= probe_sst_fwhub,
+		.erase		= erase_sst_fwhub,
+		.write		= write_sst_fwhub,
 	},
 
-	{"SST", "SST49LF004A/B", SST_ID, SST_49LF004A,
-	 512, 64 * 1024,
-	 TEST_OK_PREW,
-	 probe_sst_fwhub, erase_sst_fwhub, write_sst_fwhub
+	{
+		.vendor		= "SST",
+		.name		= "SST49LF004A/B",
+		.manufacture_id	= SST_ID,
+		.model_id	= SST_49LF004A,
+		.total_size	= 512,
+		.page_size	= 64 * 1024,
+		.tested		= TEST_OK_PREW,
+		.probe		= probe_sst_fwhub,
+		.erase		= erase_sst_fwhub,
+		.write		= write_sst_fwhub,
 	},
 
-	{"SST", "SST49LF004C", SST_ID, SST_49LF004C,
-	 512, 4 * 1024,
-	 TEST_UNTESTED,
-	 probe_49lfxxxc, erase_49lfxxxc, write_49lfxxxc
+	{
+		.vendor		= "SST",
+		.name		= "SST49LF004C",
+		.manufacture_id	= SST_ID,
+		.model_id	= SST_49LF004C,
+		.total_size	= 512,
+		.page_size	= 4 * 1024,
+		.tested		= TEST_UNTESTED,
+		.probe		= probe_49lfxxxc,
+		.erase		= erase_49lfxxxc,
+		.write		= write_49lfxxxc,
 	},
 
-	{"SST", "SST49LF008A", SST_ID, SST_49LF008A,
-	 1024, 64 * 1024,
-	 TEST_OK_PREW,
-	 probe_sst_fwhub, erase_sst_fwhub, write_sst_fwhub
+	{
+		.vendor		= "SST",
+		.name		= "SST49LF008A",
+		.manufacture_id	= SST_ID,
+		.model_id	= SST_49LF008A,
+		.total_size	= 1024,
+		.page_size	= 64 * 1024,
+		.tested		= TEST_OK_PREW,
+		.probe		= probe_sst_fwhub,
+		.erase		= erase_sst_fwhub,
+		.write		= write_sst_fwhub,
 	},
 
-	{"SST", "SST49LF008C", SST_ID, SST_49LF008C,
-	 1024, 4 * 1024,
-	 TEST_UNTESTED,
-	 probe_49lfxxxc, erase_49lfxxxc, write_49lfxxxc
+	{
+		.vendor		= "SST",
+		.name		= "SST49LF008C",
+		.manufacture_id	= SST_ID,
+		.model_id	= SST_49LF008C,
+		.total_size	= 1024,
+		.page_size	= 4 * 1024,
+		.tested		= TEST_UNTESTED,
+		.probe		= probe_49lfxxxc,
+		.erase		= erase_49lfxxxc,
+		.write		= write_49lfxxxc,
 	},
 
-	{"SST", "SST49LF016C", SST_ID, SST_49LF016C,
-	 2048, 4 * 1024,
-	 TEST_OK_PREW,
-	 probe_49lfxxxc, erase_49lfxxxc, write_49lfxxxc
+	{
+		.vendor		= "SST",
+		.name		= "SST49LF016C",
+		.manufacture_id	= SST_ID,
+		.model_id	= SST_49LF016C,
+		.total_size	= 2048,
+		.page_size	= 4 * 1024,
+		.tested		= TEST_OK_PREW,
+		.probe		= probe_49lfxxxc,
+		.erase		= erase_49lfxxxc,
+		.write		= write_49lfxxxc,
 	},
 
-	{"SST", "SST49LF020", SST_ID, SST_49LF020,
-	 256, 16 * 1024,
-	 TEST_OK_PR,
-	 probe_jedec, erase_49lf040, write_49lf040
+	{
+		.vendor		= "SST",
+		.name		= "SST49LF020",
+		.manufacture_id	= SST_ID,
+		.model_id	= SST_49LF020,
+		.total_size	= 256,
+		.page_size	= 16 * 1024,
+		.tested		= TEST_OK_PR,
+		.probe		= probe_jedec,
+		.erase		= erase_49lf040,
+		.write		= write_49lf040,
 	},
 
-	{"SST", "SST49LF020A", SST_ID, SST_49LF020A,
-	 256, 16 * 1024,
-	 TEST_UNTESTED,
-	 probe_jedec, erase_49lf040, write_49lf040
+	{
+		.vendor		= "SST",
+		.name		= "SST49LF020A",
+		.manufacture_id	= SST_ID,
+		.model_id	= SST_49LF020A,
+		.total_size	= 256,
+		.page_size	= 16 * 1024,
+		.tested		= TEST_UNTESTED,
+		.probe		= probe_jedec,
+		.erase		= erase_49lf040,
+		.write		= write_49lf040,
 	},
 
-	{"SST", "SST49LF040", SST_ID, SST_49LF040,
-	 512, 4096,
-	 TEST_OK_PREW,
-	 probe_jedec, erase_49lf040, write_49lf040
+	{
+		.vendor		= "SST",
+		.name		= "SST49LF040",
+		.manufacture_id	= SST_ID,
+		.model_id	= SST_49LF040,
+		.total_size	= 512,
+		.page_size	= 4096,
+		.tested		= TEST_OK_PREW,
+		.probe		= probe_jedec,
+		.erase		= erase_49lf040,
+		.write		= write_49lf040,
 	},
 
-	{"SST", "SST49LF040B", SST_ID, SST_49LF040B,
-	 512, 64 * 1024,
-	 TEST_OK_PREW,
-	 probe_sst_fwhub, erase_sst_fwhub, write_sst_fwhub
+	{
+		.vendor		= "SST",
+		.name		= "SST49LF040B",
+		.manufacture_id	= SST_ID,
+		.model_id	= SST_49LF040B,
+		.total_size	= 512,
+		.page_size	= 64 * 1024,
+		.tested		= TEST_OK_PREW,
+		.probe		= probe_sst_fwhub,
+		.erase		= erase_sst_fwhub,
+		.write		= write_sst_fwhub,
 	},
 
-	{"SST", "SST49LF080A", SST_ID, SST_49LF080A,
-	 1024, 4096,
-	 TEST_OK_PREW,
-	 probe_jedec, erase_49lf040, write_49lf040
+	{
+		.vendor		= "SST",
+		.name		= "SST49LF080A",
+		.manufacture_id	= SST_ID,
+		.model_id	= SST_49LF080A,
+		.total_size	= 1024,
+		.page_size	= 4096,
+		.tested		= TEST_OK_PREW,
+		.probe		= probe_jedec,
+		.erase		= erase_49lf040,
+		.write		= write_49lf040,
 	},
 
-	{"SST", "SST49LF160C", SST_ID, SST_49LF160C,
-	 2048, 4 * 1024,
-	 TEST_OK_PREW,
-	 probe_49lfxxxc, erase_49lfxxxc, write_49lfxxxc
+	{
+		.vendor		= "SST",
+		.name		= "SST49LF160C",
+		.manufacture_id	= SST_ID,
+		.model_id	= SST_49LF160C,
+		.total_size	= 2048,
+		.page_size	= 4 * 1024,
+		.tested		= TEST_OK_PREW,
+		.probe		= probe_49lfxxxc,
+		.erase		= erase_49lfxxxc,
+		.write		= write_49lfxxxc,
 	},
 
-	{"ST", "M25P05-A", ST_ID, ST_M25P05A,
-	 64, 256,
-	 TEST_UNTESTED,
-	 probe_spi_rdid, spi_chip_erase_c7, spi_chip_write, spi_chip_read
+	{
+		.vendor		= "ST",
+		.name		= "M25P05-A",
+		.manufacture_id	= ST_ID,
+		.model_id	= ST_M25P05A,
+		.total_size	= 64,
+		.page_size	= 256,
+		.tested		= TEST_UNTESTED,
+		.probe		= probe_spi_rdid,
+		.erase		= spi_chip_erase_c7,
+		.write		= spi_chip_write,
+		.read		= spi_chip_read,
 	},
 
-	{"ST", "M25P10-A", ST_ID, ST_M25P10A,
-	 128, 256,
-	 TEST_UNTESTED,
-	 probe_spi_rdid, spi_chip_erase_c7, spi_chip_write, spi_chip_read
+	{
+		.vendor		= "ST",
+		.name		= "M25P10-A",
+		.manufacture_id	= ST_ID,
+		.model_id	= ST_M25P10A,
+		.total_size	= 128,
+		.page_size	= 256,
+		.tested		= TEST_UNTESTED,
+		.probe		= probe_spi_rdid,
+		.erase		= spi_chip_erase_c7,
+		.write		= spi_chip_write,
+		.read		= spi_chip_read,
 	},
 
-	{"ST", "M25P20", ST_ID, ST_M25P20,
-	 256, 256,
-	 TEST_UNTESTED,
-	 probe_spi_rdid, spi_chip_erase_c7, spi_chip_write, spi_chip_read
+	{
+		.vendor		= "ST",
+		.name		= "M25P20",
+		.manufacture_id	= ST_ID,
+		.model_id	= ST_M25P20,
+		.total_size	= 256,
+		.page_size	= 256,
+		.tested		= TEST_UNTESTED,
+		.probe		= probe_spi_rdid,
+		.erase		= spi_chip_erase_c7,
+		.write		= spi_chip_write,
+		.read		= spi_chip_read,
 	},
 
-	{"ST", "M25P40", ST_ID, ST_M25P40,
-	 512, 256,
-	 TEST_UNTESTED,
-	 probe_spi_rdid, spi_chip_erase_c7, spi_chip_write, spi_chip_read
+	{
+		.vendor		= "ST",
+		.name		= "M25P40",
+		.manufacture_id	= ST_ID,
+		.model_id	= ST_M25P40,
+		.total_size	= 512,
+		.page_size	= 256,
+		.tested		= TEST_UNTESTED,
+		.probe		= probe_spi_rdid,
+		.erase		= spi_chip_erase_c7,
+		.write		= spi_chip_write,
+		.read		= spi_chip_read,
 	},
 
-	{"ST", "M25P40-old", ST_ID, ST_M25P40_RES,
-	 512, 256,
-	 TEST_UNTESTED,
-	 probe_spi_res, spi_chip_erase_c7, spi_chip_write, spi_chip_read
+	{
+		.vendor		= "ST",
+		.name		= "M25P40-old",
+		.manufacture_id	= ST_ID,
+		.model_id	= ST_M25P40_RES,
+		.total_size	= 512,
+		.page_size	= 256,
+		.tested		= TEST_UNTESTED,
+		.probe		= probe_spi_res,
+		.erase		= spi_chip_erase_c7,
+		.write		= spi_chip_write,
+		.read		= spi_chip_read,
 	},
 
-	{"ST", "M25P80", ST_ID, ST_M25P80,
-	 1024, 256,
-	 TEST_UNTESTED,
-	 probe_spi_rdid, spi_chip_erase_c7, spi_chip_write, spi_chip_read
+	{
+		.vendor		= "ST",
+		.name		= "M25P80",
+		.manufacture_id	= ST_ID,
+		.model_id	= ST_M25P80,
+		.total_size	= 1024,
+		.page_size	= 256,
+		.tested		= TEST_UNTESTED,
+		.probe		= probe_spi_rdid,
+		.erase		= spi_chip_erase_c7,
+		.write		= spi_chip_write,
+		.read		= spi_chip_read,
 	},
 
-	{"ST", "M25P16", ST_ID, ST_M25P16,
-	 2048, 256,
-	 TEST_OK_PREW,
-	 probe_spi_rdid, spi_chip_erase_c7, spi_chip_write, spi_chip_read
+	{
+		.vendor		= "ST",
+		.name		= "M25P16",
+		.manufacture_id	= ST_ID,
+		.model_id	= ST_M25P16,
+		.total_size	= 2048,
+		.page_size	= 256,
+		.tested		= TEST_OK_PREW,
+		.probe		= probe_spi_rdid,
+		.erase		= spi_chip_erase_c7,
+		.write		= spi_chip_write,
+		.read		= spi_chip_read,
 	},
 
-	{"ST", "M25P32", ST_ID, ST_M25P32,
-	 4096, 256,
-	 TEST_OK_PREW,
-	 probe_spi_rdid, spi_chip_erase_c7, spi_chip_write, spi_chip_read
+	{
+		.vendor		= "ST",
+		.name		= "M25P32",
+		.manufacture_id	= ST_ID,
+		.model_id	= ST_M25P32,
+		.total_size	= 4096,
+		.page_size	= 256,
+		.tested		= TEST_OK_PREW,
+		.probe		= probe_spi_rdid,
+		.erase		= spi_chip_erase_c7,
+		.write		= spi_chip_write,
+		.read		= spi_chip_read,
 	},
 
-	{"ST", "M25P64", ST_ID, ST_M25P64,
-	 8192, 256,
-	 TEST_UNTESTED,
-	 probe_spi_rdid, spi_chip_erase_c7, spi_chip_write, spi_chip_read
+	{
+		.vendor		= "ST",
+		.name		= "M25P64",
+		.manufacture_id	= ST_ID,
+		.model_id	= ST_M25P64,
+		.total_size	= 8192,
+		.page_size	= 256,
+		.tested		= TEST_UNTESTED,
+		.probe		= probe_spi_rdid,
+		.erase		= spi_chip_erase_c7,
+		.write		= spi_chip_write,
+		.read		= spi_chip_read,
 	},
 
-	{"ST", "M25P128", ST_ID, ST_M25P128,
-	 16384, 256,
-	 TEST_UNTESTED,
-	 probe_spi_rdid, spi_chip_erase_c7, spi_chip_write, spi_chip_read
+	{
+		.vendor		= "ST",
+		.name		= "M25P128",
+		.manufacture_id	= ST_ID,
+		.model_id	= ST_M25P128,
+		.total_size	= 16384,
+		.page_size	= 256,
+		.tested		= TEST_UNTESTED,
+		.probe		= probe_spi_rdid,
+		.erase		= spi_chip_erase_c7,
+		.write		= spi_chip_write,
+		.read		= spi_chip_read,
 	},
 
-	{"ST", "M29F002B", ST_ID, ST_M29F002B,
-	 256, 64 * 1024,
-	 TEST_UNTESTED,
-	 probe_jedec, erase_chip_jedec, write_jedec
+	{
+		.vendor		= "ST",
+		.name		= "M29F002B",
+		.manufacture_id	= ST_ID,
+		.model_id	= ST_M29F002B,
+		.total_size	= 256,
+		.page_size	= 64 * 1024,
+		.tested		= TEST_UNTESTED,
+		.probe		= probe_jedec,
+		.erase		= erase_chip_jedec,
+		.write		= write_jedec,
 	},
 
-	{"ST", "M29F002T/NT", ST_ID, ST_M29F002T,
-	 256, 64 * 1024,
-	 TEST_UNTESTED,
-	 probe_jedec, erase_chip_jedec, write_jedec
+	{
+		.vendor		= "ST",
+		.name		= "M29F002T/NT",
+		.manufacture_id	= ST_ID,
+		.model_id	= ST_M29F002T,
+		.total_size	= 256,
+		.page_size	= 64 * 1024,
+		.tested		= TEST_UNTESTED,
+		.probe		= probe_jedec,
+		.erase		= erase_chip_jedec,
+		.write		= write_jedec,
 	},
 
-	{"ST", "M29F040B", ST_ID, ST_M29F040B,
-	 512, 64 * 1024,
-	 TEST_OK_PREW,
-	 probe_29f040b, erase_29f040b, write_29f040b
+	{
+		.vendor		= "ST",
+		.name		= "M29F040B",
+		.manufacture_id	= ST_ID,
+		.model_id	= ST_M29F040B,
+		.total_size	= 512,
+		.page_size	= 64 * 1024,
+		.tested		= TEST_OK_PREW,
+		.probe		= probe_29f040b,
+		.erase		= erase_29f040b,
+		.write		= write_29f040b,
 	},
 
-	{"ST", "M29F400BT", ST_ID, ST_M29F400BT,
-	 512, 64 * 1024,
-	 TEST_UNTESTED,
-	 probe_m29f400bt, erase_m29f400bt, write_coreboot_m29f400bt
+	{
+		.vendor		= "ST",
+		.name		= "M29F400BT",
+		.manufacture_id	= ST_ID,
+		.model_id	= ST_M29F400BT,
+		.total_size	= 512,
+		.page_size	= 64 * 1024,
+		.tested		= TEST_UNTESTED,
+		.probe		= probe_m29f400bt,
+		.erase		= erase_m29f400bt,
+		.write		= write_coreboot_m29f400bt,
 	},
 
-	{"ST", "M29W010B", ST_ID, ST_M29W010B,
-	 128, 16 * 1024,
-	 TEST_UNTESTED,
-	 probe_jedec, erase_chip_jedec, write_jedec
+	{
+		.vendor		= "ST",
+		.name		= "M29W010B",
+		.manufacture_id	= ST_ID,
+		.model_id	= ST_M29W010B,
+		.total_size	= 128,
+		.page_size	= 16 * 1024,
+		.tested		= TEST_UNTESTED,
+		.probe		= probe_jedec,
+		.erase		= erase_chip_jedec,
+		.write		= write_jedec,
 	},
 
-	{"ST", "M29W040B", ST_ID, ST_M29W040B,
-	 512, 64 * 1024,
-	 TEST_UNTESTED,
-	 probe_jedec, erase_chip_jedec, write_jedec
+	{
+		.vendor		= "ST",
+		.name		= "M29W040B",
+		.manufacture_id	= ST_ID,
+		.model_id	= ST_M29W040B,
+		.total_size	= 512,
+		.page_size	= 64 * 1024,
+		.tested		= TEST_UNTESTED,
+		.probe		= probe_jedec,
+		.erase		= erase_chip_jedec,
+		.write		= write_jedec,
 	},
 
-	{"ST", "M50FLW040A", ST_ID, ST_M50FLW040A,
-	 512, 64 * 1024,
-	 TEST_UNTESTED,
-	 probe_stm50flw0x0x, erase_stm50flw0x0x, write_stm50flw0x0x
+	{
+		.vendor		= "ST",
+		.name		= "M50FLW040A",
+		.manufacture_id	= ST_ID,
+		.model_id	= ST_M50FLW040A,
+		.total_size	= 512,
+		.page_size	= 64 * 1024,
+		.tested		= TEST_UNTESTED,
+		.probe		= probe_stm50flw0x0x,
+		.erase		= erase_stm50flw0x0x,
+		.write		= write_stm50flw0x0x,
 	},
 
-	{"ST", "M50FLW040B", ST_ID, ST_M50FLW040B,
-	 512, 64 * 1024,
-	 TEST_UNTESTED,
-	 probe_stm50flw0x0x, erase_stm50flw0x0x, write_stm50flw0x0x
+	{
+		.vendor		= "ST",
+		.name		= "M50FLW040B",
+		.manufacture_id	= ST_ID,
+		.model_id	= ST_M50FLW040B,
+		.total_size	= 512,
+		.page_size	= 64 * 1024,
+		.tested		= TEST_UNTESTED,
+		.probe		= probe_stm50flw0x0x,
+		.erase		= erase_stm50flw0x0x,
+		.write		= write_stm50flw0x0x,
 	},
 
-	{"ST", "M50FLW080A", ST_ID, ST_M50FLW080A,
-	 1024, 64 * 1024,
-	 TEST_OK_PREW,
-	 probe_stm50flw0x0x, erase_stm50flw0x0x, write_stm50flw0x0x
+	{
+		.vendor		= "ST",
+		.name		= "M50FLW080A",
+		.manufacture_id	= ST_ID,
+		.model_id	= ST_M50FLW080A,
+		.total_size	= 1024,
+		.page_size	= 64 * 1024,
+		.tested		= TEST_OK_PREW,
+		.probe		= probe_stm50flw0x0x,
+		.erase		= erase_stm50flw0x0x,
+		.write		= write_stm50flw0x0x,
 	},
 
-	{"ST", "M50FLW080B", ST_ID, ST_M50FLW080B,
-	 1024, 64 * 1024,
-	 TEST_UNTESTED,
-	 probe_stm50flw0x0x, erase_stm50flw0x0x, write_stm50flw0x0x
+	{
+		.vendor		= "ST",
+		.name		= "M50FLW080B",
+		.manufacture_id	= ST_ID,
+		.model_id	= ST_M50FLW080B,
+		.total_size	= 1024,
+		.page_size	= 64 * 1024,
+		.tested		= TEST_UNTESTED,
+		.probe		= probe_stm50flw0x0x,
+		.erase		= erase_stm50flw0x0x,
+		.write		= write_stm50flw0x0x,
 	},
 
-	{"ST", "M50FW002", ST_ID, ST_M50FW002,
-	 256, 64 * 1024,
-	 TEST_UNTESTED,
-	 probe_49lfxxxc, NULL, NULL
+	{
+		.vendor		= "ST",
+		.name		= "M50FW002",
+		.manufacture_id	= ST_ID,
+		.model_id	= ST_M50FW002,
+		.total_size	= 256,
+		.page_size	= 64 * 1024,
+		.tested		= TEST_UNTESTED,
+		.probe		= probe_49lfxxxc,
+		.erase		= NULL,
+		.write		= NULL,
 	},
 
-	{"ST", "M50FW016", ST_ID, ST_M50FW016,
-	 2048, 64 * 1024,
-	 TEST_UNTESTED,
-	 probe_82802ab, erase_82802ab, write_82802ab
+	{
+		.vendor		= "ST",
+		.name		= "M50FW016",
+		.manufacture_id	= ST_ID,
+		.model_id	= ST_M50FW016,
+		.total_size	= 2048,
+		.page_size	= 64 * 1024,
+		.tested		= TEST_UNTESTED,
+		.probe		= probe_82802ab,
+		.erase		= erase_82802ab,
+		.write		= write_82802ab,
 	},
 
-	{"ST", "M50FW040", ST_ID, ST_M50FW040,
-	 512, 64 * 1024,
-	 TEST_OK_PREW,
-	 probe_82802ab, erase_82802ab, write_82802ab
+	{
+		.vendor		= "ST",
+		.name		= "M50FW040",
+		.manufacture_id	= ST_ID,
+		.model_id	= ST_M50FW040,
+		.total_size	= 512,
+		.page_size	= 64 * 1024,
+		.tested		= TEST_OK_PREW,
+		.probe		= probe_82802ab,
+		.erase		= erase_82802ab,
+		.write		= write_82802ab,
 	},
 
-	{"ST", "M50FW080", ST_ID, ST_M50FW080,
-	 1024, 64 * 1024,
-	 TEST_UNTESTED,
-	 probe_82802ab, erase_82802ab, write_82802ab
+	{
+		.vendor		= "ST",
+		.name		= "M50FW080",
+		.manufacture_id	= ST_ID,
+		.model_id	= ST_M50FW080,
+		.total_size	= 1024,
+		.page_size	= 64 * 1024,
+		.tested		= TEST_UNTESTED,
+		.probe		= probe_82802ab,
+		.erase		= erase_82802ab,
+		.write		= write_82802ab,
 	},
 
-	{"ST", "M50LPW116", ST_ID, ST_M50LPW116,
-	 2048, 64 * 1024,
-	 TEST_UNTESTED,
-	 probe_jedec, erase_chip_jedec, write_jedec
+	{
+		.vendor		= "ST",
+		.name		= "M50LPW116",
+		.manufacture_id	= ST_ID,
+		.model_id	= ST_M50LPW116,
+		.total_size	= 2048,
+		.page_size	= 64 * 1024,
+		.tested		= TEST_UNTESTED,
+		.probe		= probe_jedec,
+		.erase		= erase_chip_jedec,
+		.write		= write_jedec,
 	},
 
-	{"SyncMOS", "S29C31004T", SYNCMOS_ID, S29C31004T,
-	 512, 128,
-	 TEST_UNTESTED,
-	 probe_jedec, erase_chip_jedec, write_49f002
+	{
+		.vendor		= "SyncMOS",
+		.name		= "S29C31004T",
+		.manufacture_id	= SYNCMOS_ID,
+		.model_id	= S29C31004T,
+		.total_size	= 512,
+		.page_size	= 128,
+		.tested		= TEST_UNTESTED,
+		.probe		= probe_jedec,
+		.erase		= erase_chip_jedec,
+		.write		= write_49f002,
 	},
 
-	{"SyncMOS", "S29C51001T", SYNCMOS_ID, S29C51001T,
-	 128, 128,
-	 TEST_UNTESTED,
-	 probe_jedec, erase_chip_jedec, write_49f002
+	{
+		.vendor		= "SyncMOS",
+		.name		= "S29C51001T",
+		.manufacture_id	= SYNCMOS_ID,
+		.model_id	= S29C51001T,
+		.total_size	= 128,
+		.page_size	= 128,
+		.tested		= TEST_UNTESTED,
+		.probe		= probe_jedec,
+		.erase		= erase_chip_jedec,
+		.write		= write_49f002,
 	},
 
-	{"SyncMOS", "S29C51002T", SYNCMOS_ID, S29C51002T,
-	 256, 128,
-	 TEST_OK_PREW,
-	 probe_jedec, erase_chip_jedec, write_49f002
+	{
+		.vendor		= "SyncMOS",
+		.name		= "S29C51002T",
+		.manufacture_id	= SYNCMOS_ID,
+		.model_id	= S29C51002T,
+		.total_size	= 256,
+		.page_size	= 128,
+		.tested		= TEST_OK_PREW,
+		.probe		= probe_jedec,
+		.erase		= erase_chip_jedec,
+		.write		= write_49f002,
 	},
 
-	{"SyncMOS", "S29C51004T", SYNCMOS_ID, S29C51004T,
-	 512, 128,
-	 TEST_UNTESTED,
-	 probe_jedec, erase_chip_jedec, write_49f002
+	{
+		.vendor		= "SyncMOS",
+		.name		= "S29C51004T",
+		.manufacture_id	= SYNCMOS_ID,
+		.model_id	= S29C51004T,
+		.total_size	= 512,
+		.page_size	= 128,
+		.tested		= TEST_UNTESTED,
+		.probe		= probe_jedec,
+		.erase		= erase_chip_jedec,
+		.write		= write_49f002,
 	},
 
-	{"Winbond", "W25x10", WINBOND_NEX_ID, W_25X10,
-	 128, 256,
-	 TEST_UNTESTED,
-	 probe_spi_rdid, spi_chip_erase_c7, spi_chip_write, spi_chip_read
+	{
+		.vendor		= "Winbond",
+		.name		= "W25x10",
+		.manufacture_id	= WINBOND_NEX_ID,
+		.model_id	= W_25X10,
+		.total_size	= 128,
+		.page_size	= 256,
+		.tested		= TEST_UNTESTED,
+		.probe		= probe_spi_rdid,
+		.erase		= spi_chip_erase_c7,
+		.write		= spi_chip_write,
+		.read		= spi_chip_read,
 	},
 
-	{"Winbond", "W25x20", WINBOND_NEX_ID, W_25X20,
-	 256, 256,
-	 TEST_UNTESTED,
-	 probe_spi_rdid, spi_chip_erase_c7, spi_chip_write, spi_chip_read
+	{
+		.vendor		= "Winbond",
+		.name		= "W25x20",
+		.manufacture_id	= WINBOND_NEX_ID,
+		.model_id	= W_25X20,
+		.total_size	= 256,
+		.page_size	= 256,
+		.tested		= TEST_UNTESTED,
+		.probe		= probe_spi_rdid,
+		.erase		= spi_chip_erase_c7,
+		.write		= spi_chip_write,
+		.read		= spi_chip_read,
 	},
 
-	{"Winbond", "W25x40", WINBOND_NEX_ID, W_25X40,
-	 512, 256,
-	 TEST_OK_PREW,
-	 probe_spi_rdid, spi_chip_erase_c7, spi_chip_write, spi_chip_read
+	{
+		.vendor		= "Winbond",
+		.name		= "W25x40",
+		.manufacture_id	= WINBOND_NEX_ID,
+		.model_id	= W_25X40,
+		.total_size	= 512,
+		.page_size	= 256,
+		.tested		= TEST_OK_PREW,
+		.probe		= probe_spi_rdid,
+		.erase		= spi_chip_erase_c7,
+		.write		= spi_chip_write,
+		.read		= spi_chip_read,
 	},
 
-	{"Winbond", "W25x80", WINBOND_NEX_ID, W_25X80,
-	 1024, 256,
-	 TEST_OK_PREW,
-	 probe_spi_rdid, spi_chip_erase_c7, spi_chip_write, spi_chip_read
+	{
+		.vendor		= "Winbond",
+		.name		= "W25x80",
+		.manufacture_id	= WINBOND_NEX_ID,
+		.model_id	= W_25X80,
+		.total_size	= 1024,
+		.page_size	= 256,
+		.tested		= TEST_OK_PREW,
+		.probe		= probe_spi_rdid,
+		.erase		= spi_chip_erase_c7,
+		.write		= spi_chip_write,
+		.read		= spi_chip_read,
 	},
 
-	{"Winbond", "W29C011", WINBOND_ID, W_29C011,
-	 128, 128,
-	 TEST_OK_PREW,
-	 probe_jedec, erase_chip_jedec, write_jedec
+	{
+		.vendor		= "Winbond",
+		.name		= "W29C011",
+		.manufacture_id	= WINBOND_ID,
+		.model_id	= W_29C011,
+		.total_size	= 128,
+		.page_size	= 128,
+		.tested		= TEST_OK_PREW,
+		.probe		= probe_jedec,
+		.erase		= erase_chip_jedec,
+		.write		= write_jedec,
 	},
 
-	{"Winbond", "W29C020C", WINBOND_ID, W_29C020C,
-	 256, 128,
-	 TEST_OK_PREW,
-	 probe_jedec, erase_chip_jedec, write_jedec
+	{
+		.vendor		= "Winbond",
+		.name		= "W29C020C",
+		.manufacture_id	= WINBOND_ID,
+		.model_id	= W_29C020C,
+		.total_size	= 256,
+		.page_size	= 128,
+		.tested		= TEST_OK_PREW,
+		.probe		= probe_jedec,
+		.erase		= erase_chip_jedec,
+		.write		= write_jedec,
 	},
 
-	{"Winbond", "W29C040P", WINBOND_ID, W_29C040P,
-	 512, 256,
-	 TEST_UNTESTED,
-	 probe_jedec, erase_chip_jedec, write_jedec
+	{
+		.vendor		= "Winbond",
+		.name		= "W29C040P",
+		.manufacture_id	= WINBOND_ID,
+		.model_id	= W_29C040P,
+		.total_size	= 512,
+		.page_size	= 256,
+		.tested		= TEST_UNTESTED,
+		.probe		= probe_jedec,
+		.erase		= erase_chip_jedec,
+		.write		= write_jedec,
 	},
 
-	{"Winbond", "W29EE011", WINBOND_ID, W_29C011,
-	 128, 128,
-	 TEST_OK_PREW,
-	 probe_w29ee011, erase_chip_jedec, write_jedec
+	{
+		.vendor		= "Winbond",
+		.name		= "W29EE011",
+		.manufacture_id	= WINBOND_ID,
+		.model_id	= W_29C011,
+		.total_size	= 128,
+		.page_size	= 128,
+		.tested		= TEST_OK_PREW,
+		.probe		= probe_w29ee011,
+		.erase		= erase_chip_jedec,
+		.write		= write_jedec,
 	},
 
-	{"Winbond", "W39V040A", WINBOND_ID, W_39V040A,
-	 512, 64*1024,
-	 TEST_UNTESTED,
-	 probe_jedec, erase_chip_jedec, write_39sf020
+	{
+		.vendor		= "Winbond",
+		.name		= "W39V040A",
+		.manufacture_id	= WINBOND_ID,
+		.model_id	= W_39V040A,
+		.total_size	= 512,
+		.page_size	= 64*1024,
+		.tested		= TEST_UNTESTED,
+		.probe		= probe_jedec,
+		.erase		= erase_chip_jedec,
+		.write		= write_39sf020,
 	},
 
-	{"Winbond", "W39V040B", WINBOND_ID, W_39V040B,
-	 512, 64*1024,
-	 TEST_OK_PREW,
-	 probe_jedec, erase_chip_jedec, write_39sf020
+	{
+		.vendor		= "Winbond",
+		.name		= "W39V040B",
+		.manufacture_id	= WINBOND_ID,
+		.model_id	= W_39V040B,
+		.total_size	= 512,
+		.page_size	= 64*1024,
+		.tested		= TEST_OK_PREW,
+		.probe		= probe_jedec,
+		.erase		= erase_chip_jedec,
+		.write		= write_39sf020,
 	},
 
-	{"Winbond", "W39V040C", WINBOND_ID, 0x50,
-	 512, 64*1024,
-	 TEST_OK_PREW,
-	 probe_w39v040c, erase_w39v040c, write_w39v040c
+	{
+		.vendor		= "Winbond",
+		.name		= "W39V040C",
+		.manufacture_id	= WINBOND_ID,
+		.model_id	= 0x50,
+		.total_size	= 512,
+		.page_size	= 64*1024,
+		.tested		= TEST_OK_PREW,
+		.probe		= probe_w39v040c,
+		.erase		= erase_w39v040c,
+		.write		= write_w39v040c,
 	},
 
-	{"Winbond", "W39V040FA", WINBOND_ID, W_39V040FA,
-	 512, 64*1024,
-	 TEST_OK_PREW,
-	 probe_jedec, erase_chip_jedec, write_39sf020
+	{
+		.vendor		= "Winbond",
+		.name		= "W39V040FA",
+		.manufacture_id	= WINBOND_ID,
+		.model_id	= W_39V040FA,
+		.total_size	= 512,
+		.page_size	= 64*1024,
+		.tested		= TEST_OK_PREW,
+		.probe		= probe_jedec,
+		.erase		= erase_chip_jedec,
+		.write		= write_39sf020,
 	},
 
-	{"Winbond", "W39V080A", WINBOND_ID, W_39V080A,
-	 1024, 64*1024,
-	 TEST_OK_PREW,
-	 probe_jedec, erase_chip_jedec, write_39sf020
+	{
+		.vendor		= "Winbond",
+		.name		= "W39V080A",
+		.manufacture_id	= WINBOND_ID,
+		.model_id	= W_39V080A,
+		.total_size	= 1024,
+		.page_size	= 64*1024,
+		.tested		= TEST_OK_PREW,
+		.probe		= probe_jedec,
+		.erase		= erase_chip_jedec,
+		.write		= write_39sf020,
 	},
 
-	{"Winbond", "W49F002U", WINBOND_ID, W_49F002U,
-	 256, 128,
-	 TEST_OK_PREW,
-	 probe_jedec, erase_chip_jedec, write_49f002
+	{
+		.vendor		= "Winbond",
+		.name		= "W49F002U",
+		.manufacture_id	= WINBOND_ID,
+		.model_id	= W_49F002U,
+		.total_size	= 256,
+		.page_size	= 128,
+		.tested		= TEST_OK_PREW,
+		.probe		= probe_jedec,
+		.erase		= erase_chip_jedec,
+		.write		= write_49f002,
 	},
 
-	{"Winbond", "W49V002A", WINBOND_ID, W_49V002A,
-	 256, 128,
-	 TEST_OK_PREW,
-	 probe_jedec, erase_chip_jedec, write_49f002
+	{
+		.vendor		= "Winbond",
+		.name		= "W49V002A",
+		.manufacture_id	= WINBOND_ID,
+		.model_id	= W_49V002A,
+		.total_size	= 256,
+		.page_size	= 128,
+		.tested		= TEST_OK_PREW,
+		.probe		= probe_jedec,
+		.erase		= erase_chip_jedec,
+		.write		= write_49f002,
 	},
 
-	{"Winbond", "W49V002FA", WINBOND_ID, W_49V002FA,
-	 256, 128,
-	 TEST_UNTESTED,
-	 probe_jedec, erase_chip_jedec, write_49f002
+	{
+		.vendor		= "Winbond",
+		.name		= "W49V002FA",
+		.manufacture_id	= WINBOND_ID,
+		.model_id	= W_49V002FA,
+		.total_size	= 256,
+		.page_size	= 128,
+		.tested		= TEST_UNTESTED,
+		.probe		= probe_jedec,
+		.erase		= erase_chip_jedec,
+		.write		= write_49f002,
 	},
 
-	{"Winbond", "W39V080FA", WINBOND_ID, W_39V080FA,
-	 1024, 64*1024,
-	 TEST_OK_PREW,
-	 probe_winbond_fwhub, erase_winbond_fwhub, write_winbond_fwhub
+	{
+		.vendor		= "Winbond",
+		.name		= "W39V080FA",
+		.manufacture_id	= WINBOND_ID,
+		.model_id	= W_39V080FA,
+		.total_size	= 1024,
+		.page_size	= 64*1024,
+		.tested		= TEST_OK_PREW,
+		.probe		= probe_winbond_fwhub,
+		.erase		= erase_winbond_fwhub,
+		.write		= write_winbond_fwhub,
 	},
 
-	{"Winbond", "W39V080FA (dual mode)", WINBOND_ID, W_39V080FA_DM,
-	 512, 64*1024,
-	 TEST_UNTESTED,
-	 probe_winbond_fwhub, erase_winbond_fwhub, write_winbond_fwhub
+	{
+		.vendor		= "Winbond",
+		.name		= "W39V080FA (dual mode)",
+		.manufacture_id	= WINBOND_ID,
+		.model_id	= W_39V080FA_DM,
+		.total_size	= 512,
+		.page_size	= 64*1024,
+		.tested		= TEST_UNTESTED,
+		.probe		= probe_winbond_fwhub,
+		.erase		= erase_winbond_fwhub,
+		.write		= write_winbond_fwhub,
 	},
 
-	{"Atmel", "unknown Atmel SPI chip", ATMEL_ID, GENERIC_DEVICE_ID,
-	 0, 256,
-	 TEST_UNTESTED,
-	 probe_spi_rdid, NULL, NULL
+	{
+		.vendor		= "Atmel",
+		.name		= "unknown Atmel SPI chip",
+		.manufacture_id	= ATMEL_ID,
+		.model_id	= GENERIC_DEVICE_ID,
+		.total_size	= 0,
+		.page_size	= 256,
+		.tested		= TEST_UNTESTED,
+		.probe		= probe_spi_rdid,
+		.erase		= NULL,
+		.write		= NULL,
 	},
 
-	{"EON", "unknown EON SPI chip", EON_ID_NOPREFIX, GENERIC_DEVICE_ID,
-	 0, 256,
-	 TEST_UNTESTED,
-	 probe_spi_rdid, NULL, NULL
+	{
+		.vendor		= "EON",
+		.name		= "unknown EON SPI chip",
+		.manufacture_id	= EON_ID_NOPREFIX,
+		.model_id	= GENERIC_DEVICE_ID,
+		.total_size	= 0,
+		.page_size	= 256,
+		.tested		= TEST_UNTESTED,
+		.probe		= probe_spi_rdid,
+		.erase		= NULL,
+		.write		= NULL,
 	},
 
-	{"Macronix", "unknown Macronix SPI chip", MX_ID, GENERIC_DEVICE_ID,
-	 0, 256,
-	 TEST_UNTESTED,
-	 probe_spi_rdid, NULL, NULL
+	{
+		.vendor		= "Macronix",
+		.name		= "unknown Macronix SPI chip",
+		.manufacture_id	= MX_ID,
+		.model_id	= GENERIC_DEVICE_ID,
+		.total_size	= 0,
+		.page_size	= 256,
+		.tested		= TEST_UNTESTED,
+		.probe		= probe_spi_rdid,
+		.erase		= NULL,
+		.write		= NULL,
 	},
 
-	{"PMC", "unknown PMC SPI chip", PMC_ID, GENERIC_DEVICE_ID,
-	 0, 256,
-	 TEST_UNTESTED,
-	 probe_spi_rdid, NULL, NULL
+	{
+		.vendor		= "PMC",
+		.name		= "unknown PMC SPI chip",
+		.manufacture_id	= PMC_ID,
+		.model_id	= GENERIC_DEVICE_ID,
+		.total_size	= 0,
+		.page_size	= 256,
+		.tested		= TEST_UNTESTED,
+		.probe		= probe_spi_rdid,
+		.erase		= NULL,
+		.write		= NULL,
 	},
 
-	{"SST", "unknown SST SPI chip", SST_ID, GENERIC_DEVICE_ID,
-	 0, 256,
-	 TEST_UNTESTED,
-	 probe_spi_rdid, NULL, NULL
+	{
+		.vendor		= "SST",
+		.name		= "unknown SST SPI chip",
+		.manufacture_id	= SST_ID,
+		.model_id	= GENERIC_DEVICE_ID,
+		.total_size	= 0,
+		.page_size	= 256,
+		.tested		= TEST_UNTESTED,
+		.probe		= probe_spi_rdid,
+		.erase		= NULL,
+		.write		= NULL,
 	},
 
-	{"ST", "unknown ST SPI chip", ST_ID, GENERIC_DEVICE_ID,
-	 0, 256,
-	 TEST_UNTESTED,
-	 probe_spi_rdid, NULL, NULL
+	{
+		.vendor		= "ST",
+		.name		= "unknown ST SPI chip",
+		.manufacture_id	= ST_ID,
+		.model_id	= GENERIC_DEVICE_ID,
+		.total_size	= 0,
+		.page_size	= 256,
+		.tested		= TEST_UNTESTED,
+		.probe		= probe_spi_rdid,
+		.erase		= NULL,
+		.write		= NULL,
 	},
 
-	{NULL,}
-};
+	{ NULL 	}
+	};




From c-d.hailfinger.devel.2006 at gmx.net  Thu Jan  8 04:42:37 2009
From: c-d.hailfinger.devel.2006 at gmx.net (Carl-Daniel Hailfinger)
Date: Thu, 08 Jan 2009 04:42:37 +0100
Subject: [coreboot] [patch] flashrom flashchips array modification
In-Reply-To: <4945B7DD.1020806@gmx.net>
References: <4945480C.1070102@free.fr>	<dd3c80060812141014q353c7747s1aa21503f7642c49@mail.gmail.com>	<49454FB8.3070209@free.fr>
	<4945B7DD.1020806@gmx.net>
Message-ID: <4965762D.9010200@gmx.net>

On 15.12.2008 02:50, Carl-Daniel Hailfinger wrote:
> On 14.12.2008 19:26, Stephan GUILLOUX wrote:
>   
>> Corey Osgood a ?crit :
>>     
>>> On Sun, Dec 14, 2008 at 12:53 PM, Stephan GUILLOUX <stephan.guilloux at free.fr>
>>> wrote:
>>>       Hello all,
>>>
>>>     Using flashrom for some times, I find that flashchips array becomes
>>>     difficult to read.
>>>     To be able to read a single entry, in this array, you need to expand your
>>>     editor window
>>>     to its maximum size and reduce the font size. Any new field in this array
>>>     will result
>>>     in a nightmare to read and for support.
>>>
>>>     My suggestion for this, is to detail each line with field names, like with
>>>     the extract
>>>     below :
>>>     [...]
>>>       {
>>>           .vendor         = "AMD",
>>>           .name           = "Am29F016D",
>>>           .manufacture_id = AMD_ID,
>>>           .model_id       = AM_29F016D,
>>>           .total_size     = 2048,
>>>           .page_size      = 64 * 1024,
>>>           .tested         = TEST_UNTESTED,
>>>           .probe          = probe_29f040b,
>>>           .erase          = erase_29f040b,
>>>           .write          = write_29f040b,
>>>       },
>>>     [...]
>>>
>>>
>>> Good idea, but someone already had it ;) Take a look at a fresh checkout of 
>>> flashrom, not quite the same but very similar.
>>>       
>> I know. This patch is based on this work too.
>> But still difficult to parse to add/remove any field.
>>   
>>     
>
> Agreed.
>
>
>   
>>> -Corey
>>>
>>>
>>>     This kind of syntax makes flashchips.c rather longer in term of lines, but
>>>     keeps it
>>>     readable, and easily parsable with an external shell/tool...
>>>
>>>     Any comment ?
>>>
>>>     Also in attachement.
>>>
>>>       Stephan.
>>>
>>>     Signed-off-by: Stephan Guilloux <stephan.guilloux at free.fr>
>>>       
>>   
>>     
>
> Awesome!
> The patch improves machine parseability and human readability over
> what's currently in flashrom HEAD. And the explicit initialization makes
> sure any future struct flashchip reordering is not needed. (And I can
> throw away some of my pending patches because this solution is cleaner
> and fulfills all my requirements.)
>
> Acked-by: Carl-Daniel Hailfinger <c-d.hailfinger.devel.2006 at gmx.net>
>   

Committed in r3851.

I assume you have a script or some other way to convert flashchips.c. I
have quite a few pending chip changes for that file and manually
updating all of them is going to be a nightmare. Can you dig up that
script and mail it to the list or may I send my flashchips.c variants to
you for conversion? Thanks!

Regards,
Carl-Daniel

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




From rminnich at gmail.com  Thu Jan  8 05:29:28 2009
From: rminnich at gmail.com (ron minnich)
Date: Wed, 7 Jan 2009 20:29:28 -0800
Subject: [coreboot] domain vs device statictree order
In-Reply-To: <2831fecf0901070835h1f260f9cweaea5d8ad38ae0fd@mail.gmail.com>
References: <534e5dc20901061346g5eb604c5kf63a80f5634a1128@mail.gmail.com>
	<F893D0B3C6794D4BA36DE9DDC72625D3@chimp>
	<2831fecf0901061437k3367b4fbgbf237c66a5af87ff@mail.gmail.com>
	<1231320337.4567.4.camel@martr-gentoo.artec>
	<2831fecf0901070835h1f260f9cweaea5d8ad38ae0fd@mail.gmail.com>
Message-ID: <13426df10901072029t4be3825cy89942423d57ffa9@mail.gmail.com>

On Wed, Jan 7, 2009 at 8:35 AM, Myles Watson <mylesgw at gmail.com> wrote:
>>> I guess it's not really breadth first.  It's just parents before siblings.
>>>
>>> I think this should be done for all the phases unless there's some
>>> compelling reason not to.
>>
>> I don't think having different phases run in different order is a good
>> idea, as it can lead to unexpected code execution orders all over again.
>
> I agree.
>
>> Code-wise this looks good if all phases act the same way.
>
> Without this patch Phase1, Phase2, and Phase6 are done in statictree
> order, and Phase3, Phase4, and Phase5 are done Parents before
> children.
>
> I don't see Phase1 being used anywhere.  Phase2 is handled with the
> patch.  I think Phase6 should be updated, and I can send a patch.
>
> Ron?
>

I am still sort of out but you guys are on the right approach, do what
you think best. I trust you ...

ron



From mylesgw at gmail.com  Thu Jan  8 05:39:39 2009
From: mylesgw at gmail.com (Myles Watson)
Date: Wed, 7 Jan 2009 21:39:39 -0700
Subject: [coreboot] domain vs device statictree order
In-Reply-To: <20090108023135.GA21159@localdomain>
References: <534e5dc20901061346g5eb604c5kf63a80f5634a1128@mail.gmail.com>
	<F893D0B3C6794D4BA36DE9DDC72625D3@chimp>
	<2831fecf0901061437k3367b4fbgbf237c66a5af87ff@mail.gmail.com>
	<534e5dc20901061513l3b63756mf0a102cddc33ecc0@mail.gmail.com>
	<2831fecf0901061519i873cdf5ua5110832479f1679@mail.gmail.com>
	<2831fecf0901061529p539d4e80s2bcb8c15abdf06a6@mail.gmail.com>
	<534e5dc20901070905p401b0a5aj2598ccef1a3edec7@mail.gmail.com>
	<2831fecf0901071027t461c3c54rf8fd0b54112b5238@mail.gmail.com>
	<20090108020137.GA20844@localdomain>
	<20090108023135.GA21159@localdomain>
Message-ID: <2831fecf0901072039r52c14481j8e7da3d4ccee7850@mail.gmail.com>

On Wed, Jan 7, 2009 at 7:31 PM, Ward Vandewege <ward at gnu.org> wrote:
> On Wed, Jan 07, 2009 at 09:01:37PM -0500, Ward Vandewege wrote:
>> > > Acked-by: Marc Jones <marcj303 at gmail.com>
>> > Rev 1103.
>>
>> Marc asked me to test on geode - I tried on an alix2c3 just now with v1104.
>> Looks like something broke (but perhaps not because of this particular
>> checkin - the last known ok v3 version for alix2c3 is 682). Basically, the
>> alix resets itself right after (during?)
>>
>>   cs5536: southbridge_init
>>
>> Bootlog attached.
>>
>> Help?
>
> The rev that broke the boot was 1089 or 1090. 1089 does not build, so I can't
> tell for sure. 1088 boots fine. 1090 is broken.

They might have well been the same commit because they were
interdependent.  It was just an easier way of looking at the changes
for me.

Thanks for tracking it down.  Could you send me a log from 1088?
Hopefully we can track it down quickly.

> Btw: buildrom + artec dongle + alix2c3 -> 40 second turnaround time between
> boots (and that includes 10 seconds for me). This is *nice*.

That is nice.  I wish my Tyan boards had < 1min turnaround.

Thanks,
Myles



From svn at coreboot.org  Thu Jan  8 05:56:59 2009
From: svn at coreboot.org (svn at coreboot.org)
Date: Thu,  8 Jan 2009 05:56:59 +0100
Subject: [coreboot] r3852 - trunk/util/flashrom
Message-ID: <mailman.2647.1355071467.16123.coreboot@coreboot.org>

Author: hailfinger
Date: 2009-01-08 05:56:59 +0100 (Thu, 08 Jan 2009)
New Revision: 3852

Modified:
   trunk/util/flashrom/flashrom.8
Log:
The flashrom man page has incomplete author/copyright sections and an
incorrect license section.
- Remove the copyright listings and refer the reader to the source
  files.
- Update the author list to those which have copyright messages in the
source files.
- Correct the license from GPL v2+ to (GPL v2, with some files under
  later versions as well)

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


Modified: trunk/util/flashrom/flashrom.8
===================================================================
--- trunk/util/flashrom/flashrom.8	2009-01-08 03:40:17 UTC (rev 3851)
+++ trunk/util/flashrom/flashrom.8	2009-01-08 04:56:59 UTC (rev 3852)
@@ -1,4 +1,4 @@
-.TH FLASHROM 8 "June 22, 2008"
+.TH FLASHROM 8 "January 5, 2009"
 .SH NAME
 flashrom \- a universal BIOS/ROM/flash programming utility
 .SH SYNOPSIS
@@ -84,22 +84,50 @@
 .RB "(" http://coreboot.org/Mailinglist ")."
 .SH LICENCE
 .B flashrom
-is covered by the GNU General Public License (GPL), version 2 or later.
+is covered by the GNU General Public License (GPL), version 2. Some files are
+additionally available under the GPL (version 2, or any later version).
 .SH COPYRIGHT
-2000 Silicon Integrated System Corporation
 .br
-2003 Niki W. Waibel
+Please see the individual files.
+.SH AUTHORS
+Carl-Daniel Hailfinger
 .br
-2004 Tyan Corp
+Claus Gindhart <claus.gindhart at kontron.com>
 .br
-2005-2007 coresystems GmbH
-.SH AUTHORS
-Yinghai Lu <yinghai.lu at amd.com>
+Dominik Geyer <dominik.geyer at kontron.com>
 .br
+Eric Biederman <ebiederman at lnxi.com>
+.br
+Giampiero Giancipoli <gianci at email.it>
+.br
+Joe Bao <Zheng.Bao at amd.com>
+.br
+Luc Verhaegen <libv at skynet.be>
+.br
+Markus Boas <ryven at ryven.de>
+.br
+Nikolay Petukhov <nikolay.petukhov at gmail.com>
+.br
+Peter Stuge <peter at stuge.se>
+.br
+Reinder E.N. de Haan <lb_reha at mveas.com>
+.br
+Ronald G. Minnich <rminnich at gmail.com>
+.br
+Ronald Hoogenboom <ronald at zonnet.nl>
+.br
 Stefan Reinauer <stepan at coresystems.de>
 .br
-Niki W. Waibel <niki.waibel at gmx.net>
+Stefan Wildemann <stefan.wildemann at kontron.com>
 .br
+Steven James <pyro at linuxlabs.com>
+.br
+Uwe Hermann <uwe at hermann-uwe.de>
+.br
+Wang Qingpei <Qingpei.Wang at amd.com>
+.br
+Yinghai Lu <yinghai.lu at amd.com>
+.br
 some others 
 .PP
 This manual page was written by Uwe Hermann <uwe at hermann-uwe.de>.




From c-d.hailfinger.devel.2006 at gmx.net  Thu Jan  8 05:57:25 2009
From: c-d.hailfinger.devel.2006 at gmx.net (Carl-Daniel Hailfinger)
Date: Thu, 08 Jan 2009 05:57:25 +0100
Subject: [coreboot] [PATCH] flashrom: Update man page
In-Reply-To: <20090107121347.GC7490@greenwood>
References: <496166A3.2040705@gmx.net>
	<20090105230413.GB12484@greenwood>	<4964014F.5090205@gmx.net>
	<20090107121347.GC7490@greenwood>
Message-ID: <496587B5.8010508@gmx.net>

On 07.01.2009 13:13, Uwe Hermann wrote:
> On Wed, Jan 07, 2009 at 02:11:43AM +0100, Carl-Daniel Hailfinger wrote:
>   
>> Signed-off-by: Carl-Daniel Hailfinger <c-d.hailfinger.devel.2006 at gmx.net>
>>     
>
> Acked-by: Uwe Hermann <uwe at hermann-uwe.de>
>   

Thanks, r3852.

Regards,
Carl-Daniel

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




From engineerguy3737 at yahoo.com  Thu Jan  8 06:49:54 2009
From: engineerguy3737 at yahoo.com (Dan Lykowski)
Date: Wed, 7 Jan 2009 21:49:54 -0800 (PST)
Subject: [coreboot] FIDVID question
Message-ID: <704889.9516.qm@web57006.mail.re3.yahoo.com>

I have narrowed the resetting of my board to:

Referring to real_main in cache_as_ram.c for dbm690t and pistachio.
msr=rdmsr(0xc0010042); ( Reading the FIDVID_STAUS register )

According to the docs, trying to read this register on a processor that doesn't support FID/VID changes will cause a GP#. 
I was under the assumption that all mobile 0Fh processors had this capability.
Would calling enable_fid_change() before the rdmsr call enable the MSR? ( I am skeptical because the code is working for other processors. )
Would it be appropriate to add a check around the FIDVID sections?

struct cpuid_result cpuid1;
cpuid1 = cpuid(0x8000007);
if( (cpuid1.edx & 0x06) == 0x06 ) {
}

S1G1 Sempron 2100+ 9W 1Ghz

Thanks,
Dan Lykowski 





      
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20090107/78a3bed3/attachment.html>

From r.marek at assembler.cz  Thu Jan  8 09:45:09 2009
From: r.marek at assembler.cz (r.marek at assembler.cz)
Date: Thu, 08 Jan 2009 09:45:09 +0100
Subject: [coreboot] FIDVID question
In-Reply-To: <704889.9516.qm@web57006.mail.re3.yahoo.com>
References: <704889.9516.qm@web57006.mail.re3.yahoo.com>
Message-ID: <20090108094509.fha2rnz3k884csgo@webmail.trustica.cz>

Hi,

if you check your CPUID, does it support FIDVID?

If yes, then there is another problem. Perhaps you are hit by
some errata which says first is needed not HT reset (LDTSTOP) but PCI reset.
I don't have a code at my hand right now, but is HT reset stuff done
_before_ the fidvid?

Thanks,
Rudolf


----------------------------------------------------------------
This message was sent using IMP, the Internet Messaging Program.




From JasonZhao at viatech.com.cn  Thu Jan  8 12:10:18 2009
From: JasonZhao at viatech.com.cn (JasonZhao at viatech.com.cn)
Date: Thu, 8 Jan 2009 19:10:18 +0800
Subject: [coreboot] how to add some constant bytes into .rom file in
	coreboot v2 and v3?
Message-ID: <9156F9F8217CD44898ABE1E581FAFF882FB47F@exchbj02.viatech.com.bj>

To support VIA's ROMSIP I need to add the bellow constant into .rom
file.
How should I do to achieve this?
The data I need add include:
At ffffffd0, a 4byte pointer (pointto a address X (e.g. 0xffffff70))
At X, 32byte ROMSIP data

Thank you!

-jasonzhao 



From r.marek at assembler.cz  Thu Jan  8 12:21:56 2009
From: r.marek at assembler.cz (Rudolf Marek)
Date: Thu, 08 Jan 2009 12:21:56 +0100
Subject: [coreboot] how to add some constant bytes into .rom file
 in	coreboot v2 and v3?
In-Reply-To: <9156F9F8217CD44898ABE1E581FAFF882FB47F@exchbj02.viatech.com.bj>
References: <9156F9F8217CD44898ABE1E581FAFF882FB47F@exchbj02.viatech.com.bj>
Message-ID: <4965E1D4.8000108@assembler.cz>

Hi check the:
http://tracker.coreboot.org/trac/coreboot/browser/trunk/coreboot-v2/src/southbridge/via/k8t890/romstrap.inc

And the *.lds and Config .lb.

I think you can take it from there.

Rudolf



From ward at gnu.org  Thu Jan  8 14:58:06 2009
From: ward at gnu.org (Ward Vandewege)
Date: Thu, 8 Jan 2009 08:58:06 -0500
Subject: [coreboot] domain vs device statictree order
In-Reply-To: <2831fecf0901072039r52c14481j8e7da3d4ccee7850@mail.gmail.com>
References: <F893D0B3C6794D4BA36DE9DDC72625D3@chimp>
	<2831fecf0901061437k3367b4fbgbf237c66a5af87ff@mail.gmail.com>
	<534e5dc20901061513l3b63756mf0a102cddc33ecc0@mail.gmail.com>
	<2831fecf0901061519i873cdf5ua5110832479f1679@mail.gmail.com>
	<2831fecf0901061529p539d4e80s2bcb8c15abdf06a6@mail.gmail.com>
	<534e5dc20901070905p401b0a5aj2598ccef1a3edec7@mail.gmail.com>
	<2831fecf0901071027t461c3c54rf8fd0b54112b5238@mail.gmail.com>
	<20090108020137.GA20844@localdomain>
	<20090108023135.GA21159@localdomain>
	<2831fecf0901072039r52c14481j8e7da3d4ccee7850@mail.gmail.com>
Message-ID: <20090108135806.GA20056@localdomain>

On Wed, Jan 07, 2009 at 09:39:39PM -0700, Myles Watson wrote:
> > The rev that broke the boot was 1089 or 1090. 1089 does not build, so I can't
> > tell for sure. 1088 boots fine. 1090 is broken.
> 
> They might have well been the same commit because they were
> interdependent.  It was just an easier way of looking at the changes
> for me.
> 
> Thanks for tracking it down.  Could you send me a log from 1088?
> Hopefully we can track it down quickly.

Sure, see attached.

> > Btw: buildrom + artec dongle + alix2c3 -> 40 second turnaround time between
> > boots (and that includes 10 seconds for me). This is *nice*.
> 
> That is nice.  I wish my Tyan boards had < 1min turnaround.

Well, with the dongle + plcc adapter, you might get pretty close to that... I
have not tried with a tyan board and plcc adapter yet though.

Thanks,
Ward.

-- 
Ward Vandewege <ward at fsf.org>
Free Software Foundation - Senior Systems Administrator
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 12.cap.gz
Type: application/octet-stream
Size: 8997 bytes
Desc: not available
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20090108/d415f7b4/attachment.obj>

From uwe at hermann-uwe.de  Thu Jan  8 15:58:39 2009
From: uwe at hermann-uwe.de (Uwe Hermann)
Date: Thu, 8 Jan 2009 15:58:39 +0100
Subject: [coreboot] [PATCH] flashrom: add SST49LF020 support
In-Reply-To: <87zli346o1.fsf@begreifnix.intranet.astaro.de>
References: <877i5ahon6.fsf@apollo.stackframe.org>
	<20090105232701.GD12484@greenwood>
	<87ljtoj0o6.fsf@apollo.stackframe.org>
	<20090107123615.GE7490@greenwood>
	<87zli346o1.fsf@begreifnix.intranet.astaro.de>
Message-ID: <20090108145839.GA8192@greenwood>

On Wed, Jan 07, 2009 at 01:55:26PM +0100, Sven Schnelle wrote:
> Hi Uwe,
> 
> Uwe Hermann <uwe at hermann-uwe.de> writes:
> 
> > Btw, can we mark all the new stuff from your patches as supported in
> > the wiki, i.e. is all of it tested on hardware?
> 
> Yes, they are tested on hardware - i have three Boards here,

OK, wiki updated.


> 2 with the Intel 5000 Chipset,

Is this chipset related to or compatible with the new 631xESB/632xESB/3100
stuff you added in flashrom? Did you test 5000, or 631xESB/632xESB/3100,
or both?


> 1 with AMD 760 Chipset.

Do you mean 780 here?

 
> The reason for adding the Flash/Chipset support is that i want to port/use
> coreboot on these platforms.

Nice! There's some old AMD-768 code in coreboot-v1, maybe you can use
that as inspiration (no idea if or how well that worked back then).
Those files don't have license headers unfortunately, so you can either
start from scratch with a v2 or even v3 code, or find out who wrote that
code and add the proper license headers (judging from the svn commit log
it should be Eric Biederman, GPL2)...

CC'd Eric...


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



From mart.raudsepp at artecdesign.ee  Thu Jan  8 16:29:13 2009
From: mart.raudsepp at artecdesign.ee (Mart Raudsepp)
Date: Thu, 08 Jan 2009 17:29:13 +0200
Subject: [coreboot] domain vs device statictree order
In-Reply-To: <20090108011144.1228.qmail@stuge.se>
References: <534e5dc20901061346g5eb604c5kf63a80f5634a1128@mail.gmail.com>
	<F893D0B3C6794D4BA36DE9DDC72625D3@chimp>
	<2831fecf0901061437k3367b4fbgbf237c66a5af87ff@mail.gmail.com>
	<2831fecf0901071304u26e06834t14a0d5b1f30b815d@mail.gmail.com>
	<20090108011144.1228.qmail@stuge.se>
Message-ID: <1231428553.1723.3.camel@martr-gentoo.artec>

?hel kenal p?eval, N, 2009-01-08 kell 02:11, kirjutas Peter Stuge:
> Myles Watson wrote:
> > This patch implements preorder traversal for Phase 2 and Phase 6, and prints a
> > warning that Phase 1 is obsolete if anyone implements one.
> > 
> > The only difference between the Phase 2 and Phase 6 implementations is
> > that phase2_fixup is always called if it's defined, but phase6_init is
> > only called if the device is enabled.
> > 
> > Note that any devices not found in the tree will not have their init
> > functions called with this patch.  I think that's a good thing, but it
> > will require some dts fixes.

What's the easy way to find out which devices could be missing from the
tree?

> > Boot tested on Serengeti and qemu.
> > 
> > Signed-off-by: Myles Watson <mylesgw at gmail.com>
> 
> Acked-by: Peter Stuge <peter at stuge.se>

This patch is necessary to get GeodeLX to boot again (DBE61). rev1103
had broken it with the memory controller device separation being
committed before, as stuff appears to not be set up right and it resets
in the end parts of stage2. Peter suggested the memory controller isn't
set up right, and something like that appears to be the case then, as
this patch here fixed it up again with the execution order being
changed.


Mart Raudsepp




From svn at coreboot.org  Thu Jan  8 16:44:56 2009
From: svn at coreboot.org (svn at coreboot.org)
Date: Thu,  8 Jan 2009 16:44:56 +0100
Subject: [coreboot] r1105 - coreboot-v3/northbridge/intel/i945
Message-ID: <mailman.2648.1355071467.16123.coreboot@coreboot.org>

Author: uwe
Date: 2009-01-08 16:44:56 +0100 (Thu, 08 Jan 2009)
New Revision: 1105

Modified:
   coreboot-v3/northbridge/intel/i945/i945.h
Log:
Port r3738 from v2 to v3 (build-tested in v3):

945.h: Add some more comments, align data for better readability (trivial).

Also, add missing C1DRA2 #define (as per public datasheet).

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



Modified: coreboot-v3/northbridge/intel/i945/i945.h
===================================================================
--- coreboot-v3/northbridge/intel/i945/i945.h	2009-01-07 18:37:21 UTC (rev 1104)
+++ coreboot-v3/northbridge/intel/i945/i945.h	2009-01-08 15:44:56 UTC (rev 1105)
@@ -31,15 +31,15 @@
 #define X60BAR		0x60
 
 /* Northbridge BARs */
-#define DEFAULT_PCIEXBAR	0xf0000000
+#define DEFAULT_PCIEXBAR	0xf0000000	/* 4 KB per PCIe device */
 #define DEFAULT_X60BAR		0xfed13000
-#define DEFAULT_MCHBAR		0xfed14000
-#define DEFAULT_DMIBAR		0xfed18000
-#define DEFAULT_EPBAR		0xfed19000
+#define DEFAULT_MCHBAR		0xfed14000	/* 16 KB */
+#define DEFAULT_DMIBAR		0xfed18000	/* 4 KB */
+#define DEFAULT_EPBAR		0xfed19000	/* 4 KB */
 
-#define GGC		0x52
+#define GGC		0x52			/* GMCH Graphics Control */
 
-#define DEVEN		0x54
+#define DEVEN		0x54			/* Device Enable */
 #define  DEVEN_D0F0 (1 << 0)
 #define  DEVEN_D1F0 (1 << 1)
 #define  DEVEN_D2F0 (1 << 3)
@@ -48,22 +48,22 @@
 #define BOARD_DEVEN ( DEVEN_D0F0 | DEVEN_D2F0 | DEVEN_D2F1 )
 #endif
 
-#define PAM0	0x90
-#define PAM1	0x91
-#define PAM2	0x92
-#define PAM3	0x93
-#define PAM4	0x94
-#define PAM5	0x95
-#define PAM6	0x96
+#define PAM0		0x90
+#define PAM1		0x91
+#define PAM2		0x92
+#define PAM3		0x93
+#define PAM4		0x94
+#define PAM5		0x95
+#define PAM6		0x96
 
-#define LAC	0x97		/* Legacy Access Control */
-#define TOLUD	0x9c		/* Top of Low Used Memory */
-#define SMRAM	0x9d
-#define ESMRAM	0x9e
+#define LAC		0x97	/* Legacy Access Control */
+#define TOLUD		0x9c	/* Top of Low Used Memory */
+#define SMRAM		0x9d	/* System Management RAM Control */
+#define ESMRAM		0x9e	/* Extended System Management RAM Control */
 
-#define TOM	0xa0
+#define TOM		0xa0
 
-#define SKPAD	0xdc		/* Scratchpad */
+#define SKPAD		0xdc	/* Scratchpad Data */
 
 /* Device 0:1.0 PCI configuration space (PCI Express) */
 
@@ -72,7 +72,7 @@
 
 /* Device 0:2.0 PCI configuration space (Graphics Device) */
 
-#define GCFC		0xf0	/* Graphics Clock Frequency and Gating Control */
+#define GCFC		0xf0	/* Graphics Clock Frequency & Gating Control */
 
 
 /*
@@ -119,6 +119,7 @@
 #define C1DRB2		0x182	/*  8bit */
 #define C1DRB3		0x183	/*  8bit */
 #define C1DRA0		0x188	/*  8bit */
+#define C1DRA2		0x189	/*  8bit */
 #define C1DCLKDIS	0x18c	/*  8bit */
 #define C1BNKARC	0x18e	/* 16bit */
 #define C1DRT0		0x190	/* 32bit */
@@ -152,7 +153,7 @@
 #define DQSMT		0x2f4	/* 16bit */
 #define RCVENMT		0x2f8	/* 32bit */
 
-#define C0R0B00DQST	0x300	/*  64bit */
+#define C0R0B00DQST	0x300	/* 64bit */
 
 #define C0WL0REOST	0x340	/*  8bit */
 #define C0WL1REOST	0x341	/*  8bit */
@@ -162,7 +163,7 @@
 #define C0WDLLCMC	0x36c	/* 32bit */
 #define C0HCTC		0x37c	/*  8bit */
 
-#define C1R0B00DQST	0x380	/*  64bit */
+#define C1R0B00DQST	0x380	/* 64bit */
 
 #define C1WL0REOST	0x3c0	/*  8bit */
 #define C1WL1REOST	0x3c1	/*  8bit */




From mylesgw at gmail.com  Thu Jan  8 16:52:44 2009
From: mylesgw at gmail.com (Myles Watson)
Date: Thu, 8 Jan 2009 08:52:44 -0700
Subject: [coreboot] domain vs device statictree order
In-Reply-To: <20090108135806.GA20056@localdomain>
References: <F893D0B3C6794D4BA36DE9DDC72625D3@chimp>
	<534e5dc20901061513l3b63756mf0a102cddc33ecc0@mail.gmail.com>
	<2831fecf0901061519i873cdf5ua5110832479f1679@mail.gmail.com>
	<2831fecf0901061529p539d4e80s2bcb8c15abdf06a6@mail.gmail.com>
	<534e5dc20901070905p401b0a5aj2598ccef1a3edec7@mail.gmail.com>
	<2831fecf0901071027t461c3c54rf8fd0b54112b5238@mail.gmail.com>
	<20090108020137.GA20844@localdomain>
	<20090108023135.GA21159@localdomain>
	<2831fecf0901072039r52c14481j8e7da3d4ccee7850@mail.gmail.com>
	<20090108135806.GA20056@localdomain>
Message-ID: <2831fecf0901080752p49b3621dj2c073588f8d119c5@mail.gmail.com>

On Thu, Jan 8, 2009 at 6:58 AM, Ward Vandewege <ward at gnu.org> wrote:
> On Wed, Jan 07, 2009 at 09:39:39PM -0700, Myles Watson wrote:
>> > The rev that broke the boot was 1089 or 1090. 1089 does not build, so I can't
>> > tell for sure. 1088 boots fine. 1090 is broken.
>>
>> They might have well been the same commit because they were
>> interdependent.  It was just an easier way of looking at the changes
>> for me.
>>
>> Thanks for tracking it down.  Could you send me a log from 1088?
>> Hopefully we can track it down quickly.
>
> Sure, see attached.

The biggest difference that I see is that there is no graphics device
(PCI 1.1) in the broken one.  In 1088 it was found dynamically (not in
the tree), but now it isn't found at all.

Since it was supposed to be disabled by:
	/* this board does not really have vga; disable it (pci device 00:01.1)  */
			unwanted_vpci = < 80000900 0 >;
in the dts, I'm not sure why it disappeared now.

Possible solution:
- Try it again without the unwanted_vpci line in the dts.

I guess I don't understand why the device is gone now.  I didn't think
the changes I've made would make the device disappear.

>> > Btw: buildrom + artec dongle + alix2c3 -> 40 second turnaround time between
>> > boots (and that includes 10 seconds for me). This is *nice*.
>>
>> That is nice.  I wish my Tyan boards had < 1min turnaround.
>
> Well, with the dongle + plcc adapter, you might get pretty close to that... I
> have not tried with a tyan board and plcc adapter yet though.
Good to know.

Thanks,
Myles



From svn at coreboot.org  Thu Jan  8 17:01:25 2009
From: svn at coreboot.org (svn at coreboot.org)
Date: Thu,  8 Jan 2009 17:01:25 +0100
Subject: [coreboot] r1106 - coreboot-v3/northbridge/intel/i945
Message-ID: <mailman.2649.1355071468.16123.coreboot@coreboot.org>

Author: uwe
Date: 2009-01-08 17:01:25 +0100 (Thu, 08 Jan 2009)
New Revision: 1106

Modified:
   coreboot-v3/northbridge/intel/i945/i945.h
   coreboot-v3/northbridge/intel/i945/raminit.c
   coreboot-v3/northbridge/intel/i945/rcven.c
Log:
Port relevant parts of r3741 from v2 to v3 (build-tested on v3):

Merge some parts of the i945 review (trivial):

* fix \r\n occurence in i945 code
* drop early TOLUD write
* fix 16bit BCTRL1 access

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



Modified: coreboot-v3/northbridge/intel/i945/i945.h
===================================================================
--- coreboot-v3/northbridge/intel/i945/i945.h	2009-01-08 15:44:56 UTC (rev 1105)
+++ coreboot-v3/northbridge/intel/i945/i945.h	2009-01-08 16:01:25 UTC (rev 1106)
@@ -67,7 +67,7 @@
 
 /* Device 0:1.0 PCI configuration space (PCI Express) */
 
-#define BCTRL1		0x3e	/*  8bit */
+#define BCTRL1		0x3e	/* 16bit */
 
 
 /* Device 0:2.0 PCI configuration space (Graphics Device) */

Modified: coreboot-v3/northbridge/intel/i945/raminit.c
===================================================================
--- coreboot-v3/northbridge/intel/i945/raminit.c	2009-01-08 15:44:56 UTC (rev 1105)
+++ coreboot-v3/northbridge/intel/i945/raminit.c	2009-01-08 16:01:25 UTC (rev 1106)
@@ -1158,7 +1158,7 @@
 
 static int i945_silicon_revision(void)
 {
-	return pci_conf1_read_config8(PCI_BDF(0, 0x00, 0), 8);
+	return pci_conf1_read_config8(PCI_BDF(0, 0x00, 0), PCI_CLASS_REVISION);
 }
 
 static void sdram_force_rcomp(void)
@@ -1435,11 +1435,15 @@
 		tolud = (cum0 + cum1) << 1;
 	else
 		tolud = (cum1 ? cum1 : cum0)  << 1;
-	pci_conf1_write_config16(PCI_BDF(0,0,0), TOLUD, tolud);
-	
+
+	/* Some extra checks needed. See 4.1.26 in the 
+	 * 82945G MCH datasheet (30750203)
+	 */
+	pci_conf1_write_config8(PCI_BDF(0,0,0), TOLUD, tolud);
+
 	printk(BIOS_DEBUG, "C0DRB = 0x%08x\n", MCHBAR32(C0DRB0));
 	printk(BIOS_DEBUG, "C1DRB = 0x%08x\n", MCHBAR32(C1DRB0));
-	printk(BIOS_DEBUG, "TOLUD = 0x%04x\n", tolud);
+	printk(BIOS_DEBUG, "TOLUD = 0x%02x\n", tolud);
 
 	pci_conf1_write_config16(PCI_BDF(0,0,0), TOM, tolud>>3);
 
@@ -2837,8 +2841,6 @@
 	pci_conf1_write_config8(PCI_BDF(0, 0x00, 0), PAM5, 0x33);
 	pci_conf1_write_config8(PCI_BDF(0, 0x00, 0), PAM6, 0x33);
 
-	pci_conf1_write_config8(PCI_BDF(0, 0x00, 0), TOLUD, 0x40);	/* 1G XXX dynamic! */
-
 	pci_conf1_write_config32(PCI_BDF(0, 0x00, 0), SKPAD, 0xcafebabe);
 	printk(BIOS_DEBUG, " done.\n");
 
@@ -3141,24 +3143,23 @@
 	u32 timeout;
 	u32 reg32;
 	u16 reg16;
-	u8 reg8;
 
 	/* For now we just disable the x16 link */
 	printk(BIOS_DEBUG, "Disabling PCI Express x16 Link\n");
 
 	MCHBAR16(UPMC1) |= (1 << 5) | (1 << 0);
 
-	reg8 = pcie_read_config8(PCI_BDF(0, 0x01, 0), BCTRL1);
-	reg8 |= (1 << 6);
-	pcie_write_config8(PCI_BDF(0, 0x01, 0), BCTRL1, reg8);
+	reg16 = pcie_read_config16(PCI_BDF(0, 0x01, 0), BCTRL1);
+	reg16 |= (1 << 6);
+	pcie_write_config16(PCI_BDF(0, 0x01, 0), BCTRL1, reg16);
 
 	reg32 = pcie_read_config32(PCI_BDF(0, 0x01, 0), 0x224);
 	reg32 |= (1 << 8);
 	pcie_write_config32(PCI_BDF(0, 0x01, 0), 0x224, reg32);
 
-	reg8 = pcie_read_config8(PCI_BDF(0, 0x01, 0), BCTRL1);
-	reg8 &= ~(1 << 6);
-	pcie_write_config8(PCI_BDF(0, 0x01, 0), BCTRL1, reg8);
+	reg16 = pcie_read_config16(PCI_BDF(0, 0x01, 0), BCTRL1);
+	reg16 &= ~(1 << 6);
+	pcie_write_config16(PCI_BDF(0, 0x01, 0), BCTRL1, reg16);
 
 	printk(BIOS_DEBUG, "Wait for link to enter detect state... ");
 	timeout = 0x7fffff;

Modified: coreboot-v3/northbridge/intel/i945/rcven.c
===================================================================
--- coreboot-v3/northbridge/intel/i945/rcven.c	2009-01-08 15:44:56 UTC (rev 1105)
+++ coreboot-v3/northbridge/intel/i945/rcven.c	2009-01-08 16:01:25 UTC (rev 1106)
@@ -82,7 +82,7 @@
 {
 	u32 reg32;
 
-	printk(BIOS_SPEW, "    set_receive_enable() medium=0x%x, coarse=0x%x\r\n", medium, coarse);
+	printk(BIOS_SPEW, "    set_receive_enable() medium=0x%x, coarse=0x%x\n", medium, coarse);
 	
 	reg32 = MCHBAR32(C0DRT1 + channel_offset);
 	reg32 &= 0xf0ffffff;
@@ -116,7 +116,7 @@
 
 static int normalize(int channel_offset, u8 * mediumcoarse, u8 * fine)
 {
-	printk(BIOS_SPEW, "  normalize()\r\n");
+	printk(BIOS_SPEW, "  normalize()\n");
 
 	if (*fine < 0x80)
 		return 0;
@@ -125,7 +125,7 @@
 	*mediumcoarse += 1;
 
 	if (*mediumcoarse >= 0x40) {
-		printk(BIOS_DEBUG, "Normalize Error\r\n");
+		printk(BIOS_DEBUG, "Normalize Error\n");
 		return -1;
 	}
 
@@ -143,12 +143,12 @@
 	/* find start of the data phase */
 	u32 reg32;
 
-	printk(BIOS_SPEW, "  find_preamble()\r\n");
+	printk(BIOS_SPEW, "  find_preamble()\n");
 
 	do {
 		if (*mediumcoarse < 4) {
 			
-			printk(BIOS_DEBUG, "No Preamble found.\r\n");
+			printk(BIOS_DEBUG, "No Preamble found.\n");
 			return -1;
 		}
 		*mediumcoarse -= 4;
@@ -162,7 +162,7 @@
 
 	if (!(reg32 & (1 << 18))) {	
 		
-		printk(BIOS_DEBUG, "No Preamble found (neither high nor low).\r\n");
+		printk(BIOS_DEBUG, "No Preamble found (neither high nor low).\n");
 		return -1;
 	}
 
@@ -175,14 +175,14 @@
 
 static int add_quarter_clock(int channel_offset, u8 * mediumcoarse, u8 * fine)
 {
-	printk(BIOS_SPEW, "  add_quarter_clock() mediumcoarse=%02x fine=%02x\r\n",
+	printk(BIOS_SPEW, "  add_quarter_clock() mediumcoarse=%02x fine=%02x\n",
 			*mediumcoarse, *fine);
 	if (*fine >= 0x80) {
 		*fine -= 0x80;
 
 		*mediumcoarse += 2;
 		if (*mediumcoarse >= 0x40) {
-			printk(BIOS_DEBUG, "clocks at max.\r\n");
+			printk(BIOS_DEBUG, "clocks at max.\n");
 			return -1;
 		}
 
@@ -202,7 +202,7 @@
 {
 	u32 rcvenmt;
 
-	printk(BIOS_SPEW, "  find_strobes_low()\r\n");
+	printk(BIOS_SPEW, "  find_strobes_low()\n");
 	
 	for (;;) {
 		MCHBAR8(C0WL0REOST + channel_offset) = *fine;
@@ -228,7 +228,7 @@
 
 	}
 
-	printk(BIOS_DEBUG, "Could not find low strobe\r\n");
+	printk(BIOS_DEBUG, "Could not find low strobe\n");
 	return 0;
 }
 
@@ -238,7 +238,7 @@
 	int counter;
 	u32 rcvenmt;
 
-	printk(BIOS_SPEW, "  find_strobes_edge()\r\n");
+	printk(BIOS_SPEW, "  find_strobes_edge()\n");
 
 	counter = 8;
 	set_receive_enable(channel_offset, *mediumcoarse & 3,
@@ -273,7 +273,7 @@
 			continue;
 		}
 
-		printk(BIOS_DEBUG, "could not find rising edge.\r\n");
+		printk(BIOS_DEBUG, "could not find rising edge.\n");
 		return -1;
 	}
 	
@@ -302,7 +302,7 @@
 	u8 mediumcoarse;
 	u8 fine;
 
-	printk(BIOS_SPEW, "receive_enable_autoconfig() for channel %d\r\n",
+	printk(BIOS_SPEW, "receive_enable_autoconfig() for channel %d\n",
 		    channel_offset ? 1 : 0);
 
 	/* Set initial values */




From mylesgw at gmail.com  Thu Jan  8 17:08:14 2009
From: mylesgw at gmail.com (Myles Watson)
Date: Thu, 8 Jan 2009 09:08:14 -0700
Subject: [coreboot] domain vs device statictree order
In-Reply-To: <1231428553.1723.3.camel@martr-gentoo.artec>
References: <534e5dc20901061346g5eb604c5kf63a80f5634a1128@mail.gmail.com>
	<F893D0B3C6794D4BA36DE9DDC72625D3@chimp>
	<2831fecf0901061437k3367b4fbgbf237c66a5af87ff@mail.gmail.com>
	<2831fecf0901071304u26e06834t14a0d5b1f30b815d@mail.gmail.com>
	<20090108011144.1228.qmail@stuge.se>
	<1231428553.1723.3.camel@martr-gentoo.artec>
Message-ID: <2831fecf0901080808p462a2fb6oe1caae856d12e3f7@mail.gmail.com>

On Thu, Jan 8, 2009 at 8:29 AM, Mart Raudsepp
<mart.raudsepp at artecdesign.ee> wrote:
> ?hel kenal p?eval, N, 2009-01-08 kell 02:11, kirjutas Peter Stuge:
>> Myles Watson wrote:
>> > This patch implements preorder traversal for Phase 2 and Phase 6, and prints a
>> > warning that Phase 1 is obsolete if anyone implements one.
>> >
>> > The only difference between the Phase 2 and Phase 6 implementations is
>> > that phase2_fixup is always called if it's defined, but phase6_init is
>> > only called if the device is enabled.
>> >
>> > Note that any devices not found in the tree will not have their init
>> > functions called with this patch.  I think that's a good thing, but it
>> > will require some dts fixes.
>
> What's the easy way to find out which devices could be missing from the
> tree?

If you look at the device tree that's printed "after phase 3", any
device that is dynamic wasn't found in the device tree.  PCI cards
that you plug in will never be in the dts, so they will always be
dynamic.

>> > Boot tested on Serengeti and qemu.
>> >
>> > Signed-off-by: Myles Watson <mylesgw at gmail.com>
>>
>> Acked-by: Peter Stuge <peter at stuge.se>
>
> This patch is necessary to get GeodeLX to boot again (DBE61). rev1103
> had broken it with the memory controller device separation being
> committed before, as stuff appears to not be set up right and it resets
> in the end parts of stage2. Peter suggested the memory controller isn't
> set up right, and something like that appears to be the case then, as
> this patch here fixed it up again with the execution order being
> changed.

I'm glad it fixes it.  Thanks for testing.

Myles



From svn at coreboot.org  Thu Jan  8 17:14:13 2009
From: svn at coreboot.org (svn at coreboot.org)
Date: Thu,  8 Jan 2009 17:14:13 +0100
Subject: [coreboot] r1107 - in coreboot-v3: northbridge/intel/i945
	southbridge/intel/i82801gx
Message-ID: <mailman.2650.1355071468.16123.coreboot@coreboot.org>

Author: uwe
Date: 2009-01-08 17:14:12 +0100 (Thu, 08 Jan 2009)
New Revision: 1107

Modified:
   coreboot-v3/northbridge/intel/i945/ich7.h
   coreboot-v3/southbridge/intel/i82801gx/i82801gx.h
   coreboot-v3/southbridge/intel/i82801gx/lpc.c
Log:
Port r3747, r3732, r3733 from v2 to v3 (build-tested on v3):

src/northbridge/intel/i945/ich7.h:

Thanks to Uwe Hermann for spotting this typo.


src/southbridge/intel/i82801gx/i82801gx_lpc.c:

The enable_hpet() code in intel/i82801gx will not work with the
ICH7 southbridge (but it might work with ICH4/ICH5 or so).
The ICH7 needs a different init code. Drop the non-working code for now.


src/southbridge/intel/i82801gx/i82801gx.h:

Drop #defines for registers that are not existant on the ICH7.
Also, fix BIOS_CNTL, which is 0xdc on ICH7.
Build-tested with kontron/986lcd-m.

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



Modified: coreboot-v3/northbridge/intel/i945/ich7.h
===================================================================
--- coreboot-v3/northbridge/intel/i945/ich7.h	2009-01-08 16:01:25 UTC (rev 1106)
+++ coreboot-v3/northbridge/intel/i945/ich7.h	2009-01-08 16:14:12 UTC (rev 1107)
@@ -60,7 +60,7 @@
 #define RP2D		0x0130	/* 32bit */
 #define RP2BA		0x0138	/* 64bit */
 #define RP3D		0x0140	/* 32bit */
-#define RP3BA		0x0138	/* 64bit */
+#define RP3BA		0x0148	/* 64bit */
 #define RP4D		0x0150	/* 32bit */
 #define RP4BA		0x0158	/* 64bit */
 #define HDD		0x0160	/* 32bit */

Modified: coreboot-v3/southbridge/intel/i82801gx/i82801gx.h
===================================================================
--- coreboot-v3/southbridge/intel/i82801gx/i82801gx.h	2009-01-08 16:01:25 UTC (rev 1106)
+++ coreboot-v3/southbridge/intel/i82801gx/i82801gx.h	2009-01-08 16:14:12 UTC (rev 1107)
@@ -22,18 +22,20 @@
 #define SOUTHBRIDGE_INTEL_I82801GX_I82801GX_H
 
 /* warning: included in stage1 and stage2 */
-#define PCI_DMA_CFG		0x90
 #define SERIRQ_CNTL		0x64
-#define GEN_CNTL		0xd0
-#define GEN_STS			0xd4
-#define RTC_CONF		0xd8
+
 #define GEN_PMCON_1		0xa0
 #define GEN_PMCON_2		0xa2
 #define GEN_PMCON_3		0xa4
 
+/* GEN_PMCON_3 bits */
+#define RTC_BATTERY_DEAD	(1 << 2)
+#define RTC_POWER_FAILED	(1 << 1)
+#define SLEEP_AFTER_POWER_FAIL	(1 << 0)
+
 #define PMBASE			0x40
 #define ACPI_CNTL		0x44
-#define BIOS_CNTL		0x4E
+#define BIOS_CNTL		0xDC
 #define GPIO_BASE		0x48 /* LPC GPIO Base Address Register */
 #define GPIO_CNTL		0x4C /* LPC GPIO Control Register */
 
@@ -46,28 +48,10 @@
 #define PIRQG_ROUT		0x6A
 #define PIRQH_ROUT		0x6B
 
-#define FUNC_DIS		0xF2
-
 #define LPC_IO_DEC		0x80 /* IO Decode Ranges Register */
 #define LPC_EN			0x82 /* LPC IF Enables Register */
 
-#define SBUS_NUM		0x19
-#define SUB_BUS_NUM		0x1A
-#define SMLT			0x1B
-#define IOBASE			0x1C
-#define IOLIM			0x1D
-#define MEMBASE			0x20
-#define MEMLIM			0x22
-#define CNF			0x50
-#define MTT			0x70
-#define PCI_MAST_STS		0x82
-
-/* GEN_PMCON_3 bits */
-#define RTC_BATTERY_DEAD	(1 << 2)
-#define RTC_POWER_FAILED	(1 << 1)
-#define SLEEP_AFTER_POWER_FAIL	(1 << 0)
-
-/* PCI Configuration Space (D31:F1) */
+/* PCI Configuration Space (D31:F1): IDE */
 #define INTR_LN			0x3c
 #define IDE_TIM_PRI		0x40	/* IDE timings, primary */
 #define   IDE_DECODE_ENABLE	(1 << 15)
@@ -82,7 +66,7 @@
 #define   PCB1			(1 <<  1)
 #define   PCB0			(1 <<  0)
 
-/* PCI Configuration Space (D31:F3) */
+/* PCI Configuration Space (D31:F3): SMBus */
 #define SMB_BASE		0x20
 #define HOSTC			0x40
 

Modified: coreboot-v3/southbridge/intel/i82801gx/lpc.c
===================================================================
--- coreboot-v3/southbridge/intel/i82801gx/lpc.c	2009-01-08 16:01:25 UTC (rev 1106)
+++ coreboot-v3/southbridge/intel/i82801gx/lpc.c	2009-01-08 16:14:12 UTC (rev 1107)
@@ -201,22 +201,7 @@
 
 static void enable_hpet(struct device *dev)
 {
-	u32 reg32;
-	u32 code = (0 & 0x3);
-
-	reg32 = pci_read_config32(dev, GEN_CNTL);
-	reg32 |= (1 << 17);	/* Enable HPET. */
-	/*
-	 * Bits [16:15]	Memory Address Range
-	 * 00		FED0_0000h - FED0_03FFh
-	 * 01		FED0_1000h - FED0_13FFh
-	 * 10		FED0_2000h - FED0_23FFh
-	 * 11		FED0_3000h - FED0_33FFh
-	 */
-	reg32 &= ~(3 << 15);	/* Clear it */
-	reg32 |= (code << 15);
-	/* TODO: reg32 is never written to anywhere? */
-	printk(BIOS_DEBUG, "Enabling HPET @0x%x\n", HPET_ADDR | (code << 12));
+	/* TODO */
 }
 
 static void i82801gx_lock_smm(struct device *dev)




From svn at coreboot.org  Thu Jan  8 17:19:51 2009
From: svn at coreboot.org (svn at coreboot.org)
Date: Thu,  8 Jan 2009 17:19:51 +0100
Subject: [coreboot] r1108 - coreboot-v3/device
Message-ID: <mailman.2651.1355071468.16123.coreboot@coreboot.org>

Author: myles
Date: 2009-01-08 17:19:51 +0100 (Thu, 08 Jan 2009)
New Revision: 1108

Modified:
   coreboot-v3/device/device.c
Log:
This patch implements preorder traversal for Phase 2 and Phase 6, and prints a
warning that Phase 1 is obsolete if anyone implements one.

The only difference between the Phase 2 and Phase 6 implementations is that
phase2_fixup is always called if it's defined, but phase6_init is only called if
the device is enabled.

Note that any devices not found in the tree will not have their init functions
called with this patch.  I think that's a good thing, but it will require some
dts fixes.

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


Modified: coreboot-v3/device/device.c
===================================================================
--- coreboot-v3/device/device.c	2009-01-08 16:14:12 UTC (rev 1107)
+++ coreboot-v3/device/device.c	2009-01-08 16:19:51 UTC (rev 1108)
@@ -989,6 +989,7 @@
 	printk(BIOS_DEBUG, "Phase 1: Very early setup...\n");
 	for (dev = all_devices; dev; dev = dev->next) {
 		if (dev->ops && dev->ops->phase1_set_device_operations) {
+			printk(BIOS_WARNING, "Phase 1 is obsolete...\n");
 			dev->ops->phase1_set_device_operations(dev);
 		}
 	}
@@ -997,32 +998,38 @@
 	post_code(POST_STAGE2_PHASE1_EXIT);
 }
 
+/*
+ * Starting at the root device, walk the tree and call the device's phase2()
+ * method to do early setup.  It's done parents before children in case there
+ * are dependencies.
+ */
+void phase2_tree(struct device *root)
+{
+	struct device *child;
+	unsigned link;
+
+	if (root->ops && root->ops->phase2_fixup) {
+		printk(BIOS_DEBUG, "Phase 2: %s fixup.\n", dev_path(root));
+		root->ops->phase2_fixup(root);
+	}
+	for (link = 0; link < root->links; link++) {
+		for (child = root->link[link].children; child;
+		     child = child->sibling) {
+			phase2_tree(child);
+		}
+	}
+}
+
 /**
- * Do early setup for all devices in the global device list.
- *
- * Starting at the first device on the global device link list,
- * walk the list and call the device's phase2() method to do
- * early setup.
+ * Do early setup for all devices in the global device tree.
  */
 void dev_phase2(void)
 {
-	struct device *dev;
-
 	post_code(POST_STAGE2_PHASE2_ENTER);
 	printk(BIOS_DEBUG, "Phase 2: Early setup...\n");
-	for (dev = all_devices; dev; dev = dev->next) {
-		printk(BIOS_SPEW,
-		       "%s: dev %s: ops %sNULL ops->phase2_fixup %s\n",
-		       __FUNCTION__, dev->dtsname, dev->ops ? "NOT " : "",
-		       dev->ops ? (dev->ops->phase2_fixup ? "NOT NULL" : "NULL")
-		       : "N/A");
-		if (dev->ops && dev->ops->phase2_fixup) {
-			printk(BIOS_SPEW, "Calling phase2 phase2_fixup...\n");
-			dev->ops->phase2_fixup(dev);
-			printk(BIOS_SPEW, "phase2_fixup done\n");
-		}
-	}
 
+	phase2_tree(&dev_root);
+
 	post_code(POST_STAGE2_PHASE2_DONE);
 	printk(BIOS_DEBUG, "Phase 2: Done.\n");
 	post_code(POST_STAGE2_PHASE2_EXIT);
@@ -1321,28 +1328,36 @@
 	printk(BIOS_INFO, "Phase 5: Done.\n");
 }
 
+/*
+ * Walk the device tree and call the device's phase6_init() method.  It's done
+ * preorder (parents before children) in case there are dependencies.
+ */
+void phase6_tree(struct device *root)
+{
+	struct device *child;
+	unsigned link;
+
+	if (root->enabled && root->ops && root->ops->phase6_init) {
+		printk(BIOS_DEBUG, "Phase 6: %s init.\n", dev_path(root));
+		root->ops->phase6_init(root);
+	}
+	for (link = 0; link < root->links; link++) {
+		for (child = root->link[link].children; child;
+		     child = child->sibling) {
+			phase6_tree(child);
+		}
+	}
+}
+
 /**
- * Initialize all devices in the global device list.
- *
- * Starting at the first device on the global device link list, walk the list
- * and call the device's init() method to do device specific setup.
+ * Initialize all devices in the device tree.
  */
 void dev_phase6(void)
 {
-	struct device *dev;
+	printk(BIOS_INFO, "Phase 6: Initializing devices...\n");
 
-	printk(BIOS_INFO, "Phase 6: Initializing devices...\n");
-	for (dev = all_devices; dev; dev = dev->next) {
-		if (dev->enabled && dev->ops && dev->ops->phase6_init) {
-			if (dev->path.type == DEVICE_PATH_I2C) {
-				printk(BIOS_DEBUG, "Phase 6: smbus: %s[%d]->",
-				       dev_path(dev->bus->dev), dev->bus->link);
-			}
-			printk(BIOS_DEBUG, "Phase 6: %s init.\n",
-			       dev_path(dev));
-			dev->ops->phase6_init(dev);
-		}
-	}
+	phase6_tree(&dev_root);
+
 	printk(BIOS_INFO, "Phase 6: Devices initialized.\n");
 }
 




From mylesgw at gmail.com  Thu Jan  8 17:20:46 2009
From: mylesgw at gmail.com (Myles Watson)
Date: Thu, 8 Jan 2009 09:20:46 -0700
Subject: [coreboot] domain vs device statictree order
In-Reply-To: <20090108011144.1228.qmail@stuge.se>
References: <534e5dc20901061346g5eb604c5kf63a80f5634a1128@mail.gmail.com>
	<F893D0B3C6794D4BA36DE9DDC72625D3@chimp>
	<2831fecf0901061437k3367b4fbgbf237c66a5af87ff@mail.gmail.com>
	<2831fecf0901071304u26e06834t14a0d5b1f30b815d@mail.gmail.com>
	<20090108011144.1228.qmail@stuge.se>
Message-ID: <2831fecf0901080820q736ed41fpf3c37a2ae18439cc@mail.gmail.com>

On Wed, Jan 7, 2009 at 6:11 PM, Peter Stuge <peter at stuge.se> wrote:
> Myles Watson wrote:
>> This patch implements preorder traversal for Phase 2 and Phase 6, and prints a
>> warning that Phase 1 is obsolete if anyone implements one.
>>
>> The only difference between the Phase 2 and Phase 6 implementations is
>> that phase2_fixup is always called if it's defined, but phase6_init is
>> only called if the device is enabled.
>>
>> Note that any devices not found in the tree will not have their init
>> functions called with this patch.  I think that's a good thing, but it
>> will require some dts fixes.
>>
>> Boot tested on Serengeti and qemu.
>>
>> Signed-off-by: Myles Watson <mylesgw at gmail.com>
>
> Acked-by: Peter Stuge <peter at stuge.se>

Rev 1108.

Thanks,
Myles



From svn at coreboot.org  Thu Jan  8 17:22:40 2009
From: svn at coreboot.org (svn at coreboot.org)
Date: Thu,  8 Jan 2009 17:22:40 +0100
Subject: [coreboot] r1109 - in coreboot-v3: mainboard/amd/dbm690t
	mainboard/amd/serengeti mainboard/gigabyte/m57sli northbridge/amd/k8
Message-ID: <mailman.2652.1355071468.16123.coreboot@coreboot.org>

Author: myles
Date: 2009-01-08 17:22:39 +0100 (Thu, 08 Jan 2009)
New Revision: 1109

Modified:
   coreboot-v3/mainboard/amd/dbm690t/dts
   coreboot-v3/mainboard/amd/serengeti/dts
   coreboot-v3/mainboard/gigabyte/m57sli/dts
   coreboot-v3/northbridge/amd/k8/domain.c
Log:
This is a small HT fixup until HT links get figured out better.

It removes processors from the list of devices on the domain's bus so
that pci_scan_bus won't disable them, then scans for them, then puts
them back.  There are lots of other ways to do this, but this one
seemed minimally invasive and ends up with a correct tree.

The dts fixups I should have put in with the other K8 patch for the
new resource allocator.  I went to the v2 Config.lb files and tried to
get them as complete as possible.

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


Modified: coreboot-v3/mainboard/amd/dbm690t/dts
===================================================================
--- coreboot-v3/mainboard/amd/dbm690t/dts	2009-01-08 16:19:51 UTC (rev 1108)
+++ coreboot-v3/mainboard/amd/dbm690t/dts	2009-01-08 16:22:39 UTC (rev 1109)
@@ -66,52 +66,75 @@
 /{
 	device_operations="dbm690t";
 	mainboard_vendor = "AMD";
-	mainboard_name = "Serengeti";
+	mainboard_name = "dbm690t";
 	cpus { };
 	apic at 0 {
 	};
 	domain at 0 {
 		/config/("northbridge/amd/k8/domain");
-		pci at 1,0{
+		/* Make sure that the HT device is first; if it isn't found,
+		 * the rest of the devices won't be found.
+		 */
+		pci at 0 {
+			/config/("southbridge/amd/rs690/ht.dts");
 		};
-		/* guesses; we need a real lspci */
-		pci0 at 18,0 {
-			/config/("northbridge/amd/k8/pci");
-			/* make sure that the ht device is first, as it controls many other things. */
-			pci0 {
-				/config/("southbridge/amd/rs690/ht.dts");
-			};
-			pci1{
+		pci at 1{
+			/config/("southbridge/amd/sb600/pci.dts");
+			pci at 5{
 				/config/("southbridge/amd/rs690/gfx.dts");
 			};
-			pci2{
-				/config/("southbridge/amd/rs690/pcie.dts");
+		};
+		pci at 6{ /* Port 2 */
+			/config/("southbridge/amd/rs690/pcie.dts");
+		};
+		pci at 7{ /* Port 3 */
+			/config/("southbridge/amd/rs690/pcie.dts");
+		};
+		pci at 12{
+			/config/("southbridge/amd/sb600/hda.dts");
+		};
+		pci at 13,0{
+			/config/("southbridge/amd/sb600/usb.dts");
+		};
+		pci at 13,1{
+			/config/("southbridge/amd/sb600/usb.dts");
+		};
+		pci at 13,2{
+			/config/("southbridge/amd/sb600/usb.dts");
+		};
+		pci at 13,3{
+			/config/("southbridge/amd/sb600/usb.dts");
+		};
+		pci at 13,4{
+			/config/("southbridge/amd/sb600/usb.dts");
+		};
+		pci at 13,5{
+			/config/("southbridge/amd/sb600/usb2.dts");
+		};
+		pci at 14,0{
+			/config/("southbridge/amd/sb600/sm.dts");
+		};
+		pci at 14,1{
+			/config/("southbridge/amd/sb600/ide.dts");
+		};
+		pci at 14,2{
+			/config/("southbridge/amd/sb600/ac97audio.dts");
+		};
+		pci at 14,3{
+			/config/("southbridge/amd/sb600/lpc.dts");
+			ioport at 2e {
+				/config/("superio/ite/it8712f/dts");
+				com1enable = "1";
 			};
-			pci4{
-				/config/("southbridge/amd/sb600/hda.dts");
-			};
-			pci5{
-				/config/("southbridge/amd/sb600/usb.dts");
-			};
-			pci6{
-				/config/("southbridge/amd/sb600/usb2.dts");
-			};
 		};
-		pci1 at 18,0 {
-			/config/("northbridge/amd/k8/pci");
+		pci at 14,4{
+			/config/("southbridge/amd/sb600/pci.dts");
 		};
-		pci2 at 18,0 {
+		pci at 18,0 {
 			/config/("northbridge/amd/k8/pci");
-			/* just for illustrating link #2 */
-			pci at 2,0{
-			};
 		};
 		pci at 18,1 {};
 		pci at 18,2 {};
 		pci at 18,3 {};
-		ioport at 2e {
-			/config/("superio/ite/it8712f/dts");
-			com1enable = "1";
-		};
 	};
 };

Modified: coreboot-v3/mainboard/amd/serengeti/dts
===================================================================
--- coreboot-v3/mainboard/amd/serengeti/dts	2009-01-08 16:19:51 UTC (rev 1108)
+++ coreboot-v3/mainboard/amd/serengeti/dts	2009-01-08 16:22:39 UTC (rev 1109)
@@ -22,76 +22,82 @@
 	device_operations="serengeti";
 	mainboard_vendor = "AMD";
 	mainboard_name = "Serengeti";
-	subsystem_vendor = "PCI_VENDOR_ID_AMD";
-	subsystem_device = "0x2b80";
+	mainboard_pci_subsystem_vendor = "PCI_VENDOR_ID_AMD";
+	mainboard_pci_subsystem_device = "0x2b80";
 	cpus { };
 	apic at 0 {
 		/config/("northbridge/amd/k8/apic");
 	};
 	domain at 0 {
 		/config/("northbridge/amd/k8/domain");
-		pci at 18,0 {
-			/config/("northbridge/amd/k8/pci");
-			pci_a at 0,0 {
-				/config/("southbridge/amd/amd8132/pcix.dts");
-				};
-			pci_a at 0,1 {
-				/config/("southbridge/amd/amd8132/apic.dts");
-				};
-			pci_a at 1,0 {
-				/config/("southbridge/amd/amd8132/pcix.dts");
-				};
-			pci_a at 1,1 {
-				/config/("southbridge/amd/amd8132/apic.dts");
-				};
-			pci at 0,0 {
-				/config/("southbridge/amd/amd8111/pci.dts");
-				pci at 0,0{
-					/config/("southbridge/amd/amd8111/usb.dts");
-				};
-				pci at 0,1{
-					/config/("southbridge/amd/amd8111/usb.dts");
-				};
-				pci at 0,2{
-					/config/("southbridge/amd/amd8111/usb2.dts");
-					disabled;
-				};
-				pci at 1,0{
-					/config/("southbridge/amd/amd8111/nic.dts");
-					disabled;
-				};
+		pci_a at 0,0 {
+			/config/("southbridge/amd/amd8132/pcix.dts");
 			};
-			pci at 1,0 {
-				/config/("southbridge/amd/amd8111/lpc.dts");
-				ioport at 2e {
-					/config/("superio/winbond/w83627hf/dts");
-					kbenable = "1";
-					com1enable = "1";
-					hwmenable = "1";
-				};
+		pci_a at 0,1 {
+			/config/("southbridge/amd/amd8132/apic.dts");
 			};
-			pci at 1,1 {
-				/config/("southbridge/amd/amd8111/ide.dts");
-				ide0_enable = "1";
-				ide1_enable = "1";
+		pci_a at 1,0 {
+			/config/("southbridge/amd/amd8132/pcix.dts");
 			};
-			pci at 1,2 {
-				/config/("southbridge/amd/amd8111/smbus.dts");
+		pci_a at 1,1 {
+			/config/("southbridge/amd/amd8132/apic.dts");
 			};
-			pci at 1,3 {
-				/config/("southbridge/amd/amd8111/acpi.dts");
+		pci at 0,0 {
+			/config/("southbridge/amd/amd8111/pci.dts");
+			pci at 0,0{
+				/config/("southbridge/amd/amd8111/usb.dts");
 			};
-			pci at 1,5 {
-				/config/("southbridge/amd/amd8111/ac97audio.dts");
+			pci at 0,1{
+				/config/("southbridge/amd/amd8111/usb.dts");
+			};
+			pci at 0,2{
+				/config/("southbridge/amd/amd8111/usb2.dts");
 				disabled;
 			};
-			pci at 1,6 {
-				/config/("southbridge/amd/amd8111/ac97modem.dts");
+			pci at 1,0{
+				/config/("southbridge/amd/amd8111/nic.dts");
 				disabled;
 			};
-			pci at 1,7 {
+		};
+		pci at 1,0 {
+			/config/("southbridge/amd/amd8111/lpc.dts");
+			ioport at 2e {
+				/config/("superio/winbond/w83627hf/dts");
+				kbenable = "1";
+				com1enable = "1";
+				hwmenable = "1";
 			};
 		};
+		pci at 1,1 {
+			/config/("southbridge/amd/amd8111/ide.dts");
+			ide0_enable = "1";
+			ide1_enable = "1";
+		};
+		pci at 1,2 {
+			/config/("southbridge/amd/amd8111/smbus.dts");
+		};
+		pci at 1,3 {
+			/config/("southbridge/amd/amd8111/acpi.dts");
+		};
+		pci at 1,5 {
+			/config/("southbridge/amd/amd8111/ac97audio.dts");
+			disabled;
+		};
+		pci at 1,6 {
+			/config/("southbridge/amd/amd8111/ac97modem.dts");
+			disabled;
+		};
+		pci at 1,7 {
+		};
+		pci_8 at 0,0 {
+			/config/("southbridge/amd/amd8151/agpbridge.dts");
+		};
+		pci_8 at 1,0 {
+			/config/("southbridge/amd/amd8151/agpdev.dts");
+		};
+		pci at 18,0 {
+			/config/("northbridge/amd/k8/pci");
+		};
 		pci at 18,1 {};
 		pci at 18,2 {};
 		pci at 18,3 {
@@ -101,12 +107,6 @@
 			/config/("northbridge/amd/k8/pci");
 		};
 		pci at 19,1 {
-			pci at 0,0 {
-				/config/("southbridge/amd/amd8151/agpbridge.dts");
-			};
-			pci at 1,0 {
-				/config/("southbridge/amd/amd8151/agpdev.dts");
-			};
 		};
 		pci at 19,2 {};
 		pci at 19,3 {

Modified: coreboot-v3/mainboard/gigabyte/m57sli/dts
===================================================================
--- coreboot-v3/mainboard/gigabyte/m57sli/dts	2009-01-08 16:19:51 UTC (rev 1108)
+++ coreboot-v3/mainboard/gigabyte/m57sli/dts	2009-01-08 16:22:39 UTC (rev 1109)
@@ -44,20 +44,58 @@
 	apic at 0 {
 	};
 	domain at 0 {
-		pci at 1,0{
+		pci at 0,0 { /* MCP55 RAM? */
 		};
+		pci at 1,0 {
+			/config/("southbridge/nvidia/mcp55/lpc.dts");
+			ioport at 2e {
+				/config/("superio/ite/it8716f/dts");
+				com1enable = "1";
+				ecenable = "1";
+				kbenable = "1";
+				mouseenable = "1";
+				gpioenable = "1";
+			};
+		};
+		pci at 1,1 { /* smbus */
+		};
+		pci at 2,0 { /* usb */
+		};
+		pci at 2,1 { /* usb */
+		};
+		pci at 4,0 {
+			/config/("southbridge/nvidia/mcp55/ide.dts");
+			ide0_enable = "1";
+		};
+		pci at 5,0 {
+			/config/("southbridge/nvidia/mcp55/sata.dts");
+			sata0_enable = "1";
+		};
+		pci at 5,1 {
+			/config/("southbridge/nvidia/mcp55/sata.dts");
+			sata1_enable = "1";
+		};
+		pci at 6,0 { /* PCI */
+		};
+		pci at 6,1 {
+			/*/config/("southbridge/nvidia/mcp55/audio.dts"); */
+		};
+		pci at 8,0 {
+		/*
+			/config/("southbridge/nvidia/mcp55/nic.dts");
+			mac_eeprom_smbus = "3";
+			mac_eeprom_addr = "0x51";
+		*/
+		};
+		pci at f,0 { /* PCIe */
+		};
 		pci at 18,0 {
 			/config/("northbridge/amd/k8/pci");
-			pci at 0,0 {
-				/config/("southbridge/nvidia/mcp55/ide.dts");
-			};
-			pci at 0,1 {
-				/config/("southbridge/nvidia/mcp55/sata.dts");
-			};
 		};
-		ioport at 2e {
-			/config/("superio/ite/it8716f/dts");
-			com1enable = "1";
+		pci at 18,1 {};
+		pci at 18,2 {};
+		pci at 18,3 {
+			/config/("northbridge/amd/k8/mcf3");
 		};
 	};
 };

Modified: coreboot-v3/northbridge/amd/k8/domain.c
===================================================================
--- coreboot-v3/northbridge/amd/k8/domain.c	2009-01-08 16:19:51 UTC (rev 1108)
+++ coreboot-v3/northbridge/amd/k8/domain.c	2009-01-08 16:22:39 UTC (rev 1109)
@@ -717,6 +717,7 @@
 {
 	unsigned reg;
 	int i;
+	struct device *last_dev, *children;
 
 	printk(BIOS_DEBUG, "%s: %s \n", __func__, dev->dtsname);
 
@@ -746,8 +747,31 @@
 		}
 	}
 
+	/* Take processors off the list; we always know what link they're on. */
+	for (last_dev = dev->link[0].children; last_dev;
+	     last_dev = last_dev->sibling)
+		if (last_dev && last_dev->sibling == __f0_dev[0])
+			last_dev->sibling = NULL;
+
 	max = amdk8_scan_chains(dev, __f0_dev[0], max);
 
+	/* Save non-processor children. */
+	children = dev->link[0].children;
+
+	/* Probe for processors and disable those that don't respond. */
+	dev->link[0].children = __f0_dev[0];
+	pci_scan_bus(&dev->link[0], PCI_DEVFN(0x18,0), 0xff, 0);
+
+	/* Add them back to the new end of the list. */
+	for (last_dev = children; last_dev && last_dev->sibling;
+	     last_dev = last_dev->sibling);
+
+	if (last_dev) {
+		last_dev->sibling = __f0_dev[0];
+		dev->link[0].children = children;
+	} else
+		dev->link[0].children = __f0_dev[0];
+
 	return max;
 }
 




From mylesgw at gmail.com  Thu Jan  8 17:23:01 2009
From: mylesgw at gmail.com (Myles Watson)
Date: Thu, 8 Jan 2009 09:23:01 -0700
Subject: [coreboot] K8 HT and dts fixups
In-Reply-To: <20090108012033.2758.qmail@stuge.se>
References: <2831fecf0901071524m357a8b43n9c4210545c4fe4d5@mail.gmail.com>
	<2831fecf0901071524r4bd7ee48n3ea6ff16ebb9ff75@mail.gmail.com>
	<20090108012033.2758.qmail@stuge.se>
Message-ID: <2831fecf0901080823y466e1e9bs38df206ee2445f11@mail.gmail.com>

On Wed, Jan 7, 2009 at 6:20 PM, Peter Stuge <peter at stuge.se> wrote:
> Myles Watson wrote:
>> And the patch.
>> Signed-off-by: Myles Watson <mylesgw at gmail.com>
>
> Acked-by: Peter Stuge <peter at stuge.se>
Rev 1109.

Thanks,
Myles



From c-d.hailfinger.devel.2006 at gmx.net  Thu Jan  8 17:38:10 2009
From: c-d.hailfinger.devel.2006 at gmx.net (Carl-Daniel Hailfinger)
Date: Thu, 08 Jan 2009 17:38:10 +0100
Subject: [coreboot] [PATCH] flashrom: Add erase and write functions to Atmel
 AT25* and AT26*
Message-ID: <49662BF2.5030400@gmx.net>

Add erase and write functions to the following chip definitions:

AT25DF021
AT25DF041A
AT25DF081
AT25DF161
AT25DF321
AT25DF321A
AT25DF641
AT25F512B
AT25FS010
AT25FS040
AT26DF081A
AT26DF161
AT26DF161A
AT26DF321
AT26F004

Straight from the data sheets, untested because I lack the hardware.

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

Index: flashrom-atmel_readerasewrite/flashchips.c
===================================================================
--- flashrom-atmel_readerasewrite/flashchips.c	(Revision 3852)
+++ flashrom-atmel_readerasewrite/flashchips.c	(Arbeitskopie)
@@ -123,8 +123,8 @@
 		.page_size	= 256,
 		.tested		= TEST_UNTESTED,
 		.probe		= probe_spi_rdid,
-		.erase		= NULL,
-		.write		= NULL,
+		.erase		= spi_chip_erase_60_c7,
+		.write		= spi_chip_write,
 		.read		= spi_chip_read,
 	},
 
@@ -137,8 +137,8 @@
 		.page_size	= 256,
 		.tested		= TEST_UNTESTED,
 		.probe		= probe_spi_rdid,
-		.erase		= NULL,
-		.write		= NULL,
+		.erase		= spi_chip_erase_60_c7,
+		.write		= spi_chip_write,
 		.read		= spi_chip_read,
 	},
 
@@ -151,8 +151,8 @@
 		.page_size	= 256,
 		.tested		= TEST_UNTESTED,
 		.probe		= probe_spi_rdid,
-		.erase		= NULL,
-		.write		= NULL,
+		.erase		= spi_chip_erase_60_c7,
+		.write		= spi_chip_write,
 		.read		= spi_chip_read,
 	},
 
@@ -165,8 +165,8 @@
 		.page_size	= 256,
 		.tested		= TEST_UNTESTED,
 		.probe		= probe_spi_rdid,
-		.erase		= NULL,
-		.write		= NULL,
+		.erase		= spi_chip_erase_60_c7,
+		.write		= spi_chip_write,
 		.read		= spi_chip_read,
 	},
 
@@ -179,7 +179,7 @@
 		.page_size	= 256,
 		.tested		= TEST_OK_PREW,
 		.probe		= probe_spi_rdid,
-		.erase		= spi_chip_erase_c7,
+		.erase		= spi_chip_erase_60_c7,
 		.write		= spi_chip_write,
 		.read		= spi_chip_read,
 	},
@@ -193,8 +193,8 @@
 		.page_size	= 256,
 		.tested		= TEST_UNTESTED,
 		.probe		= probe_spi_rdid,
-		.erase		= NULL,
-		.write		= NULL,
+		.erase		= spi_chip_erase_60_c7,
+		.write		= spi_chip_write,
 		.read		= spi_chip_read,
 	},
 
@@ -207,8 +207,8 @@
 		.page_size	= 256,
 		.tested		= TEST_UNTESTED,
 		.probe		= probe_spi_rdid,
-		.erase		= NULL,
-		.write		= NULL,
+		.erase		= spi_chip_erase_60_c7,
+		.write		= spi_chip_write,
 		.read		= spi_chip_read,
 	},
 
@@ -221,8 +221,8 @@
 		.page_size	= 256,
 		.tested		= TEST_UNTESTED,
 		.probe		= probe_spi_rdid,
-		.erase		= NULL,
-		.write		= NULL,
+		.erase		= spi_chip_erase_60_c7,
+		.write		= spi_chip_write,
 		.read		= spi_chip_read,
 	},
 
@@ -235,8 +235,8 @@
 		.page_size	= 256,
 		.tested		= TEST_UNTESTED,
 		.probe		= probe_spi_rdid,
-		.erase		= NULL,
-		.write		= NULL,
+		.erase		= spi_chip_erase_60_c7,
+		.write		= spi_chip_write,
 		.read		= spi_chip_read,
 	},
 
@@ -249,8 +249,8 @@
 		.page_size	= 256,
 		.tested		= TEST_UNTESTED,
 		.probe		= probe_spi_rdid,
-		.erase		= NULL,
-		.write		= NULL,
+		.erase		= spi_chip_erase_60_c7,
+		.write		= spi_chip_write,
 		.read		= spi_chip_read,
 	},
 
@@ -277,8 +277,8 @@
 		.page_size	= 256,
 		.tested		= TEST_UNTESTED,
 		.probe		= probe_spi_rdid,
-		.erase		= NULL,
-		.write		= NULL,
+		.erase		= spi_chip_erase_60_c7,
+		.write		= spi_chip_write,
 		.read		= spi_chip_read,
 	},
 
@@ -291,8 +291,8 @@
 		.page_size	= 256,
 		.tested		= TEST_UNTESTED,
 		.probe		= probe_spi_rdid,
-		.erase		= NULL,
-		.write		= NULL,
+		.erase		= spi_chip_erase_60_c7,
+		.write		= spi_chip_write,
 		.read		= spi_chip_read,
 	},
 
@@ -305,8 +305,8 @@
 		.page_size	= 256,
 		.tested		= TEST_UNTESTED,
 		.probe		= probe_spi_rdid,
-		.erase		= NULL,
-		.write		= NULL,
+		.erase		= spi_chip_erase_60_c7,
+		.write		= spi_chip_write,
 		.read		= spi_chip_read,
 	},
 
@@ -320,7 +320,7 @@
 		.page_size	= 256,
 		.tested		= TEST_UNTESTED,
 		.probe		= probe_spi_rdid,
-		.erase		= spi_chip_erase_c7,
+		.erase		= spi_chip_erase_60_c7,
 		.write		= spi_chip_write,
 		.read		= spi_chip_read,
 	  },*/
@@ -334,7 +334,7 @@
 		.page_size	= 256,
 		.tested		= TEST_UNTESTED,
 		.probe		= probe_spi_rdid,
-		.erase		= NULL,
+		.erase		= spi_chip_erase_60_c7,
 		.write		= NULL /* Incompatible Page write */,
 		.read		= spi_chip_read,
 	},


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




From peter at stuge.se  Thu Jan  8 17:44:32 2009
From: peter at stuge.se (Peter Stuge)
Date: Thu, 8 Jan 2009 17:44:32 +0100
Subject: [coreboot] [PATCH] flashrom: Add erase and write functions to
	Atmel AT25* and AT26*
In-Reply-To: <49662BF2.5030400@gmx.net>
References: <49662BF2.5030400@gmx.net>
Message-ID: <20090108164432.4482.qmail@stuge.se>

Carl-Daniel Hailfinger wrote:
> Add erase and write functions to the following chip definitions:
> 
> AT25DF021 AT25DF041A AT25DF081 AT25DF161 AT25DF321 AT25DF321A AT25DF641
> AT25F512B AT25FS010 AT25FS040 AT26DF081A AT26DF161 AT26DF161A AT26DF321
> AT26F004
> 
> Straight from the data sheets, untested because I lack the hardware.
> 
> Signed-off-by: Carl-Daniel Hailfinger <c-d.hailfinger.devel.2006 at gmx.net>

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



From mylesgw at gmail.com  Thu Jan  8 17:49:23 2009
From: mylesgw at gmail.com (Myles Watson)
Date: Thu, 8 Jan 2009 09:49:23 -0700
Subject: [coreboot] [PATCH] flashrom: Add erase and write functions to
	Atmel AT25* and AT26*
In-Reply-To: <49662BF2.5030400@gmx.net>
References: <49662BF2.5030400@gmx.net>
Message-ID: <2831fecf0901080849m38d43b04nc4cadc36eb8b8e2c@mail.gmail.com>

On Thu, Jan 8, 2009 at 9:38 AM, Carl-Daniel Hailfinger
<c-d.hailfinger.devel.2006 at gmx.net> wrote:
> Add erase and write functions to the following chip definitions:
>
> AT25DF021
> AT25DF041A
> AT25DF081
> AT25DF161
> AT25DF321
> AT25DF321A
> AT25DF641
> AT25F512B
> AT25FS010
> AT25FS040
> AT26DF081A
> AT26DF161
> AT26DF161A
> AT26DF321
> AT26F004
>
> Straight from the data sheets, untested because I lack the hardware.
>
> Signed-off-by: Carl-Daniel Hailfinger <c-d.hailfinger.devel.2006 at gmx.net>

> @@ -179,7 +179,7 @@
>                .page_size      = 256,
>                .tested         = TEST_OK_PREW,
>                .probe          = probe_spi_rdid,
> -               .erase          = spi_chip_erase_c7,
> +               .erase          = spi_chip_erase_60_c7,

It's surprising to change this one since it was tested OK.  Shouldn't
you mark it TEST_UNTESTED now or TEST_OK_PRW?

Thanks,
Myles



From marcj303 at gmail.com  Thu Jan  8 17:52:07 2009
From: marcj303 at gmail.com (Marc Jones)
Date: Thu, 8 Jan 2009 09:52:07 -0700
Subject: [coreboot] AMD DBM690T PowerNow table problems
In-Reply-To: <4965662A.5060109@gmx.net>
References: <49583EA2.8080903@gmx.net> <495FE0E5.7020503@assembler.cz>
	<534e5dc20901051725l69907601k7d2ccf6817510257@mail.gmail.com>
	<DD1CC71B621B004FA76856E5129D6B17024A0045@sbjgexmb1.amd.com>
	<534e5dc20901060847j6c19053av20fe3845ca3df3b5@mail.gmail.com>
	<4965662A.5060109@gmx.net>
Message-ID: <534e5dc20901080852gbdd37ccu83304fcf206e448a@mail.gmail.com>

On Wed, Jan 7, 2009 at 7:34 PM, Carl-Daniel Hailfinger
<c-d.hailfinger.devel.2006 at gmx.net> wrote:
> On 06.01.2009 17:47, Marc Jones wrote:
>> On Mon, Jan 5, 2009 at 6:36 PM, Bao, Zheng <Zheng.Bao at amd.com> wrote:
>>
>>> If fid_multiplier is 0, it doesn't seem to have any sense. So I agree.
>>>
>>> Acked-by: zheng bao <zheng.bao at amd.com>
>>>
>>>
>>
>> I also fixed this in acpi_tables.c Pistachio.
>>
>> r 3847
>>
>
> Thanks!
> The Linux kernel powernow-k8 driver doesn't complain anymore, but now
> the machine will lock up or reboot once I put some load on it.
> Blacklisting the powernow-k8 driver avoids the issue, but that makes
> frequency scaling impossible.
>
> AFAICS the standard cpu frequency governor is ondemand and it scales the
> frequency down from 1800 MHz to 1000 Mhz. That seems to work fine, but
> scaling up again will cause the lockups/reboots. By the way, coreboot
> reports a BIST failure after such reboots. Not nice.
>
> Rudolf's PowerNow tables had entries for 1000/1600/1800 MHz. The
> proprietary BIOS and coreboot only have entries for 1000/1800 MHz.
> According to the docs, scaling from 1000 MHz to 1800 MHz can't be done
> in a single step. Is that maybe the reason for the problems I'm seeing?


Can you dump the current tables or can you not get that far before a
crash? The entries are end points and the driver takes care of the
stepping that needs to be done to get to those points. We need to
check that the table generated the correct vid setting for the fid. It
is well described in the bkdg section 10.6.

Marc



From svn at coreboot.org  Thu Jan  8 17:53:13 2009
From: svn at coreboot.org (svn at coreboot.org)
Date: Thu,  8 Jan 2009 17:53:13 +0100
Subject: [coreboot] r3853 - trunk/util/flashrom
Message-ID: <mailman.2653.1355071468.16123.coreboot@coreboot.org>

Author: hailfinger
Date: 2009-01-08 17:53:13 +0100 (Thu, 08 Jan 2009)
New Revision: 3853

Modified:
   trunk/util/flashrom/flashchips.c
Log:
Add erase and write functions to the following chip definitions:

AT25DF021 AT25DF041A AT25DF081 AT25DF161 AT25DF321 AT25DF321A AT25DF641
AT25F512B AT25FS010 AT25FS040 AT26DF081A AT26DF161 AT26DF161A AT26DF321
AT26F004

Straight from the data sheets, untested because I lack the hardware.

Signed-off-by: Carl-Daniel Hailfinger <c-d.hailfinger.devel.2006 at gmx.net>
Acked-by: Peter Stuge <peter at stuge.se>


Modified: trunk/util/flashrom/flashchips.c
===================================================================
--- trunk/util/flashrom/flashchips.c	2009-01-08 04:56:59 UTC (rev 3852)
+++ trunk/util/flashrom/flashchips.c	2009-01-08 16:53:13 UTC (rev 3853)
@@ -123,8 +123,8 @@
 		.page_size	= 256,
 		.tested		= TEST_UNTESTED,
 		.probe		= probe_spi_rdid,
-		.erase		= NULL,
-		.write		= NULL,
+		.erase		= spi_chip_erase_60_c7,
+		.write		= spi_chip_write,
 		.read		= spi_chip_read,
 	},
 
@@ -137,8 +137,8 @@
 		.page_size	= 256,
 		.tested		= TEST_UNTESTED,
 		.probe		= probe_spi_rdid,
-		.erase		= NULL,
-		.write		= NULL,
+		.erase		= spi_chip_erase_60_c7,
+		.write		= spi_chip_write,
 		.read		= spi_chip_read,
 	},
 
@@ -151,8 +151,8 @@
 		.page_size	= 256,
 		.tested		= TEST_UNTESTED,
 		.probe		= probe_spi_rdid,
-		.erase		= NULL,
-		.write		= NULL,
+		.erase		= spi_chip_erase_60_c7,
+		.write		= spi_chip_write,
 		.read		= spi_chip_read,
 	},
 
@@ -165,8 +165,8 @@
 		.page_size	= 256,
 		.tested		= TEST_UNTESTED,
 		.probe		= probe_spi_rdid,
-		.erase		= NULL,
-		.write		= NULL,
+		.erase		= spi_chip_erase_60_c7,
+		.write		= spi_chip_write,
 		.read		= spi_chip_read,
 	},
 
@@ -179,7 +179,7 @@
 		.page_size	= 256,
 		.tested		= TEST_OK_PREW,
 		.probe		= probe_spi_rdid,
-		.erase		= spi_chip_erase_c7,
+		.erase		= spi_chip_erase_60_c7,
 		.write		= spi_chip_write,
 		.read		= spi_chip_read,
 	},
@@ -193,8 +193,8 @@
 		.page_size	= 256,
 		.tested		= TEST_UNTESTED,
 		.probe		= probe_spi_rdid,
-		.erase		= NULL,
-		.write		= NULL,
+		.erase		= spi_chip_erase_60_c7,
+		.write		= spi_chip_write,
 		.read		= spi_chip_read,
 	},
 
@@ -207,8 +207,8 @@
 		.page_size	= 256,
 		.tested		= TEST_UNTESTED,
 		.probe		= probe_spi_rdid,
-		.erase		= NULL,
-		.write		= NULL,
+		.erase		= spi_chip_erase_60_c7,
+		.write		= spi_chip_write,
 		.read		= spi_chip_read,
 	},
 
@@ -221,8 +221,8 @@
 		.page_size	= 256,
 		.tested		= TEST_UNTESTED,
 		.probe		= probe_spi_rdid,
-		.erase		= NULL,
-		.write		= NULL,
+		.erase		= spi_chip_erase_60_c7,
+		.write		= spi_chip_write,
 		.read		= spi_chip_read,
 	},
 
@@ -235,8 +235,8 @@
 		.page_size	= 256,
 		.tested		= TEST_UNTESTED,
 		.probe		= probe_spi_rdid,
-		.erase		= NULL,
-		.write		= NULL,
+		.erase		= spi_chip_erase_60_c7,
+		.write		= spi_chip_write,
 		.read		= spi_chip_read,
 	},
 
@@ -249,8 +249,8 @@
 		.page_size	= 256,
 		.tested		= TEST_UNTESTED,
 		.probe		= probe_spi_rdid,
-		.erase		= NULL,
-		.write		= NULL,
+		.erase		= spi_chip_erase_60_c7,
+		.write		= spi_chip_write,
 		.read		= spi_chip_read,
 	},
 
@@ -277,8 +277,8 @@
 		.page_size	= 256,
 		.tested		= TEST_UNTESTED,
 		.probe		= probe_spi_rdid,
-		.erase		= NULL,
-		.write		= NULL,
+		.erase		= spi_chip_erase_60_c7,
+		.write		= spi_chip_write,
 		.read		= spi_chip_read,
 	},
 
@@ -291,8 +291,8 @@
 		.page_size	= 256,
 		.tested		= TEST_UNTESTED,
 		.probe		= probe_spi_rdid,
-		.erase		= NULL,
-		.write		= NULL,
+		.erase		= spi_chip_erase_60_c7,
+		.write		= spi_chip_write,
 		.read		= spi_chip_read,
 	},
 
@@ -305,8 +305,8 @@
 		.page_size	= 256,
 		.tested		= TEST_UNTESTED,
 		.probe		= probe_spi_rdid,
-		.erase		= NULL,
-		.write		= NULL,
+		.erase		= spi_chip_erase_60_c7,
+		.write		= spi_chip_write,
 		.read		= spi_chip_read,
 	},
 
@@ -320,7 +320,7 @@
 		.page_size	= 256,
 		.tested		= TEST_UNTESTED,
 		.probe		= probe_spi_rdid,
-		.erase		= spi_chip_erase_c7,
+		.erase		= spi_chip_erase_60_c7,
 		.write		= spi_chip_write,
 		.read		= spi_chip_read,
 	  },*/
@@ -334,7 +334,7 @@
 		.page_size	= 256,
 		.tested		= TEST_UNTESTED,
 		.probe		= probe_spi_rdid,
-		.erase		= NULL,
+		.erase		= spi_chip_erase_60_c7,
 		.write		= NULL /* Incompatible Page write */,
 		.read		= spi_chip_read,
 	},




From c-d.hailfinger.devel.2006 at gmx.net  Thu Jan  8 17:53:39 2009
From: c-d.hailfinger.devel.2006 at gmx.net (Carl-Daniel Hailfinger)
Date: Thu, 08 Jan 2009 17:53:39 +0100
Subject: [coreboot] [PATCH] flashrom: Add erase and write functions to
 Atmel AT25* and AT26*
In-Reply-To: <20090108164432.4482.qmail@stuge.se>
References: <49662BF2.5030400@gmx.net> <20090108164432.4482.qmail@stuge.se>
Message-ID: <49662F93.7020404@gmx.net>

On 08.01.2009 17:44, Peter Stuge wrote:
> Carl-Daniel Hailfinger wrote:
>   
>> Add erase and write functions to the following chip definitions:
>>
>> AT25DF021 AT25DF041A AT25DF081 AT25DF161 AT25DF321 AT25DF321A AT25DF641
>> AT25F512B AT25FS010 AT25FS040 AT26DF081A AT26DF161 AT26DF161A AT26DF321
>> AT26F004
>>
>> Straight from the data sheets, untested because I lack the hardware.
>>
>> Signed-off-by: Carl-Daniel Hailfinger <c-d.hailfinger.devel.2006 at gmx.net>
>>     
>
> Acked-by: Peter Stuge <peter at stuge.se>
>   

Thanks, r3853.

Regards,
Carl-Daniel

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




From ebiederm at xmission.com  Thu Jan  8 17:54:31 2009
From: ebiederm at xmission.com (Eric W. Biederman)
Date: Thu, 08 Jan 2009 08:54:31 -0800
Subject: [coreboot] [PATCH] flashrom: add SST49LF020 support
In-Reply-To: <20090108145839.GA8192@greenwood> (Uwe Hermann's message of "Thu, 
	8 Jan 2009 15:58:39 +0100")
References: <877i5ahon6.fsf@apollo.stackframe.org>
	<20090105232701.GD12484@greenwood>
	<87ljtoj0o6.fsf@apollo.stackframe.org>
	<20090107123615.GE7490@greenwood>
	<87zli346o1.fsf@begreifnix.intranet.astaro.de>
	<20090108145839.GA8192@greenwood>
Message-ID: <m18wplzqk8.fsf@frodo.ebiederm.org>

Uwe Hermann <uwe at hermann-uwe.de> writes:

> On Wed, Jan 07, 2009 at 01:55:26PM +0100, Sven Schnelle wrote:
>> Hi Uwe,
>> 
>> Uwe Hermann <uwe at hermann-uwe.de> writes:
>> 
>> > Btw, can we mark all the new stuff from your patches as supported in
>> > the wiki, i.e. is all of it tested on hardware?
>> 
>> Yes, they are tested on hardware - i have three Boards here,
>
> OK, wiki updated.
>
>
>> 2 with the Intel 5000 Chipset,
>
> Is this chipset related to or compatible with the new 631xESB/632xESB/3100
> stuff you added in flashrom? Did you test 5000, or 631xESB/632xESB/3100,
> or both?
>
>
>> 1 with AMD 760 Chipset.
>
> Do you mean 780 here?
>
>  
>> The reason for adding the Flash/Chipset support is that i want to port/use
>> coreboot on these platforms.
>
> Nice! There's some old AMD-768 code in coreboot-v1, maybe you can use
> that as inspiration (no idea if or how well that worked back then).
> Those files don't have license headers unfortunately, so you can either

Not necessary the entire project was GPLv2.  Saying it in every file
is redundant and useful, but as I understand it not strictly necessary,
and in certain cases very very annoying.

> start from scratch with a v2 or even v3 code, or find out who wrote that
> code and add the proper license headers (judging from the svn commit log
> it should be Eric Biederman, GPL2)...

Yep.  I wrote it.  The code worked well, there is a cluster or two running it.
It was released late in the life cycle of the hardware because it took a while
to get the last critical bits out of NDA with AMD.

Eric



From peter at stuge.se  Thu Jan  8 18:01:09 2009
From: peter at stuge.se (Peter Stuge)
Date: Thu, 8 Jan 2009 18:01:09 +0100
Subject: [coreboot] [PATCH] flashrom: Add erase and write functions to
	Atmel AT25* and AT26*
In-Reply-To: <2831fecf0901080849m38d43b04nc4cadc36eb8b8e2c@mail.gmail.com>
References: <49662BF2.5030400@gmx.net>
	<2831fecf0901080849m38d43b04nc4cadc36eb8b8e2c@mail.gmail.com>
Message-ID: <20090108170109.9317.qmail@stuge.se>

Myles Watson wrote:
> > @@ -179,7 +179,7 @@
> >                .page_size      = 256,
> >                .tested         = TEST_OK_PREW,
> >                .probe          = probe_spi_rdid,
> > -               .erase          = spi_chip_erase_c7,
> > +               .erase          = spi_chip_erase_60_c7,
> 
> It's surprising to change this one since it was tested OK. 
> Shouldn't you mark it TEST_UNTESTED now or TEST_OK_PRW?

Thanks for catching that. Please revert this hunk.


//Peter



From c-d.hailfinger.devel.2006 at gmx.net  Thu Jan  8 18:04:36 2009
From: c-d.hailfinger.devel.2006 at gmx.net (Carl-Daniel Hailfinger)
Date: Thu, 08 Jan 2009 18:04:36 +0100
Subject: [coreboot] [PATCH] flashrom: Add erase and write functions to
 Atmel AT25* and AT26*
In-Reply-To: <20090108170109.9317.qmail@stuge.se>
References: <49662BF2.5030400@gmx.net>	<2831fecf0901080849m38d43b04nc4cadc36eb8b8e2c@mail.gmail.com>
	<20090108170109.9317.qmail@stuge.se>
Message-ID: <49663224.8070001@gmx.net>

On 08.01.2009 18:01, Peter Stuge wrote:
> Myles Watson wrote:
>   
>>> @@ -179,7 +179,7 @@
>>>                .page_size      = 256,
>>>                .tested         = TEST_OK_PREW,
>>>                .probe          = probe_spi_rdid,
>>> -               .erase          = spi_chip_erase_c7,
>>> +               .erase          = spi_chip_erase_60_c7,
>>>       
>> It's surprising to change this one since it was tested OK. 
>> Shouldn't you mark it TEST_UNTESTED now or TEST_OK_PRW?
>>     
>
> Thanks for catching that. Please revert this hunk.
>   

Sure, will do. Thanks Myles!

Regards,
Carl-Daniel

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




From marcj303 at gmail.com  Thu Jan  8 18:10:12 2009
From: marcj303 at gmail.com (Marc Jones)
Date: Thu, 8 Jan 2009 10:10:12 -0700
Subject: [coreboot] FIDVID question
In-Reply-To: <20090108094509.fha2rnz3k884csgo@webmail.trustica.cz>
References: <704889.9516.qm@web57006.mail.re3.yahoo.com>
	<20090108094509.fha2rnz3k884csgo@webmail.trustica.cz>
Message-ID: <534e5dc20901080910r3d41b751ic55f9206cb0ec1fb@mail.gmail.com>

On Thu, Jan 8, 2009 at 1:45 AM,  <r.marek at assembler.cz> wrote:
> Hi,
>
> if you check your CPUID, does it support FIDVID?
>
> If yes, then there is another problem. Perhaps you are hit by
> some errata which says first is needed not HT reset (LDTSTOP) but PCI reset.
> I don't have a code at my hand right now, but is HT reset stuff done
> _before_ the fidvid?
>

I think that all the revf/g processors support fidvid even if it can't
be changed. The S1G1 socket means revf and above and checking for
support really isn't needed. I think it is safe for a platform to make
some assumptions like that.

Have you narrowed the reset to the fidvid code?  After fidvid setup
there should be a ht reset as Rudolf noted. You can skip fidvid setup
for now. It just means that the processor will run at min frequency.


Marc



From peter at stuge.se  Thu Jan  8 18:17:48 2009
From: peter at stuge.se (Peter Stuge)
Date: Thu, 8 Jan 2009 18:17:48 +0100
Subject: [coreboot] [PATCH] There's a pciconf.h with PCI conf constants
	- lets actually use it
In-Reply-To: <1231234547.4627.5.camel@martr-gentoo.artec>
References: <1231166997.20385.3.camel@martr-gentoo.artec>
	<20090105232412.GC12484@greenwood>
	<20090105233800.24547.qmail@stuge.se>
	<1231234547.4627.5.camel@martr-gentoo.artec>
Message-ID: <20090108171748.13412.qmail@stuge.se>

Mart Raudsepp wrote:
> Subject: [PATCH] Remove unused pciconf.h header with constants that
> everyone uses by value instead per convention
> 
> Signed-off-by: Mart Raudsepp <mart.raudsepp at artecdesign.ee>

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



From svn at coreboot.org  Thu Jan  8 18:21:37 2009
From: svn at coreboot.org (svn at coreboot.org)
Date: Thu,  8 Jan 2009 18:21:37 +0100
Subject: [coreboot] r1110 - in coreboot-v3: arch/x86 device include/arch/x86
Message-ID: <mailman.2654.1355071468.16123.coreboot@coreboot.org>

Author: mraudsepp
Date: 2009-01-08 18:21:37 +0100 (Thu, 08 Jan 2009)
New Revision: 1110

Removed:
   coreboot-v3/include/arch/x86/pciconf.h
Modified:
   coreboot-v3/arch/x86/pci_ops_auto.c
   coreboot-v3/arch/x86/pci_ops_conf1.c
   coreboot-v3/arch/x86/pci_ops_mmconf.c
   coreboot-v3/device/pci_ops.c
Log:
Remove unused pciconf.h header with constants that everyone uses by value instead per convention

Signed-off-by: Mart Raudsepp <mart.raudsepp at artecdesign.ee>
Acked-by: Peter Stuge <peter at stuge.se>

Modified: coreboot-v3/arch/x86/pci_ops_auto.c
===================================================================
--- coreboot-v3/arch/x86/pci_ops_auto.c	2009-01-08 16:22:39 UTC (rev 1109)
+++ coreboot-v3/arch/x86/pci_ops_auto.c	2009-01-08 17:21:37 UTC (rev 1110)
@@ -1,6 +1,5 @@
 #include <console.h>
 #include <device/device.h>
-#include <pciconf.h>
 #include <device/pci.h>
 #include <device/pci_ids.h>
 #include <device/pci_ops.h>

Modified: coreboot-v3/arch/x86/pci_ops_conf1.c
===================================================================
--- coreboot-v3/arch/x86/pci_ops_conf1.c	2009-01-08 16:22:39 UTC (rev 1109)
+++ coreboot-v3/arch/x86/pci_ops_conf1.c	2009-01-08 17:21:37 UTC (rev 1110)
@@ -1,6 +1,5 @@
 #include <console.h>
 #include <device/device.h>
-#include <pciconf.h>
 #include <device/pci.h>
 #include <device/pci_ids.h>
 #include <device/pci_ops.h>

Modified: coreboot-v3/arch/x86/pci_ops_mmconf.c
===================================================================
--- coreboot-v3/arch/x86/pci_ops_mmconf.c	2009-01-08 16:22:39 UTC (rev 1109)
+++ coreboot-v3/arch/x86/pci_ops_mmconf.c	2009-01-08 17:21:37 UTC (rev 1110)
@@ -1,6 +1,5 @@
 #include <console.h>
 #include <device/device.h>
-#include <pciconf.h>
 #include <device/pci.h>
 #include <device/pci_ids.h>
 #include <device/pci_ops.h>

Modified: coreboot-v3/device/pci_ops.c
===================================================================
--- coreboot-v3/device/pci_ops.c	2009-01-08 16:22:39 UTC (rev 1109)
+++ coreboot-v3/device/pci_ops.c	2009-01-08 17:21:37 UTC (rev 1110)
@@ -20,7 +20,6 @@
 
 #include <console.h>
 #include <device/device.h>
-#include <pciconf.h>
 #include <device/pci.h>
 #include <device/pci_ids.h>
 #include <device/pci_ops.h>

Deleted: coreboot-v3/include/arch/x86/pciconf.h
===================================================================
--- coreboot-v3/include/arch/x86/pciconf.h	2009-01-08 16:22:39 UTC (rev 1109)
+++ coreboot-v3/include/arch/x86/pciconf.h	2009-01-08 17:21:37 UTC (rev 1110)
@@ -1,13 +0,0 @@
-#ifndef ARCH_X86_PCICONF_H
-#define ARCH_X86_PCICONF_H
-
-#ifndef PCI_CONF_REG_INDEX
-
-// These are defined in the PCI spec, and hence are theoretically
-// inclusive of ANYTHING that uses a PCI bus. 
-#define	PCI_CONF_REG_INDEX	0xcf8
-#define	PCI_CONF_REG_DATA	0xcfc
-
-#endif
-
-#endif /* ARCH_X86_PCICONF_H */




From uwe at hermann-uwe.de  Thu Jan  8 18:53:14 2009
From: uwe at hermann-uwe.de (Uwe Hermann)
Date: Thu, 8 Jan 2009 18:53:14 +0100
Subject: [coreboot] [PATCH] v1: Add license headers to AMD AMD-768 code
Message-ID: <20090108175314.GA22435@greenwood>

Yay, my first v1 patch :)

Eric, any other code chunks which were mostly/entirely written by you
where we can slap a GPLv2 header on? AMD-766, others?

Btw, was this code from 2003 (C) Eric W. Biederman or rather (C) LNXI?


Thanks, Uwe.
-- 
http://www.hermann-uwe.de  | http://www.holsham-traders.de
http://www.crazy-hacks.org | http://www.unmaintained-free-software.org
-------------- next part --------------
A non-text attachment was scrubbed...
Name: v1_amd768_gpl_headers.patch
Type: text/x-diff
Size: 21709 bytes
Desc: not available
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20090108/bcb8de53/attachment.bin>

From ward at gnu.org  Thu Jan  8 19:00:54 2009
From: ward at gnu.org (Ward Vandewege)
Date: Thu, 8 Jan 2009 13:00:54 -0500
Subject: [coreboot] domain vs device statictree order
In-Reply-To: <2831fecf0901080752p49b3621dj2c073588f8d119c5@mail.gmail.com>
References: <534e5dc20901061513l3b63756mf0a102cddc33ecc0@mail.gmail.com>
	<2831fecf0901061519i873cdf5ua5110832479f1679@mail.gmail.com>
	<2831fecf0901061529p539d4e80s2bcb8c15abdf06a6@mail.gmail.com>
	<534e5dc20901070905p401b0a5aj2598ccef1a3edec7@mail.gmail.com>
	<2831fecf0901071027t461c3c54rf8fd0b54112b5238@mail.gmail.com>
	<20090108020137.GA20844@localdomain>
	<20090108023135.GA21159@localdomain>
	<2831fecf0901072039r52c14481j8e7da3d4ccee7850@mail.gmail.com>
	<20090108135806.GA20056@localdomain>
	<2831fecf0901080752p49b3621dj2c073588f8d119c5@mail.gmail.com>
Message-ID: <20090108180054.GA28851@localdomain>

On Thu, Jan 08, 2009 at 08:52:44AM -0700, Myles Watson wrote:
> On Thu, Jan 8, 2009 at 6:58 AM, Ward Vandewege <ward at gnu.org> wrote:
> > On Wed, Jan 07, 2009 at 09:39:39PM -0700, Myles Watson wrote:
> >> > The rev that broke the boot was 1089 or 1090. 1089 does not build, so I can't
> >> > tell for sure. 1088 boots fine. 1090 is broken.
> >>
> >> They might have well been the same commit because they were
> >> interdependent.  It was just an easier way of looking at the changes
> >> for me.
> >>
> >> Thanks for tracking it down.  Could you send me a log from 1088?
> >> Hopefully we can track it down quickly.
> >
> > Sure, see attached.
> 
> The biggest difference that I see is that there is no graphics device
> (PCI 1.1) in the broken one.  In 1088 it was found dynamically (not in
> the tree), but now it isn't found at all.
> 
> Since it was supposed to be disabled by:
> 	/* this board does not really have vga; disable it (pci device 00:01.1)  */
> 			unwanted_vpci = < 80000900 0 >;
> in the dts, I'm not sure why it disappeared now.
> 
> Possible solution:
> - Try it again without the unwanted_vpci line in the dts.
> 
> I guess I don't understand why the device is gone now.  I didn't think
> the changes I've made would make the device disappear.

I have not tried that yet, but here's a boot log from v1108, which still does
not boot but it stops in a different place now, it seems.

Thanks,
Ward.

-- 
Ward Vandewege <ward at fsf.org>
Free Software Foundation - Senior Systems Administrator
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 13.cap.gz
Type: application/octet-stream
Size: 22820 bytes
Desc: not available
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20090108/bdf98ecd/attachment.obj>

From mylesgw at gmail.com  Thu Jan  8 19:27:05 2009
From: mylesgw at gmail.com (Myles Watson)
Date: Thu, 8 Jan 2009 11:27:05 -0700
Subject: [coreboot] domain vs device statictree order
In-Reply-To: <20090108180054.GA28851@localdomain>
References: <534e5dc20901061513l3b63756mf0a102cddc33ecc0@mail.gmail.com>
	<2831fecf0901061529p539d4e80s2bcb8c15abdf06a6@mail.gmail.com>
	<534e5dc20901070905p401b0a5aj2598ccef1a3edec7@mail.gmail.com>
	<2831fecf0901071027t461c3c54rf8fd0b54112b5238@mail.gmail.com>
	<20090108020137.GA20844@localdomain>
	<20090108023135.GA21159@localdomain>
	<2831fecf0901072039r52c14481j8e7da3d4ccee7850@mail.gmail.com>
	<20090108135806.GA20056@localdomain>
	<2831fecf0901080752p49b3621dj2c073588f8d119c5@mail.gmail.com>
	<20090108180054.GA28851@localdomain>
Message-ID: <2831fecf0901081027r2cec5378lb594f2d8179f0f7c@mail.gmail.com>

On Thu, Jan 8, 2009 at 11:00 AM, Ward Vandewege <ward at gnu.org> wrote:
> On Thu, Jan 08, 2009 at 08:52:44AM -0700, Myles Watson wrote:
>> On Thu, Jan 8, 2009 at 6:58 AM, Ward Vandewege <ward at gnu.org> wrote:
>> > On Wed, Jan 07, 2009 at 09:39:39PM -0700, Myles Watson wrote:
>> >> > The rev that broke the boot was 1089 or 1090. 1089 does not build, so I can't
>> >> > tell for sure. 1088 boots fine. 1090 is broken.
>> >>
>> >> They might have well been the same commit because they were
>> >> interdependent.  It was just an easier way of looking at the changes
>> >> for me.
>> >>
>> >> Thanks for tracking it down.  Could you send me a log from 1088?
>> >> Hopefully we can track it down quickly.
>> >
>> > Sure, see attached.
>>
>> The biggest difference that I see is that there is no graphics device
>> (PCI 1.1) in the broken one.  In 1088 it was found dynamically (not in
>> the tree), but now it isn't found at all.
>>
>> Since it was supposed to be disabled by:
>>       /* this board does not really have vga; disable it (pci device 00:01.1)  */
>>                       unwanted_vpci = < 80000900 0 >;
>> in the dts, I'm not sure why it disappeared now.
>>
>> Possible solution:
>> - Try it again without the unwanted_vpci line in the dts.
>>
>> I guess I don't understand why the device is gone now.  I didn't think
>> the changes I've made would make the device disappear.
>
> I have not tried that yet, but here's a boot log from v1108, which still does
> not boot but it stops in a different place now, it seems.

Thanks for your patience.  One problem is that there is no area
reserved for the APIC and the ROM.  I think we should add a reserved
resource in the domain that goes from 0xfc000000-0xffffffff.  That
will stop allocations from going there.

I copied the reserved areas from i440bx_emulation.  Like the comments
say, I know these need to be reserved areas, but I'm not exactly sure
where they belong.

Compile tested.

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

Thanks,
Myles
-------------- next part --------------
A non-text attachment was scrubbed...
Name: geode_reserved.diff
Type: text/x-patch
Size: 1169 bytes
Desc: not available
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20090108/97fb055b/attachment.diff>

From engineerguy3737 at yahoo.com  Thu Jan  8 19:27:51 2009
From: engineerguy3737 at yahoo.com (Dan Lykowski)
Date: Thu, 8 Jan 2009 10:27:51 -0800 (PST)
Subject: [coreboot] [patch] Proposed patch for FIDVID question
Message-ID: <231212.15416.qm@web57001.mail.re3.yahoo.com>

Marc,

I have narrowed the reset to the first
? msr = rdmsr(0xc0010042); 
line in cache_as_ram.c.
I assume the second would do the same thing if it ever made it there.

Booting with the orig bios, linux reports
ts ttp tm stc 100mhzsteps
as the available power options. It is missing fid vid.

Based on the lack of cpuinfo bits and the documentation the says the processor will do exactly what it is doing, I propose the included patch.
I made the changes to pistachio and norwich also but they are untested.

With this patch I make it here:

coreboot-2.0.0 Wed Jan? 7 17:09:38 PST 2009 starting...???????????????????????? 
bsp_apicid=0x0????????????????????????????????????????????????????????????????? 
Enabling routing table for node 00 done.??????????????????????????????????????? 
Enabling UP settings??????????????????????????????????????????????????????????? 
Disabling read/write/fill probes for UP... done.??????????????????????????????? 
coherent_ht_finalize??????????????????????????????????????????????????????????? 
done??????????????????????????????????????????????????????????????????????????? 
core0 started:????????????????????????????????????????????????????????????????? 
SBLink=00?????????????????????????????????????????????????????????????????????? 
NC node|link=00???????????????????????????????????????????????????????????????? 
rs690_early_setup()???????????????????????????????????????????????????????????? 
get_cpu_rev EAX=0x60fc2.??????????????????????????????????????????????????????? 
CPU Rev is K8_G0.?????????????????????????????????????????????????????????????? 
NB Revision is A12.???????????????????????????????????????????????????????????? 
k8_optimization()?????????????????????????????????????????????????????????????? 
rs690_por_init????????????????????????????????????????????????????????????????? 
sb600_early_setup()???????????????????????????????????????????????????????????? 
sb600_devices_por_init()??????????????????????????????????????????????????????? 
sb600_devices_por_init(): SMBus Device, BDF:0-20-0????????????????????????????? 
SMBus controller enabled, sb revision is 0x13?????????????????????????????????? 
sb600_devices_por_init(): IDE Device, BDF:0-20-1??????????????????????????????? 
sb600_devices_por_init(): LPC Device, BDF:0-20-3??????????????????????????????? 
sb600_devices_por_init(): P2P Bridge, BDF:0-20-4??????????????????????????????? 
sb600_devices_por_init(): SATA Device, BDF:0-18-0?????????????????????????????? 
sb600_pmio_por_init()?????????????????????????????????????????????????????????????????????????????????????????????????????? 
Changing FIDVID not supported ??????????????????????????????????????????????????????? 
entering optimize_link_incoherent_ht??????????????????????????????????????????? 
sysinfo->link_pair_num=0x1????????????????????????????????????????????????????? 
entering ht_optimize_link?????????????????????????????????????????????????????? 
pos=0x8a, unfiltered freq_cap=0x8035??????????????????????????????????????????? 
pos=0x8a, filtered freq_cap=0x35??????????????????????????????????????????????? 
pos=0xd2, unfiltered freq_cap=0x65????????????????????????????????????????????? 
pos=0xd2, filtered freq_cap=0x65??????????????????????????????????????????????? 
freq_cap1=0x35, freq_cap2=0x65????????????????????????????????????????????????? 
dev1 old_freq=0x5, freq=0x5, needs_reset=0x0??????????????????????????????????? 
dev2 old_freq=0x5, freq=0x5, needs_reset=0x0??????????????????????????????????? 
width_cap1=0x11, width_cap2=0x11??????????????????????????????????????????????? 
dev1 input ln_width1=0x4, ln_width2=0x4???????????????????????????????????????? 
dev1 input width=0x1??????????????????????????????????????????????????????????? 
dev1 output ln_width1=0x4, ln_width2=0x4??????????????????????????????????????? 
dev1 input|output width=0x11??????????????????????????????????????????????????? 
old dev1 input|output width=0x11??????????????????????????????????????????????? 
dev2 input|output width=0x11??????????????????????????????????????????????????? 
old dev2 input|output width=0x11??????????????????????????????????????????????? 
after ht_optimize_link for link pair 0, reset_needed=0x0??????????????????????? 
after optimize_link_read_pointers_chain, reset_needed=0x0?????????????????????? 
rs690_htinit k8_ht_freq=5.????????????????????????????????????????????????????? 
rs690_htinit NB_CFG_Q_F1000_800=0?????????????????????????????????????????????? 
needs_reset=0x0???????????????????????????????????????????????????????????????? 
sysinfo->nodes:? 1? sysinfo->ctrl: cf188? spd_addr: ffffae98??????????????????? 
Ram1.00???????????????????????????????????????????????????????????????????????? 
setting up CPU00 northbridge registers????????????????????????????????????????? 
done.?????????????????????????????????????????????????????????????????????????? 
Ram2.00???????????????????????????????????????????????????????????????????????? 
Enable 64MuxMode & BurstLength32??????????????????????????????????????????????? 
Unbuffered????????????????????????????????????????????????????????????????????? 
333Mhz????????????????????????????????????????????????????????????????????????? 
333Mhz

Thanks,
Dan Lykowski
Signed-off-by: Dan Lykowski <lykowdk at gmail.com>

--- On Thu, 1/8/09, Marc Jones <marcj303 at gmail.com> wrote:

From: Marc Jones <marcj303 at gmail.com>
Subject: Re: [coreboot] FIDVID question
To: r.marek at assembler.cz
Cc: "Dan Lykowski" <engineerguy3737 at yahoo.com>, "Coreboot" <coreboot at coreboot.org>
Date: Thursday, January 8, 2009, 12:10 PM


-----Inline Attachment Follows-----

On Thu, Jan 8, 2009 at 1:45 AM,? <r.marek at assembler.cz> wrote:
> Hi,
>
> if you check your CPUID, does it support FIDVID?
>
> If yes, then there is another problem. Perhaps you are hit by
> some errata which says first is needed not HT reset (LDTSTOP) but PCI reset.
> I don't have a code at my hand right now, but is HT reset stuff done
> _before_ the fidvid?
>

I think that all the revf/g processors support fidvid even if it can't
be changed. The S1G1 socket means revf and above and checking for
support really isn't needed. I think it is safe for a platform to make
some assumptions like that.

Have you narrowed the reset to the fidvid code?? After fidvid setup
there should be a ht reset as Rudolf noted. You can skip fidvid setup
for now. It just means that the processor will run at min frequency.


Marc

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



      
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20090108/339db0fc/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: add_fidvid_support_check.patch
Type: text/x-diff
Size: 4513 bytes
Desc: not available
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20090108/339db0fc/attachment.bin>

From marcj303 at gmail.com  Thu Jan  8 19:35:19 2009
From: marcj303 at gmail.com (Marc Jones)
Date: Thu, 8 Jan 2009 11:35:19 -0700
Subject: [coreboot] domain vs device statictree order
In-Reply-To: <2831fecf0901081027r2cec5378lb594f2d8179f0f7c@mail.gmail.com>
References: <534e5dc20901061513l3b63756mf0a102cddc33ecc0@mail.gmail.com>
	<534e5dc20901070905p401b0a5aj2598ccef1a3edec7@mail.gmail.com>
	<2831fecf0901071027t461c3c54rf8fd0b54112b5238@mail.gmail.com>
	<20090108020137.GA20844@localdomain>
	<20090108023135.GA21159@localdomain>
	<2831fecf0901072039r52c14481j8e7da3d4ccee7850@mail.gmail.com>
	<20090108135806.GA20056@localdomain>
	<2831fecf0901080752p49b3621dj2c073588f8d119c5@mail.gmail.com>
	<20090108180054.GA28851@localdomain>
	<2831fecf0901081027r2cec5378lb594f2d8179f0f7c@mail.gmail.com>
Message-ID: <534e5dc20901081035g1e5953e8o50046a7fd4fb9c96@mail.gmail.com>

On Thu, Jan 8, 2009 at 11:27 AM, Myles Watson <mylesgw at gmail.com> wrote:
> On Thu, Jan 8, 2009 at 11:00 AM, Ward Vandewege <ward at gnu.org> wrote:
>> On Thu, Jan 08, 2009 at 08:52:44AM -0700, Myles Watson wrote:
>>> On Thu, Jan 8, 2009 at 6:58 AM, Ward Vandewege <ward at gnu.org> wrote:
>>> > On Wed, Jan 07, 2009 at 09:39:39PM -0700, Myles Watson wrote:
>>> >> > The rev that broke the boot was 1089 or 1090. 1089 does not build, so I can't
>>> >> > tell for sure. 1088 boots fine. 1090 is broken.
>>> >>
>>> >> They might have well been the same commit because they were
>>> >> interdependent.  It was just an easier way of looking at the changes
>>> >> for me.
>>> >>
>>> >> Thanks for tracking it down.  Could you send me a log from 1088?
>>> >> Hopefully we can track it down quickly.
>>> >
>>> > Sure, see attached.
>>>
>>> The biggest difference that I see is that there is no graphics device
>>> (PCI 1.1) in the broken one.  In 1088 it was found dynamically (not in
>>> the tree), but now it isn't found at all.
>>>
>>> Since it was supposed to be disabled by:
>>>       /* this board does not really have vga; disable it (pci device 00:01.1)  */
>>>                       unwanted_vpci = < 80000900 0 >;
>>> in the dts, I'm not sure why it disappeared now.
>>>
>>> Possible solution:
>>> - Try it again without the unwanted_vpci line in the dts.
>>>
>>> I guess I don't understand why the device is gone now.  I didn't think
>>> the changes I've made would make the device disappear.
>>
>> I have not tried that yet, but here's a boot log from v1108, which still does
>> not boot but it stops in a different place now, it seems.
>
> Thanks for your patience.  One problem is that there is no area
> reserved for the APIC and the ROM.  I think we should add a reserved
> resource in the domain that goes from 0xfc000000-0xffffffff.  That
> will stop allocations from going there.
>
> I copied the reserved areas from i440bx_emulation.  Like the comments
> say, I know these need to be reserved areas, but I'm not exactly sure
> where they belong.
>
> Compile tested.
>
> Signed-off-by: Myles Watson <mylesgw at gmail.com>

There is just a PIC in the Geode so you don't need to reserve the
LAPIC range. You do still need to reserve the ROM range. Just fix up
the comment.

Acked-by: Marc Jones <marcj303 at gmail.com>

Marc



From marcj303 at gmail.com  Thu Jan  8 20:08:54 2009
From: marcj303 at gmail.com (Marc Jones)
Date: Thu, 8 Jan 2009 12:08:54 -0700
Subject: [coreboot] [patch] Proposed patch for FIDVID question
In-Reply-To: <231212.15416.qm@web57001.mail.re3.yahoo.com>
References: <231212.15416.qm@web57001.mail.re3.yahoo.com>
Message-ID: <534e5dc20901081108t3f755422w29b4c3f43b33f5f9@mail.gmail.com>

On Thu, Jan 8, 2009 at 11:27 AM, Dan Lykowski <engineerguy3737 at yahoo.com> wrote:
> Marc,
>
> I have narrowed the reset to the first
>   msr = rdmsr(0xc0010042);
> line in cache_as_ram.c.
> I assume the second would do the same thing if it ever made it there.
>
> Booting with the orig bios, linux reports
> ts ttp tm stc 100mhzsteps
> as the available power options. It is missing fid vid.
>
> Based on the lack of cpuinfo bits and the documentation the says the
> processor will do exactly what it is doing, I propose the included patch.
> I made the changes to pistachio and norwich also but they are untested.
>
> With this patch I make it here:
>
> coreboot-2.0.0 Wed Jan  7 17:09:38 PST 2009
> starting...
> bsp_apicid=0x0
> Enabling routing table for node 00
> done.
> Enabling UP
> settings
> Disabling read/write/fill probes for UP...
> done.
> coherent_ht_finalize
> done
> core0
> started:
> SBLink=00
> NC
> node|link=00
> rs690_early_setup()
> get_cpu_rev
> EAX=0x60fc2.
> CPU Rev is
> K8_G0.
> NB Revision is
> A12.
> k8_optimization()
> rs690_por_init
> sb600_early_setup()
> sb600_devices_por_init()
> sb600_devices_por_init(): SMBus Device,
> BDF:0-20-0
> SMBus controller enabled, sb revision is
> 0x13
> sb600_devices_por_init(): IDE Device,
> BDF:0-20-1
> sb600_devices_por_init(): LPC Device,
> BDF:0-20-3
> sb600_devices_por_init(): P2P Bridge,
> BDF:0-20-4
> sb600_devices_por_init(): SATA Device,
> BDF:0-18-0
> sb600_pmio_por_init()
> Changing FIDVID not supported
>
> entering
> optimize_link_incoherent_ht
> sysinfo->link_pair_num=0x1
> entering
> ht_optimize_link
> pos=0x8a, unfiltered
> freq_cap=0x8035
> pos=0x8a, filtered
> freq_cap=0x35
> pos=0xd2, unfiltered
> freq_cap=0x65
> pos=0xd2, filtered
> freq_cap=0x65
> freq_cap1=0x35,
> freq_cap2=0x65
> dev1 old_freq=0x5, freq=0x5,
> needs_reset=0x0
> dev2 old_freq=0x5, freq=0x5,
> needs_reset=0x0
> width_cap1=0x11,
> width_cap2=0x11
> dev1 input ln_width1=0x4,
> ln_width2=0x4
> dev1 input
> width=0x1
> dev1 output ln_width1=0x4,
> ln_width2=0x4
> dev1 input|output
> width=0x11
> old dev1 input|output
> width=0x11
> dev2 input|output
> width=0x11
> old dev2 input|output
> width=0x11
> after ht_optimize_link for link pair 0,
> reset_needed=0x0
> after optimize_link_read_pointers_chain,
> reset_needed=0x0
> rs690_htinit
> k8_ht_freq=5.
> rs690_htinit
> NB_CFG_Q_F1000_800=0
> needs_reset=0x0
> sysinfo->nodes:  1  sysinfo->ctrl: cf188  spd_addr:
> ffffae98
> Ram1.00
> setting up CPU00 northbridge
> registers
> done.
> Ram2.00
> Enable 64MuxMode &
> BurstLength32
> Unbuffered
> 333Mhz
> 333Mhz
>
> Thanks,
> Dan Lykowski
>
> Signed-off-by: Dan Lykowski <lykowdk at gmail.com>

That looks correct to me. Maybe Bao or someone cold test and ack it.

Marc



From svn at coreboot.org  Thu Jan  8 21:07:21 2009
From: svn at coreboot.org (svn at coreboot.org)
Date: Thu,  8 Jan 2009 21:07:21 +0100
Subject: [coreboot] r1111 - coreboot-v3/northbridge/amd/geodelx
Message-ID: <mailman.2655.1355071468.16123.coreboot@coreboot.org>

Author: myles
Date: 2009-01-08 21:07:21 +0100 (Thu, 08 Jan 2009)
New Revision: 1111

Modified:
   coreboot-v3/northbridge/amd/geodelx/geodelx.c
Log:
This patch adds reserved regions to the geode northbridge for the ROM and
IOAPIC.

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


Modified: coreboot-v3/northbridge/amd/geodelx/geodelx.c
===================================================================
--- coreboot-v3/northbridge/amd/geodelx/geodelx.c	2009-01-08 17:21:37 UTC (rev 1110)
+++ coreboot-v3/northbridge/amd/geodelx/geodelx.c	2009-01-08 20:07:21 UTC (rev 1111)
@@ -149,8 +149,27 @@
  */
 static void geodelx_pci_domain_read_resources(struct device *dev)
 {
+	struct resource *res;
+
 	/* If the domain has any specific resources, read them here. */
 	pci_domain_read_resources(dev);
+
+	/* Reserve space for the IOAPIC.  This should be in the Southbridge,
+	 * but I couldn't tell which device to put it in. */
+	res = new_resource(dev, 2);
+	res->base = 0xfec00000UL;
+	res->size = 0x100000UL;
+	res->limit = 0xffffffffUL;
+	res->flags = IORESOURCE_MEM | IORESOURCE_FIXED | IORESOURCE_STORED |
+		     IORESOURCE_ASSIGNED;
+
+	/* Reserve space for the ROM. */
+	res = new_resource(dev, 3);
+	res->base = 0xfff00000UL;
+	res->size = 0x100000UL;
+	res->limit = 0xffffffffUL;
+	res->flags = IORESOURCE_MEM | IORESOURCE_FIXED | IORESOURCE_STORED |
+		     IORESOURCE_ASSIGNED;
 }
 
 /**




From mylesgw at gmail.com  Thu Jan  8 21:07:55 2009
From: mylesgw at gmail.com (Myles Watson)
Date: Thu, 8 Jan 2009 13:07:55 -0700
Subject: [coreboot] domain vs device statictree order
In-Reply-To: <534e5dc20901081035g1e5953e8o50046a7fd4fb9c96@mail.gmail.com>
References: <534e5dc20901061513l3b63756mf0a102cddc33ecc0@mail.gmail.com>
	<2831fecf0901071027t461c3c54rf8fd0b54112b5238@mail.gmail.com>
	<20090108020137.GA20844@localdomain>
	<20090108023135.GA21159@localdomain>
	<2831fecf0901072039r52c14481j8e7da3d4ccee7850@mail.gmail.com>
	<20090108135806.GA20056@localdomain>
	<2831fecf0901080752p49b3621dj2c073588f8d119c5@mail.gmail.com>
	<20090108180054.GA28851@localdomain>
	<2831fecf0901081027r2cec5378lb594f2d8179f0f7c@mail.gmail.com>
	<534e5dc20901081035g1e5953e8o50046a7fd4fb9c96@mail.gmail.com>
Message-ID: <2831fecf0901081207t46f41a87hf42fc84f4b3cb4f0@mail.gmail.com>

>> I copied the reserved areas from i440bx_emulation.  Like the comments
>> say, I know these need to be reserved areas, but I'm not exactly sure
>> where they belong.
>>
>> Compile tested.
>>
>> Signed-off-by: Myles Watson <mylesgw at gmail.com>
>
> There is just a PIC in the Geode so you don't need to reserve the
> LAPIC range. You do still need to reserve the ROM range. Just fix up
> the comment.
>
> Acked-by: Marc Jones <marcj303 at gmail.com>

Rev 1111.

Thanks,
Myles



From svens at stackframe.org  Thu Jan  8 21:17:10 2009
From: svens at stackframe.org (Sven Schnelle)
Date: Thu, 08 Jan 2009 21:17:10 +0100
Subject: [coreboot] [PATCH] flashrom: add SST49LF020 support
In-Reply-To: <20090108145839.GA8192@greenwood> (Uwe Hermann's message of "Thu\,
	8 Jan 2009 15\:58\:39 +0100")
References: <877i5ahon6.fsf@apollo.stackframe.org>
	<20090105232701.GD12484@greenwood>
	<87ljtoj0o6.fsf@apollo.stackframe.org>
	<20090107123615.GE7490@greenwood>
	<87zli346o1.fsf@begreifnix.intranet.astaro.de>
	<20090108145839.GA8192@greenwood>
Message-ID: <87mye1pn7d.fsf@apollo.stackframe.org>

Hi Uwe,

Uwe Hermann <uwe at hermann-uwe.de> writes:

> On Wed, Jan 07, 2009 at 01:55:26PM +0100, Sven Schnelle wrote:
>> Uwe Hermann <uwe at hermann-uwe.de> writes:
>> 
>> > Btw, can we mark all the new stuff from your patches as supported in
>> > the wiki, i.e. is all of it tested on hardware?
>> 
>> Yes, they are tested on hardware - i have three Boards here,
>
> OK, wiki updated.
>
>
>> 2 with the Intel 5000 Chipset,
>
> Is this chipset related to or compatible with the new 631xESB/632xESB/3100
> stuff you added in flashrom? Did you test 5000, or 631xESB/632xESB/3100,
> or both?

I should have written Intel 5000/631x/632x/3100 as they are used
together:

$ lspci -tv
-[0000:00]-+-00.0  Intel Corporation 5000P Chipset Memory Controller Hub
           +-02.0-[0000:01-05]--+-00.0-[0000:02-04]--+-00.0-[0000:03]--
           |                    |                    \-02.0-[0000:04]--+-00.0  Intel Corporation 80003ES2LAN Gigabit Ethernet Controller (Copper)
           |                    |                                      \-00.1  Intel Corporation 80003ES2LAN Gigabit Ethernet Controller (Copper)
           |                    \-00.3-[0000:05]----01.0  Adaptec AIC-7892A U160/m
           +-03.0-[0000:06]--
           +-04.0-[0000:07]--+-00.0  ATI Technologies Inc Mobility Radeon HD 3600 Series
           |                 \-00.1  ATI Technologies Inc RV635 Audio device [Radeon HD 3600 Series]
           +-05.0-[0000:08]--
           +-06.0-[0000:09]--
           +-07.0-[0000:0a]--
           +-08.0  Intel Corporation 5000 Series Chipset DMA Engine
           +-10.0  Intel Corporation 5000 Series Chipset FSB Registers
           +-10.1  Intel Corporation 5000 Series Chipset FSB Registers
           +-10.2  Intel Corporation 5000 Series Chipset FSB Registers
           +-11.0  Intel Corporation 5000 Series Chipset Reserved Registers
           +-13.0  Intel Corporation 5000 Series Chipset Reserved Registers
           +-15.0  Intel Corporation 5000 Series Chipset FBD Registers
           +-16.0  Intel Corporation 5000 Series Chipset FBD Registers
           +-1c.0-[0000:0b]--
           +-1d.0  Intel Corporation 631xESB/632xESB/3100 Chipset UHCI USB Controller #1
           +-1d.1  Intel Corporation 631xESB/632xESB/3100 Chipset UHCI USB Controller #2
           +-1d.2  Intel Corporation 631xESB/632xESB/3100 Chipset UHCI USB Controller #3
           +-1d.3  Intel Corporation 631xESB/632xESB/3100 Chipset UHCI USB Controller #4
           +-1d.7  Intel Corporation 631xESB/632xESB/3100 Chipset EHCI USB2 Controller
           +-1e.0-[0000:0c]--
           +-1f.0  Intel Corporation 631xESB/632xESB/3100 Chipset LPC Interface Controller
           +-1f.1  Intel Corporation 631xESB/632xESB IDE Controller
           +-1f.2  Intel Corporation 631xESB/632xESB/3100 Chipset SATA IDE Controller
           \-1f.3  Intel Corporation 631xESB/632xESB/3100 Chipset SMBus
           Controller

Actually i have no idea if i'll have any luck getting something done one
that Platform, but i have two of these Boards, Documentation from Intel
seems to be available, so it's worth a try.

(Real reason is that i've seen the great Presentation from Peter Stuge
at the 25. Chaos Communication Congress (25C3). As i have no boards here
which are supported by coreboot now, only chance to play is trying to add
support for the boards i have. ;) )

>> The reason for adding the Flash/Chipset support is that i want to port/use
>> coreboot on these platforms.
>
> Nice! There's some old AMD-768 code in coreboot-v1, maybe you can use
> that as inspiration (no idea if or how well that worked back then).
> Those files don't have license headers unfortunately, so you can either
> start from scratch with a v2 or even v3 code, or find out who wrote that
> code and add the proper license headers (judging from the svn commit log
> it should be Eric Biederman, GPL2)...

Thanks for that hint, will look into that code :)

Sven.



From ward at gnu.org  Thu Jan  8 21:17:58 2009
From: ward at gnu.org (Ward Vandewege)
Date: Thu, 8 Jan 2009 15:17:58 -0500
Subject: [coreboot] domain vs device statictree order
In-Reply-To: <2831fecf0901081207t46f41a87hf42fc84f4b3cb4f0@mail.gmail.com>
References: <2831fecf0901071027t461c3c54rf8fd0b54112b5238@mail.gmail.com>
	<20090108020137.GA20844@localdomain>
	<20090108023135.GA21159@localdomain>
	<2831fecf0901072039r52c14481j8e7da3d4ccee7850@mail.gmail.com>
	<20090108135806.GA20056@localdomain>
	<2831fecf0901080752p49b3621dj2c073588f8d119c5@mail.gmail.com>
	<20090108180054.GA28851@localdomain>
	<2831fecf0901081027r2cec5378lb594f2d8179f0f7c@mail.gmail.com>
	<534e5dc20901081035g1e5953e8o50046a7fd4fb9c96@mail.gmail.com>
	<2831fecf0901081207t46f41a87hf42fc84f4b3cb4f0@mail.gmail.com>
Message-ID: <20090108201758.GA3534@localdomain>

On Thu, Jan 08, 2009 at 01:07:55PM -0700, Myles Watson wrote:
> >> I copied the reserved areas from i440bx_emulation.  Like the comments
> >> say, I know these need to be reserved areas, but I'm not exactly sure
> >> where they belong.
> >>
> >> Compile tested.
> >>
> >> Signed-off-by: Myles Watson <mylesgw at gmail.com>
> >
> > There is just a PIC in the Geode so you don't need to reserve the
> > LAPIC range. You do still need to reserve the ROM range. Just fix up
> > the comment.
> >
> > Acked-by: Marc Jones <marcj303 at gmail.com>
> 
> Rev 1111.

Still the same, sadly, cf attached.

Thanks,
Ward.

-- 
Ward Vandewege <ward at fsf.org>
Free Software Foundation - Senior Systems Administrator
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 14.cap.gz
Type: application/octet-stream
Size: 11165 bytes
Desc: not available
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20090108/2ba7325f/attachment.obj>

From mylesgw at gmail.com  Thu Jan  8 21:57:04 2009
From: mylesgw at gmail.com (Myles Watson)
Date: Thu, 8 Jan 2009 13:57:04 -0700
Subject: [coreboot] domain vs device statictree order
In-Reply-To: <20090108201758.GA3534@localdomain>
References: <2831fecf0901071027t461c3c54rf8fd0b54112b5238@mail.gmail.com>
	<20090108023135.GA21159@localdomain>
	<2831fecf0901072039r52c14481j8e7da3d4ccee7850@mail.gmail.com>
	<20090108135806.GA20056@localdomain>
	<2831fecf0901080752p49b3621dj2c073588f8d119c5@mail.gmail.com>
	<20090108180054.GA28851@localdomain>
	<2831fecf0901081027r2cec5378lb594f2d8179f0f7c@mail.gmail.com>
	<534e5dc20901081035g1e5953e8o50046a7fd4fb9c96@mail.gmail.com>
	<2831fecf0901081207t46f41a87hf42fc84f4b3cb4f0@mail.gmail.com>
	<20090108201758.GA3534@localdomain>
Message-ID: <2831fecf0901081257q1bfbc7f3m6e16a737456f6a3b@mail.gmail.com>

On Thu, Jan 8, 2009 at 1:17 PM, Ward Vandewege <ward at gnu.org> wrote:
> On Thu, Jan 08, 2009 at 01:07:55PM -0700, Myles Watson wrote:
>> >> I copied the reserved areas from i440bx_emulation.  Like the comments
>> >> say, I know these need to be reserved areas, but I'm not exactly sure
>> >> where they belong.
>> >>
>> >> Compile tested.
>> >>
>> >> Signed-off-by: Myles Watson <mylesgw at gmail.com>
>> >
>> > There is just a PIC in the Geode so you don't need to reserve the
>> > LAPIC range. You do still need to reserve the ROM range. Just fix up
>> > the comment.
>> >
>> > Acked-by: Marc Jones <marcj303 at gmail.com>
>>
>> Rev 1111.
>
> Still the same, sadly, cf attached.

I wasn't traversing the tree completely when constraining resources.
This patch adds the domain's resources and all links (not just link 0)
to the tree traversal.  Build and boot tested on qemu and serengeti.

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

Thanks,
Myles



From mylesgw at gmail.com  Thu Jan  8 21:57:39 2009
From: mylesgw at gmail.com (Myles Watson)
Date: Thu, 8 Jan 2009 13:57:39 -0700
Subject: [coreboot] domain vs device statictree order
In-Reply-To: <2831fecf0901081257q1bfbc7f3m6e16a737456f6a3b@mail.gmail.com>
References: <2831fecf0901071027t461c3c54rf8fd0b54112b5238@mail.gmail.com>
	<2831fecf0901072039r52c14481j8e7da3d4ccee7850@mail.gmail.com>
	<20090108135806.GA20056@localdomain>
	<2831fecf0901080752p49b3621dj2c073588f8d119c5@mail.gmail.com>
	<20090108180054.GA28851@localdomain>
	<2831fecf0901081027r2cec5378lb594f2d8179f0f7c@mail.gmail.com>
	<534e5dc20901081035g1e5953e8o50046a7fd4fb9c96@mail.gmail.com>
	<2831fecf0901081207t46f41a87hf42fc84f4b3cb4f0@mail.gmail.com>
	<20090108201758.GA3534@localdomain>
	<2831fecf0901081257q1bfbc7f3m6e16a737456f6a3b@mail.gmail.com>
Message-ID: <2831fecf0901081257k4a6cf197i3a4ff89b3fb8d2df@mail.gmail.com>

And the patch :)
> Signed-off-by: Myles Watson <mylesgw at gmail.com>
>
> Thanks,
> Myles
>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: constraint_fix.diff
Type: text/x-patch
Size: 2613 bytes
Desc: not available
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20090108/66a9a7c6/attachment.diff>

From marcj303 at gmail.com  Thu Jan  8 22:16:18 2009
From: marcj303 at gmail.com (Marc Jones)
Date: Thu, 8 Jan 2009 14:16:18 -0700
Subject: [coreboot] domain vs device statictree order
In-Reply-To: <20090108201758.GA3534@localdomain>
References: <2831fecf0901071027t461c3c54rf8fd0b54112b5238@mail.gmail.com>
	<20090108023135.GA21159@localdomain>
	<2831fecf0901072039r52c14481j8e7da3d4ccee7850@mail.gmail.com>
	<20090108135806.GA20056@localdomain>
	<2831fecf0901080752p49b3621dj2c073588f8d119c5@mail.gmail.com>
	<20090108180054.GA28851@localdomain>
	<2831fecf0901081027r2cec5378lb594f2d8179f0f7c@mail.gmail.com>
	<534e5dc20901081035g1e5953e8o50046a7fd4fb9c96@mail.gmail.com>
	<2831fecf0901081207t46f41a87hf42fc84f4b3cb4f0@mail.gmail.com>
	<20090108201758.GA3534@localdomain>
Message-ID: <534e5dc20901081316r5ef154efoca4a09e3e9262110@mail.gmail.com>

On Thu, Jan 8, 2009 at 1:17 PM, Ward Vandewege <ward at gnu.org> wrote:
> On Thu, Jan 08, 2009 at 01:07:55PM -0700, Myles Watson wrote:
>> >> I copied the reserved areas from i440bx_emulation.  Like the comments
>> >> say, I know these need to be reserved areas, but I'm not exactly sure
>> >> where they belong.
>> >>
>> >> Compile tested.
>> >>
>> >> Signed-off-by: Myles Watson <mylesgw at gmail.com>
>> >
>> > There is just a PIC in the Geode so you don't need to reserve the
>> > LAPIC range. You do still need to reserve the ROM range. Just fix up
>> > the comment.
>> >
>> > Acked-by: Marc Jones <marcj303 at gmail.com>
>>
>> Rev 1111.
>
> Still the same, sadly, cf attached.
>

I see the graphics device still getting setup even though it has no
memory. I think that is might be a problem. This patch hides the
header before resource allocation and should avoid the problem and is
completely untested.....

Marc
-------------- next part --------------
A non-text attachment was scrubbed...
Name: hidegraphics.patch
Type: application/octet-stream
Size: 2042 bytes
Desc: not available
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20090108/88edba45/attachment.obj>

From corey.osgood at gmail.com  Thu Jan  8 23:07:41 2009
From: corey.osgood at gmail.com (Corey Osgood)
Date: Thu, 8 Jan 2009 17:07:41 -0500
Subject: [coreboot] [RFC] Netbook Support
In-Reply-To: <49609F4D.6080602@assembler.cz>
References: <49430370.4020508@onelabs.com>
	<dd3c80060812121657p7e902672x92fc00e557829a6@mail.gmail.com>
	<49431788.3000107@onelabs.com>
	<13426df10812122157s30c4ad72ycde1716792c066a8@mail.gmail.com>
	<4943DF6B.7080901@cosmicpenguin.net> <494411BE.1000104@gmx.net>
	<494471A7.6000801@gmail.com> <4944BA6F.6030005@onelabs.com>
	<49491B85.9080808@gmail.com> <49609F4D.6080602@assembler.cz>
Message-ID: <dd3c80060901081407u2f585b7am5fefd98605a79f22@mail.gmail.com>

On Sun, Jan 4, 2009 at 6:36 AM, Rudolf Marek <r.marek at assembler.cz> wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Hi all,
>
> > do end up needed to did deeper and you can't get any info from the
> > manufacturer then EnE is your best bet for reverse engineering.
>
>
> I have taken a BIOS from Mini A110 (q1d25i.rom). The Quanta IL1 reference
> design
> seems to use ENE3310 controller. The q1d25i.rom was examined. The EC code
> is on
> 0xFFF00000 length is 64KB. The file is called HOLE0.ROM inside BIOS.
>
> The ENE KB3310 seems to be similar to ENE KB3920, which datasheet I found
> via
> google.
>
> I have taken IDA and did the LST file. It has 8051 inside. Yesterday I
> spoke
> with Bari and got the s51 emulator from (SVN:
> https://sdcc.svn.sourceforge.net/svnroot/sdcc/trunk).
>
> I fixed the serial port issue, and now the firmware runs inside emulator:
>
> Serial output:
> 00,
> ec[ECFV]==80ac
> wake at z,ACOut
> Zttttttttttttttttttttttttttt
>
> It prints 't' every second or so.
>
> It seems that a flash can be flashed even unsoldered via serial interface
> of EC.
> (some other pins must be pulled low)
>
> http://laptop.org/teamwiki/images/e/e5/SPI_Recovery.pdf
>
> Here is a EC schematics from reference design.
> http://laptop.org/teamwiki/images/f/fe/CL1_A1A.pdf


Those links are dead, any chance you know where they've moved to?

Thanks,
Corey
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20090108/47f9750b/attachment.html>

From c-d.hailfinger.devel.2006 at gmx.net  Thu Jan  8 23:21:35 2009
From: c-d.hailfinger.devel.2006 at gmx.net (Carl-Daniel Hailfinger)
Date: Thu, 08 Jan 2009 23:21:35 +0100
Subject: [coreboot] [RFC] Netbook Support
In-Reply-To: <dd3c80060901081407u2f585b7am5fefd98605a79f22@mail.gmail.com>
References: <49430370.4020508@onelabs.com>	
	<dd3c80060812121657p7e902672x92fc00e557829a6@mail.gmail.com>	
	<49431788.3000107@onelabs.com>	
	<13426df10812122157s30c4ad72ycde1716792c066a8@mail.gmail.com>	
	<4943DF6B.7080901@cosmicpenguin.net>
	<494411BE.1000104@gmx.net>	 <494471A7.6000801@gmail.com>
	<4944BA6F.6030005@onelabs.com>	 <49491B85.9080808@gmail.com>
	<49609F4D.6080602@assembler.cz>
	<dd3c80060901081407u2f585b7am5fefd98605a79f22@mail.gmail.com>
Message-ID: <49667C6F.4090904@gmx.net>

On 08.01.2009 23:07, Corey Osgood wrote:
> On Sun, Jan 4, 2009 at 6:36 AM, Rudolf Marek <r.marek at assembler.cz> wrote:
>
>   
>> -----BEGIN PGP SIGNED MESSAGE-----
>> Hash: SHA1
>>
>> Hi all,
>>
>>     
>>> do end up needed to did deeper and you can't get any info from the
>>> manufacturer then EnE is your best bet for reverse engineering.
>>>       
>> I have taken a BIOS from Mini A110 (q1d25i.rom). The Quanta IL1 reference
>> design
>> seems to use ENE3310 controller. The q1d25i.rom was examined. The EC code
>> is on
>> 0xFFF00000 length is 64KB. The file is called HOLE0.ROM inside BIOS.
>>
>> The ENE KB3310 seems to be similar to ENE KB3920, which datasheet I found
>> via
>> google.
>>
>> I have taken IDA and did the LST file. It has 8051 inside. Yesterday I
>> spoke
>> with Bari and got the s51 emulator from (SVN:
>> https://sdcc.svn.sourceforge.net/svnroot/sdcc/trunk).
>>
>> I fixed the serial port issue, and now the firmware runs inside emulator:
>>
>> Serial output:
>> 00,
>> ec[ECFV]==80ac
>> wake at z,ACOut
>> Zttttttttttttttttttttttttttt
>>
>> It prints 't' every second or so.
>>
>> It seems that a flash can be flashed even unsoldered via serial interface
>> of EC.
>> (some other pins must be pulled low)
>>
>> http://laptop.org/teamwiki/images/e/e5/SPI_Recovery.pdf
>>
>> Here is a EC schematics from reference design.
>> http://laptop.org/teamwiki/images/f/fe/CL1_A1A.pdf
>>     
>
>
> Those links are dead, any chance you know where they've moved to?
>   

The whole team wiki seems to be dead.
The google cache is somewhat helpful:
http://209.85.129.132/search?q=cache:3Rz-90dw9JUJ:www.laptop.org/teamwiki/images/f/fe/CL1_A1A.pdf
http://209.85.129.132/search?q=cache:bSz5-sskn5QJ:laptop.org/teamwiki/images/e/e5/SPI_Recovery.pdf
Get them while the google cache is still hot.

Regards,
Carl-Daniel

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




From mylesgw at gmail.com  Thu Jan  8 23:45:55 2009
From: mylesgw at gmail.com (Myles Watson)
Date: Thu, 8 Jan 2009 15:45:55 -0700
Subject: [coreboot] domain vs device statictree order
In-Reply-To: <534e5dc20901081316r5ef154efoca4a09e3e9262110@mail.gmail.com>
References: <2831fecf0901071027t461c3c54rf8fd0b54112b5238@mail.gmail.com>
	<20090108023135.GA21159@localdomain>
	<2831fecf0901072039r52c14481j8e7da3d4ccee7850@mail.gmail.com>
	<20090108135806.GA20056@localdomain>
	<2831fecf0901080752p49b3621dj2c073588f8d119c5@mail.gmail.com>
	<20090108180054.GA28851@localdomain>
	<2831fecf0901081027r2cec5378lb594f2d8179f0f7c@mail.gmail.com>
	<534e5dc20901081035g1e5953e8o50046a7fd4fb9c96@mail.gmail.com>
	<2831fecf0901081207t46f41a87hf42fc84f4b3cb4f0@mail.gmail.com>
	<20090108201758.GA3534@localdomain>
	<534e5dc20901081316r5ef154efoca4a09e3e9262110@mail.gmail.com>
Message-ID: <034861328A344F45BDBB18716024910E@chimp>



> -----Original Message-----
> From: Marc Jones [mailto:marcj303 at gmail.com]
> Sent: Thursday, January 08, 2009 2:16 PM
> To: Myles Watson; Marc Jones; ron minnich; Coreboot
> Subject: Re: [coreboot] domain vs device statictree order
> 
> On Thu, Jan 8, 2009 at 1:17 PM, Ward Vandewege <ward at gnu.org> wrote:
> > On Thu, Jan 08, 2009 at 01:07:55PM -0700, Myles Watson wrote:
> >> >> I copied the reserved areas from i440bx_emulation.  Like the
> comments
> >> >> say, I know these need to be reserved areas, but I'm not exactly
> sure
> >> >> where they belong.
> >> >>
> >> >> Compile tested.
> >> >>
> >> >> Signed-off-by: Myles Watson <mylesgw at gmail.com>
> >> >
> >> > There is just a PIC in the Geode so you don't need to reserve the
> >> > LAPIC range. You do still need to reserve the ROM range. Just fix up
> >> > the comment.
> >> >
> >> > Acked-by: Marc Jones <marcj303 at gmail.com>
> >>
> >> Rev 1111.
> >
> > Still the same, sadly, cf attached.
> >
> 
> I see the graphics device still getting setup even though it has no
> memory. I think that is might be a problem. This patch hides the
> header before resource allocation and should avoid the problem and is
> completely untested.....

It seems cleaner to hide the graphics when there's no memory allocated, but
is the geodelx always paired with the cs5536?  It's surprising to have them
be that tightly coupled.

I think I'd prefer to hide the device in the cs5536 stage2_fixup.  That way
it can stay in cs5536, but get done in the right order.  I would submit a
patch, but while I was there I saw that there are other things (ide vs nand)
that probably should be moved at the same time, and Mart's already working
on that.

Thanks,
Myles




From ward at gnu.org  Fri Jan  9 01:52:56 2009
From: ward at gnu.org (Ward Vandewege)
Date: Thu, 8 Jan 2009 19:52:56 -0500
Subject: [coreboot] domain vs device statictree order
In-Reply-To: <2831fecf0901081257k4a6cf197i3a4ff89b3fb8d2df@mail.gmail.com>
References: <2831fecf0901072039r52c14481j8e7da3d4ccee7850@mail.gmail.com>
	<20090108135806.GA20056@localdomain>
	<2831fecf0901080752p49b3621dj2c073588f8d119c5@mail.gmail.com>
	<20090108180054.GA28851@localdomain>
	<2831fecf0901081027r2cec5378lb594f2d8179f0f7c@mail.gmail.com>
	<534e5dc20901081035g1e5953e8o50046a7fd4fb9c96@mail.gmail.com>
	<2831fecf0901081207t46f41a87hf42fc84f4b3cb4f0@mail.gmail.com>
	<20090108201758.GA3534@localdomain>
	<2831fecf0901081257q1bfbc7f3m6e16a737456f6a3b@mail.gmail.com>
	<2831fecf0901081257k4a6cf197i3a4ff89b3fb8d2df@mail.gmail.com>
Message-ID: <20090109005256.GA14466@localdomain>

On Thu, Jan 08, 2009 at 01:57:39PM -0700, Myles Watson wrote:
> And the patch :)

Yay, that fixes booting (log attached).

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

Acked-by: Ward Vandewege <ward at gnu.org>

Thanks,
Ward.

-- 
Ward Vandewege <ward at fsf.org>
Free Software Foundation - Senior Systems Administrator
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 15.cap.gz
Type: application/octet-stream
Size: 8948 bytes
Desc: not available
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20090108/f51aece6/attachment.obj>

From ward at gnu.org  Fri Jan  9 01:54:26 2009
From: ward at gnu.org (Ward Vandewege)
Date: Thu, 8 Jan 2009 19:54:26 -0500
Subject: [coreboot] domain vs device statictree order
In-Reply-To: <534e5dc20901081316r5ef154efoca4a09e3e9262110@mail.gmail.com>
References: <20090108023135.GA21159@localdomain>
	<2831fecf0901072039r52c14481j8e7da3d4ccee7850@mail.gmail.com>
	<20090108135806.GA20056@localdomain>
	<2831fecf0901080752p49b3621dj2c073588f8d119c5@mail.gmail.com>
	<20090108180054.GA28851@localdomain>
	<2831fecf0901081027r2cec5378lb594f2d8179f0f7c@mail.gmail.com>
	<534e5dc20901081035g1e5953e8o50046a7fd4fb9c96@mail.gmail.com>
	<2831fecf0901081207t46f41a87hf42fc84f4b3cb4f0@mail.gmail.com>
	<20090108201758.GA3534@localdomain>
	<534e5dc20901081316r5ef154efoca4a09e3e9262110@mail.gmail.com>
Message-ID: <20090109005426.GB14466@localdomain>

On Thu, Jan 08, 2009 at 02:16:18PM -0700, Marc Jones wrote:
> On Thu, Jan 8, 2009 at 1:17 PM, Ward Vandewege <ward at gnu.org> wrote:
> > On Thu, Jan 08, 2009 at 01:07:55PM -0700, Myles Watson wrote:
> >> >> I copied the reserved areas from i440bx_emulation.  Like the comments
> >> >> say, I know these need to be reserved areas, but I'm not exactly sure
> >> >> where they belong.
> >> >>
> >> >> Compile tested.
> >> >>
> >> >> Signed-off-by: Myles Watson <mylesgw at gmail.com>
> >> >
> >> > There is just a PIC in the Geode so you don't need to reserve the
> >> > LAPIC range. You do still need to reserve the ROM range. Just fix up
> >> > the comment.
> >> >
> >> > Acked-by: Marc Jones <marcj303 at gmail.com>
> >>
> >> Rev 1111.
> >
> > Still the same, sadly, cf attached.
> >
> 
> I see the graphics device still getting setup even though it has no
> memory. I think that is might be a problem. This patch hides the
> header before resource allocation and should avoid the problem and is
> completely untested.....

I tested with a few small (typo) changes, but it does not fix the boot. Log
attached. Myles' patch does fix it though, and for what it's worth, it also
boots with both patches applied.

Thanks,
Ward.

-- 
Ward Vandewege <ward at fsf.org>
Free Software Foundation - Senior Systems Administrator
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 16.cap.gz
Type: application/octet-stream
Size: 13043 bytes
Desc: not available
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20090108/4eb22e56/attachment.obj>

From marcj303 at gmail.com  Fri Jan  9 02:12:15 2009
From: marcj303 at gmail.com (Marc Jones)
Date: Thu, 8 Jan 2009 18:12:15 -0700
Subject: [coreboot] domain vs device statictree order
In-Reply-To: <034861328A344F45BDBB18716024910E@chimp>
References: <2831fecf0901071027t461c3c54rf8fd0b54112b5238@mail.gmail.com>
	<20090108135806.GA20056@localdomain>
	<2831fecf0901080752p49b3621dj2c073588f8d119c5@mail.gmail.com>
	<20090108180054.GA28851@localdomain>
	<2831fecf0901081027r2cec5378lb594f2d8179f0f7c@mail.gmail.com>
	<534e5dc20901081035g1e5953e8o50046a7fd4fb9c96@mail.gmail.com>
	<2831fecf0901081207t46f41a87hf42fc84f4b3cb4f0@mail.gmail.com>
	<20090108201758.GA3534@localdomain>
	<534e5dc20901081316r5ef154efoca4a09e3e9262110@mail.gmail.com>
	<034861328A344F45BDBB18716024910E@chimp>
Message-ID: <534e5dc20901081712l15e88c7eg205adb0fc76c4e0b@mail.gmail.com>

On Thu, Jan 8, 2009 at 3:45 PM, Myles Watson <mylesgw at gmail.com> wrote:
>
>
>> -----Original Message-----
>> From: Marc Jones [mailto:marcj303 at gmail.com]
>> Sent: Thursday, January 08, 2009 2:16 PM
>> To: Myles Watson; Marc Jones; ron minnich; Coreboot
>> Subject: Re: [coreboot] domain vs device statictree order
>>
>> On Thu, Jan 8, 2009 at 1:17 PM, Ward Vandewege <ward at gnu.org> wrote:
>> > On Thu, Jan 08, 2009 at 01:07:55PM -0700, Myles Watson wrote:
>> >> >> I copied the reserved areas from i440bx_emulation.  Like the
>> comments
>> >> >> say, I know these need to be reserved areas, but I'm not exactly
>> sure
>> >> >> where they belong.
>> >> >>
>> >> >> Compile tested.
>> >> >>
>> >> >> Signed-off-by: Myles Watson <mylesgw at gmail.com>
>> >> >
>> >> > There is just a PIC in the Geode so you don't need to reserve the
>> >> > LAPIC range. You do still need to reserve the ROM range. Just fix up
>> >> > the comment.
>> >> >
>> >> > Acked-by: Marc Jones <marcj303 at gmail.com>
>> >>
>> >> Rev 1111.
>> >
>> > Still the same, sadly, cf attached.
>> >
>>
>> I see the graphics device still getting setup even though it has no
>> memory. I think that is might be a problem. This patch hides the
>> header before resource allocation and should avoid the problem and is
>> completely untested.....
>
> It seems cleaner to hide the graphics when there's no memory allocated, but
> is the geodelx always paired with the cs5536?  It's surprising to have them
> be that tightly coupled.
>
> I think I'd prefer to hide the device in the cs5536 stage2_fixup.  That way
> it can stay in cs5536, but get done in the right order.  I would submit a
> patch, but while I was there I saw that there are other things (ide vs nand)
> that probably should be moved at the same time, and Mart's already working
> on that.

Yes they are that closely attached and use the same SMM code which is
how the device is hidden. I think that hiding the graphics device
during graphics init is the right thing to do.

Marc



From Zheng.Bao at amd.com  Fri Jan  9 03:44:25 2009
From: Zheng.Bao at amd.com (Bao, Zheng)
Date: Fri, 9 Jan 2009 10:44:25 +0800
Subject: [coreboot] [patch] Proposed patch for FIDVID question
In-Reply-To: <231212.15416.qm@web57001.mail.re3.yahoo.com>
References: <231212.15416.qm@web57001.mail.re3.yahoo.com>
Message-ID: <DD1CC71B621B004FA76856E5129D6B17024FEDAD@sbjgexmb1.amd.com>

It works on dbm690t and pistachio. Please note some indents are spaces instead of tabs. Please correct it.

Zheng

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

________________________________________
From: coreboot-bounces+zheng.bao=amd.com at coreboot.org [mailto:coreboot-bounces+zheng.bao=amd.com at coreboot.org] On Behalf Of Dan Lykowski
Sent: Friday, January 09, 2009 2:28 AM
To: Marc Jones
Cc: Coreboot
Subject: [coreboot] [patch] Proposed patch for FIDVID question

Marc,

I have narrowed the reset to the first
? msr = rdmsr(0xc0010042); 
line in cache_as_ram.c.
I assume the second would do the same thing if it ever made it there.

Booting with the orig bios, linux reports
ts ttp tm stc 100mhzsteps
as the available power options. It is missing fid vid.

Based on the lack of cpuinfo bits and the documentation the says the processor will do exactly what it is doing, I propose the included patch.
I made the changes to pistachio and norwich also but they are untested.

With this patch I make it here:

coreboot-2.0.0 Wed Jan? 7 17:09:38 PST 2009 starting...???????????????????????? 
bsp_apicid=0x0????????????????????????????????????????????????????????????????? 
Enabling routing table for node 00 done.??????????????????????????????????????? 
Enabling UP settings??????????????????????????????????????????????????????????? 
Disabling read/write/fill probes for UP... done.??????????????????????????????? 
coherent_ht_finalize??????????????????????????????????????????????????????????? 
done??????????????????????????????????????????????????????????????????????????? 
core0 started:????????????????????????????????????????????????????????????????? 
SBLink=00?????????????????????????????????????????????????????????????????????? 
NC node|link=00???????????????????????????????????????????????????????????????? 
rs690_early_setup()???????????????????????????????????????????????????????????? 
get_cpu_rev EAX=0x60fc2.??????????????????????????????????????????????????????? 
CPU Rev is K8_G0.?????????????????????????????????????????????????????????????? 
NB Revision is A12.???????????????????????????????????????????????????????????? 
k8_optimization()?????????????????????????????????????????????????????????????? 
rs690_por_init????????????????????????????????????????????????????????????????? 
sb600_early_setup()???????????????????????????????????????????????????????????? 
sb600_devices_por_init()??????????????????????????????????????????????????????? 
sb600_devices_por_init(): SMBus Device, BDF:0-20-0????????????????????????????? 
SMBus controller enabled, sb revision is 0x13?????????????????????????????????? 
sb600_devices_por_init(): IDE Device, BDF:0-20-1??????????????????????????????? 
sb600_devices_por_init(): LPC Device, BDF:0-20-3??????????????????????????????? 
sb600_devices_por_init(): P2P Bridge, BDF:0-20-4??????????????????????????????? 
sb600_devices_por_init(): SATA Device, BDF:0-18-0?????????????????????????????? 
sb600_pmio_por_init()?????????????????????????????????????????????????????????????????????????????????????????????????????? 
Changing FIDVID not supported ??????????????????????????????????????????????????????? 
entering optimize_link_incoherent_ht??????????????????????????????????????????? 
sysinfo->link_pair_num=0x1????????????????????????????????????????????????????? 
entering ht_optimize_link?????????????????????????????????????????????????????? 
pos=0x8a, unfiltered freq_cap=0x8035??????????????????????????????????????????? 
pos=0x8a, filtered freq_cap=0x35??????????????????????????????????????????????? 
pos=0xd2, unfiltered freq_cap=0x65????????????????????????????????????????????? 
pos=0xd2, filtered freq_cap=0x65??????????????????????????????????????????????? 
freq_cap1=0x35, freq_cap2=0x65????????????????????????????????????????????????? 
dev1 old_freq=0x5, freq=0x5, needs_reset=0x0??????????????????????????????????? 
dev2 old_freq=0x5, freq=0x5, needs_reset=0x0??????????????????????????????????? 
width_cap1=0x11, width_cap2=0x11??????????????????????????????????????????????? 
dev1 input ln_width1=0x4, ln_width2=0x4???????????????????????????????????????? 
dev1 input width=0x1??????????????????????????????????????????????????????????? 
dev1 output ln_width1=0x4, ln_width2=0x4??????????????????????????????????????? 
dev1 input|output width=0x11??????????????????????????????????????????????????? 
old dev1 input|output width=0x11??????????????????????????????????????????????? 
dev2 input|output width=0x11??????????????????????????????????????????????????? 
old dev2 input|output width=0x11??????????????????????????????????????????????? 
after ht_optimize_link for link pair 0, reset_needed=0x0??????????????????????? 
after optimize_link_read_pointers_chain, reset_needed=0x0?????????????????????? 
rs690_htinit k8_ht_freq=5.????????????????????????????????????????????????????? 
rs690_htinit NB_CFG_Q_F1000_800=0?????????????????????????????????????????????? 
needs_reset=0x0???????????????????????????????????????????????????????????????? 
sysinfo->nodes:? 1? sysinfo->ctrl: cf188? spd_addr: ffffae98??????????????????? 
Ram1.00???????????????????????????????????????????????????????????????????????? 
setting up CPU00 northbridge registers????????????????????????????????????????? 
done.?????????????????????????????????????????????????????????????????????????? 
Ram2.00???????????????????????????????????????????????????????????????????????? 
Enable 64MuxMode & BurstLength32??????????????????????????????????????????????? 
Unbuffered????????????????????????????????????????????????????????????????????? 
333Mhz????????????????????????????????????????????????????????????????????????? 
333Mhz

Thanks,
Dan Lykowski
Signed-off-by: Dan Lykowski <lykowdk at gmail.com>

--- On Thu, 1/8/09, Marc Jones <marcj303 at gmail.com> wrote:

From: Marc Jones <marcj303 at gmail.com>
Subject: Re: [coreboot] FIDVID question
To: r.marek at assembler.cz
Cc: "Dan Lykowski" <engineerguy3737 at yahoo.com>, "Coreboot" <coreboot at coreboot.org>
Date: Thursday, January 8, 2009, 12:10 PM


-----Inline Attachment Follows-----
On Thu, Jan 8, 2009 at 1:45 AM,? <r.marek at assembler.cz> wrote:
> Hi,
>
> if you check your CPUID, does it support FIDVID?
>
> If yes, then there is another problem. Perhaps you are hit by
> some errata which says first is needed not HT reset (LDTSTOP) but PCI reset.
> I don't have a code at my hand right now, but is HT reset stuff done
> _before_ the fidvid?
>

I think that all the revf/g processors support fidvid even if it can't
be changed. The S1G1 socket means revf and above and checking for
support really isn't needed. I think it is safe for a platform to make
some assumptions like that.

Have you narrowed the reset to the fidvid code?? After fidvid setup
there should be a ht reset as Rudolf noted. You can skip fidvid setup
for now. It just means that the processor will run at min frequency.


Marc

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





From ebiederm at xmission.com  Fri Jan  9 03:44:38 2009
From: ebiederm at xmission.com (Eric W. Biederman)
Date: Thu, 08 Jan 2009 18:44:38 -0800
Subject: [coreboot] [PATCH] v1: Add license headers to AMD AMD-768 code
In-Reply-To: <20090108175314.GA22435@greenwood> (Uwe Hermann's message of
	"Thu, 8 Jan 2009 18:53:14 +0100")
References: <20090108175314.GA22435@greenwood>
Message-ID: <m1zli1xko9.fsf@frodo.ebiederm.org>

Uwe Hermann <uwe at hermann-uwe.de> writes:

> Yay, my first v1 patch :)
>
> Eric, any other code chunks which were mostly/entirely written by you
> where we can slap a GPLv2 header on? AMD-766, others?
>
> Btw, was this code from 2003 (C) Eric W. Biederman or rather (C) LNXI?

Always a fuzzy line that.  If we care how about we slap both on, and
not worry to much about the details.

Eric




From c-d.hailfinger.devel.2006 at gmx.net  Fri Jan  9 06:24:39 2009
From: c-d.hailfinger.devel.2006 at gmx.net (Carl-Daniel Hailfinger)
Date: Fri, 09 Jan 2009 06:24:39 +0100
Subject: [coreboot] [PATCH] flashrom: Add erase and write functions to
 Atmel AT25* and AT26*
In-Reply-To: <49663224.8070001@gmx.net>
References: <49662BF2.5030400@gmx.net>	<2831fecf0901080849m38d43b04nc4cadc36eb8b8e2c@mail.gmail.com>	<20090108170109.9317.qmail@stuge.se>
	<49663224.8070001@gmx.net>
Message-ID: <4966DF97.7060500@gmx.net>

On 08.01.2009 18:04, Carl-Daniel Hailfinger wrote:
> On 08.01.2009 18:01, Peter Stuge wrote:
>   
>> Myles Watson wrote:
>>   
>>     
>>>> @@ -179,7 +179,7 @@
>>>>                .page_size      = 256,
>>>>                .tested         = TEST_OK_PREW,
>>>>                .probe          = probe_spi_rdid,
>>>> -               .erase          = spi_chip_erase_c7,
>>>> +               .erase          = spi_chip_erase_60_c7,
>>>>       
>>>>         
>>> It's surprising to change this one since it was tested OK. 
>>> Shouldn't you mark it TEST_UNTESTED now or TEST_OK_PRW?
>>>     
>>>       
>> Thanks for catching that. Please revert this hunk.
>>   
>>     
>
> Sure, will do. Thanks Myles!
>   

Per the discussion with Peter, that hunk will stay as is unless anyone
objects to the reason below:
The new erase function calls the old erase function and if that fails it
will call an alternative erase function.
Worst case: The new function behaves like the old function.
Best case: The new function works even if the old function fails due to
chipset constraints.

Regards,
Carl-Daniel

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




From Zheng.Bao at amd.com  Fri Jan  9 07:07:30 2009
From: Zheng.Bao at amd.com (Bao, Zheng)
Date: Fri, 9 Jan 2009 14:07:30 +0800
Subject: [coreboot] [flashrom]: AAI program supported?
Message-ID: <DD1CC71B621B004FA76856E5129D6B17024FEE99@sbjgexmb1.amd.com>

Hi, all,
I am trying to add AAI command support in flashrom. We know that some
chips support AAI while others don't. I want to add a member in struct
flashchip to indicate whether this chip support AAI. AAI programming
improves the speed of writing.

Does anyone give some advice? Do you guys think it makes sense?


Zheng




From mdjohnson88 at hotmail.com  Fri Jan  9 02:39:38 2009
From: mdjohnson88 at hotmail.com (Matt Johnson)
Date: Thu, 8 Jan 2009 19:39:38 -0600
Subject: [coreboot] Question about dual operating systems
Message-ID: <BAY117-DS78FBEC49CA68AC843A41CB7DD0@phx.gbl>

I was wondering, let's say I install linux using Wubi (so it isn't a
separate partition)  and want to use coreboot to boot to linux.  Will cause
problems?


Thanks,

Matt

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

From c-d.hailfinger.devel.2006 at gmx.net  Fri Jan  9 10:05:31 2009
From: c-d.hailfinger.devel.2006 at gmx.net (Carl-Daniel Hailfinger)
Date: Fri, 09 Jan 2009 10:05:31 +0100
Subject: [coreboot] AMD DBM690T PowerNow table problems
In-Reply-To: <534e5dc20901080852gbdd37ccu83304fcf206e448a@mail.gmail.com>
References: <49583EA2.8080903@gmx.net> <495FE0E5.7020503@assembler.cz>	
	<534e5dc20901051725l69907601k7d2ccf6817510257@mail.gmail.com>	
	<DD1CC71B621B004FA76856E5129D6B17024A0045@sbjgexmb1.amd.com>	
	<534e5dc20901060847j6c19053av20fe3845ca3df3b5@mail.gmail.com>	
	<4965662A.5060109@gmx.net>
	<534e5dc20901080852gbdd37ccu83304fcf206e448a@mail.gmail.com>
Message-ID: <4967135B.4050608@gmx.net>

On 08.01.2009 17:52, Marc Jones wrote:
> On Wed, Jan 7, 2009 at 7:34 PM, Carl-Daniel Hailfinger
> <c-d.hailfinger.devel.2006 at gmx.net> wrote:
>   
>> On 06.01.2009 17:47, Marc Jones wrote:
>>     
>>> On Mon, Jan 5, 2009 at 6:36 PM, Bao, Zheng <Zheng.Bao at amd.com> wrote:
>>>
>>>       
>>>> If fid_multiplier is 0, it doesn't seem to have any sense. So I agree.
>>>>
>>>> Acked-by: zheng bao <zheng.bao at amd.com>
>>>>
>>>>
>>>>         
>>> I also fixed this in acpi_tables.c Pistachio.
>>>
>>> r 3847
>>>
>>>       
>> Thanks!
>> The Linux kernel powernow-k8 driver doesn't complain anymore, but now
>> the machine will lock up or reboot once I put some load on it.
>> Blacklisting the powernow-k8 driver avoids the issue, but that makes
>> frequency scaling impossible.
>>
>> AFAICS the standard cpu frequency governor is ondemand and it scales the
>> frequency down from 1800 MHz to 1000 Mhz. That seems to work fine, but
>> scaling up again will cause the lockups/reboots. By the way, coreboot
>> reports a BIST failure after such reboots. Not nice.
>>
>> Rudolf's PowerNow tables had entries for 1000/1600/1800 MHz. The
>> proprietary BIOS and coreboot only have entries for 1000/1800 MHz.
>> According to the docs, scaling from 1000 MHz to 1800 MHz can't be done
>> in a single step. Is that maybe the reason for the problems I'm seeing?
>>     
>
>
> Can you dump the current tables or can you not get that far before a
> crash? The entries are end points and the driver takes care of the
> stepping that needs to be done to get to those points. We need to
> check that the table generated the correct vid setting for the fid. It
> is well described in the bkdg section 10.6.
>   

I managed to boot fine with the proprietary BIOS, blacklisted the
k8-powernow driver and rebooted with coreboot.

Attached are the following files:
_PSS with coreboot (crash)
_PSS with proprietary BIOS (ok)

If I combine the _PSS from the proprietary BIOS with the other tables
from coreboot, the machine does not crash. I'll try to narrow it down
further.

Regards,
Carl-Daniel

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




From paulepanter at users.sourceforge.net  Fri Jan  9 10:22:43 2009
From: paulepanter at users.sourceforge.net (Paul Menzel)
Date: Fri, 09 Jan 2009 10:22:43 +0100
Subject: [coreboot] AMD DBM690T PowerNow table problems
In-Reply-To: <4967135B.4050608@gmx.net>
References: <49583EA2.8080903@gmx.net> <495FE0E5.7020503@assembler.cz>
	<534e5dc20901051725l69907601k7d2ccf6817510257@mail.gmail.com>
	<DD1CC71B621B004FA76856E5129D6B17024A0045@sbjgexmb1.amd.com>
	<534e5dc20901060847j6c19053av20fe3845ca3df3b5@mail.gmail.com>
	<4965662A.5060109@gmx.net>
	<534e5dc20901080852gbdd37ccu83304fcf206e448a@mail.gmail.com>
	<4967135B.4050608@gmx.net>
Message-ID: <1231492963.4085.33.camel@mattotaupa.wohnung.familie-menzel.net>

Dear Carl-Daniel,


there were no attachments in the message I received.


Thanks,

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

From mart.raudsepp at artecdesign.ee  Fri Jan  9 11:20:27 2009
From: mart.raudsepp at artecdesign.ee (Mart Raudsepp)
Date: Fri, 09 Jan 2009 12:20:27 +0200
Subject: [coreboot] domain vs device statictree order
In-Reply-To: <534e5dc20901081712l15e88c7eg205adb0fc76c4e0b@mail.gmail.com>
References: <2831fecf0901071027t461c3c54rf8fd0b54112b5238@mail.gmail.com>
	<20090108135806.GA20056@localdomain>
	<2831fecf0901080752p49b3621dj2c073588f8d119c5@mail.gmail.com>
	<20090108180054.GA28851@localdomain>
	<2831fecf0901081027r2cec5378lb594f2d8179f0f7c@mail.gmail.com>
	<534e5dc20901081035g1e5953e8o50046a7fd4fb9c96@mail.gmail.com>
	<2831fecf0901081207t46f41a87hf42fc84f4b3cb4f0@mail.gmail.com>
	<20090108201758.GA3534@localdomain>
	<534e5dc20901081316r5ef154efoca4a09e3e9262110@mail.gmail.com>
	<034861328A344F45BDBB18716024910E@chimp>
	<534e5dc20901081712l15e88c7eg205adb0fc76c4e0b@mail.gmail.com>
Message-ID: <1231496427.4558.6.camel@martr-gentoo.artec>

?hel kenal p?eval, N, 2009-01-08 kell 18:12, kirjutas Marc Jones:
> On Thu, Jan 8, 2009 at 3:45 PM, Myles Watson <mylesgw at gmail.com> wrote:
> >
> >
> >> -----Original Message-----
> >> From: Marc Jones [mailto:marcj303 at gmail.com]
> >> Sent: Thursday, January 08, 2009 2:16 PM
> >> To: Myles Watson; Marc Jones; ron minnich; Coreboot
> >> Subject: Re: [coreboot] domain vs device statictree order
> >>
> >> On Thu, Jan 8, 2009 at 1:17 PM, Ward Vandewege <ward at gnu.org> wrote:
> >> > On Thu, Jan 08, 2009 at 01:07:55PM -0700, Myles Watson wrote:
> >> >> >> I copied the reserved areas from i440bx_emulation.  Like the
> >> comments
> >> >> >> say, I know these need to be reserved areas, but I'm not exactly
> >> sure
> >> >> >> where they belong.
> >> >> >>
> >> >> >> Compile tested.
> >> >> >>
> >> >> >> Signed-off-by: Myles Watson <mylesgw at gmail.com>
> >> >> >
> >> >> > There is just a PIC in the Geode so you don't need to reserve the
> >> >> > LAPIC range. You do still need to reserve the ROM range. Just fix up
> >> >> > the comment.
> >> >> >
> >> >> > Acked-by: Marc Jones <marcj303 at gmail.com>
> >> >>
> >> >> Rev 1111.
> >> >
> >> > Still the same, sadly, cf attached.
> >> >
> >>
> >> I see the graphics device still getting setup even though it has no
> >> memory. I think that is might be a problem. This patch hides the
> >> header before resource allocation and should avoid the problem and is
> >> completely untested.....
> >
> > It seems cleaner to hide the graphics when there's no memory allocated, but
> > is the geodelx always paired with the cs5536?  It's surprising to have them
> > be that tightly coupled.
> >
> > I think I'd prefer to hide the device in the cs5536 stage2_fixup.  That way
> > it can stay in cs5536, but get done in the right order.  I would submit a
> > patch, but while I was there I saw that there are other things (ide vs nand)
> > that probably should be moved at the same time, and Mart's already working
> > on that.
> 
> Yes they are that closely attached and use the same SMM code which is
> how the device is hidden. I think that hiding the graphics device
> during graphics init is the right thing to do.

We now have a graphics device in the device tree of mainboards.
How about having a graphics device in northbridge/amd/geodelx or
southbridge/amd/cs5536 too, and doing graphics init from there if the
device exists in mainboard device tree? Or does that need to be run even
on headless?
Also, what if we had the possibility to run code for disabled devices -
then the vpci hiding could cleanly happen when the device is disabled
instead of checks from northbridge code. Like a .disable functor in
device_ops?

Take it as a possible thought on how to make things more v3-ish if you
will. The hiding on zero graphics memory patch is still good in the
current state and should be committed for the time being either way
imho.


Regards,
Mart Raudsepp
Artec Design LLC




From c-d.hailfinger.devel.2006 at gmx.net  Fri Jan  9 13:10:29 2009
From: c-d.hailfinger.devel.2006 at gmx.net (Carl-Daniel Hailfinger)
Date: Fri, 09 Jan 2009 13:10:29 +0100
Subject: [coreboot] [flashrom]: AAI program supported?
In-Reply-To: <DD1CC71B621B004FA76856E5129D6B17024FEE99@sbjgexmb1.amd.com>
References: <DD1CC71B621B004FA76856E5129D6B17024FEE99@sbjgexmb1.amd.com>
Message-ID: <49673EB5.5020708@gmx.net>

Hi Zheng,

On 09.01.2009 07:07, Bao, Zheng wrote:
> Hi, all,
> I am trying to add AAI command support in flashrom. We know that some
> chips support AAI while others don't. I want to add a member in struct
> flashchip to indicate whether this chip support AAI. AAI programming
> improves the speed of writing.
>
> Does anyone give some advice? Do you guys think it makes sense?
>   

Yes, it makes sense, but all current mainboards don't support it. The
big problem is that AAI for FWH/LPC needs another electrical interface
and the boards do not have that interface. For SPI the situation is similar.

If we add AAI support to flashrom, it will only work with external
programmers.

Regards,
Carl-Daniel

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




From mart.raudsepp at artecdesign.ee  Fri Jan  9 13:20:56 2009
From: mart.raudsepp at artecdesign.ee (Mart Raudsepp)
Date: Fri, 09 Jan 2009 14:20:56 +0200
Subject: [coreboot] [PATCH 1/2] cs5536: Add a NAND device and do the IDE PCI
 header disabling on time.
Message-ID: <1231503657.4558.9.camel@martr-gentoo.artec>

cs5536: Add a NAND device and do the IDE PCI header disabling on time.

This implements a nand device, akin to the ide device to follow the coreboot-v3 device tree design better.
It allows us to do the IDE PCI header early enough in a clean way - the hide_vpci was called way too late
before - in phase6 of southbridge device, but we need the Flash header active instead of IDE in the VSA2
before bus scans happen, or the PCI device gets disabled in coreboot understanding by the time we get it
enabled in VSA2.
It makes NAND setup work better, but still not completely. There is a VSA2 bug for which I made a patch,
but waiting on a new binary to test if after that everything works or not. A quick hack to workaround the
VSA2 bug suggests something further will still need fixing. There are also more potential opportunities
to shuffle NAND code around to match v3 approach better, but that's a next step for me after NAND setup
actually works right in the current form.

Also corrected the documentation of ide_init() to match current reality.

Signed-off-by: Mart Raudsepp <mart.raudsepp at artecdesign.ee>
---
 mainboard/artecgroup/dbe61/dts  |    3 ++
 mainboard/artecgroup/dbe62/dts  |    3 ++
 southbridge/amd/cs5536/cs5536.c |   47 ++++++++++++++++++++++++--------------
 southbridge/amd/cs5536/nand     |   23 +++++++++++++++++++
 4 files changed, 59 insertions(+), 17 deletions(-)
 create mode 100644 southbridge/amd/cs5536/nand

diff --git a/mainboard/artecgroup/dbe61/dts b/mainboard/artecgroup/dbe61/dts
index b443533..48df288 100644
--- a/mainboard/artecgroup/dbe61/dts
+++ b/mainboard/artecgroup/dbe61/dts
@@ -109,6 +109,9 @@ end
 			/* USB Port Power Handling setting. */
 			pph = "0xf5";
 		};
+		pci at f,1 {
+			/config/("southbridge/amd/cs5536/nand");
+		};
 		pci at f,2 {
 			/config/("southbridge/amd/cs5536/ide");
 		};
diff --git a/mainboard/artecgroup/dbe62/dts b/mainboard/artecgroup/dbe62/dts
index 213c397..3cbe0ff 100644
--- a/mainboard/artecgroup/dbe62/dts
+++ b/mainboard/artecgroup/dbe62/dts
@@ -63,6 +63,9 @@
 			/* USB Port Power Handling setting. */
 			pph = "0xf5";
 		};
+		pci at f,1 {
+			/config/("southbridge/amd/cs5536/nand");
+		};
 		pci at f,2 {
 			/config/("southbridge/amd/cs5536/ide");
 		};
diff --git a/southbridge/amd/cs5536/cs5536.c b/southbridge/amd/cs5536/cs5536.c
index 89d64d6..0c5adb1 100644
--- a/southbridge/amd/cs5536/cs5536.c
+++ b/southbridge/amd/cs5536/cs5536.c
@@ -98,6 +98,21 @@ static void hide_vpci(u32 vpci_devid)
 }
 
 /**
+ * Enables the FLASH PCI header when NAND device existing in mainboard device
+ * tree. Used when the mainboard has a FLASH part instead of an IDE drive and
+ * that fact is expressed in the mainboard device tree.
+ * Must be called after VSA init but before PCI scans to enable the flash
+ * PCI device header early enough - that is .phase2_fixup of the device.
+ *
+ * @param dev The device.
+ */
+static void nand_phase2(struct device *dev)
+{
+	/* Tell VSA to use FLASH PCI header. Not IDE header. */
+	hide_vpci(0x800079C4);
+}
+
+/**
  * Power button setup.
  *
  * Setup GPIO24, it is the external signal for CS5536 vsb_work_aux which
@@ -170,16 +185,6 @@ static void chipset_flash_setup(struct southbridge_amd_cs5536_dts_config *sb)
 	printk(BIOS_DEBUG, "chipset_flash_setup: Finish\n");
 }
 
-/**
- * Use this in the event that you have a FLASH part instead of an IDE drive.
- * Run after VSA init to enable the flash PCI device header.
- */
-static void enable_ide_nand_flash_header(void)
-{
-	/* Tell VSA to use FLASH PCI header. Not IDE header. */
-	hide_vpci(0x800079C4);
-}
-
 #define RTC_CENTURY	0x32
 #define RTC_DOMA	0x3D
 #define RTC_MONA	0x3E
@@ -601,8 +606,8 @@ void chipsetinit(void)
 #define IDE_ETC	  0x50
 
 /**
- * Enabled the IDE. This is code that is optionally run if the ide_enable is set
- * in the mainboard dts. 
+ * Enables the IDE. This is code that is run if there is an ide device in the mainboard
+ * device tree and it has set non-zero "enable_ide".
  * 
  * @param dev The device 
  */
@@ -658,11 +663,6 @@ static void southbridge_init(struct device *dev)
 		printk(BIOS_SPEW, "cs5536: done second call vr_write\n");
 	}
 
-	printk(BIOS_ERR, "cs5536: %s: enable_ide_nand_flash is %d\n",
-	       __FUNCTION__, sb->enable_ide_nand_flash);
-	if (sb->enable_ide_nand_flash != 0)
-		enable_ide_nand_flash_header();
-
 	enable_USB_port4(sb);
 
 	/* disable unwanted virtual PCI devices */
@@ -733,3 +733,16 @@ struct device_operations cs5536_ide = {
 	.ops_pci		 = &pci_dev_ops_pci,
 };
 
+struct device_operations cs5536_nand = {
+	.id = {.type = DEVICE_ID_PCI,
+		{.pci = {.vendor = PCI_VENDOR_ID_AMD,
+			 .device = PCI_DEVICE_ID_AMD_CS5536_FLASH}}},
+	.constructor		 = default_device_constructor,
+	.phase2_fixup		 = nand_phase2,
+	.phase3_scan		 = 0,
+	.phase4_read_resources	 = pci_dev_read_resources,
+	.phase4_set_resources	 = pci_set_resources,
+	.phase5_enable_resources = pci_dev_enable_resources,
+	.phase6_init		 = 0, /* No Option ROMs */
+	.ops_pci		 = &pci_dev_ops_pci,
+};
diff --git a/southbridge/amd/cs5536/nand b/southbridge/amd/cs5536/nand
new file mode 100644
index 0000000..69f4fa4
--- /dev/null
+++ b/southbridge/amd/cs5536/nand
@@ -0,0 +1,23 @@
+/*
+ * This file is part of the coreboot project.
+ *
+ * Copyright (C) 2009 Mart Raudsepp <mart.raudsepp at artecdesign.ee>
+ *
+ * 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
+ */
+
+{
+	device_operations = "cs5536_nand";
+};
-- 
1.6.0.4




From mart.raudsepp at artecdesign.ee  Fri Jan  9 13:21:47 2009
From: mart.raudsepp at artecdesign.ee (Mart Raudsepp)
Date: Fri, 09 Jan 2009 14:21:47 +0200
Subject: [coreboot] [PATCH 2/2] cs5536: Remove redundant enable_ide variable
 from ide device.
Message-ID: <1231503707.4558.10.camel@martr-gentoo.artec>

cs5536: Remove redundant enable_ide variable from ide device.

The device infrastructure already has an enabled bit, so we don't need to duplicate it in the current form.
cs5536.c:ide_init() is phase6_init, which is called only if the device is enabled, so if the device doesn't
exist, or the mainboard dts says "disabled;" for it, the init is not done and an extra conditional is not
necessary.
Adapt all cs5536 using mainboards to it (removing enable_ide variable) - artecgroup/dbe6[12] gets the whole
IDE device removed, which results in the ide_init() code not being ran as before (before it was called but
early return from enable_ide == 0, now it won't be called in the first place).

Signed-off-by: Mart Raudsepp <mart.raudsepp at artecdesign.ee>
---
 mainboard/adl/msm800sev/dts     |    1 -
 mainboard/amd/db800/dts         |    1 -
 mainboard/amd/norwich/dts       |    1 -
 mainboard/amp/tinygx/dts        |    1 -
 mainboard/artecgroup/dbe61/dts  |    3 ---
 mainboard/artecgroup/dbe62/dts  |    3 ---
 mainboard/pcengines/alix1c/dts  |    1 -
 mainboard/pcengines/alix2c3/dts |    1 -
 southbridge/amd/cs5536/cs5536.c |    7 +------
 southbridge/amd/cs5536/ide      |    3 ---
 10 files changed, 1 insertions(+), 21 deletions(-)

diff --git a/mainboard/adl/msm800sev/dts b/mainboard/adl/msm800sev/dts
index 46a2169..12e27a5 100644
--- a/mainboard/adl/msm800sev/dts
+++ b/mainboard/adl/msm800sev/dts
@@ -39,7 +39,6 @@
 		};
 		pci at f,2 {
 			/config/("southbridge/amd/cs5536/ide");
-			enable_ide = "1";
 		};
 		ioport at 2e {
 			/config/("superio/winbond/w83627hf/dts");
diff --git a/mainboard/amd/db800/dts b/mainboard/amd/db800/dts
index dd44487..75da7de 100644
--- a/mainboard/amd/db800/dts
+++ b/mainboard/amd/db800/dts
@@ -54,7 +54,6 @@
 		};
 		pci at f,2 {
 			/config/("southbridge/amd/cs5536/ide");
-			enable_ide = "1";
 		};
 		ioport at 2e {
 			/config/("superio/winbond/w83627hf/dts");
diff --git a/mainboard/amd/norwich/dts b/mainboard/amd/norwich/dts
index 6444e9d..ea7f9c0 100644
--- a/mainboard/amd/norwich/dts
+++ b/mainboard/amd/norwich/dts
@@ -57,7 +57,6 @@
 		};
 		pci at f,2 {
 			/config/("southbridge/amd/cs5536/ide");
-			enable_ide = "1";
 		};
 	};
 };
diff --git a/mainboard/amp/tinygx/dts b/mainboard/amp/tinygx/dts
index 95f3722..75a93b0 100644
--- a/mainboard/amp/tinygx/dts
+++ b/mainboard/amp/tinygx/dts
@@ -54,7 +54,6 @@
 		};
 		pci at f,2 {
 			/config/("southbridge/amd/cs5536/ide");
-			enable_ide = "1";
 		};
 		ioport at 2e {
 			/config/("superio/ite/it8716f/dts");
diff --git a/mainboard/artecgroup/dbe61/dts b/mainboard/artecgroup/dbe61/dts
index 48df288..a6995ce 100644
--- a/mainboard/artecgroup/dbe61/dts
+++ b/mainboard/artecgroup/dbe61/dts
@@ -112,8 +112,5 @@ end
 		pci at f,1 {
 			/config/("southbridge/amd/cs5536/nand");
 		};
-		pci at f,2 {
-			/config/("southbridge/amd/cs5536/ide");
-		};
 	};
 };
diff --git a/mainboard/artecgroup/dbe62/dts b/mainboard/artecgroup/dbe62/dts
index 3cbe0ff..8089e79 100644
--- a/mainboard/artecgroup/dbe62/dts
+++ b/mainboard/artecgroup/dbe62/dts
@@ -66,8 +66,5 @@
 		pci at f,1 {
 			/config/("southbridge/amd/cs5536/nand");
 		};
-		pci at f,2 {
-			/config/("southbridge/amd/cs5536/ide");
-		};
 	};
 };
diff --git a/mainboard/pcengines/alix1c/dts b/mainboard/pcengines/alix1c/dts
index 724a74f..2f3d767 100644
--- a/mainboard/pcengines/alix1c/dts
+++ b/mainboard/pcengines/alix1c/dts
@@ -51,7 +51,6 @@
 		};
 		pci at f,2 {
 			/config/("southbridge/amd/cs5536/ide");
-			enable_ide = "1";
 		};
 		ioport at 2e {
 			/config/("superio/winbond/w83627hf/dts");
diff --git a/mainboard/pcengines/alix2c3/dts b/mainboard/pcengines/alix2c3/dts
index c1b4d31..30390b5 100644
--- a/mainboard/pcengines/alix2c3/dts
+++ b/mainboard/pcengines/alix2c3/dts
@@ -51,7 +51,6 @@
 		};
 		pci at f,2 {
 			/config/("southbridge/amd/cs5536/ide");
-			enable_ide = "1";
 		};
 	};
 };
diff --git a/southbridge/amd/cs5536/cs5536.c b/southbridge/amd/cs5536/cs5536.c
index 0c5adb1..4374a0a 100644
--- a/southbridge/amd/cs5536/cs5536.c
+++ b/southbridge/amd/cs5536/cs5536.c
@@ -607,7 +607,7 @@ void chipsetinit(void)
 
 /**
  * Enables the IDE. This is code that is run if there is an ide device in the mainboard
- * device tree and it has set non-zero "enable_ide".
+ * device tree.
  * 
  * @param dev The device 
  */
@@ -615,11 +615,6 @@ static void ide_init(struct device *dev)
 {
 	u32 ide_cfg;
 
-	struct southbridge_amd_cs5536_ide_config *ide =
-	    (struct southbridge_amd_cs5536_ide_config *)dev->device_configuration;
-	if (!ide->enable_ide)
-		return;
-
 	printk(BIOS_DEBUG, "cs5536_ide: %s\n", __func__);
 	/* GPIO and IRQ setup are handled in the main chipset code. */
 
diff --git a/southbridge/amd/cs5536/ide b/southbridge/amd/cs5536/ide
index 42c9d5f..6cc8e2e 100644
--- a/southbridge/amd/cs5536/ide
+++ b/southbridge/amd/cs5536/ide
@@ -20,7 +20,4 @@
 
 {
 	device_operations = "cs5536_ide";
-
-	/* IDE: enable CS5536 IDE. There may be a different IDE controller on board */
-	enable_ide = "0";
 };
-- 
1.6.0.4




From patrick at georgi-clan.de  Fri Jan  9 14:41:55 2009
From: patrick at georgi-clan.de (Patrick Georgi)
Date: Fri, 9 Jan 2009 14:41:55 +0100
Subject: [coreboot] [PATCH]coreboot-v2: ignore some more sections
Message-ID: <200901091441.55536.patrick@georgi-clan.de>

Hi,

after I updated my SuSE system, coreboot.strip grew to 4GB. Seems 
like they introduced some new notes sections that got in the way.
Attached patch ignores them, too.

It should be trivial, but I'd rather have some confirmation.


Regards,
Patrick Georgi
-------------- next part --------------
A non-text attachment was scrubbed...
Name: ldscripts-too-many-notes.diff
Type: text/x-patch
Size: 1093 bytes
Desc: not available
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20090109/fe0793ee/attachment.diff>

From svn at coreboot.org  Fri Jan  9 15:17:09 2009
From: svn at coreboot.org (svn at coreboot.org)
Date: Fri,  9 Jan 2009 15:17:09 +0100
Subject: [coreboot] r1112 - coreboot-v3/device
Message-ID: <mailman.2656.1355071468.16123.coreboot@coreboot.org>

Author: myles
Date: 2009-01-09 15:17:06 +0100 (Fri, 09 Jan 2009)
New Revision: 1112

Modified:
   coreboot-v3/device/device.c
Log:
This patch adds the domain's resources and all links to the tree traversal for
constraining resources.  Build and boot tested on qemu, serengeti, and
alix2c3.

Signed-off-by: Myles Watson <mylesgw at gmail.com>
Acked-by: Ward Vandewege <ward at gnu.org>


Modified: coreboot-v3/device/device.c
===================================================================
--- coreboot-v3/device/device.c	2009-01-08 20:07:21 UTC (rev 1111)
+++ coreboot-v3/device/device.c	2009-01-09 14:17:06 UTC (rev 1112)
@@ -705,41 +705,42 @@
 #define MEM_TYPE (IORESOURCE_MEM)
 #define IO_TYPE (IORESOURCE_IO)
 
-	/* Descend into every child and look for fixed resources. */
-	for (child=dev->link[0].children; child; child = child->sibling) {
-		constrain_resources(child, limits);
-		for (i = 0; i<child->resources; i++) {
-			res = &child->resource[i];
-			if (!(res->flags & IORESOURCE_FIXED))
-				continue;
+	/* Constrain limits based on the fixed resources of this device. */
+	for (i = 0; i<dev->resources; i++) {
+		res = &dev->resource[i];
+		if (!(res->flags & IORESOURCE_FIXED))
+			continue;
 
-			/* PREFETCH, MEM, or I/O - skip any others. */
-			if ((res->flags & MEM_MASK) == PREF_TYPE)
-				lim = &limits->pref;
-			else if ((res->flags & MEM_MASK) == MEM_TYPE)
-				lim = &limits->mem;
-			else if ((res->flags & IO_MASK) == IO_TYPE)
-				lim = &limits->io;
-			else
-				continue;
+		/* PREFETCH, MEM, or I/O - skip any others. */
+		if ((res->flags & MEM_MASK) == PREF_TYPE)
+			lim = &limits->pref;
+		else if ((res->flags & MEM_MASK) == MEM_TYPE)
+			lim = &limits->mem;
+		else if ((res->flags & IO_MASK) == IO_TYPE)
+			lim = &limits->io;
+		else
+			continue;
 
-			/* Is it already outside the limits? */
-			if (res->size &&
-			    (((res->base + res->size -1) < lim->base) ||
-			     (res->base > lim->limit)))
-				continue;
+		/* Is it already outside the limits? */
+		if (res->size && (((res->base + res->size -1) < lim->base) ||
+				  (res->base > lim->limit)))
+			continue;
 
-			/* Choose to be above or below fixed resources.  This
-			 * check is signed so that "negative" amounts of space
-			 * are handled correctly.
-			 */
-			if ((s64)(lim->limit - (res->base + res->size -1)) >
-			    (s64)(res->base - lim->base))
-				lim->base = res->base + res->size;
-			else
-				lim->limit = res->base -1;
-		}
+		/* Choose to be above or below fixed resources.  This
+		 * check is signed so that "negative" amounts of space
+		 * are handled correctly.
+		 */
+		if ((s64)(lim->limit - (res->base + res->size -1)) >
+		    (s64)(res->base - lim->base))
+			lim->base = res->base + res->size;
+		else
+			lim->limit = res->base -1;
 	}
+
+	/* Descend into every child and look for fixed resources. */
+	for (i = 0; i< dev->links; i++)
+		for (child=dev->link[i].children; child; child = child->sibling)
+			constrain_resources(child, limits);
 }
 
 static void avoid_fixed_resources(struct device *dev)




From mylesgw at gmail.com  Fri Jan  9 15:18:55 2009
From: mylesgw at gmail.com (Myles Watson)
Date: Fri, 9 Jan 2009 07:18:55 -0700
Subject: [coreboot] domain vs device statictree order
In-Reply-To: <20090109005256.GA14466@localdomain>
References: <2831fecf0901072039r52c14481j8e7da3d4ccee7850@mail.gmail.com>
	<20090108135806.GA20056@localdomain>
	<2831fecf0901080752p49b3621dj2c073588f8d119c5@mail.gmail.com>
	<20090108180054.GA28851@localdomain>
	<2831fecf0901081027r2cec5378lb594f2d8179f0f7c@mail.gmail.com>
	<534e5dc20901081035g1e5953e8o50046a7fd4fb9c96@mail.gmail.com>
	<2831fecf0901081207t46f41a87hf42fc84f4b3cb4f0@mail.gmail.com>
	<20090108201758.GA3534@localdomain>
	<2831fecf0901081257q1bfbc7f3m6e16a737456f6a3b@mail.gmail.com>
	<2831fecf0901081257k4a6cf197i3a4ff89b3fb8d2df@mail.gmail.com>
	<20090109005256.GA14466@localdomain>
Message-ID: <4BBE517617F84EAC9485216A51A370C3@chimp>



> On Thu, Jan 08, 2009 at 01:57:39PM -0700, Myles Watson wrote:
> > And the patch :)
> 
> Yay, that fixes booting (log attached).

Whew!

> > > Signed-off-by: Myles Watson <mylesgw at gmail.com>
> 
> Acked-by: Ward Vandewege <ward at gnu.org>

Rev 1112.

Thanks,
Myles




From peter at stuge.se  Fri Jan  9 15:19:02 2009
From: peter at stuge.se (Peter Stuge)
Date: Fri, 9 Jan 2009 15:19:02 +0100
Subject: [coreboot] Question about dual operating systems
In-Reply-To: <BAY117-DS78FBEC49CA68AC843A41CB7DD0@phx.gbl>
References: <BAY117-DS78FBEC49CA68AC843A41CB7DD0@phx.gbl>
Message-ID: <20090109141902.31509.qmail@stuge.se>

Matt Johnson wrote:
> I was wondering, let's say I install linux using Wubi (so it isn't
> a separate partition)  and want to use coreboot to boot to linux.
> Will cause problems?

coreboot doesn't care, but the bootloader payload has to be able to
access the kernel and root filesystem which are on the Windows
partition.

That leaves you fewer choices for the payload but is by no means
impossible. You'll need to use Linux as payload and either have it
kexec the "real" kernel or possibly it can mount the root directly.
In either case you'll need a custom-made initramfs or initrd as
"glue" between the payload kernel and the stuff on the Windows drive.

This is why I think Linux as payload is so awesome; if you can access
a filesystem when Linux is running, you can always boot from that
filesystem because with coreboot you can be using Linux as the
bootloader.

(Of course some small details need to check out; your board has to be
supported by coreboot, and the flash chip has to be big enough to fit
coreboot+Linux. The flash chip can usually be upgraded though.)


//Peter



From mylesgw at gmail.com  Fri Jan  9 15:22:23 2009
From: mylesgw at gmail.com (Myles Watson)
Date: Fri, 9 Jan 2009 07:22:23 -0700
Subject: [coreboot] domain vs device statictree order
In-Reply-To: <1231496427.4558.6.camel@martr-gentoo.artec>
References: <2831fecf0901071027t461c3c54rf8fd0b54112b5238@mail.gmail.com><20090108135806.GA20056@localdomain><2831fecf0901080752p49b3621dj2c073588f8d119c5@mail.gmail.com><20090108180054.GA28851@localdomain><2831fecf0901081027r2cec5378lb594f2d8179f0f7c@mail.gmail.com><534e5dc20901081035g1e5953e8o50046a7fd4fb9c96@mail.gmail.com><2831fecf0901081207t46f41a87hf42fc84f4b3cb4f0@mail.gmail.com><20090108201758.GA3534@localdomain><534e5dc20901081316r5ef154efoca4a09e3e9262110@mail.gmail.com><034861328A344F45BDBB18716024910E@chimp><534e5dc20901081712l15e88c7eg205adb0fc76c4e0b@mail.gmail.com>
	<1231496427.4558.6.camel@martr-gentoo.artec>
Message-ID: <F7906484EA2F478BA5AA8FD3BE3B7666@chimp>



> -----Original Message-----
> From: coreboot-bounces at coreboot.org [mailto:coreboot-bounces at coreboot.org]
> On Behalf Of Mart Raudsepp

> Also, what if we had the possibility to run code for disabled devices -
> then the vpci hiding could cleanly happen when the device is disabled
> instead of checks from northbridge code. Like a .disable functor in
> device_ops?

We do.  If you run it in phase2 it runs independent of the enabled flag, and
could use that to do any disabling that was needed.  It's a little confusing
to put the device in the tree then, though, because it will never show up in
lspci.

Thanks,
Myles




From peter at stuge.se  Fri Jan  9 15:29:41 2009
From: peter at stuge.se (Peter Stuge)
Date: Fri, 9 Jan 2009 15:29:41 +0100
Subject: [coreboot] [PATCH 1/2] cs5536: Add a NAND device and do the IDE
	PCI header disabling on time.
In-Reply-To: <1231503657.4558.9.camel@martr-gentoo.artec>
References: <1231503657.4558.9.camel@martr-gentoo.artec>
Message-ID: <20090109142941.1606.qmail@stuge.se>

Mart Raudsepp wrote:
> cs5536: Add a NAND device and do the IDE PCI header disabling on time.
> 
> This implements a nand device, akin to the ide device to follow the coreboot-v3 device tree design better.
> It allows us to do the IDE PCI header early enough in a clean way - the hide_vpci was called way too late
> before - in phase6 of southbridge device, but we need the Flash header active instead of IDE in the VSA2
> before bus scans happen, or the PCI device gets disabled in coreboot understanding by the time we get it
> enabled in VSA2.
> It makes NAND setup work better, but still not completely. There is a VSA2 bug for which I made a patch,
> but waiting on a new binary to test if after that everything works or not. A quick hack to workaround the
> VSA2 bug suggests something further will still need fixing. There are also more potential opportunities
> to shuffle NAND code around to match v3 approach better, but that's a next step for me after NAND setup
> actually works right in the current form.
> 
> Also corrected the documentation of ide_init() to match current reality.
> 
> Signed-off-by: Mart Raudsepp <mart.raudsepp at artecdesign.ee>

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



From peter at stuge.se  Fri Jan  9 15:32:13 2009
From: peter at stuge.se (Peter Stuge)
Date: Fri, 9 Jan 2009 15:32:13 +0100
Subject: [coreboot] [PATCH 2/2] cs5536: Remove redundant enable_ide
	variable from ide device.
In-Reply-To: <1231503707.4558.10.camel@martr-gentoo.artec>
References: <1231503707.4558.10.camel@martr-gentoo.artec>
Message-ID: <20090109143213.2246.qmail@stuge.se>

Mart Raudsepp wrote:
> cs5536: Remove redundant enable_ide variable from ide device.

Patch itself is clean, but I don't know if it is desirable to change
the behavior this way. I could ack but I am not 100% sure about the
disabling/enabling stuff - I remember a lot of discussion about it
but I don't remember the outcome. :\

Will a dts expert please chime in?


//Peter



From mylesgw at gmail.com  Fri Jan  9 15:33:37 2009
From: mylesgw at gmail.com (Myles Watson)
Date: Fri, 9 Jan 2009 07:33:37 -0700
Subject: [coreboot] [PATCH 1/2] cs5536: Add a NAND device and do the IDE
	PCI header disabling on time.
In-Reply-To: <1231503657.4558.9.camel@martr-gentoo.artec>
References: <1231503657.4558.9.camel@martr-gentoo.artec>
Message-ID: <EC244EE6BC7E4B398B3D66256B62A7F0@chimp>



> -----Original Message-----
> From: coreboot-bounces+mylesgw=gmail.com at coreboot.org [mailto:coreboot-
> bounces+mylesgw=gmail.com at coreboot.org] On Behalf Of Mart Raudsepp
> Sent: Friday, January 09, 2009 5:21 AM
> To: coreboot at coreboot.org
> Subject: [coreboot] [PATCH 1/2] cs5536: Add a NAND device and do the IDE
> PCI header disabling on time.
> 
> cs5536: Add a NAND device and do the IDE PCI header disabling on time.
> 
> This implements a nand device, akin to the ide device to follow the
> coreboot-v3 device tree design better.
> It allows us to do the IDE PCI header early enough in a clean way - the
> hide_vpci was called way too late
> before - in phase6 of southbridge device, but we need the Flash header
> active instead of IDE in the VSA2
> before bus scans happen, or the PCI device gets disabled in coreboot
> understanding by the time we get it
> enabled in VSA2.
> It makes NAND setup work better, but still not completely. There is a VSA2
> bug for which I made a patch,
> but waiting on a new binary to test if after that everything works or not.
> A quick hack to workaround the
> VSA2 bug suggests something further will still need fixing. There are also
> more potential opportunities
> to shuffle NAND code around to match v3 approach better, but that's a next
> step for me after NAND setup
> actually works right in the current form.
> 
> Also corrected the documentation of ide_init() to match current reality.
> 
> Signed-off-by: Mart Raudsepp <mart.raudsepp at artecdesign.ee>
> ---
>  mainboard/artecgroup/dbe61/dts  |    3 ++
>  mainboard/artecgroup/dbe62/dts  |    3 ++
>  southbridge/amd/cs5536/cs5536.c |   47 ++++++++++++++++++++++++----------
> ----
>  southbridge/amd/cs5536/nand     |   23 +++++++++++++++++++
>  4 files changed, 59 insertions(+), 17 deletions(-)
>  create mode 100644 southbridge/amd/cs5536/nand
> 
> diff --git a/mainboard/artecgroup/dbe61/dts
> b/mainboard/artecgroup/dbe61/dts
> index b443533..48df288 100644
> --- a/mainboard/artecgroup/dbe61/dts
> +++ b/mainboard/artecgroup/dbe61/dts
> @@ -109,6 +109,9 @@ end
>  			/* USB Port Power Handling setting. */
>  			pph = "0xf5";
>  		};
> +		pci at f,1 {
> +			/config/("southbridge/amd/cs5536/nand");
> +		};
>  		pci at f,2 {
>  			/config/("southbridge/amd/cs5536/ide");
>  		};

Shouldn't you remove the ide device if it's going to be hidden?

> diff --git a/mainboard/artecgroup/dbe62/dts
> b/mainboard/artecgroup/dbe62/dts
> index 213c397..3cbe0ff 100644
> --- a/mainboard/artecgroup/dbe62/dts
> +++ b/mainboard/artecgroup/dbe62/dts
> @@ -63,6 +63,9 @@
>  			/* USB Port Power Handling setting. */
>  			pph = "0xf5";
>  		};
> +		pci at f,1 {
> +			/config/("southbridge/amd/cs5536/nand");
> +		};
>  		pci at f,2 {
>  			/config/("southbridge/amd/cs5536/ide");
>  		};

Same thing here.

Maybe it would be better to have IDE/NAND selection depend on a CMOS/NVRAM
value, so that the same BIOS could be used with either choice.

Could we make an ide_or_nand device that called your nand_phase2 if it was
nand, and used the ide_init if it wasn't.  They seem so similar, and only
one is allowed at a time.

Thanks,
Myles




From peter at stuge.se  Fri Jan  9 15:36:07 2009
From: peter at stuge.se (Peter Stuge)
Date: Fri, 9 Jan 2009 15:36:07 +0100
Subject: [coreboot] [PATCH 1/2] cs5536: Add a NAND device and do the IDE
	PCI header disabling on time.
In-Reply-To: <EC244EE6BC7E4B398B3D66256B62A7F0@chimp>
References: <1231503657.4558.9.camel@martr-gentoo.artec>
	<EC244EE6BC7E4B398B3D66256B62A7F0@chimp>
Message-ID: <20090109143607.3317.qmail@stuge.se>

Myles Watson wrote:
> Could we make an ide_or_nand device that called your nand_phase2 if
> it was nand, and used the ide_init if it wasn't.  They seem so
> similar, and only one is allowed at a time.

I'm not sure I like that because they always have different PCI ids..


//Peter



From mart.raudsepp at artecdesign.ee  Fri Jan  9 15:36:56 2009
From: mart.raudsepp at artecdesign.ee (Mart Raudsepp)
Date: Fri, 09 Jan 2009 16:36:56 +0200
Subject: [coreboot] domain vs device statictree order
In-Reply-To: <F7906484EA2F478BA5AA8FD3BE3B7666@chimp>
References: <2831fecf0901071027t461c3c54rf8fd0b54112b5238@mail.gmail.com>
	<20090108135806.GA20056@localdomain>
	<2831fecf0901080752p49b3621dj2c073588f8d119c5@mail.gmail.com>
	<20090108180054.GA28851@localdomain>
	<2831fecf0901081027r2cec5378lb594f2d8179f0f7c@mail.gmail.com>
	<534e5dc20901081035g1e5953e8o50046a7fd4fb9c96@mail.gmail.com>
	<2831fecf0901081207t46f41a87hf42fc84f4b3cb4f0@mail.gmail.com>
	<20090108201758.GA3534@localdomain>
	<534e5dc20901081316r5ef154efoca4a09e3e9262110@mail.gmail.com>
	<034861328A344F45BDBB18716024910E@chimp>
	<534e5dc20901081712l15e88c7eg205adb0fc76c4e0b@mail.gmail.com>
	<1231496427.4558.6.camel@martr-gentoo.artec>
	<F7906484EA2F478BA5AA8FD3BE3B7666@chimp>
Message-ID: <1231511816.4558.14.camel@martr-gentoo.artec>

?hel kenal p?eval, R, 2009-01-09 kell 07:22, kirjutas Myles Watson:
> 
> > -----Original Message-----
> > From: coreboot-bounces at coreboot.org [mailto:coreboot-bounces at coreboot.org]
> > On Behalf Of Mart Raudsepp
> 
> > Also, what if we had the possibility to run code for disabled devices -
> > then the vpci hiding could cleanly happen when the device is disabled
> > instead of checks from northbridge code. Like a .disable functor in
> > device_ops?
> 
> We do.  If you run it in phase2 it runs independent of the enabled flag, and
> could use that to do any disabling that was needed.  It's a little confusing
> to put the device in the tree then, though, because it will never show up in
> lspci.


I guess I mean a way to run disabling code if a device doesn't appear in
the mainboard dts at all. E.g, there is a
northbridge/amd/geodelx/graphics.dts and if the mainboard dts doesn't
source it or it's disabled, a disabling function would be ran. This is
just something that optionally wired built-in PCI devices might be
interested in, not the typical case of PCI slots.

I can imagine it would get tricky to implement and quite likely it's
just a bad idea.


Mart Raudsepp




From mart.raudsepp at artecdesign.ee  Fri Jan  9 15:41:24 2009
From: mart.raudsepp at artecdesign.ee (Mart Raudsepp)
Date: Fri, 09 Jan 2009 16:41:24 +0200
Subject: [coreboot] [PATCH 1/2] cs5536: Add a NAND device and do the IDE
 PCI header disabling on time.
In-Reply-To: <EC244EE6BC7E4B398B3D66256B62A7F0@chimp>
References: <1231503657.4558.9.camel@martr-gentoo.artec>
	<EC244EE6BC7E4B398B3D66256B62A7F0@chimp>
Message-ID: <1231512084.4558.18.camel@martr-gentoo.artec>

?hel kenal p?eval, R, 2009-01-09 kell 07:33, kirjutas Myles Watson:
> 
> > -----Original Message-----
> > From: coreboot-bounces+mylesgw=gmail.com at coreboot.org [mailto:coreboot-
> > bounces+mylesgw=gmail.com at coreboot.org] On Behalf Of Mart Raudsepp
> > Sent: Friday, January 09, 2009 5:21 AM
> > To: coreboot at coreboot.org
> > Subject: [coreboot] [PATCH 1/2] cs5536: Add a NAND device and do the IDE
> > PCI header disabling on time.
> > 
> > cs5536: Add a NAND device and do the IDE PCI header disabling on time.
> > 
> > This implements a nand device, akin to the ide device to follow the
> > coreboot-v3 device tree design better.
> > It allows us to do the IDE PCI header early enough in a clean way - the
> > hide_vpci was called way too late
> > before - in phase6 of southbridge device, but we need the Flash header
> > active instead of IDE in the VSA2
> > before bus scans happen, or the PCI device gets disabled in coreboot
> > understanding by the time we get it
> > enabled in VSA2.
> > It makes NAND setup work better, but still not completely. There is a VSA2
> > bug for which I made a patch,
> > but waiting on a new binary to test if after that everything works or not.
> > A quick hack to workaround the
> > VSA2 bug suggests something further will still need fixing. There are also
> > more potential opportunities
> > to shuffle NAND code around to match v3 approach better, but that's a next
> > step for me after NAND setup
> > actually works right in the current form.
> > 
> > Also corrected the documentation of ide_init() to match current reality.
> > 
> > Signed-off-by: Mart Raudsepp <mart.raudsepp at artecdesign.ee>
> > ---
> >  mainboard/artecgroup/dbe61/dts  |    3 ++
> >  mainboard/artecgroup/dbe62/dts  |    3 ++
> >  southbridge/amd/cs5536/cs5536.c |   47 ++++++++++++++++++++++++----------
> > ----
> >  southbridge/amd/cs5536/nand     |   23 +++++++++++++++++++
> >  4 files changed, 59 insertions(+), 17 deletions(-)
> >  create mode 100644 southbridge/amd/cs5536/nand
> > 
> > diff --git a/mainboard/artecgroup/dbe61/dts
> > b/mainboard/artecgroup/dbe61/dts
> > index b443533..48df288 100644
> > --- a/mainboard/artecgroup/dbe61/dts
> > +++ b/mainboard/artecgroup/dbe61/dts
> > @@ -109,6 +109,9 @@ end
> >  			/* USB Port Power Handling setting. */
> >  			pph = "0xf5";
> >  		};
> > +		pci at f,1 {
> > +			/config/("southbridge/amd/cs5536/nand");
> > +		};
> >  		pci at f,2 {
> >  			/config/("southbridge/amd/cs5536/ide");
> >  		};
> 
> Shouldn't you remove the ide device if it's going to be hidden?

With this patch there is still an enable_ide that has a default of zero
via southbridge/amd/cs5536/ide. The 2/2 patch does the enable_ide
killing and removal of this entry as you suggest.

> > diff --git a/mainboard/artecgroup/dbe62/dts
> > b/mainboard/artecgroup/dbe62/dts
> > index 213c397..3cbe0ff 100644
> > --- a/mainboard/artecgroup/dbe62/dts
> > +++ b/mainboard/artecgroup/dbe62/dts
> > @@ -63,6 +63,9 @@
> >  			/* USB Port Power Handling setting. */
> >  			pph = "0xf5";
> >  		};
> > +		pci at f,1 {
> > +			/config/("southbridge/amd/cs5536/nand");
> > +		};
> >  		pci at f,2 {
> >  			/config/("southbridge/amd/cs5536/ide");
> >  		};
> 
> Same thing here.

And same reply :)

> Maybe it would be better to have IDE/NAND selection depend on a CMOS/NVRAM
> value, so that the same BIOS could be used with either choice.

The board doesn't have IDE stuff wired anywhere. No existing boards
supported by coreboot do to my knowledge. I'm thinking that if a board
appears that wants to do it, we'd have both devices in the dts and have
the mainboard (or NVRAM handler) specific code disable one of them
before phase2 of devices with dev_set_enabled(dev, 0)

> Could we make an ide_or_nand device that called your nand_phase2 if it was
> nand, and used the ide_init if it wasn't.  They seem so similar, and only
> one is allowed at a time.

How do we get pci at f,1 in case of Flash and pci at f,2 in case of IDE then
if there is an ide_or_nand device?


Mart Raudsepp




From mylesgw at gmail.com  Fri Jan  9 15:42:51 2009
From: mylesgw at gmail.com (Myles Watson)
Date: Fri, 9 Jan 2009 07:42:51 -0700
Subject: [coreboot] [PATCH 1/2] cs5536: Add a NAND device and do the
	IDEPCI header disabling on time.
In-Reply-To: <20090109143607.3317.qmail@stuge.se>
References: <1231503657.4558.9.camel@martr-gentoo.artec><EC244EE6BC7E4B398B3D66256B62A7F0@chimp>
	<20090109143607.3317.qmail@stuge.se>
Message-ID: <5891387B853A4E349BEA394D52293E9F@chimp>



> -----Original Message-----
> From: coreboot-bounces+mylesgw=gmail.com at coreboot.org [mailto:coreboot-
> bounces+mylesgw=gmail.com at coreboot.org] On Behalf Of Peter Stuge
> Sent: Friday, January 09, 2009 7:36 AM
> To: coreboot at coreboot.org
> Subject: Re: [coreboot] [PATCH 1/2] cs5536: Add a NAND device and do the
> IDEPCI header disabling on time.
> 
> Myles Watson wrote:
> > Could we make an ide_or_nand device that called your nand_phase2 if
> > it was nand, and used the ide_init if it wasn't.  They seem so
> > similar, and only one is allowed at a time.
> 
> I'm not sure I like that because they always have different PCI ids..

Good catch.  You're right.

Thanks,
Myles





From mart.raudsepp at artecdesign.ee  Fri Jan  9 15:45:05 2009
From: mart.raudsepp at artecdesign.ee (Mart Raudsepp)
Date: Fri, 09 Jan 2009 16:45:05 +0200
Subject: [coreboot] [PATCH 2/2] cs5536: Remove redundant enable_ide
 variable from ide device.
In-Reply-To: <20090109143213.2246.qmail@stuge.se>
References: <1231503707.4558.10.camel@martr-gentoo.artec>
	<20090109143213.2246.qmail@stuge.se>
Message-ID: <1231512305.4558.21.camel@martr-gentoo.artec>

?hel kenal p?eval, R, 2009-01-09 kell 15:32, kirjutas Peter Stuge:
> Mart Raudsepp wrote:
> > cs5536: Remove redundant enable_ide variable from ide device.
> 
> Patch itself is clean, but I don't know if it is desirable to change
> the behavior this way. I could ack but I am not 100% sure about the
> disabling/enabling stuff - I remember a lot of discussion about it
> but I don't remember the outcome. :\

The controversial part is about such a variable in the southbridge
parent device that would select ide or nand. E.g what
sb->enable_ide_nand_flash kind of is right now - zero means IDE and
non-zero means Flash in a given chip select. I haven't gotten around to
investigating if that chip select and its setup can be moved to the
newly created NAND device or not - once I do that "controversy" will
arise.
The ide->enable_ide statictree struct member that this patch kills just
duplicates existing ide->enabled struct member.

> Will a dts expert please chime in?

That'd be appreciated


Mart Raudsepp




From ward at gnu.org  Fri Jan  9 15:46:03 2009
From: ward at gnu.org (Ward Vandewege)
Date: Fri, 9 Jan 2009 09:46:03 -0500
Subject: [coreboot] [PATCH 1/2] cs5536: Add a NAND device and do the	IDE
	PCI header disabling on time.
In-Reply-To: <EC244EE6BC7E4B398B3D66256B62A7F0@chimp>
References: <1231503657.4558.9.camel@martr-gentoo.artec>
	<EC244EE6BC7E4B398B3D66256B62A7F0@chimp>
Message-ID: <20090109144603.GA16760@localdomain>

On Fri, Jan 09, 2009 at 07:33:37AM -0700, Myles Watson wrote:
> Maybe it would be better to have IDE/NAND selection depend on a CMOS/NVRAM
> value, so that the same BIOS could be used with either choice.

Will that work on boards without cmos battery (they exist - alix2c3 for
instance)?

Thanks,
Ward.

-- 
Ward Vandewege <ward at fsf.org>
Free Software Foundation - Senior Systems Administrator



From mylesgw at gmail.com  Fri Jan  9 15:45:58 2009
From: mylesgw at gmail.com (Myles Watson)
Date: Fri, 9 Jan 2009 07:45:58 -0700
Subject: [coreboot] [PATCH 1/2] cs5536: Add a NAND device and do the IDE
	PCI header disabling on time.
In-Reply-To: <1231512084.4558.18.camel@martr-gentoo.artec>
References: <1231503657.4558.9.camel@martr-gentoo.artec><EC244EE6BC7E4B398B3D66256B62A7F0@chimp>
	<1231512084.4558.18.camel@martr-gentoo.artec>
Message-ID: <D9D45FAC6BE04B748C4EEE818B248D8E@chimp>



> -----Original Message-----
> From: coreboot-bounces at coreboot.org [mailto:coreboot-bounces at coreboot.org]
> On Behalf Of Mart Raudsepp
> Sent: Friday, January 09, 2009 7:41 AM
> To: coreboot at coreboot.org
> Subject: Re: [coreboot] [PATCH 1/2] cs5536: Add a NAND device and do the
> IDE PCI header disabling on time.
> 
> ?hel kenal p?eval, R, 2009-01-09 kell 07:33, kirjutas Myles Watson:
> >
> > > -----Original Message-----
> > > From: coreboot-bounces+mylesgw=gmail.com at coreboot.org
> [mailto:coreboot-
> > > bounces+mylesgw=gmail.com at coreboot.org] On Behalf Of Mart Raudsepp
> > > Sent: Friday, January 09, 2009 5:21 AM
> > > To: coreboot at coreboot.org
> > > Subject: [coreboot] [PATCH 1/2] cs5536: Add a NAND device and do the
> IDE
> > > PCI header disabling on time.
> > >
> > > cs5536: Add a NAND device and do the IDE PCI header disabling on time.
> > >
> > > This implements a nand device, akin to the ide device to follow the
> > > coreboot-v3 device tree design better.
> > > It allows us to do the IDE PCI header early enough in a clean way -
> the
> > > hide_vpci was called way too late
> > > before - in phase6 of southbridge device, but we need the Flash header
> > > active instead of IDE in the VSA2
> > > before bus scans happen, or the PCI device gets disabled in coreboot
> > > understanding by the time we get it
> > > enabled in VSA2.
> > > It makes NAND setup work better, but still not completely. There is a
> VSA2
> > > bug for which I made a patch,
> > > but waiting on a new binary to test if after that everything works or
> not.
> > > A quick hack to workaround the
> > > VSA2 bug suggests something further will still need fixing. There are
> also
> > > more potential opportunities
> > > to shuffle NAND code around to match v3 approach better, but that's a
> next
> > > step for me after NAND setup
> > > actually works right in the current form.
> > >
> > > Also corrected the documentation of ide_init() to match current
> reality.
> > >
> > > Signed-off-by: Mart Raudsepp <mart.raudsepp at artecdesign.ee>
> > > ---
> > >  mainboard/artecgroup/dbe61/dts  |    3 ++
> > >  mainboard/artecgroup/dbe62/dts  |    3 ++
> > >  southbridge/amd/cs5536/cs5536.c |   47 ++++++++++++++++++++++++------
> ----
> > > ----
> > >  southbridge/amd/cs5536/nand     |   23 +++++++++++++++++++
> > >  4 files changed, 59 insertions(+), 17 deletions(-)
> > >  create mode 100644 southbridge/amd/cs5536/nand
> > >
> > > diff --git a/mainboard/artecgroup/dbe61/dts
> > > b/mainboard/artecgroup/dbe61/dts
> > > index b443533..48df288 100644
> > > --- a/mainboard/artecgroup/dbe61/dts
> > > +++ b/mainboard/artecgroup/dbe61/dts
> > > @@ -109,6 +109,9 @@ end
> > >  			/* USB Port Power Handling setting. */
> > >  			pph = "0xf5";
> > >  		};
> > > +		pci at f,1 {
> > > +			/config/("southbridge/amd/cs5536/nand");
> > > +		};
> > >  		pci at f,2 {
> > >  			/config/("southbridge/amd/cs5536/ide");
> > >  		};
> >
> > Shouldn't you remove the ide device if it's going to be hidden?
> 
> With this patch there is still an enable_ide that has a default of zero
> via southbridge/amd/cs5536/ide. The 2/2 patch does the enable_ide
> killing and removal of this entry as you suggest.
> 
> > > diff --git a/mainboard/artecgroup/dbe62/dts
> > > b/mainboard/artecgroup/dbe62/dts
> > > index 213c397..3cbe0ff 100644
> > > --- a/mainboard/artecgroup/dbe62/dts
> > > +++ b/mainboard/artecgroup/dbe62/dts
> > > @@ -63,6 +63,9 @@
> > >  			/* USB Port Power Handling setting. */
> > >  			pph = "0xf5";
> > >  		};
> > > +		pci at f,1 {
> > > +			/config/("southbridge/amd/cs5536/nand");
> > > +		};
> > >  		pci at f,2 {
> > >  			/config/("southbridge/amd/cs5536/ide");
> > >  		};
> >
> > Same thing here.
> 
> And same reply :)
> 
> > Maybe it would be better to have IDE/NAND selection depend on a
> CMOS/NVRAM
> > value, so that the same BIOS could be used with either choice.
> 
> The board doesn't have IDE stuff wired anywhere. No existing boards
> supported by coreboot do to my knowledge. I'm thinking that if a board
> appears that wants to do it, we'd have both devices in the dts and have
> the mainboard (or NVRAM handler) specific code disable one of them
> before phase2 of devices with dev_set_enabled(dev, 0)

That's the answer to the question I should have asked. :)  Thanks for the
clarification.

> > Could we make an ide_or_nand device that called your nand_phase2 if it
> was
> > nand, and used the ide_init if it wasn't.  They seem so similar, and
> only
> > one is allowed at a time.
> 
> How do we get pci at f,1 in case of Flash and pci at f,2 in case of IDE then
> if there is an ide_or_nand device?

Yes.  They were separate suggestions.

Thanks,
Myles




From peter at stuge.se  Fri Jan  9 15:46:15 2009
From: peter at stuge.se (Peter Stuge)
Date: Fri, 9 Jan 2009 15:46:15 +0100
Subject: [coreboot] [PATCH 1/2] cs5536: Add a NAND device and do the IDE
	PCI header disabling on time.
In-Reply-To: <1231512084.4558.18.camel@martr-gentoo.artec>
References: <1231503657.4558.9.camel@martr-gentoo.artec>
	<EC244EE6BC7E4B398B3D66256B62A7F0@chimp>
	<1231512084.4558.18.camel@martr-gentoo.artec>
Message-ID: <20090109144615.6038.qmail@stuge.se>

Mart Raudsepp wrote:
> The board doesn't have IDE stuff wired anywhere. No existing boards
> supported by coreboot do to my knowledge.

ALIX.1, .2 and .6 boards have the CF on IDE and an IDE header in
parallell.


//Peter



From mart.raudsepp at artecdesign.ee  Fri Jan  9 15:50:48 2009
From: mart.raudsepp at artecdesign.ee (Mart Raudsepp)
Date: Fri, 09 Jan 2009 16:50:48 +0200
Subject: [coreboot] [PATCH 1/2] cs5536: Add a NAND device and do the IDE
 PCI header disabling on time.
In-Reply-To: <20090109144615.6038.qmail@stuge.se>
References: <1231503657.4558.9.camel@martr-gentoo.artec>
	<EC244EE6BC7E4B398B3D66256B62A7F0@chimp>
	<1231512084.4558.18.camel@martr-gentoo.artec>
	<20090109144615.6038.qmail@stuge.se>
Message-ID: <1231512648.4558.24.camel@martr-gentoo.artec>

?hel kenal p?eval, R, 2009-01-09 kell 15:46, kirjutas Peter Stuge:
> Mart Raudsepp wrote:
> > The board doesn't have IDE stuff wired anywhere. No existing boards
> > supported by coreboot do to my knowledge.
> 
> ALIX.1, .2 and .6 boards have the CF on IDE and an IDE header in
> parallell.

Sorry, I meant that no existing board supported by coreboot has IDE and
Flash interface wired at the same time currently.

Does your comment still apply then in relation to enable_ide existence
perhaps?
How is the selection between CF and IDE header done on those ALIX
boards?


Mart Raudsepp




From mylesgw at gmail.com  Fri Jan  9 15:55:44 2009
From: mylesgw at gmail.com (Myles Watson)
Date: Fri, 9 Jan 2009 07:55:44 -0700
Subject: [coreboot] [PATCH 1/2] cs5536: Add a NAND device and do theIDE
	PCI header disabling on time.
In-Reply-To: <20090109144603.GA16760@localdomain>
References: <1231503657.4558.9.camel@martr-gentoo.artec>
	<EC244EE6BC7E4B398B3D66256B62A7F0@chimp>
	<20090109144603.GA16760@localdomain>
Message-ID: <FF5CB0BB4789466B9DBEE75D39426D9E@chimp>



> -----Original Message-----
> From: Ward Vandewege [mailto:ward at gnu.org]
> Sent: Friday, January 09, 2009 7:46 AM
> To: Myles Watson
> Cc: coreboot at coreboot.org
> Subject: Re: [coreboot] [PATCH 1/2] cs5536: Add a NAND device and do
> theIDE PCI header disabling on time.
> 
> On Fri, Jan 09, 2009 at 07:33:37AM -0700, Myles Watson wrote:
> > Maybe it would be better to have IDE/NAND selection depend on a
> CMOS/NVRAM
> > value, so that the same BIOS could be used with either choice.
> 
> Will that work on boards without cmos battery (they exist - alix2c3 for
> instance)?

Maybe there are no boards with IDE and NAND support?  If there are, are
there any without a CMOS battery?  How would the factory BIOS handle
selection?

I was just brainstorming.

Thanks,
Myles





From peter at stuge.se  Fri Jan  9 16:02:09 2009
From: peter at stuge.se (Peter Stuge)
Date: Fri, 9 Jan 2009 16:02:09 +0100
Subject: [coreboot] [PATCH 1/2] cs5536: Add a NAND device and do the IDE
	PCI header disabling on time.
In-Reply-To: <1231512648.4558.24.camel@martr-gentoo.artec>
References: <1231503657.4558.9.camel@martr-gentoo.artec>
	<EC244EE6BC7E4B398B3D66256B62A7F0@chimp>
	<1231512084.4558.18.camel@martr-gentoo.artec>
	<20090109144615.6038.qmail@stuge.se>
	<1231512648.4558.24.camel@martr-gentoo.artec>
Message-ID: <20090109150209.10735.qmail@stuge.se>

Mart Raudsepp wrote:
> Sorry, I meant that no existing board supported by coreboot has IDE
> and Flash interface wired at the same time currently.

Ah right! No, I haven't seen that. Seems a little unlikely because
IDE would be PIO only.


> Does your comment still apply then in relation to enable_ide
> existence perhaps?

Guess not. I think the motivation for enable_ide is simply one of
consistency. Most chipsets do not allow the IDE PCI device to be
hidden completely so enable_ide was added to control how it gets
configured.


> How is the selection between CF and IDE header done on those ALIX
> boards?

They're just parallell, and there's a master/slave jumper for the CF.


//Peter



From mart.raudsepp at artecdesign.ee  Fri Jan  9 16:06:31 2009
From: mart.raudsepp at artecdesign.ee (Mart Raudsepp)
Date: Fri, 09 Jan 2009 17:06:31 +0200
Subject: [coreboot] [PATCH 1/2] cs5536: Add a NAND device and do the IDE
 PCI header disabling on time.
In-Reply-To: <FF5CB0BB4789466B9DBEE75D39426D9E@chimp>
References: <1231503657.4558.9.camel@martr-gentoo.artec>
	<EC244EE6BC7E4B398B3D66256B62A7F0@chimp>
	<20090109144603.GA16760@localdomain>
	<FF5CB0BB4789466B9DBEE75D39426D9E@chimp>
Message-ID: <1231513591.4558.33.camel@martr-gentoo.artec>

?hel kenal p?eval, R, 2009-01-09 kell 07:55, kirjutas Myles Watson:
> 
> > -----Original Message-----
> > From: Ward Vandewege [mailto:ward at gnu.org]
> > Sent: Friday, January 09, 2009 7:46 AM
> > To: Myles Watson
> > Cc: coreboot at coreboot.org
> > Subject: Re: [coreboot] [PATCH 1/2] cs5536: Add a NAND device and do
> > theIDE PCI header disabling on time.
> > 
> > On Fri, Jan 09, 2009 at 07:33:37AM -0700, Myles Watson wrote:
> > > Maybe it would be better to have IDE/NAND selection depend on a
> > CMOS/NVRAM
> > > value, so that the same BIOS could be used with either choice.
> > 
> > Will that work on boards without cmos battery (they exist - alix2c3 for
> > instance)?
> 
> Maybe there are no boards with IDE and NAND support?  If there are, are
> there any without a CMOS battery?  How would the factory BIOS handle
> selection?

There's a default CMOS content to fall back to, so during build
configuration you'd probably select the default and then in NVRAM be
able to switch that around. If there is no CMOS battery or it gets reset
(checksums don't validate or so) you just fall back to the fallback
iirc.
So without a CMOS battery you'd always have the default chosen at build
time, but you can switch by booting from the default and changing it
with nvramtool and soft restarting without removing power, or with a
currently non-existent setup menu payload in the future.

Everything highly hypothetical and if there are no boards with both
supported based on this choice, then it's quite unlikely new ones will
appear either given the status of GeodeLX.


Regards,
Mart Raudsepp




From ward at gnu.org  Fri Jan  9 16:08:22 2009
From: ward at gnu.org (Ward Vandewege)
Date: Fri, 9 Jan 2009 10:08:22 -0500
Subject: [coreboot] [PATCH 1/2] cs5536: Add a NAND device and do the	IDE
	PCI header disabling on time.
In-Reply-To: <1231513591.4558.33.camel@martr-gentoo.artec>
References: <1231503657.4558.9.camel@martr-gentoo.artec>
	<EC244EE6BC7E4B398B3D66256B62A7F0@chimp>
	<20090109144603.GA16760@localdomain>
	<FF5CB0BB4789466B9DBEE75D39426D9E@chimp>
	<1231513591.4558.33.camel@martr-gentoo.artec>
Message-ID: <20090109150822.GA18313@localdomain>

On Fri, Jan 09, 2009 at 05:06:31PM +0200, Mart Raudsepp wrote:
> > > -----Original Message-----
> > > From: Ward Vandewege [mailto:ward at gnu.org]
> > > Sent: Friday, January 09, 2009 7:46 AM
> > > To: Myles Watson
> > > Cc: coreboot at coreboot.org
> > > Subject: Re: [coreboot] [PATCH 1/2] cs5536: Add a NAND device and do
> > > theIDE PCI header disabling on time.
> > > 
> > > On Fri, Jan 09, 2009 at 07:33:37AM -0700, Myles Watson wrote:
> > > > Maybe it would be better to have IDE/NAND selection depend on a
> > > CMOS/NVRAM
> > > > value, so that the same BIOS could be used with either choice.
> > > 
> > > Will that work on boards without cmos battery (they exist - alix2c3 for
> > > instance)?
> > 
> > Maybe there are no boards with IDE and NAND support?  If there are, are
> > there any without a CMOS battery?  How would the factory BIOS handle
> > selection?
> 
> There's a default CMOS content to fall back to, so during build
> configuration you'd probably select the default and then in NVRAM be
> able to switch that around. If there is no CMOS battery or it gets reset
> (checksums don't validate or so) you just fall back to the fallback
> iirc.
> So without a CMOS battery you'd always have the default chosen at build
> time, but you can switch by booting from the default and changing it
> with nvramtool and soft restarting without removing power, or with a
> currently non-existent setup menu payload in the future.
> 
> Everything highly hypothetical and if there are no boards with both
> supported based on this choice, then it's quite unlikely new ones will
> appear either given the status of GeodeLX.

Agreed. Sounds good to me.

Thanks,
Ward.

-- 
Ward Vandewege <ward at fsf.org>
Free Software Foundation - Senior Systems Administrator



From rminnich at gmail.com  Fri Jan  9 17:07:57 2009
From: rminnich at gmail.com (ron minnich)
Date: Fri, 9 Jan 2009 08:07:57 -0800
Subject: [coreboot] [PATCH 2/2] cs5536: Remove redundant enable_ide
	variable from ide device.
In-Reply-To: <1231512305.4558.21.camel@martr-gentoo.artec>
References: <1231503707.4558.10.camel@martr-gentoo.artec>
	<20090109143213.2246.qmail@stuge.se>
	<1231512305.4558.21.camel@martr-gentoo.artec>
Message-ID: <13426df10901090807h541a4107ka4817fa48b03cf65@mail.gmail.com>

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

I think it makes sense. I have not tested it.

ron



From mart.raudsepp at artecdesign.ee  Fri Jan  9 18:13:37 2009
From: mart.raudsepp at artecdesign.ee (Mart Raudsepp)
Date: Fri, 09 Jan 2009 19:13:37 +0200
Subject: [coreboot] [PATCH 1/2] cs5536: Add a NAND device and do the IDE
 PCI header disabling on time.
In-Reply-To: <20090109142941.1606.qmail@stuge.se>
References: <1231503657.4558.9.camel@martr-gentoo.artec>
	<20090109142941.1606.qmail@stuge.se>
Message-ID: <1231521217.4558.35.camel@martr-gentoo.artec>

?hel kenal p?eval, R, 2009-01-09 kell 15:29, kirjutas Peter Stuge:
> Mart Raudsepp wrote:
> > cs5536: Add a NAND device and do the IDE PCI header disabling on time.
> > 
> > This implements a nand device, akin to the ide device to follow the coreboot-v3 device tree design better.
> > It allows us to do the IDE PCI header early enough in a clean way - the hide_vpci was called way too late
> > before - in phase6 of southbridge device, but we need the Flash header active instead of IDE in the VSA2
> > before bus scans happen, or the PCI device gets disabled in coreboot understanding by the time we get it
> > enabled in VSA2.
> > It makes NAND setup work better, but still not completely. There is a VSA2 bug for which I made a patch,
> > but waiting on a new binary to test if after that everything works or not. A quick hack to workaround the
> > VSA2 bug suggests something further will still need fixing. There are also more potential opportunities
> > to shuffle NAND code around to match v3 approach better, but that's a next step for me after NAND setup
> > actually works right in the current form.
> > 
> > Also corrected the documentation of ide_init() to match current reality.
> > 
> > Signed-off-by: Mart Raudsepp <mart.raudsepp at artecdesign.ee>
> 
> Acked-by: Peter Stuge <peter at stuge.se>


Here's a new patch for the same thing.
It adds a dev->enabled check to nand_phase2 hide_vpci call compared to
the previous, so that it won't switch to NAND if some mainboard dts
decides to add a nand device that is spedified to be "disabled;".


Regards,
Mart Raudsepp

From mart.raudsepp at artecdesign.ee  Thu Jan  8 19:49:16 2009
From: mart.raudsepp at artecdesign.ee (Mart Raudsepp)
Date: Thu, 8 Jan 2009 20:49:16 +0200
Subject: [PATCH] cs5536: Add a NAND device and do the IDE PCI header disabling on time.
Message-ID: <mailman.2657.1355071468.16123.coreboot@coreboot.org>

This implements a nand device, akin to the ide device to follow the coreboot-v3 device tree design better.
It allows us to do the IDE PCI header early enough in a clean way - the hide_vpci was called way too late
before - in phase6 of southbridge device, but we need the Flash header active instead of IDE in the VSA2
before bus scans happen, or the PCI device gets disabled in coreboot understanding by the time we get it
enabled in VSA2.
It makes NAND setup work better, but still not completely. There is a VSA2 bug for which I made a patch,
but waiting on a new binary to test if after that everything works or not. A quick hack to workaround the
VSA2 bug suggests something further will still need fixing. There are also more potential opportunities
to shuffle NAND code around to match v3 approach better, but that's a next step for me after NAND setup
actually works right in the current form.

Also corrected the documentation of ide_init() to match current reality.

Signed-off-by: Mart Raudsepp <mart.raudsepp at artecdesign.ee>
---
 mainboard/artecgroup/dbe61/dts  |    3 ++
 mainboard/artecgroup/dbe62/dts  |    3 ++
 southbridge/amd/cs5536/cs5536.c |   49 +++++++++++++++++++++++++-------------
 southbridge/amd/cs5536/nand     |   23 ++++++++++++++++++
 4 files changed, 61 insertions(+), 17 deletions(-)
 create mode 100644 southbridge/amd/cs5536/nand

diff --git a/mainboard/artecgroup/dbe61/dts b/mainboard/artecgroup/dbe61/dts
index b443533..48df288 100644
--- a/mainboard/artecgroup/dbe61/dts
+++ b/mainboard/artecgroup/dbe61/dts
@@ -109,6 +109,9 @@ end
 			/* USB Port Power Handling setting. */
 			pph = "0xf5";
 		};
+		pci at f,1 {
+			/config/("southbridge/amd/cs5536/nand");
+		};
 		pci at f,2 {
 			/config/("southbridge/amd/cs5536/ide");
 		};
diff --git a/mainboard/artecgroup/dbe62/dts b/mainboard/artecgroup/dbe62/dts
index 213c397..3cbe0ff 100644
--- a/mainboard/artecgroup/dbe62/dts
+++ b/mainboard/artecgroup/dbe62/dts
@@ -63,6 +63,9 @@
 			/* USB Port Power Handling setting. */
 			pph = "0xf5";
 		};
+		pci at f,1 {
+			/config/("southbridge/amd/cs5536/nand");
+		};
 		pci at f,2 {
 			/config/("southbridge/amd/cs5536/ide");
 		};
diff --git a/southbridge/amd/cs5536/cs5536.c b/southbridge/amd/cs5536/cs5536.c
index 89d64d6..057400f 100644
--- a/southbridge/amd/cs5536/cs5536.c
+++ b/southbridge/amd/cs5536/cs5536.c
@@ -98,6 +98,23 @@ static void hide_vpci(u32 vpci_devid)
 }
 
 /**
+ * Enables the FLASH PCI header when NAND device existing in mainboard device
+ * tree. Used when the mainboard has a FLASH part instead of an IDE drive and
+ * that fact is expressed in the mainboard device tree.
+ * Must be called after VSA init but before PCI scans to enable the flash
+ * PCI device header early enough - that is .phase2_fixup of the device.
+ *
+ * @param dev The device.
+ */
+static void nand_phase2(struct device *dev)
+{
+	if (dev->enabled) {
+		/* Tell VSA to use FLASH PCI header. Not IDE header. */
+		hide_vpci(0x800079C4);
+	}
+}
+
+/**
  * Power button setup.
  *
  * Setup GPIO24, it is the external signal for CS5536 vsb_work_aux which
@@ -170,16 +187,6 @@ static void chipset_flash_setup(struct southbridge_amd_cs5536_dts_config *sb)
 	printk(BIOS_DEBUG, "chipset_flash_setup: Finish\n");
 }
 
-/**
- * Use this in the event that you have a FLASH part instead of an IDE drive.
- * Run after VSA init to enable the flash PCI device header.
- */
-static void enable_ide_nand_flash_header(void)
-{
-	/* Tell VSA to use FLASH PCI header. Not IDE header. */
-	hide_vpci(0x800079C4);
-}
-
 #define RTC_CENTURY	0x32
 #define RTC_DOMA	0x3D
 #define RTC_MONA	0x3E
@@ -601,8 +608,8 @@ void chipsetinit(void)
 #define IDE_ETC	  0x50
 
 /**
- * Enabled the IDE. This is code that is optionally run if the ide_enable is set
- * in the mainboard dts. 
+ * Enables the IDE. This is code that is run if there is an ide device in the mainboard
+ * device tree and it has set non-zero "enable_ide".
  * 
  * @param dev The device 
  */
@@ -658,11 +665,6 @@ static void southbridge_init(struct device *dev)
 		printk(BIOS_SPEW, "cs5536: done second call vr_write\n");
 	}
 
-	printk(BIOS_ERR, "cs5536: %s: enable_ide_nand_flash is %d\n",
-	       __FUNCTION__, sb->enable_ide_nand_flash);
-	if (sb->enable_ide_nand_flash != 0)
-		enable_ide_nand_flash_header();
-
 	enable_USB_port4(sb);
 
 	/* disable unwanted virtual PCI devices */
@@ -733,3 +735,16 @@ struct device_operations cs5536_ide = {
 	.ops_pci		 = &pci_dev_ops_pci,
 };
 
+struct device_operations cs5536_nand = {
+	.id = {.type = DEVICE_ID_PCI,
+		{.pci = {.vendor = PCI_VENDOR_ID_AMD,
+			 .device = PCI_DEVICE_ID_AMD_CS5536_FLASH}}},
+	.constructor		 = default_device_constructor,
+	.phase2_fixup		 = nand_phase2,
+	.phase3_scan		 = 0,
+	.phase4_read_resources	 = pci_dev_read_resources,
+	.phase4_set_resources	 = pci_set_resources,
+	.phase5_enable_resources = pci_dev_enable_resources,
+	.phase6_init		 = 0, /* No Option ROMs */
+	.ops_pci		 = &pci_dev_ops_pci,
+};
diff --git a/southbridge/amd/cs5536/nand b/southbridge/amd/cs5536/nand
new file mode 100644
index 0000000..69f4fa4
--- /dev/null
+++ b/southbridge/amd/cs5536/nand
@@ -0,0 +1,23 @@
+/*
+ * This file is part of the coreboot project.
+ *
+ * Copyright (C) 2009 Mart Raudsepp <mart.raudsepp at artecdesign.ee>
+ *
+ * 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
+ */
+
+{
+	device_operations = "cs5536_nand";
+};
-- 
1.6.0.4


--=-1xTwwUBL3x7eRC+hClPJ--




From peter at stuge.se  Fri Jan  9 18:40:09 2009
From: peter at stuge.se (Peter Stuge)
Date: Fri, 9 Jan 2009 18:40:09 +0100
Subject: [coreboot] [PATCH 1/2] cs5536: Add a NAND device and do the IDE
	PCI header disabling on time.
In-Reply-To: <1231521217.4558.35.camel@martr-gentoo.artec>
References: <1231503657.4558.9.camel@martr-gentoo.artec>
	<20090109142941.1606.qmail@stuge.se>
	<1231521217.4558.35.camel@martr-gentoo.artec>
Message-ID: <20090109174009.19766.qmail@stuge.se>

Mart Raudsepp wrote:
> From 21de84bab3d32cefd71a2e95e6caf4f505c4cbff Mon Sep 17 00:00:00 2001
> From: Mart Raudsepp <mart.raudsepp at artecdesign.ee>
> Date: Thu, 8 Jan 2009 20:49:16 +0200
> Subject: [PATCH] cs5536: Add a NAND device and do the IDE PCI header disabling on time.
> 
> This implements a nand device, akin to the ide device to follow the coreboot-v3 device tree design better.
> It allows us to do the IDE PCI header early enough in a clean way - the hide_vpci was called way too late
> before - in phase6 of southbridge device, but we need the Flash header active instead of IDE in the VSA2
> before bus scans happen, or the PCI device gets disabled in coreboot understanding by the time we get it
> enabled in VSA2.
> It makes NAND setup work better, but still not completely. There is a VSA2 bug for which I made a patch,
> but waiting on a new binary to test if after that everything works or not. A quick hack to workaround the
> VSA2 bug suggests something further will still need fixing. There are also more potential opportunities
> to shuffle NAND code around to match v3 approach better, but that's a next step for me after NAND setup
> actually works right in the current form.
> 
> Also corrected the documentation of ide_init() to match current reality.
> 
> Signed-off-by: Mart Raudsepp <mart.raudsepp at artecdesign.ee>

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



From svn at coreboot.org  Fri Jan  9 19:12:05 2009
From: svn at coreboot.org (svn at coreboot.org)
Date: Fri,  9 Jan 2009 19:12:05 +0100
Subject: [coreboot] r1113 - in coreboot-v3: mainboard/artecgroup/dbe61
	mainboard/artecgroup/dbe62 southbridge/amd/cs5536
Message-ID: <mailman.2658.1355071468.16123.coreboot@coreboot.org>

Author: mraudsepp
Date: 2009-01-09 19:12:05 +0100 (Fri, 09 Jan 2009)
New Revision: 1113

Added:
   coreboot-v3/southbridge/amd/cs5536/nand
Modified:
   coreboot-v3/mainboard/artecgroup/dbe61/dts
   coreboot-v3/mainboard/artecgroup/dbe62/dts
   coreboot-v3/southbridge/amd/cs5536/cs5536.c
Log:
cs5536: Add a NAND device and do the IDE PCI header disabling on time.

This implements a nand device, akin to the ide device to follow the coreboot-v3 device tree design better.
It allows us to do the IDE PCI header early enough in a clean way - the hide_vpci was called way too late
before - in phase6 of southbridge device, but we need the Flash header active instead of IDE in the VSA2
before bus scans happen, or the PCI device gets disabled in coreboot understanding by the time we get it
enabled in VSA2.
It makes NAND setup work better, but still not completely. There is a VSA2 bug for which I made a patch,
but waiting on a new binary to test if after that everything works or not. A quick hack to workaround the
VSA2 bug suggests something further will still need fixing. There are also more potential opportunities
to shuffle NAND code around to match v3 approach better, but that's a next step for me after NAND setup
actually works right in the current form.

Also corrected the documentation of ide_init() to match current reality.

Signed-off-by: Mart Raudsepp <mart.raudsepp at artecdesign.ee>
Acked-by: Peter Stuge <peter at stuge.se>

Modified: coreboot-v3/mainboard/artecgroup/dbe61/dts
===================================================================
--- coreboot-v3/mainboard/artecgroup/dbe61/dts	2009-01-09 14:17:06 UTC (rev 1112)
+++ coreboot-v3/mainboard/artecgroup/dbe61/dts	2009-01-09 18:12:05 UTC (rev 1113)
@@ -109,6 +109,9 @@
 			/* USB Port Power Handling setting. */
 			pph = "0xf5";
 		};
+		pci at f,1 {
+			/config/("southbridge/amd/cs5536/nand");
+		};
 		pci at f,2 {
 			/config/("southbridge/amd/cs5536/ide");
 		};

Modified: coreboot-v3/mainboard/artecgroup/dbe62/dts
===================================================================
--- coreboot-v3/mainboard/artecgroup/dbe62/dts	2009-01-09 14:17:06 UTC (rev 1112)
+++ coreboot-v3/mainboard/artecgroup/dbe62/dts	2009-01-09 18:12:05 UTC (rev 1113)
@@ -63,6 +63,9 @@
 			/* USB Port Power Handling setting. */
 			pph = "0xf5";
 		};
+		pci at f,1 {
+			/config/("southbridge/amd/cs5536/nand");
+		};
 		pci at f,2 {
 			/config/("southbridge/amd/cs5536/ide");
 		};

Modified: coreboot-v3/southbridge/amd/cs5536/cs5536.c
===================================================================
--- coreboot-v3/southbridge/amd/cs5536/cs5536.c	2009-01-09 14:17:06 UTC (rev 1112)
+++ coreboot-v3/southbridge/amd/cs5536/cs5536.c	2009-01-09 18:12:05 UTC (rev 1113)
@@ -98,6 +98,23 @@
 }
 
 /**
+ * Enables the FLASH PCI header when NAND device existing in mainboard device
+ * tree. Used when the mainboard has a FLASH part instead of an IDE drive and
+ * that fact is expressed in the mainboard device tree.
+ * Must be called after VSA init but before PCI scans to enable the flash
+ * PCI device header early enough - that is .phase2_fixup of the device.
+ *
+ * @param dev The device.
+ */
+static void nand_phase2(struct device *dev)
+{
+	if (dev->enabled) {
+		/* Tell VSA to use FLASH PCI header. Not IDE header. */
+		hide_vpci(0x800079C4);
+	}
+}
+
+/**
  * Power button setup.
  *
  * Setup GPIO24, it is the external signal for CS5536 vsb_work_aux which
@@ -170,16 +187,6 @@
 	printk(BIOS_DEBUG, "chipset_flash_setup: Finish\n");
 }
 
-/**
- * Use this in the event that you have a FLASH part instead of an IDE drive.
- * Run after VSA init to enable the flash PCI device header.
- */
-static void enable_ide_nand_flash_header(void)
-{
-	/* Tell VSA to use FLASH PCI header. Not IDE header. */
-	hide_vpci(0x800079C4);
-}
-
 #define RTC_CENTURY	0x32
 #define RTC_DOMA	0x3D
 #define RTC_MONA	0x3E
@@ -601,8 +608,8 @@
 #define IDE_ETC	  0x50
 
 /**
- * Enabled the IDE. This is code that is optionally run if the ide_enable is set
- * in the mainboard dts. 
+ * Enables the IDE. This is code that is run if there is an ide device in the mainboard
+ * device tree and it has set non-zero "enable_ide".
  * 
  * @param dev The device 
  */
@@ -658,11 +665,6 @@
 		printk(BIOS_SPEW, "cs5536: done second call vr_write\n");
 	}
 
-	printk(BIOS_ERR, "cs5536: %s: enable_ide_nand_flash is %d\n",
-	       __FUNCTION__, sb->enable_ide_nand_flash);
-	if (sb->enable_ide_nand_flash != 0)
-		enable_ide_nand_flash_header();
-
 	enable_USB_port4(sb);
 
 	/* disable unwanted virtual PCI devices */
@@ -733,3 +735,16 @@
 	.ops_pci		 = &pci_dev_ops_pci,
 };
 
+struct device_operations cs5536_nand = {
+	.id = {.type = DEVICE_ID_PCI,
+		{.pci = {.vendor = PCI_VENDOR_ID_AMD,
+			 .device = PCI_DEVICE_ID_AMD_CS5536_FLASH}}},
+	.constructor		 = default_device_constructor,
+	.phase2_fixup		 = nand_phase2,
+	.phase3_scan		 = 0,
+	.phase4_read_resources	 = pci_dev_read_resources,
+	.phase4_set_resources	 = pci_set_resources,
+	.phase5_enable_resources = pci_dev_enable_resources,
+	.phase6_init		 = 0, /* No Option ROMs */
+	.ops_pci		 = &pci_dev_ops_pci,
+};

Added: coreboot-v3/southbridge/amd/cs5536/nand
===================================================================
--- coreboot-v3/southbridge/amd/cs5536/nand	                        (rev 0)
+++ coreboot-v3/southbridge/amd/cs5536/nand	2009-01-09 18:12:05 UTC (rev 1113)
@@ -0,0 +1,23 @@
+/*
+ * This file is part of the coreboot project.
+ *
+ * Copyright (C) 2009 Mart Raudsepp <mart.raudsepp at artecdesign.ee>
+ *
+ * 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
+ */
+
+{
+	device_operations = "cs5536_nand";
+};




From svn at coreboot.org  Fri Jan  9 19:12:08 2009
From: svn at coreboot.org (svn at coreboot.org)
Date: Fri,  9 Jan 2009 19:12:08 +0100
Subject: [coreboot] r1114 - in coreboot-v3: mainboard/adl/msm800sev
	mainboard/amd/db800 mainboard/amd/norwich
	mainboard/amp/tinygx mainboard/artecgroup/dbe61
	mainboard/artecgroup/dbe62 mainboard/pcengines/alix1c
	mainboard/pcengines/alix2c3 southbridge/amd/cs5536
Message-ID: <mailman.2659.1355071468.16123.coreboot@coreboot.org>

Author: mraudsepp
Date: 2009-01-09 19:12:08 +0100 (Fri, 09 Jan 2009)
New Revision: 1114

Modified:
   coreboot-v3/mainboard/adl/msm800sev/dts
   coreboot-v3/mainboard/amd/db800/dts
   coreboot-v3/mainboard/amd/norwich/dts
   coreboot-v3/mainboard/amp/tinygx/dts
   coreboot-v3/mainboard/artecgroup/dbe61/dts
   coreboot-v3/mainboard/artecgroup/dbe62/dts
   coreboot-v3/mainboard/pcengines/alix1c/dts
   coreboot-v3/mainboard/pcengines/alix2c3/dts
   coreboot-v3/southbridge/amd/cs5536/cs5536.c
   coreboot-v3/southbridge/amd/cs5536/ide
Log:
cs5536: Remove redundant enable_ide variable from ide device.

The device infrastructure already has an enabled bit, so we don't need to duplicate it in the current form.
cs5536.c:ide_init() is phase6_init, which is called only if the device is enabled, so if the device doesn't
exist, or the mainboard dts says "disabled;" for it, the init is not done and an extra conditional is not
necessary.
Adapt all cs5536 using mainboards to it (removing enable_ide variable) - artecgroup/dbe6[12] gets the whole
IDE device removed, which results in the ide_init() code not being ran as before (before it was called but
early return from enable_ide == 0, now it won't be called in the first place).

Signed-off-by: Mart Raudsepp <mart.raudsepp at artecdesign.ee>
Acked-by: Ronald G. Minnich <rminnich at gmail.com>

Modified: coreboot-v3/mainboard/adl/msm800sev/dts
===================================================================
--- coreboot-v3/mainboard/adl/msm800sev/dts	2009-01-09 18:12:05 UTC (rev 1113)
+++ coreboot-v3/mainboard/adl/msm800sev/dts	2009-01-09 18:12:08 UTC (rev 1114)
@@ -39,7 +39,6 @@
 		};
 		pci at f,2 {
 			/config/("southbridge/amd/cs5536/ide");
-			enable_ide = "1";
 		};
 		ioport at 2e {
 			/config/("superio/winbond/w83627hf/dts");

Modified: coreboot-v3/mainboard/amd/db800/dts
===================================================================
--- coreboot-v3/mainboard/amd/db800/dts	2009-01-09 18:12:05 UTC (rev 1113)
+++ coreboot-v3/mainboard/amd/db800/dts	2009-01-09 18:12:08 UTC (rev 1114)
@@ -54,7 +54,6 @@
 		};
 		pci at f,2 {
 			/config/("southbridge/amd/cs5536/ide");
-			enable_ide = "1";
 		};
 		ioport at 2e {
 			/config/("superio/winbond/w83627hf/dts");

Modified: coreboot-v3/mainboard/amd/norwich/dts
===================================================================
--- coreboot-v3/mainboard/amd/norwich/dts	2009-01-09 18:12:05 UTC (rev 1113)
+++ coreboot-v3/mainboard/amd/norwich/dts	2009-01-09 18:12:08 UTC (rev 1114)
@@ -57,7 +57,6 @@
 		};
 		pci at f,2 {
 			/config/("southbridge/amd/cs5536/ide");
-			enable_ide = "1";
 		};
 	};
 };

Modified: coreboot-v3/mainboard/amp/tinygx/dts
===================================================================
--- coreboot-v3/mainboard/amp/tinygx/dts	2009-01-09 18:12:05 UTC (rev 1113)
+++ coreboot-v3/mainboard/amp/tinygx/dts	2009-01-09 18:12:08 UTC (rev 1114)
@@ -54,7 +54,6 @@
 		};
 		pci at f,2 {
 			/config/("southbridge/amd/cs5536/ide");
-			enable_ide = "1";
 		};
 		ioport at 2e {
 			/config/("superio/ite/it8716f/dts");

Modified: coreboot-v3/mainboard/artecgroup/dbe61/dts
===================================================================
--- coreboot-v3/mainboard/artecgroup/dbe61/dts	2009-01-09 18:12:05 UTC (rev 1113)
+++ coreboot-v3/mainboard/artecgroup/dbe61/dts	2009-01-09 18:12:08 UTC (rev 1114)
@@ -112,8 +112,5 @@
 		pci at f,1 {
 			/config/("southbridge/amd/cs5536/nand");
 		};
-		pci at f,2 {
-			/config/("southbridge/amd/cs5536/ide");
-		};
 	};
 };

Modified: coreboot-v3/mainboard/artecgroup/dbe62/dts
===================================================================
--- coreboot-v3/mainboard/artecgroup/dbe62/dts	2009-01-09 18:12:05 UTC (rev 1113)
+++ coreboot-v3/mainboard/artecgroup/dbe62/dts	2009-01-09 18:12:08 UTC (rev 1114)
@@ -66,8 +66,5 @@
 		pci at f,1 {
 			/config/("southbridge/amd/cs5536/nand");
 		};
-		pci at f,2 {
-			/config/("southbridge/amd/cs5536/ide");
-		};
 	};
 };

Modified: coreboot-v3/mainboard/pcengines/alix1c/dts
===================================================================
--- coreboot-v3/mainboard/pcengines/alix1c/dts	2009-01-09 18:12:05 UTC (rev 1113)
+++ coreboot-v3/mainboard/pcengines/alix1c/dts	2009-01-09 18:12:08 UTC (rev 1114)
@@ -51,7 +51,6 @@
 		};
 		pci at f,2 {
 			/config/("southbridge/amd/cs5536/ide");
-			enable_ide = "1";
 		};
 		ioport at 2e {
 			/config/("superio/winbond/w83627hf/dts");

Modified: coreboot-v3/mainboard/pcengines/alix2c3/dts
===================================================================
--- coreboot-v3/mainboard/pcengines/alix2c3/dts	2009-01-09 18:12:05 UTC (rev 1113)
+++ coreboot-v3/mainboard/pcengines/alix2c3/dts	2009-01-09 18:12:08 UTC (rev 1114)
@@ -51,7 +51,6 @@
 		};
 		pci at f,2 {
 			/config/("southbridge/amd/cs5536/ide");
-			enable_ide = "1";
 		};
 	};
 };

Modified: coreboot-v3/southbridge/amd/cs5536/cs5536.c
===================================================================
--- coreboot-v3/southbridge/amd/cs5536/cs5536.c	2009-01-09 18:12:05 UTC (rev 1113)
+++ coreboot-v3/southbridge/amd/cs5536/cs5536.c	2009-01-09 18:12:08 UTC (rev 1114)
@@ -609,7 +609,7 @@
 
 /**
  * Enables the IDE. This is code that is run if there is an ide device in the mainboard
- * device tree and it has set non-zero "enable_ide".
+ * device tree.
  * 
  * @param dev The device 
  */
@@ -617,11 +617,6 @@
 {
 	u32 ide_cfg;
 
-	struct southbridge_amd_cs5536_ide_config *ide =
-	    (struct southbridge_amd_cs5536_ide_config *)dev->device_configuration;
-	if (!ide->enable_ide)
-		return;
-
 	printk(BIOS_DEBUG, "cs5536_ide: %s\n", __func__);
 	/* GPIO and IRQ setup are handled in the main chipset code. */
 

Modified: coreboot-v3/southbridge/amd/cs5536/ide
===================================================================
--- coreboot-v3/southbridge/amd/cs5536/ide	2009-01-09 18:12:05 UTC (rev 1113)
+++ coreboot-v3/southbridge/amd/cs5536/ide	2009-01-09 18:12:08 UTC (rev 1114)
@@ -20,7 +20,4 @@
 
 {
 	device_operations = "cs5536_ide";
-
-	/* IDE: enable CS5536 IDE. There may be a different IDE controller on board */
-	enable_ide = "0";
 };




From marcj303 at gmail.com  Fri Jan  9 20:40:50 2009
From: marcj303 at gmail.com (Marc Jones)
Date: Fri, 9 Jan 2009 12:40:50 -0700
Subject: [coreboot] [PATCH 1/2] cs5536: Add a NAND device and do the IDE
	PCI header disabling on time.
In-Reply-To: <20090109174009.19766.qmail@stuge.se>
References: <1231503657.4558.9.camel@martr-gentoo.artec>
	<20090109142941.1606.qmail@stuge.se>
	<1231521217.4558.35.camel@martr-gentoo.artec>
	<20090109174009.19766.qmail@stuge.se>
Message-ID: <534e5dc20901091140i78ff1e9dn491951541bd047c@mail.gmail.com>

peOn Fri, Jan 9, 2009 at 10:40 AM, Peter Stuge <peter at stuge.se> wrote:
> Mart Raudsepp wrote:
>> From 21de84bab3d32cefd71a2e95e6caf4f505c4cbff Mon Sep 17 00:00:00 2001
>> From: Mart Raudsepp <mart.raudsepp at artecdesign.ee>
>> Date: Thu, 8 Jan 2009 20:49:16 +0200
>> Subject: [PATCH] cs5536: Add a NAND device and do the IDE PCI header disabling on time.
>>
>> This implements a nand device, akin to the ide device to follow the coreboot-v3 device tree design better.
>> It allows us to do the IDE PCI header early enough in a clean way - the hide_vpci was called way too late
>> before - in phase6 of southbridge device, but we need the Flash header active instead of IDE in the VSA2
>> before bus scans happen, or the PCI device gets disabled in coreboot understanding by the time we get it
>> enabled in VSA2.
>> It makes NAND setup work better, but still not completely. There is a VSA2 bug for which I made a patch,
>> but waiting on a new binary to test if after that everything works or not. A quick hack to workaround the
>> VSA2 bug suggests something further will still need fixing. There are also more potential opportunities
>> to shuffle NAND code around to match v3 approach better, but that's a next step for me after NAND setup
>> actually works right in the current form.
>>
>> Also corrected the documentation of ide_init() to match current reality.
>>
>> Signed-off-by: Mart Raudsepp <mart.raudsepp at artecdesign.ee>
>
> Acked-by: Peter Stuge <peter at stuge.se>
>
> --
> coreboot mailing list: coreboot at coreboot.org
> http://www.coreboot.org/mailman/listinfo/coreboot
>
Peter already acked but for what it is worth.

Acked-by; Marc Jones <marcj303 at gmail.com>



From c-d.hailfinger.devel.2006 at gmx.net  Fri Jan  9 22:18:20 2009
From: c-d.hailfinger.devel.2006 at gmx.net (Carl-Daniel Hailfinger)
Date: Fri, 09 Jan 2009 22:18:20 +0100
Subject: [coreboot] SeaBIOS and Windows 7
Message-ID: <4967BF1C.1060209@gmx.net>

Hi,

Microsoft is offering free _beta_ downloads of Windows 7 and Windows
Server 2008 R2 while supplies last (2.5 million downloads is the total
limit for Windows 7).

Windows 7 is available at
http://www.microsoft.com/germany/windows/windows-7/beta-download.aspx
(that server has load problems, but some useful information can be found
at
http://www.heise.de/newsticker/foren/S-Direkt-Download-Eng-Updatetd/forum-150081/msg-16113668/read/
)
Windows Server 2008 R2 is available at
http://www.microsoft.com/downloads/details.aspx?FamilyId=85CFE4C9-34DE-477C-B5CA-75EDAE3D57C5&displaylang=en

Has anybody downloaded this and tested it with SeaBIOS? If it works, we
have a real marketing opportunity.
I'd download it myself, but my hd doesn't have enough space for an
abuild run and these isos.

Regards,
Carl-Daniel

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




From r.marek at assembler.cz  Sat Jan 10 00:56:25 2009
From: r.marek at assembler.cz (Rudolf Marek)
Date: Sat, 10 Jan 2009 00:56:25 +0100
Subject: [coreboot] SeaBIOS and Windows 7
In-Reply-To: <4967BF1C.1060209@gmx.net>
References: <4967BF1C.1060209@gmx.net>
Message-ID: <4967E429.9010302@assembler.cz>

Hi all,

If I find some DVD ROM I can try that. Btw here is direct download link:
wget -c
"http://download.microsoft.com/download/6/3/3/633118BD-6C3D-45A4-B985-F0FDFFE1B021/EN/7000.0.081212-1400_client_en-us_Ultimate-GB1CULXFRE_EN_DVD.ISO"


It went pretty smooth, around 32Mbit/s

Rudolf



From r.marek at assembler.cz  Sat Jan 10 00:59:21 2009
From: r.marek at assembler.cz (Rudolf Marek)
Date: Sat, 10 Jan 2009 00:59:21 +0100
Subject: [coreboot] SeaBIOS and Windows 7
In-Reply-To: <4967E429.9010302@assembler.cz>
References: <4967BF1C.1060209@gmx.net> <4967E429.9010302@assembler.cz>
Message-ID: <4967E4D9.3010302@assembler.cz>

Oh I forgot, dont forgot to apply the MP3 corrupt by media player issue.

(and bonus XKCD)

http://www.neowin.net/news/main/09/01/09/windows-7-public-beta-released-remember-to-patch

Rudolf



From stepan at coresystems.de  Sat Jan 10 20:09:26 2009
From: stepan at coresystems.de (Stefan Reinauer)
Date: Sat, 10 Jan 2009 20:09:26 +0100
Subject: [coreboot] [PATCH]coreboot-v2: ignore some more sections
In-Reply-To: <200901091441.55536.patrick@georgi-clan.de>
References: <200901091441.55536.patrick@georgi-clan.de>
Message-ID: <4968F266.8040501@coresystems.de>

Patrick Georgi wrote:
> Hi,
>
> after I updated my SuSE system, coreboot.strip grew to 4GB. Seems 
> like they introduced some new notes sections that got in the way.
> Attached patch ignores them, too.
>
> It should be trivial, but I'd rather have some confirmation.
>
>
> Regards,
> Patrick Georgi
>   

> Ignore some more sections, created by newer toolchains
>
> 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


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

From svn at coreboot.org  Sun Jan 11 01:35:30 2009
From: svn at coreboot.org (svn at coreboot.org)
Date: Sun, 11 Jan 2009 01:35:30 +0100
Subject: [coreboot] r3854 - trunk/coreboot-v2/src/arch/i386/init
Message-ID: <mailman.2660.1355071468.16123.coreboot@coreboot.org>

Author: oxygene
Date: 2009-01-11 01:35:30 +0100 (Sun, 11 Jan 2009)
New Revision: 3854

Modified:
   trunk/coreboot-v2/src/arch/i386/init/ldscript.lb
   trunk/coreboot-v2/src/arch/i386/init/ldscript_failover.lb
   trunk/coreboot-v2/src/arch/i386/init/ldscript_fallback.lb
Log:
Ignore some more sections, created by newer toolchains

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


Modified: trunk/coreboot-v2/src/arch/i386/init/ldscript.lb
===================================================================
--- trunk/coreboot-v2/src/arch/i386/init/ldscript.lb	2009-01-08 16:53:13 UTC (rev 3853)
+++ trunk/coreboot-v2/src/arch/i386/init/ldscript.lb	2009-01-11 00:35:30 UTC (rev 3854)
@@ -62,6 +62,8 @@
 
 	/DISCARD/ : {
 		*(.comment)
+		*(.comment.*)
 		*(.note)
+		*(.note.*)
 	}
 }

Modified: trunk/coreboot-v2/src/arch/i386/init/ldscript_failover.lb
===================================================================
--- trunk/coreboot-v2/src/arch/i386/init/ldscript_failover.lb	2009-01-08 16:53:13 UTC (rev 3853)
+++ trunk/coreboot-v2/src/arch/i386/init/ldscript_failover.lb	2009-01-11 00:35:30 UTC (rev 3854)
@@ -52,5 +52,7 @@
 	/DISCARD/ : {
 		*(.comment)
 		*(.note)
+		*(.comment.*)
+		*(.note.*)
 	}
 }

Modified: trunk/coreboot-v2/src/arch/i386/init/ldscript_fallback.lb
===================================================================
--- trunk/coreboot-v2/src/arch/i386/init/ldscript_fallback.lb	2009-01-08 16:53:13 UTC (rev 3853)
+++ trunk/coreboot-v2/src/arch/i386/init/ldscript_fallback.lb	2009-01-11 00:35:30 UTC (rev 3854)
@@ -67,5 +67,7 @@
 	/DISCARD/ : {
 		*(.comment)
 		*(.note)
+		*(.comment.*)
+		*(.note.*)
 	}
 }




From vidwer at gmail.com  Sun Jan 11 04:12:26 2009
From: vidwer at gmail.com (Idwer Vollering)
Date: Sun, 11 Jan 2009 04:12:26 +0100
Subject: [coreboot] [patch] update the readme of flashrom
Message-ID: <fdea27e40901101912n43f59b76l415abf96e26387ef@mail.gmail.com>

Mimicked from flashrom.c, see patch.

Signed-off-by: Idwer <vidwer at gmail.com>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20090111/500a5764/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: update_flashrom_readme.patch
Type: text/x-diff
Size: 1079 bytes
Desc: not available
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20090111/500a5764/attachment.bin>

From svn at coreboot.org  Sun Jan 11 04:31:02 2009
From: svn at coreboot.org (svn at coreboot.org)
Date: Sun, 11 Jan 2009 04:31:02 +0100
Subject: [coreboot] r3855 - trunk/util/flashrom
Message-ID: <mailman.2661.1355071468.16123.coreboot@coreboot.org>

Author: stuge
Date: 2009-01-11 04:31:02 +0100 (Sun, 11 Jan 2009)
New Revision: 3855

Modified:
   trunk/util/flashrom/README
Log:
flashrom: Update usage in README

Mimicked from flashrom.c

Signed-off-by: Idwer Vollering <vidwer at gmail.com>
Acked-by: Peter Stuge <peter at stuge.se>


Modified: trunk/util/flashrom/README
===================================================================
--- trunk/util/flashrom/README	2009-01-11 00:35:30 UTC (rev 3854)
+++ trunk/util/flashrom/README	2009-01-11 03:31:02 UTC (rev 3855)
@@ -21,7 +21,7 @@
 Usage
 -----
 
- $ flashrom [-rwvEVfh] [-c chipname] [-s exclude_start] [-e exclude_end]
+ $ flashrom [-rwvEVfLhR] [-c chipname] [-s exclude_start] [-e exclude_end]
             [-m [vendor:]part] [-l file.layout] [-i imagename] [file]
    -r | --read:                      read flash and save into file
    -w | --write:                     write file into flash (default when
@@ -36,6 +36,9 @@
    -f | --force:                     force write without checking image
    -l | --layout <file.layout>:      read rom layout from file
    -i | --image <name>:              only flash image name from flash layout
+   -L | --list-supported:            print supported devices
+   -h | --help:                      print this help text
+   -R | --version:                   print the version (release)
 
  If no file is specified, then all that happens
  is that flash info is dumped and the flash chip is set to writable.




From peter at stuge.se  Sun Jan 11 04:31:29 2009
From: peter at stuge.se (Peter Stuge)
Date: Sun, 11 Jan 2009 04:31:29 +0100
Subject: [coreboot] [patch] update the readme of flashrom
In-Reply-To: <fdea27e40901101912n43f59b76l415abf96e26387ef@mail.gmail.com>
References: <fdea27e40901101912n43f59b76l415abf96e26387ef@mail.gmail.com>
Message-ID: <20090111033129.25708.qmail@stuge.se>

Idwer Vollering wrote:
> Mimicked from flashrom.c, see patch.
> 
> Signed-off-by: Idwer <vidwer at gmail.com>

Thanks! r3855


//Peter



From r.marek at assembler.cz  Sun Jan 11 16:12:43 2009
From: r.marek at assembler.cz (Rudolf Marek)
Date: Sun, 11 Jan 2009 16:12:43 +0100
Subject: [coreboot] We boot Windows XP,
	Windows Vista and Windows 7 (build 7000)
Message-ID: <496A0C6B.70609@assembler.cz>

Hello,

I'm pleased to announce that SeaBIOS and Coreboot can boot (and install) Windows 
7 build 7000, which was released as public beta yesterday.

There is also some video taken by mine Cannon G7 camera.

http://media.avc-cvut.cz/avc_vlastni_tvorba/2009/ruik/w7-coreboot/

Test platform: Asus M2V-MX SE, 512MB RAM, AMD Sempron on 2GHz.

Moreover I was able to boot/install there Windows Vista (Bussines, 64bit) and 
Windows XP.

Most patches are in, there is just one missing which I indicated in the previous 
email, http://www.coreboot.org/pipermail/coreboot/2008-December/043493.html

Kevin, can we sort this out?

Rudolf



From peter at stuge.se  Sun Jan 11 18:41:59 2009
From: peter at stuge.se (Peter Stuge)
Date: Sun, 11 Jan 2009 18:41:59 +0100
Subject: [coreboot] We boot Windows XP,
	Windows Vista and Windows 7	(build 7000)
In-Reply-To: <496A0C6B.70609@assembler.cz>
References: <496A0C6B.70609@assembler.cz>
Message-ID: <20090111174159.5804.qmail@stuge.se>

Rudolf Marek wrote:
> I'm pleased to announce that SeaBIOS and Coreboot can boot (and
> install) Windows 7 build 7000, which was released as public beta
> yesterday.

Very cool!

I've added a news entry and the videos to the wiki video page.


//Peter



From rminnich at gmail.com  Sun Jan 11 19:23:47 2009
From: rminnich at gmail.com (ron minnich)
Date: Sun, 11 Jan 2009 10:23:47 -0800
Subject: [coreboot] We boot Windows XP,
	Windows Vista and Windows 7 (build 7000)
In-Reply-To: <20090111174159.5804.qmail@stuge.se>
References: <496A0C6B.70609@assembler.cz> <20090111174159.5804.qmail@stuge.se>
Message-ID: <13426df10901111023q540fac61u499104953a2d848b@mail.gmail.com>

On Sun, Jan 11, 2009 at 9:41 AM, Peter Stuge <peter at stuge.se> wrote:
> Rudolf Marek wrote:
>> I'm pleased to announce that SeaBIOS and Coreboot can boot (and
>> install) Windows 7 build 7000, which was released as public beta
>> yesterday.
>
> Very cool!
>
> I've added a news entry and the videos to the wiki video page.
>

I wonder if we could get a "windows 7 certified" seal or some such to
put on the wiki?

ron



From r.marek at assembler.cz  Sun Jan 11 20:01:45 2009
From: r.marek at assembler.cz (Rudolf Marek)
Date: Sun, 11 Jan 2009 20:01:45 +0100
Subject: [coreboot] We boot Windows XP,
 Windows Vista and Windows 7 (build 7000)
In-Reply-To: <13426df10901111023q540fac61u499104953a2d848b@mail.gmail.com>
References: <496A0C6B.70609@assembler.cz> <20090111174159.5804.qmail@stuge.se>
	<13426df10901111023q540fac61u499104953a2d848b@mail.gmail.com>
Message-ID: <496A4219.9010309@assembler.cz>

> I wonder if we could get a "windows 7 certified" seal or some such to
> put on the wiki?

Hi, its bit more complicated, check:

http://www.microsoft.com/whdc/winlogo/hwrequirements.mspx

(check the snapshot)

Rudolf



From c-d.hailfinger.devel.2006 at gmx.net  Mon Jan 12 02:04:54 2009
From: c-d.hailfinger.devel.2006 at gmx.net (Carl-Daniel Hailfinger)
Date: Mon, 12 Jan 2009 02:04:54 +0100
Subject: [coreboot] We boot Windows XP,
 Windows Vista and Windows 7 (build 7000)
In-Reply-To: <496A4219.9010309@assembler.cz>
References: <496A0C6B.70609@assembler.cz>
	<20090111174159.5804.qmail@stuge.se>	<13426df10901111023q540fac61u499104953a2d848b@mail.gmail.com>
	<496A4219.9010309@assembler.cz>
Message-ID: <496A9736.9010303@gmx.net>

On 11.01.2009 20:01, Rudolf Marek wrote:
>> I wonder if we could get a "windows 7 certified" seal or some such to
>> put on the wiki?
>
> Hi, its bit more complicated, check:
>
> http://www.microsoft.com/whdc/winlogo/hwrequirements.mspx
>
> (check the snapshot)

I think the only requirement that's a bit difficult (conceptually, not
code-wise) right now on the coreboot side (without multiple payloads) is
SYSFUND-0071 sub-item "Provide a mechanism to enable and disable
user-accessible USB ports during POST (enabled by default)."
Some other requirements (SYSFUND-0049,SYSFUND-0050) may need tweaks to
audio codec initialization.
SYSFUND-0070 wants booting from UHCI and OHCI flash drives. I'm not
really sure whether that makes any sense to implement.

Generally, even with libpayload and SeaBIOS there are some things left
before we conform, but it is within reach.

If someone has time to check each requirement and confirm the status,
that would be great. I have to prepare for some more exams, so I'll be
relatively silent for the next few weeks.


Regards,
Carl-Daniel

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




From Qingpei.Wang at amd.com  Mon Jan 12 04:27:31 2009
From: Qingpei.Wang at amd.com (Wang, Qingpei)
Date: Mon, 12 Jan 2009 11:27:31 +0800
Subject: [coreboot] We boot Windows XP,
	Windows Vista and Windows 7 (build 7000)
In-Reply-To: <496A0C6B.70609@assembler.cz>
References: <496A0C6B.70609@assembler.cz>
Message-ID: <DD1CC71B621B004FA76856E5129D6B1701D7E8E3@sbjgexmb1.amd.com>

Is it booted by QEMU? Or real hardware?

Jason Wang
BeiJing Technology Development Center
Advanced Micro Devices (AMD)


-----Original Message-----
From: coreboot-bounces at coreboot.org
[mailto:coreboot-bounces at coreboot.org] On Behalf Of Rudolf Marek
Sent: Sunday, January 11, 2009 11:13 PM
To: Coreboot
Cc: Kevin O'Connor
Subject: [coreboot] We boot Windows XP,Windows Vista and Windows 7
(build 7000)

Hello,

I'm pleased to announce that SeaBIOS and Coreboot can boot (and install)
Windows 
7 build 7000, which was released as public beta yesterday.

There is also some video taken by mine Cannon G7 camera.

http://media.avc-cvut.cz/avc_vlastni_tvorba/2009/ruik/w7-coreboot/

Test platform: Asus M2V-MX SE, 512MB RAM, AMD Sempron on 2GHz.

Moreover I was able to boot/install there Windows Vista (Bussines,
64bit) and 
Windows XP.

Most patches are in, there is just one missing which I indicated in the
previous 
email,
http://www.coreboot.org/pipermail/coreboot/2008-December/043493.html

Kevin, can we sort this out?

Rudolf

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





From peter at stuge.se  Mon Jan 12 05:24:27 2009
From: peter at stuge.se (Peter Stuge)
Date: Mon, 12 Jan 2009 05:24:27 +0100
Subject: [coreboot] We boot Windows XP,
	Windows Vista and Windows 7	(build 7000)
In-Reply-To: <DD1CC71B621B004FA76856E5129D6B1701D7E8E3@sbjgexmb1.amd.com>
References: <496A0C6B.70609@assembler.cz>
	<DD1CC71B621B004FA76856E5129D6B1701D7E8E3@sbjgexmb1.amd.com>
Message-ID: <20090112042427.8804.qmail@stuge.se>

Wang, Qingpei wrote:
> Is it booted by QEMU? Or real hardware?

Real hardware. Have a look at the video here:
http://www.coreboot.org/Screenshots#coreboot_and_SeaBIOS_starting_Windows_7

It's an ASUS M2V-MX SE with an AMD Sempron CPU. This board has a VIA
K8T890 chipset.


//Peter



From JasonZhao at viatech.com.cn  Mon Jan 12 07:40:06 2009
From: JasonZhao at viatech.com.cn (JasonZhao at viatech.com.cn)
Date: Mon, 12 Jan 2009 14:40:06 +0800
Subject: [coreboot] v3 bug report: Error base address register of UART in
	vt1211
Message-ID: <9156F9F8217CD44898ABE1E581FAFF882FB89E@exchbj02.viatech.com.bj>

Hi Carl,
I find a bug need to fix in superior/via/vt1211/Stage1.c 
	rawpnp_set_iobase(dev, 2, (iobase >> 2) & 0xff); 
    should be
    	rawpnp_set_iobase(dev, 0x60, ((iobase >> 2) & 0xff)<<8);
    according the spec of VT1211.
It seems that vt1211 only define the Rx60 for LOW address of UART
base,and Rx61 is not used at all.
However
-jasonzhao 



From engineerguy3737 at yahoo.com  Mon Jan 12 09:02:14 2009
From: engineerguy3737 at yahoo.com (Dan Lykowski)
Date: Mon, 12 Jan 2009 00:02:14 -0800 (PST)
Subject: [coreboot] [patch] Proposed patch for FIDVID question
Message-ID: <916783.43144.qm@web57003.mail.re3.yahoo.com>

Second attempt with the spaces fixed.



Signed-off-by: Dan Lykowski <lykowdk at gmail.com>


Dan Lykowski

--- On Thu, 1/8/09, Bao, Zheng <Zheng.Bao at amd.com> wrote:

From: Bao, Zheng <Zheng.Bao at amd.com>
Subject: Re: [coreboot] [patch] Proposed patch for FIDVID question
To: "Dan Lykowski" <engineerguy3737 at yahoo.com>, "Marc Jones" <marcj303 at gmail.com>
Cc: "Coreboot" <coreboot at coreboot.org>
Date: Thursday, January 8, 2009, 9:44 PM

It works on dbm690t and pistachio. Please note some indents are spaces instead of tabs. Please correct it.

Zheng

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




      
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20090112/90231a77/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: add_fidvid_support_check.patch
Type: text/x-patch
Size: 4474 bytes
Desc: not available
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20090112/90231a77/attachment.patch>

From engineerguy3737 at yahoo.com  Mon Jan 12 09:21:39 2009
From: engineerguy3737 at yahoo.com (Dan Lykowski)
Date: Mon, 12 Jan 2009 00:21:39 -0800 (PST)
Subject: [coreboot] [patch] Add missing FID support check in raminit_f.c
Message-ID: <958275.14497.qm@web57008.mail.re3.yahoo.com>

Added FID check in raminit_f.c.
Same problem that was fixed by my last patch just in a different location. 
Trying to read MSR(0xC0010042) causes a GP fault on a processor that does not support changing FIDVID.

I believe that if the FID support check fails the startup FID should be used. 
It can be read from MSR(0xC0010015).

Thanks,
Dan Lykowski

Signed-off-by: Dan Lykowski <lykowdk at gmail.com>

---



      
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20090112/7e4dd644/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: add_fid_support_check.patch
Type: text/x-patch
Size: 897 bytes
Desc: not available
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20090112/7e4dd644/attachment.patch>

From eaglesoldier at dishmail.net  Mon Jan 12 02:51:52 2009
From: eaglesoldier at dishmail.net ((Eaglesoldier) Duane Simpson)
Date: Sun, 11 Jan 2009 17:51:52 -0800
Subject: [coreboot] Information request
Message-ID: <496AA238.4010606@dishmail.net>

Hi,
    I really am interested in your bios upgrade for linux but am not a 
programmer, only proficient in pasting into terminal and many times 
don't fully understand what is taking place, in other words, a complete 
newbie.
    For those like me, is there anyone in your database of developers 
that will make a bios for my specific computer? The reason for the 
upgrade is when I first turn it on it gives me the message; the system 
does not meet the cutoff date (year 2000) or something similar and then 
continues with the loading. Although there are no major problems, I have 
minor glitches with mouse functions, and some video doesn't play, 
although I have all the codecs loaded to run them. I would like to know 
if doing a bios upgrade could fix some of these problems, and the main 
reason is to break my dependency on proprietary software. I have an 
older system, purchased in 1998, and my wife's computer was bought in 
1999, I know it's not cutting edge, more like ancient, but I would like 
to keep it running the best I can for as long as possible. It isn't much 
but it works and it's all I have.
    As I said, I don't know alot about my computer, but if I can be told 
where to find the information about the computer motherboard, the bios 
(amibios) don't know any version, so would need to find that, and 
complete information about the best way to make the bios change to best 
serve my system configuration. If I indeed need to build a bios chip for 
my system, is there service to help walk me through the process step by 
step if needed, including how to build and use any tools that are 
required and how to test the finished product. I have looked at some of 
the tutorials and what may be required and can definitely say that what 
would stop me at first is fear of the unknown, as it would entail more 
than I have ever attempted before.
    I realize this is a long email, but it needed to be due to my 
limited experience. I am only hoping that someone with knowledge gained 
will remember how at some point in their learning experience they needed 
personal help of a similar nature.
    I thank you for any help that you may provide, and will wait for 
your reply. Duane L Simpson



From rminnich at gmail.com  Mon Jan 12 17:09:02 2009
From: rminnich at gmail.com (ron minnich)
Date: Mon, 12 Jan 2009 08:09:02 -0800
Subject: [coreboot] v3 bug report: Error base address register of UART
	in vt1211
In-Reply-To: <9156F9F8217CD44898ABE1E581FAFF882FB89E@exchbj02.viatech.com.bj>
References: <9156F9F8217CD44898ABE1E581FAFF882FB89E@exchbj02.viatech.com.bj>
Message-ID: <13426df10901120809w6b5bbef8ibb5b7136f7d5f184@mail.gmail.com>

On Sun, Jan 11, 2009 at 10:40 PM,  <JasonZhao at viatech.com.cn> wrote:
> Hi Carl,
> I find a bug need to fix in superior/via/vt1211/Stage1.c
>        rawpnp_set_iobase(dev, 2, (iobase >> 2) & 0xff);
>    should be
>        rawpnp_set_iobase(dev, 0x60, ((iobase >> 2) & 0xff)<<8);

I Understand the 0x60. I don't understand this part:
((iobase >> 2) & 0xff)<<8)

Is that correct? Not just (iobase >> 8)&0xff (although the &0xff is
not really needed)

thanks

ron



From svn at coreboot.org  Mon Jan 12 17:16:08 2009
From: svn at coreboot.org (svn at coreboot.org)
Date: Mon, 12 Jan 2009 17:16:08 +0100
Subject: [coreboot] r3856 - in trunk/coreboot-v2/src/mainboard/amd: dbm690t
	pistachio serengeti_cheetah
Message-ID: <mailman.2662.1355071468.16123.coreboot@coreboot.org>

Author: mjones
Date: 2009-01-12 17:16:08 +0100 (Mon, 12 Jan 2009)
New Revision: 3856

Modified:
   trunk/coreboot-v2/src/mainboard/amd/dbm690t/cache_as_ram_auto.c
   trunk/coreboot-v2/src/mainboard/amd/pistachio/cache_as_ram_auto.c
   trunk/coreboot-v2/src/mainboard/amd/serengeti_cheetah/cache_as_ram_auto.c
Log:
Check to see if K8 processor is capable of changing FIDVID otherwise it will throw a GP# when reading FIDVID_STATUS

Signed-off-by: Dan Lykowski <lykowdk at gmail.com>
Acked-by: Zheng Bao <zheng.bao at amd.com>

Modified: trunk/coreboot-v2/src/mainboard/amd/dbm690t/cache_as_ram_auto.c
===================================================================
--- trunk/coreboot-v2/src/mainboard/amd/dbm690t/cache_as_ram_auto.c	2009-01-11 03:31:02 UTC (rev 3855)
+++ trunk/coreboot-v2/src/mainboard/amd/dbm690t/cache_as_ram_auto.c	2009-01-12 16:16:08 UTC (rev 3856)
@@ -161,6 +161,7 @@
 	int needs_reset = 0;
 	u32 bsp_apicid = 0;
 	msr_t msr;
+	struct cpuid_result cpuid1;
 	struct sys_info *sysinfo = (struct sys_info *)(DCACHE_RAM_BASE + DCACHE_RAM_SIZE - DCACHE_RAM_GLOBAL_VAR_SIZE);
 
 
@@ -197,17 +198,27 @@
 	rs690_early_setup();
 	sb600_early_setup();
 
-	msr=rdmsr(0xc0010042);
-	printk_debug("begin msr fid, vid: hi=0x%x, lo=0x%x\n", msr.hi, msr.lo);
+	/* Check to see if processor is capable of changing FIDVID  */
+	/* otherwise it will throw a GP# when reading FIDVID_STATUS */
+	cpuid1 = cpuid(0x80000007);
+	if( (cpuid1.edx & 0x6) == 0x6 ) {
 
-	enable_fid_change();
-	enable_fid_change_on_sb(sysinfo->sbbusn, sysinfo->sbdn);
-	init_fidvid_bsp(bsp_apicid);
+		/* Read FIDVID_STATUS */
+		msr=rdmsr(0xc0010042);
+		printk_debug("begin msr fid, vid: hi=0x%x, lo=0x%x\n", msr.hi, msr.lo);
 
-	/* show final fid and vid */
-	msr=rdmsr(0xc0010042);
-	printk_debug("end msr fid, vid: hi=0x%x, lo=0x%x\n", msr.hi, msr.lo);
+		enable_fid_change();
+		enable_fid_change_on_sb(sysinfo->sbbusn, sysinfo->sbdn);
+		init_fidvid_bsp(bsp_apicid);
 
+		/* show final fid and vid */
+		msr=rdmsr(0xc0010042);
+		printk_debug("end msr fid, vid: hi=0x%x, lo=0x%x\n", msr.hi, msr.lo);
+
+	} else {
+		printk_debug("Changing FIDVID not supported\n");
+	}
+
 	needs_reset = optimize_link_coherent_ht();
 	needs_reset |= optimize_link_incoherent_ht(sysinfo);
 	rs690_htinit();

Modified: trunk/coreboot-v2/src/mainboard/amd/pistachio/cache_as_ram_auto.c
===================================================================
--- trunk/coreboot-v2/src/mainboard/amd/pistachio/cache_as_ram_auto.c	2009-01-11 03:31:02 UTC (rev 3855)
+++ trunk/coreboot-v2/src/mainboard/amd/pistachio/cache_as_ram_auto.c	2009-01-12 16:16:08 UTC (rev 3856)
@@ -155,6 +155,7 @@
 	int needs_reset = 0;
 	u32 bsp_apicid = 0;
 	msr_t msr;
+	struct cpuid_result cpuid1;
 	struct sys_info *sysinfo =
 	    (struct sys_info *)(DCACHE_RAM_BASE + DCACHE_RAM_SIZE -
 				DCACHE_RAM_GLOBAL_VAR_SIZE);
@@ -198,17 +199,27 @@
 
 	post_code(0x04);
 
-	msr = rdmsr(0xc0010042);
-	printk_debug("begin msr fid, vid: hi=0x%x, lo=0x%x\n", msr.hi, msr.lo);
+	/* Check to see if processor is capable of changing FIDVID  */
+	/* otherwise it will throw a GP# when reading FIDVID_STATUS */
+	cpuid1 = cpuid(0x80000007);
+	if( (cpuid1.edx & 0x6) == 0x6 ) {
 
-	enable_fid_change();
-	enable_fid_change_on_sb(sysinfo->sbbusn, sysinfo->sbdn);
-	init_fidvid_bsp(bsp_apicid);
+		/* Read FIDVID_STATUS */
+		msr=rdmsr(0xc0010042);
+		printk_debug("begin msr fid, vid: hi=0x%x, lo=0x%x\n", msr.hi, msr.lo);
 
-	// show final fid and vid
-	msr = rdmsr(0xc0010042);
-	printk_debug("end msr fid, vid: hi=0x%x, lo=0x%x\n", msr.hi, msr.lo);
+		enable_fid_change();
+		enable_fid_change_on_sb(sysinfo->sbbusn, sysinfo->sbdn);
+		init_fidvid_bsp(bsp_apicid);
 
+		/* show final fid and vid */
+		msr=rdmsr(0xc0010042);
+		printk_debug("end msr fid, vid: hi=0x%x, lo=0x%x\n", msr.hi, msr.lo);
+
+	} else {
+		printk_debug("Changing FIDVID not supported\n");
+	}
+
 	post_code(0x05);
 
 	needs_reset = optimize_link_coherent_ht();

Modified: trunk/coreboot-v2/src/mainboard/amd/serengeti_cheetah/cache_as_ram_auto.c
===================================================================
--- trunk/coreboot-v2/src/mainboard/amd/serengeti_cheetah/cache_as_ram_auto.c	2009-01-11 03:31:02 UTC (rev 3855)
+++ trunk/coreboot-v2/src/mainboard/amd/serengeti_cheetah/cache_as_ram_auto.c	2009-01-12 16:16:08 UTC (rev 3856)
@@ -259,6 +259,7 @@
 
         int needs_reset; int i;
         unsigned bsp_apicid = 0;
+	struct cpuid_result cpuid1;
 
         if (bist == 0) {
 		bsp_apicid = init_cpus(cpu_init_detectedx, sysinfo);
@@ -311,8 +312,13 @@
 #endif
 
 #if K8_SET_FIDVID == 1
+	/* Check to see if processor is capable of changing FIDVID  */
+	/* otherwise it will throw a GP# when reading FIDVID_STATUS */
+	cpuid1 = cpuid(0x80000007);
+	if( (cpuid1.edx & 0x6) == 0x6 ) {
 
         {
+		/* Read FIDVID_STATUS */
                 msr_t msr;
                 msr=rdmsr(0xc0010042);
                 print_debug("begin msr fid, vid "); print_debug_hex32( msr.hi ); print_debug_hex32(msr.lo); print_debug("\r\n");
@@ -332,6 +338,11 @@
                 print_debug("end   msr fid, vid "); print_debug_hex32( msr.hi ); print_debug_hex32(msr.lo); print_debug("\r\n"); 
 
         }
+
+	} else {
+		print_debug("Changing FIDVID not supported\n");
+	}
+
 #endif
 
 #if 1




From marcj303 at gmail.com  Mon Jan 12 17:16:29 2009
From: marcj303 at gmail.com (Marc Jones)
Date: Mon, 12 Jan 2009 09:16:29 -0700
Subject: [coreboot] [patch] Proposed patch for FIDVID question
In-Reply-To: <916783.43144.qm@web57003.mail.re3.yahoo.com>
References: <916783.43144.qm@web57003.mail.re3.yahoo.com>
Message-ID: <534e5dc20901120816t5ad8626am68ad0f08621914fc@mail.gmail.com>

On Mon, Jan 12, 2009 at 1:02 AM, Dan Lykowski <engineerguy3737 at yahoo.com> wrote:
> Second attempt with the spaces fixed.
>
> Signed-off-by: Dan Lykowski <lykowdk at gmail.com>
>
> Dan Lykowski

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

r3856

Thanks,
Marc



From chris at stockwith.co.uk  Mon Jan 12 17:52:17 2009
From: chris at stockwith.co.uk (Chris Lingard)
Date: Mon, 12 Jan 2009 16:52:17 +0000
Subject: [coreboot] DFI LANPARTY NF4 SLI
In-Reply-To: <1231497396.7481.1.camel@localhost.localdomain>
References: <1231154992.14529.6.camel@localhost.localdomain>	
	<49621F3D.7060103@stockwith.co.uk>
	<1231497396.7481.1.camel@localhost.localdomain>
Message-ID: <496B7541.9060703@stockwith.co.uk>

lambros galanis wrote:
> I think my motherboard has the CK804 chipset

These are used by the coreboot project

See

http://www.coreboot.org/Tyan_S2891#Hardware

and

http://www.coreboot.org/pipermail/linuxbios/2007-September/024937.html

I am not at all experienced with coreboot to give you advice.  My DFI 
motherboard had an identical chip set to a Gigabyte M57SLI, so I just 
used that code.  You could try looking at the Tyan stuff, to see what 
corresponds

I am pretty sure your BIOS chip is a Pm49FL004, is so, that is good, 
because you can get some SST49LF160 chips, and this gives you a 16M bit 
chip instead of the standard 4M bit.

Perhaps if you identified what chip set it uses, one of the experts 
might help

Chris Lingard




From rminnich at gmail.com  Mon Jan 12 18:05:13 2009
From: rminnich at gmail.com (ron minnich)
Date: Mon, 12 Jan 2009 09:05:13 -0800
Subject: [coreboot] SCALE
Message-ID: <13426df10901120905y467dd40at3a6db1522dad668f@mail.gmail.com>

OK, this is the first of several calls for help. I'm time-starved
right now as I have things I have to get working on BG/P, my day job
;-)

I'd like to have the 5 second "boot to X" demo at the table. If
somebody can help direct me to getting that set up, I'd appreciate it.
I will probably do this on a dmb690t mobo (marc? What kind of 1M flash
part do I use?). I want to have a "naked mainboard" for the demo.

I'm going to have a v3 demo; artec guys, I think I've asked this but
... what would you like to see.

can someone put this in a nice place on the wiki:
http://scale7x.socallinuxexpo.org/conference-info/banners-and-promos.

For the talk I'm going to show how to use v2, then v3, then seabios,
then buildrom.

I'm happy to lay out promotional material on the table if you send it
to me in time. We've got 5 weeks left. One thing that comes to mind is
the AMD Embedded initiative with the pointer to the coreboot page.
VIA, do you have any paper for me to hand out?

once again, any of you who want to help are most welcome.

thanks

ron



From joe at settoplinux.org  Mon Jan 12 19:14:07 2009
From: joe at settoplinux.org (Joseph Smith)
Date: Mon, 12 Jan 2009 13:14:07 -0500
Subject: [coreboot] SCALE
In-Reply-To: <13426df10901120905y467dd40at3a6db1522dad668f@mail.gmail.com>
References: <13426df10901120905y467dd40at3a6db1522dad668f@mail.gmail.com>
Message-ID: <f25959e0f4d03a76a343d4c7a438e352@imap.1and1.com>


> I'm happy to lay out promotional material on the table if you send it
> to me in time. We've got 5 weeks left. One thing that comes to mind is
> the AMD Embedded initiative with the pointer to the coreboot page.
This would be great! Good eye catcher for people browsing by :-)

I would be glad to print out a bunch of coreboot logo stickers and send
them to you. Just let me know.

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




From marcj303 at gmail.com  Mon Jan 12 19:30:22 2009
From: marcj303 at gmail.com (Marc Jones)
Date: Mon, 12 Jan 2009 11:30:22 -0700
Subject: [coreboot] SCALE
In-Reply-To: <13426df10901120905y467dd40at3a6db1522dad668f@mail.gmail.com>
References: <13426df10901120905y467dd40at3a6db1522dad668f@mail.gmail.com>
Message-ID: <534e5dc20901121030l6ecd86c2o78b021c98d60ee97@mail.gmail.com>

On Mon, Jan 12, 2009 at 10:05 AM, ron minnich <rminnich at gmail.com> wrote:
> OK, this is the first of several calls for help. I'm time-starved
> right now as I have things I have to get working on BG/P, my day job
> ;-)
>
> I'd like to have the 5 second "boot to X" demo at the table. If
> somebody can help direct me to getting that set up, I'd appreciate it.
> I will probably do this on a dmb690t mobo (marc? What kind of 1M flash
> part do I use?). I want to have a "naked mainboard" for the demo.
>
 SST49LF080A - 8 Mbit LPC Flash PLCC or similar should work.

Marc



From peter at stuge.se  Mon Jan 12 20:55:57 2009
From: peter at stuge.se (Peter Stuge)
Date: Mon, 12 Jan 2009 20:55:57 +0100
Subject: [coreboot] SCALE
In-Reply-To: <13426df10901120905y467dd40at3a6db1522dad668f@mail.gmail.com>
References: <13426df10901120905y467dd40at3a6db1522dad668f@mail.gmail.com>
Message-ID: <20090112195557.20579.qmail@stuge.se>

ron minnich wrote:
> I'd like to have the 5 second "boot to X" demo at the table. If
> somebody can help direct me to getting that set up, I'd appreciate
> it.

If you don't want to cram everything into a 16Mbit flash chip, which
could be tight, you need some ATA flash to store apps on.

Since the dbm690 has an LPC PLCC socket you can use the dongle and my
adapter plug though, that way you have 32Mbit which is already more
roomy.

Maybe the dongle occupied for the ALIX already?


//Peter



From svn at coreboot.org  Mon Jan 12 22:00:35 2009
From: svn at coreboot.org (svn at coreboot.org)
Date: Mon, 12 Jan 2009 22:00:35 +0100
Subject: [coreboot] r3857 - trunk/util/flashrom
Message-ID: <mailman.2663.1355071469.16123.coreboot@coreboot.org>

Author: stuge
Date: 2009-01-12 22:00:35 +0100 (Mon, 12 Jan 2009)
New Revision: 3857

Modified:
   trunk/util/flashrom/flashrom.c
   trunk/util/flashrom/layout.c
Log:
flashrom: Check return value of fscanf()/fwrite()/fread()

Fix build error on distros with warn_unused_result attributes in glibc.

Signed-off-by: Peter Stuge <peter at stuge.se>
Acked-by: Yul Rottmann <yulrottmann at bitel.net>


Modified: trunk/util/flashrom/flashrom.c
===================================================================
--- trunk/util/flashrom/flashrom.c	2009-01-12 16:16:08 UTC (rev 3856)
+++ trunk/util/flashrom/flashrom.c	2009-01-12 21:00:35 UTC (rev 3857)
@@ -296,7 +296,7 @@
 int main(int argc, char *argv[])
 {
 	uint8_t *buf;
-	unsigned long size;
+	unsigned long size, numbytes;
 	uint32_t erasedbytes;
 	FILE *image;
 	/* Probe for up to three flash chips. */
@@ -517,11 +517,11 @@
 				       exclude_end_position -
 				       exclude_start_position);
 
-			fwrite(buf, sizeof(char), size, image);
+			numbytes = fwrite(buf, 1, size, image);
 			fclose(image);
-			printf("done.\n");
+			printf("%s.\n", numbytes == size ? "done" : "FAILED");
 			free(buf);
-			exit(0);
+			return numbytes != size;
 		}
 		// FIXME: flash writes stay enabled!
 		exit(1);
@@ -615,9 +615,11 @@
 			memset(buf + exclude_start_position, 0,
 			       exclude_end_position - exclude_start_position);
 
-		fwrite(buf, sizeof(char), size, image);
+		numbytes = fwrite(buf, 1, size, image);
 		fclose(image);
-		printf("done.\n");
+		printf("%s.\n", numbytes == size ? "done" : "FAILED");
+		if (numbytes != size)
+			return 1;
 	} else {
 		struct stat image_stat;
 
@@ -634,9 +636,13 @@
 			exit(1);
 		}
 
-		fread(buf, sizeof(char), size, image);
+		numbytes = fread(buf, 1, size, image);
 		show_id(buf, size, force);
 		fclose(image);
+		if (numbytes != size) {
+			fprintf(stderr, "Error: Failed to read file. Got %ld bytes, wanted %ld!\n", numbytes, size);
+			return 1;
+		}
 	}
 
 	/* exclude range stuff. Nice idea, but at the moment it is only

Modified: trunk/util/flashrom/layout.c
===================================================================
--- trunk/util/flashrom/layout.c	2009-01-12 16:16:08 UTC (rev 3856)
+++ trunk/util/flashrom/layout.c	2009-01-12 21:00:35 UTC (rev 3857)
@@ -146,8 +146,8 @@
 
 	while (!feof(romlayout)) {
 		char *tstr1, *tstr2;
-		fscanf(romlayout, "%s %s\n", tempstr,
-		       rom_entries[romimages].name);
+		if (2 != fscanf(romlayout, "%s %s\n", tempstr, rom_entries[romimages].name))
+			continue;
 #if 0
 		// fscanf does not like arbitrary comments like that :( later
 		if (tempstr[0] == '#') {




From engineerguy3737 at yahoo.com  Mon Jan 12 22:03:18 2009
From: engineerguy3737 at yahoo.com (Dan Lykowski)
Date: Mon, 12 Jan 2009 13:03:18 -0800 (PST)
Subject: [coreboot] SCALE
Message-ID: <71148.85253.qm@web57002.mail.re3.yahoo.com>

I would suggest this part:
http://www.innodisk.com/flashstorage_specification.jsp?flashid=29
They plug right in to the SATA port.
They have a minor quirk where you have to 'force.libata=1:1.5g' to get them to work under Linux but that is the only negative I have run across so far.

Dan Lykowski

--- On Mon, 1/12/09, Peter Stuge <peter at stuge.se> wrote:

From: Peter Stuge <peter at stuge.se>
Subject: Re: [coreboot] SCALE
To: coreboot at coreboot.org
Date: Monday, January 12, 2009, 2:55 PM


-----Inline Attachment Follows-----

ron minnich wrote:
> I'd like to have the 5 second "boot to X" demo at the table. If
> somebody can help direct me to getting that set up, I'd appreciate
> it.

If you don't want to cram everything into a 16Mbit flash chip, which
could be tight, you need some ATA flash to store apps on.

Since the dbm690 has an LPC PLCC socket you can use the dongle and my
adapter plug though, that way you have 32Mbit which is already more
roomy.

Maybe the dongle occupied for the ALIX already?


//Peter

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



      
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20090112/4d1f3e15/attachment.html>

From svn at coreboot.org  Mon Jan 12 22:28:03 2009
From: svn at coreboot.org (svn at coreboot.org)
Date: Mon, 12 Jan 2009 22:28:03 +0100
Subject: [coreboot] r3858 - trunk/util/flashrom
Message-ID: <mailman.2664.1355071469.16123.coreboot@coreboot.org>

Author: stuge
Date: 2009-01-12 22:28:03 +0100 (Mon, 12 Jan 2009)
New Revision: 3858

Modified:
   trunk/util/flashrom/it87spi.c
Log:
flashrom: IT8718F works just like IT8716F.

Signed-off-by: Peter Stuge <peter at stuge.se>
Acked-by: Yul Rottmann <yulrottmann at bitel.net>


Modified: trunk/util/flashrom/it87spi.c
===================================================================
--- trunk/util/flashrom/it87spi.c	2009-01-12 21:00:35 UTC (rev 3857)
+++ trunk/util/flashrom/it87spi.c	2009-01-12 21:28:03 UTC (rev 3858)
@@ -80,7 +80,7 @@
 	id |= regval(port, CHIP_ID_BYTE2_REG);
 
 	/* TODO: Handle more IT87xx if they support flash translation */
-	if (id == 0x8716) {
+	if (0x8716 == id || 0x8718 == id) {
 		/* NOLDN, reg 0x24, mask out lowest bit (suspend) */
 		tmp = regval(port, 0x24) & 0xFE;
 		printf("Serial flash segment 0x%08x-0x%08x %sabled\n",




From svn at coreboot.org  Mon Jan 12 22:31:15 2009
From: svn at coreboot.org (svn at coreboot.org)
Date: Mon, 12 Jan 2009 22:31:15 +0100
Subject: [coreboot] r3859 - trunk/util/flashrom
Message-ID: <mailman.2665.1355071469.16123.coreboot@coreboot.org>

Author: stuge
Date: 2009-01-12 22:31:14 +0100 (Mon, 12 Jan 2009)
New Revision: 3859

Modified:
   trunk/util/flashrom/board_enable.c
Log:
flashrom: Board enable for GIGABYTE GA-MA78G-DS3H

This board has 2x MX25L8005 flash chips behind an IT8718F LPC->SPI bridge.
The board uses GIGABYTE's patented BIOS failover technology, and at this point
we do not know how to control which of the two chips flashrom actually hits.

Signed-off-by: Peter Stuge <peter at stuge.se>
Acked-by: Yul Rottmann <yulrottmann at bitel.net>


Modified: trunk/util/flashrom/board_enable.c
===================================================================
--- trunk/util/flashrom/board_enable.c	2009-01-12 21:28:03 UTC (rev 3858)
+++ trunk/util/flashrom/board_enable.c	2009-01-12 21:31:14 UTC (rev 3859)
@@ -634,6 +634,8 @@
 	 "gigabyte", "m57sli", "GIGABYTE GA-M57SLI-S4", it87xx_probe_spi_flash},
 	{0x10de, 0x03e0, 0x0000, 0x0000, 0x0000, 0x0000, 0x0000, 0x0000,
 	 "gigabyte", "m61p", "GIGABYTE GA-M61P-S3", it87xx_probe_spi_flash},
+	{0x1002, 0x4398, 0x1458, 0x5004, 0x1002, 0x4385, 0x1458, 0x4385,
+	 NULL, NULL, "GIGABYTE GA-MA78G-DS3H", it87xx_probe_spi_flash},
 	{0x1039, 0x0761, 0x0000, 0x0000, 0x0000, 0x0000, 0x0000, 0x0000,
 	 "gigabyte", "2761gxdk", "GIGABYTE GA-2761GXDK", it87xx_probe_spi_flash},
 	{0x1022, 0x7468, 0x0000, 0x0000, 0x0000, 0x0000, 0x0000, 0x0000,




From tsylla at gmail.com  Mon Jan 12 22:45:19 2009
From: tsylla at gmail.com (Tom Sylla)
Date: Mon, 12 Jan 2009 16:45:19 -0500
Subject: [coreboot] SCALE
In-Reply-To: <71148.85253.qm@web57002.mail.re3.yahoo.com>
References: <71148.85253.qm@web57002.mail.re3.yahoo.com>
Message-ID: <57947bf80901121345j5e5dd3bcte22ca072e347c773@mail.gmail.com>

Do most normal motherboards supply +5V on pin 7 of their SATA
connectors to make this work?

Are you using them on an off-the-shelf motherboard?

This looks like something intended for an embedded design, where you
make your connector a non-standard pinout to support it.


On Mon, Jan 12, 2009 at 4:03 PM, Dan Lykowski <engineerguy3737 at yahoo.com> wrote:
> I would suggest this part:
> http://www.innodisk.com/flashstorage_specification.jsp?flashid=29
> They plug right in to the SATA port.
> They have a minor quirk where you have to 'force.libata=1:1.5g' to get them
> to work under Linux but that is the only negative I have run across so far.
>
> Dan Lykowski
>
> --- On Mon, 1/12/09, Peter Stuge <peter at stuge.se> wrote:
>
> From: Peter Stuge <peter at stuge.se>
> Subject: Re: [coreboot] SCALE
> To: coreboot at coreboot.org
> Date: Monday, January 12, 2009, 2:55 PM
>
>
> -----Inline Attachment Follows-----
>
> ron minnich wrote:
>> I'd like to have the 5 second "boot to X" demo at the table. If
>> somebody can help direct me to getting that set up, I'd appreciate
>> it.
>
> If you don't want to cram everything into a 16Mbit flash chip, which
> could be tight, you need some ATA flash to store apps on.
>
> Since the dbm690 has an LPC PLCC socket you can use the dongle and my
> adapter plug though, that way you have 32Mbit which is already more
> roomy.
>
> Maybe the dongle occupied for the ALIX already?
>
>
> //Peter
>
> --
> coreboot mailing list: coreboot at coreboot.org
> http://www.coreboot.org/mailman/listinfo/coreboot
>
>
> --
> coreboot mailing list: coreboot at coreboot.org
> http://www.coreboot.org/mailman/listinfo/coreboot
>



From engineerguy3737 at yahoo.com  Mon Jan 12 23:31:56 2009
From: engineerguy3737 at yahoo.com (Dan Lykowski)
Date: Mon, 12 Jan 2009 14:31:56 -0800 (PST)
Subject: [coreboot] SCALE
Message-ID: <115709.8576.qm@web57008.mail.re3.yahoo.com>

The manufacturer makes them in a number of form factors. 
In the form I have on hand, it plugs right in to a standard motherboard SATA slot without a cable. I have to connect an external +5V supply from the power supply.

Dan Lykowski

--- On Mon, 1/12/09, Tom Sylla <tsylla at gmail.com> wrote:

From: Tom Sylla <tsylla at gmail.com>
Subject: Re: [coreboot] SCALE
To: "Dan Lykowski" <engineerguy3737 at yahoo.com>
Cc: "Peter Stuge" <peter at stuge.se>, coreboot at coreboot.org
Date: Monday, January 12, 2009, 4:45 PM


-----Inline Attachment Follows-----

Do most normal motherboards supply +5V on pin 7 of their SATA
connectors to make this work?

Are you using them on an off-the-shelf motherboard?

This looks like something intended for an embedded design, where you
make your connector a non-standard pinout to support it.


On Mon, Jan 12, 2009 at 4:03 PM, Dan Lykowski <engineerguy3737 at yahoo.com> wrote:
> I would suggest this part:
> http://www.innodisk.com/flashstorage_specification.jsp?flashid=29
> They plug right in to the SATA port.
> They have a minor quirk where you have to 'force.libata=1:1.5g' to get them
> to work under Linux but that is the only negative I have run across so far.
>
> Dan Lykowski
>
> --- On Mon, 1/12/09, Peter Stuge <peter at stuge.se> wrote:
>
> From: Peter Stuge <peter at stuge.se>
> Subject: Re: [coreboot] SCALE
> To: coreboot at coreboot.org
> Date: Monday, January 12, 2009, 2:55 PM
>
>
> -----Inline Attachment Follows-----
>
> ron minnich wrote:
>> I'd like to have the 5 second "boot to X" demo at the table. If
>> somebody can help direct me to getting that set up, I'd appreciate
>> it.
>
> If you don't want to cram everything into a 16Mbit flash chip, which
> could be tight, you need some ATA flash to store apps on.
>
> Since the dbm690 has an LPC PLCC socket you can use the dongle and my
> adapter plug though, that way you have 32Mbit which is already more
> roomy.
>
> Maybe the dongle occupied for the ALIX already?
>
>
> //Peter
>
> --
> coreboot mailing list: coreboot at coreboot.org
> http://www.coreboot.org/mailman/listinfo/coreboot
>
>
> --
> coreboot mailing list: coreboot at coreboot.org
> http://www.coreboot.org/mailman/listinfo/coreboot
>

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



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

From kevin at koconnor.net  Mon Jan 12 23:15:44 2009
From: kevin at koconnor.net (Kevin O'Connor)
Date: Mon, 12 Jan 2009 17:15:44 -0500
Subject: [coreboot] We boot Windows XP,
	Windows Vista and Windows 7	(build 7000)
In-Reply-To: <496A0C6B.70609@assembler.cz>
References: <496A0C6B.70609@assembler.cz>
Message-ID: <20090112221544.GA17965@morn.localdomain>

On Sun, Jan 11, 2009 at 04:12:43PM +0100, Rudolf Marek wrote:
> Hello,
>
> I'm pleased to announce that SeaBIOS and Coreboot can boot (and install) 
> Windows 7 build 7000, which was released as public beta yesterday.

Great news!

> Most patches are in, there is just one missing which I indicated in the 
> previous email, 
> http://www.coreboot.org/pipermail/coreboot/2008-December/043493.html
>
> Kevin, can we sort this out?

I believe the SeaBIOS code is fully synched up with your code.  So, I
guess the only things left are the changes to coreboot.

It would be great if someone could enhance coreboot to have an option
for storing the bios tables in high memory or at 0xf0000.  We've had
to manually hardcode the top-of-ram in the src/arch/i386/boot/tables.c
file - I think this should be automatically done when the appropriate
option is set.

-Kevin



From uwe at hermann-uwe.de  Mon Jan 12 23:38:13 2009
From: uwe at hermann-uwe.de (Uwe Hermann)
Date: Mon, 12 Jan 2009 23:38:13 +0100
Subject: [coreboot] [PATCH] v1: Add license headers to AMD AMD-768 code
In-Reply-To: <m1zli1xko9.fsf@frodo.ebiederm.org>
References: <20090108175314.GA22435@greenwood>
	<m1zli1xko9.fsf@frodo.ebiederm.org>
Message-ID: <20090112223813.GB9820@greenwood>

On Thu, Jan 08, 2009 at 06:44:38PM -0800, Eric W. Biederman wrote:
> Uwe Hermann <uwe at hermann-uwe.de> writes:
> 
> > Yay, my first v1 patch :)
> >
> > Eric, any other code chunks which were mostly/entirely written by you
> > where we can slap a GPLv2 header on? AMD-766, others?
> >
> > Btw, was this code from 2003 (C) Eric W. Biederman or rather (C) LNXI?
> 
> Always a fuzzy line that.  If we care how about we slap both on, and
> not worry to much about the details.

OK, updated patch attached.

Please send an "Acked-by: Eric W. Biederman <ebiederm at xmission.com>" if this
looks ok to you.


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



From uwe at hermann-uwe.de  Mon Jan 12 23:46:08 2009
From: uwe at hermann-uwe.de (Uwe Hermann)
Date: Mon, 12 Jan 2009 23:46:08 +0100
Subject: [coreboot] [PATCH] v1: Add license headers to AMD AMD-768 code
In-Reply-To: <20090112223813.GB9820@greenwood>
References: <20090108175314.GA22435@greenwood>
	<m1zli1xko9.fsf@frodo.ebiederm.org>
	<20090112223813.GB9820@greenwood>
Message-ID: <20090112224608.GC9820@greenwood>

On Mon, Jan 12, 2009 at 11:38:13PM +0100, Uwe Hermann wrote:
> On Thu, Jan 08, 2009 at 06:44:38PM -0800, Eric W. Biederman wrote:
> > Uwe Hermann <uwe at hermann-uwe.de> writes:
> > 
> > > Yay, my first v1 patch :)
> > >
> > > Eric, any other code chunks which were mostly/entirely written by you
> > > where we can slap a GPLv2 header on? AMD-766, others?
> > >
> > > Btw, was this code from 2003 (C) Eric W. Biederman or rather (C) LNXI?
> > 
> > Always a fuzzy line that.  If we care how about we slap both on, and
> > not worry to much about the details.
> 
> OK, updated patch attached.
> 
> Please send an "Acked-by: Eric W. Biederman <ebiederm at xmission.com>" if this
> looks ok to you.

Forgot the patch, sorry.

All files from v1's
  src/southbridge/amd/amd768
  src/northbridge/amd/amd76x
have license headers added now.


Uwe.
-- 
http://www.hermann-uwe.de  | http://www.holsham-traders.de
http://www.crazy-hacks.org | http://www.unmaintained-free-software.org
-------------- next part --------------
A non-text attachment was scrubbed...
Name: v1_amd768_gpl_headers.patch
Type: text/x-diff
Size: 30817 bytes
Desc: not available
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20090112/c065d248/attachment.bin>

From uwe at hermann-uwe.de  Tue Jan 13 00:21:21 2009
From: uwe at hermann-uwe.de (Uwe Hermann)
Date: Tue, 13 Jan 2009 00:21:21 +0100
Subject: [coreboot] ASUS A7M-266D infos
Message-ID: <20090112232121.GD9820@greenwood>

Here's a dump provided by Sven Schnelle <svens at stackframe.org> for the
ASUS A7M-266D (dual CPU) board with AMD-76x/AMD-780 chipset, for
reference and archival purposes.

There's some support in v1 for this, but as soon as the license patches
I sent are committed, I'll probably have a try at porting all of this
to v2 and adding support for the board.


-[0000:00]-+-00.0  Advanced Micro Devices [AMD] AMD-760 MP [IGD4-2P] System Controller [1022:700c]
           +-01.0-[0000:01]--
           +-07.0  Advanced Micro Devices [AMD] AMD-768 [Opus] ISA [1022:7440]
           +-07.1  Advanced Micro Devices [AMD] AMD-768 [Opus] IDE [1022:7441]
           +-07.3  Advanced Micro Devices [AMD] AMD-768 [Opus] ACPI [1022:7443]
           \-10.0-[0000:02]--+-00.0  Advanced Micro Devices [AMD] AMD-768 [Opus] USB [1022:7449]
                             +-04.0  C-Media Electronics Inc CM8738 [13f6:0111]
                             +-05.0  nVidia Corporation NV4 [RIVA TNT] [10de:0020]
                             \-06.0  3Com Corporation 3c905 100BaseTX [Boomerang] [10b7:9050]

-----------------------------------------------------------------------------------------------------

superiotool r3828
Probing for ALi Super I/O at 0x3f0...
  Failed. Returned data: id=0xffff, rev=0xff
Probing for ALi Super I/O at 0x370...
  Failed. Returned data: id=0x3f3f, rev=0x3f
Probing for Fintek Super I/O at 0x2e...
  Failed. Returned data: vid=0x80fe, id=0x5359
Probing for Fintek Super I/O at 0x4e...
  Failed. Returned data: vid=0xffff, id=0xffff
Probing for ITE Super I/O (init=standard) at 0x2e...
  Failed. Returned data: id=0x0000, rev=0x0
Probing for ITE Super I/O (init=it8761e) at 0x2e...
  Failed. Returned data: id=0x0000, rev=0x0
Probing for ITE Super I/O (init=it8228e) at 0x2e...
  Failed. Returned data: id=0x0000, rev=0x0
Probing for ITE Super I/O (init=0x87,0x87) at 0x2e...
  Failed. Returned data: id=0x5953, rev=0xf
Probing for ITE Super I/O (init=standard) at 0x4e...
  Failed. Returned data: id=0xffff, rev=0xf
Probing for ITE Super I/O (init=it8761e) at 0x4e...
  Failed. Returned data: id=0xffff, rev=0xf
Probing for ITE Super I/O (init=it8228e) at 0x4e...
  Failed. Returned data: id=0xffff, rev=0xf
Probing for ITE Super I/O (init=0x87,0x87) at 0x4e...
  Failed. Returned data: id=0xffff, rev=0xf
Probing for ITE Super I/O (init=legacy/it8661f) at 0x370...
  Failed. Returned data: id=0x3f3f, rev=0xf
Probing for ITE Super I/O (init=legacy/it8671f) at 0x370...
  Failed. Returned data: id=0x2222, rev=0x2
Probing for NSC Super I/O at 0x2e...
  Failed. Returned data: port=0x00, port+1=0x00
Probing for NSC Super I/O at 0x4e...
  Failed. Returned data: port=0xff, port+1=0xff
Probing for NSC Super I/O at 0x15c...
  Failed. Returned data: port=0xff, port+1=0xff
Probing for SMSC Super I/O (idregs=0x20/0x21) at 0x2e...
  Failed. Returned data: id=0x00, rev=0x00
Probing for SMSC Super I/O (idregs=0x0d/0x0e) at 0x2e...
  Failed. Returned data: id=0x00, rev=0x00
Probing for SMSC Super I/O (idregs=0x20/0x21) at 0x4e...
  Failed. Returned data: id=0xff, rev=0xff
Probing for SMSC Super I/O (idregs=0x0d/0x0e) at 0x4e...
  Failed. Returned data: id=0xff, rev=0xff
Probing for SMSC Super I/O (idregs=0x20/0x21) at 0x162e...
  Failed. Returned data: id=0xff, rev=0xff
Probing for SMSC Super I/O (idregs=0x0d/0x0e) at 0x162e...
  Failed. Returned data: id=0xff, rev=0xff
Probing for SMSC Super I/O (idregs=0x20/0x21) at 0x164e...
  Failed. Returned data: id=0xff, rev=0xff
Probing for SMSC Super I/O (idregs=0x0d/0x0e) at 0x164e...
  Failed. Returned data: id=0xff, rev=0xff
Probing for SMSC Super I/O (idregs=0x20/0x21) at 0x3f0...
  Failed. Returned data: id=0xff, rev=0xff
Probing for SMSC Super I/O (idregs=0x0d/0x0e) at 0x3f0...
  Failed. Returned data: id=0xff, rev=0xff
Probing for SMSC Super I/O (idregs=0x20/0x21) at 0x370...
  Failed. Returned data: id=0x22, rev=0x22
Probing for SMSC Super I/O (idregs=0x0d/0x0e) at 0x370...
  Failed. Returned data: id=0x22, rev=0x22
Probing for Winbond Super I/O (init=0x88) at 0x2e...
  Failed. Returned data: id/oldid=0x00/0x00, rev=0x00
Probing for Winbond Super I/O (init=0x89) at 0x2e...
  Failed. Returned data: id/oldid=0x00/0x00, rev=0x00
Probing for Winbond Super I/O (init=0x86,0x86) at 0x2e...
  Failed. Returned data: id/oldid=0x00/0x00, rev=0x00
Probing for Winbond Super I/O (init=0x87,0x87) at 0x2e...
Found Winbond W83627SF (id=0x59, rev=0x53) at 0x2e
No dump available for this Super I/O
Probing for Winbond Super I/O (init=0x88) at 0x4e...
  Failed. Returned data: id/oldid=0xff/0x0f, rev=0xff
Probing for Winbond Super I/O (init=0x89) at 0x4e...
  Failed. Returned data: id/oldid=0xff/0x0f, rev=0xff
Probing for Winbond Super I/O (init=0x86,0x86) at 0x4e...
  Failed. Returned data: id/oldid=0xff/0x0f, rev=0xff
Probing for Winbond Super I/O (init=0x87,0x87) at 0x4e...
  Failed. Returned data: id/oldid=0xff/0x0f, rev=0xff
Probing for Winbond Super I/O (init=0x88) at 0x3f0...
  Failed. Returned data: id/oldid=0xff/0x0f, rev=0xff
Probing for Winbond Super I/O (init=0x89) at 0x3f0...
  Failed. Returned data: id/oldid=0xff/0x0f, rev=0xff
Probing for Winbond Super I/O (init=0x86,0x86) at 0x3f0...
  Failed. Returned data: id/oldid=0xff/0x0f, rev=0xff
Probing for Winbond Super I/O (init=0x87,0x87) at 0x3f0...
  Failed. Returned data: id/oldid=0xff/0x0f, rev=0xff
Probing for Winbond Super I/O (init=0x88) at 0x370...
  Failed. Returned data: id/oldid=0x22/0x02, rev=0x22
Probing for Winbond Super I/O (init=0x89) at 0x370...
  Failed. Returned data: id/oldid=0x22/0x02, rev=0x22
Probing for Winbond Super I/O (init=0x86,0x86) at 0x370...
  Failed. Returned data: id/oldid=0x22/0x02, rev=0x22
Probing for Winbond Super I/O (init=0x87,0x87) at 0x370...
  Failed. Returned data: id/oldid=0x22/0x02, rev=0x22
Probing for Winbond Super I/O (init=0x88) at 0x250...
  Failed. Returned data: id/oldid=0xff/0x0f, rev=0xff
Probing for Winbond Super I/O (init=0x89) at 0x250...
  Failed. Returned data: id/oldid=0xff/0x0f, rev=0xff
Probing for Winbond Super I/O (init=0x86,0x86) at 0x250...
  Failed. Returned data: id/oldid=0xff/0x0f, rev=0xff
Probing for Winbond Super I/O (init=0x87,0x87) at 0x250...
  Failed. Returned data: id/oldid=0xff/0x0f, rev=0xff


-----------------------------------------------------------------------------------

/* 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, which BIOS sets up.
 *
 * Documentation at: http://www.microsoft.com/whdc/archive/pciirq.mspx
 */

#ifdef GETPIR
#include "pirq_routing.h"
#else
#include <arch/pirq_routing.h>
#endif

const struct irq_routing_table intel_irq_routing_table = {
	PIRQ_SIGNATURE,  /* u32 signature */
	PIRQ_VERSION,    /* u16 version   */
	32+16*9,	 /* There can be total 9 devices on the bus */
	0x00,		 /* Where the interrupt router lies (bus) */
	(0x07<<3)|0x3,   /* Where the interrupt router lies (dev) */
	0,		 /* IRQs devoted exclusively to PCI usage */
	0x1022,		 /* Vendor */
	0x7440,		 /* Device */
	0,		 /* Miniport */
	{ 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0 }, /* u8 rfu[11] */
	0x17,		 /* u8 checksum. This 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,(0x07<<3)|0x0, {{0x00, 0x1eb8}, {0x01, 0x1eb8}, {0x02, 0x1eb8}, {0x03, 0x1eb8}}, 0x0, 0x0},
		{0x00,(0x08<<3)|0x0, {{0x00, 0x1eb8}, {0x01, 0x1eb8}, {0x02, 0x1eb8}, {0x03, 0x1eb8}}, 0x1, 0x0},
		{0x00,(0x09<<3)|0x0, {{0x01, 0x1eb8}, {0x02, 0x1eb8}, {0x03, 0x1eb8}, {0x00, 0x1eb8}}, 0x2, 0x0},
		{0x02,(0x06<<3)|0x0, {{0x01, 0x1eb8}, {0x02, 0x1eb8}, {0x03, 0x1eb8}, {0x00, 0x1eb8}}, 0x3, 0x0},
		{0x02,(0x05<<3)|0x0, {{0x02, 0x1eb8}, {0x03, 0x1eb8}, {0x00, 0x1eb8}, {0x01, 0x1eb8}}, 0x4, 0x0},
		{0x02,(0x08<<3)|0x0, {{0x03, 0x1eb8}, {0x00, 0x1eb8}, {0x01, 0x1eb8}, {0x02, 0x1eb8}}, 0x5, 0x0},
		{0x01,(0x05<<3)|0x0, {{0x00, 0x1eb8}, {0x01, 0x1eb8}, {0x02, 0x1eb8}, {0x03, 0x1eb8}}, 0x0, 0x0},
		{0x02,(0x04<<3)|0x0, {{0x01, 0x1eb8}, {0x02, 0x1eb8}, {0x03, 0x1eb8}, {0x00, 0x1eb8}}, 0x0, 0x0},
		{0x02,(0x00<<3)|0x0, {{0x00, 0x1eb8}, {0x01, 0x1eb8}, {0x02, 0x1eb8}, {0x03, 0x1eb8}}, 0x0, 0x0},
	}
};

unsigned long write_pirq_routing_table(unsigned long addr)
{
	return copy_pirq_routing_table(addr);
}

--------------------------------------------------------------------------------------------


/* generated by MPTable, version 2.0.15*/
/* as modified by RGM for coreboot */
#include <console/console.h>
#include <arch/smp/mpspec.h>
#include <device/pci.h>
#include <string.h>
#include <stdint.h>

void *smp_write_config_table(void *v)
{
        static const char sig[4] = "PCMP";
        static const char oem[8] = "LNXI    ";
        static const char productid[12] = "P4DPE       ";
        struct mp_config_table *mc;

        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);


/*Bus:		Bus ID	Type*/
	smp_write_bus(mc, 0, "PCI   ");
	smp_write_bus(mc, 1, "PCI   ");
	smp_write_bus(mc, 2, "PCI   ");
	smp_write_bus(mc, 3, "ISA   ");
/*I/O APICs:	APIC ID	Version	State		Address*/
	smp_write_ioapic(mc, 2, 0x20, 0xfec00000);
	{
		device_t dev;
		struct resource *res;
		dev = dev_find_slot(1, PCI_DEVFN(0x1e,0));
		if (dev) {
			res = find_resource(dev, PCI_BASE_ADDRESS_0);
			if (res) {
				smp_write_ioapic(mc, 3, 0x20, res->base);
			}
		}
		dev = dev_find_slot(1, PCI_DEVFN(0x1c,0));
		if (dev) {
			res = find_resource(dev, PCI_BASE_ADDRESS_0);
			if (res) {
				smp_write_ioapic(mc, 4, 0x20, res->base);
			}
		}
                dev = dev_find_slot(4, PCI_DEVFN(0x1e,0));
                if (dev) {
			res = find_resource(dev, PCI_BASE_ADDRESS_0);
			if (res) {
				smp_write_ioapic(mc, 5, 0x20, res->base);
			}
                }
                dev = dev_find_slot(4, PCI_DEVFN(0x1c,0));
                if (dev) {
			res = find_resource(dev, PCI_BASE_ADDRESS_0);
			if (res) {
				smp_write_ioapic(mc, 8, 0x20, res->base);
			}
                }
	}
/*I/O Ints:	Type	Polarity    Trigger	Bus ID	 IRQ	APIC ID	PIN#
*/	smp_write_intsrc(mc, mp_INT, MP_IRQ_TRIGGER_LEVEL|MP_IRQ_POLARITY_LOW, 0x2, 0x3, 0x2, 0x13);
	smp_write_intsrc(mc, mp_INT, MP_IRQ_TRIGGER_LEVEL|MP_IRQ_POLARITY_LOW, 0x2, 0x10, 0x2, 0x11);
	smp_write_intsrc(mc, mp_INT, MP_IRQ_TRIGGER_LEVEL|MP_IRQ_POLARITY_LOW, 0x2, 0x14, 0x2, 0x12);
	smp_write_intsrc(mc, mp_INT, MP_IRQ_TRIGGER_LEVEL|MP_IRQ_POLARITY_LOW, 0x2, 0x18, 0x2, 0x11);
	smp_write_intsrc(mc, mp_ExtINT, MP_IRQ_TRIGGER_DEFAULT|MP_IRQ_POLARITY_DEFAULT, 0x3, 0x0, 0x2, 0x0);
	smp_write_intsrc(mc, mp_INT, MP_IRQ_TRIGGER_DEFAULT|MP_IRQ_POLARITY_DEFAULT, 0x3, 0x1, 0x2, 0x1);
	smp_write_intsrc(mc, mp_INT, MP_IRQ_TRIGGER_DEFAULT|MP_IRQ_POLARITY_DEFAULT, 0x3, 0x0, 0x2, 0x2);
	smp_write_intsrc(mc, mp_INT, MP_IRQ_TRIGGER_DEFAULT|MP_IRQ_POLARITY_DEFAULT, 0x3, 0x3, 0x2, 0x3);
	smp_write_intsrc(mc, mp_INT, MP_IRQ_TRIGGER_DEFAULT|MP_IRQ_POLARITY_DEFAULT, 0x3, 0x4, 0x2, 0x4);
	smp_write_intsrc(mc, mp_INT, MP_IRQ_TRIGGER_DEFAULT|MP_IRQ_POLARITY_DEFAULT, 0x3, 0x5, 0x2, 0x5);
	smp_write_intsrc(mc, mp_INT, MP_IRQ_TRIGGER_DEFAULT|MP_IRQ_POLARITY_DEFAULT, 0x3, 0x6, 0x2, 0x6);
	smp_write_intsrc(mc, mp_INT, MP_IRQ_TRIGGER_DEFAULT|MP_IRQ_POLARITY_DEFAULT, 0x3, 0x7, 0x2, 0x7);
	smp_write_intsrc(mc, mp_INT, MP_IRQ_TRIGGER_DEFAULT|MP_IRQ_POLARITY_DEFAULT, 0x3, 0x8, 0x2, 0x8);
	smp_write_intsrc(mc, mp_INT, MP_IRQ_TRIGGER_DEFAULT|MP_IRQ_POLARITY_DEFAULT, 0x3, 0x9, 0x2, 0x9);
	smp_write_intsrc(mc, mp_INT, MP_IRQ_TRIGGER_DEFAULT|MP_IRQ_POLARITY_DEFAULT, 0x3, 0xd, 0x2, 0xd);
	smp_write_intsrc(mc, mp_INT, MP_IRQ_TRIGGER_DEFAULT|MP_IRQ_POLARITY_DEFAULT, 0x3, 0xe, 0x2, 0xe);
	smp_write_intsrc(mc, mp_INT, MP_IRQ_TRIGGER_DEFAULT|MP_IRQ_POLARITY_DEFAULT, 0x3, 0xf, 0x2, 0xf);
/*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, 0x3, 0x0, MP_APIC_ALL, 0x0);
	smp_write_intsrc(mc, mp_NMI, MP_IRQ_TRIGGER_EDGE|MP_IRQ_POLARITY_HIGH, 0x0, 0x0, MP_APIC_ALL, 0x1);
MP Config Extended Table Entries:

--
System Address Space
 bus ID: 0 address type: I/O address
 address base: 0x0
 address range: 0x10000
--
System Address Space
 bus ID: 0 address type: memory address
 address base: 0x10000000
 address range: 0xe9f00000
--
System Address Space
 bus ID: 0 address type: prefetch address
 address base: 0xf9f00000
 address range: 0x4d00000
--
System Address Space
 bus ID: 0 address type: memory address
 address base: 0xfec00000
 address range: 0x1400000
--
System Address Space
 bus ID: 0 address type: memory address
 address base: 0xa0000
 address range: 0x20000
--
Bus Heirarchy
 bus ID: 3 bus info: 0x01 parent bus ID: 0--
Compatibility Bus Address
 bus ID: 0 address modifier: add
 predefined range: 0x00000000--
Compatibility Bus Address
 bus ID: 0 address modifier: add
 predefined range: 0x00000001	/* 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);
}


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



From JasonZhao at viatech.com.cn  Tue Jan 13 03:11:59 2009
From: JasonZhao at viatech.com.cn (JasonZhao at viatech.com.cn)
Date: Tue, 13 Jan 2009 10:11:59 +0800
Subject: [coreboot] v3 bug report: Error base address register of UART
	in vt1211
In-Reply-To: <13426df10901120809w6b5bbef8ibb5b7136f7d5f184@mail.gmail.com>
References: <9156F9F8217CD44898ABE1E581FAFF882FB89E@exchbj02.viatech.com.bj>
	<13426df10901120809w6b5bbef8ibb5b7136f7d5f184@mail.gmail.com>
Message-ID: <9156F9F8217CD44898ABE1E581FAFF882FBA43@exchbj02.viatech.com.bj>



-jasonzhao 

> -----Original Message-----
> From: ron minnich [mailto:rminnich at gmail.com]
> Sent: Tuesday, January 13, 2009 12:09 AM
> To: Jason Zhao
> Cc: c-d.hailfinger.devel.2006 at gmx.net; coreboot at coreboot.org
> Subject: Re: [coreboot] v3 bug report: Error base address register of UART in
> vt1211
> 
> On Sun, Jan 11, 2009 at 10:40 PM,  <JasonZhao at viatech.com.cn> wrote:
> > Hi Carl,
> > I find a bug need to fix in superior/via/vt1211/Stage1.c
> >        rawpnp_set_iobase(dev, 2, (iobase >> 2) & 0xff);
> >    should be
> >        rawpnp_set_iobase(dev, 0x60, ((iobase >> 2) & 0xff)<<8);
> 
> I Understand the 0x60. I don't understand this part:
> ((iobase >> 2) & 0xff)<<8)
Something copied from vt1211 spec:
5.1.1.1 UART1_RX60: Serial Port 1 Base Address  
Attribute: RW         Default Value: FEh 
Bit Description 
[7:1] ADR9~ADR3 
[0]  Must be 0
This will help to under stand why >>2,  and   <<8 is because the definition of function rawpnp_set_iobase?

void rawpnp_set_iobase(u16 port, u8 index, u16 iobase)
{
	rawpnp_write_config(port, index + 0, (iobase >> 8) & 0xff); /* MSB */
	rawpnp_write_config(port, index + 1, iobase & 0xff);	    /* LSB */
}
The rawpnp_set_iobase suppose the MSB of "iobase" is written into register 0x60, however vt1211 spec(above) says bit[3-9] should be written into this 0x60.

> 
> Is that correct? Not just (iobase >> 8)&0xff (although the &0xff is
> not really needed)
> 
> thanks
> 
> ron




From kconnelly at siliconmechanics.com  Tue Jan 13 03:25:18 2009
From: kconnelly at siliconmechanics.com (Kevin Connelly)
Date: Mon, 12 Jan 2009 18:25:18 -0800
Subject: [coreboot] Supermicro H8DME-2 Coreboot v2
Message-ID: <496BFB8E.8020104@siliconmechanics.com>

Hi All,

I am attempting to boot a H8DME-2 using the Supermicro H8DMR-i2 code as 
a starting point. I am having problems getting the ram to initialize 
properly. I can get a bootable system, but not with the proper amount of 
ram available in the OS.

Using i2cdetect, it appears that the ram off the first cpu is at 30-37, 
and the ram off the second cpu is at 50-57. Setting these addresses in 
Congig.lb does not seem to fix the problem.

I have attached lspci and dmidecode dumps. Please let me know what other 
debug information would be helpful.

Any help or guidance is greatly appreciated.

Thanks in advance.

Kevin

-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: dmidecode
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20090112/49714e31/attachment.ksh>
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: lspci.tv
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20090112/49714e31/attachment-0001.ksh>
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: lspci.vvvx
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20090112/49714e31/attachment-0002.ksh>

From rminnich at gmail.com  Tue Jan 13 07:14:06 2009
From: rminnich at gmail.com (ron minnich)
Date: Mon, 12 Jan 2009 22:14:06 -0800
Subject: [coreboot] v3 bug report: Error base address register of UART
	in vt1211
In-Reply-To: <9156F9F8217CD44898ABE1E581FAFF882FBA43@exchbj02.viatech.com.bj>
References: <9156F9F8217CD44898ABE1E581FAFF882FB89E@exchbj02.viatech.com.bj>
	<13426df10901120809w6b5bbef8ibb5b7136f7d5f184@mail.gmail.com>
	<9156F9F8217CD44898ABE1E581FAFF882FBA43@exchbj02.viatech.com.bj>
Message-ID: <13426df10901122214qd8a0439m3f969eda088c9a0e@mail.gmail.com>

OK, thanks, your patch is
Acked-by: Ronald G. Minnich <rminnich at gmail.com>

ron



From svn at coreboot.org  Tue Jan 13 15:10:18 2009
From: svn at coreboot.org (coreboot)
Date: Tue, 13 Jan 2009 14:10:18 -0000
Subject: [coreboot] #119: Winbond W39V040FBPZ is not written correctly by
 flashrom
Message-ID: <061.c7a42005f16f326cb9f32928b1396882@coreboot.org>

#119: Winbond W39V040FBPZ is not written correctly by flashrom
-----------------------------------------+----------------------------------
   Reporter:  charles.herndon@?          |          Owner:  somebody
       Type:  enhancement                |         Status:  new     
   Priority:  minor                      |      Milestone:          
  Component:  flashrom                   |        Version:  v2      
   Keywords:  W39V040FBPZ                |   Dependencies:          
Patchstatus:  there is no patch          |  
-----------------------------------------+----------------------------------
 Flash device is detected as a Winbond W39V040B device.  Flashrom attempts
 to flash device, but verification fails.  No actual writing to the chip
 appears to be done.  Tried changing write and erase in flashchips.c to:
 jedec, winbond_fwhub and 49lfxxxc.

 ./flashrom -wv xxxx.bin
 Calibrating delay loop... OK.
 No coreboot table found.
 Found chipset "Intel ICH7/ICH7R", enabling flash write... OK.
 Found chip "Winbond W39V040B" (512 KB) at physical address 0xfff80000.
 Flash image seems to be a legacy BIOS. Disabling checks.
 Programming page: 0007 at address: 0x00070000
 Verifying flash... FAILED!  Expected=0xc7, Read=0x49

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


From svn at coreboot.org  Tue Jan 13 15:32:27 2009
From: svn at coreboot.org (svn at coreboot.org)
Date: Tue, 13 Jan 2009 15:32:27 +0100
Subject: [coreboot] r3860 - trunk/util/flashrom
Message-ID: <mailman.2666.1355071469.16123.coreboot@coreboot.org>

Author: stuge
Date: 2009-01-13 15:32:27 +0100 (Tue, 13 Jan 2009)
New Revision: 3860

Modified:
   trunk/util/flashrom/flashrom.c
Log:
flashrom: Always print address when verification fails, not only with -V.

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


Modified: trunk/util/flashrom/flashrom.c
===================================================================
--- trunk/util/flashrom/flashrom.c	2009-01-12 21:31:14 UTC (rev 3859)
+++ trunk/util/flashrom/flashrom.c	2009-01-13 14:32:27 UTC (rev 3860)
@@ -186,10 +186,11 @@
 			printf("0x%08x", idx);
 
 		if (*(buf2 + idx) != *(buf + idx)) {
-			if (verbose) {
-				printf("0x%08x ", idx);
-			}
-			printf("FAILED!  Expected=0x%02x, Read=0x%02x\n",
+			if (verbose)
+				printf("0x%08x FAILED!", idx);
+			else
+				printf("FAILED at 0x%08x!", idx);
+			printf("  Expected=0x%02x, Read=0x%02x\n",
 			       *(buf + idx), *(buf2 + idx));
 			return 1;
 		}




From svn at coreboot.org  Tue Jan 13 17:11:08 2009
From: svn at coreboot.org (coreboot)
Date: Tue, 13 Jan 2009 16:11:08 -0000
Subject: [coreboot] #119: Winbond W39V040FBPZ is not written correctly
 by flashrom
In-Reply-To: <061.c7a42005f16f326cb9f32928b1396882@coreboot.org>
References: <061.c7a42005f16f326cb9f32928b1396882@coreboot.org>
Message-ID: <070.be9746a2d569cf055b90f2868f10e012@coreboot.org>

#119: Winbond W39V040FBPZ is not written correctly by flashrom
-----------------------------------------+----------------------------------
   Reporter:  charles.herndon@?          |          Owner:  somebody
       Type:  enhancement                |         Status:  new     
   Priority:  minor                      |      Milestone:          
  Component:  flashrom                   |        Version:  v2      
   Keywords:  W39V040FBPZ                |   Dependencies:          
Patchstatus:  there is no patch          |  
-----------------------------------------+----------------------------------

Comment(by coreboot01@?):

 I got a similar problem using W39V040FBPZ.

 After starting flashrom, output stopped at "disabling checks" for a minute
 or so, then the first "Programming page" appeared and nothing more
 happened.
 Looking with strace at the process id showed that the process was doing
 nothing at all. I left the system at this state for a whole day, but still
 nothing happened.

 Then I tried again using a SST 49LF040 chip on the board (VIA PC2500e) and
 flashing worked without any problem.

 Andreas Wanske

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


From svn at coreboot.org  Tue Jan 13 18:19:58 2009
From: svn at coreboot.org (coreboot)
Date: Tue, 13 Jan 2009 17:19:58 -0000
Subject: [coreboot] #119: Winbond W39V040FBPZ is not written correctly
 by flashrom
In-Reply-To: <061.c7a42005f16f326cb9f32928b1396882@coreboot.org>
References: <061.c7a42005f16f326cb9f32928b1396882@coreboot.org>
Message-ID: <070.20ba4a64f9aa1fe879f01e8fa2d53bf0@coreboot.org>

#119: Winbond W39V040FBPZ is not written correctly by flashrom
-----------------------------------------+----------------------------------
   Reporter:  charles.herndon@?          |          Owner:  somebody
       Type:  enhancement                |         Status:  new     
   Priority:  minor                      |      Milestone:          
  Component:  flashrom                   |        Version:  v2      
   Keywords:  W39V040FBPZ                |   Dependencies:          
Patchstatus:  there is no patch          |  
-----------------------------------------+----------------------------------

Comment(by hailfinger):

 strace is unable to see any flashrom activity because flashrom does not
 use syscalls. (There are no syscalls for flashing.)

 So if you think flashrom does nothing at all, it is still doing something,
 but no utility like strace can see it.

 The Winbond chips are really problematic. If we try to program them
 according to their data sheets, they fail sometimes. Any insight is
 appreciated. No other chip vendor has these problems.

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


From svn at coreboot.org  Tue Jan 13 18:37:18 2009
From: svn at coreboot.org (coreboot)
Date: Tue, 13 Jan 2009 17:37:18 -0000
Subject: [coreboot] #119: Winbond W39V040FBPZ is not written correctly
 by flashrom
In-Reply-To: <061.c7a42005f16f326cb9f32928b1396882@coreboot.org>
References: <061.c7a42005f16f326cb9f32928b1396882@coreboot.org>
Message-ID: <070.a68811a3d0d3e72dbff12dfb0d5c8552@coreboot.org>

#119: Winbond W39V040FBPZ is not written correctly by flashrom
-----------------------------------------+----------------------------------
   Reporter:  charles.herndon@?          |          Owner:  somebody
       Type:  enhancement                |         Status:  new     
   Priority:  minor                      |      Milestone:          
  Component:  flashrom                   |        Version:  v2      
   Keywords:  W39V040FBPZ                |   Dependencies:          
Patchstatus:  there is no patch          |  
-----------------------------------------+----------------------------------

Comment(by charles.herndon@?):

 Replying to [comment:2 hailfinger]:
 > strace is unable to see any flashrom activity because flashrom does not
 use syscalls. (There are no syscalls for flashing.)
 >
 > So if you think flashrom does nothing at all, it is still doing
 something, but no utility like strace can see it.
 >
 > The Winbond chips are really problematic. If we try to program them
 according to their data sheets, they fail sometimes. Any insight is
 appreciated. No other chip vendor has these problems.

 I'm willing to provide any information you need.  The only thing I do know
 about this chip is that by mistake I was successful programming it with an
 EEPROM programmer using the settings for SST49LF004 (I forgot to change
 models to the Winbond part)

-- 
Ticket URL: <http://tracker.coreboot.org/trac/coreboot/ticket/119#comment:3>
coreboot <http://www.coreboot.org/>


From mart.raudsepp at artecdesign.ee  Tue Jan 13 20:42:52 2009
From: mart.raudsepp at artecdesign.ee (Mart Raudsepp)
Date: Tue, 13 Jan 2009 21:42:52 +0200
Subject: [coreboot] [PATCH] Remove redundant unused tRCD entries from
 dbe61/dbe62 SPD value list.
Message-ID: <1231875772.14574.3.camel@martr-gentoo.artec>

SPD_MIN_RAS_TO_CAS_DELAY is already set earlier in the list, so the alternative
constant tRCD in the end has no effect in the memory algorithm - remove them.

Signed-off-by: Mart Raudsepp <mart.raudsepp at artecdesign.ee>
---
 mainboard/artecgroup/dbe61/initram.c |    2 --
 mainboard/artecgroup/dbe62/initram.c |    1 -
 2 files changed, 0 insertions(+), 3 deletions(-)

diff --git a/mainboard/artecgroup/dbe61/initram.c b/mainboard/artecgroup/dbe61/initram.c
index d8612de..4c16bdb 100644
--- a/mainboard/artecgroup/dbe61/initram.c
+++ b/mainboard/artecgroup/dbe61/initram.c
@@ -66,7 +66,6 @@ static const struct spd_entry spd_table_dbe61c[] = {
 	{SPD_REFRESH, 0x82},
 	{SPD_SDRAM_CYCLE_TIME_2ND, 0x0},
 	{SPD_SDRAM_CYCLE_TIME_3RD, 0x0},
-	{SPD_tRCD, 15},
 };
 
 /* Fake SPD for DBE61A - 128MB */
@@ -89,7 +88,6 @@ static const struct spd_entry spd_table_dbe61a[] = {
 	{SPD_REFRESH, 0x82},
 	{SPD_SDRAM_CYCLE_TIME_2ND, 0x0},
 	{SPD_SDRAM_CYCLE_TIME_3RD, 0x0},
-	{SPD_tRCD, 15},
 };
 
 /**
diff --git a/mainboard/artecgroup/dbe62/initram.c b/mainboard/artecgroup/dbe62/initram.c
index d3940fc..35e5b3f 100644
--- a/mainboard/artecgroup/dbe62/initram.c
+++ b/mainboard/artecgroup/dbe62/initram.c
@@ -70,7 +70,6 @@ static const struct spd_entry spd_table[] = {
 	{SPD_REFRESH, 0x82},
 	{SPD_SDRAM_CYCLE_TIME_2ND, 0x0},
 	{SPD_SDRAM_CYCLE_TIME_3RD, 0x0},
-	{SPD_tRCD, 15},
 };
 
 /**
-- 
1.6.0.4




From marcj303 at gmail.com  Tue Jan 13 21:00:41 2009
From: marcj303 at gmail.com (Marc Jones)
Date: Tue, 13 Jan 2009 13:00:41 -0700
Subject: [coreboot] Supermicro H8DME-2 Coreboot v2
In-Reply-To: <496BFB8E.8020104@siliconmechanics.com>
References: <496BFB8E.8020104@siliconmechanics.com>
Message-ID: <534e5dc20901131200j4ecf9b48g2209b5ba78c5bc02@mail.gmail.com>

On Mon, Jan 12, 2009 at 7:25 PM, Kevin Connelly
<kconnelly at siliconmechanics.com> wrote:
> Hi All,
>
> I am attempting to boot a H8DME-2 using the Supermicro H8DMR-i2 code as a
> starting point. I am having problems getting the ram to initialize properly.
> I can get a bootable system, but not with the proper amount of ram available
> in the OS.
>
> Using i2cdetect, it appears that the ram off the first cpu is at 30-37, and
> the ram off the second cpu is at 50-57. Setting these addresses in Congig.lb
> does not seem to fix the problem.
>
> I have attached lspci and dmidecode dumps. Please let me know what other
> debug information would be helpful.

Hi Kevin,

The i2c address is not used from the config.lb (yeah that needs to be
fixed). In cache_as_ram_auto.c the spd_addr needs to be filled in
correctly. That is what maps an i2c address to a dimm slots.

Marc



From svn at coreboot.org  Tue Jan 13 21:02:47 2009
From: svn at coreboot.org (coreboot)
Date: Tue, 13 Jan 2009 20:02:47 -0000
Subject: [coreboot]  #120: flashrom failure to read
Message-ID: <053.0bcc838ee0a3c5de1df320df034ed573@coreboot.org>

#120: flashrom failure to read
---------------------------------+------------------------------------------
   Reporter:  toc@?              |          Owner:  somebody
       Type:  defect             |         Status:  new     
   Priority:  major              |      Milestone:          
  Component:  flashrom           |        Version:  v2      
   Keywords:                     |   Dependencies:          
Patchstatus:  there is no patch  |  
---------------------------------+------------------------------------------
 Running flashrom -r rom.file results in an output file of all null bytes.
 Standard output:
 {{{
 Calibrating delay loop... OK.
 No coreboot table found.
 Found chipset "Intel ICH9R", enabling flash write... tried to set 0xdc to
 0x3 on Intel ICH9R failed (WARNING ONLY)
 FAILED!
 Found chip "Macronix MX25L8005" (1024 KB) at physical address 0xfff00000.
 Reading flash... done.
 }}}
 Verbose output indicates failure of opcode 0x03.
 {{{
 Reading flash... ich_spi_read_page: offset=0, number=256, buf=0xb7cf0008
 Opcode 3 not found.
 run OPCODE 0x03 failed
 Error readingdone.
 }}}
 Full verbose output attached

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


From stephan.guilloux at free.fr  Tue Jan 13 22:02:15 2009
From: stephan.guilloux at free.fr (Stephan GUILLOUX)
Date: Tue, 13 Jan 2009 22:02:15 +0100
Subject: [coreboot] [PATCH] flashrom patch easier board_pciid_enables parsing
Message-ID: <496D0157.9000403@free.fr>


    Hello,

Similarly to flashchips array, this patch intends to make the table
board_pciid_enables more readable.

Also in attachment.

  Stephan.

Signed-off-by: Stephan Guilloux <mailto:stephan.guilloux at free.fr>

Index: coreboot-v2/util/flashrom/board_enable.c
===================================================================
--- coreboot-v2/util/flashrom/board_enable.c    (r??vision 3860)
+++ coreboot-v2/util/flashrom/board_enable.c    (copie de travail)
@@ -626,58 +626,369 @@
 };
 
 struct board_pciid_enable board_pciid_enables[] = {
-    {0x1106, 0x0571, 0x1462, 0x7120, 0x0000, 0x0000, 0x0000, 0x0000,
-     "msi", "kt4v", "MSI KT4V", board_msi_kt4v},
-    {0x8086, 0x1a30, 0x1043, 0x8070, 0x8086, 0x244b, 0x1043, 0x8028,
-     NULL, NULL, "ASUS P4B266", ich2_gpio22_raise},
-    {0x10de, 0x0360, 0x0000, 0x0000, 0x0000, 0x0000, 0x0000, 0x0000,
-     "gigabyte", "m57sli", "GIGABYTE GA-M57SLI-S4", 
it87xx_probe_spi_flash},
-    {0x10de, 0x03e0, 0x0000, 0x0000, 0x0000, 0x0000, 0x0000, 0x0000,
-     "gigabyte", "m61p", "GIGABYTE GA-M61P-S3", it87xx_probe_spi_flash},
-    {0x1002, 0x4398, 0x1458, 0x5004, 0x1002, 0x4385, 0x1458, 0x4385,
-     NULL, NULL, "GIGABYTE GA-MA78G-DS3H", it87xx_probe_spi_flash},
-    {0x1039, 0x0761, 0x0000, 0x0000, 0x0000, 0x0000, 0x0000, 0x0000,
-     "gigabyte", "2761gxdk", "GIGABYTE GA-2761GXDK", 
it87xx_probe_spi_flash},
-    {0x1022, 0x7468, 0x0000, 0x0000, 0x0000, 0x0000, 0x0000, 0x0000,
-     "iwill", "dk8_htx", "IWILL DK8-HTX", w83627hf_gpio24_raise_2e},
-    {0x10de, 0x005e, 0x0000, 0x0000, 0x0000, 0x0000, 0x0000, 0x0000,
-     "msi", "k8n-neo3", "MSI K8N Neo3", w83627thf_gpio4_4_raise_4e},
-    {0x1022, 0x746B, 0x1022, 0x36C0, 0x0000, 0x0000, 0x0000, 0x0000,
-     "AGAMI", "ARUMA", "agami Aruma", w83627hf_gpio24_raise_2e},
-    {0x1106, 0x3177, 0x1106, 0xAA01, 0x1106, 0x3123, 0x1106, 0xAA01,
-     NULL, NULL, "VIA EPIA M/MII/...", board_via_epia_m},
-    {0x1106, 0x3177, 0x1043, 0x80A1, 0x1106, 0x3205, 0x1043, 0x8118,
-     NULL, NULL, "ASUS A7V8-MX SE", board_asus_a7v8x_mx},
-    {0x1106, 0x3227, 0x1106, 0xAA01, 0x1106, 0x0259, 0x1106, 0xAA01,
-     NULL, NULL, "VIA EPIA SP", board_via_epia_sp},
-    {0x1106, 0x0314, 0x1106, 0xaa08, 0x1106, 0x3227, 0x1106, 0xAA08,
-     NULL, NULL, "VIA EPIA-CN", board_via_epia_sp},
-    {0x8086, 0x1076, 0x8086, 0x1176, 0x1106, 0x3059, 0x10f1, 0x2498,
-     NULL, NULL, "Tyan Tomcat K7M", board_asus_a7v8x_mx},
-    {0x10B9, 0x1541, 0x0000, 0x0000, 0x10B9, 0x1533, 0x0000, 0x0000,
-     "asus", "p5a", "ASUS P5A", board_asus_p5a},
-    {0x1166, 0x0205, 0x1014, 0x0347, 0x0000, 0x0000, 0x0000, 0x0000,
-     "ibm", "x3455", "IBM x3455", board_ibm_x3455},
-    {0x8086, 0x7110, 0x0000, 0x0000, 0x8086, 0x7190, 0x0000, 0x0000,
-     "epox", "ep-bx3", "EPoX EP-BX3", board_epox_ep_bx3},
-    {0x8086, 0x1130, 0x0000, 0x0000, 0x105a, 0x0d30, 0x105a, 0x4d33,
-     "acorp", "6a815epd", "Acorp 6A815EPD", board_acorp_6a815epd},
-    {0x1022, 0x2090, 0x0000, 0x0000, 0x1022, 0x2080, 0x0000, 0x0000,
-     "artecgroup", "dbe61", "Artec Group DBE61", board_artecgroup_dbe6x},
-    {0x1022, 0x2090, 0x0000, 0x0000, 0x1022, 0x2080, 0x0000, 0x0000,
-     "artecgroup", "dbe62", "Artec Group DBE62", board_artecgroup_dbe6x},
+    {
+        .first_vendor        = 0x1106,
+        .first_device        = 0x0571,
+        .first_card_vendor    = 0x1462,
+        .first_card_device    = 0x7120,
+        .second_vendor        = 0x0000,
+        .second_device        = 0x0000,
+        .second_card_vendor    = 0x0000,
+        .second_card_device    = 0x0000,
+        .lb_vendor        = "msi",
+        .lb_part        = "kt4v",
+        .name            = "MSI KT4V",
+        .enable            = board_msi_kt4v,
+    },
+    {
+        .first_vendor        = 0x8086,
+        .first_device        = 0x1a30,
+        .first_card_vendor    = 0x1043,
+        .first_card_device    = 0x8070,
+        .second_vendor        = 0x8086,
+        .second_device        = 0x244b,
+        .second_card_vendor    = 0x1043,
+        .second_card_device    = 0x8028,
+        .lb_vendor        = NULL,
+        .lb_part        = NULL,
+        .name            = "ASUS P4B266",
+        .enable            = ich2_gpio22_raise,
+    },
+    {
+        .first_vendor        = 0x10de,
+        .first_device        = 0x0360,
+        .first_card_vendor    = 0x0000,
+        .first_card_device    = 0x0000,
+        .second_vendor        = 0x0000,
+        .second_device        = 0x0000,
+        .second_card_vendor    = 0x0000,
+        .second_card_device    = 0x0000,
+        .lb_vendor        = "gigabyte",
+        .lb_part        = "m57sli",
+        .name            = "GIGABYTE GA-M57SLI-S4",
+        .enable            = it87xx_probe_spi_flash,
+    },
+    {
+        .first_vendor        = 0x10de,
+        .first_device        = 0x03e0,
+        .first_card_vendor    = 0x0000,
+        .first_card_device    = 0x0000,
+        .second_vendor        = 0x0000,
+        .second_device        = 0x0000,
+        .second_card_vendor    = 0x0000,
+        .second_card_device    = 0x0000,
+        .lb_vendor        = "gigabyte",
+        .lb_part        = "m61p",
+        .name            = "GIGABYTE GA-M61P-S3",
+        .enable            = it87xx_probe_spi_flash,
+    },
+    {
+        .first_vendor        = 0x1002,
+        .first_device        = 0x4398,
+        .first_card_vendor    = 0x1458,
+        .first_card_device    = 0x5004,
+        .second_vendor        = 0x1002,
+        .second_device        = 0x4385,
+        .second_card_vendor    = 0x1458,
+        .second_card_device    = 0x4385,
+        .lb_vendor        = NULL,
+        .lb_part        = NULL,
+        .name            = "GIGABYTE GA-MA78G-DS3H",
+        .enable            = it87xx_probe_spi_flash,
+    },
+    {
+        .first_vendor        = 0x1039,
+        .first_device        = 0x0761,
+        .first_card_vendor    = 0x0000,
+        .first_card_device    = 0x0000,
+        .second_vendor        = 0x0000,
+        .second_device        = 0x0000,
+        .second_card_vendor    = 0x0000,
+        .second_card_device    = 0x0000,
+        .lb_vendor        = "gigabyte",
+        .lb_part        = "2761gxdk",
+        .name            = "GIGABYTE GA-2761GXDK",
+        .enable            = it87xx_probe_spi_flash,
+    },
+    {
+        .first_vendor        = 0x1022,
+        .first_device        = 0x7468,
+        .first_card_vendor    = 0x0000,
+        .first_card_device    = 0x0000,
+        .second_vendor        = 0x0000,
+        .second_device        = 0x0000,
+        .second_card_vendor    = 0x0000,
+        .second_card_device    = 0x0000,
+        .lb_vendor        = "iwill",
+        .lb_part        = "dk8_htx",
+        .name            = "IWILL DK8-HTX",
+        .enable            = w83627hf_gpio24_raise_2e,
+    },
+    {
+        .first_vendor        = 0x10de,
+        .first_device        = 0x005e,
+        .first_card_vendor    = 0x0000,
+        .first_card_device    = 0x0000,
+        .second_vendor        = 0x0000,
+        .second_device        = 0x0000,
+        .second_card_vendor    = 0x0000,
+        .second_card_device    = 0x0000,
+        .lb_vendor        = "msi",
+        .lb_part        = "k8n-neo3",
+        .name            = "MSI K8N Neo3",
+        .enable            = w83627thf_gpio4_4_raise_4e,
+    },
+    {
+        .first_vendor        = 0x1022,
+        .first_device        = 0x746B,
+        .first_card_vendor    = 0x1022,
+        .first_card_device    = 0x36C0,
+        .second_vendor        = 0x0000,
+        .second_device        = 0x0000,
+        .second_card_vendor    = 0x0000,
+        .second_card_device    = 0x0000,
+        .lb_vendor        = "AGAMI",
+        .lb_part        = "ARUMA",
+        .name            = "agami Aruma",
+        .enable            = w83627hf_gpio24_raise_2e,
+    },
+    {
+        .first_vendor        = 0x1106,
+        .first_device        = 0x3177,
+        .first_card_vendor    = 0x1106,
+        .first_card_device    = 0xAA01,
+        .second_vendor        = 0x1106,
+        .second_device        = 0x3123,
+        .second_card_vendor    = 0x1106,
+        .second_card_device    = 0xAA01,
+        .lb_vendor        = NULL,
+        .lb_part        = NULL,
+        .name            = "VIA EPIA M/MII/...",
+        .enable            = board_via_epia_m,
+    },
+    {
+        .first_vendor        = 0x1106,
+        .first_device        = 0x3177,
+        .first_card_vendor    = 0x1043,
+        .first_card_device    = 0x80A1,
+        .second_vendor        = 0x1106,
+        .second_device        = 0x3205,
+        .second_card_vendor    = 0x1043,
+        .second_card_device    = 0x8118,
+        .lb_vendor        = NULL,
+        .lb_part        = NULL,
+        .name            = "ASUS A7V8-MX SE",
+        .enable            = board_asus_a7v8x_mx,
+    },
+    {
+        .first_vendor        = 0x1106,
+        .first_device        = 0x3227,
+        .first_card_vendor    = 0x1106,
+        .first_card_device    = 0xAA01,
+        .second_vendor        = 0x1106,
+        .second_device        = 0x0259,
+        .second_card_vendor    = 0x1106,
+        .second_card_device    = 0xAA01,
+        .lb_vendor        = NULL,
+        .lb_part        = NULL,
+        .name            = "VIA EPIA SP",
+        .enable            = board_via_epia_sp,
+    },
+    {
+        .first_vendor        = 0x1106,
+        .first_device        = 0x0314,
+        .first_card_vendor    = 0x1106,
+        .first_card_device    = 0xaa08,
+        .second_vendor        = 0x1106,
+        .second_device        = 0x3227,
+        .second_card_vendor    = 0x1106,
+        .second_card_device    = 0xAA08,
+        .lb_vendor        = NULL,
+        .lb_part        = NULL,
+        .name            = "VIA EPIA-CN",
+        .enable            = board_via_epia_sp,
+    },
+    {
+        .first_vendor        = 0x8086,
+        .first_device        = 0x1076,
+        .first_card_vendor    = 0x8086,
+        .first_card_device    = 0x1176,
+        .second_vendor        = 0x1106,
+        .second_device        = 0x3059,
+        .second_card_vendor    = 0x10f1,
+        .second_card_device    = 0x2498,
+        .lb_vendor        = NULL,
+        .lb_part        = NULL,
+        .name            = "Tyan Tomcat K7M",
+        .enable            = board_asus_a7v8x_mx,
+    },
+    {
+        .first_vendor        = 0x10B9,
+        .first_device        = 0x1541,
+        .first_card_vendor    = 0x0000,
+        .first_card_device    = 0x0000,
+        .second_vendor        = 0x10B9,
+        .second_device        = 0x1533,
+        .second_card_vendor    = 0x0000,
+        .second_card_device    = 0x0000,
+        .lb_vendor        = "asus",
+        .lb_part        = "p5a",
+        .name            = "ASUS P5A",
+        .enable            = board_asus_p5a,
+    },
+    {
+        .first_vendor        = 0x1166,
+        .first_device        = 0x0205,
+        .first_card_vendor    = 0x1014,
+        .first_card_device    = 0x0347,
+        .second_vendor        = 0x0000,
+        .second_device        = 0x0000,
+        .second_card_vendor    = 0x0000,
+        .second_card_device    = 0x0000,
+        .lb_vendor        = "ibm",
+        .lb_part        = "x3455",
+        .name            = "IBM x3455",
+        .enable            = board_ibm_x3455,
+    },
+    {
+        .first_vendor        = 0x8086,
+        .first_device        = 0x7110,
+        .first_card_vendor    = 0x0000,
+        .first_card_device    = 0x0000,
+        .second_vendor        = 0x8086,
+        .second_device        = 0x7190,
+        .second_card_vendor    = 0x0000,
+        .second_card_device    = 0x0000,
+        .lb_vendor        = "epox",
+        .lb_part        = "ep-bx3",
+        .name            = "EPoX EP-BX3",
+        .enable            = board_epox_ep_bx3,
+    },
+    {
+        .first_vendor        = 0x8086,
+        .first_device        = 0x1130,
+        .first_card_vendor    = 0x0000,
+        .first_card_device    = 0x0000,
+        .second_vendor        = 0x105a,
+        .second_device        = 0x0d30,
+        .second_card_vendor    = 0x105a,
+        .second_card_device    = 0x4d33,
+        .lb_vendor        = "acorp",
+        .lb_part        = "6a815epd",
+        .name            = "Acorp 6A815EPD",
+        .enable            = board_acorp_6a815epd,
+    },
+    {
+        .first_vendor        = 0x1022,
+        .first_device        = 0x2090,
+        .first_card_vendor    = 0x0000,
+        .first_card_device    = 0x0000,
+        .second_vendor        = 0x1022,
+        .second_device        = 0x2080,
+        .second_card_vendor    = 0x0000,
+        .second_card_device    = 0x0000,
+        .lb_vendor        = "artecgroup",
+        .lb_part        = "dbe61",
+        .name            = "Artec Group DBE61",
+        .enable            = board_artecgroup_dbe6x,
+    },
+    {
+        .first_vendor        = 0x1022,
+        .first_device        = 0x2090,
+        .first_card_vendor    = 0x0000,
+        .first_card_device    = 0x0000,
+        .second_vendor        = 0x1022,
+        .second_device        = 0x2080,
+        .second_card_vendor    = 0x0000,
+        .second_card_device    = 0x0000,
+        .lb_vendor        = "artecgroup",
+        .lb_part        = "dbe62",
+        .name            = "Artec Group DBE62",
+        .enable            = board_artecgroup_dbe6x,
+    },
     /* Note: There are >= 2 version of the Kontron 986LCD-M/mITX! */
-    {0x8086, 0x27b8, 0x0000, 0x0000, 0x0000, 0x0000, 0x0000, 0x0000,
-     "kontron", "986lcd-m", "Kontron 986LCD-M", board_kontron_986lcd_m},
-    {0x10ec, 0x8168, 0x10ec, 0x8168, 0x104c, 0x8023, 0x104c, 0x8019,
-     "kontron", "986lcd-m", "Kontron 986LCD-M", board_kontron_986lcd_m},
-    {0x1106, 0x3149, 0x1565, 0x3206, 0x1106, 0x3344, 0x1565, 0x1202,
-     NULL, NULL, "BioStar P4M80-M4", board_biostar_p4m80_m4},
-    {0x1106, 0x3227, 0x1458, 0x5001, 0x10ec, 0x8139, 0x1458, 0xe000,
-     NULL, NULL, "GIGABYTE GA-7VT600", board_biostar_p4m80_m4},
-    {0x1106, 0x3149, 0x1462, 0x7094, 0x10ec, 0x8167, 0x1462, 0x094c,
-     NULL, NULL, "MSI K8T Neo2", w83627thf_gpio4_4_raise_2e},
-    {0, 0, 0, 0, 0, 0, 0, 0, NULL, NULL}    /* Keep this */
+    {
+        .first_vendor        = 0x8086,
+        .first_device        = 0x27b8,
+        .first_card_vendor    = 0x0000,
+        .first_card_device    = 0x0000,
+        .second_vendor        = 0x0000,
+        .second_device        = 0x0000,
+        .second_card_vendor    = 0x0000,
+        .second_card_device    = 0x0000,
+        .lb_vendor        = "kontron",
+        .lb_part        = "986lcd-m",
+        .name            = "Kontron 986LCD-M",
+        .enable            = board_kontron_986lcd_m,
+    },
+    {
+        .first_vendor        = 0x10ec,
+        .first_device        = 0x8168,
+        .first_card_vendor    = 0x10ec,
+        .first_card_device    = 0x8168,
+        .second_vendor        = 0x104c,
+        .second_device        = 0x8023,
+        .second_card_vendor    = 0x104c,
+        .second_card_device    = 0x8019,
+        .lb_vendor        = "kontron",
+        .lb_part        = "986lcd-m",
+        .name            = "Kontron 986LCD-M",
+        .enable            = board_kontron_986lcd_m,
+    },
+    {
+        .first_vendor        = 0x1106,
+        .first_device        = 0x3149,
+        .first_card_vendor    = 0x1565,
+        .first_card_device    = 0x3206,
+        .second_vendor        = 0x1106,
+        .second_device        = 0x3344,
+        .second_card_vendor    = 0x1565,
+        .second_card_device    = 0x1202,
+        .lb_vendor        = NULL,
+        .lb_part        = NULL,
+        .name            = "BioStar P4M80-M4",
+        .enable            = board_biostar_p4m80_m4,
+    },
+    {
+        .first_vendor        = 0x1106,
+        .first_device        = 0x3227,
+        .first_card_vendor    = 0x1458,
+        .first_card_device    = 0x5001,
+        .second_vendor        = 0x10ec,
+        .second_device        = 0x8139,
+        .second_card_vendor    = 0x1458,
+        .second_card_device    = 0xe000,
+        .lb_vendor        = NULL,
+        .lb_part        = NULL,
+        .name            = "GIGABYTE GA-7VT600",
+        .enable            = board_biostar_p4m80_m4,
+    },
+    {
+        .first_vendor        = 0x1106,
+        .first_device        = 0x3149,
+        .first_card_vendor    = 0x1462,
+        .first_card_device    = 0x7094,
+        .second_vendor        = 0x10ec,
+        .second_device        = 0x8167,
+        .second_card_vendor    = 0x1462,
+        .second_card_device    = 0x094c,
+        .lb_vendor        = NULL,
+        .lb_part        = NULL,
+        .name            = "MSI K8T Neo2",
+        .enable            = w83627thf_gpio4_4_raise_2e,
+    },
+    {
+        .first_vendor        = 0,
+        .first_device        = 0,
+        .first_card_vendor    = 0,
+        .first_card_device    = 0,
+        .second_vendor        = 0,
+        .second_device        = 0,
+        .second_card_vendor    = 0,
+        .second_card_device    = 0,
+        .lb_vendor        = NULL,
+        .lb_part        = NULL,
+    }    /* Keep this */
 };
 
 void print_supported_boards(void)
-------------- next part --------------
A non-text attachment was scrubbed...
Name: flashrom-board_pciid_enables.patch
Type: text/x-diff
Size: 13231 bytes
Desc: not available
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20090113/bb95dcf5/attachment.bin>

From rminnich at gmail.com  Tue Jan 13 22:03:23 2009
From: rminnich at gmail.com (ron minnich)
Date: Tue, 13 Jan 2009 13:03:23 -0800
Subject: [coreboot] [PATCH] Remove redundant unused tRCD entries from
	dbe61/dbe62 SPD value list.
In-Reply-To: <1231875772.14574.3.camel@martr-gentoo.artec>
References: <1231875772.14574.3.camel@martr-gentoo.artec>
Message-ID: <13426df10901131303gd647c35obcdd18a65526afcb@mail.gmail.com>

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



From libv at skynet.be  Wed Jan 14 00:34:07 2009
From: libv at skynet.be (Luc Verhaegen)
Date: Wed, 14 Jan 2009 00:34:07 +0100
Subject: [coreboot] [PATCH] flashrom patch easier board_pciid_enables
	parsing
In-Reply-To: <496D0157.9000403@free.fr>
References: <496D0157.9000403@free.fr>
Message-ID: <20090113233407.GA6508@skynet.be>

On Tue, Jan 13, 2009 at 10:02:15PM +0100, Stephan GUILLOUX wrote:
> 
>    Hello,
> 
> Similarly to flashchips array, this patch intends to make the table
> board_pciid_enables more readable.
> 
> Also in attachment.

For certain versions of readable. What real problem does this solve?

Luc Verhaegen.



From rminnich at gmail.com  Wed Jan 14 00:23:26 2009
From: rminnich at gmail.com (ron minnich)
Date: Tue, 13 Jan 2009 15:23:26 -0800
Subject: [coreboot] [PATCH] flashrom patch easier board_pciid_enables
	parsing
In-Reply-To: <20090113233407.GA6508@skynet.be>
References: <496D0157.9000403@free.fr> <20090113233407.GA6508@skynet.be>
Message-ID: <13426df10901131523j3444a6e5ya5f4aeb4321cb56f@mail.gmail.com>

On Tue, Jan 13, 2009 at 3:34 PM, Luc Verhaegen <libv at skynet.be> wrote:
> On Tue, Jan 13, 2009 at 10:02:15PM +0100, Stephan GUILLOUX wrote:
>>
>>    Hello,
>>
>> Similarly to flashchips array, this patch intends to make the table
>> board_pciid_enables more readable.
>>
>> Also in attachment.
>
> For certain versions of readable. What real problem does this solve?
>

1. Next time someone adds a new struct member, we avoid mistakes of
ordering of initializers
2. we avoid mistakes in the first place.

The .x = y stuff was added for a (good) reason, I think this is an improvement.

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



From peter at stuge.se  Wed Jan 14 00:33:31 2009
From: peter at stuge.se (Peter Stuge)
Date: Wed, 14 Jan 2009 00:33:31 +0100
Subject: [coreboot] [PATCH] flashrom patch easier
	board_pciid_enables	parsing
In-Reply-To: <13426df10901131523j3444a6e5ya5f4aeb4321cb56f@mail.gmail.com>
References: <496D0157.9000403@free.fr> <20090113233407.GA6508@skynet.be>
	<13426df10901131523j3444a6e5ya5f4aeb4321cb56f@mail.gmail.com>
Message-ID: <20090113233331.14411.qmail@stuge.se>

ron minnich wrote:
> >> Similarly to flashchips array, this patch intends to make the
> >> table board_pciid_enables more readable.
> >
> > For certain versions of readable. What real problem does this solve?
> 
> 1. Next time someone adds a new struct member, we avoid mistakes of
> ordering of initializers
> 2. we avoid mistakes in the first place.
> 
> The .x = y stuff was added for a (good) reason, I think this is an
> improvement.
> 
> Acked-by: Ronald G. Minnich <rminnich at gmail.com>

Sorry, but I really do not like these at all and I would much rather
see the chip table change back. There seemed to be general agreement
about that on IRC the other day as well.

If a mistake sneaks into the structs it will be trivial to fix..


//Peter



From stepan at coresystems.de  Wed Jan 14 00:55:45 2009
From: stepan at coresystems.de (Stefan Reinauer)
Date: Wed, 14 Jan 2009 00:55:45 +0100
Subject: [coreboot] [PATCH] flashrom patch easier	board_pciid_enables
 parsing
In-Reply-To: <20090113233331.14411.qmail@stuge.se>
References: <496D0157.9000403@free.fr>
	<20090113233407.GA6508@skynet.be>	<13426df10901131523j3444a6e5ya5f4aeb4321cb56f@mail.gmail.com>
	<20090113233331.14411.qmail@stuge.se>
Message-ID: <496D2A01.2060703@coresystems.de>

On 14.01.2009 0:33 Uhr, Peter Stuge wrote:
> ron minnich wrote:
>   
>>>> Similarly to flashchips array, this patch intends to make the
>>>> table board_pciid_enables more readable.
>>>>         
>>> For certain versions of readable. What real problem does this solve?
>>>       
>> 1. Next time someone adds a new struct member, we avoid mistakes of
>> ordering of initializers
>> 2. we avoid mistakes in the first place.
>>
>> The .x = y stuff was added for a (good) reason, I think this is an
>> improvement.
>>
>> Acked-by: Ronald G. Minnich <rminnich at gmail.com>
>>     
>
> Sorry, but I really do not like these at all and I would much rather
> see the chip table change back. There seemed to be general agreement
> about that on IRC the other day as well.
>   
Why?


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




From peter at stuge.se  Wed Jan 14 01:00:02 2009
From: peter at stuge.se (Peter Stuge)
Date: Wed, 14 Jan 2009 01:00:02 +0100
Subject: [coreboot] [PATCH] flashrom patch easier
	board_pciid_enables	parsing
In-Reply-To: <496D2A01.2060703@coresystems.de>
References: <496D0157.9000403@free.fr> <20090113233407.GA6508@skynet.be>
	<13426df10901131523j3444a6e5ya5f4aeb4321cb56f@mail.gmail.com>
	<20090113233331.14411.qmail@stuge.se>
	<496D2A01.2060703@coresystems.de>
Message-ID: <20090114000002.21484.qmail@stuge.se>

Stefan Reinauer wrote:
> > Sorry, but I really do not like these at all and I would much
> > rather see the chip table change back. There seemed to be general
> > agreement about that on IRC the other day as well.
> 
> Why?

I find it less readable. I find the "table" view much easier on the
eyes and brain than one-field-per-line.


//Peter



From libv at skynet.be  Wed Jan 14 02:28:39 2009
From: libv at skynet.be (Luc Verhaegen)
Date: Wed, 14 Jan 2009 02:28:39 +0100
Subject: [coreboot] [PATCH] flashrom patch easier board_pciid_enables
	parsing
In-Reply-To: <13426df10901131523j3444a6e5ya5f4aeb4321cb56f@mail.gmail.com>
References: <496D0157.9000403@free.fr> <20090113233407.GA6508@skynet.be>
	<13426df10901131523j3444a6e5ya5f4aeb4321cb56f@mail.gmail.com>
Message-ID: <20090114012839.GA7013@skynet.be>

On Tue, Jan 13, 2009 at 03:23:26PM -0800, ron minnich wrote:
> On Tue, Jan 13, 2009 at 3:34 PM, Luc Verhaegen <libv at skynet.be> wrote:
> > On Tue, Jan 13, 2009 at 10:02:15PM +0100, Stephan GUILLOUX wrote:
> >>
> >>    Hello,
> >>
> >> Similarly to flashchips array, this patch intends to make the table
> >> board_pciid_enables more readable.
> >>
> >> Also in attachment.
> >
> > For certain versions of readable. What real problem does this solve?
> >
> 
> 1. Next time someone adds a new struct member, we avoid mistakes of
> ordering of initializers
> 2. we avoid mistakes in the first place.
> 
> The .x = y stuff was added for a (good) reason, I think this is an improvement.
> 
> Acked-by: Ronald G. Minnich <rminnich at gmail.com>

I personally prefer (very long) single lines for a table like this. 

Single long lines make it easy to visually parse, provided the editor is
set wide enough to show the whole table. Long lines only stop people 
from easily parsing this code in a 80char terminal, but the 80char 
boundary is being significantly broken in ther files of flashrom. And it 
really is the least of the two possible pains, would you rather break 
readability for all or just for those who know that this table should 
not be edited when blindfold?

Strings should be padded to a common length, so that all but the last 
member is fully aligned. No errors can then occur when a new member is 
added, as the difference between entries become immediately clear. How 
often have new struct members been added since this table was created 
close to two years ago?

Luc Verhaegen.



From libv at skynet.be  Wed Jan 14 03:04:09 2009
From: libv at skynet.be (Luc Verhaegen)
Date: Wed, 14 Jan 2009 03:04:09 +0100
Subject: [coreboot] [flashrom] Asus A7N8X-E Support.
Message-ID: <20090114020409.GB7013@skynet.be>

With the discussion of the board_enables table, i ended up looking at 
the flashrom page on coreboot.org and spotted a bunch of boards that are 
known to not work.

The first one i looked at was the aforementioned and this here is what 
is needed for the flash enable of that board.

{
	uint8_t tmp;

	pci_write_byte(dev, 0x92, 0);

	tmp = pci_read_byte(dev, 0x6D);
	tmp |= 0x01;
	pci_write_byte(dev, 0x6D, tmp);
}	

While it seems that the second operation seems to match both ck804 and 
mcp55 chip enables, this is not true. The device used is 0:01.0 (ISA 
bridge) and not 0:01.1 (SMB controller).

I googled, but could not find a report to the coreboot (or linuxbios) 
list of this board being tested. Does anyone remember who reported this 
as broken?

Luc Verhaegen.



From svn at coreboot.org  Wed Jan 14 03:00:12 2009
From: svn at coreboot.org (coreboot)
Date: Wed, 14 Jan 2009 02:00:12 -0000
Subject: [coreboot] #120: flashrom failure to read
In-Reply-To: <053.0bcc838ee0a3c5de1df320df034ed573@coreboot.org>
References: <053.0bcc838ee0a3c5de1df320df034ed573@coreboot.org>
Message-ID: <062.911bc9df1b4b932b59c015da1f3683c9@coreboot.org>

#120: flashrom failure to read
----------------------------------+-----------------------------------------
   Reporter:  toc@?               |          Owner:  stuge   
       Type:  defect              |         Status:  assigned
   Priority:  major               |      Milestone:          
  Component:  flashrom            |        Version:          
   Keywords:  ich9                |   Dependencies:          
Patchstatus:  patch needs review  |  
----------------------------------+-----------------------------------------
Changes (by stuge):

  * keywords:  => ich9
  * owner:  somebody => stuge
  * patchstatus:  there is no patch => patch needs review
  * status:  new => assigned
  * version:  v2 =>


Comment:

 Thanks for the report!

 Please try the attached patch (also at http://stuge.se/fr.ich9lock.patch)
 and send an Acked-by line if it solves the problem.

 (Please see http://www.coreboot.org/Development_Guidelines#Reviews for a
 full description of how Acked-by-lines work/look.)

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


From svn at coreboot.org  Wed Jan 14 12:22:32 2009
From: svn at coreboot.org (svn at coreboot.org)
Date: Wed, 14 Jan 2009 12:22:32 +0100
Subject: [coreboot] r1115 - in coreboot-v3/mainboard/artecgroup: dbe61 dbe62
Message-ID: <mailman.2667.1355071469.16123.coreboot@coreboot.org>

Author: mraudsepp
Date: 2009-01-14 12:22:32 +0100 (Wed, 14 Jan 2009)
New Revision: 1115

Modified:
   coreboot-v3/mainboard/artecgroup/dbe61/initram.c
   coreboot-v3/mainboard/artecgroup/dbe62/initram.c
Log:
Remove redundant unused tRCD entries from dbe61/dbe62 SPD value list.

SPD_MIN_RAS_TO_CAS_DELAY is already set earlier in the list, so the alternative
constant tRCD in the end has no effect in the memory algorithm - remove them.

Signed-off-by: Mart Raudsepp <mart.raudsepp at artecdesign.ee>
Acked-by: Ronald G. Minnich <rminnich at gmail.com>

Modified: coreboot-v3/mainboard/artecgroup/dbe61/initram.c
===================================================================
--- coreboot-v3/mainboard/artecgroup/dbe61/initram.c	2009-01-09 18:12:08 UTC (rev 1114)
+++ coreboot-v3/mainboard/artecgroup/dbe61/initram.c	2009-01-14 11:22:32 UTC (rev 1115)
@@ -66,7 +66,6 @@
 	{SPD_REFRESH, 0x82},
 	{SPD_SDRAM_CYCLE_TIME_2ND, 0x0},
 	{SPD_SDRAM_CYCLE_TIME_3RD, 0x0},
-	{SPD_tRCD, 15},
 };
 
 /* Fake SPD for DBE61A - 128MB */
@@ -89,7 +88,6 @@
 	{SPD_REFRESH, 0x82},
 	{SPD_SDRAM_CYCLE_TIME_2ND, 0x0},
 	{SPD_SDRAM_CYCLE_TIME_3RD, 0x0},
-	{SPD_tRCD, 15},
 };
 
 /**

Modified: coreboot-v3/mainboard/artecgroup/dbe62/initram.c
===================================================================
--- coreboot-v3/mainboard/artecgroup/dbe62/initram.c	2009-01-09 18:12:08 UTC (rev 1114)
+++ coreboot-v3/mainboard/artecgroup/dbe62/initram.c	2009-01-14 11:22:32 UTC (rev 1115)
@@ -70,7 +70,6 @@
 	{SPD_REFRESH, 0x82},
 	{SPD_SDRAM_CYCLE_TIME_2ND, 0x0},
 	{SPD_SDRAM_CYCLE_TIME_3RD, 0x0},
-	{SPD_tRCD, 15},
 };
 
 /**




From c-d.hailfinger.devel.2006 at gmx.net  Wed Jan 14 12:40:07 2009
From: c-d.hailfinger.devel.2006 at gmx.net (Carl-Daniel Hailfinger)
Date: Wed, 14 Jan 2009 12:40:07 +0100
Subject: [coreboot] [PATCH] flashrom patch easier	board_pciid_enables
 parsing
In-Reply-To: <496D2A01.2060703@coresystems.de>
References: <496D0157.9000403@free.fr>	<20090113233407.GA6508@skynet.be>	<13426df10901131523j3444a6e5ya5f4aeb4321cb56f@mail.gmail.com>	<20090113233331.14411.qmail@stuge.se>
	<496D2A01.2060703@coresystems.de>
Message-ID: <496DCF17.3010001@gmx.net>

On 14.01.2009 00:55, Stefan Reinauer wrote:
> On 14.01.2009 0:33 Uhr, Peter Stuge wrote:
>   
>> ron minnich wrote:
>>   
>>     
>>>>> Similarly to flashchips array, this patch intends to make the
>>>>> table board_pciid_enables more readable.
>>>>>         
>>>>>           
>>>> For certain versions of readable. What real problem does this solve?
>>>>       
>>>>         
>>> 1. Next time someone adds a new struct member, we avoid mistakes of
>>> ordering of initializers
>>> 2. we avoid mistakes in the first place.
>>>
>>> The .x = y stuff was added for a (good) reason, I think this is an
>>> improvement.
>>>
>>> Acked-by: Ronald G. Minnich <rminnich at gmail.com>
>>>     
>>>       
>> Sorry, but I really do not like these at all and I would much rather
>> see the chip table change back. There seemed to be general agreement
>> about that on IRC the other day as well.
>>   
>>     
> Why?
>   

I was unaware of the general agreement on IRC although I was there.

The current table is horrible. Two lines per entry combine the worst of
both worlds.

And since I edit the wrong line every single time I touch that array,
the patch is

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

Regards,
Carl-Daniel

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




From svn at coreboot.org  Wed Jan 14 18:21:44 2009
From: svn at coreboot.org (coreboot)
Date: Wed, 14 Jan 2009 17:21:44 -0000
Subject: [coreboot] #120: flashrom failure to read
In-Reply-To: <053.0bcc838ee0a3c5de1df320df034ed573@coreboot.org>
References: <053.0bcc838ee0a3c5de1df320df034ed573@coreboot.org>
Message-ID: <062.f2110bf7bb4f72be2070fe77ae269352@coreboot.org>

#120: flashrom failure to read
----------------------------------+-----------------------------------------
   Reporter:  toc@?               |          Owner:  stuge   
       Type:  defect              |         Status:  assigned
   Priority:  major               |      Milestone:          
  Component:  flashrom            |        Version:          
   Keywords:  ich9                |   Dependencies:          
Patchstatus:  patch needs review  |  
----------------------------------+-----------------------------------------

Comment(by toc@?):

 Patch applied to svn revision 3860. Same results, i.e., disk file full of
 null bytes, verbose output complains about Opcode 3.

 Standard output:
 {{{
 Calibrating delay loop... OK.
 No coreboot table found.
 Found chipset "Intel ICH9R", enabling flash write... tried to set 0xdc to
 0x3 on Intel ICH9R failed (WARNING ONLY)
 FAILED!
 Found chip "Macronix MX25L8005" (1024 KB) at physical address 0xfff00000.
 Reading flash... done.
 }}}

 Verbose output
 {{{
 Calibrating delay loop... 663M loops per second, 100 myus = 200 us. OK.
 No coreboot table found.
 Found chipset "Intel ICH9R", enabling flash write...
 BIOS Lock Enable: enabled, BIOS Write Enable: disabled, BIOS_CNTL is 0x2
 tried to set 0xdc to 0x3 on Intel ICH9R failed (WARNING ONLY)

 Root Complex Register Block address = 0xfeda8000
 GCS = 0x410460: BIOS Interface Lock-Down: disabled, BOOT BIOS Straps: 0x1
 (SPI)
 Top Swap : not enabled
 SPIBAR = 0xfeda8000 + 0x3800
 0x00: 0x1fff (HSFS)
 FLOCKDN 0, FDV 0, FDOPSS 0, SCIP 1, BERASE 3, AEL 1, FCERR 1, FDONE 1
 0x50: 0x0000ffff (FRAP)
 BMWAG 0, BMRAG 0, BRWA 255, BRRA 255
 0x54: 0x00001fff (FREG0)
 0x58: 0x00001fff (FREG1)
 0x5C: 0x00001fff (FREG2)
 0x60: 0x00001fff (FREG3)
 0x64: 0x00001fff (FREG4)
 0x74: 0x00000000 (PR0)
 0x78: 0x00000000 (PR1)
 0x7C: 0x00000000 (PR2)
 0x80: 0x00000000 (PR3)
 0x84: 0x00000000 (PR4)
 0xB0: 0x00000000 (FDOC)
 Programming OPCODES... done
 SPI Read Configuration: prefetching disabled, caching enabled, FAILED!
 <<<snip>>>>
 Probing for Macronix MX25L8005, 1024 KB: RDID returned c2 20 14.
 probe_spi_rdid_generic: id1 0xc2, id2 0x2014
 Chip status register is 00
 Chip status register: Status Register Write Disable (SRWD) is not set
 Chip status register: Bit 6 is not set
 Chip status register: Bit 5 / Block Protect 3 (BP3) is not set
 Chip status register: Bit 4 / Block Protect 2 (BP2) is not set
 Chip status register: Bit 3 / Block Protect 1 (BP1) is not set
 Chip status register: Bit 2 / Block Protect 0 (BP0) is not set
 Chip status register: Write Enable Latch (WEL) is not set
 Chip status register: Write In Progress (WIP/BUSY) is not set
 Found chip "Macronix MX25L8005" (1024 KB) at physical address 0xfff00000.
 <<<<snip>>>>
 Reading flash... ich_spi_read_page: offset=0, number=256, buf=0xb7cb7008
 Opcode 3 not found.
 run OPCODE 0x03 failed
 Error readingdone.
 }}}

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


From ceolin at ulevel.com  Wed Jan 14 20:29:35 2009
From: ceolin at ulevel.com (=?ISO-8859-1?Q?Fabr=EDcio_Ceolin?=)
Date: Wed, 14 Jan 2009 16:29:35 -0300
Subject: [coreboot] flashrom on MCP73
Message-ID: <df845de0901141129t4b11c702l5345bacdfe70604b@mail.gmail.com>

Hi guys,

We are trying to make flashrom work on
http://www.ecs.com.tw/ECSWebSite/Products/ProductsDetail.aspx?detailid=858&CategoryID=1&DetailName=Specification&MenuID=1&LanID=0
Chipset MCP73 / SIP chipset Macronix MX25L8005.

We made modifications using a enable_flash_mcp55 function, but does't work.

 ./flashrom -V -c MX25L8005 -r -f rom
Calibrating delay loop... 627M loops per second, 100 myus = 199 us. OK.
No coreboot table found.
Found chipset "NVIDIA MCP73", enabling flash write... OK.
Probing for Macronix MX25L8005, 1024 KB: spi_command called, but no SPI
chipset/strapping detected
No EEPROM/flash device found.
Force read (-f -r -c) requested, forcing chip probe success:
Probing for Macronix MX25L8005, 1024 KB: Found chip "Macronix MX25L8005"
(1024 KB) at physical address 0xfff00000.
Force reading flash... spi_chip_read called, but no SPI chipset/strapping
detected 0
done.

How can I do works?

Are there any hints?

Thanks!

--

Fabr?cio Ceolin
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20090114/b263850e/attachment.html>

From yulrottmann at bitel.net  Wed Jan 14 22:08:11 2009
From: yulrottmann at bitel.net (Yul Rottmann)
Date: Wed, 14 Jan 2009 22:08:11 +0100
Subject: [coreboot] EHCI debug port finder
Message-ID: <496E543B.5070901@bitel.net>

Hello,
I come from [1] and maybe I can contribute a bit. First to the page
itself: "Finding the USB debug port" links to the script at [2], but
should actually link to [3] (the updated script). And in "Hardware
capability" the command 'lspci -vs' does not work here, the parameter -s
seems unknown.
Nonetheless I think I can contribute that my controller has a Debug
port. I cannot really verify because I don't have a cable to do so nor
am I able to run coreboot, but attached is a file that contains the
output of some commands. If I can do furthermore anything for you, feel
free to ask.
Thanks!
	Yul Rottmann


[1] http://www.coreboot.org/EHCI_Debug_Port
[2] http://coreboot.org/pipermail/coreboot/2008-September/038615.html
[3] http://coreboot.org/pipermail/coreboot/2008-September/038635.html
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: output.txt
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20090114/8c448b84/attachment.txt>

From peter at stuge.se  Thu Jan 15 01:36:40 2009
From: peter at stuge.se (Peter Stuge)
Date: Thu, 15 Jan 2009 01:36:40 +0100
Subject: [coreboot] flashrom on MCP73
In-Reply-To: <df845de0901141129t4b11c702l5345bacdfe70604b@mail.gmail.com>
References: <df845de0901141129t4b11c702l5345bacdfe70604b@mail.gmail.com>
Message-ID: <20090115003640.27649.qmail@stuge.se>

Hi,

Fabr?cio Ceolin wrote:
> We are trying to make flashrom work on
> http://www.ecs.com.tw/ECSWebSite/Products/ProductsDetail.aspx?detailid=858&CategoryID=1&DetailName=Specification&MenuID=1&LanID=0
> Chipset MCP73 / SIP chipset Macronix MX25L8005.
> 
> We made modifications using a enable_flash_mcp55 function, but
> does't work.
..

> How can I do works?
> 
> Are there any hints?

It's not that easy.

First you have to figure out what chip is the SPI bus master. I
suggest powering off the board and using a continuity tester to check
if most flash chip pins are connected to the superio chip. (The
superio is the chip between the PCI slots and the CMOS battery. It
may have an AMI BIOS sticker on it, just peel that off and look at
what is etched underneath.)

If there are no connections you're out of luck, because then the
MCP73 is the SPI bus master and there's little to no chance of
getting documentation from NVIDIA.

However, if the superio is the SPI bus master it should be possible
to get flashrom working. In this case please check which part number
your superio chip has. I found no good enough photos of the board
online to tell what it is, but the logo looks a little like Winbond.
I have a patch for Winbond superio SPI master support but it's a
little old by now and probably doesn't apply cleanly. It would have
to be fixed up, but it worked fine when I wrote it.

http://stuge.se/fr.wbsio_spi.d201gly.patch

Very likely you will also need a board enable routine for this
mainboard.


//Peter



From svn at coreboot.org  Thu Jan 15 01:48:24 2009
From: svn at coreboot.org (svn at coreboot.org)
Date: Thu, 15 Jan 2009 01:48:24 +0100
Subject: [coreboot] r3861 - trunk/util/flashrom
Message-ID: <mailman.2668.1355071469.16123.coreboot@coreboot.org>

Author: hailfinger
Date: 2009-01-15 01:48:24 +0100 (Thu, 15 Jan 2009)
New Revision: 3861

Modified:
   trunk/util/flashrom/board_enable.c
Log:
Similarly to flashchips array, this patch intends to make the table
board_pciid_enables more readable.

Signed-off-by: Stephan Guilloux <stephan.guilloux at free.fr>

> What real problem does this solve?

1. Next time someone adds a new struct member, we avoid mistakes of
ordering of initializers
2. we avoid mistakes in the first place.

The .x = y stuff was added for a (good) reason, I think this is an
improvement.
Acked-by: Ronald G. Minnich <rminnich at gmail.com>
Acked-by: Carl-Daniel Hailfinger <c-d.hailfinger.devel.2006 at gmx.net>


Modified: trunk/util/flashrom/board_enable.c
===================================================================
--- trunk/util/flashrom/board_enable.c	2009-01-13 14:32:27 UTC (rev 3860)
+++ trunk/util/flashrom/board_enable.c	2009-01-15 00:48:24 UTC (rev 3861)
@@ -626,58 +626,369 @@
 };
 
 struct board_pciid_enable board_pciid_enables[] = {
-	{0x1106, 0x0571, 0x1462, 0x7120, 0x0000, 0x0000, 0x0000, 0x0000,
-	 "msi", "kt4v", "MSI KT4V", board_msi_kt4v},
-	{0x8086, 0x1a30, 0x1043, 0x8070, 0x8086, 0x244b, 0x1043, 0x8028,
-	 NULL, NULL, "ASUS P4B266", ich2_gpio22_raise},
-	{0x10de, 0x0360, 0x0000, 0x0000, 0x0000, 0x0000, 0x0000, 0x0000,
-	 "gigabyte", "m57sli", "GIGABYTE GA-M57SLI-S4", it87xx_probe_spi_flash},
-	{0x10de, 0x03e0, 0x0000, 0x0000, 0x0000, 0x0000, 0x0000, 0x0000,
-	 "gigabyte", "m61p", "GIGABYTE GA-M61P-S3", it87xx_probe_spi_flash},
-	{0x1002, 0x4398, 0x1458, 0x5004, 0x1002, 0x4385, 0x1458, 0x4385,
-	 NULL, NULL, "GIGABYTE GA-MA78G-DS3H", it87xx_probe_spi_flash},
-	{0x1039, 0x0761, 0x0000, 0x0000, 0x0000, 0x0000, 0x0000, 0x0000,
-	 "gigabyte", "2761gxdk", "GIGABYTE GA-2761GXDK", it87xx_probe_spi_flash},
-	{0x1022, 0x7468, 0x0000, 0x0000, 0x0000, 0x0000, 0x0000, 0x0000,
-	 "iwill", "dk8_htx", "IWILL DK8-HTX", w83627hf_gpio24_raise_2e},
-	{0x10de, 0x005e, 0x0000, 0x0000, 0x0000, 0x0000, 0x0000, 0x0000,
-	 "msi", "k8n-neo3", "MSI K8N Neo3", w83627thf_gpio4_4_raise_4e},
-	{0x1022, 0x746B, 0x1022, 0x36C0, 0x0000, 0x0000, 0x0000, 0x0000,
-	 "AGAMI", "ARUMA", "agami Aruma", w83627hf_gpio24_raise_2e},
-	{0x1106, 0x3177, 0x1106, 0xAA01, 0x1106, 0x3123, 0x1106, 0xAA01,
-	 NULL, NULL, "VIA EPIA M/MII/...", board_via_epia_m},
-	{0x1106, 0x3177, 0x1043, 0x80A1, 0x1106, 0x3205, 0x1043, 0x8118,
-	 NULL, NULL, "ASUS A7V8-MX SE", board_asus_a7v8x_mx},
-	{0x1106, 0x3227, 0x1106, 0xAA01, 0x1106, 0x0259, 0x1106, 0xAA01,
-	 NULL, NULL, "VIA EPIA SP", board_via_epia_sp},
-	{0x1106, 0x0314, 0x1106, 0xaa08, 0x1106, 0x3227, 0x1106, 0xAA08,
-	 NULL, NULL, "VIA EPIA-CN", board_via_epia_sp},
-	{0x8086, 0x1076, 0x8086, 0x1176, 0x1106, 0x3059, 0x10f1, 0x2498,
-	 NULL, NULL, "Tyan Tomcat K7M", board_asus_a7v8x_mx},
-	{0x10B9, 0x1541, 0x0000, 0x0000, 0x10B9, 0x1533, 0x0000, 0x0000,
-	 "asus", "p5a", "ASUS P5A", board_asus_p5a},
-	{0x1166, 0x0205, 0x1014, 0x0347, 0x0000, 0x0000, 0x0000, 0x0000,
-	 "ibm", "x3455", "IBM x3455", board_ibm_x3455},
-	{0x8086, 0x7110, 0x0000, 0x0000, 0x8086, 0x7190, 0x0000, 0x0000,
-	 "epox", "ep-bx3", "EPoX EP-BX3", board_epox_ep_bx3},
-	{0x8086, 0x1130, 0x0000, 0x0000, 0x105a, 0x0d30, 0x105a, 0x4d33,
-	 "acorp", "6a815epd", "Acorp 6A815EPD", board_acorp_6a815epd},
-	{0x1022, 0x2090, 0x0000, 0x0000, 0x1022, 0x2080, 0x0000, 0x0000,
-	 "artecgroup", "dbe61", "Artec Group DBE61", board_artecgroup_dbe6x},
-	{0x1022, 0x2090, 0x0000, 0x0000, 0x1022, 0x2080, 0x0000, 0x0000,
-	 "artecgroup", "dbe62", "Artec Group DBE62", board_artecgroup_dbe6x},
+	{
+		.first_vendor		= 0x1106,
+		.first_device		= 0x0571,
+		.first_card_vendor	= 0x1462,
+		.first_card_device	= 0x7120,
+		.second_vendor		= 0x0000,
+		.second_device		= 0x0000,
+		.second_card_vendor	= 0x0000,
+		.second_card_device	= 0x0000,
+		.lb_vendor		= "msi",
+		.lb_part		= "kt4v",
+		.name			= "MSI KT4V",
+		.enable			= board_msi_kt4v,
+	},
+	{
+		.first_vendor		= 0x8086,
+		.first_device		= 0x1a30,
+		.first_card_vendor	= 0x1043,
+		.first_card_device	= 0x8070,
+		.second_vendor		= 0x8086,
+		.second_device		= 0x244b,
+		.second_card_vendor	= 0x1043,
+		.second_card_device	= 0x8028,
+		.lb_vendor		= NULL,
+		.lb_part		= NULL,
+		.name			= "ASUS P4B266",
+		.enable			= ich2_gpio22_raise,
+	},
+	{
+		.first_vendor		= 0x10de,
+		.first_device		= 0x0360,
+		.first_card_vendor	= 0x0000,
+		.first_card_device	= 0x0000,
+		.second_vendor		= 0x0000,
+		.second_device		= 0x0000,
+		.second_card_vendor	= 0x0000,
+		.second_card_device	= 0x0000,
+		.lb_vendor		= "gigabyte",
+		.lb_part		= "m57sli",
+		.name			= "GIGABYTE GA-M57SLI-S4",
+		.enable			= it87xx_probe_spi_flash,
+	},
+	{
+		.first_vendor		= 0x10de,
+		.first_device		= 0x03e0,
+		.first_card_vendor	= 0x0000,
+		.first_card_device	= 0x0000,
+		.second_vendor		= 0x0000,
+		.second_device		= 0x0000,
+		.second_card_vendor	= 0x0000,
+		.second_card_device	= 0x0000,
+		.lb_vendor		= "gigabyte",
+		.lb_part		= "m61p",
+		.name			= "GIGABYTE GA-M61P-S3",
+		.enable			= it87xx_probe_spi_flash,
+	},
+	{
+		.first_vendor		= 0x1002,
+		.first_device		= 0x4398,
+		.first_card_vendor	= 0x1458,
+		.first_card_device	= 0x5004,
+		.second_vendor		= 0x1002,
+		.second_device		= 0x4385,
+		.second_card_vendor	= 0x1458,
+		.second_card_device	= 0x4385,
+		.lb_vendor		= NULL,
+		.lb_part		= NULL,
+		.name			= "GIGABYTE GA-MA78G-DS3H",
+		.enable			= it87xx_probe_spi_flash,
+	},
+	{
+		.first_vendor		= 0x1039,
+		.first_device		= 0x0761,
+		.first_card_vendor	= 0x0000,
+		.first_card_device	= 0x0000,
+		.second_vendor		= 0x0000,
+		.second_device		= 0x0000,
+		.second_card_vendor	= 0x0000,
+		.second_card_device	= 0x0000,
+		.lb_vendor		= "gigabyte",
+		.lb_part		= "2761gxdk",
+		.name			= "GIGABYTE GA-2761GXDK",
+		.enable			= it87xx_probe_spi_flash,
+	},
+	{
+		.first_vendor		= 0x1022,
+		.first_device		= 0x7468,
+		.first_card_vendor	= 0x0000,
+		.first_card_device	= 0x0000,
+		.second_vendor		= 0x0000,
+		.second_device		= 0x0000,
+		.second_card_vendor	= 0x0000,
+		.second_card_device	= 0x0000,
+		.lb_vendor		= "iwill",
+		.lb_part		= "dk8_htx",
+		.name			= "IWILL DK8-HTX",
+		.enable			= w83627hf_gpio24_raise_2e,
+	},
+	{
+		.first_vendor		= 0x10de,
+		.first_device		= 0x005e,
+		.first_card_vendor	= 0x0000,
+		.first_card_device	= 0x0000,
+		.second_vendor		= 0x0000,
+		.second_device		= 0x0000,
+		.second_card_vendor	= 0x0000,
+		.second_card_device	= 0x0000,
+		.lb_vendor		= "msi",
+		.lb_part		= "k8n-neo3",
+		.name			= "MSI K8N Neo3",
+		.enable			= w83627thf_gpio4_4_raise_4e,
+	},
+	{
+		.first_vendor		= 0x1022,
+		.first_device		= 0x746B,
+		.first_card_vendor	= 0x1022,
+		.first_card_device	= 0x36C0,
+		.second_vendor		= 0x0000,
+		.second_device		= 0x0000,
+		.second_card_vendor	= 0x0000,
+		.second_card_device	= 0x0000,
+		.lb_vendor		= "AGAMI",
+		.lb_part		= "ARUMA",
+		.name			= "agami Aruma",
+		.enable			= w83627hf_gpio24_raise_2e,
+	},
+	{
+		.first_vendor		= 0x1106,
+		.first_device		= 0x3177,
+		.first_card_vendor	= 0x1106,
+		.first_card_device	= 0xAA01,
+		.second_vendor		= 0x1106,
+		.second_device		= 0x3123,
+		.second_card_vendor	= 0x1106,
+		.second_card_device	= 0xAA01,
+		.lb_vendor		= NULL,
+		.lb_part		= NULL,
+		.name			= "VIA EPIA M/MII/...",
+		.enable			= board_via_epia_m,
+	},
+	{
+		.first_vendor		= 0x1106,
+		.first_device		= 0x3177,
+		.first_card_vendor	= 0x1043,
+		.first_card_device	= 0x80A1,
+		.second_vendor		= 0x1106,
+		.second_device		= 0x3205,
+		.second_card_vendor	= 0x1043,
+		.second_card_device	= 0x8118,
+		.lb_vendor		= NULL,
+		.lb_part		= NULL,
+		.name			= "ASUS A7V8-MX SE",
+		.enable			= board_asus_a7v8x_mx,
+	},
+	{
+		.first_vendor		= 0x1106,
+		.first_device		= 0x3227,
+		.first_card_vendor	= 0x1106,
+		.first_card_device	= 0xAA01,
+		.second_vendor		= 0x1106,
+		.second_device		= 0x0259,
+		.second_card_vendor	= 0x1106,
+		.second_card_device	= 0xAA01,
+		.lb_vendor		= NULL,
+		.lb_part		= NULL,
+		.name			= "VIA EPIA SP",
+		.enable			= board_via_epia_sp,
+	},
+	{
+		.first_vendor		= 0x1106,
+		.first_device		= 0x0314,
+		.first_card_vendor	= 0x1106,
+		.first_card_device	= 0xaa08,
+		.second_vendor		= 0x1106,
+		.second_device		= 0x3227,
+		.second_card_vendor	= 0x1106,
+		.second_card_device	= 0xAA08,
+		.lb_vendor		= NULL,
+		.lb_part		= NULL,
+		.name			= "VIA EPIA-CN",
+		.enable			= board_via_epia_sp,
+	},
+	{
+		.first_vendor		= 0x8086,
+		.first_device		= 0x1076,
+		.first_card_vendor	= 0x8086,
+		.first_card_device	= 0x1176,
+		.second_vendor		= 0x1106,
+		.second_device		= 0x3059,
+		.second_card_vendor	= 0x10f1,
+		.second_card_device	= 0x2498,
+		.lb_vendor		= NULL,
+		.lb_part		= NULL,
+		.name			= "Tyan Tomcat K7M",
+		.enable			= board_asus_a7v8x_mx,
+	},
+	{
+		.first_vendor		= 0x10B9,
+		.first_device		= 0x1541,
+		.first_card_vendor	= 0x0000,
+		.first_card_device	= 0x0000,
+		.second_vendor		= 0x10B9,
+		.second_device		= 0x1533,
+		.second_card_vendor	= 0x0000,
+		.second_card_device	= 0x0000,
+		.lb_vendor		= "asus",
+		.lb_part		= "p5a",
+		.name			= "ASUS P5A",
+		.enable			= board_asus_p5a,
+	},
+	{
+		.first_vendor		= 0x1166,
+		.first_device		= 0x0205,
+		.first_card_vendor	= 0x1014,
+		.first_card_device	= 0x0347,
+		.second_vendor		= 0x0000,
+		.second_device		= 0x0000,
+		.second_card_vendor	= 0x0000,
+		.second_card_device	= 0x0000,
+		.lb_vendor		= "ibm",
+		.lb_part		= "x3455",
+		.name			= "IBM x3455",
+		.enable			= board_ibm_x3455,
+	},
+	{
+		.first_vendor		= 0x8086,
+		.first_device		= 0x7110,
+		.first_card_vendor	= 0x0000,
+		.first_card_device	= 0x0000,
+		.second_vendor		= 0x8086,
+		.second_device		= 0x7190,
+		.second_card_vendor	= 0x0000,
+		.second_card_device	= 0x0000,
+		.lb_vendor		= "epox",
+		.lb_part		= "ep-bx3",
+		.name			= "EPoX EP-BX3",
+		.enable			= board_epox_ep_bx3,
+	},
+	{
+		.first_vendor		= 0x8086,
+		.first_device		= 0x1130,
+		.first_card_vendor	= 0x0000,
+		.first_card_device	= 0x0000,
+		.second_vendor		= 0x105a,
+		.second_device		= 0x0d30,
+		.second_card_vendor	= 0x105a,
+		.second_card_device	= 0x4d33,
+		.lb_vendor		= "acorp",
+		.lb_part		= "6a815epd",
+		.name			= "Acorp 6A815EPD",
+		.enable			= board_acorp_6a815epd,
+	},
+	{
+		.first_vendor		= 0x1022,
+		.first_device		= 0x2090,
+		.first_card_vendor	= 0x0000,
+		.first_card_device	= 0x0000,
+		.second_vendor		= 0x1022,
+		.second_device		= 0x2080,
+		.second_card_vendor	= 0x0000,
+		.second_card_device	= 0x0000,
+		.lb_vendor		= "artecgroup",
+		.lb_part		= "dbe61",
+		.name			= "Artec Group DBE61",
+		.enable			= board_artecgroup_dbe6x,
+	},
+	{
+		.first_vendor		= 0x1022,
+		.first_device		= 0x2090,
+		.first_card_vendor	= 0x0000,
+		.first_card_device	= 0x0000,
+		.second_vendor		= 0x1022,
+		.second_device		= 0x2080,
+		.second_card_vendor	= 0x0000,
+		.second_card_device	= 0x0000,
+		.lb_vendor		= "artecgroup",
+		.lb_part		= "dbe62",
+		.name			= "Artec Group DBE62",
+		.enable			= board_artecgroup_dbe6x,
+	},
 	/* Note: There are >= 2 version of the Kontron 986LCD-M/mITX! */
-	{0x8086, 0x27b8, 0x0000, 0x0000, 0x0000, 0x0000, 0x0000, 0x0000,
-	 "kontron", "986lcd-m", "Kontron 986LCD-M", board_kontron_986lcd_m},
-	{0x10ec, 0x8168, 0x10ec, 0x8168, 0x104c, 0x8023, 0x104c, 0x8019,
-	 "kontron", "986lcd-m", "Kontron 986LCD-M", board_kontron_986lcd_m},
-	{0x1106, 0x3149, 0x1565, 0x3206, 0x1106, 0x3344, 0x1565, 0x1202,
-	 NULL, NULL, "BioStar P4M80-M4", board_biostar_p4m80_m4},
-	{0x1106, 0x3227, 0x1458, 0x5001, 0x10ec, 0x8139, 0x1458, 0xe000,
-	 NULL, NULL, "GIGABYTE GA-7VT600", board_biostar_p4m80_m4},
-	{0x1106, 0x3149, 0x1462, 0x7094, 0x10ec, 0x8167, 0x1462, 0x094c,
-	 NULL, NULL, "MSI K8T Neo2", w83627thf_gpio4_4_raise_2e},
-	{0, 0, 0, 0, 0, 0, 0, 0, NULL, NULL}	/* Keep this */
+	{
+		.first_vendor		= 0x8086,
+		.first_device		= 0x27b8,
+		.first_card_vendor	= 0x0000,
+		.first_card_device	= 0x0000,
+		.second_vendor		= 0x0000,
+		.second_device		= 0x0000,
+		.second_card_vendor	= 0x0000,
+		.second_card_device	= 0x0000,
+		.lb_vendor		= "kontron",
+		.lb_part		= "986lcd-m",
+		.name			= "Kontron 986LCD-M",
+		.enable			= board_kontron_986lcd_m,
+	},
+	{
+		.first_vendor		= 0x10ec,
+		.first_device		= 0x8168,
+		.first_card_vendor	= 0x10ec,
+		.first_card_device	= 0x8168,
+		.second_vendor		= 0x104c,
+		.second_device		= 0x8023,
+		.second_card_vendor	= 0x104c,
+		.second_card_device	= 0x8019,
+		.lb_vendor		= "kontron",
+		.lb_part		= "986lcd-m",
+		.name			= "Kontron 986LCD-M",
+		.enable			= board_kontron_986lcd_m,
+	},
+	{
+		.first_vendor		= 0x1106,
+		.first_device		= 0x3149,
+		.first_card_vendor	= 0x1565,
+		.first_card_device	= 0x3206,
+		.second_vendor		= 0x1106,
+		.second_device		= 0x3344,
+		.second_card_vendor	= 0x1565,
+		.second_card_device	= 0x1202,
+		.lb_vendor		= NULL,
+		.lb_part		= NULL,
+		.name			= "BioStar P4M80-M4",
+		.enable			= board_biostar_p4m80_m4,
+	},
+	{
+		.first_vendor		= 0x1106,
+		.first_device		= 0x3227,
+		.first_card_vendor	= 0x1458,
+		.first_card_device	= 0x5001,
+		.second_vendor		= 0x10ec,
+		.second_device		= 0x8139,
+		.second_card_vendor	= 0x1458,
+		.second_card_device	= 0xe000,
+		.lb_vendor		= NULL,
+		.lb_part		= NULL,
+		.name			= "GIGABYTE GA-7VT600",
+		.enable			= board_biostar_p4m80_m4,
+	},
+	{
+		.first_vendor		= 0x1106,
+		.first_device		= 0x3149,
+		.first_card_vendor	= 0x1462,
+		.first_card_device	= 0x7094,
+		.second_vendor		= 0x10ec,
+		.second_device		= 0x8167,
+		.second_card_vendor	= 0x1462,
+		.second_card_device	= 0x094c,
+		.lb_vendor		= NULL,
+		.lb_part		= NULL,
+		.name			= "MSI K8T Neo2",
+		.enable			= w83627thf_gpio4_4_raise_2e,
+	},
+	{
+		.first_vendor		= 0,
+		.first_device		= 0,
+		.first_card_vendor	= 0,
+		.first_card_device	= 0,
+		.second_vendor		= 0,
+		.second_device		= 0,
+		.second_card_vendor	= 0,
+		.second_card_device	= 0,
+		.lb_vendor		= NULL,
+		.lb_part		= NULL,
+	}	/* Keep this */
 };
 
 void print_supported_boards(void)




From c-d.hailfinger.devel.2006 at gmx.net  Thu Jan 15 01:48:59 2009
From: c-d.hailfinger.devel.2006 at gmx.net (Carl-Daniel Hailfinger)
Date: Thu, 15 Jan 2009 01:48:59 +0100
Subject: [coreboot] [PATCH] flashrom patch easier board_pciid_enables
 parsing
In-Reply-To: <496D0157.9000403@free.fr>
References: <496D0157.9000403@free.fr>
Message-ID: <496E87FB.5080605@gmx.net>

On 13.01.2009 22:02, Stephan GUILLOUX wrote:
>
>    Hello,
>
> Similarly to flashchips array, this patch intends to make the table
> board_pciid_enables more readable.
>
> Also in attachment.
>
>  Stephan.
>
> Signed-off-by: Stephan Guilloux <mailto:stephan.guilloux at free.fr>

Thanks, r3861.

Regards,
Carl-Daniel

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




From peter at stuge.se  Thu Jan 15 02:14:12 2009
From: peter at stuge.se (Peter Stuge)
Date: Thu, 15 Jan 2009 02:14:12 +0100
Subject: [coreboot] [PATCH] flashrom patch easier	board_pciid_enables
	parsing
In-Reply-To: <496E87FB.5080605@gmx.net>
References: <496D0157.9000403@free.fr> <496E87FB.5080605@gmx.net>
Message-ID: <20090115011412.6243.qmail@stuge.se>

Carl-Daniel Hailfinger wrote:
> r3861

..just horrible..



From peter at stuge.se  Thu Jan 15 02:32:35 2009
From: peter at stuge.se (Peter Stuge)
Date: Thu, 15 Jan 2009 02:32:35 +0100
Subject: [coreboot] EHCI debug port finder
In-Reply-To: <496E543B.5070901@bitel.net>
References: <496E543B.5070901@bitel.net>
Message-ID: <20090115013235.10266.qmail@stuge.se>

Yul Rottmann wrote:
> I come from [1] and maybe I can contribute a bit. First to the page
> itself: "Finding the USB debug port" links to the script at [2], but
> should actually link to [3] (the updated script). And in "Hardware
> capability" the command 'lspci -vs' does not work here, the
> parameter -s seems unknown.

Run lspci -h and look under "Selection of devices" - it should work.
But the sh fu may be broken by now.


> Nonetheless I think I can contribute that my controller has a Debug
> port. I cannot really verify because I don't have a cable to do so
> nor am I able to run coreboot, but attached is a file that contains
> the output of some commands.

Thanks. I updated the EHCI page with the SB700.


> If I can do furthermore anything for you, feel free to ask.

It's interesting that you have two EHCI devices with a debug port
each. I don't know what coreboot does in this case. Not much to do
since you can't test, but you could look around at the port registers
to see if you can locate if the debug port(s!) actually go(es)
anywhere on the board.


//Peter



From libv at skynet.be  Thu Jan 15 03:09:10 2009
From: libv at skynet.be (Luc Verhaegen)
Date: Thu, 15 Jan 2009 03:09:10 +0100
Subject: [coreboot] [PATCH] flashrom patch easier	board_pciid_enables
	parsing
In-Reply-To: <20090115011412.6243.qmail@stuge.se>
References: <496D0157.9000403@free.fr> <496E87FB.5080605@gmx.net>
	<20090115011412.6243.qmail@stuge.se>
Message-ID: <20090115020910.GA10161@skynet.be>

On Thu, Jan 15, 2009 at 02:14:12AM +0100, Peter Stuge wrote:
> Carl-Daniel Hailfinger wrote:
> > r3861
> 
> ..just horrible..

Acked-By Luc Verhaegen <libv at skynet.be>



From svn at coreboot.org  Thu Jan 15 03:13:18 2009
From: svn at coreboot.org (svn at coreboot.org)
Date: Thu, 15 Jan 2009 03:13:18 +0100
Subject: [coreboot] r3862 - trunk/util/flashrom
Message-ID: <mailman.2669.1355071469.16123.coreboot@coreboot.org>

Author: stuge
Date: 2009-01-15 03:13:18 +0100 (Thu, 15 Jan 2009)
New Revision: 3862

Modified:
   trunk/util/flashrom/ichspi.c
Log:
flashrom: Add ICH opcode debugging.

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


Modified: trunk/util/flashrom/ichspi.c
===================================================================
--- trunk/util/flashrom/ichspi.c	2009-01-15 00:48:24 UTC (rev 3861)
+++ trunk/util/flashrom/ichspi.c	2009-01-15 02:13:18 UTC (rev 3862)
@@ -313,6 +313,7 @@
 		opmenu[1] |= ((uint32_t) op->opcode[a].opcode) << ((a - 4) * 8);
 	}
 
+	printf_debug("\n%s: preop=%04x optype=%04x opmenu=%08x%08x\n", __func__, preop, optype, opmenu[0], opmenu[1]);
 	switch (flashbus) {
 	case BUS_TYPE_ICH7_SPI:
 	case BUS_TYPE_VIA_SPI:




From engineerguy3737 at yahoo.com  Thu Jan 15 03:13:08 2009
From: engineerguy3737 at yahoo.com (Dan Lykowski)
Date: Wed, 14 Jan 2009 18:13:08 -0800 (PST)
Subject: [coreboot] [PATCH] fixes ram init when processor doesn't have FID
	control
Message-ID: <367509.59922.qm@web57003.mail.re3.yahoo.com>

This patch fixes ram init problems when using the 9W Sempron part.

Trying to read the FIDVID register when the processor does not support FIDVID control causes a GP Fault. This patch reads the startup FID from a different MSR. I have verified this patch to work on the dbm690t platform.

This patch includes the changes I submitted a few days ago that haven't been acked yet. 


I now have a working Coreboot system. ( Although SATA needs a little work so I am not booting linux yet. ) But at least FILO comes up.

Dan Lykowski

Signed-off-by: Dan Lykowski <lykowdk at gmail.com>



      
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20090114/08ec391d/attachment.html>

From svn at coreboot.org  Thu Jan 15 03:14:44 2009
From: svn at coreboot.org (coreboot)
Date: Thu, 15 Jan 2009 02:14:44 -0000
Subject: [coreboot] #120: flashrom failure to read
In-Reply-To: <053.0bcc838ee0a3c5de1df320df034ed573@coreboot.org>
References: <053.0bcc838ee0a3c5de1df320df034ed573@coreboot.org>
Message-ID: <062.222882c837e106a74ae1d2a016ebf21e@coreboot.org>

#120: flashrom failure to read
----------------------------------+-----------------------------------------
   Reporter:  toc@?               |          Owner:  stuge   
       Type:  defect              |         Status:  assigned
   Priority:  major               |      Milestone:          
  Component:  flashrom            |        Version:          
   Keywords:  ich9                |   Dependencies:          
Patchstatus:  patch needs review  |  
----------------------------------+-----------------------------------------

Comment(by stuge):

 Ok, the patch worked, but there is some other problem. I just committed a
 small change that adds useful debugging in r3862. Please update and resend
 output from running with -V.

-- 
Ticket URL: <http://tracker.coreboot.org/trac/coreboot/ticket/120#comment:3>
coreboot <http://www.coreboot.org/>


From engineerguy3737 at yahoo.com  Thu Jan 15 03:15:01 2009
From: engineerguy3737 at yahoo.com (Dan Lykowski)
Date: Wed, 14 Jan 2009 18:15:01 -0800 (PST)
Subject: [coreboot] [PATCH] fixes ram init when processor doesn't have
	FID control
Message-ID: <429720.60302.qm@web57003.mail.re3.yahoo.com>

So now I will remember to attach the patch.

Dan Lykowski

Signed-off-by: Dan Lykowski <lykowdk at gmail.com>

--- On Wed, 1/14/09, Dan Lykowski <engineerguy3737 at yahoo.com> wrote:

From: Dan Lykowski <engineerguy3737 at yahoo.com>
Subject: [coreboot] [PATCH] fixes ram init when processor doesn't have FID control
To: coreboot at coreboot.org
Date: Wednesday, January 14, 2009, 9:13 PM

This patch fixes ram init problems when using the 9W Sempron part.

Trying to read the FIDVID register when the processor does not support FIDVID control causes a GP Fault. This patch reads the startup FID from a different MSR. I have verified this patch to work on the dbm690t platform.

This patch includes the changes I submitted a few days ago that haven't been acked yet. 


I now have a working Coreboot system. ( Although SATA needs a little work so I am not booting linux yet. ) But at least FILO comes up.

Dan Lykowski

Signed-off-by: Dan Lykowski <lykowdk at gmail.com>





      
-----Inline Attachment Follows-----

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


      
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20090114/d05866c0/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: ram_init_FID_detection.patch
Type: text/x-patch
Size: 1807 bytes
Desc: not available
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20090114/d05866c0/attachment.patch>

From svn at coreboot.org  Thu Jan 15 03:21:27 2009
From: svn at coreboot.org (svn at coreboot.org)
Date: Thu, 15 Jan 2009 03:21:27 +0100
Subject: [coreboot] r3863 - trunk/coreboot-v2/src/northbridge/amd/amdk8
Message-ID: <mailman.2670.1355071469.16123.coreboot@coreboot.org>

Author: stuge
Date: 2009-01-15 03:21:27 +0100 (Thu, 15 Jan 2009)
New Revision: 3863

Modified:
   trunk/coreboot-v2/src/northbridge/amd/amdk8/raminit_f.c
   trunk/coreboot-v2/src/northbridge/amd/amdk8/raminit_f_dqs.c
Log:
amdk8: This patch fixes ram init problems when using the 9W Sempron part.

Trying to read the FIDVID register when the processor does not support FIDVID
control causes a GP Fault. This patch reads the startup FID from a different
MSR. I have verified this patch to work on the dbm690t platform.

Signed-off-by: Dan Lykowski <lykowdk at gmail.com>
Acked-by: Peter Stuge <peter at stuge.se>


Modified: trunk/coreboot-v2/src/northbridge/amd/amdk8/raminit_f.c
===================================================================
--- trunk/coreboot-v2/src/northbridge/amd/amdk8/raminit_f.c	2009-01-15 02:13:18 UTC (rev 3862)
+++ trunk/coreboot-v2/src/northbridge/amd/amdk8/raminit_f.c	2009-01-15 02:21:27 UTC (rev 3863)
@@ -1656,15 +1656,29 @@
 	  /*15*/   200, 160, 120, 100,
 	};
 
-	unsigned fid_cur;
+	
 	int index;
-
 	msr_t msr;
-	msr = rdmsr(0xc0010042);
-	fid_cur = msr.lo & 0x3f;
 
-	index = fid_cur>>1;
+	/* Check for FID control support */
+	struct cpuid_result cpuid1;
+	cpuid1 = cpuid(0x8000007);
+	if( cpuid1.edx & 0x02 ) {
+		/* Use current FID */
+		unsigned fid_cur;
+		msr = rdmsr(0xc0010042);
+		fid_cur = msr.lo & 0x3f;
 
+		index = fid_cur>>1;
+	} else {
+		/* Use startup FID */
+		unsigned fid_start;
+		msr = rdmsr(0xc0010015);
+		fid_start = (msr.lo & (0x3f << 24));
+		
+		index = fid_start>>25;
+	}
+
 	if (index>12) return divisor;
 
 	if (i>3) return divisor;

Modified: trunk/coreboot-v2/src/northbridge/amd/amdk8/raminit_f_dqs.c
===================================================================
--- trunk/coreboot-v2/src/northbridge/amd/amdk8/raminit_f_dqs.c	2009-01-15 02:13:18 UTC (rev 3862)
+++ trunk/coreboot-v2/src/northbridge/amd/amdk8/raminit_f_dqs.c	2009-01-15 02:21:27 UTC (rev 3863)
@@ -432,15 +432,28 @@
 	 /*15*/   5000, 4000, 3000, 2500,
 	};
 
-	unsigned fid_cur;
 	int index;
-
 	msr_t msr;
-	msr = rdmsr(0xc0010042);
-	fid_cur = msr.lo & 0x3f;
 
-	index = fid_cur>>1;
+	/* Check for FID control support */
+	struct cpuid_result cpuid1;
+	cpuid1 = cpuid(0x8000007);
+	if( cpuid1.edx & 0x02 ) {
+		/* Use current FID */
+		unsigned fid_cur;
+		msr = rdmsr(0xc0010042);
+		fid_cur = msr.lo & 0x3f;
 
+		index = fid_cur>>1;
+	} else {
+		/* Use startup FID */
+		unsigned fid_start;
+		msr = rdmsr(0xc0010015);
+		fid_start = (msr.lo & (0x3f << 24));
+		
+		index = fid_start>>25;
+	}
+
 	if(index>12) return T1000_a[i];
 
 	return TT_a[index * 4+i];




From peter at stuge.se  Thu Jan 15 03:22:06 2009
From: peter at stuge.se (Peter Stuge)
Date: Thu, 15 Jan 2009 03:22:06 +0100
Subject: [coreboot] [PATCH] fixes ram init when processor doesn't	have
	FID control
In-Reply-To: <429720.60302.qm@web57003.mail.re3.yahoo.com>
References: <429720.60302.qm@web57003.mail.re3.yahoo.com>
Message-ID: <20090115022206.21916.qmail@stuge.se>

Dan Lykowski wrote:
> This patch fixes ram init problems when using the 9W Sempron part.
> 
> Trying to read the FIDVID register when the processor does not
> support FIDVID control causes a GP Fault. This patch reads the
> startup FID from a different MSR. I have verified this patch to
> work on the dbm690t platform.
> 
> Signed-off-by: Dan Lykowski <lykowdk at gmail.com>

r3863



From engineerguy3737 at yahoo.com  Thu Jan 15 03:24:01 2009
From: engineerguy3737 at yahoo.com (Dan Lykowski)
Date: Wed, 14 Jan 2009 18:24:01 -0800 (PST)
Subject: [coreboot] [PATCH] Adds a retry/faildown to SB600 SATA detection
	logic
Message-ID: <709266.30271.qm@web57008.mail.re3.yahoo.com>

Adds a retry/faildown to SB600 SATA detection logic.

SATA port status kept returning 0x1: BAR5+po+28h
1h = Device presence detected but Phy communication not established
?
This patch adds logic to force 1.5g if the drive fails to communicate at 3.0g.

Thanks
Dan Lykowski

Signed-off-by: Dan Lykowski <lykowdk at gmail.com>



      
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20090114/e6d63732/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: sb600_sata_slow.patch
Type: text/x-patch
Size: 1263 bytes
Desc: not available
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20090114/e6d63732/attachment.patch>

From bari at onelabs.com  Thu Jan 15 03:25:32 2009
From: bari at onelabs.com (bari)
Date: Wed, 14 Jan 2009 20:25:32 -0600
Subject: [coreboot] SiS 963/964/965/966/968 Flashrom Support
Message-ID: <496E9E9C.8030006@onelabs.com>

Has anyone worked on Flashrom for the SiS 963, 964, 965, 966 or 968 
southbridges?

The ga 2761gxdk with SiS966 worked on a year ago used SPI FLASH through 
an IT8716F superIO.

-Bari



From peter at stuge.se  Thu Jan 15 03:28:43 2009
From: peter at stuge.se (Peter Stuge)
Date: Thu, 15 Jan 2009 03:28:43 +0100
Subject: [coreboot] SiS 963/964/965/966/968 Flashrom Support
In-Reply-To: <496E9E9C.8030006@onelabs.com>
References: <496E9E9C.8030006@onelabs.com>
Message-ID: <20090115022843.23312.qmail@stuge.se>

bari wrote:
> Has anyone worked on Flashrom for the SiS 963, 964, 965, 966 or 968 
> southbridges?
>
> The ga 2761gxdk with SiS966 worked on a year ago used SPI FLASH
> through an IT8716F superIO.

Note that the ITE is the SPI master. The SiS chipset is the LPC
master and not too involved in the actual flash specifics.

What do you need?


//Peter



From libv at skynet.be  Thu Jan 15 03:49:07 2009
From: libv at skynet.be (Luc Verhaegen)
Date: Thu, 15 Jan 2009 03:49:07 +0100
Subject: [coreboot] [PATCH] flashrom patch easier	board_pciid_enables
	parsing
In-Reply-To: <20090115020910.GA10161@skynet.be>
References: <496D0157.9000403@free.fr> <496E87FB.5080605@gmx.net>
	<20090115011412.6243.qmail@stuge.se>
	<20090115020910.GA10161@skynet.be>
Message-ID: <20090115024907.GB10161@skynet.be>

On Thu, Jan 15, 2009 at 03:09:10AM +0100, Luc Verhaegen wrote:
> On Thu, Jan 15, 2009 at 02:14:12AM +0100, Peter Stuge wrote:
> > Carl-Daniel Hailfinger wrote:
> > > r3861
> > 
> > ..just horrible..
> 
> Acked-By Luc Verhaegen <libv at skynet.be>

Heck, i tried getting some sleep after seeing this but failed.

This change goes in against every instinct i have.

diffstat tells me this:
 board_enable.c |  413 +++++++++++++++++++++++++++++++++++++++++++++++++--------
 1 file changed, 362 insertions(+), 51 deletions(-)

Daniel, you just bloated an almost overseeable table 7fold. If you claim 
that you still have any oversight and any control, then you're lying.

Luc Verhaegen.
Who just happens to be the original creator of this table.



From svn at coreboot.org  Thu Jan 15 03:35:30 2009
From: svn at coreboot.org (svn at coreboot.org)
Date: Thu, 15 Jan 2009 03:35:30 +0100
Subject: [coreboot] r3864 - trunk/coreboot-v2/src/southbridge/amd/sb600
Message-ID: <mailman.2671.1355071469.16123.coreboot@coreboot.org>

Author: stuge
Date: 2009-01-15 03:35:30 +0100 (Thu, 15 Jan 2009)
New Revision: 3864

Modified:
   trunk/coreboot-v2/src/southbridge/amd/sb600/sb600_sata.c
Log:
Adds a retry/faildown to SB600 SATA detection logic.

SATA port status kept returning 0x1: BAR5+po+28h
1h = Device presence detected but Phy communication not established

This patch adds logic to force 1.5g if the drive fails to communicate at 3.0g.

Signed-off-by: Dan Lykowski <lykowdk at gmail.com>
Acked-by: Peter Stuge <peter at stuge.se>


Modified: trunk/coreboot-v2/src/southbridge/amd/sb600/sb600_sata.c
===================================================================
--- trunk/coreboot-v2/src/southbridge/amd/sb600/sb600_sata.c	2009-01-15 02:21:27 UTC (rev 3863)
+++ trunk/coreboot-v2/src/southbridge/amd/sb600/sb600_sata.c	2009-01-15 02:35:30 UTC (rev 3864)
@@ -175,6 +175,35 @@
 		byte = readb(sata_bar5 + 0x128 + 0x80 * i);
 		printk_spew("SATA port %i status = %x\n", i, byte);
 		byte &= 0xF;
+
+		if( byte == 0x1 ) {
+			/* If the drive status is 0x1 then we see it but we aren't talking to it. */
+			/* Try to do something about it. */
+			printk_spew("SATA device detected but not talking. Trying lower speed.\n");
+
+			/* Read in Port-N Serial ATA Control Register */
+			byte = readb(sata_bar5 + 0x12C + 0x80 * i);
+
+			/* Set Reset Bit and 1.5g bit */
+			byte |= 0x11; 
+			writeb(byte, (sata_bar5 + 0x12C + 0x80 * i));
+			
+			/* Wait 1ms */			
+			mdelay(1); 
+
+			/* Clear Reset Bit */
+			byte &= ~0x01; 
+			writeb(byte, (sata_bar5 + 0x12C + 0x80 * i));
+
+			/* Wait 1ms */
+			mdelay(1);
+
+			/* Reread status */
+			byte = readb(sata_bar5 + 0x128 + 0x80 * i);
+			printk_spew("SATA port %i status = %x\n", i, byte);
+			byte &= 0xF;
+		}
+
 		if (byte == 0x3) {
 			for (j = 0; j < 10; j++) {
 				if (!sata_drive_detect(i, ((i / 2) == 0) ? sata_bar0 : sata_bar2))




From peter at stuge.se  Thu Jan 15 03:35:39 2009
From: peter at stuge.se (Peter Stuge)
Date: Thu, 15 Jan 2009 03:35:39 +0100
Subject: [coreboot] [PATCH] Adds a retry/faildown to SB600
	SATA	detection logic
In-Reply-To: <709266.30271.qm@web57008.mail.re3.yahoo.com>
References: <709266.30271.qm@web57008.mail.re3.yahoo.com>
Message-ID: <20090115023539.25350.qmail@stuge.se>

Dan Lykowski wrote:
> Adds a retry/faildown to SB600 SATA detection logic.
> 
> SATA port status kept returning 0x1: BAR5+po+28h
> 1h = Device presence detected but Phy communication not established
> ?
> This patch adds logic to force 1.5g if the drive fails to communicate at 3.0g.
> 
> Signed-off-by: Dan Lykowski <lykowdk at gmail.com>

r3864



From peter at stuge.se  Thu Jan 15 03:44:38 2009
From: peter at stuge.se (Peter Stuge)
Date: Thu, 15 Jan 2009 03:44:38 +0100
Subject: [coreboot] [PATCH] flashrom patch easier	board_pciid_enables
	parsing
In-Reply-To: <20090115024907.GB10161@skynet.be>
References: <496D0157.9000403@free.fr> <496E87FB.5080605@gmx.net>
	<20090115011412.6243.qmail@stuge.se>
	<20090115020910.GA10161@skynet.be>
	<20090115024907.GB10161@skynet.be>
Message-ID: <20090115024438.27170.qmail@stuge.se>

Luc Verhaegen wrote:
> Heck, i tried getting some sleep after seeing this but failed.

Hah, I don't blame you.


> This change goes in against every instinct i have.

Yeah, I also feel that it is completely wrong.


> Daniel, you just bloated an almost overseeable table 7fold.

I'd like to hear back from Stefan and/or Ron. If they have no
comments or strong opinions in a few days or so I'd like to ask you
to please revert this commit Carl-Daniel. If the formalia is
important feel free to consider it naked by me by then.


//Peter



From c-d.hailfinger.devel.2006 at gmx.net  Thu Jan 15 03:44:41 2009
From: c-d.hailfinger.devel.2006 at gmx.net (Carl-Daniel Hailfinger)
Date: Thu, 15 Jan 2009 03:44:41 +0100
Subject: [coreboot] [PATCH] flashrom patch easier	board_pciid_enables
 parsing
In-Reply-To: <20090115024907.GB10161@skynet.be>
References: <496D0157.9000403@free.fr>
	<496E87FB.5080605@gmx.net>	<20090115011412.6243.qmail@stuge.se>	<20090115020910.GA10161@skynet.be>
	<20090115024907.GB10161@skynet.be>
Message-ID: <496EA319.7050602@gmx.net>

On 15.01.2009 03:49, Luc Verhaegen wrote:
> On Thu, Jan 15, 2009 at 03:09:10AM +0100, Luc Verhaegen wrote:
>   
>> On Thu, Jan 15, 2009 at 02:14:12AM +0100, Peter Stuge wrote:
>>     
>>> Carl-Daniel Hailfinger wrote:
>>>       
>>>> r3861
>>>>         
>>> ..just horrible..
>>>       
>> Acked-By Luc Verhaegen <libv at skynet.be>
>>     
>
> Heck, i tried getting some sleep after seeing this but failed.
>
> This change goes in against every instinct i have.
>
> diffstat tells me this:
>  board_enable.c |  413 +++++++++++++++++++++++++++++++++++++++++++++++++--------
>  1 file changed, 362 insertions(+), 51 deletions(-)
>
> Daniel, you just bloated an almost overseeable table 7fold. If you claim 
> that you still have any oversight and any control, then you're lying.
>   

Rest assured, I'll sleep well tonight.

> Luc Verhaegen.
> Who just happens to be the original creator of this table.
>   

The new table has a format which elicits a WTF for several entries. The
reason for the WTF (content, not style) was there already, but the old
style didn't make it that obvious. Making things obvious is good. Making
strange code painful to look at is good.

Regards,
Carl-Daniel
Who thinks lots of lines with =0 or =NULL can be removed now which was
impossible with the old style.

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




From peter at stuge.se  Thu Jan 15 03:55:38 2009
From: peter at stuge.se (Peter Stuge)
Date: Thu, 15 Jan 2009 03:55:38 +0100
Subject: [coreboot] [PATCH] flashrom patch easier	board_pciid_enables
	parsing
In-Reply-To: <496EA319.7050602@gmx.net>
References: <496D0157.9000403@free.fr> <496E87FB.5080605@gmx.net>
	<20090115011412.6243.qmail@stuge.se>
	<20090115020910.GA10161@skynet.be>
	<20090115024907.GB10161@skynet.be> <496EA319.7050602@gmx.net>
Message-ID: <20090115025538.29732.qmail@stuge.se>

Carl-Daniel Hailfinger wrote:
> Making strange code painful to look at is good.

..to ensure that noone will ever want to look at it again, so that
bugs won't be found? Makes no sense.

I consider the opposite to be true, in particular code with strange
logic should be easy on the eyes so that anyone who has even slight
interest could actually review it and maybe even spot a bug.

If the code is painful $person will just laugh and go away, leaving
bugs lingering..


//Peter



From libv at skynet.be  Thu Jan 15 04:24:26 2009
From: libv at skynet.be (Luc Verhaegen)
Date: Thu, 15 Jan 2009 04:24:26 +0100
Subject: [coreboot] [PATCH] flashrom patch easier	board_pciid_enables
	parsing
In-Reply-To: <496EA319.7050602@gmx.net>
References: <496D0157.9000403@free.fr> <496E87FB.5080605@gmx.net>
	<20090115011412.6243.qmail@stuge.se>
	<20090115020910.GA10161@skynet.be>
	<20090115024907.GB10161@skynet.be> <496EA319.7050602@gmx.net>
Message-ID: <20090115032426.GA10631@skynet.be>

On Thu, Jan 15, 2009 at 03:44:41AM +0100, Carl-Daniel Hailfinger wrote:
> On 15.01.2009 03:49, Luc Verhaegen wrote:
> >   
> > Daniel, you just bloated an almost overseeable table 7fold. If you claim 
> > that you still have any oversight and any control, then you're lying.
> >   
> 
> Rest assured, I'll sleep well tonight.
> 
> > Luc Verhaegen.
> > Who just happens to be the original creator of this table.
> >   
> 
> The new table has a format which elicits a WTF for several entries. The
> reason for the WTF (content, not style) was there already, but the old
> style didn't make it that obvious. Making things obvious is good. Making
> strange code painful to look at is good.

Hey, if you don't understand the code, don't touch it.

And here i was thinking there was a clear comment in front of the table 
structure definition that explained how the different entries are used 
and why some entries can be nulled.

Luc Verhaegen.



From c-d.hailfinger.devel.2006 at gmx.net  Thu Jan 15 04:16:38 2009
From: c-d.hailfinger.devel.2006 at gmx.net (Carl-Daniel Hailfinger)
Date: Thu, 15 Jan 2009 04:16:38 +0100
Subject: [coreboot] [PATCH] flashrom patch easier	board_pciid_enables
 parsing
In-Reply-To: <20090115025538.29732.qmail@stuge.se>
References: <496D0157.9000403@free.fr>
	<496E87FB.5080605@gmx.net>	<20090115011412.6243.qmail@stuge.se>	<20090115020910.GA10161@skynet.be>	<20090115024907.GB10161@skynet.be>
	<496EA319.7050602@gmx.net> <20090115025538.29732.qmail@stuge.se>
Message-ID: <496EAA96.503@gmx.net>

On 15.01.2009 03:55, Peter Stuge wrote:
> Carl-Daniel Hailfinger wrote:
>   
>> Making strange code painful to look at is good.
>>     
>
> ..to ensure that noone will ever want to look at it again, so that
> bugs won't be found? Makes no sense.
>
> I consider the opposite to be true, in particular code with strange
> logic should be easy on the eyes so that anyone who has even slight
> interest could actually review it and maybe even spot a bug.
>   

It is definitely easier on the eyes if you only have to look at two
places at the same time (array and board enable function) now instead of
three places (flash.h and array and board enable function) before.

The pain I was referring to is in the loads of NULL/0 stuff. It can be
eliminated with liberal application of grep. The real question is why
there are so many NULL/0 entries in the first place.


> If the code is painful $person will just laugh and go away, leaving
> bugs lingering..
>   

Actually, there are bugs lingering in related code, but nobody bothered
to fix it. Well, that's not entirely true. I bothered to send a patch,
but iirc it was never acked. I can resend...

Anyway, this change makes it easy to add a new board without having to
open two editor windows at the same time to find out the correct struct
ordering. And that makes it easier for new contributors who just want to
fix flashrom for their board.

The two-line layout was really painful. It was multiline (which you seem
to dislike extremely) and it required anybody changing it to have
flash.h open at the same time (which I think is more complicated than it
should be).
I consider anything to be an improvement over the old layout.

Regards,
Carl-Daniel

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




From peter at stuge.se  Thu Jan 15 04:19:10 2009
From: peter at stuge.se (Peter Stuge)
Date: Thu, 15 Jan 2009 04:19:10 +0100
Subject: [coreboot] Fwd: [RFC] Here we go... the SLOF biosemu
	for	coreboot-v3
In-Reply-To: <b5765cdf0901070049s2329579cqc0c0bafcd54bfe74@mail.gmail.com>
References: <b5765cdf0812131243g19e87f7fl4944f905945da164@mail.gmail.com>
	<2831fecf0812131318v6342777cs4f78f54115c91640@mail.gmail.com>
	<b5765cdf0812131339l32b6f180gd138fe4b26a03d6f@mail.gmail.com>
	<20081215014832.15094.qmail@stuge.se>
	<8EA485427B6E4C578D25D1D9DF8780E9@chimp>
	<b5765cdf0812150930pd897bf4p1b5a771785ab293f@mail.gmail.com>
	<20081215182855.16628.qmail@stuge.se>
	<b5765cdf0812160514h474d03d6o4fa5f41b0b8595d5@mail.gmail.com>
	<20090106235157.10599.qmail@stuge.se>
	<b5765cdf0901070049s2329579cqc0c0bafcd54bfe74@mail.gmail.com>
Message-ID: <20090115031910.2248.qmail@stuge.se>

Pattrick Hueper wrote:
> >> +     my_wrl(0x10 * 4, 0xf000f065);
> >> +     my_wrb(0x000ff065, 0xcf);
> >
> > Has this gotten some feedback? The fix is correct!
> 
> This code is currently in svn, isnt it?

Yes - I was looking at an older patch. Thanks!


//Peter



From c-d.hailfinger.devel.2006 at gmx.net  Thu Jan 15 04:19:42 2009
From: c-d.hailfinger.devel.2006 at gmx.net (Carl-Daniel Hailfinger)
Date: Thu, 15 Jan 2009 04:19:42 +0100
Subject: [coreboot] [PATCH] flashrom patch easier	board_pciid_enables
 parsing
In-Reply-To: <20090115024438.27170.qmail@stuge.se>
References: <496D0157.9000403@free.fr>
	<496E87FB.5080605@gmx.net>	<20090115011412.6243.qmail@stuge.se>	<20090115020910.GA10161@skynet.be>	<20090115024907.GB10161@skynet.be>
	<20090115024438.27170.qmail@stuge.se>
Message-ID: <496EAB4E.4010009@gmx.net>

On 15.01.2009 03:44, Peter Stuge wrote:
> Luc Verhaegen wrote:
>   
>> Daniel, you just bloated an almost overseeable table 7fold.
>>     
>
> I'd like to hear back from Stefan and/or Ron. If they have no
> comments or strong opinions in a few days or so I'd like to ask you
> to please revert this commit Carl-Daniel. If the formalia is
> important feel free to consider it naked by me by then.
>   

Ron gave his Ack and a reason why he prefers the new format. I'll gladly
forward the mail to you if you missed it.

Regards,
Carl-Daniel

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




From libv at skynet.be  Thu Jan 15 04:42:13 2009
From: libv at skynet.be (Luc Verhaegen)
Date: Thu, 15 Jan 2009 04:42:13 +0100
Subject: [coreboot] [PATCH] flashrom patch easier	board_pciid_enables
	parsing
In-Reply-To: <496EAA96.503@gmx.net>
References: <496D0157.9000403@free.fr> <496E87FB.5080605@gmx.net>
	<20090115011412.6243.qmail@stuge.se>
	<20090115020910.GA10161@skynet.be>
	<20090115024907.GB10161@skynet.be> <496EA319.7050602@gmx.net>
	<20090115025538.29732.qmail@stuge.se> <496EAA96.503@gmx.net>
Message-ID: <20090115034213.GB10631@skynet.be>

On Thu, Jan 15, 2009 at 04:16:38AM +0100, Carl-Daniel Hailfinger wrote:
> On 15.01.2009 03:55, Peter Stuge wrote:
> > Carl-Daniel Hailfinger wrote:
> >   
> >> Making strange code painful to look at is good.
> >>     
> >
> > ..to ensure that noone will ever want to look at it again, so that
> > bugs won't be found? Makes no sense.
> >
> > I consider the opposite to be true, in particular code with strange
> > logic should be easy on the eyes so that anyone who has even slight
> > interest could actually review it and maybe even spot a bug.
> >   
> 
> It is definitely easier on the eyes if you only have to look at two
> places at the same time (array and board enable function) now instead of
> three places (flash.h and array and board enable function) before.
> 
> The pain I was referring to is in the loads of NULL/0 stuff. It can be
> eliminated with liberal application of grep. The real question is why
> there are so many NULL/0 entries in the first place.
> 
> 
> > If the code is painful $person will just laugh and go away, leaving
> > bugs lingering..
> >   
> 
> Actually, there are bugs lingering in related code, but nobody bothered
> to fix it. Well, that's not entirely true. I bothered to send a patch,
> but iirc it was never acked. I can resend...
> 
> Anyway, this change makes it easy to add a new board without having to
> open two editor windows at the same time to find out the correct struct
> ordering. And that makes it easier for new contributors who just want to
> fix flashrom for their board.
> 
> The two-line layout was really painful. It was multiline (which you seem
> to dislike extremely) and it required anybody changing it to have
> flash.h open at the same time (which I think is more complicated than it
> should be).
> I consider anything to be an improvement over the old layout.
> 
> Regards,
> Carl-Daniel

flash.h? This table is fully file internal. The struct definition is 
right before the table!

My original code was single long line per entry.

Luc Verhaegen.



From c-d.hailfinger.devel.2006 at gmx.net  Thu Jan 15 04:36:54 2009
From: c-d.hailfinger.devel.2006 at gmx.net (Carl-Daniel Hailfinger)
Date: Thu, 15 Jan 2009 04:36:54 +0100
Subject: [coreboot] [PATCH] flashrom patch easier	board_pciid_enables
 parsing
In-Reply-To: <20090115032426.GA10631@skynet.be>
References: <496D0157.9000403@free.fr> <496E87FB.5080605@gmx.net>
	<20090115011412.6243.qmail@stuge.se>
	<20090115020910.GA10161@skynet.be>
	<20090115024907.GB10161@skynet.be> <496EA319.7050602@gmx.net>
	<20090115032426.GA10631@skynet.be>
Message-ID: <496EAF56.8020006@gmx.net>

On 15.01.2009 04:24, Luc Verhaegen wrote:
> On Thu, Jan 15, 2009 at 03:44:41AM +0100, Carl-Daniel Hailfinger wrote:
>   
>> On 15.01.2009 03:49, Luc Verhaegen wrote:
>>     
>>>   
>>> Daniel, you just bloated an almost overseeable table 7fold. If you claim 
>>> that you still have any oversight and any control, then you're lying.
>>>   
>>>       
>> Rest assured, I'll sleep well tonight.
>>
>>     
>>> Luc Verhaegen.
>>> Who just happens to be the original creator of this table.
>>>   
>>>       
>> The new table has a format which elicits a WTF for several entries. The
>> reason for the WTF (content, not style) was there already, but the old
>> style didn't make it that obvious. Making things obvious is good. Making
>> strange code painful to look at is good.
>>     
>
> Hey, if you don't understand the code, don't touch it.
>   

No problem. I assume you're willing to create all board enable functions
and table entries for the foreseeable future for everyone who asks once
we switch back to the old layout. That includes debugging and sending
new patches to volunteer testers.
By the way, I understand the code.


> And here i was thinking there was a clear comment in front of the table 
> structure definition that explained how the different entries are used 
> and why some entries can be nulled.
>   

Calling subsystem IDs card IDs is not my definition of clear.

Regards,
Carl-Daniel

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




From c-d.hailfinger.devel.2006 at gmx.net  Thu Jan 15 04:45:04 2009
From: c-d.hailfinger.devel.2006 at gmx.net (Carl-Daniel Hailfinger)
Date: Thu, 15 Jan 2009 04:45:04 +0100
Subject: [coreboot] [PATCH] flashrom patch easier	board_pciid_enables
 parsing
In-Reply-To: <20090115034213.GB10631@skynet.be>
References: <496D0157.9000403@free.fr>
	<496E87FB.5080605@gmx.net>	<20090115011412.6243.qmail@stuge.se>	<20090115020910.GA10161@skynet.be>	<20090115024907.GB10161@skynet.be>
	<496EA319.7050602@gmx.net>	<20090115025538.29732.qmail@stuge.se>
	<496EAA96.503@gmx.net> <20090115034213.GB10631@skynet.be>
Message-ID: <496EB140.9040801@gmx.net>

On 15.01.2009 04:42, Luc Verhaegen wrote:
> My original code was single long line per entry.
>   

The two-line layout change was committed in r2581 and
Signed-off-by: Luc Verhaegen <libv at skynet.be>

So unless you want to accuse Stefan of botching the commit of your
patch, there is a small problem.

Regards,
Carl-Daniel



From libv at skynet.be  Thu Jan 15 05:00:48 2009
From: libv at skynet.be (Luc Verhaegen)
Date: Thu, 15 Jan 2009 05:00:48 +0100
Subject: [coreboot] [PATCH] flashrom patch easier	board_pciid_enables
	parsing
In-Reply-To: <496EAF56.8020006@gmx.net>
References: <496D0157.9000403@free.fr> <496E87FB.5080605@gmx.net>
	<20090115011412.6243.qmail@stuge.se>
	<20090115020910.GA10161@skynet.be>
	<20090115024907.GB10161@skynet.be> <496EA319.7050602@gmx.net>
	<20090115032426.GA10631@skynet.be> <496EAF56.8020006@gmx.net>
Message-ID: <20090115040048.GC10631@skynet.be>

On Thu, Jan 15, 2009 at 04:36:54AM +0100, Carl-Daniel Hailfinger wrote:
> On 15.01.2009 04:24, Luc Verhaegen wrote:
> >
> > Hey, if you don't understand the code, don't touch it.
> >   
> 
> No problem. I assume you're willing to create all board enable functions
> and table entries for the foreseeable future for everyone who asks once
> we switch back to the old layout. That includes debugging and sending
> new patches to volunteer testers.

Sure, i'll do that next to keeping X from degrading even further.

> Calling subsystem IDs card IDs is not my definition of clear.

As you well know, people use the names interchangedly, all the time.

Luc Verhaegen.



From libv at skynet.be  Thu Jan 15 05:06:35 2009
From: libv at skynet.be (Luc Verhaegen)
Date: Thu, 15 Jan 2009 05:06:35 +0100
Subject: [coreboot] [PATCH] flashrom patch easier	board_pciid_enables
	parsing
In-Reply-To: <496EB140.9040801@gmx.net>
References: <496D0157.9000403@free.fr> <496E87FB.5080605@gmx.net>
	<20090115011412.6243.qmail@stuge.se>
	<20090115020910.GA10161@skynet.be>
	<20090115024907.GB10161@skynet.be> <496EA319.7050602@gmx.net>
	<20090115025538.29732.qmail@stuge.se> <496EAA96.503@gmx.net>
	<20090115034213.GB10631@skynet.be> <496EB140.9040801@gmx.net>
Message-ID: <20090115040635.GD10631@skynet.be>

On Thu, Jan 15, 2009 at 04:45:04AM +0100, Carl-Daniel Hailfinger wrote:
> On 15.01.2009 04:42, Luc Verhaegen wrote:
> > My original code was single long line per entry.
> >   
> 
> The two-line layout change was committed in r2581 and
> Signed-off-by: Luc Verhaegen <libv at skynet.be>
> 
> So unless you want to accuse Stefan of botching the commit of your
> patch, there is a small problem.
> 
> Regards,
> Carl-Daniel

Last patch sent on this that i can find:
http://www.coreboot.org/pipermail/coreboot/2007-March/019425.html

Stefans commit message:
http://www.coreboot.org/pipermail/coreboot/2007-April/019690.html

Luc Verhaegen.



From libv at skynet.be  Thu Jan 15 05:16:36 2009
From: libv at skynet.be (Luc Verhaegen)
Date: Thu, 15 Jan 2009 05:16:36 +0100
Subject: [coreboot] [patch] flashrom: improve board enable table readability.
Message-ID: <20090115041636.GE10631@skynet.be>

Luc Verhaegen.
-------------- next part --------------
Make the board enables table readable again.

This patch reverts the change made in 3862.

It also moves the split lines to single lines, and properly pads
all entries. With a table like this, there is always some pain,
long lines is probably the least painful of all possible
solutions.

All 0x0000 pci id values are now string-replaced to 0 for improved
readability. End marker now also has the proper amount of entries.
Comment was added to the top of the table as a quick aid for
identifying entries.

Signed-off-by Luc Verhaegen <libv at skynet.be>

Index: board_enable.c
===================================================================
--- board_enable.c	(revision 3862)
+++ board_enable.c	(working copy)
@@ -626,369 +626,35 @@
 };
 
 struct board_pciid_enable board_pciid_enables[] = {
-	{
-		.first_vendor		= 0x1106,
-		.first_device		= 0x0571,
-		.first_card_vendor	= 0x1462,
-		.first_card_device	= 0x7120,
-		.second_vendor		= 0x0000,
-		.second_device		= 0x0000,
-		.second_card_vendor	= 0x0000,
-		.second_card_device	= 0x0000,
-		.lb_vendor		= "msi",
-		.lb_part		= "kt4v",
-		.name			= "MSI KT4V",
-		.enable			= board_msi_kt4v,
-	},
-	{
-		.first_vendor		= 0x8086,
-		.first_device		= 0x1a30,
-		.first_card_vendor	= 0x1043,
-		.first_card_device	= 0x8070,
-		.second_vendor		= 0x8086,
-		.second_device		= 0x244b,
-		.second_card_vendor	= 0x1043,
-		.second_card_device	= 0x8028,
-		.lb_vendor		= NULL,
-		.lb_part		= NULL,
-		.name			= "ASUS P4B266",
-		.enable			= ich2_gpio22_raise,
-	},
-	{
-		.first_vendor		= 0x10de,
-		.first_device		= 0x0360,
-		.first_card_vendor	= 0x0000,
-		.first_card_device	= 0x0000,
-		.second_vendor		= 0x0000,
-		.second_device		= 0x0000,
-		.second_card_vendor	= 0x0000,
-		.second_card_device	= 0x0000,
-		.lb_vendor		= "gigabyte",
-		.lb_part		= "m57sli",
-		.name			= "GIGABYTE GA-M57SLI-S4",
-		.enable			= it87xx_probe_spi_flash,
-	},
-	{
-		.first_vendor		= 0x10de,
-		.first_device		= 0x03e0,
-		.first_card_vendor	= 0x0000,
-		.first_card_device	= 0x0000,
-		.second_vendor		= 0x0000,
-		.second_device		= 0x0000,
-		.second_card_vendor	= 0x0000,
-		.second_card_device	= 0x0000,
-		.lb_vendor		= "gigabyte",
-		.lb_part		= "m61p",
-		.name			= "GIGABYTE GA-M61P-S3",
-		.enable			= it87xx_probe_spi_flash,
-	},
-	{
-		.first_vendor		= 0x1002,
-		.first_device		= 0x4398,
-		.first_card_vendor	= 0x1458,
-		.first_card_device	= 0x5004,
-		.second_vendor		= 0x1002,
-		.second_device		= 0x4385,
-		.second_card_vendor	= 0x1458,
-		.second_card_device	= 0x4385,
-		.lb_vendor		= NULL,
-		.lb_part		= NULL,
-		.name			= "GIGABYTE GA-MA78G-DS3H",
-		.enable			= it87xx_probe_spi_flash,
-	},
-	{
-		.first_vendor		= 0x1039,
-		.first_device		= 0x0761,
-		.first_card_vendor	= 0x0000,
-		.first_card_device	= 0x0000,
-		.second_vendor		= 0x0000,
-		.second_device		= 0x0000,
-		.second_card_vendor	= 0x0000,
-		.second_card_device	= 0x0000,
-		.lb_vendor		= "gigabyte",
-		.lb_part		= "2761gxdk",
-		.name			= "GIGABYTE GA-2761GXDK",
-		.enable			= it87xx_probe_spi_flash,
-	},
-	{
-		.first_vendor		= 0x1022,
-		.first_device		= 0x7468,
-		.first_card_vendor	= 0x0000,
-		.first_card_device	= 0x0000,
-		.second_vendor		= 0x0000,
-		.second_device		= 0x0000,
-		.second_card_vendor	= 0x0000,
-		.second_card_device	= 0x0000,
-		.lb_vendor		= "iwill",
-		.lb_part		= "dk8_htx",
-		.name			= "IWILL DK8-HTX",
-		.enable			= w83627hf_gpio24_raise_2e,
-	},
-	{
-		.first_vendor		= 0x10de,
-		.first_device		= 0x005e,
-		.first_card_vendor	= 0x0000,
-		.first_card_device	= 0x0000,
-		.second_vendor		= 0x0000,
-		.second_device		= 0x0000,
-		.second_card_vendor	= 0x0000,
-		.second_card_device	= 0x0000,
-		.lb_vendor		= "msi",
-		.lb_part		= "k8n-neo3",
-		.name			= "MSI K8N Neo3",
-		.enable			= w83627thf_gpio4_4_raise_4e,
-	},
-	{
-		.first_vendor		= 0x1022,
-		.first_device		= 0x746B,
-		.first_card_vendor	= 0x1022,
-		.first_card_device	= 0x36C0,
-		.second_vendor		= 0x0000,
-		.second_device		= 0x0000,
-		.second_card_vendor	= 0x0000,
-		.second_card_device	= 0x0000,
-		.lb_vendor		= "AGAMI",
-		.lb_part		= "ARUMA",
-		.name			= "agami Aruma",
-		.enable			= w83627hf_gpio24_raise_2e,
-	},
-	{
-		.first_vendor		= 0x1106,
-		.first_device		= 0x3177,
-		.first_card_vendor	= 0x1106,
-		.first_card_device	= 0xAA01,
-		.second_vendor		= 0x1106,
-		.second_device		= 0x3123,
-		.second_card_vendor	= 0x1106,
-		.second_card_device	= 0xAA01,
-		.lb_vendor		= NULL,
-		.lb_part		= NULL,
-		.name			= "VIA EPIA M/MII/...",
-		.enable			= board_via_epia_m,
-	},
-	{
-		.first_vendor		= 0x1106,
-		.first_device		= 0x3177,
-		.first_card_vendor	= 0x1043,
-		.first_card_device	= 0x80A1,
-		.second_vendor		= 0x1106,
-		.second_device		= 0x3205,
-		.second_card_vendor	= 0x1043,
-		.second_card_device	= 0x8118,
-		.lb_vendor		= NULL,
-		.lb_part		= NULL,
-		.name			= "ASUS A7V8-MX SE",
-		.enable			= board_asus_a7v8x_mx,
-	},
-	{
-		.first_vendor		= 0x1106,
-		.first_device		= 0x3227,
-		.first_card_vendor	= 0x1106,
-		.first_card_device	= 0xAA01,
-		.second_vendor		= 0x1106,
-		.second_device		= 0x0259,
-		.second_card_vendor	= 0x1106,
-		.second_card_device	= 0xAA01,
-		.lb_vendor		= NULL,
-		.lb_part		= NULL,
-		.name			= "VIA EPIA SP",
-		.enable			= board_via_epia_sp,
-	},
-	{
-		.first_vendor		= 0x1106,
-		.first_device		= 0x0314,
-		.first_card_vendor	= 0x1106,
-		.first_card_device	= 0xaa08,
-		.second_vendor		= 0x1106,
-		.second_device		= 0x3227,
-		.second_card_vendor	= 0x1106,
-		.second_card_device	= 0xAA08,
-		.lb_vendor		= NULL,
-		.lb_part		= NULL,
-		.name			= "VIA EPIA-CN",
-		.enable			= board_via_epia_sp,
-	},
-	{
-		.first_vendor		= 0x8086,
-		.first_device		= 0x1076,
-		.first_card_vendor	= 0x8086,
-		.first_card_device	= 0x1176,
-		.second_vendor		= 0x1106,
-		.second_device		= 0x3059,
-		.second_card_vendor	= 0x10f1,
-		.second_card_device	= 0x2498,
-		.lb_vendor		= NULL,
-		.lb_part		= NULL,
-		.name			= "Tyan Tomcat K7M",
-		.enable			= board_asus_a7v8x_mx,
-	},
-	{
-		.first_vendor		= 0x10B9,
-		.first_device		= 0x1541,
-		.first_card_vendor	= 0x0000,
-		.first_card_device	= 0x0000,
-		.second_vendor		= 0x10B9,
-		.second_device		= 0x1533,
-		.second_card_vendor	= 0x0000,
-		.second_card_device	= 0x0000,
-		.lb_vendor		= "asus",
-		.lb_part		= "p5a",
-		.name			= "ASUS P5A",
-		.enable			= board_asus_p5a,
-	},
-	{
-		.first_vendor		= 0x1166,
-		.first_device		= 0x0205,
-		.first_card_vendor	= 0x1014,
-		.first_card_device	= 0x0347,
-		.second_vendor		= 0x0000,
-		.second_device		= 0x0000,
-		.second_card_vendor	= 0x0000,
-		.second_card_device	= 0x0000,
-		.lb_vendor		= "ibm",
-		.lb_part		= "x3455",
-		.name			= "IBM x3455",
-		.enable			= board_ibm_x3455,
-	},
-	{
-		.first_vendor		= 0x8086,
-		.first_device		= 0x7110,
-		.first_card_vendor	= 0x0000,
-		.first_card_device	= 0x0000,
-		.second_vendor		= 0x8086,
-		.second_device		= 0x7190,
-		.second_card_vendor	= 0x0000,
-		.second_card_device	= 0x0000,
-		.lb_vendor		= "epox",
-		.lb_part		= "ep-bx3",
-		.name			= "EPoX EP-BX3",
-		.enable			= board_epox_ep_bx3,
-	},
-	{
-		.first_vendor		= 0x8086,
-		.first_device		= 0x1130,
-		.first_card_vendor	= 0x0000,
-		.first_card_device	= 0x0000,
-		.second_vendor		= 0x105a,
-		.second_device		= 0x0d30,
-		.second_card_vendor	= 0x105a,
-		.second_card_device	= 0x4d33,
-		.lb_vendor		= "acorp",
-		.lb_part		= "6a815epd",
-		.name			= "Acorp 6A815EPD",
-		.enable			= board_acorp_6a815epd,
-	},
-	{
-		.first_vendor		= 0x1022,
-		.first_device		= 0x2090,
-		.first_card_vendor	= 0x0000,
-		.first_card_device	= 0x0000,
-		.second_vendor		= 0x1022,
-		.second_device		= 0x2080,
-		.second_card_vendor	= 0x0000,
-		.second_card_device	= 0x0000,
-		.lb_vendor		= "artecgroup",
-		.lb_part		= "dbe61",
-		.name			= "Artec Group DBE61",
-		.enable			= board_artecgroup_dbe6x,
-	},
-	{
-		.first_vendor		= 0x1022,
-		.first_device		= 0x2090,
-		.first_card_vendor	= 0x0000,
-		.first_card_device	= 0x0000,
-		.second_vendor		= 0x1022,
-		.second_device		= 0x2080,
-		.second_card_vendor	= 0x0000,
-		.second_card_device	= 0x0000,
-		.lb_vendor		= "artecgroup",
-		.lb_part		= "dbe62",
-		.name			= "Artec Group DBE62",
-		.enable			= board_artecgroup_dbe6x,
-	},
+	/* first pci-id set,             second pci-id set,              coreboot identification,  boardname,                flash enable */
+	{0x1106, 0x0571, 0x1462, 0x7120, 0,      0,      0,      0,      "msi",        "kt4v",     "MSI KT4V",               board_msi_kt4v},
+	{0x8086, 0x1a30, 0x1043, 0x8070, 0x8086, 0x244b, 0x1043, 0x8028, NULL,         NULL,       "ASUS P4B266",            ich2_gpio22_raise},
+	{0x10de, 0x0360, 0,      0,      0,      0,      0,      0,      "gigabyte",   "m57sli",   "GIGABYTE GA-M57SLI-S4",  it87xx_probe_spi_flash},
+	{0x10de, 0x03e0, 0,      0,      0,      0,      0,      0,      "gigabyte",   "m61p",     "GIGABYTE GA-M61P-S3",    it87xx_probe_spi_flash},
+	{0x1002, 0x4398, 0x1458, 0x5004, 0x1002, 0x4385, 0x1458, 0x4385, NULL,         NULL,       "GIGABYTE GA-MA78G-DS3H", it87xx_probe_spi_flash},
+	{0x1039, 0x0761, 0,      0,      0,      0,      0,      0,      "gigabyte",   "2761gxdk", "GIGABYTE GA-2761GXDK",   it87xx_probe_spi_flash},
+	{0x1022, 0x7468, 0,      0,      0,      0,      0,      0,      "iwill",      "dk8_htx",  "IWILL DK8-HTX",          w83627hf_gpio24_raise_2e},
+	{0x10de, 0x005e, 0,      0,      0,      0,      0,      0,      "msi",        "k8n-neo3", "MSI K8N Neo3",           w83627thf_gpio4_4_raise_4e},
+	{0x1022, 0x746B, 0x1022, 0x36C0, 0,      0,      0,      0,      "AGAMI",      "ARUMA",    "agami Aruma",            w83627hf_gpio24_raise_2e},
+	{0x1106, 0x3177, 0x1106, 0xAA01, 0x1106, 0x3123, 0x1106, 0xAA01, NULL,         NULL,       "VIA EPIA M/MII/...",     board_via_epia_m},
+	{0x1106, 0x3177, 0x1043, 0x80A1, 0x1106, 0x3205, 0x1043, 0x8118, NULL,         NULL,       "ASUS A7V8-MX SE",        board_asus_a7v8x_mx},
+	{0x1106, 0x3227, 0x1106, 0xAA01, 0x1106, 0x0259, 0x1106, 0xAA01, NULL,         NULL,       "VIA EPIA SP",            board_via_epia_sp},
+	{0x1106, 0x0314, 0x1106, 0xaa08, 0x1106, 0x3227, 0x1106, 0xAA08, NULL,         NULL,       "VIA EPIA-CN",            board_via_epia_sp},
+	{0x8086, 0x1076, 0x8086, 0x1176, 0x1106, 0x3059, 0x10f1, 0x2498, NULL,         NULL,       "Tyan Tomcat K7M",        board_asus_a7v8x_mx},
+	{0x10B9, 0x1541, 0,      0,      0x10B9, 0x1533, 0,      0,      "asus",       "p5a",      "ASUS P5A",               board_asus_p5a},
+	{0x1166, 0x0205, 0x1014, 0x0347, 0,      0,      0,      0,      "ibm",        "x3455",    "IBM x3455",              board_ibm_x3455},
+	{0x8086, 0x7110, 0,      0,      0x8086, 0x7190, 0,      0,      "epox",       "ep-bx3",   "EPoX EP-BX3",            board_epox_ep_bx3},
+	{0x8086, 0x1130, 0,      0,      0x105a, 0x0d30, 0x105a, 0x4d33, "acorp",      "6a815epd", "Acorp 6A815EPD",         board_acorp_6a815epd},
+	{0x1022, 0x2090, 0,      0,      0x1022, 0x2080, 0,      0,      "artecgroup", "dbe61",    "Artec Group DBE61",      board_artecgroup_dbe6x},
+	{0x1022, 0x2090, 0,      0,      0x1022, 0x2080, 0,      0,      "artecgroup", "dbe62",    "Artec Group DBE62",      board_artecgroup_dbe6x},
 	/* Note: There are >= 2 version of the Kontron 986LCD-M/mITX! */
-	{
-		.first_vendor		= 0x8086,
-		.first_device		= 0x27b8,
-		.first_card_vendor	= 0x0000,
-		.first_card_device	= 0x0000,
-		.second_vendor		= 0x0000,
-		.second_device		= 0x0000,
-		.second_card_vendor	= 0x0000,
-		.second_card_device	= 0x0000,
-		.lb_vendor		= "kontron",
-		.lb_part		= "986lcd-m",
-		.name			= "Kontron 986LCD-M",
-		.enable			= board_kontron_986lcd_m,
-	},
-	{
-		.first_vendor		= 0x10ec,
-		.first_device		= 0x8168,
-		.first_card_vendor	= 0x10ec,
-		.first_card_device	= 0x8168,
-		.second_vendor		= 0x104c,
-		.second_device		= 0x8023,
-		.second_card_vendor	= 0x104c,
-		.second_card_device	= 0x8019,
-		.lb_vendor		= "kontron",
-		.lb_part		= "986lcd-m",
-		.name			= "Kontron 986LCD-M",
-		.enable			= board_kontron_986lcd_m,
-	},
-	{
-		.first_vendor		= 0x1106,
-		.first_device		= 0x3149,
-		.first_card_vendor	= 0x1565,
-		.first_card_device	= 0x3206,
-		.second_vendor		= 0x1106,
-		.second_device		= 0x3344,
-		.second_card_vendor	= 0x1565,
-		.second_card_device	= 0x1202,
-		.lb_vendor		= NULL,
-		.lb_part		= NULL,
-		.name			= "BioStar P4M80-M4",
-		.enable			= board_biostar_p4m80_m4,
-	},
-	{
-		.first_vendor		= 0x1106,
-		.first_device		= 0x3227,
-		.first_card_vendor	= 0x1458,
-		.first_card_device	= 0x5001,
-		.second_vendor		= 0x10ec,
-		.second_device		= 0x8139,
-		.second_card_vendor	= 0x1458,
-		.second_card_device	= 0xe000,
-		.lb_vendor		= NULL,
-		.lb_part		= NULL,
-		.name			= "GIGABYTE GA-7VT600",
-		.enable			= board_biostar_p4m80_m4,
-	},
-	{
-		.first_vendor		= 0x1106,
-		.first_device		= 0x3149,
-		.first_card_vendor	= 0x1462,
-		.first_card_device	= 0x7094,
-		.second_vendor		= 0x10ec,
-		.second_device		= 0x8167,
-		.second_card_vendor	= 0x1462,
-		.second_card_device	= 0x094c,
-		.lb_vendor		= NULL,
-		.lb_part		= NULL,
-		.name			= "MSI K8T Neo2",
-		.enable			= w83627thf_gpio4_4_raise_2e,
-	},
-	{
-		.first_vendor		= 0,
-		.first_device		= 0,
-		.first_card_vendor	= 0,
-		.first_card_device	= 0,
-		.second_vendor		= 0,
-		.second_device		= 0,
-		.second_card_vendor	= 0,
-		.second_card_device	= 0,
-		.lb_vendor		= NULL,
-		.lb_part		= NULL,
-	}	/* Keep this */
+	{0x8086, 0x27b8, 0,      0,      0,      0,      0,      0,      "kontron",    "986lcd-m", "Kontron 986LCD-M",       board_kontron_986lcd_m},
+	{0x10ec, 0x8168, 0x10ec, 0x8168, 0x104c, 0x8023, 0x104c, 0x8019, "kontron",    "986lcd-m", "Kontron 986LCD-M",       board_kontron_986lcd_m},
+	{0x1106, 0x3149, 0x1565, 0x3206, 0x1106, 0x3344, 0x1565, 0x1202, NULL,         NULL,       "BioStar P4M80-M4",       board_biostar_p4m80_m4},
+	{0x1106, 0x3227, 0x1458, 0x5001, 0x10ec, 0x8139, 0x1458, 0xe000, NULL,         NULL,       "GIGABYTE GA-7VT600",     board_biostar_p4m80_m4},
+	{0x1106, 0x3149, 0x1462, 0x7094, 0x10ec, 0x8167, 0x1462, 0x094c, NULL,         NULL,       "MSI K8T Neo2",           w83627thf_gpio4_4_raise_2e},
+	/* Keep this; end marker. */
+	{0,      0,      0,      0,      0,      0,      0,      0,      NULL,         NULL,       NULL,                     NULL}
 };
 
 void print_supported_boards(void)

From peter at stuge.se  Thu Jan 15 05:04:25 2009
From: peter at stuge.se (Peter Stuge)
Date: Thu, 15 Jan 2009 05:04:25 +0100
Subject: [coreboot] [PATCH] flashrom patch easier	board_pciid_enables
	parsing
In-Reply-To: <496EAB4E.4010009@gmx.net>
References: <496D0157.9000403@free.fr> <496E87FB.5080605@gmx.net>
	<20090115011412.6243.qmail@stuge.se>
	<20090115020910.GA10161@skynet.be>
	<20090115024907.GB10161@skynet.be>
	<20090115024438.27170.qmail@stuge.se> <496EAB4E.4010009@gmx.net>
Message-ID: <20090115040425.13123.qmail@stuge.se>

Carl-Daniel Hailfinger wrote:
> > I'd like to hear back from Stefan and/or Ron. If they have no
> > comments or strong opinions in a few days or so I'd like to ask
> > you to please revert this commit Carl-Daniel.
> 
> Ron gave his Ack and a reason why he prefers the new format.

I guess I should have written "no further comments" instead. That
would have been more clear.


//Peter



From peter at stuge.se  Thu Jan 15 05:12:19 2009
From: peter at stuge.se (Peter Stuge)
Date: Thu, 15 Jan 2009 05:12:19 +0100
Subject: [coreboot] [PATCH] flashrom patch easier	board_pciid_enables
	parsing
In-Reply-To: <496EAA96.503@gmx.net>
References: <496D0157.9000403@free.fr> <496E87FB.5080605@gmx.net>
	<20090115011412.6243.qmail@stuge.se>
	<20090115020910.GA10161@skynet.be>
	<20090115024907.GB10161@skynet.be> <496EA319.7050602@gmx.net>
	<20090115025538.29732.qmail@stuge.se> <496EAA96.503@gmx.net>
Message-ID: <20090115041219.14985.qmail@stuge.se>

Carl-Daniel Hailfinger wrote:
> >> Making strange code painful to look at is good.
> >
> > ..to ensure that noone will ever want to look at it again, so that
> > bugs won't be found? Makes no sense.
> >
> > I consider the opposite to be true, in particular code with strange
> > logic should be easy on the eyes so that anyone who has even slight
> > interest could actually review it and maybe even spot a bug.
> 
> The pain I was referring to is in the loads of NULL/0 stuff. It can be
> eliminated with liberal application of grep.

I'm afraid this doesn't help me understand your point about making
code painful. :\


> The real question is why there are so many NULL/0 entries in the
> first place.

Because many boards have non-specific PCI IDs?


> It is definitely easier on the eyes if you only have to look at two
> places at the same time (array and board enable function) now
> instead of three places (flash.h and array and board enable
> function) before.

What did you look up in flash.h? When I've poked at this table I just
banged in some PCI IDs, -m strings if the IDs weren't good enough for
an automatic match, the pretty name and the function that should be
run. The function was often reused from another, similar, board, thus
allowing me to do the change with only a single file open, not that I
consider that a very important metric anyway.


> > If the code is painful $person will just laugh and go away,
> > leaving bugs lingering..
> 
> Actually, there are bugs lingering in related code, but nobody
> bothered to fix it.

Maybe they just aren't serious enough?


> Well, that's not entirely true. I bothered to send a patch, but
> iirc it was never acked. I can resend...

What should I search for? I can probably find the thread. Would've
been real handy to have it in trac though.


..

> And that makes it easier for new contributors who just want to fix
> flashrom for their board.

I dare say they aren't exactly the common case. Of course I would
like it if they were, but for now they aren't. I don't believe this
bikeshed actually plays even a small part in their (lack of)
contributions anyway.


> The two-line layout was really painful. It was multiline (which you
> seem to dislike extremely)

That's why I think the fourteen-line layout with mostly noise is bad.
The 2-line layout has confused me too a few times, but it was nothing
an extra carriage return while editing didn't fix immediately.


..

> I consider anything to be an improvement over the old layout.

You might be able to sell me on a single line layout, but I actually
think the two-line layout is as good as it gets here.


//Peter



From c-d.hailfinger.devel.2006 at gmx.net  Thu Jan 15 05:35:29 2009
From: c-d.hailfinger.devel.2006 at gmx.net (Carl-Daniel Hailfinger)
Date: Thu, 15 Jan 2009 05:35:29 +0100
Subject: [coreboot] AMD DBM690T PowerNow table problems
In-Reply-To: <4967135B.4050608@gmx.net>
References: <49583EA2.8080903@gmx.net>
	<495FE0E5.7020503@assembler.cz>		<534e5dc20901051725l69907601k7d2ccf6817510257@mail.gmail.com>		<DD1CC71B621B004FA76856E5129D6B17024A0045@sbjgexmb1.amd.com>		<534e5dc20901060847j6c19053av20fe3845ca3df3b5@mail.gmail.com>		<4965662A.5060109@gmx.net>	<534e5dc20901080852gbdd37ccu83304fcf206e448a@mail.gmail.com>
	<4967135B.4050608@gmx.net>
Message-ID: <496EBD11.8090301@gmx.net>

On 09.01.2009 10:05, Carl-Daniel Hailfinger wrote:
> On 08.01.2009 17:52, Marc Jones wrote:
>   
>> On Wed, Jan 7, 2009 at 7:34 PM, Carl-Daniel Hailfinger
>> <c-d.hailfinger.devel.2006 at gmx.net> wrote:
>>
>>     
>>> The Linux kernel powernow-k8 driver doesn't complain anymore, but now
>>> the machine will lock up or reboot once I put some load on it.
>>> Blacklisting the powernow-k8 driver avoids the issue, but that makes
>>> frequency scaling impossible.    
>>>       
>> Can you dump the current tables or can you not get that far before a
>> crash? The entries are end points and the driver takes care of the
>> stepping that needs to be done to get to those points. We need to
>> check that the table generated the correct vid setting for the fid. It
>> is well described in the bkdg section 10.6.
>>     
>
> I managed to boot fine with the proprietary BIOS, blacklisted the
> k8-powernow driver and rebooted with coreboot.
>
> If I combine the _PSS from the proprietary BIOS with the other tables
> from coreboot, the machine does not crash. I'll try to narrow it down
> further.
>   

I finally found the bug.

The DBM90T code sets bit 10 in _PSS as part of the control value, but
bit 10 is part of NewVID. That means the resulting VID is wrong and
causes the processor to crash.
The Pistachio code has the same bug.

This patch fixes the wrong setting and changes control from a magic and
incorrect unexplained value (0xE8202C00) to a combination of explained
values and shifts which has the right value (0xE8202800).

It is tested on my machine and it survived 200 changes from minimum to
maximum frequency every 100 ms under heavy load and under no load.

In the long term we want to consolidate all AMD FIDVID code into one
generic library file.

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

--- src/mainboard/amd/pistachio/acpi_tables.c	(Revision 3850)
+++ src/mainboard/amd/pistachio/acpi_tables.c	(Arbeitskopie)
@@ -400,10 +400,10 @@
 		Pstate_num++;
 	}
 
-	/* Print Pstate feq,vid,volt,power */
+	/* Print Pstate freq,vid,volt,power */
 
 	for (index = 0; index < Pstate_num; index++) {
-		printk_info("Pstate_feq[%d] = %dMHz\t", index,
+		printk_info("Pstate_freq[%d] = %dMHz\t", index,
 			    Pstate_feq[index]);
 		printk_info("Pstate_vid[%d] = %d\t", index, Pstate_vid[index]);
 		printk_info("Pstate_volt[%d] = %dmv\t", index,
@@ -414,8 +414,11 @@
 
 	/*
 	 * Modify the DSDT Table to put the actural _PSS package
-	 * corefeq-->Pstate_feq[index] power-->Pstate_power[index] transitionlatency-->0x64 busmasterlatency-->0x7,
-	 * control-->0xE8202C00| Pstate_vid[index]<<6 | Pstate_fid[index]
+	 * corefeq-->Pstate_feq[index]
+	 * power-->Pstate_power[index]
+	 * transitionlatency-->0x64
+	 * busmasterlatency-->0x7,
+	 * control--> 0xE8202800| Pstate_vid[index]<<6 | Pstate_fid[index]
 	 * status --> Pstate_vid[index]<<6 | Pstate_fid[index]
 	 * Get the _PSS control method Sig.
 	 */
@@ -461,7 +464,13 @@
 				transitionlatency = 0x64;
 				busmasterlatency = 0x7;
 				control =
-				    0xE8202C00 | (Pstate_vid[index] << 6) |
+				    (0x3 << 30) | /* IRT */
+				    (0x2 << 28) | /* RVO */
+				    (0x1 << 27) | /* ExtType */
+				    (0x2 << 20) | /* PLL_LOCK_TIME */
+				    (0x0 << 18) | /* MVS */
+				    (0x5 << 11) | /* VST */
+				    (Pstate_vid[index] << 6) |
 				    Pstate_fid[index];
 				status =
 				    (Pstate_vid[index] << 6) |
--- src/mainboard/amd/dbm690t/acpi_tables.c	(Revision 3850)
+++ src/mainboard/amd/dbm690t/acpi_tables.c	(Arbeitskopie)
@@ -260,7 +260,7 @@
 
 	/* Get the multipier of the fid frequency */
 	/*
-	 * Fid multiplier is always 100 revF and revG.
+	 * Fid multiplier is always 100 revF and revG.
 	 */
 	fid_multiplier = 100;
 
@@ -400,10 +400,10 @@
 		Pstate_num++;
 	}
 
-	/* Print Pstate feq,vid,volt,power */
+	/* Print Pstate freq,vid,volt,power */
 
 	for (index = 0; index < Pstate_num; index++) {
-		printk_info("Pstate_feq[%d] = %dMHz\t", index,
+		printk_info("Pstate_freq[%d] = %dMHz\t", index,
 			    Pstate_feq[index]);
 		printk_info("Pstate_vid[%d] = %d\t", index, Pstate_vid[index]);
 		printk_info("Pstate_volt[%d] = %dmv\t", index,
@@ -414,8 +414,11 @@
 
 	/*
 	 * Modify the DSDT Table to put the actural _PSS package
-	 * corefeq-->Pstate_feq[index] power-->Pstate_power[index] transitionlatency-->0x64 busmasterlatency-->0x7,
-	 * control-->0xE8202C00| Pstate_vid[index]<<6 | Pstate_fid[index]
+	 * corefeq-->Pstate_feq[index]
+	 * power-->Pstate_power[index]
+	 * transitionlatency-->0x64
+	 * busmasterlatency-->0x7,
+	 * control--> 0xE8202800| Pstate_vid[index]<<6 | Pstate_fid[index]
 	 * status --> Pstate_vid[index]<<6 | Pstate_fid[index]
 	 * Get the _PSS control method Sig.
 	 */
@@ -461,7 +464,13 @@
 				transitionlatency = 0x64;
 				busmasterlatency = 0x7;
 				control =
-				    0xE8202C00 | (Pstate_vid[index] << 6) |
+				    (0x3 << 30) | /* IRT */
+				    (0x2 << 28) | /* RVO */
+				    (0x1 << 27) | /* ExtType */
+				    (0x2 << 20) | /* PLL_LOCK_TIME */
+				    (0x0 << 18) | /* MVS */
+				    (0x5 << 11) | /* VST */
+				    (Pstate_vid[index] << 6) |
 				    Pstate_fid[index];
 				status =
 				    (Pstate_vid[index] << 6) |


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

-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: linuxbios_fam0f_fidvid_pss_fix.diff
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20090115/9b1dee7d/attachment.ksh>

From c-d.hailfinger.devel.2006 at gmx.net  Thu Jan 15 07:31:58 2009
From: c-d.hailfinger.devel.2006 at gmx.net (Carl-Daniel Hailfinger)
Date: Thu, 15 Jan 2009 07:31:58 +0100
Subject: [coreboot] [PATCH] Convert print_* to printk_* in K8 RAM init
Message-ID: <496ED85E.6020202@gmx.net>

Since all K8 targets now have CONFIG_USE_PRINTK_IN_CAR enabled, using
print_* in K8 RAM init does not make sense anymore. Convert almost all
print_* to printk_*.
This improves readability a lot and makes the code shorter.

Add a warning about false negatives in the DIMM dual channel
compatibility check. This needs to be implemented correctly.

Fix a few typos.

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

Index: LinuxBIOSv2-asus_m2a-vm/src/northbridge/amd/amdk8/raminit_f.c
===================================================================
--- LinuxBIOSv2-asus_m2a-vm/src/northbridge/amd/amdk8/raminit_f.c	(Revision 3850)
+++ LinuxBIOSv2-asus_m2a-vm/src/northbridge/amd/amdk8/raminit_f.c	(Arbeitskopie)
@@ -34,34 +34,20 @@
 #define QRANK_DIMM_SUPPORT 0
 #endif
 
-static inline void print_raminit(const char *strval, uint32_t val)
-{
 #if CONFIG_USE_PRINTK_IN_CAR
-	printk_debug("%s%08x\r\n", strval, val);
 #else
-	print_debug(strval); print_debug_hex32(val); print_debug("\r\n");
+#error This file needs CONFIG_USE_PRINTK_IN_CAR
 #endif
-}
 
-#define RAM_TIMING_DEBUG 0
+#define RAM_TIMING_DEBUG 1
 
-static inline void print_tx(const char *strval, uint32_t val)
-{
 #if RAM_TIMING_DEBUG == 1
-	print_raminit(strval, val);
+#define printk_raminit printk_debug
+#else
+#define printk_raminit(fmt, arg...)   do {} while(0)
 #endif
-}
 
 
-static inline void print_t(const char *strval)
-{
-#if RAM_TIMING_DEBUG == 1
-	print_debug(strval);
-#endif
-}
-
-
-
 #if (CONFIG_LB_MEM_TOPK & (CONFIG_LB_MEM_TOPK -1)) != 0
 # error "CONFIG_LB_MEM_TOPK must be a power of 2"
 #endif
@@ -713,9 +699,7 @@
 	}
 	sysinfo->ctrl_present[ctrl->node_id] = 1;
 
-	print_spew("setting up CPU");
-	print_spew_hex8(ctrl->node_id);
-	print_spew(" northbridge registers\r\n");
+	printk_spew("setting up CPU %02x northbridge registers\n", ctrl->node_id);
 	max = ARRAY_SIZE(register_values);
 	for (i = 0; i < max; i += 3) {
 		device_t dev;
@@ -729,7 +713,7 @@
 		pci_write_config32(dev, where, reg);
 	}
 
-	print_spew("done.\r\n");
+	printk_spew("done.\n");
 }
 
 
@@ -829,14 +813,14 @@
 	if (value <=4 ) value += 8; // add back to 1G to high
 	value += (27-5); // make 128MB to the real lines
 	if ( value != (sz->per_rank)) {
-		print_err("Bad RANK Size --\r\n");
+		printk_err("Bad RANK Size --\n");
 		goto val_err;
 	}
 
 	goto out;
 
  val_err:
-	die("Bad SPD value\r\n");
+	die("Bad SPD value\n");
 	/* If an hw_error occurs report that I have no memory */
  hw_err:
 	sz->per_rank = 0;
@@ -1070,9 +1054,7 @@
 	}
 
 	/* Report the amount of memory. */
-	print_debug("RAM: 0x");
-	print_debug_hex32(tom_k);
-	print_debug(" KB\r\n");
+	printk_debug("RAM: 0x%08x kB\n", tom_k);
 
 	msr_t msr;
 	if (tom_k > (4*1024*1024)) {
@@ -1202,7 +1184,7 @@
 		csbase += csbase_inc;
 	}
 
-	print_debug("Interleaved\r\n");
+	printk_debug("Interleaved\n");
 
 	/* Return the memory size in K */
 	return common_size << ((27-10) + bits);
@@ -1306,7 +1288,7 @@
 	    CMOS_VLEN_interleave_chip_selects, 1) != 0) {
 		tom_k = interleave_chip_selects(ctrl, meminfo->is_Width128);
 	} else {
-		print_debug("Interleaving disabled\r\n");
+		printk_debug("Interleaving disabled\n");
 		tom_k = 0;
 	}
 	
@@ -1325,9 +1307,7 @@
 static long disable_dimm(const struct mem_controller *ctrl, unsigned index,
 			  struct mem_info *meminfo)
 {
-	print_debug("disabling dimm");
-	print_debug_hex8(index);
-	print_debug("\r\n");
+	printk_debug("disabling dimm %02x\n", index);
 	if (!(meminfo->dimm_mask & 0x0F) && (meminfo->dimm_mask & 0xF0)) { /* channelB only? */
 		pci_write_config32(ctrl->f2, DRAM_CSBASE + (((index << 1) + 4) << 2), 0);
 		pci_write_config32(ctrl->f2, DRAM_CSBASE + (((index << 1) + 5) << 2), 0);
@@ -1402,9 +1382,9 @@
 
 #if 1
 	if (meminfo->is_registered) {
-		print_debug("Registered\r\n");
+		printk_debug("Registered\n");
 	} else {
-		print_debug("Unbuffered\r\n");
+		printk_debug("Unbuffered\n");
 	}
 #endif
 	return meminfo->dimm_mask;
@@ -1448,15 +1428,11 @@
 		4,	/* *Column addresses */
 		5,	/* *Number of DIMM Ranks */
 		6,	/* *Module Data Width*/
-		9,	/* *Cycle time at highest CAS Latency CL=X */
 		11,	/* *DIMM Conf Type */
 		13,	/* *Pri SDRAM Width */
 		17,	/* *Logical Banks */
-		18,	/* *Supported CAS Latencies */
 		20,	/* *DIMM Type Info */
 		21,	/* *SDRAM Module Attributes */
-		23,	/* *Cycle time at CAS Latnecy (CLX - 1) */
-		26,	/* *Cycle time at CAS Latnecy (CLX - 2) */
 		27,	/* *tRP Row precharge time */
 		28,	/* *Minimum Row Active to Row Active Delay (tRRD) */
 		29,	/* *tRCD RAS to CAS */
@@ -1464,11 +1440,18 @@
 		36,	/* *Write recovery time (tWR) */
 		37,	/* *Internal write to read command delay (tRDP) */
 		38,	/* *Internal read to precharge commanfd delay (tRTP) */
+#warning Why is SPD address 41 checked twice?
 		41,	/* *Extension of Byte 41 tRC and Byte 42 tRFC */
 		41,	/* *Minimum Active to Active/Auto Refresh Time(Trc) */
 		42,	/* *Minimum Auto Refresh Command Time(Trfc) */
+#warning The SPD addresses below need special treatment like in spd_set_memclk. Right now they cause many false negatives.
+		18,	/* *Supported CAS Latencies */
+		9,	/* *Cycle time at highest CAS Latency CL=X */
+		23,	/* *Cycle time at CAS Latency (CLX - 1) */
+		26,	/* *Cycle time at CAS Latency (CLX - 2) */
 	};
 	u32 dcl, dcm;
+	u8 common_cl;
 
 /* S1G1 and AM2 sockets are Mod64BitMux capable. */
 #if CPU_SOCKET_TYPE == 0x11 || CPU_SOCKET_TYPE == 0x12
@@ -1497,6 +1480,14 @@
 		}
 		device0 = ctrl->channel0[i];
 		device1 = ctrl->channel1[i];
+		/* Abort if the chips don't support a common CAS latency. */
+		common_cl = spd_read_byte(device0, 18) & spd_read_byte(device1, 18);
+		if (!common_cl) {
+			printk_debug("No common CAS latency supported\n");
+			goto single_channel;
+		} else {
+			printk_raminit("Common CAS latency bitfield: 0x%02x\n", common_cl);
+		}
 		for (j = 0; j < ARRAY_SIZE(addresses); j++) {
 			unsigned addr;
 			addr = addresses[j];
@@ -1509,11 +1500,12 @@
 				return -1;
 			}
 			if (value0 != value1) {
+				printk_raminit("SPD values differ between channel 0/1 for byte %i\n", addr);
 				goto single_channel;
 			}
 		}
 	}
-	print_spew("Enabling dual channel memory\r\n");
+	printk_spew("Enabling dual channel memory\n");
 	dcl = pci_read_config32(ctrl->f2, DRAM_CONFIG_LOW);
 	dcl &= ~DCL_BurstLength32;  /*	32byte mode may be preferred in platforms that include graphics controllers that generate a lot of 32-bytes system memory accesses
 					32byte mode is not supported when the DRAM interface is 128 bits wides, even 32byte mode is set, system still use 64 byte mode	*/
@@ -1566,7 +1558,7 @@
 
 	static const struct mem_param speed[] = {
 		{
-			.name	    = "200Mhz\r\n",
+			.name	    = "200Mhz\n",
 			.cycle_time = 0x500,
 			.divisor    = 200, // how many 1/40ns per clock
 			.dch_memclk = DCH_MemClkFreq_200MHz, //0
@@ -1578,7 +1570,7 @@
 
 		},
 		{
-			.name	    = "266Mhz\r\n",
+			.name	    = "266Mhz\n",
 			.cycle_time = 0x375,
 			.divisor    = 150, //????
 			.dch_memclk = DCH_MemClkFreq_266MHz, //1
@@ -1589,7 +1581,7 @@
 			.DcqByPassMax = 4,
 		},
 		 {
-			.name       = "333Mhz\r\n",
+			.name       = "333Mhz\n",
 			.cycle_time = 0x300,
 			.divisor    = 120,
 			.dch_memclk = DCH_MemClkFreq_333MHz, //2
@@ -1601,7 +1593,7 @@
 
 		 },
 		{
-			.name	    = "400Mhz\r\n",
+			.name	    = "400Mhz\n",
 			.cycle_time = 0x250,
 			.divisor    = 100,
 			.dch_memclk = DCH_MemClkFreq_400MHz,//3
@@ -1628,9 +1620,10 @@
 	if (!param->cycle_time) {
 		die("min_cycle_time to low");
 	}
-	print_spew(param->name);
 #ifdef DRAM_MIN_CYCLE_TIME
-	print_debug(param->name);
+	printk_debug(param->name);
+#else
+	printk_spew(param->name);
 #endif
 	return param;
 }
@@ -1722,7 +1715,7 @@
 	}
 	min_latency = 3;
 
-	print_tx("1 min_cycle_time:", min_cycle_time);
+	printk_raminit("1 min_cycle_time: %08x\n", min_cycle_time);
 
 	/* Compute the least latency with the fastest clock supported
 	 * by both the memory controller and the dimms.
@@ -1734,7 +1727,7 @@
 		int latency;
 		u32 spd_device = ctrl->channel0[i];
 
-		print_tx("1.1 dimm_mask:", meminfo->dimm_mask);
+		printk_raminit("1.1 dimm_mask: %08x\n", meminfo->dimm_mask);
 		if (!(meminfo->dimm_mask & (1 << i))) {
 			if (meminfo->dimm_mask & (1 << (DIMM_SOCKETS + i))) { /* channelB only? */
 				spd_device = ctrl->channel1[i];
@@ -1756,8 +1749,8 @@
 		latencies = spd_read_byte(spd_device, SPD_CAS_LAT);
 		if (latencies <= 0) continue;
 
-		print_tx("i:",i);
-		print_tx("\tlatencies:", latencies);
+		printk_raminit("i: %08x\n",i);
+		printk_raminit("\tlatencies: %08x\n", latencies);
 		/* Compute the lowest cas latency supported */
 		latency = log2(latencies) - 2;
 
@@ -1773,15 +1766,15 @@
 				goto hw_error;
 			}
 
-			print_tx("\tindex:", index);
-			print_tx("\t\tlatency:", latency);
-			print_tx("\t\tvalue1:", value);
+			printk_raminit("\tindex: %08x\n", index);
+			printk_raminit("\t\tlatency: %08x\n", latency);
+			printk_raminit("\t\tvalue1: %08x\n", value);
 
 			value = convert_to_linear(value);
 
-			print_tx("\t\tvalue2:", value);
+			printk_raminit("\t\tvalue2: %08x\n", value);
 
-			/* Only increase the latency if we decreas the clock */
+			/* Only increase the latency if we decrease the clock */
 			if (value >= min_cycle_time ) {
 				if (value < new_cycle_time) {
 					new_cycle_time = value;
@@ -1792,8 +1785,8 @@
 					}
 				}
 			}
-			print_tx("\t\tnew_cycle_time:", new_cycle_time);
-			print_tx("\t\tnew_latency:", new_latency);
+			printk_raminit("\t\tnew_cycle_time: %08x\n", new_cycle_time);
+			printk_raminit("\t\tnew_latency: %08x\n", new_latency);
 
 		}
 
@@ -1811,15 +1804,15 @@
 			min_latency = new_latency;
 		}
 
-		print_tx("2 min_cycle_time:", min_cycle_time);
-		print_tx("2 min_latency:", min_latency);
+		printk_raminit("2 min_cycle_time: %08x\n", min_cycle_time);
+		printk_raminit("2 min_latency: %08x\n", min_latency);
 	}
 	/* Make a second pass through the dimms and disable
 	 * any that cannot support the selected memclk and cas latency.
 	 */
 
-	print_tx("3 min_cycle_time:", min_cycle_time);
-	print_tx("3 min_latency:", min_latency);
+	printk_raminit("3 min_cycle_time: %08x\n", min_cycle_time);
+	printk_raminit("3 min_latency: %08x\n", min_latency);
 
 	for (i = 0; (i < DIMM_SOCKETS); i++) {
 		int latencies;
@@ -1874,7 +1867,7 @@
 		meminfo->dimm_mask = disable_dimm(ctrl, i, meminfo);
 	}
 
-	print_tx("4 min_cycle_time:", min_cycle_time);
+	printk_raminit("4 min_cycle_time: %08x\n", min_cycle_time);
 
 	/* Now that I know the minimum cycle time lookup the memory parameters */
 	result.param = get_mem_param(min_cycle_time);
@@ -1886,7 +1879,7 @@
 	value |= result.param->dch_memclk << DCH_MemClkFreq_SHIFT;
 	pci_write_config32(ctrl->f2, DRAM_CONFIG_HIGH, value);
 
-	print_debug(result.param->name);
+	printk_debug(result.param->name);
 
 	/* Update DRAM Timing Low with our selected cas latency */
 	value = pci_read_config32(ctrl->f2, DRAM_TIMING_LOW);
@@ -2054,16 +2047,16 @@
 
 	value = spd_read_byte(spd_device, SPD_TRAS); //in 1 ns
 	if (value < 0) return -1;
-	print_tx("update_dimm_Tras: 0 value=", value);
+	printk_raminit("update_dimm_Tras: 0 value= %08x\n", value);
 
 	value <<= 2; //convert it to in 1/4ns
 
 	value *= 10;
-	print_tx("update_dimm_Tras:  1 value=", value);
+	printk_raminit("update_dimm_Tras:  1 value= %08x\n", value);
 
 	clocks = (value  + param->divisor - 1)/param->divisor;
-	print_tx("update_dimm_Tras: divisor=", param->divisor);
-	print_tx("update_dimm_Tras: clocks=", clocks);
+	printk_raminit("update_dimm_Tras: divisor= %08x\n", param->divisor);
+	printk_raminit("update_dimm_Tras: clocks= %08x\n", clocks);
 	if (clocks < DTL_TRAS_MIN) {
 		clocks = DTL_TRAS_MIN;
 	}
@@ -2366,8 +2359,8 @@
 	uint32_t reg;
 
 	if ((val < TT_MIN) || (val > TT_MAX)) {
-		print_err(str);
-		die(" Unknown\r\n");
+		printk_err(str);
+		die(" Unknown\n");
 	}
 
 	reg = pci_read_config32(ctrl->f2, TT_REG);
@@ -2610,12 +2603,12 @@
 		break;
 	}
 
-	print_raminit("\tdimm_mask = ", meminfo->dimm_mask);
-	print_raminit("\tx4_mask = ", meminfo->x4_mask);
-	print_raminit("\tx16_mask = ", meminfo->x16_mask);
-	print_raminit("\tsingle_rank_mask = ", meminfo->single_rank_mask);
-	print_raminit("\tODC = ", dword);
-	print_raminit("\tAddr Timing= ", dwordx);
+	printk_raminit("\tdimm_mask = %08x\n", meminfo->dimm_mask);
+	printk_raminit("\tx4_mask = %08x\n", meminfo->x4_mask);
+	printk_raminit("\tx16_mask = %08x\n", meminfo->x16_mask);
+	printk_raminit("\tsingle_rank_mask = %08x\n", meminfo->single_rank_mask);
+	printk_raminit("\tODC = %08x\n", dword);
+	printk_raminit("\tAddr Timing= %08x\n", dwordx);
 #endif
 
 #if (DIMM_SUPPORT & 0x0100)==0x0000 /* 2T mode only used for unbuffered DIMM */
@@ -2697,37 +2690,37 @@
 		    !(meminfo->dimm_mask & (1 << (DIMM_SOCKETS + i))) ) {
 			continue;
 		}
-		print_tx("spd_set_dram_timing dimm socket: ", i);
+		printk_raminit("spd_set_dram_timing dimm socket:  %08x\n", i);
 		/* DRAM Timing Low Register */
-		print_t("\ttrc\r\n");
+		printk_raminit("\ttrc\n");
 		if ((rc = update_dimm_Trc (ctrl, param, i, meminfo->dimm_mask)) <= 0) goto dimm_err;
 
-		print_t("\ttrcd\r\n");
+		printk_raminit("\ttrcd\n");
 		if ((rc = update_dimm_Trcd(ctrl, param, i, meminfo->dimm_mask)) <= 0) goto dimm_err;
 
-		print_t("\ttrrd\r\n");
+		printk_raminit("\ttrrd\n");
 		if ((rc = update_dimm_Trrd(ctrl, param, i, meminfo->dimm_mask)) <= 0) goto dimm_err;
 
-		print_t("\ttras\r\n");
+		printk_raminit("\ttras\n");
 		if ((rc = update_dimm_Tras(ctrl, param, i, meminfo->dimm_mask)) <= 0) goto dimm_err;
 
-		print_t("\ttrp\r\n");
+		printk_raminit("\ttrp\n");
 		if ((rc = update_dimm_Trp (ctrl, param, i, meminfo->dimm_mask)) <= 0) goto dimm_err;
 
-		print_t("\ttrtp\r\n");
+		printk_raminit("\ttrtp\n");
 		if ((rc = update_dimm_Trtp(ctrl, param, i, meminfo)) <= 0) goto dimm_err;
 
-		print_t("\ttwr\r\n");
+		printk_raminit("\ttwr\n");
 		if ((rc = update_dimm_Twr (ctrl, param, i, meminfo->dimm_mask)) <= 0) goto dimm_err;
 
 		/* DRAM Timing High Register */
-		print_t("\ttref\r\n");
+		printk_raminit("\ttref\n");
 		if ((rc = update_dimm_Tref(ctrl, param, i, meminfo->dimm_mask)) <= 0) goto dimm_err;
 
-		print_t("\ttwtr\r\n");
+		printk_raminit("\ttwtr\n");
 		if ((rc = update_dimm_Twtr(ctrl, param, i, meminfo->dimm_mask)) <= 0) goto dimm_err;
 
-		print_t("\ttrfc\r\n");
+		printk_raminit("\ttrfc\n");
 		if ((rc = update_dimm_Trfc(ctrl, param, i, meminfo)) <= 0) goto dimm_err;
 
 		/* DRAM Config Low */
@@ -2784,37 +2777,37 @@
 #endif
 	meminfo = &sysinfo->meminfo[ctrl->node_id];
 
-	print_debug_addr("sdram_set_spd_registers: paramx :", &paramx);
+	printk_debug("sdram_set_spd_registers: paramx :%p\n", &paramx);
 
 	activate_spd_rom(ctrl);
 	meminfo->dimm_mask = spd_detect_dimms(ctrl);
 
-	print_tx("sdram_set_spd_registers: dimm_mask=0x%x\n", meminfo->dimm_mask);
+	printk_raminit("sdram_set_spd_registers: dimm_mask=0x%x\n", meminfo->dimm_mask);
 
 	if (!(meminfo->dimm_mask & ((1 << 2*DIMM_SOCKETS) - 1)))
 	{
-		print_debug("No memory for this cpu\r\n");
+		printk_debug("No memory for this cpu\n");
 		return;
 	}
 	meminfo->dimm_mask = spd_enable_2channels(ctrl, meminfo);
-	print_tx("spd_enable_2channels: dimm_mask=0x%x\n", meminfo->dimm_mask);
+	printk_raminit("spd_enable_2channels: dimm_mask=0x%x\n", meminfo->dimm_mask);
 	if (meminfo->dimm_mask == -1)
 		goto hw_spd_err;
 
 	meminfo->dimm_mask = spd_set_ram_size(ctrl, meminfo);
-	print_tx("spd_set_ram_size: dimm_mask=0x%x\n", meminfo->dimm_mask);
+	printk_raminit("spd_set_ram_size: dimm_mask=0x%x\n", meminfo->dimm_mask);
 	if (meminfo->dimm_mask == -1)
 		goto hw_spd_err;
 
 	meminfo->dimm_mask = spd_handle_unbuffered_dimms(ctrl, meminfo);
-	print_tx("spd_handle_unbuffered_dimms: dimm_mask=0x%x\n", meminfo->dimm_mask);
+	printk_raminit("spd_handle_unbuffered_dimms: dimm_mask=0x%x\n", meminfo->dimm_mask);
 	if (meminfo->dimm_mask == -1)
 		goto hw_spd_err;
 
 	result = spd_set_memclk(ctrl, meminfo);
 	param     = result.param;
 	meminfo->dimm_mask = result.dimm_mask;
-	print_tx("spd_set_memclk: dimm_mask=0x%x\n", meminfo->dimm_mask);
+	printk_raminit("spd_set_memclk: dimm_mask=0x%x\n", meminfo->dimm_mask);
 	if (meminfo->dimm_mask == -1)
 		goto hw_spd_err;
 
@@ -2826,7 +2819,7 @@
 	paramx.divisor = get_exact_divisor(param->dch_memclk, paramx.divisor);
 
 	meminfo->dimm_mask = spd_set_dram_timing(ctrl, &paramx, meminfo);
-	print_tx("spd_set_dram_timing: dimm_mask=0x%x\n", meminfo->dimm_mask);
+	printk_raminit("spd_set_dram_timing: dimm_mask=0x%x\n", meminfo->dimm_mask);
 	if (meminfo->dimm_mask == -1)
 		goto hw_spd_err;
 
@@ -2961,13 +2954,13 @@
 	/* FIXME: How about 32 node machine later? */
 	tsc_t tsc, tsc0[8];
 
-	print_debug_addr("sdram_enable: tsc0[8]: ", &tsc0[0]);
+	printk_debug("sdram_enable: tsc0[8]: %p", &tsc0[0]);
 #endif
 	uint32_t dword;
 
 	/* Error if I don't have memory */
 	if (memory_end_k(ctrl, controllers) == 0) {
-		die("No memory\r\n");
+		die("No memory\n");
 	}
 
 	/* Before enabling memory start the memory clocks */
@@ -2993,12 +2986,12 @@
 	/* We need to wait a mimmium of 20 MEMCLKS to enable the  InitDram */
 	memreset(controllers, ctrl);
 #if 0
-	print_debug("prepare to InitDram:");
+	printk_debug("prepare to InitDram:");
 	for (i=0; i<10; i++) {
-		print_debug_hex32(i);
+		printk_debug("%08x", i);
 		print_debug("\b\b\b\b\b\b\b\b");
 	}
-	print_debug("\r\n");
+	printk_debug("\n");
 #endif
 
 	for (i = 0; i < controllers; i++) {
@@ -3015,7 +3008,7 @@
 		dcl = pci_read_config32(ctrl[i].f2, DRAM_CONFIG_LOW);
 		if (dcl & DCL_DimmEccEn) {
 			uint32_t mnc;
-			print_spew("ECC enabled\r\n");
+			printk_spew("ECC enabled\n");
 			mnc = pci_read_config32(ctrl[i].f3, MCA_NB_CONFIG);
 			mnc |= MNC_ECC_EN;
 			if (dcl & DCL_Width128) {
@@ -3057,17 +3050,17 @@
 		/* Skip everything if I don't have any memory on this controller */
 		if (sysinfo->meminfo[i].dimm_mask==0x00) continue;
 
-		print_debug("Initializing memory: ");
+		printk_debug("Initializing memory: ");
 		int loops = 0;
 		do {
 			dcl = pci_read_config32(ctrl[i].f2, DRAM_CONFIG_LOW);
 			loops++;
 			if ((loops & 1023) == 0) {
-				print_debug(".");
+				printk_debug(".");
 			}
 		} while(((dcl & DCL_InitDram) != 0) && (loops < TIMEOUT_LOOPS));
 		if (loops >= TIMEOUT_LOOPS) {
-			print_debug(" failed\r\n");
+			printk_debug(" failed\n");
 			continue;
 		}
 
@@ -3080,7 +3073,7 @@
 		if (cpu_f0_f1[i]) {
 			tsc= rdtsc();
 
-			print_debug_dqs_tsc("\r\nbegin tsc0", i, tsc0[i].hi, tsc0[i].lo, 2);
+			print_debug_dqs_tsc("\nbegin tsc0", i, tsc0[i].hi, tsc0[i].lo, 2);
 			print_debug_dqs_tsc("end   tsc ", i, tsc.hi, tsc.lo, 2);
 
 			if (tsc.lo<tsc0[i].lo) {
@@ -3095,7 +3088,7 @@
 			print_debug_dqs_tsc("     dtsc0", i, tsc0[i].hi, tsc0[i].lo, 2);
 		}
 #endif
-		print_debug(" done\r\n");
+		printk_debug(" done\n");
 	}
 
 #if HW_MEM_HOLE_SIZEK != 0
Index: LinuxBIOSv2-asus_m2a-vm/src/northbridge/amd/amdk8/raminit_f_dqs.c
===================================================================
--- LinuxBIOSv2-asus_m2a-vm/src/northbridge/amd/amdk8/raminit_f_dqs.c	(Revision 3850)
+++ LinuxBIOSv2-asus_m2a-vm/src/northbridge/amd/amdk8/raminit_f_dqs.c	(Arbeitskopie)
@@ -21,15 +21,16 @@
 //0: mean no debug info
 #define DQS_TRAIN_DEBUG 0
 
+#if CONFIG_USE_PRINTK_IN_CAR
+#else
+#error This file needs CONFIG_USE_PRINTK_IN_CAR
+#endif
+
 static inline void print_debug_dqs(const char *str, unsigned val, unsigned level)
 {
 #if DQS_TRAIN_DEBUG > 0
 	if(DQS_TRAIN_DEBUG > level) {
-		#if CONFIG_USE_PRINTK_IN_CAR
 		printk_debug("%s%x\r\n", str, val);
-		#else
-		print_debug(str); print_debug_hex32(val); print_debug("\r\n");
-		#endif
 	}
 #endif
 }
@@ -38,11 +39,7 @@
 {
 #if DQS_TRAIN_DEBUG > 0
 	if(DQS_TRAIN_DEBUG > level) {
-		#if CONFIG_USE_PRINTK_IN_CAR
 		printk_debug("%s%08x%s%08x\r\n", str, val, str2, val2);
-		#else
-		print_debug(str); print_debug_hex32(val); print_debug(str2); print_debug_hex32(val2); print_debug("\r\n");
-		#endif
 	}
 #endif
 }
@@ -51,22 +48,14 @@
 {
 #if DQS_TRAIN_DEBUG > 0
 	if(DQS_TRAIN_DEBUG > level) {
-		#if CONFIG_USE_PRINTK_IN_CAR
 		printk_debug("%s[%02x]=%08x%08x\r\n", str, i, val, val2);
-		#else
-		print_debug(str); print_debug("["); print_debug_hex8(i); print_debug("]="); print_debug_hex32(val); print_debug_hex32(val2); print_debug("\r\n");
-		#endif
 	}
 #endif
 }
 
 static inline void print_debug_dqs_tsc_x(const char *str, unsigned i, unsigned val, unsigned val2)
 {
-	#if CONFIG_USE_PRINTK_IN_CAR
 	printk_debug("%s[%02x]=%08x%08x\r\n", str, i, val, val2);
-	#else
-	print_debug(str); print_debug("["); print_debug_hex8(i); print_debug("]="); print_debug_hex32(val); print_debug_hex32(val2); print_debug("\r\n");
-	#endif
 
 }
 
@@ -855,11 +844,7 @@
 
 #if MEM_TRAIN_SEQ != 1
 	/* We need tidy output for type 1 */
-	#if CONFIG_USE_PRINTK_IN_CAR
-	printk_debug(" CTLRMaxDelay=%02x", CTLRMaxDelay);
-	#else
-	print_debug(" CTLRMaxDelay="); print_debug_hex8(CTLRMaxDelay);
-	#endif
+	printk_debug(" CTLRMaxDelay=%02x\n", CTLRMaxDelay);
 #endif
 
 	return (CTLRMaxDelay==0xae)?1:0;
@@ -1135,7 +1120,7 @@
 
 	print_debug_dqs("\t\t\tTrainDQSPos begin ", 0, 3);
 
-	print_debug_addr("TrainDQSPos: MutualCSPassW[48] :", MutualCSPassW);
+	printk_debug("TrainDQSPos: MutualCSPassW[48] :%p\n", MutualCSPassW);
 
 	for(DQSDelay=0; DQSDelay<48; DQSDelay++) {
 		MutualCSPassW[DQSDelay] = 0xff; // Bitmapped status per delay setting, 0xff=All positions passing (1= PASS)
@@ -1408,7 +1393,7 @@
 
 	print_debug_dqs("\r\nTrainDQSRdWrPos: 0 ctrl ", ctrl->node_id, 0);
 
-	print_debug_addr("TrainDQSRdWrPos: buf_a:", buf_a);
+	printk_debug("TrainDQSRdWrPos: buf_a:%p\n", buf_a);
 
 	Errors = 0;
 	channel = 0;
@@ -1542,7 +1527,7 @@
 {
 	print_debug_dqs("\r\ntrain_DqsPos: begin ctrl ", ctrl->node_id, 0);
 	if(TrainDQSRdWrPos(ctrl, sysinfo) != 0) {
-		print_err("\r\nDQS Training Rd Wr failed ctrl"); print_err_hex8(ctrl->node_id); print_err("\r\n");
+		printk_err("\r\nDQS Training Rd Wr failed ctrl%02x\r\n", ctrl->node_id);
 		return 1;
 	}
 	else {
@@ -1705,19 +1690,11 @@
 		}
 		sizek = 1 << align;
 #if MEM_TRAIN_SEQ != 1
-	#if CONFIG_USE_PRINTK_IN_CAR
 		printk_debug("Setting variable MTRR %d, base: %4dMB, range: %4dMB, type %s\r\n",
 			reg, range_startk >>10, sizek >> 10,
 			(type==MTRR_TYPE_UNCACHEABLE)?"UC":
 			    ((type==MTRR_TYPE_WRBACK)?"WB":"Other")
 			);
-	#else
-		print_debug("Setting variable MTRR "); print_debug_hex8(reg); print_debug(", base: "); print_debug_hex16(range_startk>>10);
-			print_debug("MB, range: "); print_debug_hex16(sizek >> 10); print_debug("MB, type ");
-			print_debug( (type==MTRR_TYPE_UNCACHEABLE)?"UC\r\n":
-				      ((type==MTRR_TYPE_WRBACK)?"WB\r\n":"Other\r\n")
-				   );
-	#endif
 #endif
 		set_var_mtrr_dqs(reg++, range_startk, sizek, type, address_bits);
 		range_startk += sizek;
@@ -1866,10 +1843,9 @@
 		/* Skip everything if I don't have any memory on this controller */
 		if(sysinfo->meminfo[i].dimm_mask==0x00) continue;
 
-		print_debug("DQS Training:RcvrEn:Pass1: ");
-		print_debug_hex8(i);
+		printk_debug("DQS Training:RcvrEn:Pass1: %02x\n", i);
 		if(train_DqsRcvrEn(ctrl+i, 1, sysinfo)) goto out;
-       		print_debug(" done\r\n");
+       		printk_debug(" done\r\n");
 	}
 
 	tsc[1] = rdtsc();
@@ -1885,10 +1861,9 @@
 		/* Skip everything if I don't have any memory on this controller */
 		if(sysinfo->meminfo[i].dimm_mask==0x00) continue;
 
-		print_debug("DQS Training:DQSPos: ");
-		print_debug_hex8(i);
+		printk_debug("DQS Training:DQSPos: %02x\n", i);
 		if(train_DqsPos(ctrl+i, sysinfo)) goto out;
-		print_debug(" done\r\n");
+		printk_debug(" done\r\n");
 	}
 
 	tsc[3] = rdtsc();
@@ -1899,10 +1874,9 @@
 		/* Skip everything if I don't have any memory on this controller */
 		if(sysinfo->meminfo[i].dimm_mask==0x00) continue;
 
-		print_debug("DQS Training:RcvrEn:Pass2: ");
-		print_debug_hex8(i);
+		printk_debug("DQS Training:RcvrEn:Pass2: %02x\n", i);
 		if(train_DqsRcvrEn(ctrl+i, 2, sysinfo)) goto out;
-		print_debug(" done\r\n");
+		printk_debug(" done\r\n");
 		sysinfo->mem_trained[i]=1;
 	}
 
@@ -1943,8 +1917,7 @@
 	if(v) {
 		tsc[0] = rdtsc();
 
-		print_debug("set DQS timing:RcvrEn:Pass1: ");
-		print_debug_hex8(i);
+		printk_debug("set DQS timing:RcvrEn:Pass1: %02x\n", i);
 	}
 	if(train_DqsRcvrEn(ctrl, 1,  sysinfo)) {
 		sysinfo->mem_trained[i]=0x81; //
@@ -1952,10 +1925,9 @@
 	}
 
 	if(v) {
-		print_debug(" done\r\n");
+		printk_debug(" done\r\n");
 		tsc[1] = rdtsc();
-		print_debug("set DQS timing:DQSPos: ");
-		print_debug_hex8(i);
+		printk_debug("set DQS timing:DQSPos: %02x\n", i);
 	}
 
 	if(train_DqsPos(ctrl, sysinfo)) {
@@ -1964,11 +1936,10 @@
 	}
 
 	if(v) {
-		print_debug(" done\r\n");
+		printk_debug(" done\r\n");
 		tsc[2] = rdtsc();
 
-		print_debug("set DQS timing:RcvrEn:Pass2: ");
-		print_debug_hex8(i);
+		printk_debug("set DQS timing:RcvrEn:Pass2: %02x\n", i);
 	}
 	if(train_DqsRcvrEn(ctrl, 2,  sysinfo)){
 		sysinfo->mem_trained[i]=0x83; //
@@ -1976,7 +1947,7 @@
 	}
 
 	if(v) {
-		print_debug(" done\r\n");
+		printk_debug(" done\r\n");
 
 		tsc[3] = rdtsc();
 	}
@@ -2027,7 +1998,7 @@
 	#endif
 		set_top_mem_ap(sysinfo->tom_k, sysinfo->tom2_k); // keep the ap's tom consistent with bsp's
 	#if CONFIG_AP_CODE_IN_CAR == 0
-		print_debug("CODE IN ROM AND RUN ON NODE:"); print_debug_hex8(nodeid); print_debug("\r\n");
+		printk_debug("CODE IN ROM AND RUN ON NODE: %02x\n", nodeid);
 		train_ram(nodeid, sysinfo, sysinfox);
 	#else
 		/* Can copy dqs_timing to ap cache and run from cache?


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

-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: linuxbios_k8_raminit_printk_conversion.diff
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20090115/7213d30e/attachment.ksh>

From c-d.hailfinger.devel.2006 at gmx.net  Thu Jan 15 07:44:23 2009
From: c-d.hailfinger.devel.2006 at gmx.net (Carl-Daniel Hailfinger)
Date: Thu, 15 Jan 2009 07:44:23 +0100
Subject: [coreboot] wiki page for Asus M2A-VM
In-Reply-To: <495E34A9.1090201@gmx.net>
References: <49487459.7060209@gmx.net>	<49506040.5070805@gmx.net>	<4950ED85.60205@gmx.net>	<49583FD5.2010806@gmx.net>	<1230632371.4269.16.camel@mattotaupa.wohnung.familie-menzel.net>	<495A011C.9050208@gmx.net>	<1230636643.4269.19.camel@mattotaupa.wohnung.familie-menzel.net>	<20090102005827.11367.qmail@stuge.se>	<1230909896.4092.3.camel@mattotaupa.wohnung.familie-menzel.net>
	<495E34A9.1090201@gmx.net>
Message-ID: <496EDB47.30006@gmx.net>

On 02.01.2009 16:37, Carl-Daniel Hailfinger wrote:
> On 02.01.2009 16:24, Paul Menzel wrote:
>   
>> Am Freitag, den 02.01.2009, 01:58 +0100 schrieb Peter Stuge:
>>   
>>     
>>> Paul Menzel wrote:
>>>     
>>>       
>>>> Done [1]. If you have time could you please send me or update the
>>>> ROM chip package (PLCC, DIP32, DIP8, SOIC8)?
>>>>       
>>>>         
>>> The board has a soldered PLCC LPC flash chip.
>>>     
>>>       
>> Thanks, Peter. Done [1].
>>
>> Unfortunately the Wiki seems to be an older version, since the links in
>> the (change) comments are not formated correctly. At least it works in
>> Wikipedia I think. Also references would be supported directly.
>>
>> Now it is up to Carl-Daniel to announce the port on the main page.
>>   
>>     
>
> Thanks, I'll test with 4 GB RAM and some USB flash drives and report back.
>   

4 GB are a problem for dualchannel because my DIMMS are only compatible
and not identical. That's a missing feature in our code. I have sent a
cleanup patch which should make fixing that a bit easier.

Other status items were updated as well:

Fan control and sensors do not work yet because the GPIO and SIO
controls hang the machine during coreboot init if enabled via Config.lb.
Maybe direct PNP writes will fix that.

CPU frequency scaling works with the patch I sent a few hours ago.

Besides that, I think the board is in pretty good shape.

Regards,
Carl-Daniel

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




From Maggie.Li at amd.com  Thu Jan 15 07:42:21 2009
From: Maggie.Li at amd.com (Li, Maggie)
Date: Thu, 15 Jan 2009 14:42:21 +0800
Subject: [coreboot] AMD DBM690T PowerNow table problems
In-Reply-To: <496EBD11.8090301@gmx.net>
Message-ID: <DD1CC71B621B004FA76856E5129D6B17025579AB@sbjgexmb1.amd.com>

Hi

I have tested it on my DBM690T board. It is ok.

Best regards
Maggie li

-----Original Message-----
From: coreboot-bounces+maggie.li=amd.com at coreboot.org [mailto:coreboot-bounces+maggie.li=amd.com at coreboot.org] On Behalf Of Carl-Daniel Hailfinger
Sent: Thursday, January 15, 2009 12:35 PM
To: Marc Jones
Cc: Rudolf Marek; Bao, Zheng; Coreboot
Subject: Re: [coreboot] AMD DBM690T PowerNow table problems

On 09.01.2009 10:05, Carl-Daniel Hailfinger wrote:
> On 08.01.2009 17:52, Marc Jones wrote:
>   
>> On Wed, Jan 7, 2009 at 7:34 PM, Carl-Daniel Hailfinger
>> <c-d.hailfinger.devel.2006 at gmx.net> wrote:
>>
>>     
>>> The Linux kernel powernow-k8 driver doesn't complain anymore, but now
>>> the machine will lock up or reboot once I put some load on it.
>>> Blacklisting the powernow-k8 driver avoids the issue, but that makes
>>> frequency scaling impossible.    
>>>       
>> Can you dump the current tables or can you not get that far before a
>> crash? The entries are end points and the driver takes care of the
>> stepping that needs to be done to get to those points. We need to
>> check that the table generated the correct vid setting for the fid. It
>> is well described in the bkdg section 10.6.
>>     
>
> I managed to boot fine with the proprietary BIOS, blacklisted the
> k8-powernow driver and rebooted with coreboot.
>
> If I combine the _PSS from the proprietary BIOS with the other tables
> from coreboot, the machine does not crash. I'll try to narrow it down
> further.
>   

I finally found the bug.

The DBM90T code sets bit 10 in _PSS as part of the control value, but
bit 10 is part of NewVID. That means the resulting VID is wrong and
causes the processor to crash.
The Pistachio code has the same bug.

This patch fixes the wrong setting and changes control from a magic and
incorrect unexplained value (0xE8202C00) to a combination of explained
values and shifts which has the right value (0xE8202800).

It is tested on my machine and it survived 200 changes from minimum to
maximum frequency every 100 ms under heavy load and under no load.

In the long term we want to consolidate all AMD FIDVID code into one
generic library file.

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

--- src/mainboard/amd/pistachio/acpi_tables.c	(Revision 3850)
+++ src/mainboard/amd/pistachio/acpi_tables.c	(Arbeitskopie)
@@ -400,10 +400,10 @@
 		Pstate_num++;
 	}
 
-	/* Print Pstate feq,vid,volt,power */
+	/* Print Pstate freq,vid,volt,power */
 
 	for (index = 0; index < Pstate_num; index++) {
-		printk_info("Pstate_feq[%d] = %dMHz\t", index,
+		printk_info("Pstate_freq[%d] = %dMHz\t", index,
 			    Pstate_feq[index]);
 		printk_info("Pstate_vid[%d] = %d\t", index, Pstate_vid[index]);
 		printk_info("Pstate_volt[%d] = %dmv\t", index,
@@ -414,8 +414,11 @@
 
 	/*
 	 * Modify the DSDT Table to put the actural _PSS package
-	 * corefeq-->Pstate_feq[index] power-->Pstate_power[index] transitionlatency-->0x64 busmasterlatency-->0x7,
-	 * control-->0xE8202C00| Pstate_vid[index]<<6 | Pstate_fid[index]
+	 * corefeq-->Pstate_feq[index]
+	 * power-->Pstate_power[index]
+	 * transitionlatency-->0x64
+	 * busmasterlatency-->0x7,
+	 * control--> 0xE8202800| Pstate_vid[index]<<6 | Pstate_fid[index]
 	 * status --> Pstate_vid[index]<<6 | Pstate_fid[index]
 	 * Get the _PSS control method Sig.
 	 */
@@ -461,7 +464,13 @@
 				transitionlatency = 0x64;
 				busmasterlatency = 0x7;
 				control =
-				    0xE8202C00 | (Pstate_vid[index] << 6) |
+				    (0x3 << 30) | /* IRT */
+				    (0x2 << 28) | /* RVO */
+				    (0x1 << 27) | /* ExtType */
+				    (0x2 << 20) | /* PLL_LOCK_TIME */
+				    (0x0 << 18) | /* MVS */
+				    (0x5 << 11) | /* VST */
+				    (Pstate_vid[index] << 6) |
 				    Pstate_fid[index];
 				status =
 				    (Pstate_vid[index] << 6) |
--- src/mainboard/amd/dbm690t/acpi_tables.c	(Revision 3850)
+++ src/mainboard/amd/dbm690t/acpi_tables.c	(Arbeitskopie)
@@ -260,7 +260,7 @@
 
 	/* Get the multipier of the fid frequency */
 	/*
-	 * Fid multiplier is always 100 revF and revG.
+	 * Fid multiplier is always 100 revF and revG.
 	 */
 	fid_multiplier = 100;
 
@@ -400,10 +400,10 @@
 		Pstate_num++;
 	}
 
-	/* Print Pstate feq,vid,volt,power */
+	/* Print Pstate freq,vid,volt,power */
 
 	for (index = 0; index < Pstate_num; index++) {
-		printk_info("Pstate_feq[%d] = %dMHz\t", index,
+		printk_info("Pstate_freq[%d] = %dMHz\t", index,
 			    Pstate_feq[index]);
 		printk_info("Pstate_vid[%d] = %d\t", index, Pstate_vid[index]);
 		printk_info("Pstate_volt[%d] = %dmv\t", index,
@@ -414,8 +414,11 @@
 
 	/*
 	 * Modify the DSDT Table to put the actural _PSS package
-	 * corefeq-->Pstate_feq[index] power-->Pstate_power[index] transitionlatency-->0x64 busmasterlatency-->0x7,
-	 * control-->0xE8202C00| Pstate_vid[index]<<6 | Pstate_fid[index]
+	 * corefeq-->Pstate_feq[index]
+	 * power-->Pstate_power[index]
+	 * transitionlatency-->0x64
+	 * busmasterlatency-->0x7,
+	 * control--> 0xE8202800| Pstate_vid[index]<<6 | Pstate_fid[index]
 	 * status --> Pstate_vid[index]<<6 | Pstate_fid[index]
 	 * Get the _PSS control method Sig.
 	 */
@@ -461,7 +464,13 @@
 				transitionlatency = 0x64;
 				busmasterlatency = 0x7;
 				control =
-				    0xE8202C00 | (Pstate_vid[index] << 6) |
+				    (0x3 << 30) | /* IRT */
+				    (0x2 << 28) | /* RVO */
+				    (0x1 << 27) | /* ExtType */
+				    (0x2 << 20) | /* PLL_LOCK_TIME */
+				    (0x0 << 18) | /* MVS */
+				    (0x5 << 11) | /* VST */
+				    (Pstate_vid[index] << 6) |
 				    Pstate_fid[index];
 				status =
 				    (Pstate_vid[index] << 6) |


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


From paulepanter at users.sourceforge.net  Thu Jan 15 08:56:55 2009
From: paulepanter at users.sourceforge.net (Paul Menzel)
Date: Thu, 15 Jan 2009 08:56:55 +0100
Subject: [coreboot] Attachment missing (was: Re: [PATCH] fixes ram init	when
	processor doesn't have FID control)
In-Reply-To: <367509.59922.qm@web57003.mail.re3.yahoo.com>
References: <367509.59922.qm@web57003.mail.re3.yahoo.com>
Message-ID: <1232006215.6744.1.camel@mattotaupa.wohnung.familie-menzel.net>

Dear Dan,


these are great news. But there was no files attached at the messages I
received.


Thanks,

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

From stepan at coresystems.de  Thu Jan 15 10:04:03 2009
From: stepan at coresystems.de (Stefan Reinauer)
Date: Thu, 15 Jan 2009 10:04:03 +0100
Subject: [coreboot] [PATCH] factor SMM code into generic and specific
 code
In-Reply-To: <49594B5A.5010306@coresystems.de>
References: <49594B5A.5010306@coresystems.de>
Message-ID: <496EFC03.3040903@coresystems.de>

On 29.12.2008 23:12 Uhr, Stefan Reinauer wrote:
> See patch...
>
> --
> coreboot mailing list: coreboot at coreboot.org
> http://www.coreboot.org/mailman/listinfo/coreboot

If nobody cares to review, I'll gladly assume this is a trivial 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: coreboot-v2-generic-smm.diff
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20090115/d23df5c3/attachment.ksh>

From svn at coreboot.org  Thu Jan 15 10:56:21 2009
From: svn at coreboot.org (coreboot)
Date: Thu, 15 Jan 2009 09:56:21 -0000
Subject: [coreboot] #120: flashrom failure to read
In-Reply-To: <053.0bcc838ee0a3c5de1df320df034ed573@coreboot.org>
References: <053.0bcc838ee0a3c5de1df320df034ed573@coreboot.org>
Message-ID: <062.6bd281c145185c1702245dc7cfa1d3dc@coreboot.org>

#120: flashrom failure to read
----------------------------------+-----------------------------------------
   Reporter:  toc@?               |          Owner:  stuge   
       Type:  defect              |         Status:  assigned
   Priority:  major               |      Milestone:          
  Component:  flashrom            |        Version:          
   Keywords:  ich9                |   Dependencies:          
Patchstatus:  patch needs review  |  
----------------------------------+-----------------------------------------

Comment(by fengyuning1984@?):

 Please also try [http://tracker.coreboot.org/trac/coreboot/raw-
 attachment/ticket/120/fr.ich9prg_ops_fail.patch fr.ich9prg_ops_fail.patch]
 without fr.ich9lock2-s.patch applied, and post the verbose output.

 Thanks!

-- 
Ticket URL: <http://tracker.coreboot.org/trac/coreboot/ticket/120#comment:4>
coreboot <http://www.coreboot.org/>


From joe at settoplinux.org  Thu Jan 15 12:58:18 2009
From: joe at settoplinux.org (Joseph Smith)
Date: Thu, 15 Jan 2009 06:58:18 -0500
Subject: [coreboot] [PATCH] factor SMM code into generic and specific
	code
In-Reply-To: <496EFC03.3040903@coresystems.de>
References: <49594B5A.5010306@coresystems.de> <496EFC03.3040903@coresystems.de>
Message-ID: <5d35046a063e171c2b05471c73de9926@imap.1and1.com>




On Thu, 15 Jan 2009 10:04:03 +0100, Stefan Reinauer <stepan at coresystems.de>
wrote:
> On 29.12.2008 23:12 Uhr, Stefan Reinauer wrote:
>> See patch...
>>
>> --
>> coreboot mailing list: coreboot at coreboot.org
>> http://www.coreboot.org/mailman/listinfo/coreboot
> 
> If nobody cares to review, I'll gladly assume this is a trivial patch ;-)
> 
Looks good. Have to tested it yet?
If so, Acked-by: Joseph Smith <joe at settoplinux.org>

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




From mylesgw at gmail.com  Thu Jan 15 15:22:47 2009
From: mylesgw at gmail.com (Myles Watson)
Date: Thu, 15 Jan 2009 07:22:47 -0700
Subject: [coreboot] [PATCH] Convert print_* to printk_* in K8 RAM init
In-Reply-To: <496ED85E.6020202@gmx.net>
References: <496ED85E.6020202@gmx.net>
Message-ID: <26DC33D0A05A450BA49A6E65850DE5A9@chimp>



> -----Original Message-----
> From: coreboot-bounces at coreboot.org [mailto:coreboot-bounces at coreboot.org]
> On Behalf Of Carl-Daniel Hailfinger
> Sent: Wednesday, January 14, 2009 11:32 PM
> To: Coreboot
> Subject: [coreboot] [PATCH] Convert print_* to printk_* in K8 RAM init
> 
> Since all K8 targets now have CONFIG_USE_PRINTK_IN_CAR enabled, using
> print_* in K8 RAM init does not make sense anymore. Convert almost all
> print_* to printk_*.
> This improves readability a lot and makes the code shorter.
> 
> Add a warning about false negatives in the DIMM dual channel
> compatibility check. This needs to be implemented correctly.
> 
> Fix a few typos.
> 
> Signed-off-by: Carl-Daniel Hailfinger <c-d.hailfinger.devel.2006 at gmx.net>
> 
> Index: LinuxBIOSv2-asus_m2a-vm/src/northbridge/amd/amdk8/raminit_f.c
> ===================================================================
> --- LinuxBIOSv2-asus_m2a-vm/src/northbridge/amd/amdk8/raminit_f.c
> 	(Revision 3850)
> +++ LinuxBIOSv2-asus_m2a-vm/src/northbridge/amd/amdk8/raminit_f.c
> 	(Arbeitskopie)
> @@ -34,34 +34,20 @@
>  #define QRANK_DIMM_SUPPORT 0
>  #endif
> 
> -static inline void print_raminit(const char *strval, uint32_t val)
> -{
>  #if CONFIG_USE_PRINTK_IN_CAR
> -	printk_debug("%s%08x\r\n", strval, val);
>  #else
> -	print_debug(strval); print_debug_hex32(val); print_debug("\r\n");
> +#error This file needs CONFIG_USE_PRINTK_IN_CAR
>  #endif
> -}
> 
> -#define RAM_TIMING_DEBUG 0
> +#define RAM_TIMING_DEBUG 1

Do we really want to always debug RAM timing?

> -static inline void print_tx(const char *strval, uint32_t val)
> -{
>  #if RAM_TIMING_DEBUG == 1
> -	print_raminit(strval, val);
> +#define printk_raminit printk_debug
> +#else
> +#define printk_raminit(fmt, arg...)   do {} while(0)

Why is the do{} while (0) needed here?

>  		4,	/* *Column addresses */
>  		5,	/* *Number of DIMM Ranks */
>  		6,	/* *Module Data Width*/
> -		9,	/* *Cycle time at highest CAS Latency CL=X */
>  		11,	/* *DIMM Conf Type */
>  		13,	/* *Pri SDRAM Width */
>  		17,	/* *Logical Banks */
> -		18,	/* *Supported CAS Latencies */
>  		20,	/* *DIMM Type Info */
>  		21,	/* *SDRAM Module Attributes */
> -		23,	/* *Cycle time at CAS Latnecy (CLX - 1) */
> -		26,	/* *Cycle time at CAS Latnecy (CLX - 2) */
>  		27,	/* *tRP Row precharge time */
>  		28,	/* *Minimum Row Active to Row Active Delay (tRRD) */
>  		29,	/* *tRCD RAS to CAS */
> @@ -1464,11 +1440,18 @@
>  		36,	/* *Write recovery time (tWR) */
>  		37,	/* *Internal write to read command delay (tRDP) */
>  		38,	/* *Internal read to precharge commanfd delay (tRTP)
*/
> +#warning Why is SPD address 41 checked twice?
>  		41,	/* *Extension of Byte 41 tRC and Byte 42 tRFC */
>  		41,	/* *Minimum Active to Active/Auto Refresh Time(Trc)
*/
>  		42,	/* *Minimum Auto Refresh Command Time(Trfc) */
> +#warning The SPD addresses below need special treatment like in
> spd_set_memclk. Right now they cause many false negatives.
> +		18,	/* *Supported CAS Latencies */
> +		9,	/* *Cycle time at highest CAS Latency CL=X */
> +		23,	/* *Cycle time at CAS Latency (CLX - 1) */
> +		26,	/* *Cycle time at CAS Latency (CLX - 2) */

I guess I'd rather leave them in order and add their numbers to the warning
message.

>  	};
>  	u32 dcl, dcm;
> +	u8 common_cl;
> 
>  /* S1G1 and AM2 sockets are Mod64BitMux capable. */
>  #if CPU_SOCKET_TYPE == 0x11 || CPU_SOCKET_TYPE == 0x12
> @@ -1497,6 +1480,14 @@
>  		}
>  		device0 = ctrl->channel0[i];
>  		device1 = ctrl->channel1[i];
> +		/* Abort if the chips don't support a common CAS latency. */
> +		common_cl = spd_read_byte(device0, 18) &
> spd_read_byte(device1, 18);
> +		if (!common_cl) {
> +			printk_debug("No common CAS latency supported\n");
> +			goto single_channel;
> +		} else {
> +			printk_raminit("Common CAS latency bitfield:
0x%02x\n",
> common_cl);
> +		}

I didn't see this part in the summary of the patch.


>  	if (!param->cycle_time) {
>  		die("min_cycle_time to low");
>  	}
> -	print_spew(param->name);
>  #ifdef DRAM_MIN_CYCLE_TIME
> -	print_debug(param->name);
> +	printk_debug(param->name);

It seems like you could get rid of this ifdef and just make it printk_debug
or printk_raminit.

Thanks,
Myles




From rminnich at gmail.com  Thu Jan 15 15:27:40 2009
From: rminnich at gmail.com (ron minnich)
Date: Thu, 15 Jan 2009 06:27:40 -0800
Subject: [coreboot] patch: atomic.h
Message-ID: <13426df10901150627s67e5473bi47a6c35216b8a274@mail.gmail.com>

attached.

ron
-------------- next part --------------
A non-text attachment was scrubbed...
Name: atomic.diff
Type: text/x-patch
Size: 2132 bytes
Desc: not available
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20090115/54f68176/attachment.diff>

From svn at coreboot.org  Thu Jan 15 15:49:21 2009
From: svn at coreboot.org (coreboot)
Date: Thu, 15 Jan 2009 14:49:21 -0000
Subject: [coreboot] #120: flashrom failure to read
In-Reply-To: <053.0bcc838ee0a3c5de1df320df034ed573@coreboot.org>
References: <053.0bcc838ee0a3c5de1df320df034ed573@coreboot.org>
Message-ID: <062.3832fed81629d9fabc1e380940f0449e@coreboot.org>

#120: flashrom failure to read
----------------------------------+-----------------------------------------
   Reporter:  toc@?               |          Owner:  stuge   
       Type:  defect              |         Status:  assigned
   Priority:  major               |      Milestone:          
  Component:  flashrom            |        Version:          
   Keywords:  ich9                |   Dependencies:          
Patchstatus:  patch needs review  |  
----------------------------------+-----------------------------------------

Comment(by toc@?):

 Replying to [comment:3 stuge]:
 > Ok, the patch worked, but there is some other problem. I just committed
 a small change that adds useful debugging in r3862. Please update and
 resend output from running with -V.

 {{{
 Calibrating delay loop... 663M loops per second, 100 myus = 200 us. OK.
 No coreboot table found.
 Found chipset "Intel ICH9R", enabling flash write...
 BIOS Lock Enable: enabled, BIOS Write Enable: disabled, BIOS_CNTL is 0x2
 tried to set 0xdc to 0x3 on Intel ICH9R failed (WARNING ONLY)

 Root Complex Register Block address = 0xfeda8000
 GCS = 0x410460: BIOS Interface Lock-Down: disabled, BOOT BIOS Straps: 0x1
 (SPI)
 Top Swap : not enabled
 SPIBAR = 0xfeda8000 + 0x3800
 0x00: 0x1fff (HSFS)
 FLOCKDN 0, FDV 0, FDOPSS 0, SCIP 1, BERASE 3, AEL 1, FCERR 1, FDONE 1
 0x50: 0x0000ffff (FRAP)
 BMWAG 0, BMRAG 0, BRWA 255, BRRA 255
 0x54: 0x00001fff (FREG0)
 0x58: 0x00001fff (FREG1)
 0x5C: 0x00001fff (FREG2)
 0x60: 0x00001fff (FREG3)
 0x64: 0x00001fff (FREG4)
 0x74: 0x00000000 (PR0)
 0x78: 0x00000000 (PR1)
 0x7C: 0x00000000 (PR2)
 0x80: 0x00000000 (PR3)
 0x84: 0x00000000 (PR4)
 0xB0: 0x00000000 (FDOC)
 Programming OPCODES...
 program_opcodes: preop=0006 optype=463b opmenu=05d80302c79f01ab
 done
 SPI Read Configuration: prefetching disabled, caching enabled, FAILED!
 <<<snip>>>>
 probe_spi_rdid_generic: id1 0xc2, id2 0x2014
 Chip status register is 00
 Chip status register: Status Register Write Disable (SRWD) is not set
 Chip status register: Bit 6 is not set
 Chip status register: Bit 5 / Block Protect 3 (BP3) is not set
 Chip status register: Bit 4 / Block Protect 2 (BP2) is not set
 Chip status register: Bit 3 / Block Protect 1 (BP1) is not set
 Chip status register: Bit 2 / Block Protect 0 (BP0) is not set
 Chip status register: Write Enable Latch (WEL) is not set
 Chip status register: Write In Progress (WIP/BUSY) is not set
 Found chip "Macronix MX25L8005" (1024 KB) at physical address 0xfff00000.
 <<<<snip>>>>>
 Reading flash... ich_spi_read_page: offset=0, number=256, buf=0xb7cdd008
 Opcode 3 not found.
 run OPCODE 0x03 failed
 Error readingdone.
 }}}}

-- 
Ticket URL: <http://tracker.coreboot.org/trac/coreboot/ticket/120#comment:5>
coreboot <http://www.coreboot.org/>


From svn at coreboot.org  Thu Jan 15 16:05:56 2009
From: svn at coreboot.org (coreboot)
Date: Thu, 15 Jan 2009 15:05:56 -0000
Subject: [coreboot] #120: flashrom failure to read
In-Reply-To: <053.0bcc838ee0a3c5de1df320df034ed573@coreboot.org>
References: <053.0bcc838ee0a3c5de1df320df034ed573@coreboot.org>
Message-ID: <062.40013e1bc5426bcf96d5f23e61f9e839@coreboot.org>

#120: flashrom failure to read
----------------------------------+-----------------------------------------
   Reporter:  toc@?               |          Owner:  stuge   
       Type:  defect              |         Status:  assigned
   Priority:  major               |      Milestone:          
  Component:  flashrom            |        Version:          
   Keywords:  ich9                |   Dependencies:          
Patchstatus:  patch needs review  |  
----------------------------------+-----------------------------------------

Comment(by toc@?):

 Replying to [comment:4 fengyuning1984@?]:
 > Please also try [http://tracker.coreboot.org/trac/coreboot/raw-
 attachment/ticket/120/fr.ich9prg_ops_fail.patch fr.ich9prg_ops_fail.patch]
 without fr.ich9lock2-s.patch applied, and post the verbose output.
 >
 > Thanks!

 I will be attaching verbose output from r3862+fr.ich9pro_ops_fail.patch
 and r3862+fr.ich9prg_ops_fail.patch+fr.ich9lock2-s.patch.

-- 
Ticket URL: <http://tracker.coreboot.org/trac/coreboot/ticket/120#comment:6>
coreboot <http://www.coreboot.org/>


From c-d.hailfinger.devel.2006 at gmx.net  Thu Jan 15 16:47:32 2009
From: c-d.hailfinger.devel.2006 at gmx.net (Carl-Daniel Hailfinger)
Date: Thu, 15 Jan 2009 16:47:32 +0100
Subject: [coreboot] [PATCH] Convert print_* to printk_* in K8 RAM init
In-Reply-To: <26DC33D0A05A450BA49A6E65850DE5A9@chimp>
References: <496ED85E.6020202@gmx.net> <26DC33D0A05A450BA49A6E65850DE5A9@chimp>
Message-ID: <496F5A94.8050901@gmx.net>

On 15.01.2009 15:22, Myles Watson wrote:
>   
>> -----Original Message-----
>> From: coreboot-bounces at coreboot.org [mailto:coreboot-bounces at coreboot.org]
>> On Behalf Of Carl-Daniel Hailfinger
>> Sent: Wednesday, January 14, 2009 11:32 PM
>> To: Coreboot
>> Subject: [coreboot] [PATCH] Convert print_* to printk_* in K8 RAM init
>>
>> Since all K8 targets now have CONFIG_USE_PRINTK_IN_CAR enabled, using
>> print_* in K8 RAM init does not make sense anymore. Convert almost all
>> print_* to printk_*.
>> This improves readability a lot and makes the code shorter.
>>
>> Add a warning about false negatives in the DIMM dual channel
>> compatibility check. This needs to be implemented correctly.
>>
>> Fix a few typos.
>>
>> Signed-off-by: Carl-Daniel Hailfinger <c-d.hailfinger.devel.2006 at gmx.net>
>>
>> Index: LinuxBIOSv2-asus_m2a-vm/src/northbridge/amd/amdk8/raminit_f.c
>> ===================================================================
>> --- LinuxBIOSv2-asus_m2a-vm/src/northbridge/amd/amdk8/raminit_f.c
>> 	(Revision 3850)
>> +++ LinuxBIOSv2-asus_m2a-vm/src/northbridge/amd/amdk8/raminit_f.c
>> 	(Arbeitskopie)
>> @@ -34,34 +34,20 @@
>>  #define QRANK_DIMM_SUPPORT 0
>>  #endif
>>
>> -static inline void print_raminit(const char *strval, uint32_t val)
>> -{
>>  #if CONFIG_USE_PRINTK_IN_CAR
>> -	printk_debug("%s%08x\r\n", strval, val);
>>  #else
>> -	print_debug(strval); print_debug_hex32(val); print_debug("\r\n");
>> +#error This file needs CONFIG_USE_PRINTK_IN_CAR
>>  #endif
>> -}
>>
>> -#define RAM_TIMING_DEBUG 0
>> +#define RAM_TIMING_DEBUG 1
>>     
>
> Do we really want to always debug RAM timing?
>   

No. This is a local change that crept in. Thanks for noticing. I'll drop it.


>> -static inline void print_tx(const char *strval, uint32_t val)
>> -{
>>  #if RAM_TIMING_DEBUG == 1
>> -	print_raminit(strval, val);
>> +#define printk_raminit printk_debug
>> +#else
>> +#define printk_raminit(fmt, arg...)   do {} while(0)
>>     
>
> Why is the do{} while (0) needed here?
>   

I was going to point to http://kernelnewbies.org/FAQ/DoWhile0 but that
does not apply to empty statements. I blame having coded this at 4am.
Will drop.


>>  		4,	/* *Column addresses */
>>  		5,	/* *Number of DIMM Ranks */
>>  		6,	/* *Module Data Width*/
>> -		9,	/* *Cycle time at highest CAS Latency CL=X */
>>  		11,	/* *DIMM Conf Type */
>>  		13,	/* *Pri SDRAM Width */
>>  		17,	/* *Logical Banks */
>> -		18,	/* *Supported CAS Latencies */
>>  		20,	/* *DIMM Type Info */
>>  		21,	/* *SDRAM Module Attributes */
>> -		23,	/* *Cycle time at CAS Latnecy (CLX - 1) */
>> -		26,	/* *Cycle time at CAS Latnecy (CLX - 2) */
>>  		27,	/* *tRP Row precharge time */
>>  		28,	/* *Minimum Row Active to Row Active Delay (tRRD) */
>>  		29,	/* *tRCD RAS to CAS */
>> @@ -1464,11 +1440,18 @@
>>  		36,	/* *Write recovery time (tWR) */
>>  		37,	/* *Internal write to read command delay (tRDP) */
>>  		38,	/* *Internal read to precharge commanfd delay (tRTP) */
>> +#warning Why is SPD address 41 checked twice?
>>  		41,	/* *Extension of Byte 41 tRC and Byte 42 tRFC */
>>  		41,	/* *Minimum Active to Active/Auto Refresh Time(Trc) */
>>  		42,	/* *Minimum Auto Refresh Command Time(Trfc) */
>> +#warning The SPD addresses below need special treatment like in
>> spd_set_memclk. Right now they cause many false negatives.
>> +		18,	/* *Supported CAS Latencies */
>> +		9,	/* *Cycle time at highest CAS Latency CL=X */
>> +		23,	/* *Cycle time at CAS Latency (CLX - 1) */
>> +		26,	/* *Cycle time at CAS Latency (CLX - 2) */
>>     
>
> I guess I'd rather leave them in order and add their numbers to the warning
> message.
>   

I want to remove them altogether because they can't be treated specially
in that array. That reordering is there to make sure that we know if any
other mismatches are present in the DIMM. So in a way the new order
helps debugging with the old code. I'm not feeling strongly about this,
though.


>>  	};
>>  	u32 dcl, dcm;
>> +	u8 common_cl;
>>
>>  /* S1G1 and AM2 sockets are Mod64BitMux capable. */
>>  #if CPU_SOCKET_TYPE == 0x11 || CPU_SOCKET_TYPE == 0x12
>> @@ -1497,6 +1480,14 @@
>>  		}
>>  		device0 = ctrl->channel0[i];
>>  		device1 = ctrl->channel1[i];
>> +		/* Abort if the chips don't support a common CAS latency. */
>> +		common_cl = spd_read_byte(device0, 18) &
>> spd_read_byte(device1, 18);
>> +		if (!common_cl) {
>> +			printk_debug("No common CAS latency supported\n");
>> +			goto single_channel;
>> +		} else {
>> +			printk_raminit("Common CAS latency bitfield:
>>     
> 0x%02x\n",
>   
>> common_cl);
>> +		}
>>     
>
> I didn't see this part in the summary of the patch.
>   

I'll add the following sentence to the summary:
"Check for dual channel CAS latency compatibility."


>>  	if (!param->cycle_time) {
>>  		die("min_cycle_time to low");
>>  	}
>> -	print_spew(param->name);
>>  #ifdef DRAM_MIN_CYCLE_TIME
>> -	print_debug(param->name);
>> +	printk_debug(param->name);
>>     
>
> It seems like you could get rid of this ifdef and just make it printk_debug
> or printk_raminit.
>   

I'll probably make it printk_debug.

Thanks for the review.
Any other comments before I repost?


Regards,
Carl-Daniel

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




From yulrottmann at bitel.net  Thu Jan 15 16:50:46 2009
From: yulrottmann at bitel.net (Yul Rottmann)
Date: Thu, 15 Jan 2009 16:50:46 +0100
Subject: [coreboot] EHCI debug port finder
In-Reply-To: <20090115013235.10266.qmail@stuge.se>
References: <496E543B.5070901@bitel.net> <20090115013235.10266.qmail@stuge.se>
Message-ID: <496F5B56.5060807@bitel.net>

Peter Stuge wrote:
> Run lspci -h and look under "Selection of devices" - it should work.
> But the sh fu may be broken by now.
I tested again and it's just that the complete line does not work. I
just copied and pasted this into a shell, and it did not work, unsure if
this was the right way. If I insert the output of the one command by
hand, it works as expected. Maybe this command line could be improved.
Just for the case you still need the output, it is attached.

> It's interesting that you have two EHCI devices with a debug port
> each. I don't know what coreboot does in this case. Not much to do
> since you can't test, but you could look around at the port registers
> to see if you can locate if the debug port(s!) actually go(es)
> anywhere on the board.
I don't know how to find out, whether those debug ports go anywhere on
the board. If it is easy, could you help me with that?
Thanks!

	Yul Rottmann

-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: output(2).txt
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20090115/12687cd5/attachment.txt>

From svn at coreboot.org  Thu Jan 15 17:00:02 2009
From: svn at coreboot.org (coreboot tracker)
Date: Thu, 15 Jan 2009 17:00:02 +0100
Subject: [coreboot] Trac reminder: list of new ticket(s)
Message-ID: <E1LNUdW-0002ri-OD@ra.coresystems.de>

An HTML attachment was scrubbed...
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20090115/0f53016d/attachment.html>

From patrick at georgi-clan.de  Thu Jan 15 17:15:00 2009
From: patrick at georgi-clan.de (Patrick Georgi)
Date: Thu, 15 Jan 2009 17:15:00 +0100
Subject: [coreboot] patch: atomic.h
In-Reply-To: <13426df10901150627s67e5473bi47a6c35216b8a274@mail.gmail.com>
References: <13426df10901150627s67e5473bi47a6c35216b8a274@mail.gmail.com>
Message-ID: <496F6104.60903@georgi-clan.de>

ron minnich schrieb:
> attached.
>
> ron
Right from Linux. I am not comfortable inserting our headers in linux files.

Signed-off-by: Ronald G. Minnich <rminnich at gmail.com>
Acked-by: Patrick Georgi <patrick.georgi at coresystems.de>




From c-d.hailfinger.devel.2006 at gmx.net  Thu Jan 15 17:24:24 2009
From: c-d.hailfinger.devel.2006 at gmx.net (Carl-Daniel Hailfinger)
Date: Thu, 15 Jan 2009 17:24:24 +0100
Subject: [coreboot] patch: atomic.h
In-Reply-To: <496F6104.60903@georgi-clan.de>
References: <13426df10901150627s67e5473bi47a6c35216b8a274@mail.gmail.com>
	<496F6104.60903@georgi-clan.de>
Message-ID: <496F6338.3040302@gmx.net>

On 15.01.2009 17:15, Patrick Georgi wrote:
> ron minnich schrieb:
>> attached.
>>
>> ron
> Right from Linux. I am not comfortable inserting our headers in linux
> files.

Can you add a header that it comes from Linux 2.6.something? That way,
you give credit and avoid any licensing questions.

> Signed-off-by: Ronald G. Minnich <rminnich at gmail.com>
> Acked-by: Patrick Georgi <patrick.georgi at coresystems.de>

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

Regards,
Carl-Daniel

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




From svn at coreboot.org  Thu Jan 15 17:56:44 2009
From: svn at coreboot.org (svn at coreboot.org)
Date: Thu, 15 Jan 2009 17:56:44 +0100
Subject: [coreboot] r1116 - coreboot-v3/include/arch/x86/arch
Message-ID: <mailman.2672.1355071470.16123.coreboot@coreboot.org>

Author: rminnich
Date: 2009-01-15 17:56:44 +0100 (Thu, 15 Jan 2009)
New Revision: 1116

Added:
   coreboot-v3/include/arch/x86/arch/atomic.h
Log:
Right from Linux. I am not comfortable inserting our headers in linux files.

Signed-off-by: Ronald G. Minnich <rminnich at gmail.com>
Acked-by: Patrick Georgi <patrick.georgi at coresystems.de>



Added: coreboot-v3/include/arch/x86/arch/atomic.h
===================================================================
--- coreboot-v3/include/arch/x86/arch/atomic.h	                        (rev 0)
+++ coreboot-v3/include/arch/x86/arch/atomic.h	2009-01-15 16:56:44 UTC (rev 1116)
@@ -0,0 +1,70 @@
+/* this implementation is from Linux. */
+#ifndef ARCH_ATOMIC_H
+#define ARCH_ATOMIC_H
+
+/*
+ * Make sure gcc doesn't try to be clever and move things around
+ * on us. We need to use _exactly_ the address the user gave us,
+ * not some alias that contains the same information.
+ */
+struct atomic { volatile int counter; };
+
+#define ATOMIC_INIT(i)	{ (i) }
+
+/*
+ * Atomic operations that C can't guarantee us.  Useful for
+ * resource counting etc..
+ */
+
+/**
+ * atomic_read - read atomic variable
+ * @v: pointer of type struct atomic
+ * 
+ * Atomically reads the value of @v.  Note that the guaranteed
+ * useful range of an struct atomic is only 24 bits.
+ */ 
+#define atomic_read(v)		((v)->counter)
+
+/**
+ * atomic_set - set atomic variable
+ * @v: pointer of type struct atomic
+ * @i: required value
+ * 
+ * Atomically sets the value of @v to @i.  Note that the guaranteed
+ * useful range of an struct atomic is only 24 bits.
+ */ 
+