Re: [coreboot] Patch: support for the Lenovo Thinkpad W520

[Pok Gu]

Hi, I'm not sure if the issue is related to power management. I'm using
Windows and an obvious issue is there is a yellow question mark for the
Dynamic Platform and Thermal Framework driver PCI\VEN_8086&DEV_0153. I
googled and found some chromebooks have the dptf.asl in their source, but
the thinkpads do not. Is this possible to be fix and how to do it?

Thanks
Pokgu

2016-11-08 3:20 GMT+08:00 Charlotte Plusplus :
> > I am new to coreboot. I could try to add the missing power management
> > states. But can I please ask for pointers and suggestions? What is
> > missing? Is there any documentation?
>
> Power management is done through ACPI.
> You'd need to figure out which ACPI functions are used by your operating

system and implement/fix them.

I am using Linux, Arch or Ubuntu. I don't really understand what you
mean there. I thought ACPI functions for power management were quite
standard. After reading my dmesg, I thought the linux kernel PSTATE
and CPUFREQ drivers were working fine. I need to do more tests with
powertop.

Is the power management state complete enough from coreboot standpoint
to work with the current linux kernel??

If not, could you point me to an Ivy Bridge board that has the most
complete implementation of power management, so I can use it as an
example?

I see some boards have cstates support, like
src/mainboard/lenovo/x200/cstates.c and after googling I found that
libreboot had "Higher battery life on GM45 (X200, T400, T500, R400)
due to higher cstates now being supported (thanks Arthur Heymans). C4
power states also supported. Higher battery life on i945 (X60, T60,
MacBook2,1) due to better CPU
C-state settings. (Deep C4, Dynamicl L2 shrinking, C2E).

Patch is in:
https://notabug.org/vimuser/libreboot/commit/89819c5ce3cd5c9
a38e9e7e817573dca52cbabcb

2016-11-08 3:20 GMT+08:00 Charlotte Plusplus :
> Hello
>
> On 11/6/16, Patrick Rudolph  wrote:
> > thanks for adding support for W520.
>
> My pleasure to help! As soon as I get the RAM issues fixed, I will try
> to add another mainboard. This was quite fun (reading the block
> diagram, making sure the ports match, etc)
>
> My only real issue at the moment is the RAM. I wish I could fix that
> soon, because I really need my laptop to work!! And since I replaced
> the CPU by one that is not supported in the bios, coreboot is my only
> option :-/
>
> I can't even boot reliably with more than 1 ram stick inserted :-(
> > Am 06.11.2016 um 09:33 schrieb Charlotte Plusplus:
> > Please use git (
> > https://www.coreboot.org/Development_Guidelines#How_to_contribute ) and
> > gerrit ( http://review.coreboot.org/#/q/status:open ) to upload your
> > patch. This allows easy reviewing and commenting, including an automatic
> > build for every change made.
>
> Sorry, I haven't used git yet ever, except to download code. I thought
> an archive would be ok. I will read your links and prepare a
> submission in the correct format. Thanks for the explanation!
> > Please note that I didn't test anything beyond DDR3-800. Some people
> > reported that DDR3-1866 is working.
> > Can you try to limit max frequency to DDR3-1333 or DDR3-1600 (using
> > max_mem_clock_mhz) and tell if it's working ?
>
> Currently doing that. I have read a bit more about memory, and
> apparently it could also be due to Intel XMP.
> > Native raminit is done in
> > coreboot/src/northbridge/intel/sandybridge/raminit.c
> > Please have a look at this file first. I don't think that there are SPD
> > issues, but there might be issues with frequencies of + DDR3-1600.
>
> I looked at that. I see you recently added XMP support:
> https://www.coreboot.org/pipermail/coreboot-gerrit/
> 2016-February/040779.html
>
> The sticks I am using are Corsair CMSX16GX3M2B2133C1, which use XMP.
> They are dual voltage, 1.35 and 1.5V
>
> Here is the output from decode-dimm run in the BIOS, and from
> coreboot. I can also add screenshots from memtest86 7.1, which showed
> the proper SPD settings and speed. Speed tests curves gave numbers
> compatibles with 2133, which is above DDR3-1600 as bios 1.36 did not
> restrict their speed. I did test them for over a day in memtest86 7.1.
>
> Since the sticks work reliably in the default bios as confirmed by
> memtest86 71, the problem seems to be coreboot specific: memtest86+
> 5.0 gives me various error that never showed up before. And with one
> stick, coreboot won't even boot.
>
> I don't understand how the existing raminit code could have issues
> with frequencies over DDR3-1600.
>
> My best guess is it may be due to using the CL10 profile (even if it
> is "correct") and ignoring the XMP CL11 profile, because I see the
> current code only select the 1st XMP profile, which could be the cause
> of the error if say the 2nd XMP profile is the one that should be
> used.
>
> It all looks innocent, but it is a serious error, as one 8G sticks
> gives me tens of thousands of errors in memtest86. I think this could
> cause serious data corruption :-(
> > > I am new to coreboot. I could try to add the missing power management
> > > states. But can I please ask for pointers and suggestions? What is
> > > missing? Is there any documentation?
> >
> > Power management is done through ACPI.
> > You'd need to figure out which ACPI functions are used by your
>
> operating  system and implement/fix them.
>
> I am using Linux, Arch or Ubuntu. I don't really understand what you
> mean there. I thought ACPI functions for power management were quite
> standard. After reading my dmesg, I thought the linux kernel PSTATE
> and CPUFREQ drivers were working fine. I need to do more tests with
> powertop.
>
> Is the power management state complete enough from coreboot standpoint
> to work with the current linux kernel??
>
> If not, could you point me to an Ivy Bridge board that has the most
> complete implementation of power management, so I can use it as an
> example?
>
> I see some boards have cstates support, like
> src/mainboard/lenovo/x200/cstates.c and after googling I found that
> libreboot had "Higher battery life on GM45 (X200, T400, T500, R400)
> due to higher cstates now being supported (thanks Arthur Heymans). C4
> power states also supported. Higher battery life on i945 (X60, T60,
> MacBook2,1) due to better CPU
> C-state settings. (Deep C4, Dynamicl L2 shrinking, C2E).
>
> Patch is in:
> https://notabug.org/vimuser/libreboot/commit/
> 89819c5ce3cd5c9a38e9e7e817573dca52cbabcb
>
> However, I could not need documentation or explainations for the
> numbers used (which differ in coreboot and libreboot)
>
> I have found http://www.intel.com/content/www/us/en/support/processors/
> 000006619.html
> but that is not super helpful.
>
> I would be happy to write proper power management support, but I would
> really appreciate some links to the documentation or some examples.
>
> A related question: how do I write a ACPI method to receive a call
> from userland and do something on coreboot side, like write a
> register? I would like to add a way to turn the NVidia GPU on and off
> from userland, for bumblebee or KVM with IOMMU GPU passthrugh.
> > I'm using BeagleBone Black for USBDEBUG.
>
> Ok, I will get one too. Thanks to Kyosti message I understand why I
> can't use my existing cable.
> > Once you got USBDEBUG working, please provide a full raminit log. It may
> > help to fix the remaining issue.
>
> Given the output from the script, I have selected port 1 This is the
> only external USB2 port in the laptop anyway!!
>
> The following PCI devices support a USB debug port (says lspci):
> 0000:00:1a.0 0000:00:1d.0
> The following PCI devices support a USB debug port (says the kernel):
> 0000:00:1a.0 0000:00:1d.0
> PCI device 0000:00:1a.0, USB bus 1, USB physical port 2
> PCI device 0000:00:1d.0, USB bus 2, USB physical port 2
> Currently connected high-speed devices:
> /:  Bus 02.Port 1: Dev 1, Class=root_hub, Driver=ehci-pci/3p, 480M
>     |__ Port 1: Dev 2, If 0, Class=Hub, Driver=hub/8p, 480M
>         |__ Port 4: Dev 3, If 12, Class=Communications, Driver=cdc_mbim,
> 480M
>         |__ Port 4: Dev 3, If 13, Class=CDC Data, Driver=cdc_mbim, 480M
> /:  Bus 01.Port 1: Dev 1, Class=root_hub, Driver=ehci-pci/3p, 480M
>     |__ Port 1: Dev 2, If 0, Class=Hub, Driver=hub/6p, 480M
>         |__ Port 2: Dev 5, If 0, Class=Mass Storage, Driver=usb-storage,
> 480M
>
> I have ordered the BBB. It may take a day or two to arrive. In the
> meantime, do you know any tool to dump the XMP profiles and check them
> manually?
>
> Thanks
> Charlotte