bcm27xx: enable Raspberry Pi camera stack

[jeremymcgee73]

Summary

Enable Raspberry Pi CSI camera support on OpenMANET bcm2710 and bcm2711 builds, and wire the default camera streaming path to the OpenMANET HaLow-facing interface.

This MR adds the kernel/module/image/config changes needed for Raspberry Pi CSI cameras, and updates the openmanet feed pin to package-side fixes for libcamera and camera service defaults.

What this changes

Firmware-side changes

• add missing kernel package definitions for:
  • kmod-video-cci
  • kmod-video-dw9807-vcm
  • camera sensor modules:
    • kmod-video-imx219
    • kmod-video-imx477
    • kmod-video-imx708
    • kmod-video-ov5647
  • kmod-i2c-mux-pinctrl
  • kmod-camera-bcm2835-unicam
• enable required bcm27xx kernel config for Raspberry Pi camera sensors
• include the Raspberry Pi camera sensor packages in bcm2710 / bcm2711 Morse Pi images
• enable camera-related package defaults in the Pi camera diffconfigs
• restore DMA heap object build so libcamera / RPi camera pipelines can allocate DMA heap devices correctly
• pin the openmanet feed to the package commit that contains the corresponding userspace fixes

Package-side dependency

This MR depends on the packages branch:

• codex/libcamera-rpi-fix

That branch includes:

• a libcamera fix for an RPi first-stream crash in the frame-length queue path
• a Pi-only default that sets camera-onvif-server.rpicamera.interface=ahwlan
• a Pi-only preserved-config migration that corrects old lan camera service bindings when ahwlan comes up

Why

Before these changes:

• the IMX219 sensor could be present in DT but not fully usable in OpenMANET images
• sensor kmods were not available by default in the target images
• the RPi camera pipeline failed when DMA heap objects were not built
• camera-onvif-server defaulted to lan, which does not match the OpenMANET Pi network topology when the device uses ahwlan
• preserved-config upgrades could carry forward stale lan camera service settings

After these changes:

• cam -l enumerates the camera
• the MediaMTX rpicamera path is created correctly
• RTSP streaming works from the Pi camera on OpenMANET Pi images
• camera service interface selection matches the OpenMANET Pi network model

Scope

Explicitly supported by this MR:

• bcm2710
• bcm2711

This MR does not claim support for:

• bcm2712 / Pi 5
• non-Raspberry Pi OpenMANET boards such as Venice / HD01

Validation

Validated on Raspberry Pi 4 / bcm2711 with IMX219:

• cam -l reports:
  • 1: 'imx219'
• media-ctl -p -d /dev/media2 shows sensor -> unicam topology
• MediaMTX exposes:
  • rtsp://<device-ip>:554/rpicamera
• streaming succeeds once camera-onvif-server is bound to ahwlan

Also verified:

• the Pi-side camera service default is corrected to ahwlan
• preserved-config cases can be migrated automatically when ahwlan comes up

Notes

This MR should be merged together with, or after, the corresponding packages branch update, since feeds.conf.default is pinned to that package commit.

[GhostLabs-ent]

I’m testing this on a Raspberry Pi 3A+ / bcm2710 target and found what looks like a small bcm2710 gap in the current PR.

The codec package itself already exists as:

kmod-codec-bcm2835

but the bcm2710 board config still references:

CONFIG_PACKAGE_kmod-video-codec-bcm2835=y

which does not appear to correspond to an existing package.

I also found that ekh-bcm2710 does not currently pull in the camera/video common_extras configs, while the bcm2711 target does. That means the fixes in camera_diffconfig from this PR are picked up automatically on bcm2711, but not on bcm2710.

From my local review, the bcm2710 side appears to need only a very small follow-up:

• correct the stale kmod-video-codec-bcm2835 package name to kmod-codec-bcm2835
• include camera_diffconfig for ekh-bcm2710
• include video_diffconfig for ekh-bcm2710
• correct the same stale package reference in the other affected bcm2710 board config

I’m currently building/testing this on an actual Pi 3A+ with a UVC camera.

Current device evidence before the fix:

• vcgencmd codec_enabled H264 -> H264=enabled
• FFmpeg already exposes h264_v4l2m2m
• UVC capture is working
• no V4L2 M2M H.264 encoder is currently exposed because the bcm2835 codec kmod is not present

Once I validate the rebuilt image, I can post the exact diff and before/after V4L2 results here.