Phase 3: the ChromeOS EC, built-in keyboard, keyboard backlight and fans (2026-11-03)

Attempts 2026-11-03-13 (image 17bf703d696856ed, kernel #11, commit f1d817e), a repeat boot of the same image, and 2026-11-03-14 (image e2f2bee81254d578, kernel #12, commit 702de45). Owner round 2026-11-03: target the EC (1a), with its children and captures in one boot (2a), kernel patches back on (3a), other unbound nodes as leads only (4a). Sources: the netlog dumps/firstboot/2026-11-03-netlog.txt, the AP and EC console logs dumps/firstboot/2026-11-03-{ap,ec}.log (all gitignored), and the pinned tree a804c57.

Why

All 10 boots on 2026-11-03 up to attempt -12 logged sync_state() pending due to a94000.spi (77 lines in the netlog) and not one cros_ec line. a94000 is spi13 (hamoa.dtsi:1905), the bus of cros_ec: ec@0 in dts/x1e80100-google-mica.dts. Its driver (qcom,spi-geni, drivers/spi/Kconfig:1013, SPI_QCOM_GENI) is =m in arm64 defconfig, and the initramfs loads no modules. So the EC, the built-in keyboard (cros-ec-keyb) and everything the EC adds had never probed. The keyboards in earlier AP logs were USB ones.

Attempt -13: the SPI bus binds, the EC answers garbage

• Change: kernel/mica-ec.config builds in SPI_QCOM_GENI, CROS_KBD_LED_BACKLIGHT, PWM_CROS_EC, LEDS_CROS_EC and CROS_EC_CHARDEV, requires the already built-in EC core, and forbids CROS_EC_TYPEC and CROS_EC_UCSI at =y (pmic_glink owns the Type-C ports). /init gained the ec-* captures, a 20 s key-press window and one keyboard-backlight write (max for 5 s, then 0).
• Result: ec-spi=a94000.spi driver=geni_spi, then cros-ec-spi spi0.0: packet too long (252 bytes, expected 4) and Cannot identify the EC: error -28.
  • -28 (-ENOSPC) comes from the v2 command path (cros_ec_spi.c:611): the v2 hello reply’s length byte read 252 (0xfc). The v3 protocol query before it had failed too, logged only at dev_dbg level (cros_ec_proto.c:389, fallback at :492). Both failing points at the transfer, not the EC (inference).
  • The repeat boot of the same image (the stick reached the Googlebook before the -14 write) failed the same way at 3.94 s.
• The stock node matches ours (overlay entry01 fragment 48: 3 MHz, interrupt TLMM 66 level-low, no google,cros-ec-spi-pre-delay or -msg-delay). Stock drives CS on gpio55 with function qup1_se5, drive 6, bias-disable (entry00-base.dts:3017-3028), but through Qualcomm’s vendor GENI driver.
• Mainline precedent: both mainline Qualcomm Chromebooks with the EC on GENI SPI drive CS as a GPIO: trogdor (sc7180-trogdor.dtsi:910-911, cs-gpios = <&tlmm 62 GPIO_ACTIVE_LOW>) and herobrine (sc7280-herobrine.dtsi:542-544, with an output-high init state at :895-899).

Attempt -14: GPIO chip-select, pass

• Change (commit 702de45): &spi13 takes pinctrl-0 = <&qup_spi13_data_clk>, <&qup_spi13_cs_gpio> and cs-gpios = <&tlmm 55 GPIO_ACTIVE_LOW>; the new qup_spi13_cs_gpio state is gpio55, function gpio, the stock drive 6 and bias-disable, output-high. CONFIG_DYNAMIC_DEBUG=y and an /init re-probe with the cros_ec debug lines on, for a failed EC (not needed: the EC registered at boot). dt-validate output unchanged (322 lines, all the known root compatible warning).
• EC: cros-ec-spi spi0.0: Chrome EC device registered at 0.747 s; cros-ec-rtc registered as rtc0 at 0.677 s. a94000.spi is gone from the sync_state() pending lines.
• Built-in keyboard: input: cros_ec (input0, event0) and cros_ec_buttons (input1) at 0.93 s. In the 20 s window the owner typed on it: ec-keys=bytes=9336 events=389 (24-byte input_events).
• Keyboard backlight: chromeos::kbd_backlight (the cros-keyboard-leds cell, so the EC reports EC_FEATURE_PWM_KEYB; drivers/mfd/cros_ec_dev.c:145-147), max=100. Set to 100, read back 100; set to 0, read back 0. The owner saw the keyboard light up for the 5 s (reported 2026-11-03, about 6:05 PM ET).
• Fans: hwmon54 name=cros_ec fan1_input=0 fan2_input=0: two fans through the EC, both stopped (cool, idle). The EC runs them on its own; nothing on the AP side drives them.
• Everything else unchanged; errors=1 (from 17 on the repeat -13 boot).

SCMI on these cold starts (aside)

The EC logged G3->S5 before each of the three boots (EC uptime 15984, 17025 and 17236 s), so all three were cold starts. SCMI still failed on two of them: -13 (-110, no firmware version) and the repeat (timed out in resp, firmware version 0x0, cpufreq=none). It worked on -14 (0x20000, all three policies, one timed out in resp line at 0.418 s). So a cold start does not always bring SCMI up; “cold boot only” in scmi-2026-11-03.md needs a dated update. compare printed start: unknown for these boots (the EC reset spacing did not match boot_start.py’s expectation), although the EC log shows G3->S5.

Open

• Keyboard layout, Fn keys and the top-row keymap: only key events were counted, not which keys.
• Fan behaviour under load and fan control from the AP (cros_ec hwmon PWM, if the EC offers it).
• The EC’s Type-C and UCSI cells stay modules; pmic_glink keeps the ports.
• Other nodes that never bind (owner round 4a, leads only): crypto@1dfa000, videocc@aaf0000, camcc@ade0000, the CPU PMUs (24091000, 240b3400, 240b5400, 240b6400) and 3d6a000.gmu.
• SCMI on cold starts: intermittent (above).