coreboot March 2017

coreboot@coreboot.org

79 participants
267 discussions

Re: [coreboot] Suspend-to-RAM on Thinkpad X230
by Gert Menke 12 Mar '17

12 Mar '17

Hi, Thanks for your quick reply! On 2017-03-12 13:08, Kyösti Mälkki wrote: > We'll likely need coreboot debug logs. You can get one for normal boot > using the tool under utils/cbmem, that might help us already. To > collect log from failing S3 resume you need to learn about usbdebug > and possibly get some FT232H or beaglebone hardware. I'll attach the cbmem log, both for a clean boot and a boot that happens instead of the expected resume. It's likely I already have all I need for USB debugging at home; I will check when I get home tomorrow. Is it simply a serial console via FTDI? > Also check ifdtool -d output. S3 resume requires host CPU has write > access to the part of SPI flash where MRC cache is located. It should be okay; I unlocked all regions using ifdtool. And flashrom can write the whole 12MB without problems. ifdtool -d does not mention anything about MRC cache, though; I'll attach that, too. Gert

2 1

Suspend-to-RAM on Thinkpad X230
by Gert Menke 12 Mar '17

12 Mar '17

Hi everyone, I recently installed coreboot on my Thinkpad X230 and overall I am pretty happy with it. Everything seems to work well, except one annoying problem: Suspend-to-RAM does not work correctly. Well, maybe suspend works correctly, but resume doesn't. Instead of resuming, the system simply boots like on power-on. Since I'm pretty new to coreboot, I'm at a loss here. Is there something obvious that I might have missed? I'm using the current master revision from git (4eb155cee47557cd652d1a85fed5021b23f18a2a), and I'll attach my coreboot .config. Thanks in advance for any help! Gert

2 1

Regression with new toolchain and AGESA boards
by Paul Menzel 10 Mar '17

10 Mar '17

Dear coreboot folks, GCC 6.3 shipped with the new coreboot toolchain 1.44 creates code differently causing the boot to fail with the latest commits. Yesterday, once again, Kyösti showed how awesome he, and pushed a fix for review [1][2]. It’d be great if you could help test that. Thanks, Paul [1] https://review.coreboot.org/18622/ "AGESA: Fix SSE regression and align stack early" [2] https://review.coreboot.org/18691/ "binaryPI: Fix SSE regression and align stack early"

1 1

New Defects reported by Coverity Scan for coreboot
by scan-admin＠coverity.com 10 Mar '17

10 Mar '17

Hi, Please find the latest report on new defect(s) introduced to coreboot found with Coverity Scan. 12 new defect(s) introduced to coreboot found with Coverity Scan. 479 defect(s), reported by Coverity Scan earlier, were marked fixed in the recent build analyzed by Coverity Scan. New defect(s) Reported-by: Coverity Scan Showing 12 of 12 defect(s) ** CID 1372122: Parse warnings (PARSE_ERROR) /tmp/temp.wd1Xl3.c: 1 in () ________________________________________________________________________________________________________ *** CID 1372122: Parse warnings (PARSE_ERROR) /tmp/temp.wd1Xl3.c: 1 in () >>> CID 1372122: Parse warnings (PARSE_ERROR) >>> The Coverity compiler fails to compile this file. Please see the build output log for more information. ** CID 1372121: Parse warnings (PARSE_ERROR) /tmp/temp.PwE3Ix.c: 1 in () ________________________________________________________________________________________________________ *** CID 1372121: Parse warnings (PARSE_ERROR) /tmp/temp.PwE3Ix.c: 1 in () >>> CID 1372121: Parse warnings (PARSE_ERROR) >>> The Coverity compiler fails to compile this file. Please see the build output log for more information. ** CID 1372120: Parse warnings (PARSE_ERROR) /tmp/temp.l5huTj.c: 1 in () ________________________________________________________________________________________________________ *** CID 1372120: Parse warnings (PARSE_ERROR) /tmp/temp.l5huTj.c: 1 in () >>> CID 1372120: Parse warnings (PARSE_ERROR) >>> The Coverity compiler fails to compile this file. Please see the build output log for more information. ** CID 1372119: Parse warnings (PARSE_ERROR) /tmp/temp.NhKFBO.c: 1 in () ________________________________________________________________________________________________________ *** CID 1372119: Parse warnings (PARSE_ERROR) /tmp/temp.NhKFBO.c: 1 in () >>> CID 1372119: Parse warnings (PARSE_ERROR) >>> The Coverity compiler fails to compile this file. Please see the build output log for more information. ** CID 1372118: Parse warnings (PARSE_ERROR) /tmp/temp.d5VfJC.c: 1 in () ________________________________________________________________________________________________________ *** CID 1372118: Parse warnings (PARSE_ERROR) /tmp/temp.d5VfJC.c: 1 in () >>> CID 1372118: Parse warnings (PARSE_ERROR) >>> The Coverity compiler fails to compile this file. Please see the build output log for more information. ** CID 1372117: Parse warnings (PARSE_ERROR) /tmp/temp.RRVI6C.c: 1 in () ________________________________________________________________________________________________________ *** CID 1372117: Parse warnings (PARSE_ERROR) /tmp/temp.RRVI6C.c: 1 in () >>> CID 1372117: Parse warnings (PARSE_ERROR) >>> The Coverity compiler fails to compile this file. Please see the build output log for more information. ** CID 1372116: Parse warnings (PARSE_ERROR) /tmp/temp.zm5Rym.c: 1 in () ________________________________________________________________________________________________________ *** CID 1372116: Parse warnings (PARSE_ERROR) /tmp/temp.zm5Rym.c: 1 in () >>> CID 1372116: Parse warnings (PARSE_ERROR) >>> The Coverity compiler fails to compile this file. Please see the build output log for more information. ** CID 1372115: Parse warnings (PARSE_ERROR) /tmp/temp.ZIoNj2.c: 1 in () ________________________________________________________________________________________________________ *** CID 1372115: Parse warnings (PARSE_ERROR) /tmp/temp.ZIoNj2.c: 1 in () >>> CID 1372115: Parse warnings (PARSE_ERROR) >>> The Coverity compiler fails to compile this file. Please see the build output log for more information. ** CID 1372114: Parse warnings (PARSE_ERROR) /tmp/temp.eDfkcm.c: 1 in () ________________________________________________________________________________________________________ *** CID 1372114: Parse warnings (PARSE_ERROR) /tmp/temp.eDfkcm.c: 1 in () >>> CID 1372114: Parse warnings (PARSE_ERROR) >>> The Coverity compiler fails to compile this file. Please see the build output log for more information. ** CID 1372113: Parse warnings (PARSE_ERROR) /tmp/temp.XutzxI.c: 1 in () ________________________________________________________________________________________________________ *** CID 1372113: Parse warnings (PARSE_ERROR) /tmp/temp.XutzxI.c: 1 in () >>> CID 1372113: Parse warnings (PARSE_ERROR) >>> The Coverity compiler fails to compile this file. Please see the build output log for more information. ** CID 1372112: Parse warnings (PARSE_ERROR) /tmp/temp.B5xif5.c: 1 in () ________________________________________________________________________________________________________ *** CID 1372112: Parse warnings (PARSE_ERROR) /tmp/temp.B5xif5.c: 1 in () >>> CID 1372112: Parse warnings (PARSE_ERROR) >>> The Coverity compiler fails to compile this file. Please see the build output log for more information. ** CID 1372111: Parse warnings (PARSE_ERROR) /tmp/temp.ENiEDc.c: 1 in () ________________________________________________________________________________________________________ *** CID 1372111: Parse warnings (PARSE_ERROR) /tmp/temp.ENiEDc.c: 1 in () >>> CID 1372111: Parse warnings (PARSE_ERROR) >>> The Coverity compiler fails to compile this file. Please see the build output log for more information. ________________________________________________________________________________________________________ To view the defects in Coverity Scan visit, https://u2389337.ct.sendgrid.net/wf/click?upn=08onrYu34A-2BWcWUl-2F-2BfV0V0… To manage Coverity Scan email notifications for "coreboot(a)coreboot.org", click https://u2389337.ct.sendgrid.net/wf/click?upn=08onrYu34A-2BWcWUl-2F-2BfV0V0…

1 0

call on AMD to release src+specs+datasheets for ryzen
by Leah Rowe 10 Mar '17

10 Mar '17

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Hi all, https://libreboot.org/amd-libre/ We call on coreboot to join us in our campaign to convince AMD to start cooperating with the libre hardware community again. Are there people in coreboot already doing this? - -- Leah Rowe Libreboot developer Use free software. Free as in freedom. https://en.wikipedia.org/wiki/Free_software Use a free operating system, GNU+Linux. https://libreboot.org/docs/distros/ Or BSD: https://libreboot.org/docs/bsd/ Use a free BIOS. https://libreboot.org/ Support computer user freedom. https://peers.community/ Minifree Ltd, trading as Ministry of Freedom | Registered in England, No. 9361826 | VAT No. GB202190462 Registered Office: 19 Hilton Road, Canvey Island, Essex SS8 9QA, UK | Web: https://minifree.org/ -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEE+JRrnG26iGmvPhSA/0W3TPnRz5QFAli5wy0ACgkQ/0W3TPnR z5SjBQf+NCfTdd5WPPW9KDAD/UtvddNtjKrtwQz/50wR2mxuwqoiESq2M4pPk9C4 17zVqTPbQYESk5+smT4h3fnqVG5HvqhDJHpwEchq4x/PO0ZgsEGbDNpjt9FjOv6M 82U/RT33wW/X3KvPKhywYNOp5qhYzUN7DL4275cgikKsqLk9izbRxUE6lgTbcSTU 3mjTlRfyCr46EKEsB+c+qmbWAhaIrnu/6Vuv3LHZfO1iFEOQKmnZEvoNNnEGMPKY JQF/B3kuf3jcJ9yq4nhIQO9pBEAB2CuuYPn4XZZArHJS1OZX7ILMO2zj2o8favDf 5SWR2o2zEui3LZkwj8gwCPz3VF4Rag== =3Ke8 -----END PGP SIGNATURE-----

4 6

Re: [coreboot] USB HUB depth
by Joshua Pincus 09 Mar '17

09 Mar '17

Hi Patrick and Nico, Everything works now as expected. I wasn't calling usb_poll() properly. Thanks, again, for the quick responses to my exceedingly naive queries. JP On Thu, Mar 9, 2017 at 10:40 AM, Joshua Pincus <joshua.pincus(a)gmail.com> wrote: > Hi, > > Cool. I'm looking at that code now. Thanks for your help. > JP > > On Thu, Mar 9, 2017 at 10:29 AM, Patrick Georgi <pgeorgi(a)google.com> > wrote: > >> 2017-03-09 18:53 GMT+01:00 Joshua Pincus <joshua.pincus(a)gmail.com>: >> > Enable_port() merely provides power to those ports. It doesn't scan >> them and then attach them in any way. >> That happens on the next usb_poll(), which calls ->poll() for every >> device. >> In case of hubs, that's generic_hub_poll(), which covers everything else. >> >> >> Patrick >> > >

1 0

Re: [coreboot] USB HUB depth
by Joshua Pincus 09 Mar '17

09 Mar '17

Hi, Cool. I'm looking at that code now. Thanks for your help. JP On Thu, Mar 9, 2017 at 10:29 AM, Patrick Georgi <pgeorgi(a)google.com> wrote: > 2017-03-09 18:53 GMT+01:00 Joshua Pincus <joshua.pincus(a)gmail.com>: > > Enable_port() merely provides power to those ports. It doesn't scan > them and then attach them in any way. > That happens on the next usb_poll(), which calls ->poll() for every device. > In case of hubs, that's generic_hub_poll(), which covers everything else. > > > Patrick >

1 0

Re: [coreboot] USB HUB depth
by Patrick Georgi 09 Mar '17

09 Mar '17

2017-03-09 18:53 GMT+01:00 Joshua Pincus <joshua.pincus(a)gmail.com>: > Enable_port() merely provides power to those ports. It doesn't scan them and then attach them in any way. That happens on the next usb_poll(), which calls ->poll() for every device. In case of hubs, that's generic_hub_poll(), which covers everything else. Patrick

1 0

Re: [coreboot] USB HUB depth
by Nico Huber 09 Mar '17

09 Mar '17

On 09.03.2017 11:18, Joshua Pincus wrote: > Hi, > > I'm new to coreboot and to this group. As this is my first post, let me > thank you folks for developing an impressive and incredibly useful product! Hi Joshua, > I recently fired up the coreboot USB stack on an x86 development board. > The USB stack reported back that I have 2 EHCI host controllers on the > board. Each controller, in turn, has a number of ports. Attached to at > most 1 of the ports beyond each controller is a USB 2.0 hub. Each hub, in > turn, has a number of ports which the coreboot USB stack enables. are you talking about libpayload's USB stack? coreboot itself doesn't have one. > > My issue is this: I see the host controllers get initialized. I see the > aforementioned hubs get initialized. I see the ports underneath those hubs > get enabled. I do not see nor can I find any existing code that scans and > attaches the ports associated with those hubs. Consequently, none of the > devices (aka keyboard, USB stick, etc.) plugged into the ports beyond those > hubs are scanned and attached. Put another way, it looks like the USB > stack, as currently written, only scans and attaches devices at tier 0 and > tier 1. Anything beyond the hub is merely enabled. > > Am I wrong or missing something? How difficult would it be to continue the > process of recursion to subsequent tiers? If you are talking about libpayload, there shouldn't be an artificial limit. Responsible for hub class USB devices is the code in drivers/usb/ generic_hub.c + drivers/usb/usbhub.c. Hope that helps, Nico

2 1

USB HUB depth
by Joshua Pincus 09 Mar '17

09 Mar '17

Hi, I'm new to coreboot and to this group. As this is my first post, let me thank you folks for developing an impressive and incredibly useful product! I recently fired up the coreboot USB stack on an x86 development board. The USB stack reported back that I have 2 EHCI host controllers on the board. Each controller, in turn, has a number of ports. Attached to at most 1 of the ports beyond each controller is a USB 2.0 hub. Each hub, in turn, has a number of ports which the coreboot USB stack enables. My issue is this: I see the host controllers get initialized. I see the aforementioned hubs get initialized. I see the ports underneath those hubs get enabled. I do not see nor can I find any existing code that scans and attaches the ports associated with those hubs. Consequently, none of the devices (aka keyboard, USB stick, etc.) plugged into the ports beyond those hubs are scanned and attached. Put another way, it looks like the USB stack, as currently written, only scans and attaches devices at tier 0 and tier 1. Anything beyond the hub is merely enabled. Am I wrong or missing something? How difficult would it be to continue the process of recursion to subsequent tiers? Thanks, JP

1 0

← Newer
1
...
18
19
20
21
22
23
24
...
27
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 March 2017