[meta-raspberrypi] Using the camera

[meta-raspberrypi] Using the camera

[Gary Thomas]

I have the raspberrypi camera (the one that plugs directly into
the board) running with Raspbian.  Now I'd like to have it working
with my Yocto based build.  I'm running the latest kernel which I
think matches the same kernel on Raspbian and I copied the /boot/config.txt
from my Raspbian disk to my Yocto image which I think should enable the
camera.  I've also checked the kernel cmdline which I think matches.

However, when I try to access the camera I get this error:
   root@raspberrypi:~# raspistill  -o /tmp/xx.jpg
   mmal: mmal_component_create_core: could not find component 'vc.ril.camera'
   mmal: Failed to create camera component
   mmal: main: Failed to create camera component
   mmal: Failed to run camera app. Please check for firmware updates

Any ideas what I need to do to get the camera working?

Thanks

-- 
------------------------------------------------------------
Gary Thomas                 |  Consulting for the
MLB Associates              |    Embedded world
------------------------------------------------------------

Re: [meta-raspberrypi] Using the camera

[Philipp Wagner]

Am 18.11.2013 21:37, Gary Thomas wrote:
> I have the raspberrypi camera (the one that plugs directly into
> the board) running with Raspbian.  Now I'd like to have it working
> with my Yocto based build.  I'm running the latest kernel which I
> think matches the same kernel on Raspbian and I copied the /boot/config.txt
> from my Raspbian disk to my Yocto image which I think should enable the
> camera.  I've also checked the kernel cmdline which I think matches.
> 
> However, when I try to access the camera I get this error:
>   root@raspberrypi:~# raspistill  -o /tmp/xx.jpg
>   mmal: mmal_component_create_core: could not find component
> 'vc.ril.camera'
>   mmal: Failed to create camera component
>   mmal: main: Failed to create camera component
>   mmal: Failed to run camera app. Please check for firmware updates
> 
> Any ideas what I need to do to get the camera working?

Did you also check that you are using the latest firmware (i.e. a quite
recent checkout of meta-raspberrypi)? I don't have the camera myself, so
I've never tested this feature.

Philipp

Re: [meta-raspberrypi] Using the camera

[Gary Thomas]

On 2013-11-18 14:10, Philipp Wagner wrote:
> Am 18.11.2013 21:37, Gary Thomas wrote:
>> I have the raspberrypi camera (the one that plugs directly into
>> the board) running with Raspbian.  Now I'd like to have it working
>> with my Yocto based build.  I'm running the latest kernel which I
>> think matches the same kernel on Raspbian and I copied the /boot/config.txt
>> from my Raspbian disk to my Yocto image which I think should enable the
>> camera.  I've also checked the kernel cmdline which I think matches.
>>
>> However, when I try to access the camera I get this error:
>>    root@raspberrypi:~# raspistill  -o /tmp/xx.jpg
>>    mmal: mmal_component_create_core: could not find component
>> 'vc.ril.camera'
>>    mmal: Failed to create camera component
>>    mmal: main: Failed to create camera component
>>    mmal: Failed to run camera app. Please check for firmware updates
>>
>> Any ideas what I need to do to get the camera working?
>
> Did you also check that you are using the latest firmware (i.e. a quite
> recent checkout of meta-raspberrypi)? I don't have the camera myself, so
> I've never tested this feature.

I do have the very latest version of meta-raspberrypi, with the 20131113
version of the firmware (bcm bootfiles).

-- 
------------------------------------------------------------
Gary Thomas                 |  Consulting for the
MLB Associates              |    Embedded world
------------------------------------------------------------

[meta-raspberrypi] Using the camera

[Edward Vidal]

[-- Attachment #1: Type: text/plain, Size: 871 bytes --]

Hello,
To get my C920 camera to work with the zedboard
I needed to add v4l-utils and then I need several modules that I add to 3.6
kernel
https://github.com/Digilent/linux-digilent.git
    3.6.0-digilent-13.01-00002-g06b3889/
    ├── kernel
    │   └── drivers
    │       ├── media
    │       │   └── video
    │       │       ├── gspca
    │       │       │   └── gspca_main.ko
    │       │       ├── uvc
    │       │       │   └── uvcvideo.ko
    │       │       ├── v4l2-common.ko
    │       │       ├── v4l2-int-device.ko
    │       │       ├── videobuf2-core.ko
    │       │       ├── videobuf2-memops.ko
    │       │       ├── videobuf2-vmalloc.ko
    │       │       └── videodev.ko
Hope this helps

[-- Attachment #2: Type: text/html, Size: 1234 bytes --]

Re: [meta-raspberrypi] Using the camera

[Gary Thomas]

On 2013-11-19 09:18, Edward Vidal wrote:
> Hello,
> To get my C920 camera to work with the zedboard
> I needed to add v4l-utils and then I need several modules that I add to 3.6 kernel
> https://github.com/Digilent/linux-digilent.git
>      3.6.0-digilent-13.01-00002-g06b3889/
>      ├── kernel
>      │   └── drivers
>      │       ├── media
>      │       │   └── video
>      │       │       ├── gspca
>      │       │       │   └── gspca_main.ko
>      │       │       ├── uvc
>      │       │       │   └── uvcvideo.ko
>      │       │       ├── v4l2-common.ko
>      │       │       ├── v4l2-int-device.ko
>      │       │       ├── videobuf2-core.ko
>      │       │       ├── videobuf2-memops.ko
>      │       │       ├── videobuf2-vmalloc.ko
>      │       │       └── videodev.ko
> Hope this helps

Thanks for the reply, but this is not what I'm looking for.  The
camera module I'm using is directly connected to the RaspberryPi
via the CSI interface, not USB like your C920 and it uses very
different drivers to access.

-- 
------------------------------------------------------------
Gary Thomas                 |  Consulting for the
MLB Associates              |    Embedded world
------------------------------------------------------------

Re: [meta-raspberrypi] Using the camera

[Andrei Gherzan]

[-- Attachment #1: Type: text/plain, Size: 1429 bytes --]

On Tue, Nov 19, 2013 at 6:22 PM, Gary Thomas <gary@mlbassoc.com> wrote:

> On 2013-11-19 09:18, Edward Vidal wrote:
>
>> Hello,
>> To get my C920 camera to work with the zedboard
>> I needed to add v4l-utils and then I need several modules that I add to
>> 3.6 kernel
>> https://github.com/Digilent/linux-digilent.git
>>      3.6.0-digilent-13.01-00002-g06b3889/
>>      ├── kernel
>>      │   └── drivers
>>      │       ├── media
>>      │       │   └── video
>>      │       │       ├── gspca
>>      │       │       │   └── gspca_main.ko
>>      │       │       ├── uvc
>>      │       │       │   └── uvcvideo.ko
>>      │       │       ├── v4l2-common.ko
>>      │       │       ├── v4l2-int-device.ko
>>      │       │       ├── videobuf2-core.ko
>>      │       │       ├── videobuf2-memops.ko
>>      │       │       ├── videobuf2-vmalloc.ko
>>      │       │       └── videodev.ko
>> Hope this helps
>>
>
> Thanks for the reply, but this is not what I'm looking for.  The
> camera module I'm using is directly connected to the RaspberryPi
> via the CSI interface, not USB like your C920 and it uses very
> different drivers to access.


Alexandru was working on this (camera support). Maybe he can help you with
this. Adding him in the loop.

ag

[-- Attachment #2: Type: text/html, Size: 2170 bytes --]

Re: [meta-raspberrypi] Using the camera

[jan alexandru vaduva]

[-- Attachment #1: Type: text/plain, Size: 2272 bytes --]

Hello guys, I am trying to enable the functionality for the camera.
I am trying to solve the following problem:
    mmal: mmal_vc_component_create: failed to create component
'vc.ril.camera'
    mmal: mmal_component_create_core: could not create component
'vc.ril.camera'
    mmal: Failed to create camera component
Updated to the latest firmware, enabled the functionality into config.txt
but the problem continues.

The problem seems to be the rootfs constructions. The right libraries are
there but the name of the component that the function needs is not there. I
assume it will take me some time to solve it, but when the time permits I
will try to wrap this thing up.


Regards,
Alex


On Tue, Dec 3, 2013 at 11:54 PM, Andrei Gherzan <andrei@gherzan.ro> wrote:

>
>
>
> On Tue, Nov 19, 2013 at 6:22 PM, Gary Thomas <gary@mlbassoc.com> wrote:
>
>> On 2013-11-19 09:18, Edward Vidal wrote:
>>
>>> Hello,
>>> To get my C920 camera to work with the zedboard
>>> I needed to add v4l-utils and then I need several modules that I add to
>>> 3.6 kernel
>>> https://github.com/Digilent/linux-digilent.git
>>>      3.6.0-digilent-13.01-00002-g06b3889/
>>>      ├── kernel
>>>      │   └── drivers
>>>      │       ├── media
>>>      │       │   └── video
>>>      │       │       ├── gspca
>>>      │       │       │   └── gspca_main.ko
>>>      │       │       ├── uvc
>>>      │       │       │   └── uvcvideo.ko
>>>      │       │       ├── v4l2-common.ko
>>>      │       │       ├── v4l2-int-device.ko
>>>      │       │       ├── videobuf2-core.ko
>>>      │       │       ├── videobuf2-memops.ko
>>>      │       │       ├── videobuf2-vmalloc.ko
>>>      │       │       └── videodev.ko
>>> Hope this helps
>>>
>>
>> Thanks for the reply, but this is not what I'm looking for.  The
>> camera module I'm using is directly connected to the RaspberryPi
>> via the CSI interface, not USB like your C920 and it uses very
>> different drivers to access.
>
>
> Alexandru was working on this (camera support). Maybe he can help you with
> this. Adding him in the loop.
>
> ag
>

[-- Attachment #2: Type: text/html, Size: 3382 bytes --]

Re: [meta-raspberrypi] Using the camera

[Alex J Lennon]

On 03/12/2013 22:13, jan alexandru vaduva wrote:
> Hello guys, I am trying to enable the functionality for the camera.
> I am trying to solve the following problem:
>     mmal: mmal_vc_component_create: failed to create component
> 'vc.ril.camera'
>     mmal: mmal_component_create_core: could not create component
> 'vc.ril.camera'
>     mmal: Failed to create camera component
> Updated to the latest firmware, enabled the functionality into
> config.txt but the problem continues.
>
> The problem seems to be the rootfs constructions. The right libraries
> are there but the name of the component that the function needs is not
> there. I assume it will take me some time to solve it, but when the
> time permits I will try to wrap this thing up.
>

Hi Alex,

Did manage to get to the bottom of this? I'm seeing the same thing with
raspivid / raspistill (although mjpg-streamer works fine).

mmal: mmal_vc_component_create: failed to create component 'vc.ril.camera'

- My checkout of meta-raspberrypi is current on f3a8693f (Andrei
Gherzan, May 8th) so I don't believe this is an out of date firmware
issue (?)

- I tried disabling the preview screen in case there was some kind of
video overlay issue

e.g. raspivid -n -w 640 -h 480 -fps 5

- I'm not seeing ENOMEM as the error and my GPU_MEM = "128" which I've
checked translates into the correct setting in config.txt in the boot
partition

- I read that it could possibly be related to current consumption and
the polyfuse, so I'm now powering from a bench PSU direct into the P1
header, and current limiting isn't the issue.

- I've just put a downloaded and put copy of Raspbian on there.  Running
raspivid seems to work fine (preview screen etc. etc.)

e.g. raspivid -w 640 -h 480 -fps 5

- Looking at the raspivid source it seems a fairly straightforward setup
call is failing early on, leading me to think something is missing as
you suggest?

https://github.com/raspberrypi/userland/blob/677f3cc646c8847822998c6409a748c900897076/host_applications/linux/apps/raspicam/RaspiVid.c

Thanks,

Alex

Re: [meta-raspberrypi] Using the camera

[Alexandru Vaduva]

[-- Attachment #1: Type: text/plain, Size: 2851 bytes --]

Hello,

Sorry for my late response, I put on pause the investigation with this bug.
Hope to return to it next month (or at least after 13 June).
Right now in my head there are more questions then answers regarding
this bug, so I cannot really help.A quick suggestion would be to inspect the config.txt for raspbian for example 
and investigate the differences. 
Also try GPU_MEM = "256" just to make a confirmation of my assumption that 
something is missing.


Thanks,
Alex



On Sunday, May 25, 2014 2:37 PM, Alex J Lennon <ajlennon@dynamicdevices.co.uk> wrote:
 



On 03/12/2013 22:13, jan alexandru vaduva wrote:
> Hello guys, I am trying to enable the functionality for the camera.
> I am trying to solve the following problem:
>     mmal: mmal_vc_component_create: failed to create component
> 'vc.ril.camera'
>     mmal: mmal_component_create_core: could not create component
> 'vc.ril.camera'
>     mmal: Failed to create camera component
> Updated to the latest firmware, enabled the functionality into
> config.txt but the problem continues.
>
> The problem seems to be the rootfs constructions. The right libraries
> are there but the name of the component that the function needs is not
> there. I assume it will take me some time to solve it, but when the
> time permits I will try to wrap this thing up.
>

Hi Alex,

Did manage to get to the bottom of this? I'm seeing the same thing with
raspivid / raspistill (although mjpg-streamer works fine).

mmal: mmal_vc_component_create: failed to create component 'vc.ril.camera'

- My checkout of meta-raspberrypi is current on f3a8693f (Andrei
Gherzan, May 8th) so I don't believe this is an out of date firmware
issue (?)

- I tried disabling the preview screen in case there was some kind of
video overlay issue

e.g. raspivid -n -w 640 -h 480 -fps 5

- I'm not seeing ENOMEM as the error and my GPU_MEM = "128" which I've
checked translates into the correct setting in config.txt in the boot
partition

- I read that it could possibly be related to current consumption and
the polyfuse, so I'm now powering from a bench PSU direct into the P1
header, and current limiting isn't the issue.

- I've just put a downloaded and put copy of Raspbian on there.  Running
raspivid seems to work fine (preview screen etc. etc.)

e.g. raspivid -w 640 -h 480 -fps 5

- Looking at the raspivid source it seems a fairly straightforward setup
call is failing early on, leading me to think something is missing as
you suggest?

https://github.com/raspberrypi/userland/blob/677f3cc646c8847822998c6409a748c900897076/host_applications/linux/apps/raspicam/RaspiVid.c

Thanks,

Alex


-- 
_______________________________________________
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

[-- Attachment #2: Type: text/html, Size: 6425 bytes --]

Re: [meta-raspberrypi] Using the camera

[Alex J Lennon]

[-- Attachment #1: Type: text/plain, Size: 684 bytes --]


On 25/05/2014 21:51, Alexandru Vaduva wrote:
> Hello,
>
> Sorry for my late response, I put on pause the investigation with this
> bug.
> Hope to return to it next month (or at least after 13 June).
> Right now in my head there are more questions then answers regarding
> this bug, so I cannot really help.
> A quick suggestion would be to inspect the config.txt for raspbian for
> example
> and investigate the differences.
> Also try GPU_MEM = "256" just to make a confirmation of my assumption
> that
> something is missing.
>

Thanks Alex. I will try that. I'm going to have another look today and
see if I can get to the bottom of it

Best Regards,

Alex

[-- Attachment #2: Type: text/html, Size: 2770 bytes --]

Re: [meta-raspberrypi] Using the camera

[Alex J Lennon]

[-- Attachment #1: Type: text/plain, Size: 2805 bytes --]


On 26/05/2014 11:39, Alex J Lennon wrote:
>
> On 25/05/2014 21:51, Alexandru Vaduva wrote:
>> Hello,
>>
>> Sorry for my late response, I put on pause the investigation with
>> this bug.
>> Hope to return to it next month (or at least after 13 June).
>> Right now in my head there are more questions then answers regarding
>> this bug, so I cannot really help.
>> A quick suggestion would be to inspect the config.txt for raspbian
>> for example
>> and investigate the differences.
>> Also try GPU_MEM = "256" just to make a confirmation of my assumption
>> that
>> something is missing.
>>
>
> Thanks Alex. I will try that. I'm going to have another look today and
> see if I can get to the bottom of it

Hi Alex,

I've been taking a look at various things. I don't have a solution
though unfortunately at present

- The GPU_MEM = "256" doesn't help unfortunately

- The raspivid call is failing here, when it tries to instantiate a
camera component

https://github.com/raspberrypi/userland/blob/master/host_applications/linux/apps/raspicam/RaspiVid.c#L1674

calls,

https://github.com/raspberrypi/userland/blob/master/interface/mmal/core/mmal_component.c#L708

This seems to be because there is no supplier registered for the camera
component. Why I am not sure...

...

As I was investigating this I came across OpenMAX Bellagio which seems
to provide an intermediary registry of OpenMax components.

I'm not sure whether this relates to the RaspiVid issue but I believe it
does relate to an issue I am seeing when I try to run a Gstreamer pipeline

gst-launch-0.10 -v videotestsrc pattern=smpte !
'video/x-raw-rgb,width=1920,height=1080' ! omx_h264enc ! rpth264pay !
udpsink=192.168.0.13 port=5000
OMX-Component not found with current ST static component loader.

Now apparently we are supposed to have run omxregister-bellagio which
registers up components.

(omxregister-bellagio is provided by the
poky/meta/recipes-multimedia/libomxil recipe.)

On Raspbian there are a set of components registered with bellagio, and
provided by individual libomx-foo packages.
(e.g. libomxvideosrc.so, libomxfbdev.so, libomxclocksrc.so,
libomxcamera.so, libomxaudio_effects.so, libomxxvideo.so)

ref:
http://www.nielsmayer.com/bin/view/Raspberry+Pi/Notes+on+Qt5,+Multimedia,+OpenMax+Acceleration,+5.1+Audio

These are missing on my Yocto Poky RPi image.

It looks as though at some time in the past these components may have
been present in the core bellagio build, but then at some point they
were broken out into separate components tarballs.

e.g. http://sourceforge.net/projects/omxil/files/components/

I can't see recipes for these anywhere so I am wondering if they need to
be added in...

Cheers,

Alex


Looking at



[-- Attachment #2: Type: text/html, Size: 6099 bytes --]

Re: [meta-raspberrypi] Using the camera

[Alexandru Vaduva]

[-- Attachment #1: Type: text/plain, Size: 3605 bytes --]

I do not believe the mmal_component is missing from the rootfs or it is not
enabled somehow.
I hate to mention this but it may have something to do with the the
functionality of the component.
Try this: https://github.com/raspberrypi/linux/issues/435
Also something like strace or even 'sudo vcdbg syms | grep -i cam' would be
useful if available of
the rootfs.

Sorry for this type of interaction. I am really busy with some other
project.
If nothing works we could use OpenMax as you suggested to interact with the
camera, but I still hope
this problem can be fixed.


Alex


On Mon, May 26, 2014 at 8:56 PM, Alex J Lennon <
ajlennon@dynamicdevices.co.uk> wrote:

>
> On 26/05/2014 11:39, Alex J Lennon wrote:
>
>
> On 25/05/2014 21:51, Alexandru Vaduva wrote:
>
>  Hello,
>
>  Sorry for my late response, I put on pause the investigation with this
> bug.
> Hope to return to it next month (or at least after 13 June).
> Right now in my head there are more questions then answers regarding
> this bug, so I cannot really help.
> A quick suggestion would be to inspect the config.txt for raspbian for
> example
> and investigate the differences.
> Also try GPU_MEM = "256" just to make a confirmation of my assumption that
> something is missing.
>
>
> Thanks Alex. I will try that. I'm going to have another look today and see
> if I can get to the bottom of it
>
>
> Hi Alex,
>
> I've been taking a look at various things. I don't have a solution though
> unfortunately at present
>
> - The GPU_MEM = "256" doesn't help unfortunately
>
> - The raspivid call is failing here, when it tries to instantiate a camera
> component
>
>
> https://github.com/raspberrypi/userland/blob/master/host_applications/linux/apps/raspicam/RaspiVid.c#L1674
>
> calls,
>
>
> https://github.com/raspberrypi/userland/blob/master/interface/mmal/core/mmal_component.c#L708
>
> This seems to be because there is no supplier registered for the camera
> component. Why I am not sure...
>
> ...
>
> As I was investigating this I came across OpenMAX Bellagio which seems to
> provide an intermediary registry of OpenMax components.
>
> I'm not sure whether this relates to the RaspiVid issue but I believe it
> does relate to an issue I am seeing when I try to run a Gstreamer pipeline
>
> gst-launch-0.10 -v videotestsrc pattern=smpte !
> 'video/x-raw-rgb,width=1920,height=1080' ! omx_h264enc ! rpth264pay !
> udpsink=192.168.0.13 port=5000
> OMX-Component not found with current ST static component loader.
>
> Now apparently we are supposed to have run omxregister-bellagio which
> registers up components.
>
> (omxregister-bellagio is provided by the
> poky/meta/recipes-multimedia/libomxil recipe.)
>
> On Raspbian there are a set of components registered with bellagio, and
> provided by individual libomx-foo packages.
> (e.g. libomxvideosrc.so, libomxfbdev.so, libomxclocksrc.so,
> libomxcamera.so, libomxaudio_effects.so, libomxxvideo.so)
>
> ref:
> http://www.nielsmayer.com/bin/view/Raspberry+Pi/Notes+on+Qt5,+Multimedia,+OpenMax+Acceleration,+5.1+Audio
>
> These are missing on my Yocto Poky RPi image.
>
> It looks as though at some time in the past these components may have been
> present in the core bellagio build, but then at some point they were broken
> out into separate components tarballs.
>
> e.g. http://sourceforge.net/projects/omxil/files/components/
>
> I can't see recipes for these anywhere so I am wondering if they need to
> be added in...
>
> Cheers,
>
> Alex
>
>
> Looking at
>
>
>

[-- Attachment #2: Type: text/html, Size: 6468 bytes --]

Re: [meta-raspberrypi] Using the camera

[Alex J Lennon]

[-- Attachment #1: Type: text/plain, Size: 1412 bytes --]


On 26/05/2014 19:24, Alexandru Vaduva wrote:
> I do not believe the mmal_component is missing from the rootfs or it
> is not enabled somehow.
> I hate to mention this but it may have something to do with the the
> functionality of the component.
> Try this: https://github.com/raspberrypi/linux/issues/435
> Also something like strace or even |'sudo vcdbg syms | grep -i cam'
> |would be useful if available of
> the rootfs.
>  

That's interesting. I wonder if that is related to the issue I found
with w1-gpio the other day?

w1-gpio is given GPIO0 as a pullup pin by the BSP so it takes control of
it for that purpose, possibly breaking the I2C bus as mentioned in your link

Issue: https://github.com/raspberrypi/linux/issues/601

My fix is here: https://github.com/raspberrypi/linux/pull/602

I'm not loading the w1-gpio at present though so I don't believe it is
causing the problem

(In fact - at any point I can run mjpg-streamer and that will work! So I
know the camera is OK...)

> Sorry for this type of interaction. I am really busy with some other
> project.
> If nothing works we could use OpenMax as you suggested to interact
> with the camera, but I still hope
> this problem can be fixed.
>

No problem Alex. I appreciate any thoughts at all :)

I think next I'm going to have a look at gstreamer1.0-omx and see where
that gets me...

Cheers,

Alex


[-- Attachment #2: Type: text/html, Size: 3019 bytes --]

Re: [meta-raspberrypi] Using the camera

[Alexandru Vaduva]

[-- Attachment #1: Type: text/plain, Size: 1884 bytes --]

It`s really hard to just offer impressions or suggestion.
Also I agree with the fact that the camera is ok cause I also tested it
with raspbian. No problems there.
But never the less I hope to keep me posted on any progress and
observations.
When I will have the time I will try some things of my own.

Alex


On Mon, May 26, 2014 at 9:34 PM, Alex J Lennon <
ajlennon@dynamicdevices.co.uk> wrote:

>
> On 26/05/2014 19:24, Alexandru Vaduva wrote:
>
>   I do not believe the mmal_component is missing from the rootfs or it is
> not enabled somehow.
>  I hate to mention this but it may have something to do with the the
> functionality of the component.
>  Try this: https://github.com/raspberrypi/linux/issues/435
>  Also something like strace or even 'sudo vcdbg syms | grep -i cam' would
> be useful if available of
> the rootfs.
>
>
>
> That's interesting. I wonder if that is related to the issue I found with
> w1-gpio the other day?
>
> w1-gpio is given GPIO0 as a pullup pin by the BSP so it takes control of
> it for that purpose, possibly breaking the I2C bus as mentioned in your link
>
> Issue: https://github.com/raspberrypi/linux/issues/601
>
> My fix is here: https://github.com/raspberrypi/linux/pull/602
>
> I'm not loading the w1-gpio at present though so I don't believe it is
> causing the problem
>
> (In fact - at any point I can run mjpg-streamer and that will work! So I
> know the camera is OK...)
>
>
>  Sorry for this type of interaction. I am really busy with some other
> project.
>  If nothing works we could use OpenMax as you suggested to interact with
> the camera, but I still hope
>  this problem can be fixed.
>
>
> No problem Alex. I appreciate any thoughts at all :)
>
> I think next I'm going to have a look at gstreamer1.0-omx and see where
> that gets me...
>
> Cheers,
>
> Alex
>
>

[-- Attachment #2: Type: text/html, Size: 3475 bytes --]

Re: [meta-raspberrypi] Using the camera

[Alex J Lennon]

On 26/05/2014 19:40, Alexandru Vaduva wrote:
> It`s really hard to just offer impressions or suggestion.
> Also I agree with the fact that the camera is ok cause I also tested
> it with raspbian. No problems there.
> But never the less I hope to keep me posted on any progress and
> observations.
> When I will have the time I will try some things of my own.
>
> Alex

I've made a certain amount of progress with this Alex.

1) I've been comparing Raspbian with a Yocto meta-raspberrypi armhf
build, as raspivid works for me with Raspbian, but not with my
meta-raspberrypi poky build.

     To cut a long story short the raspivid in Raspian is v1.3.9 and it
comes from raspiberrypi/firmware which as you know is the binary-only
release

     If I copy only the raspivid executable from the Raspbian
installation over to the Yocto installation then raspivid runs up ok,
shows the cam onscreen and so forth.
     (so shared libs, config and so forth all would seem to be fine)

     I tried building the same v1.3.9 version of raspivid from the
userland repository, but I get the same error as before,

root@raspberrypi:~# raspivid -o test
mmal: mmal_component_create_core: could not find component 'vc.ril.camera'
mmal: Failed to create camera component
mmal: main: Failed to create camera component
mmal: Failed to run camera app. Please check for firmware updates

     So it looks to me as though there's something different between the
firmware binary release and the more recent open-sourced userland code

    I can show that by just doing my armhf build then pulling down the
binary, which runs up,
  
   
https://github.com/raspberrypi/firmware/raw/master/hardfp/opt/vc/bin/raspivid

    Looking back through the meta-raspberrypi commit logs it looks as
though userland replaced vc-graphics-hardfp back at 33d2e1d7

-PREFERRED_PROVIDER_virtual/egl ?= "vc-graphics-hardfp"
-PREFERRED_PROVIDER_virtual/libgles2 ?= "vc-graphics-hardfp"
+PREFERRED_PROVIDER_virtual/egl ?= "userland"
+PREFERRED_PROVIDER_virtual/libgles2 ?= "userland"

    If I build with vc-graphics-hardfp I get a raspivid that runs up

2) I was wrong about the Bellagio support. Instead there are a set of
library mappings in /etc/xdg/gstomx.conf
  These need to be modified to point to libopenmaxil.so not the bellagio
library

e.g.

[omxh264enc]
type-name=GstOMXH264Enc
core-name=/opt/vc/lib/libopenmaxil.so
component-name=OMX.broadcom.video_encode
rank=256
in-port-index=200
out-port-index=201
hacks=no-component-role
 
  With this in place we can do some hardware encoding of h.264 video
with gstreamer-1.0, both to file and via RTP over UDP.

3) I believe gstreamer1.0-omx may need to be configured to target RPi
not Bellagio

e.g. GSTREAMER_1_0_OMX_TARGET="rpi"

https://github.com/openembedded/oe-core/blob/master/meta/recipes-multimedia/gstreamer/gstreamer1.0-omx.inc

There's also a patch needed in gstreamer1.0-omx.inc as the RPi headers
are as incomplete as the Bellagio headers .

4) There are some issues using the v4l2 driver with gstreamer. It seems
to block on polling

As v4l2src doesn't currently support h.264 for Gstreamer1.0 inherently
(my reading is that there's some uvch264_src code for this in
development) I'm concentrating on getting raspivid working for now and
then piping into an Gstreamer1.0 fdsrc which works for me on Raspbian,
and I'll see what the overhead is with that approach.

Cheers,

Alex

Re: [meta-raspberrypi] Using the camera

[Alexandru Vaduva]

[-- Attachment #1: Type: text/plain, Size: 4291 bytes --]

This are indeed some very good news Alex J Lennon.
I have some questions, but those maybe can be answered by the
maintainers of the meta-raspberrypi layer:
Why was this change done?
     -PREFERRED_PROVIDER_virtual/egl ?= "vc-graphics-hardfp"
     -PREFERRED_PROVIDER_virtual/libgles2 ?= "vc-graphics-hardfp"
     +PREFERRED_PROVIDER_virtual/egl ?= "userland"
     +PREFERRED_PROVIDER_virtual/libgles2 ?= "userland"
How it may affect other applications?
Andrei: Do you have any input on this?


Thanks,
Alex





On Mon, Jun 2, 2014 at 12:07 AM, Alex J Lennon <
ajlennon@dynamicdevices.co.uk> wrote:

>
> On 26/05/2014 19:40, Alexandru Vaduva wrote:
> > It`s really hard to just offer impressions or suggestion.
> > Also I agree with the fact that the camera is ok cause I also tested
> > it with raspbian. No problems there.
> > But never the less I hope to keep me posted on any progress and
> > observations.
> > When I will have the time I will try some things of my own.
> >
> > Alex
>
> I've made a certain amount of progress with this Alex.
>
> 1) I've been comparing Raspbian with a Yocto meta-raspberrypi armhf
> build, as raspivid works for me with Raspbian, but not with my
> meta-raspberrypi poky build.
>
>      To cut a long story short the raspivid in Raspian is v1.3.9 and it
> comes from raspiberrypi/firmware which as you know is the binary-only
> release
>
>      If I copy only the raspivid executable from the Raspbian
> installation over to the Yocto installation then raspivid runs up ok,
> shows the cam onscreen and so forth.
>      (so shared libs, config and so forth all would seem to be fine)
>
>      I tried building the same v1.3.9 version of raspivid from the
> userland repository, but I get the same error as before,
>
> root@raspberrypi:~# raspivid -o test
> mmal: mmal_component_create_core: could not find component 'vc.ril.camera'
> mmal: Failed to create camera component
> mmal: main: Failed to create camera component
> mmal: Failed to run camera app. Please check for firmware updates
>
>      So it looks to me as though there's something different between the
> firmware binary release and the more recent open-sourced userland code
>
>     I can show that by just doing my armhf build then pulling down the
> binary, which runs up,
>
>
>
> https://github.com/raspberrypi/firmware/raw/master/hardfp/opt/vc/bin/raspivid
>
>     Looking back through the meta-raspberrypi commit logs it looks as
> though userland replaced vc-graphics-hardfp back at 33d2e1d7
>
> -PREFERRED_PROVIDER_virtual/egl ?= "vc-graphics-hardfp"
> -PREFERRED_PROVIDER_virtual/libgles2 ?= "vc-graphics-hardfp"
> +PREFERRED_PROVIDER_virtual/egl ?= "userland"
> +PREFERRED_PROVIDER_virtual/libgles2 ?= "userland"
>
>     If I build with vc-graphics-hardfp I get a raspivid that runs up
>
> 2) I was wrong about the Bellagio support. Instead there are a set of
> library mappings in /etc/xdg/gstomx.conf
>   These need to be modified to point to libopenmaxil.so not the bellagio
> library
>
> e.g.
>
> [omxh264enc]
> type-name=GstOMXH264Enc
> core-name=/opt/vc/lib/libopenmaxil.so
> component-name=OMX.broadcom.video_encode
> rank=256
> in-port-index=200
> out-port-index=201
> hacks=no-component-role
>
>   With this in place we can do some hardware encoding of h.264 video
> with gstreamer-1.0, both to file and via RTP over UDP.
>
> 3) I believe gstreamer1.0-omx may need to be configured to target RPi
> not Bellagio
>
> e.g. GSTREAMER_1_0_OMX_TARGET="rpi"
>
>
> https://github.com/openembedded/oe-core/blob/master/meta/recipes-multimedia/gstreamer/gstreamer1.0-omx.inc
>
> There's also a patch needed in gstreamer1.0-omx.inc as the RPi headers
> are as incomplete as the Bellagio headers .
>
> 4) There are some issues using the v4l2 driver with gstreamer. It seems
> to block on polling
>
> As v4l2src doesn't currently support h.264 for Gstreamer1.0 inherently
> (my reading is that there's some uvch264_src code for this in
> development) I'm concentrating on getting raspivid working for now and
> then piping into an Gstreamer1.0 fdsrc which works for me on Raspbian,
> and I'll see what the overhead is with that approach.
>
> Cheers,
>
> Alex
>
>

[-- Attachment #2: Type: text/html, Size: 5534 bytes --]

Re: [meta-raspberrypi] Using the camera

[Alex J Lennon]

[-- Attachment #1: Type: text/plain, Size: 6191 bytes --]


On 01/06/2014 22:22, Alexandru Vaduva wrote:
> This are indeed some very good news Alex J Lennon.
> I have some questions, but those maybe can be answered by the
> maintainers of the meta-raspberrypi layer:
> Why was this change done?
>      -PREFERRED_PROVIDER_virtual/egl ?= "vc-graphics-hardfp"
>      -PREFERRED_PROVIDER_virtual/libgles2 ?= "vc-graphics-hardfp"
>      +PREFERRED_PROVIDER_virtual/egl ?= "userland"
>      +PREFERRED_PROVIDER_virtual/libgles2 ?= "userland"
> How it may affect other applications?
> Andrei: Do you have any input on this?
>
>

The maintainers would know better than I, but if I had to guess, it
might have been to replace the binary
only proprietary licensed vc-graphics with the replacement userland
source code when Broadcom opened it,

i.e. http://www.raspberrypi.org/open-source-arm-userspace/

I'm going to have a go at compiling userland on Raspbian to see if it
might be a cross-compilation issue.

Cheers,

Alex

> Thanks,
> Alex
>
>
>
>
>
> On Mon, Jun 2, 2014 at 12:07 AM, Alex J Lennon
> <ajlennon@dynamicdevices.co.uk <mailto:ajlennon@dynamicdevices.co.uk>>
> wrote:
>
>
>     On 26/05/2014 19:40, Alexandru Vaduva wrote:
>     > It`s really hard to just offer impressions or suggestion.
>     > Also I agree with the fact that the camera is ok cause I also tested
>     > it with raspbian. No problems there.
>     > But never the less I hope to keep me posted on any progress and
>     > observations.
>     > When I will have the time I will try some things of my own.
>     >
>     > Alex
>
>     I've made a certain amount of progress with this Alex.
>
>     1) I've been comparing Raspbian with a Yocto meta-raspberrypi armhf
>     build, as raspivid works for me with Raspbian, but not with my
>     meta-raspberrypi poky build.
>
>          To cut a long story short the raspivid in Raspian is v1.3.9
>     and it
>     comes from raspiberrypi/firmware which as you know is the binary-only
>     release
>
>          If I copy only the raspivid executable from the Raspbian
>     installation over to the Yocto installation then raspivid runs up ok,
>     shows the cam onscreen and so forth.
>          (so shared libs, config and so forth all would seem to be fine)
>
>          I tried building the same v1.3.9 version of raspivid from the
>     userland repository, but I get the same error as before,
>
>     root@raspberrypi:~# raspivid -o test
>     mmal: mmal_component_create_core: could not find component
>     'vc.ril.camera'
>     mmal: Failed to create camera component
>     mmal: main: Failed to create camera component
>     mmal: Failed to run camera app. Please check for firmware updates
>
>          So it looks to me as though there's something different
>     between the
>     firmware binary release and the more recent open-sourced userland code
>
>         I can show that by just doing my armhf build then pulling down the
>     binary, which runs up,
>
>
>     https://github.com/raspberrypi/firmware/raw/master/hardfp/opt/vc/bin/raspivid
>
>         Looking back through the meta-raspberrypi commit logs it looks as
>     though userland replaced vc-graphics-hardfp back at 33d2e1d7
>
>     -PREFERRED_PROVIDER_virtual/egl ?= "vc-graphics-hardfp"
>     -PREFERRED_PROVIDER_virtual/libgles2 ?= "vc-graphics-hardfp"
>     +PREFERRED_PROVIDER_virtual/egl ?= "userland"
>     +PREFERRED_PROVIDER_virtual/libgles2 ?= "userland"
>
>         If I build with vc-graphics-hardfp I get a raspivid that runs up
>
>     2) I was wrong about the Bellagio support. Instead there are a set of
>     library mappings in /etc/xdg/gstomx.conf
>       These need to be modified to point to libopenmaxil.so not the
>     bellagio
>     library
>
>     e.g.
>
>     [omxh264enc]
>     type-name=GstOMXH264Enc
>     core-name=/opt/vc/lib/libopenmaxil.so
>     component-name=OMX.broadcom.video_encode
>     rank=256
>     in-port-index=200
>     out-port-index=201
>     hacks=no-component-role
>
>       With this in place we can do some hardware encoding of h.264 video
>     with gstreamer-1.0, both to file and via RTP over UDP.
>
>     3) I believe gstreamer1.0-omx may need to be configured to target RPi
>     not Bellagio
>
>     e.g. GSTREAMER_1_0_OMX_TARGET="rpi"
>
>     https://github.com/openembedded/oe-core/blob/master/meta/recipes-multimedia/gstreamer/gstreamer1.0-omx.inc
>
>     There's also a patch needed in gstreamer1.0-omx.inc as the RPi headers
>     are as incomplete as the Bellagio headers .
>
>     4) There are some issues using the v4l2 driver with gstreamer. It
>     seems
>     to block on polling
>
>     As v4l2src doesn't currently support h.264 for Gstreamer1.0 inherently
>     (my reading is that there's some uvch264_src code for this in
>     development) I'm concentrating on getting raspivid working for now and
>     then piping into an Gstreamer1.0 fdsrc which works for me on Raspbian,
>     and I'll see what the overhead is with that approach.
>
>     Cheers,
>
>     Alex
>
>

-- 

Dynamic Devices Ltd <http://www.dynamicdevices.co.uk/>

Alex J Lennon / Director
1 Queensway, Liverpool L22 4RA

mobile: +44 (0)7956 668178

Linkedin <http://www.linkedin.com/in/alexjlennon> Skype
<skype:alexjlennon?add>

This e-mail message may contain confidential or legally privileged
information and is intended only for the use of the intended
recipient(s). Any unauthorized disclosure, dissemination, distribution,
copying or the taking of any action in reliance on the information
herein is prohibited. E-mails are not secure and cannot be guaranteed to
be error free as they can be intercepted, amended, or contain viruses.
Anyone who communicates with us by e-mail is deemed to have accepted
these risks. Company Name is not responsible for errors or omissions in
this message and denies any responsibility for any damage arising from
the use of e-mail. Any opinion and other statement contained in this
message and any attachment are solely those of the author and do not
necessarily represent those of the company.


[-- Attachment #2.1: Type: text/html, Size: 11677 bytes --]

[-- Attachment #2.2: ddlogo-4.png --]
[-- Type: image/png, Size: 3997 bytes --]

[-- Attachment #2.3: linkedin.png --]
[-- Type: image/png, Size: 631 bytes --]

[-- Attachment #2.4: skype.png --]
[-- Type: image/png, Size: 800 bytes --]

Re: [meta-raspberrypi] Using the camera

[Alex J Lennon]

[-- Attachment #1: Type: text/plain, Size: 2755 bytes --]


On 01/06/2014 22:35, Alex J Lennon wrote:
>
> On 01/06/2014 22:22, Alexandru Vaduva wrote:
>> This are indeed some very good news Alex J Lennon.
>> I have some questions, but those maybe can be answered by the
>> maintainers of the meta-raspberrypi layer:
>> Why was this change done?
>>      -PREFERRED_PROVIDER_virtual/egl ?= "vc-graphics-hardfp"
>>      -PREFERRED_PROVIDER_virtual/libgles2 ?= "vc-graphics-hardfp"
>>      +PREFERRED_PROVIDER_virtual/egl ?= "userland"
>>      +PREFERRED_PROVIDER_virtual/libgles2 ?= "userland"
>> How it may affect other applications?
>> Andrei: Do you have any input on this?
>>
>>

I think I've worked out what is happening. It looks like an interesting,
and pretty obscure, effect of the default bitbake linker flags.

There's an __attribute__(constructor) decorated function that is
supposed to be executed when libmmal_vc_client.so is loaded.

However by default bitbake passes in LDFLAGS of --as-needed which means
that although raspivid is set to be linked against libmmal_vc_client,
the dependency, which is un-needed by raspivid as there's no call into
that library, is removed.

The userland code for Raspivid tries to create a component with a call
to  mmal_component_create() which is in libmmal_core

ref:
https://github.com/raspberrypi/userland/blob/master/host_applications/linux/apps/raspicam/RaspiVid.c

This function goes to a default constructor     which walks a list
mmal_component_supplier_create(const char *name, MMAL_COMPONENT_T
*component)

ref:
https://github.com/raspberrypi/userland/blob/master/interface/mmal/core/mmal_component.c

The function that populates the supplier list,
mmal_component_supplier_register(), is called from a function in another
library, libmmal_vc_client, which is decorated with

MMAL_CONSTRUCTOR(mmal_register_component_videocore);

which is defined as

# define MMAL_CONSTRUCTOR(func) void __attribute__((constructor,used))
func(void)

i.e. This registration function would normally execute when the library
it lives in is loaded, but because there's no call into that library
from raspivid, and because we linked with --as-needed, the library is
removed from the executable's dependency list, and the components are
never registered...

Diffing the working and non-working raspivids,

Dynamic Section:
   NEEDED               libmmal_core.so
   NEEDED               libmmal_util.so
-  NEEDED               libmmal_vc_client.so
   NEEDED               libvcos.so

So if I modify the userland_git.bb to remove the --as-needed

+LDFLAGS="-Wl,-O1 -Wl,--hash-style=gnu"

With this change I can now build userland out of meta-raspberrypi and
raspivid works for me.

Cheers,

Alex



 

[-- Attachment #2: Type: text/html, Size: 5163 bytes --]

Re: [meta-raspberrypi] Using the camera

[Andrei Gherzan]

[-- Attachment #1: Type: text/plain, Size: 3783 bytes --]

On Mon, Jun 2, 2014 at 4:18 AM, Alex J Lennon <ajlennon@dynamicdevices.co.uk
> wrote:

>
> On 01/06/2014 22:35, Alex J Lennon wrote:
>
>
> On 01/06/2014 22:22, Alexandru Vaduva wrote:
>
>  This are indeed some very good news Alex J Lennon.
>  I have some questions, but those maybe can be answered by the
> maintainers of the meta-raspberrypi layer:
>  Why was this change done?
>      -PREFERRED_PROVIDER_virtual/egl ?= "vc-graphics-hardfp"
>      -PREFERRED_PROVIDER_virtual/libgles2 ?= "vc-graphics-hardfp"
>      +PREFERRED_PROVIDER_virtual/egl ?= "userland"
>      +PREFERRED_PROVIDER_virtual/libgles2 ?= "userland"
>  How it may affect other applications?
>  Andrei: Do you have any input on this?
>
>
>
> I think I've worked out what is happening. It looks like an interesting,
> and pretty obscure, effect of the default bitbake linker flags.
>
> There's an __attribute__(constructor) decorated function that is supposed
> to be executed when libmmal_vc_client.so is loaded.
>
> However by default bitbake passes in LDFLAGS of --as-needed which means
> that although raspivid is set to be linked against libmmal_vc_client, the
> dependency, which is un-needed by raspivid as there's no call into that
> library, is removed.
>
> The userland code for Raspivid tries to create a component with a call to
> mmal_component_create() which is in libmmal_core
>
> ref:
> https://github.com/raspberrypi/userland/blob/master/host_applications/linux/apps/raspicam/RaspiVid.c
>
> This function goes to a default constructor     which walks a list
> mmal_component_supplier_create(const char *name, MMAL_COMPONENT_T
> *component)
>
> ref:
> https://github.com/raspberrypi/userland/blob/master/interface/mmal/core/mmal_component.c
>
> The function that populates the supplier list,
> mmal_component_supplier_register(), is called from a function in another
> library, libmmal_vc_client, which is decorated with
>
> MMAL_CONSTRUCTOR(mmal_register_component_videocore);
>
> which is defined as
>
> # define MMAL_CONSTRUCTOR(func) void __attribute__((constructor,used))
> func(void)
>
> i.e. This registration function would normally execute when the library it
> lives in is loaded, but because there's no call into that library from
> raspivid, and because we linked with --as-needed, the library is removed
> from the executable's dependency list, and the components are never
> registered...
>
> Diffing the working and non-working raspivids,
>
> Dynamic Section:
>    NEEDED               libmmal_core.so
>    NEEDED               libmmal_util.so
> -  NEEDED               libmmal_vc_client.so
>    NEEDED               libvcos.so
>
> So if I modify the userland_git.bb to remove the --as-needed
>
> +LDFLAGS="-Wl,-O1 -Wl,--hash-style=gnu"
>
> With this change I can now build userland out of meta-raspberrypi and
> raspivid works for me.
>
> Cheers,
>
> Alex
>
>
>
>
>

I managed to get in sync with this discussion and will come with some
clarifications.

We switched to userland because that should give the user the best
customization for graphics libraries. So as long as we have the sources
would be strange not to use it. But if user doesn't want to compile the
graphics libraries, can overwrite the PREFERENCE as needed. But generally
building packages from source would avoid incompatibilities and some of the
issues (linkage etc). But this is an example which proves that this can add
issues too.

Now specific to this problem, I understand it, and the the fix that follows
this discussion seems to be right. Just heading to merges. Thanks a lot
guys (sorry for delay - will try to be more responsive).



-- 
*Andrei Gherzan*
m: +40.744.478.414 |  f: +40.31.816.28.12

[-- Attachment #2: Type: text/html, Size: 6323 bytes --]

Re: [meta-raspberrypi] Using the camera

[Andrei Gherzan]

[-- Attachment #1: Type: text/plain, Size: 4943 bytes --]

On Tue, Jun 10, 2014 at 9:01 PM, Andrei Gherzan <andrei@gherzan.ro> wrote:

>
>
>
> On Mon, Jun 2, 2014 at 4:18 AM, Alex J Lennon <
> ajlennon@dynamicdevices.co.uk> wrote:
>
>>
>> On 01/06/2014 22:35, Alex J Lennon wrote:
>>
>>
>> On 01/06/2014 22:22, Alexandru Vaduva wrote:
>>
>>  This are indeed some very good news Alex J Lennon.
>>  I have some questions, but those maybe can be answered by the
>> maintainers of the meta-raspberrypi layer:
>>  Why was this change done?
>>      -PREFERRED_PROVIDER_virtual/egl ?= "vc-graphics-hardfp"
>>      -PREFERRED_PROVIDER_virtual/libgles2 ?= "vc-graphics-hardfp"
>>      +PREFERRED_PROVIDER_virtual/egl ?= "userland"
>>      +PREFERRED_PROVIDER_virtual/libgles2 ?= "userland"
>>  How it may affect other applications?
>>  Andrei: Do you have any input on this?
>>
>>
>>
>> I think I've worked out what is happening. It looks like an interesting,
>> and pretty obscure, effect of the default bitbake linker flags.
>>
>> There's an __attribute__(constructor) decorated function that is supposed
>> to be executed when libmmal_vc_client.so is loaded.
>>
>> However by default bitbake passes in LDFLAGS of --as-needed which means
>> that although raspivid is set to be linked against libmmal_vc_client, the
>> dependency, which is un-needed by raspivid as there's no call into that
>> library, is removed.
>>
>> The userland code for Raspivid tries to create a component with a call
>> to  mmal_component_create() which is in libmmal_core
>>
>> ref:
>> https://github.com/raspberrypi/userland/blob/master/host_applications/linux/apps/raspicam/RaspiVid.c
>>
>> This function goes to a default constructor     which walks a list
>> mmal_component_supplier_create(const char *name, MMAL_COMPONENT_T
>> *component)
>>
>> ref:
>> https://github.com/raspberrypi/userland/blob/master/interface/mmal/core/mmal_component.c
>>
>> The function that populates the supplier list,
>> mmal_component_supplier_register(), is called from a function in another
>> library, libmmal_vc_client, which is decorated with
>>
>> MMAL_CONSTRUCTOR(mmal_register_component_videocore);
>>
>> which is defined as
>>
>> # define MMAL_CONSTRUCTOR(func) void __attribute__((constructor,used))
>> func(void)
>>
>> i.e. This registration function would normally execute when the library
>> it lives in is loaded, but because there's no call into that library from
>> raspivid, and because we linked with --as-needed, the library is removed
>> from the executable's dependency list, and the components are never
>> registered...
>>
>> Diffing the working and non-working raspivids,
>>
>> Dynamic Section:
>>    NEEDED               libmmal_core.so
>>    NEEDED               libmmal_util.so
>> -  NEEDED               libmmal_vc_client.so
>>    NEEDED               libvcos.so
>>
>> So if I modify the userland_git.bb to remove the --as-needed
>>
>> +LDFLAGS="-Wl,-O1 -Wl,--hash-style=gnu"
>>
>> With this change I can now build userland out of meta-raspberrypi and
>> raspivid works for me.
>>
>> Cheers,
>>
>> Alex
>>
>>
>>
>>
>>
>
> I managed to get in sync with this discussion and will come with some
> clarifications.
>
> We switched to userland because that should give the user the best
> customization for graphics libraries. So as long as we have the sources
> would be strange not to use it. But if user doesn't want to compile the
> graphics libraries, can overwrite the PREFERENCE as needed. But generally
> building packages from source would avoid incompatibilities and some of the
> issues (linkage etc). But this is an example which proves that this can add
> issues too.
>
> Now specific to this problem, I understand it, and the the fix that
> follows this discussion seems to be right. Just heading to merges. Thanks a
> lot guys (sorry for delay - will try to be more responsive).
>

I merged the patches but there is a strange behavior. With --as-needed
removed i still get the unneeded dependency.
 0x00000001 (NEEDED)                     Shared library: [libmmal_core.so]
 0x00000001 (NEEDED)                     Shared library: [libmmal_util.so]
 0x00000001 (NEEDED)                     Shared library:
[libmmal_vc_client.so]
 0x00000001 (NEEDED)                     Shared library: [libvcos.so]
 0x00000001 (NEEDED)                     Shared library: [libbcm_host.so]
 0x00000001 (NEEDED)                     Shared library: [libpthread.so.0]
 0x00000001 (NEEDED)                     Shared library: [libdl.so.2]
 0x00000001 (NEEDED)                     Shared library: [librt.so.1]
 0x00000001 (NEEDED)                     Shared library: [libvchiq_arm.so]
 0x00000001 (NEEDED)                     Shared library: [libc.so.6]

Alex, can you take another look on this? It seems like somehow the fix
doesn't work for me.
-- 
*Andrei Gherzan*
m: +40.744.478.414 |  f: +40.31.816.28.12

[-- Attachment #2: Type: text/html, Size: 7986 bytes --]

Re: [meta-raspberrypi] Using the camera

[Alex J Lennon]

> I merged the patches but there is a strange behavior. With --as-needed
> removed i still get the unneeded dependency.
>  0x00000001 (NEEDED)                     Shared library: [libmmal_core.so]
>  0x00000001 (NEEDED)                     Shared library: [libmmal_util.so]
>  0x00000001 (NEEDED)                     Shared library:
> [libmmal_vc_client.so]
>  0x00000001 (NEEDED)                     Shared library: [libvcos.so]
>  0x00000001 (NEEDED)                     Shared library: [libbcm_host.so]
>  0x00000001 (NEEDED)                     Shared library: [libpthread.so.0]
>  0x00000001 (NEEDED)                     Shared library: [libdl.so.2]
>  0x00000001 (NEEDED)                     Shared library: [librt.so.1]
>  0x00000001 (NEEDED)                     Shared library: [libvchiq_arm.so]
>  0x00000001 (NEEDED)                     Shared library: [libc.so.6]
>
> Alex, can you take another look on this? It seems like somehow the fix
> doesn't work for me.

If I understand you correctly the issue is that by default bitbake is
providing --no-as-needed into the userland configuration step

This has the effect that libmmal_vc_client is removed as a needed
library, therefore not loaded when raspivid loads,
and therefore doesn't register components that it would register when it
was loaded (because of use of
__attribute__((constructor,used)) decorating functions in that library).

We override --as-needed with --no-as-needed so that the dependency upon
libmmal_vc_client is no longer removed,
which I think is what you show above. If you remove my patch you should
see libmmal_vc_client disappear I believe.

Cheers,

Alex

Re: [meta-raspberrypi] Using the camera

[Andrei Gherzan]

[-- Attachment #1: Type: text/plain, Size: 1924 bytes --]

On Wed, Jun 11, 2014 at 3:54 PM, Alex J Lennon <
ajlennon@dynamicdevices.co.uk> wrote:

>
> > I merged the patches but there is a strange behavior. With --as-needed
> > removed i still get the unneeded dependency.
> >  0x00000001 (NEEDED)                     Shared library:
> [libmmal_core.so]
> >  0x00000001 (NEEDED)                     Shared library:
> [libmmal_util.so]
> >  0x00000001 (NEEDED)                     Shared library:
> > [libmmal_vc_client.so]
> >  0x00000001 (NEEDED)                     Shared library: [libvcos.so]
> >  0x00000001 (NEEDED)                     Shared library: [libbcm_host.so]
> >  0x00000001 (NEEDED)                     Shared library:
> [libpthread.so.0]
> >  0x00000001 (NEEDED)                     Shared library: [libdl.so.2]
> >  0x00000001 (NEEDED)                     Shared library: [librt.so.1]
> >  0x00000001 (NEEDED)                     Shared library:
> [libvchiq_arm.so]
> >  0x00000001 (NEEDED)                     Shared library: [libc.so.6]
> >
> > Alex, can you take another look on this? It seems like somehow the fix
> > doesn't work for me.
>
> If I understand you correctly the issue is that by default bitbake is
> providing --no-as-needed into the userland configuration step
>
> This has the effect that libmmal_vc_client is removed as a needed
> library, therefore not loaded when raspivid loads,
> and therefore doesn't register components that it would register when it
> was loaded (because of use of
> __attribute__((constructor,used)) decorating functions in that library).
>
> We override --as-needed with --no-as-needed so that the dependency upon
> libmmal_vc_client is no longer removed,
> which I think is what you show above. If you remove my patch you should
> see libmmal_vc_client disappear I believe.
>

My bad. Clear now. Thanks.


-- 
*Andrei Gherzan*
m: +40.744.478.414 |  f: +40.31.816.28.12

[-- Attachment #2: Type: text/html, Size: 2908 bytes --]