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
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
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
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
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
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
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
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
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
