[yocto] Illegal Instruction Generate for Intel Atom

[Chris Trobridge]

This arose building asterisk switching from 13.7 to 13.11+.


The executable core dumps immediately with an illegal instruction instruction, 
which gdb reported as 'andn'.  This is part of BMI1, which was introduced with 
Haswell.  I am targeting a (32-bit) Z5xx Atom processor, which predates this 
instruction.


I don't know what changed in the Asterisk build to cause this (the instruction 
is in some regular compiler generate code) but the compiler is still generating 
legal core2 code and tune-core2.inc is recommended for Atom processors:


"This tune is recommended for the Intel Core 2 CPU family, including Conroe, 
Merom and beyond, as well as the first Atom CPUs, Diamondville, and beyond."


I am still considering this output is down to some quirk in my configuration 
but I found that -mtune and -march options were added for Atom in GCC in 4.5, 
so this could be another line of attack, although I didn't find any explicit 
code for this in meta/meta-intel.


Any ideas?


My initial plan is to try to acoid the core2 tuning and then, if that helps, 
attempt to get atom tuning working, unless that's likely to be cause further 
breakages due to being unexpected.


Regards,

Chris


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

Re: [yocto] Illegal Instruction Generate for Intel Atom

[Leon Woestenberg]

Hello Chris,

Probably unrelated, but yesterday my krogoth build failed on an Atom
*host/build* system. I was just about to debug this when I saw your email.

The configure stage of gmp-native decided to choose -march=k8 and -mtune=k8
-m64. I am debugging this currently.

Maybe check if the asterix recipe tries to be smart in a similar way? And
verify the do_compile log for actual compiler options.

Regards,

Leon.



build/tmp-glibc/work/x86_64-linux/gmp-native/6.1.0-r0

configure:

checking compiler gcc  -O2 -pedantic -fomit-frame-pointer -m64 ... yes
checking compiler gcc  -O2 -pedantic -fomit-frame-pointer -m64
-mtune=k8... yes
checking compiler gcc  -O2 -pedantic -fomit-frame-pointer -m64 -mtune=k8
-march=k8... yes

"-m64 -mtune=k8 -march=k8" on gcc 5.4.0:

x86_64-linux-libtool: compile:  g++ -DHAVE_CONFIG_H -I.
-I../../gmp-6.1.0/cxx -I.. -D__GMP_WITHIN_GMPXX -I../../gmp-6.1.0
-isystem/home/leon/build/tmp-glibc/sysroots/x86_64-linux/usr/include -O2
-pedantic -fomit-frame-pointer -m64 -mtune=k8 -march=k8
-isystem/home/leon/build/tmp-glibc/sysroots/x86_64-linux/usr/include -O2
-pipe -c ../../gmp-6.1.0/cxx/osmpq.cc  -fPIC -DPIC -o .libs/osmpq.o
../x86_64-linux-libtool  --tag=CXX   --mode=compile g++  -DHAVE_CONFIG_H
-I. -I../../gmp-6.1.0/cxx -I..  -D__GMP_WITHIN_GMPXX -I../../gmp-6.1.0
-isystem/home/leon/build/tmp-glibc/sysroots/x86_64-linux/usr/include  -O2
-pedantic -fomit-frame-pointer -m64 -mtune=k8 -march=k8
-isystem/home/leon/build/tmp-glibc/sysroots/x86_64-linux/usr/include -O2
-pipe -c -o osmpz.lo ../../gmp-6.1.0/cxx/osmpz.cc
make[2]: *** [osmpz.lo] Segmentation fault


On Mon, Jan 16, 2017 at 9:46 AM, Chris Trobridge  wrote:

> This arose building asterisk switching from 13.7 to 13.11+.
>
>
> The executable core dumps immediately with an illegal instruction
> instruction, which gdb reported as 'andn'.  This is part of BMI1, which
> was introduced with Haswell.  I am targeting a (32-bit) Z5xx Atom
> processor, which predates this instruction.
>
>
> I don't know what changed in the Asterisk build to cause this (the
> instruction is in some regular compiler generate code) but the compiler is
> still generating legal core2 code and tune-core2.inc is recommended for
> Atom processors:
>
>
> "This tune is recommended for the Intel Core 2 CPU family, including
> Conroe, Merom and beyond, as well as the first Atom CPUs, Diamondville,
> and beyond."
>
>
> I am still considering this output is down to some quirk in my
> configuration but I found that -mtune and -march options were added for
> Atom in GCC in 4.5, so this could be another line of attack, although I
> didn't find any explicit code for this in meta/meta-intel.
>
>
> Any ideas?
>
>
> My initial plan is to try to acoid the core2 tuning and then, if that
> helps, attempt to get atom tuning working, unless that's likely to be cause
> further breakages due to being unexpected.
>
>
> Regards,
>
> Chris
>
>
>
>
> --
> ___
> 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] Debug packages and source files

[Gary Thomas]

In trying to debug my Xorg server problem, I've installed a
number of xxx-dbg packages (using IPK/OPKG).  One thing that
I noticed is that for some of them, e.g. xserver-xorg, I got
a full source tree which works great for debugging with GDB.
Some other packages, e.g. xf86-video-imxfb-vivante which is
the hardware driver for the i.MX6Q display (VPU/GPU) has none :-(

Any ideas why the difference and more importantly, how I might
arrange to get the sources for xf86-video-imxfb-vivante?

Thanks

--

Gary Thomas |  Consulting for the
MLB Associates  |Embedded world

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

Re: [yocto] Illegal Instruction Generate for Intel Atom

[Chris Trobridge]

Thanks Leon,


I agree it is probably an unrelated coincidence.  I am also using morty.


I don't have the logs around any more but the logs had -march=core2 
-mtune-core2 -m32, which was correct for the build.  I did wonder whether the 
asterisk autoconf was too clever but I think in my case it may be more a case 
of the compiler using core2 instructions that are not valid for atom.

Regards,
Chris

From: Leon Woestenberg 
Sent: 16 January 2017 09:57
To: Chris Trobridge
Cc: Yocto List
Subject: Re: [yocto] Illegal Instruction Generate for Intel Atom

Hello Chris,

Probably unrelated, but yesterday my krogoth build failed on an Atom 
*host/build* system. I was just about to debug this when I saw your email.

The configure stage of gmp-native decided to choose -march=k8 and -mtune=k8 
-m64. I am debugging this currently.

Maybe check if the asterix recipe tries to be smart in a similar way? And 
verify the do_compile log for actual compiler options.

Regards,

Leon.



build/tmp-glibc/work/x86_64-linux/gmp-native/6.1.0-r0

configure:

checking compiler gcc  -O2 -pedantic -fomit-frame-pointer -m64 ... yes
checking compiler gcc  -O2 -pedantic -fomit-frame-pointer -m64  -mtune=k8... yes
checking compiler gcc  -O2 -pedantic -fomit-frame-pointer -m64 -mtune=k8  
-march=k8... yes

"-m64 -mtune=k8 -march=k8" on gcc 5.4.0:

x86_64-linux-libtool: compile:  g++ -DHAVE_CONFIG_H -I. -I../../gmp-6.1.0/cxx 
-I.. -D__GMP_WITHIN_GMPXX -I../../gmp-6.1.0 
-isystem/home/leon/build/tmp-glibc/sysroots/x86_64-linux/usr/include -O2 
-pedantic -fomit-frame-pointer -m64 -mtune=k8 -march=k8 
-isystem/home/leon/build/tmp-glibc/sysroots/x86_64-linux/usr/include -O2 -pipe 
-c ../../gmp-6.1.0/cxx/osmpq.cc  -fPIC -DPIC -o .libs/osmpq.o
../x86_64-linux-libtool  --tag=CXX   --mode=compile g++  -DHAVE_CONFIG_H -I. 
-I../../gmp-6.1.0/cxx -I..  -D__GMP_WITHIN_GMPXX -I../../gmp-6.1.0 
-isystem/home/leon/build/tmp-glibc/sysroots/x86_64-linux/usr/include  -O2 
-pedantic -fomit-frame-pointer -m64 -mtune=k8 -march=k8 
-isystem/home/leon/build/tmp-glibc/sysroots/x86_64-linux/usr/include -O2 -pipe 
-c -o osmpz.lo ../../gmp-6.1.0/cxx/osmpz.cc
make[2]: *** [osmpz.lo] Segmentation fault


On Mon, Jan 16, 2017 at 9:46 AM, Chris Trobridge 
> wrote:

This arose building asterisk switching from 13.7 to 13.11+.


The executable core dumps immediately with an illegal instruction instruction, 
which gdb reported as 'andn'.  This is part of BMI1, which was introduced with 
Haswell.  I am targeting a (32-bit) Z5xx Atom processor, which predates this 
instruction.


I don't know what changed in the Asterisk build to cause this (the instruction 
is in some regular compiler generate code) but the compiler is still generating 
legal core2 code and tune-core2.inc is recommended for Atom processors:


"This tune is recommended for the Intel Core 2 CPU family, including Conroe, 
Merom and beyond, as well as the first Atom CPUs, Diamondville, and beyond."


I am still considering this output is down to some quirk in my configuration 
but I found that -mtune and -march options were added for Atom in GCC in 4.5, 
so this could be another line of attack, although I didn't find any explicit 
code for this in meta/meta-intel.


Any ideas?


My initial plan is to try to acoid the core2 tuning and then, if that helps, 
attempt to get atom tuning working, unless that's likely to be cause further 
breakages due to being unexpected.


Regards,

Chris



--
___
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: [yocto] Debugging question

[Burton, Ross]

On 16 January 2017 at 04:29, Gary Thomas  wrote:

> * Any ideas how upgrading the X server now calls into openssl?
>I've bisected this error down to the change in the X server
>recipe to v1.19 from v1.18.4
>

$ grep ssl *
xserver-xorg.inc:XORG_CRYPTO ??= "openssl"
xserver-xorg.inc:PACKAGECONFIG[openssl] = "--with-sha1=libcrypto,,openssl"

The X server took the reasonable approach of refusing to reimplement
cryptographic functions and instead relies on an external library, of which
openssl (well, libcrypto, part of openssl) is one option.

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

Re: [yocto] Debugging question

[Gary Thomas]

On 2017-01-16 11:40, Burton, Ross wrote:


On 16 January 2017 at 04:29, Gary Thomas > wrote:

* Any ideas how upgrading the X server now calls into openssl?
   I've bisected this error down to the change in the X server
   recipe to v1.19 from v1.18.4


$ grep ssl *
xserver-xorg.inc:XORG_CRYPTO ??= "openssl"
xserver-xorg.inc:PACKAGECONFIG[openssl] = "--with-sha1=libcrypto,,openssl"

The X server took the reasonable approach of refusing to reimplement 
cryptographic functions and instead relies on an
external library, of which openssl (well, libcrypto, part of openssl) is one 
option.


Thanks, I missed that.

That said, this wasn't really related to the problem anyway.
libcrypt causes that illegal instruction - on purpose - to
check for certain hardware capabilities and handles it.  Just
running 'continue' in GDB lets the X server get a lot further.

I was able to isolate the problem down to a data structure being
trashed.  I'm not sure yet how/why, but I think there may have
been some important changes that the i.MX6 Vivante hardware
driver isn't currently up to speed on.  Still investigating.

--

Gary Thomas |  Consulting for the
MLB Associates  |Embedded world

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

Re: [yocto] Building on MacOS X

[Burton, Ross]

On 14 January 2017 at 19:45, Roger Smith  wrote:

> Is Building Yocto project on a POSIX system, a desire for the Yocto
> project? It would allow support on all bsd UNIX’s including macOS
>

Making OE itself work isn't rocket science - fix a few Linuxisms in
bitbake, port pseudo to macOS.

The hard bit is then convincing the hundred-odd recipes that are often
Linux-centric if not Linux specific to build under something that isn't
Linux.  My ross/darwin branch (from before the security changes) has a
patch to gmp as 'echo' has different semantics. unlink() has different
error codes between macOS and Linux.  There's a very long tail of
differences that will need patching and testing.

But if this is something you care about, patches welcome!

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

[yocto] [meta-mingw][PATCH 1/7] mingw-64-runtime_3.1.bb: Adapt to SDK_ARCH -> SDK_SYS chanages for crosssdk

[Nathan Rossi]

From: Juro Bystricky 

With the change of crosssdk to use SDK_SYS instead of SDK_ARCH, we need to 
update
the recipe to match the changes in master.

[YOCTO #9281]

Signed-off-by: Juro Bystricky 
---
 recipes-devtools/mingw-w64/nativesdk-mingw-w64-runtime_3.1.0.bb | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/recipes-devtools/mingw-w64/nativesdk-mingw-w64-runtime_3.1.0.bb 
b/recipes-devtools/mingw-w64/nativesdk-mingw-w64-runtime_3.1.0.bb
index ddffcf4180..c4292ad48e 100644
--- a/recipes-devtools/mingw-w64/nativesdk-mingw-w64-runtime_3.1.0.bb
+++ b/recipes-devtools/mingw-w64/nativesdk-mingw-w64-runtime_3.1.0.bb
@@ -24,7 +24,7 @@ PROVIDES += "virtual/nativesdk-${SDK_PREFIX}libc-for-gcc"
 PROVIDES += "virtual/nativesdk-libintl"
 
 STAGINGCC = "gcc-cross-initial-${TARGET_ARCH}"
-STAGINGCC_class-nativesdk = "gcc-crosssdk-initial-${TARGET_ARCH}"
+STAGINGCC_class-nativesdk = "gcc-crosssdk-initial-${SDK_SYS}"
 TOOLCHAIN_OPTIONS = " --sysroot=${STAGING_DIR_TARGET}"
 PATH_prepend = "${STAGING_BINDIR_TOOLCHAIN}.${STAGINGCC}:"
 
-- 
2.11.0

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

[yocto] [meta-mingw][PATCH 5/7] glib-2.0: Clean up unnecessary appends that are resolved in oe-core

[Nathan Rossi]

The changes that are appended for '--enable-include=printf=yes' and
packaging of charset.alias and gthread-2.0.def are handled in oe-core.
Clean up these appends.

Signed-off-by: Nathan Rossi 
---
 recipes-core/glib-2.0/glib-2.0_%.bbappend | 3 ---
 1 file changed, 3 deletions(-)

diff --git a/recipes-core/glib-2.0/glib-2.0_%.bbappend 
b/recipes-core/glib-2.0/glib-2.0_%.bbappend
index 2b9ec53182..398af88d8b 100644
--- a/recipes-core/glib-2.0/glib-2.0_%.bbappend
+++ b/recipes-core/glib-2.0/glib-2.0_%.bbappend
@@ -1,6 +1,3 @@
-EXTRA_OECONF_mingw32 = "--enable-included-printf=yes ${CORECONF}"
-FILES_${PN}_append_mingw32 = " ${libdir}/charset.alias 
${libdir}/gthread-2.0.def"
-
 # glib always provides bash-completion output, package the output but prevent
 # the dependency chain on bash (via bash-completion) for mingw32 targets only.
 RDEPENDS_${PN}-bash-completion_remove_mingw32 = "bash-completion"
-- 
2.11.0

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

[yocto] [meta-mingw][PATCH 6/7] libgcc_%.bbappend: Relocate and package dll's in bindir

[Nathan Rossi]

Relocate and package the dll's provided by libgcc in bindir. It is
convention that on mingw/windows dll files are installed into the
bindir, this is done to avoid issues with search paths and allows for
execution of binaries without the need to point at a libdir.

Signed-off-by: Nathan Rossi 
---
 recipes-devtools/gcc/libgcc_%.bbappend | 8 +++-
 1 file changed, 7 insertions(+), 1 deletion(-)

diff --git a/recipes-devtools/gcc/libgcc_%.bbappend 
b/recipes-devtools/gcc/libgcc_%.bbappend
index dd95317618..2a95d02cad 100644
--- a/recipes-devtools/gcc/libgcc_%.bbappend
+++ b/recipes-devtools/gcc/libgcc_%.bbappend
@@ -1,2 +1,8 @@
-FILES_${PN}_append_mingw32 = " ${base_libdir}/libgcc*.dll"
+FILES_${PN}_append_mingw32 = " ${bindir}/libgcc*.dll"
 FILES_${PN}-dev_append_mingw32 = " ${base_libdir}/libgcc*.a"
+
+do_install_append_mingw32 () {
+   # move the .dll files into bindir
+   install -d ${D}${bindir}
+   mv ${D}${base_libdir}/libgcc*.dll ${D}${bindir}/
+}
-- 
2.11.0

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

[yocto] [meta-mingw][PATCH 0/7] Adding support for building QEMU for Windows

[Nathan Rossi]

This series is paired with a series that is sent for the oe-core meta
layer. That series depends on changes in this series and vice-versa. The
oe-core meta series can be reviewed via:

  https://patchwork.openembedded.org/series/4800/

Additional information about this work can be read in the cover letter
of the above linked series.

The following series fixes a number of issues with compilation of
certain components that are required to build and distribute QEMU. This
series includes:

 * Enabling 'secure-api' for mingw-w64-headers
 * Allow building of shared libraries for gettext
 * Work around to avoid dependency on bash for glib-2.0, and clean up of
   glib-2.0 appends which are resolved in oe-core meta
 * Better packaging of libgcc for easy use on Windows (deploy dll to
   bindir)
 * Enabling build of libfdt in the dtc the recipe, but skipping dtc
   itself

Additionally this series includes an un-merged patch from Juro which is
required for functional building with master of oe-core.

The goal of these changes is to allow for building of QEMU for mingw32
and generating a deployable archive for use on the target.

For convenience this series is also available in the git repository:

  https://github.com/nathanrossi/meta-mingw nrossi/mingw-qemu-v1


Juro Bystricky (1):
  mingw-64-runtime_3.1.bb: Adapt to SDK_ARCH -> SDK_SYS chanages for
crosssdk

Nathan Rossi (6):
  mingw-w64-headers: Add 'secure-api' PACKAGECONFIG
  gettext: Enabling building shared libs/dlls
  glib-2.0_%.bbappend: Prevent a bash dependency via bash-completion
  glib-2.0: Clean up unnecessary appends that are resolved in oe-core
  libgcc_%.bbappend: Relocate and package dll's in bindir
  dtc_%.bbappend: Only build libfdt for mingw32

 recipes-core/dtc/dtc_%.bbappend  | 16 
 recipes-core/gettext/gettext_0.19.%.bbappend |  2 +-
 recipes-core/glib-2.0/glib-2.0_%.bbappend|  5 +++--
 recipes-devtools/gcc/libgcc_%.bbappend   |  8 +++-
 .../mingw-w64/nativesdk-mingw-w64-headers_3.1.0.bb   |  4 
 .../mingw-w64/nativesdk-mingw-w64-runtime_3.1.0.bb   |  2 +-
 6 files changed, 32 insertions(+), 5 deletions(-)
 create mode 100644 recipes-core/dtc/dtc_%.bbappend

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

[yocto] [meta-mingw][PATCH 3/7] gettext: Enabling building shared libs/dlls

[Nathan Rossi]

Enable building of shared libs/dlls for gettext.

Signed-off-by: Nathan Rossi 
---
 recipes-core/gettext/gettext_0.19.%.bbappend | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/recipes-core/gettext/gettext_0.19.%.bbappend 
b/recipes-core/gettext/gettext_0.19.%.bbappend
index efd10d6bb6..d6ecc46f4d 100644
--- a/recipes-core/gettext/gettext_0.19.%.bbappend
+++ b/recipes-core/gettext/gettext_0.19.%.bbappend
@@ -2,5 +2,5 @@ DEPENDS_append_mingw32 = " pthreads-win32"
 LDFLAGS_prepend_mingw32 = " -lpthread "
 
 CFLAGS_append_mingw32 = " -DLIBXML_STATIC"
-EXTRA_OECONF_append_mingw32 = " --enable-threads=windows --enable-static 
--disable-shared "
+EXTRA_OECONF_append_mingw32 = " --enable-threads=windows --enable-static"
 
-- 
2.11.0

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

[yocto] [meta-mingw][PATCH 7/7] dtc_%.bbappend: Only build libfdt for mingw32

[Nathan Rossi]

Whilst building libfdt on mingw32 is functional, building dtc for minw32
is not. This is due to dtc relying on certain POSIX functions as well as
not handling the MSVCRT printf formatting.

This change enables building and installing libfdt only for mingw32,
disabling the build of device-tree-compiler itself.

Signed-off-by: Nathan Rossi 
---
 recipes-core/dtc/dtc_%.bbappend | 16 
 1 file changed, 16 insertions(+)
 create mode 100644 recipes-core/dtc/dtc_%.bbappend

diff --git a/recipes-core/dtc/dtc_%.bbappend b/recipes-core/dtc/dtc_%.bbappend
new file mode 100644
index 00..140693778a
--- /dev/null
+++ b/recipes-core/dtc/dtc_%.bbappend
@@ -0,0 +1,16 @@
+
+do_configure_append_mingw32 () {
+   # don't try to build the other dtc components when installing 
libs
+   sed -i 's/install-lib: all/install-lib: libfdt/g' ${S}/Makefile
+}
+
+do_compile_mingw32 () {
+   oe_runmake libfdt
+}
+
+do_install_mingw32 () {
+   oe_runmake install-lib install-includes
+}
+
+RDEPENDS_${PN}-misc_remove_mingw32 = "bash"
+
-- 
2.11.0

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

Re: [yocto] [meta-selinux] What's the point of refpolicy-minimum?

[Shrikant Bobade]

Hi Joe,

On Thu, Jan 12, 2017 at 8:57 PM, Joe MacDonald 
wrote:
>
> Hi guys,
>
> [Re: [meta-selinux] What's the point of refpolicy-minimum?] On 17.01.12
(Thu 12:57) wenzong fan wrote:
>
> > On 01/10/2017 10:48 PM, Joe MacDonald wrote:
> > >Wenzong / Shrikant,
> > >
> > >I thought I knew the answer to the above question, and maybe my
> > >understanding is still correct, but I think I need to ask it now
anyway.
> > >
> > >I don't use refpolicy-minimum for anything, so when I did the updates
to
> > >refpolicy*_git I didn't even glance at refpolicy-minimum_git.
Wenzong's
> > >change to refpolicy-minimum_2.20161023 (in the same thread as the uprev
> > >of the recipe) piqued my curiosity, so I had a look.  Of course,
> > >refpolicy-minimum_git.bb also needs to be updated (or thrown out), but
> > >now that I'm looking at the recipe I see what seems like conflicting
> > >statements in the recipe:
> > >
> > >   recipes-security/refpolicy/refpolicy-minimum_2.20161023.bb:
> > >
> > > 1 include refpolicy-targeted_${PV}.bb
> > > 2
> > > 3 SUMMARY = "SELinux minimum policy"
> > > 4 DESCRIPTION = "\
> > > 5 This is a minimum reference policy with just core policy
modules, and \
> > > 6 could be used as a base for customizing targeted policy. \
> > > 7 Pretty much everything runs as initrc_t or unconfined_t so all
of the \
> > > 8 domains are unconfined. \
> > > 9 "
> > >
> > >and:
> > >
> > >   recipes-security/refpolicy/refpolicy-targeted_2.20161023.bb:
> > >
> > > 1 SUMMARY = "SELinux targeted policy"
> > > 2 DESCRIPTION = "\
> > > 3 This is the targeted variant of the SELinux reference policy.
Most service \
> > > 4 domains are locked down. Users and admins will login in with
unconfined_t \
> > > 5 domain, so they have the same access to the system as if
SELinux was not \
> > > 6 enabled. \
> > > 7 "
> > >
> > >So now I'm trying to understand what the point of refpolicy-minimum
> > >really is here.  Those of you who are using it, what are you using it
> > >for and what do you expect would be the correct behaviour of a system
> > >running that policy?
> > >
> >
> > I don't have much experience on using the refpolicy-minimum as well.
> >
> > But from the original logs it should be "minimum targeted policy".
> >
> > commit 65675f02e33f5da31ec5dbac7a45849f4952569b
> > Author: Wenzong Fan 
> > Date:   Mon Mar 24 21:07:50 2014 -0400
> >
> > refpolicy: add minimum targeted policy
> >
> > This is a minimum targeted policy with just core policy modules, and
> > could be used as a base for customizing targeted policy.
> > Pretty much everything runs as initrc_t or unconfined_t so all of
the
> > domains are unconfined.
> >
> > Signed-off-by: Wenzong Fan 
> > Signed-off-by: Joe MacDonald 
> >
> >
> > >At the very least, I'm going to remove the 'include [...].bb' from both
> > >'minimum' recipes, as that's completely incorrect, but when I do that I
> > >want to know what anyone using this recipe wants to see from it, so
> > >whatever the 'include' gets replaced with is doing the right thing
> > >(which isn't necessarily what it's doing today).
> >
> > I won't object to make the changes, if you think there should be a
different
> > minimum policy with targeted.
>
> I'm not proposing an alternative, I'm just saying that the statements in
> the descriptions of the recipes seem to conflict.  (And do note that the
> git log you quoted is precisely the text in DESCRIPTION for
> refpolicy-minimum.
>
> What I'm confused by is this in minimum:
>
> > Pretty much everything runs as initrc_t or unconfined_t so all of
the
> > domains are unconfined.
>
> and this in targeted:
>
> > > Most service domains are locked down.
>
> So I guess my question is what is the desired behaviour out of this
> recipe?  If nobody knows and it's not being used, I'm leaning toward a
> 'git rm'-based solution.  :-)
>
> It sounds, though, like Shrikant is using it, so it's of some use, I
> guess.  Shrikant, on the systems you've used the minimum policy, what
> does the policy look like on your running system?  In the current world
> refpolicy-minimum inherits POLICY_TYPE and POLICY_MLS_SENS from
> refpolicy-targeted, is that good / bad / irrelevant to what you're doing
> with it?  If I just rework minimum to remove the include and bring in
> the minimal number of changes to get the policy to load again, is that
> good enough for your purposes?  Do you want to volunteer to test my
> changes for me before I commit them?  :-)

Sure, the rework for minimum to remove the include and minimal no. of
changes to get the policy loading,
seems good to server the expectations from it.
Happy to volunteer  to validate the changes, please advise the location to
fork the in-progress changes. :)

>
> --
> -Joe MacDonald.
> :wq
>
> --
> ___

[yocto] [meta-mingw][PATCH 2/7] mingw-w64-headers: Add 'secure-api' PACKAGECONFIG

[Nathan Rossi]

Add the 'secure-api' PACKAGECONFIG and enable it by default. The
'secure-api' feature enables the secure string functions that are
provided in the MS C Runtime e.g. "strerror_s".

These functions are needed for glib-2.0 compilation.

Signed-off-by: Nathan Rossi 
---
 recipes-devtools/mingw-w64/nativesdk-mingw-w64-headers_3.1.0.bb | 4 
 1 file changed, 4 insertions(+)

diff --git a/recipes-devtools/mingw-w64/nativesdk-mingw-w64-headers_3.1.0.bb 
b/recipes-devtools/mingw-w64/nativesdk-mingw-w64-headers_3.1.0.bb
index 06312d604e..5cd4e34e09 100644
--- a/recipes-devtools/mingw-w64/nativesdk-mingw-w64-headers_3.1.0.bb
+++ b/recipes-devtools/mingw-w64/nativesdk-mingw-w64-headers_3.1.0.bb
@@ -18,6 +18,10 @@ inherit autotools nativesdk
 INHIBIT_DEFAULT_DEPS = "1"
 DEPENDS = ""
 
+PACKAGECONFIG ??= "secure-api"
+
+PACKAGECONFIG[secure-api] = "--enable-secure-api,--disable-secure-api"
+
 do_configure() {
oe_runconf
 }
-- 
2.11.0

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

[yocto] [meta-mingw][PATCH 4/7] glib-2.0_%.bbappend: Prevent a bash dependency via bash-completion

[Nathan Rossi]

Prevent glib-2.0 depending on bash indirectly due to the RDEPEND on
bash-completion. The bash dependency is undesirable due to bash
depending on POSIX compatibility (fork, etc) which is not provided by
MinGW but instead MSYS or CYGWIN.

The glib-2.0 configure does not allow for disabling of bash-completion
output, so instead of disabling the bash-completion bbclass entirely
allow the output to be packaged but remove the
RDEPENDS_${PN}-bash-completion on bash-completion.

Signed-off-by: Nathan Rossi 
---
 recipes-core/glib-2.0/glib-2.0_%.bbappend | 4 
 1 file changed, 4 insertions(+)

diff --git a/recipes-core/glib-2.0/glib-2.0_%.bbappend 
b/recipes-core/glib-2.0/glib-2.0_%.bbappend
index d0531d6f4c..2b9ec53182 100644
--- a/recipes-core/glib-2.0/glib-2.0_%.bbappend
+++ b/recipes-core/glib-2.0/glib-2.0_%.bbappend
@@ -1,2 +1,6 @@
 EXTRA_OECONF_mingw32 = "--enable-included-printf=yes ${CORECONF}"
 FILES_${PN}_append_mingw32 = " ${libdir}/charset.alias 
${libdir}/gthread-2.0.def"
+
+# glib always provides bash-completion output, package the output but prevent
+# the dependency chain on bash (via bash-completion) for mingw32 targets only.
+RDEPENDS_${PN}-bash-completion_remove_mingw32 = "bash-completion"
-- 
2.11.0

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

Re: [yocto] Illegal Instruction Generate for Intel Atom

[Burton, Ross]

On 16 January 2017 at 14:47, Chris Trobridge 
wrote:

> Managed to get the actual compiler lines and the initial args are "-m32
> -march=i586" but there is "-march=native" appended to the end of the line.
>
>
Looks like asterisk itself is adding -march=native, so you'll need to dig
through it's makefiles and work out how to disable it (or just delete them).

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

Re: [yocto] [meta-raspberrypi][PATCH 0/2] Drop kernel versions 4.7 and 4.8

[Paul Barker]

On 16 January 2017 14:51:55 GMT+00:00, Gary Thomas  wrote:
>On 2017-01-16 15:48, Gary Thomas wrote:
>> On 2017-01-16 08:26, Paul Barker wrote:
>>> As discussed recently on the list, we can just keep LTS versions now
>>> that v4.9 is available.
>>>
>>> I'm sending these so anyone who still needs v4.7 or v4.8 can shout
>>> 'stop!' before we remove them.
>>>
>>> Paul Barker (2):
>>>   linux-raspberrypi: Drop v4.7
>>>   linux-raspberrypi: Drop v4.8
>>>
>>>  .../0001-fix-dtbo-rules.patch  | 44
>--
>>>  recipes-kernel/linux/linux-raspberrypi_4.7.bb  |  9 -
>>>  recipes-kernel/linux/linux-raspberrypi_4.8.bb  |  8 
>>>  3 files changed, 61 deletions(-)
>>>  delete mode 100644
>recipes-kernel/linux/linux-raspberrypi-4.7/0001-fix-dtbo-rules.patch
>>>  delete mode 100644 recipes-kernel/linux/linux-raspberrypi_4.7.bb
>>>  delete mode 100644 recipes-kernel/linux/linux-raspberrypi_4.8.bb
>>>
>>
>> +1 at least for 4.7 given that with today's repo I get this:
>>
>> ERROR: linux-raspberrypi-1_4.7.7+gitAUTOINC+c2cbd9c611-r0
>do_kernel_version_sanity_check: Package Version
>> (4.7.7+gitAUTOINC+c2cbd9c611) does not match of kernel being built
>(4.7.10). Please update the PV variable to match the
>> kernel source.
>> ERROR: linux-raspberrypi-1_4.7.7+gitAUTOINC+c2cbd9c611-r0
>do_kernel_version_sanity_check: Function failed:
>> do_kernel_version_sanity_check (log file is located at
>>
>/build/rpi3_2016-09-13/tmp/work/raspberrypi3-amltd-linux-gnueabi/linux-raspberrypi/1_4.7.7+gitAUTOINC+c2cbd9c611-r0/temp/log.do_kernel_version_sanity_check.27925)
>>
>> ERROR: Logfile of failure stored in:
>>
>/build/rpi3_2016-09-13/tmp/work/raspberrypi3-amltd-linux-gnueabi/linux-raspberrypi/1_4.7.7+gitAUTOINC+c2cbd9c611-r0/temp/log.do_kernel_version_sanity_check.27925
>>
>> ERROR: Task
>>
>(/local/poky-cutting-edge/meta-raspberrypi/recipes-kernel/linux/linux-raspberrypi_4.7.bb:do_kernel_version_sanity_check)
>> failed with exit code '1'
>>
>
>
>However, there is this error when I tried to switch to 4.9:
>ERROR: linux-raspberrypi-1_4.9.2+gitAUTOINC+4052b0da7d-r0 do_fetch:
>Fetcher failure: Unable to find revision 
>4052b0da7dbab0df22ca8733cf50b3e573e221e0 in branch rpi-4.9.y even from
>upstream
>ERROR: linux-raspberrypi-1_4.9.2+gitAUTOINC+4052b0da7d-r0 do_fetch:
>Fetcher failure for URL: 
>'git://github.com/raspberrypi/linux.git;protocol=git;branch=rpi-4.9.y'.
>Unable to fetch URL from any source.
>ERROR: linux-raspberrypi-1_4.9.2+gitAUTOINC+4052b0da7d-r0 do_fetch:
>Function failed: base_do_fetch
>ERROR: Logfile of failure stored in: 
>/build/rpi3_2016-09-13/tmp/work/raspberrypi3-amltd-linux-gnueabi/linux-raspberrypi/1_4.9.2+gitAUTOINC+4052b0da7d-r0/temp/log.do_fetch.13098
>ERROR: Task
>(/local/poky-cutting-edge/meta-raspberrypi/recipes-kernel/linux/linux-raspberrypi_4.9.bb:do_fetch)
>failed 
>with exit code '1'
>
>Using meta-raspberrypi:e1f69daa805cb02ddd123ae2d4d48035cb5b41d0

I think any upstream branch after 4.4.y is still at risk of being rebased at 
the minute. I think the best solution is to still drop 4.7.y and 4.8.y, but try 
to get an update in for 4.9.y first.


-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

[yocto] bitbake -c menuconfig linux-fslc in a tmux window

[Oliver Graute]

Hello list,

if I start the following command in a tmux window it doesn't work.

bitbake -c menuconfig linux-fslc

if I start this command in a extra gnome-terminal a new gnome-terminal
pops-up and I can configure my kernel related stuff.

in the poky /os-poky/meta/lib/oe/terminal.py there is some code that
indicate that it could be possible that a new tmux-pane should open here.

Some clue why bitbake does not open an extra tmux-pane for me?

I'am using yocto jethro 2.0.2.

Best Regards,

Oliver

NOTE: Executing RunQueue Tasks
ERROR: Error executing a python function in 
/home/graute/5411_IBIS/yocto/os-meta-fsl-arm/recipes-kernel/linux/linux-fslc_4.4.bb:

The stack trace of python calls that resulted in this exception/failure was:
File: 'do_menuconfig', lineno: 25, function: 
 0021:bb.note("Configuration changed, recompile will be forced")
 0022:bb.build.write_taint('do_compile', d)
 0023:
 0024:
 *** 0025:do_menuconfig(d)
 0026:
File: 'do_menuconfig', lineno: 11, function: do_menuconfig
 0007:shutil.copy(".config", ".config.orig")
 0008:except OSError:
 0009:mtime = 0
 0010:
 *** 0011:oe_terminal("/bin/bash -c \"make menuconfig; if [ \$? -ne 0 ]; 
then echo 'Command failed.'; printf 'Press any key to continue... '; read r; 
fi\"", 'linux-fslc Configuration', d)
 0012:
 0013:# FIXME this check can be removed when the minimum bitbake 
version has been bumped
 0014:if hasattr(bb.build, 'write_taint'):
 0015:try:
File: 'terminal.bbclass', lineno: 55, function: oe_terminal
 0051:except oe.terminal.ExecutionError as exc:
 0052:bb.fatal('Unable to spawn terminal %s: %s' % (terminal, 
exc))
 0053:
 0054:try:
 *** 0055:oe.terminal.spawn_preferred(command, title, None, d)
 0056:except oe.terminal.NoSupportedTerminals:
 0057:bb.fatal('No valid terminal found, unable to open devshell')
 0058:except oe.terminal.ExecutionError as exc:
 0059:bb.fatal('Unable to spawn terminal %s: %s' % (terminal, exc))
File: '/home/graute/5411_IBIS/yocto/os-poky/meta/lib/oe/terminal.py', lineno: 
199, function: spawn_preferred
 0195:def spawn_preferred(sh_cmd, title=None, env=None, d=None):
 0196:"""Spawn the first supported terminal, by priority"""
 0197:for terminal in prioritized():
 0198:try:
 *** 0199:spawn(terminal.name, sh_cmd, title, env, d)
 0200:break
 0201:except UnsupportedTerminal:
 0202:continue
 0203:else:
File: '/home/graute/5411_IBIS/yocto/os-poky/meta/lib/oe/terminal.py', lineno: 
214, function: spawn
 0210:terminal = Registry.registry[name]
 0211:except KeyError:
 0212:raise UnsupportedTerminal(name)
 0213:
 *** 0214:pipe = terminal(sh_cmd, title, env, d)
 0215:output = pipe.communicate()[0]
 0216:if pipe.returncode != 0:
 0217:raise ExecutionError(sh_cmd, pipe.returncode, output)
 0218:
File: '/home/graute/5411_IBIS/yocto/os-poky/meta/lib/oe/terminal.py', lineno: 
133, function: __init__
 0129:
 0130:if not os.getenv('TMUX'):
 0131:raise UnsupportedTerminal('tmux is not running')
 0132:
 *** 0133:if not check_tmux_pane_size('tmux'):
 0134:raise UnsupportedTerminal('tmux pane too small')
 0135:
 0136:Terminal.__init__(self, sh_cmd, title, env, d)
 0137:
File: '/home/graute/5411_IBIS/yocto/os-poky/meta/lib/oe/terminal.py', lineno: 
225, function: check_tmux_pane_size
 0221:try:
 0222:p = sub.Popen('%s list-panes -F 
"#{?pane_active,#{pane_height},}"' % tmux,
 0223:shell=True,stdout=sub.PIPE,stderr=sub.PIPE)
 0224:out, err = p.communicate()
 *** 0225:size = int(out.strip())
 0226:except OSError as exc:
 0227:import errno
 0228:if exc.errno == errno.ENOENT:
 0229:return None
Exception: ValueError: invalid literal for int() with base 10: ''

ERROR: Function failed: do_menuconfig
ERROR: Logfile of failure stored in: 
/home/graute/5411_IBIS/yocto/build-imx6ulevk-nand/tmp/work/imx6ulevk-poky-linux-gnueabi/linux-fslc/4.4+gitAUTOINC+4fa9845f9b-r0/temp/log.do_menuconfig.22623
ERROR: Task 4 
(/home/graute/5411_IBIS/yocto/os-meta-fsl-arm/recipes-kernel/linux/linux-fslc_4.4.bb,
 do_menuconfig) failed with exit code '1'

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

Re: [yocto] [meta-raspberrypi][PATCH 0/2] Drop kernel versions 4.7 and 4.8

[Gary Thomas]

On 2017-01-16 08:26, Paul Barker wrote:

As discussed recently on the list, we can just keep LTS versions now
that v4.9 is available.

I'm sending these so anyone who still needs v4.7 or v4.8 can shout
'stop!' before we remove them.

Paul Barker (2):
  linux-raspberrypi: Drop v4.7
  linux-raspberrypi: Drop v4.8

 .../0001-fix-dtbo-rules.patch  | 44 --
 recipes-kernel/linux/linux-raspberrypi_4.7.bb  |  9 -
 recipes-kernel/linux/linux-raspberrypi_4.8.bb  |  8 
 3 files changed, 61 deletions(-)
 delete mode 100644 
recipes-kernel/linux/linux-raspberrypi-4.7/0001-fix-dtbo-rules.patch
 delete mode 100644 recipes-kernel/linux/linux-raspberrypi_4.7.bb
 delete mode 100644 recipes-kernel/linux/linux-raspberrypi_4.8.bb



+1 at least for 4.7 given that with today's repo I get this:

ERROR: linux-raspberrypi-1_4.7.7+gitAUTOINC+c2cbd9c611-r0 do_kernel_version_sanity_check: Package Version 
(4.7.7+gitAUTOINC+c2cbd9c611) does not match of kernel being built (4.7.10). Please update the PV variable to match the 
kernel source.
ERROR: linux-raspberrypi-1_4.7.7+gitAUTOINC+c2cbd9c611-r0 do_kernel_version_sanity_check: Function failed: 
do_kernel_version_sanity_check (log file is located at 
/build/rpi3_2016-09-13/tmp/work/raspberrypi3-amltd-linux-gnueabi/linux-raspberrypi/1_4.7.7+gitAUTOINC+c2cbd9c611-r0/temp/log.do_kernel_version_sanity_check.27925)
ERROR: Logfile of failure stored in: 
/build/rpi3_2016-09-13/tmp/work/raspberrypi3-amltd-linux-gnueabi/linux-raspberrypi/1_4.7.7+gitAUTOINC+c2cbd9c611-r0/temp/log.do_kernel_version_sanity_check.27925
ERROR: Task 
(/local/poky-cutting-edge/meta-raspberrypi/recipes-kernel/linux/linux-raspberrypi_4.7.bb:do_kernel_version_sanity_check) 
failed with exit code '1'



--

Gary Thomas |  Consulting for the
MLB Associates  |Embedded world

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

Re: [yocto] [meta-raspberrypi][PATCH 0/2] Drop kernel versions 4.7 and 4.8

[Gary Thomas]

On 2017-01-16 15:48, Gary Thomas wrote:

On 2017-01-16 08:26, Paul Barker wrote:

As discussed recently on the list, we can just keep LTS versions now
that v4.9 is available.

I'm sending these so anyone who still needs v4.7 or v4.8 can shout
'stop!' before we remove them.

Paul Barker (2):
  linux-raspberrypi: Drop v4.7
  linux-raspberrypi: Drop v4.8

 .../0001-fix-dtbo-rules.patch  | 44 --
 recipes-kernel/linux/linux-raspberrypi_4.7.bb  |  9 -
 recipes-kernel/linux/linux-raspberrypi_4.8.bb  |  8 
 3 files changed, 61 deletions(-)
 delete mode 100644 
recipes-kernel/linux/linux-raspberrypi-4.7/0001-fix-dtbo-rules.patch
 delete mode 100644 recipes-kernel/linux/linux-raspberrypi_4.7.bb
 delete mode 100644 recipes-kernel/linux/linux-raspberrypi_4.8.bb



+1 at least for 4.7 given that with today's repo I get this:

ERROR: linux-raspberrypi-1_4.7.7+gitAUTOINC+c2cbd9c611-r0 
do_kernel_version_sanity_check: Package Version
(4.7.7+gitAUTOINC+c2cbd9c611) does not match of kernel being built (4.7.10). 
Please update the PV variable to match the
kernel source.
ERROR: linux-raspberrypi-1_4.7.7+gitAUTOINC+c2cbd9c611-r0 
do_kernel_version_sanity_check: Function failed:
do_kernel_version_sanity_check (log file is located at
/build/rpi3_2016-09-13/tmp/work/raspberrypi3-amltd-linux-gnueabi/linux-raspberrypi/1_4.7.7+gitAUTOINC+c2cbd9c611-r0/temp/log.do_kernel_version_sanity_check.27925)

ERROR: Logfile of failure stored in:
/build/rpi3_2016-09-13/tmp/work/raspberrypi3-amltd-linux-gnueabi/linux-raspberrypi/1_4.7.7+gitAUTOINC+c2cbd9c611-r0/temp/log.do_kernel_version_sanity_check.27925

ERROR: Task
(/local/poky-cutting-edge/meta-raspberrypi/recipes-kernel/linux/linux-raspberrypi_4.7.bb:do_kernel_version_sanity_check)
failed with exit code '1'




However, there is this error when I tried to switch to 4.9:
ERROR: linux-raspberrypi-1_4.9.2+gitAUTOINC+4052b0da7d-r0 do_fetch: Fetcher failure: Unable to find revision 
4052b0da7dbab0df22ca8733cf50b3e573e221e0 in branch rpi-4.9.y even from upstream
ERROR: linux-raspberrypi-1_4.9.2+gitAUTOINC+4052b0da7d-r0 do_fetch: Fetcher failure for URL: 
'git://github.com/raspberrypi/linux.git;protocol=git;branch=rpi-4.9.y'. Unable to fetch URL from any source.

ERROR: linux-raspberrypi-1_4.9.2+gitAUTOINC+4052b0da7d-r0 do_fetch: Function 
failed: base_do_fetch
ERROR: Logfile of failure stored in: 
/build/rpi3_2016-09-13/tmp/work/raspberrypi3-amltd-linux-gnueabi/linux-raspberrypi/1_4.9.2+gitAUTOINC+4052b0da7d-r0/temp/log.do_fetch.13098
ERROR: Task (/local/poky-cutting-edge/meta-raspberrypi/recipes-kernel/linux/linux-raspberrypi_4.9.bb:do_fetch) failed 
with exit code '1'


Using meta-raspberrypi:e1f69daa805cb02ddd123ae2d4d48035cb5b41d0

--

Gary Thomas |  Consulting for the
MLB Associates  |Embedded world

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

Re: [yocto] Illegal Instruction Generate for Intel Atom

[Chris Trobridge]

Ok,


Rebuilt system the for i586 and asterisk is still the one program to fail, 
still with that illegal andn instruction.  So I can rule out the core2 tuning.


The compiler log is next to useless, as the asterisk build hides the command 
lines but the makeopts files has the following, which seems fair enough:


CC=i586-poky-linux-gcc  -m32 -march=i586 
--sysroot=/home/chris/yocto/build/tmp/sysroots/pokini
HOST_CC=cc
BUILD_CC=cc
CXX=i586-poky-linux-g++  -m32 -march=i586 
--sysroot=/home/chris/yocto/build/tmp/sysroots/pokini

Looking around the web, this illegal andn instruction has come up before - 
possibly to do with using 'native' tuning.  This is over a long period of time 
though, so not very helpful.


Managed to get the actual compiler lines and the initial args are "-m32 
-march=i586" but there is "-march=native" appended to the end of the line.


As noted previously , there have been various issues reported with 
march=native, for a very long time, so I will try to see how to get that 
removed from the build.


Chris



From: Leon Woestenberg 
Sent: 16 January 2017 09:57
To: Chris Trobridge
Cc: Yocto List
Subject: Re: [yocto] Illegal Instruction Generate for Intel Atom

Hello Chris,

Probably unrelated, but yesterday my krogoth build failed on an Atom 
*host/build* system. I was just about to debug this when I saw your email.

The configure stage of gmp-native decided to choose -march=k8 and -mtune=k8 
-m64. I am debugging this currently.

Maybe check if the asterix recipe tries to be smart in a similar way? And 
verify the do_compile log for actual compiler options.

Regards,

Leon.



build/tmp-glibc/work/x86_64-linux/gmp-native/6.1.0-r0

configure:

checking compiler gcc  -O2 -pedantic -fomit-frame-pointer -m64 ... yes
checking compiler gcc  -O2 -pedantic -fomit-frame-pointer -m64  -mtune=k8... yes
checking compiler gcc  -O2 -pedantic -fomit-frame-pointer -m64 -mtune=k8  
-march=k8... yes

"-m64 -mtune=k8 -march=k8" on gcc 5.4.0:

x86_64-linux-libtool: compile:  g++ -DHAVE_CONFIG_H -I. -I../../gmp-6.1.0/cxx 
-I.. -D__GMP_WITHIN_GMPXX -I../../gmp-6.1.0 
-isystem/home/leon/build/tmp-glibc/sysroots/x86_64-linux/usr/include -O2 
-pedantic -fomit-frame-pointer -m64 -mtune=k8 -march=k8 
-isystem/home/leon/build/tmp-glibc/sysroots/x86_64-linux/usr/include -O2 -pipe 
-c ../../gmp-6.1.0/cxx/osmpq.cc  -fPIC -DPIC -o .libs/osmpq.o
../x86_64-linux-libtool  --tag=CXX   --mode=compile g++  -DHAVE_CONFIG_H -I. 
-I../../gmp-6.1.0/cxx -I..  -D__GMP_WITHIN_GMPXX -I../../gmp-6.1.0 
-isystem/home/leon/build/tmp-glibc/sysroots/x86_64-linux/usr/include  -O2 
-pedantic -fomit-frame-pointer -m64 -mtune=k8 -march=k8 
-isystem/home/leon/build/tmp-glibc/sysroots/x86_64-linux/usr/include -O2 -pipe 
-c -o osmpz.lo ../../gmp-6.1.0/cxx/osmpz.cc
make[2]: *** [osmpz.lo] Segmentation fault


On Mon, Jan 16, 2017 at 9:46 AM, Chris Trobridge 
> wrote:

This arose building asterisk switching from 13.7 to 13.11+.


The executable core dumps immediately with an illegal instruction instruction, 
which gdb reported as 'andn'.  This is part of BMI1, which was introduced with 
Haswell.  I am targeting a (32-bit) Z5xx Atom processor, which predates this 
instruction.


I don't know what changed in the Asterisk build to cause this (the instruction 
is in some regular compiler generate code) but the compiler is still generating 
legal core2 code and tune-core2.inc is recommended for Atom processors:


"This tune is recommended for the Intel Core 2 CPU family, including Conroe, 
Merom and beyond, as well as the first Atom CPUs, Diamondville, and beyond."


I am still considering this output is down to some quirk in my configuration 
but I found that -mtune and -march options were added for Atom in GCC in 4.5, 
so this could be another line of attack, although I didn't find any explicit 
code for this in meta/meta-intel.


Any ideas?


My initial plan is to try to acoid the core2 tuning and then, if that helps, 
attempt to get atom tuning working, unless that's likely to be cause further 
breakages due to being unexpected.


Regards,

Chris



--
___
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: [yocto] Illegal Instruction Generate for Intel Atom

[Leon Woestenberg]

Hi Chris,

there is a hint here how you can find out what gcc is actually using; you
could try with and without the -march=native:

http://en.chys.info/2010/04/what-exactly-marchnative-means/

On Mon, Jan 16, 2017 at 3:47 PM, Chris Trobridge  wrote:

> the initial args are "-m32 -march=i586" but there is "-march=native"
> appended to the end of the line.
>

Regards,

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

[yocto] [[PATCH][yocto-autobuilder] 1/2] buildsteps/CreateAutoConf.py: Add support for specify MACHINE by build prop

[Aníbal Limón]

Sometimes is a good idea to could specify a machine to build via a build
property.

Signed-off-by: Aníbal Limón 
---
 .../site-packages/autobuilder/buildsteps/CreateAutoConf.py  | 6 +-
 1 file changed, 5 insertions(+), 1 deletion(-)

diff --git 
a/lib/python2.7/site-packages/autobuilder/buildsteps/CreateAutoConf.py 
b/lib/python2.7/site-packages/autobuilder/buildsteps/CreateAutoConf.py
index 021f542..7915dd5 100644
--- a/lib/python2.7/site-packages/autobuilder/buildsteps/CreateAutoConf.py
+++ b/lib/python2.7/site-packages/autobuilder/buildsteps/CreateAutoConf.py
@@ -174,7 +174,11 @@ class CreateAutoConf(ShellCommand):
 fout = fout + 'baselib = 
\\042${@d.getVar(\\047BASE_LIB_tune-\\047 + (d.getVar(\\047DEFAULTTUNE\\047, 
True) or \\047INVALID\\047), True) or \\047lib\\047}\\042 \n'
 if self.distro == "poky-rt":
 fout = fout + 
'PREFERRED_PROVIDER_virtual/kernel="linux-yocto-rt" \n'
-machine=self.machine
+machine=self.getProperty('custom_machine')
+if machine:
+self.machine = machine
+else:
+machine = self.machine
 if layerversion is not None and int(layerversion) > 1:
 if self.machine == "atom-pc":
 machine = self.machine.replace("atom-pc", "genericx86")
-- 
2.1.4

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

[yocto] [[PATCH][yocto-autobuilder] 2/2] buildset-config.yocto-qa: Add nightly-oe-build-perf-test buildset

[Aníbal Limón]

From: Monserrat Sedeno 

The new nightly-oe-build-perf-test buildset executes the
build-perf-test-wrapper.sh into a worker and publish the results to
specified folder by AB config.

When the performance script finish it sends an notifcation email to
yocto alias users, the worker machine needs to configure the email
addresses for yocto alias.

[YOCTO #9377]

Signed-off-by: Monserrat Sedeno 
Signed-off-by: Aníbal Limón 
---
 .../nightly-oe-build-perf-test.conf| 28 
 config/autobuilder.conf.example|  8 +++
 .../autobuilder/buildsteps/RunOeBuildPerfTest.py   | 78 ++
 .../autobuilder/buildsteps/SendOePerfEmail.py  | 64 ++
 .../buildsteps/TarballOeBuildPerfTest.py   | 33 +
 lib/python2.7/site-packages/autobuilder/config.py  |  2 +-
 6 files changed, 212 insertions(+), 1 deletion(-)
 create mode 100644 buildset-config.yocto-qa/nightly-oe-build-perf-test.conf
 create mode 100644 
lib/python2.7/site-packages/autobuilder/buildsteps/RunOeBuildPerfTest.py
 create mode 100644 
lib/python2.7/site-packages/autobuilder/buildsteps/SendOePerfEmail.py
 create mode 100644 
lib/python2.7/site-packages/autobuilder/buildsteps/TarballOeBuildPerfTest.py

diff --git a/buildset-config.yocto-qa/nightly-oe-build-perf-test.conf 
b/buildset-config.yocto-qa/nightly-oe-build-perf-test.conf
new file mode 100644
index 000..999036d
--- /dev/null
+++ b/buildset-config.yocto-qa/nightly-oe-build-perf-test.conf
@@ -0,0 +1,28 @@
+[nightly-oe-build-perf-test]
+builders: 'example-worker'
+repos: [{'poky':
+{'repourl':'git://git.yoctoproject.org/poky',
+ 'layerversion':{'core':'meta', 'yoctobsp':'meta-yocto-bsp', 
'yocto':'meta-yocto', 'poky':'meta-poky'},
+ 'branch':'master'}}]
+props: [{'machine':{'prop_type':'ChoiceStringParameter',
+   'choices': ['qemux86', 'qemuarm', 'qemumips', 
'qemuppc', 'qemux86-64', 'qemuarm64', 'qemumips64'],
+   'name': 'machine',
+   'label':'Selects machine for performance 
measurement.'}},
+{'create_eventlog':{'prop_type':'ChoiceStringParameter',
+   'choices': ['False', 'True'],
+   'name': 'create_eventlog',
+   'label':'Create Toaster event log as part of image 
creation?:'}}]
+steps: [{'SetDest':{}},
+{'CheckOutLayers': {}},
+{'RunPreamble': {}},
+{'GetDistroVersion' : {'distro': 'poky'}},
+{'CreateAutoConf': {'machine': 'qemux86-64', 'SDKMACHINE' : 'i686',
+'distro': 'poky', 'buildhistory' : True,
+'atextappend' : 'CONNECTIVITY_CHECK_URIS = ""'}},
+{'CreateBBLayersConf': {'buildprovider' : 'yocto'}},
+{'SyncPersistDB' : {'distro' : 'poky'}},
+{'GetBitbakeVersion': {}},
+{'RunOeBuildPerfTest': {}},
+{'TarballOeBuildPerfTest': {}},
+{'SendOePerfEmail': {}},
+]
diff --git a/config/autobuilder.conf.example b/config/autobuilder.conf.example
index 2e42013..2ee11e6 100644
--- a/config/autobuilder.conf.example
+++ b/config/autobuilder.conf.example
@@ -87,3 +87,11 @@ QA_MAIL_SIG = "Multiline\nSig\nLine"
 
 [Buildlogger]
 BUILDLOG_TO_WIKI = False
+
+[Performance]
+PERFORMANCE_PUBLISH_DIR = "/tmp/yocto-autobuilder/performance"
+PERFORMANCE_SEND_EMAIL = "False"
+PERFORMANCE_MAIL_TO = "root@localhost otherperson@localhost"
+PERFORMANCE_MAIL_CC = "buildcc@localhost"
+PERFORMANCE_MAIL_BCC = "buildbcc@localhost"
+PERFORMANCE_MAIL_SIG = "Multiline\nSig\nLine"
diff --git 
a/lib/python2.7/site-packages/autobuilder/buildsteps/RunOeBuildPerfTest.py 
b/lib/python2.7/site-packages/autobuilder/buildsteps/RunOeBuildPerfTest.py
new file mode 100644
index 000..dcc17dd
--- /dev/null
+++ b/lib/python2.7/site-packages/autobuilder/buildsteps/RunOeBuildPerfTest.py
@@ -0,0 +1,78 @@
+import os, datetime, subprocess
+from buildbot.steps.shell import ShellCommand
+from buildbot.process.buildstep import LogLineObserver
+
+from autobuilder.config import PERFORMANCE_PUBLISH_DIR
+
+class OeBuildPerfTestLogLineObserver(LogLineObserver):
+"""
+Scans lines in order to save the oe-buil-perf-test command
+output.
+"""
+
+def _handleLine(self, line):
+if not hasattr(self.step, 'oe_build_perf_test_output'):
+self.step.oe_build_perf_test_output = ""
+self.step.oe_build_perf_test_match = False
+
+# Search for ### Shell environment set up for builds. ### to start
+# capturing.
+if not self.step.oe_build_perf_test_match and line.startswith('###'):
+self.step.oe_build_perf_test_match = True
+
+if self.step.oe_build_perf_test_match:
+self.step.oe_build_perf_test_output += line + '\n'
+
+def outLineReceived(self, line):
+self._handleLine(line)
+
+def errLineReceived(self, line):
+

Re: [yocto] [meta-raspberrypi][PATCH v2] linux-raspberrypi-rt: add

[Andreas Müller]

On Tue, Jan 17, 2017 at 1:12 AM, Trevor Woerner  wrote:
> Hi Paul,
>
> On Thu 2017-01-05 @ 09:59:16 PM, Paul Barker wrote:
>> Also, are you thinking of moving the -rt recipe to the 4.9 series when
>> upstream linux-raspberrypi declares that stable?
>
> I just want to confirm that 4.9 is going to be the next stable series? How do
> we know 4.8 isn't going to be the next stable after 4.4?
> --
Upstream 4.8 is already marked as EOL

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

Re: [yocto] Illegal Instruction Generate for Intel Atom

[Leon Woestenberg]

+Khem

On Mon, Jan 16, 2017 at 4:40 PM, Burton, Ross  wrote:

>
> On 16 January 2017 at 14:47, Chris Trobridge 
> wrote:
>
>> Managed to get the actual compiler lines and the initial args are "-m32
>> -march=i586" but there is "-march=native" appended to the end of the
>> line.
>>
>> Looks like asterisk itself is adding -march=native, so you'll need to dig
> through it's makefiles and work out how to disable it (or just delete them).
>
> Ross
>

That makes me wonder what are the exact rules of processing the command
line options by GCC.

I thought the precedence is:  TUNE >= CPU >= ARCH.

But apparently, multi -march= definitions, is not well defined, or is it?

There is an unanswered similar question here:
https://lists.debian.org/debian-gcc/2015/12/msg00153.html

Regards,

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

Re: [yocto] Illegal Instruction Generate for Intel Atom

[Chris Trobridge]

Thanks Ross,


I came to that conclusion too, and changes to the asterisk build system was 
really always the most likely source of the problem.  On the plus side, I have 
learned a lot more about machine/processor configuration in the bsp layers 
pursuing that dead end.


I went back through the asterisk change notes and at some point in the past 
they decided to use -march=native as a means to produce the best optimised 
code, while still retaining the option to disable this.


There are some more notes from last summer about changing how this is 
configured, and it certainly defaults to enabled since then.  BUILD_NATIVE is 
an option in their 'menuselect' so I need to configure that, as the clean 
solution, rather than just patching their makeopts.


Regards,

Chris


From: Burton, Ross 
Sent: 16 January 2017 15:40
To: Chris Trobridge
Cc: Leon Woestenberg; Yocto List
Subject: Re: [yocto] Illegal Instruction Generate for Intel Atom


On 16 January 2017 at 14:47, Chris Trobridge 
> wrote:

Managed to get the actual compiler lines and the initial args are "-m32 
-march=i586" but there is "-march=native" appended to the end of the line.

Looks like asterisk itself is adding -march=native, so you'll need to dig 
through it's makefiles and work out how to disable it (or just delete them).

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

Re: [yocto] [meta-raspberrypi][PATCH v2] linux-raspberrypi-rt: add

[Trevor Woerner]

Hi Paul,

On Thu 2017-01-05 @ 09:59:16 PM, Paul Barker wrote:
> Also, are you thinking of moving the -rt recipe to the 4.9 series when
> upstream linux-raspberrypi declares that stable?

I just want to confirm that 4.9 is going to be the next stable series? How do
we know 4.8 isn't going to be the next stable after 4.4?
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] Building on MacOS X

[Brian Avery]

Hi,

A couple of comments even though I'm coming late to the discussion.

So, from what I've understood from the above, the main issue with the
docker approach to building a yocto/oe image on the mac is that it was much
slower...  Here's  some numbers that don’t quite agree with that assertion:

I ran a couple of tests, some on my linux box and some on my mac laptop.
The tests involved building core-image-minimal for a qemux86 target. All
the downloads were in place. There was no sstate, parse cache, nor was
there an existing tmp directory before the tests were run.

My linux box has a Intel(R) Xeon(R) CPU E5-2699 v3 @ 2.30GHz , 36 cores.
My mac laptop has a Intel(R) Core(TM) i7-4870HQ CPU @ 2.50GHz.

The test is "$ time bitbake core-image-minimal"

Here are the results of the tests:

Linux box Ubuntu 14.04

clock : 30m24.024

user  : 229m12.324

sys: 20m10.188

—-

Linux box Ubuntu 14.04 running inside docker 1.12.3 using crops/poky:latest

clock : 30m37.66

user  : 231m35.984

sys: 31m20.204


——

Linux box Ubuntu 14.04 running inside docker 1.12.3 using crops/poky:latest

I set the following in my local.conf file:

BB_NUMBER_THREADS=“2”

BB_NUMBER_PARSE_THREADS=“2”

PARALLEL_MAKE=“-j 2”

AND I constrained docker to 2 cpu cores and 8 gb of ram (This is what I
have my mac laptop set to).

clock : 127m8.523

user  : 201m32.468

sys: 19m54.052


—

Mac OSX laptop - running docker 1.12.5 2 cpus, 8gb ram

I set the following in my local.conf file:

BB_NUMBER_THREADS=“2”

BB_NUMBER_PARSE_THREADS=“2”

PARALLEL_MAKE=“-j 2”


clock : 99m31.190

user  : 137m40.400

sys: 18m38.650


——


So, from the above, it looks like my mac is actually faster when it has the
same number of cores and memory.  I haven’t seen any particular slowdown
with running docker linux programs on the mac other than those caused by
the difference in horsepower between my build server and my laptop.


Thanks,

Brian Avery

an Intel employee


p.s. Andrea, would you mind replying with how you changed the docker run to
make loopback work? I’d like to add it to the docs. Also, if you could
point me at what layers you used to make resin, I’d like to give that a try
as well.  Right now, we are providing a bare bones environment but I’d be
happy to write up a howto for inheriting from our images to customize your
own for special purposes (like doing builds that require loopback mounts,
for instance).







On Mon, Jan 16, 2017 at 3:19 AM, Burton, Ross  wrote:

>
> On 14 January 2017 at 19:45, Roger Smith  wrote:
>
>> Is Building Yocto project on a POSIX system, a desire for the Yocto
>> project? It would allow support on all bsd UNIX’s including macOS
>>
>
> Making OE itself work isn't rocket science - fix a few Linuxisms in
> bitbake, port pseudo to macOS.
>
> The hard bit is then convincing the hundred-odd recipes that are often
> Linux-centric if not Linux specific to build under something that isn't
> Linux.  My ross/darwin branch (from before the security changes) has a
> patch to gmp as 'echo' has different semantics. unlink() has different
> error codes between macOS and Linux.  There's a very long tail of
> differences that will need patching and testing.
>
> But if this is something you care about, patches welcome!
>
> Ross
>
>
>
> --
> ___
> yocto mailing list
> yocto@yoctoproject.org
> https://lists.yoctoproject.org/listinfo/yocto
>
>
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

[linux-yocto] [PATCH 0/3] yocto-kernel-cache: Update ethernet and add NVMe hardware support

[Jussi Laako]

Two first patches modularize and update ethernet driver support by dropping few 
old ones
and adding couple of new ones.

Third patch adds support for NVMe storage devices.

This set of patches targets master-branch of yocto-kernel-cache.

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

[linux-yocto] [PATCH 2/3] Modularize PCI/PCIe ethernet drivers

[Jussi Laako]

Build PCI/PCIe ethernet drivers as modules. Also add some new common
interfaces, mostly gigabit ones.

Signed-off-by: Jussi Laako 
---
 bsp/common-pc/common-pc-eth.cfg | 27 ++-
 1 file changed, 22 insertions(+), 5 deletions(-)

diff --git a/bsp/common-pc/common-pc-eth.cfg b/bsp/common-pc/common-pc-eth.cfg
index b2218447..a7f84e14 100644
--- a/bsp/common-pc/common-pc-eth.cfg
+++ b/bsp/common-pc/common-pc-eth.cfg
@@ -3,16 +3,33 @@
 # resulting bug reports.
 CONFIG_NET_CORE=y
 CONFIG_ETHERNET=y
+CONFIG_NET_VENDOR_3COM=y
+CONFIG_TYPHOON=m
 CONFIG_NET_VENDOR_BROADCOM=y
-CONFIG_TIGON3=y
+CONFIG_TIGON3=m
+CONFIG_BNX2X=m
+CONFIG_BNX2X_SRIOV=y
+CONFIG_BNXT=m
+CONFIG_BNXT_SRIOV=y
 CONFIG_NET_VENDOR_ATHEROS=y
+CONFIG_ATL1=m
+CONFIG_ATL1C=m
+CONFIG_ATL1E=m
 CONFIG_ATL2=m
+CONFIG_ALX=m
 CONFIG_NET_VENDOR_INTEL=y
-CONFIG_E1000=y
+CONFIG_E100=m
+CONFIG_E1000=m
+CONFIG_E1000E=m
 CONFIG_NET_VENDOR_AMD=y
-CONFIG_PCNET32=y
+CONFIG_PCNET32=m
 CONFIG_NET_VENDOR_REALTEK=y
 CONFIG_8139CP=m
 CONFIG_8139TOO=m
-CONFIG_R8169=y
-CONFIG_ATL1E=m
+CONFIG_R8169=m
+CONFIG_NET_VENDOR_DLINK=y
+CONFIG_DL2K=m
+CONFIG_NET_VENDOR_MARVELL=y
+CONFIG_SKGE=m
+CONFIG_SKY2=m
+CONFIG_JME=m
-- 
2.11.0

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

[linux-yocto] [PATCH 3/3] Add support for NVMe storage devices

[Jussi Laako]

Lot of new hardware supports and uses NVMe storage devices, enable
support by default.

Signed-off-by: Jussi Laako 
---
 bsp/common-pc/common-pc-drivers.cfg | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/bsp/common-pc/common-pc-drivers.cfg 
b/bsp/common-pc/common-pc-drivers.cfg
index cea6a99d..a996ef51 100644
--- a/bsp/common-pc/common-pc-drivers.cfg
+++ b/bsp/common-pc/common-pc-drivers.cfg
@@ -66,3 +66,6 @@ CONFIG_I2O_PROC=m
 CONFIG_I2O_SCSI=m
 
 CONFIG_EEPROM_AT24=m
+
+CONFIG_NVME_CORE=y
+CONFIG_BLK_DEV_NVME=y
-- 
2.11.0

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

[linux-yocto] [PATCH 1/3] Modularize USB network drivers

[Jussi Laako]

Build USB network drivers as modules, drop support for some old devices
and add couple of new ones.

Signed-off-by: Jussi Laako 
---
 features/usb-net/usb-net.cfg | 33 +
 1 file changed, 17 insertions(+), 16 deletions(-)

diff --git a/features/usb-net/usb-net.cfg b/features/usb-net/usb-net.cfg
index a5c6a175..59e13f3d 100644
--- a/features/usb-net/usb-net.cfg
+++ b/features/usb-net/usb-net.cfg
@@ -1,24 +1,25 @@
 CONFIG_USB=y
 CONFIG_NET=y
 CONFIG_NETDEVICES=y
-CONFIG_USB_USBNET=y
-CONFIG_USB_KAWETH=y
-CONFIG_USB_PEGASUS=y
-CONFIG_USB_RTL8150=y
-CONFIG_USB_NET_AX8817X=y
-CONFIG_USB_NET_CDCETHER=y
-CONFIG_USB_NET_CDC_NCM=y
-CONFIG_USB_NET_DM9601=y
-CONFIG_USB_NET_SMSC75XX=y
-CONFIG_USB_NET_SMSC95XX=y
-CONFIG_USB_NET_NET1080=y
-CONFIG_USB_NET_MCS7830=y
-CONFIG_USB_NET_CDC_SUBSET=y
+CONFIG_USB_USBNET=m
+CONFIG_USB_NET_DRIVERS=m
+CONFIG_USB_KAWETH=m
+CONFIG_USB_PEGASUS=m
+CONFIG_USB_RTL8150=m
+CONFIG_USB_RTL8152=m
+CONFIG_USB_NET_AX8817X=m
+CONFIG_USB_NET_AX88179_178A=m
+CONFIG_USB_NET_CDCETHER=m
+CONFIG_USB_NET_CDC_EEM=m
+CONFIG_USB_NET_CDC_NCM=m
+CONFIG_USB_NET_DM9601=m
+CONFIG_USB_NET_SMSC75XX=m
+CONFIG_USB_NET_SMSC95XX=m
+CONFIG_USB_NET_MCS7830=m
+CONFIG_USB_NET_CDC_SUBSET_ENABLE=m
+CONFIG_USB_NET_CDC_SUBSET=m
 CONFIG_USB_ALI_M5632=y
 CONFIG_USB_AN2720=y
 CONFIG_USB_BELKIN=y
 CONFIG_USB_ARMLINUX=y
 CONFIG_USB_KC2190=y
-CONFIG_USB_NET_ZAURUS=y
-CONFIG_USB_NET_INT51X1=y
-
-- 
2.11.0

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