[coreboot] Re: libgfxinit: Panel Backlight with Apollo Lake (Broxton)

[Nico Huber]

Hello Wolfgang,

On 21.04.20 16:50, Wolfgang Kamp - datakamp wrote:
> I found out that the panel backlight enable function in libgfxinit for 
> Broxton platform (Intel x5-E3940) will not work for me.
> The Backlight Enabling Sequence Description in the Intel document Doc Ref # 
> IHD-OS-BXT-Vol 7-05.17 says:
> 1. Set frequency and duty cycle in BLC_PWM_FREQ Frequency and BLC_PWM_DUTY 
> Duty Cycle.
> 2. Enable PWM output and set polarity in BLC_PWM_CTL PWM Enable and PWM 
> Polarity.

> It is also necessary to set Bit 2 in the PP_CONTROL register to "1" to enable 
> Backlight Power.

did you confirm this additional step by testing? I have only tested
one board so far. It uses the second set of panel registers and I can
control the PWM output just fine _without_ touching PP_CONTROL.

>
> In "hw-gfx-gma-panel.adb" in the function Backlight_On only 
> BXT_BLC_PWM_CTL_ENABLE will be set and PP_CONTROL setting is excluded through 
> the If statement.
> Also I can't find any call of the Set_Backlight function and I'm missing the 
> setting of the PWM frequency divider in this function. Most panels will work 
> with 200Hz PWM.

`libgfxinit` is not designed as firmware and expects that board/panel
specific settings are already performed by the firmware. I have just
pushed a patch [1] to add the missing configuration in coreboot. It
needs to be configured in the devicetree.

Hope that helps,
Nico

[1] https://review.coreboot.org/c/coreboot/+/40694
___
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 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.
>
> 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: CBFS pointer problem with SeaBios and Apollo Lake platform

[Matt DeVillier]

On Fri, Apr 24, 2020 at 4:59 AM Wolfgang Kamp - datakamp 
wrote:

> Hello Matt,
>
>
>
> Thank you for your response. I see that SeaBIOS still can’t handle the
> FMAP structure.
>
> The pointer depends on the FMAP layout and this is different to chromium
> devices.
>
> For the UP squared board I did not find any other solution than to set
> CONFIG_CBFS_LOCATION=0xFFFC and
>

this is for the upsquared board? looking at the fmap, I'm not sure how you
calculated that CBFS location


> to patch the 16M coreboot.rom image at address 0x00EBEFFE with 0x44.
>
> Then SeaBIOS will find the CBFS to load the APL VGA BIOS ROM.
>

what does patching 0x00EBEFFE with 0x44 do exactly?


>
>
>
>
> Kind regards,
>
> Wolfgang
>
> *Von:* Matt DeVillier [mailto:matt.devill...@gmail.com]
> *Gesendet:* Donnerstag, 23. April 2020 17:35
> *An:* Wolfgang Kamp - datakamp 
> *Cc:* coreboot@coreboot.org
> *Betreff:* [coreboot] Re: CBFS pointer problem with SeaBios and Apollo
> Lake platform
>
>
>
> Apollolake should work with:
>
> CONFIG_CBFS_LOCATION=0xfffb1000
>
> # CONFIG_HARDWARE_IRQ is not set
>
>
>
> That's what I use for SeaBIOS as a legacy boot payload on ChromeOS
> devices, but the CBFS address will be the same if using upstream coreboot
>
>
>
> regards,
> Matt
>
>
>
> On Thu, Apr 23, 2020 at 3:24 AM Wolfgang Kamp - datakamp <
> wmk...@datakamp.de> wrote:
>
> Hello,
>
>
>
> Am I correct that the problem still exists that SeaBios can’t find the
> CBFS in apl platform?
>
>
>
> Kind regards,
>
> Wolfgang Kamp
>
> ___
> 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)

[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
(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: CBFS pointer problem with SeaBios and Apollo Lake platform

[Felix Singer]

Hi,

On Thu, 2020-04-23 at 08:15 +, Wolfgang Kamp - datakamp wrote: 
> Am I correct that the problem still exists that SeaBios can’t find
> the CBFS in apl platform?

I used this as workaround: 
https://review.coreboot.org/c/coreboot/+/32327

It requires that you put the CBFS at the end of your partitions.

-- 
Best regards / Mit freundlichen Grüßen

Felix Singer


signature.asc
Description: This is a digitally signed message part
___
coreboot mailing list -- coreboot@coreboot.org
To unsubscribe send an email to coreboot-le...@coreboot.org

[coreboot] Re: Planning the next coreboot release

[Patrick Rudolph]

Hi Jonathan,
I'll have a look, but I cannot help on the IIO stuff, as we still don't
have access to Intel's confidential documents.

Kind Regards,
Patrick Rudolph
B.Sc. Electrical Engineering
System Firmware Developer


9elements Agency GmbH, Kortumstraße 19-21, 44787 Bochum, Germany
Email:  patrick.rudo...@9elements.com
Phone:  +49 234 / 68 94 188

Sitz der Gesellschaft: Bochum
Handelsregister: Amtsgericht Bochum, HRB 13207
Geschäftsführung: Eray Basar, Sebastian Deutsch


Am Fr., 24. Apr. 2020 um 05:36 Uhr schrieb Jonathan Zhang (Infra) via
coreboot :

> Hi Patrick,
>
> Your help and dedication is much appreciated!
>
> As we (FB and its partners) successfully finished bring-up of coreboot on
> CooperLake-SP based
> 1 socket platform, we are shifting our focus to exclusively on
> Cooperlake-SP based platfroms, away
> from using Skylake-SP based TiogaPass as the feature development vehicle.
>
> This timing works well with the planned coreboot release.  We have a
> number of SKX-SP
> platform related changes in the pipeline, we will try our best to work
> with the community to get them
> merged, then we will run a test pass, and we could report the status to
> the community (such as
> document what works and what further works are needed in
> Documentation/mainboard).
>
> Many features (in particular smbios and BMC interaction) have been added
> to TiogaPass OCP
> platform, also TiogaPass can be bought off-the-shelf from Wiwynn. If we
> are lucky enough to have
> an IBV taking care of SKX-SP FSP maintenance, the industry at large will
> have an end to end open source
> firmware solution for SKX-SP based platform. Such solution is not 100%
> open source due to FSP, ME, etc,
> but it is a huge step forward.
>
> The patch sets we would like to merge in for the planned releases are:
> a. https://review.coreboot.org/c/coreboot/+/40500 .
> b. https://review.coreboot.org/q/author:wiwynn.com+status:open
> c. https://review.coreboot.org/c/coreboot/+/40481
>
> Thank you,
> Jonathan
>
> On 4/22/20, 11:09 AM, "Patrick Georgi via coreboot" <
> coreboot@coreboot.org> wrote:
>
> Hi everybody,
>
> it's that time of year again: we should look into cutting a
> release. Not because there's anything noteworthy that we should bring
> out (although there certainly is), but because we have a 6-monthly
> cadence of giving our tree a new number and pushing out tarballs and
> press releases.
>
> I plan to do the release on or shortly after May 11, and
> this announcement is in accordance to the process detailed on
> https://doc.coreboot.org/releases/checklist.html, so we're at the
> "~2 weeks prior to release" point right now.
>
> As such, there are a number of things I ask of you (all of you
> subscribed to the list, but since you're reading this mail, yes,
> I mean you, personally!):
>
> 1. If you have anything big that you want to get in before the release,
> it's on you to maintain the changes responsibly and responsively so
> that it all works out in time. I'll gladly help coordinate things
> but I'm not interested in last-minute heroics, so get in touch with
> me ASAP.
>
> 2. Please try to postpone riskier refactorings and the like until after
> the release (unless they're ready to land in the next few days), so
> that people have a solid foundation to test their hardware on. Which
> gets us to the next point:
>
> 3. Please test your coreboot-supported gear if you can, report and/or
> fix issues, and upload fresh reports to the board-status repo. While
> we have no quality requirement for releases - they're _really_ only
> about giving the tree a new number, a release is a good opportunity
> to verify that what we have in the tree is still functional, with
> only limited work required to pin-point new issues (bisections since
> 4.11 should take 12 steps or less at this time).
>
> 4. Please check the preliminary release notes in
> Documentation/releases/coreboot-4.12-relnotes.md and add whatever
> happened since 4.11 that you think is noteworthy. If in doubt, push
> a change to gerrit and see what your fellow developers think about it.
>
>
> Thanks,
> Patrick Georgi
> --
> Google Germany GmbH, ABC-Str. 19, 20354 Hamburg
> Registergericht und -nummer: Hamburg, HRB 86891, Sitz der
> Gesellschaft: Hamburg
> Geschäftsführer: Paul Manicle, Halimah DeLaine Prado
>
>
> ___
> 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 . ramesh . singh]

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)

[Paul Menzel]

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

[coreboot] Re: CBFS pointer problem with SeaBios and Apollo Lake platform

[Wolfgang Kamp - datakamp]

Hello Matt,

Thank you for your response. I see that SeaBIOS still can’t handle the FMAP 
structure.
The pointer depends on the FMAP layout and this is different to chromium 
devices.
For the UP squared board I did not find any other solution than to set 
CONFIG_CBFS_LOCATION=0xFFFC and
to patch the 16M coreboot.rom image at address 0x00EBEFFE with 0x44.
Then SeaBIOS will find the CBFS to load the APL VGA BIOS ROM.


Kind regards,
Wolfgang
Von: Matt DeVillier [mailto:matt.devill...@gmail.com]
Gesendet: Donnerstag, 23. April 2020 17:35
An: Wolfgang Kamp - datakamp 
Cc: coreboot@coreboot.org
Betreff: [coreboot] Re: CBFS pointer problem with SeaBios and Apollo Lake 
platform

Apollolake should work with:

CONFIG_CBFS_LOCATION=0xfffb1000
# CONFIG_HARDWARE_IRQ is not set

That's what I use for SeaBIOS as a legacy boot payload on ChromeOS devices, but 
the CBFS address will be the same if using upstream coreboot

regards,
Matt

On Thu, Apr 23, 2020 at 3:24 AM Wolfgang Kamp - datakamp 
mailto:wmk...@datakamp.de>> wrote:
Hello,

Am I correct that the problem still exists that SeaBios can’t find the CBFS in 
apl platform?

Kind regards,
Wolfgang Kamp
___
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.

[nitin . ramesh . singh]

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.
___
coreboot mailing list -- coreboot@coreboot.org
To unsubscribe send an email to coreboot-le...@coreboot.org

[coreboot] Re: Regarding Intel CPU frequency.

[Paul Menzel]

Dear Nitin,


Am 23.04.20 um 14:35 schrieb nitin.ramesh.si...@gmail.com:


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-proc-cpuinfo-report-different-numbers

___
coreboot mailing list -- coreboot@coreboot.org
To unsubscribe send an email to coreboot-le...@coreboot.org

[coreboot] Re: Regarding Intel CPU frequency.

[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 -- 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