[coreboot] Patch: support for the Lenovo Thinkpad W520

Tue Nov 8 11:58:08 CET 2016

I remembered Windows 7 was not well supported under coreboot (sometimes it
boots sometimes not). A fresh install of MSDN Windows 10 can at least boot
everytime. Could you try if Windows 10 works?

I don't known how to fix the usb issues. So I cc the community maillist.

2016-11-08 14:54 GMT+08:00 Charlotte Plusplus <pluspluscharlotte at gmail.com>:

> I have tried to boot a windows 7 to explore these issues, it didn't work.
>
> I may have residual problems. I noticed I also have USB3 not working while
> I have in the devicetree:
>
> device pci 1c.6 on end # PCIe Port #7 USB 3.0 only W520
>
> I checked the specs, it is the correct address. However, it doesn't work,
> and in cbmem I can see the port is being disabled :-(
>
>
> On Mon, Nov 7, 2016 at 9:36 PM, Pok Gu <pokgoo002 at gmail.com> wrote:
>
>> 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 <pluspluscharlotte at gmail.com
>> >:
>>
>>
>> >> 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 <pluspluscharlotte at gmail.com
>> >:
>>
>>> Hello
>>>
>>> On 11/6/16, Patrick Rudolph <siro at das-labor.org> 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-Febr
>>> uary/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/89819c5ce3cd5c9
>>> a38e9e7e817573dca52cbabcb
>>>
>>> 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/w
>>> ww/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
>>>
>>> --
>>> coreboot mailing list: coreboot at coreboot.org
>>> https://www.coreboot.org/mailman/listinfo/coreboot
>>>
>>
>>
>> --
>> coreboot mailing list: coreboot at coreboot.org
>> https://www.coreboot.org/mailman/listinfo/coreboot
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20161108/7aec505d/attachment.html>