Describe the bug
imx219 Rev.C (UC-350) working fine on raspberry4 64bit with libcamera interface
imx219 Rev.D (UC-350) not working with various issues with libcamera interface
Additional context
Some imx219 Rev.D can run as secondary camera on multi camera boards. Several have issues on initialization with a direct connection to raspberry. It is unclear why there is variation in behavior, the Rev.D camera have been ordered in one batch from the producer.
dmesg log is shown regardless if camera imx219 C or D is connected on boot:
[ 7.055467] imx219 10-0010: Consider updating driver imx219 to match on endpoints
Updating OS, eeprom, rpi-update did not help.
Swapping (replugging) between RevC and RevD cameras is possible. It leads to same behavior.
RevC working init, RevD error stuck in init.
We are also seeing this issue where the Rev. D modules fail on initialization while the Rev. C modules work fine on the same carrier. We have two different custom carrier designs (Jetson platform, not RPI), and we are seeing elevated failure rates with the Rev. D on one vs. the other.
@torsten_schenk Did you gain any insight into the root cause of the issue?
We had several cameras delivered during the corona chip shortage. The final result of our debugging affords was to identify several faulty cameras Rev.D. Mostly due to i2c timeout. Singapore support identified that error as camera HW failure. Replace was provided quick.
It seems the quality assurance put a lower level during the time of extreme shortage on the market.
In case you need support in debugging, please respond here with a contact information.
We operate the IMX219 in rev B and C without issues. Still camera shooting on full resolution on timed intervals is the standard application. We operate the camera on RPi systems in double camera mode.
Since Rev D was introduced we get erratic break downs due to resource failures, typcially described as “Camera was not closed” issues in various RPi chats. Standard Error is "failed to enable port vc.null_sink:in:0(OPQV): ENOSPC followed by various iterations of same issue and a final “Out of Resources” Summary of PiCamera software package.
However, the behaviour is unpredictable. It took us quite some time until we noted that not the mainboard, not the cables (flash/data) are the problem but rev D cams. Further difficulty was, that some have worked, but at a 30 to 40% success rate only. We operate is harsh environment, which makes finding this more difficult.
We have three Cams of Rev D left but we need to purchase another 20 set pack in next quarter to replace wear and tear.
Question: Is Rev D generally an issue and is there a new REV E available which is stable ? Or is a stable Rev D batch available - if yes - how to recognise when purchasing?