[W4HO-ham]

Stacked on #235 (0.2.3), #234 (0.2.2) and #230 (0.2.1); the fourth commit is this one.

With linux-omarchy-mobile#168 the 9a's device tree has the zumapro PCIe channel-1 host and the Wi-Fi node. The graphics start gains a last hang-safe step for it:

1. modprobe pcie_zumapro. Its probe brings the link up.
2. Wait for 0000:01:00.0.
3. modprobe brcmfmac, and wait for a wl* interface.

The step only runs when the host's node (13120000.pcie), the wifi-dma-pool reserved memory and the owner's brcmfmac4383-pcie.bin are all there. Otherwise it logs a skip, so the palmtop's daily integration boot (no pcie_zumapro in that tree) is unaffected. Each failure is logged and skipped, and the marker is cleared, as for the other steps. Both modules were already blacklisted in omamobile-tegu-guards.conf, whose comment now says the graphics start loads them. The test covers the order, the summary, and a failed host load that must not load brcmfmac.

Tested on the palmtop today with #168's kernel (and brcmfmac as at linux-omarchy-mobile#56) and this package. At boot, with nothing by hand:

• "omamobile-tegu-graphics: up: GPU, display, haptics, torch, gauge 89 %, Wi-Fi (wlan0)".
• wlan0 up and connected through NetworkManager, with 8 networks in the scan.
• A ping over wlan0 at 18 ms.

test/all and tools/pr-check pass.

[derekross]

Wi-Fi at boot on the 9a, nice work, and thank you for the ping and scan numbers. I merged 0.2.1 to 0.2.3 through #235, so this needs a rebase onto main (0.2.4 on top of 0.2.3). Before I merge it, could you post a tools/phone-smoke report from a boot of this head, with uname -r? That's what lands.

Two small things, neither blocking: the graphics unit runs before the display manager and Wi-Fi is its last step, so a failing Wi-Fi bring-up can hold the login screen back by up to about 35 s; a separate unit after the display manager would avoid that someday. And one README line saying that a hang in the Wi-Fi step also keeps the GPU and display off on the next boot (the single marker) would help someone reading a bad boot.

[W4HO-ham]

Rebased onto main (0.2.4 on top of your 0.2.3), and the README now says that a hang in the Wi-Fi step leaves the one marker, so the GPU and the display stay off on the next boot too. It also names the Wi-Fi step in the table. After the rebase, the only package change from what's installed on the palmtop is that README text; the scripts are byte-identical.

The boot: 7.3.0-rc6-omamobile-push1-g07bdf006cdc2 (kernel #168's head on #161, brcmfmac as in kernel #56), with omamobile-device-tegu 0.2.4 and nothing started by hand. The graphics start brought Wi-Fi up on its own:

omamobile-tegu-graphics: up: GPU, display, haptics, torch, gauge 90 %, Wi-Fi (wlan0)

wlan0 connected through NetworkManager, 12 networks in a scan, a ping through wlan0 at 22-31 ms. Then six rescans, 12 s apart: 13 networks, and no oops.

One correction to the evidence: the 10-31 boot of this same kernel had two oopses in brcmfmac's scan handler, and its smoke report (on #168) said "4 oops/BUG". brcmf_inform_single_bss() passed cfg80211 a NULL channel for a BSS on a channel the wiphy doesn't list. I've pushed the fix to kernel #56 as its own commit, and this boot ran that brcmfmac.ko, rebuilt for the same release. A clean run doesn't prove the guard fired, since the offending BSS may simply not have been heard this time, but there was no oops in six rescans.

The smoke report from this boot:

phone-smoke: tegu

Kernel 7.3.0-rc6-omamobile-push1-g07bdf006cdc2, tools at e567062, 2026-11-01T14:27Z.

Check	Result	Detail
boot (required)	ok	kernel 7.3.0-rc6-omamobile-push1-g07bdf006cdc2, slot b, up 251s
storage guard (required)	ok	62 partitions; only userdata and slot B's boot images writable
root (required)	ok	ext4 on userdata, 18G free
kernel health (required)	ok	no oops or BUG; 0 WARN, 45 error lines in dmesg
systemd units	not ok	failed: systemd-backlight@backlight:19440000.dsi.0.service tegu-gpu-dvfs.service tegu-nfc-clkpad.service
USB gadget (required)	ok	bound to 11210000.usb
display	ok	card1-DSI-1 connected, 1080x2424
GPU	ok	render node on panthor
session (required)	ok	Hyprland and the Omarchy shell running
lock	ok	PAM file present, the shell can lock (passwordPam true, locked true)
touch	ok	Synaptics TouchComm Touchscreen
buttons	ok	gpio-keys
Wi-Fi	ok	wlan0 on brcmfmac, link up
Bluetooth	skip	no controller
battery	ok	90% Full, 29 °C
sound cards	skip	none
sensors	skip	no sensor proxy
cameras	not ok	libcamera lists none (or a camera app holds them)
thermal	ok	hottest zone 41 °C

Packages: hyprland 0.56.2-5.1, libcamera 0.7.2-4.22, mesa 1:26.2.4-1.4, omacam 0.3.3-1, omamobile-apps 0.2.0-1, omamobile-audio 0.5.6-1, omamobile-device-tegu 0.2.4-1, omamobile-fingerprint 0.1.8-1, omamobile-firstboot 0.1.0-1, omamobile-gnss 0.2.5-1, omamobile-keyring 20261013-1, omamobile-mirror 0.1.1-1, omamobile-modem 0.1.4-1, omamobile-modem-sit 0.3.3-1, omamobile-omarchy 0.1.23-1, omamobile-owl-widgets 0.1.1-1, omamobile-sensors 0.2.1-1, omamobile-shell 0.2.62-1, omarchy 4.0.6-1

Bluetooth, sound, sensors and cameras are skipped or failing because this DTB is the stack only up to the charger plus Wi-Fi. The three failed units aren't from the package: two are bring-up units on the palmtop looking for nodes later PRs add, and systemd-backlight fails the same way on every test boot of this stack. The palmtop is back on the daily kernel.

[derekross]

Thanks for the rebase, the README line about the single marker, and the smoke report from this head. It's also good that you caught the scan-handler oops from the 10-31 boot and fixed it in brcmfmac as its own commit.

I found one thing that would keep Wi-Fi off on every 9a but yours. The step only runs when this file exists:

wifi_fw=$root/usr/lib/firmware/brcm/brcmfmac4383-pcie.bin

But tools/extract-vendor-firmware -d tegu never installs that name. It writes the board-suffixed files under updates/, and tools/phone-provision pushes them to /usr/lib/firmware/updates. That's brcm/brcmfmac4383-pcie.google,zumapro-tegu.bin (and .txt, .clm_blob, .txcap_blob), matching brcm,board-type = "google,zumapro-tegu" in kernel #168's Wi-Fi node. The extractor's header even says a generic file must not shadow the owner's, and this package's own README lists the board-suffixed name under "Firmware the phone needs". So on a phone set up by our tools, the gate never passes and the log says "no Wi-Fi host, DMA pool or BCM4383 firmware in this boot; skipped". On your palmtop it passes, I think because of a generic copy left from bring-up (ls -l /usr/lib/firmware/brcm/brcmfmac4383-pcie.bin would show it).

Could you point the check at the file the extractor installs?

wifi_fw=$root/usr/lib/firmware/updates/brcm/brcmfmac4383-pcie.google,zumapro-tegu.bin

Or accept that path or the same name without updates/. Please make the test create that path rather than the generic one, so it follows the provisioning tools. Once your palmtop has only the extractor's files (move the generic copy aside), one boot showing "Wi-Fi (wlan0)" in the summary would confirm it.

The rest reads well:

• The step is gated on the host's node, the restricted DMA pool and the firmware, and each failure is logged and skipped.
• The endpoint wait is bounded and the interface wait is bounded too.
• The test covers the order and a failed host load.

One note for the merge order: this needs kernel #168 for the host's node and #227 for CONFIG_PCIE_ZUMAPRO, and until they land the step simply logs a skip, which is fine.

[derekross]

Thanks for moving this to the shared zuma-family host so quickly. Choosing the host from the node's compatible and keeping the old module as the fallback is a clean way to cover both kernels, and the test covers both, including a failed PHY load.

The point from my last comment still stands, though. Line 49 still gates Wi-Fi on the generic name:

wifi_fw=$root/usr/lib/firmware/brcm/brcmfmac4383-pcie.bin

tools/extract-vendor-firmware and tools/phone-provision install only updates/brcm/brcmfmac4383-pcie.google,zumapro-tegu.bin, so on a phone set up by our tools the step logs a skip and Wi-Fi stays off. Could you point the check at that path, have the test create it instead of the generic one, and post one boot with only the extractor's files that shows "Wi-Fi (wlan0)"?

Two notes on the new commit, neither blocking:

• The shared-host branch hasn't run yet, since kernel device/tegu USB-HOST-PLAN: H2b, H4 and H5 ran on 2026-10-30 #178 hasn't booted. That's fine: if it fails, the step logs a skip.
• Our kernel config fragment has CONFIG_PCIE_GS201 but not CONFIG_PHY_ZUMA_PCIE. With device/tegu USB-HOST-PLAN: H2b, H4 and H5 ran on 2026-10-30 #178 and today's fragment, the step would log "phy_zuma_pcie failed". That config line belongs with device/tegu USB-HOST-PLAN: H2b, H4 and H5 ran on 2026-10-30 #178 (or omamobile-modem-sit 0.3.4: read the CP state on one open file #156), in a kernel-config PR, not here.

When this merges, I'll also update the title, since the host is no longer only the zumapro one.

[W4HO-ham]

Fixed in 84b1e34: the check now looks for updates/brcm/brcmfmac4383-pcie.google,zumapro-tegu.bin, the test creates that file instead of the generic one, and the README says which file it is.

The boot you asked for, today on the palmtop with kernel #178 (7.3.0-rc6-omamobile-push1-g87476c05a600): I ran tools/extract-vendor-firmware -d tegu on the factory image (cp3a.261005.005) and installed its four brcmfmac4383-pcie.google,zumapro-tegu.* files, then moved the hand-copied generic brcmfmac4383-pcie.* files out of /usr/lib/firmware/brcm before the boot. The unit's journal:

omamobile-tegu-graphics: up: GPU, display, haptics, torch, gauge 89 %, Wi-Fi (wlan0)

phy_zuma_pcie and pcie_gs201 loaded (the shared-host branch, from the node's compatible), Gen2 x1 on try 1, brcmfmac loaded firmware 20.25.929.104.8, and wlan0 associated and passed traffic. So the shared-host branch has run now too. The boot before it, with only the generic files, logged the skip ("no Wi-Fi host, DMA pool or BCM4383 firmware"), which is what a phone set up by hand gets now. The CONFIG_PHY_ZUMA_PCIE line goes in a separate kernel-config PR, as you said.

[derekross]

Landed on main as c5795a8 (squashed, authored by you). My review notes from before the merge, for the record:

Thank you for the fix and for the boot. Keying on updates/brcm/brcmfmac4383-pcie.google,zumapro-tegu.bin, which is where tools/extract-vendor-firmware and tools/phone-provision put it, and then booting with only the extractor's files and the generic ones moved away, is exactly the check I hoped for. It's also good to see the shared-host branch run on #178 end to end, with Wi-Fi associated and passing traffic.

I'll merge this first and #275 right after it, so this one keeps 0.2.4 and #275 lands as 0.2.5. Since the host is no longer only the zumapro one, I'll use "omamobile-device-tegu 0.2.4: Wi-Fi at boot through the zuma-family PCIe host" as the subject and write the merged message from the current code, because the description still describes #168's pcie_zumapro path.

One note for later, not for this PR: #168's driver has been superseded by #178, and our kernel config dropped CONFIG_PCIE_ZUMAPRO today, so the pcie_zumapro fallback only helps a kernel built from #168. You can drop it whenever it suits you. The CONFIG_PHY_ZUMA_PCIE line in a kernel-config PR is still what a published kernel needs for this step.