firmware
firmware copied to clipboard
MrChromebox
Acer Spin 13 can't sleep/hibernate on Linux
When attempting to do it anyway, the system either shuts down (when on battery) or the fans start spinning at 100% until you resume.
Some folks have said it's a tpm issue, bug apparently, TPM is disabled in the bios already.
Here's a post I wrote about this in the arch forums. There are no replies, but I've uploaded some logs there if you're interested: https://bbs.archlinux.org/viewtopic.php?id=250514
I'm running on 4.10 remix. The issue happens on UEFI as well as on legacy bios. On legacy bios, the boot flags or smth like that are also reset. This means that after the system is shut down like this (not via normal shut down), the white dev screen comes and when I try to boot from USB, it beeps and that's it. I can only boot Chrome OS at that point. If I recall correctly, before that, the "chrome is is dead" boot screen appears but after a restart it's like I described.
suspend/resume issues on the legacy BIOS are a product of Google's use of the TPM in their verified boot -- there's nothing I can do about that, it's an issue with the stock firmware.
with the UEFI firmware, I'd need to see the output of the EC serial console to see what's going on. Also highly recommended to update to the 4.11 release to avoid NVRAM issues
if you have a USB-C debug cable, log the EC console starting just prior to suspend, let it sit 30s or so, then wake up. That would help me see what's going on with the EC that the fan state isn't getting set properly.
Currently, I don't have one, but I found this thing on eBay: https://www.ebay.it/ulk/itm/122662276987
Would this work?
Nevermind, this probably won't work, since the Chromium website says that to access CCD, you need a SuzyQ cable which I obviously don't own and also can't purchase since it's out of stock and relatively expensive for a one time use with uncertain outcome. :(
Sparkfun shows backordered with 12/9 ETA: https://www.sparkfun.com/products/14746
Hmm, maybe I'll do it. If I get one, how would I read the EC console? I can use Windows or Arch Linux. I won't need any extra devices right?
minicom under Linux is all you'd need. I believe the EC console is readable by default, so you'd just need to connect the cable (correct port, orientation) start minicom on the proper port (-D /dev/ttyUSB2), and start logging
edit: fixed EC ttyUSB port. 0 is CCD, 1 is AP/CPU, 2 is EC
@CiriousJoker Were you able to make any progress on this? I'm running into this issue as well, and I was already considering the SuzyQ in case the flash broke. I ended up just partially unlocking the CCD and crossing my fingers really hard, but I'd still buy it if it meant finding a resolution.
I have the SuzyQable, if someone could walk me through what to do.
Edit: I'm lazy and didn't read the thread. I'll message again if I have any problems interpreting MrChromebox' original instructions.
Relevant question regarding the TPM. If I flash my EFI will I lose my keys? The reason I'm asking is because I'm going to make a full image backup, but if I lose the system key then that will make that useless since the cryptohome won't decrypt without it. I created individual backups of Android and Crostini which should cover my bases anyway, but I'd rather not deal with those because I'll still need to reconfigure some stuff again if I have to use them.
you'll lose the keys if you open the CCD as part of disabling the firmware write protect, since that will transition you out of Developer Mode and will wipe the TPM.
Thanks, I just discovered that :/
IRT the fan state, I was seeing some messages repeating over and over, "Fan 0 stalled", when suspending with ChromeOS at the first time setup screen. I haven't been able to get them to come up again since setting up the system and unlocking the CCD again.
I've attached the suspend logs from ChromeOS with the default firmware, for both CCD and EC ports. I'll do the same for Linux once I go through reflashing.
Was there a specific kernel I should be using? I'm using Xubuntu 19.10 with 5.3.0-46-generic.
Linux EC and CCD logs. The suspend was executed with systemctl suspend because it wasn't clear to me if the lid switch was actually doing the correct thing.
sleep_linux_ec.bin.gz sleep_linux_ccd.bin.gz
Would you be able to walk me through how you would use this information to debug the issue? I'm fairly technical and I want to help you. Also I would like to put CrOS back on my machine soon, but I've been putting it off in case you needed me to do something else.
@MrChromebox I'm also still interested in this, in case there's a fix, I'll try it out immediately
having looked at the logs, it's not providing me with any info as to why sleep would be failing, or why the fan wouldn't be resuming coming out of suspend. And I'm not seeing this problem on other (non-ChromeOS) KBL-U boards here
@MrChromebox Is it possible to do gdb debugging over the Cr50? Would that give you any useful information?
@empathicqubit I'm not sure, but I don't think so. one can query the fan state from the EC console though, so one could check the fan mode, RPM, duty cycle, etc before and after suspend
I don't think it's actually suspending so I'm not sure how useful that is, but I'll take a look. I also ran through all the commands in the EC and AP and got an output for that session. I'm not sure if that's useful.
Edit: There is a 32K memory dump in there. Given that it's so short I assume that's just a memory dump of the EC or the AP. I dunno.
Irrelevant to anything but I think it's funny that the stack has "deadd00d" in it when the system crashes.
Output with hcdebug every. I'm not sure it's actually anything different. It says the fan is "frustrated"
Actual: 0 rpm Target: 2982 rpm Duty: 100% Status: 3 (frustrated) Mode: rpm Auto: yes Enable: yes >
hcenabled0.bin.gz hcenabled2.bin.gz
Should the UART console be enabled and reporting over ttyUSB1, or am I getting that mixed up? Would that be useful?
the CPU UART (ttyUSB1) might show the coreboot log on resume, assuming it actually suspends and then tries to resume. Otherwise it's not going to show anything useful
I built coreboot myself and was able to enable a bunch of messages on the UART console as well as GDB. I was able to load the symbols and step through a bit. Probably useless though as it won't help determine what the correct suspend procedure is. I was thinking about trying to enable DCI in the ChromeOS IFD so that I could trace that instead and get more insight on what it's doing during suspend, but I'm not sure if that's even possible. I'm probably overcomplicating things.
What about the UART console for the ChromeOS kernel? There's a blank console option for it but I'm not sure if setting it will even do anything because documentation seems to imply that support needs to be compiled in and usually isn't.
Sorry for all the nonsense. I have no idea what I'm doing.
Probably useless though as it won't help determine what the correct suspend procedure is
every other SKL/KBL coreboot device I have access to suspends/resumes correctly, I'd find it very surprising if one board is having an issue, vs a kernel or driver issue
Should I close this bug and go complain to kernel devs? I want to help solve it I just need some direction.
I'd say leave it open in case, but definitely pursue the other route as well. I'll see if I can get another NAMI-based board for testing