Re: [yocto] BSP Guide: what means "bsp_name.conf"?

2017-03-06 Thread Anders Darander 
* Robert P. J. Day  [170303 12:50]:

> "Note
>  When the preferred provider is assumed by default, the
>  PREFERRED_PROVIDER statement does not appear in the bsp_name.conf
>  file.   ^

>   can i assume those should read "machine.conf"? because i have no
> idea what "bsp_name.conf" refers to as it is.

Yes, that's the machine.conf...

Cheers,
Anders

-- 
Anders Darander, Senior System Architect
ChargeStorm AB / eStorm AB
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] [meta-raspberrypi][PATCH] gstreamer1.0-omx: remove bbappend for version 1.2.0

2017-03-06 Thread Khem Raj 
On Mon, Mar 6, 2017 at 7:28 AM, Maxin B. John  wrote:
> OE-Core rev: aa06a18d59eb391d1a7ace9daa0681bdf8daf17f
> removed gstreamer1.0-omx_1.2.0 recipe.
>

this is good.

> Signed-off-by: Maxin B. John 
> ---
>  ...o-acquire-buffer-when-src-pad-isn-t-activ.patch |  48 
>  .../0001-config-files-path.patch   | 137 
> -
>  .../0002-fix-decoder-flushing.patch|  16 ---
>  .../0003-no-timeout-on-get-state.patch |  16 ---
>  ...erly-handle-drain-requests-while-flushing.patch |  69 ---
>  ...-gst_omx_video_dec_set_format-if-there-s-.patch |  30 -
>  ...-unref-allocator-after-getting-it-from-al.patch |  48 
>  ...mxvideodec-Use-gstglmemoryegl-for-the-RPi.patch | 115 -
>  .../gstreamer/gstreamer1.0-omx_1.2.0.bbappend  |  14 ---
>  9 files changed, 493 deletions(-)
>  delete mode 100644 
> recipes-multimedia/gstreamer/gstreamer1.0-omx-1.2.0/0001-Don-t-try-to-acquire-buffer-when-src-pad-isn-t-activ.patch
>  delete mode 100644 
> recipes-multimedia/gstreamer/gstreamer1.0-omx-1.2.0/0001-config-files-path.patch
>  delete mode 100644 
> recipes-multimedia/gstreamer/gstreamer1.0-omx-1.2.0/0002-fix-decoder-flushing.patch
>  delete mode 100644 
> recipes-multimedia/gstreamer/gstreamer1.0-omx-1.2.0/0003-no-timeout-on-get-state.patch
>  delete mode 100644 
> recipes-multimedia/gstreamer/gstreamer1.0-omx-1.2.0/0004-Properly-handle-drain-requests-while-flushing.patch
>  delete mode 100644 
> recipes-multimedia/gstreamer/gstreamer1.0-omx-1.2.0/0005-Don-t-abort-gst_omx_video_dec_set_format-if-there-s-.patch
>  delete mode 100644 
> recipes-multimedia/gstreamer/gstreamer1.0-omx-1.2.0/0006-omxvideodec-unref-allocator-after-getting-it-from-al.patch
>  delete mode 100644 
> recipes-multimedia/gstreamer/gstreamer1.0-omx-1.2.0/0007-omxvideodec-Use-gstglmemoryegl-for-the-RPi.patch
>  delete mode 100644 
> recipes-multimedia/gstreamer/gstreamer1.0-omx_1.2.0.bbappend
>
> diff --git 
> a/recipes-multimedia/gstreamer/gstreamer1.0-omx-1.2.0/0001-Don-t-try-to-acquire-buffer-when-src-pad-isn-t-activ.patch
>  
> b/recipes-multimedia/gstreamer/gstreamer1.0-omx-1.2.0/0001-Don-t-try-to-acquire-buffer-when-src-pad-isn-t-activ.patch
> deleted file mode 100644
> index 815a7c2..000
> --- 
> a/recipes-multimedia/gstreamer/gstreamer1.0-omx-1.2.0/0001-Don-t-try-to-acquire-buffer-when-src-pad-isn-t-activ.patch
> +++ /dev/null
> @@ -1,48 +0,0 @@
> -From 2e111e52f96f0b942abda120c30a876629bd73fc Mon Sep 17 00:00:00 2001
> -From: =?UTF-8?q?Enrique=20Oca=C3=B1a=20Gonz=C3=A1lez?= 
> -Date: Mon, 25 May 2015 14:53:35 +0200
> -Subject: [PATCH] Don't try to acquire buffer when src pad isn't active
> -
> -This solves a race condition when setting the pipeline from PAUSE to
> -NULL while the decoder loop is still running. Without this patch, the
> -thread which interacts with the decode sink pad gets blocked here:
> -
> -  gst_element_change_state()
> -  gst_element_change_state_func()
> -  gst_element_pads_activate() --> Deactivating pads
> -  activate_pads()
> -  gst_pad_set_active()
> -  gst_pad_activate_mode()
> -  post_activate()
> -  GST_PAD_STREAM_LOCK()
> -
> -while gst_omx_port_acquire_buffer() gets stalled forever in
> -gst_omx_component_wait_message() waiting for a message that will never
> -arrive:
> -
> -  gst_omx_video_dec_loop()
> -  gst_omx_port_acquire_buffer()
> -  gst_omx_component_wait_message()
> 
> - omx/gstomxvideodec.c | 5 +
> - 1 file changed, 5 insertions(+)
> -
> -diff --git a/omx/gstomxvideodec.c b/omx/gstomxvideodec.c
> -index cd24944..57a61dd 100644
>  a/omx/gstomxvideodec.c
> -+++ b/omx/gstomxvideodec.c
> -@@ -1247,6 +1247,11 @@ gst_omx_video_dec_loop (GstOMXVideoDec * self)
> -   GstClockTimeDiff deadline;
> -   OMX_ERRORTYPE err;
> -
> -+  if (!gst_pad_is_active(GST_VIDEO_DECODER_SRC_PAD (self))) {
> -+GST_DEBUG_OBJECT (self, "Src pad not active, not acquiring buffer and 
> flushing instead");
> -+  goto flushing;
> -+  }
> -+
> - #if defined (USE_OMX_TARGET_RPI) && defined (HAVE_GST_GL)
> -   port = self->eglimage ? self->egl_out_port : self->dec_out_port;
> - #else
> ---
> -1.8.3.2
> -
> diff --git 
> a/recipes-multimedia/gstreamer/gstreamer1.0-omx-1.2.0/0001-config-files-path.patch
>  
> b/recipes-multimedia/gstreamer/gstreamer1.0-omx-1.2.0/0001-config-files-path.patch
> deleted file mode 100644
> index a7da922..000
> --- 
> a/recipes-multimedia/gstreamer/gstreamer1.0-omx-1.2.0/0001-config-files-path.patch
> +++ /dev/null
> @@ -1,137 +0,0 @@
>  a/config/bellagio/gstomx.conf
> -+++ b/config/bellagio/gstomx.conf
> -@@ -1,6 +1,6 @@
> - [omxmpeg4videodec]
> - type-name=GstOMXMPEG4VideoDec
> --core-name=/usr/local/lib/libomxil-bellagio.so.0
> -+core-name=/usr/lib/libomxil-bellagio.so.0
> - component-name=OMX.st.video_decoder.mpeg4
> - rank=256
> - in-port-index=0
> -@@ -9,7 +9,7 @@
> -
> - [omxh264dec]
> - type-name=GstOMXH264Dec
>

Re: [yocto] Files missing from SDK

2017-03-06 Thread Gary Thomas 

On 2017-03-06 21:56, Paul Eggleton wrote:

On Tuesday, 7 March 2017 2:28:22 AM NZDT Gary Thomas wrote:

On 2017-03-06 13:22, Burton, Ross wrote:

On 3 March 2017 at 06:39, Gary Thomas > wrote:

I'm trying to build SDKs for my board, both the native style
using populate_sdk_ext as well as including the SDK packages
in my image.  My image includes some extended libraries of
my own packaging (am335x-pru-support) that I need to get into
these SDKs.  This package (via debian renaming) turns into

  libprussdrv-dbg - 2016-08-30-r0.23 - am335x-pru-support version
  2016-08-30-r0 - Debugging files libprussdrv-dev - 2016-08-30-r0.23
  - am335x-pru-support version 2016-08-30-r0 - Development files
  libprussdrv-staticdev - 2016-08-30-r0.23 - am335x-pru-support
  version 2016-08-30-r0 - Development files (St) libprussdrv1 -
  2016-08-30-r0.23 - am335x-pru-support version 2016-08-30-r0>
On my board/image, I can get the files I need but only if I manually
include libprussdrv-dev>
  # opkg files libprussdrv-dev | sort
  /usr/bin/pasm
  /usr/include/pruss/
  /usr/include/pruss/pruss_intc_mapping.h
  /usr/include/pruss/prussdrv.h
  /usr/lib/libprussdrv.so

How can I get these automatically added to my SDK images?  To build
the

board SDK, I'm adding these packages to my image:
  CORE_IMAGE_EXTRA_INSTALL = "packagegroup-core-sdk
  packagegroup-core-standalone-sdk-target">
I suppose I could add libprussdrv-dev to that list, but I'd like it a
bit more automated.>
For the native SDK, I tried adding this to local.conf:
  TOOLCHAIN_HOST_TASK_append = " nativesdk-am335x-pru-support"

which only got me the 'pasm' tool in my sysroot, but nothing else.

If libprussdrv1 is in your image then the -dev package should be pulled
into your SDK images, assuming that you have IMAGE_FEATURES+=dev-pkgs
already.


Thanks, that did it for the embedded SDK


That shouldn't actually be necessary. IMAGE_FEATURES controls what goes into
the image, adding dev-pkgs to that is going to include those in the image, not
just the SDK. We have a SDKIMAGE_FEATURES and the default value of that
includes dev-pkgs. If libprussdrv1 is in the image and SDKIMAGE_FEATURES is at
the default (or otherwise includes dev-pkgs) I have to say I'm not sure what
would be preventing this from working.


The same should mean that standalone SDKs (populate_sdk-style) contain the
headers too.  Worse case, TOOLCHAIN_TARGET_TASK_append = "
libprussdrvi-dev".


Sadly, this still doesn't work.  With the TOOLCHAIN* line above, I get:
   ERROR: Nothing RPROVIDES 'libprussdrv1-dev'
Without it, no changes - the bits are still missing.


As with almost all variables, in TOOLCHAIN_TARGET_TASK you want the recipe-
space name of the package, not the final (post debian-renamed) name.


I tried that as well, and it got a lot farther along, but failed in
the final steps:

ERROR: uninative-tarball-1.0-r0 do_populate_sdk: Unable to install packages. Command 
'/build/p8701_2016-10-22/tmp/work/x86_64-nativesdk-amltdsdk-linux/uninative-tarball/1.0-r0/recipe-sysroot-native/usr/bin/opkg 
--volatile-cache -f /build/p8701_2016-10-22/tmp/work/x86_64-nativesdk-amltdsdk-linux/uninative-tarball/1.0-r0/opkg.conf 
-t /build/p8701_2016-10-22/tmp/work/x86_64-nativesdk-amltdsdk-linux/uninative-tarball/1.0-r0/temp/ipktemp/ -o 
/build/p8701_2016-10-22/tmp/work/x86_64-nativesdk-amltdsdk-linux/uninative-tarball/1.0-r0/sdk/image/opt/amltd/2.2+snapshot/sysroots/none 
 --force_postinstall --prefer-arch-to-version   install libprussdrv-dev' returned 255:

Collected errors:
 * opkg_prepare_url_for_install: Couldn't find anything to satisfy 
'libprussdrv-dev'.

ERROR: uninative-tarball-1.0-r0 do_populate_sdk: Function failed: 
do_populate_sdk

--

Gary Thomas |  Consulting for the
MLB Associates  |Embedded world

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

[yocto] [meta-rockchip][PATCH v2] recipes-graphics: mali-userspace: add

2017-03-06 Thread Jacob Chen 
Do some modifying according to meta-sunxi

* add COMPATIBLE_MACHINE statement
* detect hard-float
* combine to one bb file

The difference is it depend on mesa to provide dev-package rather than offer it
by itself, which can save some time to solve the compile errors.

Change-Id: If81c363d4cfb11ade08b6c7cfcbfbe56e9d8824b
---
 .../mali-userspace/mali-userspace_git.bb   | 83 ++
 1 file changed, 83 insertions(+)
 create mode 100644 recipes-graphics/mali-userspace/mali-userspace_git.bb

diff --git a/recipes-graphics/mali-userspace/mali-userspace_git.bb 
b/recipes-graphics/mali-userspace/mali-userspace_git.bb
new file mode 100644
index 000..787f79d
--- /dev/null
+++ b/recipes-graphics/mali-userspace/mali-userspace_git.bb
@@ -0,0 +1,83 @@
+SUMMARY = "Userspace mali driver"
+DESCRIPTION = "Userspace mali driver"
+LICENSE = "CLOSED"
+SECTION = "libs"
+
+COMPATIBLE_MACHINE = "(rk3036|rk3288|rk3399)"
+
+# There's only hardfp version available
+python __anonymous() {
+tunes = d.getVar("TUNE_FEATURES", True)
+if not tunes:
+return
+if "callconvention-hard" not in tunes:
+pkgn = d.getVar("PN", True)
+pkgv = d.getVar("PV", True)
+raise bb.parse.SkipPackage("%s-%s ONLY supports hardfp mode for now" % 
(pkgn, pkgv))
+}
+
+DEPENDS = "libdrm mesa"
+
+PROVIDES += "virtual/egl virtual/libgles1 virtual/libgles2 virtual/libopencl 
libgbm"
+PROVIDES += "${@bb.utils.contains("DISTRO_FEATURES", "wayland", " 
virtual/libwayland-egl", " ", d)}"
+
+S = "${WORKDIR}/git"
+
+SRC_URI = "git://github.com/rockchip-linux/libmali.git;branch=rockchip;"
+SRCREV_pn-${PN} = "${AUTOREV}"
+
+INSANE_SKIP_${PN} = "already-stripped ldflags dev-so"
+
+INHIBIT_PACKAGE_DEBUG_SPLIT = "1"
+INHIBIT_PACKAGE_STRIP = "1"
+
+USE_X11 = "${@bb.utils.contains("DISTRO_FEATURES", "x11", "yes", "no", d)}"
+USE_WL = "${@bb.utils.contains("DISTRO_FEATURES", "wayland", "yes", "no", d)}"
+
+MALI_X11_rk3288 = "arm-linux-gnueabihf/libmali-midgard-r13p0-r0p0.so"
+MALI_WAYLAND_rk3288 = 
"arm-linux-gnueabihf/libmali-midgard-r13p0-r0p0-wayland.so "
+MALI_GBM_rk3288 = "arm-linux-gnueabihf/libmali-midgard-r13p0-r0p0-gbm.so "
+
+MALI_X11_rk3036 = "arm-linux-gnueabihf/libmali-utgard-r6p0.so"
+
+MALI_X11_rk3399 = "aarch64-linux-gnu/libmali-midgard-4th-r9p0.so"
+
+do_configure[noexec] = "1"
+do_compile[noexec] = "1"
+
+do_install () {
+   # Create MALI manifest
+   install -m 755 -d ${D}/${libdir}
+   if [ "${USE_X11}" = "yes" ]; then
+   install ${S}/lib/${MALI_X11} ${D}/${libdir}/libmali.so
+   elif [ "${USE_WL}" = "yes" ]; then
+   install ${S}/lib/${MALI_WAYLAND} ${D}/${libdir}/libmali.so
+   else
+   install ${S}/lib/${MALI_GBM} ${D}/${libdir}/libmali.so
+   fi
+
+   ln -sf libmali.so ${D}/${libdir}/libEGL.so
+   ln -sf libmali.so ${D}/${libdir}/libEGL.so.1
+   ln -sf libmali.so ${D}/${libdir}/libGLESv1_CM.so
+   ln -sf libmali.so ${D}/${libdir}/libGLESv1_CM.so.1
+   ln -sf libmali.so ${D}/${libdir}/libGLESv2.so
+   ln -sf libmali.so ${D}/${libdir}/libGLESv2.so.2
+   ln -sf libmali.so ${D}/${libdir}/libOpenCL.so
+   ln -sf libmali.so ${D}/${libdir}/libOpenCL.so.1
+   ln -sf libmali.so ${D}/${libdir}/libgbm.so
+   ln -sf libmali.so ${D}/${libdir}/libgbm.so.1
+
+   if [ "${USE_WL}" = "yes" ]; then
+   ln -sf libmali.so ${D}/${libdir}/libwayland-egl.so
+   fi
+}
+
+PACKAGES = "${PN}"
+FILES_${PN} += "${libdir}/*.so"
+
+RREPLACES_${PN} = "libegl libgles1 libglesv1-cm1 libgles2 libglesv2-2 libgbm"
+RCONFLICTS_${PN} = "libegl libgles1 libglesv1-cm1 libgles2 libglesv2-2 libgbm"
+
+# Workaround: libmali.so provided by rk having no SONAME field in it
+# so add it to fix rdepends problems
+RPROVIDES_${PN} += "libwayland-egl.so libgbm.so libGLESv1_CM.so libGLESv2.so 
libEGL.so libOpenCL.so"
-- 
2.7.4

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

[yocto] Reminder: Yocto Project Technical Team Meeting - Tuesday, Mar. 7, 2017 8:00 AM US Pacific Time

2017-03-06 Thread Jolley, Stephen K 
Tuesday, Mar. 7, 2017 8:00 AM US Pacific Time



Agenda:



* Opens collection - 5 min (Stephen)

* Yocto Project status - 5 min (Stephen/team)

https://wiki.yoctoproject.org/wiki/Yocto_Project_v2.3_Status

https://wiki.yoctoproject.org/wiki/Yocto_2.3_Schedule

https://wiki.yoctoproject.org/wiki/Yocto_2.3_Features

* Opens - 10 min

* Team Sharing - 10 min



We encourage people attending the meeting to logon the Yocto Project IRC 
chancel during the meeting (optional):



Yocto IRC: http://webchat.freenode.net/?channels=#yocto

IRC Tutorial: http://www.irchelp.org/irchelp/irctutorial.html



Conference Details:

Company:   WIND RIVER SYS

Ready-Access Number: 8007302996/9139049836

Access Code: 2705751


For International numbers see: 
https://www.yoctoproject.org/tools-resources/community/monthly-technical-call


Thanks,

Stephen K. Jolley
Yocto Project Program Manager
INTEL, MS JF1-255, 2111 N.E. 25th Avenue, Hillsboro, OR 97124
*   Work Telephone:(503) 712-0534
*Cell:   (208) 244-4460
* Email:
stephen.k.jol...@intel.com
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] Files missing from SDK

2017-03-06 Thread Paul Eggleton 
On Tuesday, 7 March 2017 2:28:22 AM NZDT Gary Thomas wrote:
> On 2017-03-06 13:22, Burton, Ross wrote:
> > On 3 March 2017 at 06:39, Gary Thomas > wrote:
> > I'm trying to build SDKs for my board, both the native style
> > using populate_sdk_ext as well as including the SDK packages
> > in my image.  My image includes some extended libraries of
> > my own packaging (am335x-pru-support) that I need to get into
> > these SDKs.  This package (via debian renaming) turns into
> > 
> >   libprussdrv-dbg - 2016-08-30-r0.23 - am335x-pru-support version
> >   2016-08-30-r0 - Debugging files libprussdrv-dev - 2016-08-30-r0.23
> >   - am335x-pru-support version 2016-08-30-r0 - Development files
> >   libprussdrv-staticdev - 2016-08-30-r0.23 - am335x-pru-support
> >   version 2016-08-30-r0 - Development files (St) libprussdrv1 -
> >   2016-08-30-r0.23 - am335x-pru-support version 2016-08-30-r0> 
> > On my board/image, I can get the files I need but only if I manually
> > include libprussdrv-dev> 
> >   # opkg files libprussdrv-dev | sort
> >   /usr/bin/pasm
> >   /usr/include/pruss/
> >   /usr/include/pruss/pruss_intc_mapping.h
> >   /usr/include/pruss/prussdrv.h
> >   /usr/lib/libprussdrv.so
> > 
> > How can I get these automatically added to my SDK images?  To build
> > the
> > 
> > board SDK, I'm adding these packages to my image:
> >   CORE_IMAGE_EXTRA_INSTALL = "packagegroup-core-sdk
> >   packagegroup-core-standalone-sdk-target"> 
> > I suppose I could add libprussdrv-dev to that list, but I'd like it a
> > bit more automated.> 
> > For the native SDK, I tried adding this to local.conf:
> >   TOOLCHAIN_HOST_TASK_append = " nativesdk-am335x-pru-support"
> > 
> > which only got me the 'pasm' tool in my sysroot, but nothing else.
> > 
> > If libprussdrv1 is in your image then the -dev package should be pulled
> > into your SDK images, assuming that you have IMAGE_FEATURES+=dev-pkgs
> > already.
> 
> Thanks, that did it for the embedded SDK

That shouldn't actually be necessary. IMAGE_FEATURES controls what goes into 
the image, adding dev-pkgs to that is going to include those in the image, not 
just the SDK. We have a SDKIMAGE_FEATURES and the default value of that 
includes dev-pkgs. If libprussdrv1 is in the image and SDKIMAGE_FEATURES is at 
the default (or otherwise includes dev-pkgs) I have to say I'm not sure what 
would be preventing this from working.

> > The same should mean that standalone SDKs (populate_sdk-style) contain the
> > headers too.  Worse case, TOOLCHAIN_TARGET_TASK_append = "
> > libprussdrvi-dev".
> 
> Sadly, this still doesn't work.  With the TOOLCHAIN* line above, I get:
>ERROR: Nothing RPROVIDES 'libprussdrv1-dev'
> Without it, no changes - the bits are still missing.

As with almost all variables, in TOOLCHAIN_TARGET_TASK you want the recipe-
space name of the package, not the final (post debian-renamed) name.

Cheers,
Paul

-- 

Paul Eggleton
Intel Open Source Technology Centre
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] [meta-rockchip][PATCH 4/7] recipes-graphics: Add support for mali-userspace

2017-03-06 Thread Trevor Woerner 
Hi Jacob,

This is a good first version, but I think there are some things that
could be added to make it better. For example, it should have a
COMPATIBLE_MACHINE statement, and it should detect whether the target
is using hard-float. Also the name "mali-userspace_t76x.bb" isn't a
good choice, the part after the underscore should indicate the
version, but t76x indicates the target mali implementation.

I think the sunxi people have done a good job with their mali recipes:
https://github.com/linux-sunxi/meta-sunxi/tree/master/recipes-graphics/libgles.
Would you be interested in creating a v2 modeled after their work?

Best regards,
Trevor


On Thu, Feb 9, 2017 at 2:23 AM, Jacob Chen  wrote:
> Hi,
>
>
>
> Trevor Woerner wrote on 2017年01月28日 09:44:
>>
>> On Fri, Jan 27, 2017 at 9:41 AM, Romain Perier 
>> wrote:
>>>
>>> Hi all,
>>>
>>> Correct me if I am wrong, but these are generic mali userpace binaries ?
>>> meta-rockchip is a bsp meta layer, it should only contains files and
>>> recipes
>>> to make rockchip board working or things specific to the rockchip board.
>>> For
>>> me these recipes are completly generic and might be re-used for another
>>> platform with another SoC.
>>>
>>> I don't want this in meta-rockchip. There is no a layer called meta-mali
>>> or
>>> something ?
>>>
>>> @Trevor: Feel free to comment, the point of view of the second maintainer
>>> is
>>> always welcome
>>
>> :-)
>>
>>
>> I was just about to point out that there is no meta-mali, and that
>> most BSP layers do include their own recipes for mali (meta-sunxi,
>> meta-96boards, meta-xilinx) but, googling around, there is in fact a
>> meta-mali provided my ARM itself:
>> https://github.com/ARM-software/meta-mali . So I guess we could go
>> either way. Although I haven't looked at what's specifically provided
>> in meta-mali to know if it would be useful or not.
>>
>
> I think GPU is a part of SOC. Other bsp meta layer also contain gpu userpace
> binaries.
> And, mali userpace binaries are not very generic, there are different in
> hardware versions, software versions and backends.
> e.g:
> rk3288's GPU is T76x-r0p0 but rk3288w's GPU is T76x-r1p0, so they have
> to use different binaries.
>
>
>
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

[yocto] [meta-oic][PATCH] Add recipe for IoTivity 1.2.1

2017-03-06 Thread Philippe Coval 
Signed-off-by: Philippe Coval 
---
 Origin: https://github.com/TizenTeam/meta-oic/commit/master.patch

 README  |   2 +-
 recipes-core/iotivity/iotivity_1.2.1.bb | 489 
 2 files changed, 490 insertions(+), 1 deletion(-)
 create mode 100644 recipes-core/iotivity/iotivity_1.2.1.bb

diff --git a/README b/README
index c6cf1a7..229e783 100644
--- a/README
+++ b/README
@@ -1,6 +1,6 @@
 meta-oic
 
-This layer contains recipes for the IoTivity Project (v1.2.0)
+This layer contains recipes for the IoTivity Project (v1.2.1)
 , sample applications and related components for any Yocto target.
 
 Contents
diff --git a/recipes-core/iotivity/iotivity_1.2.1.bb 
b/recipes-core/iotivity/iotivity_1.2.1.bb
new file mode 100644
index 000..344db21
--- /dev/null
+++ b/recipes-core/iotivity/iotivity_1.2.1.bb
@@ -0,0 +1,489 @@
+SUMMARY = "IoTivity framework and SDK sponsored by the Open Connectivity 
Foundation."
+DESCRIPTION = "IoTivity is an open source software framework enabling seamless 
device-to-device connectivity to address the emerging needs of the Internet of 
Things."
+HOMEPAGE = "https://www.iotivity.org/;
+DEPENDS = "boost virtual/gettext chrpath-replacement-native expat openssl 
util-linux curl glib-2.0 glib-2.0-native"
+DEPENDS += "sqlite3"
+EXTRANATIVEPATH += "chrpath-native"
+SECTION = "libs"
+LICENSE = "Apache-2.0"
+LIC_FILES_CHKSUM = "file://LICENSE.md;md5=22bf216f3077c279aed7b36b1fa9e6d1"
+
+branch_iotivity = "1.2-rel"
+SRCREV = "0c90ca6ffcbb6a2c56c977ec11bebb7b1d14053b"
+SRC_URI = 
"git://github.com/iotivity/iotivity.git;destsuffix=${S};branch=${branch_iotivity};protocol=http;"
+SRC_URI += 
"file://0364-yocto-Use-tools-from-sysroot-before-system-PATH-agai.patch"
+
+url_tinycbor = "git://github.com/01org/tinycbor.git"
+SRCREV_tinycbor = "31c7f81d45d115d2007b1c881cbbd3a19618465c"
+SRC_URI += 
"${url_tinycbor};name=tinycbor;destsuffix=${S}/extlibs/tinycbor/tinycbor;protocol=http"
+
+url_gtest = 
"http://pkgs.fedoraproject.org/repo/pkgs/gtest/gtest-1.7.0.zip/2d6ec8ccdf5c46b05ba54a9fd1d130d7/gtest-1.7.0.zip;
+SRC_URI[gtest.md5sum] = "2d6ec8ccdf5c46b05ba54a9fd1d130d7"
+SRC_URI[gtest.sha256sum] = 
"247ca18dd83f53deb1328be17e4b1be31514cedfc1e3424f672bf11fd7e0d60d"
+SRC_URI += "${url_gtest};name=gtest;subdir=${BP}/extlibs/gtest"
+
+url_hippomocks = "git://github.com/dascandy/hippomocks.git"
+SRCREV_hippomocks = "dca4725496abb0e41f8b582dec21d124f830a8e5"
+SRC_URI += 
"${url_hippomocks};name=hippomocks;destsuffix=${S}/extlibs/hippomocks-master;protocol=http"
+SRC_URI += "file://hippomocks_mips_patch"
+
+SRCREV_mbedtls = "85c2a928ed352845793db000e78e2b42c8dcf055"
+url_mbedtls="git://github.com/ARMmbed/mbedtls.git"
+SRC_URI += 
"${url_mbedtls};name=mbedtls;destsuffix=${S}/extlibs/mbedtls/mbedtls;protocol=http"
+
+inherit pkgconfig scons
+
+
+python () {
+IOTIVITY_TARGET_ARCH = d.getVar("TARGET_ARCH", True)
+d.setVar("IOTIVITY_TARGET_ARCH", IOTIVITY_TARGET_ARCH)
+EXTRA_OESCONS = d.getVar("EXTRA_OESCONS", True)
+EXTRA_OESCONS += " TARGET_OS=yocto TARGET_ARCH=" + IOTIVITY_TARGET_ARCH + 
" RELEASE=1"
+EXTRA_OESCONS += " VERBOSE=1"
+# Aligned to default configuration, but features can be changed here (at 
your own risk):
+# EXTRA_OESCONS += " ROUTING=GW"
+# EXTRA_OESCONS += " SECURED=1"
+# EXTRA_OESCONS += " TCP=1"
+d.setVar("EXTRA_OESCONS", EXTRA_OESCONS)
+}
+
+
+IOTIVITY_BIN_DIR = "/opt/${PN}"
+IOTIVITY_BIN_DIR_D = "${D}${IOTIVITY_BIN_DIR}"
+
+do_compile_prepend() {
+export PKG_CONFIG_PATH="${PKG_CONFIG_PATH}"
+export PKG_CONFIG="PKG_CONFIG_SYSROOT_DIR=\"${PKG_CONFIG_SYSROOT_DIR}\" 
pkg-config"
+export LD_FLAGS="${LD_FLAGS}"
+}
+
+make_dir() {
+install -d $1
+}
+
+copy_file() {
+install -c -m 444 $1 $2
+}
+
+copy_exec() {
+install -c -m 555 $1 $2
+}
+
+copy_file_recursive() {
+cd $1 && find . -type d -exec install -d $2/"{}" \;
+cd $1 && find . -type f -exec install -c -m 444 "{}" $2/"{}" \;
+}
+
+copy_exec_recursive() {
+cd $1 && find . -executable -exec install -c -m 555 "{}" $2/"{}" \;
+}
+
+do_install() {
+make_dir ${D}${libdir}
+#Resource
+#C++ APIs
+copy_file ${S}/out/yocto/${IOTIVITY_TARGET_ARCH}/release/liboc.so 
${D}${libdir}
+if ${@bb.utils.contains('EXTRA_OESCONS', 'SECURED=1', 'true', 'false', 
d)}; then
+copy_file 
${S}/out/yocto/${IOTIVITY_TARGET_ARCH}/release/resource/provisioning/libocprovision.so
 ${D}${libdir}
+fi
+
+#Logger
+copy_file ${S}/out/yocto/${IOTIVITY_TARGET_ARCH}/release/liboc_logger.so 
${D}${libdir}
+copy_file 
${S}/out/yocto/${IOTIVITY_TARGET_ARCH}/release/liboc_logger_core.so 
${D}${libdir}
+
+#CSDK Shared
+copy_file 
${S}/out/yocto/${IOTIVITY_TARGET_ARCH}/release/libconnectivity_abstraction.so 
${D}${libdir}
+copy_file ${S}/out/yocto/${IOTIVITY_TARGET_ARCH}/release/liboctbstack.so 
${D}${libdir}
+
+#CSDK Static
+copy_file

Re: [yocto] [meta-rockchip][PATCH v2 2/5] u-boot-rockchip: add

2017-03-06 Thread Trevor Woerner 
On Mon, Mar 6, 2017 at 2:04 AM, Eddie Cai  wrote:
> 2017-03-06 13:06 GMT+08:00 Trevor Woerner :
>>
>> I can assume everyone can build/include u-boot successfully when using
>> unmodified repositories?
>
> Yes, I can build it successfully.

Excellent, thank you for the update. I'll push the commit to master.
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

[yocto] [qa-tools][PATCH] testopia_update: Add option to define test plan

2017-03-06 Thread jose . perez . carranza 
From: Jose Perez Carranza 

There are cases where the test plan and the product name are not equal hence
an option is added to handle those cases and define thetest plan to work on.

Signed-off-by: Jose Perez Carranza 
---
 testopia_update.py  | 11 +--
 testopia_update/product/__init__.py |  6 +++---
 2 files changed, 12 insertions(+), 5 deletions(-)

diff --git a/testopia_update.py b/testopia_update.py
index 9b35188..1dd40cd 100755
--- a/testopia_update.py
+++ b/testopia_update.py
@@ -70,6 +70,9 @@ def get_args():
 dest="project_revision", help='SCM Revision of the project.')
 parser.add_argument('--project-date', required=False,
 dest="project_date", help='SCM version/revision date of the project.')
+parser.add_argument('--test-plan', required=False,
+dest="plan_name", help='Name of the test plan of the product, used 
when \
+test plan name is different from product 
name.')
 
 parser.add_argument('--results-log', required=False,
 dest="results_log", help='Results log.')
@@ -139,10 +142,14 @@ if __name__ == '__main__':
 (sys.argv[0], args.product_name))
 sys.exit(1)
 
+product.plan = args.plan_name
+if not product.plan:
+product.plan = product.name
+
 test_plan = product.get_test_plan(args.branch_name)
 if not test_plan:
-logger.error("%s: Test plan for product %s and branch %s not exists."\
- % (sys.argv[0], args.product_name, args.branch_name))
+logger.error("%s: Test plan %s for product %s and branch %s not 
exists."\
+ % (sys.argv[0], product.plan ,args.product_name, 
args.branch_name))
 
 sys.exit(1)
 
diff --git a/testopia_update/product/__init__.py 
b/testopia_update/product/__init__.py
index e401824..023fb02 100644
--- a/testopia_update/product/__init__.py
+++ b/testopia_update/product/__init__.py
@@ -16,11 +16,11 @@ class Product(object):
 def get_test_plan(self, branch_name):
 tp = None
 
-tp_name = '%s: %s branch' % (self.name, branch_name)
+tp_name = '%s: %s branch' % (self.plan, branch_name)
 
 tp = self.testopia.testplan_list(name=tp_name)
 if not tp:
-tp_alt_name = '%s: %s branch' % (self.name, branch_name.lower())
+tp_alt_name = '%s: %s branch' % (self.plan, branch_name.lower())
 tp = self.testopia.testplan_list(name=tp_alt_name)
 
 if tp:
@@ -68,7 +68,7 @@ class Product(object):
 category_name, optional):
 summary_alts = []
 summary_alts.append('%s_%s_%s_%s' % (ttype, project_version,
-category_name, self.name))
+category_name, self.plan))
 summary_alts.append('%s_%s_%s' % (ttype, project_version,
 category_name))
 summary_alts.append('%s_%s' % (ttype, category_name))
-- 
2.11.0

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

Re: [yocto] Strange error

2017-03-06 Thread Matthew McClintock 
On Mon, Mar 6, 2017 at 6:15 AM, Gary Thomas  wrote:
> ERROR: When reparsing
> /local/poky-cutting-edge/meta/recipes-core/sysvinit/sysvinit-inittab_2.88dsf.bb.do_install,
> the basehash value changed from 2b888d6b72e00c404fc7e17436e465eb to
> 0fd6c915488c10c37cdfd6a674354e65. The metadata is not deterministic and this
> needs to be fixed.
> ERROR: Taskhash mismatch 15202ef0ff19a8f7a485533510dab7e8 versus
> 81fae57019b1a17967258945560affc1 for
> /local/poky-cutting-edge/meta/recipes-core/sysvinit/sysvinit-inittab_2.88dsf.bb.do_install

Is there anything in this file that can cause the signature to change?
E.g. a variable expanding to a time, or parallel make option, or size,
etc.

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

[yocto] Yocto Project Status WW10’17

2017-03-06 Thread Jolley, Stephen K 
Current Dev Position: YP 2.3 M3

Next Deadline: YP 2.3 M3 by Feb. 27, 2017


*** FEATURE FREEZE for 2.3 is now in effect. ***


SWAT team rotation: Todor -> Tracy on Mar. 4, 2017.

SWAT team rotation: Tracy -> Alejandro on Mar. 11, 2017.

https://wiki.yoctoproject.org/wiki/Yocto_Build_Failure_Swat_Team


Key Status/Updates:

·2.3 M3 has not yet build but progress is being made on 
stabilizing/merging the patches.

·As promised, the codename for 2.4 will be announced now and will be 
‘rocko’

·We have been hit with a number of problems around minimal builds of 
eSDK, where there were problems in the autobuilder implementation of this, 
minimal eSDKs themselves and changes to the testing infrastructure for minimal 
eSDKs. With so many moving pieces it's taken Ross/RP several days to unwind the 
problems and fix them. The good news is this issue is now resolved.

·We are not going to make the move from smart to dnf in 2.3, there 
simply isn’t enough development time left and the feature isn’t ready.

·We have merged ovmf, the queued wic changes, many queued version 
updates, some selftest speedup optimizations, 4.10 kernel changes, the YP 
compatible testing script, and many other patches.

·Still pending are:

o   Merging go into OE-Core?

o   Separate out elderly GPLv2 into a separate layer?

Go continues to suffer build failures, I have a patchset for gplv2 ready for 
testing and have posted on the openembedded-architecture list about that change.

·Since we’re into the stabilization phase of 2.3, planning for 2.4 will 
be beginning soon and we’re starting to plan out 2.4 in the bugzilla. If you 
have suggestions for 2.4, please ensure they are in bugzilla.


Proposed upcoming dot releases:

YP 2.1.3 Cut off May 15, 2017

YP 2.1.3 Release by May 26, 2017

YP 2.2.2 Cut off May 29, 2017

YP 2.2.2 Release by June 9, 2017


Key YP 2.3 Dates:

YP 2.3 M3 Release is Mar. 10, 2017 (Will be a few weeks late.)

YP 2.3 M4 Cutoff is April 10, 2017

YP 2.3 M4 Release is May 5, 2017


Tracking Metrics:

WDD 2737 (last week 2744)

(https://wiki.yoctoproject.org/charts/combo.html)


Key Status Links for YP:

https://wiki.yoctoproject.org/wiki/Yocto_Project_v2.3_Status

https://wiki.yoctoproject.org/wiki/Yocto_2.3_Schedule

https://wiki.yoctoproject.org/wiki/Yocto_2.3_Features


[If anyone has suggestions for other information you’d like to see on this 
weekly status update, let us know!]

Thanks,

Stephen K. Jolley
Yocto Project Program Manager
INTEL, MS JF1-255, 2111 N.E. 25th Avenue, Hillsboro, OR 97124
•   Work Telephone:(503) 712-0534
•Cell:   (208) 244-4460
• Email:stephen.k.jol...@intel.com

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

[yocto] [meta-raspberrypi][PATCH] gstreamer1.0-omx: remove bbappend for version 1.2.0

2017-03-06 Thread Maxin B. John 
OE-Core rev: aa06a18d59eb391d1a7ace9daa0681bdf8daf17f
removed gstreamer1.0-omx_1.2.0 recipe.

Signed-off-by: Maxin B. John 
---
 ...o-acquire-buffer-when-src-pad-isn-t-activ.patch |  48 
 .../0001-config-files-path.patch   | 137 -
 .../0002-fix-decoder-flushing.patch|  16 ---
 .../0003-no-timeout-on-get-state.patch |  16 ---
 ...erly-handle-drain-requests-while-flushing.patch |  69 ---
 ...-gst_omx_video_dec_set_format-if-there-s-.patch |  30 -
 ...-unref-allocator-after-getting-it-from-al.patch |  48 
 ...mxvideodec-Use-gstglmemoryegl-for-the-RPi.patch | 115 -
 .../gstreamer/gstreamer1.0-omx_1.2.0.bbappend  |  14 ---
 9 files changed, 493 deletions(-)
 delete mode 100644 
recipes-multimedia/gstreamer/gstreamer1.0-omx-1.2.0/0001-Don-t-try-to-acquire-buffer-when-src-pad-isn-t-activ.patch
 delete mode 100644 
recipes-multimedia/gstreamer/gstreamer1.0-omx-1.2.0/0001-config-files-path.patch
 delete mode 100644 
recipes-multimedia/gstreamer/gstreamer1.0-omx-1.2.0/0002-fix-decoder-flushing.patch
 delete mode 100644 
recipes-multimedia/gstreamer/gstreamer1.0-omx-1.2.0/0003-no-timeout-on-get-state.patch
 delete mode 100644 
recipes-multimedia/gstreamer/gstreamer1.0-omx-1.2.0/0004-Properly-handle-drain-requests-while-flushing.patch
 delete mode 100644 
recipes-multimedia/gstreamer/gstreamer1.0-omx-1.2.0/0005-Don-t-abort-gst_omx_video_dec_set_format-if-there-s-.patch
 delete mode 100644 
recipes-multimedia/gstreamer/gstreamer1.0-omx-1.2.0/0006-omxvideodec-unref-allocator-after-getting-it-from-al.patch
 delete mode 100644 
recipes-multimedia/gstreamer/gstreamer1.0-omx-1.2.0/0007-omxvideodec-Use-gstglmemoryegl-for-the-RPi.patch
 delete mode 100644 recipes-multimedia/gstreamer/gstreamer1.0-omx_1.2.0.bbappend

diff --git 
a/recipes-multimedia/gstreamer/gstreamer1.0-omx-1.2.0/0001-Don-t-try-to-acquire-buffer-when-src-pad-isn-t-activ.patch
 
b/recipes-multimedia/gstreamer/gstreamer1.0-omx-1.2.0/0001-Don-t-try-to-acquire-buffer-when-src-pad-isn-t-activ.patch
deleted file mode 100644
index 815a7c2..000
--- 
a/recipes-multimedia/gstreamer/gstreamer1.0-omx-1.2.0/0001-Don-t-try-to-acquire-buffer-when-src-pad-isn-t-activ.patch
+++ /dev/null
@@ -1,48 +0,0 @@
-From 2e111e52f96f0b942abda120c30a876629bd73fc Mon Sep 17 00:00:00 2001
-From: =?UTF-8?q?Enrique=20Oca=C3=B1a=20Gonz=C3=A1lez?= 
-Date: Mon, 25 May 2015 14:53:35 +0200
-Subject: [PATCH] Don't try to acquire buffer when src pad isn't active
-
-This solves a race condition when setting the pipeline from PAUSE to
-NULL while the decoder loop is still running. Without this patch, the
-thread which interacts with the decode sink pad gets blocked here:
-
-  gst_element_change_state()
-  gst_element_change_state_func()
-  gst_element_pads_activate() --> Deactivating pads
-  activate_pads()
-  gst_pad_set_active()
-  gst_pad_activate_mode()
-  post_activate()
-  GST_PAD_STREAM_LOCK()
-
-while gst_omx_port_acquire_buffer() gets stalled forever in
-gst_omx_component_wait_message() waiting for a message that will never
-arrive:
-
-  gst_omx_video_dec_loop()
-  gst_omx_port_acquire_buffer()
-  gst_omx_component_wait_message()

- omx/gstomxvideodec.c | 5 +
- 1 file changed, 5 insertions(+)
-
-diff --git a/omx/gstomxvideodec.c b/omx/gstomxvideodec.c
-index cd24944..57a61dd 100644
 a/omx/gstomxvideodec.c
-+++ b/omx/gstomxvideodec.c
-@@ -1247,6 +1247,11 @@ gst_omx_video_dec_loop (GstOMXVideoDec * self)
-   GstClockTimeDiff deadline;
-   OMX_ERRORTYPE err;
- 
-+  if (!gst_pad_is_active(GST_VIDEO_DECODER_SRC_PAD (self))) {
-+GST_DEBUG_OBJECT (self, "Src pad not active, not acquiring buffer and 
flushing instead");
-+  goto flushing;
-+  }
-+
- #if defined (USE_OMX_TARGET_RPI) && defined (HAVE_GST_GL)
-   port = self->eglimage ? self->egl_out_port : self->dec_out_port;
- #else
--- 
-1.8.3.2
-
diff --git 
a/recipes-multimedia/gstreamer/gstreamer1.0-omx-1.2.0/0001-config-files-path.patch
 
b/recipes-multimedia/gstreamer/gstreamer1.0-omx-1.2.0/0001-config-files-path.patch
deleted file mode 100644
index a7da922..000
--- 
a/recipes-multimedia/gstreamer/gstreamer1.0-omx-1.2.0/0001-config-files-path.patch
+++ /dev/null
@@ -1,137 +0,0 @@
 a/config/bellagio/gstomx.conf
-+++ b/config/bellagio/gstomx.conf
-@@ -1,6 +1,6 @@
- [omxmpeg4videodec]
- type-name=GstOMXMPEG4VideoDec
--core-name=/usr/local/lib/libomxil-bellagio.so.0
-+core-name=/usr/lib/libomxil-bellagio.so.0
- component-name=OMX.st.video_decoder.mpeg4
- rank=256
- in-port-index=0
-@@ -9,7 +9,7 @@
- 
- [omxh264dec]
- type-name=GstOMXH264Dec
--core-name=/usr/local/lib/libomxil-bellagio.so.0
-+core-name=/usr/lib/libomxil-bellagio.so.0
- component-name=OMX.st.video_decoder.avc
- rank=256
- in-port-index=0
-@@ -18,7 +18,7 @@
- 
- [omxmpeg4videoenc]
- type-name=GstOMXMPEG4VideoEnc
--core-name=/usr/local/lib/libomxil-bellagio.so.0

Re: [linux-yocto] [yocto-2.2.1][PATCH] Revert "tty: serial: 8250: add CON_CONSDEV to flags"

2017-03-06 Thread Bruce Ashfield 
On Mon, Mar 6, 2017 at 12:24 AM, Dengke Du  wrote:

> Thanks!
>
> Maybe we should update the commit in linux-yocto_4.8.bb in oe-core.
>


That will happen, just at a slower cadence then me getting the patch into
the tree.

Bruce


>
> Dengke
>
>
>
> On 2017年03月04日 04:14, Bruce Ashfield wrote:
>
>> merged
>>
>> Bruce
>>
>> On 2017-02-27 12:48 AM, Dengke Du wrote:
>>
>>> From: Herbert Xu 
>>>
>>> Upstream commit: 6741f551a0b26479de2532ffa43a366747e6dbf3
>>>
>>> This commit needs to be reverted because it prevents people from
>>> using the serial console as a secondary console with input being
>>> directed to tty0.
>>>
>>> IOW, if you boot with console=ttyS0 console=tty0 then all kernels
>>> prior to this commit will produce output on both ttyS0 and tty0
>>> but input will only be taken from tty0.  With this patch the serial
>>> console will always be the primary console instead of tty0,
>>> potentially preventing people from getting into their machines in
>>> emergency situations.
>>>
>>> Fixes: d03516df8375 ("tty: serial: 8250: add CON_CONSDEV to flags")
>>> Signed-off-by: Herbert Xu 
>>> Cc: stable 
>>> Signed-off-by: Greg Kroah-Hartman 
>>>
>>> Upstream-Status: Backport
>>> Signed-off-by: Dengke Du 
>>> ---
>>>  drivers/tty/serial/8250/8250_core.c | 2 +-
>>>  1 file changed, 1 insertion(+), 1 deletion(-)
>>>
>>> diff --git a/drivers/tty/serial/8250/8250_core.c
>>> b/drivers/tty/serial/8250/8250_core.c
>>> index dcf43f6..fa823a5 100644
>>> --- a/drivers/tty/serial/8250/8250_core.c
>>> +++ b/drivers/tty/serial/8250/8250_core.c
>>> @@ -675,7 +675,7 @@ static struct console univ8250_console = {
>>>  .device= uart_console_device,
>>>  .setup= univ8250_console_setup,
>>>  .match= univ8250_console_match,
>>> -.flags= CON_PRINTBUFFER | CON_ANYTIME | CON_CONSDEV,
>>> +.flags= CON_PRINTBUFFER | CON_ANYTIME,
>>>  .index= -1,
>>>  .data= _reg,
>>>  };
>>>
>>>
>>
>>
>


-- 
"Thou shalt not follow the NULL pointer, for chaos and madness await thee
at its end"
-- 
___
linux-yocto mailing list
linux-yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/linux-yocto

Re: [yocto] Files missing from SDK

2017-03-06 Thread Gary Thomas 

On 2017-03-06 13:22, Burton, Ross wrote:


On 3 March 2017 at 06:39, Gary Thomas > wrote:

I'm trying to build SDKs for my board, both the native style
using populate_sdk_ext as well as including the SDK packages
in my image.  My image includes some extended libraries of
my own packaging (am335x-pru-support) that I need to get into
these SDKs.  This package (via debian renaming) turns into
  libprussdrv-dbg - 2016-08-30-r0.23 - am335x-pru-support version 
2016-08-30-r0 - Debugging files
  libprussdrv-dev - 2016-08-30-r0.23 - am335x-pru-support version 
2016-08-30-r0 - Development files
  libprussdrv-staticdev - 2016-08-30-r0.23 - am335x-pru-support version 
2016-08-30-r0 - Development files (St)
  libprussdrv1 - 2016-08-30-r0.23 - am335x-pru-support version 2016-08-30-r0

On my board/image, I can get the files I need but only if I manually 
include libprussdrv-dev
  # opkg files libprussdrv-dev | sort
  /usr/bin/pasm
  /usr/include/pruss/
  /usr/include/pruss/pruss_intc_mapping.h
  /usr/include/pruss/prussdrv.h
  /usr/lib/libprussdrv.so

How can I get these automatically added to my SDK images?  To build the
board SDK, I'm adding these packages to my image:
  CORE_IMAGE_EXTRA_INSTALL = "packagegroup-core-sdk 
packagegroup-core-standalone-sdk-target"
I suppose I could add libprussdrv-dev to that list, but I'd like it a bit 
more automated.

For the native SDK, I tried adding this to local.conf:
  TOOLCHAIN_HOST_TASK_append = " nativesdk-am335x-pru-support"
which only got me the 'pasm' tool in my sysroot, but nothing else.


If libprussdrv1 is in your image then the -dev package should be pulled into 
your SDK images, assuming that you have
IMAGE_FEATURES+=dev-pkgs already.


Thanks, that did it for the embedded SDK



The same should mean that standalone SDKs (populate_sdk-style) contain the 
headers too.  Worse case,
TOOLCHAIN_TARGET_TASK_append = " libprussdrvi-dev".


Sadly, this still doesn't work.  With the TOOLCHAIN* line above, I get:
  ERROR: Nothing RPROVIDES 'libprussdrv1-dev'
Without it, no changes - the bits are still missing.

--

Gary Thomas |  Consulting for the
MLB Associates  |Embedded world

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

Re: [yocto] Files missing from SDK

2017-03-06 Thread Burton, Ross 
On 3 March 2017 at 06:39, Gary Thomas  wrote:

> I'm trying to build SDKs for my board, both the native style
> using populate_sdk_ext as well as including the SDK packages
> in my image.  My image includes some extended libraries of
> my own packaging (am335x-pru-support) that I need to get into
> these SDKs.  This package (via debian renaming) turns into
>   libprussdrv-dbg - 2016-08-30-r0.23 - am335x-pru-support version
> 2016-08-30-r0 - Debugging files
>   libprussdrv-dev - 2016-08-30-r0.23 - am335x-pru-support version
> 2016-08-30-r0 - Development files
>   libprussdrv-staticdev - 2016-08-30-r0.23 - am335x-pru-support version
> 2016-08-30-r0 - Development files (St)
>   libprussdrv1 - 2016-08-30-r0.23 - am335x-pru-support version
> 2016-08-30-r0
>
> On my board/image, I can get the files I need but only if I manually
> include libprussdrv-dev
>   # opkg files libprussdrv-dev | sort
>   /usr/bin/pasm
>   /usr/include/pruss/
>   /usr/include/pruss/pruss_intc_mapping.h
>   /usr/include/pruss/prussdrv.h
>   /usr/lib/libprussdrv.so
>
> How can I get these automatically added to my SDK images?  To build the
> board SDK, I'm adding these packages to my image:
>   CORE_IMAGE_EXTRA_INSTALL = "packagegroup-core-sdk
> packagegroup-core-standalone-sdk-target"
> I suppose I could add libprussdrv-dev to that list, but I'd like it a bit
> more automated.
>
> For the native SDK, I tried adding this to local.conf:
>   TOOLCHAIN_HOST_TASK_append = " nativesdk-am335x-pru-support"
> which only got me the 'pasm' tool in my sysroot, but nothing else.
>

If libprussdrv1 is in your image then the -dev package should be pulled
into your SDK images, assuming that you have IMAGE_FEATURES+=dev-pkgs
already.

The same should mean that standalone SDKs (populate_sdk-style) contain the
headers too.  Worse case, TOOLCHAIN_TARGET_TASK_append = "
libprussdrvi-dev".

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

Re: [yocto] Files missing from SDK

2017-03-06 Thread Gary Thomas 

On 2017-03-03 07:39, Gary Thomas wrote:

I'm trying to build SDKs for my board, both the native style
using populate_sdk_ext as well as including the SDK packages
in my image.  My image includes some extended libraries of
my own packaging (am335x-pru-support) that I need to get into
these SDKs.  This package (via debian renaming) turns into
  libprussdrv-dbg - 2016-08-30-r0.23 - am335x-pru-support version 2016-08-30-r0 
- Debugging files
  libprussdrv-dev - 2016-08-30-r0.23 - am335x-pru-support version 2016-08-30-r0 
- Development files
  libprussdrv-staticdev - 2016-08-30-r0.23 - am335x-pru-support version 
2016-08-30-r0 - Development files (St)
  libprussdrv1 - 2016-08-30-r0.23 - am335x-pru-support version 2016-08-30-r0

On my board/image, I can get the files I need but only if I manually include 
libprussdrv-dev
  # opkg files libprussdrv-dev | sort
  /usr/bin/pasm
  /usr/include/pruss/
  /usr/include/pruss/pruss_intc_mapping.h
  /usr/include/pruss/prussdrv.h
  /usr/lib/libprussdrv.so

How can I get these automatically added to my SDK images?  To build the
board SDK, I'm adding these packages to my image:
  CORE_IMAGE_EXTRA_INSTALL = "packagegroup-core-sdk 
packagegroup-core-standalone-sdk-target"
I suppose I could add libprussdrv-dev to that list, but I'd like it a bit more 
automated.

For the native SDK, I tried adding this to local.conf:
  TOOLCHAIN_HOST_TASK_append = " nativesdk-am335x-pru-support"
which only got me the 'pasm' tool in my sysroot, but nothing else.

Thanks for any pointers



Does no-one have ideas how I can get these additional files into my SDK(s)?

--

Gary Thomas |  Consulting for the
MLB Associates  |Embedded world

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

[yocto] Strange error

2017-03-06 Thread Gary Thomas 

I wanted to change (disable) extra getty tasks in my target image.  I'm using
sysvinit, so I added this line to my .conf:
  SYSVINIT_ENABLED_GETTYS = ""

I thought that would get the sysvinit-inittab package rebuilt as do_install
uses that variable, but alas it did not.

So I took out the big hammer and tried:

$ bitbake sysvinit-inittab -c cleanall
$ bitbake sysvinit-inittab

Now I get this error:

ERROR: When reparsing /local/poky-cutting-edge/meta/recipes-core/sysvinit/sysvinit-inittab_2.88dsf.bb.do_install, the 
basehash value changed from 2b888d6b72e00c404fc7e17436e465eb to 0fd6c915488c10c37cdfd6a674354e65. The metadata is not 
deterministic and this needs to be fixed.
ERROR: Taskhash mismatch 15202ef0ff19a8f7a485533510dab7e8 versus 81fae57019b1a17967258945560affc1 for 
/local/poky-cutting-edge/meta/recipes-core/sysvinit/sysvinit-inittab_2.88dsf.bb.do_install


So I took out an even bigger hammer:
$ find sstate-cache/ -name "*sysvinit-inittab*" | xargs -t rm -f
$ bitbake sysvinit-inittab -c cleanall
$ bitbake sysvinit-inittab

and I still get the same errors.  How can this be?  How do I get
to rebuild my sysvinit-inittab recipe and make the results stick?

Thanks for any pointers

--

Gary Thomas |  Consulting for the
MLB Associates  |Embedded world

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