Cold boot occasionally comes up with no display at all (A8 + Renits A5)

[eliasbakken]

On a Recore A8 with a Renits A5, a cold boot (power applied from off) came up with no
image on the screen at any point — the panel appeared to be off for the whole boot, never
showing the u-boot splash nor anything afterwards. The board itself booted normally.

This is not the flicker/re-lock of #77. There the panel is showing an image and loses it
briefly. Here nothing is displayed at all, start to finish.

Frequency

n=1, possibly n=2 — one of the attempts cut power at the 220V switch rather than at the
board, so it may not be an equivalent test. Not reproduced since:

attempt	result
cold boot into Rebuild	no image at all
warm boot	fine
warm boot into Reflash	fine
cold boot from Reflash into Rebuild	fine

So it is rare, or depends on how power is removed/applied.

Why this is worth tracking rather than dismissing

All of #77's validation used warm reboots (systemctl reboot) — 30/30 clean. Cold boot
was never measured, so it is a genuine gap rather than a regression from that work. Cold boot
differs in ways that plausibly matter for the display path:

• the USB phys start from power-on reset rather than a state Linux had initialised
• rails ramp from zero instead of staying up (relevant if the coupling is a decoupling
  weakness on this board — early revisions had USB instability suspected around audio
  voltage domains)
• the panel's own firmware boots cold and acquires from scratch, rather than already being
  locked when the SoC resets
• 220V-switch removal vs. board-level power-off may discharge rails differently

Environment

• Recore A8, Renits A5 screen, 5 USB devices (Cypress hub, Renits A5, Logitech C270,
  Realtek 802.11ac, rp2040)
• Image rebuild-fluidd-cd3e92e / rebuild-barebone-cd3e92e
• u-boot 2024.01_armbian-…-Pccb4-… — includes the u-boot -> Linux splash handover: HDMI glitch traced to USB PHY1 reset in usb_stop() #77 fix
• kernel 6.18.33-edge-sunxi64

What would pin it down

1. Reproduce with counting. Cold-boot N times and score; the failure rate decides whether
   this is a real defect or a one-off. Distinguish 220V-switch removal from board-level power
   cycling, since those are not the same test.
2. Serial console during a failure. A capture exists for this period
   (~/serial-a8.log, CH340 on the laptop) — a failing cold boot should show whether u-boot
   set the display up at all, or set it up and the panel never acquired.
3. Panel telemetry. The Renits A5 has no async event stream today, which is what made the
   Manga Screen 2 measurable in u-boot -> Linux splash handover: HDMI glitch traced to USB PHY1 reset in usb_stop() #77. Its firmware is modifiable — even a minimal
   "lock acquired / lock lost" line over USB would make this scriptable instead of eyes-only.

Related

• u-boot -> Linux splash handover: HDMI glitch traced to USB PHY1 reset in usb_stop() #77 — u-boot → Linux handover glitch (fixed; validated on warm reboots only)
• USB gadget never comes up on A5, A6 or A7 - nothing appears in lsusb #75 — USB gadget setup

[eliasbakken]

Cold-boot rig is working, and the oracle is now calibrated

Built a reproducible cold-boot loop and, more importantly, a display oracle that
has been checked against reality. No reproduction yet — this is infrastructure,
not a result.

The rig

A Shelly Plug S Gen3 supplies the board, so each iteration is a genuine cold
start rather than a warm reboot (which does not reproduce this):

systemctl poweroff  ->  wait for ping to stop  ->  cut mains 10s  ->  wait for ssh
curl "http://<plug>/rpc/Switch.Set?id=0&on=false&toggle_after=10"

toggle_after does the off/on in a single call, so a dropped HTTP reply cannot
strand the board powered off. 5s was not enough for the rails to drain — that is
a brownout, not a cold start. 10s works.

Confirmed the plug really does feed the board by watching its power meter across
a cycle: 13.7 W running → 1.1 W halted → cold cut.

Boot time is consistent: 45–47 s from power-on to ssh, across 6 cycles.

The oracle

DRM state is not a usable signal: the SoC will happily scan out into a bridge
that never locked, so /sys/class/drm/... reports connected / enabled /
dpms On whether or not a picture actually arrives. Only the panel can answer
this, so the oracle is the Manga Screen 2's own status command over its CDC
console.

Two firmware quirks had to be worked around, both of which cost real time:

1. The async event printer shares state with the microrl line editor. Event
   text lands in the command input buffer, so a command sent mid-event gets
   concatenated onto the fragment already there. Visible directly in minicom:

   sition change detection interrupt
   ...
   command: 'sition' not found
   command: 'change' not found
   

   The fix is to wait for the event stream to go quiet, send a bare CR to discard
   any partial line, wait again, and only then send status. Without the drain,
   the port returns zero bytes and looks dead.

2. Lines terminate with a bare CR (no LF) and every typed character is echoed
   wrapped in ANSI cursor moves. Both must be stripped before parsing.

Fields that are NOT usable as failure signals

Measured constant on a known-good panel, so they must not be scored:

• Sync: no — reads no while the display is working perfectly
• +INT_DSI_ACKERR: 0x0020 — fires on every single query

The verdict uses only Has input, Phy PLL Lock, TMDS, Display is On, and
Resolution == 720x1280.

One false positive, worth recording

The first cold cycle scored DOWN — and the screen was fine. The MS2 console was
mute (the drain bug above), and "console will not answer" was being conflated with
"panel is dark". The loop now reports NO_ANSWER as a distinct outcome from
DOWN, retries the query four times, and dumps DRM state, USB presence, service
status and a dmesg tail on any non-UP cycle so the two can be told apart after
the fact.

Calibration result

5 cold cycles on Recore A7 + MS2, rebuild-fluidd-v1.1.0-RC5, kernel
6.18.33:

UP=5  DOWN=0  NO_ANSWER=0

The instrument agrees with reality. It does not say anything about the failure
rate — at a true rate of 20%, five clean boots would still happen ~33% of the
time. It only means a future DOWN is now worth believing.

Next

• Longer unattended run, with broader per-boot health checks than just the panel:
  failed systemd units, kernel panics/oopses, service states — a cold boot could
  be broken in ways that have nothing to do with the display.
• Test A8 + Renits A5, which is the combination this was originally seen on.
  A7 + MS2 may simply not be affected, in which case sweeping it will never
  reproduce regardless of how many boots we run.

[eliasbakken]

Data point for the frequency table, 2026-08-19. Same hardware as the report: Recore A8
with a Renits A5.

attempt	result
warm reboot, Reflash -> rebuild-fluidd-8e73c9c	display fine, no flicker

So this adds to the "fine" column rather than reproducing the fault. Worth recording only
because it is the same A8 + Renits A5 combination the report is about, on a newer image
(8e73c9c vs cd3e92e), and because #77's fix is in the u-boot underneath it.

It does not touch the open question. This was a warm reboot, and the report is
explicit that warm boots have always been fine - the gap is that #77's 30/30 validation
never covered cold boot. Nothing here narrows that.

Serial console was captured across the reboot. It shows a clean handover with nothing
display-related: u-boot 7.65s to Starting kernel, Splash displayed, DTB and a 23.8 MiB
uInitrd loaded with a verified checksum, then silence because the image boots quiet. The
only two error-level lines were a USB-audio sample-rate rejection and WCN_ERR: dts node for bt_wake not found, neither of which is display-related.

Also worth restating from the report's own "what would pin it down" list: the Renits A5
has no async event stream, so unlike the Manga Screen 2 in #77 there is no oracle here -
a failing cold boot can only be scored by eye. Until that changes, reproducing this needs
someone watching the panel through N cold boots, and the 220V-switch vs board-level
power-off distinction has to be kept separate.

[eliasbakken]

Closing as cannot reproduce.

10 consecutive cold boots, 0 failures. Recore A8 with the Renits A5 - the same
hardware combination as the report. Mains removed at a Shelly plug for 10s after a
controlled shutdown each time, so the rails genuinely started from zero:

boot time   40-47 s   (mean 42.4, ping-to-answer)
settled     21.5-21.8 W  (spread 0.3 W)
services    klipper + KlipperScreen active, 10/10
display     came up every time (confirmed by eye, not only by meter)

Elias also reports not having seen it since the original occurrence. The likely
explanation is that it was an artefact of an earlier, botched image rather than a
standing defect.

What this does and does not establish. 0/10 bounds the failure rate at roughly
26% (95% CI) - it does not show the rate is zero. Given the report was n=1
(possibly n=2), a true rate well under 26% was always likely, so this run is
consistent with the fault existing and simply not appearing. Bounding it at 10% would
need ~30 boots and at 5% ~60. Those were not run, because the visual evidence and the
absence of any recurrence make further cycling poor value.

Two caveats worth recording in case this comes back:

• The test used 220V removal at the plug, which the issue is explicit is not the
  same test as board-level power-off. That case remains unexercised.
• The board was on 8e73c9c with a hand-regenerated initramfs, not the cd3e92e the
  report was filed against, so the software is not an exact match either.

If it does recur, the cycling harness makes it cheap to chase. Controlled
shutdown, cut mains, restore, capture serial read-only, sample power once settled -
about 2 minutes per cycle unattended. The halt is detected from the meter (a running
board draws ~21 W, a halted one ~7.5 W) rather than a fixed wait.

One honest limitation of that harness: power is an unvalidated oracle for this
fault. Content barely moves the meter - Plymouth alone reads 21.4-21.5 W against
KlipperScreen's 21.6 W - so the draw is dominated by the backlight being on at all.
If a failure means the panel gets no signal and drops to standby, the drop will be
obvious; if it means the panel is lit but showing black, the meter will score the
failure as a pass. That could not be calibrated remotely: the panel exposes no
backlight control under /sys/class/backlight. The first real failure would settle it
in one reading.

[eliasbakken]

Reproduced, and it is not rare: 9 failures in 38 boots (~24%)

This was closed at n=1–2 as "rare, or depends on how power is removed/applied". Running the
counting experiment this issue asked for, it reproduces at roughly one boot in four.

The measurement came out of an unrelated boot loop for #85 (scripts/hunt-110, controlled
shutdown now then a 6–9 s mains cut, with scripts/serial-log capturing the console). The
off-time is almost certainly irrelevant to this fault — failures are spread across all four
buckets — but the loop happens to be a cold-boot generator with a serial capture attached,
which is exactly what point 1 of "What would pin it down" asked for.

	count
boots	38
Splash displayed	30
Splash failed to display	9

Failures are intermittent throughout, not clustered: there is a 15-boot clean run in the
middle and further failures after it, so this is not a warm-up effect.

What is actually failing

On the console the only visible symptom is an error about an unrelated environment variable:

## Error inserting "stdout" variable, errno=22
Splash failed to display

That comes from boot-sun50i-next.cmd, which does setenv stdout vidconsole before drawing
the splash. EINVAL there means U-Boot has no vidconsole device — the video device never
bound. bmp display then fails for the same reason.

The chain, with the U-Boot v2024.01 sources:

1. sunxi_dw_hdmi_probe() — drivers/video/sunxi/sunxi_dw_hdmi.c:360

   ret = dw_hdmi_phy_wait_for_hpd(&priv->hdmi);
   if (ret < 0) {
           debug("hdmi can not get hpd signal\n");
           return -1;
   }

2. dw_hdmi_phy_wait_for_hpd() — drivers/video/dw_hdmi.c:925 — polls hot-plug detect and
   gives up after 300 ms.

3. Probe fails → no video device → no vidconsole → setenv stdout vidconsole returns
   EINVAL → no splash.

The failure is invisible by design. The only diagnostic on that path is debug(), which
is compiled out of a normal build, so the log shows an env-variable error and nothing about
HDMI at all.

Why this is "no image at all", not "no splash"

armbian/recore.csc sets CONFIG_DRM_SUN4I=n and CONFIG_DRM_SIMPLEDRM=y. Its own comment
says it: "the mode is whatever u-boot set at boot." The kernel has no display driver of its
own — it inherits U-Boot's framebuffer.

So when U-Boot's video probe fails there is no framebuffer to hand over, and the panel stays
dark for the entire boot: no splash, no Plymouth, no console, no KlipperScreen. That is
precisely what this issue described — "no image on the screen at any point ... the board
itself booted normally" — and it explains why it looked like a display-hardware mystery
rather than a boot-time probe failure.

It also explains why it seemed rare. On a barebone or KlipperScreen image a dark panel is
indistinguishable from a board that did not boot, and nobody was watching the serial console.

Timing evidence

The splash step is sharply bimodal, with nothing in between across 38 boots — a fixed timeout,
not variance:

ok    bmp loaded -> "Splash displayed"      0.020 s
FAIL  bmp loaded -> errno=22                0.840-0.850 s

What does not fit yet

The obvious reading is "HPD is not asserted within U-Boot's 300 ms window", and raising that
timeout is the obvious fix. But one measurement argues against it being that simple.

The gap between Loading Environment ... OK and the In: line — where stdio, and therefore
the video device, is set up — is shorter on failing boots:

ok    env -> stdio   1.340-1.350 s
FAIL  env -> stdio   1.270-1.280 s

If a 300 ms HPD timeout were being hit during that step, failing boots would be longer
there, not ~70 ms shorter. So either the probe fails earlier and faster than the HPD wait, or
the 845 ms seen later is a second probe attempt, or the video device is probed lazily at
setenv rather than at stdio-init. The data collected so far cannot distinguish these.

Concretely: this evidence does not establish that HPD is asserted late. It is equally
consistent with HPD never being asserted at all on those boots, in which case no timeout
change helps.

Proposed next step: instrument before changing anything

1. Make the failure speak. Turn the debug() in sunxi_dw_hdmi_probe() into a
   printf(), and print how long dw_hdmi_phy_wait_for_hpd() actually took plus the final
   plug-in status. On a healthy boot that also tells us the normal HPD latency — if it is
   ~0 ms on all 30 good boots, then "marginally late" is the wrong model and a longer timeout
   would be pointless.
2. Re-run the loop (~40 boots, about 40 minutes) and read the answer off the capture.
3. Only then pick a fix. If HPD arrives late but arrives, raising the 300 ms limit is a
   one-line patch that costs nothing on a healthy boot, since hdmi_get_plug_in_status()
   returns immediately when HPD is up — that is why passing boots take 20 ms. If HPD never
   arrives, the question moves to the panel or the HPD signal itself, and a retry of the whole
   probe would be the thing to try instead.

Worth keeping regardless of the outcome: the debug() → printf() change. A failure mode
that reports itself as errno=22 on an env variable cost a lot of time to trace back to HDMI.

Environment

• Recore A8, image rebuild-barebone-891e72c, kernel 6.18.33-edge-sunxi64
• u-boot 2024.01_armbian-...-S866c-P0d41-Hc6a9-V29e7-Bd0d2-R448a
• 5 USB devices on the bus, panel as in the original report
• capture: scripts/serial-log, loop: scripts/hunt-110

[eliasbakken]

Reopening: closed at n=1-2 as possibly-rare, now reproduced at 9/38 boots (~24%) with a mechanism and a serial capture.

[eliasbakken]

Follow-up: the leading hypothesis is that this is about how USB and HDMI power are brought
up, not about HDMI in isolation.

u-boot-sunxi64-legacy-5-hdmi-vbus.patch puts HDMI VBUS on PG9 as a fixed regulator, defined
alongside the usb1-vbus nodes, and it is asserted by regulators_enable_boot_on() from
board_init() (patch 3). That commit message already states the constraint this issue keeps
running into:

It also has to come up before video probes and reads EDID, which is why doing it via
board_init() works where a manual "gpio set" at the prompt is already too late.

So HDMI VBUS and USB VBUS are enabled by the same mechanism at the same moment, and the video
probe's 300 ms HPD window starts shortly after. If the panel is still powering up when that
window opens, HPD is low for the whole of it and the probe fails - which is consistent with
everything observed, and would make "cold boot" the relevant variable exactly as the original
report said.

One thing that can be ruled out already: it is not downstream USB trouble. Across 41 boots
in the loop, splash failures do not track EHCI enumeration problems:

splash	EHCI timeout	count
FAIL	no	8
FAIL	yes	1
ok	no	27
ok	yes	5

11% of failures saw an EHCI timeout against 16% of successes, and both groups enumerate the
same 5 devices. Enumeration is not the discriminator.

That is not evidence against the VBUS-timing hypothesis, though - regulator bring-up happens in
board_init(), long before enumeration, and leaves nothing in the log. Nothing currently
printed distinguishes a boot where PG9 came up in time from one where it did not, which is why
the instrumentation step above is worth doing before changing any timeout: print the actual HPD
latency and plug-in status, and the answer follows directly.