Hi, I tried the V4L2 driver with Buster which worked OK on a Pi4 4 GB then I tested Bullseye with the legacy mode and the same V4L2 driver ( veyecam2m ver 5.10.63) and that worked OK too.
I was previously testing with a Pi 3A which I would like to work but that does seem to have a problem with the v4L2 driver with both OS's.
Posts made by Roger
-
RE: imx327 missing from raspberrypi_v4l2 ver 5.10.63-
-
RE: imx327 missing from raspberrypi_v4l2 ver 5.10.63-
I have the IMX327E boards. I am currently trying with bullseye 5.10.63.
I installed the veyecam2m driver and updated the raspi-config to be able to select legacy support but I cannot get motioneye to work nor can I get the gstreamer tests on your readme on github for the v4l2. I see that the readme is out of date compared with the wiki but I still cannot get gstreamer to work.
This all seems in order....pi@raspberrypi:~ $ dmesg |grep veye
[ 11.775403] veyecam2m 10-003b: camera id is veyecam2m
[ 11.778121] veyecam2m 10-003b: sensor is IMX327
[ 11.778144] veyecam2m 10-003b: board type is TWO board
[ 11.779786] veyecam2m 10-003b: veyecam2m camera probed@raspberrypi:~ $ ls /dev/video0
/dev/video0pi@raspberrypi:~ $ v4l2-ctl --list-formats-ext
ioctl: VIDIOC_ENUM_FMT
Type: Video Capture[0]: 'UYVY' (UYVY 4:2:2) Size: Discrete 1920x1080
But gstreamer gives:-
pi@raspberrypi:~ $ gst-launch-1.0 v4l2src num-buffers=1 device=/dev/video0 ! 'video/x-raw, format=(string)UYVY, width=1920,height=1080' ! jpegenc ! filesink location=test_image.jpg
Setting pipeline to PAUSED ...
Pipeline is live and does not need PREROLL ...
Pipeline is PREROLLED ...
Setting Pipeline to PLAYING ...
New clock: GstSystemClock
ERROR: from element /GstPipeline:pipeline0/GstV4l2Src:v4l2src0: Failed to allocate required memory.
Additional debug info:
../sys/v4l2/gstv4l2src.c(659): gst_v4l2src_decide_allocation (): /GstPipeline:pipeline0/GstV4l2Src:v4l2src0:
Buffer pool activation failed
Execution ended after 0:00:00.004531494
Setting pipeline to NULL ...
ERROR: from element /GstPipeline:pipeline0/GstV4l2Src:v4l2src0: Internal data stream error.
Additional debug info:
../libs/gst/base/gstbasesrc.c(3127): gst_base_src_loop (): /GstPipeline:pipeline0/GstV4l2Src:v4l2src0:
streaming stopped, reason not-negotiated (-4)
Freeing pipeline ... -
RE: imx327 missing from raspberrypi_v4l2 ver 5.10.63-
I emailed 'xumm' and was told
"Please use veyecam2m.ko, this module support all 2M pixel VEYE-MIPI-* camera modules."
So I believe the installation line:-
sudo ./install_driver.sh [camera module]should use a [module name] of veyecam2m, which seems to install but as yet I don't have a fully working system motioneye or allsky system using it. I should find out soon...
-
RE: New change for camera on new raspberry OS.
Does the IMX327E camera work on Bullseye with libcamera i.e. not in legacy mode? If not, are you working on supporting it?
-
imx327 missing from raspberrypi_v4l2 ver 5.10.63-
The two 5.10.63 releases are missing the imx327 versions of the driver, would it be possible to release these files as well?
-
RE: veye_raspistill hangs up
With this fix it seems more reliable but it did crash again last night leaving a veye_raspistill Zombie. Short stack trace:-
Apr 11 23:31:21 allsky kernel: [22053.109872] WARNING: CPU: 3 PID: 20358 at drivers/firmware/raspberrypi.c:64 rpi_firmware_transaction+0xec/0x128
Apr 11 23:31:21 allsky kernel: [22053.109884] Firmware transaction timeout
Apr 11 23:31:21 allsky kernel: [22053.109895] Modules linked in: rpcsec_gss_krb5 8021q garp stp llc spidev brcmfmac brcmutil sha256_generic i2c_mux_pinctrl i2c_mux raspberrypi_hwmon cfg80211 rfkill bcm2835_codec(C) v4l2_mem2mem bcm2835_v4l2(C) bcm2835_isp(C) bcm2835_mmal_vchiq(C) videobuf2_vmalloc snd_bcm2835(C) videobuf2_dma_contig videobuf2_memops videobuf2_v4l2 videobuf2_common snd_pcm snd_timer i2c_bcm2835 snd spi_bcm2835 videodev mc vc_sm_cma(C) uio_pdrv_genirq uio fixed i2c_dev ip_tables x_tables ipv6
Apr 11 23:31:21 allsky kernel: [22053.110362] CPU: 3 PID: 20358 Comm: kworker/3:0 Tainted: G C 5.10.17-v7+ #1403
Apr 11 23:31:21 allsky kernel: [22053.110369] Hardware name: BCM2835
Apr 11 23:31:21 allsky kernel: [22053.110386] Workqueue: events dbs_work_handler -
RE: veye_raspistill hangs up
camera_buffer_callback() should always post via vcos_semaphore_post() even if there is a disk write error or disk full, so in the code where "complete = 1" is commented out it shouldn't be.
-
RE: veye_raspistill hangs up
Hi, Last night I had a failure just using the 32Gbyte SD card and there is 15G available I got this syslog trace.
Is there a way of sharing the whole file with you as it gets flagged as spam if I put much here?
Here is a short extract :Apr 7 04:15:58 allsky allsky.sh[661]: mmal: Splitter has 4 output port,you could use num 2,3 for extend
Apr 7 04:15:59 allsky allsky.sh[661]: Opening output file image.jpg
Apr 7 04:15:59 allsky allsky.sh[661]: mmal: camera_buffer_callback data len is 931322 file handle is ba5718
Apr 7 04:15:59 allsky allsky.sh[661]: mmal: camera_buffer_callback data len is 931074 file handle is ba5718
Apr 7 04:15:59 allsky allsky.sh[661]: mmal: Unable to write buffer to file - aborting 0 vs 931074
Apr 7 04:16:01 allsky kernel: [51999.788089] ------------[ cut here ]------------
Apr 7 04:16:01 allsky kernel: [51999.788135] WARNING: CPU: 2 PID: 8580 at drivers/firmware/raspberrypi.c:64 rpi_firmware_transaction+0xec/0x128
Apr 7 04:16:01 allsky kernel: [51999.788147] Firmware transaction timeout
Apr 7 04:16:01 allsky kernel: [51999.788158] Modules linked in: cmac bnep hci_uart btbcm bluetooth ecdh_generic ecc 8021q garp stp llc spidev brcmfmac brcmutil raspberrypi_hwmon sha256_generic i2c_mux_pinctrl i2c_mux cfg80211 bcm2835_codec(C) rfkill v4l2_mem2mem bcm2835_v4l2(C) videobuf2_vmalloc bcm2835_isp(C) bcm2835_mmal_vchiq(C) videobuf2_dma_contig videobuf2_memops videobuf2_v4l2 snd_bcm2835(C) videobuf2_common snd_pcm snd_timer videodev snd mc vc_sm_cma(C) spi_bcm2835 i2c_bcm2835 uio_pdrv_genirq uio fixed i2c_dev ip_tables x_tables ipv6 -
RE: veye_raspistill hangs up
I wonder if this could be anything to do with a file write error not be handled properly? In my ideal configuration the image file is would be written directly to a mounted NFS drive but currently it is written to SD card first and then copied across, so I can't see why this would affect the function of the veye_raspistill command completion as this appears to lock on an 'futex'.
The system seems to be more reliable if no NFS drive is mapped and copied to but I have insufficient evidence to be sure.
I have also experimented using a timelapse option for veye_rasptistill but this stopped after 9999 files had been written (even using %08 in the filename) but I could be wanting to write 30K to 40K files overnight.
I was expecting at least a 64K file limit and could have understood a 32K limit.
I need to try this again for repeatability and try with the official raspberry camera too. -
RE: veye_raspistill hangs up
@veye_xumm
It may be worse on the latest updated Buster release but I am currently working from the December 2020 release and it still happens.If it helps my code is at
https://github.com/bleara/allsky
This is still in development so some of the configuration is still to be fully done but it might help you with your replication of the problem, although it might also be a distraction. It needs the camera set in config.sh as CAMERA="RPi_VEYE" as auto will not work.
Some nights it will only run for an hour or two others like last night it ran for 12 hours.
I am now using a timeout like "timeout 10s veye_raspistill ...." but last night that hung too. -
veye_raspistill hangs up
I am working on an allsky camera using the Raspberry Pi with the imx327e module. I initially had this working for a couple of nights without error at the beginning of February which was fantastic and spurred me on. Recently though it invariably locks up after a few minutes or hours.
The allsky code is basically running the veye_raspistill code as fast as it can which is about every second as the exposure time is about 1 second.
When it fails I get
$ps -el | grep veye
0 S 1000 30964 30961 0 90 10 - 19941 futex_ ? 00:00:00 veye_raspistill$ps -aux | grep veye
pi 30961 0.0 0.0 1940 376 ? S 05:16 0:00 sh -c nice veye_raspistill --nopreview --output image.jpg --burst --mode 3 --quality 95
pi 30964 0.0 0.2 79764 2316 ? SNl 05:16 0:00 veye_raspistill --nopreview --output image.jpg --burst --mode 3 --quality 95I have established that this semaphore in main() does complete
vcos_semaphore_wait(&callback_data.complete_semaphore);but the main() function does not return.
I cannot see why this is locking up and whether it is unique to veye_raspistill() and not with the standard raspistill().
Has anyone else seen this issue and can offer any assistance?