I’m not sure where the best place is to report this, but the ECDT ACPI table on the Framework (at least the i5 model) points to an invalid device in the DSDT:
[03Ch 0060 4] UID : 00000001
[040h 0064 1] GPE Number : 6E
[041h 0065 20] Namepath : "\_SB.PC00.LPCB.H_EC"
That should probably point to \_SB.PC00.LPCB.EC0 which is the actual PNP0C09 device.
Thanks for reporting this. This is the best place to report it. CC @Kieran_Levin
Hi, while fixing some things in OpenBSD to make it work better on the Framework Laptop, I was debugging why closing the lid didn’t cause the system to suspend, despite there being a PNP0C0D device in the DSDT and the acpibtn driver attaching to it. It ended up being the ECDT pointing at a bogus device which is preventing the acpiec driver from properly attaching to the PNP0C09 device (EC0) where all of the notifications are defined, so notifications are generated when the lid is closed but they don’t reach the acpiec driver for processing into an actual S3 suspend request.
@jcs we will fix this in bios 3.04.
Great support, thanks @Kieran_Levin! Any rough idea when the next BIOS upgrade might appear? Thx
We are preparing 3.03 now for beta testing and then release. 3.04 would be the follow-on, and there are a few items pending completion before we can start a release schedule for it.
This looks like an OpenBSD ACPI issue rather than something specific to the Framework. The early ECDT-based attach in acpiec(4) assumes that the ECDT namepath identifies the same EC device as the AML-defined PNP0C09 node. On newer systems this assumption doesn’t seem to hold. If the ECDT namepath refers to a different object, the early attach can bind to the wrong node. In that case the real EC device never attaches, which would explain a non-functional EC (e.g. missing battery data). A better approach would be to treat ECDT as bootstrap information only, and defer EC device attachment until after the AML namespace has been enumerated.