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
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...
Hello
On 11/6/16, Nico Huber nico.h@gmx.de 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!!
Hello
On 11/6/16, Patrick Rudolph siro@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-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