From d7cb506c4677cc5ee9977de0891e6de0b3399d06 Mon Sep 17 00:00:00 2001 From: ScottW514 Date: Sat, 15 Aug 2026 13:36:51 -0400 Subject: [PATCH] BRINGUP: hv_enable readback bench-validated on image 20260815162923 --- docs/BRINGUP.md | 52 ++++++++++++++++++++++++++++++++++++++++++++++--- 1 file changed, 49 insertions(+), 3 deletions(-) diff --git a/docs/BRINGUP.md b/docs/BRINGUP.md index 7f6afff..63f50ec 100644 --- a/docs/BRINGUP.md +++ b/docs/BRINGUP.md @@ -1394,6 +1394,13 @@ accordingly ("Automatic — AP country, else World"). devices in this kernel). - **Any probe/liveness move goes RIGHT (+X) first, then back**: a cable lives at the end of LEFT travel and must never be crushed. +- **WL1805 Wi-Fi rides uSDHC1** (mmc0, 4-bit, SD-high-speed at 49.5 MHz, + `no-1-8-v`; IRQ GPIO6_04, WLAN_EN GPIO5_26). Factory pad control, now + ours too: CMD/DATA `0x17069`, CLK `0x10069` (SPEED_MED, DSE 48 Ω, fast + slew, HYS; 47 kΩ pull-up on CMD/DATA only). eMMC (uSDHC3) and the SD + slot (uSDHC2) use `0x17059`/`0x10059` (80 Ω), SD2_DAT3 `0x13059`. An + SDIO CRC error surfaces as `sdio write failed (-84)` and costs ~1 s of + Wi-Fi (wlcore firmware recovery) — see Next work item 13. - SDMA pulse engine: ring size = the `ring_mb` module parameter (default 16 MiB; power of two, must fit the 16 MiB `cnc-pulsebuf` DT @@ -2346,9 +2353,16 @@ accordingly ("Automatic — AP country, else World"). `SW_HV_ENABLE`, and the standard built-image checks pass (root locked, no watchdog daemon, K80/K90 order, `glowforge.ko` in `extras/`); the only build warning is the usual forced-`do_compile` taint note. - **Flash pending (operator).** **Bench, after the flash:** `/status` - shows `hv_enable:false` at idle, `true` during a jog, back to `false` - ≈0.45 s after the run ends, in lockstep with `charge_pump_alive`. + **Flashed and BENCH-VALIDATED 2026-08-15 (operator flashed; image + reports `20260815162923 (dev)`, `/proc/device-tree/switches/hv_enable` + present):** with `/status` and `cnc/charge_pump_alive` sampled together + at ~10 Hz on the board through a 5 mm X jog (`$J=G91 X-5 F300`, no + Grbl client attached, laser locked): `hv_enable:false` / pump 0 at + idle; `true` / 1 in the same sample the state went `running`; still + `true` / 1 in the first `idle` sample after the run; pump 0 ≈0.4 s + after that idle sample with `hv_enable` false in the next sample + (89 ms later); the head returned to `MPos 0.000`. The switch reads as + HV_ENABLE itself, in lockstep with the watchdog readback. - **GATE A kernel fixes added to the same flash (2026-08-14):** the controlled-deceleration ramp now floors at the minimum step frequency with a saturating decrement, and `epit_hz_to_divisor()` @@ -2495,3 +2509,35 @@ accordingly ("Automatic — AP country, else World"). Resume path, Start-with-lid-open, or the sender's own handling of the `Door` state, and what the controller reports at each step. Until then the door change stands as partially validated (item 4). +13. **uSDHC pad strength brought to the factory values (DTS change + 2026-08-15, bench validation pending — ships with the next full image + flash, per the batched kernel/BSP rule).** Trigger: one + `wl1271_sdio mmc0:0001:2: sdio write failed (-84)` (`-EILSEQ` = SDIO + bus CRC error) on the WL1805 Wi-Fi bus at 49.5 MHz SD-high-speed, + followed by wlcore's designed hardware recovery (firmware reboot + + reassociation, ~1.0 s of Wi-Fi outage) and one `ipu1_csi0: NFB4EOF` + 160 ms later (a consequence of the recovery/WARN console burst, not a + co-cause). It happened at idle, 1.7 s after a kernel run ended and + ~2 s after a button press — no motion, no fire, HV_ENABLE already + down — so nothing points at laser or stepper EMI. Rate observed: + 1 event in 49 min of uptime. Effect if it lands mid-job: a 1–2 s + sender stall (planner drains, head pauses; laser off in M4 mode) — + a cut-quality nuisance, never a safety matter (nothing safety-relevant + crosses Wi-Fi). Finding: `glowforge.dts` drove all three uSDHC + controllers with `0x17019` (SPEED_LOW, DSE 80 Ω, 47 kΩ pull-up on + CLK too), while the factory DTB uses `0x17069`/`0x10069` (SPEED_MED, + DSE 48 Ω; no pull on CLK) for the Wi-Fi bus and `0x17059`/`0x10059` + (80 Ω) for eMMC and SD (SD2_DAT3 `0x13059`) — softer edges than the + factory at the same 50 MHz clock. `openglow_common.dtsi` now carries + the four factory-exact values (`USDHC_PAD_CTRL`, `USDHC_CLK_PAD_CTRL`, + `USDHC_SDIO_PAD_CTRL`, `USDHC_SDIO_CLK_PAD_CTRL`) and the compiled + `fsl,pins` tuples were checked byte-identical to the factory DTB's + `glowforge_usdhc1/2` and `usdhc3grp`. **Bench:** on the next image + confirm `pinconf-pins` reads `0x17069`/`0x10069` on SD1, eMMC and + Wi-Fi come up, then watch `dmesg | grep -c "sdio .* failed"` across + sessions (baseline: 1 per ~49 min). Only if it still recurs, cap + the bus with `max-frequency = <25000000>` on `&usdhc1` (halves Wi-Fi + throughput — last resort; the factory ran 50 MHz on these pads). The + `WARNING … wlcore/main.c:874 wl12xx_queue_recovery_work` block that + accompanies the event is upstream noise (an "unintended recovery" + `WARN_ON`), not a crash — the `-84` line is the signal to watch.