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
Dear coreboot ThinkPad users,
with the current master (and next stable release) it is possible to
power cycle the BDC (Bluetooth Daughter Card) from within an ACPI
compliant OS.
As the implementation follows the vendors one, all you need is to use
existing drivers, like the thinkpad_acpi kernel module on GNU/Linux.
You can use keyboard shortcuts or toggle it from the desktop
environment's settings dialog.
It should work with all ThinkPads currently supported by coreboot.
Please test it, hack it or give feedback.
Regards,
Patrick
Hi Matthias,
The dsdt.dsl is a static file, generated at build time. The ssdt.dsl is generated at each boot.
Is there a HBDC in the ssdt.dsl under the same scope ?
Regards Patrick
Am 14. Juli 2018 00:08:09 MESZ schrieb Matthias Gazzari <mail(a)qtux.eu>:
>Hi Patrick,
>
>I built with the current origin/master, so the Nehalem fix
>https://review.coreboot.org/#/c/coreboot/+/26287/ is already included.
>I
>see "ACPI: * H8" and have the following mentions of HBDC inside the
>dsdt.dsl:
>
>External (HBDC, IntObj)
>
>and
>
>Method (GBDC, 0, NotSerialized)
>{
> If (HBDC)
> {
> Local0 = One
> If (BTEB)
> {
> Local0 |= 0x02
> }
>
> Local0 |= 0x04
> Return (Local0)
> }
> Else
> {
> Return (Zero)
> }
>}
>
>Method (SBDC, 1, NotSerialized)
>{
> If (HBDC)
> {
> Local0 = ((Arg0 & 0x02) >> One)
> BTEB = Local0
> }
>}
>
>Hope that helps.
>
>Cheers,
>Matthias
>
>On 13/07/18 23:41, Patrick Rudolph wrote:
>> Hi Matthias,
>> It looks like the Ssdt generator on x201/nehalem doesn't work as
>expected.
>> It was broken and has been fixed in commit
>https://review.coreboot.org/#/c/coreboot/+/26287/
>> Do you see "ACPI: * H8" in coreboot console log ?
>> Do you see any HBDC method in disassembled ACPI ?
>> Regards Patrick
>>
>> Am 13. Juli 2018 22:46:12 MESZ schrieb Matthias Gazzari
><mail(a)qtux.eu>:
>>> Hello,
>>>
>>> commit f1114d891865e70ae1f2ba58844fec11d055ae3a (ec/lenovo/h8/acpi:
>Add
>>> BDC interface) introduces the following ACPI errors on the Lenovo
>>> X201i:
>>>
>>> ACPI BIOS Error (bug): Could not resolve [\_SB.EC.HKEY],
>AE_NOT_FOUND
>>> (20180313/dswload2-160)
>>> ACPI Error: AE_NOT_FOUND, During name lookup/catalog
>>> (20180313/psobject-221)
>>> ACPI Error: Ignore error and continue table load
>>> (20180313/psobject-604)
>>> ACPI Error: Skipping Scope block (20180313/psloop-532)
>>>
>>> and
>>>
>>> ACPI BIOS Error (bug): Could not resolve
>>> [\_SB.PCI0.LPCB.EC.HKEY.GBDC.HBDC], AE_NOT_FOUND
>(20180313/psargs-330)
>>> ACPI Error: Method parse/execution failed
>\_SB.PCI0.LPCB.EC.HKEY.GBDC,
>>> AE_NOT_FOUND (20180313/psparse-516)
>>>
>>> Do you have any idea on how to fix these issues?
>>>
>>> Cheers,
>>> Matthias
>>>
>>> --
>>> coreboot mailing list: coreboot(a)coreboot.org
>>> https://mail.coreboot.org/mailman/listinfo/coreboot
>>
>
>
>--
>coreboot mailing list: coreboot(a)coreboot.org
>https://mail.coreboot.org/mailman/listinfo/coreboot
--
Diese Nachricht wurde von meinem Android-Gerät mit K-9 Mail gesendet.
Another regression I have noticed is that my 4th SATA hard drive doesn't
appear in linux for some reason, although it does appear in grub...ideas?
Also kyosti what logs and tests would you like? For now I have
re-flashed my old 4.6 coreboot but I will flash master again soon for you.
Tim - Yes I have CC6 enabled in my CMOS and my CMOS.default
Hi Matthias,
It looks like the Ssdt generator on x201/nehalem doesn't work as expected.
It was broken and has been fixed in commit https://review.coreboot.org/#/c/coreboot/+/26287/
Do you see "ACPI: * H8" in coreboot console log ?
Do you see any HBDC method in disassembled ACPI ?
Regards Patrick
Am 13. Juli 2018 22:46:12 MESZ schrieb Matthias Gazzari <mail(a)qtux.eu>:
>Hello,
>
>commit f1114d891865e70ae1f2ba58844fec11d055ae3a (ec/lenovo/h8/acpi: Add
>BDC interface) introduces the following ACPI errors on the Lenovo
>X201i:
>
>ACPI BIOS Error (bug): Could not resolve [\_SB.EC.HKEY], AE_NOT_FOUND
>(20180313/dswload2-160)
>ACPI Error: AE_NOT_FOUND, During name lookup/catalog
>(20180313/psobject-221)
>ACPI Error: Ignore error and continue table load
>(20180313/psobject-604)
>ACPI Error: Skipping Scope block (20180313/psloop-532)
>
>and
>
>ACPI BIOS Error (bug): Could not resolve
>[\_SB.PCI0.LPCB.EC.HKEY.GBDC.HBDC], AE_NOT_FOUND (20180313/psargs-330)
>ACPI Error: Method parse/execution failed \_SB.PCI0.LPCB.EC.HKEY.GBDC,
>AE_NOT_FOUND (20180313/psparse-516)
>
>Do you have any idea on how to fix these issues?
>
>Cheers,
>Matthias
>
>--
>coreboot mailing list: coreboot(a)coreboot.org
>https://mail.coreboot.org/mailman/listinfo/coreboot
--
Diese Nachricht wurde von meinem Android-Gerät mit K-9 Mail gesendet.
Hello,
commit f1114d891865e70ae1f2ba58844fec11d055ae3a (ec/lenovo/h8/acpi: Add
BDC interface) introduces the following ACPI errors on the Lenovo X201i:
ACPI BIOS Error (bug): Could not resolve [\_SB.EC.HKEY], AE_NOT_FOUND
(20180313/dswload2-160)
ACPI Error: AE_NOT_FOUND, During name lookup/catalog (20180313/psobject-221)
ACPI Error: Ignore error and continue table load
(20180313/psobject-604)
ACPI Error: Skipping Scope block (20180313/psloop-532)
and
ACPI BIOS Error (bug): Could not resolve
[\_SB.PCI0.LPCB.EC.HKEY.GBDC.HBDC], AE_NOT_FOUND (20180313/psargs-330)
ACPI Error: Method parse/execution failed \_SB.PCI0.LPCB.EC.HKEY.GBDC,
AE_NOT_FOUND (20180313/psparse-516)
Do you have any idea on how to fix these issues?
Cheers,
Matthias
On 07/12/2018 10:41 PM, Kyösti Mälkki wrote:
> On Fri, Jul 13, 2018 at 5:41 AM, Timothy Pearson
> <tpearson(a)raptorengineering.com <mailto:tpearson@raptorengineering.com>>
> wrote:
>
> Good to know, thanks for testing! I've been looking into relocateable
> ramstage in case suspend was still failing, but if things fell back into
> place, so to speak, in master we should also look at reactivating REACTS
> with the suspend tests enabled.
>
>
> I never suspected RELOCATABLE_RAMSTAGE=n would be a reason for
> (possible) S3 regressions. The motivation for having
> RELOCATABLE_RAMSTAGE=y goes beyond the improvement it has on not having
> to do low-mem backup S3 resume path. I am also wondering how S3 resume
> path is taking one minute and how that relates to normal boot path time.
>
> Kyösti
My understanding is that without relocateable ramstage, there are
additional bounce buffers involved that not only slow things down, but
also introduce new code paths that could be responsible for regressions
in resume. I think avph on IRC is looking into an initial port of the
CAR code for relocateable support, and if things are stable enough in
master to reactivate the REACTS tests on the KGPE-D16 that would help
him iterate more quickly.
--
Timothy Pearson
Raptor Engineering
+1 (415) 727-8645 (direct line)
+1 (512) 690-0200 (switchboard)
https://www.raptorengineering.com
On 06/15/2018 03:33 AM, Kyösti Mälkki wrote:
> On Fri, Jun 15, 2018 at 8:58 AM, Taiidan(a)gmx.com <Taiidan(a)gmx.com> wrote:
>
>> On 06/14/2018 08:42 PM, Kyösti Mälkki wrote:
>>> On Thu, Jun 14, 2018 at 4:38 AM, qtux <mail(a)qtux.eu> wrote:
>>> Now, since commit babb2e6 that claims to add S3 support on kgpe-d16 is
>>> within the latter period, I do not quite see how S3 support could have
>>> worked with that commit on kgpe-d16. Or maybe this feature was never
>>> retested once it was rebased and upstreamed. Nor can I see how it
>>> could have worked for any commit in 4.6
>>
>> I just tested S3 again and it worked fine on my v4.6 D16.
>>
>
> Please state the commit hash of the source tree you built and booted from,
> we don't literally have such tag as "v4.6".
I was using the coreboot-4.6.tar.xz from the coreboot download page
which is why I didn't include the hash.
[ 0.000000] DMI: ASUS KGPE-D16/KGPE-D16, BIOS
4.6-db508565d2483394b709654c57533e55eebace51 07/10/2017
>
> Repeat tests with current master.
Thanks, I will have info for you by the end of the this weekend and I
will also investigate things myself if S3 doesn't work...
