[coreboot] [PATCH] make I/O APIC IDs and processor APIC IDs unique (asus/m4a785-m)

[Scott Duplichan]

]-----Original Message-----
]From: coreboot-bounces at coreboot.org [mailto:coreboot-bounces at coreboot.org] On Behalf Of Marc Jones
]Sent: Wednesday, September 15, 2010 12:36 PM
]To: coreboot at coreboot.org
]Subject: Re: [coreboot] [PATCH] make I/O APIC IDs and processor APIC IDs unique (asus/m4a785-m)
]
]On Wed, Sep 15, 2010 at 4:53 AM, Peter Stuge <peter at stuge.se> wrote:
]> Scott Duplichan wrote:
]>> Assigning a unique id to the SB ioapic is not as simple as choosing
]>> the next biggest available value, because the ioapic is
]>> traditionally a 4-bit value.
]>
]> Did you look at how the K8 support does this? I think this may
]> already be handled there, maybe it's a useful reference.
]>
]
]K8 and Fa10 have the same option to lift the BSP APIC ID, The code
]looks stale and I don't think that it would be enough for FAM10. For
]K8 you only need to move one ID to make room for the SB (2*8). For
]FAM10, you need to lift more than just the BSP.
]
]
]>
]>> +++ src/southbridge/amd/sb700/sb700_sm.c      (working copy)
]>> +   #if (CONFIG_APIC_ID_OFFSET == 0 && CONFIG_MAX_CPUS * CONFIG_MAX_PHYSICAL_CPUS < 16)
]> ..
]
]Have you tried setting CONFIG_APIC_ID_OFFSET?

I didn't even test this method because AMD recommends starting the processor
local apic ids at zero if possible. That is for better compatibility with
some older operating systems I believe. I think none of the coreboot AMD
projects currently support >= 16 cores, so processor apic IDs can start at
zero for the time being. But even if this lifting method resolves the ID
conflict, it does not solve the problem of passing the io apic id to the
os through acpi. Currently the acpi tables use a hard-coded value of 2 for
the io apic id. So there are two problems: ID conflict, and ACPI reporting.

]>
]>> +++ src/mainboard/asus/m4a785-m/acpi_tables.c (working copy)
]>> +   #if (CONFIG_APIC_ID_OFFSET == 0 && CONFIG_MAX_CPUS * CONFIG_MAX_PHYSICAL_CPUS < 16)
]>> +   #define IO_APIC_ID (CONFIG_MAX_CPUS * CONFIG_MAX_PHYSICAL_CPUS)
]>> +   #else
]>> +   #define IO_APIC_ID 0
]>> +   #endif
]>
]> Is there a header file in north or southbridge that could be used to
]> store the logic?
]
]I agree, this doesn't belong in acpi code.  IO_APIC_ID could be used
]in the sb700_sm.c as well.

It seems like a generic sysconf structure is needed. sb700_sm.c could
use such a structure to pass the io apic id base to acpi_tables.c.

]Marc
]
]-- 
]http://se-eng.com