Preparing the repo to go public (ADR-0007): - CI: kernel-build moves from the self-hosted runner to ubuntu-latest (installs its own cross toolchain + qemu, caches the pristine tarball). On a public repo a registered self-hosted runner is reachable from approved fork-PR workflows — i.e. arbitrary code on private infrastructure — and the build never actually needed the SDK host. ADR-0004 marked superseded-in-part; docs/ci-cd.md rewritten (site specifics now live only in the private deployment log). - Licensing: LICENSE gains the GPL-2.0 carve-out for patches/ and the kernel source excerpts (Linux derivatives; per-driver provenance was already tracked in PROVENANCE.md); patches/README.md states it too. - Scrubbed from the tip: bench-unit dev credentials and its gadget IP (m2-boot notes), the site AP SSID+BSSID and a neighboring AP's BSSID and the device WLAN MAC (wifi bring-up evidence — BSSIDs are geolocatable), the runner mesh IP. NOTE: these remain in git history; decision on a pre-publication history rewrite is separate. - Emoji cleanup across 21 tracked files (kernel port docs, review report, enforce-mcdc.sh) per repo text conventions: status marks became [x]/[wip]/[ ]/OK plain text. - "[maintainer]-gated" process phrasing normalized to "maintainer-gated" (attributions in dated evidence docs kept). Verified: zero emojis tracked; scrub grep clean; patches carry no internal references; ci.yml parses; shellcheck unchanged. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_018HUayid7W5w7jBdb9Rrj1K
5.2 KiB
Display (VOP + RGB panel) — VERIFIED on warden-c8a3 (2026-08-25)
The 86-Panel renders the full WardenOS Dashboard UI on our self-built Linux
6.18.46 (_b slot), pixel-identical to the stock 5.10 _a slot. Verified by
webcam pointed at the physical panel (pixels can't be checked over serial/ssh) —
warden-ui -b DRM drawing the Dashboard: nav sidebar, "Wellhead 03" site card,
Mesh/WAN/LAN/RS485 status rows, correct colors, no banding, no colour swap.
This closes the "Open" item in README.md (connector-not-created + the deeper
black-screen chain that followed it).
The bring-up chain (each step was a real blocker)
- Connector never created (
Cannot find any crtc):CONFIG_ROCKCHIP_RGBwas not set, AND the vendor&rgbbridge node's dangling endpoint (rgb_in_vop -> vop_out_rgb) read to fw_devlink as a vop↔panel dependency cycle, so the VOP probed before the panel. Fix: enableROCKCHIP_RGB+/delete-node/ &rgb;sovop_out_rgb <-> panel_in_vopis the only graph link (rockchip_rgb_init then defers + retries and finds the panel →LVDS-1). - Backlight dark:
&pwm1hadpinctrl-names = "active"; mainline pwm-rockchip relies on the driver core auto-applying the"default"state, so the PWM pin was never muxed. Fix: rename to"default". - bus-format unset (RGB output width undefined): mainline
panel-dpiignores the DTbus-format. Fix: smallpanel_dpi_probe()patch to read it +bus-format = <MEDIA_BUS_FMT_RGB666_1X18>on the panel node. - RGB output pins unmuxed (no data reaches the panel): the 22-pin parallel
bus (
lcd_clk+lcd_d0..d17+ den/hsync/vsync) needs the&lcd_pinsmux. The vendor carried it aspinctrl-0 = <&lcd_pins>on the&rgbnode, which we deleted in step 1. Fix: re-attach it on&vop(pinctrl-names="default"; the core auto-applies it at VOP probe). reset-gpioson the panel node is WRONG (leave it off): GPIO0_A1 resets the CH32V003 panel-init MCU, released once early by U-Bootboard_init(). Handing it topanel-simplemakesdrm_panel_prepare()re-reset the MCU mid-scanout. Luckfox deleted these props upstream (commit e2b0ffa22); the flare-edge 5.10 DTS documents the deletion as "the fix." We match: backlight only, no reset-gpios.
The two root causes of the final "backlit-black" (VOP driver bugs)
With connector + backlight + pins + panel-init all correct, the screen was still
physically black (backlight on, LVDS-1 connected, VOP streaming, fb0 720×720,
modetest/splash written) — the classic "everything healthy, glass dark" state.
Found by dumping the VOP register block 0xff990000 on the working _a slot
and diffing against _b (same SoC, same register map):
Bug 1 — DCLK polarity inverted. rockchip_drm_vop.c hardcodes
rgb_dclk_pol = 1 for the LVDS/RGB output. The panel latches pixel data on the
non-inverted edge — _a reads PX30_DSP_CTRL0 (0xff990020) = 0x1
(rgb_dclk_pol bit1 = 0). The vendor 5.10 derives it as
(bus_flags & PIXDATA_DRIVE_NEGEDGE) ? 1 : 0, which is 0 for this panel. With the
inverted clock the panel samples RGB on the wrong edge → black. Fix: set
rgb_dclk_pol to 0 in the DRM_MODE_CONNECTOR_LVDS case.
Bug 2 — wrong primary scanout window. The rv1106 VOP scans out through
WIN1, but our port reused rv1126's win table (win0-overlay + win2-primary).
The vendor rv1106_vop_win_data is { NULL-win0, rk3366_lit_win1_data-primary } —
i.e. WIN1 (PX30_WIN1_* at 0x090). Mainline was configuring WIN2, which never
reaches this SoC's RGB interface, so WIN1 stayed all-zero and nothing scanned out.
Register evidence (_a working vs _b broken, before the fix):
| reg | name | _a (works) |
_b (black) |
|---|---|---|---|
| 0x090 | WIN1_CTRL0 (enable) | 0x00000001 |
0x00000000 |
| 0x098 | WIN1_VIR (stride) | 0x000002D0 (720) |
0x00000000 |
| 0x0a0 | WIN1_MST (fb addr) | 0x0F900000 |
0x00000000 |
| 0x0a4 | WIN1_DSP_INFO (size) | 0x02CF02CF (720×720) |
0x00EF013F (stale) |
Fix: rv1106_vop_win_data[] = { { .phy = &px30_win1_data, PRIMARY } }
(px30_win1_data already exists in mainline over PX30_WIN1_* — just wasn't wired
for rv1106). After the fix _b reads WIN1_CTRL0=1, WIN1_DSP_INFO=0x02CF02CF —
matching _a.
Files changed (in research/linux-6.18.46)
drivers/gpu/drm/rockchip/rockchip_drm_vop.c—rgb_dclk_pol1 → 0 (LVDS case).drivers/gpu/drm/rockchip/rockchip_vop_reg.c—rv1106_vop_win_datausespx30_win1_dataas the single PRIMARY window (was rv1126's win0+win2).drivers/gpu/drm/panel/panel-simple.c—panel_dpi_probe()reads DTbus-format.arch/arm/boot/dts/rockchip/rv1106-warden.dts—&voppinctrl<&lcd_pins>;&pwm1pinctrl "default";/delete-node/ &rgb; panelbus-formatRGB666, no reset-gpios.
Known separate issue (NOT display)
_b still cold-reboots periodically (pre-existing _b general-stability issue,
independent of the display — the panel renders correctly the whole time it is up).
Tracked separately; the high-bootlimit env (bootlimit=10000) keeps these reboots
from tripping altbootcmd=download into the loader during bring-up.