[coreboot] Re: Regarding Intel CPU frequency (Intel Denverton based)
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 = _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 = _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
[coreboot] Re: Regarding Intel CPU frequency (Intel Denverton based)
Hi Jay, Thanks for your suggestion. I was able to figure out the given problem by inserting few debug prints under the file "cpu.c" , it seems the stepping mode is not getting set for given cpu, along with apic id coming out as 4. The observation matches with your comments as well. Once tested, I will update the given thread along with the results. Thanks, Nitin. On Fri, Apr 24, 2020 at 9:20 PM Jay Talbott 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! | > > [ 11.644646] - > > [ 11.644650] smpboot: Total of 4 processors activated (17600.00 > BogoMIPS) > > " > > > > Thanks for you help. > > > > Thanks, > > Nitin. > > ___ > > coreboot mailing list -- coreboot@coreboot.org > > To unsubscribe send an email to coreboot-le...@coreboot.org > > ___ coreboot mailing list -- coreboot@coreboot.org To unsubscribe send an email to coreboot-le...@coreboot.org
[coreboot] Re: Regarding Intel CPU frequency (Intel Denverton based)
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! | > [ 11.644646] - > [ 11.644650] smpboot: Total of 4 processors activated (17600.00 BogoMIPS) > " > > Thanks for you help. > > Thanks, > Nitin. > ___ > coreboot mailing list -- coreboot@coreboot.org > To unsubscribe send an email to coreboot-le...@coreboot.org ___ coreboot mailing list -- coreboot@coreboot.org To unsubscribe send an email to coreboot-le...@coreboot.org
[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/0bc26e9524533c38fdbdc95eed2b1...@teksavvy.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! | [ 11.644646] - [ 11.644650] smpboot: Total of 4 processors activated (17600.00 BogoMIPS) " Thanks for you help. Thanks, Nitin. ___ coreboot mailing list -- coreboot@coreboot.org To unsubscribe send an email to coreboot-le...@coreboot.org
[coreboot] Re: Regarding Intel CPU frequency (Intel Denverton based)
Dear Nitin, Am 24.04.20 um 11:53 schrieb nitin.ramesh.si...@gmail.com: I have tried different measures to increase the load on CPU, but still the frequency reflects the same value ie. 800Mz. My question is why this behavior is different w.r.t the one when system boots up with BIOS. If you have the vendor firmware working, please also attach the information when booted with that. When I boot with BIOS, I can see that frequency output stays at 2200Mhz. Do I need to enable some settings under the coreboot code related to turbo frequency e.t.c ? Please share your code, so people can take a look. Please find the lscpu dump as follows: Architecture: x86_64 CPU op-mode(s): 32-bit, 64-bit Byte Order: Little Endian Address sizes:39 bits physical, 48 bits virtual CPU(s): 5 On-line CPU(s) list: 0,2-4 Off-line CPU(s) list: 1 Why is one CPU off-line? Thread(s) per core: 1 Core(s) per socket: 4 Socket(s):1 Vendor ID:GenuineIntel CPU family: 6 Model:95 Model name: Intel(R) Atom(TM) CPU C3558 @ 2.20GHz Stepping: 1 CPU MHz: 800.000 No idea, about Atom processors, but on my system there are also two more lines. CPU max MHz: 3200, CPU min MHz: 500, […] Without knowing your code, people need to stab in the dark. If you cannot share your code, I recommend to get commercial support [1]. Kind regards, Paul [1]: https://www.coreboot.org/consulting.html ___ coreboot mailing list -- coreboot@coreboot.org To unsubscribe send an email to coreboot-le...@coreboot.org
