coreboot October 2010

coreboot@coreboot.org

55 participants
316 discussions

Mark Beihoffer has invited you to open a Google mail account
by Mark Beihoffer 22 Oct '10

22 Oct '10

I've been using Gmail and thought you might like to try it out. Here's an invitation to create an account. You're Invited to Gmail! Mark Beihoffer has invited you to open a Gmail account. Gmail is Google's free email service, built on the idea that email can be intuitive, efficient, and fun. Gmail has: *Less spam* Keep unwanted messages out of your inbox with Google's innovative technology. *Lots of space* Enough storage so that you'll never have to delete another message. *Built-in chat* Text or video chat with Mark Beihoffer and other friends in real time. *Mobile access* Get your email anywhere with Gmail on your mobile phone. You can even import your contacts and email from Yahoo!, Hotmail, AOL, or any other web mail or POP accounts. Once you create your account, Mark Beihoffer will be notified of your new Gmail address so you can stay in touch. Learn more<http://mail.google.com/mail/help/intl/en/about.html>or get started<http://mail.google.com/mail/a-273fae0330-b83fc009ac-kCWmf2yFIP99-wBkiFmp7ts…> ! Sign up<http://mail.google.com/mail/a-273fae0330-b83fc009ac-kCWmf2yFIP99-wBkiFmp7ts…> Google Inc. | 1600 Ampitheatre Parkway | Mountain View, California 94043

2 1

coreboot doesn't compile smihandler.c smmhandler.S, even smm.h file, am I supposed to use other ways to compile SMM mode code?
by fengwei zhang 22 Oct '10

22 Oct '10

Hi, It seems like coreboot doesn't compile smihandler.c, smmhandler.S, even smm.h file. I tried to put some junk into these files, and then make the coreboot source code. it could still build the coreboot.rom image. In other words, coreboot BIOS doesn't use any code under src/cpu/x86/smm/. Since SMM is a special mode, am I supposed to use other ways to compile SMM mode code? Thank you very much! Best, Fengwei

3 4

[commit] r5976 - trunk/src/cpu/amd/car
by repository service 21 Oct '10

21 Oct '10

Author: sduplichan Date: Tue Oct 19 23:08:11 2010 New Revision: 5976 URL: https://tracker.coreboot.org/trac/coreboot/changeset/5976 Log: 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. Signed-off-by: Scott Duplichan <scott(a)notabs.org> Acked-by: Myles Watson <mylesgw(a)gmail.com> Modified: trunk/src/cpu/amd/car/cache_as_ram.inc Modified: trunk/src/cpu/amd/car/cache_as_ram.inc ============================================================================== --- trunk/src/cpu/amd/car/cache_as_ram.inc Tue Oct 19 17:25:06 2010 (r5975) +++ trunk/src/cpu/amd/car/cache_as_ram.inc Tue Oct 19 23:08:11 2010 (r5976) @@ -132,14 +132,34 @@ 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 + #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

5 6

#168: USBDEBUG might slow down coreboot
by coreboot 21 Oct '10

21 Oct '10

#168: USBDEBUG might slow down coreboot -------------------------+-------------------------------------------------- Reporter: oxygene | Owner: stepan@… Type: defect | Status: new Priority: minor | Milestone: Component: coreboot | Keywords: usbdebug Dependencies: | Patch Status: there is no patch -------------------------+-------------------------------------------------- If USBDEBUG and verbose logging are enabled, printing text slows down after the resource allocator reconfigured EHCI. This is because the usbdebug console caches the BAR location, and the resource allocator is free to move the BAR to somewhere else. -- Ticket URL: <https://tracker.coreboot.org/trac/coreboot/ticket/168> coreboot <http://www.coreboot.org/>

1 0

Extension to inteltool and a request
by Keith Hui 21 Oct '10

21 Oct '10

Hi all, This patch extends inteltool's MSR dumping to all Slot 1 Intel CPUs. I made this an attempt to gather some information for an updated L2 patch, so I have a request to all, Can anyone with a Slot 1 CPU apply the attached patch, compile inteltool, and post the output together with some information on your CPU? Thanks. Patch is Signed-off-by: Keith Hui <buurin(a)gmail.com> if it's useful for the future and worth committing.

4 3

Getting started with ASUS M2N-SLI Deluxe design
by Michael Cassaniti 21 Oct '10

21 Oct '10

Hi All, Apologies in advance for my naivety. I am starting out with a build for an ASUS M2N-SLI Deluxe board. This uses the nForce MCP55 chipset, with a supported southbridge and LPC flash chip for the BIOS. Original product specifications can be found here: http://www.asus.com.au/product.aspx?P_ID=szSFtrap7crpBaQE First, I am wondering how to go about adding a backup flash chip to this board. I don't wish to remove the whole flash chip if I don't need to. I was thinking of attaching a device and simply de-soldering the OE pin of the original chip. Secondly, what tables change between motherboards that I would need to identify? I gather that the memory map and the PIRQ information changes, but I'm not sure what else does. I have ordered a port 80 debug card, and I have a machine I can use for serial console monitoring of the BIOS. Any help beyond the developers manual is appreciated. Thank you, Michael Cassaniti

1 0

[PATCH] fix cpu ht speed display in rs780_gfx.c
by Liu Tao 20 Oct '10

20 Oct '10

Hello, the original code reads cpu ht speed from HT chain 0's register. the patch fix it to read the register from the chain which SB chip is on. Signed-off-by: Liu Tao <liutao1980(a)gmail.com> Index: src/southbridge/amd/rs780/rs780_gfx.c =================================================================== --- src/southbridge/amd/rs780/rs780_gfx.c (revision 5923) +++ src/southbridge/amd/rs780/rs780_gfx.c (working copy) @@ -302,7 +302,7 @@ unsigned char * bpointer; volatile u32 * GpuF0MMReg; volatile u32 * pointer; - int i; + int i, sblk; u16 command; u32 value; u16 deviceid, vendorid; @@ -453,9 +453,15 @@ vgainfo.usMinNBVoltage = 0; vgainfo.usBootUpNBVoltage = 0x1a; + /* SB link */ + value = pci_read_config32(k8_f0, 0x64); + sblk = (value >> 8) & 0x3; + printk(BIOS_DEBUG, "SBLK = %d.\n", sblk); + + /* HT speed */ value = pci_read_config32(nb_dev, 0xd0); printk(BIOS_DEBUG, "NB HT speed = %x.\n", value); - value = pci_read_config32(k8_f0, 0x88); + value = pci_read_config32(k8_f0, 0x88 + (sblk * 0x20)); printk(BIOS_DEBUG, "CPU HT speed = %x.\n", value); vgainfo.ulHTLinkFreq = 100 * 100; /* set HT speed. */ -- Regards, Liu Tao

5 10

[commit] r5978 - trunk/src/southbridge/amd/rs780
by repository service 20 Oct '10

20 Oct '10

Author: uwe Date: Wed Oct 20 22:21:27 2010 New Revision: 5978 URL: https://tracker.coreboot.org/trac/coreboot/changeset/5978 Log: Revert sblk/sblink change, use sblk like the rest of the codebase does. Signed-off-by: Uwe Hermann <uwe(a)hermann-uwe.de> Acked-by: Uwe Hermann <uwe(a)hermann-uwe.de> Modified: trunk/src/southbridge/amd/rs780/rs780_gfx.c Modified: trunk/src/southbridge/amd/rs780/rs780_gfx.c ============================================================================== --- trunk/src/southbridge/amd/rs780/rs780_gfx.c Wed Oct 20 21:23:22 2010 (r5977) +++ trunk/src/southbridge/amd/rs780/rs780_gfx.c Wed Oct 20 22:21:27 2010 (r5978) @@ -304,7 +304,7 @@ volatile u32 * pointer; int i; u16 command; - u32 value, sblink; + u32 value, sblk; u16 deviceid, vendorid; device_t nb_dev = dev_find_slot(0, 0); device_t k8_f2 = dev_find_slot(0, PCI_DEVFN(0x18, 2)); @@ -455,13 +455,13 @@ /* Get SBLink value (HyperTransport I/O Hub Link ID). */ value = pci_read_config32(k8_f0, 0x64); - sblink = (value >> 8) & 0x3; - printk(BIOS_DEBUG, "SBLINK = %d.\n", sblink); + sblk = (value >> 8) & 0x3; + printk(BIOS_DEBUG, "SBLINK = %d.\n", sblk); /* HT speed */ value = pci_read_config32(nb_dev, 0xd0); printk(BIOS_DEBUG, "NB HT speed = %x.\n", value); - value = pci_read_config32(k8_f0, 0x88 + (sblink * 0x20)); + value = pci_read_config32(k8_f0, 0x88 + (sblk * 0x20)); printk(BIOS_DEBUG, "CPU HT speed = %x.\n", value); vgainfo.ulHTLinkFreq = 100 * 100; /* set HT speed. */

1 0

[commit] r5977 - in trunk/src: arch/i386 cpu/x86/pae
by repository service 20 Oct '10

20 Oct '10

Author: myles Date: Wed Oct 20 21:23:22 2010 New Revision: 5977 URL: https://tracker.coreboot.org/trac/coreboot/changeset/5977 Log: Now that no boards set RAMBASE < 1M, get rid of some dead code. Trivial. It's probably time to reconsider moving all fam10 boards to RAMBASE = 1M. Signed-off-by: Myles Watson <mylesgw(a)gmail.com> Acked-by: Myles Watson <mylesgw(a)gmail.com> Modified: trunk/src/arch/i386/coreboot_ram.ld trunk/src/cpu/x86/pae/pgtbl.c Modified: trunk/src/arch/i386/coreboot_ram.ld ============================================================================== --- trunk/src/arch/i386/coreboot_ram.ld Tue Oct 19 23:08:11 2010 (r5976) +++ trunk/src/arch/i386/coreboot_ram.ld Wed Oct 20 21:23:22 2010 (r5977) @@ -106,13 +106,6 @@ } _eheap = .; - /* Some assertions to print human readable errors for certain linker - * error scenarios. - */ - - /* Avoid running into 0xa0000-0xfffff */ - _bogus = ASSERT(CONFIG_RAMBASE >= 0x100000 || _eheap < 0xa0000, "Please move RAMBASE to 1MB"); - /* The ram segment. This includes all memory used by the memory * resident copy of coreboot, except the tables that are produced on * the fly, but including stack and heap. @@ -125,13 +118,6 @@ */ _bogus = ASSERT( ( _eram_seg < (CONFIG_RAMTOP)) , "Please increase CONFIG_RAMTOP"); - /* This rule is only good for the few broken targets that still live - * below 1MB per default. Those are the Geode and VIA targets that come - * with their own version of real mode switches that can't live above - * 1MB. Once these are fixed, this rule should go away. - */ - _bogus = ASSERT( !((CONFIG_CONSOLE_VGA || CONFIG_PCI_ROM_RUN || CONFIG_VGA_ROM_RUN || CONFIG_HAVE_SMI_HANDLER) && ((_ram_seg<0xa0000) && (_eram_seg>0xa0000))), "Please increase CONFIG_RAMTOP and if still fail, try to set CONFIG_RAMBASE to 1M"); - /* Discard the sections we don't need/want */ /DISCARD/ : { Modified: trunk/src/cpu/x86/pae/pgtbl.c ============================================================================== --- trunk/src/cpu/x86/pae/pgtbl.c Tue Oct 19 23:08:11 2010 (r5976) +++ trunk/src/cpu/x86/pae/pgtbl.c Wed Oct 20 21:23:22 2010 (r5977) @@ -54,24 +54,7 @@ struct pde pdp[512]; } __attribute__ ((packed)); -#if (CONFIG_RAMTOP>0x100000) && (CONFIG_RAMBASE<0x100000) && ((CONFIG_CONSOLE_VGA==1) || (CONFIG_PCI_ROM_RUN == 1)) - /* - pgtbl is too big, so use last one 1M before CONFIG_LB_MEM_TOP, otherwise for 8 way dual core with vga support will push stack and heap cross 0xa0000, - and that region need to be used as vga font buffer. Please make sure set CONFIG_RAMTOP=0x200000 in MB Config - */ - struct pg_table *pgtbl = (struct pg_table*)0x100000; //1M - - unsigned x_end = 0x100000 + sizeof(struct pg_table) * CONFIG_MAX_CPUS; -#if (0x100000+20480*CONFIG_MAX_CPUS) > (CONFIG_RAMTOP) - #warning "We may need to increase CONFIG_RAMTOP, it need to be more than (0x100000+20480*CONFIG_MAX_CPUS)\n" -#endif - if(x_end > (CONFIG_RAMTOP)) { - printk(BIOS_DEBUG, "map_2M_page: Please increase the CONFIG_RAMTOP more than %dK\n", x_end); - die("Can not go on"); - } -#else static struct pg_table pgtbl[CONFIG_MAX_CPUS] __attribute__ ((aligned(4096))); -#endif static unsigned long mapped_window[CONFIG_MAX_CPUS]; unsigned long index; unsigned long window;

1 0

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

20 Oct '10

Contempt? Whatever. Mark Beihoffer Dragonfly Networks mbeihoffer(a)gmail.com mark(a)dragonfly-networks.com (612)508-5128 On Wed, Oct 20, 2010 at 12:31 AM, <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. [commit] r5976 - trunk/src/cpu/amd/car (repository service) > 2. Re: [PATCH] AMD F10h: set MMCONF bus count according > toconfigured value (Peter Stuge) > 3. Re: [PATCH] fix cpu ht speed display in rs780_gfx.c (Liu Tao) > 4. Extension to inteltool and a request (Keith Hui) > 5. Re: coreboot Digest, Vol 68, Issue 108 (Mark Beihoffer) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Tue, 19 Oct 2010 23:08:12 +0200 > From: repository service <svn(a)coreboot.org> > To: coreboot(a)coreboot.org > Subject: [coreboot] [commit] r5976 - trunk/src/cpu/amd/car > Message-ID: <E1P8JPo-0008L5-HC(a)ra.coresystems.de> > Content-Type: text/plain; charset=UTF-8 > > Author: sduplichan > Date: Tue Oct 19 23:08:11 2010 > New Revision: 5976 > URL: https://tracker.coreboot.org/trac/coreboot/changeset/5976 > > Log: > 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. > > Signed-off-by: Scott Duplichan <scott(a)notabs.org> > Acked-by: Myles Watson <mylesgw(a)gmail.com> > > Modified: > trunk/src/cpu/amd/car/cache_as_ram.inc > > Modified: trunk/src/cpu/amd/car/cache_as_ram.inc > > ============================================================================== > --- trunk/src/cpu/amd/car/cache_as_ram.inc Tue Oct 19 17:25:06 2010 > (r5975) > +++ trunk/src/cpu/amd/car/cache_as_ram.inc Tue Oct 19 23:08:11 2010 > (r5976) > @@ -132,14 +132,34 @@ > 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 > + #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 > > > > > ------------------------------ > > Message: 2 > Date: Wed, 20 Oct 2010 00:17:31 +0200 > From: Peter Stuge <peter(a)stuge.se> > To: coreboot(a)coreboot.org > Subject: Re: [coreboot] [PATCH] AMD F10h: set MMCONF bus count > according toconfigured value > Message-ID: <20101019221731.1550.qmail(a)stuge.se> > Content-Type: text/plain; charset=us-ascii > > Scott Duplichan wrote: > > back to inlined code with the extra error checks: > > > > Signed-off-by: Scott Duplichan <scott(a)notabs.org > > Acked-by: Peter Stuge <peter(a)stuge.se> > > > > ------------------------------ > > Message: 3 > Date: Wed, 20 Oct 2010 09:13:17 +0800 > From: Liu Tao <liutao1980(a)gmail.com> > To: Uwe Hermann <uwe(a)hermann-uwe.de> > Cc: Myles Watson <mylesgw(a)gmail.com>, coreboot(a)coreboot.org > Subject: Re: [coreboot] [PATCH] fix cpu ht speed display in > rs780_gfx.c > Message-ID: > <AANLkTinGdeiSayFcuGp5dffa1qL6eq2uLCFOpwNx1280(a)mail.gmail.com> > Content-Type: text/plain; charset=ISO-8859-1 > > The name of sblink seems more clear, but for most cases, the name of sblk > only appears in K8/Fam10 codes, so it didn't cause much confusions. > > A more consistent way to get HT southbridge link in sb700 chipset is to > include > the <cpu/amd/amdk8_sysconf.h> or <cpu/amd/amdfam10_sysconf.h>, and > use global variable sysconf.sblk. For now, fam10 codes set sysconf.sblk > during > early romstage, but K8 codes didn't. Maybe we should fix K8 coeds to set > sysconf.sblk earlyer, and use it in later device drivers. > > On Mon, Oct 18, 2010 at 6:01 AM, Uwe Hermann <uwe(a)hermann-uwe.de> wrote: > > On Sun, Oct 17, 2010 at 11:39:46PM +0200, Uwe Hermann wrote: > >> ?- Renamed sblk to sblink (the name of the register bits as per > >> ? ?BIOS + Kernel Developer's Guide for AMD Athlon 64 & AMD Opteron > Processors, > >> ? ?chapter 3.3.8. > > > > Hm, I noticed that the K8/Fam10h code uses "sblk" as function/variable > name > > pretty consistently, but I can't seem to find that spelling in any of > > the AMD manuals. Should we rename "sblk" to "sblink" in the whole tree? > > -- > Regards, > Liu Tao > > > > ------------------------------ > > Message: 4 > Date: Wed, 20 Oct 2010 00:57:21 -0400 > From: Keith Hui <buurin(a)gmail.com> > To: coreboot(a)coreboot.org > Subject: [coreboot] Extension to inteltool and a request > Message-ID: > <AANLkTimCnR9RdDSMpNYk72DrP6rHvemX41R-f3ZZVCVk(a)mail.gmail.com> > Content-Type: text/plain; charset="iso-8859-1" > > Hi all, > > This patch extends inteltool's MSR dumping to all Slot 1 Intel CPUs. > > I made this an attempt to gather some information for an updated L2 > patch, so I have a request to all, > > Can anyone with a Slot 1 CPU apply the attached patch, compile > inteltool, and post the output together with some information on your > CPU? > > Thanks. > > Patch is Signed-off-by: Keith Hui <buurin(a)gmail.com> > if it's useful for the future and worth committing. >

1 0

← Newer
1
...
8
9
10
11
12
13
14
...
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