[PATCH]Change all type declaration to uintxx_t
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 <hamo.by@gmail.com> 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 {
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 <hamo.by@gmail.com>
Acked-by: Peter Stuge <peter@stuge.se> But I will wait a little to see if anyone else has comments, before I commit this. //Peter
Ping... Comments are welcome... On Fri, Apr 22, 2011 at 1:00 AM, Peter Stuge <peter@stuge.se> 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 <hamo.by@gmail.com>
Acked-by: Peter Stuge <peter@stuge.se>
But I will wait a little to see if anyone else has comments, before I commit this.
//Peter
-- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
-- """ Keep It Simple,Stupid. """ Chinese Name: 白杨 Nick Name: Hamo Homepage: http://hamobai.com/ GPG KEY ID: 0xA4691A33 Key fingerprint = 09D5 2D78 8E2B 0995 CF8E 4331 33C4 3D24 A469 1A33
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
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
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
participants (4)
-
Hamo -
Marc Jones -
Peter Stuge -
Scott Duplichan