Re: [coreboot] Investigating the high pitched noise on the x60 tablet
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 sudo powertop Go to tunables. Turn everything in tunables to Good and the noise goes away. Do this without idle=halt or processor.max_cstate=2 options. This plus backlight support (see http://libreboot.org/howto.html#x60_native_notes) you can get battery life as high as on lenovo bios without any of that noise. On 09/06/14 22:56, Peter Stuge wrote: Charles Devereaux wrote: I would like to investigate the whining noise issue. I have a spare motherboard that I'm setting up for studying this noise issue by pinpointing from which component it comes from .. by default going into a power saving mode that make this noise. The noise is not created by a particular state. The noise is created by switching between states. I expect that the noise comes from power supply circuitry. Use an oscilloscope in clever ways to find the source. idle=halt skips all C-states. uhci_hcd requires the CPU to run every ms. Factory BIOS and coreboot have different noise. Thermal shutdown is fairly easy to induce when running coreboot, but not with factory BIOS. X60 has notoriously poor thermal design, but still there is no thermal shutdown with factory BIOS. Find why. Understanding the thermal issue might be helpful for the noise issue. Learn how the factory BIOS manages the CPU power states. You will not be able to find the documentation you may want for this. //Peter -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBAgAGBQJTlqTOAAoJEP9Ft0z50c+UD40H/2JyyZshBQ+eAx0J8IkM8TCH 2obiHcIpCq5TMrJtM1DF3xOWH9lTn9edw5ooFQNUJXS1fgtWub83f4GY3mebgddW /52vtJst0SZHwbmmL8NKYzvUmdV+QYoCg75SoS2sU7mLrtclpKxYKfBINS8ykZqV vxhDBVBq0Yhn1blJkoQzxZjRL/NTej5Nn7WXiIXnEBluGa12y1xxhVAczEfUaoDZ 89U8ytMVZviYlWidxt/q7LtndYZooztpK8EdMqePx5wwlKg/Q3kL+CM3rL7ChSYe MSj/PEw8AtqYYWCNna9WnJJe4ntcCLGC4eSTyLtPyucMHZ3fh2HM+wVGTZ9MVP4= =1pFt -END PGP SIGNATURE- -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] Intel native graphics init: Questions about GTT setup: Decode error on Lenovo X60
Dear Ron, Am Montag, den 09.06.2014, 20:18 -0700 schrieb ron minnich: Folks, do I correctly understand this regression is X60-only? I only have confirmation on the Lenovo X60 [1]. I am not sure about the Lenovo T60 and the Apple MacBook 2,1. Unfortunately my requests for tests on other Intel hardware were not heard yet. In that case, I suspect there will not be lots of interest in fixing it from the kernel side :-( Well, luckily for us the Linux kernel has a no-regression policy. And this is clearly a regression. Unfortunately the Lenovo X60 owners have not bisected or reported this yet. Thanks, Paul [1] http://www.coreboot.org/Lenovo_x60x_vgainit_todos#No_video_at_all_even_after_kernel_boots signature.asc Description: This is a digitally signed message part -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
[coreboot] [RFH] Testing Linux 3.12+ on Intel hardware to initialize the IGD
Dear coreboot folks, following up on [1], could you please test latest Linux kernels (3.12, 3.13, 3.14, 3.15) on Intel based laptops and check if the Intel driver is able to initialize the IGD [2] without a Video BIOS or coreboot’s native graphics init? If you know if that was ever possible, for example with Linux 3.2, that’d be also interesting. Thanks, Paul [1] http://www.coreboot.org/pipermail/coreboot/2014-June/078104.html [2] Integrated Graphics Device signature.asc Description: This is a digitally signed message part -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] [RFH] Testing Linux 3.12+ on Intel hardware to initialize the IGD
On Tue, Jun 10, 2014 at 12:22 AM, Paul Menzel paulepan...@users.sourceforge.net wrote: Dear coreboot folks, following up on [1], could you please test latest Linux kernels (3.12, 3.13, 3.14, 3.15) on Intel based laptops and check if the Intel driver is able to initialize the IGD [2] without a Video BIOS or coreboot’s native graphics init? If you know if that was ever possible, for example with Linux 3.2, that’d be also interesting. Intel made a change to their driver to rely on the VBT for initializing the graphics device. The VBT is usually carried in the Video BIOS so that's where that dependency comes in. -Aaron -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] [RFH] Testing Linux 3.12+ on Intel hardware to initialize the IGD
Aaron Durbin wrote: Intel made a change to their driver to rely on the VBT for initializing the graphics device. The VBT is usually carried in the Video BIOS so that's where that dependency comes in. It's not a horrible move. What it means is that coreboot should grow a data model (have we heard that before?) to expose the relevant data to the graphics driver. For compatibility it might be wise to use the legacy VBT format. Perhaps we can do something clever with coreboot tables, like putting the VBT into a table entry located in low memory. //Peter -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] Intel FSP on Bayley Bay CRB
Gerald, Does the crb have a port80? You should get early postcodes from coreboot and the FSP. You are also correct that there might be something different in the descriptor.bin that isn't anticipated. You may want to use the coreboot util/ifdtool to get a look at the entire image. Marc On Tue, Jun 3, 2014 at 6:03 AM, Gerald Otter gerald.ot...@gmail.com wrote: Hi all, I am trying to run coreboot + seabios payload on the bayley bay crb with the recently committed FSP integration, but have had no luck so far. This crb uses the bay trail I (now atom e3800) soc from intel. Following the instructions from commit d75800c7f , I have built a 2MB image and flashed it to the upper 2MB of the 8MB flash, leaving the TXE / flash descriptor intact. I have added the config from the build. The FSP I used is BAYTRAIL_FSP_GOLD_002_10-JANUARY-2014, together with the flash descriptor and TXE from the 80.21 bios provided by intel, and vga bios 36.2.2. Fwiw, I have tried both the 32bit and 64bit releases of the bios, even though the flash descriptor and TXE binary seem to be exactly the same. The issue I’m running into is that I have no idea if anything is running at all. There is no output on the VGA/HDMI ports or uart. The legacy uart referred to in the source is working correctly with the original intel bios, but does not produce any output with the coreboot image. I have tried the most common baud rates (115200, 19200, 9600 ) and did some measurements with a scope in case I got the baud rate wrong, but no cigar. The uart I’m using is the PCU uart, as opposed to hsuart1/2 and the superIO uart. This matches with the configuration in coreboot when compared to the datasheet, so I’m assuming I got this set up correctly. Unfortunately, this is about all the information I have, so I hope I am missing something obvious when building the image / flashing it, etc. I have also used intel’s flash image tool (fitc) to build a complete image, thinking that maybe the flash descriptor needed to contain some specific information regarding the coreboot image (size/checksums), but given the original instructions I wasn’t surprised this didn’t work. Thanks in advance! -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot -- http://se-eng.com -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] XHCI device disconnect on S3 standby
On 6/4/2014 1:06 PM, Duncan Laurie wrote: On Tue, May 27, 2014 at 3:17 PM, Matt DeVillier matt.devill...@gmail.com wrote: Greetings, I'm unable to use any USB devices connected to an XHCI controller to resume from S3 standby, as something causes all connected devices to disconnect just prior to entering standby, as per the output of dmesg. I've traced the relevant sections in the southbridge and ACPI source for my device (a haswell-based ChromeOS device with an Intel lynxpoint southbridge), but have been unable to find the culprit. CONFIG_FINALIZE_USB_ROUTE_XHCI is set, as this device only has USB3 ports (4x), but having it set either way doesn't make a difference. The usb_xhci_sleep_prepare() call doesn't seem to be the culprit, as commenting it out has no (positive) effect. Resuming via the power switch or wake on lan work perfectly, so it's not a general resuming issue. Appreciate any pointers on how to proceed USB/XHCI devices disconnecting in the kernel before the system goes to suspend suggests it may be an intentional OS (via udev?) action. Which distro are you using? I think the panther mainboard has not been upstreamed yet so I assume you are using a checkout from the chromium coreboot? Or is this pulling the chromium panther mainboard into the upstream coreboot? Here are a few things to check: - Is there an XHCI device visible (and set as enabled) in /proc/acpi/wakeup output? - When you go to suspend what does the kernel print about XHCI controller itself? (ignoring the devices for the moment) I would expect to see lines like this before it actually goes to suspend: xhci_hcd :00:14.0: System wakeup enabled by ACPI xhci_hcd :00:14.0: power state changed by ACPI to D3cold And then after resume: xhci_hcd :00:14.0: power state changed by ACPI to D0 xhci_hcd :00:14.0: System wakeup disabled by ACPI In an attempt to debug further it could help to send some additional output: - dmesg after a suspend/resume cycle - /sys/firmware/acpi/tables/DSDT (after run through iasl -d) I don't expect issues here if wake-on-lan is working, but worth a check. Thanks, -duncan Hi Duncan, I'm currently testing on OpenELEC 4.0.4 (k 3.14.5, 3.15.0) and Ubuntu 14.04 (k 3.14.1). This is using upstream coreboot with the panther mainboard info pulled from the panther chromium branch. I also pulled over any changes to the northbridge/haswell and southbridge/lynxpoint directories that hadn't made it back upstream yet. 'cat /proc/acpi/wakeup' shows the xhci controller as enabled, as does 'cat /sys/bus/usb/devices/dev #/power/wakeup' for all connected devices. dmesg shows the following prior to entering suspend: xhci_hcd :00:14.0: remove, state 4 usb usb2: USB disconnect, device number 1 xhci_hcd :00:14.0: USB bus 2 deregistered xhci_hcd :00:14.0: remove, state 1 usb usb1: USB disconnect, device number 1 usb 1-2: USB disconnect, device number 2 usb 1-4: USB disconnect, device number 5 usb 1-5: USB disconnect, device number 4 xhci_hcd :00:14.0: USB bus 1 deregistered snip PM: Entering mem sleep and coming out of resume, nothing xhci related prior to 'PM: Finishing wakeup.' afterwards, it re-inits the xhci controller identically to at boot: xhci_hcd :00:14.0: xHCI Host Controller xhci_hcd :00:14.0: new USB bus registered, assigned bus number 1 etc etc. Nothing related to setting the power states either prior to or after suspend. thanks, Matt -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
[coreboot] setting smbios values from the OS
Hi folks, first time posting here. I was wondering if it would be possible to modify smbios values once a system is up and running. Has anyone ever looked into that? If not, any pointers on how to implement this would be greatly appreciated. I'm fairly new to coreboot but would like to look into this. This is with coreboot + seabios, btw. Thanks, Rafael -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] Intel FSP on Bayley Bay CRB
Hi Marc, There is indeed a port80 4 digit hex display on that board, so Gerald should be getting something from that. Hi Gerald, If you had serial output from the BIOS, then I think you probably have the UART connected properly. I always use the microUSB connector, though, with a standard phone cable to get serial from those boards. It has an on-board usb to serial adapter. Coreboot usually sets baud rate to 115200, but it is configurable. Check your .config: CONFIG_CONSOLE_SERIAL=y CONFIG_TTYS0_BASE=0x3f8 CONFIG_CONSOLE_SERIAL_115200=y CONFIG_TTYS0_BAUD=115200 CONFIG_TTYS0_LCS=3 CONFIG_POST_IO=y CONFIG_POST_DEVICE=y CONFIG_POST_DEVICE_NONE=y CONFIG_POST_IO_PORT=0x80 Regardless of these settings, FSP will send info to the port80 so something should have shown. Other things you can check: 1) Properly configured FSP for BayleyBay with the bct program. BayleyBay is a non-ECC RAM board and won't boot with ECC FSP. 2) Have the appropriate microcode for your stepping of CPU. B0 steppings are harder to get correct and the microcode is not in git. Cheers, Sean On 06/11/2014 03:04 AM, Marc Jones wrote: Gerald, Does the crb have a port80? You should get early postcodes from coreboot and the FSP. You are also correct that there might be something different in the descriptor.bin that isn't anticipated. You may want to use the coreboot util/ifdtool to get a look at the entire image. Marc On Tue, Jun 3, 2014 at 6:03 AM, Gerald Otter gerald.ot...@gmail.com wrote: Hi all, I am trying to run coreboot + seabios payload on the bayley bay crb with the recently committed FSP integration, but have had no luck so far. This crb uses the bay trail I (now atom e3800) soc from intel. Following the instructions from commit d75800c7f , I have built a 2MB image and flashed it to the upper 2MB of the 8MB flash, leaving the TXE / flash descriptor intact. I have added the config from the build. The FSP I used is BAYTRAIL_FSP_GOLD_002_10-JANUARY-2014, together with the flash descriptor and TXE from the 80.21 bios provided by intel, and vga bios 36.2.2. Fwiw, I have tried both the 32bit and 64bit releases of the bios, even though the flash descriptor and TXE binary seem to be exactly the same. The issue I’m running into is that I have no idea if anything is running at all. There is no output on the VGA/HDMI ports or uart. The legacy uart referred to in the source is working correctly with the original intel bios, but does not produce any output with the coreboot image. I have tried the most common baud rates (115200, 19200, 9600 ) and did some measurements with a scope in case I got the baud rate wrong, but no cigar. The uart I’m using is the PCU uart, as opposed to hsuart1/2 and the superIO uart. This matches with the configuration in coreboot when compared to the datasheet, so I’m assuming I got this set up correctly. Unfortunately, this is about all the information I have, so I hope I am missing something obvious when building the image / flashing it, etc. I have also used intel’s flash image tool (fitc) to build a complete image, thinking that maybe the flash descriptor needed to contain some specific information regarding the coreboot image (size/checksums), but given the original instructions I wasn’t surprised this didn’t work. Thanks in advance! -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
