Phase 3: Wi-Fi firmware, WCN7850 up (2026-11-03)

Attempt 2026-11-03-1. Image 550a4055eee29513: kernel, config and DTB unchanged from attempt 2026-11-02-6. The new /init and the Wi-Fi firmware went into the initramfs (commit 07c76e5). Source: the AP console log dumps/firstboot/2026-11-03-ap.log (gitignored); MACs are not printed.

Result

The Wi-Fi works: the ath12k probe completes. wlan0 stays down; nothing scans or transmits.

• Firmware boot: MHI powers the chip on and it reaches mission mode, then QMI reports chip_id 0x2 chip_family 0x4 board_id 0xff soc_id 0x40170200.
• Firmware version: fw_version 0x1103006c, build WLAN.HMT.1.1.c7-00108-QCAHMTSWPL_V1.0_V2.0_SILICONZ_UPSTREAM-3 (2026-03-06). That’s the linux-firmware amss.bin.
• Interfaces: GBOOK: wifi-phy=phy0, GBOOK: wifi-net=wlan0 operstate=down driver=ath12k_wifi7_pci wireless=yes, wifi-wait=0s.
• No errors: no failed to fetch board data and no regdb warning.
• PCI subsystem IDs, model-level and new in the pci= line:
  • WCN7850 0004:01:00.0: subsystem 105b:e0ee;
  • NVMe 0006:01:00.0: subsystem 1344:1100, still driver=none (# forbid-y: BLK_DEV_NVME).

Board data

WCN7850 matches board data by bus and board (ath12k/wifi7/pci.c:135,159 at a804c57). The name it builds is bus=pci,vendor=17cb,device=1107,subsystem-vendor=105b,subsystem-device=e0ee,qmi-chip-id=2,qmi-board-id=255 (core.c:232-247). board-2.bin in linux-firmware-atheros 20260916-1 has exactly that entry. It also has variant=DE01 and DE02 entries, but those are only picked through an SMBIOS/ACPI variant, which a DT boot doesn’t have (qmi.c:2973-2982). A board-data miss would have aborted the probe before wlan0 registered (core.c:520-580), so the mica module uses the generic Foxconn 105b:e0ee entry. The stock bdwlan.* files from modem_a are not needed.

Other captures (unchanged from attempt 6)

• ADSP running; CDSP offline.
• Type-C ports 0 and 1.
• Both PCIe links up: Gen4 x4 and Gen3 x2.
• Deferred: arm-scmi (mailbox 17430000) and 3da0000.iommu (waits for GPU clock controller 3d90000; also seen in the 2026-11-02 log).
• The 5 s settle in /init works: the GBOOK lines no longer interleave with probe messages.
• Ramoops readback: the newest dropbox SYSTEM_LAST_KMSG entry (12:53 PM) holds this boot and ends at [ 81.894902] reboot: Restarting system.
• The udev no-automount rule works: on 2026-11-03 the kernel stick plugged into the build host with nothing mounted.

Firmware in the initramfs (not in git, ADR 0005)

Decompressed from the build host’s linux-firmware-atheros 20260916-1 (/usr/lib/firmware) into ~/.cache/gbook/firmware:

Notice.txt (the licence) sits next to them. The firmware tree hash in manifest.txt is 8a75fc5ebfeea9766b1d59c6a718c42e080721f68ccb078df3edf0ce59f03075 (68 files, ADSP included).

Stock reference (read, not used)

• modem_a /image/kiwi/ (the cnss2 layout): amss.bin, amss20.bin, bdwlan.e01…e54, bdwlan01.*, bdwlan.elf, regdb.bin, phy_ucode*.elf.
• Stock Android drives the chip with the downstream cnss2/cnss_pci driver (/sys/module/cnss2), through the DT node qcom,cnss-kiwi@b0000000.
• Shell can’t read the PCI IDs or /sys/kernel/cnss/* there (Permission denied).

First try refused: “No valid image detected”

The first stick boot of this image failed with “No valid image detected” on screen. A re-insert gave the same error.

• What the firmware log showed: every rescan printed GptNextKernelEntry … s0 t0 p0, no more kernels and vb2api_load_kernel() = 0x100b2000.
• What was on the stick: read back on the build host, KERN-A had priority 0, tries 0. The image had written 15/3.
• Why a re-insert can’t help: vboot marks a partition it rejects as bad (GPT_UPDATE_ENTRY_BAD, 2load_kernel.c:743 at firmware-bluey-16702.B 34fbbe6).
• Why the reason is lost: the log is a 128 KiB ring (Read cbmem console: size=131064). It was full of rescans and menu lines, and the first attempt’s error line was gone.
• Outcome: the stick was rewritten with the same image (read-back identical), and the next boot worked.
• Cause: unknown. Inference: a transient USB read on the first try, since the bytes and the size (the FIT is 58.9 MiB, against the 256 MiB KERNEL_SIZE) were identical both times. The runbook’s failure playbook now says to read the log right after the first refusal and to rewrite the stick before retrying.

Attempt 2026-11-03-2: join, DHCP, ping

Image ec9f9f4b96ad4f86 (commit 4428f27). The kernel, DTB and firmware are as in attempt 1. The initramfs adds:

• iw:arm64 6.17-1+b1 and wpasupplicant:arm64 2:2.11-7 from sid, with their 13 shared libraries in /lib;
• the owner’s network block, from ~/.local/state/gbook/wifi.conf (mode 600, never printed or hashed).

AP console, MACs and the SSID redacted:

The panel goes dark at about 33 s: VREG_EDP_3P3: disabling. The kernel switches off unclaimed regulators, and no display driver holds the panel supply yet. That’s expected while only simpledrm drives the screen.

The wpa_supplicant log printed the own SSID once; /init now redacts SSID='…' too.

Update 2026-11-03: the cause of the “No valid image” refusals

The inference above (“a transient USB read”) was wrong. Attempt 2 was refused the same way on its first two power-ons. The EC console logged boot_keys: recovery (boot_keys_value=0x00000009) before both refused boots in dumps/firstboot/2026-11-03-ec.log, and not before either boot that worked.

The owner had powered on with the recovery keys, because the agent’s instructions said so; runbook section 6 says plain power-on. In recovery mode vboot scans the stick for a recovery kernel. The dev-signed kernel fails that check, and the partition is marked bad (GPT_UPDATE_ENTRY_BAD, cgptlib.c:155 at 34fbbe6). On that power-on, the first USB scan already showed s0 t0 p0 (owner photo of the firmware log).

After a rewrite and a power-on with no keys held, the stick booted. Runbook section 6 step 3 now forbids the recovery keys with the image stick in.

Attempt 2026-11-03-3: netlog over Wi-Fi

Image 6582ef037a626828, commit d3b37f8. After GBOOK: end, /init sends /tmp/gbook.log (every GBOOK: line) and the whole dmesg with busybox nc to <the build host's LAN address>:5140. That target is in /etc/gbook-netlog, written by package-image.sh. On the build host, scripts/attempt.sh netlog start runs socat bound to the LAN address. It accepts only <the device's lease> (range=), and the owner-approved ufw rule allows only that peer.

• Sent: GBOOK: netlog=sent 1176 lines to <the build host's LAN address>:5140 exit=0.
• Received: dumps/firstboot/2026-11-03-netlog.txt (mode 600), 1176 lines: 361 GBOOK: lines and 813 kernel lines.
• The netlog covers the whole boot: it starts at [ 0.000000] Booting Linux on physical CPU 0x0000000000 and includes the Linux version banner. The AP console starts at about 0.6 s; ramoops starts mid-boot and has no banner.
• Redaction: no MAC-like strings and no SSIDs; 12 <mac> substitutions.
• One fix: the serial pattern also caught Serial: AMBA PL011 and Serial: 8250/16550. It now matches only SerialNumber: and serial number:.
• The rest matched attempt 2: join after 15 s, DHCP <the device's lease>/24, gateway ping 3/3 (11.1 ms average), reboot at 117.6 s, stock Android back.

The Googlebook now has three independent log channels: the SuzyQ AP console, ramoops through dropbox, and netlog.