GXFP51A0 SPI (MateBook 13 2021): driver_51x0_spi reads 0xFF — reset GPIO + wake missing

[GodsQuantum]

Testing driver_51x0_spi (run_5120_spi) over /dev/spidev0.0 on a MateBook 13 2021 (GXFP51A0): MISO is constant 0xFF, even during the write half of a full-duplex xfer, at 1 and 10 MHz.

Two gaps found:

1. The sensor's ACPI GpioIo reset (gpiochip0 line 264 here) must be asserted before SPI — nothing in the flow drives it.
2. SPIProtocol.read() polls blind: the data-ready interrupt.poll() is commented out and hard-codes gpiochip0 line 279 (the author's line), not this machine's GpioInt.

Even with reset asserted, MISO stays silent — likely a proprietary wake/bootloader step. Full ACPI + test details: https://github.com/GodsQuantum/huawei-matebook-fingerprint-linux . Anyone with a working GXFP51A0 capture?

[GodsQuantum]

Update from the GXFP51A0 / Huawei MateBook 13 investigation (2026-09-02):

The earlier MISO=0xFF / missing reset+wake interpretation is obsolete after
reverse-engineering the exact Goodix FP 1.1.141.36 driver and tracing the
Linux controller.

Confirmed:

• ACPI\GXFP51A0 selects Goodix transport mode 5.
• Windows mode 5 sends each Milan packet using two distinct synchronous SPB
  writes: outer 4 bytes -> 2 ms -> inner bytes.
• Linux now matches this exact transaction boundary.
• Native ACPI IRQ mapping has been validated.
• A fresh-boot Linux trace shows:
  spi_set_cs -> pxa2xx_spi_set_cs -> lpss_ssp_cs_control
  around the tested transfers, with clean controller completion but no sensor
  IRQ.

Important startup correction:

send_driver_install_to_MCU() does not propagate the SetDriverState()
result as the _DeviceInit gate. Windows continues into init_MCU().

The real common-init response gate is GetEvkVersionWithRetry:

• compiled retry_count_for_common_init default = 3;
• three initial GetEvkVersion calls;
• HardResetMcu after all three fail when D0Exit has not started;
• reset BOOL ignored by this wrapper;
• one final GetEvkVersion.

The Linux research harness now reproduces this flow and passes its complete
test/safety suite.

Current technical boundary:
https://github.com/GodsQuantum/huawei-matebook-fingerprint-linux/blob/main/docs/software-boundary-2026-09-02.md

Windows WDF/IFR/WPP/ETW traces from a working GXFP51A0 would be especially
useful.

[szlukabence]

The GXFP51A0 replies on Linux. After months of 0xff on four machines, mine
answered today. Two conditions are needed together — either alone gives
silence, which is why this hid for so long:

1. The "enable" GPIO is an active-HIGH RESET

Holding it HIGH holds the sensor's MCU in reset. It must be LOW to run.

Most of us drove it HIGH and treated that as "powered on" — I certainly did, in
~300 attempts. Worse, the interrupt line reads HIGH in that state, which looks
like a healthy powered part and is actually the MCU's undriven pin.

How I found it: booting Windows, unlocking with the fingerprint, then reading the
pad registers with RWEverything while the sensor was working:

pin 189 (reset)      Windows 0x44000200 (driven LOW)   Linux was 0x44000201 (HIGH)
pin 41  (interrupt)  Windows 0x40100100 (reads LOW)    Linux was 0x40100102 (HIGH)

The four SPI pads were identical on both systems, every bit.

2. spidev SPI_CS_HIGH — chip select inverted

Mode 0 | SPI_CS_HIGH (0x04). This is despite ACPI _CRS declaring
PolarityLow and Intel's Windows controller driver logging CsPolarity:Low.
I have not yet explained that contradiction; the wire is the wire.

Measured from a kernel module sampling LPSS CS_CONTROL during live traffic:

mode 0           idle bit1=1 (0xe003)   during transfer bit1=0 (0xe001)
mode 0|CS_HIGH   idle bit1=0 (0xe001)   during transfer bit1=1 (0xe003)

(I had previously published that SPI_CS_HIGH "never reached the hardware". That
was wrong and is retracted — I had compared only which values appeared, not which
one is held during a transfer.)

Try it — it's a 2-minute test

sudo modprobe spidev
echo spidev | sudo tee /sys/bus/spi/devices/spi-GXFP51A0:00/driver_override
echo spi-GXFP51A0:00 | sudo tee /sys/bus/spi/drivers/spidev/bind
git clone https://github.com/szlukabence/goodix-fingerprint-spi-linux
sudo python3 goodix-fingerprint-spi-linux/tools/cshigh_repro.py

That script runs the working case plus three controls (CS normal; reset held HIGH;
no command sent), so a negative result is informative too. Your reset line number
may differ from gpiochip0 line 264 — check your _CRS.

Expected on success:

a0 1a 00 ba  a8 17 00  "GF_ST411SEC_APP_14115"  00 4c

What already works past first contact

0xa2 reset      -> 01 00 08 (2048), identical to Windows
0x82 chip id    -> 0x2504   (reads 00s until the 0xa2 reset has run)
0xa6 OTP        -> 64 bytes, byte-identical to the Windows driver log
0x70 + 0x80 x4  -> DAC writes from OTP accepted
0x90 config     -> 256-byte block accepted; ACK status flips 0x03 -> 0x01
0xF2            -> arbitrary memory read works (read 128 KB of RAM in ~5 s)

Remaining: locating the TLS PSK on this firmware build (GF_ST411SEC_APP_14115),
then handshake and image capture — all of which exist in working code for sibling
parts (@Sigfrodr's GXFP5187 driver, @berkekbgz's GDIX51C0 libfprint driver).

Full write-up with every control and the corrections to my own earlier claims:
https://github.com/szlukabence/goodix-fingerprint-spi-linux/blob/main/docs/FIRST-CONTACT.md

Please report either way — a "still silent on my machine" is as useful as a
success, because it tells us whether the two conditions generalise across boards.

[GodsQuantum]

Huge thanks @szlukabence — your Windows logging work and especially the active-HIGH reset + SPI_CS_HIGH finding directly unblocked this project.

Confirmed on my MateBook 13 / GXFP51A0: GF_ST411SEC_APP_14115 replies under Linux, chip 0x2504 / ChicagoHS 80x64 / 64-byte OTP are confirmed, the target config is accepted, and the TLS profile is now pinned to TLS 1.2 / PSK-AES128-GCM-SHA256.

One correction from later exact-target firmware analysis: I no longer consider F2 a viable PMK/RAM-read path on this 14115 build; its validated readable window is application flash, not the runtime PMK location.

The remaining blocker is host-key recovery. The Windows transcript shows Goodix_Cache.bin being SGX-unsealed twice before yielding a type-13 / 48-byte PMK. I have also validated legacy /dev/isgx and production Launch Enclave EINIT on the actual hardware, so SGX itself is not a dead end.

I’m now checking faster routes before doing more custom PE-loader work, especially whether the same-die GDIX51C0 PSK provisioning mechanism is safely applicable to 14115. Your contribution saved a huge amount of duplicated work — thank you.

[GodsQuantum]

Confirmed on a second MateBook 13 2021 / GXFP51A0: the active-high reset + SPI_CS_HIGH combination generalizes. It produced the first A8/EVK reply (GF_ST411SEC_APP_14115), followed by successful A2 reset, chip ID 0x2504, 64-byte OTP and target-config upload.

Many thanks to @szlukabence — this was the finding that finally broke the months-long 0xff wall. We are now testing whether the same-die GDIX51C0 APP-mode PSK provisioning path can remove the remaining SGX dependency.