From cb9cd53bda2e35041746720ba1d693a0eecc6611 Mon Sep 17 00:00:00 2001 From: ScottW514 Date: Mon, 24 Aug 2026 14:17:48 -0400 Subject: [PATCH] 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 | 27 +++++++++++++++++++++ docs/CAMPAIGN-LOG.md | 57 ++++++++++++++++++++++++++++++++++++++++++++ 2 files changed, 84 insertions(+) diff --git a/docs/BRINGUP.md b/docs/BRINGUP.md index 626db86..7dd6ac8 100644 --- a/docs/BRINGUP.md +++ b/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 diff --git a/docs/CAMPAIGN-LOG.md b/docs/CAMPAIGN-LOG.md index a70e042..9ff337e 100644 --- a/docs/CAMPAIGN-LOG.md +++ b/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