An IMX219 is live on the Orin's CAM0 at /dev/video0, verified by capture rather
than by a bound driver: a 16,163,840-byte frame, exactly 3280x2464x2 for
10-bit Bayer, 99.8% non-zero across 40 distinct values. Real sensor data, not
an allocated buffer.
⚠ The fault was configuration, and it is indistinguishable from dead hardware.
The Pi auto-detects cameras; the Jetson does not. Until the sensor's device-tree
overlay is selected there is no /dev/video0, no sensor line in dmesg and nothing
on i2c — the same evidence a broken cable produces, which is how it got blamed
on a cable here. Fixed with config-by-hardware.py, and the README now says to
check the OVERLAYS line BEFORE suspecting hardware.
Two traps recorded with it: the -n flag needs the header number (2= for the CSI
connector) or it defaults to the 40-pin header and reports the module as
unsupported, and v4l-utils is not installed by default so v4l2-ctl reports
"command not found", which reads as "no camera".
The Pi 5 fault was genuinely a cable and is kept for contrast, along with why
its lit IR LEDs proved nothing: the illuminator sits on the 3.3V rail
independently of the i2c and CSI lanes, so it lights whenever the ribbon carries
power, even when the traces detection needs are broken.
AGENTS.md also gains the rules that came out of a 27-attempt loop in this repo:
write files with apply_patch and never write_stdin, never invent or increment a
session id, stop after two identical failures instead of retrying, and emit tool
calls as JSON arguments rather than leaking <parameter=...> markup into strings.
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.
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