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 <[email protected]> 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) > [email protected] > http://www.sysproconsulting.com > > > -----Original Message----- > > From: [email protected] [mailto:[email protected]] > > Sent: Friday, April 24, 2020 5:35 AM > > To: [email protected] > > 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 -- [email protected] > > To unsubscribe send an email to [email protected] > >
_______________________________________________ coreboot mailing list -- [email protected] To unsubscribe send an email to [email protected]
