Re: [yocto] [meta-raspberrypi] Using the camera
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 -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] [meta-raspberrypi] Using the camera
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 < ajlen...@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 > > -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] [meta-raspberrypi] Using the camera
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 > mailto:ajlen...@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
Re: [yocto] [meta-raspberrypi] Using the camera
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 -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] [Package Report System]Manual check recipes name list
This mail was sent out by Package Report System. It will list all the recipes which can't check upstream version by script, and will show how long it is since their last mannual version check. You can check the detail information at http://packages.yoctoproject.org/manuallychkinfo PackageName Version LastChkVersion LastChkTime Maintainer NoUpgradeReason puzzles r10116 N/A 41790 d Valentin Popa -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] [Package Report System]Upgrade recipes name list
This mail was sent out by Package Report System. This message list those recipes which need to be upgraded. If maintainers believe some of them needn't to upgrade this time, they can fill in RECIPE_NO_UPDATE_REASON_pn-"xxx" in upstream_tracking files to ignore this recipe remainder until newer upstream version was detected. Example: RECIPE_NO_UPDATE_REASON_pn-"xxx" = "Not upgrade to 2.0 because the new version is unstable" You can check the detail information at http://packages.yoctoproject.org/upgradepkgname PackageName Version UpVersion MaintainerNoUpgradeReason gnome-common 3.7.4 3.12.0 Valentin Popa puzzles r10116N/A Valentin Popa gtk+ 2.24.22 3.13.2 Valentin PopaDo not upgrade to version: 2 gnutls3.2.133.2.15 Valentin Popa gtk+3 3.10.73.13.2 Valentin Popa libpam1.1.6 1.1.8 Valentin Popa libtasn1 3.5 3.6 Valentin Popa gsettings-desktop-schemas 3.10.13.13.2 Valentin Popa gtk-update-icon-cache-native 3.4.4 3.13.2 Valentin Popa hicolor-icon-theme0.12 0.13 Valentin Popa gnome-icon-theme 2.31.03.12.0 Valentin Popawaiting for the sato gtk3 port liberation-fonts 1.04 2.00.1 Valentin Popa2.00.0 - fontforge package re... screen4.0.3 4.2.1 Valentin Popa xdg-utils 1.1.0-rc1 1.0.2 Valentin Popaonly release candidates avail... matchbox-panel-2 2.0+gitAUTOINC+26a3a67b41 2.0+gitAUTOINC+1a7304dValentin Popa webkit-gtk1.8.3 2.4.3 Valentin Popa>= 1.10.2 needs ruby matchbox-desktop 2.0+gitAUTOINC+71e3e6e042 2.0+gitAUTOINC+09170f4Valentin Popa shared-mime-info 1.2 1.3 Valentin Popa gnome-desktop 2.32.13.13.2 Valentin Popawaiting for the sato gtk3 port matchbox-keyboard 0.0+gitAUTOINC+217f1bfe14 0.0+gitAUTOINC+0899b02Valentin Popa blktrace 1.0.5+gitAUTOINC+d6918c8 1.0.5+gitAUTOINC+ce9ded7 Tom Zanussi systemtap-uprobes 2.5+gitAUTOINC+8f0fcd995f 2.5+gitAUTOINC+3db4196Tom Zanussi sysprof 1.2.0+gitAUTOINC+cd44ee6 1.2.0+gitAUTOINC+6901897 Tom Zanussi libusb1 1.0.181.0.19 Saul Wold mkelfimage4.0+gitAUTOINC+686a48a339 4.0+gitAUTOINC+25b55f3Saul Wold libcheck 0.9.120.9.13 Saul Wold cups 1.7.2 1.7.3 Saul Wold dpkg 1.17.41.17.9 Saul Wold glib-networking 2.38.02.40.1 Saul WoldPending Glib-2.0 Update vte 0.28.20.37.1 Saul WoldPending Glib-2.0 Update libxkbcommon 0.4.1 0.4.2 Saul Wold resolvconf1.74 1.75 Saul Wold sqlite3 3.8.4.3 3080403 Saul Wold man-pages 3.65 3.68 Saul Wold mx-1.0
