Hello!
I wanted to share my experiences with corebooting the X131e (Intel edition) and hope to be able to resolve some of the remaining issues. Previously I used a corebooted X131e Chromebook (Stout) and it worked perfectly - I didn't have any of the issues, which I'm going to detail further down. I got the X131e Intel as an "upgrade" and because I thought that migrating would be trivial. I'm using the same peripherals with the Intel boards, but installed new RAM. Turns out the stock BIOS had hardware whitelists, so that was a good pretext to try out coreboot.
I based my build on the 4.9 release but ended up applying some X131e patches by James Ye, which are still pending in Gerrit. The following changes on top of 4.9 to be precise:
commit b21539d2c4f57518b964949b30ebdd200a8d1f5a Author: James Ye jye836@gmail.com Date: Thu Jan 24 00:18:28 2019 +1100
mb/lenovo/x131e: add function key support
Enables function keys for X131e. SMI handler based on google/stout. ACPI code and event masks are reverse-engineered.
The IT8518e EC of this board uses some different ACPI methods compared to the regular Lenovo H8. Add an option to use the alternative set of methods.
Change-Id: Ib3a01f37a8b54889b55e92c501c9350e6c68bd57
commit 178cf723697b9d069810fd404dcabd448d136503 Author: James Ye jye836@gmail.com Date: Fri Feb 1 13:29:02 2019 +1100
mb/lenovo/x131e: correct USB port config
Based on schematic and register dumps.
Change-Id: I91fc47022988cfe986fb8c1ed21dc073ee7d16bc
commit 750432f7a1487175243065d95c57f9e0e6c21204 Author: James Ye jye836@gmail.com Date: Tue Feb 12 22:17:52 2019 +1100
mb/lenovo/x131e: enable mSATA slot
Per google/stout. Functionality untested.
Change-Id: I7cc9837f572236acac2007e95990e64c25a5d6e2
commit 151019a9d21c612834dacad649cde7aec3132844 Author: James Ye jye836@gmail.com Date: Sat Jan 19 18:25:44 2019 +1100
mb/lenovo/x131e: enable WWAN detection
Per schematic. Non-presence is detected correctly, but presence is untested.
Change-Id: I4cfefb06556c9d69bc8e4a4f9d112246885c253a
commit 5bdb3cd2a802b0654feeeb19471c719db62a23c4 Author: James Ye jye836@gmail.com Date: Sat Jan 19 18:25:04 2019 +1100
mb/lenovo/x131e: remove PMH7
This board does not have PMH7.
Change-Id: I382958f012e5f4445efc76c7f36bbdf460c29be4
commit 1cd0a5920fb93489aa1fe5b1c0be6170f88f23da Author: James Ye jye836@gmail.com Date: Thu Jan 17 22:00:14 2019 +1100
mb/lenovo/x131e: add VBT
VBT was extracted from VBIOS ROM. Tested with libgfxinit, booting SeaBIOS into Linux.
Change-Id: Ibedb43852dc9b846850e1070b84f708c847b7dbf
Here's the board-status report: https://coreboot.org/status/board-status.html#lenovo/x131e
The EC is probably rather old, as I didn't do a BIOS upgrade before flashing coreboot. If possible, I'd like to avoid upgrading the EC now, as that would require extracting it from the Lenove BIOS and programming it externally. Isn't it?
Now regarding the remaining issues, in order of significance (for me):
1.) There are infrequent system freezes - possibly a kernel panic? - without any visible reason in the system journal. Unfortunately, I haven't run the board long enough on the original BIOS to judge whether this is Coreboot-specific. At least I tried performing some SMART and memtest86 tests - to no avail.
2.) At some point during my experimenting, only 4 of the 8GB RAM I've installed would be detected. This wasn't the case in the beginning, when I started out with a clean 4.9-build. I've attached a board status report from this time. Maybe somebody can see why the 2nd 4GB module is no longer detected. Naturally, one of the commits I later added might be responsible. If really necessary, I could do a git-dissect.
3.) The internal speakers __sometimes__ don't work after startup. They are simply mute. I initially thought this depends on the headphones being plugged in at boot, but there is no causal relation. None of the thinkpad_acpi-kernel-modules' `volume_*` params have any effect. Changing the settings of the enigmatic "ThinkPad Console Audio Control" sound card (created if volume_mode != 2 (N/A)) does not have any audible effect at all - even while headphones are working. Rerouting pins with hdajackretask does not help. Comparing Linux kernel logs (dmesg) does not yield any difference between working and non-working boots in the output of the relevant audio drivers.
4.) My 1600Mhz DDR3 RAM supposedly runs at 666Mhz (dmidecode --type 17). I think it's running at 1330 MHz, though. I somewhere read that 1600 Mhz CL11 is equivalent to 1300 Mhz CL9, which could explain this. So I guess, I simply bought crappy RAM.
5.) The Fn-keys work after the corresponding patch. But is it possible to use the Fn-key like any other (modifier) key? I do not get separate key-down/release events and events for any other key-presses (except for a few that have assigned Fn-functions). That's a bit of a waste. I guess, this is an EC "feature"...
6.) I have a WWAN mPCI card (Sierra 7710). It used to be reported as always-hard-blocked (rfkill list). WWAN was enabled in NVRAM. All of these (WIFI, Bluethooth, WWAN) Enable-NVRAM-settings have no effect on the hard-block state of any of the corresponding devices, though. thinkpad_acpi reads these values from the EC via ACPI as far as I could follow the sources. So I conclude that this is probably a Coreboot-EC-communication problem!? h8_wwan_enable() probably has no effect on this board. The infamous trick of taping the miniPCI pin 20 did not help either in unblocking the card. Neither did disabling power-off mode per AT commands on the modem. Turned out however that the card wasn't really physically blocked, as scanning would still work via modem-manager-gui. thinkpad_acpi simply reported it as blocked, which is probably what rfkill reported as well. So I was able to work around this issue with the following module params (e.g. store as /etc/modprobe.d/thinkpad_acpi.conf): options thinkpad_acpi dbg_wwanemul=1 wwan_state=1 dbg_wlswemul=1 wlsw_state=1 (Interestingly `dbg_wwanemul` seems to have no effect.) The modem now appears to work.
7.) The internal PS2 keyboard does not work in some secondary payloads (eg. nvramcui). Only USB-keyboards do. That's a bit annoying in a notebook, especially since...
8.) nvramtool crashes. Is that known and fixed, or would you like a core dump? Needless to mention that I enabled CONFIG_USE_OPTION_TABLE and nvramcui also generally works.
9.) Waking up from sleep-mode does not work. I haven't investigated this thoroughly and I haven't tested hibernation. Quite possibly an OS issue.
10.) Maybe off-topic, but relevant for anybody trying to coreboot this board: flashrom had to be patched in order to work with the flash chip. Turns out the probing/identification command would not be answered correctly by the chip (found out after attaching a logic analyzer), even though I checked against the datasheet. Didn't dive into this question too deeply but simply worked around it by letting flashrom skip the probing. Flashing externally is quite unreliable, and needs to be repeated often until a complete image would be flashed. This could be because of long and crappy wires, though. Internal flashing does currently not work.
In a related matter: There is zero documentation on how to coreboot this board in the entire internet AFAIK. That's a bit sad, as it significantly decreases its possible audience and might also result in the port dying once the initial maintainer looses interest. Maybe including documentation should be made mandatory for every new port?
I can also confirm that the WWAN detection (I4cfefb06556c9d69bc8e4a4f9d112246885c253a) works for detecting a card's presence as well.
Any ideas, especially on how to proceed with 1.) and 2.)?
Best regards, Robin