[coreboot] [commit] r6341 - trunk/src/southbridge/amd/rs690
Author: oxygene
Date: Thu Feb 10 09:49:57 2011
New Revision: 6341
URL: https://tracker.coreboot.org/trac/coreboot/changeset/6341
Log:
RS690: Provide support for MMCONF.
If enabled, set up 0xe000..0xf000 as MMCONF
area. Must still be configured in per-board ACPI for
the OS to pick it up, so it's disabled by default.
Signed-off-by: Josef Kellermannse...@arcor.de
Acked-by: Patrick Georgi patrick.geo...@secunet.com
Modified:
trunk/src/southbridge/amd/rs690/Kconfig
trunk/src/southbridge/amd/rs690/ht.c
Modified: trunk/src/southbridge/amd/rs690/Kconfig
==
--- trunk/src/southbridge/amd/rs690/Kconfig Thu Feb 10 08:51:51 2011
(r6340)
+++ trunk/src/southbridge/amd/rs690/Kconfig Thu Feb 10 09:49:57 2011
(r6341)
@@ -20,3 +20,10 @@
config SOUTHBRIDGE_AMD_RS690
bool
+if SOUTHBRIDGE_AMD_RS690
+config EXT_CONF_SUPPORT
+ def_bool n
+ help
+ Select if RS690 should be setup to support MMCONF.
+
+endif
Modified: trunk/src/southbridge/amd/rs690/ht.c
==
--- trunk/src/southbridge/amd/rs690/ht.cThu Feb 10 08:51:51 2011
(r6340)
+++ trunk/src/southbridge/amd/rs690/ht.cThu Feb 10 09:49:57 2011
(r6341)
@@ -22,8 +22,93 @@
#include device/pci.h
#include device/pci_ids.h
#include device/pci_ops.h
+#include lib.h
#include rs690.h
+static void ht_dev_set_resources(device_t dev)
+{
+#if CONFIG_EXT_CONF_SUPPORT == 1
+ unsigned reg;
+ device_t k8_f1;
+ resource_t rbase, rend;
+ u32 base, limit;
+ struct resource *resource;
+
+ printk(BIOS_DEBUG,%s %s\n, dev_path(dev), __func__);
+
+ resource = probe_resource(dev, 0x1C);
+ if (resource) {
+ set_nbmisc_enable_bits(dev, 0x0, 1 3, 0 3); // make bar3
visible
+ set_nbcfg_enable_bits(dev, 0x7C, 1 30, 1 30); /*
Enables writes to the BAR3 register. */
+ set_nbcfg_enable_bits(dev, 0x84, 7 16, 0 16); // program
bus range: 255 busses
+ pci_write_config32(dev, 0x1C, resource-base);
+ /* Enable MMCONFIG decoding. */
+ set_htiu_enable_bits(dev, 0x32, 1 28, 1 28); /*
PCIEMiscInit */
+ set_nbcfg_enable_bits(dev, 0x7C, 1 30, 0 30); /*
Disable writes to the BAR3 register. */
+ set_nbmisc_enable_bits(dev, 0x0, 1 3, 1 3); // hide bar 3
+
+ // setup resource nonposted in k8 mmio
+ /* Get the base address */
+ rbase = resource-base;
+ /* Get the limit (rounded up) */
+ rend = resource_end(resource);
+ printk(BIOS_DEBUG,%s: %s[0x1C] base = %0llx limit = %0llx\n,
__func__, dev_path(dev), rbase, rend);
+ k8_f1 = dev_find_slot(0,PCI_DEVFN(0x18,1));
+ // find a not assigned resource
+ for( reg = 0xb8; reg = 0x80; reg -= 8 ) {
+ base = pci_read_config32(k8_f1,reg);
+ limit = pci_read_config32(k8_f1,reg+4);
+ if( !(base 3) ) break; // found a not assigned
resource
+ }
+ if( !(base 3) ) {
+ u32 sblk;
+ device_t k8_f0 = dev_find_slot(0, PCI_DEVFN(0x18, 0));
+ /* Remember this resource has been stored. */
+ resource-flags |= IORESOURCE_STORED;
+ report_resource_stored(dev, resource, mmconfig);
+ /* Get SBLink value (HyperTransport I/O Hub Link ID). */
+ sblk = (pci_read_config32(k8_f0, 0x64) 8) 0x3;
+ base = 0x00f0;
+ base |= ((rbase 8) 0xff00);
+ base |= 3;
+ limit = 0x0048;
+ limit |= ((rend 8) 0xff00);
+ limit |= (sblk 4);
+ limit |= (1 7);
+ printk(BIOS_INFO, %s - index %x base %04x limit
%04x\n, dev_path(k8_f1), reg, base, limit);
+ pci_write_config32(k8_f1, reg+4, limit);
+ pci_write_config32(k8_f1, reg, base);
+ }
+ }
+#endif
+ pci_dev_set_resources(dev);
+}
+
+static void ht_dev_read_resources(device_t dev)
+{
+#if CONFIG_EXT_CONF_SUPPORT == 1
+ struct resource *res;
+
+ printk(BIOS_DEBUG,%s %s\n, dev_path(dev), __func__);
+ set_nbmisc_enable_bits(dev, 0x0, 1 3, 1 3); // hide bar 3
+#endif
+
+ pci_dev_read_resources(dev);
+
+#if CONFIG_EXT_CONF_SUPPORT == 1
+ /* Add an MMCONFIG resource. */
+ res = new_resource(dev, 0x1C);
+ res-base = EXT_CONF_BASE_ADDRESS;
+ res-size = 256 * 1024 * 1024; // 256 busses, 1MB memory
Re: [coreboot] what was 'set' in struct io_info for?
On 08/02/2011 01:38, Jonathan A. Kollasch wrote: Hi, I noticed that, other than initialization in almost every superio, the 'set' member of struct io_info doesn't seem to be referenced by the pnp code. Worth the removing? Jonathan Kollasch I found the same thing as you a while ago. The io_info structure in pnp.h is never referenced by the code, and it's purpose is never really defined anywhere. If you change the name to something else (just in the header file) the code still all compiles, so I'd say remove it. I also asked about it on the news group, but got no reply. MM -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
[coreboot] searching volunteer to install coreboot on asus m4a78 pro
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hello everybody, I would like to start with thanking all volunteers on the coreboot project! At FOSDEM 2011 I had dinner with two of the volunteers. I have been watching the coreboot for the past years, as something that I love to have running on my motherboards but never found the time/resources to made a first step. I would like to get coreboot on this system[1]. I would like the coreboot to be installed by a volunteer. I can provide ssh access (both ipv4 and ipv6) and a root passwd to the machine, and standby to help over IRC. [1] http://debian.pastebin.com/mqphUf5U # details ASUSTeK M4A78 PRO Features I would like: * Serial Console Redirection * AMD Athlon II X4 615e support * ECC Memory support * Readout volt,temp,rpm sensors * Boot 2.6 kernel support * Grub 2 (lvm, mdadm, ext4) support I got two M4A78 PRO motherboards that I would like to give new life by getting coreboot on them. With kind regards, Jelle de Jong -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (GNU/Linux) iJwEAQECAAYFAk1T/5sACgkQ1WclBW9j5HlTBwP+KOImcCztj3LYsrMKGO5nMO0x shPLdP+Zaa+kgM4pJP2QX748f9ibZEQGYlljbb3ZdgPzPYEguuGyZrFU+TfjTDHx ePQhfxf6IiySOMGqMLDJ7Gyd+xBVujuzvZXaF7JXfwEuXX0bQLZyq+qjEI14pKfu 0tVUxrAThodY4+a+SO4= =x6PR -END PGP SIGNATURE- -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
[coreboot] [PATCH] cache type for BIOS flash memory should be WP-MMIO, not WB-MMIO
According to AMD documentation, cache type WP should be used for execution from flash memory. Coreboot uses WB. While there is no noticeable performance difference between the two settings, use of WB can cause a problem for a jtag debugger. The attached patch changes AMD cache as ram setting for flash execution from WB to WP. Signed-off-by: Scott Duplichan sc...@notabs.org Index: src/cpu/amd/car/cache_as_ram.inc === --- src/cpu/amd/car/cache_as_ram.inc(revision 6341) +++ src/cpu/amd/car/cache_as_ram.inc(working copy) @@ -294,11 +294,11 @@ xorl%edx, %edx /* * IMPORTANT: The two lines below can _not_ be written like this: -* movl $(REAL_XIP_ROM_BASE | MTRR_TYPE_WRBACK), %eax +* movl $(REAL_XIP_ROM_BASE | MTRR_TYPE_WRPROT), %eax * http://www.coreboot.org/pipermail/coreboot/2010-October/060855.html */ movl$REAL_XIP_ROM_BASE, %eax - orl $MTRR_TYPE_WRBACK, %eax + orl $MTRR_TYPE_WRPROT, %eax wrmsr movl$MTRRphysMask_MSR(1), %ecx wbToWp.patch Description: Binary data -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] [PATCH] cache type for BIOS flash memory should be WP-MMIO, not WB-MMIO
On Thu, Feb 10, 2011 at 12:32 PM, Scott Duplichan sc...@notabs.org wrote: According to AMD documentation, cache type WP should be used for execution from flash memory. Coreboot uses WB. While there is no noticeable performance difference between the two settings, use of WB can cause a problem for a jtag debugger. The attached patch changes AMD cache as ram setting for flash execution from WB to WP. Signed-off-by: Scott Duplichan sc...@notabs.org Index: src/cpu/amd/car/cache_as_ram.inc === --- src/cpu/amd/car/cache_as_ram.inc (revision 6341) +++ src/cpu/amd/car/cache_as_ram.inc (working copy) @@ -294,11 +294,11 @@ xorl %edx, %edx /* * IMPORTANT: The two lines below can _not_ be written like this: - * movl $(REAL_XIP_ROM_BASE | MTRR_TYPE_WRBACK), %eax + * movl $(REAL_XIP_ROM_BASE | MTRR_TYPE_WRPROT), %eax * http://www.coreboot.org/pipermail/coreboot/2010-October/060855.html */ movl $REAL_XIP_ROM_BASE, %eax - orl $MTRR_TYPE_WRBACK, %eax + orl $MTRR_TYPE_WRPROT, %eax wrmsr movl $MTRRphysMask_MSR(1), %ecx -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot Acked-by: Marc Jones marcj...@gmail.com -- http://se-eng.com -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
[coreboot] [commit] r6342 - trunk/src/cpu/amd/car
Author: sduplichan Date: Thu Feb 10 21:49:56 2011 New Revision: 6342 URL: https://tracker.coreboot.org/trac/coreboot/changeset/6342 Log: According to AMD documentation, cache type WP should be used for execution from flash memory. Coreboot uses WB. While there is no noticeable performance difference between the two settings, use of WB can cause a problem for a jtag debugger. The attached patch changes AMD cache as ram setting for flash execution from WB to WP. Signed-off-by: Scott Duplichan sc...@notabs.org Acked-by: Marc Jones marcj...@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 Thu Feb 10 09:49:57 2011 (r6341) +++ trunk/src/cpu/amd/car/cache_as_ram.inc Thu Feb 10 21:49:56 2011 (r6342) @@ -294,11 +294,11 @@ xorl%edx, %edx /* * IMPORTANT: The two lines below can _not_ be written like this: -* movl $(REAL_XIP_ROM_BASE | MTRR_TYPE_WRBACK), %eax +* movl $(REAL_XIP_ROM_BASE | MTRR_TYPE_WRPROT), %eax * http://www.coreboot.org/pipermail/coreboot/2010-October/060855.html */ movl$REAL_XIP_ROM_BASE, %eax - orl $MTRR_TYPE_WRBACK, %eax + orl $MTRR_TYPE_WRPROT, %eax wrmsr movl$MTRRphysMask_MSR(1), %ecx -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
[coreboot] inteltool: first preview for machine-readable output
inteltool: first preview for machine-readable output Signed-off-by: Anton Kochkov anton.koch...@gmail.com --- This is only for preview and discussion, it's still ugly and dont safe/clear. inteltool_machine_readable_first_preview.patch Description: Binary data -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] what was 'set' in struct io_info for?
* Mark Marshall mark.marsh...@csr.com [110210 11:52]: I found the same thing as you a while ago. The io_info structure in pnp.h is never referenced by the code, and it's purpose is never really defined anywhere. If you change the name to something else (just in the header file) the code still all compiles, so I'd say remove it. I also asked about it on the news group, but got no reply. Oh, we have a news group? -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] how Coreboot keeps the right offsets of the sections
* Peter Stuge pe...@stuge.se [110209 20:44]:
I checked the content of build/coreboot.rom and the last byte was
0x0a!! Which is written probably on the top of our EEPROM. Right?
but src/arch/i386/init/ldscript.ld specifies the last byte as 0x00!!
SECTIONS {
_ROMTOP = 0xfff0;
. = _ROMTOP;
.resetvector . : {
*(.reset)
. = 15 ;
BYTE(0x00);
}
}
Please help me with this puzzle. Thank you.
What is the concrete problem? You should not rule out that there are
binutils bugs. Just be happy that the reset vector has the right
opcodes.
cbfstool updates those memory regions.
--
coreboot mailing list: coreboot@coreboot.org
http://www.coreboot.org/mailman/listinfo/coreboot
[coreboot] Fwd: inteltool: first preview for machine-readable output
inteltool: first preview for machine-readable output
Signed-off-by: Anton Kochkov anton.koch...@gmail.com
---
This is only for preview and discussion, it's still ugly and dont safe/clear.
inteltool_machine_readable_first_preview.patch
Description: Binary data
#include stdio.h
#include inteltool.h
/*
char *xml_header = ?xml version=1.0 encoding=UTF-8? \
database xmlns=http://nouveau.freedesktop.org/; \
xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance; \
xsi:schemaLocation=http://nouveau.freedesktop.org/ rules-ng.xsd
*/
void machine_readable_printf(reg_t *reg) {
#ifdef XML
printf(register domain='%s' base='0x%x' offset='0x%x' size='%d' value='0x%x' name='%s' description='%s' /\n,
reg-domain, reg-base_addr, reg-offset, reg-size, reg-value, reg-name, reg-desc);
#endif
#ifndef XML
printf(domain: %s\n, reg-domain);
printf(base addr: 0x%x\n, reg-base_addr);
printf(offset: 0x%x\n, reg-offset);
printf(size: %d\n, reg-size);
printf(value: 0x%x\n, reg-value);
printf(name: %s\n, reg-name);
printf(description: %s\n, reg-desc);
#endif
}
--
coreboot mailing list: coreboot@coreboot.org
http://www.coreboot.org/mailman/listinfo/coreboot
[coreboot] inteltool: first preview for machine-readable output, fixes
inteltool: first preview for machine-readable output, fixes Signed-off-by: Anton Kochkov anton.koch...@gmail.com --- This is only for preview and discussion, it's still ugly and dont safe/clear. inteltool_machine_readable_second_preview.patch Description: Binary data -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
