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 <pluspluscharlo...@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 <pokgoo...@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 <pluspluscharlo...@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 <pluspluscharlo...@gmail.com >> >: >> >>> Hello >>> >>> On 11/6/16, Patrick Rudolph <s...@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@coreboot.org >>> https://www.coreboot.org/mailman/listinfo/coreboot >>> >> >> >> -- >> coreboot mailing list: coreboot@coreboot.org >> https://www.coreboot.org/mailman/listinfo/coreboot >> > >
-- coreboot mailing list: coreboot@coreboot.org https://www.coreboot.org/mailman/listinfo/coreboot
