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)
JayTalbott@sysproconsulting.com
http://www.sysproconsulting.com

> -----Original Message-----
> From: nitin.ramesh.singh@gmail.com [mailto:nitin.ramesh.singh@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-leave@coreboot.org