> > > > > > 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.
Format Video Capture:
Width/Height : 3280/2464
Pixel Format : 'BGR4' (32-bit BGRA/X 8-8-8-8)
Field : None
Bytes per Line : 13184
Size Image : 32485376
Colorspace : SMPTE 170M
Transfer Function : Default (maps to Rec. 709)
YCbCr/HSV Encoding: Default (maps to ITU-R 601)
Quantization : Default (maps to Full Range)
Flags :
> 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
