After a few weeks of playing around, our Genx320 can talk over i2c to a Raspberry Pi 5, but apparently not over MIPI/CSI2. This involved creating a device tree overlay, modifying the Linux drivers open sourced by Prophesee, patching v4l2 utils, compiling the kernel with appropriate flags, and patching the Pi's rp1-cfe media system.

To get around the critical NRESET pin, the device tree overlay sets up a GPIO pin to appropriately set the NRESET to allow the chip to boot -- flipping the hardware switch did nothing because the switch's output pin is somehow only electrically connected to the RESET pin line and thus literally not connected to the 1.8v sub-circuit -- the hardware has an error.

The device boots and the driver code checks for the "boot magic" code which in my case, returns 0xBAADFOOD when instead it expects 0xCAFEBABE. I just bypass this check but desperately want to know if this is either a different firmware version, bad sensor state, or something I can continue to ignore.

Beyond that, the system can power up fine, with i2c reads happening normally, and after setting the correct v4l2 parameters and pipeline, we can even proceed to being detected by the OpenEB software where things will eventually hang on poll() for v4l2 data transfer.

However, this all happens with most of the i2c registers being un-changed: both the driver software and external programs (ie i2ctransfer on the command line) cannot write to most of the registers of the x320 device, such as those that set up mipi/csi communications.

When I've scoped the i2c lines myself, they are able to be decoded and appear okay, and the software doesn't throw any errors on i2c writes, but the register values are never changed. Obviously this is an issue, but there is no obvious cause.

So the a) inability to change most i2c registers  b) the 0xBAADFOOD boot magic code and c) the hardware switch bug make me think that there's something off about the firmware.

Any advice is welcome, and would be appreciated.

For those curious, we are targeting raspberry pi's is because they are widely available generally, already used in the drone space, and don't require custom hardware development; we're building a proof-of-concept counter-UAS drone interceptor.