Closed travankor closed 5 years ago
MrChromebox
commented
5 years ago I don't have any clue how to begin to debug that, I don't believe there's any sort of power management since it's not expected that you'd stay in the UEFI setup for any amount of time.
As for changing the lid open behavior, that would require a custom firmware build, if not a custom EC build (but pretty sure I can disable that as a wake source from coreboot)
travankor
commented
5 years ago After doing some testing, it seems like the unexpected power-ons are actually caused by a combination of wiggling/rotating the laptop (the lid opens slightly) and then plugging the laptop into an AC power brick. This only happened ~20% of the time; the firmware behaved normally for the rest of the time.
In any case, I can't reliably reproduce how the laptop turns on unexpectedly. I never experienced this problem with SeaBIOS or Depthcharge.
I think the fastest way to "fix" this would be to just make the power button the only way to turn it on, but maybe there is some trivial bug out there or some portion of the firmware got corrupted when I flashed it (I was fairly careful when flashing, though; I took multiple firmware dumps and had flashrom verify the payload several times).
travankor
commented
5 years ago As for changing the lid open behavior, that would require a custom firmware build, if not a custom EC build (but pretty sure I can disable that as a wake source from coreboot)
@MrChromebox Could you do this when/before 4.10 firmware gets tagged and built?
MrChromebox
commented
5 years ago because this is a significant change and breaks the expected functionality of the device, it's not something I'd liky do for the public release. I could probably do a one-off for you though (since you'd need a ME disabled build anyway)
nyxb71
commented
5 years ago I also have this problem with my LULU (firmware version 4.9), I've been investigating workarounds but would appreciate firmware that prevents it. On my LULU there is a ~2-3mm gap between the screen bezel and body of the laptop when closed (without pressure on the lid), so maybe the it thinks the lid is open.
travankor
commented
5 years ago Personally, I probably will switch back to the stock Depthcharge/BIOS firmware since that one works with the EC. Don't have time to deal with Intel's bugwarez. JSC's blog and the Arch wiki seem to describe how to overcome the annoyances of the default Chromebook firmware.
MrChromebox
commented
5 years ago the stock Depthcharge/BIOS firmware since that one works with the EC
huh?
JSC's blog and the Arch wiki seem to describe how to overcome the annoyances of the default Chromebook firmware.
why are those mitigations not valid for my firmware?
travankor
commented
5 years ago huh?
I mean the RW_Legacy firmware doesn't run into this issue. I mistakenly treated RW_Legacy and stock as the same thing.
JSC's blog and the Arch wiki seem to describe how to overcome the annoyances of the default Chromebook firmware.
why are those mitigations not valid for my firmware?
They are valid, but you don't actually document the caveats of RW_Legacy with SeaBIOS on your site since you assume everyone uses UEFI, ie:
https://wiki.archlinux.org/index.php/Chromebook#Fixing_suspend
JSC describes how to setup a custom bitmap image for the splash screen, which is not needed, but looks nice.
I'm sure the fix is something trivial, but UEFI is more complex/confusing to me than BIOS (especially a half-baked implementation like Tianocore).
MrChromebox
commented
5 years ago I mean the RW_Legacy firmware doesn't run into this issue. I mistakenly treated RW_Legacy and stock as the same thing.
they are. RW_LEGACY is just a legacy BIOS bootloader. It doesn't/can't change any of the hardware init done by coreboot
They are valid, but you don't actually document the caveats of RW_Legacy with SeaBIOS on your site since you assume everyone uses UEFI, ie:
I don't document issues with Google's stock firmware, no -- not when there's 60+ devices and growing that I support. And most of those issues are better handled with hardware/distro-specific files like the Arch wiki. I'll fix firmware-related issues that I can with my UEFI firmware, and document those I can't via this issue tracker.
JSC describes how to setup a custom bitmap image for the splash screen, which is not needed, but looks nice.
no idea who or what JSC is, and Google is no help
I'm sure the fix is something trivial, but UEFI is more complex/confusing to me than BIOS (especially a half-baked implementation like Tianocore).
the bootloader isn't the issue. SeaBIOS vs Tianocore has no bearing here. All they do is provide a mechanism to boot the OS. coreboot does all the heavy lifting.
travankor
commented
5 years ago In case anyone finds this useful, I finally "resolved" all the firmware/hardware issues with my Lulu (just in time for school, too).
Idling on the UEFI shell generates a lot of heat and quickly drains battery. Reproduce by staying on th UEFI shell or menu for ~30 minutes on a Lulu Broadwell i3.
Regression in Tianocore EDK 201811. EDK 201808 did not burn my fingers.
Additionally, whenever my desktop sway session crashes, the computer reverts to some UEFI state and generates a lot of heat. The fans turn on in the UEFI after this sort of crash, but otherwise the fans don't work when initially booting.
Intel GPU bug that hasn't been fixed five years later :/
Need to pass intel_iommu=igfx_off as a kernel parameter.
In any case, I can't reliably reproduce how the laptop turns on unexpectedly.
Regression in coreboot 4.9.
Idling on the UEFI shell generates a lot of heat and quickly drains battery. Reproduce by staying on th UEFI shell or menu for ~30 minutes on a Lulu Broadwell i3. (Also disabled ME, but I doubt it's related)
Additionally, whenever my desktop sway session crashes, the computer reverts to some UEFI state and generates a lot of heat. The fans turn on in the UEFI after this sort of crash, but otherwise the fans don't work when initially booting.
This is somewhat problematic since the UEFI turns on when the lid is opened. When I commute, the lid might accidently open slightly and then I end up at school with a very hot laptop with a drained battery.
Not sure how difficult this is to fix/debug, but a way to disable auto-turning on of the UEFI when the lid opens would effectively mitigate this for me and save me from a lot of trouble.