The solution to this problem has already been discussed here. You just need to replace in the file devicetree.cb "lapic 4" to "lapic 0xbeef".
*device cpu_cluster 0 on #device lapic 4 on end device lapic 0xbeef on end #NOTE: correct Local APIC ID is set in in dev_enumerate() end*
This works for two cores (C3338), quad cores (C3538), eight cores, twelve cores, and 16 cores - I've tested this.
пн, 16 авг. 2021 г. в 19:45, Jay Talbott JayTalbott@sysproconsulting.com:
Unfortunately, for the Denverton SoC (C3000 series), the APIC ID of the first core is not always the same. For 16-core SKUs, it’s always 0, but for SKUs with a lower number of cores, it may be a different number. It’s also possible (but not confirmed) that for a particular SKU (other than 16-core SKUs), it might not be consistent between parts. The solution is to basically ignore the value in devicetree and use the actual APIC ID from the first core.
*From:* Sumo [mailto:email@example.com] *Sent:* Monday, August 16, 2021 9:15 AM *To:* Nico Huber *Cc:* Дмитрий Понаморев; Coreboot *Subject:* [coreboot] Re: A different lapic number in devicetree.cb needed for CPU with the same SKU and steping (Intel Atom C3538).
have you tried omitting the `device lapic` line from the devicetree?
I have tested this, in this case Linux shows only one processor core. Therefore the 'device lapic' line is really needed...
I can submit that Local APIC Fixup patch to gerrit but I'm not sure if this is really the best solution.
On Wed, Oct 7, 2020 at 6:35 PM Nico Huber firstname.lastname@example.org wrote:
have you tried omitting the `device lapic` line from the devicetree? It would only matter if there is configuration associated with it, but I can't see anything like that for `intel/harcuvar`.
What happens is that this `device lapic` line in the devicetree becomes an entry in a list at runtime. This list is later filled with the actual cores present. If any of the actual cores has the same APIC id as given in the devicetree, no additional entry is added for this core. However if none of the actual cores has that id, the original entry is left blindly in the list, causing coreboot to report the spurious, fifth core.
On 07.10.20 21:27, email@example.com wrote:
Thank you so much Javier Galindo!
Sorry for not finding this case myself ... I checked it on the motherboard with lapic #4 - everything works as it
Tomorrow I'll check it on the motherboard with lapic #0. I wish I could understand how this magic works :)! lapic 0xbeef .....
It's kind of a wildcard that gets replaced with the number found in the hardware. Nothing too special but probably unnecessary.
Nico _______________________________________________ coreboot mailing list -- firstname.lastname@example.org To unsubscribe send an email to email@example.com