[yocto] [meta-security][PATCH 2/2 v2] ecryptfs-utils: add new recipe

2017-05-22 Thread jackie.huang 
From: Jackie Huang 

eCryptfs is a stacked cryptographic filesystem that ships
in Linux kernel versions 2.6.19 and above. This package
provides the mount helper and supporting libraries to
perform key management and mount functions.

Signed-off-by: Jackie Huang 
---
 .../ecryptfs-utils/ecryptfs-utils_111.bb   | 64 +
 .../files/ecryptfs-utils-CVE-2016-6224.patch   | 65 ++
 .../ecryptfs-utils/files/ecryptfs.service  |  9 +++
 3 files changed, 138 insertions(+)
 create mode 100644 recipes-security/ecryptfs-utils/ecryptfs-utils_111.bb
 create mode 100644 
recipes-security/ecryptfs-utils/files/ecryptfs-utils-CVE-2016-6224.patch
 create mode 100644 recipes-security/ecryptfs-utils/files/ecryptfs.service

diff --git a/recipes-security/ecryptfs-utils/ecryptfs-utils_111.bb 
b/recipes-security/ecryptfs-utils/ecryptfs-utils_111.bb
new file mode 100644
index 000..160533a
--- /dev/null
+++ b/recipes-security/ecryptfs-utils/ecryptfs-utils_111.bb
@@ -0,0 +1,64 @@
+SUMMARY = "The eCryptfs mount helper and support libraries"
+DESCRIPTION = "eCryptfs is a stacked cryptographic filesystem \
+that ships in Linux kernel versions 2.6.19 and above. This \
+package provides the mount helper and supporting libraries \
+to perform key management and mount functions."
+HOMEPAGE = "https://launchpad.net/ecryptfs;
+SECTION = "base"
+
+LICENSE = "GPL-2.0"
+LIC_FILES_CHKSUM = "file://COPYING;md5=8ca43cbc842c2336e835926c2166c28b"
+
+DEPENDS = "keyutils libgcrypt intltool-native glib-2.0-native"
+
+SRC_URI = "\
+
https://launchpad.net/ecryptfs/trunk/${PV}/+download/${BPN}_${PV}.orig.tar.gz \
+file://ecryptfs-utils-CVE-2016-6224.patch \
+file://ecryptfs.service \
+"
+
+SRC_URI[md5sum] = "83513228984f671930752c3518cac6fd"
+SRC_URI[sha256sum] = 
"112cb3e37e81a1ecd8e39516725dec0ce55c5f3df6284e0f4cc0f118750a987f"
+
+inherit autotools pkgconfig systemd
+
+SYSTEMD_PACKAGES = "${PN}"
+SYSTEMD_SERVICE_${PN} = "ecryptfs.service"
+
+EXTRA_OECONF = "\
+--libdir=${base_libdir} \
+--disable-pywrap \
+--disable-nls \
+"
+
+PACKAGECONFIG ??= "nss \
+${@bb.utils.filter('DISTRO_FEATURES', 'pam', d)} \
+"
+PACKAGECONFIG[nss] = "--enable-nss,--disable-nss,nss,"
+PACKAGECONFIG[openssl] = "--enable-openssl,--disable-openssl,openssl,"
+PACKAGECONFIG[pam] = "--enable-pam,--disable-pam,libpam,"
+
+do_configure_prepend() {
+export NSS_CFLAGS="-I${STAGING_INCDIR}/nspr4 -I${STAGING_INCDIR}/nss3"
+export NSS_LIBS="-L${STAGING_BASELIBDIR} -lssl3 -lsmime3 -lnss3 -lsoftokn3 
-lnssutil3"
+export KEYUTILS_CFLAGS="-I${STAGING_INCDIR}"
+export KEYUTILS_LIBS="-L${STAGING_LIBDIR} -lkeyutils"
+}
+
+do_install_append() {
+chmod 4755 ${D}${base_sbindir}/mount.ecryptfs_private
+mkdir -p ${D}/${libdir}
+mv ${D}/${base_libdir}/pkgconfig ${D}/${libdir}
+sed -i -e 's:-I${STAGING_INCDIR}::' \
+   -e 's:-L${STAGING_LIBDIR}::' ${D}/${libdir}/pkgconfig/libecryptfs.pc
+sed -i -e "s: ${base_sbindir}/cryptsetup: ${sbindir}/cryptsetup:" 
${D}${bindir}/ecryptfs-setup-swap
+if ${@bb.utils.contains('DISTRO_FEATURES','systemd','true','false',d)}; 
then
+install -d ${D}${systemd_system_unitdir}
+install -m 0644 ${WORKDIR}/ecryptfs.service 
${D}${systemd_system_unitdir}
+fi
+}
+
+FILES_${PN} += "${base_libdir}/security/* ${base_libdir}/ecryptfs/*"
+
+RDEPENDS_${PN} += "cryptsetup"
+RRECOMMENDS_${PN} = "gettext-runtime"
diff --git 
a/recipes-security/ecryptfs-utils/files/ecryptfs-utils-CVE-2016-6224.patch 
b/recipes-security/ecryptfs-utils/files/ecryptfs-utils-CVE-2016-6224.patch
new file mode 100644
index 000..4252f97
--- /dev/null
+++ b/recipes-security/ecryptfs-utils/files/ecryptfs-utils-CVE-2016-6224.patch
@@ -0,0 +1,65 @@
+From 558a513ba3100ea5190de1a24cf1fed663367765 Mon Sep 17 00:00:00 2001
+From: Li Zhou 
+Date: Mon, 5 Sep 2016 10:28:08 +0800
+Subject: [PATCH] ecryptfs-utils: CVE-2016-6224
+
+src/utils/ecryptfs-setup-swap: Prevent unencrypted swap partitions from
+being automatically enabled by systemd. This bug affected GPT partitioned
+NVMe/MMC drives and resulted in the swap partition being used without
+encryption. It also resulted in a usability issue in that users were
+erroneously prompted to enter a pass-phrase to unlock their swap partition
+at boot. (LP: #1597154)
+
+the patch comes from:
+https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2016-6224
+https://bazaar.launchpad.net/~ecryptfs/ecryptfs/trunk/revision/882
+
+Upstream-Status: backport
+
+Signed-off-by: Li Zhou 
+---
+ ChangeLog |  9 +
+ src/utils/ecryptfs-setup-swap | 10 --
+ 2 files changed, 17 insertions(+), 2 deletions(-)
+
+diff --git a/ChangeLog b/ChangeLog
+index d255a94..2c9c73e 100644
+--- a/ChangeLog
 b/ChangeLog
+@@ -1,3 +1,12 @@
++ecryptfs-utils-112
++  [ Jason Gerard DeRose ]
++  *

[yocto] [meta-security][PATCH 1/2 v2] keyutils: add new recipe

2017-05-22 Thread jackie.huang 
From: Jackie Huang 

keyutils is utilities to control the kernel key
management facility and to provide a mechanism by
which the kernel call back to userspace to get a
key instantiated.

It's required by ecryptfs-utils.

Signed-off-by: Jackie Huang 
---
 ...ix-error-report-by-adding-default-message.patch | 42 
 .../files/keyutils-test-fix-output-format.patch| 41 
 .../keyutils-use-relative-path-for-link.patch  | 28 ++
 recipes-security/keyutils/files/run-ptest  |  3 ++
 recipes-security/keyutils/keyutils_1.5.10.bb   | 45 ++
 5 files changed, 159 insertions(+)
 create mode 100644 
recipes-security/keyutils/files/keyutils-fix-error-report-by-adding-default-message.patch
 create mode 100644 
recipes-security/keyutils/files/keyutils-test-fix-output-format.patch
 create mode 100644 
recipes-security/keyutils/files/keyutils-use-relative-path-for-link.patch
 create mode 100755 recipes-security/keyutils/files/run-ptest
 create mode 100644 recipes-security/keyutils/keyutils_1.5.10.bb

diff --git 
a/recipes-security/keyutils/files/keyutils-fix-error-report-by-adding-default-message.patch
 
b/recipes-security/keyutils/files/keyutils-fix-error-report-by-adding-default-message.patch
new file mode 100644
index 000..acd91c0
--- /dev/null
+++ 
b/recipes-security/keyutils/files/keyutils-fix-error-report-by-adding-default-message.patch
@@ -0,0 +1,42 @@
+fix keyutils test error report
+
+Upstream-Status: Pending
+
+"Permission denied" may be the reason of EKEYEXPIRED and EKEYREVOKED.
+"Required key not available" may be the reason of EKEYREVOKED.
+EXPIRED and REVOKED are 2 status of kernel security keys features.
+But the userspace keyutils lib will output the error message, which may
+have several reasons.
+
+Signed-off-by: Han Chao 
+
+diff --git a/tests/toolbox.inc.sh b/tests/toolbox.inc.sh
+index bbca00a..739e9d0 100644
+--- a/tests/toolbox.inc.sh
 b/tests/toolbox.inc.sh
+@@ -227,11 +227,12 @@ function expect_error ()
+   ;;
+   EKEYEXPIRED)
+   my_err="Key has expired"
+-  alt_err="Unknown error 127"
++  alt_err="Permission denied"
+   ;;
+   EKEYREVOKED)
+   my_err="Key has been revoked"
+-  alt_err="Unknown error 128"
++  alt_err="Permission denied"
++  alt2_err="Required key not available"
+   ;;
+   EKEYREJECTED)
+   my_err="Key has been rejected"
+@@ -249,6 +250,9 @@ function expect_error ()
+ elif [ "x$alt_err" != "x" ] && expr "$my_errmsg" : ".*: $alt_err" 
>&/dev/null
+ then
+   :
++elif [ "x$alt2_err" != "x" ] && expr "$my_errmsg" : ".*: $alt2_err" 
>&/dev/null
++then
++  :
+ elif [ "x$old_err" != "x" ] && expr "$my_errmsg" : ".*: $old_err" 
>&/dev/null
+ then
+   :
+
diff --git 
a/recipes-security/keyutils/files/keyutils-test-fix-output-format.patch 
b/recipes-security/keyutils/files/keyutils-test-fix-output-format.patch
new file mode 100644
index 000..a4ffd50
--- /dev/null
+++ b/recipes-security/keyutils/files/keyutils-test-fix-output-format.patch
@@ -0,0 +1,41 @@
+From 49b6321368e4bd3cd233d045cd09004ddd7968b2 Mon Sep 17 00:00:00 2001
+From: Jackie Huang 
+Date: Mon, 15 May 2017 14:52:00 +0800
+Subject: [PATCH] keyutils: fix output format
+
+keyutils ptest output format is incorrect, according to yocto
+Development Manual
+(http://www.yoctoproject.org/docs/latest/dev-manual/dev-manual.html#testing-packages-with-ptest)
+5.10.6. Testing Packages With ptestThe test generates output in the format 
used by Automake:
+: 
+where the result can be PASS, FAIL, or SKIP, and the testname can be any
+identifying string.
+So we should change the test result format to match yocto ptest rules.
+
+Upstream-Status: Inappropriate [OE ptest specific]
+
+Signed-off-by: Li Wang 
+Signed-off-by: Jackie Huang 
+---
+ tests/runtest.sh | 5 +
+ 1 file changed, 5 insertions(+)
+
+diff --git a/tests/runtest.sh b/tests/runtest.sh
+index b6eaa7c..84263fb 100644
+--- a/tests/runtest.sh
 b/tests/runtest.sh
+@@ -21,6 +21,11 @@ for i in ${TESTS}; do
+ echo "### RUNNING TEST $i"
+ if [[ $AUTOMATED != 0 ]] ; then
+ bash ./runtest.sh
++if [ $? != 0 ]; then
++echo "FAIL: $i"
++else
++echo "PASS: $i"
++fi
+ else
+ bash ./runtest.sh || exit 1
+ fi
+-- 
+2.11.0
+
diff --git 
a/recipes-security/keyutils/files/keyutils-use-relative-path-for-link.patch 
b/recipes-security/keyutils/files/keyutils-use-relative-path-for-link.patch
new file mode 100644
index 000..dde1af4
--- /dev/null
+++ b/recipes-security/keyutils/files/keyutils-use-relative-path-for-link.patch
@@ -0,0 +1,28 @@
+Subject: [PATCH] keyutils: use relative path for link
+
+The absolute path of the symlink will be

[yocto] [meta-security][PATCH 0/2 v2] add new recipe for ecryptfs-utils and keyutils

2017-05-22 Thread jackie.huang 
From: Jackie Huang 

v2 comments:
- add systemd support
- add PACKAGECONFIG for pam to fix the warning

--
The following changes since commit 43ae8fc27eb411e91285eb374f05682ca8bee055:

  packagegroup-security-tpm-i2c: fix syntax (2017-05-19 07:37:35 -0700)

are available in the git repository at:

  https://github.com/jackiehjm/meta-security.git 
jhuang0/r_up_ecryptfs_keyutils_170523_0
  https://github.com//tree/jhuang0/r_up_ecryptfs_keyutils_170523_0

Jackie Huang (2):
  keyutils: add new recipe
  ecryptfs-utils: add new recipe

 .../ecryptfs-utils/ecryptfs-utils_111.bb   | 64 +
 .../files/ecryptfs-utils-CVE-2016-6224.patch   | 65 ++
 .../ecryptfs-utils/files/ecryptfs.service  |  9 +++
 ...ix-error-report-by-adding-default-message.patch | 42 ++
 .../files/keyutils-test-fix-output-format.patch| 41 ++
 .../keyutils-use-relative-path-for-link.patch  | 28 ++
 recipes-security/keyutils/files/run-ptest  |  3 +
 recipes-security/keyutils/keyutils_1.5.10.bb   | 45 +++
 8 files changed, 297 insertions(+)
 create mode 100644 recipes-security/ecryptfs-utils/ecryptfs-utils_111.bb
 create mode 100644 
recipes-security/ecryptfs-utils/files/ecryptfs-utils-CVE-2016-6224.patch
 create mode 100644 recipes-security/ecryptfs-utils/files/ecryptfs.service
 create mode 100644 
recipes-security/keyutils/files/keyutils-fix-error-report-by-adding-default-message.patch
 create mode 100644 
recipes-security/keyutils/files/keyutils-test-fix-output-format.patch
 create mode 100644 
recipes-security/keyutils/files/keyutils-use-relative-path-for-link.patch
 create mode 100755 recipes-security/keyutils/files/run-ptest
 create mode 100644 recipes-security/keyutils/keyutils_1.5.10.bb

-- 
2.11.0

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

Re: [yocto] sstate-cache question

2017-05-22 Thread Gary Thomas 

On 2017-05-22 22:35, Paul Eggleton wrote:

Hi Gary,

On Tuesday, 23 May 2017 2:53:45 AM NZST Gary Thomas wrote:

I have a build where I've never manually removed anything from
the sstate-cache and this same build has been used for hundreds
of builds over the last 18 months.  I just tried to find out why
gcc-cross-arm had to be rebuilt (it seems to happen almost every
time I update my Poky/Yocto tree (master)).  Here's what I got:

$ bitbake-diffsigs -t gcc-cross-arm compile
Hash for dependent task gcc/gcc-cross_6.3.bb.do_configure changed from

208373dd9ae01101a26a9412eb50b110 to

d65095d4b9aff89f6990bd17c0ab210b
Unable to find matching sigdata for /local/poky-cutting-edge/meta/recipes-

devtools/gcc/gcc-cross_6.3.bb.do_configure

with hashes 208373dd9ae01101a26a9412eb50b110 or

d65095d4b9aff89f6990bd17c0ab210b


So if I didn't remove those files, where did they go?  Am I doing
something wrong running this tool?  (running the same command for
qemu-native seemed to work correctly)


Is this with master, pyro, morty or some other version?


Poky master: 2568e18701fb20d7105eb6e4929f3aff4b9f9c06



If you search for files with those hashes in their name do they show up?


Only .siginfo files:
$ find sstate-cache/ -name "*d65095d4b9aff89f6990bd17c0ab210b*"
sstate-cache/universal/d6/sstate:gcc-cross-arm:x86_64-amltd-linux-gnueabi:6.3.0:r0:x86_64_arm:3:d65095d4b9aff89f6990bd17c0ab210b_configure.tgz.siginfo
$ find sstate-cache -name "*208373dd9ae01101a26a9412eb50b110*"
sstate-cache/universal/20/sstate:gcc-cross-arm:x86_64-amltd-linux-gnueabi:6.3.0:r0:x86_64_arm:3:208373dd9ae01101a26a9412eb50b110_configure.tgz.siginfo

However, I do find some in tmp/stamps:
$ ls tmp/stamps/x86_64-linux/gcc-cross-arm
6.3.0-r0.do_build.41aca0d85971087f4675d2f504642ce4
6.3.0-r0.do_compile.b0eae7e91833efd5e7eceaedbc59983e
6.3.0-r0.do_compile.sigdata.9a06aa40225be30babaceb7673cef0a6
6.3.0-r0.do_compile.sigdata.b0eae7e91833efd5e7eceaedbc59983e
6.3.0-r0.do_configure.d65095d4b9aff89f6990bd17c0ab210b
6.3.0-r0.do_configure.sigdata.208373dd9ae01101a26a9412eb50b110
6.3.0-r0.do_configure.sigdata.d65095d4b9aff89f6990bd17c0ab210b
6.3.0-r0.do_fetch.1dd3c87b3e509c20fa4ffe61d6dc3b41
6.3.0-r0.do_gcc_stash_builddir.063822f91220bb40cef0696eb604a568
6.3.0-r0.do_gcc_stash_builddir.sigdata.063822f91220bb40cef0696eb604a568
6.3.0-r0.do_gcc_stash_builddir.sigdata.28144d3c18c0a09f23f3b0c5e80f049d
6.3.0-r0.do_install.0f96c5448dc9360ca3a24d551ad3da89
6.3.0-r0.do_install.sigdata.0f96c5448dc9360ca3a24d551ad3da89
6.3.0-r0.do_install.sigdata.f2e4d12289c5039854081a832dc8bc0e
6.3.0-r0.do_populate_lic_setscene.d2c9226ddb0de5277e2347b69ef84664
6.3.0-r0.do_populate_sysroot.15afc3bb019a6c0c1285cbda46cb32b0
6.3.0-r0.do_populate_sysroot.sigdata.15afc3bb019a6c0c1285cbda46cb32b0
6.3.0-r0.do_populate_sysroot.sigdata.a0c5b715ae9217f02318beff6987d169
6.3.0-r0.do_prepare_recipe_sysroot.150112323551011e0e87f99f47ad79c4
6.3.0-r0.do_prepare_recipe_sysroot.sigdata.150112323551011e0e87f99f47ad79c4
6.3.0-r0.do_prepare_recipe_sysroot.sigdata.4a528becf11832cc3b8f6fa479e98210

I guess the sstate-cache info alone is not sufficient to use 'bitbake diffsigs'?
I do occasionally wipe tmp & downloads, so that may explain these errors.

--

Gary Thomas |  Consulting for the
MLB Associates  |Embedded world

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

Re: [yocto] [meta-security][PATCH 2/2] ecryptfs-utils: add new recipe

2017-05-22 Thread Huang, Jie (Jackie) 
Hi Martin,

Thanks for the reference, but the one in meta-ivi is an older version and
also has the same pam issue, I will fix it with PACKAGECONFIG and
DISTRO_FEATURES check for PAM, and also add the systemd support.

Thanks,
Jackie

From: Martin Jansa [mailto:martin.ja...@gmail.com]
Sent: Friday, May 19, 2017 23:27
To: Huang, Jie (Jackie)
Cc: akuster808; yocto@yoctoproject.org
Subject: Re: [yocto] [meta-security][PATCH 2/2] ecryptfs-utils: add new recipe

How does this one relate to:
http://git.yoctoproject.org/cgit/cgit.cgi/meta-ivi/tree/meta-ivi/recipes-support-ivi/ecryptfs-utils/ecryptfs-utils_106.bb?h=master

the later has also support for systemd, not sure if it has the issue with pam 
or not.

On Fri, May 19, 2017 at 4:56 PM, Huang, Jie (Jackie) 
> wrote:


> -Original Message-
> From: akuster808 [mailto:akuster...@gmail.com]
> Sent: Friday, May 19, 2017 22:50
> To: Huang, Jie (Jackie); yocto@yoctoproject.org
> Subject: Re: [yocto] [meta-security][PATCH 2/2] ecryptfs-utils: add new recipe
>
>
>
> On 05/17/2017 12:56 AM, 
> jackie.hu...@windriver.com wrote:
> > From: Jackie Huang 
> > >
> >
> > eCryptfs is a stacked cryptographic filesystem that ships
> > in Linux kernel versions 2.6.19 and above. This package
> > provides the mount helper and supporting libraries to
> > perform key management and mount functions.
> >
> > Signed-off-by: Jackie Huang 
> > >
>
> This has the following warning:
> WARNING: libpam-1.3.0-r5 do_pam_sanity: Building libpam but 'pam' isn't
> in DISTRO_FEATURES, PAM won't work correctly
>
> I noticed this package has the ability to disable-pam so maybe
> PACKAGECONFIG with the DISTRO_FEATURES check for PAM would be
> applicable
> in this case?
>
> please investigate.

I will investigate and fix the warning.

Thanks,
Jackie

>
> everything else looks fine for inclusion to meta-security.
>
> regards,
> Armin
>
> > ---
> >   .../ecryptfs-utils/ecryptfs-utils_111.bb
> >| 52 +
> >   .../files/ecryptfs-utils-CVE-2016-6224.patch   | 65
> ++
> >   2 files changed, 117 insertions(+)
> >   create mode 100644 
> > recipes-security/ecryptfs-utils/ecryptfs-utils_111.bb
> >   create mode 100644 
> > recipes-security/ecryptfs-utils/files/ecryptfs-utils-CVE-
> 2016-6224.patch
> >
> > diff --git 
> > a/recipes-security/ecryptfs-utils/ecryptfs-utils_111.bb
> >  b/recipes-
> security/ecryptfs-utils/ecryptfs-utils_111.bb
> > new file mode 100644
> > index 000..49c2605
> > --- /dev/null
> > +++ 
> > b/recipes-security/ecryptfs-utils/ecryptfs-utils_111.bb
> > @@ -0,0 +1,52 @@
> > +SUMMARY = "The eCryptfs mount helper and support libraries"
> > +DESCRIPTION = "eCryptfs is a stacked cryptographic filesystem \
> > +that ships in Linux kernel versions 2.6.19 and above. This \
> > +package provides the mount helper and supporting libraries \
> > +to perform key management and mount functions."
> > +HOMEPAGE = "https://launchpad.net/ecryptfs;
> > +SECTION = "base"
> > +
> > +LICENSE = "GPL-2.0"
> > +LIC_FILES_CHKSUM =
> "file://COPYING;md5=8ca43cbc842c2336e835926c2166c28b"
> > +
> > +DEPENDS = "keyutils libgcrypt libpam nss intltool-native glib-2.0-native"
> > +
> > +inherit autotools pkgconfig
> > +
> > +SRC_URI = "\
> > +
> https://launchpad.net/ecryptfs/trunk/${PV}/+download/${BPN}_${PV}.orig.tar.
> gz \
> > +
> > file://ecryptfs-utils-CVE-2016-6224.patch
> >  \
> > +"
> > +
> > +SRC_URI[md5sum] = "83513228984f671930752c3518cac6fd"
> > +SRC_URI[sha256sum] =
> "112cb3e37e81a1ecd8e39516725dec0ce55c5f3df6284e0f4cc0f118750a987f"
> > +
> > +PARALLEL_MAKEINST=""
> > +
> > +EXTRA_OECONF = "\
> > +--libdir=${base_libdir} \
> > +--disable-pywrap \
> > +--disable-nls \
> > +--enable-openssl=no \
> > +"
> > +
> > +do_configure_prepend() {
> > +export NSS_CFLAGS="-I${STAGING_INCDIR}/nspr4 -
> I${STAGING_INCDIR}/nss3"
> > +export NSS_LIBS="-L${STAGING_BASELIBDIR} -lssl3 -lsmime3 -lnss3 -
> lsoftokn3 -lnssutil3"
> > +export KEYUTILS_CFLAGS="-I${STAGING_INCDIR}"
> > +export KEYUTILS_LIBS="-L${STAGING_LIBDIR} -lkeyutils"
> > +}
> > +
> > +do_install_append() {
> > +chmod 4755 ${D}${base_sbindir}/mount.ecryptfs_private
> > +mkdir -p ${D}/${libdir}
> > +mv ${D}/${base_libdir}/pkgconfig ${D}/${libdir}
> > +sed -i -e 's:-I${STAGING_INCDIR}::' \
> > +   -e 's:-L${STAGING_LIBDIR}::' 
> > ${D}/${libdir}/pkgconfig/libecryptfs.pc
> > +sed -i -e "s:

Re: [linux-yocto] [kernel-cache] [PATCH] bsp/axxiaarm[64]: Enable AXXIA MDIO and EDAC drivers

2017-05-22 Thread Bruce Ashfield 

merged.

Bruce

On 2017-05-17 12:57 PM, Daniel Dragomir wrote:

Intel Axxia updates for yocto-kernel-cache, yocto-4.9 branch.

Enable AXXIA_MDIO driver, and EDAC_AXXIA_L2_CPU_5500 for
axxiaarm bsp | EDAC_AXXIA_L2_CPU_5600 for axxiaarm64 bsp.

Also, enable SWP_EMULATE proc feature for axxiaarm bsp.

Signed-off-by: Daniel Dragomir 
---
 bsp/axxiaarm/axxiaarm.cfg | 2 ++
 bsp/axxiaarm/edac.cfg | 2 +-
 bsp/axxiaarm64/axxiaarm64.cfg | 1 +
 bsp/axxiaarm64/edac.cfg   | 2 +-
 4 files changed, 5 insertions(+), 2 deletions(-)

diff --git a/bsp/axxiaarm/axxiaarm.cfg b/bsp/axxiaarm/axxiaarm.cfg
index 692a6c3..82f753c 100644
--- a/bsp/axxiaarm/axxiaarm.cfg
+++ b/bsp/axxiaarm/axxiaarm.cfg
@@ -30,6 +30,7 @@ CONFIG_ARM_TIMER_SP804=y
 CONFIG_ARM_LPAE=y
 CONFIG_ARCH_PHYS_ADDR_T_64BIT=y
 CONFIG_ARCH_DMA_ADDR_T_64BIT=y
+CONFIG_SWP_EMULATE=y
 CONFIG_ARM_ARCH_TIMER=y
 CONFIG_ARM_THUMBEE=y
 CONFIG_OUTER_CACHE=y
@@ -144,6 +145,7 @@ CONFIG_BLK_DEV_LOOP=y
 CONFIG_LSI_MTC=y
 CONFIG_LSI_NCR=y
 CONFIG_ATA=y
+CONFIG_AXXIA_MDIO=y

 #
 # EEPROM support
diff --git a/bsp/axxiaarm/edac.cfg b/bsp/axxiaarm/edac.cfg
index 1bd0d5c..23da7ad 100644
--- a/bsp/axxiaarm/edac.cfg
+++ b/bsp/axxiaarm/edac.cfg
@@ -15,6 +15,6 @@ CONFIG_EDAC=y
 CONFIG_EDAC_MM_EDAC=y
 CONFIG_EDAC_AXXIA_SYSMEM_5500=y
 CONFIG_EDAC_AXXIA_L3=y
-CONFIG_EDAC_AXXIA_L2_CPU=y
+CONFIG_EDAC_AXXIA_L2_CPU_5500=y

 # CONFIG_LSI_SMMON is not set
diff --git a/bsp/axxiaarm64/axxiaarm64.cfg b/bsp/axxiaarm64/axxiaarm64.cfg
index c31e8ba..73096a3 100644
--- a/bsp/axxiaarm64/axxiaarm64.cfg
+++ b/bsp/axxiaarm64/axxiaarm64.cfg
@@ -106,6 +106,7 @@ CONFIG_LSI_NCR=y
 CONFIG_ARCH_AXXIA_NCR_RESET_CHECK=y
 CONFIG_AXXIA_OEM=y
 CONFIG_AXXIA_PEI=y
+CONFIG_AXXIA_MDIO=y

 #
 # SCSI device support
diff --git a/bsp/axxiaarm64/edac.cfg b/bsp/axxiaarm64/edac.cfg
index b338756..d9fc4f3 100644
--- a/bsp/axxiaarm64/edac.cfg
+++ b/bsp/axxiaarm64/edac.cfg
@@ -16,6 +16,6 @@ CONFIG_EDAC_MM_EDAC=y
 CONFIG_EDAC_AXXIA_SYSMEM_5600=y
 CONFIG_EDAC_AXXIA_CMEM_5600=y
 # CONFIG_EDAC_AXXIA_L3 is not set
-# CONFIG_EDAC_AXXIA_L2_CPU is not set
+CONFIG_EDAC_AXXIA_L2_CPU_5600=y

 # CONFIG_LSI_SMMON is not set



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

Re: [linux-yocto] [PATCH] smp: Adds config X86_BIGSMP since its needed when NR_CPUS > 8

2017-05-22 Thread Bruce Ashfield 

merged.

SRCREV updates will follow shortly.

Bruce

On 2017-05-17 11:18 AM, Alejandro Hernandez wrote:

When we set NR_CPUS to something > than 8, we also need to set X86_BIGSMP
according to Kconfig:

config X86_BIGSMP
bool "Support for big SMP systems with more than 8 CPUs"

otherwise NR_CPU will end up being reset to 8

[YOCTO #10362]

Signed-off-by: Alejandro Hernandez 
---
 cfg/smp.cfg | 4 
 1 file changed, 4 insertions(+)

diff --git a/cfg/smp.cfg b/cfg/smp.cfg
index 22047746..bf7348cb 100644
--- a/cfg/smp.cfg
+++ b/cfg/smp.cfg
@@ -3,3 +3,7 @@ CONFIG_SCHED_SMT=y
 # Increase default NR_CPUS from 8 to 64 so that platform with
 # more than 8 processors can be all activated at boot time
 CONFIG_NR_CPUS=64
+# The following is nedded when setting NR_CPUS to something
+# greater than 8 on x86 architectures, it should be automatically
+# disregarded by Kconfig when using a different arch
+CONFIG_X86_BIGSMP=y



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

Re: [linux-yocto] [PATCH] bluetooth: Adds BT_BREDR and BT_LE, which are needed as dependencies

2017-05-22 Thread Bruce Ashfield 

Sorry for the delay, this is now merged.

Bruce

On 2017-05-16 5:34 PM, Alejandro Hernandez wrote:

Several configurations need the previously mentioned dependencies:

BT_LE is nedded by BT_6LOWPAN

BT_BREDR is needed by:
BT_RFCOMM, BT_RFCOMM_TTY (secondary),
BT_BNEP, BT_BNEP_MC_FILTER (secondary), BNEP_PROTO_FILTER (secondary),
BT_CMTP, BT_HIDP

[YOCTO #10425]

Signed-off-by: Alejandro Hernandez 
---
 features/bluetooth/bluetooth.cfg | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/features/bluetooth/bluetooth.cfg b/features/bluetooth/bluetooth.cfg
index 67d3f528..7f07298a 100644
--- a/features/bluetooth/bluetooth.cfg
+++ b/features/bluetooth/bluetooth.cfg
@@ -12,3 +12,5 @@ CONFIG_BT_BNEP_MC_FILTER=y
 CONFIG_BT_BNEP_PROTO_FILTER=y
 CONFIG_BT_CMTP=m
 CONFIG_BT_HIDP=m
+CONFIG_BT_LE=y
+CONFIG_BT_BREDR=y



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

Re: [yocto] How to build initramfs with modules but without bzImage

2017-05-22 Thread Ferry Toth 
Op Mon, 22 May 2017 00:05:41 +0200, schreef Ferry Toth:

> I am building 2 images. One has my rootfs, the other builds a kernel
> with builtin initramfs.
> 
> To build the initramfs I did the following:
> In the .../conf directory, I create a file named initramfs.conf and add
> the following:
>  
> INITRAMFS_IMAGE = "core-image-minimal-initramfs"
> INITRAMFS_IMAGE_BUNDLE = "1"
>  
> IMAGE_FSTYPES = "cpio.gz"
>  
> Then to build the initramfs based on the core-image-base recipe, I
> execute the following bitbake command:
>  
>  bitbake -R conf/initramfs.conf core-image-minimal-initramfs
>  
> When it completes, there is a kernel + initramfs file in the .../tmp/
> deploy/images//  directory.
>  
> This image boots to the init script, but then hangs as the mmc drivers
> have not been included.
> 
> Now I create a core-image-minimal-initramfs.bbappend file and
> PACKAGE_INSTALL the modules I need (also tried kernel-modules).
> 
> Unfortunately this also installs the kernel bzImage in the /boot
> directory, that appears to be a dependancy. This adds another 6MB to my
> initramfs, which is now to load.
> 
> I expect it should be possible to add the modules without adding the
> kernel, but haven't been able to find a way to do that. Or it should be
> possible to remove the contents of /boot after do_rootfs.
> 
> But I have no clue how to do that.
> 
> Or am I just generating the initramfs in the wrong way?

Thanks people especially paulg and khem on irc,

I added to my core-image-minimal-initramfs.bbappend:

ROOTFS_POSTPROCESS_COMMAND += "clobber_unused"

clobber_unused () {
rm ${IMAGE_ROOTFS}/boot/*
}

This shrink my initramfs just enough to boot. Of course I can remove more 
files if needed, by adding dir's to the clobber function.

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

Re: [yocto] sstate-cache question

2017-05-22 Thread Paul Eggleton 
Hi Gary,

On Tuesday, 23 May 2017 2:53:45 AM NZST Gary Thomas wrote:
> I have a build where I've never manually removed anything from
> the sstate-cache and this same build has been used for hundreds
> of builds over the last 18 months.  I just tried to find out why
> gcc-cross-arm had to be rebuilt (it seems to happen almost every
> time I update my Poky/Yocto tree (master)).  Here's what I got:
> 
> $ bitbake-diffsigs -t gcc-cross-arm compile
> Hash for dependent task gcc/gcc-cross_6.3.bb.do_configure changed from 
208373dd9ae01101a26a9412eb50b110 to 
> d65095d4b9aff89f6990bd17c0ab210b
> Unable to find matching sigdata for /local/poky-cutting-edge/meta/recipes-
devtools/gcc/gcc-cross_6.3.bb.do_configure 
> with hashes 208373dd9ae01101a26a9412eb50b110 or 
d65095d4b9aff89f6990bd17c0ab210b
> 
> So if I didn't remove those files, where did they go?  Am I doing
> something wrong running this tool?  (running the same command for
> qemu-native seemed to work correctly)

Is this with master, pyro, morty or some other version?

If you search for files with those hashes in their name do they show up?

Cheers,
Paul

-- 

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

[linux-yocto] v4.8.x - stable updates comprising v4.8.23

2017-05-22 Thread Paul Gortmaker 
Bruce, Yocto kernel folks:

Here is another 4.8.x stable update.  Continuing on top of the previously
released v4.8.22 kernel, we now have the appropriate content from 4.9.15
to 4.9.17 applied on top of our latest 4.8 baseline.  Once again, I've
combined several 4.9.x which results in about 165 backported commits out
of the 200 found in that 4.9.x range.

As before, I've put this 4.8.x queue through the various testing that I
figured made sense, which includes but is not limited to:

-x86-64 sanity boot test of defconfig on COTS Core2 i915 family box.
-build MIPS, PPC, ARM, ARM64 with yocto .config and toolchains
-build x86-64 allmodconfig/allyesconfig
-build i386 defconfig

I bumped the Makefile and did the signed tag just as per the previously
released 4.8.x versions.

Please find a signed v4.8.23 tag using this key:

http://pgp.mit.edu/pks/lookup?op=vindex=0xEBCE84042C07D1D6

in the repo in my kernel.org directory here:

   https://git.kernel.org/cgit/linux/kernel/git/paulg/linux-4.8.y.git/
   git://git.kernel.org/pub/scm/linux/kernel/git/paulg/linux-4.8.y.git

for merge to standard/base in linux-yocto-4.8 and then out from there
into the other base and BSP branches.

For those who are interested, the evolution of the commits is here:

   https://git.kernel.org/cgit/linux/kernel/git/paulg/longterm-queue-4.8.git/

This repo isn't needed for anything; it just exists for transparency and
so people can see how the commits were adjusted to apply to the 4.8.x
kernel baseline in case people are interested.

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

Re: [yocto] Creating a directory in a recipe

2017-05-22 Thread Joshua Watt 
On Sun, May 21, 2017 at 7:25 AM, bahjat khan  wrote:

> *do_install() {*
> *  install -d /test/*
>
> Should be: install -d ${D}/test/

>
> *install -m 0777 bye.sh /test/*
>
> Should be: install -m 0777 bye.sh ${D}/test/

> *}*
>
> All of your install tasks need to install into the ${D} directory

See:
http://www.yoctoproject.org/docs/2.3/mega-manual/mega-manual.html#ref-tasks-install
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

[yocto] Creating a directory in a recipe

2017-05-22 Thread bahjat khan 
I've searched the vast net for an answer to this but i've found NOTHING!  that 
works for me. All i want to do is a simple task, i want to create a new 
directory called "test" located in "/".
 My recipe is below

DESCRIPTION = "Hello world"
S = "${WORKDIR}"
SRC_URI="file://bye.sh"
LICENSE = "CLOSED"

LIC_FILES_CHKSUM = "file://${S}/README;md5=e584df0feead52ed7de9b60172adc0cf "

#INHIBIT_DEFAULT_DEPS = "1"

do_install() {
  install -d /test/
install -m 0777 bye.sh /test/
}

 I can't seem to to do this, the error message is below
[cid:927d4972-8462-4e14-a645-1e674bf9e641]
I understand that there is a permissions issue with making a directory in "/" 
but i have no idea how to to get past this.

I feel it would be very useful to newbies (like me) if there was a tutorial 
which gave solutions to simple tasks like this. The reference manual breezes 
over most things and i understand that it can't cover everything but this does 
cause a massive barrier to entry when learning Yocto. Apologies if i'm sounding 
a bit harsh but i've been self teaching Yocto for 3 weeks in my spare time and 
still don't have any fruits to show for my labour :'(.

Kind Regards,
Bahjat
(Very stressed engineer)
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] [meta-rockchip][PATCH 0/3] u-boot: mainline

2017-05-22 Thread Trevor Woerner 
u-boot 2017.05 was released May 10. Wouldn't it be better to update
oe-core's u-boot to 2017.05 then just add any differences in
meta-rockchip?

On Mon, May 22, 2017 at 11:17 AM, Romain Perier
 wrote:
> This set of patches add a new u-boot-common file for 2017.05, so
> it can be shared between u-boot-rockchip and a u-boot recipe for
> mainline. Then, it add a bbappend to bump u-boot to the last
> v2017.05.
>
> Romain Perier (3):
>   u-boot: Add u-boot-common_2017.05.inc
>   u-boot-rockchip: Use u-boot-common_2017.05.inc
>   u-boot: Add bbappend for u-boot mainline
>
>  recipes-bsp/u-boot/u-boot-common_2017.05.inc | 14 ++
>  recipes-bsp/u-boot/u-boot-rockchip_git.bb|  2 +-
>  recipes-bsp/u-boot/u-boot_%.bbappend |  5 +
>  3 files changed, 20 insertions(+), 1 deletion(-)
>  create mode 100644 recipes-bsp/u-boot/u-boot-common_2017.05.inc
>  create mode 100644 recipes-bsp/u-boot/u-boot_%.bbappend
>
> --
> 1.8.3.1
>
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

[yocto] [meta-rockchip][PATCH 3/3] u-boot: Add bbappend for u-boot mainline

2017-05-22 Thread Romain Perier 
This bumps u-boot mainline to the last v2017.05

Signed-off-by: Romain Perier 
---
 recipes-bsp/u-boot/u-boot_%.bbappend | 5 +
 1 file changed, 5 insertions(+)
 create mode 100644 recipes-bsp/u-boot/u-boot_%.bbappend

diff --git a/recipes-bsp/u-boot/u-boot_%.bbappend 
b/recipes-bsp/u-boot/u-boot_%.bbappend
new file mode 100644
index 000..a7fc393
--- /dev/null
+++ b/recipes-bsp/u-boot/u-boot_%.bbappend
@@ -0,0 +1,5 @@
+PV="2017.05"
+
+require u-boot-common_${PV}.inc
+
+DEPENDS += "bc-native dtc-native"
-- 
1.8.3.1

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

[yocto] [meta-rockchip][PATCH 2/3] u-boot-rockchip: Use u-boot-common_2017.05.inc

2017-05-22 Thread Romain Perier 
Now, use the new common include file for u-boot

Signed-off-by: Romain Perier 
---
 recipes-bsp/u-boot/u-boot-rockchip_git.bb | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/recipes-bsp/u-boot/u-boot-rockchip_git.bb 
b/recipes-bsp/u-boot/u-boot-rockchip_git.bb
index 291438a..2785d35 100644
--- a/recipes-bsp/u-boot/u-boot-rockchip_git.bb
+++ b/recipes-bsp/u-boot/u-boot-rockchip_git.bb
@@ -4,7 +4,7 @@
 # Released under the MIT license (see COPYING.MIT for the terms)
 
 require recipes-bsp/u-boot/u-boot.inc
-require recipes-bsp/u-boot/u-boot-common_2017.01.inc
+require u-boot-common_2017.05.inc
 
 DESCRIPTION = "Rockchip next-dev U-Boot"
 COMPATIBLE_MACHINE = "(firefly-rk3288|rock2-square)"
-- 
1.8.3.1

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

[yocto] [meta-rockchip][PATCH 1/3] u-boot: Add u-boot-common_2017.05.inc

2017-05-22 Thread Romain Perier 
This adds new common file for u-boot 2017.05, so u-boot mainline recipe
and u-boot-rockchip can share common information about this version.

Signed-off-by: Romain Perier 
---
 recipes-bsp/u-boot/u-boot-common_2017.05.inc | 14 ++
 1 file changed, 14 insertions(+)
 create mode 100644 recipes-bsp/u-boot/u-boot-common_2017.05.inc

diff --git a/recipes-bsp/u-boot/u-boot-common_2017.05.inc 
b/recipes-bsp/u-boot/u-boot-common_2017.05.inc
new file mode 100644
index 000..3719aee
--- /dev/null
+++ b/recipes-bsp/u-boot/u-boot-common_2017.05.inc
@@ -0,0 +1,14 @@
+HOMEPAGE = "http://www.denx.de/wiki/U-Boot/WebHome;
+SECTION = "bootloaders"
+
+LICENSE = "GPLv2+"
+LIC_FILES_CHKSUM = 
"file://Licenses/README;md5=a2c678cfd4a4d97135585cad908541c6"
+PE = "1"
+
+# We use the revision in order to avoid having to fetch it from the
+# repo during parse
+SRCREV = "64c4ffa9fa223f7ae8640f9c8f3044bfa0e3bfda"
+
+SRC_URI = "git://git.denx.de/u-boot.git"
+
+S = "${WORKDIR}/git"
-- 
1.8.3.1

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

[yocto] [meta-rockchip][PATCH 0/3] u-boot: mainline

2017-05-22 Thread Romain Perier 
This set of patches add a new u-boot-common file for 2017.05, so
it can be shared between u-boot-rockchip and a u-boot recipe for
mainline. Then, it add a bbappend to bump u-boot to the last
v2017.05.

Romain Perier (3):
  u-boot: Add u-boot-common_2017.05.inc
  u-boot-rockchip: Use u-boot-common_2017.05.inc
  u-boot: Add bbappend for u-boot mainline

 recipes-bsp/u-boot/u-boot-common_2017.05.inc | 14 ++
 recipes-bsp/u-boot/u-boot-rockchip_git.bb|  2 +-
 recipes-bsp/u-boot/u-boot_%.bbappend |  5 +
 3 files changed, 20 insertions(+), 1 deletion(-)
 create mode 100644 recipes-bsp/u-boot/u-boot-common_2017.05.inc
 create mode 100644 recipes-bsp/u-boot/u-boot_%.bbappend

-- 
1.8.3.1

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

Re: [linux-yocto] [PATCH 00/17] Intel Axxia updates to linux-yocto-4.9

2017-05-22 Thread Dragomir, Daniel 
Hi Bruce!

Did you had time to look into this set?
I sent also a patch for kernel-cache.

Regards,
Daniel

From: Daniel Dragomir [daniel.drago...@windriver.com]
Sent: Tuesday, May 16, 2017 9:38 PM
To: linux-yocto@yoctoproject.org
Cc: Ashfield, Bruce; Dragomir, Daniel
Subject: [linux-yocto] [PATCH 00/17] Intel Axxia updates to linux-yocto-4.9

Hello Bruce!

This series of patches brings various improvements to the Intel Axxia
drivers from linux-yocto-4.9, including MISC, NCR, USB, CORESIGHT, PCI,
sRIO, MDIO drivers and some updates in device trees for Intel Axxia boards.

I checked all the patches with checkpatch.pl script and fixed all errors.
Also, I compiled Axxia BSP using both branches and successfully booted the 
board.

Please pull the patches from
https://github.com/axxia/axxia_yocto_linux_4.9_pull.git
into
git://git.yoctoproject.org/linux-yocto-4.9

Pull
standard/axxia/base-1.6 -> standard/axxia/base
standard/preempt-rt/axxia/base-1.6 -> 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

Charlie Paul (2):
  drivers/usb/core: fix over-current race condition
  drivers/usb/dwc3: Initialize dma for axxia dwc3

Gary McGee (4):
  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

John Jacques (11):
  drivers/pci: Support the Updated Axxia PCIe/sRIO Coefficients
  axxia: Clean Up the MDIO Access Code
  axxia: Remove Debug Prints
  drivers/misc: Fix a Wrong Address in the Axxia NCR Driver
  axxia: Added L1/L2 cache edac drivers for AXM56xx family
  drivers/pci: Fix a Compiler Warning in the Axxia Driver
  drivers/misc: Update the Axxia PEI Driver
  drivers/misc: Fix an Error in the Axxia OEM Driver
  opencsd: This is a Backport of the Following
  drivers/misc: Update the Axxia NCR Driver
  drivers/misc: Updates to the Axxia PEI Driver

 .../devicetree/bindings/arm/axxia/edac_cpu.txt |   14 +
 .../devicetree/bindings/arm/axxia/edac_l2.txt  |   14 +
 Documentation/trace/coresight.txt  |  138 +-
 arch/arm/include/asm/axxia_l2_55xx.h   |   32 +
 arch/arm64/boot/dts/intel/axc6732-waco.dts |7 +
 arch/arm64/boot/dts/intel/axc67xx.dtsi |4 +-
 arch/arm64/boot/dts/intel/axm5616-victoria.dts |   17 +
 arch/arm64/boot/dts/intel/axm56xx.dtsi |   15 +-
 arch/arm64/include/asm/axxia_l2_56xx.h |   35 +
 drivers/edac/Kconfig   |   12 +-
 drivers/edac/Makefile  |6 +-
 drivers/edac/axxia_edac-l2_cpu.c   |   27 +-
 drivers/edac/axxia_edac-l2_cpu_56xx.c  |  299 
 drivers/hwtracing/coresight/coresight-etm-perf.c   |   31 +-
 drivers/hwtracing/coresight/coresight-etm.h|5 +
 .../hwtracing/coresight/coresight-etm3x-sysfs.c|   12 +-
 drivers/hwtracing/coresight/coresight-priv.h   |4 +-
 drivers/hwtracing/coresight/coresight-stm.c|9 +-
 drivers/hwtracing/coresight/coresight-tmc-etf.c|   48 +-
 drivers/hwtracing/coresight/coresight-tmc-etr.c|  286 +++-
 drivers/hwtracing/coresight/coresight-tmc.h|2 +-
 drivers/hwtracing/coresight/coresight.c|   62 +-
 drivers/misc/Kconfig   |6 +
 drivers/misc/Makefile  |1 +
 drivers/misc/axxia-mdio.c  |  225 +++
 drivers/misc/axxia-oem.c   |   12 +-
 drivers/misc/axxia-pei.c   | 1653 +++-
 drivers/misc/lsi-ncr.c |  372 -
 drivers/net/ethernet/lsi/Kconfig   |   34 -
 drivers/net/ethernet/lsi/Makefile  |2 -
 drivers/net/ethernet/lsi/lsi-femac.c   | 1198 --
 drivers/net/ethernet/lsi/lsi-mdio.c|  205 ---
 drivers/pci/host/pcie-axxia.c  |  139 +-
 drivers/usb/core/hub.c |7 +-
 drivers/usb/dwc3/dwc3-axxia.c  |2 +-
 include/linux/axxia-mdio.h |   21 +
 include/linux/axxia-pei.h  |6 +-
 include/linux/lsi-ncr.h|3 +
 tools/perf/Makefile.config |   18 +
 tools/perf/Makefile.perf   |3 +
 tools/perf/arch/arm/util/cs-etm.c  |2 -
 tools/perf/builtin-script.c|3 +-
 tools/perf/scripts/python/cs-trace-disasm.py   |  134 ++
 tools/perf/scripts/python/cs-trace-ranges.py   |   44 +
 tools/perf/util/Build  |2 +
 tools/perf/util/auxtrace.c

Re: [yocto] sstate-cache question

2017-05-22 Thread Gary Thomas 

On 2017-05-22 16:53, Gary Thomas wrote:

I have a build where I've never manually removed anything from
the sstate-cache and this same build has been used for hundreds

 ^directory^

of builds over the last 18 months.  I just tried to find out why
gcc-cross-arm had to be rebuilt (it seems to happen almost every
time I update my Poky/Yocto tree (master)).  Here's what I got:

$ bitbake-diffsigs -t gcc-cross-arm compile
Hash for dependent task gcc/gcc-cross_6.3.bb.do_configure changed from 
208373dd9ae01101a26a9412eb50b110 to
d65095d4b9aff89f6990bd17c0ab210b
Unable to find matching sigdata for 
/local/poky-cutting-edge/meta/recipes-devtools/gcc/gcc-cross_6.3.bb.do_configure
with hashes 208373dd9ae01101a26a9412eb50b110 or d65095d4b9aff89f6990bd17c0ab210b

So if I didn't remove those files, where did they go?  Am I doing
something wrong running this tool?  (running the same command for
qemu-native seemed to work correctly)

Thanks for any ideas




--

Gary Thomas |  Consulting for the
MLB Associates  |Embedded world

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

[yocto] sstate-cache question

2017-05-22 Thread Gary Thomas 

I have a build where I've never manually removed anything from
the sstate-cache and this same build has been used for hundreds
of builds over the last 18 months.  I just tried to find out why
gcc-cross-arm had to be rebuilt (it seems to happen almost every
time I update my Poky/Yocto tree (master)).  Here's what I got:

$ bitbake-diffsigs -t gcc-cross-arm compile
Hash for dependent task gcc/gcc-cross_6.3.bb.do_configure changed from 208373dd9ae01101a26a9412eb50b110 to 
d65095d4b9aff89f6990bd17c0ab210b
Unable to find matching sigdata for /local/poky-cutting-edge/meta/recipes-devtools/gcc/gcc-cross_6.3.bb.do_configure 
with hashes 208373dd9ae01101a26a9412eb50b110 or d65095d4b9aff89f6990bd17c0ab210b


So if I didn't remove those files, where did they go?  Am I doing
something wrong running this tool?  (running the same command for
qemu-native seemed to work correctly)

Thanks for any ideas

--

Gary Thomas |  Consulting for the
MLB Associates  |Embedded world

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

Re: [yocto] unmodified binary RPM installed on rootfs?

2017-05-22 Thread Alexander Kanavin 

On 05/22/2017 02:43 AM, Russell Peterson wrote:

I am fairly new to yocto and I think I’m having trouble installing an
RPM on the rootfs. What I am trying to do is install an arm64 binary RPM
file straight onto the root file system without a recipe… just use the
native rpm tool to put it there.  There are several reasons why I’m
experimenting with this.  Seems fairly simple but I have now been
messing around for days with little to show for it.  Here is what I’m doing…


Yocto does not currently support installing 3rd party RPMs. Even if it 
would install, whatever contents it has would very likely not work due 
to mismatches between the environment where the rpm was built and the 
environment where you are installing it. And --nodeps would only make 
the problem worse.


You have to write a recipe.


Alex

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

[yocto] How to build initramfs with modules but without bzImage

2017-05-22 Thread Ferry Toth 
I am building 2 images. One has my rootfs, the other builds a kernel with 
builtin initramfs.

To build the initramfs I did the following:
In the .../conf directory, I create a file named initramfs.conf and add 
the following:
 
INITRAMFS_IMAGE = "core-image-minimal-initramfs"
INITRAMFS_IMAGE_BUNDLE = "1"
 
IMAGE_FSTYPES = "cpio.gz"
 
Then to build the initramfs based on the core-image-base recipe, I 
execute the following bitbake command:
 
 bitbake -R conf/initramfs.conf core-image-minimal-initramfs
 
When it completes, there is a kernel + initramfs file in the .../tmp/
deploy/images//  directory.
 
This image boots to the init script, but then hangs as the mmc drivers 
have not been included.

Now I create a core-image-minimal-initramfs.bbappend file and
PACKAGE_INSTALL the modules I need (also tried kernel-modules).

Unfortunately this also installs the kernel bzImage in the /boot 
directory, that appears to be a dependancy. This adds another 6MB to my 
initramfs, which is now to load.

I expect it should be possible to add the modules without adding the 
kernel, but haven't been able to find a way to do that. Or it should be 
possible to remove the contents of /boot after do_rootfs.

But I have no clue how to do that.

Or am I just generating the initramfs in the wrong way?

Ferry

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