Hi Peter On Fri, 11 Jan 2019 at 06:10, Peter Robinson <pbrobinson@xxxxxxxxx> wrote: > > Hi Stefan, > > > > > > I get difference results with 5.0-rc1 but neither of the above apps > > > > > work either, will follow up based on the rest of the thread there. > > > > > > > > > > > > > My first step with Raspbian is to enable the Camera interface which results into an appending of the following lines to config.txt: > > > > > > > > start_x=1 > > > > gpu_mem=128 > > > > > > > > AFAIK a smaller value for gpu_mem wont work. Please provide your settings which results in this crash. > > > > > > start_x=1 > > > gpu_mem=64 > > > > even with those settings i'm getting a picture in qv4l2 (v1.12.3) and no crash. > > > > According to dmesg i also have 64M reserved for CMA. How many do you have? > > I have 192Mb of CMA with LXDE, the vc4 driver uses CMA rather than the > gpu_mem via the firmware so that's what we set it to (and to 256Mb for > GNOME) As Stefan says, with Raspbian the default gpu_mem to use the camera is 128MB. The memory required depends on your use case as it includes the buffers for the output images. Checking on a running system, a V2 camera streaming 1080P YU12 with 3 V4L2 buffers is using 58MB of gpu_mem for the camera stack. H264 encode isntead of YU12 and it's around 63MB. With the vc4 driver loaded there's only a small number of other allocations left from the gpu_mem heap, so it's around the 70MB mark that will be the minimum to get the camera running. > > Does your qc4l2 make use of OpenGL (not in my case)? > > Yes, mine does. The crash with qv4l2 was only when I tried Cheese > first, if I reboot and just use qv4l2 it works fine when configured > with 128Mb without any crash. Which display driver are you using? Are > you using vc4 or the proprietary closed one? With vc4 using cma rather > than gpu_mem I wonder if we can reduce the amount needed there, but in > the interim I've at least now got picture output when using purely > qv4l2 and a reserve of 128Mb > > I'm not sure quite what gstreamer1/cheese is doing to cause that crash. Can you confirm what resolution and format they are using in your failure case? "v4l2-ctl -V" after they've been run will tell you. Your earlier request: > As a side note it would be a useful debug feature from a support PoV > if the following line could also note which firmware is loaded: > > [ 8.087691] raspberrypi-firmware soc:firmware: Attached to firmware > from 2019-01-09 20:07 > > Something like "attached to extended/reduced/whatecer firmware from XXXX-XX-XX" A very valid suggestion. I've made the firmware changes to advertise the build variant and firmware hash via the mailbox service, and that should be in the next firmware release. Pull request https://github.com/raspberrypi/linux/pull/2806 has added the Linux kernel changes to our kernel rpi-4.19.y branch. With the updated firmware, "vcgencmd version" will also report the build variant for you. Dave _______________________________________________ devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxx http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
