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

[Patrick Rudolph]

Hello Charlotte,

thanks for adding support for W520.

Am 06.11.2016 um 09:33 schrieb Charlotte Plusplus:
> Hello
>
> I am new to coreboot. I tried to run coreboot on my Thinkpad W520 to
> replace my Sandy Bridge CPU by a Ivy Bridge CPU, since several people
> reported it worked very well.
>
> Following their suggestions, I simply tried to flash a T520 image to
> save time. It didn't work at all. I was very angry I had wasted almost
> 2 days doing that. So I took the time to port coreboot to the Thinkpad
> W520 following the specs from
> http://kythuatphancung.vn/uploads/download/5165b_Wistron_Kendo-3_WS_-_10222-...
> and explore the issues I had (black screen, no boot)
>
> First, please find the patch attached to add support to the Thinkpad
> W520 mainboard. This patch is based on the T520 mainboard as the W520
> is very close. However, it needed romstage additions for ram init (cf
> p103 of the pdf)

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.
> I can now boot with various combinations of population of the Dimm
> slots, with the 4 slots all working, and the Dimm correctly identified
> by memtest
>
> However, I can not use my normal 8Gb Dimm sticks. One of them work,
> but 2x8Gb does not work most of the time. I get errors in memtest when
> I am lucky to boot. The sticks are DDR3L 2133 (bus speed 1066 MHz) and
> they worked fine with the bios 1.36: I tested the sticks for over 24h
> with memtest86 7.1 just a week ago to check how hot my old CPU would
> get.

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 ?
> After further investigation, if I run memtest86 7.1 on the bios 1.36,
> it shows the correct information and timings: tCL-tRCD-tRP-tRAS are
> 11-11-11-29, and the RAM is running at 1066MHz.
>
> If I run memtest86 on coreboot, it shows the RAM is running at 931MHz
> with timings 10-10-10-28. All this would be fine if it didn't cause
> errors on the memtest86! It looks like the SPD decoding is buggy, and
> instead of using the optimal configuration (11-11-11) coreboot picks
> the next one.

CL11 is optimal configuration for DDR3-2133, but not for DDR3-1866. The 
choosen CL value is correct.
> I would be happy to fix that but I don't know where to look. I
> correctly put max_mem_clock_mhz = 1066 in devicetree.cb so I don't
> understand. Can I hardcode timing settings? Is there any other place I
> should check for SPD issues?

No you can't hardcode timings.
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.
> There are some other W520 specific issues. I will try to prepare a
> wiki page to explain them. The big ones are:
> the bottom plastic case is conductive: if you add a J100 header,
>
> you must trim the ends or you will have shorts and the computer will
> not boot
> if you flash with a raspberry pi, you do not need external power.
>
> the 3V from pin 17 are enough. WP and HOLD can be left floating if you
> want. But you must insert all the pins at once, otherwise the W25Q64
> may not respond (it is weird, I see no logical reason, but it works
> reliably)
> native graphics initialization gave me video artifacts in seabios.
>
> Using the VGA bios fixed that
>
> On https://www.coreboot.org/Board:lenovo/t520 I see issues:
>      yellow USB port isn't powered in power-off state.
>      DisplayPort only connected to Discrete GPU
>      TPM. At the moment there is only basic support inside coreboot...
>      Boot time issues ( keyboard rest timeout )
>      ultrabay hot plug (event missing?)
>      some power management states missing
>
> 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.
> Also, in romstage I am not sure of :
>          /* Disable unused devices (board specific) */
>          RCBA32(FD) = 0x1ee51fe3;

You can dump the value stock lenovo bios sets at boot using the 
inteltool, that ships in coreboot's utils folder.
> The W520 is a bit different from a t420 and I think it may not be the
> same. How do I compute this number?
>
> Also, can I please ask for some help on USBDEBUG? I have a FT232R
> cable and enabled CONFIG_USBDEBUG_DONGLE_FTDI_FT232H. But I receive
> nothing. Is it necessary to have a FT232H? I looked at the code and it
> does not seem very specific. Having debug information would be helpful
> to fix these ram issues.

I'm using BeagleBone Black for USBDEBUG. I cannot tell if FT232R is 
working, too.
Please note that you have to use the USB port that has USBDEBUG 
capabilities. Other USB ports do not work. There's no fix rule where to 
find it.
Some thinkpads have it on the back, some are on the side. Please use 
lspci to identifiy it first.
For more information have a look at the wiki ( 
https://www.coreboot.org/EHCI_Debug_Port )
Once you got USBDEBUG working, please provide a full raminit log. It may 
help to fix the remaining issue.

Regards,
Patrick
> Charlotte

Patch: support for the Lenovo Thinkpad W520

[Nico Huber]

Hi,

On 06.11.2016 11:25, Patrick Rudolph wrote:
> Am 06.11.2016 um 09:33 schrieb Charlotte Plusplus:
> > Also, in romstage I am not sure of :
> >          /* Disable unused devices (board specific) */
> >          RCBA32(FD) = 0x1ee51fe3;
>
> You can dump the value stock lenovo bios sets at boot using the
> inteltool, that ships in coreboot's utils folder.
> > The W520 is a bit different from a t420 and I think it may not be the
> > same. How do I compute this number?

The function disable (FD) register is publicly documented [1, p.407].
As most times, the documentation isn't comprehensive. There are some
more bits explained in src/southbridge/intel/bd82x6x/pch.h:442, bit 27
is for the xHCI controller, bit 26 should always be set. Bits 5:12 btw.
don't apply to your PCH, they used to be for UHCI controllers. The only
bit in the number above I can't figure out is bit 28.

The FD register is actually configured dynamically based on the device-
tree (see src/southbridge/intel/bd82x6x/pch.c). So you don't need an
ugly constant there. You should only make sure that PCH_DISABLE_ALWAYS
is set. Some boards also disable the PCI bridge early so that this one
doesn't get probed (just an optimization). I'm not sure, why disabling
the bridge in the devicetree wouldn't suffice.

Nico

[1]
http://www.intel.com/content/dam/www/public/us/en/documents/datasheets/6-chi...

Patch: support for the Lenovo Thinkpad W520

[Charlotte Plusplus]

Hello

On 11/6/16, Nico Huber  wrote:
> http://www.intel.com/content/dam/www/public/us/en/documents/datasheets/6-chi...

Thanks a lot for the documentation the detailed  the explaination!

I will try to fix my devicetree.

Now if only I could  find something like that for power  management!!

Patch: support for the Lenovo Thinkpad W520

[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/89819c5ce3cd5c9a38e9e7e817573dc...

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