Thank you for the clarification — understood regarding firmware-applied overlays via `config.txt` not appearing in `dtoverlay -l`. That explains the “No overlays loaded” output and confirms the overlay is indeed merged into the base DT before kernel boot.
Given that, our issue is no longer overlay loading but runtime binding: despite the overlay being applied and the PR2000K subdevice probing successfully, the Unicam async notifier never completes and `bcm2835_unicam_async_bound()` is not called. As a concrete example, the same DT endpoint graph and V4L2 subdevice driver bind correctly on other SoCs (e.g., i.MX / Rockchip) and produce `/dev/video*`, whereas on CM4 the CSI pipeline remains inactive unless the source is a firmware-enumerated sensor.
Could you please confirm whether Unicam on Raspberry Pi is intentionally limited to firmware-recognized camera sensors, and whether generic CSI-2 decoders/bridges (like PR2000K, ADV728x, etc.) are unsupported by design, or if there is a documented/supported way to enable them?
Given that, our issue is no longer overlay loading but runtime binding: despite the overlay being applied and the PR2000K subdevice probing successfully, the Unicam async notifier never completes and `bcm2835_unicam_async_bound()` is not called. As a concrete example, the same DT endpoint graph and V4L2 subdevice driver bind correctly on other SoCs (e.g., i.MX / Rockchip) and produce `/dev/video*`, whereas on CM4 the CSI pipeline remains inactive unless the source is a firmware-enumerated sensor.
Could you please confirm whether Unicam on Raspberry Pi is intentionally limited to firmware-recognized camera sensors, and whether generic CSI-2 decoders/bridges (like PR2000K, ADV728x, etc.) are unsupported by design, or if there is a documented/supported way to enable them?
Statistics: Posted by mukam — Sun Jan 04, 2026 2:52 pm