Attention is currently required from: Michał Kopeć, Arthur Heymans.
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);
Can this be removed? BTW that comment about the io-apic ID does not match what the other code does a […]
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.
To view, visit change 59808. To unsubscribe, or for help writing mail filters, visit settings.