Skip to main content

Debugging a Raspberry Pi video problem

· 3 min read

I was putting Home Assistant OS on a spare Raspberry Pi 4, booting off a USB SSD, with an HDMI capture card plugged into the board so I could watch the boot on my main monitor. I powered it on, console output started scrolling, and about four and a half seconds in the screen went to NO SIGNAL and stayed there. Every boot attempt did the same thing.

Four hardware swaps, same failure​

I read this as the board failing to boot, so I started ruling out hardware:

  • Changed the power supply.
  • Moved the SSD to a different USB port.
  • Added a powered USB hub between the SSD and the board.
  • Swapped the keyboard.

Identical result each time. Screen drops to NO SIGNAL a few seconds into boot.

The screen dropped at the same moment every time​

I had been noting that the screen dropped, never when. Going back over those four boots gave me:

4.4027s
4.7080s
4.6497s
4.4972s

Four different hardware configurations, all landing inside about 300 milliseconds of each other. I stopped swapping parts and went to look at what the kernel was doing at that point in boot.

[drm] Initialized v3d 1.0.0 for fec00000.v3d​

That was the last line before the screen went dark, and it was the same line on all four boots. It's the Pi's GPU driver taking over the display from the firmware framebuffer, the same vc4-kms-v3d handover I wrote about on a Pi 5: enabling full KMS hands graphics memory control to the kernel instead of the firmware.

My guess is that the handover renegotiates the HDMI link, and that the capture card, which is built to lock onto a signal that has already been negotiated, doesn't follow a live renegotiation and never comes back. I didn't verify that. I unplugged the capture card, plugged a real monitor into the same cable, and booted the same board: full console output, start to finish, no drop. That test says nothing about whether my HDMI explanation is right.

Evidence I had the whole time​

The bootloader on this board keeps a counter of failed boot attempts, part of a failover scheme that falls back to a known-good image if boots keep failing. It only counts down when the running OS reports back that it booted successfully. It sat at "2 attempts remaining" through all four hardware swaps, which means the OS had been reporting successful boots the whole time I was replacing power supplies.

A second machine on the network could also reach the Pi over HTTP while the console showed me nothing. One port answered with a healthy status page. The port for the Home Assistant app itself refused the connection outright rather than timing out, so the network stack was up and something further along in the boot was still missing.

Serial console first​

On any new single board install I now wire up a serial console on the GPIO header before the first boot instead of after I hit something like this. It doesn't go through the display pipeline at all.