Regarding Intel CPU frequency.

Hi,

I am using coreboot to boot Denverton cpu (CPU C3558) based board.

I can see that the cpu frequency is set to the correct value i.e. "2200 Mhz" under the coreboot logs.
.
"
CPU #3 initialized
bsp_do_flight_plan done after 146 msecs.
cpu: frequency set to 2200
"

Later when I check the frequency reading under linux (kernel version 4.19) , It comes out as 800 Mz:

model name      : Intel(R) Atom(TM) CPU C3558 @ 2.20GHz
stepping        : 1
microcode       : 0x24
cpu MHz         : 800.000

When I reprogram the board with BIOS, the cpu frequency gets reflected correctly (i.e. 2200 MHz) with the same kernel image.

I have also tried out the different Grub command line options like disabling the pstate, and idle state e.t.c, but the end result remains same.

Can anyone please provide me some suggestions. Is there is any cpu specific settings which needs to enabled under coreboot or with Intel-FSP ?

Thanks,
Nitin.

[Szafranski, MariuszX]

Hi Nitin,

Look`s like SpeedStepping in action - correct behavior while on idle.
Please put more stress on CPU and recheck - It should jump back to 2200

BR,
Mariusz

-----Original Message-----
From: [e-mail]  
Sent: czwartek, 23 kwietnia 2020 14:36
To: [e-mail]
Subject: [coreboot] Regarding Intel CPU frequency.

Hi,

I am using coreboot to boot Denverton cpu (CPU C3558) based board.

I can see that the cpu frequency is set to the correct value i.e. "2200 Mhz" under the coreboot logs.
.
"
CPU #3 initialized
bsp_do_flight_plan done after 146 msecs.
cpu: frequency set to 2200
"

Later when I check the frequency reading under linux (kernel version 4.19) , It comes out as 800 Mz:

model name      : Intel(R) Atom(TM) CPU C3558 @ 2.20GHz
stepping        : 1
microcode       : 0x24
cpu MHz         : 800.000

When I reprogram the board with BIOS, the cpu frequency gets reflected correctly (i.e. 2200 MHz) with the same kernel image.

I have also tried out the different Grub command line options like disabling the pstate, and idle state e.t.c, but the end result remains same.

Can anyone please provide me some suggestions. Is there is any cpu specific settings which needs to enabled under coreboot or with Intel-FSP ?

Thanks,
Nitin.
_______________________________________________
coreboot mailing list -- [e-mail] To unsubscribe send an email to [e-mail]
--------------------------------------------------------------
Intel Research and Development Ireland Limited
Registered in Ireland
Registered Office: Collinstown Industrial Park, Leixlip, County Kildare
Registered Number: 308263

This e-mail and any attachments may contain confidential material for the sole
use of the intended recipient(s). Any review or distribution by others is
strictly prohibited. If you are not the intended recipient, please contact the
sender and delete all copies.

Hi Mariusz,

I tried running the stress test to increase the load average, but still the frequency stays at 800Mhz.

Thanks,
Nitin.

[Alesandar Metodiev]

Hello Nitin,

Since you are running Linux, do you see anything interesting in the output
of dmesg? You could filter for warnings and errors by running "dmesg -l
warn,err", but it might be better to provide the full log.

Recently, I have started experiencing a similar issue with a i7-3720QM and
T420. The CPU is being stuck at 1,2GHz, which seems to be the lowest CPU
frequency detected by the kernel. Sometimes I feel like I have to
disconnect some peripherals, e.g. external monitor connected through a DP,
in order to fix it.
Changing the CPU governor from powersave to performance and vice-versa
typically works, but not in that case. I believe that my issue could be
related to the 65W PSU I have been using and I might have to upgrade at
least to 90W PSU.

Alesandar

On Thu, Apr 23, 2020 at 7:43 PM  wrote:
> Hi Mariusz,
>
> I tried running the stress test to increase the load average, but still
> the frequency stays at 800Mhz.
>
> Thanks,
> Nitin.
> _______________________________________________
> coreboot mailing list -- [e-mail]
> To unsubscribe send an email to [e-mail]

[Paul Menzel]

Dear Nitin,

Am 23.04.20 um 14:35 schrieb [e-mail]:
> I am using coreboot to boot Denverton cpu (CPU C3558) based board.

Nice. Are you going to send it upstream?
> I can see that the cpu frequency is set to the correct value i.e. "2200 Mhz" under the coreboot logs.
> .
> "
> CPU #3 initialized
> bsp_do_flight_plan done after 146 msecs.
> cpu: frequency set to 2200
> "
>
> Later when I check the frequency reading under linux (kernel version 4.19) , It comes out as 800 Mz:
>
> model name      : Intel(R) Atom(TM) CPU C3558 @ 2.20GHz
> stepping        : 1
> microcode       : 0x24
> cpu MHz         : 800.000
>
> When I reprogram the board with BIOS, the cpu frequency gets reflected correctly (i.e. 2200 MHz) with the same kernel image.
>
> I have also tried out the different Grub command line options like disabling the pstate, and idle state e.t.c, but the end result remains same.
>
> Can anyone please provide me some suggestions. Is there is any cpu specific settings which needs to enabled under coreboot or with Intel-FSP ?

I believe, that is expected [1]. Please paste the output of `lscpu` from 
the package *util-linux*.

Kind regards,

Paul

[1]: 
https://unix.stackexchange.com/questions/87522/why-do-cpuinfo-cur-freq-and-p...

HI Paul,

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.
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 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
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
BogoMIPS:             4400.00
Virtualization:       VT-x
L1d cache:            24K
L1i cache:            32K
L2 cache:             2048K
Flags:                fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx pdpe1gb rdtscp lm constant_tsc art arch_perfmon pebs bts rep_good nopl xtopology nonstop_tsc cpuid aperfmperf tsc_known_freq pni pclmulqdq dtes64 monitor ds_cpl vmx est tm2 ssse3 sdbg cx16 xtpr pdcm sse4_1 sse4_2 x2apic movbe popcnt tsc_deadline_timer aes xsave rdrand lahf_lm 3dnowprefetch cpuid_fault cat_l2 ssbd ibrs ibpb stibp tpr_shadow vnmi flexpriority ept vpid ept_ad fsgsbase tsc_adjust smep erms mpx rdt_a rdseed smap clflushopt intel_pt sha_ni xsaveopt xsavec xgetbv1 xsaves dtherm arat pln pts arch_capabilities

Thanks,
Nitin.

Regarding Intel CPU frequency (Intel Denverton based)

[Paul Menzel]

Dear Nitin,

Am 24.04.20 um 11:53 schrieb [e-mail]:
> 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,0000
CPU min MHz:                     500,0000

[…]

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

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/[e-mail]/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.

Regarding Intel CPU frequency (Intel Denverton based)

[Jay Talbott]

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
[phone]
[phone] (FAX)
[e-mail]
http://www.sysproconsulting.com
> -----Original Message-----
> From: [e-mail] [mailto:[e-mail]]
> Sent: Friday, April 24, 2020 5:35 AM
> To: [e-mail]
> 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 -- [e-mail]
> To unsubscribe send an email to [e-mail]

Regarding Intel CPU frequency (Intel Denverton based)

[Nitin Singh]

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.
> 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.
> 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
> [phone]
> [phone] (FAX)
> [e-mail]
> http://www.sysproconsulting.com
> > -----Original Message-----
> > From: [e-mail] [mailto:[e-mail]]
> > Sent: Friday, April 24, 2020 5:35 AM
> > To: [e-mail]
> > 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 -- [e-mail]
> > To unsubscribe send an email to [e-mail]

Regarding Intel CPU frequency (Intel Denverton based)

[Sumo]

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 <arch/ebda.h>
 #endif
 #include <timer.h>
+#if IS_ENABLED(CONFIG_SOC_INTEL_DENVERTON_NS)
+#include <cpu/x86/lapic.h>
+#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" = "0x00000000" # 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 <
[e-mail]> 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.
> 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.
> 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
> [phone]
> [phone] (FAX)
> [e-mail]
> http://www.sysproconsulting.com
> > -----Original Message-----
> > From: [e-mail] [mailto:[e-mail]]
> > Sent: Friday, April 24, 2020 5:35 AM
> > To: [e-mail]
> > 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 -- [e-mail]
> > To unsubscribe send an email to [e-mail]
>
> coreboot mailing list -- [e-mail]
> To unsubscribe send an email to [e-mail]

[Sumo]

Hi,

Looks like for this SoC turbo state is not available, so try the following
(enable speedstep regardless if turbo state is available or not, as you
need speedstep!) :

--- a/src/soc/intel/denverton_ns/cpu.c
+++ b/src/soc/intel/denverton_ns/cpu.c
@@ -71,11 +71,11 @@ static void denverton_core_init(struct device *cpu)
        enable_turbo();

/* Enable speed step. */
-       if (get_turbo_state() == TURBO_ENABLED) {
+//     if (get_turbo_state() == TURBO_ENABLED) {
                msr = rdmsr(IA32_MISC_ENABLE);
                msr.lo |= SPEED_STEP_ENABLE_BIT;
                wrmsr(IA32_MISC_ENABLE, msr);
-       }
+//     }
 }

King regards,
Sumo

Hi Sumo,

Thanks for your reply. 
As mentioned in my previous mail,.

There are two different fixes which are required for c3558.

a.) The SPEED STEP needs to enabled separately.
b.) APIC id has to be changed under the device tree.

Thanks,
Nitin.