[PATCH]Change all type declaration to uintxx_t

[Hamo]

We mixed normal type declaration and uintxx_t in the definition of
CBFS headers before, this may confuse newbies who want to study CBFS
structure.

Signed-off-by: Yang Bai

Index: util/cbfstool/cbfs.h
===================================================================
--- util/cbfstool/cbfs.h	(revision 6534)
+++ util/cbfstool/cbfs.h	(working copy)
@@ -37,11 +37,11 @@
 } __attribute__ ((packed));

struct cbfs_stage {
-	unsigned int compression;
-	unsigned long long entry;
-	unsigned long long load;
-	unsigned int len;
-	unsigned int memlen;
+	uint32_t compression;
+	uint64_t entry;
+	uint64_t load;
+	uint32_t len;
+	uint32_t memlen;
 } __attribute__ ((packed));

#define PAYLOAD_SEGMENT_CODE	0x45444F43
@@ -51,12 +51,12 @@
 #define PAYLOAD_SEGMENT_ENTRY	0x52544E45

struct cbfs_payload_segment {
-	unsigned int type;
-	unsigned int compression;
-	unsigned int offset;
-	unsigned long long load_addr;
-	unsigned int len;
-	unsigned int mem_len;
+	uint32_t type;
+	uint32_t compression;
+	uint32_t offset;
+	uint64_t load_addr;
+	uint32_t len;
+	uint32_t mem_len;
 } __attribute__ ((packed));

struct cbfs_payload {

[Peter Stuge]

Thank you for the patch!

Hamo wrote:
> We mixed normal type declaration and uintxx_t in the definition of
> CBFS headers before, this may confuse newbies who want to study CBFS
> structure.
>
> Signed-off-by: Yang Bai

Acked-by: Peter Stuge

But I will wait a little to see if anyone else has comments, before I
commit this.

//Peter

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

[Scott Duplichan]

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.
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

[Hamo]

Ping...
Comments are welcome...

On Fri, Apr 22, 2011 at 1:00 AM, Peter Stuge  wrote:
> Thank you for the patch!
>
> Hamo wrote:
> > We mixed normal type declaration and uintxx_t in the definition of
> > CBFS headers before, this may confuse newbies who want to study CBFS
> > structure.
> >
> > Signed-off-by: Yang Bai
>
> Acked-by: Peter Stuge
>
> But I will wait a little to see if anyone else has comments, before I
> commit this.
>
> //Peter

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

[Marc Jones]

Hi Scott,
Thanks for this discussion.

On Thu, Apr 21, 2011 at 1:10 PM, Scott Duplichan  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:
> Windows 7 with SP1 and latest AMD video driver
> ubuntu-11.04-beta2-dvd-amd64.iso
> Windows Server 2003 x64 SP2
> Windows XP x64 SP2
>
> Live CD test only:
> linuxmint-9
> slax 6.12
> 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;
> 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
> Add device allocation for AP cores so that they will be reported and used by OS.
> Change cimx wrapper code so that OS shutdown function will work.
> Fix problems that cause incorrect programming and incorrect reporting of I/O APIC ID.
> Fix code that ignores MMCONF_BUS_NUMBER value and always uses 256.
> Change coreboot ACPI code to not report RTC as PIIX4 compatible.
> Add coreboot ACPI code to report PS/2 KB and mouse (ASRock only).
> Change coreboot ACPI code to report memory range A0000-Bffff as used.
> Change coreboot ACPI code to report proper FADT revision.
> Correct MP table reporting of APIC version.
> Program SB800 MiscCntrl earlier so first serial output is not garbled.
> Enable cache early to decrease coreboot execution time.
> Remove some unused HT code. Remove other unneeded code.
> Change seabios to use DMA instead of PIO for disk reads.
>
> Thanks,
> Scott

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

[Scott Duplichan]

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