Patchwork Update AMD Persimmon project to support Windows 7, XP, linux

login
register
about
Submitter Scott
Date 2011-04-21 19:10:09
Message ID <DF9883C3F0C54A4ABDBAFC086F972F43@m3a78>
Download mbox | patch
Permalink /patch/2901/
State New
Headers show

Comments

Scott - 2011-04-21 19:10:09
I have a set of AMD persimmon patches for improved OS support.
The changes should easily port to ASRock E350M1 and AMD Inagua.

These operating systems were tested and can install from a DVD and boot from hard disk:
1) Windows 7 with SP1 and latest AMD video driver
2) ubuntu-11.04-beta2-dvd-amd64.iso
3) Windows Server 2003 x64 SP2
4) Windows XP x64 SP2

Live CD test only:
1) linuxmint-9
2) slax 6.12
3) nimblex 2010 beta

Here is a summary of the changes. Change #1 is essential, but it is a work around
and not a true fix. Before submitting the patches, we should decide what to do
about item #1. Here is a past discussion of the problem. While the past problem
occurred only when a PCI video card was added, the current problem happens with
no added cards:
http://www.coreboot.org/pipermail/coreboot/2010-October/061320.html

Here is the work around I am testing with. It limits device memory
allocation to the area below MMCONF_BASE. The method works, but
wastes address space:


1) Work around coreboot resource allocation problem that causes
overlap of PCIe MMIO space and graphics MMIO space.
2) Add device allocation for AP cores so that they will be reported and used by OS.
3) Change cimx wrapper code so that OS shutdown function will work.
4) Fix problems that cause incorrect programming and incorrect reporting of I/O APIC ID.
5) Fix code that ignores MMCONF_BUS_NUMBER value and always uses 256.
6) Change coreboot ACPI code to not report RTC as PIIX4 compatible.
7) Add coreboot ACPI code to report PS/2 KB and mouse (ASRock only).
8) Change coreboot ACPI code to report memory range A0000-Bffff as used.
9) Change coreboot ACPI code to report proper FADT revision.
10) Correct MP table reporting of APIC version.
11) Program SB800 MiscCntrl earlier so first serial output is not garbled.
12) Enable cache early to decrease coreboot execution time.
13) Remove some unused HT code. Remove other unneeded code.
14) Change seabios to use DMA instead of PIO for disk reads.

Thanks,
Scott
Marc Jones - 2011-05-03 05:13:45
Hi Scott,
Thanks for this discussion.

On Thu, Apr 21, 2011 at 1:10 PM, Scott Duplichan <scott@notabs.org> wrote:
> I have a set of AMD persimmon patches for improved OS support.
> The changes should easily port to ASRock E350M1 and AMD Inagua.
>
> These operating systems were tested and can install from a DVD and boot from hard disk:
> 1) Windows 7 with SP1 and latest AMD video driver
> 2) ubuntu-11.04-beta2-dvd-amd64.iso
> 3) Windows Server 2003 x64 SP2
> 4) Windows XP x64 SP2
>
> Live CD test only:
> 1) linuxmint-9
> 2) slax 6.12
> 3) nimblex 2010 beta
>
> Here is a summary of the changes. Change #1 is essential, but it is a work around
> and not a true fix. Before submitting the patches, we should decide what to do
> about item #1. Here is a past discussion of the problem. While the past problem
> occurred only when a PCI video card was added, the current problem happens with
> no added cards:
> http://www.coreboot.org/pipermail/coreboot/2010-October/061320.html
>
> Here is the work around I am testing with. It limits device memory
> allocation to the area below MMCONF_BASE. The method works, but
> wastes address space:
> Index: src/devices/pci_device.c
> ===================================================================
> --- src/devices/pci_device.c  (revision 6483)
> +++ src/devices/pci_device.c  (working copy)
> @@ -259,6 +259,7 @@
>      if (attr == PCI_BASE_ADDRESS_MEM_LIMIT_32) {
>         /* 32bit limit. */
>         resource->limit = 0xffffffffUL;
> +        resource->limit = CONFIG_MMCONF_BASE_ADDRESS - 1;
>      } else if (attr == PCI_BASE_ADDRESS_MEM_LIMIT_1M) {
>         /* 1MB limit. */
>         resource->limit = 0x000fffffUL;
>
>
> 1) Work around coreboot resource allocation problem that causes
> overlap of PCIe MMIO space and graphics MMIO space.

Why isn't this covered by the bus resource allocation for MMCONF? I
think that this should handle the situation. How does the overlap
happen?

static void cpu_bus_read_resources(device_t dev)
{
    printk(BIOS_DEBUG, "\nFam14h - cpu_bus_read_resources.\n");

#if CONFIG_MMCONF_SUPPORT
    struct resource *resource = new_resource(dev, 0xc0010058);
    resource->base = CONFIG_MMCONF_BASE_ADDRESS;
    resource->size = CONFIG_MMCONF_BUS_NUMBER * 4096*256;
    resource->flags = IORESOURCE_MEM | IORESOURCE_RESERVE |
        IORESOURCE_FIXED | IORESOURCE_STORED |  IORESOURCE_ASSIGNED;
#endif
}

Thanks,
Marc


> 2) Add device allocation for AP cores so that they will be reported and used by OS.
> 3) Change cimx wrapper code so that OS shutdown function will work.
> 4) Fix problems that cause incorrect programming and incorrect reporting of I/O APIC ID.
> 5) Fix code that ignores MMCONF_BUS_NUMBER value and always uses 256.
> 6) Change coreboot ACPI code to not report RTC as PIIX4 compatible.
> 7) Add coreboot ACPI code to report PS/2 KB and mouse (ASRock only).
> 8) Change coreboot ACPI code to report memory range A0000-Bffff as used.
> 9) Change coreboot ACPI code to report proper FADT revision.
> 10) Correct MP table reporting of APIC version.
> 11) Program SB800 MiscCntrl earlier so first serial output is not garbled.
> 12) Enable cache early to decrease coreboot execution time.
> 13) Remove some unused HT code. Remove other unneeded code.
> 14) Change seabios to use DMA instead of PIO for disk reads.
>
> Thanks,
> Scott
>
>
> --
> coreboot mailing list: coreboot@coreboot.org
> http://www.coreboot.org/mailman/listinfo/coreboot
>
Scott - 2011-05-04 06:58:41
Marc Jones wrote:

]> 1) Work around coreboot resource allocation problem that causes
]> overlap of PCIe MMIO space and graphics MMIO space.
]
]Why isn't this covered by the bus resource allocation for MMCONF? I
]think that this should handle the situation. How does the overlap
]happen?

Hello Marc,

I think the short answer is the mmconf range is added to a device that
is skipped by the bus resource allocation code. The mmconf range is
added to APIC_CLUSTER:0, which is not looked at by the resource
allocation code. Here is what I found a while back:

  Why does the current code for handling fixed resources allow the mmconf
  space to get allocated to a PCI device? Function avoid_fixed_resources
  calls function constrain_resources, which recursively searches the
  device tree for fixed io and memory resources. The ioapic fixed memory
  address is found and avoided during the recursive search because this
  southbridge device is below the level where the search starts. On the
  other hand, the mmconf fixed resource is added from the northbridge code,
  and falls under 'APIC_CLUSTER: 0'. This device is not part of the search
  for two reasons. One is that it is not at or below 'pci_domain 0' in the
  device tree. Another reason is that its type is APIC_CLUSTER and not
  PCI_DOMAIN.

The last patch I sent includes a better workaround. To avoid modification
of the resource allocation code, mmconf is moved from e0000000 to f8000000.
This is the solution I attempted originally, but had to set aside until a 
couple of mmio problems were fixed.

Thanks,
Scott

Patch

Index: src/devices/pci_device.c
===================================================================
--- src/devices/pci_device.c  (revision 6483)
+++ src/devices/pci_device.c  (working copy)
@@ -259,6 +259,7 @@ 
      if (attr == PCI_BASE_ADDRESS_MEM_LIMIT_32) {
         /* 32bit limit. */
         resource->limit = 0xffffffffUL;
+        resource->limit = CONFIG_MMCONF_BASE_ADDRESS - 1;
      } else if (attr == PCI_BASE_ADDRESS_MEM_LIMIT_1M) {
         /* 1MB limit. */
         resource->limit = 0x000fffffUL;