coreboot November 2016

coreboot@coreboot.org

66 participants
187 discussions

Re: [coreboot] native video init question
by ron minnich 20 Nov '16

20 Nov '16

I'm working from memory here, I wrote this code over 4 years ago, but I did find out there's lots of ways to get a dark panel or other issues you mention. And it's very hard sometimes to get it all right. It's also easy to have it almost working with parameters that are so wrong that getting back to a dark screen is a good sign! To add to the fun, vendors can ship any number of panels with a given laptop that are very different in behavior. We had to put 4 panel types into the falco configuration and try to figure out which one it was. One thing you can try that sometimes works, if you have serial, is to do NO video initialization at all and let X11 do it instead. I did a lot of debug this way and on ivybridge it works pretty well. You can take the normal boot path and, again assuming you have serial, start Xorg and just see if you get a lightup. If so, well, you've got a starting point: you can put debug prints in the driver to show each and everything it does to the panel, and compare to coreboot. There may be a surprise in there somewhere. The timing is extremely tricky sometimes. You could also consider running the vga bios in the 'safe' mode (i.e. the emulator in coreboot) and tracing all the IOs. Sometimes you can learn something that way. I also wonder if you could use the code Nico put in for the graphics init. I have no idea if it's possible, Nico could tell us. But that code looks really thorough and might work better.

1 0

Re: [coreboot] using overlayfs to have several coreboot dev envs
by Trammell Hudson 20 Nov '16

20 Nov '16

On Sun, Nov 13, 2016 at 03:34:49PM -0500, Charlotte Plusplus wrote: > With the cross compiling tool chain, coreboot takes 1G. If you are a bit > short on space, or if you want to save writes to your SSD, instead of > having multiple copies of the coreboot source folder, I have found out > overlayfs is very practical. [...] An alternative is to use the "external build" option if you're building for multiple targets with different .config files for each. It isn't quite as simple as the Linux kernel's kbuild O= syntax, but works fairly well. I have three main builds that I'm alternating between (x230, chell and qemu) so I've created three directories and have a .config for each stored in a top-level config directory. From the coreboot directory I can modify the configs and build them independently: make obj=./x230 DOTCONFIG=./config/x230 menuconfig make obj=./x230 DOTCONFIG=./config/x230 -j 8 The builds will share the same cross build tree, so the actual build output is only 64M per configuration. Also note that any paths to external files like bzImage and initrd in each buld's .config are relative to the coreboot tree, not the output directory. -- Trammell

2 1

Re: [coreboot] native video init question
by Peter Stuge 20 Nov '16

20 Nov '16

Charlotte Plusplus wrote: > The number match, the EDID is correct, and the panel is properly detected. > But the internal display still shows a garbled picture with stretched > letters. I'm out of ideas to get native video init working. Correct timing/sequencing is just as important as correct numbers. //Peter

2 1

Re: [coreboot] TINT payload major update!
by Mike Banon 20 Nov '16

20 Nov '16

Hi Martin, here is my new TINT commit - https://review.coreboot.org/#/c/17507/ (had to abandon a previous one) I fixed all the problems that were noticed by you, and other reviewers. Also: [*] added check for archive before downloading it [*] added SHA-1 checksum verification of the downloaded archive for TINT payload [*] added USB keyboard support to nvramcui as well [*] made a correct logic for USB enabling: #ifndef CONFIG_LP_USB #define CONFIG_LP_USB 0 <--- earlier it was 1, now it is 0, because - if for some board CONFIG_LP_USB is not defined, USB should not be initialized then #endif #if IS_ENABLED(CONFIG_LP_USB) usb_initialize(); #endif [*] excluded nvramcui from kconfig_lint search (just like tint has been excluded) --> for the same purpose The only problem now is, because our kconfig_lint are different, my commit conflicts with yours here: https://review.coreboot.org/#/c/17443/1 . Very sorry for that, I'm new to gerrit and made many mistakes before doing it right. This latest TINT commit should be correct and final, I really hope Mike On Wed, Nov 16, 2016 at 6:52 AM, Martin Roth <gaumless(a)gmail.com> wrote: > Hi Mike, I'll take care of it. Thanks for pointing it out. > > Martin > > On Tue, Nov 15, 2016 at 3:21 PM, Mike Banon <mikebdp2(a)gmail.com> wrote: >> Finally I found a way to commit this (after a few more changes, also >> attaching a final version to this letter just in case) - >> https://review.coreboot.org/#/c/17439/1 >> >> Problem with this commit is a false positive error generated by >> lint.lint-stable-008-kconfig : >> >> #!!!!! Error: IS_ENABLED() used on unknown value CONFIG_LP_USB at >> payloads/external/tint/libpayload_tint.patch:378. >> # 1 errors >> >> despite that CONFIG_LP_USB is always defined by: >> #ifndef CONFIG_LP_USB >> #define CONFIG_LP_USB 1 >> #endif >> and also in libpayload. >> >> Please tell, how to suppress this error, or maybe there is a >> workaround to make it disappear? >> >> Best regards, >> Mike Banon >> >> On Mon, Nov 14, 2016 at 11:09 PM, Mike Banon <mikebdp2(a)gmail.com> wrote: >>> Please scroll down to the end of letter to download the attachments >>> ("Non-text attachment was scrubbed..."), don't copy paste (because >>> Google ate my tabs and broke the files) >>> >>> >>> On Mon, Nov 14, 2016 at 10:50 PM, Mike Banon <mikebdp2(a)gmail.com> wrote: >>>> There are (were) five problems with a TINT payload: >>>> 1) It is outdated: version 0.03b vs the latest 0.04+nmu1 . Two buffer >>>> overflows have been fixed since that, as well as some other >>>> improvements >>>> 2) When you press 'p', "Paused - Press any key to continue" message is >>>> not displayed - because there are no "refresh()" functions between >>>> "out_printf" and "while" waiting cycle >>>> 3) When you lose or quit, PC does not reboot - could only reboot by >>>> the power button, really inconvenient. Meanwhile, coreinfo and >>>> nvramcui payloads have a working reboot function "outb(0x6, 0xcf9);" >>>> which could be borrowed >>>> 4) libpayload_tint.patch is bloated - could reduce it in half for the >>>> same effect (with a few changes to Makefile) >>>> 5) Standard USB keyboard does not work, only internal PS2-like >>>> keyboard works (at least it is this way on my G505S laptop). The same >>>> USB keyboard works for me in coreinfo thanks to "#if >>>> IS_ENABLED(CONFIG_LP_USB) usb_initialize(); #endif" right in the >>>> beginning of "int main(void)" function at coreinfo.c file >>>> >>>> I have already fixed all these problems by making the changes to >>>> Makefile and libpayload_tint.patch , but I have no idea how to make a >>>> pull request to coreboot repository and don't have any commit rights! >>>> So if you have the commit rights, please review the changes and commit >>>> these updated versions of "coreboot/payloads/external/tint/Makefile" >>>> and "coreboot/payloads/external/tint/libpayload_tint.patch" - files >>>> attached below. Whoever commits them first could take a credit for my >>>> work >>>> >>>> Best regards, >>>> Mike Banon >>>> >>> >>> >> >> -- >> coreboot mailing list: coreboot(a)coreboot.org >> https://www.coreboot.org/mailman/listinfo/coreboot

1 0

Re: [coreboot] Powersavings: 8W of difference between bios and coreboot
by Alexander Couzens 20 Nov '16

20 Nov '16

Hi Charlotte, here are some description of the EC in your board. Don't know how much you already know. The Thinkpad has 2 EC controller. 1x Thinker 1x H8S (W530 has a SMSC chip). The ectool dump only shows a buffer, which both side(host+ec) can use to communicate. The ectool usually talks to the H8S and not to the Thinker. There is a way to community to the Thinker using different I/O address. --------- |Chipset| --------- | | LPC | ------- | H8S | ------- | | SPI | --------- |Thinker| --------- best, lynxis -- Alexander Couzens mail: lynxis(a)fe80.eu jabber: lynxis(a)fe80.eu mobile: +4915123277221 gpg: 390D CF78 8BF9 AA50 4F8F F1E2 C29E 9DA6 A0DF 8604

1 0

Re: [coreboot] native video init question
by Charlotte Plusplus 20 Nov '16

20 Nov '16

So I used inteltool, checked to compute the values, then even tried with autoport. The number match, the EDID is correct, and the panel is properly detected. But the internal display still shows a garbled picture with stretched letters. I'm out of ideas to get native video init working. register "gfx.did" = "{ 0x80000100, 0x80000240, 0x80000410, 0x80000410, 0x00000005 }" register "gfx.use_spread_spectrum_clock" = "1" register "gfx.link_frequency_270_mhz" = "1" register "gpu_dp_b_hotplug" = "4" register "gpu_dp_c_hotplug" = "4" # Enable DisplayPort Hotplug with 6ms pulse register "gpu_dp_d_hotplug" = "0x06" # Enable Panel as LVDS and configure power delays register "gpu_panel_port_select" = "0" # LVDS register "gpu_panel_power_cycle_delay" = "6" register "gpu_panel_power_up_delay" = "300" # T1+T2: 30ms register "gpu_panel_power_down_delay" = "300" # T5+T6: 30ms register "gpu_panel_power_backlight_on_delay" = "3000" # T3: 300ms register "gpu_panel_power_backlight_off_delay" = "3000" # T4: 300ms #0x0c6014: 0x89046004 register "gpu_cpu_backlight" = "0x00001155" register "gpu_pch_backlight" = "0x11551155" Log: PCI: 00:00.0 init ... Disabling PEG12. Disabling PEG11. Disabling PEG10. Disabling PEG60. Disabling PEG IO clock. Set BIOS_RESET_CPL CPU POWER_UNIT: 8 CPU TDP: 440 CPU TDP: 55 Watts CPU POWER_LIMIT HI: 33318 CPU POWER_LIMIT LO: 14451128 CPU POWER_LIMIT NOMINAL HI: 0 CPU POWER_LIMIT NOMIAL LO: 30 PCI: 00:00.0 init finished in 6714 usecs PCI: 00:02.0 init ... GT Power Management Init IVB GT2 35W Power Meter Weights GT Power Management Init (post VBIOS) Initializing VGA without OPROM. EDID: 00 ff ff ff ff ff ff 00 06 af ed 11 00 00 00 00 00 16 01 04 90 22 13 78 02 21 35 ad 50 37 aa 24 11 50 54 00 00 00 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 7c 38 80 d4 70 38 32 40 3c 30 aa 00 58 c1 10 00 00 18 7c 38 80 7e 72 38 32 40 3c 30 aa 00 58 c1 10 00 00 18 00 00 00 fe 00 41 55 4f 0a 20 20 20 20 20 20 20 20 20 00 00 00 fe 00 42 31 35 36 48 54 4e 30 31 2e 31 20 0a 00 81 Extracted contents: header: 00 ff ff ff ff ff ff 00 serial number: 06 af ed 11 00 00 00 00 00 16 version: 01 04 basic params: 90 22 13 78 02 chroma info: 21 35 ad 50 37 aa 24 11 50 54 established: 00 00 00 standard: 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 descriptor 1: 7c 38 80 d4 70 38 32 40 3c 30 aa 00 58 c1 10 00 00 18 descriptor 2: 7c 38 80 7e 72 38 32 40 3c 30 aa 00 58 c1 10 00 00 18 descriptor 3: 00 00 00 fe 00 41 55 4f 0a 20 20 20 20 20 20 20 20 20 descriptor 4: 00 00 00 fe 00 42 31 35 36 48 54 4e 30 31 2e 31 20 0a extensions: 00 checksum: 81 Manufacturer: AUO Model 11ed Serial Number 0 Made week 0 of 2012 EDID version: 1.4 Digital display 6 bits per primary color channel Digital interface is not defined Maximum image size: 34 cm x 19 cm Gamma: 220% Check DPMS levels Supported color formats: RGB 4:4:4 First detailed timing is preferred timing Established timings supported: Standard timings supported: Detailed timings Hex of detail: 7c3880d4703832403c30aa0058c110000018 Detailed mode (IN HEX): Clock 144600 KHz, 158 mm x c1 mm 0780 07bc 07ec 0854 hborder 0 0438 0442 044c 046a vborder 0 -hsync -vsync Did detailed timing Hex of detail: 7c38807e723832403c30aa0058c110000018 Detailed mode (IN HEX): Clock 144600 KHz, 158 mm x c1 mm 0780 07bc 07ec 09fe hborder 0 0438 0442 044c 046a vborder 0 -hsync -vsync Hex of detail: 000000fe0041554f0a202020202020202020 ASCII string: AUO Hex of detail: 000000fe004231353648544e30312e31200a ASCII string: B156HTN01.1 Checksum Checksum: 0x81 (valid) bringing up panel at resolution 1920 x 1080 Borders 0 x 0 Blank 212 x 50 Sync 48 x 10 Front porch 60 x 10 Spread spectrum clock Dual channel Polarities 1, 1 Data M1=10108272, N1=8388608 Link frequency 270000 kHz Link M1=280785, N1=524288 Pixel N=7, M1=22, M2=8, P1=2 Pixel clock 144489 kHz waiting for panel powerup panel powered up On Thu, Nov 17, 2016 at 11:54 PM, Charlotte Plusplus < pluspluscharlotte(a)gmail.com> wrote: > Ok, I found a way to get usable inteltool results: I ran inteltool -f on a > borrowed W530 that has the exact same CPU 3940XM, the exact same integrated > GPU (HD4000) and the exact same screen as my W520. Only the southbridge is > different: QM77 instead of QM67 > > Now I will have to check the documentation of the registers to use this > information to get native video init working. > > Is there anything else I should run before I have to give it back?? > > Charlotte > > On Wed, Nov 16, 2016 at 10:06 PM, Charlotte Plusplus < > pluspluscharlotte(a)gmail.com> wrote: > >> Hello >> >> Yes I have included this patch 17389 in my build. Unfortunately, it gave >> me the raminit logs failures attached before. I will try to see what's >> stored in the MRC cache. I would like to make the ram init conditional on >> the boot status, which means having 2 mrc cache: one for normal, one for >> fallback. This way, I flush one and debug ram issues with less fear >> (because the W520 I am porting coreboot to is my main laptop) >> >> For native video, I have 2 memory segments: >> Memory at f1400000 (64-bit, non-prefetchable) [size=4M] >> Memory at e0000000 (64-bit, prefetchable) [size=256M] >> >> I guess I should always read from the first one. >> >> It seems to work, but I am always getting the same result at different >> addresses >> $ ./iotools mem_read32 f14C7200 >> 0xf000ff53 >> $ ./iotools mem_read32 f14C7201 >> 0xf000ff53 >> $ ./iotools mem_read32 f14C7202 >> 0xf000ff53 >> $ ./iotools mem_read32 f14C7203 >> 0xf000ff53 >> $ ./iotools mem_read32 f1400000 >> 0xf000ff53 >> >> Here is the romstage that I tried using with non native raminit. It gave >> me no video, but besides that it goes to payload and work fine. I wonder if >> I should declare the HD4000 in the peidata. It seems the video was just not >> initialized at all. >> >> For brightness in the payloads, if it cause security issues, I guess I >> can do without it. >> >> Charlotte >> >> >> >> On Wed, Nov 16, 2016 at 7:32 AM, Nico Huber <nico.huber(a)secunet.com> >> wrote: >> >>> On 16.11.2016 06:08, Charlotte Plusplus wrote: >>> > Hello >>> > >>> > On Tue, Nov 15, 2016 at 6:46 PM, Nico Huber <nico.h(a)gmx.de> wrote: >>> > >>> >> I've seen a garbled image, too, lately. When I built with native >>> >> raminit by chance but with a completely different gfx init code >>> >> (3rdparty/libgfxinit). So it might still be some problem in the >>> >> raminit. This was also on an Ivy Bridge system with four DIMMs, >>> >> btw. I suspected that the native raminit just wasn't tested in that >>> >> configuration. >>> >> >>> > >>> > Interesting, I noticed some patterns with raminit too. Most of my >>> problems >>> > with the native raminit happen with 4x 8Gb DIMMS. The more sticks I >>> have, >>> > the less likely native ram training is to succeed. I have logged a few >>> of >>> > the failed attempt in case anyone else is interested (attached). >>> > >>> > Basically, the training can fail several times with the exact same >>> > parameters that it later succeeds with. Also, failure is a function of >>> > speed. All the attempts I have done but not attached can be summed up >>> like >>> > this: failure of the native ram training is also more likely with a MCU >>> > over 666MHz. But whenever the raminit succeed, the memory is stable in >>> > memtests (I did several passes to check. >>> > >>> > Now that I can use Windows 10 with Coreboot, I decided to experiment a >>> bit >>> > more. First, I tried changing the SPD settings with Thaiphoon Burner. >>> The >>> > sticks I have advertise they supported both 1.35 and 1.5V profiles >>> (SPD: >>> > 006=03) which I feared might cause issue. Changing that to 1.5V only >>> (SPD: >>> > 006=00) did not help, even if it did help with another computer that I >>> > borrowed to do some comparisons with (I was afraid my sticks were at >>> fault) >>> > >>> > Then I tried manually filling XMP profile 1 with known to be working >>> values >>> > (either published, or found during native raminit training). It seemed >>> to >>> > help but the results were inconsistent. Between my tests for different >>> > value, I was clearing the MRC cache. >>> > >>> > Then I had a weird idea: what if the ram training or the MRC cache >>> clearing >>> > was the cause of the problem? I changed my protocol to do: clear cache, >>> > train after changing the SPD/MCU frequency/etc, then when it succeeds >>> > disable the MRC cache clearing hook, and do a few reboots or a power >>> off >>> > before doing the memtest. And this was sufficient to get stabilility at >>> > 666Mhz and frequencies above without having to tweak the SPD anymore >>> (like >>> > adding some latency to the detected values) >>> > >>> > Currently 800Mhz is validated, I haven't tested 933 MHz because ram >>> > training success seems to be a probability that goes down with the >>> > frequency, and pressing on the power button every time it fails quickly >>> > gets boring! >>> > >>> > I have no way to prove that, but I believe that the ram training by >>> itself >>> > interferes with the stability of the RAM, or that there is some non >>> > deterministic part in the code. I don't know why or how, it's a lot of >>> code >>> > that I haven't read in detail, but it's what my tests suggests. I would >>> > love to compare these results to ones the blob raminit would give. But >>> blob >>> > raminit causes video issues. So I'm trying to focus on native video >>> init >>> > first, in case it helps me to use mrc.bin. >>> >>> I can't recall if Patrick or you mentioned this already, there's a rela- >>> ted patch up for review: >>> https://review.coreboot.org/#/c/17389/ >>> Do you have that already applied locally? >>> >>> > >>> > Well, I don't see any setting that could really break something. The >>> >> code might just be buggy. I'll go through the settings anyway, taking >>> >> src/mainboard/lenovo/t520/devicetree.cb as example: >>> >> >>> > >>> > I used this code as a source, as I figured the screen was likely to be >>> the >>> > same. >>> > >>> > That's about ACPI, let's not care (the last appendix in the ACPI spec >>> if >>> >> you want to have a look). >>> >> >>> > >>> > I will check that too because Fn Home and Fn end (brightness + and -) >>> don't >>> > work in memtest86, even if they work in linux and windows >>> >>> That's expected. coreboot does the brightness control through ACPI. >>> And ACPI is something for bloated OSs not for payloads (it comes with >>> a whole bunch of code including a byte-code interpreter). >>> >>> A workaround would be to do the EC event handling in SMM until ACPI >>> takes over. But that's usually discouraged as SMM has security issues. >>> So we want as little code as possible in SMM. >>> >>> > >>> > >>> >> Those are real register settings, you can dump the whole GMA MMIO >>> >> space with `inteltool -f` (hoping that your system doesn't hang). The >>> >> registers are described in [1, chapter 2.4]. >>> >> >>> > >>> > Sorry, but it did hang. I couldn't even ssh to it. Any alternative to >>> get >>> > the info? >>> >>> Look up the base address of the gfx MMIO space: >>> $ lspci -vs 00:02.0 | grep Memory >>> or >>> $ head -1 /sys/devices/pci0000:00/0000:00:02.0/resource >>> >>> Grab a copy of iotools: https://github.com/adurbin/iotools.git >>> You should be able to read single registers with the mem_read32 command: >>> # ./iotools mem_read32 $((base+register_offset)) >>> >>> Nico >>> >>> >> >

1 0

Support for student project
by Tobias Wegner 20 Nov '16

20 Nov '16

Dear developers of Coreboot. I am a student at the University of Bremen, Germany. In our recently started project 'badUSB' our team researches for new ways to detect and prevent attacks through reverse engineered USB devices-firmware (so called 'badusb'). One of our main security targets is to stop boot sector attacks. Therefore we are looking forward to find solutions based on opensource coreboot. Right now we try to decide on supported hardware and were hoping to get help directly from people who already faced the problem. We saw your vendor list but are especially interested in information about tips for developing. Are there any systems that were easier to build for? Maybe you got suggestions for development environments (virtual maschines you used?) or warnings to beware us from some pitfalls. With best regards Tobias Wegner

3 2

Re: [coreboot] Powersavings: 8W of difference between bios and coreboot
by Charlotte Plusplus 20 Nov '16

20 Nov '16

Quick update: I tried experimenting on the w530 to find which ACPI call turns off the dGPU. bbswitch reported it was: \_SB.PCI0.LPC.EC.PUBS._OFF however, in tests with powertop it failed to show any improvement. A lot of information was found on https://github.com/Lekensteyn/acpi-stuff/blob/master/notes.txt, with further discussion on https://github.com/Bumblebee-Project/bbswitch/issues/112 The following acpi call takes the power consumption of a W530 in the default bios from 20W to 13W, and is reported to also work on the W520 by http://hybrid-graphics-linux.tuxfamily.org/index.php?title=ACPI_calls \_SB.PCI0.PEG.VID._DSM {0xF8,0xD8,0x86,0xA4,0xDA,0x0B,0x1B,0x47,0xA7,0x2B,0x60,0x42,0xA6,0xB5,0xBE,0xE0} 0x100 0x1A {0x1,0x0,0x0,0x3} \_SB.PCI0.PEG.VID._PS3 _PS3 puts the card in D3 mode (what I was trying to do with setpci before) but not in totally off model. The card is truly off when lspci shows rev ff, and that is done by the _DSM. powertop then reports about 12W, so _PS3 shaves 7W and _DSM shaves 1W which is just what I may need to fix by extra consumption of 8W Apparently with the default bios some fields in the DSDT also change when Optimus is enabled, cf http://www.insanelymac.com/forum/topic/273621-guide-os-x-lion-on-thinkpad-w… : OperationRegion (MNVS, SystemMemory, 0xBAF9D018, 0x1000) // optimusOperationRegion (GNVS, SystemMemory, 0xBAF3FE18, 0x01A6) // optimus OperationRegion (MNVS, SystemMemory, 0xBF79D018, 0x1000) // discreteOperationRegion (GNVS, SystemMemory, 0xBF73FE18, 0x01A6) // discrete I could confirm that on the extracted DSDT. I have yet to make sense of the content of MVNS and GNVS, and the consequences of the field changes. Switching between \_SB.PCI0.PEG.VID._PS3 and \_SB.PCI0.PEG.VID._PS0 ( with echo $i > /proc/acpi/call) changes the power consumption reliably by 7W, so I think this controls the Nvidia power I am now trying to replicate these results on coreboot, by studying the EC dump with ectool -d before and after switching the power. No success so far. I tried acpi_debug but the logs were not helpful. In case anyone is interested, here is the relevant part of the ACPI tables. Please read https://github.com/Lekensteyn/acpi-stuff/blob/master/notes.txt for a possible interpretation: Device(VID) { Name(_ADR, 0x00) OperationRegion(VPCG, PCI_Config, 0x00, 0x0100) Field(VPCG, DWordAcc, NoLock, Preserve) { Offset(0x2C), //Offset(44), VSID, 32, Offset(0x70), //Offset(112), VPWR, 8, } Name(_S3D, 0x03) Name(DGOS, 0x00) Method(_INI, 0, NotSerialized) { \VUPS(0x02) Store(\VCDL, VQDL) Store(\VCDC, VQDC) Store(\VCDT, VQD0) Store(\VCDD, VQD1) If(ISOP()) { \VHYB(0x04, 0x01) } } Method(_PS0, 0, NotSerialized) { If(ISOP()) { If(DGOS) { \VHYB(0x02, 0x00) Sleep(0x64) \VHYB(0x00, 0x01) Sleep(0x0A) Store(0x01, \_SB.PCI0.LPC.PCRS) Store(0x01, \_SB.PCI0.LPC.PCRQ) Sleep(0x64) \VHYB(0x02, 0x01) Sleep(0x01) \VHYB(0x08, 0x01) Store(0x0A, Local0) Store(0x32, Local1) While(Local1) { Sleep(Local0) If(\LCHK(0x01)) { Break } Decrement(Local1) } Store(0x00, \_SB.PCI0.LPC.PCRQ) \VHYB(0x04, 0x00) \SWTT(0x01) Store(Zero, DGOS) } Else { If(LNotEqual(VSID, 0x21D117AA)) { \VHYB(0x04, 0x00) } } \VHYB(0x09, \_SB.PCI0.PEG.VID.HDAS) } } Method(_PS1, 0, NotSerialized) { NoOp } Method(_PS2, 0, NotSerialized) { NoOp } Method(_PS3, 0, NotSerialized) { If(ISOP()) { If(LEqual(\_SB.PCI0.PEG.VID.OMPR, 0x03)) { \SWTT(0x00) \VHYB(0x08, 0x00) Store(0x0A, Local0) Store(0x32, Local1) While(Local1) { Sleep(Local0) If(\LCHK(0x00)) { Break } Decrement(Local1) } \VHYB(0x02, 0x00) Sleep(0x64) \VHYB(0x00, 0x00) Store(One, DGOS) Store(0x02, \_SB.PCI0.PEG.VID.OMPR) } } } Method(_STA, 0, NotSerialized) { Return(0x0F) } Method(_DSM, 4, NotSerialized) { If(\CMPB(Arg0, ToUUID("A486D8F8-0BDA471B-A72B6042A6B5BEE0")})) { Return(NVOP(Arg0, Arg1, Arg2, Arg3)) } } Name(_IRC, 0x00) OperationRegion(ATRP, SystemMemory, \ATRB, 0x00010000) Field(ATRP, AnyAcc, Lock, Preserve) { IDX0, 262144, IDX1, 262144, } Method(_ROM, 2, Serialized) { If(LGreaterEqual(Arg0, 0x8000)) { Return(GETB(Subtract(Arg0, 0x8000), Arg1, IDX1)) } If(LGreater(Add(Arg0, Arg1), 0x8000)) { Subtract(0x8000, Arg0, Local0) Subtract(Arg1, Local0, Local1) Store(GETB(Arg0, Local0, IDX0), Local3) Store(GETB(0x00, Local1, IDX1), Local4) Concatenate(Local3, Local4, Local5) Return(Local5) } Return(GETB(Arg0, Arg1, IDX0)) } Method(GETB, 3, Serialized) { Multiply(Arg0, 0x08, Local0) Multiply(Arg1, 0x08, Local1) CreateField(Arg2,Local0,Local1,TBF3) Return(TBF3) } Method(VSWT, 0, NotSerialized) { If(\WVIS) { Store(\VEVT(0x07), Local0) } Else { Store(\VEVT(0x05), Local0) } And(0xFF, Local0, Local1) If(Local1) { ASWT(Local1, 0x01) } } Method(VLOC, 1, NotSerialized) { If(LEqual(Arg0, \_SB.LID._LID())) { \VSLD(Arg0) Store(0x00, Local0) If(LEqual(And(VPWR, 0x03), 0x00)) { If(Arg0) { If(LOr(\WIN7, \WVIS)) {} Else { Store(\VEVT(0x01), Local0) } } Else { If(LOr(\WIN7, \WVIS)) {} Else { Store(\VEVT(0x02), Local0) } } And(0x0F, Local0, Local1) If(Local1) { ASWT(Local1, 0x00) } } } } Method(_DOS, 1, NotSerialized) { If(LEqual(Arg0, 0x02)) { Store(0x14, Local0) While(Local0) { Decrement(Local0) Acquire(MDGS, 0xFFFF) If(LEqual(0x00, MSWT)) { Store(0x01, MSWT) Store(0x00, Local0) Store(Arg0, VDEE) } Release(MDGS) Sleep(0xC8) } } Else { Acquire(MDGS, 0xFFFF) If(LEqual(VDEE, 0x02)) { Store(0x00, MSWT) } If(LGreater(Arg0, 0x02)) { Store(0x01, VDEE) } Else { Store(Arg0, VDEE) } Release(MDGS) } } Method(_DOD, 0, NotSerialized) { Return(Package(8) {0x0100, 0x0114, 0x0111, 0x0115, 0x0112, 0x0116, 0x0113, 0x0110}) } Method(ASWT, 2, NotSerialized) { If(LEqual(0x01, VDEE)) { And(0x01, Arg1, Local1) \VSDS(Arg0, Local1) } Else { Store(0x14, Local0) While(Local0) { Decrement(Local0) Acquire(MDGS, 0xFFFF) If(LEqual(0x00, MSWT)) { Store(0x00, Local0) If(And(0x01, Arg1)) { Store(0x01, VUPC) } Else { Store(0x00, VUPC) } If(And(0x01, Arg0)) { Store(0x01, VQDL) } Else { Store(0x00, VQDL) } If(And(0x02, Arg0)) { Store(0x01, VQDC) } Else { Store(0x00, VQDC) } If(And(0x04, Arg0)) { Store(0x01, VQD0) } Else { Store(0x00, VQD0) } If(And(0x08, Arg0)) { Store(0x01, VQD1) } Else { Store(0x00, VQD1) } If(And(0x10, Arg0)) { Store(0x01, VQD2) } Else { Store(0x00, VQD2) } If(And(0x20, Arg0)) { Store(0x01, VQD3) } Else { Store(0x00, VQD3) } If(And(0x40, Arg0)) { Store(0x01, VQD4) } Else { Store(0x00, VQD4) } If(And(0x80, Arg0)) { Store(0x01, VQD5) } Else { Store(0x00, VQD5) } } Release(MDGS) Sleep(0xC8) } If(And(0x02, Arg1)) { Notify(VID, 0x81) } Else { Notify(VID, 0x80) } } } Method(VDSW, 1, NotSerialized) { If(LEqual(VPWR, 0x00)) { If(Arg0) { Store(\VEVT(0x03), Local0) } Else { Store(\VEVT(0x04), Local0) } And(0x0F, Local0, Local1) If(Local1) { ASWT(Local1, 0x00) } } } Device(LCD0) { Method(_ADR, 0, NotSerialized) { Return(0x0110) } Method(_DCS, 0, NotSerialized) { \VUPS(0x00) If(\VCDL) { Return(0x1F) } Else { Return(0x1D) } } Method(_DGS, 0, NotSerialized) { Return(VQDL) } Method(_DSS, 1, NotSerialized) { And(Arg0, 0x01, VSDL) If(And(Arg0, 0x80000000)) { If(And(Arg0, 0x40000000)) { DSWT(0x02) } Else { DSWT(0x01) } } } Method(_DDC, 1, NotSerialized) { If(ISOP()) { Return(0x00) } If(LEqual(Arg0, 0x01)) { Return(\VEDI) } Else { If(LEqual(Arg0, 0x02)) { Return(\VEDI) } } Return(0x00) } } Device(CRT0) { Method(_ADR, 0, NotSerialized) { Return(0x0100) } Method(_DCS, 0, NotSerialized) { \VUPS(0x01) If(\VCSS) { If(\VCDC) { Return(0x1F) } Else { Return(0x1D) } } Else { If(\VCDC) { Return(0x0F) } Else { Return(0x0D) } } } Method(_DGS, 0, NotSerialized) { Return(VQDC) } Method(_DSS, 1, NotSerialized) { And(Arg0, 0x01, VSDC) If(And(Arg0, 0x80000000)) { If(And(Arg0, 0x40000000)) { DSWT(0x02) } Else { DSWT(0x01) } } } } Device(DVI0) { Method(_ADR, 0, NotSerialized) { Return(0x0111) } Method(_DCS, 0, NotSerialized) { \VUPS(0x00) If(\VCDD) { Return(0x1F) } Else { Return(0x1D) } } Method(_DGS, 0, NotSerialized) { Return(VQD1) } Method(_DSS, 1, NotSerialized) { And(Arg0, 0x01, VSD1) If(And(Arg0, 0x80000000)) { If(And(Arg0, 0x40000000)) { DSWT(0x02) } Else { DSWT(0x01) } } } } Device(DP0) { Method(_ADR, 0, NotSerialized) { Return(0x0114) } Method(_DCS, 0, NotSerialized) { \VUPS(0x00) If(\VCDT) { Return(0x1F) } Else { Return(0x1D) } } Method(_DGS, 0, NotSerialized) { Return(VQD0) } Method(_DSS, 1, NotSerialized) { And(Arg0, 0x01, VSD0) If(And(Arg0, 0x80000000)) { If(And(Arg0, 0x40000000)) { DSWT(0x02) } Else { DSWT(0x01) } } } } Device(DVI1) { Method(_ADR, 0, NotSerialized) { Return(0x0112) } Method(_DCS, 0, NotSerialized) { \VUPS(0x00) If(\VCDD) { Return(0x1F) } Else { Return(0x1D) } } Method(_DGS, 0, NotSerialized) { Return(VQD3) } Method(_DSS, 1, NotSerialized) { And(Arg0, 0x01, VSD3) If(And(Arg0, 0x80000000)) { If(And(Arg0, 0x40000000)) { DSWT(0x02) } Else { DSWT(0x01) } } } } Device(DP1) { Method(_ADR, 0, NotSerialized) { Return(0x0115) } Method(_DCS, 0, NotSerialized) { \VUPS(0x00) If(\VCDT) { Return(0x1F) } Else { Return(0x1D) } } Method(_DGS, 0, NotSerialized) { Return(VQD2) } Method(_DSS, 1, NotSerialized) { And(Arg0, 0x01, VSD2) If(And(Arg0, 0x80000000)) { If(And(Arg0, 0x40000000)) { DSWT(0x02) } Else { DSWT(0x01) } } } } Device(DVI2) { Method(_ADR, 0, NotSerialized) { Return(0x0113) } Method(_DCS, 0, NotSerialized) { \VUPS(0x00) If(\VCDD) { Return(0x1F) } Else { Return(0x1D) } } Method(_DGS, 0, NotSerialized) { Return(VQD5) } Method(_DSS, 1, NotSerialized) { And(Arg0, 0x01, VSD5) If(And(Arg0, 0x80000000)) { If(And(Arg0, 0x40000000)) { DSWT(0x02) } Else { DSWT(0x01) } } } } Device(DP2) { Method(_ADR, 0, NotSerialized) { Return(0x0116) } Method(_DCS, 0, NotSerialized) { \VUPS(0x00) If(\VCDT) { Return(0x1F) } Else { Return(0x1D) } } Method(_DGS, 0, NotSerialized) { Return(VQD4) } Method(_DSS, 1, NotSerialized) { And(Arg0, 0x01, VSD4) If(And(Arg0, 0x80000000)) { If(And(Arg0, 0x40000000)) { DSWT(0x02) } Else { DSWT(0x01) } } } } Method(DSWT, 1, NotSerialized) { If(VSDL) { Store(0x01, Local0) } Else { Store(0x00, Local0) } If(VSDC) { Or(0x02, Local0, Local0) } If(VSD0) { Or(0x08, Local0, Local0) } If(Local0) { If(VUPC) { \VSDS(Local0, Arg0) } } Else { NoOp } } } On Sat, Nov 19, 2016 at 1:57 AM, Charlotte Plusplus < pluspluscharlotte(a)gmail.com> wrote: > Quick update: > > Just having "device pci 01.0 on end" in the devicetree results in the > following powertop measurements: > 26W after boot, 21W with power savings applied, 20W at maximum power > savings > > So just declaring the nvidia makes things much worse, even without really > using the dGPU for anything. (there are no nvidia modules, to make sure it > would not interfere with the measurements) > > Since it was in D0, I tried setting the Nvidia gpu in D3 state > setpci -s 01:00.0 CAP_PM+4.b > 08 > setpci -s 01:00.0 CAP_PM+4.b=0b > > It didn't help with the power. To confirm whether disabling the Nvidia > pcie interface results in this +4W in maximal power savings, I completed > src/drivers/lenovo/hybrid_graphics.c with the PCI ID from my card. I > could return to 17W with all power savings applied. > > So I'm back to trying to find a way to turn off the power completely with > the EC, and hoping this is where the extra 8W come from. > > After some googling I found ec_access, but I don't know which register to > write to. > > In case anyone is interested, here are the pci devices, of course ASPM is > already enabled (root: 0xB0 : 0x43, peripheral: 0x88 : 0x4B) and I am not > using the dGPU for anything at all. > > $ cat /sys/devices/pci0000:00/0000:00:01.0/0000:01:00.0/power/runt > ime_status > suspended > $ cat /sys/devices/pci0000:00/0000:00:01.0/0000:01:00.1/power/runt > ime_status > active > > $ lspci -s 00:01.0 -xxx > > 00:01.0 PCI bridge: Intel Corporation Xeon E3-1200 v2/3rd Gen Core > processor PCI Express Root Port (rev 09 > ) > 00: 86 80 51 01 07 04 10 00 09 00 04 06 10 00 81 00 > 10: 00 00 00 00 00 00 00 00 00 01 01 00 20 20 00 20 > 20: 00 f0 00 f1 01 c0 f1 d1 00 00 00 00 00 00 00 00 > 30: 00 00 00 00 88 00 00 00 00 00 00 00 0b 01 03 00 > 40: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > 50: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > 60: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > 70: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0a > 80: 01 90 03 c8 08 00 00 00 0d 80 00 00 86 80 00 00 > 90: 05 a0 01 00 d8 02 e0 fe 00 00 00 00 00 00 00 00 > a0: 10 00 42 01 01 80 00 00 00 00 00 00 03 ad 61 02 > b0: 43 00 02 51 00 00 04 00 00 00 48 00 08 00 00 00 > c0: 00 00 00 00 00 00 00 00 00 00 00 00 0e 00 00 00 > d0: 03 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > e0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > f0: 00 00 00 00 00 00 01 00 00 00 00 00 01 00 10 00 > > # 0 1 2 3 4 5 6 7 8 9 a b c d e f > > $ lspci -d 10de:0dfa -xxx > 01:00.0 VGA compatible controller: NVIDIA Corporation GF108GLM [Quadro > 1000M] (rev a1) > 00: de 10 fa 0d 03 00 10 00 a1 00 00 03 10 00 80 00 > 10: 00 00 00 f0 0c 00 00 c0 00 00 00 00 0c 00 00 d0 > 20: 00 00 00 00 01 20 00 00 00 00 00 00 00 00 00 00 > 30: 00 00 00 f1 60 00 00 00 00 00 00 00 0b 01 00 00 > 40: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > 50: 00 00 00 00 01 00 00 00 ce d6 23 00 00 00 00 00 > 60: 01 68 03 00 08 00 00 00 05 78 80 00 00 00 00 00 > 70: 00 00 00 00 00 00 00 00 10 b4 02 00 a0 8d 00 00 > 80: 10 28 00 00 02 2d 05 00 4b 01 02 11 00 00 00 00 > 90: 00 00 00 00 00 00 00 00 00 00 00 00 10 00 00 00 > a0: 00 00 00 00 00 00 00 00 02 00 00 00 00 00 00 00 > b0: 00 00 00 00 09 00 14 01 00 00 00 00 00 00 00 00 > c0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > d0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > e0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > f0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > > # 0 1 2 3 4 5 6 7 8 9 a b c d e f > > # 78 contains 10, on 88 : 4b > > $ lspci -d 10de:0bea -xxx > > 01:00.1 Audio device: NVIDIA Corporation GF108 High Definition Audio > Controller (rev a1) > 00: de 10 ea 0b 06 00 18 00 a1 00 03 04 10 00 80 00 > 10: 00 00 08 f1 00 00 00 00 00 00 00 00 00 00 00 00 > 20: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > 30: 00 00 00 00 60 00 00 00 00 00 00 00 0b 02 00 00 > 40: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > 50: 00 00 00 00 00 00 00 00 ce d6 23 00 00 00 00 00 > 60: 01 68 03 00 08 00 00 00 05 78 80 00 00 00 00 00 > 70: 00 00 00 00 00 00 00 00 10 00 02 00 a0 8d 00 00 > 80: 10 28 00 00 02 2d 05 00 4b 01 02 11 00 00 00 00 > 90: 00 00 00 00 00 00 00 00 00 00 00 00 10 00 00 00 > a0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > b0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > c0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > d0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > e0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > f0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > > Charlotte > > > On Fri, Nov 18, 2016 at 4:04 PM, Charlotte Plusplus < > pluspluscharlotte(a)gmail.com> wrote: > >> Hello >> >> Super interesting, I didn't know all that! >> >> Currently, I have only set in devicetree: >> >> device pci 00.0 on end # host bridge >> device pci 01.0 off end # NVidia >> device pci 02.0 on end # Intel >> >> and in my nvram options I have: >> hybrid_graphics_mode = Integrated Only >> >> I assumed that would be sufficient to turn off the power for the dGPU >> until I figure out a way to make it work. I will enable the NVidia and do >> more power tests. >> >> After reading hybrid_graphics.c, I understand a bit more, but I also have >> more questions: >> - can I add register "pcie_hotplug_map" = "{ 0, 1, 0}" to make the >> NVidia removable? >> (so that the operating system will not freak out when the NVidia >> disappears from the PCI bus if I find a way to control the power by talking >> to the EC and send >> GFXCORE_ON_D + the other signal for the VRAM) >> >> - can you change the connection of the displayport? Based on the >> specsheets, it is connected to the dGPU, while the internal display is >> connected to the iGPU. If is it possible to control the muxes for the >> internal display, I suppose it is possible for the other displays as well. >> (I have just tested and I do not have any video on the displayport, and >> xrandr does not detect anything) >> >> - there seem to be some missing IDs in pci_device_ids_nvidia : cf >> http://envytools.readthedocs.io/en/latest/hw/pciid.html which agrees >> with the W530 : 0x0ffb, so I will propose a patch: >> 0x0dfa, /* Nvidia NVS Quadro 1000m Lenovo W520 */ >> 0x0ffb, /* Nvidia NVS Quadro K1000m Lenovo W530 >> */ >> 0x0ffc, /* Nvidia NVS Quadro K2000m Lenovo W530 */ >> >> It may also be the reason why the Nvidia is still getting power, as Iru >> noted that hybrid_graphics should turn off the power. I will test that >> separately. >> >> - until I can find a better solution, I am thinking of letting the Nvidia >> show on on the PCIe bus and then sending commands to get in into advanced >> sleep - like on https://wireless.wiki.kernel.o >> rg/en/users/documentation/aspm >> >> It should be possible as the w530 lspci -v shows: >> Capabilities: [60] Power Management version 3 >> Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA >> PME(D0-,D1-,D2-,D3hot-,D3cold-) >> Status: D0 NoSoftRst+ PME-Enable- DSel=0 DScale=0 PME- >> >> Would you have a better idea? >> >> Thanks >> Charlotte >> >> On Fri, Nov 18, 2016 at 4:52 AM, Felix Held <felix-coreboot(a)felixheld.de> >> wrote: >> >>> Hi! >>> >>> I don't know if Charlotte has added the ID of the dGPU to >>>> src/drivers/lenovo/hybrid_graphics.c. Does the dGPU consume power >>>> after hybrid_graphics.c disable the dGPU? >>>> >>> OPTIMUS_ENABLE is a PCH GPIO and controls the muxes that select if the >>> internal display is connected to the iGPU or the dGPU; that's done in >>> hybrid_graphics.c. >>> GFXCORE_ON_D (and another signal that controls the power supply of the >>> VRAM) are driven by the Thinker-1 chip; those switch on/off the power >>> supply of the GPU. So to really disable the GPU you probably have to ask >>> the EC to make that chip turn off the voltage for the GPU and VRAM. >>> >>> >>> Regards >>> Felix >>> >>> -- >>> coreboot mailing list: coreboot(a)coreboot.org >>> https://www.coreboot.org/mailman/listinfo/coreboot >>> >> >> >

1 0

Success: Native gfx init on T500 with 1680x1050 display working w/o VGA blob
by Daniel Kulesz 19 Nov '16

19 Nov '16

Hi folks, already since a while, there exists a hardware mod for the Thinkpad T500 which allows to run a quadcore CPU from from the Q9000-QX9300 series using Coreboot [1]. After trying various Coreboot configurations, I managed to make the current coreboot-master (e39a8a9c092ed66686632d591ec84ed7a6165a50) work on such a Quadcore-modded T500 with the Q9000 CPU [2]. What is really stunning: Although this T500 has one of the "believed-unsupported" 1680x1050 screen, even without the VGA blob and without microcode updates I get Seabios output using native gfx init! However, there are some small issues: - sometimes the screen is a little garbled, similar to the bug I reported for my X60s in [3]. It's not that bad, however and only affects booting. - the memtest86+ payload does not boot (or it boots but shows no image, I don't know. Is it possible to make memtest86+ use the 1680x1050 resolution?). - when booting the Debian Jessie installer, selecting the default VGA mode does not work. However, selecting mode 7 (1680x1050 VESA) works fine. - when booting into an installed Debian Jessie base system, the grub screen (from Debian, not a coreboot payload) is not visible unless you set GRUB_GFXMODE=1680x1050 in grub.cfg and rewrite it. Since I haven't reassembled the machine yet, I haven't done any extensive testing, didn't try virtualization etc. However, installing Debian Jessie worked fine. Power consumption in idle is very good as for this CPU (13,5-19W, depending on screen brightness). I am attaching my config to this post and will try to run board-status script as soon. Very happy with my T500 so far - huge thanks to the Coreboot developers! Cheers, Daniel [1] https://thinkpad-forum.de/threads/199129-Core2-Quad-mit-Coreboot-Libreboot-… [2] http://ark.intel.com/products/40480/Intel-Core2-Quad-Processor-Q9000-6M-Cac… [3] https://ticket.coreboot.org/issues/80

2 1

Re: [coreboot] Powersavings: 8W of difference between bios and coreboot
by Charlotte Plusplus 19 Nov '16

19 Nov '16

Quick update: Just having "device pci 01.0 on end" in the devicetree results in the following powertop measurements: 26W after boot, 21W with power savings applied, 20W at maximum power savings So just declaring the nvidia makes things much worse, even without really using the dGPU for anything. (there are no nvidia modules, to make sure it would not interfere with the measurements) Since it was in D0, I tried setting the Nvidia gpu in D3 state setpci -s 01:00.0 CAP_PM+4.b 08 setpci -s 01:00.0 CAP_PM+4.b=0b It didn't help with the power. To confirm whether disabling the Nvidia pcie interface results in this +4W in maximal power savings, I completed src/drivers/lenovo/hybrid_graphics.c with the PCI ID from my card. I could return to 17W with all power savings applied. So I'm back to trying to find a way to turn off the power completely with the EC, and hoping this is where the extra 8W come from. After some googling I found ec_access, but I don't know which register to write to. In case anyone is interested, here are the pci devices, of course ASPM is already enabled (root: 0xB0 : 0x43, peripheral: 0x88 : 0x4B) and I am not using the dGPU for anything at all. $ cat /sys/devices/pci0000:00/0000:00:01.0/0000:01:00.0/power/runtime_status suspended $ cat /sys/devices/pci0000:00/0000:00:01.0/0000:01:00.1/power/runtime_status active $ lspci -s 00:01.0 -xxx 00:01.0 PCI bridge: Intel Corporation Xeon E3-1200 v2/3rd Gen Core processor PCI Express Root Port (rev 09 ) 00: 86 80 51 01 07 04 10 00 09 00 04 06 10 00 81 00 10: 00 00 00 00 00 00 00 00 00 01 01 00 20 20 00 20 20: 00 f0 00 f1 01 c0 f1 d1 00 00 00 00 00 00 00 00 30: 00 00 00 00 88 00 00 00 00 00 00 00 0b 01 03 00 40: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 50: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 60: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 70: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0a 80: 01 90 03 c8 08 00 00 00 0d 80 00 00 86 80 00 00 90: 05 a0 01 00 d8 02 e0 fe 00 00 00 00 00 00 00 00 a0: 10 00 42 01 01 80 00 00 00 00 00 00 03 ad 61 02 b0: 43 00 02 51 00 00 04 00 00 00 48 00 08 00 00 00 c0: 00 00 00 00 00 00 00 00 00 00 00 00 0e 00 00 00 d0: 03 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 e0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 f0: 00 00 00 00 00 00 01 00 00 00 00 00 01 00 10 00 # 0 1 2 3 4 5 6 7 8 9 a b c d e f $ lspci -d 10de:0dfa -xxx 01:00.0 VGA compatible controller: NVIDIA Corporation GF108GLM [Quadro 1000M] (rev a1) 00: de 10 fa 0d 03 00 10 00 a1 00 00 03 10 00 80 00 10: 00 00 00 f0 0c 00 00 c0 00 00 00 00 0c 00 00 d0 20: 00 00 00 00 01 20 00 00 00 00 00 00 00 00 00 00 30: 00 00 00 f1 60 00 00 00 00 00 00 00 0b 01 00 00 40: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 50: 00 00 00 00 01 00 00 00 ce d6 23 00 00 00 00 00 60: 01 68 03 00 08 00 00 00 05 78 80 00 00 00 00 00 70: 00 00 00 00 00 00 00 00 10 b4 02 00 a0 8d 00 00 80: 10 28 00 00 02 2d 05 00 4b 01 02 11 00 00 00 00 90: 00 00 00 00 00 00 00 00 00 00 00 00 10 00 00 00 a0: 00 00 00 00 00 00 00 00 02 00 00 00 00 00 00 00 b0: 00 00 00 00 09 00 14 01 00 00 00 00 00 00 00 00 c0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 d0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 e0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 f0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 # 0 1 2 3 4 5 6 7 8 9 a b c d e f # 78 contains 10, on 88 : 4b $ lspci -d 10de:0bea -xxx 01:00.1 Audio device: NVIDIA Corporation GF108 High Definition Audio Controller (rev a1) 00: de 10 ea 0b 06 00 18 00 a1 00 03 04 10 00 80 00 10: 00 00 08 f1 00 00 00 00 00 00 00 00 00 00 00 00 20: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 30: 00 00 00 00 60 00 00 00 00 00 00 00 0b 02 00 00 40: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 50: 00 00 00 00 00 00 00 00 ce d6 23 00 00 00 00 00 60: 01 68 03 00 08 00 00 00 05 78 80 00 00 00 00 00 70: 00 00 00 00 00 00 00 00 10 00 02 00 a0 8d 00 00 80: 10 28 00 00 02 2d 05 00 4b 01 02 11 00 00 00 00 90: 00 00 00 00 00 00 00 00 00 00 00 00 10 00 00 00 a0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 b0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 c0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 d0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 e0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 f0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 Charlotte On Fri, Nov 18, 2016 at 4:04 PM, Charlotte Plusplus < pluspluscharlotte(a)gmail.com> wrote: > Hello > > Super interesting, I didn't know all that! > > Currently, I have only set in devicetree: > > device pci 00.0 on end # host bridge > device pci 01.0 off end # NVidia > device pci 02.0 on end # Intel > > and in my nvram options I have: > hybrid_graphics_mode = Integrated Only > > I assumed that would be sufficient to turn off the power for the dGPU > until I figure out a way to make it work. I will enable the NVidia and do > more power tests. > > After reading hybrid_graphics.c, I understand a bit more, but I also have > more questions: > - can I add register "pcie_hotplug_map" = "{ 0, 1, 0}" to make the NVidia > removable? > (so that the operating system will not freak out when the NVidia > disappears from the PCI bus if I find a way to control the power by talking > to the EC and send > GFXCORE_ON_D + the other signal for the VRAM) > > - can you change the connection of the displayport? Based on the > specsheets, it is connected to the dGPU, while the internal display is > connected to the iGPU. If is it possible to control the muxes for the > internal display, I suppose it is possible for the other displays as well. > (I have just tested and I do not have any video on the displayport, and > xrandr does not detect anything) > > - there seem to be some missing IDs in pci_device_ids_nvidia : cf > http://envytools.readthedocs.io/en/latest/hw/pciid.html which agrees with > the W530 : 0x0ffb, so I will propose a patch: > 0x0dfa, /* Nvidia NVS Quadro 1000m Lenovo W520 */ > 0x0ffb, /* Nvidia NVS Quadro K1000m Lenovo W530 > */ > 0x0ffc, /* Nvidia NVS Quadro K2000m Lenovo W530 */ > > It may also be the reason why the Nvidia is still getting power, as Iru > noted that hybrid_graphics should turn off the power. I will test that > separately. > > - until I can find a better solution, I am thinking of letting the Nvidia > show on on the PCIe bus and then sending commands to get in into advanced > sleep - like on https://wireless.wiki.kernel.org/en/users/documentation/ > aspm > > It should be possible as the w530 lspci -v shows: > Capabilities: [60] Power Management version 3 > Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA > PME(D0-,D1-,D2-,D3hot-,D3cold-) > Status: D0 NoSoftRst+ PME-Enable- DSel=0 DScale=0 PME- > > Would you have a better idea? > > Thanks > Charlotte > > On Fri, Nov 18, 2016 at 4:52 AM, Felix Held <felix-coreboot(a)felixheld.de> > wrote: > >> Hi! >> >> I don't know if Charlotte has added the ID of the dGPU to >>> src/drivers/lenovo/hybrid_graphics.c. Does the dGPU consume power after >>> hybrid_graphics.c disable the dGPU? >>> >> OPTIMUS_ENABLE is a PCH GPIO and controls the muxes that select if the >> internal display is connected to the iGPU or the dGPU; that's done in >> hybrid_graphics.c. >> GFXCORE_ON_D (and another signal that controls the power supply of the >> VRAM) are driven by the Thinker-1 chip; those switch on/off the power >> supply of the GPU. So to really disable the GPU you probably have to ask >> the EC to make that chip turn off the voltage for the GPU and VRAM. >> >> >> Regards >> Felix >> >> -- >> coreboot mailing list: coreboot(a)coreboot.org >> https://www.coreboot.org/mailman/listinfo/coreboot >> > >

1 0

← Newer
1
...
6
7
8
9
10
11
12
...
19
Older →

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

coreboot November 2016