coreboot October 2010

coreboot@coreboot.org

55 participants
316 discussions

Re: [coreboot] coreboot Digest, Vol 68, Issue 108
by Mark Beihoffer 20 Oct '10

20 Oct '10

I tried that and it worked! Thants! Mark Beihoffer Dragonfly Networks mbeihoffer(a)gmail.com mark(a)dragonfly-networks.com (612)508-5128 On Tue, Oct 19, 2010 at 2:03 PM, <coreboot-request(a)coreboot.org> wrote: > Send coreboot mailing list submissions to > coreboot(a)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(a)coreboot.org > > You can reach the person managing the list at > coreboot-owner(a)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: [PATCH] AMD F10h: set MMCONF bus count according > toconfigured value (Scott Duplichan) > 2. Re: [PATCH] AMD F10h: set MMCONF bus count > accordingtoconfigured value (Myles Watson) > 3. Re: [PATCH] AMD F10h: set MMCONF bus count according > toconfigured value (Carl-Daniel Hailfinger) > 4. Re: [PATCH] AMD F10h: set MMCONF bus count according > toconfigured value (Scott Duplichan) > 5. Re: [PATCH] AMD F10h: set MMCONF bus count according > toconfigured value (Myles Watson) > 6. Re: [PATCH] AMD F10h: set MMCONF bus count according > toconfigured value (Scott Duplichan) > 7. Re: [PATCH] AMD F10h: set MMCONF bus count according > toconfigured value (Myles Watson) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Tue, 19 Oct 2010 12:47:08 -0500 > From: "Scott Duplichan" <scott(a)notabs.org> > To: "'Arne Georg Gleditsch'" <arne.gleditsch(a)numascale.com> > Cc: 'Coreboot' <coreboot(a)coreboot.org> > Subject: Re: [coreboot] [PATCH] AMD F10h: set MMCONF bus count > according toconfigured value > Message-ID: <51AC17B3FD284FE6BA8547D65AC3C0C5@m3a78> > Content-Type: text/plain; charset="us-ascii" > > -----Original Message----- > From: coreboot-bounces(a)coreboot.org [mailto:coreboot-bounces@coreboot.org] > On Behalf Of Arne Georg Gleditsch > Sent: Tuesday, October 19, 2010 01:51 AM > To: Scott Duplichan > Cc: 'Coreboot' > Subject: Re: [coreboot] [PATCH] AMD F10h: set MMCONF bus count according > toconfigured value > > ]"Scott Duplichan" <scott(a)notabs.org> writes: > ] > ]> For AMD family 10h processors, msr c0010058 is always programmed > ]> for 256 buses, even if fewer are configured. This patch lets msr > ]> c0010058 programming use the configured bus count, > CONFIG_MMCONF_BUS_NUMBER. > ] > ]How about just renaming CONFIG_MMCONF_BUS_NUMBER to ...BUS_BITS? > ]There's only 8 discrete values it can take anyway, and this would also > ]make it harder to pick an unsupported value for BUS_NUMBER. > ] > ]-- > ] Arne. > > Hello Arne, > > Thanks for the suggestion. It would certainly eliminate the awkward > logic. On the other hand, if anyone is overriding the kconfig > value CONFIG_MMCONF_BUS_NUMBER locally, they would have to update > their override. > > Last night, I thought I would just learn about gas macros and do it > that way. It was more difficult than I thought. I cannot even find > examples of gas macros that use arguments. A C style macro seemed > possible, but I found when gas processes it the needed ?: does not > work. So I ended up with a gas macro that does not use arguments. > The macro allows the awkwark logic and additional error checking to > be placed in an existing include file. The new error checking was > tested by forcing a few failing cases: > > > Signed-off-by: Scott Duplichan <scott(a)notabs.org> > > Index: src/include/cpu/amd/mtrr.h > =================================================================== > --- src/include/cpu/amd/mtrr.h (revision 5975) > +++ src/include/cpu/amd/mtrr.h (working copy) > @@ -32,6 +32,44 @@ > #define TOP_MEM_MASK 0x007fffff > #define TOP_MEM_MASK_KB (TOP_MEM_MASK >> 10) > > + > +#if defined(ASSEMBLY) > + > +.macro SET_C0010058 > + #if (CONFIG_MMCONF_BASE_ADDRESS > 0xFFFFFFFF) > + #error MMCONF_BASE_ADDRESS too big > + #elif (CONFIG_MMCONF_BASE_ADDRESS & 0xFFFFF) > + #error MMCONF_BASE_ADDRESS not 1MB aligned > + #endif > + movl $0, %edx > + movl $((CONFIG_MMCONF_BASE_ADDRESS) | (1 << 0)), %eax > + #if (CONFIG_MMCONF_BUS_NUMBER == 1) > + #elif (CONFIG_MMCONF_BUS_NUMBER == 2) > + orl $(1 << 2), %eax > + #elif (CONFIG_MMCONF_BUS_NUMBER == 4) > + orl $(2 << 2), %eax > + #elif (CONFIG_MMCONF_BUS_NUMBER == 8) > + orl $(3 << 2), %eax > + #elif (CONFIG_MMCONF_BUS_NUMBER == 16) > + orl $(4 << 2), %eax > + #elif (CONFIG_MMCONF_BUS_NUMBER == 32) > + orl $(5 << 2), %eax > + #elif (CONFIG_MMCONF_BUS_NUMBER == 64) > + orl $(6 << 2), %eax > + #elif (CONFIG_MMCONF_BUS_NUMBER == 128) > + orl $(7 << 2), %eax > + #elif (CONFIG_MMCONF_BUS_NUMBER == 256) > + orl $(8 << 2), %eax > + #else > + #error "bad MMCONF_BUS_NUMBER value" > + #endif > + movl $(0xc0010058), %ecx > + wrmsr > +.endm > + > +#endif > + > + > #if !defined(__PRE_RAM__) && !defined(ASSEMBLY) > void amd_setup_mtrrs(void); > #endif > Index: src/cpu/amd/car/cache_as_ram.inc > =================================================================== > --- src/cpu/amd/car/cache_as_ram.inc (revision 5975) > +++ src/cpu/amd/car/cache_as_ram.inc (working copy) > @@ -132,15 +132,7 @@ > wrmsr > > #if CONFIG_MMCONF_SUPPORT > - /* Set MMIO config space BAR. */ > - movl $MSR_MCFG_BASE, %ecx > - rdmsr > - andl $(~(0xfff00000 | (0xf << 2))), %eax > - orl $((CONFIG_MMCONF_BASE_ADDRESS & 0xfff00000)), %eax > - orl $((8 << 2) | (1 << 0)), %eax > - andl $(~(0x0000ffff)), %edx > - orl $(CONFIG_MMCONF_BASE_ADDRESS >> 32), %edx > - wrmsr > + SET_C0010058 > #endif > > CAR_FAM10_out_post_errata: > > > > > > ------------------------------ > > Message: 2 > Date: Tue, 19 Oct 2010 12:05:48 -0600 > From: "Myles Watson" <mylesgw(a)gmail.com> > To: "'Scott Duplichan'" <scott(a)notabs.org>, "'Arne Georg Gleditsch'" > <arne.gleditsch(a)numascale.com> > Cc: 'Coreboot' <coreboot(a)coreboot.org> > Subject: Re: [coreboot] [PATCH] AMD F10h: set MMCONF bus count > accordingtoconfigured value > Message-ID: <7ABE7F9D18144867B79B98A8C6407C8A@chimp> > Content-Type: text/plain; charset="us-ascii" > > > Last night, I thought I would just learn about gas macros and do it > > that way. It was more difficult than I thought. I cannot even find > > examples of gas macros that use arguments. A C style macro seemed > > possible, but I found when gas processes it the needed ?: does not > > work. So I ended up with a gas macro that does not use arguments. > > The macro allows the awkwark logic and additional error checking to > > be placed in an existing include file. The new error checking was > > tested by forcing a few failing cases: > > > > > > Signed-off-by: Scott Duplichan <scott(a)notabs.org> > I'm sorry that I wasn't more clear. I think it was better before. The > code > looks exactly the same, but it's in a different file, which wasn't my > intent > at all. > > I like the other version much better. I hope that your new knowledge of > gas > macros will come in handy in the future :) > > Thanks, > Myles > > > > > ------------------------------ > > Message: 3 > Date: Tue, 19 Oct 2010 20:24:38 +0200 > From: Carl-Daniel Hailfinger <c-d.hailfinger.devel.2006(a)gmx.net> > To: Scott Duplichan <scott(a)notabs.org> > Cc: 'Arne Georg Gleditsch' <arne.gleditsch(a)numascale.com>, 'Coreboot' > <coreboot(a)coreboot.org> > Subject: Re: [coreboot] [PATCH] AMD F10h: set MMCONF bus count > according toconfigured value > Message-ID: <4CBDE266.2050604(a)gmx.net> > Content-Type: text/plain; charset=ISO-8859-1 > > Hi Scott, > > On 19.10.2010 19:47, Scott Duplichan wrote: > > Last night, I thought I would just learn about gas macros and do it > > that way. It was more difficult than I thought. I cannot even find > > examples of gas macros that use arguments. > > Take a look at src/cpu/amd/car/cache_as_ram.inc, specifically > extractmask and simplemask. > > Regards, > Carl-Daniel > > -- > http://www.hailfinger.org/ > > > > > ------------------------------ > > Message: 4 > Date: Tue, 19 Oct 2010 13:34:20 -0500 > From: "Scott Duplichan" <scott(a)notabs.org> > To: "'Carl-Daniel Hailfinger'" <c-d.hailfinger.devel.2006(a)gmx.net> > Cc: 'Arne Georg Gleditsch' <arne.gleditsch(a)numascale.com>, 'Coreboot' > <coreboot(a)coreboot.org> > Subject: Re: [coreboot] [PATCH] AMD F10h: set MMCONF bus count > according toconfigured value > Message-ID: <E22BFE2842734C9D87B56FB2388A7CC4@m3a78> > Content-Type: text/plain; charset="us-ascii" > > -----Original Message----- > From: coreboot-bounces(a)coreboot.org [mailto:coreboot-bounces@coreboot.org] > On Behalf Of Carl-Daniel Hailfinger > Sent: Tuesday, October 19, 2010 01:25 PM > To: Scott Duplichan > Cc: 'Arne Georg Gleditsch'; 'Coreboot' > Subject: Re: [coreboot] [PATCH] AMD F10h: set MMCONF bus count according > toconfigured value > > ]Hi Scott, > ] > ]On 19.10.2010 19:47, Scott Duplichan wrote: > ]> Last night, I thought I would just learn about gas macros and do it > ]> that way. It was more difficult than I thought. I cannot even find > ]> examples of gas macros that use arguments. > ] > ]Take a look at src/cpu/amd/car/cache_as_ram.inc, specifically > ]extractmask and simplemask. > ] > ]Regards, > ]Carl-Daniel > ] > ]-- > ]http://www.hailfinger.org/ > > > > Thanks Carl-Daniel. > > Hello Myles, > > I am not so happy with the new one either. What I really wanted was a > macro called highestSetBit. That way, the reader can guess what macro > invocation highestSetBit (CONFIG_MMCONF_BUS_NUMBER) does without > actually digging it out. But I could not find a way to make that work. > Another idea was to find highestSetBit at runtime, if it could be done > a short and readable code sequence. This would be possible with family > 15h, where instructions such as lzcnt are supported. But family 10h > does not have this instruction. > > Now that Carl-Daniel has showed how to do gas macros, how about I add a > highestSetBit macro to amd/mtrr.h? Then everything else can be inlined? > > Thanks, > Scott > > > > > ------------------------------ > > Message: 5 > Date: Tue, 19 Oct 2010 12:39:47 -0600 > From: Myles Watson <mylesgw(a)gmail.com> > To: Scott Duplichan <scott(a)notabs.org> > Cc: Coreboot <coreboot(a)coreboot.org> > Subject: Re: [coreboot] [PATCH] AMD F10h: set MMCONF bus count > according toconfigured value > Message-ID: > <AANLkTin0CEA+NtTi_owW6ux=5bBkr2-QhSGawEwDqFx0(a)mail.gmail.com> > Content-Type: text/plain; charset=ISO-8859-1 > > On Tue, Oct 19, 2010 at 12:34 PM, Scott Duplichan <scott(a)notabs.org> > wrote: > > -----Original Message----- > > From: coreboot-bounces(a)coreboot.org [mailto: > coreboot-bounces(a)coreboot.org] On Behalf Of Carl-Daniel Hailfinger > > Sent: Tuesday, October 19, 2010 01:25 PM > > To: Scott Duplichan > > Cc: 'Arne Georg Gleditsch'; 'Coreboot' > > Subject: Re: [coreboot] [PATCH] AMD F10h: set MMCONF bus count according > toconfigured value > > > > ]Hi Scott, > > ] > > ]On 19.10.2010 19:47, Scott Duplichan wrote: > > ]> Last night, I thought I would just learn about gas macros and do it > > ]> that way. It was more difficult than I thought. I cannot even find > > ]> examples of gas macros that use arguments. > > ] > > ]Take a look at src/cpu/amd/car/cache_as_ram.inc, specifically > > ]extractmask and simplemask. > > ] > > ]Regards, > > ]Carl-Daniel > > ] > > ]-- > > ]http://www.hailfinger.org/ > > > > > > > > Thanks Carl-Daniel. > > > > Hello Myles, > > > > I am not so happy with the new one either. What I really wanted was a > > macro called highestSetBit. That way, the reader can guess what macro > > invocation highestSetBit (CONFIG_MMCONF_BUS_NUMBER) does without > > actually digging it out. But I could not find a way to make that work. > > Another idea was to find highestSetBit at runtime, if it could be done > > a short and readable code sequence. This would be possible with family > > 15h, where instructions such as lzcnt are supported. But family 10h > > does not have this instruction. > > > > Now that Carl-Daniel has showed how to do gas macros, how about I add a > > highestSetBit macro to amd/mtrr.h? Then everything else can be inlined? > > I would say it isn't worth the effort, but it's up to you. The > problem with macros in assembly is that it's unclear which registers > they clobber. That was why I suggested a pre-processor macro, but > it's not that important. > > Thanks, > Myles > > > > ------------------------------ > > Message: 6 > Date: Tue, 19 Oct 2010 13:56:14 -0500 > From: "Scott Duplichan" <scott(a)notabs.org> > To: "'Myles Watson'" <mylesgw(a)gmail.com> > Cc: 'Coreboot' <coreboot(a)coreboot.org> > Subject: Re: [coreboot] [PATCH] AMD F10h: set MMCONF bus count > according toconfigured value > Message-ID: <6D1AD5ECCB184C52B72A0F9A7CE30587@m3a78> > Content-Type: text/plain; charset="us-ascii" > > ]I would say it isn't worth the effort, but it's up to you. The > ]problem with macros in assembly is that it's unclear which registers > ]they clobber. That was why I suggested a pre-processor macro, but > ]it's not that important. > ] > ]Thanks, > ]Myles > > Hello Myles, > > Good point. Best would be a 'macro' that allows writing: > movl highestSetBit (busn), %eax > But that is not possible apparently. How about then, back > to inlined code with the extra error checks: > > Signed-off-by: Scott Duplichan <scott(a)notabs.org > > Index: src/cpu/amd/car/cache_as_ram.inc > =================================================================== > --- src/cpu/amd/car/cache_as_ram.inc (revision 5975) > +++ src/cpu/amd/car/cache_as_ram.inc (working copy) > @@ -132,15 +132,35 @@ > wrmsr > > #if CONFIG_MMCONF_SUPPORT > - /* Set MMIO config space BAR. */ > - movl $MSR_MCFG_BASE, %ecx > - rdmsr > - andl $(~(0xfff00000 | (0xf << 2))), %eax > - orl $((CONFIG_MMCONF_BASE_ADDRESS & 0xfff00000)), %eax > - orl $((8 << 2) | (1 << 0)), %eax > - andl $(~(0x0000ffff)), %edx > - orl $(CONFIG_MMCONF_BASE_ADDRESS >> 32), %edx > - wrmsr > + #if (CONFIG_MMCONF_BASE_ADDRESS > 0xFFFFFFFF) > + #error "MMCONF_BASE_ADDRESS too big" > + #elif (CONFIG_MMCONF_BASE_ADDRESS & 0xFFFFF) > + #error "MMCONF_BASE_ADDRESS not 1MB aligned" > + #endif > + movl $0, %edx > + movl $((CONFIG_MMCONF_BASE_ADDRESS) | (1 << 0)), %eax > + #if (CONFIG_MMCONF_BUS_NUMBER == 1) > + #elif (CONFIG_MMCONF_BUS_NUMBER == 2) > + orl $(1 << 2), %eax > + #elif (CONFIG_MMCONF_BUS_NUMBER == 4) > + orl $(2 << 2), %eax > + #elif (CONFIG_MMCONF_BUS_NUMBER == 8) > + orl $(3 << 2), %eax > + #elif (CONFIG_MMCONF_BUS_NUMBER == 16) > + orl $(4 << 2), %eax > + #elif (CONFIG_MMCONF_BUS_NUMBER == 32) > + orl $(5 << 2), %eax > + #elif (CONFIG_MMCONF_BUS_NUMBER == 64) > + orl $(6 << 2), %eax > + #elif (CONFIG_MMCONF_BUS_NUMBER == 128) > + orl $(7 << 2), %eax > + #elif (CONFIG_MMCONF_BUS_NUMBER == 256) > + orl $(8 << 2), %eax > + #else > + #error "bad MMCONF_BUS_NUMBER value" > + #endif > + movl $(0xc0010058), %ecx > + wrmsr > #endif > > CAR_FAM10_out_post_errata: > >

1 0

[PATCH] AMD F10h: set MMCONF bus count according to configured value
by Scott Duplichan 20 Oct '10

20 Oct '10

For AMD family 10h processors, msr c0010058 is always programmed for 256 buses, even if fewer are configured. This patch lets msr c0010058 programming use the configured bus count, CONFIG_MMCONF_BUS_NUMBER. Tested with the mahogany_fam10 project. Does the assembler have a compile time operator for highest set bit or base 2 log? That would sure simplify this patch. Signed-off-by: Scott Duplichan <scott(a)notabs.org> Index: src/cpu/amd/car/cache_as_ram.inc =================================================================== --- src/cpu/amd/car/cache_as_ram.inc (revision 5965) +++ src/cpu/amd/car/cache_as_ram.inc (working copy) @@ -136,8 +136,26 @@ movl $MSR_MCFG_BASE, %ecx rdmsr andl $(~(0xfff00000 | (0xf << 2))), %eax - orl $((CONFIG_MMCONF_BASE_ADDRESS & 0xfff00000)), %eax - orl $((8 << 2) | (1 << 0)), %eax + orl $((CONFIG_MMCONF_BASE_ADDRESS & 0xfff00000) | (1 << 0)), %eax + #if (CONFIG_MMCONF_BUS_NUMBER == 2) + orl $1, %eax + #elif (CONFIG_MMCONF_BUS_NUMBER == 4) + orl $2, %eax + #elif (CONFIG_MMCONF_BUS_NUMBER == 8) + orl $3, %eax + #elif (CONFIG_MMCONF_BUS_NUMBER == 16) + orl $4, %eax + #elif (CONFIG_MMCONF_BUS_NUMBER == 32) + orl $5, %eax + #elif (CONFIG_MMCONF_BUS_NUMBER == 64) + orl $6, %eax + #elif (CONFIG_MMCONF_BUS_NUMBER == 128) + orl $7, %eax + #elif (CONFIG_MMCONF_BUS_NUMBER == 256) + orl $8, %eax + #else + #error "unsupported MMCONF_BUS_NUMBER value" + #endif andl $(~(0x0000ffff)), %edx orl $(CONFIG_MMCONF_BASE_ADDRESS >> 32), %edx wrmsr

6 14

[commit] r5975 - trunk/src/mainboard/msi/ms7135
by repository service 19 Oct '10

19 Oct '10

Author: jakllsch Date: Tue Oct 19 17:25:06 2010 New Revision: 5975 URL: https://tracker.coreboot.org/trac/coreboot/changeset/5975 Log: Drop duplicate SB_HT_CHAIN_ON_BUS0 in Kconfig for MS-7135. Trivial. Signed-off-by: Jonathan Kollasch <jakllsch(a)kollasch.net> Acked-by: Jonathan Kollasch <jakllsch(a)kollasch.net> Modified: trunk/src/mainboard/msi/ms7135/Kconfig Modified: trunk/src/mainboard/msi/ms7135/Kconfig ============================================================================== --- trunk/src/mainboard/msi/ms7135/Kconfig Tue Oct 19 17:17:18 2010 (r5974) +++ trunk/src/mainboard/msi/ms7135/Kconfig Tue Oct 19 17:25:06 2010 (r5975) @@ -29,10 +29,6 @@ int default 2 -config SB_HT_CHAIN_ON_BUS0 - int - default 2 - config MAINBOARD_PART_NUMBER string default "MS-7135"

1 0

[commit] r5974 - trunk/src/mainboard/msi/ms7135
by repository service 19 Oct '10

19 Oct '10

Author: jakllsch Date: Tue Oct 19 17:17:18 2010 New Revision: 5974 URL: https://tracker.coreboot.org/trac/coreboot/changeset/5974 Log: Use the correct (W83627THF, not W83627HF) superio code in MS-7135 romstage. This is consistent with the device tree and the chip actually on the board. Trivial. Signed-off-by: Jonathan Kollasch <jakllsch(a)kollasch.net> Acked-by: Jonathan Kollasch <jakllsch(a)kollasch.net> Modified: trunk/src/mainboard/msi/ms7135/romstage.c Modified: trunk/src/mainboard/msi/ms7135/romstage.c ============================================================================== --- trunk/src/mainboard/msi/ms7135/romstage.c Tue Oct 19 16:02:10 2010 (r5973) +++ trunk/src/mainboard/msi/ms7135/romstage.c Tue Oct 19 17:17:18 2010 (r5974) @@ -22,7 +22,7 @@ * Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA */ -#define SERIAL_DEV PNP_DEV(0x4e, W83627HF_SP1) +#define SERIAL_DEV PNP_DEV(0x4e, W83627THF_SP1) /* Used by raminit. */ #define QRANK_DIMM_SUPPORT 1 @@ -41,7 +41,7 @@ #include <pc80/mc146818rtc.h> #include "cpu/x86/lapic/boot_cpu.c" #include "northbridge/amd/amdk8/reset_test.c" -#include "superio/winbond/w83627hf/w83627hf_early_serial.c" +#include "superio/winbond/w83627thf/w83627thf_early_serial.c" #include <cpu/amd/model_fxx_rev.h> #include <console/console.h> @@ -135,7 +135,7 @@ bsp_apicid = init_cpus(cpu_init_detectedx); } - w83627hf_enable_serial(SERIAL_DEV, CONFIG_TTYS0_BASE); + w83627thf_enable_serial(SERIAL_DEV, CONFIG_TTYS0_BASE); uart_init(); console_init();

1 0

[patch] hard_reset() for 6300esb
by Jonathan A. Kollasch 19 Oct '10

19 Oct '10

Copy ICH4 hard_reset() for 6300ESB. Signed-off-by: Jonathan Kollasch <jakllsch(a)kollasch.net> ---

2 2

[commit] r5973 - trunk/src/southbridge/intel/esb6300
by repository service 19 Oct '10

19 Oct '10

Author: jakllsch Date: Tue Oct 19 16:02:10 2010 New Revision: 5973 URL: https://tracker.coreboot.org/trac/coreboot/changeset/5973 Log: Copy ICH4 hard_reset() for 6300ESB. Signed-off-by: Jonathan Kollasch <jakllsch(a)kollasch.net> Acked-by: Peter Stuge <peter(a)stuge.se> Added: trunk/src/southbridge/intel/esb6300/esb6300_reset.c - copied unchanged from r5972, trunk/src/southbridge/intel/i82801dx/i82801dx_reset.c Modified: trunk/src/southbridge/intel/esb6300/Makefile.inc Modified: trunk/src/southbridge/intel/esb6300/Makefile.inc ============================================================================== --- trunk/src/southbridge/intel/esb6300/Makefile.inc Tue Oct 19 15:49:11 2010 (r5972) +++ trunk/src/southbridge/intel/esb6300/Makefile.inc Tue Oct 19 16:02:10 2010 (r5973) @@ -1,4 +1,5 @@ driver-y += esb6300.c +driver-y += esb6300_reset.c driver-y += esb6300_uhci.c driver-y += esb6300_lpc.c driver-y += esb6300_ide.c Copied: trunk/src/southbridge/intel/esb6300/esb6300_reset.c (from r5972, trunk/src/southbridge/intel/i82801dx/i82801dx_reset.c) ============================================================================== --- /dev/null 00:00:00 1970 (empty, because file is newly added) +++ trunk/src/southbridge/intel/esb6300/esb6300_reset.c Tue Oct 19 16:02:10 2010 (r5973, copy of r5972, trunk/src/southbridge/intel/i82801dx/i82801dx_reset.c) @@ -0,0 +1,27 @@ +/* + * This file is part of the coreboot project. + * + * Copyright (C) 2004 Ronald G. Minnich + * + * This program is free software; you can redistribute it and/or modify + * it under the terms of the GNU General Public License as published by + * the Free Software Foundation; version 2 of the License. + * + * This program is distributed in the hope that it will be useful, + * but WITHOUT ANY WARRANTY; without even the implied warranty of + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the + * GNU General Public License for more details. + * + * You should have received a copy of the GNU General Public License + * along with this program; if not, write to the Free Software + * Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA + */ + +#include <arch/io.h> +#include <reset.h> + +void hard_reset(void) +{ + /* Try rebooting through port 0xcf9 */ + outb((0 << 3) | (1 << 2) | (1 << 1), 0xcf9); +}

1 0

[patch] 6300ESB early smbus cleanup
by Jonathan A. Kollasch 19 Oct '10

19 Oct '10

Remove unused variables from 6300ESB smbus_write_block(). #if 0 smbus_write_byte() and smbus_write_block() as they are static and nothing uses them or are incompletely implemented. Signed-off-by: Jonathan Kollasch <jakllsch(a)kollasch.net> ---

3 3

[commit] r5972 - trunk/src/southbridge/intel/esb6300
by repository service 19 Oct '10

19 Oct '10

Author: jakllsch Date: Tue Oct 19 15:49:11 2010 New Revision: 5972 URL: https://tracker.coreboot.org/trac/coreboot/changeset/5972 Log: Remove unused variables from 6300ESB smbus_write_block(). #ifdef DEADCODE out smbus_write_byte() and smbus_write_block() as they are static and nothing uses them or are incompletely implemented. Signed-off-by: Jonathan Kollasch <jakllsch(a)kollasch.net> Acked-by: Peter Stuge <peter(a)stuge.se> Modified: trunk/src/southbridge/intel/esb6300/esb6300_early_smbus.c Modified: trunk/src/southbridge/intel/esb6300/esb6300_early_smbus.c ============================================================================== --- trunk/src/southbridge/intel/esb6300/esb6300_early_smbus.c Tue Oct 19 15:39:38 2010 (r5971) +++ trunk/src/southbridge/intel/esb6300/esb6300_early_smbus.c Tue Oct 19 15:49:11 2010 (r5972) @@ -22,6 +22,7 @@ return do_smbus_read_byte(SMBUS_IO_BASE, device, address); } +#ifdef DEADCODE static void smbus_write_byte(unsigned device, unsigned address, unsigned char val) { if (smbus_wait_until_ready(SMBUS_IO_BASE) < 0) { @@ -33,8 +34,6 @@ static int smbus_write_block(unsigned device, unsigned length, unsigned cmd, unsigned data1, unsigned data2) { - unsigned char global_control_register; - unsigned char global_status_register; unsigned char byte; unsigned char stat; int i; @@ -95,4 +94,5 @@ print_debug("SMBUS Block complete\n"); return 0; } +#endif

1 0

[patch] i855 raminit comment spelling corrections
by Jonathan A. Kollasch 19 Oct '10

19 Oct '10

Correct spelling of spacing (in comments). Signed-off-by: Jonathan Kollasch <jakllsch(a)kollasch.net> ---

2 2

[commit] r5971 - trunk/src/northbridge/intel/i855
by repository service 19 Oct '10

19 Oct '10

Author: jakllsch Date: Tue Oct 19 15:39:38 2010 New Revision: 5971 URL: https://tracker.coreboot.org/trac/coreboot/changeset/5971 Log: Correct spelling of "spacing" (in comments). Signed-off-by: Jonathan Kollasch <jakllsch(a)kollasch.net> Acked-by: Peter Stuge <peter(a)stuge.se> Modified: trunk/src/northbridge/intel/i855/raminit.c Modified: trunk/src/northbridge/intel/i855/raminit.c ============================================================================== --- trunk/src/northbridge/intel/i855/raminit.c Tue Oct 19 15:11:56 2010 (r5970) +++ trunk/src/northbridge/intel/i855/raminit.c Tue Oct 19 15:39:38 2010 (r5971) @@ -755,7 +755,7 @@ */ /* - * Back to Back Read-Write command spaceing (DDR, different Rows/Bank) + * Back to Back Read-Write command spacing (DDR, different Rows/Bank) */ /* Set to a 3 clock back to back read to write turn around. * 2 is a good delay if the CAS latency is 2.0 */ @@ -766,7 +766,7 @@ dram_timing |= (1 << 28); // 3 clocks /* - * Back to Back Read-Write command spaceing (DDR, same or different Rows/Bank) + * Back to Back Read-Write command spacing (DDR, same or different Rows/Bank) */ dram_timing &= ~(3 << 26); if (current_cas_latency == DRT_CAS_2_0)

1 0

← Newer
1
...
9
10
11
12
13
14
15
...
32
Older →

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

coreboot October 2010