The first version told the reader a camera in "a DISP port" would never appear.
That is Pi 4 thinking. The Pi 5 has two 4-lane MIPI connectors, CAM/DISP 0 and
CAM/DISP 1, and BOTH are dual-purpose — either one accepts a camera. Left as
written it would have sent someone hunting a port mix-up that cannot happen,
and away from the likelier cause.
Promotes that likelier cause to the top: the Pi 5 uses the narrow 22-pin FPC,
while Pi 4-era camera modules ship with a 15-pin cable and need the adapter.
Also records the evidence that narrows this to hardware rather than config.
pisp_be is loaded and /dev/media0-2 exist, so the imaging pipeline is up, but
/sys/bus/i2c/devices holds only i2c-13 and i2c-14 — no camera bus was
instantiated and no CFE bound. camera_auto_detect probes at boot and loads a
sensor overlay when it finds one, so an absent bus means the firmware found
nothing to probe. Confirmed unchanged across a reboot.
README records the real starting state rather than an aspirational one: the
camera module is NOT detected. rpicam-hello reports no cameras and dmesg has no
sensor probe lines at all, while camera_auto_detect=1 is already set and the
libcamera userland is fully installed. Silence in dmesg is the diagnostic — a
sensor that is seen but misconfigured still probes — so this is cabling, not
config, and the doc says so instead of sending anyone to edit dtoverlay lines.
Also records the trap that /dev/video* nodes already exist on this Pi and belong
to the codec and ISP blocks, so they are not evidence of a camera.
AGENTS.md gives Codex the project-specific rules: it runs ON the target, so it
should test rather than reason about whether something would run; it must not
try to fix the camera in software; and claims about the stream need a command
that ran, because a 200 with no frames looks exactly like a working one.
Mikkeli
mikkeli