Hi Jay,
Regarding the APIC ID problem, besides updating devicetree.cb with the
correct value do you think something else is required?
I have created a patch to make the APIC ID of devicetree.cb "dynamic" for
Denverton SoC, so it can be updated during runtime, see below:
diff --git a/src/device/device.c b/src/device/device.c
index 02209d9e..8852270b 100644
--- a/src/device/device.c
+++ b/src/device/device.c
@@ -50,6 +50,9 @@
#include
#endif
#include
+#if IS_ENABLED(CONFIG_SOC_INTEL_DENVERTON_NS)
+#include
+#endif
/** Linked list of ALL devices */
struct device *all_devices = &dev_root;
@@ -983,6 +986,16 @@ void dev_enumerate(void)
{
struct device *root;
+#if IS_ENABLED(CONFIG_SOC_INTEL_DENVERTON_NS)
+ /* Bootstrap processor Local APIC fixup */
+ struct device *t = dev_find_lapic(0xbeef);
+ if (t) {
+ unsigned int apic_id = lapicid();
+ printk(BIOS_INFO, "Denverton-NS BSP Local APIC fixup:
lapic=%u\n", apic_id);
+ t->path.apic.apic_id = apic_id;
+ }
+#endif
+
printk(BIOS_INFO, "Enumerating buses...\n");
root = &dev_root;
diff --git a/src/mainboard/intel/harcuvar/devicetree.cb
b/src/mainboard/intel/harcuvar/devicetree.cb
index 2e463c09..18654d42 100644
--- a/src/mainboard/intel/harcuvar/devicetree.cb
+++ b/src/mainboard/intel/harcuvar/devicetree.cb
@@ -45,7 +45,7 @@ chip soc/intel/denverton_ns
register "ipc3" = "0x" # IPC3
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
device domain 0 on
Thanks,
Sumo
On Fri, Apr 24, 2020 at 12:50 PM Jay Talbott <
jaytalb...@sysproconsulting.com> wrote:
> Nitin,
>
> We have encountered both of these issues and have corrected them in our own
> code base for a particular client. We are not in a position to upstream our
> changes, but I can tell you the source of each problem.
>
> 1. CPU frequency: For Denverton SKUs that do NOT support turbo mode (like
> the one you are using), the code does not properly enable speedstep. The
> code needs to be modified to correctly enable speedstep in the case of a
> SKU
> that does not support turbo mode.
>
> 2. Linux log: For Denverton SKUs with less than 16 cores, processor 0 is
> not
> guaranteed to have an APIC ID of 0 (as specified in devicetree). If you
> know the APIC ID of processor 0 and change devicetree to match, the problem
> you are seeing will go away. However, that's not a generalized solution, as
> the APIC ID can be different from SKU to SKU and, I believe, even between
> different parts of the same SKU (other than 16-core SKUs). So the code
> needs
> to be modified to use the actual APIC ID of processor 0 instead of the
> fixed
> value specified in devicetree.
>
> The original code developed by Intel was tested using a Harcuvar CRB with a
> 16-core SKU that supports turbo mode, and that's why neither of these
> issues
> were discovered in the original implementation.
>
> Without actually looking at the code, I believe both of these can be fixed
> in src/soc/intel/denverton_ns/cpu.c.
>
> - Jay
>
> Jay Talbott
> Principal Consulting Engineer
> SysPro Consulting, LLC
> 3057 E. Muirfield St.
> Gilbert, AZ 85298
> (480) 704-8045
> (480) 445-9895 (FAX)
> jaytalb...@sysproconsulting.com
> http://www.sysproconsulting.com
>
> > -Original Message-
> > From: nitin.ramesh.si...@gmail.com [mailto:nitin.ramesh.si...@gmail.com]
> > Sent: Friday, April 24, 2020 5:35 AM
> > To: coreboot@coreboot.org
> > Subject: [coreboot] Re: Regarding Intel CPU frequency (Intel Denverton
> > based)
> >
> > Hi Paul,
> >
> > As far as cpu init is concerned, I haven't modified the cpu
> initialization
> > sequence for the given board. The code is located under following sub-
> > folder "src/soc/intel/denverton_ns/cpu.c".
> >
> > The given CPU (CPU C3558) has 4 cores, and I am noticing the following
> logs
> > while booting up,
> > which I am trying to debug in parallel by inserting some delays.
> >
> > The wakeup fails for cpu (core) 1, but it continues and passes for 2,3,4.
> > So at the end, cores are getting recognized as CPU 0,2,3,4 respectively.
> >
> > There are few records available for the same sort of cases:
> > https://lore.kernel.org/lkml/0bc26e9524533c38fdbdc95eed2b1448@teksavv
> > y.com/T/
> >
> >
> > " 1.620879] x86: Booting SMP configuration:
> > [1.624592] node #0, CPUs: #1
> > [ 11.624587] smpboot: do_boot_cpu failed(-1) to wakeup CPU#1
> > [ 11.632919] #2 #3 #4
> > [ 11.636707] smp: Brought up 1 node, 4 CPUs
> > [ 11.640585] smpboot: Max logical packages: 2
> > [ 11.644585]
> > [ 11.644587] | NMI testsuite:
> > [ 11.644588]
> > [ 11.644590] remote IPI: ok |
> > [ 11.644623]local IPI: ok |
> > [ 11.644642]
> > [ 11.644644] Good, all 2 testcases passed! |
> >
