April 28, 2018 5:40 PM, "Kyösti Mälkki" kyosti.malkki@gmail.com wrote:
I thought I had seen some other message [1] on the list regarding X201(i) not booting or resuming. Looking at your boot log ending on "0:1f.0 final", it appears we are looking at the same commit which adds INTEL_CHIPSET_LOCKDOWN implementation in lpc_final(). The commit message tells it was not tested for ibexpeak so you may want to try revert that one before going for full bisect.
[1] https://mail.coreboot.org/pipermail/coreboot/2018-April/086564.html [2] https://review.coreboot.org/c/coreboot/+/21129
Kyösti
You're right, that's the broken commit, see attached logs.
April 28, 2018 5:59 PM, "Nico Huber" nico.h@gmx.de wrote:
Yes, that's very likely a problem. It looks like the whole finalize code path of the X201 was untested all the time (even on resume). I don't remember if EHCI debug works in SMM? If it does, you could enable log- ging for the SMI handler as well (if you want to debug it).
Nico
Attached you can find the log with the SMM debug enabled, but it doesn't seem to me much different from the non-debug log.
Nicola
On Sun, Apr 29, 2018 at 1:35 PM, Nicola Corna nicola@corna.info wrote:
April 28, 2018 5:59 PM, "Nico Huber" nico.h@gmx.de wrote:
Yes, that's very likely a problem. It looks like the whole finalize code path of the X201 was untested all the time (even on resume). I don't remember if EHCI debug works in SMM? If it does, you could enable log- ging for the SMI handler as well (if you want to debug it).
Nico
Attached you can find the log with the SMM debug enabled, but it doesn't seem to me much different from the non-debug log.
Nicola
DEBUG_SMI does not output to EHCI, I have considered it too unstable.
You can try your luck with attached patch to have DEBUG_SMI=y output on EHCI debug. EHCI console code does not take precautions against someone else touching the same register set so it's likely to fail once payload and/or OS loads its EHCI driver, possibly making USB media and keyboard unusable as well.
Kyösti