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