summaryrefslogtreecommitdiff
path: root/src/commonlib/mem_pool.c
diff options
context:
space:
mode:
authorFelix Held <felix-coreboot@felixheld.de>2022-02-09 22:07:29 +0100
committerKyösti Mälkki <kyosti.malkki@gmail.com>2022-02-10 10:23:22 +0000
commit49be1a93467e6bd1bd61ec7889c0a6f24e824288 (patch)
tree51d326d830754a3a6c0003914012d9811d156bd7 /src/commonlib/mem_pool.c
parentecdc714ef8eeb672c1125ce810aaf76d0752f520 (diff)
Revert "cpu/x86/lapic: Unconditionally use CPUID leaf 0xb if available"
This reverts commit ceaf959678905f44a54a116f37bd15acab5d4608. The AMD Picasso SoC doesn't support x2APIC and neither advertises the presence of its support via bit 21 in EAX of CPUID leaf 1 nor has the bit 10 in the APIC base address MSR 0x1b set, but it does have 0xd CPUID leaves, so just checking for the presence of that CPUID leaf isn't sufficient to be sure that EDX of the CPUID leaf 0xb will contain a valid APIC ID. In the case of Picasso EDX of the CPUID leaf 0xb returns 0 for all cores which causes coreboot to get stuck somewhere at the end of MP init. I'm not 100% sure if we should additionally check bit 21 in EAX of CPUID function 1 is set instead of adding back the is_x2apic_mode check. TEST=Mandolin with a Picasso SoC boots again. Signed-off-by: Felix Held <felix-coreboot@felixheld.de> Change-Id: If1e3c55ce2d048b14c08e06bb79810179a87993d Reviewed-on: https://review.coreboot.org/c/coreboot/+/61776 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Raul Rangel <rrangel@chromium.org> Reviewed-by: Tim Wawrzynczak <twawrzynczak@chromium.org> Reviewed-by: Christian Walter <christian.walter@9elements.com> Reviewed-by: Angel Pons <th3fanbus@gmail.com> Reviewed-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Diffstat (limited to 'src/commonlib/mem_pool.c')
0 files changed, 0 insertions, 0 deletions