docs: the kernel built for one board (BRINGUP item 21, CAMPAIGN-LOG)

BRINGUP gains Next-work item 21, the kernel trim and what it still owes
(a GRBL job and the acceptance campaign); CAMPAIGN-LOG records the
2026-08-24 review, the trim, and the bench drill on dev 20260824164619
through the forced-panic read-back from pstore.

Docs only; no catalog consequence.

docs/BRINGUP.md

@@ -1496,6 +1496,33 @@ Open items only. Anything closed is in `CAMPAIGN-LOG.md`.
     compare) plus `FORGECTRL_GPU_PASSES` (limit the draws) and the
     frame-wait column in the stream stats.
 
+21. **Kernel trim: bench validation.** The kernel is built for this board
+    alone: `glowforge.cfg` names the driver set and turns off what the
+    multi-board defconfig adds, and `glowforge.conf` names the modules and
+    firmware the rootfs carries. Built into image 20260824164619, not yet
+    flashed: zImage 4.8 MB (was 9.1 MB), 31 kernel-module packages (was 254),
+    no SDMA, EPDC or Quad-VPU firmware, ARMv7-only code, no virtual console
+    (`USE_VT = "0"`), and no `dmas` on ecspi2, so the pulse ring is the SDMA's
+    only client. New on the same image: pstore/ramoops in the 1 MiB the
+    bootloader holds back at the top of DRAM (`/sys/fs/pstore` mounts from
+    fstab), the hung-task and soft-lockup detectors behind the panic
+    notifier, `PANIC_TIMEOUT=10` in Kconfig, and `evbug` gone from the kernel
+    log. Bench-validated on that image (CAMPAIGN-LOG 2026-08-24): every node
+    binds and nothing defers, the panic sysctls read as configured,
+    `/sys/fs/pstore` mounts with ramoops registered, `/dev/dri/renderD128`
+    is present and both cameras stream through the GPU demosaic, Wi-Fi
+    associates with `regulatory.db` loaded, the switches sit on `event0`,
+    31 modules load and no DMA channel is held by anyone. Two cosmetic dmesg
+    lines came with it: spi-imx reports the absent DMA channel at ERR level
+    and runs PIO, and `consoleblank=0` (uEnv) is an unknown parameter without
+    a virtual console. The crash record is proven: a forced `sysrq-c`
+    panicked, rebooted on the timeout, and the next boot read back
+    `dmesg-ramoops-0` and `console-ramoops-0` with no ECC errors (the
+    first boot's header-init lines did not repeat). Still owed: a GRBL job
+    on the image, then the acceptance campaign (platform change). The `spi_device_id` table for
+    `glowforge,pic` (kernel-module-glowforge) is not in this image; it lands
+    with the module's next pin bump.
+
 **Deliberately not gated:** an armed GRBL job after an underrun cuts at the
 stale origin unless homing is required (GRBL mode permits unhomed cutting; the
 underrun itself alarms and unlinks the anchor). Not in the acceptance catalog

docs/CAMPAIGN-LOG.md

@@ -3751,6 +3751,63 @@ image carrying d97cb35 (a platform change: Mesa joined the image), and
 first light of all of it on an 8 MP machine when one exists. Bench
 left clean; stock service restored.
 
+## 2026-08-24: the kernel built for one board
+
+A read-only review of the running kernel (config, dmesg, bindings,
+module tree, image manifests) found the multi-board defconfig doing
+what multi-board defconfigs do: USB, Ethernet, CAN, Bluetooth, SATA,
+PCIe, NAND, audio, a display stack, touchscreens, ten other i.MX SoCs
+and 153 DVB modules, none with a node in the device tree or a driver
+bound. Two real defects sat among them: `evbug` autoloading for the
+switch block and logging every lid and button transition to the
+kernel log, and the fragment's hung-task and soft-lockup panic lines
+silently dropped because their detectors were off, so only
+`PANIC_ON_OOPS` stood behind the laser-safing notifier. No crash
+record existed either: `panic=10` rebooted and the reason left with
+it.
+
+The fragment was rewritten as the board's driver set plus the
+defconfig's leftovers turned off, and the machine conf names the
+modules and firmware the rootfs carries. The first configure pass
+taught what the defconfig never says: `PM`, the regulator core and
+`EXT4_FS` only ever arrived by selection from suspend, the PMICs and
+ext3, so they are pinned by name now. Built into dev 20260824164619:
+zImage 9.13 MB to 4.76 MB, kernel-module packages 254 to 31,
+`/lib/firmware` down to the WL18xx set and the DualLite VPU blob,
+ARMv7-only code, no virtual console, ramoops in the 1 MiB the factory
+bootloader already holds back at the top of DRAM, and ecspi2 without
+`dmas`, so the pulse ring is the SDMA's only client (the ROM scripts
+stay; the RAM firmware never loaded and no client here needs it).
+
+On the bench, fresh boot of that image: every node binds and nothing
+defers; `hung_task_panic` and `softlockup_panic` read 1, `panic` 10;
+`/sys/fs/pstore` mounts and ramoops registers at 0x2ff00000 with ECC
+(the ten "uncorrectable error in header" lines are the never-written
+region's first initialization, expected once); `/dev/dri/renderD128`
+present and both cameras streamed through the GPU demosaic
+(`gpu: GLES2 debayer up` for lid and head, GPU interrupts 0 to 135,
+snapshot 200 OK); Wi-Fi associated with the regulatory database
+loaded; the switches on `event0`; 31 modules loaded, `evbug` gone; no
+DMA channel held by anyone. MemTotal rose by 9.4 MB. Two new dmesg
+lines, both cosmetic: spi-imx reports the absent DMA channel at ERR
+level and continues in PIO (the PIC probes and reads), and
+`consoleblank=0` is now an unknown parameter without a virtual
+console. `cannot start cut; no data enqueued` at 31 s is not new (47
+earlier occurrences in the kernel log).
+
+The crash record, proven the direct way: `echo c > /proc/sysrq-trigger`
+panicked the kernel, the ten-second timeout rebooted it, and the next
+boot logged no header errors and mounted `/sys/fs/pstore` holding
+`dmesg-ramoops-0` (24 KB, "Panic#1 Part1", the kmsg buffer from
+"Booting Linux" to the panic) and `console-ramoops-0` (23 KB, ending
+"sysrq: Trigger a crash / Kernel panic - not syncing / Rebooting in
+10 seconds.. / ECC: No errors detected"). A panic now leaves its
+reason where the next boot can read it.
+
+Still owed: a GRBL job on the image, the acceptance campaign (platform
+change), and the `spi_device_id` table for `glowforge,pic`, which
+rides the module's next pin bump. Bench left clean.
+
 ## Superseded status notes
 
 ### Shared machine services — remaining polish, as listed 2026-08-13