I’m seeing problematic power button behavior on my ASUS C302 (Intel m3-6Y30 Skylake) Flip Chromebooks. With the lid closed the power button will not power on the C302 for a repeatable one hour and 20 seconds after shutdown, which is good, but after that it will. This is a problem because the power button can easily get bumped while the C302 is being transported.
When this happens on my ChromeOS C302 the EC powers on the AP and coreboot executes, which in turn boots ChromeOS which shuts down immediately, mitigating the problem.
When this happens on my Fedora 35 C302 the EC powers on the AP and coreboot (MrChromebox coreboot_tiano-cave-mrchromebox_20220718.rom UEFI) executes, which in turn boots Fedora 35 which then waits indefinitely for a LUKS passphrase to be entered, eventually resulting in a fully discharged battery.
I would like to fix this and need help/advice.
I think it’s an EC problem, not a coreboot problem, but I’m not sure. The C source file ec/common/power_button.c contains code in raw_power_button_pressed() that ignores the power button if the laptop lid is closed. That code has changed over time, becoming conditionally compiled depending on CONFIG_POWER_BUTTON_IGNORE_LID, and I don’t know which version of the EC code is in these C302s, but the fact that the power button is ignored with the lid closed for the first one hour and 20 seconds suggests that this code is present in these EC instances.
I’m stumped by the change in power button behavior after one hour and 20 seconds. This is repeatable on four C302 laptops. At first I thought this might be a charge leakage problem in hardware lid switch circuitry or something like that, but it’s the same on all four C302 laptops, and is consistently repeatable, so I think that pretty much rules out hardware. That leaves softwwhatare as the cause. Maybe an overflow in a timer? A 32 bit unsigned integer overflow in a microsecond timer occurs in approximately one hour 12 minutes, not one hour 20 seconds, so that’s not it.
What could be causing this, and how can it be fixed? I’ve thought about adding code to a custom version of coreboot to request the EC to power down the AP if coreboot is booted while the laptop lid is closed, but I’m not sure this is the best approach. Does coreboot have knowledge of the laptop lid state? I’ve also thought about adding code to a custom linux kernel to shut down during boot if the laptop lid is closed, but by the time the kernel has knowledge of the laptop lid state the boot is already well advanced – better to power down much earlier, in either coreboot or preferably the EC.
I would welcome any comments or suggestions for solving this problem. Thank you in advance. -Dindoo