date:20180418

[linux-yocto] [PATCH 1/2] driver: of: configfs: fix a building warning

2018-04-18 Thread Meng.Li

From: Limeng 

Build kernel for arm64 platform, there is a warning as below:
drivers/of/configfs.c:153:34: note: format string is defined here
  pr_debug("%s: buf=%p max_count=%u\n", __func__,
 ~^
 %lu
This building warning is introduced by commit 784a7fe5585c
("OF: DT-Overlay configfs interface (v7)")

Because on arm64 platform, size_t is long unsigned int.
Therefore, change %u into %zu to compatible with arm
and arm64 platform.

Signed-off-by: Meng Li 
---
 drivers/of/configfs.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/of/configfs.c b/drivers/of/configfs.c
index c7e999c..8490d9c 100644
--- a/drivers/of/configfs.c
+++ b/drivers/of/configfs.c
@@ -150,7 +150,7 @@ ssize_t cfs_overlay_item_dtbo_read(struct config_item 
*item, void *buf,
 {
struct cfs_overlay_item *overlay = to_cfs_overlay_item(item);
 
-   pr_debug("%s: buf=%p max_count=%u\n", __func__,
+   pr_debug("%s: buf=%p max_count=%zu\n", __func__,
buf, max_count);
 
if (overlay->dtbo == NULL)
-- 
2.9.3

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

[linux-yocto] [v2]: : [yocto-4.12]: intel-socfpga: update patches for Stratix10 platform

2018-04-18 Thread Meng.Li

From: Limeng 


Hi Bruce,

Now, there are 2 below patches to update intel-socfpga, Stratix10 SoC platform.
0001-driver-of-configfs-fix-a-building-warning.patch
0002-driver-misc-intel-service-schedule-thread-out-when-t.patch

Please help to meger the 2 patches into linux-yocto, kernel 4.12, branch is 
standard/base

misc/intel-service.c |5 -
of/configfs.c|2 +-
2 files changed, 5 insertions(+), 2 deletions(-)

thanks,
Limeng


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

Re: [yocto] rocko cmake buld cstdlib:75:15: fatal error: stdlib.h: No such file or directory

2018-04-18 Thread Måns Zigher

Hi,

I am building with the SDK (not extensible) but it is also built as a
recipe when building an image. The recipe is inheriting cmake but it is
only in the image build that I am experiencing this problem which I
shouldn't since the cmake_do_configure should be called. I will try and run
bitbake -e on the recepie to see if I get any clear if the
cmake_do_configure is part of it or not.

Thanks for your time I appreciate it.

Br
Mans Zigher


On Wed, Apr 18, 2018, 22:47 Dennis Menschel  wrote:

> Hi Mans,
>
> Am 18.04.2018 um 06:56 schrieb Måns Zigher:
> > Hi Dennis,
> >
> > This makes me a bot confused in cmake_do_configure we have
> >
> >   -DCMAKE_NO_SYSTEM_FROM_IMPORTED=1 \
> >   ${EXTRA_OECMAKE} \
> >   -Wno-dev
> >
> > I would think that I am using this cmake_do_configure so then the
> > -DCMAKE_NO_SYSTEM_FROM_IMPORTED=1 should already be called correct?
> >
> > BR
> > Mans Zigher
>
> if you use "devtool build" from the extensible SDK to build a recipe
> that inherits cmake.bbclass, then the function cmake_do_configure() will
> be called implicitly.
>
> But if you manually compile a cmake project with the SDK, then that
> function won't be used. If your SDK contains the package
> nativesdk-cmake, then the SDK contains the following file:
>
>   $OECORE_NATIVE_SYSROOT/environment-setup.d/cmake.sh
>
> This file will be sourced along with the rest of the SDK and set an
> alias for cmake with an SDK-specific toolchain file.
>
> To verify if the option CMAKE_NO_SYSTEM_FROM_IMPORTED has been set by
> cmake, you can check if the file CMakeCache.txt (in the build directory)
> contains an entry for CMAKE_NO_SYSTEM_FROM_IMPORTED. An alternative way
> is to inspect the configuration via ccmake after calling cmake.
>
> Best regards,
> Dennis
>
>
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [linux-yocto] [PATCH 1/2] driver: of: configfs: fix a building warning

2018-04-18 Thread Li, Meng



> -Original Message-
> From: Bruce Ashfield [mailto:bruce.ashfi...@windriver.com]
> Sent: Thursday, April 19, 2018 5:01 AM
> To: Li, Meng
> Cc: linux-yocto@yoctoproject.org
> Subject: Re: [PATCH 1/2] driver: of: configfs: fix a building warning
> 
> On 2018-04-18 10:17 AM, meng...@windriver.com wrote:
> > From: Limeng 
> >
> > Build kernel for arm64 platform, there is a waring as below:
> 
> w/waring/warning/
> 
> > drivers/of/configfs.c:153:34: note: format string is defined here
> >pr_debug("%s: buf=%p max_count=%u\n", __func__,
> >   ~^
> >   %lu
> > Because on arm64 platform, size_t is long unsigned int.
> > Therefore, change %u into %zu to compatible with arm
> > and arm64 platform.
> 
> Is this a mainline introduced warning, or one that some backported
> patches have introduced ? If we've introduced the warning, we need
> to log the commit ID that introduced it in this commit message. We
> also need to quickly explain why that commit caused the warning.
> 
> Same comment for patch 2/2
> 

No, there is mainline or backported patches introduce this issue. We introduce 
the building warning.
The 2 files, configfs.c and intel-service.c are used implement FPGA manager 
feature.
They are from Intel-PSG(Altera) SDK.

I will send v2 pull request to fix the typo (warning) and add commit ID that 
introduce issue.

Thanks,
Limeng

> Bruce
> 
> >
> > Signed-off-by: Meng Li 
> > ---
> >   drivers/of/configfs.c | 2 +-
> >   1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/drivers/of/configfs.c b/drivers/of/configfs.c
> > index c7e999c..8490d9c 100644
> > --- a/drivers/of/configfs.c
> > +++ b/drivers/of/configfs.c
> > @@ -150,7 +150,7 @@ ssize_t cfs_overlay_item_dtbo_read(struct
> config_item *item, void *buf,
> >   {
> > struct cfs_overlay_item *overlay = to_cfs_overlay_item(item);
> >
> > -   pr_debug("%s: buf=%p max_count=%u\n", __func__,
> > +   pr_debug("%s: buf=%p max_count=%zu\n", __func__,
> > buf, max_count);
> >
> > if (overlay->dtbo == NULL)
> >

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

[yocto] [meta-mingw][PATCH 1/1] nativesdk-packagegroup-sdk-host: add qemu to SDK

2018-04-18 Thread Juro Bystricky

Now that we can build qemu for mingw, include it in SDK.

Signed-off-by: Juro Bystricky 
---
 recipes-core/packagegroups/nativesdk-packagegroup-sdk-host.bbappend | 1 +
 1 file changed, 1 insertion(+)

diff --git 
a/recipes-core/packagegroups/nativesdk-packagegroup-sdk-host.bbappend 
b/recipes-core/packagegroups/nativesdk-packagegroup-sdk-host.bbappend
index 9629354..ad69b13 100644
--- a/recipes-core/packagegroups/nativesdk-packagegroup-sdk-host.bbappend
+++ b/recipes-core/packagegroups/nativesdk-packagegroup-sdk-host.bbappend
@@ -1,4 +1,5 @@
 RDEPENDS_${PN}_mingw32 = "\
 nativesdk-pkgconfig \
 nativesdk-libtool \
+nativesdk-qemu \
 "
-- 
2.7.4

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

[yocto] [meta-mingw][PATCH 0/1 Add QEMU to SDK

2018-04-18 Thread Juro Bystricky

Now that we can build QEMU for mingw, also include it in the SDK.
We have been able to build QEMU for Windows for a while now, but only
via a standalone recipe. QEMU has never been a part of SDK (as we were not
able to build it). The Autobuilder does test SDK build for mingw, but
does not test building of QEMU. Any QEMU build breakage (and there are 
occasional
ones) went unnoticed for periods of time and then we usually needed to bisect
the commits to find the culprit that broke the build.
So including QEMU in the SDK will have a nice sideffect: building QEMU will be 
tested
by the Autobuilder as well


Juro Bystricky (1):
  nativesdk-packagegroup-sdk-host: add qemu to SDK

 recipes-core/packagegroups/nativesdk-packagegroup-sdk-host.bbappend | 1 +
 1 file changed, 1 insertion(+)

-- 
2.7.4

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

Re: [yocto] [meta-cgl][PATCH 0/5][RFC] CGL cleanup

2018-04-18 Thread Adrian Dudau

On mån, 2018-04-16 at 08:03 -0700, Armin Kuster wrote:
> I understand some of these changes a harsh. This set of changes allow
> this layer to pass the
> yocto-check-layer. This is one of many options to address passing.
>

Hi Armin,

Thanks for doing this. The series is good, and I merged it with some
minor changes, see below.

I also fixed the LAYERSERIES_COMPAT issue in meta-cgl-common so you
won't have to resend that series.

Regards,
--Adrian



> Armin Kuster (5):
>   meta-cgl-fsl-ppc: drop layer supporting old kernel

This patch didn't apply without your patches from the
LAYERSERIES_COMPAT series which wasn't correct. I was going to drop the
layer anyways, so I did it in a separate commit to simplify things.

>   Corosync: remove recipe its in meta-networking.
>   makedumpfile: remove as its in meta-oe
>   iscsi-initiator-utils: drop bbappends
>   meta-cge-common: Add README

Fixed typo in subject.

>
>  meta-cgl-common/README | 138
> ++
>  .../corosync/build-cleanup-configure-ac.patch  |  57 
>  .../corosync/corosync/corosync-docs.patch  |  37 -
>  .../corosync/corosync/corosync-notifyd.service |  13 --
>  .../recipes-cgl/corosync/corosync/corosync.init| 160 -
> 
>  .../recipes-cgl/corosync/corosync/corosync.service |  26 
>  .../corosync/corosync/fix-define-semun-union.patch |  20 ---
>  .../corosync/corosync/groff-desc-path.patch|  12 --
>  .../recipes-cgl/corosync/corosync/notifyd.init | 120 -
> ---
>  .../recipes-cgl/corosync/corosync/volatiles|   1 -
>  .../recipes-cgl/corosync/corosync_1.4.8.bb |  88 -
> ---
>  .../files/alias-powerpc-powerpc32.patch|  18 ---
>  .../recipes-cgl/makedumpfile/makedumpfile_1.5.8.bb |  20 ---
>  .../iscsi-initiator-utils_%.bbappend   |   1 -
>  meta-cgl-fsl-ppc/conf/layer.conf   |  14 --
>  ...p-inherit-auth-capable-on-INIT-collisions.patch |  41 --
>  ...erpc-Fix-64-bit-builds-with-binutils-2.24.patch |  80 ---
>  .../linux/linux-qoriq-cgl-prt_3.12.bb  |  36 -
>  18 files changed, 138 insertions(+), 744 deletions(-)
>  create mode 100644 meta-cgl-common/README
>  delete mode 100644 meta-cgl-common/recipes-
> cgl/corosync/corosync/build-cleanup-configure-ac.patch
>  delete mode 100644 meta-cgl-common/recipes-
> cgl/corosync/corosync/corosync-docs.patch
>  delete mode 100644 meta-cgl-common/recipes-
> cgl/corosync/corosync/corosync-notifyd.service
>  delete mode 100644 meta-cgl-common/recipes-
> cgl/corosync/corosync/corosync.init
>  delete mode 100644 meta-cgl-common/recipes-
> cgl/corosync/corosync/corosync.service
>  delete mode 100644 meta-cgl-common/recipes-
> cgl/corosync/corosync/fix-define-semun-union.patch
>  delete mode 100644 meta-cgl-common/recipes-
> cgl/corosync/corosync/groff-desc-path.patch
>  delete mode 100644 meta-cgl-common/recipes-
> cgl/corosync/corosync/notifyd.init
>  delete mode 100644 meta-cgl-common/recipes-
> cgl/corosync/corosync/volatiles
>  delete mode 100644 meta-cgl-common/recipes-
> cgl/corosync/corosync_1.4.8.bb
>  delete mode 100644 meta-cgl-common/recipes-
> cgl/makedumpfile/files/alias-powerpc-powerpc32.patch
>  delete mode 100644 meta-cgl-common/recipes-
> cgl/makedumpfile/makedumpfile_1.5.8.bb
>  delete mode 100644 meta-cgl-common/recipes-extended/iscsi-initiator-
> utils/iscsi-initiator-utils_%.bbappend
>  delete mode 100644 meta-cgl-fsl-ppc/conf/layer.conf
>  delete mode 100644 meta-cgl-fsl-ppc/recipes-kernel/linux/files/Fix-
> CVE-2014-5077-sctp-inherit-auth-capable-on-INIT-collisions.patch
>  delete mode 100644 meta-cgl-fsl-ppc/recipes-
> kernel/linux/files/powerpc-Fix-64-bit-builds-with-binutils-2.24.patch
>  delete mode 100644 meta-cgl-fsl-ppc/recipes-kernel/linux/linux-
> qoriq-cgl-prt_3.12.bb
>
> --
> 2.7.4
>

This message, including attachments, is CONFIDENTIAL. It may also be privileged 
or otherwise protected by law. If you received this email by mistake please let 
us know by reply and then delete it from your system; you should not copy it or 
disclose its contents to anyone. All messages sent to and from Enea may be 
monitored to ensure compliance with internal policies and to protect our 
business. Emails are not secure and cannot be guaranteed to be error free as 
they can be intercepted, a mended, lost or destroyed, or contain viruses. The 
sender therefore does not accept liability for any errors or omissions in the 
contents of this message, which arise as a result of email transmission. Anyone 
who communicates with us by email accepts these risks.
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

[yocto] How to patch a file in mysql recipe

2018-04-18 Thread Greg Wilson-Lindberg

I need to patch the my.cnf file that is part of the mysql/mariadb recipe. It 
lives in meta-openembedded/meta-oe/recipes-support/mysql/mariadb/my.cnf with 
the mariadb_5.5.52.bb file one level down.

I've set up a mariadb_5.5.52.bbappend file as:

FILESEXTRAPATHS_prepend := "${FILE_DIRNAME}/${PN}:"

SRC_URI += "file://my.cnf.patch"

# need to enable auto startup
SYSTEMD_AUTO_ENABLE_${PN}-server = "enable"


bitbake finds the my.cnf.patch file but reports that it can't find the my.cnf 
file to patch. I've set up patching of files that are downloaded as part of a 
source tree, but never tried to patch a file that is part of a recipe, and 
apparently I'm missing something. Is it possible to do this, and if so, can 
someone point out what I need to do to do it correctly?
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] Extensible SDK and DEFAULT_PREFERENCE

2018-04-18 Thread Andrea Galbusera

On Wed, Apr 18, 2018 at 2:41 PM, Martin Siegumfeldt  wrote:
> Hi,
>
> I am having a number of recipes residing in two versions, some (development 
> versions) being down-prioritized using:
>
> DEFAULT_PREFERENCE = "-1"
>
>
> The source code is hosted at a private git repository, and the git version is 
> selected using 'AUTOREV'. The extensible SDK renders successfully, however 
> the installation (by third party) fails:
>
> Traceback (most recent call last):
>   File "/home/martin/gomspace_sdk/layers/poky/bitbake/lib/bb/data_smart.py", 
> line 412, in DataSmart.expandWithRefs(s='dev+git${SRCPV}', varname='PV'):
>  try:
> >s = __expand_var_regexp__.sub(varparse.var_sub, s)
>  try:
>   File "/home/martin/gomspace_sdk/layers/poky/bitbake/lib/bb/data_smart.py", 
> line 111, in VariableParse.var_sub(match=<_sre.SRE_Match object; span=(7, 
> 15), match='${SRCPV}'>):
>  else:
> >var = self.d.getVarFlag(key, "_content")
>  self.references.add(key)
>   File "/home/martin/gomspace_sdk/layers/poky/bitbake/lib/bb/data_smart.py", 
> line 794, in DataSmart.getVarFlag(var='SRCPV', flag='_content', expand=True, 
> noweakdefault=False, parsing=False):
>  cachename = var + "[" + flag + "]"
> >value = self.expand(value, cachename)
>
>   File "/home/martin/gomspace_sdk/layers/poky/bitbake/lib/bb/data_smart.py", 
> line 436, in DataSmart.expand(s='${@bb.fetch2.get_srcrev(d)}', 
> varname='SRCPV'):
>  def expand(self, s, varname = None):
> >return self.expandWithRefs(s, varname).value
>
>   File "/home/martin/gomspace_sdk/layers/poky/bitbake/lib/bb/data_smart.py", 
> line 426, in DataSmart.expandWithRefs(s='${@bb.fetch2.get_srcrev(d)}', 
> varname='SRCPV'):
>  except Exception as exc:
> >raise ExpansionError(varname, s, exc) from exc
>
> bb.data_smart.ExpansionError: Failure expanding variable SRCPV, expression 
> was ${@bb.fetch2.get_srcrev(d)} which triggered exception FetchError: Fetcher 
> failure: Fetch command export GIT_SSL_CAINFO="/home
> /martin/gomspace_sdk/buildtools/sysroots/x86_64-gomspacesdk-linux/etc/ssl/certs/ca-certificates.crt";
>  export 
> PATH="/home/martin/gomspace_sdk/tmp/work/aarch64-gomspace-linux/libgsisl/fetcheravoidrecurse-r0
> /recipe-sysroot-native/usr/bin/python-native:/home/martin/gomspace_sdk/layers/poky/scripts:/home/martin/gomspace_sdk/tmp/work/aarch64-gomspace-linux/libgsisl/fetcheravoidrecurse-r0/recipe-sysroot-native/u
> sr/bin/aarch64-gomspace-linux:/home/martin/gomspace_sdk/tmp/work/aarch64-gomspace-linux/libgsisl/fetcheravoidrecurse-r0/recipe-sysroot/usr/bin/crossscripts:/home/martin/gomspace_sdk/tmp/work/aarch64-gomsp
> ace-linux/libgsisl/fetcheravoidrecurse-r0/recipe-sysroot-native/usr/sbin:/home/martin/gomspace_sdk/tmp/work/aarch64-gomspace-linux/libgsisl/fetcheravoidrecurse-r0/recipe-sysroot-native/usr/bin:/home/marti
> n/gomspace_sdk/tmp/work/aarch64-gomspace-linux/libgsisl/fetcheravoidrecurse-r0/recipe-sysroot-native/sbin:/home/martin/gomspace_sdk/tmp/work/aarch64-gomspace-linux/libgsisl/fetcheravoidrecurse-r0/recipe-s
> ysroot-native/bin:/home/martin/gomspace_sdk/layers/poky/bitbake/bin:/home/martin/gomspace_sdk/tmp/hosttools";
>  export HOME="/home/martin"; git -c core.fsyncobjectfiles=0 ls-remote 
> ssh://g...@github.com/GomS
> pace/libisl  failed with exit code 128, output:
> Host key verification failed.
> fatal: Could not read from remote repository.
>
>
> Please make sure you have the correct access rights
> and the repository exists.
>
> It is not the intention that third party will ever need access to the 
> development version, and I don't see why the version information is fetched 
> given the reduced priority. Have I encountered an 'undocumented bug' or is 
> there an alternate approach to achieve this?

eSDK and recipes doing AUTOREV are known to not play well (yet). There
is a bug open to address it at
https://bugzilla.yoctoproject.org/show_bug.cgi?id=11350

>
> Thanks,
> Martin
> --
> ___
> yocto mailing list
> yocto@yoctoproject.org
> https://lists.yoctoproject.org/listinfo/yocto
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [linux-yocto] [PATCH 1/2] driver: of: configfs: fix a building warning

2018-04-18 Thread Bruce Ashfield


On 2018-04-18 10:17 AM, meng...@windriver.com wrote:

From: Limeng 

Build kernel for arm64 platform, there is a waring as below:


w/waring/warning/


drivers/of/configfs.c:153:34: note: format string is defined here
   pr_debug("%s: buf=%p max_count=%u\n", __func__,
  ~^
  %lu
Because on arm64 platform, size_t is long unsigned int.
Therefore, change %u into %zu to compatible with arm
and arm64 platform.


Is this a mainline introduced warning, or one that some backported
patches have introduced ? If we've introduced the warning, we need
to log the commit ID that introduced it in this commit message. We
also need to quickly explain why that commit caused the warning.

Same comment for patch 2/2

Bruce



Signed-off-by: Meng Li 
---
  drivers/of/configfs.c | 2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/of/configfs.c b/drivers/of/configfs.c
index c7e999c..8490d9c 100644
--- a/drivers/of/configfs.c
+++ b/drivers/of/configfs.c
@@ -150,7 +150,7 @@ ssize_t cfs_overlay_item_dtbo_read(struct config_item 
*item, void *buf,
  {
struct cfs_overlay_item *overlay = to_cfs_overlay_item(item);
  
-	pr_debug("%s: buf=%p max_count=%u\n", __func__,

+   pr_debug("%s: buf=%p max_count=%zu\n", __func__,
buf, max_count);
  
  	if (overlay->dtbo == NULL)




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

Re: [linux-yocto] [PULL REQUEST v4] Intel Axxia updates to linux-yocto-4.12

2018-04-18 Thread Bruce Ashfield


On 2018-04-18 12:06 PM, Daniel Dragomir wrote:

Hello Bruce!

I made the rebase on top of 4.12.22 tag.

You can pull the patches from
https://github.com/axxia/axxia_yocto_linux_4.12_pull.git


merged!

Bruce



Pull
standard/axxia/base-1.1v4 -> standard/axxia/base
standard/preempt-rt/axxia/base-1.1v4 -> standard/preempt-rt/axxia/base

If you add more patches to standard/(preempt-rt)/axxia/base beforehand
please notify me. I will rebase our changes so you can do a clean,
fast-forward pull.

Thank you,
Daniel Dragomir

Anders Berg (14):
   arm64: dts: Add initial AXM56xx device tree
   arm64: Add Axxia NEMAC Gigabit Ethernet controller
   arm64: dts: Corrected SPI definitions for AXM56xx
   arm64: dts: Added SPI and flash for AXM56xx sim
   arm64: dts: Add VMFS node for simulation DT
   net: ethernet: Enable Axxia FEMAC driver
   arm64: dts: Add device tree for AXC67xx (Lionfish)
   arm64: dts: Fixed bad VMFS reg property
   net: ethernet: Add MDIO driver for LSI AXM55xx
   net: ethernet: Add driver for FEMAC on AXM55xx
   drivers: net: Add Axxia NEMAC driver
   arm64: dts: Add NEMAC device nodes
   net: nemac: Fix crash when using NEMAC from bootloader
   misc: lsi-ncr: Only use AMP lock on PPC platforms.

Charlie Paul (43):
   fs/vmfs: Adding arm vmfs file system
   i2c: Support for i2c to the LSI axxia 5500 board
   drivers/dma: Updated to support Axxia dma
   arch/arm/boot/dts: Files added to support axxia 5500 board
   arch/arm/boot: Changes to support the axxia BSP
   arch/arm/mach-axxia: kernel files to support the mach-axxia
   arch/arm: arm changes to support the axxia BSP
   misc: Changes made to support axxia BSP
   drivers/mtd: Changes to support the axxia BSP
   drivers/net/ethernet: Changes to support the axxia BSP
   drivers/rapidio/devices: Changes to support axxia BSP
   drivers/spi: Changes to support the axxia BSP
   drivers/tty: Changes to support the axxia BSP
   drivers/usb/host: Changes to support the axxia BSP
   arch/arm/mach-axxia: Removed axxia_circular_queue
   arch/arm/mach-axxia: fixed compiler warning
   arch/arm/mach-axxia: fixed NO SMP
   arch/arm/mach-axxia: changed affinity parameter to cpu
   arch/arm/mach-axxia: Reverse checkpatch compatibility
   arch/arm/mach-axxia: Fixed L2 power up failure
   arch/arm/axxia: Remove the axxia zImage.fm build
   drivers/ethernet/lsi: Fixed code to support 4.1
   arm/mach-axxia: Updated to support linux 4.1
   drivers/misc: Updated to support linux 4.1
   drivers/rapidio: Update to support linux 4.9
   drivers/pci: updated to support axxia for 4.9
   drivers/net: Updated to support axxia on 4.9
   driver/net/ethernet: Updated to support axxia on 4.9
   drivers/misc: Updated to support axxia on 4.9
   drivers/i2c/busses: Updated to support axxia on 4.9
   arch/arm/mach-axxia: Updated to support 4.9 on the 5500
   i2c/busses: Updated to support 4.9 on the 5500
   drivers/net: Updated to support 4.9 on the 5500
   boot/dts/axxia: Updated to support 4.9 on the 5500
   arm/mach-axxia: allow interupts (16-32) set to LOW
   drivers/usb/core: fix over-current race condition
   drivers/usb/dwc3: Initialize dma for axxia dwc3
   drivers/misc: Add Fault Handling for Axxia
   drivers/edac: Added axxia edac
   drivers/gpio: updated to support axxia gpio
   drivers/net/ethernet: updated nemac for compile
   drivers/usb/dwc3: updated to compile usb dwc3
   linux/amba: added support for pl061.h

Daniel Dragomir (2):
   tools/perf: Correct the hexa value 0x1ULL from opencsd
   Change all LSI references to INTEL Axxia

David Mercado (1):
   kernel/irq/manage.c: Fix irq_set_affinity to allow use with buslocks

Fredrik Markstrom (1):
   usb ehci-ci13612: Enable HCD_BH mode in ci13612

Gary McGee (9):
   mach-axxia: Make AXXIA_NCR_RESET_CHECK a Kconfig Option
   power: reset: preliminary support for Axxia DDR Retention reset
   arch/arm/mach-axxia: Flush TLB
   axxia-reset.c: Use syscon address from device tree
   axxia: enable trng for axc6732-waco and axm5616-victoria
   axxia: generalize driver support for multi-controller PCI/SRIO/SATA
   axxia: enable PCI1/PCI2 controllers in device tree
   drivers/misc/axxia-pei.c: Update PEI Configuration
   drivers/misc/axxia-pei: Update PCIe/sRIO Lane Configuration

Geoff Levand (1):
   arm64: Enable the identity mapping to allow the MMU disabling

John Jacques (142):
   arch/arm64: Correct GIC Physical Address in Axxia
   arch/arm64: Correct GIC Physical Address in Axxia XLF
   axxia: Add dts for Emulation
   mrch/arm64/mach-axxia: Device Tree Updates for Emulation
   axxia: Updated Device Trees for Emulation and Simulation
   arch/arm64: Use SYSROOT If Defined
   arch/arm64: Add Device Tree for Axxia Emulation
   arch/arm64: Axxia Device Tree and Configuration Changes
   arch/arm64: Axxia Device Tree Update
   arch/arm64: Axxia Interrupt Number Updates
   arch/arm64: Update the Axxia Device Tree for Emulation
   arch/arm64: Correct physical addresses for Simulation dts
   arch/arm64: Axxia Device Tree Updates

Re: [yocto] [PATCH 4/4] update_layer.py: move layer validation to update.py (Performance improve)

2018-04-18 Thread Paul Eggleton

On Wednesday, 18 April 2018 11:04:33 PM NZST Robert Yang wrote:
> The utils.setup_django() costs a lot of time, but both update.py and
> update_layer.py calls it, so move layer validation from update_layer.py to
> update.py to avoid calling update_layer.py when possible can save a lot of
> time.

Unfortunately I still can't merge this, as mentioned earlier it breaks 
handling older python 2-bound releases.

Cheers,
Paul

-- 

Paul Eggleton
Intel Open Source Technology Centre


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

Re: [yocto] rocko cmake buld cstdlib:75:15: fatal error: stdlib.h: No such file or directory

2018-04-18 Thread Dennis Menschel

Hi Mans,

Am 18.04.2018 um 06:56 schrieb Måns Zigher:
> Hi Dennis,
> 
> This makes me a bot confused in cmake_do_configure we have
> 
>           -DCMAKE_NO_SYSTEM_FROM_IMPORTED=1 \
>           ${EXTRA_OECMAKE} \
>           -Wno-dev
> 
> I would think that I am using this cmake_do_configure so then the
> -DCMAKE_NO_SYSTEM_FROM_IMPORTED=1 should already be called correct?
> 
> BR
> Mans Zigher

if you use "devtool build" from the extensible SDK to build a recipe
that inherits cmake.bbclass, then the function cmake_do_configure() will
be called implicitly.

But if you manually compile a cmake project with the SDK, then that
function won't be used. If your SDK contains the package
nativesdk-cmake, then the SDK contains the following file:

  $OECORE_NATIVE_SYSROOT/environment-setup.d/cmake.sh

This file will be sourced along with the rest of the SDK and set an
alias for cmake with an SDK-specific toolchain file.

To verify if the option CMAKE_NO_SYSTEM_FROM_IMPORTED has been set by
cmake, you can check if the file CMakeCache.txt (in the build directory)
contains an entry for CMAKE_NO_SYSTEM_FROM_IMPORTED. An alternative way
is to inspect the configuration via ccmake after calling cmake.

Best regards,
Dennis



signature.asc
Description: OpenPGP digital signature
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] [PULL] provide debug sources in externalsrc -dbg packages

2018-04-18 Thread Burton, Ross

This is the wrong list, please submit the patch to
openembedded-c...@lists.openembedded.org.  Also the patches, not just
a link to the patches.

Ross

On 18 April 2018 at 05:14, Vignesh Rajendran (RBEI/ECF3)
 wrote:
> Hi Yocto,
>
>
>
> I have made some changes to fix missing debug sources in -dbg packages while
> using externalsrc.
>
> Please have look and let me know for any changes needed.
>
>
>
> Thanks. :-)
>
>
>
> the changes are available in the git repository at:
>
>
>
> https://git.yoctoproject.org/git/poky-contrib
> vrajendran/externalsrc-debugsrc
>
> http://git.yoctoproject.org/cgit.cgi//log/?h=vrajendran/externalsrc-debugsrc
>
>
>
> Vignesh Rajendran (1):
>
>   package.bbclass: provide debug sources in externalsrc -dbg packages
>
>
>
> meta/classes/externalsrc.bbclass |  3 +++
>
> meta/classes/package.bbclass | 14 +++---
>
> 2 files changed, 14 insertions(+), 3 deletions(-)
>
>
>
> --
>
> 2.7.4
>
>
>
> Mit freundlichen Grüßen / Best regards
>
> Rajendran Vignesh
> RBEI/ECF33
>
> Tel. +91 422 67-65103
>
>
> --
> ___
> yocto mailing list
> yocto@yoctoproject.org
> https://lists.yoctoproject.org/listinfo/yocto
>
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

[yocto] [PULL] provide debug sources in externalsrc -dbg packages

2018-04-18 Thread Vignesh Rajendran (RBEI/ECF3)

Hi Yocto,

I have made some changes to fix missing debug sources in -dbg packages while 
using externalsrc.
Please have look and let me know for any changes needed.

Thanks. :-)

the changes are available in the git repository at:

https://git.yoctoproject.org/git/poky-contrib  vrajendran/externalsrc-debugsrc
http://git.yoctoproject.org/cgit.cgi//log/?h=vrajendran/externalsrc-debugsrc

Vignesh Rajendran (1):
  package.bbclass: provide debug sources in externalsrc -dbg packages

meta/classes/externalsrc.bbclass |  3 +++
meta/classes/package.bbclass | 14 +++---
2 files changed, 14 insertions(+), 3 deletions(-)

--
2.7.4

Mit freundlichen Grüßen / Best regards

Rajendran Vignesh
RBEI/ECF33

Tel. +91 422 67-65103

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

Re: [yocto] Extensible SDK and DEFAULT_PREFERENCE

2018-04-18 Thread Khem Raj

On Wed, Apr 18, 2018 at 5:41 AM, Martin Siegumfeldt  wrote:
> Hi,
>
> I am having a number of recipes residing in two versions, some (development 
> versions) being down-prioritized using:
>
> DEFAULT_PREFERENCE = "-1"
>
>
> The source code is hosted at a private git repository, and the git version is 
> selected using 'AUTOREV'. The extensible SDK renders successfully, however 
> the installation (by third party) fails:
>
> Traceback (most recent call last):
>   File "/home/martin/gomspace_sdk/layers/poky/bitbake/lib/bb/data_smart.py", 
> line 412, in DataSmart.expandWithRefs(s='dev+git${SRCPV}', varname='PV'):
>  try:
> >s = __expand_var_regexp__.sub(varparse.var_sub, s)
>  try:
>   File "/home/martin/gomspace_sdk/layers/poky/bitbake/lib/bb/data_smart.py", 
> line 111, in VariableParse.var_sub(match=<_sre.SRE_Match object; span=(7, 
> 15), match='${SRCPV}'>):
>  else:
> >var = self.d.getVarFlag(key, "_content")
>  self.references.add(key)
>   File "/home/martin/gomspace_sdk/layers/poky/bitbake/lib/bb/data_smart.py", 
> line 794, in DataSmart.getVarFlag(var='SRCPV', flag='_content', expand=True, 
> noweakdefault=False, parsing=False):
>  cachename = var + "[" + flag + "]"
> >value = self.expand(value, cachename)
>
>   File "/home/martin/gomspace_sdk/layers/poky/bitbake/lib/bb/data_smart.py", 
> line 436, in DataSmart.expand(s='${@bb.fetch2.get_srcrev(d)}', 
> varname='SRCPV'):
>  def expand(self, s, varname = None):
> >return self.expandWithRefs(s, varname).value
>
>   File "/home/martin/gomspace_sdk/layers/poky/bitbake/lib/bb/data_smart.py", 
> line 426, in DataSmart.expandWithRefs(s='${@bb.fetch2.get_srcrev(d)}', 
> varname='SRCPV'):
>  except Exception as exc:
> >raise ExpansionError(varname, s, exc) from exc
>
> bb.data_smart.ExpansionError: Failure expanding variable SRCPV, expression 
> was ${@bb.fetch2.get_srcrev(d)} which triggered exception FetchError: Fetcher 
> failure: Fetch command export GIT_SSL_CAINFO="/home
> /martin/gomspace_sdk/buildtools/sysroots/x86_64-gomspacesdk-linux/etc/ssl/certs/ca-certificates.crt";
>  export 
> PATH="/home/martin/gomspace_sdk/tmp/work/aarch64-gomspace-linux/libgsisl/fetcheravoidrecurse-r0
> /recipe-sysroot-native/usr/bin/python-native:/home/martin/gomspace_sdk/layers/poky/scripts:/home/martin/gomspace_sdk/tmp/work/aarch64-gomspace-linux/libgsisl/fetcheravoidrecurse-r0/recipe-sysroot-native/u
> sr/bin/aarch64-gomspace-linux:/home/martin/gomspace_sdk/tmp/work/aarch64-gomspace-linux/libgsisl/fetcheravoidrecurse-r0/recipe-sysroot/usr/bin/crossscripts:/home/martin/gomspace_sdk/tmp/work/aarch64-gomsp
> ace-linux/libgsisl/fetcheravoidrecurse-r0/recipe-sysroot-native/usr/sbin:/home/martin/gomspace_sdk/tmp/work/aarch64-gomspace-linux/libgsisl/fetcheravoidrecurse-r0/recipe-sysroot-native/usr/bin:/home/marti
> n/gomspace_sdk/tmp/work/aarch64-gomspace-linux/libgsisl/fetcheravoidrecurse-r0/recipe-sysroot-native/sbin:/home/martin/gomspace_sdk/tmp/work/aarch64-gomspace-linux/libgsisl/fetcheravoidrecurse-r0/recipe-s
> ysroot-native/bin:/home/martin/gomspace_sdk/layers/poky/bitbake/bin:/home/martin/gomspace_sdk/tmp/hosttools";
>  export HOME="/home/martin"; git -c core.fsyncobjectfiles=0 ls-remote 
> ssh://g...@github.com/GomS
> pace/libisl  failed with exit code 128, output:
> Host key verification failed.
> fatal: Could not read from remote repository.
>
>
> Please make sure you have the correct access rights
> and the repository exists.
>
> It is not the intention that third party will ever need access to the 
> development version, and I don't see why the version information is fetched 
> given the reduced priority. Have I encountered an 'undocumented bug' or is 
> there an alternate approach to achieve this?

AUTOREV is floating dependency, fetcher has to ensure to get a value
for it to populate version strings
before comparing which one to use. you might be able to use BBMASK
effectively to eliminate these
recips from parsers visibility completely.

>
> Thanks,
> Martin
> --
> ___
> yocto mailing list
> yocto@yoctoproject.org
> https://lists.yoctoproject.org/listinfo/yocto
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

[yocto] Need Help for meta-qt5

2018-04-18 Thread Vincent Daanen

Hi,

I have to add Qt5 QtCore libs to my image. I know I must use meta-qt5 but as 
I'm not familiar with qt configuration, I simply do not know how to start !
So can someone help me to configure meta-qt5 to simply build and add QtCore to 
my image ?
Thank you

Vincent


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

Re: [yocto] Connecting to mysql/mariadb

2018-04-18 Thread Martin Hundebøll


Hi Greg,

On 2018-04-17 18:50, Greg Wilson-Lindberg wrote:
I've got a Yocto system that I'm working on that has mysql/mariadb 
configured but I can't connect to it with MySQL Workbench from another 
machine. mariadb is running, the network connection is live, but when I 
try to connect using MySQL Workbench I get an immediate "connection 
refused" response. I've tried user root, & mysql, same response. I'm 
using the default configuration from Yocto, so maybe I'm missing 
something that I should be configuring.



If anybody here has any experience with this I would appreciate any 
enlightenment you can give me.


By default, mysql only listens on local interfaces. To make it listen on 
"external" interfaces also, change the "bind-address" setting in 
/etc/my.cnf on the target, and restart mysql.


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

[linux-yocto] [PULL REQUEST v4] Intel Axxia updates to linux-yocto-4.12

2018-04-18 Thread Daniel Dragomir

Hello Bruce!

I made the rebase on top of 4.12.22 tag.

You can pull the patches from
https://github.com/axxia/axxia_yocto_linux_4.12_pull.git

Pull
standard/axxia/base-1.1v4 -> standard/axxia/base
standard/preempt-rt/axxia/base-1.1v4 -> standard/preempt-rt/axxia/base

If you add more patches to standard/(preempt-rt)/axxia/base beforehand
please notify me. I will rebase our changes so you can do a clean,
fast-forward pull.

Thank you,
Daniel Dragomir

Anders Berg (14):
  arm64: dts: Add initial AXM56xx device tree
  arm64: Add Axxia NEMAC Gigabit Ethernet controller
  arm64: dts: Corrected SPI definitions for AXM56xx
  arm64: dts: Added SPI and flash for AXM56xx sim
  arm64: dts: Add VMFS node for simulation DT
  net: ethernet: Enable Axxia FEMAC driver
  arm64: dts: Add device tree for AXC67xx (Lionfish)
  arm64: dts: Fixed bad VMFS reg property
  net: ethernet: Add MDIO driver for LSI AXM55xx
  net: ethernet: Add driver for FEMAC on AXM55xx
  drivers: net: Add Axxia NEMAC driver
  arm64: dts: Add NEMAC device nodes
  net: nemac: Fix crash when using NEMAC from bootloader
  misc: lsi-ncr: Only use AMP lock on PPC platforms.

Charlie Paul (43):
  fs/vmfs: Adding arm vmfs file system
  i2c: Support for i2c to the LSI axxia 5500 board
  drivers/dma: Updated to support Axxia dma
  arch/arm/boot/dts: Files added to support axxia 5500 board
  arch/arm/boot: Changes to support the axxia BSP
  arch/arm/mach-axxia: kernel files to support the mach-axxia
  arch/arm: arm changes to support the axxia BSP
  misc: Changes made to support axxia BSP
  drivers/mtd: Changes to support the axxia BSP
  drivers/net/ethernet: Changes to support the axxia BSP
  drivers/rapidio/devices: Changes to support axxia BSP
  drivers/spi: Changes to support the axxia BSP
  drivers/tty: Changes to support the axxia BSP
  drivers/usb/host: Changes to support the axxia BSP
  arch/arm/mach-axxia: Removed axxia_circular_queue
  arch/arm/mach-axxia: fixed compiler warning
  arch/arm/mach-axxia: fixed NO SMP
  arch/arm/mach-axxia: changed affinity parameter to cpu
  arch/arm/mach-axxia: Reverse checkpatch compatibility
  arch/arm/mach-axxia: Fixed L2 power up failure
  arch/arm/axxia: Remove the axxia zImage.fm build
  drivers/ethernet/lsi: Fixed code to support 4.1
  arm/mach-axxia: Updated to support linux 4.1
  drivers/misc: Updated to support linux 4.1
  drivers/rapidio: Update to support linux 4.9
  drivers/pci: updated to support axxia for 4.9
  drivers/net: Updated to support axxia on 4.9
  driver/net/ethernet: Updated to support axxia on 4.9
  drivers/misc: Updated to support axxia on 4.9
  drivers/i2c/busses: Updated to support axxia on 4.9
  arch/arm/mach-axxia: Updated to support 4.9 on the 5500
  i2c/busses: Updated to support 4.9 on the 5500
  drivers/net: Updated to support 4.9 on the 5500
  boot/dts/axxia: Updated to support 4.9 on the 5500
  arm/mach-axxia: allow interupts (16-32) set to LOW
  drivers/usb/core: fix over-current race condition
  drivers/usb/dwc3: Initialize dma for axxia dwc3
  drivers/misc: Add Fault Handling for Axxia
  drivers/edac: Added axxia edac
  drivers/gpio: updated to support axxia gpio
  drivers/net/ethernet: updated nemac for compile
  drivers/usb/dwc3: updated to compile usb dwc3
  linux/amba: added support for pl061.h

Daniel Dragomir (2):
  tools/perf: Correct the hexa value 0x1ULL from opencsd
  Change all LSI references to INTEL Axxia

David Mercado (1):
  kernel/irq/manage.c: Fix irq_set_affinity to allow use with buslocks

Fredrik Markstrom (1):
  usb ehci-ci13612: Enable HCD_BH mode in ci13612

Gary McGee (9):
  mach-axxia: Make AXXIA_NCR_RESET_CHECK a Kconfig Option
  power: reset: preliminary support for Axxia DDR Retention reset
  arch/arm/mach-axxia: Flush TLB
  axxia-reset.c: Use syscon address from device tree
  axxia: enable trng for axc6732-waco and axm5616-victoria
  axxia: generalize driver support for multi-controller PCI/SRIO/SATA
  axxia: enable PCI1/PCI2 controllers in device tree
  drivers/misc/axxia-pei.c: Update PEI Configuration
  drivers/misc/axxia-pei: Update PCIe/sRIO Lane Configuration

Geoff Levand (1):
  arm64: Enable the identity mapping to allow the MMU disabling

John Jacques (142):
  arch/arm64: Correct GIC Physical Address in Axxia
  arch/arm64: Correct GIC Physical Address in Axxia XLF
  axxia: Add dts for Emulation
  mrch/arm64/mach-axxia: Device Tree Updates for Emulation
  axxia: Updated Device Trees for Emulation and Simulation
  arch/arm64: Use SYSROOT If Defined
  arch/arm64: Add Device Tree for Axxia Emulation
  arch/arm64: Axxia Device Tree and Configuration Changes
  arch/arm64: Axxia Device Tree Update
  arch/arm64: Axxia Interrupt Number Updates
  arch/arm64: Update the Axxia Device Tree for Emulation
  arch/arm64: Correct physical addresses for Simulation dts
  arch/arm64: Axxia Device Tree Updates for the XLF Platform
  arch/arm64: Axxia Device Tree Update
  arch/arm64: Correct the addresses and interrupt numbers for AXC6700
  irqchip: Ignore bit 17

Re: [yocto] Connecting to mysql/mariadb

2018-04-18 Thread Victor Palacio


Hi Greg,


There are no leads to follow in logs? How about using netstat to check 
if port is really open?


Can you connect locally from a mysql client running in the device 
instead of using it externally?



BTW, verify that the skip-networking paramater is commented in your 
my.cnf file. Maybe networking is disabled by default.



Regards,



El 17/04/18 a las 18:50, Greg Wilson-Lindberg escribió:


I've got a Yocto system that I'm working on that has mysql/mariadb 
configured but I can't connect to it with MySQL Workbench from another 
machine. mariadb is running, the network connection is live, but when 
I try to connect using MySQL Workbench I get an immediate "connection 
refused" response. I've tried user root, & mysql, same response. I'm 
using the default configuration from Yocto, so maybe I'm missing 
something that I should be configuring.



If anybody here has any experience with this I would appreciate any 
enlightenment you can give me.



Thanks in advance,

Greg Wilson-Lindberg






--

Victor M. Palacio Tárrega

vpala...@intemotechnologies.com 

**

*Intemo Technologies- Idetech Europe, S.L.*

Mov.: (+34)  670 03 66 08

Tel: (+34) 93 336 16 51

C/ Montserrat Roig, nº 23, Pol. Ind. Pedrosa

08908 Hospitalet de Llobregat

BARCELONA (SPAIN)

| SmartCards |RFID |NFC |Biometría |

Este correo electrónico puede contener información reservada 
y/o confidencial, destinada exclusivamente para el uso del destinatario. 
Si Vd no es el destinatario o la persona encargada de distribuirlo, no 
está autorizado a copiar o entregar esta comunicación a ninguna otra 
persona. Si ha recibido este correo electrónico por error, le rogamos 
nos lo notifique inmediatamente por  teléfono o por el mismo medio. Gracias.


Privilege/Confidential Information may be contained in this e-mail and 
is intended only for use of the addressee. If you are not  the 
addressee, or the person responsible for delivering it to the person 
addressed, you may not copy or deliver this to anyone else. If you 
receive this e-mail by mistake, please notify us immediately by 
telephone or e-mail. Thank you.


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

[yocto] Extensible SDK and DEFAULT_PREFERENCE

2018-04-18 Thread Martin Siegumfeldt

Hi,

I am having a number of recipes residing in two versions, some (development 
versions) being down-prioritized using:

DEFAULT_PREFERENCE = "-1"


The source code is hosted at a private git repository, and the git version is 
selected using 'AUTOREV'. The extensible SDK renders successfully, however the 
installation (by third party) fails:

Traceback (most recent call last):
  File "/home/martin/gomspace_sdk/layers/poky/bitbake/lib/bb/data_smart.py", 
line 412, in DataSmart.expandWithRefs(s='dev+git${SRCPV}', varname='PV'):
                 try:
    >                s = __expand_var_regexp__.sub(varparse.var_sub, s)
                     try:
  File "/home/martin/gomspace_sdk/layers/poky/bitbake/lib/bb/data_smart.py", 
line 111, in VariableParse.var_sub(match=<_sre.SRE_Match object; span=(7, 15), 
match='${SRCPV}'>):
                 else:
    >                var = self.d.getVarFlag(key, "_content")
                 self.references.add(key)
  File "/home/martin/gomspace_sdk/layers/poky/bitbake/lib/bb/data_smart.py", 
line 794, in DataSmart.getVarFlag(var='SRCPV', flag='_content', expand=True, 
noweakdefault=False, parsing=False):
                     cachename = var + "[" + flag + "]"
    >            value = self.expand(value, cachename)
     
  File "/home/martin/gomspace_sdk/layers/poky/bitbake/lib/bb/data_smart.py", 
line 436, in DataSmart.expand(s='${@bb.fetch2.get_srcrev(d)}', varname='SRCPV'):
         def expand(self, s, varname = None):
    >        return self.expandWithRefs(s, varname).value
     
  File "/home/martin/gomspace_sdk/layers/poky/bitbake/lib/bb/data_smart.py", 
line 426, in DataSmart.expandWithRefs(s='${@bb.fetch2.get_srcrev(d)}', 
varname='SRCPV'):
                 except Exception as exc:
    >                raise ExpansionError(varname, s, exc) from exc
     
bb.data_smart.ExpansionError: Failure expanding variable SRCPV, expression was 
${@bb.fetch2.get_srcrev(d)} which triggered exception FetchError: Fetcher 
failure: Fetch command export GIT_SSL_CAINFO="/home
/martin/gomspace_sdk/buildtools/sysroots/x86_64-gomspacesdk-linux/etc/ssl/certs/ca-certificates.crt";
 export 
PATH="/home/martin/gomspace_sdk/tmp/work/aarch64-gomspace-linux/libgsisl/fetcheravoidrecurse-r0
/recipe-sysroot-native/usr/bin/python-native:/home/martin/gomspace_sdk/layers/poky/scripts:/home/martin/gomspace_sdk/tmp/work/aarch64-gomspace-linux/libgsisl/fetcheravoidrecurse-r0/recipe-sysroot-native/u
sr/bin/aarch64-gomspace-linux:/home/martin/gomspace_sdk/tmp/work/aarch64-gomspace-linux/libgsisl/fetcheravoidrecurse-r0/recipe-sysroot/usr/bin/crossscripts:/home/martin/gomspace_sdk/tmp/work/aarch64-gomsp
ace-linux/libgsisl/fetcheravoidrecurse-r0/recipe-sysroot-native/usr/sbin:/home/martin/gomspace_sdk/tmp/work/aarch64-gomspace-linux/libgsisl/fetcheravoidrecurse-r0/recipe-sysroot-native/usr/bin:/home/marti
n/gomspace_sdk/tmp/work/aarch64-gomspace-linux/libgsisl/fetcheravoidrecurse-r0/recipe-sysroot-native/sbin:/home/martin/gomspace_sdk/tmp/work/aarch64-gomspace-linux/libgsisl/fetcheravoidrecurse-r0/recipe-s
ysroot-native/bin:/home/martin/gomspace_sdk/layers/poky/bitbake/bin:/home/martin/gomspace_sdk/tmp/hosttools";
 export HOME="/home/martin"; git -c core.fsyncobjectfiles=0 ls-remote 
ssh://g...@github.com/GomS
pace/libisl  failed with exit code 128, output:
Host key verification failed.
fatal: Could not read from remote repository.


Please make sure you have the correct access rights
and the repository exists.

It is not the intention that third party will ever need access to the 
development version, and I don't see why the version information is fetched 
given the reduced priority. Have I encountered an 'undocumented bug' or is 
there an alternate approach to achieve this?

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

[linux-yocto] [PATCH 1/2] driver: of: configfs: fix a building warning

2018-04-18 Thread Meng.Li

From: Limeng 

Build kernel for arm64 platform, there is a waring as below:
drivers/of/configfs.c:153:34: note: format string is defined here
  pr_debug("%s: buf=%p max_count=%u\n", __func__,
 ~^
 %lu
Because on arm64 platform, size_t is long unsigned int.
Therefore, change %u into %zu to compatible with arm
and arm64 platform.

Signed-off-by: Meng Li 
---
 drivers/of/configfs.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/of/configfs.c b/drivers/of/configfs.c
index c7e999c..8490d9c 100644
--- a/drivers/of/configfs.c
+++ b/drivers/of/configfs.c
@@ -150,7 +150,7 @@ ssize_t cfs_overlay_item_dtbo_read(struct config_item 
*item, void *buf,
 {
struct cfs_overlay_item *overlay = to_cfs_overlay_item(item);
 
-   pr_debug("%s: buf=%p max_count=%u\n", __func__,
+   pr_debug("%s: buf=%p max_count=%zu\n", __func__,
buf, max_count);
 
if (overlay->dtbo == NULL)
-- 
2.9.3

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

[linux-yocto] [PATCH 2/2] driver: misc: intel-service: schedule thread out when there is no data reveived

2018-04-18 Thread Meng.Li

From: MengLi 

In thread svc_normal_to_secure_thread(), function kfifo_out_spinlocked()
always return, so this thread can't release cpu even if there is no data
received, and cause cpu is under heave load status. System performance
is poor.
Therefore, schedule this thread out when there is no data reveived, and
wake it up after sending data to it.

Signed-off-by: Meng Li 
---
 drivers/misc/intel-service.c | 5 -
 1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/drivers/misc/intel-service.c b/drivers/misc/intel-service.c
index 4c63330..8aa2a24 100644
--- a/drivers/misc/intel-service.c
+++ b/drivers/misc/intel-service.c
@@ -278,6 +278,7 @@ int intel_svc_send(struct intel_svc_chan *chan, void *msg)
ret = kfifo_in_spinlocked(>ctrl->svc_fifo, p_data,
  sizeof(*p_data),
  >ctrl->svc_fifo_lock);
+   wake_up_process(chan->ctrl->task);
 
kfree(p_data);
 
@@ -537,8 +538,10 @@ static int svc_normal_to_secure_thread(void *data)
pdata, sizeof(*pdata),
>svc_fifo_lock);
 
-   if (!ret_fifo)
+   if (!ret_fifo) {
+   schedule_timeout_interruptible(MAX_SCHEDULE_TIMEOUT);
continue;
+   }
 
pr_debug("get from FIFO pa=0x%016x, command=%u, size=%u\n",
 (unsigned int)pdata->paddr, pdata->command,
-- 
2.9.3

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

[linux-yocto] : [yocto-4.12]: intel-socfpga: update patches for Stratix10 platform

2018-04-18 Thread Meng.Li

From: Limeng 


Hi Bruce,

Now, there are 2 below patches to update intel-socfpga, Stratix10 SoC platform.
0001-driver-of-configfs-fix-a-building-warning.patch
0002-driver-misc-intel-service-schedule-thread-out-when-t.patch

Please help to meger the 2 patches into linux-yocto, kernel 4.12, branch is 
standard/base

misc/intel-service.c |5 -
of/configfs.c|2 +-
2 files changed, 5 insertions(+), 2 deletions(-)

thanks,
Limeng


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

Re: [yocto] [PATCH 0/4][layerindex-web] bug fix and performance improve

2018-04-18 Thread Burton, Ross

On 18 April 2018 at 12:04, Robert Yang  wrote:
>   fixup! update: don't stop on unsatisfied layer dependencies

Pretty sure this isn't what you intended.

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

[yocto] [PATCH 4/4] update_layer.py: move layer validation to update.py (Performance improve)

2018-04-18 Thread Robert Yang

The utils.setup_django() costs a lot of time, but both update.py and
update_layer.py calls it, so move layer validation from update_layer.py to
update.py to avoid calling update_layer.py when possible can save a lot of
time.

Now we don't have to call update_layer.py in the following cases:
* The branch doesn't exist
* The layer is already update to date on specified branch (when no
  reload)
* The layer dir or conf/layer.layer doesn't exist

We can save up to 98% time in my testing:

$ update.py -b master --nofetch [--fullreload]

   BeforeNow   Reduced
No update: 276s  3.6s  98%
Partial update:312s  87s   72%
Full repload:  1016s 980s  3%

Note:
* All of the testing are based on --nofetch

* "No update" means all layers on the branch is up-to-date, for
  example, when we run it twice, there is no update in the second run, so we
  only need about 3s now, which is the most common case when we use cron to run
  it per half an hour.

* "Partly update" means part of the layers have been updated.

* "Fullreload" means all of the layers have been updated.

Signed-off-by: Robert Yang 
---
 layerindex/update.py   | 79 +-
 layerindex/update_layer.py | 39 +++
 2 files changed, 82 insertions(+), 36 deletions(-)

diff --git a/layerindex/update.py b/layerindex/update.py
index 44a7b90..2bb2df7 100755
--- a/layerindex/update.py
+++ b/layerindex/update.py
@@ -140,6 +140,15 @@ def fetch_repo(vcs_url, repodir, urldir, fetchdir, 
layer_name):
 logger.error("Fetch of layer %s failed: %s" % (layer_name, e.output))
 return (vcs_url, e.output)
 
+def print_subdir_error(newbranch, layername, vcs_subdir, branchdesc):
+# This will error out if the directory is completely invalid or had never 
existed at this point
+# If it previously existed but has since been deleted, you will get the 
revision where it was
+# deleted - so we need to handle that case separately later
+if newbranch:
+logger.info("Skipping update of layer %s for branch %s - subdirectory 
%s does not exist on this branch" % (layername, branchdesc, vcs_subdir))
+elif vcs_subdir:
+logger.error("Subdirectory for layer %s does not exist on branch %s - 
if this is legitimate, the layer branch record should be deleted" % (layername, 
branchdesc))
+
 def main():
 if LooseVersion(git.__version__) < '0.3.1':
 logger.error("Version of GitPython is too old, please install 
GitPython (python-git) 0.3.1 or later in order to use this script")
@@ -195,7 +204,7 @@ def main():
 
 utils.setup_django()
 import settings
-from layerindex.models import Branch, LayerItem, Update, LayerUpdate
+from layerindex.models import Branch, LayerItem, Update, LayerUpdate, 
LayerBranch
 
 logger.setLevel(options.loglevel)
 
@@ -337,6 +346,74 @@ def main():
 collections.add((layerbranch.collection, 
layerbranch.version))
 
 for layer in layerquery:
+layerbranch = layer.get_layerbranch(branch)
+branchname = branch
+branchdesc = branch
+newbranch = False
+branchobj = utils.get_branch(branch)
+if layerbranch:
+if layerbranch.actual_branch:
+branchname = layerbranch.actual_branch
+branchdesc = "%s (%s)" % (branch, branchname)
+else:
+# LayerBranch doesn't exist for this branch, create it
+newbranch = True
+layerbranch = LayerBranch()
+layerbranch.layer = layer
+layerbranch.branch = branchobj
+layerbranch_source = layer.get_layerbranch(branchobj)
+if not layerbranch_source:
+layerbranch_source = layer.get_layerbranch(None)
+if layerbranch_source:
+layerbranch.vcs_subdir = 
layerbranch_source.vcs_subdir
+
+# Collect repo info
+urldir = layer.get_fetch_dir()
+repodir = os.path.join(fetchdir, urldir)
+repo = git.Repo(repodir)
+assert repo.bare == False
+try:
+if options.nocheckout:
+topcommit = repo.commit('HEAD')
+else:
+topcommit = repo.commit('origin/%s' % branchname)
+except:
+if newbranch:
+logger.info("Skipping update of layer %s - branch 
%s doesn't exist" % (layer.name, branchdesc))
+else:
+logger.info("layer %s - branch

[yocto] [PATCH 3/4] update.py: print failed layers summary in the end

2018-04-18 Thread Robert Yang

This makes it easy to see which layers are failed. For example:

ERROR: Failed layers on branch master: openembedded-core meta-python

Signed-off-by: Robert Yang 
---
 layerindex/update.py | 9 +
 1 file changed, 9 insertions(+)

diff --git a/layerindex/update.py b/layerindex/update.py
index e4ca7b6..44a7b90 100755
--- a/layerindex/update.py
+++ b/layerindex/update.py
@@ -319,6 +319,7 @@ def main():
 # unreliable due to leaking memory (we're using bitbake internals 
in a manner in which
 # they never get used during normal operation).
 last_rev = {}
+failed_layers = {}
 for branch in branches:
 # If layer_A depends(or recommends) on layer_B, add layer_B 
before layer_A
 deps_dict_all = {}
@@ -384,9 +385,12 @@ def main():
 # If nothing changed after a run then some dependencies 
couldn't be resolved
 if operator.eq(deps_dict_all_copy, deps_dict_all):
 logger.warning("Cannot find required collections on 
branch %s:" % branch)
+layer_names = []
 for layer, value in deps_dict_all.items():
 logger.error('%s: %s' % (layer.name, 
value['requires']))
+layer_names.append(layer.name)
 logger.warning("Known collections on branch %s: %s" % 
(branch, collections))
+failed_layers[branch] = layer_names
 break
 
 for layer in layerquery_sorted:
@@ -427,6 +431,11 @@ def main():
 # Interrupted by user, break out of loop
 logger.info('Update interrupted, exiting')
 sys.exit(254)
+if failed_layers:
+print()
+for branch, err_msg_list in failed_layers.items():
+logger.error("Failed layers on branch %s: %s" % (branch, " 
".join(err_msg_list)))
+print()
 finally:
 utils.unlock_file(lockfile)
 
-- 
2.7.4

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

[yocto] [PATCH 2/4] update.py: add an option --timeout for lockfile

2018-04-18 Thread Robert Yang

We have an update.py running perodically in background, but we also need run it
manually, for example, run it to update actual_branch, the manually run usually
failed because can't get lockfile, we have to run it again and again. A timeout
option helps a lot in such a case. Now the following command can make sure we
can run the command successfully:
$ update.py -b master -a actual_branch -t 2000

Signed-off-by: Robert Yang 
---
 layerindex/update.py |  5 -
 layerindex/utils.py  | 14 +++---
 2 files changed, 15 insertions(+), 4 deletions(-)

diff --git a/layerindex/update.py b/layerindex/update.py
index 07240ab..e4ca7b6 100755
--- a/layerindex/update.py
+++ b/layerindex/update.py
@@ -156,6 +156,9 @@ def main():
 parser.add_option("-l", "--layer",
 help = "Specify layers to update (use commas to separate 
multiple). Default is all published layers.",
 action="store", dest="layers")
+parser.add_option("-t", "--timeout",
+help = "Specify timeout in seconds to get layerindex.lock. Default 
is 30 seconds.",
+type="int", action="store", dest="timeout", default=30)
 parser.add_option("-r", "--reload",
 help = "Reload recipe data instead of updating since last update",
 action="store_true", dest="reload")
@@ -265,7 +268,7 @@ def main():
 update.save()
 try:
 lockfn = os.path.join(fetchdir, "layerindex.lock")
-lockfile = utils.lock_file(lockfn)
+lockfile = utils.lock_file(lockfn, options.timeout, logger)
 if not lockfile:
 logger.error("Layer index lock timeout expired")
 sys.exit(1)
diff --git a/layerindex/utils.py b/layerindex/utils.py
index 08a4001..ebcfcaf 100644
--- a/layerindex/utils.py
+++ b/layerindex/utils.py
@@ -309,8 +309,10 @@ class ListHandler(logging.Handler):
 return log
 
 
-def lock_file(fn):
-starttime = time.time()
+def lock_file(fn, timeout=30, logger=None):
+start = time.time()
+last = start
+counter = 1
 while True:
 lock = open(fn, 'w')
 try:
@@ -318,8 +320,14 @@ def lock_file(fn):
 return lock
 except IOError:
 lock.close()
-if time.time() - starttime > 30:
+current = time.time()
+if current - start > timeout:
 return None
+# Print a message in every 5 seconds
+if logger and (current - last > 5):
+last = current
+logger.info('Trying to get lock on %s (tried %s seconds) ...' 
% (fn, (5 * counter)))
+counter += 1
 
 def unlock_file(lock):
 fcntl.flock(lock, fcntl.LOCK_UN)
-- 
2.7.4

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

[yocto] [PATCH 1/4] fixup! update: don't stop on unsatisfied layer dependencies

2018-04-18 Thread Robert Yang

The previous commit broke the layer order, e.g.:
A -> B -> C -> D

The algorithm is checking the dependencies one by one, and until we find D, add
D to layerquery_sorted, and add it "collections", the one in "collections"
means it's dependencies are OK, then C, B and A will check against collections,
so that update_layer.py will update them one by one. The previous commit added
A/B/C/D to collections directly, so that when check against it, all the
dependencies are met, thus broke the layer sorting, and then there would be
failures if we pass layer A to update_layer.py before B, C and D (suppose they
are newly to database). This commit fix the problem.

BTW., why I use collections to record the one whose dependencies are matched,
but not directly use layerquery_sorted, it is because collections contains both
the ones to be added/updated and the ones in database, but layerquery_sorted
only contains the ones to be updated/added.

Signed-off-by: Robert Yang 
---
 layerindex/update.py | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/layerindex/update.py b/layerindex/update.py
index f60b943..07240ab 100755
--- a/layerindex/update.py
+++ b/layerindex/update.py
@@ -348,12 +348,11 @@ def main():
 deps = re.search("^LAYERDEPENDS = \"(.*)\"", output, 
re.M).group(1) or ''
 recs = re.search("^LAYERRECOMMENDS = \"(.*)\"", output, 
re.M).group(1) or ''
 
-collections.add((col, ver))
-
 deps_dict = utils.explode_dep_versions2(bitbakepath, deps 
+ ' ' + recs)
 if len(deps_dict) == 0:
 # No depends, add it firstly
 layerquery_sorted.append(layer)
+collections.add((col, ver))
 continue
 deps_dict_all[layer] = {'requires': deps_dict, 
'collection': col, 'version': ver}
 
@@ -374,6 +373,7 @@ def main():
 # All the depends are in collections:
 del(deps_dict_all[layer])
 layerquery_sorted.append(layer)
+collections.add((value['collection'], 
value['version']))
 
 if not len(deps_dict_all):
 break
-- 
2.7.4

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

[yocto] [PATCH 0/4][layerindex-web] bug fix and performance improve

2018-04-18 Thread Robert Yang

Hi Paul,

The patch 4 can improve a lot on update.py (up to 98%), here is the testing
data, please feel free to give your comments.

$ time update.py -b master --nofetch [--fullreload]

   BeforeNow   Reduced
No update: 276s  3.6s  98%
Partial update:312s  87s   72%
Full repload:  1016s 980s  3%

Note:
* All of the testing are based on --nofetch

* "No update" means all layers on the branch is up-to-date, for
  example, when we run it twice, there is no update in the second run, so we
  only need about 3s now, which is the most common case when we use cron to run
  it per half an hour.

* "Partly update" means part of the layers have been updated.

* "Fullreload" means all of the layers have been updated.

// Robert

The following changes since commit 611c96883c35240d3c291951146154d828745774:

  requirements.txt: use the most recent Django 1.8 version (2018-03-26 08:29:27 
+1300)

are available in the git repository at:

  git://git.pokylinux.org/poky-contrib rbt/layerindex
  http://git.pokylinux.org/cgit.cgi//log/?h=rbt/layerindex

Robert Yang (4):
  fixup! update: don't stop on unsatisfied layer dependencies
  update.py: add an option --timeout for lockfile
  update.py: print failed layers summary in the end
  update_layer.py: move layer validation to update.py (Performance
improve)

 layerindex/update.py   | 97 --
 layerindex/update_layer.py | 39 ++-
 layerindex/utils.py| 14 +--
 3 files changed, 108 insertions(+), 42 deletions(-)

-- 
2.7.4

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

Re: [linux-yocto] [PULL REQUEST v3] Intel Axxia updates to linux-yocto-4.12

2018-04-18 Thread Daniel Dragomir



On 17.04.2018 20:56, Bruce Ashfield wrote:

On 04/12/2018 12:29 PM, Daniel Dragomir wrote:

Hello Bruce!

I made the changes you asked and I ran regression testings on 3 INTEL 
boards

(arm64: cortexa57 and cortexa53; arm: cortexa15).

I attached to the mailing list only the patches I made changes.
I also added a new patch to change all LSI references to INTEL Axxia.

If everything is ok, please pull the patches from
https://github.com/axxia/axxia_yocto_linux_4.12_pull.git
into
git://git.yoctoproject.org/linux-yocto-4.12

Pull
standard/axxia/base-1.1v3 -> standard/axxia/base
standard/preempt-rt/axxia/base-1.1v3 -> standard/preempt-rt/axxia/base

If you add more patches to standard/(preempt-rt)/axxia/base beforehand
please notify me. I will rebase our changes so you can do a clean,
fast-forward pull.


These look ok now.

I just merged the 4.12.22 -stable, can you rebase on top of that
push and re-send the pull request ?

Bruce



Of course. Thank you!

Daniel



Thank you,
Daniel Dragomir

Anders Berg (14):
   arm64: dts: Add initial AXM56xx device tree
   arm64: Add Axxia NEMAC Gigabit Ethernet controller
   arm64: dts: Corrected SPI definitions for AXM56xx
   arm64: dts: Added SPI and flash for AXM56xx sim
   arm64: dts: Add VMFS node for simulation DT
   net: ethernet: Enable Axxia FEMAC driver
   arm64: dts: Add device tree for AXC67xx (Lionfish)
   arm64: dts: Fixed bad VMFS reg property
   net: ethernet: Add MDIO driver for LSI AXM55xx
   net: ethernet: Add driver for FEMAC on AXM55xx
   drivers: net: Add Axxia NEMAC driver
   arm64: dts: Add NEMAC device nodes
   net: nemac: Fix crash when using NEMAC from bootloader
   misc: lsi-ncr: Only use AMP lock on PPC platforms.

Charlie Paul (43):
   fs/vmfs: Adding arm vmfs file system
   i2c: Support for i2c to the LSI axxia 5500 board
   drivers/dma: Updated to support Axxia dma
   arch/arm/boot/dts: Files added to support axxia 5500 board
   arch/arm/boot: Changes to support the axxia BSP
   arch/arm/mach-axxia: kernel files to support the mach-axxia
   arch/arm: arm changes to support the axxia BSP
   misc: Changes made to support axxia BSP
   drivers/mtd: Changes to support the axxia BSP
   drivers/net/ethernet: Changes to support the axxia BSP
   drivers/rapidio/devices: Changes to support axxia BSP
   drivers/spi: Changes to support the axxia BSP
   drivers/tty: Changes to support the axxia BSP
   drivers/usb/host: Changes to support the axxia BSP
   arch/arm/mach-axxia: Removed axxia_circular_queue
   arch/arm/mach-axxia: fixed compiler warning
   arch/arm/mach-axxia: fixed NO SMP
   arch/arm/mach-axxia: changed affinity parameter to cpu
   arch/arm/mach-axxia: Reverse checkpatch compatibility
   arch/arm/mach-axxia: Fixed L2 power up failure
   arch/arm/axxia: Remove the axxia zImage.fm build
   drivers/ethernet/lsi: Fixed code to support 4.1
   arm/mach-axxia: Updated to support linux 4.1
   drivers/misc: Updated to support linux 4.1
   drivers/rapidio: Update to support linux 4.9
   drivers/pci: updated to support axxia for 4.9
   drivers/net: Updated to support axxia on 4.9
   driver/net/ethernet: Updated to support axxia on 4.9
   drivers/misc: Updated to support axxia on 4.9
   drivers/i2c/busses: Updated to support axxia on 4.9
   arch/arm/mach-axxia: Updated to support 4.9 on the 5500
   i2c/busses: Updated to support 4.9 on the 5500
   drivers/net: Updated to support 4.9 on the 5500
   boot/dts/axxia: Updated to support 4.9 on the 5500
   arm/mach-axxia: allow interupts (16-32) set to LOW
   drivers/usb/core: fix over-current race condition
   drivers/usb/dwc3: Initialize dma for axxia dwc3
   drivers/misc: Add Fault Handling for Axxia
   drivers/edac: Added axxia edac
   drivers/gpio: updated to support axxia gpio
   drivers/net/ethernet: updated nemac for compile
   drivers/usb/dwc3: updated to compile usb dwc3
   linux/amba: added support for pl061.h

Daniel Dragomir (2):
   tools/perf: Correct the hexa value 0x1ULL from opencsd
   Change all LSI references to INTEL Axxia

David Mercado (1):
   kernel/irq/manage.c: Fix irq_set_affinity to allow use with buslocks

Fredrik Markstrom (1):
   usb ehci-ci13612: Enable HCD_BH mode in ci13612

Gary McGee (9):
   mach-axxia: Make AXXIA_NCR_RESET_CHECK a Kconfig Option
   power: reset: preliminary support for Axxia DDR Retention reset
   arch/arm/mach-axxia: Flush TLB
   axxia-reset.c: Use syscon address from device tree
   axxia: enable trng for axc6732-waco and axm5616-victoria
   axxia: generalize driver support for multi-controller PCI/SRIO/SATA
   axxia: enable PCI1/PCI2 controllers in device tree
   drivers/misc/axxia-pei.c: Update PEI Configuration
   drivers/misc/axxia-pei: Update PCIe/sRIO Lane Configuration

Geoff Levand (1):
   arm64: Enable the identity mapping to allow the MMU disabling

John Jacques (142):
   arch/arm64: Correct GIC Physical Address in Axxia
   arch/arm64: Correct GIC Physical Address in Axxia XLF
   axxia: Add dts for Emulation
   mrch/arm64/mach-axxia: Device

[yocto] [meta-security][PATCH] xmlsec1: remove host paths from target files

2018-04-18 Thread wenzong.fan

From: Wenzong Fan 

Signed-off-by: Wenzong Fan 
---
 recipes-security/xmlsec1/xmlsec1_1.2.25.bb | 5 -
 1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/recipes-security/xmlsec1/xmlsec1_1.2.25.bb 
b/recipes-security/xmlsec1/xmlsec1_1.2.25.bb
index dbb6f7d..341ca08 100644
--- a/recipes-security/xmlsec1/xmlsec1_1.2.25.bb
+++ b/recipes-security/xmlsec1/xmlsec1_1.2.25.bb
@@ -46,7 +46,10 @@ do_compile_ptest () {
 }
 
 do_install_append() {
-sed -i -e "s@${STAGING_DIR}@@g" ${D}${bindir}/xmlsec1-config
+for i in ${bindir}/xmlsec1-config ${libdir}/xmlsec1Conf.sh \
+${libdir}/pkgconfig/xmlsec1-openssl.pc; do
+sed -i -e "s@${RECIPE_SYSROOT}@@g" ${D}$i
+done
 }
 
 do_install_ptest () {
-- 
2.8.1

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

[linux-yocto] [PATCH 1/2] driver: of: configfs: fix a building warning

[linux-yocto] [v2]: : [yocto-4.12]: intel-socfpga: update patches for Stratix10 platform

Re: [yocto] rocko cmake buld cstdlib:75:15: fatal error: stdlib.h: No such file or directory

Re: [linux-yocto] [PATCH 1/2] driver: of: configfs: fix a building warning

[yocto] [meta-mingw][PATCH 1/1] nativesdk-packagegroup-sdk-host: add qemu to SDK

[yocto] [meta-mingw][PATCH 0/1 Add QEMU to SDK

Re: [yocto] [meta-cgl][PATCH 0/5][RFC] CGL cleanup

[yocto] How to patch a file in mysql recipe

Re: [yocto] Extensible SDK and DEFAULT_PREFERENCE

Re: [linux-yocto] [PATCH 1/2] driver: of: configfs: fix a building warning

Re: [linux-yocto] [PULL REQUEST v4] Intel Axxia updates to linux-yocto-4.12

Re: [yocto] [PATCH 4/4] update_layer.py: move layer validation to update.py (Performance improve)

Re: [yocto] rocko cmake buld cstdlib:75:15: fatal error: stdlib.h: No such file or directory

Re: [yocto] [PULL] provide debug sources in externalsrc -dbg packages

[yocto] [PULL] provide debug sources in externalsrc -dbg packages

Re: [yocto] Extensible SDK and DEFAULT_PREFERENCE

[yocto] Need Help for meta-qt5

Re: [yocto] Connecting to mysql/mariadb

[linux-yocto] [PULL REQUEST v4] Intel Axxia updates to linux-yocto-4.12

Re: [yocto] Connecting to mysql/mariadb

[yocto] Extensible SDK and DEFAULT_PREFERENCE

[linux-yocto] [PATCH 1/2] driver: of: configfs: fix a building warning

[linux-yocto] [PATCH 2/2] driver: misc: intel-service: schedule thread out when there is no data reveived

[linux-yocto] : [yocto-4.12]: intel-socfpga: update patches for Stratix10 platform

Re: [yocto] [PATCH 0/4][layerindex-web] bug fix and performance improve

[yocto] [PATCH 4/4] update_layer.py: move layer validation to update.py (Performance improve)

[yocto] [PATCH 3/4] update.py: print failed layers summary in the end

[yocto] [PATCH 2/4] update.py: add an option --timeout for lockfile

[yocto] [PATCH 1/4] fixup! update: don't stop on unsatisfied layer dependencies

[yocto] [PATCH 0/4][layerindex-web] bug fix and performance improve

Re: [linux-yocto] [PULL REQUEST v3] Intel Axxia updates to linux-yocto-4.12

[yocto] [meta-security][PATCH] xmlsec1: remove host paths from target files

32 matches

Site Navigation

Mail list logo

Footer information