Written as a Pi 5 project because that is where the first camera went. That was
never the destination — the camera is meant for an Orin Nano, and the Pi was
convenient and available first.
⚠ This is not a wording change. The two boards do not share a camera stack:
libcamera/picamera2 on the Pi, V4L2/GStreamer with Argus for CSI Bayer sensors
on the Jetson. Code written directly against picamera2 does not run on the Orin
at all. So capture goes behind an interface with a backend per platform, chosen
at runtime from what the hardware reports, and everything above it depends only
on "a source of frames". Recorded as the main design constraint rather than
left to be discovered when the code moves.
The same split decides where face recognition can live: TensorRT on GPU/DLA on
the Orin, CPU-only on the Pi. The Pi proves the pipeline, never the
performance, and AGENTS.md now requires a measurement to say which board it
came from.
Also generalises the camera-not-detected section to cover both boards, and
keeps the cable notes that cost a module: the Pi 5's 22-pin FPC versus 15-pin
Pi 4-era cables, and that Jetson carriers use their own pinout, so a cable
fitting a Pi does not necessarily carry the same signals.
Status corrected to "no camera connected anywhere" — the first module's cable
is confirmed faulty and the module may be damaged; a second is being tried on
an Orin.
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