coreboot July 2018

coreboot@coreboot.org

39 participants
72 discussions

Re: [coreboot] More ACPI errors on Lenovo X201i

by Patrick Rudolph

Hi Matthias, On 2018-07-23 03:32 PM, Matthias Gazzari wrote: > Hi Patrick, > > I found new ACPI errors on my Lenovo X201i: > > commit "60eca531df ec/lenovo/h8/acpi: Add WWAN ACPI methods" introduces > the following error just before shutdown: > > thinkpad_acpi_ acpi_evalf(\WGSV, vd, ...) failed: AE_NOT_FOUND > Is expected, as the method doesn't exists in coreboot. I'm working on a cmos acpi driver, allowing easy integration of that method. If you want you can implement a stub driver (emtpy function) in the meantime. > and commit "31fb846c59 ec/lenovo/h8/acpi: Apply state on wake" > introduces the following errors on boot: > > ACPI Error: No handler for Region [ERAM] ( (ptrval)) > [EmbeddedControl] (20180313/evregion-132) > ACPI Error: Region EmbeddedControl (ID=3) has no handler I've no idea what the problem is. Is there an ACPI expert here ? > (20180313/exfldio-265) > ACPI Error: Method parse/execution failed \_SB.PCI0.LPCB.EC.HKEY._INI, > AE_NOT_EXIST (20180313/psparse-516) > ACPI Error: AE_NOT_EXIST, during \_SB.PCI0.LPCB.EC.HKEY._INI execution > (20180313/nsinit-670) > > Cheers, > Matthias Regards, Patrick

2 years

Re : restrict SMI

by echelon＠free.fr

Thank you Ron, Just curious, about who could be the originator of this "future OS requirement", but I guess that anyone can guess his identity.. ;-) Anyway is good to see that common sense prevails (SMM dies) .. finally .. but I fear that the "clients" that until now were dependent of this kind of service will "migrate" to another "service provider".. (give me a "M", give me a "E", .. oh nevermind.. sorry just jocking .. lets not start another flame war.. ;-)) Florentin ----- Mail d'origine ----- De: ron minnich <rminnich(a)gmail.com> À: coreboot <coreboot(a)coreboot.org> Envoyé: Sun, 29 Jul 2018 23:54:19 +0200 (CEST) Objet: [coreboot] restrict SMI Florentin wrote this: I just peeked inside the pdf and tumbled upon the following statement (page4): "The latest reasoning for replacement of SMI is driven by a future OS requirement that restricts the use of SMI as a means to communicate with the system firmware." Can someone enlighten me what this "future OS requirement" means?.. Thanks in advance, Florentin OK, the future OS requirement is not complicated in my view. Nobody trusts SMM, or should ever have trusted SMM from the beginning, and many companies have reached the decision that SMM is a monstrous security hole and must die. SMI being the way one gets into SMM, both SMI and SMM are, we hope, soon to be a thing of the past. Not soon enough for me ... ron

2 years

restrict SMI

by ron minnich

Florentin wrote this: I just peeked inside the pdf and tumbled upon the following statement (page4): "The latest reasoning for replacement of SMI is driven by a future OS requirement that restricts the use of SMI as a means to communicate with the system firmware." Can someone enlighten me what this "future OS requirement" means?.. Thanks in advance, Florentin OK, the future OS requirement is not complicated in my view. Nobody trusts SMM, or should ever have trusted SMM from the beginning, and many companies have reached the decision that SMM is a monstrous security hole and must die. SMI being the way one gets into SMM, both SMI and SMM are, we hope, soon to be a thing of the past. Not soon enough for me ... ron

2 years

Re: [coreboot] Intel GMA: Backlight brightness driver

by Patrick Rudolph

On 2018-07-29 06:39 PM, Alexander Couzens wrote: > Hi Patrick, > > thanks for your work. > Are there any documentation or description what Mailbox 3 support is? > Where it come from? > It's documented here: https://01.org/sites/default/files/documentation/skl_opregion_rev0p5.pdf > Best, > lynxis

2 years

Intel GMA: Backlight brightness driver

by Patrick Rudolph

Dear coreboot users, The following commit adds Mailbox 3 support for improved panel back- light brigthness control on Intel GMA platforms. It fixes the problem with 100% brightness on S3 resume. Please test and review https://review.coreboot.org/#/c/coreboot/+/27711 / Regards, Patrick

2 years

Digital Archeology

by ron minnich

This remind's me of rudolf marek's revival of pc basic in 2014. http://www.chrisfenton.com/cray-1-digital-archeology/

2 years

Re: [coreboot] Kaby Lake FSP

by Desimone, Nathaniel L

Hi Youness, Per your specific question, I am working through the laundry list of approvals to publish Coffee Lake binaries right now. Its "in the works." I'll post an announcement once it is up. Thanks, Nate -----Original Message----- From: Youness Alaoui [mailto:kakaroto@kakaroto.homelinux.net] Sent: Wednesday, July 25, 2018 3:40 PM To: Desimone, Nathaniel L <nathaniel.l.desimone(a)intel.com> Cc: coreboot <coreboot(a)coreboot.org> Subject: Re: [coreboot] Kaby Lake FSP Great, thanks! I understand that as platform ages, it gets less development, I was mostly asking because I saw that coffeelake FSP headers are in coreboot but there are no FSP images for coffeelake on github yet, which is basically the same/similar issue as what we complained about with regards to Kabylake, and your answer was only about Kabylake, so I was hoping other platforms are "in the works" for being kept up to date between public and "internal" releases. Thanks, Youness. On Wed, Jul 18, 2018 at 8:05 PM Desimone, Nathaniel L <nathaniel.l.desimone(a)intel.com> wrote: > > Hi Youness, > > In general yes, Intel does plan to continue developing of FSP for future platforms. We will make a good faith effort to keep the publically posted FSP binary freshly updated. I would like to caution that as a platform ages, our internal development shifts to newer ones. Accordingly, I would expect the frequency of FSP releases to lengthen as a platform ages. > > Thanks, > Nate > > -----Original Message----- > From: Youness Alaoui [mailto:kakaroto@kakaroto.homelinux.net] > Sent: Monday, July 16, 2018 12:29 PM > To: Desimone, Nathaniel L <nathaniel.l.desimone(a)intel.com> > Cc: coreboot <coreboot(a)coreboot.org> > Subject: Re: [coreboot] Kaby Lake FSP > > Hi Nate, > > Thanks a lot for listening to our request and taking care of this! I'm happy to see the binaries finally updated and the FSP headers in coreboot having a matching publicly available binary to use. > You've only mentioned Kabylake in your email, is it safe to assume that you'll use these same practices for future platforms as well ? > > Thanks, > Youness. > On Tue, Jul 10, 2018 at 9:04 PM Desimone, Nathaniel L <nathaniel.l.desimone(a)intel.com> wrote: > > > > Hi All, > > > > I am a UEFI firmware architect working for Intel Corp. One of my focus areas is FSP. There was some prior discussion here regarding the lack of public updates for Kaby Lake FSP binaries and headers and questions regarding specialized FSP binaries being built for specific boards. I would like to clear up some of these questions and concerns. We just pushed all of the recently released versions of Kaby Lake FSP (3.1.0 through 3.6.0) to https://github.com/IntelFsp/FSP/tree/Kabylake. While there might appear to be forks of Kaby Lake FSP, they are actually just snapshots at different points in time. For example, there is one commit labelled as "Gold release for Kaby Lake FSP" that appears to be special fork for IoT devices... this commit is actually just Kaby Lake FSP Release 2.6.0 without any IoT specific modifications. Apologies for the confusing commit messages and for the temporary lapse in updates. > > > > With Best Regards, > > > > Nate > > > > -- > > coreboot mailing list: coreboot(a)coreboot.org > > https://mail.coreboot.org/mailman/listinfo/coreboot

2 years

Re: [coreboot] Kaby Lake FSP

by Youness Alaoui

Great, thanks! I understand that as platform ages, it gets less development, I was mostly asking because I saw that coffeelake FSP headers are in coreboot but there are no FSP images for coffeelake on github yet, which is basically the same/similar issue as what we complained about with regards to Kabylake, and your answer was only about Kabylake, so I was hoping other platforms are "in the works" for being kept up to date between public and "internal" releases. Thanks, Youness. On Wed, Jul 18, 2018 at 8:05 PM Desimone, Nathaniel L <nathaniel.l.desimone(a)intel.com> wrote: > > Hi Youness, > > In general yes, Intel does plan to continue developing of FSP for future platforms. We will make a good faith effort to keep the publically posted FSP binary freshly updated. I would like to caution that as a platform ages, our internal development shifts to newer ones. Accordingly, I would expect the frequency of FSP releases to lengthen as a platform ages. > > Thanks, > Nate > > -----Original Message----- > From: Youness Alaoui [mailto:kakaroto@kakaroto.homelinux.net] > Sent: Monday, July 16, 2018 12:29 PM > To: Desimone, Nathaniel L <nathaniel.l.desimone(a)intel.com> > Cc: coreboot <coreboot(a)coreboot.org> > Subject: Re: [coreboot] Kaby Lake FSP > > Hi Nate, > > Thanks a lot for listening to our request and taking care of this! I'm happy to see the binaries finally updated and the FSP headers in coreboot having a matching publicly available binary to use. > You've only mentioned Kabylake in your email, is it safe to assume that you'll use these same practices for future platforms as well ? > > Thanks, > Youness. > On Tue, Jul 10, 2018 at 9:04 PM Desimone, Nathaniel L <nathaniel.l.desimone(a)intel.com> wrote: > > > > Hi All, > > > > I am a UEFI firmware architect working for Intel Corp. One of my focus areas is FSP. There was some prior discussion here regarding the lack of public updates for Kaby Lake FSP binaries and headers and questions regarding specialized FSP binaries being built for specific boards. I would like to clear up some of these questions and concerns. We just pushed all of the recently released versions of Kaby Lake FSP (3.1.0 through 3.6.0) to https://github.com/IntelFsp/FSP/tree/Kabylake. While there might appear to be forks of Kaby Lake FSP, they are actually just snapshots at different points in time. For example, there is one commit labelled as "Gold release for Kaby Lake FSP" that appears to be special fork for IoT devices... this commit is actually just Kaby Lake FSP Release 2.6.0 without any IoT specific modifications. Apologies for the confusing commit messages and for the temporary lapse in updates. > > > > With Best Regards, > > > > Nate > > > > -- > > coreboot mailing list: coreboot(a)coreboot.org > > https://mail.coreboot.org/mailman/listinfo/coreboot

2 years

Doubts about link scripts

by 王翔

I try to read link scripts of coreboot. In addition to the x86 platform, code segments and data segments are contiguous during the bootblock/romstage phase. However, only CAR/SRAM can be used as memory in the bootblock/romstage stage, this should be separate from the flash where the program is located. Why this is not reflected in the link script？ Does the machine have a special mechanism ? Looking forward to your reply !!! WangXiang

2 years

Re: [coreboot] fsp_broadwell_de: USB keyboard and mouse doesn't work.

by David Hendricks

Hello Jose, On Mon, Jul 23, 2018 at 5:23 AM, Jose Trujillo via coreboot <coreboot(a)coreboot.org> wrote: > Dear coreboot developers: > > I am trying to create CB firmware for Broadwell-D 1559 system using > CamelBack Mountain CRB as mainboard selection, and the system boots Windows > and Linux operating systems but USB keyboard and mouse doesn't work. > > I already enable/disabled EHCI/xHCI devices in devicetree without success. > I tried Seabios and Tianocore without success. > > Anyone had experience this issue? EHCI support may need to be enabled in FSP. What version of coreboot are you using? I added a Kconfig option to enable the EHCI controllers using UPD values: https://review.coreboot.org/c/coreboot/+/26042 > Any advise will be appreciated. > Thank you, > Jose Trujillo. > > -- > coreboot mailing list: coreboot(a)coreboot.org > https://mail.coreboot.org/mailman/listinfo/coreboot

2 years

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

coreboot July 2018