Attention is currently required from: Michał Żygowski, Michał Kopeć.
1 comment:
File src/northbridge/amd/pi/00730F01/northbridge.c:
/*
* APIC ID calculation is tightly coupled with AGESA v5 code.
* This calculation MUST match the assignment calculation done
* in LocalApicInitializationAtEarly() function.
* And reference GetLocalApicIdForCore()
*
* Apply APIC enumeration rules
* For systems with >= 16 APICs, put the IO-APICs at 0..n and
* put the local-APICs at m..z
*
* This is needed because many IO-APIC devices only have 4 bits
* for their APIC id and therefore must reside at 0..15
*/
if ((node_nums * core_max) + ioapic_count >= 0x10) {
lapicid_start = (ioapic_count - 1) / core_max;
lapicid_start = (lapicid_start + 1) * core_max;
printk(BIOS_SPEW, "lpaicid_start = 0x%x ", lapicid_start);
}
u32 apic_id = (lapicid_start * (i/modules + 1)) + ((i % modules) ? (j + (siblings + 1)) : j);
printk(BIOS_SPEW, "node 0x%x core 0x%x apicid = 0x%x\n",
i, j, apic_id);
struct device *cpu = add_cpu_device(cpu_bus, apic_id, enable_node);
if (cpu)
amd_cpu_topology(cpu, i, j);
The comment describes what is done typically in the large core count systems. And yes the code assigns the IOAPICs at CONFIG_MAX_CPUS + n (n is the number of IOAPIC). This apic calculation could probably be removed since there is at most 8 CPUs in fam 16h models 30-3fh supported by the binaryPI, for the rest of the code IDK, would have to look deeper. Anway this is subject to change in another patch.
Well both the parallel mp code as this code here add lapic devices to the linked list so regardless of the ioapic it's good to make sure these things won't be conflicting.
To view, visit change 59808. To unsubscribe, or for help writing mail filters, visit settings.